はじめに
この記事は 食べログアドベントカレンダー2025 の2日目の記事です🎅🎄。
こんにちは。食べログ開発本部に所属している相馬です。新卒で入社してから今年で3年目になります。
今回は、私がエンジニアとして2回経験したブレイクスルーについて書きます。
「ブレイクスルー」と聞くととんでもない成長を想像されるかもしれませんが、ここで書くのは新卒で入社して3年目の私がこれまでできなかったことをできるようになった自分なりの成長の過程です。特別な成果を出したわけではなく、自分自身にとって大きな変化があったという意味でのブレイクスルーです。
この記事では、2回のブレイクスルーを経験した私が、どうやってブレイクスルーできたのか、その過程を振り返って気づいたことをまとめます。自分なりに整理してみると、いくつか共通点があることに気づきました。同じように成長したいと考えているエンジニアの方の参考になればと思います。
要求と要件について
この記事では、「要求」と「要件」という言葉を使います。簡単に説明すると、以下の通りです。
- 要求（Requirement）：ステークホルダーが「何を実現したいか」という要望やニーズ
- 要件（Specification）：要求を実現するために「何を満たす必要があるのか」を定義した仕様
例えば、「ユーザーがログインできるようにしたい」というのが要求で、「IDとパスワードで認証する」というのが要件です。要求を正確に理解し、適切な要件に落とし込むことが重要です。
コードを書く前に、勝負は決まっている
入社したての頃、私は要件をもらったらすぐに実装に取り掛かっていました。チームメンバーから受けた依頼を基に、要件通りに実装することを中心に取り組んでいました。
しかし、2回のブレイクスルーを経験する中で、実装前に準備することの重要性に気づきました。現在は要求を噛み砕いて要件を定義し、変更に強いコードを実装できるように設計します。もろもろの準備が整って初めて実装へ着手するようになりました。実装前に準備する段階（要求の明確化、設計）を充実させることで、最終的な成果物の質を向上させることができるようになったと実感しています。
1回目のブレイクスルー：設計で道筋を立てる
スピード重視で、設計は後回し
基本的に画面を一から作るというわけではなく、既存の機能の改修を主に実施していました。徐々に業務内容や仕事のやり方を学び、システムのことも細かい改修を通じて理解を深めていきました。
同じチームのメンバーがまとめてくださった要件を確認し、他の実装を真似しながらコードを書くような改修を続けていました。自分としても成果物としてどんどん作業をこなしたいという思いがあり、早くコードを提出することに注力していました。
コードレビューで指摘があったことはメモに書き留めて次に活かすようにしていましたが、毎回コードを書くときに指摘されたことを思い出して修正するような状態で、まだ体系的な改善には至っていませんでした。
レビューで見えた設計の重要性
あるときに、画面やバッチ、APIをそれぞれ一から作るプロジェクトに関わらせていただくことになりました。これまで既存機能の改修が中心だった私にとって、一から作るプロジェクトは大きなチャレンジでした。
「よし、動くものができた！」と自信を持ってレビューを依頼したところ、たくさんの指摘を受けました。特に印象的だったのは、レビューで「もし画面の仕様変更があった場合、今の実装では対応できない構造になっている」と指摘されたことです。例えば、画面遷移の順番が変わった場合、修正箇所が広範囲にわたっており、修正漏れが発生しやすい設計になっていました。
この経験を通じて、私は設計の重要性を理解できていなかったことに気づきました。コードを書くことだけに集中していた結果、1つのクラスやメソッドに複数の責務が混在し、処理が肥大化したコントローラーや、様々な箇所で同じ処理が散在するような硬直したコードを作ってしまっていたのです。コードで実装するだけでは不十分だと気づき、設計の重要性を学ぶ大きなきっかけとなりました。
上長からは、設計の重要性について「メソッドやクラスは過剰な責務を持つべきでない。メソッドやクラスが適切に責務を持っているコードはファットになりえないし、柔軟な変更にも対応しやすい」というアドバイスを受けました。そして、実際にチームメンバーが設計し直して修正してくれたコードを見せてもらえたことで、処理が簡潔になったメソッドや適切に役割分担されたクラス構造など、仕様変更にも対応しやすく見やすく整ったコードの構造を学ぶことができました。
このアドバイスと良いコード例を参考に、自分でも設計を意識するようになりました。手元に簡単なイメージ図を書いてみたり、構造を明確にした資料を作ってみたりと、自分なりに実践してみました。
チームメンバーがコードを修正してくれたあとに、実際に仕様変更があり、その仕様変更を私が担当することになりました。例えば、「入力 -> 認証 -> 確認 -> 登録 -> 完了」という画面遷移を「入力 -> 確認 -> 認証 -> 登録 -> 完了」に変更するという内容でした。各ファイルやメソッドの役割が明確だったため、数個のメソッドを移動するだけで対応でき、ものの数分で完了しました。この経験を通じて、設計がしっかりしていることで仕様変更がスムーズにできることを実感し、設計の重要性をより深く理解できました。これが、私にとって大きな成功体験となりました。
設計を意識し、繰り返し実践
上長からのアドバイスを受け、設計の重要性に気づきました。実装を円滑に、かつ今後の運用も考えた道筋を立てること、そして今後運用するコードとして構造がはっきりしていて管理しやすいものを作成することが重要だと理解しました。
自分の中で、設計を意識できていなかったことだと認識しました。以前は似たような実装をしている箇所を参考にしながら、そのコードに合わせたような作りをしていました。自分の設計意図を明確に持てていなかったため、レビューで「どうしてこうした作りにしたのか」という問いに対して、「似たようなコードを参考にしたから」としか答えられない状態でした。
そこで、どういう意図で設計をしたのかを説明でき、その意図を設計へ反映できるようになることを意識して実施しようと考えました。この意識が、自分ができたかどうかを判断する基準となりました。目指すべき方向性がはっきりし、重点的に実践しようと考えました。
手元に簡単なイメージ図を書いてみたり、構造を明確にした資料を作ってみたりと、自分なりに設計を意識してみました。「これは〇〇するためだけのメソッド/クラス」のように意識して設計を考えるようにし、メソッドやクラスの役割や汎用的な作りにできるか、どこまで修正の影響があるのかを考慮するようになりました。
これを繰り返し意識して設計してみたことで、この部分はもっと役割を分けるべきだ、この実装は分けられていないなどの切り分けがスムーズにできるようになってきました。また、画面遷移の順番が変わったときなど、この設計だと修正が大変になりそうといったことにも気がつけるようになりました。この繰り返しの実践がブレイクスルーに繋がり、メソッドやクラスの役割を意識して設計できるようになり、仕様変更に対応できる柔軟なコードを作れるようになりました。
設計の意図を説明し、コードに込める
こうした経験を得て半年ほど設計に注力してきました。意識して取り組んだ結果、どういう意図で設計をしたのかを説明でき、その意図を設計へ反映できるようになったことを実感できるようになりました。
どうしてそう実装したのかを明確に答えることができ、コードにもそれが現れるようになってきました。まだ細かいコーディングのところで指摘を受けることはありますが、以前よりも明確な意思をもって設計と実装へ取り組めるようになりました。この変化により、自分の中で成長できていると感じています。
2回目のブレイクスルー：要求を明確にする
要求の背景を見落としていた
設計の重要性に気がついてからは、実装の依頼があれば設計してコードを書く作業を繰り返していました。設計の質が成果物全体に大きく影響することを実感し、設計に重きを置き始めていました。
しかし、設計の前段階である要求の明確化にはまだ視点が向いていませんでした。要求をそのまま受け取って設計に進んでしまい、要求の背景やどのような業務で必要とされることなのかを確認しないまま進めていました。要求が絶対に正しいもので、依頼者が本当にやりたいことを表しているということを前提とした取り組み方でした。
設計修正の頻発から見えた要求の把握不足
ある依頼で何度も設計を修正する必要がありました。もちろん自分の設計をレビューしてもらい修正があったのは確かなのですが、何度も修正する原因となっていたのは設計の内容だけでなく、要求で何を実現したいかを把握できていなかったことです。
要求に対してクラスやメソッドの構造や責務に重点を置いて設計を進めていました。しかし、設計段階では「この画面に機能を追加すれば対応可能か」「既存の機能で要件を満たせるのではないか」といった方針の迷いや、処理後の運用フローが不明確な点が後から明らかになりました。結果として設計の見直しややり直しが頻発する事態となりました。
これはそもそも「この依頼をした人は何をしたいのか」という、設計以前の要求をまとめきれていなかったことが根本的な原因でした。私は要求をそのまま作ろうとして設計を進めていましたが、その要求が本当に依頼者が実現したい内容だったのかを精査しないまま設計へ進んでしまっていたのです。
「こうした機能が欲しい」「これをできるようにしたい」といった要求があります。その根底には何かしらの意図があります。もしかしたら要求の中にはその根底にある意図が省略されていて、ただ「こうしたい」という要求だけしかない時もあります。しかし、その機能が欲しいと言っている依頼者が必ずしもベストな機能を要求しているとは限りません。
この経験を通じて、まずは要求の背景やどのような業務で必要とされることなのかを細かくヒアリングして相手の要求を正確に引き出すことの重要性に気がつきました。
不明点を洗い出し、本質を引き出す
細かくヒアリングを続けてすり合わせていくことで、以前よりも後から修正が発生するケースは少なくなりました。ただ、まだ適切な手段を提案するためにもっとできることはないかと試行錯誤を続けていました。
その中で、不明点を洗い出し、それをもとに要求に対して的確な質問ができるようになることを意識して取り組むことにしました。
また、要求に書いてあった内容をシンプルにまとめることができるようになることも、意識して取り組むべきこととして考えました。この意識が、自分ができたかどうかを判断する基準となりました。目指すべき方向性がはっきりし、より適切な手段を提案するための方法を模索し続けました。
あるとき、文章に特定の内容が含まれているかどうかを判別して、判別内容によって処理を分けるという要求があったときに道が開けました。要求者からは「判定をAIにさせて、その結果をもとに処理を実行する」という手段が提案されました。
一旦持ち帰り、チーム内で要求を確認したとき、上長から「要求から懸念点/不明点を洗い出して資料にまとめるといい」というアドバイスを受けました。自分が思いつく懸念点や不明点を書き出し、AIが考える懸念点/不明点も加えていきました。
最初はどんなふうにまとめていいかわからなかったのですが、AIに修正要求の資料やチーム内のレビューをまとめたテキストを渡すことで、どのような点についてまとめるのかの叩き台を作ってもらいました。AIに叩き台を作ってもらえたことで、その叩き台から自分なりにまとめることができるようになりました。
洗い出してみると、相当な数の懸念点/不明点が出てきました。チームメンバーから「懸念点/不明点が多い要求というのは実現が難しいか、そもそもやることを間違っている可能性が高いよね」と言われました。確かに、懸念点が多いものは実現が困難なことが多かったです。また、不明点が多いものは要求者のやりたいことが定まっていないことが多かったです。
チーム内での相談の結果、AIによる判別についてはもっと簡単な方法がないか要求者とも相談して見直すことになりました。その後、要求者から「AIによる解析でなくても、ある単語が含まれていれば判定できる」ということになり、単純な文字列の部分一致で対応することになりました。この結果、実装の複雑さが大幅に減り、よりシンプルで保守しやすい実装になりました。
この経験を通じて、要求を明確化して、それにあったアプローチや不明点、懸念点の洗い出しを行うことの重要性を実感しました。懸念点/不明点を洗い出すことで、要求の本質的な問題点が見えてきて、より適切な解決策を見つけられるようになったのです。これが2回目のブレイクスルーに繋がり、要求の本質的な問題点を見つけ、懸念点/不明点を洗い出して、より適切な解決策を見つけられるようになりました。この変化により、より効率的に要件を把握し、適切な解決策を提案できるようになったことを実感しています。
不明点を洗い出し、質問で本質を引き出す
意識して取り組んだ結果、不明点の洗い出しができて、洗い出した不明点から要求へ対して的確な質問ができるようになったことを実感できるようになりました。また、要求に書いてあった内容をシンプルにまとめることができるようになったことも、達成できた指標の1つです。
以前は手当たり次第に確認をしていましたが、今は「こうした懸念が発生している」「やりたいことと反していないか」「資料に書いてある要求が違う可能性がある」といった道筋で考えられるようになりました。的確な確認が取れるようになりました。また、要求に書いてあった内容をシンプルにまとめることができるようになったことで、相手の要求を明確化できる力がついたと感じます。
2回のブレイクスルーから見えてきたこと
2回のブレイクスルーを経験した私が、改めて振り返ってみると、いくつか共通点があることに気がつきました。これらを意識することで、自分なりのブレイクスルーを実現できたのではないかと思います。
1. 参考例や良い実践例から学ぶ
参考例や良い実践例を見ることで、目指すべき方向性が明確になり、その方向性から結果へ繋げることができるのです。正解がない問題でも、良い実践例や参考例から学ぶことで、自分なりのアプローチを見つけることができます。
1回目のブレイクスルーでは、チームメンバーが具体的な実装を示してくれました。見やすく整ったコードを見ることで、「こういう設計をすればいいのか」という方向性が明確になりました。2回目では、AIが懸念点/不明点の洗い出し方の例を示してくれました。AIに叩き台を作ってもらうことで、どのような点についてまとめればいいのかがわかりました。
参考例や良い実践例を見る機会があれば、積極的に学び、それを自分の状況に適用していく姿勢が大切です。正解がない問題でも、参考例から学んだパターンや考え方を応用することで、自分なりの解決策を見つけることができます。
2. アドバイスを素直に受け入れて、愚直に実践してみる
アドバイスを素直に受け入れて、愚直に実践してみる姿勢が、ブレイクスルーに繋がりました。
1回目は、上長から設計の重要性についてアドバイスを受け、クラスやメソッドの構造を手元に書いてみるといったことを愚直に繰り返してみました。2回目は、上長から「要求から懸念点/不明点を洗い出して資料にまとめてみて」というアドバイスを受け、懸念点の洗い出しなどを愚直に実践してみたことから始まりました。
最初は「なぜこれをやる必要があるのか」がわからなくても、とりあえず試してみることで、後からその意味が理解できるようになります。繰り返し実践していく中で、自分なりの判断基準や答えが見えてくるようになりました。
3. 成功体験を積み重ねる
成功体験を通じて、今後に活かせると思い続けることができたのです。
1回目は、設計によって修正が軽微になったことです。チームメンバーがコードを改修した後に仕様変更があり、数個のメソッドを移動するだけで対応できた経験が、大きな成功体験となりました。2回目は、要求の見直しでハードルの高かった当初の解決手法（AIによる解析）が簡易的な方法（文字列の部分一致）に変更できたことです。この成功体験が、今後の取り組みに活かせると思い続ける原動力になりました。
小さな成功体験を積み重ねていくことで、自分なりの成長の指標が見えてきます。
なお、私がこの成功体験を経験できたのは、周りのサポートが手厚かったことも大きな要因だと思います。設計の手本を見せてくれたり、懸念点の洗い出しなどを指示してくださったチームメンバーのサポートがあってこそ、ブレイクスルーを実現できました。
この場を借りて、チームメンバーの方々に感謝の気持ちをお伝えしたいと思います。
また、設計に注力できたり、懸念点の洗い出しが素早くできたのは、AIによるサポートも大きかったと感じています。やり方がわからなかった私にとって、AIが先にある程度の土台を作ってくれることで、最初の一歩を踏み出せたのは大きな助けでした。
現在の状況と今後の目標
2回のブレイクスルーを経て、現在は設計よりも前の要求というところに着目して取り組めるようになりました。実装前に準備する段階（要求の明確化、設計）を充実させることで、最終的な成果物の質を向上させることができるようになったと実感しています。
自分なりの成長の指標としては、以下の3つがあります。
- 設計：自分の意思を反映できている – どういう意図で設計をしたのかを説明でき、その意図を設計へ反映できたとき
- 要求：的確な質問ができる – 不明点の洗い出しができて、洗い出した不明点から要求へ対して的確な質問ができるようになったとき
- 要求：シンプルにまとめられる – 要求に書いてあった内容をシンプルにまとめることができるようになり、相手の要求を明確化できる力がついたと感じるとき
今後は、各フローの質を深めたり効率化したり、より大きな要求に対応できるよう進めていきたいと考えています。また、AIを業務ツールとして活用し、設計や課題検討の質を高めていきたいです。
まとめ
今回は、私がエンジニアとして2回のブレイクスルーを経験した過程を振り返り、気づいたことをまとめました。
1回目のブレイクスルーでは、設計で道筋を立てられるようになったことで、メソッドやクラスの役割を意識して設計できるようになり、仕様変更に対応できる柔軟なコードを作れるようになりました。
2回目のブレイクスルーでは、要求のやりたいことを明確化できるようになったことで、要求の本質的な問題点を見つけ、懸念点/不明点を洗い出してより適切な解決策を見つけられるようになりました。ハードルの高い解決手法を簡易的な方法へ変更できるようになったことも、大きな成果の1つです。
この2回のブレイクスルーから見えてきた共通点は以下の通りです。
- 参考例や良い実践例から学ぶ – 自分が目指すべき方向性を明確にする
- アドバイスを素直に受け入れて、愚直に実践してみる – アドバイスを愚直に実践する姿勢
- 成功体験を積み重ねる – 小さな成功体験を原動力にする
特に、AIを業務ツールとして活用して参考例や叩き台を作ってもらったりすることで、作業効率が大幅に上がりました。
同じように成長したいと考えているエンジニアの方には、この3つの共通点を意識して実践してみていただければと思います。まずはアドバイスを素直に受け入れて、愚直に実践してみることから始めてみてください。小さな成功体験を積み重ねていくことで、自分なりのブレイクスルーを実現できるかもしれません。
明日は @redpine の『「要件が決まらない」と嘆くのをやめて、企画と一緒に「業務」を作りに行こう』です。お楽しみに!
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
