金融の基幹システムを1年半かけて.NET 6に移行した話
うーん。起きたことはTrimの仕様違いによるという話だが、そもそもデータフォーマットの仕様はあるはずで、そこに合致しないデータが通過しているというのは致命的では。テストとしても妥当性検査できていない話かと
うーん。
書いている本人は些末な問題として取り扱っているのだけど、同じ金融系のエンジニアの立場から見ると、これ結構大問題だと思うのだけど。
そもそも、個別システム間でデータ仕様や入出力に関する仕様があるわけで、その間をやり取りするデータはCSVで交換されているのであれば、余計に厳格なチェックが必要になる。
というのも、如何せんCSVは他のデータフォーマットと比較しても明らかに地雷が埋め込みやすく、一般的にエンジニアであれば、見た目以上に危険な代物として理解しているわけで、例えば、CSVは行単位の仕様が当然であるという思い込みであったり、言語に搭載されているパーサーを使えば確実に処理できると思い込んでいたりと、地雷を上げればきりがない程度には危険な代物ではある。
内輪の仕組みで使うとしても、一定の厳格さで仕様は取り決めが必要で、見た目が単純であるが故に誤解が起きないように配慮が必要かと思われる。
で、その基本的な部分の妥当性が確認されていなかったというわけで、単純な話、テスト設計が失敗していたという事ではないかと。
僕から見ると、些細な問題というのは、もっと機能的な不具合、つまり上位のレイヤーでの不備や不具合が発見された場合であり、こういった下位のレイヤーでの不備は、一歩間違うと大トラブルにつながるわけであり、決して些細な問題でもないし、ましてや、根幹となるデータ交換部分での変換差異が生じていたという話なので、それほど容認できる話でもないのではと。
というのも、金融データでは結構固定長データも使われており、スペースのような文字は残すのか、削るのかというのは個々の定義により処理が異なる。
当然Trimなので別にスペースのような文字に限定されるものでもありませんが、他の文字・文字列でも同様で、その削除処理が正常に行われていないという事自体が結構致命的な話かと。
他の業界では別にスペースが紛れ込んでいても影響ないでしょ、精々見た目の問題では、と思いがちだが、金融では桁ずれが起きると仕向け先（お金の送り先）が異なる金融機関あてになったり、異なる口座になる可能性もあるわけで、そんな致命的なミスは当然できない。
最近でいえば、即時送金対応を行った金融エンジニアは多いと思うが、あの手のやり取りでも、固定長フォーマットである全銀フォーマット（但し、一部銀行はフロントで別フォーマット／可変長含め受付をしているのでその限りではない）を扱った事が比較的多かったのではないかと思うが、あのケースでも受け手である銀行側が厳格に検査しているので比較的事故は少ないのではないかと思うが、出し手側のデータをそのまま受け手が処理した場合、一歩間違うと事故となるような事が起きる事も想定される。
そうでなくても、想定された処理・送金が行われないという時点で、大事故ではあるが。
つまり、金融系システムにおいて、Trimが行われていないという問題の解釈としては、時と場合によるというのはそうであるとしても、少なくとも「些細な問題」として処理できると言い切れるものでもない。
そして、そのような問題が、そもそもテストケース内で処理されていないという事は、データ交換部分における機能仕様が理解されていないか、文中にもある「不具合も含めた仕様」が顕在化した事例であり、逆にそれが後工程まで処理できなかったという話で、テスト全体の信頼性は著しく低下している話ですから、結構マネジメントとしては頭が痛い（わかる人であれば状況から指摘できる程度には致命的なので、その前提でテスト全体の信頼性を説明しなければならにという地獄）話で、笑い話にもならないのではと。
まぁ、実際の事例の詳細までは記載がないので何ともいえないが、結構社名を出して言える程の笑い話でもないような気がするが…。
