これはNE Advent Calenderの23日目の記事です！毎年会社のアドカレに参加していますが、書く記事を2021年から+2ずつ増やしていき、2023年、ついに7日分の記事を書くことになりました。7日間あすみアドベントカレンダー的には5日目の記事です📚

「この1年、スクラムマスターとして活動していた自分の間違っていたことをふりかえっていくぞ〜〜！！」＆「あの頃読んで好きだった本のOSUSUME〜〜！！」を7日間通してやっています💪

そういえば、アドカレっていつ書くのが正解なんですかね？前日とかそれより前に書いて登録しておく？個人的には"ネタバレ"感あるから当日出したいけど、偉い人みんな前日までに書いてますよね。当日に投稿したとしても正解...？その日のアドベントカレンダーなんだから当日でも大丈夫そうですよね。

まぁ、調べれば出てくるかもしれませんが（あと皆の記事を見ていればわかるかな）、怖いので調べません。ちなみに、俺理論は！！！！！！！！！！！！！！！！！！！！！寝るまでが当日で〜〜〜〜〜〜〜〜〜〜〜〜す！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

では、やっていこう〜〜🍥

うまくいくチーム・うまくいかないチーム？

どんな罪か

next-engine.net

弊社が開発している「ネクストエンジン」はWebアプリケーションですが、ネクストエンジンAPIも提供しています。私が担当することとなった2つのチームは、コアとなっているWebアプリケーション側の開発（以降コア機能）するチームとAPIを使用したWebアプリを開発（以降アプリ）するチームでした。 "解決したい課題"が同じだったため、親和性があることから私がこの2つのスクラムマスターを担当することになりました。

チームビルディング→スクラムを軌道に乗せる→...その他色々...→ と、同じタイミングでそれぞれのチームで成長を遂げていきました。序盤の方はどちらもメチャクチャ調子が良く、開発部の締め会でも両チームとも賞を取るなど勢いがありました。

ただ時が経つにつれ、コア機能を開発をしているチームだけスプリント内にやりたいものが終わらないことが増える様になりました。

両チームのプロダクトオーナーは共通の課題に取り組むため意見を共有し合っていたのですが、その時にも「こちらのチームはうまくいってなさそうだなあ」という雰囲気が漂っていました。

当時のEMにも「うまくいってなさそう」という雰囲気だけが見えており「あすみんが何の仕事をしているかあまりわからない」と言われました。確かにその通りで、うまくいっているチームの方では"プロダクトオーナーの支援"について奮闘しておりEMからはその活動が見えにくかったというのと、うまくいってないチームのほうでは結構マジでどうしたらいいかわからず、アクションが打てずいました。レトロスペクティブはやっているのですが、根本的に解決しているか？と言われると、一歩ずつはカイゼンしているが、根本的には解決していないような...。こんな感じで、実際自分の中でどう思っていたかというと、やっぱりプロダクトオーナーやEMと同じように「うまくいってないのかも」と思っていた面はありました。

自分でも思ってるわけだし、そう思われるのも仕方ないなぁと申し訳ない気持ちと、落ち込む気持ちでした。色々が色々なのでこの時色々辛かった...😔

ただマジで強く言っておきたいのですが、チームメンバーが怠けていたということは一切ありません。毎日真剣に仕事をしていたし、良いものを作ろうと努力していました。ただ結果だけがついてきていないように見えてしまっていただけでした。

ふりかえり、反省する

"チームごとの速度"があることをしっかり認識する・伝える

zenn.dev

自分の認識の誤りに気付いたのは上記の制度でスクラムマスターに相談した時でした。

コア機能の開発とアプリの開発だと開発速度が違う
- 主に"負債"という面でアドバンテージが違う
  - アプリは一から技術選定して令和最新版で作ってあるため"負債"がほぼない状態
  - コア機能の方は10年以上の歴史があるため、それなりに"負債"と戦うタイミングがある
- コア機能の方はPHPのバージョンアップのタイミングと丁度重なり移行のタイミングで色々あって生産性が落ちたタイミングだった
  - これはうち以外のコア機能の開発をしているところも共通でそうだった
チーム単位で見るとはいえ、個人レベルでの技術力に差があるので比較できるような対象じゃない

つまり何が言いたいかというとそもそも別のチーム同士を比較して"うまくいっている"、"うまくいっていない"は測れないということです。たまたま同じタイミングで始めて、たまたま序盤の方は同じようなアクションを適用したら同じようにうまくいって、同じような動きをしていただけなのです。

私自身が、序盤の経験から「同じアクションを適用したらこの2つのチームは同じようにうまくいく」と思い込んでしまい、チームに合わせた動き方をしなきゃいけない、という認識が抜けていました。

大罪〜〜〜〜！！

あの時に戻れるならすること

間違った認識を「それは違う」ときっぱりと主張する
- 別のチーム同士を比較して「うまくいっている」「うまくいってない」を測るのは違う、ときっぱり主張する
- ベロシティを見せてチームとしては速度が落ちていないことを主張する、など
プロダクトオーナーとの期待値調整
- "スコープを削る"がうまくいってない可能性がある（そりゃスプリントごとに「うまくいかない」という感覚になる）
- ここの部分に関して開発者とプロダクトオーナーが話す部分を支援できた
他のチームの人をちょっとだけ借りて入れてみる
- アプリ側が「スプリント内にインクリメントをうまく積めている」理由が他にもあるなら、カオスを求めてペアプロ・モブプロなどで協力してもらうのも面白そう
自分も開発に入る
- スクラムマスターだから開発に関わらない方がいい、という基本の姿勢を保とうとしていた
- だが、チームとして本当にやりたいのは「スプリントゴールの達成」「プロダクトゴールの達成」、ひいては最高のプロダクトが作られること
- インクリメントを積むためにどんな手段でもとってやるぞの気持ちでいいのかもしれない
- （実際に気付いてから自分も手を動かす側に回った）

↑の中でやったやつもあればやれてないやつもありますが、あの時「なんもできねえ」って悩んでいたこと、今になると「まだまだできることはめちゃくちゃあるぞ」という気持ちになるので、あの頃に戻ってもう一度人生やり直させてください、という気持ちになってきたな。なってきました。はい。

まとめ

チームを俯瞰して観察していても、「マジで越えられない壁、悩み」が出てきてしまうことが今後もあると思います。そんな時にスクラムマスター同士で支えていく、相談ができる環境って大事ですよね。

昨日紹介した本、「SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ」にもその様な記述があったのを覚えています。

うちだとまだ一部でしかスクラム取り入れているところがないので、どんどん外から吸収していきたい気持ち...！俺が最強になる！！！そんで組織に浸透させる！！！！！ぞ！！！！！！！ムン💪

Today's Osusume Books

ゾンビスクラムサバイバルガイド: 健全なスクラムへの道

私たちは複数のスクラムチームと仕事をする中で、繰り返し発生する現象があることに気がついた。それは、ほとんどの人が熱意を持って始めたものの、しばらくすると自己満足に陥り、ただただ作業を進めるだけになってしまうということだ。不思議なことに、コミュニティの中でこのことを話したり、上手くいっていないことを素直に認めたりする人はほとんどいなかった。そこで私たちは、何体のゾンビを捕獲し...（省略）

（第1章はじめに）

上記の様な状況になってしまったスクラムチーム、多様な方面のゾンビたちを！！健全な方向に向かわせるには！！の様なことが書いてある本です。

感じている課題感が同じで、それに対してやれるアクションで刺さるものがあったらマジで最高だと思います。実際に起こせるアクションもたくさん書いてあり、さらに良いのはアクションごとに「労力／インパクト比（サバイバルに及ぼす効果）」が"実験"と称してたくさん載っていることです。自分たちが手を出しやすいものから、ハードルが高いがやってみるとインパクトが強く与えられるものなど、チームに合わせたアクションを選択できます。

例えば、第5部の「自己組織化」には「なぜ自己組織化する必要があるのか」「なぜ自己組織しないのか」という記述があり、その中の1つとして「ゾンビスクラムでは、スクラムマスターがすべての阻害要因を解決していく」というものがあります。はああ昨日の私じゃん。ピーー！！！と、いった気持ちになります。

また「探すべきサイン」も一緒に記述されているので、読んでみましょう。

スプリントレトロスペクティブの間、特定したほとんどの課題の解決にスクラムチームはスクラムマスターをあてにしている

スクラムマスターは、ソフトウェアのライセンス管理やJiraのアップデート、チームの事務用品調達、会議室予約といった作業を日常的に行っている

スクラムマスターが、いつもスクラムイベントのファシリテーションを行っている

開発チームは、プロダクトオーナーを含む外部に依存する問題に出くわすと、いつもスクラムマスターが解決している

（第5部自己組織化する）