なんちゃってスクラムから本物スクラムに移行するために【スクラムガイドを読む】

「私どもは、アジャイルをしています。スクラムチームもあります」

クライアントから、こう説明されることがある。
「スクラムは既にできているから、全社的にスケールするために支援して欲しい」という依頼である。

こういったケースでは、まず1番進んでいるチームを見せてもらう。

だが。。残念ながら、本当にスクラムができているケースは全体の2割程度だ。。

今回は、スクラムの公式ガイドを基準に、「大抵できていない」ところを説明していこう。

スクラムガイドは黒太字で転記し、私の解釈と考えは青字で示している。

スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・イベント・作成物・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。

毎日朝会をしているから、アジャイルをしているとは言えない。
本当にスクラムをするなら、スクラムイベントを漏れなく行わなくてはならない。

スクラムイベントは、５つある。

スプリント
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ

加えて、プロダクトバックログリファインメントも継続的に行う（いつどのようにするかはスクラムチームが決定する）。

スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。

スクラムチームには、3つの役割がある。

プロダクトオーナー
開発チーム
スクラムマスター

繰り返しになるが、スクラムイベントは次の5つだ。

スプリント
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ

スプリントを除く、残り4つのイベントは、スクラムの「検査」と「適応」を促す公式イベントである。スプリントは4つの公式イベントを含むコンテナの役割を果たす。
「公式」と言っているのは、スクラムになるために最低限必要ということである。スクラムイベントを、追加で非公式に開催しても構わない。

例えば、デイリースクラムなら朝会に加え、夕会を追加してもいい。プロダクトインクリメントも、できたモノから順番に、非公式なデモ会を開催してもいい。早めに見てもらい、フィードバックを募る。ふりかえりもしかり。毎日したって構わない。

経験主義のスクラムでは、経験的プロセスをグルグル回す。スクラムの検査と適応は、経験的プロセスのメカニズムだ。スプリント単位で、スクラムイベントを最低1回ずつ回すこと（デイリースクラムは24時間サイクルで一回だ）。

スクラムの作成物は、３つ。

プロダクトバックログ
スプリントバックログ
インクリメント

ルール

スクラムの作成物の透明性を確保すること。
作成物の透明性が不完全だと、スクラム本来の価値が得られない。
完成を定義すること。
プロダクトインクリメントが完成するということは、どのような状態になることか、完全に明らにし、スクラムチーム全員で合意すること。

なにか一つでも欠如している場合、スクラムをしているとは言えない。

スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。

具体的に、開発チームは9名以内であること（6名±3名）。12~13人のメンバーは多すぎる。人数が2桁になるなら、減らそう。どうしても必要なら、2チームにしよう。
メンバーがコンポーネント毎に固定化されており、分業制で作業しているなら、スクラムではない。

スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。

スクラムの経験的プロセスは「検査」と「適応」である。毎スプリント「検査」と「適応」プロセスを繰り返すことで、経験主義を体現する。だから、スクラムイベントをスキップしたらスクラムにならない。

しばしば目にするのが、ふりかえりをスキップしている、または時々スキップするケースだ。「割り込み作業があるから」「スコープ達成圧力が強いから、時間がない」は言い訳にしかならない。
経験的プロセスを回すことは、スクラムの肝である。スプリント毎に最低1回ふりかえる。

経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
例：
• プロセスの用語を参加者全員で共有している。
• 作業する人とそのインクリメントを検査する人が「完成」の定義を共有している。

「検査」と「適応」の経験的プロセスを回すにあたり、あらゆる状態が完全に透明でないといけない。プロダクトインクリメントやプロセスを検査し、問題がないか判断する。インクリメントやプロセスが不透明であれば、判断を誤る。判断を誤ると、適応が不十分になる。インクリメントはどんどん逸脱し、リスクはどんどん高くなる。

「検査」と「適応」の経験的プロセスを頻繁に回し、課題が小さい内に対処するのがスクラムである。リスクや逸脱を早めに特定し、正しい改善策を導くには、現場の状態をリアルに見える化することが不可欠だ。

経験的プロセスを回し、スクラムの価値を享受するには、あらゆるモノが完全に透明でないといけない。「透明性」が完全であるとき、判断の精度が十分に高まり、「検査」と「適応」が正しく行われる。

スクラムチームが、確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬（respect）の価値基準を取り入れ、それらを実践するとき、スクラムの柱（透明性・検査・適応）は現実のものとなり、あらゆる人に対する信頼が築かれる。

スクラムを活用するには、これらの5つの価値基準を上手に実践しなければいけない。個人は、スクラムチームのゴールの達成を確約しなければいけない。スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。全員が、スプリントの作業とスクラムチームのゴールに集中しなければいけない。スクラムチームとステークホルダーは、すべての仕事とそれらを遂行する上での課題を公開することに合意しなければいけない。スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。

経験的プロセスの「検査」と「適応」。そして「検査」と「適応」を精緻化する状況の「透明性」。これがスクラムの3本柱である。

この3本柱を実現するために、不可欠な5つの価値基準がある。順番に説明しよう。

確約：コミットメントとは、周りから強要されるものでなく、スクラムチームが、主体的に、自ら課すものである。コミットするのはスクラムチームのゴールを達成するためにベストを尽くすこと。プロセスを改善し、自分達の進め方を最適化していくことを指す。スプリントのバックログ全量（スコープ）をコミットしている訳ではない。ゴール達成のために、全力を尽くすコミットメントがあるか。
勇気：組織的、人的、システム的、文化的に制約があったり、既存の進め方と異なるとき反発がある。だが、チームは恐れることなく、ゴール達成のために正しいことをする勇気があるか。
集中：メンバー全員が一枚岩となって、チームゴールを達成するため、作業に集中・専念しているか。
公開：作業に関わる懸念事項や課題を隠さない。常にオープンな姿勢を貫いているか。
尊敬：（チームとして作業するが、依存するのではなく）チームの同僚を、高い能力を有する個人として尊敬しているか。

欠けているものがあれば、スクラムはできていない。

スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。

スクラムチームは、自ら思考し、計画し、実行し、反省し，学び、改善していく。指示されて動くのはスクラムではない。
スクラムチーム内にヒエラルキーがある場合、スクラムになってない。
プロダクトオーナーと開発チームは対等である。
開発チーム内にもヒエラルキーはない。スクラムマスターも開発チームに指示してはいけない。

プロダクトオーナーと開発チームが対等な立場でないケースがある。組織上、プロダクトオーナーが本部長や事業部長だとしても、スクラムの役割上、立場は対等である。プロダクトは、リリースした後も、利用者のニーズを取り込み進化していく。将来的な機能拡張性や保守性も含めた正しいつくり方を知っているのは開発チームである。最新のテクノロジーを知っているのも開発チームである。正しくつくる説明責任は開発チームにあるから、ソリューションは開発チームが決める。

開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。

働き方について、開発チームは、組織から権限をエンパワメントされている。
作業方法をプロダクトオーナーやスクラムマスターに相談しているなら、スクラムとは言えない。

機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。

組織の他の部署やチームに作業を依頼（依存）しなくてはインクリメントが完成できないなら、スクラムチームではない。
開発チームはフィーチャーチームでなくてはならない。

スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。

スクラムマスターは上から仕切るのではなく、下から支える、縁の下の力持ちである。
朝会でスクラムマスターが一番話している（目立っている）なら、スクラムはできていない。

組織へのスクラムの導入を指導・コーチする。

母体組織へのスクラム導入を主導するのはスクラムマスターの仕事である。組織のスクラムの理解が進めば、開発チームも助かる。
従来型の組織では、要求分析、要件定義、設計、開発、テスト、品質保証、リリース管理の各機能が担当者ごとに分離されている。
スクラムマスターは、組織のスクラム化に向けて、必要な変更を推進する。

プロダクト開発を、「滝モデル」から「反復的・漸進的に届けるモデル」に変更する
「ドキュメント駆動」から「対話駆動」へのアプローチに変更する
機能単位の「コンポーネントチーム」から顧客バリューチェーン単位の「フィーチャーチーム」に変更する

これらの変更を、組織を変える権限のあるマネジメント層に粘り強く訴え、協力を獲得する。
（この領域の支援は、外部コーチの使いどころでもある。）

スクラムマスターが、開発チームの世話しかしていない場合、スクラムではない。

他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。

毛利家の三本矢の教えではないが、一本の矢は簡単に折れるが、束になると折れない。
スクラムマスター達が一丸となって、組織のスクラム化を推進しよう。

すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。

朝会は15分以内で終える。
スクラムイベントもタイムボックス内に収める。

スクラムガイドのタイムボックスは最大の時間である。目的を達成したら、速やかに終える。

スプリントを開始すると、その期間は固定され、増減することはできない。

スプリント期間は固定である。
2週間スプリントなのに、3週間～4週間に延長しているケースを見かける。スクラムではない。スクラムでは、タイムボックスを重視し、スコープで調整をかける。

スプリント以外のスクラムイベントは、何かを検査・適応するための公式な機会である（スプリントはその他のイベントの入れ物である）。これらのイベントは、非常に重要な透明性と検査の両方が実現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の多くの機会を失う。

スクラム公式イベントは全て実施する。チームの負担にならない範囲で、頻度を増やすことは構わないが、実施しないとスクラムではない。

「ふりかえり」まで行う事。
日常的な作業は、計画・実行・チェックで終わる。
スクラムの良さは、プロセスに「ふりかえり」がデフォルトで組み込まれていることだ。
計画・実行・チェック・ふりかえりの4ステップまとめてワンクールである。スプリント毎に「ふりかえり」を徹底する。

スプリントの期間は1か月以内に制限されている。スプリントが長すぎると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくとも 1か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも1か月分のコストに収まるようになる。

過去に6週間のイテレーションで回していたチームがあった。最大1ヶ月までのスプリントをスクラムと言う。
ちなみに、期間が長くなるとプロダクト（コード）をシンプルに保つハードルが高くなる。スクラムを初めてするなら、1週間スプリントがオススメである。

プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チームだけである。

プロダクトオーナーがスプリントスコープを決めてはいけない。
作業量を決めるのは開発チームである。

スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとして、どのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない。

スプリントプランニングのトピック2（後半）にもプロダクトオーナーに参加してもらう。トピック1（前半）で選択したプロダクトバックログアイテムにトレードオフが生じた際、プロダクトオーナーが不在だと困る。

デイリースクラムは毎日、同じ時間・場所で開催し、複雑にならないようにする。

デイリースクラムは、スクラムの公式イベントであり、毎日行う。週2～3回とか、必要に応じて開催なら、スクラムではない。
スクラムは、24時間サイクルでスプリントゴールの達成状況をチェックし、計画を最適化する。

開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。

進捗管理は開発チームの仕事だ。毎日ゴールに近づいていることをチェックするのは、開発チームである。
1～2週間で完成品までもっていく。朝会で進み具合をチェックすることはマストだ。

デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する。

プロダクトオーナーや利害関係者が朝会で発言しているケースがあるが、スクラムではない。

スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。
グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。

スプリントレビューで行うのは、プロダクトインクリメントのデモだけではない。次のスプリントで実装するプロダクトバックログアイテムについて、関係者全員で議論する。そして、フィードバックを踏まえ、プロダクトバックログを最新化する。

スクラムマスターは、このイベントが確実に開催されるようにする。

このイベントとは、スプリントレトロスペクティブのことである。
スクラムマスターは、スクラムが本質的な価値を提供できるようにするプロセスファシリテーターだ。
スクラムの公式イベントが確実に実施されるようにしよう。するかしないかの判断を、開発チームに任せてはいけない。

スプリントレトロスペクティブでは、スクラムチームは作業プロセスの改善や「完成」の定義の調整によって、プロダクトの品質を向上させる方法を計画する。ただし、プロダクトや組織の基準と衝突しないように適切に行う。

「完成の定義」は、チームの成熟度に左右され、チーム毎に異なる。
だが、プロダクトが共通なら、複数チームで協業していても、「完成の定義」はプロダクトレベルで統一する。
所属する組織に「完成の定義」がある場合、その標準を含んでいなくてはならない。組織標準を無視したチーム独自の「完成の定義」はスクラムではない。

また、「完成の定義」はスプリント毎のレトロスペクティブで評価する。チームの成長に従い、「完成の定義」を拡張していく。

プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。プロダクトに対する変更要求の唯一の情報源である。

ひとつのプロダクトに、ひとつのプロダクトバックログが存在する。カテゴリー欄を設けて分類してもいいが、カテゴリー別に複数のプロダクトバックログを作ってはいけない。

プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。

優先順位を付けるには、「見積り」と「価値」が不可欠である。
プロダクトバックログはスクラムの3つの作成物の一つである。作成物に必要な情報が網羅されており、正しい判断を促す「透明性」が完全であること。尚、「リスク」属性を追加するなど補強するのは構わない。

要求の変更は止まらない。プロダクトバックログは生きた作成物である。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。

プロダクトバックログが静的なら、スクラムではない。
経験的プロセスを回し、利害関係者からフィードバックを継続的に獲得し、プロダクトバックログもプロダクトインクリメントもどんどん進化していく。
開発チームは、新しいテクノロジーを評価し、学習する。これらの作業もプロダクトバックログに投入される。

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。

スクラムなら、プロダクトバックログのリファインメントをする。リファインメントを定期的に行う事で、次のスプリントをスムースに運べる。リファインメントはスクラムの公式イベントではないが、状況を握り直し、プロダクトバックログの「検査」と「適応」を回す肝となるプロセスである。

開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。

エンジニアの中に協力会社のメンバーが含まれていても、協力会社のマネージャーが見積もってはいけない。スクラムでは、作る人が見積もる。

スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。

スプリントバックログはスクラム作成物のひとつである。作成物の透明性が完全でないと、スクラムと言えない。

継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。

経験的プロセスの価値を享受するには、経験を経て獲得したアイデアを、実験して評価する必要がある。

スプリントバックログは十分に詳細であり、今後も変更される可能性のある計画である。それはデイリースクラムで理解できる程度のものである。開発チームは、スプリントでスプリントバックログを修正する。スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。
新しい作業が必要になれば、開発チームがスプリントバックログに作業を追加する。作業が完了すれば、残作業の見積りを更新する。計画の要素が不要になれば削除する。スプリントでスプリントバックログを変更できるのは開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。

スプリントバックログが静的なら、スクラムではない。
自己組織化され、学び続ける開発チームは、日々スプリントバックログを更新し、スプリントゴールに迫っていく。

スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。

開発チームの作業を管理するのは、開発チーム自身である。残作業の特定は、タスクボードやバーンダウンチャートを利用するのが一般的だが、開発チームは、自律したチームとして自分達に最適な方法を選べばいい。

日々の進捗管理はスクラムマスターもプロダクトオーナーもしない。開発チームの作業進捗を誰かに管理されているなら、スクラムではない。

スプリントの終了時には、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。

時間が王様である。タイムボックスはスクラムのルールだ。
タイムボックスを尊重し、集中力を高めて、一気に完成品までもっていく。

スクラムマスターは、作成物の検査、パターンの察知、言説の傾聴、期待値と実際値の違いを把握することで、不完全な透明性を検知できる。
スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。

スクラムに透明性は欠かせない。
スクラムの経験的プロセスの価値を最大化するには、作成物の「透明性」を最大化し、判断の精度を最適化し、「検査」と「適応」をリアルな状況に噛み合わせることだ。
スクラムマスターは、耳を澄まし、周りを観察し、データを揃え、あらゆる状況の透明性を最大化する。

複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。

共通のプロダクトだから、共通の「完成の定義」が必要である。
「完成の定義」に一貫性がないと、ワンプロダクトとして結合できない。
開発チームは、自己組織化したチームとして、依存関係のある開発チームと共同する。

スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。新しい定義を作り、それを使用していくと、以前に「完成」したインクリメントにも手を加えなければいけないことが明らかになる可能性がある。あらゆるプロダクトやシステムは「完成」の定義を備えるべきである。それがあらゆる作業の完了基準となる。

プロダクトやシステムに「完成の定義」を設ける。そして、チームの成長と共に「完成の定義」を拡張する。
「完成の定義」がアイデアをカタチにするまでの作業を特定し、個々の作業の完了基準を定義する。「完成の定義」がなければ、スクラムではない。

どうだろう。
あなたは、スクラムを正しくできていただろうか。

スクラムガイドは、わずか18ページである。
最後の3ページは、スクラムの歴史、および2016年版と2017年版の変更点サマリーだ。だから、正味15ページだけである。

これからスクラムをする人、すでにスクラムを始めている人も、もう一度スクラムガイドを読んで、理解を確かなものにして欲しい。

スクラムは、アジャイルの一フレームワークだが、なかなか奥が深いのである。

スクラムは知っている、スクラムならできると過信せず、新たな気持ちでスクラムガイドを読み、共に、経験的プロセスを回していこう。