なるべくありふれた道具を使う

情報システムや自動化の仕組みを作るにあたって、目新しいものを採用することを極力避けるようにしています。なぜかというなら、単純に、存在感が安定しているかどうかの問題です。

プログラムを書くのがすこし得意になってくると、例えばExcelやAccessの上で動くVBA（Visual Basic for Applications）なんかが妙に不便に感じられてくることがあります。記述量を少なくできるようなうまい書き方が他のプログラム言語にはあるのに、こっちには準備されていない、といったことがままあり、仕方なく、少々長ったらしい書き方をする羽目になる、と感じるのです。長くなったプログラムは記述ミスを起こす可能性も大きくなるため、余分な注意が必要です。「ああ、ここに、もっと先進的な○○言語を書くのが許されていればいいのにな」という気分を感じることも時々はあるでしょう。何なら、そういう○○言語で、同様にExcelなどのドキュメントを自動編集するような仕組みも世の中の有志によって色々と作られていることがあり、実際にそれを使って、ちょっと「洗練された風」のプログラムを作成することができるかもしれません。

こういう選択肢があったときには、筆者としては、「現在、この世に、このやり方で理解している人が一番多いという方法はどれだろう」という点を考慮します。また、「数年後、できるなら10年後になっても廃（すた）れていない方法はどれだろう」とも考えます。相対的に目新しい方法のほうだと、流行が終わったあとに定番として定着しておらず、その結果、理解できる人がとても減っているかもしれません。もっと悪いのは、内部的に不具合が見つかったときに、それを簡単には直せない、という状況になってしまうことです。

プログラムを書くために外部ライブラリを援用するときも同じです。ライブラリというのは、誰かが書いた便利なプログラムを部分的に再利用するためのものです。これを活用することで、自分が余分な努力をするまでもなく、他人の成果を借りてやりたいことができる（しかも、多分自力でやるよりずっとうまくやれる）ようになる、というのが最大の利点なのですが、作者がいつまでもそのライブラリを保守し続けてくれる保証は普通は全くなく、もしそうなら、あとでバグが見つかったときや、プログラム言語自体がバージョンアップして、それに対応した調整が必要になったときに、普通の利用者は、手をつける場所が分からずに困ってしまうでしょう。見つけたライブラリがすでに「定番」のような状態になっていれば、複数の開発者が引き継ぎながら、またはチームを形成して、長く保守を続けてくれるという見込みが高いかもしれません。ここらへんを見極めて、どんなライブラリを採用するか（またはしないか）を決めることになります。

思いつくほとんどのことは、普段から目にしているありふれた道具だけで実現できるものですし、それのせいで少し「ダサい」作られ方がされているように見えたとしても、そのおかげで長く安定した動作が実現できるなら、それが一番優先されるべき価値であろうと思います。