※この記事は、2025 Speee Advent Calendar 19日目の記事です。 昨日の記事はこちら
こんにちは、Housii でエンジニアをしている25新卒の田中一城です。
Speee に入社しておよそ9ヶ月が経ちました。 入社から1〜2ヶ月は先輩が設計したイシューを実装し、レビューをもらいながら機能をリリースする日々でした。しかし、3ヶ月目からは先輩や業務委託の方のコードをレビューする側に回りました。最近では、設計にも挑戦し、自分が設計して分割したイシューを他のメンバーが実装、リリースするまで責任を持つという役割も担うようになっています。
この記事では、新卒エンジニアである自分が、コードレビューと設計に取り組む中でぶつかった壁と、それを乗り越えるために実際に取ったアプローチを紹介します。
「Speee のエンジニアはどう開発しているのか？」「新卒でもレビューや設計をやれるようになるのか？」と気になっている方の参考になれば幸いです。
コードレビューでぶつかった3つの壁
冒頭で述べた通り、入社3ヶ月目から先輩や業務委託の方のPRをレビューする立場になりました。 レビューを受ける側からする側に回ったことで、プロダクトの品質に責任を持つ視点でコードと向き合うようになりました。 実際にレビューを始めてみると、3つの壁にぶつかりました。
壁1：PRを読んでも何をコメントすべきかわからない
最初の壁は、PRを読んでも何をしているのかわからないことでした。 ドメイン知識と既存コードの理解が浅く変更差分を追うだけで時間がかかっていました。結果として、差分を追えたとしても何をコメントすればよいかまで判断できませんでした。
さらに、経験のある先輩や業務委託の方が書いたコードに対して、どの観点で意見すべきかがわからず最初は疑問点を質問するコメントしかできませんでした。
乗り越え方：全PRを読み、先輩のコメントと自分の視点を比較した
そこでまず取り組んだのは、その日に出た全てのPRに目を通すことです。 Housii にはレビュー依頼専用の Slack チャンネルがあり、そこで流れてくるPRは自分がレビューアサインされていないものも含めてすぐ読みに行くようにしました。 量をこなす中でドメイン知識と既存コードの理解が進み、読むスピードも上がっていきました。
次に、自分が読んだ後で先輩のレビューコメントを確認しました。 自分が思いついた観点と先輩の指摘を比べることで、どこを見落としていたか、どんな視点を持つべきかが具体的にわかるようになりました。
壁2：指摘が表面的で、意図が相手に伝わらない
PRを多く読むことで少しずつコメントできるようになってきましたが、次は本質的なコメントができないという壁にぶつかりました。 当時の私は先輩のコメントを表面的に真似しているだけで、なぜその指摘が必要なのかを自分の言葉で説明できていませんでした。その結果、次のような問題が起きていました。
- 体裁的な指摘（typo・インデントなど）ばかりになる
- 重要な論点を見逃す
- コメントの意図や背景が伝わらず、ラリーが増える
特に、ジョインしたばかりでHousiiのコードにまだ慣れていない方へのレビューでは、コメントの意図を正しく伝えられず、ラリーが発生して双方がしんどくなる場面もありました。
乗り越え方：なぜその指摘が必要かを言語化し、理想のコードを定義した
そこで、過去に先輩からもらったレビューコメントを振り返り、なぜこの指摘が必要なのか、なぜこの修正が事業や将来の開発に効くのかを言語化しました。わからない部分は、隣の席の2年目の先輩に質問しました。
具体的な指摘をなぜという問いで抽象化することで、レビューで見るべき本質的な観点が少しずつつかめてきました。例えば、次のような観点です。
- パッと見て意図が読み取れるか（認知負荷を上げていないか）
- 将来の変更コストを増やさない構造になっているか
このように具体の指摘を自分の力で抽象化することで、理想のコードとは何かを自分なりに定義できるようになった感覚がありました。その結果、コメントする内容が少しずつ良くなっていきました。
例えば以前は「この部分、メソッドに切り出した方がいいと思います」とだけコメントしていました。今は次のようにコメントしています。
テキスト生成クラスで、メインのメソッドを見たときに①データを取得する、②加工する、③結果を返す、という流れがパッとわかる状態が理想だと思っています。加工する部分の処理が多く、全体の流れがパッと理解しづらくなっていると思うので、メソッドに切り出すとよいと思います。
また以前は「この書き方、統一した方がいいと思います」とだけコメントしていました。今は次のようにコメントしています。
ユーザーの検索条件が変更されたか判定する処理で、他の箇所では値を直接比較しているのに、ここだけテキストに変換してから比較しています。書き方が混在していると後から読んだときにどちらが正しいか迷いますし、新しい処理を追加するときも判断コストがかかるので、統一した方がよいと思います。
このように、「自分はこれが理想だと思います。だからこうした方がよいと思います」というスタンスを取りつつ、意図が伝わるようなコメントができるようになりました。この辺りから、ただレビューをしてコメントをするだけではなく、Housiiのエンジニアとしてプロダクトコードの品質に責任を持つということが少しずつできるようになりました。
壁3：レビューに時間がかかりすぎて開発が遅れる
徐々にプロダクトコードの品質に責任を持てるようになった一方で、1つのPRのレビューに時間をかけすぎるという壁にぶつかりました。 先輩は30分で済ませているのに対して、自分は1〜2時間かかってしまい、担当する開発が遅れてしまう状況です。 レビューでプロダクトの品質を守ることは重要ですが、それによって開発が進まず、目先の価値提供のスピードが落ちては本末転倒です。
乗り越え方：理想のコードを先にイメージし、差分だけを見るようにした
レビュー品質と目先の価値提供のスピードを両立するために、1つのPRのレビューにかける時間を30分にするという理想水準を引きました。その上で時間がかかる要因を分析すると、PRに含まれるファイルをすべて完全に理解しようとしていることに時間をかけすぎているのがボトルネックだとわかりました。 そこで、コードレビューはそもそも何のためにやるのかを整理しました。
自分なりに整理したレビューの目的は、事業を継続的に成長させるために、プロダクトの品質を一定以上に保つことです。 この目的に照らすと、PRのすべてを丁寧に読む必要はないことに気づきました。 先輩のアドバイスを受け、自分ならこのイシューをどう実装するかを先に考え、理想のコードを頭の中で描いてからレビューに入るようにしました。
- 「自分だったらあのファイルのあのクラスを変更するな」
- 「この仕様ならこういうテストケースが必要だな」
このように理想を先に描いておくと、PRとの差分が浮かび上がり、見るべきポイントが明確になります。 その結果コードを読む時間が短縮され、理想水準の時間でレビューできるようになりました。
設計でぶつかった2つの壁
入社半年ほどからは、設計にも取り組むようになりました。Housii では、設計した Epic の内容を設計者だけでなく他のエンジニアも実装します。そのため、設計内容をドキュメントにまとめ、チーム全体で共通理解をつくる必要があります。 Housiiの設計では、以下のような完了条件があります。
### 完了条件 - [ ] 設計ドキュメントの内容がエンジニア全体に共有されていること - [ ] 設計ドキュメントの内容を実装すれば、Epicの要件が実現できる具体的なイメージが湧いていること - [ ] 設計ドキュメントの内容を実装すれば、計測したい項目が計測できるようになっていること - [ ] 想定される追加開発のときに不要な工数がかからないような設計になっていること - [ ] より少ない工数で同等以上の価値のものを実現する方法がないかを考え切れていること
この水準を満たしつつ、他のメンバーが迷わず実装できる状態まで落とし込む必要があります。そうすることで実装着手時の不確実性を潰し、手戻りによってリリース日が大きくビハインドする状況を防ぐことができます。
当時の私は設計とは何かをよく理解しておらず、他のエンジニアメンバーに対して設計内容についての説明責任を果たせない場面が多くありました。
壁1：要件の背景を説明できず、共有で手戻りする
設計を始めた頃は、Epic の背景や実現したいユーザー体験を十分に理解しないまま設計に入り、他のエンジニアメンバーへの共有の場で手戻りが発生するという壁にぶつかりました。 Housii の先輩エンジニアは「より少ない工数で同等以上の価値を実現する方法を選ぶ」ことを大切にしています。そのためにはまず、どんな体験をユーザーに提供したいのかを正しく捉え、他のエンジニアに説明する必要があります。 この前提が欠けていると、技術的には正しく見える設計をしても判断軸が定まらず手戻りが発生します。
乗り越え方：ユーザー体験を自分の言葉で書き出し、判断軸を明確にした
根本原因は要件の背景を理解できていないことでした。そこで、PM が整理したユースケースを踏まえて「今回の施策で満たすべきユーザー体験」を自分の言葉で書き出すところから設計を始めるようにしました。 どんな体験を実現したいかを文章化し、設計の起点に置くことで判断軸が明確になりました。検討すべき論点も自然と整理されていきます。
また先輩の進め方を見て気づいたのは、先輩は常にユーザー体験に近い抽象度の高い論点から順に考え、ひとつずつ潰していることです。一方、自分はイメージしやすいクラス構造やコードレベルの論点から検討を始めていました。コードから考え始めると論点が分散し、設計全体の整合性が保てなくなります。ユーザー体験という理想状態から論点を引くと、議論の順序が整理され、設計の一貫性が保ちやすくなることがわかりました。
壁2：既存コードの理解が浅く、説明責任を果たせない
もう一つの壁は、既存コードの理解が浅く推測で設計してしまっていたことです。 先輩は既存コードの前提条件・処理の流れ・責務の分担まで把握した上で設計しています。一方、自分は「このディレクトリにこの責務のクラスがあるから、たぶんここを触ればいけそう」という表層的な理解にとどまっていました。 そのため「本当にこの設計で実現できるのか」と問われても答えられず、手戻りが発生していました。
乗り越え方：「理想と現状の差分」を言語化できる状態をゴールにした
そこで、既存コードをキャッチアップする上での完了条件を「理想と現状の差分を説明できる状態」と定義しました。「たぶんこうだろう」で済ませず、実際にコードを読み、処理を追い、一次情報を取りに行くことを徹底しました。処理の流れ、前提条件、関連クラスの責務を事実ベースで整理し、ユーザー体験としての理想と現在の構造がどこでずれているかを明確にしました。
このアプローチを通して、設計とは突き詰めると、理想の状態と現状のコードの差分をどう埋めるかを考えることだと理解しました。差分を正しく把握して言語化できると、「なぜこの変更が必要なのか」「既存の仕組みとどう整合を取るか」を説明でき、レビューでの手戻りも大きく減りました。
まとめ：できないことをできるようにするには
ここまで紹介した壁と乗り越え方をまとめると、以下のようになります。
- PRを読んでも何をコメントすべきかわからないという壁 → 先輩のコメントとの差分を比較した
- 指摘が表面的で意図が伝わらないという壁 → 理想のコードとは、を自分なりに言語化した
- レビューに時間がかかりすぎるという壁 → 先に理想のコードを引いて差分だけ見るようにした
- 要件の背景を説明できないという壁 → ユーザー体験を理想の状態として言語化した
- 既存コードの理解が浅いという壁 → 理想と現状のコードの差分を言語化できる状態をゴールにした
このように対象はさまざまですが、どの壁も「まず理想を引く。そして現状との差分を捉える」ことで乗り越えることができました。
理想を引く際には、「何のためにやるのか？」という事業の目的から逆算することが大切だと思います。レビューも設計も、結局は事業のためにやっています。現時点でレビューや設計の目的は、事業を伸ばすために、「直近の価値提供のスピード」と「将来の開発速度を維持するための品質」の両方を実現することだと私は思っています。
この目的から逆算すると、どのくらいの品質で、どのくらいの時間で完了させるべきかという具体的な理想水準を引くことができます。理想水準が引けると現状との差分が明確になり、差分が明確になると「次に何をするべきか」という具体的なアクションを実行可能な状態に落とし込めるようになります。
まだまだできないことがたくさんありますし、乗り越えるべき壁が山ほどあります。これからも先輩との差分、事業から引いた理想との差分を捉えながら、一つずつ壁を越えて、できないことをできるようにしていきたいです。
最後まで読んでいただき、ありがとうございました。
Speeeでは一緒にサービス開発を推進してくれる仲間を募集しています！
新卒の方はこちらより本選考に申し込みが可能です！キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれた方は、こちらをチェックしてみてください！
