想定読者
- タスクがいつまでも「進行中」のまま動かない経験がある人
- タスクを細かく分けたのに、逆に管理が大変になった人
- 「なんとなく」で順序を決めて、後で手戻りが発生した人
- エンジニア、PM、EM問わず、タスク管理で悩んでいる人
この記事でわかること
- タスク分解の3層構造（ゴール → MS → タスク）
- Done条件の書き方（成果物 × 確認者 × 基準）
- 「デモできるか？」でマイルストーンを切る方法
- 依存関係でタスクの順序を決める方法
- よくある失敗パターンとその対策
はじめに：「進行中」のまま動かないタスク、ありませんか？
プロジェクト管理ツールを開くと、何週間も「進行中」のまま動かないタスクが並んでいる。
「あれ、これって何をすればゴールなんだっけ？」と思って見直すと、タスク名は「ダッシュボード設計」の一言だけ。
あるいは、「タスクを細かく分解したほうがいい」と聞いて、やたら細かく分割した結果、チェックボックスを埋める作業が仕事になってしまった。
こういった経験、ありませんか？
試行錯誤の末にたどり着いたのが、「Done条件を先に書く」 というシンプルなルールです。
この記事では、私が実践している「タスク分解の型」を、具体例とともに紹介します。
タスク分解の3層構造
タスク分解は「ゴール → マイルストーン → タスク」の3層で行います。
ゴール（1つ）
「何が達成されたら、このプロジェクトは成功か？」
│
マイルストーン（3〜6個）
「ユーザーに届く価値の単位」
│
タスク（MS毎に5〜15個）
「1人が1〜3日で完了できる作業単位」
この3層構造を守ることで、「今どこにいて、何をすればゴールに近づくのか」が明確になります。
第1層：ゴール — 「成功とは何か」を定義する
プロジェクトに1つだけ。「成功とは何か」を定義します。
必須3要素
ゴールには次の3つが必須です。
| 要素 | 問い | 例 |
|---|---|---|
| 誰のため | 誰の何が変わる？ | 運用者がCR作成前に過去事例を参照できる |
| 定量指標 | 数字で測れるか？ | CR作成時間を30%短縮 |
| 期限 | いつまでに？ | 2026年Q3末 |
アンチパターン
よくある失敗例がこちらです。
- ❌ 「AIを導入する」 → 手段であってゴールではない
- ❌ 「効率化する」 → 何がどう変わるか不明
- ❌ 「なるべく早く」 → 判断基準がない
ゴールが曖昧だと、途中で方向性がブレます。
「何をもって成功とするか」を最初に決めることで、後のタスク分解がスムーズになります。
第2層：マイルストーン — 「デモできるか?」で切る
マイルストーンは「ユーザーに届く価値」の単位で切ります。
「デモできるか？」テスト
マイルストーンの切り方に迷ったら、次の問いを自問してください。
そのMSが完了した時点で、誰かに「見て、こうなった」とデモできるか？
- ✅ デモできる → 良いマイルストーン
- ❌ デモできない → まだ「作業の塊」。分割か統合が必要
例えば：
| MS名 | デモできるか？ | 判定 |
|---|---|---|
| ベクトルDB環境構築 | できる（「データが入って検索できる」と見せられる） | ✅ |
| DB設計完了 | できない（設計書だけでは価値が見えない） | ❌ |
| タグ付け + 検索機能 | できる（「タグで絞り込める」と見せられる） | ✅ |
「DB設計完了」だけでは価値が見えません。
「DB設計 + データ投入 + 簡単なクエリ実行」まで含めて1つのMSにすると、デモ可能になります。
サイズの基準
マイルストーンのサイズ目安はこちらです。
| 基準 | 目安 |
|---|---|
| 期間 | 1MS = 2〜4週間 |
| タスク数 | 5〜15個 |
| 超えたら | 中間MSに分割する |
4週間を超えると、フィードバックが遅れ、手戻りが大きくなります。
順序の決め方
マイルストーンの順序は、依存関係で決めます。「好み」や「やりやすさ」で決めてはいけません。
問い：「このMSがないと、次のMSは成り立つか？」
- 成り立たない → 先にやる
- 成り立つ → 並行可能
例：
- MS1.5（BQテーブル確認）とMS2（タグ付け実装）は並行で進められます
- MS3（検索機能）は、MS2とMS1.5の両方が終わらないと始められません
依存関係を無視して「やりやすい順」で進めると、後で「あれ、あのデータがないとこの機能作れない」となり、手戻りが発生します。
第3層：タスク — Done条件を先に書く
タスク分解で最も重要なルールは「完了条件を先に書く」です。
タスクの書き方
まず、悪い例と良い例を見てください。
❌ 悪い例
- [ ] ダッシュボード設計
何ができたら終わりなのか不明です。
「設計書を書けばいい？」「モックを作ればいい？」「レビューは必要？」
この曖昧さが、タスクが止まる原因です。
✅ 良い例
- [ ] ダッシュボード設計
Done: 画面モックがあり、運用者1人のレビューが通っている
これなら、「何をすれば終わりか」が明確です。
Done条件の3要素
Done条件には次の3つを含めます。
| 要素 | 問い | 例 |
|---|---|---|
| 成果物 | 何ができるか？ | 画面モックがある |
| 確認者 | 誰がOKを出すか？ | 運用者1人 |
| 基準 | 何を満たせばOKか？ | レビューが通っている |
この3つが揃っていれば、タスクの終わりが明確になります。
粒度の判断
タスクの粒度は「1〜3日で終わるか」で判断します。
そのタスクを見て、すぐ手を動かせるか？
├─ YES → 粒度OK
└─ NO → 「何を調べれば手を動かせるか？」で分解
例えば「ベクトルDB構築」というタスクを見たとき、すぐ手を動かせるでしょうか？
おそらく「どのDBを使うか調べないと」となるはずです。
それなら、タスクを分けましょう。
「調査」と「実装」を分ける
1つのタスクに調査と実装を混ぜると、見積もりが崩壊します。
❌ 悪い例
- [ ] ベクトルDB構築
これだと、調査に何日かかるか読めません。
✅ 良い例
- [ ] ベクトルDB選定（調査）
Done: 比較表があり、1つに決定済み
- [ ] ベクトルDB環境構築（実装）
Done: ローカルで起動し、テストデータが入っている
調査と実装を分けることで、「選定に2日、構築に1日」と見積もりが立てられます。
タスク分解の手順
では、実際にどう分解するか、手順を紹介します。
Step 1：ゴールから逆算する
上から順に考えてはいけません。「何があれば達成できるか？」で逆算します。
ゴール: 運用者がCR作成前に過去事例を参照できる
↑ そのために何が必要？
過去事例が検索できる
↑ そのために何が必要？
事例にタグが付いている
↑ そのために何が必要？
タグ設計が決まっている
この逆算により、「タグ設計 → タグ付け → 検索機能」という順序が自然に見えてきます。
Step 2：依存関係を整理する
次に、タスク間の依存関係を図にします。
この図から次のことがわかります：
- 矢印がないもの → 並行で進められる
- 矢印が集中するもの → ボトルネック（優先して着手）
例えば、「BQテーブル確認」と「タグ付け実装」は並行で進められます。
一方、「検索機能」はボトルネックなので、ここに人を厚く配置するといった判断ができます。
Step 3：各タスクにDoneを書く
最後に、全タスクに成果物・確認者・基準を書きます。
- [ ] タグ設計
Done: タグ一覧表があり、運用者1人のレビューが通っている
- [ ] BQテーブル確認
Done: 既存テーブルの構造ドキュメントがあり、不足カラムが特定されている
- [ ] タグ付け実装
Done: 100件のテストデータにタグが付いている
- [ ] 検索機能実装
Done: タグで絞り込み検索ができ、結果が表示される
- [ ] 運用者テスト
Done: 運用者2人が実際に使い、改善点リストがある
ここまで書けば、「何をすれば終わりか」が全員に明確です。
よくある失敗パターンと対策
私自身が踏んできた失敗と、その対策をまとめます。
| パターン | 症状 | 対策 |
|---|---|---|
| タスクが大きすぎる | 何日経っても「進行中」 | 「1〜3日で終わるか？」で分割 |
| タスクが細かすぎる | チェックを入れる作業が仕事になる | 「独立して価値があるか？」で統合 |
| 調査と実装が混ざる | 見積もりが崩壊する | 明示的に分ける |
| Doneが曖昧 | 終わったか不明 | 完了条件を先に書く |
| 全部直列に並べる | 遅い。1つ止まると全停止 | 依存関係を整理して並行可能なものを見つける |
| 「やりやすい順」で並べる | 依存先が終わっておらず手戻り | 依存関係で順序を決める |
特に「全部直列に並べる」は、経験の浅いメンバーがやりがちです。
依存関係を整理すれば、実は並行で進められるタスクが見つかり、プロジェクトが大幅に加速します。
チェックリスト
タスク分解が終わったら、次のチェックリストで確認してください。
- ゴールに定量指標があるか？
- 各MSは「デモできる」単位か？
- 1MSが4週間を超えていないか？
- 各タスクにDone条件があるか？
- 各タスクは1〜3日で終わるサイズか？
- 「調査」と「実装」が分かれているか？
- 依存関係が整理されているか？
- 並行で進められるタスクを把握しているか？
すべてYESなら、タスク分解は成功です。
まとめ
タスク分解の9割は「Done条件」の書き方で決まります。
- 成果物 は何か？
- 確認者 は誰か？
- 基準 は何か？
この3つを書くだけで、タスクが止まらなくなります。
そして、マイルストーンは「デモできるか？」で切り、順序は「依存関係」で決める。
この型を守れば、プロジェクトは確実に前に進みます。
私自身、この型を使うようになってから、「進行中のまま止まるタスク」がほぼなくなりました。
ぜひあなたのプロジェクトでも試してみてください。