コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想

本日のDevelopers Summit 2013 Summer：エンタープライズに向けた「DevOps」&「Mobile」のカンファレンスで、和智さん翻訳・コプリエン著のアジャイルソフトウェア開発の「組織パターン」が販売されていた。
ラフな感想をメモ書き。

【1】コプリエンの論文「生成的開発プロセス・パターンランゲージ」はとても素晴らしかった。
その感想は以前書いた。

パターンランゲージの形式と正当性: プログラマの思索

組織パターンとプロセスパターン: プログラマの思索

Coplienの開発工程の生成的パターン言語を読むpart1: プログラマの思索

同様に、「組織パターン」でも、第1・2章に書かれているパターンの考え方や動機に関する洞察がすごいと思う。
特に「2.1.2節　最高傑作の欠点」に書かれているプロセス中心主義への洞察は非常に鋭いと思う。
プロセス中心主義の欠点を彼は次の3つで説明している、と僕は理解している。

【1-1】実践とプロセス定義が経験的に擦り合わされていない。

多くのプロセスは振れ幅(変動、揺らぎ)が大きいため、プロセスを定義しようとしても、他のプロジェクトではプロセスを再現しにくい。
したがって、プロセスの典型的なシナリオがどれなのか、を関係者が合意しにくいのだ。
そんな事情があるために、プロセス中心主義の組織は、理想的なプロセス定義(ToBeモデル)を作り上げるだけでなく、理想的なプロセス定義(ToBeモデル)をベースラインにしてしまう。
それゆえに、プロセス定義モデルは、現場の個別の状況(コンテキスト・AsIsモデル)とかけ離れているために、各チームは現場で編み出されたプラクティスに自信を持てない。
せっかく暗黙知から実践知として生み出したプラクティスというノウハウが、プロセス中心主義では生かされないのだ。

この指摘は、ToBeモデルありきではなく、AsIsモデルから指向すべきであり、AsIsモデルを少しずつ継続的に改善する適応型開発が良いという主張につながる。
つまり、まずは試してみて、実践知を貯めていきながら、製品を作り上げていくという適応型開発の方がうまくいくのだろう。

【1-2】プロセス中心主義は、タスクやイベント中心に考えていて、プロセスモデルが不十分。

WF型開発は、工程における作業の品質を重視するために、作業の手順やイベント(レビュー、テストなど)を重視する。
タスクやイベントを重視する方向性は、プロセスの自動化と相性が良い。
実際、手順化できるということは、手続き型プログラムに近くなるので、自動化することでプロセスを再現しやすくなるからだ。

それゆえに、組織のもう一つの側面であるロールや成果物を軽視している。
しかし、むしろ、ロールはプロジェクトよりも安定している、と。
チーム構成における役割は、どんな種類のソフトウェア開発であれ、それほど大きな差はないはずだ。

多分、ロール指向のプロセスという発想から、Scrumのフレームワーク(PO・CSM・チーム)が生まれたのだろうと推測する。

スクラムの新しさ: プログラマの思索

実際、Scrumは、3つのロール、4つのイベント、3つの成果物のフレームワークと呼ばれている。

重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） － Publickey

【1-3】プロセスが長期に安定するように抽象化できていない。

プロセス中心主義は、手順や工程を重視したタスク指向になりやすいが、タスクの優先順位は頻繁に変わるため、タスクはプロセス構造上、安定した基盤にならない。
例えば、設計、実装、検証などの中核プロセスはタスクだけでは把握できない。
設計した通りに作ってみたら、実は技術上の問題や性能上の問題がテスト工程で判明して作り直した、などの例は枚挙がない。

そして面白いことに、開発チームのほとんどは、公式プロセスではなく、実は、プロセス定義が認める例外的なプロセスの下で作業していた。
多分その理由は、プロセス定義というToBeモデルが現場の実情とかけ離れているために、現場では常に例外的な状況におけるプロセスでしかToBeモデルを実現できないからだろう。

また、最近のソフトウェア開発は高度な並行開発であり、イテレーティブかつインクリメンタルな開発にならざるをえない。
実際の現場では、WF型開発のような、鎖のように一直線の工程で連なるプロセスとして定義できないのだ。

例えば、経験豊富なプロマネは、WF型開発を実施していると標榜していても、実は、裏プロセスとして、プロトタイプを先行開発しながら、顧客から引き出した要件やアーキテクチャを検証するプロセスを並行して走らせたり、大規模システムを分割して段階リリースするという並行開発の手法を取っている時が多い。
つまり、並行開発のプロセスが必要だが、そのモデルはプロセス標準が定義するモデルと違うことは、開発者もリーダーも実は自覚している。

裏プロセスは並行プロセス: プログラマの思索

しかし、並行エンジニアリングを採用する組織は、逆説的に、プロセス中心主義が定めるプロセス定義に忠実になろうとしていた。
むしろ、ロールを元にしたモデルの方が、タスクやイベント指向のモデルよりも安定しているがゆえに、現場のプロセスにうまく当てはまるのではないか、と。

この主張は非常に同感。
但し、並行エンジニアリングを採用する組織は、なぜWF型開発に忠実であろうとする行動に陥るのか、本文では読み取りにくかった。
おそらく、並行開発で成功した現場は、自分たちが生み出した実践知をプロセス標準モデル(ToBeモデル)の枠組みに反映させることで、自分たちの実践知の正当性を評価して欲しいという気持ちが暗黙的に表現されているのだろうと推測する。

【2】そのような背景を元に、組織を「正式な組織」よりも「インストゥルメンタルな組織」として捉える。
和智さんに聞いた所、「正式な組織」は部署のような形式的な階層構造で規定された組織に対し、「インストゥルメンタルな組織」は自然発生的に人が集まり、各メンバーにロールが割り当てられたチームのような組織という意味だそうだ。

ロール指向の組織である「インストゥルメンタルな組織」は、組織のタックマンモデルを連想させる。
つまり、組織が有機体として力を発揮するには、各メンバーで対立や混乱を経た後に、ロールが各メンバーにアサインされて安定したチームが形成されるのだろう。

Educate.co.jp | タックマンモデル

新たな習慣へのトライ　タックマンモデルを体感する

コプリエンは、組織をロール指向で捉えるための手法として、CRCカードを使って、ソシオグラムやインタラクショングリッドでグラフ化する。
ロール間の結合度や凝集度をグラフや表で表現するわけだ。

その手法を使うことで、優れた組織はどんなロール間の特徴があるかを探りだす。
それが組織パターンになる。

彼の調査方法は非常に帰納的で、社会学みたいだ。
ボーランドとAT&Tの2つのグループしか対象にしていないという弱点があるけれども、組織パターンの内容は普遍性があるように直感的に思う。

【3】全般的な感想としては、各パターンが叙述的で、ちょっと読みづらかった。
下記の本にあるCoplienの論文のパターン形式のように「コンテキスト」「フォース」「解決策」「適用結果」「論理的根拠」によるカタログの方が分かりやすい。
「組織パターン」の文章のうち、どれがコンテキストで、どれがフォースなのか、を理解するのが面倒だった。

和智さんに聞いた所、各パターンをカタログ化するよりも、パターンを組み合わせた全体像を主張したかったのでしょう、と聞いて納得した。
実際、「プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集」と比較すると「組織パターン」では、パターンの関連図が章の冒頭に記述されていて、パターン同士の関連性が分かりやすく書かれている。

【4】「組織パターン」を読んでみて、プロセス改善はToBeモデルありきよりも、AsIsモデルから小さく継続的に改善する方向の方が成功しやすい、という感想を持った。
プロセス標準モデルというToBeモデルをベースラインにしても、現場のプロジェクトは変動が大きすぎて、適用しにくいのだ。
むしろ、個別の現場で実践知を貯めて、少しずつ改善していくボトムアップアプローチの方が良いのだろう。

でも、その指摘はユーザ企業の業務改善(BPR)のやり方と何となく違和感がある。
いわゆるERP導入で業務改革する場合、ERPというToBeモデルを一気に導入することで、ユーザ企業の組織構造そのものも変えてしまう。
ERP導入はトップダウンアプローチが普通。

システムで業務を自動化することで、人を減らし、コストカットできるメリットを活かす。
ERPで実現されている業界のベストプラクティスを導入することで、業務の効率化を目指す。
AsIsモデルを残すことは、逆に従来の非効率なプロセスを残してしまい、改革が中途半端になる。

DOAの優れたアーキテクトは、AsIsモデルは描かずにToBeモデルから始める。
その理由は、AsIsモデルに囚われ過ぎると、本来のあるべきシステム(ToBeモデル)が曖昧になってしまうから、と言っていたのを思い出す。

とはいえ、ERP導入は失敗事例が多い。
その理由はToBeモデルありきでは、現場のAsIsモデルから生み出された実践知を無視しているからだろう。
アジャイル開発が現代のソフトウェア開発プロセスとして成功しやすい理由の一つは、現場の実践知を大切にすることで、自然に、変化に富んだビジネスに対して適応型開発を実現できるからだろうと思っている。