第23回Redmine大阪の感想～AIの暴走はチケット駆動で制御する！AI時代に人間が担うべき真の役割は何なのか？ #redmineosaka

AIが開発を自動化する現代、プロジェクトの文脈を知らないAIの暴走をどう防ぐか？
第23回Redmine大阪で語られたRedmineのMCPサーバー化や、制御工学に基づく『チケット駆動によるAI制御』を通じ、AI時代における人間の役割とプロセスのあり方を考えてみた。

【参考】
第23回Redmine大阪 - connpass

Redmine-osaka-023 - Redmine.Osaka

【1】1年ぶりのRedmine大阪のテーマは、やはり「AIｘRedmine」だった。
AIがソフトウェア開発を飲み込んでしまって、AI無しのソフトウェア開発はもうありえない。
プログラミングはもちろん、テスト駆動開発・CI・CD・スペック駆動開発・コンテナ作成・インフラ基盤作成まで全てAIエージェントで自動化できてしまう。

おそらく、タスク管理のような単純なマネジメント作業そのものもAIで自動化されるだろう。
では、現代のAI時代では、何が問題になるのか？
現代のAI時代では、ソフトウェア開発のあるべき姿は何なのか？

【2】@haru_iidaさんの講演で興味を持ったことは、RedmineAIヘルパープラグインにより、RemdineそのものがMCPサーバの機能を持つことだ。
僕はこの意味が即理解できなかったが、 レイリーさん、@akahane92さんの説明により理解した。

RedmineサーバーにMCPサーバー機能をもたせることには2つの意味がある。
1つ目は、RedmineのI/Fがプロンプトを認識できることにより、ユーザはRedmineに自然言語で直接アクセス制御できることだ。
以前なら、REST APIでデータ取得更新するしかなかった。
つまり、REST APIの仕様に従って逐一PythonやRubyのプログラムを書くしかなかった。
しかし、RedmineがMCPサーバー機能を持つことにより、RedmineにあるチケットやWikiなどのPJ情報は、「期日間近のチケットを教えて」とプロンプトを投げればいつでも簡単に取り出せる。
よって、プログラミングを知らない初心者でも、Redmineのチケット情報、ナレッジを有効活用できる。
これはすごいことだ。

2つ目は、MCPサーバをローカルPC上に作成する必要がないこと。
以前なら、ClaudeCodeでRedmineにアクセスしたいならば、自分のPC上にMCPサーバを構築してそれを経由してRedmineやGitHub、Slackなどにアクセスするしかなかった。
逐一、MCPサーバをコンテナ作成するなど手間がかかった。
しかし、RedmineにMCPサーバー機能を持たせることで、ユーザは面倒な作業を除去できる。
この考え方は、一昔前のクライアント・サーバーモデルと同じだ。
クライアント側にビジネスロジックを持たせてサーバーと同期させたり、データの取得更新処理を実行するのではなく、サーバー側にすべての処理を集約させる考え方と同じだ。

一つ疑問点が浮かぶことは、レイリーさんの質問の通り、RedmineにMCPサーバを持たせることにより、セキュリティやアクセス権限制御は大丈夫なのか？という点だ。
どんなPCからも自由にRedmineを簡単に制御させられるのは危険だ。
@haru_iidaさんの回答では、Redmine側のログイン機能やアクセス権限弦制御に従うこと、最新バージョンならOAuth機能も付いているから大丈夫、とのことだった。

【3】@tokudiroさんの講演「AIｘチケット駆動」は、僕が参加者と深く議論したかったテーマ「AIの暴走をチケット駆動で制御する」になる。
アイデアは既に書いた。

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

@tokudiroさんの講演を改めて聞いて、ポイントは3つある。

1つ目は、AIは案件のコンテキスト、チームのコンテキスト、ローカルなコンテキストを知らないから暴走しやすいという根本問題だ。
AIはいくら優秀だとしても、彼らは、僕らの案件の詳細を知らないし、僕らの組織にある暗黙知を知らないし、僕らのチームメンバーの癖や暗黙知を知らない。
だから、AIは一般論で突っ走って、僕らが想定しない成果物を出してくる。
そこで、チケットを作業指示書とみなして、作業指示書にプロンプトや前提条件、制約条件を集約して、AIに実行させることでAIを制御する。
プロンプト実行後にAIが出してきた成果物、設計構想、検討結果に対し、人が取捨選択して意思決定し、その履歴はIssueログに残す。
Issueログには、意思決定の履歴が残る。
つまり、意思決定した時にどれを選択したのか、選択した基準は何か、却下した理由は何か、それらのログは全て残る。
それら暗黙知は、プロジェクトのコンテキストそのものだ。
AIはそれらを学習することにより、僕らの癖、価値観をAIは理解して、AIが出す成果物の品質基準を僕らの価値観にできるだけ合わせるように制御できるはずだ。

2つ目は、AIによる処理をチケット駆動で制御する発想は、制御工学の考え方や仕組みにとても似ていることだ。

チケットを作業指示書とみなして、AIの処理を実行させる。
AIの処理結果を人間がレビューして、誤差を検出しAIにフィードバックさせてAIにココが間違えているから直せと再実行させる。
そういうループ処理を回しながら、チケットに本来書き残した目標に近づけていく。
これは、制御工学そのものだ。
講演資料では「AIのプロセスを制御工学に見立てて、AIの思考に物理的なガードレールを設ける」とある。
つまり、AIは暴走しやすいので、チケットとGitHubリポジトリという物理的なガードレールを設けて、意識的にフィードバックループの制約をかけるわけだ。

一方、@hiranabeさんによれば、制御工学は、いわゆる工業製品では当たり前の考え方だ。
たとえば、お風呂の自動湯沸かし器。
お湯が指定した温度で一定量までお湯を張るようにフィードバックさせるが、一定量になれば止める。
お湯を止める制御がなければ、お風呂はお湯で溢れてしまって、水道代が無駄になるだろう。

@hiranabeさんによれば、モノの制御工学では、センサーにより定量的な数値をフィードバックさせて、アクチュエータが力に変えて水量を制御する。
一方、AIによる処理、あるいはScrumでは、ゴールは曖昧で揺れ動くものであるので、定性的なデータをフィードバックして制御するしか無い。
Scrumなら、フィードバックさせるものは人の経験であり、経験を深めることで、特定のコンテキストに対するナレッジを獲得して目標達成に近づける。

【4】懇親会で色々話して理解したことは、チケット駆動でAIを制御する仕組みは、LoopEngineeringとVibeCodingの間に位置し、AIにすべてを委ねず人間が関与すべきプロセスを明示した点だ。

いわゆるルーチンワークのような業務的意思決定は、もはやAIで全て自動化できるだろう。
しかし、事業戦略の判断、アーキテクチャの判断、我々が本来作りたいシステムのあるべき姿に対する戦略的意思決定は、AIは支援できてもAIに全てを委ねて、AIが自動化できることにはならないだろう。
すると、戦略的意思決定のプロセスでは、細かい作業や処理はAIで自動化したとしても、途中でポーズさせて、チェックポイント地点でゲートレビューを設けて、AIの成果物を人間がチェックして、判断するチェックポイントを入れる必要がある。
これこそがAI時代の本来のプロセス設計だろう。

LoopEngineeringでは、このプロセスが全てAIで自動化されるがやはり怖い。
そこで、人間がゲートレビューする出番をわざと作る。
実際、GitHubにおけるプルリクに対するコードレビューが相当するだろう。

この発想は、監査プロセスに対しAIによってどこまでAI自動化できるのか、という問題に発展するだろう。
製造業では、人命・品質に関する規格により、製品も製造プロセスも制御されている。
一定の品質の製品でなければ、人が怪我をしたり命に関わる事象に陥る。

製造プロセスをできるだけAIで自動化したとしても、AIが作り出した製品の機能が本当に品質担保できているのか？を人間が監査して承認を取る必要がある。
つまり、ゲートレビューは監査プロセスで必要だ。
しかし、監査でAIが作り出した成果物の中身を人間が全て理解してチェックできるのか？

@sakaba37さんや@hiranabeさんの意見を聞く限り、AIが出す成果物は膨大なので人間は全てをレビューできない。
しかし、監査プロセスという手続きが妥当であること、サンプルとして取り出したエビデンスが妥当であることが分かれば、AIの成果物の品質も妥当だと判断できるだろう、とのことだった。
つまり、監査とは結局、プロセス監査に過ぎないので、標準プロセスとして定めた監査プロセスが妥当であるならば、その手順に沿ってAIが実行されたことをチェックするだけに過ぎないわけだ。

すなわち、AI時代の監査プロセスは、従来通りのやり方で基本は残るだろうと考える。

【5】@kazuhitoさんの議論で面白かった点は、人がコードレビューしなくなる時代はもう近づいているだろうが、人がコードレビューしなくなる基準は何なのか？という点だ。

今まさに、AIがソフトウェア開発を完全に飲み込んでしまっている。
AIのソースコードは膨大なので、人はすべてを読めないし理解できない。
また、AIが出すソースコードの方が、自分が書いたソースコードよりも凄いぞ、と認識を改める場面も多くなっているだろう。
つまり、AIの成果物の方が品質が良いのだ。
すると、人はコードレビューする能力をそもそも持っているのだろうか？
コードレビューはもはや単なる承認する儀式に過ぎないのか？

@sakaba37さんの意見によれば、アセンブラの頃のプログラミングやテストに似ていると言う。
アセンブラは機械語なので人間には読みにくい。
しかし、デバッグが必要な場面もある。
すると、人は、あるチェックポイントでゲートレビューしてレポートを出させて、成果物そのもののアセンブラは見なくて、レポートだけで判断する。
そのレポートを見ながら、デバッグの指示を出しデバッグのフィードバックを繰り返して、期待する処理に近づける。

その話を聞いて、僕は、結局、AI時代の監査プロセスと同じだな、と思った。
結局、AIの成果物の中身まで人間は全てを把握することは諦めるしか無い。
人間は、手続きというプロセスが正しいことを信じて、承認という判子を押すだけの存在になるしか無い。
AI時代のプロセスは、プロセスの中で実行される処理を見るのではなく、処理を実行させる元のプロンプトに妥当性があることしか、人間はチェックできないだろう。

すると、コードレビューしなくなる基準は、AIによるコード生成のプロンプトによって実行されるプロセスそのものの妥当性が保証される状態を指すだろう。
つまり、プロンプト群から生成されるAIの処理に再現性があり、一定品質をクリアできるならば、もはや人間が関与する必要はない。

たとえば、自動運転技術が最たる例になるだろう。
人間が運転するよりも、AIで自動運転するほうが交通事故が少ないならば、その方が人命は安全だからだ。
つまり、人間が変にこだわって意思決定する行為は、もう無くなる可能性もある。

【6】@kazuhitoさんの話でもう一つ面白かった点は、AIとの付き合い方は、オフショア委託や下請け委託と同じように考えたほうがいいですよ、という主張だ。
たしかにそうだ。

今、ソフトウェア開発をAIで全振りした場合、発注者である自分は、AIに、これこれの機能を実装せよ、こういう品質をクリアせよ、とたくさんの制約条件や前提条件を書いて、指示を出す。
AIは、プロンプトという契約に沿って、成果物を作り出す。
AIが出して来た成果物を人間はレビューして、気に食わなければ、AIに突き返す。
AIはまた修正して、人間にレビューを依頼する。
AIと人間のループ作業によって、最終的に欲しい成果物が得られる。

この関係は、請負契約や業務委託契約に似ている。
AIが作り出す成果物が品質基準をクリアしなければ突き返すならば、請負契約と同じだ。
AIに壁打ちして、企画構想やアイデアを具体化していく作業を行うなら、AIに一定期間のコンサル業務を業務委託契約している感覚だ。

一方、AIは人間と違って、24時間365日フル稼働できるし、こちらの要望に沿ってすり合わせしてくれるので、優秀なオフショア委託ベンダーみたいなものだ。
他方、AIは責任を負わない。
たとえば、インドや海外のオフショア委託ベンダーが期限までに間に合わければ、発注者はペナルティを課し、損害賠償させる契約を結んでリスク回避させることもできるが、AIにペナルティを課して損害賠償させることは出来ない。
AIは、こちらが頼んだ成果物と違うといくら言っても、プロンプトを投げれば即座に成果物を作って送り返してくるので、納期までに間に合わないリスクは、結局、発注者である自分に戻ってくる。

そんなことを考えると、AIを上手く使いこなせる人は、発注者として下請けを上手く操れる手配師みたいな人の方が向いているのかもしれない。
でも、その考え方は何故かしっくり来ないけどね。

【7】AI時代のRedmineの課題は、今までの常識では通用せず、AIの処理の速さによりボトルネックが自分自身に跳ね返ってくる点にあるのだろうと思う。
問題となるボトルネックは、システムではなく、人間の思考や行為そのものに存在する。
たとえば、Redmineがいくらナレッジ基盤として優秀であっても、人間がチケット入力しないと意味がないし、チケット運用する必要もある。
本来はRedmineチケット管理でもっと管理作業を効率化したいのに、AIやRedmineがすごく優秀になりすぎると、人間自体がボトルネックになってしまうわけだ。

僕が考えているテーマは結局下記の2つだ。
現代のAI時代では、ソフトウェア開発のあるべき姿は何なのか？
監査プロセスに対しAIによってどこまでAI自動化できるのか？

この辺りの問題解決のアイデアは色々考えてみる。

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のハルシネーションを物理的に封じ込める最適解「チケット駆動」の実践論を考えてみた。
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は速く回すことを重視するが、工程がたくさんあるので、その工程が切れる点が弱点になる。
その点を考えるほうがいいかもしれない。

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による問題解決のレベルがどんどん上っていくだろう。

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

AIが設計も思考も代替する時代ではエンジニアはモデルを理解するだけの存在なのか？

要件から実装までAIが完遂する「FDE」の台頭。
それはアジャイル開発の終焉と、システム設計や「思考」すらAIに委ねる未来を示唆している。
人間はAIが生成したモデルをただ「理解」するだけになるのか。
すべての作業と思考が代替される世界で、私たち人間の存在意義は一体どこにあるのか。

【参考】
Astah Pro MCP | astah* プラグイン

takaakit/astah-pro-mcp: A local MCP server that runs as a plugin for Astah Professional, a UML modeling tool.

takaakit/superpowers-uml: Superpowers-UML modifies Superpowers to ensure a software development workflow in which AI agents design through UML modeling.

astah* AI連携機能

FDEは「客先常駐SES」と何が違う？人間の複雑さに向き合う「AI SaaSの生存戦略」【ログラス×LayerX】 - レバテックLAB

FDEとは？最高峰のAI職種「Forward Deployed Engineer」について徹底解説！年収・職務内容・転職・求人情報 | AI・エンジニア転職ならムービン

【1】最近、FDEという言葉を知った。
「Forward Deployed Engineer」と呼ぶらしい。
僕の理解では、FDEは、要件だけ作って、後はAIエージェントに設計・実装・テスト・移行まで全てやらせる。
つまり、顧客にヒアリングして、課題解決のためにシステム要件を提案し、その後のシステム開発は全てAIにやらせる。
また、AIエージェントにシステム開発させる仕組み、つまり、ハーネスエンジニアリングも設計する役割と理解している。

【2】では、プログラマはもちろん、システムアーキテクトもFDEで代用されるのか？
そんな疑問を感じる。

AIによるシステム開発は、アジャイル開発そのものを否定するだろう。
アジャイル開発は、顧客と開発チームが一体化して開発する。
しかし、要件さえ固めれば、後はAIが全て自動生成してくれる。
つまり、顧客と、顧客からヒアリングして要件をまとめるコンサルがいれば、後はAIがよろしくシステム開発してくれる。

すなわち、ソフトウェア開発プロセスを見れば、要件定義だけになる。
なぜならば、その後の工程、設計、開発、テスト、移行は全てAIが代替してくれるので、気にしなくていいからだ。
すると、AI主導のソフトウェア開発プロセスはWF型開発に先祖返りするだろう。
要件定義をガチガチに固めるのが重要なのだから。

アジャイル開発プロセスに乗せたとしても、AIがリリースしたシステムから顧客のフィードバックをもらって、それを要件定義して、再度リリースするだけだ。
アジャイル開発プロセスが定義する、設計も開発もテストも同時並行して開発チームが考えるプロセスは無くなる。
つまり、要件定義とAIのシステム開発だけの工程になるならば、WF型開発で工程管理した方が楽だ。

よって、システムアーキテクトという役割もAIに吸収される。
じきに、顧客自身が要件をまとめられるならば、コンサルも必要ない。
要件をのものをまとめる作業すら、AIにいろんな要望をプロンプトで投げれば、要件定義書も作ってくれるだろう。
つまり、ビジネスアナリストという役割もAIに吸収されるかもしれない。

FDEが示唆するものは、AIがシステム設計から移行までを代替するだけでなく、じきに要件定義そのものもAIが代替することを示唆しているだろう。

【3】また、astahでは、AI機能が投入された。
Copilotと連携して、AIと対話形式でクラス図、シーケンス図などの自動生成をしてくれる。

astah* AI連携機能

振り返れば、MermaidやPlantUMLでクラス図やシーケンス図などUMLダイアグラムは全て書けるのだから、AIでMermaidやPlantUMLをAIで生成すればいい。
つまり、モデルそのものもテキストで表現できるならば、プロンプトと相性がすごくいい。

astah上で、モデルの配置をマウスでグリグリする作業すらいらない。
AIがモデル要素を吐き出し、モデルの配置すら定義してくれるからだ。

【4】では、モデリング作業や、システム設計という思考そのものはAIがどこまで代替可能であるか？

モデリング作業そのものはAIに吸収されるだろう。
UMLの全てのダイアグラムは、MermaidやPlantUMLで書けるのだから、UMLによるモデル生成はAIで実装される。

FDEと同様に、モデルを定義するアーキテクチャ設計そのものもじきにAIが代替するだろう。
要求を適当にプロンプトで投げれば、要件定義書が出力できるからだ。
そこから、Bestなアーキテクチャ設計もAIに聞いて、判断すればいい。
判断そのものも、判断基準をプロンプトで投げてAIにやらせればいい。

すると、システム設計という思考そのものもAIに委託して、AIに代替されるのか？
確かに、人間が思考する行為そのものもAIに委託できるだろう。

しかし、人間はシステムを理解したい欲求があるはずだ。
システムは複雑で、目に見えないので理解しづらい。
そこで、システムをモデル化して理解したい。
よって、システムをリバースして、モデル化する作業そのものをAIにやらせればいい。

AIにシステム開発させるだけでなく、人間が理解するためのモデルもAIに生成させる。
AIで生成されたモデルを通じて、人間はシステムとアーキテクチャ設計を理解するだろう。

【5】結論は、AIがシステム開発も、システム設計も、アーキテクチャ設計も、モデル生成も、モデル設計の作業も全て代替するだろう。

システム要件を考える行為、モデルを考えるモデリング行為そのものもAIが代替するだろう。
人間の思考そのものも、AIに委託できるだろう。

しかし、モデリング作業は必要にはならないと思う。
人間がシステムを理解するためにモデルが必要だからだ。
つまり、人間がシステムを理解し把握するために、AIがモデル生成する作業そのものは残るだろう。

すると、人間の役割は何なのか？
AIがすべての作業を代替してやれるならば、人間の存在意義は何なのか？

要件定義を行うビジネスアナリスト、システムアーキテクチャを考えるシステムアーキテクトの役割もAIが代替するならば、人間の存在は何の役に立つのか？
思考する行為が人間の存在意義だったのに、それすらもAIに委託できて、AIの方がはるかに深い考察結果を出すのならば、人間は不要なのか？

製造業の工程管理の課題とアジャイル化の壁

米中の製造業がアジャイル開発を推進して躍進する一方、なぜ日本の製造業はアジャイル化に苦しむのか。
自動車や半導体装置の事例から見えたのは、機能別組織による工程分断という組織構造の呪縛だ。
次世代のものづくりに向け、製品アーキテクチャと組織の壁を越え、アジャイル変革を成し遂げる突破口を探る。

【参考】

challenges-in-process-management-and-barriers-to-agile-transformation-in-the-manufacturing-industryfrom akipii ogaoga

【1】僕は、製造業でもアジャイル化すべきだと思う。
実際、イーロン・マスクのTesla、SpaceXは、製造業でアジャイルを実践している企業だろう。
しかし、日本の製造業は従来の工程管理、WF型開発に固執し、最先端を行く米国企業、中国企業に追いつけてない。

【2】では、日本の製造業の工程管理の実態は何か？
彼らの工程管理では、どんな課題があるのか？

製造業の業界にもたくさん種類があり、各メーカーごとに工程も異なる。
ここでは、僕が経験したメーカーとして、自動車OEMメーカー、半導体製造装置メーカー、防衛宇宙メーカーの事例を通して考えてみる。

【3】1点目は、各メーカーの工程管理の実情は、製品軸の事業部内でも機能別に部門が担当し、工程を跨いだ連携が困難になる。
つまり、機能別組織が工程管理の分断を生んでいる。

SIerでは、PJ単位に、1つの事業部が見積もり～運用保守までの工程を全て管理しているだろう。
つまり、SIerの事業部内には、PM、PL、SE、PGがいて、彼らが各案件を担当する。
とはいえ、インフラ部隊、セキュリティ部隊は専門家集団なので、全社共通の機能別組織として存在し、各案件で必要な時だけ顔を出して作業する。
また、事業部制組織なので、事業部には、管理部門がある。
SIerでは、管理部門が事業部ごとに散在し重複した機能を持つので、無駄は発生しているが、案件優先なので良しとしているだろう。

よって、SIerでは、1つの事業部が全てのリソースを把握して、複数案件を管理する構造になるから、WF型開発であっても、全工程で担当者は密に連携する特徴がある。

【4】一方、製造業では機能別組織が中心なので、SIerとは組織観点が大きく異なる。
製造業では、メカ・エレキ・ソフト・生産計画・製造・品質管理などの部門は、独自の専門知識が必要であるため、専門家集団として統率する方がメリットがある。
しかし、その弊害も大きい。

たとえば、自動車OEMメーカーでは、試作車を作り、それを元に設計し試験して、設計仕様を固める。
その後、量産準備に入り、大量の部品を期日通りに発注し入荷して、工場で量産し、販売会社に渡して出荷する。
デメリットは、設計部門、生産計画部門、調達部門、製造部門、販売部門のように、専門分化されているために、各工程間の情報連携が悪いことだ。
だから、トヨタなど大手OEMメーカーでは、車種ごとにプロダクトオーナーのような人やチームが存在して、エンジン・ブレーキ・シャーシ・サスペンションなどの専門家集団へ必要な機能要件を提示して納入させて、独特な優れた車を生み出していた。
つまり、ある意味では、Scrumのような組織体制や運用を回していたわけだ。
しかし、組織構造としてはマトリクス型組織になるので、作業者にとっては、2ボス体制になるので、2ボスの優先順位が異なると混乱する。
また、専門部署の作業者も1つの案件に関わるわけではなく、複数の案件の開発に関わるケースも多いので、複数案件の担当になる。
よって、メンバーの作業負荷に繁忙期が発生しやすく、リソース管理が非常に難しくなる。
これが、マトリクス型組織の弊害だ。

【5】たとえば、半導体製造装置メーカーでは、TSMCやサムスンなどの大手半導体メーカーに製品を出荷する。
半導体製造装置も機種単位に作られ、基本は派生開発が中心になる。
AMSLのような大手であれば1機種500億円もするし、他の工程担当のメーカーでも1機種数億円から数十億円はするので、月産台数は100台にも満たない。
しかし、自動車並みに部品点数が多く、顧客ごとにカスタマイズした機能要件で設計する必要があるので、典型的な特注品の受注生産になる。
彼らも設計部門が非常に重要であり、設計工程で仕様が確定し、その仕様に基づいて発注や製造が行われる。
設計部門は派生開発を担当するので、複数の機種を担当するために、マトリクス型組織になる。
同様に、2ボス体制やリソース管理の問題が発生する。

【6】たとえば、防衛宇宙メーカーでも、同様の工程が存在する。
こちらも典型的な特注品の受注生産になる。
面白い点は、ミサイルやレーダーなどの防衛装置は巨大であるので、倉庫へ配置したり、実際の戦場に配置するために建設部隊が必要になる点だ。
建設工程は、SIerで言えばシステム移行に相当するだろう。
彼らも設計部門が非常に重要だ。
なぜならば、設計部門が基本的にプロジェクトマネジメントも担当し、メカ・エレキ・ソフト、調達、製造、建設部門に指示を出し進捗管理を行っているからだ。
すると彼ら設計部門も、複数の製品を担当するケースが多いので、マトリクス型組織になる。
同様に、2ボス体制やリソース管理の問題が発生する。

以上のように、どのメーカーでも工程管理がしっかりしているが、工程が各組織に分断されているために、情報連携が悪い。
どの部門も複数の製品や案件を担当するので、マトリクス型組織になるので、特に要員管理に非常に苦労している。

【7】2点目は、SIerと比較して製造業は工程が専門的で分断するために、アジャイルな工程管理を実現しづらい点だ。

SIerなら、ウォータースクラムフォールのように、Agileを挟んだWF型開発が主流だろう。
よって、アジャイル開発をスムーズに運用しやすいメリットがある。
明確に要件が固まれば、後は定期リリースの型に当てはめれば、自然にアジャイル開発になるからだ。
しかし、製造業では事情が異なる。

【8】たとえば、自動車OEMメーカーでは、試作工程のテストカーを作る段階は完全にアジャイルだ。
その後の設計、試験も普通はアジャイル開発を実装できるはずだが、単なるバグ修正ばかりやっている。
実際、設計してECUをハードウェアで作り、ソフトウェアを乗せて、山奥の試験場でテストカーを走らせてバグ出しする。
そのサイクルを繰り返すので、アジャイル開発にしやすいはずだが、そうならない。
なぜならば、ハードウェアがなければソフトウェアも載せられない。
つまり、ハードとソフトの間には依存関係や支配関係があり、どうしてもソフトウェアは後回しになりやすく、しわ寄せを受けやすい。
本来は、アジャイルリリーストレインのように、複数のマイルストーンを1スプリント内に設けてハードとソフトの開発を同期させるような仕組みが必要なはずだが、そのようなプロセス設計は結局見られなかった。

そして、量産準備から調達、量産以降の工程は全てWF型開発になる。
大量の部品を期日に従って調達し、生産ラインで量産していくため、どうしても期日通りにWF型開発でやるのが当たり前になる。
しかし、昨今は、戦争や国際政治、地震台風などによるサプライチェーン阻害により、量産工程を期日通りに回す運用が非常に難しくなっている。
よって、WF型開発で量産するという発想をアジャイル開発に切り替える、というアイデアへ変えるべき時に来ているかもしれない。

【9】たとえば、半導体製造装置メーカーでは、特注品の派生開発がほとんどなので、マイルストーン単位の開発をアジャイル開発に置き換えられるはずだ。
しかし、実際は、見積もり工程や設計工程がPLMやERPと連携されておらず、自動車並みに複雑な製品を作っているのに、Excel仕様書で散在しているためにすごく煩雑な作業になっている。
単なる手作業で忙しく回しているに過ぎない。
調達や量産も同様の事象の問題が発生し、期日通りに製造するのが難しい状況にある。

【10】たとえば、防衛宇宙メーカーでも同様に、特注品の派生開発が中心だ。
ここでは、設計部門がプロジェクトマネジメントも担当しているので、彼らが意図的にアジャイル開発を適用してプロジェクト管理できればよいが、彼ら自身がアジャイル開発を知らないし、たくさんの機能部門と調整する作業に忙殺されている。
調達や量産も同様の事象の問題が発生し、期日通りに製造するのが難しい状況にある。
ここでもアジャイル開発を適用できていない。

【11】つまり、製造業では、各工程とその機能別組織に分断されているために、アジャイル開発を適用するハードルが高く、アジャイル開発プロセスをそもそも適用しづらい。
アジャイルリリーストレインのような高度な同期システムが必要になるが、個別の企業ごとに実装するには、検討すべき点が多くて非常に難しいだろう。

【12】そんな状況にあるので、現時点では、日本の製造業アジャイルはAsIsの呪縛から逃れるのが非常に難しいと考える。
しかし、イーロン・マスクの企業はやっているのだから、何かヒントがあるはずだ。
そのヒントを探してみる。

Redmine利用成熟度モデルによる運用戦略

Redmineを単なるタスク管理で終わらせるな。
全社展開で組織のプロジェクトマネジメント能力を獲得するには明確な運用戦略が不可欠だ。
僕が独自で考えた「Redmine利用成熟度モデル」を提唱し、7段階のステップで現在地から理想のゴールへ導く実践的ロードマップを以下に示す。

【参考】
Redmineによるタスクマネジメント実践技法

operational-strategy-based-on-redmine-utilization-maturityfrom akipii ogaoga

【1】今、JTC全体にRedmineを運用推進する立場にあったとする。
その時、どんな戦略を立てて、Redmineを全社の案件に適用し、推進していくべきか？
Redmineを利用していく前提に対し、どんなゴールを目指すのか？

その時に考えるべきモデルが必要だ。
僕は「Redmine利用成熟度モデル」を提唱し、そのモデルを基準として運用戦略を立てる方針とした。

【2】なぜ、Redmine利用成熟度モデルを考える必要があるのか？
そもそも、そんなモデルは役に立つのか？

前提として、Redmineを個別最適化された一つの案件だけでなく、全社に展開し、全ての案件に適用したい立場にある。
すると、Redmineというツールを単に導入するだけの仕事になってしまう。
しかし、本来は何かしらの目的があるはずだ。
そうでなければ、わざわざ、工数やコストを支払ってでもやる必要がない。

Redmineを導入する目的は、Redmineという柔軟なチケット管理ツールを用いて、組織としてのプロジェクトマネジメント能力を獲得したいからだ。
さらには、多種多様なプロジェクトを一つのツール内のタスク管理や進捗管理、コスト管理に収めて、一元管理することによって、全ての案件の健康状態を即座に把握し、管理職層や経営層にエスカレーションし、意思決定できる基盤を提供することだ。

つまり、組織のプロジェクトマネジメント能力を獲得できている状態が目指すべきゴールになる。
そういう組織的能力が身につくからこそ、単なる進捗管理だけでなく、予定工数や実績工数を入力してEVM活用やプロジェクト報告を出力することにより、複数案件をまたいだ要員管理や予算計画のようなコスト管理まで可能になる。
そうなれば、事業部長レベルの意思決定支援にRedmineを有効活用できるようになる。

そんなゴールを目指すためには、組織のプロジェクトマネジメント能力がどのレベルにあるのか、を把握する基準やメトリクスが必要になってくる。
その基準を組織に当てはめることにより、現在地を知り、ゴールに向けて後どれくらいの階段が残っているのか、を見極めて、戦略を練ることができる。

【3】組織のプロジェクトマネジメント能力、具体的にはRedmineの利用レベルがどんな状態にあるのか、それを把握する基準の考え方が、Redmine利用成熟度モデルという概念だ。

ネタバレとして、CMMIやIT経営成熟度モデル、DX成熟度モデルなどを参考にしたが、Redmineの利用状況をより具体的に明確に定義するために、７段階で定義した。

operational-strategy-based-on-redmine-utilization-maturityfrom akipii ogaoga

【4】レベル１は、Excelで進捗管理している状態。
案件が順調ならまだしも、３人のチームであっても、突発的な作業依頼や仕様変更、手戻り作業が発生すれば、すぐに破綻する。
まだ、Redmineを運用できていない状態だ。

【5】レベル２は、ガントチャートの工程管理ができる状態。
Redmineを利用して、チケット管理を通じて、ガントチャートの工程管理ができる。
WBSをチケットにすれば、３階層、５階層でも複雑なWBSも実現できる。
ただし、標準プロセスが確立していないので、プロジェクトごとに運用ルールがバラバラであり、ノウハウも共有できていない。
各案件ごとに個別最適化されたRedmineプロジェクトが乱立している状態だ。

この状態が続くと、運用はじきに破綻する。
なぜならば、Redmineを単なるタスク管理としてしか使っておらず、全社でナレッジを共有したり、プロセス改善する仕組みがないからだ。
よって、プロジェクトリーダーの手腕に案件の成功が依存する。
したがって、組織のプロジェクトマネジメント能力が向上できるとはいえない。

【6】レベル３は、最低１タイプの標準プロセスが確立し、各プロジェクトに適用して運用できている状態。
具体的には、全社で使うべきトラッカーの種類が確定し、ワークフローが定められて、全てのPJに適用できている。
たとえば、「タスク」以外にも、「障害」「課題」「カスタマーサポート」などのトラッカーとワークフローが準備されているだろう。

さらに、製造業であれば、ISO9001などの国際規格に準じたプロセスに適用する必要がある。
そんなプロセスの実装手段として、チケットテンプレート、チケットセット、プロジェクトテンプレートのような機能があるだろう。

たとえば、チケットの書き方として、作業内容だけでなく、作業手順や完了条件、資料リンク、対応履歴などの記載をチケットテンプレートとして案件に提供し、記載内容の粒度を揃える。
つまり、LycheeRedmineのチケットテンプレートを使う。
そうすれば、システム監査やISO監査でも、調査しやすくなる。

たとえば、CADの画面を出図する設計プロセス、製品の部品や役務を購買する発注プロセス、製品の試験や品質保証を規定するプロセスがある。
つまり、各プロセスには、既に定められた手順がある。
その手順をチケット化してテンプレート化すればいい。
LycheeRedmineには、チケットセットという機能があり、標準WBSとして階層構造のチケットの塊をテンプレートとして保持し、コピーすることで使える。
つまり、出図プロセス、発注プロセス、製品試験プロセスの標準WBSをチケットセットで作っておき、必要な時にコピーして案件に取り込めばよい。

たとえば、製品の派生開発の案件に対し、以前の製品開発の案件設定をそのまま流用して使いたい場面が出てくる。
派生製品であれば、カスタマイズする場所は特定できている前提ならば、トラッカーやカテゴリなどのチケット機能、メンバー、WBSなどもそのまま流用したくなる。
あるいは、親PJの設定を子PJへ流用して同様に設定したい場合も多々ある。
そんな実装手段として、LycheeRedmineのプロジェクトテンプレートが使える。
そうすれば、以前のプロジェクト、親プロジェクトをそのまま流用して適用すれば良い。

【7】ここまで到達すれば、Redmineを運用する基盤は整う。
僕の経験上、レベル３に到達するには、一般に、SEPGと呼ばれる「Software Engineering Process Group（ソフトウェアエンジニアリング・プロセス・グループ）」の部門が必要になるだろう。
つまり、ソフトウェア開発の品質向上や業務効率化を目的として、組織の標準的な開発プロセス（進め方）の企画・構築・改善を専門に行うチームや推進者を指す。

SEPGは主に下記３点のミッションがあるだろう。
・プロセスの標準化: 組織全体で一定の品質を担保するため、開発手順やルールを定めた「標準プロセス」を策定。
・プロセス改善（SPI）: 現場の課題を分析し、より効率的で安全な開発ができるようにプロセスを改善・更新。
・現場への展開と支援: 新しいプロセスを現場のプロジェクトに導入・定着させるための教育やサポート実施。

【8】ただし、レベル３以上の機能に確実に対応するには、Redmine標準の機能だけでは足りない。
LycheeRedmineのような有償機能の導入が必要になる。
コスト面さえクリアできれば、Redmine利用成熟度モデルに従って、組織のプロジェクトマネジメント能力の現在地に応じて、どこまでのレベルを目指すべきなのか、検討できる。

【9】レベル４では、Redmineに蓄積されたデータを元に定量分析・測定できる状態にある。
具体的には、Redmineに蓄積されたチケット、Wiki、外部リポジトリを集計して、案件のQCDを把握するための情報を測定し、分析し、プロセス改善を行う。
たとえば、Redmine標準ならサマリの機能があるし、LycheeRedmineならダッシュボードがあるだろう。

一般に、SEPGが定量分析・測定を行い、各案件のQCDのメトリクスを出力し、診断レポートを作成し、案件のリーダーやメンバーに配布して、プロセス改善を促す
あるいは、案件のQCDを見える化して、プロジェクトの組織的課題やプロセス観点の課題を抽出し、マネジメント層や経営層へエスカレーションして、意思決定を促す。
これこそが、SEPG本来の仕事になる。

なお、LycheeRedmineだけでなく、Tableauなどの外部BIツールを使ってもいいだろう。

【10】レベル５では、各タスクの予定工数や実績工数を入力し、EVMを出力し活用できている状態になる。
EVMのメリットは、案件の進捗やコストの状況を定量的にリアルタイムに把握できる点だろう。

PMBOKではEVMの定義と計算をやらされるが、実際のプロジェクトマネジメントで適用するのは非常に難しい。
単純なExcel管理では実現できないからだ。
だから、EVMは机上の理論に過ぎないとよく言われる。
しかし、たとえば、僕の経験では、能力の高いプロマネは、ExcelマクロでEVM機能を実装しておき、社内の予算管理システムから予算、原価管理システムから実績工数や実績原価を取得し、Excelマクロに取り込んで、EVMを測定し、独自に分析していた。
EVMのグラフを出力できれば、一目瞭然に案件を傾向分析できる。
彼は、EVMを案件のリスク管理に使っていたわけだ。

一方、2010年当時に「Redmineによるタスクマネジメント実践技法」本を出版した時は、EVM活用はまだアイデア段階だった。
しかし、LycheeRedmineによりついに機能として実装された。
標準プロセスが確立し、予定工数や実績工数を入力する運用を徹底できれば、EVMの出力は簡単になる。

【11】EVM運用できる状態にあるメリットは、リソース管理により、生産性、稼働率を把握でき、負荷計画を立てやすくなることだ。
たとえば、人別の実績工数から、案件の稼働率も把握できる。
製造業にとって、稼働率というKPIは非常に重要だ。
設備機械、担当者の稼働率が高いほど、工場にある資源を有効活用できている状態になるからだ。
彼らは月別の稼働率を色んな観点で把握し、遊んで休んでいる設備や人がいないか、いつもチェックしている。
そんな管理作業にRedmineが使える。

たとえば、人別の予定・実績工数より、人別生産性が分かる。
最近では、36協定による労働時間規制が厳しくなったので、メンバーの労働時間を正確に把握する必要がある。
Redmineに実績工数があれば即座に把握できるし、生産性を把握することで、リソース配分のKPIとして使うこともできる。

このやり方を更に発展できれば、複数の案件を一括集計して、部内全体の要員管理にも適用できるだろう。
この観点では、案件リーダーのような一人のプロマネではなく、複数の案件を管理するプロマネないし、課長・部長クラスの仕事になる。
彼らにもRedmineが有効なツールになるわけだ。

【12】レベル６では、Redmineに蓄積された情報から集計出力されたQCD情報を元に、PJ報告を作成し運用できている状態になる。
具体的には、EVM運用できている状態であれば、案件のQは課題や障害チケットを集計すればいい。
案件のDはタスクの進捗率やステータスから把握できる。
案件のCはEVM運用により、予定・実績工数を把握できているので、工数ベースで把握できる。
ここで、LycheeRedmineには経費機能があるので、直接コストを円入力することで、原価ベースで保持できる。
この機能により、Redmine上で週次や月次でPJのQCDを報告する運用が可能になる。

今なら、生成AI機能を使って、Redmineのデータを食わせて、報告文章を自動生成すればいい。
LycheeRedmineでは、PJ報告の機能があるので、週次レベルのPJ報告をバッチ出力させて、週次で書かせればいい。

従来は、案件リーダーがExcelやパワポの週次報告をせっせと作って、管理作業が無駄に発生していた。
しかし、LycheeRedmineを使えば、案件リーダーは週次報告作成のような管理作業は必要無くなる。

Redmine上のチケットが正しい状態であれば、週次PJ報告は精度の高い内容になり、単に案件リーダーだけでなく、マネジメント層や経営層に報告して意思決定する情報を提供できる状態になる。
これこそが本来の組織が持つプロジェクトマネジメント能力を測る指標になるだろう。

ただし、LycheeRedmineのPJ報告機能はビジネスプランでしか提供されておらず、一般に使われるプレミアムプランには入っていない。
その点だけ注意が必要だ。

【13】レベル7では、多種多様なプロジェクトへテーラリングできる状態にある。
たとえば、ScrumやCCPMが相当するだろう。
つまり、Redmineによるチケット駆動開発やWF型開発プロセスだけでなく、他のプロセスを主体的に選択できる状態にあるわけだ。
LycheeRedmineにはCCPM、Scrumに特化した機能が用意されている。
CCPMは、製造業の経営層が大好きなマネジメント理論なので、やりたければ、運用ルールを指定してCCPM機能と使えばいい。
Scrumも、NeoバックログやNeoかんばんの機能を使えば、よりアジャイル開発に即したプロセスで運用できるだろう。

しかも、Redmineには複数プロジェクト機能が標準で実装済みなので、CCPMの案件やScrumの案件を、従来のWF型開発案件と併存して運用するのが非常に簡単だ。
CCPMやScrumの運用ルールと、Redmineに即した機能の運用ルールを事前に検討できていれば、個人的にはそんなにハードルは高くないと考えている。

【14】以上が、Redmine利用成熟度による運用戦略のアイデアだ。
Redmine利用成熟度のレベルに応じて、SEPGが目指すべきゴールを定めて、現在地とのギャップをどのように解決していくか、を個別に撃破していく。
そんな戦略を考えるのに、Redmine利用成熟度モデルが使えると考えている。

実際にこの考え方を適用してみたいと思う。

製造業アジャイルの事例リンク

製造業アジャイルの事例を見つけたのでメモ。
細谷さんが実践してきた事例になる。

【参考】
スピード感と品質を両立したアジャイル開発に対応する品質マネジメントシステムとは ～テスト設計方針を組み込んだ完成の定義と品質技術者の導入～ | SQiPソフトウェア品質ライブラリ

三菱電機におけるアジャイル開発への挑戦 ～過去20年の取組みと今後の展望～ | エンタープライズアジャイル勉強会 2025年10月 - YouTube

アジャイル開発時代の品質マネジメントシステム - Yasuo Hosotani - YouTube

RSGT2026参加レポート

三菱電機 DX イノベーションセンターが ISO 9001 認証を取得

併設チュートリアル | ソフトウェア品質シンポジウム 2026
（引用開始）
併設チュートリアル４
アジャイル開発時代の品質マネジメントシステム
細谷 泰夫 氏
三菱電機株式会社
DXイノベーションセンター 開発・品質管理部 部長
概要
本チュートリアルでは、三菱電機がアジャイル開発とISO9001認証を両立させるために構築した、方法論に依存しない「QMSアーキテクチャ」と「品質ガバナンス」の具体的アプローチを解説します。

特にスクラムにおける「完成の定義（Definition of Done: DoD）」に着目し、品質技術者（QE）がどのように定義し、形骸化を防ぐかの実践手法を共有します。後半では、参加者自身が現場の文脈に合わせたDoDを策定するワークショップを実施します。組織の柔軟性と規律を両立させ、品質を自律的に向上させるための具体的なヒントを持ち帰っていただくことを目的とします。
（引用終了）

【1】製造業アジャイルの事例としては考え方が2つある。
1つは、ビジネス観点で、複数ドメイン事業にアジャイル開発を導入し、新卒1年目の若いメンバーからベテランまでアジャイルプラクティスを経験しながらチームの成長を得たこと。

もう一つは、ISO9001のQMSのWFシステムに、アジャイル開発プロセスを取り入れながらも、品質保証プロセスと品質担保の観点を取り入れていること。

いずれもすごく興味深い。
僕もこういう事例を作って発表したい。