AI導入に全員賛成。それでも実装が止まるのはなぜか：部署ごとの「正しさ」を、意思決定と実行につなぐPM・PMOの仕事

経営層は、AIによる生産性向上を期待しています。

事業部門は、営業や顧客対応の現場でAIを活用したいと考えています。

IT部門も、その実現に向けて技術的な検討を進めています。

AIを導入すること自体には、誰も反対していません。

ところが、具体的な開発要件を決めようとすると、プロジェクトはなかなか前へ進みません。

「できるだけ早く現場で使い始めたい」

「安全性が確認できるまでは、本番環境に導入できない」

「まずは投資に見合う効果を明確にすべきだ」

それぞれの主張は、もっともです。

しかし、すべての主張が正しいことと、プロジェクト全体が前へ進めることは、どうやら別の問題のようです。

なぜ、全員が賛成しているはずのAI導入が止まってしまうのでしょうか。

そして、こうした状況を前に進めるために、PMやPMOには何が求められるのでしょうか。

「小さく始める」ことに合意しても、何を作るかは決まらない

当社の小川良太は、「最小限の投資」でプロジェクトを成功に導く方法という記事で、これによく似た問題を紹介しています。

「MVPで小さく始めましょう」

新しいプロダクトを開発するとき、この方針には多くの人が賛成します。

しかし、「どこまでをMVPに含めるか」を決め始めると、意見が分かれます。

例えば、ビジネス部門は、入力ミスを防ぐ仕組みを最初から実装したいと考えます。ユーザーに安心して使ってもらうためには、信頼性が欠かせないからです。

一方、IT部門は、そのリスクは初期段階なら運用で吸収できると判断します。まずは機能を絞って検証し、必要に応じて追加すればよいと考えます。

どちらも「最小限で始める」という方針には賛成しています。

しかし、何を最小限と考えるかが違うのです。

小川は、こうした認識のずれが解消されないまま進み、当初の想定より大きな投資になってしまったプロジェクトを何度も見てきたと述べています。

AI導入でも、同じことが起こりえます。

AIの導入自体に賛成していても、何を最初に実装すべきか、どこまでのリスクを許容するか、どのような成果をもって成功とするかについては、異なる考えがあるからです。

「それぞれが自分の仕事を正しく果たそうとしているからこそ、物事が進まない」という状況が、ごく現実的なものとして生じるのです。

各部署は、異なる境界を守っています

企業は、異なる専門性と責任を持つ人々が集まって成立しています。それぞれの部署が、異なるものを守っています。

この構造を考えるうえで、デザイン思考の基本的な枠組みが参考になります。

Desirability・Feasibility・Viabilityという三つの観点です。

• Desirability（望ましさ）：人々が本当に求めるものか。

• Feasibility（実現可能性）：技術や組織の能力によって実現できるか。

• Viability（事業成立性）：事業として成立し、継続できるか。

優れたプロダクトやサービスを実現するには、この三つを同時に考える必要があります。

この三つの観点を、部署ごとの責任に重ねてみます。

顧客に向き合う営業部門や事業部門は、Desirabilityを強く意識するかもしれません。IT部門はFeasibilityを重視するでしょう。経営や事業管理を担う人々は、Viabilityを問い続けます。

もちろん、三つの観点が部署と一対一で対応するわけではありません。各部署は複数の条件を考慮しますし、法務やセキュリティのように、複数の観点にまたがる責任もあります。

しかし、各部署が特定の条件に対して強い責任を負っていることは確かです。

そして、この三つの観点は、どれか一つが正解なのではありません。

それぞれが重要だからこそ、互いに譲れないことがあるのです。

顧客価値を守る人が技術的な難しさだけを理由に価値の追求を簡単に諦めてしまえば、魅力的なサービスは生まれにくくなります。実現可能性を守る人が技術的なリスクを軽視すれば、プロジェクトは破綻しかねません。事業性を守る人が投資や収益の合理性を問わなくなれば、サービスの継続そのものが難しくなるかもしれません。

各部署は、それぞれの責任を果たすために、プロジェクトの可能性に対して異なる境界を引いているとも考えられます。

合意が起こらないのは、ある意味で、各部署が各部署としての仕事をしている証拠なのかもしれません。

異なる境界が、新しい選択肢を生み出す

ここで、イノベーション研究者のロベルト・ベルガンティの議論を紹介したいと思います。

ベルガンティは著書『突破するデザイン』で、意味のあるイノベーションを生み出すためには、アイデアを大量に集めるだけでなく、それらを批判的に検討することが重要だと論じています。

ここでいう批判は、単に相手を否定するためのものではありません。

ある仮説の前提や意味を深く掘り下げ、異なる仮説を突き合わせることによって、当初は見えていなかった新しい解釈を探る営みです。

この考え方を、部署間の対立に重ねてみましょう。

各部署の「これは譲れない」という主張は、互いに対立する意見であると同時に、プロジェクトが満たすべき条件を示しています。

それは、「ここを越えると、この部署が守るべき価値を満たせなくなる」という、境界の提示でもあるのです。

そして、異なる境界が明確になることによって、初めて検討できる選択肢があります。

例えば、AIを全社に一斉導入するか、それとも安全性が完全に確認できるまで延期するか、という議論があったとします。

ここで双方の主張を単に折衷するのではなく、守るべき条件を明らかにすれば、別の方法が見つかるかもしれません。

顧客情報を扱わない限定的な業務から導入する。一定の条件を満たした場合に対象を広げる。問題が生じた場合の停止条件をあらかじめ定める。

こうした選択肢は、早さと安全性のどちらかを軽視するのではなく、双方を重要な条件として扱うことから生まれます。

もちろん、異なる主張をぶつければ、必ず優れた解決策が見つかるわけではありません。

条件が両立しない場合には、何を優先するかという難しい判断も必要です。

それでも、各部署の主張が明確であることは、その判断を行うための重要な材料になります。

部署間の対立は、解消すべき障害であるだけでなく、よりよい実装の条件を発見するための材料にもなりうるのです。

私たちCULTURELABSは、この考え方をプロジェクトの設計そのものに組み込むことがあります。

過去に実施したデザインスプリントでは、プロジェクトのスタート時に、数名のメンバーをそれぞれ「Desirabilityを追求する人」「Feasibilityを追求する人」「Viabilityを追求する人」として明確に任命しました。

この人たちの役割は、意見をまとめることではありません。自分に託された観点から、「ここは譲れない」という境界を示し続けることです。

境界を示す役割をあらかじめ置いておけば、反対意見は「場を乱すもの」ではなく、「任された役割を果たしている発言」として扱えるようになります。

それは、メンバーが部署の代表としてではなく、任された観点の担い手として発言できるようにする仕掛けでもあります。

誰もが知っているのに、誰も言えないこと

ここまで見てきたように、各部署、あるいは各メンバーが異なる境界を明確に示すことでこそ、プロジェクト全体が満たすべき条件は明らかになります。

しかし、境界が明確になるだけでは、プロジェクトは前へ進みません。

各部署の主張は、どれも合理的です。それでも、すべての主張を並べただけでは、何をどう実行するかは決まりません。

ここでは、一つの不思議なことが起こっています。

誰もがプロジェクトの成功を望んでいます。誰もが、自分の部署の主張だけでプロジェクト全体が成立するわけではないと理解しています。それなのに、会議では、それぞれの部署が守るべき条件ばかりが繰り返し語られるのです。

なぜでしょうか。

それは、各部署の仕事に、自分の責任の境界を示すこと自体が含まれているからなのかもしれません。

例えば、営業部門のAさんとIT部門のBさんが、AI導入について話し合っているとします。できるだけ早くAIを現場で使えるようにしたい営業部門のAさんも、安全性の重要性はある程度理解しているでしょう。逆に、セキュリティやシステムの安定性を確認してから導入したいIT部門のBさんも、早期導入によって営業部門が得られる価値を想像することはできるはずです。

しかし、自分の立場からの主張を弱め、他部署との妥協点を先回りして提示することは、場合によっては、守るべき境界を自ら曖昧にすることにつながります。

だから、全体のために必要だと理解していても、自分の部署の立場からは言いにくいことが生まれる。

言い換えるなら、組織には、誰もが必要性を理解しているのに、それを引き受けることが誰の仕事にもなっていない問いが存在しうるのです。

Z軸は、最初からそこにあります

この状況を、綱引きにたとえてみます。

会議の場では、各部署がそれぞれの方向へ綱を引いています。早さの方へ、安全性の方へ、投資効果の方へ。

どの方向に、どれだけ引くか。その議論を続けている限り、誰かが引けば誰かが引きずられるという関係からは抜け出せません。

しかし、プロジェクトには、もう一つの問いがあります。

「プロジェクト全体にとって、どうするのが最善なのか」

これは、部署ごとの綱引き（どの方向に引くか）とは別の次元にある問いです。問われているのは、そもそも何のために綱を引いているのか、だからです。

これを、ここではZ軸と呼んでみましょう。

重要なのは、Z軸は誰かが新しく持ち込むものではないということです。

最初からそこにあります。

各部署はその責務として自分に託された観点を強く主張しますが、顧客への価値も、技術的な実現可能性も、事業としての成立性も、本来は一つのプロダクトやサービスを成功させるために検討されるものです。

もちろん、実際の大企業では、部署ごとに成功のイメージそのものが異なることもあります。全員がAI導入に賛成していても、何をもって成功とするかまで一致しているとは限りません。

だからこそ、暗黙の目的を言語化し、異なる解釈を確かめ、必要なら共通の目標を定義し直すことが必要です。

ここで、先ほどの綱引きを、少し離れた場所から眺めてみましょう。

各部署がそれぞれの方向へ引いている綱は、互いを打ち消し合う力に見えます。しかし見方を変えれば、それは一つの山の裾野でもあります。

山は、裾野が広いほど、高くなりやすいものです。

同じように、各部署が守るべき境界をはっきりと示すほど、プロジェクトが満たすべき条件は広く、確かなものになります。その分だけ、プロジェクトがZ軸の方向へ、つまり実際に起こしたい成果へと到達できる高さも上がっていきます。

対立を避けようと各部署が主張を弱めれば、裾野は狭くなります。会議は穏やかになるかもしれませんが、そのぶん山は低くなります。

ただし、裾野が広いだけでは、山にはなりません。広がった裾野を、一つの頂へと積み上げていく働きが必要です。その頂の方向こそが、Z軸です。

Z軸がなかったのではありません。それを示す役割が、空席だったのです。

PMOは、別軸の価値に奉仕します

各部署は、それぞれが組織に必要な機能を担っています。

しかし、すべての部署が自分の仕事を正しく果たせば、AI導入が必ず成功するわけではありません。

安全で高性能なAIシステムが完成しても、現場で使われなければ、業務は変わりません。顧客のニーズを正確に把握できても、それに応える仕組みが実装されなければ、顧客体験は変わりません。優れた事業計画を立てても、実行されなければ、新しい事業は生まれません。

この状況を、「異なる二つの価値」という考え方で読み解いてみます。

一つは、機能としての価値です。

それぞれの部署が、自らに託された仕事を正しく果たすことで生まれます。

もう一つは、現象としての価値です。

異なる機能が組み合わさることで、人々の行動が変わり、新しいサービスが使われ、これまでになかった成果が実際に生まれることです。

例えば、AIを活用して営業担当者の情報整理にかかる時間が短くなり、顧客と向き合う時間が増える。あるいは、AIによる業務支援が現場に定着し、従来は難しかったサービスを提供できるようになる。

これらは、システムが完成したという事実だけでは説明できない成果です。技術が機能し、現場の人々がそれを使い、業務の仕組みや判断が変わることで、初めて起こることだからです。

そして、この二つの価値は、上下の関係ではありません。

機能としての価値がなければ、現象は成立しません。しかし、機能が成立しただけで、望んだ現象が必ず起こるわけでもありません。

各部署の責任は、機能としての価値を守ることにあります。

一方、それらの機能を接続し、プロジェクトが目指す現象を成立させる条件を整えるという別の責任を果たすのが、PMOです。

各部署は、機能としての価値に奉仕します。PMOは、現象としての価値に奉仕します。

先ほどのZ軸を可視化し、必要に応じて関係者と目的を定義し直しながら、実際の成果へと結びつけていく。それがPMOの仕事なのです。

「AIを導入する」という合意を、「AIで仕事が変わる」という現象へ

これを、AI導入プロジェクトに当てはめてみましょう。

経営・事業・ITの各部門がAI導入に賛成し、それぞれが必要な条件を提示しても、条件が並んだだけでは、何から着手すればよいのかは決まりません。

ここでPMOが最初に確かめるべきなのは、例えば次のような問いでしょう。

「AIを導入することで、現場ではどんなことが起こるようになってほしいのでしょうか」

単にAIツールを利用可能にすることでしょうか。

それとも、営業担当者が顧客への提案により多くの時間を使えるようになることでしょうか。あるいは、これまで対応できなかった顧客の相談に応えられるようになることでしょうか。

プロジェクトが目指す現象が明らかになれば、各部署の主張の意味も変わってきます。

IT部門の求める安全性は、導入を遅らせるための条件ではありません。AIを安心して使い続けるための条件になります。

事業部門の求める早期導入は、開発を急がせるための要求ではありません。現場で価値を検証し、改善を始めるための条件になります。

経営層の求める投資対効果は、予算を抑制するためだけの制約ではありません。生まれた変化を継続可能な事業成果へつなげるための条件になります。

それぞれが守る境界は、なくなっていません。

むしろ、その境界が明確だからこそ、プロジェクト全体として何を満たすべきかがわかるようになります。

ここで重要なのは、各部署に妥協を求めることよりも、各部署が守っている条件を、目指す現象の成立条件として読み替えることです。

小川は、HMW（How Might We）に関する記事で、プロジェクトの随所で問いを立て、チーム全体で共有することの重要性を説明しています。

「どうすれば、私たちは〜できるだろうか？」

この問いは、部署ごとの要望を単に並べるのではなく、共通の目的に向かって何を実現すべきかを考える出発点になります。また、MVPに関する記事では、機能の必要性を価値創出とリスク対策の観点から整理し、優先順位を決める方法を紹介しています。

これらの方法は、機能と現象の間をつなぐためにも活用できます。

実現したい現象を言葉にし、そのために必要な機能を考え、どの条件を優先すべきかを判断する。

そして、決めたことを実際の開発と現場での検証につなげる。

こうした一連の仕事によって初めて、AI導入の合意は、実行可能なプロジェクトへと変わっていきます。

PMOには、具体的に何が求められるのでしょうか

機能としての価値を、現象としての価値へ接続するために、PMOはどんな行動を取る必要があるのでしょうか。

「関係者と調整する」「進捗を管理する」という説明だけでは、十分ではありません。

各部署が守るべき境界を明確にしながら、それらの間から新しい選択肢を生み出す。そのためには、異なる立場の人々が、安心して自分の考えを示し、互いの主張を批判的に検討できる環境が必要です。

ここで、もう一度ロベルト・ベルガンティの議論に戻ってみましょう。

ベルガンティは『突破するデザイン』で、批判が創造の源泉となるためには、三つの信頼が必要だと論じています。

一つ目は、話すことの信頼です。

未成熟な考えや、周囲から否定されるかもしれない仮説でも、安心して共有できることです。

二つ目は、行動の信頼です。

従来の常識にとらわれない実験を試み、未知の可能性を検証できることです。

三つ目は、聞くことの信頼です。

自分の考えに対する批判を、敵意や攻撃としてではなく、考えをよりよくするための働きかけとして受け止められることです。

これは、部署間の合意形成にも重要な示唆を与えてくれます。

例えば、IT部門が「この条件では安全性を確保できません」と率直に発言できること。

事業部門が「この仕様では顧客に十分な価値を届けられません」と、遠慮なく主張できること。さらに、それぞれが相手の指摘を、自分たちの仕事への攻撃ではなく、よりよい実装のための条件として受け止められること。そのうえで、既存の手順にない方法でも、適切な範囲で試すことができること。

こうした環境があって初めて、部署ごとの異なる主張は、単なる対立から、創造的な議論の材料へと変わっていきます。

ここで注意したいのは、信頼とは、相手の言うことに無条件で従うことではないという点です。むしろ、異なる意見を率直に述べ、それを受け止め、実際に試すことができるからこそ、信頼が意味を持つのです。

そして、このような環境をつくることも、PMOが担うべき仕事の一つではないでしょうか。

具体的には、次のような行動が考えられます。

最初の三つの信頼は、その後の五つの仕事を成立させる土台でもあります。

話すことの信頼がなければ、各部署の本当の懸念は表に出てこないかもしれません。

聞くことの信頼がなければ、明らかになった懸念は、相手を批判するための材料として扱われてしまうかもしれません。

行動の信頼がなければ、新しい選択肢が見つかっても、実際に試すところまで進めないかもしれません。

つまり、PMOに必要なのは、意見を集めて整理する能力だけではありません。

異なる部署が、それぞれの専門性と責任に忠実でありながら、互いの違いを新しい行動へと変えられる環境を設計することです。

各部署が機能としての価値を守り、その違いを率直に表現できること。

そして、その違いを批判的に検討し、実際の行動へつなげられること。

そうした条件を整えることで、PMOは現象としての価値が生まれる可能性を高めていくのです。

CULTURELABSが、この仕事を担える理由

こうしたPMOの仕事を果たすためには、プロジェクトマネジメントの知識だけでは足りません。

事業や顧客の課題を理解する力、技術的な制約を扱う力、異なる立場の人々と合意を形成する力、そして決定を実際の開発へつなげる力が必要です。

私たちはこれまで、こうした力を組み合わせながら、大企業のプロジェクトを支援してきました。ここでは、公開している事例の中から四つを紹介します。

1. 異なる専門性を、顧客価値の検証へつなげる

大手保険会社のイノベーションセンターへのデザインスプリント導入事例では、私たちはプロダクトデザインコーチとして、新規事業開発の仕組みづくりを支援しました。

約3か月周期のプロジェクトチームを組み、社内で集まったアイデアを顧客テストによって検証し、具体的なプロダクトやサービスへと発展させる方法を導入しました。

年間7件のビジネスデザイン・プロダクトデザイン・MVP開発案件に伴走しました。

この事例で重要なのは、ビジネス、デザイン、テクノロジーという異なる専門性を、顧客の課題を検証するという一つの活動へ接続していることです。

それぞれの専門家が自分の立場から意見を述べるだけではなく、顧客の反応やプロトタイプという共通の対象をもとに、次に何をすべきかを判断します。

機能としての専門性を、顧客に新しい価値が生まれるという現象へつなげる実践です。

2. 経営の構想を、AI事業の実行可能な計画へ変える

大手金融機関の新規AI事業開発事例では、私たちが事業領域の選定からプロダクト設計、PoC、ビジネスモデル設計まで、約1年間にわたって伴走しました。

当初、顧客企業では新規事業開発の経験が十分ではなく、何から着手すべきかも明確ではありませんでした。

私たちは、市場リサーチやワークショップを通じた事業領域の選定、開発要件の整理と優先順位づけ、PoCの設計・分析を支援しました。

PoCでは、約10社の顧客企業、100名を超えるユーザーを対象に検証を行い、事業化判断に必要な情報を取得しました。

この事例は、経営が掲げる新しい収益の柱という構想を、顧客ニーズや技術的な検証を通じて、判断可能な事業計画へと具体化する仕事を示しています。

重要なのは、AIを使ったプロダクトを構想したことだけではありません。

何を検証し、どの情報をもとに事業化を判断するのかまでを、プロジェクトとして前進させたことです。

3. 複雑な開発体制を、継続的なローンチへつなげる

大手金融機関の新規事業プラットフォーム開発事例では、私たちがPM・PMO・スクラムマスターを横断的に支援しました。

このプロジェクトでは、新規事業や新商品を継続的に立ち上げるために、契約・会計・営業支援などを統合するプラットフォームの構築が求められていました。

私たちは、開発チームのリソースや工程の管理、プロダクトデザイン、要件の優先順位管理を担いました。

その結果、半年以内の初期ローンチを実現し、24か月で5回のローンチを達成しました。プラットフォームは、1,000を超える販売パートナー企業に利用されています。

お客様からは、スケジュールや要件の変更に柔軟に対応できる体制を整え、安定したスクラム運営に貢献した点を評価いただいています。

これは、AI導入そのものの事例ではありません。

しかし、大企業における複雑な開発体制の中で、異なる仕事を調整し、要件を優先順位づけし、継続的なローンチへ接続してきた実績です。

各部署がそれぞれの機能を果たすだけでなく、実際に新しいプラットフォームが利用されるという現象を成立させるための支援だったと考えています。

4. 判断する能力を、顧客企業の中に残す

私たちは、大手金融機関のIT部門コーチ育成基盤の構築にも取り組んでいます。

この案件では、IT部門の支援人材にスキルの差があり、ベテラン層へ負荷が集中していました。また、ITの知識はあっても、ユーザー起点のプロダクト設計や事業性検証に関する知見が不足していることも課題でした。

そこで私たちは、64項目のスキルマップを策定し、プロジェクトのフェーズごとに必要な役割やスタンス、陥りやすい失敗パターンを明文化しました。

そして、年間20件以上のデジタル新規プロダクト支援に適用される育成基盤として整備しました。

私たちは、自らプロジェクトを進めることだけを目標にしているわけではありません。

顧客企業のメンバー自身が、異なる専門性をつなぎ、事業性を検証し、次の判断を行えるようにする。そのための知恵や方法を、組織の中に残していく取り組みです。

もちろん、部署間の対立に万能の解決策があるわけではありません。プロジェクトごとに、守るべき条件も、関係者の間で交わされた合意も異なります。

だからこそ私たちは、一つの方法論を当てはめるのではなく、それぞれの現場で条件と合意事項を確かめながら進めることを大切にしています。

これまでの支援を通じて、私たちは、事業構想、顧客検証、開発要件の優先順位づけ、PM・PMOによる実行、人材育成という一連の仕事に取り組んできました。

私たちの強みは、これらを独立した専門サービスとして提供するだけではなく、プロジェクトの目的に応じて組み合わせ、関係者とともに実行まで進められることにあります。

合意形成とは、全員を同じ意見にすることではありません

AI導入における合意形成とは、全員が同じ意見を持つことではありません。

事業部門が顧客への価値を、IT部門が安全性を、経営層が事業の持続可能性を重視していて、よいのです。

それぞれが異なる責任を果たしているからこそ、プロジェクトには多様な条件が持ち込まれます。

そして、その条件が明確であるほど、何を守りながら前進すべきかを具体的に考えられるようになります。

しかし、条件を並べただけでは、新しい価値は生まれません。

必要なのは、異なる機能がそれぞれの役割を果たした先に、何が起こるべきなのかを明らかにすることです。

AIシステムを開発することと、AIによって仕事が変わることは違います。

AIを導入することに合意することと、そのAIが現場で使われ、成果を生み出すことも違います。

各部署は、機能としての価値を守っています。

PMOは、それらが組み合わさることで生まれる、現象としての価値に目を向けます。

そこに、役割の優劣はありません。

各部署が自分たちの正しさを守っているからこそ、PMOは、その正しさを一つの成果へと結びつけることができます。

そしてPMOが全体の目的を可視化することで、各部署は、自らの専門性や責任を手放すことなく、プロジェクトへ参加できます。

合意形成が難しいのは、誰かが間違っているからとは限りません。

むしろ、全員が正しく自分の仕事をしているからこそ、それらを結びつける別の仕事が必要になるのです。

私たちCULTURELABSは、経営・事業・ITを横断した目的や体制の合意形成から、開発要件の優先順位づけ、PM・PMOによる実行までを支援しています。

関係者とともに考え、それぞれが守るべき条件を明らかにし、必要な意思決定を促しながら、実装と改善へつなげていきます。

目指すのは、AI導入に関する合意を得ることだけではありません。

AIによって、これまで起こっていなかった変化が、現場で実際に起こるようになることです。そのために、私たちは皆さんと一緒に考え、実行まで伴走します。

参考文献

• ロベルト・ベルガンティ『突破するデザイン』

• 小川良太「プロジェクトを成功させるために『絶対に』必要なこと」

• 小川良太「『最小限の投資』でプロジェクトを成功に導く方法」

• CULTURELABS「大手保険会社イノベーションセンターへのデザインスプリント導入」

• CULTURELABS「大手金融機関の新規AI事業開発」

• CULTURELABS「大手金融機関の新規事業プラットフォーム開発PM」

• CULTURELABS「IT部門コーチの育成基盤構築」