最近、タイムラインで「受託開発 is dead」という言葉をよく見ます。AIでソフトウェアがどんどん速く・安く作れるようになって、これまでの「顧客の要望どおりに作って納品する」という受託開発のかたちが、急速に価値を失いつつある。だいたい、そういう文脈で語られています。
最初は正直、「また◯◯ is dead系の煽りか」と思っていました。
というのも、「受託開発 is dead」という話は、AI以前から何十年も言われ続けてきたからです。内製化、クラウド、多重下請け、オフショア。そのたびに「今度こそ死ぬ」と言われて、それでも受託開発はゾンビのように生き残っています。
実は自分も、ずっと事業会社に所属していた人間なので、こうした話題を半分外野から眺めていました。受託開発って大変そうだな、なんとなく近づきたくないな、と思っていたことを覚えています。
そんな自分が、3年前に株式会社ホロラボに参画して、いまは受託開発をはじめとするクライアントワークのど真ん中にいます。正直、参画するとき「受託開発」という言葉には少しひっかかりました。それでも、新しい技術がもたらす変革への挑戦と、会社そのものの魅力が勝ちました。そもそも「受託開発」だって、やってみてから文句言わないとださいよなーと。
あれから3年。経営チームにも参画し、受託開発と本気で向き合ってきました。だからこそ今回は、「受託開発 is dead」という言葉からも逃げずに、本気で向き合ってみます。
「受託開発 is dead」は真実か
真実です。
AI以前から、DXの文脈でのノーコードの取り組みや、内製化の流れはずっとありました。そこにAI（特にAIエージェント）の波が来て、この傾向は一気に強くなりました。非エンジニアでも、ソフトウェアを作れるようになりました。
この手の話をすると、それを生業にしているエンジニアを中心に「品質ガー」「セキュリティガー」と騒ぎになって、「ソフトウェア開発はそんなに簡単ではない」という議論になりがちです。
でも、ソフトウェアに求められる品質は、目的や用途によってさまざまです。顧客向けや実運用に絡むソフトウェアには、それなりのサービスレベルが求められます。一方で、社内で使うツールやPoC（コンセプト検証）に求められるレベルは、相対的に低いことが多いです。そしてこの領域こそ、AIエージェントに代替されやすい、というよりもう代替が始まっているところです。
セキュリティや品質の面も、モデルの進化と、人間側のAI活用の知見が溜まっていくことで、年々差分は埋まってきているように感じます。ほんの2〜3年前まで「AIに支援はさせても、コードを書かせるのはまだ早い」が主流の論調だったのに、今ではAIがコードを書いていることのほうが多いです。この変化のスピードを見ると、現時点では完全に任せることが難しい領域でも、近い将来「人間よりもAIのほうが信頼できる」という状況は、普通に起こりえます。
正直に言うと、自分もエンジニアなので、自分がやってきた仕事が簡単に置き換わるなんて、信じたくない気持ちはあります。でも、死につつあるものは、自分の現場からもハッキリ見えています。煽りでもポジショントークでもなく、これは本当に起きている変化です。
ただし、「受託開発がまるごと死ぬ」という意味ではありません。死ぬのは受託開発ではなく、"つくるだけ" のソフトウェア開発です。なぜそう考えるのか、順番に書いていきます。
① 「受託開発」でひとくくりにできない
受託開発と一言でいっても、人月だけを売る会社、SIer、コンサル、プロダクト伴走、PMO、DX支援まで、中身は全部違います。だから問うべきは「受託開発 is deadか」ではなく、「何が dead なのか」です。
そこを分けて考えると、AIによる価値の低下は、いきなり全部が消えるというより、段階的に進んでいきます。そして、その波が最初に効いてくるのが「コードを書く」という行為の価値です。実際に、開発の生産性が上がって案件の利益構造が変わり始めています。
そしてこの波は、コードを書くところだけでは止まりません。設計、要件定義、その手前の構想へと、少しずつ広がっていきます。だからこそ、どこの価値が先に下がって、どこが残るのかを分けて見ておきたいのです。
だから死ぬのは、"言われた通りにコードを書くだけ" の仕事です。受託開発かどうかは、関係ありません。そしてこの領域は、もう縮み始めています。
ただし、縮み方は一枚岩ではありません。中小の受託開発や小さな自社開発は、内製化と生成AIの波をもろに受けて、案件が消え始めています。一方で、大手エンタープライズの複雑なシステムは、内製だけでは賄いきれないので、今のところそんなに困っていない、という話もよく聞きます。効き方は規模と顧客層でぜんぜん違うので、ここを混ぜると話がぼやけてしまいます。
② そもそも、顧客は「コード」を買っていない
顧客は、コードを書いてほしくて受託しているんだっけ？と考えると、違うんですよね。
顧客が期待しているのは、事業戦略を整理したい、要件を一緒に考えてほしい、意思決定を助けてほしい、社内調整を手伝ってほしい、リスクを減らしたい、といった問題解決です。コードは、そのための一つの手段にすぎません。
このように考えてみると、「コードが安くなった＝受託開発が死ぬ」は、かなり短絡した話になります。安くなったのは手段であって、期待されている中身のほうは何も消えていないからです。
これは、事業会社と受託開発の両方を経験した自分の実感とも重なります。事業に踏み込んでいく受託開発の現場もあれば、事業部に言われたものをつくっているだけの、社内請負のような開発チームもある。「事業会社か受託開発か」という線を引いても、実態はもう捉えられません。
しかもこれは受託開発だけの話ではありません。開発とコンサルの境界も溶けています。コンサル会社はどんどん開発部隊を持ちますし、SIerは事業支援を始めています。「SaaS is dead」も同じ構造で、ソフトを売るだけの会社は終わり、BPOや運用や伴走、成果保証まで踏み込む会社は伸びています。コンサルも、SIerも、SaaSも、事業会社も、やっていることがどんどん重なってきています。行き着く先は、顧客にとっての「価値」です。
③ 「考える」と「つくる」が近づいている
ソフトウェアをつくるコストは、長いあいだ、あまりに高いものでした。だからどうしても「考える」と「つくる」は分業になっていました。役割が分かれ、職種が分かれ、組織が分かれ、会社まで分かれがちでした。
AIによって、「つくる」のコストが下がりました。その結果、「考える」と「つくる」が自然と近づき始めています。役割が近づき、職種が近づき、組織が近づき、会社も近づいてきた。いま起きているのは、この変化です。
そして、アジャイル開発が実現したかったことが、まさにこの「考える」と「つくる」を近づけることでした。当時はつくるコストが高くて実現しきれなかった理想に、今ようやく近づき始めています。
実際、自分たちのクライアントワークでも、開発だけでは終わらないケースが増えています。最初は普通の開発だったのに、途中から「事業の進め方も相談したい」となって、PMO、ビジネスモデル設計、プロジェクト推進、意思決定支援まで広がっていく。今では「システムを作る」より「事業を作る」ことのほうが多い現場もあります。これは受託開発なのか？と最初は思っていましたが、もはや境界は気にしなくなりました。
最近FDE（Forward Deployment Engineer）という言葉をよく聞くのも、たぶん同じ流れです。顧客の現場に入り、課題を一緒に考え、必要ならコードも書く。「考える人」と「つくる人」ではなく、"考えながらつくる人"。ここで勘違いされやすいのですが、本質は常駐でも、顧客への物理的な近さでもありません。問題解決への近さです。
ただし、この変化は諸刃でもあります。最近、ある大企業でこんな話を聞きました。最初は事業戦略があった。システム開発が始まる。途中から、作ることだけが目的になる。戦略が消える。そして、使われないシステムが大量に残る。これはAI以前からずっとあった現実です。でもAIで作るコストが下がると、この悲劇はもっと簡単に、もっと大量に起きるようになります。作ることが簡単になればなるほど、「何を作るか」の重みは増していきます。
だから、問題解決に踏み込む受託開発にとって、AIは逆風ではなく追い風です。is deadどころの話ではありません。ただし、問題解決から離れた瞬間に、その追い風は「使われないもの量産マシン」に化けます。
④ 結局、価値の源泉は「人」
ここまで来ると、受託開発もコンサルもSaaSも、価値の源泉は同じだと思えてきます。ソフトウェアそのものではありません。人です。
どの会社でも解決できる仕事は、代替されます。AIでも解決できる仕事も、代替されます。でも、「この人たちじゃないと解決できない」は残ります。「この人たちと働きたい」も残ります。
だから目指すのは、成果物を納めることではなく、顧客が価値にたどりつくためのパートナーであることです。モノではなく、人に価値を感じてもらう。
その筆頭が、意思決定です。AIは候補をいくらでも出せます。でも、決めるのは人です。そして意思決定は、意思決定することでしか上手くなりません。
人の育て方も変わります。自分の部署でも「考える＋つくる」へシフトしていて、もちろん苦労もあります。でも、これは研修では身につきません。仕事の中でしか育ちません。
採用の話も少しだけしておきます。最近、AIを理由に若手採用を減らす会社が増えています。「AIがコードを書くなら、ジュニアはいらない」というロジックです。でも、自分は逆だと考えています。AIネイティブな若手のほうが、固定観念がないぶん、自分たちには思いつかない使い方を編み出す可能性があります。短期的に採用を控えることはあっても、人が増えて育っていく環境をつくれなければ、その産業は衰退していくだけです。それはAIのせいではなく、AIがもたらした変化に適応できていないだけです。
エンジニアという職種がなくなるのではありません。"つくるだけ" のエンジニアの仕事がなくなるのです。
すべてのソフトウェア開発が、「価値」に近づいている
「受託開発 is dead」は真実です。ただし、受託開発が死ぬのではなく、"つくるだけ" のソフトウェア開発が死ぬ。エンジニアという職種がなくなるのではなく、"つくるだけ" のエンジニアの仕事がなくなる。そしてそれは、もう始まっています。受託開発は、たまたまその矢面に立っているだけです。
ここまで並べてきた変化を一歩引いて眺めると、もっと大きな絵が見えてきます。事業に踏み込む受託開発。開発組織を持つコンサルティングファーム。成果保証まで踏み込むSaaS。顧客の現場に入るFDE。立場も形式もバラバラなのに、向かっている先はぜんぶ同じです。すべてのソフトウェア開発が、それぞれのかたちで「価値」に近づいているのです。
しかもこれは、新しい潮流ではありません。エンジニアはずっと昔から「つくるだけではだめだ」と知っていて、顧客に、ユーザーに、価値に近づこうとしてきました。その代表例がアジャイル開発です。アジャイル開発が誕生してから、25年。「考える」と「つくる」を近づけたかったあの理想が、AIによって、この数年で一気に加速している。自分にはそう見えています。
だからもう、ソフトウェア開発の「かたち」にこだわっている場合ではありません。受託開発か、事業会社か。SIerか、コンサルか。そこで消耗するのではなく、問うべきは「価値にどれだけ踏み込めるか」です。
7/24に「受託開発 is dead」をテーマに朝まで生討論します
7/24にCreationlineさん主催の「AI時代の受託開発のミライ ─「受託開発 is dead」のその先へ」というイベントに登壇します。
https://creationline.connpass.com/event/398146/
2026年7月24日（金）19:00〜20:30、Zoom開催・参加無料です。
@samuraiRed、@sasakendayo と3人で、「受託開発 is dead」をテーマに本音で徹底討論します。
話してはいけないことまで話しかねない3人なので、事前打ち合わせの際に運営の方に「いざとなったら止めてください」と伝えています。きっとリアルタイムでしか聞けない臨場感がそこにあります。
どんな話をするのかって？
答えは……トランキーロ！あっせんなよ！
当日、お待ちしております。
ブログはこちら
