gen-specs-as-issues

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

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

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 テンプレート構造:

[機能名]

概要

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

スコープ

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

技術要件

[具体的な技術的ニーズと制約]

実装計画

[簡単なコード例を交えた段階的なアプローチ]

受け入れ基準

[機能が完了したと見なすための要件の明確なリスト]

優先度

[優先順位付けの根拠]

依存関係

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

実装規模

• 推定工数: [小/中/大]
• サブイシュー: [これが親イシューの場合、サブイシューへのリンク]

5.5 作業分担の最適化

• 独立性の分析

  • 各仕様をレビューし、真に独立したコンポーネントを特定します
  • 仕様をリファクタリングし、独立した作業ストリームを最大化します
  • 相互依存するコンポーネント間に明確な境界を作成します

• 依存関係のマッピング

  • 避けられない依存関係を持つ機能については、明確なイシュー階層を確立します
  • 機能全体の親イシューを作成し、コンポーネントごとにサブイシューを作成します
  • 「blocked by」および「blocks」の関係を明示的に文書化します

• 作業負荷のバランス調整

  • 大きな仕様をより小さく管理可能なサブイシューに分割します
  • 各サブイシューが 1～3 日分の開発作業を表すようにします
  • サブイシュー固有の受け入れ基準を含めます

実装ガイドライン:

• GitHub のイシューリンク構文を使用して、明示的な関係を作成します
• 依存関係のステータスを示すラベルを追加します（例: 「blocked」、「prerequisite」）
• スプリント計画に役立てるため、各イシューの推定複雑度/工数を含めます

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

• 作成したすべての仕様を要約します
• 機能間の実装依存関係を強調します
• 論理的な実装順序を提案します
• 潜在的な課題や考慮事項を記載します

このプロセス全体を通じて覚えておいてください:

• 複雑さよりもシンプルさを優先します
• 動作する最小限の実装から始めます
• 開発者体験に焦点を当てます
• 後から拡張できる基盤を構築します
• オープンソースコミュニティとコントリビューションモデルを考慮します

このワークフローは、私たちのアプローチを具現化したものであり、機能がどのように仕様化され、優先順位付けされるかの一貫性を維持するのに役立ち、ソフトウェアプロジェクトが思慮深く、ユーザー中心の方法で進化することを確実にします。