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

Redmineが日本人好みのツールであるという仮説について、考えていることをラフなメモ書き。

akipiiさんのツイート: "Redmine はアジャイル開発よりもWF型開発に向いているから日本で流行している仮設あり。RT @vvakame: 他人をこき使うにはGitHubよりRedmineのほうが適しているのではないかという着想を得た"

akipiiさんのツイート: "@makopy_inside 分かります。Redmineのようなチケット管理ツール は本来はアジャイル開発に向いているのに、日本ではWF型開発の仕組みに取り入れられてる。原因を調べたい。"

akipiiさんのツイート: "@makopy_inside 発注者、受注側元請け企業、下請けPGの観点でそれぞれの事情がよく分かります。ソフトウェア開発がコモディティ化した現在、Redmineのようなチケット管理ツールで作業内容をやり取りしたい動機が多くなっている状況なのでしょう。そこにWF型開発があるみたい"

【1】Redmineが日本で普及しているのはなぜなのだろうか？
実際、世界で見れば、RedmineはTracの人気度にも及ばないらしい。
世界では、日本以外に、ロシア、韓国、台湾、チェコなど世界の東側でよく使われているらしい。

Redmine 10周年記念 10年ふりかえり from Go Maeda

Redmineの9年間の歩みを振り返ってみる from Go Maeda

【1-1】「Redmineが日本人好みのツールである」という仮説については、以前書いた。

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

理由は下記の3つがあると思う。

(1)Redmineはライセンスが無料であり、導入や設置が簡単で、保守工数だけで十分であること
　日本のIT企業やソフトウェア開発の現場では、開発基盤にコストを払ってもいいという認識はないから。

(2)パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれていて、自社の開発プロセスにフィットしないから。
　「Redmineは組織の戦略に従う」「Redmineを組織構造や開発プロセスに従わせる」ことがやりやすいから。
　日本人は、ERPにせよ業務システムにせよ、自社の組織や業務に沿った仕様へカスタマイズしたい動機が強すぎる。
　特に、日本人の帳票レイアウトへのこだわりは尋常ではない。

(3)自分たちで機能拡張していく機運が生まれて、現場主導で業務を効率化していこうとする動機づけを強化してくれること。
　つまり「カイゼン」が自主的に生まれやすいこと。
　日本人はラディカルイノベーションよりもプロセス・イノベーション、持続的イノベーションの方が得意であり、Redmineはその気質に向いているツールである。

【2】Twitterでのやり取りでもう一つの仮説を思いついた。
それは「Redmineはアジャイル開発よりもWF型開発に向いているツールだから、日本の現場で適用しやすいのではないか」という仮説。

akipiiさんのツイート: "「JiraよりもRedmineの方がWF型開発に向いている」という仮説があるのか。 https://t.co/JLeLaXVYX7"

akipiiさんのツイート: "Redmine はアジャイル開発よりもWF型開発に向いているから日本で流行している仮設あり。RT @vvakame: 他人をこき使うにはGitHubよりRedmineのほうが適しているのではないかという着想を得た"

僕はそもそも、Redmineはアジャイル開発の作業管理に非常に向いていると気付いて、その裏にはチケット駆動開発という開発プロセスがあるのではないか、と思っていた。
しかし、日本の実際の開発現場は、ほとんどがWF型開発が主流のはずだ。

色んな人の話を聞くと、Redmineを使ってみたい理由は、いくつかある。

【2-1】一つは、ガントチャートがデフォルト機能であること、チケットの階層化でWBSを表現できることにあるみたい。
つまり、MSProjectやExcelのガントチャートをRedmineでWebで表現して共有できることにメリットを感じているみたい。

以前は、チケットを階層化した場合、親チケットの開始日・期日・進捗率・予定工数は、子チケットの属性値を自動で集計してしまうために使いづらい、という声があった。
本来は、WBSの100％ルールにより、親チケットは子チケットをロールアップすべきなのだが、実際の運用では、試行錯誤しながら階層化したい場合が多く、当初入力していた予定期間や予定工数が、子チケットを作った時点で消えてしまうのが使いづらい、と言われていた。
しかし、Ver3以後では、親チケットは「子チケットから独立」の設定が可能になったので、この点もクリアされている。

Redmineの親チケットの値に子チケットをロールアップさせない設定方法: プログラマの思索

特に昨今、オフショア開発やニアショア開発が普通になってきているので、オフショアチームや社外のベンダーと障害だけでなく、課題や作業の情報を共有したい場合、Webアプリでやりたい動機がある。
その時に、Redmineを導入すれば、ライセンスが無料だし、仮想サーバーにBitnamiを入れればすぐに稼働でき、ガントチャート画面上で進捗状況を即座に把握できる。
その時に、WBSの修正や操作は、直感的に気軽にやりたいニーズがある。

SIだけでなくメーカーでも、そのようなニーズがあるのだから、日本でもRedmineが相当に使われているのではないか、と思う。

【2-2】もう一つは、複数プロジェクト機能があるので、大規模な作業管理にも適用しやすく、派生開発やプロダクトラインのような製品ファミリーの並行開発にも向いている点だろう。

プロジェクトの階層化によって、複数プロジェクトの案件を横串で集計できるし、一つの案件で複数チームの作業管理を子プロジェクトで分割統治できる。
Redmineは本来は少人数のタスク管理に向いたツールだが、プロジェクトの階層化機能を使えば、100人月規模のタスク管理にも使えるだろうと思う。

SIで大規模な開発案件でタスク管理を共有したい場合はあるし、最近は新規開発よりもソフトウェア保守や派生開発の方が案件が多い。
だからこそ、気軽にプロジェクトをたくさん作れて、作業規模が大きくなっても管理したいニーズがあるのだろう。

その場合、Redmine上の組織構造としてはマトリクス型組織になるだろう。
すなわち、製品ラインと機能・職種というラインのマトリクスで、タスクと作業者が各プロジェクトにアサインされるので、メンバーは作業の役割を認識しやすくなるし、作業負荷も担当チケット数で把握しやすくなるメリットが出てくる。

【3】他には、日本企業の組織構造が機能別組織に偏っているため、Redmineを取り入れるとプロジェクト型組織の雰囲気が出てきて、組織が活性化するという点があるのではないか、と思う。

日本ではWF型開発が主流である理由の一つは、組織体制がWF型開発に最適化している環境になっていて、おそらく機能別組織のような縦割り組織が主流だからではないか、と思う。
しかし、機能別組織でも、Redmineを導入すると、体制上はPJ型チームになり、一つの有機的なチームが形成されやすい利点がある。

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う～システム運用フローの背後にある組織構造の影: プログラマの思索

他に、IOT案件のように、ハードウェアチーム・ソフトウェアチーム・サポートチームのように気質が違う複数チームでやり取りしたい場合もある。
その場合、機能別組織に複数プロジェクト機能を対応付けて、それぞれのレイヤーで作業をチケット化して、管理する方がチケットの粒度もまとめやすいし、プロジェクトごとにチケット管理の特徴を出しやすい。

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい: プログラマの思索

すなわち、古い日本企業の組織構造にRedmineを取り入れると、当初は想定しなかったメリット、つまりPJ型組織やマトリクス型組織の雰囲気が出てくる点があるのではないか。
一方、既にアジャイルな開発組織の場合、PJ型組織やマトリクス型組織をツール上に作る必然性はないので、Redmineを使うメリットがそう感じられないという点もあるのではないか。

つまり、Redmineにガントチャート機能があるから、という単純な理由よりも、日本の硬い組織構造をRedmineが柔らかくしてくれる所にメリットがあるような気がしている。
そうであれば、Redmineを組織変革のためのツールとして使えないか、と思ったりもする。
色々考えてみたい。

第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』 from akipii Oga

【追記】こんな意見もあり。

まいく@定時に帰りたいさんのツイート: "時代はScrumだJIRA使うぞー！って感じでJIRA導入したけど我々が本当にやりたかったのはマルチプロジェクトのWFだということが分かりRedmineにしたい"