生産性を高めよう ブレイクダウン：先延ばしを克服する方法

『SOFT SKILLS』より　生産性を高めよう

大きいことが必ずしもよくないのはなぜか

　タスクは、大きければ大きいほど威圧的に見えるようになる。ソフトウェアアプリケーション全体を書くのは難しい。しかし、コードを１行書くのは簡単だ。ソフトウェア開発の分野では、タスクやプロジェクトは小さいものよりも大きいものの方が増えてきている。

　しかし、私たちはずっと先の将来を見通すことができないので、こういった大きなタスク、プロジェクトは、私たちの生産性を低下させがちである。大きなタスクを全体として見てしまうと、ほとんど実現不可能なもののように見えてしまう。摩天楼や数kmも続く橋を構築するという、とてっもなく大きな仕事について考えてみよう。多くの摩天楼や橋が建築されてきたので、実現可能なことはわかっている。にもかかわらず、この種のプロジェクトを全体の形で見ると、誰もそんなことは実現できないように感じてしまう。

　私は、長年に渡ってゼロからアプリケーションを構築するような巨大プロジェクトに関わってきた。私は様々なアプリケーションを手がけたが、物事をブレイクダウンすることを学ぶまでは、どれひとつとして完成にたどり着けなかった。いつも最初はプロジェクトに情熱を注いでいるのに、すぐに細部に埋没しているような感じになった。私は、あとどれだけの仕事が残されているかを考えることに囚われていて、完成地点まで作り上げることができなかった。プロジェクトが大きければ大きいほど、失敗する傾向があったのだ。

　しかし、同じ問題を抱えるのは私だけではないようだ。ソフトウェア開発分野の様々な職務のなかでほかの開発者に仕事を任せてきたが、決まって夕スクの大きさがプロジェクトの成否の大きな指標になることを感じたのである。任せるタスクが大きければ大きいほど、彼らがそのタスクをこなせなくなる可能性が高くなるのだ。

　なぜこうなるかの理由のひとつはすでに述べた。大きなタスクの心理的な負担である。大きな問題に直面すると、私たちは問題解決の手順を進めることより、問題そのものについて考えることのために時間を費やしてしまう傾向がある。人は、もっとも抵抗の低い道を選ぶ傾向にある。大きなタスクに直面すると、ほとんど必ずメールをチェックしたり、コーヒーをもう一杯飲んだりすることの方が楽そうに見えてしまい、先延ばしが起きてしまう。

　しかし、大きなタスクがよくない理由は、先延ばしが起きることだけではない。タスクが大きければ大きいほど、しっかりと定義されていない傾向がある。店に行って卵、牛乳、パンを買ってきてほしいと頼む場合、タスクは明確に定義されており、あなたは何をすべきか正確にわかる。そのような夕スクは簡単に実行でき、あなたが正しくミッションをクリアする可能性は高い。

　それに対し、私のためにウェブサイトを作ってくれと頼むと、このタスクは先はどの例よりも相当大きい上に定義が明確でない。どこから始めるのかなど、答えられていない疑問がたくさんある。仕事を完成させるために何をしたらいいかが正確にわかる可能性は低い。私にとってウェブサイトの作成とは正確にどういう意昧なのか、私が何を期待しているのかの説明を書くことはできるが、そこまで詳しく説明すると、読んで理解するために時間がかかるし、エラーが起きる可能性が非常に高くなる。

　大きなタスクは、見積もりも非常に難しくなることが多い。リストのなかからもっとも大きい要素を見つけるアルゴリズムを書くためにどれくらいかかるかと尋ねられれば、たいていの人がかなり正確な見積もりを出せるだろう。しかし、ウェブサイトのショッピングカート機能を実装するためにどれくらい時間がかかるかと尋ねられても、出せる見積もりはほとんど当てずっぽうになってしまうはずだ。

　つまり、大きなタスクは小さなタスクと比べて精神的に負担になり、日程が遅れがちになり、一般に説明が曖昧になってエラーが起きやすく見積もりが難しくなる。

ブレイクダウンの効用

　しかし、希望を失ってはならない。解決方法はある。大きなタスクのほとんどは、小さなタスクに分解できることがわかっている。実際、ほぼすべての大きなタスクは、ほとんど無限ともいえる個数の簡単で小さなタスクに分解できるのである。

　大きなタスクを小さなタスクに分割することは、できる仕事量を増やすとともに、自分か仕事をしたときにかかる時間をより正確に見積もるために、私がいつも使っている常套手段のひとつである。

　実際、この本の構成との一致は偶然ではない。読者は、この本にはなぜ、こんなにたくさんの章があるのだろうと思われたかもしれない。本書の執筆に取り掛かったとき、少数の大きな章を書くのではなく、多くの小さな章を書き、それをいくつかの部にまとめるという方法を意図的に選んだ。これにはふたつの理由がある。

　まず第１に、この方が、読者が内容を消化しやすいだろうということである。私の場合、長い章を含む本は、章全体を読むだけの時間がない限り、取り出して読むのを避ける傾向がある。長い章を持つ本は、そうでない本よりも威圧感があるので、私はそうならないようにした。読者から見ても、千から二千ワードの章の方が､細かく分けられていない大きな章を持つ本よりも、読みやすく、威圧的に感じないのではないだろうか。

　第２に、この方が私にとって楽だからだ。私は、ほとんどの人がデスクの前に座って本を書き始めたものの、書き上げられないで終わることを知っている。私も何度か自分で本を書こうとして完成させられなかった経験がある。各章を長いブログポストくらいの小さなものにしておけば、本を書くという仕事は、はるかに管理しやすくなる。大作を書くというひとつの大きなタスクではなく、小さな章を書くという80個程度の小さなタスクに立ち向かうことにしたのである。

　タスクを小さく分割するとき、それらのタスクは取り組みやすくなり、夕スクを終わらせるために必要な時間の見積もりはずっと正確になり、正しく仕事ができる可能性が高くなる。小さなタスクで仕事を間違えても、大きなプロジェクトに深入りしたり取り掛かったりする前に修正するチャンスが見つかることが多い。私は、ほとんどの場合で、大きなタスクを小さなタスクに分割するのは正しいと考えるようになった。

どのようにして分解するか

　大きなものを分解するのはそれほど難しいことではない。ほとんどのタスクにに度に１ステップずつ進むようにすれば、簡単に小さなタスクに分解できる。象の食べ方の引用は、まさに真実だ。象を食べられる方法があるとすれば、一口ずつ食べること以外に考えられない。ほとんどすべての大規模な仕事でも同じことが当てはまる。大きなタスクを意図的に分割しなかったとしても、線形に進む時間の制約を受ける。あることを終わらせなければ、ほかのことを終わらせられない。それが延々と続くのである。

　大きなタスクがあるときに、その威圧感を抑えたいなら、まずそのタスクを完成させるために、どのようなステップを踏んでいかなければならないかを明らかにする必要がある。大きなタスクを任されたとき、私がまずしてみることは、タスクを小さい連続的な部品に分解できるかどうかを明らかにすることだ。

　最近、クライアントが持つ継続的インテグレーションシステムとデプロイの手順をクライアントのコードににとって有効なものにするというプロジェクトに取り組んだ。これはとても大きなタスクだった。当初、このタスクは圧倒的で、難しく感じたが、頭からぶつかっていくのではなく、タスクを小さなタスクに分割するところから始めた。

　最初は、コマンドラインからそのコードをビルド、コンパイルすることから始めることにした。自動ビルドを作るためには、まずこの作業が必要なのである。次のタスクとしては、ビルドサーバーにコードをチェックアウトできるようにすることが妥当なところだ。すると、ふたつのタスクを結合する新しいタスクを作れる。つまり、ビルドサーバーにコードをチェックアウトして、コマンドラインスクリプトでコードをコンパイルするというものである。

　私は、このような形でプロジェクト全体を小さなタスクに分解していった。すると、とても太刀打ちできない猛獣が小さなネズミのように見えてきた。プロジェクト全体は非常に難しい問題のように見えたが、個々の小さなタスクはばかばかしいほど単純に見えたのである。

　大きなタスクを多数の小さなタスクに分割しようとすると、自分に何をしてほしいのかについての十分かつ正確な情報が与えられていないことがわかる。大きなタスクは小さなタスクよりもしっかりと定義されていないという指摘を思い出そう。小さくて明快に定義されたタスクを作るのを防いでいる情報の欠如を明らかにすることは、大きなタスクを小さなタスクに分割するときのきわめて重要なステップのひとっだ。大きなタスクを小さなタスクに分割するために苦労しているなら、それは情報の欠如によるものかもしれない。

　しかし、これは悪いことではない。情報が足りないことがプロジェクトを始めてかなりしてからわかるくらいなら、プロジェクトの初期の段階でわかる方がはるかにいい。大きなタスクを小さなタスクに分割するときには、小さなタスクが明確な目標を持つようにしよう。そのような目標を明らかにしようとすると、本来なら、なければならない重要な情報が足りないことが明らかになることがよくある。

　アジャイルチームで仕事をするときには、私はこのテクニックを使って顧客から適切な情報を引き出そうとすることが多い。顧客は、サイトにショッピングカートを追加するなどの大きなタスクを依頼するときに、自分が望んでいることをあなたに正確に言えない場合がある。しかし、あなたが大きなタスクを小さなタスクに分割できるなら、彼らがしたいことをあなたに伝えやすくなるようにすることができる。

分解の問題点

　ブレイクダウン：分解というアプローチは、コードや問題解決にも直接応用できる。新人開発者の多くは、書くのが難しいコードとか解決するのが難しい問題と感じてしまうものを解決しようとして､問題に圧倒されてしまう。それは一度に解こうとするには大きすぎる問題にぶつかっていってしまうからだ。彼らは分解の方法を知らないのである（私自身、まだたびたびそうなるという点では同じだということを認めなければならない）。

　私たちは、自分が書くコードの複雑さを管理するために、自然のうちに分解というアプローチを部分的に行っている。私たちがすべてのコードを収めたひとつの巨大なメソッドを書かないのはそのためだ。私たちは、自分のコードをメソッド、関数、変数、クラスなどの構造に分解して、コードを単純にしている。

　プログラミングするために与えられた課題は、いかに複雑でも、必ず小さな部品に分解していくことができる。複雑なアルゴリズムを書こうとしている場合には、しゃにむに前進してコードを書こうとするより、独立に逐次的に解決できる小さな部品に問題を分割するといい。アプリケーションがいかに大きくて複雑でも､必ずコード行に煮詰めることができる。1行のコードは、どんなプログラマでも理解でき､書くことができる複雑度を決して越えない。だから、問題を十分細かく分解するつもりがあれば、わずか１行のコードを書くだけの能力だけでどんなアプリケーションだって書けるのである。