§この章の導入
コーチングで一番よくある相談は、「自分がAIを使えるようになった、次はどうやって社員に広げるか」というものです。経営コンサル・M&A会社の社長も、人材紹介会社の経営者も、順番として必ずここに来ます。最初は自分のPCで動くようになって感動し、次の週には「これを社内全員に使わせたい」「AI推進部を作ろうと思う」「研修プログラムを組みたい」という話を持ってきます。
この章では、それらの「よくある打ち手」がなぜ空振るのか、代わりに何をすればチームや会社にAIが根付くのかを、コーチング現場で実際に効果が出たものだけまとめます。5つの節に分けて扱いますので、経営者(社長・役員クラス)の方も、コーチング側で伝える立場の方も、順に読み進めてください。
なお、本章はセットアップ済みの環境(第1章・第2章で扱ったClaude CodeやCodexの導入)を前提に書いています。まだ導入前の方は、演習の一部は Web の Claude や ChatGPT で代替できますので、そちらで試してから読み進めていただいて構いません。
§1. 経営者自身がAIを覚える(社員に覚えさせるより速い)
社長自身がAIを触って、自分で作れる状態になっていること
§解説
チーム展開を考える前に、絶対に飛ばしてはいけない前提があります。社長自身がAIを触って、自分で作れる状態になっていることです。この順番を逆にすると、多くの場合失敗します。
なぜかというと、AIへのインプットの質は、事業に対する解像度と全体像の把握速度でほぼ決まるからです。「うちのビジネスで何が本当のボトルネックか」「この作業を自動化したときに何が困るか」「この数字が動いたときにPLのどこにヒットするか」——これらは、社長が一番速く、一番深く分かっています。
社員が同じ質問をAIに投げても、そもそも問いの解像度が違います。だから同じClaude Code、同じCodexを触っても、社長が触った方が圧倒的に速く、良いアウトプットが出ます。
もう一つの理由は、社長が触っていないと、社員の成果物を評価できないことです。若手がAIで作ってきた提案書を、社長が「良し悪しの判断基準」を持っていないままレビューすると、結局現場の自己満足で終わります。
経営者がやった方が圧倒的にいい。社員にAIを覚えさせるよりも、社長が覚えて自分で作る方が早い
§2. AI専任部署は作らない(マネジメント定義に組み込む)
専任部署は作らない方が良いです
§解説
「AI推進部を作りたい」「AI活用チームを立ち上げたい」というご相談を、これまで何度も受けてきました。理由はシンプルで、AI推進部を作ると「AIを推進すること」自体が仕事になってしまい、数字に落ちるまで距離が生まれるからです。
正しい設計は、マネージャー全員がAIを日常的に使う状態を作ることです。マネージャーの役割定義を「AIを実装しながら数字を出す」に書き換える。これだけです。専任部署に切り出すのではなく、既存の管理職ラインに埋め込む。こうすると、AIは「推進する対象」ではなく「毎日使う道具」になります。
もう一つ大事なのが、社員向けのAIリスキリング研修に大きな期待をしないことです。全社研修は基本的に効きません。研修終了後の短い期間で全員が元のExcelとメールに戻るからです。研修で覚えたことは、翌週に使わなければ完全に忘れます。人間はそういう作りです。だから研修に予算を割くよりも、マネージャー全員が「AIを使わないと自分の数字が達成できない」状況を作る方が圧倒的に速いです。
代わりに全社に向けて発信するメッセージは、シンプルな一言で十分です。「AIを使えなかったら3年でポンコツになる」。これを社長から繰り返し伝える。危機感ドリブンで良いです。優しい言い方は、この局面では逆効果になることが多いです。
AI使えなかったら3年でポンコツになる
- 「AIを推進すること」自体が仕事になってしまい
- 数字に落ちるまで距離が生まれる
- 全社研修は基本的に効きません
- マネージャーの役割定義を「AIを実装しながら数字を出す」に書き換える
- 既存の管理職ラインに埋め込む
- AIは「推進する対象」ではなく「毎日使う道具」になります
§3. 社内ツールは作っても使われない、作れる人を育てろ
使う本人が自分で作れるようになる方向に投資するのが正解です
§解説
これも多い相談です。「営業チームで事例検索の需要があるから、AIで社内ツールを作って配りたい」「経理向けに請求書チェックのツールを内製したい」——気持ちはとても分かります。分かるのですが、予言します。使われません。
なぜかというと、社内ツールは「作った人が欲しいもの」と「使う人が欲しいもの」が微妙にズレるからです。使う側は自分の業務フローの中で「これは違う」「もう1個ボタンが欲しい」と細かい不満が出ます。その調整コストは、実は使う本人が自分で作った方が圧倒的に安いです。だから、ツール配布ではなく、使う本人が自分で作れるようになる方向に投資するのが正解です。
コーチングの現場では、この考え方を「わざマシン化」という言い方で伝えることもあります。ポケモンに出てくる「わざマシン」の比喩で、定型作業の型を1個のスキル(=わざマシン)として保存し、次回から全部教え直さずに使い回すという考え方です。ただし配るのはツールではなく、スキルの作り方と、AI自体を触る力です。ゴールは、メンバー全員が「AIで自分が欲しいものを勝手に作れる状態」に到達することです。
- 「作った人が欲しいもの」と「使う人が欲しいもの」が微妙にズレる
- 「これは違う」「もう1個ボタンが欲しい」
- その調整コストは、実は使う本人が自分で作った方が圧倒的に安いです
- 配るのはツールではなく、スキルの作り方と、AI自体を触る力です
- メンバー全員が「AIで自分が欲しいものを勝手に作れる状態」に到達すること
§4. エンジニア採用要件(3年以上・出社必須・紹介ルート)
ここで採用要件を間違えると、長期間を無駄にします。
§解説
チーム展開のフェーズに入ると、必ず「エンジニアを採用したい」という話が出ます。マネージャーがAIを触る、社員も触る、と広げていくと、どうしても社内で技術判断ができる人が1人は必要になります。
コーチング現場で伝えている鉄則は3つです。
1つ目、開発経験は最低3年、できれば5年以上。理由は明確です。直近1〜2年しか経験がないエンジニアは、実はAIネイティブ世代でして、コードは書けるのですがgit(=コード変更の履歴を管理する仕組み)、サーバーの基礎、環境変数(=APIキーやパスワードなどの秘密情報をコードに直書きせず外から渡す仕組み)といった土台の理解が抜けていることが多いです。
AIが便利すぎて基礎を通らずに現場に出てきているケースが増えています。この人たちに社内の重要システムを触らせると、後で必ず事故ります。「3年以上」というのは、AIがまだそこまで使えなかった時代に手で書いた経験があるかどうか、の線引きです。
2つ目、週2以上は出社必須。フルリモートは、この採用に限っては見送った方が良いです。理由は、AI時代のエンジニアは「経営者や現場と一緒に画面を見て、その場で試行錯誤する」ことが仕事の中心になるからです。フルリモートだとこの部分の速度が出ません。特に導入初期は、隣に座って一緒にAIを触る時間の質が決定的に効きます。
3つ目、可能な限り知り合い紹介ルート。転職サイトや人材紹介経由の応募も悪くはないのですが、AI時代のエンジニアは技術力の見極めが本当に難しいです。GitHubを見ても、コミット履歴を見ても、実力の判定にはあまり役立ちません。それよりも、信頼できる人が「あの人は良いですよ」と紹介してくれるルートの方が、圧倒的に外しません。
これに加えて、人物軸も忘れないでください。「飲んでて楽しい人」「話していて頭の回転が伝わってくる人」。技術力だけで採用すると、社内でずっと孤立します。ビジネス理解は最低限で良いです、そこは経営者が補えます。
最後に、いきなり正社員採用ではなく、まず業務委託かアドバイザーからスタートするのが安全です。少ない時間数の契約から入り、相性を見てから正社員に切り替える。この方が、経営者側もエンジニア側もリスクが少ないです。
コーチングの現場でお伝えしているコツをもう一つ。マネージャー層に1人、自由に使えるエンジニアを配置してください。この配置は、費用対効果を厳密に計算しないでください。マネージャーが「これAIでやれる?」と相談した時に、その場で試して短時間で動くものが出てくる。この速度が組織全体の生産性を上げます。専任部署は要らないと先ほど書きましたが、マネージャーに1人つく自由エンジニア、これはむしろ強く推奨します。
最低でも3年以上開発してる人。直近1-2年だとAIで書いてるだけで基礎が抜けてる
§5. 意図的な痛み体験(基礎の必要性を実感させる)
AIを教える時、抽象的な説明では腹落ちしません。意図的に「痛み」を体験させることが、実は最速の教え方です
§解説
これは、コーチング側のテクニックの話でもあり、経営者ご自身が社員を育てる時の考え方の話でもあります。
例えば、Claude Codeには過去のセッション履歴を呼び出す機能があります。これを最初から丁寧に説明しても、多くの方は「へえ、そうなんですね」で終わります。しばらく経つと忘れています。
だから私は、コーチングでは3回目あたりのセッション冒頭で、いきなり「今、過去のセッションを呼び出してみてください」とお願いします。当然、記録の残し方を教えていないので、過去は出てきません。「あれ、消えてる」「先週やったのに」——この5秒のショックが、その後の学習速度を大きく上げます。
これは意地悪でやっているのではありません。人間は、痛みや失敗から学ぶようにできています。「最初は覚えている風なんですが、しばらく経つと『覚えてないな』とキレ出す人が多いんです」。だから、キレる前に、意図的に体験させる。これがコーチとしての設計です。
同じ考え方は、社員教育にも使えます。研修で「AIを使えないと困りますよ」と言っても、社員は困ると思っていません。だから、社員自身が「これAIでやってみて」と振られて、短時間でできるはずのことに何時間もかかった、という体験を先にさせる。この体験の後で研修をやると、吸収率が全く違います。
もう一つ、コーチングでよく使う例えが野球です。「AIでホームランを打ちたい」と言う経営者は多いのですが、実際にはバッティング練習(プロンプトの型)、守備練習(記録の残し方)、走塁練習(モデルの使い分け)といった地味な基礎練を積んでいないケースがほとんどです。「基礎練しないでホームランは打てないですよ、これは野球と同じです」とお伝えすると、野球経験のある方はほぼ納得されます。
日々の練習を積んでいないから、大きな成果が出ないだけです。これも、抽象論より一発で通じる伝え方です。
最初は覚えてる風なんで1ヶ月後にキレ出す人が多い