はじめに

こんにちは、アドプラットフォーム事業アドテクノロジーdivのゼネラルマネージャーを担当しているりょーまです。
アドテクノロジーdivは、JANetやAppDriverといった自社広告プロダクトの開発を行う部門です。
プロダクト毎に複数のプロダクトチームが稼働しています。

今回は、プロダクトチームの生産性を高めるために設立したProdOpsチームについてお話します。

はじめに
プロダクト開発組織として目指す姿
プロダクトチームが直面する問題
ProdOpsチームがプロダクトチームを支援する
問題解消のための取り組み
- 意思決定フローの透明化と最適化
  - ぶっちゃけ、、誰がやってもいいんだけどね！
- プロダクト戦略の理解と浸透
  - CPF~PMFの説明
他にも解決しないといけないこと、やりたいことはたくさんある
まとめ

プロダクト開発組織として目指す姿

「良い体験を早くユーザーに届けたい」

大前提として、私たちがプロダクトを作る目的は、広告を通じて得た新しい発見・情報などからユーザーの「よかった」を創るためです。
言葉通り「よかった」と言えるような良質な体験を作ることがプロダクト開発組織の使命です。
しかし、「良い体験を作る」だけでは十分ではありません。それを「早くユーザーに届ける」こともまた重要な使命です。
なぜなら、ユーザーのニーズは常に変化しており、新たな解決策を早く提供することが、彼らの満足度を高めることに繋がるからです。
また、一度の開発で良い体験を提供できるほど、プロダクト開発は容易なものではありません。リリースを繰り返し失敗から学び、学びから新たなアイデアを生み出し、少しずつでも真に良い体験を創造していくことが求められます。

このように、プロダクト開発組織は良い体験を作ることと、早く届けることのバランスを取り続ける必要があります。
しかし、このような状態に到達するまでにはいくつかの問題を解決していかなければなりません。

プロダクトチームが直面する問題

よくある問題として、以下の二つ(そこから生まれるもう一つ)を提起します。

意思決定の遅延

意思決定の遅延はプロダクト開発の進行速度に直接的に影響します。これは主に、開発フローやプロダクトのフェーズについての共通認識がチーム内にないこと、またフローやフェーズ毎の権限設計が明確でないことに起因します。フローがないことでチームとして何をすべきかを都度考える必要が生じ、権限設計が明確でないことで誰がリードし誰が関与すべきかが不明確です。
結果として、必要ないほど多くの関係者が集まり、自明と思われる議論を繰り返すことがあります。また、逆に重要な決定が特定の個人によって一方的に行われ、必要な専門的観点が抜け落ち、議論が戻ってしまうこともあります。

プロダクト戦略の誤解

前提として、プロダクト戦略は以下の要素を含むと定義します：

プロダクトを通じて実現したいビジョン(世界観)
ユーザー価値とビジネス的収益のバランス

プロダクト戦略に当たるものが本当に全くなく開発が進むことは実際のところ殆どないと思います。しかし、チーム全体がプロダクト戦略を十分に理解した上で開発を進めているかというと、一気に難しくなるのではないでしょうか。多くの場合で「伝えた気でいる」「わかった気でいる」ということがあります。このような状況で開発を進めてしまうと、ビジョンや目的と乖離した機能が出来上がってしまったり、収益性だけを追求した結果ユーザービリティが悪かかったり(逆も然り)することが起きてしまいます。

意思決定の遅延とプロダクト戦略の誤解が引き起こす第三の問題：関心ごとの増加

意思決定が不安定かつ開発に戦略性がなくなると、いろいろなことを何度も何度も考える隙(機会)が生じてしまいます。
結果的にチームに複数の焦点が存在してしまい、並列で異なる関心ごとへの取り組みが動き出すことがあります。
このような状態をリソース効率とも呼びます。

やりたいことがたくさんあったり、選択肢が多いことは決して悪いことではありませんが、それを分け隔てなく行動に移してしまうのは結果的に自分たちに首を絞めることにつながってしまいます。

フロー効率性とリソース効率性について #xpjug | PPT から引用

※「リソース効率」とは、リソースを余すことなく使うことを優先することを指します。つまりは複数の事柄を並列に進めるため、結果的に全ての進行が遅れるという問題が起きやすい状態です。対し、「フロー効率」と呼ばれる状態があります。これはタスクやプロジェクトが直列に進行し、まず一つのことを完成することを優先します。プロダクト開発においては着想からユーザー提供までの速さ(リードタイム)がより重要となるため、基本的にはフロー効率が推奨されます。

ProdOpsチームがプロダクトチームを支援する

さて、このような問題に対してもプロダクトチームが自己組織的に解決できる事が理想です。
しかしながら、日々の開発に全力を注いでいるチームが、「プロダクトを作る」から「チームの動き方」に視点を変えることは決して容易ではありません。

このような状況において、助言や支援を提供するための専門部隊として設立したのが、ProdOpsチームです。
このチームは私（マネージャー）を始め、現場で活動しているPdM、デザイナー、エンジニアを含む職能横断チームとして設計されています。
職能横断とすることで、現場のプロダクトチームで起きている様々な事象や問題に対して、各ロールの専門的観点を踏まえた分析や考察が可能となります。 ProdOpsチームがプロダクトチームの外から客観的な質問をぶつけたり、フレームワークを用意したり、一緒に考えてあげたりすることで、チームが心理的安全かつ冷静に問題に向き合うことができるようになります。

ProdOpsチームの取り組みも基本的にはプロダクトチームと同様の動き方になります。
まず、各プロダクトチームが抱えるプロダクト開発における問題や課題を発見/定義し、それらをどのような戦略で解決していくのかという中長期的な方針を立てます。
その後は週に一度のプランニングを行い、各チームの状況や問題を共有し、どのような支援が必要かを計画します。
ProdOpsチームは現場メンバーも含まれているので、それぞれのメンバーが自身のチームに戻り、対策を打ちます(マネージャーの私も状況に応じて現場に入ります)。
ProdOpsチームを通じて現場と組織全体を連携させることができ、各チーム間での知識やノウハウも共有することも可能となります。

問題解消のための取り組み

さて、ここからは具体的な問題解消のための取り組みです。
基本的にはProdOpsがリードしながら現場チームと伴走的に動きます。
チームが慣れてきたらProdOpsチームはリードの役割を離れ、現場主導になっていきます。

意思決定フローの透明化と最適化

ステークホルダーマップの作成やRACI図の利用により、開発フローごとの役割と責任を明確に定義しています。
これにより、意思決定の流れと各ロールの責任範囲が明確になり、誰が何を決定するのかが明確になりました。

ステークホルダーマップはプロダクト開発における関係者を図示し、大まかなコミュニケーションラインと意思決定者を端的に表現したものです。
ワーク形式でプロダクトとセールスそれぞれの現場のメンバーを巻き込みながら作成します。
マップ形式で図示しながら一緒に話すことで、ブラックボックスになっていたところや複雑になっていたコミュニケーションラインの認識を合わせることができます。
ASISの作成時には事実とその中で起きている問題を炙り出すこと、TOBEの作成時には出来るだけシンプルにすることが重要になってきます。

RACI図は、プロダクト開発のフローとフロー毎の関係者それぞれ役割の表現するために採用しています。
考え方として、先にフローが来ます。誰が何やるか後回しで良いです。
チームとしてどういった進め方でプロダクトを作っていくのか。ここが本質です。
大前提、プロダクト開発はチームで進めることが大事です。しかし、全てのフローを全員でやるのは非効率であり、意思決定がどんどん遅くなります。
フロー毎に重要なロールを選定し、関わりの度合いをグラデーション的に示しています。

ぶっちゃけ、、誰がやってもいいんだけどね！

少々暴論かもしれませんが、本質的には誰が何をやっても何を決めてもいいと思っています。
役割を飛び越えた動きはイノベーションのきっかけになりますし、誰が何をやるという権限設計が絶対的に強くなってしまうと新しい観点やアイディアを潰す可能性があると思っています。
とはいえ、いきなりなんでもいいよというのは流石に動きづらいのと、やっぱり衝突が起きます。ということで、目印としてのステークホルダーマップやRACI図です。
この辺のバランスは本当に難しいですよね。
いずれ、このような目印がなくても柔軟かつ適切に動けるチームに進化していくことが理想だなと思っています。

プロダクト戦略の理解と浸透

プロダクト戦略がチーム全体に理解されていないという問題に対応するため、戦略作成のテンプレートをパッケージ化し、チームが戦略を考えやすくなる(理解しやすくなる)工夫を行っています。また、戦略をチーム全体で共有し理解するための会議設計も行なっています。これにより、全員が同じ方向を向いて働くことが可能となり、組織全体としての一体感と効率性を高めることができます。

特に重要視しているのが事業目標との連動です。プロダクトは言葉通り「製品」を指しているので、それを利用してどのような事業を展開したいのか、どのような成果を出したいのかという事業的背景は必ず把握する必要があります。ここがずれていると、事業として実現したいこととプロダクトとして表現することの間にずれが生じてしまいます。
戦略パッケージの活用は、PdMを中心に質問をしながら埋めていくイメージです。一人で悶々と考えているよりもずっと効率的なのと、パッケージに則って質問をぶつけるのはドメイン知識が少なくても出来ることです。

また、プロダクトのフェーズを意識した行動ができるようにCPF~PMFをベースにやることやロードマップを考えるようにしています。
よくある問題としてCPFがクリアしていない(ユーザーニーズが曖昧等)PSFに進行してしまったり、じきPSFが終わりを迎えるのにSPFの準備(機能のスケールや運用体制)が全くできていなかったりします。
中長期的に考え可能な限り先見性を持ったプロダクト開発をするためにためにパッケージに組み込んでいます。
最近では「まずCPFに取り掛からないとね」「そろそろPSFが完了しそう」といったフレーズをチームから聞くようになり、徐々にユビキタス言語化してきているのを感じています。

CPF~PMFの説明

CPF (Customer Problem Fit)：顧客の問題が明確であり、解決のための代替手段が明らかになっている。
FPF (Founder Problem Fit)：創業者(重要ステークホルダーや上長)が顧客の問題を理解している。(組織としてそれを進めることに同意し熱量を持てている状態)
PSF (Problem Solution Fit)：ソリューションが顧客の問題を解決する可能性があると証明される。
SPF (Solution Product Fit)：ソリューションを具体的なプロダクトやサービスとして持続的に提供できるようになっている。
PMF (Product Market Fit)：プロダクトが市場の需要に適合し、顧客から十分な価値を得られると感じられ、市場で成功する可能性が高いと証明される。

他にも解決しないといけないこと、やりたいことはたくさんある

今回はよくある問題として意思決定、および戦略に対して取り上げました。
他にもProdOpsの文脈で以下のようなことに取り組んでいる最中なので、また紹介できたらと思います。

プロダクトの優先順位付けがうまくできない：RICEスコアリングの活用
他ロールの領域やスキルの理解が足りない：相互理解文化の構築
プロダクトチームの評価が正しくできない：生産性の正確な定義
ProdOpsチームのメンバーが現場兼務で十分に集中できない：組織設計

まとめ

改めて言語化すると、意思決定とか戦略とか至極シンプルかつ基礎的なテーマではありますが、やっぱりここがチームが上手くいくための根幹かなって思います。
最終的には誰がやってもいいよねって極論かましましたが、そこに至るまでのステップは絶対に必要で、それを作っていくのがマネージャーの仕事です。
マネージャーの仕事なんですが、、今回の取り組みはひじょーーーにメンバーに助けられています。嬉しい。頼もしい。ありがとう。
引き続きみんなと良いプロダクト組織作りに励んで参ります。
ProdOps第二弾の投稿をお楽しみに。