株式会社リソース・シェアリング スポンサードサーチ
最近、X（旧Twitter）などで、AIの台頭により「SIerはもういらない（消える）」というお話を良く目にします。
最近のAIブームも重なって、AIに任せると「仕様書も書ける」「コードも生成できる」「なら間に入るSIerはいらないのではないか」という空気は、以前よりも強まっているように感じます。
実際、その問題提起自体は非常に本質的です。
特に、実際の現場でコードを書いたことがない人や複雑なシステム開発プロジェクトに関わったことがない人ほど、「SIerは不要だ」ということを語りがちです。
しかし、「SIerは不要」というのと、「AIでSIerは不要」というのは全く別の議論です。
ここを明確に切り分けて議論をしないと、物事の本質を見失うことになってしまいます。
そこで、今回は「SIerが不要」と「AIでSIerが不要」という話について見ていきたいと思います。
「SIerは不要」なのか、「特定のSIerが不要」なのか
「SIerは不要」という話には、私も同意をする部分は多くあります。
例えば、日本のSIerが主導するシステム開発プロジェクトにおいて、実際のシステムの開発に携わるメンバーがSIerの社員であることはほぼありません。
日本のIT業界の問題
このような現場では、SIerは上流工程だけを行い、実際のシステム開発では、SES（システムエンジニアリングサービス）と呼ばれるITエンジニアがSIerやSIerの顧客企業に常駐して、技術力や労働力を提供する契約形態（主に準委任契約）で行っています。
また、このSESで行われる開発のメンバーは、SIerからの一次請けの会社の社員ではなく、二次請け、三次請け、酷いところでは四次請け、五次請けがやっているという多重下請け構造が主流となっています。
これは、建設業の元請（大手ゼネコン）から下請（1次、2次、3次…）へ業務が再委託されるピラミッド型構造の多重下請構造と同じです。
人材を提供するSESの会社は、建設業の下請と同じく、プロジェクトに人を出すだけで売上が立つため、システム開発の技術力を勝負するというよりも、どちらかというと「求められる人間をどれだけ集められるか」が売りとなっています。
SESの会社に勤める社員は、プロジェクトに入ってる間は、そのプロジェクトで必要なスキルしか求められないため、新たなスキルを習得することは難しいものがあります。
また、プロジェクトでもらえる売上単価はスキルで決まっており、一次請けから下にいくに従って中抜きがどんどん行われるため、下の方の会社では単価も安くなって、社員の給与も上がらない、評価も自社上司からの評価というよりも、上流企業から必要とされるかどうかだけ、という不透明なものとなっています。
こういった、人を育てようとしない、人月を稼げなければ躊躇なく人を切ってしまう、というようなSESの会社を見ていると、IT業界の多重下請け構造は問題だと考えています。
「要求定義」は誰がやるのか
さらに、SIerの中には、顧客企業の曖昧な要望を受け取り、それを単に開発会社向けの言葉に置き換えるだけの「翻訳業」に近いだけの仕事をする、また顧客企業がプロジェクトで解決したい課題とゴールを定義する「要求定義」をきちんとやらず、顧客企業の要求を丸呑みした「要件定義」をして下請けに丸投げする、というSIerも数多くいます。
これに対し、顧客企業の担当者も、SIerに依頼することで、プロジェクトに失敗しても「大手SIerに依頼して失敗した」という責任論から逃れられるから、あるいはプロジェクトの規模が膨らんでも、財務体質的に安心感がある、という理由で大手SIerに依頼をする話も聞きます。
このような問題を見ていると、「SIerは不要」というのも宜なるかなとは思います。
しかし、プロジェクトの成果を厳密に求められる現在において、こういったスタンスでは顧客企業の経営陣が望む成果を得る事は到底難しいものがあります。
企業の事業戦略と現場業務を理解し、「何をつくるか」の前に「なぜそれをやるのか」「その投資で何を実現したいのか」を言語化し、利害関係者の合意を形成しながら、実装可能な計画へ落とし込む「要求定義」は、むしろ今まで以上に重要になっています。
そのため、この「要求定義」ができるSIerか、できないSIerか、という点で見るのではなく、一括りに「SIerは不要」と言ってしまうのは問題ですし、SIerの多重下請け構造や、発注側企業の丸投げ体質については、日本のIT業界の問題という面が大きいです。
「AIでSIerは不要」が広がるのはある意味自然です
ただ、この議論が広がる背景には、単なる感情論ではなく、現実の構造変化もあります。
生成AIやSaaSの多様化
まず、生成AIによって、要件のたたき台作成や画面設計、テスト観点の洗い出し、さらには一定レベルの実装まで、以前よりもはるかに速くできるようになりました。
また、SaaSやパッケージも成熟し、「ゼロから作る」必要がない領域が増えています。
ECで言えば、Shopifyのように短期間で立ち上げられるサービスは非常に魅力的ですし、目的が明確で、業務の複雑さがそこまで高くないケースでは合理的な選択肢です。
その結果、ユーザー企業から見れば、「昔ほど大人数のSIerが間に入る意味が見えない」という感覚が生まれやすく、それはある意味では健全な市場の反応です。
DXがうまくいっていない
さらに、日本のDX推進は量の面では広がっている一方で、成果創出の面では課題が残っています。
IPAの「DX動向2025」では、日本企業でDXの成果が「出ている」と答えた割合は6割弱にとどまり、米国・ドイツの8割以上と比べて低い水準であり、しかも日本は、全体最適よりも個別業務の最適化に偏る傾向があると指摘されています。
DX の取組成果を従業員規模別・国別でみると、日本は「1,001 人以上」の企業が「成果が出ている」と回答する企業の割合が最も高く 64.2%であるが、米国の 84.0％、ドイツの92.0％との差は大きい（図表 1-8）。
「DX動向2025」日米独比較で探る成果創出の方向性「内向き・部分最適」から「外向き・全体最適」へ
このデータは示唆的ですが、日本企業はDXに取り組んでいないのではなく、様々な取り組みを行なっていますが、成果につながる形でシステム導入ができていない、という点に問題があります。
つまり、現場ではこうなっているのです。
- システム導入を行なった。
- ツールも導入した。
- でも、事業成果につながらない。
この状態が続けば、「間に入っていた人たちは何をしていたのか」という疑問が出るのは当然であり、「SIerは不要」というのが広がるのは、単なる誤解ではなく、業界側が生み出してきた面もあるでしょう。
どんなに要件を細かく詰めても、仕様の抜けはゼロにならない
たしかに、生成AIの進化によって、従来は人手に頼っていた作業の一部が大きく効率化されているのは事実です。
ただ、ここからすぐに「だからSIerは不要になる」と結論づけるのは、かなり危険な話だと私は考えています。
AIは曖昧な指示や間違った指示でも作ってしまう
なぜなら、AIは単機能で比較的シンプルなシステムであれば、かなりそれらしく動くものを短時間で作れる一方で、複雑な業務要件を持つ実運用レベルのシステムになると、一気に話が変わるからです。
- 見た目には整っている。
- 画面もある。
- コードも書かれている。
- 一見すると動いているように見える。
しかし、実際に業務で使おうとすると、そこで初めて多くの問題が見えてきます。
- 想定していた例外処理が入っていない
- 権限制御の粒度が甘い
- 業務フローの分岐条件に抜けがある
- データ整合性の担保が不十分
- 他システム連携時のエラー処理が弱い
- セキュリティ上の考慮が浅い
- 運用開始後の保守性や拡張性が低い
システムの仕様は、人が問いを立て、確認し、矛盾を見つけ、必要に応じて意思決定を促すことで固まっていきます。
つまり、AIは自然言語で指示ができるので、曖昧な仕様からも「それっぽいもの」を作る力は非常に高いのですが、そのまま本番運用に耐えるものを自動的に完成させるわけではないのです。
ITに詳しくない人は仕様漏れがあること自体に気がつきにくい
AIに指示をして、そのまま出来上がったものがなぜ本番運用に使えないのか。
これは、システム開発において難しいのが、単に文章量を増やすことではなく、現実の業務に潜んでいる前提条件や例外条件をどこまで拾い切って仕様に落とし込める事だからです。
さらに注意すべきなのは、ITに詳しくない人ほど、仕様漏れがあること自体に気づきにくいという点です。
しかし実際には、そのできたように見えるものの中に、業務上致命的な抜けや、セキュリティ上の問題、例外処理の不備、権限制御の甘さが潜んでいることがあります。
しかも、ITに詳しくない利用者や発注者は、その危険を危険として認識できないまま導入してしまう可能性があります。
これは非常に恐ろしいことです。
なぜなら、本当に危険なのは「明らかに壊れているシステム」ではなく、一見すると動いてしまうが、実運用の中で重大な問題を引き起こすシステムだからです。
だからこそ、AIで設計・開発を進めるうえで本当に重要なのは、単にプロンプトを書けることではないのです。
ここを見誤ると、プロトタイプと実務システムの違いを過小評価してしまいます。
曖昧な要求を詳細な仕様に言語化して開発ができるか
つまり、AIを活用してシステム開発をする時代になってより必要となるのは、要求定義から要件定義、基本設計、詳細設計、開発、テストという流れ全体を理解した上で、曖昧な要求を仕様に言語化して開発ができることです。
- この要求は何を実現したいのか
- この要件で業務は成立するのか
- 設計として矛盾はないか
- 例外処理は十分か
- セキュリティ上の穴はないか
- テストで何を確認すべきか
といった論点を最後まで追いきり、結果として問題のないシステムを構築する能力です。
システム開発の実装自体は、これからますますAIに任せられる部分が増えるでしょう。
AIを使うことで開発スピードも上がりますし、初期たたき台の品質も向上するため、それ自体は良いことです。
ただし、実装をAIにある程度任せることと、システム全体の品質責任を手放すことは、まったく別の話です。
AIは、自然言語で指示ができるため、曖昧な指示や間違った指示でもそのまま実装をしてしまいます。
しかし、実際に使えるシステムにするためには、この曖昧な部分を明確にし、正しい仕様に落とし込む事ができる能力こそが重要です。
つまり、AI時代に価値が高まるのは、AIに指示をして実装ができる人ではありません。
工程の流れを理解し、抜けや矛盾を見つけ、要求を現実に耐える仕様に落とし込み、システムを仕上げられる人材、あるいはそうした体制を持つ企業です。
この意味で、要求定義から関われるSIer、そして要求定義を要件定義へ落とし込み、設計・開発・テストを通じて本番運用に耐える状態まで仕上げられるSIerは、AI時代でも不要になるどころか、むしろその価値がより明確になると私は考えています。
最終的なテストは、AI時代だからこそ必須になる
ここまで述べてきたように、AIは設計や実装の初速を大きく上げる力を持っています。
しかし、それは「品質確認の必要性が下がる」という意味ではなく、むしろ逆です。
AIが生成する成果物は、壊れていてすぐにわかるものよりも、一見すると成立しているように見えるもののほうが多い。
だからこそ、その中に潜む不整合や危険を、人が意識的に見つけにいかなければなりません。
実際のプロジェクトで本当に重要なのは、単体で「それっぽく動く」ことではなく、業務全体の流れの中で破綻しないことです。
たとえば、次のような点は、AIが作った成果物をそのまま受け入れているだけでは見落とされやすい部分です。
- 正常系だけでなく異常系・例外系でも成立するか
- 他システム連携時に不整合や再送問題が起きないか
- 権限制御や監査ログは十分か
- データ更新の整合性は担保されているか
- 将来の運用変更や機能追加に耐えられる設計か
- 実際の現場担当者が迷わず使える導線になっているか
このような確認は、単なるコードレビューだけでは不十分です。
結合テスト、業務シナリオテスト、受入テスト、セキュリティ観点でのチェックまで含めて、ようやく本番運用に耐えるかどうかが見えてきます。
つまり、AI時代にテストは不要になるどころか、AIを活用するほど、テストの意味と重要性はさらに増すのです。
AI時代に本当に必要なSIerとは何か
では、これからの時代に必要とされるSIerとは、どのような存在でしょうか。
私は、これから必要とされるのは、単に開発会社と顧客企業の間に入る調整役ではなく、要求を成果に変えるための伴走者だと考えています。
具体的には、次のような役割を担えることが重要です。
要求定義から入れること
プロジェクトの成否は、要件定義の精度だけでは決まりません。
その前段階である「要求定義」が曖昧であれば、どれほど整った要件定義書を作っても、そもそも違う方向に進んでしまいます。
- なぜこの投資をするのか
- 何を変えたいのか
- 何を成果として評価するのか
- どこが競争優位になるのか
- 何をシステムで解決し、何を運用で解決するのか
こうした問いを整理しないまま開発を始めると、プロジェクトは高い確率で迷走します。
要求定義から関われるSIerは、単に機能一覧を作るのではなく、事業として何を実現したいのかを言語化するところから支援できます。
これができるかどうかで、その後のすべてが変わってきます。
要求を要件へ落とし込めること
また、要求定義ができるだけでも十分ではありません。
それを実装可能なレベルまで要件へ落とし込めなければ、プロジェクトは前に進みません。
たとえば「業務を効率化したい」「売上を伸ばしたい」「顧客体験を改善したい」といった要求は、そのままでは開発できません。
- どの業務フローを変えるのか
- どのデータをどう扱うのか
- 誰がどの権限で何を操作するのか
- どの指標で改善効果を見るのか
といった形に落とし込んでいく必要があります。
この作業は、現場理解、技術理解、業務設計、関係者調整のすべてが求められます。
ここを雑にやると、AIでどれだけ開発スピードが上がっても、最後に使えないものが残るだけです。
実装を仕上げるところまで責任を持てること
AI時代に価値が残るのは、コードを書く人ではありません。
むしろ、AIによってコードが以前より速く書ける時代だからこそ、最後に責任を持って仕上げられる人の価値が高まります。
- 設計の矛盾を見つける
- 仕様漏れを補う
- 例外条件を洗い出す
- テスト観点を立てる
- 現場で使える品質まで持っていく
これらを担えるSIerは、AI時代でも明確に必要です。
逆に言えば、ここに責任を持たないSIerは、今後ますます存在意義を問われることになるでしょう。
不要になるのは「SIer」ではなく「責任を持たない中抜き業」です
私は、「SIerは不要」という議論が広がる背景には、やはり業界自身の問題もあると思っています。
実際、これまでのSIerの中には、
- 顧客の要望をそのまま受けるだけ
- 自分では要求を深掘りしない
- 要件定義を形式的にまとめるだけ
- 実際の設計や開発は下請けに丸投げ
- 品質や成果には責任を持たない
というスタンスの企業も少なくありませんでした。
こうしたプレイヤーに対して「それなら不要ではないか」と言われるのは、ある意味で自然なことです。
しかし、それは「SIerという役割自体が不要」という話ではありません。
不要になるのは、責任を持たず、価値を編集せず、ただ情報を受け渡すだけの中抜き業です。
- 要求定義から入り
- 要件へ落とし込み
- 設計・実装・テストまで全体を見通し
- 最終的に現場で使える形まで仕上げる
こうした役割を果たせるSIerは、今後も必要ですし、むしろ以前より重要になるはずです。
発注側企業もまた、変わらなければならない
この話は、SIer側だけの問題ではなく、発注側企業にも変化が求められます。
プロジェクト成果が厳しく問われる今、重要なのはどの会社に頼むかという看板ではなく、その会社が要求定義から伴走できるか、実装を最後まで仕上げられるかです。
発注側として本来問うべきなのは、たとえば次のような点です。
- こちらの事業や業務を理解しようとしているか
- こちらの言葉をそのまま要件化するのではなく、問い返してくれるか
- 「なぜそれが必要なのか」を一緒に整理してくれるか
- パッケージ導入ありきではなく、最適な打ち手を考えているか
- テストや運用まで含めて現実的な提案ができるか
つまり、発注側も「丸投げする相手」を探すのではなく、一緒に成果を作るパートナーを見極める必要があります。
AI時代は、開発会社の“正体”が問われる時代です
AIの進化によって、これから多くの開発工程は効率化されていくでしょう。
これは避けられない流れですし、むしろ歓迎すべきことです。
しかし、その結果として起きるのは、「開発会社が不要になること」ではありません。
起きるのは、開発会社が何の価値を提供しているのかが、これまで以上にはっきり見えるようになることです。
単にコードを書くことだけが価値だった会社は厳しくなります。
また、単に顧客と下請けの間に入るだけの会社も厳しくなります。
一方で、要求を整理し、要件へ落とし込み、設計・開発・テストを通じて、問題のないシステムへ仕上げられる会社は、引き続き必要とされるでしょう。
私は、AI時代に問われるのは技術力だけではなく、要求を成果へ変える力です。
- 顧客の言葉をそのまま受けるのではなく、本質を問う力
- 抽象的な要求を、実行可能な要件に変える力
- 仕様漏れや矛盾を見抜く力
- AIを道具として使いながら、品質責任を最後まで担う力
この総合力を持つ企業こそが、これから選ばれていくはずです。
「AIかSIerか」ではなく、「誰が最後まで責任を持つか」
結局のところ、この議論の本質は「AIかSIerか」という二項対立にはありません。
- AIは強力な道具です。
- 設計のたたき台も作れる。
- コードも生成できる。
- テストケースの案も出せる。
だからこそ、開発のやり方そのものは確実に変わっていきます。
しかし、それでもなお変わらないものがあります。
それは、要求を明確にし、要件へ落とし込み、設計し、実装し、テストし、問題のない状態で現場へ届ける責任です。
この責任は、AIが自動的に引き受けてくれるわけではありません。
誰かが最後まで持たなければなりません。
だから私は、「AIでSIerは不要になる」という言い方には賛成しません。
不要になるのは、責任を持たないSIerであり、価値を出せないSIerです。
一方で、要求定義から入り、要求定義を要件定義へ落とし込み、設計・開発・テストを通じて、本番運用に耐える状態まで仕上げられるSIerは、これからも必要です。
むしろ、AIが普及するほど、その価値はより鮮明になります。
これから本当に求められるのは、「AIを使える人」ではなく、AIを使いながら、最後まで責任を持ってシステムを完成させられる人、企業、体制です。
そして、それができるSIerこそが、AI時代においても確かな存在意義を持ち続けるのだと私は考えています。
ITを使った経営課題の解決でお困りではありませんか？
DXを始めとするITを使った経営課題の解決が上手くいっていない企業は数多くあります。
それは、単なるソリューションの導入や、社内人材への丸投げとなっており、課題解決がゴールになっていないからです。
そのためには、経営とITを理解した人材が、経営者層と共に取り組み、経営者の頭の中を可視化することが必須要件です。
現在、1時間の無料オンライン・コンサルティングを実施しております。
是非この機会にご相談ください。
構築予算が10分の1に
経営課題を解決するECサイト、越境ECサイト、BtoB ECサイト、マーケットプレイスを構築するならCS-Cartをご検討ください。
スポンサードサーチ