読書メモ　SCRUM BOOT CAMP THE BOOK

「SCRUM BOOT CAMP THE BOOK」という本を読んだので、その感想。

この本は、「初めてスクラムをやることになったら読む本」とのことで、まさにそれに適した内容だったため、以降はこの本で書かれていたスクラムの基本事項について自分なりにまとめておく。
また、それに対する現在の自分の感覚を書いておく。

ロール

- プロダクトオーナー
プロダクトの責任者でプロダクトバックログの管理者

- 開発チーム
プロダクトを作るために必要なすべての作業を行う

- スクラムマスター
スクラムがうまく回るように支援、教育

用語

- タイムボックス
　- それぞれのイベントごとに定められた固定の作業時間（デイリースクラムは１５分以内とか）
　- 予測に使うため必ずそれぞれのタイムボックスは守る必要がある

- スプリント
スクラムでは固定の短い期間に区切って繰り返し開発を行うが、その固定の期間をスプリントという

- プロダクトバックログ
　- 実現したことをリストにして並べ替えたもの
　- 上位のものから開発していくため常にメンテしておく必要がある
　- 誰でも自由に書けるようにしておく

- スプリントプランニング
　- 今回のスプリントで何を開発するか（どのプロダクトバックログの項目を選択するか）、どうやって選択したプロダクトバックログの項目を実現するのかを議論する
　- 確実に終わらせることができる計画を作る。確実な計画を作るための活動である

- デイリースクラム
　- 毎日１５分程度実施
　- 昨日やったこと、今日やること、進めるにあたって障害になるものを共有する
　- 問題が発見されてもデイリースクラム中では問題解決のための議論は行わない

- スプリントレビュー
プロダクトオーナー主催でスプリントの成果をレビューするイベント。プロダクトに対するフィードバックを得ることを目的とする

- スプリントレトロスペクティブ
　- 作業において改善できる点を議論するイベント
　- 出てきた内容は次回のスプリント以降に含める

- ベロシティ
　- スクラムごとに開発チームが終わらせることのできるポイント数
　- ベロシティがわかれば先の見通しが見えるようになる
　- 人を単純に増やしてもベロシティは上がらない
　- 経験を積むことにより見積ポイントが変化したりもするので、ベロシティはあくまでも目安とする

- ユーザーストーリー
実際に使う人たちの視点で実現したいことを記述したもの

- リリーススプリント
　- 通常のスプリントが終わった後にリリースに必要な作業をまとめたもの
　- 必須ではなく、むしろなるべくなら必要としないほうが良い

その他

- チーム全員で話し合うことが重要
- スクラムでは各作業の見積もりの方法は決まっていない

読み終わっての感想

スクラムというのは今までは開発手法のフレームワークだと思っていたが、実はチームとしての進め方のフレームワークであるとこの本を読んで思った。
そういう意味では、開発タスク以外にもスクラムは応用できる可能性があると思う。
一方、ベロシティを計測するという側面があるので、ある程度見通しの効くタスクにしか使えないのでは？という懸念も持った。
このため、保守・運用のような突発的にタスクが頻繁に発生するような業務には向かないし、調査のようなある程度着手してみないと見通しが見えにくいタスクにも向かない。
さらに、１年以上後にゴールが設定されているような長期間の開発にも向かないと思う。
スクラムの特性上、まずは直近で重要と思われるものに集中して取り掛かることになると思うので、はるか遠くに設定されたゴールへの全てのタスクを洗い出すことはしないのではないかと思う。
もしそれをするのであれば、ウォーターフォール型の開発とあまり変わらなくなるし。
といったことを考えると、スクラムが活かせる場面というのはものはかなり狭い範囲に思えてくる。
実際には世の中的に広まっている開発手法なのでそんなことはないのだと思うが、本書を読んだだけではそこまで見えてこなかったので、もしそういった実例に近い成功例があれば見てみたいと思った。

スクラムについてはもう１つ懸念を持った。
冒頭で書いたように、スクラムはチームとしての進め方のフレームワークだと思うので、チームの力を向上させる手法としては非常に優れているように思った。
しかし、チームというものは固定されていないことも多々ある。
プロジェクトが変わるだけであれば問題ないが、チームのメンバーの入れ替わりが発生すると、そのたびにベロシティは計測し直さなくてはいけない。
ベロシティを計測し直すということは、計測できるまではチームとしての作業スピードがわからないということになるし、つまり大げさに言えば見通しが立たないことになる。
ある程度簡単に見通しが立てられることがスクラムの１つの強みだと思ったが、この点がチーム改変のたびにスポイルされることになる。
つまり、スクラムはある程度チームが固定されていることを前提としたスキームなので、フレキシブルにチームメンバーが変わるような体制には向かない。
当然、短期間の開発のために新設されたようなチームにはまったく向かない。
前述したようにゴールの遠い長期間の開発にも向かないし、短期間の開発にも向かない、となると相当適用範囲が狭くなる気がする。

逆にスクラムが効果的だと思うプロジェクト。
真っ先に思いついたのはゲーム。
ゲーム業界に詳しいわけではないが、だいたい最近のゲームは１週間とか２週間のスパンでイベント的なものを用意する傾向にあると思うので、その配信スパンにあわせてスプリントを設定することができる。
やることがかなり明確化されているし、それを確実に実現するための手法としてはスクラムはピッタリだと思う。
また、次のスプリントにどこまで新要素を盛り込めるのかといった検討も、毎回大体同じような開発が多いと思うし、ベロシティがとても有効に機能する条件が揃っていると思う。

ゲームに限らず、こういったある程度決まったスパンでアップデートを行っていくようなサービスの開発にはスクラムは非常に適していると思う。
ただし、これはサービスインしてからの話で、サービスイン前の開発についてはウォーターフォールの方がいいかもしれない。
そういった意味では、スタートはウォーターフォールで開発を行い、ある程度主要な機能が完成したら、その後はスクラムという手法は有力な気がする。

ざっくりまとめると下記の感想。

- スクラムはチームの１人１人の能力を底上げするようなチームの力を向上させる手法としては優れていそう
- ゲームサービスのような特定の条件が揃っている開発では非常に有効そう
- 開発手法としてはごく限られたプロジェクトでしか有効に機能しないのではないかと懸念する

ただし、スクラムは良くも悪くもベースの考え方はある程度規定されているようだが、細かい規定はわりと自由に設定できる想定のようなので、アレンジすることにより対応できる範囲を広げることができる余地はあると思う。
このアレンジの仕方がキモになるのではないかと、自分は推測している。

おしまい。