10分でわかるはじめてのスクラム
こんにちは！
今回は開発方法論として、スクラムの基本を紹介します。
スクラムは以前別の記事でも紹介しましたが、今回は基本となる考え方や19のルールに絞ってみます。
想定読者は
はじめに
薄いフレームワーク
大量のルールがガチガチに固まっているわけではなく、覚えることが少ないのではじめることは難しくないはずです。少なくともPMBOKやITILよりかは 👻
また、巷にはオレオレスクラムという自己流スクラムが大量に転がっています。
基本となる考え方やルールはありますが、どれもケースバイケースで良し悪しは変わるという考えがその背景にあります。
上手くやるのは大変なので、誰しもが試行錯誤中かと思います。
開発方法論のデファクトスタンダード
アジャイルの基本は、アジャイルソフトウェア開発宣言にまとめられています。
従来重要とされていた価値も大事と考えつつ、それ以上に対話、動くソフトウェア、顧客との協調、変化への対応を重視する考えです。
アジャイル開発は企業やNPO、政府調達にまで採用されていて、アメリカではほぼデファクトスタンダードとなっています。
中でも成功事例を多く耳にする方法論がスクラムです。
参考 日本と世界のアジャイルの導入状況 - スクラムマスダーの日記
参考 7 top project management methodologies: Which is best?
小さくはじめよう
批判する方もいますが、我流でスクラムを導入すること（オレオレスクラム）は誰しもが通る道。
最初の導入にあたっては、顧客や上司、ステークホルダーに説明することは大変かもしれません。現場にも反対する方はいるでしょう。
それでもはじめる覚悟があるなら、用語を隠したり自分がコントロール可能な範囲で試験導入しちゃいましょう。
やっちゃえスクラム 👊
スクラムの基本
スクラムは問題を発見するフレームワーク
大前提として、世の中の変化は日々早くなっていて、その変化に上手く対応できるかが生き残りの鍵となる状況にあります。
スクラムでは、プロジェクトを上手く進めるための鍵が変化への適応と考えられていて、そのため問題をいかに発見するかが重要と考えます。
さらにアジャイルの本来の意味である「Agility（俊敏さ）」を上げるため、自律的かつ学習し続ける組織であることが望ましいです。
そのため、未来をよりよくするために解決すべき問題、
例えば現在抱えているプロジェクトや組織上の問題を浮き上がらせ、プロジェクトに関係する「人」を中心に対応していく仕組みが整っています。
公式リファレンス
コアとなる考えや、スクラム提唱者や普及団体の考え方は公式リファレンスにまとまっています。説明をかなり省略しているので理解するのは大変ですけどね 😅
19のルールと用語の解説
スクラムの実践イメージを作るため、基本となるルールと言葉の意味を知りましょう。
スクラムの三本柱「透明性、検査、適応」
スクラムの三本柱は、その他のルールの全てに適用されてる大事な考え方。
スクラムをやっていく中で、常に意識しましょう。
例えば、
- 透明性が確保され透明化された物事が活用できてるか
- 過去の踏襲ではなく、常に現状を疑い、良し悪しを検査できてるか
- 発見した変化に上手く適応するため、対話をとおして納得した適応ができてるか
など。
透明性
あらゆる情報や考えをさらけ出し、変化や問題の兆しに気ける状態。
透明性が悪ければゆでガエルじゃないが、現状維持が許され、気づいた時には後戻りできない状況に陥ってしまいます。
プロジェクトの進捗状況は常に誰でも見られる状態にしましょう。
感覚や憶測だけで話すのではなく、データや事実を集めましょう。
ステークホルダーの意見も、失敗した取り組みも、全てさらけ出しましょう。
検査
良し悪しを判定したり、正誤を判断したりできる状態。
主観的だったり曖昧な基準だったりも時には必要ですが、透明性が確保された状態を活かすためにも成功と失敗はハッキリさせましょう。
事実やデータが本当かのファクトチェックも重要。恣意的な判断は排除しましょう。
検査する基準がないなら仮説を立て、定性でも定量でもまずはデータを収集し、検査できる仕組みを整えましょう。
また、検査の仕組み自体が間違っていないかも検査することが大事。
仕組みや基準を撤回するルールや、変更するルールも考えておきましょう。
適応
変化を味方につけるため、状況や問題をコントロールできるよう試行錯誤する状態。
良いことは続け、まずいことは改善する。
そのための適応方法は、変化から学び自律的に見出しましょう。
ただし、一度決めたルールや考え方にこだわりすぎず、臨機応変に対応すること。
役割
PO（Product Owner）
プロダクトオーナー。プロダクトの中長期的な価値最大化に責任を持つ。
プロダクトの意思決定者なので、権限と責任を持つ一名が担当しましょう。
価値最大化には、いかにコスパの良い施策を計画し、後述のTeamに素早く対応してもらえるかが鍵となる。
短期的な施策ではなく、最も重要なタイミング（例えば2020東京オリンピックの開催期間、など）でプロダクトの価値が最大化されるよう計画を立てること。もちろん状況の変化にあわせて計画自体も疑いましょう。
要点と譲れない条件を明確にし、Teamが実作業に集中できるよう短い時間で説明し切ること。
SM（ScrumMaster）
スクラムマスター。POやTeamを含めたステークホルダーが、スクラムを最大限活用できることに責任を持つ。
POが困っているなら支援します。
Teamが困っているなら支援します。
組織や顧客が困っているなら支援します。
あらゆる人や物事を観察し、プロジェクトが上手くいくことを支援していきましょう。
スクラムを周囲に説くこともありますが、スクラムが合わない状況であれば他の開発方法論を提案することも必要です。
スクラムの最大限活用で誰も困らない状況ならSMは不要だし、SMなしでも関係者が自律的に動けるプロジェクトを築けたら大成功です。
Team
チーム。プロジェクトの生産性を最大化させることに責任を持つ。
必要なスキルを学び活用し、開発生産性を上げましょう。
生産性を上げるための方法をPOやSMに提案し、提案内容がいかに重要かを説明することも大事。
流れ作業的に仕事をするのではなく、プロジェクトにおける責任ある立場ということを胸に刻み、どうやるかのがベストかを考えましょう。
あまり大人数だとコミュニケーションが複雑化するので、5±2人が望ましいと言われています。
スクラムセレモニー
スクラム内でやるべきイベント群。
色々なセレモニーを実施し、スクラムのリズムを体感しましょう。
スプリント（Sprint）
スクラムの中心で、一連のスクラムセレモニーを一巡する期間。長くとも1ヶ月間。
スクラムは「計画を立て、作業と進捗を繰り返し、成果を確認し、改善を考える」という流れを繰り返します。
スプリント内でPO、SM、Teamは自分たちの責任を果たすため全力で仕事を進めていきます。
スプリント内で行われた活動により、プロジェクトの成果が生まれます。
スプリントプランニング（Sprint Planning）
POとTeamの共同作業により、スプリント内で完了させるタスク（プロダクトバックログアイテム）を決めるイベント。
POが求めるタスクの優先順位を考慮しながら、Teamはスプリント内で完了できそうなタスクを見繕います。
POは優先順位の理由や一つひとつのタスクの意味や求めている結果を説明し、Teamは内容理解しようと努めます。
POとTeamが納得し合意できる範囲でタスク群を集め、スプリント内で完了させることをTeamは約束します。
朝会（Daily Scrum）
Teamがより実のある1日を過ごすため、毎日集まって話すイベント。
私は朝会として企画することが多いですが、別に朝でなくとも1日のうちどこかで話せれば問題ないです。
前回の朝会からの進捗や状況の変化を一人ひとり話します。
スクラムガイドでは話す内容の例が書かれています。
- 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
- 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
- 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
時間は15分内で終わりましょう。長く話しすぎると他のタスクに影響してしまいます。
話さないとどうしようもない状態なら朝会している場合ではありません。緊急会議を予定するか、POにスプリントの中止を提案しましょう。
リファインメント（Refinement）
POの責任において、中長期的な状況の変化をTeamに説明するイベント。
状況は常に変化するから、今後必要となるタスクの頭出しや現在決めているルール群（例えば、完了条件や後述するアーティファクト）の見直しを図ります。
スプリントレビュー（Sprint Review）
POの責任で、Teamがスプリント内で生み出した成果に対してあれこれ確認やツッコミをいれるイベント。
誰が意見しても問題ありません。POでもその後ろにいるステークホルダーでも、Teamが自らツッコミしても大丈夫。参加して欲しい人をPOが招待しましょう。
実物ができてはじめて気づくこともあるので、より良い価値を世の中に届けるため、お互い遠慮なく議論しよう。それが改善の糸口となるはず。
ふりかえり（Sprint Retrospective）
Teamの責任で、より良い進め方を考えるイベント。
やり方や進め方はTeamが責任を持つのが望ましく、だからこそTeam自身でやり方の問題を発見し、取り組みを検査し、改善に向けて変化に適応しましょう。
アーティファクト
アーティファクトは、各役割の人がスクラムの中で作り込む成果物です。
SBL（スプリントバックログ）
スプリントプランニングをした結果出来る、スプリント内でのタスク群。
POとTeamがお互い納得し、合意できていること。
PBL（プロダクトバックログ）
プロダクトの価値最大化のため、今後やっていくであろう全タスク群。
一つひとつのタスクはPBI（プロダクトバックログアイテム）と言う。
スプリント内のあらゆるタイミングで追加、更新、削除しましょう。
障害リスト（Impediment List）
スクラム全体をとおして、上手くいかない要因をまとめたリスト。
主にSMが追加、更新、削除、対応することが多いかもしれません。
内容は何でもOKです。
例えば毎回朝会が遅れるとか、自動テストが長い、など。
A.C.（Acceptance Criteria）
PBIの完了をPOが受け入れる条件。POの責任で決めること。
スプリントレビューでツッコミが入ろうが、A.C.が満たされているなら完了は完了。
ツッコミに対するタスクは別PBIとすること。
逆に十分作り込まれた成果物があろうとも、A.C.が満たされていないならTeamは勝手にPBIを完了扱いにできません。POも納得した上でA.C.を変えるなら、そこは柔軟に。
その他
スプリント停止
POの責任で、スプリントを止めること。
スプリントを途中でどうしても止めたい場合、スプリント停止を宣言し、全てをやり直す。
完了条件（Definition of done）
Teamの責任で決める、PBIをリリース可能と判断する条件。
DoneとUndoneの2つの概念がある。
PBI一つひとつで満たすべき条件（例えば単体テストが実施済、関連ドキュメントが作成済、など）は、Done。
PBI一つひとつでは満たせない条件（例えば複数のPBIが揃ってはじめてテストできること、負荷テスト、など）は、Undone。
両方の完了条件を満たしてはじめて出荷可能（リリース可能）と判断する。
リリース可能なプロダクト（Potentially Shippable Product Increment）
A.C.やDefinition of doneを満たしたプロダクト。
おわりに
スクラムの基本的な考え方やルールは把握できましたか？
分かりづらい点やツッコミがあればぜひフィードバックをお願いします。
そして、スクラムに興味があったりすでに取り組みはじめているなら、共に頑張っていきましょう。
時には失敗することもありますが、まずはTry&Errorで良いと思います。
これからスクラムをはじめるなら、別記事も参考になるかもしれません。
それでは、良いスクラムライフを！
