AI駆動開発が前提になる

AI駆動開発（AI driven Development）と呼ばれるシステム開発の方法が、普及しつつあります。これは、システム開発のプロセス全体にAI技術を活用し、効率化と品質向上を図る開発手法であり、従来に比べ、工数削減と高品質な開発を実現することを目指しています。

開発プロセスでAIをどのように使うかを以下にまとめました。

要件定義：要件の分析や整合性チェックを支援

設計：設計パターンを推奨し、ドキュメント作成を支援

コード生成：コード生成や補完、最適化

テスト：テストケースの生成や自動テストの実行を支援

デプロイ：インフラ構築やリソース管理を最適化

運用・保守：異常検知や予防保守を支援

AI駆動開発により、以下のような効果が期待できます。

開発効率の向上：AIによるコード生成やバグ検出支援により、開発サイクル全体が短縮。

品質の向上：AIによる自動テストは、人間の手によるテストよりも一貫性があり、高い精度で行われるため、リリース前の品質保証が強化。

コスト削減：自動化されたプロセスが増えることで、人件費や時間コストが削減。

具体的なAIツールをシステム開発プロセスにマッピングしたのが以下のチャートです。

このチャートは、日本総研のレポート「生成AIを活用したシステム開発の現状と展望（2024年09月30日）」を参考に作成しました。今後のシステム開発にAIがどのように使われるかを網羅的に紹介しており、大変参考になる資料です。

このレポートや昨今の動向を見ると、システムの開発や運用・保守にAIを使うことは、近い将来前提になることが分かります。結果として、ユーザー企業のシステム内製が広範囲に拡大し、その動きが加速すること、これにともないSI事業者の工数ビジネスの需要が減少し、新たな収益源の確保が必要となると考えられます。

かつては、算盤ができなければ仕事になりませんでした。いまやExcelやWordが使えなければ仕事になりません。同様の変化、すなわち「AIツールを使えなければシステム開発ができない」時代へと代わりつつあります。

ChatGPTが登場した2022年11月から2年足らずで、社会の様相が大きく変わりました。この変化は、今しばらくは加速度を増しつづけるでしょう。事実毎日のように新しいツールやサービスが登場し、性能の向上や適用範囲の拡大が続いています。AI駆動開発もそんなスピードに巻き込まれ、一気に「システム開発の前提」になることは間違えありません。

そこそこのエンジニアは仕事を奪われる

システム開発プロセス全般でAIの適用が拡大することを述べましたが、その影響は、短期的には限定的なものになると考えられます。ただ、コード生成やテストなどの工数ボリュームの大きい作業に於いては、既に大幅な生産性向上の実績もあり、AIを活かしたコード生成やテストのためツールの普及は、短期間のうちに急速に普及するでしょう。

このようなツールは、成熟したスキルの高いエンジニアほど、この恩恵は大きく、仕様書通りのコードを書くことを強いられているエンジニアや初学者にとっては、その恩恵を十分に受けることは難しいかもしれません。

これは、スキルの高いエンジニアが、AIによってアウトプットされた結果を評価し、必要な訂正を直ちに判断できる能力が高いからです。それは単にコーディング・スキルが高いと言うだけではなく、システム開発全般にわたって、包括的な知識やスキルを有しているからできることです。一方、スキルの低いエンジニアはその判断に手間取り、AI支援の恩恵を十分に生かし切れないからです。

このようになるのは、この段階での使い方は、既存のシステム開発プロセスを変えることなく、各プロセスのタスクをAIによって補完して、生産性や品質の向上を支援するという使い方が前提になるからです。

中期的には、システム開発に特化したAIエージェントの性能向上と普及により、システム開発プロセス全般の作業が完全に自動化されるようになります。

そうなると、エンジニアの役割も大きく変わります。つまり、「システムを開発すること」から、「何のためにどのようなシステムを作るのか」や「システムを活かすための業務プロセスの最適化」、「他システムとの連係」、「効果的なシステム配置とアーキテクチャー」といった、システム全般の包括的な知識を駆使した高次な役割をこれまで以上に期待されます。これをわかりやすく表現すれば、つぎのようになります。

「そこそこプログラムを書ける一般的なスキル・レベルのエンジニアの仕事はなくなり、ITシステム全般についての包括的な知識とスキルを持つエンジニアしか生き残れない。」

そんなAIネイティブの時代になると、システム開発は、AIエージェントが前提となることから、エンジニアは、指示や命令を自然言語で論理的かつ適切な表現で言語化できるスキルが必須となります。これには、システム技術的な、知識やスキルに留まらず業務や経営についての見識も求められます。また、AIモデルの特性の違いを理解し使い分ける、RAG（検索拡張生成）を使いこなすなどのAIエイティブ開発のスキルもまた必須になります。

エンジニアに求められるスキルが変わり、SI事業者の仕事も変わる

このような変化は、ITエンジニアに求められるスキルも大きく変えるでしょう。具体的には、次のようなスキルや知識が求められます。

ソフトウェア・エンジニアリング

データ・サイエンスと業務分析

AI／機械学習（ML）

このようなAIネイティブ時代になると、SI事業者とSI事業者の役割分担は大きく変わります。これを示したのが次のチャートです。

SI事業者の視点で捉えると次のような変化が起きます。

工数需要が減少し、AI前提の技術支援の需要が拡大する。

工数需要の減少は、短期的には、SESを主な収益源としている2次や3次の下請け事業者の収益を減少させる。中期的には、AIネイティブへの対処を先送りしていた1次請負事業者の収益をも減少させる。

SI事業者からユーザー企業への人材の流出が加速する。特に、AIネイティブを先取りし、独学でスキルを磨いていたエンジニアは、対処を怠ったSI事業者から急速に流出する。

これは10年先の話しではありません。数ヶ月から数年という時間感覚で捉えるべきでしょう。

工数見積の”完全”崩壊

システム開発における工数見積はAI駆動型開発を使った開発が普及することでもはや意味を持たなくなります。この点について、プログラミング言語や開発手法の歴史との関連で整理してみましょう。

＊PDFデータはこちらから

手続き型言語時代の明確な相関関係：

「COBOL」や「PL/I」といった手続き型言語の時代には、実装される機能とコードのステップ数（行数）との間に比較的明確な相関関係がありました。これらの言語では、一つの機能を実現するために必要なコード量が直接的に工数に影響を与えていたため、コード行数やステップ数を基にした見積もりが有効でした。開発プロセスも直線的で、タスクの分解や進捗の管理が比較的容易でした。

オブジェクト指向言語の登場と開発者スキルの影響：

「Java」などのオブジェクト指向言語が登場すると、コードの再利用性や抽象化が進み、一つのクラスやメソッドで複雑な機能を実現できるようになりました。しかし、これによりコード行数と機能の間の直接的な関係が薄れました。さらに、オブジェクト指向の設計・実装には高度なスキルが求められ、開発者の経験や能力によって生産性が大きく異なるようになりました。このため、従来のような定量的な指標に基づく工数見積の論理的根拠が弱まり、見積もりの精度が低下しました。

クラウドネイティブ開発により変化への俊敏性を獲得：

「HTML5/JS」や「Ruby」、「PHP」によるクラウドネイティブ開発は「クラウドの力をフル活用して、システムを小さな部品に分けて作り、必要に応じてすぐに変更や拡張ができる開発方法」と言えるでしょう。従来の開発は「一つの大きなシステムをじっくり作り上げ、変更や拡張には時間がかかる方法」であり、この点が大きな違いとなります。

クラウドネイティブ開発は現代のビジネス環境に適した、柔軟でスピーディーな開発手法であり、安定性はあるものの変化に対応しにくいという点で従来の開発とは異なります。

見積は、アジャイル見積もりは、ユーザーストーリーやタスクの複雑さを評価し、過去のプロジェクトデータを基に、機能ごとの工数を見積もりますが、過去のデータがない場合や、技術が大きく変わった場合には見積は難しくなります。

AI駆動型開発と工数見積のさらなる困難：

今後、AI駆動型開発やAIエージェントの普及により、コードの自動生成や最適化が進むと予想されます。AIは大量のコードを迅速に生成・修正できるため、人間の開発者が担当するタスクは設計や検証など、より抽象的で創造的な部分にシフトします。このような環境では、従来のコード行数や機能点数を基にした工数見積はほとんど意味を持たなくなります。さらに、AIツールの活用度や組織の成熟度によっても生産性が変動し、見積もりの不確実性が増大します。

工数見積は定義型言語でこそ成り立ちましたが、それ以降の手法では対応しきれない限界に直面していました。それは、開発者のスキルや定性的な要因が工数に大きく影響を与えるからです。そのため見積もりには新しいアプローチが必要です。アジャイル開発でのベロシティの活用など、適応的な見積もり手法を取り入れることで、これらの限界に対応していくことが求められます。

AI駆動開発は「改善」では対処できず、根本的な「変革」を迫られる

工数見積の根拠がもはや意味を持たないにもかかわらず、ユーザー企業側は、コスト予測の容易さやリスクの転嫁を求め、従来の調達プロセスを維持したいと考えています。これには、新しい開発手法への理解不足や不確実性への不安も背景にあると考えられます。

一方、SI事業者側は、自社のビジネス・モデルや収益構造を維持するため、工数見積に基づく契約を好みます。その背景には、リスク管理の容易さや新手法への対応コストを避けたいという思惑もあります。

結果として、業界全体としても、変革への抵抗感が存在し、新しい契約モデルや見積手法の標準化が進んでいません。このように、双方の思惑や業界の慣習が相まって、工数見積に基づく契約形態が依然として主流となっています。見積と実績が一致せず、トラブルとなるケースが頻繁に起きるのは、このような背景があるからです。

今後、AI駆動開発やAIネーティブ開発が広く普及すれば、契約モデルや見積手法の見直しが求められます。ここにいち早く手を付け、新たなユーザー企業やSI事業者の関係を築けることができるかどうかが、両者にとっての健全な関係、ひいては、ユーザー企業のIT活用の促進やSI事業者の存続と不可分です。

システム開発や運用にAI技術をどのように適用するかという側面だけではなく、契約関係を含む業界の慣習もまたAI時代にふさわしい変革が求められています。

いずれにしても、AI駆動型開発は、もはや前提となります。これに対処するには、新しい技術やプロセスへの理解と適応が不可欠です。つまり、既存のシステム開発の方法論の単純な「改善」にはなりません。コンテナやサーバーレス、マイクロサービスといった技術を前提に、アジャイル開発やDevOpsといったモダンな手法へと転換することで、その真価を存分に発揮できます。

これは、前述の通り、AI以前の話しであることを理解しておかなければなりません。まずは、この現実を直視し、必要な取り組みをすぐにでも始めるべきでしょう。

ユーザー企業は、このトレンドに乗じて、内製化の適用範囲を加速するでしょう。これを自分たちの事業に結びつけたいと考えるSI事業者にとっては、工数を売ることから技術力を売ることへと売り物を変えなくてはなりません。必然的に、収益構造の転換は不可避であり、事業内容や顧客との関係、契約など、事業や経営の根本の変革を強いられることになります。