はじめに
前回、ミドルプロダクトマネージャー（ミドルPM）とシニアプロダクトマネージャー（シニアPM）の間にあるキャズムの一つとして、「事業計画を読めるかどうか」を取り上げました。
事業計画の数字をただ受け取るのではなく、構造を分解し、賭け方を読み取り、自分のロードマップと接続する。この視座の転換が、ミドルとシニアを分けるラインの一つだという話でした。
ただ、前回書きながら感じていたこともあります。事業計画を「読める」ようになったとして、それだけで何かが変わるわけではないな、ということです。読めた上で、何を動かすのか。多くの場合、その対象になるのは「組織」ではないかと思っています。
組織と聞くと、経営やマネジメントの仕事であって、PMの領域ではないと感じる方もいるかもしれません。私もかつてはそう思っていました。ただ、今の自分の実感としては、シニアPMにとって組織を扱うことは「追加の仕事」ではなく、事業計画を実行に変えるための中心的な手段なのではないかと考えています。
今回はこの話を、DIGGLEでの具体的な事例も交えながら掘り下げていきます。
組織は、事業計画の「従属変数」である
PMが組織について語るとき、よくある入り口があります。
「クロスファンクショナルチームが良いらしい」「スクラムを導入したい」「チームトポロジーの考え方を取り入れよう」
組織のあり方に関心を持つこと自体は、とても良いことだと思います。ただ、ここで気をつけたいのは、組織の「型」から入ってしまうことのリスクです。
型から入ると、「この組織形態にすれば、こういう成果が出るはずだ」という思考になりやすい。しかし実際には、同じ形をとっても機能する会社としない会社がある。組織の形そのものが成果を生むわけではないからです。
私は、組織とは事業計画に対する「従属変数」だと考えています。事業計画があり、その達成に向けて集団をどう構造化すれば動きやすくなるかを考える。順序としては、事業計画が先で、組織はその手段です。
当たり前のことのように聞こえるかもしれません。ただ、現場を見ていると、この順序が逆になっているケースは意外と多いように感じます。組織の課題感が先に立ち、「今の体制だとうまくいかないから変えたい」という動機で組織変更が始まる。結果として、変えた先の組織が事業計画の達成にどう効くのかがあいまいなまま進んでしまう。
DIGGLEでも、2025年12月に大きな組織変更を行いました。職能別の組織から、クロスファンクショナル型の組織への移行です。
この変更には、事業計画から逆算した明確な理由がありました。
DIGGLEは予実管理のSaaSとして、管理会計という専門性の高い領域を扱っています。事業を成長させていくためには、顧客のドメインに深く入り込み、一次情報を取りに行ける体制が不可欠でした。しかし、職能別の組織では、PMが企画し、デザイナーが設計し、エンジニアが実装するという流れの中で、ドメインの情報がPMに集中しやすい構造になっていました。
事業計画が求める成長スピードに対して、この構造では間に合わない。各チームがドメインに直接触れ、自律的に判断し、動ける状態を作る必要がある。クロスファンクショナル化は、そのための手段でした。
「クロスファンクショナルが良いから変えた」のではなく、「事業計画を達成するために、集団の構造をこう変える必要があった」という話です。この順序を間違えないことが、組織を扱う上で最も重要な前提だと考えています。
「正しい組織図」より、「過渡期」をどう乗り切るか
事業計画から組織の構造を考えるという話をしました。ただ、仮にその方向性が正しかったとしても、組織変更には他の打ち手とは決定的に異なる難しさがあります。組織は人で構成されている、という点です。
プロダクトの機能開発であれば、As-IsとTo-Beを描き、その差分を埋めていくという進め方が成立します。しかし組織の場合、綺麗な2枚の図にはなりません。今ここにいるメンバーには、それぞれの経験、習熟度、関係性、期待がある。一気に構造を変えたとしても、中にいる人が翌日から別の動き方をできるわけではありません。
組織は毎日の積み重ねでできています。だからこそ、変更そのものよりも、「過渡期をどうマネジメントするか」の方がはるかに重要ではないかと考えています。
DIGGLEのクロスファンクショナル組織化でも、このことを強く実感しました。
実は、組織構造に対する課題感自体は、2025年12月よりもずっと前から上がっていました。職能別組織の限界は見えていたし、変えるべきだという声もあった。ただ、当時のDIGGLEは一気に人が入社したタイミングで、オンボーディングフェーズにあるメンバーが多く、チームとしてのケイパビリティがまだ十分に出来上がっていない状態でした。
この状態で組織構造を変えるのは、改善どころか致命傷になり得る。そう判断して、あえてそのタイミングでは動かさないという選択をしています。
ここでの判断は、「正しい組織の形は何か」ではなく、「今このタイミングで変えるべきか」です。第1回で書いた「正しさよりも今やるべきかを判断する」というのは、まさにこういう局面の話だと思っています。
結果として、ケイパビリティが揃ったタイミングで変更を実行できたことは大きかったと感じています。変更後、他部門から「リリースの速度が上がったように感じる」という声が複数上がるまでになりました。
ただ、それは「タイミングさえ合えばうまくいく」という話ではありません。変更の前後では、かなりの準備と運用を進めています。変更後は週に1度マネージャー間で方向性をすり合わせる時間を設けたり、各チームでの変更後の効果実感をアンケートで確認したりといったことを継続的にやっていました。
なぜそこまでやるのかというと、組織変更自体は何かを変えるものではないからです。変えた後の環境の中で、各チームのメンバーが事業計画に対して実行しやすい状態になっているかどうか。そこまで見届けて初めて、「組織を動かした」と言えるのではないかと思っています。
