めっちゃ美しいけど危険な刃: Scrum@Scaleガイドを読んで
はじめに
最近は、アジャイルに造詣が深い若手2人( @tyantya41717651さん、@zakky_devさん )とアジャイルのトピックについて定期的にディスカッションさせていただいています。 そしてそれが個人的には楽しく、かつめちゃめちゃ為になる時間になっています。
先日、大規模アジャイル手法の一つであるScrum@Scaleについてディスカッションしたので、内容を残したいと思い、今回ブログにすることにしました。
今回Scrum@Scaleについて詳しく説明しないため、知りたい方はガイドか素晴らしい要約スライドをお読みください。*1
エグゼクティブ・アクション・チーム(EAT)について
エグゼクティブ・アクション・チーム(以下EAT)とは、アジャイル組織全体のスクラムマスターに例えられる存在です。具体的にはアジャイル組織移行にあたってのリファレンスモデルとなるチームを作成したり、組織や複数チーム間の問題を文字通り食べてしまう(EAT)ことが役割です。リファレンスモデルの維持や組織的な問題解決にはある程度の権限が必要なため、実質的には経営層中心で構成されるチームと考えられます。面白いのはEATは組織変容バックログを実現するためのスクラムチームとしてスクラムで運用されることです。
これは、エグゼクティブ・アクション・チーム(EAT)による作成が最善の達成方法である。
エグゼクティブ・アクション・チーム(EAT)は、変革戦略の策定と実行の責務があるためだ。
EATは、リファレンスモデルの存続を保証するために政治的、財政的に権限を与えられた個々人で構成されなければならない。チームのこのセットは、アジリティを阻害する組織的な問題を通じて働き、組織横断的なスクラムをスケールするためのパターンとして使われうるリファレンスモデルを作成する。
ディスカッションでの意見
- マネージャーや経営層の役割はスクラムガイドで規程されていないため、アジャイルをスケール化する際にこうしたチームが必要なのでは?
- (むしろスクラムが現実の組織を無視したイデア界の純粋概念ともいえる)
- 「必要最低限の官僚制」(Minimum Viable Bureaucracy)というコンセプトは面白い
- 名前的にトップダウンぽくて、むやみに反発を呼びそうな感
- 組織のスクラムの品質、アジリティの最終責任チームという印象
- 要するにマネージャー陣の集まりか?
- 実際の大手企業の実態に即しているのかも
- エグゼクティブという名前は、経営陣が喜んで入るための工夫では?
- (EAT頼りになり)EAT以下のチームの自律性や改善意欲の低下を招いてしまわないかが心配
HowとWhatの責任やプロセスの明確化について
スクラムでは、"How"と"What"の責任の分離に注意する必要がある。
Scrum@Scaleでも同様に、チームの最適な生産性を達成を邪魔する、無駄な
組織上の衝突を取り除くために、権限と責務を明確に理解し、注意する必要がある。
Scrum@Scaleでは、これまでスクラムガイドで詳細化されてこなかったプロダクトオーナーがビジョンからプロダクトバックログを作成し順位付けするプロセスがプロダクトオーナーサイクルとして明確化されている。それを担うのはアジャイル組織全体のプロダクトオーナーに例えられるメタスクラムというチームです。メタスクラムもEATと同じく一つのスクラムチームとしてスクラムで運用されます。
プロダクトオーナーサイクル
ディスカッションでの意見
個人的にはScrum@Scaleの最大の特徴はこのHowとWhatの責任やプロセスの分離にあると感じました。ここが一番ディスカッションでも盛り上がった部分です。
- 企画(What)と開発(How)を分離すると縦割り意識や受け渡しのムダが促進され、組織全体のパフォーマンスがかえって落ちるのでは?
- いきなり最初から全員アジャイルを導入してもうまくいかない、小さい型をちゃんと入れて、徐々に生まれていく。組織レベルでは最初の1歩として分離があるのは悪くないのでは?(もちろん成長していくにつれ境界がなくなるのは望ましい)
- 分離が問題と言っているが、そもそもスクラムも最初から分離している
- ただその分離を拡大してしまっていることが問題では
- 理想は全社員に経営状況が開示されていて、全員野球で仕事すること
- プロダクトオーナーサイクルもスクラムマスターサイクルもそれぞれのスキルが高度化しているため、全員野球で一緒に仕事することはできるのか? デザイナーが開発者の仕事できるのか?(逆も然り)
- そのあたりはデュアルトラックアジャイルで補完されている?(よくわからない)
フラクタル構造の美しさと、スケールフリーネットワークについて
Scrum@Scaleで印象的なのは、その構造の美しさとその構造からもたらされるスケールフリーネットワークです。
構造の美しさとは、「一部が全体と自己相似な構造を持っている」フラクタル構造があちこち見られること。たとえば、Scale@Scaleは全体としてスクラムチームとして機能しますが、その各構成チーム、たとえばEATやメタスクラムもスクラムチームです。そしてEATやスクラムオブスクラムを結節点にして、理論上は無限に各チームを追加することができます。このようにソフトウェアアーキテクチャのように組織を捉え、チームをコンポーネントのように追加していく発想は自分にはとても新鮮に映りました。
全体的な意見
その他、Scrum@Scale全体に対する意見です。
個人的には、「書かなくとも大企業ってこんな感じじゃねーの」には少し笑ってしまいました。
- 「スクラムガイドでは最適なチームサイズを3人から9人と定義しているが、ハーバードの調査では最適なチームサイズは4.6人であると判断されている。」とあって共感
- 小さいセットチームから作るって考え方には共感。いきなり複数チームは経験上うまくいかない気がする
- 書かなくとも大企業ってこんな感じじゃねーの
- EATは経営層がスクラムを理解するのに良い仕組みでは?
- 導入者の力量が問われる
- 大規模アジャイルの導入の足掛かりとして導入するのは良いが、ガイドをそのまま導入すると末端のチームは単なる部品となるリスクが高い
- 構造を変えるだけでは、現実のふるまいは変わらない
- LeSSでいうオーバーレトロスペクティブのような横断的なレトロスペクティブはあるのか?
- 企画と開発が分離されて縦割り組織になったり、フラクタル組織がピラミッド組織に堕落するリスクの指摘やリスクを軽減するプラクティスが見当たらない
- 導入はScrum.Incのコンサルティングが前提になっているのかな
さいごに、自分の印象
今回、Scrum@Scaleガイドを読んで、Scrum@Scaleへの全体的な印象は、"めっちゃ美しいけど危険な刃"です。
フラクタル構造やスケールフリーネットワーク性などの数学的な構造はとても美しくエンジニアとしてもとても惹かれるものがありますが、その分刃がめちゃめちゃ鋭く、素人が使うとあっという間に組織を傷だらけにさせてしまう印象です。現時点では、組織単独で導入するのは難しく、Scrum.Incなどの支援が必須と感じました。ただし、組織変革やプロダクトオーナーの仕事をスクラムで運用するというアイディアは使えるかも。日本での導入事例があまりないため、海外での導入事例も是非知りたいと思いました!
*1:文中の図やテキストは全てScrum@Scaleガイドからの引用です