スクラムマスターを体験することでどんな学びがあったか？　経験することで実感した、自身の知識・関心と視野の広がり

スクラムの主な流れ

塚原彰仁氏：寄り道が長くなってしまいましたが、ここで「スクラムマスターは何をやっている人なのか」という話に入っていこうと思います。（スライドを示して）賑やかな図ですが、これはスクラムの全体像を表しています。

スライドの左下から、Product Backlogです。実装したいユーザーストーリーをまとめたタスクが優先順に並んでいます。Refinementは、次にやりたいことをどんどんこの場所に積み重ねていくようにしています。

スタートはSprint Planningです。プロダクトオーナーから、「このスプリントのサイクル中に何を実現したいのか」「なぜそれが必要なのか」という説明を開発チームに共有してもらいます。開発チームはそれをどうやって作るか、この期間中にどうやったらうまくスケジュールどおりに乗っかっていくかという話をします。

そして、実際に開発期間が始まります。Daily Scrumというもので、日々の進捗、「昨日これをやろうと思っていたもの、計画どおりに行ったよ」「ちょっと巻いているよ」「今日はこれをやろうとしているよ」ということをチーム間で話し合います。何かメンバーの困りごとがあればDaily Scrumで共有して、「チームでうまくやっていきましょう」という話や、コミュニケーションが生まれます。

そしてSprint Reviewです。ステークホルダーに「本スプリントでこういうものを実装しました。こういう動きを期待しているんですが、想定どおりのものでしょうか？」とフィードバックを受けるようにしています。ここで受けたレビューのアイデアは、プロダクトオーナーが次のアイデアとして、Product Backlogに積んでいくという算段です。

あとはSprint Retrospectiveという、いわゆるふりかえりです。1サイクルのスプリントの期間を思い出して、「もっとよくできたところがあるんじゃないか」とか、「その取り組みはすごく良かったから、次も繰り返しやっていきましょう」とふりかえります。このサイクルを短く繰り返すことで、チームがどんどん良くなっていくのがスクラムの主な流れになっています。

スクラムマスターの仕事と責任

スクラムにおける主な登場人物を3人。PO（Product Owner）は何を作るのかを担当してくれます。開発チームは、プロダクトをどうやって作るのかについて責任を持ちます。スクラムマスターは、スクラムがうまく回るように調整する役で、開発のプロセスに対して責任を持っています。

今回は、スライドで赤い帽子を被っている、スクラムマスターについてもう少し見ていきましょう。

スクラムマスターの主な仕事は、スクラムをチームに導入すること。指導・トレーニング・コーチの役割です。あとは、チームが開発に集中できるように支援やサポートをしてあげるほか、すべてのスクラムイベントがきちんと開催されていて、ポジティブで生産的であって、タイムボックス（スケジュール）どおりに進むように守ってあげることです。

いわゆるファシリテーターとして、イベントをうまくサポートするサポーターの立場です。あとは、複雑な環境での経験的なプロダクト計画を支援する。具体的には、先ほど紹介した、プロダクトオーナーがBacklogアイテムを作成する時に支援してあげるなどです。

プロダクトオーナーにエンジニア的な知見がなく、「どのような実装になるんだろう」というイメージがつかめない時は、スクラムマスターが「こういうことですよ」とサポートをしてあげます。

スクラムマスター自身がエンジニア出身でない場合は、必要に応じた人をミーティングにアサインして話し合ってもらうとか、ミーティングの場をセッティングするのが、スクラムマスターの仕事です。他にも多岐にわたります。

求められるスキルもエンジニアと異なります。例を挙げると、コーチング、ファシリテーリング、メンタリング、状況を分析する力など、多岐にわたります。

スクラムマスターを経験することでどんな学びがあったのか

スクラムマスターを経験することでどんな学びがあったのか、私の経験を踏まえて紹介します。ファシリテーターとして、ミーティングの場づくりを意識するようになりました。ファシリテーターは、あまりしゃべりすぎてはいけないと考えています。私はけっこうしゃべってしまうファシリテーターなので、なかなか難しいんですけれど（笑）。

自分が話を振って語ってもらうようなことをしなくても、その場に参加することでメンバーが話したいことの議論が自然と始まって、どんどんテーマが深掘りされて、次のアクションまで落とし込める場を作ってあげることがすごく重要ということです。ファシリテーターがいなくても自立している状態を作れるのが、良いファシリテーターなのかなと思っています。

あとは、チームの成熟度やどのようなチームになっていきたいのかを、アジャイル思想を踏まえつつ考えることです。開発チームに入っていると、つい目の前のタスクやスプリントをどうにか達成することに集中して（しまい）、チームの中長期的な（未来、）半年後や2、3年後にどうなっていたいかを考える時間がなかなか取れない。

なので、スクラムマスターは、開発チームから一歩離れたところから現在の課題を観察してあげる。「どうしたらもっと動きやすくなるのか」とか、「今後もっとチームが成長していく状態を作るためには、どんなコミュニケーションや関係性があればいいのか」をサポートしていくことが大事だと思っています。

あとは、シンプルに新しい知識を身に付けることはすごく楽しいと思います。自分の関心の視野が広がっていくことです。技術的なことばかりじゃなくても、すごくワクワクします。今までプロダクトオーナーやPdMが話していた、ビジネス的な知見がある瞬間につながること。「なんだかすごく学びがあったな」と、私はそういうところにワクワクしていました。

スクラムマスターごとに進め方やチームのサポート方法に特徴があるのは、私の中で新しい関心事に気づくきっかけになりました。私の前にやっていたスクラムマスターや、私のあとにやっているスクラムマスターは、同じチームを観察していても気になるポイントが違うことで、自分が惹かれているものや、やりたいことが違うんだなと、無意識のうちにそこから学びました。

そういう意味では、私はチームを巻き込んでスクラムを楽しんでもらうことを意識していたので、いろいろなワークショップを企画していました。

（スライドを示して）例えばこれ。チームでカレーを作って、アジャイルやスクラムを学ぶ企画をしていました。自分のSNSのアイコンはコック帽を被っていますが、「アジャイルカレークッキング」を楽しんでくれたメンバーが、コック帽を着けたアイコンを描いてくれました。

参加したメンバーもすごく楽しんで作ってくれました。

（次回に続く）