かつて同僚だった粕谷大輔さんの著書「スクラムの拡張による組織づくり（技術評論社）」を読んでみた。エンジニアではない僕にとっては、組織論としての位置づけの方が大きかったが、スクラムやアジャイル開発のフレームワークにも興味があるので、論点はそれなりに理解できたと思う。
スクラムの拡張による組織づくり ――複数のスクラムチームをScrum@Scaleで運用する：書籍案内｜技術評論社 (gihyo.jp)
＊＊＊
スクラムは基本的に自主性、自治性を持ったチームがスクラムマスター（SM）の仕切りで開発を進めるスタイル。SMは指示をする上司ではなく、ファシリテートするという感覚の方が近い。一方、商品性に責任を持つのはプロダクトオーナー（PO）で、こちらは逆に細かい開発手法にはタッチしないし、エンジニアリングに精通しているわけではない。事業と技術という2つの視点を回す上では、顧客（ユーザー）視点に立って価値を創出することが重要だ。
その意味では、スクラムチームのメンバーはもちろん、外部から応援が入る際にはその応援者もゴールをしっかり共有しておくことが必要だろう。メンバー間では「伝えること」もポイントになり、創発的な対話や議論に向かわせるような進捗報告をすべきだと感じた。これは、形骸化しがちな「1on1」においても同様だろう。
「メンバーの負荷状況を把握すること」はSMの主要な役割だからこそ、本書で示されいるスクラムチームつぃて妥当な規模は、この負荷把握が可能な人数なのだと理解した。かつて勤務していた会社では「チームが10～12名になるように管理者を置く」というガイドラインがあったが、スクラムの場合はこれでも多すぎる。
一番悩ましいのは、SMとPOの関係だ。お互いが創発的な対話や議論をすることは有用ではあるが、SMはWhat、POはHowという本来は守備範囲の埒外にあることに対してどこまで意見を出してよいかの塩梅が難しそうに感じた。これは、実際に現場の部門長からも聞かれる声でもある。エンジニアではないPOのスクラムへの理解不足からPOサイクルが形骸化すると、結果的に技術者目線で突っ走ってしまうリスクもありそうだ。
「守破離」もキーワードのひとつとして提示されるが、体制が不十分な状態では「守」ができていないのに「離」に進んでしまうか、「破」に行けなくて形式的に「守」に留まり続けることがありそうだ。そのためにも、初期のスクラムチームは「基本を守るための道場」かもしれない。だからこそ、マスターにとってのパダワンは、多すぎてはいけないのだろう。
＊＊＊
クラフトビールのエピソードなど、粕谷さんらしさも散りばめられていて、懐かしさもあった。上記のような感想をメッセンジャーで送ったところ、自分も同じようなことで悩むという返信をいただいた。ちなみに彼は、Xでも @daiksy として様々な情報発信をされていて、登山やマーベルなど興味の幅が広いので刺激を受けている。
