プロダクトマネージャーに依存しない体制へ
意思決定のコンフリクトについて、鈴木氏は「事業では当たり前に発生する問題であり、必要な情報を持って判断できる人間がその場にいれば解決することだ」と強調する。しかし、当時のClassiは、責任を持つべきメンバーが適切な情報を持っておらず、意思決定ができない状況だった。また、チーム内部の目標に集中しすぎるがあまり、個別最適な判断に陥る傾向もあった。
この状況を解消するために、「自分がイニシアチブを握り、コンフリクトを解消する手段も考えた」と鈴木氏。しかしこの方法では、PdMと鈴木氏、どちらの意見に従えば良いのかという混乱を招く。PdMが“お飾り”になってしまうわけだ。
妙案は浮かばないまま、事業面では停滞が続き、エンジニア組織には不満が溜まっていく。「当時のログを見返すと、葛藤の記憶が蘇る」と話す鈴木氏のもとに、さらなるトラブルが発生した。進行していた機能開発プロジェクトが「炎上」したのだ。
炎上のセオリーに則り、プロジェクトのスコープ調整に着手した鈴木氏。しかし、プロジェクトを深く理解するにつれ、事態はさらに深刻であると判明した。ビジネス要求の実現可能性が考慮されないままリリース日だけが決められており、機能開発に失敗すれば、顧客の解約が避けられない状態だった。
「前述の通り、当時の営業組織は強いプレッシャーにさらされていた。その結果、リリース予定の機能を前提に顧客提案が行われており、その機能が搭載できなければ『話が違う』とお叱りを受けてしまうことが容易に想像できた」。
「プロダクトマネジメントが全く機能していなかった」というこの事件は、鈴木氏をはじめとしたメンバーの奔走により、一応の収束を見せる。しかし組織に与えたダメージは大きく、メンバーの疲弊と組織への不信感を募らせる結果となった。
このような事態を二度と引き起こさないためにはどうすればよいのか。一連の出来事から鈴木氏は、Classiの状態を「正常なプロダクト開発ができず、メンバーの不満も蓄積する危機的な状況」と再認識。ハレーションも覚悟で、組織とプロセスの根本的かつ大胆な改革を決意した。
鈴木氏がエンジニアリングマネージャーたちと議論を重ね、解決策として打ち出したアプローチは二つだ。
まず、プロダクト組織、営業組織が同じ目標を共有し、一丸となって進める体制を作ること。次に、ビジネス要求の実現可能性を事前に検証し、合意の上でプロダクトの意思決定を行う仕組みを構築することだ。
前者を実現するために、Classiでは全社目標を「売上・利益目標の達成」に絞った。プロダクト組織と営業組織が共通の数値目標を共有することで「一蓮托生、運命共同体」となる構造を作り上げたのだ。
ただし、これだけでは目標に具体性が不足する。確実に施策へとつなげるために、Classiでは「契約継続率」と「新規顧客獲得数」を全社目標の指標に選んだ。これを各チームがブレークダウンすることで、施策に落とし込んでいくわけだ。
このような改革を行った結果、各チームでの議論の質も高まった。「この機能を活発に利用している顧客は、サービス利用を継続しやすい」「だとすれば、この機能を使ってもらうために何ができるか？」のように、指標をもとにした会話や分析がカジュアルに行われるようになった、と鈴木氏は手応えを語る。
一方で、ビジネス要求の実現可能性を検証するための仕組みについては、「1人のプロダクトマネージャーが、スーパーマンのように『プロダクトマネジメントトライアングル』（※）の全てを担うのは非現実的だ」という考えから、複数人がそれぞれの専門性を活かして補い合う体制を目指した。
※プロダクトの成功に必要な3つの要素「ビジョン・戦略」「ユーザー価値」「技術実現性」を示す概念。3つのバランスを取ることで、顧客ニーズに応えつつ、技術的に実現可能で持続可能なビジネスを構築する考え方。
もとを正せば、プロダクトマネジメントが機能しなくなった原因は、意思決定を行うべき人（PdM）が必要な専門知識や背景知識を持っていないことだった。初めから専門家を集めることで、意思決定がスムーズに行われることを目指したのだ。
