今はまあまあ人数の多いチームで働いていて、仮にこのチーム全体でスクラムをやっていくとしたらどういう形になるんだろうと思って勉強することにした。
大規模スクラムフレームワークは色々あるけど、CSMの講師や周囲の人などの雰囲気からLeSSが良さそうと深く考えずに判断した。このあたりはちゃんと比較しようと思うと一通りのフレームワークについて学ぶ必要が出てきて学習コストが大きくなりすぎるので、アジャイルコーチで飯を食っていくわけでもなければまあこれくらいの判断で良いんじゃないかと思っている。
ただこの電子書籍の残念なところとして、固定レイアウトなのでめちゃくちゃ読みにくいしハイライトもできないというところがある。また、個人的にはあまり構成がうまくまとまっているとも思えなかった。ので、全体を通したぼんやりとした感想しか今は持ってない。
本の末尾にLeSSのルールや索引などがまとまっているページがあるので、トップダウン・アプローチで理解したいならそちらから読んでも良いかもと思った。 内容としては、LeSSはこれこれこういう理由でこうしてるんです、ってことが延々と書かれているような印象で「LeSSはスクラムです」と書かれていた通りスクラムについてある程度知っていたらそんなに驚くような内容でも無かったように思う。
そして文量がまあまあ多いので自分の記憶力では暗記できるわけもなく、実践するとしたら下記のようなウェブサイトなども見ながら実践→困りごとをキャッチアップ→当該の章を読んで改善みたいな流れになるんだろうなあ、と思う。
チームの分け方について
スクラムガイドではチームの人数は3～9人が推奨されている。この数字は、有名な2枚のピザルールとも整合的だと思う。このような人数制限は取引コスト(=通信不確実性)を削減するためのものだと自分は理解している。 それを実現するために、ハイレベルな人材しか雇うべきでないし、チームは固定的にして学習を促進・コンテキストを深めてスピードを出していきましょうということになってるように思う。
しかし現実の名だたる企業の様子を見ていると、どうも少人数で大成功している企業というのはほとんど無いように感じる。GAFAとかよく言うけど、彼らだって超優秀な人材をかなりの人数雇用している(チームが固定的かどうかはよく知らない)。まあ彼らが教科書的なアジャイル開発をやっているわけではないという話もありそうだけど、そういう現実を踏まえると何らかの形でスケールさせる必要はどこかで出てくるのだろうな、と思う。
どのあたりからスケールさせていく必要が出てくるのか？というのは、自分はわからない。けど、新卒採用をしていたりチームの異動が多いような環境下ではチームが処理できる情報量の上限が低くなるので、そうでない環境と比較して(同程度のビジネスをしてるなら)かなり早い段階でスケールが求められるのではないか。つまり、スケールを実現するための組織デザインや開発プロセスの重要性が相対的に高まるのだと思う。
スケールの仕方として、今回はLeSSを学んだ。 LeSSのような大規模スクラムは当然もっと多くの人数が関わることになる。ので、増大を避けられない取引コストとアウトカムの最大化のバランスに主な関心があるはず。
一方ここで思い浮かべるのは、逆コンウェイ戦略やマイクロサービス化といったキーワード。これらのキーワードも、取引コストとアウトカムの最大化のバランスに主な関心があるものと思っている。
このあたりの話題は、LeSSのこの図っぽいなあと思う。
LeSSではフィーチャーチームが推奨されていて、コンポーネントチームは推奨されていない。なぜなら、アウトカムを生み出すための取引コストが増大するから。
じゃあ逆コンウェイ戦略やマイクロサービス化が常に間違った選択なのかというと、当然そうでもないと思う。 このあたりは最近ちょうど見かけた
認知能力の問題、事業ケイパビリティの問題が起こるコンテクスト境界は0.1M-1Mslocにあって、最近作られるマイクロなサービスは10K-100Kslocくらいのものが多いため、このような齟齬が起こる。 / “マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏” https://t.co/XLc33awaeq
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2020年10月22日
たとえば、数人しかいないプロジェクトで1-10kslocのマイクロサービスをベースにした設計で、entity serviceのアンチパターンにハマってしまって、結局コアドメインが何処にも表現されていないから、スケールしづらい・リファクタリングしづらいみたいなのわりとよく見る。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2020年10月23日
あたりが一つの目安になるんだろうなあ、と思われる(うまくマイクロサービス化できたら、例えばAWSのマネージドサービスを使っている組織のように恩恵は大きそう)。
このあたりの話題はかなり直接的に組織に根ざした話題なので一概にこうするべきであると言い切れるものではなさそうなので、こうした基本的なキーワードを把握した上で各自何が最適か考え・実施して・ふりかえっていくことになるんだろうなあ。
