ORCAのアーキテクチャ(UI) | おごちゃんの雑文

「(序)」から読んでね☆

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でもクライアントが実現出来たのは、このアーキテクチャによるところが大きいはずだ。