今回は実務で開発をする中で「個人開発だけでは学べなかった」と思う実務における開発ノウハウを3つ書きます。個人開発出身でチーム開発の経験が少なく、やっていけるのか不安に感じている方に参考になれば幸いです。

1. 設計段階でレビューを依頼する

実装前に設計・実装方針をチームメンバーにレビューしてもらいましょう。設計段階でレビューをもらうことで、実装後のレビュー時に設計上の問題が発覚するということを防げます。また、設計のレビューをしていた場合、共通認識があるため実装のレビューもスムーズに行えます。

自分は設計段階にレビューをもらうことで、実装の手戻りが発生することがかなり少なくなりました。より良い設計について議論するのはチームメンバーの設計力向上にも繋がるので積極的にやっていきたいところです。

2. プルリクエストの粒度は小さくする

レビューをしたものの、差分が多い故にミスに気づけなかったことはありませんか？自分は過去に巨大プルリクを作成してしまい、ミスに気づけず、問題を起こしてしまったことがあります。レビュー時にもその問題を弾けませんでした。

当時のレビュワーとしては悲鳴を上げる差分の量

この量の差分になると1行1行の変更に問題がないかの確認、テストケースの洗い出し・動作確認のレビューは実質不可能です。（目安は 300 以下）

なので、プルリクエストは小さく保ちましょう。例えば一つの機能を開発する際にロジックの実装、APIの用意とフロントエンドの実装があるとします。

その際は、ロジック (Model や Service)、API (Controller)、フロントエンド (View) の実装をそれぞれで分け、プルリクエストを作成してレビュー、マージをしていくのが堅実です。

3. 実装前に仕様の決定者と認識を合わせる

個人開発の場合、機能のあるべき姿を決める決定者は自分です。しかし仕事でエンジニアとして開発をする場合、機能の仕様を決定する役割を持つのは自分ではありません。大抵はプロダクトマネージャーになります。

コードを書く前には、必ずプロダクトマネージャーと仕様を確実にしましょう。以下は仕様を確認していなかった場合の悲惨な例です。

レビュワー「このケースの場合、Aという挙動になるのですが問題ないですか？」

実装者「問題ないです。A の方が便利だからです（主観）」

レビュワー「それは、〇〇（仕様の決定者）さんに確認とりましたか？」

実装者「確認していないので聞いてみます。」

プロダクトマネージャー「それは B でお願いします。なぜなら〇〇だからです」

実装者「分かりました。B となるよう実装し直します；；」

こうなると再実装、再レビューが必要になってしまいます。僕は個人開発の勢いでこれをやってしまったことがあり、深く反省をしました。組織において仕様の最終決定者はプロダクトマネージャーです。実装前には認識合わせをしましょう。

予め仕様をドキュメントにまとめると良いです。プロダクトマネージャーも忙しいので、仕様をまとめ、非同期でレビューをもらってディスカッションするのが良いでしょう。

最後に

こう振り返ると実務だからこそ学べたことは多いなと感じます。他にもあるのでまた気が向いたら第２弾を書きます。