[ThinkIT] 第3回：DOAを進めるためのミニマムセット (1/3)

TOP＞プロジェクト管理＞システム開発におけるドキュメントのあり方

DOAとは何か！〜開発現場から見るDOA〜

第３回：DOAを進めるためのミニマムセット
著者：システムズ・デザイン DOA推進ワークショップ 2007/5/23

1 2 3 次のページ

システム開発におけるドキュメントのあり方

   システム開発に携わる方なら「決められたドキュメントを作成したけど、それが何に使われたのかよくわからない」や「たくさんのドキュメントを作成したけど、本番リリース後にはほとんど読みもしない」といった経験をしたことがあると思います。

   特に上流工程のドキュメントは、設計者とユーザ、そして設計者と製造者との間のコミュニケーションツールといえます。このコミュニケーションツールという側面をしっかり認識し、ドキュメント作成が設計者の自己満足で終わってしまわないように、作成の目的や役割を理解した上で着手する必要があります。

   このようなドキュメントはコミュニケーションツールですから、技術や知識の少ない人にもわかりやすいものになっている必要があります。特にDOAの現場では、多少の差はあるものの、上流工程で必要とされるドキュメントの種類は決まっています。その例として「第1回：DOAを採用した現場の実態とは」において掲載した成果物一覧を表1に再掲します。

工程	ドキュメント成果物	備考
要件定義	要件／機能対応一覧
	システム概念図	当該システムと周囲の関連システムの連関を図示
	論理DFD	基本フロー、基本的概念
	業務フロー	基本フロー、基本的概念
	画面／帳票一覧
	システム構概要	当該システムのハードウェア、ファームウェア構成
	システム資源概算見積り
外部設計	論理DFD	詳細フロー、仕様レベル
	業務フロー	イベントフローレベル。基本、例外、拡張、エラー処理を記載
	プロトタイプ画面／帳票イメージ
	画面／帳票説明書
	画面遷移図
	ER図
	データ項目定義書	全項目のアクセス名、項目名称、属性、桁型、意味などを記載
	物理DFD
	処理機能記述書
	CRUDマトリックス
	ユーザ／グループ一覧	ユースケースのアクタ一覧に同じ
	権限マトリックス	画面ごとのユーザ／グループの割り当てを検討した対応表
	非機能要件書	適用技術、稼動環境、LAN・WANセキュリティ要件など
	移行・運用設計	移行対象、移行方法、運用方法、運用上の制約など

表1：成果物一覧（再掲）

今回は、上記の観点を踏まえた上で、データモデリングの前段としての「要件一覧（要件整理表）」と「業務フロー」、そして従来からDOAで一般的にあつかわれているものとして「DFD（データフローダイアグラム）」と「ER図（以下、データモデルと表現）」「CRUDマトリックス」の計5つのドキュメントについて、その役割やあり方などについて筆者の経験から述べていきます。

要件一覧（要件整理表）

   設計者側には、ユーザの要件を体系化して整理したり、不足を補うことが求められます。ユーザからだされた要件項目は粒度も粗く、あいまいな表現が多く含まれており、暗黙的要件も多く存在します。

   設計者側がイメージをふくらませて設計を行った結果、ユーザがイメージしていたものとの違いから、多くの要件漏れや仕様の食い違いが発生しています。実際の現場で、「ユーザのいう通りに作ったら」や「ユーザが要求しなかったから（いわなかったから）」などの言葉を耳にされた方も多いでしょう。

   要件一覧においては「ユーザ要件が設計にどう反映されるかを明確に想定できる」というレベルまで詳細に記述することを目標とします。設計を進める過程で要件を補っていくことは、極力、少なくしなければなりません。

   ユーザ要件を整理する際は、ユーザの要望を漫然と一覧に記述するだけでは不十分です。要件を階層化し、表2のような「FURPS」のカテゴリに分割してヒアリングを進めていくことが効果的です。

機能要求	F（Functionality）
非機能要求	U（Usability、使いやすさ）
	R（Reliability、信頼性）
	P（Performance、性能）
	S（Supportability、サポートしやすさ）

表2：FURPSのカテゴリ

このように整理しておくことで、要件にみやすさが生まれ、要件に対する優先順位を付けやすくなります。また、要件間の不整合を発見しやすくなるといった利点もあります。

しかし、納期との兼ね合いを考慮すると、すべてを均一に詳細化する必要はありません。大切なのは「ユーザ側と設計者側でコンセンサスが得られていること」です。両者の間で自明の事項であれば、粒度の粗いままでもかまいません。例えば、標準のフレームワークが存在するのであれば「フレームワークに沿った操作性に準拠する」という記述で、非機能要求に応えられるケースもあるでしょう。

1 2 3 次のページ

著者プロフィール
システムズ・デザイン株式会社 DOA推進ワークショップ
ビジネス解析方法論であるDOAと、開発プロセス方法論であるRAD、ウォーターフォール、UPなどを現場の最前線で適用している技術者を中心に開設した、sdc独自のワークショップ。PDCAサイクルを回して、さらなる進化と「確かなモデリング∧確かな開発プロセス→いい仕事」の可能性を追求する。

INDEX
第3回：DOAを進めるためのミニマムセット
	システム開発におけるドキュメントのあり方
	業務フロー
	データモデル