novel-jp/learn-se-decompose

/learn-se-decompose — 成果物→タスク分解（04-01、必修）

成果物（Deliverable）を定義し、独立して検証可能なタスクに分解する演習です。

所要時間: 約 60 分 前提: /learn-ie-analyze（03-01）完了済み スキル対応: Specification Engineering（自律実行できる仕様）

---

Step 1: 導入

「Specification Engineering — AI が数時間から数日、迷わず実行できる『一貫した仕様』を書く最上位スキルです。

Prompt Craft（何を伝えるか）、Context Eng.（どんな情報環境を作るか）、Intent Eng.（なぜを記録するか）
の 3 スキルを統合し、『自律実行できる仕様』を構築します。
まだ全スキルを体験していなくても大丈夫です。この演習で統合的に使っていきます。

このセクションでは以下を学びます:
- 成果物をタスクに分解する技術
- 各タスクに完了条件を設定する方法
- AI が迷わず実行できるタスク記述の書き方」

---

Step 2: 成果物の定義

受講者に 1 つの成果物（Deliverable）を定義してもらう。

粒度の目安: ProjSight の成果物は、他ツールでいう Epic に近い粒度です。「ユーザー認証機能」「ブログ機能」のように、複数のタスクにまとまる単位で定義します。

テーマ例:

| テーマ | 概要 | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | A: ユーザー認証機能 | ログイン・サインアップ・パスワードリセット | | B: ブログ機能 | 記事の作成・編集・削除・一覧表示 | | C: ダッシュボード | KPI カード・グラフ・フィルタ機能 | | D: 自由テーマ | 受講者のプロジェクトから（テーマ A〜C の方が演習の例題と対応しやすく、学習効率は高めです。自由テーマを選ぶ場合、次の /learn-se-workflow では学習プロジェクト内で簡易的に実装します。実プロジェクトへの本格的な反映は別途行ってください） |

「まず成果物を 1 つ定義しましょう。
成果物とは『プロジェクトの最終的な出力物』で、他のツールでいう Epic に近い粒度です。
テーマを選んでください。自分のプロジェクトの成果物でも構いません。」

受講者が選んだら、ガイドが upsert_deliverable で ProjSight に登録する。

• title: 受講者が選んだテーマ名（例: 「ユーザー認証機能」）
• description の記入例: 「ログイン・サインアップ・パスワードリセットの3機能を提供する。OAuth 対応は将来スコープとし、初期はメール+パスワード認証のみ実装する。」

---

Step 3: タスク分解

レビュー観点の事前共有

「タスクを書き始める前に、品質チェックの観点を共有しておきます。
後のステップで /review-task を使ってスコアリングしますが、そこでは以下の 3 点を評価します:

1. **検証可能性** — 完了条件が「できた/できてない」を客観的に判定できるか
2. **独立性** — 他のタスクが未完了でも、このタスク単体で動作確認できるか
3. **具体性** — 対応内容が「〜を実装する」の1行ではなく、手順や範囲が明確か

この 3 観点を意識しながらタスクを書いていきましょう。」

良い分解 vs 悪い分解

テーマ B「ブログ機能」を例に、良い分解と悪い分解を比較します。

悪い分解（ありがちな失敗）:

| タスク | 問題点 | | ---------------------- | -------------------------------------------- | | ブログのバックエンド | 範囲が広すぎ。何をもって「できた」か判定不能 | | ブログのフロントエンド | バックエンドに依存。単体で検証できない | | テストを書く | 何の、どこまでのテストか不明 |

良い分解:

| タスク | 完了条件 | | ------------------------- | ------------------------------------------------------------------------------ | | 記事作成 API | POST /articles でタイトル・本文を送信し、201 が返る。DB にレコードが保存される | | 記事一覧画面 | /articles にアクセスすると、モックデータで一覧が表示される | | 記事一覧画面と API の結合 | 一覧画面が実際の API からデータを取得して表示される |

「『一覧は作成に依存するのでは？』と思うかもしれません。
良い分解では、一覧画面はモックデータで単体動作確認でき、API 結合は別タスクにしています。
『独立して検証可能』とは、他のタスクが完了していなくてもそのタスク単体でテスト・確認できるという意味です。
依存関係があること自体は問題ありません。重要なのは検証が独立にできるかどうかです。」

description 完成例

上の「記事作成 API」タスクを例に、description の全文を示します。実際に upsert_task に渡す内容です:

## 背景

ブログ機能の中核となる記事データの永続化が必要。
一覧画面・詳細画面はすべて記事データの存在を前提とするため、最初に API を整備する。

## 対応内容

- POST /articles エンドポイントの実装（タイトル・本文・著者IDを受け取る）
- バリデーション（タイトル必須・本文 10,000 文字以内）
- DynamoDB への保存処理と、作成された記事の JSON レスポンス返却

## 完了条件

- [ ] POST /articles にタイトル・本文を送信すると 201 が返り、DB にレコードが保存される
- [ ] タイトル未指定で 400 エラーが返る（バリデーション動作確認）
- [ ] レスポンスに記事 ID・作成日時が含まれる

この例のように、## 背景 / ## 対応内容 / ## 完了条件 の 3 セクション構成で書きます。完了条件はチェックリスト形式（- [ ]）で 2〜3 行が目安です。

タスクの記述と登録

「それでは、成果物を 3〜4 個のタスクに分解してください。

分解の基準:
- 1人が1セッションで完了できるサイズ
- 独立して検証可能 — 他のタスクが未完了でもテスト・確認できる
- 完了条件が明確 — 「できた/できてない」が客観的に判定できる」

各タスクの description は以下の構成で記述する（各フィールド 2〜3 行程度が目安）:

| フィールド | 説明 | 例 | | ------------ | ---------------------- | -------------------------------------------------------------------------------------- | | 背景 | なぜこのタスクが必要か | 「ユーザーがパスワードを忘れた場合に、自力でアカウントを復旧できる手段が必要」 | | 対応内容 | 具体的に何をするか | 「メール送信 API の実装、リセットトークンの生成・検証ロジック、リセット画面の作成」 | | 完了条件 | 検証可能な基準 | 「リセットメールが送信され、新パスワードでログインできる。トークンの有効期限は24時間」 |

制約やルールがある場合は、完了条件に含めて記述します（例: 「トークンの有効期限は24時間」）。

まず 最初の 2 タスク を定義してもらい、upsert_task(deliverableId) で登録する。先にレビューで基準の感覚をつかみ、残りのタスクに活かすための段階的フローです。

---

Step 4: 最初のレビューと残りのタスク

最初の 2 タスクを登録したら、ガイドが /review-task でレビューを実行する。

レビュー結果の読み方

/review-task は 10 点満点でスコアリングします。検証可能性・独立性・具体性の各観点で減点されます。よくある減点パターン:

• 完了条件が動詞で始まっていない — 「ログイン画面」ではなく「ログイン画面が表示される」と書く
• 対応範囲が曖昧 — 「認証まわりを実装」ではなく、具体的なエンドポイントや画面を列挙する

「まず最初の 2 タスクをレビューして、基準の感覚をつかみましょう。
私がレビューを実行しますね。」

• 各タスクのスコアを確認
• 8 点未満のタスクは改善を提案
• 特に以下を重点チェック:
  • 完了条件が検証可能か（「動詞 + 目的語 + 検証方法」になっているか）
  • タスクが独立しているか（他タスクへの暗黙の依存がないか）
  • 対応内容が具体的か（手順や範囲が明確か）

改善が必要な場合は受講者に修正してもらい、upsert_task で更新する。

「スコアの感覚がつかめましたね。同じ基準で残りの 1〜2 タスクを追加しましょう。」

残りのタスクを定義・登録したら、同様に /review-task でレビューする。全タスクが 8 点以上になるまで改善を繰り返す。

---

Step 5: 振り返り

「タスク分解は Specification Engineering の基礎です。

ポイント:
- 『独立して検証可能なサイズ』が鍵 — 大きすぎるタスクは AI も人も迷う
- 完了条件は『動詞 + 目的語 + 検証方法』で書く
- 制約の明記が AI の暴走を防ぐ — 制約なしは『何でもあり』と同じ
- 良いタスク分解は、そのまま AI への実装指示になる

今回の分解で一番迷ったのはどこですか？ その迷いが、次に活かせるヒントになります。

次の /learn-se-workflow では、ここで作ったタスクを実際に start_work → complete_work で遂行します。」

この演習自体のタスクを complete_work(taskId) で完了にする。学習カリキュラム上の進捗が自動で更新される。