新卒エンジニアの成長を加速化 〜事業部横断型「360°ソースコードレビュー」制度〜
お待たせいたしました、お待たせし過ぎたかもしれません。初めまして、VST（Vision Success Team）の中野です！
今回はタイトルにある通りですが、エンジニア組織で取り組んでいる事業部横断型「360°ソースコードレビュー」の話をしようと思います。
新卒エンジニアの組織課題
Hajimariでは事業部ごとに担当エンジニアが分かれており、今年は新卒エンジニアが4名入社しました！
各部署に1〜2名が新卒として配属され、1名のメンターが面倒を見る、といった体制をとっています。
コロナ前の全員出社の状況なら、特段問題なかったのですが、
『全員フルリモート』なので必然的に新卒のコミュニケーション相手はメンターのみ、という状態。"新卒の自立"をエンジニア組織全体で支えられず、マンツーマン指導となってしまったがために、こんな課題が散見されるようになりました。。。。！
- 課題
・メンターが忙しい時、新卒に対するフォローが難しい
・部署によって人の成長にばらつきがある
・コロナの影響もあり、事業部外のエンジニアとのコミニケーションが希薄化してる
・新しい知見やノウハウが欲しいのではないか
「Hajimariこそが人生史上No1のチームだ」を目標に掲げるVSTに所属している身としては、新卒エンジニアの成長を、エンジニア組織全体で支えることができていないことは由々しき事態。
そこで、何かないかと、、、
新卒エンジニアの育成方法や組織論等の文献や記事を漁りまくってたら、「新卒エンジニアの育成に、"多頻度マルチフィードバック"という概念を導入してみた結果。」 という記事に出会いました。
記事内では、「多頻度マルチフィードバック」という育成方法論が試されており、「これなら解決できそうじゃん！やるしかない！」と思い、すぐに制度内容を固めて、関係各所に合意形成を取り、事業部横断型「360°ソースコードレビュー」という制度を作りました！（後程、説明します）
そもそも"ソースコードレビュー"とはなんぞや？という方もいらっしゃると思うので、簡単に説明します。
ソースコードレビューとは？
"ソースコードレビュー"とは、誰かが書いたソースコードを他の人が見て、問題のある記法やバグが無いかを確認する作業のことです。"ソースコードレビュー"で見いだされた修正箇所を開発作業者にフィードバックして、ソースコード修正を行います。
何故"ソースコードレビュー"が必要かというと、ソフトウェアの品質を高めて、継続的にサービスを提供していく為です。バグだらけのサービスなんて、誰も使いたくありませんよね笑
事業部横断型「360°ソースコードレビュー」とは
主に新卒エンジニアが 事業部外のエンジニア に対しても、レビュー依頼 を出せるようにしました。
ざっくりですが、
Slackの「360°ソースコードレビュー」というオープンチャンネルで、
レビューして欲しいPull Requestを共有します。
↓
レビュー依頼の投稿に気がついた人（新卒含む）が、レビューをします。
↓
マージされたタイミングで360度レビューくんに
メンションつけてURLを送信 （集計用）
という流れになります。
上記文中に出てくる360度レビューくんですが、弊社エンジニアのテックブログにて現「360°ソースコードレビュー」のプロジェクトリーダーである新卒エンジニアの濱田が解説をしてくれるでしょう。w
↑360度レビューくんです
運用してみた結果
新卒メンバーのモチベーションが高まり、成長のスピードも早くなった気がします。またメンターの負担が軽減され、エンジニア全員で新卒メンバーをフォローするという意識が芽生えた気がします。
- 新卒
・ 色々な角度からのフィードバックが貰える為に、従来と比べて気づきが得られた
・ 誰かしらコメントをくれるので、放置されず、心理的安全性が担保された
・ 事業部外のエンジニアとのコミニケーションが取れた
・ 成長速度が上がった
- メンター
・教育を分担するので、負担が少なかった
・ 他の人のレビューを見るので、自身も学びがある
・メンバーのスキルがアップして、チームの開発スピードが上がった
・メンバー育成が楽しくなった
みんなの声
新卒・メンターから本制度に対するフィードバックを貰ったので、掲載します。諸々の改善点はあるものの、大きな手応えが感じられました。
- 新卒
実際に360°ソースコードレビューを使ってみて感じたことは、「エンジニアリングスキルの向上」と「ソースコードの品質向上」、「エンジニア組織のコミュニケーションの活性化」が出来ていると感じています。
具体的には一つのプルリクエストに対して、各事業部のエンジニアの方々からレビューをしてもらえるため、別の書き方を知ることが出来たり、自分では気づかなかったバグを発見することができます。加えて、1つのレビューから議論が生まれ、事業部を横断したコミュニケーションが出来ているのも良い点だと感じています。
また、レビューを受けるだけでなく自分が他の方々のプルリクエストにレビューをすることで、自分の考えや意見をアウトプットする機会になるのも良い点だと思います。
懸念点としては、修正コストが上がることが考えられますが、マストな修正とベターな修正があるので、僕は自分のタスクの兼ね合いで修正範囲をコントロールすることで対応出来ています。
360°ソースコードレビューの制度で感じた事を率直に表現すると、「緊張する」「高速成長」「関係構築」の3つです。
自分のコードに関する認識が現状マイナス(きちんとかけていないのではないか)なので、レビュー頂く内容がどうしてもより良く改善というよりはダメな部分を指摘して頂いて修正する、という意識がまだ強いのでレビューに出す事に対して緊張します。
ただ、その分成長速度はかなり早いと感じています。先輩方から様々な側面でのレビューを頂けるので、今まで知らない観点からコードを
みられるようになってきます。そのため成長を数多くの場面で実感できるようになってきました。
加えて、先輩方との関係構築が今まで以上に進むようになったと感じます。レビューをきっかけに、他事業部で普段あまり関わりのない先輩と
コードについて議論をしたりする機会が増えました。それを元にそれぞれの先輩の価値観を少しずつでも理解してきたり、
個人的な趣味の話をしたりするようになったので、今まで以上にエンジニアチーム内での関係性ができてきました。
- メンター
自分には無い視点のレビューがあったりするので楽しいです。
計算量とかチューニングの考え方とか、経験によって得られる知識を共有できるのも良いと感じます！
何より、新卒メンバーが楽しんで仕事をするというのが成長出来ると思うので、とても期待してます。
まだ、あまりメリットを感じられていない。もう一工夫で何か良くなりそうな気はしている。
自分含めスケジュールとレビュー依頼の兼ね合いに問題がありそう。
あと、レビューとコミュニケーションはやっぱり違うものなので、注力しない方が良いかも。
あーでもこの間の◯◯に対するPull Requestのとかは自分が見る前に指摘が全部上がってて、助かった！
最後に
チーム全員でメンバーの成長に責任を持ち、互いにサポートし合うチームワークって、最高です。
まだまだ改善点があるので、この新しい制度を文化として根付かせる為に、ブラッシュアップしていきたいと思います。
Hajimariのエンジニア組織はまだまだ発展途上なので、今よりもチームワークを発揮できる強い組織にしていけるように、どんどん挑戦したいと思っております！
今後も社内文化/風土をお伝えできればと思いますので、次回をお楽しみにしてください✌️
