プロダクトマネージャーアシスタント: 機能の特定と仕様書作成

このワークフローは、不足している機能を体系的に特定し、優先順位を付け、実装のための詳細な仕様書を作成するための体系的なアプローチを説明します。

1. プロジェクト理解フェーズ

• プロジェクト構造を確認して、その構成を理解する
• README.md およびその他のドキュメントを読んで、プロジェクトのコア機能を理解する
• 以下を検証することで、既存の実装状況を特定する:
  • メインエントリーポイント (CLI、API、UI など)
  • コアモジュールとその機能
  • 期待される動作を理解するためのテスト
  • プレースホルダー実装

ガイディングクエスチョン:

• このプロジェクトの主な目的は何か?
• ユーザーのどのような問題を解決しているか?
• 現在の実装にはどのようなパターンが存在するか?
• ドキュメントに記載されているが、完全に実装されていない機能はどれか?

2. ギャップ分析フェーズ

• ドキュメント記載の機能 のみ を実際の実装と比較する
• 実際の機能を欠く「プレースホルダー」コードを特定する
• ドキュメントに記載されているが堅牢な実装がない機能を探す
• ユーザージャーニーを考慮して、壊れている、または不足しているステップを特定する
• コア機能に焦点を当てる (ナイスツーハブ機能ではなく)

成果物作成:

• 潜在的な不足機能のリストを作成する (5〜7項目)
• 各機能について、以下を記入する:
  • 現在の実装状況
  • ドキュメントの参照
  • 不足している場合のユーザー体験への影響

3. 優先順位付けフェーズ

• 特定された各ギャップにスコアを付与する:

スコアリングマトリクス (1〜5段階):

• ユーザー影響度: 利益を受けるユーザーは何人か?
• 戦略的適合性: コアミッションに適合しているか?
• 実装可能性: 技術的複雑度は?
• リソース必要性: 必要な開発努力は?
• リスクレベル: 潜在的な悪影響は?

優先度 = (ユーザー影響度 × 戦略的適合性) / (実装努力 × リスクレベル)

成果物作成:

• スコアリングに基づいて、優先度が最も高い不足機能トップ3を提示する
• 各機能について、以下を提供する:
  • 機能名
  • 現在の状況
  • 実装されない場合の影響
  • その他の機能への依存関係

4. 仕様開発フェーズ

• 優先順位付けされた各機能について、詳細かつ実践的な仕様を開発する:
  • 哲学的なアプローチから始める: 複雑さより単純さを優先する
  • MVP機能に最初に焦点を当てる
  • 開発者体験を考慮する
  • 仕様を実装しやすい形に保つ

各機能仕様について:

1. 概要とスコープ

   • どのような問題を解決するのか?
   • 何が含まれ、何が明示的に除外されるのか?

2. 技術要件

   • 必要なコア機能
   • ユーザー向けインターフェース (API、UI、CLI など)
   • 既存コードとの統合ポイント

3. 実装計画

   • 作成または変更するキーモジュール/ファイル
   • アプローチを示すシンプルなコード例
   • 明確なデータ構造とインターフェース

4. 受け入れ基準

   • 完成をどのように判定するか?
   • どのような特定の機能が動作する必要があるか?
   • どのようなテストが成功する必要があるか?

5. GitHub Issue作成フェーズ

• 各仕様について、GitHub issueを作成する:
  • 明確で説明的なタイトル
  • 本文に包括的な仕様
  • 適切なラベル (enhancement、high-priority など)
  • 関連する場合は MVP 哲学を明示的に言及する

Issue テンプレート構造:

[機能名]

Overview

[機能とその目的の簡潔な説明]

Scope

[何が含まれ、何が明示的に除外されるのか]

Technical Requirements

[特定の技術的ニーズと制約]

Implementation Plan

[シンプルなコード例を含むステップバイステップのアプローチ]

Acceptance Criteria

[機能が完成したと判定するための明確な要件リスト]

Priority

[優先順位付けの根拠]

Dependencies

• Blocks: [このissueによってブロックされるissueのリスト]
• Blocked by: [このissueが依存するissueのリスト]

Implementation Size

• Estimated effort: [Small/Medium/Large]
• Sub-issues: [これが親issueの場合、サブissueへのリンク]

5.5 作業分配最適化

• 独立性分析

  • 各仕様を確認して、本当に独立したコンポーネントを特定する
  • 独立した作業ストリームを最大化するために仕様を再構成する
  • 相互に依存するコンポーネント間の明確な境界を作成する

• 依存関係マッピング

  • 回避不可能な依存関係のある機能については、明確なissue階層を確立する
  • 全体機能の親issueとコンポーネント用のサブissueを作成する
  • 「ブロック元」と「ブロック先」の関係を明示的に文書化する

• 作業負荷バランシング

  • 大規模な仕様をより小さく管理可能なサブissueに分割する
  • 各サブissueが1〜3日の開発作業を表すようにする
  • サブissue固有の受け入れ基準を含める

実装ガイドライン:

• GitHub issue リンク構文を使用して明示的な関係を作成する
• 依存関係ステータスを示すラベルを追加する (例: "blocked"、"prerequisite")
• スプリント計画を支援するために、各issueの推定複雑度/努力を含める

6. 最終レビューフェーズ

• 作成されたすべての仕様をまとめる
• 機能間の実装依存関係を強調する
• 論理的な実装順序を提案する
• 潜在的な課題または検討事項を記述する

このプロセス全体を通じて以下を忘れずに:

• 複雑さより単純さを優先する
• 機能する最小限の実装から始める
• 開発者体験に焦点を当てる
• 後で拡張できる基盤を構築する
• オープンソースコミュニティと貢献モデルを考慮する

このワークフロー実装は、機能がどのように仕様化および優先順位付けされるかの一貫性を維持し、ソフトウェアプロジェクトが思慮深く、ユーザー中心の方法で進化することを保証します。