アジャイルコーチ同士のスクラムガイド雑談会2020

2020年11月18日（水）に、スクラムガイドの最新版がリリースされました。

それを受けまして、アジャイルコーチの中村 洋さんからお声がけいただき、11月23日（月）朝に同ガイドの内容に関する雑談（1 on 1）をさせていただきました。

1時間半を超える熱のこもった内容になりましたので、せっかくですので内容を備忘録として書き出してみました。同ガイドの読み方・解釈方法の1意見として読んでいただければ幸いです。

ちなみに、中村さんは日本語版を、私は英語版を読んだ上での雑談です。その違いも含めて楽しんでいただければ〜

1. スクラムガイドの目的

スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。
（日本語版 1ページ）

• （中村）この「問題が隠蔽され」という点は、スクラムに取り組む理由の一つとして（自分自身がコーチ先のチームなどに）説明することがある。
• （伊藤）この記述を含め、今回のガイドは全体的に透明性・検査・適応とその相関関係とを強調している印象。

2. スクラムの定義

スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
（日本語版 4ページ）

• （中村）スクラムマスターの必要性を明記している点が興味深い。単なる会議のファシリテーターとかではないことを強調する必要が出てきたのかも？
• （伊藤）それは確かにありそう。一方で、各ロールとその相関関係を含め、文字通りここで「スクラムの定義」を簡潔にまとめ、全体の見通しを良くしようという著者の強い意図を感じた。

スクラムフレームワークは意図的に不完全なものであり
（日本語版 4ページ）

• （中村）「不完全」の解釈が分かれそう。自分は、1) プロダクトバックログの書き方や使用ツールといった、実践方法の詳細を明示していないという意味合いと、2) 仮説設定・検証やマーケティングなど、スクラムの「外側」のプロセスを明記していないことと捉えた。
• （伊藤）自分は、「イノベーションのチャンス」と解釈した。スクラムはフレームワークのベースラインだけの定義にとどめているため、実践時は各ドメイン・プロダクトに合わせた肉付けが必要。そこに各実践者の工夫や、スクラム自体を豊かにする余地があるのだと捉えた。

3. スクラムの理論

「リーン思考」の「リーン」は、「ムダを省き」という記述があるので、「リーンスタートアップ」ではなく「リーンソフトウェア開発」を指すだろう。

4. スクラムの価値基準

スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。
（日本語版 5ページ）

• （中村）日本だと、（確約・集中・公開・尊敬・勇気といった）価値基準及びそれらの学習・探求の必要性をあまり明言していない印象。
• （伊藤）確かに日本では、これらを明示的に話していないかも。そういえば、Kubernetes Podcast from Googleなどを聞いていると、海外の団体・コミュニティなどでは、これらの重要性を明言していることが多いかも。
• （中村）日本のSIer所属のアジャイルコーチをみていると、こうした発想自体を持っているのか疑問に思うこともある。
• （伊藤）日本のSIerだと、一定期間過ぎたらチームが解散する「プロジェクト」の思考に馴れていることが多くて、中長期的思考を持ちづらいということはあるかも。

5. スクラムチーム

自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。
（日本語版 6ページ）

自己「組織化」から自己「管理型」に記述が変更されている。意思決定の責務を、（POを含む）スクラムチームとして持つことを明示したのでは？

スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。
（日本語版 6ページ）

• （中村）「すべての活動」とはどこまでを指すのか？例えば「検証」は、リサーチャーが行うプロダクトの仮説設定・検証を指すのか？
• （伊藤）仮説設定・検証も含めて「すべて」ではないか？ちなみに（会社の）自分のチームでは、大変ではあるがこれらをすべてやっている。
• （中村）「責任を持つ」の記述が重要。他チームなどに助けを求めてでも「活動に責任を持つ」という意味であって、自分たちが実施する責任（＝自力でやらなければならない）という意味ではないと思う。
• （伊藤）ですね〜

5.1. 開発者

完成の定義を忠実に守ることにより品質を作り込む。
（日本語版 6ページ）

「完成の定義」という言葉がここに出てくるようになったことは、大きな変化だと思う。プロダクトの「作り込み」を強調する意図があるのかも。
一方で「品質の作り込み」は、スクラムガイドだけでは情報不足。ソフトウェア開発ならば、XP・CI/CD・DevOpsなどを取り入れる必要がある。

5.2. プロダクトオーナー

プロダクトゴールを策定し、明示的に伝える。
（日本語版 7ページ）

• （中村）「プロダクトゴール」を明記するようになったのは、スプリントだけを回して結果プロダクトのゴールを見失いがちになるスクラムチームが多かったからかも？
• （伊藤）それはありそう。書籍『A Scrum Book』でも、プロダクトバックログのインプットとしてのVisionやProduct Roadmapに多くの記述を割いていた。

A Scrum Book: The Spirit of the Game

5.3. スクラムマスター

スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。
（日本語版 7ページ）

• （中村）「組織へのリーダーシップ」を明示したことは、大きな変化だと思う。チーム内だけに留まって、本来の価値を発揮していないスクラムマスターが多かったのでは？
• （伊藤）それはありそう。私たちはJames Coplienさんの認定スクラムマスター研修を一緒に受講して、Red Pill、既存の枠組みを外れてでも貢献する重要性を叩き込まれたので、「組織へのリーダーシップ」が当たり前になっている。それを全員が持っているわけではないので、明示には意味があると思う。

6. スクラムイベント

6.1. スプリント

スプリントゴールの達成を危険にさらすような変更はしない。
（日本語版 8ページ）

• （中村）「危険にさらすような変更」には、どのようなものがあるか？
• （伊藤）（考慮不足の）APIの破壊的変更など、スプリント内では対応しきれないようなうっかり追加作業。CI/CDをやっていると予防はできる。やはりスクラムガイドだけでは不足かも？

すでに発生したことだけが、将来を見据えた意思決定に使用できる。
（日本語版 9ページ）

• （中村）一連の文章で言いたいことはなんだろうか？（日本語の文章がやや複雑）
• （伊藤）メトリクスなどの「過去の」実績情報をベースに、経験主義的に行動しましょうという程度の意味では？（英語で読んだから詰まらなかった？）

6.2. スプリントプランニング

キャパシティ
（日本語版 10ページ）

• （中村）「キャパシティ」は、時間・日数の意味か？
• （伊藤）Capability、学習の要素なども含む、広い意味での「能力」の意味合いではないか？自分がコーチングをする場合は、これを伸ばすタスクを意図的に追加したりしている。

6.3. デイリースクラム

プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。
（日本語版 10ページ）

• （中村）これは、（本来は禁止されているはずの）ロールの兼任をしろという意味なのか？
• （伊藤）帽子の被り直し程度の意味では？デイリースクラムの参加者を開発者に限定している旨の、前段の記述とも符合する。

6.4. スプリントレトロスペクティブ

スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。
（日本語版 11ページ）

「効果」は、プロダクトとプロセスの両方を指す。

スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。
（日本語版 11ページ）

「仮説」は、プロダクトとプロセスの両方を指す。

スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。
（日本語版 11ページ）

• （中村）「最も」と明記しているのは、改善項目をたくさん実施しても無駄が多いなどの点を指摘している？
• （伊藤）おそらくそう。TOC（Theory of Constraints、制約理論）の、「多くの問題は、少数の原因による」という考え方と同じではないか？

7. スクラムの作成物

プロダクトゴールは、スクラムチームの⻑期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成(または放棄)しなければならない。
（日本語版 12ページ）

• （伊藤）「達成または放棄」とは、プロダクトのPivot（方針変換）のことを指すのではないか？

スプリントゴールはスプリントの唯一の目的である。
（日本語版 12ページ）

• （中村）スプリントゴールは、1つにした方が良いでは？
• （伊藤）同意。もし複数必要になる場合は、ゴール間の優先度設定が重要。

7.1. インクリメント

また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。
（日本語版 13ページ）

• （中村）「徹底的に」という言葉が興味深い。リグレッションテストの重要性と、技術的プラクティスを軽視する近年の風潮への警鐘の意味合いがあるのでは？
• （伊藤）同意。技術的プラクティスがあって初めて、スクラムガイドが示す「徹底的な検証」ができる。

8. 全体

自分たちのような経験を積んだ実践者にとっては読みやすくなった一方で、初学者にとっては曖昧すぎて読みづらい内容になっているかも？

• 経験のあるコーチが、初学者とペアないしモブを組んで教えることを「前提」としないと辛いかも？
• 一方で、コーチの知識・経験を活かして初学者を導くスキームが想定されているかも
• 聖書と牧師さんの関係が似ているかも
  
  

最後に

同じアジャイル実践者でも、積んできた経験の差でこれだけ解釈が割れるのかという驚きと、その解釈の差を共有し合うことでさらに理解を深められる面白さの両方を体感できました。 このような雑談は、是非皆さんにもお勧めしたいです。

機会をくださった中村さんに感謝です！