サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2>はじめに</h2>

<p>初めまして、プロダクト本部ブラウザプラットフォーム部の鈴木です。DMM GAMESオンラインゲームプラットフォームのシステム開発を担う第３チームのリーダーを勤めています。</p>

<p>前提としてブラウザプラットフォーム部は、DMM GAMESのPC・スマートフォン向けのWebサイト全般のエンハンスを行なっている部署で、60名近くのメンバーが所属する、プロダクト本部の中で最も大世帯の組織です。</p>

<p>この部では、保守・運用をしているシステムが年々複雑化し、それにともないシステム開発のデリバリー速度の低下が大きな課題となっていました。</p>

<p>そこでスクラムを導入することで、スクラムの各イベントがチームの行動を改善へ促し、その成果の一つとしてデリバリー速度の向上に繋がるのではないかと仮説を立て、部内でスクラムの導入を支援する動きが生まれました。</p>

<p>第３チームは、スクラムの導入支援の一環として、認定スクラムマスター、認定プロダクトオーナーの資格をもつ2名(以下：スクラムコーチ)の指導を受けて、スクラムをチームに導入するモデルケースとしての活動をしています。&nbsp;</p>

<p>今回は、スクラム導入直後の試行錯誤について紹介していきたいと思います。&nbsp;</p>

<p>この記事が、スクラムの導入を検討している方や導入初期で悩んでいる方にとって一歩を踏み出す糧になれば幸いです。</p>

<h2><strong>山を見つける</strong></h2>

<p>まず初めに、私たちはスクラムコーチから、スクラムをすることでどんな山を上りたいのか尋ねられ答える事ができませんでした。そこで私たちは、どんなチームになりたいかを考えるワークを実施しました。&nbsp;</p>

<p>ワークでは、<a href="https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/#introduction">Google re:Workの『「効果的なチームとは何か」を知る</a>』を読み合わせることから始まり、良いチームとは何か考え、自分達はどんなチームになりたいかを議論しました。&nbsp;</p>

<p>ワークを通して、今のチームの悪いところは「チームなのにバラバラに活動してしまっていること」で、良いところは「コミュニケーションを沢山とっていること」だと気付くことができました。</p>

<p>また、そこから導き出したゴールとして「協力し合える一番早いチーム」という山を登る事に決めました。これまでスクラムをやったらアジャイルなチームになれるという漠然としたゴールから、明確なゴールが示された瞬間でした。&nbsp;</p>

<h2><strong>スクラムガイドを読む</strong>&nbsp;</h2>

<p>第３チームの中には、スクラムガイドを一度も読んだことがないメンバーが大半でした。&nbsp;</p>

<p>そこで、スクラムコーチと<a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf">スクラムガイド</a>の輪読を実施しました。&nbsp;</p>

<p>１８ページのスクラムガイドは概念的で具体的な手法などの説明はありませんが、スクラムコーチから所々で解説や理解が深まる資料の提示がありました。また、疑問もその場でディスカッションできたことで、スクラムについて深く理解する事ができました。&nbsp;</p>

<p>この輪読をしたことで、今までなんとなくやっていたスクラムのイベントの意味がハッキリし、やれていると思っていたスクラムがスクラムガイドとは合っていないと気付くことができました。</p>

<p>これはは恥ずかしくもありましたが、正しくないスクラムだったから上手くいかなかったのは当然で、正しくやれば良くなるはずだという勇気をもらいました。</p>

<h2><strong>スクラムガイドと現実の差分を見る</strong>&nbsp;</h2>

<p>スクラムを正しく行なえば改善されるという未来が見えた私たちは、スクラムガイドに沿ってスプリントのイベント、スプリントプランニング、デイリースクラム、スプリントレビューの内容の整理を行いました。&nbsp;</p>

<p>各イベントのゴールを明確化し、今までそれとなくやっていた口頭での共有はSlackなどの非同期な方法に変更。イベントの内容がそのイベントのゴールに必要な項目だけになり、イベントの実施結果の良し悪しを判断できるようになりました。&nbsp;</p>

<p>スプリントレトロスペクティブでは、スクラムコーチにファシリテーターの手本を見せてもらい、議論の仕方や、スプリントで起きた事実からTry/Actionを導く方法を学びました。&nbsp;</p>

<p>それまでのやり方では、レトロスペクティブで出たTry/Actionが実施されずに貯まり続ける状態だったのが、少しづつですが、実施可能なTry/Actionが出るようになり、実行できたTry/Actionの結果を振り返ることができる、正しいレトロスペクティブができるようになりました。</p>

<h2><strong>スクラムのゴールは近いようで遠い</strong></h2>

<p>これまでの活動によって、順調にスクラムができるようになり、アジャイルなチームになれているはずでしたが、逆にチームから色々な問題や課題が発生しました。&nbsp;</p>

<p>チームは、スクラムガイドに従って実施したことで、タックマンモデルの統一期に到達したつもりでしたが、実は形成期が終わって混乱期のステージに入ったところだったのです。</p>

<h3><strong>僕らの失敗談</strong></h3>

<ul>
	<li>レトロスペクティブのTRYが出るのに時間がかかる</li>
	<li>レトロスペクティブのアクティビティ迷子</li>
	<li>TRYを出すことの価値がわからなくなった</li>
	<li>人数が多くてデイリーの時間が足りない</li>
	<li>メンバー間の情報共有がうまくいかない</li>
	<li>バックログのスライスが下手でプランニングがもたつく</li>
	<li>TRYをいっぺんにやりすぎて混乱</li>
</ul>

<h2><strong>アジャイル見学会に参加</strong></h2>

<p>&nbsp;こうした状況を見たスクラムコーチから、「アジャイル見学会」の提案をいただきました。</p>

<p>&nbsp;</p>

<p>アジャイル見学会とは永和システムマネジメント様のアジャイルの専門組織「Agile Studio」が実施しているリモート見学の事で、アジャイル開発の現場をネットワーク越しに見学して、「アジャイル開発とは実際にどのようなものなのか」を知ることができるというものです。&nbsp;</p>

<p>アジャイル開発を実施するチームを見て第3チームの現状と比較することで、現状抱えている課題の解決のきっかけや気付きを得たり、新たな課題を見い出せることができるのでは、というのがスクラムコーチの考えでした。</p>

<p>この時、チームはスクラムガイドに従ってやっているのに、なぜうまくいかないのかわからない迷走状態だったので、見学会の提案はチームにとって一筋の光明が差した感覚でした。</p>

<h3><strong>アジャイル見学会への様々な期待</strong>&nbsp;</h3>

<p>私たちは、様々な期待を持ってアジャイル見学会への参加を決めました。</p>

<ul>
	<li>成功事例を知れるかもしれない</li>
	<li>リモートアジャイルのやり方がわかるかもしれない</li>
	<li>スクラム導入に向けてのアドバイスが受けられるかもしれない</li>
	<li>学習を継続するモチベーションの保ち方がわかるかもしれない</li>
	<li>実際にスクラムやっている会社と自分たちとの違いを知れるかもしれない</li>
</ul>

<h3><strong>アジャイル見学会のANAシステムズの事例</strong>&nbsp;</h3>

<p>アジャイル見学会では、基本的なスクラムを忠実に実行している12名の開発者と、SM、PO代理で構成されたANAシステムズのスクラムチームの事例を聞くことができました。&nbsp;</p>

<p>ANAシステムズが行なっている、スクラムを実現させるための様々な工夫の中から、「これは秀逸だ」と感じた2つの工夫を紹介します。</p>

<h3><strong>1つ目の工夫：情報共有</strong>&nbsp;</h3>

<p>情報共有の工夫とは、一枚のオンラインホワイトボードに全ての情報を集約することです。</p>

<p>オンラインホワイトボードを見れば全てがわかるようにしてあり、毎日メンバー全員で共有し、そこにはスケジュールやバックログ、バーンダウンチャートだけではなく、スクラムガイドやチーム構成から自己紹介、仕様書、年表など、必要な情報は全て乗せてありました。&nbsp;</p>

<p>情報をただ乗せるのではなく、見るための工夫や遊び心もあるものでした。</p>

<h3><strong>2つめの工夫：レンジャー</strong>&nbsp;</h3>

<p>このチームでは、スプリントバックログアイテムをPO代行✖️SM✖️開発メンバーで、1スプリントでデプロイできるところまで小さくリファインメントし、それをプランニング時に並べ替えを行い、3名のサブチームで担当するそうです。&nbsp;</p>

<p>この3名のサブチームがレンジャーです。&nbsp;</p>

<p>レンジャーとは、スプリント毎にくじ引きでランダムにメンバーを配置した１スプリント限定のサブチームのことで、なぜこのようにやっているかというと、特定の人がプロダクトを担当することで属人化してしまう問題を、ランダムに配置することで防ぎ、経験の均等化を実現するためだそうです。&nbsp;</p>

<h3><strong>アジャイル見学会でわかったこと</strong>&nbsp;</h3>

<p>ANAシステムズの事例の他にも、ディスカッションの時間も設けられ、たくさんの話を聞くことができました。&nbsp;</p>

<ul>
	<li>ステークホルダーにも開発者にもわかりやすいユーザーストーリーを書く</li>
	<li>Discordの活用</li>
	<li>一度に多く変えすぎない、１週間に１つ</li>
	<li>案件の隙間、ちょっと手が空いたときにスクラムを浸透させる</li>
	<li>スクラムは目的を達成するための手段である</li>
	<li>新人教育にモブワークを活用している</li>
</ul>

<p>などなど...</p>

<p>今回の見学会で学べたことは沢山ありますが、一番はスクラムは銀の弾丸ではなく、アジャイルになるために成功や失敗の振り返りを行い、課題とその解決を継続的に解決していく、「自己改善できる組織作りのフレームワーク」であること。そして、それを自分達のプロジェクトに合わせてカスタマイズすることが必要であることを再認識しました。</p>

<h2><strong>総括</strong></h2>

<p>第３チームは、まだスクラムを開始して半年も経っていません。まだまだ解決すべき課題があり、解決しても次々に課題ができています。</p>

<p>スクラムどころか、チームがバラバラになってしまうのではという恐怖もありました。&nbsp;</p>

<p>スクラムは課題を早期発見し、解決するためのフレームワークであるとするならば、第３チームに今たくさんの課題が出続けているのは、スクラムを実施していたからこそ発見できたともいえます。&nbsp;</p>

<p>アジャイル見学会で、スクラムは自分達で工夫をしてチームに合うように改善する必要があり、それらは一朝一夕で終わるものではく、継続的にやり続ける意志と勇気、そしてチームワークが必要だと言うことなのだと学びました。&nbsp;</p>

<p>まだ志し半ばです。そんなに遠くない近い未来で実現出来ると信じて、第３チームは「協力し合える一番早いチーム」を目指し今後もスクラムを続けていきます。</p>

<p>&nbsp;</p>

<p>EXNOAでは、一緒にDMM GAMESプラットフォームを開発していく仲間を募集しております。ご興味のある方は下記募集要項をご覧のうえ、ぜひご応募ください。</p>

<p><a href="https://dmmgames.co.jp/recruit/entry/job/id=182">フロントエンドエンジニア（東京（六本木））の採用について - 合同会社EXNOA</a></p>

<p><a href="https://dmmgames.co.jp/recruit/entry/job/id=1069">国内プラットフォームチームリーダー候補（エンジニア経験者）（東京（六本木））の採用について - 合同会社EXNOA</a></p>


DMM GAMESプラットフォーム部における、開発チームのスクラム導入初期時の事例についてご紹介します。

協力し合える一番早いチームになるために〜スクラム導入初期の取り組み紹介〜

シェア

関連する求人

関連する記事

関連するサービス

協力し合える一番早いチームになるために 〜スクラム導入初期の取り組み紹介〜

シェア

関連する求人

関連する記事

関連するサービス

協力し合える一番早いチームになるために〜スクラム導入初期の取り組み紹介〜