#05 - Conversion Project

1980年代、異なるメーカー間でシステムを入れ替えるプロジェクトに参加しました。Conversion Projectと呼ばれ、多くのプロジェクトが立ち上がっていたように記憶しています。

この手のプロジェクトを担当するとびっくりするくらいスキルが上がります。
ITインフラとしてのスキル、お客様業務のスキル、運用のスキルなど広い範囲に及び、私も例外ではありませんでした。
更に、競合他社製品の知識も身につくので知識の幅が広がりました。

その時の一つで移行に苦労したプロジェクトを振り返ってみたいと思います。

1980年代後半

1980年代後半からは、コンピューターメーカーを変更するお客様が増加していました。国内メーカーから外資メーカーへ、またはその逆など。根本にあったのは、新しいテクノロジーを手に入れることと、長期でのコストダウンを狙っていたのではないかと思います。

もともと日本は、1970年代に通産省の施策により、海外コンピューターメーカー(特にIBM)に対抗すべく、国内に三大コンピューターメーカーグループを後押しして創設させた経緯があります。その結果、国内コンピューターの導入も増加していきましたが、20年程度の時間の経過とともに、産業界も変化していったため、このグループの関係も希薄になり消滅していきました。そうなると、再度IBMのコンピュータを含めた外資系コンピュータを利用するという動きも再燃することとなり、大手電機メーカーもその波に乗りました。メインフレーム全盛時代として、いわゆるコンバージョンプロジェクトが必然的に発生したのです。

その際、私が経験したのはACOSからIBMへのコンバージョン・プロジェクトでした。それもWord MachineからByte Machineへのコンバージョンでした。

Word Machine と Byte Machine
文字を表すとき、コンピュータ内部では通常8bitで表現することが標準となっています。1bitは、0または1を表します。それが8個連続したものをByteと呼び、1文字の英数字を表すことになります。Wordといった場合は、word = 4byteで表すことになります。通常は、byte = 8bitなので、word = 32bitが標準ということになります。ところが、1byte = 9bitで表現するMachineが存在していました。ということは、word = 36bitということになり、4byte単位を1つとして稼働するコンピュータをword machineと呼び、1byte単位を1つとして稼働するコンピュータをbyte machineと呼んでいました。コンピュータの中で計算を実施するときに、精度が高いのはword machineでしたが、さまざまな制約を受けるので、byte machineの方が世の中の標準として定着しました。今回の記事で扱ったコンピュータは、1Byteが9Bit単位で構成されたword machineだったのです。
ちょっとわかりにくいですね。

ACOSについて
ACOSは、NECが提供しているコンピュータでです。しかし、この記事で取り上げているのは、ACOS-6と呼ばれる日本電気と東芝が共同でリリースしたコンピュータでです。下記リンクに生い立ちの記述がありますので参照ください。ただし、詳細なアーキテクチャーは記載されていないようです。

ACOS-6-コンピュータ博物館

変換ツール検証

参加した時には、移行するためのツールとして、言語変換やデータベース変換のツールが開発されていたため、それらの有用性を検証し、本番のプロジェクトに備える段階でした。対象言語はJIS-COBOLからIBM-COBOLへ、対象データベースは、ネットワーク型からリレーショナル型への移行でした。COBOLは、互換性の高い言語ですが、提供するメーカーにより独自の命令だったり、振る舞いの差であったり、計算精度の差がありますのでちょっと厄介でした。特に、計算精度の差は表面では発見できず、実際の計算結果で誤差となって現れてきます。解りやすく言えば、同じ計算式でも小数点以下第何位まで表現できるかで、わずかながら誤差が生じます。それが計算精度の差となって現れることになります。

そして対象となるものがもう一つ存在していました。データです。これが、前述したword machineとbyte machineの差を最も顕著に表すことになりました。そうです、ACOSは1文字を表すのに9bit使用していましたが、IBMは8bitなのです。また、数字を表す時には、ACOSは、35bitで表現し、IBMは31bitで表現されることになるので精度の差(bit数が多いほど精度は高い)が生じてしまうことになります。(1bit少ないのは、ACOSは符号で利用し、IBMはアドレッシングモードの識別用として使われていたと記憶しています。間違っていたらごめんさい。)

ツール評価に際しては、私自身、それなりのプログラム開発経験を持っていたため、変更後のプログラムなどの保守に問題が生じないかという観点で評価を実施することが担当でした。

ツール開発者は、変換がうまくいくことが最大の目標として開発してしまうことが多いので、変換後のソースがとても見づらくなってしまうことが良くありました。

変換した直後に保守する担当者は、移行前のシステムに精通している人達であるということも念頭に置く必要があるのです。つまり、移行後のシステムに関しては、その後の学習で補って行くことになるので、当面の保守は、移行前の知識で処理できることが理想であるということになります。また、移行されたシステムは遠からずリニューアルされる運命にあります。それまではスムーズな保守環境を維持できるのが望ましいのです。

以下が当時評価した時の結果でした。

1.言語変換について
COBOLの変換自体は、よく出来ていましたが、変換がうまくいかなかった場合に挿入されるコメントが判別しにくいという欠点がありましたが許容範囲と判断しました。

2.データベース変換について
プログラムの中からデータベースにアクセスする部分は使い物になりませんでしたし、デーベース生成に関してはツールで対象としていないので新規で作成する必要がありました。これは人的ミスを誘発する可能性大でした。変換率も30%程度だったのでないでしょうか。

3.データ変換について
メーカーから提供されるユーティリティを利用することで検証しましたが、前述した数字項目(正確にはバイナリーデータ項目)の部分の対応がうまくいかないので、文字の変換部分でしか有効活用できませんでした。

結果として、データベース変換に関しては、ツール再作成、データ変換については新規ツール開発を提案し、結局私が作成することになりました。

変換ツールの開発

与えられた期間は、約1ヶ月。というか、1ヶ月あれば簡易的なツールを作ってみせますと行ってしまったのです。そうしたら、ぜひお願いしますと言われてしまいました。うーん、後には引けません。その期間で簡易的なデータベース変換ツールとデータ変換ツールを開発することになりました。かなり短い期間です。しかし、受けてしまった以上弱音は吐けません。オフィスの一室に一人陣取って、ACOSのマニュアルを読み漁りました。時折、気の毒に思ったのか同僚が差し入れを持ってきてくれたのを覚えています。検討していて変だなと思うところはお客様に直接確認し、マニュアル通りには機能しない箇所を特定しながら、変換ツールに反映することを決意しました。

まず、データベースに関しては、データベースの定義文も自動生成して、プログラムとの整合性をツールで保障するような連携を考慮しました。これにより、定義文とプログラム内で利用しているデータエリウ、つまりデータベースを読み込んだときに一時保管するエリアの整合性が保たれるようになりました。そして、プログラム内からデータベースにアクセスしている箇所は、変換後がみやすくなければならないので、SQL文を直接データベースアクセス部分に挿入せず、定型ロジックとして呼び出す名前だけを標準化してプログラムの原型をできるだけ変えないようにしました。呼び出す手段もCOBOLでよく使う命令(PERFORM)のみにしたので、保守する際も間違えることがないように考慮できました。我ながら上出来でした。

問題は移行するデータです。9bit単位で構成されているのでIBMのコンピュータにそのまま読み込ませると意味不明なデータになります。よって、1bitを1byteで表現して印刷するプログラムを先に開発しました。これで、可視化できるようになったのです。これを応用して変換前後の比較も可能になりました。移行後の確認がファイルでの比較で可能になるので作業は楽になるはずです。

そして、データ変換そのものは、基本は9bit単位に変換処理を実施して、バイナリーのところだけは36bit単位で変換処理を実施するようにプログラムを作成しました。心配していた、35bit全てを利用している実データがあるとIBM内では収納することができないので分割するなどの代替手段が必要となるはずでしたが、幸いなことに実在していませんでした。それだけで、開発が遅延することを回避する事ができました。

なんだかんだで、約1ヶ月ギリギリで変換ツールは完成しました。
期間はひと月でしたが、かけた時間は、250時間以上だったと思います。ツールとしてはASSEMBLERで5000stepに近かったように記憶しています。
その後1ヶ月かけてマニュアル作成、そしてお客様に説明し使用開始まで漕ぎ着けました。

実プロジェクトでの適用

いよいよ、本番プロジェクトでの適用が始まりました。
順番としては、データベース定義体の作成とCOBOLの変換を同時に実施します。そして、データベースの定義を実行し、変換後のプログラムをコンパイルします。この時のコンパイルエラーが多ければ、手修正の作業が大変になりますが、この時は、データベース部分の変換に関して80%以上の変換率を達成していたので、作業もスムーズに行きました。手修正が必要となるプログラムはデータベースに対して特殊な処理を実施しているものだけだったので、ほとんどは手修正が入りませんでした。これも大きな成果です。鼻高々でした。

お客様の立場に立った場合、保守段階に苦労することになることが明らかであり、それをなんとか回避したいという気持ちと、既に作成されていたツールより、いいものを作りたいという気持ちから、単独でのツール開発を決心し、1ヶ月程度の期間(残業の日々でしたが)で構築しました。その後、この変換ツールは、お客様内の工場など5箇所程度のシステムで利用され、IBM環境への移行に大きく貢献することができ、お客様との関係もよりよくなり、その後のお客様担当SEとしての活動も実施しやすくなったのを覚えています。お客様と、変換前と変換後の話の両方ができるということは信頼にも結びついていきました。

なければ作ってしまおうという考えがまだ適用しやすい時代でした。変換ツールなどは一過性なので作ってもいいとは思いますが、現代は極力つくらず、世の中にあるものを利用、応用するという時代です。これも保守のことを考慮していることに他なりません。この時作成した変換ツールは、この後は私の手を離れ何度か利用されましたが、保守されることもなく、利用する場がなくなり役目を終えました。

必要なのは発想の転換

課題に対して対応策を考えるというとき、発想の転換が重要だと思います。
直面した課題に対し、最速で解決することは重要ですが、そこで終わってしまうと解決した課題を人に渡すことが難しいままかもしれません。自分以外の担当者が見てもわかりやすい解決策になっているかという視点で見直すことで長く使える解決策にする事ができます。

私の場合は、作ったシステムやその結果が保守に回った場合に担当する際に最小限の時間で対応できるようになっているかということを考えるようにしています。もちろん、自分ではそう思っていても、必ずしも解りやすくなる訳ではありませんが、そんな発想を常にしておかなければ、ビジネスとして実施している「作品作り」は感謝されません。

エンジニアなので、持てる知識を駆使して対応することは大変重要ですが、自分自身のスキルアップを満たした後は、プロフェッショナルとしての「作品」になるように心がけることが必要だと思っています。

また、今回はデータベースの変換ツールを開発した訳ですが、金額にすると約200万円程度です。しかし、開発する前に作成されていた変換ツールは、機能的に不足しているにもかかわらず、数千万円の投資をしていたようです。それほど差が出ることになるので最初の検討はとても重要ですね。結果として、作成されていたデータベース変換ツールは利用されることはありませんでした。ビジネス的には、私の開発にかかったコストを含めてリカバリーしなければならないので、プロジェクト費用はそれなりの価格になります。何となく、釈然としないものはありましたが、私ではどうにもできせん。最初から参画していれば。。。あとの祭りです。

SEとしては、発想の転換を常に意識して数年先のことを考えたシステムという作品作りに取り組む事が重要だと思います。そして、それが最小のコストで作成できるように工夫するのもSEではないでしょうか。そんなことを学んだプロジェクトでした。