受託開発・SESの現場でAI駆動開発の話をすると、返ってくる反応はほぼ2通りです。「やらないとまずいのは分かっているが、何から手をつければいいか分からない」。もうひとつは「現場のエンジニアが個別にツールを使い始めていて、会社として統制できていない」。どちらも足りていないのはツールの知識ではなく、着手の順番です。本コラムでは、社内承認から始めて、案件1本での実測、開発標準への組み込み、そして見積り・契約への反映まで、ベンダーが進む道を4つの段階に分けて示します。各段階の詳細を扱った個別のコラムへの入口も兼ねています。
AI駆動開発の情報は、すでに十分すぎるほど流通しています。ツールの比較記事があり、プロンプトの書き方があり、先行事例があります。それでも受託開発・SESの経営者やPMと話すと、着手できていない会社が大半です。
理由を聞くと、ツールが分からないという答えはほとんど返ってきません。返ってくるのは順番の問いです。セキュリティ審査が先か、試験導入が先か。全社に配るのか、1案件で試すのか。顧客に言うのか、言わないのか。単価にどう反映するのか。どれも個別には答えのある問いですが、順番を誤ると前の段階の答えが後の段階を縛ります。
逆のパターンもあります。現場のエンジニアが個人アカウントでツールを使い始めていて、会社はそれを把握していないか、黙認している状態です。この状態は「導入済み」ではありません。顧客のコードや資料がどのツールに渡っているか会社が答えられない状態であり、統制の観点ではむしろ未着手より悪い位置にいます。
どちらの状態からでも、進む道は同じです。全体は4つの段階に分かれます。
各段階の成果物が、次の段階の前提になる。途中を飛ばした導入は、飛ばした段階の形で失敗する。
承認を飛ばせばシャドーITとして発覚し、実測を飛ばせば標準が形骸化し、標準を飛ばせば見積りの根拠を問われたときに答えられない。
段階の分け方には理由があります。各段階の成果物が、次の段階の前提になるからです。
社内承認(段階1)が通っていなければ、案件で使うこと自体が社内規程との衝突になります。案件1本の実測(段階2)がなければ、開発標準(段階3)は一般論の写しになり、現場に定着しません。開発標準として統制が回っていなければ、見積りや契約(段階4)で顧客に説明できる状態になりません。
逆に言えば、途中を飛ばした導入は、飛ばした段階の形で失敗します。承認を飛ばせばシャドーITとして発覚し、実測を飛ばせば標準が形骸化し、標準を飛ばせば見積りの根拠を問われたときに答えられません。
以降、段階ごとに要点を押さえます。段階1と段階3は個別のコラムで詳細を扱っているため、ここでは位置づけと最初の一歩に絞ります。
最初の段階は、技術の話ではありません。自社のセキュリティ規程・情報管理規程の中で、生成AIツールを業務利用してよい状態を作ることです。
受託の場合、扱うコードと資料は顧客の資産です。それを外部のサービスに送信することになるため、論点は自社の規程だけでは閉じません。顧客との秘密保持契約、再委託条項、そして案件ごとの顧客側セキュリティ基準が絡みます。ここを整理しないまま現場が使い始めると、発覚した時点で問題は技術ではなく契約の話になります。
押さえる項目は3つです。
この段階の進め方——稟議の通し方、情報システム部門・法務との論点整理——はAI駆動開発の最初のハードルは社内承認で詳細に扱っています。
なお、この段階は完璧を目指すと止まります。全案件で使える状態を最初から作る必要はなく、次の段階で使う1案件(多くは自社内の開発か、同意の取りやすい既存顧客の案件)について通れば先へ進めます。
4つの段階のうち、飛ばされることが最も多いのがこの段階です。承認が通ると、多くの会社は全社展開か研修に進みます。その前に、小さい案件を1本、実際にAI駆動で作りきることを挟むべきです。
理由は、この段階の成果物が「工数の実測値」だからです。
AI駆動開発の効果は、一般論としては語られ尽くしています。しかし「実装工程が何割縮むか」は、技術スタック、案件の性質、既存資産の状態で大きく変わります。自社の案件でどうなのかは、自社で測るしかありません。そしてこの数字は、後の段階すべての根拠になります。
測り方は難しくありません。案件を工程で割り、工程ごとに従来の見積り工数と実績工数を並べるだけです。精密である必要はなく、「実装は想定の40%で終わったが、レビューは減らなかった」という粒度で十分です。効いた工程と効かなかった工程の内訳こそが、次の段階で開発標準に落とす素材になります。
1本目の案件選びには条件があります。小さいこと、失敗しても事業に響かないこと、そして工程が一通り揃っていることです。社内ツールの開発や、自社サービスの周辺機能がよく合います。顧客案件で始める場合は、段階1で整理した同意の枠内で選びます。
段階2までは、少人数の取り組みで完結します。ここから先が組織の話です。
実測で分かった「効く工程・効かない工程」を、自社の開発標準に落とします。具体的には、工程ごとに何をAIに生成させ、誰が何を承認するのかを決め、生成の手順と禁止事項を個人の習熟ではなく仕組みの側に置くことです。この設計を持たないまま人数だけ増やすと、品質が個人のプロンプトの巧拙に依存し、案件ごとにばらつきます。
受託の主戦場であるウォーターフォール工程での統制設計——承認単位の切り方、正本の指定、生成と検証の分離、レビュー文書の作り方——はウォーターフォールでAI駆動開発を回すで工程別に扱っています。また、統制を実装として配布する形はClaude Code プロジェクトパックとしてGitHubで公開しています。
この段階で決めておくべきことがもうひとつあります。エンジニアの評価です。実装量やステップ数で測る評価が残っていると、AIに書かせることが評価上の不利になり、現場は標準に従う理由を失います。レビューの質、統制の遵守、仕様の切り方といった、AIに移らない部分を評価軸に足すことが、標準を定着させる条件になります。
最後の段階が、ベンダーにとって最も重い問いです。人月で見積もっている以上、工数の圧縮はそのまま売上の圧縮に見えます。「速くなったら儲からなくなるのではないか」。この不安が、経営として着手をためらう実質的な理由になっている会社は少なくありません。
まず、放置した場合に何が起きるかを確認します。自社が動かなくても、競合は動きます。実装工程の相場は下がり方向に動いており、従来の人月見積りは相見積りの場で説明を求められるようになります。「AIを使っていないので従来通りです」は、価格競争力の放棄と同義になっていきます。つまりこの問いは「対応するか否か」ではなく「どう対応するか」の問いです。
取りうる構えは3つあります。
持続するのは構え2と構え3の組み合わせ。構え1は移行期の形にとどまる。
実装(How)はコモディティ化し、価値はコンテクスト(What・Why)へ移る。
人月を温存して圧縮分を粗利にする構え(1)は、短期的には成立します。ただし顧客側も同じ情報を持ち始めており、実装工程の工数根拠を問われたときに説明が持ちません。移行期の形と割り切るべきです。
持続するのは(2)と(3)の組み合わせです。実装は工程として値下がりを受け入れ、その分を、値下がりしない側——要件定義、業務知識の翻訳、統制と品質保証、受入の設計——の比重を上げて取り返す。実装(How)がコモディティ化し、価値がコンテクスト(WhatとWhy)へ移るというこの構造は、SES・受託開発企業がFDEを名乗る日で扱った戦略の、見積りへの現れです。
契約面では、値付け以外に先回りして整理しておくべき論点が2つあります。
4段階を裏返すと、失敗の型が見えます。実際によく見るのは次の3つです。
ツール選定から入る。 「どのツールがいいか」は最も答えやすい問いなので、検討がここから始まりがちです。しかしツールの差は、統制と順番の差に比べれば小さい。段階1〜2を終える頃には現場が答えを持っています。
全社一斉で始める。 研修を全員に受けさせ、ライセンスを全員に配る形です。実測(段階2)と標準(段階3)を経ていないため、使う人と使わない人に割れ、数ヶ月後には「うちは導入したが効果が出なかった」という結論だけが残ります。導入の失敗ではなく、順番の失敗です。
現場任せで黙認する。 冒頭に挙げた状態です。動いているように見えますが、会社としては顧客資産の扱いを説明できず、個人の退職とともにノウハウが消えます。黙認は段階1の省略であり、いずれ契約の形で請求が来ます。
共通するのは、どれも「進んでいる感触」があることです。道標が要るのは、進んでいる感触と進んでいることが別物だからです。
現在地の確認から始めてください。
Chapter Techでは、この道筋を受託開発・SES企業と並走する形で支援しています。工程統制の設計と定着はエンタープライズDX & FDE支援サービス、デリバリー領域の拡張と直受けシフトはDelivery Scope+として提供しています。自社の現在地の見立てからで構いませんので、お問い合わせからご相談ください。
なお、発注側(事業会社)から見た同じ構造——実装工数が減っても外注費が自動では減らない理由——は、事業会社が外注費を減らすためのAI駆動開発で扱っています。顧客がどの経路で費用を下げに来るかを知っておくことは、段階4の設計の前提になります。