フレームワーク活用ガイドひとことで言うと#
プロダクトの意思決定で迷ったとき、チーム全員が同じ方向に進むための判断基準を明文化したもの。シリコンバレーのプロダクトマネジメントの第一人者Marty Caganが体系化した考え方で、ビジョンと日々の開発判断をつなぐ橋渡し役になる。
押さえておきたい用語#
- Principle（プリンシプル）
- チームが共有する行動・判断の原則のこと。「速度よりも安全を優先する」のように、トレードオフの方向性を示す文として記述する。
- Product Vision（プロダクト ビジョン）
- プロダクトが2〜5年後に実現したい世界観を指す。プリンシプルはビジョンを日々の判断に落とし込む役割を持つ。
- Trade-off（トレードオフ）
- ある選択肢を取ると別の選択肢を犠牲にする二律背反の関係のこと。プリンシプルはこのトレードオフの判断を統一するために存在する。
- Alignment（アラインメント）
- チーム全体の認識や方向性が揃っている状態を指す。プリンシプルによってアラインメントが生まれ、意思決定のスピードが上がる。
プロダクトプリンシプルの全体像#
こんな悩みに効く#
- 機能の優先順位をつけるたびにチーム内で議論が紛糾する
- PMが不在のとき、開発チームが判断に困って作業が止まる
- プロダクトの方向性がメンバーによってバラバラになっている
基本の使い方#
プリンシプルはビジョンの下位概念。まずプロダクトビジョンが明確になっているか確認する。ビジョンが曖昧なままプリンシプルを作ると、根拠のないルール集になってしまう。
- ビジョンの例: 「すべての中小企業が、大企業と同じレベルのデータ分析を5分でできる世界」
- ビジョンが未策定なら、先にそちらから着手する
チームで「判断に迷った場面」「意見が割れた場面」を振り返る。そこにプリンシプルが必要なポイントが隠れている。
- 直近3〜6ヶ月の開発で揉めたテーマをリストアップ
- 例: 「初心者向けのシンプルさ vs パワーユーザー向けの拡張性」
- 例: 「リリース速度 vs バグのない品質」
良いプリンシプルは「AよりBを優先する」というトレードオフ形式で書かれている。誰もが賛成する当たり前のことは原則にならない。
- 良い例: 「機能の多さより、初回体験の分かりやすさを優先する」
- 悪い例: 「ユーザーにとって使いやすいプロダクトを作る」（誰も反対しない）
- 5〜10個に絞る。多すぎると覚えられない
プリンシプルは一人で決めるものではない。チーム全員で議論し、納得した上で共有ドキュメントにする。
- 合意プロセスを経ることで、メンバーの当事者意識が高まる
- Slackやドキュメントのヘッダーなど、すぐ参照できる場所に置く
- 四半期ごとに見直し、プロダクトのフェーズに合わなくなった原則は更新する
具体例#
月間アクティブユーザー12万人の家計簿アプリ。新機能の要望が月50件以上来るが、開発リソースは3人。何を作り、何を作らないかで毎週2時間以上の議論が発生していた。
チームが策定したプリンシプル（抜粋）:
| # | プリンシプル | 背景 |
|---|---|---|
| 1 | 自動化 > 手入力 | ユーザーの継続率は自動連携ありで78%、手入力のみで23% |
| 2 | 初月の体験 > 長期利用者の便利さ | 新規ユーザーの60%が初週で離脱している |
| 3 | 見える化 > 細かい管理 | 「ざっくり把握したい」層が利用者の72% |
導入から3ヶ月後、機能判断の会議時間は週2時間から30分に短縮。プリンシプルに照らせば、議論の大半は5分で結論が出るようになった。
従業員120名のプロジェクト管理SaaS。日本市場でARR 8億円に到達し、海外展開を始めた段階。日本チームと海外チームで「ローカライズの深さ」について毎回衝突していた。
策定したプリンシプル:
- 共通基盤の一貫性 > 各国固有のカスタマイズ — コア機能は全世界共通。個別対応はAPIとプラグインで吸収する
- 英語ドキュメント > 各国語ドキュメント — 設計書・仕様書はすべて英語で書き、翻訳は後工程
- 法規制対応 > UI要望 — GDPRやインボイス制度など法的要件は最優先。「このボタンの色を変えたい」は後回し
この3つを明文化したことで、海外拠点のPMが東京の承認なしで判断できる範囲が広がった。意思決定のリードタイムは平均5営業日から1営業日に短縮。プリンシプルに沿った判断であれば、事後報告で済むルールも同時に導入している。
人口5万人の温泉地で観光DXに取り組む創業2年目のスタートアップ。エンジニア2名、デザイナー1名。自治体・旅館・観光客の3者からそれぞれ違う要望が飛んでくる状態だった。
全員で半日のワークショップを開き、5つのプリンシプルを策定。
- 「観光客の体験 > 旅館の管理効率」 — 管理画面より予約体験を優先
- 「スマホで完結 > PC対応」 — 観光客の**91%**がスマホ経由
- 「リアルタイム情報 > 網羅性」 — 今空いている温泉を出す方が、全旅館の一覧より価値がある
ワークショップ前は、自治体の要望で「観光統計ダッシュボード」を作りかけていた。プリンシプルに照らして一度棚上げし、観光客向けの「今すぐ入れる温泉」検索機能にリソースを集中。リリース1ヶ月で利用者が800人から3,200人に増え、結果として自治体へのレポート材料も自然に集まるようになった。
やりがちな失敗パターン#
- 誰も反対しないことを原則にしてしまう — 「ユーザーファーストで行く」は原則ではなくスローガン。トレードオフが含まれていないプリンシプルは判断基準として機能しない
- 作って満足し、運用しない — ドキュメントに書いて終わりにすると、3ヶ月後には誰も参照しなくなる。意思決定の場面で「プリンシプル3番に照らすと…」と口に出す文化を意識的に作る必要がある
- 数が多すぎる — 15個も20個も作ると覚えられず、結局使われない。5〜10個に絞り、本当にトレードオフが発生するポイントだけを選ぶ
まとめ#
プロダクトプリンシプルは、ビジョンと日々の開発判断をつなぐ判断基準のセット。良いプリンシプルはトレードオフを含み、「AよりBを優先する」形式で書かれている。チーム全員で合意し、意思決定の場で実際に参照することで初めて機能する。プロダクトの規模やフェーズが変わったら見直すことも忘れずに。