こんにちは！
立ち上げからおよそ半年経ってもいまだ二人しかいないアジャイル推進室のメンバーの一人、エンジニアマネージャーの森住（@t_morizumi）です。
今回は表題の通り、SmartHR 社内スクラム勉強会を開催しましたよ、というお話をしていきます。
社内スクラム勉強会開催にいたる経緯
SmartHR では複数チームが関わる開発には Large Scale Scrum（LeSS）を、単一チームで行う開発ではスクラムや、スクラムの一部プラクティスを取り入れた手法を用いています。
しかし、各チームにスクラムマスターのようなコーチ役が必ずしもいる体制ではなく、チームの改善の方向性づけや問題の検知といった部分に課題を持っていました。
そこで、スクラム（とアジャイル）の理念・概念について改めて学習してもらい、その上で自分たちのチームの状況を観察し、最終的には「各チームで改善の方向性づけ、問題の検知を行えるようにする」ことを目的に勉強会を開催することにしました。
勉強会は希望者制で、合計十五人の方に参加いただきました。
社内スクラム勉強会の構成
全七回、各回一時間で進めました。
第一回
初回は講演形式で、スライドを映しつつアジャイルとスクラムに関して以下のような話をしました。
- アジャイルとはなにか
- なぜスクラムが生まれたのか
- スクラムとはなにか
- スクラムのルールはなぜ存在するのか
第二回 〜 第七回
二回から七回は、 スクラムガイド を読み、その箇所に関連する事柄をディスカッションしてもらう形式で進めました。
アジャイル推進室側で議題を用意し、それについて一時間でディスカッション -> 結論の共有という流れです。 （アジャイル推進室の見解、というのも最後に共有しています）
議題は勉強会が開催される前週に共有し、自主学習として以下のことをやってからディスカッションに臨んでもらいました。
- 該当箇所のスクラムガイドを読んできてもらう
- 議題について事前に検討し、自分なりの結論を用意してくる
なお、ディスカッションの議題とアジャイル推進室の見解は、アジャイル推進室のメンバー @kissy と協力して作成しました。
以下に各回の議題をいくつかピックアップして貼っていきます。
気になった議題がありましたら、皆さんもチーム内でディスカッションをしてみてください。もし需要があれば全議題を公開します。
第二回：経験主義と透明性・検査・適応について
- 経験的プロセス制御の実現において、なぜ透明性が重要なのでしょうか？ また、透明性がある状態の具体例を教えてください。
- 経験的プロセス制御の実現において、なぜ検査が重要なのでしょうか？ また、検査できている状態の具体例を教えてください。
- 経験的プロセス制御の実現において、なぜ適応が重要なのでしょうか？ また、適応できている状態の具体例を教えてください。
第三回：プロダクトオーナー / 開発チーム / スクラムマスター
- プロダクトオーナー / 開発チーム / スクラムマスターをそれぞれ何かに喩えてください。また、それに喩えた理由を教えてください。
- なぜプロダクトオーナーは「一人の人間」でなければならないのでしょうか？
- 自己組織化チームとは一言で表すとどんなチームでしょうか？ また、なぜ自己組織化チームである必要があるのでしょうか？
（この回で「議題が調べればある程度わかっちゃう系で簡単かも」という話があり、以降ケーススタディのような形式になっていきます）
第四回：スプリント / スプリントプランニング
- スプリントの長さを固定するのはなぜでしょうか?
- 直近の 3 スプリントをすべてバーンダウンできなかったチームの中で、スプリントを 1 週間から 2 週間に伸ばした方がいいのではないかと議論になっています。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。
- あるチームがスプリントプランニングに丸 2 日かかってしまいました（スプリントは 1 週間）。残りの期間で計画したタスクは全て Done し、PBI は PO に受け入れられました。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。
第七回：インクリメント / 完成の定義
- とあるスクラムチームの PO から、スクラムマスターであるあなたに以下のような相談がきました。「1ヶ月前に完成の定義を作ったのはいいものの、リリース後に完成の定義が満たされていないことがたびたび発覚します。また、完成の定義を満たした PBI であっても、リリースするまでにいくつかの調整を私が行なっています。どうしたらよいでしょうか？」。あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。
- とあるスクラムチームはレシピ検索サービスの Android アプリを製作しています。そのアプリは同じ会社の別チームが開発する Web API に依存しています。スクラムチームは毎スプリント Android アプリをインクリメントとして作成していますが、アプリは実際に Web API に繋いでいるわけではなく、スプリント終了時点ではモック API に繋いでいます。Android アプリの開発が Web API の開発に先行しており、モック API が返すサンプルレスポンスを使用するしかないためです。そのような状況で、あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。
参加者からの感想（抜粋）
- スプリント2週間にしたいって言われたらどうしますか？の講義の直後、講義に出ていないチームメンバーから「2週間にするのってどうですかね？」と提案が来てワロタでした。 色んな人の意見を頭に入れた状態で検討できたので、即効性があってよかったです。
- 養成講座を通して経験的プロセス制御、検査と適応など繰り返し出てくる表現がありケースは違えど繰り返して考えをまとめることができたので身についたように感じた。
まとめ
勉強会の感想を集めるアンケートには「勉強会での学習が実際の業務に活きたエピソードがあれば教えてください」という項目を用意したのですが、それに対して以下のような回答があり、当初の目的であった「各チームで改善の方向性づけ、問題の検知を行えるようにする」は一定程度達成できたのかなと思いました。
- デイリースクラムの目的がスプリントゴールを達成するために検査・適応をすることだと知って、チームの朝会が進捗報告の場になってしまっているのに気づいた。 タイムボックスの計算も始まるようになったタイミングで、朝会で残りタイムボックスと残り想定時間を見るようにしたことで、バーンダウンの確率が上がった。
- 開発プロセスに対してのレトロスペクティブを行うようになった。 スプリントレビューでステークホルダーにもうすぐ着手するバックログを見てもらい、優先順にズレが無いことが確認できた。
また、ディスカッションの議題作成などを通じてアジャイル推進室としても非常に学びの多い勉強会だったので、開催してよかったなと感じています。
余談ですが、スクラム勉強会は二回目の開催を計画中で、ありがたいことにすでに結構な数の参加希望者がいて、アジャイル推進室としてはドキドキしています。
We are Hiring!
SmartHR ではアジリティを意識し、ユーザに価値を届けるために全力になれるエンジニアを募集しています！
選考フローも全てオンラインに対応されています ので、安心してご応募いただければと思います。
