20190426(金) 19:00から開催しました。いつも場所提供で協力いただいている（株）テラスカイの大阪支店が淀屋橋に移転され、新しい場所での第一回目でした。いつもご協力ありがとうございます。
今回はある意味実験的なテーマでした。渡辺幸三さんが無料公開されているCONCEPTWAREを素材として佐野が＜データモデルから読み解く業務パターン＞のたたき台を提示しました。それを渡辺幸三さんを含む皆さんで検討するというスタイルでした。また賛助会員の方が遠方から入れるようにGoogleのmeetでつないだところ、インターネット会議で参加された方からも貴重な発言を頂けました。
ただ一つ困ったことはオフィス街のため2次会の居酒屋さんのラストオーダーが22時だったことです。21時から2次会ですから1時間しか飲み物の注文も出来ません。ただそのために健全な会に生まれ変わるかも知れません（笑）。案内はこちら
https://drive.google.com/open?id=1gHF-KBWFN85VvqkWvlZ26Zr_qskxmAzD
![]()
![]()
![]()
![]()
今回はある意味実験的なテーマでした。渡辺幸三さんが無料公開されているCONCEPTWAREを素材として佐野が＜データモデルから読み解く業務パターン＞のたたき台を提示しました。それを渡辺幸三さんを含む皆さんで検討するというスタイルでした。また賛助会員の方が遠方から入れるようにGoogleのmeetでつないだところ、インターネット会議で参加された方からも貴重な発言を頂けました。
ただ一つ困ったことはオフィス街のため2次会の居酒屋さんのラストオーダーが22時だったことです。21時から2次会ですから1時間しか飲み物の注文も出来ません。ただそのために健全な会に生まれ変わるかも知れません（笑）。案内はこちら
＜今回の勉強宴会資料＞
【データモデルから読み解く業務パターン（試案）】https://drive.google.com/open?id=1gHF-KBWFN85VvqkWvlZ26Zr_qskxmAzD
データモデルから読み解く業務パターン
デービーコンセプト 渡辺 幸三さん
（株）テラスカイ 佐野 初夫
データモデルを出来る人と出来ない人の差はどこにあるのかという議論を何度かやったことがあります。モデルの美しさを気持ち良いと感じる能力など色々な理由があるとは思いますが、もしかすると業務上の経験から、何かの業務パターンを持っているか否かが一つの分水嶺になっているのかも知れないと考えました。そこでCONCEPTWARE／販売管理を佐野がどう読んでいるかを解説し、それにモデル作者の渡辺さんを始めとして皆さんにツッコミを入れてもらうという企画を考えました。
１．業務フロー
まずは販売管理についての大枠の説明です。国内・海外の仕入先から仕入れて国内の顧客に売るという卸売業を対象とした業務モデルです。その時に考える3要素は「売上」「仕入れ」そして在庫の増減を表す「受払」です。
売上と受払が関係する取引は「売上出荷・売上返品」です。そういう風にこの3つがどう関連するかを考えてサブシステムが別れている事がわかります。一般仕入取引というのは売上にも受払にも関係しない仕入ですので、例えば買掛金額の年次調整処理などです。
２．職務別担当業務－プロトコル／パネル
渡辺さんのモデルは３要素分析法です。３要素はなにかご存知ですか？
実は業務フローは３要素の１つには入っていません。データモデルと画面などのパネル、そしてあと一つは「どういうきっかけで何をするか」というプロトコルです。このプロトコルをしっかり設計すれば、設計完了時点で業務マニュアルが完成すると渡辺さんの本には書いてあります。
３．データモデル
ここから、私がデータモデルを読みながらどういうパターンを見つけ出したかを解説していきます。（資料に詳しく書きましたので興味がある方はそちらを御覧ください。賛助会員コミュニティにはpptで公開してあります。このブログでは特に議論になったものを中心に紹介します）
（１）ヒエラルキー構造パターン
部門の項目として「上位部門」という属性を持つのではなく、別テーブルの「部門構成」に日付をキーとして上位部門Ｃを持つ構造。これを使うと組織変更の予約が出来ます。
→最新のブログに書いたのですが、ヒエラルキーを表すというよりは、「期間に従属する部門の属性」だと考えたほうがわかりやすいと思います。
（２）実体と役割の派生パターン
取引先という企業属性とは別テーブルとして、顧客や仕入先という「役割（ロール）」のテーブルを派生関係で持つというパターン。
（３）重複禁止パターン
取引先の漢字名を二次識別にすることでユニーク性を担保したモデルになっています。
→実際の企業名は平成20年の会社法施行により、同一商号の法人が同じ市区町村内にあっても、その商号の会社を作れるようになりました。そのため例えば同じ「帝国ホテル」が複数ある時は例えば「帝国ホテル（大阪）」などとします。
（４）表示順パターン
S/M/LなどSortすると希望通りに並ばない時は表示順を持ちます。セット構成の中に「構成一覧順」があるのがそれです。他のテーブルでは渡辺さんの造語の「月序」という項目が出てきますがそれも同じです。会計年度が４月の会社なら、４月の月序は「０１」とします。
（５）増減履歴管理パターン
今日のパターンの中で私（佐野）が一番重要だと考え、一番わかりにくいだろうと考えているパターンです。入荷明細や仕入振替など仕入が発生した時にそのテーブルの中に連番「取引管理No」を含めます。買掛増減履歴を書く時にその実体テーブルの「取引管理No」をセットすることで、どの原因で買掛が増減したかをトレースすることが出来ます。
この構造は在庫を増減する受払履歴にも使われています。
自分自身のテーブルの主キーとして連番を振るだけでなく、取引に統一的な別の連番を同時に振り、二次識別として登録するというテクニックについて、私はこのCONCEPTWARE販売管理で初めて見ました。三要素分析法だけの独自のテクニックとして「テーブルの帰属サブシステムを明確にする」というものがあります。青いテーブルだけがこのサブシステムに帰属しているためCRUDを許されています。黒いテーブルは他のサブシステム帰属ですのでRしかされています。一度実業務で使おうとして途中で断念したことがあるのですが、それを可能にしている秘密のテクニックが、この増減履歴管理パターンなのだと考えています。
（６）処理済み判断パターン
買掛増減履歴の「支払依頼No」は最初はNULLになっています。支払期日が来ており「支払依頼NoがNULL」のレコードだけを抽出して支払依頼レコードを作成します。その時に作られた支払依頼Noを買掛増減履歴にも更新します。
これは請求書を作成する時などにも良く使うテクニックです。売上明細に、請求書Noを入れると請求対象明細をトレースすることが簡単になりますので、バッチ処理のリランも簡単になります。
→（渡辺さん）こういう番号をバッチNoと呼んで、バッチテーブルパターンと呼びます
→（井田さん）明細見出しパターンと呼ぶことがあります
（７）予定スーパータイプパターン
これも相当読み解くのが難しいです。こもパターンこそが「在庫推移監視方式」のキモになっていますのでぜひ読み込んでみて下さい。
→（渡辺さん）この在庫推移監視方式を活かすためには、在庫の回転を良くすることで評価される役割の人を造ることが重要です。在庫推移が見えるだけでは何も改善されません。
→（下山さん）Accessでこの販売管理を動かそうとした時に初めて理解出来ました
→（佐々木さん）魚の販売管理でこれを使いました。受払予定に時間まで書くと、営業はその時間の魚を売り始めます。この在庫推移監視方式に助けられました。
（８）サブストラクチャーパターン
発注から入荷し検品するという「流れ」をTHデータモデルにあやかってこう表現してみました。主キーの移り変わりで業務の流れを追うことが出来ます。
- 発注明細：発注No、発注行
- 入荷明細：発注No、発注行、入荷行 （分納があるため）
分納があると言われて慌てて受注行を分けたりして滅茶苦茶なデータモデルにされることがあります。分納がある時は次のようなモデルになります。
＜質疑応答＞
親子関係と参照関係の違いは？
- 親子は主キーを共有しますので絶対変更出来ない文字通り親子です。
- 参照関係は恋人関係のように関係が変わる可能性のあるものです
＜考察＞
初めてやったわりには評判が良くて安心しました。パターン名の案も思いつかれたらぜひ教えて下さい。私が付けた「処理済み判断パターン」はこれからは井田さんのアイデアを採用して「明細見出しパターン」と呼ぼうと思います。
他のCONCEPTWAREを読めばもっといろいろなパターンが見つかると思います。発表したいという方がおられましたら是非連絡して下さい。
以上