AI時代のシステム開発は「作る力」より「決める力」が問われる
1. AIで「作る力」は急速に高まっている
生成AIの進化によって、システム開発の現場は大きく変わりつつあります。プログラムを書く、設計書のたたき台を作る、テストケースを洗い出す、コードレビューを行う、ドキュメントを整える。これまで多くの人手を必要としていた作業のかなりの部分が、AIによって支援されるようになっています。
Stack Overflow Developer Survey 2025では、回答者の84%が開発プロセスでAIツールを使っている、または使う予定があると回答し、プロ開発者の51%がAIツールを毎日使っているとされています。GitHubの調査では、Copilotを使った開発者は、使わない開発者よりもタスク完了が55%速かったとされ、別の調査ではコードがユニットテストを通過する可能性が53.2%高かったと報告されています。
日本国内でも、AIを使ったシステム開発はすでに一部の先進企業だけの取り組みではなくなりつつあります。Gartner Japanの2025年調査では、国内ソフトウェア開発従事者において「コード生成・補完」で49.0%、「コードレビュー」で40.0%、「要件定義」で39.8%がAI使用中と回答しています。前年調査では各工程の使用中割合が12.8〜21.2%だったことを踏まえると、国内でもAI活用は急速に広がっていると言えます。
JUASの「企業IT動向調査2026」速報でも、言語系生成AIは導入済み33.9%、試験導入・準備中を含めると53.4%に達し、コード系生成AIも32.6%となっています。IPA「DX動向2025」では生成AIに前向きな企業の割合は日本5割弱と、米国8割弱・ドイツ7割弱に比べ遅れはあるものの、特に大企業を中心に現実の開発現場へ広がりつつあります。
AIはすでに、コーディング、テストケース作成、単体テスト支援、コードレビュー、ドキュメント作成、既存コードの説明、エラー原因の特定、改修案の提示など、開発の幅広い領域に入り込んでいます。
ただし、ここで一気に「だから開発者はいらなくなる」という訳ではありません。作る速度が上がることは、必ずしも良いシステムができることを意味しません。むしろ、間違ったものを以前よりも速く、きれいに、もっともらしく作ってしまうリスクも高まります。
AI時代には、作る力の差は縮まる。だからこそ、何を作るべきかを決める力が、システム開発の成否を分ける。
2. AIで効率化が進むほど、上流の誤りが大きな問題になる
Google Cloudが公表したDORA 2024では、AI利用は開発者の生産性向上に寄与する一方で、AI導入の増加はソフトウェアデリバリーのスループットや安定性にマイナスの影響を与える可能性も示されています。具体的には、AI導入の25%増加に対して、コード品質やレビュー速度は改善する一方、デリバリースループットは1.5%低下、安定性は7.2%低下する推定が示されました。
つまり、AIで個々の作業は速くなるが、開発全体が必ず良くなるわけではないということです。
システム開発では、実装やテストの効率が上がっても、そもそもの要件が間違っていれば、完成するのは「間違ったシステム」です。AIは、与えられた前提に基づいてコードを書き、テストを作り、設計書を整えることは得意ですが、その前提が本当に正しいのか、業務として意味があるのか、現場が使い続けられるのかまでは、自動的に判断してくれません。
これまでは、設計や実装に多くの工数がかかっていたため、開発のボトルネックは「どう作るか」に見えやすかった。しかし、AIによって「どう作るか」の負荷が下がるほど、真のボトルネックは「何を作るか」「なぜ作るか」「どこまで作るか」に移っていきます。
AI時代の開発リスクは、作れないことではなく、決めないまま作れてしまうことである。
3. 要件定義は、単なるヒアリング結果の整理ではない
要件定義というと、現場にヒアリングをして要望を一覧化し、それをシステム機能に落とし込む作業だと考えられがちです。しかし、現場の要望をそのままシステム化しても、良いシステムになる訳ではありません。現場が語る「困りごと」は、現在の業務の中で見えている不便さであり、必ずしも本質的な業務課題そのものではないからです。
要件定義で問うべきは、「何を作りたいか」ではなく、「なぜ作りたいか」です。たとえば「承認画面を追加したい」「Excelの入力項目をそのままシステム化したい」「今ある帳票と同じものをBIで見たい」という要望があったとします。しかし本当に確認すべきなのは、なぜ承認が必要なのか、何を判断するための帳票なのか、その入力項目は誰がいつ何のために使うのか、そのデータがあることでどの意思決定が変わるのか、その業務は今後も同じやり方で残すべきなのか、です。
要件定義とは、業務でやりたいこと、システムでできること、運用でできることの重なりを最大化する作業です。
業務でやりたいことは、経営課題、業務課題、現場の困りごと、意思決定を変えたいポイント。システムでできることは、データモデル、マスタ構造、権限設計、画面構成、既存システム制約、AIやBIで実現できる範囲。運用でできることは、業務フロー、承認ルール、役割分担、入力・確認・更新の責任、現場が継続できる運用負荷です。
この3つがずれると、業務では必要だがデータが存在しない、システムでは実現できるが現場の運用負荷が高すぎる、現場は便利になるが経営上の意思決定にはつながらない、データは取れるが誰が更新責任を持つか決まっていない、画面はできたが業務フロー上で使うタイミングがない、といった状態に陥ります。こうしたシステムは「使えるもの」ではなく「作っただけのもの」になります。
要件定義とは、要望を集める作業ではなく、業務・データ・運用の最適な重なりを設計する作業である。
4. 要件定義で決めるべきは「業務」と「データ」である
要件定義を「機能一覧」や「画面一覧」に閉じてはいけません。要件定義で最初に決めるべきものは、機能ではなく「業務」と「データ」です。
どの業務を変えるのか。どの判断を変えるのか。どのデータを、誰が、いつ、どの粒度で登録・更新・確認するのか。ここが曖昧なまま画面や機能を作っても、業務の中で使われるシステムにはなりません。
要件定義で決めるべきことは、対象業務、変える業務と変えない業務、システムで支援する判断、管理対象データ、登録者・更新者・承認者、データ発生のタイミング、マスタの正、権限の単位、画面の目的、システム対応範囲と運用吸収範囲、初期リリース範囲と後続ステップ、と多岐にわたります。
そして要件定義では、何を作るかを決めることと同じくらい、何を作らないかを決めることが重要です。すべての要望を取り込もうとすると、システムは複雑になり、運用は重くなり、開発期間は長くなります。その結果、完成した頃には現場の期待とずれ、使われないシステムになることもあります。
最初から正解の要件が見えていることはほとんどありません。「この業務をこう変えればよいのではないか」「このデータを持てば判断できるのではないか」「この画面があれば現場は使えるのではないか」という仮説を作り、現場・システム・運用の観点から検証し、必要に応じて壊し、作り直す。この繰り返しこそが、要件定義の本質です。
要件定義は、業務とデータを軸に、作ること・作らないこと・運用で担保することを決めるプロセスである。
5. AIは要件定義を代替するのではなく、思考を支援する
要件定義でもAIは十分に活用できます。ただし、設計・実装フェーズのように決まった仕様をコードやテストに変換する使い方とは異なります。要件定義におけるAI活用は、答えを出させることではなく、人間の思考を広げ、論点を整理し、抜け漏れを減らすことにあります。
AIが得意なのは、ヒアリングメモの整理、課題一覧の分類、要件一覧のたたき台作成、業務フロー案の作成、画面項目・データ項目の候補出し、ステークホルダー別の影響整理、論点の抜け漏れ確認、要望と目的の対応関係の整理、現行とあるべき業務の比較、リスク・運用負荷の洗い出し、合意形成用資料のたたき台作成です。
一方で、AIだけでは決められないこともあります。何を優先するか、どこまでをシステム化するか、どこからを運用で吸収するか、どの業務を変えるか・残すか、現場にどこまで負担を求めるか、どのデータを正とするか、誰に責任を持たせるか、何を初期リリースから外すか、経営目的に照らして何を捨てるか。これらはすべて人間の判断領域です。
要件定義では、正しい答えを紙に書くだけでは不十分です。関係者が同じ言葉で理解し、同じ前提で判断できる状態を作る必要があります。ステークホルダー間で共通言語を作り、業務・データ・運用の前提をそろえ、最終的にサインオフを得ることが重要です。
さらに、要件定義で決めた内容は、システム部門だけで実現できるものではありません。データを入力する人、承認する人、確認する人、判断に使う人が、それぞれ新しい業務の進め方にコミットして初めて、システムは機能します。要件定義は単なる仕様決めではなく、関係者の納得と責任分担を作るプロセスでもあります。
AIは要件定義の作業を効率化できる。しかし、何を優先し、何を捨て、誰がどう運用するかを決めるのは、人間の判断である。
6. まとめ：AI時代に問われるのは「決める力」である
AI時代のシステム開発では、作る力の価値がなくなるわけではありません。しかし、作る力はAIによって大きく補完され、平準化されていきます。その結果、開発の成否を分けるのは、何を作るべきかを決める力になります。
要件定義とは、現場の要望をそのまま機能に変換する作業ではありません。業務でやりたいこと、システムでできること、運用でできることを見極め、その重なりを最大化する作業です。その過程では、「何を作るか」だけでなく、「何を作らないか」も決めなければなりません。また、業務とデータの関係を整理し、関係者の共通言語を作り、合意形成を進めることも要件定義フェーズでの重要な作業になります。
TKコンサルティングの要件定義支援では、スクラッチからのカスタマイズシステム構築をはじめ、数多くのシステム開発、導入、運用支援をしてきた経験を活かして、単にシステム機能を整理するだけではなく、業務・データ・運用の関係を整理し、現場の要望の背景にあるWhyを深掘りします。そのうえで、要件一覧、業務フロー、データモデル、画面構成、権限・承認設計、段階的なスコープ設定を通じて、関係者が納得して進められる要件定義を推進します。
AI時代だからこそ、システムを速く作る前に、何を作るべきかを正しく決めることが重要です。