学校も夏休みに突入する7月も後半、めちゃくちゃ暑い！暑すぎる！ そんな暑さに乗っかり、明日のイベントは更にアツくなることズバリ間違いないでしょう！
どうも笹です。
明日7/24、「AI時代の受託開発のミライ -『受託開発 is dead』のその先へ」というイベントで、及部さん、森實さんとタイトルに関連するお話をしようと思っています。それに先駆け、及部さんが先日「『受託開発 is dead』は真実か」という記事を書いてくれました。結論は「真実です。ただし死ぬのは受託開発ではなく、"つくるだけ"のソフトウェア開発です」。いやぁわかるぅ〜！
イベント前に私の意見も整理しておこうかと思い、私も受託の中の人として考えていることや予想を書きます。及部さん記事と被るところもありますし、ちょっと違う観点も入っているかなと思います。 先に断っておくと、これは一般的な予測記事ではなく、私個人の意見です。世の中のデータや歴史から見たときに「そうかな？」となるところもあるかもしれません。この記事はAIと議論しながら書いたのですが、AIが「それは一般論と違いますよ」と反論してきた箇所は、隠さずそのまま「🤖反論メモ」として載せておきます。どちらの意見も楽しんでもらえればと！
① 個人と組織に対するAIの浸透速度
「AI時代の」という枕詞があるので、まずは今どこまでAIが浸透しているのか、その現在地から。
AIの浸透は、これまでのアジャイル、ノーコード、クラウドと比べても、速度も範囲も比較にならないと感じています。アジャイルは組織を変えないと浸透しませんでした。クラウドもノーコードも、結局は使いこなせる専門家や環境整備が必要でした。それに対してAIは自然言語で使えるので、個人には摩擦ゼロで入ります。うちの息子や娘も日常で普通に使っています。皆さんの中にも、資料作成やちょっとしたツールづくりに使ったことのある人も多いのではないでしょうか？
ただ、「個人がみんな使っている」と「組織として有効活用できている」は、ぜんぜん別の話です。組織全体でAIをベースに経営ができている所は、まだ少ない印象です。個人レベルでは「効率が数倍になった」という話を聞きつつ、それが組織レベルのアウトカムやビジネスインパクトに繋がっているかというと、疑問が残ります。
🤖 反論メモ：「個人レベルで数倍」という体感すら怪しい、という研究があります。2025年の実験で、経験豊富な開発者がAIを使うと「20%速くなった」と感じながら、実測では19%遅くなっていた、という結果が出ました。体感と実測のズレ、そして個人と組織のズレ。二重のズレがある、というのがAI相棒の指摘です。（出典：METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」）
② 「受託開発 is dead」に対する回答
で、本題です。私の答えはYes！ただし今のままなら、です。この手の議論は「いつの話をしているか」がズレると噛み合わないので、時間軸を分けて話します。
現状： 社内を見てもスタートアップを見ても、PoCやプロトタイプ、簡易な社内システムは自社で、しかも一人で作っていることが増えてきています。「ある程度小さく、作るものが明確なモノ」のニーズはかなり減っている印象です。ここは個人でのAI活用が進んでいることが効いているのかなと。一方で、エンプラ品質の大規模な開発はまだ影響が少ない印象です。大企業向けだと、AIをベースにした開発を行いつつ内製化の支援もする、受託開発＆内製化支援みたいな仕事は逆に増えている感触があります。チーム・組織レベルでのAI活用はまだまだこれからで、少しずつ進めているのが現状かなと思います。受託開発全体の規模はあまり変わらず、という感じですかね？
2〜3年後： AIモデルの進化に加えて、ハーネスエンジニアリングやループエンジニアリングといったアプローチのアップデート、AIを組み込んだ品質保証の確立などが進み、エンプラ品質の大きなシステムでもAIを使った開発が増えていると思います。ただし、業界や製品の特性によってまちまちかなと予想しています。規制や監査が絡む現場では調達や契約が追いつかず、本格化している現場と、まだ超局所的な活用に限定される現場の差が開いていそうです。トータルとして見ると、定義された品質を守りながら、定義されたものを作るような開発の規模はかなり減っているはず。ただし、事業会社の中の人とAIだけでは全てが解決できるとも思っていません。課題発見・課題定義・課題解決といった難易度の高いことができるエンジニアの需要は高まり、コードをしっかり書けるだけのエンジニアの需要は下がる。エンジニアの二極化が起きる気がしています。この辺りは及部さんが言ってる「ただし死ぬのは受託開発ではなく、"つくるだけ"のソフトウェア開発です」と同じかなと思います。現状のよくある受託開発の案件数はかなり減ってるものの、ビジネス規模としては微減くらいの感じですかね？ ちょっと視点が変わりますが、組織運営の中核でAIが活用できていない受託開発企業も厳しい状況かなと思います。AI活用のレベル感がクライアントよりも高いのは大前提になると思います。なんとなく、kyonさんのRALGOあたりのイメージです。
10年後： もはや未知数ですが、今まで通りの時間単価で受託開発をしているビジネスは、ほぼなくなっているかもしれないですね。COSTAのようなビジネスが主流になっていたりして？
🤖 反論メモ：ここはAI相棒からはっきり反論されました。AI相棒いわく——ITサービス市場は世界でも国内でも成長中。日本は数十万人規模のIT人材不足がバッファになるので、2〜3年で市場の金額が減ることはまず考えにくい。減るのは金額ではなく仕事の中身で、数字が好調なまま、中身だけが入れ替わっていく。そしてこの時差こそタチが悪い。数字が良いうちは、変わる理由がないように見えてしまうから——とのこと。（IT人材不足の出典：経済産業省「デジタル人材の育成」・IT人材需給に関する調査）
あと、工数だけでなく責任の話もあるかなと思います。「何かあったら受託先に責任を取ってもらう」ためにお金を払う、という側面です。数年後は、外部にお金を払って責任を取ってもらうよりも、自分たちで素早く直す方向に舵を切り出すビジネスが増えてくるのかなぁとも思っています。
🤖 反論メモ：責任には二層ある、というのがAI相棒の反論です。バグを直す「技術的責任」は自社で持てるようになる。でも監査対応・賠償・対外説明といった「制度的責任」は直す能力の問題ではないので、金融や医療のような規制領域では外部に残り続ける、と。
③ 現状の道具を利用して、個人・組織で成果を出せるエンジニアか？
ではエンジニアはどうするか。キーワードは「道具」だと思っています。
AIに限らず、エンジニアリングに有効な道具はこれまでもたくさん開発されてきました。今ニーズがあるのは、個人やチームレベルでAIという道具をより上手く使うこと —トークンの使い方、ループの回し方、品質の確保— による開発・運用フェーズの課題解決や、それを人に教えられるレベルであることだと思います。
そしてもう少しすると、「作ったプロダクトが売れない」「組織のビジネスに効いていない」みたいな話が増えてくると思います。①で書いた、個人の効率化が組織の成果に繋がっていない問題が色んなところで表面化するタイミングです。AIはコストが数字で見やすいぶん、コスパやROIの議論がしやすく、アジャイルの時よりもストレートに話題になると思います。そうなると、これまで通りのディスカバリーや業務改善に関する課題解決、組織全体のデータ基盤やマインドセットの変革に関する課題解決ができる人にニーズが来る。
ここで大事なのは、新しいAIツールの話だけではないということです。ユーザーインタビューも、バリューストリームマッピングも、アジャイルもDevOpsも、これまでの道具はぜんぜん有効です。これまでのやり方に固執せず、新しい道具を学び続けつつ、これまでの道具もこだわりなく自在に使いこなせるようになっていけると良さそうです。達成したいことのために道具を選ぶ、ですね。この辺りはスクフェス福岡で話した内容ですね。ちなみに、道具にこだわって学び続ける、一時的な手段の目的化も私は好きです。
🤖 コメントメモ：「答え合わせが遅くて、責任が重い仕事ほど人間に残る」というのがAI相棒の見立てです。コードは秒で答え合わせできるから最初にAIに取られた。課題設定や意思決定の答え合わせには数ヶ月かかるから残る、と。
④ 受託企業にいながらクライアント以上に価値のある仕事ができるか？
クライアントの方がドメイン知識があるのに、受託で良い仕事できなくない？について。
こちらのテーマについては、これまでの経験と、今やっている株式対価での開発の経験から見えてきていることがあります。 まず、クライアントのドメインにもよりますが、専門性が非常に高い場合はクライアント以上の知識を持つのは難しいです。例えば自動運転ソフトを生業にしている所にソフトウェア開発の受託で入るのは、無理とは言いませんが相当大変です。整理された要件に従って開発する所に落ち着いてしまうことが多いかもしれません。 ただ、環境テックなど、ハードウェアに強みのある企業・スタートアップであれば全然ありえます。クライアントが既に価値のあるハードを作り上げた後に、その価値をスケールさせるためのソフトウェアが必要になるケースはかなり多く、そこにはニーズがあるし、活躍のタイミングがあります。 ただ、専門家レベルの知識は不要とはいえ、専門家に近しいドメイン知識を獲得していく必要はあります。「オレはソフトウェア屋さんだから」のスタンスで活躍するのは難しいですが、ビジネスをスケールさせるエンジニアだというスタンスで臨めるのであれば、クライアントにいるメンバーとは一味違った価値のある仕事はできると感じています。
🤖 反論メモ：この知識の掛け算競争は双方向だ、というのがAI相棒の指摘です。エンジニアがAIでドメイン知識を学べるようになったのと同じように、クライアント側のドメイン専門家もAIでソフトウェアを作れるようになっていく。つまり「エンジニアがドメインを学ぶ速度」と「ドメイン専門家がソフトウェアを扱えるようになる速度」の競争になる。エンジニア側が勝ち続けられるのは、品質・スケール・運用のような、経験でしか身につかない領域を持っている間だ、と。
⑤ 新世代エンジニアへの期待
ちょっと話はズレますがもうひとつ。
受託開発の大手企業などでも新卒エンジニアの採用を控え目にしている所が多くなっているように感じます。ちなみにクリエーションラインでは、新卒採用を増やしています。この判断が正しいかは正直分からないところもあります。ただ個人的な意見として、私は新卒エンジニアと一緒に仕事がしたいと思っています。
新卒メンバーとはもうかなり年齢差もあるので、感覚も常識も違って、色んな意味で驚きがあります。新卒メンバーは「オレが若い頃はなぁ…」がないので、フラットに今を捉えて動けるのがスゴイなぁと思っています。③で書いた道具の観点で言えば、新しい道具をこれまで以上に上手く使えるのは、間違いなく彼らです。
ただ、「オレが若い頃はなぁ…」が救ってくれることも多々あるのも感じています。これまでの道具を上手く使えるのは、ベテランエンジニアの良さです。
ということで、ベテランエンジニアと若手エンジニアのペアで仕事を行うのが良いかなぁと思っています。お互いの成長観点でも。少なくとも私はそうしたい。条件があるとすれば、お互いが学び合うペアであること。これまでのプライドで若手を下に見てしまったり、若手の現時点のアウトプットをAIと比較してしまったりすると、上手くいかないと思います。
🤖 反論メモ（今回は補足です）：米国では、AIの影響を受けやすい職種の若手雇用が減少として数字に出始めています。そしてAI相棒いわく、エンジニアの「勘」はコードを書いた量ではなく「結果に責任を持った経験の量」から育つ。だとすると若手に必要なのは、書く機会より「責任を持たされる機会」——ペアで働くなら、小さくても本物の責任を少しずつ渡すことがセットかも、と。（若手雇用の出典：Stanford Digital Economy Lab「Canaries in the Coal Mine?」）
エンジニアは楽しい仕事だと思っています。だからこそ、楽しく継続できる仕組みを作っていきたいですね！……もはや受託かどうかは関係ない話ですが。
⑥ 現実世界へ出よう
最後に、私がいま一番意識していることを。
相対的に「PCに向かってやれること」は、AIで代替できることが多いなぁと思っています。だとすると、PCに向かわずにやる必要のある、割と泥臭いことの価値が高まっている気がします。現場に足を運んだり、顔を合わせて信頼関係を築いたり。PCの中はAIがいい感じにしてくれるので、外側の現実世界に立つことが自身の価値を高めることに繋がると思っています。
現実世界へ出ていきましょう！
……こうして今日もPCに向かって記事を書いている私なのでした。
おわりに
明日7/24（金）19時から、このへんの話を及部さん、森實さんとワイワイ好きなことを話そうと思っています。無料・オンラインなので、ぜひ気軽に遊びに来てくださーい！一緒にわいわい考えましょー！
（感想・反論、大歓迎です。AI相棒への反論も受け付けます！）
