NPO法人　IT勉強宴会

IT勉強宴会タイトル

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

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

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

まず、業界全体の設計品質を底上げする必要があると考えるからです。ユーザ企業にとって、業務システムの開発は未だに高価でリスクの高いものです。さまざまな要因があるでしょうが、まずは設計技術を向上させることで状況は改善されると考えています。 新しいシステムを新規で開発するとき、多くの現場ではゼロから設計しています。しかし、業務システムの設計において、プロジェクトに固有な条件はあるものの、共通する設計課題も少なくない。こうした課題は、先人の知恵をそのまま借りたほうが効率的に解決できます。

―確かに、簡単な例で言えば、ユーザや組織の管理といったモジュールはどのシステムでも必須ですから、そういった箇所はすでに実績のあるモデルを使ったほうが効率的なのでしょうね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


＜しおりの作り方＞
１．全部のページ（４ページ）を印刷する
２．全部を印刷面を表にして２つ折りする
３．１ページめが表表紙／裏表紙になるように全体をおおう

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上









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