【現場のリアル】未経験エンジニアが初めて経験したレビューの話

エンジニア現場に入って感じた「レビュー」という壁

レビューって何をするの？最初は全然イメージできなかった

未経験からエンジニアとして現場に入ると、

「レビュー」という言葉を頻繁に耳にします。

コードレビュー、設計レビュー、テストレビュー、スプリントレビュー。

正直なところ、参画当初の筆者はこう思っていました。

• 何を見られるんだろう
• 間違っていたら怒られるのかな
• そもそも自分が説明して大丈夫なのか

特に未経験の場合、「自分の理解が浅い状態で人前に出る」

という状況そのものがかなりハードルになります。

レビュー＝怖いもの

というイメージを持つ人も多いと思いますが、現場では必ずしもそうではありません。

この案件で経験したレビューは、「詰める場」ではなく「認識を揃える場」

という印象が強いものでした。
実際、筆者が経験したレビューはどの会も終始和やかでした！😊

はじめてのレビュー前の正直な気持ち

はじめてレビューに出る前日は、正直かなり緊張していました。
手汗が止まらなかったです（苦笑）

• 質問されたら答えられるだろうか
• そもそも理解がズレていたらどうしよう

未経験からエンジニアになると、

「分かったつもり」で進んでいる部分がどうしても出てきます。

レビューは、その“つもり”が一気に表に出る場でもあります。

今回参画した案件とチーム構成のリアル

マイグレーション案件ならではの役割分担

今回参画したのは、

現行システムから新環境へのマイグレーション案件でした。

この案件では、チームが大きく2つに分かれていました。

筆者は、開発チーム側として参画していました。

分析チームが「現行ではどう動いているか」

を細かく整理してくれます。

その資料をもとに、開発チームが「新環境でも同じ動きを再現する」

ことがミッションです。

分析チームと開発チームの関係性

ここで重要なのが、

分析チームと開発チームは対立関係ではないという点です。

• 分析チーム：仕様を明確にする役割
• 開発チーム：仕様を形にする役割

どちらかが偉い、という関係ではありません。

だからこそレビューでは、

• 仕様の抜け漏れがないか
• 認識にズレがないか

を一緒に確認するという空気感がありました。

テストレビューで実際に使っていた資料と準備内容

レビューで使った成果物一覧

今回のテストレビューで使用していた主な資料はこちらです。

• サービス仕様書（I/Oと、そのサービスで行われる処理の概要を記載しています）
• 単体テスト仕様書
• DT（デシジョンテーブル）
• プロセスフロー図
• 必要に応じてクラス図

ローコード開発だったため、DTが実質的なソースコード代わりでした。

「コードを見せて説明」ではなく、設計資料を使って処理を説明する

というスタイルです。

資料を「説明できる状態」にする難しさ

資料を作るだけなら、正直なんとかなります。

でもレビューで求められるのは、

• なぜこの設計になっているのか
• このテストで何を担保しているのか

を言葉で説明できることです。ここが一番大変でした。

• 書いてあることは分かる
• でも、質問されると詰まる

という場面も最初は多かったです。

ここまで読んで、
「人に説明できるレベルまで理解するのって大変そう…」
と感じた方もいるかもしれません。

実際、現場では　“動くコードが書ける”　だけでは足りず、
「なぜそう動くのか」を言葉で説明できるかが問われます。

こうした力は、頭で読むだけでなく、実際に手を動かしながら
理解を積み上げていくことで身についていきます。

実際のレビューで交わされたやりとりと空気感

分析チームからよく聞かれた質問

実際のレビューでは、こんな質問がありました。

Q：この観点のテストは、どのテストケースで実施していますか？

→ テスト仕様書を示しつつ、

　どんなデータで検証したかを説明します。

　もし漏れていれば、指摘事項として持ち帰ります。

Q：この機能は、このサービスには無いようですが別で行う設計でしたっけ？

→ 後続の別マイクロサービスで実現しています、と説明。

詰められる、というより

事実確認と認識合わせに近い印象でした。

開発チームから確認したポイント

逆に、開発チーム側から質問することもあります。

Q：分析資料に条件が無かったので実装していませんが、問題ありませんか？

→ 問題ない場合もあれば、分析チームが持ち帰るケースも。

Q：前段サービスで条件が絞られるため、このテストケースは実施不可です…。

→ 別フェーズでのテスト依頼になることも。

レビューは一方通行ではなく、双方向の会話で進んでいきます。

もし今、

・エンジニアを目指して勉強中だけど、実務のイメージが湧かない
・コードは読めるようになってきたが、人に説明する自信がない
・環境構築でつまずいて、学習が止まりがち

と感じているなら、
ブラウザ上で学べる学習コンテンツ
「ZeroCodePlus」を一度触ってみるのも一つの手です。

ZeroCodePlusは、Progateのように
インストールや環境構築が不要で、
画面の指示に従いながらコードを書いていく学習スタイル。

実際に手を動かしながら、
「この処理はなぜ必要なのか」
「どんな入力でどう動くのか」
を確認できるため、
レビューで説明が求められる場面の事前練習にもなります。

現場に出てから焦らないための“準備運動”として、
こうしたブラウザ完結型の学習環境は相性が良いと感じました。

▶ ZeroCodePlusでJava学習をブラウザから始めてみる

レビューで得られた一番大きな学び

人に説明して初めて分かる理解不足

• 担当マイクロサービスの説明
• I/Oや処理内容の言語化
• テスト観点の説明
• フィードバックを受ける

この流れの中で、自分の理解不足がはっきり見える瞬間が何度もありました。

でもそれは悪いことではありません。

• 理解が浅い箇所に気づける
• その場で修正できる

という、成長に直結する体験でした。

緊張と成長がセットでやってくる現場

人前で話すのは、やっぱり緊張します。

しかも、

• 設計
• 開発
• テスト

を並行しながら、レビュー準備もしなければいけません。

最初は時間配分も難しく、正直しんどいと感じることもありました。

それでも、

• 説明できるレベルまで理解する
• フィードバックを受けて改善する

この繰り返しが、エンジニアとしての土台を作ってくれたと感じています。

未経験からでも、現場でレビューに参加し、
少しずつ理解を深めていくことはできます。

ただ、「レビューで話せるレベルの理解」を作るには、
事前にどれだけ“自分で動かしたか”が大きく影響します。

読む → 書く → 動かす
このサイクルを回しやすい環境として、完全無料の
ZeroCodePlusを学習の入口に使ってみるのもおすすめです！