自分が体験したシステム障害を紹介してトラウマを抉り返す自虐コーナー
※特定避けるため一部脚色・変更しているが、大体ほぼ実体験。
障害No障害分類No
（自分用）発生分類
アプリ/データ/ミドル/ハード案件名個人的ヤバイ度
（５段階評価）
| 12 | A | アプリ | 対外システムから受信した インターフェースデータのカタカナが不正で 検索できない |
★★☆☆☆ |
| 発生日時 | 2017/02某日 | 解決日時 | 2017/03中 | 発見者 | お客さん | 対応者 | 俺 | 原因者 | 俺じゃない… はず… |
||||||||
| 障害の詳細内容 | 先に言っておくとこの件は正直個人的には「障害」とは思っていない。 何か勢いにまけて結局無償対応をしちまったのだが、 根本的な原因はこっち（の管理しているシステム）にはないと思っている。 そういう意味だと仕様変更でもいいはずなのだがなぜかそうはならなかった悲しい案件である。 俺の担当していたシステムをA、対外システムをBとする。 Aではエンドユーザーからの受注を受け付ける。 Aで受け付けた受注データはBにインターフェースファイルとして送信され、 Bで受信取込後、内容の訂正・補完等を行った後、受注の「本登録」を行い、 「本登録しましたよ」というデータをインターフェースファイルでBからAに送信する。 まぁよくある話である。 A→Bの受注受付データにも、 B→Aの受注登録データにも、 「商品の読み仮名」が項目として含まれている。 例えば 「情報処理試験対策過去問題集」であれば「ジョウホウショリシケンタイサクカコモンダイシュウ」 といった具合である。 B→Aの受注登録データには、A以外から受け付けた受付データも含まれるが、 いずれにしてもBで一度「受注登録」をすることでインターフェースの対象になる。 この際、商品マスタを再読み込みして、 各所から集めた受付データの商品名等を最新化する役目をBが担っていた。 →これには、「特別商品の受注拒否」みたいな目的があって、そのための処置だったようで、 「商品名の最新化」はそのオマケだということだったが つまり、 Aで受け付けたときに「あいうえお」だった商品は、 Bで受注の本登録する段階では「かきくけこ」に変わっている可能性もある。 基本的にはこの仕組みをA、B両者設計時に認識合わせしていたはずだった。 ところが、あるケースでこれに反するデータが発生した。 そのケースでは以下のようにインターフェースされた。 Noデータ（方向）商品名（漢字）商品名（読み仮名）
おわかりいただけただろうか？ つまり、 「商品名（漢字）」は最新化されてるのに 「商品名（読み仮名）」が最新化されていない（A→B当時のまま）なのである。 A側では、Bからインターフェースされたこの「読み仮名」のほうで検索できる仕組みを作っており、 「受注時点の読み仮名」で検索できるよう構築していた。 しかし、上の通り、 商品名（漢字）と商品名（読み仮名）が一致していないので、 商品名（漢字）に従ってカナ検索してもひっかからないし、 かといって 昔の（商品名変更前の）カナで検索すると、検索したのとは違う商品名（漢字）が出てくるし、 で、 なんだこれは？と問題になった。 この時点で俺は「どう考えてもBが悪い」としか思えなかったし 俺の考えが一般からずれてなければ大多数の人がそう思ってくれると信じてるのだが、 何故かお客さん・及びB側担当者の反応は鈍く、どうも何か口ごもっており、 挙句 「B→Aの読み仮名項目をそういう用途で使うって ちゃんとBに伝えてましたっけ？」 とか言い出しやがった。 つまり俺たち（A担当者）が 「検索に使うからちゃんと読み仮名も最新化してくれよな！」と ちゃんとBの担当者に伝えてないのが悪いのでは？ という流れになぜかなったのである。 お客さん側・B側担当者の言い分は
ということである。 確かに設計時の議論では 「読み仮名」を具体的に指定してBへの仕様指示（依頼？）はしていないが 「漢字名」に対して「読み仮名」を合わせてくれ、なんて、 そんなこと言わなきゃわからんことか？？ というのがまず疑問だったし、 2.の前半はまぁまだ理解できなくはないが、 "（から、A→Bのまま送り返した）"は思考として全く理解できない。 B→Aのインターフェースなのだから、A側がどういったかではなく Bが責任もって設計するのが筋なんじゃないのか？ そもそもBがどういう業務要件や要望に基づいて仕様化するのかは 俺ら（A側）の関知するところではないから そんな仕様指示をこっちからすること自体お門違いなわけである。 何度話してもB側が態度を変えないため、 止むを得ず（納得はいかないが）A側での対応策を講じることになったのである。 |
||||||||||||||||
| 対応内容・経緯等 | A側で検索させるとき、 「どの時点のデータをもとに検索しているか？」を、 改めてはっきりさせなければならない、という検討になった。 →そういう意味では確かにはっきり決めてなかったかもしれないし、 それに対してよくわからない対外システムに仕様を依存していたのは 確かに今にして思えば問題だったかもしれない 考えられるタイミングとしては以下の３点がある。
うち、2.は↑で書いた通り、最早使い物にならないので、選択肢からは消える。 3.も、選択肢としてはナシではないが、 取り込みがバッチ処理タイミング（しかも日中10分間隔で動いてる処理）である以上、 正確な日時を特定するのは難しいし、 A側で検索させるユーザーサービスとしても、 ユーザー側に「いつ時点」の説明がうまくできない。 以上から、消去法的に選択肢が1.だけとなり、1.での対応を行うことになった。 A→BのデータはA側に残っているので、 それがBから戻ってきたあと、BのデータをAの内容で上書きすればいいのである。 そこまで難しい話ではない。 強いて言うなら なんで俺ら（A側）がこんなことやらなきゃならねえんだ？ というストレスフルな思いがあったことくらいか。 今回のシステムにおいて、ユーザーへの「利用明細」をつくっているのは、B側である。 Bの役割は、システム全体からすると「販売管理システム」に近く、 いわゆる「請求書」の作成等も担っている。 当然だが、それらに印字される「商品名」は上記で言う2.－つまり「受注登録時」の内容だ。 （本来、受発注の管理システムにおいては、特別な事情がない限りそれが筋である…はず） この点において、Aにおける検索仕様とは乖離が出る。 今回の対応により、 「受注を受け付けた（依頼した）ときの情報でしか検索できませんよ」 という変な制限付きの（目的のよくわからない）画面機能になってしまったのである。 まあBはAとは物理的に違うシステムで、 受注登録をしている様子もAからはわからない。 このためAを主眼に（Aだけで）見れば、「受注登録時の情報」は意識する場面が存在せず、 Aシステム内で整合性を取るという意味であればこの対応でも良いのかもしれない。 なお、この件は、「Bで商品名を最新化していない」ことから発覚した問題だが、 これにより、Bが困らなかったのは、 「商品名（漢字）」は最新化していて、 「利用明細」「請求書」には「商品名（漢字）」しか印字していないから である。 というよりBとしては、恐らく、その後の業務処理に流す際に、 必要になる個所"しか"最新化の対象にしていなかったのだろう。 このため「商品名（読み仮名）」は最新化の対象から漏れていた、ということだと思われる。 （B担当者からはっきり聞いたわけではないが、話を聞く限りそうだと推測される） 要するにBはBのことしか考えておらず、Aのことなど微塵も気にしていない というのが明らかになったのである。 |
||||||||||||||||
| 反省点・あとがき | 正直Bとのやり取りでは設計時からこのテの議論がずっと続いており、 この件も若干「またか」って感じではあったが、 ※ちなみにこの日記でボヤいてる「話にならない」ってのはこのBのことである 単純に納得いかないのは、 その度毎回俺ら（A）が対応をする羽目になるという現状である。 僅かながら俺らに軍配があがり、Bが対応する案件もあるが、 全体規模からすると恐らく1/10程度だろう（ちゃんと数えたわけではないが…） そのときもお客さんの第一声はまず「Aでなんとかなりませんか？」だから救えない。 これにはお客さんの体制も関係している。 お客さんの、Bの担当部門とAの担当部門は、それぞれ違う部署で、かつ仲が悪い。 お客さんの会社が縦割りの印象が強い組織構成だったことも関係しているかもしれないが、 いかんせん折り合いが悪く、お互いまともに話そうとしない。 一方で、性格からなのか、 Aの担当部門の人は、なぜかBの担当部門の人に強く物言いできず、 今回の件のような、交渉事というか、「AのためにBに改修を依頼する事項」に関しては、 Bの担当部門の人がものすごい拒否反応を示し、大抵けんかになる。 すると、上記の通り、強く物言いできない関係から、大抵すぐにAの担当部門の人が折れて、 結果担当ベンダーである俺らに話が回ってくる。 そんな流れがしょっちゅうであった。 こうなると厄介なのが、Aの担当部門の人も、 Bの担当部門の人に「折れる」と、 まるで共謀したかのようにベンダーの俺らを攻め立ててくることだ。 「Aを開発した」という立場で言えば、 ベンダーの俺らも、Aの担当部門の人も同じはずなのに。 このときばかりは（悪い言い方をすると）「ベンダーのせい」という態度を取る。 この商売の悲しいところである。 |
||||||||||||||||
