プログラマの思索

昨日の第16回東京Redmine勉強会の感想をラフなメモ書き。
疲れているのでラフなメモ。

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

第16回東京Redmine勉強会『Ver４に上げよう Redmineのさらなる進化と多用性！』 #redmineT (18ページ目) - Togetter

第16回redmine.tokyo勉強会　まとめ

redmine.tokyo 16 感想 - アカベコマイリ

redmine.tokyo 第16回東京Redmine勉強会に参加してきました。 - みずりゅの自由帳

「Redmine 4.1 新機能選抜総選挙」で紹介できなかった新機能 10選 - ファーエンドテクノロジー株式会社

【1】昨日のRedmine勉強会でちょっと嬉しかったことは、@rechiba3 さんに初めてお会いできたことと@ohnukiさんに5年ぶりにお会いできたこと。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。講演者、スタッフ、参加者の皆様ありがとうございました?? 懇親会の参加率が約7割で50人で盛り上がりが凄いと思います。今回は7年越しに @rechiba3 さんとお会いできたのが収穫でした。ユーザー層も老若男女、開発者からPMOまで幅広くて来る度に面白い"

@rechiba3 さんの下記の資料を以前読んでBlogに感想を書いたことがあったので気になっていた。

TiDDでウルトラハッピーな開発フロー実践しちゃおう！

WebディレクターによるRedmine運用事例: プログラマの思索

また、@ohnukiさんは、5年前の勉強会が大雪だった時にLTで講演して頂いたことを覚えていたから。

第6回勉強会 - redmine.tokyo

他にも@MzRyuKaさんから、懇親会でこんな話もあって盛り上がった。

みずりゅさんのツイート: "#redmineT https://t.co/XfSENoynLn 初参加、どれも凄く楽しかったけど、あえて一番を選ぶとしたら懇親会でakipiiさんとお話しできたこと。 数年前に会社のブログで書いた記事を取り上げてもらったことに、やっとお礼を言うことができました。"

チケット駆動開発の運用例part4: プログラマの思索

BlogやSNSのおかげで、実際に会ったことがなくても、すぐに仲良くなれる。
そういう場をコミュニティが提供してくれて本当にありがたい。

【2】10個以上の講演があったので、記憶に残った所だけ書き残す。

【2-1】@netazoneさん「ある工場の Redmine バージョンアップ」では、プラグイン作者にVer4.0対応を自らお願いしまくった結果、そうなったからには自分のRedmineをバージョンアップしなくては、という行動に至った気概に強く共感した。
数多くの日本人プラグイン開発者が対応してくれたからこそ、Ver4.0に安心してバージョンアップできるからだ。

つまり、Redmine本体だけでなく、主要なプラグインがVerUpに追随することは、Redmineユーザにとって非常に重要な要素である、という事実を明示していると思う。
よって、RedmineコミュニティがRedmineプラグイン開発者を巻き込んでRedmineを盛り上げていくことは、非常に重要な活動なのだ、と改めて感じた。

【2-2】@agilekawabataさん「LycheeカンバンとRedmine運用の事例紹介」では、Lycheeプラグインの機能紹介が多くなってしまったけれど、メーカーのRedmine利用事例の話に興味を惹かれた。

akipiiさんのツイート: "#redmineT 複数案件を複数チームで進捗管理するにはどうする？メーカーなら、エンジンチーム、ボディチームなどの複数チームがあるが、トラックプロジェクトと乗用車プロジェクトの親チケットから派生した子チケットは、それぞれのプロジェクトで管理したい。"

例えば、自動車メーカーでは、トラックプロジェクト、乗用車プロジェクトの2つのプロジェクトが別々にある一方、エンジンチーム、ボディチームの2チームも別々にある。
トラックプロジェクトの機能（親チケット）には、エンジンチーム、ボディチームの開発タスク（子チケット）でぶら下がるが、チームごとのプロジェクトで扱いたい。
理由は、チーム単位のタスク管理がしたいこと、各プロジェクト単位で他者には情報を見せたくないことがあるから。
現状の標準Redmineでは、Redmineプロジェクトを跨ぐ親子チケットや関連チケットは作ることができるので、ある程度は運用できるだろうが、もっと細かなニーズを実現して運用する場合は、色々問題が噴出するだろう。
おそらく、それら問題となる利用シーンでは、Redmineのカスタマイズやプラグインによる機能拡張が必要になるだろうと想像する。

つまり、複数プロジェクトと複数チームのタスク管理を横串でプロジェクト管理する手法を、Redmineが支援できる可能性がある。
そうすれば、組織をまたいだ複数案件のPJ管理のように、より大規模なPJ管理もRedmineがカバーできるようになるだろう。
本来、Redmineという一つの箱にWF型開発案件もAgile案件もデータが格納されているので、横串のデータ集計はRedmineのようなチケット管理ツールが得意な所。
その機能をさらに大規模なPJ管理にも適用していくには、Redmineにどんな機能が標準で必要になってくるのか、という問題を提起してくれた点が面白かった。

【2-3】@yassan168さんのLTでは、クラウド上でDockerを使って、Redmineを含めたサーバー構築を行った、という点が興味を惹いた。
Redmineサーバーだけでなく、リバースプロキシやDNS設定などは、オンプレサーバー上のインフラ構築作業と全く同じなのに、クラウドの方がものすごく簡単に構築できるわけだ。
オンプレミスのインフラ構築は、本当に面倒な作業だった。
たとえば、iptableをいじったり、hostsをいじったりしていたから。

しかし、@akabekobekoさんと話しながら、簡単に構築できる理由は、DockerでOSに依存しないミドルウェアの構築ができるので、後はそれらをつなぐ構成をすればいいだけ、ということで理解した。
よって、今後はAnsibleよりもDockerの方が有用だろうという気がした。

【2-4】hin-tさんのLTでは、定期的にチケット登録するプラグインを紹介していた。
営業事務の定形業務で、物忘れせずに役立つんですよ、という発言があった。
どのプラグインか忘れたので後で探しておく。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【2-5】石川さんのLTでは、message_customizeプラグインが興味を引いた。
このプラグインは、ymlに書かれた文言を修正して表示できること。
メリットは、ymlを書き換えなくても、管理画面で修正できるので、viewCustomizeプラグインに似た感覚で管理者が操作できることだろう。
すると、@netazoneさんが発した問題「海外ユーザと1個のRedmineインスタンスを共有する時、ステータスやトラッカーを日本語・英語で併記しない方法はあるか？」に対応できないか、考えてみたくなる。
一方、@g_maedaさんの話では、Redmineの画面をリロードしたらhtmlからlang=ja,enは取得できるので、その情報を元に、ログインユーザ毎に修正文言を表示できるはず、と言っていた。
たぶん、message_customizeプラグインとviewCustomizeプラグインを駆使すれば、その問題は解決可能だろうと思う。

GitHub - ishikawa999/redmine_message_customize: This is a plugin for Redmine.

GitHub - onozaty/redmine-view-customize: View customize plugin for Redmine

【2-6】堂端さんのLTでは、Redmine大阪で話したGitHub連携プラグインの続きだった。
興味を引いたのは、RedmineチケットとGitHubブランチを紐づけた後、Github上でプルリク受付、プルリク承認、masterマージという一連の作業ごとに、Redmineチケット一覧画面でチケットのアイコンが更新される機能があったこと。

つまり、GitHubからRedmineへフックさせているわけだ。
裏では、GitHubのクローンがRedmineサーバー上にあるので理解できるが、Redmineチケット一覧でプルリクのステータスをアイコンで判別できる機能は良いな、と思った。

但し、RedmineチケットとGitHubブランチを紐づける時に、「xx@#チケット番号」のようにブランチ名にプレフィックスを付ける手順がいる点は注意。

GitHub - agileware-jp/redmine_github

【2-7】@miokakusuさんのLTでは、MSのVisualStudioからTFSへチェックインする時に、Redmineチケットと同期させる仕組みを作った事例。
TFSの通知メールからRedmineとREST APIで連携する処理が面倒ですね、という話が興味を引いた。
仕掛けについては、@ryouma_nagareさんからアドバイスをもらったので理解できた。

akipiiさんのツイート: "#redmineT TFSの通知メールをRedmine がキャッチして、RESE APIで、チェックインとチケットを紐づけた。ごめん、この辺りがよく分からない。"

りょうま@redmine.tokyo終了でRedmineロスさんのツイート: "ですね。 メールサーバで受信したメールを標準出力でスクリプトが受け取る 本文解析して、チケット番号、内容、ステータスを生成 REST APIでRedmineサーバにアクセス です。メールサーバかRedmineに同居している必要もないです… "

【2-8】@naitohさんのアンケート集計では、Git利用率が下がっている点が気になった。
たぶん、Git中心で開発する場合、GitHubやGitlabだけの運用に流れているのかもしれない。
つまり、RedmineとGit連携の機能が弱い点は、今後、Redmineの弱点になってくるかもしれない。

【3】@ohnukiさんから、コミュニティ運営を褒められたことは一スタッフとして嬉しかった。

Hiroshi Ohnukiさんのツイート: "久しぶりの参加、第一印象ですが運営が素晴らしい #redmineT"

【4】Redmineコミュニティに関わって8年経つが、なぜRedmineコミュニティを継続できたのか、とふと疑問に思う。
僕はコミュニティ経験がまだ浅いけれども、過去を振り返ると、コミュニティの浮き沈みはとても激しいと感じる。
長期に渡って熱気を維持できるコミュニティは正直多くない。

その理由は、Redmineというツールが、日本における市場の潜在ニーズをうまく汲み取ってきたから、ではないかと考えた。
つまり、日本の官公庁や大企業における非効率な業務にRedmineが当てはまるケースが多いのだろう、と考える。

たとえば「プラットフォーム革命」にはこんな一節がある。
プラットフォームビジネスの機会を見つけるには、「取引コストが高い所」「複雑で見過ごされているネットワーク」「大規模で分断された未活用な資源がある所」に注目せよ、と。

この言葉を念頭に置いて、以前、CoderDojoの関係者と話していたら、まさに日本の教育業界はとても非効率な業界なので、ベンチャー企業が参入しやすいという印象を受けた。
実際、日本の学校ではIT化が進んでおらず、プログラミング教育や英語教育などの外部環境の大きな変化に揺さぶられていて、教育者だけで自力解決できず、袋小路になっている印象だ。
そんな非効率な業界だからこそ、CoderDojoなどのITコミュニティやITベンチャー企業はちょっとした改善ツールを導入するだけでも、すごく通用する。
そういう話を聞きながら、CoderDojoは本当に良いマーケットを持っているなあ、今後しばらくはその業界でビジネスをやっていけるだろう、という印象を持った。

同様に、日本の官公庁や大企業は、メールやExcel帳票の文化で凝り固まっている現場が多いので、昨今の最先端のIT企業から見れば、非効率極まりない利用シーンが非常に多く見受けられるだろう。
だからこそ、そういう業務にRedmineを単純に導入するだけでも、それなりの改善効果を得やすい状況があるのだろう、と思う。
よって、そういう非効率な市場が残っている限り、まだ今後しばらくは、Redmineは日本で根付いていくだろうと思っている。