Agile Studio プロデューサーの木下です。

2020年11月にスクラムガイドが改訂されました。前回の改訂が2017年だったので3年ぶりの改訂です。

スクラムガイド（日本語版）PDF

スクラムガイドの変更点の詳細については Scrum Inc. Japan のホームページにまとまってます。こちらもあわせてご覧ください。

スクラムガイド2020のアップデートについて

今回の改訂による変更点の多くはスクラムに対しての誤解されやすいポイントをよりクリアに記載したという点にあるのではないでしょうか。したがって、これまでまっとうにスクラムを運用してきた組織やチームは今回の改訂により大きくやり方を変える必要はないのではないかと感じました。

この記事ではスクラムガイドの変更点から見えてきた「スクラムを運用している組織やチームが陥りやすい3つの罠」（以下の3つ）について解説してきたいと思います。

スクラムイベントが形式的、儀式的になってしまっている
プロダクトオーナー vs. 開発チームの構図に陥ってしまっている
スクラムマスターがスクラム警察もしくは雑用係になってしまっている

それぞれについて、スクラムガイドの変更点を解説した後、症状（現象）、処方箋（どのような対策が考えられるか）について紹介していきます。処方箋はあくまでも対策の例ですので、それぞれの組織やチームで議論してもらえると嬉しいです。

1. スクラムイベントが形式的、儀式的になってしまっている

2020年版のスクラムガイドの変更点を見ると「指示的な部分を削除」とあります。実際にデイリースクラムでの典型的な3つの質問やスプリントレビューの進め方に関する記載は削除されています。

症状

デイリースクラムを例に取りあげると、参加者が順番に3つの質問に答えるだけになっているチームがあります。デイリースクラムの目的は状況にあわせた再計画ですから3つの質問に全員が答えただけで終わりではいけません。

スクラムの実践事例もたくさんでてきたこともあり、表面的にスクラムイベントの進め方をなぞるだけというチームも増えているようです。

処方箋

スクラムガイドの表紙には「ゲームのルールブック」と書かれています。スクラムガイドがルールブックなのであれば、それぞれのチームにあわせたプレイブックを作っていくのがよいと思います。ルールブックに書かれている「目的」を踏まえて、具体的にどのように実践していくのかを組織やチームで議論し考えていくプロセスが重要です。

私自身は2005年からエクストリームプログラミングを実践しています。当時は事例もあまりなく、書籍『XPエクストリーム・プログラミング入門』（通称：白本）の初版を参考にしながらのスタートでした。白本を読んだことがある人は分かると思いますが抽象的なことしか書かれておらず、具体的なやり方は手探りで自分たちで試行錯誤しながら決めていきました。

具体的なやり方や事例を教えてもらえば試行錯誤をショートカットできるかもしれませんが表面的になぞっているだけでは目的を見失う危険性があります。あらためてやっていることひとつひとつの目的を考えてみてはいかがでしょうか。

2. プロダクトオーナー vs. 開発チームの構図に陥ってしまっている

2020年版のスクラムガイドではチーム内の分断をなくし「ワンチーム」になることが強調されています。

「開発チーム」という用語をあらため「開発者」とすることによって、スクラムチームの内側に開発チームが存在するというチームの入れ子構造を解消しています。

変更点にある「自己組織化（Self-Organizing）」から「自己管理（Self-Managing）」へというのも重要なポイントです。自己組織化と自己管理は似たような言葉ですが、注目すべきは「開発チームの自己組織化」から「スクラムチームの自己管理」へと主体がスクラムチームに変わっている点です。「何を（What）」やるかも含めてスクラムチーム全体で考えていきます。

なお、自己管理（Self-Management）と自己組織化（Self-Organization）については以前から議論があったようです。

The Difference between Self-Management and Self-Organization - BPI - The destination for everything process related

Self-Organization versus Self-Management | by Marty de Jonge | Serious Scrum | Medium
※リンク先のページが削除されたため、2023年3月時点でリンク切れになってしまっています。

症状

スプリントプランニングでスプリントでどれくらい完了できるかを計画する際に、プロダクトオーナー（以下、PO）と開発者のあいだで駆け引きが発生しているようなケースが散見されます。POは過去のベロシティを無視し、できるだけ多くのプロダクトバックログアイテム（以下、PBI）を詰め込もうとし、開発者は見積り（ポイント）の水増しをはじめます。

開発者がPBIを書くことを拒んでいるチームを見たこともあります。なんということでしょう。プロダクトバックログアイテムPBIを書くのはPOの仕事、PBIを書いてもらえればその通りに作りますというスタンスに開発者がなってしまっているのです。開発者はReadyなPBIがないので着手できませんという声が聞こえてきます。一方、POからはこんなに詳細なことまでPOが決めなくてはいけないのか？という質問が飛んできます。

結果的に「PO補佐」なる訳の分からない役割の人が大量発生します。

反対に、開発者を邪魔したくないから（ベロシティを下げたくないから）POがPBIを書いているというチームもあります。

これらはもちろんスクラムの誤った理解です。PBIを書くのがPOとは決まっていません。

2017年版のスクラムガイドでは、プロダクトバックログの管理について以下のように書かれています。

プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。

2020年版でも以下のようになっています。

プロダクトオーナーが行うこともできるが、他の人に委任することもできる。

POがPBIを書くことになっていたことは一度もありません。

スクラムが役割を3つに分けているのはそれぞれの仕事に線を引くためではありません。「計画」と「実行」を分離してしまってはスクラムの意味がありません。そんなやり方は本末転倒です。

処方箋

役割を超えて協力していくことが欠かせません。

2020年版のスクラムガイドでは役割の帽子化が進んでいます。プロダクトオーナーやスクラムマスターは固定された役職ではなく、まるで帽子をかぶり分けるように必要な場面で適切な人がその役割を担うというように柔軟に役割を変えて行ってもいいでしょう。

たとえば、デイリースクラムの説明には以下の記述があります。

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

一方、2017年版の記述はこうです。

デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、 開発チームの邪魔にならないようにスクラムマスターが配慮する。

これらの記述を比較すると、POと開発者がより対等な関係で交換可能な役割として捉えられていることが分かります。

また、「あなた対私」ではなく「問題対私たち（Problem vs. US）」の構図を引き出すことも重要です。「私たち」はもちろんスクラムチームですが、私たちが向き合う問題とは何なのかをチームが共通認識しとして持っておく必要があります。そのひとつの答えが、スクラムガイドにチームが確約（コミットメント）するものとしてあげられているプロダクトゴール、スプリントゴール、完成の定義です。これらをうまく使ってスクラムチームの視線を揃えていきましょう。

弊社のアジャイル研修では簡単なゲームでスクラムのスプリントをまわす模擬体験を取り入れていますが、その中でプロダクトバックログの優先順位やPBIの中身についてPOが一方的に決めるのではなく、POと開発者が話し合う時間を設けています。開発者は単にPOに言われたことをやる人ではないということを伝えています。

3. スクラムマスターがスクラム警察もしくは雑用係になってしまっている

2020年版のスクラムガイドにおいてスクラムマスターの定義は以下のようになっています。

スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。

2017年版で「サーバントリーダー」だったところが「真のリーダー（true leader）」になっています。

真のリーダーとは何でしょうか？

Forbes に掲載されていた記事が分かりやすかったので紹介します。ボスとリーダーの違いが対比されています。

Good Leaders Are Invaluable To A Company. Bad Leaders Will Destroy It.

これを読んで真のリーダーってサーバントリーダーと何が違うのと思われたかも知れません。Scrum Inc. Japan からスクラムガイドの執筆者のひとりである Jeff Sutherland 氏に確認をとったところ、同じものだよという回答が返ってきたそうです。

「リーダー」という言葉を使うことによってボス的なリーダーを連想される懸念もありますが、それよりもサーバントリーダーが単にサーバントになってしまっているという懸念が上回ったのでしょう。

その他にも細かい所ですが、スクラムマスターが支援することの例として2017年版では以下のことがあげられていました。

開発チームの進捗を妨げるものを排除する。

これが2020年版では以下のようになっています。

スクラムチームの進捗を妨げる障害物を排除するように働きかける。

対象が開発チームからスクラムチームに広がり、「働きかける」と付け加えられました。スクラムマスターは「働きかける」役割であり、排除するのはスクラムチームであることが明確になっています。

私個人的には2017年版のこの箇所は、開発チームはスクラムマスターによって守ってもらっている存在という解釈をすることもでき、とても屈辱的で気に入っていませんでした。私が知っている開発者はもっと自立的な存在です。

症状

スクラムマスターがプロダクトの成果や組織の目標にコミットメントせず、スクラムのルールを守らせることだけに注力し、スクラム警察化している現場があります。

スクラムマスターが雑用係になっているチームもあります。コーヒーやお菓子を買ってくるとスクラムマスター自身もチームの役に立ったような気になりますが、そんなことで仕事をした気になっていてはいけません。スクラムマスターは使いっぱしりではないのです。

スクラムマスターが単なる司会役になっているのもあるあるです。

2017年版のスクラムガイドには以下の記述があります。

必要に応じてスクラムイベントをファシリテートする。

スクラムマスターが必ずしもスクラムイベントの司会をする必要はありません。「必要に応じて」と書いてあるのに、「常に」スクラムマスターがスクラムイベントをファシリテートしているチームが多いです。

2020年版ではこの文は削除されました。

処方箋

スクラムマスターの育成に力を入れることが重要になりますが、これは難しいテーマです。作戦はいくつもありますが、ひとつおすすめを紹介しておくと、スクラムマスターの社内コミュニティをつくることです。スクラムマスター同士の横の繋がりで相互に学びや経験を共有していくことで、高い学習効果が得られます。

また、最近、弊社がチームの支援をする際に取り入れたことは、弊社が支援を開始してからスクラムマスターを選任するようにしました。当たり前のことですが、スクラムをこれからはじめるという組織において、スクラムマスターが何者かも分からない状態で支援先でスクラムマスターを選任してもらうのは無理があります。そのような場合、たいていは課長や主任といった役職のついている方や開発リーダーの方、技術リードの方をスクラムマスターとして選任される傾向が強いです。実際には、スクラムマスターは役職に紐付くものではありませんし、開発リーダーや技術リードの適性とも異なります。

ボスとリーダーとの比較で示したような真のリーダーとしての資質とプロダクトの成果や組織の目標にコミットメントしていくための熱量を重視して選任していく必要があるでしょう。

告白すると弊社でアジャイル開発に取り組んでいるチームにスクラムマスターはいません。ただし、「リーダー」と呼ばれている役割はあります。これは役職ではなくあくまでも役割です。「リーダー」はまさに真のリーダーだということに2020年版のスクラムガイドを読んでいて気づきました。

さいごに

これを読んで自分たちの組織やチームがこれらの罠にはまっているかもしれないと思った方。以下のリンクからお気軽にご相談ください。

お問い合わせ | Agile Studio