スクラムガイドが2020/11/19でアップデートされたので読んでみました！
前回のスクラムガイドは2017年に書かれたものであるのでこちら3年ぶりの改訂になります。
TL;DR(結論)
- 2020年版ではWhy/What/Howのうち、Why(なぜそれが価値があるのか？）を考えることをより重視化
- 自己組織化から自己管理化へ、チームの壁をこえてWhy/What/Howをチーム全体で考えられるように
- リモートワーク時代、ガヤの価値高まる？
概要
今回読んだスクラムガイドはこちらのリンクから読むことができます。
→ スクラムガイドはこちら(https://scruminc.jp/blog/2885)
上記の記事によると
- スクラムを回すこと自体が目的化している
- エンジニアリング以外で導入したいニーズに添えていない
という大きく２つの課題感にそって今回の改訂に至ったようです。
今回2020年度版で2017年度版からアップデートされた点に,
- スクラムマスターの役割(サーバントリーダー→ 真のリーダー)
- チームはより一丸に（主体をスクラムチームへ、自己組織化→自己管理化)
- スプリントプランニングのトピックの追加 (このスプリントはなぜ価値があるのか？と考える項目の追加
などがあります。
また全体的にHowや方法論的な部分の分量を減らして、Whyにより焦点を当てた形です。
今回はアジャイル開発の基本を振り返りながら2020年のスクラムガイドを読んで気づいたことをまとめていきたいと思います。
前提
アジャイル開発って？
そもそもアジャイル開発とはそもそも色んな開発手法からいくつかの共通項を抜き出してまとめた概念で、先にアジャイル開発手法という物がカチッとあるわけではないです。
人によって様々な解釈があり、現場にあった形での実践が求められる類のものです。
そんなアジャイル開発には幅がある概念ですが共通性として有名なのは、
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を、
という4つの価値です。
そしてその4つの価値の背後には以下の12の原則があります。
〈プロセス〉
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、２〜３週間から２〜３ヶ月というできるだけ短い時間間隔でリリースします。
〈働き方〉
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
〈持続可能性〉
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
〈設計〉
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それにもとづいて自分たちのやり方を最適に調整します。
そしてこうした原則をどう実践するのかが、現場で行われているスクラムであり,
そのスクラムについて簡潔にまとめられているガイドが今回改訂されたスクラムガイドです。
アジャイルソフトウェア開発宣言について詳しくは
アジャイルソフトウェア開発宣言の 読みとき方（https://www.ipa.go.jp/files/000065601.pdf ）
等のipaのリンク等をみてください！
じゃあスクラムって？
スクラムはプロセスそのものではなくて、アジャイルをベースに様々なプロセスやプラクティスを取り入れたフレームワークです。
そして経験を基本においていて、これがスクラムだ！と上から降りてくるものと言うよりは、
やってみてわかったことから、次にやるべきことや試すべきことを自分たちの活動に組み込んでいくという経験主義的な考え方を重視しています。
他の現場やチームで発見されたプラクティスを導入するのではなくて、実践に支えられた知識を元にやってこう！というのがスクラムのベースの考え方です。
そしてそのフレームワークは3つのロール、４つのスクラムイベント、３つの作成物で構成されていると言われています。
- 開発チーム (スクラムマスター, プロダクトオーナー, 開発者)
- スプリント (スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ)
- 作成物 (プロダクトバックログ, スプリントバックログ、インクリメント)
スクラムガイドによると、スクラムとは、上にあげたすべてを備えたものであり、その他の技法・方法論・プラクティスの入れ物として機能するものだとあります。
こちらも詳しくは
スクラムの原則を、いかにして実践するか
（https://eh-career.com/engineerhub/entry/2020/05/12/103000）
辺りにも詳しく書いてあるのでおすすめです。
大きく改定されたところ
Whyに立ち返ろう！
- スプリントプランニングのトピックの追加 (このスプリントはなぜ価値があるのか？と考える項目の追加）
スクラム開発を導入しつつも、計画と実行が完全に分離されてしまって、なんでこの作業やっているのかよくわからないよね、、という状態のままスプリントが進んでいくことがあります。
開発者が、POの人が整理したバックログをただこなす作業者になってしまう状態などは望ましくないです。
逆にPOの人もただバックログを整理するだけの雑用という意識を持ってしまうのは望ましくないです。
ここでよくあるアンチパターンをあげます。
- わからないからとりあえず始める
探索的にわからないからとりあえず進めるというやり方だと、検証が難しくなります。
自分たちの現在位置を把握せず、何がわかって何がわからないまま進めても、一貫した基準を持って現時点をふまえて進めたりしていかなくては、自分たちがやっていることを後で評価したりすることが難しくなります。
- わからないからとりあえず教科書通りに進める
わからないから教科書通りに進めていっても何を目的に進めたのかという部分が定まっていなければ後ほど検証活動を行って精査することができず、積み上げが生まれないです。
そのためにも
** 思っていたのとなんか違うなという気持ちを握りつぶさないでいられるか **
ということが大事かなと感じます。
そしてどれだけうまくいっていないかという現状を早く知れるかということも大切です。
目的や検証することを大事にするために1日に1回は再計画の時間をイベントとして想定するところもあるそうです。
ふわっと進めずWhyに立ち返り、後から見直せるように一定の論拠に基づいて判断を選択していけるようになっていくことがスクラムです。(と認定スクラムコーチの方から習いました）
自己管理化されたチームを目指そう！
自己組織化から自己管理化へ、チームの壁をこえてWhy/What/Howをチーム全体で考えられるように
開発チームの自己組織化からスクラムチームの自己管理化へとはなんでしょうか？
自己組織化とはこれまでのスクラムでよく使われてきたキーワードですが、how（どうやって進めるか）の部分を開発チームが担うという意味に捉えられがちでした。あくまで手法だけの主導権を取っているだけで、自社開発部が社内にいる外注の受託チームのような認識で捉えられているケースもあります。
そうではなくチームメンバーがWhy/What/Howを自分たちで決めるんだという意識を持つための自己管理化です。
そのためにもチームに適切な権限が与えられて自己管理できるような体制ができているが大事です。
また今回のスクラムガイドの改訂では、スクラムマスターの役割が、サーバントリーダー→ 真のリーダーに変更されました。
役割は単なる帽子であり、役職や地位ではない、スクラムマスターがサーバントとしてあれやこれや先回りしてやっちゃうのではなく、リーダーという立場なだけだよということを強調するために真のリーダーという表現に変更されました。
ちなみにスクラムガイドの執筆者によると真のリーダーの意味はサーバントリーダーと同じであるがサーバントに囚われすぎないようにという意味を込めて変更しただけだそうです。
またプロダクトオーナーも何を開発して何を開発しないかやどういう順番で進めるかを決めることが職務ですが、
- プロダクトオーナーが主観的に決めちゃってる
- 開発者も開発に専念したいから積極的に意見しない
みたいな問題が起きて分業化がだんだんチームが分断されたり、仕事が作業化していうという問題もあります。
- チームがそれぞれの職能や経験に基づいて仮説を立てる
- プロダクトオーナーが一人で仮説検証や観察と解釈を行うのではなく、チームでみて考え作る体制を作る
というところが鍵です。
プロダクトオーナーにせよスクラムマスターにせよ、職能や役割の違いはあれど、各々の役割から同じ問題に対して向き合うという姿勢が大切です。
そうした姿勢は問題vs私たちと呼ばれ、個々人に対して目を向けるよりも、同じ問題に対して共通認識をとってサポートし合いながら向き合う姿勢のことを指します。
開発は時間がかかるし頭も使うのにスクラムにおいては開発以外の面でもフルスタックさを要求されてまじ大変だ、、、という感じですね。
分業化してじっくり取り組む方が向いているようなものの時はあえて難易度の高いスクラム開発で取り組む必要はないということでしょう。
スクラム開発は不確実性の高い新規開発を共同で取り組む時に適したフレームワークなイメージです。
でも仮説検証を回す必要性があるようなときは職能や立場を超えて一緒に考えて模索していける体制が必要ってことですね。
リモートワーク時代、ガヤの価値高まる？
こちらはガイドを読んだ上で、リモートワークの時代にどうこれを落とし込めばいいのかなと思った時の自分の考えです。
個々の活動が越境的で自律的に動けるメンバーが理想ですが、リモートワークの人が増えている現状では難易度が上がってしまっています。
リモートワーク下では定期的なコミュニケーションの機会を作るのもコストであり、作業や役割を切り出して渡してしまう方がワークしがちという面もあります。
そんな環境下でもみんなが役割を超えて動けるようになるために、、、
ガヤの価値が上がっていくのでは？と思われます。
###ガヤのメリット的なやつ
- **アイスブレーキング的役割 **
リモートワーク化では顔も合わせたことのない人と働く可能性があります。論理をぶつけ合う必要があるスクラムにおいてはアイスブレイクしたり、意見を出しやすい雰囲気を作っていくことは大切です。
- 役割を中心とした調整から問いを作って向き合うために
役割が固定化されないためにも問い(ガヤ）を投げかけてチームのメンバーが考えるような機会を作っていくことが大切です。
- 言語化される前の解釈の余地、発想の余地を残したイメージを伝えられる
必ずしもかっちりドキュメントやルールを作って言語化して進めていくことが大事だと限りません。
ふわっとした言語化される前のアイデア（ガヤ）などもどんどん投げていく必要があります。
- 非同期コミュニケーションだと邪魔にならない
オフラインだと話している時などにガヤ (チャチャ）を入れられると邪魔になったりしますが、リモートワークのオンライン空間だと非同期に処理できて邪魔になりにくいです。
コミュニケーションコストが上がりすぎないまま、コミュニケーションの総量を増やし、チームの一丸さを出すためにはガヤを入れる人がいることは案外有効なのでは？という提起でした。
まとめ
- なぜスクラムで取り組んでいるのか意識を持ち、スクラムの手法だからと盲目的に従うのではなくなぜそれに取り組むのかという根拠、判断基準に基づいて動く
- 役割を超えていく プロダクトオーナーでなくてもプロダクトバックログを整理できるし、いつ何をやるべきなのか考えていく必要がある 越境して自律して動けるようなチーム化を目指す
- 役割を超えてみんなが動けるように潤滑油となれるガヤ人間は大事
是非スクラムガイド2020は目を通してみてください。
→スクラムガイド2020
参考
以下のスクラムガイドの比較記事は非常に参考になりました！
ありがとうございました。