やはりK氏のことば。
数千台のパソコンを確実に動かすということは絶対条件。WindowsのバージョンやI.Eのバージョンの違いで挙動がわずかでも異なるようなことがあると、ぎりぎりで画面設計をした場合命取りになることもある。
その点Biz/Browserは、Biz/Browser自身がWindowsやI.Eのバージョン違いを吸収してくれているので、まったく安心できる。アクシスソフトさんは、Windows Update がかかるたびに膨大なテストをやっていて、ほんとうに大変だと思うが、そのおかげで我々は安心してアプリケーションに専念できる。
これがBiz/Browserを選択した最大の理由です、とのこと。
アクシスソフトのテストチームのみなさん、ありがとう！
K氏は、インフラ系大手システムインテグレータのファイアーマン。
北に納期遅れをきたしそうなプロジェクトがあれば、飛んで行って立て直し、南に仕様が決まらないプロジェクトがあればそばに寄り添ってあっという間に満足の行く仕様に仕立てる。その原動力は高校・大学とキャプテンを務めてきたラグビーにあると振り返る。
ラグビーは１５人対15人で戦う。敵味方３０人が今どんな位置関係にあり、それぞれが次に何をしようとしているか、手の取るように分かるという。２００人規模のシステム開発プロジェクトでも一人ひとりの動きが分かるのはその時培ったものだと思うという。
K氏は、C++でできていた数千人規模で使う見積もり積算システムのWeb化を成功させた人。SAP R/3で行くか、通常のWebで行くか、リッチクライアントで行くかの中で、リッチクライアントのBiz/Browserを選んでプロジェクトを大成功させた。操作性が従来と変わらないので、システムテストに入ったとき、ユーザが、画面も見ずすごい勢いでデータ入力するのを見たときは驚いたという。そして端末画面の仕様は苦労したクライアントサーバ（C/S)時代に確立していたのだなとつくづく思ったという。ユーザも、操作性が変わらないので安堵の色を浮かべていたという。
基幹業務システムの画面はC/S時代に確立している。これをそのままWebに持っていければいいというケースは多いのではないかと思う、とK氏は言う。
K氏に乾杯。
プログラムの品質は問われるが仕様書の品質が問題になることは、ない。
なぜか？
仕様書は発注側が書き、プログラムは受注側が作るから。
そもそも、どんなシステムを作りたいのかが（仕様）が曖昧なら、それを受けて作る側は途方に暮れてしまう。それでも納期があるから、何とか形を整える。しかし魂の入っていないシステムは使いにくい。その結果プログラムの問題にされる。プログラムは仕様書を具現化したものだから、本来の責めは仕様書を書いた発注側が追わねばならないと思うのだが。
