〜経験と勘を「戦略的ロジック」でアップデートする〜
1. はじめに：EMによる「見積もりレビュー」の限界
エンジニアリングマネージャー（EM）にとって、メンバーから上がってきたWBS（作業分解構成図）や工数見積もりをレビューする作業は、日常的でありながら最も事故が起きやすいタスクの一つです。
特に、クライアントサイドと複数のサーバー基盤システムが複雑に跨る大規模開発において、人間一人の脳ですべての依存関係や非機能要件の漏れを完璧に把握するのは不可能です。多くの場合、私たちは過去の経験や「なんとなくの直感」で、感覚的なフィードバックに終止してしまいがちです。
しかし、AIを「冷徹なレビュアー」として起用すれば、見積もりのレビューは「妥当性の根拠をあぶり出す科学的なプロセス」へと進化します。
2. AIに「あえて否定させる」レビュー手法
見積もりレビューにおいて AI を最も効果的に使うコツは、AIに「肯定」ではなく「批判」を求めることです。
「この見積もりは正しいか？」と問えば、AIは多くの場合、論理的な整合性があれば肯定的な回答をします。しかし、実務で必要なのは「どこが壊れるか」という視点です。 私は自身のレビュープロセスにおいて、AIに対して以下のような役割を与えています。
- 「最悪のシナリオライター」としてのAI: 「この見積もりが破綻するとしたら、どの工程がボトルネックになるか？ 3つのリスクを挙げよ」
- 「依存関係の探偵」としてのAI: 「インターフェースの仕様変更が、関連システムに与える影響が、このWBSから欠落していないか？」
AIに「死角」を指摘させることで、EMは「経験による直感」を「論理的な裏付け」へと変換し、メンバーに対して納得感のある問いかけができるようになります。
3. 「戦略的整数」によるリスクバッファ設計
以前の記事（30/60/100%の解像度管理編）で述べた通り、WBSを100%作り込む必要はありません。しかし、見積もりには必ず「バッファ（予備）」が必要です。
これまでのバッファは、根拠のない「なんとなく20%上乗せ」という形になりがちでした。しかし、説得力のあるマネジメントにおいては、計算の根拠（エビデンス）を感じさせる「戦略的な一桁の整数」を活用すべきです。
- リスク検証コストの明文化: AIが「基盤刷新に伴う未知の不確実性」を指摘した場合、その検証工数を「一律20%」とするのではなく、精緻に計算した結果としての「27%」や「14%」としてWBSに組み込みます。
- 「守りの強い」数値の活用: 27%や14%といった具体的な整数を用いることで、資料としての美しさを保ちつつ、「実態を精緻に計算した結果」という印象をステークホルダーに与え、不透明なバッファに対する疑念を払拭します。
これにより、バッファは「怠慢」ではなく「不確実性への誠実な投資」として、強固な説明責任を果たす根拠になります。
4. 【実践】レビュー品質を劇的に上げる3つの質問
明日のレビューからすぐに使える、AIへの「問い」の型を紹介します。
- 構造の不備を問う: 「このWBSに欠落している非機能要件を指摘せよ。特に、今回の基盤刷新において、将来的な技術負債になりかねない『簡略化』がなされていないか？」
- 依存関係を問う: 「複数のプラットフォーム間で発生しうる、並行開発上のボトルネックを特定せよ。特に、データ構造の変更が既存の整合性に与える影響を考慮せよ」
- 実現性を問う: 「業界標準のベストプラティスと比較し、この工数設定が『楽観的すぎる』箇所を3つ挙げよ。また、メンバーがこの期間内に完遂するために、マネージャーが排除すべき外部障害は何か？」
AIという冷徹な参謀と共にこれらの問いを繰り返すことで、EMは経験則に頼らない、再現性の高いレビューを行えるようになります。 しかし、見積もりという『手段』を磨く前に、我々にはそもそも『そのプロジェクトで何を解決したいのか』という問いそのものを設計する責任があります。この最上位概念については、本ブログの旗艦記事である問いの設計責任：AIに代替できないEMの核心で詳述しています。
よくある質問（FAQ）
- Q：AIが出した見積もりと、現場メンバーの見積もりに大きな乖離があった場合はどうすべきですか？
- A：結論として、その乖離こそがプロジェクトに潜む「不確実性」の正体であり、論理的な対話のきっかけとして活用してください。
- AIの指摘をそのまま正解とするのではなく、「AIは〇〇というリスクを懸念して工数を多めに見積もっているが、現場の認識はどうだろうか？」と問いかけることで、隠れたリスクの早期発見に繋がります。
- Q：自社独自のレガシーシステムや特殊な制約をAIが知らないため、レビュー精度が落ちる心配はありませんか？
- A：結論として、EMが「制約条件の設計者」となり、独自の文脈（Context）をプロンプトで明示する必要があります。
- AIは一般的な「論理」を担当し、EMは「今回のみの物理的制約」を足すという役割分担を意識してください。これにより、複数の開発ラインを管轄する組織においても、高いレビュー精度を維持することが可能です。
- Q：メンバーに対して「27%」や「14%」といった具体的なバッファを提示することに、細かすぎるという反発はありませんか？
- A：結論から言えば、むしろ逆です。エビデンスに基づいた具体的な数値は、メンバーにとっての納得感を高める「論理の盾」になります。
- 「なんとなく2割」という曖昧な指示よりも、「過去の依存関係のリスクを計算した結果、今回は27%の検証コストが必要だ」と伝える方が、感情的な説得ではなく論理的な合意形成を可能にします。
5. むすび：「進捗を追う人」から「ロジックを管理する人」へ
EMが一生懸命進捗を追いかけなくても、「ロジックが正しいWBS」は自然と回ります。
AIと共に「見積もりの妥当性」を極限まで検証し、隠れた地雷を事前に撤去しておく。この事前の「論理的守備力」こそが、デリバリーの速度を最大化し、現場の疲弊を防ぐ唯一の道です。
管理の事務作業はAIに任せ、あなたは「組織のロジック」を磨くことに集中しましょう。
