開発の現場では、実装レビューのタイミングで「設計そのものがおかしい」と気づくことがあります。
レビュアーがコードを確認しながら「いや、そもそもこの仕様では動かないよ」と指摘する──そんな場面、あなたも見たことがあるのではないでしょうか。

レビューで問題が明らかになるのは悪いことではありません。ですが、問題はそのタイミングです。設計の不備がレビューまで放置されると、すでに実装が進んでいるため修正コストは大きく膨らみます。スケジュールに余裕がなければ、チーム全体の負担となってしまう💦

本来なら、その違和感に最初に気づけるのは「実装を担当するメンバー」のはずです。

設計を受け取った時点で「この仕様は実際にコードとして成立するのか？」「運用を想定すると矛盾はないか？」と立ち止まれるかどうか。ここにエンジニアの視座の違いが表れます。

「設計に書かれているから、その通りに作る」──それは一見、忠実に仕事をしているようで、実は責任を放棄している姿勢です。設計に疑問を持たない限り、手戻りはいつまでも減らず、レビュアーが最後の砦となり続けてしまうのです。

逆に、実装メンバーが「この仕様は本当に正しいのか？」と考え、必要に応じて設計者に確認できるチームは強い。

レビューは「設計の不備を見抜く場」ではなく、「コードの質を高める場」として本来の役割を果たせます。

レビューで指摘される前に、自ら気づく✨
それは“スキル”ではなく、“スタンス”の問題です💡

気づけるエンジニアは、やがてレビューアーに近い視点を持ち、チームを導く立場に進んでいきます。設計を疑問なくなぞるのか、設計の背景を理解し矛盾に気づけるのか──その差が、キャリアを大きく分けていくのです😊