「いつまでたってもユーザーインタフェースが決まらない」「テスト段階に入ってからも仕様変更が多発する」――。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。要件定義のやり方にそもそもの問題がある。

中山裕美子(なかやまゆみこ)
日本アイ・ビー・エム 技術ソフトウェア・エンジニアリング主任 ITスペシャリスト

要件定義作業の手順

 ここからは,図4に示した要件定義作業のプロセスに沿って,日本IBMにおける標準的な要件定義の作業手順を説明しよう。

図4●日本IBMにおける要件定義のプロセス
図4●日本IBMにおける要件定義のプロセス
[画像のクリックで拡大表示]

 最初に,要件定義作業の計画と基準を作成する(図4のP1)。具体的には,まず要件定義フェーズでどんな成果物を作成するのか,要件定義書には最終的に何を記載するのかを決定する。図5に,要件定義書に含むべき項目の例をまとめたので参考にして欲しい。

図5●要件定義書に含む項目の例
図5●要件定義書に含む項目の例

 次にこの決定に基づいて,要件定義の作業計画や要員計画を作成し,作業チームを編成するとともに,成果物を作成するための作業手順やガイドを作成する。すぐに作業に取り掛かれるように,記述ルールやサンプル,記述フォームも用意しておく。さらに,システム化目標や作業項目,品質管理方針や守るべきルール,作業に必要となる技法をメンバーに徹底させるための説明会も実施する。

現業務を現物理モデルで表す

 現行業務・システムをベースに新システムを開発する場合は,計画と基準の作成後,「DFD現物理モデル」の作成に取り掛かる(図4のP 2)。DFD現物理モデルとは,現行業務におけるデータの流れと変換プロセスをDFDで表現したものである(図6の(1))。現行業務の内容や意味,役割,業務上の問題点を洗い出すのが目的だ。なお,新システムの対象となる既存業務がない場合は,このステップを省略して,後述するユーザーへの調査から作業を開始する。

図6●IBM-DOAにおけるDFDモデリングの流れ
図6●IBM-DOAにおけるDFDモデリングの流れ
[画像のクリックで拡大表示]

 DFD現物理モデルを作成するためには,システム化対象となる現行業務を確実に把握する必要がある。そのためには,ユーザー側の協力を得て,現行の業務処理フローや事務処理マニュアルのほか,現行システムの帳票/伝票/画面,ファイルやデータベースのレイアウトといった資料を漏れなく収集しなければならない。現行業務を深く理解するためにユーザーへのインタビューも実施する。

 DFD現物理モデルを作成する際は,前述したようにコンテキスト・ダイヤグラムから詳細に展開していき,DFD4点セットまで作成する。この段階で4点セットのすべてがそろわない場合は,現行帳票のレイアウトなどを必ず添付しておく。

 DFD現物理モデルの作成と並行して,現行業務で使用しているすべてのデータ項目を抽出し,データ・ディクショナリ*4に登録しておく。未使用の項目や「シノニム(異名同義語)」/「ホノニム(同名異義語)」があっても,この段階では整理せず,そのまま登録する。これは,現行システムから新システムにデータを移行する際に極めて重要な情報となる。

現行業務の本質をモデル化

 DFD現物理モデルは,現行の業務/システムを“ありのまま”に表したものなので,現状の問題点はそのまま残っている。そこで,DFD現物理モデルから誰(人や組織,現行システム)が,いつ(タイミング),どのようにして(手段や媒体)それを実施しているかといった“物理的な制約”を取り払い,複数部署で二重に管理しているデータストアなどの統廃合を行う。これが,「DFD現論理モデル」だ(図4のP3図6の(2))。DFD現論理モデルは,現行業務の“本質”を表現したモデル(エッセンシャル・モデル)と言える。この段階までには,DFD4点セットをきちんと作成しておく。

 DFD現物理モデルを論理化する過程で,現行業務のしがらみや古いシステムがかかえている問題点が明確になるので,これを「問題点リスト」にまとめておき,新システムにおける改善候補とする。また,DFD現論理モデルの作成中に判明したシノニムやホノニムがあれば,データ・ディクショナリにその旨を記入しておく。