Dev Step Plan Roadmap

Step 2: ロードマップの構築

[注意] Step 1が完了してから着手してください

ロードマップを構築します。 まず、ロードマップを構築する際の参考として、## ステップの例 セクションを読み、一般的なステップを把握してください。

次に、## フローチャート セクションに従って、タスクのロードマップを構築してください。

質問には以下のラベルがついており、以下の意味を持ちます。

• [Q]: (Questionの意) このラベルがついている質問は、場合によってはユーザーから指示を仰ぎ、それに従い答えを出してほしい質問です
  • ユーザーから指示を仰ぐかどうかの判断は、指定されたあなた(AI)自身の自律性に従って行ってください
  • ユーザーから指示を仰ぐ場合、 そこで応答を一旦終了し、次の会話からフローチャートを再開してください

フローチャートには、タスク分解に関する質問も含まれています。 タスク分解をする/しないの判断基準については ## タスク分解の判断基準 セクション記載の内容に従って判断してください。

またフローチャートには、「残りロードマップの再検討」というステップを追加して終了するよう指示している箇所があります。 これは、タスクの具体性が不足している状態で無理に全ロードマップを計画することを避けるためです。 一般に複雑なタスクでは、前段のステップで得られた情報や結論によって後段のアプローチが大きく変わる可能性があるため、最初の段階で後段のステップをすべて見積もることは困難です。 そのため、具体性の不足を解消するためのステップの追加後は「残りロードマップの再検討」をしてもらうようにしています。

Step 3: ロードマップの確定

[注意] Step 2が完了してから着手してください

決定した各ステップごとに、実施にあたって使うスキルを検討してください（スキルを使わない判断をしてもよいです）。 その後、以下の出力フォーマットで、提案内容を出力してください（使用予定のスキルについては、「なし」と答えてください）。 そして、この内容で問題ないかを必要であればユーザーに確認してください。

## ロードマップの提案
1. {ステップ名} ({使用予定のスキル}): {そのステップで行うこと}
2. {ステップ名}:({使用予定のスキル}) {そのステップで行うこと}
...

## 理由
- Q1: {回答した判定フローチャートの質問} → {yes/no などの判断}
  - 判断理由: {判断理由を簡潔に}
  - 追加したステップ: {追加したステップ名があれば記載}
- Q2: {回答した判定フローチャートの質問} → {yes/no などの判断}
  - 判断理由: {判断理由を簡潔に}
  - 追加したステップ: {追加したステップ名があれば記載}
...

{ロードマップの提案理由について、まとめのコメントがあればここに記載}

ユーザーに質問・確認するかどうかの判断基準

「必要に応じてユーザーに質問(確認)してください」という指示に対しては、あなたに指示された自律性の程度に従って、 ユーザーに質問(確認)をするかしないかを判断してください。

ユーザーから特に自律性の程度について指示が無かった場合は、該当の指示に直面した場合は基本的にユーザーに質問(確認)をとってください。

フローチャート

• Q1: タスクの背景と目的はどちらも整理されていますか？ 背景について、タスクのビジネス的な意義や必要性や、タスクが起票された経緯が整理されていてほしいです

  • yes: 次へ
  • no: 「背景・目的の整理」「残りロードマップの再検討」を追加し、終了

• Q2: あなた(AI)は今回のタスクについて、「対応方針を検討できる」もしくは「子タスクへの分解の検討ができる」 ほどの関連システム・関連技術の情報を持っていますか？

  • yes: 次へ
  • no: 「既存システム・関連技術の調査」「残りロードマップの再検討」を追加し、終了

• Q3: [Q] 必要であればユーザーに、今回のタスクの関連システムと関連技術を伝え、理解しているか質問して下さい。 得られた回答について、ユーザーは今回のタスクの関連システム・関連技術について理解していましたか？

  • 質問不要と判断した場合: 次へ
  • yes: 次へ
  • no: 「関連システムの理解促進」や「関連技術の理解促進」を追加し、次へ

• Q4: 今回のタスクを完了するために、複数の子タスクに分解して実行するほどのタスクだと思いますか？

  • yes(= 子タスクに分解すべき): 「タスク分解」というステップを追加し、終了
  • no(= このタスク1個で十分): 次へ
  • unknown(= 不明・まだ判断できない): 次へ

• Q5: 「要求定義」「要件定義」「対応方針決め」はすべて実施済み、もしくはやらないと決定済みですか？

  • yes: 次へ
  • no

    • Q5-1: [Q] 必要であればユーザーに、「要求定義」「要件定義」「対応方針決め」のうち、作業順序や必要性の有無について、意見を伺ってください 質問の意図としては、たとえば対応方針について「(そのほうがメリットが多いため) そもそも対応しない」という判断をする場合、 その前に詳細に要求定義や要件定義を行う必要はないため、そのような対応方針になる可能性があるのであれば、 「要求定義」「要件定義」よりも先に「対応方針決め」を行うことも検討したい、という意図です。 またこの質問をする際、あなた(AI)の意見も添えてください。

      • 質問不要と判断した場合: あなた(AI)の意見に従いステップを追加し、最後に「残りロードマップの再検討」も追加し、終了
      • 意見があった場合: その意見に従いステップを追加し、最後に「残りロードマップの再検討」も追加し、終了
      • 意見がなかった場合: 次へ

    • Q5-2: タスクの要求事項(ビジネス的に求められている事柄)はすでに定義されていますか？もしくは自明(= タスクの目的そのまま)ですか？

      • yes: 次へ
      • no: 「要求定義」を追加し、次へ

    • Q5-3: タスクの要件(どのような仕様にするか)はすでに定義されている、もしくは自明(= タスクの目的そのまま)ですか？

      • yes: 次へ
      • no: 「要件定義」を追加し、次へ

    • Q5-4: タスクの対応方針は自明、もしくはすでに決定されていますか？

      • yes: 次へ
      • no: 「対応方針決め」「残りロードマップの再検討」を追加し、終了

• Q6: 対応方針について、改めて、その対応方針を進めるにあたって複数の子タスクに分解して実行すべきと思いますか？

  • yes(= 子タスクに分解すべき): 「タスク分解」というステップを追加し、終了
  • no(= このタスク1個で十分): 次へ

• Q7: 対応方針について、その決定を踏まえて、改めて詳細事項を詰めるために、追加で要求定義(ビジネス的に求められている事柄)や要件定義(どのような仕様にするか)の整理検討は必要ですか？

  • yes: 「要求定義」「要件定義」のうち必要なものを追加し、次へ
  • no: 次へ

• Q8: [Q] 必要であればユーザーに、対応方針を進めるにあたって、どのようなステップに分けて進めるべきか意見を伺ってください その際、「ステップ分けの判断基準」セクションを参考に、あなた(AI)の意見も添えてください。 そして、意見があればそれに従いステップを追加してください。 質問不要と判断した場合、あなたの意見通りにステップを追加してください。

ステップの例

汎用

• 背景・目的の整理: なぜこのタスクが必要なのか、何を達成したいのかを明確にする
  • 推奨スキル: dev-step--clarify-background
• 既存システム・関連技術の調査: 今回のタスクに関連する「システムの仕組み」「技術・概念」「前例」などについて調査をし、意思決定の判断材料を揃える
• 既存システムの理解促進: 今回のタスクに関連するシステムの仕組みについて、ユーザーの理解を深めさせる
  • 推奨スキル: dev-step--explain-feature
• 関連技術の理解促進: 今回のタスクに関連する技術や概念について、ユーザーの理解を深めさせる
  • 推奨スキル: dev-step--explain-technology
• 要求定義: 要求を確定する。ユーザーに提案し、合意を得る
  • 推奨スキル: dev-step--clarify-requirements
• 要件定義: 機能要件・非機能要件を定める。要件をユーザーに提案し、合意を得る
  • 推奨スキル: dev-step--clarify-requirements
• 対応方針決め: 解決策を検討し、ユーザーに提案し、対応方針を決定する
  • 推奨スキル: dev-step--explore-solutions

開発系

• 技術選定: どの技術・ライブラリ・アーキテクチャを採用するかを決定する
• 設計: システム設計、データモデル設計、API設計などを行う
  • 推奨スキル: dev-step--design-architecture
• 実装計画: どのコード（テストコード含む）をどの順番で、どれくらいの段階を踏んで実装していくかを計画する
  • 推奨スキル: dev-step--plan-implementation
  • 判断指針
    • 実装が必要なタスクの場合、簡単なものであってもこちらのステップを追加し、そのあとに「実装」ステップを追加してください
• 実装: 実際にコードを書く
• 検証環境上で動作確認: 検証環境やステージング環境で実際の動作を確認する
  • 推奨スキル: dev-step--verify-implementation
• PR作成: 実装内容をPRにまとめる
  • 推奨スキル: dev-step--write-pr
• レビュー修正: レビューを受けてその対応を行う
• ドキュメント作成: README、設計書、運用手順書などを作成する

その他

• タスク分解: 課題を複数の子タスクに分解する
• 残りロードマップの再検討: 前段のステップで得られた結論をもとに、次に実施すべきステップを改めて検討する
  • dev-step--plan-roadmap スキルを使うこと

タスク分解の判断基準

タスクのステップが上流から下流に一直線に進まない場合、子タスクに分解したほうが良いです。 例えば「Aの調査→Aの設計→Aの実装→Bの調査→Bの設計→Bの実装」というステップがあった場合、 これは (Aの)実装から(Bの)設計という下流から上流に戻る流れが発生しているため、 「Aの調査→Aの設計→Aの実装」と「Bの調査→Bの設計→Bの実装」の2つの子タスクに分解すべきです。

ステップ分けの判断基準

ステップ分ける際は、以下の区切り方を参考にしてください。

• 意思決定単位で区切る（例: 「技術選定」→「設計」→「実装計画」）
• 依存関係の前後で区切る（例: 画面仕様の合意が前提なら「UI設計」→「実装」）
• 成功基準が変わる地点で区切る（例: 動作検証が目的なら「実装」→「検証環境で動作確認」）
• リスクが変わる地点で区切る（例: 新規ライブラリ採用なら「技術検証（PoC）」→「実装」）
• 合意/レビューが必要な地点で区切る（例: 設計レビューが必須なら「設計」→「設計レビュー」→「実装」）

チェックポイント

以下に気をつけてください。 もし間違えていることに気付いた場合、やり直してください。

• フローチャートに記載の各質問に対して、「終了」に到達した場合を除いて、途中でスキップなどしていないこと
• 逆に、「終了」に到達している場合は、そこでフローチャートを終了していること