第13回東京Redmine勉強会の感想～『Redmineの今と未来』 #redmineT

昨日の勉強会は参加者、スタッフの皆さん、お疲れ様でした。
あいにくの雨にもかかわらず、参加率が約90％で大変盛り上がりました。
楽しかった余韻が冷めないうちに、感想をラフなメモ書き。

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

第13回勉強会 - redmine.tokyo ～『Redmineの今と未来』（2017/11/18）　#redmineT - Togetterまとめ

redmine.tokyo 第13回勉強会 - connpass

“CODA” チケット管理システム | JSS2@JAXA

【1】数多くの参加者に感想を聞いた所、JAXA様の講演が聞きたかった、という話もあったが、LTも含めて運用事例からプラグイン開発などの技術、最新バージョンの紹介、ちょっとしたプラグインの利用事例、家庭内のRedmine利用事例など、幅広いテーマで面白かった、という話があった。
また、参加者層も初心者から10年近い利用者まで、年代層も20歳から40代まで幅広かった。

akipiiさんのツイート: "#redminet 今日も参加率90%で驚異的でした。利用事例から技術まで幅広いテーマで面白かったと言う声をたくさん聞けてスタッフ一同嬉しいです。参加者層も初心者より数年経験者の人が半数以上いた。Redmineコミュニティが今後も長続きできるといいなと思う。"

さらに、女子の参加が10名を超えたのも初めてではないかと思う。（正確に数えてない）

akipiiさんのツイート: "#redminet 今日の東京Redmine 勉強会は過去最高で女子率が高くて華やかだったと思う。以前、@agilekawabata さんが、Redmine はおっさんのツールだから若い人や女子は少ないんですよ、と言ってたが、時代が変わった？"

第7回Redmine.tokyoの感想 #redmineT: プログラマの思索

そんなことを振り返ると、多種多様な年齢層や女性という人口的変数、プロジェクトリーダーだけでなくSEPG等の品質保証部の人からプラグイン開発者までの心理的変数というセグメントが幅広くて、たくさんの化学反応があって面白かったと思う。
幅広い利用者が集まるコミュニティになれば、ある人はRedmineを使っているなら常識と思っていても、他の人にとっては新鮮な内容であることも多いだろうから、そういう数多くの議論が発生して、さらに理解が深まるだろうと思う。

たとえば、Redmineのそんな所でつまずくのか、という質問が、実はRedmineというツールではなく、プロセス保証やプロジェクトマネジメントの根本的な問題に触れていたり、とか。
僕も色々気づきがあった。

【2】JAXA様の利用事例で、興味深い点は二つある。

“CODA” チケット管理システム | JSS2@JAXA

【2-1】一つは、フローの管理とストックの管理を明確に別々に分けていること。

akipiiさんのツイート: "#redmineT JAXAでは、議事録はチケット、構成管理すべき文書は、文書管理機能、実際はDMSFプラグインで管理を区別してる。フローの管理はチケット管理、ストックの管理は構成管理ツールでなく文書管理プラグインで制御してる。全文検索プラグインで文書も全文検索できると、かなり良… https://t.co/AVf8WAHtsc"

Redmine本来の設計思想では、日々流れるフローのような管理対象はチケットにする。
タスク、かんばん、ISOの変更依頼書のように、作業指示書のようなレベルのものは、ステータス管理の方が重要だ。
つまり、日々のフローで管理する時、担当者とステータスに着目する。

一方、ストックのような管理対象は基本は、GitやSubversionのような構成管理ツール、あるいはWikiに蓄積する。
たとえば、ソースコードやExcel設計書は構成管理ツールの配下で履歴管理したり、技術や共有情報などのナレッジはWikiに蓄積する。
あるいは、チケットそのものを議事録にしたり、障害管理票のようにチケットに障害の発生原因や修正履歴を追記して、チケットそのものをナレッジにしてもいい。

Redmineのメリットは、フローとストックの管理を一つのツールで一元管理できるので、フローとストックの間で相互リンクを貼ることにより、トレーサビリティを実現できることだ。
よって、成果物から要件の発端まで前方追跡して変更理由を探したり、発端となった要件から成果物まで後方追跡して仕様変更の影響範囲を探る、といった使い方ができる。
この運用ルールが「No Ticket, No Commit」であり、他のプロジェクト管理ツールにないチケット管理ツール特有の最大の特徴でもある。

しかし、JAXA様の運用では、ストックの管理はRedmineの文書管理にDMSFプラグインを入れて活用されている。
この点がRedmine本来の設計思想と大きく異なる。

その理由を推測すると、成果物の対象がExcelであるため、構成管理ツールだけでは文書の変更の権限制御がやりにくい点があるのだろう。
そこで、DMSFプラグインを入れることで、Excel文書の変更履歴を残したり、Excel文書の参照・更新の細かな権限制御を付けることで、より使いやすくしているわけだ。

たとえば、外部委託したベンダーには特定のExcel文書は参照権限はあるが、更新権限は与えない、といった使い方をしたい場面があるのだろう。

【2-2】もう一つは、Redmineではボトムアップで運用ルールを柔軟に変更して、より良くしていく手法がある点。
Redmineは管理画面にあるワークフロー、ロール、トラッカー、カスタムフィールドを細かく制御できるので、運用しながら標準プロセスを固めていくことも可能だし、そういうやり方の方が普通なのではないか。

akipiiさんのツイート: "#redmineT Redmine の良さは、管理機能をフレキシブルに変更できる点。実際の運用は、かなり試行錯誤した、とのこと。プロセス標準化は一夜にしてならず、ですね"

akipiiさんのツイート: "#RedmineT 更新ロールと参照ロールに分ける。基本ワークフローは、全般トラッカーと名付けて、プロジェクトごとでカスタムフィールドを切り替えて利用する。つまり多様なプロジェクトの構造を管理画面の機能で制御するわけだ"

たとえば、Redmineの基本ロールは「PJ管理者」「開発者」「報告者」だけだが、実際に運用してくると、PJ管理者とシステム管理者の間のロールが欲しくなってくる。
その場合、「ロールのORルール」を用いて、「システム管理者でない管理者」のロールを新規作成し、各プロジェクトで各ユーザにそのロールを追加付与すればいい。
すると、既存のロールをいじることなく、既存ロールにパッチを当てる感じで、権限を細かく制御できるようになる。
たとえば、基本ロールと追加ロール、参照ロールと更新ロールのようにロールを細かく作っておけば、ロールのORルールを適用して、数多くのバリエーションで権限制御できるようになる。

すなわち、運用で試行錯誤しながら、ロールやワークフローを再定義したい時に、Redmineではパッチを当てる感じで既存の運用フローを修正していくことが可能なのだ。
こういう運用が可能な理由は、Redmineの管理画面の機能が豊富で柔軟であるからだろう。
換言すれば、Redmineの豊富で柔軟な機能をもっと理解しておけば、最初からトップダウンで完璧な運用を目指すのではなく、運用しながら標準プロセスを固めていく、といった、アジャイル的な発想を取り込めるはずだ。

僕はアジャイル開発が好きなので、ソース修正だけでなくプロセス構築にもアジャイル的なやり方を組み込むことは、実現不可能と思っていないし、むしろ、トップダウンでガチガチに固めてしまってメンバーのやる気を失わせるよりも、メンバーのより良い意見を取り入れながらチーム一丸でRedmineをより良く使いやすくしていくことは可能だと思っている。

【3】前田剛さん、堂端さんからRedmineの次期バージョン4.0に関する講演があり、興味深かった。

Redmineウォッチャーとしては、Railsの最新バージョンに追随する形でRedmineもどんどん最新化して欲しい。
性能面、セキュリティ面、今後の機能追加のしやすさ、を考慮すれば、開発基盤の最新バージョンに追随して欲しいから。
講演によれば、Ver4.0は早めにリリースしたい、とJPLが言っていた、とのこと。

Ver4.0で問題になってくるのは、既存プラグインがそのままでは、ほぼ使えなくなることだろう、とのこと。
Rails5に追随できるようにプラグインの修正が必ず発生する。
過去のRedmineのバージョンアップでも、追随できなかったプラグインは数多くあったので、利用ユーザは注意すべきだろう。

前田剛さんのアドバイスでは、古いRedmineはあらかじめVer3.4へVerUpしておくべきこと。
理由は、Rails5ではRuby2.2.1未満は切り捨てられるので、Ruby2.2.1に対応済みのVer3.4のRedmineで動作できるようにしておくと事前に検証できるから。

【4】他の講演も面白かった。
Redmineの利用が深まる中で、色んな問題意識があげられていて、興味深かった。

RedmineとSlackなどのコミュニケーションツールは、どのように使い分けた方がいいのか？

お子さんの宿題管理にRedmineを適用し、EVMや分析を行ったが結局使いこなせなかった、とのこと。
このLTも、普段のRedmineとは違う観点で面白い、という別の参加者の感想もあった。
個人的には、Redmineが使いこなせなかった理由には、Redmineが見れるPCをお父さん部屋しか置かず、子供の導線上で見える化しなかった点もあるのでは、と思った笑。

akipiiさんのツイート: "お母さんの反省点はRedmineが見れる端末を廊下と子供部屋に置くことかな笑。RT @agilekawabata: お母さんの反省会で導線が大事だったということで、JAXAの事例にもあったように、ホーム画面に担当者が必要となる導線を置くことはとてもいいと思う #redmineT"

【5】Redmineの面白さは、プロジェクトリーダーや品質保証部の観点でプロセスを自分で構築できて運用を試せる一方、プログラマの観点で不足機能をカスタマイズしたりプラグイン開発してより使いやすくできる、という両面があることだろうと思う。

すなわち、前者の観点では、Redmineは標準プロセスの運用基盤またはメトリクス収集・集計のプロセス基盤である一方、後者の観点では、Redmineはプロジェクト管理ツールの汎用的な開発基盤とみなせることだ。
つまり、ソフトウェア工学の観点とRuby開発の観点の両面からRedmineをいじくり倒せる点が、面白い点なのだろうと思う。
そして、その両方に詳しい人はほとんどいないので、Redmineコミュニティで多種多様な人達が集まることで色んなメリットが出てくる。

僕もRubyやRailsをちょっとずつ勉強しなくては、ね。。

他の資料はコチラ。

Redmine次期バージョン 4.0・4.1 とその先の未来像 from Go Maeda

Redmine4時代のプラグイン開発 redmine.tokyo #13 from Sho Douhashi

第13回東京Redmine勉強会オープニング #redmineT from akipii Oga

灰かぶりチケットはシンデレラに成り得るか？ from ishikawa_mizuki

Redmine tokyo #13 LT from Asako Yanuki

View customizeてRSS通知を拡張する from Asa Morino

20171117 redminetokyo13 from 如弥 林

Redmine.tokyo 13 questionnaire from Jun Naitoh

Unofficial Redmine Cooking 闇鍋_デモ環境への発展 from Yuuki Nara