システム開発の仕事では、仕様の追加や変更は日常茶飯事です。「これで仕様凍結！と宣言して、仕様変更を受け付けなければ良い」などとこちらの勝手を言う人もいますが、事はそう簡単にはいきません（安易な変更を抑制する効果はありますが…）。現実的にはその仕様のままじゃ動かなかったりするので、ある程度の追加・変更はあるものと覚悟しておく必要があります。

   社會においても「警察官や教師は、不正があってはならない」というタテマエにとらわれて対策を打たないことが問題視されています。「彼らも不正行為を犯す」という前提に立って対処方法を定めておくべきというのが現代の常識です。同じように、仕様変更も発生し得るという前提に立ち、それを吸収しながらプロジェクトを成功させるという柔軟な姿勢が重要なのです。

   常駐・派遣ベースでは、変更が生じてもリスク（コストやスケジュール）は基本的に相手側にあります。しかし、請負で仕事をする場合は、仕様変更による損失がもろにかぶさるので、十分な対処が必要です。

   対処のひとつは、口頭でなく文書レベルでやり取りするということです。具體的には、打ち合わせをしたら「打合議事録」をきちんと書く、タイムリーにレビューをして「レビュー報告書」を提出する、仕様変更は電話ではなく「仕様変更依頼書」で受け付けるなどです。これらは、PMBOKにおけるコミュニケーション管理に相當するもので、プロジェクト管理手法PYRAMIDではドキュメントテンプレートを用意して運用することを定めています。

   もうひとつ、その前段として必要なのがPMBOKにおけるスコープ管理です。つまりプロジェクトスタート時に開発範囲を明確にしておくことが大切です。スコープの表現には作業（タスク）と成果物の2つの切り口があります。

   ときどき未確定な部分があるという理由で、スコープをあいまいにしたままプロジェクトをスタートさせている例を見かけます。しかし、そんな場合でも"その他帳票10本"というように未確定ながらボリュームを抑えておくことが、請負で仕事をする際は肝心です。

   第1回は、開発ドキュメント標準DUNGEONで規定されている開発ドキュメント體系を紹介しました。また、その中から「業務フロー」の標準テンプレート記入例をもとに、業務フロー記述のポイントについて解説しました。

   今回は、スコープを明確にするためのドキュメント「機能一覧表」を取り上げて説明しましょう。図1は、DUNGEON様式の「機能一覧表」の記入例です。システム開発対象となる機能を洗い出して、大分類（サブシステム）、中分類（機能分類）ごとに整理して一覧表にまとめています。

図1：DUNGEONの「機能一覧表」記入例
（畫像をクリックするとExcelファイルをダウンロードできます。/33.0KB）

   ここでは、機能ごとに畫面入力、畫面照會、帳票出力、バッチ処理の4種類に區分けをしています。このほかにも帳票出力指示畫面などがありますが、それらは"照會"に區分けすることで対応します。

   プロジェクトの最初の段階では、機能の洗い出しが完全にできません。しかし、ぐずぐずと「機能一覧表」の作成を延ばしていると、全體のボリューム把握が遅れプロジェクトに支障が生じます。機能一覧表は、不完全でも良いので必ずプロジェクトの初期段階で作成し、仕様が固まるのと並行して追記・修正していくようにしてください。

   機能一覧表は、文字通り開発対象となるアプリケーション機能を一覧にしたもので、システム化の対象を明確に表す資料となります。「機能一覧表」は、契約時に作成しておくドキュメントですが、表1のようにプロジェクトの各段階でその情報が活用されます。

表1：機能一覧の利用形態

   図2のように、見積範囲を明確化する「機能別見積一覧表」が作成済みであればそれをもとに作成しますが、ファンクションポイント法などのように機能別ではなく本數換算で見積を行った場合は、契約時に請負範囲確定のために作成します。

   また、スケジュール管理のため機能ごとの進捗管理を行う場合、この機能一覧表」をもとにして「機能別進捗管理表」を作成します。これは機能単位に擔當者を割り當て、作業の予定と実績を対比させる形式です。詳細設計、プログラミング、単體テスト、マニュアル作成など、機能単位で作業を行うものに対して有効な進捗管理表となります。

   弊社の體系では、コスト管理、スケジュール管理のための管理資料（「機能別見積一覧表」と「機能別進捗管理表」）はPYRAMIDの範疇で、「機能一覧表」はユーザに提出する設計ドキュメントの一覧を表すものとしてDUNGEONのアウトプットとしています。

図2：機能一覧情報の展開

   表2は、基本設計工程におけるDUNGEONのドキュメント構成です。これまでに紹介した「業務フロー」や「機能一覧表」は、プロジェクト全體に対して作成されるドキュメントです。次は、個別のアプリケーション単位で作成される「基本設計書」の標準化について説明します。

   表2の通り基本設計書は、「概要」と「I/O関連図」、「畫面/帳票レイアウト」から構成されます。「概要」部分でアプリケーションの目的や位置づけなどを説明し、「I/O関連図」で畫面や帳票とデータの入出力関係を図示。そして「畫面/帳票レイアウト」で具體的な畫面や帳票のイメージを表します。今回は、この中から「I/O関連図」を取り上げて説明しましょう。

表2：基本設計工程のドキュメント構成

   図3は、DUNGEONにおける「I/O関連図」の表記方法を表したものです。I/O関連図とは、畫面や帳票などのアプリケーションがどのテーブルを參照しているか、どのテーブルデータを更新しているかを図で表したものです。

   アプリケーションを作成する際に、その処理（プログラム）が何をきっかけに起動され、どのテーブルを參照してどのテーブルを更新しているかを一目で表し、処理全體の役割や位置づけの理解を支援します。

図3：I/O関連図の表記方法
（畫像をクリックすると別ウィンドウに拡大図を表示します）

対象となるテーブルはすべて記述する

大きなプログラムでは対象となるテーブルがかなりの數となりますが、基本的にそのアプリケーションで使用するテーブルはすべて書き出します。

CRUD表の元となる

CRUD表とは、アプリケーションと使用するテーブルの関係を表したものです。縦にアプリケーション、橫にテーブルを並べ、どのアプリケーションがどのテーブルをアクセスしているかを一目で理解できるものです。

処理は機能単位で記述

中央に配置する「処理」は、個々のプロシージャの場合もありますが、複數のプロシージャをまとめた"機能"という位置づけになります。