プログラマの思索

Conwayの法則の拡張版として、「運用は組織に従う」「ワークフローは組織に従う」という経験則があるように感じた。
ラフなメモ書き。

【参考】
システム設計よりも業務プロセスの設計をやっている: プログラマの思索

業務システム設計の隠れた要件～会計監査やシステム監査: プログラマの思索

Conwayの法則～アーキテクチャは組織にしたがう: プログラマの思索

「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索

パターン１４：Conwayの法則　

(引用開始)
別名：
アーキテクチャは組織にしたがう
問題：
組織とアーキテクチャの整合

コンテキスト：
アーキテクチャ設計者と開発者チームが集まった。アーキテクチャは結構うまく設計されている。

影響する事柄：
アーキテクチャは組織の中での情報交換の経路を形作る。
デファクトな組織構成は、形式的な組織構成を形作る。
形式的な組織構成がアーキテクチャを形作る。
初期段階におけるアーキテクチャにしたがった定型化は、単に近似であり不安定である。

解決策：
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。

結果として生じるコンテキスト：
組織と製品アーキテクチャが整合する。

論理的根拠：
このパターンは歴史的なものである。
Gerard Meszaros (BNR)は、人々はアーキテクチャが安定してから組織をアーキテクチャに合わせようとしたがる、といっている。もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。
(引用終了)

【1】端的に言えば、Conwayの法則とは「どんなソフトウェアであれ、それを作った組織の構造を反映する」という経験則。
ソフトウェアのアーキテクチャ、ソフトウェアの複雑さは、それを作った開発した組織、利用する組織の組織構造がそのまま反映されてしまう。

よく言われる例として、コンパイラを作る開発者が4つのチームに分かれていたために、4パスコンパイラという無駄なアーキテクチャになってしまった、という事例がある。

「組織構造がソフトウェアの複雑さに反映されてしまう」というConwayの法則は、他の場面にも拡張できると思う。

【2】「ワークフローは組織に従う」経験則を感じる場面は、Redmineをいろんな現場に導入する際に、現場特有の事情からワークフローが複雑になっていく状況で痛感する。

本来は、ワークフローはシンプルでいい。
「タスク」「バグ」などのトラッカーのワークフローは、本来はそんなに複雑にすべきではない。

しかし、開発現場によっては、開発チーム以外に、品質保証部や他部署の開発チーム、オフショアの開発チームとやり取りする状況があり、複雑になりがち。

例えば、国内の開発チームが設計した設計書に従って、オフショアの開発チームがコーディングし、そのプログラムを国内の開発チームが受入する場合がある。
すると、国内の開発チームの作業のワークフローはシンプルで良いが、オフショアへ開発作業を依頼してから受入するまでの作業を進捗管理したい場合、ステータスが増えてしまい、ワークフローも複雑にならざるを得ない。

例えば、受入担当者も、仕様レビューもあれば、開発標準のレビューもあるから、担当者が変わるし、その状態に対応するようにステータスも増える。
関連する組織が増えるほど、作業の状態を表すステータスが必要になり、ワークフローも長くなっていく。

僕もステータスが10個以上あるようなワークフローを実際に見たことがある。
それは「スタンプラリー」というアンチパターンにつながると思う。

でも、関連する組織構造があれば、ワークフローに反映せざるを得ないのだ。
そうでなければ、Redmineの運用が回らないから。

【3】「運用は組織に従う」経験則を感じる場面は、システム設計ではなく運用設計を考えている時に痛感する。

ERPを導入したら、そのERPを現場でどのように使うべきか、担当者ごとに業務ごとに役割や作業内容を決めていく。
しかし、システム設計の観点でトップダウンで決めると、現場の業務担当者から総スカンを食らう。
「その作業は私の業務ではありません」と言われてしまうのだ。
大企業ほど、組織がサイロ型になっているので、自分の担当範囲以外の作業を押し付けられるのを嫌う。

すると、現場の意見を聞きながら、ERPの運用を導入すると、こんなメリットがあるから、むしろ作業した方がいい、とか、この作業は年数回しかないからマニュアルを見てやれば問題ありません、などのように、運用フローの同意を得ていく必要がある。

こんなまどろっこしい作業が必要な理由は、現状の運用フローは組織構造に従った職務分掌で決まっており、それを修正することは、組織構造を変更することにつながると直感的に感じているからだろう。

運用フローが変更されることで、作業が増えるのは拒否されるのは当たり前。
だが、現状の運用フローが変更されると、現場は混乱してしまいがちなので、拒否反応を起こしがち。

最悪なのは、ERP導入によって、担当の業務がなくなると分かったとしても、以前の部署が残り続けることで、ERP導入の反対者になってしまう状況だろう。

そんなことを思うと、現場の運用フローをシステム設計の観点で変更するのは、あちこちの部署に同意を取る根回しが必要になり、非常に面倒だ。
運用フローは組織構造を反映しているから、そう簡単に変更できないのだ。

この辺りのノウハウや経験則もプロジェクトマネージャには必要なのだろう、と今更ながら感じる。