はじめに

こんにちは、23卒エンジニアの sekiyan です。2023年4月に入社してから7月上旬まで行われた研修を終え、今はヒューマンリソース本部人事総務統括部人事部エンゲージメントプラットフォームグループに所属しています。

私は、DeNA入社前までは学生が中心の場でのチーム開発を行なってきており、時には開発のリーダーのような立場も担ってきました。もちろん、スクラムという言葉は聞いたことがあり、チームに取り入れようとネット記事などを読み漁ってなんとなくその手法を導入してみたりしてもいました。

しかし、結局スクラムについて"なんとなく"知っているつもりでも、研修を通して自分がいかに無知であったかを自覚することになります。

この記事では、そんな私がスクラムマスターとしていかにつまづき、最高のスクラムチームを目指してやったことを書きたいと思います。

ぜひ、これからDeNAに入社される方や、研修の様子を知りたいという方は参考にしていただけたら嬉しいです！

プロダクト開発研修の概要

新卒の中でもエンジニアだけが受けるエンジニア研修というものがあり、そのエンジニア研修の中でも最後に行われるのがプロダクト開発研修です。プロダクト開発研修は、新卒がお題ごとに6~7人のチームに分けられ、研修期間でありながら社内で実運用されることを目指したサービスを0から作り上げるという実践的な研修になります。

プロダクト開発研修は以下のような流れで進みました。

1. プロダクト開発研修の説明
2. お題発表・チーム分け
3. スクラムについての講義(1日)
4. デザインスプリント(1週間)
5. スクラム開発(1ヶ月)
6. 成果発表

お題を元にチーム分けを行い、与られたお題からデザインスプリントという手法を使って実際にどういったプロダクトにするのかしっかりと考え、モックレベルまで作り上げます。その後1ヶ月かけてスクラム開発を行い、研修の最後に成果発表を行うというのがプロダクト研修の一連の流れになります。

今年度はエンジニアだけでなくビジネスの新卒メンバーも研修に参加しました。

スクラムとは何か

スクラムは、複雑な問題に対応するために、人、チーム、組織が価値を生み出すための軽量級フレームワークです。スクラムガイドで宣言されており、2023年9月現在の最新版は スクラムガイド2020 です。スクラムガイドでは、5つのイベント、3つのロール、3つの成果物がルールとしてあり、最低限の決まりが記されています。

スクラムはチーム開発のhow toではなく、あくまでフレームワークであるため、チームごとにスクラムのルールをどのように適応させていくのか考える必要があります。

本記事ではスクラムについて詳しく解説はしないので、もし本記事を読んでスクラムについて興味を持たれた方は、スクラムガイドや関連書籍にも目を通してみてください！

研修で行われるスクラムの概要

スクラムはスプリントと呼ばれる1ヶ月以内の決まった長さを繰り返すのですが、プロダクト開発研修では1スプリントが1週間と定められており、期間が1ヶ月なのでそれを4スプリント分繰り返すことになります。

スプリントでの動き方

研修で行われるスクラムでは、金曜日は1日かけてスクラムイベントを行うと決まっているので、月~木曜で開発を進める必要があります。週に固定で行われるイベントについて以下にまとめました。

スクラムチームの構成

私たちのスクラムチームは以下のような構成で開発を行いました。

• 開発者 4人
• プロダクトオーナー 2人
• スクラムマスター 1人（私）

プロダクトオーナーが2人というのは通常のスクラムで考えるとあまりないのですが、今回ビジネスサイドから参加したメンバーが通常業務との兼任だったため、なかなか時間を割きにくいという特殊な事情もあり、このような体制をとっていました。

スクラム開発で起こった問題

「スクラムわからん」

これが僕たちのチームに最初に立ちはだかった、最大にして最難関の壁でした。

スクラムの講義やスクラムガイドに目を通しただけではスクラムを理解することは難しく、何を取り組むにしても「これはスクラムのやり方に則っているのだろうか？」という疑問にぶつかってしまい、みんながモヤモヤしているし、物事も前に進まないということがスプリント1では起きていました。

スプリント1のスプリントレビューでは、何もレビューしてもらう成果物がなく、ステークホルダー（メンター）に対して「何も見せられません…」と言い、地獄のような雰囲気だったことは忘れもしません。

スクラムマスターとしての取り組み

上記の状況をきっかけに、私はスクラムマスターとしてどうあるべきかを考え直しました。

積極的にスクラムについて調べ、どのようにしたらチームとして良くなるのか、どのようにしたら立派なスクラムマスターになれるのかを考えて動くようになったと思います。

そんな私が実際に行った特徴的な取り組みや考え方についてご紹介したいと思います！

スクラムマスターがスクラムに一番詳しくなる

そもそも前述したような状況にチームが陥ってしまったのは、私がスクラムマスターなのにあいまいな理解な状態のままでいたのが一つの原因だと、当時の私は深く反省をしました。

スクラムマスターはチームにスクラムを浸透させたり、スクラムチームの導き手のような役割であるため、少なくともチーム内では一番スクラムに詳しい人であった方が良いと思います。ですが、スプリント1までの私は他のメンバーと一緒に「スクラムわからん」と言っていたような状況だったため、まずはそこから打開をしていきました。

スクラムを学ぶ上で私がつまづいた点として、スクラムガイドが抽象的で理解しにくいと感じていたことでした(※個人の感想です)。間違いなくスクラムを知るのにスクラムガイドは1次情報なので見た方がいいのですが、どうしてもフレームワークとして抽象化されているので、実際の開発に繋げてイメージすることが難しかったのです。

そこで、私はスクラムの理解を深めるために2冊の本を擦り切れるまで読み込みました。

• SCRUM BOOT CAMP THE BOOK : スクラムの全体をわかりやすく学べる本
• SCRUM MASTER THE BOOK : スクラムマスターのための本

SCRUM BOOT CAMP THE BOOKは現場でスクラムを導入するというストーリー仕立てでスクラムを学べるので、より具体的なイメージを持ちやすい本です。SCRUM MASTER THE BOOKはスクラムマスターとしての心構えや立ち振る舞いを学べる、スクラムマスターによるスクラムマスターのための本です。

私はこの2冊をメモをしながら端から端まで読み込み、研修期間中は常に持ち歩いて、わからなければ参照できるようにしていました。

特に、SCRUM BOOT CAMP THE BOOKはスプリント1と2の間の2日間で、内容のほとんどを頭に叩き込んだのですが、スプリント2の開始時に「スクラムマスターとして見違えるように変わった」とメンバーから言われるぐらい理解が深まりました。

開発をしない専任のスクラムマスター

他のチームと比べて、私のチームだけがしていたユニークな部分が、スクラムマスターはスクラムのことに集中して開発はしないということでした。他の全てのチームは、スクラムマスターと開発者を兼任しており、スクラムのことも考える傍ら開発もするといった体制をとっていましたが、私だけは常にスクラムのことに集中していました。

理由としては、私のチームメンバーは皆、開発経験やエンジニアリングの知識は豊富なメンバーが多く、どうスクラムを進めていくかが決まれば開発が進んでいくことは明確であったため、その時私がすべきことはスクラムマスターとしてスクラムを浸透させることだったからです。なので、スプリント2の最初に「スクラムをチームに浸透させるまで、自分はしばらく開発をしないという形をとってもいいだろうか？ただし、スクラムのことは全て自分に任せてくれ」と私から他のメンバーに宣言して、専任のスクラムマスターとなることに決まりました。

「エンジニア研修なのに開発をしないでいいのだろうか」という葛藤もありはしましたが、それよりもスクラムマスターでありながらその役割を果たせていない悔しさの方が圧倒的に上であったため、かなり割り切れていました。

俺たちのスクラムガイドの作成

スクラムというフレームワークを使うには、スクラムマスターだけではなくプロダクトオーナーや開発者にもその役割やスクラムの考え方を理解してもらう必要があリます。そして、そのようにチームにスクラムを浸透させるのもスクラムマスターの役割です。

そこで、チームにスクラムを浸透させるために私が考えたのが、俺たちのスクラムガイド（通称俺スク） の作成でした。

俺たちのスクラムガイドは、スクラムガイドで抽象化されている部分を自分のスクラムチーム向けに全て具体化して書き出したものになります。なので、構成はスクラムガイドと非常に似ているのですが、スクラムの考え方、チームメンバー、ステークホルダー、スクラムイベントの流れ、準備すること、どんなツールを使うかなど、チームにとってスクラムで必要な情報を網羅して書いていました。

俺スクを書いたことで、自分が本を読んで掴んだスクラムのイメージをチームメンバーにも伝えることができましたし、スクラムイベントの手順や実施時間、準備の仕方など事細かに書いていたので誰もが俺スクを見れば次の行動がわかるようになっており、行動の指針とすることができました。

俺スクは、本を呼んでいた時に個人的にまとめていたメモをもとに考えたアイデアです。自分はこの本を読んで理解することができたが、チームメンバー全員に本を読め！というのは違うよなぁ、どうしたらチームメンバーへの負担を最小限にしてスクラムを伝えることができるのだろうと考えた時に、今しているメモをもっとわかりやすくしてスクラムについて困ったら頼れるチーム専用のドキュメントにすればいいんじゃないか？と考えたのが誕生秘話だったりします。

チームをとにかく観察する

スクラムマスターは、開発者とPOがスクラムで開発を進めれるようにするためなら何でもやります。スクラムをチームに浸透させ理解してもらうだけでなく、困りごとがあれば支援をしたり、外部からの差し込みを排除したり、スクラムチームがうまく回るためにあらゆる手段を尽くします。

スクラムがうまく回っているのかは完了したストーリーポイントの数やインクリメントだけでは計れません。メンバーが困っているけどいい出せないことや、本人たちも気づいていない潜在的な課題、ちょっとした困りごとなどが必ずあり、これが溜まっていくと後に必ず大きな障害となります。

そういった課題を引き出して解決するのに必要なのがチームを観察することなのです。

私たちのチームはチャットはSlack、オンライン作業やペアプロ/モブプロをする時はSpatialChatというオンライン空間で対面のようにコミュニケーションが取れるツールを使っていました。特に、SpatialChatでは今誰が一緒に作業しているのか、一人で黙々とやっているのかがわかり、画面共有をしていればそれを見にいくこともできる環境でした。なので、私は常にSlackやSpatialChatの様子を観察しながら、今誰がどんなことをやっていて、うまくいっているのか困っているのか、疲れていないかなどを気にするようにしていました。もし少し困っていそうだなと思った時は、SpatialChat上で突撃していって「今どんな感じ？」「何かあった？」と言ったように声をかけるようにしていました。

そういった行動を続けているとチームにも変化があり、振り返りで「もっとSlackでの発言を増やそう」とか「一人の作業でも画面共有で作業の様子を垂れ流そう」といった意見が他のメンバーからも出てきました。そうすると、少しの変化でも気づきやすくなり、メンバーの困りごとを素早く解決することができるとても透明性の高い良いチームになっていったと感じます。

チームの共有財産を増やす

チームメンバーそれぞれが持っている知識や、過程で獲得した情報を共有して透明性を高めることはとても大切です。そのために有効だった一つがドキュメントを書くことです。私のチームでは、開発者が開発で詰まったことや解決した方法、設計の考え方などを、プロダクトオーナーがユーザーインタビューの内容を、スクラムマスターがスクラムに関するトピックをというように、それぞれが何かあったときに Confluence にまとめておく文化が定着しており、チームの共有財産として有効活用されていたと思います。

私はチームメンバーから言われたスクラムの中でもわかりにくい部分や、スクラムメンターの方に相談した時にもらったアドバイスなどを再度自分で調べ直して、情報をまとめた上でドキュメント化し、それをチーム内で共有するようにしていました。これにより、俺スクだけではどうしてもカバーできないアジャイルの考え方をチーム全体で理解するようできたと思います。

具体的には、フロー効率、WIP制限、受け入れ基準についてまとめました。これらは他のチームの方にも読まれていたようで、チームを超えた共有財産にできていたのも嬉しかったです。

スクラムマスター勉強会の運営

スプリント2からスプリント4までの間、週に1回ほど研修チームのスクラムマスターが集まって、それぞれのチームでの取り組みや困りごとを共有する会を開催していました。発案は私ではなく他のチームのスクラムマスターの方なのですが、私も運営として参加していました。

スクラムマスター勉強会の概要は以下のようになります。

• 時間: 30分間
• 場所: 専用のSlackチャンネルのハドルミーティング
• やり方:
  1. 10分間で「レトロスペクティブで出た問題」「レトロスペクティブで出た対応策」「工夫した点、疑問点」をまとめてSlackに投稿
  2. みんなの投稿に目を通しながら気になった点を質問する

同じスクラムというフレームワークを使っていても、チームごとにやり方は変わってきますし、ぶつかる壁も違います。それぞれのチームの様子を知り、どういう対策をしているのかや、どういった考え方を他のスクラムマスターが持っているのかを知ることができるこの取り組みはとても良かったと感じます。

また、どうしてもスクラムマスターとしての悩みを抱えることもあり、それを他のスクラムマスターに相談したり意見を聞くことができる場というのも貴重だったと思います。

研修を終えて

チームが「スクラムわからん」となった状況から、スクラムをしっかりと勉強して、学んだことを行動に移すことで徐々にスクラムチームも変わっていきました。

はじめは「スクラムでやる意味ある？」というような声が飛び交う状態から、最後には「スクラムにちゃんと則ってやれて良かった」という言葉が出るぐらいの成長をチームですることができ、本当に頑張って良かったと思いました。

研修が終わった後に、2S2B（2ストライク2ボール） というフレームワークで振り返りを行いました。その時に僕のターンでチームメンバーからもらった声がこちらになります。

スクラムマスターとしての頑張りをチームメンバーから褒めてもらえるような声が多くあり、スクラムの改善を通してチームに貢献できたと胸をはって言って良いと思っています（ボールのところで僕個人の基質的な課題があるのはまた別の話ということで笑）。

また、他のチームからも「スクラムめちゃくちゃうまくいってたらしいね」「俺スクを見て真似をしてチーム用のドキュメントを作ったよ！」といったような声をありがたいことにたくさんもらいまして、他のチームにまで影響を与えられていたことも嬉しく思います。中には、会社のラウンジでお昼ご飯を食べている時に声をかけてくれて、スクラムのやり方について相談してくれた他のチームのスクラムマスターもおり、力になれたのは嬉しかったです。

スクラムマスターとして今後の展望

ここまで短期間ではありますが、スクラムと向き合って、スクラムを学んだ経験は今後の業務でも必ず活かすことができると考えています。

今回学んだことを活かして、業務のチームのやり方に対しても改善を提案できるようになりたいです。

また、スクラムマスターには認定資格というものがあるので、今後も勉強を続けて資格取得もしつつ、スクラムについてアドバイザーになれるようなレベルを目指すことも視野に入れたいと考えています。

おわりに

「えぇ！？はじめてのスクラムマスターでも新卒研修で最高のスクラムチームを作れるようになれるって本当ですか？」

本当でしたね。はじめてのスクラムマスターでも、チームと向き合い、スクラムと向き合えば最高のスクラムチームを作ることはできます。しかし、ここまで私がスクラムマスターとして成長できたのは、チームメンバーや他のチームの同期たち、メンターや講師の方、研修を作ってくださった方など多くの支えがあってのことでした。本当にありがとうございました。

そして、ここまで記事を読んでくださった皆さま、誠にありがとうございます。少しでもDeNAの研修を通して成長できた姿をお伝えできていたら嬉しいです。