【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」 #47redmine

東京で雪だるまができるくらい積もったにも関わらず、第6回品川Redmine勉強会は、スタッフは全員、参加者も7割も参加して開催されました。
懇親会も27人も集まり、大変盛り上がりました。

参加者の方には足元が悪い中、来てくださりありがとうございました。
また、会場を提供して頂いたフューチャーアーキテクト様、そして協賛して頂いたアジャイルウェア様に厚くお礼申し上げます。

【元ネタ】
第6回勉強会 - shinagawa.redmine

第6回品川Redmine勉強会(2014/2/15) - Togetterまとめ

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」 from akipii Oga

【1】Redmine超入門のお話

中山さん、@naitohさん、@tkusukawaさんから、Redmine超入門に絡んだお話があった。
本の執筆はやはり大変。
中山さんの見積では、90ページ書くのに2人月かかるらしい。

そこで、品川Redmineスタッフも加わって執筆したものの、並行作業になったので、最後に成果物を結合した時に整合性を取るために苦労されたらしい。
ソフトウェア開発でも、結合テストでビッグバンテストで苦労するのと同じく、並行作業は時間短縮できるが、結合した時に初めてリスクが発生する。

執筆作業でもソフトウェア開発でも、並行作業には、時間短縮の利点と同じくらい、ビッグバンテストのリスクも大きい。

【2】開発基盤としてのRedmine

日本のSIの現場で、Redmineはかなり普及している印象を僕は持っています。
最近の僕も、Redmineエバンジェリストの立場で、色んな現場にRedmineを導入する時が多いです。
その時にいつも苦労するのが、開発者の評判は良いのに、マネージャからは、Redmineが使いづらいというフィードバックが多いのです。

その理由は、マネージャは、プロジェクトの進捗だけでなく、コストや品質、リスクをサマリとして集計した結果を週次または月次で報告が欲しいのに、そんな機能がRedmineにはないからです。
そのため、Redmineをカスタマイズして、もっと使いやすくしようという動きが最近多いように見受けられます。

Redmineのカスタマイズで注意すべき点は、要約すると2点あります。
一つは、現場の運用とRedmineの機能のフィットギャップ分析をきちんと行うこと。

現場にRedmineを導入する場合、何も考えずに導入すると、マネージャだけでなく開発者も抵抗勢力になります。
やはり、現場の運用のレベルに合うように、Redmineのワークフローを合わせたり、チケット管理の運用ルールについて説明会(いわゆる導入時研修)を開いて十分に説明したりすることが必要になります。
2014年の今でも、TracやJiraなどのITSを触ったことがない人も多いので、そんな人達には丁寧に、Redmineの利点を強調しながら説明する必要があります。

また、Redmineは柔軟性が高いため、トラッカーやワークフロー、カスタムフィールド、ユーザ、プロジェクトをあらかじめ決めておかないと、すぐに運用することはできません。
そのため、現場にヒヤリングしながら、Redmineの機能を現場に合わせる必要があるのです。

一度Redmineを導入してしまえば、20代の若い人ほど、すぐに慣れてくれます。
逆に、Excelで20年管理をやってきた40代のマネージャほど、Redmineに染めるのが難しい。

もう一つは、Redmineを機能拡張する時に、Redmineの外部接続I/Fを利用してデータの取得や更新処理を行うようにすること。

Redmineは機能改善やユーザインターフェイスの改善の開発速度が早く、VerUpがとても頻繁に起こります。
そのため、RedmineのVerUpに追随する方が、新しい機能を自然に使えるようになる利点があります。
下手に、自分たちでRedmineのソースを弄ってユーザインターフェイスを改善するよりも、VerUpに追随する方がコスト的にも安全かもしれません。

また、Redmineの外部接続I/Fは、RESTやJSONP、rakeなどのインターフェイスが豊富にあるので、それを有効利用する方が、RedmineのVerUpの影響を受けることもありません。
RedmineのVerUpが発生すると、自分たちが作ったプラグインや機能修正した箇所がデグレしていないか、回帰テストする工数がVerUPのたびに発生します。
そのコストは、VerUpの回数が多いほど、結構かかります。

RESTを使えば、HTTP通信で、チケットのデータを簡単に一括取得したり、一括更新できます。
また、JSONPインターフェイスを使えば、例えば、Redmine画面の一部の領域を非同期通信で画面更新するプラグインも簡単に作れるでしょう。

さらに、rakeインターフェイスを新規開発すれば、日次バッチ処理のように、データを一括取得したり、Redmineチケットの内容を定期的にメール送信するなどの処理も実現できるでしょう。
Twitterのタイムラインを読むと、パスワードの一括初期化もrakeで実現できるのでは、という話もありました。

個人的には、rakeコマンドでRedmineにあるデータを一括処理するバッチ処理には、大きな可能性を秘めているように思います。

【3】Lychee Enterprise製品

アジャイルウェアの@agilekawabataさんが、Redmineのエンタープライズ向け製品として、3つの製品を紹介されました。
3つの製品の位置づけとしては、マネージャの観点で、プロジェクト管理のQCD(品質・コスト・納期)を支援する製品と位置づけられています。

Lychee Enterprise

LycheeGanttChartは、Redmineガントチャート画面から、チケットを直感的に操作できるプラグインです。
ガントバーをドラッグ＆ドロップで移動したり、日数を縮めたり延ばしたりできます。
また、ガントバー同士に先行・後続の関係を、ドラッグした矢印で簡単に引くことができます。
さらに、親子関係も右クリックから簡単に設定できます。

マネージャとしては、個々のチケットよりも、プロジェクト全体のタスクを俯瞰的に眺めて分析したいので、LycheeGanttChartのようにガントチャート画面で直感的に操作できるプラグインがあると、すごく便利でしょう。

LycheeEVMは、PMBOKのEVM(出来高管理システム)を実現したプラグインです。
マネージャは、要員表と実績工数をにらめっこしながら、プロジェクトの原価をいつも気にしています。

だから、EVMをRedmine上で見ることが出来れば、現在の開発ペースで進むと、いつ予算オーバーになるのか、を予測できるし、早めにリスク対策を実施することもできます。
また、SPIやCPIも日次で時系列に表示するので、ScrumのVelocityのグラフのように、開発チームがアウトプット(出来高)を増やして成長しているのか、逆に、大きな問題にぶつかって進捗が遅延しているのか、を分析することができます。

LycheeAssociationChartは、Redmineチケット同士の関連をグラフ化したプラグインです。
WBSっぽく親子チケットを作っているならば、ツリー構造のようにチケットの関連図を表現できます。
あるいは、チケットの先行・後続関係をきちんと反映していれば、PERT図のようにチケットの関連図が表現されます。

特に、チケットとソースのリビジョンのグラフも表示されるので、WBSの最下層にある作業タスク(ワークパッケージ)と成果物(ソース管理のリビジョン）がリンクされていなければ、成果物ができていないので、その原因を探っていく、という使い方もできます。

川端さんの話では、品質管理部の方が、リリース前の出荷時に、LycheeAssociationChartを使って、チケットと成果物のチェックに使われているそうです。

昨日まで行われたデブサミ2014のブースでもLychee製品のデモを行い、評判が良かったという話も聞きました。
皆さん、Redmineのエンタープライズ向け製品は結構気にされているみたい。

【4】大貫さんのJiraの話、神谷さんと大和田さんのEPM-Xの話

Jiraでも、ガントチャートをカスタマイズしたり、テストケース管理したり、色々な機能があるそうです。
Redmineにある改善要望は、Jiraでも同じように出てくるでしょう。

神谷さんの話で興味深かったのは、ツールの進化にマネージャや経営層が付いていけてないこと。
僕の経験でも、40代以上のマネージャやSEは、Cobolや汎用機の技術で止まっていて、Rubyはおろか、Javaなどのオブジェクト指向やWebシステムの技術を知らない。

彼らはプログラミングしていないので、技術動向の細かな内容まで把握できていない弱点があります。
そういう人達が抵抗勢力になり、日本のSIの技術力の進化を妨げている部分も大きいと思います。

また、従来のソフトウェア工学では、机上でたくさんの理論を作っているものの、定量データを収集し集計するコストが高かったり、そのような定量データ管理ツールの実装が難しかったという背景があって、机上の空論に過ぎない場面が多かったのではないかと思います。

でも、現代は、RedmineやJira、Jenkins、Gitなど優れたツールを連携することで、ソフトウェア開発で発生する作業ログは全て記録できます。

したがって、現代では、それらトランザクションデータをBIツールで分析する機能も簡単に実現できるはずです。
それによって、プロジェクトのリスクを事前に検知して是正対策を実施できたり、次のプロジェクトへ向けて過去のノウハウを生かすといったことも可能になるでしょう。

既にソフトウェア工学では、CMMI、品質管理、PMBOK、ITILなどで仕様は既に公開されているので、それらをツールで実現していくだけなのです。

【5】今回の勉強会で感じたことは、「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」で執筆したものの、まだ実現されていない機能が製品として現れたことでした。
ツール連携、チケット集計の機能強化というRedmineの課題は、もっともっと可能性を秘めていると思います。

【追記】
@tkusukawaさんの発表「Redmineって何ができるの？」と大和田さん、大貫さんの資料を追加した。
とても分かりやすい資料です。

Redmineって何ができるの？ from Tomohisa Kusukawa

Epm x紹介 20140215 from Yohwada

Jiraの紹介(redmineとの比較視点にて) from Hiroshi Ohnuki