スクラムの説明の問題
よくあるスクラムの説明では、HOWにフォーカスしていてWHYにフォーカスしてないものが多いように思います。
会社ではスクラムマスターしているのですが始めた当初はWHYを理解できておらず、誤った方向にスクラムを導いてしまったり、本当のメリットが享受できていなかったです。
そんな自分の失敗から学んだ、それぞれのルールのWHYを共有したいと思い記事にしました。
スクラム開発のWHY！
なぜ自己組織化？
スクラムではトップダウン的な意思決定プロセスではなくチーム自身で判断して行動できること（自己組織化）が求められます。これについては大きく2つのWHYがあると考えています。
WHY① モチベーションと成果
モチベーションには2種類のモチベーションがあり、一つは給料や罰則によるアメとムチによる外発的モチベーションです。外発的モチベーションは一般的に浸透している手法ですが、心理学や経済学の研究によって金銭的な報酬を提示されると、人間のクリエイティブな発想が低下し、一度アメをもらうと作業に対して興味・関心が失われることがわかっています。
そのため、スクラムが目指してるのはもう一方の自分がやりたいという意思からくる内発的なモチベーションです。内発的モチベーションを持ってもらうためには、目的、スキルアップ、個人裁量の3つを与えることが大切だと言われており、スクラム開発でトップダウン的な意思決定をせず、個人裁量による自己組織化を提唱しているのにはこういった背景があります。
モチベーションについてもっと詳しく知りたい人はダニエル・ピンクのモチベーション3.0をぜひ読んでみてください。
WHY② 無駄を減らす
スクラム開発では無駄を極限まで減らすという考えがあります。そのためマネージャーや管理者などの余分な役職の定義がありません。
これはシンプルな理由ですが、誰かが管理者になる場合はその人がボトルネックになる可能性があります。また、問題を一番理解している現場の開発者が、わざわざ上司に報告するのは無駄だからです。
なぜイテレーティブ？
スクラムでは2週間程度のスプリントを繰り返して、イテレーティブに開発をおこなっていきます。
WHY① チームの改善
スプリントを切らないウォーターフォール的な開発では開発プロセスの検証がされないままの開発が進められる場合が多々あります。
スクラムにはスプリントレトロスペクティブがあり、これを導入することでスプリントごとに開発プロセスやチームの雰囲気など改善がなされることでスプリントを重ねるごとに、より効率的に働くことが可能になります。
WHY② アウトプット
新しいシステムを開発するときに漏れがなく、余分なものもない完璧な設計をするのは不可能です。そのため、スクラムではバックログを活用して、価値の高いものから着手することで、余分なものがなく本当に必要な機能が揃ったシステムを開発できます。また、スプリントを繰り返しているので、出来上がったもののフィードバックを素早く得られることができ、ビジネスの変更にも強くなります。
指標の導入は？
スクラムでは他のアジャイル手法とは違い、ベロシティなどの指標は一切出てきません。指標は導入してはいけないというルールはありませんが、安易な指標の導入には大きなリスクがあります。
WHY① 局所最適
例えばベロシティに着目すれば、工数の過剰見積もりに繋がる可能性があります。不具合の件数に着目すると改修をしなくなったり、重要だけど複雑な部分を避ける可能性出てきます。
この現象は局所最適と呼ばれていて、本当に大切なことは顧客体験の最大化にも関わらず、そこにフォーカスがされなくなることがあります。
WHY② 個人よりチーム
局所最適の話とつながりますが、指標が個人のスキルにフォーカスするようなものになると、自分自身のパフォーマンスを上げるために、チームとしてのパフォーマンスに目が向きづらくなります。例えばベロシティを重視した場合に、ソースレビューや新人のサポートは自分自身のパフォーマンスの低下を引き起こします。
いかに優秀なメンバーを揃えても、バトンを落としてしまってはリレーでは勝てないのと同じように、本当の目的を見失ってしまうと開発が失敗に終わることになります。
最後に
私自身まだまだスクラム勉強中なので、どんどん新しいことがあれば追加していこうと思います。
内容はあくまで私の意見なので、ご意見ご指摘あればぜひコメントいただけると嬉しいです。