アジャイルな見積りと計画づくり：第1部：問題とゴール「２章 なぜ計画づくりに失敗するのか」まとめ
個人的まとめ
プログラミングを始めた頃に「顧客の価値は何か？」という問に対する意識をどのくらいしただろうか？与えられたタスクをこなし、それで満足していた頃があったのを思い出す。それが本当に価値があるものかどうかを知ることもなく。これはとっても怖いことだ。本当の価値とは何か？と言われると困るが、少なくとも顧客が喜ぶものでないといけない、何かを作り終えて、顧客が嫌な顔をしても、「言われたことをこなしたじゃないか」という文句では、プロジェクトの成功とは言えない。単なる作業ではなく「顧客・ユーザーが喜ぶ良いものを作ろう」と意識しないといけない。仕事とは他人のためにやることだ。それはプロフェッショナルとしての基本なのだけど、日々の忙しさもあって、つい忘れてしまうのではないだろうか。仕事とは他の人に役に立ってこそ仕事なのである。これを肝に銘じよう。
目次
- なぜ計画づくりに失敗するのか
- フィーチャではなく作業を計画している
- 作業は早く終わらない
- スケジュールの遅れは先へと伝わる
- 作業は独立していない
- マルチタスク化が遅れを助長する
- 優先順位の順にフィーチャを開発していない
- 不確実性を無視している
- 見積りがコミットメントになっている
- まとめ
- 個人的まとめ
なぜ計画づくりに失敗するのか
- 従来のプロジェクト計画手法にはがっかりさせられることが多い。新規プロダクトのスコープ、スケジュール、リソースのすべてに回答しようにも、従来の計画策定プロセスでは満足のいく回答はまず得られない。したがって、満足のいくプロダクトも得られない。それは次の言葉からも明らかだ
- プロジェクトの3分の2近くは、コスト見積りを大幅に超過する
- プロダクトのフィーチャの64%は、めったに、あるいはまったく利用されない
- 平均的なプロジェクトは予定スケジュールの2倍以上かかる
フィーチャではなく作業を計画している
- 従来の計画策定の考え方では、作業の完了を基準にしており、フィーチャの提供はあまり重視されていない
- 従来の手法でマネジメントされているプロジェクトでは、ガントチャートやWBS(Work Breakdown Structure)で作業を管理する
- 作業がチームの進捗の測定基準になる
- 顧客からすれば作業の完了にはなんの価値もない
- 顧客にとっての価値の単位はフィーチャだ。計画づくりでは、作業ではなくフィーチャを単位にすべきなのである
- 作業を基準にしたスケジュールをレビューしていると、レビューの視点も作業が基準になってしまう。すなわち、足りないフィーチャを探そうとするのではなく、足りない作業を見つけようとしてしまうのだ
- 作業を基準にした計画は遅延しやすい。そこでさらに問題が起きる。スケジュールから遅れそうになると、チームによっては品質を下げてまで時間を節約しようとすることがある。あるいは、プロダクトへの変更を制限するような変更管理手順を導入するチームも出てくる。その変更が極めて高い価値を実現するものであったとしてもだ
- 作業を基準にした計画がスケジュール遅延を招きがちなのには、いくつか理由がある
- 作業は早く終わらない
- スケジュールの遅れは先へと伝わる
- 作業は独立していない
作業は早く終わらない
スケジュールの遅れは先へと伝わる
- 従来型の計画は作業を基準としているので、計画全体が作業間の依存関係を重視したものとなる
- テストに着手するのを早めようと思ったら、次のような幸運が偶然続かねばならない
- ビジネスロジックの実装が早く終わること。そのためには、データベーステーブルの追加も早く終わっていなければならない
- ユーザインターフェースの実装が早く終わること
- テスト要員を早めに確保できること
- ここでのポイントは、このような単純な例であっても、３つすべてが首尾よく運んではじめて、テストを早く開始できるということだ。１つでも上手くいかなかった場合には、テストの開始が遅れてしまう
- 私たちは、作業が早く終わることがめったにないことを知っている。作業が早く終わらないということは、常に作業の着手が遅れていくということであり、さらにその遅れはスケジュールの先へと伝わっていくことになる
作業は独立していない
- 「作業が独立している」とは、ある作業の所要時間が他の作業の所要時間には影響しないということだ
- ソフトウエア開発の作業は独立しているだろうか？残念ながらそうではない。ソフトウエア開発作業の多くは他の作業から独立してはいない。たとえば、アプリケーションのクライアントを実装しているとしよう。もし最初の画面でスケジュールを50%超過したとしたら、残っている画面のそれぞれでも余分に時間がかかる可能性が高い。開発に必要な作業が独立していないのなら、遅れた分を相殺することはできない
- 典型的なプロジェクトの多くの作業は独立していない。しかし私たちはそのことを忘れがちである
- 最初の１つ目で作業が遅れてしまうと、「確かに今回は遅れてしまったけれども、次で挽回するよ」と言うことがよくある。このような発言の根拠は、初回の作業で得られた知識を活かせば、同じような作業なら次回以降では効率を改善して、計画よりも早く完了できる、という思い込みにある
- こうした状況から私たちが本当に学ぶべき教訓は、ある作業が予定よりも長くかかったら、それと類似の他の作業も同様に予定よりも長くかかるということだ
マルチタスク化が遅れを助長する
- 従来型の計画づくりがうまくいかない次の理由は、マルチタスク化である
- マルチタスク化は生産性に甚大な悪影響を与える
- クラークとウィールライトによるマルチタスク化の研究で、個人が3つ以上の作業を並行して進めると、価値を生み出す作業に使える時間が大幅に減少することがわかった
- 2つの作業を並行に進めると効率が上がるのは筋の通る話だ。片方の作業が進められなくなったときに、もう片方の作業に切り替えることが出来るからだ。同時に2つ以上の作業が進められなくなってしまうことはまれなので、3つ以上の作業を同時に進めると、作業の切り替えにかかる時間の増加が目立ち、無視できないほどの負荷となってしまう
- マルチタスク化の問題がプロジェクトで顕在化するのは、複数の作業に遅れがではじめてからである。複数の作業が遅れると、作業間の依存関係が深刻な問題となる
- 以下の図は、マルチタスク化によって作業期間が長くなり、完了日が遅れる例。マルチタスク化せずに順番に取り組んでいれば、10日間ずつで済んでいたはずだ
- さらに事態を悪化させるのは、上の図では私の作業が切替えても生産性がオチないと仮定している点だ。実際には作業の切り替えは生産性を低下させる
- マルチタスク化が従来のプロジェクト計画で問題になるのは、主に２つの理由による
- １点目は、作業を割り振るのが実際に着手するよりもずっと前であり、その時点では効果的な作業分担が出来ない点だ。作業をグループではなく、個人に割り当てていることも問題をさらに深刻にしている
- ２点目は、プロジェクトメンバー個々人の稼働率を高めることを重視しがちなことだ
- 個々人の稼働率を高めることばかりに気を向けていると、プロジェクトの通常の作業において避けられない変動に対処するためのゆとり（slack）を用意できなくなってしまう。メンバー全員に許容量の100%まで負荷をかけると、高速道路に許容量の100%まで車を詰め込むのと同じ結果になる。つまり、誰ひとりとしてまったく先に進めなくなるのだ
優先順位の順にフィーチャを開発していない
- 計画に作業を記述するときに、ユーザーや顧客にとっての価値による優先順位付けをしていないからだ。従来型の計画の多くが、計画にあるすべての作業を完了させることを前提にしている。そのため、開発チームに都合の良いように優先順位と作業順序が決められることになる
- 従来型の考え方では、作業がすべて完了するのであれば、こなしていく順序を顧客は気にしないものとされている。これによって顧客の視点からは、開発チームがフィーチャを開発する順序はでたらめに見える。そしてプロジェクトの納期が近づいてくると、チームはスケジュールになとしても間に合わせるために、フィーチャを削ってしまう
不確実性を無視している
- 従来型計画づくりの第4の欠点は、不確実性を無視している点だ
- 初期の要求分析において、完璧で漏れのないプロダクト仕様を策定できることを前提にしている
- ユーザの気が変わらないと決め込んでいる
- 彼らは考えを改めることもなければ、計画が対象としている期間中に新しい要望が発生することもない、そう想定しているのだ
- プロジェクトの初期段階では、不確実性の最大である。であれば、この段階の見積りにも不確実性が反映されるべきだ
- 不確実性に対処していく最善の方法は、繰り返すことだ。プロダクトがどうあるべきかという不確実性を低減させるには、短いイテレーションで作業すると良い
見積りがコミットメントになっている
- そもそも見積りというのは、見積もった時間内に作業が完了する確率のことである
- 従来型の計画づくりの問題点は、プロジェクトのチームやステークホルダーが見積りをコミットメントと捉えてしまうことだ
- フィリップ・アーマーが指摘するように、見積りは確率だが、コミットメントは確率ではない。
- いかなる見積りも暗黙のコミットメントになってはならない
まとめ
- 作業を基準にした計画はフィーチャを軽視することにつながるが、フィーチャこそが顧客にとっての価値なのだ
- ユーザが最終的に何を求めるかには不確実性があり、はっきりとはわからない。この事実を無視すると、プロジェクトとしては期日を守れたとしても、ユーザーにとって本当に重要なフィーチャを取りこぼしてしまいかねない。というのも、計画を立てたあとで明らかになった重要なフィーチャを反映させられないからだ
