現在の金融機関にとってIT部門は会社の1部門ではなく本来業務の中心である。
営業、契約管理、会計処理などすべてコンピュータに頼っているので、これがトラブルを起こすと
業務ができなくなる。そしてコンピュータシステムは常に更新する必要がありシステム開発を伴う。
社長が営業や内務部門等の出身でシステムに関する知識・経験がない場合は基幹システムの開発などは
システム担当役員に任せきりになり、その結果失敗して会社の屋台骨が揺らぐこともままある。
大手銀行でもシステム開発に失敗してオンラインがストップし当局から経営責任を問われたことがあるし、
最大手の損保会社でも基幹システムの問題でオンラインがストップしたことがある。
昔の保険会社ではIT部門は機械計算課とか電算課などと呼ばれる小さな組織で、契約をキーパンチャーが
カード穿孔機でパンチカードに入力し、月次処理といって月に1回まとめて契約処理を行った。
業務量が増え計算機センターが24時間体制になると、オンラインリアルタイム処理が必要となり、
全国にオンライン端末機を設置する必要が出てきた。
筆者がシステム部門に配属されたのはこの時期で全国オンライン計画では当事者として参加した。
その当時端末機の操作には特別な知識が必要とされたが、全国の端末機をオンラインで結ぶ計画では
特別な知識がなくても操作できるユーザーフレンドリーなシステムを目指して、あえてシステム要員ではなく
ユーザー部門の人間を集めてIT教育を施しシステム設計を行った。
しかし3年経ってシステム設計が終わり、残り2年で実際に組み上げる段になって、技術上の問題が発生して
それまでの設計ではどうにもならなくなり、計画が頓挫しかかった。
このときこの会社はシステム開発について副社長が直接指示を出すようにした。
営業出身だった開発責任者のシステム部長はふてくされていたが、副社長は若い頃この会社の計算機導入に関わった人で
自分自身もプログラムを勉強してシステムに精通していた。
副社長はまず他部門に異動していた専門技術を持つ社員をシステム部門に呼び戻し
それまでの複数ベンダーを1社に統一して責任のなすり合いができないようにし、
各部門から上がっている新システムに関する要望を必要最低限まで切り詰め、
経費を抑えつつ高性能のホストマシン（大型計算機）を導入するためそれまで金融機関では例がなかった中古の大型計算機を導入した。
さらにホストマシンの計算負荷を減らすために端末機もこれまでに例がなかったPCによるインテリジェント端末に
置き換えて分散処理とした。これもトップが最新の技術を理解していないとできないことだった。
技術部門がいかに新技術の優位性を説明しても通常トップは安全性を考えてどうしても実績のある従来の方法にこだわるが、
システム部門発足時に計算機導入を自身でやってきた副社長は業界初の技術をためらわずに導入した。
その結果残りの2年で業界初の全国オンラインネットワークが完成した。
その後転職した先の外資系の保険会社ではトップはシステムに精通しておらず、それまでの基幹システムは本国のものを
使っていたので社内にシステム技術者がおらず、新しく作る基幹システムの構築をコンサルティング会社に任せていた。
コンサル会社は経費を抑えるためにインドのシステム開発会社を使い、運用を行うはずの日本のシステム部門とのやりとりには
通訳を入れた。この結果実際に開発を行うインド人の技術者は日本語がわからず。日本のシステム部門の人間は英語がわからず、
通訳はシステムの専門知識がないためコミュニケーションがうまくとれず開発は失敗した。
次に再び日本の保険会社に転職したのだが、この会社は自社コンピュータを持たずシステム運用の経験がなかったため
外部からシステム開発の専門家を採用して新基幹システムの開発を任せた。
しかし開発を任せたはずの専門家には権限を与えず、開発の総指揮を任されたのはシステムを全く知らないプロパー役員で、
しかも本来の担当だった商品部門との兼任だった。常識的に考えても会社全体の問題である基幹システム開発の担当役員が
兼任というのは土台無理な話でシステムを知らないトップの認識不足だった。
この担当役員の下で実際にシステム開発をすることになった専門家は担当部長という役職で社内的に何の権限もなく、
社外から転職で来たため社内の人脈もなく、他部門からの協力が得られないまま苦労の末、結局開発は失敗した。
最初の会社が途中で頓挫しかかったにもかかわらず結果的に成功したのは最終的に開発の責任者となった副社長がシステムに精通していた
ことと、副社長であったため社内の各部門に対して予算でも人事でも最優先に進めることができたからである。
どこの会社でも予算や人材の取り合いは最後は力関係で決まるので、基幹システム開発にはこの権限が不可欠である。
失敗した2社は会社のトップにシステムに関する知識がなかったことと開発担当者に権限がなかったことが失敗の根本的な原因である。
似たような失敗事例は現在でも列挙に暇がないが、失敗を公表して損失補填を公表するのは正直な会社で、タチの悪い某社は
開発失敗を金融庁に知られることを恐れて開発は失敗ではなく延期だと発表して某監査法人も巻き込んで損失を隠蔽したりしていた。
もちろん延期された計画が再開されることはなく、その後経営者が変わった後でも同様の失敗を繰り返している。