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

各年、若干ジャンルを揃えて書いているのですが、今年は「私のスクラムマスターとしての失敗記録」を書いていってみようと思います。

去年の12月頃から自分が所属しているチームはスクラムで回していくぞ！！と気合い入れて、この1年間いくつかのPJでスクラムマスターとして仕事をしてきました。その中で、ある時は「自分のしていることって正しいぞ」と思っていることが、期間が経つと「何もかも間違っていたんだが？」ってなるんですよね。マジでめちゃくちゃありました。いや本当にびっくりするんですけど1回とかじゃなくて何回も何回も。こんなに覆るんだってくらい。ネタ帳に書き出してみたら、ちゃんと7つ出揃って笑いました！！

正解はわからないし、今でも間違っていることもありそうなのですが、「間違ってた」って、私の中で「成長」しているんだろうな〜〜と思っています。...................というのは表向きの私の感情で本当の私は「公開するのめっっっっっっっっっっつちゃ恥ずかしいしマジで出したくないな」って思っていますが、だからこそ（？？）、この1年の締めくくりに赤裸々に書いていく💪

あとは、今年はアジャイル・スクラム関連の本を10冊くらい読んだので、その時の罪に合ったり合わなかったりする本を一緒に添えていきます。

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

やりすぎリファインメント

どんな罪か

そもそも冒頭にも書いたのですが、私が「スクラムでやっていってみよう」と思ったのはちょうど1年前頃でした。会社の組織体制が「マトリクス型」になり、他の部署の方も混じった30名弱程度の部署になりました。今までほぼエンジニアとだけのチーム構成でやってきた私にとってはとても新鮮で、この機会をうまく利用したいな、と思っていました。

以前自分が所属していたチームで一部をスクラムを用いてやっていて雰囲気は知っていたので（その頃はDevとしてチームに所属していた）、まずは「何をやっていくか」と「誰とやるか」を集める必要がありました。まずはこの部署でやっていくリリースを部署全員巻き込んで決めて、部署内で数名を募りエンジニア3名＋営業の方＋顧客対応の方でチームを作りました。

▲ まずはトレードオフスライダーを用いてチームの価値基準を決めました。チームで揺れがあった部分については話し合い、チームで持つべき価値観を揃えました。この基準を以て意思決定をしていこうね、という指標ができました。

▲ そして、「プロダクトバックログ」候補を出していきました。黒い付箋がそれに当たります。それ以外の色の枠は「どんなことが叶えられるか」「どの様に使うか」などを話し合った結果をまとめたものです。そして、15個くらいあるな...........めちゃくちゃリファインメントやりすぎだ〜〜〜〜〜〜〜😢😢😢

▲ そして、やりすぎリファインメントに終わらず、「プロダクトバックログ」いくつかをまとめた単位リリースをしていくぞ、どの単位でまとめて出すか、をver.1,2,3くらいまで相談していました...（図としては、黒い星以外のところが1人1人の意見で、黒い星のところが全員の意思として固まったもの）

こんな話、まだ出来上がってもないのにやらなくていい😢

▲ 「こいつリリースしたくないんじゃねぇか！？」と"今の私"は思ったのですが、"過去の私"はこの頃に「いち早くリリースしたい」というマインドを残しています。「他部署の人との初めてPJを組んだから」「この方式で進めるのが初めてだったから」「そもそも前まではプロダクトバックログ全部を1つでリリースしていたのでこれでも小さい単位にはなっていた」とか、色々言い訳はあるのですが今思えば実態としては「やりすぎ」ていたなと思います。

ふりかえり、反省する

スクラムのイベントをちゃんと理解していなかった

「リリースしたい単位ごとにプロダクトバックログをまとめる」という行為自体はプロダクトバックログを優先度順に並び替える、に近いことをしたくてやっていそうです。そもそもスクラムの基本イベントはそのまま忠実にやるべきでした...。なぜやっていなかったかというと、自分の理解が浅いまま始めてしまったので、スクラムで得た知識を使いつつ、リリース予定マイルストーンを立てることが重要だと思っていたのでこの方式をとってしまっておりました。

まずは、スクラムのイベントを忠実にやっていくことが必要でした。反省。

あまりにも先のことを考えすぎている

www.ryuzee.com

プロダクトバックログの上位にあって、直近数スプリント以内に着手しそうなプロダクトバックログアイテムが、スプリントに持ち込めるくらいの状態（これをReadyと呼びます）になっているかどうかになります。

「プロダクトバックログの上位」っぽいものは決めてありそうなので100歩譲ってよかったとしても、「直近数スプリント以内に着手しそうなプロダクトバックログアイテム」以外もリファインメントをしている状況でした。Readyがめちゃくちゃあるみたいな。やりすぎです。

今までの自分たちは「全部決めて全部開発してドカンとリリース」が慣習だったので、それに引っ張られていたところはありそうです。これでも「いち早くリリースするための最低限必要なこと」と思っていました。今、この頃の自分にアドバイスができるなら「とりあえず、一番大事なプロダクトバックログを決めてデモまで持ってこう！！」って言います。まだスプリントでどの程度できるかもわかっていない状態なので、動くものを作ろうぜって伝えたいです。

逆によかったこと

たしかにやりすぎかなとは思うけど、やりすぎたことでチームに何が起こったかが気になる。これまでの慣習を踏襲したことで不安を少なくできた良い動きに僕は感じるから。 https://t.co/GGpCOpxZg3
— SHIIBA Mitsuyuki (@bufferings) 2023年12月18日

ブログを公開したところ、「チームに何が起こったかが気になる」とコメントを頂き、確かに自分のこの動きが良かったこともめちゃくちゃあるな...と思ったので追記します。（すっかり反省モードだったので良いところに触れてなかったw）

やりすぎたことで逆に良かったことは「プロセスやツールよりも個人と対話を」（アジャイルソフトウェア開発宣言）の体現を"全員で"やり始められたところです。「マトリクス型」になったとはいえ、やろうと思えば今までのやり方、「これ開発してください」→「OK〜！」の開発体制でやることもできたはずです。その選択を取らずスクラムを組んだことにより、「何をどう作るか、何が大事か」の対話の部分（今回で言うとやりすぎリファインメント）を同じチームで同じ目線で濃くできた体験は全員にとって新鮮で、「今までより確実に良いものができるのでは...！！」という感覚をチームの全員が感じていました。

あとは「全員を巻き込む」という上ではこの丁寧さが功を奏した部分がありました。同じ部署になったとはいえ、他ロール（営業・顧客対応）の方は定常業務もあります。その方たちに「基本のスクラム」の説明をして基本通り始めても、"勝手に巻き込まれた"という感覚を感じて温度差が起こってしまうのではないか、という懸念がありました。そのような文脈違いを起こしたくないから、今までを踏襲して敢えて丁寧にやる選択をしていた部分もあります。

そしてこの「丁寧さ」が当たりチーム全員のハートキャッチができていたな、と思います。「基本のスクラム」からは逸脱していましたが、「本当にやりたかったこと」である「対話」ができたのは「やりすぎリファインメント」での大きな功績です。

まとめ

スクラムマスターとして、一番初めに犯した罪を紹介しました。

そもそも「スクラム」自体を理解できていないのが一番の失敗ポイントそうです...。今でも「...これって、そういうことか！？（今まで理解できていなかった）」と点と点が繋がる瞬間もあったりするので、スクラムって最初から全部理解するの結構難しいな、という気持ちは持っています。

思い返せばプロダクトゴールもありましたが、リファインメントをする上での基準としては抽象的すぎて使えてなかったな...というのもブログ書いてて反省してました。...てか実はこの頃若干プロダクトオーナー的な位置も担っていそうで、だいぶめちゃくちゃだ〜〜〜〜。新しく何かを上手に始めるのって難しいですね。まぁ！！！いいのだ！！！！！！！人は失敗して成長していく！！！！！！！！

明日も失敗していきます💪💪💪

Today's Osusume Books

SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発

"はじめて「スクラム」をやることになったら読む本！"とあるように、「基本」を理解する上でこれが一番に薦めたい本です！

最初の「基礎編:スクラムってなに？」にスクラムにおけるロール・イベント・作成物・価値基準が漏れず書いてあり、とりあえずここだけ読むだけでも価値がめちゃくちゃありそうです。スクラムガイドももちろんおすすめしたいのですが、個人的には本を先に読んだ方が頭に入ってきやすかったです（図とかもあるからかな）。

その後は「実践編」となっており、スクラムを始める上で迷いやすそうな部分を漫画・具体例と共に紹介されています。やっぱり「漫画」になっているのが良くて、だいぶハードル低くサクサク読めていけるのがこの本のいいところ...！

自分が一番好きだなーというところは「Scene No.04:見積もりをしていく」「Scene No.05:見積もりをより確実にする」あたりの見積もりと向き合う部分です。

そもそも「正確な見積もり」ができないから相対的に見積もりを素早くやろう、という様なことが書いてあります。...書いてあるけど！！最初の方はこの辺の感覚を掴むのがめちゃくちゃ難しかったです...！「見積もりはマジで見積もりでしかないので、確約じゃないぞ」というのを学びました。また「全員でやるのが大事だよね」というのもありますよね。今まではリーダーとして見積もりを全部バーーっとやっていました。今になって考えると確かにこれは良くなくて、初動らへんは正確性高めなのですが、進んでくうちにめちゃくちゃずれていくんですよね...。最初読んだ時は衝撃でしたが、今では、全員の目線が合う様に、いろんな角度から見られる様に、全員でやることが大事なんだな、と強く感じています。

その後の「Scene14:ベロシティを上げていく」とかの話も、「マジで見積もりは見積もりでしかないし、ベロシティは目安なんだぞ」みたいなのを本の中できちんと書いていて！！めちゃくちゃ好き〜といった感じ。

アジャイルサムライ−達人開発者への道

これ、私の「アジャイルなマインド」を濃く作ってくれた本で、すっごいブッ刺さった本です...！！一番好きな本まであります。

▲ 読んだ時にかなり興奮して1on1でめちゃくちゃ喋ったな...と覚えていて、その時のログを引っ張り出してきてみました。

ブログで再度擦りたいところは、「誰もがこの働き方を気にいるわけじゃない」の部分です。画像の中でも書いてある様に、この時期の自分、チームメンバー、部署での働き方の変化はかなり目まぐるしく、私にとっては気持ちいい辛さだったのを覚えています。その一方でこのやり方にストレスを感じてそうなメンバーがいるのも肌で感じていて、進む方向は合ってるのかな〜...と悩んでいた時期でもありました。

警告しておくと「お客さんに価値ある成果を毎週届ける」というのは、気弱な人にはおすすめできない。たとえるなら、アジャイルに開発するというのは、これまで経験したことのないほど強烈なスポットライトを浴びてるみたいな感覚だ。

ここらへんがすごい刺さって、「強烈なスポットライトを浴びてるみたいな感覚」が今までやってきたことと違うから、ストレスを感じるのは当たり前だよな、という気持ちにさせてくれました。個人的にはそのストレスが「ヒリついてる感覚」でめちゃくちゃ気持ち良かったので、言語化されてブッ刺さったところがあります。今では、あの頃ストレスを感じていた人たちも、み〜〜んなヒリつきたがってるので、アジャイルの良さに気づいてそれじゃないと満足できないようになったのでしょう。いやぁ、最高なチームになれたな〜〜(⌒▽⌒)