Redmineが日本人好みのツールであるという仮説part3～日本のRedmineコミュニティにはプラグイン開発者が多い

@agilekawabataさんが「Redmineが日本人好みのツールである」意見を述べていて、なるほどと思ったのでメモ。

【参考】
Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2～日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

【1】Rubyアソシエーション - 株式会社アジャイルウェア

（引用開始）
川端氏はOSSの活動にも力を入れている。
Ruby、Redmineどちらもコミュニティによる開発が中心となっており、OSS活動がビジネスに直結しているからだ。

「RxT Study(現 Redmine大阪)でRedmineプラグインの作り方という発表をしたこともありました。
アジャイル、Ruby、Redmineいずれのコミュニティでも私自身が楽しみながら活動しています。
コミュニティの特徴をつかんでおくとビジネスに活用できることも多いです」

啓蒙普及活動を通じてユーザー数の増加を目指すことは分かりやすいコミュニティ活動の一例と言えるが、その他にも活動を通じて面白い発見があるようだ。
例えば、日本のRedmine開発コミュニティは、どちらかといえば本体よりもプラグインを開発する開発者が多くいるとのこと。

「他のオープンソースタスク管理ソフトウェアや商用のソフトウェアと比較して、Redmineはアジャイル、ウォーターフォールのどちらでも上手く適用できます。
それにカスタマイズも容易にできます。
日本企業ではその組織に合うように、導入ツールをカスタマイズして使うことを好む文化があります。
それが、Redmineが日本で多くの人に受け入れられている理由であり、Redmineのプラグイン開発が盛んな理由もそこに関係があると思ってます」
（引用終了）

【2】Redmine以外にも数多くの有名なOSSツールはいくらでもある。

たとえば、Rubyは日本人のコミュニティがすごく活発だ。
RubyコミュニティはRuby自身のコミッタという開発者が関わっているように、たいていのコミュニティは開発者自身が積極的に関わって、コミュニティを形成する場合が多い。
まつもとさんを中心として、数多くに日本人コミッタがRubyを積極的に開発し、かつ、Ruby会議のようなコミュニティ活動も積極的に行なっている。

しかし、日本のRedmineコミュニティは少し違う側面がある。

Redmine本体の開発者はフランス人のJPLだけであり、まるやまさんもコミッタと言いながらも、多言語化やテストコード整備などに徹しており、役割分担されている。
前田剛さんもコントリビュータとして、リリース計画に携わっているが、現状はRedmine本体のソースにコミットできるわけではない。
つまり、Redmine本体のソースを修正できる人は事実上JPLただ1人だけだ。

一方、東京RedmineやRedmine大阪に参加する人達の属性を振り返ると、Redmineプラグイン開発者やRedmineサーバー管理者のセグメントが非常に多い。

思いつく日本人のプラグイン作者は、@akiko_pusuさん、@two_packさん、@haru_iidaさん、@onozatyさんなど。
彼らが提供するOSSのプラグインは、正直なくては運用できないレベルがある。
たとえば、Issue Template、Excelエクスポート、SideBarやWikiExtensionsなど。

また、堂端さん(アジャイルウェア)や@y503unavailableさんのRedmineのデータ移行、@akahane92さんの性能チューニングなどの利用事例も数多く発表されている。

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

QA #247: 複数のRedmineサーバを統合したい - Unofficial Redmine Cooking - redmine.tokyo

【3】Redmineの開発基盤であるRailsは、DBのスキーマ構造、CoCによる設計、JavaScriptの各種フレームワークとの相性の良さによる今風のリッチなUI、プラグインによる機能拡張のしやすさ、REST APIなどの外部接続IF、など数多くの利点を持つ。
Railsの長所が、カスタマイズに向いているように思える。

実際、新しい機能を追加したいと思う時、プラグインで製品本体に依存せずに機能開発できる。
また、テーブル構造も、機能追加で必要なテーブルを新規作成しておけば、製品本体のVerUpの影響も受けにくくなる。
さらに、Redmineは、REST APIでXMLやJSONでチケットデータを取得・更新できる外部接続IFがあるので、それを使うようにすれば、製品本体のVerUpを受けにくいような設計にできる。
他にも、rakeやメールによるチケット自動登録などの機能もあるので、状況に応じて設計を変えれば良い。

Redmineの裏の顔～開発基盤としてのRedmine: プログラマの思索

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

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

昨今は、ViewCustomizeプラグインを使えば、Redmineのソースを触らずに、画面のUIを自由に修正できる方法も公開されている。
たとえば、ちょっとした画面のUIの配置、デザイン変更、初期表示や画面遷移の変更を行いたい時は、ViewCustomizeプラグインを使った方がいいだろう。

ViewCustomizeプラグインでRedmineをマイクロコア化できるか: プログラマの思索

【4】彼らのようなプラグイン開発者が日本には多い、という背景には、川端さんの指摘の通り、Redmine本体のVerUPに追随しながらも、自分たちの組織に合った運用ルールにRedmineをフィットさせたい、という場合に、プラグインで機能拡張しているのだろう。
つまり、日本企業は自分の組織文化に合うようにツールをカスタマイズしたい、という要望がすごく強いのだろう。

実際、Redmineを利用する企業の業種を聞くと、本来はIT業界のうち、受託開発がメインと僕は思っていたが、デザイナーやゲーム業界、製造業、サービス業など、多種多様な業界でも使われている。
利用事例は、ソフトウェア開発という特殊な業態だけではないのだ。

また、日本の大企業での事例（メーカーが多い）、JAXAや気象庁の事例もWebで公開されている。
つまり、企業の規模も問わず、日本では中小企業から大企業までRedmineが幅広く利用されているようだ。

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JAXAのRedmine利用事例の講演資料がWeb公開されました: プログラマの思索

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

そうすると、それらの業態に合うような画面UIや機能が欲しい、という要望が増えるのも、割と自然に理解しやすい。

【5】そういう背景を考えると、下記のツイートのように、ERPのパッケージ製品SAPは仕事そのものだ、というような製品は日本企業には合わないのだろうと思う。
なぜなら、自分たちのやり方にあわせてカスマイズできないからだ。

Takanori Sekiさんのツイート: "SAP役員の弁「SAPはパッケージソフトではありません。それは仕事のやり方そのものです」つまりERPを買うということは仕事のやり方を買うってこと。その意識で買ったところはどれだけあるか…"

無理してカスタマイズすれば、保守費用が大きくなるし、製品本体のVerUP追随のための保守費用が更に増えてしまう。
かと言って、製品本体のVerUpができなくなると、セキュリティパッチなどの重要なパッチが当たらないリスクが増えてしまう。
半ば惰性的にERPを使い続けている所が多いのではないか。

つまり、日本のビジネス文化、日本の市場の特性、日本の組織の特性を考えると、自社の特徴を活かすようなシステム構築の方が、日本企業には向いているのではないだろうか。

【6】日本では多種多様な業態でRedmineが使われている、という事実は、Redmineをよりカスタマイズしたい要望が多くなる原因の1つであろうと思う。

すると、本来の発端の機能であった障害管理だけではなく、ITSやチケット駆動へ発展し、さらに、BPMや事務処理ワークフロー、勤怠管理、ISO9001などへの利用シーンも増えているのだろう。

そして、その利用シーンに必要な機能をRedmineのプラグインやRedmineの外部で運用基盤を整えるなどの手法も必要になってくるだろうと思う。

Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索

RedmineをBPMツールとして使うアイデア: プログラマの思索

ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデア: プログラマの思索

Redmineを勤怠管理システムで運用するアイデア: プログラマの思索

Redmineを帳票ワークフローツールとして強化するstatus_buttonプラグインが面白い: プログラマの思索

この辺りのアイデアは、実現可能性も含めて、もっと探ってみたい。