LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

工数見積り技法の種類と使い分け

工数見積り技法とは、システム開発の作業量や期間を数値化するための算出方法を指します。代表的な技法には、ファンクションポイント法(FP法)・類推見積り・COCOMO^*1などの係数モデル・ボトムアップ見積り・プランニングポーカーがあり、それぞれ算出の根拠と精度が異なります。

技法の選び方は開発の進行段階によって変わります。企画段階では要求が固まっていないため、類推見積りや係数モデルのように少ない情報から概算できる技法が向いています。設計がある程度固まった段階では、FP法のように機能を定量化する技法や、作業を分解して積み上げるボトムアップ見積りが精度を高めやすくなります。アジャイル開発ではスプリントごとにプランニングポーカーで相対見積りを重ね、実績データを積み上げていく方法が一般的です。

本記事では、これらの技法そのものの仕組みと精度を上げる考え方を整理します。発注側が相見積もりを取る進め方や比較の仕方ではなく、見積りの精度をどう高めるかに焦点を当てます。

ファンクションポイント法(FP法)が積み上げ型で精度を出す仕組み

ファンクションポイント法(FP法)とは、ソフトウェアが持つ機能を入力・出力・照会・内部ファイル・外部インタフェースなどの種類ごとに数え上げ、複雑さの度合いで補正して規模を点数化する見積り技法を指します。国際ファンクションポイント利用者グループ(IFPUG)は、Function Point Analysis(FPA)を含む複数の規模測定手法を統治する団体として、認定資格制度や標準の整備を行っています^*2。

FP法の特徴は、コード行数や開発者の感覚に依存せず、要求定義の時点で確認できる「機能の数」を根拠にする点です。IPAが公開する「ソフトウェア開発分析データ集2022」は、企業のシステム開発プロジェクトから収集した定量データをもとに、FP規模と工数の関係を分析した資料です^*3。この白書に基づく分析では、FP規模と工数の間には近似的な相関関係があることが報告されており^*4、過去の類似案件データがない場合でも、公開されている生産性データを目安として使える点がFP法の実務的な利点とされています。

一方でFP法には手間もあります。機能を洗い出して分類し、複雑さを判定する作業には一定の習熟が必要です。要求定義がまだ粗い段階では、機能の数え漏れや重複がそのまま見積り誤差につながります。この手間を理由に、企画段階では簡易な類推見積りで概算を出し、要求が固まった段階でFP法による精緻化を行う、という段階的な使い分けが実務では取られています。

類推見積り・係数モデル・プランニングポーカーの位置づけ

類推見積りとは、過去に実施した類似プロジェクトの工数・期間・コストを参照し、規模や難易度の違いを補正して概算する技法です。参照できる類似案件が社内に蓄積されているほど精度が上がりますが、蓄積が乏しい組織では担当者の経験に依存しやすく、担当者間でブレが生じやすいという弱点があります。

係数モデルとは、開発規模やチームの特性などの変数を数式に入力し、工数や期間を算出する見積り技法です。代表例であるCOCOMO(Constructive Cost Model)は、Barry Boehm氏が1980年代に提唱したモデルで、ソフトウェア規模(ソースコード行数)を基点に工数を推定する手法として知られています^*1。係数モデルは初期段階での概算に向きますが、モデルが前提とする開発環境や技術スタックと自社の実態がずれている場合、算出結果の妥当性が下がる点に注意が必要です。

ボトムアップ見積りとは、開発対象の作業をタスク単位まで分解し、タスクごとに必要な工数を積み上げて全体工数を算出する技法です。要件が明確な場合は精度が高くなりますが、分解が粗いタスクや見落としたタスクがあると、そのまま見積り不足につながります。

プランニングポーカーとは、チームメンバーが数値の書かれたカードを同時に提示し合い、作業規模を相対的に見積もる技法です。ワイドバンドデルファイ法を土台に2002年頃に考案され、2005年に書籍で紹介されて以降、アジャイル開発のスプリント計画で広く使われています^*5。絶対時間ではなく相対的な大小関係で見積もるため、個人のバイアスが薄まりやすいとされていますが、見積りの単位(ポイント)を工数や期間に変換するには、チームの過去の実績データが別途必要になります。

見積りが外れる理由と不確実性コーン

見積りが実績と大きく異なる背景には、要求そのものの不確実性があります。ソフトウェア工学者のSteve McConnell氏は、著書「Software Estimation: Demystifying the Black Art」で「不確実性コーン(Cone of Uncertainty)」という考え方を紹介しました^*6。これはBarry Boehm氏の1980年代の研究を基にした概念で、プロジェクトの初期構想段階での見積りは、後の実績値に対して数倍単位で振れる可能性があり、要件定義や設計が進むにつれてその振れ幅が収束していく、という傾向を図示したものです^*6。

つまり見積りの誤差は、担当者の技量不足だけが原因ではなく、その時点で確定していない要求が多いこと自体が主因になります。企画段階の一度の見積りを確定金額として扱うと、後工程で要求が具体化するたびに見積りとの差が広がりやすくなります。

この考え方を実務に落とし込むと、見積りは「一度出したら終わり」ではなく、要求が具体化する各段階で見積りを更新する前提を持つ必要があります。企画時はレンジ(幅)で示し、要件定義完了時・基本設計完了時に見積りを精緻化していく運用が、不確実性コーンの考え方と整合します。

見積りバイアスにも留意が必要です。担当者が楽観的に見積もる傾向や、発注者の期待予算に見積りを合わせてしまう傾向は、技法の精度とは別の要因で見積りを歪めます。技法を正しく使っても、算出プロセスに恣意的な調整が入れば精度は保てません。

見積りレビュー・第三者チェックで精度を上げる考え方

見積りの精度を高める方法の一つが、見積りを作成した担当者以外による見積りレビューです。同じ組織内でレビューする場合、前提条件や暗黙の了解を共有しているため、抜け漏れに気づきにくいことがあります。

外部の第三者に見積りレビューを依頼する価値は、この「内部では見えにくい前提」を洗い出せる点にあります。第三者は自社の開発体制や過去の癖に縛られないため、機能の数え漏れ・タスクの分解粒度の粗さ・係数モデルの前提条件のズレなどを、外部の視点で点検できます。

必要なスキル・工数の面でも留意点があります。見積りレビューを内製で行うには、複数の見積り技法の特性を理解した人材と、レビュー対象システムの業務知識を両方持つ人材が必要です。両方を兼ねる人材が社内にいない場合、レビューの質が担当者一人の視野に依存し、見積り誤差の発見が遅れるリスクがあります。専門家に依頼した場合との違いは、複数プロジェクトの見積りを見てきた第三者が、業界共通の見落としパターンを踏まえて点検できることにあります。

見積りを誤ったまま契約・開発に進むと、追加の予算確保や仕様調整が発生し、プロジェクトの計画そのものを見直す事態につながります。見積りレビューは、こうした後工程での手戻りコストを避けるための工程として位置づけられます。

外注で見積り技法を支援してもらう場合の委託範囲

見積り技法そのものを外部支援してもらう場合、委託範囲は主に次の3つに分けられます。第一に、FP法やボトムアップ見積りといった技法の社内導入支援です。技法の選定基準づくりや、初回の見積り作成に伴走する形の支援が該当します。

第二に、既存の見積りに対するレビュー・妥当性検証です。発注側が作成した見積りを外部パートナーが点検し、前提条件の漏れや算出根拠の妥当性を確認します。契約金額を決める前の見積り自体を作り直すのではなく、既存の見積りの精度を検証する位置づけです。

第三に、見積り精度を高めるためのプロセス設計支援です。段階的見積り(企画時・要件定義完了時・設計完了時の見積り更新タイミング)や、見積りバイアスを防ぐレビュー体制の設計など、見積りを一度の作業で終わらせない仕組みづくりを支援します。

これらはいずれも、発注側が既に持っている開発計画や要求定義の情報を前提に進める支援です。開発そのものの受託とは別に、見積りの精度向上という工程単体で依頼できる範囲になります。

外部支援を依頼する前に発注側が準備すべきこと

外部に見積り技法の支援を依頼する場合、発注側にも準備が必要です。まず、対象システムの機能一覧や業務フローなど、見積りの根拠となる資料をできる範囲で整理しておくことが前提になります。資料が整理されていないと、外部パートナーが最初にヒアリングと資料整理に時間を要し、支援の効果が出るまでの期間が延びます。

次に、どの段階の見積りを対象にするかを明確にすることです。企画段階の概算精度を求めるのか、契約直前の確定見積りの検証を求めるのかで、依頼する技法・支援内容が変わります。目的を曖昧にしたまま依頼すると、期待した精度のレビューを受けられない可能性があります。

さらに、社内の見積り担当者が最終的に技法を使いこなせるようになることを目指すのか、その都度のレビューだけを依頼するのかも整理しておく必要があります。前者であれば技法導入・教育を含む支援、後者であればレビュー単体の支援と、依頼する契約形態が異なります。

まとめ：見積り精度は技法選定とレビュー体制で決まる

本稿では、工数見積り技法の種類と使い分け、見積りが外れる背景にある不確実性、精度を高めるための外部支援の考え方を整理しました。要点は3つに集約できます。第一に、FP法・類推見積り・係数モデル・ボトムアップ・プランニングポーカーは、開発段階に応じて使い分けるべき技法であり、どれか一つが常に優れているわけではありません。第二に、見積りの誤差は担当者の技量だけでなく、その時点の要求の不確実性に起因する部分が大きく、段階的な見積り更新が必要です。第三に、見積りレビューを外部の第三者に依頼することで、社内では気づきにくい前提の漏れを点検できます。

見積り技法を正しく選び、レビュー体制を整えることが、開発計画全体の精度を左右する土台になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Barry W. Boehm「Software Engineering Economics」（1981年、COCOMOモデルの提唱）
2. *2　出典：IFPUG（International Function Point Users Group）公式サイト「About IFPUG」
3. *3　出典：独立行政法人情報処理推進機構(IPA)「ソフトウェア開発分析データ集2022」（2022年公表）
4. *4　出典：独立行政法人情報処理推進機構(IPA)「ソフトウェア開発分析データ集」シリーズにおけるFP規模と工数の関係分析（同データ集本編に基づく）
5. *5　出典：Mike Cohn「Agile Estimating and Planning」（2005年、プランニングポーカーの手法紹介）
6. *6　出典：Steve McConnell「Software Estimation: Demystifying the Black Art」（Microsoft Press、2006年、不確実性コーン(Cone of Uncertainty)の提示）

Tweet