20チーム規模で見えた「健全に見える病」

井上：今日、他のセッションではAIの話が結構盛り上がっているかなと思うのですが、このセッションではもっと泥臭くて、もっと明日から使えそうなものを話していきたいなと思います。タイトルは「ボトムアップの限界を越える、20チームを束ねる“Drive Map”」です。会社としてのビジョンや目標は結構明確にあるけれども、なんとなく現場とうまく噛み合っていないな、というところがあって、そこの話を今日していきたいと思います。

私のキャリアは出発点がエンジニアです。新卒で大手企業向けのECサイト・通販サイトを作る企業で、サイトの構築、導入後の売上支援などをしてきました。プログラマーから始まって、プロジェクトリーダー、プロジェクトマネージャーという形でSIに近い形でやってきて、最終的にはパッケージ自体を作っているサービス開発部の責任者を務めていました。新卒で入って20年、ずっと同じ会社にいて、去年の4月にこのカオナビに入社しました。

最初に転職してぶつかった壁ですが、前職は出社がメインの会社だったので、今のフリーアドレスでテレワーク中心の環境では、そもそも誰がどこに座っているか分からないですし、誰が何をしているか分からない、という状態でした。自社のプロダクト「カオナビ」を「社員辞書」として活用して、いろんな人に話を聞いたりして、この1年過ごしてきました。

もう1つ、前職での自分の最大の価値だった「社内調整力」「空気を読む力」、「誰にどう話をしたら話がうまく進むか」みたいなところがゼロになったというのが、この1年の中で結構きつかったところです。これからの経験から自分の強みって何なんだろうと、その時結構考えたのですが、会社を変えて越境した時に何が通用したのかなと考えると、やっぱり背景を言語化する力みたいなところは力になったかなと思っています。

簡単にカオナビをご紹介させてください。タレントマネジメントシステム、ちょっと聞き慣れない方もいらっしゃるかもしれませんが、このパイオニアでありリーディングカンパニーになっています。利用企業数もアクティブで4,500社を超えています。

プロダクトとしては「個の力を最大化し、組織をもっと強くする」をビジョンとして、人材データの一元化・可視化を中心に、評価、目標設定、配置、育成、分析、最近は労務・打刻、採用管理のシステムまで支援するプラットフォームを提供しています。機能が多岐にわたるプロダクトで、それぞれの機能領域を担当する開発チームがあります。

今日の話の一番大事な数字、開発チームが20チームあります。起きる問題の質が、3チーム・4チームでやっている時とこのチーム数では、だいぶ変わってきます。そこをどう束ねてきたか、というのを今日お話しします。

入社して見えた「健全に見える病」というところで、結構病気と一緒なんですけど、自覚症状がないものが一番怖いなと自分も思っています。熱が出たり調子が悪ければ病院に行くと思うのですが、自覚症状がないままで進行する病気みたいなものが一番あったので、その話をさせてください。

カオナビの開発組織は、まず会社としてのビジョンや戦略が結構明確で、中長期の計画も事業戦略もしっかり立てています。方向性自体は全社ミーティングで共有されていて、経営陣がしっかり戦略を語ってくれるという状況にあります。2つ目に、ボトムアップで自律的というところ。トップダウンで「これやりなさい」みたいなのがあんまりない会社なので、開発チームも営業も含めて、チームが主体的に施策を考えて立案・実行しています。3つ目に、エンジニア組織がすごい優秀です。技術力も高くて開発のプロセスも成熟しています。

ここまで聞くと結構理想的な状態に聞こえるかなと思うのですが、何が問題だったのかというと、問題がなかったのではなく、問題が見えづらい状況だったのかなと自分的には考えています。

入社して3ヶ月にかけて、各チームのリーダー、プロダクトマネージャー、エンジニアと1on1を重ねていきました。ロードマップを見せてもらったり、チームの判断基準を聞いていく中で、結構構造的な問題があと感じたところがあります。

20チームそれぞれが「認識」と「正義」で走っているところです。各チームに施策の優先順位の根拠を聞くと、返ってくる答えがバラバラでした。「競合がこの機能を出したから」「特定のお客さんから強い要望があるから」、どれも間違っていないのですが、全体として見た時に、会社の戦略に対して最適な順番になっているかというと結構疑問が残る部分がありました。

2つ目はプロダクト戦略のオーナーが事実上不在ということです。カオナビはプロダクト「カオナビ」1本でやっているので当たり前なのですが、事業戦略はある、でもそれをプロダクトとしてどう実現するかを全体最適の視点で判断して優先順位をつける役割の人が、明確に誰、というのがいなかった状態です。プロダクトを全体に俯瞰してみた時に、「今期はこっちを優先すべき」とはっきり言える人がいなかったかなと思っています。

3つ目が、機能を作ることがゴール化していたというところです。当社は1年に1回、既存のお客さん向けにロードマップを公開していて「今期こんなものを作りますよ」とやっているのですが、それを明確にしているからこそ、目先の機能を作ることがゴール化していました。これは現場の意欲が低いという話ではなくて、むしろ逆で、みんなすごく一生懸命開発してくれています。ただ、その開発が事業にどうインパクトを与えるのかが構造的に抜け落ちていたかなと思っています。

ボトムアップの限界 — ピラミッド構造の歪み

わかりやすく図に起こすと、左側がカオナビを作っていた初期フェーズのイメージです。開発チームが3チーム・4チームの時は、三角錐・四角錐のようなイメージで、会社としてのビジョンがあって、その間に戦略がある。チーム数がまだ少ないので「これを作ろう」と誰かが言えば、みんなが意見を交換し合ってできる状況だったかなと思います。ボトムアップでも正確なピラミッドができ上がるようなイメージです。

問題が右側で、今は開発チーム20チームいます。20チームになるとビジョンの解釈がチームごとに微妙にずれていて、同じ言葉を聞いても受け取り方が違うようなイメージです。さらに難しい問題として、この機能は今ゼロイチで作っている、この機能は1→10で作っている、この機能は10→100で作っているという形で、機能の成熟度が全然違うという状況がありました。

その間に翻訳レイヤーがいないと、ビジョンと各チームの間をつなぐ層がしっかりしていないと、各チームが独自の解釈で独自の方向で積み上げていくので、結構いびつなピラミッドになるなというところです。いびつになると、プロダクトの価値が正確にお客さんに伝わらない、ということが起きるかなと思います。

プロダクトプランニング本部の設立と3つの施策

この構造的な問題に対して実際にやったことは、結構シンプルで、その間にあった翻訳レイヤーを構築するということです。翻訳レイヤーと聞くと、作ったプロダクト戦略をスプレッドシートやパワポにまとめて1枚で展開するイメージがあるかもしれませんが、戦略を言語化し、仕組み自体を設計し、コミュニケーションの型を作る、という3つをセットにして進めました。

入社して、先ほどお話ししたような課題の構造が見えてきた段階で、今、開発本部長をやっているメンバーがいますので、その課題感を共有しました。開発の中にも「何かちょっとズレが発生しているな」と感じている方もいたので、後押ししてくれた形になっていて、2025年10月に、もともと開発組織にいたPdMのメンバーも含めて、プロダクト戦略とデリバリーを専門に扱う「プロダクトプランニング本部」を作っています。入社して半年ぐらいのタイミングです。

この本部を起点に大きく3つの施策を推進しています。1つ目はプロダクト戦略を明確化して言語化するというところで、事業戦略とプロダクトがどうつながっているのかを明確にします。2つ目がDrive Mapの設計と導入で、全部のチームが自分の位置を確認できる共通の地図を作っていきました。3つ目が「報告から相談へ」というところで、会議体・コミュニケーションの転換です。仕組みを作るだけでは動かないので、日常のコミュニケーションの型を変えました。

プロダクト戦略の明確化・言語化

1つ目のプロダクト戦略の言語化です。事業戦略は中長期的にお客さんにどんな価値を届けたいか、数字としてどんな売上を出すかというものがあるのですが、それが開発チームにとっての判断基準になっていませんでした。事業目的として「売上を伸ばす」「市場シェアを拡大する」「お客様にこんな価値を届けたい」みたいなものはあっても、じゃあ開発として何を優先すべきか、しっかり翻訳されていない状態でした。

1つ目は事業戦略の開発観点への翻訳。プロダクトとしてどういう戦略を取ることが具体的に事業貢献できるのかを言語化します。ここはかなり抽象度を下げて、開発チームが読んで判断できるレベルまでしっかり落とし込むことをやっています。

2つ目は優位性（モート）の明示。当社でないとできないことは何なのか、当社だからこそ提供できる価値は何かを言語化して、これも全チームに共有しています。これがないと競合が何か出すたびに振り回されることになるので、当社として何が一番優位性が高いかを言語化します。

3つ目が「やること・やらないことの基準」。判断に困った時にこれを基準にしてください、というものです。これによって、もともと結構自律的に動いている開発チームでも、各チームが自律的により判断しやすい状況を作ります。

4つ目が顧客セグメント別の課題と攻め方の共通言語化です。事業戦略があって、プロダクトの戦略があって、もちろん営業の戦略もあるのですが、それがちゃんと一気通貫でつながっている必要があります。どのセグメントのお客さんがどういう課題を持っていて、当社としてそれをどう支援できるかを各機能で横断で共有しました。これを最初にやったのは、後で説明するDrive Mapの前提になるからです。翻訳元のテキストが曖昧だと、いくら翻訳してもいいものにならないので、ここの言語化に結構力を入れてやっています。

Drive Map — 全チームの「共通地図」

ここが今日の話の主役なので丁寧に説明させてもらいます。Drive Mapは一言で言うと、指示書ではなくナビゲーションです。最近のカーナビを想像してもらうと、「この道を走れ」と命令するんじゃなくて、「あなたはここにいて、目的地はここで、このルートがいいんじゃないですか」と提示している。実際はドライバーが自分で道路を走って状況を察知して、違うルートを選んだりするわけです。「今どこにいて、どこに向かっているか」を同じフォーマットで語る共通地図、というのがDrive Mapの位置づけです。

設計で意識したことは3つあります。各チームに「なぜやるか」を紐づけること、全チーム同一フォーマットで書くこと、情報の非対称性をなくすことです。チームによって書き方が違うと比較も議論もできず、結局「隣のチーム、何やってるかわからない」という状況になるので、そこも重視しました。

構造としては、左から順に、まずプロダクト戦略があって、戦略を受けて開発部門にOKRを作ってもらって、それぞれ各開発チームがその下にいて、各開発チームに「チームのゴール」を埋めてもらいました。ここを単純に短期スパンや中長期スパンだけじゃなくて、半年・1年・1年半後という3つのゴールを設定してもらうようにしました。

なぜ1年半後があるかというと、目先の半年だけだとどうしても今できることに注力しがちなので、1年半後を意識させることで、プロダクト戦略と開発チームの内容がどう接続されているかをチーム自身で考えるようにという設計です。

次に、追いかける指標を定義してもらいました。施策や開発内容が何をもってうまくいったか、を各チームに考えてもらうようにしました。上から指標を見て「有数がどう」「利用率がどう」というところではなくて、チーム自身がこの数字が動けば、自分たちの施策が当たっていると実感できるものを、自分たちで考えてもらうことを意識して設計しています。

最後が事業KPIとの接続です。導入数、オプション付帯率、事業の数字をしっかり握ってもらう形でやっています。目先の開発タスクだけではなく、中期の目標を意識させ、何をもって成功とするかを各チームが自分で考えて自分で重ねる状態を作ったのが、このDrive Mapです。

導入プロセスで結構大事にしたのは、「あるべき」「理想論」で作らないことを意識しました。理由は明確で、自分が去年4月に入社した中途入社の、外から来た人間なので、押しつけをしてしまってもなかなか浸透しないからです。長年このカオナビのプロダクトを牽引してきたメンバーと一緒に設計し、これまでの開発文化やチームが大事にしてきたこともしっかりヒアリングして、過去の経緯を大事にしながらやっています。

次に大きな判断があったのは、こういう新しい施策は「1チームだけ」「2チームだけ」やりたくなるのですが、特にパイロットチームを設けずに一気に全チームに導入したことです。新しい施策なので、一気に導入しておかないと「隣のチームで今試している状態」のように見えてしまうので、そこを結構意識しました。

ドキュメントを配って「読んでおいてください」という形ではなくて、20チーム規模の開発組織に浸透させるために細かい泥臭いことをやっています。まずタウンホールミーティングのような形でプロダクト戦略の全体像とDrive Mapを導入する背景、「なぜ今これが必要なのか」を共有しました。その上で20チーム分、全部ミーティングして、30分から1時間かけてやっています。

ボトムアップの文化を大事にした組織で、あえてトップダウン的にやるという場を作るというところは、自分的にはメッセージだったかなと思っていて、「全員で同じ方向を向く必要がある」というシグナルを、あえてトップダウン方式でやりました。

その上で全チームとの個別対話を、20チーム分やります。読み合わせだけじゃなくて、しっかり対話する。1チーム当たり長いと1時間〜1時間半やりながら、チームの今の背景がどうなっているか、戦略との接続を一緒に考えよう、というところを丁寧にやっていきました。これをやると、上から降ってきたフレームワークではなく、自分たちで考えて自分たちの言葉で書く、そのプロセスを一緒に歩むことが、結構浸透の鍵だったかなと思っています。完璧な状態で一気に展開はできないので、ヒアリングを重ねながら設計して、導入してから改善することを随時やってきています。

「報告」から「相談」へ — コミュニケーションの転換

3つ目の施策は、こういう仕組みを作っても日常のコミュニケーションが変わらないと、なかなか機能しないので、人が毎日やっている会話の型を変えていきました。

まずやめたことから言うと、全チームが集まるロードマップの共有会議があって、それは各チームが今ゴールに対して進捗かどうか、みたいな進捗報告でした。そのやり方を変えています。

進捗報告は実際、今80%進んでいる、いつリリース予定です、というのはSlackで非同期で全然問題ないので、そこで事前にやってもらって、当日のミーティングでは報告や相談、つまり「今、課題が何で、どことのコミュニケーションで問題があるか」を中心に会話するようにしています。全員が集まる時間は短くして、関係するチーム同士は深い議論をする形にしました。隣のチームが何をやっているかがより見えるようになったので、非同期＋必要なチーム同士の居残り方式でやってきました。

プロダクトの共創ボードというところで、開発と企画側だけじゃなく、営業、カスタマーサクセス、サポートのメンバーもいるので、その声を構造化してDrive Mapにしっかり接続する仕組みも作っています。現場のお客さんの声がバラバラ入ってくるのではなくて、「この声はDrive Mapのこのチームのこの施策に効く」というのを明確にできるように設計しました。

良かったのは、フロントメンバーの営業やサクセスのメンバーが「自分たちの声がちゃんとプロダクトに反映される」も声として届いている形になっているので、ここも実感できていいかなと思っています。

3つの壁と、トップダウンが生んだボトムアップの加速

うまくいかなかったこともたくさんあります。大きく3つの壁があったのですが、1つ目は「権限のない中での影響力」で、これが最初にぶつかった壁です。私はプロダクトプランニング本部長ですが、開発チーム20チームの上司ではない。Drive Mapを描く側にはいますが、それを実行するチームは私の部下ではないので、「これをやれ」とは言えない。正しいと思うことを言っても指示者ではない、という状況です。入社半年の人間が組織の仕組みを変えようとしているので、当然の反応だと思っています。

なので、人の役に立つところから始めるところでやっていきました。相手が困っていることを聞いて、自分にできることで貢献していく。戦略を立てているチームの壁打ち相手になったり、他チームとの調整を引き受けたり、進めたいとなったらコストもかかるので経営と話をして橋渡しもしてきました。役割としては、WhatとWhyはプロダクトプランニングが持つ、実際にいつまで何を作るかは開発チームが決める、ときれいに線引きできたところは意識的に設計したかなと思っています。

2つ目が開発文化との融合です。企画側がプロダクト戦略として「こうするべきだ」と言っても、開発の観点では技術的負債があったり、作る上で技術的に難しい部分があったりするので、「理想はわかるけど現実的じゃないな」みたいな反発はもちろん起きます。これは文化による違いかなと思っていて、先ほど話した役割の線引きが効いてきました。10月にプロダクトプランニング本部を立ち上げる前の3ヶ月間だけですが、開発部長も兼務させていただいて、実際に開発の現場でどういうプロセスでどう開発しているかを見たところがあったので、それが結構効いたかなと思っています。

3つ目が組織構造の限界です。これは個人の努力ではどうしようもない内容だったかなと思っています。カオナビのプロダクトマネージャーは20チームの中に埋め込み型で、それぞれのチームにいます。なので、各開発チームのメンバーは、その機能については詳しいけれど、隣の機能についてはあまり詳しくないということが起きがちで、自分のチームの優先順位を語れるけど、プロダクト戦略全体を見て語れるPdMが育ちにくい環境になっていたのも1つ課題かなと思っています。ここは構造の問題なので、構造を変えるしかないというところで、組織体制の変更を今実施しています。プロダクトマネージャー組織を、各機能ごとではなく各領域ごとに戦略を立てるPdMとして再編しています。ここはまだ発展途上です。

成果の話もさせてください。まだ1年なので、数字として劇的に何が変わったかをお見せできる状態ではないのですが、明らかに変わった兆しを3つ挙げます。1つ目、大きな変化なのですが、ちょっと逆説的で、トップダウンの構造を入れたことで、ボトムアップが加速しました。

ミドルクラスのPdMの自律性がかなり目に見えて上がりました。Drive Mapで戦略の「なぜ」が明確になったことで、施策の判断にかかる時間が短くなりました。以前は「これやっていいですかね？」みたいな確認が都度あって、そのたびに何を基準に判断してどう判断したかでコミュニケーション時間がかかっていたのですが、それはなくなりました。

2つ目が、若手PdMの変化。目の前の機能開発が「点」で開発していたメンバーが、「今作っている機能は半年後にどうなっているか、1年半後にどうなっていたいか」「今自分がやっている開発が事業の数字のどこを動かしているか」がわかったことで、目の前の機能開発というところからだいぶ目線が動いたかなと思っています。

3つ目がチーム間の対話が自然発生したというところ。横のチームが何やっているかがわかりやすくなったことで、「あのチームが今やっている施策、うちの機能と関連ありそうだから、ちょっとチーム間でコミュニケーションしてみよう」というコミュニケーションが生まれています。トップダウンで構造を作ったことで現場の自律的な動きがむしろ加速して、対立したわけじゃなく、正しいトップダウンが正しいボトムアップの文化を生む、というのが今回の学びかなと思っています。

改めて自分の1年を振り返ると、5つのフェーズに分かれたかなと思っています。最初の3ヶ月は「聞く」、自分の最大の武器が通用しなくなったので、まず聞く側に徹底しました。次の3ヶ月が「体現する」で、開発部長を兼務して開発の現場に入り込んでコードの議論やスプリントレビューを一緒に見ました。その次から「描く・変える」で、Drive Mapの設計や会議体の再設計をしていきました。直近の3ヶ月は「組み替える」で、PdM組織の再編、役割分離の定義をしています。この4月から「つなげる」で、CPOとしてやらせていただいています。

これは別にタイトルを取ることが目的だったわけではなくて、先ほどお話しした「権限のない中での影響力」みたいな壁にぶつかった時に、「構造的な課題を解くにはやっぱりポジションに紐づく正当性が必要だ」というところがあったので、経営と現場をしっかりつなぐ役割を自分が果たしたいなという思いで、今回引き受けています。

今日持ち帰っていただきたいことを3つにまとめます。1つ目は、ボトムアップ文化は翻訳レイヤーなしでは規模に耐えられないというところ。2つ目が、Drive Mapは管理ツールではなく共通言語であるというところ。3つ目が、ボトムアップを生かすためにあえてトップダウンの構造を作る、というところです。これがこの1年の振り返りでやったことになっているかなと思っています。

なんとなく今、事業とプロダクトが噛み合っていないなと感じる方がいたら、今日の内容から1つでも持ち帰っていただけると嬉しいなと思っています。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
Product Management Summit

※動画の視聴にはFindyへのログインが必要です。