AIに実装タスクを分解させる｜WBSの抜けを見つける使い方
「来週の頭までに、この機能のタスク一覧と工数を出しておいて」。夕方にそう言われて、夜、まだ何も書かれていない表を開いたまま少し固まる——そんな時間が、たぶん今日もどこかにあります。
機能の中身は、だいたい頭に入っています。ただ、それを他人が読める粒度の一覧に落とすのが重い。しかも一覧に書き忘れたものは、そのまま「無かったこと」になって、後半で自分に返ってきます。
そこでAIに「この機能の実装タスクを分解して」と頼むと、30秒できれいな一覧が返ってきます。番号が振られ、順番も通っている。問題は、その一覧が「うまくいったときの順路」だけでできていることです。この記事では、そこにどう抜けを足すかを整理します。
結論：AIにタスク分解（WBS＝やることを作業単位まで細かく分けた一覧のこと）を手伝わせるときの要点は3つです。①一度で完成させようとせず、まず粗く8〜15行で出させる。細かい一覧をいきなり出させると、粒度がばらついたまま固まってしまいます。②「抜けているタスク」を名指しで洗わせる——決まっていないこと・他人が絡むこと・後片付け。AIは聞かれた範囲しか答えないので、抜けやすい場所を先にこちらから指定します。③出てきた一覧は、工数を入れる前に人に確認する。抜けの多くは、あなたの現場の事情の中にあります。
3つ全部を今日やる必要はありません。まずは①の「粗く出す」だけで、白紙の前で止まる時間はなくなります。
何が起きているのか——AIは「うまくいく順路」を分解する
まず、なぜAIの一覧に穴が空くのかを共有させてください。理由は3つあります。
1つ目は、ハッピーパス（＝想定どおりに全部うまくいく道筋）で分解すること。図の左のように、AIは「作る順番」を素直に並べます。画面を作り、APIを作り、つないで、テストする。この順路は正しいのですが、現場の時間を食うのは順路の外側です。仕様が決まらない、レビューが返ってこない、検証環境が空かない。そこは道筋の中に出てきません。
2つ目は、粒度が揃わないこと。「認証機能の実装」と「エラーメッセージの文言修正」が、同じ1行として並びます。行数と作業量が比例しない一覧は、そのまま工数表にすると事故のもとです。AIが手を抜いているのではなく、どこを厚く見たいかを伝えていないだけです。
3つ目は、あなたの現場の事情を知らないこと。承認に何日かかるか、外部APIのアカウント発行に誰の判子が要るか、リリース前に情シスの確認が入るか。ここはコードの外側にある情報なので、渡さない限り出てきません。前提の渡し方そのものはAIにコードを書かせる前に渡す前提と制約｜伝え方の型と同じ考え方です。
この3つが重なると、「一覧はきれいなのに、後半でどんどん増える」という状態が生まれます。逆に言えば、抜けやすい場所は毎回だいたい同じということでもあります。だから、そこだけ名指しで聞けばいい。
具体例——AIのタスク分解から抜けやすいもの
現場でよく落ちるのは、次のようなタスクです。どれも「AIが悪い」わけではなく、聞かれていないから出てこなかったというだけの話です。
- 決めごと待ち：仕様の確定、画面の文言、デザインの確定、どのパターンを採用するか。手は動かないのに日数だけ進むので、一覧にないと丸ごと消えます。
- 他人が絡む作業：コードレビュー、承認、情シスへの申請、外部サービスのアカウント発行、他チームのAPI待ち。自分の頑張りでは縮まない種類の時間です。
- 環境まわり：検証環境の用意、テストデータの準備、権限の付与、秘密情報の設定。「実装が終わったのに動かせない」はここから来ます。
- データまわり：既存データの移行、初期データの投入、移行のリハーサルと切り戻し。本番のデータは、開発中のデータより必ず汚れています。
- 異常系と失敗時の扱い：通信が落ちたとき、二重に押されたとき、途中で止まったとき。観点の洗い方はAIにテストケースを洗い出させる｜観点の与え方が使えます。
- 非機能まわり：性能、ログ、監視、権限、同時アクセス。まとめて洗いたいときは非機能要件の抜け漏れをAIに洗わせる｜観点リストと確認の型へ。
- リリース作業そのもの：手順書、周知、切り戻しの段取り、当日の立ち会い。「作る」の中には入っていないのに、確実に人の時間を使います。
- 後片付け：一時的に入れたフラグの撤去、旧コードの削除、ドキュメントの更新、運用手順の引き渡し。後回しにすると、次の案件の見積もりに紛れ込みます。
- 手戻りの枠：レビュー指摘の反映、QAからの差し戻し、仕様変更の取り込み。ゼロで組むと、必ずどこかを削ることになります。
並べてみると、抜けているものの多くが「決まっていないこと」「他人が絡むこと」「後片付け」の3か所に集まっています。見る場所は、思ったより少ないのです。
影響——抜けたタスクは、いちばん動きにくい時期に出てくる
一覧から落ちたタスクが、その場で消えてくれるならいいのですが、実際には遅れて出てきます。しかも出てくる時期が悪い。
- 後半に集中する：申請、環境、移行、リリース準備。抜けやすいものほど工程の終盤に位置しているので、余白がいちばん少ない時期にまとめて現れます。
- 自分では巻き取れない：他人待ちの時間は、残業でも短縮できません。早く気づいて、早く声をかける以外に手がない種類の遅れです。
- 説明が難しくなる：あとから足したタスクは、外から見ると「見積もりが甘かった」に見えます。実際には、最初から見えないところにあっただけなのですが、その説明に時間を取られます。
- 次の見積もりに引きずる：片付け残りが次の案件に紛れ込むと、そちらの数字も少しずつずれていきます。
ここで言っておきたいのは、これは分解が下手だから起きることではないということです。決まっていないことは、その時点では誰にも書けません。他人の予定は、こちらからは見えません。だから、個人の注意力ではなく聞き方の型で埋める——それが、この件でいちばん効く考え方です。
そしてもうひとつ。一度この聞き方を作っておくと、次の案件からはコピーして使えます。今日30分かけて作る質問文は、半年後のあなたと、隣の席の人の分まで働いてくれます。
明日からやること（3ステップ）
大がかりな道具は要りません。この順番なら、今日の夜から小さく始められます。
1. まず粗く、8〜15行で出させる
いきなり細かい一覧を頼まないでください。細かく出させると、粒度がばらついたまま固まって、直すのが面倒になります。最初は、あとから足せる余地のある粗さで止めます。
そのまま使える頼み方の例：
次の機能の実装タスクを、8〜15行の粗い単位で分解してください。条件は次のとおりです。
1. 1行＝おおむね半日〜2日で終わる大きさにそろえてください。それより大きいものは「（分解が必要）」と付けてください。
2. 実装だけでなく、設計・確認・準備の作業も1行として立ててください。
3. 順番の前後関係（このタスクはどれが終わってから始められるか）を、各行に1つだけ書いてください。
4. 前提が足りなくて分解できない部分は、勝手に埋めず「確認が必要なこと」として別に並べてください。
機能：（何を作るか。画面・処理・データの範囲）
今ある材料：（仕様書・既存の似た機能・使う技術）
制約：（期限・人数・触ってはいけない範囲）
条件4がいちばん効きます。前提が足りないとき、AIは黙って埋めてしまうことがあります。もっともらしい仕様が紛れ込む形の外し方についてはAIのハルシネーションの見抜き方｜開発現場で気づく型も合わせて見ておくと迷いません。
既存システムへの追加なら、ここで現物を少し渡すと精度が変わります。ディレクトリ構成や似た機能のファイルを見せる渡し方は既存コードにAIを馴染ませる文脈の渡し方｜実務の型にまとめてあります。
2. 「抜けているタスク」を名指しで洗わせる
粗い一覧ができたら、同じAIに、今度は穴を探させます。図の中央です。ここは「他に何かありますか」と聞かない。抜けやすい場所をこちらから指定したほうが、はるかに出ます。
さきほどのタスク一覧について、抜けている作業を洗い出してください。次の観点ごとに、足りないタスクだけを挙げてください（十分な観点は「なし」と書いてください）。
1. まだ決まっていないこと（仕様・文言・デザイン・採用方式）と、それを決めるのに必要な作業
2. 自分以外の人が関わる作業（レビュー・承認・申請・他チーム待ち・外部サービスの発行手続き）
3. 環境とデータ（検証環境、テストデータ、権限、設定、既存データの移行と切り戻し）
4. 異常系・失敗時の扱い（通信断、二重実行、途中終了、入力の想定外）
5. 非機能（性能、ログ、監視、権限、同時アクセス）
6. リリースと後片付け（手順書、周知、切り戻し、一時的な仕組みの撤去、ドキュメント更新、運用への引き渡し）
7. 手戻り（レビュー指摘の反映、差し戻し、仕様変更の取り込み）
各タスクには、なぜ必要かを1行で添えてください。この機能に当てはまらない観点は、無理に埋めないでください。
最後の一文を入れておくのが小さなコツです。これを言わないと、7観点すべてを律儀に埋めようとして、要らないタスクまで並びます。
出てきたものは、そのまま全部足さなくて大丈夫です。「これはうちでは要らない」と自分で消せる状態になったこと自体が、ここでの成果です。見落としを洗わせる考え方は、設計側でも同じように使えます(設計レビューの見落としをAIに洗わせる｜プロンプトの型)。
3. 工数を入れる前に、人に確認する
最後は、一覧を持って人のところへ行くことです。図の右です。ここを飛ばすと、抜けの残りは埋まりません。
一覧に、次の3列だけ足しておくと話が早くなります。
- 誰がやるか（自分／他チーム／外部）
- 何を待つか（決定待ち・レビュー待ち・発行待ちなど、待ちの相手）
- いつまでに決まっていてほしいか（着手できなくなる日）
このうち 「何を待つか」の列に何か書いてある行だけを持って、関係する人に確認します。全部を相談する必要はありません。聞くのは1つで十分です。
「この作業、着手できるのは何が決まったあとになりますか」
この質問が強いのは、相手を急かさずに、こちらの前提を先に見せられるところです。「いつまでにやってください」ではなく「これが決まると動けます」。同じ内容でも、受け取られ方がまるで違います。
そして工数の数字は、AIに出させたものをそのまま使わないでください。AIは、あなたのチームの速さも、レビューの戻りやすさも知りません。数字の握り方と、「AIで早くなるよね」と言われたときの答え方は「AIで早くなるよね」と言われた見積もり｜工数の織り込み方にまとめてあります。上に出す前の期待値そろえには「AIならできる」の期待値を現実に着地させる説明術も合わせてどうぞ。
タスク分解のチェックリスト
全部に○が要るわけではありません。気になった行だけで十分です。
① AIに頼む前に
- 何を作るか（画面・処理・データの範囲）を、1〜2行で書き出せているか
- 期限・人数・触ってはいけない範囲を伝えているか
- 既存システムへの追加なら、似た機能や構成を渡せているか
- 1行の大きさ（半日〜2日など）を指定しているか
- 前提が足りない部分は「確認が必要」と分けて返すよう頼んでいるか
② 返ってきた一覧を見るとき
- 1行の大きさが、極端にばらついていないか
- 決まっていないことを決める作業が、行として立っているか
- レビュー・承認・申請など、他人が関わる作業が入っているか
- 環境・テストデータ・権限の準備が入っているか
- 異常系と、失敗したときの戻し方が入っているか
- リリース作業と周知が入っているか
- 一時的な仕組みの撤去・ドキュメント更新など、後片付けが入っているか
- 手戻りの枠がゼロになっていないか
- この機能には要らないタスクが、観点を埋めるためだけに並んでいないか
③ 出す前に
- 「誰がやるか」「何を待つか」の列を足したか
- 待ちのある行について、関係する人に声をかけたか
- 工数の数字を、自分の感覚で握り直したか
- 前提（この日までに決まっている想定）を、一覧と一緒に添えたか
この記事のまとめ
AIは、タスク分解のたたき台を作るのが速い。白紙から書き始める重さを、まるごと引き受けてくれます。苦手なのは、まだ決まっていないことと、あなたの職場でだけ起きる待ち時間を想像することです。だから、そこだけこちらから名指しで聞きます。
やることは3つだけです。①粗く8〜15行で出させる／②抜けを観点ごとに名指しで洗わせる／③工数を入れる前に人に確認する。この順番で組むと、一覧は「きれいだけど当てにならない表」から、「後半で慌てないための地図」に近づきます。
一覧に並んだ行が増えて、少し気が重くなったなら、それは悪い兆候ではありません。後半で出てくるはずだったものが、前半に移動しただけです。全部を今日そろえなくて大丈夫。まずは粗い8行から始めれば、抜けはあとから足せます。
よければ、こちらも
- 数字を出す段になったら「AIで早くなるよね」と言われた見積もり｜工数の織り込み方
- 作る前に要件をそろえたいときは業務システムにAI機能を載せる前に｜要件と期待値の整理
- 設計そのものを相談したいときはAIを設計の壁打ち相手にする｜問いの立て方の型
- 実装に入るときの切り方はAIコーディングは小さく切る｜関数1個から始めるスコープ設計