第21回 Redmine大阪の感想 #RedmineOsaka

第21回 Redmine大阪で初めて実施したオンライン勉強会が無事に終了しました。
参加者、講演者、スタッフの皆さん、お疲れ様でした。

【参考】
第21回 Redmine大阪 Online - connpass

Redmine-osaka-021 - Redmine.Osaka

第21回 Redmine大阪 Online(2020/7/11) - Togetter

RedmineOsaka 2020 夏の陣｜makoto0119｜note

第21回Redmine大阪でみんなの苦労と工夫を知る　#redmineosaka | マドびっ！ Madosan's View

【1】Redmine大阪は4月から2回延期してようやく実現できたので、スタッフの立場ではとにかくホッとした。
この3ヶ月間、世間では色々あったし、コミュニティは全てオンライン配信に変わってしまった。
そんな中、アジャイルウェアさんがZoomウェビナーを提供してくれて、redmine.tokyoのスタッフ2人が配信を手伝ってくれて、そして、3ヶ月以上も待ち続けてくれた参加者がいて、初めて無事に終わった。
特に今回は、関西在住の人達よりも、東京など遠方の参加者が多かった。

そういうことを思うと、Redmineコミュニティはすごく熱気があっていいなと思う。

勉強会の講演で興味を惹いた点をラフなメモ書き。

【2】前田さんの発表では、RedMicaに3つのプラグインを推奨プラグインとして取り込んで、開発者にフィードバックする発表があった。
それは、Issue template plugin, View Customize plugin, message customize pluginの３つ。
いずれも日本人が開発しているので、プラグイン開発者にとって、RedmineのVerUpに追随する上で品質向上に役立つだろうと思う。

akipiiさんはTwitterを使っています 「まさにそうなんですよね。RT @RyohHAMADA2: オーナー以外唯一のコミッタから推奨されるとか、称号として最強といえよう・・・ ＞ 推奨プラグイン #RedmineOsaka」 / Twitter

また、Redmineコミッタが、優れたプラグイン開発者と連携することで、Redmineの付加価値が上がることも期待できる。
そういう政治的影響として重要と思った。

【3】みうみうさんの発表では、Redmineのアンチパターンの新規概念を提唱しているように思えて参考になった。

akipiiさんはTwitterを使っています 「#RedmineOsaka ロール、権限にやたらヒエラルキーを持ち込むアンチパターン。ネーミングがいいな、使おう」 / Twitter

akipiiさんはTwitterを使っています 「なるほど、ロールや権限の機能がチームを分断するのか。RT @tw_yukia: #RedmineOsaka　Redmineって利用者をファーストステップとしてそこから開発者と運用管理者に派生していく気がするんですがはじめのステップは共通なのでSlackのチャットサロンのようなものがあるといいんだろうなとボンヤリ。」 / Twitter

Redmineのロール、権限にやたらヒエラルキーを持ち込むアンチパターンは、まさに組織文化をRedmineに押し付けるイメージ。
現場の業務、標準プロセスにこだわりがあるとはまりやすい。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka 内向きRedmine と外向けエクセルはよく聞くが、Redmine で裏プロジェクトがあるのか！」 / Twitter

Redmineで顧客向けPJと内向けPJを使い分けたくなる、というアンチパターン。
日本人しか分からない、本音と建前みたいな感じ。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka 人力ポーリングのネーミングがいいな」 / Twitter

チケットに書いているんだから、人力で常時見ておけ、というアンチパターン。

いずれも押し付けがましい感じ。

akipiiさんはTwitterを使っています 「#RedmineOsaka Redmine は、ぽーたるなどの静的情報、タイムラインなどの動的情報、ソースコードなどのリソースに３つに分類される、という主張」 / Twitter

Redmineなどのチケット管理ツールでは、情報の蓄積場所はチケットだけではない。
Wikiやフォーラム、構成管理ツール連携など色々ある。
その場合、その情報は3種類に分けられる、という主張は参考になった。

いわゆるチケット集計機能は、動的情報に相当する。
ガントチャート、サマリ、チケット一覧、カレンダーなど。
これらは、チケットの集計結果を表示するタイミングで確定する。

僕は、こういう「データの見える化」がプロジェクト管理で最重要と考えている。
なぜなら、プロジェクトは日々変化しているのに、その最新状況を把握できない、という問題をプロジェクトリーダーはいつも持っているから。
だからこそ、Redmineのようなツールが欲しくなる。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka データは鉱山。見せ方が大事。僕も、見える化が大事と思う一方、蓄積の仕方が大事という門屋さんの意見もある。」 / Twitter

一方、静的情報は、プロジェクト関係者で共有すべき情報を指す。
普通は、運用ルールや技術情報、設計思想などをWikiに書き溜めるだろう。

その場合、複数のチケットに記載された情報から、蒸留した情報をWikiで共有したくなる時がある。
プロジェクト特有、システム特有、チーム特有の情報は、実際に活動したノウハウとしてまとめて、今後に役立てたいから。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka そう、蓄積した情報を蒸留した情報も欲しいんだよね。自動化できればいいけど」 / Twitter

他方、リソース情報は、ソースコードや設計書など、構成管理で管理すべき成果物。
チケット管理ツールは、チケットとSCMのトレーサビリティの機能によって、その付加価値を高めている。
Excelではできない芸当。
個人的には、このトレーサビリティ機能を何らかのサマリ機能として表現する機能が欲しい、と思っている。

【3】junoさんのLTでは、DockerでRedmineと10個くらいのプラグインを入れた環境を作る話。
講演のストーリーは簡単かもしれないが、個人的にはとても重要と思っている。
理由は、Redmineとプラグインはバージョン依存があって、構築するのにかなり手間がかかるからだ。
本来は、Redmineを使いたいだけなのに、RubyやRailsにハマってしまうのはナンセンスだから。

akipiiさんはTwitterを使っています 「#RedmineOsaka DockerでRedmine＋プラグイン込みの環境を作る事例。初心者にとっては、プログラミングしたり、アプリを動かす前に、環境を構築する時に挫折してしまう。やはりRailsの環境は癖があるので、Dockerで環境を丸ごと作ってしまうのが吉と思う。」 / Twitter

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka Redmine のラストワンマイル問題。優れたプラグインがあっても、環境構築が難しい。ホントこれ。」 / Twitter

この話は、Redmine運用に限らず、Railsアプリの開発でも同様の問題はある。
RubyもRailsもバージョンアップが激しい為に、機能は便利なのだが、開発環境やプログラミング環境を構築するのが初心者には難しい。
PythonのAnacondaみたいに、1個のパッケージを入れたら、RailsもRedmineもプラグインも簡単に動く、みたいな環境があればいいなと思う。

【3】パネルディスカッションでは、@ryouma_nagare さん 、@Madowindahead さん, @seizukio さんと「チケット駆動で成長し組織文化を変える」を発表した。
前回の東京で話せなかったネタをもう一度話すことができた。

内容は第21回Redmine大阪でみんなの苦労と工夫を知る　#redmineosaka | マドびっ！ Madosan's Viewの通り。

【4】懇親会でみうみうさんから、Redmineコミュニティでは管理者の観点の話が多すぎる、利用者の観点の話をもっと入れてみるべきでは、と言われた点が気になった。
この話は、Redmineコミュニティではもっと初心者向けの入門的な話を入れた方がいいのでは、という声が以前からあがっていたのに、なかなか実現していないからだ。

個人的な意見としては、テーマが偏らないレベルであれば、今のままでもいいかな、と思っている。
理由は、現在のRedmineの利用層はプロジェクト管理者や情報システム部門の人達なので、彼らに提供できる価値ある話をコンテンツに集めた方がいいから。
一方、Redmineの利用者の人は、受け身の立場なので、どうしても利用する以上のメリットがあまり感じられないように思えるから。

他に、みうみうさんと話していて気づいた点は、僕の興味は、Redmineの導入の手段ではなくて、Redmineをどんな場面で使うとより効果的なのか、自分がまだ知らない未知の使い方はないのか、Redmineを使ってプロジェクトをスムーズに進行させるだけでなく、チームやメンバーをRedmineでいかに変化させるか、にあることだ。
だから、Redmineの導入でなかなか浸透しない、という問題の解決はたしかに重要だけれど、その話だけにならないようにしたいと思っている。

実は似たような議論が、つい数年前までアジャイル開発の導入に関する話であった。
日本でアジャイル開発を導入・運用する事例やその講演では、いつも、アジャイル開発の導入のために現場の反対をいかに抑えて浸透させるか、という問題ばかりを10年以上もずっと話しているだけ、という指摘があった。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

つまり、日本のソフトウェア開発のコンテキストでは、いつもアジャイルの導入部分の話ばかりで終わっていて、アジャイル開発を実践した後に、アジャイル開発にどんな可能性があるのか、その先にどんな世界が待っているのか、という議論が日本では欠落している、という指摘だ。

日本のアジャイルは導入部分ばかりで終わっている: プログラマの思索

よって、Redmineの導入に関する話の議論もこの方向の罠にハマってしまいそうで怖いと思っている。
本来は、導入が目的ではなくて、その先のメリットや、一段レベルが上った所での新たな課題解決を目指すべきはず。
たとえば、僕が議論したり考えたりしたいのは、Redmineの背後にあるチケット駆動開発はどんなメリットがあるのか、チケット駆動開発にはこういう可能性があるのにまだ実装できていない機能は何なのか、ということだ。

同様に、Redmineの利用者向けの話も、どうしてもRedmine導入のハードルを下げるための議論だけにハマってしまいそうな気がしている。
この辺りは色々議論してみたい。