※この記事は、2022 Speee Advent Calendar 23日目の記事です。 昨日の記事はこちらからチェック！ tech.speee.jp
はじめに
初めまして、2022年度新卒でSpeeeに入社し、現在Housii（ハウシー）という完全会員制の家探しマッチングプラットフォームの開発チームでエンジニアをしている大金と申します。
今回は、先輩エンジニアと比べ、経験や技術力・経験の乏しい新卒エンジニアである自分が、どうやって同じスピード感で開発を進めていくのかを言語化を通して模索した話をブログとして公開します。
現在新卒で中々自分の開発のスピードが上がらないことに悩んでいる方や、これから新卒エンジニアになる方々にとって少し参考になれば嬉しいです！
大きな開発物の開発においてスプリントがなかなか達成できないという壁
Housiiにjoinして1ヶ月くらいの間、プロダクトのキャッチアップ兼軽めの大きさの開発をしていました。その頃は大きかったとしても4~5日間くらいかけてやる粒度の開発物を担当しており、スプリントで任された開発物を計画通りに進めることができていました。
ちょうど2ヶ月目に差し掛かるタイミングで、想定見積もり2ヶ月相当の開発が自分に任されることになりました。初めは感覚で、「2~3日くらいので終わるタスクの組み合わせやろ、いけるはず」くらいに思っており、かなり楽観的に進んでいきましたが、その雲行きは徐々に怪しくなっていき、苦しい開発(自分の感覚)が続きました。
なぜか終わらない、なぜか時間がかかる、レビューのラリーが止まらず、スプリントから溢れて玉突きのように次スプリントが達成できなくなるという悪循環に陥ってしまいました。
自分と先輩との差分を言語化してみた
なぜ先輩は達成できて、自分は達成できないのか？ 単純に「技術力」や「経験」という言葉に全ての責任を押し付けて思考を放棄するのではなく、その実態を捉えられる形に言語化をしてアクション設定をしていく作業をとことこんやりました。 いくつかでてきましたが、自分にとって重要だったものを2つピックアップします。
1. 開発突入時点でのリリースまでのロードマップの解像度の違い
先輩はビジネス側の要件を実現するために、現状のプロダクトコードに対してどんな変更が必要か？とそれをどのように開発すればプロダクトの品質を担保した上で開発できるのか？を開発方針的にある程度見通せた状態で開発に着手している、という違いにまず気が付きました。
自分は開発に入る前にただissueを分割してこのスプリントでこういったAPIを作る、こういった画面を作る、といったくらいのふわふわした状態で開発に着手することがほとんどでした。
小さめな粒度の開発物ならば、手を動かしながら都度都度考えて実装していく、、、という向き合い方でもなんとかできてしまうことがほとんどですが、開発物が大きければ、単純に間違って設計・コーディングした場合のレビューのラリー数が膨れることになったり、既存のコードへの影響が著しいものも多かったりするので、結果的に無駄なコードを生み出している時間が発生してしまうのです。また、そういったコードをレビュワーに依頼すると、コンテキストが伝わりづらく、レビューする上でも認知負荷の高い状態になってしまい、結果的に技術的負債を生むコードなどを見逃し、プロダクトコードの品質を落としかねません。
先輩方はコーディングに着手する前の段階で、要件を実現するためにどのファイルにどのようなコードを書くのか、という実現していくまでの開発方針のようなものを詳細まで頭の中で描いた上で、開発をスムーズに進めていました。
2. 現状のプロダクトコードへの精通度合いの差
次に、現状のプロダクトコードではどんな技術がどんなコードの書き方で書かれていて、どのような意思決定・背景でそのコードが書かれているのか、どういう構成になっているのかをどれくらい理解しているかということにも差分があることに気がつきました。
例えば、現状のプロダクトコードにおいて、どこでエラーハンドリングを行っているのか、このコンポーネントはどこまでを再利用しているのかといったプロダクトコードの構成に関しての知識や、単純に命名規則のルールといったプロダクト固有のルールを知っているかどうかなどです。
結局自分たちが行っていることは、物理的に言うと、現状のプロダクトコードを理想のプロダクトコードへ変更していくことでしかありません。従って、現状のコードが今どういう状態なのか？を知っていると知らないのではスタートラインが明らかに違うことがわかります。知らない場合は、絶対的にコードリーディングという工程が発生するからです。また、こういった部分への未知がレビューのラリーを膨らますことはいうまでもありません。
言語化した差分を埋めていくプロセスにも工夫を
差分の実態を捉えた上でまずやったことは、差分が知識なのか、それとも今の自分の思考プロセスや行動プロセスを変えることによって埋められるかどうか切り分けを行いました。
例えば、1の差分に関しては、自分の行動プロセスの中に、先輩方から早い段階でFBをもらうということをすることで差分を埋めることができるなと考えました。
デイリースクラムの時間を利用して、これから自分が開発するものに関して、どのファイルにどんな実装をするのかといった内容をできるだけ詳細に共有し、先輩方にフィードバックをいただき、あらかじめ開発着手前に実装をすすめる上で不確実なことをできるだけ解消してからコーディングに入るというやり方で差分を埋めていきました。
今までならば、フィードバックがコードレビューのタイミングにならざるを得なかったので、仮に設計から大きく変更する必要がある場合、コードレビューのラリー回数が大きく膨れて、自分もレビュワーも大きく苦しむという状況が多かったのですが、
これによって、そんな効率の悪い状況をだんだん回避できるようになりました。
2の差分に関しては、単純に知っている/知らないの話であり、知ることさえできれば埋めることが可能ですが、瞬間的にできるものではなく、少しずつコツコツと埋めていくものだと考えました。
まずプロダクトのコア機能や、自分が直近担当する開発回りのコードに関して、コードリーディングする時間を別で確保し、この機能はどんな技術の組み合わせで成り立っているのかを、データの流れに基づいて理解をしていき、その内容をひたすら自分用に記事にまとめました。
加えて、バックログリファインメントやレビューなどの機会を活用して、自分以外の方が担当する実装に関しても、自分ならこうやって書くなといった仮説を先輩方に話してフィードバックをいただいたりすることを繰り返していきました。
上記を繰り返すことによって、プロダクトコード内に関して、自分が知らない箇所のコードが段々と減っていっています。
まとめ
上記を泥臭くやっていくうちに、段々と先輩方と同じスピード感でもスプリントが達成できるようになってきました。また、自分でも大きい開発物を一人で進めていく力も段々とついていき、現在では請求周りの実装といった複雑な箇所も任せていただけるようになりました！
まだまだ先輩方と自分の差は山ほどありますが、なんとなく技術力が足りないから、という理由に逃げて闇雲に知識の勉強をするのではなく、日々の振り返りや課題の言語化を通して、自分のアクションができる形まで咀嚼し、それを着実に埋めていくことで、先輩エンジニアと同水準で開発していくことは充分可能だと感じることができました。
最後に
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
こちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
