※この記事は、2024 Speee Advent Calendar13日目の記事です。 昨日の記事はこちら tech.speee.jp
はじめに
こんにちは、2024年新卒で株式会社Speeeに入社し、現在すまいステップ（すまステ）という、不動産売却マッチングプラットフォームの開発チームでエンジニアをしている渋谷と申します。
今回は、新卒エンジニアとして挑戦・失敗を繰り返す中で、自分がどうやって自身の問題に向き合い、思考・行動を変化させ、成果に繋げてきたかをお話しできればと思います。新卒エンジニアとしてこれから開発に携わっていくが、経験を成果に繋げられるか不安な方にとって、少しでも参考になれば嬉しいです！
日々の開発においてベロシティが上がらずスプリントゴールを達成できないという壁
私は、すまステにジョインしてからの半年間で、RailsのWebpackerを剥がす作業やパフォーマンス改善など、さまざまな開発に取り組んできました。最初は2〜3日程度で完了する小さなプロジェクトを担当していましたが、途中からはチームの同期と協力しながら、1〜2ヶ月かかるような大きなプロジェクトにも挑戦するようになりました。
日々の開発を通じて、プロダクトのアーキテクチャやコードに触れる機会が増え、自分の中に知識が蓄積されている実感はありました。そのため、時間が経てば自然とベロシティ（開発速度）も向上し、スプリントゴールを達成できるようになるだろうと楽観的に捉えていました。
しかし、半年が経過してもベロシティは思うように向上せず、安定もしませんでした。また、週の初めに「この計画なら達成できる」と予想していたものが、気づけば達成できない計画になっていることも少なくありませんでした。この時、自分は「さまざまな開発に挑戦しているはずなのに、成果（スプリントゴールの達成やベロシティの向上・安定）に繋がらない」という壁に直面していることに気づきました。
壁を突破するための問題の理解と、思考・行動の変化
壁に直面した際、まず最初に気づいたのは、他のプロダクトチームで自分と同じように様々な開発に取り組んでいる同期メンバーが、ベロシティを向上・安定させているという事実でした。そこで、自分と同期メンバーとの違いを言語化してみることにしました。
その結果、同期メンバーは自分なりの意見を持っているだけでなく、その意見に対して「どういった背景でその意見に至ったのか」「何が根拠なのか」を明確にしている点が、自分との明確な差分であることに気づきました。この差分を元に、自分の意見に背景や根拠がないことによって日々の開発にどういった影響が及んでいるのかを振り返り言語化してみた結果、スプリントゴールの達成、ベロシティの向上・安定のために改善できることは次のようなことであると分かりました。
- 知識の定着に拘り判断軸を身につけること
- 計画の整合性を高め開発効率を向上させること
解決に向けたアクション
上記を目的として、自分なりの意見に背景や根拠を持たせる機会を意図的に作り出すことにしました。その具体的なアクションとして、以下を実行しました。
月曜日にDraft PRと週の開発計画を作成 担当するすべてのIssueについてDraft PRを作成し、週の開発計画を立てました。このプロセスでは、「なぜこの計画でスプリントゴールを達成できるのか」という背景や根拠を明確にすることを意識しました。Draft PRと開発計画を作成することで、計画の妥当性を検証する機会を自分に課し、より深く広い範囲の知識をキャッチアップする必要性を生み出しました。これにより、計画の精度を高めるだけでなく、知識の定着や応用力の向上にも繋がることを目指しました。
先輩との壁打ち 作成したDraft PRと開発計画を先輩に共有し、壁打ちを行いました。このプロセスでは、自分の意見に不足している観点や計画の不備を指摘してもらい、計画の整合性を高めることを目指しました。壁打ちを通じて、手戻りや追加の開発が発生しにくい計画にブラッシュアップすることができ、結果としてスプリントゴールの達成率向上を期待していました。
意見に背景や根拠を持たせてみた
アクションの実行を通して得られた、開発に対する影響を2つご紹介します。
1. 深く・広い知識のキャッチアップに繋がる
意見に背景や根拠を持たせるためには、その意見を補足するための知識が必要です。例えば、これから実装予定のコードについて背景や根拠を示す場合、実装が既存のコードに与える影響範囲やパフォーマンス面での評価が求められます。そのため、実装予定の範囲だけでなく、より広い範囲のコードを理解し、既存の実装がなぜそのような形になっているのかを読み解く必要があります。
以前は、実装予定の範囲で分からない箇所があれば、先輩に質問し、その回答をそのまま実装に反映するだけでした。この方法では、知識の幅が広がっていく速度が遅く、且つ、新しい知識が点在するだけで、全体的な構造を理解できていませんでした。その結果、応用が効かず、似たような問題に直面すると再び質問が必要になることが多かったのです。
しかし、意見に背景や根拠を持たせるためには、他の実装箇所との関係性を考慮する必要があります。この過程で、知識を単に点在させるのではなく、構造的に理解するようになりました。その結果、応用力が身につき、似たような問題にも自分で対応できるようになりました。
このように、背景や根拠を意識して知識を吸収することを繰り返すことで、プロダクトのアーキテクチャやコード全体への理解が深まりました。そして、少しずつ先輩と同じレベルの視点でコードを捉えられるようになり、自分で実装のイメージを持てるようになったことで、開発効率も向上しました。
2. 計画の整合性を精度高く確認できる
アクションを実行する前は、計画に対して背景や根拠を持たせることができていませんでした。そのため、「週の計画がなぜ達成できるのか？」という問いに対して、感覚的に判断してしまうことが多かったです。この結果、計画上の不確実性を考慮できず、予想外の手戻りや追加実装が発生し、計画が間に合わない事態に陥ることがありました。最終的には、時間的リソースを投下するしかない状況に追い込まれることも少なくありませんでした。
さらに、計画に背景や根拠がないということは、「なぜその開発を行うのか」「何がその開発のゴールなのか」を十分に理解していないことを意味します。つまり、問題の「Why（なぜ）」「What（何を）」を理解せずに、「How（どのように）」だけを考えていたのです。その結果、問題解決に向けた開発をしているつもりでも、最速で解決する方法にはなっていませんでした。
時間の見通しも不確実で、且つ、最速の解決法を模索していないので、計画達成の信憑性が下がるのは当然と言えば当然です。
この状況から脱し、計画に背景や根拠を持たせるために、「その計画がなぜ達成できるのか？」という問いに答え続けることを意識しました。そのために、週ごとの開発計画を先輩に壁打ち（意見交換）する機会を設け、意図的に取り組むようにしたのです。このプロセスでは、例えば以下のような観点を意識しました。
- 既存実装の再利用：再利用できるコードがないかを確認する。
- 影響範囲の最小化：任意引数を追加することで、既存実装への影響を最小限に抑える方法などを検討する。
- テストの簡略化：責務を単一化することで、単体テスト・統合テストの記述を簡単にできないかを考える。
これらのような観点を持つことで、計画に対する判断軸を養うことができました。
判断軸を持つようになると、計画が整合しているかどうかを自分で判断できるようになります。そして、計画が整合していない場合には、適切に他のメンバーに助けを求めることができるようになりました。結果として、計画の整合性を精度高く確認できるようになり、気づけば達成できない計画になっていたという事態を極力避けることが可能となりました。
失敗から得た問題の理解と思考・行動の変化が重要だった
このようなことに日々の振り返りを通して取り組んでいくことで、徐々に開発効率も上がり、ベロシティが向上・安定していき、スプリントゴールを達成できることも増えていきました。しかし、「意見に背景や根拠を持たせる」ということが自分の問題であると最初から理解できていたわけではありません。これまでの約半年間で様々な開発に挑戦し失敗してきた過程で得た気づきや観点が積み重なって、自分の根本的な問題を理解することが可能になったのだと思っています。そして、問題を理解した後に、思考・行動を変化させることまで拘って実行したことも結果が好転した大きな要因だと思っています。
まだまだ他の同期や先輩との差分は多くありますが、変わらず様々な開発に挑戦し、失敗し、その都度問題を理解し、思考・行動を変化させ続ければ、失敗を「良質な失敗」に変化させ、成長し続けることができると感じています。
挑戦や失敗を繰り返しながらも、なかなか成果に繋がらず悩んでいる方が、このブログを通じて問題を深く理解し、思考や行動を変えるきっかけを得られれば嬉しいです。その一歩が、成果を好転させる大きな力になることを願っています。
最後に
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ 新卒の方はこちらより本選考に申し込みが可能です！ キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
