役員説明の終わり際、スライドの見積もり欄を指して役員が聞く。「この人日は、どこから出てきたの」。数字はチームがAIに出させた工数見積もりのたたき台で、あなたが把握している内訳は半分ほどしかない。
その場で答えるのは、作ったチームでもAIでもなく、あなただけだ。
flowchart TD
A[AIのたたき台] --> B[範囲の1行]
B --> C[調整時間の1行]
C --> D[日・週・月に丸める]
D --> E[施策の比較で決まる]
工数見積もりで削られるのは、精度を詰める作業ではなく根拠に一人で答える場面だ#
根拠を聞かれたあとの次の手は、たいてい決まっている。AIに内訳をもっと細かく出させ、画面ごと・工程ごとの人日を並べて次回に持っていく。
ところが内訳を細かくするほど、役員が指を差せる行も増える。「このテストの日数は多くないか」「この画面は流用でいけるだろう」と、質問は1行ごとに生まれる。精度を上げるほど答える量が増えるので、詰めても終わらない。
消耗の正体は精度不足ではない。人月の数字に根拠を求められる場で、答える役が一人に固定されていることだ。名前を付けるなら「人月の答弁役」になる。数字はAIとチームが作れても、答弁は渡せない。AIに渡せる部分と渡せない部分を紙に書き出してみると、この答弁ははっきり残る側に入る。
役員が比べたいのは何人日かではなく、数日規模か数週間規模かだ#
粒度を考え直す材料に、タンプのエンジニアが書いた記事がある（TANP Blog「人による工数見積もりをやめて、AIに任せることにした」）。原典は以前の流れを6つの手順で書いており、その中に「エンジニア全員で工数を見積もる」が入っていた。今は事業部がテンプレートで要求定義を書き、コードベースを読めるAI（Devin）がレビューから見積もりまでを担う。
割り切りの根拠ははっきりしている。施策の検討段階で事業部が知りたいのは、必ずしも「正確に何人日か」ではないとし、こう書く。「実際の開発工数が5日なのか7日なのかを完璧に当てることよりも、数日規模なのか数週間規模なのかを素早く判断できる方が重要です」。求めるのは「高い絶対精度ではなく、意思決定に十分な精度と一貫性」ではないか、という。
ただし著者は、見積もりにはリリース日を決める用途や人員配置・プロジェクト計画の用途もあると挙げ、施策検討の用途なら「必ず守るべき約束として扱う必要はありません」と区別している。AIの見積もりが常に正しいわけではないとも書いたうえで、施策を比べる尺度としてなら、AIが一定の基準で素早く見積もる方が合理的ではないかと考えた。
この区別を役員説明に当てはめると、帰属が変わる。根拠を詰められるのは説明が下手だからではない。比べるための数字を、約束の精度で出しているからだ。
問いは1つ、答えは2通りだ。その数字は何に使われるのか。
- 比べるための数字 他の施策と並べて優先順位を決めるだけなら、規模の尺度で足りる
- 約束の数字 日付や人員の確約に使うなら、別の見積もりとして作り直す
AIのたたき台を役員に出す前に、自分で見るのは前提の2行だけでいい#
ここからは私の側の切り出しで、TANPの記事が書いていることではない。比べるための数字として出すなら、確かめる前提は対象範囲の1行と、調整の時間を含めたかの1行で足りる。数字の中身は追わず、粒度を丸めて渡す。
1行目は「含めていないもの」が書かれているかで判定する#
タンプのAIは、コードベースを読んで変更箇所を調べてから見積もる。入力の要求定義も、テンプレートとAIのレビューで先に揃えている。手元のチャットAIに依頼文だけを渡した場合、何を対象に数えたかはAIの推測になる。
だから1行目は、含めたものより「含めていないもの」が書かれているかで見る。データ移行・既存画面の改修・テストのどれを外したかが空欄なら、その見積もりはチームへ戻す。数字の定義が書かれていないと、部署ごとに出したAIの数字が食い違い、役員説明の直前に突き合わせる羽目になる。
2行目は作業の時間と調整の時間を分ける#
2行目は、顧客確認・レビューの往復・承認待ちといった調整の時間を工数に含めたかだ。作業3日と、着手から完了まで3日とは別物で、混ざると作業日数がそのまま完了日として読まれる。
作業と調整を分けて読む見方は、発注側ではもう始まっている。私が提案側で受け取るRFPでは、社内調整のレーンと技術的な作業のレーンを分けて見積もるよう求めるものが出てきた。
2行は見積もりを作る側に書かせる。チームのAI依頼文の頭に、標準として次を足してもらう。あなたは上がってきた2行を読み、空欄なら戻すだけでいい。
数字を出す前に、見積もりの先頭へ次の2行を書いてください。
1行目：対象に含めたもの／含めていないもの
2行目：顧客確認・レビュー往復・承認待ちの時間を工数に含めたか
分からない項目は推測で埋めず「未確認」と書いてください。数字は日・週・月の3段階に丸めて渡す#
2行が読めたら、数字は丸める。目安として、5営業日に収まるなら「数日」、4週に収まるなら「数週間」、それを超えたら「数か月」で切る。スライドの見積もり欄は次の形にする。
規模：数週間
前提：対象は〇〇の改修のみ。データ移行は含まない
前提：作業時間のみ。顧客確認とレビューの待ちは含まない
用途：施策を比べるための目安。日付の約束ではない最後の「用途」の行が、答弁の範囲を前提の2行に絞る。根拠を聞かれたら、2行を読み上げれば済む。
逃げの一手：人日を譲らない役員には、用途を聞いて持ち帰る#
丸めた規模を出しても「で、何人日なの」と返る場面はある。そのときは数字を言わず、用途を1問だけ聞く。
この数字は、施策を比べるためにお使いですか。それとも日付や人員のお約束に使われますか。約束に使うなら、TANPの記事が分けていたのと同じ別用途の見積もりになる。その場で人日を作らず、チームで見積もり直して回答する日だけを決めて持ち帰る。
持ち帰った宿題は、会議が終わった直後に、返事が要る発言だけを拾って残しておくと、次の説明までに埋める物が1行に絞れる。2行目がどうしても埋まらない見積もりは、「作業時間のみ。調整の時間は未確認」と書いたまま出してよい。未確認と書いてある前提は、答弁で詰まらない。
まとめ：答弁を減らすのは精度ではなく、前提2行と粒度だ#
人月の答弁役から降りられなくても、答える範囲は前提の2行まで縮められる。役員が比べたいのは数日か数週間かであって、5日か7日かではない。
本記事は AI が下書きし、管理人が監修しています。
続きはタイムラインに置いていく。
