AIが『How』を肩代わりする時代にエンジニアは何に向き合うべきか

はじめに

こんにちは、株式会社エムニでエンジニア・PMとして働いている宮木です。
Claude Code、マジで便利ですよね。

自分も、ここ1年で個人の実装スピード、体感で5〜10倍くらいになった気がしてて。「実装もう終わったの?」って言われることも増えたし、プロトタイプなら一晩で作れたりもする。

ただ、組織で開発を進める場合には引っかかる部分があります。

個人の実装は爆速になったのに、お客さんが「良くなった」と感じる速度って、本当に上がってる?

実装速度と、ユーザーに価値が届く速度って、別物だよなって。後者こそ本来追いかけるべきところなのに、そのギャップが結構あるなと感じてます。

この記事では、AI駆動開発の文脈の中で、なぜDevOpsという「土台」が今こそ大事なのか、エンジニアの思考の軸はどう変わるべきなのか、自分なりに整理してみます。これからAI駆動開発と本気で向き合っていきたいなって考えてる人に、何かしら届けばいいなと思っています。

なお本記事は、広木大地さんの『エンジニアリング組織論への招待』^[1]の不確実性論を強く下敷きにしています。

そもそも、なぜ我々はソフトウェアを作るのか

ちょっと青臭い問いから始めます。

ソフトウェア開発の目的って何でしょうか?「動くコードを書くこと」?「機能をリリースすること」?

たぶん違いますよね。ユーザーの課題を解決することが目的で、コードもリリースもその手段でしかない。

ソフトウェア開発の本質は「不確実性を減らす営み」

広木さんは『エンジニアリング組織論への招待』の中で、エンジニアリングを 「不確実性を効率よく削減する活動」 として定義しています。同書では、ソフトウェア開発における不確実性が3つに整理されています。

• 目的不確実性:何を作るべきかの不確実性(顧客が本当に欲しいものは何か、価値仮説は正しいか)
• 方法不確実性:どう作るかの不確実性(技術選定、設計、実装の正しさ)
• 通信不確実性:人と人の認識のズレから生まれる不確実性(チーム内、開発と運用、ビジネスと技術)

この前提に立つと、本当の生産性って何かが見えてきます。

不確実性の削減速度 × 価値提供速度

• どれだけ速く「ユーザーが本当に欲しいもの」「有効な解決策」「正しい設計」を学べるか
• 学んだ結果を、どれだけ速く価値として届けられるか

実装速度はこの掛け算の中の一要素でしかないんですよね。

「アウトカム起点で考える」という言葉がよく使われますが、要はこれです。アウトプット(作ったもの)じゃなくて、アウトカム(顧客に起きた変化)を見ようね、という考え方。そしてアウトカムが生まれるには、不確実性を減らし続けることが必要、というわけです。

AIが変えたのは「How」、人間が向き合うべきは「What」と「Why」

もう一つ、視点の話をさせてください。

これまでエンジニアの価値の多くは「How(どう作るか)」にありました。良いコードが書ける、難しいアルゴリズムが実装できる、複雑なシステムが設計できる。これは間違いなく価値だったし、今も大事です。

ただ、AI駆動開発はHowをかなり民主化しました。Claude Codeを使えば、TypeScriptもRustもPythonも、それなりに動くコードが出てきます。実装力の差は、確実に縮まってきている。

不確実性の言葉で言い直すと、AIは方法不確実性の処理コストを大きく下げてくれたということです。

ではエンジニアの価値はどこに移るのか。私はこう考えています。

• What(何を作るか):目的不確実性を減らす営み。どの課題を、どの優先順位で、どこまでのスコープで解くか
• Why(なぜ作るか):目的不確実性の根っこ。顧客の本質的な課題は何か、なぜ今これをやるのか、価値仮説は何か

Howだけを磨いてきたエンジニアは、これからAIに代替されていくと思います。逆に、What/Whyを考えられるエンジニアは、AIを使い倒して何倍もの価値を出せる。

ここで誤解されたくないのは、「エンジニアは全員PMになれ」という話ではないということです。そうではなくて、コードを書く一人ひとりが、自分の作るものの Why と What をちゃんと理解している状態を目指すべきだよね、という話です。

「これは誰の何を解決するのか」を、コードを書く前に問える人。AI時代に強いのは、そういうエンジニアじゃないかなと思っています。

歴史を振り返る:不確実性削減の進化として読む

ここで、技術的発展の歴史を振り返ってみます。

技術的発展の階層構造 — 各層は前の層が抱えていた不確実性に対処するために生まれた

ソフトウェア開発の歴史って、 「どの不確実性に、どう対処してきたか」 の進化として読み解けます。ざっくり4つのフェーズで見ていきます。

反復型開発の登場(1980〜90年代):方法不確実性に対処する

ウォーターフォール時代の「全部作りきってから初めて動かす」という構造は、巨大な失敗リスクを生んでいました。これに対する反省として、スパイラルモデル^[2]やRUPなどの反復型・漸進型の開発手法が広がります。

要するに、「方法不確実性(=作り方が正しいかへの不安)を、早く減らそう」 というアプローチです。全部作りきる前に動かしてみれば、設計や実装の問題を早く発見できる、というシンプルな発想ですね。

アジャイルの誕生(1990年代後半〜2001年):目的不確実性に正面から取り組む

1990年代後半、Scrum、XP、Crystalなどの軽量な開発手法が次々と生まれます^[3]。そして2001年、これらの提唱者17人がユタ州 Snowbird に集まって、「アジャイルソフトウェア開発宣言」をまとめました^[4]。それまで「軽量(Light)手法」と呼ばれていたものが、ここで「アジャイル」という名前を得ました。

アジャイルが起こした本質的な変化は、「顧客の声」を開発サイクルに正式に組み込んだことです。動くソフトウェアを早く出して、フィードバックを得て、次の優先順位を決める。「顧客が本当に欲しいものは、作って見せるまでわからない」という前提に立った考え方ですね。

これは目的不確実性(=何を作るべきかへの不安)に対する正面からの回答でした。

ちなみに継続的インテグレーション(CI) の概念は、実はもう少し古くて、1991年に Grady Booch が提唱、1994年の著書で記述されています。それを実践として定着させたのが、Kent Beck らによるXPです^[5]。

DevOpsムーブメント(2009〜):通信不確実性と検証サイクルへ

アジャイルで「速く作れる」ようになっても、開発(Dev)と運用(Ops)の間に深い溝があれば、本番に届けるまでに時間がかかる。これだと「学んだことをすぐ届ける」ことができず、目的不確実性の検証サイクルが律速されてしまいます。

転機になったのが、2009年の Velocity Conference での John Allspaw と Paul Hammond の講演 "10+ Deploys per Day: Dev and Ops Cooperation at Flickr" でした。当時は「月1回のリリースで野心的」とされていた中で、1日10回以上デプロイできるという話は衝撃的だったようです。同じ年、Patrick Debois がベルギーの Ghent で DevOpsDays を初開催し、ここで "DevOps" という用語が確立します。翌2010年には Jez Humble と David Farley が 『Continuous Delivery』 を出版し、デプロイメントパイプラインの考え方が体系化されました^[6]。

DevOpsの本質的な貢献は2つあると思っています。

1. 通信不確実性の削減 — Dev/Opsの組織的な壁、認識のズレ、コミュニケーションコストを、文化と自動化で減らす
2. 目的不確実性の検証サイクルの高速化 — CDによって学んだことをすぐ本番に届け、顧客のフィードバックでさらに学ぶループを回す

AI駆動開発(2020年代〜):方法不確実性の処理を機械に肩代わりさせる

そして現在。GitHub Copilot、ChatGPT、Claude、Cursor、Claude Code などの登場で、AI駆動開発が一気に広がりました。

これは単に「実装が速くなる」話ではなくて、本質的には方法不確実性の処理コストを大きく下げているんだと捉えています。どう書くべきかの問いにAIが提案してくれる。設計のたたき台が一瞬で出てくる。実装の選択肢を比較しやすくなる。ドキュメントやテストの自動生成で、仕様の明文化コストも下がる。

結果として、エンジニアが 目的不確実性と通信不確実性に集中できる「はず」 の時代になりました。「はず」と書いたのは、土台がない組織では、これが実現しないからです。

---

歴史を振り返って見えてくるのは、人間が向き合うべき不確実性の重心が、方法不確実性から目的不確実性・通信不確実性へとシフトしてきたという流れですね。

そして大事なのは、各層は前の層が抱えていた不確実性に対処するために生まれているということ。スキップできる層はないんです。

AI駆動開発が土台を必要とする3つの理由

ここからが本題です。なぜAI駆動開発はDevOps基盤を必要とするのか。不確実性の言葉で3つ挙げます。

理由1:AIで実装が速くても、検証できなければ「目的不確実性」は減らない

AIは大量にコードを生成します。一人のエンジニアが一日で書ける量が、明らかに増えました。

でも、生成されたコードが「正しく動くか」「本当にユーザーの課題を解決しているか」を検証する仕組みがないとどうなるか。

• 動作確認は手動 → ボトルネック化
• レビューは人間 → 認知負荷が爆増
• バグは本番で発覚 → 顧客が真っ先に気づく
• 仮説の検証ができない → 「この方向性で合ってるか」がいつまで経ってもわからない

これだと、せっかくAIで速く作っても、「本当に学べたのか」を確認するサイクルが止まってしまいます。目的不確実性が減らないんですよね。

CIとテストって、こう考えると「品質を守るためのもの」というより、「不確実性を減らし続ける速度を守るためのもの」 として再定義できる気がします。テストが落ちたら直す、CIが赤いままにしない。これは品質の問題以前に、チームの学習速度を守る行為なんだなと。

理由2:AIで作っても、届けられなければ「目的不確実性」は減らない

実装が爆速になっても、リリースが月1回なら、顧客に届く速度は月1回のままです。そして顧客に届かなければ、どう使われるか、本当に欲しかったものなのか、というフィードバックは永遠に得られません。

CDが整っていない組織だと、AI駆動開発の恩恵は本番の手前で詰まります。マージされたコードが何週間もstagingで眠って、リリース日にまとめて出される。途中でコンフリクトが起きる。リリース直前にバグが見つかって後ろ倒し。よくあるパターンですよね。

CDは、AI時代において 「目的不確実性を減らすための情報経路」 として機能します。これがないと、AIで作ったものは倉庫に積み上がるだけで、肝心の「顧客の反応」という情報が手元に届かないんです。

理由3:AIは目的不確実性も通信不確実性も持っていない

これが一番見落とされがちですが、たぶん一番大事なポイントです。

AIは、あなたのプロダクトの顧客が何に困っているかを知りません。あなたのチームが今期何を優先すべきかも知りません。これまでにどんな仮説を試して、何が外れたかも知りません。

AIに与えられる文脈は、人間が用意したコードベース、ドキュメント、Issue、設計判断だけです。

つまり、

• 良い設計のコードベース → AIも良いコードを書きやすい
• 整理されたIssueとドキュメント → AIも適切な実装ができる
• 明確な技術選定 → AIが暴走しない

逆に言えば、Garbage In, Garbage Out。乱雑なコードベース、書きかけのドキュメント、曖昧なIssueにAIを走らせると、乱雑な成果物が爆速で量産されます。

これって不確実性の言葉で言うと、「通信不確実性を減らすこと」 そのものなんですよね。コードベース、ドキュメント、Issue、レビューでの議論、設計の意思決定記録(ADR)。これら全部が、人間からAIへの「通信」を機能させるための装置になります。

そして、顧客の声を取り込んで「次に何を作るか」を決める仕組み(=DevOps文化のフィードバックループ)がなければ、AIは見当違いの方向に爆速で走り続けることになります。

---

3つの理由に共通する本質はシンプルです。

DevOps基盤は、エンジニアが Why/What に集中できる環境を作っている

土台がない組織では、AI駆動開発は「速く間違える」装置になりがちです。エンジニアはAIの生成物のレビューと不具合対応に追われ続けて、結局Howの世界から抜け出せない、っていう。

アンチパターン:土台がないままAIを入れるとどうなるか

具体的に何が起きるか。よく見聞きするパターンを並べてみます。

• PRが詰まる:AIが生成したPRが大量に積み上がって、レビュアーが追いつかない。レビュー待ちで仕事が止まる
• テストなしAI生成コード:テストがないコードベースに、AIで機能を追加し続ける。動いてるように見えて、実は何が壊れているかわからない
• 「動いた」が信用できなくなる:ローカルで動いた、AIが「動きます」と言った、でも本番で壊れる。テスト網がないと「動いた」の意味が崩壊する
• デプロイ恐怖症の悪化:コードベースは膨らむのに自動化が追いつかず、リリースのたびに祈る時間が増える
• 顧客視点の悲劇:「機能は増えたのに、使いにくくなった」「リリース速度は上がったのに、不具合も増えた」「対応してくれるのは速いけど、結局直っていない」

「速く作る」が「速く壊す」になる。「速く届ける」が「速く謝る」になる。これが、土台のない組織のAI駆動開発の現実だなと。

そして個人的に一番きついなと思うのは、エンジニア自身がHowの沼から抜け出せなくなることです。AIで速くなったはずなのに、その分の時間がレビューと不具合対応に吸い取られる。Why/Whatを考える時間が逆に減る、という逆説が起きるんですよね。

じゃあ、現場のエンジニアとして何をすべきか

ここまで読んで、「で、自分は何すればいいの?」と思った方へ。

特別なことではなくて、明日からできる小さな習慣の話です。

アウトカム起点で考える習慣をつける

PRを書くとき、Issueを切るとき、設計を考えるとき、自分にこう問いかけてみてください。

「これで、顧客の何が変わるのか?」

この問いに答えられないなら、まだ「コードを書く準備ができていない」状態かもしれません。

コードを書く前に Why と What を言語化する

Issueの説明欄、PRのdescription、Slackの相談、何でもいいです。「なぜこれをやるのか」を一行でいいから書く習慣をつけてみるといいかなと。

書けないなら、まだ理解できてない証拠です。書く前にもう一段考える。これだけで、AI時代にけっこう差がつくと思います。

これは通信不確実性を減らす行為でもあって、自分の頭の中にしかない「なぜ」を言語化することで、チームメンバーにも、未来の自分にも、そしてAIにも、文脈が伝わるようになります。

テストを書く = 不確実性を減らし続ける速度を守ること

テストは「品質を守るため」だけのものじゃないんですよね。チームが安心して速く仮説検証するための装置でもあります。

「テストを書く時間がない」と思ったら、ちょっと立ち止まってみてほしいです。それって「学習を止めても速く作れ」と言ってるのと同じじゃない?と。

CIを守る = チームの学習速度を守ること

CIが赤いままmainにマージしない。落ちたら直す。skipしない。

これは規律の問題というより、チーム全員の学習速度を守る行為です。CIが赤いコードベースだと、AIに何かを依頼しても結果を信用できないので、めぐりめぐって自分も困ることになります。

レビューを「Howのチェック」だけでなく「What/Whyの議論の場」にする

レビューで「ここの実装、こうしたほうがいい」だけを指摘してませんか?

それも大事なんですが、「これって本当にやる必要ある?」「これでユーザーの何が変わる?」 みたいな問いも投げかけられるようになると、チームのアウトカム志向が一段上がる気がします。

「動いた」ではなく「顧客に価値を届けられる状態」を目指す

「ローカルで動きました」「PRマージしました」で満足しない。

顧客が使える状態になって初めて、自分の仕事は終わる。この感覚を持てるかどうかが、AI時代のエンジニアの分かれ目かなと思っています。

おわりに

AI駆動開発の本質って、方法不確実性の処理を機械に肩代わりさせることだと思っていて。

だからこそ、人間に残されるのは目的不確実性と通信不確実性で、Why/Whatを問い続けて、それをチームや顧客と共有し続ける営み。これがAI時代のエンジニアの仕事になっていくはずだなって。

そしてDevOps基盤は、この営みを支える土台。基盤がないと、目的不確実性を減らす学習サイクルは回らないし、通信不確実性を減らす自動化や標準化も機能しないんですよね。

AI駆動開発って、土台がある人ほど恩恵を受ける、非対称な技術だなって思ってます。

• DevOps基盤がある組織では、AIは学習サイクルを加速する道具になる
• 基盤がない組織では、AIは混乱を加速する装置になる

エンジニア個人としても、

• Howだけを磨いてきたエンジニアは、AIに代替されていく
• What/Whyを考えられるエンジニアは、AIを使い倒して何倍もの価値を出せる

DevOpsを学ぶことって、単に「インフラの仕事」を学ぶってことじゃなくて、AI時代に自分自身の価値を高めるための、けっこう確実な投資なんじゃないかなって。

そして最終的に目指すところは、シンプルに一つだなと思ってます。

顧客に、速く、確実に、価値を届けること。

実装が10倍速くなったその先に、ユーザーアウトカムも10倍になる世界を目指したいですよね。そのためには、土台が必要だなって。

最後まで読んでくれてありがとうございました。明日からコードを書く一行目で、ぜひこの問いを思い出してみてもらえると嬉しいです。

「これで、顧客の何が変わるのか?」

そこから、AI時代のエンジニアの仕事は始まるんじゃないかなって思ってます。

---

参考文献

• 広木大地『エンジニアリング組織論への招待 〜不確実性に向き合う思考と組織のリファクタリング』技術評論社、2018年
• 高橋裕之(ファインディ株式会社)「ソフトウェア開発現代史: 55%が変化に備えていない現実 ─ AI支援型開発時代のReboot Japan」Agile Japan 2025、2025年11月14日
• Beck, K. Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999
• Humble, J. & Farley, D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley, 2010
• Kim, G., Humble, J., Debois, P., Willis, J. The DevOps Handbook, IT Revolution Press, 2016
• Larman, C. & Basili, V. R. "Iterative and Incremental Development: A Brief History" IEEE Computer, 2003
• "Manifesto for Agile Software Development" https://agilemanifesto.org/

本記事の階層構造図は、ファインディ株式会社 高橋裕之氏による Agile Japan 2025 講演「ソフトウェア開発現代史: 55%が変化に備えていない現実 ─ AI支援型開発時代のReboot Japan」^[7]の中で示された「技術的発展の階層構造」を参考に、本記事のメッセージに合わせて再構成したものです。

脚注

1. 広木大地『エンジニアリング組織論への招待 〜不確実性に向き合う思考と組織のリファクタリング』技術評論社、2018年

2. Boehm, B. "A Spiral Model of Software Development and Enhancement", 1986. インクリメンタル開発の起源自体はもっと古く1950〜60年代まで遡れます(参照: Larman & Basili "Iterative and Incremental Development: A Brief History" IEEE Computer, 2003)。

3. Scrum (Sutherland & Schwaber, 1995)、Extreme Programming (Beck, 1996)、Crystal (Cockburn, 1996) など。

4. "Manifesto for Agile Software Development", 2001年2月. https://agilemanifesto.org/

5. Beck, K. Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

6. Humble, J. & Farley, D. Continuous Delivery, Addison-Wesley, 2010. その後の体系化として Kim, G., Humble, J., Debois, P., Willis, J. The DevOps Handbook, IT Revolution Press, 2016 も。

7. 高橋裕之(ファインディ株式会社) 「ソフトウェア開発現代史: 55%が変化に備えていない現実 ─ AI支援型開発時代のReboot Japan」Agile Japan 2025、2025年11月14日. https://2025.agilejapan.jp/timetable_day2/