【図解】コレ1枚でわかるシステム開発の手法/言語と見積
システム開発における工数見積はAI駆動型開発やAIエージェントを使った開発が普及することでもはや意味を持たなくなります。この点について、プログラミング言語や開発手法の歴史との関連で整理してみましょう。
手続き型言語時代の明確な相関関係:
「COBOL」や「PL/I」といった手続き型言語の時代には、実装される機能とコードのステップ数(行数)との間に比較的明確な相関関係がありました。これらの言語では、一つの機能を実現するために必要なコード量が直接的に工数に影響を与えていたため、コード行数やステップ数を基にした見積もりが有効でした。開発プロセスも直線的で、タスクの分解や進捗の管理が比較的容易でした。
オブジェクト指向言語の登場と開発者スキルの影響:
「Java」などのオブジェクト指向言語が登場すると、コードの再利用性や抽象化が進み、一つのクラスやメソッドで複雑な機能を実現できるようになりました。しかし、これによりコード行数と機能の間の直接的な関係が薄れました。さらに、オブジェクト指向の設計・実装には高度なスキルが求められ、開発者の経験や能力によって生産性が大きく異なるようになりました。このため、従来のような定量的な指標に基づく工数見積の論理的根拠が弱まり、見積もりの精度が低下しました。
AI駆動型開発と工数見積のさらなる困難:
今後、AI駆動型開発やAIエージェントの普及により、コードの自動生成や最適化が進むと予想されます。AIは大量のコードを迅速に生成・修正できるため、人間の開発者が担当するタスクは設計や検証など、より抽象的で創造的な部分にシフトします。このような環境では、従来のコード行数や機能点数を基にした工数見積はほとんど意味を持たなくなります。さらに、AIツールの活用度や組織の成熟度によっても生産性が変動し、見積もりの不確実性が増大します。
これらの変化により、工数見積は従来の定量的な手法では対応しきれない限界に直面しています。開発者のスキルやAIの活用度など、定性的な要因が工数に大きく影響を与えるため、見積もりには新しいアプローチが必要です。アジャイル開発でのベロシティの活用など、適応的な見積もり手法を取り入れることで、これらの限界に対応していくことが求められます。
工数見積の根拠がもはや意味を持たないにもかかわらず、ユーザー企業側は、コスト予測の容易さやリスクの転嫁を求め、従来の調達プロセスを維持したいと考えています。これには、新しい開発手法への理解不足や不確実性への不安も背景にあると考えられます。
一方、SI事業者側は、自社のビジネス・モデルや収益構造を維持するため、工数見積に基づく契約を好みます。その背景には、リスク管理の容易さや新手法への対応コストを避けたいという思惑もあります。
結果として、業界全体としても、変革への抵抗感が存在し、新しい契約モデルや見積手法の標準化が進んでいません。このように、双方の思惑や業界の慣習が相まって、工数見積に基づく契約形態が依然として主流となっています。見積と実績が一致せず、トラブルとなるケースが頻繁に起きるのは、このような背景があるからです。
今後、AI駆動開発やAIネーティブ開発が広く普及すれば、契約モデルや見積手法の見直しが求められます。ここにいち早く手を付け、新たなユーザー企業やSI事業者の関係を築けることができるかどうかが、両者にとっての健全な関係、ひいては、ユーザー企業のIT活用の促進やSI事業者の存続と不可分です。
システム開発や運用にAI技術をどのように適用するかという側面だけではなく、契約関係を含む業界の慣習もまたAI時代にふさわしい変革が求められています。
神社の杜のワーキング・プレイス 8MATO
8MATOのご紹介は、こちらをご覧下さい。
6月22日・販売開始!【図解】これ1枚でわかる最新ITトレンド・改訂第5版
生成AIを使えば、業務の効率爆上がり?
このソフトウェアを導入すれば、DXができる?
・・・そんな都合のいい「魔法の杖」はありません。