こんにちは、EventHubの井上です。今回は『プログラマが知るべき97のこと』で紹介されている「ボーイスカウト・ルール」について、チーム開発でどのように実践しているかをお話しします。このルールを適用することで、コードの品質向上や技術的負債の削減につながることを実感しており、具体的な手法を共有します。
ボーイスカウト・ルールとは何か
ボーイスカウト・ルールとは、既存のコードに手を加える際に、そのコードに関連する箇所をより良い状態にリファクタリングすることです。簡単にいうと「来た時よりも美しく」です。例えば、以下のようなJavaScriptコードがあったとします。
const add = (a, b) => {
return a + b;
}
これを以下のように修正します。
// 整数を足し合わせる
const add = (num1, num2) => {
return num1 + num2
}
説明コメントを追加し、変数名を変更し、インデントを整えました。挙動に変更はありませんが、変更前と比べるとコード・リーディング時に生じる疑問を減らすことができました。このように、実装時に関連処理をできる範囲できれいにするのが、ボーイスカウト・ルールです。
ボーイスカウト・ルールを実践しないとどうなるか
日々の開発で軽微な修正を重ねていくことをしない場合、処理の複雑性が増したり、サポート終了が近づいているライブラリを使い続けるなど、技術的負債が溜まっていきます。それを返済するには、どこかのタイミングで時間を確保してリファクタリングする必要が出てきます。競合のプロダクトが日々進化していく中で、その工数を確保する意思決定は簡単ではありません。実装者だけでなく、QAを含めたレビュワーの工数も必要になります。
また、リファクタリングの規模が大きくなるほど、その過程で新たなバグを生み出してしまう（デグレ）リスクが高まります。家の掃除に例えると、ゴミ屋敷になってしまってからではもう手遅れなので、日々の小さな工夫で、少しずつ綺麗にしていけばいいのではないでしょうか。
ボーイスカウト・ルールを実践する上での注意点
ボーイスカウト・ルールを実践する際には注意すべき点があります。「デグレのリスク増加」と「デリバリースピードの低下」です。平たく言うと、余計なことをしてバグを発生させたり、リファクタリングに時間をかけすぎることでリリースが遅くなってしまうリスクです。こういった負の側面から、触らぬ神に祟りなしということで、よろしくないコードに目を瞑りながら開発されている方も多いと思います。では、これらのリスクを最小化しつつ実践するにはどうすればよいのでしょうか。
デグレのリスクを最小化する
デグレのリスクを下げる上で、以下2点が重要だと考えています。
- 基本的に軽微な修正に留める
- テストコードがある状態で実施する
軽微な修正とは、コメント追加、lint修正などです。これらの修正は挙動に影響を与える可能性が低いため、安全に実施することができます。
ただ、処理の共通化やライブラリの刷新など、軽微ではない修正を実施することもあります。その際に、テストコードがない状態で修正を加えてしまうと、壊れていることに気づけないままリリースしてしまうかもしれません。なので、挙動に影響のある変更は、テストコードがあることを前提にすべきだと思います。
デリバリースピードの低下を抑える
実装工数が増えることは避けられないため、レビュー負荷削減の観点で、以下2点を意識するようにしています。
- コーディング規約に沿った形で改修する
- 差分が大きくなる場合はPR（Pull Request）を分ける
「来た時よりも美しく」の美しいの定義は人によって異なります。実装者はこれが美しい状態だと思っていても、レビュワーがそうではないと感じれば、PRの議論が白熱し、なかなかマージできなくなってしまいます。一方、コーディング規約に沿った変更であれば、意思決定がスムーズにいきやすく、レビューのリードタイムを削減することができます。
また、修正範囲が広がるとレビュワーの負荷が高くなるため、状況に応じてリファクタリング用のPRとメイン実装のPRを分けることで、レビューがスムーズにいきやすくなります。
ボーイスカウト・ルールの実践例
おさらいになりますが、個人としてボーイスカウト・ルールを実践する際に意識しているポイントは以下の4つです。
- 基本的に軽微な修正に留める
- テストコードがある状態で実施する
- コーディング規約に沿った形で改修する
- 差分が大きくなる場合はPRを分ける
ここからは、私が直近でどのようにボーイスカウト・ルールを実践したか非常に簡単な例を一つご紹介します。
コメントで@deprecatedアノテーションを追加する
EventHubではクラウドインフラとしてAWSを利用しています。AWS関連の関数はAWSUtilsというファイルにまとめられており、今回はある関数に改修を加えました。
この関数ではAWS SDK for JavaScript v2が使用されていましたが、v2は2025年9月にサポートを終了するというアナウンスがされていることを知りました。
これを受けて、この関数については、SDK v3を使った書き方に変更しました。
この変更を行うだけでは、通常の実装と何ら変わりません。ここからがボーイスカウト・ルール実践の話になります。
他にもSDK v2を使用した関数がありましたが、他の関数に手を加えるのはデグレのリスクや工数の観点で断念しました。そこで、以下のようなJSDoc形式の関数コメントを追加することにしました。
/** * AWS S3にファイルをアップロードする * * @deprecated * sdk v2は2025年9月にサポートが終了するため、v3での実装を推奨します。 * 新たに処理を追加する場合は、v3を使用して再定義してください。 * @see https://aws.amazon.com/jp/blogs/developer/announcing-end-of-support-for-aws-sdk-for-javascript-v2/ */ public static async uploadToS3(
このように@deprecatedアノテーションを付けることで、ソースコード上では以下のように打ち消し線が引かれ、非推奨の旨が表示がされるようになります。（VSCode、TypeScriptの場合）
この変更によって、後続の開発者はdeprecatedの関数を避け、v3対応を検討しやすくなります。結果として、将来のコード修正コストを削減し、技術的負債の再生産を未然に防ぐことができます。また、当然ですが、コメント追加のみのためデグレの心配はありません。
このように、小さな変更でも積み重ねることで、ソースコードの品質向上に繋がります。
tipsとして、直したい気持ちはすごくあるけど時間がないという時には、とりあえずコメントだけ残しておくのをおすすめしたいです。
直すだけではなく負債を増やさない心がけも大事
有名な話で、ソースコードの割れ窓理論というのがあります。建物の窓を割れた状態で放置すると、他の窓を割る心理的ハードルが下がりどんどん割られてしまう現象のことです。
ソースコードも同じで、汚いコードを残すと再生産されていってしまう傾向にあります。一度レビューを経たものだから、真似しておけば合意を得られるはずと考えるためです。ボーイスカウト・ルールで少しずつ綺麗にしていくのと同様に、日々の実装やレビューでそのようなコードを生まないようにする心がけが大事だと思っています。
まとめ
ボーイスカウト・ルールは、日々の小さな改善を積み重ねることで、プロダクトの健全性を保つための強力な指針です。チームの誰か一人がこのルールを実践し始めると、その姿勢が自然と周囲に伝わり、広がっていきます。私自身、今回ご紹介したボーイスカウト・ルールは、他のメンバーに影響を受けて実践し始めました。ぜひ、皆さんの開発現場でも取り入れてみていただければと思います。
EventHubにはコード品質を良くしていこうという文化があり、私はそれがとても気に入っています。テックブログ以外にも会社全体の雰囲気を知るためのブログやXもありますので、もし興味を持っていただけたらそちらもぜひ見てみてください！（エンジニア絶賛採用中です！）
