AIソフトウェア開発の未来

2026年2月19日原文(martinfowler.com)

概要

Thoughtworks Future of Software Development Retreat の主な議論点と業界への影響についてまとめる。 AI時代のソフトウェア開発 における課題と新しい実践、組織構造の変化を紹介。 LLMやAI技術 による専門性の変化とコスト、役割の再定義について考察。 セキュリティやプラットフォームの重要性、および多様性と対話の文化について言及。 コードヘルスやTDDの価値、AIフレンドリーな開発の実践的知見を共有。

Thoughtworks Future of Software Development Retreatの振り返り

Thoughtworks主催 のFuture of Software Development Retreat参加報告
新たなAI開発マニフェスト 策定の場ではなく、現状の課題と展望の共有が主目的
イベント要約PDF は8つの主要テーマで議論を整理
- 「厳密性の行方」「新しい中間的な作業カテゴリ」「技術基盤：言語・セマンティクス・OS」「人間側：役割・スキル・経験」など
AI支援開発 により従来の人間中心の開発手法や組織構造が機能不全に
新たな実践や組織構造 は形成途上、成熟には至らず

AI時代の開発現場の実感

Annie Vellaの感想 ：AI導入やチーム再編の「正解」は未だ模索中
不確実性が支配的 で、全員が手探り状態
共通認識の形成 が最大の成果
問いの共有 が今後の議論の出発点

AIの加速効果とリスク

AIは「加速装置」 として既存のプロセスを増幅
DORA 2025レポート ではAIの役割を「アンプリファイア」と定義
コード執筆速度向上 はボトルネック解消には直結せず、むしろ技術的負債の加速要因
従来のベストプラクティス未整備 の場合、AI導入が負債増幅に

LLMがもたらす専門性の変化

LLM普及により フロントエンド・バックエンド専門家の役割縮小
Expert Generalistの台頭 や、LLMによるサイロ横断の可能性
LLMがサイロを回避するのか、解消するのか は今後の課題
LLM利用コスト の将来予測は不透明、コスト次第で使い方が大きく変化

ワークフローと開発プロセスの変化

仕様主導型開発 （ウォーターフォール回帰）の懸念
LLMによる進化的設計 支援の効果はワークフロー次第
小さな機能単位でのリリース の価値は変わらず、LLMはそのサイクルを加速

セキュリティとプラットフォームの重要性

AI導入に慎重な大企業 の姿勢（先端から四半期遅れで採用）
セキュリティは後回し になりがちだが、AI時代はプラットフォームの設計が鍵
AIベンダーの責任 と安全設計の必要性
「バレットトレイン」的な安全かつ迅速な導入経路 の確立が重要

オープンスペース形式と多様性

Open Space形式 の議論による深い対話と多様性の尊重
参加者全員が対等に議論 できる場の価値
Thoughtworksのカルチャー としての一体感と外部とのギャップ

AI普及による業界動向と心構え

Stephen O’Gradyの分析 ：AIはソフトウェア開発の民主化を推進
Grady Boochの見解 ：「AIは歴史的な抽象化の一歩」、冷静な受け止めを推奨
AIの不可逆性 と、メリット最大化・コスト最小化への取り組みの必要性

コードヘルスとAIフレンドリー開発

Adam Tornhillの研究 ：「AIフレンドリー」なコードはリファクタリング成功率が高い
5,000プログラム・6種LLMでの大規模実験
ヘルシーなコードベース ではAIのパフォーマンスが向上
レガシーコードでのリスク増加、非線形な関係性が示唆

TDDとLLM活用の実践知

TDD（テスト駆動開発）の価値 をLLM活用現場で再認識
明確なテストとTDDサイクル がLLM活用の成功要因
最先端ユーザーからもTDD推奨の声 が多数

Hackerたちの意見

HNのタイトルはTFAの内容を反映してない気がするな。リンク先の記事[0]の方が合ってると思う。でも、ファウラーの記事は面白いよね。「すべてのコードは技術的負債だ」という考え方、いいと思うし、必要以上に増やすべきじゃないよね。ただ、負債自体が悪いわけじゃないことも忘れちゃいけない。住宅ローンで家を買うのも負債だけど、いろんな理由で良い選択になることもあるしね。 [0]: https://thenewstack.io/ai-velocity-debt-accelerator/

└

ここで紹介されてる「認知的負債」のアイデア、好きだな。特に「理解なしの速度は持続可能ではない」というフレーズが響く。

└

うん、あの編集されたタイトルはこの投稿には全然合ってない。問題は、実際のタイトルが「Fragments: February 18」っていうのもここには合わないってこと。だから、「Thoughtworksのソフトウェア開発の未来リトリートからの小ネタ」みたいな感じにしたらどうかな？（最初の文から取ったら、内容をうまく捉えてると思う。）

└

技術的負債って名前、全然間違ってるよ。「技術的負債」は負債というよりも株式に近い感じ。プロジェクトがうまくいかなければ、その「技術的負債」は問題にならなくなるし。

└

個人的にはそう思わないけど、混乱を避けるためにタイトルを変更したよ。

あの編集されたタイトル、なんなの？実際はThoughtworksのソフトウェア開発の未来に関するリトリートについての文章なんだけど。

└

私の意見では、そうは思わないけど、混乱を避けるためにタイトルを変えたよ。

LLMは専門的なスキルを食いつぶしている。LLM駆動のスキルがプラットフォームの使い方の詳細よりも重要になってくるから、専門のフロントエンドやバックエンド開発者の需要は減るだろうね。これがエキスパート・ジェネラリストの役割の認識を高めることにつながるのか？それとも、LLMがたくさんのコードを書く能力が、サイロを排除するんじゃなくて、周りをコードで囲むことになるのか？今のところ、これが一番面白い質問だと思う。LLMのおかげで、フロントエンド開発やオペレーション、自動化、UIデザインなんかで、もっと大きな挑戦を受け入れられるようになった。これが他の人にも上手くいけば、私たちの職業の形はどうなるんだろう？

└

自分も同じようになってきた。独自の実装に特化する代わりに、すべてをもっと完全に計画して、業界基準や他の開発者のベストプラクティスに基づいたスキルを書いている（もちろん、たくさんのアンチパターンも含めてね）。それ以来、作業フローは劇的に改善されたけど、これらの実装を適切にデバッグするスキルが育っていないんじゃないかと心配してる。スキルがほとんどの作業をやってくれたからね。

└

自分も同じような経験があるけど、結論は逆だな。過去6ヶ月間、俺のコードはすべてClaude CodeとGemini CLIで書かれてる。バックエンド、フロントエンド、インフラ、iOSのコードも書いたよ。キャリアの流れを考えると、数年前にはこれが不可能だった。だけど、技術的負債はすごく大きい。正直に言うと、これらの技術に対する理解は「専門家」レベルじゃない。経験豊富な開発者が俺のコードを見たら、ひどいもので再アーキテクチャが必要だと思うだろうね。動いてるから良いけど（それは素晴らしい！）、ソフトウェアエンジニアリングの面ではまだまだ足りない。

└

コードは急速に商品化していると思う。以前は、コード自体が価値のあるもので、MicrosoftのMS-DOSとIBMのPCハードウェアのような関係だった。それが長い間続いていた。FOSSのおかげで、再利用可能なコンポーネントを使うコストはほぼゼロになった。大規模なパブリッククラウドは、コードを実行するコストがほとんど無視できるほどになった。そして今、モデルプロバイダー（Anthropic、Google、OpenAI）のおかげで、コードを生産するコストは比較的小さい。コードの生産コストがほぼゼロに近づくと、周りのすべてを最適化し始める。今やコードは鋼鉄のような存在だ。自体としては少し価値があるけど、もう町の鍛冶屋に物を作ってもらう必要はない。まだ価値があるのは、何を作るべきか、いつ作るべきかを知る直感。それが我々の職業に残された「何か」なんだ。

└

それってただ階層が一つ上がっただけじゃない？10年前にはほとんどの開発者が機械語でコーディングすることを忘れてた。だって、知ってる必要がなかったからね。今は、ただ一段階上に進んでるだけだよ。

Hacker Newsで議論の続きを見る

ハクソク