初めに
僕は4年ほどスクラムを採用した組織づくりを行ってきました。
最近「スクラムの内容は理解したけど、結局スクラムがなんなのかがわからない」という話をされることがちょこちょこあるので、記事としてまとめることにしました。
スクラムとは
スクラムとは、アジャイル開発を実現するためのフレームワーク、プラクティスの一種です。
スクラムガイドには、以下のように定義されています。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織
が価値を⽣み出すための軽量級フレームワークである。
スクラムガイド より引用
スクラムでは、スクラムマスターやプロダクトオーナーなど、いくつかのロールをもうけ、ロールごとにチームとしての開発を進めていきます。
また、スプリントの単位で以下のようなイベントを実施していきます。
- スプリントプランニング
- デイリースクラム
- ミッドタームレビュー
- スプリントレビュー
- スプリントレトロスペクティブ
詳しいイベントの目的や定義などはスクラムガイド をご覧ください。
スクラムの難しさ
スクラムはイベントなどの定義が明確にされており、それらは何かを準備せずともはじめることができてしまうものが大半なので、比較的開始するハードルが低いと思っています。
その一方で、https://qiita.com/getty104/items/74512b8a0d89b8b4bea3 の記事にも書いたのですが、始めるのが簡単な一方、各イベントの目的や、スクラム自体の造詣がなくとも運用自体はできてしまうため、なんとなく「しっくりこない」状態に陥りやすいです。
おそらく「スクラムの内容は理解したけど、結局スクラムがなんなのかがわからない」という言葉もこの、形だけの始めやすさとスクラムの練度の低さのギャップにより生まれてくる悩みなんじゃないかなと考えています。
スクラムの正体
スクラムの正体を理解するためには、まずはアジャイルとはなんなのかを理解する必要があると思っています。
アジャイルという思想が登場するまでは、システムはウォーターフォールという思想での開発が主流だったことは有名な話だと思います。
ウォーターフォールとは、各ステップが予定通り進んでいく前提でスケジューリング、開発を行っていく、いわば「不確実性」は計画段階でゼロにすることができる、という思想を持つ手法だと考えています。
それに対して、アジャイルとは「不確実性をゼロにすることはできない」という、ある意味での銀の弾丸の存在を否定する思想だと考えています。
つまり、アジャイルとは不確実性をゼロにするかわり
- できるだけイテレーティブにものづくりを行う
- プロダクトの評価を細かいスパンで行い、軌道修正を行なっていく
- 事前に用意するマニュアルより、今リアルタイムで動いているコードを信頼する
などの、リアルタイムで進んでいる開発、手続き、チームの状態に目を向け続け、細かい軌道修正をしながら道を進んでいきましょう、という開発思想、手法です。
そしてスクラムも同じく、「開発手法、進め方に銀の弾丸はない」という前提で自分たちのプラクティスを獲得していくための手法です。
一言で言ってしまえば「自分たちにとってのプラクティスを獲得するためのプラクティス集」がスクラムなのです。
つまりスクラムのイベントやロールをマニュアル通りに行なってもスクラムの目的は達成されません。
重要なのは「いかにスクラムのプロセスを経て自分たちの学びが増えているか」になります。
ここを勘違いすると、マニュアル通りにスクラムを回すこと自体が目的になってしまい、実は自分たちの学びは何も増えていなかった、という状態になるリスクがあります。
まとめ
このように、スクラムとは実施するのは簡単な一方、本当の意味でスクラムによって実現したい目的を達成し続けることはとても難しいものです。
過去スクラムについていくつか記事を書いているので、よかったら併せてご覧ください。