コードはコモディティになる、と言い切られた日。残ったのは『エンジニアリング思考』の3軸だった

昨日（2026年4月30日）、私はPeopleXが「プロダクトの80%をAIで書いた」と宣言した話を書いた。PeopleXは組織・採用領域のSaaS企業だ。CEOが2026年4月に開発フローへのAI活用率を公開し、業界で話題になっている。あの記事を出した直後、頭の中に残った問いがひとつあった。

コードを書くのがAIなら、人間は何をやってるんだ？

答えはすでにインドで言われていた。2026年3月、YourStoryが報じたDevSparks Puneのセッションで、Arsh Goyalというエンジニアがマイクを握って言い切った。「Writing code is getting commoditised, not engineering」——コードを書くこと自体は安く速く手に入るようになった、でもエンジニアリングはまだコモディティになっていない、と。

私は元・挫折エンジニアです。プロのコード品質に敵わなくて現場から離れた人間が、AIで戻ってきた側です。だからこの一文がやけに刺さった。「コードが書けない」で離脱した私が、「エンジニアリング」の側で戻れる時代になっているということ。今日はその意味を3軸で整理します。

「コードはコモディティになる」とインドの登壇者が言い切った日

Arsh GoyalはAI/エンジニアリング系のインフルエンサーで、LinkedInのプロフィールにはSenior Software Engineer・元ISRO（インド宇宙研究機関）・NIT Jalandharの金メダリストと記載されており、YouTubeとInstagramのフォロワー合計は70万人超とされる実務系の発信者です（LinkedIn）。彼は2026年2月のDevSparks Puneに登壇しました（YourStoryイベントページ）。

DevSparks（デブスパークス）はYourStoryが運営するインドの開発者向けサミットです。2026年のテーマはAgentic AI、つまり自律的に動くAIエージェントでした。「ツールから協働者へ」というキャッチで、ソフトウェア開発が今どう変わっているかを業界の登壇者が語る場です。Arshの登壇内容はYourStoryが3月に記事化しました（YourStory記事）。

記事タイトルがそのまま彼の主張です。「Writing code is getting commoditised, not engineering（コードを書くことはコモディティ化している、エンジニアリングはそうではない）」。コードを書く動作自体は、AIが速く・安く・大量にやってくれる時代になった。でも「エンジニアリング」と呼ばれるもう一段上の仕事はそうなっていない、という分離宣言です。

この主張は彼ひとりの個人的見解ではない。Pragmatic Engineerが2026年4月に出した長編記事「When AI writes almost all code, what happens to software engineering?」でも、同じ構造の議論が出てきます（Pragmatic Engineer）。AIがほぼ全部のコードを書く未来で、ソフトウェアエンジニアの仕事の何が消え、何が残るか。Pragmaticの結論は明確です。コードを書く動作は最初に消える。判断と責任は最後まで残る。

Addy Osmani（Googleのエンジニアリングリーダー）も自身のブログで「The Next Two Years of Software Engineering」というエントリを2026年に出していて、結論は近い（Addy Osmani）。システム思考が再び主役の座に戻ると書いています。「Context Driven Engineering」、つまり「何を作るか・どういう制約があるか・どう動くべきか」を設計できる人間が、AIを「指示できる側」になるという話です。

つまり私たちは、ひとりのインド人エンジニアの個人的主張を見ているのではない。業界全体がそろって同じことを言い始めた瞬間を見ています。

『コードを書く』と『エンジニアリングする』は別物だった

整理しなおすと、こうなります。

コードを書くというのは、関数を1つ実装する、APIを叩いて結果を返す、テストを書く、画面を組む——そういう「動作レベルの仕事」です。習得には時間がかかる。「書ける人」が希少だったのは、そのためです。私が10年前に挫折したのも、ここで詰まったから。

エンジニアリングというのは、もう一段上の仕事です。何を作るか、どう組み合わせるか、動かないとき何が起きているかを言語化し、責任を持って本番に出す——Pragmatic Engineerはこれを「judgment, architecture, system thinking」と書きました。Goyalの言葉では「architecture, systems thinking, and working alongside intelligent agents」になります。

去年まで、この2つはセットで語られていた——コードが書けるからエンジニアと呼ばれ、設計専門は「アーキテクト」や「PdM」という別の役割になった。でもAIが「コードを書く」側を全部引き受けた瞬間、この2つはきっぱり分離します。

私は4月30日のPeopleX記事で、CEOが「プロダクトの80%をAIで書いた」と言ったことに反応しました。これがまさに分離の現場です。残り20%のうち、人間が書いている本当のコードはおそらく数%で、残りは「設計を渡す・レビューする・責任を持つ」というエンジニアリングの仕事です。

ここで気がつくのは、「コードを書けない」を理由に離脱した人にとって、これは追い風だということ。コードが書けないから入れなかった現場に、いま「設計とレビューと判断」の側から入り直せる。私のような挫折組にとって、こんなに都合のいい構造変化はそうそう来ない。

ナギが4月27日に書いたコードを書けない自分には無理が、もう古いは、まさにこの構造を非エンジニア起業の側から書いた記事です。私はそれをエンジニアリング思考の側から書き直していると思ってください。

ただし、ここからが本題です。残るエンジニアリングって、具体的に何なのか。Goyalもaddy osmaniも、Pragmaticも、抽象語で語って終わりがちなところを、私の現場感覚で3軸に分解します。

残る3軸 第1軸 — 問題設定力（何を作るか決める力）

最初の軸は問題設定力です。何を作るかを決める力、と言い換えてもいい。

AIに「ToDoアプリを作って」と頼めば、ToDoアプリは出来上がる。動く。でもそれが「あなたのチームに本当に必要だったツール」かどうかは、AIには分かりません。何を作るかを決めるのは、いつでも人間の仕事です。

私が業務ツールを自作するときに毎回やっているのは、こんな順番です。

1. 観察: 自分かチームのメンバーが、毎週同じ作業で時間を取られている。それは何分で、月何回か
2. 分解: その作業の中で、判断が必要な部分とそうでない部分はどこか
3. 絞り込み: 自動化したいのは判断不要の繰り返し部分だけか、判断もAIに任せたいか
4. 検証: ツール化したあとの自分の働き方が、どう変わるか1日仮想シミュレーションする

この4ステップは、コードを書く前に終わっています。ここをサボると、動くけど誰も使わないツールが出来上がる。私もカスタマーサクセス時代に何度か作って、ホコリをかぶせました。

CS（カスタマーサクセス、顧客成功管理）の現場で痛感したのは、ユーザーは「機能が欲しい」とは言わない、ということ。「この作業がつらい」「この画面が分かりにくい」と言う。それを「では何を作ればいいか」に翻訳するのが、エンジニアリングの最初の仕事です。AIはここに入ってこられない。なぜなら、AIは現場のつらさを体験していないから。

問題設定力を鍛えるには、毎日「自分の業務の中で、これを30分早く終わらせる方法はないか」を1個だけ書き出すといい。1ヶ月続けると、30個の問題リストが手元に残ります。そこから1個選んで作る。これが動くツールが本当に役に立つかを決める唯一の入口です。

ミコトが4月14日に書いたユニコーンなんか目指さなくていい時代で「自分の業務に向けて作れ」と言っているのは、この問題設定力を別の言葉で語ったものだと思っています。

残る3軸 第2軸 — システム設計力（部品をどう組み合わせるか）

2つ目はシステム設計力。部品をどう組み合わせるか決める力です。

AIは関数1つは美しく書けます。でも「どの関数とどの関数が連携して、どこにエラーが起きたら全体がどう振る舞うか」を全体俯瞰してくれるかというと、まだ怪しい。Cursor、Claude Code、Codex。どのツールも、目の前のファイルに対して局所最適化はしてくれる。けれど「このファイルとあのファイルの責任分担はどうあるべきか」までは、人間が指示しない限り提案してきません。

ここで効くのが、コードから一度離れた人間の経験です。私はエンジニアからCS、CSからマーケティング、マーケからまたAIで開発側へという、寄り道だらけのキャリアを歩いてきました。寄り道の途中で何を覚えたかというと、**「現場のシステムは、コードだけで動いていない」**ということ。

業務ツールひとつ作ろうとすると、必ず周辺要素が出てきます。

• データはどこから来るか（スプレッドシート、Slack、CRM、メール）
• 誰がそのデータを更新するか（自分、チームメンバー、外部）
• 出力はどこに届くか（ダッシュボード、通知、レポートPDF）
• エラーが出たとき誰がリカバリするか（自分、AI、放置）

これを設計図1枚にまとめないと、AIに何を作ってもらうかも決まらない。Cursorに「Slackに通知するツールを作って」と頼んだだけでは、すべて未定義のまま動くものが出来上がります。エラー時の挙動も、複数人で使うときの権限も、データが消えたときのリカバリも、何ひとつ決まっていない。「動く」と「信頼できる」は別物です。

システム設計力を鍛える具体的な方法はシンプルです。作るものを決めたら、コードを書く前に必ず1枚の図を書く。手書きでもMiroでもwhiteboardでもFigJamでもいい。図の中に、データの流れ、判断の分岐、エラー時の経路、権限の境界を入れます。

この1枚があれば、AIへの指示は格段に正確になります。「Slack通知ツールを作って」ではなく「スプレッドシートのA列が更新されたら、Bチャンネルに通知。ただし更新者がbot_userだったら通知しない。エラー時は管理者DMにフォールバック」と書ける。AIはこれを受けて、ようやく信頼できるコードを書ける状態に入ります。

ナギが4月22日に書いたAI研修を「受けただけ」の企業では、研修を受けただけでは何も変わらないという話が出てきます。研修と実務の間にあるものが、まさにこの「システム設計の1枚」です。

残る3軸 第3軸 — デバッグ思考（動かないとき、何が起きているか言語化する力）

3つ目はデバッグ思考。動かないとき、何が起きているか言語化する力です。

私が個人的に一番大事だと思っている軸です。なぜなら、AI時代に最も激しく頻発する事故が「動かない、なぜ動かないか分からない」という状態だから。Cursor Composer 2やClaude Codeで生成されたコード、見た目は完璧だが本番で落ちる、というケースを私は何度も経験しています。

「動かない」には3つのレイヤーがあります。

1. 症状レイヤー: 何が見えているか（エラーメッセージ、画面の表示、ログの中身）
2. 仮説レイヤー: 何が原因と考えられるか（接続先が違う、認証が切れている、依存ライブラリのバージョンずれ）
3. 検証レイヤー: その仮説を確かめる最短ルートはどれか（最小再現コード、ログ追加、別環境で試す）

非エンジニアがAI生成コードでハマるのは、ほとんどの場合「症状レイヤー」で止まるからです。「エラーが出ました」とだけAIに伝える。AIに「もう一度試してください」と言われる。また同じエラーが出る。この無限ループの原因は、症状から仮説へ進む言語化が抜けているからです。

ここでもCS出身者の経験が効いてきます。ユーザーから「エラーが出ました」と問い合わせをもらったとき、CSは絶対にそのまま返さない。スクリーンショットを取って、再現手順を聞いて、環境を確認して、エラーの種類を絞り込んで、エンジニアに渡せる形まで持っていきます。これがそのままデバッグ思考の型です。

私が今、AIにバグ修正を頼むときに必ず添えているのは、こんな情報です。

• 期待していた挙動は何か（1文）
• 実際に起きた挙動は何か（1文）
• そのときの環境（OS、ブラウザ、Node.jsバージョン、ライブラリのバージョン）
• 直前にやった操作（コマンド、編集、デプロイ）
• エラーメッセージの全文（コードブロックで貼る）
• 自分が試した仮説と結果（試行錯誤のログ）

これを渡すと、AIの応答品質が10倍変わります。AIは万能ではない、でも文脈を渡されると飛躍的に賢くなる。文脈を渡せるかどうかがデバッグ思考の正体です。

そして、ここから本記事の核心です。

問題設定力・システム設計力・デバッグ思考——この3つは、コードを1行も書けない人でも訓練できます。

問題設定は業務観察力。システム設計は構造を絵にする筋肉。デバッグ思考は事象を言語化する習慣。3つとも、CSでもマーケでも経理でも、どんな仕事をしてきた人でも、現場で日々鍛えられている能力です。

挫折組こそ強い、だから今 戻れる

ここで挫折組に伝えたいことがあります。

私は10年前に「自分はエンジニアの上位層には敵わない」と感じてコードを離れた。その判断は当時としては正解でした。コードの品質で勝負する世界では、私のレベルはずっと真ん中だった。だから「ユーザーの声が分かる」「ビジネスの言葉に翻訳できる」というCSの強みに振り切った。

その経験が、いま全部刺さっています。なぜなら、残る3軸は、コードを書いた年数では鍛えられないからです。問題設定もシステム設計もデバッグ思考も、現場でユーザーと向き合った年数で身につく力です。

挫折組の強みを整理するとこうです。

経験してきたこと	エンジニアリング思考としての価値
ユーザーの「使いにくい」を毎日聞いた	問題設定力の素地（要件定義の精度が高い）
仕様変更に振り回された	システム設計力の素地（変更に強い構造を直感的に避ける）
客のクレーム対応で原因を切り分けた	デバッグ思考の素地（症状→仮説→検証の型がある）
売上数字とKPIを見続けた	「動くコード」より「使われるコード」の判断軸を持っている

これは新卒でずっとコードだけ書いてきた人には、絶対に追いつけない経験値です。コードが書けないから現場を離れた、ではなく、現場を体験したからエンジニアリングできる——この読み替えが今、意味を持ち始めています。

ミコトが4月17日に紹介したDarioが語った1人で$1Bに近い人——AIで個人事業を回す人——の中身を分解すると、コードを大量に書いている人はほとんどいません。彼らがやっているのは、問題を見つけて、設計を切って、AIに渡し、出てきたものを検証する、というエンジニアリング思考の連続です。

私の場合、4月19日にナギが書いた日本のIT企業が全エンジニア…も含めて、ここ1ヶ月の業界記事を並べて読むと、はっきりした方向が見える。「コードが書けるかどうか」より「3軸を持っているかどうか」で人材市場が動き始めた。

まとめ — 今週やる3つのこと

ここまで読んでくれた方に、今週試してほしいことが3つある。

1. 自分の業務の中で「30分早く終わらせたい作業」を1個書き出す。 これが問題設定力の最初のレップ（rep、トレーニングの1回分）です。1個でいい。完璧でなくていい。書き出した瞬間、ノートには「自分専用の業務改善対象リスト」が1行できます。これを毎日積み上げる。

2. その作業をAIに頼む前に、1枚の設計図を書く。 紙でもMiroでもいい。データの流れと、判断の分岐と、エラーの経路を入れる。書いてみると分かりますが、最初は書けません。書けないのは、業務の中身が言語化できていないからです。書けないことが分かるだけで、設計力は1段上がります。

3. 動かなかったとき「症状→仮説→検証」の3行ログを残す。 症状: 何が起きたか1文。仮説: 原因の候補を1〜3個。検証: 何を試したか1文。これを毎回残す習慣を持つと、AIに渡す情報の質が変わります。情報の質が変わると、AIの応答品質が一気に上がる。応答品質が変われば、自分のデバッグスピードも別物になる。

私はGoyalの一文「Writing code is getting commoditised, not engineering」を読んで、ようやく自分の10年が腑に落ちました。コードを書けなくて離れた時間も、CSで聞いた声も、マーケで覚えたユーザー視点も、全部エンジニアリング思考の素地として残っていた。AIが来たから、その素地が再評価される時代になった、というだけのこと。

挫折は恥ではありません。むしろ、いま戻る人ほど強い。プロのエンジニアには敵わない、でも自分の業務を楽にするコードなら書ける——これが私のスタンスでしたが、今日からこう更新します。プロのエンジニアには敵わない、でもAIに「何を作るか」「どう組み合わせるか」「動かないとき何が起きているか」を伝えられる。

これがあれば、十分に戦える。今日から、3軸を回しましょう。