以前対談させていただいただいくしーさんが本を出されたということで、対談内容にも通じる組織の話ということもありこれは読まねば！ と思い買って読んでみました。*1
結果、とてもよかったです。
最近の個人的な関心事にも通じる部分が大きく、多くのヒントが得られ、また思考を刺激する内容でした。
複数チームでうまく価値を届ける
僕がいる組織ではスクラムを取り入れていませんし、スクラムやScrum@Scaleを取り入れる予定もありません。*2
それでも、複数のB2B SaaSを展開するアジャイルなプロダクトチームとして、複数チームでうまく価値を届けていく必要はあります。
単一のプロダクトを複数チームで開発するに際して、どのようにチームが分かれているとよいのか。チーム間の連携についてはどう考えるとよいのか。その濃淡は。また、（スクラムでいうところの）プロダクトオーナー側はどうなっているとよいのか。さらには、複数プロダクトの間での関係性はどうあるべきか。
最近は、一つのチームの開発者として働きながらも、より大きなチームとしてもより大きな価値を届けていきたいので、そういったことにも日々頭を悩ませています。
Scrum@Scaleではどうするのか
そういったさまざまな関心・課題感に対して、「Scrum@Scaleではどう考え、どう取り組むのか」という一つのリファレンスが得られるという点で、僕にとってとても有用な本でした。
Scrum@Scaleには12の「コンポーネント」が定義されているのですが、いずれもなんらかのかたちで（Scrum@Scaleではないとしても）組織に必ず必要になる機能なんですよね。
特に、「スクラムマスターサイクル」と「プロダクトオーナーサイクル」という両輪の枠組みで、開発チーム（+スクラムマスター）側とプロダクトオーナー側のそれぞれが複数チームで連携していく、という整理の仕方は、確かに複数チームでプロダクトを作っていくと自然とそうなるよな、と感じられるものです。*3
Scrum@Scale、そしてその解説書であるこの本の内容は、その自然をいかに構造的にサポートしていくか、という取り組みの一つの解と言えるでしょう。
複数チームで価値を届けていく組織に所属しているなら（かつ、そのありようをよりよくしていきたいと思っているなら）、仮にスクラムやScrum@Scaleに取り組んでいない・取り組む予定がないとしても、知っておいて損のない内容だと思います。
また、本の構成もとてもよく考えられていて読みやすく、読みながら段階的に理解や思考を深めていくことができました。
自分のチームのことを考えるヒントにする
この本を読む中で、僕はたとえば以下のようなことを考えました。
- 開発チーム間の連携と、プロダクトオーナー間の連携が別れているのは、確かにスケールしやすい構造だよなとは思う。でも一方で、この構造だと開発チームがフィーチャーファクトリーに矮小化されてしまいやすくないだろうか？
- 同じScrum of Scrumsに含めるのは、共通の関心事を扱っているチーム。だとすれば、関心事を切り離すことで強く連携せず独立して動けるようにするという方向性も重要だよなあ（と改めて認識）
- 「毎日45分で問題が解決する」構造は美しいし、本当に経営レベルの課題まで1日単位で解決できるなら最強すぎるな
- 一方で、強力ゆえに、いわゆる「すぐ話しに行けばいいのに、Daily Scrum待っちゃう問題」を助長しないかというところが気になるな
- 自分の組織全体では、明確な構造をトップダウンには定めず*4、コミュニケーションの価値を基礎として、全体が全体と自由に連携し合うことをむしろ推奨している。とはいえ、n対nの関係性を維持し続けることにさすがに限界も感じられる中で、意図的になんらかの構造を入れることでより有効なコミュニケーションを促進できる可能性があるかもしれないな
- 一方で自分がいる事業では、事業内は比較的密結合な状態が続いてきたところを、少しずつ疎結合に近づけてきた。その方向性をさらに推し進めるか、ある点では維持するのか。また、どういう形を目指すのか、Scrum@Scaleのコンポーネントも参考にしながら考えてみるとよさそうだな
これらはいずれも（個人的には）Scrum@Scaleをやろうとか、取り入れようとかいうこととはまったく関係なく、チーム・組織を考えるための良質なヒントを得られたことで思考が刺激され、考え始めることができたことです。
これらの考えはまだまとまっていないのですが、これからも考え続けていくうえで、Scrum@Scaleの考え方や、だいくしーさんが補ってくれたさまざまな解説は間違いなく貴重なリファレンス・補助線になると感じます。
ということで、だいくしーさんとてもよい本をありがとうございます。
そして、僕みたいに複数チームや組織のことを考えていたり、もっとよくしたいと思っている人にはとてもおすすめの本です！
*1:ちなみにそのときの対談記事はこちら: アジャイルリーダーシップとはなにか？どう実践するか？権力ではなく影響力でアジャイルな組織をつくるために【対談】 - Agile Journey
*2:XPをそのままスケールした感じと言えばいいのか……興味がある方はスライド「実践エクストリームプログラミング / Extreme Programming in Practice - Speaker Deck」をご覧いただけるとイメージがわくかもしれません
*3:Scrum@Scaleガイド - Scrum Inc. Japan #TeamworkMakesTheDreamWorkに掲載されている「Scrum@Scaleのコンポーネント」の図を見るとイメージしやすいと思います
*4:チーム全体は複数事業にまたがっているので、事業の区切りは一応あるにはあるが
