スクラムのよくある誤解（勘違い）とその対策

スクラムとは

スクラムは、今や多くの組織とプロダクトで実践されている信頼のおけるフレームワークとなっています。その用途は、いわゆるアジャイル開発のみならず、複雑な問題に対するフレームワークとして認知され、実践されています。さらに、スクラムは、コミュニティの力も借りて、常に検査と適応を繰り返しており、継続的なアップデートが行われています。それらは、「スクラムガイド」として更新されており、最新版は、2020年11月に公開され、日本語を含む各国語に翻訳されています。

スクラムの知識が古いままであったり、そもそも最初から誤解していたり、勘違いしていたりということはよくあることです。例えば、スクラムを開発プロセスだと誤解していると、「スクラムを実践したら、質の高い要求通りの機能が量産できる」と期待されてしまったり、考え、進化することを忘れてしまったりしてしまうでしょう。

スクラムのよくある誤解（勘違い）

ここでは、一連のツイートで列挙したスクラムのよくある誤解（勘違い）を紹介していきます。

#スクラムのよくある誤解（勘違い）
— 長沢智治アジャイルコーチ兼エバンジェリスト (@tnagasawa) July 18, 2023

プロダクトオーナーをスクラムチームの上司として扱ってしまう

「スクラムガイド」を読み直しましょう

プロダクトオーナーをはじめとしたスクラムの「責任」は役割でも役職でもありません。上司がプロダクトオーナーであることはあり得るかもしれませんが、プロダクトオーナーが上司であることはありません。プロダクトオーナーの責任からも上司としての振る舞いは求められていません。

参考記事:

スクラムマスターをプロジェクトマネージャーとして扱ってしまう

「スクラムガイド」を読み直しましょう

スクラムマスターをはじめとしたスクラムの「責任」は役割でも役職でもありません。スクラムでは、スクラムチームは「自己管理」を行います。したがって、プロジェクトのマネジメントを一人の人に任せる、押し付けることはありません。極端に言うと、今までのプロジェクトマネジメントは、チームで分散して、または共有して行うことになります。また、スクラムマスターは従来のマネージャーでも、プロジェクトの遂行者でもありません。経験主義とスクラムのフレームワークをスクラムチームやステークホルダーに対して馴染ませて、目的遂行に向けて取り組めるようにする「責任」があります。したがって仮にプロジェクトが上手くいかないからといってスクラムマスターが責任を取るべきでもありません。スクラムチーム、ステークホルダーで、次のスプリントからどう修正できるのか、経験的に学び、実践していくべきです。

明確に定義できるプロダクトゴールとスプリントゴールを持ち合わせていない

「スクラムガイド」を読み直しましょう

確約（コミットメント）はスクラムの価値基準の一つであり、根幹です。プロダクトゴール、スプリントゴール（さらに、完成の定義）は、必ずセットしましょう。

プロダクトゴールはプロダクトビジョンへの具体的な踏み石となるものをセットし、達成できたらさらにプロダクトビジョンに到達するためのものをセットしていきます。インクリメントはプロダクトゴールへの具体的な踏み石となるため、スプリントレビューでは、インクリメントとプロダクトゴールとのギャップを中心にレビューすることで、次以降のプロダクトバックログに適応させることができます。同時にプロダクトゴール自体の検査を行い、状況の応じて適応させていく、すなわち元プロダクトゴールがマッチしていなかったら破棄して、別のプロダクトゴールをセットします。

スプリントゴールは、先に示したようにプロダクトゴールへの具体的な踏み石となるインクリメントをそのスプリントで更新するための目標です。従って、プロダクトゴールに関連したものであるべきです。スプリントゴールを達成したときには、インクリメントは完成の定義を満たしている必要があります。

参考文献:

スクラムの価値基準（The Scrum Values）

参考記事:

掲げたプロダクトゴールを変更してはいけないと思っている

「スクラムガイド」を読み直しましょう

プロダクトゴールも変化に適応させなければなりません。プロダクトゴールは、「プロダクトビジョンへの具体的な踏み石」です。踏み石にならないとわかった時点で、破棄して新たなプロダクトゴールを設定すべきです。そのためには、プロダクトゴールの検査と適応をする必要があるのです。具体的な「場」としてはスプリントレビューがその機会です。また、プロダクトゴールは、スクラムチームとステークホルダーが目指すものは「一つ」ですが、プロダクトビジョンへの道筋としては、複数のプロダクトゴールを経ることになります。これが、いわゆるプロダクトロードマップにつながります。繰り返しになりますが、硬直化したプロダクトゴールは害になりがちです。

参考文献:

スクラムの価値基準（The Scrum Values）

参考記事:

使用可能で価値のあるプロダクトを早期かつ頻繁にリリースしようとしない

「スクラムガイド」を読み直しましょう

本当に価値があるのかは、ユーザー/顧客に提供してフィードバックをもらうまでわかりません。それまでは仮説に過ぎないと言えます。したがって、リリースする気がないならスクラムでなくてもいいのかもしれまん。「何がわからないのかは、わかるまでわからない」です。

参考記事:

スプリントで少なくとも1つのインクリメントを追加作成しようとしない

「スクラムガイド」を読み直しましょう

ちなみに仮説に過ぎないとはいえ、適当に設定したり、作ったりしていいわけではありません。蓄積された「事実」に基づいた仮説を立てるようにすべきです。従ってわかっている事実が何かを検査することを忘れてはなりません。

参考記事:

ベロシティと価値の区別がついていない

「スクラムガイド」を読み直しましょう

ことソフトウェアに関しては、作った量や費やした作業量でアウトカムを測ることはできません。逆に、アクティビティやアウトプットをどんなに測っても価値に直結しているのかはわかりません。2014年にKen Schwaberがこの問題提起をしてEBMのフレームワークを提唱したように、アウトカム（価値）とベロシティや作った機能の量、費やした作業量には直接の関連性がないのです。

参考記事:

スプリントレビューに適切なステークホルダーを参加させず（参加せず）、積極的にフィードバックを求めない（しない）

「スクラムガイド」を読み直しましょう

本当に価値があるのかは、ユーザー/顧客に提供してフィードバックをもらうまでわかりません。それまでは仮説に過ぎないと言えます。ステークホルダーとのコラボレーションは、スクラムにおいても、みなさんのビジネスやプロダクトの成功にとっても欠かすことができません。ステークホルダーが関与してくれない前提、ステークホルダーを関与させない戦術ではなく、如何に感じよく関与してもらえるか、関与する恩恵があるかを追求してみましょう。

そのためには「プロダクトゴール」でステークホルダーと語れるようになることが重要です。場当たり的なフィードバックではなく、ビジョンに基づいた具体的なプロダクトゴールという目標を目指した建設的なフィードバックを得ることが重要となります。

参考記事:

失敗したくないから、実験や学習、継続的改善の機会を作らない

「スクラムガイド」を読み直しましょう

失敗せずに成功するなんてことはほとんどありません。とは言え、大きな事故につながる失敗や、同じような失敗の繰り返しは好ましくありません。防御したいお気持ちはわかりますが、小さくリカバリーが効くうちに失敗して学んでいく方が近道です。スクラムでは、経験的アプローチに基づいた検査と適応が組み込まれているため、意図的に小さく失敗する（失敗したことに気が付く）ことがし易くなっています。その利点を活かしましょう。

参考記事:

スクラムを従うべきプロセスと捉えていて、スクラムの価値基準を重要視（意識）していない

「スクラムガイド」を読み直しましょう

スクラムは経験的アプローチという科学的な手法に基づきます。そのためには信頼が不可欠です。スクラムの価値基準や意図を置き去りにして単に進め方としてスクラムを用いるとゴミを大量生産できます。

これを「メカニカルスクラム」または、「ゾンビスクラム」と呼んでいます。

参考記事:

心理的安全性や信頼を築くための時間を設けない

「スクラムガイド」を読み直しましょう

スクラムの価値基準は、信頼のために不可欠な要素です。信頼は、経験的アプローチの透明性の促進に欠かすことができません。信頼を築くためには、スクラムの価値基準とスクラムイベントでどの価値基準を特に重視すべきかを意識してチームで議論するところからはじめるとよいでしょう。

参考記事:

デイリースクラムを現状の進捗報告会として実施している

「スクラムガイド」を読み直しましょう

デイリースクラムは、「検査と適応」の機会です。進捗報告会ではありません。よくある「3つの質問」は、デイリースクラムでの実施のフレームワークの例にすぎませんので、これに盲目的に従うのはやめましょう。あえで「3つの質問」を使うならば、意図を明確にしましょう。

スプリントゴールの達成のために、昨日何を行ったか
スプリントゴールの達成のために、今日何をやるか
スプリントゴールの達成のために、障害物となっていることは何か

デイリースクラムは、スプリントゴールの達成に対する検査と適応の機会です。スプリントプランニングで計画した通りに進捗しているかどうかを確認する場ではありません。プランニングの誤りがあれば、容赦なく今からできることをしてスプリントゴールの達成のために右往左往すべきです。

参考記事:

スプリントレトロスペクティブで対立や障害物を避け、わいわいするためだけに行なっている

「スクラムガイド」を読み直しましょう

スプリントレトロスペクティブは、チームの活動に対する検査と適応を行う重要なイベントです。スプリントの最後に行うイベントのため、わいわいやりたいのは大切なことではありますが、本質を見失わないようにしましょう。同様に単なる「反省会」になるのもよくありません。要するにこのイベントは過去をふりかえって反省する場ではなく、未来に向けて前向きに議論し、改善するきっかけを生むものであるべきだということです。少しでもよりよくするための時間として捉え、個人を変えるのではなく、仕組みを変えること、相互補完をすることをテーマに取り組むことで、対立や障害物との向き合い方が変わる傾向があります。

参考記事:

スクラムチームが「リベレイティングストラクチャー」の原則から恩恵を受ける方法

スプリントプランニングをゴールの確認と設定ではなく、単なるスプリントでの詳細計画の場となっている

「スクラムガイド」を読み直しましょう

作業を機械的に行いたくなり（作業の意思決定の責任を軽減したくなり）、プロダクトバックログの上から順にスプリント期間に収まるプロダクトバックログアイテム（PBI）を選択しようとしがちですが、それに何の価値があるのか、それらを作ったとしてステークホルダーにレビューしてもらう価値があるのか、レビューで価値あるフィードバックが得られるのかを考えてみましょう。

スプリントプランニングでは、スプリントゴールを設定し、そのゴール達成に必要なPBIを選択するようにします。当然、十分に洗練されたPBIでなければスプリント期間内で開発できないことも忘れてはなりません。また、プランニングではスプリントゴールの達成だけでなく、将来のスプリントでの仕事をよりよくするための改善も行う必要があるはずです。

また、「プランニング」と名がついていますが、スプリントでの作業タスクを全て洗い出し、それらに人をアサインするような計画になることは稀です。なぜならば、スプリント中にも変化があり、わからなかったことがわかるようになるのが常だからです。従って綿密な計画を立てるというよりは、スプリントで実施しようとしているPBIを作りきれるのか、一つも価値を生み出せないようなことがないようにできそうかをスクラムチームでディスカッションしましょう。

よって、詳細な作業タスクにさほど意味がないため、予実管理もあまり効果的ではないこともおわかりでしょう。そう、過去の実績と照らし合わせてプランニングするよりも、これから何をすべきかに集中すべきです。

参考記事:

スクラムチームが「リベレイティングストラクチャー」の原則から恩恵を受ける方法

リファインメントを怠っているか、関心を示さない

「スクラムガイド」を読み直しましょう

参考記事:

スクラムチームが「リベレイティングストラクチャー」の原則から恩恵を受ける方法

ステークホルダーとの対話はプロダクトオーナーだけが行えばいいと思っている: 「スクラムガイド」を読み直しましょう

ファシリテーションはスクラムマスターだけが行えばいいと思っている: 「スクラムガイド」を読み直しましょう

開発者は開発作業だけを行なっていればいいと思っている: 「スクラムガイド」を読み直しましょう

スクラムをカタ通りに行なっていれば、いいプロダクトが作れると思っている: 「スクラムガイド」を読み直しましょう

スプリント期間を短くしたからといって、意味もなく（機械的に）各イベントの時間を短縮する: 「スクラムガイド」を読み直しましょう

スプリント期間を短くしたからといって、イベントを省く: 「スクラムガイド」を読み直しましょう

スプリントの中止をチームで話し合って決めてしまう: 「スクラムガイド」を読み直しましょう

経験的アプローチをしていない。スクラムイベントで何を検査し、何に適応させるかわかっていない: 「スクラムガイド」を読み直しましょう

バーンダウンチャートを作業進捗の道具として扱っている: 「スクラムガイド」を読み直しましょう

マネージャーはスクラムの責任にいないから、チームのために何もやらなくていいと思っている（チームはマネージャーを無視していいと思っている）: 「スクラムガイド」を読み直しましょう

PBIはユーザーストーリーの形式で書かなければならない: 「スクラムガイド」を読み直しましょう

スプリント中に完成しなかったPBIを繰り越して次のスプリントで作業してしまう: 「スクラムガイド」を読み直しましょう

デイリースクラムはスクラムマスターが主催する: 「スクラムガイド」を読み直しましょう

プロダクトバックログにプロダクトゴールと関係のないアイテムがいつまでも残っている: 「スクラムガイド」を読み直しましょう

インクリメントにすでに不要になった機能が残っている: 「スクラムガイド」を読み直しましょう

プロダクトオーナーやスクラムマスターを役職や役割、JDとして定義しないといけないと思っている: 「スクラムガイド」を読み直しましょう

誤解や勘違いをしないための対策

スクラムの誤解や勘違いをできるだけ減らしていきたいものですが、誤解や勘違いにフォーカスしすぎると価値を生み出す方にフォーカスできなくなる危険もあります。そこで私が誤解や勘違いに効果があると思っている事柄を挙げておきます。

スクラムガイドの読み合わせを行う
スクラムガイドは一人で読んで理解するのもよいですが、せっかくですので、チームで、関係者全員で読み合わせすることをおすすめしています。これにより共通認識が醸成されると同時に、疑問を吐き出すきっかけづくりができます。私がアジャイルコーチとして参画する際には、ほぼ確実にスクラムガイドの読み合わせをしてもらい、その状況を観察させていただくようにしています。
コミュニティに参加する
コミュニティには、あなたの悩みをすでに通過した人、今まさに同じ悩みを抱えている人、これから同じような悩みに突入する人が集まっています。したがって、この場に身を置くことで、自身と他者の差分を感じ取る（知るまで意識しなくてもいいです）ことができます。また、あなたの経験と知識が他者の手助けになることも知ることができます。また、コミュニティとは社外コミュニティだけをさしません。社内コミュニティ、いわゆる（CoP: プラクティスコミュニティ）を強く推奨します。やり方がわからなかったらご相談ください。
誤解や勘違いを恐れず実践する
誤解や勘違いは、他人に知られると恥ずかしいものです。でも自分自身やチームでならそこまで恥ずかしくありません。誤解や勘違いを恐れて実践しないよりは、実践して自分たちでこれらに気づく方が心理的にもリスクの観点からも楽です。「何がわからないかは、わかるまでわからない」ものなので、実践により誤解や勘違いを発見し、適応させていきましょう。
アジャイルコーチを雇う
自分たちだけでは心許ない、できるだけ早くなんとかしたいなど、事情は現場それぞれなはずです。そこでアジャイルコーチを連れてきて、伴走してもらうことも検討してみましょう。