エンタープライズ

《ステップ・バイ・ステップガイド》

佐野 央の
社内システム導入を成功させる方法

2005年8月31日　　文●佐野 央

Step 9
ドキュメントの重要性について考える（2/3）

●テスト結果報告は品質を証明するもの

アドバイザー佐野：まず、システム導入プロジェクトは大きく2つの業務から成りたっています。

PM：Step 4で話した、「プロジェクト管理業務」と「構築関連業務」ですね。

アドバイザー佐野：はい。「構築関連業務」はフェーズに分かれており、そこで作成したドキュメントには「フェーズで決定した、システムに関する情報」が盛り込まれています。システムはこれらドキュメントを元に組み立てられますから、導入したハードウェアやソフトウェア同様、成果物の一種となります。ですから、構築関連業務で作成されるドキュメントはRFPを除いて基本的に有料です。

PM：プロジェクトによってはここにあげられたすべてのドキュメントを作成する必要はないんですよね。今回A社では、「要件定義書」「基本設計書」「詳細設計書」「運用管理設計書」、それとリストにはありませんが、自分たちでクライアントを移行するための「クライアント移行手順書」を発注しました。

アドバイザー佐野：それでは、発注していない成果物ドキュメントについて、何か質問はありませんか？

PM：そういえば、試験計画書、試験結果報告書というものがありますけど……これがどうもぴんと来ないんです。テストの結果報告なんて、成果物になるんですか？

アドバイザー佐野：はい、この2つのドキュメントは「システムの品質のレベル」を証明するものなのです。

PM：品質のレベルを証明するためのもの、ですか？

アドバイザー佐野：はい。設計書に基づいて構築したシステムが、要件定義書で決定した「使用目的」どおりに動作するかどうかを、「何を基準に」「どんな動作を」「どんな方法で試験し」「その結果、どうなったか」を、ドキュメントという形で明確にするんです。これで、A社とX社（システムインテグレータ）の双方が、同じ目線で「システムの品質レベルを満たしている」と確認できるわけです。

PM：ふぅむ。プロジェクトに関わる複数の人間が持つシステムへの意識を徹底的に「すり合わせる」のですね。

アドバイザー佐野：はい。試験結果報告書は、一種の品質保証書、というわけです。