経営層は生成AIの活用を号令し、ライセンスは全社に配布済み。それでも開発のリードタイムと品質は変わっていない——いま、事業会社の開発組織からSIerまで、規模を問わず同じ相談が寄せられています。原因はツールでも現場の意欲でもありません。「ツールの導入」と「開発プロセスへの定着」が別の仕事であり、後者を担う人が組織のどこにもいないことです。本コラムでは、定着までの道のりを5段の階段に整理し、社内推進が止まる構造的な理由と、最初の2〜3ヶ月で作るべきものを解説します。
ある共通の風景があります。
経営会議で生成AIの活用が方針として掲げられ、GitHub CopilotやClaudeのライセンスが開発部門に配布される。若手を中心にAI推進の委員会が立ち上がる。数ヶ月後、経営層が「開発はどれくらい速くなったか」と問うと、答えられる数字がどこにもない——。
これは特定の会社の話ではありません。アルムナイSaaSを運営するHR Tech企業でも、物流大手のユーザー系SIerでも、物流コンサルティングを手がけるSI企業でも、私たちはほとんど同じ文言の課題を聞いています。実際、フリーランス人材の市場には「AI駆動開発の導入・定着を推進できる人」を求める案件が並び、月額単価は経験豊富なテックリード級の水準に達しています。組織の外にお金を払ってでも埋めたい欠落が、そこにあるということです。
課題の言い回しは各社さまざまですが、分解すると同じ3つに行き着きます。
注目すべきは、この3つのどれも「ツールが使えない」という話ではないことです。ツールはもう入っています。止まっているのは、その先です。
ツールの配布から組織としての定着までは、ひと続きの作業ではなく、性質の異なる5つの段階に分かれます。
段2までは調達の仕事、段3からは開発プロセス設計の仕事。性質が変わる段差で多くの組織が止まる。
多くの組織は段2で停滞する。段3以降は担当者と工数を割り当てない限り進まない。
多くの組織が止まっているのは、段2「個人利用」です。感度の高い数人が自分の作業にAIを使い、その人の生産性は確かに上がっている。しかし隣の席のメンバーは使っておらず、使っている人のやり方も共有されていない。この状態では、組織の数字——リードタイム、レビュー滞留、障害率——は動きません。個人の工夫は個人のものだからです。
段2と段3の間には、それまでと質の違う壁があります。段2までは「ツールを買って配る」という調達の仕事で登れますが、段3から先は開発プロセスを設計し直す仕事になるのです。どの工程でAIに何をさせるか、生成物を誰がどう検証するか、AIに読ませる資料（設計書・コーディング規約・過去の障害知見）をどう整備するか。これはツールの知識ではなく、開発プロセス改善の仕事であり、担当者を決めて工数を割り当てない限り、自然には誰もやりません。
「ツールは導入済みなのに変わらない」という状態は、失敗ではなく、単に階段の途中にいるだけです。ただし、段2から段3へは放っておいても登れない——ここが本コラムの出発点になります。
多くの組織は、この壁を「推進委員会」や「AIワーキンググループ」で越えようとします。そして、その多くが数ヶ月で失速します。委員会のメンバーが無能だからではありません。3つの欠落が重なる構造になっているからです。
| 欠落 | 何が起きるか |
|---|---|
| 工数の欠落 | メンバー全員が開発業務と兼務。検証や整備は「手が空いたら」になり、繁忙期に止まる |
| 経験の欠落 | 定着まで到達した経験者が社内にいない。何から着手すべきかの優先順位がつけられない |
| 事例の欠落 | 参照できる社内の成功事例がゼロ。説得材料がなく、懐疑的なメンバーを巻き込めない |
このうち最も重いのは経験の欠落です。工数は経営判断で確保できますし、事例は最初の一つが生まれれば解消します。しかし「どの工程から着手すれば早く成果が出るか」「生成AIのガイドラインには何を書き、何を書かなくてよいか」「効果測定はどの指標なら現場の負担なく取れるか」といった判断は、一度定着までやり切った経験がないと精度が出ません。手探りで進めると、検証だけで数ヶ月が過ぎ、その間に現場の期待値が下がっていきます。
もうひとつ見落とされがちなのは、失速のコストが「現状維持」では済まないことです。一度「AIをやってみたが大して変わらなかった」という空気が組織に定着すると、二度目の推進は最初よりはるかに難しくなります。段2で止まった状態を長く放置すること自体が、将来の選択肢を削っているのです。
では、段3から先へ登るには何をすればよいのか。私たちが支援の現場で最初の2〜3ヶ月に作るものは、次の4つに集約されます。
順序に意味がある。現状分析が先、ツール活用の設計は後。
1で取った基準値が4の効果測定の分母になる。設計図が先にあれば、レガシー保守からでも始められる。
順序に意味があります。現状分析が先、ツール活用の設計は後です。どの工程に工数がかかっているか、レビューはどこで滞留しているか、属人化している作業は何か——これを工程別に可視化しないまま「AIで何ができるか」から入ると、効果の薄い場所に労力を注ぐことになります。AIで解決できる課題の整理とは、課題の一覧が先にあって初めて成立する作業です。
ルールの整備には、書き方の要点がひとつあります。人間が読む「利用ガイドライン」と、AIに読ませる「コンテクスト」を分けて設計することです。コーディング規約、アーキテクチャの前提、過去の障害から得た禁則事項をAIが参照できる形式で整備しておくと、生成物の品質が個人のプロンプトの巧拙に依存しなくなります。ここが、段2（個人の工夫）と段4（組織のプロセス）を分ける技術的な分岐点です。
効果測定は、凝った指標より「経営に報告できる指標」を優先します。対象工程のリードタイム、レビューにかかる時間、テスト作成工数——着手前に基準値を取っておけば、2〜3ヶ月後には「やってみた」ではなく数字で報告できます。経営層の号令で始まった取り組みは、経営層に数字を返せた時点で初めて、予算と工数が継続的につく活動になります。
「うちは10年物のレガシーだから、AI駆動開発は新規開発の話だろう」という声をよく聞きます。実際は逆で、保守開発こそ効果が出やすい領域です。
理由は単純で、レガシーシステムの保守で工数を食っているのは、新しいコードを書く作業ではないからです。影響調査、テスト仕様書の作成、回帰テスト、レビュー、ドキュメントの復元——既存の資産を「読む」作業と「確かめる」作業が大半を占めます。そして生成AIが最も安定して力を発揮するのは、まさにこの領域です。
.NET系の業務システムでも、10年を超えるWMS（倉庫管理システム）でも、この3つは技術スタックをほとんど選びません。むしろ有利な点さえあります。保守開発は同種の作業が繰り返し発生するため、一度整備したルールとコンテクストの再利用回数が多く、整備コストの回収が早いのです。
新規のモダンな開発を待つ必要はありません。いま工数が最もかかっている場所が、最初のPoC（概念実証）の場所です。
ここまでの整理を踏まえると、外部支援に求めるべきものがはっきりします。第3章で見たとおり、社内に欠けているのは工数・経験・事例の3つでした。このうち外部から本当に調達すべきは経験であり、工数と事例は組織の中に作られるべきものです。
この区別を誤ると、支援の形が「代行」になります。外部の専門家がPoCを作り、ガイドラインを書き、成果を出して去っていく——一見成功に見えますが、契約が終わった瞬間に段2へ逆戻りします。ノウハウが個人（それも社外の個人）に残り、組織に残っていないからです。
私たちがAI駆動開発の導入・定着支援を「伴走」の形で設計しているのは、このためです。現状分析と設計図の作成は経験者が主導しつつ、PoCの実施もルールの整備も、貴社の開発メンバーと共同で進めます。ゴールは私たちが成果を出すことではなく、次の対象工程には貴社のメンバーだけで展開できる状態——つまり内製化です。定着とは、外部支援が不要になることの別名だからです。
判断の材料として、外部支援を検討する意味があるのは次のような状況です。
逆に、まだツールの配布すら済んでいない段階であれば、外部支援より先に社内の合意形成が必要です（その論点はAI駆動開発の最初のハードルは社内承認で扱っています）。
Chapter Techでは、本コラムで整理した現状分析から効果測定までの定着支援を、AI Delivery Scope+として提供しています。自社がいま階段のどの段にいるかの見立てからで構いません。現状の開発プロセスと課題感を、お問い合わせからお聞かせください。