動かないコンピューター
「動かないコンピューター」とは
日経コンピュータに「動かないコンピューター」という連載記事があります。これは、さまざまなトラブルによって稼動しなかったコンピューターシステムを取り上げ、その失敗の経過を説明し、原因や教訓となる事を示しているコラムです。このコーナーはそのパロディですが、内容はノンフィクションです。
この記事に登場する社名は全て仮名です。社名のイニシャルは、実際の社名のイニシャルとは一切関係ありません。
オンライン販売管理システム
1989年、都内某所にあるＡ社は、Ｂ社に「オンライン販売管理」を発注した。しかし、導入直後からトラブルが相次ぎ、Ａ社では業務ができないまま、リース料金を払いつづけてたと言われている。
遅れた開発
Ａ社では、事業をさらに展開するにあたって、オンライン販売管理システムをＢ社にハード、ソフトこみで全てお任せでシステムの開発を依頼した。それは「Ｂ社とはつきあいが長く、うちの業務も理解している」（Ａ社取締役）ためである。
しかし、ここで問題が生じた。今まで使っていたのは、単に納品書をドットインパクトプリンタで打ち出すだけの簡単なシステムであったため、開発も楽であったが、今回契約したシステムはオンラインで全ての事業所の売り上げのデーターを集中管理しなければならず、これまでのシステムとはまるで規模の異なるものであった。
しかし、Ｂ社の営業担当者や管理職はそれを理解しておらず、開発期間はこれまでの単なる納品書発行と同じ期間である１ヶ月しか確保しなかった。そのため、完成は予定よりも遅れに遅れ、当初予定していた１ヶ月後の稼働は不可能になってしまった。
未確認のリース開始
しかし、Ｂ社の営業担当者は、契約１ヶ月後にすぐにリースを開始してしまった。それは「１ヶ月で必ずできると言われた」（Ｂ社営業担当）ためである。
リースというものは、普通いったん開始してしまうと途中解約や途中中断はできない。したがってＡ社は全く納入されていないシステムに対して、リース料を支払いつづけなければならなくなってしまった。
相次ぐトラブル
ソフトは約３ヶ月後に完成し、納入された。しかし、すぐに問題が生じた。まず、Ａ社では月に億単位の売り上げがあるのにもかかわらず、このソフトでは月額の売り上げ金額の最大桁数として８桁しか桁をとっていなかったのである。また、ソフトにもバグが多く、「前の機械のほうがはるかに使いやすかった」（Ａ社オペレーター）という。
また、Ｂ社はＡ社の業務内容を理解しているはずだったが、このプロジェクトの責任者Ｏ氏にとっては全く初めての内容であった。「Ａ社の業務内容は全く知らなかった。それに、前の業務を担当していた人は既に全員が退社しており、Ａ社の業務内容を把握するのは不可能だった」（Ｂ社プロジェクト責任者Ｏ氏）。
オンライン部に欠陥
半年後、ようやくＢ社本社にて単体での動作が安定し、各営業所に端末が納入された。しかし、このソフト自体、単独で動作することしか考えられておらず、過去の売り上げデーターを修正しても修正作業を行った端末でのみ反映され、他の端末に反映されないといった不具合が発生した。
というより、まだインターネットのなかったこの時代に、電話回線＋半二重モデム(BSC手順)を使って夜間バッチで全営業所の変更をサーバーに反映させ、サーバーの全データーを全端末に反映させるなどという、そもそも設計に無理があった。
この機能はデバッグ中はすぐに終了するからいいものの、実際に業務が本稼動すると、データー量は肥大し、確認作業のためにまる一晩徹夜になる事もざらにあった。
Ａ社との決裂
リースが開始されて約１年後、オンラインの部分もようやく稼働し始めたた頃、Ａ社の追加変更要求が多発していた。これによって、せっかく安定していた部分にも影響が出るほど、根本的に作り直さねばならない変更が頻発した。特に固定長レコードを用いたCOBOLのデーターベースでは、これは致命的な変更で、その都度データーベースのリビルドのために全端末の業務が停止する事が頻繁に発生した。
だがＡ社の言い分は違っていた。「これは追加要求ではなく、最初からＢ社の営業とは約束していた内容。いままでそれがなされなかった事に対する損害賠償を請求したいぐらいだ」（Ａ社取締役）という。これに対してＢ社のプロジェクト責任者は「最初の段階で詳細な要求はなく、全てお任せで受注したはずだ」と語った。
その頃にもなると、プロジェクト責任者はＡ社の追加要求にはうんざりしていた。特にＡ社との打ち合わせ後に帰社した際、机の上に乗っていたＦＡＸに、Ａ社からのこれまでの打ち合わせ内容を根底から覆す要求が書かれていた事で、ついに堪忍袋の緒が切れてしまった。
その後プロジェクト責任者は、Ａ社取締役と激しい口論の末、ついにはＡ社に出入り禁止を宣告されてしまった。以後、そのシステムを再構築できる人物は既にＢ社にはおらず、未完成のまま放置される事となった。
双方に責任
この件を取材していくうちに、筆者は双方の責任を感じた。まず第一に販売する時点でのしっかりした内容や納期設定をちゃんとしていれば、こうはならなかったのではないか。また、ハードが変われば開発担当も営業所も完全に変わってしまい、前の担当との交流が一切ないばかりか、人の入れ替わりが激しく前の業務に担当した人間が１人もいないにもかかわらず、Ａ社の業務は完全に把握しているなどという事を売り文句にしてはならないと感じた。
またＡ社も、自分たちの要求ばかりごり押しするのではなく、少しは妥協することも必要だ。例えば、開発を大幅に遅れさせる原因となったある要求については、実際には業務にはまったく必要とはしておらず、「なんとなく、あったら便利かもしれない」という程度のものであった。
結局、このシステムはリース満了まで、システムが完成しないままリース料金を支払い続けたといわれている。
インターネットを使った販売管理システム
決まらない開発環境
1995年、都内某所にあるＣ社は、Ｂ社に社内ネットワークシステムを利用した販売管理システムを発注した。将来的には全国にある営業所を専用回線で結び、本社で売り上げを一元管理する計画であった。しかし、導入直後からトラブルが相次ぎ、最後まで稼動する事はなかったと言われている。
当初の予定では、オフコンを使いネットワークの専用線を引き、全営業所を結ぶ計画だった。しかし、打ち合わせを進めていくにつれ、要求仕様は二転三転した。まず当初予定していたハードは東芝TP90/550SVあったが、Ｃ社の依頼により急きょWindows95搭載のパソコンに変更になった。それは「パソコンでないと、他のソフトを使いたい場合に困る。せっかく全営業所にコンピューターを導入するのだから、単一の業務だけでなくWORDやExcelも使いたい」（Ｃ社取締役）ためである。
しかし、Ｂ社ではそれまでネットワークを使ったシステムといえば、専用線を用いたオフコンを使ったものだけであり、パソコンでインターネットを使った開発環境もノウハウも一切なかった。パソコンを使ったシステムといえば、せいぜいモデムを使ったJCA手順オンライン受注システムや、そのプログラムを流用した夜間バッチぐらいであった。
しかし、「インターネットはもうどこの会社でも導入している。ここでうちができないようでは競争に負ける」（Ｂ社取締役）ため、ネットワークに関する知識もないまま、なかば強引にこの仕事を引き受けたという。
その後、開発環境は急いで用意されたが、社内自体にインターネット環境がまったくない状態からのスタートであり、当初予定された納期の目前になってようやく開発環境ができあがるというお粗末さであった。
相次ぐトラブル
この後、システムは突貫工事で開発され、無事納期前に納品はしたものの、納入後にトラブルが相次いだ。社内では何の問題もなく動作していた10BaseTのＬＡＮカードが、設置場所ではなぜか作動しないのである。
しかし、このような環境が初めてであったＡ社では、原因の切り分けができず「これはソフトのバグによるものと判断し、ソフト修正による対応を命じた」（Ｂ社取締役）ために、問題は一向に解決しなかった。
これが、設置場所の電源の出力が不安定だった事が原因で、電源にいったんＵＰＳを通す事で解決できる事がわかったのは、実に納品より半年が過ぎたためであった。
責任問題へと発展
ＵＰＳを使う事でハード自体は安定して動作するようになったが、ソフト面での不具合が多発し、一向に修正される気配すらなかった。それから約１年後・・・ハード納入から数えて約１年半後、いつまでもこのシステムが稼動しない事がＣ社の重役会議で問題になった。Ｃ社はＢ社に対し抗議するとともに、このままでは損害賠償も辞さない考えをＢ社に対して示した。
しかし、開発を担当したＢ社では責任をたらい回しされた。「当初オフコンで受注したシステムだったため、打ち合わせおよび設計段階まで全てオフコンの開発担当部署が行っていた。受注した部署にパソコンでのネットワーク環境やノウハウの全くないゼロからのスタートで、半ば強引に契約書をもらってきたのは無理があったのではないか」（同社開発担当者）という声に対し、「当時、開発担当者に直接『できるか？』と問いただしたところ『できます』という答えが返ってきたために安心して任せたのだ」（同社取締役）という。
さらに「きっとこれは開発担当Ｙ氏が、同社のライバルＯ氏に対抗意識を燃やし、功をあせったのではないか」（同取締役）とも語っている。これに対し「対抗意識を燃やした覚えはないし、『できるか？』と聞かれて『できません』と答える事が許されない風潮が会社にはあった」（同社Ｙ氏）と語っている。
ハードごとに縦割りの部署
結局のところ、Ｂ社では他社との競争に負けることを著しく恐れ、インターネットに関するノウハウも開発環境も全くない状態で受注してしまった事がまず原因として考えられる。また、Ｂ社ではオフコンとパソコンでは担当部署がまるで異なるのにもかかわらず、ハードが変更になってもそのまま当初の部署が開発を行ったのも問題である。これは部署ごとに持ち客が決まっており、また部署ごとに厳しい売り上げノルマが決まっていたため、みすみす持ち客を他の部署に取られる事を嫌ったためである。
結局、このシステムはリース満了まで、システムが完成しないままリース料金を支払い続けたといわれている。
おことわり
このトラブルは筆者の所属していない部署（オフコン担当部署）で起こったものであり、筆者は急遽ハードがパソコンに変更になったためにノウハウを提供した程度です。私はオフコンを使った事はありません。
リース契約について
これまでの２つの事象では、最後はユーザー側がシステムが不完全（もしくは全く稼動しない）まま、リース料金だけを払い続けて終わります。つまり、ユーザーの泣き寝入りです。なぜ、このような結果になってしまったのでしょう？
リース物件は固定資産にならず、リース会社の所有物となります。したがって、固定資産税を払う必要がなく、減価償却の計算など煩雑な固定資産税の計算を省略する事ができます。そのため、しばしば高額なコンピューターシステムを導入する際に、リース契約が用いられます。
しかし、それにはリスクがあります。リース契約は途中解約の制度がありません。したがって、一度リースを開始したら、つまり一度納入されたものは必ず契約満了まで何があっても使い続けなければならないという事です。もちろん、契約したものがまったく納入されなかったのであれば、支払う必要はありません。しかし、基本的にリース物件はハードに対して行うものであり、ハードの代金にソフト代金を上乗せして契約されるものです。したがって、ハードが納入された時点で、システム一式の納入が完了したものとみなされます。
しかし、世の中そんな不条理が常にまかり通るほど甘くはありません。契約内容とあまりにかけ離れた状態でリース代金を引き落とされてしまった時は、ユーザーは契約不履行を訴える事ができます。つまり、裁判になります。裁判でユーザーが勝訴すれば、リースは解約できないものの、ソフト会社はリース代を全額負担しなければなりません。また、その間に業務が正常に稼動しなかった事に対する賠償責任を問われる場合もあります。
ひとたび裁判になれば、プロジェクト責任者は四面楚歌です。会社は何もフォローしてはくれません。
自分の勤めている会社が、
ｵﾝﾄﾞｩﾙﾙﾗｷﾞって
裏切ってあなたに全責任を押し付けようとするなんて事もザラにあります。
上の例にもあるように、あなたが今までずっと
ｲｶﾀﾞなんだよな
味方だと信じていた会社の上司や営業担当者が、「○○君ができるといったから、私は○○君を信じて任せたんだ」と言ってきます。それで裁判に負けると、最悪そのプロジェクトの責任者が全責任を負わされる事もあります。
そうならないために、仕事を引き受ける際には注意すべき事があります。それは、決して安請け合いをしてはならないという事です。自分のスキルと相談し、できそうもないものは断ることです。ただし、上の例にもあるように、会社の風潮として断ることが許されない場合もままあります。ですので、仕事を請けるときには「できます」ではなく、また「できません」でもなく、「厳しいです」「しかし精一杯やります」と答えるようにしましょう。そして、その通り精一杯やってください。精一杯やりますと言って、精一杯やった結果の失敗であれば、
それ以上個人の責任になる事はありません。もちろん、精一杯やったからといって失敗の責任自体から逃れる事はできませんが、少なくとも会社ぐるみで個人の責任にしようとする事からは逃れる事ができます。
記録を残す
裁判ともなると、必ず客先との間で言った言わないの問題が発生します。そこで役に立つのが記録です。記録はあなたを救います。最初の打ち合わせの議事録は特に重要です。最初の打ち合わせの通りの事さえできていれば、後からの追加要求が一切なされてなくとも、裁判で負けることはありません。そのためにも、議事録は必ず残し、相手の責任者の印鑑をもらいましょう。
追加要求に対しても必ず全て記録を残す事です。いつ、誰から、どんな追加要求が発生したか、それに対して自分はどのように対応したのか、具体的に記録します。ここで注意しなければならない事は、電子データーではなく手書きで残す事です。電子データーは後からいくらでも捏造が可能であり、検察側はともかく、会社が自分に不利なように証拠を捏造してくる事も考えられます。また、裁判では自分の有利なように後から自分で改ざんした可能性を指摘されます。したがって、記録は全て手書きで残し、日付を記載し、自社の責任者の印鑑をもらいましょう。これだけの追加要求に対し、どれだけ精一杯の対応をしたかという記録は、きっとあなたを救うことでしょう。
できる事ならタイムカードのコピーも残して起きましょう。過度の超過勤務は、プログラマの間ではスキルのなさを示すバロメーターのように言われていますが、裁判では
何が起こるかわかりませんが、大抵は
あなたを救います。
メインフレームとオフコンを使ったPOSシステム
1996年、全国に店舗を展開している大手チェーンストアＤ社は、Ｂ社にPOSシステム一式を発注した。全国でも名の通った、聞けば誰もが一度は聞いた事のある大手チェーンだ。(注意：このストアの頭文字はDではありません。「D社」はあくまで仮名です)
これの販売管理だけでなく、在庫の状況も一元管理し、在庫不足になればすぐ配送の手配をするシステムになるはずであった。
ホストコンピューターとして東芝のメインフレームを使い、各店舗の端末として東芝のオフコンを、また、最終的には仕入先の業者に東芝パソコンを導入しJCA手順によるオンライン発注も計画していた。
このプロジェクトには数億単位の予算がつぎ込まれ、人材もメインフレームでのプログラミングに詳しい人が集められ、都内の
駅から歩いて５分の
一等地にそのプロジェクト専用の事務所まで用意された。そのプロジェクト参加者は将来的にはＢ社とは全く独立した別法人となる計画もあった。
進まぬプロジェクト
だが受注から１年後、本来ならとっくにサーバーを納品していて各店舗との接続テストに入ってなければならない時期になっても、プログラムは一向に動く気配をみせなかった。
この原因についてB社では「打ち合わせが難航し度重なる仕様変更があったため」(B社プロジェクトリーダー）であるとした。だが、D社の主張はB社とはまるっきり異なったものであった。「いつまでもプログラムが完成しそうもなかったため、こちらとしてはむしろ当初の計画よりも大幅に譲歩して、機能を大幅に減らした要求に変えたものにした。当初の要求通りでは、それこそ何十年かかるかわからなかった」(D社プロジェクト担当）という。
最後通告
それからさらに半年が経過し、D社は１ヶ月以内に少なくとも販売管理のアウトラインだけでも見れる状態にする事を要求。それがなされなければ解約という、いわば最後通告を行った。
しかし１ヵ月後になってもプログラムは一向に姿を見せなかった。「この時点でも、こちらで確認した限りではメニュー画面しかできておらず、まるで話にならななかった」(D社プロジェクト担当）と言う。また「『アウトラインだけでも見れる状態』という要求を満たすために、メニューだけ作ってゴマかそうとしたような感じだった」（D社同氏）とも。
これに対してB社では「担当を決めた途端担当が退職しては新しい人が入社するなど、人の入れ替わりが激しかった。そのせいで当初の計画は大幅に狂ってしまった」（B社プロジェクトリーダー）としている。
また「こちらの作業は徹夜の連続だった。こちらだって精一杯やったのだ」（B社同氏）とも。
事の顛末
その直後、このプロジェクトはB社から全面引き上げとなり、別のシステム会社に引き継がれる事となった。B社ではプロジェクトチームは解散となり、作業に関わった人間はほぼ全員解雇となった。プロジェクトリーダーは解雇こそ免れたもののヒラの営業社員に格下げとなり、一ヵ月後に自主退職した。
なお、このプロジェクトは別会社で順調に進み、現在も問題なく稼動している。
身の程を知るべし
筆者はこのプロジェクトに一切かかわらなかった（このプロジェクトが順調に進めば、仕入れ業者に東芝J-3100パソコンと半二重同期モデムを納入してオンライン受注システムを作る予定ではあった）が、このプロジェクトにかかわった人間とは、以前に何度か仕事をした事はあった。それでわかったが、このプロジェクト参加者のほとんどが勤務態度は不真面目で、日中はほぼ雑談で終わっていた。これでは何年経とうがシステムが完成するはずがない。
筆者はこの4年後の2000年に、大手の仕事の外注社員をやったのだが、その時にわかった事は進捗は厳重に管理され、少しでもスケジュールに遅れが生じたが最後、すぐに遅れの原因と反省文（いわゆる始末書）を書かされたものだ。当然、日中雑談する余裕など全くない。日中サボりにサボった上での形だけの徹夜などなかったし、それ以前に日中に体力を使い切って徹夜作業などする余裕などなかった。
このプロジェクトは大手のソフト会社が受注したものを下請けしたものではなく、自社で直接受注したために進捗管理が疎かになってしまった。そのため、B社取締役達は仕事が全く進まないまま形だけの徹夜作業に騙されてしまった事になる。
筆者はこれまで色々な失敗プロジェクトを見てきたが、総じて自分の身の丈に合わない計画がうまくいったためしがない。本件にしたって、B社ではこれまでメインフレームを使った実績がない。もちろん、実績を作るためにあえて新しい事に挑戦する事は必要だが、それにしても普通は他社からそれなりのノウハウや実績を持った人間を招いてリーダーに据えるぐらいの事は必要である。このプロジェクトのために集められた人たちは、一部オフコンでの実績のある人を除けばほとんどが新卒の採用であった。
このプロジェクトはリース開始前であったために、リース満了まで動かないコンピューターにお金を払い続けるといった最悪の事態だけは免れたが、これまでの開発にかかった１年分の費用はD社が支払ったとされている。
FM/Vとイマジオを使った見積書作成システム
1995年、都内某所にあるE社は、B社に見積書作成システムを依頼した。これまでの販売管理とセットとなったシステムとは異なり、単なる見積書の発行だけ。パソコンを単なる印刷マシンとして使うためだけのものだった。今のPC環境で同じ事をやろうと思ったら、エクセルで作れば十分な内容であった。
そのため、リース契約にはせず、単に完成時に現金払いという契約であった。また、ハードも、B社が通常使っている東芝ではなく、E社が既に使っていた富士通のPCに組み込むというものであった。
プリンタも、通常B社ではドットインパクトプリンタを納品して、既存の複写の最初から枠ができている用紙（感圧紙）に内容だけ印字するものであったが、今回はE社でいつも使っているイマジオに見積書の枠ごと印字するという事で話はまとまった。
ソフトはすぐに完成するが
見積書の発行だけであるから、ソフトは1ヶ月もたたないまま即完成した。だが納品後に問題が発生した。余白の左右の量が違うというのだ。ものさしで測定した結果、右の罫線までの余白が2cm、左の罫線までの余白が2.1cmと左の方が1mm多いというのだ。
しかし、そんな事もあろうかと全体的に絶対位置指定（<1B> $）を使ってオフセットを与える機能がついていた。全体的にn/60インチずつ微調整する事で、なんとかE社の見るところの誤差の範囲で落ち着いた。
満足のいかないE社
だが、E社の要求は続いた。表題の見積書の「積」の文字の中心が用紙の中央にないというのだ。それも、印刷した用紙を２つ折りにして、さらにそれをものさしで測定した結果1.5cm程左に寄っているという程度であり、見た目では全く気にならない程度（B社開発担当者）であった。
余白の調整機能はあくまで全体的に印字位置を調整する機能であって、表題の文字のセンタリングを余白の微調整機能を使って動かすと、せっかく合わせた左右余白と縦罫線までの距離までずれてしまうのだ。。この日はソースをいじってできる限り調整を試みたものの、この日中にE社の満足の行く結果にはならなかった。後日再納品となったが、帰り際にB社担当者はE社社長より、「こんな精度の低いものを作って、プロとして恥ずかしいと思わないのか」と言われた。
E社との決裂
その後もE社からの要求は続いた。まず、右上にある自社名の欄の、株式会社の部分の文字間を今よりも若干狭く、社名の部分の文字間を今よりも若干広くしてくれというものだ。「<1C>S」コマンドを挿入する事で文字間隔の調整はできたが、すると今度は社名の部分と住所の部分、そしてTEL、FAXの部分の文字の右端と左端をそろえるように要求。文字間調整コマンドを微調整する事で数日かけてようやく文字の右端と左端をそろえる事ができたが、「今度こそ満足してもらえると思った」(B社開発担当者）ものの、印刷結果を見たE社社長は激高した。最初の要求であった「株式会社の部分の文字間を今よりも若干狭く、社名の部分の文字間を今よりも若干広く」という要求が犠牲になってしまっていたのだ。
これについてB社では、「社名、住所、TEL、FAXの全ての文字の右端と左端を揃えるだけでも至難の業だった。その上で、なお株式会社の文字間隔を今よりも若干狭く、社名の文字間隔を今よりも若干広くといった指定まではとても無理だった」(B社開発担当者）としている。これに対してE社では「どうしてもできないというのなら解約しても構わない」（E社社長)と言ってきた。
B社開発担当者は、解約するか担当から外してもらうよう、このプロジェクトの営業担当兼取締役に相談した。が、結果、けんもほろろに断られた。まず一度契約したものはこちらの都合で解約できないという事。「相手から解約を持ちかけてきた」(B社開発担当)と言ったが、B社としては断固として解約はできないという。であれば、せめて担当から外して欲しいと要求したものの、「お前は将来会社を背負っていかなければならないのだから、どうのこうの、どうしたこうした、ああだこうだ・・・」と説教が始まってしまった。
この時E社の度重なる無理難題にただでさえ理性が限界に達していた開発担当者は、この説教でついに理性が切れてしまった。その後、開発担当者はこのプロジェクトの営業担当兼取締役と激しい言い争いになった。その後、開発担当者はこのプロジェクトを自ら放棄し、別の仕事に専念した。当時、この他にも仕事が山積しており、このプロジェクトだけにそんなに時間をかけられる状態ではなかった。また、社内でもこのプロジェクトについては触れる事はタブーとされ、誰もこのプロジェクトについて語られる事はなく、また、E社からの催促もなく、このままこのプロジェクトはなかった事になった。
幸い、リースではなかったために、動かないコンピューターにお金を払い続ける事もなく、訴訟になる事もなかったが、この１ヶ月あまりの開発にかかった人件費はB社が丸損する事になった。
10年越しに出した結論
この場合、誰が悪い彼が悪いという話をするときりがない。というより（当然ながら）要求通りの精度で帳票を作れなかったB社開発担当者（筆者の事ではない(多分)）が悪い事は間違いないのだが、ここでは教訓を残すという目的で、誰が悪い彼が悪いという話ではなく、もう少し掘り下げて考えてみよう。
まず、ソフト開発ではこの例のように作ってから作ったものが気に入らない、途中引き上げという事は頻繁にある話で、そうなった時に気をつけないとソフト会社が全面的に負担を強いられてしまうことになる。そういうわけでリース契約になる事が多いのだが、今度はハードが納入された時点で、どんなに気に入らなくともユーザーがリース満了まで全面負担しなければならないというリスクがあるため、ユーザー側は現金払いを望むところも少なくない。
だが、完成時に全額払いという契約は危険である。なぜなら、契約後に資金繰りが悪化したために、あえて無理難題をおしつけて契約を解除するように仕向ける事もできるし、無理難題をおしつけてお金を払わないまま、実は納入されたものをそのまま使うという裏ワザもできてしまう。
そうならないためにも、現金払いであれば着手する前に手付金をもらい、ある程度途中までできた時点で分納してもらうようにしなければならない。分納まではしなくても構わないが、少なくとも手付金なしで完成時に一括払いというのは非常に危険だ。
また、契約時にどの程度の精度を要求しているのかまできちんと確認する事が必要だ。
レーザープリンターを使ったところで所詮はパソコンで打ち出した帳票。
そんなに精度の高いものができるはずもない。Ｅ社はおそらく専門の印刷屋なみのクオリティーを期待したのだろう。
現在でこそ、PostScript言語で記述することでより高い精度で帳票を作る事が可能だし、社名のロゴの部分はPhotoshopで画像として作っておいて、画像を貼り付ける事でより高い精度で社名のロゴを印刷する事は可能だが、当時の開発環境といえばMS-DOS
+ COBOLであり、GUI環境で編集しているわけではなく、全体的なバランスまで高精度にレイアウトするのはまず不可能だ。ESC/Pのコマンドを駆使してのレイアウト調整は、印刷結果を画面上では確認できず、いったん印刷してみなければならなかった。また、当時開発用に使っていたプリンター
LP-1000が動作が非常に低速で、１枚印刷するごとに２～３分待たされてしまうという辛いものであった。
筆者はこの件を思い出すたびE社社長の言葉を思い出す。
「こんな精度の低いものを作って、プロとして恥ずかしいと思わないのか」
そして、それを気にするあまり、筆者はこの後、転職後も見積書を作る時は左右の余白や中心をミリ単位で合うように最大限時間をかけて調整した上で、プリンター毎による誤差にも対応できるように、最初に初期設定ファイル(bicho.iniファイル）を読み込んで上マージン左マージンを納品後も即座に変更できるように作っていた。
だが、そのような精度を望んでいる客はほとんどおらず、どちらかといえば早く納品してほしい人ばかりであった。にもかかわらず、筆者は高い精度にこだわって作業を続けていた。
あの日から10年後の2005年、転職した筆者は別の会社で見積書作成の仕事をしていた。しかし、あまりにも時間がかかるために担当から外され、別の人に回されてしまった。その際、社長が新担当者に指示していた言葉は一生忘れられない。「このbicho.iniとかいうわけわかんない部分、意味ないから消しちゃってくれる？」それを遠くから聞いていた筆者は、ショックのあまりしばらく呆然とした。
結局、新担当者の作った見積書は全体的に左に寄りまくり、上に寄りまくり、全体的にレイアウトはあまりよろしくなく、正直言ってプロとしては恥ずかしいクオリティのものであった、が、客からはクレームが来る事もなく納品は無事終了していた。
その時筆者は10年経ってようやく結論が出た。プロというのは高いクオリティのものを作るものではなく、客が文句を言わないギリギリのクオリティのものを最短の時間で作らねばならないのだと。
最後のシ事
既にほとんどのPCにWindows95が導入され、MS-DOSのソフトが姿を消しつつあった1997年の某日、埼玉県内にあるF社は生産管理システムをB社に発注した。
内容は、E社で生産している製品の受注数を入力する事で、自動的にその製品を作るのに必要な部品数が算出され、部品の在庫がない時は部品の注文書が仕入先ごとに印刷されるというものだった。同時に、受注管理も行われ、受注残数と納期の一覧も印刷できるというシステムだった。
打ち合わせ・納品までが全て順調
それまでトラブル続きであったB社にしては珍しく、このプロジェクトでは打ち合わせでもめる事もなく、納期に遅れる事もなく、納品後に追加要求でもめる事もなく、全てが順調に進んだ。F社でも「大変便利なものを作ってもらってありがたかった。これで作業効率も大幅にアップするに違いない」(F社取締役)と大変好評だった。
ほどなくしてリースも開始され、リース満了まで何１つ不満なく、リース満了までこのシステムは稼動する・・・はずだった。
オペレーター入社によって状況が一変
F社ではそれまでPCの操作に精通した者がおらず、入力もほとんどが1本指で行われていた。そのため、データーの入力には相当の時間がかかってしまった。そこで、PCの操作に詳しい若い従業員を雇った。F社ではPCの操作自体に詳しい者がいなかったため、B社開発担当者が直接F社に出向いて説明をする事となった。
だが、B社開発担当者がF社を訪れると、それまで穏便だった雰囲気は一変していた。それまで、Microsoft Officeの操作に精通していたF社新オペレーターにとって、MS-DOSベースのCUIベースで作られたソフトの操作に不満が爆発した。例えばエクセルでは比較的簡単な操作で表からグラフにする事ができるし、グラフの種類も自由に選ぶ事ができる。出力帳票のレイアウトだって簡単な操作で自由に変更が可能だ。それに引きかえ、このソフトではCOBOL言語で固定のプログラムであったため、レイアウトの変更はできず、グラフ出力もできなかった。エクセルのアドオン機能にある、推移予測の機能などもっての他だった。
おまけに、データーの出力は基本的に紙ベースであり、多くのデーターが画面では確認できなかった。部品の入出庫明細は月単位で更新され、過去の履歴は印刷物を探して確認しなければならず、過去の履歴に対する検索機能もなかった。
B社ではこの原因について「それまではPCのハードディスクは多くても100メガ程度であり、そうしなければハードディスクの容量が持たなかった。」「ISAMの検索機能には限界があり、あまりに副キーをつけすぎると重くて動作できないレベルになってしまう。そのため、過去のデーターは紙ベースで探してもらうしかなかった」(B社開発担当者)という。また、「ハードディスクが100メガだった頃からの設計をずっと引き継いでいたため、ハードの性能アップに見合わないシステムになってしまった」（同氏）とも。
このシステムについてF社オペレーターは、「導入されたシステムは、全くの時代遅れの代物だった。」(F社同氏）「10年前から使っているシステムなら話はわかるが、これを今から新たに導入すると言われ、自分の目を疑った。」(同氏）というものだった。
また、操作性についても、GUIに慣れた人にとってこのCUIベースでの操作性には相当の不満もあった。そのため、F社オペレーターは幾度となくこのシステムを厳しい口調で批判した。
雨、逃げ出した後
その後、数日間はB社開発担当者がF社を訪問し、操作の説明を行っていたが、ある時F社オペレーターがデーターのバックアップの方法について質問をした際、ついに限界がきてしまった。
開発担当者「（バックアップの機能は）ありません」
F社オペレーター「な・・！！ ないんですか？？」
開発担当者「はい。ありません」
F社オペレーター「あのさぁ・・・そんな簡単に言いますけど、『ありません』じゃ済まないと思うんですけど」
COBOLのISAMファイルで作られたこのシステムがそう簡単にバックアップ/リストアできるものでもなく、また、フロッピー１枚に収まる量でもなかったため、バックアップ機能を付けるためには、外付けのMOもしくは外付けのハードディスクが必要であった。だがリース価格にそのような追加ハードの料金は一切含まれておらず、また、ソフト担当者の権限でハードを追加する事もできなかった。この件についてB社では、「現在の価格でもギリギリの状態。これ以上価格を上げると競争に負ける」(B社営業担当）というものだった。
そのためこの件は完全に手詰まりになってしまった。「あのさあ、『ありません』じゃ済まないと思うんですけど」に対する返答に困った開発担当者は、
F社オペレーター「あのさぁ・・・そんな簡単に言いますけど、『ありません』じゃ済まないと思うんですけど」
開発担当者「・・・・・・・」
F社オペレーター「あの、バックアップ機能ありませんって、ありえないんですけど。よくそんなもの平気で納品できますね。」
開発担当者「・・・・・・・・」
F社オペレーター「あの、もしもし？」
開発担当者「すいまんが、私、今日で退職しますので、その件については別の担当の者に言ってください」
と言って、F社を飛び出して、そのまま走って逃げてしまった。 「あのさぁ！！」っていう怒鳴り声を背中で聞きながら・・・。
そして、彼は帰社せず、そのまま自宅へと向かった。たまたまＦ社は彼の自宅の近くだった。途中、雨が降ってきたが、彼は傘を持っていなかった。しかし彼は傘もささず、うつむいたまま自宅へと向かった。Ｆ社は彼の自宅の近くとはいえ、歩いて１時間はかかった。
その後、この開発担当者はこの後しばらく出社しなかった。
１週間後、社長に電話で呼び出された開発担当者はこう告げられた。
B社社長「無断直帰、無断欠勤、客先からの逃走、全て社内規則違反だ。何か言いたい事はあるか？」
開発担当者「僕はもうＦ社の仕事はやりたくありません。ここにもいたくありません。」
B社社長「だったら、さっさと（退職の）手続きしろや！」
開発担当者「はい、そうします。ニートに戻ります。」
時代の変化に対応した設計を
途中までB社とF社との間で全てが穏便に進んでいたこのプロジェクトが、一人のオペレーターの入社によって崩れてしまった。が、だからといってこのオペレーターが悪いとも言えない。実際、B社のソフトは既に時代遅れであった事は事実であり、エクセルを使えば遥かに良いものが作れるにもかかわらず、B社では旧態依然としたシステムを作り続けていた事もまた事実である。そのため、Office製品に精通した人の目には、B社のシステムはさぞかし見劣りしたシステムに映った事だろう。
今では信じられない事であるが、B社ではMS-DOSベースの業務ソフトにおいて、 バックアップの機能は全てにおいて搭載されていなかった。 筆者もずっと前から不思議に思っていた。どうしてB社の作るシステムにはバックアップ機能がないのか。 だが、1989年～1997年のこの時までにバックアップ機能がないのがおかしいという指摘をしたユーザーはいなかったし、 売り側も、作る側も、そのような機能が必要だと思う人すらいなかった。 それまでB社相手にしていた顧客は扱っている得意先も商品も少なく、ハードディスクの故障時に得意先、商品を全て１から入力し直しになったとしても大したダメージにならなかった事も原因の１つだった。
だが、今回の問題は、それだけではない。最初にきちんと責任者との打ち合わせの上で納得ずくでリースを開始したシステムが、後から入社した何ら権限もない新人オペレーターの意見で解約できるものなのか。
普通なら不可能である。しかし今回の場合、B社のシステムが著しく時代遅れであった事、 バックアップ機能がないという非常識さであった事、 そして両者の責任者同士が、その事がいかに非常識かという事を全く知らなかったという特殊な例である。
コンピューターの進歩は日進月歩しており、今後コンピューターシステムを販売して生計を立てるのであれば、そういう事態も起こりうるという事は念頭においておいた方が良い。少なくとも、弁護士を雇うなどして、こういった事態が起こった際の対策は事前にとっておく必要はあるだろう。
なお、この件の顛末は不明です。なにしろ、開発担当者はこの後解雇になりましたので・・・。
失敗は恥ではない
ソフトウェアというものは、物理的に何かを作るわけではなく、何度でも補強や作り直しが利くものである。それがソフトウェアの利点であり欠点でもある。何度でも作り直しができるという事が、逆に完成後に何度でも作り直しを要求されてしまうという欠点にもなる。その解決策は、本でいくら勉強しても、いくらGoogleで検索しても得られるものではない。何度もトラブルを経験して、少しずつ対策を立てていくしかない。
さまざまな失敗を経験した筆者でも、それなりに得られるものはあったし、以前の失敗を繰り返さないように事前に対策をする事もできるようになった。技術者は失敗から学ぶ事が多く、成功から学ぶことは少ないのだ。
このページの先頭へ