AIを広める前に農家と病院に学んだこと

Last updated at 2026-10-04Posted at 2026-10-03

AIを入れると、組織がもともと持っている強みも弱みも、そのまま大きくなります。土台が古いチームほど、速くはなっても、そのぶん不安定になります。

難しいのは、開発の土台が自分のチームにできていても、チーム外にどう広げるかです。
事例を調べていると、AIより前の時代、農業や医療が何十年も前に同じ問題を取り組み、うまくいった方法と効かなかった形、その両方を残していることを見つけました。

この記事で持ち帰ってほしいのは次の3つです。

AIの前に土台が要る理由を、上司に話せる言葉
他分野が見つけた、押しつけずに根づかせる原則と落とし穴
明日から使える棚卸しの観点、チェックリスト、測り方

急いでいる人は、5節の原則と8節のチェックリストだけでもどうぞ。

この記事は、システム開発チームでマネージャーをしている私（エンジニア歴15年以上）が、部署全体の底上げを任されたときに、調べたことの記録です。

1. AIを入れると速くはなっても不安定になる

AIを入れると、チームにすでにある強みも弱みも大きくなる。これが、Google CloudのDORAチームが2025年にまとめた調査報告の結論です（Google Cloud公式ブログ）。

調査は、世界の約5,000人の技術者に聞いたものです。

報告書は、土台がないとAIで生まれた生産性は一部にとどまり、後の工程の混乱で失われがちだとも書いています（DORA 2025レポート）。

速くはなります。ただ、自動テストやバージョン管理、速いフィードバックといった歯止めがないと、変更が増えたぶんだけ不安定になります（Google Cloud Blog）。

日本の数字もあります。AIを導入した企業のうち、効果が期待どおりか期待以上だったのは31.8%でした（情報処理推進機構、1,799社）。

最も多かったのは「一定の効果はあった」の50.6%です。使い道も、文書の要約や作成など、業務の効率化が中心でした（同）。

同じ調査で不足が目立ったのは、現場の知見と基礎的なAI知識を持ち、自社へのAI導入を推進できる人材でした（同）。現場とAIをつなぐ橋渡し役です。

同じころ、奇妙な流行も生まれました。AIのトークン消費量を社内でランキングにして、たくさん使った人を称える取り組みです。英語圏では「tokenmaxxing」と呼ばれています。

DORAはこれを、入力の量を数えているだけで、簡単にごまかせる指標だと批判しました。個人のスコアは有害だとまで書いています（DORA）。

では、AIの効果を出すには、何を先にやればいいのか。手がかりは、開発とは別の世界にありました。

2. 自分のチームでできたことが部署では通用しなかった

上司から、部署全体の開発の底上げを任されました。部署を見渡すと、開発の進め方も道具への慣れも、チームごとにさまざまでした。

声がかかったのは、私のチームでAIエージェントの導入が早く進んでいたからだと思います。メンバーの感度の高さに、ずいぶん助けられていました。

私がチームを引き継いだのは今年の4月、前任のマネージャーは実務に追われ、チームを見る時間がほとんど取れていませんでした。マネジメントが後回しになっている状態だったのが、私の最初の悩みです。

個人の問題というより、マネージャーにも実務が積まれ、チームを見る時間が仕組みとして確保されていなかったからだと思います。だから私は、まずその時間を取ることから始めました。

チームでやってきたことは地味です。月2回の1on1ではメンバーに話したいことを話してもらい、毎朝の朝会では「何かある？」と聞いていました。

全プロジェクトに顔を出して、どこが詰まっているかも見ていました。経験のない仕事も、まずできる人の補助から入ってもらい、任せる範囲を少しずつ広げていきました。

現場が推したAIエージェントは、チームの目標に入れて、業務として時間を確保しました。

最初はAIに対して様子見だったメンバーも、技術イベントに参加してもらい、変化を肌で感じてからは、自分のプロジェクトに入れたいと提案するようになりました。

チームの土台は整いました。でも、チームでのやり方を部署全体に広げようとして、手が止まりました。
チームでうまくいったのは、困りごとを1on1や朝会で直接聞けて、時間や仕事の配分を自分で決められたからです。

ほかのチームに対して、私はそのどちらも持っていませんでした。

次に考えたのは勉強会です。ですが「勉強会で毎日のやり方は変わるのか？」と疑問に思い調べるうちに、「エンジニアリングイネーブルメント」という言葉がヒットしました。

イネーブルメントは「できるようにする」という意味です。エンジニアが力を出せるように、組織として支える取り組みを指します。

この言葉を手がかりに、『エンジニアチームの生産性の高め方』（技術評論社、2024年）の第6章にたどり着きました。

研修や勉強会は誰にでも使えるぶん、自分の現場への読み替えが残ります。OJTは現場ですぐ使えますが、教える人で質がぶれます（技術評論社）。

広く届けることと、現場ですぐ使えることの両方を満たすように、現場に合ったナレッジやノウハウを組織として体系立てて届ける。それがイネーブルメントだ、という整理でした。

権限も距離もない相手に、新しいやり方をどう根づかせるか。医療には、この問いを専門に扱う「実装科学」という分野があります。

実装科学では、正しいやり方だけでは定着に足りないとされます。定着を左右するのは、根拠の質、現場の状況、進め方の支援の組み合わせです（PARIHS）。

3. 放っておけばどの現場も止まる

やり方の更新が止まるのは、誰かが怠けているからではありません。忙しい現場には、やり方を更新する仕組みも時間もないからです。

医療でも、研究論文が出てから現場に根づくまで平均17年かかるという報告がよく引用されます（医学界新聞）。止まるのは、むしろ普通のことです。

止まったままの現場にAIだけを入れると、1節で見たとおり不安定になります。では、AIの効果を出す条件は何か。DORAはそれを7つの能力にまとめています。主なものは次の4つです。

明確で、全員に周知されたAIポリシー
しっかりしたバージョン管理
小さな単位での作業
質の高い社内プラットフォーム

どれも組織の土台の話で、ツールの名前は一つも出てきません（Google Cloud公式ブログ）。

たとえばバージョン管理を、DORAはAI時代の安全網と呼んでいます。

こまめにコミットするほど個人に、ためらわず元に戻せるほどチームに、AIの効果が大きく出るという報告です（DORA）。

私がバージョン管理のありがたさを一番感じるのは、AIエージェントを何本も並べて同時に開発するときです。エージェントごとに作業場所を分け、変更を確かめてから、取り込むか捨てるかを決めます。

この並列の開発は、バージョン管理があって初めて成り立ちます。

Claude Codeの公式ドキュメントも、並列のセッションはgitの作業ツリー（worktree）で分けるよう案内しています（Claude Code Docs）。

# エージェントごとに作業場所を分ける
git worktree add ../wt-agent-a -b agent-a
git worktree add ../wt-agent-b -b agent-b

# 不要になったら片づける
git worktree list
git worktree remove ../wt-agent-a
# 取り込み済みのブランチだけ消せる
git branch -d agent-a

技術で大きくなるのは今ある力だけ、という考え方は、途上国の支援の現場からも出ていました。マイクロソフトの研究所でインドのIT支援に取り組んだ研究者、外山健太郎さんです。

外山さんはその経験から、著書『テクノロジーは貧困を救わない』で、技術で大きくなるのは、人と組織がもともと持っている力だけだと書いています（みすず書房）。

もっと古い警告もあります。1983年の論文「自動化の皮肉」は、自動化するほど人に残るのは難しい仕事になり、その技能は使わないうちに衰えると指摘しました。

2024年の研究は、生成AIでも同じことが起きていると報告しています（Simkuteほか）。AIに任せるほど、AIの出力を確かめる人の力が要ります。

4. 同じ仕事が別の名前で何十年も続いていた

新しいやり方を知っている人と、忙しく自分たちのやり方で回している現場。その間に立って、やり方を現場に根づかせる仕事があります。

調べていくと、この仕事は分野ごとに別の名前で、何十年も前から続いていました。

一番古いのは農業です。1948年に始まった協同農業普及事業では、都道府県の普及指導員が農家に直接会い、研究機関で生まれた技術を地域に合う形で広めます（農林水産省）。

農林水産省はこの事業を、研究機関と農業者をつなぐ双方向の橋渡し役と位置づけています（農林水産省）。いまも全国に約7,200人の普及指導員などがいます（同）。

病院の仕組みは、開発組織にほぼそのまま重なります。病院長のもとに置かれた感染対策チームがルールを整え、各病棟のリンクナースが自分の病棟で感染対策を広めます（日本医師会雑誌）。

リンクナースは、現場の問題をチームに返す役も担います。イギリスで確立された仕組みで、いまでは褥瘡（床ずれ）の対策や栄養サポートにも広がっています（ナース専科）。

営業の世界も、同じ問題に先にぶつかっていました。米国の調査会社Forresterが2009年に、「セールス・イネーブルメント」という継続的な取り組みとして定義しています（Forrester）。

IT企業は、販管費の平均19%を営業の支援に使っていました。ところがそのコストは、社内のあちこちの予算に紛れていました（Forrester）。

製品部門もマーケティングも人事も、善意で営業を助けようとした結果でした。15年以上前の数字ですが、開発組織で各チームが善意で別々に環境を整えるのと同じ構図です。

分野	呼び名	橋渡し役	学べること
農業	協同農業普及事業（1948年〜）	普及指導員	研究成果を、地域の条件に合わせて広める
医療	感染制御チーム（ICT）とリンクナース	病棟ごとの推進役	中央の小さなチームと、現場の推進役の二層で回す
教育	教員研修とコーチング（1980年代）	同僚のコーチ	見せるだけでは実践に移らない。練習と伴走が要る
国際協力	キャパシティ・ディベロップメント（JICA）	専門家と相手国の担当者	能力は外から移せない。相手が自力で伸ばし続けることがゴール
営業	セールス・イネーブルメント（2009年に定義）	イネーブルメント担当	場当たり的な支援を見える化し、マネージャーから支える
IT	Enabling Team（Team Topologies、2019年）	イネーブリングチーム	期間を区切って伴走し、相手が自分でできるようになったら離れる

分野ごとに名前が違うせいで、互いの知見はほとんど行き来していません。

「イネーブルメント」という言葉を、先行していた営業からエンジニアリングの世界に持ってきたことを示す出典を、私は見つけられませんでした。同じ問題に、別々の道からたどり着いたのだと思います。

5. 先人が見つけた押しつけずに根づかせる9つの原則

各分野の知見を重ねると、9つの原則にまとまりました。どれも、どこかの分野で効果が確かめられたか、失敗から学ばれたものです。

9つは、関わり方（1〜3）、進め方（4〜6）、体制（7〜9）に分かれます。体制が外側から支え、その内側で進め方と関わり方が成り立つ関係です。

何を整えるかは8節のチェックリストに、どう根づかせるかはこの9つにまとめています。

原則	やること	根拠になった分野
1. 代わりにやらない	問題の持ち主は各チームのまま。自分たちで解ける状態を目指す	組織開発（シャイン）、IT（BCG）
2. 呼ばれて行く	困りごとを起点に入る。よそのチームの当たり前を持ち込まず、現場に合わせる	農業（普及事業）
3. お手本は現場の中から探す	同じ制約の中でうまく回している人を見つけ、そのやり方を広める	国際保健（ポジティブ・デビアンス）
4. 見せるだけで終わらせない	デモは入口。実際の作業で一緒に手を動かし、つまずきを伴走で解く	教育（Joyce & Showers）
5. 小さく試し、広げる先でも手を動かす	手を挙げた1〜2チーム、1つの作業から始める。成果は隣に自然には広がらないので、広げる先でも一緒に手を動かす	普及研究（Rogers）、農業（農民学校）
6. 予防は、すぐ体感できる改善とセットで	バックアップやバージョン管理は効果が見えにくい。ビルド待ちの短縮など、体感できる改善と一緒に出す	普及研究（Rogers）
7. 守りはルール、作り方は支援	セキュリティ・AIの利用ルール・バックアップだけは全チーム共通に。ビルドやテストのやり方はチームが選ぶ	医療（感染対策）
8. リーダーを最初に支える	定着させるのは、毎日隣にいる各チームのリーダー	営業（CSO Insights）、医療（リンクナース）
9. 推進役が抜けても回る形にする	活動は恒常的に置き、各チームの定例や目標に組み込む。伴走は期間を区切って手を離す	営業、教育、製造、国際協力

表にしてみると、私がチームでやっていたことの多くが、どれかに当てはまっていました。話したいことを話す1on1や朝会の「何かある？」は原則2、補助から任せるやり方は原則4と9です。

メンバーを変えたのも、私の説明より技術イベントでの体験でした。チームで無意識にやれていたことを、部署全体では意図してやる必要があります。

一番悩んだのは原則7でした。強制はしたくない。けれど事故を防ぐための新しいやり方は、効果が目に見えにくく、広まるのが遅いことが知られています（Rogers）。

病院の感染対策チームは、病院長から権限を委ねられ、予防のルールが守られているかを確かめています（日本医師会雑誌）。その形にならい、ルールにするのは「守り」の3つに絞りました。

3つとは、セキュリティ、AIの利用ルール、バックアップです。どれも事故が起きると取り返しがつきません。ビルドやテストのやり方は、チームが選びます。

原則3にも助けられました。人は「できていない」と言われるより、すぐ隣にうまくやっている仲間がいると知ったほうが動きます。

ベトナムの子どもの栄養改善（1990年〜）では、同じ貧しさの中でも健康に育っている子の家庭を探し、そのやり方を住民どうしで広めました（国際保健医療）。

だから企画書には、「できていないところを直す」とは書かず、「開発の土台を一緒に更新する」と書きました。

権限なしに新しいやり方を広める方法は、ソフトウェア開発の世界でもパターン集になっています。

『Fearless Change』は、小さな成功を祝う、組織に顔の広い人の協力を得るなど、48の場面ごとの打ち手をまとめた本です（監訳者による一覧）。

6. 先人は効かなかった形も残していた

原則の裏には、効かなかった形があります。今回の調査で特に重く見たのは、次の3つです。

試した人の隣には広がらない

農業には、農家が畑で一緒に学ぶ「農民学校」という方法があり、途上国で広く行われてきました。参加した農家では、知識や収量、収入が上がります。

ところが、研究をまとめた系統的レビューでは、参加していない隣の農家に知識が広がっていませんでした（Waddingtonほか）。

大規模に行うと、効果も出ませんでした（同）。手を動かして覚えるやり方は、聞くだけでは移りにくいと分析されています（評価機関3ieの要約）。

開発チームでも、試行チームの成果は隣のチームに自然には広がらない、と考えておくほうが安全です。

推進役は置くだけでは足りず抜けると止まる

推進役を置いた組織では、新しいやり方が使われる割合が増える傾向がありました。調べられた7件の研究のうち5件です。ただ、どれも成果への効果ははっきりしていません（Santosほか）。

リンクナースの制度も、効果を示す頑健な証拠は乏しいとされます。効果を出す条件として挙がるのは、役割の明確化、実装の研修、病棟と病院の上からの支援です（Dekkerほか）。

2026年5月には、「推進役の逆説」を論じた研究も出ました。

推進役を有能にしている特徴から、その人が抜けたときの脆さも生まれる、という指摘です（実装科学の論文誌）。

研究者は、推進役に頼る形から、仕組みに頼る形へ移すことを勧めています（著者の解説）。推進役は、組織の力が育つまでの期間限定の存在として置く、という考え方です。

本業の外の集まりは消えやすい

1980年代の米国では、QCサークルが一気に広まりました。現場の有志が本来の組織とは別に集まり、品質の改善を話し合う小さなグループです。

ハーバード・ビジネス・レビューの論文は、その多くが衰えていったと書いています。

理由は、中間管理職の抵抗、予算の削減、参加者の熱が冷めることでした（HBR）。

日本でも、小集団活動を行う事業所は1984年の60.2%から2004年の30.9%に減りました。QCサークル本部は2002年に、活動を「業務一体」と位置づけ直しています（横浜国立大学の論文）。

勉強会や有志の活動も、本業の外に置いたままだと同じ道をたどりやすくなります。だから活動は、各チームの定例や目標の中に組み込みます。

16の落とし穴

ほかの分野が先にはまった落とし穴も含めて、表にしておきます。

16の落とし穴の表を開く

落とし穴	先に起きた分野	対策
試した人の隣には広がらない	農業	広げる先のチームでも、一緒に手を動かす
推進役を置くだけで、役割と時間がない	医療	役割を書き、時間を確保し、上が支える
推進役が抜けて止まる	営業・教育	副担当を置き、各チームの定例に組み込む
本業の外の集まりが消える	製造	活動を各チームの定例や目標に入れる
善意の支援がバラバラに行われ、隠れたコストになる	営業	棚卸しで隠れたコストを集計し、活動を一本にまとめる
作った資料が使われない	営業	使う側に聞いてから作り、使われ方を測る
研修やデモで終わり、行動が変わらない	教育・営業	練習と伴走を行い、定着度を一番重く測る
中央のチームが作って配る	IT	現場の必要から作り、横に広げる
御用聞き・何でも屋になる	営業・開発者体験	「代わりにやらない」を明文化し、依頼の一覧を公開する
専門家への依存が残る	IT・国際協力	「推進役なしで回せるチームの数」で評価する
ツールが先で使われない	IT・営業	ツールより先に困りごとと習慣を扱う
一度に全部やる	IT	上位2〜3件に絞る
予防の効果が見えず、関心が続かない	普及研究	すぐ体感できる改善とセットにし、ヒヤリハットを記録する
AIに任せて判断力が衰える	人間工学	AIの出力を確かめる力を「当たり前」に含める
外注して判断力を失う	行政学・経営学	判断と定着は社内に残す
「できていない」と指摘して反発を招く	国際保健	うまくやっている人から始める

表の中には、とくに痛い実例が残っているものもあります。

作った資料は、たいてい使われません。B2Bマーケティングでは、作ったコンテンツの60〜70%が使われずに終わるとされます（Forrester）。

主な原因は、使う側を知らずに作ることでした（同）。

ツールから入ると、使われません。開発者ポータルのBackstageは、Spotify社内ではほぼ全員が使っています。

ところが他社での平均利用率は10%ほどだと、Spotifyの担当者自身が話しています（The New Stack）。

理由は、開発者の困りごとを理解しないまま導入し、試験導入の段階を越えられないからだそうです（同）。

支援する側は、何でも屋になりがちです。開発者体験の専任チームには、持ち主のいない問題が次々に流れ込むと指摘されています（LeadDev）。

BCG Digital Venturesの支援チームは「代わりに作業して」という依頼を断るために、チームの作業の一覧（バックログ）を公開し、効果をデータで見せ続けました（InfoQ）。

7. 始め方は一緒に棚卸し

まず手をつけるのは、教育より実態の把握です。最初に見えている問題は一例にすぎず、もっと大きな問題が隠れていることもよくあります。

呼び方は「一緒に棚卸し」にしました。専門家が診断して処方する形がうまくいくのは、相手がその診断を受け入れ、自分で実行したときだけだからです。

組織心理学者シャインが、著書『人を助けるとはどういうことか』で説いていることです（英治出版）。

棚卸しでは、次の8つを見ます。

成果物：コードやデータのバージョン管理、バックアップ
仕事：タスク・進捗・バグの管理
知識：仕様やノウハウの置き場所、属人化
作り方：ビルドや環境構築の手作業、テスト、変更してから動作を確かめるまでの時間
守り：パスワードや鍵の扱い、ライセンス
AI：使い方、ルールの有無、社外のサービスに入れている情報
隠れたコスト：各チームが独自にやっている環境整備やツール作りの工数
うまくやっている人：同じ制約の中で回せている人と、そのやり方（原則3）

調べ方は3段構えにしました。まずは軽く答えられるアンケートで、困っていること・怖いことと、うまくいっているやり方を聞きます。何を使っているかは、その次です。

次に、各チームのリーダーに30分のヒアリングをします。余裕があれば、1チームの作業を半日見学します。本人にとって当たり前すぎて言葉にならないことは、見ないと見つかりません。

優先度は、被害の大きさ×起きやすさ×気づきにくさで付けます。製造業のFMEAという故障分析で使う考え方です（FMEAの解説）。

バックアップがない状態のように、問題が起きるまで誰も気づかないものほど上に来ます。取り返しのつかない被害が出るものは、点数にかかわらず先にやります。

古いやり方でも誰も困っておらず事故のリスクも低いなら、無理には変えません。

私が考えた最初の半年の順番は、次のとおりです。

時期	やること	上に見せる成果
1〜2か月目	上司と方針・工数の枠を決める。AIの利用ルールなど「守り」は全チームで先に始める。棚卸しを行う	全チームの棚卸し完了、優先度つきの課題リスト
3〜5か月目	手を挙げた1〜2チームで、実際の作業を題材に練習と伴走。予防の改善と、すぐ体感できる改善を組み合わせる	試行チームのチェックリスト達成率の変化
6か月目	定例で試行チームがデモをする。次の対象を決め、広げる先でも一緒に手を動かす	ビフォーアフターの数字と、現場の声

工数の目安は、推進側の定例が月1回30分、各チームの関わりが月2時間ほどです。小さく始めるほうが、承認も取りやすくなります。

8. 測るのは数えやすいものより行動

勉強会の参加人数や資料の閲覧数は、数えやすいぶん、つい目標にしたくなります。けれど行動の代わりにはなりません。

DORAは、コードの行数やコミット数で生産性を測ろうとしてきた歴史を振り返り、トークン消費量のランキングを同じ罠だと位置づけています（DORA）。

3節で触れたとおり、こまめなコミットは良い習慣です。けれどその数を成果の指標にしたとたん、数を増やすこと自体が目的になって意味を失います。

指標は3層に分けます。研修評価の古典であるカークパトリックの4段階評価（反応・学習・行動・結果）と対応させると、上にも説明しやすくなります（日本の人事部）。

反応は活動量に、行動は定着度に、結果は効果にあたります。学習の段階は、試行チームとの伴走の中で確かめます。

層	目的	指標の例	頻度
活動量	止まっていないことを示す	棚卸しを終えたチームの割合、アンケートの回答率、定例の開催数	毎月
定着度（本命）	土台がどこまで整ったか	下の「当たり前チェックリスト」の達成率（チーム単位）	節目ごと
効果	土台を整えて何が良くなったか	環境構築にかかる時間、ビルドや確認の待ち時間、新しく入った人が最初の変更を取り込むまでの日数、ヒヤリハットの件数	半期ごと

新しく入った人が最初の変更を取り込むまでの日数は、安く測れて、改善も見えやすい指標です。

Spotifyは、新人が10本目のプルリクエストをマージするまでの日数をいちばん大事な指標にして、60日から20日未満まで縮めました（Spotify）。

最後に見る指標は、推進役なしで回せるチームの数です。国際協力でも、能力は外から移すものでなく、相手が自分で伸ばし続けるものだと定義されています（JICA）。

6節の「推進役の逆説」を受けて、節目ごとに一つ問いを足します。いまの推進役が明日いなくなっても、このチームは回るか。

研究者も、推進役が抜けた場面を想定して確かめることを勧めています（著者の解説）。

数字は個人の評価に使わず、チーム単位でだけ扱います。個人の評価に使ったとたん、人は数字を良く見せる方向に動くからです。

開発の「当たり前」チェックリスト

コピーして、自分のチームで試してみてください。

成果物と知識

コードはすべてバージョン管理下にある
画像やデータなど、コード以外の成果物も履歴を追える
バックアップがあり、実際に戻せることを一度試した
タスクとバグを、チーム全員が見られる場所で管理している
仕様と「なぜそう決めたか」が、特定の人の頭の外にある

作り方

新しく入った人が、手順書だけで開発環境を作れる
誰でも同じ手順でビルドできる
ビルドが自動化されている
自動テストが少しでもある
変更してから動作を確かめるまでの時間を知っている

守りとAI

パスワードや鍵を、コードやチャットに直接書いていない
使っているライブラリや素材のライセンスを確かめている
AIの利用ルールがあり、全員が知っている
社外のAIに入れてはいけない情報がはっきりしている
AIが書いたコードも、人がレビューしてから取り込んでいる

チームの到達度は、レベルでも見せます。Googleの有志が自動テストを広めたときの段階認定「Test Certified」にならった形です（Mike Bland）。

レベル	状態
Lv1	全コードがバージョン管理下にある
Lv2	誰でも手順どおりにビルドできる
Lv3	ビルドが自動化されている
Lv4	自動テストが少しある
Lv5	CIが回っている

「試行チームがLv1からLv3へ」と、一言で変化を伝えられます。

9. 上に説明するときは3つの言葉を用意する

土台づくりは、成果が見えるまでに時間がかかります。

2026年に出たDORAのROIレポートも、AI導入の効果はいったん落ち込んでから上がるJカーブを描くと説明しています（InfoQ）。

普及研究の古典では、明らかに優れたトウモロコシの新品種でさえ、アメリカの農家に広まるまで10年以上かかっています（『イノベーションの普及』）。

だから始める前に、上の理解を得ておく必要があります。私が用意した言葉は3つです。

一つめは「病院が実施している感染対策、その開発版です」。専門のチームがルールを整え、各病棟の推進役と組んで、手洗いの習慣を現場に根づかせる仕組みです。

誰でも知っている仕組みなので、一言で伝わります。効果の証拠としてではなく、仕組みを伝える例えとして使います。

二つめは「見えていない業務を、見える化します」。営業では、場当たり的な支援のコストが販管費の19%に達しながら、誰も気づいていませんでした。

棚卸しで各チームの隠れた工数を集めれば、数字で話せます。

三つめは「作業は外に出せますが、判断と定着は社内に残します」。
「派遣や外注で済むのでは？」とは、必ず聞かれます。

行政学には「スマートバイヤー」という議論があります。

外注する側が、何を買い、何を受け取ったかを判断できなければ、外注はかえって問題を悪化させる、というものです（Kettl）。

経営学でも、外の知識を使いこなす力は、社内にある関連知識の量で決まるとされています（赤門マネジメント・レビュー）。

AIで大きくなるのは自社の力なので、土台を外に預けると、力がつくのは外注先の側になります。

説明資料の骨格には、1枚の「憲章」を作ります。書くのは、目的、対象、扱う課題、提供する支援、成果の測り方、そして「代わりに作業はしない」の6点です。

営業分野の調査では、正式なビジョンと憲章を持つ組織の成果達成率が51.3%、単発のプロジェクトとして進めた組織は34.7%でした（CSO Insights）。

相関なので、因果までは言えません。

憲章は、こんな1枚のイメージです。

開発力強化（イネーブルメント）憲章

目的：AIの効果を出すための開発の土台を、各チームが自分で回せる状態にする

対象：部署の開発チーム（まずは手を挙げた1〜2チーム）

扱う課題：棚卸しで優先度が高かった上位2〜3件

提供する支援：棚卸し、試行チームへの伴走、定例でのデモ共有、チェックリスト

成果の測り方：チェックリスト達成率、環境構築やビルド待ちの時間、推進役なしで回せるチームの数

やらないこと：各チームの代わりに作業はしない

「イネーブルメント」というカタカナのままだと、開発の外の人にはまず伝わりません。資料では「開発力強化（イネーブルメント）」のように、日本語を主にしました。

10. 来週やる3つのこと

やろうと思うだけより、いつ何をするかを先に決めたほうが、人は実際に動きます。

94の検証をまとめた研究でも、はっきりした効果が出ています（Gollwitzerほか）。

そこで最後は、この形で書きます。

次のチーム定例が来たら、「最近いちばん怖かったこと」と「最近うまくいったこと」を1つずつ聞く
上司と話す機会が来たら、「土台づくりしませんか」を相談する
来週の金曜日、上のチェックリストで自分のチームを採点し、点数を残す。それが、あなたのチームの出発点になる

AIの話から始めた記事ですが、来週やる3つにAIの使い方の話は一つも出てきません。AIの効果を出すために先にやることは、人と仕組みの側にあります。

付録

主な参考文献

AIと開発の土台

橋渡しの仕事の先行分野

効かなかった形

営業とエンジニアのイネーブルメント

執筆中の調査限界

ここに書いた原則は、私ひとりの力ではありません。AIにシステム以外の分野や国外事例を探してもらった結果です。各実践と研究の根拠は必ず出典付きで置いています。
リンクナースや推進役の効果には頑健な証拠が乏しく、病院の例えにも限界があります。
農民学校の研究は途上国の農業が対象で、開発チームにそのまま当てはまるとは限りません。
営業分野で効果を示す数字の多くはツールベンダー発の調査で、相関にとどまります。
日本の小集団活動の実施率は、調査年ごとに対象や定義が少しずつ違い、厳密には比べられません。
医療でよく引かれる「17年」は、測る区間によって数字が大きく変わるという批判があります。
エンジニアリングの世界が営業から言葉を持ってきたことを示す出典は、見つけられませんでした。

AIの利用について

この記事の調査と下書きには生成AIを使いました。事実と出典はすべて私が確認し、体験の部分は私の言葉で書いています。

更新履歴

2026/10/03：公開

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up