スクラムとは

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

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

スクラムのよくある誤解(勘違い)

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

プロダクトオーナーをスクラムチームの上司として扱ってしまう
スクラムマスターをプロジェクトマネージャーとして扱ってしまう
明確に定義できるプロダクトゴールとスプリントゴールを持ち合わせていない
掲げたプロダクトゴールを変更してはいけないと思っている
使用可能で価値のあるプロダクトを早期かつ頻繁にリリースしようとしない
スプリントで少なくとも1つのインクリメントを追加作成しようとしない
ベロシティと価値の区別がついていない
スプリントレビューに適切なステークホルダーを参加させず(参加せず)、積極的にフィードバックを求めない(しない)
失敗したくないから、実験や学習、継続的改善の機会を作らない
スクラムを従うべきプロセスと捉えていて、スクラムの価値基準を重要視(意識)していない
心理的安全性や信頼を築くための時間を設けない
デイリースクラムを現状の進捗報告会として実施している
スプリントレトロスペクティブで対立や障害物を避け、わいわいするためだけに行なっている
スプリントプランニングをゴールの確認と設定ではなく、単なるスプリントでの詳細計画の場として
リファインメントを怠っているか、関心を示さない
ステークホルダーとの対話はプロダクトオーナーだけが行えばいいと思っている
ファシリテーションはスクラムマスターだけが行えばいいと思っている
開発者は開発作業だけを行なっていればいいと思っている
スクラムをカタ通りに行なっていれば、いいプロダクトが作れると思っている
スプリント期間を短くしたからといって、意味もなく(機械的に)各イベントの時間を短縮する
スプリント期間を短くしたからといって、イベントを省く
スプリントの中止をチームで話し合って決めてしまう
経験的アプローチをしていない。スクラムイベントで何を検査し、何に適応させるかわかっていない
バーンダウンチャートを作業進捗の道具として扱っている
マネージャーはスクラムの責任にいないから、チームのために何もやらなくていいと思っている(チームはマネージャーを無視していいと思っている)
PBIはユーザーストーリーの形式で書かなければならない
スプリント中に完成しなかったPBIを繰り越して次のスプリントで作業してしまう
デイリースクラムはスクラムマスターが主催する
プロダクトバックログにプロダクトゴールと関係のないアイテムがいつまでも残っている
インクリメントにすでに不要になった機能が残っている
プロダクトオーナーやスクラムマスターを役職や役割、JDとして定義しないといけないと思っている

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

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

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

本記事の執筆者:

長沢智治

長沢 智治 - アジャイルストラテジスト

サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。

PSPO II - Professional Scrum Product Owner II
PSPO I - Professional Scrum Product Owner I
PSM II - Professional Scrum Master II
PSM I - Professional Scrum Master I
PSD I - Professional Scrum Developer I
PAL-EBM - Professional Agile Leadership - Evidence-Based Management
PAL I - Professional Agile Leadership I
SPS- Scaled Professional Scrum
PSU I - Professional Scrum with User Experience
PSK I - Professional Scrum with Kanban I
PSF - Professional Scrum Facilitation Skills
PSPBM - Professional Scrum Product Backlog Management Skills
認定スクラムマスター
DASA Accredited DevOps Trainer

『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール