(スライド版) ツールを入れても浸透しない—AI推進を「組織変革」として設計する6つの要素

AI推進に取り組む他社の担当者と話していると、「ツールは導入した、でも思うように浸透しない」という声をよく聞きます。ChatGPTやGeminiを全社展開した、勉強会も開いた、でも数ヶ月後には使っている人と使っていない人が固定化されて、結局アーリーアダプター的な社員だけが使っている状態に、というパターンです。

これはツールの問題ではなく、設計の問題だと思っています。そしてこの問いに真っ向から向き合っているのが、私がPMOとして関わっている「kube-AI（くべあい）」というkubellの全社プロジェクトです。

これまでkubellにおいても複数の全社プロジェクトをPMやPMOとして推進してきましたが、AI推進は他のプロジェクトと根本的に異なる点がひとつあります。それは、「型がない」ということです。
業務改善プロジェクトであればある程度の成功パターンが存在しますが、AI推進は「誰がどう使うか」が不確定で、正解がまだ誰にも分かっていない、その上テクノロジーの進化スピードも異常に速く、昨日の正解が今日には陳腐化することもあります。

そういう状況で、私たちが何を考え、どう設計しているか。まだ道半ばではありますが、「こういう観点が参考になるかもしれない」という気持ちで、現時点での考えを以下のnoteにまとめ先日公開したところ、ありがたいことに大変多くの反響をいただきました。
https://note.com/takeshisumida_/n/nb262cb397c0f

今回のスライドは、そのnoteをベースとして、より気軽にご覧いただけるよう、エッセンスを簡単にまとめたものになります。

・AI活用の推進を絶賛行っている会社の経営者、推進責任者・担当者の方
・AI活用の推進をまさにこれから行おうとしている会社の経営者、推進責任者・担当者の方

などに特に見ていただけると嬉しいです。

Transcript

1. 【スライド版】 ツールを入れても浸透しない AI推進を「組織変革」として設計する 6つの要素
2. はじめに 全社的でのAI活用に課題を持つ経営層やプロジェクト責任者の方へ 角田 剛史 / Takeshi Sumida 株式会社kubellパートナー 執行役員 CAO コーポレート&ピープルディビジョン長 ▼X @takeshisumida_ ▼note @takeshisumida_ 本スライドは、noteの記事に基づいて作成されています 詳しくはぜひnoteをご覧ください
3. ツールは導入した、でも思うように浸透しない その回避のため、kubellでは「kube-AI（くべあい）」プロジェクトを立ち上げ kubellではそうなる状態を避けるため に、早期にプロジェクトを立ち上げ。 プロジェクト名の「kube-AI（くべあ い）」は、kubellの「薪をくべる」と いう社名に由来、「AIにお願いできる ことは、どんどんお願いしていって、 生産性の炎を大きくしていきましょ う」、という思いが込められている。 由来 全社的に導入したのに、数ヶ月後には 使っている人と使っていない人が固定 化。 結局アーリーアダプター的な社員だけ が使っている状態に。 よくある状態 「AIを『組織のOS』とし、全社の生 産性と市場価値を飛躍させる」とい うプロジェクト目標の元に、2025年 12月にプロジェクトを立ち上げ。 約半年が経過し、AIツール利用のア クティブ率、社員のAIレベル、業務 時間削減への寄与など、主要なKPIが 大きく向上。 成果 全員にChat GPTを 付与したのに... AI活用の勉強会も したのに....
4. AI推進を「組織変革」として設計する6つの要素 プロジェクトの半年の活動を振り返り、必要な要素を一旦言語化 1 　環境整備 4 　経営コミット AI活用を経営アジェンダの中核に置く 使える土台を整える 　体制設計 2 　組織変革設計 3 「誰が動かすか」を正しく設計する ツール導入ではなく文化形成として捉える 　測定設計 6 感覚ではなくデータで回す 　ガバナンス設計 5 安心して使えるルールをつくる
5. ①経営コミット AI活用を経営アジェンダの中核に置く 　経営陣の高いコミットメントはまずは何より 　重要。kubellにおいても「kube-AI」が 　動き出した最大の理由は、これに尽きる。 • 経営者が「なぜAIか」を自分の言葉で語る ◦ →エンジニア出身で技術的解像度を持つ CEOが全社総会で直接発信 • 戦略の最上位にAIを明示的に位置づける ◦ →中期戦略の冒頭に「全ての戦略にAIを強 く組み込む」と明記 • 一度限りでなく「定期的に」発信し続ける ◦ →半期ごとの全社総会（kubell CAMP）、 月次会議（kubell-ba）で継続発信 「kubell CAMP」におけるCEOプレゼンの様子
6. ②体制設計 「誰が動かすか」を正しく設計する 　①の経営コミットがあったとしても、 　動かす体制が無ければ机上の空論で終わる。 　分散していた各部門の動きを全社で統合。 • PJオーナー（PO）を会社のトップとする ◦ 経営課題としてのメッセージが伝わる ◦ 意思決定の迅速化につながる • 各部門からメンバーをアサインする ◦ 部門固有の取り組みを統合・可視化 ◦ 各部門での自分ごと化を促進 • 情報・コミュニケーション体制の整備 ◦ AI関連の発信・問い合わせチャットの窓口 を一本化（kube-AIチャット） 「kube-AI（くべあい）」プロジェクト体制
7. ③組織変革設計 ツール導入ではなく文化形成として捉える Awareness（認知） なぜやるのか Desire（欲求） 自分にとってのメリットは何か Knowlege（知識） どうすれば使えるのか Ability（能力） どう使いこなすのか Reinforcement（定着） どう継続させるのか 　変革管理のフレームワークである 　「ADKAR（アドカー）」をベースに設計。 　 • ツール導入の意識が強いと、Knowledge（知 識）やAbility（能力）にフォーカスしがち。 • Awareness（認知）やDesire（欲求）に対する 設計が弱いと、文化形成までは行き着きづら い。 • 具体施策を何にするかは各会社次第だが、 ADKARを意識しつつ、網羅的かつ、会社の各 フェーズの状態に応じた適切な施策を打つこと が肝要。
8. (参考) kubellにおけるADKARの施策例 • 全社総会・月次会 議での定期発信 • 新入社員のオン ボーディングへの 入れ込み Awareness （認知） • AIスキルレベル定 義（5段階）※詳細 次頁 • 特定のツール利用 にレベルの制限を 設けることによる 内発的動機付け Desire （欲求） • 月次会議での「事 例紹介」の実施 • スターターキット の提供（各種基礎 知識のリンク集) • kube-AIチャットで の情報提供 Knowlege （知識） • 個別勉強会・ワー クショップの実施 • 汎用的なGemやス キルの配布 • AIオペレーション マネージャーの体 制整備 Ability （能力） • 組織目標(評価)への 組み込み • マネージャーへの サーベイ・ダッ シュボードの公開 • 全社アワードでの 表彰 Reinforcement （定着）
9. (参考) kubellにおけるAI活用レベル Level 5 Level 4 Level 3 Level 2 Level 1 開発職 AIを利用して業界全体の生産性を上げられている状態 ・AIに関しての業界標準となるような手法の提唱をし、業界全体へ貢献で きる ・数多くの実績を持ち、登壇や執筆活動を通じて会社のAIブランディング へ貢献できる AIを利用してチームを超えて生産性を上げられている状態 ・LLMのプロダクトへの組み込みに関する知見を有し、AI機能実装へ貢献 できる ・AIに関する適切なガードレール設計ができ、セキュリティ・ガバナンス 策定が行える AIを利用してチームの生産性を上げられている状態 ・AIエージェント、RAG構築などを通じ、開発全体の生産性向上に貢献で きる ・AI利用を前提とした社内ドキュメントやデータ整備を実施し、AI利用を 促進させる環境整備ができる AIを利用して個人の生産性を上げられている状態 ・AIをエディタ/IDEに統合し、自力でコード補完や生成を活用できる ・生成AIの基礎を理解し、プロンプトを改善できる AIを利用することができる状態 ・AIと対話的にコード生成や情報収集を行い、基本的なプロンプティング でAIを扱える 非開発職 AIを利用して業界全体の生産性を上げられている状態 ・AIに関しての業界標準となるような手法の提唱をし、業界全体へ貢献で きる ・数多くの実績を持ち、登壇や執筆活動を通じて会社のAIブランディング へ貢献できる AIを利用してチームの生産性を上げられている状態 ・再現性や効率性の観点で他者が利用可能な形で展開し、所属部門の生産 性向上に貢献できる AIを利用することができる状態 ・日常的に対話型のAIを利用して業務を遂行している AIを利用して個人の生産性を上げられている状態 ・自律的にツールの利用や業務適応を通じて自身の業務の生産性向上がで きている AIを利用し始めた状態 ・自身の業務において社内で推奨されてるチャットベースのAIを試したこ とがある
10. ④環境整備 最初から完璧な環境を整えてからスタートするのではなく、段階的に拡張 エンジニアにとって「Gemini」で は物足りないシチュエーションが 徐々に発生。 特にコーディング支援やAIエー ジェントとしての活用のため、 「Claude Code」をプロダクト部 門で全面的に導入。 プロダクト部門での Claude Code展開 Google Workspaceの契約範囲内 で、「Gemini」を全社員が触れら れる状態に。 既存の全社基盤をベースとするこ とで、最小の追加コスト、展開ス ピード重視で、まずはAI活用が開 始できる土台を構築。 Gemini の 全社展開 世の中の事例も踏まえて、エンジ ニアに限らず「Claude」の有用性 が高まる。 「Gemini」は全社基盤として継続 しつつ、社内のAIスキルレベルに 応じ、非開発職に対しても 「Claude」の付与を開始。 非開発職への Claude展開
11. ⑤ガバナンス設計 安心して使えるルールをつくる 社員が利用する可能性のあるサービ スを、セキュリティ専門部隊が個別 に評価し、情報区分ごとの利用可否 や注意事項をまとめた一覧。（記事 執筆時点で50超のサービスが掲載） 社員が自分で判断できる状態を作る ことで、問い合わせ対応のコストを 減らしながら、現場の自律的な判断 を促す仕組み。 AIサービス 評価一覧 セキュリティの観点で最も軸となる ガイドライン。主に以下を記載。 ・情報区分別の入力ルール ・AI利用時の注意事項や禁止事項、 主要なツールごとの機能別利用可否 ・インシデント発生時の対応フロー 全社員が閲覧可能なドキュメントと して公開。オンボーディングにも組 み込み、新しく入った社員もすぐに 認識ができる状態に。 AI利用 ガイドライン 前述の非開発職向けのClaude利用に ついては、社内のセキュリティテス トで満点を取ることをアカウント付 与の条件としている。 セキュリティ専門部隊の監修によ り、リスクを本質的に正しく理解す るための学習機会として設計。 また、付与後に低利用が続く場合は アカウントを停止するルールも入れ ており、AIツールが不要に広く配ら る状態を防ぐ仕組みも整備。 利用条件の 設計 セキュリティ専門部隊への問い合わ せフォームを設置、「このサービス は使っていいか」「このケースはど う判断すればいいか」といった現場 からの相談を随時受け付け。 その問い合わせ内容を踏まえなが ら、ガイドラインやサービス評価を 継続的にアップデート。AIの進化に 合わせ、形骸化・陳腐化しない仕組 みを構築。 定期的な 見直し運用 「何でも使っていい」というルール不在は、現場を不安にさせむしろ推進を阻害する。 「使わせないためのルール」ではなく「安心して使うためのルール」として機能させる意識が肝要。
12. ⑥測定設計 感覚ではなくデータで回す 　確実な浸透のため、「何を測るか」を定義。 　サーベイ×システムデータの2軸で設計。 • サーベイ ◦ 2ヶ月に一度、全社員に対して実施 ◦ 単に使用状況を聞くだけでなく、 前述ADKARの浸透状態を意識して設計 • システムデータ ◦ 「Gemini」と「Claude」の利用データを、リ アルタイムでトラッキングできるダッシュ ボードを内製で作成 ◦ 主には、利用回数とアクティブ率、それらの 時系列トレンド、及び組織別・個人別ブレー クダウンの確認が可能
13. 終わりに 「kube-AI」はプロジェクトとしてはまだまだ道半ばであり、「これが正解である」と言い切れ るほどの完成度には達していません。 ただ、AIを個人のツールではなく「組織のOS」レベルまで浸透させていくには、組織文化の変 革として捉え、その前提で一連のプロセスを設計する必要性は強く感じています。③の組織変 革設計をADKARを軸にしたものにしているのもそれが理由です。 AI推進は、組織に「未知のものを面白がり、変化を許容する土壌があるか」を映し出す鏡のよ うなものでもあり、AI推進のプロセスそのものが次世代の組織文化を耕すことでもあります。 そして、AI活用によって生まれた時間をただの時間削減で終わらせず、その時間を「人間にし かできない業務」に再投資していき、AIと人間が本質的に協業する組織に変革していくことが 大事だと考えています。 今回の記事が、AI推進をこれから始めるという方、AI推進は始めているものの迷っている方に とって、少しでも参考になれば幸いです。