スクラム開発に関する輪講会を開催しました
こんにちは！NTTドコモ第一プロダクトデザイン部サービス基盤担当に所属している遠藤です。
スクラム開発をより深く理解し、実践に活かすことを目的に、担当内の有志メンバーでスクラム開発に関する資料内容を紹介しあい、内容について議論する勉強会を開催しました。
本記事では、輪講会の進め方や議論の内容、そこから得られた学びについて紹介します。
輪講会の題材
アジャイルコーチの吉羽龍太郎さん（Ryuzee.com）が、スクラムをテーマとしたカンファレンス等の登壇資料を公開されており、その中で「Deep Dive」とタイトルにつく資料の一部を、今回の輪講会の題材とせていただきました。 これらの資料は、スクラムの各イベントやプラクティスについて、実践者の視点で深く解説されているのが特徴です。
今回の輪講会では、以下の5資料を取り上げました。
スクラムガイドの内容だけでなく、現場でよく起きる課題やアンチパターンについても解説されており、 「自分たちのチームではどうだろう？」と考えながら議論する題材として非常に勉強になる内容でした。
以下のリンクにて、その他にも吉羽さんの資料が公開されていますので、ぜひご覧ください。
輪講会の背景
私の所属するサービス基盤担当では多くのチームがスクラム開発を採用しています。
また、サービス基盤担当の所属する部（第一・第二プロダクトデザイン部）の社員は、CSM（Certified Scrum Master）・CSPO（Certified Scrum Product Owner）の取得率40%という目標を掲げ、達成に向けて学習に励んでいます。
このように、スクラムの導入と学習に対し、積極的に取り組んでいる状況ではありますが、
スクラムは「知っている」と「実践できる」の間に大きなギャップが生まれることを、一社員として実感していました。
担当内でも
プロダクトバックログの書き方
スプリントゴールの設定
レビューの進め方
ベロシティの扱い
レトロスペクティブの改善
といったテーマについて、「スクラムガイドの理解はあるが、実践に落とし込めているのか？」という疑問がありました。
そこで、上記でご紹介した吉羽さんのDeep Diveシリーズの資料を題材に、少人数（5名）で議論しながら学ぶ輪講会を開催することにしました。
参加メンバーについて
第一プロダクトデザイン部サービス基盤担当に所属する社員のうち、有志の5名が参加しました。
いずれのメンバも社内向け共通基盤システムのプロダクトに携わっています。
それぞれの立場は以下になります。
Aさん：スクラムチームaのプロダクトオーナー
私：スクラムチームbのプロダクトオーナー
Bさん：スクラムチームbの開発チームメンバ
Cさん：スクラムチームbや他チームのプロダクトオーナー支援
Dさん：スクラムチームa, bや他チームのマネージャー
輪講会の進め方
輪講会はDeep Diveシリーズの資料に沿って、以下のテーマで、1時間 × 全5回で実施しました。
プロダクトバックログ
スプリントプランニング
スプリントレビュー
ベロシティ
スプリントレトロスペクティブ
各回は次のような流れで進めました。
① テーマ解説（約25分）
担当者が事前に資料を読み、
内容の要約
自チームでの実践例
気になったポイント
を紹介します。
※準備時間は最大1時間までとし、参加メンバーの負担を増やさないことを重視しました。
② 個人ワーク（約10分）
資料を読んで、以下の観点で参加メンバーそれぞれが自チームを振り返りました。
おすすめ通りできている点
おすすめ通りできておらず、改善したい点
おすすめ通りではないが、今のままで良いと思う点
③ 意見交換（約15分）
各メンバーのコメントを元に議論します。
例えば
各チームの違い
なぜこのやり方になっているのか
改善できるポイントはあるか
など、実践ベースの議論を行いました。
議論で出てきた主な気づき
1. PBIが「ソリューション」になりがち
プロダクトバックログ（資料：プロダクトバックログ Deep Dive | Ryuzee.com）をテーマとした回では、
「デプロイを自動化する」
「管理画面を作る」
のように、解決策ベースのPBIになっているケースがあるという話が出ました。
本来は
どんな課題を解決したいのか
どんな価値を生みたいのか
といったアウトカム視点で整理する必要があります（資料p.40）。
2. スプリントゴールが不明瞭
スプリントプランニング（資料：スプリントプランニング Deep Dive | Ryuzee.com）をテーマとした回では、
複数のチームで共通していた課題が
スプリントゴールが明確でない
という点でした。
よくあるパターンとして
PBIの集合 = スプリントゴール
になってしまうケースがあります。
スプリントゴールは
今回のスプリントで達成したい価値
を示すもの（資料p.13）なので、より明確に定義する必要があるという議論になりました。
3. スプリントレビューが内向きになりがち
スプリントレビュー（資料：スプリントレビュー Deep Dive | Ryuzee.com）をテーマとした回では、
各チームのスプリントレビューを振り返り、
ステークホルダーの参加が限定的になっている
開発チームからPOへ向けた説明会になっている
といった課題が提起されました。
スクラムのレビューは本来
ステークホルダーと一緒にプロダクトを検査する場
です（資料p.9）。
そのため
開発要望を出したステークホルダーを積極的にレビューに呼ぶ
新機能のデモを見てもらう
といった改善案が出ました。
4. ベロシティの扱い
ベロシティ（資料：ベロシティ Deep Dive | Ryuzee.com）をテーマとした回では、
ベロシティは未完成のPBIについて部分計上などは行わない（資料p.7）
スクラムでは、ベロシティのような「物的生産性」の指標で生産性を評価すべきではなく、「付加価値生産性」を重視すべき（資料p.12）
といった点について議論を深めました。
特に、「付加価値生産性」については、私たちの担当では社内向けのシステムを中心に提供しており、売上などのわかりやすい指標が立てづらいこともありますが、各プロダクトにあった指標で評価をする必要がある、という議論になりました。
5. レトロスペクティブのマンネリ化
スプリントレトロスペクティブ（資料：スプリントレトロスペクティブ Deep Dive | Ryuzee.com）をテーマとした回では、
多くのチームでスプリントレトロスペクティブのフレームワークとして
KPTばかり使っている
という話が出ました。
そこで
Fun / Done / Learn
タイムライン
リーンコーヒー
など、フレームワークを変えてみる工夫が紹介されました。
また、幸福感と人間のパフォーマンス（資料p.29）の関係性についても、各メンバーが実感した経験が共有され、
チームの幸福感や心理的安全性も重要なテーマとして議論されました。
輪講会の最後に「行動宣言」
全5回の輪講会の後、6回目として各自が行動宣言を行いました。
たくさんの気づきがあった中で、スプリントレトロスペクティブにおける
「もっとも役立つものに集中」して適応を計画する
（スプリントレトロスペクティブ Deep Dive | Ryuzee.com P.37）
という考えに沿って、1人1つだけを選んで行動宣言しました。
例：
課題と価値を起点にPBIを作成する
「どんな価値を生みたいか」という視点でスプリントゴールを定義する
レビューに呼ぶステークホルダーの予定を前もって押さえる
ベロシティよりも、付加価値生産性につながる指標を優先して改善する
状況によってフレームワークを使い分けてレトロを実施する
このように
学びを具体的な行動に落とすこと
を重視しました。
輪講会での工夫
参加メンバーからは、輪講会の実施にあたり「ここがよかった」という感想がありました。
少人数（5名）だったため、率直かつ十分に議論できた
異なるチームに所属するメンバーが集まったため、他チームの悩みや工夫を知ることができた
既存資料を活用し、事前の準備時間は最大1時間というルールを定めたため、負担が少なく続けやすかった
次回以降、こういった輪講会を開催する際に工夫することとして、ヒントになりました。
まとめ
今回の輪講会では
既存の資料を活用する
少人数で議論する
行動宣言につなげる
という形で、学びを実践につなげる勉強会を実施しました。
スクラムは「知識」だけでなく、 チームごとの実践と改善の積み重ねが重要と実感しました。
今後もこのような場を継続し、より良いスクラム開発を目指していきたいと思います。
最後までお読みいただき、ありがとうございました！
