アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料）
スクラムで陥りがちな罠24個
みなさんこんにちは。@ryuzeeです。
Agile Adviceの24 Common Scrum Pitfalls Summarizedより、スクラムで陥りがちな間違い24個がまとめられていたので、抜粋・意訳にてご紹介します。
スクラムはフレームワークとしてはそんなに複雑ではないですが、実践するのは結構難しいのが実情です。 よく聞くのがデイリースクラムが15分では終わらずに1時間かかるとか、出荷可能な製品をスプリント毎に作れないとかいったものです。 そして多くの組織において、基本としてのスクラムを実現できない（という思い込み）が故に、何かを変えたり、本来のスクラムの価値を失った間違ったやり方をしています。 以下にあがっているような症状があるのであれば、もう一度原理原則に立ち返って考えなおしてみるべきでしょう。
- 過剰な準備や計画作成：スクラムにおいては定常的な大きな前払いの計画作成は必要ではない。かわりに、チームは作業を開始し、計画を調整するためにスプリントレビューの継続的なフィードバックを利用する
- ツールにフォーカスしてしまう：多くの組織ではスクラムプロセスを管理する手助けとなる電子的なツールを探そうとする…しかも、スクラムをうまくやる方法を知る前にだ。初期のスクラムにおいては手で紙ベースのトラッキングを行うべきだ。というのもその方が始めやすいからだ。ツールを探す作業は往々にしてスクラムを始めることの妨げになるものだ。加えて、アジャイルマニフェストではツールについてどのように言っているかもチェックすること
- デイリースクラムで問題解決しようとする：デイリースクラムは問題（障害、妨害）の解決策を探すために使うべきではない。そうではなく、ミーティングを短い時間に保ち、その後にその問題に関係のある人だけを集めて問題解決のための会話をすべきだ
- タスクを割り当てる：自己組織化のコンセプトについては長い間言われているにも関わらず、いまだにプロジェクトマネージャやチームリードがチームメンバーにタスクを割り当てるべきだと思っている人もいる。タスクを支配し割り当てるよりも、自分からサインアップするのを待つほうが良い
- 失敗したスプリントを再開する：スプリントが途中で中止になることは珍しいが、再開する前に全てを完璧にしたりReadyになるまで待ちたくなるのが人情だ。ただそうではなく、スプリントがキャンセルされたら速やかに次のスプリントを開始するべきだ
- スクラムマスターを作業者にしてしまう：スクラムマスターは消防士のようなものだ。暇な方がチームにとって良いことだ。チームを観察し、緊急の障害を待っていれば良い。タスクを持ってしまうと、チームがスクラムのルールに従うことを助ける仕事や積極的に障害を取り除く仕事や割り込みからチームを守る仕事の妨げになってしまう
- ゴールを拡張する：チームはどれだけの作業がスプリント内でこなせるかを決める。誰もチームにオーバーコミットするようなプレッシャーをかけるべきではない。これは反感を生んだり、信用を失ったり、品質の低い作業を推奨するようなものだ。チームはプロジェクトやプロジェクトのゴールにチャレンジすることによって動機づけられる
- 個人を英雄視する：スクラムチームにおいてはメンバーを過度に単独にさせることはすべきではないし、チームのヒーローであろうとすべきではない。スクラムは素晴らしいチームを作る助けとなるものであり、すごい人たちのチームを作るものではない
- 開発チームがプロダクトバックログを作る：開発チームはユーザーのニーズに対する適切な洞察を持っているわけではなく、技術的な問題を解決することに集中すべきだ。プロダクトオーナーはROIに対する責任があり、それゆえ、技術的な理由での進め方の順番を決めようとするチームからのプレッシャーには抵抗すべきなのだ
- プロダクトオーナーが解決策を指定する：プロダクトオーナーはプロダクトバックログにある項目についてどのような解決策を取るかについてはチームに完全に自由を与えなければならない。プロダクトバックログアイテムには、顧客やエンドユーザーからの直接的な要望と紐づいていない限り、技術的な仕様は含まれない
- 緊急の割り込み：スプリントでの緊急の割り込みは許されるべきではない。代わりに、本当に緊急であれば、チームはスプリントを中止するべきだ。さもなくば、割り込みはプロダクトバックログに追加され、次のスプリント以降に繰り延べられるべきだ
- 思い込み：チームメンバーがプロダクトオーナーに対して今取り組んでいる作業の詳細について質問をしないことがしばしばある。チームメンバーは問題を解決するが、制約を知っていることは必要不可欠だ。プロダクトオーナーとチームの間のフィードバックはスプリントの間毎日毎日行われるべきなのだ
- 完了にならない：次から次へと起こる物事から逃れることは困難だが、チームがオーバーコミットしてしまうことは習慣になってしまう可能性がある。チームが効果的にバーンダウンチャートを使っているか、作業が全て完了していない場合でもデモを行っているかを確認すること
- デモの準備ができていない：チームがデモの準備（チームのスペースを綺麗にして、デモ環境をセットアップし、スクリプトを配置し、重要なステークホルダーが予習していることを確認する）に時間をとるのを忘れることもある。これらのタスクはスプリントバックログのタスクの一部だ
- プロトタイプで出荷可能ではない：スクラムチームは一番最初のスプリントから製品品質レベルにある、出荷可能なソフトウェアを作り出せるようにしていかなければならない。プロトタイプのコードを作ることはプロダクションコードを作ることを遅らせることになる。同様にワイヤーフレームや詳細なデザインなどは避けるべきだ
- 分散チーム：スクラムでは公式的には全員が作業部屋に集まっていることを要求しているわけではないが、現実としては、チームメンバーが分散していること（たとえそれがパーティションによる区切りくらいでも）は透明性やコミュニケーションに対して悪影響を及ぼすし、結果として生産性や品質にも影響を及ぼす
- スクラムマスターが指示する：スクラムマスターはチームが自己組織化することやスクラムのルールを学ぶことをサポートするファシリテーター役でなければならない。スクラムマスターはチームメンバーがどのように自分の仕事をするか、次に取り掛かるタスクを何にするかといったことに口を出す誘惑には絶対に屈服してはならない
- 開発チームのメンバーを変える：スクラムは高いパフォーマンスを持つ開発チームを作るためのフレームワークだ。もしチームのメンバーを変えてしまったら、チームは形成→混乱・対立→統一→機能の順番で最初からチームづくりをやり直さなければならなくなる。もしチームが統一や機能の段階にあったら、いかなる理由であれメンバーを変えることはムダでしかない
- スクラムチームにスクラムで規定された以外のロールがある：社内での公式の肩書きや責務について変更することなしにスクラムチームを作ってしまうのはとてもよくあることだ。例えば、プロジェクトマネージャの人が肩書きの変更なしにプロダクトオーナーとしての責任を与えられるという感じだ。スクラムチームは、スクラムマスター、プロダクトオーナー、チームメンバーだけであるべきだ
- 品質を諦める：スクラムはチームに対して成果物「出荷可能な製品」の品質を強く求める。チームや組織にとって常に品質を極めて高く保つよりもバグを出してトラッキングしていくほうが簡単だがそれではいけない。そのようなことが起こるのは、機能のリリースに対して強いプレッシャーがかかっているが故だ
- 押し付け型の締切りとリソース：スクラムは現実をベースにしている。もし外部のステークホルダーがスコープと締切りを押し付け、チームのリソースが十分ではなかったら、品質を犠牲にするだろう。これはスクラムの原則に反している。現実として、誰も未来を見通すことはできないし、そのようなことは幻想に過ぎない
- 完成の定義の押し付け：完成の定義と標準の定義の考え方の差は不明確だ。マネージャやステークホルダーは正しくない標準をチームの完成の定義として押し付けることがしばしばある
- スクラムマスターがその場にいない：かつて私はスクラムマスターたちのための部屋が用意されている組織を見たことがある。彼らはほとんどの時間をそこで他のスクラムマスターたちと一緒に働いていた。スクラムマスターがチームを離れることを許されるのは、チーム外にある妨害事項の除去のための活動の時だけであるべきだ。その他の時間はチームの部屋にいなければならない
