ソフトウェア開発の工数見積もりは、多くの現場で悩まれるテーマです。
当然ながら、あくまで未来の作業量を予測するものなので、厳密な正解は存在しません。
しかし、だからこそ「どのように考え、どの視点で見積もるか」に、その人の技術観・経験・姿勢が表れます。
この記事では、弊社が普段どのように工数見積もりを構築しているかを、できる限り丁寧に言語化しました。
特に業務系アプリケーションの開発を行うエンジニアやプロジェクト担当者の方にとって、参考になる部分があれば幸いです。
全体像を立体的に描く
見積もりの第一歩は、顧客からのヒアリング内容をもとに、「プロダクト全体の構造を頭の中で立体的に組み立てること」から始まります。
たとえば業務系アプリの場合、データ構造と画面の種類は強く連動しています。
ひとつのマスターテーブルを扱う機能であれば、次のような画面が自然と必要になります。
- 一覧画面
- 新規作成画面
- 編集画面
- etc...
このように、データ構造をざっくりイメージすると、必要な画面群が自然と浮かんできます。
また、どのアプリでも避けて通れない共通機能があります。例に挙げると以下のようなものです。
- ログイン / ログアウト
- ロールや権限設定
- ログインユーザ管理
- パスワード変更
これらの機能は、個別機能に依らず必要される場合がほとんどなので、特別な要件がある場合を除いて最初から見積もりに組み込みます。
なお、機能を分割する際は、顧客側が理解しやすいよう、「画面単位」ではなく「画面のまとまりをひとつの機能」として扱うようにしています。
たとえば「商品管理機能」というような形で、一覧・登録・編集・検索などの小機能をひとまとまりとして扱うことで、イメージがしやすくなります。
画面を持たない処理（バッチ・バックグラウンド処理等）については、トリガーや処理内容を基準に“まとまり単位”で切り出し、機能として見積もります。
このように「実装するシステムの具体的なイメージを立体的に組み立てながら見積もりを検討する」ことが基本となります。
過去の経験からスケール感を推定する
工数を検討するにあたっては、「過去の似たような案件」と照らし合わせて、以下のような考察を実施します。
- 過去案件に、今回要求されているものと類似のものが存在するか
- 存在する場合、画面数や処理数はどのくらいか
- その時と比べて、設計や実装の複雑度は高いか低いか
- 外部連携はあるか
完全に同じ案件はありませんが、「似ている点」と「異なる点」を比較することで、規模感が掴めるようになります。
ただし注意が必要なのは、過去の案件の工数をそのまま横展開しないことです。
たとえば、機能の実現に使用するプロダクトAで実現できた機能が、プロダクトBでは単純に実現することができず、工数が大きく変わる可能性があります。
曖昧さを分割して理解する
見積もりを進めていると、「ここだけはどうしてもイメージできない」という部分が生じることがあります。
この曖昧さを放置すると、後半で大きな手戻りに発展するため、イメージできない部分は、まずその背景を丁寧に切り分けるようにしています。
理由として多いのは次のようなものです。
- 実装方式がわからない
- 顧客の説明が抽象的すぎる（背景・目的が曖昧）
- 作るべきものの仕様が明確でない
- 外部連携先（APIなど）の仕様が不明
- 制約的に実現可能か疑わしい
理由の切り分けができると、
- 調査すべき領域
- 再ヒアリングすべき箇所
- リスクとして扱うべき点
がより明確になります。
事前調査の見切り所を知る
事前調査においては、利用するプロダクトの公式ドキュメントなど、正確性の高い情報ソースを参考にします。
ネット上の情報（ブログ記事、Qiita、Stack Overflow など）についても、必要に応じて参考にしますが、情報の正確性には十分注意します。
これらの情報は不正確なことも多いため、正確性は十分に確認する必要があります。
小さく確認できそうな場合は、簡単な実装のプロトタイプを作ることもあります。
ただし、所要時間に対して見積もりの精度が上がらないことも想定されるため、あくまで最小限の確認に留まる場合に限定しています。
これらの調査を進めても不確実性が解消されない場合は、事前検証フェーズなどの、実装前にリスクポイントを明らかにする工程を追加するなどの工夫が必要となります。
コミュニケーション起因の不確実性を見抜く
工数は技術だけで決まるものではありません。顧客側の説明の精度・コミュニケーションの特性・要件の固まり具合も工数に大きく影響します。
例えば次のような場合、不確実性が高いと判断できるかと思います。
- 願望レベルのざっくりとした要望しか出てこない
- 説明が毎回少しずつ変わる
- 極端な短納期・低予算を求められる
- 言葉遣いや前提条件が曖昧
これは単なる「嫌な予感」ではなく、過去の経験から積み重なった「リスクのシグナル」です。
こうした兆候がある場合には、仕様調整やコミュニケーションにかかる時間を見越して、見積もり工数にある程度のバッファを上乗せするのが安全です。
避けるべきアンチパターン
実務の中で、特に避けるべきだと感じている見積もりのアンチパターンがあります。
バッファを設けない
最善のケースのみを想定した見積もりではなく、潜在的なリスクについて常に意識をしておく。
過去案件の工数をそのまま横展開
技術的背景が違えば工数も変わるため、安易な横展開は避ける。
機能の粒度が大きすぎる
「管理機能まとめて30人日」のように、 ひとつの機能の粒度が大きすぎる場合、大機能を分割して複数の小機能と扱ったほうが、精度面および管理面に優れる。
前提条件を明示しない
前提条件は、正確な見積もりのベースとなる重要事項のため、見積もりの提示に際しては決して曖昧にしない。
まとめ
より正確な見積もりを作成するためには、以下のものが必要になると考えています。
- 要件から構造を描く力
- 過去の案件のスケール感を参照する力
- わからない理由を切り分ける力
- 必要な深さで調査する力
- 顧客の言動から不確実性を察知する力
- 危険な見積もりパターンを避ける判断力
この記事で触れた、見積もりや技術判断の考え方は、日々の開発プロジェクトでも役に立つものばかりです。
弊社では、企業の技術的な意思決定やプロジェクト運営を継続的に支援する「レンタルCTOサービス」を提供しています。
「技術の相談役がいつでもそばにいる状態」をつくりたい企業担当者の方がいらっしゃれば、ぜひ一度サービス内容をご覧ください。
