mcpField
P
product-methodology

product-methodology

github.com/magnus919生産性15366 回インストール今日更新
リポジトリ

product-methodology について

product-methodology は、検証済みの根拠に基づいて進めるプロダクトチーム向けの、ホストに依存しないスキルです。RICE や MoSCoW などを参照し、優先順位付け、意思決定の記録、仕様作成、対象に応じた情報共有を支援します。

主な機能

  1. 01RICE と MoSCoW による優先順位付け
  2. 02機会と解決策の対応付け
  3. 03判断と根拠の記録
  4. 04構造化されたプロダクト仕様の作成
  5. 05対象に応じた伝達方法の調整

活用シーン

  1. 01機能提案や施策の優先順位を決める
  2. 02期間限定リリースの範囲を定める
  3. 03判断とトレードオフを記録する
  4. 04機能仕様やステークホルダー向け報告を作成する

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/magnus919/agent-skills --skill product-methodology

インストール後、Claude Code で/product-methodologyを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
evals/
evals.json
references/
decision-log.md
moscow-prioritization.md
opportunity-solution-trees.md
rice-framework.md
source-index.md
spec-template.md
stakeholder-communication.md
templates/
DECISION_LOG.md
SPEC.md

詳細

プロダクトの方法論

このスキルは、ディスカバリーが終わったところから始まります。ステークホルダーとの会話、競合調査、または利用データから得られた根拠を検証した後、優先順位付け、意思決定、仕様策定、コミュニケーションを進めるためのガイドとなります。

パイプライン

VALIDATED EVIDENCE → [PRIORITIZE] → [DECIDE] → [SPECIFY] → [COMMUNICATE]
                         |              |           |              |
                    RICE + MoSCoW   Decision log   Spec        Stakeholder
                                     template    template       briefs

リファレンスガイド

タスクに関連するリファレンスのみを読み込んでください。

リファレンス読み込むタイミング
RICE スコアリングReach × Impact × Confidence / Effort を使って、関連のない機能提案を比較する必要がある場合
MoSCoW 優先順位付け期間が限られたリリースのスコープが厳しく、Must／Should／Could／Won't の明確な境界が必要な場合
オポチュニティソリューションツリー問題領域が複雑で、解決策に飛びつかずに顧客のニーズと構築の判断を結び付ける必要がある場合
意思決定ログ後でトレードオフについて問われるような意思決定を行い、その背景と期待する結果を記録する場合
仕様テンプレートエンジニア、デザイナー、ステークホルダーが共通して利用できる要件ドキュメントが必要な場合
ステークホルダーとのコミュニケーション経営幹部、エンジニア、デザイナー、顧客に向けたメッセージを準備する場合。対象ごとに異なる形式が必要です
ソースインデックス出典、移植範囲、信頼できるソースへのリンクを確認する場合

テンプレート

テンプレート読み込むタイミング
意思決定ログのテンプレートフロントマター付きの、記入可能な意思決定ログが必要な場合
仕様テンプレートこの方法論で提示されるセクションを含む、記入可能な仕様書が必要な場合

使用条件

次の場合にこのスキルを読み込んでください。

  • 機能提案や取り組みのバックログに優先順位を付ける
  • 根拠を文書化する必要があるプロダクトの意思決定を行う
  • 機能やインテグレーションの仕様書を作成する
  • 対象者（経営幹部、エンジニア、デザイナー、顧客）に応じてプロダクトの意思決定を伝える
  • 顧客の機会を潜在的な解決策に結び付ける
  • 明確な境界を定めて、期間が限られたリリースのスコープを決める
  • ステークホルダーから「なぜこれに決めたのか」と尋ねられたが、記録がない

使用しない場合

  • ステークホルダーのディスカバリーとインタビュー — まず product-discovery を読み込んでください。このスキルは、検証済みの根拠を起点とするものであり、ステークホルダーとの生の会話を起点とするものではありません。
  • 範囲が定まっていないアイデアを賭けに仕立てる（アペタイト、ピッチ、サーキットブレーカー）— 優先順位付けのフレームワークを適用する前に、product-shaping を読み込んでください。このスキルは採択済みの賭けを扱うものであり、賭けを生み出すものではありません。
  • インタラクションデザイン、タスクフロー、状態／復旧モデル、ユーザビリティ調査の計画 — このスキルでスコープを決めた後に、product-design-and-ux を使用してください。このスキルは何を構築し、なぜ構築するかを決め、product-design-and-ux はユーザー向けの振る舞いを定義します。

作業方法

  1. 検証済みの根拠（インタビューのメモ、利用データ、競合分析）があることを確認します。ない場合は product-discovery に引き継いでください。検証済みの問題に対して、アペタイトや範囲を限定した解決策がまだ定まっていない場合は、まず product-shaping を通じて形にしてください。賭けが決まる前に、ピッチをタスクへ細分化してはいけません。
  2. 関連のない提案を比較する場合は RICE で優先順位を付け、期間が限られたデリバリーのスコープを決める場合は MoSCoW を使います。
  3. 背景、選択肢、根拠、期待する結果を含む構造化された記録として、意思決定を記録します。
  4. 問題、成功指標、スコープの境界、未解決の疑問、エッジケースを定義する仕様書を作成します。
  5. 対象者に必要な形式で意思決定を伝えます。経営幹部には推奨事項を先に、エンジニアには背景を先に、顧客にはまず耳を傾けます。

ルーティングの境界

CPO レベルのビジョン、ポジショニング、市場戦略、ポートフォリオの方向性には product-strategy を使用してください。戦略の方向性と検証済みのエビデンスがそろったら、戦術的な優先順位付け、仕様、意思決定ログ、バックログの順序付けはここに戻してください。このスキルではポートフォリオ戦略の意思決定を行わないでください。

ポータビリティ

このスキルは、意図的にホストに依存しない設計になっています。プロファイルシステム、出力形式、スクリプト、外部サービスは必要ありません。参照資料はパスを直接指定して読み込み、ホストエージェントの通常のファイル読み込み方法を使用してください。

出典

フレームワーク起源出典
RICEIntercom（Sean McBride、2016 年）intercom.com/blog/rice-simple-prioritization-for-product-managers
MoSCoWDai Clegg、Oracle UK（1994 年）。後に DSDM が採用Agile Business Consortium：MoSCoW prioritisation
Opportunity Solution TreesTeresa Torres（Product Talk）producttalk.org/opportunity-solution-tree
意思決定ログADR の実践とプロダクトマネジメントの慣例をもとに統合—
仕様テンプレート一般的な PRD の慣行をもとに統合—
ステークホルダーとのコミュニケーションプロダクトマネジメントにおけるコミュニケーションの実践をもとに統合—

このスキルは、コミット 867a555 の magnus919/hermes-profiles から移植されました。ポータビリティの境界については、references/source-index.md を参照してください。

コメント

Markdown 対応