【新卒】23卒の新卒メンバーで1ヶ月のチーム開発研修に取り組んだので振り返ってみた

先日、クラスメソッドグループの新卒メンバーによる1ヶ月のチーム開発研修が終了しました。この研修を通じて、エンジニアリングに関する技術やチーム開発について多く学べました。今回はチーム開発研修でどんなことをやったのか・どういった学びがあったかについて紹介していきます。

#新卒研修

#チーム開発

#クラスメソッド

おのやん

2023.06.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは！2023年度新卒入社のおのやんです。

先日、クラスメソッドグループの新卒メンバーによる1ヶ月のチーム開発研修が終了しました。この研修を通じて、エンジニアリングやチーム開発について、多くの学びを得ることができました。

今回はチーム開発研修でどんなことをやったのか・どういった学びがあったかについて紹介したいと思います。

クラスメソッドグループの新卒研修について

クラスメソッドグループの新入社員は、入社してから約3ヶ月間新卒研修を受けることになります。この研修期間で、基本的なビジネスマナーだったり、GitやLinuxといったソフトウェア開発の基礎を学びます。

この研修の集大成として、6月をまるまる使ったチーム開発研修があります。チーム開発研修では、新卒メンバー同士でチームを組んで、アジャイル開発でプロダクトを開発していきます。

そしてチーム開発研修が終わると、新卒メンバーは7月から各部署へと配属されていきます。

（ちなみに私も先日配属が決定しました。戦力になれるよう頑張ります！）

1週目: 5/29(月)~6/2(金)

ここでは、チーム開発研修の1周目に取り組んだ内容について紹介していきます。

新卒メンバー、日比谷オフィスに集合

2023年度の新卒メンバーは、基本的に全国からリモートメインで勤務しています。今回は開発チームの立ち上げということで、全員東京の日比谷オフィスに集められました。4月以来の久々の顔合わせだったので、すごいテンションが上がりました笑

余談ですが、この「チームの立ち上がりのタイミングに対面で顔を合わせる」という動きは、チーム形成に大きく影響します。アジャイルサムライには、"「チームの生産性を劇的に改善できる方法をひとつだけ挙げろ」と聞かれたら、間違いなくそれは、全員が同じ職場に集まって働くことだろう。"と書かれています。

アジャイル開発講座

クラスメソッドでスクラムマスターをされている社員さんによる座学が行われました。ここでは、アジャイル開発で出てくる用語や概念を学んだほか、アジャイル開発のワークショップにも取り組みました。

このワークショップでは、新卒メンバーでスクラムを組んでエレベーターピッチを作ったり、プロトタイプを作るプロセスを回したりしました。その後にチームに分かれて開発をスタートさせました。

エレベーターピッチ

ワークショップで最初に行ったのがエレベーターピッチの作成です。エレベーターピッチについての説明は、アジャイルサムライから拝借します。

急げ！今エレベーターに乗ろうとしているのは、3ヶ月前からどうにかして会いたいと思っていたベンチャーキャピタルの関係者だ。エレベーターで同乗している30秒のあいだに、君が始めたばかりの新規事業を説明しなきゃならない。

（中略）

これがエレベーターピッチという言葉の由来だ。ごく短い時間でアイデアの本質を伝える手段というわけだ。

私たちのチームは、ワークポッド（1~4人で使える個人用作業ブース）の利用状況がひとめで確認できる「Hitome」というWebアプリケーションを作ることにしました。そのため、これらの特徴をシンプルにエレベーターピッチに書き出しました。最初は、エレベーターピッチなんて簡単に書けるだろうと思っていました。が、作業時間中に何度も修正が入ったり、「やっぱこれ書き直した方がいいな」と思える箇所が作業中ずっと出てきて、時間内にギリギリ終わるといった具合でした。

私たちのチームのエレベーターピッチを共有しておきます。

プロトタイプの作成

次に、メンバー間でおおまかなデザインについて話し合いました。具体的には、miroの付箋などを使って、プロダクトデザインのモックを作成しました。このままプロダクトに使うわけではないのですが、どこにどんな機能を持たせるかはイメージできるようにしました。おおまかでも形にすることで、各メンバーの認識を擦り合わせていきました。

技術スタックの決定

チームメンバーが扱う技術についても、1週目で決定しました。私は大学時代からReactをメインにフロントを扱っていました。またチームメンバーの中には、AWSでバックエンドを構築できるメンバーもいました。ということで、2人ずつフロントとバックで分かれて、それぞれ私とAWSができるメンバーがもう1人のメンバーをサポートすることになりました。

チーム全体でどう動くか決定

2周目以降はほぼ全員オンラインで作業することになっていました。そのため、開発期間中にどのようにコミュニケーションを取ればいいか話し合いました。

最終的に、開発中はGather（ドット絵のRPG風オンラインコミュニケーションツール）に常駐しようという方針になりました。わからなかった時にすぐにメンバーに聞ける環境は大事です。

Figmaでのプロトタイプ作成

ここでは、miroで組んだデザイン案を具体的にプロダクト向けに落とし込んでいきました。メンバーは全員Figmaは扱ったことがなかったため、都度調べながらプロトタイプを作成していきました。やはり今メインのデザインツールということもあって、かなりそれっぽいデザインにできたと思います。

開発環境の整備

チームメンバーのPCには、開発環境が整備されていませんでした。そのため、全員と対面で話せる1週目の段階で、VS CodeやGitHub、Node.jsなどの開発環境を構築していきました（いまだにNode.jsのバージョン管理ツールは正解がない感じなんですね...）。

日比谷オフィスのメンバーに直接ヒアリング

日比谷オフィスのお昼休みの時間に、社員の方々にチームのプロダクト案をレビューしてもらいました。フィードバックとしては、「めっちゃ欲しい〜！」「需要はあると思います」など、ポジティブなフィードバックが多かったです。一方で、「ワークポッドに人がいる時はどうやって検知するの？」「リアルタイム性は欲しいですね」といった、改善フィードバックもいただきました。これらの意見を踏まえて、実際の開発に進んでいきました。

2週目: 6/5(月)~6/9(金)

次に、チーム開発研修2週目で取り組んだことを紹介します。

プロダクトの開発

2週目は、1週目に準備した開発環境をもとに開発を進めていきました。

フロントの実装

私はフロントエンドの担当だったため、プロダクトのUI部分を実装していきました。この際、もう一人のフロント担当メンバーがフロントの経験が浅かったため、そちらの後方支援にも回っていました。うまくサポートできたんだろうか？と今でも思います。

実装内容としては、バックエンドに対してAPIリクエストを送り、返ってきたレスポンスを画面に表示するというシンプルなものでした。そのため、今回の実装では設計やリファクタリングを積極的に行いました。こちらも、学生時代はあまり意識したことはなかったです。なので、チーム開発研修をサポートしてくださるオブザーバーの方々にガンガン質問を投げていきました。

テストの導入

チーム開発研修の指針として「できるだけテストは書いた方がいいですね」と言われていました。今までフロントのテスト経験はなかったのですが、いい機会だと思ってフロントのテストを導入してみることにしました。ここでも、オブザーバーの方々に積極的に質問していきました。

オブザーバーの方々は普段から開発に関わってくださっていたので、私たちの質問にも丁寧に対応していただきました。これがなかったら開発が相当遅れていました... 本当に感謝です。

質問ルールの設定

チーム開発研修を通して感じたのは、質問マジ大事ということです。巷では「15分調べてわからなかったら質問しろ」と言われたりもしますが、本当にこれだと思います。調べてもわからなかったら多分知識がないので、自分より知識のある人に聞くのがいいです。それが個人にとっても全体にとってもいいんじゃないか、と感じました。

このルールは途中から私たちのチームにも設定されました。本当にこの心構えは重要だと思います。

アジャイルサムライ購入

2週目に入って、「アジャイル開発むずかしいな！？」になっていました。ファシリテーターとして会を進行する時も、どうやったらうまくチーム開発を回せるんだろうと考えていました。そんな時に、アジャイル開発講座を受けた際の参考資料としてアジャイルサムライが紹介されていることを思い出しました。そこで「読むなら今しかねぇ」と書店に駆け込んでアジャイルサムライを購入しました。だいたい3~4日で読み終えたと思います。

具体的な経緯・感想はこちらの記事に記載しています。

オンラインユーザーレビュー

2周目の木曜日には、クラスメソッドグループ社員の方々を呼んでのレビュー会を行いました。週に1回、第三者からのレビューをもらって、プロダクトを改善していこうという取り組みです。

レビュー会当日は社員さんが数名来てくださりました。そこで実際に開発しようとしているプロダクト案や現在の進行状況、今後の開発方針について話しました。そこでは「座席の利用可能数が減ってきたら黄色の警告バッジを表示するのはどうか？」「時間帯がおおまかに予想できると使いやすいですね」など、プロダクトのクオリティを上げるような意見をいただけました。

3週目: 6/12(月)~6/16(金)

このあたりになると、だいぶアジャイル開発やスクラムの加減がわかってきました。毎日の会の進行もスムーズに行くようになりました。

デザイナーさんのレビュー

3週目の時点での一番の懸念事項が、マップのデザインでした。2周目までの実装段階で「日比谷オフィスのどのエリアか判断つかない」といったレビューが多数見られました。しかし、メンバーの中でデザインに精通している人がいませんでした。毎日のスプリントレビューでも「デザインどうにかしようぜ」という意見は出ていましたが、正直詰みの状態でした。

このことを察したオブザーバーさんが、ある日「デザイナーさん呼んだからレビューしてもらいましょう」と突然のデザインレビュー会を開催してくれました。そこでは、デザイナーさんからゴリゴリのデザインの観点からのレビューをいただきました。デザインの観点で物事を見たことがなかったので、レビュー会の時間はただ圧倒されていました。

いただいたデザインレビューを一部載せておきます。

4週目: 6/19(月)~6/22(木)

さあ大変です。木曜のチーム開発最終日までに、4週目の実施予定のタスクに加えて、先週もらったデザインレビューも反映させる必要があります。4週目のタスクを整理するウィークリースプリントプランニングでも、「今までの実装のベロシティ（開発の速度）の上振れを狙わないと間に合わない」という共通認識ができていました。

猛スピードでの実装

木曜には開発が終了するので、プロダクトの機能を猛スピードでさばいていきました。

アイコンの変更

今まで設定していた地図上のワークポッドのアイコンを、人の表示から利用可能な数字に置き換えました。

マップの変更

オフィス内の机や座席といったオブジェクトを目立たないように表示させたバージョンのマップを作成しました。このマップは、チームメンバーの数人が担当して作業してくれました。感謝！

アイコンの作成

メンバーが持ち寄ってくれたアイコンデザイン案をもとに、Figmaでアイコンを作成しました。最初に作ったアイコンの方は、私もメンバーも（なんか違うんだよなぁ...）みたいな雰囲気になっていました。そこからいくらか改良を加えて、最終的にシンプルな感じのアイコンで落ち着きました。最終的に検討したアイコンはこんな感じになります。

プロダクトアイコンはこんな感じに決まりました！決まった方のアイコンは、メンバーみんなが「めっちゃいいやん」と言ってくれました。これをSVGファイルに出力して、Reactのフロント部分に読み込ませました。

モバイル版とデスクトップ版でUIを切り替え

これはタスクとしてToDoリストに上げたものではなく、チームメンバーが自主的に実装したものでした。いつの間にか実装してきて、しかもめっちゃいい感じのUIになってました。具体的には、画面幅を検知して一定以上の幅になるとUIが切り替わるようになっていました。マジですごい。

こちらがデスクトップ版のUIになります。

そして、こちらがモバイル版のUIになります。

最終週のプロダクトの伸びがすごかったです。前の状態だと、まだプロダクトとしてリリースするには不十分というか、クオリティが高いわけではありませんでした。それを、それぞれのメンバーがそれぞれできることを同時並行で処理しまくって、3日間でほぼほぼ実装できました。1ヶ月のチーム開発研修の中で一番稼働していたと思います。

最後のレビュー会

この最終盤のプロダクトを引っ提げて、最後のレビュー会に臨みました。

評価としてはなかなか良かったです！「めっちゃ見やすいっすね！」「問題とその解決方法がはっきりしていて、課題解決のプロダクトとしてめちゃめちゃイケてると思います！」とのフィードバックをいただきました。一方で、「オフィスにあるすべてのワークポッドを管理しようとしたら、社内プロダクトになりますね」といった、実際の使用を考えた際のフィードバックもいただきました。

このプロダクトでは、ワークポッドの中にSwitchBot人感センサを置いて人を検知する想定でした。今回の研修の都合上、今回はSwitchBotからのデータは用いず、DB上にはダミーデータを持たせました（SwitchBot自体はちゃんと動作することを確認済みです）。そのデータを1分間ごとにランダムで切り替えてレスポンスを返すという仕様になっていたため、どうしても実際の想定と比べるとリアルタイム性に欠けていたと言えます。また実運用するのなら、SwitchBotを20個ほど購入してワークポッドに設置し、そのデータをインターネット上に飛ばすことも必要でした。こういった感じで、実際に使用するとなるとまだまだ不十分な部分は多かったです。

それでも、プロダクトの完成度自体はかなりの高評価でした。この1ヶ月間、頑張って本当に良かったです。

チーム開発研修を振り返って

このチーム開発研修ではさまざまな学びがありました。最後にこれらを紹介していきたいと思います。

議論することの大切さ

チーム開発研修では、開発に携わるのは1人ではありません。チームメンバー全員が関わるプロジェクトになります。そのため、何か詰まったりわからない部分があれば、チーム内で積極的に共有して議論していきました。

後から考えてみれば、この動きがめちゃくちゃ効果的だったと思います。自分がいいと思っていたことは、他の皆からは不評だったりします。チーム内で認識の齟齬が発生する前に、自分から積極的にメンバーと話し合う雰囲気・土壌を作り上げていくのが大事なんだなーと思いました。

教える側の学び

新卒研修だと、新卒のメンバーは初めてのことを多く経験します。そのため、学びも多くあると思います。しかし同時に、新卒メンバーを指導する講師やオブザーバーといった役割の人たちにも学びがあるんですね。私は最後の振り返り会の時にこれを感じました。

具体的には「デイリーでスプリントを回していたからか、チームの立ち上がりが早かったですね。案件でもチームの立ち上げの際にデイリーやってみようかな」といったフィードバックをもらいました。これらは新卒として研修を受ける側だった私からみると、かなり意外なフィードバックでした。今までその視点に立ったことがなかったので、「へぇ〜学びがあったのは新卒メンバーだけじゃなかったのか」と興味深く思いました。

もし将来研修などを教える立場になったとしたら、その立場からも学びを得られるような先輩になりたいですね。