業務システム、予約管理、顧客管理、在庫管理、請求管理、社内ポータルなど、 会社の業務に合わせたシステム開発を検討する中小企業は少なくありません。
しかしシステム開発では、プログラムそのものだけでなく、 開発前後に作成されるドキュメントが非常に重要です。
たとえば、要件定義書、設計書、テスト仕様書、議事録、課題管理表、操作説明書、運用マニュアルなどです。
これらの資料が不十分なまま開発を進めると、
「依頼した内容と違う」
「どこまで対応してもらえるのかわからない」
「担当者が変わったら内容がわからなくなった」
「納品後に使い方や運用方法がわからない」
システム開発のドキュメントは、開発会社のためだけのものではありません。
依頼する会社側が開発内容を理解し、確認し、将来も安心して運用するための重要な資料です。
この記事では、中小企業がシステム開発を依頼するときに知っておきたい主なドキュメントの種類と、 確認すべきポイントをわかりやすく解説します。
システム開発でドキュメントが重要な理由
システム開発では、目に見える成果物として、画面や機能、プログラムに注目しがちです。
しかし、実際にはその前段階である要件整理や設計内容の確認がとても重要です。
どの業務をシステム化するのか、どの機能が必要なのか、誰が使うのか、どのようなデータを扱うのか、 どこまでを開発範囲にするのかを明確にしておかなければ、開発途中や納品後に認識違いが起こりやすくなります。
ドキュメントには、次のような役割があります。
- 依頼内容を明確にする
- 開発会社との認識違いを減らす
- 見積範囲を確認しやすくする
- 開発途中の変更点を管理する
- テスト内容を確認する
- 納品後の操作や運用に役立てる
- 担当者変更時の引き継ぎ資料になる
特に、社内にIT担当者がいない中小企業では、ドキュメントがないと開発内容を後から確認しにくくなります。
口頭の打ち合わせだけで進めず、必要な内容は必ず文章や資料として残しておくことが大切です。
開発を依頼する前に整理したいRFP
システム開発でRFPとは、提案依頼書のことです。
会社がシステム開発を依頼する際に、開発会社へ自社の要望や条件を伝えるための資料です。
通常、RFPには次のような内容を記載します。
- システム開発の目的
- 現在困っている業務課題
- 実現したいこと
- 対象となる業務範囲
- 利用する部署や人数
- 必要な機能
- 希望する納期
- 想定予算
- 運用開始後のサポート希望
中小企業では、正式なRFPを作成せずに、口頭やメールだけで相談を始めることもあります。
もちろん、小規模な開発であれば簡易的な資料でも構いません。
ただし、少なくとも「何のために作るのか」「どの業務を改善したいのか」「絶対に必要な機能は何か」は整理しておくべきです。
ここが曖昧なまま見積もりを依頼すると、開発会社ごとに提案内容がバラバラになり、比較しにくくなります。
要件定義書は開発の土台になる
要件定義書は、システムで実現する内容を整理した資料です。
開発会社がヒアリングを行い、業務課題、必要な機能、利用者、データ、画面、帳票、運用方法などを整理して作成することが多いです。
要件定義書で確認したい主な内容は次の通りです。
- システム化する目的
- 対象業務の範囲
- 利用者と権限
- 必要な機能一覧
- 入力するデータ
- 出力する帳票や一覧
- 他システムとの連携有無
- 運用上の制約
- 対応する範囲と対応しない範囲
要件定義書が曖昧だと、開発後に「この機能も入っていると思っていた」という問題が起こりやすくなります。
依頼する側も、要件定義書をただ受け取るだけでなく、 自社の業務に合っているか、抜け漏れがないか、実際の現場で使える内容かを確認することが大切です。
基本設計書は画面や帳票を確認するための資料
基本設計書は、要件定義で決めた内容をもとに、画面、帳票、入力項目、表示項目、操作の流れなどを具体化する資料です。
開発会社によって形式は異なりますが、主に次のような内容が含まれます。
- 画面レイアウト
- ボタンや入力欄の配置
- 入力項目や必須項目
- 検索条件
- 一覧表示の項目
- 帳票や印刷物の形式
- エラー表示
- 画面遷移
基本設計書は、依頼する会社側にとって非常に重要です。
なぜなら、完成後の画面や操作感をイメージしやすい資料だからです。
この段階で確認不足があると、開発が進んだ後に修正が大きくなり、費用や納期に影響することがあります。
基本設計書を確認するときは、実際に利用する担当者にも見てもらい、 日常業務の流れに合っているか確認しましょう。
詳細設計書は主に開発者向けの資料
詳細設計書は、基本設計の内容をさらに細かく分解し、プログラムとしてどのように実装するかをまとめた資料です。
一般的には、開発会社の内部資料として使われることが多く、依頼する会社側がすべてを詳細に確認する必要はない場合もあります。
ただし、次のような場合は、内容の説明を求めた方がよいことがあります。
- 他社へ保守を引き継ぐ可能性がある
- 将来的に機能追加を予定している
- 社内にIT担当者や外部IT顧問が確認する体制がある
- データベース構造や連携仕様が重要
- 長期運用する業務システムである
詳細設計書は専門的な内容になりやすいため、依頼側がすべて理解する必要はありません。
しかし、将来の保守や改修を考えるなら、最低限どのような資料が納品されるのかを確認しておくと安心です。
テスト仕様書・テスト結果は品質確認に必要
システム開発では、開発した機能が正しく動くかを確認するためにテストを行います。
テスト仕様書は、どの機能を、どの条件で、どのように確認するかをまとめた資料です。
テスト結果や成績書は、実際にテストを実施した結果を記録した資料です。
主なテストには、次のようなものがあります。
- 単体テスト
- 結合テスト
- システムテスト
- 受入テスト
依頼する会社側が特に確認したいのは、受入テストです。
受入テストでは、実際の業務に近い流れで、システムが想定通りに使えるかを確認します。
開発会社が「テスト済み」と言っていても、実際の業務で使う人が確認しなければ気づかない問題もあります。
納品前には必ず自社側でも操作確認を行い、問題点や修正したい要望などを記録しておきましょう。
議事録は「言った・言わない」を防ぐために重要
システム開発では、打ち合わせの内容を議事録として残すことが重要です。
打ち合わせでは、機能追加、仕様変更、スケジュール、費用、保留事項など、重要な話が出ることがあります。
これらを口頭だけで済ませると、後から認識違いが起こりやすくなります。
議事録には次のような内容を残すとよいでしょう。
- 打ち合わせ日時
- 参加者
- 決定事項
- 保留事項
- 次回までの確認事項
- 担当者
- 期限
議事録は単なる記録ではありません。
開発会社と依頼会社の認識を合わせるための大切な資料です。
打ち合わせ後には、議事録の内容を双方で確認し、必要があれば修正しておくことをおすすめします。
課題管理表で未対応事項を見える化する
システム開発では、打ち合わせやテストの中で多くの課題が出てきます。
たとえば、仕様確認、画面修正、不具合対応、追加要望、データ移行、運用ルールの確認などです。
これらを口頭やメールだけで管理すると、対応漏れが起こりやすくなります。
そこで役立つのが課題管理表です。
課題管理表には、次のような項目を入れると管理しやすくなります。
- 課題番号
- 課題内容
- 発生日
- 担当者
- 対応期限
- 優先度
- 対応状況
- 完了日
課題管理表があると、どの課題が未対応なのか、誰が対応するのか、いつまでに対応するのかが明確になります。
中小企業がシステム開発を依頼する場合でも、課題管理表は必ず用意しておくことをおすすめします。
WBS・工程表でスケジュールを確認する
WBS（作業分解構造図）や工程表は、システム開発の作業内容とスケジュールを管理するための資料です。
開発会社側の作業だけでなく、依頼する会社側の確認作業や資料準備も含めて管理することが大切です。
工程表で確認したい主な内容は次の通りです。
- 要件定義の期間
- 設計の期間
- 開発の期間
- テストの期間
- 受入確認の期間
- データ移行の期間
- 操作説明の予定
- 本番公開日
スケジュールは、開発会社だけで進むものではありません。
依頼する会社側が確認に時間を取れないと、開発全体が遅れることがあります。
そのため、社内確認の担当者や確認期限も含めてスケジュールを管理することが重要です。
操作説明書・運用マニュアルは納品後に必要
システムは完成して終わりではありません。
実際に社内で使い続けるためには、操作説明書や運用マニュアルが必要です。
操作説明書は、システムの画面ごとの使い方や操作手順をまとめた資料です。
運用マニュアルは、日常業務の流れに沿って、誰が、いつ、何をするのかを整理した資料です。
たとえば、次のような内容です。
- ログイン方法
- データ入力手順
- 検索方法
- 帳票出力方法
- エラー時の対応
- バックアップ確認
- 権限管理
- 退職者や担当者変更時の対応
操作説明書や運用マニュアルがないと、担当者が変わったときに使い方が分からなくなります。
また、開発会社に問い合わせないと対応できないことが増え、運用コストが高くなる可能性もあります。
納品時には、どのようなマニュアルが提供されるのかを事前に確認しておきましょう。
ドキュメントは「誰のために必要か」を考える
システム開発のドキュメントは、形式的に作るものではありません。
それぞれのドキュメントには、必ず目的があります。
たとえば、要件定義書は、依頼会社と開発会社の認識を合わせるために必要です。
基本設計書は、画面や帳票が業務に合っているか確認するために必要です。
テスト仕様書は、システムが正しく動くか確認するために必要です。
議事録や課題管理表は、決定事項や未対応事項を残すために必要です。
操作説明書や運用マニュアルは、納品後に社内で使い続けるために必要です。
つまり、ドキュメントは開発会社だけのためではなく、依頼する会社側にとっても大切な資料です。
「誰のために必要なのか」を考えることで、どの資料を重視すべきかが見えやすくなります。
中小企業が確認したいドキュメント一覧
システム開発を依頼する前に、次のようなドキュメントが作成・共有されるか確認しておきましょう。
- RFP（提案依頼書）または要望整理資料
- 要件定義書
- 基本設計書
- 詳細設計書
- テスト仕様書・テスト結果
- 議事録
- 課題管理表
- WBS（作業分解構造図）・工程表
- 操作説明書
- 運用マニュアル
- 保守対応範囲の資料
- アカウント・権限管理資料
すべてを分厚い資料として作る必要はありません。
小規模な開発であれば、簡易的な資料でも構いません。
重要なのは、必要な情報が残っていて後から確認できる状態になっていることです。
ドキュメントがない開発で起こりやすい問題
ドキュメントが不十分なままシステム開発を進めると、次のような問題が起こりやすくなります。
- 依頼内容と完成物に差が出る
- 見積範囲が曖昧になる
- 追加費用の判断が難しくなる
- 仕様変更の履歴が残らない
- 不具合と追加要望の区別がつきにくい
- 納品後の操作方法が分からない
- 担当者変更時に引き継げない
- 他社へ保守を依頼しにくい
特に中小企業では、社内にIT担当者がいないことも多いため、開発会社に任せきりになりがちです。
しかし資料が残っていないと、将来の改修や保守で困る可能性があります。
開発を依頼する段階で、どのドキュメントを作成してもらえるのか、どこまでが納品物に含まれるのかを確認しておきましょう。
ドキュメントは作るだけでなく更新・共有が重要
ドキュメントは、作成しただけでは十分ではありません。
システム開発では、打ち合わせやテストの中で仕様変更や追加要望が発生することがあります。
その内容がドキュメントに反映されていなければ、古い情報のまま残ってしまいます。
ドキュメント管理で大切なのは次の点です。
- 最新版がどれか分かるようにする
- 変更履歴を残す
- 関係者が同じ資料を確認できるようにする
- 古い資料と混在しないようにする
- 保管場所を決める
- 納品後も確認できるようにする
最近では、Word、Excel、PDFだけでなく、クラウドストレージやプロジェクト管理ツールを使って共有するケースもあります。
どの方法を使う場合でも、最新版が分かること、関係者が確認できること、必要なときに確認できることが重要です。
システム開発を依頼する前の確認ポイント
中小企業がシステム開発を依頼する前には、次の点を確認しておくことをおすすめします。
- 要件定義書は作成されるか
- 画面や帳票の設計資料を確認できるか
- テスト内容と結果を確認できるか
- 議事録や課題管理表を共有してもらえるか
- スケジュール表を共有してもらえるか
- 操作説明書や運用マニュアルは納品されるか
- 納品後の保守範囲は書面で確認できるか
- ドキュメントの保管場所や形式はどうなるか
これらを事前に確認することで、開発後のトラブルを減らしやすくなります。
システム開発は開発費用だけで判断するのではなく、ドキュメントや運用後のサポートも含めて比較することが大切です。
まとめ
システム開発では、プログラムや画面だけでなく、各種ドキュメントが重要な役割を持っています。
RFP（提案依頼書）、要件定義書、基本設計書、詳細設計書、テスト仕様書、議事録、課題管理表、WBS（作業分解構造図）、操作説明書、運用マニュアルなどは、 開発会社と依頼会社の認識を合わせ、品質を確認し、納品後も安心して使い続けるために必要です。
特に中小企業では、社内にIT担当者がいない場合は特にシステム開発会社に任せきりになりやすくなります。
しかし、ドキュメントが不十分なまま開発を進めると、認識違い、追加費用、納品後の運用トラブル、担当者変更時の引き継ぎ問題につながる可能性があります。
システム開発を依頼する際は、どのドキュメントが作成されるのか、誰が確認するのか、どこに保存するのかを事前に確認しましょう。
ドキュメントは形式的な資料ではなく、会社が安心してシステムを使い続けるための土台です。
IT顧問のITAでは、中小企業のシステム開発相談を支援しています
IT顧問のITAでは、八王子市を中心に、中小企業・小規模事業所様のIT環境やシステム導入・開発相談をサポートしています。
「システム開発を依頼したいが、何を準備すればよいかわからない」
「開発会社から提示された資料の内容を確認してほしい」
「要件定義や設計内容に不安がある」
「納品後に困らないよう、ドキュメントや運用方法を整理したい」
このようなお悩みがありましたら、お気軽にご相談ください。
開発会社との打ち合わせ前の要件整理、資料確認、運用ルールづくり、ドキュメント管理まで、 会社の状況に合わせて無理のない形で支援いたします。
