仕事術の分野では一般的かつ基本的な考え方であり、そこにメリットがあることは間違いないでしょう。
概略としては、「次は何を、どのようにしようか」を考えるコストは意外と大きいため、それを予め決定しておくことでそのタスクに取り掛かりやすくする、といったところでしょうか。
よくある例を出しておくと、
- プレゼン用スライド作成
を
- 資料を読む
- 過去に使用したスライドを見る
- アウトラインの作成
- 細部の作成
- デザインの調整
に分解しておくことです。
こうすることで、悩むことなく行動を開始でき、全体として所要時間を短縮できるのです。
（「所要時間の短縮」以外にもメリットは考えられますが、それは別の機会にします）
「悩むことなく行動を開始」？
上にも書きましたが、ここまでの議論はとても一般的なもので、誤りはないはずです。
そうだとすると、少し気づくことがあります。
いま、順序としては、
- タスクを分解する
- 悩むことなく行動を開始できる
- 全体の所要時間を短縮できる
ここから、「タスクを分解」の作業が直接「全体の所要時間短縮」をもたらしているわけではないことが言えます。間に「行動を開始できる」が挟まれて、初めてそうなるのです。
更に言えば、元々存在しなかった「タスクを分解する」作業が追加されているため、ここだけ見れば全体の作業時間は増加してしまいます。
「行動を」分解する
それでは「タスクを分解」は何をもたらしているのでしょうか。言いかえれば、それは何を行っているのでしょうか。
それは、人間の行動を分解しています。
「タスクを分解」することが、「次どうしようかな」と悩む時間（分解したタスクをスケジューリングすることとはまた別の話です）をくくり出して、先頭に持ってきてくれます。
そして、悩む時間は悩む時間、タスク実行の時間は実行の時間、に集中して取り組むことが可能になり、全体の所要時間を短縮させられるのです。
繰り返すと、「タスクを分解」しただけでは、タスクが減ったわけではありませんので、全体の所要時間は何も変わっていません。
そこに内在していて見えなかった、「悩む時間」をいつの間にか取り出してきて（これを「行動を分解する」と呼びました）、消滅させています。
「いつの間にか」取り出している
ここで重要なのは、「いつの間にか」内在していた悩む時間を取り出せていることです。
「タスクを分解」している最中には、「行動を分解しよう」とか「悩む時間を取り出そう」などと、人間の方を見ているわけではありません。
あくまで、「このプロジェクトは順にこんな作業をしていく必要があるな」と、プロジェクトの方に視点が向いています。
これは非常に優れたアーキテクチャです。
私たちはインタフェースとしての「タスク分解」だけを行えば良く、「その内部で実際に何が行われているか」は全く知らなくて構わないのです。
そして、（実は）内部で「悩む時間がくくり出される」というアダプタが自然に生成され、結果作業時間が短縮されています。
実生活へのフィードバック
ここで行った考察から、しばしば問題となる「タスクをどのように、どこまで分解すべきか？」という疑問に、回答の指針くらいは示すことができたはずだと考えています。
それは、「十分に悩む時間が取り出せているかどうか」です。
……抽象的ですね。
要するに、このエントリにはっきりした結論はなかったということです。
ちなみに…
今回の考察は、前回エントリ時に、
- 読む時間とその他の時間を分ける
- iPod touchとiPhoneを分ける
ここだけの話ですが、途中でこのことに気づいてしまったせいで、前エントリ執筆時に落としどころがわからなくなりました。今読み返しても、何が言いたいエントリなのかよくわかりません。
で、実は今エントリも、予定していた流れとはまるで異なってしまいました。本当に書きたかったことは、別の機会にします。
何にせよ、文章を書くのは難しいのです。