認定スクラムマスター(CSM)研修を受けました。

はじめに

8月某日、Odd-e主催の認定スクラムマスター研修を受講し、晴れて認定スクラムマスターとなりました!今回は研修の概要や学んだことをまとめたいと思います。

www.odd-e.jp

研修の概要

Odd-eの認定スクラムマスター研修は以前はオフラインでの開催でしたが、コロナ禍のため今はZoomとMiroを使用したオンライン開催となっています。研修中にトレーナーから説明がありましたが、トレーナー側もオンラインでどうやったら良い研修が実施できるか模索・改善を続けているようです。オフライン開催を待つ手もありましたが、現場ではリモート環境が当たり前になっている現状を踏まえ、逆にオンラインで研修を受ける方が面白いと考えて、今回受講に踏み切りました。

研修期間は従来だと2〜3日間だったところ、オンラインでは5日間と長くなっており、月曜から金曜までスクラムを探求する日々を過ごすことが出来ました。いやー楽しかった。トレーナーはMJことMichael JamesさんとAgileコーチの榎本さん。研修中は受講者から多数の質問が飛び交いましたが、どの質問にも本当に丁寧に回答して頂きました。コロナ禍のためオフミーティングは実施出来ませんでしたが、コロナ禍が落ち着いてMJさんが来日された際はお声掛けしてくれるとのこと。楽しみ!

「Certified LeSS Basics」の資格も同時に取得

今回の研修では「Certified ScrumMaster」だけでなく、「Certified LeSS Basics」の資格も同時に取得することが出来ました。Large Scale Scrum (LeSS)は複数チームによるスクラムのためのフレームワークで、Craig LarmanさんとBas Voddeさんが開発したものです。実際に業務で複数スクラムチームの運用をどうするか?について試行錯誤していたところがあったので、今回LeSSのフレームワークを学べたのはとても有意義でした。

スクラムの型

スクラムに関する情報は世の中に多く出回っていますが、中には型から外れていることが書かれている場合もあるとのこと。そのため、参考図書も限定され、きちんとスクラムの基礎・型を学ぶことが重要視されていました。つまり、守破離の守。

教本となったのは以下の4つです。

また、その他参考資料として、MJさんのWebページであるScrummaster.jpLeSSフレームワークのルールLeSS.worksスクラムマスターチェックリスト等が参照・説明されました。宿題として事前セルフアセスメントを実施。

何度もスクラムガイドを読んでいましたし、実際にスクラムっぽい形で開発を実施していたので、それなりに型は理解しているつもりだったのですが今回研修を受けて、いかに自分が"スクラムっぽい何か"でやっていたかを思い知りました…。大事なところの学び直しと間違って理解していたところの矯正が出来て本当に良かったです。

研修中の学びに関するメモ

色々な学びがありましたが特に心に残っているものや学び直したものを、ふりかえりも兼ねていくつかまとめます。 沢山あって書ききれない…!

小さく始める

プロジェクトに投入可能そうな人が多くいると、とりあえず体制表を作って人を組み込み、稼働率を高めてタスクを振りがちになるのが従来の仕事の仕方。スクラムでは大規模開発をまず避けます。最初は1チーム(リーディングチーム)で小さく素早く作り始めて価値を検証することを重要視します。「大規模開発は最後の選択肢」とマーティン・ファウラーさんも言ってます。チームを増やすのは本当に必要だと判断してから。我々はプロダクトを成功させたいのであって、人を忙しい状態にさせたいのではないのです。これは意識しないと従来の仕事になりがち…

スクラムチームのゴール ≠ スプリントゴール

スクラムを活用するには、これらの 5 つの価値基準を上手に実践しなければいけない。個人は、ス クラムチームのゴールの達成を確約しなければいけない。スクラムチームのメンバーは、正しいこと をする勇気を持ち、困難な問題に取り組まなければいけない。

誤読していたのですが、スクラムガイドのここで説明しているスクラムチームのゴールとは、スプリントゴールのことではなく、スクラムチームが目指す目標・ありたい姿のことだということです。ゴールと言えばスプリントゴールと思っていたので読み誤りましたが、確かにここでスプリントゴールの話が出てくるのはおかしい。

ちなみに、確約(Commitment)についても議論があり、コミットという単語が強すぎで開発チームを追い詰める事例が海外でもあったことからCommitmentではなくForecastを使おうという動きがあるとMJさんが補足されていました。元々見積もり困難な仕事に取り組んでいるのに、コミットしたやないかと詰めてもお互い苦しいですよね。

スプリントバックログは開発チームのもの

プロダクトオーナーはプロダクトバックログを管理しますが、スプリントバックログは開発チームが管理します。 プロダクトバックログから過去の経験と直感を元に、スプリントでこなすプロダクトバックログを選択するのは開発チームの役割です。プロダクトオーナーではありません。スプリントプランニングでは、そのスプリントで何を開発するか(What)を決めた後に、どう開発するか(How)を開発チームが考えます。

INVESTのIndependentは優先順位を変えられるということ

プロダクトバックログはINVESTが良いと言われています。

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Sized right (Small)

この中のIndependentは"独立している"や"依存関係がない"という意味となりますが、より目的に沿った意図としては、プロダクトバックログの優先順位を変えられるということです。

A⇨Bの優先順位でしか実現できない場合はIndependentではありません。良いプロダクトバックログコンポーネント単位(横切り)ではなくフィーチャー単位(縦切り)に分割されています。より価値の高いものを優先的に開発するため、A⇨BとB⇨Aのどちらの順番でも実施可能となっていることが求められます。

Doneの定義が組織課題を炙り出す。

Doneの時点でプロダクトがリリース可能な状態になっていないとしたら、そこには組織の課題があります。 例えば、セキュリティテストや品質管理が別部門の管理となっていて開発チームから権限が奪われている状態です。 権限が奪われた開発チームにはその観点の責任が育たないため自己組織化から遠くなります。そもそも何故別部門が必要なんでしょうか。 開発チームが考えるDoneの定義で何故リリース出来ないかを考えることで、組織の課題が見えてくるとのことです。 そうした課題に関しては、5つのWhyで根本原因を考え、組織改善フォームを提出し組織構造を見直すことを支援するのもスクラムマスターの役割となります。

スクラムマスターの仕事は能動的に何もしないこと

スクラムを知っているが故に、チームがスクラムから外れるとスクラムマスターがついつい注意したくなります。導入初期など時にはティーチングも必要ですが、より重要なのはコーチングです。自分たちで気づくまで待ち、チームを観察することが求められます。決して放置ではなく、最も効果的なタイミングで最も効果的な投げ方をするために観察・考える時間がスクラムマスターにとって一番長い時間になります。他スクラムマスターと協力しながら、チームの自己組織化を支援し、組織自体の改善も図っていく。これがまさにスクラムマスターの役割だなと本研修で学びました。

おわりに

今回研修を受けて、スクラムアジャイルが好きだなーと改めて思いました。スクラム楽しい。スクラムの探求も楽しい。そしてスクラムマスターの責任は広いし重い。

"組織の何を最適化するか?"次第なので必ずしもスクラムが適しているとは限りませんが、チームだけでなく組織へのアプローチを認定スクラムマスターとして今後も推進していきたいなーと思います。ではまた。