流通XML-EDIのJava化計画？ですが、うーん、危険なものにクビを突っ込んでしたっまらしい。
流通ＸＭＬ－ＥＤＩで、実際に、交換するメッセージが、概説書の後ろのほうに載っている。そこで、それを、ＸＭＬに書き直しているとき、手が止まった。
こんな項目があるのです。
伝票区分 伝票の種類をあらわすコード（発注伝票／返品伝票などの区分を示す）
納品区分 店直、センター納品の区分
ちょっとまって？？
概説書のどこにも、返品なんて言葉は出てこない。センターなんていう言葉も出てこない。
つーことは、概説書に載っているモデルと、実際交換しているフォーマットがずれている？？
危険な香りがします。
こういう、データ構造から想定されるモデルと、実際の要求仕様で書かれた業務モデルが異なることは、結構あります。たとえば、こういうときです。
・要求仕様のときには、そんな業務を作らなくていいことになっていたが、急に、やっぱ作んないとダメ！ということになり、現場で対応した。
・要求仕様書では、カットされているが、現場の人間が、「それですむわけ無いだろう」と、こっそり入れている（想定の範囲内とか、折込済みとかＳＥさんが、よく言う言葉）。
この２つのケースが多いと思う（とくに前者）。
で、とくに前者の場合だと、現場で部分的に対応するから、インターフェースが狂ったり、バグが出たりとなる。でも、流通ＸＭＬ－ＥＤＩの場合、国のお金で作ったから、急に仕様変更っていうのは、考えにくい。
つーと、後者のケースかな？と想像されます。つまり、統一伝票にあわせないとまずいだろうっていうふうに考えた。
まあ、いずれにしろ、要求仕様と、現場のプログラムがずれている可能性があるわけで、この場合、経験上言えることは、「このプログラムを元に作ろうとすると、デスマーチがおこる。捨てたほうがいい。」
要求仕様とプログラムが正確に、またはほぼ合っている場合、論理的な矛盾はすくないので、これは、再利用してもＯＫです。
でも、要求仕様とプログラムがあっていない場合、結果として、全体から見ると矛盾している可能性があります。もし、矛盾しているところがあると、矛盾＝嘘ですから、嘘を正しく見せるために、嘘を嘘で上塗りしていくしか、なくなります。
結果として、嘘だらけになります。嘘を重ねて正直者になるのは、大変です。
そのために無駄な努力が費やされるわけです（開発はデスマーチとなるわけですな）
そういう場合、すなおに、さくっとプログラムを捨てるのが一番です。
うーん、ウィリアムのいたずらも、ここで撤退したほうがよさそうです。
ということで、このシリーズを期待していた人、ごめんなさい。
でも、ウィリアムのいたずら、身の安全が一番です。
ということで、この企画、ここで
撤収！！
流通ＸＭＬ－ＥＤＩで、実際に、交換するメッセージが、概説書の後ろのほうに載っている。そこで、それを、ＸＭＬに書き直しているとき、手が止まった。
こんな項目があるのです。
伝票区分 伝票の種類をあらわすコード（発注伝票／返品伝票などの区分を示す）
納品区分 店直、センター納品の区分
ちょっとまって？？
概説書のどこにも、返品なんて言葉は出てこない。センターなんていう言葉も出てこない。
つーことは、概説書に載っているモデルと、実際交換しているフォーマットがずれている？？
危険な香りがします。
こういう、データ構造から想定されるモデルと、実際の要求仕様で書かれた業務モデルが異なることは、結構あります。たとえば、こういうときです。
・要求仕様のときには、そんな業務を作らなくていいことになっていたが、急に、やっぱ作んないとダメ！ということになり、現場で対応した。
・要求仕様書では、カットされているが、現場の人間が、「それですむわけ無いだろう」と、こっそり入れている（想定の範囲内とか、折込済みとかＳＥさんが、よく言う言葉）。
この２つのケースが多いと思う（とくに前者）。
で、とくに前者の場合だと、現場で部分的に対応するから、インターフェースが狂ったり、バグが出たりとなる。でも、流通ＸＭＬ－ＥＤＩの場合、国のお金で作ったから、急に仕様変更っていうのは、考えにくい。
つーと、後者のケースかな？と想像されます。つまり、統一伝票にあわせないとまずいだろうっていうふうに考えた。
まあ、いずれにしろ、要求仕様と、現場のプログラムがずれている可能性があるわけで、この場合、経験上言えることは、「このプログラムを元に作ろうとすると、デスマーチがおこる。捨てたほうがいい。」
要求仕様とプログラムが正確に、またはほぼ合っている場合、論理的な矛盾はすくないので、これは、再利用してもＯＫです。
でも、要求仕様とプログラムがあっていない場合、結果として、全体から見ると矛盾している可能性があります。もし、矛盾しているところがあると、矛盾＝嘘ですから、嘘を正しく見せるために、嘘を嘘で上塗りしていくしか、なくなります。
結果として、嘘だらけになります。嘘を重ねて正直者になるのは、大変です。
そのために無駄な努力が費やされるわけです（開発はデスマーチとなるわけですな）
そういう場合、すなおに、さくっとプログラムを捨てるのが一番です。
うーん、ウィリアムのいたずらも、ここで撤退したほうがよさそうです。
ということで、このシリーズを期待していた人、ごめんなさい。
でも、ウィリアムのいたずら、身の安全が一番です。
ということで、この企画、ここで
昨日のブログで、、「乙部さんはいいんだよ、システム開発の場合、なんのドキュメントが必要なのさ！」という話について。
システム開発のときにどのドキュメントを残すかということで、意外と大事なのに、渡されないドキュメントとして、「そのシステムで採用しているフレームワークがらみのドキュメント」があります。
もちろん、Strutsとかの、標準的なものだけを採用している場合は、いいんです。なくっても。
でも、Strutsだとしても、ＤＢとの接続のとき、O/Rマッピング「もどき」のことをやっている場合って、多いと思うんです。Hibernateとかを使わないで（なぜ使わないのかについては、後日書きます。予定未定だけど。現在、理論武装中）。
ちなみに、「もどき」というのは、セッション部分と、実際にSQLを発行する部分を分けています。それをフレームワークで規定しているものをさします。
そうやって、独自のフレームワークを使っている場合で、そのプロジェクトに途中から入った場合、プログラムを書こうとしても、どうやって書くのが正しいか、はっきりしません。
とくにフレームワーク部分をライブラリ（あるいはjar)のバイナリの形で渡された場合、確認のしようがありません。
サンプルプログラムを渡されても、そのサンプルと違ったこと、新しいことをやろうとしたとき、フレームワーク内でどう規定されているかわかんない。
結局、「えいや！」と書いてしまい。。フレームワークに外れたりして、バグをつくりやすくしてしまったりするわけです。
さらに、解析のときも、そういうドキュメントがあれば、プログラムの流れが分かりやすく解析しやすい。
で、フレームワークのドキュメントなんですが、フレームワークは、プログラムの書き方だけでなく、画面構造、あるいは、設計の仕方まで規定してしまうこともある（Strutsとかね）
ところが、今、ドキュメントの開発標準というと、たとえば、日経システム構築の３月号「のとはら先生のプロジェクト・マネジメント指南」P１２３に書いてあるのをみると、
■■プロジェクト標準
・共通
・プロジェクト・マネジメント規約
・システム開発環境規約
・システム開発規約
・システム運用規約
となってます。
さらに、フレームワークに関係しそうな、システム開発規約に書いてあるのは、以下のとおり。
■■システム開発規約
システム開発方法論
要求定義・設計ガイドライン
ユーザーレビューガイドライン
ユーザーインターフェース設計ガイドライン
・画面設計
・帳票設計
コーディング規約
テストガイドライン
セキュリティ設計ガイドライン
ふつう、こんなもんだとおもいます。
この中で、フレームワークについてかけそうなところは、「システム開発方法論」だけど、方法論のところに、まさか、クラスの継承の仕方やメソッドの内容までも書けず。。。
ということで、フレームワークの内容が、分散してしまうんです。
で、分散していればまだいいんだけど、コーディング規約をプロジェクトマネージャーが、なにもかんがえず、他のところからもってきてしまうと、このシステムのフレームワークについて、どうコーディングしていいかについて、書かれることが無く。。。
なんてことになりかねない。
もちろん、現場の人は、この問題を知っているので、フレームワークについてのまとめたドキュメントを持っているんだけど、いかんせん、プロジェクトマネージャーとかが、それがどれだけ大切かを知らないので（たんなる現場の資料だと思っている）渡してくれないことがあるのね。
そーすると、たいへん、こまったりするわけです。
システム開発のときにどのドキュメントを残すかということで、意外と大事なのに、渡されないドキュメントとして、「そのシステムで採用しているフレームワークがらみのドキュメント」があります。
もちろん、Strutsとかの、標準的なものだけを採用している場合は、いいんです。なくっても。
でも、Strutsだとしても、ＤＢとの接続のとき、O/Rマッピング「もどき」のことをやっている場合って、多いと思うんです。Hibernateとかを使わないで（なぜ使わないのかについては、後日書きます。予定未定だけど。現在、理論武装中）。
ちなみに、「もどき」というのは、セッション部分と、実際にSQLを発行する部分を分けています。それをフレームワークで規定しているものをさします。
そうやって、独自のフレームワークを使っている場合で、そのプロジェクトに途中から入った場合、プログラムを書こうとしても、どうやって書くのが正しいか、はっきりしません。
とくにフレームワーク部分をライブラリ（あるいはjar)のバイナリの形で渡された場合、確認のしようがありません。
サンプルプログラムを渡されても、そのサンプルと違ったこと、新しいことをやろうとしたとき、フレームワーク内でどう規定されているかわかんない。
結局、「えいや！」と書いてしまい。。フレームワークに外れたりして、バグをつくりやすくしてしまったりするわけです。
さらに、解析のときも、そういうドキュメントがあれば、プログラムの流れが分かりやすく解析しやすい。
で、フレームワークのドキュメントなんですが、フレームワークは、プログラムの書き方だけでなく、画面構造、あるいは、設計の仕方まで規定してしまうこともある（Strutsとかね）
ところが、今、ドキュメントの開発標準というと、たとえば、日経システム構築の３月号「のとはら先生のプロジェクト・マネジメント指南」P１２３に書いてあるのをみると、
■■プロジェクト標準
・共通
・プロジェクト・マネジメント規約
・システム開発環境規約
・システム開発規約
・システム運用規約
となってます。
さらに、フレームワークに関係しそうな、システム開発規約に書いてあるのは、以下のとおり。
■■システム開発規約
システム開発方法論
要求定義・設計ガイドライン
ユーザーレビューガイドライン
ユーザーインターフェース設計ガイドライン
・画面設計
・帳票設計
コーディング規約
テストガイドライン
セキュリティ設計ガイドライン
ふつう、こんなもんだとおもいます。
この中で、フレームワークについてかけそうなところは、「システム開発方法論」だけど、方法論のところに、まさか、クラスの継承の仕方やメソッドの内容までも書けず。。。
ということで、フレームワークの内容が、分散してしまうんです。
で、分散していればまだいいんだけど、コーディング規約をプロジェクトマネージャーが、なにもかんがえず、他のところからもってきてしまうと、このシステムのフレームワークについて、どうコーディングしていいかについて、書かれることが無く。。。
なんてことになりかねない。
もちろん、現場の人は、この問題を知っているので、フレームワークについてのまとめたドキュメントを持っているんだけど、いかんせん、プロジェクトマネージャーとかが、それがどれだけ大切かを知らないので（たんなる現場の資料だと思っている）渡してくれないことがあるのね。
そーすると、たいへん、こまったりするわけです。
アクセス
トータル
ランキング
