前置き
仕事で楽観的な見積もりをしてしまい少々痛い目を見たとき、本書をオススメしている方がいたので、手に取ってみた。
全体で23章（500ページ程度）あるが、とくに最初の8章までが今の自分にとって学びになったので、気になった記述、思ったことをまとめる。
ちなみに発売日は2006/10/10で、18年前の本である。
ターゲットとコミットメント
まず大事な言葉として「ターゲット」と「コミットメント」の説明があった。
ターゲットとは実現したいビジネス上の目標を明文化したもの。これは達成可能なものとは限らない。
コミットメントとは定義された機能を特定の品質レベルを確保しながら、期日までに納品すると言う約束。コミットメントが見積もりより挑戦的だったり、保守的だったりすることもある。
「見積もりよろしく」と言われることがよくあるが、こういった場合は実際に見積もりを行うのか、あるいはターゲットの達成方法を尋ねられているのかを判断するのが大事だそう。
ソフトウェア見積もりの主目的は、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断すること。つまり、もしも現状のターゲットがあまりに非現実である場合、ビジネスとエンジニアリングの観点から適切なコミットメントを決めるための、1つの判断基準がソフトウェア見積もりなのだと理解した。
人は見積もり幅を狭くしてしまいがち
第2章には見積もりのクイズがあり、ここは面白かった。
見積もりの下限と上限の幅に限度は設けないという前提ではあっても、人は個人の勝手な思い込みにより見積もり幅を狭くするプレッシャーを感じ取り、見積もり幅を十分に取らないケースが多いという証明になるクイズであった。
実際に自分も上記の通りで、クイズに対して十分な正解数を得られなかった。
以下記述をこれから意識しようと思う。
見積もり幅を狭くするプレッシャーを感じたら、そのプレッシャーが自分の思い込みではなく、実際に存在するものかどうかを確かめよう。
実際にプレッシャーが存在する場合もあるが、その場合は22章、23章が参考になるみたいなので、実際の場面に遭遇したら読んでみることにする。
過小見積もりによる悲劇
過大見積もりとか過小見積もりのどちらがまだマシなのかという議論については色んな意見があるみたいだ。
過大見積もりの場合「パーキンソンの法則」や「学生症候群」が発動してしまう可能性を危惧する声もある。
過小見積もりの場合の危惧は以下の通り。
見積もりが少ない場合、要求や設計のような上流のアクティビティーにはほとんど時間を費やすことができない。設計や要求に対して充分注力しなければ、プロジェクトの後期になって要求や設計をやり直す羽目になるだろう。こうなると、最初の時点でこれらのアクティビティーを十分に行った場合と比べてより大きなコストがかかってしまう。
A Philosophy of Software Designという書籍でも、全体工数の10-20%を常に設計に充てて、小さな投資を繰り返し行うことで長期的に速度が出るという話があり、こちらの記事 でも内部品質を落とすことによる長期的なスピードの低下については触れられている。
また実体験としても見積もりが少なかった場合、プロジェクトの初期から焦り気味で設計の検査などがおざなりになり、後半になってスピードの急低下が起こることを感じている。
まさに本書の以下記述の通り、過小見積もりはデメリットのインパクトがより強いと感じた。
ソフトウェアにおいて課題見積もりの不利益は直線的で有限である。作業は使用可能な時間を使い尽くすまで拡大するだろう。しかしそれ以上は拡大しない。一方、過小見積もりの不利益は直線的でなく限界がない。計画の誤りや上流工程での手抜きによる多くの欠陥の作り込みは、課題、見積もりの場合よりも多くの損害を引き起こす。
プロジェクトが遅延状態に陥ると、余計なタスクがさらに増えるという例も書かれていた。 遅延状態になると、余計なタスクが増え、さらに遅れるという悪循環になるのだ。
例
- 開発速度を元の速さに戻す会議が行われる。
- 進捗状況についてより頻繁に上層部と擦り合わせる必要に迫られる。
- リリース日を決定するための再見積もりを要求される。
- 最初のリリース予定日に間に合わないことを、主要顧客へ謝罪する。
- 顧客の宣伝や展示会など特定の用途に使う暫定リリース版を用意する。
- どの機能が必須で、どの機能なら落とせるかの議論が多くなる。
18年前でもあるあるだったみたいだが、これ今でもあるあるなのでは...と感じた。
見積もりの不確実性
不確実性コーンの話が触れられていた。
プロジェクトの初期段階（規格や要件定義など）では、見積もりと実際のズレが大きくなりがちで、後半（設計、実装、テスト）になるにつれて、ズレが小さくなっていくという図である。
以下のような記述があり参考になった。
あらゆる見積もりには確率が含まれている。確率を明示した見積もりは良い見積もりと思って良い。
最良ケースと最悪ケースの見積もりを作成して起こり得るすべての範囲の結果について考えることも大事だが、出した見積もりに対してプロジェクトの現段階なども踏まえた上での実現確率も合わせてビジネス側に伝えるようなコミュニケーションが大事なのではと思った。
見積もりの方法
多くの場合、小規模プロジェクトで最適な見積もり技法はボトムアップ技法であると書かれていた。実際に作業を行う個々のメンバーが作成する見積もりをもとにして、プロジェクトの見積もりを作成する技法のことで、「大前提として可能な場合はいつでもまず数えよう」という筆者の原則に則ってこの主張があるみたいであった。
数えられないような場合（大規模プロジェクトであるとか）の場合にはじめて計算しよう。そして判断だけに頼るのは最後の手段とのこと。
また、もちろん過去のデータを元に見積もりを立てるのも、見積もりの精度向上には良いと書かれていた。
見積もりに使用する過去のデータを収集するときは、小さな規模で始め、自分が何を収集しているのか理解して、一貫性を持ってデータを収集しよう。プロジェクトが終わったら、できるだけ早くプロジェクトの過去のデータを収集しよう。
まとめ
18年も前からすでにあるあるだったミスを自分もやらかしてしまったこともあるし、色んな職場で現在も聞く話ではあるので、ソフトウェアプロジェクトの管理って改めて難しい分野なのかなと感じた。
実装段階になれば、今はかなりAIのサポートを活用してスムーズにコードを書くことができるが、開発観点を取り入れたビジネス上のターゲットの調整、コミットメントの決定、コミットメントを達成するために滞りなくプロジェクトを進めること、つまり人が絡むすべてのプロセスはまだまだ難しい分野だとつくづく感じたし、人の経験などが役立つ分野でもあるのかなと感じた。
AIはこの辺にどう絡んでくるんだろう？