01-03 ゼロから書く演習。テーマを選び、タスク記述をゼロから3件作成する。
テーマを選び、タスク記述をゼロから 3 件作成する演習です。
所要時間: 約 60〜80 分
前提: /learn-pc-rewrite 完了推奨（必修ではない）
スキル対応: Prompt Craft（指示の構造化）
「ここまでは既存のタスクを「改善」してきました。
この演習では、ゼロから自分でタスクを書きます。
以下のテーマから 1 つ選ぶか、自分の業務から題材を持ってきてください:
A. 社内の備品管理アプリ
B. チーム用の日報ボット
C. ファイルの自動バックアップスクリプト
D. 自分の業務から（自由テーマ）
実務経験がまだ少ない場合は、A〜C がおすすめです。
経験のある方にはテーマ D を推奨します。自分の業務に近いほど、学びが実務に直結します。
※ テーマ D を選ぶ場合: 学習プロジェクトのデータはプロジェクトメンバーのみ閲覧可能ですが、
機密情報は避け、架空化・抽象化した題材の使用を推奨します。」
選んだテーマで成果物（Deliverable）を定義する。
「まず、このテーマの成果物を定義しましょう。
成果物とは、完成させたい"もの"の単位です。
タスクが個々の作業なら、成果物はそれらをまとめた「何を作るか」の全体像にあたります。
ProjSight では成果物ごとにタスク進捗率が自動算出されるため、進捗管理の基本単位になります。
粒度は「1〜2 週間で完成できる機能単位」を目安にしてください（Jira の Epic に近い概念です）。
タイトルと説明を考えてください:
- タイトル: 短く明確に（例: 「備品管理 Web アプリ MVP」）
- 説明: このプロダクト/機能の目的と主な利用者」
受講者の回答を受けて upsert_deliverable(projectId, title, description) で登録。
「この成果物を実現するために、3 つのタスクに分解してください。
分け方に正解はありませんが、よく使われる切り口があります:
- 機能ごと: 入力画面 / データ保存 / 通知機能
- 工程ごと: 設計 / 実装 / テスト
- レイヤーごと: フロントエンド / API / データベース
自分のテーマに合う切り口を選んでください。
各タスクには以下の 4 要素を含めてください。
この 4 要素は、AI が正しく作業するために必要な最小限の情報セットです
（01-02 で扱った品質基準を構造化したものです）:
- ## 背景 — なぜこのタスクが必要か
- ## 対応内容 — 何をするか（箇条書きで具体的に）
- ## 完了条件 — チェックリスト形式で検証可能な基準
- ## 制約 — やらないこと・スコープ外
まず 1 件目から始めましょう。タイトルと内容を教えてください。」
各タスクについて:
upsert_task(projectId, title, deliverableId, description) で登録ペース: 1 件目は丁寧にフィードバック、2〜3 件目は受講者のペースで。
「3 件のタスクが完成しました！
品質をセルフチェックしてみましょう。
まず、あなた自身で各タスクに ○/△/× を付けてみてください。
判定の基準はこちらです:
- ○ = 第三者がこの記述だけを読んで作業に着手できる
- △ = 意図は伝わるが、曖昧な部分があり確認が必要
- × = 情報不足で、何をすればよいかわからない」
受講者がまず自分で ○/△/× を付けた後、/review-task の観点でスコアリングを提示する:
| チェック観点 | タスク1 | タスク2 | タスク3 |
|---|---|---|---|
| 背景（なぜやるか） | ○/△/× | ○/△/× | ○/△/× |
| 対応内容の具体性 | ○/△/× | ○/△/× | ○/△/× |
| 完了条件（検証可能） | ○/△/× | ○/△/× | ○/△/× |
| 制約（やらないこと） | ○/△/× | ○/△/× | ○/△/× |
受講者の自己評価と AI の判定を比較し、ズレがあれば一緒に理由を考える。
upsert_task で更新）「お疲れさまでした。
ゼロから書いてみて、改善するときと比べてどう感じましたか？
難しかった点、意外とスムーズだった点があれば教えてください。」
受講者の回答を受けて、以下のポイントを補足する:
「次の /learn-pc-review では、他の人が書いたタスクに
フィードバックを出す練習をします。
人に指摘することで、自分の基準もさらに明確になります。」