Redmineが日本人好みのツールであるという仮説

第10回東京Redmine勉強会のグループディスカッションでも話題になったのが、Redmineの運用が大規模化していく上での課題だ。
@Will_meaningさんとのやり取りがとても参考になったのでメモ。
以下は私的感想。

【参考】
Redmineの運用が大規模化していく上での課題～@Will_meaningさんとのやり取り - Togetterまとめ

Redmineを運用している規模について - Google グループ

第10回東京Redmine勉強会～「メトリクスの見える化とその周辺」　#redmineT - Togetterまとめ

【1】@Will_meaningさんが持つ問題意識は「なぜ海外ではJIRAが多く普及していて、日本ではRedmineが多く浸透しているのか」。
彼の意見を読むと、「SVN中心の開発プロセスはRedmine、Git中心の開発プロセスはJiraやGitHubではないか」という意見のように思える。
理由は、「ビジネスアジリティという視点で見た時に、どのくらいのスピード感が必要かによって、開発スタイルの方向性が絞られていき、そこからSVN（集中型管理）かGit（分散型管理）かが決まり、それに見合う関連ツールとして、RedmineかJIRAかが決まっているんじゃないかなと思うんですよ。」だから。

確かに、そんな部分もあるだろう。
特にJiraは、アジャイル開発用のプラグインも揃っているし、Git連携だけでなく、ビルド管理やWikiなどの周辺ツールもパッケージ製品群として完成している。
お金があれば、SIがソフトウェア開発の基盤として持ってもいいだろうと思う。

だが、悲しいかな、日本のIT企業やソフトウェア開発の現場では、開発基盤にコストを払ってもいいという認識はない。
だからこそ、Excel管理や大量の紙による申請承認フローが、SIの現場でもいまだに残っているのだ。

【2】でも、そんな現状があったとしても、ソフトウェアの開発基盤をオープンソースのプロセス支援ツールで固めて、アジャイル開発の恩恵が受けられるように業務を改善することは意味があると思う。

個人的な思いとしては、Redmineは日本人好みのツールであるように思う。
理由はいくつかある。

【2-1】一つは、ライセンスが無料であり、導入や設置が簡単で、保守工数だけで十分であること。
Redmineはオープンソースなので、余ったサーバーに、まずは評価検証用にインストールすればいい。
Bitnamiのようなワンクリックインストーラーを使えば、導入はすごく簡単。
タスク管理・障害管理・問合せ管理に必要な設定は、全てWeb画面から操作できるので、すぐに運用を開始できる。
Redmineでお金がかかるとすれば、社内のサーバー保守くらいであり、小規模チームで運用しているなら、管理工数の一部に含めてしまえばいい。
顧客向けの進捗報告や障害報告を作成するために、元ネタとなる進捗データをExcelで収集して集計するくらいなら、Redmineでデータを蓄積して、加工集計するスクリプトを自作した方が早い。

【2-2】もう一つは、自分たちで機能拡張していく機運が生まれて、現場主導で業務を効率化していこうとする動機づけを強化してくれること。

以前、陸野さんが言われていたが、Redmineを社内に導入したら、Redmineに足りない機能は開発者が自ら作って補おうとする雰囲気が出てきて、自然にプロセス改善が進んだ、という話があった。

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

第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy: プログラマの思索

SEPGとしてCMMI/PSP/TSP、アジャイルなど数多くのプロセスを導入、運用されてきた。
その過程で、現場にたくさんパッケージ製品のプロジェクト管理ツールを入れてきたが、そのたびに失敗した。
パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれている。
だから、自社の組織文化や自社の開発プロセスにフィットしない部分が必ずあり、そこがボトルネックになって、業務の改善がなかなか進まない。

しかも、パッケージ製品はカスタマイズしようとすると費用がかかり、VerUpのたびに追加コストがどんどん膨らんでいく。
結局、パッケージ製品の外側で、他社製プロジェクト管理システムで不足した機能を手作業でカバーする運用が生まれて、無駄な管理コストが増えてしまいがち。
すると、現場の開発者も、業務をより良くしていこうと動く前に、不平不満をこぼして、何もしなくなる。
たとえば、業務システムの現場でも、ERPのようなパッケージ製品を導入した結果、システムの中身がブラックボックスのために、業務の改善をやろうとしても業務の全体を見通せる人がいなくなって、どこも苦労している。

一方、オープンソースの開発基盤やプロセス支援ツールは、自分たちのプロセスにカスタマイズが可能だ。
自分たちでソースパッチを当ててもいいし、ツールの外側で集計用Excelマクロなり、集計用スクリプトなりを作って、不足した機能を補えばいい。
そういうツールを作ることは結構楽しい。
プログラミング技術を使って、自分たちのソフトウェア開発プロセスを作り上げていくのが楽しいのだ。

その雰囲気は、バブル不況前の日本の製造業の現場にあったQCサークルと同じ雰囲気ではないか、と想像する。
現場にある目の前の道具を使って、どのようにアレンジすれば、製造工程を効率化できるか、同僚が議論しながら、試行錯誤していたはずだ。
でも、ISO9001のような舶来の品質管理手法が導入されて、日本独自の良さが失われ、ドキュメントを一生懸命作る管理作業ばかり追われるようになった、という話はよく聞く。

【2-3】たぶん、日本人はプロセスイノベーションが得意。
iPhoneのようなラディカルイノベーションを生み出せなくても、品質管理のようなプロセスイノベーションを生み出してきた歴史を振り返ると、オープンソースの開発基盤を用いて、プロセス改善していく手法は、日本人の性格に合っているのではないかと思う。

日本の歴史を見れば、中国や西洋の文化を取り入れた時、それを自分たちの体に合わせて、加工して取り入れてきた。
だから、オープンソースの開発基盤ツールの方が、自分たちの組織文化に合わせて、フィットできるようにカスタマイズするのは多分得意なのかもしれない。

【2-4】しかし、Redmineの運用が隣のチーム、隣の部署へ拡大していくと、社内の保守工数も馬鹿にならなくなっていく。
そして、オープンソースのツールを自社独自にカスタマイズするよりも、市販のパッケージ製品を入れて、保守コストを下げた方がいいのでは、という動きも出やすい。

その流れは、自社独自の業務システムを汎用ERPにリプレースして、社内の人件費のコストも下がり、見た目はスッキリしたものの、せっかく育まれた組織文化が消えてしまうのと同じ症状かなあ、と思ったりする。
ERPというブラックボックスのシステムは、現場の人の活動を統制することが主な目的なので、現場の人達の自由度が減り、自分たちでシステムを上手く使って効率化しようという動機は生まれにくいから。

【3】RedmineやJenkinsなどの開発基盤ツールが日本人好みではないか、という仮説はもう少し考えてみたい。

【追記】
RedmineとJiraの機能比較について、Jiraの立場から書かれた記事がある。
画面キャプチャの比較なので分かりやすい。

JIRA Software(+Atlassianツール) vs Redmineについて - 製品とサービスのブログ - サポートドキュメント