新卒研修でスクラムマスターを任され実践した「押し付けないスクラム導入」

こんにちは、25新卒エンジニアの渡邉（ @ukwhatn ）です。 新卒エンジニア研修では、1on1支援ツール「すごマネ」の開発チームにて、スクラムマスターを担当しました。 「すごマネ」について、詳しくは以下の記事もご覧いただけますと幸いです： DeNAの1on1をAIで支援 - 新卒チームが開発した「すごマネ」の挑戦 新卒エンジニアチームが陥ったAI活用のバッドパターン 本記事では、エンジニア研修でのスクラム開発において、私がスクラムマスター（以下、SM）として行ったことをいくつかご紹介したいと思います。 スクラムの考え方をチームに浸透させていく上で直面しやすい、「どう受け入れてもらおうか」「どう改善サイクルを回していくか」といった悩みについて、具体的な事例として役立てていただけますと幸いです。 スクラムマスターとしての「こと」 DeNAには、社内で大切にされている「DeNA Quality」という5つの行動指針が存在し、その中に 「こと」に向かう（本質的な価値を提供する） というものがあります。 SMとして何をすべきかを考えるにあたり、まずは自分自身が向かうべき「こと」を明確にしておく必要があると感じました。そこで、「この2ヶ月で自分が向かうべき“こと”は何か」 を定義することから始めました。 結果として、私は以下の2つを “こと” として定義しました。 ① チームが最終的にスクラムにたどり着ける状態にすること スクラムを実践することには、いくらかの制約や、常に意識しなければならないことがあります。そのため、スクラムでの開発を行うことに必要性を認識していない状態でただ押し付けるだけでは、チームにフラストレーションを溜めるだけになるように思いました。 そこで、「スクラムを押し付けるのではなく、スクラムを選び取れる状態にすること」を目的として行動することにしました。 ここで重要なのが、「スクラムを実践する必要性を認識するためには、そうでない状態を体験しなければならない」ということです。 もちろんそうではない場合もあるでしょうが、開発初期のチームの様子を見たうえで「一度バッドパターンを踏み、その解決策としてスクラムを段階的に根付かせていくほうがよい」と考え、些かスパルタ気味の方針を取ることにしました。 ② チームの学びを最大化すること この開発は研修の一環として行われることであり、作っているものも社内向けのプロダクトなので、ある程度の失敗は許容される性質のものです。 失敗が許される環境なのであれば、「立ち上がれる範囲で失敗できるようにする」ことで、 スクラム開発の経験だけではなく、チームでの開発そのものや、技術的な学びなど、配属後に役に立ちそうな経験をできるだけ多く持って帰ってもらえるようにする ということを第2の"こと"として定義しました。 上述の通り、私は「バッドパターンを体験すること」が必要だと考えていたので、その一環としても作用します。研修という場だからこそ取れる方針だと思いました。 これら2つの “こと” は、結果として最後まで貫くことができたと思っています。そのために行ったことを、これからご紹介できればと思います。 スクラムマスターとして行ったこと Sprint1のはじめから、私はSlackワークフローを通じて、以下の画像のようなフォームをチームメンバーに（ほぼ）毎日送付しました。 ここでは、各メンバーの満足度やコンディション、良かったこと、悪かったことなどをラフに答えられるようにし、最後の設問は日替わりでその時々に合わせたことを聞くようにしていました。 ![](images/meyasu.webp) このフォームには、主に2つの目的がありました。 1つ目は、各メンバーがアラートを出せる場を事前に増やしておきたかったという点です。 不満や引っ掛かりをチーム内のミーティングなどで直接解決できれば理想ですが、言い出しにくいことや、わざわざ時間を取るほどじゃないけど気になったことについて、私がその情報を拾える場を最初から作っておくことで、Sprintが進んでいった先の将来に対して「転ばぬ先の杖」として機能するのではないか？と考えました。 2つ目の目的は、自分たちが作ろうとしているものの類似機能を体験してもらうことです。 「すごマネ」には、1on1の前にメンティーがメンターに対して「コンディションアンケート」を送付し、話したいことなどを事前に通知できる機能があります。 類似のフォームをメンバーに提示することで、ユーザの体験に対する解像度を少しずつ上げてもらう手助けができるのではないかと思い、このようなフォーム構成にしました。 結果として、この目安箱は大いに役立ちました。特に、「スプリントレビューまでに終わらないんじゃないか」「今日はみんなパフォーマンスが良かった気がする」など、メンバーの肌感覚がフィードバックとして毎日得られたことは、チームの状態をキャッチアップするうえで大きな情報源となりました。 なお、この目安箱の回答はSMである私のみが閲覧できる形とし、必要に応じて私からデイリースクラムやSprint Retrospectiveなどで議題に上げるようにしていました。 スクラムの原則に従えば、回答を全体に公開し、メンバーによる自律的な改善につなげることが大切になりますが、チームがまだ形成段階にあるうちは、全体に公開しづらい内容も拾い上げられる場が必要だと考えたためです。実際、Sprint4以降はチームの心理的安全性が高まり、デイリースクラムなどで直接議題が上がることが増えたため、次第にこの目安箱が担う役割は薄れていきました。 タイミングを見てスクラムを導入 上述の通り、私は「スクラムを押し付けるのではなく、スクラムを選び取れるようにすること」を目的として行動していました。 とはいえ、最初から必要だと思ってくれたら…..という思いで、Sprint1のはじめに「モブプロとかやらない？」という打診をしてみましたが、開発メンバー（以下、Dev）からは「短期的な効率を優先したい」「自分たちなら並列で開発できると思う」といった声が上がったため断念しました。 背景として、Sprint1でプロダクトオーナー（以下、PO）から提示されたスプリントゴールの実装コストがかなり重く、SBIの量も多かったため、無意識に効率を優先するバイアスが働いていたのではないかと考えています。 正直に言えば「本当に終わるかな？」と疑問に思いつつ、それ以上は押しつけになるとして、基本的にDevの思い通りに開発を進めてもらうこととしました。 その後、Sprint1の4〜5日目に、1人のDevメンバーからペアプロやモブプロをしたいという声が上がりました。 私が強く印象に残っているのは、「一人一人が別々のタスクを並列で行うことは、質問するほどじゃない細かい意思決定が積み重なり、結果として負債となる」という分析が出てきたことです。 チーム全体として、この時点で進捗の遅延が少しずつ表出していたり、コードレビュー後の修正量が多く、効率的ではないのではないかという意見が出ていたのがこの頃です。 ここからSprint1のスプリントレビューに向けて、夕会などを通して少しずつ改善すべき点を挙げ、その改善策としてスクラムの考え方やよく用いられる方策を取り入れていきました。 正直に言えば、Sprint1のSprint Retrospectiveで改善策としてメンバーから挙げられたものがほとんどスクラム開発に帰着するようなものだったため、つらさを改善していくうちに勝手にスクラムになっていった、という部分が大きかったように思います。 Sprint2〜3の頃には、見積もりの精度などの問題点はありつつも、各々の意識や開発プロセスとしてはスクラムに則っていきました。 私たちのチームでは、夕会で当初KPTを振り返りフレームワークとして利用していました。 しかし「Keep / Problem / Try」の分類が粗いこと や 振り返りが心理的に負担になること により、次第にProblemが出なくなっていきました。 チームに本当に問題がないのであれば、Problem が出てこなくても問題ありません。しかし、Problem が出なくなったのは Sprint1 の4〜5日目で、ちょうど「進捗遅延」や「非効率さ」が目に見えてきたタイミングでした。つまり、問題が存在しているにもかかわらず 表出しなくなってしまった 状態であり、形式そのものを見直す必要があると判断しました。 それでもProblemが出ないのであれば、形式を変えるべきだろうと判断しました。 ここからは、開発を進めながら実際にどのように振り返り手法を改善していったのかを紹介します。 自由に書きたいことを書いてもらう形式（Sprint1 後半） これは夕会で行っていた振り返りの形式です。 miro上に反省や話したいことなどを自由に書いてもらい、それをもとに全員で議論をする形式を取りました。 この時点でチームは「議論を建設的に進められる」状態だったため、あえて形式を緩めても議論が破綻しないと判断しました。また、各自が話したいことを抱えている雰囲気もあったため、自由度を上げることで本音が出やすい環境を意図的につくりました。 ![](images/sprint1_hassan.webp) Sprint2に入ってからは、夕会にフレームワークを再び持ち込む形で、2S2B（2ストライク2ボール）を導入しました。 これは、各自へのフィードバックとして、相手の強み（Good）と期待（More）を2つ程度ずつ書いていく、というものです。 これはモチベーション維持の面で一定の効果があったように思いますが、そのときに何があったか、何を思ったかなどの事実や主観的な情報が欠落し、客観だけが残るため、Sprint Retrospectiveでの振り返りにあまり寄与しない感覚がありました。 ![](images/2s2b.webp) オリジナルのフレームワーク（Sprint3〜） 上記の問題点を解決するため、Sprint3では夕会とSprint Retrospectiveの形式を両方変更しました。 まず夕会では「起こったこと」の周りに「感情」「原因」「解決策」などの付属情報を付け加えていく形式としました。 この形式はSprint2のSprint Retrospectiveで他チームが実施していた形式を参考にアレンジしたものですが、事実・主観・客観がすべて残せる面でかなり良いものとなりました。（私はこれを「チェックポイントを作る」と表現していました。） また、喫緊の課題として解決しなければならないこと以外は、ここではあまり議論しないことにもしました。これは夕会によって発生する心理的負担を下げる狙いがありました。 ![](images/yukai.webp) ここで出た「事実」と「その付属情報」は、Sprint Retrospectiveで回収することにしました。 まず、以下のように夕会で出たそれぞれの付箋を時系列に並べ、これを眺めることで「このSprintで何があったか」「その時どう思ったか」を思い出せるようにしました。 ![](images/timeline_view.webp) ここでSprint全体で起こったことを思い出したうえで、以下の２つの手法で振り返りを実施しました。 各メンバーに対しての「感謝」を付箋にして、それを贈り合う場を用意しました。これは、自分と周りの強みの認識と、モチベーション維持を狙ったものです。 結果として、メンバー全員がかなり多くのFBを贈り合える場となりました。 ![](images/thanks_giving.webp) このときから、Retrospectiveでの振り返りフレームワークとしてStarfishを採用しました。これにより、KPTよりも細かい粒度で、かつ先ほど思い出した事実をベースに振り返りを行うことができました。 また、一旦非同期に書き出してもらったうえで、リアクションを使ったドット投票を行い、投票数の多かったものに対しては同期的に議論を行う、といった形で深堀りを行い、その過程をコメントの形で残すことで、改善アクションの具体化にも繋がりました。 ![](images/starfish.webp) これらの形式は主観的にも客観的にもかなり良い効果を生んでいたため、この形式は最後まで継続されることとなりました。 Sprint3に入りSlackでの非同期コミュニケーションが増えたため、チャンネル構成を整理しました。目的は 情報の透明性向上 と 議論の流れを追いやすくすること です。 研修運営チームによって用意されており、これまではこのチャンネルだけを利用していました。 Sprint3以降は細かい情報伝達など、randomチャンネルに近い使われ方となりました。 毎日、それぞれのメンバー専用の実況（times/分報に近い用途）用スレッドをワークフローから作成することで、各メンバーの出勤状態や現在のタスクなどを相互に確認できるようにし、透明性を向上する試みでした。 このチームはSlackでのアウトプットの多いメンバーが多かったため、かなり良い効果をもたらしたと思います。 また、スレッド作成時のデフォルトメッセージにProduct Vision/GoalやSprint Goal、その他ひとことメッセージなどを記載し、意識しやすい環境を作りにも寄与しました。 ![](images/times_thread.png) ![](images/times_thread_2.webp) 目的の決まった議論を行う際の専用チャンネルを用意しました。 ワークフローを用いたスレッド作成を原則とすることで、全体の見通しを確保しつつ、並列で議論を行うことのできる場を作りました。 ![](images/giron.png) PR提出時にレビューを依頼するための専用チャンネルも新たに作成しました。 議論チャンネルと同様にワークフローによって管理することで、レビュー依頼がタイムラインに埋もれないよう整理された状態を保つ仕組みにしています。これにより、PRに関する議論や確認がスムーズに行えるようになりました。 ![](images/review_request.webp) これらの用途別のチャンネルとワークフローの整備により、非同期の議論環境を整備し、リモートでの開発をスムーズに行うことに寄与できたと考えています。 本記事では、スクラムを押し付けるのではなく、チーム自身が必要性を理解して選び取れるようにするアプローチを紹介しました。あえてバッドパターンを経験してもらい、そこから改善策を自分たちで見つけてもらうことで、スクラムが自然と根付いていきました。振り返り手法やSlack整備など具体的な施策も、すべてこの「押し付けない」という方針のもとで試行錯誤した結果です。 実作業としては細かいファシリテーションなども多かったのですが、その中から特に効果のあったものをピックアップして記載しました。 これから初めてのスクラムマスターに挑戦する方、チーム開発をはじめる方など、少しでも参考になりましたら幸いです。 最後まで読んでいただき、ありがとうございます！ この記事をシェアしていただける方はこちらからお願いします。

新卒研修でスクラムマスターを任され実践した「押し付けないスクラム導入」

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト