Redmineの裏の顔～開発基盤としてのRedmine

Redmineには、オープンソースのプロジェクト管理ツールという表の顔だけでなく、業務アプリケーションの開発基盤(プラットフォーム)という裏の顔もある。
アイデアを下記にまとめてみた。

Redmineの裏の顔～開発基盤としてのRedmine from akipii Oga

【1】最近、Redmineを企業(IPAも含む)が機能拡張する事例が少しずつ増えている。
何故、Redmineをカスタマイズしてでも、使いたいのか？

Redmineは本来は、オープンソースのプロジェクト管理ツールという表の顔がある。
ソフトウェア開発の進捗管理を開発チームがやりたいなら、一通りの機能が揃っている。

特に、日本では、Redmineの人気が高いらしい。
その理由は、インストールして、プロジェクトやワークフローなどのパラメータを設定すれば、すぐに運用できるからだろう。
そして、実際の運用は各チームで微妙に異なる場合が多いけれど、その微妙な違いもRedmineで実装できるくらい、Redmineが柔軟な機能を持っている点があるだろう。
日本のSIerの運用例としては、障害管理(BTS)や課題管理(ITS)としてまず使い始めて、その後、全工程のタスク管理をRedmineで運用するパターンが多いだろうと想像する。

第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

しかし、実際にRedmineを運用してみると、開発者よりもマネージャ層から、Redmineに対する不満が出ることが多い。
実際、僕が今までの現場でRedmineによるチケット駆動の運用を導入した時、その後の運用で不満が出てくるのは、特にマネージャ層だった。

マネージャ層の話を聞くと、Redmineは開発者の観点では使いやすいが、マネージャが欲しいデータを簡単に取得したり、操作するのが面倒なようだ。

Redmineチケットに開発チームの全ての作業データがあり、まさに生データなので、そのデータを進捗・品質・リスク・工数の観点で色々集計して、分析したい。
しかし、Redmineの集計機能は、チケットをフィルタリングするクエリ、ガントチャート、ロードマップ、サマリぐらいで、マネージャが進捗・品質・リスクを日々追跡するには物足りない。
結局、RedmineからチケットをCSV出力して、ローカルPC上のExcelで手集計して、時間をかけて分析しているのだ。

Redmineにせっかく溜まった生データをマネージャ向けの観点で分析したい、という要望こそが、企業がRedmineを機能拡張する動機なのだろうと思う。

【2】Redmineを機能拡張する方向性としては、Redmineを開発基盤と言うプラットフォームで考えると分かりやすいと思う。
つまり、Redmineをプロジェクト管理用ERPと見なして、どのように機能拡張すればよいか、という観点で整理できる。

すると、Redmineと言うプラットフォームでは、以下の４つの観点でカスタマイズする方法を分類できるだろう。

・外部接続I/F
・パラメータ設定
・プラグイン(アドオン)
・モディフィケーション

【2-1】外部接続I/F

Redmineには、外部接続I/Fを通じてデータ操作を行える仕組みが豊富に揃っている。
例えば、RESTによるWebサービス、リポジトリ管理用のWebサービス、受信メールによるWebサービス、rakeによるデータ移行、rakeによる期日間近のチケットの通知などがある。

Redmineの外部接続、データ移行の機能: プログラマの思索

RedmineのREST APIは素晴らしい～ビッグデータの手法をRedmineにも活用する: プログラマの思索

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine: プログラマの思索

期日が間近のRedmineチケットをメールで通知する: プログラマの思索

オープンソースなのに、これだけの種類の外部接続I/Fが標準で装備されているのは、本当に凄いことだ。
SIがスクラッチで受託開発する特定顧客向けの業務システムでも、これほどの外部接続I/Fを実装するのは、かなり工数がかかるだろう。

外部接続I/Fを使う状況としては、社内の会計システムや工数管理システムからRedmineにある工数データを取得したり、社内の品質管理システムからRedmineにある障害情報を取得する場合があるだろう。
つまり、Redmineにある元ネタを引っ張り出して、外部システムが取り込んで加工する流れになる。
特に、障害チケットやソース管理リポジトリ情報は、ビジネスインテリジェンス(BI)によって加工すれば、より意味のある観点で分析できるはずだ。
品質管理担当者ならば、障害データから品質の状況や傾向を分析したいし、マネージャならば、工数データから今後どれくらいコストが発生して、納期通りにプロジェクトが完了できるか、分析できるだろう。

このアイデアは、ソフトウェア・リポジトリ・マイニングというエンピリカル・ソフトウェア工学の方向に一致するだろう。

ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する: プログラマの思索

BTSをBusiness Intelligenceとして使う: プログラマの思索

但し、前提条件としては、既に使える外部システムがあり、その外部システムでRedmineのデータを取り込んで加工すれば解決できることがある。

ここで、Redmineの外部接続I/FはRESTなどのWebサービスが基本なので、HTTP接続によるリアル連携になる。
昔は、外部接続といえば、Cobolによる夜間の日次バッチ処理が主流だったが、リアル連携の方が最新データをいち早く取得できる利点がある。

注意すべき点は、HTTPによるリアル連携のため、大量データのやり取りには向いていないこと。
頻繁にリアル連携するならば、負荷テストで事前検証する必要があるだろう。

但し、開発チームの規模が小さく、プロジェクトで発生するチケットや進捗情報が少ないならば、例えば、５分おきのリアル連携でも問題ないかもしれない。

【2-2】パラメータ設定

普通のERPでは、最初に、特定顧客向け用パラメータを初期マスタとして登録する運用がある。
例えば、会計システムならば、企業が使う勘定科目は企業ごとに微妙に違うので、あらかじめ勘定科目データを洗い出して登録する必要がある。
あるいは、経費申請などのワークフロー管理システムならば、企業独自のワークフローで使えるように、あらかじめ帳票データや承認フローを登録する必要がある。

Redmineの場合、初期パラメータの設定は、ワークフローやユーザ、ロール、プロジェクトなどの初期設定の作業になる。
ここで一番重要な設定作業は、ワークフロー管理だ。

Redmineのワークフロー管理では、チケットの種類ごと、ロールごとにワークフローを自由自在に設定することができる。

RedmineとTracの機能比較: プログラマの思索

Tracのワークフロー: プログラマの思索

この機能こそがTracやMantisよりも優れている点であり、ワークフローを運用の場面に応じて変えれば、ソフトウェア開発のあらゆる作業をすべてチケットに置き換えることができる。
さらには、ソフトウェア開発以外にも、ヘルプデスクの問合せ管理やPC資産管理など、他業務へも適用できる利点がある。

【公開】講演資料「Redmineの運用パターン集～私に聞くな、チケットシステムに聞け」 #tidd: プログラマの思索

逆に言えば、自分たちの開発チームではそもそもどれだけのワークフローが必要なのか、という問題を事前に洗い出しておく必要もある。
ワークフローは一度決めると、新規追加は簡単でも、運用中のワークフローを変更・削除するのは、過去の履歴データの扱いによっては、修正不可能な場合があるからだ。

ここで、ウォーターフォール型開発とアジャイル開発では運用スタイルが全く異なる。
この違いについては、詳細は「Redmine超入門」を読んでみると良いかもしれない。

「Redmine超入門 (日経BPムック)」が発売されました: プログラマの思索

Redmineのパラメータ設定が成功する前提条件としては、Redmineの標準機能だけでプロジェクト運営できる前提がある。
実際は、プラグインを幾つか追加して、機能拡張するのが普通だろうと思う。

【2-3】プラグインというアドオン

Redmineのプラグインは、Railsフレームワークのおかげでとても開発しやすい。
「設定よりも規約」「繰り返しの禁止」などのおかげで、少ないソースで簡単に作成できる。
また、プラグインのインストールも、rakeコマンドを叩いてRedmineを再起動するだけなので、とても簡単。

プラグイン開発ガイド - r-labs

プラグインの開発 ? Redmine.JP

プラグイン開発の特徴は、「標準機能のソースを修正する事無く」追加開発で機能拡張する点にある。
つまり、プラグインの利点は、Redmine本体のソースは基本は手を加えず、テーブルの新規追加などぐらいで、Redmine本体をパワーアップできる点だ。

Redmineを開発基盤として機能拡張(アドオン)したい場合、できるだけRedmine本体は触らずにプラグインの追加だけで対応できるようにしておきたい。
理由は、RailsもRedmineも頻繁にVerUpしていくには、Redmine本体に手を加えると、そのVerUpに付いていけなくなるからだ。

今までの経緯を見ると、Redmineはセキュリティに関するバグ修正は即リリースするので、できるだけRedmineは最新版で運用できるようにしておきたい。

だから、プラグインを開発して、マネージャ向けの機能を追加して反映するのが主流になるだろうと思う。
Railsを操る技術力さえあれば、マネージャを顧客と見なして、その要望をRedmineプラグイン化すれば、ソフトウェア開発のプロジェクト管理を全てプログラム化することもできるだろう。

【2-4】モディフィケーション

モディフィケーションは、「標準機能のソースを直接修正して」機能拡張する場合に相当する。
ERPを導入する場合、普通はパラメータ設定やアドオン追加だけでは足りず、どうしてもERP本体にも手を入れて修正する場合が多い。
特に大企業になるほど、独自の業務があったり、業務で発生するトランザクション量が多いために、独自実装せざるを得ないのだ。

Redmineを小さな開発チームで運用するなら、Redmineの標準機能といくつかのプラグインだけで問題ないかもしれない。
しかし、大手SIが組織全体・会社全体でRedmineを導入し、プロジェクトごとの進捗管理や品質管理、コスト管理、リスク管理を厳格に行いたい場合は、もっと機能が欲しくなる。

モディフィケーションの方向性としては、２つあると思う。
一つは、マネージャ向けに集計・分析機能を強化すること。
もう一つは、マネージャが操作しやすいユーザインターフェイスに機能改善したり、運用しやすいようにサービスもセットで提供すること。

前者は、IPAがオープンソースで提供しているEPM-Xが相当するだろう。
課題管理や品質管理の機能をもっと徹底的に使い倒して、リスクを追跡していきたいのだ。
イメージとしては、「チケット&計測でITプロジェクト運営の体質改善」に書かれている内容に相当するだろう。

チケット駆動開発を紹介した書籍一覧: プログラマの思索

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

定量的プロジェクト管理ツールはIT企業の基幹システムを目指す: プログラマの思索

後者は、アジャイルウェア(株)のLychee Enterpise製品シリーズや、ホロンテクノロジー(株)のソリューションサービス「Redmine for ITIL」があるだろう。

第9回RxTstudy勉強会の感想～Redmineとチケット駆動開発の今後の課題　#RxTStudy: プログラマの思索

Redmine for ITILが解決するもの: プログラマの思索

Lycheeシリーズでは、ガントチャートのユーザインターフェイスを改善することで、マネージャがチケット中心ではなくガントチャート中心に進捗管理できるように操作を改善している。
他に、EVMによる工数管理や、チケットの親子関係・先行後続関係を表示するチケット関連図など、興味深い製品もある。
特に、EVMの実現方法は「Redmineによるタスクマネジメント実践技法」で詳しく書いたので、Lychee EVMがどれくらい、僕が考えたアイデアを実装しているのか、に興味がある。

「Redmine for ITIL」は、Hinemosと連携した運用保守のサービス・パッケージだ。
RedmineのようなITSは元々、障害管理ツールから発展したので、本番障害の管理がメインとなる運用保守とは相性が良い。
ITILというフレームワークをRedmineに実装して運用できるのではないか、というアイデアは「Redmineによるタスクマネジメント実践技法」に書いたけれど、そのアイデアが製品として実際に実現されたのは注目に値すると思う。

モディフィケーションの注意点としては、Redmine本体に手を加えているため、RedmineのVerUpで保守コストが発生する点だ。
RedmineのVerUpが頻繁に行われた場合、最新版に追いつくだけでも大変だ。
カスタマイズの量が多いほど、困難になるだろう。
実際、EPM-XはRedmineのVerUpに追いついているようには資料上見えない。

もう一つは、Redmine本体のソースを直接修正する場合でも、RedmineのWebサービスAPIを使用して改造する方向が良いことだ。
Redmine管理画面から「RESTによるWebサービス」「リポジトリ管理用のWebサービス」「受信メール用のWebサービス」「JSONP」を有効に設定できるので、これらの外部接続I/Fを通じてデータをやり取りすれば、スクラッチでデータ接続部分を作るコストを減らすことができるし、今後のRedmineのVerUpにも対応しやすくなる。
同様に、Redmine標準のrakeコマンドを真似て、データを一括処理するrakeコマンドを実装すれば、バッチ処理の代替にもなる。

モディフィケーションのアーキテクチャがうまく設計されているか否かで、保守コストに大きく関わってくると思う。

【3】Redmineをプロジェクト管理システムのプラットフォームとして扱う場合、以下のようにまとめられると思う。

(1)外部システムが既にあるならば、Redmineの外部接続I/Fを通じて最新データをリアル連携する。
(2)Redmineの運用は、初期パラメータ設定で可能か、事前検証しておく。
(3)機能拡張はできるだけプラグインで対応する。
(4)より高機能に使い倒したい場合は、Redmineのパッケージ製品を購入してみる。

以上のように考えてみると、Redmineを機能拡張してパッケージ製品として販売したり、チケット駆動開発の運用とセットにしたトータル・ソリューションで提供したりする方法は、今後増えるのではないか、と思う。

僕が一番興味があるのは、「Redmineによるタスクマネジメント実践技法」や「チケット駆動開発」で書いたアイデアが、どれだけ製品として実現されるのか、という点だ。
本を出版する時点ではあくまでもアイデアに過ぎなかったが、もう３年以上たった今、どのように実装されて運用されているのか、にとても興味がある。

今後も追いかけてみる。

【追記】
下記のTwitterを見つけたのでメモ。

Twitter / kimutansk: 内容の方向性自体はRedmineでなくても共通的な内容ですが、ここまで拡張ポイント充実してましたか。 / “Redmineの裏の顔～開発基盤としてのRedmine” http://htn.to/n8zRqU

Twitter / kimutansk: Redmineまとめ。ワークフローは他のでもできたような・・・ただ、それも慣れたから言える話なのかもしれませんね / “Redmineの裏の顔～開発基盤としてのRedmine: プログラマの思索” http://htn.to/Nw2E2H

Twitter / kimutansk: 最適解かどうかはさておき、こういう用途にも使えるわけですか。 / “「Redmineの運用パターン集～私に聞くな、チケットシステムに聞け」” http://htn.to/cF6DCS

Twitter / sakaba37: RedmineがJSONP対応だった件！ RT @akipii: Webユーザエクスペリエンスのためのパターン集～Ajaxデザインパターン http://bit.ly/JKSFjq