スクラムとは何か？現状を把握するフレームワーク｜19個の要素に分解

純粋なスクラムを理解したい場合にはCore Scrumとスクラムガイドを読むことをおすすめします。両者は用語や表現に微妙な差異がありますが、両方を読むことで幅が広がります。

現時点（2020年3月）でCore Scrumは2014年、スクラムガイドは2020年に更新されています。

アジャイル宣言は2001年から止まっていますね。

本記事ではもっとさらりとスクラムを説明します。

Agenda

1. 代表的なアジャイル開発手法
2. スクラムとはなにか
3. スクラムにおける19個の要素
4. スクラムの役割（ロール）
5. スクラムの三本の柱（3つの原則）
6. 近くの人にスクラムを説明してみましょう

代表的なアジャイル開発手法

スクラムはアジャイルの手法のひとつであるため、先にアジャイルを理解します。

アジャイル宣言の4つの価値を覚えていらっしゃいますでしょうか。

個人との対話
動くソフトウェア
顧客との協調
変化への対応

これらの価値観を胸に、俊敏にカイゼンし続けている状態がアジャイル（Be Agile）です。

※ Be Agile rather than Do Agile.

ただ、アジャイルの原理原則だけでは、なにをどうすればいいのか分かりません。

アジャイルを実践するためのHowについて、数々のアジャイル開発手法（方法論）が生み出され、その中で最も普及が進んでいるのがスクラムです。

流行っているからスクラムが優れている、というわけではなく、それぞれに適した開発手法を選べばよいと思います。

※スクラムと並んで有名なXP（エクストリーム・プログラミング）については別記事にします。

スクラムとはなにか

アジャイルになるために現場を把握するためのフレームワークです。

（スクラムを取り入れたかといって、自動的に生産性があがったり、楽しなるものでもない、とのことです。）

フレームワーク（骨組み）ですから、中身はみなさんが埋めることになります。

ちなみに、Java、PHP、Javascript、Ruby、C#などの様々なプログラム言語にもフレームワークというものがあります。それらをただ使っている、だけでは意味がありません。

フレームワークが何を背景として作られているかを理解し、正しく運用することで初めて本来の価値を発揮できます。

せっかくフレームワークを導入しているのに重複したコードが点在していたり、ルールに則っていないソースコードを見てガッカリした経験はありませんか。

スクラムも同じです。

スクラムの背景を理解して、正しく運用し、アジャイルにカイゼンし続けている状態になれていたら、自分たちのチームはスクラムになっている、と胸をはれます。

そして、カイゼンし続けることがアジャイルであるため、スクラムというフレームワークが足かせ、ボトルネック、上限になってもいけないと考えています。時には枠からはみ出したり、変えたり、増やしたり、減らしたりも試す価値があります。あくまで、スクラムという手段が目的にならないように。

スクラムにおける19個の要素

スクラムには19個の要素があります。

透明性
検査
適応
スプリントプランニング（スプリント計画）
デイリースクラム
プロダクトバックログリファインメント（リファインメント）
スプリントレビュー
スプリントレトロスペクティブ（レトロ、振り返り）
プロダクトオーナー（PO）
開発チーム
スクラムマスター
プロダクトバックログ
受け入れ条件（Acceptance Criteria）
完了の定義（Doneの定義）
スプリントバックログ
スプリント：1〜4週間単位をタイムボックスとするイテレーション開発
潜在的リリース可能なプロダクトインクリメント（Potentially Shippable Product Increment）
インペディメント（障害）リスト：スクラムチームに対する阻害要因の一覧
スプリント中止（スプリントストップ）

極端に言いますと、上記以外のものはスクラムでは定義されていません。

例えば、ベロシティ、バーンダウンチャート、かんばんボード、インセプションデッキはスクラムで定義されていません。また、テスト駆動開発（TDD）、ペア・プログラミング、ユーザーストーリー、リファクタリング、持続可能な開発などはXP（エクストリーム・プログラミング）のプラクティスとなります。

ただ、実際のスクラムチームは必要に応じて他のアジャイルプラクティスを適用することが多いです。

それも、単に流行っているから、隣のチームがやっているから、過去のプロジェクトでやっていたから、といった理由で導入するのではなく、アジャイルであるために必要かどうか、という視点で判断します。

スクラムの役割（ロール）

スクラムにおいての役割は3つのみ定義されています。

開発チーム：6〜9名
プロダクトオーナー：1名
スクラムマスター：1名

（要求分析はウォーターフォール開発の要件定義に近いです。ただ、要件という言葉は作るものを定義する、変えられないもの、というニュアンスがあるため、アジャイルではユーザーやビジネスの価値を表す可変な要求という言葉を好みます。）

ひとりのプロダクトオーナーに仮説検証、要求分析、プロダクトバックログ作成などの、何を作るか？というところを任せようとする場合がありますが、それは無理があります。

なんでもやってくれるプロダクトオーナーは都合の良い概念でしかありません。

稀に神様のようなプロダクトオーナーがいるかもしれませんが、多くはプロダクト開発以外の仕事を持っていたり、まだ経験が浅かったり、求められるスキルに及ばなかったり、そもそも物量が多すぎたりします。

そして、ひとりに任せてしまうと、ひとりのプロダクトオーナーの視座がプロダクトの上限になってしまいます。

よって、プロダクトオーナーの民主化が必要で、開発チームと一緒にやる、もしくはプロダクトオーナーチームをつくる、というのも手段のひとつでしょう。

また、プロダクトオーナーはプロダクトバックログの優先順位をROI（投資対効果）に従って決定します。

得られる価値が高い、という視点だけでなく、大きなリスクを回避できるもの、問題を解決できるものも、そして開発の優先順位によるコストの増減、実際にリリースをする単位などを考慮して、プロダクトバックログに優先順位をつけて並べます。

重要度順ではなく、ROIを考慮した優先順位です。

「優先度」も英語では「priority」ではありますが、ここでは明確に「優先順位」という言葉を使います。

「優先度高」「優先度 A」というものが並んだら、結局、何から手をつけて良いか分からなくなるからです。

ちなみに、役割は対等でありフラット（階層構造ではない）です。プロダクトオーナーが偉いとかありません。スクラムマスターがプロジェクトマネージャーというわけでもありません。

（スクラムではプロジェクトマネージャーという役割は定義されておりませんが、ソフトウェア開発は例外なくプロジェクトであるため、プロジェクトマネジメントは必須です。プロジェクトマネジメントをスクラムチームができるならそれでいいですし、難しいのであれば、別途、プロジェクトマネージャーを立てる必要があります。）

スクラムマスターはスクラムがうまく回るようにスクラムのイベントや、開発時にファシリテートしますが、プロダクトオーナーや開発チームに対するコーチングも行います。

スクラムマスターは自分がいなくてもスクラムが回るように、開発チームが自己組織化していくことを促しますが、スクラムを健全に回すことはとてもとても難しいです。

真にアジャイルなスクラムにしていくためには、組織が阻害要因となることが多いです。そのため、スクラムマスターは組織の変革者としての役割も担います。つまに、インペディメント（障害物）リストの問題解決をしていくことになります。

開発チームには、よくある、プログラマー、システムエンジニア、デザイナー、テスター、DBエンジニア、データサイエンティスト、アーキテクチャ、運用担当などの役割（職業）は定義されていません。

もちろん、上記の役割（職業）や専門性が不要なわけでもありません。

重要なことは、開発チーム全体が価値のあるプロダクトを作り出すことに責任を持つということです。

ただ、ものを作ればいい、ではないのです。