喜ばされてばっかりだね

オンビー？　オンビー！＜そんなの絶対はやらねえよ
さて、今夜はひさびさにテクニカルレポートをお届けします。（仕事のぐちとも言う）　システム開発の業務において、相手方からさまざまな種類のデータを受け取って、それを利用したり加工したりするプログラムを作るようなことがあります。データベースだったりテーブルファイルだったりしますが、そこに格納されているデータを表示したり、検索したり、あるいは更新したりってなことですね。そこで問題となってくるのが、その元データの正当性です。仕様とまったく異なる値や、予想だにしない値が入っていたりすると、開発時でも稼働時でもそれが大きな問題となります。
ファイル構造などもふくめてこちらから提案する場合は、当然そのことに細心の注意を払う必要があります。項目ごとのデータ型を定義するだけでなく、入力できる値に制約をもうけたり事前に検証して不正なデータの登録を防ぐとか、どのような値を受け取ってもエラーとならないよう処理を工夫するなどといったことが重要になってきます。いや、それだったらむしろそれでいいのですよ。もっと厄介なのは、あちらさんがすでに独自にデータを用意してくれやがっていて（皮肉特盛り）、これをそのまま使いなさいと手渡されたときです。もうね、目もあてられません。いうても素人さんが作るデータですので、フォーマットも何もあったものではありません。数値が範囲外とかはまだいいとしよう。数値を入れるべき項目の型指定がなぜか文字列になっていてあられもないデータが入っているだとか、主キーであるはずの項目に重複した値がわんさか入っているだとか、データベースで言うところの正規化がされていないのでどう更新したらいいものやらとか、…どうよ。＜どうよって　いっそこっそりデータを書き直そうかとも思うこともありますが、レコード数が数千、数万ともなるとさすがに手をつける気も起こりませんし、そうなると結局プログラム側での対応ということになって、よけいな作業が増えるわけです。スマートですっきりしたコードを書きたいという私たち開発者の野望ははかなくもあっけなく散りゆくわけです。（何）
ま、そんなわけで。データは一貫性というか、せめて整合性をもったものを用意してもらいたいものです。ただ、利用者から見て扱いやすいデータ構造と、開発する立場から見て処理しやすいデータ構造ってのがそもそもちがうってケースはあるかもしれませんが。