はじめに
プロダクトが増加し、複数のプロダクトチーム体制になると、次のような歪みが出てきます。
意思決定の分散と情報のサイロ化
- プロダクトごとにプロダクトマネージャー（PM）の数が増える
- 各プロダクトマネージャーが、独自にユーザー調査・データ分析・ロードマップ運営を行い、情報がサイロ化してしまう
- 組織として「どのプロダクトに、なぜ投資するのか」が見えづらくなる
ツール／プロセスの乱立
- チームごとに使うツール（ユーザーインタビューの記録、A/Bテスト、分析基盤、ロードマップ管理など）がバラバラになる
- 似たようなイベントや実験が重複し、ナレッジが共有されない
- チーム単位で個別最適化されるため、組織全体としてスケールしたときに非効率が生じる
プロダクトマネージャーの役割が「雑務」で圧迫される
- ユーザーインタビューの調整、ダッシュボードの更新、実験結果の整理、全社向け資料作成などの「運営・事務・調整」系のタスクが増加する
- その結果、プロダクトマネージャーが本来フォーカスしたい「戦略」「課題定義」「優先順位づけ」に十分な時間を割けない
組織横断で「プロダクト運営の質」を上げたい
- データドリブンな意思決定を標準化したい
- 実験やフィードバックを収集し、プロダクトへ反映するサイクルを高速化したい
- しかし、これを各プロダクトマネージャーに個別に任せると進め方がバラバラになり、再現性が低くなる
こうした課題に対して、「プロダクトマネジメントの “運営・仕組み化” に特化した役割」を置き、チーム横断で標準化し、スケールさせようという背景から「プロダクトオペレーション（Product Operations）」という役割が生まれました。
営業組織の効率を高めるSales Opsチームや、マーケティング業務の効率を高めるMarketing Ops（MOps）チームと同じ構造だと考えるとイメージしやすいでしょう。
プロダクトオペレーションマネージャーは、プロダクト開発のプロセスを最適化する役割を担います。その目的は、チームが最高の成果を上げられるよう支援し、顧客に価値を届け、会社の目標達成に貢献するプロダクトを構築できるようにすることです。
以下では、プロダクトオペレーションを機能させるために必要な3つのポイントを解説します。
1. 一貫性と自律性のバランスをとる
プロダクトチームが増えるにつれ、それぞれのチームの実践方法が異なるのは、ある意味では自然なことです。しかし最終的には、こうしたバラバラな働き方が、プロダクトチーム同士、あるいはプロダクトと他の業務機能との間に摩擦や連携の断絶を生み出します。
チームが最善の成果を上げるには、プロセスに対する一定の裁量と自律性が必要です。その上で、プロダクトオペレーションの中核的な課題は、チームの自律性とプロセスの整合性とのバランスを取ることです。
そのために、まず以下の3つの領域の標準化に注力し、共通言語を構築します。
- 企業の目標（ゴール）：すべてのチームが、企業の目標に確実に貢献していることを確認する。
- 優先順位づけ：ディスカバリーフェーズ（課題・機会の探索プロセス）を標準化する。
- 各アイデアに対する労力／投資レベル：「小さい」「大きい」といった規模感の定義を共通化し、すべてのチームに浸透させる。
アトラシアンでは、これらを支えるために次の3つのフレームワークを活用しています。
- OKR（目標と主要な結果）
- ディスカバリーのステージ定義
- 労力の分類のための「巨岩（Boulder）」「岩（Rock）」「小石（Pebble）」
OKRを活用して戦略的優先事項を伝達する
どの企業にも目標があります。例えば「経常収益10億円の達成」や「顧客満足度スコアの20%向上」といったものです。しかし、こうした目標が社内で十分に可視化・共有・更新されていないケースがよくあります。
そこで、OKRの導入は、プロダクトオペレーションにおいて最も効果的な実践手法の一つとなります。OKRは、大局的な戦略を具体的で測定可能な目標へ落とし込み、チームが自ら責任を持って取り組める仕組みを提供します。
ディスカバリーのステージ：構想・探索・開発・影響
アトラシアンでは、アイデアのライフサイクルを次の4段階で管理しています。
- 構想（Wonder）
- 探索（Explore）
- 開発（Make）
- 影響（Impact）
このサイクルを通じて、すべてのプロダクトアイデアを精査して構想し、実行に移します。全員がこのフレームワークを理解しているため、「このアイデアはいまどの段階にあるのか？」と聞けば、その進捗状況をすぐに把握できます。
アイデアのライフサイクルについて共通言語を持つことで、チーム内やステークホルダーとの優先順位づけの議論が、より生産的になります。
- 構想：アイデアが解決し得る問題や機会、そのアイデアに影響を受ける対象や重要性について議論する。
- 探索：顧客からのフィードバックによって検証されるソリューションにたどり着くまで、潜在的な解決策を考案する。
- 開発：ソリューションを構築し、十分な顧客ニーズを満たすまで反復改善する。
- 影響：ソリューションをローンチし、その結果を測定し、望ましい成果が得られるまで継続的に改善する。
各段階は必ずしも直線的に進むわけではありません。例えば、ソリューションのテストを通じて問題の本質が明らかになり、探索段階のアイデアが再び構想段階に戻ることはよくあります。また、何度試行しても有効なアプローチが見出せない場合、そのアイデアをいったん放棄することも想定されています。
アイデアを労力に応じて「巨岩」「岩」「小石」に分類する
ここでいう「労力（Effort）」とは、アイデアを実行するために必要な投資・リソースのレベルを指します。多くのチームでは、アイデアがすでに開発段階（デリバリーフェーズ）に入って初めて、必要な労力を評価しがちですが、それでは手遅れになることが少なくありません。
アイデアを実行に移す前に、その実現に必要なものを把握しておけば、チームはリソースをより適切に配分できます。
アトラシアンでは、アイデアを次の3つに分類しています。
- 巨岩（Boulder）：大きな投資を要し、リターンも大きい可能性があるが、不確実性も高い（例：大規模な新規投資、新製品、大規模なエンジニアリングプロジェクト）
- 岩（Rock）：リスクが比較的少ない中規模の投資（例：新機能、新しいオンボーディング実験、フィードバックに基づく大きめの再設計）
- 小石（Pebble）：小規模で、通常はシンプルな投資（例：小さなUX改善など）
