２人の方法論者によるデータモデリング激レア対談＜第62回IT勉強宴会in新大阪＞

20180327(金)　19:00から開催しました。偶然、佐藤正美さんが住友電工情報システム様主催のセミナーで大阪に来られる事を知り、ついでに遊びに来てほしいと依頼したところ快諾いただき開催出来ました。

佐藤正美さんは一般の講演会などにめったにされない方ですので貴重な会となりました。渡辺幸三さんとは挨拶程度は何度かされているのですが、がっつり会話することは初めてでした。お二人とも気心を良く存じてますのでつかみ合いの喧嘩になったりしない自信はありましたが、どういう展開になるのか読めないままドキドキの開催となりました。

申し込み案内はこちら

今回もめちゃくちゃ面白かったですね。佐藤正美さんの方法論だけでシステム開発する会社株式会社アイティーエスから５名に来ていただきました。その他佐藤さんの名前で初めて来ていただいた方も多かったです。東京からこの勉強会のためだけに２名こられましたし、名古屋からも４名来ていただいてました。
2次会は同じビルのＢ１「くつろぎ庵」さんで２３名、３次会は昨年の忘年会で使った「ダイニングバー・グー」で７人。そして４次会は６人で「ＴＨＥ　ＢＡＲ新大阪」。３時半にお開きでした。

＜２人の方法論者によるデータモデリング激レア対談＞

１．アンケート

従業員マスタの中に部門を入れると、ＮＵＬＬが発生する可能性が出てきます。対照表はＮＵＬＬを出さない工夫です。
その後Ｔ字形ＥＲは明らかに間違っていることに気付き、ＴＭを作りました。今はそれをまた修正してＴＭ２．０と呼んでいますが、もうすぐＴＭ３．０になる予定です。

ところで、渡辺さんは自分の手法をＤＯＡ(Data Oriented Approach:データ中心アプローチ）と呼んでるの？ＤＯＡってどういう意味で使っているのですか？
（渡辺さん）ＰｏＡ(Process Oriented Approach:プロセス中心アプローチ）との対比でＤＯＡと言ってます。
（佐藤さん）それなら僕のもＤＯＡですね。
（佐野）日本のいわゆるＤＯＡの皆さんは関数従属性を大変重視して設計されていると考えています。ピーター・チェンのＥＲ図は関数従属性を捨てた表記法だと思います。オブジェクトモデルも関数従属性を使いません。私の勝手な用語定義ですが、関数従属性を重視した設計手法はＤＯＡと呼んでも良いのではないでしょうか？

３．お２人が方法論を生み出された経緯について教えて下さい

（渡辺さん）最初SIerに勤めていて、IBMのSystem36からSystem38、AS400と移ってきました。System38の時に本格的なRDBが使えるようになったので、勉強しました。ところがRDBなのに昔ながらのポインタ方式で使っている人が多かったです。
教えたのですが、「記号で書かれてもわからない」と言われました。関数従属性でテーブル設計することは初心者には難しかったようです。
その後AS400の4GL（CASEツール）が大好きになりました。パターンを入れると画面定義まで自動でやってくれます。新しいパターンを作るのは大変なのですがそれを創るとすごく便利になるという経験をしました。その時に「データ構造をトポロジーのパターンに落とし込めば良い。画面などは自動で出来る」という事に気付きました。

ところが、設計書だけは手書きなので大変でした。そこでDelphiで設計ツールを作成しました。独立してからJavaでX-TEA Modelerを作り公開しました。

（佐藤さん）リビア大使館のガードマンをやっていた時、JapanTimesの募集でアシストが翻訳家を募集していたので応募しました。アンダーセンに少し在籍していた経歴から、翻訳は1行もせずに固定資産会計のパッケージ作成を手伝いしました。その後MRPのパッケージを日本に導入普及する仕事を担当していました。当時日本の企業は、ほとんど製番管理かカンバン方式を使っていて、MRPは普及していなかった。ほぼ完成した時にビル・トッテン氏に呼び出され、ＭＲＰは販売を中止するから、ＲＤＢをやってくれと言われました。
辞表をだしたのですが、米国に行けるという事で引き受けました。辞表は7回くらい出しています。後から考えると技術者だけでやっていたので上手く行かなかったので毛色の変わったメンバを投入しようと思ったようです。そのＲＤＢは世界初のデータコムＤＢ(英語wiki)です。RDBの開発者たちから内部構造の基本を直接に指導してもらいました

大阪の或る企業がRDBのパフォーマンスで困っていました。私がその企業に3日間出向いて、パフォーマンスの改善を担当することになりました。行くとユーザから「CPUを80%下げてくれ」と言われました。本番稼働中ですから数千本のプログラムを書きなおす事は出来ません。アクセスの状況などを調査して改善した結果2日目でCPUが60%下がりました。あと20%が難しいと考えているとユーザは大喜びで「あとはメモリやスペックを上げて対応する」との事でした。このユーザにこういわれました。「自動車を買う時にエンジンの構造を知らないと運転できないなら買いますか？構造を知らないと使えないならRDBなんて買えない」
その企業に言われて、コッド論文を読んで、データ設計の分野を学習しました。コッド論文を読んで、コッド正規形の『弱点』を補強するためにＴ字形ER法を作りました。しかし、Ｔ字形ER法には、いくつか不備がありました。そこで、数学基礎論を学習してＴ字形ER法を修正したのがTMです。

４．方法論は何を保証するのでしょうか？

（渡辺さん）パターンにさえはまれば、プログラムが簡単に作れることを保証するものだと考えています。3要素分析法は「データの形（データモデル）」と「業務の形（アクションツリー）」から機能の形（画面・帳票）を導き出し、この３つを設計する手法です。ここまで決まればプログラムは簡単に作れますし、X-TEA DriverなどのDSP(Domain Specific Platform：ドメイン固有基盤)を使えばノンプログラミングで動かすことも出来ます。

（佐藤さん）TMは規則しかないので、規則通りにやれば中学生でも正しいモデルが書けるという事はあります。ただしそれを読むには業務知識が必要です。
ユーザ企業で、ＲＡＤ(Rapid Application Developmen)、今でいうアジャイル開発を行う事があります。100万ステップ規模のシステムを6ヵ月で構築出来ると謳ってます。
全社統一でＴＭを使えるなら、SIerを決められるので楽です。部分採用の場合は政治的につぶされるという経験を何度かしています。TMだけでなく3要素分析法やTHなどの名の通った方法論ならどれを選択しても失敗しません。ただ、既に入っているSIerさんにとって工数が下がる事は良い事ではないのかも知れません。

５．モデルを実装にどうつなげるのでしょうか？

（渡辺さん）方法論としては先ほどいった３つを押さえます。DSPという業務システムを生み出す開発基盤を使えばそのまま動きます。
3要素分析法を作った時は、DSPまで考えてませんでした。DelphiのUIはパターンを選ぶとパターンに応じたプロパティを設定するようになっています。「こんな風にアプリケーションを定義したいな」と考えてX-TEA Driverを作りました。

（佐藤さん）ＴＭのモデル図と、アトリビュートリスト（項目定義）を作ります。アトリビュートリストには制約も書いてあります。画面や処理でどうアクセスするかを考えてINDEX-KEYの定義表を作ります。
そこまで出来ると、アルゴリズムの指示書を書くことがあります。これは簡単なので本には書いてませんが、どのエンティティをどのIndexを使ってどういうSQLを書くかを指示するものです。ここまで設計しますので、プログラマーはこの通り書くだけです。

インデックスオンリーについて説明します。
ＴＭで簡単に受注エンティティを書きます。INDEX-KEYの定義表には、まずそこで出てくる全項目を縦に書きます。処理として「顧客別の注文一覧表が欲しい」と言われると、アクセスする順番に番号を付けます。「受注数の多いもの順に一覧が欲しい」と言われると、受注数をdecendingにして順番を付けます。これをCreate Indexすれば検索の時にデータアクセスしませんので圧倒的に早くなります。

所感

お二人とも相当深いところまでお話していただいて大変ありがたかったです。
前回来てくれた、情報処理の専門学校の優秀な学生さんが、「学校ではデータモデリングという言葉を一切習わない」と言っていた事を佐藤さんにお伝えすると驚かれていました。いま新入社員で入ってこられるIT技術者にどうやってこういう技術を伝えていくのかというのはこの業界の大きな課題でしょう。

以上