会の概要
以下、イベントページから引用です。
身に付けていく中で、実績を築いてこられました。
しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。
Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。今回の第32回目では、2023年8月26日発売の『スクラムの拡張による組織づくり』著者の粕谷 大輔氏をお招きし、お話を伺います。
スクラムは，今や数多くの現場で活用されています。しかし，スクラムは少人数での開発を想定しており，大規模開発で実践する際にさまざまな問題が発生します。そこで，大規模開発でスクラムを行うための手法がいくつか提唱されています。本書はその中の一つであるScrum@Scaleを解説する書籍です。
今回は著者である粕谷 大輔氏に、Scrum@Scaleをどのように日々の開発に取り入れるのか，導入事例を交えながらお話しいただきます。
会の様子
基調講演〜『スクラムの拡張による組織づくり』でScrum@Scaleに触れてみる〜
最初は本の著者のだいくしーさんから基調講演がありました。
今回の講演では4章と7章を中心に解説がありました。
第1章
大規模スクラムに限らず、そもそも大規模なものって扱うのが難しいよね、という話が書いてあるということでした。
第2章
スクラムのおさらいであり、スクラムを知っている人は読み飛ばしてもOKということです。
とはいえ、スクラムガイドの変遷をたどりながらの考察など、スクラムを知っている人視点での見どころもあるということでした。
第3章
今回一つの核になっている章ということです。
架空のチームを見学することで、理屈を説明する前に活動の理解を深める目的の章になっているということでした。
第4章
まず、スクラムマスターサイクルなど、Scrum@Scaleの説明が書いてあるということです。他の書籍と比べ、プロダクトオーナーに関する話が詳しく書いてある点がだいくしーさん的には気に入っているということでした。
次に、チームプロセスについて書かれているということでした。スクラムに詳しい人が見ると、スクラムをちゃんとやろうという話に移るかもしれないということですが、大規模スクラムの本ということで、スクラムチームのスケールに関するフラクタル構造やSoS->SoSoS->SoSoSoS、EAT/EMSの話、プロダクトオーナーのスケール*1に関する話なども記載されているということです。
第5章
第4章で紹介したEAT/EMS/チームプロセスを除いた細かい活動に関する話がされているということでした。
第6章
実際に現場に導入するにあたってどのような順序で導入していくと良いかの紹介が書かれているということでした。
第7章
だいくしーさんが実際に今の会社で運用している様子を具体的に紹介している章になっているということでした。
最初に、アーキテクチャ刷新PJでバックログには技術的負債関連の話が多いという前提の紹介がありました。そのため、ユーザーインタビューなどの仕事はそこまで入ってこないということです。
次に、現在の体制として、一週間の具体的なスケジュールやチーム体制に関する話があるということです。
最後に、システム特性のコンテキストに伴うチームの推移が本の中では紹介されているというお話がありました。
Q&A
発表後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
大規模スクラムの導入を妨げるもっとも大きな原因は？
ボトムアップな導入ができないため、トップダウン的なアプローチが必要になってくるのは難しいところかな、と思っているそうです。
なぜ小規模開発に適したスクラムを大規模にやる必要があるのか？
だいくしーさん自身も小規模なほうがいいのは間違いないと思っている。とはいえ、組織が大きくなっていくときに小規模なチームで完結するのが難しくなることはあると思っていて、そうしたときには何かしら小規模スクラム以外のフレームワークを用いる必要が出てくる。
この際の選択肢の一つが大規模スクラムだと思っている。
利害が異なるチームとの協働に関する取り組みを知りたい
プロダクトゴールがはっきりとしていれば利害が一致するとは思うが、SoSで構造を整理するのは一つの方法。
大規模スクラムが他の大規模開発手法と比べて優れているポイントは？
優れいている/優れていないはないと思うので、自分たちのプロダクトや特性にマッチしているかが重要だと思う。
プロダクトオーナーがスケールするところがポイントなので、会社全体としては一つのプロダクトがあるけどちょっとずつ方向性が変わってくる場合などは大規模スクラムが適している可能性は高いと思っている。
EATやEMSが「偉い」からお伺いを立てようみたいなコミュニケーションにならないコツはあるか？
エグゼクティブが意思決定に中心的に関わるのは間違いないが、ふりかえりをしながら共通意識を形成していくのが一つのポイントだと思っている。
機能が密結合しているプロダクトにとってはSoSは相性が悪いのか？
考え方次第だが、機能の結合を一つのSoSに盛り込んでみて運用するのはある。
ドキュメントのメンテナンスコストを低減する工夫はあるか？
意思決定の背景に関わる話はドキュメントに残すというのが多い。Whyを大切にしている。
一つのプロダクトを10チームで作るという場合はS@Sはふさわしくないのか？
チームの中に大きく固定した役割がないというならLeSSのほうが良いと思う。マイクロサービス化されているというならS@Sも選択肢の一つになると思う。
LeSSに比べたS@Sの利点は？
プロダクトオーナーが複数いて嬉しいかどうか？がポイントになると思う。
大規模スクラムにおけるプロダクトオーナーの役割は？
スクラムのプロダクトオーナーと一緒
チーフプロダクトオーナーのスキルは何が必要か？
これもスクラムのプロダクトオーナーと一緒。見ている範囲が広くなり、分割に頭を使うくらい。
プロダクトオーナー育成のための書籍はあるか？
絶版だが「スクラムを活用したアジャイルなプロダクト管理」がおすすめ。
要件が爆発したときにどのような取り組みをするか？
少ない労力でより価値の高い仕事をするのが仕事なので、仕事量が爆発していたらそれはPOが責務を全うしていない可能性がある。
同期のためプロダクトバックログの運用コストは高くなると思うが、どのように対処するのか？
コストが高くなるのはそのとおりなので、リファインメントが重要になってくると思っている。
会全体を通した感想
本もすでに読ませてもらったのですが、完全なScrum@Scaleではないにしろ、自分たちの会社でもScrum@Scaleに近い取り組みをしていることもあって、共通点と相違点を見ながら楽しく読ませてもらいました。
書籍の構成は非常に工夫されているなあと思いながら読んでいたのですが、発表の中で構成に思慮した様子が幾度となく伺えて、やはり色々と工夫を凝らしていたんだなあというのが感じられたのもよかったです。
*1:チーフプロダクトオーナーの役割に関する話など
