はじめまして。
株式会社PRUMのmasaです。
今日は現場の開発フロー全体を知り、実装前後の工程の意図を理解してから実装することで何が変わるのかを、エンジニア初心者向けに書いてみました。興味がある方は読んでいただけると嬉しいです。
一つの機能ができるまでには5つのステップがある
プログラミング学習中は「コードを書く＝開発する」というイメージを持ちやすいです。でも実際の現場では、コードを書くのは全体のうちの1工程に過ぎません。
大まかに整理すると、こういう流れになります。
- 企画・仮説検証 ── 「この機能を作れば、ユーザーにとって価値があるか」を確認する。MVP（実用最小限の機能）を素早く作って検証するのが現代の主流です
- 要件定義 ── 「何を作るか」を言語化する。現場では1ページ程度の仕様書でスタートすることもある
- 設計 ── 「どう作るか」を決める。インフラの構成、データの持ち方、クラスやモジュールの分け方など
- 実装・テスト ── コードを書く。同時に自動テストも書いて、壊れていないことを確認できるようにしておくこともある
- コードレビュー ── チームメンバーがコードを読んで、問題がないか確認し合う
未経験で入社した直後は、この5つのうち「実装・テスト」から携わることがほとんどです。企画や設計に関わる機会は、最初のうちは少ないです。でも、だからこそ「上流で何が決まったのか」を知っておくかどうかが、実装の質に直結します。
「なぜこう作るのか」を知ってから実装すると、何かが変わった
現場に入って数ヶ月経ったころ、先輩に言われた一言が今でも残っています。
先輩「タスク着手する前に、この機能の設計ドキュメント読んだ？」
私「あ、まだです。でも内容はチケットに書いてあったので…」
先輩「読んでみて。なんでこの構造にしたか書いてあるから」
その日、設計ドキュメントを読んでから実装に入ったのですが、明らかに違いました。「なぜテーブルがこう分かれているのか」「なぜこのAPIはこういう引数を取るのか」が分かると、実装の判断に迷う場面が減りました。何より「自分が今何のために手を動かしているのか」がクリアになって、開発のおもしろさや、やりがいを感じることにもつながりました。
「なぜそうなっているのか」を知ることは、設計自体に携わることとは別の話です。設計に関わる機会は経験を積んでから増えていきますが、「意図を読む」ことは今日から始められます。
コードレビューは「添削」じゃなく「対話」だった
実装が終わったら、プルリクエストを出してチームメンバーにレビューしてもらいます。最初はこれが正直、怖かったです。
「自分のコードを見られる」というプレッシャーと、「指摘されたらどうしよう」という不安が重なって、プルリクエストを出す前に何度も見直していました。
でも実際にやってみると、印象はかなり違いました。
先輩「ここの処理、別のやり方もあるんだけど、なんでこっちにした？」
私「正直、思いつかなくて…こっちしか浮かばなかったです」
先輩「なるほど、じゃあ一緒に見てみようか」
「間違えたことを指摘される場」じゃなくて、「どう考えて作ったのかを一緒に振り返る場」だったんです。設計の意図を理解して実装に入っているときは、この対話がさらに深くなります。「なぜそう実装したのか」を自分の言葉で説明できるようになるので、レビューが怖い場から学べる場に変わっていきました。
実はこのスタンスを知っているかどうかは、実装中の動き方にも影響します。「あとでなぜそうしたか聞かれる」とわかっていると、「なんとなく」で進めることが減り、先輩に確認するか・自分で調べるかを選ぶ意識が生まれます。
コードレビューは実装が終わってから始まるものではなく、実装中の思考と地続きになっています。コードレビューを意識して実装に取り組むようにしてみましょう。
まとめ
「コードが書けること」と「現場で開発できること」は、少し違います。
現場では、コードを書く前にたくさんのことが決まっています。企画があり、要件があり、設計があります。その流れを知って、「今自分が書いているコードがどこに位置するのか」を理解し、「なぜこのコードを書いたのか」考えながら実装できると、判断に迷う回数が減り、コードレビューで伝えられることも増えていきます。
設計そのものに携わる機会は、経験とともに増えていきます。でも「意図を読んで動く」ことは、今の実力に関係なく取り組めます。
次に実装タスクをもらったとき、着手する前に一度だけ「なぜこの機能が必要なのか」を誰かに確認してみてください。それだけで、書くコードの質が変わると思いますので、ぜひ試してみてくださいね。
株式会社PRUMで運営している記事サイトから知識を補充することもおすすめです。
最近読まれている記事も、興味があれば覗いてみてくださいね👇