人の成果物は品質基準に不足しすぎるが、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へ監査プロセスの適用を当てはめなければ、上手くいなかいだろうと直感する。

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

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

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の方がはるかに深い考察結果を出すのならば、人間は不要なのか？

製造業でアジャイルが定着しない理由～スプリント不在とチケット二重管理の壁 #Redmine

製造業でアジャイル開発が定着しない根因は「スプリント」概念の欠落だ。
WF型の現場ではスコープ調整が機能せず、大日程とチケットの二重管理や階層的なマイルストーンが壁となる。
Redmine運用が破綻する背景から、製造業特有の構造的課題とチケット駆動開発の実態を紐解く。

【参考】
Redmineのバージョンはなぜ使われないのか？: プログラマの思索

第29回東京Redmine勉強会の感想～今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet: プログラマの思索

【0】製造業でアジャイル開発できないのはなぜか？
原因にスプリントの概念が不明確な点があると考える。

【1】ソフトウェア開発では、スプリントの概念は自然に現れる。
たとえWF型開発であってもだ。

アジャイル開発をやっているならば、1～4週間の単位で、定期的にリリースするタイミングがある。
それがスプリントだ。
スプリントの単位で、どの機能を最優先にするのか、決める。
あれもこれも機能実装するわけにはいかない。
限られた期間、限られた人数では、やれる範囲は限られる。
そこで、スコープを調整することで、やるべき機能を優先順位付けし、スプリントの工数に当てはまる範囲に絞り込む。
一般に、カンバン機能を使うだろう。
スプリントレビューで成果物を関係者がレビューし、スプリントデモで実際に成果物を見せる。
そこで得られたフィードバックを元に、また次回のスプリントに活かす。

複数のスプリントを見渡して、どの機能をどの順番でリリースしてシステムを拡張していくべきか？
それがリリース戦略になる。
リリース戦略の観点では、各スプリントの成果物はインクリメント、増分だから、計画的にどのようにインクリメントを積み重ねて最終ゴールに辿り着くのか、という考えになるだろう。
これが、小規模リリースの考えにつながるだろう。
一般に、複数のスプリントをカバーする機能はバックログ機能になるだろう。

一方、ソフトウェア開発の保守案件であれば、普通は月次の単位でリリースする運用が多いだろう。
月次の単位がスプリントになるだろう。
保守契約の工数の範囲内で、リリースする機能の優先順位を決めて、順次作業してリリースしていく。

これが開発のリズムになる。
ソフトウェア開発者にとって、この開発リズムは心地よい。
タスクの優先順位や作業順序は明確だし、自分たちの作業ペースを守って作業できるので、基本は作業負荷が高くなるケースはないからだ。

【2】しかし、製造業の現場では、スプリントの概念がしっくり来ない。

製造業の現場では、基本はWF型開発がほとんどだ。
設計工程、製造工程、試験工程、保守工程になるだろう。
各工程の大日程計画がマスタスケジュールとしてベースラインになり、ガントチャートで予実管理を行う。
そこにはスプリントという概念がない。

たとえば、Redmineのバージョンはなぜ使われないのか？: プログラマの思索に書いたように、Redmineバージョン機能は作業者レベルでは出てこない発想だ。
Redmineバージョンは期日に紐づく機能ではない。
バージョンは、スプリントでありリリースする単位であるので、期日とは別物だ。

そこで、PMOである僕は、PJ全般を見渡す権限を持つ担当として、Redmineバージョンを事前に計画する。
たとえば月次や週次でRedmineバージョンを設定する。
たとえ、製造業の案件であっても、経営層向けの報告のタイミング、顧客に報告するタイミングはあるので、それをマイルストーンに割り当てれば、それがリリースと同じ内容になるからだ。

しかし、製造業の担当者は、このバージョン、スプリント、マイルストーンをあまり意識していないように思える。
彼らはマイルストーンを意識していても、タスク量というスコープをコントロールする意識がない。
理由は簡単だ。
設計工程は確かに試行錯誤する作業が多いが、設計できたCADデータを元に製造工程、試験工程は日程が定まり、リードタイムもきっちり固まる。
設計図をもとに、全ての部品や材料を一括発注し、製造工程でまとめて組み立てて、まとめて試験するからだ。
製造工程以降ではアジャイル開発にはなりえない。

【3】Redmineバージョンが使われないタスク管理ではどんな悪影響が出るのか？

LycheeRedmineには、カンバンやバックログ機能があり、とても使いやすいUIになっている。
しかし、Redmineバージョンが設定されていないと、スプリント単位にタスクがグルーピングされないので、カンバンやバックログを有効に活用できない。
だから、製造業の現場では、カンバンやバックログの機能が使いづらい。
むしろ、ガントチャート画面で、大工程から中日程までのWBSを詳細化して階層化する方を彼らは好む。

でも、僕が第三者観点で見ると、LycheeRedmineのガントチャート画面はUIも優れているし使いやすいが、製造業の彼らは進捗管理に上手く使えているように思えない。
大工程は月次レベル、中日程は週次レベルなので、毎日の朝会でタスク確認すると、あまり進捗が進んでいないように見える。
実際、5日程度の作業量なので、毎日の進捗はせいぜい20％くらい進む程度であり、1日程度の差ではそんなに変わらない。
本来は朝会で進捗状況から課題を把握したいが、担当者が手を上げてエスカレーションしない限り、課題は分からない。
課題は現場でしか落ちていないので、現場すべてを見ていないリーダーからは、課題がないように見える。

そこで、リーダーは小日程レベルのタスクをチケット登録し、WBS管理したがるが、そうなるとタスク管理が発散する。
製造業であっても、小さなタスクはいくらでもあるので、それらを逐一登録すれば、あっという間に1案件でも数千行のWBSに膨れ上がる。
そうなれば、リーダーであってもすべての作業を追跡して把握するのは難しくなる。

本来は、スプリント単位に大量のタスクをグルーピングして、リーダーが追跡できるボリュームにタスク量を減らすべきだ。
すると、カンバンで現在のスプリントのタスク管理ができるようになる。
バックログで、現在と未来のスプリントのタスク管理ができ、出荷までの戦略を立てれるようになる。

でも、製造業の彼らはそんな管理はしていない。

【4】なぜ、製造業ではスプリントの概念が現場で上手く根付かないのか？

今僕が現場を見て認識する組織的課題は「製造業では、スプリントの単位で仕事していない。だからLycheeが提供するカンバンやバックログを利用するメリットをメンバーは感じていない」だ。
製造業でもマイルストーンはあるが、ソフトウェア開発におけるアジャイル開発の概念と根本的に異なると感じている。
僕が設定したRedmineバージョンでアジャイル開発をやろうとしても、製造業のメンバーは理解がしっくり来ず、運用できていない。
ソフトウェア開発では、スプリントに収まるタスク量をスコープ調整することで、スプリントを意識しながら作業できる。
しかし製造業ではWF型開発の観点が強いので、マイルストーンを決めると、マイルストーンに従ったスコープは確定して変更できない。
そこで、バッファを持たせてタスク管理しようとするが、よくあるようにバッファをすぐに食い潰す。
製造業でアジャイル開発をやるにはマイルストーン管理、スプリントの実装が必要だが、何か上手くいかない。

【5】もう一つの問題もある。
製造業では、大日程計画のマスタスケジュールに基づくタスク管理と、突発的な作業依頼や月次報告のためのタスク管理が混在するので、実際のタスク管理は二重管理になっている。
詳細はこうだ。

一般に、大日程計画のマスタスケジュールは顧客と締結する。
いつまでに設計が終わって製造を開始して、半年後、1年後に納品します、と顧客に提示する。
顧客に提示するマスタスケジュールは、小日程計画レベルのような細かいスケジュール表ではない。
月次レベルの荒いスケジュールであり、パワポやExcelのポンチ絵だ。
このマスタスケジュールがベースラインとなる。
製造業の社内でも、承認されたスケジュールとして保管されて、ISO9001のような監査でも使われるだろう。
つまり、大日程計画のマスタスケジュールは、顧客向け、監査向けのタスク管理だ。

一方、日々の詳細なタスク管理もある。
僕はチケット駆動開発が好きなので、製造業の現場であっても、メンバー自らチケットを発行してタスク管理を促している。
製造業の担当者もチケット管理に慣れると、自分のTODOみたいにどんどん書き出して、作業漏れを無くすように自ら動く。
また、製造業のタスクは先行後続関係が生まれるケースが多いので、彼らはRedmineチケットの先行・後続関係を使い始める。
LycheeRedmineのガントチャート画面は、先行後続関係を簡単に紐づけできるUIなので、彼らは率先して使い始める。
LycheeRedmineのクリティカルパス機能、Redmine標準のイナズマ線を使えば、ガントチャート画面上で、最優先でやるべきタスクが分かるし、進捗の遅延があるか否かを判別できる。
製造業の彼らも、Redmineのチケット管理に慣れると、こういう機能を自ら使い始めて、進捗管理を始めてくれる。

しかし、僕は、この日々のタスク管理はマスタスケジュールに故意に連動させない運用にしている。
なぜならば、せっかくチケット駆動でやり始めたタスクを大工程に紐づけると、親子チケットが発生し、WBS100%ルールに縛られて、大工程の予定期間や予定工数が上書き更新される状況が発生するからだ。
大日程計画のマスタスケジュールは顧客と握ったものだから、勝手に予定の期間や工数を変えるべきではない。

他方、大工程のマスタスケジュールと日々の詳細なタスクを紐づけたとして、WBS100％ルールを課さない設定で運用すると、マスタスケジュールよりも遅れたチケットが発生し、予実管理の意味がなくなる。
マスタスケジュールより遅れたチケットがあるならば、マスタスケジュールを更新すればよいだろうが、顧客と交渉して変更する必要があり、それは非常に難易度が高いことは誰でも知っている。

つまり、顧客に見せた綺麗な大日程のマスタスケジュールと、案件にあるチーム内のタスク管理で二重管理が発生する。
わざわざ連動させようとすると、チケットメンテ工数が肥大化するし、その管理工数はそもそも案件の目的に沿わない作業になるので無駄だ。

よって、製造業のタスク管理をRedmineでチケット管理しようとすると、PM層や顧客にきれいに見せるガントチャートと、メンバーが日々作業するチケット管理の２種類が混在するようになる。
これらを上手く管理する方法が僕にはまだ分かっていない。

【6】製造業でRedmineバージョンが上手くいかない理由は何か？

１つ目は、すでに上記で書いた。
製造業には、スプリントでスコープ管理する発想がないこと。

２つ目も、すでに書いた。
大日程のマスタスケジュールと日々のチケット管理という二重管理が発生している状況に対し、Redmineバージョンを大日程のマスタスケジュールや日々のチケット管理にどのように割り当てるべきなのか、という問題がさらに状況を複雑化させているからだ。

３つ目は、以前発表したように、製造業のタスク管理でマイルストーン管理を行う場合、メカ・エレキ・ソフトのような機能別組織があるために、マイルストーンを階層化する複雑性が発生するからだ。

第29回東京Redmine勉強会の感想～今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet: プログラマの思索

how-we-operated-ticket-driven-development-in-jira-pdffrom akipii ogaoga

【7】ソフトウェア開発では上手くやれるアジャイル開発を製造業の現場で上手くやるには何が必要なのか？
それは、Redmineバージョンをいかに製造業のタスク管理に実装できるか、が鍵を握る。
そのためには、上記の３つの問題を解決しなければ、本来のチケット管理の良さを引き出せないだろう。

今後も考える。

Redmineはチェンジマネジメントのツールであるべきだ

Redmineは単なるタスク管理ツールではない。
その真の価値は、チームを自己組織化へ導き、組織文化を変革する「チェンジマネジメント」の力にある。
メンバーが自律的に躍動する組織をどう創るのか。Redmineを用いた真の組織変革の可能性と実践アプローチを探求する。

【1】Redmineとは結局何だろうか？
Redmineを導入する目的は色々あるだろう。

【2】たとえば、メンバーがExcelでのタスク管理は上手くいかないし、何度やっても混乱する。
そこで、Redmineを導入してみると、TODOリスト代わりに使い始めて、じきに積極的にチケットを発行してクローズするうちに、開発のリズムが出てくる。

たとえば、管理者目線で、チームの作業を見える化したい。
そこで、Redmineを導入してみると、各メンバーの作業が一目瞭然で分かるし、昨日の実績や本日の作業予定もすぐに分かる。
秘伝のタレのようなプログラム開発だけやっていた人は、最初は重宝されていても、チームの中で作業を可視化されると、その人の貢献度合いはそうでもないと分かり、自然にチームは整理されて、新たに生まれ変わる。

たとえば、品質管理部門やPMOが、複数案件のQCDを管理し、プロセス改善したい。
そこで、Redmineを導入してみると、各案件ごとに全く異なる活動が見える化される。
各案件のチケットをCSV出力して、定期的に分析すれば、各チームの傾向も見えてくる。
そこから、課題を抽出し、プロセス改善のアイデアが生まれる。

【3】このように、Redmineはいろんな立場で導入して成果が出てくる。
しかし、それだけなのだろうか？

Redmineエバンジェリストとして、Redmineの伝道師として、熱くなって、Redmineを導入し、組織を変えようとしたい。
そんな時に、たったそれだけの成果を求めているのか？

【4】そうではないはずだ。
Redmineを導入し運用するのは、単にタスク管理が楽になるとか、管理者がメンバーを管理しやすくなる、という目的だけではない。
僕は、Redmineというツールを導入すれば、単なる一ツールではなく、メンバー自身が活き活きと活躍し、チームが自己組織化し始めて、組織を活性化させるチェンジマネジメントのツールであるはずだ、と思う。
つまり、Redmineを真に有効活用すれば、組織文化を変革し、組織そのものを変革させるチェンジマネジメントのツールになりうる。

組織文化を変えることは非常に難しい。
大企業になれば尚更だ。
大きな組織になるほど、組織文化が足かせとなり、イノベーションを起こせなくなる。

【5】しかし、Redmineというツールは単なるツールではない。
Scrumを導入し真に活かせた組織では、組織文化が変わり、チェンジマネジメントを行えた実績がある。
同様に、僕も、Redmineが単なるタスク管理ツールではなく、メンバー自身の行動が変わり、チームが自己組織化を始めて、自ら動き始める、という光景を何度も見てきた。
つまり、Redmineはチェンジマネジメントのツールであるはずだ。

【6】チェンジマネジメントを行うために、Redmineをどのように有効活用すべきなのか？
その方法を今模索している。

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利用成熟度モデルが使えると考えている。

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