人数半減の中で総開発量UPを実現させた秘訣 by エイチームコマーステック Advent Calendar 2023

5記事目は、エイチームコマーステックフロントエンドエンジニア中村（@machumun）が担当させていただきます。

今回は前回に引き続き、レビュー時間の短縮について書かせていただきます。前回の記事では主に設計レベルの大きな指摘の話でしたが、今回は小さな指摘を減らすことでレビュー時間の短縮を図ったことについて記載します。

レビュー工程に時間がかかっていた理由

我々の組織は以前、レビュー工程に大きな時間がかかっていました。詳細は前回のアドベントカレンダーの記事(https://qiita.com/bayasist/items/d46e7b0e5ce0e140a5e7)
に説明があります。

レビューにかかる時間が長くなっていた理由として、以下のようなものがありました。

細かい指摘で同様のものの繰り返しが多かった。
nullが入るなどの不具合がある可能性があるコードの指摘が完璧にできず、後から気付き再度レビューが必要になることがあった。

また、各レビュアーによってレビュー基準が異なることで、レビュアーによっては出戻りが多かったり少なかったりとレビュー・修正工数にムラがあることで、施策の計画に問題が出ているという課題も別途ありました。

具体的な施策内容

前述の問題を解決するために、コードの品質を機械的にチェックしてくれるような機構を整える試みを行いました。

機械的なチェックを増やすことでレビューの指摘箇所が減り、それによってレビューの総時間の削減を狙いました。

また、レビュアーの負担が減ることで他の施策に手を付けることができ、その点でも効率化できると考えました。

そこで、機械的な確認をするためにlintとTSConfigを整備していくこととしました。

lintはコードの書き方に制約を設ける事ができ、TSConfigはTypeScriptのオプションを設定できるもので型の書き方に対する制約を設定可能です。

それぞれに様々な設定がありますが、どのように設定をしていったかの記載をしていきます。

lint

まずは比較的有名であるAirbnbのlintの設定を丸パクリし、その上で過不足を調整することにしました。

何もない真っ白な状態から作り上げることや、他のlintなどとの比較検討をしていくとなると時間もかかるため、比較的有名である＝ある程度どのようなプロジェクトでもフィットしやすいと信じて入れてみることにしました。

ですが「とりあえず導入してみる」という手法にはデメリットもあり、当然自社の設計思想に合わないlintルールが紛れている可能性があります。

ですのでルールの追加や無効化など調整を運用しながらしていくことにしました。

実際にAirbnbのルール以外の追加をいくつか行っています。
せっかくなのでそれらいくつかを紹介しておきます。

複雑なロジックの禁止
文字列中の変数展開はstring型のデータ以外は禁止
==を禁止し、===での記載を強制(===の方がより厳密に評価します)
etc...

さらには、コードレビューで人的に繰り返し指摘がなされるものや課題感があるものをlint化したり、バックエンド・フロントエンド間でのルールの横展開など改善を重ねました。

大事なことは、まずは導入してみるということです。

導入した上で、システムが目指したい形や現在の組織構成から取捨選択をしていく事でより効果的にlintを機能させることができます。

TSConfig

TypeScriptで用いる型の厳密さを設定する項目がありますが、その設定を厳しくすることでメンバーのコードの書き方に縛りを付けました。

厳しいルール付けにより、実行時ではなく開発段階で変数がnullになる可能性を見抜けるなど型に関する恩恵を多く受けることができるようになります。

導入過程

lintやTSConfigを理想的な状態にするためには、相当な量の編集が必要です。
設定の変更だけではなく、その設定に適合するように各ソースコードを変更する必要があるからです。
我々は少数組織なのでそこにまとまった時間が取れませんでした。また仮にまとまった時間が取れたとしても、他のメンバーとのコンフリクトや、不具合リスクなどもあるため、一気に変更することは適切ではないと考えました。

その問題を解決するために、いきなり全てのファイルを編集するのではなく、段階的に編集をしていきました。

以下、具体的にどのように実施したかを説明します。

lint

lintやTSConfigを理想的な状態にするためには、相当な量の編集が必要です。

設定の変更だけではなく、その設定に適合するように各ソースコードを変更する必要があるからです。

我々は少数組織なのでそこにまとまった時間が取れませんでした。また仮にまとまった時間が取れたとしても、他のメンバーとのコンフリクトや、不具合リスクなどもあるため、一気に変更することは適切ではないと考えました。

その問題を解決するために、いきなり全てのファイルを編集するのではなく、段階的に編集をしていきました。

以下、具体的にどのように実施したかを説明します。下記のような方法をとることで、徐々にコードを直していくことができ、半年たった後にはよく触るファイルのほとんどが基準に適合したソースコードになりました。

lint

まず初めにlintのルールに適合しないコードはリリース出来ないようCI/CDパイプラインを整備し、lintに適合しないコードの増殖を防止しました。

そのうえでlintのルールを設定しました。

この状態では既存のコードがlintに反してしまいリリースが出来ないため、各ファイルにlintのルールを無視する設定を入れました。

以後、各施策のために編集したファイルは施策担当者が無視の設定を外さないといけないというルールで運用しました。

施策によって各ファイルが編集されるごとにちょっとずつlintに適合するコードが増えていきました。

TSConfig

TSConfigにはlintのようにルール違反したコードを無視する設定がないので、同じようなアプローチは取れず、徐々に設定を入れていくようにしました。

nullエラーになる可能性のあるコードを認めない設定など1つの設定を変えるだけで相当な労力を要するものもありました。

そのようなものは、同じようなことが出来るlintを探してきて導入し、該当コードが少なくなってきた段階で一気にコードと設定を変更するというアプローチをとりました。

結果

lintやTSConfigといった、システムレベルでコードの書き方を縛るルールを既存プロジェクトに無事導入することができました。

現在ではコードレビューでの細かい指摘がなくなり、往復回数や不具合を減らすことに成功しています。

副次的にも、制約があることによってコードを書く際に迷いが生じる事も少なくなったため実装時間も短縮されるという嬉しい効果がありました。

さいごに

lintも個人開発だと面倒だと思っていただけでしたが、こうやって組織開発で仕組みとして導入すると便利さを実感することができました。

次回カレンダーのテーマは、

検証工数激減の立役者：ノーコードE2Eテストを導入してみた

です！

もしご興味があれば、エイチームコマーステック Advent Calendar 2023をご購読いただければ嬉しいです。

ここまで読んでいただき、ありがとうございました。