ここ最近、ボーイスカウト・ルールって良いルールだなーと改めて思ったという話。
今年の下半期は、他のチームにスポットで入ったり、別のチームがオーナーのリポジトリを触ったり、オーナーが明確じゃないリポジトリを触るケースが多かった。何かしら事業上、とりわけ売上に関わるイシューを解決するために一時的に触るという感じだったが、そのときに意識したのがボーイスカウト・ルール。
ボーイスカウト・ルールというと下記のページを見る限りコーディングに対して「来たときよりも美しく」を適用させようという趣旨に読み取れるけど、もっと広い範囲で適用させても良いと思う。
そう考えていたら、同じようなことを言っている方がいらっしゃった。
生産性とかもそうなんだけど、「次来た人のことを考えて行動する」ということなのかなと思った。
自分の話に戻ると、古いIssueを掃除したり、ランタイムをアップグレードしたり、RDBの不要なカラムを削除したり、シードデータ生成処理を改善したり、不要な処理を削除したりといった感じで、「美しく」の捉え方にもよるけど、次来た人のことを考えてこういったことに手を伸ばした。
自分以外の例だと、多くのリポジトリのデフォルトブランチが未だにmasterになっているのを全てmainにしようと呼びかけた人がいた。その時限プロジェクトにはたくさんの協力者が集まり、あっという間にmainブランチへのリネームをやりきった。
今自分がいる会社にはボーイスカウト・ルールを当たり前のように実践できる人がたくさんいいて日々刺激を貰っているのだけど、彼らを見たり、自分の経験を元に考えてみると、ボーイスカウト・ルールを実践するとその人のできることが広がっていくんじゃないかと思う。
来たときよりも美しくするために行動すると、会社の事業やシステムの知識が少しずつ広がっていったり、過去の経緯を知る機会になったりもする。改善のために必要な技術の習得にもなる。他の人になぜこの変更を今したいのか伝える必要があるので情報の整理や文章化の訓練にもなるし、関われる人も増える。そうやって行動する人が増えるとなんかすごく良さそうな気がした。
そしてこれは礼儀以上の話でもあります。他人が書いたコードを改善しようと思えば、自分の担当部分のコードを改善する場合とは全く違った配慮が必要になります。チームのメンバーが互いに助け合い、そして互いのコードを綺麗にするのです。ボーイスカウト・ルールを守るのは、それが自分だけではなく、皆のためになるからです。
ボーイスカウト・ルールが大事と言っても、100個問題を見つけたら100個全部解決しないといけないというわけでもないと思うし、無理にアラ探ししようということでもなく、まずは「気づいたらどう振る舞うか」なのかなと思う。そのうち1個でも前に進めたり解決したりすればすごいことだし、そのうち気づける範囲も広がっていくと思うので、地道にやっていこうと思いました。
---
気が向いたらコネヒト Advent Calendarの他の記事もチラ見してみてください。