タスク分解・起票ガイド

抽象的なタスクを壁打ちで構造化し、「なぜ・何を・誰が・いつまでに」が明確な issue として起票する。起票者 ≠ 実行者を前提に、誰が取っても同じ解像度で動ける状態を作る。

理論的背景

本スキルは RACI・チームトポロジー・HIGH OUTPUT MANAGEMENT・INVEST の考え方を取り入れている。詳細は references/theory.md を参照。以下は実務での使い方の要点。

• RACI: タスクごとに「実行者・見届ける人・相談先・共有先」を明確にする。見届ける人（Accountable）が不在のタスクは「誰の責任でもない」状態になる
• チームトポロジー: チーム境界をまたぐタスクは境界で切る。相談先が 3 人以上必要なタスクはスコープが広すぎるサイン
• HIGH OUTPUT MANAGEMENT: 担当者の習熟度が低いほど確認ポイントを増やす。タスクは習熟度「低〜中」でも動けるレベルで書く
• INVEST: 分割後の各タスクが Independent・Negotiable・Valuable・Estimable・Small・Testable を満たすか確認する

いつ使うか

• タスクや issue を起票したいが、まだ抽象的で整理が必要なとき
• 「〇〇の調査が必要」「〇〇を実装したい」のような種を具体的な issue に仕上げたいとき
• 既存タスクの粒度が大きすぎて分割したいとき
• チームメンバーに渡すタスクの解像度を上げたいとき
• 領域ごとの責任者（オーナー）を明確にしたいとき

このスキルがやらないこと

• コードレビューや実装は行わない。 タスクの構造化と起票（または出力）までが責務
• PRレビュー・マージ判断は行わない。 レビュー依頼はこのスキルのスコープ外
• プロジェクト管理ツールの操作は行わない。 Jira / Linear 等への直接連携はしない（出力されたテキストを手動で転記する想定）
• 汎用的な技術知識でタスク内容を補完しない。 タスクの完了条件・スコープ・差分はユーザーの入力（FRD・会話・仕様書）に明示された情報のみを使う。入力に書かれていない技術的事実（例:「Android では Sign in with Apple 不要」）は推測として混入させず、「要確認」として明示する。

推奨モデル

入力の状態	推奨モデル	理由
曖昧・抽象的なタスク	Opus	Step 2-3 の質問力が最大の価値。Opus は曖昧な入力に対し仮定せず明確化質問をする傾向があり、壁打ちの質が上がる
具体的なタスク（ショートカット判定でスキップ）	Sonnet	テンプレート整形・構造化出力が中心。Sonnet の instruction following で十分

壁打ちフロー

Step 1: タスクの種を受け取る + ショートカット判定

ユーザーが抽象的なタスクを投げる。まずはそのまま受け取る。

タスク分類: 受け取った時点でタスクの種類を判定し、以降の Step で重視するポイントを調整する:

分類	重視する Step	軽くできる Step
調査・検証	Step 3（成果物の形式）、Step 5（期日）	Step 4（分割は稀）
新規実装	Step 2（背景）、Step 4（粒度）	—
バグ修正	Step 3（再現手順 = 完了条件）	Step 2（背景は短くてよい）
リファクタリング	Step 4（影響範囲で分割）	Step 5（期日は柔軟）
意思決定・合意形成	Step 2（背景）、Step 3.5（責任）、Step 3（成果物 = ADR 推奨）	Step 4（分割は稀）

ショートカット判定: ユーザーの入力がすでに十分具体的な場合（分割方針が明確、背景が語られている、完了条件が列挙されている等）は、Step 2-5 のうち情報が揃っている Step をスキップして Step 6 へ進んでよい。スキップした場合は「背景は会話から取得済み」のように一言添える。

Step 2: 背景の深掘り

背景がないと「作業」になる。背景があれば、タスクを取った人が「じゃあここまでやらないと意味ないな」と自分で判断できる。以下を AskUserQuestion で確認する（すでに会話の中で語られている場合は確認済みとしてスキップ）:

• このタスクが必要になった理由は？
• プロジェクトのどの部分に影響する？
• このタスクの結果を使って次に何をする予定？

Step 3: ゴールと完了条件の具体化

背景をもとにゴールを具体化する。「調査する」ではなく「調査結果をもとに導入提案をドキュメント化し、チームに共有する」まで書く。ゴールが曖昧だと、取った人の解釈次第でアウトプットの質がブレる。

確認事項:

• 成果物は何か（ドキュメント？ PR？ 提案？ 動作するコード？）
• 「完了」とはどういう状態か
• やらなくていいことは何か（スコープの膨張を防ぐために「やらないこと」も明示する）

質問ループの制御: Step 2〜3.5 の AskUserQuestion は 合計 3 回まで（計 9 問以内）。3 回で情報が揃わない場合は、不足部分を「要確認」として明示した上で Step 4 以降を進め、Step 6 の出力後にユーザーに確認する。質問攻めでテンポを崩さないことが優先。ただし、不足情報を技術的な推測で埋めてはならない。

Step 3.5: 責任の明確化（RACI 簡易版）

タスクの責任範囲を明確にする。以下の問いに答える形で自然に確認する（1 回の AskUserQuestion にまとめる）:

• 誰がやる？（Responsible）: 実際に手を動かす人。未定なら「未定（チームから取る）」でよい
• 誰が見届ける？（Accountable）: このタスクが止まっていたら突く人。起票者がデフォルト。必ず 1 人決める
• 誰に相談する？（Consulted）: 判断に迷ったときの壁打ち相手。省略可
• 誰に共有する？（Informed）: 結果を知るべき人。省略可

判断基準:

• タスクが特定の領域に閉じている場合: その領域のオーナーが Accountable
• 領域横断タスクの場合: 起票者 or 合意を取りに行く人が Accountable
• Accountable が不明確なタスクは「誰の責任でもない」状態になりやすい。必ず 1 人決める

Step 4: タスク粒度チェック

Step 3 までの整理結果をもとに、タスクが適切なサイズかを検証する。

分割すべきサイン:

• 完了条件が 5 個以上 → 独立したゴールが混在している可能性
• 成果物が 2 種類以上（例: 調査ドキュメント + 実装 PR）→ フェーズが違うので分ける
• 期日までに 3 日以上かかりそう → 中間成果物で切れないか検討
• 「〜した上で、〜する」のように直列の依存関係がある → 前半と後半で分割
• 担当者が異なるスキルセットを求められる（例: 調査 → iOS 実装 → Android 実装）
• 「やること」に異なる領域が混在している（例: デザイン連携 + CI/CD 設定）
• チーム境界をまたいでいる → 境界ごとに分割してオーナーシップを明確にする（チームトポロジーの考え方）
• 実行に必要な相談先が 3 人以上 → スコープが広すぎる。認知負荷が高い

分割不要のサイン:

• 完了条件が 3 個以下で、1 つのゴールに収束している
• 1 人が 1〜2 日で完結できる
• 途中で切ると文脈が失われて効率が落ちる

分割する場合のルール:

• 分割後の各タスクにも「背景」を書く（親タスクへのリンクでも OK）
• 依存関係がある場合は順序と依存先を明示する（例: 「#123 完了後に着手」）
• 分割後のタスク同士が独立して完了できる粒度にする
• 分割後の各タスクに Accountable を設定する。 分割しただけで誰も見届けない状態にしない

分割後の品質チェック（INVEST）: 分割した各タスクが以下を満たすか確認する。満たさない場合は分割方針を見直す:

• Independent（独立）: 他タスクの完了を待たずに着手・完了できるか
• Negotiable（交渉可能）: スコープに調整余地があるか
• Valuable（価値がある）: このタスク単体で完了してもプロジェクトに価値があるか
• Estimable（見積り可能）: 担当者が「何日かかるか」を判断できる情報があるか
• Small（小さい）: 1〜2 日で完了できるサイズか
• Testable（検証可能）: 完了条件を第三者が「できた / できてない」を判断できるか

<!-- keep-ja -->

壁打ちで使う問いかけ例:

• 「完了条件が多いですが、前半の調査と後半の提案で分けられそうですか？」
• 「これ、調査フェーズと実装フェーズで分けたほうがスコープ明確になりませんか？」
• 「iOS/Android 両方入ってますが、別 issue にしたほうが並行で進められそうですか？」
• 「このタスク、1 人で何日くらいかかるイメージですか？ 3 日超えるなら分割を検討しましょう」
• 「このタスク、止まってたら誰が突きますか？ オーナーを決めておきましょう」

<!-- /keep-ja -->

Step 5: 期日と確認ポイントの設定

• いつまでに必要か、その根拠は何か（根拠があれば、クリティカルパス上なのかバッファがあるのか判断できる）
• 中間確認が必要なタイミングはあるか（最後まで放置して完了報告だけ来るパターンを防ぐ）

確認ポイントの密度は担当者の習熟度に応じて調整する（HIGH OUTPUT MANAGEMENT）:

• 担当者が領域未経験の場合: 着手時・中間（1日ごと）・完了時
• 担当者が経験ありの場合: 着手時・中間（1回）・完了時
• 担当者が熟練の場合: 完了時のみ（自走に任せる）

習熟度判定の目安: タスク領域での実務経験が 3 ヶ月未満→低、半年〜2年→中、2年以上→高。不明な場合は「中」として扱う。詳細は references/theory.md の HIGH OUTPUT MANAGEMENT セクションを参照。

Step 6: テンプレートに整形して出力

壁打ちの結果を references/template.md のテンプレートに流し込んで出力する。タスクを分割した場合は複数タスク分を出力し、依存関係も明記する。

出力形式は 3 段階。 ユーザーの指定がなければテキスト出力をデフォルトとする:

トリガー	出力形式	説明
指定なし / 「整理して」	テキスト出力	CLI 上にそのまま表示。壁打ちの延長でサクッと確認したいとき
「ファイルに書き出して」「md にして」	マークダウンファイル	.md ファイルとして Write で書き出し。チーム共有や後で参照したいとき
「issue にして」「起票して」	gh issue create	GitHub に issue として直接起票。運用に乗せるとき

gh issue create の例:

gh issue create \
  --title "タスクタイトル" \
  --body "$(cat issue.md)" \
  --assignee username \
  --label "enhancement" \
  --project "Project Name"

テンプレートの「責任 > 担当者」が記載されていれば --assignee に、「メタ情報」のラベル・プロジェクトは --label --project オプションに変換する。

起票テンプレート

→ references/template.md を参照。Step 6 でテンプレートが必要になった時点で読み込む。

運用上のポイント

• 全タスクにこのフォーマットを強制しない。 明らかに小さいタスク（typo 修正、設定変更等）はタイトルだけで OK
• 「背景」と「完了条件」だけでも書く。 全項目埋めるのが面倒でも、この 2 つがあればアウトプットの質は大きく変わる
• 起票者 ≠ 実行者を前提にする。 誰が取っても動ける状態がゴール
• 壁打ちで仕上げる習慣をつける。 抽象的なまま起票しない。壁打ちで 5 分かけて具体化するだけで、実行時のロスが大幅に減る
• Accountable を必ず 1 人決める。 全員の責任は誰の責任でもない。タスクを起票したら「誰が見届けるか」を明示する
• チーム境界を意識して分割する。 iOS / Android / 共通基盤など、領域をまたぐタスクは境界で切ったほうがオーナーシップが明確になる