(スライド版) 全社AI推進プロジェクト開始から半年で 組織に起きた5つの変化 〜kubellのkube-AIで見えた成果と課題〜 / ai-project-progress

以前、「AI推進は組織変革として進めるべき」という趣旨のスライドを公開しました。SaaSのようにツール導入としてもAI活用は全社に浸透しない、組織文化そのものを変革すると捉えて施策を設計すべきである、という内容です。
それに絶賛取り組んでいるのが、私がPMOとして関わっている「kube-AI（くべあい）」というkubellの全社プロジェクトです。
https://speakerdeck.com/takeshisumida_/ai-project

上記のスライドでは、主に「プロジェクトの推進手法」についてだったのですが、本格的に取り組み開始から半年が経ち、対外的な場でも「で、実際にどのような成果が出たのか？」について聞かれる機会が増えてきました。
そこで「プロジェクトによってどんな成果が出たのか、半年前と比べて景色がどう変わったのか」を中心にお伝えしたnoteを公開したところ、ありがたいことに大変多くの反響をいただきました。

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

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

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

Transcript

1. 【スライド版】 全社AI推進プロジェクト開始から半年で 組織に起きた5つの変化 〜kubellのkube-AIで見えた成果と課題〜
2. はじめに 全社的なAI活用の推進に課題を持つ経営層やプロジェクト責任者の方へ 角田 剛史 / Takeshi Sumida 株式会社kubellパートナー 執行役員 CAO コーポレート&ピープルディビジョン長 ▼X @takeshisumida_ ▼note @takeshisumida_ 本スライドは、noteの記事に基づいて作成されています 詳しくはぜひnoteをご覧ください
3. はじめに：kube-AIとは 「AIを組織のOSとし、全社の生産性と市場価値を飛躍させる」ことを目標とする全社プロジェクト きっかけ 由来 体制 方法論 年初の全社会議で、CEOが 「すべての戦略にAI活用を 強く組み込む」と宣言。 プロジェクト名のkube-AI （くべあい）は、kubellの 「薪をくべる」という社名 に由来。 PJオーナーは会社のトップ であるCEO、その上で、各 部門からキーパーソンをア サイン。 AI推進を「ツール導入」で はなく「組織文化の形成」 としてとらえる。 一方で当時は、使う人は使 い、使わない人はまったく 触らないという自主性に任 せられた点の状態。 「AIにお願いできること は、どんどんお願いして、 生産性の炎を大きくしてい きましょう」、という思い が込められている。 部門固有の取り組みの統合 ・可視化、またガバナンス 面の強化(情シス、セキュリ ティ)を実現する体制とし た。 ハンズオンで凄さを体感し ても、業務で使う意義を感 じていなければ翌日から触 らなくなる。まずは意識と 環境を整えることにフォー カス。
4. AI推進を「組織変革」として設計する6つの要素 変革管理のフレームワーク「ADKAR」を軸に設計、その上で感覚ではなくデータで回す体制を整備 1. 経営コミット AI活用を経営アジェンダの中核に置く 2. 体制設計 「誰が動かすか」を正しく設計する • 経営者が「なぜAIか」を自分の言葉で語る • PJオーナー（PO）を会社のトップとする • 戦略の最上位にAIを明示的に位置づける • 各部門からキーパーソンをアサインする • 一度限りでなく「定期的に」発信し続ける • 情報・コミュニケーション体制を整備する 3. 組織変革設計 変革管理のフレームワーク「ADKAR（ア ドカー）」を軸に設計 • Awareness（認知）やDesire（欲求）に対する設 計が弱いと、文化形成までは行き着きづらい • SNS等で見聞きした施策を手当たり次第行うので はなく、体系的かつ網羅的に施策を実行 4. 環境整備 使える土台を整える • 最初から完璧な環境を整えてからスタートするの 5. ガバナンス設計 6. 方法論 安心して使えるルールをつくる 感覚ではなくデータで回す • ではなく、段階的に拡張 ◦ 1. Geminiの全社展開 ◦ 2. プロダクト部門でのClaude Code展開 ◦ 3. 非開発職へのClaude展開 「何でも使っていい」というルール不在は、現場 を不安にさせ、むしろ推進を阻害する • サーベイ × システムデータの2軸で設計。 ◦ 「使わせないためのルール」ではなく「安心して 使うためのルール」として機能させる • • AI利用ガイドライン、AIサービス評価一覧を整備 サーベイ：2ヶ月に一度、全社員に対して 実施。 ◦ システムデータ：GeminiとClaudeの利用 データを、リアルタイムでトラッキング
5. (参考) 【スライド版】ツールを入れても浸透しない—AI推進を「組織変革」として設計する6つの要素 各要素の詳細については、前回のスライドをご参照ください https://speakerdeck.com/takeshisumida_/ai-project
6. 半年でのスコアの変化 ほぼ全てのスコアが改善し、「全社の底上げ」という初期目標を達成 • • • • 全社共通基盤であるGeminiまたはClaudeのいずれかを使用しているアクティブ率(MAU)は常に90%後半 初期2点台だったAI活用レベルは3超に向上、特にAIをチャットベースで会話する程度にとどまるボトム層の割合が1割台に激減 当初はきわめて限定的だったレベル4・レベル5のハイレベル層が3割以上となった 初期に存在していた部門間の温度差も全指標で解消された
7. プロジェクト半年経過後に起きた5つの変化 スコアが向上した結果、組織にどのような”変化”が起きたのか 1 各領域のエキスパートの自走 非開発職による業務改革が増加した 2 人の役割・視座の変化 職種の境界線が薄れ、越境が拡大した 3 仕組みの全社標準化 個人や部署の専門知識が全社展開された 4 外部への影響拡大 AIに関する個人発信が増加した 5 経営の評価軸の変化 「生産性」に対する見方が変わった
8. 1. 各領域のエキスパートの自走 非開発職による業務改革が増加した 採用業務 セキュリティチェック業務 BCP業務 630時間削減 8割の工数削減 1ヶ月の開発を3日で内製化 https://note.com/modern_pipit1612/n/n293b241deaa2 https://note.com/easy_tiger8668/n/nd3366c261ca4 https://note.com/mao_obata/n/ncd5ebe076dc5 初期はスコアが低かったバックオフィス・コーポレート部門から、その職種ならではの業務改善が次々と生まれたことが象 徴的。領域特化の改善には現場の深い知識が必要で、プロジェクトが一つひとつ入り込むには限界がある。短期間でこうし た事例が生まれたのは、AI活用が文化として根づいたからこそ。
9. 2. 人の役割・視座の変化 職種の境界線が薄れ、越境が拡大した ビジネス職 エンジニア職 企画・要件定義から実装まで自己完結 コーディングから、事業課題の解決へ 従来は、大規模・高度な改善にはエンジニアとの連携が 必要で、ビジネスの役割は、企画・要件定義まで。 コーディング時間が大幅に短縮され、事業課題に深く踏 み込んだり、現場の生の声を拾いにいったりと、ビジネ AIを壁打ち相手に、GASやCowork、Claude Codeなど ス領域への染み出しが増加。（例：顧客提案資料の作成 の仕組み構築、UI/UXデザインへの染み出し） を使い、開発・実装含めてビジネスで自己完結できるよ うに。 「ビジネス職だから作れない」「エンジニアだから現場要件が分からない」という言い訳が無くなり、職種の垣根を超えて 自発的に課題を見つけ、事業を動かす。そんな「ビジネスアーキテクト」が社内のあちこちで誕生している。
10. 3. 仕組みの全社標準化 個人や部署の専門知識が全社展開された 社内Webアプリの公開基盤 ブランド準拠のスライド作成基盤 「公開して」の一言で、社内限定Webアプリが完成 ブランドに沿ったスライドを、ブレなく作れる共通基盤 セキュリティを保ったまま、 AIによるスライド作成は 非開発職でもAIで作った 「何かちょっと違う」になりがち。 Webアプリを社内に公開できる 大元のテンプレートを管理していた 横断基盤。裏側の仕組みはGAS、 デザイナー自身が、アウトプットの この基盤自体もClaudeで構築。 ブレが小さい基盤を構築。 https://note.com/smitsunori/n/nbd9142cee380 個人や単一部署の効率化を超えて、部門の専門職の知識が全社共通のインフラとして全社員に展開。各自で車輪の再発明を することが減り、全社員の生産性向上に寄与。
11. 4. 外部への影響拡大 AIに関する個人発信が増加した • • 情報発信・メディア掲載・イベント登壇の総数は、プロジェクト開始前のおよそ10倍に 特定のメンバーだけでなく、多様な部署・社員から発信が生まれている 社内で 取り組む → 外部へ 発信する → 外部から 評価される → 社員が 誇りを感じる → 自走意欲が 高まる 再び、社内の取り組みを後押しする正の循環 元々意図して狙っていた施策。ADKARのReinforcement（定着）を、外部評価と社員の誇りで後押しする効果がある。加 えて、kubellがAIに本気であることに共感し、kubellに入社を志す人が増えることは、目標への到達を早めるという意味で も目指すべき姿。
12. 見えてきた課題 AIの活用効果は広く実感されている一方で、「生産性」指標は大きく動いていなかった 大きく前進した半年だったが、一方で、課題も見えてきた。 活用事例が拡大し、サーベイで聞く限りは業務時間の削減も広く実感されている中、「生産性」の観点では、 全社の定量的なトレンドがほとんど変わっていなかった。具体的には、この時点で特に見ていた指標は、「一 人当たり売上」と「G&A比率」。 しかし、これは考えてみると当然。この時点では組織体制や事業プロセスを再構築したわけではなく、効率化 により生み出された時間は他の作業に再配分されただけ、つまり個人の時間の使い方のバランスが変わっただ けの状態だった。 もちろん時間の使い方を変えれば、よりコア業務に取り組めるようになることで、一人当たり売上の要素であ る売上にも少なからず影響はあるはずだが、全社という観点においては、グラフを動かすほどの影響はまだな かった。 経営陣との振り返りで直面したこの現実を受け、今後追うべき指標を大きく変更、合わせて生産性指標を再定 義した。（後述）
13. (参考) 生産性とは 定義自体はAI時代以前から不変、フェーズに相応しいアウトプットとインプットをいかに定義するか アウトプット（成果） 生産性 = インプット（投入資源） インプット = ヒト・モノ・カネ・時間など アウトプット = 売上、付加価値、生産量、処理量など 生産性向上の2つの方向性 ・インプットを減らす = より少ないコストでこれまでと同じ成果を出す ・アウトプットを増やす = 同じコストでこれまで以上の成果を出す
14. 5. 経営の評価軸の変化 「生産性」に対する見方が変わった 生産性 • • = アウトプット： 売上 インプット： 人件費＋業務委託費＋システム利用料（AI含む） インプット：AI活用の拡大によりツール利用料が積み上がっている中、引き続きインプットを「人数」だけと捉えていると、生産性を見誤る。 一方で、AI費用だけを見るのは片手落ち。少人数化、外部委託の不要化、SaaSの置き換えまで含め、投入しているコストの全体の変化を見る。 アウトプット：最終的な事業成果である「売上」で括って見る。売上には無数の変動要素があるが、インプットを全投入コストと定義した以 上、対置させるのに最も適しているのは売上。制作物など各種質の向上も、結局は売上に結びつくととらえる。 全社一律の数値だけでは現場の具体アクションに繋がりにくいため、存在するすべての事業PLの単位でモニタリング。ただし新規 事業は別指標、事業フェーズに応じた検証プロセスと専用の指標を用意。 この生産性指標は「全社的な構造変化」をとらえるためのものであり、各部門が業務執行のために持っている実務KPIは、個人目標 との接続の観点からも、各レイヤーに応じた適切な指標を並行してモニタリング。
15. kube-AIのこれから 全社員が自走する基盤を整える「第1フェーズ」から、業務プロセス自体をAI前提で再設計する「第2フェーズ」に 第1フェーズ 第2フェーズ（現在） 全社員が自走する基盤づくり AI前提のプロセス再設計 認知・意欲を高め、ツールと環境を整えて、 全社員が自走する状態へ。 業務プロセス自体をAI前提で再設計し、 真の生産性向上と企業価値向上へ。 活動量評価：利用率・活用レベル・削減時間 アウトカム評価：事業成果・生産性 初期と異なり、現在のkube-AIにおいては、そこまでADKARを強く意識していない。「AI推進は組織文化の変革である」という前提 は変わっていないが、初期の認知（Awareness）や意欲（Desire）を高めるフェーズは、すでに完了したと考えているため。 全社員が日常的にAIを使い、必要に応じてツールを使い分ける。チャットでの対話にとどまらず、アプリ作成やワークフローまで活 用が広がり、部門の専門知識を活かした基盤が全社にまで展開されている。 これからは「いかにAIを使っているか」という利用頻度や使用時間を追いかける段階から卒業し、「いかに事業成果や全社の生産性 向上（アウトカム）に結びついているか」という本質的な経営課題にシフトしていく。