第28回redmine.tokyoの感想～今後のRedmineの方向性が見えてきた #redmineT
昨日の第28回redmine.tokyoの感想をラフなメモ書き。
2025/5/11 第28回勉強会 - redmine.tokyo #redmineT - posfie
半年ぶりの定期開催で楽しかった。
今回は講演もLTも前回より少なかったけれど、その分QAタイムを多くしたら、次々に参加者から質問が出てきて、非常に活発な意見交換ができて、場も盛り上がった。
他人の質問から、いろんな疑問を連想させてくれるのが楽しい。
多数の講演やLTを聞いて、今後のRedmineの方向性が見えてきたと思う。
RedmineにあるチケットからAIがナレッジを抽出すること
一つは、AI機能を使ってチケットに蓄積されたナレッジから要約して報告機能を強化したり、プロマネの意思決定を支援していくこと。
チケットのデータの精度が良ければ蒸留した知識の抽出はAIが得意。
たとえば、経営層向けPJ報告、プロマネが作成する報告資料は、多数のチケットデータをベースにAIに要約させて作ればいい。
CopilotやChatGPTなら、資料のアウトラインだけでなく、パワポ資料まで作成してくれる。
エグゼクティブ向け資料では、案件の状況はどうなのか、を一言で言う必要がある時に、AI要約機能が有効に使えるはず。
あるいは、今週のバグチケットや課題チケットを一言でまとめると、こういう状況です、という報告にも使えるだろう。
また、案件のQCD状況をお天気マークで一目で分かるように記載するケースが多々ある。
その時に、AI Helperプラグインのデモにあったように、占いエージェントで案件状況を占うとか、使えそう。
AIがチケットデータを元に、プロマネに意思決定支援機能を提供してくれると嬉しい。来週はこのチケットに着目してください、このチケットがボトルネックです、とかサジェスチョンすることくらいはAIができるはず。
つまり、チケットに蓄積されたナレッジを基盤としてAIを活用すれば、色んな利用シーンが考えられる。
RedmineのUIを改善すること
もう一つは、RedmineのUI改善。
アイコン表示以外にチケットヘッダ固定表示、リアクション機能、画面のSPA化の話があった。
最近のWebデザイン追随、GitHub等他ツールの良さを取り込む事は、以前からRedmineの課題としてあがっていた。
Redmineはチケット管理機能は優れているが、画面がいつもリフレッシュされてしまいSPA化されておらず、UIが古臭いと従来から言われていた。
しかし、この点は前田さんも含むコミッタや開発者も認識していて、ちょっとずつ改善されている。
古臭いUIが良くなる余地はまだまだある。
Redmineを初めて使うユーザ、Redmineを利用者として使う程度のユーザに対し、最近のWebデザインを取り入れて、使いやすいUIを提供することは重要だと思う。
最近感じるチケット管理ツールの課題
なおまえさんと話していて気づいたことは、チケット管理ツールが生まれてもう15年以上経つのに、チケット管理でタスク管理や進捗管理していくプロセスや運用は、まだまだ課題があること。
元々、チケット駆動開発は小規模なチームのアジャイル開発として生まれた。
しかし、開発案件に適用する範囲や規模が広がるにつれて、数千件、数万件のチケットを管理していくことは手動作業では現実的に難しい。
結局、チケット管理のアンチパターンにはまってしまい、チケット管理の運用方法を再度見直すという堂々巡りに陥っている。
この点は、僕も過去記事で同様の認識を持っている。
現代のチケット駆動開発ではどこに課題があるのか？ #redminet #redmine ｜akipii
なおまえさんと話していて気づいたことは、チケット管理・運用プロセス・成果物の3つのレイヤでマッピングが上手くいっていないことだ。
どの開発案件であれ、プロジェクト計画の時点である程度の粒度で、WBSは決まっていて、そのWBSをベースに進捗管理していくことになる。
しかし、実際は当初計画時点のWBS通りに開発が進むわけではなく、突発的な障害発生、やってみて初めて気づいた課題などをチケットに追加して保守していく。
その時に、当初の計画からズレが生じて予実管理が複雑になったり、プロジェクトの影響を把握しきれなかったり、色んな問題が噴出するのに、チケット管理に全て反映しきれない。
小規模案件であれば、一人のプロジェクトリーダーが全てのチケットを把握できるだろうが、50～100人月以上の大規模案件では、チケット枚数が数千、数万程度になるので、もはや把握しきれず、チケットから状況把握できなくなる。
また、WBSからプロセスや作業だけでなく、作るべき成果物も定義されるが、Redmineのチケットに成果物のリビジョンを紐づける運用をやっていないケースが非常に多いと感じる。
GitHubやGitLabでソース管理しているので、そちらでタスク管理した方が開発者にとって楽だが、Redmineチケット管理とマッピングできていないから、プロマネ視点では進捗状況を把握できない。
つまり、Redmineチケット管理は、成果物の更新状況とかけ離れたところで作業や課題のやり取りを記録しているに過ぎず、逐一GitHubなど他の画面を開いたりして状況確認する手間が発生する。
すなわち、チケット管理による変更管理と成果物の構成管理が、Redmineという一つのツールで一元管理できていない。
この問題は、チケット管理・運用プロセス・成果物の3つのレイヤでマッピングできていない症状を表している。
更に複雑化させている原因の一つが、開発組織の組織構造がより複雑な階層構造になっている場合、プロセスやチケット管理に反映されてしまうことだろう。
昨今であれば、チームトポロジーの考え方を取り入れて、イネーブルチームやプラットフォームチームのような支援チーム、管理チームを別途設けて、ストリームラインチームのような主たる開発チームを支援する仕組みで組織づくりを実現したい。
しかし、それらとチケット管理、プロセスへのマッピングがまだ上手くいっていない感触を受ける。
たぶん、色んなノウハウがまだまだ必要なのだろうと思う。
チケット管理はもう古い技法だが、まだ問題が堂々巡りしているように感じている。
