型

いくつかシステムなりスクリプトなりを書いていると、何回も使い回される部分が決まってくるんですね。毎回毎回、同じモノを作っていては時間の無駄だし、一定したクオリティを保つことが難しくなるわけで。

そこで、ある程度使い回された状態で一つのまとまりにして、それを毎回使うようにしていくと、車輪の再開発をしないで効率化ができていくと。・・・そういうのはソフトウェア開発に関わる人ならみんな知っていることですけど。

少人数でシステム開発と保守を任されていたことがあった。まだ、その頃はハケンじゃなくて、お客様から業務委託の仕事を請け負っていたりしました。あの頃は、家賃も半分経費にしていたから経済的にはだいぶ助かっていたよなぁ・・・と、そんな話じゃなかった。

少人数ゆえに生産性を拡大させていくためには、今、行った仕事を必ず後にも再利用できるための工夫をする必要を感じていました。とにかくスクリプト関連は言うに及ばず、業務帳票から統計分析表まで、全部、使い回しのきくものはまとめていったりとかね。

仕事の型を作る。もうちょっとかっこよく言うと「テンプレートを作る」ということに喜びを感じていたんだなぁ。たぶん私はプログラムを書く人としてはひんしゅくを買うタイプの人だと思う。とにかく関数やらを覚えることが馬鹿馬鹿しかった。そうは言っても、よく使う関数なんかは覚えてしまうんだけど。

プログラム言語と心中するくらいのつもりなら、どこまでも修練してプロフェッショナルになったんだろうと思う。でも、プログラム言語は時代とともに仕組みもスタイルも変わっていく。すると特定の言語を細かいところまで覚えるのがアホらしくってねぇ。

だから、あまり使わなさそうな関数群を初めて使う時にはがんばって調査する。で、それらを使って自分流に「固めた」仕組みを一度作ったら、あとはそこをブラックボックスにしてしまい、後は自分の作ったルールで使い回す。そんなことをしてました。いわゆる自分用パッケージを作るみたいな感じ。

たいていの場合はそれでうまくいくんですよ。一回目は苦労しても、二回目以降からはウソみたいに効率的だったりもした。しかし、そういう仕組みが増えていき、ある一定の時期を超えたときに突然不便になるんですね。

仕組みを「固める」ためには利用シーンを限定するところから始めるワケだけど、だんだんルールに縛られて小回りがきかなくなってくる。そして、自分で決めたルールに適合させるために、回り道をさせられるようになってくるんですね。

しまいには、回り道をしたために計算コストが大きく・・・要するに、その仕組みを使うと処理が重く遅くなってしまったり。さらに悪いことに、そのことが「固めた箱」の利用ルールを外れた新機能を開発しようとした時に、開発コストがかかるようになってしまったり。

たぶん、日常でも新しい自分に変わろうとする時に、既存の「自分ルール」が足を引っ張ることがあるのかもしれませんね。そして自分が新しくなっていくために決めたルールもまた、ある時期がきたら柔軟に見直す必要があるんだと思います。

昆虫が脱皮していくみたいにね。