2024年の仕事初め、ハドルMTGの延長で部下から次のプロジェクトをスクラムでやりたい、と。その際、価値観を合わせたいから読んでほしい、と、この本を紹介されました。
部下が前向きにやりたいと言うなら、とまずは話を聞いて、実は僕も少し前に「認定SCRUMプロダクトオーナーの研修」を受けていたので（実務で導入するには至らなかったけど。）、一応やりたいことの理解はしたつもりでした。
研修と、その実
上記の研修の時はグループワークとしてプロダクトオーナーとかスクラムマスターとかのロール(役割)を順繰りにやって、「へー、こういうことを考えてやるんだ」と体験したけど、それを「現場に導入しよう！」と強く思わなかったのは何故なのか。
本当に良いとされている開発手法なら日本中、いや、世界中のIT企業に採用されていてもおかしくないのではないか。でもやっぱりウォーターフォールが主流だよね、みたいな。
そんなわけで、部下から要請されたことも理由だけど、2024年、新しいことにチャレンジするのも良いな、という考えのもと、ぽちって(購入して)読みました。
本書の構成
構成としては、「基礎編」「実践編」の二段階だけど、大部分が実践編に割かれています。
「SCRUM BOOT CAMP THE BOOK」P.2
- 基礎編 スクラムの全体像と決められているルールについて説明する。
- 実践編 架空の開発現場を題材に、開発が始まるときから時系列にスクラムではどう進めていくのかを説明する。
今回も読みながら気になったところに付箋をつけまくっていたので、そこから抜粋したり、読みながら書いていたメモをもとに感想を書いていきたいと思います。
基礎編
基礎編はその名の通り、「スクラム」そのものとか、それにまつわる用語だとかロールなどの説明がメインになっています。例えば、プロダクトバックログとか、プロダクトオーナー、スクラムマスターなどなど。
用語的には以前受けた研修で聞いていたのでこのあたりの理解は早かったです。もとい知っていたと言うべきか。
あ、スプリント中の各イベントでの目的とかどういったことをしていのか、みたいな部分を文章でまとめてあるのは良かったです。
スクラムの5つの価値基準
基礎編のまとめとしてスクラムを活用して良い結果を生むために取り入れるべき価値基準が書かれています。
「SCRUM BOOT CAMP THE BOOK」P.27
- 確約：それぞれの人がゴールの達成に全力を尽くすことを確約する
- 勇気：正しいことをする勇気を持ち、困難な問題に取り組む
- 集中：全員がスプリントでの作業やゴールの達成に集中する
- 公開：すべての仕事や問題を公開することに合意する
- 尊敬：お互いを能力ある個人として尊敬する
スクラムならでは、という価値基準ではないけど、掘り下げていくと結構難しい基準だな、とも思えます。すべてできれば確かに良いチーム。
実践編
本書の大部分を占めているのがこの実践編だけど、ところどころにマンガが挟まれていて非常に読み進めやすいです。
あと個人的には、マンガ外のところでも主人公の「ボク」がちょいちょい疑問点とか納得感を出してくる部分があって、一緒に読み進めている感と共に「あー、そうそう、それ思う」って共感できるのがよいな、と思いました。
プロダクトオーナーになるべき人とは（P.39）
プロダクトオーナーの作業については基礎編にも記載があるのだけど、実践編にもほぼ似通った、けど、若干表現の異なるまとめがあったのでこっちを引用。
「SCRUM BOOT CAMP THE BOOK」P.39
- 開発していくもののビジョンを伝える。
- スクラムチームで達成していきたいゴールを伝える。
- 具体的に何を実現してほしいかを伝える。
- どれを優先して実現させていくと良いものになるかを決める。
- どう実現すると良いものになるかを考えて、最終的な判断をする。
- 決定に問題がないかを関係者（ステークホルダー）と合意しておく。
- 予算や期間のような制約を守るために必要なことを調整する。
- 関係者の協力をとりつけ、調整する。
要求とか仕様、そして計画に関する作業をするのがメイン。（プロダクト実際に作る人ではない）
見積もりは素早く・作業の量で（P.72）
どんな開発手法でも見積もりは重要だけど、スクラムでもそれは同じ。ただ、あくまでも「予想」であり、ズレるのは前提くらいの気持ち。もちろんその精度を高めていくべきではあるけど、それはスプリントを回していく中で達成されていくもの。（見積もり者のスキルとかではなく）
見積もりはスクラムチームが行い、「作業の量」で見積もる。どれかひとうの項目の作業量を出し、それを基準にして相対見積もりをしていく。1,2,3,5,8,13,21,…というフィボナッチ数を使うとやりやすい（これは研修でもやった）。
自分たちの責務について理解する（P.158）
いくつかあるスクラムイベントを形式的に執り行うだけではうまくはいかない。スクラムチーム全員が「なぜこれをやるのか」といった目的を理解した上で、求められていることに応える必要がある。
このことは本書を通して語られているようにも思うけど、とにかくスクラムチームがひとつになって、チームの責任で、チームの力で進める、という気概というか、そういうものを感じる。理想的だけれど、実際の現場では横槍が入るってあるあるなんだよな・・・とも思うけど笑
ベロシティ（P.164）
この言葉は研修で触れたっけ・・・と思った言葉のひとつ。失念しているだけかも？
スクラムでは、実際にスプリントでどれくらいのことを実現できたかを計測して、今後のことを予測していく。その計測結果がベロシティだ。実際にどれくらいのペースで実現できているかがわかれば、本当にリリースできそうな日などもわかってくる。
「SCRUM BOOT CAMP THE BOOK」P.164
つまり、スクラムチームの実力を数値化したもの？スカウター的な？
それはともかく、そのベロシティは当然大きいほうがいいわけだけど、スプリントを進める上では「安定」しているべきもの。チームがスクラムに慣れていないうちは小さいけど、徐々に慣れて大きくなる、といったことは多少あっても、急激に大きくなることはないし、なるべきではない、と。
ベロシティは「計測結果」であり、信頼されうる値。それをもとに今後の計画を作ったり、予測していくわけなので、安定していないベロシティは危険。
なお、人を増やしてもベロシティは上がらない。（長期的には上がるが、即効性はない）
ゴールを満たすために、何を実現するのか判断する（P.204）
すなわち、プロダクトバックログのメンテナンス（リファインメント）を日頃から取り組むこと。そして、常に最新の情報をもとに「どの順番で、何を実現するのか」を判断する。
最新の情報とは、新しく入ってきたプロダクトバックログのことだけではなく、既に見積もりがされている上位の項目についても再見積もりをする、ということも含まれる。当初の状況と違っていたり、より精緻な見積もりができたり。
プロダクトバックログの手入れはスクラムイベントには規定されていないけど、最初は定期的なイベントにしておくとよいらしい。
失敗からどんどん学ぶ（P.236）
ここではコミットメントという価値観について語られているのだけど、ここでの例え話含めてよく理解できなかった・・・。ので、メモとして残しておく。
とりあえず、コミットメントは責任を伴う約束のことであり、スプリントゴールを達成するためのコミットメントについて他者(外部)が口を挟んではいけない、ってことらしい。これはスクラムチームよりも立場が上の人間にありがちな気はする。自分も気をつけないといけない。
その他、雑多な感想とか
ここからは読みながらメモった雑多な感想です。
従来の開発手法との違いについて思ったこととか
ウォーターフォールに比べて、遠い将来の計画まで明確に練らない一方で、日々のコミュニケーション（＝スクラムイベント）を密に持つことが必要なのでは、と。
前に誰かが「アジャイル開発では設計書を書かない（これが本当かは知らないけど）」的なことを言ってて、面倒な作業を省けるアジャイル万歳！感があるけど、これは変わり得る状況に対応するための密なコミュニケーションによって支えられてるからなのでは？と思いました。
つまり、結局設計書（＝ドキュメント）を書くか、コミュニケーションをとるか、みたいな。じゃないと間に落ちるものが絶対に出てくるはず。もちろん、アジャイルでもウォーターフォールでもどちらかでいい、どちらかをしない、というわけではなく、どちらに重きを置くかの問題だとは思う。
ドキュメントの要否についてもう少し
スクラムチームのタスクはプロダクトバックログから落ちてくるわけなので、スクラムチームのPOとして、「設計書は要らないが仕様書は要る（ステークホルダーに説明するために）」とかはありそう。
もちろん設計書の要否は運用視点で決まる部分はあると思うので、POが不要としても同じスクラムチームの開発チームが「必要」と判断すればそれは作る、になるんだろうな。
アジャイルなんでいつ終わるかは言えません
前にこんな感じのことも聞いたけど、それはまるで責任放棄だな、と本書を読んで思いました。
アジャイル（スクラム）では、「終わったこと＝確実なこと」として信用し、将来のことはあくまで予想・推測とするけど、その「確実なこと」を積み重ねて、予想・推測の精度を上げていくわけなので、「いつ終わるかわからない」はただ適当なだけじゃん・・・。
確実な計画を立てるのは無理だから直近の見える将来の計画に注力し、そこから導かれる「予想・推測」で語る。そして「終わったこと」の積み重ねによって精度が上っていく。
印象的だったこととか
スクラムチームは役割、リーダーなどはいない
踊る大捜査線を思い出したけど、その場合、実際のコードレビューとかはどうするんだろう？設計の妥当性とかは？それもプロダクトバックログでタスク化？（誰でもできるものではないが・・・）
タイムボックスを守る→自分たちのできる範囲かどうか
（後ろ向きに捉えると少し予防線的でもある？）
スクラムチームのルールもスクラムチーム全員で決める
目的や意図が腑に落ちて納得感が出るのがよい。そして「全員」という表現からしてスクラムチームの人数の制限（開発チームは3~9人+PO+SM）がここにも影響してそう。
スクラムでは実績から先のことを予測する
タイムボックスの固定はそのためにも重要。また、実現したいことが明確でないと手戻りになってしまい、実績が信頼できなくなる。
疑問点とか
読んでいく中で感じた疑問点も残しておきます。
扱いにくいコードの問題
本書のマンガの中で、「扱いにくいコードが放置されている」という状況が出てくるのだけど、スクラムマスターはそれにどう気付くのだろう？（スクラムマスターは開発チームではないけど・・・）
スクラムマスターは、実質的にシニアなエンジニアで、コードレビューをするタスクを持たないといけない？（もちろん理想は開発チームの中から上がってくることなのだろうけど・・・）
スクラムチームとは別の肩書き
リーダーとかマネージャーとか、いわゆるオリジナルの組織の肩書き、役職との兼ね合いはどうなるんだろう？例えば、役職者がプロダクトオーナーやスクラムマスターだと結局「指示・命令」になってしまわないか、とか。
役職者はスクラムチームに入るべきでないのかもしれない（ステークホルダーが関の山？）けど、現実には少なくともリーダーレイヤーは入ることになるだろうし・・・。
というわけで、まだまだ理解が追いついていない点もあるけど、研修でやったことを体系的になぞっていくような（そしてそこに文章及びマンガでの説明を付記されたような）感じで非常に納得度が強い一冊です。
現実的なところでいくと、これを速攻で適用できる現場とか状況（新規開発？追加開発？、開発者の人数は？、ビジネスの動き方は？、などなど）は限られるだろうけど、少しずつとか一部とかでも取り入れていくのはできそうな？感じ。マインド的なところも含めて。
だけど、何より一番難しそうなのは「スクラムをやる」よりも「今のやり方を変える」という部分な気がする。それならば自分のような中間管理職の立場の人間こそ、積極的に上に働きかけないといけないのかもしれないなあ。（いいこと言った）
