「オフショアって、AIが来たら終わりじゃないの？」
先日、一緒に仕事をしている神戸在住のPM、Mさんと話していたときに、こんなことを聞かれたんですよね。
「オフショア開発って、AIが来たら終わりじゃないの？」
正直なところ、同じことを僕自身もずっと考えていました。ホーチミンでエンジニアチームを抱えているのに、「これ、自分でCursorを使えば半分の時間で作れるんじゃないか」と思う瞬間が、去年から明らかに増えてきたんです。
自分でつくったチームを、自分が毎日使っているツールが脅かしている。なんとも言えない感覚で、僕はしばらくこの問いから目をそらしていました。
でも今日は、ここから逃げずに考えてみようと思います。先に結論を言うと、「今まで通りのオフショアは終わりに近い。でも終わったのはオフショアそのものじゃなくて、僕たちが何年も言ってきた“ある売り文句”なんですよね」——これが、1年以上かけてたどり着いた答えです。
AIに食われやすい仕事を、並べてみる
まず、自分にとって都合の悪い話からします。AIに食われやすい仕事って、発注する側からすると、だいたいこのへんじゃないですか。
LPや簡単なWebアプリの初期実装。CRUD中心の管理画面。決まった仕様に沿った機能追加。ちょっとした技術検証のスクラッチ。
実は、2年前まではこれがオフショアに頼む一番の理由でした。「国内のエンジニアより単価が低くて、スピードも出る」というやつです。
ただ今って、この種の仕事はClaudeやCursor、v0を使えば、一晩で動くものができてしまう。しかも「AIにできるのはここまで」の線は、これまで何度も引き直されてきた。日本の中小企業の社長さんでも「自分でやってみようかな」と思い始めている。実際そういう声を、この半年で何度か聞きました。
だから「AIが来たら終わり」という感覚は、間違ってないと思います。ただ、それは「今まで通りのオフショア」の話なんですよね。ここを一緒くたにすると、判断を間違えちゃうなと。
競合は、インドじゃなくてAIになっていた
少し前まで、オフショア業界の競争ってシンプルでした。ベトナムかインドかフィリピンか。どこが安くて品質が高いか。その勝負だったんです。
でも気づいたら、本当の競合相手は他の国のオフショア会社じゃなくなっていた。発注する人の頭の中に浮かぶ「それ、AIでよくないですか？」という問い。これが最初のハードルになっているんです。比べられている相手が、もう他社じゃないんですよね。
これはけっこう、根っこから変わったなと思っていて。AIが競合になった瞬間、「安い人件費で開発します」という売り文句は、嘘になったんです。
「嘘」という強い言葉を選んだのは、自分への戒めでもあります。価格面の優位性を価値の一つとして伝えてきたのは、ほかでもない、うちも同じだったので。単価競争に勝っても、もう意味がない。AIより安い人間はいないし、AIより速くタイピングできる人間もいない。その土俵自体が、消えちゃったんですよね。
じゃあ、何で戦うのか。ここからが本題です。
去年から、確信に変わってきた3つのこと
ホーチミンのチームで毎日仕事をしていて、去年あたりから、だんだん確信に変わってきたことがあります。
まず変わったのは、「人そのもの」より「仕組み」の重さが一気に増したことです。
1つ目は、「人が武器の時代が終わる」という話です。
プロジェクトを救えるヒーローエンジニアがいる、というのは、一見すると強みに見えるじゃないですか。ただ、僕はずっとこれを危ういと思っていました。チームで話すとき、こういう言い方をすることがあります——「プロジェクトを誰か一人が救わなければならないとしたら、それはシステムがまだ弱いということだ」と。
誤解されたくないので書いておくと、これは「人はいらない」という話じゃないんです。むしろ逆で。一人のエンジニアに全部を背負わせる状態って、その人のためにもチームのためにもならないんですよね。人を大事にしたいからこそ、人に依存しない仕組みをつくる。僕の中では、これは矛盾しないんです。
そしてAIは、このヒーロー依存の構造を、すごい速さで解体している。個人の技術スキルの希少性が、どんどん下がっているからです。人が武器だった時代から、仕組みが武器の時代へ。この移り変わりが、AIによって10年分くらい一気に進んだ感覚があります。
次に変わったのは、優秀なエンジニアの定義そのものでした。
2つ目は、「エンジニアの“優秀さ”の意味が変わった」という話です。
これはうちのエンジニアにも何度か話していることなんですけど、昔は「仕様を理解して、早くコードを書ける人」が優秀でした。でも今は違うんですよね。コードはAIが書ける。じゃあ人間に残るのは何かというと、「仕様の裏側にある、本当の問題を理解する力」と、「AIが出した60点の答えを見抜いて、本番に出せる品質まで引き上げる判断力」だと思っているんです。
基礎力がないままAIを使うと、見た目は動くんだけど、設計はぐちゃぐちゃ、みたいなものが生まれます。しかもそれに気づかないまま本番に上げちゃう。こういう事故が現場で増えているのを、うちのチームも目撃しています。
ひとつ、実際にあった話をします。ある案件で、AIで初期実装したコードをレビューしたら、Reactのコンポーネントが1ファイルで1000行を超えていて、画面の表示と内部の状態管理が完全に混ざっていたんですよね。見た目は、ちゃんと動くんです。ところが、機能をひとつ足すたびに「これ、どこに書けばいいんだ？」という状態になっていた。結局、整理するのに最初の実装より時間がかかりました。つまり、短期的には速く見えても、後から直すコストが一気に膨らむ構造になっていたんです。AIは速く作ってくれる。でも「あとから変えやすい形」までは、勝手には選んでくれないんですよね。そこを選べるかどうかが、これからの“優秀さ”なんだと思います。
そして最後に、差がつくところが「速さ」から「再現性」に移りました。
3つ目は、「速さじゃなくて、再現性が次の競争軸になる」という話です。
AIを使えば、誰でもそこそこ速く動けます。だから「速い」は、もう差別化にならないんですよね。次のラインは「誰がやっても同じ品質が出る仕組みがあるか」だと思っていて。個人の努力やモチベーションで品質を保つやり方って、どうしてもスケールしないんです。一晩だけ速いチームより、毎回ちゃんと同じ品質を出せるチームのほうが、結局は強いなと。
で、結局、何が残るんだろう
この3つを前提に考えていくと、残る価値がだいぶはっきりしてきます。
AIは、初期のプロトタイプを作るだけの道具じゃなくなりました。テストを回すのも、直した結果を検証するのも、運用の一部も、任せ方さえ設計すれば相当なところまで走ってくれる。じゃあ何も残らないのか、というと、そうじゃないんです。「本番に出せる状態」の基準を誰が決めて、外したときに誰が責任を取るのか。ここはAIがどれだけ進化しても、人間の側に残り続ける。しかも「AIにはここまでしかできない」と書いた瞬間に、その線は次のモデルで動くんですよね。だから固定の答えじゃなくて、線を引き直し続ける体制のほうが残る領域だと、僕は思っています。
本音を言うと、これはまだ完成した答えじゃないんです。今のところ、現場で何度もぶつかって、そのたびに戻ってきた視点、という感じなんですけど——うちでは大きく分けて、こんなふうに開発に向き合うようにしています。
まず、AIが開発しやすい構造を、最初に設計しておくこと。AIにコードを書かせる前提で、どんなアーキテクチャを選ぶか、どんなドキュメントを整えておくか。AIってコンテキストさえあれば動くんです。逆に言うと、そのコンテキストを設計するのが、これからの人間の仕事になっていくんですよね。
それから、AIの役割をちゃんと分けること。何でもかんでも一つのAIにやらせようとすると、混線するんです。設計する役、つくる役、チェックする役。役割を分けてはじめて、品質が安定する。AIを「一人の万能選手」として扱わない、という感覚に近いです。
そして何より、人間が責任を持つ場所を、はっきり決めておくこと。「AIが作ったんだから大丈夫だろう」でいくと、本番で痛い目を見ます。どこまでをAIに任せて、どこから人間が判断するか。この線引きの設計が、いちばん大事になってくると思います。
まだうまく言語化しきれていないし、これからの部分も多いです。でも、この向き合い方に変えてから、AIが「敵」じゃなくて「チームの一員」に変わった感覚があるんです。
明日、5分でできる一歩目
「考え方はわかった。でも、何から始めればいいの」という方に、今日すぐできることをひとつだけ。
自分の開発プロセスを、2色で塗り分けてみてほしいんです。「AIに任せていい工程」と「人間が責任を持つ工程」。アーキテクチャの最終判断、セキュリティリスクの評価、本番リリースの可否。このあたりだけでも書き出してみると、「ここは自動化できるな」「ここは絶対に人間が見ないとダメだな」の境界線が、自分の現場の言葉で見えてくると思います。
この一枚、誰かに頼まなくても今日のうちに自分で書けるんですよね。そして、この一枚があるかないかで、AIとの付き合い方が驚くほど変わるんです。
Q1: AIが来たら、オフショア開発は本当に終わりですか？
「今まで通りのオフショア」は、終わりに近いと思います。単価競争で戦ってきた部分——LPの初期実装、CRUD中心の管理画面、決まった仕様の機能追加——は、AIにとって代わられていく。残るのは「AIにできない仕事」ではなく、どこまでAIに任せてどの判断を人間が握るかの線引きを設計し、結果に責任を持つ仕事です。この線はモデルの進化で動き続けるので、引き直し続けられる体制そのものが価値になると思っています。
Q2: AIに任せていい開発と、人間が担うべき開発はどう分けますか？
乱暴に言うと「スピード＞品質でいいもの」はAIに、「本番で動き続けるもの」は人間が最終判断する、という分け方が一番わかりやすいです。プロトタイプ・PoC・技術検証はAIが得意。一方、アーキテクチャの最終判断、セキュリティリスクの評価、本番リリースの可否——ここは人間が責任を持つ。「AIが作ったから大丈夫だろう」で本番に出すと、あとから痛い目を見ます。
Q3: AIを前提にした開発チームを作るには、何から始めればいいですか？
まず「AIに渡せるコンテキストを整える」ことから始めるのが一番早いです。仕様書、コーディング規約、型定義——これが揃っているほどAIは正しく動き、揃っていないと「それっぽいが間違っている」ものが量産されます。そのうえで、自分の開発プロセスを「AIに任せる工程」と「人間が判断する工程」に色分けする。この一枚があるだけで、何から整えるべきかの優先順位が見えてきます。
15分の無料相談、やってます
「AIが来たらうちも終わり？」という問いから逃げずに、一緒に話しましょう。競合他社との比較表はありません。御社の開発プロセスで何が大事になるかを、一緒に整理する時間です。
15分相談を予約する →あなたのチームは、AIと戦ってますか。それとも、使ってますか
最初のMさんの問いに戻りますね。「オフショア開発は終わりか」。
僕の答えはこうです。今まで通りのやり方は、終わりに近い。でも、AIを活かす開発組織としての作り直しは、まだ始まったばかりなんですよね。オフショアの価値は「安い人件費」じゃなくなった。「AIを使いこなせる設計力と、それを継続して運用できる体制」のほうに移ってきている——少なくともうちでは、そう捉えています。
ひとつ、聞いてみたいんです。あなたの開発チームは今、AIと戦っているでしょうか。それとも、AIをチームに組み込んで動いているでしょうか。
もし「まだ戦っている側かもしれないな」と感じたら、よかったら一度、話を聞かせてください。僕もまだ正解を持っているわけじゃないので、お互いの現場の話をする、くらいの感じで。同じ問いから逃げずに1年以上やってきたので、何か持ち帰ってもらえるものはあるかもしれません。
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。