システム開発工程別に整理する成果物一覧と全体像

プロジェクト管理
スポンサーリンク
スポンサーリンク

システム開発において

「今どの工程で、どんな資料を作るべきか分からない」

「あとから“それ聞いてない”が発生する」

――そんな経験はありませんか。

多くのトラブルは、技術力不足ではなく

工程ごとの役割・成果物が整理されていないこと に起因します。

本記事では、

要件定義（営業）→ 要件定義（開発）→ 設計 → 実装 → テスト → リリース → 保守運用

というシステム開発ライフサイクル全体を、

  • どの工程で
  • 何を決め
  • どんな成果物（資料）が必要か

という観点で整理します。

さらに、実務で抜け落ちやすい「データ移行」工程も横断的に解説します。

👉「この記事を読めば、どのタイミングで、どんな資料が必要になるのかが一望できる」そんなチェックリスト的な記事を目指します。

各工程ごとの成果物一覧（全体俯瞰）

まずは全体像です。

システム開発は「作業」ではなく 成果物の積み上げ で進みます。

工程 主な成果物
要件定義（営業・プリセールス） 業務課題整理資料／ヒアリングメモ／提案書／概算見積書／スコープ定義
要件定義（開発側） 業務要件定義書／機能要件一覧／非機能要件定義書／制約条件一覧
基本設計 システム構成図／アーキテクチャ設計書／画面一覧／画面遷移図／API一覧
詳細設計 画面設計書／API設計書／バッチ設計書／DB論理・物理設計書
実装 ソースコード／設定ファイル／ビルド定義
テスト 単体テスト仕様書／結合テスト仕様書／テスト結果報告書
リリース リリース計画書／移行手順書／リリース判定資料
保守・運用 運用手順書／監視設計書／障害対応フロー／改修要望管理表
データ移行（横断） 移行要件定義書／マッピング表／移行手順書／検証結果

※ データ移行は 特定の1工程に属さない のがポイントです。

要件定義（営業・プリセールス）でやること

業務課題・目的のヒアリング

この工程のゴールは

「なぜこのシステムを作るのか」を言語化することです。

  • 現在の業務課題
  • 数値的な問題（時間・コスト・人員）
  • システム化によるゴール

成果物：

  • 業務課題整理資料
  • ヒアリングメモ

※ この段階で画面仕様を詰めすぎないことが重要です。

ステークホルダー整理と意思決定フロー

  • 誰が利用するのか
  • 誰が決裁するのか

を明確にします。

成果物：

  • ステークホルダー一覧
  • 意思決定フロー簡易図

スコープ定義と概算見積

  • 今回やること
  • やらないこと

を明文化し、後工程の認識ズレを防ぎます。

成果物：

  • スコープ定義書
  • 概算見積書

要件定義（開発側）でやること

機能要件の整理

営業要件を 実装できる粒度 に落とします。

成果物：

  • 機能要件一覧
  • 業務要件定義書

非機能要件の明確化

性能・セキュリティ・可用性など、

後戻りが最も高コストな領域です。

成果物：

  • 非機能要件定義書

制約条件・前提条件の明文化

  • 既存システム
  • 技術制約
  • 予算・納期

成果物：

  • 制約条件一覧

要件定義書の合意形成

この資料が 全工程の判断基準 になります。

設計工程（基本設計・詳細設計）でやること

システム構成・アーキテクチャ設計

  • 全体構成
  • 外部連携

成果物：

  • システム構成図
  • アーキテクチャ設計書

画面・API・バッチ設計

  • 利用者視点
  • システム連携視点
  • 運用視点

成果物：

  • 画面設計書
  • API設計書
  • バッチ設計書

データベース設計

  • 論理設計
  • 物理設計

成果物：

  • DB設計書

実装・テスト工程でやること

実装ルール・コーディング規約

属人化を防ぐための最低限のルールを定義します。

テスト設計と実施

テストは「確認作業」ではなく 設計工程 です。

成果物：

  • 単体テスト仕様書
  • 結合テスト仕様書
  • テスト結果報告書

CI/CD・品質管理

  • 自動化
  • 不具合管理

成果物：

  • 不具合管理表

データ移行工程（横断的に発生する重要工程）

データ移行が必要になるケース

  • 既存システムからのリプレース
  • Excel・Access管理からの移行
  • 別システム統合

👉 ほぼすべての業務系システムで発生します。

工程別に見るデータ移行の成果物

タイミング 成果物
要件定義 データ移行要件定義書
設計 データマッピング表
実装 移行プログラム
テスト 移行検証結果
リリース 本番移行手順書

重要なのは

「移行しないデータ」を明文化することです。

よくある失敗パターン

  • 件数しか見ず中身を見ない
  • 移行テストを省略
  • 本番一発勝負

👉 これらは 本番トラブルの典型例 です。

リリース・保守運用でやること

リリース計画と移行手順

  • いつ
  • 誰が
  • 何をするか

成果物：

  • リリース計画書
  • 移行手順書

運用監視・障害対応

  • 監視項目
  • エスカレーションルール

成果物：

  • 運用手順書
  • 障害対応フロー

まとめ｜成果物ベースで考えるシステム開発

システム開発を

「作業の流れ」ではなく「成果物の流れ」

として捉えることで、

  • 抜け漏れ防止
  • 認識齟齬の削減
  • プロジェクトの再現性向上

が実現できます。

特に データ移行は軽視されがちですが最重要工程の1つ です。

本記事の一覧をベースに、

自社・自チーム向けに成果物を取捨選択し、

実践的な開発標準として活用してください。

迷ったら

「この工程で、本来あるべき成果物は何か？」

に立ち返ることが、失敗しないシステム開発への近道です。

参考1：成果物テンプレート・サンプル資料集（公式・信頼性重視）

以下は、各工程の成果物について 実際に参照／ダウンロードできる公式・実務向けページ です。

読者がそのまま辿れるように URL付きでまとめています。

要件定義（営業・プリセールス）系

IPA（情報処理推進機構）

  • 超上流から攻めるIT化の事例集：要件定義（サンプル・成果物例）

    👉 https://www.ipa.go.jp/archive/digital/tools/ep/ep2.html

    → 上流工程の成果物例がまとまっており、提案〜要件定義のイメージ作りに役立ちます。

  • ユーザのための要件定義ガイド 第2版（公式：PDFダウンロード）

    👉 https://www.ipa.go.jp/archive/publish/tn20191220.html

    → 要件定義の主要ドキュメントや勘どころを体系的に学べます。

    ※ 以前の「jimcontent.com」配布PDFはミラーの可能性があるため、IPA公式の配布ページに差し替えています。

要件定義（開発側）・設計工程

企業の技術資料（事例の宝庫）

  • NTTデータ／富士通／日立などの公式技術コンテンツ

    → 企業公式サイト内で「要件定義」「基本設計」「アーキテクチャ」「設計書」「テンプレ」等で検索すると、事例や解説PDFが見つかることがあります。

    ※ 企業サイトは改版・移動が起きやすいため、リンク固定はせず 公式サイト内検索推奨の形にしています。

画面設計・UI設計

Figma（テンプレ）

データベース設計

ER図＋公式ドキュメント

※ DB製品の公式は「ER図テンプレ」よりも DDL（CREATE文）やスキーマ設計の原則の確認に向いています（仕様確認・用語の正確性を担保できるため）。

データ移行（特に重要）

AWS Database Migration Service（DMS）

テスト工程

IPA（テスト関連資料）

  • ソフトウェアテスト見積りガイドブック（IPA PDF）

    👉 https://www.ipa.go.jp/archive/publish/qv6pgp0000000yho-att/000005132.pdf

    → テスト観点・見積り・進め方の考え方を掴むのに役立ちます。

    ※ 「単体/結合テスト仕様書テンプレ」そのものではないですが、テスト設計の粒度を整える参考になります。

運用・保守工程

ITIL（IT Service Management）

  • ITIL 公式（全体像・認定体系）

    👉 https://www.itil.com/

    → 運用手順書、障害対応フロー、変更管理などの考え方の土台になります。

参考2：工程別によく利用されるツール・サービス一覧

ここでは、前章までで整理した システム開発工程について、

実務でよく使われる代表的なツール・サービスを工程別に紹介します。

ポイントは次の3つです。

  • 「理論上ある」ではなく、現場で実際によく使われている
  • 特定ベンダーに依存しすぎない
  • 中小〜中規模の業務システムでも採用しやすい

なお、ツールがほとんど使われない工程（営業ヒアリング等）は無理に載せていません。

要件定義（営業・プリセールス）で使われるツール

ドキュメント作成・共有

  • Microsoft Excel / Microsoft Word

    → 要件整理、ヒアリングメモ、概算条件整理

  • Google Docs / Google Sheets

    → 複数人での同時編集、初期たたき資料向け

👉 この工程では 専用ツールより「スピードと共有性」 が重視されます。

業務フロー整理・簡易図作成

  • Microsoft PowerPoint
  • Lucidchart

👉 「きれいさ」より その場で意思疎通できるか が重要です。

要件定義（開発側）で使われるツール

要件・課題管理

  • Redmine
  • Backlog

👉 機能要件／非機能要件／課題・質問を チケット単位で管理するケースが多いです。

ドキュメント体系化

  • Confluence
  • Notion

👉 要件定義書・用語集・決定事項を 「あとから検索できる形」で残す 目的で使われます。

設計工程（基本設計・詳細設計）で使われるツール

画面設計・UI設計

  • Figma
  • Adobe XD

👉 ワイヤーフレーム／画面遷移／簡易モックを 設計レビュー用に作る用途が中心です。

システム構成図・設計図作成

  • diagrams.net（旧 draw.io）
  • Lucidchart

👉 インフラ・アーキテクチャ設計では 視覚的に説明できること が最重要です。

データベース設計

  • A5:SQL Mk-2
  • MySQL Workbench

👉 ER図作成・テーブル定義書生成に使われます。

実装工程で使われるツール

ソースコード管理

  • GitHub
  • GitLab

👉 ブランチ運用／レビュー／履歴管理は必須要素です。

開発環境・エディタ

  • Visual Studio
  • Visual Studio Code

👉 言語・プロジェクトに応じて使い分けられます。

テスト工程で使われるツール

テスト管理・不具合管理

  • Redmine
  • Backlog

👉 テストケース／不具合／修正状況を一元管理します。

自動テスト・CI/CD

  • Jenkins
  • GitHub Actions

👉 ビルド／テスト／デプロイの自動化に利用されます。

データ移行工程で使われるツール

データ抽出・変換・投入

  • Microsoft Excel
  • Python
  • SQL Server（SQL）

👉 「専用ETLを使わず、スクリプト＋SQLで対応」 という現場は非常に多いです。

クラウド移行・DB移行

  • Amazon Web Services（DMSなど）

👉 大量データや本番移行では 公式移行サービス が使われるケースもあります。

リリース・保守運用で使われるツール

運用監視・ログ管理

  • Zabbix
  • Datadog

👉 サーバ監視／障害検知／アラート通知に利用されます。

問い合わせ・改修管理

  • Redmine
  • Backlog

👉 保守フェーズでも 開発時と同じ管理ツールを継続利用するケースが多いです。

※本記事で紹介したツール群は、あくまで「よく使われる代表例」**です。 自社の規模・文化・技術スタックに合わせて取捨選択し、工程 × 成果物 × ツールが自然につながる開発プロセスを構築してください。

プロジェクト管理
システム開発
スポンサーリンク
シェアする
tobotoboをフォローする
tobotobo

コメント

タイトルとURLをコピーしました