ベストプラクティスの庭
開発の現場でよく手順書というのがある。
たとえば、あるプロダクトを開発するための環境を作るために、やれあのソフトをインストールしろ、環境変数を追加しろ、設定値はこう、なんて書かれてあるやつだ。往々にしてこの手の文書というのはメンテナンスが後手に回りやすいので、新参のメンバーなんかがこの手順書に従って構築をやろうとすると現在ではもう古くなっている点が原因で手順通りに進まなかったりする。
最近はInfrastructure As Codeの文脈から、そういうものもコードにしておくべきではという話になってはいるものの、周辺プロダクトは勝手にアップデートしていくし、それに追随しないわけにもいかないので、手順の自動テストでも実装していれば早急に気付けるだろうが、まあ後手に回るのは変わらない。
結構この手の「後手に回る」のは過去に問題視されていて、新参、つまり一般的な会社においては新入社員などがこの立場にあたる場合が多いのだが、彼らが手順のうまくいかない部分に躓いて「手順書の更新は新入社員の仕事ではない」みたいなことを言い出すトピックがあったりした。
まあ結局はこういうのはコストの問題で、心理的・経済的そのほかいろいろな面で、コストが極端に低ければ後手後手だろうとかまわないんだろうし、逆に低コストの解決策があればみんなそれに乗っかるんだろうけど、実際のところは必ずしもそうでもないので・・・まあ難しい。
今回の話はその話ではない。
この間ある目的があって、特殊でもないがある特徴のある環境を構築する必要が出てきた。で、これにはちゃんと手順書があって、この通りやれば大体問題はない。もちろん上述の問題はあるので、現時点でのやり方に読み替えながら進める必要はあった。 そのなかで、うっかりある一つの手順を飛ばしてしまった。それが原因であとあと問題になるのだが、いつも手順書に沿って構築をおこなっているためこの手順を行わないことでどういった問題がおこるのか、自分自身よく理解できていなかった。つまり、問題が起きているのに、それがある手順が足りないためだという因果関係に気づくことができなかった。まあちょっとよく知った人に聞けばすぐわかるので良いといえばいいのだが、何にせよこの手順に落とし込めるほど知られた問題の因果を、自分が知らなかったという点に若干ショックを受けた。
これとは違うが、似たような話として、Java Puzzlers で嵌った話を過去に書いている。
過去にこういう設計の仕方はよくないであるとか、こういう場合はこういう設計にすべきであるということ（いわゆるベストプラクティスとか、デザインパターンとか、Good Partsとか言われるもの）はいろいろ学んできたつもりでいるし、世のエンジニア諸兄においてもそうあるものと信じているが、逆に考えると、「すべきでない（と思う）設計」でコードを書くことはないため、（意識的であれ、無意識的であれ）それをした時に何が起こるのかは想像の域でしかわからないのではないか。
ベストプラクティスの庭に閉じこもって振る舞う分にはなにも申し分がない。しかしひとたび踏み外した途端に一歩も進めなくなってしまう可能性がある。さらに可能性の話をするならば、使ってみたことのない設計パターンの中には目の覚めるようなイノベーションが眠ってさえいるのかもしれない。理想の庭園に閉じこもっている限り、そうした発見もないことになる。
すべきでない設計のコードを書いてみるべきか？と聞いてYesと答える人は、まあいるとすれば多分プログラミング入門書の執筆者くらいか。一般にはそんなことをしている暇はないだろう。ただそれによって問題が発生した時の対応力に大きく差が出るのであれば、一考の余地があるし、そういった技能を持つことに明確なスキルセットを認めるべきのように思う。個人的な感覚では、あまりそんなことを明確にやらせている現場はないように思うし、息まいてそんなことを推奨しだしたら煙たがられそうだ。
いや、だからと言って勧んでプロジェクトを炎上させろと言いたいわけではないのだけど。
