見出し画像
Photo by kosuketsubota

『スクラムガイド2020』読んで、イベント参加して、今考えたことと今感じたこと

ぐんちゃ

記事の経緯

『スクラムガイド2020』が出た。

このイベントに参加した。

イベント終わった。

よーやんの考えは面白そうなので聞く人は読む人になりたいと思った

よーやんは考えを書く人になる

私も一緒に考えを書く人になる

という。
「他の人が何を考えたか知りたい」「自分が何を考えたか整理したい」という。

きっとイベントのパネラーのかたがたが話していたことの一部しか理解できていないしキャッチすることもできていないと思う。
私が今感じていることは今の私しか書けないので、私が今感じていることを今私が書く(どこかで見たような構文)。

書いてみたらすごく散らかった長文になったが、この散らかりが私が今考えていることなので、このまま投稿する。

スクラムガイドには何が書かれているのか。

 > スクラムガイドにはスクラムの定義が含まれている。p1

「ガイドはガイドであってルールブックではない」という話がイベントで出た

akiさんのブログの「スクラムガイドの活用法」の部分に詳しい。

・感じたこと：
なるほどたしかに地球の歩き方や観光ガイドを絶対視しないよね〜と思いつつも、完全には腑に落ちてはいない気がして、「そうなのね。どこがどう腑に落ちないか言ってみ？一緒に考えよ〜」と仮に言われても言語化できない。というのが今感じていること。

スクラムの定義

> スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。p4

・考えたこと：
「軽量級フレームワーク」となっているのは、「スクラムの理論を実現するために必要な部分のみが定義されている」からまずはそのままこのフレームワーク使ってみ、ということなんだと思う。複雑な問題に対処するためのシンプルなフレームワークなんだという。

ITからの脱却、組閣

「ITからの脱却」「組閣」という章はスクラムガイドにはない。
イベントの中で「ガイドに用いる言葉選び」の話になった。言葉選びにあたっての論点がこの二つだった。

> 成長を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採用されている。そうした状況を見ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専門家もスクラムを利用するようになった。p1

・考えたこと：
上記引用部分に書いてあるような、IT以外のドメインでもスクラムが採用されるようになったことが「ITからの脱却」のことで、組閣の話はえ〜っとなんだったっけかな。たぶんちゃんと理解できていなくて記憶のフィルターをすり抜けてしまった。

> スクラムでは「開発者」という言葉を使っているが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。p1

・考えたこと：
なら私も含まれている。

スクラムの理論

> スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。p4

・考えたこと：
透明性について。「単にぜ〜んぶを逐一見えるようにすること」ではないと思う。それをすることで得られる価値はゼロではないが、きっとそう多くはない。では何なのかというと、私の力では言語化できない。『エンジニアリング組織論への招待』には「情報の透明性」について、こうある。

> 「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性を持って伝達されるように継続して努力し、何かわからない決定があったとしても、それは隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るのではありません。p72

検査について。「潜在的に望ましくない変化や問題を検知するため p5」に検査をするのだから、検査に必要な情報には透明性が不可欠で、情報の透明性には関係性づくりが不可欠なのだと思う。

適応について。「スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。p5」とあり、検知した変化や問題に対して今私に何ができるかをちゃんと自分の頭で考えて、その考えをチームのメンバーに伝えながら日々進めていこうと思う。

スクラムの価値基準

> スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
　確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage） p5

・分かったこと：
ゴールの達成と、互いのサポートの確約。
ゴールに向けてスプリントの作業に集中。
作業や課題の公開。
能力のある独立した個人として尊敬し合う。
正しいことをする、困難な問題に取り組む勇気。
これらの価値基準は作業・行動・振る舞いの方向性である。

・感じたこと：
ライブ前にアイドルが円陣組むやつは価値基準をえいえいお〜ってやってること多そう、と脇道にそれたことを思った。

「アイドル 円陣」でググったら出てきた。

ライブ前に価値基準をえいえいお〜ってやるくらいな頻度でスクラムの価値基準も思い出すルーティンがあってもいいのかもしれない（物理的な円陣は組めない世の中ではあるが）。

スクラムチーム

■開発者
> スクラムチームは、スクラムマスター1 人、プロダクトオーナー1 人、複数人の開発者で構成される。p6

> 開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。
開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。
 スプリントの計画（スプリントバックログ）を作成する。
 完成の定義を忠実に守ることにより品質を作り込む。
 スプリントゴールに向けて毎日計画を適応させる。
 専門家としてお互いに責任を持つ。p7

・考えたこと：
開発者、プロダクトオーナー、スクラムマスターという 3 つにおいて、今の私は開発者の項目に書いてある責務をQAエンジニアとして果たしていくことが求められている。
バックログ作成をするし、完了要件を満たすために必要なものを洗い出すし、スプリント完走のためにいつまでにどの機能がテスト実施可能な状態でテスト実施者に回ってきていればテスト実施含めてDoneになるか考えて伝える。

■プロダクトオーナー

> プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。p7

・分かったこと：
プロダクトの価値を最大化することの結果に責任をもつのがPOでその方法はさまざまであるが、POは一人の人間であって「ステークホルダー委員会の一人一人がPOです！」的なものではない。

■スクラムマスター

>スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクスを全員に理解してもらえるよう支援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。

・感じたこと：
どけかたのわからない大きさや種類の石をどけてもらっていて、「へ〜、そうやってどけるんですね、あざます」という気持ちで日々のスプリントやってる。「スクラムマスターとかがどけてくれるからいいや★」ではなくてどけかたはちゃんと観察していつかの別のプロジェクトで同じような石に出会ったらその気になれば自分でどけられるようにしておきたいところではある。

スクラムイベント

> スプリントは他のすべてのイベントの入れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。p9

■スプリント
> 一貫性を保つため、スプリントは 1 か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。
スプリントでは、
 スプリントゴールの達成を危険にさらすような変更はしない。
 品質を低下させない。
 プロダクトバックログを必要に応じてリファインメントする。
 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。p9

■スプリントプランニング
> スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。p10

スプリントプランニングが対応する3つのトピック(3つともp10)
①このスプリントはなぜ価値があるのか？
②このスプリントで何ができるのか？
③選択した作業をどのように成し遂げるのか？

・考えたこと：
③をするためのスケジューリングはテスト実施までを含めたものにするならその旨のコミュニケーションを日々取っていく必要がある。そしてそれは私から取っていくとうまくいきそうな感じがしている。

■デイリースクラム
> デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。p11

■スプリントレビュー
> スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。p11

■スプリントレトロスペクティブ
> スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。p12

・感じたこと：
それぞれのイベントについては知っていたし参加していたが、それぞれの目的を意識できていなかったことを反省した。なんだか雰囲気で仕事してしまっている。私が理解したり意識したりできるようになるまで時代もプロジェクトも待ってはくれないから、必要と感じたことは自分から取りに行かなければと思った。

スクラムの作成物

> スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最大化できるように設計されている。作成物を検査する人が、適応するときと同じ基準を持っている。p12

■プロダクトバックログ
> プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。p13

・分かったこと：
プロダクトバックログが確約するのはプロダクトゴールであり、プロダクトゴールはスクラムチームの長期的な目標である。

・私の課題：
プロダクトゴールを満たすための要素が漏れなくプロダクトバックログに入っているかはいつどのような頻度で確認していけばいいかちょっと日々考えている。なんかうっかり漏れてそうな不安をどうやって解消していけばいいのだろう。

■スプリントバックログ
> スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。
スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。p14

・分かったこと：
スプリントバックログが確約するのはスプリントゴールであり、スプリントゴールはスプリントの唯一の目的である。

■インクリメント
> インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利用可能にしなければならない。p14

・分かったこと：
インクリメント分からなかったが、分かった気になった。

インクリメントが確約するのは完成の定義であり、完成の定義とはプロダクトの品質基準を満たすインクリメントの状態を示した正式な記述？
インクリメントが誕生するのはプロダクトバックログアイテムが完成の定義を満たしたとき？
ならプロダクトバックログアイテムが完成の定義を満たしていないとインクリメントは誕生しないの？
踏み石、飛び石、マイルストーンは、言葉的にはなんか完成の定義自体ができた時点で誕生している気がするぞ？

と「ん〜分からん★」と混乱したが、incrementか〜と思ったら分かった気になった。なんかたぶん言葉の変な部分に勝手に引っかかってしまっている(私が)。
「インクリメントに追加」って言葉的にはちょっと面白い。まだちゃんと分かってないかもしれない。

スクラムガイド 2017 年版からスクラムガイド 2020 年版への変更点

■自己組織化よりも自己管理
> 以前のスクラムガイドでは、開発チームは自己組織化しており、「誰が」「どのように」作業するかを選択できるとしていた。2020 年版ではスクラムチームの自己管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。p18　

・感じたこと：
「自己組織化よりも自己管理」としているが、「よりも」で結ばれるものなのだろうか。なんかこのへん思考は漂っているけどちゃんと言語化できない。

感想

2年後くらいに読み返して、「当時はここ理解できてなかったり腑に落ちてなかったりしたんだな」と微笑ましい気持ちになりたい。

この記事が気に入ったらサポートをしてみませんか？