スクラムについて学んだこと
はじめまして、こんにちは！アジャイル型開発経験者の塚田です。
この度、初めてスクラムガイドを学ぶことになり、自分なりに記載されていた内容について理解したことをまとめました。
自分の頭の整理ではありますが、同じく勉強中の方などの理解の一助になれば幸いです。
スクラムの定義
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
1.プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
2.スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
3.スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
4.繰り返す。
ここで挙げられている「スクラムはフレームワークであり、開発手法ではない」ということがポイントとなりそうです。また軽量級フレームワークということで、全てがきっちり決められているわけではないのも重要なようです。
スクラムの理論
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
～略～
スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。
経験主義はなんとなくわかりますがリーン思考って何？となりました。ムダって何を指すのとなりますね。
リーン思考はトヨタ生産方式をベースとした考え方ということです。 ジャスト・イン・タイムとあることから
作りすぎない
待ちを発生させない
を意識するのが良いのかと思います。また、トヨタ生産方式で言われている 「誰かのために」 も併せて念頭に入れたい部分です。
スクラムの三本柱は重要な部分なので掘り下げてみます。
つまりPDCAサイクルということ？と思いましたが何か違うようです。
（Plan（計画）はないけれどCheck（確認）とAction（行動）は同じにみえます。 )
調べてみるとスクラムは OODAループ が近いようです。
なるほど。確かにこちらのほうが近そうですし、アジャイルに近い考え方な気がします。また、スクラムの理論でも言われている経験主義とも合致していそうです。
PDCAサイクルと異なり、任意の段階に戻って再開するというのも面白いと感じました。
スクラムの価値基準
スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
・確約（Commitment）
・集中（Focus）
・公開（Openness）
・尊敬（Respect）
・勇気（Courage）
～略～
これらの価値基準がスクラムチームや⼀緒に働く⼈たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。
重要なのは 「スクラムチームや⼀緒に働く⼈たちによって具現化されるとき」 の部分。誰かひとりではなくスクラム―チームや一緒に働く人たちそれぞれがこの価値基準を持つことで成功した！と言えそうです。
スクラムチーム
スクラムの基本単位は、スクラムチームという⼩さなチームである。スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。
PMは存在せず、３つのロール内にPMが行っている作業が分担されているようです。ロールの詳細を見てみます。
異なる視点を持つため、議論することで「価値は何か」にフォーカスして意思決定ができる、という仕組みです。責任を負うとありますが、明確な責任の範囲を持つわけでなく３つのロールが共通して、スプリントごとに価値のある有⽤なインクリメントを作成する責任をもっています。
スクラムチームが改善を通して成熟していくことで効率的に価値の高いプロダクトを生み出すことができるため、人の入れ替えはあまり行わないようです。
（様々な要因により発生するものなので、できる限り入れ替えないということです）
SMは初めて聞くものでしたが、とても興味深いものでした。
「スクラムの理論とプラクティスを全員に理解してもらえるように支援する」が役割として入っているということは、これを理解していないとスクラムチームがうまく機能しない、より価値の高いものを生み出すことができない、と言えるのかなと思いました。
スクラムイベント
スプリントは他のすべてのイベントの⼊れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運⽤しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を⽣み、スクラムで定義されていない会議の必要性を最⼩限に抑えるために⽤いられる。
イベントは全部で５つ挙げられています。
スプリント
開発を繰り返す期間のこと。1ヶ月以内の 固定の期間 でスプリントごとに変わらない。 この期間の中で、計画、設計、開発、テスト、すべての作業を実施。
スプリントで達成できる自分たちの能力が明らかにされることで、 経験的に 見積も精度に上がっていく。
以降の項目はスプリント内でのイベントになる。
スプリントプランニング
スプリントの起点となる。スプリントのゴールを決め、実行する作業の計画を立てる。
このスプリントはなぜ価値があるのか？
このスプリントで何ができるのか？
選択した作業をどのように成し遂げるのか？
を意識した計画を立てる必要がある。
プロダクトバックログアイテムの中から、これからのスプリントで実行するアイテムをスプリントバックログとして計画する。
デイリースクラム
開発者のための15分のイベント。
スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させる。
進捗報告ではない。
スプリントレビュー
スプリントの成果を検査し、今後の適応を決定する。
完成の定義が守られているため、このレビューは関門としての意味を持っておらず、主要なステークホルダーとプロダクトゴールに対する進捗を話し合う場となる。
「良くするにはどうするか」を議論する。
スプリントレトロスペクティブ
立ち止まって、今回のスプリントがどのように進んだかを検査する。
何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。その結果として、改善のために変更を行う。 スプリントレトロスペクティブをもってスプリントは終了する。
これらのイベントをスプリント期間を5日間とした場合、次のイメージになるようです。
さらに、スプリント期間内にプロダクトバックログを必要に応じてリファインメントを行います。 必要に応じてなので必ず発生するわけではないですが、スプリント期間内にプロダクトバックログの整理します。次のスプリントまたはその次のスプリント分のプロダクトバックログを分解しておき、スプリントプランニングで優先度付けできるようにします。
これらのイベントがスクラムの理論を支えているので、スケジュールとしてきちんと登録しておきたいですね。実際にはスプリントレビューなどは参加者が広いため毎スプリント同じスケジュールは難しいかもしれないですが、
スクラムチームの成長がより価値の高いものを生み出すことを考えると、スプリントレトロスペクティブはスプリントゴールであるだけでなく重要なイベントに感じました。
スクラムの作成物
スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最⼤化できるように設計されている。作成物を検査する⼈が、適応するときと同じ基準を持っている。
各作成物には、透明性と集中を⾼める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。
・プロダクトバックログのためのプロダクトゴール
・スプリントバックログのためのスプリントゴール
・インクリメントのための完成の定義
これらの確約は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在する。
成果物は3つです。その成果物に対する確約が含まれているということですね。
プロダクトバックログ
スクラムチームが行う作業の唯一の情報源。プロダクトが顧客に与える価値を表し、プロダクトビジョンを反映したもの。
プロダクトの改善に必要なものの⼀覧で、機能や要求などを優先順に並べたリストとなる。 TODOリストではなく、全部を行う必要はない。
優先度順に並ぶので上から行う必要がある。
プロダクトゴールはプロダクトバックログに含まれており、残っているプロダクトバックログはプロダクトゴールを達成するために必要な「何か」が定義される。
プロダクトゴール達成のために、プロダクトバックログへ新しいものが追加されることもあれば、不要になるものもあるため、最初から全部がそろっていない。
スプリントバックログ
スプリント期間で対応すると決めたバックログ。プロダクトバックログの上から順に選択したものになる。
「なぜ（スプリントゴール）」「何を（スプリント向けに選択されたいくつかのプロダクトバックログアイテム）」「どのように（実⾏可能な計画）」 と、スプリントバックログの内容が開発者が作業できるレベルまで決まっている必要がある。
スプリント内に全タスクをやらなければいけないわけではなく、本当にスプリントゴールを達成するためにすべてのことをやる必要あるのか？ を考えることが重要。作業が予想と異なる場合は、スプリントゴールに影響がないようにPOと交渉しスプリントバックログのスコープを交渉する。
スプリントゴールはスプリントの唯一の目的のため、スプリントの途中で変更しない。変更しないからこそ、一貫性と集中を生み出し、スクラムチームに一致団結した作業を促す。
インクリメント
プロダクトゴールに向けた具体的な踏み⽯（具体的に動くもの）である。作ったものが部分的に動くのではなく、これまでのものが連携して機能する必要がある。価値を提供するにはインクリメントを利用可能にしなければならない。
スプリントでは、複数のインクリメントを作成可能で、複数のインクリメントをまとめたものをスプリントレビューで提⽰する。
完成の定義はプロダクトの品質基準を満たすインクリメントの状態を示した正式な記述で、これを満たさない限り、インクリメントの一部と見なすことはできない。これがあるからこそ誰の目にも「そこまで出来ている」という共通認識を持つことができる。
一つのプロダクトバックログを共有する複数のスクラムチームがあった場合、完成の定義は共通である必要がある。
この3つの関係性を以下の図に示しました。
プロダクトバックログから選択されたスプリントバックログがスプリントレビューにより検査され、完成の定義を満たしていればインクリメントとなる、というイメージです。
プロダクトバックログがスプリントバックログのもととなるため、イベントにあったプロダクトバックログリファインメントで整理、分解されることは重要ですね。また、プロダクトゴールに合わせて動的に変化するというのは、変化への対応という部分を体現していると感じます。
まとめ
私なりのスクラムの認識としては
スクラムチームという少人数のチームが一丸となることで、より価値の高いプロダクトを生み出していく
スクラムの三本柱を守ることによってプロダクトもチームも改善される
チームが成熟されればされるほど、効率的で価値があるプロダクトを生み出しやすい
「他の人の仕事は関係ない」「自分に責任はない」ではなく、そのチームみんなが関係者であり責任を持つ
になります。まだまだ理解の及んでいない部分もあるので、より勉強していければと思います。
そして学んだ内容を大事にし、スクラムの実践をしていきたいです。
ここまで、お読みいただきありがとうございました！
参考：
執筆者プロフィール： 塚田千晶
ウォータフォール型開発を経験したのち、アジャイル型開発の現場に長く身を置く。
一念発起し転職。SHIFTへ入社。
アジャイルスクラムを学び、スクラムマスターになるべく日々勉強中。
★同日公開の記事はこちら「なんちゃってアジャイルの卒業：経験から学んだ教訓」
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
SHIFTのサービスについて（サービスサイト）
SHIFTの導入事例
お役立ち資料はこちら
SHIFTの採用情報はこちら
PHOTO：UnsplashのNordWood Themes