JTCの壁を壊す「Redmine参謀本部」という戦略～現場の職人気質を活かす組織論

redmine.tokyoでのJTCとの対話から見えたのは、硬直化した管理と現場の職人気質のジレンマだ。
激変する製造業に今こそアジャイルが必要である。
マイクロマネジメントを脱し組織力を高める鍵、それを提供する「Redmine参謀本部（AMET）」という新たな運用戦略を紐解く。

【参考】
アドレナリンジャンキー プロジェクトの現在と未来を映す

Amazon.co.jp: 組織パターン (Object Oriented SELECTION) : James O.Coplien, Neil B.Harrison, 和智 右桂: 本

エンジニアリングマネージャーのしごと

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

【1】前回のredmine.tokyo勉強会の休憩時間で、いわゆるJTCの人達と色々話し込んだ。
やっぱり愚痴が多くなる。
せっかくRedmineと環境を用意しても、社員がなかなか使ってくれない。
標準プロセスや標準ワークフローで縛ると、不満が多くなる。
一方、JTC内部で各PJにRedmine環境をホスティングすると、開発プロセスが乱立し、Redmineのバージョンアップも難しくなる。

【2】製造業では、マスタスケジュールに基づく工程管理が基本だ。
つまり、ガントチャート画面で予実管理したい。

しかし、現代では製造業と言えども、ホルムズ海峡の石油不足、半導体不足、サプライチェーン激変などの外部環境変化により、当初立てた計画通りに進捗管理もままならない。
しかも、顧客からの仕様変更、注文も頻繁に起きているので、製造リードタイムが長い製造業ほど、顧客満足させるために凄く苦労する。
つまり、量産品であれ、特注品の製造業であれ、いずれもアジャイル開発が必要とされている。

【3】一方、日本のSIerでは、プロジェクトマネージャやプロジェクトリーダーのような手配師が重宝される。
しかし、やっぱり日本人の気質は職人だ。
だから、プログラマとしてエンジニアとして、技術を磨く方が好きな人が凄く多い。
エンジニアであれば、やはりアジャイル開発がしたい。
でも、マネージャやリーダーは、マイクロマネジメントしたがるので、どうしても衝突しがちになる。

【4】このような状況は、製造業でも同じだ。
製造業でもマネージャのようなマネジメント能力の優れた人が重宝されるが、ほとんどの真面目な社員はエンジニア気質だ。
製造業なので、メカ・エレキ・ソフトのいずれかの技術に長けた人が多い。
彼らはマネジメントなんかよりも、技術を磨きたい気持ちが強い。

【5】そんなマネジメント環境において、Redmineをどのように利用して、組織のマネジメント能力をどこまで目指すべきなのか？
Redmineをマイクロマネジメントのツールではなく、個人の能力を活かし、チームとして一体感を醸成し、組織のマネジメント能力を上げるには、何が必要なのか？

直感的には、Redmine参謀本部が必要だ。
いわゆるRedmine運用事務局、Redmine運用推進部をもっとかっこよく言った部署が、Redimne参謀本部だ。

Redmine参謀本部の役割は、Redmine運用の戦略を策定し、高性能なサーバや開発能力を調達し、JTC内部に展開するための組織体制を整備して、推進していくことだ。
つまり、参謀本部であるから、軍事戦略の策定、兵站というロジスティックスやリソース調達、そして、将校や兵隊の教育訓練の役割を担う。

Redmine参謀本部が協力に動くからこそ、JTCという古い組織であっても、それなりにRedmineを運用し活用できる。

【6】Redmine参謀本部は、「アーキテクチャモダナイゼーション」に出てくる「AMET（Architecture Modernization Enabling Team）」に似ている。
各プロジェクトを技術的にもマネジメント的にも支援する役割だからだ。

Redmine参謀本部という考え方を使って、JTCにおけるRedmine運用の戦略をどのように立てるべきなのか？を考えていきたい。
まずJTCでは、Redmine参謀本部を作れ！

第30回東京Redmine勉強会の感想 #redminet ～古いチケット管理基盤にAIという新しい衣を被った未来

Redmine誕生20周年。AIの登場により、入力支援や意思決定、プロジェクト診断など、長年の課題解決に新たな光が差し始めた。
古いチケット管理基盤にAIという新たな衣をまとうことで、これまでにない斬新な解決策が見えてくる。
進化し続け、決して飽きることのないRedmineの未来と可能性を考察する。

【参考】
第30回勉強会 - redmine.tokyo

2026/5/16 第30回勉強会 - redmine.tokyoのツイートまとめ #redmineT - posfie

【1】今年は、東京Redmine勉強会も30回目、Redmineも20周年の節目の年。
LT含めて13本の講演があって、17時まで長かったのに飽きることもなかった。

Redmineコミュニティも16年やってきて飽きる所か、AIが出てきて今までの考え方と異なる運用が見えてきたと思う。たとえば、AIによるデータ分析、AI要約、PJ診断、意思決定支援、入力支援とか。
RedmineにAIを適用すると、どんな方向性に可能性があるのか？

【2】方向性は２つある。
一つは
もう一つは、傾向分析や意思決定するための情報濃縮。

実際、Redmine運用を推進するときの課題は従来から2つあった。
1つは、担当者がチケット入力する手間を下げること、チケットにナレッジを集約する手間を減らすこと。
管理者がチケット集計する作業の手間を省くこと、

もう1つは、チケット集計機能の強化により、データ分析強化による意思決定支援。
ワークフロー管理機能の強化により、運用プロセスの基盤を整備し標準プロセスを確立すること。

前者はRedmineナレッジ化の動機づけ。
後者は管理者の意思決定支援やプロセス基盤の確立。
いずれも今までのRedmineそのものが抱える課題は変わらない。

【3】しかしAIが、難易度が高い対策の実現可能性の敷居を下げてくれてる。
AIと言う最先端の技術が、今までの古い課題解決に新たな観点で焦点を当ててくれてる。

たとえば、入力機能や管理作業の効率化支援では、AIによる入力補完、AI要約、類似チケット検索など、色んな手段が簡単に実装できる。
たとえば、管理者の恣意決定支援やプロセス基盤の確立では、AIによるデータ分析、PJ診断レポート、組織のプロジェクト管理能力に応じた運用プロセスの提案とか、AIで簡単に実装できるだろう。

つまり、Redmineという古いチケット管理基盤に、AIという新しい衣を付けただけの話。
なのに、AIを導入することで、従来の課題に対するAIの解決方法がとても斬新で面白い。
いつになってもRedmineは飽きない。

【4】初めての人とツイートしてとても興味深い内容をやり取りした。
履歴として残しておく。
3層構造の観点がすごく参考になる。
インスパイアされそう。

Xユーザーのあおのうまさん: 「@akipii そこいら鍵になるのがOntology による意味構造の提供 とskills による行動形態の方向付けだと考えています。 ただ、Ontology は基本的にグラフ構造になるので、Redmine の現状建て付けだと、ちょっと苦しいかも。 そこいらはどこを境界線とするか悩ましいですね。」 / X

Xユーザーのakipiiさん: 「@uma_blue この三層モデル、レイヤー化アーキテクチャ興味あります。コントロール、マネジメント、プレゼンテーションの各層の定義教えてください。多分手垢のついた言葉なので認識揺れ起きてるため」 / X

Xユーザーのあおのうまさん: 「@akipii タスクの捌きに係る領域がコントロール。 リソースの調整に係る領域がマネジメント。 全体の可視化と認識共有に係る領域がプレゼンテーションです。」 / X

Xユーザーのakipiiさん: 「@uma_blue 各層の依存関係は、プレゼンテーション->マネジメント->タスク　で認識合ってますか？　各層をキックするアクターは、依存関係の順に、経営層＞管理職層＞現場担当者層で認識合ってますか？　各層は独立しておらず依存関係があり、依存関係以上の密接な関係があるように直感します」 / X

Xユーザーのあおのうまさん: 「@akipii プロジェクトに関わる人間のロール間でこれらは結構グラデーションになる事が多く。 結果として、ときどきどこに比重を置くかで、情報の扱い方や粒度を切り替えたいニーズがあります。 そこの同期あるいは連結には、静的な関数というより前後文脈と状況をパラメータとした動的な処理が要る。」 / X

Xユーザーのあおのうまさん: 「@akipii AI ならそこいら上手く埋められそうかなと夢想しています。 実際に手を動かしてみたわけではないので、とんだ的外れである可能様あるのですけれど。」 / X

Xユーザーのakipiiさん: 「@uma_blue 3つの層ではそれぞれの特有の課題があり対策も異なる。AIを使えば、対策の実現可能性が高まる。各層の課題へAIを適用する手法そのものも異なるでしょう。この辺り整理分類したい。AIの要件をまとめられれば、AI実装仕様も決まってくるでしょう。」 / X

Xユーザーのあおのうまさん: 「@akipii そこいら鍵になるのがOntology による意味構造の提供 とskills による行動形態の方向付けだと考えています。 ただ、Ontology は基本的にグラフ構造になるので、Redmine の現状建て付けだと、ちょっと苦しいかも。 そこいらはどこを境界線とするか悩ましいですね。」 / X

製造業がRedmine導入で必ず聞く3つの質問～MS Project派がRedmine導入で悩むこと

製造業でRedmineを導入すると、必ずぶつかるのが「MS Projectの代わりになるのか？」という壁。
製造業の現場は、工程管理と階層的な進捗管理が前提。
Redmine導入で問われるのは、機能ではなく運用思想の違いだった。
製造業の現場がRedmineに求める本当の期待を整理する。

【参考】
コンサル一年目が学ぶこと ビジネススキル本

入門Redmine第6版

逆引きでわかる！ Redmineハンドブック バージョン5.0対応 | 川端 光義 |本 | 通販 | Amazon

Amazon.co.jp: Redmineによるタスクマネジメント実践技法 : 小川 明彦, 阪井 誠: 本

Amazon.co.jp: チケット駆動開発 : 小川 明彦, 阪井 誠: 本

【1】とある製造業界のメーカーにRedmineを初めて導入しようとした時、3つの質問を受けた。
これらの質問に回答しながら、質問の背景にはどんな構造があるのか？と考えた。

【2】バージョンはガントチャートでツリー構造に表示できるのか？

答えはYes。
Redmineのガントチャートでは、プロジェクト＞バージョン＞チケットの順にツリー構造に表示される。
彼らの意図には何があるか？

製造業では、基本的に、月次レベルの大日程計画というマスタスケジュールを作る。
マスタスケジュールはマスケともよく言われる。
そのマスケから、週次レベルの中日程計画、日次レベルの小日程計画へ詳細化していく。
それらスケジュールは、マスケに書かれた工程をベースに詳細化するので、工程管理する方針になる。
たとえば、設計工程、発注購買工程、製造工程、みたいになる。

つまり、彼らは、スケジュールを工程管理の道具として扱い、工程の進捗を管理したい。
その時に、工程という大枠での予実管理の視点、あるいは日々の作業レベルの日次進捗として管理したい。

注意点は、バージョンに何を当てはめるのか？になるだろう。
僕ならアジャイル開発の観点になるので、バージョンに工程を当てはめる。
工程には必ず期日があるので、ロードマップ画面で各工程ではどのタスクをやるべきか、が一目で分かる。

しかし、製造業ではツリー構造で5階層、10階層と深く階層化したい欲求があるので、バージョンだけでは足りない。
結局、バージョンを使わず、チケットのツリー構造だけで管理する方針になりやすい。

ただし、Redmineの標準機能では、ガントチャート画面で大日程に当たる工程へ折り畳みできない弱点がある。
しかし、解決策があり、LycheeRedmineを入れると、折りたたみが可能だ。

例えば、
設計（大日程）
├─ メカ設計
├─ エレキ設計
├─ ソフト設計
└─ プロセス設計
の状態で ▼ をクリックすると
親チケット（大日程）
のように、子チケットを非表示にして親チケットのみの一覧表示にできる。

つまり、LycheeRedmineを入れれば、大日程計画から小日程計画まで、一つのガントチャート画面で整理できるメリットがある。
彼らは、ガントチャート画面で全てを把握したい欲求がある。

【3】MSProjcetからRedmineへ簡単に移行できるか？

答えはYes。
ただし工夫がいる。
MSProjectからExcelへエクスポートし、Redmineチケットのフォーマットに合わせる必要がある。

また、Redmine標準のCSVインポート機能では、親子チケットのようなツリー構造でインポートできない。
親チケットNoが最初は採番されていないからだ。
そこで、Excelチケット一括のようなツールを使って、採番した親チケットNoを入れ直すなどして数回インポートする手順になるだろう。

Excelからチケットを作成・更新できる「Redmineチケット★一括★」 | Redmine.JP Blog

彼らの意図には何があるか？
たいていの大手製造業では、Redmine導入前では、MSProjectを使って、まさに大日程計画から小日程計画までスケジュールを組んでいた。
彼らにはその資産、ノウハウがたくさんある。
だから、その資産であるMSProjectファイルを流用したい。

注意点は、MSProjectでやってきた運用方法をRedmineにも適用できるか？という点があるだろう。
たとえば、MSProjectでは、ベースライン機能がある。
つまり、PJ計画時、仕様変更時、のように、当初のマスタスケジュールを変更する時に、スナップショットを残し、変更管理プロセスに乗せる。
あるいは、週次で実績を記入し、週次でスナップショットを変更履歴として残す。
そうすれば、いつでも前回差分により、予実管理しやすくなる。

Redmine標準機能にはそんな機能はない。
しかし、Lychee Redmine には MS Project のようなベースライン機能がある。
しかもこれは単なる概念ではなく、ガントチャート上で「計画時点のスケジュールを保存し、現在との差分を比較する」機能として実装されている。
つまり、Redmine上でも、日次・週次レベルで差分表示する運用にすれば、朝会や週次定例などで進捗報告にも使えるだろう。

【4】チケットではタスクとタスク内のチェックリストの違いは何か？

答えは、タスクは他人へ委譲できる作業。
チェックリストは自分だけの作業手順。他人に見せるものではない。

LycheeRedmineには、チェックリスト機能があるので便利だ。

彼らの意図には何があるか？
タスクをチケットで切っていく時、チェックリスト機能もあるので、どこまで詳細化すればいいのか迷う時が出てくる。
詳細化レベルは個人の能力に依存するので、いくらでも細かく切れる。
すると、個人レベルの作業手順まで分割してしまうだろう。
そうなると、チケット枚数が増えてチケット管理が煩雑になりやすい。

本来のチケット管理は、作業の引き継ぎ、作業の割り振りのように、自分の作業を他人に委託できるレベルにすべきだろう。
細かくするほど、余計な情報になりノイズになるからだ。

つまり、チームメンバーの能力が全員高ければ、ある程度荒い粒度のチケットで回せる。
しかし、個人の能力が低いほど、細かいチケットを切らざるを得なくなる。
細かい作業レベルでしか、結果を出せないからだ。

だから、チケットは引き継ぎや委託できるレベルの粒度とし、細かい作業手順はチェックリストに落として、必要であれば親子チケットで分割すべきだろう。

【5】そんなことを考えると、製造業特有のチケット管理の特徴が出てくるだろう。
彼らのスケジュール管理には、工程管理がベースにある。
その工程管理は階層構造でツリー構造で管理したい欲求がある。
だから、MSProjectと似たような管理がしたい。

そこから、Redmineのバージョンやかんばんを使ったアジャイルな開発スタイルと相性があまり良くない。
本来は、Redmineはアジャイル開発の基盤に実装されるべきだと思うが、Redmineは機能がとても柔軟なので、従来のようなWF型開発でも実装できる。
ハイブリッドな開発も目指せるだろう。

つまり、経営層や管理者にはWF型開発をやると見せかけて、実際の現場ではチケット管理でアジャイルに開発すればいい。
その辺りのやり方も考えてみたい。

RedmineのAI支援機能はチケット管理システムにとって重要な要件だ

RedmineとAIの相性に着目し、その可能性を探ってみたい。
チケット入力の負荷軽減や、蓄積された膨大なデータからのナレッジ蒸留など、AI活用はRedmineの利便性を劇的に向上させることができる。
最新の連携事例を交えながら、プロジェクト管理をより進化させるためのAI活用のアイデアを考察してみる。

【参考】
Codex appでAIからプロジェクト管理ツール「Redmine」を操作する方法(1)設定・動作確認編 | Redmine.JP Blog

Codex appでAIからプロジェクト管理ツール「Redmine」を操作する方法(2)議事録からチケットを自動起票する | Redmine.JP Blog

Redmine MCPサーバーの設定と使用方法（VS Code × Codex連携） - ファーエンドテクノロジー株式会社

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

ゼロから作るDeep Learning Pythonで学ぶディープラーニングの理論と実装

ゼロから作るDeep Learning 自然言語処理編

ゼロから作るDeep Learning フレームワーク編

ゼロから作るDeep Learning ―強化学習編

ゼロから作るDeep Learning 生成モデル編

ゼロから作るDeep Learning ―LLM編 : 斎藤 康毅: 本

【1】RedmineとAIの相性は良いだろうか？
僕は、AIとRedmineは相性が良いと思う。

Redmineの主たる機能はチケットへの入力や更新、そしてチケットから意味を読み取ること。
チケットへ情報を書き込む手間は割と多い。
チケット駆動に慣れないユーザは、そこでつまずく。

また、RedmineにはチケットやWikiにどんどん情報を書き込んで蓄積するほどナレッジが溜まり、有用性が高まる。
しかし、肝心のデータを単純に検索するだけでなく、本質的な意味を長文から読み取るのは面倒。
そこでつまずく人も多い。

【2】そこで、AIを活用すれば、これらの問題はかなり解決されるだろう。

たとえば、日本語変換のように、文字列を入力する時に勝手にAIが自動補完する。
AIが、この人がこの場面ならこんな文章を入力したいのだろうと、勝手に支援してくれる。

あるいは、障害チケットや問合せチケットから、このチケットを要約するとこんな意味です、とレポートする。
あるいは、PJに蓄積されたチケットを元に、週次報告を出力し、プロジェクトの健康診断みたいに報告してくれる。

つまり、AIが入力更新の手間を減らし、AIがナレッジを蒸留させて、色んな場面でレポート出力してくれる機能も提供できるだろう。

【3】なぜAIはRedmineにとってそんなに重要なのか？

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索にも書いたように、Redmineにいくらチケットに情報を書きこんで蓄積したとしても、それを有効活用できなければ、持ち腐れに過ぎない。

その問題解決の手段の一つとして、全文検索の機能強化があった。
もう一つは、AIによる機能強化があげられるだろう。

つまり、AIにより、Redmineへナレッジを書き込む労力を減らし、利用ユーザのモチベーション低下を防ぐ。
また、いつでも簡単に、蓄積されたデータを蒸留させたナレッジが取り出すことができ、そこから、利用者が欲しい情報を手に入れたり、プロジェクトリーダーの意思決定を強化できるはずだ。

よって、Redmineに蓄積されたデータの品質が良く、データ量が多いほど、AIをフル活用させるメリットが出てくる。

RedmineとAIを組み合わせた機能改善は、今色んな人が試している。
@haru_iidaさんのAIヘルパープラグインもある。
ファーエンドテクノロジーさんのCodex appでAIからチケット入力更新を支援する事例もある。
その他にも、MCPサーバーと連携して、SlackやGitHubと連携するやり方もある。

これらの事例や技法は、今後のRedmineにたくさんの活用シーンを広げてくれるだろう。
この辺りのアイデアはもっと考えてみたい。

マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet

現代ではチケット駆動開発は当たり前になった。
しかし今、その運用はマイクロマネジメント化し、タスク管理のはずが管理強化の道具となり、現場の自律性を奪うケースが増えている。
加えて大規模運用の壁も顕在化している。
現場視点で課題と打ち手を具体的に考えてみる。

【参考】
Redmineによるタスクマネジメント実践技法 : 小川 明彦, 阪井 誠: 本

チケット駆動開発 : 小川 明彦, 阪井 誠: 本

逆引きでわかる！ Redmineハンドブック バージョン5.0対応 | 川端 光義 |本 | 通販 | Amazon

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント | 株式会社アジャイルウェア |本 | 通販 | Amazon

入門Redmine第6版

【1】僕が2008年に「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ 」をKOFで発表してからもう15年以上経った。
現在地点では、チケット駆動開発をベースとしたソフトウェア開発は、アジャイル開発であれ、WF型開発であれ、たぶん当たり前になっているだろう。

redmine-presentation-846109from akipii Oga

では、現在地点におけるチケット駆動開発の課題は何があるのだろうか？
チケット駆動開発のどこに問題が起きているのだろうか？

【2】僕個人の考えでは、2つの問題があると思う。

1つ目は、チケット駆動開発がマイクロマネジメントのツールに化してしまっていること。もう1つは、大規模チームでチケット駆動開発を運用するノウハウがまだ蓄積できていないこと。

前者の問題点は、伊藤直也さんがツイートされている。

Xユーザーのnaoyaさん: 「タスクを細かく洗い出してチケット切って開発みたいなの、自分は基本的に信用してない マイクロマネジメントで作業者から自分で物事を考えて進める思考や責任を奪ってる」 / X

Xユーザーのnaoyaさん: 「チームでざっくり直近の目標を決めて、それぞれの担当領域を決めたらその領域内でどうつくるかは各々に任せる そのうえで作ってるものの過程は成果物をマネジメントするべきで、プロセスをマネジメントしない」 / X

Xユーザーのnaoyaさん: 「2週間とかの期間がある中で、どこで本気出すかは各々の自由だしそれはコントロールできるものでもない マイクロマネジメントはその裁量を奪うだけだ」 / X

Xユーザーのnaoyaさん: 「良いプロダクトは、洗い出したタスクを全部こなしたらできあがるわけではなく、良いプロダクトになるよう仕上げることで出来上がるもの プロセスをマネジメントしすぎると、結果タスクをこなすことにマインドが向かう 良いプロダクトに仕上げることにマインドが向くようマネジメントするべき」 / X

Xユーザーのnaoyaさん: 「良いプロダクトにしようと思ったら、作りながら発見した事実をもとに、臨機応変にやることを変えていく必要がある タスク志向になると、この自分で臨機応変に状況にあわせてやることを変える、という力を奪うことになる」 / X

本来のチケット駆動開発は、タスク管理をプロマネから開発者へ権限委譲し、開発者自身がアジャイル開発をベースにタスクを消化していくことで、ソフトウェアを開発するスタイルだった。開発者の自主性を引き出す効果があった。

しかし、チケットをWBSとみなせばWF型開発にも適用できるので、プロマネが計画時点でPJ計画書に基づいてWBSをチケット化して開発者に押し付ける運用も多く見かける。
つまり、開発者がタスクを考える必要もなく、プロマネがチケットを担当する開発者をマイクロマネジメントするための道具になってしまった。
すなわち、開発者がシステム開発するためにタスクを詳細化していく思考を奪ってしまい、単純労働者の地位に押し付けられている。
こうなってしまうと、チケット駆動開発はアジャイルさを失い、ガチガチのマイクロマネジメントの道具になってしまっている。

【3】では、そんな状態から脱出し、本来のチケット駆動開発の良さを引き出すには何が必要なのか？

そもそも、マイクロマネジメントしたい状況は、特に製造業の工程管理や、ソフトウェア開発の大規模案件でよく見かける。
たとえば、製造業の工程管理では、受注、設計、購買、製造、出荷物流のような工程があらかじめ決まっている。
各工程では、メカ・エレキ・ソフト・品質管理担当などがどんな役割でどんな作業をするのか、ISOの規定に沿ってあらかじめ決まっている。
それらのタスクは、受注した時点であらかじめ確定する。
後は、納期に合わせてスケジュールを作り、担当者の負荷計画を立てるだけだ。
つまり、WF型開発みたいにガチガチの作業管理になるのは必然だ。

しかし、実際の製造業の現場を見ると、設計者も生産管理担当者も3つ4つの製品を担当していて、複数案件をまたがって作業しているのが一般的だ。
つまり、製造業の組織が機能別組織であっても、実際の作業者は複数案件を掛け持ちして兼務しているので、自然にマトリクス型組織になる。
2ボス体制なので、レポートラインが2つ以上あるため、作業者は非常にやりづらい。
製造業の担当者はいつも複数製品の作業で手一杯で、いつも忙しそうにしている。
毎日自転車操業しているようなものだ。

よって、ガチガチのガントチャート管理をしてもすぐに進捗遅延が発生する。
納期間近になってドタバタするのが当たり前だ。

だからこそ、本来のチケット駆動開発の良さを引き出すには、突破的な作業はチケット管理で忘れないように起票して毎日の朝会で優先順位付けすることが大事だと思う。
一方で、製造業では工程管理も重要なので、突発的な作業管理以外にも、工程管理するためのチケット管理も必要になると思う。

つまり、製造業のタスク管理では、突発的な作業管理と工程管理の2種類のチケット管理が必要になるだろう。
マイクロマネジメントになる雰囲気があっても、やるべき作業は見える化し、チームとして対応していく雰囲気づくりは必要だと考える。

【4】後者の問題は、大規模なチケット駆動開発により、管理の複雑性が増していることに起因しているのだと思う。

元々、チケット駆動開発は数人レベルの小規模なチームによる開発経験から生まれた。
だから、少人数で俊敏に開発するアジャイル開発と親和性が高い。
そこから、アジャイル開発のプラクティスを取り入れると開発が上手くいくことが分かり、チケット駆動開発のプラクティスやアンチパターンも色々分かってきた。

また、チケット駆動開発は元々柔軟なワークフロー管理機能を持つので、ITILによるソフトウェア保守、情シスのタスク管理、システム監査、カスタマーサポートなどにも適用できる。
つまり、色んなプロセスをチケット駆動開発で実現できる。そこが、チケット駆動開発の面白さの一つだと思う。

しかし、チケット駆動開発の適用範囲が広がり、ユーザ数やチケット数が膨大に増えていくと、複雑性が増して、単純な運用ルールだけではじきに手が負えなくなる。
大規模なチケット駆動開発では、複雑性を制御するために、何らかの標準プロセスの実装が必要になってくるのだと思う。

では、大規模なチケット駆動開発による複雑性は、どのように解決すればいいのか？

Redmineコミュニティで今までに語られたアイデアの一つとしては、Redmine警察やRedmine職人のような役割を設けたり、定期的な棚卸し会を運用するなど、組織として運用する仕組みを作ること。

他には、大規模アジャイル開発のフレームワークであるLeSS、SAFeなどのアイデアを参考にして、チームやプロセスを階層化して管理する手法もあるだろう。

つまり、チームやプロセスを階層化することで、会議体を整理し、必要な情報がレイヤに関係なく共有できる仕組みづくりが必要だろうと考えsる。

【5】2つのテーマに関するこの辺りの問題点、解決法を整理してみたいと思う。

RedmineとAIが加速させるタスク管理の未来～蓄積されたナレッジを独自のAIとして活用する可能性

Redmineは単なる管理ツールから、AIの力で「意思決定のパートナー」へと進化を遂げている。
日々蓄積されるチケットは、実は組織独自の最強のナレッジDB。
色々考えたことをメモ。

【参考】
Redmine AI Helperプラグインを更新しました: 2026年2月版

第30回勉強会 - redmine.tokyo

Redmineによるタスクマネジメント実践技法 : 小川 明彦, 阪井 誠: 本

チケット駆動開発 : 小川 明彦, 阪井 誠: 本

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント | 株式会社アジャイルウェア |本 | 通販 | Amazon

逆引きでわかる！ Redmineハンドブック バージョン5.0対応 | 川端 光義 |本 | 通販 | Amazon

入門Redmine第6版

【1】RedmineAIHelperを使っていると、Redmineに色んな可能性を感じさせてくれる。

Redmine AI Helperプラグインを更新しました: 2026年2月版では、下記の機能追加があった。

・チケットやWikiに添付された画像やPDFなどをAIが分析
・よく使うプロンプトを「カスタムコマンド」として登録
・沢山あるチケットの中から「今日やるべきチケット」をAIが提案
・重複チケットの検索
・チケットの担当者提案
・子チケット自動生成時の担当者選択
・類似チケット検索の範囲指定

OSSならではのこういう細かな機能改善をしてくれるのがいい。

【2】RedmineとAIはなぜ相性がいいのだろうか？

理由は簡単だ。
Redmineに、過去のタスク・課題・障害・問合せチケットの履歴がナレッジDBとして蓄積されているからだ。
その会社、そのチーム、個人特有の情報が蓄積されている。
だからこそ、自分たちに特化したLLMとして使えるわけだ。

こういうAIによる支援機能がRedmineに充実できれば、Redmineを利用するユーザも、Redmineにどんどんデータを入力して使いこなそうとするモチベーションも上がるだろう。
RedmineとAIの組み合わせは、正の螺旋ループ強化として、成長できる余地があると考える。

【3】懸念点としては、企業秘密として管理すべきセンシティブな内容をOpenAI、Geminiなどに食わせるのに難点があることだろう。
しかし、RedmineAIHelperプラグインにはMCPサーバ接続機能があるから、自社のLLMに接続し、自社内で閉じる形で運用すればいいだろう。

RedmineとAIの組み合わせには色んな可能性を秘めていると思うので考えてみたい。

Redmine AI HelperプラグインはRedmineをAI駆動プロジェクト管理に変える可能性を秘めている #Redmine

Redmine AI Helperプラグインの講演資料を読んで改めてアーキテクチャ構造がよく考えられているなと思った。
Redmine AI Helperプラグインを知っている前提で、理解したことをラフなメモ書き。

【参考】
Redmine AI Helperとそのしくみ

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

【1】Redmine AI Helperプラグインのマルチエージェントモデルは優れていると思った。

Redmine AI Helperプラグインのマルチエージェントモデルでは、Issueエージェント、Wikiエージェント、Userエージェントなどの機能に特化したエージェント群と、GitHubエージェント、Slackエージェント、メールエージェントのようなMCPエージェント群が協調して、互いに会話しながら動作する。

その時に、マルチエージェントモデルのアーキテクチャとして、@haru_iidaさんは、Networkではなく、Supervisorを選んだ。

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

なぜ、Supervisorを選んだのか？
redmine.tokyo勉強会の講演で聞いたときは、NetworkよりもSupervisorの方がエージェント同士のレスポンスがいいと話していた。

理由は色々推測できる。
おそらく、複数のエージェント同士で処理を実行するために会話させたならば、誰かが全体の処理を監視してコントロールしなければ、変な方向に行ってしまう場合が多いのだろう。
エージェント同士のコミュニケーションパスが多くなるほど、統制が効かなくなるはずだ。
つまり、人間集団や組織と同様に、コミュニケーションパスを減らし、1人の管理者がコントロールできる範囲に収めるようにしなければ、本来実施して欲しい処理の品質が悪くなるのだろう。

では、Supervisor型のエージェントモデルでは、どんなコミュニケーション構造を取っているのか？
@haru_iidaさんの設計では、仮想チャットルームを作り、Supervisorが必要なエージェントのみをチャットルームに召喚して処理を実行させている。
仮想チャットルームは、まるで人間のSlackみたいな感じだ。

第29回redmine.tokyo勉強会

つまり、Slack上でエージェント同士が、チケットを更新する処理のために、Supervisorがまずエージェント達にゴールを共有した後、SupervisorがUserエージェントやIssueUpdateエージェントと会話してるイメージ。
エージェントは仮想プログラムに過ぎないのに、人間のように振る舞う点がすごく面白いと思った。

実際の仕組みは想像になるが、Supervisorやエージェント同士が会話するログのテキストファイルがあって、そのログテキストにあるプロンプトからファンクションコールされてエージェントがキックされるのだろうと思う。
つまり、会話ログというテキストファイルが仮想チャットルーム、すなわち、Slackみたいなイメージになるのだろう。

そのSlackにプロンプトが書かれると、処理すべき機能に対応するエージェントがファンクションコールで呼び出されてキックされて、プロンプト通りにエージェントが実行するわけだ。

そんな仕組みを考えると、処理を実行するプロンプトの背景、ゴールを明確に定義する必要があるだろう。
つまり、AIでよく言われるコンテキストが重要になってくるだろう。
なぜならば、背景や前提条件、制約条件というコンテキストが明確でなければ、期待した結果が出てこないからだ。
実際、ChatGPTでも前提条件を細かく書かないと、欲しい結果がなかなか出てこない。

こういうエージェントモデルでは、各エージェントのフォルダにコンテキストを事前設定するプロンプトを配置して、エージェントを制御する仕組みがあるらしいので、おそらく@haru_iidaさんは事前プロンプトにかなりのノウハウを組み込んでいるのではないかと想像する。

【2】Redmine AI Helperプラグインのアーキテクチャ構造も優れていると思った。

内部構造では、ユーザ要求処理、ビジネスロジック、外部サービスの3層構造に綺麗にレイヤ化されている。
具体的には、Webアプリ層、Agent層、MCPサーバやLLMの層の3層構造に綺麗に設計されている。
これはすごく綺麗だ。
アーキテクチャをちゃんと理解できる人しか組めないような綺麗なアーキテクチャだ。

第29回redmine.tokyo勉強会

わざわざ、マルチエージェントモデルを3層構造で分けたメリットは何なのか？
オブジェクト指向設計に慣れている人ならば効果はすぐに理解できるはずだ。

ユーザがMCP Agentや各機能に特化したドメインのAgentへ処理を実行させたい時、その処理は中身は違っても操作としては共通のインターフェイスを持つはずだ。
つまり、ユーザ要求処理とビジネスロジックの間に、Agent抽象化レイヤーを入れて、Agentへ指示する操作をインターフェイスで抽象化すれば、ポリモルフィズムを使って制御すればいい。

同様に、MCP AgentがGitHubやSlackに連携させたい時、MCP抽象化レイヤで操作をインターフェイスで抽象化しておけばいい。
あるいは、IssueAgentがOpenAIやAnthropicのLLMを使いたい時、LLM抽象化レイヤで操作をインターフェイスで抽象化すればいい。
そうすれば、LLMのバージョンが上がって追加したくなる場合、ビジネスロジック層のプログラムを変えることなく、簡単に追加したLLMを利用できるようになる。
つまり、抽象化レイヤがあるおかげで機能追加や機能修正のプログラミングが非常に楽になる。

僕は、この内部構造のアーキテクチャを見て、AIエージェントの仕組みを理解できた。
さらに、最近、AIの機能を入れました～とあらゆるWebサービスやパッケージ製品で広告を見かけるが、おそらくそれらシステムも@haru_iidaさんのようなアーキテクチャ構造に似た構造になっているに違いないと思った。
そうでなければ、大量の人員とお金を投資した案件なので、今後のシステム保守を考えれば元が取れないはずだ。

【3】Redmine AI Helperプラグインの根本テーマに「プロジェクト管理にもAIを」がある点がすごくいい。
AIが当たり前の現代では、ソフトウェア開発であれ、ホワイトカラーの仕事であれ、経営戦略をねったり、プロジェクト管理することも全てAI駆動になる。
AIを使うだけでなく、AIでいかに価値を出すか？

Redmine AI Helperプラグインによって、RedmineをAI駆動プロジェクト管理に変える可能性を秘めている。
従来は、Excelによるプロジェクト管理からの脱却がメインテーマだったが、現代では、AI駆動のプロジェクト管理により、プロジェクトリーダーやプロジェクトマネージャは本来の意思決定に専念できるようになる。
そんな機能が沢山盛り込まれているし、今後の機能追加により、さらに発展するだろう。

Redmine AI Helperプラグインは、そういう機能追加がやりやすいエージェントモデル、アーキテクチャ構造になっているので、今後の開発にすごく期待できる。
今後もウォッチしていきたいと思う。

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

第29回東京Redmine勉強会に参加してきた。
今話題になっているテーマは、いわゆるJTCの中でRedmineをどのように運用しているのか、とAIによるプロマネ作業支援だった。
とてもホットな内容で興奮が翌朝も残っている。
感想をラフなメモ。

【参考】
第29回勉強会 - redmine.tokyo

2025/11/9 第29回勉強会 - redmine.tokyo #redminet - posfie

Jira ユーザー向け 入門ガイドブック | リックソフト株式会社

Jira と Confluence の活用: シームレスなコラボレーションの実現: Jira と Confluence をプロジェクト管理フレームワークに統合するための効果的な戦略 (プロジェクト管理, IT・テクノロジー) | R. Parvin

【1】いわゆるJTCがRedmineを運用している事例では、東芝や三菱電機の事例が発表された。
典型的な日本の大手SIがRedmineをどのように使っているのか、どんな目的で使おうとしているのか、そして、どんな効果や苦労があったのか、具体的な話が多くて面白かった。

発表 #1683: 第29回 講演: 2万人が利用するソフトウェア開発管理支援サービスのご紹介 - redmine.tokyo

発表 #1674: 第29回 LT: JTCでRedmine利用者2700人を実現した手法 - redmine.tokyo

Redmineは、日本ではよく使われているプロジェクト管理ツールと言っていいだろう。
なぜ、日本企業や日本人開発者はRedmineを好むのか？
その理由は以前たくさん考えてた。

僕が持つ仮説は、現場に直結した困りごとを自分たちが手作りでツールを作り込み、自分たち自身で改善していくというスタイルは日本人がとても好きだから、と思っている。
いわゆる現状に即したプロセス改善は、日本人の得意芸と思っている。
日本の製造業で出てくるQCサークル、QC７つ道具、デミングサイクルは、日本のソフトウェア開発にも根付いていると思う。

そこで、中小SI企業だけでなく、JTCのような大手SIの現場でもRedmineを使いたくなってくる。
では、JTCでRedmineを運用し始めると、どのような問題が出てくるのだろうか？

JTCになれば、案件の数は格段に多くなるので、単一のRedmineで全ての案件を管理し統制させるのは難しくなってくる。
なぜならば、案件の種類はスクラッチ、エンハンスメント、パッケージ製品導入、リプレース、PoCなど多岐にわたるために、１種類の標準プロセスでコントロールするのは正直無理があるからだ。

そこで、東芝のように、研究開発部門や品質保証部門がRedmineやGitlab、Jenkinsなどの開発支援ツールを仮想環境で作り、各案件に社内ホスティングサービスとして仮想環境を提供し、自由に使ってもらうような運用が多くなるだろう。
この運用のメリットは、社内案件で使われるプロジェクト管理ツールや開発支援ツールを社内標準として提供できるため、ある程度統制を効かせられること。
また、ツール類が共通なのでノウハウも蓄積しやすい。
実際、東芝の事例では、社内ユーザ会を年数回定期的に開いて、社内で事例を発表して共有したら、社内関係者にすごく評判が良かった、という説明があった。
つまり、ノウハウ蓄積により、社内の組織活性化、生産性向上にも繋げられる効果があるだろう。

一方、各案件ごとにRedmineインスタンスが乱立するために、Redmineのバージョンが古くなりがちで、最新版への移行が難しくなることだ。
東芝の事例では、200個以上のインスタンスがあり、Redmineの主なバージョンは4.2が多い説明があった。

本来は、AIヘルパープラグインやいいねリアクション機能が使えるバージョン6.1へ移行したいだろうが、大量のRedmineインスタンスをVerUpする一括移行は非常に大変だろう。
東芝の事例では、移行作業のためにスクリプトなどで自動化するなど運用上の工夫をされていたが、それでも各メンバーがそれぞれ各案件のRedmine移行作業を担当し、手作業でカバーしていると説明されていた。
おそらく実際は、Redmineのような年2,3回程度のVerUpに追随するように移行作業を実施することは、大量のインスタンスがあるために実現困難なのだろう。

つまり、社内ホスティングサービスでは、運用当初は良くても、その後のVerUp追随が難しく、次第に統制が効きづらくなるデメリットが増えてくる。
たぶんどこかで、損益分岐点が逆転するタイミングが発生するかもしれない。

他方、島津製作所のRedmine運用事例のように、単一Redmineで統制を効かせて、ナレッジ蓄積に効果を上げている事例もあった。
JTCでRedmineを社内展開するときの運用方法の選択基準、スコープ設定で違いがあると、どのような効果や問題点が発生するのか、考えてみたい。

Xユーザーのakipiiさん: 「JTC事例では、 @akahane92のような単一インスタンスによるナレッジDBで全般統制と、なおまえさんの所のような社内ホスティングによる乱立インスタンスによる標準プロセス適用の諸問題の対比が興味深い。この辺りは一度議論を聞いてみたい　 #redminet」 / X

【2】Redmine AI Helper の講演では、AIを使ってRedmine上のプロマネ作業支援できる具体例や、AIヘルパーの内部構造の説明が非常に興味深かった。
興味深い点は2つある。

Redmine AI Helper とそのしくみ 第29回redmine.tokyo勉強会

1つは、チケットの要約機能は、もっと発展させれば、課題一覧から更新分の内容を要約させて、進捗報告書の一つの元ネタに割り当てる事ができること。
この機能を発展させて、健全性レポートという機能がAIヘルパーで提供されていた。
つまり、測定時点のプロジェクトのQCD、いわゆる進捗率の変化、テスト密度やバグ密度、課題件数の推移や優先度の割合、などを進捗報告書として自動生成してくれる。
したがって、経営層向けのプロジェクト進捗報告書作成という管理作業をプロマネはAIに委託できるメリットがある。

他にも、親チケットから子チケットへタスクを自動的にバラしたり、類似チケットを自動検索したり、チケットコメントの自動生成、チケットやWikiで文章を予測して自動補完、誤字脱字チェック機能などがある。
こういうAIヘルパー機能を使えば、顧客相手にチケットでやり取りするときの誤字脱字防止、チケットで即返答、類似バグ調査などにも役立てられるだろう。

Xユーザーのakipiiさん: 「AIヘルパーで健全性レポートを保存できる。さらに差分チェックもできてAIが比較報告してくれる。cronを使えば報告書作成も自動生成できる。プロマネの作業工数削減に繋がる。　 #redmineT」 / X

2つ目は、AIヘルパーを実現する内部構造の解説だ。

Redmine に蓄積されたタスク、システム開発のナレッジを元に、AIがチケットの要約だけでなく、ストーリーチケットからタスクチケット分割を自動生成できたり、診断時点のプロジェクトの品質、進捗、テスト、レビュー状況を報告書としてまとめたりできる。プロマネの管理作業をAIが支援できる。

実際の仕組みはAIエージェントをロール毎に作ってプロンプトを渡して実行してるだけ。
具体的には、Redmine の背後に、AIエージェントが複数立ち上がり、リーダー役エージェントが仮想チャットルームを作り、そこにチケット作成エージェントやRedmineの機能に特化したエージェントを呼び込んで自然言語でやり取りして実行する仕組みだった。

Xユーザーのakipiiさん: 「AIヘルパー内部では、リーダーエージェントが仮想チャットルームを作り、チケットエージェントやリポジトリエージェント、ユーザエージェントなど必要なエージェントを仮想チャットルームに召喚して自然言語で会話しながら、要約したり子チケットばらしとかしてる。普通の開発チームみたい　 #redmineT」 / X

この話を聞いて、別ニュースで、AIエージェントを集めて仮想スクラムチームを作ってシミュレーションした話と似てるなと思った。
つまり、スクラムマスター、プロダクトオーナー、チームメンバーという仮想AIエージェントを作り、仮想スクラムチームを形成して、プロダクトを出していくシミュレーションができるわけだ。

仮想スクラムチームとAIヘルパーのマルチエージェントモデルの違いは、対等なエージェントでチームを作ると人数が増える毎にコミュニケーションパスが増えて無駄があるので、リーダー役エージェントが一括管理する方が仕組み的に良い点になる。
AIエージェントでチーム形成する時、アジャイル観点と違ってマイクロマネジメントの方が優れているのだろうか？

現代ではソフトウェア開発だけでなく、あらゆるプロジェクトでもマイクロマネジメントではなくサーバントリーダーシップによるチームビルディングが推奨されている。
つまり、コマンダーのようなリーダーではなく、チームメンバー自身がリーダーの役割を持ち、自己組織化していく傾向が良いはずだという流れになっている。
しかし、マルチAIエージェントモデルでは、コマンダーが指示するマイクロマネジメントの方が処理性能が良く優れているという設計になっている。

現代のアジャイル開発の流れと従来のマイクロマネジメントスタイルを持つマルチAIエージェントモデルが違う点は何なのか、今一度整理したい。

僕の仮説では、ソフトウェア開発のように、深い専門性を持つメンバーから成り立つ案件では、人間であるリーダーが全ての専門知識をカバーできないため、サーバントリーダーシップを発揮して、意思決定権限をチームに移譲するやり方にならざるを得ない。
一方、単純な作業指示のような案件では、マイクロマネジメント方式の方が簡単で効率もいい。
さらに、AIの場合、リーダー役のAIエージェントは全ての専門知識を知っている前提にすれば、実際の作業実行ロールのエージェントに作業分担させた方が、遥かに効率がいい。

よって、AIがプロジェクト管理に浸透するほど、サーバントリーダーシップよりもマイクロマネジメント方式が優勢になるかもしれない。
サーバントリーダーシップは、情報整理力が劣る人間の集団で必要なリーダーシップに過ぎないのかもしれない。

また、AIヘルパーの内部構造では、
Rails MVC　＞　エージェント抽象化レイヤ　＞　各エージェント　＞　MCP抽象化レイヤ、LLM抽象化レイヤ　＞LLM、MCPサーバ
で設計されていた。
これを見て、エージェントの追加変更やモデルの追加が非常にやりやすいアーキテクチャだな、と感心した。
むしろ、LLMモデルを使った設計はこのような仕組みにならざるを得ないのではないか。

【3】僕は、JIRAによるチケット駆動開発の運用事例を紹介してきた。
久しぶりの講演で実は緊張していたが、話しているとテンションが上って、いい感じで話せた。

How We Operated Ticket-Driven Development in JIRA

たぶん、世界的にはRedmineよりもJIRAの方がよく使われているだろう。
僕は、JIRAは複雑すぎて使いづらく、Redmineの方が好きだ。

僕は、組み込みシステム開発では、タスク管理が複雑な階層化のために運用が難しく、それをJIRAにフィッティングさせて運用するのも難しい、という話をした。

一方、懇親会では、JIRAにアドバンスドロードマップやスキーマ機能を使うとさらに便利になる話を聞いて興味を持った。

Xユーザーのakipiiさん: 「懇親会でJira機能を話し込んだ。アドバンストロードマップがプログラム管理に使えること、スキーマ機能が標準プロセス適用に使える事が分かって収穫があった。JiraはRedmineと異なる機能がまた面白い。　　 #redminet」 / X

Jira Advanced Roadmapsは、製品企画のような計画作成で使う機能と思っていた。
どうやら、複数プロジェクトを横断したプログラム管理で使えるらしい。
JIRAのプロジェクトは階層化する機能がないため、Redmineに比べると不便だった。
おそらくその機能を補完するような機能かなと推測する。

Jira Advanced Roadmaps を使った計画策定を習得する | Atlassian

ChatGPTで聞いたら
「複数プロジェクトの計画・スケジュールを俯瞰的に可視化・調整できる上位プランニングツール です。
Scrum や Kanban チームのバックログをまとめて管理するのに最適です。」
とのことだった。

また、JIRAにおけるスキーマ（Schema）とは、ワークフローや権限、画面構成などをテンプレート化し、複数プロジェクト間で共通化する機能だ。
この機能はRedmineにはない。
アジャイルウェアのプロジェクトテンプレート、チケットテンプレートプラグインに似ているだろう。

JIRAのSchema機能を使いたい場面は、社内の標準プロセスを全案件に展開して統制できることだ。
JTCならば、社内標準の開発プロセスがあり、工程・手順・成果物が明確に定義されたV字モデルを持っているだろう。
すると、社内の全案件は、社内標準プロセスに従わせて、ドキュメントの標準化や作業効率化を目指したい。
そんな時にJIRAのSchemaで社内標準プロセスをテンプレートで実装すれば、各案件に展開すればいい。

運用プロセスに対して、こういうチケット管理ツールの機能フィッティングは面白いので、今後も色々探ってみたい。

第22回 Redmine大阪の感想 #RedmineOsaka

第22回 Redmine大阪の感想をメモ。

【参考】
2025/9/21 第22回 Redmine大阪 #RedmineOsaka - posfie

Redmine-osaka-022 - Redmine.Osaka

入門Redmine第6版 : 石原佑季子, 前田剛: 本

5年ぶりの開催で盛り上がりを心配したが杞憂だった。
スタッフも参加者もテンションが高くて楽しかった。
東京、岐阜、福岡から参加者が来てくれた。
初めての参加者も若手で数人おられたが、すぐに馴染んで、本音ベースで話せた。

講演内容も多様だった。

【1】前田さんの話では、Ver4以前のRedmineは最新機能が全く取り込まれていないので、早くアップデートしましょうという主張だった。
メンション機能、チケット一覧での検索、フォントサイズやフォントの変更、テーブルタグを見やすくするUI改善が目に留まった。
次バージョンでは、いいね機能もリリースされる。
昨今のスマホのようなUIを取り入れていく改善は、地味だけれども、ユーザ体験をより良くするために重要だと思う。

【2】赤羽根さんの話では、チケット20万件以上、ユーザ数3900人以上の大規模な運用事例。
製造業という非常に縦割り組織の中で、10年以上Redmineを運用して、設計情報をRedmineに蓄積しナレッジ基盤とした運用はすごいと思う。
後で聞いた話では、Redmineをフローの管理、つまりタスク管理や進捗管理に使うのではなく、チケットに設計情報や製品に関する情報だけをどんどん蓄積していく運用に振り切った、とのこと。
だからこそ、10億字以上の文字が蓄積されるわけだし、全文検索エンジンGroongaの必要性が出てくる流れを理解できる。

【3】三浦さんの話では、自分はなぜかドキュメント管理の整備にアサインされるという話から始まって、ドキュメント管理の経験を語られた。
Wikiでナレッジが集約されるメリットがある反面、ドキュメントは負債にもなり得ること、ドキュメントの保守には工数がかなりかかる。
インセンティブや強制力を使って、ドキュメントを残し集約し、検索できるようにする基盤として、Redmineも候補になりうる。

【4】アジャイルウェア様の会場をお借りして本当に楽しかった。
広くて綺麗で、液晶モニタもすごく大きくて、プロジェクタ無しで投影できて素晴らしい会場だった。
ありがとうございました。

【5】Redmineコミュニティの良い所は、講演内容がRedmineの機能紹介やカスタマイズに偏ることなく、運用事例やプロジェクト管理、情シス部門の考え方、ナレッジ蓄積やタスク管理の考え方まで幅広く紹介されること。
このあたりが面白いなと思う。
だからこそ、かなり特殊なコミュニティもかかわらず、テーマが多様なお陰で、コミュニティが長続きしているのだろうと思う。

また次回も開催したいなと思います。

RedmineJapan vol.4の感想part1～Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan

RedmineJapan vol.4で紹介されたRedmine AI Heplerプラグインが素晴らしかったのでメモ。

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

逆引きでわかる！ Redmineハンドブック バージョン5.0対応

2025/7/25 Redmine Japan Vol.4 #RedmineJapan - posfie

Redmine Japan Vol.4

Redmine AI Helperプラグイン更新

Redmine AI Helperプラグインを公開しました

【1】Redmine AI Heplerプラグインは、RedmineからAI機能をコールして、チケットやWikiの要約などをしてくれるプラグインだ。
今年5月のredmine.tokyoでも講演されていて、参加者の多数がすごく興味を持っていた。

実際はOpenAIやGeminiなど外部のAIへトークンを発行してコールしている仕組みだけだが、AIがさらにRedmineを使いやすくしてくれる可能性を秘めている。

Redmineを長年使い込んでいくと、チケットに過去の作業、障害修正、課題対応などのノウハウがナレッジとして蓄積されていく。
しかし、そのノウハウはそのまま使えるわけではない。
内容が何なのか、ポイントを抽出したり、過去のコンテキストを元に現状の環境ではこういうナレッジになる、という仕掛けがほしい。

要約はAIが得意とする機能なので、要約機能を使えば、現場で使う詳細な進捗報告書を経営層などトップ層へサマリ化、要約して報告書を生成することもできるはず。
たとえば、詳細な障害一覧や課題一覧を見せられても彼らは分からない。
むしろ、どこにリスクがあるのか、現状はどんな評価なのか、を知りたい。
そんな時に、AIの要約機能は使えるはず。

つまり、Redmineにプロジェクト報告書を追加する機能がより具体化できるだろう。

【2】RedmineJapan vol.4ではさらに、edmine AI Heplerプラグインが進化していた。
Redmine AI Helperプラグイン更新の記事の通り、チケットの回答案生成、子チケット作成、プロジェクト報告も機能追加されていた。

チケットの回答案作成は、カスタマーサポートのような定型的な文章を書く場面で有効だろう。
主張したいことを箇条書きで提示すればAIが上手く文章を作ってくれる。

子チケット作成は、プロジェクトリーダーの管理作業を代行してくれるような機能だ。
デモでは、不具合チケットを元に、調査、原因分析、障害対応、検証、リグレッションテスト、デプロイ、リリースなどの子チケットをワンクリックで自動生成してくれていた。
つまり、障害修正のような定型作業では、手順は標準化されているので、その手順に沿ってタスクを詳細化して作成し、それぞれのタスクに担当者を割り振ればいい。
よって、プロジェクトリーダーの管理作業をかなり楽にしてくれるはずだ。

プロジェクト報告では、該当プロジェクトのチケット群をベースに、その時点のプロジェクトの進捗・品質・コストを自動で報告文を生成してくれる。
プロジェクト報告のQCDを数値で評価する機能もあり、たぶん、占いエージェントを作った経験から作られたのだろうか。
また、おれおれ報告というカテゴリもあり、AIが勝手にプロジェクトを診断して、良いか悪いかバッサリ評価した文章を生成してくれる。
遊び心があっていいと思った。

今後、プロジェクト報告機能では、定期的なタイミングでプロジェクト報告の履歴を残す機能も作りたい、と話されていた。
確かに、報告は履歴が重要で、推移を元に比較評価したい。
だから、プロジェクト報告機能の強化は、Redmineがさらにプロジェクト管理ツールとして進化する可能性を大いに秘めていると思う。

【3】RedmineにAIの機能が追加されることによって、何が大きく変わるのか？

やはり、Redmineに蓄積された作業、障害、課題、問い合わせのナレッジを元に、より精度の高いノウハウを蒸留し、抽出してくれることで、プロジェクトリーダーの管理作業や意思決定を支援する仕組みを提供することだろう。

従来のチケット管理システムでは、チケットの更新情報や活動履歴を元に、進捗・品質・コストをリアルタイムに集計できることによって、プロジェクトリーダーの意思決定を支援できる点がメリットだった。
つまり、強力なチケット集計機能がチケット管理システムの主なウリだった。

一方、チケット管理システムには案件や組織特有の情報がチケットとして蓄積されるので、ナレッジシステムにもなりうる。
ナレッジシステムであるからには、いつでも簡単にデータが検索できて、欲しい情報がすぐに得られるようにしたい。
だから、チケット管理システムでは、強力な全文検索機能も重要な要件になりうる。

しかし、全文検索機能はあくまでも文言にヒットするだけであり、本当に欲しい情報を得るには、検索結果から取捨選択する手間もかかる。
そこが弱点だった。

そこで、チケット管理システムにAI機能が追加されることにより、本当に欲しい情報が蓄積されたチケットから蒸留されてサマリ化された情報を取得できるようになる。

つまり、AI機能は、チケット管理システムがナレッジシステムでもある特徴を効果的に利用可能にするはずだ。

しかし、AI機能を単純に機能追加すればすべてが解決できるわけではない。

講演者の@haru_iidaさんが話されていたが、ある案件で担当者をアサインする時、その人の予定表をOutlookで見れば確保できる工数は限られていれば、そう簡単に意思決定できるわけではない。
つまり、Redmineだけでは、本来のリソース管理を意思決定できない。
そこで、Outlookの予定表データをAI機能でアクセスして予定情報を取り込んだり、社内システムや人事システムも取り込んで、より多角的に判断できる仕組みも必要になるだろう。

すなわち、Redmineを情報系基幹系システムとみなすことで、案件管理を強化し、プロジェクトリーダーのチーム運営や意思決定を強化する方向へ進化できるはずだ。

その辺りも今後の発展が楽しみだと思う。