システムが悪いと言えば悪いし、うまく作っていると言えばうまい。コンピュータネタ、目次へ
断罪はできない。ただし困っている人は多いかもしれない。そんなシステムを紹介することにした。結構トレンディなアプリケーションだ。原因が私が考えたとおりだとすると、今後同種の問題で悩む人が増えることになろう。喪中はがきを出さなければならなくなった。残念ながら当方の年賀状作成ソフトにその機能はない。プリンタも調子が悪い。だからどっかに頼むことにした。近所の印刷屋では宛名までやってくれそうもなかったので、Webを検索。最寄りのコンビニがネットで受け付けてくれることを発見した。
まあ、嫌な予感はしたんだよな。宛名を受け付ける際、画面入力かCSVファイルによる転送かを選べるようになっていた。CSVファイルって、項目名とフォーマットは何よ、と見ると、MS-ExcelからCSVファイルを出力する手順が大げさにも解説されている。オイオイ、宛名は「氏」と「名」に分けるのか？「氏名」で一つなのか？補足住所はどこで分けるの？郵便番号は7桁全て数字？途中にハイフンを入れるの？この辺のフォーマットを指定せずにCSVという形式だけ指定してもうまくいくわけ無いじゃん。
もっとも、MS-ExcelからのCSVファイル出力方法を教えなきゃならない人間に、項目形式はこうしてくださいと言っても、その通りにしてくれるわけがない。だからMS-ExcelからのCSVファイル出力手順なんかは記載しない方が賢明だ。分からない人はあきらめてもらった方が安定運用には有益である。どうしてもというなら、例えばOutlookの住所録からCSVに出力するやり方を記載すべきだろう。であればフォーマットもある程度固まっていると期待できる。
かくして、CSVで送信したいのはやまやまであったが、その辺のことが推測できない人間が作ったシステムを信頼できるわけがない。だから当方はWebブラウザから一件一件手入力した。で、全部入力して（はー疲れた）内容確認して、注文する。ところが届いた現物を見ると「宛名が印刷されていない」。なぜだー、あんだけ苦労して打ち込んだ私の立場は（実はMyHope使って打ち込んだのでそんなに大変でもなかったが）どうなるのだ。で、注文確認メールを読み直してみると、確かに宛名印刷件数０件と記載されている。それにしては高いぞ＞某コンビニ（以下Ｆマートと表記、紛らわしい名前ですがＫマートではありません。）、と思いつつも悪いのは確認しなかった私。どこか間違っていたのかなあと反省点を探す。うーん。オペミスしたか？いや多分していないだろう。「０件」となっているからね。空欄じゃないから。（他の指定していない項目は空欄だった。）だいたい画面で確認した際は、きちんと入っていた。
つまり、宛名印刷を受け付けたが、具体的な宛名がWebで転送する間に削除されたと推測される。そんなこと起こりうるか？ピンと来た。スパイウェア駆除ツールである。
Ｆマートが宛名情報吸い上げのために使っているモジュールはシステム構築会社が外部から買ってきたもので、これが実は広義のスパイウェアと見なされていたものだったのではなかろうか。であればスパイウェア駆除ツールがこいつを削除ないしブロックしてしまい、データを飛ばされなかったということが考えられる。従って、Ｆマートの受付サーバーに、注文枚数や宛名印刷を依頼したという情報は飛んでいったが、宛名情報は飛んでいかなかったということだろうか。
だとするとこの現象は説明できる。サーバーと回線負荷を考えると、入力情報の確認をサーバーに送信する前にクライアント側で行うという仕様は悪くない。特に入力するのが個人情報である今回のような場合、極力サーバーに流さないというのはいい設計かもしれない。ただし、これはクライアントの情報とサーバーの情報が一致することが保証されている場合である。インターネットという回線でこれを期待するのは無理だろう。そして「スパイウェア駆除ツール」や「パーソナルファイアーウォール」によって情報の疎通が阻害されることが起こりうるとすれば、これは受付サーバー側でもう一度入力情報の正当性を確認して、クライアントに投げ返すべきであろう。
まあごにょごにょ言っているヒマはない。受け取った店であわてて筆ペンを買って今度は宛名書きを夜遅くまでして、なんとかやり終えた。さて改めて考えよう。Ｆマートは何を考えて（考えなくて）こんな仕様にしたのだろう。
おそらく、ＦマートはWebブラウザで入力したクライアント情報の一部が、サーバーに飛ばない事象があることを予測していたハズである。でなければ、ユーザーへの確認条項を、はがきの印刷のみの基本料金と宛名印刷のみの追加料金に分離させて表示するはずがない。（たしか合計代金欄すらなかった。そこまで分離させている。）また、はがき印刷枚数＞宛名印刷枚数の場合の「件数と明細がずれてますけど大丈夫ですか？」の確認画面も出なかった。この辺の仕様からそもそも入力チェックをしっかりと確認できない事情を認識していたのではないかと推測できる。
で、クライアントでのWeb入力データを確認する部分をさらっと作り込み、サーバーで受け付けたデータから作る確認メールの文面と美妙（ナイスな誤変換）にずらせておけば、例え顧客の意図とは違った注文を受け付けていたとしても、確認すべき項目を提供した以上、システム側は免責される。システムサイドとしては悪くない考えだ。と、ここまでは普通の感想。ここからはシステム構築組織の文化の問題。
ただし、サービスの点から言うと、クライアント側で宛名入力の件数をカウントして、それだけは別にサーバーに送り、入力データの件数とチェックしても良かったのではないかと思う。少なくとも私ならそういう設計をする。
はがき発送サブシステムとしては、入力件数を印刷総枚数でカウントすべきだし、同様に宛名印刷サブシステムは宛名印刷件数でカウントするのが適当だろう。しかしＦマートは、はがきの注文と宛名印刷の注文を別に受け付けているようで、前述のように連携が極めて薄い。
顔の見えないお客様だからこそ、間違いがないようにしっかりと確認できるシステムを作るべきだろうに。一般論として、システムを発注するユーザーが「入力ミスがあれば分かるようにしてくれ」という要望を出すことは普通ない。しかしシステム構築屋としては、そういうニーズがあるものとしてシステム設計をすべきだと思っている。だって間違ったデータが入力されて、それがそのまま処理されてしまうと、システムの出力するデータ全体が信頼できなくなってしまうから。
え、入力ミスが分かるようにするなんてシステムでできるかって？完璧じゃないけどいくつか方法はあるよ。（システム構築会社は中堅どころを集めてテストしてごらん。多分おもしろいよ。）私がざっと考えついたのは、Ｆマートがやったのは最後のだけだった。だから、これを作ったシステム構築会社を私が二流以下と見なしても侮辱とは言えまい。
- 入力データのフォーマットチェックをする。（日付データなら実在する日付か、処理可能な日付か。金額なら数字だけか、など。最大値／最小値チェックなども有効。）
- 予め合計額、全体件数を入力させ、個別入力の合計が合わなければエラーメッセージを出す。）
- 会計処理の場合は、入払の金額が同額になるまでオペレーションが終われないようにする。
- テーブルにある値以外入力できなくする。（航空券予約の場合の発着地とか）
- 同じ項目を２人以上が入力するようにし、一致しなければエラーを出す。
- 確認計表を出力し、入力者に確認させる。
システム構築に慣れてくると、このような設計を殆ど無意識にやってしまう。まあ、こういった構築時の暗黙のルールとしてどのようなものを持ち、どのように実現するかがシステム構築組織の文化だと〜私は〜思っている。で、今それをいくらかでも成文化しようとしているところ。
と、いうのはね。これがメンテナンスの時の足かせになるかもしれないから。システムを構築した組織とメンテナンスした組織が一緒の場合は特に問題にはならないにしても、変にアウトソーシングしたりして別組織になったとき、その文化が引き継がれていないと、当然と思うところでエラーになるから。
例えば、日付データを１の範囲チェックで確認している組織と５の二重入力で確認している組織のシステムが混在してみなさい。５の組織の場合、例えば「例外的データは、西暦1111年の日付でシステムに打ち込もう」などという内部ルールを（勝手に）作れば、それで日付チェックはすり抜ける。これを１の組織のシステムが受けると範囲チェックで落ちる。どっちが悪い？という問題もあるが、それ以前に「こんなしょーもないことでシステムトラブルが起こったら嫌でしょう」と普通は感じないかなあ。
で、悪いことに、この「入力ミスが分かるように」という要望はユーザーが明示的に出したものではないので、どこかで忘れ去られてしまうものなのよ。ついでに言うと、今の中堅SEのあたりでこの文化が崩れている可能性が高いのだ。だって入社したときは2000年問題の手伝いでしょ。それが終わると、あちこちの企業や自治体で合併が続出、当然システム統合が受注案件の中心となる。だから直接ユーザーの話を聞いてシステム設計をするという経験にどうしても乏しくなる。
まあ新システム構築案件目白押しで、経験する機会のあったWeb系の会社もあるようだけど、これは信頼できない回線とＯＳを前提として作られたシステム。当然トラブルに対するモラルハザートが起きるだろう。だからそんなにしっかりしたシステムができなくても仕方がない。で、結局経験不足のSEが育ってしまうんじゃないかねえ。丁度Ｆマートのシステムを構築した会社のように。
まあ仕方がないことかもしれない。だたし私は今後コンビニ決済でＦマートを使うことは一切無かろう。