第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT

第10回redmine.tokyoは参加者100名超の大盛況で終わりました。
参加者、スタッフの皆さん、そして、コミッタのまるやまさん、コントリビュータの前田剛さん、ありがとうございました。
UStreamでも参照できるので、私的感想をメモ。

【参考】
第10回redmine.tokyo勉強会 - dots. [ドッツ]

第10回勉強会 - redmine.tokyo

第10回東京Redmine勉強会～「メトリクスの見える化とその周辺」　#redmineT - Togetterまとめ

【1】Redmineの開発とリリース計画作りは、わずか3人の体制で支えられている。
役割分担は、JPLが機能追加やリリース作業、まるやまさんがバグ修正やテストコード整備やRails5対応、前田剛さんがチケット整理と次バージョンの対象チケットをアサイン、となっているらしい。
Redmine本家の活動ログを見る限り、3人体制で上手く回っているように見える。

でも、第三者から見れば、Redmineは日本でこれだけ普及したOSSのプロジェクト管理ツールであり、SIの事実上の基幹系業務システムになっている現状を考えると、Redmineの開発体制はもっと強化してもいいかもしれない。
今後もずっと、永久的にRedmineの開発が安定して続けて欲しいのだ。

前田剛さんから、Redmine本家に、バグ報告や機能改善の提案があれば、チケット登録して欲しいと、実際の操作方法も説明された。
また、前田剛さんによれば、Twitterで「#Redmine」のハッシュタグを付けてバグ報告してもらえるだけでも拾えるから、と言っていた。

Kawabata Mitsuyoshiさんのツイート: "Redmineのコミッターは実質2人だけ。日本人コミッターまるやまさんはバグ対応しか出来ないほど追われてるので、バグ対応のパッチを送ってくれることが今一番の貢献じゃないかなと思う #redmineT #eventdots"

akipiiさんのツイート: "あなたの秘蔵パッチも本家にあげて欲しい。一度マージされれば、その後は本家が保守してくれる。 #redmineT #eventdots"

akipiiさんのツイート: "スクリーンショットは英語モードで添付して欲しい。本家の人達は海外の人だから。 #redmineT #eventdots"

松谷　秀久さんのツイート: "英語がハードルの方はGoogle groupのRedmine users(japanese)へどうぞ https://t.co/sdeNF9xQ0T"

redmine.tokyoやRxTStudyというユーザコミュニティも、Redmineのバグ報告や機能改善の提案などのフィードバックが行えればと思う。

【2】ViewCustomizePluginはとても面白いプラグインだ。
フック処理を上手く使ってRedmineの表示処理を自由に制御できる。
Redmineコミッタから見れば、邪道なプラグインかもしれないが、Redmine運用管理者にとっては非常に、かゆい所に手が届きやすいプラグインだろうと思う。

なぜなら、ちょっとした表示処理を微修正するために、Redmine本体のソースにパッチを当てたり、プラグインを追加するとなると、RedmineのDBマイグレーションやRedmine再起動が発生したりするからだ。
@netazoneさんが講演されたように、ユーザが会社全体に広がり、海外の工場でも使われ始めると、Redmine再起動のタイミングがなくなってしまうからだ。

ViewCustomizePluginを使った事例のうち、聞いた話では、金額にカンマ表示させたり、二つのプルダウンのカスタムフィールドの値同士に関連の制御をかける事例を聞いた。
たとえば、OSと.NETバージョンの二つのプルダウンに関連がある場合などだ。

ViewCustomizePluginは他の利用シーンでも使えるので、利用シーンごとに表示処理をカスタマイズするJQueryのソースが整理されると面白いだろうなあと思う。

【3】「メトリクスの見える化」というテーマは、今回の勉強会の参加者に聞くと、食い付きが良かったらしい。
話を聞くと、Redmineに溜まったチケットデータを集計する作業を実際にExcelでやっていたり、メトリクス集計をしたいがどんな方法が効果があるのか知りたい、という人が多かったみたい。

そもそもRedmineに興味を持つユーザ層は、プロジェクトリーダーやPMOクラスの人なので、ソフトウェアメトリクスによる進捗・品質の見える化は一度はやってみたいテーマなのだろうと思う。

【3-1】GnuPlotによるメトリクスのビジュアル化スクリプトの話は興味深かった。
仕組みとしては、PerlスクリプトでREST API経由でRedmineチケットデータを全件取得してCSV形式に加工し、GnuPlotにデータを食わせて画像表示して、RedmineのWikiに「ダッシュボード」タブを作って、メトリクス専用のWikiに最新表示させておく。
ダッシュボードの新規タブを作るには、Wiki Extensionsプラグインを使っているらしい。

Wiki Extensions - r-labs

松谷さんのPerlスクリプトでは、平均完了日数、最大放置日数をRedmineプロジェクト単位にメトリクス出力して、GnuPlotでヒストグラムや折れ線グラフ、散布図などで表示させる。
さらに、WikiListプラグインを使って、GnuPlotの元ネタとなるCSVデータを表形式にWikiで表示し、さらにそこから詳細はチケット一覧のクエリへリンクさせるようにしているらしい。

Wiki Lists - Plugins - Redmine

そうしておけば、たとえば、最大放置日数が多いチケット2件はどのチケットか、そのチケットを最優先で対処すべき、という意思決定が容易に行えるようになる。
また、1週間毎に平均完了日数と更新チケット枚数を折れ線と棒グラフで表示させて、平均完了日数が週ごとに短くなっているならば、チームが学習して開発速度が上がっている、という評価もできる。

この使い方は面白い。

また、GnuPlotで、信頼度成長曲線の関数を使えば、チケットの情報を渡せば、信頼度成長曲線の定数値を自動計算してくれるらしい。
チケットの精度やデータ数が多ければ、信頼度成長曲線の精度も上がるわけだ。

さらに、そこまで難しく集計加工する必要がないならば、Redmine Pivot Tableプラグインを使えると、Redmine上でExcelのピボット集計のような機能を実現できる。
Redmine Pivot Tableプラグインは、表形式に集計表示してくれるだけでなく、様々なグラフ形式でもビジュアルに表示してくれる。
これは便利だ。

Redmine Pivot Table - Plugins - Redmine

deecay/redmine_pivot_table: This Redmine plugin allows you to generate pivot table for issue analysis.

【3-2】楠川さんの話を聞いて、WorkTimeプラグインの「工数付替機能」の意味がようやく分かった。
どうやら「顧客向け工数報告」プロジェクトと、「チーム内の作業管理」プロジェクトで分けた運用をしているらしい。
つまり、月中は「チーム内の作業管理」プロジェクトで、メンバーは日々の作業チケットに実績工数を登録している。
しかし、顧客向け報告書に、その内容をそのまま出力して報告はできない。
なぜなら、顧客の観点では、本番障害に工数がかかりすぎ、とか、単純な問合せに対してなぜこんなに工数がかかり過ぎているの、など、突っ込みが入ってしまって、顧客に実費請求できないリスクがあるからだ。

そこで、「チーム内の作業管理」プロジェクトから「顧客向け工数報告」プロジェクトのチケットへ実績工数をコピーし、プロジェクトリーダーが、報告書の体裁に合うように、各チケットの実績工数を微修正したり、配分し直したりする。
その作業が「工数付替機能」なわけだ。
確かに、複数のWebシステム保守をやっているプロジェクトリーダーは、実費請求の作業報告書を作る時に、作業内容と実績工数のつじつまを合わせるために、月末に加工する作業にかなりの時間を費やしている。
正直、工数管理の二重管理だ、という指摘もあろうが、SIの準委任契約案件では、このようなドロドロした管理作業はよくあるので、工数付替機能は良く考えられた機能だと思う。

WorkTime - Work Time - r-labs

【4】各テーブルのフリーディスカッションは好評だった。
グループディスカッションで、参加者からRedmine運用の現状や問題点を聞いた。
一部の参加者の話を聞くと、実は、Redmineはソフトウェア開発チームのタスク管理よりも、カスタマーサポートや障害管理などの方が向いている、という意見があった。

理由は、ソフトウェア技術者はGitを使っているので、プルリクエストが使えないRedmineは使いにくい。
だから、GitlabをGitリポジトリに見立てて、IssueのインターフェイスはRedmineを使うように、RedmineとGitlabを連携している。
一方、ユーザからの問合せ対応やインシデント管理、製品のバグ報告の管理は、Redmineのチケットに登録して、ワークフローにのせて担当者に回す運用が上手く回っている、と。

つまり、Gitを使っているユーザは、RedmineのGit連携機能に完全に満足できていない。
一方、カスタマーサポートの担当者は、インシデント管理やバグ管理はRedmineチケット管理だけで十分に回る。

【5】改めて、Redmineの今後の課題の一つは、多様で大規模な組織に、一つのRedmineインスタンスでどれだけ幅広く業務をカバーできるか。
そのためには、Redmineにどんな機能が必要なのか、という課題だと思う。
参加者から数多くのフィードバックを聞いた。

【5-1】たとえば、Apacheのセキュリティバグが判明し、そのバグ修正を行うチケットがあったとする。
すると、一つの製品だけではなく、他顧客の他システム、他のパッケージ製品にもセキュリティパッチを当てないといけない。
その場合、一つのバグ報告のインシデントチケットに対し、関連する複数のシステムや複数の製品に同じ内容のチケットが複製されて、それぞれで対応していく必要がある。
なぜなら、システムごとにセキュリティパッチのリリース日が違うし、進捗も違うからだ。

しかし、発端となったインシデントチケットと、それを複製した他製品のチケットは、一つのRedmineプロジェクトで管理すべきものではない。
むしろ、各Redmineプロジェクトにそれぞれ配置すべきであるが、どのシステムに影響があるのか、漏れ無くチケット登録するのはかなり大変だ。
手作業なのでどうしてもミスが発生するリスクがあるし、インシデントのチケットと派生製品のチケットを関連づけて、各チケットの進捗やリリース日も漏れなく管理したいのに、今のRedmineでは機能や運用ルールが不十分なのだ。

【5-2】たとえば、ISO9001に即した作業管理をRedmineで運用している場合、チケットの構造はISO9001の文書に即した構造になるため、カスタムフィールドがとても多い。
しかも、一度作成した作業依頼書は、内容が似ているので、他の作業でもコピーして流用したくなる。

すると、Redmineチケットのコピー機能を使って、チケットを複製した時、コピー先チケットの登録時にコピー元チケットも関連付けられて、コピー先の担当者やウォッチャーだけでなく、コピー元のチケットの担当者やウォッチャーにも更新メールが飛んでしまう。

Redmineの運用を始めると、大量にメールが流れてしまうため、「～のチケットが関連付けられました」だけのメールは正直不要なので、メール送信から外したい。
しかし、今のRedmineの管理画面では、更新メールの制御条件は「担当者」「優先度」ぐらいしか条件がないので、色んな利用シーンで更新メールを通知させない制御ができない。
本来は、「チケット関連付けを通知する」「説明の変更を通知する」「開始日・期日の変更を通知する」「カスタムフィールドの更新を通知する」などのメール送信制御も入れたいし、プロジェクトごとに更新メール通知の制御もやりたい。

また、現在のRedmineのチケットコピー機能ではなく、単純な「チケット内容の複製」機能が別途欲しい。
終了チケットの内容をそのままコピーして、カスタムフィールドの内容をちょっと微修正して流用したい場面は結構ある。
事務処理ワークフローシステムでよくある「申請書コピー」機能と同じだ。

@netazoneさんによれば、今のバージョンのRedmineチケットコピー機能を使うと、コピー先のRedmineチケットの期日に、コピー元チケットの期日が複製されてしまうため、コピー先チケットの作成日よりも期日が古いという矛盾したチケットが作られるのは困る、と言っていた。
たしかに、チケットコピー機能はもう少し改善したい機能の一つ。

【5-3】JAXAのRedmine運用事例の経験論文では、「ロールのORルール」「カスタムフィールドのANDルール」という優れた運用ルールの説明がある。
参加者からその意図を聞くと、たくさんの部署に展開した時に、各Redmineプロジェクトにロールやトラッカーやカスタムフィールドを割り当てる時、それぞれの部署の業務ごとにそれらを作ってしまいがち。
すると、ロールやトラッカーやカスタムフィールドが50個以上ぐらい発散してしまい、似たような項目が増えていき、システム運用が回らなくなる。

そこで、「ロールのORルール」「カスタムフィールドのANDルール」を導入して、Redmineのロールやカスタムフィールドをできるだけ増やさないような運用方法を編み出した、と言う。
だから、Redmineデフォルトのロール「管理者」「開発者」「報告者」は使わず、独自のロールをいちから作った、と話されていた。
確かに、「ロールのORルール」「カスタムフィールドのANDルール」を徹底できれば、共通のロールやカスタムフィールドを組合せることで、より多くの業務を一つのRedmineインスタンスでカバーすることができるだろう。

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

【5-4】しかし、別の参加者の話を聞くと、会社のRedmineが使いづらいために、各部署ごと、さらには各チームでRedmineインスタンスをこっそり作って、自分たちの課題管理・障害管理・作業管理に使う利用事例もあるらしい。
つまり、自分たちの案件で自由に使いたいために、自分たちのためだけのRedmineインスタンスを作って、自分たちの運用ルールで回している。
すると、その会社では、Redmineインスタンスが20個以上乱立した状態になっているらしい。
その状況を「闇作業」「闇チケット」ならぬ「闇Redmine」と言っていた。

この事例の話は、一つのRedmineインスタンスで数多くの業務、数多くの利用状況をカバーできない問題があることを示している。
その原因は、Redmineの機能不足もあるだろうが、むしろ、運用ルールとRedmine機能のギャップにあると思う。

前田剛さんの話を聞くと、Redmineはそもそもオープンソース開発のためのプロジェクト管理ツールなので、幅広い多様な業務の運用に耐えれるように機能が最初から作られているわけではない、と言われていた。

おそらく、Redmineが当初想定されていた利用シーンであるソフトウェア開発の作業管理から、カスタマーサポートや事務処理ワークフローなど、数多くの業務にも適用されたことで、このような問題点が具体化されてきたのだろうと思う。

つまり、大規模な組織の多様な業務に対し、一つのRedmineインスタンスの機能や運用ルールが追いついていないから、闇Redmineのように、業務ごとに多数のRedmineインスタンスが乱立するわけだ。

でも、複数のRedmineインスタンスを作らざるをえない状況もある。
たとえば、オフショアチームや顧客には社内のRedmineに入れないので別途やり取りするRedmineインスタンスを作るしかない、という状況はよくある。
社内のRedmineには、見積りや原価の情報が記載されているので、社外には見せれない、という事情もあったりする。

したがって、一つのRedmineインスタンスで、大規模な組織の多様な業務をどれだけカバーできるか、そのためには、どんな利用シーンで、Redmineにどんな機能が必要で、どんな運用ルールを整備すべきか、という課題が今後必要になるだろうと思う。

【追記】
発表資料はコチラ。

みんなでRedmineを より良くしよう —Redmineプロジェクトへの貢献の仕方— from Go Maeda

View customizepluginを使いこなす from onozaty

ソフトウェアメトリクス概要 20160514 from Yutaka Ohwada

Redmineでメトリクスを見える化する方法 from Hidehisa Matsutani

工数把握のすすめ 〜WorkTimeプラグインの使い方〜 from Tomohisa Kusukawa

ある工場のRedmine画面カスタム【View Customize Plugin 活用例】 from Kohei Nakamura

Redmineカスタムフィールド表示改善 from Yuuki Nara