我々も「スクラム」やるぞ！と言われても、イマイチどうしてスクラムでやりたいかが伝わっていないことがあると思います。あまり乗り気でない開発者は以下のようなことを感じているかもしれない。
改善に興味がなかったら厳しそうですが、スクラムを導入する嬉しさは簡単にでも紹介できたほうが良いと思うのであらためてちょっと整理してみます。
そもそもどういうことができているチームが優秀なチームかというのを考えると
以下のようなことができていると、優秀なチームなのかなと私は考えています。
- 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている）
- タスクが急遽差し込まれたり、方針が変わったときにスムーズに対応できる
- あらゆるタスクの優先順を決めて集中して進めることができている
- 過去の経験からある程度見積もりを予測して開発を進めることができている
- 「このまま進むとやばそう！」ということを早い段階で察知できている
- みんな生き生きと仕事ができている
上記のようなことができている「優秀なチーム」であれば、ここからさらに「スクラム」を導入する必要性は低いと思います。逆に何かしらできてなさそうであれば、仕事の進め方（会議体の整理、タスク管理の仕方など）を考えることになると思いますが、一から独自に考えて進めていくよりは「スクラム」にそのまま乗っかるというのがコスパが良いです。
仮にこの一般的なフレームワークである「スクラム」に乗っかった上でうまくいかなかった部分があったとしても、世の中にスクラムを導入している事例は沢山あるためググったり勉強会に出向いたりすれば知見を得ることができます。スクラムはそもそも定期的にチームで振り返りを行う土台があるため、最初のうちはまだ理想の状態になっていなくても理想に近づけていくことはできます。
スクラムのフレームワークに乗っかるとお得な例の紹介
より詳細にどうしてフレームワークに乗っかるとお得か簡単に書いてみます。
- 「スクラムイベント」と呼ばれるものを全て導入すると、「1. 改善サイクルが回っている」に自然となります
- スクラムでは「スプリント」という短い単位の中で計画と開発と発表と振り返りを行うため、少なくともその単位では方針転換することが可能です（「2. タスクが急遽差し込まれたり、方針が変わったときにスムーズに対応できる」）
- 「デイリースクラム」などで相談してはやめに方針転換することも可能です
- 「バックログリファインメント」という作業をプロダクトオーナーと一緒に定期的に行うことによって「3. あらゆるタスクの優先順を決め」られるようになり、かつ「スプリント」の単位で「集中して進めることができている」状態になります
- 毎日別の仕事をランダムに倒していく感じではなく、あらかじめ計画したものだけにフォーカスを当てられる
- 「スプリント」の単位で回していることや「見積もり」を行うことによって、過去の「スプリント」ではこれくらいできているのでこの調子で進めると大丈夫そうですねと勘ではなく数値で説明できるようになります (「4. 過去の経験からある程度見積もりを予測して開発を進めることができている」)
- 「スプリントレビュー」という場で定期的に成果物をアピールすることによってある程度の「やったぜ」感を開発者は感じることができる。また「スクラムマスター」の役割の一つは「開発者の幸福度を維持すること」なので、「スプリントレトロスペクティブ」などの場で相談しつつ「5. みんな生き生きと仕事ができている」をチームで目指せるようサポートしてくれる
スクラムを全て導入しないといけないのかどうか
2020-Scrum-Guide-Japanese.pdf の「最後に」の章を読むとスクラムの一部を導入するだけでは不十分というようなことが書いてあります。以下の記事でも似たことが書いてあります。
www.ryuzee.com
ただスクラムガイド2020をよくよく読むと「かんばんをこのように使いましょう」とか「バーンアップチャートを使いましょう」みたいなことは書いてありません。全て導入しましょうというのは、例えば「スプリントプランニングはやるけどスプリントレトロスペクティブはやらない」みたいなことは避けましょうということです。スクラムイベントが全て導入されてはじめて「1. 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている）」の状態になるということですね。
なので、確かに一部のスクラムイベントだけ導入して終わりということにはなってほしくないですが、細かいタスクの管理方法などはスクラムになってもカスタマイズ自由なので、スクラムをガチガチなフレームワークなのだと恐れている人がいれば実は自由度がそこそこあるんですよということもついでに伝えておきたい。
終わり
ここまでは主に「スクラムを導入したところで嬉しさがわからない」にたいして自分なりに嬉しさを言語化してみました。最近のスクラムガイドを読むと以前と比べてどんどん簡略化されているので、かなり幅広いチーム（ソフトウェア開発に限らず）で適用することができると思いますし、おすすめできると思います。一方で「スクラム独自の用語が沢山あり、覚えるべき概念が多そうに感じる」の課題感に関してはごもっともとは思いつつも、これはスクラムマスターにサポートしてもらうしかないかなと思います。チームによってはスクラム関係の本の読書会を行ったりしているのを見かけます。改善のサイクルを回せるチームになるのは多くのところは目指していると思うので勉強してみることにメリットはあると思います。
