大企業、中堅・中小企業、中小・零細企業のシステム開発と、その方法論の違いを独断と偏見で考える

　前のブログで、中堅・中小企業の場合のＥＲＰについて書きましたが、ＥＲＰに限らず、システム開発をする場合、会社規模（会社の人材）によって、適切な開発方法論が違う気がします。

　今日は、その会社規模と適切な開発方法論について、独断と偏見をくわえて考えたいと思います。

---

■■　大企業の場合

　大企業の場合は、自分の業務について、ちゃんと語れそうな人がいたり、マニュアルがまかりなりにもあったりします。
　それをもとに、ヒアリングがある程度可能なので、ヒアリングから、現行の業務プロセスをきいて、まとめることが、不可能ではないケースが多いです。

　このようなケースの場合、オブジェクト指向やプロセス指向でも、データ指向でも、どちらでも可能です。
　ただ、組織が大きくなってしまった場合、全データを扱うのはきついので、ある程度、隠しながらやりたい（他の事業部は、ブラックボックスにして考えたい等の）場合、オブジェクト指向を採用したほうが、分析しやすいです。

　したがって、ＵＭＬをつくって、という最近のアプローチで問題ないと思います。

　ただ、そのヒアリングが本当に矛盾がないか、たしかめるには、ＤＦＤを作成し、ＤＢに落とすためＥＲ図を描くのがいいかとは、思います。

---

■■　中堅・中小企業の場合

　中堅・中小企業の場合の場合、大企業のように、自分の業務について、ちゃんと語れそうな人がいたり、マニュアルがまかりなりにもあったりするケースもあります。
　しかし、その一方、自分の業務について、語れるはずの主任クラスの言っていることが、どーも変？？ということがあります。言ってることが二転三転したり、主任全部あつめて言ってることをあわせると、仕事に抜けが出てきたりなどです。その場でよくいえば、臨機応変、わるくいえば、いい加減に処理しているからです。

　こういう場合、業務をはじめに聞いてしまうと混乱するので、先に、使っている伝票・作業票などを全部あつめてきて、「この伝票は、どういう場面につかって、このあとどうなりますか？」とモノで抑えていくほうがいい場合があります。
（抽象的にいえず、伝票などで、追っていかないとわかんない人もいるし）

　ということで、はじめに帳票分析から入り。。。ということで、データ指向ではいることになります。

　これを、プロセスから入ってしまうと、言われることがまちまちなので、ＳＥの頭の中は混乱します。
　なお、プロジェクトマネージャーさんの中で、どーもＳＥが、混乱しているように見えた場合、出力など、モノを中心に考えてるかどうか、確認するといいです。いろんなことを聞いているうち、つじつまが合わなくなり、パニックってることがあります。
　こういうときは、モノでおさえていくと、何が正しいのかが見えてくることがあります。

---

■■　中小・零細企業の場合

　たいてい、行き当たりばったりで仕事してます（っていうと、怒られます。「状況に柔軟に対応して仕事を処理しています」といいましょう）。

　なので、仕事の手順自体、よくわかんない？？きまってない？？っていうことがあります。

　はっきりいって、こういう会社は、システム開発をする必要がないケースもおおいです（たとえば、町工場の経理・給与システム、手計算でいいじゃん、みたいな）。
　でも、無理やりでもシステム開発したい場合は、まず基準をつくって、それにあわせられるかどうかという形になります（フィットギャップ分析ですな）
　過去の資産を捨てるのか！と怒られそうですが、この手の会社、過去の資産がなかったり、資産というよりはゴミでしょう(^^;)っていう場合もありますので。。。

　で、なんにあわせるのか。。。

　経理ソフトなど入っていれば、その経理ソフトが出している、ＥＲＰにあわせることになりますが、入ってない場合は。。。値段的にいって、弥生なのかなあ。。
　でも、弥生のＥＲＰって、あんまし聞かないよなあ。。。
　ホリエモンは、このへん、どう考えてるんだろう（弥生は、ライブドアの子会社）

ビジネスモジュールとはなにか？と、業務開発の最近流行かもしれない「ビジネスプロセス制御」について

　前のブログにかいた、流通システム開発センターの、「流通システム化に関する研究開発」の「ビジネス・モジュールの基本設計」を、今日は、見てみましょう。

　まずは、発注業務、どんなものを入力して、どんなプロセスになっているんでしょう。
　と思い、みてみました。

　で、はじめに、見たものなのですが、
　　「外部設計書」に相当する、「ビジネスプロセス分析成果物.pdf」
　　　　（以下、外部設計書と記載）と、
　　　内部設計書に相当する、「モジュール設計成果物.pdf」
　　　　（以下内部設計書と記載）をまず見てみましょう。

　外部設計書のほうでは、なにをやるかの指示が書かれている。
　（たぶん、解析は、外部設計書の３．３アクティビティ図概要からみて、要求仕様のユースケースに戻るほうがわかりやすい）

　たとえば、外部設計書３－２ページより、受発注業務においては、４種類のパターンが考えられることがわかる
（１）受注回答あり
（２）受注回答なし
（３）発注なし
（４）受発注なし

　このうち、受注回答ありパターンにおいて、発注者は、以下の作業を行う
　（外部設計書３－４ページより）
　　　　（PR01B01-01）業務サービス要求受付
　　　　（PR01B02-01）発注情報送信
　　　　（PR01B03-01）受注回答情報受信
　　　　（PR01B04-01）業務サービス結果通知

　ここから、「(PR01B02-01）発注情報送信」において、発注データを送信していると予想されるので、内部設計書２－５ページの発注情報送信をみると。。。
　おや、J-XML(JEDICOS-XML = EDIのためのＸＭＬ）を生成して、すぐに送信してるんですけどお。。。J-XMLの発注情報は、どこに？？
　この図からだと、BPC（ビジネスプロセス制御）から来ているようにしか見えない。
　ＢＰＣは、２－４から、業務ＡＰから来ているように見える。

　じゃあ、その業務ＡＰに、発注データを入れる部分があるってこと？？
　でも、業務ＡＰって、どこに書いてあるの（この場合、発注入力になると思うけど）

　とおもって、探したら。。。

　外部設計書１－１に


　本システムは大きく「業務システム（Web 業務アプリケーション）」「ビジネスモジュール」「通信機能（ebXML通信サーバ）」の部分によって構成されている。本書では、この「ビジネスモジュール」の主要な部分である、「ビジネスプロセス制御」の外部仕様について記述する。


　あ、「発注業務、どんなものを入力して」っていうのは、業務システムの話。。。このドキュメントじゃないんですね（＾＾；）

　で、「ビジネスプロセス制御」って？

　ということで、流れ流れて、「流通SCM共通プラットフォーム　概説書」（scm02.pdf）25ページにかいてある。


ビジネスプロセス制御機能：前述のパターンの組み合わせによるビジネスプロセスを定
義可能で、そのプロセスに従ってデータのやり取りを実行します。


　うーん、これっすかあ！
　この考えで、ウィリアムのいたずらも設計したことあるんだけど、そしたら、ＳＥさんに、「なに言ってるか、わかんない」と、１ヶ月も考え込まれてしまったことがあるぞ！
（そのあと、なぜか、この考え方を絶賛してたが）。

　印刷なんかだと、「ジョブチケット」にあたる概念で、結構馴染み深いんだけどね。。。最近、こういう考え方がはやりなのかな。

　でも、こういう標準化は、営業的に問題があるぞ。。。

　どういう考え方かと、問題については、またこんど。

流通システム開発センターのページにある、ビジネスモデル、結構良く出来てて、参考になると思う

ものものさんの、「たまゆら雑記」のブログの、積読　「ビジネス・プロセス・モデル調査研究報告書」にでてくる、流通システム開発センターの、流通システム化に関する研究開発、いけてる！かもしんない。

　事業自体は、どーでもいいんだけど（いいんかい ^^;)

---

　そこの、(1) ビジネス・プロセス・モデルの策定 にある、「ビジネス・プロセス・モデル調査研究報告書」が、ざっと見た限りでは、よく出来ていると思う。

　参考になるのは、
　　１０、１１ページの図、概略としては、きれいだと思う。
　　１２ページからの表は、一般的なプロセス内容としては、こんなもんだと思うので、
　　　実際に、自分たちが行おうとしている開発は、ふつうとどこが違うのかを比較する
　　　たたき台として使えると思う。
　　２４ページの図（３－１０）、いいっすねえ。
　　　取引条件（特売とか）の説明、きれいかも。。
　　３０ページから６４ページまでの物流関係と支払い関係は、知識として、
　　　読んでおいてもらうと、共通の意識が持ちやすいと思う。
　　　必要なことがきれいにまとまっている。

---

　(2) ビジネス・モジュールの基本設計 にかんしては、ロジックを、追っかけてないので、正しいかどうかわかんかいけど、ちょっと見た範囲では、

「ビジネス・モジュール基本設計報告書」をダウンロードして、解凍すると現れる、

・2-1-0要件定義\2-1-1システムユースケース検討\ユースケース図及び業務フロー.pdf
　内容が細かいので、このままでは、使いずらいが、とても参考になると思う

・2-2-0外部仕様設計
ビジネスプロセスが、まず、全体をつかむのにわかりやすいと思う。
　そのほかについて、よく見てないけど、いいんでないかい！！

・2-3-0内部仕様設計
　一番使えるのは、データベース設計書.pdfのデータベース設計のER図と、テーブル仕様テーブル仕様は、ウィリアムのいたずらが最近のブログで書いてきた、Excelの仕様書に近い形式で書いてあるし、ここまで、はっきりと、テーブル設計してあれば、標準として、わかりやすいんでないかい！

　データディクショナリも、いいかんじでついてきてるし（？？）

---

　ということで、流通業をやっている人は、自分たちのシステムと、標準と、どこが違うかとか、通論を学ぶのには、いいドキュメントだと思います。

　たまには、流通システム開発センターもやるじゃん。バーコード以来のヒットっていう感じです。

　あ、でも、実際にやろうとしている、「流通SCM共通プラットフォーム」は、どーでもいいんだけどね（いいんかい！！）

JAVAでRDBにアクセスするとき、SQL文、全部書きます？自動生成させます？？

　JAVAでデータベースにアクセスするとき、たとえば、

Statement stmt = con.createStatement();
String sql = "SELECT * FROM KAIGI_TBL";
ResultSet rs = stmt.executeQuery(sql);

　のような感じで、ＳＱＬ文を、「全部」自分で書きますか・・・？？

　私は、てっきり、書かないのが、普通だと思っていたんですよ(@_@!)
　つまり、
　　1.SELECTなり、UPDATEなり、ＤＢアクセスするための共通メソッドがあって、
　　2.その共通メソッドに設定する値は、ある程度自動設定し、
　　3.そのための設計書は、Excelで作られている。。。

　こういう開発ばかり（例外：この前の、ActionクラスからSQLを直接書いちゃう人）なので、最近は、そういう風に書くものかな？って思ってました。

　なので、前のブログに書いたように意識あわせのために、この記事を書きました。

　そうしないと、以前のブログなんかで、なんで、ExcelからJavaのプログラムが必要なのか、ぜんぜんわかんないですもんね！！

---

　一応、上記１～３について、説明しておきますね。

■■１について

　たとえば、データベースアクセスのSELECTをする場合（他もおなじようなもんなんでSELECTだけ説明します）、まず、こういうメソッドを、システム共通として用意しておきます。
（下のは、こんなかんじという雰囲気。正しいかどうかは確認しておりません）

　public Vector selectData(String[] komoku,String[] tbls,Vector whereKu,String[] sortKu) throws Exception
{
　// 中身は、こちら
　// メモ帳で書いて、チェックしてないので、間違えとかあるかも？？
}

これで、たとえ、どんなＳＱＬ文でも、返り値のVectorの中に、
　１レコード１エレメント（項目）で、
　　　　　　１レコードの中身は、ハッシュマップで、
　　　　　　　　キーは、カラム名、
　　　　　　　　値は、そのレコードにおけるカラムの値が、String型で
入っていることになります
（数値型のものは、Stringになっているので、使うとき、型を変える）

---

■■２、３について
　１で、komoku,tbls,whereKu,sortKuを、自動生成すれば、ＳＱＬ文がかけるということになった。
　で、そこでなんですけど、たとえば、Excelで、こんな雛形を用意して、


komoku[0] = "*";（全部検索）
tblsは、「アクセステーブル名」に書かれているテーブルをセット
whereKuの　１レコード目は項目名
　　　　　２レコード目は条件１、
　　　　　３レコード目は条件２を、（縦にみて）セットし、
sortKuを、ソートの順番をみて、設定するように、

　Excelファイルを読み込んで、Javaのプログラムを書き出す、自動生成プログラムを作ります。
　昨日までのブログで、この辺のものが作れることは、示しました。
（ここにまとめてある）
　ちなみに、ウィリアムのいたずらの主な仕事は、こういうものを作ることなので、ExcelからJava変換が重要だったのです。

　もちろん、条件式には、引数で渡された値をセットする
（たとえば > args[0]） みたいなときもあるので、すべて自動化で書かないほうが、
効率的かもしれない（それでも、自動化したほうがいいかな？？）

---

　で、よく、テーブルの項目名が変わったときっていうのが、問題としてあがっているけど、そんなもん、項目名をすぐに変えたら、いたるところで問題が起こる。

　なので、上記のselectDataメソッドの場合、返り値にVectorを返し、その要素の中のHashMapに値を入れているので、前の値も、そのハッシュマップにセットして置くようにするっていうのが、ウィリアムのいたずらがかかわった仕事ではおおいな。

（具体的にいうと、検索項目 heyaMeishoがroomNameに変わった場合、
Vector allData = selectData(komoku,tbls,whereKu,sortKu):
for(int i = 0 ; i <allData.size() i ++ ) HashMap mp = (HashMap)allData.elementAt(i);
mp.put("heyaMeisho",mp.get("roomName")); // 古い名称をセットしておく
　　allData.set(i,mp);
}

　みたいな感じで、新しい項目名の値をとってきて、前の項目名にもセットしてあげる）
　そうすれば、この返り値をもらった上位のメソッドでの変更はない。
　この名称変更はあまりないので、ここを自動生成させるメリットはあんまりないと思うけど）

---

　実際の開発では、どこまで自動化するかっていう問題がある。
　ここまできれいにやらない場合もあるし（ウィリアムのいたずらの場合、ここまでしないかな？？）
　逆に、テーブル構造が修正になったら、上記のselect内容を記述したExcelファイルを読み込み、修正があったら伝えるみたいな機能を付けることなど。。さまざまある。

って、ここまで書いて、結局結論としていいたいことは、

　だから、テーブル変更があったからって、修正が頻繁に入るっていうわけではないと思う。適切にプログラムを書いて、適切なパターン、ドキュメント規約が出来ていて、自動化するプログラムが出来てれば、ＲＤＢでも、修正箇所は、そんな目くじら立てていうほど、多くはないと思うぞ。

XMLからJava自動生成その４:XMLの内容をHashMapに入れるクラス、まとめました

　ちょっと前のブログ「XMLからJava（以外もOK)自動生成その３:DOMで、属性・テキスト・タグ名取り出し（２）」のプログラムをすこし変えて、

ＸＭＬファイル名を指定して、メソッドを呼び出すと、
　　その構造を解析して、HashMapに入れるクラス、

つくっておきました。

　やっぱ、ＨａｓｈＭａｐとかＶｅｃｔｏｒになってないと、使いにくいですよね。

---

　Javaのソースプログラムは、こちら

　そこで、staticになっている、fromXmlToHashmapメソッドを

// XMLファイルをハッシュマップに変換する // inFnameは、ＸＭＬファイル名 　　　 HashMap mp = XmlHashMap.fromXmlToHashmap(inFname);

の形で、使います（mpに結果が返ってくる）

　帰ってくるHashMapの中身などについて、書いてあるのはこちら

---

　もちろん、勝手に使ってかまいませんが、まったくの無保証です。修正して使っていただいても、ＯＫっす（というか、たぶん、パッケージとかは変えるだろう）
　現在は、最後のノード（つまり葉）にしかテキストデータがない場合について対応していますが、そのうち、どこにテキストがあってもＯＫというようにしたいと思ってます。
　あと、将来的には、書き出しもいれるかも。。。

　ということで、今、公開しましたけど、今後、もっと増えていくと思います。

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

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

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

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

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

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

　危険な香りがします。

---

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

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

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

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

---

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

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

---

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

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

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

　撤収！！

流通XML-EDIのJava化計画：その３：統一伝票の想定モデルと流通XML-EDIの問題点

　さて、昨日の話。統一伝票は、小売と卸間で、今実際使われているものなので（多分）、これと流通ＸＭＬ－ＥＤＩが合うかどうか、見てみました。

　はい。合わないです。

流通XML-EDIの想定するモデルと、統一伝票の想定するモデルで合わなさそうなところ

・統一伝票では、問屋（卸）間、さらに工場までも含めているので、直送という概念があります。つまり、ものの流れとお金の流れは一致しません。流通XML-EDIのメッセージでは、そういうものは、たぶん、表現できなさそう。

・統一伝票では、返品の伝票があります。流通ＸＭＬ－ＥＤＩには、返品はない？

　ってかんじで、あわないんです。
　実際に、小売のシステム、卸のシステムを開発するとなると、現状の伝票の流れを元にモデル化するか、統一伝票の流れをもとにモデル化するということになると思います。
　そうすると、流通ＸＭＬ－ＥＤＩで考えられているモデルとかなりずれてくると思います。

　なので、流通ＸＭＬ－ＥＤＩをもとに考えられたクラスがJavaで出来ていて、それを実際のモデルに合わせる際にextendsするのであれば、できそうだし、そういう、フレームワークとしてとらえるのであれば、流通ＸＭＬ－ＥＤＩは役に立つと思います。

　でも、流通ＸＭＬ－ＥＤＩって、システムとしてできてるのよね。
　これに手を入れて修正するって言うのは。。１から作り直したほうが早かったりして(^^;)
　（だって、返品の「業務」ロジックを考えないといけなくなっちゃうんですよ。これ採用したら！）

---

　なお、統一伝票をJavaで表現する場合、この伝票自体を１つのクラスにしてしまえばよさそうですが、流通ＸＭＬ－ＥＤＩは、交換する６種類のＸＭＬデータに対して１つずつクラスを定義したほうがいいと思います。

流通XML-EDIのJAVA化計画：その2：昨日のクラスとXML-EDIのメッセージと統一伝票の関係

流通XML-EDIについて、昨日、クラスを定義したので（今日修正しました。理由は、この記事の本文中にあります）。今日は、以下のテーマについて

(今日のお題）

・肝心の流通ＸＭＬ－ＥＤＩには、どんな種類があるか ・ＸＭＬで定義しているのはなにか？ ・そのクラスとどのようにかかわってくるのか？ ・同じような小売と卸の決め事に統一伝票があるが、それはどうかかわるのか？

について説明します。

---

肝心の流通ＸＭＬ－ＥＤＩには、どんな種類があるか

　６つのメッセージ交換をXMLで定義しています。
　その定義しているものは、以下のとおりです。
（概説書P14の図をそのまままとめています）

メッセージ交換名	小売からみると	卸からみると
（１）商品マスタ	商品情報（基本）の入力	商品情報（基本）の出力
（２）発注	発注の出力	受注の入力
（３）入荷予定	入荷予定の出力	出荷予定の入力
（４）受領	出荷確定の出力	出荷確定の入力
（５）支払案内	支払い案内の出力	支払い案内の入力
（６）請求	請求の入力	請求の出力

---

ＸＭＬで定義しているのはなにか？

小売と卸のメッセージ交換部分について、定義しています。
つまり、情報のやりとりなわけで、これは、昔（というか、今でもリアルの世界では）伝票に書いてある部分のことです。

　昨日定義したのは、小売と卸の業務であり、業務は伝票の行き来（入出力）でおこなわれるので、当然、昨日定義したクラスの入出力にもなるわけです。
　その関係は、こちら（上の表と対比してね）。

メッセージ交換名	小売からみると	卸からみると
（１）商品マスタ	商談の入力	商談の出力
（２）発注	発注の出力	受注の入力
（３）入荷予定	入荷予定の出力	出荷予定の入力
（４）受領	検品の出力	＊納品の入力
（５）支払案内	支払の出力	支払確認の入力
（６）請求	請求書受理の入力	請求書発行の出力

＊納品の入力＝納品が確定したことの入力の意味。納品書とは違う
５番と６番は、手順と入れ替わっています。

で、はじめ、昨日のブログのように書いていたら、入荷と出荷で、２つのメッセージが行き来することになり、他は１つなので、対照的にへん。なんか見落としてるかも？ということで、クラスを
（小売側）入荷については：入荷予定と検品に
（卸側）出荷については：出荷予定と納品に
わけました。その結果について、昨日のブログを修正してあります。

---

統一伝票は、どうかかわるのか

　統一伝票も、小売卸間でのメッセージのやりとりです。
ということは、上記のXML同様、統一伝票でも、伝票一枚一枚は、上記の６つのメッセージに対応、ないしは継承（XML-EDIが一般的、統一伝票が、細かくなってる）でないと変です。

　そうなっているのかについては、今後調べます。

　統一伝票の例として、e-お菓子ネット　統一伝票マニュアル　第四版を参考にしたいと思ってます。（ ここにある。ただしＰＤＦ）

流通XML-EDIのJAVA化計画：その１：クラスをきめてみる（１４日修正）

　前のブログで、流通XML-EDIをJavaで開発する流通業システムに流用する話。

　まずは、概説書をもとに、クラスをきってみましょう。
　クラスには、佐藤　正美氏の考え方に基づき（？）リソースとイベントの２種類があると考えますと、


■■　リソース
　リソースは、以下のとおり

　　１．小売（発注先）
　　　　これには、以下の２種類
　　　　　１－１：支払先（支払う会社）
　　　　　１－２：納入先
　　メソッドの定義は概説書にないので、CRUD（登録、照会、更新、削除）とします。

　　２．卸（受注先）
　　　　これも、本来は２種類に分かれるはずである
　　　　　２－１：入金先
　　　　　２－２：物流センター
　　　　ところが、この２種類は、はっきりしていない。
（よくある話で、ものが送ってくるのは、工場直送とか、大きな卸会社なんだけど、お金は、小さな商社に払うなんていうケース）メソッドの定義は概説書にないので、CRUD（登録、照会、更新、削除）とします。

　　３．商品
　メソッドの定義は、概説書１４ページの商品マスタ管理は、契約単価の提案であり、これは商談に当たると思います。ふつうのマスタ管理とはちょっと離れているので、それらは除き、ここではCRUD（登録、照会、更新、削除）をメソッドとします。

■■　イベント
　概説書１４ページの赤と黄色の四角をもとにわけます。
　メソッドについては、詳しく書きません（こまかくなってしまうので）

・小売側
　　小売-４．商談
　　商談を受けるほうになります。

　　小売-５．発注

　　小売-６．入荷
　　入荷予定と、入荷確定をまとめます
　　（１４日修正）
　　　これ、まとめないほうがいいみたいです。
　　　つまり、以下のようにします。

　　小売-６．入荷予定

　　小売-７．検品
　　　これ以降、１番ずつ番号ずらしました

　　小売-８．請求書受理
　　　請求を、このように書いておきます。買掛も、ここに入れておきます

　　小売-９．支払
　　　買掛消しこみもここに入れます。

・卸側
　　卸-４．商談
　　小売側と逆で、商談をするほうになります

　　卸-５．受注

　　卸-６．出荷
　　出荷予定と、出荷確定をまとめます
　　（１４日修正）
　　　これも、まとめないほうがいいみたいです。
　　　つまり、以下のようにします。

　　卸-６．出荷予定

　　卸-７．納品
　　　以下、番号がずれます

　　卸-８．請求書発行
　　　請求を、このように書いておきます。売掛も、ここに入れておきます

　　卸-９．支払確認
　　　支払を、このように書いておきます。小売からの売り上げを確認します。
　　　売掛消しこみもここに入れます。

---

　なお、リソースの、小売、卸、商品に関しては、小売側、卸側にも、どちらにも共通してあることになります。
　ただし、小売の場合には、小売には、自社情報、卸には、発注先情報（仕入先情報）が入ることになり、
　卸の場合には、受注先情報（得意先情報）、自社情報が入ることになります。
　ここで口座開設の業務が抜けていますが、これは、小売の場合は、卸マスタの登録、卸の場合は、小売マスタの登録に相当します。

　したがって、小売も卸も、この８（１４日訂正）９つのクラスが基本で、そこにメソッドを配置することになります。
　その前に、小売・卸間のメッセージをXMLで表現したものについてですが、それは、また記事を改めて、近いうちに書きます。