ITスキル システム開発講座

2-8 システム開発の成果物・ドキュメント一覧まとめ【DLリンク有】

ITスキル

システム開発で登場する成果物・ドキュメントをダウンロードして使えるサイトが知りたい

と言った疑問に答えます。

社内SEに必要なシステム開発のドキュメント・成果物一覧を理解できます。記事では成果物別の作成担当・レビュー担当の役割を表で解説しています。記事後半では、それぞれの成果物のワンポイントアドバイスとおすすめのサンプルダウンロードのリンクを紹介しています。

✔記事の信ぴょう性

SE歴10年以上。現在、大手EC運営企業の管理職 兼 社内SE講師として活躍中。15か国以上へのグローバルシステム開発・導入等幅広く開発を経験。

講師として体系化したコンテンツの一部をお届けする事で、社内SE・情シスの方にお役に立てればと願っています。

スポンサーリンク

システム開発における成果物・ドキュメント一覧

本記事では、システム開発の各プロセスにおける成果物・ドキュメントにフォーカスして説明をしていきます。

システム開発の全体プロセスに関しては、【システム開発が上手くなる為に、プロセス全体概要を理解から始めよう】の記事をご覧ください。

成果物・ドキュメント事の作成担当者・レビュー担当者イメージ

まずは、成果物・ドキュメント一覧に対して、「誰が」「何を」作成し、その成果物・ドキュメントを誰がレビューするのか?を解説します。

3つの注意点

1 あくまで一般的な社内SEのシステム開発(スクラッチ)を想定

2 複数ベンダーで開発する場合はシステム構成図等、複数社にまたがる領域の成果物は社内SEが作成必要

3 業務作成となている成果物も、業務ユーザーのやる気によっては社内SEが作る場合もあり。(個人的に、これからの社内SEの働き方はより作る→創るに移行する。企業によっては既に役割分担が違う場合もあり。)

システム開発成果物・ドキュメント一覧

プロセス成果物名作成担当レビュー担当サンプル
契約・変更合意NDA(秘密保持)企業間
見積書・提案書ベンダー社内SE
基本契約書企業間
個別契約書企業間
企画企画書企画者
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
運用運用設計書ベンダー社内SE
管理WBS(Work Breakdown Structure)

以下で主要成果物・ドキュメントを解説しサンプルやテンプレートのダウンロード先も紹介していきます。(ベンダーと社内SEの役割は契約によって変更しますが、大体の線引きは上記です)

契約・変更合意プロセス

NDA(秘密保持)

システム開発を行う際は企業間のNDA(秘密保持契約)の有無を交わしましょう。システム開発で社内の様々な情報を提供し後々問題にならないように準備が必要です。

見積書・提案書

NDAを確認出来たら、いよいよベンダーに情報提供を依頼します。ベンダーごとに見積・提案書を提出します。別記事で見積書・提案書の抑えどころを解説します(公開日未定)。

基本契約書

出所:IPA

NDAと同じタイミングで確認したいのが基本契約の有無です。

ベンダー企業間で合意する基本的な契約になります。基本契約がある場合は、個別契約も基本契約にのっとり実施します。

個別契約書

基本契約書がない場合は、契約時に個別でベンダーと契約する場合に利用します。個別契約は基本契約に比べると社内承認プロセスが短めです。しかし、企業によってはかなり時間がかかる場合もあります。プロジェクト開始遅延にならないように早めに準備が必要です。

✔あわせておすすめ記事

契約・変更合意プロセスと詳細な契約書の説明は以下の記事を参照ください。

2-4 システム開発の契約3種3形態を正しく把握しよう
システム開発の契約ってどうなってるか理解したい!といった疑問に答えます。この記事で、システム開発でよく登場する、NDA・基本契約・個別契約・請負契約・準委任契約といった違いが理解できるようになります。

システム開発を一括見積してくれるおすすめ2社

既存システムの改修の場合は、作成したRFP・RFIに基づいて保守を担当しているベンダーに見積をいらします。

新規スクラッチ開発やパッケージ導入の際は候補ベンダーにアプローチをします。

その際に数ある開発ベンダーに一括で見積を依頼できるサービスをご紹介します。

発注ナビ

公式URL: https://hnavi.co.jp/

ちまちまベンダーにアプローチ→説明は本当に工数がかかります。さらに、アプローチできるのも結局ネットで探す or 紹介になるので、本当にその開発に最適なベンダーにアプローチできません

発注ナビを使うと専門コンシェルジュがそのあたりを代行してくれるの相当便利です。さらに、以下の様に国内の有名企業にも一気にアプローチできるので効率抜群です。

ご相談・お見積りは無料なので安心して問い合わせできます。

EMEAO(エミーオ)

公式URL:https://emeao.jp/

一括見積サイトでもう1社おすすめがEMEAOです。発注ナビ同様無料で利用できます。特徴は、提案者数を8社以内に限定してくれる点です。

両方に問い合わせてみて担当エージェントの相性でいずれかを選定しすすめるで問題ないと思います。

企画プロセス

企画プロセスの主役は、ほとんどの場合、事業・業務側です。以下の様な成果物・ドキュメントの準備が一般的です。

企画書

ビジネス戦略に基づいて作成させる業務・サービスの構造。各社各様のフォーマットがある場合はほとんどです。文章化が非常に重要です。

この時点で事業・業務が紙アイディアを落とし込めないと、いつまでたってもふわふわした議論になりがちです。そんな人には本でも進めてとにかく文字にする重要性を説きましょう。

RFI=提案依頼書

企画がある程度固まったら、情報収集を行います。その際には、RFIを作成し複数の企業にお声がけをする場合があります。既に既存システムがある場合は、運用をしているベンダーに声をかけるのが一般的ですが、新規領域・ベンダーの際にはRFIで情報提供依頼をします。

ビジネス構想に基づき、ベンダーに提案の依頼をするフォームとなります。

システム開発ではなく、機器調達ですがイメージはつかめます。目的、概要、タイムライン、アドミン系の連絡等必要な要素を理解することが出来ます。

RFP=提案依頼書 / Request For Proposal

出所:

システム開発のベンダーを選定する際に、具体的な提案を依頼する文書です。一般的に、システムの目的や概要、要件や制約条件などを記載します。

RFIに似ていますが、目的が情報収集ではなく、提案になります。提供する情報に基づいて具体的にどうベンダーのソリューション・パッケージで自社の課題を解決できるか?いくらか?を提案していただきます。

業務要求定義プロセス

業務要件のプロセスの主人公は当然業務です。しかし、社内SEとしてどのような成果物・ドキュメントを事業・業務に用意しておいてほしいかを理解する必要があります。

アドバイスですが、大抵業務ユーザーは自分がなんのドキュメントを作らなければいけないのか?を理解していません。ここで理解した内容にもとづきまずは業務ユーザーの教育が重要です。

要件定義はシステム開発の鬼門です。以下の記事で更に詳細の要件定義の失敗しない進め方を解説しています。あわせてご参照ください。

2-6 【社内SE向け】システム要件定義の進め方・必要成果物とは?
システム要件定義の一人で進めれるようになりたい!進め方が分からない!と言った悩みに答えます。この記事でシステム要件定義のちょっと前の工程から進め方・プロセス・必要成果物を紹介します。この記事を読むことでどの順番で何を準備しなければいけないか?気を付ける点は何か?を理解できます。

AS-IS業務フロー・TO-BE業務フロー

出所:IPA

要件定義で最も重要な位置づけになるのが、業務要件の洗い出しです。

その中で最も重宝するドキュメントが業務フローです。上記の図のように、作業の流れとデータの流れを図にしていきます。

既存業務フロー・新業務フローと呼ぶ場合もあります。

要求一覧・課題一覧

事業・業務の要求の一覧をまとめます。この際には、システム化の要件だけではなく達成したい目的に必要な要件をすべて洗い出し、その後、解決方法としてシステム開発・導入する部分を決めていくことが重要です。

以下ご用意したIPAのダウンロードサンプルでは、課題一覧として取り扱っていますが要求一覧も課題一覧も目的は一緒です。

投資審議資料

システム化の要件・概要が見えてきたら必要な予算を社内承認プロセスを経て取得します。

予算管理資料

承諾された予算に基づき予算管理表に記入し投資を執行していきます。

投資審議資料と予算管理は各社各様ですので社内の先輩等に確認が必要です。

要件定義プロセス

要求定義のプロセスが完了すると、いよいよシステム開発にむけた要件定義のプロセスになります。システム化に向けプロジェクトの主体も社内SEへと移行していきます。

注意:

システム化する部分は確かに社内SEの仕事ですが、そのほかの部分(機器調達・新しいサービスの為の契約、等)は業務がシステム開発と並行して進める必要があります。

要件定義一式のテンプレートはこちらの記事で紹介しています。

システム要件定義で使える成果物サンプル・テンプレートまとめ
システム要件定義で使える成果物のサンプル・テンプレートをまとめました。本記事ではシステム要件定義の成果物に特化したサンプルを用意しています。要件定義書...

マスタースケジュール

全体のマスタースケジュールと開発の主要タスクのをアライメントさせる必要があります。マスタースケジュールなのでPPTで作成でも特に問題ないです。

体制図・会議体

システム開発を実施するために体制図と役割を定義する必要があります。特に、役割の定義は非常に重要です。

体制図と併せて非常に重要になるのが、役割の定義です。誰が何を行うのか?を明文化しておいた方が後々トラブルを防ぐことが出来ます。出来れば、WBSでは誰が何の成果物を作る担当なのか?まで決めておくべきです。

以下のIPAのサンプルに役割のサンプルもあります。

ドキュメント管理/コミニケーション管理

システム開発で発生する、会議資料・成果物の格納場所を決めておく必要があります。

又、チーム間でのコミニケーション方法や会議体も事前に定義することでロスのない円滑な進行が出来ます。プロジェクトによっては、PMOが実施する場合もありますが、小規模開発の場合、社内SE自身で決める必要があります

プロジェクト立ち上げに関するさらに詳細の情報は以下の記事が分かり易くまとまっています。

PM初心者でも出来る?プロジェクト計画書の作り方~無料サンプル付き!~
プロジェクト計画書を作ることは、プロジェクトを成功に導くための第一歩です。 この記事にたどり着いた方は、上司から「そろそろPMやってみるか」「プロジェクト計画書を作ってみろ」と言われて、プロジェクトマネジメントやプロジェクト計画書について調べ始めた人ではないでしょうか? プロジェクト計画書の重要性は分かっているが、

要件定義書

業務ユーザーの要求に基づきシステム化するための要件をまとめたドキュメントです。ベンダーとの契約によりますが、一般的には小規模開発では社内SEが要件を定義します。大規模になると要件定義書の作成からベンダーにお願いいする場合もあります。

要件一覧・機能一覧

業務フローと要求一覧に基づき、機能の一覧を作成していきます。

画面一覧

機能一覧に基づき、画面の一覧を作成していきます。

イメージとしては以下です。

画面モック・レイアウト

画面一覧でリストした画面をそれぞれ画面モック・レイアウトを作成していきます。

以下のリンクで、IPAの作り方説明とサンプルダウンロードを紹介します。

帳票一覧・レイアウト

帳票一覧・レイアウトの作成は、ほぼ画面レイアウトと同じです。最終的に画面でユーザーが見るのか、紙でみる媒体の違いになります。

画面の場合は、ボタンなどからの遷移があるのでその点は違いますが基本は同じです。

画面遷移図

画面一覧と併せて作成が重要なのが、画面遷移図です。業務のフロー・ユーザーの利用シーンを想定しながら業務フローを使いながらウォークスルーが有効です。

外部システム関連図

外部インターフェースに必要な資料は、

外部システム関連図: 図でシステム間のインターフェースを理解する
外部インターフェース一覧: システム間のインターフェース一覧を作成する
外部インターフェース定義書:一覧化されたものに基づき仕様を定義していきます

以下で解説するサンプルは全て同じPPTからサンプルを満つことが出来ます。

外部システム関連図 IPA 20ページ

外部インターフェース一覧 IPA 17ページ

外部インターフェース定義書 IPA 23ページ

注意するポイント

複数システムにまたがるインターフェース設計は、かなりコミニケーションミスが発生しやすいポイントです。しっかりと読み合わせが必要です。

一度定めたインターフェース定義書の更新ルール、受ける側・出す側どうやって更新するのか?記載の主体はどちらにするのかまで決めておく必要があります。

外部インターフェース担当なんてのを決めるとスムーズにすすみます。お見合いしがちなタスクになります。

バッチ一覧

機能一覧、画面一覧、インターフェース一覧が見えてきたら以下の非機能要件と並行してバッチ一覧とその連携方式を決めていきます。

リアルタイム性を求めるのか?一日に1回の連携でもいいのか?等ユーザー要件も加味しながら設計していきます。

バッチに関する作成方法はIPAの機能要件の合意形成ガイドの9ページ以降から非常に分かり易く解説されています。

非機能要件書

機能要件と並行して設定しておく必要があるのが、非機能要件です。たいていの開発でリリース間近になって炎上しやすいのが非機能要件です。

例えば、
・スピードが遅くて使い物にならない
・ユーザーが1000しか登録できないなんて聞いていない
です。

IPAでも以下の図を使い、非機能の違いを解説しています。

非機能要件をスムーズにするためには、経済産業省の以下のリンクがサンプルとして使えます。

※経済産業省委託事業「平成29年度新エネルギー等の保安規制高度化事業(監督部電子申請システム構築に向けた検討業務)」においてアクセンチュア株式会社が作成した原案をもとに、経済産業省にて作成

システム移行計画書・要件定義書

システム移行と言っても3種類の以降があります。
・アプリケーションのリリースを計画する=システム移行計画
・データの本番への移行を計画する=データ移行計画
・業務の切り替えを検討する=業務移行計画
です。

システム開発前の最後の鬼門でしっかりした認識が必要な重要な工程です。【SE必見|システム移行計画書のリスクと抑えておくべき4つのポイント】の記事で詳しく解説しています。解説不要な方は以下のリンクから直接DLも可能です。

システム開発の運用プロセス

運用設計書

運用設計では、前提次項を決めその後に、対象システム、サービスレベル等を決めていきます。上記の「国立原爆死没者追悼平和祈念館 情報システム システム運用設計書」がすごくいいサンプルです。

WBS(Work Breakdown Structure)のエクセルテンプレート

システム開発のスケジューリングと言えば、WBS(Work Breakdown Structure)です。以下のサイトで様々なWBSのテンプレートを見つけることが出来ます。

タスク管理用エクセルテンプレート12選!作業効率3倍UPの工程表|DuoWorks
ビジネスの現場では、複数のプロジェクトが同時に行われることも珍しくはありません。また、1人でできる仕事は限られており、多