Redmineインスタンスはチームの組織文化や慣習を表す

Redmineインスタンスはチームの組織文化や慣習を表すという指摘が非常に参考になったのでメモ。
アイデアの途中メモ。

【参考1】
Redmineを運用している規模について - Google グループ

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

(引用開始)
私自身、【結局、「Redmineだめじゃん」】って言われるのを避けたくて、
いろんなプラグインを入れて、こういう使い方できますよと宣伝しながら
各プロジェクト単位でいろんなモジュール選択できる＝いろんな使い方ができるように環境を整えてきましたが、
結局、自分の所属するチーム以外に文化として根付かせるのに失敗しております。

で、ふとRedmineを使い始めてからの挫折の流れを自分の経験から追って考えてみたのですが、、、

--------------------------------------------------
①Redmineが使える環境を準備するのが大変だった。
→Bitnami Redmineで簡単にインスタンスはたてられるようになった。
　→でも、デフォルトのままでは組織や業務にマッチしていないので、、、
　↓↓↓
②Redmineのプラグイン導入で苦戦した。
→基本的には手順は同じなので、慣れれば大丈夫だけれど、
　たまにプラグイン同士が競合したりすると、自分でパッチを当てたりしていた。（諦めたこともあります）
　→でも、めちゃくちゃ便利そうなプラグインが現在のバージョンに対応していないことがわかり、、、
　↓↓↓
③Redmineのバージョンアップで苦戦した。
→データ損失が恐怖なので、バックアップとリカバリの手順を、他のサーバで完全再現できるまで念入りに確認しました。
　その環境上でプラグインの依存関係の確認もして、バージョンアップしました。
　→さあ、これだけ充実したRedmine、ぜひ他の人にも使ってもらいたい、、、
　↓↓↓
④他チームへの展開で失敗した。
→Redmineやプラグインの動きは、私のチームは①?③までの経験で見識を広げることができたけれども、
　他の人からすると、いきなり選択肢が多すぎて、それらを取捨選択して活用する道筋が見えませんでした。
　→すると、どうしてもそのチームの既存プロセスをRedmineに当てはめる傾向になりがちで、
　　Redmineに変えた意味ってあったんだっけ？って思われてしまいました。（最終ログイン日時が止まっているという・・・涙）
--------------------------------------------------

自分のチームと比較した時に何が違ったかというと、
Redmineがデフォルトの状態からバージョンアップやプラグイン導入などで改良されるにつれて、
チーム内のRedmine成熟度もあがり、利用プロセスも改良されていったことのように思います。
(中略)

それ故に、うまく動いているRedmineについ相乗りしたくなりがちですが、
1つのインスタンスそのものがチームの文化や慣習のようなものと考えれば、飛び込んでカルチャーショック受けるよりも、
デフォルトの状態からそれぞれのチームでRedmineのインスタンスを立てて、
チームと一緒に文化を成熟していくのがシンプルに上手くいくのかなぁと今は考えております。

そして組織や文化の問題を除けば、②や③のポイントでつまづきにくいような
新鮮な情報やサポート、こういう場のQAがこの先もっと潤えばいいなぁと思います。（「Redmine実践ガイド」はその1つですね）
(引用終了)

【1】最初は、自分のチームだけのためにRedmineを導入して、チケット駆動の運用がうまくいくと、隣のチームも相乗りして使いたくなる。
あるいは、自分が担当する他のプロジェクトも、Redmineに作業や障害の情報を集約して、運用を拡大していく。

そして、Redmineの運用規模が、当初想定していた数人の利用者から、100人以上の利用者で100個以上のプロジェクトまで増大していく状況はよく見られるし、僕自身も何度も経験してきた。

すると、小規模チームで有効だったチケット駆動開発という軽量プロセスの運用ルールが、大規模なチームや大量の案件、ソフトウェア開発以外の業務の作業管理へ拡張していくに連れて、どんどん複雑になってしまう。
特に、トラッカーやカスタムフィールドは、案件の種類、業務の種類、組織構造の影響を受けやすいので、肥大化しがちだ。
例えば、同じようなワークローであっても、ステータスの呼び名が違うと、別の部署の人は混乱しがちで、使いづらい、と苦情を言いがちだ。

上記の指摘では、「Redmineインスタンスはチームの組織文化や慣習を表す」のだから、業務や組織構造の観点で、複数のRedmineインスンタンスに分けて運用した方が良いのでは、と言う。
その意見は同感だ。

【2】Redmineの運用は、正直楽しい。
トラッカーやワークフローを考える作業は、自分がチームのプロセスを一から作っていることに相当する。
自分たちがやりやすいプロセスに改善する方法を考えて、Redmineに適用してみたら、その成果がすぐに現れる。
その試行錯誤が楽しい。

RedmineはRuby on Railsで作られているので、ソースのカスタマイズも簡単だし、RubyスクリプトでREST APIを呼び出して、好きなだけチケット集計機能を作りこんでも良い。

RedmineインスタンスはBitnamiで簡単に作れるので、チームのRedmineに反映する前に、事前に自分のローカルPCでプラグインを事前検証することも可能だ。

Windows版Bitnami Redmineをインストールする - Qiita

そのように、Redmine上にプロセスを作りこんで、Redmineをカスタマイズしていくと、Redmineインスタンスには、自分たちのプロセスが埋め込まれている。
自分たちのソフトウェア開発や業務がやりやすいように、最適化されたRedmineになっている。
だから、他チームや他部署が使いづらい、と苦情を言うのは当たり前だし、その苦情を受け入れていくほど、Redmineの設定もワークフローも複雑化していく。

今はサーバーは安いのだから、一チームに1個のRedmineを渡しても良いのではないか？

【3】でも、一つのRedmineインスタンスで、大規模運用したい動機もある。
例えば、ISO9001や内部統制に即した運用プロセスをRedmineで実現したい場合、1個のRedmineインスタンスに全ての作業情報を集約し、トレーサビリティと全文検索を実現したいのだ。

そうすれば、Redmineに蓄積された作業情報から、ISO9001や内部統制の内部監査でも、必要な資料を即座に探し出し、その障害や事案の発生元の要件まで追跡する事が理論上できる。
今までの内部監査のプロセスでは、これらの作業を大量の紙媒体やExcel資料を使って運用をカバーしてきたのだから、IT化して作業を効率化したい、と思うのは普通だろう。

実際、今の日本の製造業を中心とする大企業は、こういう無駄な管理作業に、大量の人員とリソースをかなり費やして、ビジネスのスピードを落としている現状があるからだ。

しかし、Redmineは元々、障害管理ツールから生まれたツールなので、ISO9001や内部統制に必要な機能要件や性能要件を全て満たしているとは限らない。
もう少しかゆい所の機能も改善して欲しい部分もある。

【4】今、僕が考えている課題は「多様な案件かつ多様な業務を一つのRedmineインスタンスで運用するには、どんな機能やどんな運用ルールが必要なのか」だ。

Redmineで、ソフトウェア開発のほとんどの開発業務はカバーできるし、他業界のタスク管理や問合せ管理や資産管理などにも運用を拡張できることは、経験してきたし、かなり上手くいく。
Redmineの特徴である、多様な機能と柔軟性、Railsのおかげによるカスタマイズによる機能拡張のしやすさ、というメリットが大きく効いている。

例えば、日本の製造業に多く見られる機能別組織構造は、どうしてもサイロ型組織になりがちで、部署間の風通しも悪い。
しかし、Redmineを導入することで、Redmineプロジェクトにアサインされた複数部署のユーザがあたかもプロジェクト型組織に属するような雰囲気になり、チケットのやり取りを通じて、メンバーの信頼関係を育み、チームのプロセスを改善していく雰囲気も生まれるメリットがある。

でも、Redmineも業務プロセスを改善する一つのツールであるがゆえに、自分たちのプロセスがRedmineに埋め込まれているし、一度埋め込んだプロセスに関する設定を、後から大きく変更することは容易ではない。
JAXA担当者が編み出した「ロールのORルール」「カスタムフィールドのANDルール」は、Redmineの運用が大規模化していく過程で、Redmineの複雑さを軽減する一つの方法。

Redmineインスタンスに埋め込まれた、チームのノウハウというべきプロセスの思想、そこから生まれるチームの文化や慣習を、どの範囲まで拡大運用できるのか？