Core Scrum (コアスクラム) の日本語訳｜スクラムガイドとどちらが原典？アジャイル開発で最も普及している手法 l 2014年版

スクラムでは「スクラムガイド」が有名ですが、Scrum AllianceによるとCore Scrum（コアスクラム）が原典のようです。このCore Scrumを理解して守っていればスクラムと言えます。

スクラムは「現状を把握する（見える化）フレームワーク」であるため、「問題を発見する」部分にフォーカスしています。

逆に、「問題を解決する」部分はそれぞれのプロジェクトや現場に合わせて他の手法・手段を取り入れていくことになります。そのため、2つとして同じやり方のスクラムチームがないと言えますし、同じスクラムチームが新しいプロジェクトを担当することになったら、やり方を変えるでしょう。

スクラムを導入すればなんでも解決する、と誤解しないでください。過剰な期待はできません。あなたが抱えているプロジェクトの難しい課題は、やはり難しいのです。

ただ、「問題解決」は「問題を認識すること（区別して正しく理解すること）」から始まります。その第一歩をスクラムを導入することで透明になるほど認識できたら、スムーズに「問題解決」に進めるでしょう。

Amazonで「スクラム」や「scrum」で検索すると多数の書籍がヒットします。どれも素晴らしいと思いますが、それぞれの著者の思いや経験が入っています。そのような書籍の方が理解しやすかったり、現場をイメージしやすかったり、実践しやすいかもしれません。ただ、他のアジャイルプラクティスが入っていたり、個人の思いが入っており、純粋な「スクラム」からすると混じり気があるでしょう。

様々な書籍を読んだり、スクラムでアジャイル開発を実践し、ある程度「スクラム」が何者か分かってきた上で、より本質的なスクラムを知りたくなったときに「Core Scrum」を読んでいただくことをオススメします。

スクラム特有の用語がたくさん出てきますので、初めての方が読むのは少々厳しいです。

「スクラムガイド」も最新版は2017年に改訂されており良いのですが、「〜しなければならない」という表現が多いです。言葉も強く、あるべき論が全面に出ていますが、そこまでガチガチにする必要はないと考えています。何を伝えたいのかを捉え、解釈して、良いところを適用できればと思います。

それでは、「Core Scrum」をよく読み、世界のスクラムマスターたちの英知をいただいてしまいましょう。最新版は2014年版となっており、更新されています。

スクラムはアジャイル開発の手法のひとつとして最も世界で普及が進んでいます。アジャイル宣言は2001年に作成されてから凍結されてしまっていますが、スクラムは改定されています。変化に適応しているあたりが生き残っているひとつの要因かもしれませんね。

※英語を理解できる方はこのまま原文をご参照ください。また、コメントについては私の解釈であり加筆・修正していきますが、引用の日本語訳のみ読み進めていくこともできます。

Core Scrum（コアスクラムの2014年版を日本語訳してみる）

2020年3月時点で公式な日本語ドキュメントは見当たりません。いつか、スクラムガイドやアジャイル宣言のように、公式な日本語ドキュメントが公開されたら、この記事は役目を終えます。

また、十分に英語を読み取れる方は原文をご覧ください。

英語に自信があまりない方向けに、Google翻訳に頼りながら日本語訳（一部不自然なところを修正する程度）いたします。そして、コメントを差し込んで行きます。

原文と本記事を見比べたい方向けに段落タイトルのみ、紐付けのために英文を引用しています。

What is Scrum?｜スクラムとは何か？

スクラムは、主要なアジャイルソフトウェア開発フレームワークです。
これは、協調的で健全で楽しい方法でビジネス目標を達成するための基盤と道を提供します。
「コラボレーティブで、健全で、楽しい」を「ビジネス目標」と同じ文章に入れたのはいつですか？
既にスクラムを使用していない限り、覚えていないかもしれませんが、スクラムを使用すると、実際に仕事を再び楽しむことができます！

「主要な」という表現は少し盛られていますが、世界の54%以上のアジャイル開発プロジェクトでスクラムが導入されていると言われています。「スクラム」を推進したい人としては「主要な」ということにしたいのでしょう。

ソフトウェア開発の現場では大変のなことが多いですが、スクラムで楽しくなれたら良いですね。たまたまかも知れませんが、私が見てきたスクラムチームは楽しそうに見えます。

スクラムはソフトウェア開発を念頭に置いて作成されましたが、他の多くの業界ではこのフレームワークを独自の世界に適用しています。
実際、教育、マーケティング、運用などでスクラムが採用され、スクラムがもたらすメリットを享受しています。

「アジャイル」自体もあらゆる業界、仕事に適用されておりますが、「スクラム」もということです。私はまだソフトウェア開発の現場しか見たことがありませんが、いまの「スクラムへの理解」があれば、他の仕事に適用することは容易に想像ができます。

例えば、「プロダクトオーナー」や「スクラムマスター」の役割や、各種のアクティビティ、アーティファクトは特殊ですが、スクラムの三本の柱（原則）である、「透明性」「検査」「適応」はあらゆるところで有益でしょう。

「Core Scrum」では「透明性」「検査」「適応」の言葉があちこちで出てきますが、明示的にその3つを一括りにして「柱」「原則」という表現にはなっていません。このあたりは「スクラムガイド」と差異がありますが、本質的には同じであるためあまり気にしないで良いでしょう。

How did Scrum originate?｜スクラムはどのように生まれたのか？

スクラムとなる概念は、1986年に「新たな新製品開発競争（The New New Product Development Game）」（1986年1月/ 2月ハーバードビジネスレビュー）で竹内弘高と野中郁次郎によって世界に初めて紹介されました。
彼らは、そのアプローチを「柔軟で全体的な製品開発戦略」と定義し、それが迅速で柔軟な製品開発をもたらすと提案しました。
ラグビーの試合のように、クロスファンクショナルなチームが「ゴールライン」に向かって「ボール」を行き来するため、ホリスティックまたは「ラグビー」アプローチと呼ばれました。 これは、厳格で直線的な方法で進行するアプローチとはまったく対照的であり、今後もそうです。

スクラムが外国（米国）発祥だと思っていた方もいるかと思いますが、日本でした。

そして、そこから着想を得て、IT産業の開発の現場で効果的にソフトウェア開発を進める手法としてジェフ・サザーランドとケン・シュエイバーが1990年代に考案した開発の実践方法がスクラムです。

Scrum Principles｜スクラムの原則

The Agile Manifesto｜アジャイル宣言

2001年に、17人がユタ州のワサッチ山脈に集まり、アジャイル界隈の共通の場所を見つけました。
多くのスキー、会話、リラックス、食事の後、彼らはアジャイル宣言につながる4つの共通の価値観に到達しました。
スクラムはアジャイルフレームワークであり、アジャイル宣言の価値と一致しています。

時系列からすると、アジャイル宣言より先にスクラムが生まれていますが、アジャイルフレームワークのひとつとされています。

スクラムをより理解するにあたり、アジャイル宣言の価値観を理解します。

Individuals and interactions over processes and tools｜プロセスやツールよりも個人と対話を

スクラムは、ビジネスに価値を提供するためのチームベースのアプローチです。
チームのメンバーは協力して、共通のビジネス目標を達成します。
スクラムフレームワークは、チームメンバー間の効果的な相互作用を促進し、チームがビジネスに価値を提供します。

スクラムでは最上位の概念として「チーム」があります。まだ「グループ」でしかない場合は段階的に「チーム」になれるようにカイゼンしていきます。

チームはビジネス目標を達成するために次のようになります。
•作業方法の把握（見える化する）
•仕事をする
•邪魔になるものを特定する
•その範囲内のすべての困難を解決する責任を負う
•組織外の人と連携して、チームの管理外の懸念を解決する

チームとして、作業を見える化しながら仕事をし、阻害要因を特定して解決し、他者を巻き込んでチーム外の課題を解決します。

スクラムにおけるチームの責任にフォーカスを合わせることが重要です。

全ての責任は個人ではなく、チームとして持つという考え方になります。自然と、相互に支援し合える関係性になれることが理想です。

Working software over comprehensive documentation｜包括的なドキュメントよりも動くソフトウェアを

スクラムでは、すべてのスプリントの主な結果として、リリース可能なプロダクトインクリメント（既存のプロダクトに対する増分）が必要です。
スプリント中に行われるアクティビティが何であれ、プロダクトインクリメントの開発にフォーカスします。
スクラムチームの目標は、スプリントごとにプロダクトインクリメントを増やすことです。
プロダクトインクリメントには、ビジネスとしてリリースすることを決定するのに十分な機能がまだ含まれていない場合がありますが、チームの仕事は、存在する機能がリリース可能な品質であることを確認することです。

アジャイル宣言の「動くソフトウェア」をスクラムの言葉で表すと「プロダクトインクリメント」となります。「プロダクトインクリメント」はスプリントの目的になるほど重要なものです。

進捗の指標にもなるため、世に送り出せる品質の高さにまで持っていく必要があります。また、新規に開発したフィーチャ（機能を価値で表現したもの）だけでなく、これまでに開発したプロダクト全体もテストし、品質を確保します。

Customer collaboration over contract negotiation｜契約交渉よりも顧客との協調を

スクラムは、コラボレーションを促進および促進するために設計されたフレームワークです。
チームメンバーは互いに連携して、ソフトウェアまたはその他の成果物を構築し、ビジネスに提供する最適な方法を見つけます。
チーム、特にプロダクトオーナーは、プロダクトが可能な限り価値があるように、プロダクトビジョンを検査および調整するためにステークホルダーと協力します。

チームメンバー内、そしてステークホルダーとのコミュニケーションを密にし、協力し合うことが大切です。プロダクトオーナーはチームメンバーに含まれます。

「顧客」という言葉は曖昧な表現ですが、そのプロダクトを開発するにあたってお金を出す人（スポンサー）であり、重要なステークホルダーの一人です。

Responding to change over following a plan｜計画に従うことよりも変化への対応を

スクラムチームは頻繁に計画を立てます。手始めに、彼らは直近のスプリントを計画します。
さらに、多くのチームがリリース計画やプロダクトロードマップなどの長期計画を作成します。
これらの計画は、チームとビジネスの意思決定を支援します。
ただし、チームの目標は計画に盲目的に従うことではありません。 目標は価値を創造し、変化を受け入れることです。
本質的に、計画に必要な思考プロセスとアイデアは、計画自体よりも重要です。

早期に作成された計画は、将来得られる情報よりも少ない情報に基づいているため、当然、最善の計画ではない場合があります。
新しい情報が発見されると、チームはプロダクトバックログを更新します。つまり、プロダクトの方向が変わる可能性があります。
この継続的な計画（計画づくり）により、新しい知識がエクスペリエンスに組み込まれるため、チームの成功の可能性が向上します。

アジャイル開発は計画を立てないという大きな誤解されることがあります。しかし、アジャイル開発では頻繁に計画づくりをします。

プロダクトの長期計画としてプロダクトロードマップを作成し、リファインメントで中長期計画を見直しし、スプリントプランニングで直近のスプリントのバックログを見直しし、デイリースクラムで日々のタスクの見直しをします。

つまり、継続的な計画づくりがスクラムのフレームワークに組み込まれているということです。

一方、一度作られた「計画」はその時点で分かる情報で作成された「スナップショット」であるため重視されません。また、分かる情報の範囲における粒度の計画で良く、分からないことに対して詳細化するために多くの時間をかけて計画することは無駄です。

アジャイル宣言における「計画に従うよりも変化への対応を」について補足すると、過去に立てたスナップショット的な計画に固執せず、新しく分かったこと（変化）に適応して計画づくりすることを重視する、ということになります。

ちなみに、ウォーターフォール開発ではプロジェクトキックオフ時にプロジェクトのベースラインとして「プロジェクト計画書／プロジェクトマネジメント計画書」を作成します。キックオフ時は一番分かる情報が少ないのため、この計画書を作成することは大変です。

そして、プロジェクトが進むにつれて分かる情報が増え、変化し、一部が不要になることもあります。それに応じて常にプロジェクト計画書を更新できればよいですが、膨大な資料であり、更新のきっかけもなく、ステークホルダーも多いため、更新して合意を取るのはとても大きなコストがかかります。大きなコストがかかるものは、、もうお分かりですね、更新されず、見向きもされないドキュメントになります。

きっとそれは「包括的なドキュメント」のひとつです。

いつだって、やるべきことはやれることより多いものです。限りある貴重時間は、より価値の高い作業から順番に行います。きっと、包括的なドキュメントは下の方になるでしょう。

現場によっては、その包括的なドキュメント作成を避けられない場合があります。その場合はその作業を組み込むことになります。作業を少しでも減らさないか、自動化できないか、意味のあるドキュメントにできないか、を考え、思考停止しにならないようにします。

スクラムチームは常に変化に適応し、可能な限り最高の結果を達成できるようにします。
スクラムはフィードバックループのフレームワークとして説明できます。これにより、チームはプロダクトを最大限に活用できるように、常に検査と適応を行うことができます。

フィードバックのループを回すために、スプリントの最後にレトロスペクティブが組み込まれています。これによって立ち止まり、今のチームとプロダクトの状態がどうなのかを確認し、カイゼン点を見つけて次のアクションアイテムを起こし、次のスプリントで実行することになります。

フィードバックはレトロスペクティブを待たずに気づいたときに、タイムリーに、率直に、親切にすることが理想です。ただ、フィードバックは諸刃の刃です。気づきを与えて成長を促す一方、伝え方や伝わり方でマイナスの影響を与えることがあります。心理的安全性があり、個々人間で十分な信頼関係ができてからにすると安心です。

スクラムチームの問題は個人ではなくチームで責任を持つため、By Nameを出すことなく、建設的に議論しましょう。

ちなみに、「検査」と「適応」はスクラムの三本の柱の二つですね。もう一つは「透明性」です。

Scrum Values｜スクラムの価値

スクラムで実行されるすべての作業には、チームのプロセスと相互作用の基盤としての一連の価値が必要です。
そして、これらの5つの価値を受け入れることで、チームはそれらの健康と成功にさらに役立つようにします。

この5つの価値はスクラムに限らず、どんな「チーム」にも適用できそうです。

Focus｜集中

私たちは一度にいくつかのことにのみフォーカスするため、私たちは一緒にうまく働き、優れたプロダクトを生み出します。価値あるプロダクトをより早くお届けします。

一番の理想としては、そのチームの全員はそのプロジェクトの仕事のみに集中することです。全く別の仕事を掛け持ちしている人がいたら、時間や場所の分断が大きくなり、コミュニケーションも疎になってしまいます。

ただ、現実は複数の仕事を掛け持ちする場合が多いことも事実です。ひとつのプロジェクトに100%コミットが難しくとも、それが望ましいことを意識し、チームメンバーはもちろんのこと、スクラムマスターや周りのマネージャーや経営層が協力します。その際に、自分たちのチーム以外の仕事も大切なものだと捉えて、丁寧に調整することが大事です。

Courage｜勇気

私たちはチームとして働いているため、サポートされていると感じており、より多くのリソースを自由に使用できます。これにより、より大きな課題に取り組む勇気が与えられます。

リスクを伴う大きなチャレンジをするためには、安心できる場がセットで必要と考えています。足元が不安定ではチャレンジどころではなく、身を守ることで精一杯となります。

「サポートされている」とチームが感じられるように、スクラムマスターやマネージャーは振舞います。

Openness｜開放性

一緒に仕事をするとき、私たちは自分たちがどのようにやっているのか、私たちのやり方で何をしているのか、そして懸念に対処できるように懸念自体を表します。

「チームのやり方」「チームでやっていること」「チームが懸念していること」を見える化します。チームのことは包み隠さずオープンにするということです。それによって、チーム外の方から適切な支援、アイデアを得ることができます。

Commitment｜コミットメント

私たちは自分の運命を大いにコントロールしているので、私たちは成功に対して、よりコミットします。

意思決定をチームの中に持つことで、チーム自身が納得してプロダクトの成功にコミットできるということです。もし、チーム内に意思決定がなく、外部に全て決められるとしたら何のコミットもしたくなくなるはずです。

Respect｜尊敬

成功と失敗を分かち合いながら協力することで、お互いを尊重し、お互いに尊敬に値するようになります。

お互いを尊重し合うことの大切さは計り知れません。

成功を分かち合うことは簡単ですが、失敗を分かち合うことは少し勇気が必要かもしれません。ただ、失敗を分かち合えるチームは強いです。

組織がスクラムを適用すると、その利点がわかります。 同時に、これらの価値が本質的にスクラムの成功にどのように貢献するかを理解し、スクラムがそれらを必要とし、強化する理由を理解します。

この5つの価値は当たり前に感じるかもしれません。ですが、きっとその当たり前は難しいです。

Scrum Framework｜スクラムフレームワーク

スクラムは、顧客がプロダクトを必要とするときに始まります。
スクラムフレームワークは、価値の向上と進捗状況の高い可視性に重点を置いて、そのプロダクトの作成をガイドします。
行うべき最も価値のある事柄の動的なリスト（プロダクトバックログ）から作業し、スクラムフレームワークを使用して、スクラムチームはそのプロダクトをアイデアから実現します。
スクラムフレームワークはプロダクト間で一貫しているため、非常に便利です。 プロダクトに応じてフレームワークを変更する必要はありません。 あなたはすべてにおいてスクラムフレームワークを使用できます。

スクラムフレームワークはアイデアからプロダクトを開発するにあたって、プロダクトの価値を高めることと、プロジェクトの現状を把握することに役立ちます。スクラムが万能であるとは言い過ぎですが、色んな手法（フレームワーク）を混在させるより、なるべく統一した方が推進しやすいかもしれません。

Scrum Roles｜スクラムのロール

スクラムチームには3つの役割があります。
•プロダクトオーナー：プロダクトのビジョンを持つ
•スクラムマスター：チームがスクラムを最大限に活用してプロダクトを開発するのに役立ちます
•開発チーム：プロダクトを開発します

3つのロールについてさらっと書いていますが、もう少し詳しい説明が後述されています。

ちなみに、プロダクトオーナー（Product Owner）はPOと省略して呼ばれることが多いです。

プロジェクトマネージャー（Project Manager）はPMですね。最近はPOに近い存在として、プロダクトマネージャー（Product Manager）という役割を設置する場合があります。それもPMとなってしまうため、下記の略語を使うと区別できます。

「Project Manager：PjM、Product Manager：PdM」

ただ、どちらも呼ぶときは「ピーエム」です。。

プロダクトは、スプリントと呼ばれる一連の短期間で段階的に開発されます。
スプリントの長さは定義されており、通常は1〜4週間です。
ほとんどのチームは、短いスプリントが長いスプリントよりも優れていることが分かっています。
各スプリント中に、スクラムチームは、プロダクトのリリース可能なサブセットであるプロダクトインクリメントを開発して提供します。
各プロダクトインクリメントは、プロダクトの認識可能な改善されたバージョンであり、定義済みの受け入れ基準（アクセプタンスクライテリア）を満たし、done（完了）と呼ばれる品質レベルまで開発されています。

アジャイルではイテレーションという言葉の方が一般的ですが、スクラムでは「スプリント」と言います。

短いスプリントの方が優れているのは、短い方が変化に適応できるからです。もしかすると、長いスプリントの方が単位期間あたりのアクティビティ（スプリントプランニング等）の回数を減らすことができて、効率的と思われるかもしません。実際はそれらのアクティビティはスプリントの長さに比例して時間がかかります。

それでは、何を判断基準にスプリントの期間を決めるかについては、バックログから受け入れ基準を経て、完了となる品質レベルまでプロダクトインクリメントを開発するまでのリードタイムに依存します。

スプリントを進行するにあたってあまり阻害要因がないのであれば1週間が理想的だと考えています。

しかしながら、スプリント期間中に詳細な設計書が必要、技術調査に時間がかかる、綿密なテスト計画書が必要、テストが複雑もしくは非効率で時間がかかる、受け入れする人の時間の確保が難しいなどの理由から、バックログからインクリメントを開発するのに2〜4週間必要であれば、スプリント期間は2〜4週間となります。

「受け入れ基準」と「完了の定義（何をすれば完了と呼べるか）」については開発チームとプロダクトオーナーで決め、合意します。

Scrum artifacts｜スクラムのアーティファクト

スクラムには、3つの具体的なアーティファクトがあります。
•プロダクトインクリメント：プロダクトの統合されたリリース可能なサブセット
•プロダクトバックログ：プロダクトのアイデアのリスト、優先順位
•スプリントバックログ：直帰のスプリント中の開発の詳細な計画

「アーティファクト」についてそのままの言葉を使いましたが、響きがかっこいいですね。日本語訳としては「技能によって作り出したもの」となります。後述されるアクティビティに対して、アウトプットに近いものかと思います。

チームはその計画と進捗状況を見える化するため、すべてのチームメンバーとステークホルダーは常にチームが達成していることを確認できます。

スクラムではカンバンボードを使うことが多いです。

一つ一つのバックログ（タスク）を誰でも見える場所にあるカンバンボードにて「To Do→Doing→Done」とリアルタムに移動させることで、誰でも今の状態を知ることができます。

カンバンがホワイトボードと付箋を使って表現することが多いですが、オンラインのツールを活用することもあります。そのチーム、プロジェクトに適した手段を選択します。

Scrum activities｜スクラムのアクティビティ

最後に、スクラムには5つのアクティビティ、ミーティングが含まれます。
•プロダクトバックログリファインメント
•スプリントプランニング
•デイリースクラム
•スプリントレビュー
•スプリントレトロスペクティブ

上記をアクティビティ、ミーティングの他にイベントやセレモニーと表現することもあります。

そして、正式な言葉としては上記ですが少々長いため、省略する場合もあります。

アクティビティ（イベント）	他の表現（主に省略形）
プロダクトバックログリファインメント	リファイメント
スプリントプランニング	スプリント計画
デイリースクラム	朝会（昼会、夕会）、スタンドアップミーティング
スプリントレビュー	※省略せず
スプリントレトロスペクティブ	レトロ、振り返り

チームによっては朝会と夕会の両方を行なっている場合がありますがおすすめしません。今日の夕会で話す内容は明日の朝会と同じはずです。夕会と朝会の間で作業が行われることは、持続可能な開発から外れます。

ただ、プロジェクトに波があったり、リリースの直前などで高稼働にならざるを得ないこともあります。そのような状況では朝会と夕会の両方が必要になるかもしれませんが、それは一時的な対処と捉え、恒常化しないようにしましょう。

スクラムのロール、アーティファクト、およびアクティビティは、スクラムサイクル内で連携して機能します。
これらのそれぞれについて詳しく見ていきましょう。

上記の3つの要素が頭の中で有機的に繋がってきていたら、もうだいぶスクラムを理解していると思います。

Scrum Roles｜スクラムのロール

上記のように、すべてのスクラムチームには、プロダクトオーナー、スクラムマスター、開発チームの3つのロールがあります。 これらのロールのそれぞれが協力して、アイデアからプロダクトを実現します。

スクラムには3つのロールしか定義されていません。これが核であり、最低限必要な役割です。そして、この3つのロールのメンバーを合わせて「スクラムチーム」と呼びます。

少しややこしいですが、「開発チーム」は「スクラムチーム」に含まれています。

アジャイルの文脈では「顧客」、「ステークホルダー」、「プロジェクトマネージャー」も役割として定義されている場合がありますが、スクラムでは定義されていません。

Product Owner｜プロダクトオーナー

プロダクトオーナーは、チームの仕事の価値を最大化することを担うスクラムチームのメンバーです。
プロダクトオーナーはプロダクトビジョンを持ち、エンドユーザー、顧客、ビジネスなどのステークホルダーと緊密に連携して、プロダクト周辺のコミュニティを育成します。
チームとステークホルダー間のコミュニケーションを促進し、チームが適切なプロダクトを開発していることを確認します。
それらは、何を開発すべきか、なぜ開発する必要があるかを記述しますが、その方法は記述しません。

スクラムの第一歩は、プロダクトオーナーがプロダクトのビジョン（構想）を伝えることです。

逆に、プロダクトのビジョンがなければスクラムを始められません。それほど重要です。

プロダクトオーナーもスクラムチームのメンバーであることを覚えていてください。

価値の最大化とありますが、つまりはROI（投資収益率）を最大化することが、プロダクトオーナーの仕事です。ROIに貢献するためにはプロダクトバックログを洗練させることになります。

ROIは投資に対する収益率であるため、「低コスト化とビジネス価値の最大化」の両方が求められます。プロダクトバックログ自体の品質も大事ですし、「何からつくるのか？」という優先順位づけが非常に重要です。

そして、プロダクトバックログのリストはプロダクトのロードマップにもなります。直近の数スプリント分は詳細・具体的で、未来のものは粗い・抽象的（構想レベル）でしょう。

プロダクトバックログに対して、「Why」と「What」を書き、「How」は開発者に任せます。

ロールの役割を満たすために、プロダクトオーナーは次のことを行います。
•プロダクトバックログに入れるものと、同様に重要なことを含めないものを決定する
•プロダクトバックログを維持し、バックログ内のアイテムを注文して最高の価値を提供する
•チームとステークホルダーと協力して、プロダクトバックログの品質と、それに含まれるアイテムに対する全員の理解を継続的に改善する
•直近のスプリントでチームに提供するよう依頼するプロダクトバックログアイテムを決定する
•より頻繁なプロダクトを届けることを優先して、プロダクトをいつリリースするかを決定する

良質なインクリメントのためには、良質なバックログが必要です。そのバックログに対するプロダクトオーナーの果たす役割は非常に重要です。

プロダクトオーナーは他の人によってサポートされている場合がありますが、ビジョンと優先順位の明確さを維持するためには、一人でなければなりません。

上記をご覧になってお分かりの通りにプロダクトオーナーに求められる役割は多く、欠かすことのできないものばかりです。そのため、多くのプロジェクトではプロダクトオーナーの役割を他の人が支援をします。「プロダクトオーナーの民主化」という言葉を使う方もいます。

例えば、バックログの作成の仕方についてスクラムマスターは支援してくれますが、バックログの作成自体を開発者が担う場合があります。

そのような場合においても、「バックログの優先順位づけ」、ならびに「プロダクトのビジョン策定」はひとりのプロダクトオーナーが担います。

特に優先順位づけは重要で、プロダクトの価値を最大限に高めるためのキーとなります。そして、何を基準に優先順位をつけるかは非常に難しいです。一言で言いますと「ROI（投資対効果）の高い順に並べる」ですが、より具体的には下記の4つの要素を総合的に判断します。

• 得られるビジネス的価値（直近の利益）
• 開発するコスト（直近の損失）
• 開発を通して得られる学び、知識、意義（近未来の利益）
• 開発によって低減できるリスク（近未来の損失）

価値が高いものを先に開発するのはイメージがつきやすいかと思います。ただ、それだけでなく、先に開発することでリスクを大きく低減できるものもまた、優先順位を高く設定します。

Scrum Master ｜スクラムマスター

スクラムマスターはサーバントリーダーであり、スクラムチームの残りの進歩を支援します。
スクラムマスターは、スクラムチームの生産性と学習を支援します。
スクラムフレームワークと、それを使用するために他の人を訓練する能力について十分に理解している必要があります。

スクラムマスターとプロダクトオーナーは、同じ人がなることはできません（兼任できません）。時には、スクラムマスターがプロダクトオーナーの依頼を断ることをしなければならないからです（チームを守る人と、プロダクトをたくさん作りたい人とで相反します。）。

スクラムマスターはプロジェクトマネージャーとも異なります。スクラムマスターは、何をすべきか指示したり、タスクを割り当てたりしません。

ちなみに、スクラムにはプロジェクトマネージャーのロールが定義されていません。それは「ロールとしては必要なく」、「プロジェクトマネジメントを3つのロールで分担できる」と考えられているからです。

ここは非常に重要です。

プロジェクトマネージャーがいないからといって、プロジェクトマネジメントをしなくていいとは決して誤解しないでください。

プロダクト開発はひとつの例外もなくプロジェクトです。そこにプロジェクトがあればマネジメントは必須です。

プロジェクトマネジメントに必要な要素を洗い出し、3つのロールに割り当てます。

もし、3つのロールのそれぞれに対して、何らかの事情でその仕事を担うことができない場合には、別途「プロジェクトマネージャー」を用意することになるでしょう。

スクラムチームの残りの進捗とは少し不思議な言葉ですね。スクラムチームの成熟度に合わせた支援を行い、成熟しきったらスクラムマスターの仕事がなくなることになります（全てがプロダクトオーナーと開発チームで完結するようになる）。現実的には完全体のスクラムを回すことは非常に難しいため、やることはなくなりません。ただ、スクラムチームの成長に合わせて、組織に対するカイゼン活動に多くの時間を割くようになります。

スクラムマスターには、3つの中心的な責任があります。

Coach the team｜チームをコーチする

スクラムマスターは、チーム全体のパフォーマンス向上に役立ちます。
彼らは、プロダクトオーナーがプロダクトバックログを作成および維持する方法を理解するのに役立ち、プロジェクトが適切に定義され、作業がチームにスムーズに流れます。
また、スクラムチーム全体と協力して、完了の定義を決定します。
スクラムマスターは、チームにスクラムプロセスの実行方法を指導し、フレームワークを学習して使用できるようにし、各スプリントの最後に到達できるように技術的なプラクティスを見つけて実装できるようにします。

スクラムマスターのゴールはスクラムマスターがいなくても、スクラムが上手く回るようにすることです。そのために開発チームとプロダクトオーナーをコーチングします。

Keep the team moving forward｜チームを前進させ続ける

サーバントリーダーとして、スクラムマスターはチームの自己組織化を促進し、チームの進行に対する注意散漫や障害、または障害が取り除かれることを確認します。
障害は、他のチームからのサポートがないなど、チームの外部にある場合もあれば、適切なプロダクトバックログを準備する方法を知らないプロダクトオーナーのように内部にある場合もあります。
また、定期的なチームミーティングを促進して、チームが確実に完了まで進むようにすることもできます。

スクラムチームの目的が短いスプリントで確実にプロダクトインクリメントを開発していくことであるため、それを促進します。

Help everyone understand Scrum｜誰もがスクラムを理解できるようにする

スクラムマスターは、チームの内外でスクラムが理解され、適切に配置されていることを確認します。
チーム外の人々がプロセスを理解するのに役立つだけでなく、チームとのやり取りが役立つものとそうでないものもあります。
スクラムマスターは、誰もがスクラムチームの生産性と価値を高めるための改善を支援します。

スクラムをうまく回すためにはスクラムチームがアジャイルとスクラムの本質を理解するだけでなく、周りのステークホルダーにも理解いただく必要があります。

さて、スクラムマスターに必要なスキルとしては、下記の5つが求められると言われています。

• ティーチング(Teaching)
• コーチング(Coaching)
• ファシリテーティング(Facilitating)
• メンタリング(Mentoring)
• シチュエーショナリング(Situational-ing)

それぞれ専門的であるため、これを全て兼ね備えるスクラムマスターは稀かと思いますが、志すなら目指したいものです。他にも、謙虚さ、元気、明るさが必要と言われる場合もあります。チームを元気にする役割も担うスクラムマスター自身が元気がなかったり、暗かったりすると心配になりますね。

また、プロダクトオーナー、開発チーム、スクラムマスターの立場に上下はなく、全員がフラットです。一番スクラムに詳しいからといって、偉そうにする、態度が大きいスクラムマスターはハズレです。

Development team member｜開発チームのメンバー

開発チームは、プロダクトインクリメントを提供する実際の作業を行います。
チームは、プロダクトインクリメントを提供するために必要なすべてのスキルを備えた専門家の職域を超えたグループです。
すべてのチームメンバーは、チームとプロジェクトにフルタイムで対応する必要があります。

開発チームは、７人 ± ２人にすることが望ましいと言われています。2ピザチーム（ピザ2枚で足りる人数）と表現されることもあります。

※人数が9人を超えるとコミュニケーションコストが高くなりすぎます。

ソフトウェア開発の場合は開発チーム内にて、分析、設計、開発、デザイン、テスト、アーキテクチャ、ドキュメンテーション、品質保証等のプロダクトインクリメントを作成するにあたって必要とされる全てのスキルを持ったメンバーで構成されることが理想です。

1つの開発チームが全ての作業を行うため「フィーチャーチーム」と呼ばれることもあります。

（「フィーチャーチーム」の対義語は「コンポーネントチーム」です。）

ただ、それぞれの専門家を集めることは難しいため、可能な限りフルスタック（多能工）であることが望まれます。

全ての作業をタスクボード（「ToDo-Doing-Done」などに区分したカンバンボード）に貼り、進捗を瞬時に見分けられるようにしたら、自然と自分が得意ではない分野のタスクを手伝ったり、受け取ったりするでしょう。それを繰り返していくうちに、できることが増えていきます。

ペアプログラミングは育成の観点でも非常に効果的と考えています。この手法と同様に「ペアデザイン」「ペアテスト」「ペア品質保証」等を取り入れてみても良いでしょう。

開発チームはプロダクトオーナーに対して開発と、プロダクトの価値向上に関するアイデアを提供します。

チームの全員はスプリントに100%コミットできると最も生産性が高くなります。したがって、複数の仕事をかけもちすることや、メンバーの変更は可能な限り避けます。

プロダクトオーナーは、実行する必要のあるものの順序付きリスト（プロダクトバックログ）を作成します。
次に、開発チームのメンバーは、1回のスプリントでどれだけできるかを見積もり、自己組織化して作業を完了させられるプロダクトインクリメントの作成する対象（スプリントバックログ）を決定します。

プロダクトオーナーがプロダクトバックログの優先順位に責任を持ちますが、そこから生まれるスプリントバックログについては開発チーム自らが見積もってコミットメントします。コミットメントが求められるため、スプリントプランニング時にできない約束は断る勇気が必要です。

Scrum activities and artifacts: The Scrum cycle｜スクラムアクティビティとアーティファクト: スクラムサイクル

すべてのスクラムサイクルは、一連のアクティビティを使用して、具体的な成果物またはアーティファクトを生成します。
サイクルを見て、アクティビティと成果物がどのように統合されるかを見てみましょう。

Product backlog (artifact)｜プロダクトバックログ（artifact）

何をする必要があるかをどのように知っていますか？
プロダクトバックログと呼ばれるスクラムアーティファクトを確認します。
これは、プロダクトのアイデアの順序付きリストであり、プロダクトオーナー、チームメンバー、またはステークホルダーからのものです。 詳細な記述と開発の見積もりは、各プロダクトバックログアイテムを補完します。

プロダクトバックログの書き方についてスクラムで定義されておりませんが、「ユーザーストーリー」や「ユースケース」を使うことが多いです。

プロダクトバックログはユーザーやビジネスからのニーズ、プロダクトに対するアイデアや洞察、競合の動向、マーケティング、技術的な課題等を加味して作成、更新することになるため、難しく時間のかかる作業となります。

大抵のプロダクトオーナーはこの作業に慣れていないため、スクラムマスターが支援します。

プロダクトバックログは単一の順序のついたリストではありますが、想定されるリリース単位に分けたものを「リリースバックログ」と呼ぶこともあります。

プロダクトバックログは、スクラムチームによって提供される価値を最大化するように注文されます。
開発チームの仕事はプロダクトバックログから来ており、他のどこからでもありません。 すべての機能、機能強化、バグ修正、ドキュメントの要件（チームが行うすべての作業）は、プロダクトバックログアイテムに起因しています。

フィーチャー（機能）以外の開発チームの作業もプロダクバックログにすると記載されています。これによって、開発チームの作業の見える化がされます。

プロダクトバックログは、大きなリストまたは短いリストとして開始される場合があります。 あいまいまたは明確に定義されている場合があります。
通常、短くて曖昧に始まり、時間が経つにつれて長くなり、より明確になります。
実装予定のプロダクトバックログアイテムはまもなく「リファインメント」されます。つまり、さらに明確化、定義され、小さなチャンクに分割されます。
プロダクトオーナーはプロダクトバックログを管理する責任を負いますが、開発チームはプロダクトバックログの作成と更新を支援します。

リファインメントは「プロダクトバックログリファインメント」として独立して実施する場合もありますし、「スプリントレビュー」の中でリファインメントを実施することもできます。

下記はプロダクトバックログの粒度の補足です。

直近のバックログ	分かっている情報が多い	具体的	開発するスプリントバックログ候補
未来のバックログ	分かっている情報が少ない	抽象的	変化しうるため詳細化しない

Product backlog refinement (activity)｜プロダクトバックログリファインンメント（activity）

プロダクトバックログアイテムは、多くの場合、本質的に大きく一般的なものであり、優先順位の変更に応じて行き来できます。
この流動的な環境のため、プロダクトバックログのリファインメントは、スクラムプロジェクト全体で継続的に行われている活動です。
プロダクトバックログリファインメントでは、次のことを行います。
•プロダクトバックログアイテムの順序を確認する
•重要でなくなったアイテムを削除または降格する
•登場する、またはより重要になるアイテムを追加または提案する
•大きなアイテムを小さなアイテムに分割する
•小さいアイテムを大きいアイテムにマージする
•プロダクトバックログアイテムの見積もり
•スプリント対応のプロダクトバックログアイテムを特定する

プロダクトバックログリファインメントは、今後のスプリントに備える優れた方法です。
このプロセスでは、次のスプリントに予定されているアイテムを選択することに特別な注意を払います。
考慮すべき事項は次のとおりです。
•スプリントの各アイテムは、「ビジネス価値」の増分を表す必要があります。
•開発チームは、単一のスプリント内で各アイテムを構築できる必要があります。
•ステークホルダーとスクラムチーム全体の両方が、何を意図しているかを明確にする必要があります。

プロダクトの性質によっては、他のスキルとインプットが必要になる場合があります。
そのため、プロダクトバックログリファインメントは、プロダクトオーナーだけでなく、チームメンバー全員の責任です。

プロダクトバックログリファインメントの目的は大きく2つあります。

プロダクトの方向性に関わるため、通常、ステークホルダー（営業担当やマーケティング担当等が含まれる場合があります）も参加します。

また、スプリントプランニングのインプットとなるプロダクトバックログの品質も高めます。良質なプロダクトバックログを届けられないと、スプリントプランニングはうまくいきません。

Sprint planning (activity)｜スプリントプランニング（activity）

各スプリントは、スプリントプランニングと呼ばれるタイムボックスされたミーティングで始まります。 このミーティングでは、スクラムチームは、スプリントで行われる作業を選択して理解します。

チーム全員がスプリントプランニングに参加します。
プロダクトバックログから作業し、プロダクトオーナーと開発チームのメンバーは各アイテムについて話し合い、そのアイテムと、現在の完了の定義と一致してそれを完成するために必要なものを共有して理解します。
スプリントプランニングにかける推奨時間は、スプリント期間の週あたり2時間以下です。
ミーティングは時間枠が設定されているため、スプリントミーティングの成功は、進行中のプロダクトバックログの品質に依存します。
これが、プロダクトバックログリファインメントが非常に重要な理由です。

スクラムでは、スプリントプランニングには2つのアウトカムがあります。
1.スプリントで完了する作業の予測
2.仕事を達成するための計画

スクラム（アジャイル）は計画づくりを重要視します。スプリントプランニングは最重要な計画づくりと捉えています。参加者全員はそれぞれが意見を出し合い、合意を得ながらミーティングを進行し、2つのアウトカム（成果）を得ます。ファシリテーションが非常に重要であるため、初期の頃はスクラムマスターが担いますが、徐々に開発チームにてファシリテートできるようになります。

「完了する作業の予測」とはつまり「見積もり」です。「ストーリーポイント」、もしくは「理想日」といった形式を用いて、あまり時間をかけずに行うことが多いです。過去（最近）に開発したバックログを参考に相対的な見積もりをすることは、アジャイル開発の特徴のひとつです。

ソースコードの行数である「ステップ数」や「ファンクションポイント」で見積もることはありません。それらの見積もりがアテにならないこと、時間がかかることを多くの人が知っています。

アジャイルでは「無駄なものは作らない」、「シンプル」、「クリーンコード」が重視され、コード量は少ないことが望ましいです。

見積もりは開発チーム全員で行われ、「プランニングポーカー」などの手法を用いて、一部の人だけが見積もり規模を決めてしまうことを避けます。この「プランニングポーカー」は好評で楽しいと感じる方が多いです。

A forecast of what work will be completed in the sprint｜スプリントで完了する作業の予測

何をすべきかを決定するプロダクトオーナーは、注文されたプロダクトバックログアイテムを開発チームに提示し、スクラムチーム全体が協力して作業のレビューと理解を行います。

スプリントで引き受けるプロダクトバックログアイテムの数は、開発チーム次第です。 チームは、プロダクトインクリメントの現在の状態、チームの過去のパフォーマンス、現在のキャパシティ、および注文されたプロダクトバックログを考慮します。 プロダクトオーナーも他の誰も、開発チームに作業を追加できません。 常にではありませんが、多くの場合、スプリントには、スプリントゴールと呼ばれる特定の測定可能な共有ゴールが与えられます。 スプリントが行われている理由を要約したこの目標は、誰もがすべきことの本質に集中するのに役立ちます。

1つのスプリントで引き受けられるスプリントバックログ量は開発チームの能力とキャパシティに依存します。そのため、プロダクトオーナーはそれらを把握、理解する必要があります。理解することによって期待とのギャップを小さくし、将来の予測を立てることができます。その予測はプロダクトバックログの作成や優先順位づけに役立ちます。

1つのスプリントにおける開発量の平均（直近の3スプリント程度を対象とする）のことをベロシティと言います。通常はそのベロシティの数値に収まるように、スプリントバックログの量を調整します。

開発中は「バーンダウンチャート」などを用いて、日々のインクリメントの開発量（進捗状態）を見える化します。これをデイリースクラムで確認し、計画を調整します。

ちなみに、「ベロシティ」や「バーンダウンチャート」は手段であるため、スクラムでは定義されていません。

A plan for accomplishing the work｜仕事を達成するための計画

その後、開発チームは、doneの定義（完了の定義）に対する次のプロダクトインクリメントを作成する方法を決定するために協力します。 彼らはスプリント中に作業を完了することに自信を持っている必要があります。 初期の段階で行われる作業は、1日以下の小さな単位に分割されます。 後で行われる作業は、後で分解するために、より大きな単位で残される場合があります。

プロダクトオーナーは、ミーティングのこの部分で質問に答え、誤解を解決することができますが、作業の完了方法を決定することはできません。

Doneの定義（スプリント内の作業）とUnDone（スプリント外の作業）の定義は開発チームとプロダクトオーナーで合意します。開発したプロダクトをリリースをするために行う作業を全て洗い出し、done/undoneに振り分けます。スプリント期間内に実施するものがdoneに入ります。

doneの条件を満たしたものがプロダクトインクリメントとなります。理想的にはundoneがゼロになることが理想的です。現実的にはスプリント期間中の実施が困難なもの、リリースに向けてあとでまとめてやった方が効率が良いものがundoneとなります。例えば、脆弱性診断、性能試験、異常系の試験などがundoneに入る場合が多いです。

Result of sprint planning｜スプリントプランニングの結果

スプリントプランニングの最後に、スクラムチームは、スプリント中に達成すべき作業の量と複雑さについて共通の理解を持ち、合理的な範囲内で、それを完了することを期待できます。 チームはそれを達成するために互いにコミットします。

スプリントプランニングで決めたことはコミットが求められるため、無理なことは無理と断りましょう。懸念があれば懸念を表明しましょう。

そして、このコミットをスプリントごとに守っていくと信用が生まれます。

スプリントプランニングを要約すると：

The product owner decides what to do｜プロダクトオーナーが何をすべきかを決定する

•プロダクトバックログアイテムを使用して、「何をすべきか」を提示する
•プロダクトバックログアイテムに関する質問に答え、誤解を解決します。

プロダクトバックログアイテムは「ユーザーストーリー」という形式で表現されることが多いです。詳細で包括的なドキュメントではないため、読んで全てを理解することはできません。そのため、プロダクトバックログアイテムを会話のきっかけとして、プロダクトオーナーと開発チームで活発な会話をし、イメージのすり合わせをします。

The development team decides how much to take on and how to accomplish it｜開発チームは、引き受ける量とそれを達成する方法を決定します

•プロダクトオーナーとプロダクトバックログアイテムを検討し、話し合う
•それらの共通の理解を確実にします
•彼らが達成できると予測する多くの項目を選択する
•項目を確実に達成できるように、十分に詳細な計画を作成します。

結果としてできあがるリストが、「スプリントバックログ」です。

可能な限り精緻な見積もりとするために（実際はあくまで予測）、タスクレベル（1日以下の作業）にまで分解します。そして、プランニングポーカーなどの手段を用いて、開発チーム全員で見積もります。

Sprint backlog (artifact)｜スプリントバックログ(artifact)

スプリントバックログは、直近のスプリントで開発するために選択された洗練されたプロダクトバックログアイテムのリストであり、作業を達成するためのチームの計画と一緒です。 これは、どの作業を完了できるかについてのチームの予測を反映しています。 スプリントバックログが確立されると、開発チームは新しいプロダクトインクリメントの作業を開始します。

洗練されたリストにすることが、その後のスプリントにおける開発の品質を高めます。

Sprint｜スプリント

スプリント中、開発チームは自己組織化して、スプリントバックログとして定義されたプロダクトインクリメントを生成します。 自己組織化とは、開発チームのメンバーが、組織の基準とチームの定義の完了に応じてプロダクトインクリメントを最適に生成するために協力する方法を決定することを意味します。

自己組織化という言葉はアジャイル宣言の原則にもあります。チーム自体が自立していて、意思決定が中にあるほどアジリティが高くなると考えています。

また、アジャイル宣言の原則にある通り、「持続的なペース」で開発を続けることで、イテレーティブな開発を維持することができます。

Product increment (artifact)｜プロダクトインクリメント(artifact)

すべてのスプリントは、最も重要なスクラムアーティファクトであるプロダクトインクリメントを生成します。プロダクトインクリメントとは、各スプリントの「目標ライン」であり、スプリントの終了時に次のことを行う必要があります。
•ユーザーに提供するのに十分な品質であること
•スクラムチームの現在の完了の定義を確認する
•プロダクトオーナーに受け入れられる

特に重要な点はスプリントごとに「十分な品質」を確保する、保つということです。「価値品質」と「製造品質」の両方について、プロダクトインクリメントへの品質の作り込みをし、そしてこれまで開発してきたプロダクト自体の品質が保てていることを確認します。

厳密なウォーターフォール開発に比べて、アジャイル開発は品質が悪くなるという言う誤解を耳にすることがありますが、アジャイル開発の方が頻繁に品質をチェックされます。

補足として、価値品質としてはプロダクトバックログに書かれているユーザーの価値が提供されていること、製造品質としてはバグが検出されないレベルまでテストされていること、が求められます。もちろん、プロダクトの増分であるインクリメントだけでなく、プロダクト自体がデグレードを起こしていないこともテストします。毎回、全てのフィーチャー（機能）を打鍵することは現実的ではないため、ユニットテスト、CI/CD環境等のテストの自動化が手段として必要となります。

Additional indicators of progress｜進捗状況の追加指標

スクラムでは、チームの内外の人々がチームが何をしているかを見ることができる必要があります。 また、プロダクトインクリメントを提供することがこの透明性を作成する最も強力な方法ですが、スクラムチームは他のオプションではあるが有用な成果物を作成することもあります。 他のチームやステークホルダーがプロジェクトのステータスを確実に理解できるように、これらにはバーンダウンチャートやタスクボードが含まれる場合があります。

スクラムの三本の柱の一つの「透明性」が出てきました。進捗を測る手段としては動くソフトウェア（プロダクトインクリメント）ではありますが、スプリントプランニングからスプリントレビューまでの間のステータスを理解した場合には、手段としてバーンダウンチャートやタスクボード（カンバンボード）も使えるということです。

ただ、バーンダウンチャートやタスクボードは見える化の手段ではありますが、スクラムとして定義されているものではありません。

Definition of done｜完了の定義

プロダクトインクリメントが配信されると、「完了」の意味を共有して理解した上で、「完了」する必要があります。 この定義はスクラムチームごとに異なり、チームが成熟するにつれて、完了の定義が拡大し（Doneの拡張）、より厳格になります。

doneの定義には、プロダクトインクリメントがリリース可能な品質であるという概念を常に含める必要があります。 つまり、プロダクトオーナーはすぐにリリースすることを選択できます。 最新のプロダクトインクリメントには、以前のすべてのプロダクトインクリメントの機能が含まれており、完了したすべてのプロダクトバックログアイテムが引き続き連携して動作するように完全にテストされています。

開発チームはプロダクトオーナーとしてDoneの定義とUndoneの定義を合意します。Undoneがあるということはスプリントレビューで受け入れされた後にもリリースするためのタスクが残っている、ということになります。

よりアジリティを上げていくためにはUndoneのリストをDoneのリストに組み入れていることが必要です。この行為のことをDoneの拡張と言います。究極、全てがDoneの中に入れば、スプリントプランニングで受け入れられた直後にリリースすることができます。

Daily Scrum (activity)｜デイリースクラム(activity)

開発チームは、デイリースクラムミーティングを使用して、そのスプリントに向けて順調に進んでいることを確認します。 彼らは毎日同じ時間にミーティングを開催します。 ミーティングは短くし、最大15分間、時間枠を設ける必要があります。ミーティング、各開発チームのメンバーは3つの情報を提供します。
•前回のデイリースクラム以降にチームメンバーが達成したこと
•現在と次のデイリースクラムの間にチームメンバーが達成しようとしていること
•進捗を妨げるもの

デイリースクラムには他の呼び方があります。朝に開催するから「朝会」。立って短時間でやるから「スタンドアップミーティング」。

チームのメンバーは、簡潔な明確な質問をして簡単な回答を得るかもしれませんが、デイリースクラム中は詳しく説明しません。 代わりに、開発チームのサブセットは、デイリースクラムの直後に会って、発生した問題に取り組むことがよくあります。

なぜ、「最大15分間」という短いタイムボックスにしているかと言いますと、出席するメンバーの時間を大切にするためです。深い話しをしたい場合は人数を絞って別の場にすることで、必須ではないメンバーの時間を有効的に使うことができます。

デイリースクラムはレポートイベントではありません。 これは、開発チーム内のコミュニケーションミーティングであり、すべてのチームメンバーが同じページに参加し、前進することを保証します。 ステークホルダーはデイリースクラムに来て聞くことができますが、このミーティングではスクラムマスターとプロダクトオーナーを含むスクラムチームメンバーのみが発言します。 ミーティングでの予定に基づいて、開発チームは必要に応じて作業を再編成し、スプリントの目標（確立されている場合）とプロダクトインクリメントを達成します。

ステークホルダーはデイリースクラムを見ると、何か気づいたことに対して意見を述べたり、質問したくなるかもしれませんが、我慢してください。15分しかありませんから、質問を受け付けていては時間がオーバーします。聞きたいことがありましたら、デイリースクラム後に個別に聞きましょう。

通常は開発チームのみで運営します。場合によってはスクラムマスターがファシリテーションをする場合があります（特に初期の頃）。プロダクトオーナーの参加は必須ではなく必要に応じての参加となります（プロダクトオーナーは通常忙しく、毎回のデイリースクラムに参加する時間は確保できない場合が多いです）。

デイリースクラムは、透明性、信頼性、およびパフォーマンスの向上につながります。 どうやって？ 毎日のチェックインは、問題の即時認識と解決を提供し、チームの自己組織化と自立を促進します。

デイリースクラムは毎日の計画づくりとも言えます。

Sprint review (activity)｜スプリントレビュー(activity)

各スプリントの終わりに、スクラムチームとステークホルダーは、結果として生じるプロダクトインクリメントを確認します。 このミーティングはスプリントレビューと呼ばれ、スプリントの1週間に1時間の時間枠が必要です。 したがって、スプリントが2週間続く場合、スプリントレビューの推奨タイムボックスは2時間です。

議論の主なポイントは、スプリント中に完了するプロダクトインクリメントです。 ステークホルダーは結果に「利害関係」を持つ人であるため、このミーティングに出席することは良い考えであり、また有益です。 ミーティング中、チームメンバーは自分の現在地を確認し、どのように前進するかについて協力します。 全員がスプリントレビューに意見を述べています。 そして当然、プロダクトオーナーは将来について最終決定を下し、必要に応じてプロダクトバックログを更新します。

チームは、スプリントレビューを実施する独自の方法を見つけます。 ミーティングの一般的な要素には次のものがあります。
•プロダクトインクリメントの概要
•プロダクトインクリメントのデモ
•スプリント中にチームメンバーが何を観察したか、または頭に浮かんだプロダクトのアイデアについてのディスカッション
•プロダクトバックログの状態、想定される完了日、およびそれらの日付によって何が行われる可能性があるかに関するディスカッション
•プロダクトバックログの更新

スプリントレビューではしばしば「デモ」が行われますが「デモ」は目的ではありません。あくまで「検査」と「適応」のためにしているということを意識します。

「完了の定義」の通りに完了していること、「受け入れ条件（アクセプタンスクライテリア）」を満たしていることをステークホルダー含めて確認しますが、「完了」と判断されなかったものはプロダクトバックログに戻され、再度、優先順位がつけられます（通常は次のスプリントの対象となります）。

「完成系のスクラム」ではスプリントレビューで受け入れられたプロダクトインクリメントは即リリースすることができます。しかしながら、スプリント後に実施する作業がUndoneの定義に入っていることが多いかと思います。例えば、統合的なテスト、ドキュメンテーション、ステークホルダーへの承認作業、脆弱性の診断等があります。これらの残った作業を行うために「リリーススプリント」を設ける場合があります。ただ、これは「完了（Done）の拡張」によって不要にできるもの、と捉えてください。

チームメンバーが観察したこと、プロダクトのアイデアのディスカッションができるようなスプリントレビューはきっと楽しいでしょう。

Sprint retrospective (activity)｜スプリントレトロスペクティブ(activity)

各スプリントの終わりに、スクラムチームはスプリントのレトロスペクティブ（振り返り会）のために集まります。これは、スプリント期間の週に約1時間、再びタイムボックス化されます。 スプリントのレトロスペクティブで、チームメンバーは、個人間の関係や使用したツールなど、プロセスがどのように進んだかを確認します。 チームメンバーはうまくいったこととそうでないことについて話し、カイゼンの可能性を特定します。 その後、彼らは将来それらをカイゼンするための計画のアクションアイテムを出します。 スクラムフレームワークに忠実なまま、スクラムチームは方向性を提供するために他の人に依存するのではなく、自律的にプロセスをカイゼンします。

アジャイルはカイゼンし続けている状態であるため、レトロをしないとアジャイルではないとも言われることがあります。

振り返ってカイゼンのアイデア（アクションアイテム）を出すためには、チームメンバーのそれぞれが率直に意見が言える環境が重要で、心理的安全性の確保が必要です。そのため、可能な限りレトロへの参加はスクラムチームの範囲内とし、ステークホルダーは参加しないようにしましょう。

また、チームによっては忙しすぎることなどを理由にレトロを省略してしまう場合があります。これはとても悲しいことです。アジャイルは「カイゼンし続けている状態」であり、レトロを省略してしまうと、カイゼンの機会が奪われてしまいます。

スプリントごとにレトロを実施できるように、レトロを「大きな石」としてスケジュールに組み込んでから、他の予定を入れるぐらい重要なものと捉えます。

レトロには様々な手法がありますので、チームや状況によって効果的なものを選びます。いくつか試してみるとよいかと思います。

Rinse and repeat｜おさらいと繰り返し

•スクラムチームメンバー（プロダクトオーナー、開発チーム、およびスクラムマスター）は、スプリントと呼ばれるタイムボックス化された間隔で一連のプロダクトインクリメントを作成するために協力します。
•各プロダクトインクリメントは、プロダクトオーナーの受け入れ基準（アクセプタンスクライテリア）とチームの共有の定義の完了（Doneの定義）を満たします。
•チームはプロダクトバックログから作業します。
•各スプリントは、スプリントの計画であるスプリントバックログを生成するスプリントプランニングから始まります。
•チームは、デイリースクラムミーティングを使用して開発を実行するように自己組織化し、可能な限り最適なプロダクトインクリメントを調整して確保します。
•チームは、プロダクトバックログリファインメントを実行して、次のスプリントプランニングの準備をします。
•チームは、スプリントのレビューとスプリントレトロスペクティブでスプリントを終了し、プロダクトとプロセスをレビューします。

スクラムのフレームワークは「透明性」を提供し、「検査」と「適応」をすることができます。

スクラムになることはとても難しいですが、少なくとも今の現状より良くすることができます！

Ready to put Scrum into practice?｜スクラムを実践する準備はできましたか？

これで、複雑なプロジェクトを生産的かつ健全で楽しい方法で提供するために使用できるスクラムのコア要素の概要がわかりました。 これは実証済みのフレームワークですが、これはほんの始まりにすぎません。 フレームワークを適用するには、練習と試行錯誤が必要です。 ただし、より多くの作業を行うほど、より良い結果が得られます。 また、スクラムアライアンスは、スクラムの旅をより簡単に、楽しく、そしてやりがいのあるものにすることができるアドボカシー、コミュニティ、教育とともに、あらゆる段階であなたと一緒にいます。

— Scrum Alliance Core Scrum v2014.08.15

Core Scrum translations｜コアスクラムの翻訳

元のコアスクラムドキュメントの翻訳は、CSC、CST、およびその他のスクラムコミュニティの専門家によって行われています。 これらの翻訳の更新に取り組みます。 ここでは、既存の翻訳をリストし、作業を行っているボランティアを称えます。

スクラムアライアンスのWebサイト（https://www.scrumalliance.org/whyscrum/core-scrum-values-roles）にアクセスして、次の言語のコアスクラムドキュメントをご覧ください。

Chinese – Daniel Teng, Bill Li, Jackson Zhang, Joseph Yao, Mike Li 

Danish – Bent Myllerup, Kurt Nielsen 

Dutch – Jef Cumps, Kris Philippaerts, Hubert Smits 

French (Français) – Bruno Sbille, Fabrice Aimetti 

German (Deutsch) – Sabine Canditt, Markus Gaertner, Andreas Schliep 

Italian – Andrea Tomasini, Gaetano Mazzanti, Roberto Bettazzoni 

Norwegian – Geir Amsjo 

Persian – Taghi Javdani 

Portuguese – Heitor Roriz Filho, Rafael Sabbagh, Marcos Garrido, Daniel Wandarti, Filipe Albero Pomar 

Russian – Anna Dmitrieva, Sergey Dmitriev 

Spanish – Xavier Quesada Allue, Martin Alaimo, Alan Cyment 

Swedish – Arne Ahlander, Per Fagrell

残念ながら、上記のリストに「Japanese」が見当たりません。。

Core Scrum（コアスクラム）のまとめ

Core Scrumの全文を読んでみていかがだったでしょうか。スクラムのイメージ、実践しているスクラムの近かったでしょうか、遠かったでしょうか。

スクラムを理解はできても、実践することは難しいと言われいます。また、「0か1」でもありません。その「0と1」の間に多くの段階があります。

目指すべきスクラムを理解し、イメージした上で、現実からゆっくりと前に進んでいけたらよいかと思います。

もし、近くにスクラムマスター、アジャイルコーチがいたらラッキーです。道を間違えないように方向を指し示してくれたり、多くの実践知からそのときに効果的な手段を教えてくれるでしょう。ただ、「Core Scrum」や「スクラムガイド」からかけ離れたアドバイスをしているとしたら、怪しんでみてもいいかもしれません。笑

よろしかったら、「スクラムとは何か？現状を把握するもの｜19個の要素に分解」も読んでいただけたら幸いです。