- ProductZine Day 2025：S-6セッション「部分最適を超えて、全体を動かす〜大企業組織変革のためのプロダクトコーチング〜」
「企業変革のジレンマ」に陥る大企業を、今の時代に即したプロダクト組織へ変革する
「プロダクトコーチング」に明確的な定義はないが、一般的にプロダクトが生み出すアウトカム（成果・効果）を最大化するために、プロダクトチームの成長や組織システムの最適化を間接的に支援することを指す。
具体的には、「人・組織、プロダクト、プロセス・文化の3領域」をターゲットとして、「ディスカバリー」「デリバリー」「プロダクトリーダーシップ」「トランスフォーメーション」の4つのコーチングがある。
会社や組織の変革には「トランスフォーメーションコーチング」、プロダクト責任者向けには「プロダクトリーダーシップコーチング」、プロダクトチーム向けには「ディスカバリーコーチング」「デリバリーコーチング」が対応しており、それぞれ組織の大きさや対象となる部分に応じて異なるメソッドやアプローチ法が存在する。
今回登壇した兼原氏は、大企業の組織変革に対する「トランスフォーメーションコーチング」を実施してきており、「大企業が抱える課題」にたびたび遭遇してきたと言う。
兼原氏は「よく言われることながら、大企業には2000年代のITビジネス・情報システムのやり方がまだ残っている。デジタルを当たり前としたビジネスや組織に変革する必要がありながら、ずっと変わらずに来た。数年前から指摘されていることだが、なかなか変わらず、ようやく事例が出てきたところ」と語る。
とはいえ、長い歴史と成功モデルを持つ大企業は、分業化やルーティン化によって効率的な成長を実現し、収益も上がっていることから、なかなか新しい環境へと移行しにくい。現在の成功モデルが新しい環境への適応を妨げる「構造的無能化」を引き起こしていると言う。いわゆる「企業変革のジレンマ」に陥っているというわけだ。
そのため、大企業の変革には、プロダクトが育つ構造への転換と、プロダクトチームの成長支援の、“両面”からのアプローチが必要となる。とりわけプロジェクトベースの文化からプロダクトベースの文化へ移行することが大きなテーマであり、兼原氏はそのための手法として「作り方を変える」「問題解決の方法を変える」「解決すべき問題を決める方法を変える」の3つをあげた。
組織変革への道①：外注中心から内製へ「作り方を変える」ための組織変革とAI活用
まず、「作り方を変える」にあたって障壁となっているのが、大企業の開発体制が外注を中心に成り立っていることだ。
インハウスのエンジニアがほとんどいない環境では、リスクをとる挑戦が生まれづらい傾向にある。大企業側は委託による「コストの削減」に一番のメリットを感じており、低コストで委託を受けているベンダー企業側は、長期的に安定運用を行うことをもっとも重視しているからだ。兼原氏は「まさかというなら、次のようなことに心当たりはないだろうか」と言いながら、下図のようなチェックシートを示した。
思い当たることがなければ幸いだが、大企業ではこうしたことが実際に起きており、まさに危機的状況と言えるだろう。これを解決する方法として、「内製化」は大きなトレンドとなっている。
なお、ここでの「内製化」とは、外部仕様ではなくソースコードレベルでのコントロールを指す。AIの活用は半ばブーム的な印象もあるが、兼原氏は「AIを活用して生産性を高めたいなら、ソースコードレベルでコントロールできなくては難しい。そこで、内製化人材の比率が生産性を上げるための障壁の一つとなっているのではないか」と分析する。
それではどのようにして、ソースコードレベルでの内製化を進めればいいのか。兼原氏は「ステップを踏んでいくことが必要」と語り、中でも要となるステップとして「開発パートナーとの共創体制」について紹介した。
開発パートナーとの共創体制を実現するには、従来の一辺倒な方法だけではなく、「作り方」を選択的に決定できる状態を目指す必要がある。例えば「SIerなどのパートナー企業をチームに招き入れて共同開発を進める方法」や「自社エンジニアのみで開発を行う方法」など、複数の開発スタイルを確立する必要がある。また、パートナー主導の開発でも、ラボ型や請負開発など特性に応じた組み合わせを適切に選択することが求められる。これを何パターンも持てるような状態を作り出すことが必要だ。
兼原氏は、「自社商品の開発では専門性の確立が欠かせない。特に、BTC（ビジネス・テクノロジー・クリエイティブ）トライアングルのバランスを意識することが重要だ。しかし、日本の大企業では、新卒一括採用や総合職人材の採用が主流であるため、組織の構造上、ビジネス偏重になりがち。そのため、社内での分業が進み、プロダクト組織に必要なケイパビリティが分散している状態にある」と指摘する。
そこで、必要なスキルや経験部門を見定めながら、人事部門との連携により職能横断でプロダクトチームを組成することが第一歩だと言う。もちろん外部人材を取り込んでいければいいが、プロダクトチームに適した人材ほど、プロダクト文化がない組織に拒否感を感じるため、そう簡単にはいかない。
兼原氏は「プロダクト文化がない組織に外部人材を採用しようとしても難しい。すでにいる人材についてケイパビリティを確認して育成しながら、パートナーの支援を受けるのが第一歩」と語る。そして、専門性を理解したり、共創のトレーニングをしたり、さらにプロトタイプ駆動のコミュニケーションをとりながら、最終的にはBTCの観点を併せ持つプロダクトチームへと変化させていく。そこにたどり着くためには、まずは今自身の組織がどのステータスにあるのかイメージを持つことが必要というわけだ。
この組織変革を大きくドライブするのが、ノーコード／ローコードツールやAIなどの技術革新だ。専門的な運用部分をAIなどを効果的に活用しながら段階的に置き換えていくことで、外注依存の状態から変革を加速できると言う。兼原氏は、「大企業だからこそAIを率先して活用することで、プロダクトカンパニーへのリープフロッグ（最新の技術やサービスに一気に移行する）を達成できる。とても重要なポイントだ」と強調した。
組織変革への道②：効果的な探索により「問題解決の方法を変える」
2つ目のポイントである「問題解決の方法を変える」について、兼原氏はまず予算承認のあり方を変えるべきだと指摘する。大企業のプロジェクト型における予算承認は、高い確実性を“前提”に行われる。そして承認後はその範囲内で予算を執行するという流れだ。
しかし、プロダクト型ではアジャイル開発が行われるため、その予算承認制度のままでは、不確実性が高い探索時期に承認が行われることになる。そこで、不確実性の高い“探索”の時期にも適した予算適用が必要だと言う。兼原氏は「必要に応じて選択できる必要がある。なければ制度として作る必要がある」と語る。
予算承認のタイミングとして、兼原氏は「企画の承認と開発の承認は分けた方が良い」と指摘する。プロダクト型開発では、探索の時期に実験・検証して、やると決まったものだけ開発予算が承認されればよい。探索と実開発の段階を分けるだけでも、不確実性が低くなる。まずは問題解決の方法を探索するための予算承認・執行によってプロトタイプを作成し、それをベースとしてコミュニケーションすることで、解くべき問題の不確実性を下げる。そして、確実性が高まったタイミングで開発承認を行い、開発のための予算の承認・執行をするという流れだ。
プロトタイプは、AIやFigmaなどのツールが登場しており、かなり低コストで作成できるようになりつつある。本番に近いもので検証できる方がいいため、これは望ましいところだろう。また、ユーザーストーリーを小さく分割して価値のあるものだけを集中して検証することで、探索の時間とコストを圧縮できる。
兼原氏は、以上に紹介した（1）企画承認と開発承認を分割して探索のための予算を確保する、（2）探索の予算はプロトタイピングおよびこれを用いた検証に当てる、（3）企画をユーザーストーリーでスライスし価値のあるものに集中する、の3つの取り組みだけでも「得られる効果は高い」とし、「プロジェクト型文化からプロダクト型文化に変わる足がかりになる」と語った。そして、こうした事例を積み上げながら、実績に基づく年間包括予算を確保し、プロジェクトごとではなく、プロダクトに対して継続的な価値探索ができる環境をつくることの重要性を訴えた。
そして、「開発中だけアジャイルなやり方をしても仕方がない。不確実性が高い前半の企画プロセスを変革していくことがアウトカムを高めることにつながる」と語り、それこそがプロダクト型文化に移行する上での“本丸”と強調した。特に開発の大部分をアウトソースしている環境ならば、キャッシュアウトが発生しない内部人材を活かした施策は、実施しやすいといえるだろう。
組織変革への道③：NOという仕組みを実装し「解決すべき問題を決める方法を変える」
プロジェクトベースからプロダクトベースへ、「解決すべき問題を決める方法を変える」について、兼原氏はまず現在の「やることを決める」ための仕組みの問題点を指摘する。
プロジェクト型では、ビジネス部門は企画、開発部門は見積もりを出すこと、経営／執行は決裁が仕事となる。いわば「やることを決める仕事」だ。そのため、いつでも案件は緊急で重要なものであふれているというのが実情だろう。そのため、やることだけを決めるようでは、リソースが不足し、新しい施策をやりたくても1年後となり、負のスパイラルへと落ち込んでいく。
そうならないためにも、事業戦略と連動した、ヒト・モノ・カネ・情報などの経営資源を適切に配分する「リソースアロケーション」が重要になる。実際、部門視点で見れば、すべてが緊急で重要というものも、事業目線で見ればかなり絞られるはずだ。そして、そうした判断を実現するためには、組織の中に「NO」という仕組みを実装することが重要だと言う。
具体的な方法として、兼原氏は次のような6ステップに分けて、コツとともに紹介した。
ステップ1：すべての依頼案件を統合化し、可視化を行う
ステップ2：ムダな見積もりや要件定義にかかっている工数を定量化
無駄を減らすことで開発案件に工数を回せることを定量的に示し、納得感を得ることが大切。
ステップ3：HiPPO（Highest Paid Person's Opinion）による「No」という仕組み
HiPPO＝組織で重要な役職に就き、高給を得ているものの意見。アンチパターン（一見良さそうに見えて実際には問題を引き起こす典型的な失敗パターン）と言われることも多いが、これがなくては大企業では部門をまたいでの優先順位付けはできないため、決裁者の判断は重要。
ステップ4：すきまの「Why」をHiPPOに聞く
優先順位について決裁者に「なぜそうなるのか」を聞きながら、言語化を重ねることでプロダクトマネジメントとの溝を埋めていく。
ステップ5：既存のリリース計画を、アウトカムベースでひもづけし直していく
部門ごとの作業ではなく、事業単位で共通の効果指標にひもづくように機能リストを再編する。これがかなうと、会社の仕組みに組み込めるようになる。
ステップ6：「Noと言う仕組み」を会社のプロセスに組み込む
会議体や案件管理方法、優先順位決め、決裁規定、開発プロセスなどを整備し実装。「ここに来るまでに2年ほどかかる」（兼原氏）
兼原氏は、これらの施策を振り返り、「大企業の組織変革において、プロダクトコーチングは非常に幅広い領域をカバーする。文化レベルから具体的な実行フェーズまで支援し、事業とプロダクトの成長を実現するための重要な役割を担う」と語った。
そして、「プロダクトコーチングの目的は、単にプロダクト組織を構築することではない。事業とプロダクトの成長を阻害する要因を特定し、改革を進めることにある。そのため、組織横断で各レイヤーと密接にコミュニケーションを取りつつ、共に課題を解決し、変革を推進することが求められる」と強調した。
最後に兼原氏は、プロダクトコーチングにおいて大切にしていることとして、次の5つを挙げ、「大企業の方々と共有し、組織変革につなげていきたい」と語り、まとめの言葉とした。
- 見えない境界を見つけて、企業の内側にある可能性を引き出す
- 過去と未来の境界で、歴史と対応しながら、その先の未来を描く
- 短期と長期の境界で、持続可能な成長の土台を育てる
- 実践と知の境界で、手触りと実効性のある仕組みを作る
- 部分と全体の境界で、変化が波及する構造をデザインする
