AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される

デブサミ関西2026に行ってきた。
AI全振りの開発現場では「コードを手書かない時代」のエンジニアの真価が問われている。
実装コストがゼロとなった今、求められるのは単なる作業者ではなく、システム全体の説明責任を負うアーキテクトの思考だ。
全レイヤーを統括し、AIを使いこなすITエンジニアは皆、アーキテクトであるべきだ。

【参考】
Developers Summit 2026 KANSAI（2026.08.21）

AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi: プログラマの思索

【1】デブサミ関西2026に行ってきて、SIerの人は皆AIに全振りだなあと思った。
もはや、プログラムを手書きで書く人はいない。
ジュニアもシニアも皆、AIにプログラムを書かせる。
AIの方がプログラミングが楽だからだ。

すると、AI時代のソフトウェア開発者は、プログラマではない。
では、プログラマはAIに指示するだけのオペレータに過ぎないのか？
プログラマは、AIが作ったソースコードを読む必要はないのか？

【2】僕の考えでは、AI時代のソフトウェア開発では、エンジニアは皆アーキテクトを求められることだ。

つまり、AIでプログラミングのコストがゼロになったら、ITエンジニアは皆アーキテクトの 技術レベルを求められる。

なぜならば、WebサーバーもネットワークもRDBも開発フレームワークもアーキテクチャ設計もフロントエンドもコンテナも業務ドメインも全てAIで即座に実装して動作できるからだ。
中身はブラックボックスでもいい。

【2-1】つまり、ITエンジニアは、インフラ設計・DB設計・アーキテクチャ設計・詳細設計・業務設計・要件定義も全て自力で設計して、全てのコンポーネントや技術を組み合わせて一つのシステムを作らざるを得なくなるからだ。
全ての設計要素の整合性、品質担保は、ITエンジニアしかできない。
すべての技術を理解して、部品のように組み立てて、きちんと動かす能力が求められる。
そのような役割こそがアーキテクトだ。
低レイヤーからフロントエンドまでのIT技術を全て知り尽くして、顧客の要望に対して、最適なアーキテクチャ、すなわち、最適な設計コンポーネントを選択して実装して運用できる人は、アーキテクトしかいない。

たとえ、ジュニアのプログラマが大規模かつ複雑なシステムを開発できたとしても、顧客から、なぜこんな仕組みのシステムを作ったのか？と問われた時に、システムの中身に対する説明責任は必ず要求される。
システムそのもの説明責任の主体は、AIではなく、AIを実装したプログラマであるべきだ。

【2-2】アーキテクトとは、単にシステム構成に関するアーキテクチャを意思決定するだけでなく、意思決定した説明責任も負うからだ。
AIが作ったシステムの中身は分かりません、と顧客に言ってしまうプログラマは、正直最低だ。
自分は責任が持てません、自分は何も知らないから、と、自分の能力が無い事実をさらけ出しているだけだ。
自分の無能さを顧客の前にさらけ出して、恥ずかしくないのだろうか？

よって、ジュニアのエンジニアも、顧客の前ではアーキテクトとして振る舞うべきだ。
それができないならば、彼は顧客の前に立たない方が良い。

【3】デブサミ関西に行ってきて感じたことは、インターネット老人会のようなおじさん達がすごく生き生きとしていたことだ。
AIによりプログラミングの実装コストがゼロになったことで、リファクタリングやバックポートなどのような地道な作業から解放されて、本来のやりたいことを実現しやすくなったように思える。

サーバーやネットワーク、CPUアーキテクチャやC言語のポインタ、Linuxカーネル等のレベルの知識があるからこそ、彼らは最適なアーキテクチャ構成を考えることが出来る。
その後の開発作業、具体的には、多数の部品やインフラ基盤、開発基盤を組み合わせて協調動作させる開発作業は全てAIに任せれば、即座に実装できる。
インターネット老人会のような経験者にとっては、すごく楽しい時代になったんだろうな、と思う。

「理論より実装」——機械学習の本質はサイエンスではなく工学だ

機械学習、深層学習は、コンピュータサイエンスによる研究よりも、性能チューニングとコストのトレードオフを考慮するエンジニアリング対象ではないか、という指摘にしびれた。

XユーザーのPedro Domingosさん: 「Machine learning is the study of techniques that don’t work in theory but do in practice.」 / X

英語からの翻訳：
機械学習とは、理論上は機能しないが実践上は機能する技術の研究です。

XユーザーのTJOさん: 「LLMがすっかりサイエンスではなくエンジニアリングの研究になったことを見れば良く分かる」 / X

XユーザーのFrancisco Soaresさん: 「@TJO_datasci 割と最初からそうじゃない？Transformers やDPO辺りが新しいかもしれないけど、9割くらいはDLとRLの応用とスケーラビリティ問題。だからすごくないっていうわけじゃないけど、この界隈の論文をここ数年読んでるとエンジニアとして面白さをとても感じると同時にサイエンスとしてすごく浅く感じる。」 / X

サイエンティストは、コストや納期の妥当性は考えずに、ひたすら理論上の可能性を考える。
あるべき論を突き進んで考える。
それはそれで楽しい。

一方、工学の対象は、基本はQCDのトレードオフの中で、最もバランスとの取れた実装手段を見つけることにある。
それこそが、エンジニアとしての最骨頂だ。
エンジニアとしては、工学の対象の方が面白いと思う。
エンジニアは結局、Howを考える人だ。
Howを突き詰めて考えるのが好きだ。
そして、Howこそが実際の世界を変える。
Howの試行錯誤が世界を変えるからだ。

「Why（理論）」を追うサイエンティストと、「How（実装）」で世界を変えるエンジニア。
泥臭いHowの試行錯誤こそが世界を変える。だからエンジニアリングは面白い。

資料リンク「10周回って、エージェント開発は RAGがすべてだった。～RAGの歴史と開発現場で見えた実践知～」

「10周回って、エージェント開発は RAGがすべてだった。～RAGの歴史と開発現場で見えた実践知～」資料リンクを書いておく。
LLMとRAGの関係が分かりやすい。

AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi

デブサミ関西2026に参加してきた。
デブサミ関西2026で踊る「AIによる自動化」や「FDE」の波。一見スマートな潮流に違和感を覚えたのはなぜか？
AI時代のプログラミングの本質、ITビジネスの構造、そして20年続くコミュニティの絆から、エンジニアが手放してはならない「思考の領域」と真の資産を考えてみた。
感想をラフなメモ書き。

Developers Summit 2026 KANSAI（2026.08.21）

【1】講演者の大半は、AIで手作業のプログラミングはなくなる、価値創造にフォーカスを当てるべきだ、エンジニアもビジネスにシフトしようと言っているが、むしろ、僕は、AIが普及しても人間によるプログラミング、アーキテクチャ設計は変わらないと思う。

確かに、AIによるプログラミングの方が人間の手作業によるプログラミングよりも高速で品質も一定だ。
人間のプログラミングは、漏れが多く、考慮する範囲やレベルも一般的に低い。
しかし、そんな状況でも、AIよりも人間のプログラミングが重要な点は2つある。

1つ目は、AIのプログラミングは、無駄にたくさんの機能を作り、無駄にたくさんの仕様を盛り込みすぎて、品質基準を超過しすぎる。
人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる: プログラマの思索
AIは高速かつ品質基準もクリアできるために、無駄に作った機能がないか、変な方向に機能作り込みしていないか、人間がコードレビューしている感じだ。
つまり、人間もAIが作ったコードを読んで理解する必要があるので、プログラミング力が不要になることはない。

2つ目は、ソフトウェのあるべき姿を考える時に、人間もプログラムという肝心の部品を理解する必要があるからだ。
AIは高速かつ品質基準もクリアできるツールなので、極端に言えば、システム中身のソフトウェアもアーキテクチャも、ブラックボックスでいい。
つまり、プログラミングやアーキテクチャも知らなくても、テスト駆動開発で仕様を満たせれば、中身のソフトウェアが汚くても無関係だ。
なぜならば、AIでいつでも作り直せるならば、いくら大規模なシステムでも、プロトタイプを作る感覚で、何度でもリプレースしてしまえばいい。
アーキテクチャもプロトタイピングの都度、極論、何度でも大幅変更しても、AIで対応できてしまうからだ。
大規模システムを今日はJavaで作った、明日はC#で作り直した、明後日はRubyで作り直した、1週間後にはRustで全部作り直した、というやり方も、AIなら問題なく可能だ。
AIなら、じきに品質保証という監査プロセスそのものもAIで自動化できるだろう。

AIによるプログラミングは、20年前に流行したモデル駆動開発やノーコード開発と同じだ。
プログラミングを知らなくても、GUIの設計だけでプログラムを自動生成すればいいという考え方だ。
今でも、SalesforceやKintoneによるローコード開発も似たような発想だ。

Xユーザーのakipiiさん: 「AIでプログラミング代替により、プログラムは使い捨てになる。あるいは昔のノーコード開発になる。本当にそれがあるべき姿なのか？僕は違うと思う。 #devsumi」 / X

モデル駆動開発、ノーコード開発、ローコード開発であれば、アーキテクチャを考える必要性はない。
すでにアーキテクチャが存在している前提で、アプリ層のビジネスロジックを実装するだけ、という発想だからだ。

しかし、それが本当のソフトウェア開発なのだろうか？
ソフトウェア開発にアーキテクチャなんて無視して、ビジネス要件さえ満たしていれば、中身はブラックボックスでよくて、QAなんか無関係で、ソフトウェア工学も品質保証も無関係でいいのだろうか？

僕は違うと思う。
AIがこれだけ高速かつ高い能力を持ったとしても、ソフトウェアのあるべき姿を思考する行為そのものは自分の範疇に納めたい。
AIが本当に良いソフトエアを作ってくれるのか、その仕組は理解したい。
AI自体の思考プロセスを理解したい。
アーキテクチャを自分が指定して、AIに指示させたい。

上記の理由は中途半端だけど、思考プロセスそのものをAIに手渡したくないのだ。

【2】FDE（Forward Deployed Engineer）はパランティアのエンジニアのモデルから生まれたらしい。
FDEは、ソフトウェア派遣委託のSESと同じだと思う。

Xユーザーのakipiiさん: 「#devsumi FDE（Forward Deployed Engineer）はパランティアテクノロジーズのビジネスモデルから生まれた、とスピーカーから聞いた。それなら理解しやすい。」 / X

FDE（Forward Deployed Engineer：前線配備エンジニア）とは、顧客企業の現場（最前線）に直接入り込み、自社プロダクトやAI技術を用いて、課題の発見からシステムの迅速な実装・運用改善までを一気通貫で担う職種だ。
確かに、従来のSEのように、顧客先に常駐して、顧客の要望に従って、WF型開発に沿って受託開発するわけではない。

しかし、外側から見れば、客先に常駐して、顧客の要望を収集したうえでプログラミングしてシステム開発スタイルは変わらない。
従来のSESであれば、顧客から指定されたアーキテクチャやWF型開発プロセスに従ってプログラミングするだろう。
一方、FDEは、自社のフレームワーク、特にパランティアのようなオントロジーのフレームワークの上でシステム開発して高速に開発サイクルを回し、顧客に確認しながらシステムを順次提供していくだけだ。
つまり、SESとFDEの違いは、ソフトウェア開発の基盤が違うだけで、ビジネスモデルは全く同じだと思う。

せいぜい、SESは準委任契約だろうが、FEDは成果連動の契約つまり請負契約に近い契約なので、その点は違うだろう。

【3】では、僕がなぜ、FDEはSESみたいだね、ビジネスモデルも契約形態もそんなに変わらないと思う理由は何なのか？
理由は、マッキンゼー、デロイト、アクセンチュアなどの大手ITコンサルタントであっても、彼らも客先常駐ないし客先と準委任契約中心の高級派遣業であって、SESの契約形態と本質的に変わらないと思うためだ。

SESはWF型開発従った受託開発のビジネスモデルだ。
いわゆる人月ビジネスであり、従来から凄く批判されている。

一方、アクセンチュアのようなITコンサルタントも、SESから高級派遣業にアップグレードしたに過ぎない。
どれだけのコンサル人数を入れて、売上を増やしていくか、というビジネスモデルだ。

FDEも客先常駐のスタイルは変わらない。
ただし、客先指定のオレオレ開発基盤の受託開発から、AIによる自社オントロジー開発基盤の受託開発に変わっただけだから。

【4】デブサミ関西に久しぶりに出たら、10年以上前に関西アジャイル開発コミュニティで一緒に活動していた仲間からたくさん声掛けしてもらって、まるでOB会みたいな感情が沸き起こった。
以前の会社の職場にいた同僚や上司も昇進していたし、その他の仲間も職場を変えても皆活発に活動されていた。

年数が経っても、昔は一緒に苦労したね、昔も楽しかったね、今も一緒にやろう、みたいに言える雰囲気があるのは楽しい。

会社に所属する期間は所詮65歳定年までであって、会社から離れると、守秘義務などもあるので基本的に関係はなくなる。
しかし、コミュニティ活動で一緒に苦労し何かを達成した仲間は、いくら転職しても、フリーランスで働いても、無職になっても、長年一緒に経験した人間関係は一生残る。

プライベートな人間関係につながるからこそ、ビジネスを超えた環境であっても、その人の人柄や能力、人格が優れていれば、自然に人は集まる。
人間関係は細く長く続けることで、その偉大さを20年後に初めて感じるわけだ。

今後も色々やっていきたいと思う。

人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる

「人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる」という言葉に惹かれた。
アイデアをラフなメモ書き。

【参考】
チケット駆動でAIを制御する仕組みのアイデア: プログラマの思索

AIエージェントのハルシネーションは「チケット駆動」で防ぐ～次世代アジャイル開発の実践論: プログラマの思索

TkDD: Ticket-Driven Development and the Knowledge We’re Throwing Away

AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita

AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita

ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita

【1】AIによるソフトウェア開発はもはや当たり前と思う。
しかし、AIが生成したプログラムに対し、テスト駆動開発や仕様駆動開発だけの品質保証だけでは物足りないのでは？と個人的に考えている。

案件のコンテキスト、その人個人が持つコンテキスト、既成組織が今までに築いてきた組織文化（ドキュメント化されていないノウハウ）無しで、AIがソフトウェア開発できるか？

実際、「人間が作ったプログラムは品質基準に対し不足する要素が多すぎるが、AIが作ったプログラムは余計なものをたくさん作りすぎる。AIは品質基準を超過しすぎる」傾向がある。
@takaiよりこの言葉を聞いて、思わずなるほど、と思った。

つまり、AIによるプログラミングの速度が速すぎるために、AIは、人間が用意したスコープ以上の成果物をたくさん作り出してしまう。
AIは無駄な機能をたくさん作ってしまう。

そこで、AIが生成したプログラムに対して、テスト駆動開発や仕様駆動開発で、品質を担保しようとする。
しかし、AIはテストプログラムもすぐに作れてしまう。
つまり、AIはたくさん作った無駄な機能に対しても、テストプログラムを作って、いくらでもきちんと動くものを作ってくれる。

本来は、人間がこれだけのスコープでいいよ、と前提条件や制約条件をたくさんプロンプトに書き込んでやらないといけない。
AIはこれ以上無駄な機能を作るな。
AIは、人間が指定した前提条件の範囲内で機能を作れ、と。

しかし、この前提条件をすべて書き出すのは難しい。
自分の頭の中にあるやりたいことは曖昧だ。イメージしかない。
案件特有のコンテキストは、たくさんのドキュメントの行間に埋もれている。
既成組織が今までに積み上げてきた標準プロセスは、過去のたくさんの障害やレビュー、プロセス改善の経緯を踏まえて、たくさんの改訂を反映して、作られてきている。
そんな過去の経緯までAIは知らない。

また、今は、AIが暴走して無駄な機能を作らないように、人間がコードレビューやゲートレビューを各工程でガードを掛けている方針が各チームでやっている。
たとえば、CodexやClaudeCodeでは、skills.mdにたくさんの手順を入れ込んだり、AIの中間成果物を途中でコードレビューしているだろう。
だから、今は、プログラミングしているよりも、コードレビューばかりやっている人が多いだろう。
むしろ、AIによるプログラミングの速度が速すぎるために、人間のコードレビューがボトルネックになっているわけだ。

【2】そこで、AIの暴走を防ぐために、チケット駆動で制御する発想は良いと考える。
AIにローカルなコンテキストを読み込ませるために、GitHubのIssueに「AIへの作業指示書」「AIとやり取りした意思決定の履歴」「AIとやり取りして試行錯誤した履歴」を残すやり方は、一つの解決策ではないかと考える。

@tokudiroのアイデアがそうだ。

AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita

AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita

ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita

【3】@tokudiroのアイデアを僕なりに理解した内容が下記になる。

ai-and-github-and-ticket-driven-developmentfrom akipii ogaoga

【4】「AIの暴走をチケット駆動で制御する」アイデアは、世界中で皆考えているようだ。
下記記事では「チケット駆動開発」を「TkDD」と呼んでいる。
Ticket Driven Developmentの略だ。

下記記事の文中にある「AIに欠けているものは思考プロセスとその変化」という言葉が心に引っかかった。

TkDD: Ticket-Driven Development and the Knowledge We’re Throwing Away

【5】このアイデアをもっと試してみたいと思う。

「System of Systems（SoS）の統合テストは不可能だ」という言説を聞いた

【1】「System of Systems（SoS）の統合テストは不可能だ」という言説を聞いた。

Geminiに聞いたら、こんな回答だった。
結論から言えば、この主張は半分正解であり、半分は言葉足らずです。
正確には、「従来の単一システムで行っていたような、全状態をコントロールし、網羅的かつ決定論的な（結果が必ず一致する）統合テストを行うことは、原理的・実務的に不可能である」というのが真意です。

この話は真理を突いていると思う。

複数システムを組み合わせた全体に対し、統合テストで検証し品質担保できるならば、それは一つのシステムになりうるが、System of Systems の定義に反するので、システムになり得ない。
だから、System of Systemsアーキテクチャでは、複数システムを組み合わせた全体はシステムになり得ず、中途半端な状態にある。
つまり、System of Systems アーキテクチャの品質保証は完全にできない。

実際、各要素である個別システムは単体テスト～システムテストまで全て可能だが、全ての要素であるシステムを組み合わせたテストを検討してみると、本番環境だけでしかテストできないユースケースが多々出てくる。
つまり、本番環境でないテスト環境にて、いくらテストしても、確認できない機能や非機能要件が出てくる場合がある。

特に障害テストが多いように感じる。

【2】よって、複数システムを繋げた全体の品質保証範囲やレベルの上限をどこまで広げられるか、にアーキテクトは知恵を絞ってるわけだ。
つまり、本番環境でしか実際に実行しなければ確認できない機能要件、非機能要件がある前提で、それ以外はテスト環境でできるだけテストして、機能要件も非機能要件も網羅してしまおうという戦略を取ることになるだろう。

【3】「System of Systems（SoS）の統合テストは不可能だ」という前提で、SoSの品質保証するアーキテクトは誰になるのか？
発注者側なのか？
受託者側なのか？

SoSでは全ての品質基準を網羅できない。
よって、SoSのアーキテクトは非常に高度な意思決定と高度な知見を要求される。

契約上は、発注者側になる。
発注者は、各要素の個別システムを各メーカーや各SIerへ開発を受託し、納品してもらうことになる。
それら納品された各システムをつなげて、全体のシステム（SoS）を構成し、一つのモノリシックシステムを完成させたい。
しかし、発注者側のアーキテクトは、SoSは統合テストできない前提を承知したうえで、モノリシックシステムを、品質基準を満たしたうえで動作できるのか？

しかし、賢い発注者なら、受託者側にSoSの品質保証を押し付けるだろう。
賢い発注者であれば、SoSのリスクをできるだけ受託者側に押し付けることで、品質やコストを抑えたいだろう。
よって、発注者は、受託者側に各システムだけでなく、システム全体の統合の責任も契約に入れて、責任を押し付けたい。

すると、受託者は、SoSは統合できない前提のうえで、どこまで品質担保できるのだろうか？
賢い受託者であれば、契約に潜むリスクを見極めたうえで、SoSの品質保証の範囲やレベルを明確に定義して、契約に盛り込んで、発注者と握りたいだろう。
そうでなければ、リスクを全て受託者側に引き受けてしまう罠に陥ってしまうからだ。

【4】SoSの例としては、航空管制システムや自動運転車を含む交通システム、ミサイル発射システムなどの防衛システムなどがあげられるだろう。
それぞれのシステムには、要素となる製品やシステムがあるが、それらを組み合わせて一つのモノリシックシステムを作りたい。
しかし、上記の通り「System of Systems（SoS）の統合テストは不可能だ」。
SoSの品質保証は非常に難しい性質を持つ。
実際にどうやってSoSの品質を担保するのか、思考してみたい。

チケット駆動でAIを制御する仕組みのアイデア

AI開発が常識化した今、AIの「暴走」とローカルな文脈理解の欠如がソフトウェア開発現場の障壁だ。
本稿では、AIのハルシネーションを物理的に封じ込める最適解「チケット駆動」の実践論を考えてみた。
IssueをAIへの作業指示書とし、Markdownで文脈を制御する次世代アジャイルの真髄と、AIスクラム適用の限界に迫ってみた。

【参考】
AIエージェントのハルシネーションは「チケット駆動」で防ぐ～次世代アジャイル開発の実践論: プログラマの思索

AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita

AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita

ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita

ai-and-github-and-ticket-driven-developmentfrom akipii ogaoga

【1】2026年現在、プログラミングは全てAIに任せて開発するのが当たり前だろう。
もはや手作業のプログラミングは、伝統工芸と同じレベルに落ちた。
わざわざプログラミングを手作業で一つずつ書くのは、時間もかかるし、品質も不安だ。
むしろAIにやらせた方が楽だ。

しかし、設計、コーディング、テスト、ビルド、デプロイのすべての作業をAIに任せたとしても、人間の作業がなくなるわけではない。
むしろ、AIは暴走しやすいので、いかにAIをコントロールすべきか、に皆頭を使っているのではないだろうか。

【2】では、「AIによるプログラミング自動化」の問題点は何だろうか？

僕は3つあると思う。
1つ目は、AIはその人だけのコンテキスト、案件特有のコンテキスト、チームや組織の文化に根ざしたコンテキストがとても弱い。
2つ目は、AIは汎用的な知識だけで、私たちの意図を超えた範囲まで、勝手に機能実装したり、成果物を改変してくる。
つまり、AIは余計なお世話が多い。
3つ目は、AIはWordやPDFなどのドキュメント類をいきなり出力させると、意図しないレイアウトや思い通りでない内容が出る場合がある。
これもAIが余計なお世話を焼きすぎる。

【3】「AIはその人だけのコンテキスト、案件特有のコンテキスト、チームや組織の文化に根ざしたコンテキストがとても弱い」問題は、昔からずっと言われているAIの弱点だ。
たぶん、AIのコンテキストバッファは限定されていて、AIにローカルなコンテキストを保持させるにはコンテキストバッファは小さすぎる。

では、どうやって問題解消すべきか？
解決策の一つは、プロンプトを作業指示とみなし、GitHubのIssueに作業指示書として書く。
AIはIssueを前提条件かつ作業指示書とみなして実行してくれる。

@tokudiroによれば、プロダクトバックログを作って、AIにPBLに従ってプログラミングさせるやり方は上手くいくらしい。
しかし、PBL自身をテキストファイルで管理し、GitHubで管理するのは面倒だったらしい。
そこで、PBLに書いた製品の要件を全てGitHubのIssueに書き出して、PBLの優先順位をIssueの優先順に対応付けると上手くいったらしい。

理由は、作業指示書のIssueがたくさん存在し、Issueに基づいてコミットした履歴がIssueと紐づくことで、ノウハウやナレッジがAIにも蓄積されるからだろう。
つまり、Issueに従ったAIによるコミットは、AI自身がローカルなコンテキストを蓄積出来ていることを意味するのだろう。
すなわち、蓄積されたIssueとIssueに紐づくコミット履歴は、AI自身のノウハウ、ナレッジになるのだろう。

この解決策の良い点は、Issueにナレッジを貯める意識がなくても、PBLに沿ったIssue一覧とIssue実行履歴により、自然にAI自身にナレッジやノウハウが溜まることだろう。
結局、AI自身に経験主義を実践させて、ローカルなコンテキストを認識させているわけだ。

別の解決策は、AIとチャットしながら、試行錯誤したり、意思決定して何かを選択した履歴は、Issueコメントにすべて残す。
たとえば、AIに相談して、プログラミングの選択肢を3つ挙げさせた。
3つの選択肢のうち、1つを選んで、AIにIssueを書かせて実行させる。
その選択肢を実行させて、結果を見て、やはりこの選択肢は止める、という履歴もIssueコメントに残す。

@tokudiroによれば、AIとのチャットを別のチャット画面でやり取りさせるならば、Issueコメントに全て書き残せばいいと思いついたらしい。
Issueコメントに意思決定の履歴、試行錯誤の履歴も全て残せば、ローカルなコンテキストは全てIssueに集約される。
AIには、過去のIssueを全部読んでおけ、と言えば、ローカルなコンテキストを理解してくれる。

この解決策の良い点は、Issueコメントはmarkdownで書けるので、AIと相性がいい。
また、Issueコメントもmarkdownで書いた方が人間も読みやすい。
さらに、AIとのやり取りが複雑になれば、Issueを分割して、新規Issueに新たな作業指示書を書けばいい。

つまり、AIにローカルなコンテキストを理解させるために、Issueに作業指示書、ならびに、意思決定や試行錯誤などの履歴も集約させて、AIにIssueを読み込ませるわけだ。
GitHubならば、ソースコードの全てが存在し、コミット履歴もすべて残っているので、AIに案件特有のコンテキストもGitHubリポジトリそのものを読み込ませればいい。

すなわち、AIに読み込ませるローカルなコンテキストは、GitHubというIssueTrackingSystemそのものなわけだ。

【4】「AIは汎用的な知識だけで、私たちの意図を超えた範囲まで、勝手に機能実装したり、成果物を改変してくる」問題は、AIは先走りすぎて暴走してしまう弱点だ。

解決策は、上記の通り、プロンプトではなく、Issueを作業指示書としてAIに実行させることだ。
AIにガードレールを課すことと、IssueをAIの作業指示書として扱うことは同義だ。

【5】「AIはWordやPDFなどのドキュメント類をいきなり出力させると、意図しないレイアウトや思い通りでない内容が出る場合がある」問題は、ソースコードだけでなく、ドキュメント類もAIで自動化させたいのに上手く制御できない点にある。

単純なアイデアは、GitHubリポジトリのソースコードから、ユーザマニュアルをPDF出力せよ、とAIに直接指示させることだが、そのやり方では上手くいかなかった、と@tokujiroは言う。
やはり、ドキュメントの粒度や整合性、フォーマットなどをAIに指定しないと、AIは勝手に作ってしまう。

そこで、AIにまず、ユーザマニュアルや設計書に相当するテキストをmarkdownで出力させる。
ユーザマニュアルや設計書に相当するmarkdownファイルをインプットとして、AIやPandocでPDFやWordに出力するやり方を取る。

@tokudiroによれば、AIとmarkdownは相性が良いので、中間成果物としてmarkdownを出力させるのが良いらしい。
この意見は僕も同意する。
AIはテキストに強い。
特にAIはmarkdownに強い。
だから、まずドキュメント類そのものをテキスト出力し、フォーマットも別のmarkdownで指定して、AIに実行させる方がいいだろう。

【6】AIでプログラミングがいくら効率化されて自動化出来たとしても、人間によるコードレビューは必要だ。
@tokudiroと話していて気づいた点は、品質基準は人間だけが持っている。
AIに品質基準を持たせたとしても、最終的な品質基準は人間だけが最終決定するからだ。
つまり、人間がAIが生成したコードをゲートレビューしている状況と同じだ。

その時、人間によるAI生成済みソースコードのコードレビューはどうやるといいのか？
ここでも、AI自身にGitHubからDiff出力させて、そのDiffを人間がチェックする方法が良いだろう。

Diff自体もテキストなのでAIも扱いやすい。
人間にとっても、ソースコード全体は読めないが、Diffならば読みやすくなる。

今は、人間がプログラミングしなくなっても、大量のコードレビューが必要であり、コードレビューに時間がかかってボトルネックになっている状況だ。
結局、人間自身がボトルネックになっているわけだ。

【7】上記が「チケット駆動でAIを制御する仕組みのアイデア」だ。
ここから次の問題が思いつく。
「AIは監査プロセスを実装し実現できるのか？」
「AIはScrumプロセスを実装し実現できるのか？」

現代のソフトウェア開発では、Scrumでプロセスを回すのが主流だ。
すると、当然AIにScrumを回したくなる。
たとえば、開発チームの開発メンバーを複数のAIエージェントに任せてプログラミングさせて、スクラムマスターもAIに任せてスクラムチーム内の障害解決を担当させることができるだろう。
プロダクトオーナーさえも、PBLの元ネタとなる要求を渡せば、AIに任せられるだろう。

スクラムガイドをAIに事前に読み込ませれば、プロセスも役割もイベントも成果物もAIは理解するだろう。
では、本当にそれだけで、AI自身がScrumというプロセスを回せるのだろうか？

同様に、たとえば、ISO9001、A-SPICE、機能安全、サイバーセキュリティなどの規格に沿ったシステム監査がある。
これらの規格は、膨大なドキュメントとして手順、ワークフローシステム、制約条件などが細かく定義されている。
これらの規格のドキュメントをインプットにすれば、AIは一連のプロセスを理解するだろう。

では、本当にそれだけで、AI自身が規格に沿った監査プロセスを回せるのだろうか？

直感的には僕は疑問に感じる。
たったそれだけでAIが上手くいくならば、既に色んな人が試して、運用されている事例が出てくるだろう。
しかし、今時点ではそんな成功事例を聞かない。

なぜならば、AIはローカルなコンテキストに弱いからだ。
AIの暴走をチケット駆動で制御するアイデアは、IssueTrackingSystemに、人間とAIが相互会話した履歴を残し、Issueを作業指示書としてAIにガードレールを課すことで、AIを制御できる点にある。
この発想を、AIへScrumの適用、AIへ監査プロセスの適用を当てはめなければ、上手くいなかいだろうと直感する。

アジャイル開発を強化するキルチェーン進化の歴史～VUCA時代におけるモノづくりの新アーキテクチャ

「アジャイル開発を強化するキルチェーン進化の歴史～VUCA時代におけるモノづくりの新アーキテクチャ」を講演してきた。
発表資料を公開しておく。

lecture-for-the-osaka-university-professional-engineers-association_ogawa_20260802-pdffrom akipii ogaoga

脱PDCA！DXを加速する超高速戦略「KillChain」: プログラマの思索

アジャイル開発の概念は、割と軍事と密接に関係する時が多い。
Scrumの創始者ジェフサザランドは、ベトナム戦争に従軍した戦闘機パイロットだったと聞く。
OODAは、PDCAのアンチテーゼとしてアジャイル開発の文脈で語られている。

KillChainという考え方もアジャイル開発の文脈で使われていくだろうか？

脱PDCA！DXを加速する超高速戦略「KillChain」

DX推進にPDCAはもう遅い。
計画偏重のループでは激しい市場の変化に勝てないからだ。
いま不可欠なのは、事象の発見と同時に発火し、超高速で目標達成へ一直線に駆け抜ける「KillChain」である。
OODAを意思決定エンジンに据えた次世代の戦略プロセスを考えてみる。

【0】KillChainとは、攻撃目標の発見から目的達成（破壊や情報窃取など）に至るまでのプロセスを、直線的な「鎖（チェーン）」に見立てて構造化したモデルだ。
Find→Fix→Track→Target→Engage→Assessから成る。

元は軍事用語だが、現在はサイバーセキュリティ分野で攻撃者の行動段階（偵察、武器化、配送、攻撃など）を分解するフレームワークとして普及している

最大の特徴は、「一連のプロセスのうち、どこか1つの鎖（手順）を断ち切れば、最終的な目的達成を阻止できる」という点にある。
プロセスが直線的であるため、防御側はいずれかの段階で介入・遮断することで、全体を無効化（キル）することが可能になる。

【1】KillChainを計画・実行・評価プロセスとみなしたとする。
KillChainとPDCAの違いは何だろうか？　

根本的な違いは、KillChainのような「直線的な目標達成（破壊・制圧）」を目指すか、PDCAのような「循環的な継続的改善」を目指すか、という目的や前提になるだろう。
ここから、KillChainとPDCAの最大の違いとして、サイクルのスピードが全く異なる現象があげられるだろう。

【2】PDCAでは、改善のループ構造を重視する。
「計画通りに進んだか？」「なぜズレたのか？」というプロセス・原因究明ベースの評価が多い。

よって、PDCAでは、計画Pと評価Cに力点を置く。
その分、PDCAサイクルは長くなりやすい。
特に計画駆動になりやすいので、実行Doに辿り着く前に、80％くらいの労力を割くようなイメージになりやすい。

【3】一方、KillChainでは、最終目標に到達するまでの意思決定を重視する。
「目標を達成できたか？」「次はどう攻撃（または防御）するか？」という戦術的・結果ベースの評価が多い。

よって、KillChainでは、実際の行動（実行/Do）と、その瞬間の結果（評価/Check）に力点を置く。
たとえば、目標を速く特定して、追跡し、ターゲットとして定めていち早く撃破する。
そうしなければ、自分がやられるだけだ。

KillChainではループを速く回すことを重視する。
つまり、KillChainサイクルを何度も速く回しながら、攻撃目標を追い詰めていく。

【4】PDCAはWF型開発と相性がいい。
計画偏重で、じっくり計画して、その実行結果の評価に時間をかけて、原因分析と改善活動を行うからだ。

よって、いくらサイクルがループすると言っても、月次、四半期など定められた周期で回る方が向くだろう。
サイクルのスパンが長い。

【5】一方、KillChainはアジャイル開発と相性がいい。
まずは、実行して、その結果を評価して、ノウハウを蓄積して次の改善活動に向かう。
とりあえず手を打ち、ダメなら次という感じ。
経験を重視するタイプだ。

KillChainは、イベント駆動ともいえる。
目標を発見したら、KillChainが動く。
事象が発生した瞬間に発火する。

たとえば、DX戦略ではKillChainが有効だろう。
具体的には、競合のキャンペーンに対するカウンター施策では、競合の動きを発見次第、すぐに対策を練って実行しなければ、市場を失ってしまうリスクがある。
「PDCAを回して対策を練ろう」とすると、そのスピード感のミスマッチによってDX戦略が致命的な遅れになり、その効果を発揮できなくなるだろう。
システム障害対応でも同様だろう。

つまり、KillChainはPDCAよりもスピード重視のプロセスと言えるだろう。

【6】KillChainは、意思決定エンジンとして「OODAループ」と似ている。

KillChain(Find, Fix, Track, Target, Engage, Assess)とOODA（Observe, Orient, Decide, Act）は、どちらも軍事や安全保障を起源とし、不確実で敵対的な環境下で用いられる概念なので非常に似ている。

しかし、KillChainとOODAは視座が違うようだ。
KillChainが「物理的・戦術的な行動のステップ（What/How）」を定義する一方、OODAは「情報を処理し意思決定を下すための認知プロセス（Why/When）」を定義している。

KillChainは、標的を発見してから無力化するまでの一連の「物理的・システム的な手順」だ。
KillChainは工程だ。

一方、OODAは、変化する状況の中で、情報を収集し、判断し、行動に移すまでの「人間の思考と決断のサイクル」だ。
状況に適応し、相手よりも速く最適解を導き出すための意思決定エンジンだ。

端的に言えば、「KillChainという行動計画を、OODAという意思決定エンジンを使って超高速で進める（または敵のKillChainを断ち切る）」という補完関係にある。

【7】また、KillChainとOODAは構造が異なる。

KillChainは、F2E2TAのように直線的だ。
途中の工程が遮断されたり途切れると、チェーンが切断される。
相手側のKillChainをいちはやく前工程で切ることができれば、防御できる。

一方、OODAは、相互作用して循環的に回す。
各フェーズが相互にフィードバックを与え合いながら、常に高速回転し続ける。
OODAの方がPDCAのようなループ構造を持つ。
ただし、OODAはループを速く回すことを重視する
OODAが元々、戦闘機の意思決定に使われている経緯から見ても当たり前だ。

【8】KillChainは速く回すことを重視するが、工程がたくさんあるので、その工程が切れる点が弱点になる。
その点を考えるほうがいいかもしれない。

Redmineのブロッキング機能はどこで使うのか？～FF関係で使うべきだ！

Redmineの真価の1つは「先行・後続」と「ブロッキング」機能にあるのではないか。
PMBOKの依存関係をチケットに適用し、クリティカルパスを可視化すれば、プロジェクト管理の精度は劇的に向上する。
実践的な運用ノウハウと、煩雑な設定を圧倒的に効率化するLycheeプラグインの活用法を解説してみたい。

【1】Redmineのチケット機能がやはり凄いなと思う点はどこにあるのか？
僕が思うに、先行・後続関係と、ブロッキング機能だと思う。

Redmine標準機能には、先行・後続関係と、ブロッキング機能がある。
一般ユーザは使っているだろうか？

【2】PMBOKの進捗管理の授業資料では、クリティカルパスを説明する時に、アクティビティ間の論理的依存関係として4つの種類が使われる。
具体的には、FS、FF、SS、SFだ。

一般に、FS関係がよく使われるだろう。
「Aが終了しないと、Bを開始できない」関係だ。
Redmineでは驚くことに、標準機能に、チケットの先行・後続を関係づけすることができる。
たぶん、関連チケットの機能を発展させた機能の1つとして実装されたのだろう。

チケット間でFS関係が使って、ガントチャート画面上に表示させれば、クリティカルパスが一目で分かる。
実際は、FS関係を元に、最長となるタスクの経路がクリティカルパスになる。
つまり、FS関係は、クリティカルパスの計算や進捗の遅れ（遅延波及）の把握で使われるだろう。
よって、FS関係が一番利用用途が多い。

【3】では、FS以外のFF、SS、SF関係は使っているだろうか？
一般には、ユーザ自身がそれら関係を理解できていないので使えていないと思う。

【4】SS関係は、「Aが開始しないと、Bを開始できない」だ。
具体的には、2つの作業を並行して進める（ファストトラッキング）際によく用いられるだろう。

たとえば、「新業務プロセスの構築（先行）」の開始と同時に、「マニュアル作成（後続）」を開始する。
たとえば、「データベースのデータ移行（先行）」の開始に伴い、並行して「移行データの整合性チェックツール作成（後続）」を開始する。
つまり、タスクを並行稼働させることで、クリティカルパスを短くする手法として使われるだろう。

RedmineにはSS関係は実装されていない。
理由は、チケットの親子関係で解決できるからだ。
具体的には、SS関係にしたい2つのタスクがある場合、「親チケット（Epicや機能）」を作成し、その配下に複数の子チケットを並行（同じ開始日）でぶら下げることで、WBS（Work Breakdown Structure）的に表現可能だ。
つまり、SS関係にある複数のタスクを親チケットの配下にぶらさげれば実装可能だからだ。

【5】FF関係は、「Aが終了しないと、Bを終了できない」だ。

Redmineでは、完全なFF関係は実装されていない。
しかし、SS関係と同様に、親子チケットを使うことで代用できるだろう。
つまり、親チケットの配下にFF関係にある子チケットをぶらさげて、「先行アクティビティが終了して初めて、後続アクティビティも終了できる（着地を合わせる）」関係を作れる。

しかし、実際のチケット管理のシーンでは、「Aが終わらないと、Bを開始できない（FS）」ではなく、「Aが終わらないと、Bを完了できない（FF）」という制約を強制する機能にすべきだろう。
なぜならば、FF関係の制約は単純に終了日を合わせるのが目的ではなく、「Aが終わらないとBもクローズできない」というステータスに依存した機能だからだ。

具体的な実装は下記になる。
ブロック元＝先行タスク＝A
ブロック先＝後続タスク＝B

実際のRedmineのブロック機能が使われるケースはどこだろうか？
具体的には、「並行して作業は進められるが、最終的な着地（クローズ）は先行タスクの完了を待たなければならない」ケースになるだろう。

たとえば、
ブロック元＝旧システムから出力したデータのクレンジング作業
ブロック先＝新システムへのデータインポート作業
としよう。
ブロック先チケット「新システムへのデータインポート作業」は並行で実施できるが、ブロック元チケット「データクレンジング作業」が作業中ステータスであれば、ブロック先チケット「新システムへのデータインポート作業」はクローズできない。
データクレンジング作業が完了できていないのだから、データインポート作業は全て実行できていないからだ。

したがって、FF関係にあるブロック元チケットのステータスを見ることで、ブロック先チケットを勝手に完了ステータスに更新できない制約を課すことができる。

他の例としては、
ブロック元＝新機能の実装
ブロック元＝システムテスト
ブロック先＝リリース判定レビュー
にしてみよう。

炎上案件では既に進捗遅延していて納期が間に合わないリスクがあるので、リリース判定レビュー（ブロック先）の準備をしながら、新機能の実装（ブロック元）、システムテスト（ブロック元）を平行作業しているだろう。
しかし、リリース判定レビュー（ブロック先）を勝手に完了ステータスにできない。
なぜならば、先行タスクである実装、システムテストが終わっていないからだ。
つまり、リリース判定レビューをゲートウェイのように扱う時に、ブロッキング機能を使うととても有効だ。

さらに、
先行＝リリース判定レビュー
後続＝本番環境へのデプロイ作業
の関係をチケットに付けてみよう。

すると、リリース判定レビューの期日が遅れてしまった時、自動的に、デプロイ作業の開始日もずれるような仕組みを作れる。
たとえば、新機能の実装は終わっても、システムテストのバグ修正が収束せず長引いてしまった時、リリース判定レビューも並行作業で実施しても、リリース判定レビューの期日に間に合わず期日を伸ばすしかない。
その分、デプロイ作業の開始日も先行後続関係の制約により、開始日が後ろに倒れる。
このように、チケットの先行後続・ブロッキング機能をうまく使えば、ガントチャートに現実に即した制約を課すことができるだろう。

ただし、ブロッキング機能は、チケットのステータスに注目した機能なので注意点がある。

1つ目は、ブロック先のチケットは並行で作業開始しても、進捗中のままステータスが保留になる。
担当者が作業を99%終わらせて「あとはブロック元が終わるのを待つだけ」という状態になりがちだ。
つまり、90％シンドロームに陥りやすい。

一見するとプロジェクトが順調に進んでいるように見えて、実は完了待ちのチケットが大量に滞留し、最終盤で大きなボトルネックとして顕在化するリスクがある。

2つ目は、チケット間に、先行後続・ブロッキングを複雑に入れ込むと、循環ブロック（デッドロック）が発生してしまうリスクがある。
この辺りは、RDBのデッドロック機能に似ている。

【6】なお、SF関係は、「Aが開始しないと、Bを終了できない」だ。
これは一番利用用途が少ない。
殆ど見かけないので無視していい。

【7】Redmine標準機能である「先行後続」「ブロッキング」機能はとても良く考えられていると思う。
たぶん、これらの機能があれば一般には十分だろう。

しかし、大量のチケットに「先行後続」「ブロッキング」を1個ずつ付けるのは面倒だ。
実際、ブロック元、先行チケットのIDを逐一覚えておく必要が出てくるからだ。

そこで、アジャイルウェア社が出しているLycheeRedmineプラグインを使って、ガントチャート機能を使うと、ガントチャート画面上でマウスでグリグリすれば簡単に先行後続を関係づけれる。
ブロッキング機能も、ガントチャート画面上で右クリックすることで関連付けが簡単にできる。

Lychee Redmine【公式】ガントチャートで進捗管理をラクに｜プロジェクト管理ツール

丁度、MSProject上で、4種類の依存関係をマウスでグリグリできた機能と全く同じだ。

Lycheeガントチャートには便利な機能が盛りだくさんなので、今後も色々使ってみたいと思う。

Lychee-ガントチャートTips集vol.2≫ Lychee Redmine | テクマトリックス

AIエージェントのハルシネーションは「チケット駆動」で防ぐ～次世代アジャイル開発の実践論

AIにスクラム開発を任せるとコンテキストが崩壊し暴走する。
これを防ぐ現実解が、GitとチケットでAIに物理的ガードレールを設ける「チケット駆動開発」だ。
ここではAIの暴走を封じる実践手法から、ユーザーすら代替する次世代パラダイム「Loop Engineering」まで、開発プロセスの未来を紐解いてみる。

【参考】
AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita

AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiita

ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiita

AIエージェントだけでスクラムを回してみた

Context Engineeringの次が来た??Loop Engineering

【1】AIでScrumのようなアジャイル開発プロセスを実装できるのか？

この疑問の意図は、AIがこれだけ進化していると、AIエージェントを人間と同一視することで、AI同士の相互作用により、より大きな効果が見込めるのか？だ。
人間も1人だけよりも、複数人の人格が異なる人達がそれぞれの強みを掛け合わせることで大きな威力を発揮する。
AIエージェント同士の協力関係でも似たような効果が得られるのか？

それは、AIエージェントによる1つの社会実験だ。
人間を使った社会実験は実際は出来ない。
しかし、AIエージェントを使えば、シミュレーションみたいに何度でもやり直しできる。

すると、ソフトウェア開発の文脈では、標準化された開発プロセスに対し、AIエージェントを使ってプロセス実装できるか？という疑問にたどり着く。

【2】AIでScrumプロセスを実装した事例が2つある。
1つは失敗した事例、もう一つは成功した事例だ。

失敗した事例は、ちょっとAIにスクラム開発を任せてみたら破綻した話 #アンチパターン - Qiitaになる。
記事を読む限り、AIはハルシネーションを多発し、自分自身が何をやるべきか混乱している感じだ。
まあ、能力の低い、できない開発チームはこんな感じになりやすい。

上記記事の面白い点は、AIが暴走してしまう点だ。
一人のAIに、プロダクトオーナー、スクラムマスター、開発者の役割切り替えを課すと、AIは混乱してしまった。
先輩たちに上記の記事を話したら、AIのコンテキストサイズに収まりきらず、記憶できなかったからでは？という指摘を受けた。
確かに、人間でも同様に3つの役割を課されると混乱するだろうが、AIでも同じなわけだ。

【3】そこで、AIの暴走を封じ込めるために、GitHubとチケット駆動というガードレールを入れた開発スタイルだ。

AIの暴走を物理的に封じ込める【Git × チケット駆動】のクローズドループ開発 #TiDD - Qiitaの記事になる。

（引用開始）
AIにプロセスやコンテキストの管理を丸投げすると、推測が発散して暴走と破綻を招く。
これを防ぐには、アーキテクチャによってAIの行動に物理的な「ガードレール（境界線）」を設ける必要がある。
**「チケット（Issue）による境界線設定」と「Gitによる絶対的な状態管理」**を組み合わせた『チケット駆動開発（TiDD）』は、現在の私たちが手応えを感じている、極めて現実的で強力なアプローチの一つである。
（引用終了）

興味深い点は、Issueというチケットを作業指示書とみなし、GitHubに蓄積されたリポジトリのソースコードを外部記憶媒体とみなして、AIのハルシネーションを起こさせない仕組みを作った点だ。
つまり、チケット駆動が起点になれば、AIにガードレールを自然に実装できることになるわけだ。

【4】この考え方を発展させると、AIによる開発プロセス実装を「Loop Engineering」で実装したい流れになる。

AI開発の新潮流「Loop Engineering」を、Gitとチケット駆動（TiDD）で今日から安全に始める方法 #開発プロセス - Qiita

（引用開始）
現在、AI開発の最前線では「プロンプトからループへ」というパラダイムシフト（Loop Engineering）が提唱されている。
しかし、AIを自律ループさせるフレームワークを現場でゼロから構築・運用するのは、まだハードルが高い。
そこで、既存の定着した技術である【Git × チケット駆動】を用いた構成が、手軽で安全な「Loop Engineeringの実装の第一歩」になり得ると考えている。
（引用終了）

僕の理解では、Harness Engineering ＝Scrumプロセス実装、ScrumチームそのものをAIで代替。
Loop Engineering ＝Scrumチームの外にいるユーザ自身もAIで代替。

上記の記事では、AIはScrumプロセスだけでなく外側のループも飲み込めるはず、と主張している。
この意見はすごく大胆だな仮説だ。
この意見が本当ならば、ソフトウェア開発も要件定義も全てAIでやらせてしまえばいい。
ソフトウェア開発を成功させるにはScrumの適用が一番だ。
そのScrumプロセスはAIで実装できる。
さらに、Scrumチームに要求を渡すユーザそのものをAIで代用できるならば、Scrumチームの外側もAIで代替できる。

AIがScrumプロセスを実装し、Scrumプロセスの外側も代替するならば、ソフトウェア開発の世界全体はAIで全て制御できるだろう。
たぶん、今、皆がこのアイデアを試している最中だろう。

AIは急激に進化しているので、今時点でうまくいかなくても、来年にはLoopEngineeringを超えた新たな概念が生まれて、問題解決してくだろう。
つまり、AIによる問題解決のレベルがどんどん上っていくだろう。

この進化の先も見届けたいと思う。