タスクに具体化する

Table of contents

タスクに分解する

プロダクト開発においてなにか実現したいことがあるとして、それを仮にプロジェクトと呼ぶとする

そのプロジェクトを達成するためにタスクに分解して取り組みましょう、というのは一般的な手法だと思う

抽象的なプロジェクトを達成するために必要なことを、認識に齟齬が起きないレベルで自明で実行可能な状態にまで分解すると、それはタスク≒作業になる
分解されたタスクは、再現性があり、誰が実行しても期待した水準の結果が見込める
メリットは不確実性が減らせることと、人員によるスケールのしやすさを得られることだ

デメリットはあるだろうか?

“分解”というフレーズから連想するイメージ

タスクに分解すること自体は、プロジェクトの達成に強力に寄与すると思う
実際、私も日々の仕事はタスクに分解して取り組むことで捗る実感がある

ただ、私だけかもしれないが、分解をすると、分解された小さなタスクがそこにたくさん並んでいるようなイメージを持ってしまう
本来それらのタスクは全体のうちのひとつであって、タスク同士で関連性があるはずなのに

例えばそれを複数人で並行処理しようとしたとき、それぞれの担当者はそのタスクをひとつの独立したタスクとしてこなすつもりで作業するのではないだろうか
私自身その節がある

いや、それが目的で分解しているのだからなにも間違っていないのだが、経験則的にそれだとうまくいかないケースがあるのも事実だと思っている

タスクをこなすとはつまりどういうことか

目の前のタスクをこなすことは、誤解を恐れずにいえば肉体労働に近い
それがどれだけ知的な作業であれ、本質的にはリソースを結果に変換するという行為でしかない

しかし、大事なのは成果だ
今語られているコンテキストにおける成果は、“プロジェクトの達成”だ

つまりタスクをこなすことは、プロジェクトの達成に直接的に寄与していなければいけない

トートロジー的な言い回しに聞こえてしまうかもしれない
プロジェクトの達成のためにタスクに落とし込んで実行しているのだから、当然タスクをこなせばプロジェクトの達成に直接的に寄与するに決まっているだろう、と

しかし、ことはそんなに単純ではない(ことが多い)

タスクに落とし込む段階で、もれなく完璧なタスクへ分解できることは稀だ
それは、見通しが甘いなど単にスキル不足な面もあるだろうが、(度合いはあるとはいえ)未知なものをつくる以上、必然的に不確実性をはらんでいるからだ

つまり、そもそもそのタスクが間違った方向へプロジェクトを運ぶこともある、という前提に立つべきで、プロダクト開発に関わる身としてはそこに気付ける存在でありたい

フレーズの言い換えで脳をハック

ではどうするか?

このタスクをなぜやるか?に、答えられる状態で挑むのがよさそうだ
ただ、プロジェクトを進めるなかで状況は変化する
最新状況においてもそのタスクをやる意義があるかを問い続けなければいけない

そのようなマインドセットに持っていきやすいように、“タスクに分解する”のではなく”タスクに具体化する”と言い換えてみてはどうだろうか

私がいまからやろうとしていることは、プロジェクト達成の推進だが、それを具体的な行動に表現したものがこれらのタスクです、というように

ここでの狙いは、具体と抽象の行き来だ

タスクを、独立した作業の集合として捉えるのではなく、プロジェクトの達成という抽象的なことがらを現実世界で実現するための具体的な手段と捉えることで、常にプロジェクトとタスクをセットで考えるように促す
そう捉えると、プロジェクト達成という目的が視界に入りやすくなり、自ずとタスクがそれに見合うかを考えるようになるのでは?という仮説だ

また、タスクを具体化の手段と捉えるなら、それはプロジェクトと1:Nの関係になるはずだ
だから、タスクを独立した1タスクと捉えにくくなるという効果もありそうだと思う

というのを思いついたので、試してみようと思う