» 【第50号】要件定義の品質保証

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

DRI通信50号「要件定義の品質保証」2000.11.1
ON対決が終わり晩秋を迎えます。スキーシーズンを前に、ジョギングにも気
合が入ります。景気はいまいちですが、IT関係ということで、ご多忙のこと
かと思います。風邪に気を付けて冬を迎えましょう。
先月は、「データとプロセス」と題してデータを明示する図や表の生産性を
説明いたしました。これに対してコンサルタント戸田さんから、次のような
コメントが寄せられました。
<コメント 氏名=‘戸田忠良’>
データとプロセスの関係は、どの視点で見るかにより大きく変化します。もの
の世界に例えれば、製品を製造する工場のライン側で見るのか、加工されて製
造される製品側で見るのかの問題です。
当論文でも指摘されていますように、組織は処理の集合体であり、従って、
業務組織の構成員からのインタビューは、当然ながら「プロセス中心」となら
ざるを得ないと思います。彼らの視点は、工場で言えば製造ライン側の製品を
組立・加工する側の視点であり、そのための手順が発言の中心となるのは、こ
れもまた自然なことです。
そして、現在の基幹系システムは、業務担当者の視点のシステム化ですから、
プロセス中心にならざるを得ないのはいわば、一種の宿命ではなかったかと思
います。


ですから、データから見るということは、その視点を製品の側に移し、その
製品の作り方を整理すると言う形式になるはずです。その意味で、本論文中に
ある概念DB構造図は料理で言えば「レシピ」に当るものです。
料理と言う最終的に欲しい処理の結果から、それを作るプロセスを材料とと
もに論述するのがレシピであり、つまり、それは概念DB構造図の示すものに
該当するのではないかと思います。
人間が情報処理の機能を全面的に行っていたのが、つい最近までであること
を考えると現段階でプロセスから見る癖が残るのはある意味でやむを得ないと
思います。しかし、今後永久に続くはずのコンピュータによる情報処理時代で
は、人間が欲しいのは製品としての画面・帳票となるので、その作り方のレシ
ピは何?となっていくのではないでしょうか。
そのような理由で、データから見る情報処理の整理が主流となるのがそんなに
遠い日ではないように思うのですが、いかがでしょうか。
</コメント>
■要件定義の品質
さて今月は、しばしば聞かれる質問「要件定義すなわち上流工程成果物の品質
はどうすれば上がるか、どのようにして品質保証をすればよいのか」について
考えます。事の性質上、当然性能要件やコスト要件は除いて機能要件のみを考
えます。下流工程成果物の品質保証はテストによって行われますが、上流工程
成果物についてはそれまで待てませんから、機械の力を借りるとしてもドキュ
メントに基づいて人間が行うことになります。
ドキュメントとしては、筆者の提案する要件定義基本4ドキュメント、すなわち
(1)IPFチャート
(2)IOイラスト
(3)概念DB構造図(業務データ関連図)
(4)データ項目定義書
について、この品質を保証することを考えます。
品質とは、「ユーザの要求を満たすものであること」、「抜けのないこと」、「矛
盾のないこと」とします。標準部品から構成し「柔軟性」を持たせることは、
すでに方法論として保証されていると言う前提があるものとし、ここからは除
外します。
■IPFチャート
IPFチャートの品質としては、文法違反は論外として
・ 必要なすべてのIOが、要求されたタイミングで作られるべく表現されている
・ 不要なIOが作られたり送付されたりしていない
・ そのIOを作るための素材が事前に与えられている
・ その業務プロセスをスタートさせるための実現可能なトリガーが与えられている
をチェックすればよいでしょう。
■IOイラスト
IOイラストについては、必要十分なデータが表現されていることをチェック
します。いくつかのサブタイプに対応するIOのときは、抜けが発生しやすい
ので、注意が必要です。
■概念DB構造図
概念DB構造図の品質保証が一番の難題です。ツールを使って書けば格好は
できますが、「ただ書いただけ、品質がボロボロ」では意味がありません。
データ項目の抜けは、IOとそのイラストに抜けが無ければ、
・ 正しく正規化を行う
・ 同音異義語を区別する
・ 混合コード(1:営業かつ管理職など)を分解する
・ 加工元データを追いかける
ことによって防げます。
■重複による不整合
むしろデータ項目の重複による不整合の方が問題でしょう。同義語や「顧客」、
「取引先」、「届先」など表現は違うが共通部分をもつエンティティやデータ項
目の整理が必要になります。一般には集合の大きさや、従属項目にずれがあり、
サブタイプを切り出して、同一部分と相違部分とを明示することになります。
異なった業務に関わる人たちの文化を反映しているため、その整理は利害の調
整を含む難しいものになる場合があります。
企業合併などのときは、同じデータ項目に異なったデータ項目名がついている
ことが多々あります。データ項目は、あるエンティティの属性ですから、その
異同を判定するときは、先ずどのエンティティに属するものかを考えます。こ
れが同じ時は、次にその役割、「・・が」、「・・を」などを考えます。エンテ
ィティも役割も同じなら、ほとんどの場合、同じデータ項目と考えて良いはず
です。
■データ項目間の不整合
重複が無い場合、不整合には
・ KEY−RKEY間の不整合
・ 加工データ−加工元データ間の不整合
があります。KEY−RKEY間の不整合についてはツールのサポートが得ら
れます。加工データ−加工元データ間の不整合はデータ定義で規定しますが、
これをもれなく行うために、まず概念DB構造図上に、たとえば<在庫数量>
のように、加工データを表すマークをつけます。
加工データの導出過程を厳密に記述するために、結合・要約・加工・抽出など
11種の操作からなるSPF(Schema Process Flow)チャート記法が用意さ
れていますが、80%の加工データは、これを頭の中で実行し、概念DB構造
図上でトレースできると思います。
個性的なエンティティ、たとえば「社員」、「契約」などには多くの観点でのサ
ブタイプが含まれており、どこまで表現すべきか明確な基準が作れません。
筆者は現在、「加工データ分析を行って、『加工ロジックが違うとして扱いたい
ものを、違うデータ項目として定義できる』ところまでサブタイプとして表現
する」という基準を提案しています。加工データ分析に関わらないサブタイプ
を表現しても、さほどメリットが感じられないからです。
PLAN−DBではデータモデリングの中で、加工データ分析を行い、加工ロ
ジックを異にするサブタイプを明示しますが、これはIF文対応のロジックに
かかわる管理対象レコードを、データモデリング段階に識別することを意味し
ます。このためプログラム設計段階になって、データ項目や、これを切り出す
ためのサブタイプコードを追加変更することがなくなります。データモデリン
グの負荷はやや増えますが、後工程でのやり直しがなくなり、トータルには
生産性が向上する、という計算です。
データベースの整合チェックとして、複数のデータ項目間の論理的関係を挙げ
る人がいますが、これは、それらのデータ項目を加工元とする加工データを
定義すれば、前述の加工・加工元データの整合性の問題として扱うことができ
ます。たとえば、「在庫数が安全在庫を超えていること」であれば、余裕在庫
=在庫数−安全在庫、あるいはこれが正であるか否かの論理値を定義し、この
値の制約をチェックすればよいのです。これをわれわれはチェックデータ
(加工データの一種)と呼んでいます。このようなデータは物理ファイルには
持たなくても、プログラム上には登場し、これに基づいてメッセージが出され
たりしているはずです。物理データベースの発想からは見えにくいデータ項目
かもしれませんが、概念データベースでは当たり前のデータ項目です。
■データ項目定義書
データ項目定義書は、図で表現しきれない要件定義を分担することになります。
定義必須なのか、ヌルでもよいのか、値の範囲はどう制約されるのか、対応す
るKEYや定義域は何か、またそれがサブタイプに依存する場合はそのサブタ
イプ条件などが、データ項目ごとに規定されることになります。加工データの
場合は加工元データとの関係や加工ロジックが記述されます。
これらの要件定義は、すべて情報システムの成果物であるIOの仕様
「WHAT」から導出されたもので、基本的に個人差は出ないはずのものです。
しかしIOの作り方「HOW」はハード・ソフト環境やプログラマの好みに
よって変化する可能性があります。すなわち「WHAT」と「HOW」の間に
はある遊びがあるわけです。プロセス中心アプローチにはこの遊びを固定して
しまう欠陥があるように思われます。