約1ヶ月スクラム開発したので、スクラムガイド（公式）を読む
はじめに
今月頭に転職し新しい会社（ROXX.inc）に入社して、担当になったプロダクト（agent bank）の開発でスクラム開発を採用していたのでそれについて書きます。
個人的にかっちりしたスクラム開発のするのが初めてで、結構新鮮だったので、スクラムガイドを読みながらスクラム開発について復習しつつ、1ヶ月のスクラムを振り返る。振り返りというか、ちゃんとスクラム読んだよっていう記録。
スクラムをよく知らない人はこれから読む スクラムガイドの日本語訳 を読んだり、ググったりお願いします土下座。
スクラムガイドとは
スクラムの開発者であるKen Schwaber 氏, Jeff Sutherland 氏による公式のルールブック。https://www.scrumguides.org
日本語版の翻訳はMasanori Kadoさん他。感謝
スクラム開発を行なうのなら読むべきらしい。
先にまとめ
全部読んで長かった、ので先にまとめ書いとく。
振り返ると言いつつ後半疲れてほぼ読むだけになった。
「透明性」、「検査」、「適応」がすごく大事 & 大事なことがわかった。
個人的に1ヶ月スクラムに参加してみて、まだその恩恵的なものははっきり実感できてないが、（あと、各イベントにパワー & 時間がかかる）
もう少しすれば実感が出てくるんだろうなという漠然とした感じ。とりあえず、今回おさらいした内容ちゃんと頭に再びスクラム頑張る。
本題
こっから読む。
（適度にはしょりながら読みます。スクラムガイドを読みながら or 頭に入ってる状態で読んでいただければ助かります）
（特にスクラムガイドの内容を要約するとかはしてない）
スクラムの定義
スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
スクラムとは、以下のようなものである。
• 軽量
• 理解が容易
• 習得は困難
「理解が容易 習得は困難」とあったが、「スクラムとは」とか「どう動く」みたいなことはなんとなく分かった。（以前カジュアルなスクラム開発の経験があったのもあると思うが、たぶん初でもすぐ馴染めただろう...たぶん）
が、やはり実践するとなると、チームの一人ひとりが意識して動かないと、しっかり成果を発揮できるスクラムにはならなそうと感じた。（コミュニケーションの取り方だったり、議論を円滑に進めたりとか）
「スクラムは、プロセスフレームワーク」「さまざまなプロセスや技法を取り入れることのできる」と何回も書いてある。確かに、スプリントの振り返りの時とかに毎回 振り返りの方法が変わってた。（みんな毎回同じだと飽きる）
その他の面でも色々とプロセス、技法等の選択肢があるっぽい（詳しく把握してない）
スクラムの用途
クラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人や社会が日常的に使用するあらゆるものに使用されている。
（中略）
スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プロダクト、サービス、所属する組織の管理に広く利用されている。
スクラムの本質は、少人数制のチームである。
確かに少人数チーム。（1チームあたり5人くらい x2チームでやってる）
チームの人数が大幅に増えたらやりずらそうなの、なんとなくわかる。
スクラムの理論
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。（中略） 経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。 （中略） スクラムでは、検査と適応のための 4 つの公式なイベントを規定している。詳しくは、「スクラムイベント」の節で説明する。
周期的に行われるスクラムイベントによって、チーム全体の経験値を確実に積んでいこうとしているのを感じた。
実際に全員でプランニング（見積もり）やレトロスペクティブ（振り返り）を行うことで、チームで情報を共有できる場が作られていた。
下のスクラムイベントのところで詳しく書く。
大事そうなので、3本柱の「透明性、検査、適応」をさらに噛み砕いてまとめてみる。（違ったら教えて）
• 透明性 ... 「何をするべき」「どういう成果が必要」が明確になっており、チーム内でそのイメージが共有されている。
• 検査 ... 「進捗ダメです」を早めに検知できるようにする。
• 適応 ... 「進捗ダメ」などが許容できないレベルになった時に、必要な成果物を調整するなどして、やばくない状態にする。（決して「命を削ってでも間に合わせるべし」とかいう世界ではない。はず）
スクラムの価値基準
スクラムチームが、確約(commitment)・勇気(courage)・集中(focus)・公開(openness)・尊敬 (respect)の価値基準を取り入れ、それらを実践するとき、スクラムの柱(透明性・検査・適応)は現実のものとなり、あらゆる人に対する信頼が築かれる。
なんだかすごくかっこいい文章が書いてあるぞ。
つまり、スクラム開発を進めながら、5つの価値基準（確約、勇気、.etc）を実践すべしということか。
頑張る。
個人は、スクラムチームのゴールの達成を確約しなければいけない。
スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。
全員が、スプリントの作業とスクラム チームのゴールに集中しなければいけない。
スクラムチームとステークホルダーは、すべての仕事 とそれらを遂行する上での課題を公開することに合意しなければいけない。
スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。
スクラムチーム
翻訳文が結構英語文でところどころ読解にパワーいる...
スクラムチームとはなんたるかが書いてあった。
つまり、スクラムチームとは ...
・ 自己組織化されたチーム（ 最善の策を、チーム外からの指示ではなく、自分たちで選択する。）
・ 機能横断的なチーム（チーム以外に頼らずに作業を成し遂げる能力を持っている。）
・ 柔軟 性・創造性・生産性を最適化するように設計されている。
・ プロダクトを反復的・漸進的に届ける。（フィードバックの機会を最大化するため。漸進的に完成プロダクトを提供することで、役立つ可能性のあるバージョンを常に利用可能にする。）
なるほど。
記憶があるうちにフィードバックできるのでありがたいと思います。
プロダクトオーナー
プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。（中略）プロダクトバックログの管理に責任を持つ 1 人の人間である。
（中略）
プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。
「プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。」にしっくりきた。多分そうなってた。
開発チーム
開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。
開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。 その相乗効果によって、開発チーム全体の効率と効果が最適化される。
「インクリメント」は「成果」的な翻訳であってるだろうか？たぶんあっていると信じる。
開発チームの特徴の内容を読むとメンバーそれぞれの専門や得意不得意がある前提で「インクリメントを作成するスキルをチームとしてすべて備えている」「サブチームは認めない」「最終的な責任は開発チー ム全体が持つ」とあり。開発チーム内のコミュニケーションを促進させるルールになってるなーと感じる。
開発チームの規模
開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である。
多すぎても、少なすぎてもダメわかる。
スクラムマスター
スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。
大変そう。スクラム行ううえで要的存在だなと感じた。 まだ具体的に何やってるかよく分かってないが、関わりのある場では、スクラムマスターの調整と開発メンバーの協力で成り立ってるな感があった。頼ろう。
スクラムイベント
スクラムイベントはだいたい開催タイミングと、所要時間が固定されている。
今のチームでは金曜にたくさんスクラムイベントが集まってる。
スプリント
スクラムの中心はスプリントである。
スプリントを構成するのは
- スプリントプランニング
- デイリースクラム
- 開発作業
- スプリントレビュー
- スプリントレトロスペクティブ
今のチームでは1スプリント = 1週間。
スプリントの期間を短め（1ヶ月以内）にするのは、長いとリスクが増えるから。短ければそこまでリスクは大きくならないだろうという考え。だと思っている。
スプリントの中止
スプリントはタイムボックスの終了前に中止できる。（中略）とはいえ、スプリントの中止はめったに発生しない。
なるほどそんな事もあるのかと思った。うちの場合は１週間スプリントなのでそこまでなさそうう & 起きる事ほぼなさそう。
スプリントプランニング
スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業である。
プロダクトバックログから作業を棚卸しして、チーム全体で見積もりを行う場。
作業見積もりする際に曖昧だったりすると、割としっかりタスクを完了するためにどういう方法でやるかまで話してる。
全員で見積もりを行うので、詳しくない分野への見積もりも求められるので、慣れないと負担に感じるが、重ねるたびに「透明性」が上がるんだろう。
ちなみにプランニング時にはプランニングポーカーが採用されている。やってみたかったやつやれて嬉しい。
スプリントゴール
スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するものである。（中略） スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。（中略） スプリントゴールがあれば、開発チームは一致団結して作業ができる。（中略） 開発チームの予想と異なることが判明した場合は、プロダクトオーナ ーと交渉してスプリントバックログのスコープを調整する。
これちゃんと把握してなかった。
「スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる」なるほど、確かに。ここで「適応」を発揮する。
デイリースクラム
スプリントでは、毎日デイリースクラムを開催する。開発チームは、次の 24 時間の作業を計画する。前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化するのである。（中略）
開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。 （中略）デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物 を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向 上させるものである。これは、検査と適応の重要なイベントである。
思いの外長かった、（つまりそれだけ大事なんだろう）
直近の出来事について話す事で「検査」「適応」を活発化させる的なことかな？毎日のイベントになるが作業化せずに、どういう場かちゃんと意識しながら行うのが大事そう。
スプリントレビュー
スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。（中略）
これはステータスミーティングではなく、略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。
開発チームから代表者とスクラムマスター、プロダクトオーナーでやってた気がする。
スプリントレトロスペクティブ
スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。（中略）
スクラムマスターは、このミーティングがポジティブで生産的になるようにする。
結構好きな会だった。（個人的に課題について話すのが好き）
（が、所要時間オーバーしがちなのでなかなか難しい）
組織改善の場として結構重要な場になっていると感じた。
レトロスペクティブの目的は下記の3つ
- 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
- うまくいった項目や今後の改善が必要な項目を特定・整理する。
- スクラムチームの作業の改善実施計画を作成する。
スクラムの作成物
スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するものである。スクラムで定義された作成物は、全員が共通理解を得るために必要な情報の透明性を最大化するように設計されている。
プロダクトバックログ
プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。プロダクトに対する変更要求の唯一の情報源である。（中略）プロダクトが存在する限り、プロダクトバックログも存在し続けるのである。 （中略）プロダクトバックログは生きた作成物である。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。 複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述する。 （中略）プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。 開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。
プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。
プロダクトバックログ大事覚えた。
バックログの管理はAtlassianのJIRA使ってる。
ゴールへの進捗を追跡する
いずれかの時点で、ゴールに対する残作業を合計する。
スプリントの期間が1週間なのでデイリースプリント時にたまに進捗の見通しを立てる程度だった。
スプリントバックログ
スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、次のインクリメントに含まれる機能と、その機能を「完成」したインクリメントにして届けるために必要な作業について、開発チームが予想したものである。 スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。（中略）スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。
（中略）スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。
スプリントの進捗を追跡する
スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立 てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。
インクリメント
インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックロ グアイテムを合わせたものである。スプリントの終了時には、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。 プロダクトオーナーがリリースを決定する/しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。
インクリメント = 完成している、リリース可能な（ちゃんと動作する）成果だと理解した。
作成物の透明性
スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物の透明性が不完全であれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。 （中略） スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。
「透明性は一夜にしてならず。透明性とは長い道のりなのである。」かっこいい文章。ただ、実際にやってみた感想はこのかっこいい文章の通りっぽいと実感した。
「完成(Done)」の定義
プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれないが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。 （中略）インクリメントの「完成」の定義が開発組織に存在しない場合は、スクラムチームの開発チームはプロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。
「完成」の定義にも「透明性」が重要。
終わり
長かった。来月以降も頑張る
