新入社員向けスクラムゲーム

 # 新入社員向けスクラムゲーム

認定スクラムマスターを取得した2019年に、新入社員（１１人）向けのアジャイル開発の研修をしてほしいと社内で依頼がありました。

11人のメンバーはプログラムを大学で書いていたメンバーが5人であとはIT技術は素人でJavaの研修を受けたくらいです。

研修の内容は業務の内容とは関係なく、登場人物も仮称を利用させていただきます（僕以外は）。

研修の概要は以下のような感じです。

+ 単価マスターと売上情報を掛け合わせるような販売管理システムの構築

+ 社会人の開発者であれば1日か2日あれば作れるような内容

+ 4日間の作業研修で半日（3時間）が１スプリント

+ 1スプリント終了後に30分のスプリントレトロスペクティブを行う

+ 要件書類に不備がある（質問すると正しい答えを教えてもらえる）

+ スプリント中に３０分だけステークホルダ役への質問タイムがある

+ 5回めのスプリントでステークホルダの要望が追加される

+ 開発言語はユニケージ（何でもいいと思います）

開発言語が特殊で２日間ほどの研修を、アジャイル開発研修の前に行っていましたが、メンバーの中ではまだ経験が浅く、言語習得はまちまちな状態でした。

作業前に1日かけてスクラム開発の教育を行いました。

作業前のブリーフィングの様な感じです。

最初に技術力順に自己申告で並んでもらって、チーム編成をしました。

チームは３チームです。

Aチーム

一番技術力があるとされるメンバーが所属し、その代わりにメンバーは３人チーム

Bチーム

特に誰かが突出しているわけじゃない４人チーム

Cチーム

一人目立つメンバーがいるが、それ以外はおとなしい４人チーム

開始初日の動向

+ すべてのチームがチームの要のメンバーを中心に作業を行う

+ PBIをポストイットに記述して貼る作業を行っていない。

+ とにかく実装を行う（調査や情報の整理を行わない）

初日の動向を見てのフィードバックとして以下のような助言を行いました。

+ メンバー全員が効率的に動けるように業務分担する

+ PBIを必ず記述し調査や質問事項などもPBIで記述してホワイトボードに貼る

+ 初日のブリーフィングで教えたスプリントで必要とされるミーティング（プランニング、レビュー）などの実行を行う

+ PBIの作業コストはぼんやりでもいいので予想しておく

翌日の時点でBチームが初日の作業もPBIも捨てて作業し始めました。

勇気のいる行為でしたが、Bチームは誰かがメインで作業を行っていたA,Cと比べても目に見えて作業ができていなかったので、英断だったと思います。

Aチームは完全に技術力のあるメンバーがメインで動いていて、実装をゴリゴリに作成している感じでした。

他の二名は必要そうな設計などを調べていましたが、あまりメインで動いているメンバーと息があっている感じではなかったです。

Cチームもきっちりできるメンバーに頼り切りの場面が多くなっていました。

2日目を終えて折り返しでしたが、この時点で要件を満たしてしまうチームはいませんでした。

弊社に入社してくるレベルだと学生で突出した技術力のあるメンバーが居ることは少ないため今回の結果は妥当でした。

2日目のフィードバックとして

+ 作業中のメンバーは作業中のPBIを自分の手元において仲間に作業中のPBIを表示する

+ コミュニケーションを行うタイミングと作業するタイミングにメリハリを付ける

+ 質問時に現在作っているプログラムは動くようにしておいて動いている状態で進捗を報告する

2日目はじめに作業を全部捨てたBチームは2人ごとの2チームを内部で作り、ペアプログラミングをする形に変更し、スプリントの開始と終わりに必ずミーティングを行うこと、PBIの整理をその際に作り、不足分を協議して実装する場合に必要かの優先度をつけて作業をし始めました。

最初に教えたことを忠実に実践し始めました。

（ペアプログラミングは教えていませんでしたが、前日帰宅後に調べてきたようです）

3,4日目は時間ギリギリの中で全員が必死になって実装を行っていましたが、最終的に3チームとも実装はできていなかったです。

作業全体を終えて。

Aチーム

作成したプログラムは動作しているものの実装は途中までしかできていませんでした。明らかにメインと他2名で業務の差が大きく、メインのメンバーが間違えて実装していたことを指摘して戻るまでに半日（1スプリント）無駄にしたという報告をもらいました。

レトロスペクティブの時間も実装の話をしていたり、交流がしっかりできていなかったりというのが見受けられました。

チームで業務を行う上で今回の問題の解決策としてどうしたらよいか、ということを最後に話し合ってもらいました。

Bチーム

1日目を捨てたチームでしたが、実装がかなり進んでおり、2日目に出された追加要件以外は実装が終わっていました。一部処理の難しい帳票は省略した帳票で実装されており、もっともステークホルダの要望に答えられたチームとなりました。

成功の要因として、使い方のわからないコマンドはペア二人で別々で使い方を模索、そして本番コードは一緒に実装する。そこでわかったことはスプリントレトロスペクティブのミーティングでお互い情報を交換する。

このチームは30分とスプリント時間に比べて非常に長いレトロスペクティブの時間を実装時にどうするべきか、作業に詰まったところ、4人で並列に行う作業と、一緒に行う作業のタイプの分類などをしっかりと時間いっぱいに活用していました。

Cチーム

最後までバラバラでした。4日目になっても一人は実装していたけどほかのメンバーはそれを眺めているだけで手を動かす雰囲気もなく終わりました。

メンバーの中で自発的にどのように行動をするかなどの仕切るタイプもおらず、各自で分担して作業することもなく、研修を終えていました。

他のチームから比べて遅れてしまった最大の要因は誰かに任せてしまったことというのを口を揃えて発言していました。

今後の業務を行う上で、各自が自律して業務を行うためにどのようにしたらよいかを最後に話し合ってもらいました。

## 研修を通して学んだこと。

自分自身もスクラムで業務を行う前でしたが、今回一番学んだことは、Aチームのトップメンバーは11人の中では技術力は非常に高く技術的な感もあったためここがダントツで全部こなしていくことより、結果的にはメンバー4人がスクラムの規律の中で、自律して業務を行い、効率的に作業したBチームが最も実装を行えた結果を見れたことです。

初めて何かを作るという不確定性の高いことに、手探りで挑戦していく上でスクラムの規律に乗っ取り勧めていくことで、効率的に困難に立ち向かえることも学びました。

新入社員だけでなく、僕自身も学べましたので。

みなさまにも、研修の一環としてこのようなミニゲームを実践していくのをおすすめします。

> Written with [StackEdit](https://stackedit.io/).