» 【第65号】要件定義

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第65号】要件定義

DRI通信65号「要件定義」 2002.2.1
2002年も不況下、田中外相の更迭があるなど、不穏な幕開けとなっていま
すが、皆様いかがお過ごしでしょうか。
一昨日弊社恒例のセミナーには80名を超すご参加をいただき、2001年の
トレンドやレガシーシステムの可視化などお話させて頂きました。レガシーシ
ステムの実態を弊社長谷川は、「巨大化・暗黒大陸・つぎはぎ・属人化・スパ
ゲッティ状態」と説明しておりましたが、「UFJ銀18万件28億円二重引
き落し」もいつどこで起きても不思議でない、われわれシステム関係者の抱え
る共通の難題として認識した次第でした。
64号「保守の実態」に関して、コメントを頂いておりますが、次回に回し、今月は
昨年6月および8月に行われたK2Wでの議論も踏まえて、DOAの本題とも言える
「要件定義」について考察いたします。
情報システムに対するユーザの要求は、「所定のタイミングで出力される、所定の
データ項目を含む画面・帳票」ですから、情報システムはデータベースにストアさ
れたデータを部品とし、画面・帳票を製品とする組立加工製造業と見ることができます。


タイミングを記述するためには、たとえば生産所要数を含む生産計画表の出力に当たり、
これが販売計画表とどのような因果/前後関係にあるかなどを記述する必要があります。
このためには、弊社IPFチャートのような、画面・帳票を誰がいつ生成し何に用いる
かを示す、業務フロー図を用意する必要があります。
データ項目については、その意味を規定するために、その属性(Attribute)すなわち
所属するエンティティ(タイプ)と果たす役割を規定しなければなりません。これは部品
倉庫のどの棚のどの部品を使用するかを規定することに相当します。従来単にデータ項目名
を指定するだけで済ませてきたケースがありますが、一般にデータ項目名では属性がユニーク
には識別できず、かなり小規模のシステムを除いては曖昧性を残すことになります。
ここで案外軽視されているのが、エンティティの規定です。これも名前だけでは誤解を
招く場合が多々あります。A社の「発注」や「購入先」と、B社の「発注」や「業者」が、
同様の管理対象を表しているか否かは、実際データモデル図によって確認するまでは、
安心できません。「A社では生産材のみ、B社では事務用品まで含めて扱っている」
などということは多々あるからです。
こうしてわれわれは、要件定義(業務モデル、業務標準仕様ともいう)に関する基本4
ドキュメントとして
(1)IPF(Information Process Flow)チャート
(2)画面・帳票イラスト(含まれるデータ項目の規定)
(3)概念DB構造図(データモデル図)
(4)データ項目定義書およびエンティティ定義書
を定めるにいたりました。(1)、(2)はユーザから見えるクライアント側の、主として
業務プロセスに関する要件を、また(3)、(4)は共用資源を一元管理する、主として業務
データに関するサーバー側の要件を規定することになります。
注)ここでの要件定義は、正確には製造要件確定レベルの要件定義で、企画書レベルの要件定義に
含まれるシステムの目的・狙いや対象範囲(業務・部門)、またコンピュータ化のための実装機能\n要件は別途存在するものとします。
こうしてソフトウエアを
ソフトウエア=業務標準仕様*ソフト化標準仕様
のように、独立して変化する2つの部分に分解し、開発・保守の合理化ができます。すなわち業務
標準仕様は、顧客満足のためのBPRなどで変わりますし、ソフト化標準仕様はIT/プラット
フォームの変化、機械効率、操作快適性、信頼性などで変わります。それぞれの変化のきっかけは
独立ですから、分割することによって、対応に要する作業量を大幅に減らすことができます。また
これらを電子化し、それぞれのリポジトリに記述することにより、大幅なソフト自動生成への道が
開けます。
このような説明をするとき、しばしば遭遇する質問は「そのような静的仕様だけではプログラムは
できない。動的仕様が抜けているのではないか」というものです。噛み合った議論による完全な
納得はまだ得られていないように思われますが、加工データやチェックデータ(加工データの1種)
についての記述に関する前提の違いに起因するものが大部分のように思われます。
たとえば入庫数と出荷数を加工元データとする在庫数を、また在庫水準を示す在庫ステイタスを考えます。
メタデータ規定(簡略版)の骨子は次のようになるものとします。
[加工データ]−(加工機能、 処理ロジック、 処理タイミング)
在庫数 I (在庫型) −(汎用) 即
在庫ステイタス G (不定型) ISTATUS 即
[加工データ.加工元データ]−(参照KEY、 変数)
在庫数.入庫数 入庫品番&入庫倉庫# 1(+)
在庫数.出荷数 出荷品番&出荷倉庫# 2(−)
在庫ステイタス.在庫数 −(不要) −
在庫ステイタス.安全在庫数 − −
ここで加工機能=Iは在庫型の加工データであり、加工元データさえ分かれば汎用ロジックで計算できる。
また=Gは不定型なのでロジック名、この場合ISTATUSを起動することを規定する。ISTATUSとしては
(在庫数−安全在庫数)/安全在庫数を計算し、十分多ければ0、警告が必要なら1、自動発注なら
2などと計算し、メッセージ出力や(自動発注などの)プログラム起動を実行するものとする。
これらをリポジトリ上に記述することによって、動的と言われる仕様が十分記述できるのではないかと
考えます。上記在庫ステイタスはチェックデータとも言われる加工データです。在庫エンティティの
属性ですが、必ずしも物理ファイル上にある必要はありません。
データモデリングは本来概念レベルで考えるべきもののはずですが、SQLの弊害でしょうか、
物理ファイルの項目に限定して考え、動的仕様は別途扱わなければならないとの誤解を招いて
いるかに見えます。アメリカのBRG(Business Rules Group)にもこの誤解があるように
見えるのですがいかがでしょう。
われわれ人間は、したがってプログラムも、何らかの1個のデータに帰着して判断しています。
たとえばA>Bをチェックしたいのであれば、C=A−Bが正であるか負であるかをチェックすれば良い。
A、B、Cの関連をチェックするのであれば、D=f(A,B,C)を計算し(このfは処理ロジックとして定義される)、
これを評価することになります。複数のデータから計算され、プログラムのIF文の中に一瞬現れる、
上記Dのようないわゆるチェックデータは、物理ファイル上には見えないでしょうが、概念データモデル上では、
あるエンティティの立派な属性として定義することができます。こうしてチェックデータも例外としてでなく、
加工データの一つとして統一的に単純化して扱うことができます。
業務標準仕様は元来ビジネスユーザのものです。情報技術の未熟−業務要件と情報技術の未分化−によって、
これまでシステム屋に取り上げられてしまっていましたが、21世紀はこれをビジネスユーザに返すべきもの
と考えます。このためには業務標準仕様の変更・保守とソフト化標準仕様の変更・保守はそれぞれ別途行わな
ければなりません。
標準化は機械化のできない、人間の判断や関係者の調整を主体とする作業です。そして業務標準仕様の
大部分は、各社各様であり、お金を出して入手すべき性質のものではありません。自社で責任をもって造り、
ビジネス環境の変化に対応して維持管理しなければ、空洞化して企業の存立意義を損なう危険性を招来します。
ERP導入にともなう作業の大部分も、実はこの業務標準仕様を策定するためのように思われます。
従来のプログラム開発のような力仕事ではありませんから、体制ができれば、コストは1/10程度の
ものかと思われます。好況になれば、「拙速で良いから動くシステムを一日も早く」と、標準化は後回しに
なりますから、生き残るつもりの企業にとっては、むしろ不況時にこそ手掛けるべきものかと考えますが
いかがでしょう。