『スクラムの拡張による組織づくり』を読んで、組織づくりを考えてみる
@daiksyさんから、『スクラムの拡張による組織づくり』をご恵贈いただいたので、読んで刺さったところや思ったことをつらつらと書いていく。
どんな人におすすめか
本書籍は大規模スクラムの一つであるScrum@Scaleを運用するときに、どういうことに気をつけるべきなのかを教えてくれる本である。こうやって書くと、Scrum@Scaleを導入している企業の方にしか意味が無いように思われるかもしれないが、そうではない。私は過去に大規模スクラムの一つであるLeSS(Large-Scale Scrum)の実践研修を受けたり、実際にLeSSに近い開発プロセスを導入したことがある。もし本書籍が当時の開発プロセスを検討しているときにあったとしたら、多いに参考になっただろう。
また、すでにLeSSやSAFeなど別の手法を取り入れている方も、他の手法の良いところを知るのは開発プロセスを良くする助けになる。これってなんでLeSSには無いんだろうとか、SAFeだとこの会議体でやっているかも、とか考えていくのは、今やっている手法が違ったとしても理解が深まるだろう。
さらに、まだ大規模スクラムに移行するかはわからないが、もし大規模になったらどんなアクティビティをやらなければいけないのだろうか、と知っておくのは開発の今後を考える意味で意味があるだろう。Scrum@Scaleに限った話ではないが、大規模スクラムは組織における情報共有の仕組みが整備されている。本書籍を読むことにより、今が1つのスクラムチームであっても、スクラムを導入していないチームとの議論の仕組み(SDS)や、経営層との議論の仕組み(EATやEMS)は参考になるかもしれない。
まとめると本書籍の読者となりえるのは以下の通りである。
ここで、導入・検討している方としていて、スクラムマスターやプロダクトオーナー、開発メンバーなどと限定していない。これはスクラムに携わるメンバー全員が知っておいた方が良いことだからである。
スクラムをスケールしたい人ってそもそもいる？
私がLeSSっぽい開発プロセスを導入したときもそうだったが、スクラムマスターとしてスクラムをやるときって、開発チームが既にあるところからスタートするケースが多いんじゃないかなーと思う。しかも、開発メンバーが数人という所謂2pizzaルールに当てはまるような規模ではなく、スクラムの限界人数とされている9人とか、15人とか、20人とか・・・下手したらもっと大きな規模のチームとか。そういうちょっと開発プロセスの難易度が上がってきた段階で、スクラムマスターがやってくるケースが実は多いんじゃないかなと思ったりする。
スクラムマスターやっている人だったらわかると思うが、人数が多いというだけでチームの成功難易度上がる。だから、人なんて増やしたくないし、ましてチームだって増やしたくない。そんなことは百も承知な上で、大規模スクラムの導入を検討せざるを得ない状況に追い込まれているのでは、と思ったりする。「大規模スクラムの導入の前にまず考えることがあるだろう」という意見はご尤もだが、そんなこと言ってられない事情が現場のスクラムマスターにはあるんじゃないかな。
私がLeSSの実践者研修を受けたとき、救いの光だったことを良く覚えてる。大規模スクラムなんかやるんじゃねえ、という意見をもらいながらも、なんとかチームを良くするために、と考えに考えてチームを分割して、会議体を自分なりに設計してやっていた。チームを分割するだけでは深いドメイン知識を持っている方の知見が活かせないから、両方のチームを渡り歩く仕組みも作った。LeSSがその考えに考え抜いたやり方とほぼ同じだったと知ったときはものすごく嬉しかったのは、なんか自分が信じてやってきた道が肯定されたような気がしたからだろう。
本書籍の冒頭で、「スクラムをスケーリングしたいと考えている組織は、すでにある程度の規模の開発組織が存在している場合が多いのではないでしょうか」という記述がまさにあって、この言葉に救われる方はたくさんいるんじゃないかな。別にやりたくてやっているんじゃないんだよ、と。
まあ、でもスケーリングは難易度高いから(本書籍でも認めている)、開発プロセスがうまく回らなくなってきたと気がつく前に、早めにスクラムマスターを入れてくれ、とは切に思う・・・。
大規模スクラムはエグゼクティブの協力必須
本書籍にも書いてあるが、スクラムチームを1つ導入するぐらいだったら現場の判断でやっても良いけれど、大規模スクラムでは流石に現場だけでいろいろ取り決めるのは難しい。二桁人数に影響を与えることになるのは、組織として無視できないレベルのことになってくるはず。どんなことをやろうとしていて、どんな成果をあげようと思っているか、その報告フローをどうするか、について上位のマネージャーと合意を取るのは、絶対最初にやっておいた方が良い。上位のマネージャーを説得できないレベルのことしか言えないのだったら、多分一度冷静になって考え直した方が良い。
Scrum@ScaleにはEATやEMSというリーダーシップグループが定義されていて、そこで組織的な協力を得られやすくなっているのはとても良いやり方だと感じた。組織の隅々まで大規模スクラムやるのは難易度高いと思うので、多分最初はエグゼクティブ層やその他マネージャーたちは最初大規模スクラム外にいると考えると、EATとかEMSは実際にはマネジメント相談会議とかって名前になるとは思う。名前がなんであれ、スクラム外の人たちと接点を持つ場をフレームワークの中で定義されているのはまさに組織運用上必要となることで、良く考えられていると思う。単一のスクラムはこの点はサポートされていないから、悩む人も多いんじゃないかなあ。
組織構造を変えやすくするために非公式なチームを利用する
人がチームを異動すると様々なコストがかかるので、Scrum@ScaleではSoSやSoSoSといった単位でチームを固定化し、その中でチームの組み合わせを自由に変えられるとしている。私はこの仕組みはとても良いと思っていて、組織が動きやすくなるためには、うまいこと非公式なチーム(バーチャルチーム)を活用することがポイントだと思っている。組織の公式として扱うチームはそのチームのユニーク性が組織の中で大事で、同じような機能を持ったチームが何個も存在すると組織上、何をやっているチームなのか、と混乱を招きやすいです。スケールされた開発チーム同士は同じような機能を持っていると言えるので、あえてそれを取りまとめた群(SoS or SoSoS)を公式なチームとするのはとてもわかりやすくなるし、やることが少し変わったときもそれに合わせてスケールされたチームを作りやすくなる。
本書籍でも一貫しているのが、コミュニケーションコストをいかに下げられるかということで、チームを増やすことによってチーム間のコミュニケーションが全社的に増えていくのは避けなければいけない事態だ。ある程度ざっくり公式のチームを作る、その公式のチームの中は非公式なチームが何個もあって、非公式なチームと外の公式なチームは基本的に直接会話しない、というのが組織設計上大事だなと思う。
Scrum@Scaleというか組織づくりを学べた
これは自分の置かれている立場だからかもしれないが、もはやScrum@Scaleというのは大規模な組織づくりの一つの実装として捉えていて、その裏にある、どのようにコミュニケーションを取るのが大きな組織にとって最適なのか、に注目して読んだ。
冒頭にどんな人におすすめなのかと書いたが、そこにもう一つ付け加えるなら、組織全体を俯瞰して見る立場の方、というのも追加しておきたい。Scrum@Scaleという題材を元に、いろいろとアイデアが浮かんでくるに違いない。
