「(序)」からの続き。

COBOLという頭痛

実はアプリケーション開発者を集めた時点で、某社社長は「開発言語はCOBOLで」と言っていたフシがある。まぁそうでなかったら、多分彼等は参加してなかっただろう。私は逆にイマイチ仕事のない人達を使うんだから、「仕事」をエサにすれば言語には選択肢があると思っていた。仕事が欲しけりゃ言語くらい勉強すりゃいいんだから。

当時のCOBOLで一番頭が痛く、かつ私が気乗りしなかったのは、

オープンソースの処理系がない

ということだった。全くの皆無ということはなかったのだが、実用処理系はなかったのだ。確かにTinyCOBOLはCOBOL 85の重要な機能を実装してはいたが、計算が浮動小数点で行なわれていたから、金の計算には無力だった。他の処理系は、74規格までだったりしてお話にならない。いくらなんでも、21世紀になろうとしている時に、74規格はありえん。

某社社長達の「勝算」には、当時関係のあったドット研究所の「dot COBOL」を使うということがあった。確かに当時は彼等と一緒にビジネス展開とか考えていたところであるから、ある意味妥当な選択ではある。

しかし、dot COBOLはランタイムが有償だった。となると、アプリケーションはタダで配布することが出来ても、その実行環境が有償ということになってしまい、日本医師会の期待からは外れてしまう。だから、あまり使いたいとは思わなかった。

反面、dot COBOLは素晴しい開発環境を持っていて、GUIで画面を作るとか、帳表を作るとかそういったことが出来た。「序」で言ったように、当時オープンソースで業務アプリケーションを作る開発環境は皆無だということを思うと、多少ランタイムに金を払ってもペイするとも考えられる。そういった意味では「ベスト」の選択ではないが、「ベター」ではあったのだ。

ランタイムについてどうするかは、私の関わるべきレイヤではないなという部分があったので、とりあえず「有効な選択肢」として持っておくことにした。

他の言語の検討

COBOLでもう一つ気乗りしなかったのは、COBOL自体が古臭い言語だということだ。

確かに、あまり難しいことを考えなくても、それなりの品質でシステムが作れるというのは大きいし、当時はプログラマを集めるのもそれ程手間がかからなかった。このプロジェクトは「実験」でないのだから、「確実に動くものが作れる」ということは、最重視されるべきポイントだ。そういった意味では

COBOL最強

とも言える。

しかし、当時の私をして「今からCOBOL？」と思ったのも事実だ(ちなみに「COBOLの中の人」になったのは、それからずっと後のこと)。レガシーマイグレーションのツールとして、Linux上のCOBOLは非常に興味があった。しかし、新規にアプリケーションを作るものとしてCOBOLというのは、いくら何でも… というのが正直なところだった。だから、出来ることなら他の言語で開発したいと思っていた。

某社で言語と言えば、当然

Ruby

だ。だから、当然のことながら、Rubyという選択肢についての検討をした。当時の状況を考えれば、「Matzが会社でのうのうとRubyで遊ぶ対外的説明」が必要だった。その当時の某社は結構某V社やその関係者の資金が入っていたから、その辺の人達から説明を求められるということは十分に考えられた。彼等の戦略は毎晩のように変わっていたから、どの時点でどうだとは言えないが、某社を上場させて… という考えもあったので、直接目玉になるような案件が欲しいという事情もあった。その中にあって「この開発にはなぜRubyは使えないの？」というつっこみは十分に考えられた。また、そういった開発をテコに開発力を強化して… ということも考えた。他人のものであるdot COBOLへ投じる金が、「自社製品」であるRubyに投じれるのであれば、商売としてもおいしい。

そんな背景もあって、Matzに打診(聞いたのは私じゃない)をしたら「まだそんなことに使えっこないし、そんなことで縛られたくもない」というツレない返事だったらしい(*1)。まぁ当時のRubyはあくまでも「オブジェクト指向スクリプト言語」であって、汎用の業務開発言語じゃない。彼としては妥当な返事だろう。だから、Rubyという選択肢は早々に消えた。

Rubyのあるお陰で、当時の某社にはperlをガリガリ書ける人もJavaをやっている人もいなかった。何しろ、Rubyは何でもかんでも使える便利言語だ。CGIとかなら十分過ぎる。また、SI経験のない某社に、いわゆるシステム開発の仕事は入って来ない。だから、「Cで難しいプログラム」を書く人以外は、たいてい何でもRubyを使っていた。だから、某社内での人材的には、perlやJavaという選択肢はない。とは言え、「プログラム開発だけは他の外注に出し、上流工程だけ集めた技術者にやってもらう」という考えもあったから、これらについても検討してみた。

Javaはいまだに「なんで使わないんだ」とつっこまれる言語の一つであるが、当時は以下の理由で選択肢とはなりえなかった。

1. Linux上のJavaは当時はロクなもんじゃなかった
2. 当時のJavaの実行はアプレットとJSPが中心
3. 結局オープンソースの処理系はない

1.は時代をその頃に戻さないと理解出来ないだろうが、当時LinuxとSunはあまり良好な関係ではなく、Sun純正のJavaはLinuxにはなかった。また、Java自体もやっとこさJava2が出たところだったので、これを業務システムに使うというのは、まだ「チャレンジ」だった。おまけに、JavaとJava2の変化を見て、「これ、基幹業務システム開発言語という立場を理解してる？」と思ったものだった。それくらい変化が大きかった。もちろんそれは良かれと思ってされた改良だったのだが、あちこち互換性がなくなったこととか見ると、この先何10年も使えるかと言うと、不安になるものだった。

2.は後からまた話に上ることなのだが、「レセコン」は業務システムだ。業務システムのデータエントリというのは、「伝票見ながら、高速タッチタイプする」ものだ。だから、操作にマウスが必要なんてダメだし、画面の展開の速度等も速いことが求められた。だから、webを使ったシステムは検討すらしてもらえなかった。そういった意味では使えなかったのだ。

3.についてはdot COBOLと大差ないし、こっちは無償だということもあって、いくらかマシだとも言えたのだが、当時のLinux上のJVMの不安定さとか考えると、「自分たちで何とかしたい！」という気がするものでもあった。つまり、非オープンソースに身を委ねられる程の品質がなかった。また、当時(今も)JavaはECMAにすら承認されていない「Sunの俺言語」だった。つまり、Sunが潰れたらどうなるかという点についても不透明だった。これはdot COBOLも似たようなものだが、ドット研究所はあまり大きな会社じゃないから、「もしそうなったら、最悪会社ごと買え」という話があった。さすがにSunにはそれは無理だ。

そんなわけで、「当時」のJavaはまだ安心して基幹業務システムを作れる環境ではなかったし、プログラマも集めにくいものだったので、選択から落ちた。

perlはいくら何でもないだろうということで、ほぼ無検討で落ちた。

実は当時一番安心して使えたLinux上の開発言語は、「C/C++」だった。だから、当然これらも考えに入れようとした。しかし、いくら何でもCで業務システムを作るというのは、リスクも大きいし、開発にかかる負荷も大きい。本質的でない問題で悩むであろうことも想像に難くないし、「10進演算」についてもライブラリを用意しなきゃいけない。うまく環境整備をすればそれなりの生産性も上げられたかも知れないが、その工数も馬鹿にならない。また、後で述べるミドルウェアの問題もあった。そんなわけで早々に選択肢から落ちた。

ということで、なんだかんだ考えながらも、

ランタイムのことはとりあえず忘れて、
dot COBOLを使う

という選択になったのだ。結果論であれこれ言うのは簡単なのだが、「当時」の「現実」を考えると、事実上その他の選択肢はないも同然だった。

データベース

dot COBOLを使うとなると、データベースはOracleを使うしかない。だから、開発を始めた当時はOracleの上で開発していた。

もちろんこれは許されることではなくて、早々に(公式リリースまでに)他のオープンソースのデータベースを使うことが求められていた。当時の我々とドット研究所の関係から「PostgreSQLへのインターフェイスを用意してもらう」というのが前提であった。だから、「私のよく知らない上位レイヤ」では、その辺の交渉が進められていたはずである。実際どうなったか知らないけど。

私は私で、dot COBOLに他のデータベースへの口をつけることを検討していた。では、何を使うかだ。

時計の針を当時に戻すと、PostgreSQLはVer 6系から7に移る時期だ。プロジェクトが始まった当時はVer 6系だったから、まだテーブルロックしかサポートされていなかった。ただ、7系はそれが解決されるという話は、既にML等で知っていた(MLに参加したのはPostgres95のちょっと前くらいからだったと思う)から、「とりあえずそれを待つ」というつもりでいた。問題は、スケジュール通りに7系が出てくれて、それが実用に耐える品質であるかどうかだ。ORCAの開発は2000年の春頃から開発が始まっているので、いろんなタイミングが微妙な時期だ。

私のような古いタイプのエンジニアは、「初物」を嫌う。やはりある程度世間で動作が確認されたものでないと使いたいとは思えないのだ。それを思うと、「とりあえずORCAのデモ公開」という時期に、PostgreSQLが使用に耐える品質になっているというのは、甘過ぎる見通しだ。どうせ「とりあえずのデモ」なんだから、別に難しいことや高負荷をかけるつもりはないのだが、「動くと思っていた機能が動かない」という事態が起きると厄介だから、極力「初物食い」は避けたい。それを思うと、そのタイミングでPostgreSQLを正式採用するというのは、難しい選択だった。

他のデータベースエンジン、たとえばMySQLなんてのも選択肢としてあったし、InterBase(Firebird)もあった。新規に作るソフトウェアで使うのだから、難しいSQLを使わないようにすれば、多少SQLの機能が低くとも問題はないので、ある程度の速度(当初は「内科の開業医」が想定ユーザだった)とトランザクション管理さえあれば採用の候補になった。

しかし、MySQLは高速ではあるが、当時はトランザクション管理を持っていなかった。webアプリケーションではその辺をうまく騙してやって実用にしているところもあったのだが、その辺にエネルギーをかけるのはアプリケーション側には難しいからミドルウェアで頑張る必要があった。しかし、当時ミドルウェアにどこまで開発力をかけるかというのは、未定だった。だから、「ドット研究所にお願いして作ってもらえる範囲」あるいは、「私がちょっと頑張って何とかなる範囲」での採用については、否定的だった。

InterBaseは機能的には特に問題はなかったのだが、今となってななぜ候補から外したのか覚えていない。多分、PostgreSQLと比べると情報が少なかったということと、当時実際にプロジェクトをやっていたのは加藤大受さんだけのように見えたので、不安があったからだと思う。また、オープンソース公開された直後に近いタイミングだったということも災いしていると思う。

ただ、その場の人達の考えとして、「dot COBOLにPostgreSQLサポート機能を用意してもらう」ということで、PostgreSQLを将来的には使うということになっていた。

とは言え、前述のような理由で、公開デモの時に向けてはOracleのままで行き、PostgreSQLにするのは「追い追い」ということになっていた。

データベースをどうするかについては、「ミドルウェアの検討」のところで、再度考えることになる。

余計なおまけ

これまでの諸々の開発上の意思決定については、基本的に「私個人の都合」は入れていない。なぜなら、それを通してしまうと、私に責任を被せる人が出て、余計に厄介になるからだ。それでも諸々の決定については、私はかなり「強硬」に主張している。それは、当時の「周辺環境」のせいだ。

とにかく「公開デモ」の時に動いているものを見せなければならないという大前提がありながら、「上のレイヤ」の人達は様々な思惑で朝令暮改的に方針変更をしようとしていた。それを一々聞いていたら、出来るものも出来なくなってしまう。そのため、「多少マシ」な提案があっても、それはスルーしておくべきことだった。

また、なんとかして余分に金を引き出したい(引き寄せたい)人とか、これをネタに関連する会社を上場させて儲けようとか、そんな人も大勢いた。そういった人達は、どんどん話を大きくして行き、数10億単位で金が動きそうな巨大プロジェクトにしようとしていた。そんな中で、何とか「公開デモ」に漕ぎつけたのは、頑固者を演じたからだと思う。

外野が多いプロジェクトだし、「半可通」も大勢絡んでいた。そういった人達は「いつでも逃げれるポジション」を確保すると共に「自分の手柄」を作ろうと、様々な工作をしていた。「助言」だの「提言」だのと称する「雑音」も多かった。そのほとんどは「それは後にしてくれ」と返事することばかりだ。「あの時僕が提案したのに却下した」とかいうM社社長は、要するにそんな雑音を言っていたに過ぎない。物事にはやるべきタイミングというものがある。いくら「いい意見」であっても、聞くべきタイミングとそうでないタイミングがある。

「序」にも書いたように、当初

私のやる気はゼロよ！

なプロジェクトだった。とは言え、結局選択肢は「Yes」か「はい」しかなかったのだ。そうなれば、成功への最短コースだと信じる道を見い出したら、「助言という雑音」はスルーして走るしかない。仮にLarryが言うような、「鼻持ちならないような傲慢さ」を、持ち合わせていなくても、それがあるかのようにふるまうということは、プロジェクトを失敗させないためには重要なスキルだ。

成長するためには「謙虚さ」は大事なスキルだ。それはいつであっても忘れてはならない。しかし、プロジェクトをやり通すためには、謙虚さよりも傲慢さが必要になる。なーに、プロジェクトをやり通せばそれなりに成長する。プロジェクトをやっている最中くらい謙虚さを忘れてしまっても、成長が止まることはない。優先されるべきは、プロジェクトの成功だ。

PS.

*1 Matzのコメントを見るとわかるように、本人はその旨を言っていないらしい。とは言え、私はそう言われたと認識しているので、そう伝えた人がいるということだ。その当時の状況を考えると、「業務で使った実績」を求められていたことも事実なので、かなり高い優先順位で採用候補に入れていた。あるいはアプリケーション開発が難色を示したことを、そう伝えられたのかも知れない。「Ruby」についてはかなり後になって、また話題に上る。「実績」についてはdot COBOLも提携絡みで求められていたので、これはこれで採用圧力があった。これも後に再燃することになる。

PS2.

頭の悪いtweetがあるようだが…

昨日今日プログラムを始めたひよっこにとっては有史前だろうが、2000年頃Rubyがどういったステータスだったか、またGUIの世界がどんなものだったか思い出してみろ！ まだRailsもなければAJAXもない。ブラウザは互換性がまるでない。おまけにパフォーマンスもそんなに良くない。そんな時代に、どうやったらRubyでこの規模の業務システムを常識の工数で作ることが出来たか。

今から作れと言われたら、確かにこんなことはしなかっただろう。でも、当時の現実的な解としては、こうやるしかなかったのだ。