「タスク」と「プロジェクト」を語源から考える（以前チームで話したこと①） ──タスクは踊る、されど組織進まず？
こんなことありませんか？
・「締め切り」と「やること」はある。でも、何のためにそれをやっているのかは上手く説明しづらい
・毎日ちゃんと仕事は進んでいるはずなのに、誰が責任を持っているのかよくわからない部分がある
・この仕事の先に、何が変わるのかイメージできない
・明らかに手間はかかっているのに、「で、新しい成果は？」と聞かれると答えに詰まる
・いつの間にか、いつも最後は有志の頑張りでなんとかしている
これはなぜだろうか、という問いが今日の内容。
このnoteは自分が管理本部長になって4ヶ月目にチームで話ししたことでもある。（一度資料化したものをテキストに落として書くので、読みにくいかもしれない）
仕事が「プロジェクトなきタスク」化してしまう組織構造の罠の話だ。これは「現場論」というよりは、「マネジメントの構造論」である。
効率化重視／人員不足の組織ほど、この罠にかかりやすいかも知れない。
気付いたときには、「忙しいのに、何も積み上がっていない」感覚だけが残る。そしてその状態は、ある日突然ではなく、毎日の「正しさ」の積み重ねで進行する。
上の問題は「「タスク」だけが回っていて、「プロジェクト」がないのでは？」という仮説
タスクは大量に存在しているのに、それらを包摂できる「プロジェクト」が存在していない構造がある。問題はそこにあるのでははない、というのが今回の仮説である。
やることは決まっている。手も動いている。でも、それらがどこに向かって束ねられているのかが見えない。
この状態が続くと、例えば下記のようなことが起こ得る。
・目的がよくわからない作業が続く
・成果として評価されにくい
・仕事は回っているのに、組織として賢くなっている感じがしない
・ちゃんとやっているのに、なぜか報われない
念のため、当たり前だがタスク自体が悪いわけではない。
タスクは仕事の最小単位で、仕事を動かすためには不可欠である。
ただし決定的な違いは、そのタスクが、プロジェクトという傘の下で行われているかどうか。プロジェクトなきタスクになっていないかどうか。
同じ作業でも、プロジェクトの中に位置づけられているかどうかで、意味も評価も学びも動機もまったく変わると実感することが多い。
余談：ちなみに「タスクなきプロジェクト」というのも起きがちな大問題だが、それは別の話題なので今回は割愛。
目的が抽象化され、責任が曖昧になり、聞こえての良い言葉だけで何も進まないことがある。優れたタスクは悪いプロジェクトより圧倒的に価値があるというのは言うまでもない。
また、プロジェクトばかり多量に生まれた状況は認知的負荷を高めやすいことも言及しておく。（認知能力はこれからの時代の最も重要なリソースの1つだ）
なぜ組織は、無意識に「タスク化」へ流れやすいか
多くの組織は大きくなるに従って、プロジェクト→プロジェクトなきタスク化へ流れてしまいやすい。（本当なら、個別のタスク→プロジェクト化したいのに）
一つは、仕組みが効率的であればあるほど、思想がなくても回ってしまうからだろう。
・依頼フローが整っている
・承認ルートが決まっている
・チェックリストが用意されている
こうした仕組みは、仕事を速く、正確に進めるためにはとても優秀だ。認知的負荷を下げる。
ただ、その結果として、「なぜやるのか」を誰も考えなくても仕事が進む状態が生まれる。
特にマネージャーが「指示出し」に終始し、「意味づけ」を忘れたときにこの現象は加速する。
もう一つは、プロジェクト化すると、
・目的を言語化しなければならない
・役割や責任を決めなければならない
・途中で振り返る必要が出てくる
といった、少し面倒で、場合によっては衝突も起きる作業が増えるからではないか。
タスクだけがワークしている状態は摩擦や認知負荷を減らし、短期的にとてもラクになる。
下記のような場合はタスクだけがワークしている可能性が高い。
・目的を聞くと、手段や経緯が返ってくる
・責任者／オーナーより「作業者」の名前が先に出る
・振り返りが「反省会」で終わる
語源で見る「タスク」と「プロジェクト」の違い
言葉の由来を見ると、「タスク」と「プロジェクト」のの違いがはっきりする。
（この記事で一番伝えたいのはこのパートなので、ここだけでも読んで欲しい。）
・Task は中世フランス語のtaspueより、「課せられた義務」「評価や課税の対象」といった意味を持ち、外部から与えられる仕事
・Project はラテン語proiectumより、「前方に投げる」「未来に向けて構想する」という意味を持ち、内発的な意志を含む行為
タスク中心の組織の仕事では、「与えられたことを正しくこなす」ことが重視される。
一方で、プロジェクト中心の組織の仕事では、「どんな未来をつくろうとしているか」が起点になのではないか。
下記の図を見てみて欲しい。
わかりやすくすると、下記のような整理も可能である。
タスク：完了条件が「行為」で定義可能な仕事
プロジェクト：完了条件が「状態変化」で定義可能な仕事
ただただ眼の前に現れるタスクを漫然とこなすことは、人生の時間を納税しているようなものだ。
一方で、プロジェクトは自分の意志を未来に投資する行為になり得る。
私たちは今、仕事を通じて税を納めているのか。それとも、未来に投げかけているのか。
チームを動かす「動機づけ」にもプロジェクトは重要だ。人はToDoではなく、未来に動機づけられるからである。
「プロジェクト」化する
プロジェクト化する」と聞くと、
・計画書を作ること
・管理を厳しくすること
・会議を増やすこと
そんなイメージを持たれがちだが、少し違う。
プロジェクト化とは、「存在するタスクに、ひとつの「意味づけ」と「時間軸」を与えること」と言えると思う。構造と骨格をつくることだ。
もちろん、タスクをただ積み上げたものではない。
もう少し噛み砕くと、
・この仕事は、何を実現しようとしているか／何を変えようとしているのか
・そのために、いま何をやっているのか
・いつまでに、どんな状態になれば一区切りなのか
これらを言葉にして、共有可能な形にすること、とも言える。
タスクは「やること」。一方、プロジェクトは、「なぜそれをやるのか」「どこへ向かうのか」を含んだストーリー。
だから、プロジェクト化すると、
・途中で立ち止まって考えることができる
・やらない判断もできるようになる
・成果を振り返り、次に引き渡せる
といった変化も作れる。
管理を強めるためではなく、考え続けられる状態をつくるために行うのが、プロジェクト化と言えるのではないか。
一見「プロジェクト」化なんてできなそうな日々繰り返していいただいているルーティンも「四半期のキックオフ」とか切ればできる。
「何を改善したいのか」「期間としていつ区切るか」を考えるだけでも、一段階タスクへの向き合いも変わるのではないだろうか。
「プロジェクト」化すると、何が変わるのかをまとめると下記になる。
① 意味が共有される
仕事のWhyが言葉になり、全体の文脈が見えるようになります。
② 役割と責任が見える
誰が何に責任を持つのかが明確になり、人を巻き込みやすくなります。
③ 振り返りが可能になる
結果として、経験が個人に閉じず、組織の学びとして残ります。
プロジェクト化の一歩目はキックオフ
プロジェクト化というと、大げさな企画書や管理を想像するかも知れないが、最初の一歩はもっとシンプルで、「キックオフ」をすると良いと思う。
キックオフは単なる開始ミーティングではない。センスメイキング理論の言葉で言えば、キックオフは「意味づけの起点」をつくる行為と言える。
キックオフの最低限セット
・なぜ、何を目指してこれをやるのか（Purpose / Concept）
・誰が何にどこまで責任を持つのか（Role & Responsibility）
・いつまでに何をして、いつどうやって振り返るのか（Milestone）
この3点を言葉にするだけで、タスクはプロジェクトとして立ち上がりやすくなると思っている。
なお、この3点は「最初から正解である必要はない」。むしろ、仮で置いて、途中で更新できるようにしておくことが重要だと経験的に感じている。
おわりに
タスクが増えること自体は、組織が動いている証拠であろう。
しかし、プロジェクトが設計されないままだったり、プロジェクトなくタスクだけが回っている状態だと頑張りは消耗に変わりやすい。
忙しさは、成果の代理指標にならない。
「いまやっているこの仕事は、プロジェクトだろうか？」
「プロジェクト化できないだろうか？」
例えば（仕事じゃないけれど）今書いているこのnoteは何なんだろう、とか考えてみる。
どんなことでも良いから、やっているタスクを1つプロジェクトにしてみるだけで、見える世界が変わる、と言っても大げさじゃないと思っている。
もし今、ToDoリストを消していくことに疲れを感じているなら、その中のたった一つでいいから、小さな「キックオフ」をしてみてください！
※本稿でいう「プロジェクト」は、PMBOK的な管理単位というより、Outcome（状態変化）を単位に仕事を構造化するという意味に近い。
