一つのシステムを納品するのには、獏大な時間がかかるものです。
今でもそう思いますが、システムエンジニアとして走り始めた頃は、もっともっと大変でした。
COBOLと索引データベースでの開発がその原因でした。
ツールも良いものが無く、生産性が極端に悪い開発環境だったので、無駄に時間を使ってしまったり、障害を特定できるまでに長時間かかることが多くありました。
たとえば、マスタ8本、ジャーナル12本、主機能40本の販売管理を設計したとします。
主機能40本に加えて、マスタメンテナンス8本、マスタリスト8本
これらのプログラムを作るのは当然ですが、加えてジャーナルメンテナンス12本、ジャーナルリスト12本も作っていました。
今では、RDBMSやAccess、Excelであれば簡単に、メンテナンスツールやリストを作ることができます。
ところが、当時は1本のツールを作ることさえ、一から手作りでした。
だからと言って、これを作ることをさぼると、結合テスト中でも納品後に問題が起きたときでも、原因解明に膨大な時間がかかってしまうのです。
当時は、その問題を追及するためのプログラムを現場で作るということを当然のように行っていました。
今、考えるといかに生産性が悪い方法だったかと思います。
結局、最初からメンテナンス用のプログラムを作っておいたほうが、生産性は高くなるのです。
また、お客さまに納品したシステムエンジニアが、運用保守まですべて引き受けるという慣習があったため、土曜の早朝にいきなり電話がかかってくることもありました。
電話応対で対応できる問題であればなんのことはありません。
ときには、すぐ現地に飛んでいかなければなりませんでした。
いつなんどき「呼び出されるかわからない」というのが当時のシステムエンジニア、そう、私の宿命でした。
しかし、キャリアを経て気付いたのですが、それは私自身の設計に問題があったのでした。
自分が作ったシステムは「正しく動いて当たり前」と考えていたのがその理由でした。
土曜、日曜も関係なく「緊急に呼び出される」システムを作っていたのは自分だったのです。
請求書が発行できない
請求書の表記が間違っている
データの不整合がおきる
とにかく、データが正しく処理されない場合に電話がかかってくるのです。
そして、何がおかしいのか、離れた場所からはわからないので駆けつけなければなりませんでした。
今でこそ、遠隔地からでもリモートメンテナンスが可能ですが、当時はファックスも普及していない時代です。
大変苦労もし無駄な時間を使いました。
システムの開発には「押さえどころ」があるのです。
トータルコストは、お客さまの運用時間だけでなく、システムエンジニアの納品後の稼働率や駆けつけ時間までも含んで考えるべきでしょう。
いかにして「駆けつけなくてもよいシステム」を作るのか
それには、いろいろなコツがあるのです。
（次週に続く）
Vol.00188