システム開発で登場する成果物・ドキュメントをダウンロードして使えるサイトが知りたい
と言った疑問に答えます。
社内SEに必要なシステム開発のドキュメント・成果物一覧を理解できます。本記事で、成果物別の作成担当・レビュー担当の役割を表で解説します。記事後半では、成果物別に作成のアドバイスとサンプルダウンロードのリンクを紹介しています。
✔記事の信ぴょう性
SE＋社内SE歴15年以上。現大手EC運営企業の管理職 兼 社内SE講師。
グローバル（15か国以上導入）へ大規模ERPシステム開発・導入を実施。
2018年よりSE講師として100名弱の部下・生徒の教育を実施。
システム開発における成果物・ドキュメント一覧
本記事では、システム開発の各プロセスにおける成果物・ドキュメントにフォーカスして説明をしていきます。
システム開発の全体プロセスに関しては、【システム開発が上手くなる為に、プロセス全体概要を理解から始めよう】の記事をご覧ください。
成果物・ドキュメント事の作成担当者・レビュー担当者イメージ
まずは、システム開発における成果物を、「誰が」「何を」作成し、その成果物・ドキュメントを「誰が」レビューするのか？の一例を解説します。以下のサンプルでは、ウォーターフォールでのシステム開発で、システム要件定義フェーズからSierに支援していただく進め方を例にしています。
以下サンプルの前提
１ ウォーターフォール開発＋パッケージ導入ではなくスクラッチ開発を想定
２ 単一ベンダーでの開発を想定
複数ベンダーで開発する場合、システム構成図等、複数社にまたがる領域の成果物が必要
社内SEでクロスベンダーマネージメントも必要、以下では割愛
３ 以下サンプルでは、Sierから業務支援は受けない前提
プロジェクトによっては、業務作業部分もSierに依頼する場合あり
システム開発成果物・ドキュメント一覧
| プロセス | 成果物名 | 作成担当 | レビュー担当 |
|---|---|---|---|
| 契約・変更合意 | NDA（秘密保持） | 企業間 | |
| 見積書・提案書 | ベンダー | 社内SE | |
| 基本契約書 | 企業間 | ||
| 個別契約書・SoW（作業範囲記述書） | 企業間 | ||
| 企画 | 企画書 | 企画者 | |
| RFI | 社内SE | ||
| RFP | 社内SE | ||
| 業務要求定義 | キックオフ資料 | 業務 | |
| ビジネスプロセス関連図 | 業務 | ||
| AS-IS 業務フロー | 業務 | ||
| To-BE 業務フロー | 業務 | ||
| 業務一覧 | 業務 | ||
| 要求一覧’システム化業務一覧） | 業務 | 社内SE | |
| 投資審議資料 | 起案者 | ||
| 予算管理 | 予算管理者 | ||
| システム要件定義 | マスタースケジュール | 業務 | |
| 体制図・会議体 | 社内SE | ||
| マネジメント方法 | 社内SE | ||
| ドキュメント管理 | 社内SE | ||
| コミニケーション管理 | 社内SE | ||
| 要件定義書 | ベンダー | 社内SE | |
| 要件一覧 | ベンダー | 社内SE | |
| 機能一覧 | ベンダー | 社内SE | |
| 画面一覧 | ベンダー | 社内SE | |
| 画面モック・レイアウト | ベンダー | 社内SE | |
| 帳票一覧 | ベンダー | 社内SE | |
| 帳票レイアウト | ベンダー | 社内SE | |
| 外部システム関連図 | ベンダー | 社内SE | |
| 外部インターフェース一覧 | ベンダー | 社内SE | |
| 外部インターフェース定義書 | ベンダー | 社内SE | |
| バッチ一覧 | ベンダー | 社内SE | |
| 機能概要説明 | ベンダー | 社内SE | |
| 非機能要件書 | ベンダー | 社内SE | |
| 画面遷移図 | ベンダー | 社内SE | |
| ビジネスルール定義書 | 業務 | ||
| バッチ処理フロー | ベンダー | 社内SE | |
| 移行計画書 | ベンダー | 社内SE | |
| トレーニング計画書 | 業務 | ||
| 開発（基本設計） | 概念データモデル | ベンダー | 社内SE |
| テーブル一覧 | ベンダー | 社内SE | |
| データ項目定義 | ベンダー | 社内SE | |
| システム構成図 | ベンダー | 社内SE | |
| ソフトウェア設計書 | ベンダー | ||
| ネットワーク設計書 | ベンダー | ||
| ハードウェア設計書 | ベンダー | ||
| テスト | 単体テスト報告書 | ベンダー | 社内SE |
| 外結合テスト計画書 | ベンダー | 社内SE | |
| 外部結合テスト報告書 | ベンダー | 社内SE | |
| システムテスト計画書 | ベンダー | 社内SE | |
| システムテスト報告書 | ベンダー | 社内SE | |
| ユーザー受入テスト計画書 | 業務 | 社内SE | |
| システム操作マニュアル | 社内SE | ||
| 業務マニュアル | 業務 | ||
| 移行 | システム移行計画 | ベンダー | 社内SE |
| 業務移行計画 | 業務 | 社内SE | |
| データ移行計画 | ベンダー | 社内SE | |
| 運用 | 運用設計書 | ベンダー | 社内SE |
| 管理 | WBS（Work Breakdown Structure) | – | – |
以下で主要成果物・ドキュメントを解説しサンプルやテンプレートのダウンロード先も紹介していきます。（ベンダーと社内SEの役割は契約によって変更しますが、大体の線引きは上記です）
契約・変更合意プロセス
NDA(秘密保持）
システム開発を行う際は企業間のNDA(秘密保持契約）の有無を交わしましょう。システム開発で社内の様々な情報を提供し後々問題にならないように準備が必要です。
見積書・提案書
NDAを確認出来たら、いよいよベンダーに情報提供を依頼します。ベンダーごとに見積・提案書を提出します。別記事で見積書・提案書の抑えどころを解説します（公開日未定）。
基本契約書
NDAと同じタイミングで確認したいのが基本契約の有無です。
ベンダー企業間で合意する基本的な契約になります。基本契約がある場合は、個別契約も基本契約にのっとり実施します。
個別契約書
基本契約書がない場合は、契約時に個別でベンダーと契約する場合に利用します。個別契約は基本契約に比べると社内承認プロセスが短めです。しかし、企業によってはかなり時間がかかる場合もあります。プロジェクト開始遅延にならないように早めに準備が必要です。
✔あわせておすすめ記事
契約・変更合意プロセスと詳細な契約書の説明は以下の記事を参照ください。
企画プロセス
企画プロセスの主役は、ほとんどの場合、事業・業務側です。以下の様な成果物・ドキュメントの準備が一般的です。
企画書
ビジネス戦略に基づいて作成させる業務・サービスの構造。各社各様のフォーマットがある場合はほとんどです。文章化が非常に重要です。
この時点で事業・業務が紙アイディアを落とし込めないと、いつまでたってもふわふわした議論になりがちです。そんな人には本でも進めてとにかく文字にする重要性を説きましょう。
他にもシステム開発が学べるおすすめ書籍は以下の記事でご紹介しています。
RFI=提案依頼書
構想がある程度固まったら、情報収集を行います。その際には、RFIを作成し複数の企業にお声がけをする場合があります。既に既存システムがある場合は、運用をしているベンダーに声をかけるのが一般的ですが、新規領域・ベンダーの際にはRFIで情報提供依頼をします。
ビジネス構想に基づき、ベンダーに提案の依頼をするフォームとなります。
依頼をシンプルに書いているRFIです。もし面識のないベンダーさんであれば既存の業務や仕組みの説明等補足がないときびしかもしれません。
ちょっとやりすぎ感がありますが、【経済産業省基盤情報システム サービス 情報提供依頼書】もご紹介します。かなり細かく情報をベンダーさんに準備しています。必要な考え方エッセンスを抽出し準備する感じでOKです。
RFP＝提案依頼書 / Request For Proposal
システム開発のベンダーを選定する際に、具体的な提案を依頼する文書です。一般的に、システムの目的や概要、要件や制約条件などを記載します。
RFIに似ていますが、目的が情報収集ではなく、提案になります。提供する情報に基づいて具体的にどうベンダーのソリューション・パッケージで自社の課題を解決できるか？いくらか？を提案していただきます。
業務要求定義プロセス
業務要件のプロセスの主人公は当然業務です。しかし、社内SEとしてどのような成果物・ドキュメントを事業・業務に用意しておいてほしいかを理解する必要があります。
アドバイスですが、大抵業務ユーザーは自分がなんのドキュメントを作らなければいけないのか？を理解していません。ここで理解した内容にもとづきまずは業務ユーザーの教育が重要です。
要件定義はシステム開発の鬼門です。以下の記事で更に詳細の要件定義の失敗しない進め方を解説しています。あわせてご参照ください。
AS-IS業務フロー・TO-BE業務フロー
要件定義で最も重要な位置づけになるのが、業務要件の洗い出しです。
その中で最も重宝するドキュメントが業務フローです。上記の図のように、作業の流れとデータの流れを図にしていきます。
既存業務フロー・新業務フローと呼ぶ場合もあります。
要求一覧・課題一覧
事業・業務の要求の一覧をまとめます。この際には、システム化の要件だけではなく達成したい目的に必要な要件をすべて洗い出し、その後、解決方法としてシステム開発・導入する部分を決めていくことが重要です。
以下ご用意したIPAのダウンロードサンプルでは、課題一覧として取り扱っていますが要求一覧も課題一覧も目的は一緒です。
投資審議資料
システム化の要件・概要が見えてきたら必要な予算を社内承認プロセスを経て取得します。
予算管理資料
承諾された予算に基づき予算管理表に記入し投資を執行していきます。
投資審議資料と予算管理は各社各様ですので社内の先輩等に確認が必要です。
要件定義プロセス
要求定義のプロセスが完了すると、いよいよシステム開発にむけた要件定義のプロセスになります。システム化に向けプロジェクトの主体も社内SEへと移行していきます。
注意：
システム化する部分は確かに社内SEの仕事ですが、そのほかの部分（機器調達・新しいサービスの為の契約、等）は業務がシステム開発と並行して進める必要があります。
要件定義一式のテンプレートはこちらの記事で紹介しています。
マスタースケジュール
全体のマスタースケジュールと開発の主要タスクのをアライメントさせる必要があります。マスタースケジュールなのでPPTで作成でも特に問題ないです。
体制図・会議体
システム開発を実施するために体制図と役割を定義する必要があります。特に、役割の定義は非常に重要です。
体制図と併せて非常に重要になるのが、役割の定義です。誰が何を行うのか？を明文化しておいた方が後々トラブルを防ぐことが出来ます。出来れば、ＷＢＳでは誰が何の成果物を作る担当なのか？まで決めておくべきです。
以下のIPAのサンプルに役割のサンプルもあります。
ドキュメント管理/コミニケーション管理
システム開発で発生する、会議資料・成果物の格納場所を決めておく必要があります。
又、チーム間でのコミニケーション方法や会議体も事前に定義することでロスのない円滑な進行が出来ます。プロジェクトによっては、PMOが実施する場合もありますが、小規模開発の場合、社内SE自身で決める必要があります
プロジェクト立ち上げに関するさらに詳細の情報は以下の記事が分かり易くまとまっています。
要件定義書
業務ユーザーの要求に基づきシステム化するための要件をまとめたドキュメントです。ベンダーとの契約によりますが、一般的には小規模開発では社内SEが要件を定義します。大規模になると要件定義書の作成からベンダーにお願いいする場合もあります。
要件一覧・機能一覧
業務フローと要求一覧に基づき、機能の一覧を作成していきます。
画面一覧
機能一覧に基づき、画面の一覧を作成していきます。
イメージとしては以下です。
画面モック・レイアウト
画面一覧でリストした画面をそれぞれ画面モック・レイアウトを作成していきます。
以下のリンクで、IPAの作り方説明とサンプルダウンロードを紹介します。
帳票一覧・レイアウト
帳票一覧・レイアウトの作成は、ほぼ画面レイアウトと同じです。最終的に画面でユーザーが見るのか、紙でみる媒体の違いになります。
画面の場合は、ボタンなどからの遷移があるのでその点は違いますが基本は同じです。
画面遷移図
画面一覧と併せて作成が重要なのが、画面遷移図です。業務のフロー・ユーザーの利用シーンを想定しながら業務フローを使いながらウォークスルーが有効です。
外部システム関連図
外部インターフェースに必要な資料は、
外部システム関連図： 図でシステム間のインターフェースを理解する
外部インターフェース一覧： システム間のインターフェース一覧を作成する
外部インターフェース定義書：一覧化されたものに基づき仕様を定義していきます
以下で解説するサンプルは全て同じPPTからサンプルを満つことが出来ます。
外部システム関連図 IPA 20ページ
外部インターフェース一覧 IPA 17ページ
外部インターフェース定義書 IPA 23ページ
注意するポイント：
複数システムにまたがるインターフェース設計は、かなりコミニケーションミスが発生しやすいポイントです。しっかりと読み合わせが必要です。
一度定めたインターフェース定義書の更新ルール、受ける側・出す側どうやって更新するのか？記載の主体はどちらにするのかまで決めておく必要があります。
外部インターフェース担当なんてのを決めるとスムーズにすすみます。お見合いしがちなタスクになります。
バッチ一覧
機能一覧、画面一覧、インターフェース一覧が見えてきたら以下の非機能要件と並行してバッチ一覧とその連携方式を決めていきます。
リアルタイム性を求めるのか？一日に1回の連携でもいいのか？等ユーザー要件も加味しながら設計していきます。
バッチに関する作成方法はIPAの機能要件の合意形成ガイドの9ページ以降から非常に分かり易く解説されています。
非機能要件書
機能要件と並行して設定しておく必要があるのが、非機能要件です。たいていの開発でリリース間近になって炎上しやすいのが非機能要件です。
例えば、
・スピードが遅くて使い物にならない
・ユーザーが1000しか登録できないなんて聞いていない
です。
IPAでも以下の図を使い、非機能の違いを解説しています。
非機能要件をスムーズにするためには、経済産業省の以下のリンクがサンプルとして使えます。
システム移行計画書・要件定義書
システム移行と言っても3種類の以降があります。
・アプリケーションのリリースを計画する＝システム移行計画
・データの本番への移行を計画する＝データ移行計画
・業務の切り替えを検討する＝業務移行計画
です。
システム開発前の最後の鬼門でしっかりした認識が必要な重要な工程です。【SE必見|システム移行計画書のリスクと抑えておくべき４つのポイント】の記事で詳しく解説しています。解説不要な方は以下のリンクから直接DLも可能です。
システム開発の運用プロセス
運用設計書
運用設計では、前提次項を決めその後に、対象システム、サービスレベル等を決めていきます。上記IPAの運用支援調達のサンプルが体系的に文章化されていておすすめです。
WBS（Work Breakdown Structure)のエクセルテンプレート
システム開発のスケジューリングと言えば、WBS（Work Breakdown Structure)です。以下のサイトで様々なWBSのテンプレートを見つけることが出来ます。
