組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論

RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。

この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。

いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。

人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違うかもしれない。もっと自然に、必要な人と必要な人が話したり、そういうパス(経路)の発見を手助けするハブになる人というのがいるものなのだ。

ツリー型組織の問題は、3階層、4階層と深まっていくと、部署を超えた末端実務者どおしのコミュニケーションの「間に入る人」が増えていくことだ。その結果、Small World仮説だと6次の隔たりで世界中の人が話せるかもしれないというのに、たった数百人の社内で話すだけで6次以上の隔たりが常態化してしまう。おそらくこれは効率的な組織とはいえない。

組織の調査をしてきた。人々がもつパスの数を調べると、そのヒストグラム(パス数ごとの人数分布)は、通常の組織では5を中心とした正規分布になる。5人前後のつながりを持つ人が多いということだ。ツリー型の組織で一人の上司が4人の部下を持ち、それが多階層になるとこうした分布になる。しかし高効率の組織はパス数が少ない人が多く、パス数が増えるにつれて該当人数は指数関数的に減少していく。しかし一方で、非常に多数の、数十のパスを持つ人も複数現れる。この人々がハブだ。

f:id:wayaguchi:20191205173804j:image

インターネットなどのスケールフリーネットワークは、ローカルの密なつながりと、ハブを経由したネットワーク間のつながりで構成されていて、しかも冗長性を確保する。一本の線が切れても、ほかの線でつながることで、パフォーマンスは落ちるが全体が不通になることを避けるようになっている。組織も同じで、ツリーにこだわらないノード間のつながりが重要。それは自然に起きていて、効率的な組織ではそれが観察される。

アジャイルではトラックに一人轢かれると業務が出来なくなるのがトラックナンバー=1という。組織がツリー構造だと上司が単一の経路になり、上司が休暇に入るとネットワーキングのパスが切れてしまう。ネットワークの冗長性がない。スケールフリーネットワークは複数のハブが機能することで冗長性を担保する。トラックナンバー=1を避けることは重要だ。

ウォーターフォールの元の論文を書いた Winston Royceは論文の中で、フィードバックが必要だと言っていて、つまりやってみて新しい情報が明らかになったところで手戻りをすることは必然。しかし、現在、一般的に言われる「ウォーターフォール」は、各段階を別々の組織が担う。企画、設計、開発、品質保証、それぞれ別の人たちで、組織をまたがる手戻りは、許されていてもなかなか起きない。スクラムはそれをできるかぎり1チームのクロスファンクショナルな組織でやろうと言っている。そうすれば、フィードバックを素早く受けて、チーム内で柔軟に手戻りができる。

ウォーターフォールからアジャイルに移行しようとすると、これまで情報を握っていた中間の管理職が不安に陥る。自分の頭越しに情報が行き来することになるからだ。しかし、組織にとって、一番末端に近いマネジメントは実際の現場をマネジメントしているが、マネジメントをマネジメントしている人たちは現場にアクセスしていない。これはトヨタの現地現物、ホンダの三現主義でいえば、ありえない話だ。管理職が考えている以上に、組織はもともとスケールフリーネットワークで動いている。中間管理職をなくしても、各チームが自律的にマネジメントすればよく、大規模な組織でもおそらく運営可能だ。ただし、同じ組織は2つと無いので、実験してみる必要がある。

上司を通さずに、隣の部署の上司やチームメンバーと会話をするのが、スケールフリーネットワークの重要なところ。そのつながりを多数持つのがハブだ。一方で、チーム同士が密結合してしまうと効率が悪い。あくまで仕事はローカルなチームで独立してできるようにして、かつ、ハブになる人がチーム間をつなげていく。チームで解決できない問題があったら、ハブに相談すれば、適切な人たちをきっと紹介してくれる。スクラムマスター同士が行う Scrum of Scrums はその一例だろう。しかし、Scrum of Scrum of Scrum ... のように多層になっていくと、ツリー構造になり、これまで言ったような不都合を生じてくるのではないか?

ハブとスケールフリーネットワークは新しいことではなく、自然に発生している「パターン」だ。ハブを任命して作る、というものでもないだろう。どうやったらハブになれる人を育成できるか?というより、それは自然にあるもので、むしろ阻害する要因が既存の組織のマネジメント階層にある。頭越しに情報をやり取りすることを阻害する上司がそれだ。非公式な専門家同士のつながりに Birds of Featherというパターンがある(A Scrum Book)。SpotifyのGuildなどもその一例だろう。

その後飲み会で話していて、第一歩として「ハブがよいことなのだ」という認識が大事だなと思いました。パターンの名前づけの力。そうでないと「上司を差し置いて隣の部の人と話すと上司が気を悪くするかも」という余計な懸念が人々の活動を止めてしまう。むしろその考え方が危ないのに。

いやー、RSGTでの基調講演がとても楽しみです。

confengine.com

 

今回のイベントはこちらでした。

taco.connpass.com

f:id:wayaguchi:20191205105125j:image
ありがとうございました。

関連する本はこのへんです。

A Scrum Book: The Spirit of the Game

A Scrum Book: The Spirit of the Game

 

ほかの方のメモ

kobase16.hatenablog.com

 

Jim Coplienさんの研修もご興味ありましたらどうぞ

www.jp.agilergo.com


この記事はRSGT2020のアドベントカレンダーに登録しています。記事の作成にあたっては、藤村新さん、蜂須賀大貴さん、守田憲司さん、前田浩邦さんのご意見をいただきました。資料写真はJim Coplien さん、集合写真はTACOのYury Zaryaninovさんに撮影いただいたものを花井宏行さんからご提供いただきました。ありがとうございます。

adventar.org

 

木構造本醸造と見間違えたのでもう飲みに行ってきます。

*1:木構造。閉路のない有向グラフ