ProductZine(プロダクトジン)

ゼロからのPM組織立ち上げ、組織改革でぶつかった壁――Chatworkのプロダクトマネージャー育成とは?

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/01/07 11:00

 プロダクトの迅速な開発・改善が求められる中、「プロダクトに責任を持つ人=プロダクトマネージャー(PM)」に注目が集まっている。「顧客中心主義」に基づき、ユーザーやマーケットとコミュニケーションをし続け、同時にテクニカルチームと連携し、プロダクトを最適な形へ進化させ続けることがその役割だ。クラウド型ビジネスチャットツールを開発するChatworkでは、ゼロからプロダクトマネジメント組織を立ち上げ、試行錯誤を経て洗練された組織として確立させてきた。後編では、組織化する際の課題と乗り越え方、組織的なプロダクトマネージャーの育成と成長などについて、代表取締役CEOの山本正喜氏、プロダクト本部プロダクトマネジメント部マネージャーの石田隼氏にお話を聞いた。

目次

PM組織と組織全体の改革と失敗

――石田さん1人から始まったChatworkのプロダクトマネジメントですが、現在はどのような組織になっているのですか。

山本:当社にはビジネス本部、プロダクト本部、コーポレート本部、ピープル&ブランド本部の4つの部門がありますが、2021年1月よりプロダクトマネジメント室はプロダクトマネジメント部となり、プロダクト本部下にある状態です。現在は7人が所属し、開発やビジネスに携わる約160人と連携して仕事をしています。1プロダクトでそれだけの人数が関わるとなると、国内ではかなり大きいチームだと思います。

Chatwork株式会社 代表取締役CEO 山本正喜氏
Chatwork株式会社 代表取締役CEO 山本正喜氏

石田:現在は私がプロダクトマネジメント部を統括し、プロダクトマネージャーごとにグロース、API、コア機能といった専門領域を分担しています。少人数でカバーし合えるよう、スキルアップの目的もあって分担の入れ替えは頻繁に行っています。

Chatwork株式会社 プロダクトマネジメント室マネージャー 石田隼氏
Chatwork株式会社 プロダクト本部プロダクトマネジメント部マネージャー 石田隼氏

――どのようにしてプロダクトマネージャーを採用・育成し、組織を変化させてこられたのか、経緯についてお聞かせください。

石田:まず私1人だったころ、PM組織としては山本の統括のもと、ビジネスディレクターが集まるビジネス本部の一部でした。開発チームとしては、プロジェクトごとにバックエンドやWeb、モバイル、デザインなどを担当するエンジニアを集めて、そこに私がプロダクトマネージャーとして横串に関わるというスタイルをとっていました。

立ち上げ期のプロダクトマネージャーと組織の構造
立ち上げ期のプロダクトマネージャーと組織の構造

 当時の命題であるロードマップの作成・遂行を最優先としていたのですが、プロジェクトが終わると私の関与もそこで終わり、リリース後にユーザーからのフィードバックがあっても、それに対するアクションがとれなくなっていました。いわばオーナーシップが十分といえる状態ではなかったんですね。さらに1人ではロードマップの作成と遂行だけで手一杯で、それですら決定すべき事項が増えて、ボトルネックになりつつありました。本来プロダクトマネージャーを導入することで、意思決定スピードを上げ、デリバリー数を増やしていくはずが、本末転倒な事態になっていたんです。

山本:事業も拡大傾向にあり、大急ぎでプロダクトマネージャーの拡充を図ろうとしたのですが、日本では案の定プロダクトマネージャー経験者がなかなか見つかりませんでした。

 そこで、技術の理解、ユーザーや市場の理解、コミュニケーションスキルやプロジェクトマネジメント力、企画力など、プロダクトマネージャーのスキルセットと思われるものの中で1つでも持っていて、かつプロダクトマネージャーに興味がある人というのを要件とし、Webディレクター経験者やUI設計者などを中心にプロダクトマネージャーとして採用することにしました。社内で学んでもらいながらPM組織をつくっていこうと考えたわけです。

石田:まず2018年に1人入って2人になりました。それまでのビジネス本部の一チームとしての位置づけでは、どうしてもビジネス寄りになり、エンジニアとの連携力が薄くなる傾向があったため、PM組織をビジネスとエンジニアの間をブリッジする中立的な部門として独立させ、CEO直下の部門としました。

 そして、チャットやAPI、管理画面などの機能領域ごとにユニットを組んで、継続的な改善を行える体制を整えました。特定の機能領域に対するオーナーシップを持たせることで、機能ユニットごとの開発優先度を決め、スピーディな開発を行おうとしたのです。

機能領域ごとのユニット+PM室の組織構造
機能領域ごとのユニット+PM室の組織構造

 しかし、専任のプロダクトマネージャーは私も含めて2人で、開発のマネージャーがプロダクトマネージャーを兼任、エンジニアも兼任ばかりだったこともあり、あまりうまく機能しませんでした。

 一番の課題は、プロダクトのアーキテクチャがユニット通りに分かれていなかったことです。例えばチャットの改善を行おうとすると、他のユニットのエンジニアも関わる必要があり、結局別でプロジェクトチームが立ち上げざるを得ない状況になっていました。

山本:そうですね。職能別組織のままで機能別ユニットをつくるという、ちぐはぐな状況が問題だったと思います。

 組織がある程度大きくなるとサーバー、フロントエンド、モバイルといった職能別に分けた方が開発の効率はいいんです。しかし、プロダクトマネージャーや事業の観点からいくと、それでは機能ごとのオーナーシップがなく、よろしくないということで機能別のユニットで改善を試みたわけです。

 おそらく、どちらをオフィシャルな組織にして、どちらをプロジェクト的にするかが組織設計のキモになるのだと思いますが、当社の場合、職能別組織のままで機能別ユニットをつくってやろうとしたところ、いろんな対立が生じて混乱してしまったというわけです。

 その結果、全社の目標設定とのコンフリクトもありました。OKR(Objectives and Key Results)を導入して、大きな目標をブレイクダウンして職能別の組織で目標を設定していたのですが、そこにユニットの目標が入っていなかったんです。つまり、マネージャーが各エンジニアに年間の目標設定を持たせているのに、そこにユニットのプロダクトマネージャーから全く違うコンテキストで作業依頼が入るとなると優先順位が混乱しますよね。当時は「ロードマップとユニット、どちらを優先するんですか」という会話がいたるところでありました。

石田:機能ユニット単位で顧客価値について語り、合宿で盛り上がっても、マネージャーから「ロードマップのこのタスクをちゃんとやれ」と言われてしまうんです。そして、どちらを優先するかと言ったら、人事評価に負けるわけです。ラインのマネジメントが強くて、機能ユニットチームが骨抜きになる……というのがこの時の失敗でした。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 伊藤 真美(イトウ マミ)

    エディター&ライター。児童書、雑誌や書籍、企業出版物、PRやプロモーションツールの制作などを経て独立。ライティング、コンテンツディレクションの他、広報PR・マーケティングのプランニングも行なう。

  • 岡田 果子(編集部)(オカダ カコ)

    2017年7月よりCodeZine編集部所属。慶応義塾大学文学部英米文学専攻卒。前職は書籍編集で、趣味・実用書を中心にスポーツや医療関連の書籍を多く担当した。JavaScript勉強中。

バックナンバー(新着順)

連載:プロダクト開発の先進事例に学ぶ、キーパーソンインタビュー

もっと読む

All contents copyright © 2021-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5