「予定通りに進まない」「本当に求められているものが作れているのか、わからない」。
開発の現場で、この感覚に心当たりのある人は多いはずです。私自身、計画表のとおりに物事が進んだ記憶のほうが少ないくらいで、ガントチャートの線がいつのまにか現実と乖離していく、あの居心地の悪さをよく知っています。
『SCRUM BOOT CAMP THE BOOK【増補改訂版】』は、その「進まなさ」を正面から扱った一冊です。西村直人さん、永瀬美穂さん、吉羽龍太郎さんによる、はじめてスクラムに取り組む人のための実践ガイド。
前半の基礎編でルールをコンパクトに解説し、後半の実践編では架空の開発現場を舞台にしたマンガで、つまずきと立て直しを疑似体験させてくれます。
スクラムはアジャイル開発の代表的なフレームワークです。でも本書がいちばん伝えたいのは、会議の手順やツールの使い方といった技法ではありません。「スクラムは、チームで学んでいくための仕組みだ」。この一文に、本書の核心が詰まっています。
こんな人にこそ届く本
最初に言っておくと、これは開発職だけの本ではありません。チームで何かを前に進めている人なら、職種を問わず刺さる構造を持っています。
朝会が「進捗報告会」になっていて、毎回15分では終わらない人。本書は、その朝会の目的そのものを問い直してきます。「いつ終わるのか」を聞かれるたびに胃が痛くなる人。
見積りと計画への向き合い方が、たぶん根本から変わります。ふりかえりや反省会が、いつの間にか犯人探しになってしまうチームにいる人。会の設計を立て直すヒントがいくつも見つかります。
逆に、大規模組織への展開（スケーリング）や、込み入った技術的負債の解消といった高度なテーマを期待すると、物足りないはずです。本書はあくまで「初めてのスクラムチーム」が対象。守備範囲を限定しているからこそ、入口の解像度が高い、と捉えたほうがいいと思います。
開発の目的は、ソフトを作ることではない
本書の出発点は、はっとさせる一文です。開発の目的は、ソフトウェアを作ることではない。
できあがったものを実際に使ってもらい、顧客や利用者の課題を解決して、成果を上げること。それが目的であって、開発はあくまで手段にすぎない。当たり前のようでいて、現場ではこの順番がよく入れ替わります。
気づけば「予定の機能を全部作りきること」が目的化し、誰のための機能だったのかが見えなくなる。
そしてもう一つの前提が、「未来は正確に予測できない」というものです。だからこそ短いサイクルで作って試し、わかったことをもとに進路を直していく。
完璧な初期計画を一発で当てにいくのではなく、価値やリスクの高いものから順に届けていく。これがアジャイル開発の考え方で、スクラムはその思想を回すための具体的な型なのだと、私は読みました。
この本の強みは、マンガによるストーリーテリングにあります。新米スクラムマスターの「ボクくん」が直面する失敗や戸惑いを描き、そのあとにテキストで「なぜそのルールが必要なのか」を解説する。
抽象的なフレームワークが、具体的な現場の景色として頭に入ってくる。理屈の前に、まず手触りがある。これが入門書として効いています。
ルールは最小限、だから自分たちで埋める
スクラムは、分厚いマニュアルでチームを縛りません。
複雑な問題を扱うための、最低限のルールのセット。3つのロール（人の役割）、5つのイベント（会議など）、3つの作成物で構成されています。ルールが少ないからこそ、足りない部分は現場に合わせて自分たちで埋めていく余地が残されている。
これは裏を返せば、丸暗記では機能しないということでもあります。
中心になるのが3つのロールです。プロダクトオーナー（PO）は「何のために、何を、どういう順番で作るか」を決め、プロダクトの価値を最大化する責任を持つ人。
本書が面白いのは、適任の条件をスキルや権限よりも、「作るものをどうすれば良くなるか熱心に考え、情熱を持って取り組む人」だと言い切っているところです。
足りない知識は、チーム全体でカバーすればいい。
開発チームは、実際に作る人たち。「どうやって作るか」はチームに任され、設計からテストまで自分たちで進めます。適切な人数は3〜9人の少人数。そしてスクラムマスターは、いちばん誤解されやすい役割です。
タスクを割り振るマネージャーではなく、スクラムが円滑に回るよう支援し、外部からの妨害や割り込みからチームを守る「縁の下の力持ち」。本書はこれを、支援と奉仕に徹するサーバントリーダーシップと呼びます。
これらを動かすエンジンが「透明性・検査・適応」の3本柱です。現状や問題を常に明らかにし（透明性）、進捗や進め方を定期的に確かめ（検査）、まずければやり方を変える（適応）。
この3つを短いサイクルで回し続けることで、わからないことだらけの問題に対処していく。スクラムの各イベントは、結局この3本柱をどこかで担っているだけなのだと整理すると、急に見通しがよくなります。
朝会は問題を「見つける」場で、「解く」場ではない
デイリースクラムは、毎日15分の短い集まりです。
開発チームが同じ時間・同じ場所に集まり、ゴールに向かって進んでいるかを確認する。日々の作業はタスクボードに付箋で貼り出し、誰が見ても一目でわかる状態にしておく。ここで本書が強く釘を刺すのが、デイリースクラムは問題解決の場ではないという点です。
朝会で問題が報告されると、つい全員でその場で解決策を話し込んでしまう。気づけば30分、1時間。これが形骸化の入口です。15分のタイムボックスを守るために、問題が見つかったら会の後で、必要な人だけ集まって話す。報告と解決を切り離す、という割り切りです。
さらに本書は、デイリースクラムが「上司への進捗報告会」に変質する失敗にも触れます。報告のための会議になった瞬間、検査という本来の目的が失われる。
だからこれを、問題を早期に発見する場として徹底せよ、と言うわけです。ちなみに2017年版のスクラムガイドでは、おなじみの「3つの質問」（昨日・今日・困りごと）は必須ではなくオプションになりました。
形式より、問題を見つけるという目的のほうが大事だということです。
見積りは「正確さ」より「素早さ」と割り切る
ここから先は、開発職以外の人もハッとする話だと思います。
スクラムでよく使われるのは、時間や金額の絶対値ではなく、作業量を相対的に表す「相対見積り」です。まず作業量が真ん中ぐらいでイメージしやすい項目を基準にして数字を決め、他の項目がそれと比べて何倍くらい大変かを比較していく。
このとき1, 2, 3, 5, 8, 13…というフィボナッチ数をよく使います。
なぜ正確さを追わないのか。本書の登場人物はこう言います。「まだ実現していないものを見積もるっていうのは、単なる推測にすぎないんだ」。未来の作業を正確に当てようと何時間も悩むより、規模感を素早くつかむほうが価値が高い。
詳細に見積もるのは直近の数スプリント分だけでよく、先のことに時間をかけても多くは無駄になる。
不確実なものは不確実なまま、割り切って扱う。この姿勢が、見積りを「絶対の約束」と思い込むプレッシャーからチームを解放します。それでも本書は計画そのものを捨てません。
「見通しが大事なのは、スクラムかどうかにかかわらず大事なことだ」とも書く。「アジャイルだから計画は不要」というのは誤解で、継続的に計画を作り直すことこそ欠かせない、という立場です。
ベロシティを上げようとした瞬間、開発は遅くなる
私がいちばん驚いたのが、この話です。
ベロシティとは、チームが1回のスプリントで完成させた作業量（ポイントの合計）の実績値。将来のスケジュールを予測するための目安です。多くの現場が、これを「上げ続けなければならない指標」だと思い込んでいます。本書は、そこに真っ向から「ベロシティに惑わされるな」と警告します。
ベロシティは決めるものではなく、計測するもの。期日に間に合わせるために無理に上げようとすると、何が起きるか。テストを省いたり、扱いにくいコード（技術的負債）を溜め込んだり、見積りをこっそり水増ししたりする。結果として予測そのものが信用できなくなり、かえって開発が停滞する。
だから重要なのは、ベロシティが高いことではなく、安定していること。安定して初めて、未来の見通しが立てられます。「速度を上げろ」という一見もっともな指示が、長い目で見ればチームを遅くする。
この逆説は、ノルマや成約件数といった、開発以外のあらゆる「数字の管理」にもそのまま当てはまる話だと感じました。測ること自体は悪くない。測った数字を脅しに使った瞬間に、数字が嘘をつき始めるのです。
失敗していい、むしろ失敗しないと学べない
スクラムには、もう一つ思い込みを壊す主張があります。
「最初から全部を完璧にできるスクラムチームはいない」。見積りを外しても、数スプリントあれば挽回できる。むしろ初期の小さな失敗は、多くを学ぶために欠かせない。失敗を許さない環境こそが、チームの成長（カイゼン）を止めてしまう、と本書は言います。
ここで「コミットメント」の意味も再定義されます。スクラムが求めるのは、約束を必ず果たすチームではありません。本書の言葉を借りれば「責任を持って取り組んでいくことに価値を感じるチーム」です。
コミットメント＝絶対達成のノルマ、ではない。自分たちで決めた目標に本気で向き合う、という約束のことなのです。だからスプリントゴールが未達でも、結果だけを責めない。
プロセスから学び、次に活かす。この前提があるからこそ、チームは挑戦を続けられます。
ふりかえりは反省会じゃない、1%でも前に進める場だ
スプリントの終わりには、2つのイベントがあります。
スプリントレビューは、作っているものの検査。完成した成果物をステークホルダーにデモし、フィードバックをもらう場です。本書は「最大の目的は、プロダクトに対するフィードバックを得ること」だと言います。
きれいなスライドを作る会ではなく、実際に動くものを見せて評価を得る会、ということです。
もう一つがスプリントレトロスペクティブ（ふりかえり）。こちらは仕事の進め方の検査で、チームのやり方やツール、関係性を見直して改善点を決めます。そして、このふりかえりがいちばん誤解されている。多くのチームで「反省会」や「アラ探し」になり、問題ばかり挙がって空気が重くなる。
本書はここで視点の転換を求めます。問題を見つけるのと同じ以上に、うまくいったことを見つけてチームで高めていくことが大事だ、と。お菓子を食べながらリラックスして話す、少しでもうまくいったところを褒め合う、といった具体策まで紹介されています。
心理的な安全をつくったうえで改善案を出す、という順番です。
そして最大のコツが数字にあります。問題を100%解消しようとせず、1%でも前に進めるアイデアを1つだけ決める。全部を直そうとするから、結局何も変わらない。
具体的で計測できる（SMARTな）アクションを1つに絞り、次のスプリントに組み込む。この積み重ねが、チームを少しずつ強くしていきます。なお品質のものさしとして「完成の定義」という仕組みもあり、何をもって完成とするかをチームとPOで事前に合意しておくことで、「なんとなく完成」という曖昧さを防ぎます。
今日からできる3つのこと
本書の提案を、明日からの行動に落とすとこうなります。
まず、仕事を可視化する。いまの作業を洗い出し、付箋やホワイトボードで「未着手・進行中・完了」に分けて貼り出す。チーム全員が現状を一目で把握できる状態をつくる。透明性は、まずここから始まります。
次に、15分の状況確認を始める。1日1回でいい。集まって「困っていることはないか」を共有し、解決策の議論は会の後に回す。早く助け合えれば、作業の停滞を防げます。
そして、ふりかえりで直す点を1つだけ決める。大きな問題を一気に片づけようとせず、1%でも改善できる小さなアクションを1つだけ次に組み込む。これがいちばん続きます。
スクラムの名前の由来は、1986年に野中郁次郎さんと竹内弘高さんがハーバード・ビジネス・レビュー誌に発表した論文にあります。それをジェフ・サザーランド氏とケン・シュエイバー氏がソフトウェア開発に応用し、1990年代に「スクラム」が生まれました。
ラグビーのスクラムのように、チームが一体となって前へ進むイメージです。
本書はこう書きます。喜んでもらえるプロダクトを作るのは簡単じゃない、けれどそれはものすごいスキルを持った人だけの特権ではない、と。天才がいなくても、平凡なメンバーが協力し、失敗から学び続ければ良いものは作れる。
計画通りに進めることより、失敗から学んでチームで改善し続けること。その軸さえ持てれば、完璧な計画がなくても前に進めます。まずは付箋を1枚、ボードに貼るところから始めてみてください。
合わせて読みたい
『チームが機能するとはどういうことか』エイミー・C・エドモンドソン スクラムのふりかえりが機能するかどうかは、心理的安全性があるかで決まります。失敗や懸念を口にできるチームをどう作るのか、その土台を理論から学べる一冊です。
『失敗学のすすめ』畑村洋太郎 「失敗していい、むしろ失敗から学べ」というスクラムの姿勢を、より深く支えてくれます。失敗を隠す組織が同じ過ちを繰り返す構造を知ると、ふりかえりの意味が変わります。
「振り返る時間」がチームを変える レトロスペクティブの本質を、開発の文脈を離れて考えたコラムです。1%でも前に進めるという本書のアプローチと、まっすぐ響き合います。
