ソフトウエアの「中の人」が消える

ソフトウエアの「中の人」が消える、日本企業が犯した愚かな過ちの本質
2021.9.2
5件のコメント

木村 岳史=日経クロステック/日経コンピュータ
https://business.nikkei.com/atcl/gen/19/00322/082300009/?n_cid=nbpnb_mled_mre

『普通ならブラックボックスには必ず「中の人」がいるものである。何の話かと言うと、ソフトウエアのことだ。ソフトウエアはとても便利だが、それを利用する人を「無知」にする。なぜ無知になるかは単純な話で追々説明するが、利用者が無知になっても大丈夫なようにするのが、中の人である。ところが日本企業や官公庁のシステムでは往々にして、その中の人がいなくなる。これはもう真夏の夜の怪談より恐ろしい。

 ソフトウエアによってブラックボックスが生じるというのは、企業システムでは常識だと思っていたが、どうやらそれも分からない「非常識」な人も多いようだ。なぜそう言えるのかというと、これも後で改めて触れるが、RPA(ロボティック・プロセス・オートメーション)の一大ブームが日本企業の間で続いているからだ。本当に後が怖いのに、後先を考えずに導入を進めるIT部門などの愚かさを見せつけられると、ブラックボックス化の問題を認識していないのだと思わざるを得ない。

 そんな訳なので、まずはソフトウエアが生み出すブラックボックスについて説明しよう。ソフトウエアによるブラックボックス化は3つの領域で起こる。1つ目はコンピューターシステム自体のブラックボックス化だ。もっと正確に言えば、ソフトウエアは自分より下位レイヤーのハードウエアやソフトウエアをブラックボックス化する。

 つまりこういうことだ。今、業務アプリケーションなどを開発している技術者は、コンピューターが「なぜ動くのか」について分かっているだろうか。恐らく分かっている技術者はほとんどいないだろう。つまり、自分がつくっている業務アプリがなぜ動くのかも分かっていないはずだ。コンピューターのハードウエア上では全てのソフトウエアがデータと共に、0と1のビットとして論理回路などで処理されるが、そうしたコンピューター処理の原理をしっかり説明できる人は少ない。

 ソフトウエアの領域でもそれは同じことだ。業務アプリを開発する技術者は、いわゆるOSやミドルウエアがどんな働きをするかという概要と、それを利用するためにはどうすればよいかを知っていればよく、その中身(ソースコード)は知らなくてよい。ITベンダーの製品なら全く知らないし、オープンソースソフトウエア(OSS)でも中身を知る人は限られている。業務アプリを開発する技術者でさえこうであるから、業務アプリを利用するユーザーに至っては全く知るよしもない世界である。

 だがコンピューターの黎明(れいめい)期には、そうではなかった。業務アプリを書く技術者もハードウエアやOSなどに精通している人が多かったし、中にはユーザー企業の技術者なのに独自のプログラミング言語を開発してしまう人もいた。時代は下ってインターネットが普及し始めた頃は、ネットワーク技術者でもないのに通信プロトコルを熟知する人がごろごろいた。そして今、その辺りの下位レイヤーは全てブラックボックス化され、業務アプリの技術者は知るよしもない。つまりその分、技術者は無知になったのである。
パソコン画面の「こちら側」までブラックボックス化

 さて、2つ目のブラックボックスだ。こちらは1つ目のテクノロジーサイドと違って、業務サイドのブラックボックス化だ。こちらは極めて分かりやすい話だ。例えば、企業そして官公庁などの基幹系システムは、その組織の業務のやり方や業務プロセスなどをソフトウエアの機能として組み込んでいる。以前に人が紙とペンとそろばんなどで行っていた個々の業務や、一連の業務の流れ(プロセス)がシステムによって機械化されている。

 随分前の話だが、日本企業にコンピューターシステムが導入され始めた頃を知るシニア技術者から、当時の話を聞いたことがある。昔、企業には社内の業務に精通した「生き字引」みたいな人が何人かいた。初めてシステムを導入する際には、そうした生き字引たちの協力も得て、自社の業務プロセスなどをほぼ全てあぶり出したそうだ。

 あぶり出した業務プロセスは紙に書いて、システム導入プロジェクトの推進室の壁一面に貼り出したとのこと。で、壁に貼り出された業務プロセスを眺めながら、会計処理など各業務のプロセスのどの部分を機械化(システム化)するのかを、業務担当者やITベンダーの技術者などを交え、かんかんがくがくの議論をして決め、会計などのシステムを順次構築していったという。

 そんな訳なので、企業システムの黎明期には、多くの日本企業で業務プロセスが完全に見える化されていた。それを基に業務の一部をソフトウエアによりシステム化したものだから、システム導入によって業務はものすごく効率化された。ただ、業務プロセスなどがソフトウエアの機能として組み込まれた途端、ブラックボックス化も進んだ。業務担当者は時を経るに従って、システム化する前にやっていた業務を忘れてしまうからだ。

 しかも半世紀近くの時を経て、今やソフトウエアでブラックボックス化された業務の範囲は広大になった。特に大企業では、従業員はパソコン画面の「向こう側」で処理されている業務プロセスについてほとんど無知と言ってよい。そういえば、システム化の進んだ大企業では、従業員が自社の業務を知らな過ぎることにIT部門が危機感を持ち、ソフトウエアのブラックボックスの中で粛々と処理されている業務プロセスを、何らかの形で従業員に「見せよう」というプロジェクトを進めていると聞いた。

 このソフトウエアによる業務のブラックボックス化は、もう行き着く所にまで行き着いた感があったが、さらに「延長戦」があった。それが日本で一大ブームのRPAの導入である。RPAではご存じの通り、システムからデータを「コピペ」して他のシステムに入力するなどの作業を自動化するソフトウエアロボットを多数つくり出す。これによりパソコン画面の向こう側だけでなく、「こちら側」に残されていた業務までをブラックボックス化してしまうわけだ。

 ソフトウエアロボが代行する作業の多くは、単純作業だけれどもシステム化できなかった領域だから、目先の業務の効率化への貢献度は大きい。人海戦術でデータ入力などをしてきた企業では、コンピューター黎明期のシステム導入に匹敵するくらいの効果があったりする。だから、業務の変革でも何でもないのに「我が社のDX(デジタルトランスフォーメーション)の成果だ」と悪ノリする経営者は多い。しかも、既存のシステムだけでなくRPAで業務を二重にブラックボックス化する恐ろしさに気づいていないのだ。

ブラックボックス化しても「中の人」さえいれば

 ソフトウエアによるブラックボックス化の3つ目の領域は、ソフトウエア自身のブラックボックス化だ。これは1つ目に挙げた「下位レイヤーのハードウエアやソフトウエアのブラックボックス化」とは意味合いが全く違う。抽象度を高くして述べたので「何のことだ」と不審がる読者もいると思うが、種明かしをすれば「何だ、そのことか」と言うだろう。例のトホホなブラックボックス化である。

 つまり、基幹系システムなどのソフトウエアが長年の改修作業でスパゲティ化して、改修を担当する技術者以外はプログラムコードを「解読」できなくなる現象である。そういえば、「2025年の崖」で有名になった経済産業省の「DXレポート」では、基幹系システムでのこのブラックボックス化を、企業のDXを阻む深刻な問題として取り上げていたな。

 こちらのブラックボックス化が深刻な問題となるのは、2つ目に挙げた業務のブラックボックス化ともつれ合うように進むからだ。業務のブラックボックス化が進行するのは、単に業務担当者がシステム化以前の業務を忘れてしまうからだけではない。その後の業務の変化もブラックブックス化に寄与する。業務の変化は、新商品の発売に伴ってのことかもしれないし、法制度対応のためかもしれない。はたまた何らかのカイゼン活動の「成果」を取り入れたのかもしれない。いずれにせよ、そのたびにソフトウエアは改修されていく。

 結果として、業務はどんどん変わり複雑になっていくが、その複雑さの大半はソフトウエアの機能として、つまりシステムで処理されるから、従業員の仕事が複雑になっていくわけではない。ただし業務プロセスなどはますます分からなくなっていく。しかも、こうした業務の変更に伴うソフトウエアの改修などによって、ソフトウエアもどんどん訳が分からなくなる。技術者不足や緊急の改修要求などのせいで場当たり的な改修が繰り返されるケースが多いから、いつの間にか担当の技術者以外には理解できないスパゲティ状態となる。

 ただし、ソフトウエアによるブラックボックス化は、ただちに大きな問題になるわけではない。記事の冒頭で書いた通り、ブラックボックスには「中の人」がいるからだ。中の人とは、ハードウエアやOS、ミドルウエアなどの場合で言えば、それらの製品を開発・保守しているITベンダーの技術者たちだ。一方、2つ目と3つ目、つまり業務のブラックボックス、そしてスパゲティ化によるソフトウエア自体のブラックボックスでは、システムの保守運用を担う技術者が中の人に相当する。

 中の人がいるからといって、安心してよいというわけではない。中の人が突然いなくなることもあるからだ。あっ、そうだ。「突然いなくなる」というのは表現がおかしいな。十分に時間があったにもかかわらず、事の重大性を認識しようとせずに放置し、そのうちに中の人がいなくなるケースがほとんどだ。3つの領域のブラックボックスの全てで中の人がいなくなり、「このシステム、どうするんだ」とぼうぜんとしている企業もあるから、まさに中の人の消滅は真夏の夜の怪談より恐ろしいのだ。

RPA導入が恐ろしい理由は「中の人」の不在

 基幹系システムなどを利用する業務担当者から自身の絡む業務プロセスが見えなくなっても、保守運用を担当する技術者はブラックボックスの中の人として、少なくとも自身の担当する範囲の業務を把握している。プログラムコードがスパゲティ化して他の技術者にはソフトウエアがブラックボックスになっても、担当の技術者は自身がぐちゃぐちゃにしてきたコードだから、そのコードに手を入れられる。

 そんな訳なので、これらのブラックボックスの中の人である技術者は、本来ならとても貴重な存在だ。ところが、その価値はあまり認知されておらず、中の人が「外の人」だったりする。何の話かと言えば、IT部門が丸投げ体質で、システムの保守運用をITベンダーの常駐技術者に頼り切っているケースだ。これは企業だけでなく官公庁でもおなじみの話。自分たちの業務もシステムも「外の人」しか知らないのだから本当に恐ろしい。

 で、この中の人ならぬ外の人がいなくなるという事件が起こる。例えば、企業なら毎年のように保守運用料金の値下げをITベンダーに要求し続けた場合に起こり得る。ITベンダーは当初、値下げ要求をのんで常駐技術者の人数を減らすなどして対応するのだが、そのうち採算面で耐えられなくなり、常駐技術者の疲弊や不満も限界に達する。ついにITベンダーが撤退を通告し、ブラックボックスの中の人は誰もいなくなる。これは「本当にあった怖い話」だ。

 ちなみにRPAによる業務のブラックボックス化の場合、そもそも初めから中の人がいない。RPAの導入前にデータの入力業務などを担っていた人は、派遣など非正規雇用の人が多く、RPA導入から時を置かずにいなくなってしまう。正規雇用の従業員も別の業務に就くから中の人ではない。RPA導入を支援した技術者も中の人を続けることはない。かくして中の人がいないままソフトウエアロボは動き続ける。さて将来、何が起こるか。乞うご期待、である。

 もう1つのブラックボックス、つまりハードウエアやOS、ミドルウエアなどの中の人がいなくなるというのは、なかなか想定しにくいかもしれない。だが、これは極めて頻繁に発生する。何せ日本企業は最新の製品、最新バージョンのソフトウエアを使いたがらない。古い製品、古いバージョンのソフトウエアを使い続けているうちに、ITベンダーが製品に対する保守サポートを停止し、開発や保守に携わった中の人である技術者も担当を外れていなくなるというわけだ。

 企業によっては、3つのブラックボックスの全てで中の人がいなくなったという悲惨な話もある。中堅クラスの企業での悲話だが、随分前に構築した基幹系システムを延々と使っているうちに、ハードウエアやOSなどはサポートが切れた。それでも問題ないと判断して使い続けているうちに、今度は基幹系システムのブラックボックスの中身を知る唯一のIT担当者が退社し、中の人は消滅してしまった。社長が事の重大性に気づいたときは、まさに後の祭りだったという。

 さて、いかがだったであろうか。この「極言暴論」ではブラックボックス化問題を何度か取り上げているが、今回は「中の人問題」の観点でまとめてみた。結局のところ、企業が何もしなくても、いつまでも中の人として献身的に尽くしてくれる技術者やITベンダーなどいないということだ。付加価値の少ない基幹系システムにはITベンダーに中の人が大勢いるパッケージソフトウエアやクラウドなどをそのまま使い、どうしても独自システムが必要ならば自社で中の人を育てるしかない。そう思うが、いかがか。』

みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃

みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃
岡部 一詩 日経 xTECH/日経FinTech 山端 宏実、中田 敦 日経 xTECH/日経コンピュータ
2019.09.06
有料会員限定
https://xtech.nikkei.com/atcl/nxt/column/18/00942/082900007/

※ この記事でも、「前代未聞の規模」」と言っているな…。

※ そうやって開発した、「前代未聞のシステム」なわけだ…。

※ ベンダーは、「とっとと逃げる」わけだよ…。

※ 支払いの様子は、どうだったんだろう…。

※ 「気持ち良く、支払ってくれた。」ならいいが、これが「散々、苦労かけた上に、渋ちんでした。」ということだと、「二度と、お付き合いするのは、ゴメンです。」ということになる…。

※ そうやって、ふと気づいて辺りを見渡すと、「誰も、いなくなっている…。」…、という話しになるんだよ…。

『新システム「MINORI」の開発に参加したITベンダーの数は、前代未聞の規模に膨れ上がった。取りまとめ役であるみずほ情報総研(IR)の1次委託先だけで70~80社。2次委託先、3次委託先を合わせると約1000社に上る。総務省の調査によると情報通信業を手掛ける企業数は5474社で、子会社や関連会社を含めても9806社(2015年度)。実に日本中のITベンダーの少なくとも約1割が集結した。

 とりわけ重要な役割を担ったのが富士通、日立製作所、日本IBM、NTTデータの主要4ベンダーだ。MINORIを構成する業務アプリケーションの大半を開発した。

 富士通は銀行業務の中核となる「流動性預金」を中心に担当。日立は「外国為替取引」などを手掛けた。日本IBMはメインフレームをはじめとする基盤提供を主な役割とし、NTTデータはPMO(プロジェクト・マネジメント・オフィス)の支援を担った。

 主要4ベンダーを含め、プロジェクト終盤で組織した「トップマネジメント定例」の構成企業16社が、外部委託した全開発工数の約4分の3を占める。

図 主要機能と担当ベンダー
実績を重視して選定
[画像のクリックで拡大表示]

「難しい判断」と富士通

 みずほ銀行がベンダー選定で重視したのは実績だ。流動性預金が分かりやすい。流動性預金は特にトランザクションが多い業務アプリケーションであり、ミッションクリティカルな運用が求められる。日本IBM製メインフレーム上で稼働させることを決めたが、アプリケーションの開発は旧システム「STEPS」を開発・保守してきた富士通に委託した。「流動性預金は銀行業務の根幹。長年信頼関係を築いてきた富士通が最適と判断した」と、みずほ銀行の石井頼幸IT・システム統括第一部副部長は説明する。

 富士通の馬場俊介みずほ事業部事業部長は、「当社は既存システムを手掛けてきた立場。IBMの基盤上でアプリケーションを開発する判断を下すのは正直難しかった」と明かす。とはいえ、これだけの大型案件に参画しないわけにはいかない。富士通はみずほフィナンシャルグループ(FG)の提案を受け入れた。

 基盤とアプリ開発のベンダーが異なることで特有の難しさも生じた。富士通はIBMの基盤上で動作するCOBOLプログラムを開発しなければならなかった。「プロジェクトの初期段階である2012~2013年にかけて、膝詰めで技術検証した」と、日本IBMの林勇太金融第二ソリューション・デリバリー 統括部長は振り返る。結果として、富士通の開発ツールで生成したプログラムに起因する大きなトラブルは1度もなかったという。

 MINORIの開発においてITベンダーは単なる手足ではない。みずほFGはプロジェクトの序盤と終盤に特別な会議体を発足し、主要ベンダーの知恵やノウハウを活用している。

図 みずほ情報総研の委託先体制

国内ITベンダーの少なくとも1割が参加
[画像のクリックで拡大表示]

左から日立製作所の服部善成事業執行役員、富士通の馬場俊介みずほ事業部事業部長、日本IBMの林勇太金融第二ソリューション・デリバリー統括部長、NTTデータの荻田直人メガバンク統括部第一開発担当部長
[画像のクリックで拡大表示]

『有識者会議を週3回ペースで開催

 最初に発足したのが、新システムのアーキテクチャーや実装方針を議論する「技術アドバイザリーデスク」。2012年11月のことだ。みずほ銀行やみずほIRのメンバー10人に加え、主要4ベンダーから各社2人ずつ、部長級の有識者が出席した。

 「所属企業の意識は捨てて、みずほ銀行にとって最適なシステムの在り方を議論してもらった」と、みずほ銀行の間仁田幹央IT・システム統括第一部次長は振り返る。ベンダーの垣根を越えて議論するため、個別にNDA(秘密保持契約)も締結。情報交換の活性化を促したという。

 技術アドバイザリーデスクでの議論は、既に採用が決まっていたSOA(サービス指向アーキテクチャー)の実現方法が中心だった。最も苦労したのが各業務アプリケーションを構成する「商品サービス」の粒度だ。利用頻度が高いサービスは粒度が小さい方が再利用性が高まる。逆にあまり使われないものは、大きい粒度でまとめた方が効率が良い。この最適解を探るため、多い時で週3回、それぞれ2時間に及ぶ議論を重ねた。

 プロジェクト終盤の2017年5月には、3つの会議体からなる「トップマネジメント定例」と呼ぶ取り組みを始めた。参加メンバーはMINORI開発の大部分を担う16社だ。「この16社が抱える問題を解決していけば、プロジェクトを正確な方向に導けると考えた」と、みずほIRの向井康真社長は話す。開発完了とシステム移行を目の前にして、開発の進捗や課題を正確に把握し、移行準備に万全を期す狙いがあった。

関連記事:みずほシステム統合の謎、勘定系の「老朽化」問題は解決したのか
関連記事:みずほシステム統合の謎、時代遅れのバッチ処理は「解体」できたのか
関連記事:みずほシステム統合の謎、メインフレームは無くせたのか』

自治体システムまだ昭和仕様

自治体システムまだ昭和仕様 標準化阻むご当地主義
https://www.nikkei.com/article/DGXZQOUA1057X0Q1A810C2000000/

『9月発足のデジタル庁が挑む重要テーマの一つに地方自治体のコンピューターシステムを共通仕様にする「標準化」がある。現状では住民の氏名や住所などの基本データの保存法すらそろっておらず、ご当地仕様が乱立する。開発した業者しか保守管理できず、コストも高止まりしやすい。「昭和」の名残が色濃いシステムでは、デジタル行政の実現は遠い。

氏名、住所、生年月日、性別――。自治体が管理する住民の「基本4情報」すら、現状ではシステムごとにデータ形式が異なる。

例えば氏名。大手Aが手掛けるシステムは姓・名を別々に保存するが、大手Bは姓名で1データだ。住所も大手Cのシステムでは、都道府県名・市町村名・番地・建物名が別々のデータだが、大手Dは都道府県から番地・建物名までで1データだ。生年月日も西暦と和暦の扱いなどに独自仕様が多い。

数十自治体でシステムを入れ替えたTKCの松下邦彦デジタルガバメント対応推進部長は「同じ情報でもデータ形式が異なれば外部連携やシステム乗り換えがしにくくなる」と話す。

大きな自治体ほどシステムが独自化する傾向がある。総務省によると、人口10万人以上の自治体の約8割が独自仕様だ。

弊害は大きい。独自システムの保守管理を担えるのは開発当時から関わる特定業者だけになりがちだ。委託先を変更しようとしても他の業者には技術面でハードルが高く、事実上、新規参入できない。「ロックイン(囲い込み)」と呼ばれる現象だ。競争が阻害され、非効率な旧式システムに巨費が投じられ続ける構図を生む。

現在の住民基本台帳制度が始まったのは1967年。日本のデジタル産業の勃興期と重なる。60年代以降は富士通や日立製作所、NECなどがコンピューター生産に乗り出した。70年代以降、自治体への大型コンピューター導入が加速し、業者間の競争も激しくなった。その結果「自治体ごとに独自開発やカスタマイズされたシステムが導入された」(TKCの松下氏)。

政府内では過去にもバラバラ仕様を統一する「標準化」の機運はあった。情報システム学会の砂田薫会長は電子政府構想を掲げた2001年のe-Japan戦略を挙げる。戦略に標準化の文言はあったが、インターネット普及率の底上げなどに重点が置かれた結果、実現しなかった。

今回も順調に進むと考える専門家は少ない。システムだけでなく業務にもご当地仕様が多いことがもう一つの懸念材料だ。

総務省が進める地方税システムの標準仕様の検討で、象徴的な出来事があった。

地方税実務は自治体によって大きく異なる。システムをそろえるにあたり、自治体から「未納なしの証明書は非課税でも出す必要がある」「固定資産税の減免は金額も入力できるように」など4万件超の意見が寄せられた。すべての要望に応えるのは到底不可能だ。

人材難も想定される。バブル崩壊後の90年代以降、システム保守・運用の外注が進む。システムを運用できる情報部門の人材は90年代までは各自治体に20~30人ほどいたとされるが、総務省の調査をもとにすると現在は平均5人ほどだ。「組織の体制縮小を危惧する声もあったが、外注頼みは止まらず仕様書を書けないほど調達能力は低下した」(行政情報システム研究所の狩野英司主席研究員)

システムの不統一や外注頼みは官民問わず、様々な分野で起きた世界共通の課題だ。IT(情報技術)先進国の北欧諸国や韓国などは一足先に対策をとってきた。

国連の電子政府ランキングで上位常連の韓国は政府傘下の地域情報開発院(KLID)が自治体向け業務ソフトを開発する。大企業の入札参加を排除し、囲い込みも防いだ。11年にデジタル化庁をつくったデンマークも中央政府と自治体が国民の基本情報だけでなく、居住環境などのデータ基盤を10年がかりで整備した。

英国やオーストラリア、エストニア、イスラエルなどは専門人材の招請にも熱心だ。豪ビクトリア州保健福祉省は外部の専門家を招き、省内でプログラマーを育成するなどして、外注頼みだった州の保健福祉関連システムの内製化に成功した。カナダ政府は米国連邦政府一般調達局などの専門家を招き入れている。

各国は14年設立の「デジタル・ネーションズ(DN)」と呼ばれる国際連携の枠組みに加入し、専門人材の交流や情報交換にも取り組む。日本のデジタル庁も国際的なネットワークに食い込み、先行事例や優秀な人材を取り込む不断の努力が欠かせない。

〈Review 記者から〉デジタル刷新 雇用にも課題

自治体システムの課題を探ると、人材と雇用の問題を口にする専門家が多い。雇用が流動的な国ほど古いシステムからの脱却がうまくいく傾向がある。逆に日本はIT(情報技術)人材の雇用が安定しているがゆえに、脱却が遅れがちだともいえる。

情報処理推進機構の国際比較調査では、日本のIT人材の希望勤務年数は約5割が「定年まで・働ける限りずっと」だった。発注する側も受注する側も、属人的で長期的な関係に「安定」を見いだすのだろう。だが、それはロックイン(囲い込み)と背中合わせだ。

インドやシンガポールの希望勤務年数は「2~5年」、米国や英国は「5~10年」が最も多い。雇用流動性が高い米国やオーストラリアなどは、政府・自治体で「システムとともに人員も合理化することもある」と行政情報システム研究所の狩野英司氏は指摘する。

スタートアップ企業のエンジニアなどが、2~3年で活躍の場を変える光景は日本でも珍しくなくなった。だが退職金や税などの制度も含め、日本の雇用環境は流動的な働き方への対応が進んでいるとは言いがたい。

政府が取り組むシステムやデータの標準化は、北欧先進国でも10年単位の年月をかけて進めた一大プロジェクトだ。聞こえのよい標語や目標を掲げるだけでなく、デジタル化を阻害する真因を非デジタル領域も含めて検証することもデジタル庁が担うべき課題だ。

(デジタル政策エディター 八十島綾平)

住民記録や地方税、25年度までに標準化

 大阪市に電子計算機が導入された1960年以降、自治体業務への大型コンピューターの導入が加速した。この時期、旧通商産業省は国産コンピューター振興策を進め自治体での国産機導入率は9割を超えた。コンピューターでの日本語処理が増えた80年代以降、メーカー独自の文字入力方式などによってシステムは独自性を増し、90年代以降のパソコン時代も自治体ごとのカスタマイズが常態化して「バラバラ」は改善されなかった。
長年の課題を解決するため、政府は2025年度までに住民記録や地方税など17業務で標準化を進める。システムの機能の標準化は各業務を所管する省庁が担い、データの標準化はデジタル庁が担当する。』

銀行勘定系システム刷新、大規模障害で揺らぐ選択

銀行勘定系システム刷新、大規模障害で揺らぐ選択
https://www.nikkei.com/article/DGXZQOUC155500V10C21A7000000/

 ※ 残念ながら、システム開発にも、プログラミングにも、コーディングにも、仕事として関わった経験は無いんで、確たることは言いかねる…。

 ※ しかし、「システムの改変・進歩」と言ったことは、「5G」については、随分と文献も調べたんで、その観点から感想を語っておく…。

 ※ それは、「システムの進歩」と言うものは、「日々の業務の遂行・執行の中にこそ、そのタネがある。」ということだ…。

 ※ 「5G」の場合は、明確に「10年単位で、通信データの級数的な増大」というものが有り、関係者一同「その爆発的な増大に対処するための、「仕様」の改変・策定」という共通認識があって、それが「新ジェネレーション策定」の原動力となっているような感じだった…。

 ※ そして、その「問題意識」「改変のタネ」は、「現在のジェネレーション」「現在の規格」の中にこそ、潜んでいる…。

 ※ 絶えず、「ここをこう改変したら、もっと速く、もっと大量に、もっと多接続で、データを送信できるのではないのか。」と考え続け、「新規格を提案する」ことが、「次のジェネレーションの規格」を形作って行く…。

 ※ そういう「日々の改変への志向・ベクトル」が無いところに、いきなり「システムを全面刷新」したところで、「木に竹を接ぐ」と言うものだろう…。

『銀行業務の基幹である勘定系システムの刷新を巡り、銀行間で明暗が分かれている。全面刷新に踏み切ったみずほ銀行などで大規模システム障害が起きた一方、アプリケーションの刷新は一部にとどめ、システム基盤の更改を進めた銀行で目立ったトラブルは起きていない。移行コストやリスクを抑えるため「勘定系システムは塩漬けでいい」という声も強まるなか、その選択肢は果たして持続可能なのか。

みずほ銀行と静岡銀行に共通点

2021年に入り、銀行で大規模なシステム障害が2件起きた。1つがみずほ銀行だ。2月28日、定期性預金システムのトラブルがATMに波及し、4000台以上のATMが稼働を一時停止した。しかも、それから2週間あまりで立て続けに別の3件ものシステム障害を起こした。

もう1つが静岡銀行だ。1月4日に他金融機関から同行宛ての振り込みの一部が遅延したり、セブン銀行のATMで同行口座の入出金ができなかったりするシステム障害が起きた。その後も二重振り込みなどトラブルが続発した。

実は両行には共通点がある。勘定系システムを全面刷新したことだ。

みずほ銀行は19年7月、4000億円台半ばを投じて、新勘定系システム「MINORI」を本格稼働させた。新システムは旧みずほ銀行の勘定系システムである「STEPS」や旧みずほコーポレート銀行の「C-base」、みずほ信託銀行の「BEST」からソースコードを一切引き継がず、新規開発した。

静岡銀行は21年1月、日立製作所と共同開発した勘定系システムを稼働させた。旧システムは富士通製メインフレーム上で動作していたが、オープンソースソフトウエアであるLinux(リナックス)ベースの新システムに置き換えた。

当初は17年中の稼働を見込んでいたが、業務分析や現行システムの解析などに手間取り、稼働時期を2度延期した。産みの苦しみが大きかっただけに、新システムの稼働は悲願だった。

問題の先送りではないのか

両行の大規模トラブルは、今後の勘定系システム論議に大きな影響を与えそうだ。勘定系システムのアプリケーション部分に極力手を加えず、オープン化やクラウド移行などシステム基盤の更改にとどめる銀行が増える可能性がある。

事実、両行の大規模トラブルに前後する形で、こうした方針を打ち出す銀行も出始めている。横浜銀行や北陸銀行、北海道銀行、七十七銀行、東日本銀行の5行は24年1月にも、共同利用システム「MEJAR」について、富士通製メインフレームからLinuxベースのオープン基盤に移行する。ただし、アプリケーション部分はNTTデータの勘定系パッケージ「BeSTA」を温存する。

三井住友銀行は25年度までに勘定系システムを刷新するが、既存のプログラム資産にほぼ手をつけず、システム基盤の更改とアーキテクチャーの見直しを主体にする。移行コストとリスクを限定するためだ。投資額は約500億円で、みずほ銀行がMINORIの開発に投じた金額の9分の1程度の水準だ。

勘定系システムを手掛けるNTTデータや日本IBMといった主要IT(情報技術)ベンダーもこうした方針を後押しする。

全面刷新を避ける潮流に対して、1つの疑問が浮かぶ。アプリケーション部分に手をつけず、システム基盤の更改に限定するのは、問題の先送りではないかという点だ。勘定系システムを塩漬けにし、中身を知る人材がいなくなれば、新サービスの開発に時間を要し、システム障害の影響も拡大しかねない。

一方、勘定系システムの全面刷新は莫大なコストや大規模障害のリスクを抱える割に、メリットが見えづらいという側面もある。

コストやリスクを抑えながら、いかに時代の変化に対応しやすい仕組みを手に入れるか。現実解はシステム基盤の更改と並行し、商品・サービスや事務プロセスの整理を進めることだろう。こうした地道な取り組みが将来の選択肢を広げることになる。

(日経クロステック/日経コンピュータ 山端宏実)

[日経クロステック2021年7月15日付の記事を再構成]』

地銀、深刻なIT統治不全 ベンダー頼みのツケ重く

地銀、深刻なIT統治不全 ベンダー頼みのツケ重く
金融PLUS 金融グループ次長 亀井勝司
https://www.nikkei.com/article/DGXZQOUB212F90R20C21A6000000/

 ※ どうも、最大の問題点は、「銀行側に、ITに精通した人材が無く」「ベンダー側に、経営・業務に精通した人材が無い」というところのような気がする…。

 ※ その両方の領域を、つなぐ人材が、決定的に欠いているという気がする…。

 ※ これを、「プライオリティの判断」という観点から見れば、従来・旧来の「銀行経営におけるプライオリティの判断」と、「IT導入におけるプライオリティの判断」が、決定的に乖離しているという気がする…。

 ※ 例えば、あるITシステムを導入しようとしているとする…。
 当然、そこにおいては、「導入することによるメリット」と、「導入したことによるデメリット」があり、そこを「抽出」「利益衡量」することが必要となる…。
 
 ※ さらには、「パッケージソフト」を導入して、安上がりに上げようと考えたとする…。

 ※ その場合、その「お仕着せ」による従来の業務執行形態を「変える必要があるのか、否か」「そのメリット・デメリット」の利益衡量をどう図るのか、などという問題も出てくる…。

 ※ 「お仕着せ」からハミ出した、「特殊業務」を残すのか否か、そこを組み入れて、一から「システム発注」するのか否か、その場合の後々の保守・管理業務のコスト計算をも含めた「プライオリティの判断」が必要となる…。

 ※ こういうものは、従来・旧来の「銀行の経営判断」とは、全然違う…。

 ※ そういう「判断」や、その判断に必要な「要素の抽出」が、できる体制になっているのか…。人材、手順の構築は、なされているのか…。

 ※ そういう辺りが、決定的に重要なんだろう…。

 ※ さらには、「新技術」への対応・拡張性…、という問題もある…。

 ※ オンプレミス全盛時に、クラウド環境への「備え」を考えておくということは、不可能事かもしれない…。「神対応」かもしれない…。

 ※ しかし、そこの「備え」が無いと、「後れを取って」、競争における敗者となる…。

 ※ こうして検討してみると、いわゆる「日本企業」が、決定的に「苦手」としている「分野」「事例」のようだな…。

『みずほ銀行で起きたシステム障害は、システムが銀行経営に死活的に重要なことを端的に示した。ただその重要性と裏腹に、銀行、とくに地方銀行自身が主体的に関与できているかといえば疑問符がつく。』

『「監視を厳しくしないといけない。システム対応できないか」(地銀幹部)

「半年後になりますね」(システム会社)

NTTドコモの電子決済サービス「ドコモ口座」に絡む不正送金があった2020年9月。ある有力地方銀行とシステム会社で交わされた会話だ。新しいサービスの開発からマネーロンダリング(資金洗浄)につながる不正送金の対策まで、システムは銀行経営の要だが、開発や運用はシステム会社に頼っている実態が浮かぶ。』

『システム会社はベンダーと呼ばれ、みずほ銀行が4500億円を投じて導入した新システム「MINORI」は日本IBM、富士通、日立製作所、NTTデータの4社が中心となって開発した。もちろん、数千万口座を抱えるメガバンクと地方銀行のシステムには差があるものの、地銀も平均して年間50億円弱のシステム関連経費がかかっている。

金融のデジタル化が進み、システム部門の戦略的な位置づけは高まっているが、上位地銀でさえシステムの実務部隊はベンダーにほぼアウトソースしているところも多い。効率化の一環で自行のシステム人材をベンダー側に移管し、開発・運用を委ねている。ドコモ口座で問題になったインターネットバンキングから「○○ペイ」にチャージする場合も、自行からの出金にもかかわらず、その取引情報を保有しているのは銀行自身ではなくベンダーだという。』

『特定のベンダーの製品やサービスに強く依存することで、他社の同じような製品への切り替えが難しくなることをベンダーロックインと呼ぶ。言い換えれば囲い込みで、公正取引委員会もかねて問題視してきた。機動的に機能を追加したいと思っても時間と多額のコストがかかる。それでもベンダーに依存しているため「言い値」を受け入れざるをえない構図が浮かぶ。』

『銀行業務の基幹である勘定系システムを日本ユニシスからマイクロソフト社のクラウドサービスに移行した北国銀行のように、ベンダー丸投げと決別する地銀はまれだ。北国銀はクラウド上に集積した顧客データを活用し、取引やサービスの利用実態を人工知能(AI)などで分析。営業やコンサルティングにつなげる計画で、システムのフル活用を経営の中核にすえる。

システムに関していえばベンダーが銀行に対して優越的地位に立っているように見えるが、ある金融庁関係者は「だからといって地銀が『被害者』かといえば、それは一つの断面だ」と指摘する。ベンダーロックインが機動性を奪い、高コストになっている面は否めないが、ベンダー側からみれば「非効率で硬直的な事務を温存しているため、それをつなぐのに複雑な仕組みが必要になり、結果的にコストが高くなる」という声も漏れる。』

『実際、システムを共同化している信金と地銀のコストの差は、システムにあわせて事務も共通化しているかどうかの違いが大きい。システムと一言でいっても、債務者の情報を管理するシステムや取引内容を記録するシステム、担保物権を管理するシステムなど多岐にわたる。そのうえ、ほぼ取り扱いがない商品もスクラップすることなく新たな機能を付け加えようとすると、「結果的にアクロバティックなシステムになり、その分コストも上がる」(金融庁関係者)という。』

『自行に必要な機能を絞り込み、コストを減らして機動性を高めるために何が必要かを把握し、それにあわせて不要な事務を削る判断がIT統治(ガバナンス)だとすれば、ベンダーロックインはその欠如が招いた帰結にも見える。もっとも、マネロン対策など迅速に対策を打つ必要があるシステム改修で多額の費用を求め、より安価なサービスを提案する他社を阻むのは優越的地位の乱用だ。金融庁は銀行の委託先であるベンダーに立ち入り検査することもできる。

金融犯罪への対応は新たな手口が出てくるたびにシステム的な対応が必要になり、金融サービスのデジタル化もシステムの裏付けがあってこそだ。ベンダーロックイン問題は、「銀行はシステム産業」といいながらシステムを傍流に追いやってきた姿勢に変化を迫っている。』

『浅川直輝
日経BP 「日経コンピュータ」編集長
コメントメニュー

分析・考察企業内のITシステムを構築・運用する情報システム部門は本来、社内の業務とシステムの全体最適を考え、ときには経営陣や事業部門に「このやり方ではダメだ」と業務改革やサービス改革を迫ることもいとわない重要な部門です。

そんな情報システム部門の役割を外部のITベンダーに丸ごとアウトソースすれば、内発的な改革は起こりようがありません。ITベンダーも「良かれ」と考えて全てのIT関連業務を受託すれば、結果として顧客企業のデジタル変革(DX)の機会や意欲を奪う結果につながりかねません。

DXが企業競争力に直結する時代、企業とITベンダーの関係を今一度考え直すべきでしょう。』

IBMに逆転敗訴した野村HD

IBMに逆転敗訴した野村HD、強い事業部門抑えきれず
https://www.nikkei.com/article/DGXZQOUC1075J0Q1A610C2000000/

 ※ ヒデーもんだ…。

 ※ 木村岳史大先生の、「日本企業は、勝手にやっている現場の集合体。だから、DXは、絶望的にうまくいかない…。」との指摘そのままだ…。

 ※ こういう「勘違いヤロー」は、どこにもいるんだろう…。

 ※ おそらく、単に、個人としての立場だけではなく、「ある事業部門」全体・全員の「利益の代弁者」というような立場を、背負っているんだろう…。

 ※ しかし、プライオリティのつけ方が、根本的に間違っている…。

 ※ 一体、何のために、何の目的で「海外製パッケージソフト」を導入しようとしているのか…。

 ※ そこいら辺の、「大所・高所からの判断」及び「指揮監督」を行うのが、「経営判断」を担っている「上層部」「経営陣」ではないのか…。そいつらは、一体、何をやっているんだ…。

 ※ 上層部も、おそらく、「回っている現場」に手を突っ込んで、反発を買いたくないんだろう…。「触らぬ神に祟りなし」だからな…。

 ※ そうやって、「責任回避」しているうちに、傷口はドンドン広がり、事態はどうしようもなく悪化して行く…。

 ※ みずほのシステム障害の背後にも、こういう問題が横たわっているんだろう…。

 ※ しかも、みずほの場合は、それが「×3」だからな…。

『東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券の「X氏」の振る舞いだ。

当時、投資顧問事業部(判決文では「投資顧問部」)の次長だったX氏は、パッケージソフトに合わせて業務を最適化するという会社の方針に反して自身の現行業務を維持することに固執。プロジェクト途中で追加要件を多発し、日本IBMの担当者らに対して「辛辣な他罰的、攻撃的発言」(判決文)を繰り返した。

東京高裁は判決文でX氏について「自分の庭先(担当業務)をきれいにすることだけを考えている」と認定。断続的に変更要求を多発するX氏から、目標としていた13年1月の稼働開始に間に合うのかについて「質問がなかったのが不思議なくらいであった」(判決文)などと指摘した。』

『さらに判決文や裁判記録の資料を読み込むと、発注側という強い立場を利用したX氏の横暴な振る舞い、それをコントロールできなかった情報システム部門、この状況に振り回された日本IBMという構図が浮かび上がってくる。

東京高裁はX氏について「野村証券の投資SMAFWのフィー計算徴収の要件・ルール・計算手法等の知識を属人的に独占していた特定の1名の社員」(判決文)と説明している。』

『X氏は投資顧問事業部で複雑な業務を担い、新システムの要件を洗い出すうえで重要な立場にあったとされる。裁判記録によると、システム開発プロジェクトの体制はおおむね下記の通りだ。

同プロジェクトでは海外製パッケージソフトをカスタマイズ導入することになっていたが、概要設計フェーズの開始直後から要件定義書になかった追加要件が野村証券から多発した。

その後、設計・開発やテストフェーズに入っても変更要求は続出し、13年1月の稼働を諦めて総合テストの中止を判断するまで五月雨式に続いた。変更要求はX氏からだけではなかったが、多くがX氏の業務関連だった。』

『工数の膨れ上がりを看過できない状況にまで追い込まれた日本IBMは、業務の見直しやシステム化対象の絞り込みなどによる工数削減を野村側に提案。しかし、わずか14口座を対象とした処理の手作業化(システム化から除外)による工数削減でさえもX氏の猛反対を受け、実現できなかった。』

『X氏の横暴な振る舞いは判決文の随所で見られた。

例えば野村証券と日本IBMが11年7月上旬に開いた打ち合わせの場での出来事だ。工数のさらなる増加を懸念した野村証券の「IT戦略部(同社情報システム部門に相当)」部長から「今後大きな工数追加が判明する可能性はないと認識してよいか」と念を押す発言があった。同席していたX氏はここで沈黙を貫いた。

だが、X氏は後日開かれた日本IBMとの別の打ち合わせの場(野村証券側はX氏のみ)で新たな業務要件を追加。そのうえで「今後もIBMに伝えきれていない要件が見つかる可能性がある」などとした。X氏はその後も変更要求を多発し、日本IBMに対して「他罰的かつ攻撃的な苦情を述べることを繰り返した」と判決文に記されている。

X氏は社内で強い発言力を持ち、情報システム部門も意見を言いづらい雰囲気があったようだ。例えば日本IBMの担当者がカスタマイズ量を削減するため、発生頻度の低い業務要件の入力を手作業にしてはどうかと提案したときのことである。

X氏は手作業化によるリスクやオペレーション時間の短縮を理由にこの提案を拒否。「同席したIT戦略部長及び投信顧問部長はX氏の反対を黙認した」(判決文)』

『システム開発を巡る訴訟に詳しいアドバンスト・ビジネス創造協会(ABC協会)の細川泰秀副会長は、「強い発言力を持つユーザー部門の担当者がプロジェクトをかき回すケースは非常に多い」と話す。ITベンダーは「追加要件が出たら費用が発生する旨を伝え、身をていしてブロックする努力が求められる」(同)

野村側の断続的な変更要求に対し、日本IBMの担当者がどこまで止める努力をしていたのか詳細は明らかになっていない。ただ判決文によれば、日本IBMがプロジェクト途中で野村証券に仕様凍結を求め、それでも変更要求を続けた野村側の対応を東京高裁は問題視したようだ。

裁判では複数の証人が出廷したが、当のX氏は出廷せず、同氏の肉声が法廷で聞かれることはなかった。日経クロステックの取材によると、X氏はすでに野村証券に在籍していないことが分かっている。退職理由について野村HD広報に問い合わせたところ、「個人情報に関わることであり、回答はできない」とした。』

『野村HDは現在、最高裁に上告を申請中だ。期限までに上告の「理由書」を提出し、それを基に最高裁が上告を受理するか判断する。ただ一般にこの結論が出るまで数年かかり、「システム裁判で最高裁が上告を受理するケースはほぼない」(識者)とされる。』

『システム裁判はこれまで、ITベンダー側に厳しい判断が下されることが多いとされてきた。だが、ABC協会の細川副会長によると「ここ数年は裁判所がプロジェクトの実態を精査したうえで、ユーザー企業側の責任を厳しく問う判決を下すケースが増えている」と話す。

実際、病院情報管理システムの開発が失敗した責任を巡り旭川医科大学とNTT東日本が争った裁判では、17年の控訴審判決でユーザー企業側の旭川医科大学に責任があるとの判決が下った。いったん仕様を凍結した後も追加開発を要求したユーザー企業側の姿勢が問われた。

「システム開発にはユーザー企業側の協力が不可欠という理解が広がり、風向きが少しずつ変わってきている」(細川副会長)』

『ユーザー企業内における意思統一と協力関係も極めて重要である。今回、ユーザー部門による変更要求の多発を情報システム部門が抑えきれなかった構図は明らかであり、情報システム部門の責任は重い。

ただ、かつて多く見られた「ユーザー部門の立場が強く、情報システム部門が弱い」という関係性が上記のような事態を招いたのであれば、その責任は経営層にあると言わざるを得ない。

経営層が現場任せにすることなくリーダーシップを発揮し、社内の意思統一を図っていればこのような事態には至らなかった。ユーザー部門と情報システム部門のぎくしゃくした関係も生まれなかったはずだ。野村-IBM裁判は改めて教訓を示した。

(日経クロステック/日経コンピュータ 鈴木慶太)

[日経クロステック2021年6月10日付の記事を再構成]』