画像生成AIによる「楽しくスクラムを組む」の様子
こんにちは、フォースタートアップス株式会社のエンジニアの八巻（@hachimaki37）です。
Scrum Inc. 認定資格スクラムマスター研修を今年5月に受講し、Registered Scrum Master™認定資格（以下、RSMと呼ぶ）を取得いたしました。この研修で習得した知見や技術を活かし、思考錯誤しながらいくつかトライを試みています。
今回のテックブログでは、RSMやスクラムの概要について簡単に触れ、RSMを取得してから行った取り組みを書いていきます。
※RSMの講義内容やトライした結果の効果測定についてはあまり触れていません。その点にご了承頂けますと幸いです。
目次
前提
チーム
現在弊社では、2つのプロダクトチームがあります。以下、私が所属するチーム（以下、チームと呼ぶ）の紹介です。
- エンジニア：3名（うち私が、スクラムマスターを兼任）
- デザイナー：2名（うち1名が、PdMを兼任）
機能横断型のチームです。得意領域を超えて横断的に開発を進めています。
開発手法
スクラム開発（以下、スクラムと呼ぶ）を採用しています。すでに数年単位のスクラム経験があるエンジニアメンバーで構成されています。
プロジェクト管理ツール
Zenhubを使用しています。Issue管理をはじめ、スプリントレポート（バーンダウンチャート）などを確認することが可能です。
出社形態
週3日出社、週2日リモートのハイブリッドな勤務形態を採用しています。また、チームの出社日は曜日固定、出社日に合わせてスクラムイベントを組んでいます。そのため、対面での対話が非常に活発なチームです。一方リモート日は、開発を中心に集中できる機会を作り、狙いを持って出社とリモートを切り分け進めています。
背景
なぜ、認定資格スクラムマスターを取得しようと思ったのかについて、少し背景をお話しします。理由は2つです。
- なんちゃってスクラムを脱却したい
- 私のスクラム歴は5年ほどになります。ただスクラムをしっかり学んだことはなく、なんちゃってスクラム（スクラムの手法や目的、イベントなどは知っているが理解はあまりしていない）の状態でした。そのためスクラムをしっかり学び、スクラムチームとしての変貌に貢献したいという想いがありました。
- チームの生産性向上に貢献してアウトカムを最大化したい
- アジャイル宣言の背後にある原則 に記載があるように、「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」そのためには、どんなチームであるべきか、どのようにチームを導いていくのか、生産性はどのように上げられるのか、自己組織化へのステップはあるのかなど、認定資格スクラムマスターを取得することで、これらのヒントや解答が得られ、チームに還元できるのではないかと考えていました。
こんな背景があり、会社から研修のチャンスをいただきまして受講に至りました。
RSMの選定理由
詳しい説明は割愛させて頂きますが、RSM以外にも2つの認定資格スクラムマスターが存在します。有名どころですと、Certified ScrumMaster®（CSM®）ではないでしょうか。
それほど大きな理由ではないかもしれませんが、以下条件にて認定資格スクラムマスターを調査していたところ、RSMが条件に合致したため選定しました。
- オフラインである → 講師の方にたくさん質問ができる、横のつながりを作れる
- 日帰りである → 諸事情
- 実用性が高いか（体系的に学べるか） → 実業務で活用したい
RSMについて
概要
Scrum Inc. 認定資格スクラムマスター研修はスクラムの共同考案者であるジェフ・サザーランド博士によってつくられました。
このコースの受講者は、何十年に渡り、世界中のビジネスの現場でハイパフォーマンスなスクラムチームを立ち上げてきた、博士の洞察や戦略を自らのものにすることができます。
この2日間のコースは、体験型のワークショップを含み、活気で溢れています。
オンサイト（集合型）研修では、様々な背景を持った参加者が同じ場所に一同に会し、模造紙や付箋紙、ペンなどを使いアイデアを共有しまとめていきます。
リアルな場での濃密なコミュニケーションを通じ、クラスの参加者のもつ力を最大限に引き出します。
引用元：https://scruminc.jp/training/master/
私が受講したコースでは、参加者は約40名ほど、1チーム5名前後のチーム構成で2日間を共に過ごします。私のチームでは、2名がスクラム経験者（私を含む）、他3名はスクラム未経験者でした。
コースに参加してみて、体験型のワークショップの多さに驚きました。今思えば、座学よりも体験型のワークショップの方が多かったようにも思います。
実用性の高いさまざまなワークショップが用意されており、実際の活用イメージが膨らみました。またチーム内のメンバーに留まらず、チーム外の方々ともコミュニケーションを取れる機会や情報共有の機会、議論、講師の方へ気軽に質問ができる環境であり、非常に価値のある2日間だったように思います。
前置きが長くなりました。本題はここからです。
コースにて、重要だと感じた点を掻い摘んで説明いたします。
価値観
「5つの価値基準」と「経験的プロセスによる3本の柱」という概念がスクラムにはあります。これらについて、簡単に説明します。
5つの価値基準
- OPENNESS（公開）
- RESPECT（尊敬）
- お互いに能力のある独立した個人として尊敬し、一緒に働くひとたちからも同じように尊敬される。
- COURAGE（勇気）
- 正しいことをする勇気や困難な問題に取り組む勇気を持つ。
- FOCUS（集中）
- ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。
- COMMITMENT（確約）
- ゴールを達成し、お互いにサポートすることを確約する。必ずゴールを達成しなければならないというよりもゴールを達成するために最大限の協力と努力を尽くすことが重要。
経験的プロセスによる3本の柱
これらの概念がスクラムチームを下支えすることで、スクラムの成功に繋がっていきます。
基本原則
- 機能横断型チームであること。つまり、作業を完了させるために必要な全てのスキルをチームで有している。
- 最善の案を自分たちで決定する自己組織的チームである。
- スクラムチームは、開発者（以下、Devと呼ぶ） + スクラムマスター（以下、SMと呼ぶ） + プロダクトオーナー（以下、POと呼ぶ）で構成される。
- それぞれの役割の責任を果たしつつ、お互いに協力してスクラムチームのゴールを達成する。
- スクラムチームが最小単位で、サブチームは存在しない。
スクラムチームのゴール達成に向けて、それぞれの役割を果たし、最善の案を自分たちで決定しながら進んでいくことが重要です。
3つの役割
- PO
- なぜ（Why）と何を（What）に責任を持つ。
- プロダクトやチームの存在意義、魅力的なプロダクトビジョンの策定、顧客へ価値を届けること。
- など
- SM
- プロセスに責任を持つ。
- 障害物を取り除くためにプロセスを改善する。
- Dev、PO、組織のパフォーマンスを向上させる。
- スクラムイベントを効果的に繰り返すファシリテート。
- 作業の見える化、チームや組織のゴールを達成させる。
- など
- Dev
- どのように（How）に責任を持つ。
- POが決めたWhatをどのようにインクリメントするか。
- スプリントの作業計画、スプリントゴールを達成するために毎日の作業計画を状況に応じて適応させる。
- 完了の定義を忠実に守ることで品質を作り込む。
- など
スクラムチームには、これら3つの役割と責任があります。
5つの仕組み
- スプリントプランニング
- デイリースクラム
- バックログリファインメント
- スプリントレビュー
- スプリントレトロスペクティブ
シンプルなルール
スクラムの価値基準を尊重し、3-5-3のシンプルなルールに沿うことで、胸を張って「スクラムを実践している」と言うことができます。
スクラムを語るには、2つの概念を知る必要があります。
- リーン生産
- アジャイルマニフェスト
- 個人との対話
- 動くプロダクト
- 顧客との協調
- 変化への対応
スクラムは新しく誕生した考え方ではなく、トヨタ生産方式からインスパイアされ、今の形になったようです。スクラムをシンプルにいうと「軽量なデリバリー（価値を届ける）のフレームワーク」です。個人と対話し顧客と協調することで、より価値の高いものをチームで届ける。そのような考え方が、スクラムであると理解しました。
トライしてみたこと
いくつか取り組みを紹介いたします。スクラムの5つの価値基準や3本の柱を意識して、トライしてみました。
スクラム勉強会の実施
認定スクラムマスターが伝える「体験で学ぶスクラムのあれこれ」と題して、社内のエンジニア向けに勉強会を実施しました。
※スライドの枚数が多くなってしまいましたが こちら
勉強会の目的を「新たな気づきを得る機会」としました。2つのプロダクトチームでスクラムを採用しているため、少なからずスクラム経験があるエンジニアメンバーです。参加者同士で、たくさんの学びや気づきを共有し、個人やチームの改善に活かしてほしい。スクラムのポイントを押さえ、コースで行った一部のワークとディスカッションを体験頂く内容にしました。
スクラムイベントの目的と開催日時を整理する
今までチームのスクラムイベントには、明確な目的がなかったのではないかと考えています。なぜやるのか、何をやるべきか、何を共有すればいいかなど、チームは少し右往左往していたようにも感じています。そのため、方向性と立ち戻りのために「目的」と「アジェンダ」を再度整理し、スクラムイベントをファシリテートするようにしました。
またスクラムイベントの開催日時を整理し、極力フロー状態（活動を行っている人がエネルギーに満ちた集中力、完全な関与、楽しさの感覚に完全に浸っている精神状態を指す）を継続的にチームで確保できるように工夫をしています。
以下、目的とやることを整理しています。ご参考までに紹介いたします。
スプリントプランニング
- 目的
- やること
- スプリントゴールとスプリントバックログを作成する。
デイリースクラム
- 目的
- 進捗を議論し、障害物を特定する（進捗共有だけの場ではない）。
- やること
- 昨日やったこと。
- 本日やること。
- 困りごと。
- その他（確認や共有事項）。
バックログリファインメント
- 目的
- スプリントバックログを作成することができる準備完了（= 受け入れ条件が明確）のPBI（プロダクトバックログアイテム）を1~3スプリント分を用意する。
- やること
- トピック（スプリントレビューでのフィードバックなど）の共有。
- 議論/相談ごと。
- PBIの必要な労力を見積もる。
- 完了できるサイズに分割し、必要に応じて優先順位を並び替える。
スプリントレビュー
- 目的
- やること
- 進捗報告、共有事項や確認、相談を行い、ユーザーやステークホルダーの反応とプロダクトのフィードバックを収集する。
レトロスペクティブ
- 目的
- 作業の品質と有効性を高めるためにプロセスを検査する。
- やること
- スプリントの振り返り。
- 次のスプリントでトライしてみる1つ以上の改善を特定する。
少しの余剰をスプリント毎に作る
予測不能な事態への対応
開発中に予期せぬ問題が発生することはよくあります。余剰を持つことで、こうした問題に柔軟に対応でき、スプリントが大きく遅延するリスクを減らすことができます。
持続可能なペース
スクラムの一つの原則は、持続可能なペースでの作業です。余剰がないと、チームが無理をして短期間で成果を出そうとし、結果としてバーンアウトや生産性の低下につながる可能性があります。余裕があることで、健全な作業ペースを保ちつつ、質の高い成果物を提供することができます。
品質の向上
余剰を設けることで、コードレビューやテスト、リファクタリングに時間を割くことができます。これにより、最終的なプロダクトの品質が向上し、長期的なメンテナンスや技術的負債の軽減につながります。
チームの柔軟性
スプリントの途中で優先度が変わったり、新しい要求が入ったりすることがあります。余剰を持つことで、チームはこうした変化に柔軟に対応でき、顧客やステークホルダーの期待に応えることができます。
取り組みたいことへのチャレンジ
新しい技術への挑戦や調査、チームのカイゼン、知識の整理や深化などに時間を当てられ、チーム、個人としての成長機会を作ることができます。
やらないことを決める
割り込みをなるべく回避することを行なっています。一例では、スプリントゴールに明示したり、課題に優先順位をつけて「やること」、「やらないこと」を明確にしています。これは、価値あるアウトカムに「FOCUS（集中）する」ためです。
一方個人では、あれもこれも手をつけてしまい、怒涛の数ヶ月を過ごした経験があります。そこから少し改善を試みています。
一つは、極力ボールを自分で持たない。当たり前かもしれませんが、素早く相手にボールを返すことやIssue化してチームで対応するようにしました。また、これに尽きるなと感じたことがあります。それは、「優先順位をつけてさばく」です。来たものを捌くではなく、来たものを「優先順位をつけてさばく」です。つまり、今やる必要があるのかを問うことです。後でやっても問題ないものは、逆に言えば今やってもそんなに意味がありません。そのため、スコープから外してシングルタスクにすることで、負荷認知が激減し、少しうまく進められたように感じます。
株式会社カケハシ エンジニアリングマネージャーの小田中さんが書かれた記事は非常に学び深かったです。
時間がない…と嘆きがちなマネージャーに読んでほしい、割り込みタスクをなんとかする方法｜dora_e_m
情報共有の機会をより多く設ける
いわゆる情報の透明性と新鮮さを向上させることです。スクラムの価値基準でいう、OPENNESS（公開）です。いくつかの取り組みを紹介します。
- スプリントレビューの共有をバックログリファインメントのアジェンダに入れる。
- （優先順位が変わり）スプリントバックログが入れ変わった場合、理由や意図をチームに共有する。
- デイリースクラムにて、スプリントゴールの達成予測をチームに伝える。
- 別チームのスクラムイベントに参加し、学びや気づきをチームに共有する。
- 「チームから別チーム」のスクラムイベントに参加してみたい方を募る。
- 逆に「別チームからチーム」のスクラムイベントに参加してみたい方を募る。
- など
プロジェクトを完了させ、次に行く
極力チームレベルでマルチタスクによるコンテキストスイッチを回避し、なるべくプロジェクトの進行をシングルに保つようにしています。その結果、プロセス効率が劇的に変わり、顧客への価値提供スピードも向上していくと考えています。
あとがき
いかがでしたでしょうか。試行錯誤の真っ只中ですが、いくつかの取り組みを紹介させて頂きました。最後に、アジャイル宣言の背後にある原則 から私の好きな文脈を紹介して終わりたいと思います。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
こんなチームになっていけたらもっと新しい未来を創造できるチームになっていくのではないでしょうか。楽しくて仕方がありませんね。そんな未来を創造しながら、また楽しく励んでいきます。
Q&A
スクラム関連でのQ&Aをいくつか記載いたします。ご参考になれば幸いです。
Q1. ワーキングアグリーメント（チームの決め事）は、適宜変化しますか。
A.イエス。チーム編成や構成によっては新しく変えても良いです。必要に応じて、むしろ変えるべきです。
Q2. デザイナーやカスタマーサービスの方々などは、スクラムチームに入るべきでしょうか。
A.イエス。スクラムの役割の「開発者」は、何かモノを作っているエンジニアだけのことを意味していません。チームが生み出すプロダクトやサービスに対して、作業してインクメントにする人を全て「開発者」という用語で一括りにしています。従って、チームによっては、デザイナー、運用者、プロダクト営業の人も「開発者」としてチームに入ることはあります。イネーブルチームや、特殊高度スキルチームのように、特定のスクラムチームの活動に常時でなく、一時的、または、バックログアイテムの一部のみを請け負う方が効率的な場合もあります。この場合は、一時的にスクラムチームに入ったり、別の専門チームになることもあります。
Q3. スプリントゴールは、ワクワクしたゴールに設定した方が良いのでしょうか。
A.ノー。何を成し遂げ、何をインクリメントしたいのかを明確に決めるべきです。手に入れたいゴールを明確にした方が良いです。
Q4.ある一定の条件を満たさなければ、スクラムチームにはなれませんか。
A.ノー。スクラムチームのゴールに向かって、最大限の協力と努力を尽くすことが重要です。
Q5. スクラムチームでいうパフォーマンスとはなんでしょうか。
A.1つは、チームでインクリメントの量をあげること。2つ目は、フィードバックを回して価値のあるものを届けること。3つ目は、スクラムチームとしてのマインド面を上げていくことです。
Q6. 顧客価値に繋がらないIssueは、スプリントバックログやプロダクトバックログには入れてはダメなのでしょうか。
A.ノー。アーキテクチャやシステム設計、バグ改修、調査なども入れるべきです。
Q7. スクラムでいう障害とは、何を指すのでしょうか。
A.スクラムチームの作業や進行を妨げる要因や問題のことを指します。例えば、技術的な問題、外部からの干渉、コミュニケーションの問題、プロセス上の問題などです。障害物を取り除かれるように働きかける必要があります。
参考資料
