はじめまして、モンスター・ラボ、テクノロジーグループの山口です。
Linuxサーバによるインフラ構築から、
フレームワークを使ったPHPによるサーバサイド開発などメインに担当しています。
最近、自分の参画する開発プロジェクトの規模が大きくなってきたこともあり、
技術だけでなく、プロジェクトの管理や開発プロセスを学習することにも関心が高まってきました。
今日は、その第一弾としてソフトウェアの見積りについて書いてみようと思います。
スティーブ・マコネル著「ソフトウェア見積り」という本が参考書です。
興味のあるかたは、是非、読んでみてください。
■見積りは何のためにするのか
「このプロジェクトの所要期間は14週間である」といったとき、
この見積りはどのくらい確かなのでしょうか？
実はこのように単純に単一の期日を提示した見積りは、
意味がないと著者のマコネルさんは言います。
なぜなら、確率が考慮されていないから。
確かにこの14週間は、どの位の確率で実現可能なのか、背景となる情報もないため、
「これは単なる目標なのではないか？」と実現性に不安を感じてしまいます。
例えば、下のように確率を明示した見積もりは、良い見積もりと言えるとのこと。
「24週間のスケジュールで完了する確度は90%」
「最良で18週間、最悪で24週間」
まず、初期の見積もりではターゲット（ビジネス上の目標）と見積りに
どのくらいギャップがあるのか把握することが肝心です。
※見積り名言１
「ソフトウェアの見積もりの主目的は、プロジェクトの結果を予言することではない。
見積もりを行うのは、プロジェクトのターゲットがコントロールによって
達成可能な程度に現実的なものかどうかを判断するためである」
■見積りはいつ明確になるのか
では、確率を考慮した幅のある見積りというのは、
いつ明確な見積りに収束していくのでしょうか？
不確実性のコーンという、面白い図があります。
プロジェクトの最初に行った見積りは不確定要素が多いため大きな誤差がありますが、
プロジェクトが進むにつれて、ばらつきがなくなっていきます。
詳細設計が完了するころには、確度の高い見積りが可能になっています。
再見積りによってプロジェクトの見通しが明確になってくれば、
計画に有益な新しい情報が得られるはずです。
再見積りの計画を前もって関係者に伝えられるのがベストですね。
■過小見積りと過大見積りはどちらがよいか
「意図的に過小見積りをしてはいけない」この教訓は大事です。
○過小見積もりで発生する問題
・実際に必要な人数より小さなチームにしてしまい、必要な準備がまにあわないことが続出
・予定どおりに完了する機会が減少
・要求定義や設計のような上流工程に費やす時間が不足
・「遅延」状態に陥ると、「予定どおり」に行われている間には必要なかった活動が大量に発生（打合せや関係者への説明、議論など）
過大見積もりで余裕ができると、メンバーが怠けてしまうのではないかと心配するかもしれませんが、それよりも、過小見積もりで発生する問題の方がはるかに深刻です。
■見積りに見落とされがちなもの
見積りはできる限り判断に頼らず、「数える」「計算する」ことを重視べきですが、
数え上げるときに、見落としがちなものを参考までにあげておきます。
○機能要求
セットアップ/インストールプログラム、データ変換ユーティリティ、ヘルプ
○非機能要求
セキュリティ、ユーザビリティ、再利用性
○ソフトウェア開発アクティビティ
新しいチームメンバーの指導、マネージャミーティング、テストデータの作成、パフォーマンスのチューニング
○その他
休暇、トレーニング、週末、全社ミーティング
などなど
■最後に
見積りというのは、
詳細なスケジュールを作成し、機能の優先順位付けを行い、クリティカルパスを特定するなど
現実的なプロジェクトの計画を立てるための根拠となる、最も有益な情報の一つだと考えています。
まだまだ、開発プロセスについて勉強中ですが
今後、「うまくいく見積りフロー」を作っていくための
参考になれば幸いです。