システム開発がらみのネタです。
■原因が分かったからといって対策がとれるとは限らない
すでに過去の風聞になっているかもしれないが昨年の暮れに珍しい事故があった。
全銀システムの大規模障害である。今まで事故を起こしたことがなく、あらためて不滅のシステムなど無いのだと実感した。おそらくは何か変更を加える際の見落としだと思うのだが、記事を見る限りおおよそそんなところだろう。
○全銀システムの大規模障害、「真の原因」明らかに–全銀ネットとNTTデータが発表
2023年12月01日
中継コンピューターは東京と大阪に1台ずつ、冗長化として設置されていたが、2台同時に新機種のRC23シリーズに切り替えたため、2台ともにソフトウェア障害が発生。冗長化としての役割を果たせなかった。
なお、破損していたインデックステーブルは、中継コンピュータ起動時にテーブルの初期設定値を保持するロードファイルから展開されることになっていた。発表によると、このロードファイルを生成するプログラムのテーブル作成処理に不具合があったという。具体的には、展開時にメモリ上に一時的に確保する作業領域が不足していた。
なぜ作業領域の不足が発生したのか。発表によると、RC23シリーズの開発ではOSバージョンアップに伴い、ロードファイル生成時に使用する4つのテーブルのうち、1つのテーブルのサイズを拡張していた。
なお、ロードファイルの生成プログラムは、一時的に確保した領域に、まとめて4つのテーブルを展開する仕様となっていた。しかし、NTTデータの開発プロセスにおける製造工程では、各テーブルが個別に展開されるものと誤って理解されており、一時的に確保する作業領域の拡張を行っていなかった。
また、NTTデータ内の製造有識者による修正内容の再検証においても、拡張の必要性を指摘できなかった。結果、大規模障害の発生に至った。
https://japan.cnet.com/article/35212251/
○全銀ネット、NTTデータが会見「システム障害の原因は開発プロセスと検証不足、再発防止に努める」
2023/12/02
今回のシステム障害の原因は、内国為替制度運営費情報を取得する際に使用する共有メモリ上のインデックステーブルの一部が破損したことが原因。RC23シリーズのプログラムが正常に動作せず、システムダウンに繋がった。このインデックステーブルはRCの起動時に展開されるロードファイルから生成されるが、ロードファイルを作成するプログラムの不具合（一時的に確保する作業領域の不足）により破損した。不足はOSのバージョンアップに伴うテーブルサイズの拡張にもかかわらず、展開時の領域拡張が行われなかったため発生した。NTTデータの開発プロセスにおける誤解と、再検証の不足が原因で、必要な拡張が見落とされた結果だという。
https://enterprisezine.jp/news/detail/18866
興味のあるヒトは自分で詳細の資料を探して欲しい。あくまでも上記を見て思ったコトを記載する。
■原因ではなく起こったこと
こうした記事の中で「真の原因」として「NTTデータの開発プロセスにおける誤解と、再検証の不足が原因で、必要な拡張が見落とされた結果」を挙げているが、これは起きたことであり原因ではない。
では何が原因かと云えば、開発プロセスの中に
①顧客要求事項のレビュー
②設計開発上の妥当性確認
が含まれていないか有効に機能しない何かがあることだろう。
さらにいえば、こうしたプロセスが欠落する要因はシステム開発の多重請負構造があるのではと思っている。それは、こうした検証作業はいつ誰が行なうのかという問題が曖昧になる恐れがあるからだ。
■誰が責任者として行動すべきか
上記の①、②は発注する側の責任だと思うが、そうとまでは云えないという記事を見た。
少し長いが引用する。
○仕様書通りにシステムを作りました。使えなくても知りません
ユーザー企業が作った仕様書に抜け漏れがあり、その通りに作ったシステムが使いものにならなかった。悪いのは、ベンダー、ユーザー企業、どちらなのか？
2024年02月28日
ユーザー企業が要件を検討し、ベンダーに提示したが誤っていた代表的なものは、以下の2点である。
1.コード表の不備
利用者が作業コードをいったん入力すると、カーソルが後ろへ戻らず、データを修正しようとしても打ち込めない。作業コードが平成7年4月14日当時で905件に達し、統一性がなく設定され、コード検索画面も一度に6件しか表示しないので、目的のコードを見つけるまでに50回程度画面を切り替えなければならなく、実用的ではない。2.口座振替一覧表の不備
本件ソフトウェアは、顧客に対する請求を銀行に依頼する口座振替の台帳となる「口座振替一覧表」に振替金額、振替日などの情報が含まれておらず、取引銀行に口座振替を依頼できない。ユーザーが示した要件に抜け漏れや誤りがあり、これに沿って構築したシステムはユーザーが本来望んだ動作をしなかったというものだ。
ユーザーはこれを債務不履行であると訴えるが、ベンダーは「言われた通りに作っただけで、こちらには責任はない」と反論した。
この手の紛争について、裁判所の立場はおおむね一貫しているように思われ、似たような判断が各地で示されている。
広島地方裁判所 平成11年10月27日判決より
ある廃棄物関係の業者（以下、ユーザー企業）が業務拡大に伴い、基幹業務システムの刷新を企図して、ベンダーに発注した。ベンダーはユーザー企業が作成した仕様書（要件定義書）に従って開発したが、仕様書には、幾つかの業務的、論理的な誤りがあり出来上がったシステムは使用に耐えないものとなった。ユーザー企業は、これについてベンダーが契約の目的に資して開発しなかったとして、債務不履行を訴えたが、ベンダーはシステムの不具合はユーザー企業の示した仕様の誤りによると反論した。
ベンダーは提案書において、本件システムの目的として販売管理、経営管理の迅速化、合理化を図ることを提示していたのであるから、コンピュータソフトウェアの製作に関し、自らが有する高度の専門的知識経験に基づき、目的の実現に努めるべき責務を負うと解するのが相当である。
しかるところ、ベンダーは、ユーザー企業作成の「コンピュータ仕様書」の他に、旧システムの仕様書などおよび契約書や伝票などの参考資料を受領していたのであるから、ユーザー企業の調査結果や各資料に基づいてユーザー企業の業務の内容を分析した上、専門技術的な視点で判断して必要と思われる事項を提案、指摘するなどして原告をサポートする義務があったというべきである。
https://atmarkit.itmedia.co.jp/ait/articles/2402/28/news015.html
確かに上記の記事は納得できる部分もあるが納得できない部分もある。
①こうした検証作業は契約内容に含まれていたのか
②含まれていたとしたらその検収はどのように行なわれるのか
と言うことが分からないからだ。
「当然のこと」として扱われるのであれば，ベンダー側も困るだろう。
■ソフトウエア開発の多重請負
私自身はかつて4次請負だか5次請負だか分からないが開発をしたことがある。既存システムの改修であり、渡されたのは進級の仕様書とコードであった。開発の一部分だけの資料である。
開発の過程で、旧のコードが旧の仕様書と合わないので発注者に指摘したが、「それで動いているのでそのまま進めてくれ。旧の仕様書が改訂されていないかもしれない」と無視された。
妥当性確認も検証作業も下請けがすべき仕事ではないと実感した瞬間である。
多重請負は責任所在をあやふやにしてゆく。
「言われたとおりにしろ」というのが上意下達であり、それがコミュニケーションを一方的にさせる。組織内部でも同じである。技術が分からない部長クラスが打ち合せに出て、資料を部下に丸投げし、部下も外注に丸投げする。
そんな構造であれば、事故の再発防止は難しいかもしれない。
なぜなら、みんなで無責任であれば今と同じことが起きるのは明らかである。
唯一できることは、責任の内容を明示した仕様書を作ることだ。あっ、それができれば苦労しないか。（合掌）
（2024/03/06）