KKD×AIによるタスク見積もりのハイブリッド手法

この記事はAidemy Advent Calendar 2024の13日目の記事です。

はじめに

世の中でAIの普及が進む中、プロジェクトマネジメントにおいてもAIの活用が増えています。今回は、KKD法による工数見積もりを振り返りながら、AIを活用した工数見積もりについて考察してみたいと思います。

1. KKD（勘・経験・度胸）とは

KKDとは、勘（K）・経験（K）・度胸（D）の頭文字を取った言葉であり、プロジェクトや業務の見積もりを経験則や直感に頼って判断する手法です。特にスピードを重視して見積もる場面で用いられる手法の1つです。（私自身もよく使ってしまいます）

KKDが使われる背景 / 心理的な面

• 過去の成功体験:
  • 「以前も〇〇だったから、今回も〇〇でOK！」という思考。
• 経験豊富なメンバーへの依存:
  • ベテランの方がいればなんとかなる/なってしまっている/そうするしかない「属人化」の文化。
• 短期的なプレッシャー:
  • 上司や顧客からの「すぐに見積もり出して！」という要求
    （私も「ざっくりでいいから見積もりを出してほしい！」とメンバーにお願いしてしまうことがあります。反省しています。）

2. KKDに頼った見積もりのアンチパターン

いずれのケースも、結果的に納期の遅延、コスト超過（利益の圧迫や赤字案件化）、さらには品質の低いシステムの納品といった問題につながることがしばしばあります。

ケース1:前回と同じだろうパターン

• 状況:
  • 前回のシステム開発に2ヶ月かかったから、似た規模なら今回も2ヶ月だろう。
• 問題になりうる点:
  • 要件の違い（仕様の追加や複雑性の増加）が見落とされること。
  • チームの経験やスキルが変わっている場合の工数が無視されること。

ケース2:ベテラン頼みの属人化

• 状況:
  • 〇〇さんがこのタスクを3日で終わらせたから、同じく3日で見積もりでいけるはず！
• 問題になりうる点:
  • スキルや経験に依存し、他のメンバーでは再現できない。
  • ベテランが退職・異動した場合、見積もりの根拠がなくなる。

ケース3:勘と勢いで決める「度胸見積もり」

• 状況:
  • 顧客には短納期で約束しないと受注できない。なんとかなるだろう。（なんとかするしかない！）
• 問題になりうる点:
  • リスクを無視した見積もりが進み、後から手戻りが発生。
  • チームに過剰な負荷がかかり、モチベーション低下。

3. KKD頼りの見積もりが引き起こす問題

3.1 属人性と再現性の欠如

ここでの属人化とは、KKDに頼る見積もりを行うことで、見積もり方が「暗黙知」とってしまうことです。（私の経験上、）KKDで行った見積もりは、ドキュメント化されることが少ないと感じます。

問題になる点

• 後任への引き継ぎが困難
  • ベテラン社員が退職や異動すると、プロジェクトの進行が滞る。
  • 引き継いだ新しい担当者に不要なプレッシャーを与える可能性がある。（〇〇さんならすぐ見積り出せたのにー。のような）
• プロジェクト全体の品質低下
  • 再現性がない見積もりでは、プロジェクトの進捗管理やリソース配分が不安定になる。
  • 結果として、スケジュールやコストの予測が困難となり、組織全体の信頼性に悪影響を与える。
    • 受託開発のような案件であれば、顧客との信頼を失う可能性もある。

3.2 リスクの見落とし

KKDを使うと「なんとかなると思う」という楽観的思考が脳裏に存在している。（今まで経験したものに近いと楽観的に考えがちである）そこから、リスク管理を軽視してしまうことがある。

問題になる点

• リスク発見の遅れ
  • 見積もり段階でリスクが考慮されないため、プロジェクト後半で大きな問題が発覚する。
  • （本当にリスクは早めに発見・対処しておくべき）
• プロジェクト全体の不安定化
  • リスクに対する対応策がないため、予定外のコストや工数が発生。（プロジェクト後半に発覚するケースが多い）
  • チームのリソースが不足し、メンバーに過剰な負担がかかる。
• ステークホルダーへの影響
  • 納期遅延が頻発することで顧客からの信頼が低下する可能性がある
  • 同じ顧客から引き合いが来なくなり、ビジネスチャンスの機会を失う可能性もある

3.3 顧客や上司への説明力不足

契約を結ぶ際に、特に顧客が「なぜこのシステム/機能にこれぐらいの工数（費用）がかかるのか」疑問を持つ。（顧客も顧客の上司に説明する必要がある）その際に、当たり前ではあるが、「経験上こうなんです！」とは言いづらく説明しきれないものである。

• 「経験上こうです」といった根拠のない説明では、信頼を得にくい。
• 納期遅延やコスト増加が発生した際に、説明責任を果たせない。

問題になる点

• ステークホルダーからの信頼の欠如
  • 根拠のない見積もりでは、顧客や上司が「その見積もりに従って大丈夫なのか？」と不安を感じてしまう。（プロジェクト承認されないケースもあり得る）
• 納期遅延やコスト超過の説明困難
  • 問題が発生した際、「なぜこの見積もりだったのか」を説明できず、トラブルが悪化する。
    • 自分も過去に言われたことがある
  • 顧客や上司が納得せず、チーム全体への責任追及が増加する。（稼働が増えより遅延する）
• 顧客満足度の低下
  • 不正確な見積もりによる遅延や追加費用が発生すると、顧客満足度が低下し、リピート率や評判に悪影響を与える。

4. 見積もり手法の紹介

ここでは、よく使われる見積もりの手法について紹介します。

4.1 WBS（Work Breakdown Structure）の導入

タスクの細分化: 大きな作業を小さいタスクに分解し、見積もり精度を高める。
ポイント:

• 作業単位ごとに「作業内容」「担当者」「必要時間」を見積もる。
• 見積もり結果をチームでレビューし、漏れを防ぐ。

例: 新機能/システムの開発

• 設計: 20時間
• 実装: 50時間
• テスト: 30時間
• ドキュメント作成: 10時間
• リリース作業: 5時間

※なお、もっとブレイクダウンした方が良いが本記事では省略

4.2 三点見積もり法（PERT法）の活用

概要: 楽観値、悲観値、最可能値を用いて平均的な工数を算出。

計算方法:

• 見積もり時間=(楽観値+4×最可能値+悲観値)÷6

例:

• 楽観値: 40時間
• 最可能値: 60時間
• 悲観値: 100時間

→ 見積もり時間: (40 + 4×60 + 100) ÷ 6 = 63.3時間

4.3 過去データと見積もりテンプレートの活用

• 過去プロジェクトのデータベースを作成
  • 類似タスクの工数実績を参考にする。
  • 工数と結果の差分を分析し、精度向上に役立てる。
• テンプレート化: 見積もり項目を標準化し、均一な判断基準を作る。

その他

紹介した3つ以外にもたくさん見積もりの手法があります。

番号	見積もり手法	説明
1	ファンクションポイント法	ソフトウェアの機能を定量化し、工数を見積もる方法。
2	パラメトリック法	プロジェクトの特定のパラメータ（入力変数）と、それに基づいて工数やコストを計算するモデルを使用する手法。
3	ボトムアップ法	小さなタスクから工数を積み上げて全体を算出する方法。
4	COCOMO	コード行数を基準に、プロジェクトの規模や特性に応じた計算を行う方法。
5	Delphi法	複数の専門家の意見を収集し、合意を得て見積もりを行う方法。
6	ベロシティベース見積もり	アジャイル開発で、過去スプリントの完了タスク量（ベロシティ）を基準に、将来のスプリントの工数を推定する方法。
7	ストーリーポイント法	アジャイル開発で、タスクの相対的な複雑性や規模をポイント化し、それに基づいて見積もる方法。

5. KKDとデータ駆動による工数見積もりを考えてみる

大前提として、KKDもAIも100％正しい見積もりを行うことはできません。また、両者ともアウトプット（工数）の説明性は乏しいものだと感じている。KKDとデータ駆動を活用することで、属人化の排除と説明性を担保する流れを考えてみる。

5.1 データ駆動で「たたき台」を作成

過去のプロジェクトデータを活用して、AIを使い初期の工数見積もりを生成します。

具体的な流れ:

1. AIが過去プロジェクトのデータ（工数、要件、リスク情報など）を分析する
2. 提供された要件に基づき、初期の見積もり案（たたき台）を作成する
3. 見積もり結果をタスク単位で出力（例: 「設計20時間」「実装50時間」など）する
   • なお、もう少し細かくタスク分解された形式で出力されるのが理想である。

メリット:

• 属人性を排除し、客観性の高い見積もりを迅速に作成できる。
• 過去の成功事例や失敗事例を統計的に考慮することが可能である。

5.2 リスクレビューで精緻化

AIが作成した「たたき台」に対し、チーム全体でリスクを洗い出します。

具体的なアプローチ:

1. チームメンバーで「たたき台」をレビューし、抜け漏れやリスクを特定。
2. プロジェクト特有の条件（未経験の技術、依存タスクの複雑さなど）を加味して調整。
3. リスクへの対策工数を追加。
   • （負のリスクという前提で記載ですが）「回避」「軽減」「移転」「容認」の中から工数追加する/しないなどをリスク対応方針を決定する。

メリット:

• 「この技術は未経験だから悲観値を考慮する」など、現場の知見を反映。
  • （ついでにリスク管理表も作成可能）
• チーム全員でレビューすることで、属人的な判断を軽減。
  • リスクの考え方/発見の仕方などを新人に伝えることで教育的面でも活用が可能

5.3 KKDで判断を補完し、最終調整する

リスクレビューを経て、AIでは拾えない経験や直感を反映させていきます。

具体的な活用/メリット:

• ベテランメンバーの経験を基に、リスクや工数の見落としを補完する。
  • この時に補完した理由を明記することで、次回の見積り時に考慮された状態で叩き台をAIに出力させることが可能。
• 楽観的/悲観的な見積もりを現実的な値に修正することができる。
• 不確実度合いによって工数を追加することも可能である。

KKDとデータ駆動の融合による4つのメリット

1. 見積もりの精度向上:
   • AIのデータ分析により初期の精度が高まり、KKDやリスクレビューでさらに補正可能。
2. 説明性の向上:
   • データに基づいた根拠を示しつつ、現場の知見も加味した見積もりが可能。
3. 属人性の排除:
   • AIで標準化された見積もりのため、担当者によるばらつきを軽減。
4. リスクの網羅:
   • 現場の経験とAIの分析を融合することで、見落としが減少。
   • (とはいえ、完璧にリスクを網羅できるわけではない）

さいごに

KKDとデータ駆動（AI）のいずれか一方に依存した工数見積もりでは、精度や説明性に限界があり、これらを補完的に組み合わせることで、客観性/説明性や現場知見/直感を両立した高精度な見積もりができると感じています。

今回、改めてKKDのことをまとめて、自分の頭の中で、1-3の手順をしてタスクを洗い出していることに気がつきました。（反省反省）

1. WBSを作成/確認する
2. そこからリスク/不確実性がありそうなタスクを洗い出す
3. 2のタスクに悲観的（バッファ）を入れて3点見積り法を使う

また、見積もりを行う際、「自分が見積もった数字には責任を持ってやり遂げるのです！」と新卒の時の上司に言われたことを毎回思い出します。AIが出した工数見積もりの数字には、PMが遂行する度胸は今後も必要なのかも知れないと感じています。

とはいえ、データ駆動のタスク見積もりができてないため、これからは属人化しない仕組み作りを頑張ります💻