Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア

かつてアンチパターンとされたRedmineの工程別プロジェクト運用。
だが、A-SPICEなど厳格なトレーサビリティが求められる現場では、ブロッキング機能（FF関係）による制御が強力な武器となる。
製造業の複雑な階層構造に挑む、Redmineの新たな運用アプローチを探る。

Redmineプロジェクトを工程別に分けて運用したい意図を理解したのでメモ。
ラフなメモ書き。

【参考】
Redmineのブロッキング機能はどこで使うのか？～FF関係で使うべきだ！: プログラマの思索

【1】Redmineプロジェクトを工程別に分けて運用したいケースがある。

WF型開発で要件定義、設計、開発、テスト、移行の順に工程ごとにタスクが分かっていて、各タスクは上位の工程から派生して関連付けられて追跡できる前提とする。
たとえば、組み込みソフトウェア開発において、ISO規格、A-SPICEなどの規格に沿って開発し、その結果を商標と残すべき要求があるとする。

特に、A-SPICEのソフトウェア開発プロセスではV字型モデルで定義されていて、各工程のエビデンスをきちんと残すことを義務付けられている。

では、Redmineではどのように仕組みを実装すべきか？

一つのやり方として、工程別にRedmineプロジェクトを作り、各工程プロジェクトにタスクを作り、下位チケットは上位チケットに関連付けて作成する運用とする。
たとえば、要件定義チケットがあれば、そこから画面設計、機能設計、I/F設計、帳票設計、DB設計などの下位チケットが作られるだろう。
それら下位チケットは、上位の要件定義チケットに関連付けたタイミングで新規作成する。
すると、下位チケットを作成するタイミングで作業開始出来たことが分かる。

一番重要な点は、トレーサビリティが確保できることだ。
設計、開発、テスト、移行工程の各チケットは、必ず上位工程のチケットから関連付けられて作成するので、たとえば、リリース後に不具合が発生すれば、過去のチケットから上位工程に遡って影響調査することが簡単になる。
また、A-SPICEなどの規格では、ソフトウェア監査においてトレーサビリティをすごく重視するので、関連チケットを追跡できれば監査エビデンスを探し出す時に非常に有効になる。

つまり、工程別プロジェクトの運用では、「下位工程の作業チケットは上位工程の作業チケットに関連付けた時に新規作成する」制約条件が発生する。

【2】では、この工程別プロジェクトのRedmine運用において、他の重要な制約条件は何があるだろうか？

最も重要な制約条件は「上位工程の作業チケットが完了していなければ、関連付けられた下位工程の作業チケットは完了できない」だ。

たとえば、外部設計において、一つの要件から画面帳票設計、I/F設計のタスクが関連付けられて、どれかのチケットが作業完了できる状態になったとする。
しかし、1つの要件のチケットにおいて、顧客要求から要件定義がきちんと完了し、要件チケットをクローズできなければ、次工程の作業を完了に出来ない。
なぜならば、顧客要求からまだ要件定義が完了できていない状態は、まだ漏れている要求があるかもしれないし、非機能要件の品質特性を全て洗い出したとは言えないからだ。
漏れている要求があれば、下位チケットにはその要求は反映されていないのは当然だ。
ソフトウェア開発において、機能の実装漏れが出てくる場合は、たいていこんな単純ミスから発生する。

よって、下位チケットをクローズする時に、上位チケットのステータスを見て、クローズ条件を制御する必要がある。

この条件は、PMBOKで言う「FF関係」に相当する。
つまり、「上位チケットが終了できなければ、下位チケットも終了できない」条件に相当する。

利用シーンとしては、ガントチャートでタスクの依存関係に「完了の同期」を強制させたい場合がある。

【3】では、この機能はRedmineではどのように実装されているのか？

具体的には「ブロック元のチケットがクローズできなければ、ブロックされているチケットはクローズできない」機能になる。
この機能はまさに、Redmineのブロッキング機能に相当する。

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

関連するチケット ? Redmine用語解説
チケット同士の関連づけ | Redmine.JP Blog

たとえば、FF関係にある2つのチケットは、「ブロックしているチケット#11のステータスが終了でなければ、ブロックされているチケット#12のステータスを終了に変更することができない」例がある。

よくある例は、リリース判定レビューのチケットがあるだろう。
リリース判定レビューをクローズさせるには、もちろん、要件定義～移行までの全てのタスクを終わらせる必要がある。
たとえば、バグ修正が追いつかず、バグが1間残っています、とか、全部テストできておらず10件のテストケースが残っています、みたいな状態でリリースできるわけがない。

一方、炎上案件では、まだテスト中、バグ修正中だが、並行作業でリリース判定レビューを実施して、後追いでリリース判定の承認を得たい場面が割とある。
PMOレビュー事務局を経験した人ならよく分かるだろう。

すると、リリース判定レビューでは、テストケース残件が０件、バグ未解決件数０件ならばリリースを認めるといった、条件付きOKの判断が下る場合が多い。
案件のPMもPLも担当者も、リリース判定レビューの後も、必死になってテストしてバグを潰して、その結果をPMOレビュー事務局へ送って、その結果がOKならば、テストや移行作業のチケットが全て完了にできる。
そして、テストや移行作業のチケットが全て完了になった状態で、初めて後続のリリース判定レビューチケットをクローズできて、ようやくリリース承認が降りるわけだ。

このような制御をRedmineチケットに課すことで、実際の運用ルールを知らなくても、監査プロセスをRedmine上に実装できる。
僕は、Redmineのブロッキング機能をFF関係として使うケースを知らなかったので、本当に面白いなと思う。

一方、Redmineのガントチャート画面では、【FS】関係は、先行・後続の関係＝青矢印、【FF】関係はブロック元・ブロック先の関係＝赤矢印で図示される。
つまり、Redmine標準機能として、FS関係とFF関係の矢印の色が異なるように実装されているので、ガントチャート画面を見れば、チケットの依存関係を把握できる。
LycheeRedmineでは、ガントチャート画面上でマウスをD&DすることでFS関係を付けれる機能があり、そのタイミングで、ブロッキング機能をチェックするかどうか選ぶダイアログが出てくる。
つまり、LycheeRedmineでは、FS関係やSS関係を簡単につないで、まるでMSProjectみたいにガントチャート画面上で制約条件を正確に表現できる。

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

Redmineはとても奥深い。

【4】以前の僕は、Redmineを工程別プロジェクトを作るやり方は悪手だと思っていた。
その理由は１０年以上前にたくさん書いた。
つまり、理由は、アジャイル開発のイテレーション、スプリントに紐づけることが単純でないこと、工程単位のプロジェクトが乱立して１人の担当者が複数のRedmineプロジェクトを渡り歩いて見る必要があってチケット管理が面倒になるからだ。

TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

チケット駆動開発の適用範囲part5～どの工程をカバーするのかという質問: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪: プログラマの思索

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

チケット駆動開発がもたらした新しい観点part1～Redmineプロジェクトへ案件や組織構造を反映する: プログラマの思索

Redmineをもっと強化できるポイントpart1～上流工程のトレーサビリティ強化: プログラマの思索

しかし、上記のように、Redmineブロッキング機能を使って各工程チケットのトレーサビリティを確保したい場合、工程別プロジェクトを作りたい意図は理解できる。
また、Redmineブロッキング機能は所詮、Redmineの関連チケットの一種に過ぎないので、担当者にとってもチケット操作は簡単であり、運用ルールに乗せやすい。

こういう使い方もありだなと思う

【5】一方、留意点としては、複数プロジェクトをまたいでチケット同士のブロッキング機能を使うには、「管理」→「設定」画面内「チケットトラッキング」タブ内の設定「異なるプロジェクトのチケット間で関連の設定を許可」を有効にする必要がある。
この設定がなければ、プロジェクト内で閉じたチケット同士でしか、ブロッキング機能が使えない。
先行・後続関係の機能も同様だ。

Redmineで異なるプロジェクトのチケット同士を関連づけたい ? Redmine.JP

他方、「異なるプロジェクトのチケット間で関連の設定を許可」を有効にするデメリットは、情報セキュリティの高い案件のRedmineプロジェクトのチケットが関連付けられてしまうケースが考えられる。
本来は、ある案件の親PJがあり、要件定義～移行の子PJが作られて、親子PJの関係が付けられている範囲内でのみ、ブロッキング機能を有効にしてほしいのだ。
製造業のように、製品開発の案件は機密性が高いので、情報セキュリティ上、他案件のチケットが無関係の社員に見せることはしたくないからだ。

すると、「プロジェクトツリー内のチケットはで関連チケットの設定を許可する」「プロジェクトツリー内でカテゴリ、カスタムクエリ、ユーザを継承できるようにする」機能が欲しくなる。
そのアイデアは既に書いた。

製造業DXを支える工程管理とは？Redmineの大規模プロジェクト階層化における課題：プロジェクトツリーの設定継承と関連チケット制限の壁: プログラマの思索

@g_maedaさんにXで聞いたら、そんな機能はありません、の一言で終わったけれど、正直実装してほしい機能だ。
なぜならば、製造業では、親子PJを使って階層化したRedmineプロジェクトが自然に出てくるケースが多いので、プロジェクトツリー内の各プロジェクトの各チケットに対し、親PJの設定を子PJへ継承させたいケースが多くなるからだ。

たとえば、製造業では、上記のように工程単位プロジェクトが自然に出てくる。
工程単位プロジェクトが自然な理由は簡単で、製造業では工程ごとに専門部署が割り当てられているからだ。
実際、プロトタイプ製品を作る企画フェーズならR&D部、設計工程では設計部門、製造工程では工場の製造部門や生産管理部門、試験工程では品質管理や品質保証部門、サービス保守では営業部門や保守部隊などに分かれる。
製造業は、高度に専門化された知識が必要なので、機能別組織になりやすく、工程別にノウハウを集約し蓄積する機能別組織になりやすい。

また、たとえば、複数の製品を組み合わせて一つのシステムを作り、それをパッケージングして販売するSystemOfSytems（SoS）のようなサービスも製造業ではよくある。
たとえば、医療システム、防衛宇宙システムの業界ならよくあるだろう。
すると、SoSの親PJが案件に相当し、子PJには各製品や各システムが作られて、さらに孫PJは工程単位のプロジェクトが作られる。
つまり、親子孫という３階層のプロジェクトツリー構造を持つRedmineが自然に現れる。
よって、SoSの案件をRedmineで運用する場合、かなり複雑な構造をRedmine自体が持つ。
実際、プロマネが１個のRedmineプロジェクトでチケット管理できないマネジメントレベルならば、そもそも３階層のRedmineプロジェクトを持つ高度なチケット管理はできないだろう。
すなわち、SIerで僕が経験してきたアジャイル開発のRedmine運用よりも、製造業のRedmine運用のほうがはるかに難易度は高いと考える。

製造業のRedmine運用がかなり難しい理由は、実はこんな点にあるのかなと思う。
今後も製造業のRedmine運用を探っていく。

第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の成果物は品質基準を超過しすぎる

「人の成果物は品質基準に不足しすぎるが、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】このアイデアをもっと試してみたいと思う。

チケット駆動で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へ監査プロセスの適用を当てはめなければ、上手くいなかいだろうと直感する。

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

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

製造業でアジャイルが定着しない理由～スプリント不在とチケット二重管理の壁 #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利用成熟度モデルが使えると考えている。

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

なぜCCPMは挫折する？経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine

製造業の管理職、経営者と話していると、彼らはTOCやCCPMが大好きだ。
確かに、TOCの発想はアジャイル開発にも通じるし、TOCの考え方は生産効率の向上にも使える。
CCPMの考え方も、ガントチャートの工程管理では有用だ。
しかし、実際の現場でTOCやCCPMを使おうとすると、ほとんど失敗する。
教科書通りの運用がとても難しい。

そこで、なぜ製造業の経営者はTOCやCCPMが大好きなのか、考えてみた。
ラフなメモ書き。

【参考】
Amazon.co.jp: TOC/CCPM標準ハンドブック クリティカルチェーン・プロジェクトマネジメント入門 : 西原 隆, 栗山 潤: 本

Project Management進化論 クリティカルチェーン・プロジェクトマネジメント | 後藤 智博, 渡瀬 智, 西郷 智史 |本 | 通販 | Amazon

最短で達成する 全体最適のプロジェクトマネジメント | 岸良裕司 |本 | 通販 | Amazon

【1】なぜ製造業の経営者はTOCやCCPMが大好きなのか？

理由は2つある。
1つは、ボトルネック工程を見つける発想が製造業の工程管理と相性が良いこと。
もう1つは、CCPMのフィーバーチャート分析を使えば、事業部内の全ての案件からバッファを集めてマネジメントバッファに集約することで、事業部内の要員管理に役立つことだ。

前者については当たり前だろう。
後者について考えてみる。

【2】TOCの理論を実際の現場でPJ管理に使おうとする場合、CCPMを適用することになる。
では、CCPMの本質とは一体何だろうか？

CCPMの本質は全てのタスクの残工数、つまりバッファをPJバッファに集約し、プロマネが一括管理して、PJ管理の進捗をコントロールする点にある。

CCPMでは、各タスクを見積もった時、各タスクの予定工数からバッファをバッサリ切り捨てて短縮する。
教科書では、各タスクが予定通りに終わる確率が50％になるまで、予定工数をバッサリ切り捨てる。

各タスクのバッファはPJバッファとして一括集約し、プロマネが管理する。
プロマネは、各タスクが遅れたら、PJバッファから余った工数を渡して、本来の予定工数通りに終了させる。

もちろん、各タスクがバッサリ切り捨てた予定工数で完了できれば、問題ない。
むしろ、担当者がサバを読んで見積もりを膨らませたことになるだろう。

プロマネは、PJバッファの出し入れを管理することで、PJの進捗管理を行う。
プロマネは、時系列でPJバッファ消費度合いを見ることで、PJのリスクを管理することになる。

そこで、フィーバーチャートを使って、PJが危険な領域に入ったか否かを定量的に判断する。
フィーバーチャート分析では、PJ進捗率ｘPJバッファ消費率のグラフを見て、PJ消費率が異常に高すぎるゾーンに入ると危険とみなし、早めに対策を打つべきだ、という意思決定に使う。
大抵の案件では、仕様変更や手戻り作業で当初の予定よりも遅延する場合が多いので、PJバッファをどんどん消費してしまう。
もちろん、PJバッファを全て使い切れば、予算オーバーの案件になる。

ここまでは、CCPMは一般的なPJ管理の手法だ。

CCPMがすごい点は、複数の案件の現状をフィーバーチャートにプロットし、その経緯をグラフ化することで、複数の案件管理を横串で意思決定できる点だ。

つまり、事業部内の全ての案件のPJバッファを集約することで、PJバッファをマネジメントバッファとみなし、事業部内の余裕リソースをどの案件に割り当てればよいか、という意思決定に使える。

ここで、
事業部内のマネジメントバッファ＝ΣPJバッファ＝ΣPJの各タスクの予定工数
より、
事業部が持つマネジメントバッファ費用＝ΣPJの各タスクの予定工数ｘ人月単価
になる。
一般に、事業部が持つマネジメントバッファ費用は、製造業ならば当初予算からリスク費用として取り出し、別で保持しているだろう。
一般に、リスク費用は、どこかの案件で赤字になってリカバリーする場合や、戦略的な案件に投資として使いたい場合などに使うだろう

よって、事業部が持つマネジメントバッファ費用、つまりリスク費用は、事業部長が戦略的意思決定で用いるお金に相当する。
このリスク費は、事業部長という強力な権力を持つ人だけが使える「へそくり」みたいなものだ。
へそくりであるからには、むやみやたらに使うべきではなく、大事な状況で使うべきだ。
それが、事業部長の戦略的意思決定に相当する。

すなわち、CCPMを事業部内の案件管理で使いたい欲求は、事業部長がリスク費用を事業部内の要員管理として意思決定する時に、定量的な根拠して使えるからだろう。

【3】しかし、CCPMの運用はExcelでやるのは事実上無理だ。

まず、残工数を入力する運用は現場で浸透させづらい。
残工数を把握するには、タスクの予定工数を見積もる能力、実績工数を入力する運用がセットになる。
そもそも、正確に見積もり工数を出せる担当者は少ない。
また、各タスクの実績工数を入力させる運用は、現場では非常に面倒だ。
1日のタスクは10個以上に及ぶときもあるから、勤怠時間と照合させようとすると破綻する。

次に、案件にある各タスクの残工数を収集し、PJバッファに集めて、PJバッファ消費率を追跡する処理は実装しづらいからだ。
Excelではフィーバーチャートをプロットするのは非常に難しい。
データを1個のシートに集めればフィーバーチャートを描けるだろうが、綺麗に出力しようとすると、Excelマクロを駆使することになるだろう。
本気でやれば、ExcelマクロでCCPMツールを自作するくらいのレベルになるだろう。
よって、CCPM専用の管理ツールをパッケージ製品やSaaSで利用することになるだろう。

しかし、CCPM専用の管理ツールは非常に高価であり、UIがダサくて使いづらいツールが多い。
肝心のガントチャート画面で操作がモッサリしていたり、WBS詳細化する操作が使いづらかったり、WBSの属性を登録する手間が多すぎたりして、使いづらいケースが多い。

結局、CCPMは教科書ではすごいけれども、実際の現場では使えないね、という結論になる。

【4】一方、CCPMを運用するツールの一つとして、LycheeRedmineのCCPMプラグインは使いやすいツールだろうと考える。
なぜならば、Redmineのチケット入力機能を上手く流用することで、CCPMが持つ複雑さを和らげて、CCPMを運用しやすくしているからだ。

CCPMツールならLychee Redmine｜フィーバーチャートでバッファ消費率を自動で可視化

LycheeRedmineでは、CCPMを運用したい時に上手く工夫されている機能がある。
たとえば、残工数を入力するIFとしては、チケット属性の「残工数（Lychee）」になる。
チケット属性の「残工数（Lychee）」に入力すれば、各タスクの残工数を把握できる。

LycheeRedmineでは、Redmine標準の予定工数・実績工数の機能を流用し、残工数を集めて、フィーバーチャートへ自動集計してくれる。
LycheeRedmineのCCPM設定画面では、「日次バッチでフィーバーチャート分析する」設定をONにすれば、日々でフィーバーチャートをプロットしてくれる。

LycheeRedmineのCCPM設定画面では、PJバッファをPJからどれくらい集めるかを設定する機能、フィーバーチャートの危険・警告・正常領域の閾値を設定する機能があるので、色々カスタマイズできる。
さらに、バージョンごとにPJバッファを登録する機能があるので、たとえば、各工程ごとにバッファを設けて、バッファ消費率を追跡する運用も可能だ。

フィーバーチャートを出せれば、プロマネはPJリスクを定量的に意思決定できるようになる。
これがやりたいことだ。

ただし、CCPM運用の前提は、作業者がチケットの残工数を毎日入力する運用を徹底できていることだ。
そこさえクリアできれば、教科書でしか運用できなかったCCPMが、Redmineの優れたチケット管理を使って簡単に運用できるようになる。

【5】そんなことを思うと、LycheeRedmineは非常に優れたツールだと思う。

なぜならば、Redmine標準の優れたチケット管理機能を流用して、CCPM運用をよく考えて機能実装できているからだ。
LycheeRedmineでは他にも、Scrumに特化した機能、つまり、カンバンやバックログもあるので、Scrumも運用可能だ。

Lychee Redmine、アジャイル開発向け新機能「Neoカンバン」をリリース| 株式会社アジャイルウェア

すなわち、LycheeRedmineを使えば、各PJでテーラリングすることで、CCPMをやるPJもあれば、ScrumをやるPJも併存して運用可能だ。
これはすごいことだと思う。

【6】LycheeRedmineの機能については、別記事で詳しく解剖してみたいと思う。