わるいインセンティブに負けないためのコード規約と戦略

はじめに

僕はわるいインセンティブに駆られている開発者だった。
わるいインセンティブとはどういうものか。この説明のために今置かれている状況について説明させてほしい。
チームは新規開発で複数の案件を抱えている。また、ビジネス的な観点から多くのピボットが入る。
機能開発とリリースのせめぎあいの中にいると多くの開発者がこう考えるはずだ。
｢今はリリースを優先し、汚くて多少可読性が悪いし一般的にはだめなコードだけどマージしてしまおう｣
｢動くコードが優先! まずは動くものを作る｣
しかし、この誘惑は積み重なる程に泥沼に変わってしまう。
リファクタリングの時間は取れず、密結合なコードは剥がしきれず作り直しには予算と人員が足りない。こんなループの中で戦うことになる。
僕は全てはわるいインセンティブによるものだと仮定した。
わるいインセンティブとは早く品質の悪いコードを出したほうが結局評価につながるというもの。いわゆる囚人のジレンマである。

この状況から完全に抜け出すことは難しい。
しかし、なるべく囚人のジレンマから逃れることを仕組みとしてできるのではないかと考え以下の本を読んだ。
- リーダブルコード
- 読みやすいコードのガイドライン
- A Philosophy of Software Design

このブログポストは本を読んだ上で何を考えてどういうアクションをしたのかをかいつまんで書き残したものである。
このポストの対象読者はチームのコード規約を考えたいと考える人やチームで以上の本を輪読して次のアクションを考えている人である。

なお読んだ本の内容に直接触れるものではないため、上記の本の内容が知りたいという人には向かない内容である。

コード規約と戦略

今回はわるいインセンティブに負けないことを目的とする。そのためにコード規約を定め明文化しメンテナンスを続けることを戦略とする。

コード規約を定めることで一般的には
- 保守性の担保
- 変更に強いプロジェクトの運営
- コード品質の向上

を見込むことができると本にはある。これがもしも一定のレベルで達成ができるとしたら結果としてわるいインセンティブを防ぐことができるのではないかと考えた。
規約のメンテナンスがコストとして存在してしまうが、そのコストと引き換えにならないほどに捨てやすいコンポーネントやリファクタリングが可能なコードはメリットをもたらすと判断した。

チームのコード規約の作成までに考えること

ツール選定

仕組み化可能なこと
Gitなどバージョン管理可能なツールで管理可能なこと
自前で作るよりもOSSなどでメンテナンスされているものを選ぶ

以上の3点を軸にツールを選定する。
候補はESInt、 Prettier、 Romeとした。OSSとして実績があることやメンテナンスが盛んなこと、有名企業が自社で使っている規約を公開しておりその思想にあやかることができる点で候補とした。
その中で今回は一番一般的であると思われるESIntとPrettierを利用する。

ルール設定

チームのコード規約を設定するにあたり、以下の点に注意する必要がある。

規約が明確であること

規約が守られるようにすること規約が明確でないと、開発者はどのようにコードを書くべきかわからず、混乱を招くことがある。また、明確であっても守られなければ意味がないため、守られるようにする仕組みを用意する必要がある。

具体的なルール設定のポイントとしては、以下のようなものが挙げられる。

インデントのスペース数
ブロックの開始位置、終了位置の指定方法
変数名、関数名の命名規則
コメントの書き方、コメントの必要性
エラー処理の方法

コードレビュー

コードレビューは、規約が守られているかを確認する上で非常に重要な役割を果たす。レビュアーが規約に沿って書かれているかをチェックし、違反があれば指摘することで、規約の遵守を促すことができる。

ただし、レビュアーが全てをチェックすることは非常に時間がかかるため、特に重要なポイントについて中心的なレビュアーがチェックする、あるいは自動化ツールでチェックするなどの工夫が必要となる。

コミュニケーション

コード規約を策定する上で、コミュニケーションは欠かせない要素である。
全員がルールに納得し、遵守することができるよう、ルールの策定にはチーム全員が参加することが望ましい。
また、ルールの変更や修正についても、適宜コミュニケーションを行い、全員が理解できるようにすることが大切である。

メンテナンス方針を決める

フェーズを決めフェーズが変化するときにメンテナンスを入れる。
フェーズはチームの人数、抱えるプロジェクトの数を軸にする。なぜチームの人数と抱えるプロジェクトの数を軸とするかというと、新規事業チームなので開発チーム人数の変動が短い周期で起きやすい。なので人数を軸に入れる。
また、いくつもの新規事業案のPoCが並列で走ることがある。
並列数はチームにとっての負担であるため、負担を最小にする動きをするべきと判断しその足かせにならないようにする。

規約をどう守り、メンテナンスするか

規約は基本的に厳格なものとしてチームの生産性などを様子を見ながら徐々にゆるくする方針を取る。規約を守ることはコストではいけない。なので開発者にはなるべくVScodeやIntellijを利用してもらい、IDEのプラグインから支援を受けられる状況を作る。また、変更があるときにはプルリクエストを出して変更することを徹底する。

普段している開発の中にいかにコストが少ない形でコード規約を入れ込むかを重視する。
これらは守ることも大事だが意識しなくても守れている、その結果わるいインセンティブに流されないという状況がベストであると考える。

また、規約を入れ込む環境やチームの状況を把握することが重要である。まずは自分のチームのヘルスチェックと目指す方向性を把握することが重要である。

まとめ

わるいインセンティブに負けずに、良質なコードを書くためには、コード規約の策定が必要である。
コード規約を明確に定め、守られるようにすることで、品質の悪いコードを出しても評価されるというジレンマから抜け出しチームを救うことができる。

まずは今のチームとコードの現状を知るところから始めるのはどうだろうか?

誤字脱字と記載もれがあったんので追記(2023/03/19)