システムの計画・開発・納品それぞれの段階で必要なドキュメントの種類

この記事では、システム開発の計画から開発、納品で用いられるドキュメントの種類について解説します。
システム開発においてどのようなドキュメントを用意すればいいのかわからない事業者様は、ぜひご一読ください。

システム開発においてドキュメントが重要である理由

はじめに、システム開発においてドキュメントがどれだけ重要な位置にあるのか紹介します。

• 発注者とシステム開発会社が円滑な意思疎通を図れるようにするため
• スムーズな引き継ぎができるため
• 不具合があったときに対処できるため

重要性を理解することで、それぞれのドキュメント作成をより真剣に取り組めるようになるでしょう。

発注者とシステム開発会社が円滑な意思疎通を図れるようにするため

ドキュメントを作成することで、発注者と開発会社間での意思疎通を円滑に行うことができます。
なぜなら、要件定義書というドキュメント作成時に、双方の認識を合わせているからです。
システム開発は、開発業務だけが仕事ではありません。
発注者がどんなシステム開発を求めているのか、発注者が抱えている課題を解決するための最善策は何かを考え、解決するまでが仕事です。
そして、双方の意見をまとめた要件定義書の作成には、開発会社と発注者間で綿密なコミュニケーションを取る必要があります。
そのため、案件定義書というドキュメントを作成することで、発注者と開発会社間で円滑な意思疎通を図れるようになるのです。

スムーズな引き継ぎができるため

ドキュメントがあれば、引継ぎをスムーズに行えます。
通常、システム開発は複数の担当者が、それぞれの工程に分かれた作業を行うため、開発途中に担当者が変わる可能性がないとは言い切れません。
担当者が変わるたびに引継ぎを行っていては、余分な追加費用がかかってしまいます。
一人で対応していた業務の場合、ドキュメントがないとシステムの内容を自分でかみ砕いて分析しなければいけません。
この分析作業が大変で、多大な時間と労力を費やします。
しかし、ドキュメントがあれば引継ぎや分析作業に充てる時間を最小限に抑えることが可能です。
人員の変更は必ず起こるため、スムーズな引継ぎを行うためにドキュメントは必須と考えておきましょう。

不具合があったときに対処できるため

ドキュメントがあれば不具合が起きたときでも対処できます。
不具合が起きたとき、迅速な対応が必要です。
まず、不具合が起きている原因を探るために何度もシステムを起動し、試す必要があります。
実際に修正する箇所は目に見えないシステムの部分のため、どこが原因でエラーが出ているのか発見しにくいでしょう。
しかし、ドキュメントがあれば処理の流れをたどって、エラーを起こしている部分を特定できます。
業務に直結するシステムが不具合を起こした場合、迅速に対処しないと業務が止まってしまい、多大な損失を生んでしまうでしょう。
ドキュメントがあると不具合処理を迅速に行えるため、ドキュメント作成は重要です。

システム開発で用いられるドキュメント

それぞれ、計画段階で用いられるものや開発開始後に用いられるなどタイミングや用途が異なるため、ある程度の流れを把握しておくといいでしょう。
ここからは、それぞれのドキュメントの詳細を作成順に紹介します。

• 提案依頼書
• 要件定義書
• 基本設計書
• 詳細設計書
• テスト仕様書
• 運用マニュアル
• 操作説明書

それぞれ見ていきましょう。

提案依頼書

提案依頼書とは、発注者側が受注者側に提案をしてもらうために、クライアントサイドの要件をまとめた資料です。
クライアントサイドには、到達したい目標や解決したい課題があり、それらを達成するためにどのようなシステムを開発したいのかまとめます。
まとめた提案依頼書をもとに、受託企業は最適な機能やスケジュール感について提案し、提案された内容をもとに、発注者側は受託企業を選定するのです。
提案依頼書では、具体的に下記のような内容を明記します。

• 目的
• 発注者の基本情報
• 現状の課題・達成後の理想の姿
• システムに求めるニーズ
• 依頼したい範囲
• 予算・納期
• 提案して欲しい内容

提案依頼書には、関係者間での認識齟齬によるトラブルの発生率を下げるといったメリットもあります。

要件定義書

要件定義書とは、クライアントの要望に対して課題を解決するための具体的な施策をまとめたものです。
提案依頼書提出後に、受託企業が具体的なスケジュールや機能など発注者側にヒアリングし、作成します。
双方の解釈にズレが無いよう各項目を洗い出し、まとめるため、要件定義書の作成には発注側と受託側で綿密なコミュニケーションが必要です。
内容は発注者側もチェックするため、専門用語を避け、わかりやすい言葉で記述されています。
具体的には、下記の内容を記述します。

• システム概要
• 全体図
• 業務フロー図
• システム要件・納品対象
• 機能要件
• 非機能要件
• 総合・受け入れテスト設計図
• WBS

予算や納期とのバランスで発注者側の要望通りにいかない場合もあるため、優先順位をつけて話し合いを進めましょう。

基本設計書

基本設計書は、外部設計の内容をまとめたドキュメントです。
要件定義の段階で抽象的だったシステムの構成図や機能同士の関係性を細かく決めます。
受託会社が作成し、発注者側が確認する最後のドキュメントです。
基本設計では、下記のような内容を記載します。

• システム設計
• 業務フロー図
• 画面設計
• 帳票設計
• バッチ設計
• データベース設計
• ファイル設計
• 外部インターフェース設計

発注者が携われる最後のドキュメントのため、より具体的なすり合わせを行いましょう。

詳細設計書

詳細設計書は、基本設計書に記載された内容をどのように実現するのか、システムエンジニアに指示を出すためのドキュメントです。
詳細設計は、システムエンジニアの作業がスムーズにはかどるように、より専門的な内容を記載します。
詳細設計で記載する内容は下記の通りです。

• クラス図
• モジュール構成図
• アクティビティ図
• シーケンス図
• IPO（処理機能記述）
• 開発方針・ルール
• 単体・結合テスト設計

詳細設計は、あくまでエンジニア向けのドキュメントで、基本設計書の内容をより具体化したという意味ではありません。
勘違いしやすい部分のため注意しましょう。

テスト仕様書

テスト仕様書は、アプリケーションテストを行う際にチェックすべき項目がまとめられた文章のことです。
実装後に用いられるのが一般的で、機能ごとに行う単体テストや複数の機能を組み合わせて行う結合テスト、すべての機能を統合した総合テストの3回に分けて行います。
実際にテスト仕様書に含めるべき内容は、下記の通りです。

• 概要
• 実施条件
• 実行手順
• 期待結果
• テスト結果

問題点が見つかれば、その都度修正を行います。

運用マニュアル

運用マニュアルは、システム運用時に必要なマニュアルのことです。
実際にシステムを利用する発注者が一連の業務が行えるように、受注者側が用意します。
運用マニュアルに含まれる内容は、下記の通りです。

• 概要
• 運用方法
• それぞれの名称
• 注意事項
• エラー時の対応方法

概要を全く知らない人が運用する可能性も含めて作成しましょう。

操作説明書

操作説明書は、その名の通りシステムの操作手順を記したドキュメントです。
画面ごとの使い方や入力の仕方などを明記します。

操作説明書があれば、ユーザーインターフェースなどがわかりやすく、システムになれるまでに時間がかかりません。
また、運用後にわからないことが発生した際も見返すことができます。

運用マニュアル

納品後に必要となるドキュメントとして、運用マニュアルも必要になります。

運用業務フローに合わせて作成されたドキュメントのことで、IT企業側だけでなくクライアントサイドも協力して作成されるケースが多いです。
運用マニュアルは、テスト完了時や運用をスタートした際に用います。

システム開発ドキュメントの活用方法

システム開発で具体的にどのタイミングでドキュメントを活用するのか、活用方法を紹介します。
それぞれのドキュメントは、以下のような場面で活用できるでしょう。

それぞれ活用場所は異なりますが、システム開発や運用を行う上で欠かせないドキュメントです。

ドキュメント作成時のポイント

最後に、ドキュメント作成時のポイントについて紹介します。

• 作成の目的を明確にする
• 読み手の立場にたつ
• 文だけでなく画像・図表を用いる
• 難しい表現を避ける
• 失敗例や不採用となったケースも記載する

ポイントを押さえて、完成度の高いドキュメントを作成しましょう。

作成の目的を明確にする

作成の目的が明確であれば、記載内容がわかるようになります。
特に初心者は何を書けばいいのかわからず筆が止まってしまうでしょう。
しかし、目的が明確であれば、何を書くのか想像しやすいため、作成しやすくなります。
たとえば、要件定義書は関係者の認識あわせや開発が難航したときに利用するのが一般的です。
基本情報のほかに、なぜこの目的に向かって行きたいのか、この機能を追加した理由まで細かく記載します。
そうすることで、開発途中に難航しても初心に戻り、再考が可能です。
そのため、ドキュメント作成時には、なぜそのドキュメントを作成するのか目的を明確にして作成するようにしましょう。

読み手の立場にたつ

読み手の立場にたつことで、わかりやすいドキュメントの作成が可能です。
読み手は発注者やシステムエンジニアなどさまざまですが、作成するドキュメントには必ず読み手がいます。
特に発注者も目を通すドキュメントの作成には注意が必要です。
もし、専門用語だらけのドキュメントになってしまうと、わかりにくいドキュメントになってしまいます。
相互理解のためにドキュメントを作成しているため、読み手の存在を意識しながら作成しましょう。
そうすることで読みやすいドキュメントを作成できます。

文だけでなく画像・図表を用いる

文章だけでなく、画像や図、表を用いることで理解しやすいドキュメントを作成できます。
特に案件定義書は発注者と受注者の相互理解を深めるものです。
文章だけの説明だと、どうしても理解しにくかったり認識の齟齬が生まれてしまう可能性があります。
そうすると発注者の意見がうまくシステムに反映されなかったり作り直しが必要になってしまうでしょう。
これらのトラブルを防ぐためにも画像や図、表を用いた理解しやすいドキュメント作成が必要です。

難しい表現を避ける

ドキュメント作成では、難しい表現や専門用語の多用は控えましょう。
難しい表現や専門用語の多用は、人によってわかりにくいドキュメントになる可能性があります。
ドキュメントは誰がみてもわかるようなわかりやすい物である必要があるため、システム設計を全く知らない素人に教えるイメージで書くといいでしょう。
そうすることで、認識の齟齬を減らしたわかりやすいドキュメントの作成が可能です。

失敗例や不採用となったケースも記載する

ドキュメント作成では、失敗例や不採用のアイディアも記載するようにしましょう。
これらの情報があると説得力があがり、今後判断に迷ったときの指標になります。
そのため、失敗例はわかりやすいように取り消し線を引いたり文字の色を変えたりして残しましょう。
情報が多くなり、見にくくなると思うかもしれませんが、困ったときに意外と役に立つためおすすめです。

システム開発前から納品まで工程により用いられるドキュメントが違う

以上、システム開発の計画から納品までに用いられるドキュメントについて解説しました。

システム開発を成功させるためには、さまざまなドキュメントを準備しなければなりません。
そのため、資料の作成に負担を感じている方もいるのではないでしょうか。

「自社の社員では、設計書を作成することができない」
「システム開発を依頼したいが提案依頼書を作成したことがない」

という悩みで困っている事業者様は、ぜひEMEAO!にご相談ください。
実績豊富なIT企業を完全無料でご紹介します！