「ボーイスカウトルール」と「動いているプログラムは触るな」

ソフトウェア開発の世界には、開発者を悩ませる二つの指針がある。
それが「ボーイスカウトルール」という原則と、「動いているプログラムには触れるな」という慣例である。
これらは相反するものであり、どちらが正しいとも言い難いものだ。

「ボーイスカウトルール」とは？

「ボーイスカウトルール」とは以下のようなものだ

ちなみに私はボーイスカウトを20歳までやっていた。ボーイスカウトには確かにこのような教えがあり、キャンプ場を去るときには、自分が汚し分、もちこんだゴミの撤去はもちろん、最初の状態以上にキャンプ場を綺麗にしてからその場を去ることを教えられる。
これを踏襲したのが、ソフトウェア開発でよく聞く「ボーイスカウトルール」である。

「動いているプログラムは触るな」とは？

「動いているプログラムは触るな」の慣例とは以下のようなものだ。

少なくとも日本のソフトウェア開発現場では、この慣例が蔓延しており、常識化、現場によっては義務化されている。

この世界に入って、「動いているプログラムは触るな」の教えが叩き込まれてきた

自分は20代の頃は車載組み込みソフトウェアの開発に携わっていた。
そこで言われたのが
「動いているプログラムは触るな」
だ。
スペース一つでも余計な修正はするな、必要最小限修正に留めろ、勝手に触るな！古いコードにおかしい箇所があっても触るな！

理由は今問題なく動いているからだ。
必要以上に触って、そこが原因で何か問題が発生したらどうするのか？元の作りにどれだけ問題があろうが、必須ではない対応で余計な不具合を発生させてしまうのは責任問題にもなる。
極端なことをいうと、修正箇所ができるだけ少なく済むように、対象無理やりにでも修正を入れ込む。結果としてソフトウェアはより複雑になり、次回の修正変更がより難しく大変になっていく。
それでも、余計な不具合が発生してしまえば、それが納入テストや市場に出回ってから見つかってしまうと、そこにかかるコストは計り知れない。

「動いているプログラムは触るな」
は、本来あるべき形ではないことは分かってはいる。だからと言って簡単には否定できない。
既に動いているシステムで、長くメンテナンスされておらず、テストコードも存在しないのであれば、これは現状取れうる選択肢ともいえる。

動いているプログラムを触らないことを続けるとどうなるか？

動いているプログラムは触れない。しかし機能追加や不具合修正は発生する。
「動いているプログラムには触るな」の慣例を絶対視し続け、既存コードへの変更を極度に避け続けると、ソフトウェアは“触れてはならない神殿”と化す。
新たな機能はすべて既存コードを汚さないよう、パッチワークみたいに後付け後付けされていく。次第にロジックは分散し、重複し、依存関係は迷路のように絡まっていく。結果として誰も全体像を把握できなくなる。

やがて、コードに手を加えること自体がリスクとみなされ、新人エンジニアは「このクラスは触るな」「この関数は怖い」と口々に言うようになる。コードレビューでは「既存を壊さなかったからOK」とされ、設計の整合性よりも局所的な無難さが評価される。

コードは確かに“壊れてはいない”。だが、もう誰も触れない。

「ボーイスカウトルール」の適用にはテストが不可欠

Clean Coderにある一節を引用しよう。

ソフトウェアを変更しないことこそが危険であることは前述した通りだが、ではなぜ開発者がソフトウェアを変更することを怖がるかというと、それは書かれているように壊れるのが怖いからだ。
壊れる、つまり自分の変更が思わぬところに影響を与えて、今動いている機能のどれかがうまく動かなくなってしまうことだ。
それは誰だって嫌だ。ビジネス的な観点から見ても、それは最も回避すべきことだ。

では、なぜ変更しても壊れないことを保証する為に必要なことは、網羅的なテストコードの存在(単体テスト)となる。

テストに関する話は以下記事にまとめてあるのでここでは割愛する。

ボーイスカウトルールを現場に定着させるには

ずっと「動いているプログラムは触るな」が正しいと教えられてきたし、これしか選択肢がないのだと思い込んでいた。
しかし、ソフトウェア開発の知識を深めるほどにこの教えは"慣例"でしかなく、今はなんとかなるかも知れないが、問題を先送りにすることにしかならないという欠点を抱えていることに気づいた。

なんとかボーイスカウトルールを定着させるにはどうしたらよいか
そのプロセスは、以下のようになる。

1.「ボーイスカウトルール」という考え方があることを布教

まずこの考え方が、ソフトウェア開発の原則として存在することを布教する。この考えをチームや組織に知ってもらう為の活動となる。

2.もし単体テストがないプロジェクトであれば、単体テストの導入から始める

ここでいう単体テストとは、テストコードによって対象機能のふるまいを自動で検証、保障する、開発者による開発者の為のテストのことだ。
もし対象のソフトウェア開発プロジェクトに「単体テスト」が存在しないなら、これを導入するところから始める必要がある。
前述したように単体テストにより、機能が壊れないことがいつでも保障出来ることがボーイスカウトルールの適用には不可欠となる。

3.新たな機能を盛り込む前に「リファクタリング」フェーズを導入する

新機能や不具合修正対応を実施している中で、同時並行的に他の箇所の修正も入れることは推奨しない。
やるのであれば、新たな対応を実施する前に「リファクタリング」フェーズを導入して、そこでやるのがよい。
もちろん、単体テストを都度実施して、機能が壊れていないことを確認していく必要はある。

まずは小さく、そして自分が直接かかわるプロジェクトから

いきなりチームが抱えるすべてのプロジェクトの方針を変えるというのは非常に難しい。あなたが1メンバーであっても、それなりに影響力のある管理職であったもそれはやるべきではない。
まずは小さくはじめることをおすすめする。
もし自分が直接かかわるプロジェクトがあれば、その中で少しでもやっていきませんかという提案を行うことだ。

とにもかくにも、まずはマインドチェンジからが重要だと思われる。
リファクタリングが原因で何か問題が起きたとすれば、それはリファクタリングそのものに問題があったのではなく、壊れやすい元々の設計に問題があったか、単体テストに問題があったかだと考えるべきだろう。

マインドとしては「ボーイスカウトルール」を頭にいれておく

チーム事情や自身の立場もあるだろうから、仕事の現場に即座にこの考えを定着させ、実行に移させるのは難しいだろう。
ただ、自身のマインドとして、この考え方を頭に入れておくのはオススメする。
ボーイスカウトルールの詳しい解説や自身の中での納得度を上げたい場合は以下の本を手に取ってみることをおススメする。

短期的な安全を取るか、長期的な成長を取るか

短期的な安全策としての『触るな』は、結局長期で見ると負債として積み上がり、コードを硬直化させ、ソフトウェアや技術者のさらなる成長を阻害することになる。
テストに裏打ちされたボーイスカウトルールこそが、変化に強く、健全な開発を持続可能にする鍵となる。
たとえ現実的に今リファクタリングが不可能であっても、ボーイスカウトルールのマインドを頭に入れておくことは重要なことだと

そしてこれはソフトウェア開発に限った話ではない。他業種でも、あるいは私生活でもそうだ。
目先の安全性を取るか、長期的な成長を取るか。
今問題なく回っているので、触らずにいる"神殿"のようなものはないか
考えてみても面白いかも知れない。