ＩＴ勉強宴会blog

初回でしたので、ちょっと詰め込みすぎの内容でした。今思うと、相当もったいない話です。それぞれ２時間かけてもらっても話し切れない内容を１０分でお願いしてしまいました（すみません）

当然ながら相当オーバしましたが、内容は濃くなったのでよかったです。

■久保敦啓氏　「ＧｉｔＨｕｂの使い方」

ソースの履歴管理のツールとして、サブバージョン（ＳＶ）やコンカレント・バージョンシステム（ＣＶＳ）が良く使われていたが、動作が重かった。linuxの原作者がLinuxカーネルのソース管理を目的として「Ｇｉｔ」を作った。メンテナンスは日本人（濱野純氏）がされている。

Ｇｉｔを用いてプロジェクト管理を行うホスティングサービスがＧｉｔＨｕｂである。条件によるが無料で仕様可能。

複数人で共通のソースの部分部分を同時に修正しても不具合が発生しない。

＜私見＞
久保氏はご自分のオープンソース開発(MakeGoodやPieceFramework)に、実際に使われているため相当説得力がありました。リポジトリを公開するなら無料で使えるという価格体系もソフトウェアの発展を目指しているという意志が明確で好感が持てます。

■杉本啓氏　「これからの会計システム開発とＦｕｓｉｏｎＰｌａｃｅ」

会計業務という分野（ドメイン）の問題点は、経営者が必要とする「Planning & Reporting」が立ち遅れていること。情報発生元の業務（販売業務など）と財務会計のシステム化は進んでいるが、予算計画と経営報告ほとんどの会社がEXCELを駆使して人海戦術で対応しているのが実態。

システム化出来ない原因は、次の４点である。
１．会社ごと、部門ごとにやり方がバラバラ
２．業務要件が短期的に変化しやすい
３．１システムあたりのユーザ数が少ない（例外もある）
４．とにもかくにも、EXCELで何とかなっている

従来のシステム開発の方法では、費用面でもスピード面でも対応出来ない。それを解決するためメタモデル（リアルタイム多次元データベース）を作った。会計に特化しているため、ほとんどの要件がこのメタモデルの組み合わせで作り上げる事が出来る。そのツールがFusionPlaceである。

＜私見＞
いわゆるデータウェアハウスやＯＬＡＰツールの廉価版に見えますが、あえて汎用化を目指していない所がまったく違います。最近はやりのドメイン駆動言語（ＤＳＬ）の実践例だとも言えます。会計処理であれば勘定科目にさえ分解して年度・版数などを持てばほとんどの事が出来るでしょう。そのアクセス方法を提供されているなら相当使いやすいツールだろうと思いました。

■渡辺幸三氏「Xead Driverの紹介」
（資料なし）

DOAで設計した内容を画面から入力するだけで業務システムが出来るフリーツールの紹介。実際の内容は渡辺さんのページからダウンロードして使ってみてください。

このXeed Driverについて、私なりに位置づけを解説したいと思いますが、長くなりますので別エントリーとします。

■佐野初夫　「システム設計注意点－運用を考慮する①－」

運用を考慮した設計が出来ていないシステムが多い事を憂えて
・考慮しないとどういう事態が発生するか
・どういうタイミングで何をすれば良いのか
を説明した。

また、仮設ではあるが運用を考慮するとは
①人的処理（人間の操作）の考慮
②業務監視の考慮
③障害発生時の考慮
の３つをおさえれば良いという事を事例を交え説明した。

＜私見＞
最近、フォーマルメソッドだとか非機能要求グレードだとか現実離れした解決策が提唱されています。それだけ費用と期間をかけられるシステムが日本にどれだけあるのかなぁと思ってしまいます。作る側の論理でしかないでしょう。この３点だけ押さえればとりあえず破綻はしないだろうと考えています。

店を出たのは開始から４時間経過していました。その後も一部は夜の街へ・・・

データ指向設計（DOA)でテーブルと機能の仕様書を作成するだけで、プログラミングせずに業務システムが動くというツールがＸＥＡＤ　Ｄｒｉｖｅｒです。

夢のようなツールだと感じられるでしょうが、実は渡辺氏の最初の出版作である「業務別データベース設計のためのデータモデリング入門」の中にこの考えは書かれていました。この本は2001年に出版されたものですから、、氏は１０年以上前からプログラミングは不要だと言い続け、ようやく実現するためのツールを自作され発表されたのです。設計ツールであるＸＥＡＤ　ＭｏｄｅｌｅｒですらこのＤｒｉｖｅｒへのステップに過ぎなかったのかも知れません。

ＤＯＡの設計だけで何故動くのでしょうか？ＤＯＡという言葉の中には実は画面／帳票の設計も含まれているからです。この辺りはご存じのない方が多いと思いますので、少し長くなりますがＤＯＡの起源から説明したいと思います。

１．ＰＬＡＮ－ＤＢ

一口にDOAと言っても実は多くの手法があります。元祖DOAと呼べるのは椿正明氏が作られた「THモデル」です。ＴＨモデルで多くの企業を幸せにするため、データ総研（株）を創設されました。
このモデルの特徴は、リソース系（ＭＤＭ-Master Data Management）とイベント系（各アプリ）を分離し、会社全体をモデル化する事です。販売管理と生産管理で同じ商品マスタを２つ持つという事態を避けることが出来ます。またＫＥＹ、参照ＫＥＹ、加工データなど属性をもれなく書いて、処理をデータモデル上でトレース出来るようにします。レイアウトルールも細かく決まってますので、誰が書いてもほぼ同じものが出来るようになります。

実際にはデータモデルだけでは完全な設計とは言えないため、業務の流れを表す「ＩＰＦ」と加工データの導出ルールを描く「ＳＰＦ」を含めて「PLAN-DB」と呼ばれています。
※図は、http://www6.airnet.ne.jp/scmbm/seika2008/20080927-tsubaki.pdfからコピーしました

PLAN-DB　＝　THモデル（データモデル）
＋　ＩＰＦ（Information Process Flow)チャート
＋　ＳＰＦ（Schema Process Flow）チャート

２．米国の状況

そもそもＲＤＢを発明したコッド氏がその理論として「正規形」を定義したのが発祥です。主キーと従属項目との間の関数従属性を厳格に保つことで
①冗長データをなくし　　②更新異常を防ごう
という趣旨です。この考えに従って形式的に整理する手法を「構文論モデル」と呼びます。

その後ピーターチェン氏が項目間でなくテーブル間の関係を表すＥＲＤ（エンティティ・リレーションシップ・ダイヤグラム）を発案しました。業務としての意味を図示しようとする手法ですので「意味論モデル」と呼びます。現実との間に指示関係がある事を前提としたからです。この構文論と意味論のバランスをどう取るかで各種手法が生まれているようですが、哲学的な話になるので私はついていけてません。

チェン氏がＥＲＤを発表した同じ学会で椿氏はＴＨモデルを発表されました。奇しくも日米で同時発生的に生まれた２つの手法です。この辺りの経緯は、椿氏ご自身が整理されていますのでお読みください。椿氏が書かれている「一元論」と「二元論」の話は語り出すと深い話になります。私自身は、米国流と日本流のDOAの本質的な違いではないかと考えています。

チェン氏の記法は、日本では（恐らく）情報処理試験くらいしか使いません(笑)

米国のNIST（国立標準技術研究所）が定めたＩＤＥＦ１Ｘか、

ジェ－ムズマーチン氏が発案したＩＥ（information engineering）表記法

が使われます。両者とも線の上に関連（リレーションシップ）を文字で表しているのが特徴です。

※余談ですが、「リレーション」も「リレーションシップ」も関係と訳す事が出来ます。それでは混乱しますので、ｙ＝ｆ（ｘ）というような厳格な関数を「リレーション」、リレーションとリレーションの関係を「リレーションシップ」と呼び、「関連」と訳すようです。フレンドとフレンドの関連をフレンドシップと言うのと同じ使い方です。
※コッド氏は主キーから関数的に導き出される項目の集合をテーブルと定義しました。リレーショナルテーブルです。そのテーブルとテーブルの間のゆるい関係がリレーションシップです。

日本の技術者もIDEF1XかIEが主流です。ただ、関連の名称までは書かない事が多いです。これは気づかず一元論で整理しているためでしょう。コッド正規形とＥＲＤが同じものだと考えてる方もいます。また、ＩＤＥＦ１ＸもＩＥも、ＰＬＡＮ－ＤＢのデータモデル（ＴＨモデル）の部分だけだという事に注意して下さい。IPFやSPFに当たる表記は各自バラバラですし、それらが必要だという事に気付いていないＳＥも多いです。

※そもそも何のモデルも書かず画面帳票だけで設計するＳＥが多い事に危機感を覚えます。

３．Ｔ字形ＥＲ

日本にＲＤＢが入ってきた当初、相当大きな混乱が生じました。レスポンスが出ないのです。そのトラブルシューティングのため当時アシスト社から米国ＡＤＲ社に派遣されていた佐藤正美氏が駆り出されコンタルティングを行い劇的な改善をされました。その障害対応のコンサルティングで毎回同じことをやっている事に気付き、手順化して「Ｔ字形ＥＲ」を編み出されたそうです。

この手法は、元々すでに動いているデータベースをチューニングする手法から来ているためか、業務を分析するというトップダウンの手順ではありません。すでにある（または作りたい）画面／帳票を元に整理する手法です。つまりＴ字形ＥＲ手法を使う前に画面／帳票が存在することが前提になっています。

すでにある画面／帳票を要素ごとに分解し、データモデルの図として、業務の流れに従って左から右に記述します。そのため、Ｔ字形ＥＲはデータモデルを読むことで業務フローの代わりになる（と理解しています）。正しく分析し記述された図を読むと、その会社の実態が赤裸々に見えてしまうそうです。たとえば、リソースが少なくてイベントが多い会社はビジネス的発展性が望めないとか、顧客第一主義と言いながら顧客の属性が少ない会社は顧客に対して（会社として）興味を持っていないため組織として危険だとかです。この辺りは「データベース設計論 T字形ER」などを読まれて、この手法が現実の業務をいかに厳格に設計するかを理解して頂かないとピンとこないでしょう。

手順は単純なのですが、理論ベースにヴィトゲンシュタインさんやらカルナップさんなど哲学者がおいでになると混乱します。この手法は、私の知ってる限り唯一「その設計自体が正しいか」を検証する手順を持っています。主キーすら定義しないという手法ですから採用するには勇気が必要ですが、大手自動車会社など大規模システムで採用され効果を上げているそうです。

４．三要素分析法

渡辺氏の「三要素分析法」のデータモデルは、直接的にはＩＥ表記法を洗練させたものです。線の書き方はほぼ同じですが、属性項目を縦でなく横に羅列することで、項目の実際の値を書けるようにしたことが工夫です。

三要素の２つ目は、業務モデル（業務定義）です。アクションツリー形式で「仕事の進め方を定義したもの」で、個々の業務モデルが業務マニュアルの１単位となります。渡辺氏の本の中で、設計が終わった段階で業務マニュアルを書けるべきと書かれているのは、この業務モデルを必須要素とされているためです。

ここではいくつかの業務定義の連携様式を示す図面を紹介します。渡辺氏はＤＦＤと呼ぶこともありますが、悪名高い（？）ＤＦＤと混同される事を恐れてここでは業務フローと呼びます。この業務フローの工夫は「発生タイミングを記述できる」事です。実際の業務はイベントドリブンで発生します。それを設計段階でお客様とレビュー出来るため思い違いを避ける事が出来ます。また、四角と丸だけの無機質なアイコンでなく具体的なイメージを使うため専門家でないお客様にもわかりやすく工夫されています。

三要素の最後が「機能モデル」です。これは何と、画面／帳票（パネル）そのものを設計してしまいます。実際には外部インターフェースなども機能モデルになりますが大部分はパネルです。一つずつの項目がデータモデルのどの項目をどう計算して表示するのかまで定義します。

しかも、データモデルのテーブルとテーブルの関連に依って、パネルのパターンはほぼ決まっていると主張されます。パネルは単機能とすべきであり、新規登録／修正／削除は別々のパネルにすることを推奨されています。この辺りは「業務システムモデリング練習帳」を読むまで私自身も重視していなかった部分ですが実は三要素分析法から動的制御システムへの橋渡しのカギはここにあったのだと考えています。

この三要素は、どれが先という事でなく繰り返しレビューしながら同時にトップダウンで設計します。この手法で設計が終われば、画面も帳票も、計算ロジックまで設計が終わっている事になります。

５．そして動的制御へ

この三要素は、ＰＬＡＮ－ＤＢのＴＨモデル・ＩＰＦ・ＳＰＦにそれぞれ対応しています。Ｔ字形ＥＲの説明で、「すでにある（または作りたい）画面／帳票を元に」すると書きましたが、T字形の設計でも必要に応じて画面／帳票を変えます。出来上がったテーブル（エンティティ）を「業務の流れに従って」記述します。つまり設計する要素は、PLAN-DBもＴ字形ＥＲも三要素分析法も大きく変わらない。と私には思えます。

一番の違いは、三要素分析法は設計のアウトプットとしてパネルを定義している事です。メモがあるとか人によって作るとかでなく必須要素とされています。そしてそのパネルは、データモデルの関連から自ずと数パターンに収斂させ得るし、それぞれのパターンにもとづいてまとめられた仕様書を用意すれば、その内容にもとづいてパネルを動的に立ち上げることが可能だと主張されています。「コードの自動生成」ではなく「仕様書にもとづく動的制御」なのです。

※収斂されうるのか、収斂しない時は自動実行をあきらめるのかは今後の検証が必要でしょう。
ＣＯＮＣＥＰＴＷＡＲＥというフリーの業務設計結果を公開されていますので、その業務群が問題なく動くようにする事が検証になるでしょう。

この事を１０年以上前から主張されていた事は慧眼としか思えません。そしてその主張を実現できるツールを一人で作られようやく完成し日の目を見ようとしています。まだβ版ですが、日本発のフリーツールとして世界で使われ、無駄なＩＴ投資が抑制されることを願っています。

－－－－－－－－－－－－－－－－
長文におつきあい頂きありがとうございました。もし渡辺氏の本をまだ読まれた事がなければ、「上流工程入門」をお勧めします。

正式リリースの最初のお披露目は、この関西ＩＴ勉強宴会でやって欲しいなぁと期待しています。その節は是非多数のお越しをお待ちしておりますm(__)m

前回はプレゼンを４つ詰め込みましたが、今回は３つにしました。結果的には、これでも詰め込みすぎでした。相変わらず、気が付くと４時間過ぎていて、あわてて終電に駆け込むという状況でした。毎度すみません。

■下山吉洋氏　「小型コンピュータの最新動向」

基盤むき出しの小型コンピュータでもグラフィックさえ気にしなければ普通に業務に使える。しかも圧倒的に安いという報告。

Mini-ITX　＞　Nano-ITX　＞　Pico-ITX　＞　Mobile-ITX
170*170mm　　120*120mm　　　100*75mm　　　　75*45mm

小さすぎると、コネクタが特殊になるのでMini-ITXが実用的。ケース・電源・CPU付きで１～２万で購入出来る。

＜私見＞
クラウドの基盤がサーバでなくパソコン用として圧倒的に安いという事が話題になってますが、それでも１台10万円程度します。これは２万程度でさらに安くなる可能性もあります。ＦＲＥＥという本が流行りましたが、パソコンも着実にＦＲＥＥに向かっているようです。

■久保敦啓氏　「関西のオープンソース活動の現状」
（資料なし）

関西でオープンソースの活動をされている方は、東京に比べて圧倒的に少人数。京都や神戸はそれなりにやっているが特に大阪は遅れている。11月に関西オープンフォーラム(KOF)があるが、大阪ではほとんどそれが唯一のイベントかも知れない。

＜私見＞
東京で仕事をしている時に勉強会に参加するとそれなりに盛んでした。大阪が立ち遅れているとは思っていましたが、これほどとは思いませんでした。
当勉強会もＫＯＦに参加して少しでも盛り上げる事を決めました。

■佐野初夫「運用を考慮した設計（略すな危険）」

前回は、運用を考慮した設計の概要をお話ししましたので、「システム境界外の考慮」について実例と考え方をお話ししました。将来は、運用レビューチェックシートなどに整理出来ないかと思ってますが、まだまだ先だと思います。

プレゼンの後、皆さんにお話を伺っていると、この考えは運用だけに閉じた話ではないのに気づきました。ちょっとした事ですが、システム境界までしか考慮せず不幸になっているシステムは多いです。

次回はＫＯＦの11月6日としました。

今回は、KOFの中で渡辺さんにXEAD Driverのセミナーをしていただきました。前座で佐野も15分だけ話をさせていただきました。

■佐野初夫　「前座」

いきなりXEAD Driverの話をしても「DOAって何？」という方が多いだろうと考えました。システム設計の歴史の話からオープンシステムの波で文化が途切れたためDOAをはじめとするノウハウが継承出来ていないという事をお話ししました。

後の飲み会で若い方とお話ましたが、やはりDOAという言葉を知らない方が多かったです。

■渡辺幸三氏　「刮目せよ！モデリング技術がもたらすオープンソース業務システム」

音楽をコンピュータで演奏するソフト（シーケンサー）の話から自動実行ツールの必然性を解き明かされました。

「沖縄民謡の「満月の夜」をコンピュータに演奏させたい」という要望があったとき、その曲だけの個別プログラムを作る人はいない。別の曲を演奏させたい時にまた最初からプログラムする事になるから。業務システム開発は何の疑問もなくこれをやっている。

本来は次のステップであるべき
Step1:業務システムの「シーケンス化」を検討する　　　　→DOA＋α
Step2:シーケンスを動かすもの（シーケンサ）を開発する　→XEED Driver
Step3:販売管理システムのシーケンスを作成する
Step4:実行する

＜私見＞
立ち見が出るほどの盛況でした。流石に渡辺氏の名前は通っているのだと感心しました。項目に色をつけたり、特殊なエラーチェックを行ったりする個別ロジックはJavaScriptで書くのですが、わざと一番長いスクリプトを画面にだして解説されることで、プリグラミング好きの若者にも興味をもってもらえていたようです。

宴会は、久保氏が主催されている、PeaceFrameworkと合同でさせてもらったため、いつもより２倍以上の人数でした。２次会を本町で行い、結局タクシー帰りでした。

今回は、忘年会という事もあり、発表は２つに絞りました。それでも結局二人で２時間もプレゼンしてました。４人でも３人でも２人でも結局は２時間程度になってしまうのは何か体内時計があるのかも知れません。

■佐野初夫　「基幹業務としてのクラウド」

ずっとクラウド関係のニュースを追いかけてましたので、それの集大成のつもりで資料を作りました。簡単にしか説明しませんでしたが質疑応答含め一時間ほど話しました。久保さんからOPENSKIPの主体はTISだという指摘をもらいましたので、アップした資料では訂正しました。指摘ありがとうございました。

SALESEFORCEがAmazonの基盤で動いているシステム（Heroku)までFORCE.COM2と呼んで仲間として扱っています。私の推測では将来はDatabase.comがすべてのフロントエンドを束ねる事になるのだと思っています。

GoogleのPOSTINI Serviceについてあまり知られていないと考えて少し詳しく説明しました。インターネットと今あるメールサーバの間のルーティングにGoogleを入れるだけで
・アンチスパム、アンチウィルス、キーワードでのフィルタリング
・メールアーカイブ
が行えるサービスです。一人年間3000円で１年間メールを預かってもらえます。10年だと5,000円／年・人になります。容量は無制限です。1000人規模の会社でも年間500万円、３年リースで1500万円ですから大変安いです。

■下山洋吉氏　「オープンソース　Openbravo　POS」

自分の環境で実際に動かして見せてくれました。画面は日本語対応が出来ていますが、レシートプリンターの漢字が出なかったようです。恐らくShift-JISへの変換が必要なのでしょう。オーダリング用としてiPADも使えると書いてあるのですが、PDA環境は上手くログインが出来ないという事でプチデバッグ大会になりました(笑)

ついでという事でもありませんが、XEED DriverをPostgreSQLで動かす手順を説明してくれました。細かい手順は下山氏のブログに書かれています。
http://d.hatena.ne.jp/kurokouji39/
ちゃんとXEED Driverのサンプル販売管理がPostgreSQLで動いているのを見せてもらいました。

＜私見＞
POSだけでなくERPまでオープンソースで出ています。画面の見やすさにこだわる日本人にどこまで受け入れられるかがポイントでしょう。使えないわけではありませんが、下山さんが一人でAccessで作られたPOS画面と較べると見劣りがします。

その後飲み会では、話があっち行ったりこっち行ったりと忘年会らしくなりました。紅白でハヤブサの話題が出るか楽しみです。ただ、気が付くと５時間も経ってましたので、あわてて帰宅しました。

今回は、新年会という事なのか、13名に来ていただきました。ありがとうございました。発表は２つに絞りました。

毎回、気付くと終電ギリギリになってます。いい加減学習しないといけないと思い、３時間で飲み物もラストオーダにして声をかけてもらうようにお店にお願いしました。そのおかげで23時前には店を出る事が出来ました。

■野村昌由氏「Google Apps Script概説」

Googleドキュメントのスプレッドシートに張り付ける事が出来るスクリプトの説明です。ボタンで起動したり、特定の数値が入った時に自動起動したりする使い方が基本ですが、時間間隔を指定してバッチ処理的な使い方も出来ます。ワークフローのサンプルもあるそうです。

まだ日本語の情報が限られているため日本ではこれから流行するのでしょう。私の個人的な印象としては、GoogleAppEngineで作った業務に対する管理作業的な役割に使うのが良いと感じました。エンドユーザに使ってもらうのはつらそうです。

■塚田英一郎氏「テスト駆動開発の実際」

高橋メソッドでプレゼンをされましたので資料としては見易いと言えませんのでご注意ください。

大変面白いプレゼンテーションでした！ネタの要素が満載なのでそのまま100%信用するかどうかは各個人の判断ですが、私はテスト駆動開発（TDD)が今まで以上に理解出来ました。やってみたいとも思いました。

TDDはテスト作成を「設計」として行う開発手法です。

Red→Green→Refactoringの３拍子のリズムという事が良く書いてありますが、実際にやると４拍子のリズムになるそうです。「最初にテストを書いてコンパイルを通す」という事をしないとRedにすら到達しないというのは考えれば当然です。しかもテストを書くという事が簡単なように思えて大変難しい。テストを書くという事自体がTDDでは「実は設計」だからです。本で勉強した時には、ホワイトボックスの単体テストだと軽く考えていましたが「テストを実装の都合に合わせない」という指摘は深みがありました。

「TDDの暗黒面」も笑ってしまいましたが、ここ数カ月実地で苦労されてきた塚田さんだからこそ感じた事を素直に表現されていました。まだプロジェクト途中にもかかわらず発表していただいてありがとうございました。是非プロジェクトが完成した時に実践報告をお願いします。

＜私見＞

昔、マーキュリーインターラクティブという会社（2006年にHPが買収）の「Mercury QuickTest」を試験試用した事がありました。これは、スクリプトで画面入力を書いて自動テストするものです。しかもデータベースもテスト前データとテスト後データを保存しておき自動で全項目チェックしてくれます。なんかすごいっしょ(笑)　考えればわかりますが、テストスクリプトを書くのがどれほど大変か。でも作ってしまえば、夜間に走らせるだけでデグレードしていないかを確認出来ます。パッケージを作って頻繁に機能追加するような物にしか使えないと思いました。

QuickTestを使う時には結合テスト前に大きな工数をかけてテスト環境を作成する事になります。これがコーディング前に終わってるなら異次元のシステム品質になる可能性を秘めています。資料にはありませんが、テストのコツとしてデータベース更新などは全てスタブを作ってダミーにするそうです。この辺りのさじ加減がセンスなのでしょう。

TDDで開発をすれば、プログラムの改善が怖くないという事が最大のメリットです。クラス名やメソッド名すら次々に変更する師匠の後姿を見ながら「どこまで行くのですか！」と追いかけられている姿を想像してしまいました。失礼

今回は、プログラマーの思索のあきぴーさんに来ていただき発表して頂きました。ありがとうございました。

いつものお店が使えなかったので急遽新日本ニーズさんの会議室をお借りました。本当にありがとうございました。

１Ｆの宇奈甲さんにビールサーバを借り、コストコでお菓子を買い込んで紙の皿を並べていると小学校の時の茶話会の準備をしているようです。初の試みでしたが、お店より声が通りやすいので全員の議論もやりやすく好評だったようです。居酒屋でバイト経験がある方がいらっしゃってビールの注ぎ方も完璧でした(笑)

お借りしているだけですので、最後の戸締りが出来ません。ビールサーバは22時前に返して焼酎に切り替えて、ふと気が付くと23時になってました。あわてて撤収してまだ残業している方に鍵をお返ししました。これに懲りずまた貸してくださいｍ（＿＿）ｍ

■佐野初夫「『ビジネスソフト』の選び方、作り方」

春日井市で話した資料ですが、プロ相手ですから多少過激にお話しました。
＜ソフト会社を選ぶ＞
業務モデル（データモデルでなくても良い）を納品物に指定しましょう
→画面・帳票でしか業務が語れないＳＥではまともな設計は出来ない
難しければ、選定の支援をする管理会社を先に選びましょう
→管理と施工の分離。それぞれの会社に取引関係がないことが条件
＜ビジネスソフトを選ぶ＞
販売管理と生産管理でどういう点を見れば良いかを例示しました。

春日井市の時にはビジネスソフトを選ぶはほとんど話しませんでしたが、今回は後半中心にしました。一項目ずつ何故そう考えるかをお話し、議論できた事は大変有意義でした。

最後の「テーブルオーナーの意識」は項目だけではわからないので少し説明します。１つの項目が複数の「サブシステム」に属するような設計は、サブシステムの切り方を間違っているためインターフェースがグチャグチャになっている可能性が高いという話です。詳しくは渡辺幸三さんの「上流工程入門」を読んで欲しいのですが、これは言葉で言うほど簡単ではありません。渡辺さん自身「しばらく経って見直すと、サブシステムの切り方を変えたくなる事がある」と仰ってました。

■小川明彦氏「チケット駆動開発(TiDD)の概要」

アジャイル開発の進め方として、日本で開発された方法です。というかチケット駆動で開発していると気が付くとアジャイル開発になっていたそうです。

前提知識として、BTS(バグトラッキングシステム）とITS(イシュートラッキングシステム）があります。BTSはご存じの方が多いと思いますが、バグを登録してその進捗をトレースする仕掛けです。ITSは私は知らなかったのですが、利用者が求めている機能要求をイシューととらえてその進捗を管理する仕掛けのようです（誤解してるかも。すみません）。

ITSは計画された項目ですが、BTSは突発的に発生します。それらを統一した「チケット」として管理するというのがTiDDのポイントです。それをやろうとするとソースの構成管理が難しくなります。

Ver1をリリースした後Ver2をITSで管理している中で、バグ対応としてVer1.1をリリースしたとします。Ver1.1の修正がVer2に正しく入ってないないとデグレードになります。
それをtrunk(幹)とbranch(枝)として管理します。

「チケットなしでソース修正はしない」
（「Ticket First」「No Ticket, No Commit !」）

という考え方がTiDDの基本です。そのためには、サブバージョンのような甘いソース管理ではなくちゃんと差分を管理してコミット出来るツールが必要です。

（私見）
アジャイルもTiDDも、フレームワークなりデザインパターンを全員が認知出来ている世界でなら有効だと思います。全員とは言わなくても半分以上が賢い人ばかりのチームなら使えるのかなと思いました。ほぼ全員が初めてのフレームワークなら難しいでしょう。

例えば、MVCの開発で、ViewがJSP、ControlがStruts、ModelがPL/SQLで作るとします。ひとつの画面なりイシューなりを一人で開発するならTiDDで管理出来ます。スキルセットが違うため普通は３名ばらばらで開発することになります。その時彼または彼女はチケット単位でなく数多くのモジュールを順に開発することになるでしょう。そういう体制では使いにくいと感じました。

TiDDに触発されて、EDDという言葉が出来ました。「言い訳駆動開発（Excuse Driven Development)」。結構使える概念かも知れません。そのうちまとめて発表しようか(笑)

２次会で、データモデルの在庫について議論しました。在庫分科会（？）。出荷時の加工についての原価をどう扱うか、返品の時どう見るかという話です。知らない事がたくさんあり勉強になりました。結論は「結局合わないから月次で合わすしかない」でした。チャンチャン。

今回は、中国のIT技術者を３名お迎えして開催しました。先月に続いて新日本ニーズさんの会議室をお借りました。本当にありがとうございました。

■佐野初夫「プロジェクト内コミュニケーションの新しい形」

岡田斗司夫さんが、「欲求のあり方で人間を４タイプに分ける」という本を出されました。
人生の法則「欲求の4タイプ」で分かるあなたと他人

昨年夏ごろ、オタキングexのページでこの考えを知りＳＥのコミュニケーション力向上に使えると考ました。ようやく先月書籍として発売されましたので、岡田斗司夫さんに使用の許可を得てプロジェクト管理にどう生かすかを考えました。

この４タイプだけではコミュニケーションの話になりませんから、田村洋一氏の「なぜあの人だと話がまとまるのか? 」にある味方チャートを合わせながら資料を作りました。
なぜあの人だと話がまとまるのか? (アスカビジネス)

時間的制約から、コミュニケーションの基本と４タイプの話（次の１・２・４）だけで精一杯でした。初級ＳＥ～中級ＳＥの方には少しは参考になる事がお伝え出来たのではないかと思います。

コミュニケーション戦術－交渉に勝つための６ステップ

１．人間関係を築く

２．キーＭＡＮを見抜く

３．味方チャートにマッピングする

４．４タイプを見抜く

５．対角線の法則を意識して反論を整理する

（１）論理的な反論

（２）心理的な反論

６．応酬話法を駆使しクロージング話法に持ち込む

プレゼンの目的は「コミュニケーション戦術」を理解してもらう事でしたが、恐らく４時間くらいかけないと皆さんが腑に落ちる話は出来ないと感じました。将来はもう少し演習を含めたカリキュラムになるはずですし、４タイプ判断の質問もプロジェクトの中のシチュエーションにする必要があるでしょう。

これからも資料をシェープアップしていきます。

■杉本啓氏「IFRSの導入で会計と業務の関係が変わる！」

会計の世界では、IFRSという新しい会計基準（ルール）が採用されるという事で、上場企業の方は検討を開始されている事と思います。

IFRSとは何かという表面的な事から、そもそも複式簿記の発生目的と歴史的変遷を解説されました。そして今まで（私は）聞いた事のない結論を導かれます。

１．米国と日本は細則主義を取っている。それは細かい規則を条文で定義する方法
２．ところが会計が複雑化したため裏をかく手順を防げなくなった
３．エンロン事件の反省から米国はIFRSに移行する事はほぼ間違いない
４．という事は遅かれ早かれ日本でも導入される
５．IFRSは収益/費用アプローチでなく資産/負債アプローチになる。
６．それは（帳簿記録と資産評価を切り離すという意味で）ビランチオ（実地棚卸）への先祖がえりに見える。
７．今後も、会計報告はますます複雑化していく
８．接ぎ穂アプローチを断念して、取引記録と会計報告を別個の仕事として、しくみを再考すべき時ではないか。

IFRSが要求する説明責任を経理処理だけで満たすことは不可能に近いほど大変になります。そういう仕掛け・仕組みを業務システム（取引記録）側で用意すべきではないかという主張でした。コンサルタントや公認会計士はラインの業務がわからないためこういう視点での指摘が出来ません。

＜所感＞
様々な具体例を教えてもらえたので佐野自身は納得しました。ただ、現在大会社で主流になっている管理会計や部門会計という仕掛けは、人事評価にも直結しています。予算管理と利益管理を部門で行うためには、「取引記録」だけでは足りない事は明らかです。取引記録と会計報告との中間として部門実績というものを仮置きする必要があると思いました。

原価について考えてみます。会計報告の中で使う「原価」は実績原価になります。部門実績は恐らく予定原価で管理すべきでしょう。ただIFRSの説明責任を考えると予定原価と実績原価の差異の統計情報を業務システム側で持っておく必要があるのでしょう。この辺りは今までとは違う帳簿組織を考える必要があるという事ですから、DOAにとっても新たなチャレンジかも知れません。

関西IT勉強宴会の紹介記事が「情報処理」学会誌４・５合併号に載りました。「全国技術系勉強会マップ」の一つです。

twitterで、たまたま募集を見て応募した事がきっかけです。全国には色々な勉強会がありますが、上流工程の勉強会はほとんどないという事でしたので、それを強調した案内にしました。マップを見ると東京は１７個も開催されているのに、大阪は、「近畿」とくくってもたった２つだけという寂しさです。偶然とはいえ載せてもらえてよかったです。ぜひ大阪でも多く開催して欲しいです。

東京で開催されている「決定不能の会」は笑いました。世の中の決定不能な問題が決定不能である理由を納得する事が目的だそうです。恐いもの見たさで言ってみたいかも(笑)

勉強会を始めたきっかけについて書きましたので、その部分についてテキストで載せます。

データ指向設計（DOA）をベースとした業務システムデザインの意義を共有することを目的に始めた勉強会です。９０年代後半にオープンシステムの波が来たとき、35歳～40歳の技術者は新しい技術をキャッチアップする事に必死でした。先輩から学んだ技術－業務設計・品質保証・運用設計等を後続に伝えるべき世代でありながら、その余裕がなかった。そのため、システム設計スキルに関して世代間ギャップが生じており、これを埋めることができればと望んでいます。
たとえば、DOAは米国由来の古い手法だと誤解されていませんか？いえいえ、DOAは日本人が作った、企業の基幹システム向けに最適化された分析設計手法です。基幹業務等の複雑な事務処理を見直そうとする際に、こういった理論を知らないままでは正しいあり方にたどり着けません。データを記録するための帳簿組織を正しく設計し、個々の業務とその連携を正しく設計し、さらに膨大なデータ処理機能を正しく設計しなければならないからです。
とはいえ、DOAは本を読んだだけではなかなか理解出来ません。この理論は関数従属性といった数学的枠組みを基礎として体系化されています。10人が設計すると10種類の違うものが出来る方法論が多い中、同じものが出来る事を目的として、表記法なども（方言はありながらも）厳格に定まっています。それだけに、独学が難しいという難点があります。
東京ならデータ総研（株）のセミナーや佐藤正美氏のオープン講座など情報を得る手段はありますが、関西ではこれまでそのような機会がほとんどありませんでした。名著「上流工程入門」の著作者　渡辺幸三氏を中心として、計数管理パッケージFusionPlaceの杉本啓氏、オープンソースMakeGoodの久保敦啓氏の３名がほぼ毎回参加してくれています。業務設計の面白さに触れてみませんか？

私がやっている関西IT勉強宴会は毎回テーマが大きく変わります。興味のある話題があれば是非一歩を踏み出して参加して下さい。

ついに、2011.04.11　XEAD Driverの正式版が公開されました。それを記念して

【渡辺さんに目の前でシステムを作ってもらっちゃおう！】

というちょっと無茶な企画を行いました。初めて参加して頂いた４名を含む16名にお越しいただきました。本当にありがとうございました。

渡辺氏が無料で公開されている販売管理のCONCEPTWARE（コンセプトウェア）をMicrosoftのAzureというクラウドで実装された方がわざわざ東京から来てくださいました。

■司会　佐野初夫

まずはXEADが前提とする三要素分析法という渡辺幸三氏の設計手法について簡単に15分ほどで説明しました。その後、どういうシステムを作って欲しいかを聞いていきました。

多少無理やりではありましたが、５つほど挙がったなかで、２つに絞って多数決で決めました。

１．手配師支援システム
土建業、アルバイトやコンパニオンまで、人を手配するという業務を支援するシステム

２．燃焼時間判定システム
建物が万一火災になった時に何時間程度で燃えてしまうかを計算するシステム
今はやりの（？）原発関連で必要なロジックだそうです

たった１票の僅差でしたが、手配師支援システムになりました

■システム設計　渡辺幸三氏

提案者も具体的な業務イメージがあるわけではないという事がわかってしまったので(笑)、参加者みんなで合意形成しながら検討を行いました。

１．業務フロー
「三要素」の中には業務フローは入っていません。なぜなら設計対象のシステム境界を決めるために業務フローがあるためです。今から設計する対象を決めるフェーズになります。

渡辺氏の著作では、DFD（DataFlowDiagram）と呼ばれていますがIBMなどが今でも使っている表記法とは大きく異なります。従来のDFDは階層化を行い最終的に入力と出力が１本になるまで詳細化を行います。三要素分析法はあくまでシステム境界を明確にするためですので、最上位の段階しかつくりません。また、イベントが発生するタイミングを表す事が出来るのも特徴です。

参加者と会話しながら、徐々に形になっていく手法は流石でした。顧客からの引き合いがあった後、手配する「人」を探すのですが、その探すための条件（属性）がシステムの肝になることが徐々にわかってきました。

時間の関係もあるので、作業者の属性周りに絞ってデータモデルを作る事になりました

２．データモデル
いよいよ設計です。ホワイトボードのコピーは何度も書き直した後の姿です。三要素分析法のデータモデルは、ジェームズマーチンが発案したIE手法を元にして、データ項目を横に並べる事が特徴です。ホワイトボードの写真をみてもらうと、項目の下に実際のデータサンプルがずらずらと書かれている事がわかると思います。これがデータ項目を横に並べた効果の一つです。

アタマが良い人は項目名という抽象的なもので理解出来るのでしょうが、大多数の方（特にお客様）にとっては具体的なサンプルがないと理解出来ないでしょう。三要素分析法以外の方法論で実データを２件以上記入出来る形式はありません。

本来なら、XEAD Modelerを使って三要素の残りの「業務モデル」と「機能モデル」を設計するのですが、時間の関係で省略します。XEAD Driverでテーブル定義を行います。プロジェクターに映しながら画面設計をされました。

３．XEAD Driver
（１）テーブル定義
フィールドＩＤとフィールド名を入力すると、あとはデータタイプとキーの指定程度で終わりです。
今回は、次の３テーブルだけを定義されました。
キー　　　　　　　　　　用途
・作業者　　　　　作業者Ｎｏ　　　　　　　氏名・住所など
・作業者属性　　作業者Ｎｏ＋属性ＩＤ　　強度（属性のレベル）
・属性　　　　　　　属性ＩＤ　　　　　　　　　男女やＥＸＣＥＬが出来るなどと、強度の範囲

作業者属性テーブルの「強度」は拡張データタイプに「区分ＩＤ」を指定し、区分として「KBKYOUDO」と指定されました。同時にシステム管理の「ZT040　ユーザ定義区分」のデータタブから、区分値としてA、B、Cの３レコードを登録されました。こう定義すると、画面の入力の時自動的にダイヤログボックスで選択できるようになります。

（２）機能定義
いよいよ画面の定義です。といっても、IDと一時テーブルを指定するだけです。

・作業者
・作業者属性　・・・作業者の明細から登録するようになっています
・属性

それぞれ、「一覧」と「保守」の２機能ありますので、６機能（６画面）が出来上がりました。

４．その他

開発秘話のような事をお話頂きました。結合テーブルの処理はデータベースに任さずXEADが自前でやっています。DBMSでは管理出来ないような複雑な結合も許されています。複雑に結合されたテーブルであっても、削除処理のチェック（参照されているレコードは削除できない）は行っています。そのため、XEAD Driverの削除ロジックは相当複雑な処理を行っているそうです。オープンソースですから、興味のある方はGitHubからダウンロードして参照してみて下さい。

＜資料について＞

今回渡辺氏に作ってもらったXEAFファイルとこのブログで使った画像をZIPにまとめてアップしました。内容をご覧になるときには、ファイルパス名が日本語だとデータベースアクセスが上手く機能しませんのでご注意ください。これはDerbyDBの制限です。

https://sites.google.com/a/onas.asia/top01/home/kwansaiit/doc

＜所感＞

プロトタイプやアジャイルのツールとしてオープンソースとは思えないほど実用的なツールだと思います。是非本番処理で使ってみたいと思いました。

楽々フレームワークの作成者やXEADをAzureで実装された方など技術力の高い方が参加して下さったため、興味深い議論が色々ありました。例によって飲みすぎたためあまり覚えていないのですが例えばこんな内容でした。

ある項目の値が「９９」なら画面に赤色で表示するという処理をXEADでは「テーブル項目の定義」に書きます。「ZT051 セッション明細」テーブルのスクリプトを見るとこう書いてあります。

if (ZT051_KBPROGRAMSTATUS.value == '99') {

ZT051_KBPROGRAMSTATUS.color = 'red';

}　　　→プログラムステータスの値が99なら赤色にせよ

これは本来ユーザインターフェースだから機能定義に書くべきではないかという指摘がありました。レイヤーが違うのではないかという指摘です。

一見もっともな指摘のように思えますが、この辺りがDOAのDOAたる所以だと思います。正しくDOAで設計するという事は、項目のプロパティ（性質）は出来る限りテーブルとして定義するという事だというXEADの主張です。項目自体が「99なら赤」という性質を持っているわけですから、どんな画面でも赤色で出す事になります。

とは言え、スクリプトのif分で機能IDを指定すると特定の画面だけ赤くすることも出来ますから、ツールとしての融通性も備えています。

初参加の５名を含め１３名にお越しいただきました。名古屋から３名、東京から１名来られていました。本当にありがとうございました。

今回初めて生ビールを用意せずに開催しました。「勉強宴会」でなく単なる「勉強会」になり下がってしまいましたが、生ビールを用意しないだけでどれだけ主催者が楽かがわかりました。また、時間をキープしようという理性が最後まで残る事もわかりました。そりゃそうか(笑)
予定通りガッツリ３時間で終わりました。

飲み会には体調不良の方１名を除いて全員来てもらえました。楽しかったですね～

ある方に、「今回参加出来ないのでレポートお願いします」と言われたのですが「今回は半分も伝わらないかも知れません」と答えました。事前に資料は見せてもらっていましたから、今まで当たり前と思っていた事が実は間違っているという話になる事は分かっていました。しかもどの本にも書かれていない内容ですから「詳しくはこの本を」と振る事も出来ません。

今回参加して頂いた方が参加後twitterでこうつぶやかれていました。
>昨晩は大阪の関西IT勉強会へ。素晴らしい場でかなり感激。
>公認会計士の杉本さんの簿記の原理の話、と書くと固そうだが、ピュアな
>原理の話は脳内がかき混ぜられるくらい刺激的。
>今までの自分の会計の理解は何だったのか・・・と再コンパイル中。

大変嬉しいコメントです。毎回同じくらい刺激的な内容ですので過去のレポートも読んで下さいね。今回のこのレポートは佐野が理解したと「思い込んだ」内容です。参加されていない方がわかりやすいように前後を入れ替えたり用語を変えたりしていますのでご了承下さい。間違っている時には教えて下さるとありがたいです。こっそり修正します(笑)

＜資料＞
Kansai-IT-Benkyo-Enkai_2011-06-03_Sugimoto.pdf
杉本さんの資料です。回答シートは入っていません。
Kansai-IT-Benkyo-Enkai_2011-06-03_Sugimoto_Scanned_Document.zip
JPEGファイルP1～P6の6ファイルを圧縮しました。
回転寿司のくら寿司のBS/PL/CFに杉本さんのコメントを入れたものです。
kansai-IT-Benkyo-Enkai_2011-06-03-Sano.pdf
佐野の資料です。

■ＳＥに必要な帳簿知識入門＜前半＞　杉本啓氏

１．会計・簿記・業務の関係

ほとんどの簿記の本（テキスト）は、次の４つの要素が混在して解説している。ＳＥがコンピュータシステムを設計する上で本質的な部分と枝葉を混同すると法律や社会情勢が変わるたびにプログラムを変えないといけなくなる。そのため、会計知識として勉強する時は、どの要素の話かを切り分けて勉強する事が望ましい。

会計士や税理士でもわかっていない方が多くいる。本当に理解されている方ももちろん居るが、わかっていない人が書いた本はわかりにくい。

(1) 会計報告値の計算基準（会計基準）
会計基準は法律が変わったり常識が変わると計算も変わる。勉強してもすぐ変わる。
ここは会計士などの専門家に任せるべき領域。例えば・・・

10万円で商品を売って1万ポイントを付けた。売り上げはいくらになるか？
　　・もちろん10万円
　　・1万円は値引きと同じだから9万円
実はどちらでも良い。会計基準、会社法が変わると計算も変わる。IFRSなら次の計算も考えられる。
　　・商品10万、商品券1万の合計11万円を10万円に値引きしたとみなす(10*10/11)
何が「正しい」かは言えない。という事は「目的」にしたがって会計基準を選ぶことが出来る範囲が広い。論理的に決められないならＳＥがタッチできる範囲は少ない。

情報システムが、会計基準をストレートに実装する事は危険だと考える。

(2) 取引記録のメカニズム
複式簿記の仕掛けの部分。仕訳からＢ／ＳやＰ／Ｌを作成するメカニズム
★今回の勉強会の対象。ＳＥにとって重要である帳簿組織に関わる部分。

(3) 取引記録の手法（仕訳の仕方）
売上の仕訳について、分記法、総記法、三分法などのルールの知識。決め事ではあるが理解しておかないと基幹業務システムは設計出来ない。業務手順やタイミングにより適切な仕訳を考える必要がある。

(4) 業務の手法
売上原価の計算をする時の、継続記録法、棚卸計算法などの実業務の手法。入庫出庫を常に帳簿記載するか、入庫は取るが出庫（売上）は月末棚卸で行うかなどで基幹業務の設計が大きく変わる。商品分類別の循環棚卸を行うなら設計が変わる。

業務システムエンジニアは、上記(2)(3)(4)の知識を得る事が重要である。会計士・税理士は(1)の専門家であるが(2)～(4)はほとんど知らない。現場の担当者も自分が何をどうしているかはご存じだが、何故そうしているのか、他にどんな方法があるのか、その方法の欠点などは理解されていない方が多い。そこを埋められるＳＥになって欲しい。

２．Ｂ／Ｓ、Ｐ／Ｌ、Ｃ／Ｆとは

くら寿司の実例。一皿100円のお寿司の原価は平均して46円という事がわる。
50億も利益があったのに現預金は16億しか増えていない。その理由（内訳）がＣ／Ｆでわかる。

３．複式簿記はＢ／Ｓが基本

Ｂ／Ｓを、資産／負債／資本（純資産）に分けて考えるのは、会計基準を前提としているためであり、簿記の本質的なメカニズムではない。数年前会社法が変わり資本という用語が純資産に変更されたが業務システムにとっては何の関係もない。

例えば、下請け業者に資材を有償支給する時、「有償支給未収金」として独立資産とするのか、「買掛金」として負債から引くのかは単に会計基準の話であり基幹業務からみるとどちらでも関係ない。
簿記のメカニズムとして大切なのは、「残高を持つ財産の一覧表であること」「残高合計がゼロであること」の２点だけ。

(1) 複式簿記の基本
信用取引が出来る事が複式簿記の成立条件と言われている。ルネッサンスの時代(15世紀）に成立した。それまでは、お金の貸し借りは毎回公証人が公正証書として明文化していた。複式簿記の当初の狙いは、その債権債務の残高を管理する事だった。佐野が掛けで会社から商品を10万円で買った時、公正証書は「佐野は、会社に10万円借りた」となる。そのため複式簿記でも借方に記載する。公正証書を整理する事が起源であるため、借方・貸方という用語は常に「相手目線」で使っている。

その後産業革命で広く投資家に開示するために、会計基準が整備されていった。情報システムにとっては、トレーサビリティだけ確保出来れば、会計基準はどう変わっても対応出来るはず。

(2) Ｂ／Ｓだけでの複式簿記（ケーススタディ）
資料を見てもらえば理解出来ると思います。わかりにくい②と④だけ解説します。
②２月１日　旅費２０を、Ａ銀行口座から支払う

　　　　借方　　　　　　　　　　　貸方
　　資本主　　　　　２０　｜Ａ銀行口座　　－２０

銀行口座から支払ったという事は資本主から預かっていた資本を使ったという事になる。
この瞬間に会社を清算する事を考えると資本主の費用から引く事が理解しやすい

④８月１日　（5/1に300で仕入れた）パソコン10台ともＣ社に500で掛売り

　　　　借方　　　　　　　　　　　貸方
　　Ｃ社　　　　　　　５００　｜5/1仕入PC　　　　　５００

擬人化して考える。5/1にPCを300で仕入れた担当者は、会社に300の「借り」があった。それが売れたため会社に500の「貸し」を作ったという意味。相殺すると200の貸しになる。

(3) 総記法
簿記が発明されて、初期の実務は総記法だった。総記法は「ひとつの勘定に売上も仕入も記入」する。そんな事をすると残高の意味がわからなくなると初学者は思うだろう。実は当時の商品勘定は、今のように全商品を対象とした集約的なものではなく「荷口別勘定」だった。そのため特定の荷口別商品に関する全取引がひとつの勘定に記入される。一覧性が良いばかりでなく、売れ残り商品や採算の判断も出来たと思われる。

　　　借方　　　　　　　　　　　　　　　　　　　　　貸方
　----------------------------------------------------------------------
　　5/1　Ｂ社から掛けでPC仕入　10台　300　｜8/1　Ｃ社に50で掛売　500
　　8/1　販売益を資本主勘定に帰す　　200　｜

Ｂ／ＳだとかＰ／Ｌだとかが後づけで考え出されたという事を理解しないと、連結会計は理解しにくい。

■ＳＥに必要な帳簿知識入門　佐野初夫

ちょっと息抜きという意味で従来型の帳簿組織のお話をしました。

まずは、CONCEPTWARE/販売管理のデータモデルから在庫テーブルの中に「移動平均単価」を持っている事を示し、数量と金額の関連をお話しました。次に試算表の構造を示しながら、Ｂ／ＳとＰ／Ｌの当期利益が何故必ず等しくなるのかを示しました。

従来型の会計基準に毒されたオールドタイプ(笑)の話でしたので理解しやすかったと思います。

■ＳＥに必要な帳簿知識入門＜後半＞　杉本啓氏

４．利益はどこから　～　Ｐ／Ｌ

Ｂ／Ｓだけで複式簿記を付ける時は、費用も利益も「資本主」勘定に入れる。残高を計算する事で利益はわかるが、その利益がどこから来たのかは分かりにくい。

そのため、資本主勘定が増減する都度、その内訳を表す「区分」を付ける事にする。それを集計したものがＰ／Ｌである。これは総記法（というか荷口別勘定）を理解出来ていれば、資料を見るだけで理解出来るので説明は省略します。

５．勘定合って銭足らず　～　Ｃ／Ｆ

Ｃ／Ｆの表示方法には会計基準から２つのアプローチがある。直説法と間接法である。直説法はキャッシュの出入りを直接要因別に表示する。間接法は、利益とキャッシュフローの差額を要因別に表示する。実務では間接法が一般的だがＩＦＲＳでは直説法が一般的になるかも知れない。

Ｃ／Ｆの作成方法にも直説法と間接法がある。直接法は、キャッシュ勘定の代わりに「仕入代金」などの「Ｃ／Ｆ勘定」を用いる事で増減を要因別に直接分ける。間接法はキャッシュ以外のＢ／Ｓ勘定の代わりに増減要因を表す勘定を用いる。
※間接作成法の実務では、仕訳とは別のデータソースから作る事が一般的だが、原理は同じ

この「表示方法」と「作成方法」を混同して解説している事が多い
直接作成法で作成して直接表示法で表現する、または間接作成法で作成して間接表示法で表現する事が一般的。だが、間接作成法で作成して直接表示法で表現する事が可能という事が見落とされがち。
表示方法は会計基準のマターだが、作成方法の選択はＳＥの設計に密接に関係する。

資料のケーススタディは是非やってみて下さい。資料を読めばやり方はわかりますが、考え方は難しいです。

６．Ｂ／Ｓ、Ｐ／Ｌ、Ｃ／Ｆの関係再訪

複式簿記の基本は、Ｂ／Ｓである。
Ｐ／Ｌへの拡張は、「資本主勘定の詳細化」であり、
Ｃ／Ｆへの拡張は「キャッシュ勘定の詳細化」でしかない。

Ｐ／Ｌの作成方法に、損益法と財産法がある。損益法は、一定の会計期間の収益から費用を差し引く事で利益を求める方法。財産法は期末資本から期首資本を差し引くことで利益を計算する方法。Ｃ／Ｆの直接作成法／間接作成法と似た関係になっている。
損益法の利益　＝　収益　－　費用
財産法の利益　＝　期末資本　－　期首資本

Ｐ／ＬとＣ／Ｆは似ているのにもかかわらず、Ｐ／Ｌは帳簿から作成出来るのに較べてＣ／Ｆは帳簿データだけでは作成できない。それは恐らくＣ／Ｆは比較的最近のニーズなのでＣ／Ｆ作成に向いた情報システムが出てきていないためなのではないか。

もっと詳しく知りたい方は、「企業会計」に掲載された杉本さんの論文およびＣ／Ｆの作成方法を詳しく書かれたブログをご覧ください。

＜所感＞
現在のＩＴ技術の発達を前提とした時の新しい「情報システム」および「業務の仕組み」はどうあるべきか？どういう方向性になるのか？

講師の杉本さんは恐らく、それをこそ議論されたいのだろうと思います。今回は我々の知識ベースを合わせるための説明でした。キーワードは「残高項目」と「増減要因」と「時系列」です。この３軸ですべての取引明細を持てば、増減明細を他のデータソースから持ってくる必要はないはずです。

ところが実業務を考えるとそう簡単ではありません。

勉強宴会で例に出た話ですが、「機械を100で買った」という仕訳で

　　機械（借方）　　　100　｜未払金（貸方）　100

と書ける会社はほとんどないでしょう。恐らく仮勘定がクッションになります。

　　仮勘定（借方）　　100　｜未払金（貸方）　100
　　機械（借方）　　　100　｜仮勘定（貸方）　100

理由は３つあります。
1) 起票するタイミングが違う
売上伝票（この会社の仕入伝票）が来た時に購入は計上しますが、固定資産に計上するのは設置した時になるでしょう。

2) 担当部署が違う
発注担当者（購買担当者）と設備担当者がそれぞれのプロセスに従って起票する事になります。

3) 購入した時点では顛末がわからない
もしかすると、その機械を自社で使わないで顧客に販売するかも知れません。その時には商品勘定に計上する事になります。

全ての取引は、過去の取引と有機的につながっています。それを全て情報システムでとらえて関係づける事は不可能です。もし、人間の動きを全てコンピュータの情報としてとらえられたとしてもそれだけでは情報が足らないためです。

どう設計し実装するかは今後の課題です。今後の設計のための一つの有用な方向性を教えて頂けました。ありがとうございました。

初参加の４名を含め１２名にお越しいただきました。名古屋から２名も来られていました。本当にありがとうございます。「名古屋嬢」というお土産も頂きました。食べきれなかった分を数個持って帰り、かじりながらこれを書きました。

今回は講師の渡辺さんの計らいで22:15には講義は終わりましたが、そこから下山さんのXEAD勉強会などが始まり、飲み会なのか勉強会なのかわからない状態で2:30までやっていました。２次会のお金がかからなかったのは、フリーターにはありがたい話ですが、ちょっと申し訳ない気分です。

DOAの基本をおさらいしようの会

講師の渡辺幸三さんがレジュメを配布して下さいましたのでその順に報告します。ただ、今回はプロジェクターを使わずホワイトボードだけで説明されたので全部は報告し切れませんのでご了承ください。

１．正規化

正規化とは、正しい場所に置こうという事。意義（目的）は、「データ項目を形式的に理解する」事。データ項目自体の意味から離れ、データ項目を記号にして考える。

※DOAの抽象化について意味から離れて形式的に把握する事に疑問の声がありました。確かにもっともな疑問です。この事が原因でDOAに興味をもってもらえない事があると再認識しました。

(1)入れ子構造の排除
(2)関数従属性
y=f(x)の関数は、xの値が決まるとyの値が決まるため「yはxに従属している」という。
例：、y=f(x) = 2x +3
などの関数もテーブルに出来るがこういう「ルール」や「計算式」はテーブルにする意味がほどんどない。テーブルにするのは、計算出来ない「事実」であることが多い
例：y=f(x)=私がｘ歳の時に好きだった子の氏名(y)
y=f(x,z)=私がx歳の頃zさんをどれだけ好きだったか
(3)ドメイン制約（定義域）
主キーの範囲を制限するためのテーブル。属性を持たないので見つけにくい。
正しくモデリング出来たと思っていても、ドメイン制約が抜けている場合がある。これを防ぐには全てのキーを順列組合せでチェックする。

テーブルＡＢとテーブルＡＢＤＥが親子関係である事がわかりモデリングした。

だが、よく検討するとＡＢＣというドメイン制約がある事がわかった。

プログラムのif文で書くならこういうテーブルは要らないが制約が隠蔽されるため良くない。業務データの「構造」を出来る限りデータとして表すべき。

２．テーブル関連

(1)３つの位相
親子・参照・派生という３つの位相（トポロジー）で全ての関連を表す。
同じトポロジーであれば、業務が違っても同じ構造であるから動きも同じになる。一度設計で出てきたトポロジーを覚えていると、まったく違う業務でも同じように設計出来る事が多い。

業務は全然違っても、次の２つを「同じである」ととらえる事が重要

(2)多重度
上の「契約単価」を見ると、顧客１レコードに対して契約単価は商品数分だけある。これを１：Ｎの多重度（カーディナリティ）と呼ぶ。キーはテーブルのＤＮＡであり、親のＤＮＡが子供に移ると考えるとわかりやすい。
親子関係と派生関係は多重度は同じだが、性質は違う。最大の違いは、派生関係なら親を簡単に変更出来る事。（親子関係は変更出来ない）
ＤＯＡの多くの方法論ではこの２つを同じものとして扱っているので注意が必要。

(3)固有属性と導出属性、継承属性

品質レベルテーブルから、「品質レベル＋品目Ｇ」を一次キーとする品質名称テーブルを参照する。ところが品質レベルテーブルには品目Ｇは存在しない。商品テーブルからの継承属性として定義する事で参照出来るようになる。

このような継承属性は実務では良く出てくるが、ＤＯＡの教科書では見たことがない

３．上流工程

要件定義や現状分析は時間かければかけるだけ分厚い資料が出来るが、本当に役に立つのかには疑問がある。１年かけて要件定義して終わった時に要件は変わってないのでしょうか。無意味な要件定義や現状分析は手を抜いて基本設計を始めましょう。
基本設計は、創造力やコミュニケーション能力、ひらめきなどが必要なので難しい。

４．データモデルのイディオム

イディオムとは慣用句とか熟語の事です。

(1)残高と取引実績

売上・仕入・受払いの業務に良く出てくるパターン。

顧客Cをキーとして売上額（残高）を持つ。売上明細の顧客Cを外部キーとして関連付ける。
取引としてのまとまりやプロセスが違う物を１つのテーブルに入れるような設計は良くないので注意

（佐野が次の事を補足しました。ISO9001の品質保証手順では「文書」と「記録」を明確に分けます。文書は版管理して最新にします。記録は訂正できない「事実」です。記録を変更する事を改竄と呼びます。この文書と記録を１テーブルに入れていないかチェックするのもおかしな設計になっていないかを確認する一つの方法です。）

(2)バッチテーブル

レコードの発生時点では存在していない別テーブルのレコードによってグルーピングされるようなテーブルの使い方がある。
例　PJ#,行#,予定#､作業予定,日報No
→これを登録する時に日報Noはブランク（またはNULL)になる
日報#、作業内容・・・
→これを登録する時に上のレコードの日報Noに値を登録する
これにより作業予定レコードのまとまり（バッチ）が形成される

(3)再帰構造

部品表の例
品番、品名・・・
親品番、子品番、構成比・・・

＜所感＞

説明を受けながら２つの事を考えていました。

渡辺さんの一番最初の著作に「業務別データベース設計のためのデータモデリング入門」があります。この本の評価は特徴的でした。中級ＳＥ以上には高評価なのですが、初級ＳＥの方は前半（第三章）までの評価は高く後半は「理解出来ない」というものでした。これは渡辺さんが、データモデルと業務知識をコインの裏表のように一体の物としてとらえられているからだと思います。今回の勉強会も似た構造になっていました。
１の正規化は初級者向け、２のテーブル関連は中級者向け、４のイディオムは上級者向け

もう一つは、データモデルのパターンについてです。上記の本ではデータモデルを解説する事で業務知識を伝えようとされていました。今回は恐らく意識的にもっと抽象化して、色々な業務に出てくる典型的な「パターン」を説明しようとされたのかなと感じました。私自身は渡辺さんの著作は全て読んでいますから、何を説明されたいのかはわかっているつもりですが、読まれていない方には抽象的なためわかりにくいだろうなと思いました。これらは、渡辺さんが無料公開されているコンセプトウェアの基本設計の中に出てきます。販売管理や財務管理、生産管理など既に５種類の業務を公開されています。

これは、オブジェクト指向屋さんが言う「パターン」そのものです。例えばこういう切り口で整理すれば、役に立つ可能性があると思いました。
１．マスターメンテナンス業務
１－１．初級編
　１－１－１．年度替わりで、多数の商品の単価を一気に変えたい
　１－１－２．商品単価の変更を事前に登録したい
１－２．中級編
　１－２－１．組織コードの階層構造を上手く表したい
　１－２－２．同じ取引先が顧客にも仕入先にもなるときの扱い
１－３．上級編
　１－３－１．商品のサイズのパターン(S/M/L,25/26/27)を上手く管理したい
　１－３－２．再帰構造のテーブルでループしない事を保証したい

DOAをまったくご存じのない方にどこまで伝わったのか不安があります。でも「簡単ですよ。誰にでも出来ますよ」と誤魔化すよりは正直でよかったと思います。今のシステムを見直したり、より深く勉強したりするきっかけになって欲しいと祈っています。もし業務内容を部分的に公開してもらえるなら、現在の設計のダメ出しをして設計方法を一緒に考える勉強宴会を開きますのでご連絡下さい。

以上

なんだか長いタイトルになってしまいました。より進化したDOA（データ中心設計）の洗練・普及・啓蒙を推進する団体であるDOA+コンソーシアムの大阪分科会と合同開催となりました。

50名程度入る場所がみつからなかったので、DOA+の登録会員への案内は控えてもらいました。新しい方6名をお迎えし、総勢19名と大盛況でした。ありがとうございました。1名だけ、遅れてこられた方が玄関が閉まっていて申し訳ない事をしました。ごめんなさい。次回は必ず全員に携帯番号をお教えします。

今回は生ビール19L+10Lと、焼酎をひとびん用意しましたが、少し多かったのかも知れません。焼酎は来月開催への寄付として利用させて頂きます。最後は常連さん５名でいつもの居酒屋で３時ごろまで激論(笑)を交わして解散しました。

＜資料＞
DOA+の活動概要
Kansai-IT-Benkyo-Enkai_20110926_Sano.pdf

マスタ統合
Kansai-IT-Benkyo-Enkai_20110926_Horikoshi.pdf

全社システムのアーキテクチャー
Kansai-IT-Benkyo-Enkai_20110926_Watanabe.pdf

■DOA+コンソーシアム　オーバービュー　佐野初夫

設立当初から参加していましたので、設立の意義とWEBサイトにある３つの資料の概要をお話しました。大阪のＳＥからはアーカイブとして利用する事が現実的です。

■マスタ統合　堀越雅朗氏

「今日はDOA+でなく、データ総研の堀越としてお話します」という前置きで、データ総研のマスタ統合の概要をお話頂きました。世界的なデータ管理の組織であるＤＡＭＡとＤＭＢＯＫガイドについてもご紹介頂きました。私はもちろん知ってましたが「ディーエムボック」と心の中で呼んでました。それが「ディンボック」と発音されていたので軽くショックを受けました(笑)

基本的には資料に沿って話をされましたので、ここでは私が面白いと思ったところに絞って前後関係をあまり考えずに報告します。全体の流れは資料をご覧ください。

１．マスタ統合を行う理由

マスター統合していないと、目の前の問題として２つの弊害が発生します
(1) 経営戦略上の機会損失
・仕入先と顧客が同一かわからない（ERPの多くはこうなっている）
・グループ各社や部門から、同じ顧客にアプローチする
(2)業務上のコスト増加
・取引先の住所が変わった時など何か所ものメンテナンスが発生する
・個別アプリケーションごとに同じマスターを構築することになる

例えばＣＲＭ（顧客管理）に関して、顧客は自分が受けたサービスを全部知っていますが企業側は知らないという状態になります。電話会社は開局してから顧客番号を振りますので開局前後のやりとりが消えています。つまりマスタ統合の意味は、部分最適から全体最適へと視点を移動する事にあります。部分最適を捨てるわけではなく「全グループ的」「全社的」「全地域的」なデータ基盤整備プロジェクトとして取り組む必要があるという事です。

個々のシステムは「業務を回す」事を目的として作られます。それは当然ですが、ある期間を経ると「業務の記録としての蓄積」を考えるようになります。経営視点で言うとそれに基づいて過去を分析して将来を見通すという目的です。その時にマスタ統合が問題となります。

２．よくある解決策と真の問題点

商品をJANコードで統一する企業もありますが簡単には解決しません。例えばキャンペーンのためにおまけを付けた商品はJANコードを変えるのでしょうか。新しくJANを採番するのには数週間かかり間に合わない事があります。なによりJANの番号数は有限ですから無駄に採番する事は許されない企業がほとんどでしょう。取引先コードとして、統一取引先コードや帝国データバンク等の統一取引先コードを使うという話も良く出ますが解決にはなりません。役所や学校が入っていない、グループ企業がわからない、海外企業が入っていないなど問題は多く出てきます。

共用性の高いマスタを一元的に管理するためにＭＤＭ(Master Data Management：マスタデータ管理)という手法やツールが各種出ています。そこでは２つの実現事項を挙げています。
・「統合されたシングルビューを提供」すること
・「業務をまたがって統合管理」すること
これらに正解はありません。大人数で議論しても結論が出ずに「一番細かい粒度で」などという最悪の結論になり結局運用がついてこずに失敗するというパターンが多くあります。実は「調整ごと」でしかないという事がわかっておられないのです。

顧客や商品などの「マスターデータ」だけでなく、「リファレンスデータ」の統一も重要です。リファレンスデータとは、顧客ランクや商品分類などトランザクションに入る項目です。全社規模でトランザクションを集めても顧客ランクの意味合いがサブシステムによって違うなら使えなくなります。

２．目的と意味論

マスタ統合を調整事項だと認識すれば、議論しても結論が出ない事は当然です。議論の根底に、何のためにマスタ統合を行うかという「目的」を明確化する事が極めて重要です。特に多くのメンバが集まる席で執行役員を中心に議論して結論を出します。
「何のために、それをやらねばならないのか？」
「その目的を達成するためには、なにがどこまで必要か？（MUSTとWANTの切り分け）

また、マスタ統合で良く見られる課題として、名寄せの問題（ABC商事とエービーシー商事が同じか）とデータ粒度の問題があります。同じ顧客であっても、扱う商材によって「Ａ社」として管理すればよい部署と、「Ａ社第一営業部」まで管理が必要な部署、もっと細かく相手先担当者まで管理が必要な部署があります。全社的に見るなら、Ａ社よりももっと大きなグループ企業としてのくくりが必要かも知れません。

マスタ統合がマスタの「器をひとつにする」事だと勘違いしている企業だとこのように粒度の違うマスタが混在している事があります。結局使い物になりません。「意味的な整合性」を確保する事が重要です。そのためには、データモデルを利用して誰にでもわかる形で整理して議論しましょう。タイミングが意味を持つ項目については、業務フローで見える化することも重要です。データモデルと業務フローを合わせて整理する方法があります。

商品の仕様（スペック）について議論する時、予定スペックの話をされているのか結果スペックの話なのか曖昧なまま議論が進むことがあります。こういう時にも、項目とタイミングを見える化する事は役に立ちます。

３．方法論

データ総研には、PLAN-MASTERという国内唯一のマスタ統合のための方法論があります。
そこではまず経営層に参加してもらい目的を整理します。マスタが統合されていな現状の問題点を出してもらい、問題点連関図手法（Mind-SAの右方展開）を使ってそれを放置すればどうなるかを整理します。放置すれば会社がつぶれるという話になれば、「会社をつぶさないためにこのプロジェクトを推進しましょう」というスタンスになりやりやすくなります。

右方展開の影響に行き詰った時は、「えむあーるしー、ぶいきゅーてぃーえっちえすえふゆー」を丸暗記してアドバイスしましょう。
M:Monpower R:Resource C:Cost
V:Volume Q:Quority T:Timing H:Human S:Security F:Flexibility U:Utility

実際のコンサルティング事例を資料に載せてもらっています。勉強宴会では企業名も出ましたがここには書きません。

■全社システムのアーキテクチャー　渡辺幸三氏

堀越さんの言われた目的は大切です。それとともに全社システムのアーキテクチャを考えながらマッピングする事が重要だと考えます。それを立体的に表すために今日東急ハンズで買ってきましたのでそれを使って説明します。

※と言いながら発泡スチロールとラベルシールを取り出され笑いの中説明が続きました。面白かったのですが、残念ながら上手く説明することが出来ません。とりあえず資料を捏造して(笑)アップしました。

１．全社のアーキテクチャー構造

会計

財務　　人事給与　　　事業

←－－共通データ管理－－→

事業には、販売管理や生産管理などのバリューチェーンを含みます

２．事業のアーキテクチャー

統計

受注出荷　　在庫取引　　発注入荷　　　　★取引管理のレイアー

売掛　←－－－在庫－－－→　買掛　　　★残高管理のレイアー

←－－－－－　共通　－－－－－→

※これは途中の状態の写真です。最終形は資料に載せました

３．その他（質疑応答など）

海外では、取引管理と残高管理の違いがなくひとつで管理される。

日本の企業の標準化というと、取引管理を標準化しようとして失敗する事が多い。取引管理は国の習慣や顧客によって違うのが当然なので標準化出来ない。残高の標準化を考えるべき。

残高管理というレイアーで整理するという発想は、偶然データ総研内でも議論しており資料として一部作り出している。

＜所感＞

私が聞きたくて堀越さんにお願いしたテーマでした。目的と意味論を最重視して、意味を見える化するためにデータモデル(Plan-DB)を使うという一貫性は流石に800件もマスタ統合を手掛けられた会社だけあると感心しました。

私がメモに星印をつけた言葉は次の２つでした。どこかで私が使っているのに気付かれたら「堀越さんの言葉をぱくったな」と笑ってください。
・「業務を回す」から業務の記録としての蓄積へ　（過去・将来）
・予定スペックと結果スペックの違い

渡辺さんのプレゼンは相変わらず面白いです。全社アーキテクチャーというとＥＡ（エンタープライズアーキテクチャー）を考えてしまいますが、ＥＡは極めて実装寄りの話ですから３年後に使える保証はありません。この渡辺さんの視点は劣化する事はないでしょう。こういう俯瞰的視点を、忙しいお客様にどうアピールして重要度を認識してもらうかは課題だと感じました。

以上

ちょっと気になるタイトル２つです。私も楽しみでした。参加者は９名でした。参加者同士で議論するには10名程度が丁度良いのかも知れません。どちらも一般的には言われていない（？）議論ですから多少わかりにくいと思いますが突っ込みがたくさんあって大変楽しかったです。渡辺幸三さんがいきなり立ち上がってホワイトボードで語り出した時にはどうなるかと思いました(笑)

終わってからの２次会は５名で朝４時まで飲んでました。今まで私が最年長でしたが、今回は私より年配者が最後まで残って下さいました。ありがとうございました。

＜資料＞
■言い訳ドリブン開発
http://www.onas.asia/home/kwansaiit/doc/Kansai-IT-Benkyo-Enkai_20111028_Sano.pdf

■データベース設計はプログラミングの後に行う
http://www.onas.asia/home/kwansaiit/doc/Kansai-IT-Benkyo-Enkai_20111028_Ikushima.pdf

Ⅰ．言い訳ドリブン開発　　佐野初夫

・「正義の味方」と「悪玉」の特徴
テーマとは直接関係ありませんが、Twitterで流れていた言葉を表紙に使いました。同じ事でも見る方向を変えると違う見方が出来るというお話です。この事が「言い訳ドリブン開発」の通奏低音です。
正義の味方の特徴：
　　①自身の具体的な目標を持たない　②相手の夢を阻止するのが生き甲斐
　　③単独～少人数行動　④常に何かが起こってから行動　⑤よく怒る
　悪玉の特徴：
　　①大きな夢や野望を抱いている　　②日々努力を重ね夢に向かって尽力している
　　③失敗してもめげない　④組織で行動する　⑤よく笑う

・言い訳の出来る仕事をする事
私が若いころに言われた言葉です。その時はわからなかったのですが部下を持った時に理解出来ました。言い訳をしてくれないと「何故そういう事をしたか」がわからないために矯正も出来ませんし、顧客や上司から守ってあげる事も出来なくなります。

・「ごめん」と謝る勇気
プロジェクトの中では、その時点の情報だけでは決められない事が多数発生します。立ち止まる事が最悪の結果を招く事があります。判断出来ない時は「どちらが言い訳がしやすいか」で決めましょう。それが間違っていた時に正直に謝って違う道を選びましょう。

・言い訳駆動開発のステージ
お客様が失敗した時の言い訳を考えて大きな会社に頼むという事があります。悪い言葉で言うと保険としての役割を求めているように思う事があります。多重下請構造の中で小さな会社の社員がほとんどを作っている事も多いでしょう。それぞれの中で言い訳を考えた結果ですから、それを考えて動く必要があります。

Ⅱ．データベース設計はプログラミングの後に行う　生島勘富氏

・前提
原理主義者としての発言です。よく炎上しますが、芸風だと思ってください。上流の仕事とは、お客様の業務を（システムを使って）改善する事です。そのためには、技術をわかっていてもらいたい。技術のわからない上流設計が多すぎて困る事があります。

・パフォーマンス
上流工程で「なにか難しそうだからバッチ」と決めてしまう事があります。実際にはＳＱＬ文　１文で出来る事をバッチで作るため10倍や100倍のパフォーマンスになってしまう事があります。ちゃんとした技術者（=SQLがわかっている事）が作れば10分で終わる処理を上流設計者が100分や1000分かかると判断して設計すると別世界の設計になります。そういう設計が多すぎます。お客様も過去にSierから「出来ません」と嘘をつかれて信じている事もよくあります。

・具体例
某ＥＲＰパッケージのリプレイスの仕事がありました。バージョンアップの費用が出ないと頼まれたので数百万円で外部仕様からフルスクラッチで作り変えました。全プログラム400本のうち、396本までは１つまたは２・３のSQL（ストアドプロシジャー）で作る事が出来ました。4本だけはプログラム（.net）で組みました。

SQLの教育の演習の一つ。これがSQL　1文で書ける事がわかるでしょうか
＜演習問題（抄）＞
売上処理で顧客ごとに消費税の扱いが違います。顧客ごとに設定してあります。
・丸め単位：　1:明細単位　2:納品書単位　3:請求書単位
・丸め方法：　1:切り捨て　2:四捨五入　　3:切り上げ
経理システムに連動するに当たり、明細単位に消費税を持たねばならず、その合計が請求書の消費税額と一致する必要があります。配賦方法として、明細単位で丸めた消費税の合計と、納品書・請求書単位で算出した消費税の差を、明細単位の合計金額の多いものから１円ずつ増減します。

問題の全文はここにあります
http://www.g1sys.co.jp/mondai.html
回答はここにあります
http://www.g1sys.co.jp/kaito.html

・ユーザインターフェース(UI)
お客様はUIにはこだわりを持っているが、データベース側の技術を持っている方は大変少ない。そもそもUIの仕様書は作っても無駄。穴だらけの仕様書を作るくらいならアジャイルで試行錯誤すればよい。
このギャップは、お客様との接点をデータベースでなく送受信のインターフェースにする事で解決する。インターフェースは欲しい画面を出すための項目なので、正規化なども関係なくお客様でも比較的簡単に作れます。裏の業務ロジックは、プロであるSQLバリバリのSEがサクッと作れば良いという方法です。

・開発手順
インターフェースを決める時に、具体的な入力／出力のデータ自体も登録します。その具体的な入力／出力だけを行うテスト用のSQL文を作ります。具体的な入力／出力のデータがあれば、ストアドプロシジャーでその答えを返すだけのViewを作成すれば、UIからのスタブを作成できます。
＜スタブ用VIEW例＞
CREATE VIEW vi得意先マスタ
AS
SELECT 100001 AS 得意先ID, '生島商店' AS 得意先名 UNION
SELECT 100002 AS 得意先ID, '佐野商店' AS 得意先名 UNION
SELECT 100003 AS 得意先ID, '渡辺商店' AS 得意先名 UNION
SELECT 100004 AS 得意先ID, '杉本商店' AS 得意先名
GO

UIのコーディングが終わるまでＤＢはなくても開発が出来ます。UIが終わってから正規化等を考慮したデータベースの物理設計とストアドプロシジャーを使った業務ロジックの設計／実装を行います。

※サロゲートキーや命名規則の議論も盛り上がりましたが、省略します。

<<所感>>
スマホ対応やHTML5対応などでUIは今後益々複雑になってきます。データベース設計はある意味プロとしてのＳＥの仕事だと割り切り、お客様が一番気にされるUIの設計に一番近い入出力インターフェースを分界点とするという考え方です。

この入出力インターフェースを、「何かのコードを入力すると、必要な項目が返ってくる」と単純化すると、実は概念設計と言えるのではないかと言う指摘がありました。正規化だとかカーディナリティなんてことは考えずに、必要な項目だけに集中して１：１で入出力を設計する事は確かにハードルが低いと思います。

ただ、事前に全体業務としてのテーブル構造（佐野が「なんちゃってDOA」と呼んでいる部分）のイメージは必要だろうと思われます。また、画面の入出力では表せない業務ロジックは別に検討する必要があります。例えば、受注入力画面で発注可能在庫数を出す画面の場合、入出力は簡単ですが業務ロジックは複雑な場合があります。日本中に何十とある倉庫の中からある条件に合った倉庫しか使えないとか、納入希望日に近い入庫予定から引き当てるなどの条件がある場合です。

データベース設計には、概念設計→論理設計→物理設計というフェーズがあると一般的に言われています。その概念設計の一部としてUIインターフェースを位置づけるという理論が出てくるかも知れないと感じました。いや、もしかするとこれこそが現代の概念設計だと言っても間違いとは言えないかもしれません。コードを入れると項目が返ってくるというのは関数従属性だと言えます。

以上

勉強会は１時間半で切り上げて忘年会になだれ込みました。参加者は１２名でした。今回は日付が変わる頃には２次会も終了しました。

参加して頂いた皆様ありがとうございました。来年もよろしくお願いします。

テーマは「コッド論文を読もう」。なんと硬派なタイトルなんでしょうか(笑)。今回は本当に杉本さんにおんぶにだっこで申し訳ありませんでした。でもおかげで杉本さんというガイドさんに連れられて、ＲＤＢが発明された1970年にタイムスリップする事が出来て感謝しています。コッド博士は、すべてのＲＤＢは「リレーショナルではない！」と切り捨てています。初めてコッドが表明したリレーショナルモデルとはどういうものだったのか、コッドは何を言いたかったのかが勉強会のテーマです。

理解に必要な歴史的事実を少し述べます。
・この論文が書かれた当時、コッドはIBMの研究所社員でした。
・IBMは階層型のIMS/DBがばんばん売れていましたから当初この論文を無視しました。
・実装を開発するプロジェクトがスタートしてもコッドはプロジェクトからはずされました。
・IBMはコッドが推奨するアクセス言語を採用しませんでした。
・かわりに、リレーショナルでないSQL(当初はSEQUEL)を採用してしまいました。
・コッドはSQL言語を「彼の理論の間違った実装である」と公表したためIBMを辞めてしまいます。
・RDBの実装は1979年にOracleがIBMよりも先に完成させ発売しました。

＜英語版の場所＞
最初のものは1969年です。ＩＢＭの社内報に載りました。
「Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks」
http://technology.amis.nl/blogacc/blog/wp-content/images/RJ599.pdf

２つ目は1970年に学術誌に掲載されました
「A Relational Model of Data for Large Shared Data Banks」（ＰＤＦが開きます）
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.1845&rep=rep1&type=pdf

＜今回の勉強会資料＞
英語が苦手な方に
http://www.onas.asia/home/kwansaiit/doc/1970対訳.pdf
今回の資料です
http://www.onas.asia/home/kwansaiit/doc/Kansai-IT-Benkyo-Enkai_2012-12-16_Sugimoto.pdf

＜コッド論文を読もう（RDBの原点）＞
　　　　　　　　　　　　　　　　　　　　　　ウォーターマーク・アプリケーションズ　杉本啓さん

１．既製システム（１．２章）

　1970年当時は、データベースと言えば、ネットワーク型か階層型でした。そういうデータベースを扱った事がある人は参加者中半分ほどしか居ませんでした（多いような気もしますが・・・）。その説明に多くの時間を取りました。

例えばヘッダ－明細型の構造であれば、ヘッダーAを親レコードとして子レコードA1,A2,A3を格納します。実装としてはポインタを持つ事になりますが、このポインタ（＝アクセス経路）に名前を付けます。コッド博士は、アクセス経路に依存せず純粋にデータだけで見て関係がわかるべきであると言っています。

２．データに対するリレーショナルな見方（１．３章）

　Network (CODASYL) Data Modelの絵を見つけましたのでそれで説明します。

このChildレコードの親がSmithであることはアクセス経路だけでわかるという事が「アクセス経路依存」です。リレーショナルモデルなら、Childレコードに親Nameを持つでしょう。コッドは、データの属性と経路（＝関係）という２元モデルを、全部属性に持つ事で関係を表すという１元モデルで表現できる事を示しました。表現出来るというよりは、両者の区別は困難であり区別する事が不要だと証明しています。
（1969年論文では繰返し構造<第一正規形>を排除していなかったため2元モデルになってます）

数学的なリレーションを基礎とした事で、述語論理と集合演算（リレーション演算）を同じものとみなせるかも知れないと述べています。（後年、等価である事は証明されました）。これの前提は、リレーショナルモデルが「ドメイン」だけを構成要素とする１元論である事です。ところが、一般的な（チェンの）ＥＲモデルは「実体」と「関連」という２元論の言葉を使いながらも数学的にはリレーショナルモデルに立脚しています。

３．利用モデルと実装モデル（１．６章）

　コッド博士は、利用者から見えるリレーショナルモデルを説明するだけでなく実装の方法も細かく解説しています。この辺りもこの論文のわかりにくい部分です。
　　　　　　　　　　　　　　　　形式　　　　データ重複保持
・ユーザ向けのモデル　　列順なし　　　　許さない（推測）
・保管形式のデータ　　　列順あり　　　　許す

４．結合のわな（コネクショントラップ　２．１章）

　Ａ→Ｂ→Ｃという３項関係を、Ａ→Ｂ、Ｂ→Ｃという２項関係２つで表現しようとする時に生じる情報の欠損をコネクショントラップと呼んでいます。２項関係の自然結合（ナチュラルジョイン）を、現実に存在する３項関係だと思いこんでしまう事を「トラップ」と言っています。

上の図5から導き出される自然結合は図6になりますが、現実の関係は図7かも知れません。つまり、プロジェクト「J1」は、業者「S1」の部品「P1」を取り扱っていないかも知れないという事です。

※この条件を示すために、ＰＪ→業者というテーブルを作る事を結環と呼んでいますが、それでもすべての条件を示す事は出来ません。

５．強い冗長性と弱い冗長性（２．２章）

　「冗長性」という言葉は、複数の表を組み合わせて異なる表を作るときに、生じる制約の事を言っています。表Ａと表Ｂを組み合わせて、一種類の表Ｃしか出来ないなら完全に情報がダブっているわけです。そういう完全なダブリを「強い冗長性」と呼んでいます。
　いくつかの選択肢はあるけれども、表現の自由度が制限されるものを「弱い冗長性」と呼んでいます。

この冗長性と一貫性を何のためにここまでしつこく語っているのかはよくわかりません。ドロドロとした怨念のようなものを感じます(笑)

＜所感＞
正規形というのは、関数従属性（または多値従属性）を元に複数テーブルに分解する事ですが、実際のデータの中身に関係なく機械的に分解します。この論文ではデータの中身を問題にしている所が不思議でした。この冗長性を追求することで後年、コッドはまたボイス－コッド正規形(BC正規形)を発見したのでしょう。BC正規形については@ＩＴの記事をお読みください
http://www.atmarkit.co.jp/fdb/rensai/db_enginer03/db_enginer03_3.html

１元モデルと２元モデルは興味深い話でした。オブジェクト指向モデルはコッドがせっかく１元モデルで示そうとしたものをまた２元または多元モデルに戻そうとしたのだと感じました。エントロピーの法則だからしかたがないのか。最近流行しているＢｉｇＴａｂｌｅも結局責任がプログラマに戻っているという意味で先祖がえりしています。

勉強会の中で、結合のわなを避ける方法について「Ｔ字形の対照表」という話をしました。念のために調べると、佐藤正美さんはもっと深い（？）事を考えられているようなのでリンクだけを貼っておきます。私には理解出来ず解説出来ませんのでご興味があればお近くのＴ字形の方にお尋ねください。
基準編-11　対照表
http://www.sdi-net.co.jp/blackbook-12.htm
>DOA の一派および OOA の一派が、「対照表」を「データの冗長性」である、
>と非難したが、コッド流のデータ正規化から判断すれば、そうであるが、...

以上

勉強会は１時間半で切り上げて新年会になだれ込みました。参加者は１３名でした。初めて神戸　三ノ宮で開催しました。場所を提供していただいたＩＢＭさん、ありがとうございました。さすがに三ノ宮からタクシーだと破産しますから、梅田まで帰ってから飲み続けていました(笑)

参加して頂いた皆様ありがとうございました。私が就職してしまい、今までのような手間をかけられませんが、ネタがある限り続けますので、本年もよろしくお願いします。

－－－－－よろしければ、メーリングリストにもご参加ください
次のアドレスに空メールを送ればご自分で参加出来ます。退会も簡単です。

KwansaiIt+subscribe@googlegroups.com

　※+は１バイトのプラスの文字です

－－－－－

テーマは２つです。どちらも想像以上に面白かったです。

＜今回の勉強会資料＞
http://www.onas.asia/home/kwansaiit/doc/Kansai-IT-Benkyo-Enkai_2012-01013_goto.pdf
http://www.onas.asia/home/kwansaiit/doc/Kwansai-IT-Benkyo-Enkai_2012-01-13-Shimoji.pdf

＜DBセキュリティツールGuardiumのご紹介＞
　　　　　　　　　　　　　　日本IBM　後藤徹平さん

１．ツールの背景

　約２年前、２００９年１２月にIBMが買収しました。当時、企業データベースのリアルタイム監視・保護において市場トップでしたので、機能的に相当優秀です。ある報告では、漏洩事件の82%は事件そのものを自分自身で発見出来ていないそうです。カード会社など第三者からの連絡で判明することがほとんどです。

　情報セキュリティ確保のための５カ条の方針は次のとおりです
　(1) 持たせない (2) 見せない　(3) さわらせない　(4) 持ち出させない　(5) モニターする
これらを実現するためのツールです。次の３つの機能を持っています。
(1) 記録　→　100%アクセス監視
(2) 警告　→　リアルタイムチェック（大量アクセスetc）
(3) 集計　→　監査テンプレート

２．Guardiumの構成

　ほとんどの商用データベースに対応しています。大変珍しい構成になっています。
(1)DBサーバのOSにモジュールをセットする　
(2)保管はネットワーク上のアプライアンスサーバで行う

商用データベースには監査ログがあります。それとどこが違うのでしょうか？また、とにかく全部の情報を残すならネットワーク上の全部のパケットを残すという方法もあります。それと比べてこの構成のどこにメリットがあるのでしょうか？

　監査ログだと、DB管理者がログを消したり改ざんしたり出来ます。アプライアンスに保存すると消したり改ざんしたりすることが出来ない事を「保障」出来ます。システム管理者ですら信用していないという徹底ぶりがある意味気持ち良い(笑)ネットワーク上でミラーポートやリバースプロキシで残す構成だと、HTTPSなどの暗号に対応出来ません。

値段については言及ありませんでしたが、検索してみると600万円～という強気な値段設定です。

＜オープンソース　Rubyフレームワークのご紹介＞
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　下地忠史さん

１．開発のポリシー

　プログラムを作る事とシステムを作ることは大きく違う。システムは業務である限り保守メンテが必ず必要です。保守を簡単に行うためには出来る限りプログラムを作らないようにしたい。つまりこのフレームワーク自身はRubyで作ってありますが、業務を作るのにRuby言語はほとんど不要になっています。その点では好き嫌いが分かれると思います。

(1) クライアント側の編集はｊQuery
ボタンもCCS3で表示しているため画像は使っていません。AJAXが当たり前になっている今となっては、サーバ側でHTMLを生成するという構成は時代遅れだと思います。TabとEnterを同じ動きにしたり、Fキーの定義もｊQueryで行っています。

(2) すべてのデータ受け渡しはJSON形式
JSON (JavaScript Object Notation)とは、JavaScript言語の一部をベースに作られた軽量のデータ交換フォーマットです。JavaScriptは当然ですが、Rubyでも簡単に連想配列になるために大変使いやすいです。
サーバとクライアントの間もJSONフォーマットで受け渡しをしています。ブラウザの中のJavaScriptでマッピングして表示しています。この構成だと、クライアント側がiPhoneアプリでも対応出来ます。

(3) 分散バッチ
業務である限り、バッチ処理は避けて通れないと考えています。プロセス間の協調のためにRindaという並列プログラミングモジュールを使用しています。これによって、タプルとタプルスペースをコントロールしています。資料上の左上の「Model」はMVCのモデルと同じです。つまりオンラインでタプルサーバに対して、どのテーブルでどのキー範囲かを指定します。タプルサーバは指定された分散数だけKeyを分割してタプルクライアントを起動します。タプルクライアントは並列に処理を行います。

(4) 帳票作成
業務ですから帳票も必須機能です。最初は、Rubyのフリーの帳票ツールであるThinReportsで動かしていました。でもThinReportsの帳票の考え方には馴染めませんでした。年末に、たまたま本屋さんでLyXという文書プロセッサを知り、使えそうなので全面的に変更しました。これはLaTex(tef)そのものです。LaTexは理工系の大学なら使っていたと思います。それのワープロ機能がLyXです。人間が書いたような素直なソースを生成してくれますので大変使いやすいです。

２．ＭＶＣ構成

資料P.2（１．MVCモデル）のとおり、リンク

（入力時点に、ブラウザ側でvalidationチェックを行う）
(1) ブラウザからJSON形式でコントローラにrequest送信
(2)コントローラで再度validationチェックを行う
(3)指定があれば、controller.rbでチェックする ★Rubyプログラム
(4)チェック済みリクエストデータをモデルに渡す
(5)　モデルは、リクエストデータとsql.jsonを使ってSQLを生成実行する
(6)　実行結果がある時は、結果をsql.jsonのデータにマッピングする
(7)　sql実行前・後にmodel.rbを実行する。（指示が有る時）★Rubyプログラム
(8)　コントローラにリターンする
(9)コントローラはsql実行結果とリクエストデータを引数に、ビューをコールする
(10)　ビューは、tran.json内のレスポンスデータにマッピングする。
(11)　view.rbでレスポンスデータを編集する。（指示が有る時）★Rubyプログラム
(12)　レスポンスデータをコントローラへリターンする
(13)コントローラはブラウザへ送信する
（ブラウザのJavaScriptで画面レイアウトに編集を行う）

これでわかるとおり、RubyプログラムはJSONで指定された時だけ呼び出されます。
最後の結果表示は、JSON形式をブラウザ側で編集しますから、ブラウザが「ビュー」だという見方も出来るかもしれませんが、本当の意味での実行結果の編集はサーバ側の情報がないと出来ませんので、そうい見かたは取っていません。画面の編集は時代によって変わりますし、どう変わるかを指定する必要もありません。それらはｊQueryが汎用的に行ってくれます。

＜所感＞
下地さんは、昨年定年で退職されましたが、70歳まであと10年は現役のプログラマとして活躍したいそうです。一方の後藤さんは下地さんの半分の年齢でした。でも同じ分野で一線で活躍している方が年齢を超えて議論できるのは大変良い事だと感じました。私は下地さんの10歳も下ですのでこれから益々頑張ろうと勇気を頂きました。

実際に動くところを勉強会では見てもらいました。MySQLのバージョンとドライバのバージョンの関係でインストール手順を整理してから公開しますので、もう少しお待ちください。ただ、ライセンスが整備されていませんので、全公開せず、メーリングリスト上だけで公開するかもしれません。その点ご了承下さい。

以上

今回はDAMAインターナショナル日本支部会長にわざわざ東京からお越し頂いての勉強宴会となりました。本当にありがとうございました。生ビールサーバもありませんので、普通の勉強会になってしまった感はありますがご容赦下さい。環境に順応して華麗に変化する、しぶとく生き残る勉強宴会を目指しておりますので今後ともよろしくおつきあい願います。

参加者は14名、2次会は9名、3次会は5名だったのですが用事で勉強会に参加出来なかった方１名が合流されました。4次会は6名。ここでもまた何故か1人抜けて1人増えました(笑)上流工程設計をネタに明け方まで楽しく騒ぐ事が出来ました。ありがとうございました。

＜今回の勉強会資料＞
Kwansai-IT-Benkyo-Enkai_2012-03-19-matsumoto.pdf

＜フィールド間の整合性に関する「双方向性問題」を考える＞

ディービーコンセプト　渡辺幸三さん

データ項目の妥当性検査の事を、バリデーションチェックと言います。例えば「受注数は０より大きい事」というような入力規則の事です。このバリデーションチェックには、他の項目との関係で表現されるものもあります。

例えば、「a1はa2より小さい」「a2はb2の倍数」などです。後者はチェックするための項目が他のテーブルにある例です。
※勉強宴会内では、「10倍」でしたが導出項目と勘違いされないように変更しました。

これらの整合性は裏返しの制約とみることも出来ます。
「a1はa2より小さい」→「a2はa1より大きいか等しい」
「a2はb2の倍数」　　→「b2はa2の約数」

b2を変更すると、b2とa2の整合性がくずれてしまいます。それを防ぐために、プログラムで煩雑なコードを書く事が多いでしょう。「仕様書で動く業務システム」であるXEAD Driverの機能追加を考えている時、これらのバリデーションを、データベースのテーブルに内臓する事を思いつきました。それを実装してみると、プログラミングとして残る部分が大変小さくなりました。

＜所感＞
このバリデーションには、「不変条件」のものと「入力時チェック」のものとがあります。この話は前者である時に問題になります。データ中心設計(DOA)では「データの正しさを守るために入力画面がある」と考えます。その「データの正しさ」の範囲を広げてフィールド間の整合性まで含めたという事なのだと受け取りました。

この問題は、渡辺さんのブログで何度か取り上げられているものです。そもそものきっかけは「動的参照関係」の一連の議論でした。
2011.12.20　動的参照関係を「宣言的」に扱えるか　　その他
http://watanabek.cocolog-nifty.com/blog/2011/12/post-63f9.html

年が明けて、今回説明された「双方向性問題」に発展されました。
2012.01.12　バリデーションの双方向性問題を解く
http://watanabek.cocolog-nifty.com/blog/2012/01/post-1498.html

プログラムとデータベースとの役割分担はDOA技術者なら必ず意識しますし、様々な提案をされている書籍も多いです。ただ、渡辺さんはXEAD Driverという実装系を自ら作って公開されている世界唯一のデータベース技術者です。議論のための議論ではなく実装されていますので説得力が違います。「双方向バリデーションの機能を実装したところ思いほのか便利でした」と言われて反論出来る人はいないでしょう。ぜひオープンソースのXEAD Driverを使ってみましょう。
http://homepage2.nifty.com/dbc/xeadDriver.html

＜DMBOK－データマネジメント知識体系のご紹介＞

DAMA-JAPAN 会長　松本聰さん

１．DAMA Internationalとは

DAMA Internationalは完全ボランティアで活動している団体です。昨年末のカンファレンスに米国からスピーカーを招きましたが、彼らも基本的にボランティアです。
・データが企業の資産である事を認識する土壌を作る
・データマネジメントのプロを育成する
・特定のベンダーに頼らず、特定の技術に頼らず、特定の方法論を支持しない

中国とオーストラリア、インド、それに日本がAsian&Pacificとして活動しています。入会は原則個人です（年１万円）。法人会員も受け付けていますが、個人名としての登録としています。現在100名弱です。半数くらいが公式Facebookで情報交換を行っています。あわてずあせらず徐々にデータマネジメントを広げていきます。

日本では第1～第4の分科会が活動しています。
第１分科会：エンタープライズ（企業活動）での事例研究
第２分科会：データマネジメント用語の日本語訳
第３分科会：データマネジメント成熟度モデルの検討
第４分科会：意思決定に寄与するデータモデルの検討

２．Peterさん（協会トップ）のプレゼン

データマネジメントの広がりについて。日本はまだ米国の1980年ごろに見えます

1950～1970　DataBase Administration(DBA)
　　データベースデザイン
1970～1990　Data Administration（DA)
　　データ要求分析とデータモデル
1990～2000　Enterprise Data Administration(EDA)
　　データ統合
2000～　　　Data Management（DM)
　　データガバナンス、セキュリティ・・・

３．DMBOK（ディンボック）

データマネジメントを行うための１０の機能と７つの環境要素を解説したものです。何を行うべきか（WHAT)は書かれていますが、どうやれば良いのか（HOW)は書かれていません。特定の商品や方法論なども書かれていません。

DMBOKの中心はデータガバナンス（統治）です。データの品質を確保し維持するための活動です。例えば製造メーカーで品質管理を外注化している企業はいないように、ユーザ企業自らが行う必要があります。

データモデルは、10の機能の中の「データ開発管理」の一つの項目として出てきます。データ開発管理の原則の一つはこういうものです。
-----
8. データモデルは価値ある知識のリソースである（メタデータ）。データモデルの品
質と有効性の保証をライブラリ、形式、変更管理の面から注意深く管理しコントロールする
-----

４．その他

米国ではもうすぐDMBOKの次期バージョンが出る予定です。現バージョンはデータ統合が弱いので、マスタ統合を別項目として独立させると思われます。ERPのマスタの扱いについて、各社苦労されています。

たとえばSAPのマスタは色々癖がありますので、それを企業としてのマスタにする事は難しい。ある企業はSAPのマスタは捨てて全システムのマスタ統合を実施し、その統合マスタからSAPに渡すという仕掛けにされています。協和発酵キリンさんなどDOAをきっちりとやっておられる企業はそういう方向にされているようです。

アジャイル開発とデータモデリングの関係性については、米国でそういう発表を行う人が現れています。新規開発で、データモデルもなくアジャイル開発を行う事は現実的ではありませんし、逆にフラグ１つ追加するのにDAの承認が必要ならアジャイルにならないでしょう。これからのテーマだと思います。

＜所感＞
昔、高速開発の手法としてRADというものがありました。RADは実はDOAを前提としていました。アジャイルがもし本当にそちらの方向に行くなら先祖がえりだと思います。

システム設計としてのDOAは、ビジネスや業務をどう分析して整理するかという視点を持っています。DMBOKは各企業が「データを大切にしているか」という事を自ら検証してどこが弱くて注力するべきかを知るための道しるべとして利用するものだと思いました。

これを用いたコンサルティングは監査と変わらないでしょう。

DAMAは、企業にとって「データが大切」だという事を啓蒙する団体です。既にデータ中心でやっていてそれが競争優位につながっている企業にとっては敵に塩を送るような話ですから参加する意味はありません。逆にプロセス中心の企業は入ろうとするインセンティブがありません。そのためにアンテナの高い「個人」をターゲットにされているのだろうと思います。

今のところ大阪には支部がありませんが、名古屋には作る動きがあるそうです。この勉強宴会は日本でも珍しい上流工程の勉強会です。データモデリングが好きな人が集まっていますので、DAMAの動きには気を配りたいと思います。

以上

今回は初めて、シナジーマーケティングさんに会議室をお借りしました。ありがとうございました。そのため、多少遠慮して18時始まりにしました。しかもクローズドな勉強会にしましたので、参加者は10名。

予定通り20時に終わり7名で飲みました。3次会、4次会は3名で2時ごろまで。いつもより大人しい勉強宴会になりました。

＜今回の勉強会資料＞
Kwansai-IT-Benkyo-Enkai_2012-05-25-sano.pdf

＜ＤＯＡ技術者のためのセールスフォース入門＞

　（株）セールスフォース・ドットコム　佐野初夫

入社してまだ半年ですので、完全に理解してるわけではありません。でも逆に、オンプレミスとの違いについて新鮮な驚きをもっている間に説明した方が良いと考え多少背伸びして説明しました。あくまでも個人的な意見ですので、その点をご了承いただける方だけ読んで下さい。

内部的には驚くべき仕掛けであっても、１年も経つとそれが当たり前になってしまうからです。私自身の「驚き」は伝わっただろうと思います。

私はまだ新人ですので、もし明らかな嘘を言っているといけませんので、セールスフォースを良くご存じのケイズコーポレイション　吉川さんに参加して頂きました。ありがとうございました。

■セールスフォースの全体像

1999年創業。元Ｏｒａcleの技術者だったマーク・ベニオフが「Amazonで本を買うように簡単に」アプリケーションを提供しようと考えて、Oracleのエリソンに支援を得ながら創業しました。2006年、開発基盤としてForce.comをスタートしました。今でいうPaaSです。2010年、twitterやフェースブックなどSNSのメリットをビジネス（エンタープライズ）でも生かすために「ソーシャルエンタープライズ」を提唱。chatterをはじめとした様々な仕掛けのサポートを開始しました。

今のところ毎年３回大きな機能追加があります。セールスフォース側から追加する機能だけでなく、利用者から変更の希望を募って実現しています。
http://success.salesforce.com/search?type=Idea
左側には「いいね」の数がポイントとして表示されています。その数の多いアイデアから検討されて結果が示されます。この機能は、デルさんやスターバックスさんでもご利用頂いています。掲示板で投稿して「いいね」を押すだけなら、フェースブックとかでも出来ると勘違いされると思いますが、エンドユーザには見えない裏側の膨大なプロセスをサポートしている事が重要です。個人の判断で採用するかどうか決められるわけがありませんので、裏では喧々諤々検討され結果として「採用」だとか「不採用」だとかが表示されるのです。そういう裏のプロセスがなければ業務として成立しません。

全世界のデータセンターで障害が発生していないかリアルタイムに情報を出しています。
http://trust.salesforce.com/trust/status/
実際には障害を隠そうとするデータセンターは多いですが、セールスフォースは馬鹿正直に全部さらけ出しています。クラウドには信頼が最も重要だと創業者のマークが考え、それを実践しています。

セールスフォースは5～6年ごとに大きく変貌しています。それぞれについて説明します。

■SaaS(Software as a Service)としてのＣＲＭ

CRMは、Customer Relationship Managementの略です。わたしはこれを「お客様とのパイプを太くするシステム」と訳しています。まず、お客様を取り巻く360度ビューと呼んでいるのですが、マーケティングから営業支援、コールセンター、そしてマーケティングに戻るという360度グルッと取り巻くシステムと仕掛けを持っています。

ＣＲＭのバリューチェーンを定義し、それぞれの部門が自分の部門のKPIを最大化することが結果的に売上増加につながるという仕掛けです。我々のライセンス費用は通常年間払いです。つまり売上が増加しないと契約を打ち切られる可能性があるのです。契約が打ち切られないためにはお客様自身に成果を上げてもらう必要があります。そのための最大限の支援を行う組織をセールスフォース内に持っています。

■PaaSとしてのForce.com

Googleなどコンシューマ向けのクラウドは、信頼性の低いサーバやストレージを使用しながら壊れることを前提としたシステムを作っています。セールスフォースはエンタープライズシステムを対象としたシステムですので、普通の基幹システムと同等以上の構成を持っています。パッチも含めて日々進化していますので現時点の最新構成はわかりませんが、データベースはＯｒａcleｎｏのＲＡＣ構成ですしサーバやストレージはエンタープライズ向けの高信頼性の物を使っています。

マルチテナントを実現する仕掛けは大変ややこしいものです。実際に使用しているＯｒａｃｌｅの主要なテーブルは全ユーザで合計20種類もないと思われます。その中にお客様ごとの設定やプログラムやデータが混在しながら保存されています。興味のある方はこの記事をご覧ください。
http://www.publickey1.jp/blog/10/_flex_schema.html

プログラム言語はＡｐｅxという独自の物です。ぱっと見るとＪａｖａとあまり変わりません。データベースアクセスはＳＱＬと似たＳＯＱＬで行います。これらは、上位互換をセールスフォース自身が保証するために独自言語にしていると考えて下さい。ＳＯＱＬは例えばＪＯＩＮは出来ません。参照関係を定義してあるエンティティ同士なら別エンティティの項目を読む事は出来ます。レポートだけはインナーｊｏｉｎなど複雑な関係を定義することが出来ます。

標準画面のプログラムの作り方について、勉強会では少しお教えしましたがブログでは伝わりませんので、興味がある方は無料のオンライントレーニングを見て下さい。
http://www.salesforce.com/jp/services-training/education-services/online-training/
メモしながら全部をゆっくり見ると１日では終わらないほどのボリュームがあります。
もう少し具体的なテーマならこちらがあります。
http://successjp.salesforce.com/home/
これはセールスフォース社員が多数のお客様に向けて電話会議で説明するという形態です。6/8のsummer12の新機能説明会は人気が高いと思います。

■ソーシャルエンタープライズ

ＳＮＳの情報やシステム的な成果をエンタープライズにも導入しようという活動です。典型的な物として、トヨタさんが採用されたトヨタフレンドがあります。この分野では日々新しいアイデアが実現されていますので、来年の今頃どうなっているのかすらわかりません。

2010年12月に、HEROKUというクラウドサービスを買収しました。HEROKUはRUBY言語のクラウド環境として有名ですが、実はフェースブック内でアプリを作ろうとするとデフォルトではHEROKU上に作られます。今HEROKUからセールスフォース上のデータを読み書き出来るためのAPIが整備されつつあります。これが完成すればフェースブックとセールスフォースがシームレスに連携出来るようになりさらに一層新しいサービスが生まれ易くなるでしょう。

＜所感＞
私自身も大変勉強になりました。ありがとうございました。

「導入されたお客様の売上が上がらないと契約更新していただけないので、セールスフォースとお客様とはWin-Winの関係にあります」とご説明しました。この発想はセールスフォースの中に居ると当たり前なのですが、ある方に「これが日本のメーカーとの大きな違いだ」と指摘されました。

お客様が「こういう風に使いたい」とおっしゃってもそれでは売上増加に貢献出来ないと判断すると、セールスフォースの営業は反対します。反対されることに慣れておられないお客様だとそこでお話が破談になる事もあります。おっしゃる通り導入しても１年で契約終了になるとLOSE-LOSEの関係になってしまいますから、それを避けようとします。

AmazonやGoogleの課金体系では送受信パケット数など一部の項目が従量制になっています。セールスフォースは固定額です。つまり使えば使うほど相対的に安くなるという事です。私も含めてセールスフォースの営業はライセンス数が増えないと対応出来ません。セールスフォースのライセンス料を有効活用するためには、セールスフォースを良く知っている優秀なパートナーと早くから契約して相談する事が近道だと思います。

以上

今回も前回に引き続きシナジーマーケティングさんの会議室をお借りしました。ありがとうございました。前回は18時にしましたが今回は定刻の19時です。参加者は19名。しかも初参加の方が８名もいらっしゃいました。予定通り21時すぎに終わり11名で2次会開始。仕事の都合で勉強会はドタキャンされた方が1名、宴会だけ参加してくださいました。まあ「勉強」「宴会」ですからお好きなほうだけ参加されるってものありです。

3次会は9名で朝4時まで。そのうち初参加の方が2人いらっしゃいました。初参加で最後までってのはもしかすると初めてかもしれません。濃いお二人でした(笑)

＜今回の勉強会資料＞
Kwansai-IT-Benkyo-Enkai_2012-06-29-watanabe

＜データ中心設計の基本とクラウド開発＞
　デービーコンセプト　渡辺幸三

＜１＞「ドメイン駆動開発（DDD)」と「データ指向アプローチ（DOA)」の違い
ドメイン駆動開発はエリック・エバンスの同名の著作で有名になりました。モデルベースの設計を中心にしていますのでデータ指向アプローチと似ていると思われるかも知れませんが、まったく違います。DDDはオブジェクト指向の発展系でしかありません。どんな分野でも使えるというのがうたい文句です。

一方DOAは業務システムとか基幹システムとか呼ばれる狭い地味な分野でしか活躍出来ません。ただしDDDと違って数学的な基盤があります。関数従属性です。DOAで設計すると、「エレガントなデータ構造」を求めることになります。DDDで設計すると「エレガントなコード」を追い求めます。

データ構造が形式化されることで、システム開発が合理化される。このことはもう一度出てきます。

＜２＞「データ中心アプローチ」の発展
昔、1990年代に某企業が「構造化分析・設計（SADT）」を広めて大失敗しました。当時最先端の設計方法論としてDOAが言われていましたので、悪気はないと思いますがSADTをDOAだと偽って広めました。それが失敗するとともにDOAも下火になりました。

大変残念です。

SADTもDOAもDFD（データフロー図）とER図を書きます。ところが手順が大きく違います。SADAはDFDを主に分析します。0レベルから3～4レベルまで階層化しながらブレークダウンして、最下層で各プロセスに対して仕様書（ミニスペック）をあてがうことでシステムが出来あがる（そうです）。それとはまったく別のチームが作ってあったER図をぶつけてシステム化します。この手順を見ると、SADTが処理中心の設計手法（POA)だということがお分かりいただけるでしょう。オブジェクト指向もDDDもPOAです。

一方のDOAはER図を中心に設計します。DFDはないこともありますし、あってもつけたし程度です。ただ、このことはDOAの限界として再認識するべきです。大事なのは「データ」だけではありません。そのことに気づいて、三要素分析法を作りました。

＜３＞「三要素分析法」の特徴とＸＥＡＤ
データの構造が正しく出来たとして、そこからプログラムが正しく出来たとしてそれだけでお客様が正しく利用出来るのでしょうか？お客様の目からみると「どういう事態になったときに何をするのか」つまり事務作業の手順が整理されていなければ、そのシステムで過不足なく業務が行えるのかがわかりません。三要素分析法はシステムの基本設計に必要な３要素を同時に設計することを推奨しています。

　　業務モデル：どういう時に何をするかという「事務作業」
　　データモデル：処理の元になる「帳簿組織」
　　機能モデル：データを処理するための画面や帳票

ある人とモデリングのお話をしてると、いきなり厚い紙の束を取り出された事があります。その紙はA4をセロテープで貼ったものでした。パラパラと広げると大規模集積回路のような(笑)　ＥＲ図が現れました。どこと　どこがつながっているのか読むだけでも大変な代物でした。

三要素分析法の特徴のひとつとして、サブシステムがあります。プログラムを分けるだけでなくデータベースのテーブルまで分けることが出来ます。ひとつのサブシステムが管理するテーブル数を10個程度に収めることで大変見通しがよくなります。

それぞれのテーブルは自サブシステムが管理しているものなら青色、他サブシステムが管理しているものは灰色で示されます。他サブシステムで管理しているテーブルを使うときには、原則としてCRUD(Create,Read,Update,Delete)のRだけにするべきです。他で管理しているテーブルを更新したり挿入したりすると更新異常が発生しやすいです。

サブシステムを分けるときには、凝集度を高めて、結合度を下げるということが何十年も前から言われています。疎結合で独立された業務がデータベースを介してつながるというイメージが三要素分析法のDFDのイメージです。イベントドリブンで「どういう事態になったときに」「どういうまとまりの業務をするか」だけを整理します。DFDの階層を1レベル降りただけでDFDでは表せない「プロセス間のロジックを無視できない」世界が現れます。一般のDFDや業務フローはロジックまで書く羽目となっているために効率が悪くかつエンドユーザが理解しにくくなっています。

これらを効率的に入力できるＸＥＡＤ　Ｍｏｄｅｌｅｒというツールをオープンソース(OSS)で公開しています。入力した業務定義をブラウザでそのまま業務マニュアルとして閲覧できる機能もあります。必要なら設計書としえEXCELに出力する機能も持っています。是非ご利用ください。

＜４＞基幹システムを「クラウド開発」するためい必要な社会的リソース

業務システムを開発するためには、多くの専門性をもった技術者が必要でした。ところが今は徐々に１人でも開発出来るような条件が整いつつあります。まずは、業務のリファレンスとなるモデルの公開と整備です。一から設計するのではなく、似た設計を持ってきて必要な部分だけを変更するイメージです。ＣｏｎｃｅｐｔＷａｒｅとしていくつかの業務を公開しています。

次にインフラのクラウドサービスです。私もVPSを使っていますが、安いところなら月1,000円程度でサーバを借りることが出来ます。

そして最後に、設計したモデルを実行するためのプラットフォームです。これもオープンソース（OSS)で公開しています。ＸＥＡＤ　Ｄｒｉｖｅｒです。

基本的な構造はいたってシンプルです。まず設計の内容をXML形式で書いたテキストファイルを用意します。

タイトル：ｘｘｘ一覧
プライマリーテーブル：ｘｘｘ１００
並べる項目：ｄ１、ｄ２、ｄ３
機能タイプ：一覧処理

次に機能タイプ別のクラスを用意します。そのクラスはXMLファイルを読み込んで自分を変形しながら動きます。システム機能タイプは10種類ほどあれば足りると考えています。この方式は、一般的な「自動生成ツール」ではないことに注意してください。

どこにもソースコードは出てきませんしコンパイルも必要ありません。XMLファイルを読みながら自分を変形させながら動いているだけです。これを、「動的制御ツール」と呼んでいます。

重要なことは、DOAがデータ構造を形式化することでデータ処理様式も形式化出来たということです。DOAはシステム開発を合理化します。そこがDDDやオブジェクト指向との一番の違いかも知れません。

＜質疑応答＞
Ｑ：テーブル仕様書にスクリプトを組み込めるようになっていますが、これとトリガーとの違いは？
Ａ：まずはここのアプリケーションとプログラム域を共有していることです。テーブルに書きながらもセッション上の変数域を連動した形で動作する機構としてプラットフォーム上で実装されています。次にデータベースの処理系を選ばないということです。特定のDBMSでしか使えないDML文を使わなければDBMSを選びません。また、複数のDBMSを論理的にひとつのDBとみなす機能を持っていますので、それを使うためにはこの処理方式しかありません。

＜所感＞
多くの初参加者に来ていただいてありがたかったです。XEADをご存知なかった方が4名いらっしゃったのでその方はおそらく三要素分析法も初めてだったでしょう。ぜひ参考にして欲しいです。今までのDOAの方法論でも実際には、業務モデルも機能モデルも意識しています。システム境界を示すために業務フローを書いたりしますし、データの関連やインデックスを設計するためにはテーブルを読む順序（アクセスパス）は意識しています。

そもそも三要素分析法以外は、現状の画面や帳票を分析してデータモデルを書くことからスタートしますから「機能モデル」は設計前からある事が前提になっています。そこからあるべき姿（To Beモデル）を作るわけですが、三要素分析法はいきなりTo Beモデルを書き出すというユニークなものです。

XEAD Modelerもサンプルを触っている限りは簡単ですが、いざ本当に設計をしようとすると色々とわからないことが出てくると思います。もし業務内容を公開しても良いのでしたら、この勉強宴会の中で具体的な設計について説明しても良いと思っていますので是非教えてください。

今回初めて、最後まで付き合ってくださった方がこうおっしゃってました。
「今まで終電で帰ってましたが、そこから先に議論が深くなるんですね。今回初めて参加できたような気になりました。」
この業界でもまれた人は夜に強いですから、0時過ぎてから調子が上がる人も多いでしょう。もちろん勉強会だけ参加された方にも満足してもらうように努めますが、体力に余裕があれば一度最後まで参加してみてください。

今回も、シナジーマーケティングさんの会議室をお借りしました。毎回ありがとうございます。参加者は19名。しかも初参加の方が13名もいらっしゃいました。Rubyという言葉の注目度を感じました。予定通り20：45に終わり11名で2次会開始。0時前まで飲み放題で一人2千円は安かったですね。3次会は7名で朝4時まで。そのうち初参加の方が2人いらっしゃいました。ありがたいことです。

今回は、たぶん世界初の業務用rubyフレームワークであるRmenuの全容のお披露目です。限られた時間でしたが、Rmenuにかける想い、様々な仕掛けについて豊富に語ってくださいました。

なお、このブログの最後にこのフレームワークの現時点(2012年8月）のWebサイト情報を載せます。また、この勉強宴会の告知のためのメーリングリストには次のアドレスに空メールを送ると登録出来ます。
KwansaiIt+subscribe@googlegroups.com

＜今回の勉強会資料＞

Kansai-IT-Benkyo-Enkai_20120824_shimoji.pdf

Kansai-IT-Benkyo-Enkai_20120824_shimoyama.pdf

＜rubyでお手軽に帳票・バッチのある業務システムを作ろう＞

＜Rmenuの技術要素＞　下地忠史さん

　コンピュータ業界40年のノウハウをつぎ込んでRmenuをつくりました。ある自治体関係で受注が決まりましたので、もうすぐこのフレームワークを本番システムで使います。　フレームワーク自体rubyで作りソースも設定方法もなにもかもオープンにしてあります。出来るなら若い方がこのフレームワークを引き継いで改善していって欲しいと思っています。

＜１＞サーバサイドの技術要素
・dRuby　世界的に見るとおそらくRubyそのものより有名。分散オブジェクト通信が出来る実装系。Javaで言うとRMIのようなもの。日本人の関さんが作られた。
・Rinda　並列処理をするためのRuby用処理系。Javaで言うとJavaSpacesのようなもの。
・TeX　　「テフ」と読みます。有名な組版システム。
・LyX　　「リークス」と読みます。TeXを使えるワープロソフト。罫線などを描きます。

＜２＞クライアントサイド
・HTML5/CSS3　　このデモ画面は美しいボタンも一切画像は使っていません。CSS3です。
・Ajax　　　　　JavaScriptの非同期通信(Asynchronous JavaScript + XML)
・jQuery　　　　軽量なJavaScriptライブラリ。探せばほとんどどんなライブラリでもみつかる。

＜３＞サーバ・クライアント共通
・Json　　JSで使いやすい形式(JavaScript Object Notation)。連想配列になる。 XMLより軽い。

＜Rmenu　サンプルソフト説明＞ ERGO 下山吉洋さん

インターネット上にLinuxサーバでデモサイトを立てました。PCをお持ちの方は実際の画面を操作しながら聞いてください。
http://125.206.227.76/Html/apps/Logon/index.html　　　 rmenu04/psrmenu04

＜１＞画面
　メニューの下から２つ目の「JsonEditorテスト」の下の「分類一覧表」です。画面の出方をよく見てもらうとわかるのですが、静的なHTMLを表示してからJavaScriptでデータを表示しています。ブラウザで入力したデータ項目も実行するとJavaScriptでJSON形式に組み立ててからAjaxでサーバに非同期送信します。　項目と項目の移動はタブだけでなくEnterキーでも移動します。
＜２＞MVC構造
　RmenuはMVC構造になっています。ブラウザとサーバとの間はJSONフォーマットで送受信しますが、サーバの内部はRubyの配列で送受信しています。

　　ブラウザ　→　コントローラ　→　モデル（ビジネスロジック）
　　　　　　　　　　　　　　　　　　　←　モデルの結果
　　　　　　　　　　　　　　　　　　　→　ビュー（回答組み立て）
　　　　　　　　　←　　　　　　　　　←　ビューの結果

＜３＞帳票
　バッチプログラムで、TeX→dvi→pdfと変換します。それをメニューの上から５つ目「帳票出力」の「帳票管理画面」から取り出します。　TeXライブラリーは4GBもあり遅いノートパソコンではインストールに一時間もかかります。軽い処理系のPXDocも使えます。
＜４＞分散バッチ処理
　例として実際の業務データを使った処理をお見せします。メニュー上から7つ目の「ジョブ管理」の「ジョブ管理画面」です。購買履歴3万件のポイント集計が誤っていないかを10分割してチェックするプログラムです。このデモはノートパソコン１台ですので10分割しても前の処理が終わってから動きますが、10台並べれば1/10の時間で終わります。
　バッチ処理ですので途中で異常終了したときのことを考えてリラン機能を持っています。分割数全部が終了したときに親のジョブステータスの終了時間がセットされます。
＜５＞製造方法
　まずは、１つの画面を作るときにどれだけの設定ファイルが必要なのかそれをどこに配置するのかを覚えてください。JSONをエディターで書くのは面倒ですので、EXCELで入力するとJSONファイルに変換するプログラムを公開しています。将来的には専用エディターを作ってリポジトリで管理させたいと考えています。
　フレームワークのプログラムは下地さんはエディターで書かれていますが、Eclipseで読み込むことも出来ます。手順はマニュアルに書きましたので興味のある方は見てください。
＜６＞純粋日本語プログラム
　今までは論理名と物理名という呼び方があり、論理名は日本語でも物理名は英字にすることが多かったと思います。仕様書は日本語で書いてあるのでプログラミングの時に表を見ながら物理名を探します。このRmenuは、データベース項目名も画面項目名まですべて日本語を使えるようになっています。この機能によって、Accessのシステムを移植しやすくなりました。

＜質疑応答＞

Ｑ：システム構築にはログイン認証だとか一覧データのページングだとか親子画面だとか色々な要素が必要になります。どこまでの機能が用意されているのでしょうか？
Ａ：何もありません。サンプルは提供していますが、お客様それぞれの要望に合わせて作るためのフレームワークという位置づけです。

Ｑ：帳票について、ある条件で色を変えるなどの制御は出来ますか？
Ａ：できます。このフレームワークはコールバック方式でRubyプログラムを呼べるようになっています。一ページごとに関数名を書いておけばそれを呼び出しますのでそこでアトリビュートを設定してください。
　※コールバック方式は、ハリウッドの原則とも呼ばれます

Ｑ：データベースは何が使用出来ますか？
Ａ：有名どころは、ほぼ何でも大丈夫です。Oracle,DB2,PostgreSQL,MySQL・・・

＜Rmenu　Webサイト＞
１．デモサーバ
http://125.206.227.76/Html/apps/Logon/index.html
　　 ID:rmenu@@ (@@=04～30） PW:psrmenu@@ (@@=04～30）

２．ドキュメント公開場所
http://rmenu.onas.asia/
　　トップページで随時アナウンスします
http://rmenu.onas.asia/archive
　　※2012.8現在のドキュメントです。随時変更されますのでご注意ください。
■CentOS-rmenuSetup.pdf(1478k) 　Linux用のセットアップ手順書
■Rmenu20120824.zip(1938k) 　Rmenu本体
■WinXp-rmenuSetup.pdf(6905k) 　Windows用のセットアップ手順書
■dbデータ.zip(2k) 　データベース初期セットアップ用データ
■rmenu20120824.doc(1973k) 　フレームワークの詳細な説明　★これを最初にお読みください
■rmenu20120824.ppt(3284k) 　デモサイト説明書（今回の説明資料）

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上

2010-08-18（水）関西ＩＴ勉強宴会の内容

DOAとXEAD　Driverに関する私的な想い

2010-09-15（水）関西ＩＴ勉強宴会の内容

2010-11-06（土）　－ＫＯＦ　関西ＩＴ勉強宴会の内容

2010-12-14（火）関西ＩＴ勉強宴会の内容

2011-01-14（金）関西ＩＴ勉強宴会の内容

2011-02-25（金）関西ＩＴ勉強宴会の内容

2011-03-18（金）関西ＩＴ勉強宴会の内容

情報処理学会誌４・５合併号

2011-04-22（金）XEAD Driver公開記念企画の内容

2011-06-03（金）関西ＩＴ勉強宴会

2011-07-08（金）第10回関西ＩＴ勉強宴会

2011-09-26（月）DOA+コンソーシアム関西分科会＆第11回関西IT勉強宴会

2011-10-28（火）第12回関西IT勉強宴会

2011-12-16（金）第13回関西IT勉強宴会

2012-01-13（金）第14回関西IT勉強宴会

2012-03-19（月）DAMA-Japan 大阪分科会　＆　第15回関西IT勉強宴会

2012-05-25（金）第16回関西IT勉強宴会

2012-06-29（金）第17回関西IT勉強宴会

2012-08-24（金）第18回関西IT勉強宴会

＜今回の勉強会資料＞

＜rubyでお手軽に帳票・バッチのある業務システムを作ろう＞

＜Rmenuの技術要素＞　下地忠史さん

＜Rmenu　サンプルソフト説明＞ ERGO 下山吉洋さん

＜質疑応答＞

＜今回の勉強会資料＞

＜rubyでお手軽に帳票・バッチのある業務システムを作ろう＞

＜Rmenuの技術要素＞ 下地忠史さん

＜Rmenu サンプルソフト説明＞ ERGO 下山吉洋さん

＜質疑応答＞

＜Rmenuの技術要素＞　下地忠史さん

＜Rmenu　サンプルソフト説明＞ ERGO 下山吉洋さん