"実行可能な仕様書のライブラリ"を知的社会資本に：“実行可能な仕様書”を作る！（3）（2/3 ページ）

[渡辺 幸三，＠IT]

レファレンスモデルを使う

　「スクラッチ開発」でもなく「パッケージ・カスタマイズ」でもない第3の開発スタイル――それが「レファレンスモデルのカスタマイズ」である。

　「レファレンスモデル」とは、「1基の業務システムの完結した設計情報」のことだ。ただし、よく見かける「図書館蔵書管理システム」などのように、単純でありきたりなものではない。売掛・買掛・在庫を統合した販売管理システムや、所要量展開を伴う生産管理システムのように本格的なものでなければならない。それを実装すれば実用的な業務システムができ上がる、そんなものだ。これらが業種別に整備される必要がある。

　レファレンスモデルを用いた開発は次のように進行する。開発が始まるまでに、ネットから業務要件の似通ったモデルを見つけてダウンロードしておく（それは無償か格安であるべきだ）。分析・設計はこのモデルの検討から始める。「システムがそのようにでき上がったとしたら、ユーザー要件が満たされるかどうか」を回顧的にシミュレートしながらモデルをカスタマイズし、一挙に実装する。スクラッチ開発やパッケージ・カスタマイズと比べた場合の有利さは明らかだ（図1）。

	開発期間	開発費用	柔軟性
スクラッチ開発	長い	大きい	良好
パッケージ・カスタマイズ	短い	大きい	費用次第
レファレンスモデルの利用	短い	小さい	良好
図1　3つの導入方針の違い

　実務レベルのレファレンスモデルなどというものは、複雑膨大なノウハウの塊みたいなもので、これをまとめる作業の担当者には経験もスキルもいる。その有能さを個別案件の開発者が利用できるのである。この業界でよく言われるように、レファレンスモデルを用いることは「巨人の肩に乗って遠くを眺める」ような顕著なレバレッジ効果をもたらす。

　ところが、そういうものは本来ならとっくの昔に整備されていて良いのに、なぜか現在でもまともに流通していない。次から次に新しいモデリング手法や開発手法、洗練された管理ツールが登場するわりに、開発事例を汎用化して整理したレファレンスモデルがいっこうにまとめられない。今日もまた「業務システムというものは1つ1つがユニークなものだ」という信念に基づいて、労多く実り少ないスクラッチ開発がそこらじゅうで繰り返されている。結果的に、必要以上のコストとリスクが経済社会に押し付けられたままだ。

　それを「SI企業や方法論者たちの怠慢」などと糾弾するのは簡単だが、糾弾するだけで事態が変わるほど世の中は甘くない。そこで私はレファレンスモデルを自力でまとめる活動を始めた。社会貢献になるし、何よりも自分が提唱する分析設計手法「三要素分析法」の有効性を証拠立てるものになると考えたからだ。

関連リンク：分析設計技法「三要素分析法」集中講座（＠IT情報マネジメント）

　それは4年がかりの気の長いプロジェクトになった。最初にやったのは、データモデルや業務フローを閲覧・編集するためのモデリングツール「XEAD Modeler」を開発することだった。その後、基本設計情報を少しずつまとめた結果、現在では以下のようなレファレンスモデルが「CONCEPTWARE（コンセプトウェア）」の製品シリーズとして公開されている。モデリングツールもモデルも無料なので、皆さんも必要に応じて参考にしてほしい。UMLなど他の分析手法向けに翻案することも大歓迎だ。

• 財務管理システム
• 専門卸売業向け販売管理システム
• 組立型生産管理システム
• 教務管理システム
• 自治体システム

　参考までに、「CONCEPTWARE／販売管理」の発注回りのデザインをXEAD Modelerで眺めた様子を紹介しよう（図1〜3）。

図2　XEAD Modelerで眺めた「CONCEPTWARE／販売管理」の発注回りのデザイン（1）（クリックで拡大）

図3　XEAD Modelerで眺めた「CONCEPTWARE／販売管理」の発注回りのデザイン（2）（クリックで拡大）

図4　XEAD Modelerで眺めた「CONCEPTWARE／販売管理」の発注回りのデザイン（2）（クリックで拡大）

　蛇足だが、私には「ウォーターフォール」か「アジャイル」かの怨念に満ちた対立も、両陣営がスクラッチ開発を前提としている限り、子供のケンカにしか見えない。そのような議論以前にやるべきことがある。守秘義務に抵触しない形でモデルを汎用化し、社会に還元することだ。開発スタイルの違いよりも、レファレンスモデルが欠落していることの方が、業界や社会にとっての悪影響が大きいからだ。