スクラムマスター1年生の振り返り

この記事はInsuretechラボ202303アドベントカレンダー企画14日目の記事で書いています。

ラボメンバーとしてスクラムマスターをやってみて早一年。四半期(以降”Q”と記載)ごとに当時の自分がどんな状態だったのかを現時点での自分がふりかえりをしてみたいと思います。
私の目標としてスクラムマスターとしてコーチできるレベルに到達したいというものがありますが、一年でどこまで近づけたのでしょうか・・・。

4月:年初開始

【どんな状態だったか】
・前年度まで他社のアジャイル開発支援に入り、(支援先における)スクラムマスター
経験したことがある状態。
・Scrum.inc主催のスクラムマスター研修を3月末に受講したので、スクラムの基本的な
内容は学んだ状態。

【ふりかえり】
当時はラボ活動でスクラムマスターをやったとしてもそれなりにそつなくこなせて、スクラムに関する質問になんでも答えられるのだろうとのんきに考えていました。スクラムに対する捉え方が軽かったのだなと思います。
心情としては以下のイメージ。

ラボ入りたてで元気!

6月末:第1Q終わり

【どんな状態だったか】
・SlackやMiroなどプロジェクト遂行を円滑に進められる各種ツールのシングルサインオンを実現するための基盤構築検討、当HPのセキュリティ改善にスクラムマスターとして従事。チームとしてスクラムを何巡かした状態。

【ふりかえり】
5つのスクラムイベントとバックログリファインメントは実施するものの、各イベントの意味するところや何をゴールに進めているのかをあまりよく考えずに上面だけをなぞっているだけでした。
仮説検証やインセプションデッキといった開発する前に実施すること、スクラムにおけるレトロスペクティブの色々なやり方があること、感謝の会というチームのコミュニケーション向上イベントのこと等々、今まで知らなかったことの大量のインプットがありました。
過去の経験だけではやっていけないと思い、ラボ内のワークショップに参加して知識を得ることに必死でした。

知らないことばかりで
焦ってきた!

10月末:第2Q終わり

【どんな状態だったか】
・ラボ内の新たなお題によるモノづくりトライアルプロジェクトに参画してスクラムマスター継続。新たなチームでスクラムを何巡かして、今後考えられるお客様に向けたよりリアリスティックなテーマで開発を進め、中盤に差し掛かった状態。

【ふりかえり】
前半は大きく分けて、3つの異なる機能(ラボHP、ペルソナ自動生成ツール、保険関連記事収集ツール)に対する改修に加えて、メタバース調査を1つのチームでやっていました。実質、3つのチームのスクラム活動を1つのイベント枠でやっており、縦割り状態になって開発メンバー同士でのコミュニケーションがとり辛くなりました。
この時に、チームビルドにフォーカスして、メンバー同士でチームの目的は何か、個々人の想いは何かを確認し合えば、カイゼンが図れたのではと悔しさが残ります
このコミュニケーションがとり辛い問題については、開発メンバーからモブプロを試すというアイデアが出て、少しずつ縦割り状態の垣根が低くなっていきました。

後半は、現実的にあり得るテーマで、2カ月でどれだけ素早くDevOpsも考慮に入れた開発ができるかを試行していました。
当時はチーム全体やとりまく環境を俯瞰する余裕がありませんでしたが、スクラムコーチが参画され、多くの気付きをフィードバックいただけました。
強く記憶に残っているフィードバックは以下です。

スクラムコーチ

スクラムガイドに規定されているスクラムの三本柱である「透明性」、「検査」、「適応」がイベントにちゃんと込められているか。

当時、自分はスクラムの三本柱を諳んじることができませんでした。
急いでスクラムガイドを読み直し、今も続くスクラムガイド読み合わせ会を始めるきっかけになりました。
スクラムイベントの見直しとしては、冒頭でイベントを行う目的をメンバーに伝えてから始めるというやり方に切り替えて、自分自身にもスクラム三本柱が浸透するようにしていきました。
今も、意識しないと忘れて目の前のイベントをやることに注力してしまいがちになるので、個人的に要注意なポイントです。

目の前の作業に気を取られて
フィードバックカイゼン
できてない沼にハマる!

12月末:第3Q終わり

【どんな状態だったか】
・第2Qの後半から始めた開発を終えて、次のテーマである仮説検証を体感するツール開発がスタートした状態。詳細は以下の記事をご覧ください。

【ふりかえり】
第3Q後半から第4Q半にかけて、仮説検証を交えた開発を行い、仮説検証パートにおいては私自身も体感したかったのでイチ開発メンバーとして参加しました。
当記事ではスクラムマスターとしての成長にフォーカスすると前置きしていましたが、仮説検証のスキルも自分の目標に加えたいという学びを得られたので触れておきたく思います。

従来、開発に仮説検証を取り入れる場合は、想定されるユーザに対しどのようなものを作れれば良いか仮説検証を先に実施します。今回は、プランニングポーカーとファイブフィンガーができるツールを作るというお題目が決まっていましたので、これは必要だろうと思う機能をユーザーストーリーマッピングで整理し、MVPを決めてから仮説検証に入りました。インタビューを行った結果、そもそも作成したツールのメインターゲットとなる想定ユーザはいないことが分かり、仮説検証を事前に行ったうえで開発をした方が正しいものを正しく作れるのだということを実感できました。今後、開発を行う際は新規でも改修であっても何が課題でどうしていくことがカイゼンにつながるのかを理解するためにも仮説検証スキルを伸長させたいと考えています。

スクラムマスターとしては、スクラムガイドの読み合わせを行い、他メンバーと自分がどう捉えているか意見を出し合って頭の整理をしていました。

やればやるほど
押さえるべき点が
でてくる!

3月末:第4Q終わり

【どんな状態だったか】
・新たなテーマをもとに、2チームに分かれ片方はAWS Amplifyを用いて、もう片方はUnqorkを用いたWebアプリの開発に着手。AWS Amplifyを使った開発のスクラムマスターに従事。
・スクラム練度を上げることを目標にUnqorkのチームのスクラムマスターとコーチと共にコラボレーション方針を検討。
・POの権限移譲を試行するためデリゲーションポーカーを実施し、開発メンバーと共有、移譲の是非についてスプリントを通じ確認中。

【ふりかえり】
今まではラボ内に閉じ、POにフィードバックを受け開発していましたが、ステークホルダーも交え関係者を増やした活動にステップアップしています。2チームで同じものをそれぞれの技術で作っていき、お互いがお互いのステークホルダーとしてよいものを作っていくことに寄与することも大事な要素になっていますので、どうすればお互いのチームをよい方向に導いていけるのか、今も考え中です。まずはスプリントレビューを合同開催してお互いのプロダクト向上につながる意見を言い合おうというところから挑戦中です。

これに加えて、POの権限をチームメンバーに移譲する試みとしてデリゲーションポーカーを実施しました。POの責務一つ一つを整理することはしたものの、本当に腹落ちして実施できたのかはまだ正直なところ分かっておらず、スクラム活動を通じて見直ししようと考えています。
今も新たにPOとの認識にズレが生じるチームになっていやしないかという課題が見えてきており、カイゼンを考えたく思います。

少しずつでもカイゼン
していく!

次年度に向けて~

あっという間に1年が過ぎ、スクラムマスターへの道は一朝一夕で到達するものではないことがよくわかりました。自分が色々分かっていなかったことが見えて、日々悔しい思いをしていますが、これからも過去を振り返り、未来を向き直りして少しずつでも成長したいと思います。最後まで読んでいただき、ありがとうございました。