見出し画像

【LSM】スクラムマスター研修を受けてきた話

あきの/D-En

What is LSM?

Licensed Scrum Master Trainingの略称でScrum.incが主宰するスクラムマスターの研修です。

これを16時間受講した後に試験に合格することで認定スクラムマスターの資格が授与されます。

事前知識

ある程度スクラムやアジャイルに関する書籍を読んでおり、最低限の知識は一通りある状態でした。

業務でもJIRAを使用したチケット駆動や一部のスクラムイベントをチームで取り入れるなどのことはしていましたが、スクラムの型を忠実に行うような本格的なものを行った経験はありません。

研修内容

※ネタバレになってしまうので詳しくは触れません。

今回は対面ではなくZoomを使用したリモートでの研修でした。

以前行っていた紙飛行機やレゴブロックなどでの手を動かすような研修は基本なく、スプレッドシートを用いてワークショップを行うのが主体でした。

全体的にHowやWhatよりもWhyを重視して説明されていたため、新しい発見が多くて聞いているだけで楽しかったです。

気になったことや関係ないことでも各チーム毎に一人ずつコーチがついているので、気軽に質問する事ができたのもよかったと思います。

またちょうど研修日がスクラムガイドの2020が更新された同日だったのもあり、その変更点や背景などを説明してくださったりもしてとても助かりました。

ただワークショップに関してはオンラインという難しい環境下でとても工夫されているとは思うのですが、実際に手を動かすのと比べるとどうしても見劣りしてしまいあまり満足できませんでした。

新しく知った or 学んだ事など

・スクラムガイドはあくまでゲームブック（The Rule of Gameと表紙にも書いてある）

自分たちのチーム独自のPlaybookを作る必要がある。
→チームが変わるたびに改修したり作り直す必要があり、使い回すことはできない。
→メンバー全員がスクラムに慣れているからと言って、いきなりチームが守破離の離になれるわけではない。

・エンタープライズレベルのスウォーミング

組織や会社でスクラムを浸透させたり、アジャイルの考え方を広めるパターンとして紹介されていた。
→ゆめみのアジャイルワンダーランド（委員会）で目指すモデルはこれかもしれない。

・テストチームが外部委託や数ヶ月に一回の場合（スプリント内でテストまで終わらせられない）

まず大前提としてテストはストーリー内に含めるべき。（テストをしてない機能はリリースするべきではない）

テストをやってバグがないことを確認してからリリースすることが大事で、これをしないとそもそも受け入れ条件を満たせたかや、潜在的なバグの含まれた機能をリリースすることになり、将来のベロシティを前借りし負債を残すことにしかならない。

これを基本として、それがどうしても実現できない場合の対処法。
結論から言えばできるところまでやるしかない。
銀の弾丸的なものはなくチームがテストケースを作るところまでを完了条件にしたりするなど現状でできるところまで切り上げるしかない。

それよりもスプリント毎にテストできるように調整するなど、根本的な問題に着手するべき（機能横断的ではないため、そもそもスクラムをやる前提がそろってない）

特にスクラムはストーリーのテスト駆動開発というのがめっちゃわかりやすくて腹落ちしました。

・Q&Aで気になったもの

Q:
銀行さんを顧客とした場合に、契約がどうしてもウォーターフォールを前提としてしまい、社内だけスクラムといった進め方になってしまいます。うまく顧客も巻き込んでスクラムを進めていくにはどのように働きかけていったら良いでしょうか？

A:
銀行側と何を目指すのか？を一緒に共有しながら進めるしかないと思います。
営業提案時点が重要で、ここで進め方を間違えるとウォーターフォールになります。
よく、RFPがでてそれに回答すると思いますが、それをしてしまうとウォーターフォールになってしまいます。
以前、地方銀行の仕事をしてましたが、そこは内製化を進めるために、エンジニアの育成も含めて行っていました。稀な例と思いますが、銀行の方がベンダー側に出向して、一緒にやってました。
銀行の事例ではありませんが、ウォーターフォールのプロジェクトに顧客を巻き込んでいった我々のパートナー会社の事例です。最初はアジャイル、スクラムを強調せずに、お客さんと一緒にふりかえりをして一緒に課題を解決していくところからスタートしたようです。　https://www.agile-studio.jp/post/agile-japan-2019
Q:
受託開発をしている案件をスクラムチームに移行していく場合、依頼元の顧客がステークホルダー 、受託会社のPMがPO、エンジニアチームのリーダーがSMになりますでしょうか？

A:
受託開発をしている案件をスクラムチームに以降していく場合、決まったパターンはありません。仲には顧客がPO、受託会社のPMがSMになるケースもありますし、顧客側にSMにになってもらう事や、若手にSMになってもらう事もあります。ドメインの知識を一番持っていて、権限のある人がPO、チームの障害を取り除けて、チームのムードメーカーになってくれるような人がSMになるのがベストです。

上記の質問は他のチームでもあったのですが、そちらの回答では発注側がPOになるのがおすすめと書いてありました。
個人的な意見としては発注側がPOになってもらう方がいろいろ進めやすそうな気がします。

感想

研修を受けた感想としてはスクラムマスターだけではなく、チームの一開発者として知って欲しいことが多かったです。
（スクラムマスターの役目から考えると当たり前ではありますが）

ちょうどスクラムガイドの2020が公開された日というのもあり、全体的にHowよりもWhyを重視して解説されていたため、今までいまいち理解しきれてなかった各イベントや役割の背景を学ぶ事ができました。それだけで参加してよかったと思います。

これだけ学びが多いとなるとSMだけでなくPOやScrum@Scaleの視点も欲しくなりますが、実際の開発ではスクラムやアジャイルを全然実践・経験できておらず、今の状態で講習受けるのは学びが少なくなってしまいそうなので受けるにしてももっと経験を積んでいろいろな事が見えてきてからになりそうです。

最後に

認定SMになったからと言ってゴールではないし、むしろここからがスタートみたいなところがあると思うので引き続き頑張ります。

現在所属しているチームではスクラムをやっていないので、今回受けた研修内容が直近でフルで役に立つことはあまりないとは思いますが、それでも手の届く範囲から少しずつチームを改善して良くしていこうと思います。

この記事が気に入ったらサポートをしてみませんか？