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

スクラムとは
スクラムのよくある誤解（勘違い）
誤解や勘違いをしないための対策
本記事の執筆者:

スクラムとは

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

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

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

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

#スクラムのよくある誤解（勘違い）
— 長沢智治 Tomoharu Nagasawa (@tnagasawa) July 18, 2023

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

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

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

参考記事:

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

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

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

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

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

確約（コミットメント）はスクラムの価値基準の一つであり、根幹です。

参考文献:

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

参考記事:

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

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

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

参考文献:

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

参考記事:

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

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

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

参考記事:

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

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

参考記事:

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

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

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

参考記事:

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

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

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

参考記事:

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

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

失敗せずに成功するなんてことはほとんどありません。とは言え、大きな事故につながる失敗や、同じような失敗の繰り返しは好ましくありません。防御したいお気持ちはわかりますが、小さくリカバリーが効くうちに失敗して学んでいく方が近道です。

参考記事:

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

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

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

参考記事:

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

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

スクラムの価値基準は、信頼のために不可欠な要素です。信頼は、経験的アプローチの透明性の促進に欠かすことができません。

参考記事:

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

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

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

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

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

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

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

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

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

リファインメントを怠っているか、関心を示さない: 「スクラムガイド」を読み直しましょう

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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