流通XML-EDIのJava化計画：その４：モデルとXMLのずれ、危険な香りがする。撤収！

　流通XML-EDIのJava化計画？ですが、うーん、危険なものにクビを突っ込んでしたっまらしい。

　流通ＸＭＬ－ＥＤＩで、実際に、交換するメッセージが、概説書の後ろのほうに載っている。そこで、それを、ＸＭＬに書き直しているとき、手が止まった。

こんな項目があるのです。

伝票区分　伝票の種類をあらわすコード（発注伝票／返品伝票などの区分を示す）
納品区分　店直、センター納品の区分

　ちょっとまって？？
　概説書のどこにも、返品なんて言葉は出てこない。センターなんていう言葉も出てこない。
　つーことは、概説書に載っているモデルと、実際交換しているフォーマットがずれている？？

　危険な香りがします。

---

　こういう、データ構造から想定されるモデルと、実際の要求仕様で書かれた業務モデルが異なることは、結構あります。たとえば、こういうときです。

・要求仕様のときには、そんな業務を作らなくていいことになっていたが、急に、やっぱ作んないとダメ！ということになり、現場で対応した。

・要求仕様書では、カットされているが、現場の人間が、「それですむわけ無いだろう」と、こっそり入れている（想定の範囲内とか、折込済みとかＳＥさんが、よく言う言葉）。

この２つのケースが多いと思う（とくに前者）。
　で、とくに前者の場合だと、現場で部分的に対応するから、インターフェースが狂ったり、バグが出たりとなる。でも、流通ＸＭＬ－ＥＤＩの場合、国のお金で作ったから、急に仕様変更っていうのは、考えにくい。
　つーと、後者のケースかな？と想像されます。つまり、統一伝票にあわせないとまずいだろうっていうふうに考えた。

---

　まあ、いずれにしろ、要求仕様と、現場のプログラムがずれている可能性があるわけで、この場合、経験上言えることは、「このプログラムを元に作ろうとすると、デスマーチがおこる。捨てたほうがいい。」
　要求仕様とプログラムが正確に、またはほぼ合っている場合、論理的な矛盾はすくないので、これは、再利用してもＯＫです。

　でも、要求仕様とプログラムがあっていない場合、結果として、全体から見ると矛盾している可能性があります。もし、矛盾しているところがあると、矛盾＝嘘ですから、嘘を正しく見せるために、嘘を嘘で上塗りしていくしか、なくなります。
　結果として、嘘だらけになります。嘘を重ねて正直者になるのは、大変です。
　そのために無駄な努力が費やされるわけです（開発はデスマーチとなるわけですな）

---

　そういう場合、すなおに、さくっとプログラムを捨てるのが一番です。

　うーん、ウィリアムのいたずらも、ここで撤退したほうがよさそうです。
　ということで、このシリーズを期待していた人、ごめんなさい。
　でも、ウィリアムのいたずら、身の安全が一番です。

　ということで、この企画、ここで

　撤収！！