プログラマの思索

大規模組織におけるRedmineを巡る諸問題について、色々考えている。
以下、ラフなメモ書き。
特に主張なし。

【1】最近は、Redmineに組織構造がどのように影響して、Redmineのプロセスや運用ルールが変形されるか、という問題意識を持っている。
下記3点について考えてみる。

1)Redmineプロジェクトに組織構造が出てくる点

但し、下記2点は後回し。

2)機能改善の要望への対処
3)保守コスト増に対する対処

Redmineのマイクロコア化は可能か～Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【2】最近は、Redmineプロジェクトはシステム単位に作るべきなのか、組織単位で作るべきなのか、という問題を改めて感じている。

以前から、Redmineの複数プロジェクト機能のおかげで、製品の並行開発や製品の派生開発がやりやすい特徴があった。
しかし、大人数のユーザで使用し始めると、組織構造の影響がモロにRedmineに出てきて、逆に運用ルールが複雑化しがち。
特に、Redmineでは、プロジェクトツリーをいくらでも深く作れるので、Redmineプロジェクトをその時々の判断で作ってしまいがちだ。

そもそも、Redmineプロジェクトはどの基準で作るべきなのか？

【2-1】本来のRedmineの設計思想を振り返ると、Redmineプロジェクトはリポジトリと1対1に対応すべき、と考えられる。
Ver1.4までは、Redmineプロジェクトにリポジトリを1個しか追加できなかった。
その後、複数のリポジトリを追加できるようになり、GitもSVNも複数のSCMリポジトリも登録可能になったので、その設計思想があやふやになったけれど、たぶん変わっていない。

すると、その設計思想では、Redmineプロジェクトはシステム(ビルドモジュール)単位になる。
実際、ソフトウェア開発案件のタスク管理では、システム単位にプロジェクトを作る場合が多い。

さらに、その設計思想では、Redmineプロジェクトのライフサイクルは、SCMリポジトリが新規登録されて、システムが廃棄される期間と一致する。
すなわち、Redmineプロジェクトはシステムの生存期間と同期するので、Redmineは特定の期限を持つ案件の管理に向く。

【2-2】逆に、Redmineプロジェクトを組織と対応付ける運用はやりにくい。
組織内にはたくさんの案件があり、作業の種類も多いので、一つのRedmineプロジェクトでチケット管理すると、すぐに発散する。
かと言って、小さくプロジェクト分割しても、組織のメンバーの入れ替わりも激しかったりするので、放置されやすい。
僕の経験では、Redmineプロジェクトを組織に対応付けた場合は、上手くいった経験があまりない。

【2-3】この発想を突き進めると、Redmineでタスク管理を行うと、開発チームはプロジェクト型組織になりやすい。
つまり、開発チームのメンバーは、別々の組織のメンバーであったとしても、Redmine上では、あたかも一つの有機的なチームとして活動する雰囲気になる。
これは、Redmineが組織に与える「良い影響」だ。

たとえば、業務系Webシステムの開発がメインのSIならば、一つの事業部内では、インフラチーム・アプリチーム・デザイナーチームのように機能別組織に分かれている場合が多い。
インフラ・アプリ・デザイナー担当者に要求されるスキルや技術は全く違うからだ。
(と言っても、最近のWeb開発では、アプリ担当者がインフラもデザインも全て担当するようになってきているが)

そして、実際の受託開発案件では、案件ごとにインフラ・アプリ・デザイナーの担当者が一つのチームを形成するようにアサインされて、作業を開始する。
Webサーバーの構築、画面のモックやデザイン配置、実際の業務ロジックの実装など、それぞれの役割分担で、作業しなければならない。
すると、各担当者は、その組織に応じた考え方や、特有のスキルに応じた考え方を持っているために、別組織の担当者と衝突しやすい。
インフラ・アプリ・デザイナーは機能別組織に所属しているから、そう簡単に融合できないのが普通だろう。

しかし、Redmine上では、一つの作業チケットを複数人のメンバーがやり取りして、完了まで持っていく。
そういうチケットのやり取りを何度も消化していくうちに、各担当者のコミュニケーションが生まれ、各担当者同士でお互いの背景や考え方の認識のズレに気付き、協調して、一つの作業を完了していく。

つまり、Redmine上では、自分の組織の役割を主張し合って衝突するよりも、チケットのやり取りを通じて、あたかもペア作業のような雰囲気が生まれて、一つの有機的なチームが形成されやすい。
Redmineではアジャイル開発のプラクティスを適用しやすかった、という僕の経験は、おそらくそのような構造があったからだろうと思う。

【2-4】しかし、Redmineの運用対象はプロジェクト型組織が向いているからと言って、いつも、サイロ型組織の悪習を打破できるわけではない。

実際、Redmineプロジェクトをシステム単位ではなく、組織単位に作ってしまう場面もたくさん見てきた。
「工程単位のプロジェクト」はRedmineの一つのアンチパターンと僕は思っているが、そのような作り方をやりたい時もある。

例えば、ある大規模な受託開発案件で、製造フェーズのみ外注のオフショアベンダーに発注したとする。
すると、設計・結合テストは国内チーム、製造フェーズはオフショアベンダーのように、工程ごとに組織が分断される。

すると、Redmineプロジェクトは、設計・製造・結合テストのように工程ごとのプロジェクトに分割したくなる。
実際、1個のRedmineプロジェクトで管理したとしても、前工程のチケットが交じると作業しにくいからだ。

また、障害チケットを発行する時、その障害の発生工程がどこであるか、を記入する事が重要になるが、それが当たり前の時、記入するのも面倒だ。
特に、オフショアベンダーから納品後のプログラムをテストして障害が出た時、その障害チケットは、他工程の障害チケットと明確に分けて、目立つようにしたい。
なぜなら、障害修正の責任は国内チームではなく、オフショアベンダーにあるので、そのコストをベンダーに押し付けたいからだ。
たいていの場合、オフショアベンダーの仕様の理解が甘かったり、国内チームの設計が甘いという色んな理由で、ベンダー納品のプログラムの障害は多発しがち。

すると、単純なトラッカー名「障害」ではなく、「障害(ベンダー名)」とか「障害(結合テスト)」のようなトラッカーを作ってしまいがちだ。
トラッカー名を他の名前と変えて、大きく目立たせるようにしたいから、そのような運用になってしまう。
つまり、トラッカーやワークフローも増加してしまい、より複雑になりがち。

また、そんな雰囲気になると、Redmine上では、障害修正やその対応に関するQAのやり取りで、メンバー全員が疲弊してしまう雰囲気になる。
Redmineがプロジェクト型組織を促し、メンバー同士のコミュニケーションを活性化させて、有機的なチームを形成するような影響も出てこない。

【2-5】いろんな事例を見てくると、Redmineプロジェクトがシステム(機能)単位なのか、組織単位なのか、という観点は、下記の基準で評価できると思う。

Redmineプロジェクトをシステム単位に設定したい時は、メンバーが地理的にも組織的にも分散せずに、一つのチームで固まっている場合だ。

Redmineプロジェクトを組織単位に設定したい時は、工程単位に国内チームとベンダー、オフショアチームのように、地理的にも組織的にも分割されている場合だ。

そのように考えると、ソフトウェアアーキテクチャだけでなく、開発プロセスも組織構造に大きく影響を受けてしまう事実がよく分かる。
まさに、コンウェイの経験則の正しさがRedmineでも感じられるのだ。