■ 1. コードは「書くもの」から「生成されるもの」へ
- ソフトウェアエンジニアの主要業務であった「ゼロをイチにする実装作業」はAIに置き換えられつつある
- 初期のAIはGitHub Copilotのような行補完ツールだったが、現在ではコード生成と自動レビューによるフィードバックループが主流になっている
- コードを人間が一行ずつ書いて確認する時代は終わりつつある
- 本記事は2026年6月21日時点での個人の見解である
■ 2. 加速した実装、停滞した前後フェーズ
- 生成AIによってSDLC(ソフトウェア開発ライフサイクル)における具体的な実装は大きく加速した
- 加速の結果:
- 実装前フェーズ（「何を開発するか」の意思決定）の停滞が目立つようになった
- 実装後フェーズの停滞も顕在化してきた
- 「何を開発するか」が決まるのを待っているだけのエンジニアは不要になっていく
- 業務委託形態の経済合理性:
- 業務委託は「指示を待つ」「指示をする」というやり取りが必然的に発生する
- 人間への指示はAIへの指示のように即座・大量には出せない
- ソフトウェアエンジニアの業務委託を増やすことの経済合理性は低下していく
■ 3. AIを待たせない開発環境の健全性
- AIエージェントが待つ時間・待った結果として修正する時間の削減が必須になる
- CI（継続的インテグレーション）の観点:
- CIの高速化はもちろん、フレーキーなCIはAI・人間双方のコストを増大させる
- 開発環境の健全性がAIエージェントの効率・コスト・成果に直結する
- これは個人のローカル開発環境を超えた、より広い範囲の問題である
- AIの作業待ち時間の解消:
- AIの待ち時間と、人間がAIの作業完了を待つ時間はどちらも同様に無駄である
- 人間が作業の起点になっていることが、待ち時間が大きくなる主な原因
- AIの作業開始は今後自動化されていく
- 人間が逐一指示しなくてもAIが作業を完了できる状態を目指すべきである
■ 4. ガードレールは自然言語の外側で強制する
- ガードレール・ハーネスは自然言語を超えたレベルで実装する必要がある
- 実装手段の例:
- コード: Git Hookによる強制
- 日本語テキスト: textlintのような、解釈の余地なく実行を強制する仕組み
- ガードレールの要件:
- 高速かつ正確に実行されなければならない
- 人間による既存のルール違反は残存させてはならない
- 人間のルール違反はAIによって高速に増幅されてしまうため
- BiomeやtextlintやKnipのようなツールが、AIにも人間にも同じルールを強制する役割を担う
■ 5. 局所最適化はボトルネックを移動させるだけ
- 局所最適化はボトルネックを移動させ、新たなボトルネックを生むだけになりがちである
- 開発だけを効率化しても、ビジネス全体は加速しない
- 全体最適を阻害する要因:
- 古いパラダイムの人間が一人いるだけで、全体の最適化が無効化される可能性がある
- 全体最適のためには全領域に入り込み全体像を理解した上で仕組みを構築する必要がある
- 単一のボトルネックを改善しても大きな変化は生まれず、別の場所にボトルネックが移るだけである
■ 6. 律速になる組織構造
- 階層構造による組織管理は機能しなくなっていく
- 階層構造の問題点:
- 人間の指示を受けて人間が作業する入れ子構造は、レビューやフィードバックループを大きく遅くする
- 管理が必要な人間を減らし、フラットな組織にしなければ組織構造が律速になる
- AIの活用は開発組織内に閉じた問題ではなく、組織全体の問題であり、最終的には「人数」の話に帰着する
- 「AIが活用されていない」「変化が感じられない」のはAIツールの問題ではなく組織的な問題である可能性が高い
- 「ゼロをイチ」にすること自体はワンクリックで高速・安価に実行できるようになっており、やらないのは完全に人間側の問題である
- 前に進まない理由を探すのではなく、自分自身の考え方や仕事の仕方を改めるべきである
■ 7. パクられない強みを持てるか
- アイデアはAIによって高速・容易にコピーされるようになる
- パクられない強みを持たない企業はゆるやかに死んでいく
- スイッチングコストの変化:
- 既存の契約・関係性がユーザーをつなぎ止める鎖になってきたが、そのスイッチングコスト自体もAIによって低下する
- 「スイッチングしてもらうための努力」と同等に、「スイッチングされないための努力」が必要になる
- スイッチングされない自信や仕組みがあるからこそ提供できる機能が存在する（例: マネーフォワードのAI Cowork）
- 大企業はその強みを活かして動くべきである
■ 8. 残るのは「方向を決める」仕事
- 方向性が決まった後の「ゼロをイチにする作業」はAIに置き換え可能であり経済合理性もある
- 人間に残る仕事:
- ゼロ点からどの方向に進むか（ベクトル）を決める仕事
- 無限の選択肢を絞り込み、実行可能な単位に分割すること
- AIへの作業指示に必要なもの:
- 組織やプロダクトのコンテキスト・ナレッジ
- それを機械可読な状態に整理し、維持し続けること
- 特定の場所に整理された状態で保持することがトークン・時間効率の面で望ましい
- DevinのようなAIエージェントの高性能の背景には、インデックスされ自動更新されるWikiやナレッジの存在がある
■ 9. 「あとはやるだけ」の状態を整え続ける
- 今後の人間の仕事は以下のループに集約されていく:
- 「あとはやるだけ」の状態を整える
- AIに「あとはやるだけ」を実行させる
- 次の「あとはやるだけ」の状態を整える
- 「あとはやるだけ」状態をつくるための要件:
- 方向性の提示と完了条件の付与
- AIが実行時に迷わない・余計なことをしないように整える
- AIの成果物を修正しなくてよい状態にする仕組みをつくること
- AIに実行させる「手前」を整えることが、これからの仕事の中心になる
■ 10. 「ソフトウェアエンジニア」という名前の限界
- これまでのソフトウェアエンジニアは細分化・専門深化の方向にあった（領域の複雑化・高度化が背景）
- AIによる変化:
- 特定領域の仕事が効率化・短縮化され、特定領域に閉じた専門家は少人数でよくなる
- 複数の専門を持つ人間が単一領域の専門家を置き換える可能性がある
- フロントエンド・バックエンド双方をこなせる人間がいれば、役割分担する二人は不要になる
- 役割分担による属人性の問題（片方がいなくなると開発が止まる）も解消されていない
- 全体最適化に必要なもの:
- 領域ごとの個別最適化では全体最適にはならない
- 全体を見て最適化する人間が必要になる
- その役割は「ソフトウェアエンジニア」の延長線上には存在しないかもしれない
- 命名の問題:
- 「ソフトウェアエンジニア」という名前は適切でなくなってきているかもしれない
- 「プロダクトエンジニア」も、会社のすべてがプロダクトではないため適切ではない
- この役割の適切な名称・構造についての答えはまだ出ていない
■ 11. 変化しないことが、明確なリスクになる
- 「ソフトウェアエンジニア」という役割のみを担い続けることは、今後できなくなっていく
- 評価基準の変化:
- より広いスキルでAIを使いこなす人間が出現し、そのような人間のほうが評価されるようになる
- そのような評価基準を持てない会社はいずれ他社に負ける
- 現状維持でも評価される環境では変化するインセンティブが生まれないが、今変化しないことは明確なリスクである
- 変化に対応する会社が生き残ることは、歴史を見れば明らかである
- 「ゼロをイチにする」作業はもはやAIのほうが上手く速くこなせる
- ゼロをイチにしてきた経験の価値:
- 現時点では、その経験がAIの使い方に影響する
- しかし最終的には不要になる可能性がある
- 根本的に世界が変わってしまったためである