Scrum Japan のスクラムマスター研修体験記

先日Scrum incのスクラムマスター研修に行ってまいりました。

前日に財布を落としたショックからなんとか立ち直り、二日間の研修で学んだことを箇条書き方式でのメモ報告です。

二日間の全体の流れはこんな感じで学びました。 かなりスクラム用語が含まれているので、意味がわからないかもしれませんがわからないところはググってみてください 😏

#１日目

##スクラムの生い立ち、歴史、自己紹介、チーム作成
役割分担->私はPO（プロジェクトオーナー）に立候補。
今回の研修で学びたいことの、バックログアイテムの作成→今回の学びの中で、該当のバックログアイテムをTodo->Doing->Doneと移動してゆくことにより、何を学んでいるかを意識する

##なぜスクラム？

• 素早くやりたいから
• Waterfallの成功する可能性は２５％。５０％は遅延。残りの２５％は大失敗！
• 定義されたプロセスは、時間が経つにつれて振れ幅が大きくなる。
• 経験的プロセスは、短いサイクルにより結果を検知しサイクルを繰り返す中で改善を加えてゆく

##紙飛行機ゲーム
実際にスクラムを体験。飛行機を３分間で何機飛ばせるかという単純かつチーム力が問われるゲームです。3回スクラムを回し、プロセスの改善を肌で感じました。いろいろ重要なポイントはあるのですが、最重要だなと感じたのは「レトロスペクティブ（振り返りかい）」でした。これにより、今回うまくいかなかったのはどこにあって、次のスプリントではこの部分を改善して試してみよう、的な気軽な改善案の取り入れで、飛ぶ飛行機の数が増えるというトランプでマジシャンにトリックをかけられている風な経験をしました。スプリントは短くないと行けないというのはこの経験からも頷けます。

##スクラムフレームワーク
３−５−３ルール→スクラムの柱となるコンセプトです。これは研修を通じて体得してゆきます。
こちらを参照：https://www.scruminc.com/the-3-5-3-of-scrum/

##スクラムにおけるロールの説明
スクラムチーム
スクラムチームメンバーの最適な数は６〜９人と言われています。各役割はこんな感じです。

• PO（プロダクトオーナー）

  良いPOは「WHAT』を受け持ち、「HOW」はチームに任せる。決してどうやるかを指示してはいけない！
  半分の時間は顧客と過ごし、半分の時間はチームと過ごす。
  POとはプロダクトオーナーの訳で、Storyの中で次に何をやる、ReviewでOKをだすなどといった役割があります。
  プロダクトバックログの優先順位を決める

• SM（スクラムマスター）

  SMとはスクラムマスターの訳で、プロジェクトを成功に導くためのファシリテートをします。
  POをコーチし、パフォーマンスをあげる
  各イベントのファシリテート
  チームを割り込みから守る
  障害を取り除く

• T（チーム）の役割

  Tはチームの訳で、実際に作業を行う人たちのことを指します。
  仕事を完結するために必要な全てのスキルを持っている
  自己組織化：どうやって仕事を進めるかは自分たちで決める
  自己管理：どのくらいできるか自分で決める。
  協調的：全員でゴールを達成する
  各メンバーは３〜９人が望ましい。
  T字型人間である。https://jinjibu.jp/keyword/detl/271/

##スクラムの始め方
スクラムはシンプルだが簡単には習得できない！らしい。（修業っぽいです）
守破離（しゅ、は、り、と読む）の精神だそうです。教わったことに近いことを言っているのはこれ：https://www.weblio.jp/content/%E5%AE%88%E3%83%BB%E7%A0%B4%E3%83%BB%E9%9B%A2
守：スクラムマスターがガイドに沿ってただひたすら実践する。これにより、武道で言う「型」が身に付く。
破：チームのVelocityが少なくとも２倍になった状態。自身の個性が発揮され始める。
離：修行の結果、型に囚われなくても結果がだせ、チームが４００％加速している状態。

→この離の状態に持って行くのが究極の目標ですね。
詳しくはこちらのスクラムガイド：https://www.scrumguides.org/scrum-guide.html

##スクラムの各ステージ
###バックログリファインメント

• プロダクトバックログアイテム→プロダクトを構成するための現在わかっている範囲の全てのアイテム。「プロダクトのビジョン」
• ストーリーマッピング→ユーザージャーニーを可視化

###エクササイズ

• ペルソナを使ったエクササイズ！エピックを一つ選び、そのバックログのリファインメントを行った。
  • お題は「オリンピックに向けて、インバウンド旅行者に、通訳を頼めるサービスを作る！」です。
  • 我々のチームでのペルソナは
    • ベトナム人女性
    • YouTuber
    • オリンピックを視野に入れ、日本でのベトナム料理をYouTubeする
    • 日本語できないため、取材交渉をやってもらいたい
  • このペルソナをもとに、「訪問者、通訳者として待ち合わせを決定したい」というストーリーを選択。このお題をもとに、バックログのリファインメント
    • 追加
      • 自動翻訳チャットシステムの作成
      • 待ち合わせ場所の大体の場所の選択機能
      • お互いをわかるための特徴記述の追加・変更機能
    • 分割（やらなかった）
    • 優先順位付け
      • 追加の順番でOK
• サービスデザインワークショップでも出てきた「ペルソナ」。これは要チェックです！今回は時間が短かったのですが、かなり濃厚な話ができたと思います。今後いろいろ開拓してゆきたいエリアです。

###講義

• エピックをストーリーに分解。さらに優先順位をつける。
• タスク分解
• 良いユーザーストーリーの条件：INVEST
  • Immediately actionable
  • Negotiable->チームが議論できるほど、詳細か？
  • Valuable
  • Estimatable
  • Sized to fit
  • Testable→明確な受け入れ条件があるか？
• どれが良いバックログの状態か？
  

答え）左から３番目。一番右は、「５年というスパンは長すぎ」、左から２番目んは「かなり先まで細分化しすぎ」、一番左は「現在の作業なのに、作業単位に別れていない。現在の作業量をはみ出して、スプリントバックログが設定されている」だそうです。個人的には一番右もいいかなと思いましたが、スクラムでは５年のスパンは長いようですね。

###レトロスペクティブ（振り返り会）

• 今回のスプリントで改善できる点をあげ、次のスプリントの第一優先課題にします。
• これが非常に重要で、スプリントをやればやるほど効率が雪だるましきによくなっていきます。
• エクササイズ→KAIZENを見つける。

###ここで１日目終了！かなり濃厚なトレーニングで、疲れましたが達成感ありです。

#二日目
##エクササイズ→自分のスクラムを作れ!
これなかなかいいエクササイズだと思いました。バラバラのスクラムエッセンスカードがあり、それらを自分の理解をもとに、スクラムっぽくしてゆくというゲーム。(私は田園都市線の遅延により、微妙に遅れて参加しましたので、最初は「一体何が！」状態でした。)
##スプリントプラニング

• ここでは次のスプリントで何をやるかを決めます。
• ピックアップしたストーリーを細分化し、見積もりを行います。
  • こも見積もり作業もなかなか面白かった。チーム全員で、レゴブロックの作成にどのくらいのPOINTがかかるかを提示する。レファランスストーリーとそのPOINTが先に前提として提示された。
    • 「Everything is awesome!♫」のテーマソングが頭の中を駆け巡る。https://www.youtube.com/watch?v=StTqXEQ2l-Y
  • ある関連数字をもとに、近似値であればその平均をとる。近似値でなければ、最小と最大のPOINTを掲示した人の意見を聞く。この時議論してはいけない。単純に意見を聞くだけ。
  • それをもとにもう一で、全員でPOINTを「いっせいのせ！」で掲示する。↓このカードを使って。
    
  • これを近似値になるまで繰り返す。
• 見積もりを行って、前回のスプリントと同様のポイントが次のスプリントでもできるという過程のもと、決めます
• この時、割り込みがどのくらいあるのかBAUがどのくらいの頻度で起こるかなどを予測し、そのスプリントに必要なバッファーを設けておきます。過去３スプリントの割り込みの平均で計算します。

##Daily Scrum

• 昨日やったこと、その日にやること、今困ってることなどを簡潔に話します。
• これは全体で１５分で済ませるものです。
• 立って行う（そうすることで、１５分で物理的に早く終わらせるという状況をつくる）

##スプリント　レビュー
スプリント終了時に、成果物のレビューを全員で行います。

##プロダクトインクリメント
これがスプリントから出てきた成果物です。無い場合もあります。でもほとんどの場合、これはあります。

##リリースサイクル
リリースは早くから頻繁に！というのが目指すところみたいです。↓こんな感じ。

##スクラムボードの注意信号
スクラムにおいて（スクラムに限ったことではないですが）、フレームワークを使い、注意信号を検出するというもの。具体的にボードを見て、これが悪いあれが悪いなど、言い合う場面。

• バーンダウンチャート。よく見かけるこんなやつです↓
  
• 障害物も一眼でわかるようにこのように載せます
  
• その他いろいろな例があり、あーなるほどーとなりましたがここでは割愛！

##一円ゲーム
ここで、細分化の恩恵を肌で感じる一円玉の受け渡しで、３ラウンドにわけてそれぞれ別の方法を使用して実証する。これ非常に面白くて、「おおおお、そうか！」という気付きにつながった。

• 最初のラウンド
  • 片手で１０枚の一円を全部裏返して、裏返し終わったら次の人に渡す。
  • 次の人も渡された１０枚の一円を、裏返し次の人に回す。
  • これを４人繰り返し、時間を図る。
• 2回目のラウンド
  • 片手で５枚の一円を裏返し、それを次の人に渡す。残りの５枚も裏返して次の人に渡す。
  • 次に渡された人も同じ作業を繰り返す。
  • これを４人繰り返し、時間を図る。
• ３回目のラウンド
  • 片手で一枚一円を裏返し、それを次の人に渡す。この作業を残り９枚分行う。
  • 次に渡された人も同じ作業を繰り返す。
  • これを４人繰り返し、時間を図る。
    結果、最初のラウンドはと3回目のラウンドの時間は、劇的に短縮されました。

学んだこと→タスクはできるだけ細分化することで、作業時間が短縮される。

###これで二日目終了！相当詰め込まれましたが、スクラムの良さを体験できました。

#研修後のスクラムマスター試験
オープンブックのテストで、研修内容をしっかり理解していれば、試験自体は簡単でした。私も49/50の結果で、無事スクラムマスター試験をパスしました。オープンブックとはいえ、単純な語彙のテストではないので、やはり研修内容を理解することが必須だと感じました。

#まとめ
スクラムは本では学べないな、というのが今回の研修を受けた後の実感です。実際に体験することが一番良い方法だと思いました。今回学んだことは、今後スクラムプロジェクト（主に準委任契約）に携わるときに、全て実践したい内容なので、自分の理解を深めるという意味でも、早く実践したいところです。

上記研修内容は、私が「スクラム」について学んだことなので、抜けてる部分、誤解がある部分、読んでるだけでは意味不明の部分が多々あるかと思いますが、ご了承ください。今後自分の理解を深めてゆき、OUTPUTしてゆきたいと思います。
また、今回のレポートの粒度が所々で違うのも、自分のそのサブジェクトに対するモチベーションの高さによるものだと思います。あまり自分では面白くないと感じたサブジェクトは、サクッと飛ばしました。

現在社内で、スクラム推進派の同志と社内へのスクラムの普及・啓蒙にて動き始めておりますので、今後スクラムマスターとして社内外での地位を確立して行ければと思ってます。

#おまけ
##その他知っておくべきこと
Context Switching: 複数のプロジェクトを同時進行すると、切り替えに無駄なコスト（時間）を費やしてしまう。挙げられた例では、３プロジェクトに携わっていると、実際は４０％くらいしか実のある仕事ができないらしい。マルチタスキングはしない方が効率的！という見解でした。実際、あるエクササイズを行、実感いたしました。
Swarming: 昆虫が群がる様から来ている言葉で、チームが一丸となってある事象を終わらせることだそうです。これいいですね。チームの一体感とはこういうところから生まれるものではと思います。
##今後の研究課題
スクラムオブスクラム
スクラムマスターのスケーリング
バリューストリームマッピング
ペルソナ