システム開発におけるドキュメントの目的とは？種類や改定タイミングなどについて徹底解説！

システム開発を外注先に依頼するとプログラムが納品され、開発過程で作成されたドキュメント類も一緒に納品されることがあります。このドキュメントがなんのために存在するのかと疑問に感じたことはありませんか。

ドキュメントは開発をスムーズに行い、納品後も機能追加や運用を行うために重要です。ここでは、システム開発におけるドキュメント作成の目的や具体的なドキュメントの種類、ドキュメント改定のタイミングについて詳しく解説します。

1.　システム開発で用いるドキュメントの目的

システム開発を発注する側としてはアプリケーションやソフトウェアなどが納品されれば良いので、ドキュメントについて特に意識することはないかもしれません。しかし、ドキュメントはシステム開発において重要な役割を担っています。

システム開発を依頼する際にRFPなどの依頼内容をまとめたドキュメントがないと、どのようなシステムが欲しいのか、具体的な要件を伝えることができません。

また、開発会社が用意する要件定義書や設計書などのドキュメントがないと、後で機能追加の必要が生じたときシステムの仕様がわからず機能追加できなくなってしまいます。システム開発を外注する際には、ドキュメントを確認し、品質に問題がないか確認しましょう。

ここでは、ドキュメントを作成する具体的な目的について、詳しく解説します。

目的①：発注元と外注先が互いに意思疎通を図る

企画書や要件定義書など、開発の早い段階でのドキュメント類は、システム開発における仕様や設計などについて意思疎通を図るために必要です。

「こんなシステムを作ってほしい」というぼやっとした要件を外注先に伝えただけでは、正確に要件が伝わったかがわかりません。画面設計や入出力設計などを仕様書として形にしたものをお互いが確認することで、システム要件を確実に共有することができます。

目的②：円滑な引き継ぎを行う

システムを開発した外注先が納品後もメンテナンスを担当するとは限りません。メンテナンスやアフターフォローを別会社や別の担当者が行うことはよくあります。

その際にドキュメント類があれば、システムの詳細な仕様やメンテナンス手順などについて担当者に引き継ぐことが可能です。運用時にエラーや障害が発生した場合も、仕様書があれば問題への対処を素早く行えます。

2.　システム開発で用いるドキュメントの種類

ここでは、各工程でドキュメントが作成されるタイミングや内容について解説していきます。

提案依頼書（RFP）

提案依頼書（RFP）は、システム開発の検討段階でクライアントが作成して開発会社に提出するドキュメントです。システム要件について、目的・予算・納期・運用方法などを明示しており、開発会社はこのドキュメントをもとに開発を進めていきます。

なお、これ以降のドキュメントは、すべて開発会社が作成します。

要件定義書

提案依頼書をもとに開発会社がクライアントに詳細なヒアリングを行って作成するのが要件定義書です。プロジェクトの見積もりを作成する前の要件定義工程で作成します。

システムの目的や要求、実現方法、機能の概要、大まかな見積もりなどを開発会社が明示し、クライアントが確認します。

基本設計書

設計工程で開発会社が作成するのが基本設計書です。画面レイアウトや入出力仕様、帳票フォーマット、管理項目などについて明確にします。

クライアントは基本設計書を確認します。これ以降、テスト工程までのドキュメントは内部資料なのでクライアントは確認しません。

詳細設計書

設計工程で、基本設計書をもとにシステムの実現方法の詳細について詳細設計書に明示します。

単体テスト仕様書 / 成績書

テスト工程の最初の単体テスト工程で、単体テスト仕様書と成績書を作成します。プログラムを単体で動作させてテスト仕様書どおりにテストを行い、結果を成績書に記録します。

プログラムが単体で仕様どおりに動くことを確認し、品質を記録するためのドキュメントです。

結合テスト仕様書 / 成績書

テスト工程の結合テスト工程で、結合テスト仕様書と成績書を作成します。各プログラムを結合して動作させ、テスト仕様書どおりにテストを行い、結果を成績書に記録します。

プログラムを結合させて仕様どおりに動くことを確認し、品質を記録するためのドキュメントです。

システムテスト仕様書 / 成績書

テスト工程のシステムテスト工程で、システムテスト仕様書と成績書を作成します。システムを総合的に動作させてテスト仕様書どおりにテストを行い、結果を成績書に記録します。

システムをユーザー目線で動作させて仕様どおりに動くことを確認し、品質を記録するためのドキュメントです。

運用マニュアル

システムの納品前に作成する運用マニュアルです。運用担当を行う外注先や担当者がシステムメンテナンスや運用を行う際に利用します。

クライアントがシステムを運用する場合は、クライアントが運用マニュアルの確認を行います。

3.　システム開発で用いるドキュメントを改定すべきタイミング

ドキュメント類は改定が必要な場合があります。ここでは、ドキュメントを改定すべきタイミングはいつなのか、解説します。

システム仕様が変更になったタイミング

システム仕様が変更になったタイミングで、仕様書の該当箇所を変更します。

例えば、画面仕様が変更になったら、要件定義書や基本設計書、詳細設計書の該当箇所を変更しなくてはいけません。変更部分に関する各工程のテストを再度実施する場合は、テスト仕様書/成績書も新たに作成してテストします。

仕様書は最新の状態に更新し、実際のシステムの仕様と仕様書にずれが生じないようにしなければなりません。

システム運用後に修正を行ったタイミング

システムを運用していくうえで、システムの仕様や運用方法に修正が必要になる場合もあります。その際には、上記の『システム仕様が変更になったタイミング』と同様に、仕様書類の変更を行います。運用マニュアルに変更が必要な場合は、運用マニュアルも変更しておきましょう。

アップグレードを行ったタイミング

ハードウェアやソフトウェア、ミドルウェアなどがアップデートされた場合に、システムに変更が生じることがあります。その場合も、上記の『システム仕様が変更になったタイミング』と同様に仕様書類の変更を行います。また、運用マニュアルに変更が必要な場合も、忘れずに変更しましょう。

4.　まとめ

ここでは、システム開発におけるドキュメント作成の目的や具体的なドキュメントの種類、ドキュメント改定のタイミングについて詳しく解説しました。システム開発においてドキュメントは非常に重要な存在です。システム開発を外注する際には、ドキュメントの品質についても確認する必要があります。