第24回redmine.tokyo勉強会の感想 #redmineT

第24回redmine.tokyo勉強会の感想をラフなメモ書き。

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

第24回redmine.tokyo勉強会(2023/6/3) #redmineT - Togetter

【毎月更新】Redmine リリース前の新機能を先行チェック！チケットのフィルタでOR検索ができる「いずれかを含む」など（2023年4月コミット分） | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック！関連するチケットの番号を複数指定した絞り込みなど（2023年3月コミット分） | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック！オートウォッチ「自分が作成したチケット」の追加（2023年2月コミット分） | Redmine.JP Blog

【1】@g_maedaさんの講演では、Redmineで未リリースだが取り込まれたパッチの機能改善が紹介された。
興味深い機能は、検索機能の強化だ。

チケットのフィルタでOR検索ができる「いずれかを含む」は、チケット項目だけでなく、フィルタ演算子にも適用できる。
たとえば、添付ファイル名の後ろが .png または .jpg で終わるチケットを抽出とか。
チケット一覧でSQLのように扱うことができるだろう。

また、「現在・過去の値、過去の値、履歴に一度もないの3つで検索する」機能も追加された。
使い方の例として、担当者が自分になったことがないチケット、 担当者が過去に自分だったチケット、Closeしたけど過去に自分が携わったチケット、などがあった。
過去レビューしたチケットを検索したい時に、細かな検索条件を追加することで対応できる。

akipiiさんはTwitterを使っています: 「チケットのJournalテーブルを参照して、現在・過去の値、過去の値、履歴に一度もないの3つで検索する。更新日の検索条件を入れた感じかな。OR検索といい、検索の細かい機能改善をやってますね。 #redmineT」 / Twitter

仕組みとしては、Journalテーブルの更新日を検索している。
よって、過去の履歴をより詳細にフィルタリングできるわけだ。
本来は直接SQLを書ければいいのだろうが、こういう機能改善によって、SQLの検索条件をチケット一覧のUIでカバーできるようになったのはありがたいことだ。

一方、Redmineの右上の検索ボックスの機能と全く同じであるため、チケット数が20万件以上になると性能要件に問題が出てくるだろう。

akipiiさんはTwitterを使っています: 「全検索対象テキストの機能は、性能要件は大丈夫なのかな？　チケットが数万件、数十万件でもレスポンスは問題ない？　インデックスを張ってあるのだろうな。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。Journalテーブルの件数が多くなると遅くなる。検索ボックスの機能と全く同じなので、検索ボックスのボトルネックを感じるなら同じ現象が起きる、と。」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。full_text_searchの検索結果と検索ボックスの検索結果は異なるケースが発生する。クリアコードさんに機能改善を対応してほしいなあという依頼ありw」 / Twitter

RedmineのデフォルトDBはPostgresSQLなので、パラレルクエリを使って、複数のCPUを活用するクエリプランを生成しクエリの応答をより速くする方法がある。
このチューニング方法を使ってもいいかもしれない。

akipiiさんはTwitterを使っています: 「#redminet Oracleのマテリアライズド・ビューみたいな機能を使ってクエリ検索の性能を上げたいアイデアがありました。PostgresSQLならパラレルクエリの機能があるんですね。なるほど。」 / Twitter

第15章 パラレルクエリ

【2】ChatGPTでRedmineチケットを自動作成する方法を試す事例があった。

akipiiさんはTwitterを使っています: 「Redmineの連携方法をChatGPTに聞いてみた。 #redmineT https://t.co/UzMAAe7dCj」 / Twitter

しかし、チケットの内容が微妙で思ったような内容でないらしい。
プロンプトエンジニアリングとか色々テクニックが必要な気がした。

akipiiさんはTwitterを使っています: 「#redminet Redmineチケット作成にも、プロンプトエンジニアリングが必要なのかもしれませんね。」 / Twitter

ボウコバさんはTwitterを使っています: 「@akipii ChatGPTは、知らないことは適当な情報で埋める傾向があるので、知らないことは勝手に決定せず、自分に質問しろと指示する案も出ていますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@bowkoba なるほど、機械の中身は統計処理の推測ですからね。どういう立場で情報がほしいとか、前提条件や制約条件をかなり追加する必要がありそう。」 / Twitter

しかし、ポテンシャルはあるから、ChatGPTで、埋もれたナレッジを再活用するとか、バグチケットに類似バグ調査、過去の類似チケット検索とか、AIで補完してほしいと思う。

akipiiさんはTwitterを使っています: 「Bingに同じことを聞いてみた。埋もれたナレッジを再活用するとか、まだマシかな？？ #redminet https://t.co/HKtFgxwrjG」 / Twitter

【3】川端さんから、逆引きでわかる！ Redmineハンドブック バージョン5.0対応の紹介。
今までの、いかにも土壇場で作ってきました講演と異なり、Redmineの事例紹介の内容がかなり詳しかった。
たぶん、7千社近い顧客企業の事例を持っているので、Redmineのチケット管理でタスク管理するにはどういう使い方がその企業に向いているのか、かなりノウハウが溜まっているのだろうと感じた。

(1) りょうまさんはTwitterを使っています: 「川端さんが真面目な話してるの、超久々に聞くんだが #redmineT」 / Twitter

Redmineのチケット管理でハマりやすい問題は、いくつかある。
1つ目は、ワークフローの複雑さと親子チケットの階層の深さのトレードオフだ。
講演では、レビュー中というステータスを外し、ワークフローを単純化して親子チケットで対応する方法が紹介されていた。
この手法は、トラッカーの種類を減らし、ワークフローを短縮化する一方、親子チケットの階層を深くしてでも対応することに相当する。
プログラマやガントチャート好きなマネージャはツリー構造に慣れているので、このやり方が向いているかもしれない。

2つ目は、PJで現れる工程やフェーズはRedmineバージョンで使うか、親子チケットで対応するか、というトレードオフだ。
一般に、WF型開発では、Redmineバージョンを要件定義、設計、開発、テストのように割り当てる時が多い。
しかし、このやり方では、システムとしてリリースできるタイミングはPJの最後の1点だけになり、リスクが大きすぎる。

講演では、バージョンを使わず、親子チケットのうち子チケットでフェーズ分けする手法が紹介されていた。
つまり、親チケットは実装する機能とし、子チケットで要件定義・設計・開発・テストごとに作成して、親チケットでタスク全体を管理する。
このやり方であれば、親チケットをどのイテレーションでリリースするか、だけ決めるだけでいい。
WF型開発であっても、小規模な改善が多い案件、保守案件ではこのやり方の方がアジャイル開発に似ているので運用しやすいだろう。

【4】中村さんの講演では、Redmineを外部記憶装置として扱い、少ない脳内メモリを有効活用しようという話だった。
GTDにある「頭の中で動く猿を追い出す」ことと同じだなと思う。

(1) アカベコさんはTwitterを使っています: 「チケットや Wiki などを外部記憶装置と認識、よくわかる。外部記憶、かつ長期記憶で起票とかメモすることで短期記憶のスタックを明け渡すようにしてる #redmineT」 / Twitter

【5】@yukiaさんの講演では、チケット管理ツールを個人向け、チーム向け、組織向けの3階層で分類していた。
個人＜チーム＜組織の順に、統制や標準化という押しつけが大きくなるイメージだろう。

中村さんの話でも、チケットに記載しない内容として、個人タスク、案件化していない情報などがあった。
だから、GoogleKeep＋Redmineを使っているとのこと。
確かに、GoogleKeppならメモやちょっとした履歴にも使える。
つまり、個人のタスク管理、メモ管理としてRedmineを利用する方法は実はあまり議論されておらず、今後、もっと試してみる価値はあるだろう。
僕の直感では、GTDのようなワークフローやUIをRedmineで実装できるかどうか、が鍵を握ると感じる。

(1) akipiiさんはTwitterを使っています: 「タスク管理ツールは3種類ある #redmineT https://t.co/IIOkSESd5Y」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チームのためのツールは課題管理がメイン #redmineT https://t.co/WeJGHxZEAD」 / Twitter

(1) akipiiさんはTwitterを使っています: 「組織のツールはワークフローで統制できること #redmineT https://t.co/bX9m8iwioG」 / Twitter

【6】@ryouma_nagareさんが紹介してくれたpython-redmineは試したみたいと思う。
REST APIはありがたい機能なのだが、チケット全件を取ろうとすると100件という制限があったりして割と面倒。
もっと手軽にデータを扱いたいから。

maxtepkeev/python-redmine: Python Redmine is a library for communicating with a Redmine project management application

【7】@MadoWindaheadさんから、チケット管理システム有識者の集いを開催したい、という要望があった。
チケット管理ツールの同盟を組んで、想いを実現したい、と。

(1) akipiiさんはTwitterを使っています: 「プロダクトマネジメントはプロジェクトマネジメントと確かに違うね。アジャイル開発やSaaSで多いかな #redmineT https://t.co/XSlKg04ykI」 / Twitter

(1) akipiiさんはTwitterを使っています: 「PJ管理ツールと同盟を組んだ #redminet https://t.co/OY0bUqbf3Q」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チケット管理ツールの同盟を組んで、想いを実現したい #redmineT https://t.co/e9sCIQZWCt」 / Twitter

今は色んなチケット管理ツールが有償・無償であり、それらの機能を比較して考えていくと、ああそういう使い方がしたかったのか、そんな利用シーンがあったのか、と気づく時がある。
プロジェクト管理の手法はまだまだ枯れておらず、色んなやり方を試せると思う。