日々の破片

_ 入れ物が変われば生活を変えるのは当然

それまで靴で家の中に入るスタイルで暮らしていた人が、畳のある家へ引っ越したら玄関で靴脱ぐ生活に変わるのは当然だし、前者が後者を裸足で暮らす野蛮人と呼ぶのは無知だし、後者が前者を水虫小僧と呼ぶのはお門違いだ。

15年前のfjでのやり取りというのを眺めていて、正直いってぐだぐだ言ってないで仕事しろよとも思うのだが、実に奇妙な感覚を得る。

というのは数十年仕事でプログラムを書いていると、いろいろとすさまじい断絶があるのだが、どうもこのへんでおしゃべりしている人たちは随分狭い範囲しか経験していないのだなぁという感想しか出ないからだ。

今となっては誰も知らない言葉のような気がするがBUNCHの1つに入社して、きわめて特異な（でも、なんとなく68000（よりもはるかに歴史はあるのだが）に似ていなくもない）アセンブリでメインフレームのミドルウェア（コンピュータのアーキテクチャが異なるから雰囲気になるけど、カーネルモードで動くというような意味）を開発（というのは、設計から実装からテストしてさらにサポートすることまでを含んでいたりする）したり、その上に乗っかるアプリケーション（コンピュータのアーキテクチャが異なるから雰囲気になるけど、ユーザーランドで動くというような意味）をCOBOLで開発したりしていた時点があって、その時点でのミドルェアの開発と、アプリケーションの開発の違いがまずある。

次に、上のメインフレームを32ビットの独自CPU（MPUとか呼んでた）に移植したミニコン（というジャンルがあったのだ）にサブセットを組み込んでいた時点の開発というのがある。似ているのだが、上のとはまた異なる。

さらに、PC9801を入手してそれを利用して上記のそれぞれの端末として動作させるための社内ツールを開発したわけだが、その開発がまた異なる（これはシュリンクラップに近い）。

で、90年代になってそれまでDOSで作られていた種々の周辺アプリケーションをWindows3.0（3.1ですらない）とNetBIOSで開発した時点（これは2人で開発した）で、また異なる（これもシュリンクラップに近い）。

それに続けて、Windows3.1で動作する業務用のシステム（これは10人くらいで開発した）が、また異なる。

さらに、NT3.51に上記のミニコンを移植するプロジェクトがあったが、これがまた異なり、それとは別にWindows3.1用に開発したやつ（上の10人規模と書いているやつ）があるのだが、それがまた異なる。

とは別にNT3.51用にミドルウェア（今でいうフレームワークになる）を開発したが、これまた異なる。

20世紀の間に、コンピュータのアーキテクチャの変化があって、それに連れて開発スタイルが大きく変わるのを何度も経験しているわけだが、それはプログラミングを中心とした場合に、環境が大きく変わるからだ。

メインフレームで開発していたときは、ソートルーチンすら存在しないから、自分で必要に応じてソートを実装することになる。アルゴリズムを使える時間や、メモリーや、引き継ぐ必要の有無から選択しなければならない。一方入出力は単純なので考える余地はほとんどない。通信が必要となればプロトコルも0から実装することになる。いちいち面倒くさいのだが薄いOSを除けばすべては自分の制御下にあり、何かしくじればそれは自分が悪い。

ミニコンの時代となると、通信やIOについては周辺のミニコンに任せられるので、自分でSYNの間隔を制御したりパリティを計算したりする必要はなくなる代わりに、それらのコントローラを操作するためのノウハウが必要となる。何かしくじっても、自分が悪くはないことが出てくる。

パソコンになると、言語がCになりライブラリがついてくるのでたとえば自力でソートを実装する必要がなくなる。ところが突然シングルタスクの世界になってしまうために、割り込みを制御したり、Windowsになるとイベントをうまく制御して細切れでアイドルにしてやったりする必要が出てきて、そうなるとOSをうまく乗りこなしてやる必要が出てくる。大抵の場合、何かしくじるのは自分の外の部分で、回避のノウハウ（というバッドノウハウ）が重要になってくる。

というように、時代が進むにつれて不確定要素（ようするに自分では制御できないもの）が増えてくる。自分でゼロから何かしなくても良い代わりに、調べること（アルゴリズムではなくAPIのレファレンスなど）が増えてきて、考えかたの違いから、それまでの方法論が通じなくなってくる。

一番の違いは不確定要素つまるところは外部要因と、確定要素つまりは自分で開発すべき範囲のバランスだ。

最初の時点では、設計とコーディングを異なるものとできた。というよりも、まずどうするか頭でこねくりまわし、コーディングシートというパンチ屋さんに指示を出すための紙の上にコードを書き、結果のカードをコンピュータに食わせなければ何もできない。パンチ屋さんがパンチをしている間にテストの計画を立てたりする。そもそもコンパイルして動作できるようになるまで1日くらいかかるので、プログラムの修正は、直接メモリー上に機械語を埋め込んでやったりすることになり、16進ダンプでプログラムの読み書きができなければ仕事にならない。不確定要素はほとんどないのだから、どういうコードにするかという設計と、コードそのものを記述する作業は、切り離せる。

ところが、不確定要素が増えるとトライ&エラーが重要になる。しかもコードを打ち込んでから実行するまでの間がTurboCなら数秒とかになってくると、設計しながらコードを打ち込んでとにかくトライすることが重要となる。紙の上でいくら設計しても、それはほとんど役に立たない。そもそも、ソートみたいに確定的なアルゴリズムで求められるものは、ほとんどすべて用意されているから、紙の上の記述は必然的にユースケースの詳細のようなものか、外部インターフェイスの仕様記述になってくる。それ以外のことを書いてもトライ&エラーの過程で変わってしまうのであらかじめ記述する意味がない。

随分と時代が変わったものだなぁと考えているうちにXPを知って、おおなるほどと納得することになった。

というようなことを10年前に日経BPで書かせてもらったなぁ（星さんとの仕事だ）と思いながら、その後の21世紀の10年間を振り返ると、開発方法についてはそれほど変化してないような気もしないでもない。というと嘘になり、プログラミングの周辺は固まったようだが（言語についてはObjective-CとC#とJavaScriptの比重が異様に増えたけど）、いかに運用につなげるかとか、テストを自動化できるかとか、問題を見つけてそれを修正して運用につなげるまでの管理とか、パッケージ作成と配布から人的ミスをなくそう（つまり自動化しよう）とか、その周りの部分が賑やかだ。

勤め先でも一部ではJIRAとFishEyeとJenkinsが活躍していたりするくらいだ。

というわけで、今度はChef Soloを使ってみようかなと。