IT勉強宴会

深層学習の概要とドメインモデル<第53回IT勉強宴会>

2017.2.4(土)に新大阪で開催しました。
ブログはこちら
--------
2010年から日経コンピュータのレビューを書いています。 過去記事の検索にも便利です。
http://ameblo.jp/hatsanhat

IT勉強宴会は、データモデリングを主体とした上流工程の実践者が集まっている勉強会です。

趣旨

主催者は前職で大きなトラブルに何度か呼ばれて火消しをお手伝いしたことがあります。その後も気になり社内を調べると共通点がありました。それは炎上プロジェクトのすべてがデータモデルを作らず画面や帳表だけでお客様と要件確認をしてたという事です。
今でもそういうプロジェクトは多いと思います。見通しの利く程度の大きさのプロジェクトや、過去に経験した業務ならそれでも何とかなるでしょうが危うい方法です。

【どんな手法でも良いのでモデリングしましょう】

これを伝えることが当IT勉強宴会の目的です。

2004年ごろ東京出張中のホテルで読んだ生産管理・原価管理システムのためのデータモデリングという本にあまりに感激したため生まれて初めて著者紹介欄を見てファンメールを送りました。それがご縁で著者の渡辺幸三さんと、ほぼ毎月1度は飲みに行くようになりました。その時に様々な設計手法の議論や最新技術の話をしていました。主催者の退職をきっかけとしてこの飲み会を発展させるような形で飲み仲間にお手伝いいただきながら続けているのがIT勉強宴会です。

※データモデリングの方法論を詳しく知りたい方は次のブログをご参照ください。
DOAとXead Driverに関する私的な想い

・当勉強会がウェブメディア「カンパネラ」で紹介されました(2014.10)

2015年9月6日日曜日

メンバー紹介①渡辺幸三さん◆レファレンスモデルの役割

渡辺さんは、業務システムの設計手法「三要素分析法」の提唱者で、三要素分析法に基づいた設計ツール「X-TEA Modeler」および、設計情報にもとづいてアプリケーションを実行するための基盤「X-TEA Driver」を開発・公開されています。また、さまざまな設計データを「レファレンスモデル」として公開されています。自宅近くの居酒屋さんで話を伺いました。

◆設計スキルを底上げするための教材として

―「レファレンスモデル」を公開することの意義についてお聞かせください。業務システムの設計情報を公開するというのはあまり聞かない話ですが、なぜこのような取り組みをされているのでしょうか。

まず、業界全体の設計品質を底上げする必要があると考えるからです。ユーザ企業にとって、業務システムの開発は未だに高価でリスクの高いものです。さまざまな要因があるでしょうが、まずは設計技術を向上させることで状況は改善されると考えています。

新しいシステムを新規で開発するとき、多くの現場ではゼロから設計しています。しかし、業務システムの設計において、プロジェクトに固有な条件はあるものの、共通する設計課題も少なくない。こうした課題は、先人の知恵をそのまま借りたほうが効率的に解決できます。
―確かに、簡単な例で言えば、ユーザや組織の管理といったモジュールはどのシステムでも必須ですから、そういった箇所はすでに実績のあるモデルを使ったほうが効率的なのでしょうね。

そうです。建築の分野では多くの設計情報が公開されていますが、システム開発の分野では入門レベル程度のものしか見あたりません。レファレンスモデルはそういう状況を改善してくれます。

◆方法論の有効性を示すための素材として

レファレンスモデルを公開する2つめの理由は、設計手法を評価するための素材になると考えるからです。

―渡辺さんご自身も「三要素分析法」という設計手法を提唱されています。

業務システム開発向けの設計手法はいろいろあります。選択肢があったほうが良いのでしょうが、ユーザ企業が実験台になるべきではありません。その前に手法の有効性を検討できたほうがいい。その枠組みに沿って記述された設計事例や実システムが公開されていれば、第三者でも方法論の有効性を事前に検証できます。

―開発視点で考えると「どのようなプロセスか」という点に興味がかたよりがちですが、当然ながら一番大事なのは「どういうものが作れるか」ですよね。

「どういう事例を支えられるか」ですね。たとえば音楽を記述するための枠組みがあるとします。その有効性は、いかに多彩な楽曲を記述できるかで検証できます。じっさいにそのように検証されて、現在の楽典の体系がメジャーになりました。しかし、システム開発の枠組みに関しては、そういう視点が欠けている。「こういうやり方(書き方)がいい」という主張には、そのやり方(書き方)でまとめられた事例の数々がレファレンスとして添えられるべきです。

◆モデル駆動の枠組みを探る

3つめの理由は、「モデル駆動の枠組み」を探るための素材になるというものです。ソフトウエア開発には、飛行機や建築物と違って資材が要りません。だから、設計情報そのものが動作可能であるという面白い特性があります。レファレンスモデルそのものをソフトウエアとして動作させられるか。そういうことを考える素材になってくれます。

―渡辺さんはじっさいにそのような枠組みをX-TEA Driverとして公開されていますね。

音楽の楽典の例といっしょなんです。音楽の記述体系として適切ならば、その体系にもとづいて機械に演奏させることができる。五線譜で書けばそのまま演奏してくれる音楽ソフトはいろいろありますよね。ソフトウエアもいっしょで、「こういうやり方(書き方)がいい」という枠組みがあれば、その体系で記述された内容にしたがってコンピュータが動作する基盤が遅かれ早かれ出現するはずです。

―開発方法論を提唱するということは、第三者がその有効性を検証できるようないろいろな素材を添える責任をともなっているということですか。

そういう責任がないなら、誰だって明日から方法論者になれますよね。そういう素材をいろいろと提示できるという点で、私はプログラマであって良かったと思っています。まあプログラマとしては、同じ勉強宴会のメンバーである久保さんに比べたら恥ずかしいようなレベルなんですが。

―今日はどうもありがとうございました。


渡辺さんのサイト
http://homepage2.nifty.com/dbc/index.html

2015年2月15日日曜日

花束問題のしおり

花束問題をしおりとして製本できるように編集してみました。

MS WORDをお持ちの方はDOCの方をダウンロードしてご自分のメモなどを追加して下さい。データモデルに興味にある方は正規化の資料などをいれても良いでしょう。UMLの表記法を入れても参考になるでしょう。

https://drive.google.com/file/d/0BykMR9FfFyLOSF85MjdyVUluV0E/view?usp=sharing

段組みが特殊なので、WORD互換のエミュレータではくずれるかも知れません。そのためにPDF版を用意しました。

https://drive.google.com/open?id=0BykMR9FfFyLORVlLU2czY1dJUkk&authuser=0


<しおりの作り方>
1.全部のページ(4ページ)を印刷する
2.全部を印刷面を表にして2つ折りする
3.1ページめが表表紙/裏表紙になるように全体をおおう

わかるとは思いますが、図を書きました。

このフォーマットは旅のしおりをつくるのに重宝しています。

2015年1月26日月曜日

花束問題V1.2

=========================================================================
当問題は、IT勉強宴会(http://www.benkyoenkai.org)の例題として作成しました。
著作権は著者に帰属しますが、この注意書きを含め全体であれば無料で自由に再配布する事を許可します。部分変更したい場合は全体の配布とは別に変更部分を配布して下さい。
 配布方法は著作物、メール、WEBを問わず自由です。
                           2015.01.22 佐野初夫
-------------------------------------------------------------------------
【花束配送問題(V1.2)】
ロットと在庫推移(日別の在庫数)の管理が必要な、比較的複雑な業務要件にもとづくモデリング手法比較用の標準問題。

■事業と問題の概要
フラワーショップ「フレール・メモワール」は店舗売りとは切り離してWEBショップ事業を立ち上げた。WEBで注文を受け付けて、指定された日付に指定場所に花束を届けるという形態。
当初は受注も少なく手作業で管理出来ていたが、受注が増えるにつれシステム化の必要性が出てきた。「新鮮な花を大切な記念日に」を売り文句にしていることもあって、廃棄される在庫が多く、受注の増加にともなって利益が伸びていないため。

■回答方法
このビジネスのために、効率的な仕入・販売を支援する業務システムのモデル(回答者が通じている手法においてまとめられる各種図面)を作図する。当然ながら、実際のヒアリングでは、あらかじめ謳われている要件以外の要望やアイデアがいくらでも出てくるものなので、大きく逸脱しない限り、適宜ユーザ要件を補ったり修正してもかまわない。ただし、その際にはどのような補足や修正がなされたかをその意図とともに明示すること。

■文書化されているユーザ要件
///商品と在庫///
①花束の組み合わせは事前に「商品」として決めうちされている。1個の商品あたり、どの「単品(後述)」がどれだけ必要かも決められている。シングルレベルしかない部品表のようなもの。単品の在庫も含めて、保管場所は1箇所で、これが増える予定もない。

②花束の材料となるそれぞれの花は「単品」として管理される。「単品」はそれぞれ特定の仕入先から購入され、単品毎に品質維持可能日数が決められている。購入後にその日数を超えると結束には利用できずに廃棄されなければならない。なお、受注・出荷されるものは「商品」のみであって、単品がそのまま出荷されることはない。

///得意先と受注・出荷///
③リピータを期待するので、得意先(個人のみ)情報を管理したい。届け先は毎回違う可能性があるが、前回の受注情報から届け先を簡単にコピーできるような機能は欲しい。

④1回の受注で、1箇所の届け先に対する1種類の商品1個を、「届け日」と「お届けメッセージ」、「お届け先電話番号」とともに受け付ける。出荷日は届け先に関係なく届け日の前日とする。

⑤いったん受注を受けてから、届け日の変更が要望されることがある。その際には可能な限り変更に対応できるようにしたいが、指定日に出荷変更できないようならばその旨を顧客に直ちに伝えられるようでなければならない。

⑥単品を結束して商品(花束)にするための工程は十分に効率化されていて、材料さえあれば一瞬で結束可能とみなしてよい。したがって、出荷日当日に結束指示すれば出荷可能である。

///発注と入荷///
⑦単品を発注する際、単品毎に発注リードタイム(入荷されるまでにかかる日数)が異なる。発注リードタイムさえ越えていれば、どんな将来の入荷向けの単品も発注可能だし、入荷日の変更要望も受け付けてもらえる。

⑧「単品」毎に購入単位数が決まっている。たとえば、50本必要だとしても、購入単位が100本ならば100本買わなければならない。なお、仕入先の供給能力は十分かつ、納期も正確とみなしてよい。

⑨発注の判断は、在庫推移(日別の在庫予定数)をみながら人間が行う。したがって、自動発注処理を考える必要はない。

///代金の扱い///
⑩IDの登録の際にクレジットカード情報を入れるため請求や入金に関しては考慮する必要はない。

⑪入荷の実績情報があれば処理できるので、仕入先への支払に関しても考慮する必要はない。

///現状の画面・帳票///
⑫添付資料(花束問題伝票V1.0.ppt)のとおりであるが、現状のままでは使いにくいと感じているため、ユーザとしては全面的に刷新してもかまわないと考えている。

以上


sample001

sample002

sample003

sample004

sample005

sample006

sample007

-----------------------------------------------------------------