Webシステムの開発見積
Webシステムの開発見積もりは、プロジェクトの成否を分ける最も重要なプロセスです。
コーディングだけでなく、プロジェクト管理、テスト、リリース対応など、すべての作業を網羅し、現実的な数値を導き出す必要があります。
一番最初にやらなければいけない作業なのに受注額が決まってしまうので、全てがここにかかっているといっても過言ではありません。
見積時と終了時に全く乖離がないなんてことは100％ないです。
では、どうやったら精度が高く、乖離の少ない見積ができるようになるのか？
今回はあくまで個人的な私見として、見積もりの具体的な進め方から、よくある落とし穴、そして最終的な精度を左右する「経験則」の養い方までを記載していきます。
全作業を洗い出す
精度の高い見積もりは、徹底したタスクの細分化から始まります。
- 要件と前提条件の定義: 何を作り、何を作らないかを明確にする。あいまいだと後で揉めます
- 各工程の作成: プロジェクトを工程（要件定義、設計、実装、テスト、リリース等）に分け、さらに具体的なタスクへと分解します。この工程での漏れというのは後々響いてきます
- 各タスクの工数算出: タスクごとの所要時間を算出します。技法はいろいろあるのですが・・・
- バッファの追加: 不確実性や潜在的なリスクを考慮し、全体の工数にバッファ（例：全体の10〜20%）を上乗せします。ここは営業面での兼ね合いもありますが開発としても譲れない部分です。
見落とし厳禁！開発以外の必須タスク
見積もりにおいて、特に抜け漏れ、工数ズレが発生しやすいのは下記で注意が必要です。
- プロジェクト管理（PM/PMO）工数: 進捗管理、課題管理、週次定例会議、顧客報告資料の作成など。意外とかかります。PMの仕事は全てここにかかる＋αになり工数的に少なくなりがちです。対人間は意外とかかります。
- 環境構築工数: 開発・検証・本番環境（AWS等のインフラ含む）の構築。実際の経験によって大きく変わってきます
- テスト関連工数: 単体・結合テストだけでなく、テストデータ作成、顧客の受入テスト、サポート工数など。テストがうまくいくとかからないのですが、100％問題ないテストはありえません。修正や不具合といったところも想定しないと痛い目をみます
- リリース対応・移行工数: 本番移行リハーサル、データ移行手順の作成。リリース工数もしっかり準備すると以外とかかります。
2苦労するところ・落とし穴
現場で見積もりを行う際、以下のような壁にぶつかることが多々あります。
- 「要件の曖昧さ」という魔物: 顧客からの要件がフワッとしている段階で見積もりを求められるケース。後から「これもできると思っていた」と仕様が膨張（スコープクリープ）し、工数が大爆発します。成果物のビジョンを共有できるように進めましょう
- トラブル対応: 全てが計画通りに進む前提で見積もってしまうのもよくないです。APIの仕様変更や、環境のアップデート、既存システムの思わぬレガシーコードへの対処など、イレギュラーな事態への考慮が欠けていると炎上につながります。
- コミュニケーションコストの過小評価: 顧客との合意形成にかかる時間や、開発チーム内の認識合わせにかかる時間が想像以上に膨らむことがあります。
経験に勝るものなし！日常業務で意識すべきこと
FP法や係数見積もり、プランニングポーカー等ありますが、どんなに優れた技法や正確なWBSを用いても、最終的な見積もりの精度は「見積もる人の経験」に大きく依存します。勘と経験は最強です。不確実性の高いITプロジェクトにおいて、肌感覚としての「このタスクは何か落とし穴がありそうだな」という嗅覚は一朝一夕では身につかないです。
経験を磨き、見積もり精度を向上させるために、日常業務で以下のことを意識してみてください。
徹底した「予実管理（見積もりと実績の乖離分析）」
最も重要なのは、自分が「3時間で終わる」と見積もったタスクが、実際に何時間かかったかを毎日記録することです。もし5時間かかったなら、「なぜ2時間オーバーしたのか（仕様の勘違い、環境トラブル、テストデータの準備不足など）」を分析し、次の見積もりの際の参考とします。
作業の「細分化」を癖づける
日常の小さなタスクでも「プログラミング」という大きな塊で捉えるのではなく、「設計15分」「実装30分」「テストコード作成15分」「レビュー修正15分」のように、頭の中でWBSを展開する癖をつけましょう。細分化できる＝作業の全体像が見えている証拠です。
過去のプロジェクトの「失敗（炎上）の歴史」から学ぶ
「前回なぜリリース作業で徹夜になったのか」「なぜPM工数が足りなくなったのか」を検討しましょう。他人の失敗体験も自分の経験則とすることで、リスク予見力が高まります。
他者の意見を参考にする
たとえ同じ開発言語を扱っていても開発者の考え方は様々です。いろんな人に意見を聞いたり、レビューしてもらって参考にしていきましょう。
おわりに
私自身、見積時点では自信があっても結果的に工数が膨らんでしまったり、採算が合わなくなってしまう失敗は何度もあります。正直数をこなしていく、という方法がベストかもしれません。それでも、いざ見積を作成する！という場合に学んだり検討するのではなく、常日頃から業務で意識して進めて見積勘というのを養っていくよう意識して取り組んでいった方がいいなという実感でした。
