Q:大阪城を作った人は誰でしょう？

A1:豊臣秀吉

A2:大工さん

当然どっちも正しい。違いは視点であって、どっちがなくても成り立たない。ただし、豊臣秀吉は「作者」とは呼ばれない。「作者」は名もなき大工さん。

まぁそういった意味で、「OpenCOBOL」の「作者」は私ではないのだけど。

お知らせ : 【プレスリリース】OSS COBOL支援プロジェクト立ち上げ

作者じゃないから「仁義」とかいらないけど、「声」くらいはかけて欲しかった。

OpenCOBOLの開発の経緯は、以前に書いた。

ORCAのアーキテクチャ(言語とデータベース)

この中から来たもので、dot COBOLがオープンな処理系でなかったので、しょうがなく開発してもらったものだ。プロジェクトのために言語処理系を作るとか、正気の沙汰じゃないんだから。それもまぁ、西田君とゆースーパーハカーがいたから出来たものなんだけど。そう、「作者」は間違いなく西田君だ。

元々はORCAから始まったプロジェクトなんだけど、いろんな経緯から今は他の人達がやっている。それで続いているのだから、まさしくFLOSSのエコシステムの成功例だ。まぁ、COBOLなんで地味なんで、話題に上ることはないのだけど。

ってことで、開発の初期には私はタッチしているし、「やる」って意思決定したのも私なのだけど、今は赤の他人が続けているとゆーソフトウェアなのだ。

今となっては私自身COBOLでコードを書くことなんてないんで、本当に他人なんだけど、いろいろ因縁もあるので、それなりに思い入れもある。COBOLの規格に関わる「ボランティア」を甘んじで引き受けているのも、その「因縁」でもある。

とは言え、私が何らかの権利が主張出来るかと言えばそんな権利は全くないし、別にその権利が欲しいというわけでもない。てーか、そんな権利があっても何も価値がないってことはいろいろ経験済みだから、欲しがる価値もない(*1)。そういった意味では、

売ってしまった商品

と同じようなものだ。「売ってしまった商品」ってのは、もはや自分のものではない。買った人のものだ。いや、別に直接それで金もらったって訳じゃないよ。感覚的にそうだってこと。それもまぁ、かなり前に売ってしまって、売ったとゆーことはどうでも良くなってるくらいのものだ。

そーゆーわけで、私には何の権利もないし、そういったものを主張するわけでもないけど、いきなり知らないところで

お知らせ : 【プレスリリース】OSS COBOL支援プロジェクト立ち上げ

とかやられると、もにょもにょする。「仁義」とかいらないし、求められる立場ででもないし、いろんな意味で「今さら」でしかないから、そーゆーのはどうでもいいんだけど、「声」くらいはかけて欲しかったなと。「権利を持たない」ってことと「縁がない」ってとは別のことだからね。いくら「売ってしまった商品」だと言っても、それなりに思い入れがあるものだから、粗末にされると残念な気持ちになるよね。もう売ったこと自体忘れていたってね。そういった感情と同じだと言ったら、ちょっとはわかるかな？ まぁ、どこかの人達みたいに、著作が裁断されて心痛める程、豆腐メンタルじゃないけどさ。

ってこともあるけど、「WG」の面子に某社とか、某プロジェクトの関係者とか全くいない風味なのが、実は一番もにょもにょする。まぁコンソーシアムの「会員」じゃないからとか、お願いしたけど辞退されたとか、そんな事情もあるのかも知れないけど。さらに、

なんであんたらがおるの？

みたいな会社が並んでるのが不思議。そういったのを見ると、どうもこの組織の人達って、FLOSSに対して

作るよりも消費するもの

と思ってるんじゃないかと。だから、オリジネータとゆーかそのあたりにいた人達を軽視してるんだろうなと、納得してしまう。昨今のウェブサービス系の世界では、FLOSSに直接コミットするのがトレンドだと言うのに。

何をオープンソースにするべきか（1）

「井戸の水を飲む人は井戸を掘った人への感謝は忘れない」とか言うものけど、こと日本のFLOSS界隈の人達は、

ちょっとでも離れると過去の人にして忘れてしまう

ものなんだよなぁ。

まぁ、やるイベントが「勉強会」みたいなノリであるなら、どうでもいいし、大いに勝手にやればいいことだけどね。今回のはどうもそうではないようだ。

*1

何かと言うと権利を欲しがる人がいるけど、権利ってのはたいてい「責任」がついて回るので、無闇に権利など欲しがるもんじゃない。自分が主体的に行使する予定のある権利なら、持っておく価値があるのだけど、そうでない権利は「責任」とゆー面倒臭いものだけついて来て邪魔なだけだ。

PS.

誤解されぬように言っておけば、話を「通してくれ」と言いたいわけじゃない。そんなことされる立場じゃないし、されても何も出来んし。現実にされたとしても、「いや、それ私に言われても」とか言うしかないんので、あまりポジティブな反応も出来ない。でも「声」はかけて欲しかった。それなら、「勝手にすれば」から「何かあったら言って下さい」まで、いろんな反応が出来た。何もしなくても、ここで告知するとかくらいしたかも知れない。

今回は情報を知った時に(手違いとは言え)、参加が締め切られていたんで、コミットとかする余地すらなかったとゆーのが、まことに遺憾であった。まぁ、今さら何か言われても「知らん」って言うしかないけどね。

PS2.

ある筋からのタレコミによると、日立ソリューションズの担当者はこのエントリのことをご存知らしい。だったら何かアクションあってもいいと思うけど。完全スルーなんだな。まぁ、謝られるスジアイはないので謝られても困るし、勝手に怒ってるだけなんで、どうにかなるものでもないけど。

たださ。FLOSSつーかソフトウェア全般に言えることなのだけど、こういった「怒り」を持つことってのは、10年に一度出来ればラッキーな類の「怒り」なんだよ。たいていは、怒ることすら及びもつかないのが普通だ。消費者視点では「FLOSSはバザールモデルで選択肢豊富」ってのは真理だし良いことだし、生産者もそれで助かっている部分はあるんだけど、生産する側からすれば、

それなりに手間と時間をかけた一品

なのだよ。それはどんな「クソみたいなソフト」でも同じだ。

素人が手間かけて作ったラーメンより、インスタントラーメンの方が、たいてい旨い。食う方からしてみれば、インスタントラーメン食う方がマシなことはよくある(だから私はラーメンは作らない)。消費者視点で言えば、「インスタントラーメン」を選択するのは当然のこと。でも「手間かけて作ったラーメン」ってのは、作った人の思いがある。消費者にとってはそんなもんはどーでもいーし価値とは関係ないものだけど、「粗末」にされたら生産者は気分が悪い。そのことを謝られたところで、「至らぬ自分が悪い」ということがより明かになってしまって、ますます凹むだけ。

今回は前回書けなかったDebianを使っていることについて。

Debianはマイナーなdistroである。なんでそんなマイナーなものを好んで使っているかについて否定的な声はよく聞く。

Debianを採用したのは、

• ネットワークアップグレード
• コミュニティベース
• 程々にマイナー

という理由からだ。

ネットワークアップグレード

今はたいていのdistroはわりと簡単高機能なコマンドで楽にアップグレードが出来る。それも、配布媒体の類は不要で、ネットワークで出来る。しかし、このプロジェクトが始まった当時、それが可能なのは事実上Debianだけだった。ほとんどこの一点だけで、他のdistroは採用の余地がなかったのだ。

ソフトウェアにバグはつきものだ。いわゆるセキュリティアップグレードの類も、ちょいちょい行う必要がある。また、我々が作るシステムだって虫は当然いる。また、バグの類がなくても、レセプトシステムには「改正」という問題がつきまとう。半年に1度はマスターやプログラムの更新が必要になる。とにかくそのような時、一々アップグレード用の媒体を配布して… とやる体力は我々にはない。また、ユーザ数がどんどん増えて行った場合、仮に頑張って媒体を作っていても、末端のサポートはどこかで破綻することになる。物理的な媒体のハンドリングも厄介なら、人が直接動くような「作業」があるのも厄介だ。

もちろんある程度規模の大きな変更があった場合、無人で作業をするのは危険なこともある。そういった場合はしょうがないが、普段使っていないソフトウェアの軽微なセキュリティアップグレードの類までそれをやるのは、気乗りしないエンジニアだっているだろう。ところがそういったところに限って穴をつつかれて… ということがあるのは、それなりの経験を積んだエンジニアなら経験的にわかっているはず。だから、どんなに軽微に見えるセキュリティアップグレードであっても、やらないわけには行かない。そういった時には「リモートから作業」というようなことをしたいだろう。

当時、それが確実に可能なdistroはDebianだけだったのだ。我々がDebianを選択した直後くらいから、いろいろなdistroでも可能になったのだが、それからしばらく後も安心して使えるという程のものではなかった。今だったら「あれも、これも」なのでDebianでなければならないという強い理由もないのだが、当時はそうするしかなかったのだ。

コミュニティーベース

当時、distroは群雄割拠の時代だったと言っても過言ではない。また、ちょうど「Linuxバブル」の頃でもあったから、様々なdistroが商用化されていた頃でもある。ちょっと前にはRed Hatの日本法人がどうだこうだとガタガタしていたし、Turboがどうだこうだとか

——— (検閲により削除) ———–

まぁそんなわけで、distroを選択する時には細心の注意が必要だった。特に商用distroはいろいろ浮沈が激しいと共に、技術者が渡り歩いていたりして、「これなら絶対安心」という類のものはなかった。このしばらく後にRed Hatがdistroの扱いについてコロコロ方針転換をしたのだが、そういったことは「起こりうること」だと認識していた。何しろdistroについてはまだ確実なビジネスモデルは存在していなかったから、商用なものは何が起きてもおかしくなかったのだ。

そういったわけで、コミュニティーベースのものを選択するのが無難だろうという結論になった。その時、そこそこ実績があって、安定もしていて、コミュニティがしっかりしているのは、結局Debianだけと言っても過言ではなかった。個人ベースのdistroは論外でもあったわけだし。

程々にマイナー

これはいわゆる「ヲタク避け」だ。

当時でもRed Hat系の情報はネットでも書籍でも、それこそ大量にあった。ところが悪いもので、大量にあるということは玉石混交ということでもある。今だってRed Hat系(rpm系)distroの入門書には、平気で嘘が書いてあるものや、説明を省き過ぎなものが少なくない。そうなると困るのは、ちょっといじってわかったつもりになってしまう人を大量に作ってしまうことだ。なまじRed Hat系のdistroは出来が良かった(と言うか初期設定項目が少ない)せいで、全くの初心者が本の解説(それも間違いを含んでいたりする)を読んでもインストール出来てそこそこ使えたりする。ここで勘違いの余地が出来てしまう。

確かに、自力でレセプトシステムの導入が出来て、それで安定確実に使えるのであれば、敷居は低ければ低い程良いだろう。しかし、日レセのシステム自体がそれ程信頼性が高くない上に、あやふやな知識でいじり回されてしまったら、安定とか確実なんてことは不可能だ。これからしばらく後になって、「インストールマニュアルの通りにキーを打ったら入った」という程度の品質になったのだが、初期はそんなに甘いことはなかった。だから、トラブルは当然起きるわけなのだが、そのトラブルシュートが出来ない人には使って欲しくなかった。Debianはdistro自体が敷居が高いお陰で、日レセインストール以前で挫折する人も少なくなかったので、それが初期にはフィルターとなってくれた。

そんなわけで、程々にマイナーなdistroであるDebianは、「ヲタク避け」として役立ってくれた。まぁ正直なところ、これは意図したことではないし、結局「やる人はやる」ということがあって、Debian Users MLでは随分と迷惑をかけてしまっていた(る)ようだが。

まぁそんなわけで、基盤となるdistroはDebianということになった。

技術的には、特にミドルウェア的には、ソースから入れることを考えれば、何もDebianでなくても問題なく動く。開発環境だって、私のところはunstableの上で開発して、stableの上でテストしてからリリースに回す。MONTSUQI自体はMac OSXの上でも*BSDの上でも動くし、64bit環境でも動く。その程度にはポータブルに作ってある。「じゃあその上で動く版も出せ」という声はあると思うのだが、これだけの規模のソフトウェアを「リリースする」というのは容易ならざる作業だ。

本当はUbuntuの方がバージョンの安定は上のような気もするし、Macで動かして欲しい人は少なくないだろう。とは言え、我々にはそこまでのマンパワー、あるいはそれを確保する資金がない。「動かせる」と「提供出来る」の間には、非常に厚い壁があるのだ。せめて、末端の「技術者」が普通にオープンソースなものを扱える程度のスキルを持っていてくれれば、リリースする側もいろいろと楽になると思うのだが。

ORCAにはDebianを使っている。この辺もよくつっこまれるところだ。

そもそも、なぜORCAはLinux上かということについても説明が必要だろうと思う。これには

• 技術的理由
• 政治的理由
• 営業的理由

がある。

技術的理由

当時、少なくとも構想の上では、かなり大規模なネットワークが想定されていた。元々、当時想定していた医療機関は「内科の開業医」だった。これは「内科の開業医」が日本で一番多い医療機関だからだ。ボリュームゾーンを攻めるのは、この手のリソースに限りがあるプロジェクトでは当然のことだ。とは言え、医師会員は様々な専門科があり、医療機関の規模も小さなビル内診療所から大病院まである。このプロジェクトがコケない限り、そういったものを全てカバーするという話になるであろうことは、容易に想像出来た。

また、ORCAは「タダのレセコンプロジェクト」ではない。元々がネットワーク化のためのプロジェクトであり、その構想も「全医療機関のネットワーク化」という壮大なものだった。「全医療機関」が現実か妄想に過ぎないかは我々の知るところではなかったが、つまりはそれくらいの規模のことを考えなければならないということだった。仮に1割の医療機関を対象にしても、5000ユーザのネットワークだ。

そういったものをローコストに実装するには、何らかのOSSなUNIX系のOSでなければ、原因不明の障害の調査が難しかったり、対処が困難だったりということを予見した。当時のLinuxは、今と違っていろいろな点でイマイチではあったのだが、ちょうど大手メーカがいろいろな形で参入し始めた頃でもあったので、そういった「商用」的な部分でBSD系に対してアドバンテージがあった。

政治的理由

元々、医療機関はITに疎いところが多かった。そのため、事実上の必需品であるレセコンはわりとメーカのいいようにされて来た。一番酷いのはリプレースをする時のデータの移行について、リプレース元のメーカ(ベンダ)は非協力的で、うっかりリプレースでもしようものなら、手作業でデータ移行させられたものだった。

そもそも、そういった大袈裟なことでなくても、自分のところのデータを自分たちで好きに加工したり見ることが出来なくされていたということで、ちょっとITのわかる医師にとっては

自分の持ってる医療情報が使えない

というのは、不快を通り越して怒りを感じるものだったらしい。そういったことで、「メーカ」に対する恨みはハンパなかった。と同時に「プロプライエタリ」に対する警戒感も強かった。

時代はちょうど「Linuxバブル」なることが言われる時代でもあったので、「反プロプライエタリ」の代表であるLinuxに対する期待は大だったし、また説明も楽だった。「インストールした環境をまるっと渡してもライセンス違反にならない」というのも、いろんな意味で好都合だったのだ。

営業的理由

これについて私はあまり細かいことを知らない。なぜなら、以前にも書いているように、私は政治家や営業というより「技術者」としてのみタッチしていたからだ。

とは言え、その時の私の紹介のされ方は「日本Linux協会会長の」という枕詞がついていたので、営業をしていた人達は「そんな人を押えてるんだぞ」と言いたかったようだ。また、ドットコム・バブルの最中でもあったので、(今はなき)VA Linuxや(今はなき)Linux Careのように

Linuxをネタに子会社上場

とか考えていたフシもあって、「Linuxにポジションを持つ我々がLinuxで大規模システム開発」ということで売りたかった(実績を作りたかった)ということもあったようだ。

まぁそんなことで、諸々の背景を持ってORCAはLinux上のシステムということになった。

このことには、いまだに賛否ある。特にインストールするのにそれなりのスキルを要求されるということに対してはネガティブな意見を持っている人が多いようだ。これについては、現在ではますますナンセンスな主張であると思う。

そもそも、「レセコンシステム」という点だけを取っても、そうそう気楽に入れて欲しいものではない。なぜなら、レセコンシステムというのは

医療機関の基幹情報システム

であるからだ。つまり、止まるとか壊れるとかということは、原則的に許されないシステムだということだ。もちろん導入前には手作業でやっていた業務なのだが、一度システム化してしまえばもう手作業に戻ることは困難だ。「レセコンやめて手作業にします」と決定をした上であれば、マスタを紙に落として… という準備期間が設けられるが、止まったとか壊れたとかいうことだと、そういった情報には一切アクセス出来ない。だから、止まるということは許されない。

となれば、それなりに覚悟をして入れる必要がある。そういったことを考えれば、高々「インストールが簡単」というようなことは、全体の手間から見れば誤差のうちでしかない。事前準備、移行作業、運用開始などに係る手間の方がずっと大きい。下手にインストールのハードルを下げてしまうと、そういった覚悟なしに入れられてしまう。いや、入れるのは親しんでもらうという意味で良いことなのだが、そのまま運用に入られて後からギャーということになってもらっても困るわけだ。いやいや、別に後で困ることになっても、

Your own risk

ということでやってもらっていれば良いのだが、医師会員にしてみれば「自分たちの会費で開発したシステムなんだから」ということで、「保証」を求めて来る(*1)。というような実際上の問題もひっくるめて考えると、覚悟のない人には入れられない程度のハードルは必要だと考えている。今となっては、技術的ハードルは仮想化とか使えばいくらでも下げられるし、実験的にはMacやWindowsの上でも動くのだが、優先順位の低い課題になっている。本当は「つぶクリ」のことも考えれば、もっとハードルを低くしたいという気持ちはあるのだが、サポートセンターやスレの状況とかを見る限りでは、これ以上ハードルを下げることは、マクロ的には

百害あって一利なし

になってしまう。

長くなってしまったので、Debianを選択した事情はまた次の機会に。

*1 いわゆる「オプソ業界」な人達からは信じられないことであるが、ORCAは保証が要求されてしまうシステムなのだ。確かに「基幹業務システム」であるから、無保証というのは言いにくい。我々の常識から言えば、「OSSで保証が欲しけりゃ業者を使え」ということになるのだが、なぜだかORCAの世界ではそれが通用しない。また、妙に「いい格好しい」の人がいるため、「日医が出すからには保証が必要」みたいなことを言ってしまう人が少なくない。そういったこともあるため、レセプトシステムのアプリケーションに関しては、「OSD準拠でない」ライセンスになってしまっている。

あくまでも私見ではあるが、この手のソフトウェアにOSD準拠なライセンスを適用するのは、運用的に難しい。何らかの「責任」の所在を求めてしまうと、OSDの想定を外れてしまうのだ。本当は「ソフトウェアはフリーだけど無保証」と言い切ってしまって、サポートは金を取るようにするべきだと思うのだが、「いい格好しい」の人達が我田引水な論理を展開してくれるので、それも難しい。

バックアップをどうするか

これは、元々「バックアップをどうするか」という話があった。ORCAの基本設計では、最初に想定システム構成を決め、その中で安定して運用することを提供することを考えていた。ただしその「想定システム構成」は十分安く構築することが出来なければならない。

「バックアップ」となると、RAIDではダメだ。なぜなら、RAIDでは復旧させるためには、ハードウェアに手を入れなければならない。software RAIDでも少なくともディスクの交換、hardware RAIDだとコントラーラの交換… だから、RAIDはバックアップとは言えない。何にせよ、バックアップと言うからには、

• バックアップは稼働しているハードウェアから切り離せること
• 復旧する自体に手間がかからないこと
• ダウンタイムが極小化させること

という条件がつく。

その当時、マトモなバックアップの手段は、

テープ

であった。書き込み可能なDVDはまだ一般的ではなかったし、信頼性にも不安があったので、この時点では想定していない。ところが、テープは、

高い上に遅い

のだ。下手すればもう1台サーバを用意してもお釣りが来る… さらにローテーションをうまくやらないと、使えないバックアップを作ってしまうし、テープの経年劣化は環境によってはかなり激しい。ということで、その時にひらめいたのは、

サーバを二重化する

ことであった。一見オーバースペックに見える方法であるが、

• パソコンなんて安いもの
• 故障したら壊れた方だけセンドバック修理
• ダウンタイムは短い

という可能性があった。何よりも「壊れたらセンドバック」という修理方法が使えるということは、僻地離島といったサービスにとって厳しい環境であっても、安心して使えるということで意義は大きい。しかも、安いパソコンを使えばコストダウンも出来る。

データベース二重化の実現方法

問題はこれをどうやって実現するかであった。

当時、データベース(PostgreSQL)を二重化するためのソフトウェアは、これと言って決定版がなかった。どれもが

帯に短し

で、「襷に長し」なものはなかった(「襷に長し」なら切って使えばいい)。つまり、「とりあえず実装しました。いろいろ機能不足がありますが、その辺はうまくなだめて下さい」という状態で、どれを選んで良いか判断に苦しむものだった。今となれば「あれも、これも」の状態なのだが、「当時」はどれが使いものになって行くかすらわからなかった。

この時、選択を誤ると「開発元が開発を放棄したら、自分たちでずっと面倒を見る」ことを考えないといけない。それはそれで良いことなのだが、我々がやりたいことは、

使いやすいプラットフォームでアプリケーションを作る

ことであって、「これから発展するであろう他人様の開発したOSSにコミットする」ことではない(繰り返すが、このプロジェクトはOSSの実験プロジェクトではなく実用品を作るプロジェクトだ)。だから、「有りものでやれるのならそれを使うが、有りものの前途がわからなかったら手を出さない」という判断になる。ここで他人の開発したものを使わないという判断をすれば、

• 開発元の方針や進捗にプロジェクトが左右されない
• 自分たちに必要な機能だけを実装すればいい
• 自分たちの方針でプロジェクトが動かせる

となる可能性がある。

自分たちでやるメリット > 他人が作ったものを選択するメリット

であるなら、自分たちで作った方が安くて速い。特に「帯に短いものが多数」みたいな状況だと、どれを選ぶかというのは大変難しい決断を要求される。

他方、データベースエンジンについては、PostgreSQLを使うことにそれ程強いこだわりのようなものはなかった。MySQLが使いものになればそれを使えれば良いし、Oracleを使いたい人がいたらそれでもいいだろう。MONTSUQIのデータベースアクセスのアーキテクチャは、自前のO/Rラッパのようなものがあって、アプリケーションはその上での操作しかしないから、データベースエンジンでアプリケーションは左右されない。そのメリットを生かすためには、「PostgreSQLに特化した二重化ツール」は使わない方が安全だ。PostgreSQLはいいものだとは思うが、縛られたくはない。

処理レベルでの二重化

二重化には他の方法もある。複数のサーバに独立したデータベースとアプリケーションを用意しておき、処理要求は両方のサーバに分枝して行うということだ。これだと、

ダウンタイムの極小化

が実現出来る。サーバ自体がコケても、フェイルオーバしてやることにより、事実上のダウンタイムが0に出来る。つまり、完全なフォルトトレラントが実現出来る。せっかくサーバを二重化するんだから、この方法を取れば「コケてもそのまま業務が続けられます」と言うことが出来て、なかなか格好もいい。ダウンした後の対処も、「ダウンしたサーバを取り外すだけ」で済むので、運用にも都合がいい。

こういった良いことづくめの方法ではあるのだが、ORCAという環境で使うということを考えると、思わぬところに落とし穴がある。

• フェイルオーバしてしまうと、故障に気がつかない
• 「サーバ2台」とは言うもののクライアント兼用だ
• 様々な理由でデータベースの内容はくい違うことになる
• ネットワークだけ泣き分れることはしばしば起きる

ということが起こりうる。特にマズいのは「故障に気がつかない」ということだ。もちろん故障が起きたら何らかのアラートを上げればいいわけだけど、このシステムは

システムオペレータ = エンドユーザ

なのだ。だから「動いているから気にしない」みたいな判断をされかねない(実際、サポート要求の内容を見るとその手のことをやる人は、私が想定した以上に多い)。だから、「壊れたらとりあえず止まってしまう」という乱暴な方法で「エラー通知」をしなきゃいけない。となると、せっかくのフォールトトレラントが意味を持たない。

そんなわけで、処理レベルの二重化は設計の中には入れていて、コードや動作もその影響を受けているのだが、実際には全てを実装するには至っていない。大病院やSaaSというような話が一般的になれば、完成させようと思うのだが、今のところはやっていない。

実際の二重化

そんなわけで、ORCAでの二重化は、

• データベースのレベルで
• 自動のフェイルオーバなしで
• 自前のコードで

実現することとなった。具体的には、データベース層のリクエストを複数のサーバにリダイレクトする機構を自前で設け、複数のデータベースに同じ更新を行うことによって実現されている。よく「○○を使えば云々」という人がいるし、勝手にそれを使うのは構わないし、うまくやればその方が信頼性が確保しすくなると思うのだが、本体の機能としてそれに頼るわけには行かなかったのだ。

ミドルウェアをどうするか

実は、かなり後まで(と言っても初期なんだけど)、あまりミドルウェアに力を入れるつもりはなかった。というのは、ミドルウェアに力を入れ過ぎることは、アプリケーション開発のプロジェクトでは、邪魔になることが多いからだ。

特にこのプロジェクトのように、「とにかく成果らしいものを早く出す」ことが求められていると、ミドルウェアをゆっくり設計して… というのは、むしろ邪魔だからだ。なので、「とりあえずのデモ」の時には、私のミドルウェアは一切使っていない。デモが成功すれば、本格的な開発に入れるから、そのための用意として開発は始めていたが、それにしてもあまり複雑なものを作るつもりはなかった。

通常、ミドルウェアを新しくすると、アプリケーションは書き換えになる。また、ミドルウェアのAPI設計がちゃんとしていないと、アプリケーション開発の不安要素になるので、このあたりは本当はちゃんとしておかないといけない。幸いなことに、アプリケーション開発の連中は昔の職場で外注で働いていたり、元の同僚だったりしたこともあって、「その当時」の私のアプリケーションプラットフォームを知っている。なので、それを使うことにした。もちろんその時点ではまだ陰も形もないものではあるけれど、仕様は存在していたしそれは十分枯れていたので、仕様説明は、

某「プラットフォームはあれですか」
私「そうだ」

という、たった一言の会話で済んでしまった。もっとも、その時点では「あれ」はないのであるが、「あれ」を使うつもりでプログラム設計をするということになった。

「あれ」

「あれ」というのは、私が昔の会社に勤めている時に使っていた、富士通AIM DB/DCのラッパになるミドルウェアだ。元々、「画面単位でREAD/WRITE」を基本としたトランザクションモニタであるAIMを、イベントドリブンにアプリケーションが開発出来るようにしたもので、オリジナルのコードは富士通名古屋支店の人が作ったものだ。新人の頃の私はそのプロジェクトで名古屋テレビの放送システムを作っていた。

READ/WRITEを基本とした処理だとどうもコードが汚くなりがちなのだが、イベントドリブンにしてしまうと論理もすっきりと書きやすい。そういったメリットもあったので、当時の上司が「輸入」して、いろんなプロジェクトに使っていた。当時の私は主にメインフレームの開発だったのだが、その後オフコンでのシステム開発をするようになった時に、「あれ」は移植され、さらに他の環境にも移植され… ということで、私が業務で主にCOBOLでの開発をやっていた頃は重宝に使っていたものだ。

途中、著作権の問題で一度コードはクリアされてしまっているし、別のプラットフォームに移植する時もほぼ書き直しになっているため、コードそのものの継承関係は全くなかったのだが、APIやアーキテクチャは同じままでずっと持ち歩いていた。とは言え、ORCAのプロジェクトが始まった時点ではそのコードはないので、記憶に頼って作ることになる。でもまぁ「あれ」のインターフェイスで作れるというのは、アプリケーション開発の連中にとっては有難かったはずだ。

「あれ」on dotCOBOL

その当時、それ程複雑なミドルウェアにするつもりはなかった。そもそものターゲットが「内科の開業医」なので、端末もせいぜい2台もあれば十分だ。だから、凄く高度なトランザクション管理が必要でもないし、高負荷に耐える必要もない。だから、当初のデザインでは

端末を起動する毎にアプリケーションを起動する

という、ごく普通のことを思っていた。その程度であれば、イベントドリブン云々のところは、ほとんどの処理が画面インターフェイスの操作になるし、データベースアクセスに関しては、定型的なことで済む。だから、「ミドルウェア」とは言うものの、単なる「アプリケーション呼び出しフレームワーク」で良いはずだった。

またその場合、C <-> dot COBOLのインターフェイスをどうするかという問題があったのだが、いろいろ実験をしてなんとか使えるものが出来た。なので、ほとんどのコードはCで書き、dot COBOLのアプリケーションモジュールをCALLする部分だけをdot COBOLで書くことに。

とりあえずテストプログラムがちゃんと動くようになったので、これでいいと満足していた。これ以上の工数をかける余裕は私にはない。ところが実戦投入となると、これが甘い見通しだったことを思い知らされる。

アプリケーション開発チームの要求

アプリケーション開発では、もっと高度な処理を期待していた。メインフレームのトランザクション管理にある—とゆーかAIMにある—諸々の機能が使えることを期待していたのだ。一番大きかったのは、

アプリケーションをいくつかのグループに分ける

ということだった。元々、この機能は負荷分散のために実装されたらしいものだったのだが、プログラムを論理的に整理するにも都合がいい。

ところが、それを実装するとなると、「1ユーザ1プロセス」という設計では、難しくなる。となると、リソースの有効利用という観点から、「複数ユーザ1プロセス」か「複数ユーザ複数プロセス」という設計にならざるをえない。いずれにせよ、何らかの形で1つのプロセスが複数のユーザからの要求を処理出来るようにしなきゃいけなくなり、セション保持の論理がまるっきり変わる。つまり、

本格的なトランザクションモニタ

を作ることを要求されることになったのだ。

とは言えさすがに、それは荷が重い。そもそも、私はこのプロジェクトに関しては「立ち上げだけしてしまって、あとはよしなに」というスタンスでいた。また、常識的に考えて、いくら開発環境がないとは言え、アプリケーション開発のプロジェクトで本格的にミドルウェアを開発するのは、ありえないことだ。それに、ここでさらに高機能なミドルウェアを作るということは、それだけアプリケーション開発の足を引っぱることになるし、それはまたリリースを遅らせる元になる。さらに、バグの量はコードの量に強い相関があるわけだから、信頼性の確保だって馬鹿にならない。

他方、アプリケーションは既にかなりの量作ってしまっている。今さら改めて書き直すというのは、その工数が馬鹿にならない。ミドルウェアを改修するだけであれば、私一人が死ぬ思いをすればいいのだが、アプリケーションを書き直すとなると、10人くらいが作業しなきゃいけない。つまり、どっちが工数が少なくて済むかと言えば、

私が泣く方が安い

わけだ。また、「いずれ病院システムも」という話もくすぶっていたので、いつかは本格的なトランザクションモニタが必要になり、オープンソースで調達して来なけりゃいけない。そういった諸々のことを考えると、結局私が泣く方がいいということになり、要求されていた仕様を入れたミドルウェアにすることになってしまった。

そんなわけで、当初は単なる「アプリケーション呼び出しフレームワーク」だったはずが、アプリケーション側からの要求に合わせる格好で「本格的なトランザクションモニタ」になることになってしまった。

「ORCA」の意味

ORCAは日本医師会のIT化プロジェクトであり、医療機関のIT化ネットワーク化を目的としている。実際に何に使うかということは、日本医師会の公式の発表等を参照してもらうといい。一例を挙げるなら、医療機関の経営状態を把握して、診療報酬改訂がどんな影響を与えるか調査するとかという経営情報、どんな疾患が多いかという疫学的情報、そういった情報を収集して、医療に役立てようということだ。

だから、「レセコン」というのは、そのためのポータルに過ぎず、これがORCAプロジェクトそのものではない。レセコン部分だけを指す場合、「日医標準レセプトシステム(略して日レセ)」という名称である。

この文は「ORCA」についてであり、日レセだけの話ではない。

ORCAにおけるIPv6

ORCAはネットワークの設計上、IPv6を基本に置いている。もちろん現実のネットワークであるから、トラフィックのかなりの部分はIPv4で行われているのではあるが、ORCAのORCAとしてのネットワークはIPv6を使うというのが基本的なデザインである。これを実現するために、日本医師会として/32のアドレスブロックを保有している。これは少なくとも当時は、ユーザが保有する世界最大のブロックであった(今はどうだか知らない)。

IPv6の採用は、当時でも今でもかなりチャレンジなのではあるが、ORCAとしては必然だったのである。

医師会の構造

医師会には、「日本医師会」の他に、都道府県単位である「都道府県医師会」と、さらに小さなエリアを単位とする「市町村医師会」がある。また、さらに細かい単位の医師会もある。これらの医師会の間には

組織的上下関係はない

のである。つまり、「日本医師会」の支部が「都道府県医師会」なのではなく、あくまでも並列な組織なのだ。ただ、支部的側面が全くないかと言えば、「日本医師会の代議員」は都道府県医師会から選出される… という関係があるのだが、基本的に独立した法人格を持っている。同様な形態を持つ組織は、「社会福祉協議会」「弁護士会」「農協」などがある。これらも地域組織と全国組織の間に直接の上下関係はなく、独立した法人格を持った組織である。

それぞれが別の組織だということは、組織には組織の政治があり、組織同志が友好的かそうではないかは、それぞれの組織の間の関係によって決まる。つまり、「○○県医師会と××県医師会は仲が悪い」というようなことがあったりする。

このことは、ネットワークを組む時に障害となりやすい。

たとえば、○○県が自前でネットワーク(VPN)を組んでいて、××県のネットワークと接続する場合、相互に仲が良ければ話は早いのだが、仲が悪いと政治的にも技術的に面倒なことになる。

VPNの問題

既に一部の地域医師会では、VPNを使ったネットワークが始まっていた。当初は、これをさらに進め、地域医師会のVPNを相互接続するという案が有力であった。

このようなネットワークの相互接続の場合、ポリシーの整合が必要になる。ネットワークの運用ポリシーが同じでないと、無用な混乱の元になる。また、VPNの接続は「相互接続」であるから、接続する相手毎に約束や設定を行う必要がある。

このようなことを行う場合、事前に調停が必要になる。うまく擦り合わせておかないと、後々厄介の元である。ところが、このようなことは往々にして政治問題化しやすい。政治問題になってしまうと、エンジニアがどう頑張っても解決出来ない問題になってしまう。

技術的にも、それぞれのネットワークのIPアドレスやルーティングに厄介を起こす。元々別のネットワークだったのだから、IPアドレスだってそれぞれの都合で振られている。接続するVPNの数が知れている時には相互接続の手間も知れているが、ある程度を超えると加速度的に手間が増える。

というように、「医師会」というものがどんなものかを考えた時に、VPNを相互接続してネットワーク化するというのは、非常に困難を極めることが予想された。技術的な問題だけならまだしも、政治問題が絡むとお手挙げである。

IPv6という解

そういった話をしている時に、スタッフの一人が、

じゃあいっそIPv6に

という冗談を飛ばした。その時は冗談に過ぎなかったのだが、よく考えてみると実にいい案だということがわかった。いい点を挙げると、

• 相互接続に悩まないで済む
• 議論に政治が絡まないで済む
• アドレッシングに関する問題がほぼ自動的に解決する

ということである。問題と言えば、一般のネットワークではIPv6がサポートされていないとか、機器やサーバクライアントの設定が面倒臭いとかということがあるのだが、いずれも

個々で解決可能な技術的問題

だけである。我々が「政治」に関与する手間を考えれば、技術的な問題の解決だけ考えればいいIPv6は、はるかに問題がない。つまり、

困難な政治問題を技術問題に転換する

ことが出来るのである。作るもの、学習するべきものは増えるが、どうせORCAが十分普及した頃にはIPv6が一般的になるだろうと考え、「妙に苦労してVPNを使うよりは、IPv6の方が手間が少なくて済む」ということで、IPv6を使うという結論になった。

幸いなことに、LinuxではIPv6のサポートが入った頃でもあるし、日本のインターネットも「いっと(藁)」のお陰でIPv6が使えるところが徐々に増えて来た。それでも使えないところには、プロジェクトの方でトンネルを作るための機器を用意することにより、使えるようにした。トンネルの用意はIPv6でなくても必要であることはわかっていたので、用意する口の数の違いだけで済んだ。

ORCAにおけるIPv6は、実験ではない。あくまでも実用のための技術である。いろいろ解決して来た問題はあるが、実験とか研究とかの類ではないため、ただの1枚の論文も書いていない。実用システムを作ったところで論文なんて書かないのと同じ理由である。むしろ、IPv6を実験ではなく実用とするものとして扱ったということが、我々の「誇り」でもある。

UIを考える

「言語とデータベース」でも書いたが、いわゆる基幹業務システムのデータエントリは、

伝票見ながら、高速タッチタイプする

するものだ。これは、昔からEDPなんてものを見て来た人にとっては常識だ。データエントリは、「何をどうやってどこに入れる」ということがあらかじめ決まっているから、途中で打ち間違いさえなければ、画面なんて見ないで「伝票」を見ながらデータを入れて行く。

この時、入力速度を稼ぐために、「画面 -> 入力」というフィードバックはあまり好まれない。だから、「漢字変換」は極力ない方が喜ばれるし、メニューから選択して入れるという類の操作も嫌われる。また、「伝票」は左手に持たれることが多いから、右手だけで入力出来ることが歓迎される。出来ることならテンキーだけの入力がいい。

逆に、画面が綺麗だとかどうとかはどうでも良く、またデータを入れる順序が論理的であるかどうかよりは、伝票に書かれている順番に入れられることが望ましい。早い話が、我々が思う「入力しやすさ」と、実際にデータを入れる人達が思うそれとは、大きな乖離がある。

そういったことで言えば、一番理想に近いUIは、

メインフレームのダム端

なのだ。ただ、これだと入力アシストが皆無で不便だから、もうちょっとマシな入力アシストがあればそれでいい。あとは、そこそこ高速のレスポンスであることが、入力を快適にする。これが現場でデータ入力をしている人達が求める理想である。

ところが、元々のORCAが想定していた「零細の医療機関」では、設備導入の意思決定は、「院長」が行うことが多い(事務方の強いところは、医療事務員が意思決定するところもある)。そういった人達へのアピールも必要のなる。

多くの院長(つまり医師)は、そういった高速データ入力のことは考えていない。それよりは、「一見格好良い」ことや、「わかりやすさ」が重要である。「自分でも使えそうだ」という印象は大事だ。そうなると彼が求めるものは、

いわゆるGUI

だったりする。

つまり、「導入してもらう」ためのハードルを少しでも下げ、かつ快適なシステムにするためには、この背反する要求を満足させるものでなければならない。

dot COBOLのUI

当初、ORCAはdot COBOLで開発をすることを想定していた。

dot COBOLのUIは非常によく考えられていて、これら背反する要素をうまく解決している。いわゆる標準的なGUIシステムとは違うのだが、現代のハードウェア上で「ダム端 + 入力アシスト」を実現していた。見た目はかなりダサいのだが、実用本意で言えば非の打ちどころがない。だから、当初はこれを使うつもりでいた。

ところが、やっている途中にいくつかの問題に当たることになる。

まず当時のdot COBOLはLinux版が作られたばかりなので、完成度に難があった。これについては「業務提携をする」という話のあたりで、「相互に協力して改良して行きましょう」という話になりつつあったので、あまり大きな問題とは認識していない。

それよりも大きかったのは、dot COBOLの画面制御は、COBOLの「SCREEN SECTION」を使うものだったということだ。COBOLがわからない人のために説明すると、このSCREEN SECTIONを使った画面入出力は、個々のフィールド単位で入出力処理を書くことになる。動作はきめ細いことが出来るのだが、これだと

画面制御ロジックをプログラム中に書く

ことになってしまう。オフコンCOBOLで開発をやっていた人達はこれに慣れているらしいのだが、集めたエンジニアはメインフレーム出身の者が多数なので、あまり慣れていないということもあるし、そもそも面倒臭い。まぁ実はその辺はdot COBOLのIDE(?)が適当にコード生成してくれるので、致命的にダメってことはないのだが、後々考えると厄介なことになる。プログラマが面倒臭いと思うことは、品質を低下させる要因であるということとイコールでもある。

集めたエンジニア達は、富士通メインフレーム上でアプリケーションを書いていた人達が多い。富士通メインフレーム上での画面入出力は、「1枚分まとめてREAD/WRITEで入出力」が基本なのだ。だから、その方が慣れているということもあるし、トランザクション管理の単位もわかりやすい。だから出来ればそのようにしたい。

そんなこともあって、「とりあえずデモはdot COBOLのものを使うが、実際のシステムにする時には、READ/WRITEを単位とした何かを考えよう」ということになった。

UIシステムの検討

デモはそうやって乗り超えることにしたのだが、実用を目指したシステムを開発するためには、READ/WRITEを基本としたUIシステムが必要になる。アプリケーションの開発と並行して、そっちの検討を始めることになる。

UIシステムに求められるのは、

• わかりやすく軽快に動くこと
• キーボード操作を基本とし、マウス等は極力避ける
• システムが複雑でないこと

である。この他に、出来れば「画面」はポータブルにどこでも動くのが都合がいい。サーバはLinuxでいいが、クライアントは他のシステムでも動かしたいからだ。

その当時の技術レベルでまず考えられたのはwebである。

これもまた時計の針をその頃に戻してみると、FireFoxはまだリリースしていない頃だ。Netscape Navigatorは4.7が主流の時代である。その当時はまだAJAXなんて言葉も概念もなかったが、NNにはXULというGUIシステムが内包されていた。世の中、イントラネット等でwebを使うことが始まっていたから、まず第一に検討されたのはこれであった。

しかし、その当時のブラウザは非常に重いものだった。「旅費精算をポチポチ打ち込む」くらいのアプリケーションであれば問題はなかったが、「レセプトデータをどんどん打ち込む」という用途には、まるっきり話にならないくらい遅かった。このブラウザの「遅さ」は今現在であってもまだ満足されていない。

また、ブラウザは様々な操作でマウスを使うことを要求されたので、「伝票見ながらタッチタイプ」ということも難しかった。無論その当時であってもJavascriptはあったので、様々な工夫の余地もあったのではあるが、IEとNNでは様々な点で違いがあり、その両方を面倒見るということは当時のマンパワーでは無理であった。

次に考えられたのは、いわゆるC/Sシステムだ。GUIの部分をゴリゴリと書き、ビジネスロジックの動くサーバと通信して動かすというアーキテクチャだ。

これには2つのアプローチがあって、何らかのGUIツールキットを用意して、その上でアプリケーションを書くという方法と、dot COBOLのUIを使ってdot COBOLで書き、それを使うという方法だ。手間を考えると、後者の方が断然いい。

しかし、後者は「そこまで手間をかけてdot COBOLに依存するのか」という議論の結果、やめることになった。そもそも、dot COBOLは「出来れば使いたくないし、機会があれば他のオープンソースな処理系に移したい」という希望があった。これが手間をかける必要がなく使える状態であったなら、「他のもの」を作る工数分が節約出来るからということで、「dot COBOLを使い続ける」という判断も可能であったのだが、「UIのところだけdot COBOLを使い、ビジネスロジックと通信」みたいな手間をかけるくらいだったら、下手に依存すべきじゃない。そういった判断で、この方法は廃案となった。

前者は、つまりUIのところはゴリゴリとCで書くということ。ここはうまく書き方を定型化してしまえば、そんなに工数がかからないだろうということが期待出来た。とは言え、プログラムを書くということはそれだけで工数がかかる上に、ある処理をしたい時にクライアントとサーバとどっちでやるかという役割分担の問題が問題となる。たいていのC/Sな業務システムが炎上してしまうのは、まさにこれが原因だった。また、いかに定型化するとは言え、アプリケーション開発者の中でCでプログラムが書ける人は限られていたので、現実的には無理という結論になった。

そんなわけで、いずれの方法も使えないという結論となった。つまり、「他の何か」を考えるべきだということだ。

glclient/glserverのアイディア

こういった仕事とはまるっきり別に、私が以前から考えていたアイディアがあった。それは、当時の計算機は実は主にGUIにCPUを使っている、そうであれば、GUIの部分だけthin client的に追い出せば、アプリケーション実行の負荷を効果的に下げることが出来るのではないかということだ。これは、日立のIT100という軽量PC(thin client)を貸りた時に、日立に提案したアイディアの1つだ。その当時(1997年頃)は却下されたのだが。

その当時は、XClass95を使い、独自の画面定義体を使うというものだった。画面定義体をサーバから送り、クライアントで画面を組み立て、イベントとデータをやりとりするということで、「C/SでGUIを実現する」ということだった。要するに今時流行りの「リッチクライアント」と同じアイディアだ。

なので、この手のものを実現したら、汎用クライアントを作ってしまえば、後はアプリケーションプログラマに全部渡してしまえる。GUIをC/Sで実現するために、「プログラム」の類は一切書かないで済むだろうという考えである。

問題は、そういった「定義体」の解釈や定義体を作るデザインツールをどうするかということだ。

ところがある日、Matzと世間話をしたいたら「gladeは画面定義のCを出すだけじゃなくて、その定義はXMLとしてはき出される」という話が出た。ってことは、そのXMLを解析することを実現してやれば、gladeで作れる画面であれば定義体として使えるということだ。これで「デザインツール」の問題は片付いた。ついでにいろいろ調べていたら、そのXMLを解釈して画面にしてくれるlibgladeというライブラリがあることも発見した。ってことは、

gladeで画面定義をして、libgladeで表示

してやることを考えれば、解釈からデザインツールまでの一切の問題が片付く。あとは、「通信」を何とかしてやればこの問題は全て解決する。ということで、この方法を採用することにした。

GTKのダメさ加減

簡単なアプリを作って表示をさせてみると、画面が出てくれたので、この方法が使えるという感触を得た。そこでいろいろ作り始めることになる。

ところが、作っている途中や、サンプルをアプリケーションチームに渡してから、ある問題に気がついた。まず第一は、

数値の入力

だ。「伝票入力」ではこれが主だと言ってもいいくらい大事なものなのだが、GTKには数値入力専用のウィジェットがない(たいていのアプリでは文字列入力ウィジェットでやってしまう)。だから、もちろんgladeやlibgladeはサポートしていない。しょうがないので、そういったウィジェットを作ることにする。ウィジェットを作ると、gladeやlibgladeをいじらないといけないのだが、コードを見ているとわりと単純だということに気がついたので、その辺もいじって使えるようにした。お陰で、既存のgladeやlibgladeと互換性がなくなってしまったのだが、まー、それはしょうがない。

その次の問題は、

GTKのウィジェットはマウスを使うことが前提

だということだ。たとえば、コンボボックスでenterすると、リストが開く。そして、それを閉じるにはescするなりマウスを使うなりすることになる。ダム端の常識で言えば、フィールドでenterすれば「入力確定で次のフィールドへ移動」という動作を期待する。仮にそれがダメであってもescやマウスに手を伸ばしたくはない、こういったちょっとした問題は、結構あちこちにあった。

最新のGTKはどうだか知らないが、当時主流だったGTK 1.2系では、この辺は外からいじることが出来ない。しょうがないのでコードをいじって「微妙に動作の違うウィジェット」を作ることになる。数値入力ウィジェットは私が作ったのだが、こういった雑多なものまでは手が回らないのと、仕様がはっきりしているということもあったので、AXEさんにお願いすることにした。なんでAXEさんかと言えば、元々竹岡さん達と付き合いがあったということと、彼等は「式神」を作っていて、GTKの中身に詳しかったということからだ。

まぁそんなことで、いくつかあるGTKの問題は「自前ウィジェット」で解決することにした。その当時既にメジャーだったGTKであっても、こういった「普通の業務システム」に要求される機能はイマイチだったのである。これが、当時のLinuxの開発環境のレベルだった。「GUIなメールソフト」は作れても、「伝票入力」は満足なものは作れなかったのである。

gladeのXMLを使うというのは、もう一つメリットがあった。それは「解釈」さえ作ってやれば、GTKでなくても使えるという可能性だ。

当時考えていたのは、まず「CUI」だった。やはり現場はダム端を望むのだ。いかに分散してGUIを高速に動くようにしても、やはりCUIの高速さには敵わない。だから、「余力があればCUIも」と思っていた。当時のマンパワーでは実現しなかったし、今も出来ていないけれど「やろうと思えばやれる」というのは意味がある。

さらに適当な変換でHTMLを出すことも出来た。これは「Linux以外の環境も端末で使えるように」と言われたことへの答えだ。これも諸伴の事情でORCAでは使っていないのだが、随分と後になって日弁連で使うことになる。また、遠からず私の会社が行うサービスでも使う予定だ。本来はORCAの延長で「診察予約」だとか「健康管理システム」に使いたかったのであるが、それは実現に至っていない。

しばらく後になって、WindowsやMacでもクライアントが実現出来たのは、このアーキテクチャによるところが大きいはずだ。

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でこの規模の業務システムを常識の工数で作ることが出来たか。

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

オタク医者どもが相変らずぐちゃぐちゃ言うのに辟易したのと、勝手なことを言ってまわる某社社長(ここではない)にいい加減「黙れ」と言いたい。かと言って、単にぶーぶー言ってもしょうがないから、忘れてしまう前にちゃんとした文書にまとめておこうと思う。

100の反論よりも1つの事実

が大事だからだ。

序の序

表に出ている公式の情報や見解とは別に、「関係者だけが知っていること」とか、「私だけが知っていること」がある。そのほとんどは、「別に秘密にする必要はないけど、今さら言っても何かの役に立つわけじゃない」ことだ。とは言え、野次馬的にはその辺も面白いだろうから、問題のないことは書くことにする。ただし、守秘に属すること、口を開くと大人気ないというようなことは、やはり口は閉しておくことにする。

また、ここに書かれているのは随分と昔のことである。歴史に関しては、あるいは私の記憶違いのこともあるかも知れないので、それについては適宜修正したいと思う。とは言え、「過去」は美化されることも、結果論で評価されることもあるものなので、つっこみを入れる前に、時計をその頃に戻してからつっこんで戴きたい。また、「○○さんが言ったらしい」の類は、すなわち伝聞であるので、「俺はそんなことは言ってない」ということがあれば、教えて戴きたい。また、歴史に関しては、私の知らない事実も多数あるはずなので、知っている人はこっそり教えてもらうと、これも適宜更新したいと思う。ただ、「歴史」そのものは人によって受け取り方の違うものでもあるので、その辺は留意願いたい。

私の立場

私は少なくともプロジェクト発足当時は、ORCAのチーフアーキテクトだ。ORCAのシステムの骨格となるところやシステムアーキテクチャは私がデザインしたものだ。それが現在のシステム構成やソフトウェア構成に反映している。また、それに基くミドルウェアの開発や選定も、主に私がやったものだ。

また、少なくともプロジェクト初期においてのプロジェクトの重要なポイントでの決定は、私の意見なしには行われなかった。つか、出来なかったはずだ。

とは言え、プロジェクト発足当時の私は、日本医師会から見た立場としては「単なる業者」に過ぎないから、いろいろな意思決定には直接参加はしていない。また、いわゆる「金の亡者」が大勢絡んでいたシステムであったから、私の影響力や私に与えられる情報は極端に制限されていた。つまり、私は「こうやらんとシステムは動かんぞ」と言うことは許されていたし、みんなはそれを聞いて従うしかなかったのだが、プロジェクトの立案やら契約やらに「暗躍」していた人達のことは私は知らされていないし、その辺がどうなっているかは、今もってよく知らない。だから、以下に書くことも主に「技術者」として見聞きし発言して来たことである。

背景

「ORCA」というプロジェクトが始まったのは、2000年の始め頃である。仕事そのものの打診があったのは、まだ1999年だったような気がするのだけど、その辺は実はメールも何もない。なぜなら、「直接」言われたからだ。

関係者のメールを発掘すると、2000年の3月頃にオープンソースでやる云々という話が出ているらしいのだが、私はもうちょっと前に打診を受けていたと思う。そして、その時には「オープンソース」という話はなかった。

私にとっての真実は、こんなプロジェクトには関わりたくなかったから、

断わる口実

として「オープンソースにするんだったらやるよ」と言ったことが元だと思っている。これには「自分の手柄」にしたい人からの反論があるんだろうが、基本設計は「チーフアーキテクト」なる私だ。他の人達が何と言おうと、私が動かなければこのシステムは存在してない。そのアーキテクチャに従って作ったミドルウェアがMONTSUQIなのだ。

既にそれなりに成功してしまった今だったら「あれは俺の発案」とか言う人がいるだろうが、仮に本当にそうであれば、私は関わっていないはずだ。なぜなら、その当時の私の環境を考えれば、他にやる人がいたら私はやることはなかった。逆に私がやったということは、他の誰もが手を下せなかったということだ。

その時聞いた話は、「日本医師会が医療機関をネットワーク化したいと言っている。そのためのポータルとしてレセコンを作りたい」という話だ。私にしてみれば「レセコン」というだけで拒絶反応だ。

それまで、医療システムにはほとんど関わってなかったのだが、「レセコン」というシステムには、

• 定期的にメンテが必要(診療報酬改訂とか)
• 既にマーケット地図が完成している
• 既に枯れたシステムが大量に存在している

という事情があることくらいは知っていた。当時その話を持って来た人が全くその辺のことを理解していなかったとは思えないが、その話を持って来た会社は、なんだかんだ言って「ドットコムバブル」をうまく利用して上場… みたいなことを考えていた会社だったから、ほぼ永続的にメンテが必要なシステムを作って責任を取れるとはとても思えなかった。そうしたら、無責任なシステムになるか、誰かにケツを持ってもらわねばならない。それはシステムエンジニアとして敗北になると思うと共に、よけいな厄介事を抱えなければならないということを意味する。

そもそも、その時のその環境では、「じっくり腰を据えてシステムを開発する」ことよりも、「派手に見える開発計画をぶち上げて、出資を集める」ことの方に意識が向いていた。だからこのプロジェクトの受注元を知る立場から、そういった仕事にはゆっくり関われないだろうと思っていた。

仮にそれをクリアしたところで、既に長い運用歴を持つシステムが大量にある世界で、いかに「日本医師会」というブランドがついていようと、シェアが取れるとは思えない。いくらシステム価格が安くとも、他から移るコストを考えれば、「周回遅れのスタート」なのだ。どう考えても勝負になるとは思えない。それに「これから」開発しようというのだ。どれだけ開発エネルギーを裂くことが出来るかは知らないが、他の歴史のあるシステムに対抗するだけのシステムを作るのにだって随分と時間がかかる。その間に他のシステムだって進んで行く。下手すれば追いつくことすら難しい。

そんな

死亡フラグ立ちまくり

のシステムなんて、いくら金が出ると言われたって受注したくはなかったのだ。そこで、一番「金の亡者」にとって嫌われるであろうマジックワードを使うことにした。それは、

オープンソースにするなら考える

ということ。これなら、当時の業界の状況を考えると、オープンソースでマトモな業務システムが作れるとは、まだ思われていなかったし、そもそも業務システムそのものをオープンソースにしたら何が起きるかは誰も知らなかった。無責任な夢を見る人は大勢いたかも知れないし、それは関係者にもいたけれど、少なくとも「上場のネタ」になんぞはなれそうにもないと思っていた。

正直なことを言えば、当時日本Linux協会会長であった私も、オープンソースで業務システムを作ることに懐疑的だった。つか、その時点では出来っこないとすら思っていた。詳しいことは後のエントリに譲るが、そもそも当時は

業務システムの開発環境

がオープンソースにはマトモなものがなかったのだ。その当時の私の講演でも、「〜必要である。〜を作ることが急務で、それがLinuxの普及には重要なんだ」という文脈はあっても、「〜は既にあるんだから、後はやるかやらないかだ」という文脈は存在していない。つまり、その当時他のもの代替するに十分な開発環境はなかったのだ。だから、この開発環境を用意するところから物事を始めなければならない。それはそれで楽しいことだし、好きな仕事ではあるけれど、これは仕事であって遊びじゃない。また、失敗の許される「研究」でもない。と言うことは、「納期」が存在し、また「完成」を保証しなければならないのだ。

仮にそういった開発環境が用意出来たとしても、アプリケーションプログラマがある程度の生産性を確保しながら使えなければならない。そんなものを納期を設定して出来るはずがない。

間に入った人にはそういったことも含みながら、「私はこの仕事は断わりたい。ただ根拠なく断わっても納得はされないから、こう言うのだ」と説明をしておいた。まぁその話が伝わっていたかどうか私は知らない。何しろ相手方(具体的に誰ということは知らない)からは、

オープンソース大いに結構。それでやりましょう

という答えを引き出してしまったからだ。

その答えは、私まるっきり予想外だった。本来であれば当時は「これから」のものだと思われたLinuxやオープンソースに、プラスになるであろう「強力な応援団」である「日本医師会」を味方につけたわけだから、大喜びしてもいいことだ。しかし、「システムエンジニアである私」は、

なんて無茶を引き受けたんだ

と鬱ぎ込むしかない。だって、「出来っこない」と思っていたから、「やらないため」の理由を突きつけたつもりでいたのだ。勝算なんて皆無だ。でも、そこを「やる」と言われてしまったわけだ。いくらやりたくなくても、やるしかない。

最近になってわかったことなのだが、実はこの「オープンソースでやる」ということの決定の裏には、当時同じ会社の役員をやっていた某社社長とか、その会社周囲の関係者の「暗躍」があったらしい。何がどういうわけかよくわからないが、彼等は「オープンソースでやる」ということをプッシュすることをしていたらしい。その「プッシュ」がどうやら彼等が「公式にオープンソースでやると決めた」ということになるらしい。だから、彼等にとっては「自分たちが進めたんだ」ということになるらしい。それはそれで「彼等の歴史」としては納得できる。なるほどなぁ。私は「断わる口実」として言っただけなんだが、「彼等」にしてみれば何か金の臭いがしたキーワードだったのだ。

とは言え、やれと言われたからやるしかない。「出来なくても知らんよ」という言質を取りつつ、「しょうがない」のでやることにした。えらくやる気のない私の発言で、失望する関係者もいるかも知れないが、実際当時はそれくらい「やりたくない」仕事だったのだ。

とは言え、勝算が0だったかと言えばそうでもない。

確かに限りなく勝算は0に近いことであったのだが、0ではない。それがあったからスタート出来たのであるが、これについては以降のエントリにて。

まぁそんなわけで、まずはアプリケーションを開発する人達を集めることから始まった。これには某社の社長が働いた。彼の古巣で医療システムをやっていたチームが暇になっていたということがあったので、彼等に働いてもらうことにした。当時私は既に東京に生活の居を移していたから、あまり遠方(松江)の会社でやるのは気乗りしなかったのだけど、人材的にほぼ選択の余地がなかった。

何しろ前述のように、既にマーケット地図の決まってしまった「レセコン」なんてシステムを開発出来るだけのマンパワーなんてのは、「新規」に集めるのは困難を極める。そりゃ「日本医師会」というブランドやら、金やら積めば、あるいはその気になるところもあったかも知れないが、実績やら経験やらがないと、恐くて頼めない。それを思うと、それなりに経験や実績のある人達が

いるだけマシ

と考えなきゃいけない。その人々がどこにいるかについて、良いの悪いの言ってられないのだ。それが「故郷」であり「本社」の近くの人々であるということは、むしろ幸いとすべきだった。