はじめに
この記事はNTTコムウェアAdvent Calendar 2024の19日目の記事です。
NTTコムウェアの森です。
私は前職でウォーターフォールを経験し、転職後約3年間スクラムマスターを担当しています。
スクラムのベストプラクティスを学び、他スクラムマスターとの交流や、何案件かでスクラムを経験する中で感じた、
- 「現場でベストプラクティス通りうまく回すため、どうあるべきか」
- 「実際はベストプラクティス通り上手くいかないこと、どうあるべきか」
- 「スクラムマスターとして求められる能力とは何か」
をつたない経験かつ主観にはなりますが、この記事を通してお伝えできればと思います。
※当記事で記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。
◆筆者の保有資格・経歴補足
-
Scrum Alliance認定資格
-
他スクラムマスターからの引継ぎ経験や、一からのスクラム立ち上げ経験あり
-
他スクラムマスターとの交流あり
-
アジャイルコーチとの協働経験はないものの、過去にコーチが入っていた案件の担当や、座談会への参加経験はあり
-
フロントエンドの案件経験は少ないため、フロントエンドのスクラムとは意見の相違がある可能性があります。
記事の想定・読者対象
- 単一のスクラムチームを想定(複数スクラムチームの運営は除外)
- スクラム開発の用語が何となくわかり、スクラム開発に興味がある人
- スクラム開発を行っており、他チームやスクラムマスターの現場ノウハウ・考えを知りたい方
- スクラムマスターとしてのキャリアの参考に、スクラムマスターに求められるスキルを知りたい方
上述の通り、筆者がアジャイルコーチではないこと、かつ当記事は主観であることをご留意いただき、ご一読いただければと思います。
目次
1.うまく回っているチームはこうしている！ベストプラクティスとアンチパターン
2.ベストプラクティスは難しい？実際の現場で難しいと感じたこと
3.スクラムマスターのあるべき役割
引用
うまく回っているチームはこうしている！ベストプラクティスとアンチパターン
※✓はメリット・デメリットを表します
【①プロダクトバックログ管理をプロダクトオーナーが行っている】
-スクラムガイドより-
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、プロダクトゴールを策定し、明⽰的に伝える。
プロダクトバックログアイテムを作成し、明確に伝える。
プロダクトバックログアイテムを並び替える。
プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
(うまくいっているチームでの工夫)
- プロダクトオーナーがプロダクトゴールや価値・目的・背景を整理し、開発者・ステークホルダーに共有できている
- プロダクトオーナーがプロダクトバックログの作成・優先順位付けを行っている
✓ 価値の最大化の役割を担うことができる
✓ プロダクトオーナーがゴールや優先度、背景を把握できているため、ステークホルダーとの交渉や、何かあったときの優先度変更がスムーズになる
✓ 目的や背景を明確にすることで、開発者のモチベーションや成果物・提案の正確性にいい影響を与える
※個人的には開発者が一部のプロダクトバックログ起票しても、提案しやすい環境になるので良いかと思います。
(アンチパターン)
- プロダクトオーナーが多忙で、プロダクトバックログの生成が開発者・スクラムマスターになる
✓ 説明コストがかかる
✓ 優先度や目的が曖昧のため、案件が路頭に迷う
✓ 開発者・スクラムマスターが組織的にビジネス面やステークホルダーに干渉しづらい体制が多く、価値の最大化が難しくなる
✓ 目的が曖昧で、プロダクトゴールが明確でない
POCなど着手するにしても、要件が曖昧過ぎて発車ができない
※個人的にはプロダクトや作業の目的や背景共有がしっかりできていれば、インセプションデッキを必ずしも更新し続ける必要はないと思います。
【②自己組織的・意欲的で機敏なチームになるよう工夫する】
-アジャイル宣言の背後にある原則より-
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
-スクラムガイドより-
⾃⼰管理型で機能横断型のチームメンバー
スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
(うまくいっているチームでの工夫)
- プロダクトオーナーがステークホルダー・開発者との調整を積極的・即座に行う
- チャットやMTG、電話ができる環境を設ける
- 対応できる稼働を設ける
- 既読や対応状況が分かるようスタンプを活用する
- スタンプ活用は返信の工数削減にもなる
- (スクラムに限らないが)プロダクトオーナー・ステークホルダー・スクラムマスター・開発者がお互いに信頼しあっている
- スクラムマスターが改善支援するのは前提として、全員が尊敬される振る舞いを意識する
✓ 相談・提案などスムーズになる
✓ 背景・目的感、進捗をすり合わせられることで、認識齟齬による手戻りや軋轢が生まれない
- スクラムマスターが改善支援するのは前提として、全員が尊敬される振る舞いを意識する
- 開発者が進捗管理・雑務・イベント進行も担当する
- 開発者がプロダクトオーナーやステークホルダーとのやり取りを行う
- 開発者の属人化をできる限り防いでおり、意欲的に活動ができる
- スプリント途中で、スプリントが達成できそうか状況振り返りや開発者レビュー等の計画を行う
- 常に会議を繋ぎ、いつでも議論・質問やペアプロができる状態にしておく
- 積極的に手助け・後任育成をする
- 複数名or全員で成果物のレビュー(プルリクエストなど)を行う
✓ 成果物や状況を把握できる&スキルアップにつながる
✓ 自分事としてとらえることができ、作業の引継ぎがスムーズ - スクラムイベントの準備・進行や議事を担当する・ローテーションする
✓ プロダクトバックログの把握ができる - プロダクトオーナーやステークホルダーからの質問への返答担当をローテーションする
- プロダクトオーナーからは個人相談・メンションしないようにしてもらう
✓ 自分事としてとらえることができる - チャットツールを活用する
- 進捗や疑問点を共有する。疑問に回答する
- あとで見返せるよう、対応内容や参考文献、口頭議論内容などを記載する
- すぐに反応できるよう、通知設定やメンションルールを設ける
- 既読や確認中の場合のスタンプルールを設ける
(アンチパターン)
- プロダクトオーナーやステークホルダー、開発者同士で連絡がつかない、既読か返信検討中かわからない
- 開発者がイベント進行・雑務に関わらず、スクラムマスターが担当する
✓ スクラムイベントへの興味の低下・プロダクトバックログやゴールへの理解の低下
✓ 雑務の担当決定の時間が余分に必要
✓ スクラムマスターが雑用係になる - プロダクトオーナーやスクラムマスターが作業進捗を管理する
✓ 管理しすぎると甲乙関係になりがち。ロール間に軋轢が生まれる
✓ 遅れている作業の把握・対応が遅れる - レトロスペクティブなどでチームの改善ができない
- チームメンバーが意欲的でない
- チームメンバー間で軋轢が生まれている
✓ 最悪の場合、契約延長なしなどにつながる- スクラムマスターが改善を試みるのはもちろんですが、難しい場合はメンバー入れ替えや、上司を交えた話し合い、アジャイルコーチの導入の検討も視野に入れるべきです
【③役割の明確化】
-スクラムガイドより-
ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
(うまくいっているチームでの工夫)
- プロダクトオーナーがステークホルダーとの諸調整を行う
- ステークホルダーからはプロダクトオーナーに連絡するように調整する
- 技術的な疑問点がある場合、プロダクトオーナーから開発者に相談する
(アンチパターン)
- 窓口が一本化していないと、スクラムマスターや開発者に質問や依頼が飛んでくる
✓ 最悪の場合、プロダクトオーナーが把握していないかったり、契約違反になる
✓ 予期していない対応工数がかかり、プロダクトオーナーとの調整が必要になる
✓ 情報を誰が誰にどこまで伝えたかが把握できないため、連携ミスが生じる
【④透明性の担保】
-スクラムガイドより-
スクラムチームとステークホルダーは、作業や課題を公開する。
(うまくいっているチームでの工夫)
- プロダクトオーナーとステークホルダーのやり取りを開発者が把握している
- チャットや議事などが閲覧できる状態である
✓ 開発者向けに情報を整理しなおす必要がなくなり、プロダクトオーナーの工数も削減できる
- チャットや議事などが閲覧できる状態である
【⑤スプリントが進行できるように前もって準備を行う】
-アジャイル宣言の背後にある原則より-
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
(うまくいっているチームでの工夫)
- 先のスプリントで着手するプロダクトバックログアイテムの準備ができている(Readyの状態)
- プロダクトバックログアイテムの課題や開始条件が確認できており、ステークホルダーとの調整や仕様の整理が着手までに完了している
- プロダクトバックログリファインメントを開催し、バックログアイテムの内容を理解し、開発者の作業イメージができている
- ベストプラクティスでは開発者が作業計画をスプリントプランニングで行うことになっているが、課題や疑問が出ることがあるので、事前に行い課題や疑問点を解消できると円滑
- チーム結成直後の場合、スプリントゼロの期間を設けている
- 特に、完成の定義をチームで合意できていること
(アンチパターン)
- スプリントプランニングで確認事項が多発し、スプリントが開始できない
- プロダクトオーナーやステークホルダーの回答待ちで作業着手できない
ベストプラクティスは難しい？実際の現場で難しいと感じたこと
※
= 個人的に考える対策
【①カメラON・対面会話】
-アジャイル宣言の背後にある原則より-
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
- リモート作業が基本になってきて、必ずしも効果的ではなくなっている
- カメラOFFが好まれることが増えた
- 飲み会に進んで参加したい人も減ってきた
- 遠方住みのメンバーも増えてきた
- 端末環境等で物理的にONにできないこともあり
- チャットや声での連携ができているせいか、カメラONにより何か効果があったという声が少ない
やりたい&やりたくない・できないメンバーもいるので、チームで相談しましょう！
※個人的にはビデオOFFがとても楽です笑
しかし、たまの対面はより親しみを感じやすく、その後の連携がしやすく感じます！
【②動くソフトウェアのレビュー】
-アジャイルソフトウェア開発宣言より-
包括的なドキュメントよりも動くソフトウェアを
- 実際には毎回動くものを作成できるわけではない
- スクラム開発が、フロントエンド以外にも適用されるようになった
- スクラムはメンバー変更や、開発体制縮退⇒依頼元や別会社に作業移管となることがあり、ドキュメントが必要になる場合がある
- スプリントレビューは必ずしもやらなくていい
- インクリメントを作れるように作業調整するのは大前提としても、1週間スプリントだと毎回動く成果物があるわけではない
- 状況の共有や、レビューの必要性がないことを合意できるのであればわざわざ時間をかけて無理やりイベントをする必要はない
- バックエンドもレビューを行う
- データが正しく処理されることや出力結果など、短時間でレビューが可能なら動かしてレビューすると、ステークホルダーとの認識齟齬が生まれず、状況把握もできる
- 場合によっては仕様や相談事項をドキュメントにまとめ、レビューを依頼する。スプリントレビューを待つ必要はなく、チャット等で依頼するとよい
- プロダクトバックログアイテムの状況や課題感はプロダクトオーナーと共有すること
- 引継ぎがある場合は必要ドキュメントの認識合わせ・ドキュメント作成のプロダクトバックログアイテムの作成・着手を行う
- 画面遷移図、処理フローやIF仕様書、アーキ図などは一気に更新すると工数がかかるので、作成しておき定期的に更新するとよい
- 予期せぬ事態発生時に、ステークホルダーと議論が生じることがあるため、取り決めた内容はドキュメントでなくてもチャットや議事録に残しておくことをお勧め
【③プロダクトオーナーの人数】
-スクラムガイドより-
スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。
- 実際はプロダクトオーナー1人～複数人
- 可能であれば複数人がおすすめ
- プロダクトオーナー1人の場合、何かあった際にスプリントが停止する
- 休み・不在が難しい。スクラムイベントの調整が困難
- メインのプロダクトオーナーを立てる
- 複数人の場合メインのプロダクトオーナーを立てるべき。メインのプロダクトオーナーがいない場合、チームやステークホルダーとのやり取り窓口が分散したり、スクラムイベントでの意見・方針に収拾がつかなくなる場合が多い。
【④プロダクトオーナーによるプロダクト価値の最大化】
-スクラムガイドより-
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。
- 特に商用サービスは組織がやシステムが多段になり、実際にはプロダクトオーナーに収益やエンドユーザー向かいの価値提供(仕様決定)の権限がないことがある。
- ステークホルダー含め、どう価値を向上させるかの検討が必要になってくる
- ビジネス側組織からの展開がない場合、プロダクトオーナーが積極介入・把握していく必要がある
- ステークホルダー含め、組織やチームの保身に走らず、全体最適や価値向上を考える必要がある
- 本当はビジネス側がプロダクトオーナーをやるのがよい
- 技術屋がビジネス側をすることが多いが、上流支援やマーケティング、デザインなど、「どこに需要があるのか」「どう売れるか」の専門知識があるチームと組めると本当に良いものが作れると感じる
- 開発者から、できることを積極提案する
- 開発効率化や、運用費低減、処理速度向上など、見える範囲での提案はすべき
スクラムマスターのあるべき役割
スクラムマスターに必要なスキルや向いている性格とは何でしょうか？
スクラムの知識はもちろん必要ですが、活躍しているスクラムマスター・アジャイルコーチの印象や、実際の現場で求められている能力を個人的な所感でまとめてみました。
活躍しているスクラムマスター・アジャイルコーチの印象
他スクラムマスターとの交流で、スクラムマスター専任やアジャイルコーチの方々は以下のスキルがある印象を感じました。
-
状況の理解力
- 状況を理解し、問題点を把握する力
-
言語化スキル
- 把握した問題点を言語化・図示する力
-
心理的安全性を担保するスキル
- カウンセリング・コーチング・傾聴スキル
-
コミュニケーション力・人当たりのよさ
- スクラムをうまく回すにはこちらが必要。スクラムマスターが信頼されることで、チームの距離がぐっと縮まる。
-
探求心と説得スキル
- 改善には新しい取り組みがつきもののため、新しい取り組みをしようという意欲や、説得スキル
-
人と話すのが好き・問題解決が好き
- 問題についての議論からチームメンバーとの雑談まで、色々な話ができる
- 問題解決の意欲がある
- 積極的にチームメンバーやステークホルダーと交流ができる
- 登壇や座談会参加を行い、積極的に情報収集を行っている
実際の現場で求められている能力
スクラムを実際の現場で運用する上でよく必要になると感じるスキルや、これがあれば効率的だというスキルをまとめました。
また、スクラムマスターは『チームや組織の支援役』として定義されますが、実際の現場では、別の役回りとして顧客窓口や上長への報告、社内調整なとが要求される場合があります。どのようなスキルが必要でしょうか？
-
案件状況の理解・見通し
- 状況を整理・問題点を把握し、アクション出来る力
- プロダクトオーナーやステークホルダーから漏れている事項の確認
- 案件状況を見通し、将来構想の把握・見直しや要員調整などに必要なアクションや連携ができる
-
開発知識
- 実際は上司やプロダクトオーナーから技術的な質問がされることが多い
- 開発知識があると…
- プロダクトバックログアイテムやスクラム運営、各所との技術的なやりとりに対しての適正評価ができ、改善に繋げられる
- 完成の定義など、チーム立ち上げ時の開発ルールのアドバイスができる
- 緊急時や、社内制度の確認など対応できることが増える
- スクラムマスターはチームが成熟すると暇になりがち。スクラムマスターとしての能力を向上させ複数チーム兼任するか、開発者を兼任することが求められる
- 個人的には『チームや組織の支援役』に徹せず他の役回りがあるならMUSTの能力
- 開発知識がないと、チームメンバーやステークホルダーとの信頼関係が損なわれるという意見もある
-
要件定義・上流支援
- ゴールが曖昧なままの契約成立はスクラムだとあり得るため、ニーズを収集・取捨選択し成果物イメージを具体化する力が必要
-
組織ルールの把握
- 内部/外部の承認ルール
- NW要件・端末の制限 など
-
問題解決手法
- なぜなぜ分析など、問題があった場合の解決スキル
- 問題解決はスクラムマスターが支援しない場合、チームメンバーが短時間で議論しきれない場合や明後日の方向に議論が向く場合が多く、よく必要になってくるスキル
-
作業効率化知識
- CI/CD、IaC、自動テスト、AI活用など作業効率化の知識
- 開発者だよりになることが多いが、知識があるとスムーズ
-
利用できるサービス・組織、活用可否の把握力
- AWSサポートなど外部サービス
- データ収集・作業効率化などの内部/外部サービス
- 技術検証チームなど、開発分野での社内連携
- デザインやマーケティングなど、サービスをよりよくする上での異なる分野での社内連携
こうしてまとめてみると、実際の現場で必要なスキルはプロダクトオーナーに必要なスキルと似ていることが分かりました
終わりに
いかがでしたでしょうか？
皆さんの現場で思い当たる点や工夫してみたい内容はありましたか？
皆さんの現場で参考になる内容があれば幸いです。