« 第11回東京Redmine勉強会の見所 | トップページ | アジャイルな組織構成の記事のリンク »

2016/11/27

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT

第11回東京Redmine勉強会が無事終了しました。
60名以上の参加者、10人の講演者、10人のスタッフの皆さん、お疲れ様でした。
感想をラフなメモ書き。

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

第11回勉強会 - redmine.tokyo ~「Redmineの多用性とその進化」(2016/11/26) - Togetterまとめ

第11回東京Redmine勉強会の見所: プログラマの思索

【1】今回の勉強会では、LTを含めて10人の講演があって盛り沢山でした。
Redmineの運用事例や技術事例がこれだけたくさんあること、参加者も多いことを考えると、Redmineのマーケットはかなり広がっているのだろう。

グループディスカッションで参加者の属性を聞いてみると、Rubyエンジニアは少なく、情報システム部門でRedmineのシステム管理者、Redmineのインフラ運用担当者、自社内の部署にRedmineの運用を啓蒙活動している人達が多いように感じた。
他に、Redmineプラグイン作者、Redmine本を出版した経験のある人、Redmineのサービスやカスタマイズを行なっているベンダーの方もいるので、多用な属性を持つ人達がいるおかげで、場がとても盛りがったと思う。

もちろん、これから社内にRedmineの利用普及を考えている参加者もいたので、今回のテーマ「Redmineの多用性とその進化」は参考になったのではないだろうか?

kazuphさんのツイート: "Redmine Plugin開発者と本体のチケットをいじれる人、本を出版した人がいる会場。ものすごくRedmine偏差値高い。 #redmineT"

kuniさんのツイート: "redmine勉強会行って来ました。自分はこれから社内で広めていく立場なので、色んなシステムを構築している人達がいて励みになりました。次も参加したいです(*^^*)"

【2】@kazuphさんのIOT企業におけるRedmine運用事例で面白いと思った点は二つ。

【2-1】一つは、ソフト屋とハード屋では、チケット管理の観点や粒度が異なること。

ソフト屋のチケットの粒度はせいぜい数時間単位のものが多く、小さい。
だから、チケットもすぐにCloseされて、毎日の進捗もすぐに見えやすく、はかどっている感じが分かりやすい。

したがって、カンバンLikeなチケット管理の運用の方が回りやすい。
だから、Agileプラグインのように、カンバンボードのようなRedmineプラグインが重宝される。

一方、ハード屋はガントチャートが大好き。
ガントチャートでスケジュール管理を見たい。
その動機にも理由はある。

なぜなら、仕入→設計→製造→品質チェック→出荷の生産プロセスでは、どうしても各工程で作業待ちのリードタイムが発生しがちなので、チケットの粒度は大きくなりやすい。
たとえば、部品や原材料を発注して入荷するまでに、数日間のリードタイムが発生するので、設計や生産プロセスのチケットはすぐに着手できず、チケットの粒度は数日~数週間のレベルになりやすい。

したがって、ガントチャートで見る方が、作業予定やクリティカルパスを把握しやすい。
むしろ、かんばんで作業を管理すると、毎日のチケットの動きが少なく見えるために、経営者から見ると、作業が遅れているように見えて問題になるらしい。
つまり、リードタイムの長いチケットが滞留してしまって、目立ってしまうらしい。

すなわち、ソフト屋はアジャイル開発、ハード屋はWF型開発にどうしてもなりやすい。
特に、ハードウェアの作業は、特殊部品の納入がなければ生産できないとか、高価な機械が1台しかないので生産の稼働率が限定されてしまう、などの問題がどうしても出てくる。
すなわち、各工程の作業でリードタイムという作業待ち時間がどうしても発生する。
したがって、ハード屋のチケット管理では、事前にチケットで先行・後続関係を設計して、各工程のリードタイムが長くならないように、ボトルネックが発生しないように、生産計画の精度を高める必要が出てくる。

その観点が、チケットの粒度やガントチャート重視につながってくるわけだ。
そう考えると、チケット管理にTOCの発想を取り入れて、ボトルネックの稼働率を高めるようにチケット管理できないか、とか、CCPMのプラグインがあれば、とか思ったりする。

【2-2】もう一つは、社内にRedmineに相当詳しい人がいたおかげで、Redmineの運用がスムーズに進められたこと。
社内のRedmineエバンジェリストである彼がすぐにAWSにサーバーを立ち上げて、すぐにRedmineのワークフローなどを初期設定してくれて、すぐに運用可能な状態になった。
そして、Redmineエバンジェリストが勝手に動いて、Redmineのベストプラクティスはこうなんです!と強く主張して、社内のサポート部隊や事務員に説明会を開催して、Redmineの啓蒙活動をしてくれたらしい。

お話を聞くと、中途入社されたSEがRedmineに相当詳しかったそうで、Redmineの立ち上げ、設定、運用、プロセス標準化、ベストプラクティスのノウハウを既に持っていたらしい。
だから、Redmineの使い勝手に関する改善要望もそのエバンジェリストが受け付けて対応してくれたらしく、Redmineの利用度も上がっていったらしい。
以前はSlackに課題が上がっていて、Slackの内容をチケットに転記していたが、現在は、Redmineのチケットに直接記入する運用に自然に定着したらしい。

その話を聞くと、Redmineの啓蒙活動を行うRedmineエバンジェリストが社内に必要なのだ、と思う。
そういう人がいるので、サポートデスクの作業管理や課題管理などで困っている、という話があっても、すぐにRedmineを立ち上げてくれて、その日のうちから運用を開始できる手軽さがある。
しかも、チケット駆動のベストプラクティスはこれだ!というノウハウもネット上に溢れているので、自分なりに運用手順をWikiにまとめておけば、すぐに社内メンバに説明会を開いて普及を促進することもできる。

IT技術者なら問題無いだろうが、工場の作業員やサポートデスク、事務員の人はチケット管理にそんなに慣れていないだろうから、そういう説明会などのフォローは重要だ。
この辺りはいわゆるERP導入時に、ユーザ説明会によるフォロー作業と同じ。

【3】@mattaniさんの講演は、Redmineを簡易CRMとして使う話も面白い。
Redmineをカード型データベースとみなし、チケットをサーバー情報や問合せ情報のマスタとみなす。
つまり、チケットでマスタ管理している。

また、「チケット in チケット」というアイデアで、チケットの説明欄にWikiListプラグインを用いて、特定のチケット集計をサマリ表示させることで、カード型DBとして使っている。
さらに、ViewCustomizeプラグインを使って、カスタムフィールドを説明欄の下部に配置したり、プロジェクトメニューでプロジェクトを選択したタイミングでチケット一覧に遷移するように工夫している。

あくまでもCRMの簡易版の利用事例だが、ViewCustomizeプラグインを駆使したり、運用ルールを工夫すれば、CRMの代替機能としてRedmineを使うこともできるだろう。

【4】アジャイルウェアの堂端さんの講演では、20数個の野良Redmineを1個のRedmineに統合した事例。
プロジェクトは1400件以上、履歴は100万件以上、ワークフローの遷移が6万以上という野良Redmineをデータ移行して、一つのRedmineに統合できたとは恐れ入る。
しかも、統合作業をプラグイン化したらしい。

乱立してるRedmineを一つにまとめる話 · GitHub

あきこさんのツイート: "お客様の現場を舞台にした複数Redmineの統合のお話。20台以上乱立してて管理者も別。プロジェクト単位でRedmineインスタンスが立ち上がっている。でも実際は1台の物理サーバに乗っかっている!Oh! #redmineT"

松谷 秀久さんのツイート: "20台のRedmineサーバを統合するのはけっこう骨が折れそう/心も折れそう #redmineT"

あきこさんのツイート: "2ヶ月くらいかけ休日を中心に調整。最大のものは48時間くらいで統合できた。統合後のRedmineの規模がものすごいことに!プロジェクトは1400件以上、履歴は100万件以上。ワークフローの遷移が6万以上。。。でも、一元管理することで見えてきたものがある。#redmineT"

野良Redmineをデータ移行して統合するポイントはいくつかあるらしい。
話を聞くと、SQLiteの中間DB上で、それぞれの野良RedmineのチケットIDを変換して、統合Redmineへデータ移行するように設計したらしい。
確かに、ERPのマスタ移行でも、中間テーブルでユーザCDや商品CDを変換するバッチプログラムをよく作ったりする。

あきこさんのツイート: "統合の苦労話スタート!課題1: IssueIDがDBの自動採番に基づくため番号が重複する。課題2: トラッカーが色々。賢いエンジニアさんが統合用のツールを作った!!(すばらしいー)IssueIDが記載されているあらゆるテーブル、フィールドを検索して書き換え。#redminet"

但し、Redmineでは特有の課題がいくつかある。
たとえば、チケットIDがWikiやコミットログなどに散在しているので、それらも一括置換する必要がある。
たとえば、添付ファイルは別ディレクトリに保存されているので、それらも考慮する必要がある。
たとえば、Wikiの記法がTextileやMarkdownなどで混じっていた場合はどうするのか?
たとえば、Redmineプラグインが多数使われていた場合は、大丈夫なのか?

やっさんさんのツイート: "tail -f pinzo.log: RedmineでMarkdownに切り替えやすくするプラグインを作った これで任意にMarkdownとTextile切り替える出来ますよ #redmineT https://t.co/t4fJGRTbR0"

話を聞くと、野良Redmineは、最初に作られたRedmineをベースに各部署で作られたのでどれもバージョンが同じだったので、マシだった、とのこと。
また、野良Redmineを統合するRedmineプラグインとして作成したが、Redmineのバージョンに依存するので、他のバージョンで使うにはカスタマイズが必要であるらしい。

おそらく、統合プラグインは、データ移行処理をrakeによるバッチ処理で実装しておき、プラグイン設定画面で初期設定して、移行作業をキックする仕組みではないかと想像する。
実際、MantisやTracからRedmineへ移行するrakeタスクがRedmineにあるので、それを参考にして流用できるはずだ。

RedmineMigrate - Redmine

また、RedmineRake - Redmineには、添付ファイルを移行するrakeタスクもある。

野良Redmineをデータ移行できる統合プラグインは、有償プラグインであってもニーズはすごくあるだろう。
アジャイルウェアで販売しないのかな?

【5】Redmineのバージョンアップに関して、@g_maedaさんと@netazoneさんの事例があった。
やはりRedmineプラグインを入れていると、Redmine本体のバージョンアップに追随できなくなるらしい。

あきこさんのツイート: "プラグイン大量死の歴史!!!1.3系でルーティング変更、1.4系でbundler, 2系でRails...., jQueryへの変更.... #redmineT"

マサユキ@C91 2日目(金)東ア25bさんのツイート: "2011年、2012年を乗り越えたて現存するプラグインは歴戦の勇士ということか。redmine公式にあるプラグイン紹介で登録日が4年前とか #redmineT"

過去の歴史を振り返ると、Railsのバージョンアップ、Prototipe.jsからJQueryへの変更など、プラグインが大量死するタイミングが4回以上もあった。
最近は、RedmineでScrumを運用できるBacklogsプラグインがついに放置された。

個人的には、プラグインを使う時は、Redmine勉強会に参加しているプラグイン作者のプラグインに限定するようにできるだけしている笑。

1点気になったのは、@netazoneさんの事例で、@akahane92さんのチューニング手順を元に、@clearcodeさんの全文検索プラグインを入れた所、全文検索がかなり高速化されたらしい。
Redmineに残された弱点の一つが、検索ボックスからの全文検索が遅い点なので、ますます@clearcodeさんの全文検索プラグインは使いたくなってくる。

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

【6】@akiko_pusuさんのRedmineプラグインのテスト方法の事例も興味深かった。
testunitでRedmineプラグインのテストを自動化した動機は、OSSと言えども問合せが多いので、それを削減したい。
たとえば、プラグインのインストールで詰まった、とか、バージョン依存で動かない、とか。
プラグインと言えども、テストの自動化は、ソフトウェアの品質を高めるのに役立った、と。

@akiko_pusuさんの事例で参考になった点は、OSSのアプリであれば、フリーで使える開発基盤のWebサービスがたくさんあることだ。
CIツールwerkerや静的コード解析SideCIなど、色々あるらしい。
そういうのを聞くと、趣味で開発するOSSツールは、これらフリーの開発基盤を使いまくる方が、作業も効率化できるし、品質も向上できるメリットがある。

【7】グループディスカッションや懇親会で参加者と話をすると、自社でRedmineを普及させる役職の人たちが多く、既にその活動を行なっていて、数多くのノウハウを蓄積しているように見受けられた。
つまり、彼らはRedmineエバンジェリストとして、社内でRedmineを利用しやすくしたり、プロセスの標準化や作業の効率化、プロジェクトの見える化を実現するように活動しているみたい。
たとえば、自社の各地方にある事業所へRedmine説明会を毎回開催するとか、各部署にRedmine説明会を開いている、みたいな話が出ていた。

その活動を通しているうちに、Redmine特有の癖、いろんな業務におけるチケット管理のノウハウなどの知見がたまり、その内容を経験事例として発表されている人達もいる。
そういう話を聞くと、Redmineが日本のSIの現場で普及するにつれて、日本各地でRedmineエバンジェリストが出現しているように見受けられる。

そういうRedmineエバンジェリストが社内にいると、Redmineの立ち上げや社内説明会のコストが低いので、非常に運用しやすくなるだろう。
また、チケット管理はRedmineでなくても、JiraやTrelloにもノウハウを流用できるだろうから、チケット駆動開発という概念をより普及しやすくできるだろう。

個人的には、各地でRedmineエバンジェリストがバラバラに活動してノウハウが閉じこもっている状況を打破して、勉強会のようなオープンなコミュニティで、それらノウハウを情報共有できるようにしたい。
そうすれば、今からRedmineを使う初心者も参考になるし、既に運用中の経験者にも参考にできる情報を提供できるだろう。
つまり、現場の業務改善のツールの一つとしてRedmineがあるので、Redmineの運用で蓄積された皆のノウハウをベストプラクティスとしてまとめてみたいのだ。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。皆様ありがとうございました。改めてRedmine は多分日本人好みのツールなのだろうと感じた。自分達の現場で業務改善したい時に手元にフリーでそれなりに使えるツールがあって、現場に部分最適するのは日本人の得意技。"

【今日の資料はコチラ】

|

« 第11回東京Redmine勉強会の見所 | トップページ | アジャイルな組織構成の記事のリンク »

Redmine」カテゴリの記事

コミュニティ」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

先日はお疲れ様でした&ありがとうございました

>現場の業務改善のツールの一つとしてRedmineがあるので、
>Redmineの運用で蓄積された皆のノウハウをベストプラクティスとして
>まとめてみたいのだ。
については、私も貢献できますので今後ともよろしくお願いします

いろいろ相談させてください

投稿: Madowindahead | 2016/11/30 16:12

勉強会は楽しかったですね。
是非、意見交換させて下さい。
Redmineエバンジェリスト分科会をredmine.tokyoで開催してもいいかもしれませんね。

投稿: あきぴー | 2016/11/30 19:31

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 第11回東京Redmine勉強会の見所 | トップページ | アジャイルな組織構成の記事のリンク »