新卒エンジニアが初めて設計に取り組んで学んだこと

背景

新卒エンジニアとして、初めてちゃんとした設計に取り組みました。初めてということもあり、理想の水準よりかなりの時間がかかってしまいました。その経験を振り返る過程で、

そもそも設計って何？どこまで考えれば「設計ができた」と言えるん？

と思って、自分なりに言語化をしたのでそれを記事にしようと思いました

設計の完了条件を、自分なりに言語化してみた

僕は今回の経験を通して、設計を自分なりにこう定義しました。

設計とは、「理想の状態と現状のコードの差分を埋める方法を考えること。」 かなと思います。

また、設計の完了条件としては、「その設計を実装したら理想の状態が実現できることを
他のエンジニアメンバーが理解し、開発可能な状態になっていること」 だと考えました。

では、その「理想の状態」とは何なのか。
僕の中では現時点では以下のように考えました

• 実現したい価値をユーザーに届けられていること
• 今後の事業成長に必要なスピードを落とさず開発を続けられること
  • 具体的には、将来的な機能追加で無駄な工数を生まない構造をつくれている状態だと思っています。

初めての設計で微妙だったポイント

今回の設計では、正直うまくできなかった部分が多かったです。
振り返ってみると、大きく3つの問題がありました。

1. 設計の完了条件の理解がフワッとしたまま進めてしまった

「設計ってこれくらい考えればいいんでしょ？」という曖昧な理解のまま進めてしまったため、
途中で

「この方針で実現できるのか？」

というポイントがレビューでどんどん出てきました。

これはつまり、
“説明可能な状態”まで考え切れていなかった
ということです。

2. 理想を引くための観点が圧倒的に足りなかった

これは初回なので当然というか、経験不足がモロに出た部分です。

• 責務分離
• 継承構造の整理
• イミュータブルな構造になっているか
• エラー処理のハンドリング
• API クライアントの抽象化

など、多くの技術的観点は先輩にレビューをもらって初めて気づいたものでした。
これは経験で身に付く部分も大きく、悲観するべきポイントではないと思っています。

ただ、設計を完了まで持っていって成果をより早く出すためには、観点が足りない中でも先輩に聞きにいって手戻りが起きないようにする工夫も必要だなと思います。また、今回学んだ技術的な観点も次回に活かしていきたいです。

3. 現状コードのキャッチアップを浅く済ませてしまった

ここが今回一番大きな反省ポイントです。

理想と現状の差分を埋めるのが設計なのに、
現状の理解が浅いまま 具体的なHow を考え始めてしまいました。

本来であれば、

• 既存クラスやデータ構造がどんな前提や責務で設計されているのか
• どの処理がどこで呼ばれ、どんな副作用があるのか
• 過去の設計判断がどんな背景でなされたのか
• 既存機能と新規機能の整合性でどんな衝突が起きうるのか

といった “現状の構造を理解しないと出てこない論点” を、
プロダクトコードを表層だけ読んでスルーしてしまっていました。

そもそも設計は理想と現状のギャップを埋める方法を考える作業なのに、現状を理解していなかったらそりゃうまく設計できないなと思いました。

結局、設計内容を他のエンジニアメンバーに説明するためにも、現状を深く理解していないと成立しないです。

今後はもっとコードを具体レベルまで潜って、「現状がこうなっていて、理想の状態するには〜のように開発する必要がある」といった説明が可能な状態を作るために、現状のプロダクトコードの背景や、具体の内容を掴むプロセスを大事にしていきたいです。

また、今後設計する時にキャッチアップがしやすいような設計にするという観点も持ってやっていきたいです。

まとめ

今回の経験を通じて、たくさん学びがありました。今後より良い設計をしていくために今回の学びを生かしていきたいです。

• 設計を他のメンバーが理解できるように説明可能な状態にする。
• 理想を引くための観点を身につけるために日々技術力を磨く
• 現状のプロダクトコードの背景や詳細レベルまでキャッチアップする