プログラミングには”ボーイスカウト・ルール”と呼ばれる有名な格言があります。
ボーイスカウト達は「来たときよりも美しく」という原則を大事にし、キャンプした後は過去に他の人が出したであろうゴミも持ち去りキャンプ前よりもキレイにしようという文化があります。
ボーイスカウト・ルールは、プログラミングにおいてソースコードを変更する際にどこか1つでも良いからコードをきれいにして、自分が作業する前よりも作業した後の方が綺麗になっているという状態を目指そうという考え方です。
※ 元の文章が以下サイトで紹介されていました。
ボーイスカウト・ルール | プログラマが知るべき97のこと
個人的にはこの原則はすごく重要だと考えています。
システムはほとんど全てのケースにおいて、時間の経過とともに規模が拡大し複雑度が高くなっていきますが、ボーイスカウト・ルールがあることでその規模・複雑度の増大に抗えます。
このルールがないと、複雑なシステムが出来上がってしまい生産性が極端に落ちます（技術的負債と呼ばれるやつです）。
課題が生産性の低下という形で表面化したときに初めて複雑さの解消に動いても、時すでに遅しです。
そういったわけで個人的にかなり気に入っている内容なのですが、素晴らしいルールなのでコーディングだけでなくあらゆることにボーイスカウト・ルールを適用するのが良いんじゃないかと思っています。
時間の経過とともに規模・複雑度が増えていくのは、システムのソースコードだけではありません。
システムの仕様にも同じことが当てはまりますし、もっというと日常的にこなしている業務やチーム・会社の制度などにも同じことが当てはまります。
ソースコードのキレイさはエンジニアが働く環境において重要な要素の1つですが、環境全体の一部でしかありません。
例えばシステム仕様が複雑で理解に時間がかかる、無駄な会議体が設定されているなどなど、複雑な環境によって生産性が下がる例はソースコード以外にも色々あります。
あらゆるものをクリーンにリファクタリングし続けることで、仕事環境から集中を阻害する要因を減らし、生産性の高い環境をキープし続けることができます。
こういった背景で非常に重要なボーイスカウト・ルールですが、これを評価基準に入れることは難しいです。
なぜならクリーンさは定量的に測れないからです。
また残念なことに、よく評価基準として採用されている仕事の速度・量という基準とこのルールは相性が悪いです。
なぜならクリーンさがもたらす価値は、中長期的な生産性（速度・量）の向上としてのみ現れるものであり、短期的には価値をもたらさないからです。
むしろクリーンにしている作業時間の分だけ、短期的には生産性は下がります。
評価基準に入れることは難しいため、組織文化としてこのルールを定着させるのがいいと思っています。
中長期的な投資としての何かをクリーンにする行動を奨励し、実際にそのための時間を確保できるような制度を作り、実際にそういった行動が取られたときにその価値を認める文化です。
そのような文化があることで、短期的な成果だけにとらわれず、中長期的な生産性向上をができます。
