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

Redmineの運用フローが上手く回らないという声を聞く時がある。
その理由を探ってみると、結局は、組織構造に原因がある時が多い。
以下、メモ書き。

組織は戦略に従う。そして、戦略は組織に従う。

戦略が先か、組織が先か | 組織用語 | 山内翼のサイト | yamauchi283.com

【1】経営学の有名な言葉に、「組織は戦略に従う。そして、戦略は組織に従う」がある。

「組織は戦略に従う」という命題はチャンドラーが言い出した。
本来の意味は、大企業が多角化戦略で数多くの事業に展開する時、それぞれの事業ごとに事業部制組織を作る傾向があることから、経営戦略に従って事業を作り出すタイミングで組織が生まれる、ということらしい。

僕が「組織は戦略に従う」という言葉を強く意識する場面は、社長が期首に組織変更の発表をしたがる時だ。
社長は常に経営戦略を考えており、管理職だけでなく、社員全員にもその意図を伝えたい。
しかし、実際は多数の社員に逐一説明するわけにもいかないし、社員も社長の意図をすぐに理解できるわけではない。
だから、組織変更を通じて、社長の意図である戦略を社員に伝えているわけだ。
組織変更があれば、社員も自分の職務に直接的に影響するし、組織のミッションを通じて経営戦略の意図を感じ取ることができるからだ。

一方「戦略は組織に従う」という命題はアンゾフが言い出した。
本来の意味は、大企業が多角化経営を実施したとしても、新規の戦略は既存の組織から反発を食らい、組織の抵抗によってほとんど結果が出ない、という傾向があることらしい。
なぜなら、大企業ほど官僚制組織に近くなるために、組織慣性が強くなりがちで、自己変革の行動を起こすよりも安定性を求めてしまうからだ。
サイロ型組織、地理的に離れたチームが多い組織では、どうしても組織構造の制約が経営戦略の幅を狭めてしまう。

【2】そんな言葉をRedmineに当てはめてみると、どうなのか？

僕個人の思いとしては、Redmineが本来持っているチケット駆動開発をそのまま運用すればいいはずだと思っている。
しかし、実際は、その開発現場の制約条件がRedmineの運用をかなり歪めてしまう場合が多いと感じる。

過去の経験では、組織構造の複雑さがRedmineのプロジェクト構造やワークフロー設計にそのまま反映される。

【2-1】僕が過去に経験した事例では、プロジェクトの階層が5個、ワークフローは20個が最大だった。
そのような事例では、ITILのようなフレームワークをそのまま当てはめようとして、ステータス遷移がすごく複雑になってしまった時もあった。
ITILという戦略にRedmineが従属させられていた。

【2-2】既存の組織構造や案件をRedmineのプロジェクト構造に対応づける時に、組織の問題がのぞく。

たとえば、普通のSIでは事業部制組織なので、Redmineプロジェクトは案件単位またはシステム単位に作る。
つまり、契約で定められたプロジェクト、売上対象のシステムがRedmineプロジェクトになるから、開発者にとって作業しやすい。
受託開発案件、保守しているシステムの中で、作業や障害対応は普通は閉じているからだ。

しかし、製造業のように機能別組織の場合、縦割り組織になっているために、Redmineプロジェクトが組織単位になる場合が多い。
すると、組織をまたがった作業がすごくやりにくい。
たとえば、開発部署が隣の営業部署や品質保証部と一緒に作業する時、別組織の上長の承認を得る必要があるから、稟議がやたらと多くなる。

また、営業・設計・開発・品質保証のように部署ごとにサイロ型組織に分かれていると、ワークフローが複雑になりやすい。
なぜなら、ステータス遷移のタイミングが組織をまたぐ場合に発生するからだ。
たとえば、一つの作業をやる時に、複数の人達の承認を得る必要が出てくる。

この状況は、製造業でなくても、SIで、開発チームとインフラチーム、オフショア開発チームのように数多くの部署が分かれている時にも同様に発生する。
組織構造が、Redmineが本来持つ、柔軟な運用フローであるチケット駆動開発を分断してしまうのだ。

【2-3】あるいは、社内にISO9001や内部統制(JSOX)の法的ルールが存在しているために、その法的ルールの範囲を越えてRedmineを運用できなくなることだ。

特に、品質保証部が率先してRedmineを導入・運用し始めると、ワークフローが複雑になり、ステータス遷移が多くなりがち。
また、「～してはいけない」というルールばかり、はびこってしまい、多種多様な開発・保守案件の作業管理にRedmineが逆に対応できなくなってしまう。
そして、Redmineのチケット登録そのものが億劫になって、障害管理表やQA表というExcel管理表が共有フォルダに復活してしまうのだ。

ガチガチの社内ルールは、闇Excelを蔓延させる。
ISO9001やJSOXが、Redmineが本来持つ、柔軟な運用フローであるチケット駆動開発の良さを消してしまうのだ。

【3】そんな事例を見ると、「Redmineは戦略に従う」「Redmineは組織に従う」という思いが強くなる。

Redmine導入時に、社内の標準プロセスとのフィットギャップ分析するのはいい。
でも、やり過ぎると、現状(AsIs)の組織構造や社内ルール、運用フローに引きずられて、あるべきRedmine(ToBe)の運用フローは成立せず、現状の闇Excelの作業データを流しこむだけのRedmineになってしまう場合がある。

あるいは、現状の組織構造が複雑なために、プロジェクト構造が複雑化したり、ワークフローの設計が複雑になったりする場合がある。

こうなっては、本末転倒だ。

業務システムの要件定義では、AsIsの運用フローに引きずられすぎず、ToBeの運用フローの作成に時間を書けるべき、というアドバイスをよく聞く。
Redmineのシステム運用フローの背後に組織構造を感じるとき、このアドバイスをいつも連想する。

【追記】
門屋浩文@redmineエバンジェリストの会🎶さんのツイート: "思うに　@akipii と @hiroki_daichi は同じようなことを伝えてくれている。組織の癖が、redmineや完成する成果物に強烈に影響することを。ものすごく共感しています https://t.co/jYkjg9Lyai"