こんにちは！ 今年もう2ヶ月ほど経ちましたがまだまだ寒い日が続いていますね。
イノベーションセンターの原田です。 本日は2021年11月頃に実施しました新入社員研修の取り組みについてご紹介します。
研修の概要について
このハンズオンは新入社員が半年ぐらい業務に携わった頃に おそらく対峙する or したであろうレガシーなコードについて、 どのように立ち向かうべきか?を5日間チームで手を動かしながら学習していただく研修です。
この研修には2つのゴールがあり、1つ目が「レガシーコードを安全に変更するための土台作りの方法を学ぶ」、2つ目が「どのようにレガシーコードを戦略的に改善していくか意識付ける」です。
受講生は 20 名で、2021 年度入社以外の社員も数名参加しました。 また講師・メンターを社員7名が担当し、 研修は全体を通してオンラインで行いました。
下記は全体のスケジュール表になります。
こちらの表の通り、 まず1日目にレガシーコードをドンッ!と配って仕様を理解した後、 2日目でテストコードを用意し、3日目からリファクタリングや新規機能の実装に入ります。
また演習の前後にはチーム間レビュー(隣のチーム同士で意見交換)とふりかえり(KPT)を用意しており、 他のチームが得た知見や気づきを共有する場を設けています。
なお研修のジャンルとしてソフトウェアが中心となりますが、 新卒研修として NTT Com では他にもネットワーク研修、AI・データサイエンス研修などがあります!
なぜこの研修を実施したか
ソフトウェアをテーマとした新卒研修は毎年行われていますが、 昨年までの内容が IaaS や CaaS、CI/CD が中心でコードを書くことがメインでは無かったため、 新入社員から「もっとコードを書きたかった!」と意見を頂いたことがきっかけとなります。
また、NTT Com ではNeWorkなど内製開発に注力していますが、 社員が開発中の悩みをヒアリングした結果 既存のコードについてのリファクタリング・リアーキテクチャに対する悩みを持っていることが分かりました。
よって本研修を通してレガシーコードに対するアプローチ方法を学ぶことで開発力に磨きをかけ、 エンジニアとしてのキャリアを形成する後押しができればと思い企画しました。
研修の一例について
ここからは各日の研修の流れを簡単に紹介していきます。
Day1 レガシーコードを読む
レガシーコードの定義から説明し、どのようにコードを読み進めていくか解説しました。 なおレガシーコードとしてN-PTC 2020で利用したコードを題材として取り上げ、受講生は手探りで仕様を理解していきました。
Day2 テスト可能にする
1 日目に読み込んでもらったレガシーコードについて、手を加える前にテストを書きます。 テストとしては単体テスト・結合テスト・受け入れテストなどをそれぞれ実装してもらいましたが、 まずは結合テスト(API テスト)から実装してもらいました。
もちろん一日で全てのテストを書ききることは難しいため、3 日以降もテスト実装に時間を割いても OK にしています。
Day3 レガシーコードの継続開発
おおよそテストが実装できたらレガシーコードをリファクタリングして改善していきます。 また、このレガシーコードはビジネスと直接紐付いているというシナリオの元、新規機能の追加実装も業務として入ってきます。 そのため、演習者はソフトウェアを破壊しないように注意しつつ、新規機能の実装やリファクタリングを行う必要が出てきます。
また講義では、レガシーコード改善の真の目的が「ユーザへの価値提供の速度を最大化する」であることに触れ、 これから演習者がどのような実装戦略を立ててユーザへの価値を最大化するかの意識付けを行いました。
Day4/Day5
ここでは具体的なリファクタリング方法や細かなTipsを説明しました。 なお新規機能の追加や新たなお題の出題は無く、演習者がこれまで出された要求に対して取り組む時間となります。
受講生の反応
ここからはデータプラットフォームサービス部の堀内が、研修の受講生の反応についてご紹介します。
研修に参加した動機
事前アンケートで研修に期待することを聞いたところ、下記のような回答が得られました。
- レガシーコードに対して具体的にどう対処すれば良いか、どういう観点でリファクタリングすれば良いか学びたい。
- テスト駆動開発と絡めてレガシーコードをリファクタリングする手法について学びたい。
- 業務でレガシーコードを多く目にするので、研修での学びをチーム内で展開するなど、それらを減らす取り組みをしたい。
また、新入社員の方が中心ということもあり、受講生のスキルは下記のような状況でした。
- テストケースを考えたことや単体テストを実装したことはあるが、E2E などの結合テストは未経験という人が多い。
- CI (Continuous Integration) を使ったことがある人は多いが、設定したことがある人は少ない。
- GitHub を使ったことがない人や、ペアプログラミング / モブプログラミングをしたことがない人はそれぞれ半数程度。
研修中の様子
受講生は 2 人 1 組でチームを組んでもらい、そこにメンターが 1 人付くという形で演習に取り組んでもらいました。 研修中のコミュニケーションのために Slack を提供し、ペア作業ではチーム毎の Channel で Huddle を使いました。
Day1 のコードリーディングでは、準備した我々も「分かる」と言いたくなるようなコメントが多く上がりました。
- コメント / ドキュメント / テストがなく、処理の内容が分からない。
- 変数名 / 関数名が分かりにくく、意図が読み取れない。
- ソースコードのネストが深かったり、同じような処理が散らばっていて、追い掛けにくい。
Day2 では、レガシーコードに手を入れ始める前に、 まず単体テスト (pytest) と結合テスト (Postman) の実装をしてもらったのですが、 チームメイトと初対面の人も多い中、Visual Studio Live Share などを活用して上手くペアで作業を進めており、非常に驚きました。
Day3 〜 5 では業務に沿ったシナリオで演習に取り組んでもらったため、実際に直面しがちな問題に向き合ってもらいました。 各チームの振り返り (KPT) を覗いてみると、下記のようなコメントが見られました。
- 良かった点
- レガシーコードの課題を GitHub の Issue に洗い出し、チームメイトとこまめに情報共有ができた。
- テストコードを先に作り、それを通すように実装することで、テスト駆動開発を実践できた。
- 「ユーザに価値があるか?」を基準にして、機能追加とリファクタリングの優先順位を判断できた。
- docker-compose と GitHub Actions を使って CI を実現できた。
- 悪かった点
- 機能追加を優先した結果、リファクタリングがおろそかになり、レガシーコードを生み出してしまった。
- リファクタリングを後回しにした結果、デバッグのコストが増え、実装を完了できなかった。
- Postman など、演習で利用するツールを使いこなすのに手間取ってしまった。
メンターからのアドバイスとしては、NTT Com の技術顧問でもある @t_wada さんの下記資料が共有されていました。
研修後の評価
5 日間の研修を終えた受講生に事後アンケートで「今回の研修で学んだ知識・経験は業務で活かせそうだと思いますか?」と聞いてみました。 どの質問も「そう思う」「非常にそう思う」と回答した人が 8 割以上で、メンターとしてはホッとする結果でした。
また、アンケートには下記のようなコメントが寄せられました。
- 実際の現場では様々なコードがあり、そこから作成者の意図などを読み解く必要があるので、今回の経験を活かしていきたいと思った。
- テスト駆動開発を実践できたのは非常に得るものが多かった、日頃の開発でもテストを書いてから実装に取り組みたい。
- リファクタリングをする上での観点 / 考え方や、機能追加との兼ね合いなど色々な側面での知見が得られたとので、今後の業務に反映していきたい。
講師側の所感
後日、講師/メンターをした社員で集って振り返りを行いました。
- Keep
- 資料に重要なポイントが落とし込めていて分かりやすかった。
- GitHub の Issue で進捗の見える化をした結果、研修準備のプロジェクトが大炎上しなかった。
- (ラフではあるが) 事前に研修をテストプレイをして資料や題材をブラッシュアップできた。
- Problem
- Day3 以降、受講者がデザインパターンやリファクタリングなどの知識不足によって遭難しはじめる様子が見て取れた。
- 講義資料がギリギリまで出来上がらなかったり、コードと資料の齟齬があったりした。
- Git / GitHub や Postman の使い方に関する資料が足りていなかった。
- 研修題材にわかりにくい部分があった。
- Try
- Git / GitHub 研修の資料を流用するなどして、事前学習をもう少し充実させたい。
- @t_wada さんに受講してもらって模範回問を用意する、研修の流れや分量についてアドバイスをもらう。
- 今回の研修内容は全体的に難しめだったので、難易度の調整をする。
まとめ・今後について
今回の研修の評価 / 反省を受けて、2022 年も新入社員向けのソフトウェア研修を実施したいと思っています!!
