本連載「デジタル“失敗学”」では、金融分野のテクノロジや情報セキュリティの現場を渡り歩き続ける萩原栄幸氏が、日本企業が取り組むべき“デジタル変革”を失敗させないためのヒントを紹介します。
「良かれ」と思ったチャレンジでの失敗
今回は、私がまだ金融機関に勤める前のお話です。当時はシステムエンジニアとして、プログラマーとしてさまざまな仕事を楽しくこなしていました。
プログラムもまだ、「ソフトウェア工場」と呼ばれる言葉や概念がなかった頃です。今では信じられないかもしれませんが、事務計算用のプログラムは、業種や業態の違いにほとんど関係なく、幾つかのパターンに集約できました。プログラマーは、コーディング用紙に記入し、それをパンチャーが紙カードにアウトプットするという業務形式が一般的でした。当時のコンピュータは、この紙カードを読み取ることでプログラムが実行される仕組みです。
私は、コーディング用紙を機能ごとにサブルーチンとしてコピー(例えば「うるう年のチェックルーチン」という感じです)をしておき、通常は1カ月~半年でそれぞれの企業のプログラム仕様書やデータベース設計書に基づいてプログラミングや設計書を作成していました。それらをパズルのように組み合わせ、サブルーチンの集合体を1つの事務計算用プログラムとして納品していたのです。ですから、アウトプットを早くでき、生産性としては当時の通常の数倍、時には10倍以上も高く、あまりに素早くコーディングできたため、周囲が驚いていました。
しかも最初の組み合わせをうまく検討しておくと、デバッグ(パンチミスや文法ミスを発見して取り除く作業)さえ通れば、プログラムに論理的ミスがない品質に仕上げることができました。私は簡単にできる方法を追求し、それはまるでパズルを解くようにとても楽しいものでした。ところが、つい禁断の領域に踏み込んでしまったのです。
当時は、今よりもプログラマーがお客さまのシステム室に出向いて、プログラムを翌日の朝までに納品するというケースが多く、その間に本番業務の運用もよく行っていました。とはいえ、その業務も夜間バッチが一度流れ始めれば、後はマニュアルに沿ってコマンドを入力することが何回かあるだけで、その他はプログラムを組んでさえいれば、誰からもとがめられることはありません。早く作業が済むと、ついつい、そのシステム全体のユーティリティを作ったり、データベースや重要ファイルのプライベートツールを作成したりして、お客さまからも喜ばれていたのです。
そのお客さまの1つが有名な病院を運営しており、私は深夜に当番の医師とよく話をしていました。何カ月かすると、「医師が患者を診てどういう病気か? どういう薬が効くのか判断できるなら、そのパターンをコンピュータに組み込んでしまえば医師の作業が楽になるかも?」と思いついたのでした。当時はそれが素人考えであり、明らかに法律に抵触することとは思わず、深夜の待機時間中にせっせとプログラムを作成しました。
ほぼロジックが完成し、ある日の深夜、仲のいい当番の医師にその成果をこっそり見せましたが、医師は複雑な表情を浮かべてこう言いました。
「趣味でプログラムをしたとはいっても、就業時間の範囲ですよね……。通常は仮眠をとるはずの時間なので、そこはまずいのではないかと……」