プログラマの思索

昨日の第14回RxTStudy勉強会は、たぶん過去最高の参加者で盛り上がりました。
以下、自分の感想をラフなメモ書き。
以下、長文です。

【元ネタ】
RxTStudy #14 「Redmineの未来を考える - 機能・運用・コミュニティ」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

2016/03/5 RxTStudy #14 「Redmineの未来を考える - 機能・運用・コミュニティ」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 - Togetterまとめ

【1】@g_maedaさんの講演は、RedmineのVer3.0～3.2の新機能紹介とRedmineを作っている人々の話。
2015年の1年間で、メジャーバージョンアップ3回、取り込まれたチケット数は約190枚。
わずか数名のコミッタがオープンソースのツールを保守されているのを考えれば、かなり頑張っていると思う。

@g_maedaさんが、Ver3.2のRedmineの貢献度の調査結果を下記記事でまとめてくれている。
2016年3月現在では、事実上、JPL、まるやまさん、@g_maedaさんの3人でRedmineを保守されていると言えるのではないか。

Redmineを作っている人々 - ファーエンドテクノロジー株式会社

パネルディスカッションでも、Redmineに貢献するにはどうすればいいか、という質問があり、@g_maedaさんいわく。
Redmine.orgでは、誰でも新規ユーザ登録できるので、Twitterに改善要望を流すのではなく、Redmine本家のチケットに登録し欲しい、とのこと。
また、@g_maedaさんいわく。
2008年頃からredmine-users-jaというユーザメーリングリストがGoogleフォーラムに既にあり、今も多数の質問や要望が上がっているので、定期的にチェックされている、とのこと。

Kawabata MitsuyoshiさんはTwitterを使っています: "要望など、日本語okなRedmine Usersグループを活用しましょう。https://t.co/s3qiQ8xQXr #RxTStudy https://t.co/TYfOx3xpOV"

個人的には、日本でRedmineがこれだけ注目されているのだから、Redmineに日本人のコミッタやコントリビュータを増やしたい、と思うと同時に、自分も何らかの形で貢献できれば、と思う。

【2】@akahane92さんの講演は、昨年のredmine.tokyoの講演のリバイバル＆Ver3.2への最新評価の内容。
資料の最後には、Redmineをチューニングするための設定内容が全て公開されている。
Redmineを自社サーバーで運用している人にとっては、必見の資料だろう。

Kuniharu AKAHANEさんはTwitterを使っています: "本日の発表スライド https://t.co/wDfUAH9SCI に含まれる各種チューニング設定値データをGitHub Gist に書き出しました。お役に立てば幸いです。 https://t.co/z4hr3ceKQR #RxTstudy"

Setting_paramaters_for_Redmine_Performance_Tuning.txt

上記資料の評価結果では、Rubyは最新バージョン2.2にした方がRedmineの性能は良くなる。
Redmineも最新バージョン3.3よりもバージョン2.6の方が性能は一番良いが、3.3でもそれほど性能は変わらない。
むしろ、CSVインポート・ガントチャートの日付表示・レスポンシブ対応などの最新機能を持つバージョン3.3の方が、ユーザの利便性も高いから、バージョンアップした方が価値が上がるだろう。

からあげさんはTwitterを使っています: "RxTStudyに来てます。Redmine、Rubyを2.0から2.2にするだけで30%速くなるとのこと。OOGBCも入れるのがポイント。 #RxTstudy"

また、200万枚のチケットでも、Redmineの右上の検索ボックスで全プロジェクト横断かつ全チケット検索しない運用さえ回避すれば、Redmineは性能要件も問題ない、とのこと。

数十万チケット、数百万チケットまでRedmineにデータを蓄積すれば、Redmineは単なる情報システムではなく、一つのナレッジマネジメント・システムと言えるだろう。
Redmineがそれほどの大量データを蓄積したとしても、チケットの入力・参照・検索機能はユーザの利便性にほぼ問題ない、という評価結果は心強い。

【2-1】パネルディスカッションでは、仮想環境のRedmineでは性能は本当に良いのか？という質問があったが、@akahane92さんいわく。
データ移行やバックアップ、システム移行のことを考えると、仮想環境で構築した方が運用面でメリットがある。
仮想環境なら、Redmineまるごとスナップショットを定期的に取るだけでバックアップできるから、サーバーが落ちたとしても、最悪でも自分のノートPCで仮想環境のRedmineを起動することもできる。

また、手作りのサーバーと仮想環境を比較したが、性能はむしろ仮想環境の方が良い。
なぜなら、手作りのサーバーの場合、OSやミドルウェアのセットアップを最初から行い、チューニングしなければならないが、仮想環境なら、既にチューニング＆初期設定されたOSやミドルウェアをコピーすればいい。
チューニングの評価も、いくらでもインスタンスを作って試行運用すればいいから、と。

上記資料はありがたいことに「CC Attribution-NonCommercial-NoDerivs License」で公開されているので、自社の業務にRedmineを導入・評価する人は上記資料を参考データとして使えるし、社内の説得にも使えるだろう。
自分たちでわざわざ、Redmineの性能評価をしなくても、@akahane92さんの資料を添付しておけば、社内にいるRedmineに懐疑的な人でも少なくとも、性能要件については納得してもらえるだろう。

【3】僕も久しぶりにRedmine運用について講演した。

実績工数管理システムとしてRedmineを使いたいというアイデアは既にBlogにも何度も書いてきた。

Redmineは実績工数管理システムになりうるか: プログラマの思索

Redmineの合計予定工数と合計作業時間の表示機能: プログラマの思索

【3-1】実績工数管理システムとしてRedmineを使いたい背景は、3つある。

一つは、実費請求の準委任契約の案件で、作業報告書をまとめて出力する時に使いたい。
2つ目は、数多くの小粒のシステム保守を抱えている保守チームが、月末の作業報告書を出力する時に使いたい。
3つ目は、社内に常駐する協力会社のメンバーの当月の作業報告＆請求書に対し、自社の勤怠システムの作業工数や作業スケジュールと比較照合する時に使いたい。

いずれも、大手SIまたは発注者の立場のプロジェクトリーダーならば、月末月初に煩雑な管理作業に追われているのではないだろうか。
そして、普通は、ExcelやAccessで皆、ずっと頑張り続けているのが現状だろう。

【3-2】そんな背景や問題意識に対し、既に作業管理・障害管理・問合せ管理に使っているRedmineを工数管理システムとして流用したい、というアイデアは普通に考えられる。
実際、Redmineで障害管理・問合せ管理に使うケースは普通だし、チケット駆動で作業管理に使って、ToDoリスト代わりに運用しているところもあるだろう。
チケット入力の運用が既に回っているならば、後は実績工数や予定工数を入力する運用ルールを追加するだけでいいはずだ。

幸いなことに、Redmineは工数管理機能もかなり強化されている。
レポート画面で実績工数の一覧を表示できるし、チケット一覧画面でも、親子チケットを使った場合、合計の実績工数・予定工数を表示できるようになった。
また、@kusukawaさんのWorkTimeプラグインを入れれば、当月のチケット一覧や手持ちのチケットが一覧表示されるし、工数入力しやすくなる。
つまり、Redmineのデフォルト機能、WorkTimeプラグインによって、工数管理できる仕組みは整っている。

WorkTime - Work Time - r-labs

【3-3】しかし、実際に運用を試してみたが上手くいっていない笑。
理由はいくつかある。

一つは、工数の二重入力が発生すること。
実は、社内に既にある勤怠管理システムにもタイムカードがわりに勤怠工数を入力する運用が既にあるために、Redmineと双方に工数を入力する手間が発生する。
しかも、Redmineと勤怠管理システムでは、工数入力の対象の粒度が違ったりするし、整合性を取るのを考えるとかなり大変になる。

また、月末に勤怠工数を整理して、一括インポートしたい、という要望があったりする。
たとえば、複数の保守案件を抱えているので、各案件の採算で赤字にならないように、実績工数を上手く配分するように付け直したい、など様々な理由がある。
しかし、Redmineでは、実績工数をCSVで一括インポートする機能はなく、REST APIで一括インポートするしか無い。

2つ目は、親子チケットの入力の運用が徹底しにくいこと。
基本はPLが親チケットに本番障害、問合せ、システム保守の定常作業を書き、各担当者が子チケットに作業を詳細化していくイメージだった。
しかし、WBSに詳細化していく、というイメージをプログラマも含めて認識を共有していないと、整合性が取れない。
特に、実績工数を付け始めると、1日の合計の実績工数がたとえば、4hや20hのように入力ミスや入力漏れが多発する。

また、実は、親チケットに見積り工数を予定工数として入力し、実績工数を集計して、生産性を分析したいという意図も実はあった。
だが、予定工数は親チケット、実績工数は子チケットに分離されるので、運用ルールを徹底しないと、データの整合性が取れない。

3つ目は、Redmineに工数の月次締めという概念がないこと。
前月の作業報告を出力したら、前月以前の実績工数は修正不可としたいのだ。
さらに、その実績工数データは勤怠管理システムのデータと一致し、整合性が取れるものでありたい。
だが、それらの運用を手作業で徹底させるのは難しい。
やはり、Redmineの外側に、勤怠管理システムへ実績工数を送信する連携機能や、双方のシステムの工数データを照合してエラー帳票を出力する機能など、何らかの仕組みが必要になると思う。

そういう中途半端な結果の報告になってしまったが、Redmineが悪いのではなく、社内の運用とRedmineの機能が上手くマッチしていないことに根本問題がある。
Redmineの機能追加よりも、業務の運用設計が課題であると思う。

【4】パネルディスカッションや懇親会で話したり、聞いたり、感じたことをメモしておく。

【4-1】JRubyはRedmineに対応しているのか？
@g_maedaさんいわく、JRubyのGemがRailsの最新バージョンに対応していないらしい。
JRubyのGemを保守する人がヤル気がないらしい。
つまり、Redmineの問題ではなく、JRubyの方に問題がある。

個人的には、Windowsに素のCRubyでRedmineを構築するのは至難の業なので、JRubyで構築したい。
何とか解決できないか？

【4-2】Redmineの全文検索機能は、PostgresSQLのマテリアライズド・ビューを使うことで解決できるか？
@akahane92さんいわく、そのアイデアでOk。
マテリアライズド・ビューを定期的にリフレッシュすれば、インデックスが最新化され、高速に検索できる。

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

【4-3】ユーザのCSVインポート機能は追加されないのか？
昔はUser CSV Import Plugin - Plugins - Redmineというプラグインがあったが今は使えなくなった。
しかも、JOSONでユーザデータを作っても、REST APIで複数ユーザをPOSTできなかった、と言う。
なので、1件ずつJSONデータをPOSTするしかなく、面倒だ、と。

@akahane92さんわいく、RedmineのLDAP認証の連携機能を使えば、LDAPユーザを自動認識してくれるので、登録が楽になった。そちらがお勧め。

RedmineでActive Directory(LDAP)認証を使う - 旅モバ

【追記】
下記のユーザ登録一括プラグインがVer3.2でも正常動作するようだ。
マイグレーション不要なので、便利と思う。
shrkw/redmine_user_import: redmine plugin for user bulk import from csv file

あるいは、@g_maedaさんのRubyスクリプトを使って、複数ユーザをREST APIで登録することもできるようだ。

CSVファイルを読み込んでRedmineにREST API経由でユーザーを登録する

Redmineのユーザ一括インポートプラグインがVer3.2でも対応しているみたい: プログラマの思索

【4-4】AWSやAzureなどのクラウドでRedmineを運用した場合、性能要件はどうなのか？
@akahane92さんもまだやっていない。
AWSの方が安く見えるかもしれないが、CPUの消費量が大きい場合、逆にコストが増える時もある。
また、特に、海外のオフショア先でRedmineを使う場合、海外の法律がRedmineのデータに適用されると、セキュリティや法的保証が確保できるか、まだ検証できない、と。
@g_maedaさんも、その問題点は認識しています、とのこと。

【4-5】複数のRedmineで、チケットの内容を同期、参照させることはできるか？
例えば、ある会社では、社内のRedmineはオフショア先に見せたくないので、オフショアとやり取りするRedmineを別途作り、社内のRedmineのチケットの内容をコピーして、そこでやり取りしている。
その作業を楽にしたい。

パネラーからはいろんな意見が出た。
REST APIでチケットの情報を抽出してPOSTする。
社内のRedmineのチケットを更新した時に、通知メールをオフショア用のRedmineへ送り、メールによるチケットの自動登録機能を使う。

一番良いアイデアと思ったのは、カスタムフィールドのリンク型を使うことだ。
@akahane92さんいわく。
チケットのカスタムフィールドにリンク型の項目を設定し、オフショア先のRedmineのURLを記載すれば、カスタムフィールドにチケット番号を書いておくと、自動でオフショア先のRedmineチケットにリンクしてくれる。
たぶん下記の設定だろうと思う。

Feature #1358: Link_to for Custom Field - Redmine

南旺理工: Redmineのカスタムフィールドからリンクを張れる機能も今じゃ普通に標準装備な件

【4-6】小暮さんのLT資料でも、RedmineにUNCパスを使う事例が紹介されていた。
前回の@netazoneさんのLT資料で紹介されていたから、僕もUNCパスのRedmineプラグインをさっそく入れてみた。
共有ファイルサーバーの認証さえクリアできれば、IEから共有ファイルサーバーのExcel資料に直接リンクできるので非常に便利。

Redmineで共有ファイルサーバーへリンクするプラグインredmine_wiki_unc: プログラマの思索

【4-7】今回の勉強会でも参加者の半数は初参加の人が多く、東京や福岡など遠方から参加された方もいた。
そんな人達と会話してみると、Redmineユーザはプログラマの人達より、情報システム部門やプロジェクトリーダー、PMOのバックグラウンドを持つ人が多いように感じた。
さかばさんの言う通り、Redmineユーザはアーリーアダプターではなく、RubyやRailsも知らない人達が自分たちの業務に導入したい、という意識を持っている人が多いように思う。

[#redmineT] Redmineはキャズムを超える - redmine.tokyoに参加して -: ソフトウェアさかば

彼らの話を聞くと、個別では色んな背景があるけれど、社内の開発業務にRedmineを全面導入して、Redmineを基盤とした開発プロセスを構築したい、という意識を持つ人が多いように感じた。
実際、色んなプロジェクト管理ツールを比較検討した結果、Redmineが候補に上がり、その導入と運用をやりたい、そのために情報を収集したい、ということでRedmine勉強会に参加されているようだ。

だから、Redmineと他のプロジェクト管理ツールを比較検討する時に、機能面だけでなく、性能面の評価も必要だから、@akahane92さんのRedmineチューニング資料は非常に重要な資料であると言える。
他社でこれだけの規模でも性能面に問題ないという大手メーカーの事例があれば、大手のユーザ企業ほど社内で説得しやすい。

【4-7-1】だが、他にも多数のプロジェクト管理用のパッケージ製品があるのに、なぜRedmineがそれほど注目されるのだろうか？
その回答は既に、第12回のRxTStudy勉強会で陸野さんが話されている。

Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想: プログラマの思索

陸野さんいわく。
SEPGとしてCMMI/PSP/TSP、アジャイルなど数多くのプロセスを導入、運用されてきた。
その過程で、現場にたくさんパッケージ製品のプロジェクト管理ツールを入れてきたが、そのたびに失敗した。

パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれている。
しかし、作った会社のプロセスと自社のプロセスは当然違うから、ツールを使う会社の現場のプロセスにはなかなかフィットしない。
だから、現場の抵抗も強く、ツールのメリットがなかなか出ない、と。
つまり、市販のプロジェクト管理ツールに埋め込まれている開発プロセスに自社の組織が従わせられることで、組織の運用が変わってしまい、組織が混乱してしまいがちなのだ。

また、自社の開発プロセスに合うように、パッケージ製品のプロジェクト管理ツールをカスタマイズするとなると、ベンダーにカスタマイズの費用を払わなければならない。
普通は、パッケージ製品のカスタマイズ費用はかなり高額だ。
たった少しの修正だけなのに、高額の開発費用がかかり、さらに、パッケージ製品の保守料を毎年支払うのだから、相当のコストがのしかかる。

しかし、Redmineはオープンソースでありながら、ワークフローやカスタムフィールドなどが柔軟で、REST APIなどの外部接続の機能も豊富なので、Redmineの外部でカスタマイズするのが簡単だ。
すなわち、Redmineというツールに組織の運用を従わせるのではなく、組織が目指す運用ルールにRedmineをフィットさせるようにできる。

たとえば、Redmineの設定を変えたり、Redmineの外部でデータ連携機能や集計機能を作ればいいのだ。
あるいは、Redmineはオープンソースなのだから、自分たちでカスタマイズして、Redmineを自社専用のツールにしてしまえばいい。

Redmineは戦略に従う。そして、Redmineは組織に従う～システム運用フローの背後にある組織構造の影: プログラマの思索にも書いたけれど、「Redmineは(組織の)戦略に従う」「Redmineは組織(の構造や開発プロセス)に従う」考え方の方が普通なのだろうと思う。

【4-7-2】そしてもう一点重要なポイントは、日本にRedmineのエコシステムが小規模だが生まれつつあることだろう。

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索でも、JAXAの方が書かれているように、OSSであるRedmineを利用する場合、Redmine本体の開発が活発であるか、コミュニティ活動が充実しているか、は非常に重要な基準だ。
この点では、Redmineは2015年だけでもメジャーバージョンアップが3回もあって活発であり、Redmineの書籍も過去数年で10冊近く出版されてきたし、ネット上でもRedmineのセットアップからワークフロー設定、カスタマイズ、運用方法まで情報がかなり公開されている。

このRedmineのエコシステムがあるからこそ、従来はプログラマ層しか関心を持たなかったユーザ層がプロジェクトリーダー層へ、そしてPMOや品質保証部のように会社組織の上位層に関わる人まで、Redmineに興味を抱くようになってきたのだ。
より権限を持つ人達がRedmineに興味を持つことで、Redmineの普及がより加速しやすくなるメリットはあるだろう。
Redmineのユーザが増えることにより、Redmineのカスタマイズや保守サービスを専門に請け負うベンダーが増えて、ユーザも選択肢が増えるという好循環も生まれる。

そういうRedmineのエコシステムの構築をコミュニティに関わるユーザがどのように認識し、発展させていくか、と言うのが今後の課題。

【他の資料はコチラ】