ＤＲＩ通信６５号「要件定義」 ２００２．２．１
２００２年も不況下、田中外相の更迭があるなど、不穏な幕開けとなっていま
すが、皆様いかがお過ごしでしょうか。
一昨日弊社恒例のセミナーには８０名を超すご参加をいただき、２００１年の
トレンドやレガシーシステムの可視化などお話させて頂きました。レガシーシ
ステムの実態を弊社長谷川は、「巨大化・暗黒大陸・つぎはぎ・属人化・スパ
ゲッティ状態」と説明しておりましたが、「ＵＦＪ銀１８万件２８億円二重引
き落し」もいつどこで起きても不思議でない、われわれシステム関係者の抱え
る共通の難題として認識した次第でした。
６４号「保守の実態」に関して、コメントを頂いておりますが、次回に回し、今月は
昨年６月および８月に行われたＫ２Ｗでの議論も踏まえて、ＤＯＡの本題とも言える
「要件定義」について考察いたします。
情報システムに対するユーザの要求は、「所定のタイミングで出力される、所定の
データ項目を含む画面・帳票」ですから、情報システムはデータベースにストアさ
れたデータを部品とし、画面・帳票を製品とする組立加工製造業と見ることができます。
タイミングを記述するためには、たとえば生産所要数を含む生産計画表の出力に当たり、
これが販売計画表とどのような因果／前後関係にあるかなどを記述する必要があります。
このためには、弊社ＩＰＦチャートのような、画面・帳票を誰がいつ生成し何に用いる
かを示す、業務フロー図を用意する必要があります。
データ項目については、その意味を規定するために、その属性（Attribute）すなわち
所属するエンティティ（タイプ）と果たす役割を規定しなければなりません。これは部品
倉庫のどの棚のどの部品を使用するかを規定することに相当します。従来単にデータ項目名
を指定するだけで済ませてきたケースがありますが、一般にデータ項目名では属性がユニーク
には識別できず、かなり小規模のシステムを除いては曖昧性を残すことになります。
ここで案外軽視されているのが、エンティティの規定です。これも名前だけでは誤解を
招く場合が多々あります。Ａ社の「発注」や「購入先」と、Ｂ社の「発注」や「業者」が、
同様の管理対象を表しているか否かは、実際データモデル図によって確認するまでは、
安心できません。「Ａ社では生産材のみ、Ｂ社では事務用品まで含めて扱っている」
などということは多々あるからです。
こうしてわれわれは、要件定義（業務モデル、業務標準仕様ともいう）に関する基本４
ドキュメントとして
（１）ＩＰＦ（Information Process Flow）チャート
（２）画面・帳票イラスト（含まれるデータ項目の規定）
（３）概念ＤＢ構造図（データモデル図）
（４）データ項目定義書およびエンティティ定義書
を定めるにいたりました。（１）、（２）はユーザから見えるクライアント側の、主として
業務プロセスに関する要件を、また（３）、（４）は共用資源を一元管理する、主として業務
データに関するサーバー側の要件を規定することになります。
注）ここでの要件定義は、正確には製造要件確定レベルの要件定義で、企画書レベルの要件定義に
含まれるシステムの目的・狙いや対象範囲（業務・部門）、またコンピュータ化のための実装機能\n要件は別途存在するものとします。
こうしてソフトウエアを
ソフトウエア＝業務標準仕様＊ソフト化標準仕様
のように、独立して変化する２つの部分に分解し、開発・保守の合理化ができます。すなわち業務
標準仕様は、顧客満足のためのＢＰＲなどで変わりますし、ソフト化標準仕様はＩＴ／プラット
フォームの変化、機械効率、操作快適性、信頼性などで変わります。それぞれの変化のきっかけは
独立ですから、分割することによって、対応に要する作業量を大幅に減らすことができます。また
これらを電子化し、それぞれのリポジトリに記述することにより、大幅なソフト自動生成への道が
開けます。
このような説明をするとき、しばしば遭遇する質問は「そのような静的仕様だけではプログラムは
できない。動的仕様が抜けているのではないか」というものです。噛み合った議論による完全な
納得はまだ得られていないように思われますが、加工データやチェックデータ（加工データの１種）
についての記述に関する前提の違いに起因するものが大部分のように思われます。
たとえば入庫数と出荷数を加工元データとする在庫数を、また在庫水準を示す在庫ステイタスを考えます。
メタデータ規定（簡略版）の骨子は次のようになるものとします。
［加工データ］−（加工機能、 処理ロジック、 処理タイミング）
在庫数 Ｉ （在庫型） −（汎用） 即
在庫ステイタス Ｇ （不定型） ISTATUS 即
［加工データ．加工元データ］−（参照ＫＥＹ、 変数）
在庫数．入庫数 入庫品番＆入庫倉庫＃ １（＋）
在庫数．出荷数 出荷品番＆出荷倉庫＃ ２（−）
在庫ステイタス．在庫数 −（不要） −
在庫ステイタス．安全在庫数 − −
ここで加工機能＝Ｉは在庫型の加工データであり、加工元データさえ分かれば汎用ロジックで計算できる。
また＝Ｇは不定型なのでロジック名、この場合ISTATUSを起動することを規定する。ISTATUSとしては
（在庫数−安全在庫数）／安全在庫数を計算し、十分多ければ０、警告が必要なら１、自動発注なら
２などと計算し、メッセージ出力や（自動発注などの）プログラム起動を実行するものとする。
これらをリポジトリ上に記述することによって、動的と言われる仕様が十分記述できるのではないかと
考えます。上記在庫ステイタスはチェックデータとも言われる加工データです。在庫エンティティの
属性ですが、必ずしも物理ファイル上にある必要はありません。
データモデリングは本来概念レベルで考えるべきもののはずですが、ＳＱＬの弊害でしょうか、
物理ファイルの項目に限定して考え、動的仕様は別途扱わなければならないとの誤解を招いて
いるかに見えます。アメリカのＢＲＧ（Business Rules Group）にもこの誤解があるように
見えるのですがいかがでしょう。
われわれ人間は、したがってプログラムも、何らかの１個のデータに帰着して判断しています。
たとえばＡ＞Ｂをチェックしたいのであれば、Ｃ＝Ａ−Ｂが正であるか負であるかをチェックすれば良い。
Ａ、Ｂ、Ｃの関連をチェックするのであれば、Ｄ＝ｆ（Ａ，Ｂ，Ｃ）を計算し（このｆは処理ロジックとして定義される）、
これを評価することになります。複数のデータから計算され、プログラムのＩＦ文の中に一瞬現れる、
上記Ｄのようないわゆるチェックデータは、物理ファイル上には見えないでしょうが、概念データモデル上では、
あるエンティティの立派な属性として定義することができます。こうしてチェックデータも例外としてでなく、
加工データの一つとして統一的に単純化して扱うことができます。
業務標準仕様は元来ビジネスユーザのものです。情報技術の未熟−業務要件と情報技術の未分化−によって、
これまでシステム屋に取り上げられてしまっていましたが、２１世紀はこれをビジネスユーザに返すべきもの
と考えます。このためには業務標準仕様の変更・保守とソフト化標準仕様の変更・保守はそれぞれ別途行わな
ければなりません。
標準化は機械化のできない、人間の判断や関係者の調整を主体とする作業です。そして業務標準仕様の
大部分は、各社各様であり、お金を出して入手すべき性質のものではありません。自社で責任をもって造り、
ビジネス環境の変化に対応して維持管理しなければ、空洞化して企業の存立意義を損なう危険性を招来します。
ＥＲＰ導入にともなう作業の大部分も、実はこの業務標準仕様を策定するためのように思われます。
従来のプログラム開発のような力仕事ではありませんから、体制ができれば、コストは１／１０程度の
ものかと思われます。好況になれば、「拙速で良いから動くシステムを一日も早く」と、標準化は後回しに
なりますから、生き残るつもりの企業にとっては、むしろ不況時にこそ手掛けるべきものかと考えますが
いかがでしょう。
« 【第64号】保守の実態【第66号】第２のアンバンドリング »
