PM組織と組織全体の改革と失敗
――石田さん1人から始まったChatworkのプロダクトマネジメントですが、現在はどのような組織になっているのですか。
山本：当社にはビジネス本部、プロダクト本部、コーポレート本部、ピープル＆ブランド本部の4つの部門がありますが、2021年1月よりプロダクトマネジメント室はプロダクトマネジメント部となり、プロダクト本部下にある状態です。現在は7人が所属し、開発やビジネスに携わる約160人と連携して仕事をしています。1プロダクトでそれだけの人数が関わるとなると、国内ではかなり大きいチームだと思います。
石田：現在は私がプロダクトマネジメント部を統括し、プロダクトマネージャーごとにグロース、API、コア機能といった専門領域を分担しています。少人数でカバーし合えるよう、スキルアップの目的もあって分担の入れ替えは頻繁に行っています。
――どのようにしてプロダクトマネージャーを採用・育成し、組織を変化させてこられたのか、経緯についてお聞かせください。
石田：まず私1人だったころ、PM組織としては山本の統括のもと、ビジネスディレクターが集まるビジネス本部の一部でした。開発チームとしては、プロジェクトごとにバックエンドやWeb、モバイル、デザインなどを担当するエンジニアを集めて、そこに私がプロダクトマネージャーとして横串に関わるというスタイルをとっていました。
当時の命題であるロードマップの作成・遂行を最優先としていたのですが、プロジェクトが終わると私の関与もそこで終わり、リリース後にユーザーからのフィードバックがあっても、それに対するアクションがとれなくなっていました。いわばオーナーシップが十分といえる状態ではなかったんですね。さらに1人ではロードマップの作成と遂行だけで手一杯で、それですら決定すべき事項が増えて、ボトルネックになりつつありました。本来プロダクトマネージャーを導入することで、意思決定スピードを上げ、デリバリー数を増やしていくはずが、本末転倒な事態になっていたんです。
山本：事業も拡大傾向にあり、大急ぎでプロダクトマネージャーの拡充を図ろうとしたのですが、日本では案の定プロダクトマネージャー経験者がなかなか見つかりませんでした。
そこで、技術の理解、ユーザーや市場の理解、コミュニケーションスキルやプロジェクトマネジメント力、企画力など、プロダクトマネージャーのスキルセットと思われるものの中で1つでも持っていて、かつプロダクトマネージャーに興味がある人というのを要件とし、Webディレクター経験者やUI設計者などを中心にプロダクトマネージャーとして採用することにしました。社内で学んでもらいながらPM組織をつくっていこうと考えたわけです。
石田：まず2018年に1人入って2人になりました。それまでのビジネス本部の一チームとしての位置づけでは、どうしてもビジネス寄りになり、エンジニアとの連携力が薄くなる傾向があったため、PM組織をビジネスとエンジニアの間をブリッジする中立的な部門として独立させ、CEO直下の部門としました。
そして、チャットやAPI、管理画面などの機能領域ごとにユニットを組んで、継続的な改善を行える体制を整えました。特定の機能領域に対するオーナーシップを持たせることで、機能ユニットごとの開発優先度を決め、スピーディな開発を行おうとしたのです。
しかし、専任のプロダクトマネージャーは私も含めて2人で、開発のマネージャーがプロダクトマネージャーを兼任、エンジニアも兼任ばかりだったこともあり、あまりうまく機能しませんでした。
一番の課題は、プロダクトのアーキテクチャがユニット通りに分かれていなかったことです。例えばチャットの改善を行おうとすると、他のユニットのエンジニアも関わる必要があり、結局別でプロジェクトチームが立ち上げざるを得ない状況になっていました。
山本：そうですね。職能別組織のままで機能別ユニットをつくるという、ちぐはぐな状況が問題だったと思います。
組織がある程度大きくなるとサーバー、フロントエンド、モバイルといった職能別に分けた方が開発の効率はいいんです。しかし、プロダクトマネージャーや事業の観点からいくと、それでは機能ごとのオーナーシップがなく、よろしくないということで機能別のユニットで改善を試みたわけです。
おそらく、どちらをオフィシャルな組織にして、どちらをプロジェクト的にするかが組織設計のキモになるのだと思いますが、当社の場合、職能別組織のままで機能別ユニットをつくってやろうとしたところ、いろんな対立が生じて混乱してしまったというわけです。
その結果、全社の目標設定とのコンフリクトもありました。OKR（Objectives and Key Results）を導入して、大きな目標をブレイクダウンして職能別の組織で目標を設定していたのですが、そこにユニットの目標が入っていなかったんです。つまり、マネージャーが各エンジニアに年間の目標設定を持たせているのに、そこにユニットのプロダクトマネージャーから全く違うコンテキストで作業依頼が入るとなると優先順位が混乱しますよね。当時は「ロードマップとユニット、どちらを優先するんですか」という会話がいたるところでありました。
石田：機能ユニット単位で顧客価値について語り、合宿で盛り上がっても、マネージャーから「ロードマップのこのタスクをちゃんとやれ」と言われてしまうんです。そして、どちらを優先するかと言ったら、人事評価に負けるわけです。ラインのマネジメントが強くて、機能ユニットチームが骨抜きになる……というのがこの時の失敗でした。
