読書メモ：エッセンシャルスクラム

読書メモ：エッセンシャルスクラム

February 7, 2026

読書メモ。

「スクラムの適用が一番うまくいくのは、関わっている人（深く関わっていない人も含めて）全員が、その本質についてよく理解しているときだ。」と言われます。

本書は「スクラムの全体像と詳細の両方を理想的に概観でき、しかも読みやすい」「次世代のスクラム実践者にとって、基礎文献となるに違いない」と、世界中の名だたるスクラムマスタから絶賛された一冊であり、まさしくスクラムの成功を強力に導ける書籍です。

まえがき #

スクラムの本質とは何か？ #

スクラムの基礎には、コアとなる価値、原則、プラクティスの小さなまとまりがある（それらが集まって、スクラムのフレームワークとなる）。スクラムを用いる組織は、そのスクラムフレームワークをすべて受け入れなければならない。組織全体で一斉に受け入れることはできないだろうが、スクラムを最初に使うことになるチームは、必ずそうしなければならないのだ。ただし、スクラムのすべてを受け入れるといっても、紋切り型の万能なやり方にすべて従わなければならない、ということではない。自分たちでどのようなアプローチを組み合わせるべきかがわかるまでは、スクラムフレームワークを忠実に守ったほうがよい、ということなのだ。

『エッセンシャルスクラム』では、スクラムの価値、原則、プラクティスと、現場で効果のあったアプローチを組み合わせて使っている。こうしたアプローチはスクラムフレームワークと整合性は取れてはいるものの、スクラムフレームワークにとって必須というわけではない。読者の置かれた状況に合うものもあれば、合わないものもあるだろう。読者の置かれた状況に合わせて、検査と適応が必要なのだ。

本書の起源 #

アジャイル／スクラムのコーチやトレーナーをしていると、スクラムの参考書がないかと聞かれることが多い。スクラムフレームワークの包括的な全体像を見せてくれて、スクラムを適用するうえで最も人気のあるアプローチを紹介してくれるような本だ。こうした題材を、スクラムを実践している人たちに役立つレベルで、網羅できている一冊を見つけることができなかった。

実は、スクラムの考案者たち（Jeff Sutherland と Ken Schwaber）は、スクラムに特化した「スクラムガイド」と呼ばれるドキュメントを出している。著者たちはこれを「スクラムのルールブックの決定版であり、スクラム自体のドキュメント」であるとしている。このドキュメントをチェスのルールになぞらえ、「駒がどのように動き、どのように順番がやってくるか。あるいは、どうすれば勝ちなのか」といったことが書かれているとしている。「スクラムガイド」はスクラムの概要、あるいはルールブックとして見れば役に立つが、スクラムの基礎知識を包括的に論じることを意図していない。新しいスクラムチームに「スクラムガイド」を渡して、まともに指すことを期待するようなものだ。「スクラムガイド」だけでは足りないのである。

本書『エッセンシャルスクラム』は、スクラムの基礎知識が一冊にまとまった、これまでにない本にしようと考えた。そのため、スクラムの原則、価値、プラクティスに関する詳細な議論を含んでいる。

第１章：イントロダクション #

スクラムは役に立つか？ #

多くの状況において、スクラムは素晴らしいソリューションではあるが、適切に当てはまらないこともある。クネビンフレームワークは、認識のためのフレームワークであり、状況に適したアプローチに基づいて物事を進めなければならないときに、その状況を理解するうえで役に立つ。このフレームワークは、５つの異なる領域の特徴を定義、比較している。単純な領域、込み入った領域、カオスな領域、複雑な領域、そして最後が無秩序だ。無秩序とは、どの領域に当てはまるのかすらわからないときを指す。状況に応じたスクラムの向き不向きを論じるのに、このクネビンフレームワークを使っていこう。

  • 単純な領域（理解、分類、反応）
    • 事実を分析し、分類する。そして適切なプラクティスに基づいて行動する
    • ベストプラクティスの領域
    • 変化の起きる可能性が小さい安定した領域
    • 誰にとっても因果関係がはっきりしている
    • 確かな正解がある
    • 実態に基づいた管理
  • 込み入った領域（理解、分析、反応）
    • 状況を分析して取り得る手立てを検討し、適切なプラクティスに基づいて行動する
    • 洞察を得るために専門家を任せる
    • 状況を制御するため指標を使う
    • 適切なプラクティスに従うべき領域
    • 正解はひとつではない
    • 直接的ではないにしても原因と結果が観測できる
    • どちらかといえば予測しやすい
  • 複雑な領域（探索、理解、反応）
    • 問題について学ぶために探求し、学んだことに対して検査し適応する
    • 創造的で革新的なアプローチを必要とする
    • パターンを発見するための試行錯誤ができる
    • 安全に失敗できる環境を作る
    • 交流と会話を緊密にする
    • 経験に学ぶ
    • 予測不可能なことがままある
  • カオスな領域（行動、理解、反応）
    • まずは行動して、状況が安定したならその内容を検査する。そして「複雑な領域」に移行する試みに適応する
    • 決定すべきことはたくさんあるが、考える時間はほとんどない
    • 秩序を取り戻すための即時的な行動
    • 正しい答えではなく物事を前に進めることが期待される
    • 革新的なことが求められる領域
    • 誰にもわからない
    • 因果関係は明らかではない

まず、ソフトウェア開発やサポートにはさまざまな側面があり、クネビンフレームワークをひとつ描くだけではうまく当てはまらないことを理解しておくことが重要だ。ソフトウェア開発には多種多様な試みがある。その試みの各側面は互いに重なりあっており、各活動を見ると、前述した領域すべてに当てはまるものがあるのだ。そうはいっても、ほとんどのソフトウェア開発は込み入ったもの、もしくは複雑なものに当てはあるのだが、十把一絡げに「ソフトウェア開発は複雑な領域に当てはまる」といってしまうのは、浅はかだろう。ソフトウェア開発という言葉で、革新的な新製品開発から稼働中のソフトウェア・プロダクトの保守・運用・サポートまで、幅広い分野を含もうというのだからなおさらである。

複雑な領域

複雑な問題を扱うときには、物事を予期できないことのほうが多い。正解があるとしても、後でふりかえって初めてわかるのだ。これは創発的な領域である。当の問題についてどう学ぶかを模索する必要があり、そのうえで、学習に基づき、検査と適応を行うのだ。複雑な領域に取り組むには、創造的で革新的なアプローチが必要だ。同じことを繰り返すような型にはまったアプローチでは、単純にうまくいかない。実験のために安全に失敗できる環境を作り、重要な情報を見つけ出せるようにする必要がある。こうした環境では、交流と会話を緊密に行うことが欠かせない。革新的な新製品開発はこのカテゴリに当てはまる。既存のプロダクトに革新的な新しいフィーチャーを追加する場合も同様だ。

スクラムは、特にこの複雑な領域に取り組むのにうまく当てはまる。こうした状況では、探索して（調査）、理解し（検査）、反応する（適応）ことが欠かせないのだ。

込み入った領域

込み入った問題は、専門家が活躍する適切なプラクティスの領域だ。正解は複数あるだろうが、それを明らかにするためには専門家による分析が必要となる。スクラムでもそうした問題に対応することはできるが、スクラムを用いることが最善というわけではないかもしれない。たとえば、システム全体のパフォーマンスを最適化するためにパラメータを調整するような作業は、専門家を集めて状況を分析してもらい、いくつかの選択肢を検討し、適切なプラクティスに基づくのがよいだろう。日々のソフトウェアの保守作業（製品サポートや不具合対応）は、ほとんどがこのカテゴリに当てはまる。また、シックスシグマのような戦術的・定量的アプローチの多くは特にうまくいく。ただし、こうした戦術的なアプローチは単純な領域にもうまく当てはまる。

単純な領域

単純な問題を扱うときには、誰の目にも因果関係がはっきりしている。正解が明らかで疑う余地がないこともよくある。これは、正統的なベストプラクティスの領域だ。ソリューションがわかっているのである。置かれている状況を分析すれば、あらかじめ定義された適切なソリューションのどれを用いればよいかがわかる。スクラムは、単純な問題にも用いることができるが、この種の問題では、最も効率的というわけではない。適切に定義され、反復可能な手順が組み合わせられたプロセスを用いたほうがうまくいく。たとえば、同じプロダクトを繰り返し製造したいのであれば、適切に定義された組立ラインプロセスのほうがスクラムよりも合うだろう。あるいは、商用の既存のプロダクトを顧客の環境にデプロイするのがこれで 100 回めということであれば、プロダクトをインストールして設定する手順を適切に定義して繰り返すほうがうまくいくに違いない。

カオスな領域

カオスな問題には、すばやい対応が必要だ。危機に瀕しているので、これ以上の被害を食い止め、何らか秩序を回復するために、すばやい対応が求められる。たとえば、私たちのプロダクトのアルゴリズムに誤りがあり、間違った結果を出力していると、どこかの大学が論文を発表したと想定してほしい。顧客は、私たちのプロダクトの結果に基づいて現実的にビジネス上の投資を行っており、巨額の損失について訴訟を起こす準備をしている。アルゴリズムを設計したリーダーは、休暇でボルネオ島のジャングルにいて、あと２週間は連絡が取れない。このような場合、スクラムではうまくいかない。作業のバックログの優先順位を付けて、次のイテレーションでやるべき作業を判断するような状況ではない。出血を止めるために、決断力を持って迅速に行動する能力が必要なのである。カオスな問題に対しては、その状況と行動に対して、誰かが責任を負わなければならない。

無秩序

どの領域に自分がいるのかわからなければ、それは無秩序な領域にいるということだ。この領域は危険である。置かれている状況をどう理解すればよいかわからないからだ。このような場合、自らの個人的な好みに基づいて状況を解釈して行動する傾向にある。ソフトウェア開発においては、フェーズごとに順次進めるアプローチに慣れているので、それを好む人が多い。しかし、そのアプローチは単純な領域に当てはまるものだ。残念ながらこのアプローチはソフトウェア開発ではほとんどうまくいかない。無秩序な領域から脱出するためには、状況を構成要素に分解して、それぞれをその他の４つの領域に当てはめることだ。無秩序な領域にスクラムを適用しようとしてはならない。そこから脱出しようとすることだ。

割り込み駆動の作業

スクラムは、割り込みが多すぎる作業にもうまく合わない。顧客サポートチームを運営しているとして、スクラムでサポート業務をうまくまとめて管理したいと思ったとしよう。その場合のプロダクトバックログは、電話やメールでサポート依頼を受けるたびに断続的に増えていく。すぐにプロダクトバックログはいつ終わるともわからなくなり、バックログの中身と優先順位も頻繁に（数時間あるいは数分に一度という頻度で）変わるようになるだろう。

このような状況では、１週間以上のイテレーションを自信を持って計画することはできない。その作業が将来にわたって続くかどうかわからないからだ。作業がわかっていると考えていたとしても、緊急のサポート依頼が舞い込んで、先読みをしていた計画に取って代わってしまうに違いない。

割り込み駆動の環境では、カンバンと呼ばれるアジャイルアプローチを採用することを検討するとよいだろう。カンバンは独立したソリューションではなく、既存のプロセスに重ね合わせるアプローチである。特にカンバンは以下のことを推奨している。

  • 作業がシステムをどのように流れているかを可視化すること（たとえば、サポートを行う組織がサポート依頼を解決するまでの手順など）
  • 各手順において仕掛中の作業（WIP）を制限すること。そうすることで、こなせる以上の作業を行わないようにする。
  • システム内の作業の流れを計測し、最適化して、継続的に改善を行うこと。

カンバンが適しているのは、ソフトウェアの保守とサポートの領域だ。カンバンを実践している人たちの中には、カンバンは過負荷を根絶し（仕掛中の作業量を最適化する）、作業の流れのばらつきを削減しながらも、変化のための発展的なアプローチを促進し、複雑な領域にも適切に使用できると主張する人もいる。

スクラムとカンバンはどちらも開発のためのアジャイルなアプローチで、どちらにも長所と短所がある。自分が関わっている領域を理解したうえで、それらを考慮するべきだ。組織によっては、共存する別々のシステムの要求に対応するために、スクラムとカンバンをどちらも使うことができるかもしれない。たとえば、スクラムを新製品開発に用いて、カンバンを割り込み駆動のサポートと保守に使うといった具合だ。

終わりに #

スクラムは銀の弾丸でもなければ、魔法の治療薬でもない。ただ、スクラムを用いれば、複雑なプロダクト開発という営みの変化を受け入れられるようになる。

スクラムフレームワークはシンプルだが、スクラムが容易で、労せず適用できると考えるのは間違いだろう。スクラムはプロセスの疑問を規範的に答えてくれたりはしない。自分たちで疑問を投げかけ、それに答えられるようにチームを強化してくれるだけだ。スクラムは組織的な病に対して、料理のレシピのようなソリューションを与えてくれない。組織のポテンシャルを妨げている機能不全やムダを可視化してくれるだけだ。

こうした現実を見るのは、多くの組織にとって喜ばしいことではないだろう。しかし、当初の不満だった状態を乗り越え、スクラムによって表出した問題を解決しようとするなら、ソフトウェア開発プロセスやプロダクトだけでなく、従業員と顧客の満足度も大きく前進することになるだろう。

第１部：コアコンセプト #

第２章：スクラムフレームワーク #

（省略）

第３章：アジャイルの原則 #

変動性と不確実性 #

スクラムは、プロダクト開発にある変動性と不確実性を利用して、革新的なソリューションを作り出そうとする。この話題に関連する原則を４つ挙げる。

  • 役立つ変動性を受け入れよ
  • イテレーティブでインクリメンタルな開発を採用せよ
  • 検査、適応、透明性を通じて変動性を活用せよ
  • あらゆる形の不確実性を同時に削減せよ

役立つ変動性を受け入れよ

計画駆動のプロセスはプロダクト開発を製造業として扱う。変動性を避け、定義されたプロセスと一致させることを推奨する。問題は、プロダクト開発というものが、製造業とまったく異なるということだ。製造業の目的は、要件を固定し、よく理解された工程に従うことによって、（定義された振れ幅の中で）常に同じ完成品を作り出すことだ。

しかし、プロダクト開発のゴールは、他にないプロダクトをただひとつだけ作り出すことだ。プロダクトを「製造」することではない。このひとつだけのプロダクトは、料理のレシピに似ている。同じレシピを２回作ろうとは思わない。そんなことをしたら、お金のムダだ。それよりは、新しいプロダクト用のレシピをもうひとつ作ろうとするだろう。新しいプロダクトを作り出すためには、同じだけの変動性が必要だ。事実、一つのプロダクトに含まれるフィーチャーを見ても、それぞれが違っている。このレベルでさえも変動性が必要なのだ。レシピがあって、初めてプロダクトを製造できる。しかし、プロダクト開発では、ビットをコピーするだけだ。

製造業の考え方の中には、プロダクト開発に当てはまるものも確かにある。それを活用することはできるし、またそうするべきだろう。たとえば、すぐ後で議論するように、在庫（あるいは仕掛中の作業）を認識して管理することは、製造業で欠かせないが、同じことはプロダクト開発にも言える。しかし、作業の性質上プロダクト開発とプロダクトの製造はまったく異なるので、まったく別のプロセスが必要となる。

イテレーティブでインクリメンタルな開発を採用せよ

計画駆動の開発では、事前に物事を整え、プロダクトの部品のほとんどあるいはすべてを、開発の後半になってまとめ上げる。

一方、スクラムは、イテレーティブかつインクリメンタルな開発に基づいている。この２つの用語は、ひとつの考え方であるかのように使われることも多いが、イテレーティブな開発はインクリメンタルな開発とは別のものだ。

イテレーティブな開発は、間違った後にならないと正解がわからないであろうこと、失敗してからでないとうまくはできないであろうことを認めている。イテレーティブな開発とは、計画された手戻り戦略だ。自分たちが構築しているものを改善するために、いくつもの道を辿る。そうすることで、優れたソリューションに辿りつける。たとえば、プロダクトのよくわからない箇所についての知識を得るため、プロトタイプを作るところから始めるかもしれない。その後で、もう少し良くなった修正版を作り、それがさらに適切な版へとつながる。たとえば、本書を書いているときにも、フィードバックを受け取ったり、もっとよい伝え方を思いついたりすると、各章を何度も書き直している。

開発をしながらプロダクトを改善するうえでは、イテレーティブな開発は素晴らしい方法だ。イテレーティブな開発の最大の欠点は、不確定要素が存在する精度、この先どれだけの改善を行わなければならないかを事前に判断（計画）することが難しということだ。

インクリメンタルな開発は、古くからの原則である「全部作る前に少し作ってみろ」に基づいている。開発の最後になって「ビッグバンスタイル」の一大イベントをするのはご免だ。ビッグバンスタイルのイベントでは、すべての部品をまとめて、プロダクト全体をデリバリーする。だが、インクリメンタルな開発では、プロダクトを小さい部品に分解して、その一部を構築して、実際の環境でどのように動くかを学習し、その学習に基づいて適応し、続きを構築するのである。本書を書いているときに、私は一度にひとつの章を書き、できあがるたびにレビューに出していた。一度に本全体のフィードバックを受け取ろうとはしなかったのだ。おかげで、そのフィードバックを後の章に活かしたり、文体を調整したり、必要に応じて続きを見せたりできた。また、インクリメンタルに学習し、先に書いた章で学んだことを後の章に適用することもできたのである。

インクリメンタルな開発を行うことで、開発を調整し、やってきたことを変更するうえでの重要な情報が得られる。インクリメンタルな開発の最大の欠点は、部品ごとに構築すると、全体像を失ってしまうリスクがあるということだ（木を見て森を見ず）。

スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。スクラムでは、スプリントと呼ばれるタイムボックス化されたイテレーションで適応を繰り返すことで、イテレーティブかつインクリメンタルという考え方を実現する。

各スプリントの間は、動作するプロダクトインクリメント（プロダクト全体ではなく、一部）を作り出すのに必要なアクティビティをすべて行う。各スプリントで、分析、設計、構築、統合、テストがすべて完了するのだ。この、「すべてを一度に行う」アプローチには、フィーチャーの開発をすばやく検証できるという利点がある。たとえば、設計についての判断を行い、その判断に基づいてコードを書き、設計とコードをテストする。すべてを同じスプリントで行うのだ。関連する作業をすべて一つのスプリントに行うことにより、フィーチャーに対してすぐに追加作業ができる。こうして、イテレーティブな開発の恩恵を受けるのだ。しかも、あとに続くイテレーションについて、厳密に計画を立てる必要もない。

スプリントの考え方でよく間違えられるのは、各スプリントで一種類の作業だけに集中してしまうことだ。たとえばスプリント１で分析、スプリント２で設計、スプリント３でコーディング、スプリント４でテスト、といった具合だ。このようなアプローチは、ウォーターフォール型の作業分解図（Work Breakdown Structure: WBS）にスクラムを重ね合わせようとするものだ。この間違ったアプローチのことを、私は「ウォータースクラム」と読んでいる。あるいは、「スクラマーフォール」という呼び方も聞いたことがある。

スクラムでは、工程に対して一度に作業をすることはない。フィーチャーに対して作業するのだ。したがって、スプリントが終わるときには、価値のあるプロダクトインクリメント（プロダクトのフィーチャーの一部）を作り出している。そのインクリメントには過去に開発したすべてのフィーチャーが含まれている。あるいは、統合されてテストされている。そうでなければ、完成したとみなすことはできない。スプリントの最後には、すでに完成しているフィーチャーも含めて、新しくできあがったフィーチャーのフィードバックを受け取れる。こうすることで、そうでなければ得られないような、全体的な視点からプロダクトを見られるようになる。

スプリントの結果についてフィードバックを受け取ることで、適応ができるようになる。次のスプリントで作業する別のフィーチャーを選んでもよいし、次のフィーチャーを構築する際に用いるプロセスを変更しても良い。場合によっては、インクリメントが技術的にはうまくいっていたとしても、出来としてはいまひとつだったと学ぶこともあるかもしれない。その場合には、イテレーティブな開発と継続的な改善に対するコミットメントの一部として、将来のスプリントでやり直しを計画できる。こうすることで、どの程度の改善を行わなければならないかを事前に正確に知ることができないという課題を克服できるだろう。スクラムでは、イテレーションの回数を事前に決定することを求められていない。フィードバックを継続的に受け取ることにより、適切で経済的にも意味のある回数のイテレーションを行いつつ、プロダクトをインクリメンタルに開発できるのである。

検査、適応、透明性を通じて変動性を活用せよ

計画駆動の開発プロセスでは、成果の変動性はほとんど想定されないか、全く想定されない。明確に定義された一連の手順に従い、ごくわずかなフィードバックをプロセスの終盤に行う。スクラムでは、プロダクト開発に伴う事実を受け入れる。すなわち、何か新しいものを構築するためには、ある程度の変動性は必要だということだ。プロダクトを生み出すために必要なプロセスは複雑であり、事前に完全な定義を行うことはできないと想定する。さらに、適切なプロダクトを構築するために、また、プロダクトを適切に構築することを保証するために、早い段階で頻繁にフィードバックを得られるようにする。

スクラムの核心にあるのは、検査、適応、透明性である。スクラムでは、構築するものだけでなく、構築する方法についても、検査と適応を行う。

こうしたことをうまく行うために、透明性に頼る。透明性とはすなわち、プロダクトを作り出すための重要な情報はすべて、プロダクトの構築に関わる人が入手できなければならない、ということだ。透明性によって検査が可能になる。また、検査は適応のために必要だ。透明性により、プロダクトに関心を持つ人が皆、何が起きているかを観察し、理解できるようになる。そうすることで、コミュニケーションがさらに多くなり、信頼関係が築かれる（プロセスに関する信頼とチームメンバーの信頼の両方だ）。

あらゆる形の不確実性を同時に削減せよ

新しいプロダクトを開発することは、複雑な活動で、かなりの不確実性が伴う。その不確実性は大きく２種類に分けられる。

  • 目的の不確実性（「what」の不確実性）：最終的なプロダクトのフィーチャーを取り巻く不確実性
  • 手段の不確実性（「how」の不確実性）：プロダクトを開発するために用いられるプロセスやテクノロジーを取り巻く不確実性

特定の環境、あるいは特定のプロダクトでは、顧客の不確実性もあるかもしれない（「who」の不確実性）。たとえば、スタートアップ組織（新製品開発に注力する巨大組織も含む）は、その製品を使うことになる実際の顧客について、想定だけしかしていない。この不確実性を解決しなければ、素晴らしいプロダクトを間違ったマーケットに向けて構築してしまうことになる。

伝統的で順次的な開発プロセスでは、まず、最終的な不確実性をすべて排除することに注力する。何を構築するべきかを完全に事前に定義し、その後で手段の不確実性に取り組むのだ。

シンプルで直線的なこのアプローチで不確実性を減らそうとしても、プロダクト開発という複雑なドメインにはうまく当てはまらない。私たちの活動と、それを運用する環境が相互に制限し合うからだ。例を挙げよう。

  • あるフィーチャーを構築すると決める（私たちの活動）。
  • そのフィーチャーを顧客に見せる。顧客は実物を見て心変わりする。あるいは、フィーチャーについて十分説明できていなかったと気づく（私たちの活動が、環境からの反応を引き起こす）。
  • フィードバックに基づいて設計を変更する（環境からの反応によって、予期していなかった活動をすることになる。）

スクラムでは、一度に取り組む不確実性の種類をひとつに制限したりはしない。もっと全体論的なアプローチを採用して、あらゆる不確実性を同時に減らしていくことに注力するのだ（目的、手段、顧客など）。もちろん、どんなときにも最も解決したい不確実性はあるだろう。いくつもの種類の不確実性に同時に取り組むことは、イテレーティブでインクリメンタルな開発によって容易になる。これは、検査と適応、それに透明性を定常的に行うことによって導かれる。こうしたアプローチによって、折に触れて自分たちの環境を調査できるようになる。それによって、未知の未知（自分たちがそれを知らないということをまだ知らないもの）を学習できるのだ。

予見と適応 #

スクラムを用いる際には、予見したいという願望と適応の必要性との間で、常にバランスを取らなければならない。この話題に関連するアジャイルの原則を５つ説明しよう。

  • 選択肢を広げておく
  • 事前に正しく行うことは不可能だと認める
  • 適応型で探索的なアプローチを好む
  • 経済的に妥当なやり方で変化を受け入れる
  • 予見的な事前の作業と適応型のジャストインタイムの作業とのバランスを取る

選択肢を広げておく

計画駆動の開発では、要件や設計などの領域に対する重要な判断は、それぞれの工程において、決定し、レビューし、承認する。こうした意思決定が基にしている知識が限られていたとしても、次の工程に進む前にすべてを行わなければならない。

汎用的なプロセスは「今が判断すべき時だ」と主張するが、スクラムは「迅速な判断を行ってはならない」と主張する。スクラムを用いるときには、選択肢を広げる戦略を採用したほうがよい。この原則は、「最終責任時点（LRM）」と呼ばれる。つまり、コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。その瞬間はいつだろうか？それは、判断しないことのコストが判断するコストを上回ったときである。そのときになってから意思決定を行うのだ。

この原則を受け入れるために、こう考えてみよう。プロダクト開発の初日には、自分たちが何をしているかについての情報は最も少ない。開発が続くにつれて、少しずつ学習していく。それではなぜ、最も重要で、おそらくやり直しの利かない判断を初日、もしくは初期に行おうとするのだろうか？もっと情報が得られて、その情報に基づいた判断ができるようになるまで、判断を待ちたいと思う人がほとんどではないだろうか。判断に関する理解が深まれば、判断のコストは下がっていく（間違った判断をしてしまう可能性が下がる。マーケットや技術に関する確実性が増すためだ）。だからこそ、判断する前に十分な情報が得られるのを待たなければならないのだ。

事前に正しく行うことは不可能だと認める

計画駆動のプロセスが求めるのは、すべての要件と完全な計画だけではない。事前に「正しく」行えることまで想定しているのだ。だが実際には、要件をすべて集めることなどできそうもないし、そうした要件に基づいた詳細な計画を事前に立てることもできないだろう。さらに悪いことに、要件が変更されてしまうと、そのときの現実に合わせるために、基本的な要件と計画を修正しなければならなくなる。

スクラムでは、事前に正しく要件を集め、計画を立てることはできないと認めている。実際、そうすることは危険である。重要な知識が欠けているだろうし、その結果、精度の低い要件を大量に作ることになってしまう。

スクラムを用いる場合にも、ある程度は事前に要件を集め、計画を立てる。しかし、それは必要な分だけで、詳細は構築しているプロダクトの学習に合わせて埋めていく。結局、何を構築するのか、それをどうまとめるのかについて、100% 確実であると事前に考えたとしても、自分たちの成果を環境に置いてみれば、どこが本当に必要だったものと違うのかがすぐにわかる。そうした不都合な真実のせいで、変更を余儀なくさせられるのだ。

適応型で探索型のアプローチを好む

計画駆動のプロセスは、現在わかっていることを使い（あるいは調査し）、わかっていないことを予見することに注力する。スクラムは、調査を適切に行うことにより、もっと適応型で、試行錯誤型のアプローチを好む。

探索とは、何らかのアクティビティを行うことによって、知識を得ることである。たとえば、プロトタイプを構築したり、概念実証（POC）を行ったり、勉強したり、実験したりすることを指す。つまり、不確実性に向き合ったときには、調査によって情報を買うのである。

ツールやテクノロジーは、調査のコストに大きく影響する。かつては、ソフトウェアプロダクト開発の調査は高額であったため、予見的で「事前に正しくやろうとする」アプローチが好まれていた。一例を挙げよう。パンチカードを使っていたことがある。タイプライターと同じで、なにか間違えたときに修正するのは大変だった。「何が起きるかちょっと試してみよう」という考え方を受け入れるのは難しかった。「ウォーターフォール」スタイルのプロセスが現在の知識を丁寧に考慮し、不確実性がある中で先を予見して、適切なソリューションに至ろうとする試みは妥当なものだったと言える。

幸い、ツールとテクノロジーは進歩して、調査のコストは下がってきた。もはや、調査することが経済的に割に合わないということはなくなった。今日では、何かを先に構築し、それを基にユーザーのフィードバックを得て、それに適応したほうが、事前にすべてを正しくやろうとするより安上がりなことも多い。また、そのほうがよいものができる。私たちのソリューションが使われることになる環境（取り巻く技術）も、どんどん複雑化しているからだ。

スクラムでは、ソリューションに関する十分な知識が得られ、納得して意味のある一歩を踏み出せるときに、初めて前に進む。不確実性に向き合ったときには、それを予見しようとするよりも、低コストの調査を行って重要な情報を買い、その情報を基に意味のある一歩を進もうとする。こうした活動からフィードバックを得れば、さらに調査が必要かどうか、それがいつ必要なのかを判断できる。

経済的に妥当なやり方で変化を受け入れる

順次的な開発では、最初よりもあとになってからのほうが、変更のコストは明らかに高い。

一例を挙げよう。分析のときに行われた変更のコストを１ドルとする。同じ変更をあとになってテストのときに行うと、1,000 ドルかかってしまう。なぜこうなってしまうのだろうか？分析で間違いを犯し、それを分析のときに気づけば、修正するのにコストはかからない。同じ間違いが設計で見つかれば、要件だけでなく、それに基づいて行ってしまった設計も一部修正しなければならない。このようにして、各工程で失敗が積み重なる。その結果、分析のときにはすぐに直せるはずだったものが、テストや運用に入ると修正が大変になってしまうのだ。

あとになってから修正することがないように、順次的なプロセスでは要件や設計に対して注意深く統制を行い、変更を最小限に抑えようとする。このシステムは何をすべきで、それをどのように行うことになっているか、それらの予見を正確に行えるように改善するのである。

残念ながら、初期の工程で予見しすぎると、逆効果になることが多い。変更の削減に失敗するだけでなく、成果物を出すのが遅れたり、予算を超過したりすることもある。なぜこのような矛盾が起きるのだろう？第一に、各工程に対して不必要な投資をしてしまうからだ。つまり、現実的に必要ではない作業までやってしまうのである。この背景には、費用にかかる変更をなくしたいという願望がある。第二に、想定に基づいて判断しなければならないからだ。本来であれば、作業結果を関係者に見せて、フィードバックを得て、想定を検証した後に判断しなければならない。想定に基づく結果は、在庫として大量に貯まる。こうした在庫は、想定が間違っていたと判明したときに修正や破棄をすることになる。あるいは、変更（要件の追加や変化）が起きたときもそうだ。そして、変更というものは常に発生する。これは昔からある「自己成就的な予言」パターンに当てはまる。

スクラムでは、変化は常に生じると考える。プロダクト開発につきまとう不確実性は、事前にどれだけがんばっても、予見しきることはできない。したがって、変化を受け入れる準備をしなければならない。そして、その変化が起きたときには、それがプロダクト開発の後のほうだったとしても、伝統的な開発より安く対応できるようにしたいのだ。

私たちの目的は、変更コスト曲線をできる限り平坦にしておくことだ。後になってからの変更でさえも、割に合うようにしておくのである。

この目標を達成するには、プロセスにおける作業の量と流れを管理し、順次的なプロジェクトと比べて、時間の影響を変更コストに与えないようにする必要がある。

どのようなプロダクト開発のアプローチを使っても「要件に対する小さな変更は、実装に小さな変更とコストを与えるだけで済む」の因果関係を実現しようとしていることに変わりない（もちろん変更が大きくなれば、コストも大きくなるだろう）。このことは、変更がいつ発生しても、同じことが言えるようにしておくのが望ましい。

スクラムでは、多くの作業の成果物（詳細な要件、設計、テストケースなど）をジャストインタイムで作り出す。したがって、本来不要であるものが作られることはない。その結果、たとえ変更が発生しても、想定に基づいているせいで修正や破棄が必要になってしまうものははるかに少ない。このようにして、変更の量に見合ったコストを保つのである。

順次的な開発を用いると、作成物を早いうちに作り、拙速な判断をしてしまうことがある。それが原因で時間と共に在庫が増え、変更のコストが急速に大きくなっていく。その結果、伝統的な手法の転換点（線が急激に上昇し始める場所）が手前に来てしまうのだ。スクラムで開発する場合も、変更のコスト要求の大きさと見合わなくなるときにその転換点は訪れる。だが、それはもっと後になってからのことだ。

予見的な事前の作業と適応型のジャストインタイムの作業とのバランスを取る

計画駆動の開発の本質的な信念は、事前の詳細な要件と計画が必要不可欠であり、それぞれ次の工程に進む前に完了しなければならないというものだ。スクラムでは、こうした事前の作業は詳細ではなくても役に立つと考える。

スクラムでは、要件と計画を事前に正確に手に入れることはできないとする。だからといって、要件定義やプランニングの作業を事前に行わないのだろうか？そんなことはない！スクラムでは、バランスを見出そうとする。つまり、予見的な事前の作業と、適応型のジャストインタイムの作業との間でバランスを取ろうとするのだ。

プロダクトを開発するときには、経済的に妥当なやり方で、すばやいフィードバックに基づく適応の量を最大化し、事前の予見を最小化しながら、コンプライアンスや法規制、さらに企業の目的からはずれないようにしなければならない。

このバランスを取ろうとすると、プロダクトの性質や、構築しようとしているものに関する不確実性（目的の不確実性）と、それを構築する方法に関する不確実性（手段の不確実性）、開発にかかる制約などの影響を受ける。過度に予見的になろうとすると、大量の不確実性の中で多くの想定をしなければならなくなる。あまりに適応的になろうとすると、常に変化が起こる中で作業を進めなければならなくなり、作業が非効率でカオスになっていると感じるようになるだろう。革新的なプロダクトをすばやく開発するためには、適応すべきことに対して、カオスにすべり落ちていかない程度の予見をする必要がある。スクラムフレームワークは、この秩序とカオスのバランスのなかでうまく運用されているのだ。

検証による学び #

スクラムを用いるときには、検証による学びをすばやく作り出せるように作業を組み立てる。検証による学びができるのは、想定を確認したり、反証したりする知識を得たときだ。この話題に関連するアジャイルの原則を３つ挙げる。

  • 重要な想定をまず検証する
  • 複数の学習ループを並行して活用する
  • すばやいフィードバックのためのワークフローをまとめる

重要な想定をまず検証する

想定とは、推測や信念のことであり、まだ検証による学びを行っていないのに、正しいと考えられているもののことだ。計画駆動の開発は、想定が長く続くことについて、スクラムよりも寛容だ。計画駆動の開発を用いるときには、広範な要件と計画を事前に作り出す。そこには、重要な想定が多く含まれている。そうした想定は、開発のはるか終盤の工程にならないと検証されないのである。

何かを想定しているということは、開発に重大なリスクがあるということだ。スクラムでは、常に重要な想定の数を最小化しようとする。同様に、重要な想定が検証されず、長い期間残っていることがないようにする。イテレーティブかつインクリメンタルな開発を低コストの調査と組み合わせることによって、想定を早いうちに検証できるのだ。その結果、根本的に間違った想定をしたとしても、その間違いをすばやく発見し、そこから立ち直る機会ができる。計画駆動の開発で同じような間違った想定をして、検証が遅れたとしたら、開発の大部分もしくは全体が失敗してしまう。

複数の学習ループを並行して活用する

順次的な開発を用いるときにも、学習は行われる。しかし、重要な学びが得られるのは、フィーチャーを構築し、統合し、テストした後のことだ。これはつまり、開発も佳境になってから学習が行われるということだ。学習が遅れれば、その恩恵も少なくなってしまう。学習を活用する時間が十分に取れないか、活用するためのコストが高すぎるからだ。

スクラムでは、継続的な学習が成功の鍵を握っている。スクラムを用いるときには、学習する機会を増やすように、フィードバックループを活用する。こうしたスタイルを使ったプロダクト開発のパターンは、ある想定をして（あるいはゴールを設定して）、何かを構築して（何らかのアクティビティを行って）、構築したものについてフィードバックを受け取り、それを想定と比較して、自分たちが行ったことを検査するというものだ。そのうえで、自分たちが学んだことをプロダクトやプロセス、あるいは信念に適応させるのである。

スクラムでは、あらかじめ定義された複数の学習ループを活用する。たとえば、デイリースクラムは一日単位の学習ループであり、スプリントレビューはイテレーションレベルの学習ループだ。

スクラムフレームワークは柔軟なので、他のさまざまな学習ループを取り入れられる。たとえば、スクラムで定義されたものではないが、ペアプログラミング（秒単位のフィードバック）や、テスト駆動開発（分単位のフィードバック）といった技術的なプラクティスのフィードバックループもスクラム開発ではよく用いられる。

すばやいフィードバックのためのワークフローをまとめる

計画駆動のプロセスでは、想定を長い期間検証しないでいるため、学習が後回しになってしまう。したがって、すばやいフィードバックが重視されない。スクラムでは、積極的にすばやいフィードバックを得ようとする。間違った道を早く引き返すには、すばやいフィードバックが欠かせない。ごくわずかの創発的なチャンスを明らかにしてうまく活かすには、すばやいフィードバックが重要だ。

計画駆動の開発では、あらかじめ定義された工程の連続に基づき、決まったときにあらゆるアクティビティを行うことになっている。このアプローチでは、後のアクティビティからのフィードバックがなくても、前のアクティビティが完了できると想定している。その結果、何らかを行ってから、その結果に対してフィードバックを得るまで、時間がかかることになる（そのため、学習ループを閉じるにも時間がかかる）。

コンポーネントの結合とテストを例として挙げよう。ここで、３つのコンポーネントを並行して開発しているとする。ある時点でこれらのコンポーネントを結合してテストをしなければ、プロダクトを出荷することはできない。統合してみるまでは、コンポーネントを正しく構築したかわからない。統合してみて初めて、コンポーネントの開発作業についての重要なフィードバックが得られるのだ。

順次的な開発を用いた場合、統合やテストは、あらかじめ定義された下流の工程まで行われない。そこで初めて、コンポーネントの多く、あるいはすべてが統合されるのだ。残念ながら、大量のコンポーネントを並行で開発し、後の工程でひとつに統合するという考え方はうまくいきそうにない。実際、コンポーネントを開発する前にインターフェイスについてよく考えられていたとしても、統合してみると何かがうまくいかないものだ。

開発のはるか終盤になってから、フィードバックを生み出すアクティビティを行うと、不幸な副作用を生み出してしまう。別々に開発されたコンポーネントをスムーズに統合できないので、統合工程が大掛かりなテストと修正の工程になってしまったりする。この問題を修正するのにどの程度の時間とコストがかかるかは、この時点では推測するより他ない。

スクラムでは、素早くフィードバックを受け取れるようにする。フィードバックを作業の直後に行うのである。フィードバックを素早く行うことにより経済的な恩恵も受けられる。フィードバックが遅れれば、失敗が重なり、より大きな失敗につながるからだ。コンポーネントの統合の例をもう一度見てみよう。コンポーネントを設計する際には、それを統合する方法について、重要な想定を行う。こうした想定に基づき、設計を進める。この時点では、選択した設計の方法が正しいか間違っているかわからない。最善を尽くした推測でしかないのだ。

進むべき道をいったん選んだら、その選択に基づいてその他の判断を数多く行う。設計に関する元々の想定を検証するのが遅れるほど、それに依存する判断の数も増える。元々の想定が間違っていたとあとになって（統合工程のフィードバックを通じて）わかったとしても、手元には巨大なゴミが残ることになる。やり直すべき間違った判断が大量にあるだけでなく、時間が経った後でそれをやらなければならないのだ。人間の記憶は薄れるものだから、以前と同じスピードで作業ができるようになるまでには、時間がかかるだろう。

間違った判断に基づいた作業をやり直すコストに加えて、プロダクトの遅延コストを考え合わせれば、フィードバックを素早く受け取ることの経済的な恩恵はきわめて大きい。フィードバックをすばやく行えば、学習ループがすばやく閉じる。そうすれば、間違った方向に開発を進めて深刻な損害を受ける前に、その道を避けられるようになる。

仕掛中の作業（WIP） #

作業者の手待ちではなく、作業の手待ちに注目せよ

スクラムでは、作業の手待ちは作業者の手待ちに比べて、はるかにムダで、経済的に損失を与えると信じられている。作業の手持ちとは、実施したいのに何らかの原因でできない作業（構築やテストなど）である。もしかしたら、他のチームが何かを行うのを待っていて、その作業が完了するまでは自分たちの作業に着手できないのかもしれない。あるいは、やることが多すぎて、すべてを一度にできないのかもしれない。その場合、一部の作業は手が空くまで待たされていることになる。それに対して、作業者の手持ちとは、まだキャパシティに余裕があり、もっと作業ができる人のことである。

プロダクト開発を営む組織の多くは、作業者の手持ちというムダをなくすのに注力し、作業の手持ちに対してはそれほど注力しない。たとえば、伝統的な考え方によれば、テスターとして雇われた人は、時間を 100% テストに費やすことを求められる。100% を下回ったら、ムダを招いたというわけだ（テストまで手待ちをしている）。これを避けるためには、テストの作業をもっとたくさん探すことになるだろう。おそらく、複数のプロジェクトにアサインして、100% の稼働を引き出すことになる。

残念ながら、このアプローチはある種のムダ（作業者の手待ちというムダ）は減らせるが、それと同時に別の種類のムダを増やしてしまっている（作業の手待ちというムダ）。たいていの場合、作業の手待ちのコストは作業者の手待ちのコストよりもはるかに大きい。なぜ、そうなってしまうのかを考えてみよう。

この問題を説明するうえで、「作業者の稼働率を 100%」に保つ作戦をオリンピックの 100m × 4 のリレーに当てはめてみよう。「休ませない」作戦に基づくと、このレースはとても非効率に思える。お金を払って人を雇ったのに、1/4 の時間しか走っていないからだ。それ以外の時間はただ立っているだけだ。おかしいではないか！給料を 100% 払っているのだから、100% 走ってもらわなければ困る。バトンを持たせないというのはどうだろう。ずっと走り回ってもらってもよい。あるいは、隣のトラックで別のレースに出てもらってもよい。そうすれば、100% 走っていられる。

100% 走り続けさせても、金メダルを取れないとわかっている。金メダルを取るには、バトンが最初にゴールラインを超えなければならない。つまり、ここで得られる重要な教訓は、「走者ではなくバトンを見ろ」である。プロダクト開発のコンテキストにおいて「動かないバトン」に該当するのは、実行できるのに必要なリソースが割り当てられずに待ちになっている作業だ。バトンが地面にあったら、レースに勝つ（プロダクトを届ける）ことはできない（私はこのバトンと走者の比喩が大好きだ。作業を見るべきであって、作業者を見るべきではないということを、実にうまく説明している。しかし、あらゆる比喩がそうであるように、この比喩にも限界はある。この場合、作業を手渡すというリレー競走型のアプローチは、伝統的なプロダクト開発のようでもある。そういう開発を私たちは避けたいと思っているのに！）。

稼働率を 100% に維持した結果については、誰もが知っている。コンピュータを 100% で動作させたら何が起きるだろう？調子が悪くなって、そのコンピュータ上のあらゆるジョブが遅くなるはずだ。言い換えれば、コンピュータが実行する作業が増え、生産性が悪くなってしまうのだ。一度その状態になってしまうと、そこから抜け出すのは非常に難しい（ジョブを殺すか、マシンを再起動しなければならない）。稼働率を 80% 程度で実行させたほうが、はるかに効率的になる。

作業の手待ち（遅延した作業）は、いったん高稼働率になると、指数関数的に積み上がっていく。作業の手待ちのコストは非常に高く付き、作業者の手待ちの何倍にもなる。したがって、スクラムは誰かの稼働率を 100% にしておくよりも、作業の流れの中でボトルネックを見つけ、そのボトルネックを削減するという、経済的に意味のあるアクティビティに注力する。

第４章：スプリント #

（省略）

第５章：要件とユーザーストーリー #

（省略）

第６章：プロダクトバックログ #

（省略）

第７章：見積もりとベロシティ #

（省略）

第８章：技術的負債 #

（省略）

第２部：役割 #

第９章：プロダクトオーナー #

概要

プロダクトオーナーとは、プロダクトの統括を認められた中心的な存在であり、スクラムチームを構成する３つの役割のうちのひとつである（その他の２つは、スクラムマスターと開発チーム）。

プロダクトオーナーは少なくとも２つの方向に同時に目を向ける必要がある。

まずは、組織内のステークホルダー、顧客、ユーザーが持つニーズや優先順について、彼らの代理として行動できるくらい深く理解しなければならない。この意味では、プロダクトオーナーはプロダクトマネージャーとして行動し、正しいソリューションが開発されていることを保証するのである。

次に、開発チームに何をどの順番で構築するのかを伝えなければならない。それから、機能が完成しているかどうかを判断できるように、受け入れ条件を明確にして、その上限を満たすテストが実行されるようにしなければならない。プロダクトオーナーが詳細レベルのテストを書くことはないが、どうすればそのフィーチャーが完成したと言えるのかがチームに分かるように、抽象的なテストは書くようにする。つまり、プロダクトオーナーはビジネスアナリストであると同時に、テスターでもあるということだ。

主な責任

  • 経済性の管理
  • プランニングへの参加
  • プロダクトバックログのグルーミング
  • 受け入れ条件の定義と検証
  • 開発チームとの協力
  • ステークホルダーとの協力

求められる特性とスキル

  • ドメインスキル
  • 対人スキル
  • 意思決定力
  • 説明責任力

誰がプロダクトオーナーになるべきか？

プロダクトオーナーを誰がやるかは、開発や組織の種類によって異なる。次は開発の種類に応じたプロダクトオーナーの候補である。

  • 社内開発：開発の恩恵を受ける部門から任命された人がプロダクトオーナーになるべきである。たとえば、IT 部門がマーケティング部門のシステムを開発する場合、マーケティングチームの人がプロダクトオーナーになる。
  • 商用開発：社外の顧客にプロダクトを販売する商用開発では、実際の顧客の声を代弁する社員がプロダクトオーナーになる。これはプロダクトマネジメントやプロダクトマーケティングの役職にいる人が担当することが多い。
  • 外部委託開発：A 社が B 社にソリューション開発を依頼する外部委託開発では、A 社の代表がプロダクトオーナーになる。プロダクトオーナーはソリューションに対価を支払って恩恵を受ける側の会社にいなければならない。
  • コンポーネント開発：ソリューション全体ではなく一部分だけを作るコンポーネントチームを設置している組織もあるだろう。こうしたチームは再利用可能なコンポーネントやアセットなどを開発し、他のチームが顧客にソリューションを届けるための支援をしている。技術コンポーネントに注力しているので、バックログの優先順位を決定できる技術志向の人がプロダクトオーナーになる。

第１０章：スクラムマスター #

概要

スクラムマスターとは、スクラムチームを構成する３つの役割のうちのひとつである（その他の２つは、プロダクトオーナーと開発チーム）。プロダクトオーナーは正しいプロダクトを作ることに集中する。開発チームはプロダクトを正しく作ることに集中する。スクラムマスターは、スクラムの価値、原則、プラクティスがみんなに正しく理解され、受け入れられるようにする。スクラムマスターは、開発チームとプロダクトオーナーのコーチのように振る舞う。また、スクラムチームや組織が自分たちに適したパフォーマンスの高いスクラム手法を開発できるように、プロセスのリーダーとして支援する。

主な責任

  • コーチ
  • サーバントリーダー
  • プロセスの権威者
  • 防御壁
  • インペディメントの除去
  • チェンジエージェント

求められる特性とスキル

  • 博識
  • 質問力
  • 辛抱強い
  • 協力的
  • 保護力
  • 透明性

誰がスクラムマスターになるべきか？

スクラムを始めたばかりの組織には、スクラムマスターという役割が存在しない。どこでスクラムマスターを探せばいいのだろうか？プロジェクトマネージャーやプロダクトマネージャーがスクラムマスターになることもある（ただしプロダクトマネージャーはプロダクトオーナーになりやすい）。開発やテストなどの技術的なバッググラウンドを持つ人がスクラムマスターになることもある。前述した特性を持っていて、スクラムマスターの責任を果たそうという人であれば、優秀なスクラムマスターになれるだろう。

テクニカルリードや開発リーダーがスクラムマスターになるべきだという組織もある。確かに優秀なスクラムマスターになれるかもしれないが、スクラムマスターの役割が最適とは言えないだろう。技術的リーダーというのは、技術的に優れているからその立場にいるのである。スクラムマスターは技術的な卓越性を最大限に活かせる役割ではない。つまり、技術的リーダーがスクラムマスターの仕事をしている時間は、技術的なリーダーシップが損なわれている時間になるのである。そうなれば、技術的な成果に悪影響を及ぼすことになるだろう。

機能エリアマネージャーやリソースマネージャーは、スキルさせあればスクラムマスターとして成功できる可能性がある。そうしたマネージャーから人のマネジメントの責任が、少なくともスクラムチームメンバーに対する責任がなくなれば最高だ。スクラムマスターにはマネージャーとしての権限がないので、チームメンバーにとって今はスクラムマスターの帽子をかぶっているのか、それともマネージャーの帽子をかぶっているのかがわかりにくい。こうした状況は避けるべきだ。チームメンバーがスクラムマスターに報告するのは好ましくない。

有能な人であれば、スクラムマスターと開発チームメンバーを兼任できるだろう。しかし、この組み合わせは利害関係の衝突に悩まされることになる。たとえば、スクラムマスターの重要なアクティビティ（インペディメントの除去など）と最重要なタスクレベルの作業がある場合、どうすればいいだろうか？いずれも重要な仕事なので、中途半端にやるとスクラムチームの有効性が損なわれてしまう。

スクラムマスターとプロダクトオーナーを兼任するのはやめたほうがよい。スクラムマスターはスクラムチームのコーチである。つまり、プロダクトオーナーにスクラムをコーチするのがスクラムマスターである。自分自身をコーチするのは難しい。さらには、プロダクトオーナーはプロダクトの責任者であり、チームに要求を出す存在でもある。スクラムマスターは、プロダクトオーナーの要求と開発チームのニーズや能力バランスを取る役割だ。プロダクトオーナーとスクラムマスターを兼任すると、不要な混乱を招くことになるだろう。

第１１章：開発チーム #

概要

従来のソフトウェア開発手法は、アーキテクト、プログラマ、テスター、データベース管理者、UI デザイナなどのさまざまな職種を定義している。それに対してスクラムでは、開発チームという役割を定義している。これは上記の職種を機能横断的にまとめたものだ。開発チームはスクラムチームの３つの役割のひとつである。開発チームのメンバーは、プロダクトオーナーが要求したビジネス価値を届けるためのスキルをチーム全体として保持している。

開発者以外もいるのに開発チームというラベルを使うのは適当ではないと思われるかもしれない。デリバリーチーム、設計・開発・テストチーム、あるいは単にチームと呼ばれたこともある。どのラベルが適当かは明らかではないが、今のスクラムコミュニティでは開発チームを使うことになっている。

多くの組織では、仕事の役割別にチームを分けている。たとえば、デザイナのチーム、開発者のチーム、テスターのチームといった具合だ。こうしたチームは、完成した成果を次のチームに手渡すことになる。程度の差はあるが、それぞれが独立して機能しているからだ。

スクラムでは、動作するプロダクトをスプリントごとに開発する。開発チームは必要な作業をすべて行わなければならない。そこには機能の設計、開発、統合、テストなどが含まれる。したがって、こうしたスキルをすべて備えたチームが必要になる。できるだけ機能横断的なチームにしたほうがよい。仕事を役割別のチームに割り振るというのは、スクラムの成功にとって深刻なインペディメントになる可能性が高い。

主な責任

  • スプリントの実施
  • 日々の検査と適応
  • プロダクトバックログのグルーミング
  • スプリントプランニング
  • プロダクトとプロセスの検査と適応

求められる特性とスキル

  • 自己組織化
  • 機能横断的な多様性と十分な能力
  • T 字型スキル
  • 銃士の姿勢（ひとりはみんなのために、みんなはひとりのために）
  • 広域帯のコミュニケーション
  • 透明なコミュニケーション
  • 適切な規模
  • 集中とコミットメント
  • 持続可能なペースで仕事する
  • 長寿

第１２章：スクラムチームの構成 #

（省略）

第１３章：マネージャー #

（省略）

第３部：プランニング #

第１４章：スクラムのプランニングの原則 #

（省略）

第１５章：さまざまなレベルでのプランニング #

（省略）

第１６章：ポートフォリオプランニング #

（省略）

第１７章：エンビジョニング（プロダクトプランニング） #

（省略）

第１８章：リリースプランニング（長期計画） #

（省略）

第４部：スプリント #

第１９章：スプリントプランニング #

概要 #

プロダクトバックログは数週間から数ヶ月かかる作業を表していることもあり、短期間のスプリントでは完成しない場合も多い。したがって、スプリントで構築する最も重要なプロダクトバックログアイテムを決定するために、スクラムチームはスプリントプランニングを実施するのである。スプリントプランニングでは、スプリントゴールについて合意する。開発チームは、スプリントゴールに合致しており、スプリント終了までに現実的にデリバリーできるプロダクトバックログアイテムを決定する。決定したアイテムをきちんとデリバリーできるという自信を持つには、プロダクトバックログアイテムを完成させるための計画を立てる必要がある。選択したプロダクトバックログアイテムと計画を合わせたものがスプリントバックログになる。

スプリントプランニングでは、スクラムチーム全員が協力する。プロダクトオーナーは、最初のスプリントゴールを共有して、プロダクトバックログの優先順位を示し、プロダクトバックログアイテムに対するチームの疑問に答える。開発チームは、スプリントで何をデリバリーできるかを決定し、現実的なコミットメントをする。スクラムマスターは、スクラムチームのコーチとしてプランニングアクティビティを観察し、内省をうながす質問をして、確実によい成果が得られるように支援する。スクラムマスターは開発チームではないので、何を作るかを代わりに決めることはできない。スクラムマスターができるのは、チームのコミットメントに問題を提起して、現実的で適切なコミットメントができるようにすることである。

スプリントプランニングの手法 #

スプリントプランニングでは、チームでスプリントゴールを達成するための計画を立てる。ほとんどのチームはスプリントバックログを作成する。これはプロダクトバックログアイテムとそれに関連するタスクと見積もり作業時間を一覧にしたものだ。タスクレベルの完全な計画（スプリントのプロジェクト計画に相当する。ガントチャートで表現されることが多い）を作ることも可能だが、そこまですることを経済的に正当化するのは難しい。

第一の理由として、５〜９人しかいないチームの作業管理にガントチャートがわかりやすいとは思えないからだ。第二の理由は、たとえガントチャートを作ったとしても、仕事が始まるとすぐに不正確になってしまうからだ。スプリントの実施こそが重要である。実際に何かを構築したりテストしたりすることによって、本物の学習が可能になる。こうした学習は、初期段階では万全だった計画を無効にする。その結果、チームはムダな計画に貴重な時間を費やすだけでなく、さらにその計画を変更するというムダなことをしなくてはならないのである。

もちろん、タスクに依存関係があるときは、事前の計画が役に立つこともある。たとえば、２日間のストレステストを実行するとわかっているなら、スプリントの実施が終わる少なくとも２日前には、対象となる機能を完成させておくだろう。

スプリントプランニングの手法を２つ説明しよう。二部構成のスプリントプランニングと一部構成のスプリントプランニングだ。

二部構成のスプリントプランニング

まずはスプリントプランニングを二部構成に分ける手法だ。パート１（what のパート）では、開発チームのキャパシティを決定し、スプリントの終了時にデリバリーできるプロダクトバックログアイテムを予想する。たとえば、40ストーリーポイントを達成できると思ったら、40ストーリーポイント相当を選択する。

パート２（how のパート）では、パート１で予想したアイテムを、自身を持って完成できるように計画を立てる。ほとんどのチームは、プロダクトバックログアイテムをタスクに分解して、タスクの完了に必要な工数（作業時間）を見積もり、この計画を立てている。そして、見積もったタスクの時間とキャパシティを比較して、最初のコミットメントが現実的かどうかを確認する。

選択したアイテムが多すぎたり少なすぎたり、何らかの制約で開発が現実的ではなかったりするときは、予想を調整するか、場合によってはスプリントゴールをキャパシティや制約に合わせて変更する。チームの予想がキャパシティの範囲や制約に収まれば、コミットメントを最終決定して、スプリントプランニングを終了する。

一部構成のスプリントプランニング

スプリントプランニングのもうひとつの手法は、アイテムの選択とそのための自信の獲得を交互に行うものである。こちらのほうがよく見かけるように思う。

まずは、開発チームがキャパシティを決定する。キャパシティの許容量によっては、スプリントゴールを調整する必要があるかもしれない。次に、プロダクトバックログアイテムを選択して、それがスプリントに収まるという自信を持つ。

これをチームのキャパシティの上限に達するまで続ける。最後にコミットメントを最終決定して、スプリントプランニングを終了する。

キャパシティの決定 #

スプリントプランニングの最初の重要なアクティビティは、スプリントにおけるチームのキャパシティを決めることである。キャパシティを把握すれば、スクラムチームが何をデリバリーできるかを決めるときの指針になる。

キャパシティとは？

ここには、スプリント以外のアクティビティに必要な時間、スプリント以外のコミットメント、個人的な休暇、必要なバッファが含まれる。

たとえば、スプリントが２週間（10日間）だったとしよう。チームは10日間すべてをスプリントの実施に使えるわけではない。そのことを最初に受け入れなければならない。たとえば、２週間のスプリントであれば、スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブなどのアクティビティに約１日を確保しておく。また、プロダクトオーナーのグルーミング（プロダクトバックログアイテムの記述、洗練、見積もり、優先順位付け）の支援に最大10%の時間を確保して、プロダクトバックログアイテムが準備完了になるようにする。

チームはスプリント以外の作業（プロダクトのサポート、他のプロダクトの保守、現在のスプリントとは関係のない仕事）にどれだけの時間を確保するかを決めなければならない。プロダクトバックログアイテムの作業に１日８時間のすべてを費やすことはできない。このことを覚えておきたい。組織の中でうまく生きていくには、オーバーヘッド（会議の参加、メールの返信、割り込みなど）が必要である。

次に、個人的な休暇についても把握する必要がある。これがチーム全体のキャパシティを低下させるからだ。

スプリント以外のスクラムのアクティビティ、スプリント以外の仕事、個人的な休暇を除いた後に残るのが、今回のスプリントでプロダクトバックログアイテムにかけることができるチームのキャパシティである。ただし、計画どおりにいかないときのために、別途バッファを確保しておくべきだ。たとえば、見積もりは決して正確にはならず、想定よりも少しだけ大きくなってしまうことがある。あるいは、見積もりが間違ってしまう可能性もある（その可能性が高い）。予期しない問題のためには、バッファを用意しておくのが懸命だ。

バッファサイズを決めるときには、さまざまな手法が使用できる。実際には、スプリントを何度か実施してみて、開発の不確実性に必要なバッファの量を理解した後に、経験的にバッファサイズを決定する。

バッファが決まったら、スプリントで作業を完了させるキャパシティが決まる。

ストーリーポイントを使ったキャパシティ

チームのベロシティは、プロダクトバックログアイテムの単位（たとえば、ストーリーポイント）で表す。したがって、キャパシティをストーリーポイントで表せば、次のスプリントのベロシティも予測できる。

スプリントのキャパシティを決めるときには、チームのこれまでの平均ベロシティや前回のスプリントのベロシティを参考にする（これを「昨日の天気」と呼ぶこともある）。そして、今回のスプリントとの違いを考慮する（違いはないかもしれない）。その結果が、調整後のキャパシティ（予測したベロシティ）となる。

たとえば、２週間のスプリントにおけるチームの平均ベロシティが、40ストーリーポイントだったとしよう。計画中のスプリントは、米国で12月の後半に実施する。つまり、チームメンバーの多くが冬休みに入るということだ。ベロシティを40のままにすると、仕事が多すぎるということになる。チームの現実的なキャパシティを考えると、今回のスプリントのベロシティは20程度にするとよいだろう。

プロダクトバックログアイテムの選択 #

スプリントプランニングの手法を選んでも、コミットメントに含めるプロダクトバックログアイテムを選択する必要がある。選択の方法はいくつかある。スプリントゴールがあれば、それに合わせてプロダクトバックログアイテムを選択する。スプリントゴールがなければ、プロダクトバックログの優先順位の高いほうから順番にアイテムを選択する。スキルの問題などでアイテムにコミットできないときは、優先順位がその次に高くて実現できそうなプロダクトバックログアイテムを選択する。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のある小さなアイテムに分割するか、完成できそうな別のアイテムに着手する。準備完了の定義を用意しておけば、定義やリソースが不十分だったり、依存関係が解決されていないプロダクトバックログアイテムを選択したりして、スプリントで完成できなくなるのは回避できる。

「完成できそうなものだけを開始する」というルールは、WIPの制限や未完成作業のムダの原則に基づいている。未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

第２０章：スプリントの実施 #

概要 #

スプリントの実施は、それ自体がひとつのミニプロジェクトのようなものだ。つまり、出荷判断可能なプロダクトインクリメントをデリバリーするために必要な作業をすべて行う。

スプリントの大部分はスプリントの実施が占めている。スプリントプランニングが終わった後に開始して、終了したらスプリントレビューを開始する。

２週間のスプリントであれば、10日間のうち約8日間をスプリントの実施が占めることになるだろう。

スプリントの実施では、開発チームのメンバーが自己組織化して、スプリントプランニングで設定したゴールを達成する最善の方法を決める。

スクラムマスターは、コーチ、ファシリテーター、インペディメントの排除担当者など、チームが成功するためなら何でもやる役割として参加する。スクラムマスターが作業のやり方を教えたり、作業をチームに割り当てたりすることはない。自己組織化されたチームは、そうしたことについて自分たちで考えるのである。

プロダクトオーナーは、スプリントの実施のときに質問に答えたり、途中の成果のレビューをチームにフィードバックしたり、必要に応じてスプリントゴールの調整をしたり、プロダクトバックログアイテムが満たすべき受け入れ条件を検証したりする。

第２１章：スプリントレビュー #

スプリントの終了時に、チームは２つの重要な検査と適応のアクティビティを行う。スプリントレビューとスプリントレトロスペクティブだ。スプリントレビューはプロダクトに集中したものである。一方のスプリントレトロスペクティブは、チームがプロダクト構築するときに使ったプロセスに注目したものである。

概要 #

スプリントプランニングでは作業の計画を立てる。スプリントの実施では作業をする。スプリントレビューでは作業結果（出荷判断可能なプロダクトインクリメント）の検査（と適応）をする。スプリントレビューはスプリントの実施の直後、スプリントレトロスペクティブの直前になる。

スプリントレビューは、プロダクト開発のインプットに関わった人に対して、これまでに構築したものについて検査と適応をする機会を提供するものである。不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。質問をしたり、観察や提案をしたり、現状を考慮して今後の方針について議論したりする時間である。

スプリントレビューは、スクラムチームに対して、スプリントの実施に毎日参加できないような人たちからのフィードバックを得る重要な機会を提供するものである。スプリントレビューは、スプリントで作成された成果について議論する最初の機会である。したがって、スプリントレビューにはすべての利害関係者が参加するべきである。

スクラムチームのメンバー（プロダクトオーナー、スクラムマスター、開発チーム）は、すべてのスプリントレビューに参加すべきである。何が達成できたかを説明し、質問に答え、直接フィードバックを得るためである。

ビジネスエリアオーナー（開発中のシステムの発注者）、エグゼクティブマネジメント、リソース担当マネージャーなどの内部ステークホルダーも参加するべきである。チームが経済的に合理性のある成果に向かっているかを確認するには、彼らのフィードバックが必要不可欠だ。スプリントレビューはプロダクト開発の現状を把握するよい機会である。内部向けの開発の場合はユーザーも内部にいるので、専門家と一緒にユーザーの代表を参加して、有益なフィードバックを提供すべきである。

他にも参加したいという人がいるだろう。営業やマーケティングもスプリントレビューに参加して、プロダクトが市場で成功するかどうかの有益なフィードバックを提供している。サポートや法務などの部門も、チームの進捗を把握したり、タイムリーなインプットを提供したり、自分たちの仕事をいつ開始すればよいかを判断したりするために、スプリントレビューに参加することもある。

他の開発チームが代表者を派遣することもある。プロダクトがどこへ向かっているのかを確認して、現在の開発に影響する自分たちの作業に関連したインプットを提供する。

定期的に外部ステークホルダーにも参加してもらうとよい。たとえば、チームが開発しているプロダクトの顧客やユーザーである。そうすれば、内部ステークホルダーからの間接的な（代理人を介した）フィードバックではなく、直接的なフィードバックを受け取れる。ただし、内部ステークホルダーの議論だけで済むのであれば、外部ステークホルダーに参加してもらう必要はないかもしれない。外部ステークホルダーに参加して貰う場合は、招待すべき顧客やユーザーについて検討しなければならない。誰かを招待するときには、常識だけではなく熱意や人格も考慮するとよいだろう。

第２２章：スプリントレトロスペクティブ #

概要 #

スプリントレトロスペクティブが重苦しい儀式的なプロセスだとは思わないでほしい。スクラムチームが集まって、以下のようなことを話し合うだけの単純なものである。

  • KEEP：スプリントでうまくいったので、今後も続けたいことは何か？
  • PROBLEM：スプリントでうまくいかなかったので、今後は中止したいことは何か？
  • TRY：これからやったほうがよいこと、改善したほうがよいことは何か？

こうした議論に基づいて、チームメンバーは行動可能な変更点を決める。そして、インクリメンタルに改善したプロセスで次のスプリントに取り組むのである。

スプリントレトロスペクティブはプロセスをふりかえる時間なので、スクラムチーム全員の参加が必要だ。ここには、開発チームのメンバー、スクラムマスター、プロダクトオーナーが含まれる。

スクラムチーム以外のステークホルダーやマネージャーなどは、スクラムチームに招待されたときにだけレトロスペクティブに参加すればよい。透明性はスクラムの中心となる価値だが、スクラムチーム以外のメンバーが定期的にレトロスペクティブに参加できるほどの安全レベルを達成できている組織は、現実的にはそう多くない。外部から圧力をかけられずに、オープンで正直な議論をするには、チームメンバーは安全だと感じなければならない。外部の参加者がいることで、チームが実際の問題を口にしても安全だと感じられなければ、レトロスペクティブの効果は失われてしまうだろう。

第２３章：未来へ #

開発にスクラムを用いたがっている人が、いかにスクラムを使い始める準備ができていないかを語り始めるというのはよくある。スクラムアプローチの詳細について、考えきれていないというのだ！おかしな話だ。この種の考え方は、スクラムの本質的な原則とまったく合っていない。

スクラムを採用するときには、事前に物事を完璧にしなければならないと心配してはならない。そんなことはできないのだ！さらに、事前に完璧にしようとすると、当てずっぽうをしなければならなくなる。その場合、スクラムを適用して何が起きたかを見ることでしか得られない重要な学びが得られなくなるのだ。経験上、たいていのチームの最初の２回程度のスプリントは、うまくいかない。それでよいのだ。私がスクラムチームに対して望むのは、次のスプリントでは、前のスプリントよりもよくなってほしいということだけだ。だから、始めるのを遅らせてはならない。今の時点で、スクラムをどう使うのかわかっていると思っていても、次のスプリントをやりきった後になって、どれだけのことがわかるかを想像してほしい。

同じように、スクラムを適用するときに問題が起きないと考えないでほしい。どこかの時点で、あなたの組織がスクラムの実施を難しくするインペディメントに行きあたることは間違いない。スクラムによって、組織が真の実力を発揮するのを妨げる機能不全やムダが可視化される。しかしスクラムは、そうした課題をどう解決すればよいかは教えてくれない。その難題は、組織の中にいる人にゆだねられるのだ。

現状維持をしたいという考え方は強い力を持つ。スクラムを無視したりスクラムを変更したりするほうが、長いこと続いてきた組織のプロセスやルール、振る舞いを変えるよりもたやすいのだ。また、自身の機能不全を見せつけられることに対して徹底的に敵対する文化のせいで、隠れた問題を明るみに出してくれる光が消されてしまう。この傾向に対抗するためには、組織を変革するために確固たる信念を持って辛抱強く立ち向かわなければならない。変革に対する抵抗は自然なものだということを理解しよう。スクラムに根ざす原則と、達成しようとしている目標について他の人を教育し、最悪の事態を避けるようにしよう。反対する人たちとぶつかるのではなく、協力しあうことによって、障害を取り去ろう。そうすれば、チーム、プロダクト開発活動、組織が、スクラムの実践の恩恵を十二分に理解できるようになるのだ。