こんにちは。新卒1年目エンジニアのyokochiです。
この記事では、研修期間中に経験した「調査・設計の前に開発をしてしまった」というしくじりについて書かせていただきます。この経験が誰かの参考になれば幸いです。
目次
- しくじり概要
- 経緯
- 結果
- 学んだこと
- まとめ
しくじり概要
私のしくじりは「調査・設計の前に開発をしてしまった」ことです。
研修中は以下のようなフローで案件をリリースまで進めることが求められていました
- 案件オリエンテーション
- 調査（影響範囲調査）
- 設計
- 設計レビュー
- 開発
- コードレビュー
- （省略）
- リリース
案件オリエンテーションでディレクターから仕様を聞き、エンジニアがコード上で現在の仕様を調査し、改修内容に基づいて開発計画を設計書にまとめます。その後、先輩エンジニアによる設計レビューを経て開発に進みます。
このフローを理解していながら、私は開発を先行してしまいました。結果として、予定していたスケジュールから遅れ、苦労することになり、先輩の手を煩わせることにもなりました。
経緯
開発を先行した理由は以下の通りです
- 調査・設計の意義を感じる機会が少なかったこと
- 設計レビューに完璧な設計書を出したかったこと
調査・設計の意義を感じる機会が少なかったこと
以前の案件では、開発経験のある分野や影響範囲が小さい案件を担当していたため、調査・設計にあまり時間をかけずに開発を進めていました。正直なところ、「どうせコードを書けば分かることだ」という傲慢な考えを持っており、調査・設計の重要性を軽視してしまっていたのです。今思えば、とても危険な考え方でした。
設計レビューに完璧な設計書を出したかったこと
私は、細部まで記載された完璧な設計書を作成することが、レビュワーにとってもその後の開発にとっても最良だと考えていました。「完璧な設計書さえあれば、スムーズに開発できるはずだ」という思い込みもあり、細部まで詳細に記載された理想の設計書を作ろうと必死でした。結果的に、本来の目的を見失ってしまったのです。
結果
この行動による影響は以下の通りです
- 設計が終わらず、当初のレビュー日程を延期
- 開発もうまくいかず、調査・設計も疎かに
設計が終わらず、当初のレビュー日程を延期
開発に注力していたため、影響範囲調査などを後回しにしていました。また、未経験の技術の学習に時間がかかり、進捗が思うように出ませんでした。結果、レビュー日程の延期を余儀なくされました。
開発もうまくいかず、調査・設計も疎かに
開発と並行して設計書を作成しようとしたため、開発が進まなければ設計書も完成しないという状況に陥りました。最終的に、開発を中断して調査・設計に集中せざるを得なくなりました。
学んだこと
この経験を踏まえ、これから案件に携わる時の心得は以下です。
- 調査・設計 → 開発
- 設計レビューは議論の場である
- コードの改修についてはコードレビューで議論
調査・設計 → 開発
このフローを軽視したことを深く反省しています。調査・設計の段階で十分な時間を取ることで、開発時の混乱や手戻りを大幅に減らせることを身をもって学びました。「急がば回れ」というのは、まさにこのことだったのだと痛感しています。
設計レビューは議論の場である
設計レビューの本質は、チームで知恵を出し合い、より良い設計を作り上げることだと理解しました。完璧を追求するあまり、議論の機会を失うことは本末転倒です。今では、疑問点や懸念事項を率直に共有し、先輩方の知見を積極的に採り入れることの重要性を強く感じています。
コードの改修についてはコードレビューで議論
設計書に凝りすぎて、本来のコードレビューの役割を奪ってしまっていたことに気づきました。設計書は全体の構造や流れを示すものであり、細かなコードの実装はコードレビューで議論すべきだったのです。この区別を理解できていなかった自分の未熟さを痛感しています。
まとめ
この経験は、新人エンジニアとしての私に大きな気づきをもたらしました。プロセスの重要性、チームワークの大切さ、そして自分の未熟さを謙虚に受け止める必要性を学びました。今後は、この教訓を胸に刻み、より慎重かつ効率的に業務に取り組んでいきたいと思います。失敗を恐れずに、常に学び続ける姿勢を大切にしていきます。
