どんな開発現場でもコードレビューは重要です。今の時代だとGithubのプルリクエストなどをベースとしたコードレビューは、開発の現場ではもはや必須ともいえる制度です。
ただ私はスタートアップでの立ち上げ期を経て、新規開発立ち上げ期においてはコードレビューの役割を変えたほうがいいということを感じました。この記事ではコードレビューの役割について考えてみます。
平常時におけるコードレビューの役割
まずは平常時におけるコードレビューの役割を見ていきましょう。
1. ダブルチェックになるのでバグが発見できる可能性がある
バグがリリースされる可能性を減らす役割です。
2. 技術的負債になりうるコードを発見でき、品質向上につながる
1人でコードを書いているとどうしても視野が狭くなってしまい、メンテナンス性が低い設計・実装になってしまいがちですが、他の人の客観的な目線から改善点を教えてもらえるメリットがあります。
3. 属人性を減らせる
理想は『ソースコードがドキュメントになる』（＝ソースコードを読めば背景意図がわかる）ことですが、現実的にはコードを見ただけで完璧に背景意図がわかることはそうそう無いです。コードを書いた人以外もそのコードの背景を知っていることで属人性を減らすことができます。
4. 議論を行うことでレビュアー・レビュイーともに技術的な成長ができる
議論を行うことで気づきを得られたりナレッジの共有ができます。指摘を受けたレビュアーはもちろん、レビュイーも自身の考えを言語化する過程で様々な学びが得られます。そのため両者ともにレビューを通じてスキルを向上させることができます。
==================
以上が平常時におけるコードレビューの役割です。これが新規開発立ち上げ期だとどう変わるのか見ていきます。
新規開発の立ち上げ期だと何が違うのか？
新規開発の立ち上げ期ではやるべきことが膨大にあり、とにかく人も時間も足りません。
何かをレビューしてもらうということは、その何かに依存する他のタスクが前に進められなくなるということを指します。
特に新規開発の立ち上げ期では多くのタスクが絡み合う形で存在しており、またそれらを器用に分割してレビュー依頼して…としているプロジェクトマネジメントにかける労力や、その間依存タスクが進められなくなる時間が非常にもったいないです。
そのため新規開発の立ち上げ期では「できるだけ大きなバッチサイズで、個々人がまるっとタスクを担当する」のが基本になります。
そういうスタイルで進めると属人性が非常に高まるのですが、新規開発の立ち上げ期では属人性はむしろ歓迎すべきことです。属人性が高い特に1人がオーナーシップを強く持っている状態だと合意形成が不要になるので、例えば設計変更などの意思決定のスピードが桁違いに上がり、また仕様や実装が全て頭に入っているのでコードの修正も一瞬で終わります。
（このあたりの話は「10xのパフォーマンスの出し方」というテーマで以下記事でも書いています）
※ 余談ですが、あのソラコムさんもスタート時にはコンポーネント分割し属人的に進めていたことを後で知りました。（ソース記事）
またプロダクトがPMFする前頃から開発組織が急拡大するというのも、新規開発立ち上げ期の大きな特徴です。例えば最初に開発者が1~3名ぐらいでスタートしそれが4~6名ぐらいになるだけで、倍率的には組織規模は2倍・3倍になっています。また大企業の新規事業ではなくスタートアップだった場合、別会社にいる人を中途採用で採用することになるため、組織規模の拡大だけでなく文化の違いも大きな問題となります。
まとめると新規開発立ち上げ期の特徴としては以下のとおりです。
- とにかく人も時間もないので、レビューそのものの時間やレビュー待ちにより依存タスクが止まる時間がもったいない
- 属人性はむしろ歓迎すべきこと
- 途中で急拡大するタイミングがあり、組織規模や文化にまつわる問題が起きる
こういった状況でコードレビューは平常時とは違い、どういった役割として行うべきでしょうか？
レビューを通じて判断基準・文化をすり合わせる
前述のとおり新規開発立ち上げ期では、個人個人が裁量を持って一人で大きな範囲を属人的に開発することが多くなります。しかし本当にバラバラに開発していたら、最終的に整合性が取れていないメチャクチャなシステムができてしまいます。そのため皆である程度認識をすり合わせておく必要があります。
認識をすり合わせるべき点は「どういうアーキテクチャで、個々人が作っているモジュール同士がどう連動するのか」という大きなレベルは当然必要ですが、「変数名はどういったものが好ましいのか」「パッケージ分割やディレクトリ構造の考え方」「ソースコードのファイル分割の粒度」といった小さなレベルのものについても是非すり合わせておきたいところです。そういった小さなレベルの認識が統一されていると、他のコードを見たときに全く引っかかりなくスムーズにコードを読むことができ、本質的なロジックを読むとに集中できるからです。
そういった観点で、プルリクレビューを文化・判断基準のすり合わせのために使うのが個人的なオススメです。
例えば実際に私が行っているスタイルとしては、新しくチームに入ったばかりのエンジニアのコードはとにかく時間をかけて隅から隅まで詳細にレビューします。そのレビューでは、システムの挙動には関係がないようなコードの書き方のスタイルレベルのことについても詳細にコメントします。もちろんコードの書き方は文章の書き方同様、個々人の好みによる部分はありそこは尊重するのですが、特に個人に強いこだわりがないのであれば皆同じような書き方に寄せておいたほうが全体的な一貫性があって読みやすいコードになります。
また「入社直後はアウトプット速度は一切重視せず、判断基準・文化のすり合わせることを最重要にしてほしい」ということを伝え、プルリクエストには大量にコメントをします。それこそ1プルリクエストに20件ほどするときもあります。そしてそのコメントに対応して議論やコード修正をじっくり時間をかけてしてもらい、互いの認識をすり合わせます。そうするとプルリクエストの数を減るごとに劇的にコメントが減っていきます。3週間〜2ヶ月ぐらいすればほとんどコメントすることがなくなるので、あとはその人に大きく裁量を持って進めてもらい必要なとき以外レビューしないという形を取っていました。
『最初ガッツリ、その後ゆるく』なレビュースタイルは平常時でも非常に有効
なおこの「新規参加者は最初アウトプット度外視で、レビューを通じて判断基準・文化のすり合わせを最重要とする」スタイルは新規開発立ち上げ期にもすごくワークするのですが、平常時でも新規参加者のオンボーディグとして非常にオススメなスタイルです。
新規参加者は文化や判断基準以外にも、例えば「どういうutility関数が用意されているのか」「どういう命名規則なのか」「テストコードをどういう粒度で書いているのか」等々わからないことだらけです。たとえ新規参加者が同じ会社の人間であったりあるいはリファラル採用で元同僚の人であったとしても、プロジェクト固有の知識を知らない限り最初から高いアウトプットを出すことはできません。
プロジェクトの新規参加者は特に、早く成果を出さなければと焦っているのが通常です。そんな中プロジェクト固有の知識がない状態で急いでコードを書いてリリースしようとすると、技術的な負債を生み出してしまったりレビュアー・レビュイー間で軋轢を生んでしまったりと全く良いことはありません。
そのため「最初はアウトプット度外視でキャッチアップ最優先」と明確に伝え、実際にそれをレビューを通じて実践することは、非常に有効だと考えています。
