Visionalグループでは、2019年より新卒研修のカリキュラムの1つとしてスクラム研修を実施しています。 この研修では、単にスクラムのイベントを一通り体験してもらうことが目的ではなく、実際に新卒入社者でチームを作り開発する中で、スクラムやAgileで重要にしている考え方を体験してもらっています。 本記事では、研修で用いたリポジトリも公開しつつ、どのような考えで研修を行っているのか紹介します。

Visionalにおける新卒研修の全体像とスクラム研修

2021年度の新卒研修は実践課題だけでなく、その前提となるチーム開発やプロダクト組織で働くうえで欠かせない研修を含む、以下8つの研修で構成されています。

これらの新卒研修で大切にしている考え方や大枠については、技術力だけではない、Visionalの新卒研修フレームワークにて紹介しています。

本記事では、新卒研修で行っているスクラム研修とはどのようなものなのかを、重点的にご紹介します。

スクラム研修の設計方針

スクラム研修では、下記の設計方針で進めています。

結果として、実体験がまずあるため、知識やプラクティスを自分たちのプロセスに組み込みやすくなります。

スクラム研修の流れ

Visionalグループでのスクラム研修は、1つのプロダクトを2チームに分かれて同時に開発することを題材にして、4日間で1Sprintを体験してもらいます。

そして予め伝える内容を決めておくのではなく、体験の中で講師が伝えるべきだと感じた内容を都度伝える流れになっています。

なお、今回はオンラインで開催しました。そこで、Zoomを用いて、各チームで分かれて作業をする場合はブレイクアウトセッションを活用しました。

タイムスケジュール

下記のようなスケジュールになっています。

研修のスケジュール

今回は、スケジュールの中で特徴的なものを紹介します。

リファインメント

今回の題材に対して、研修運営側で予め作成していたストーリーを用意しておきます。

そのストーリーを見て、どのような振る舞いを期待しているのかgherkin形式1で整理して記述します。

デイリーレトロ

研修中は通常の業務よりもふりかえりに重点を置いています。研修では新たなことを学ぶ機会が非常に多いので、1Sprintの最後に行っても忘れてしまう可能性があると考えました。そこで、「デイリーレトロスペクティブ（デイリーレトロ）」という形を取り、毎日ふりかえることができる場を設けました。

コード鑑賞会

デイリーレトロでは仕事のやり方のふりかえりに目が行くことが多いと予想していました。しかし、研修ではスクラムの考え方や仕事のやり方を学ぶと同時に、コード品質の大切さも学んでほしいと考えました。

そこで毎朝、前日にコミットされたコードの中からピックアップして、どうすればもっと良い（技術的負債を軽減する）コードにすることができるのかを考える機会を設けました。

講義

前日の午後から当日の午前中までに起きた体験から1つピックアップして、その内容に関連する話を伝える機会を設けました。

あくまでも、実際に起きた体験を元にした講義のため、当事者感を持ちやすい内容になっています2。

また、お昼休憩明けに講義の時間を用意していましたが、この時間帯の実施を義務とはしていません。

講義で伝えるべき重要な出来事があった場合には、よりタイムリーに伝えるために、発生した出来事の直後にイレギュラーで講義する場合もあります3。今年の研修でも、そのようなことが発生しましたので、詳しくは後述します。

資料鑑賞会

コードを除き、今回の研修で作成したものは全て、miroに貼っています。

その中には、リファインメントで作成したシナリオ、プランニングで作成したタスク一覧、デイリーレトロやレトロスペクティブで作成した付箋、講義の説明で使用した資料など多岐にわたります。

そこで研修の最後に、作成した資料を見直す時間を設けました。

ワーキングアグリーメント

初期のワーキングアグリーメントとして、下記を設定しています。

なお、「gitの使い方」についてはGit/GitHub研修で、「モブプログラミング」「TDDとATDD」についてはテストの考え方研修で既に教わっている＆体験している状態です。

スクラム研修中に起きた出来事

研修の3日目に、こんな出来事が起きました。

mainブランチにコミットするたびに動くCIが、テスト失敗になってしまった。
そこで、急遽2チームが集まって、テストが失敗になった原因を特定し、今後の実装も想定して、綺麗なコードのままテスト失敗を解消できるか議論した。
1時間弱の議論の結果、テスト失敗が解消されたので、各チームに分かれることとなった。

ここからはいくつかの知見を得ることができます。

すぐにチームを越えて集まった

mainブランチに直接コミットすることによって、お互いのチームの作業を知ることができます。そのため、「CIのテスト失敗＝このままだとどちらのチームも作業を進められない」ということに気付き、チームごとの作業を中断し、チームを越えて集まることができました。

綺麗なコードのままテスト失敗を対処しようとした

TDDについては、「テストの考え方研修」の中で、下記のように伝えていました5。

TDDのサイクル

今回の出来事は、このTDDサイクルの図でいう「3.テストを実行して失敗を確認する(Red)」の状態です。

とるべき方法は下記2つのどちらかです。

しかし今回は、「今後の実装も想定して、綺麗なコードのままテスト失敗を解消できるか」という方向になってしまいました。

つまり、TDDサイクルの図の4,5,6を一緒に行って、Refactoringも議論しつつのRedの解消を目指してしまったのです。

議論が中心となった

上記のTDDサイクルの図の「4. どんな方法でも良いのでコードを書く」を行わず、議論を進めた結果、実際にコードを変更してテストする回数が極端に減りました。

議論も良いのですが、まずは小さく1つずつ試していくことが大切です。

このように、実際に研修中に起きた出来事を元に、出来事の直後に伝えるようにしました。すると、実際に当事者となるため、非常に納得したようでした。

今回のスクラム研修での作成物

「資料鑑賞会」の節で述べたように、コード以外を除き、今回の研修で作成したものは全て、miroに貼りました。

4日間の研修の結果、作成物はこのようになりました。

4日間での作成物

残念ながら詳細をお見せすることはできませんが、非常に多くのことを持ち帰っていただけたのだと感じています。

受講生の感想

4日目のレトロスペクティブの際に、「研修開始直前の自分自身に贈るアドバイス」を考えてもらうことにしました。6

一部抜粋してご紹介します。

自分自身に贈るアドバイス

本記事で紹介した「スクラム研修中に起きた出来事」だったり、スクラム研修を実際に行ったからこそ出てくる内容が多く、研修に真剣に取り組んでいるのがよく分かる内容でした。

スクラム研修のリポジトリ公開

最後に、今回のスクラム研修で使用したリポジトリをGitHub上で公開したので、それを紹介します。

スクラム研修の題材(public版)

このリポジトリでは、Spring Boot + Dockerを使った構成になっています。また、Cucumberも載せており、ATDDで進める準備が整っています。

今回の記事を見て、自分のところでも実施してみようと思った方は、是非このリポジトリを試してみてください！

おわりに

今回は、Visionalの新卒向けスクラム研修についてお伝えしました。

実際に起きた出来事の1つと研修で使用したリポジトリは公開したものの、研修中に起きた出来事は他にも様々ありました。また、今回はご紹介できておりませんが、私は「テストの考え方研修」も担当しました。

どんな研修内容なのか気になる方はお気軽にご連絡くださいませ！

  1. 物事を、前提(Given)、アクション(When)、期待結果(Then)の形式で整理すること。参考文献:Gherkin Reference ↩︎

  2. 一方で講義担当者は、前もって講義できる内容を複数用意しておき、研修中に起きていることを注意深く観察する必要があるため、非常に大変です。 ↩︎

  3. 講義を行うことは重要ですが、本来確保している開発の時間が減っているという事実もあります。そのため、タイムリーに手短に効果的に伝えることも大切です。 ↩︎

  4. 必ずしも、配属後のチームでもmainブランチのみの運用をしている訳ではありません。今回はチーム間の連携を体感してもらうため、この運用にしています。 ↩︎

  5. 和田卓人さんの「見てわかるテスト駆動開発」のスライド12ページを参考にしています。 ↩︎

  6. これは私が考えたオリジナルのふりかえり手法です。プロジェクト（今回の場合はスクラム研修）に入る直前の自分自身に立ち返ってアドバイスを贈ることで、自分自身がプロジェクトを通してどんな価値を感じたのか、どんな点を改善すれば良かったのかふりかえることができます。これは、別のプロジェクトに入る時にも有効なアドバイスになることが多いです。 ↩︎

ブロッコリー
ブロッコリー

QAエンジニア。前職からテストやQAに関わってきた経験を活かし、現在は如何に有効なテストを開発者に書いてもらうか指導・啓蒙している。認定スクラムマスター、認定スクラムデベロッパー。社外活動としては、ソフトウェアレビューシンポジウム(JaSST Review) 実行委員長・WACATE（若手テストエンジニア向けワークショップ）実行委員など。