⚖️ 2.2 工程の定義

2.2 工程の定義


2.2.1 V 字モデル

  • 定義: サンエム標準では、工程は以下の図のようなV字モデルを前提とする。
Image in a image block

2.2.2 作りこみ工程

上流工程(Upstream Process)
  • 定義: 要件定義工程および基本設計工程のこと。
要件定義(Requirement Definition)
  • 定義: プロジェクト目的を達成するために、システムまたは業務が満たすべき要件を関係者間で合意し、その内容を合意文書として確定させる工程。
  • 説明:
    • ステークホルダーの要望や課題を分析し、業務要件とシステム化要件に整理する。
    • 要件定義書として成果物をまとめ、後続の設計工程の基盤となる。
基本設計(Base Design)
  • 定義: 要件を実現するための、システム全体の構造・仕組み・方式・外部仕様を定義したもの。また、その工程。
  • 説明:
    • 要件定義(何を実現するか)の結果を受けて、技術的に実現可能な仕様に落とし込む。
    • システムの全体像や方式、外部仕様(画面・帳票・インターフェース等)を含む。
  • 例: 顧客情報はマスタテーブルで管理する、画面はReactで実装する、認証機能はOAuth2.0で実現する

2.2.3 検証工程

結合テスト(Integration Test)
  • 定義: 複数のモジュールやコンポーネントを組み合わせて、それらが連携して正しく動作するかを検証するテストのこと。
  • 略語: IT
  • 説明:
    • 単体テスト後に実施され、インターフェース仕様通りにデータが受け渡されるか、機能間の整合性が保たれているかを確認する。
    • 契約上のスコープ定義によって、外部結合テストと内部結合テストに分けられることがある。
  • 例: ログイン機能と顧客管理機能を連携させ、認証後に顧客情報が正しく取得・表示されることを確認する
外部結合テスト(External Integration Test)
  • 定義: 開発したシステムと外部システムや外部環境との連携動作を検証するテストのこと。
  • 略語: ITb, 外結
  • 同義語: 外部仕様テスト
  • 説明:
    • 契約上のスコープ定義の一つ。
    • 外部API、外部データベース、他システムとのインターフェース、ハードウェア連携などが正しく動作するかを確認する。
  • 例: 開発した在庫管理システムと既存の販売管理システムをAPI連携させ、受注データが正しく在庫に反映されることを確認する
内部結合テスト(Internal Integration Test)
  • 定義: 開発したシステム内部のモジュール間やコンポーネント間の連携動作を検証するテストのこと。
  • 略語: ITa, 内結
  • 同義語: 内部仕様テスト、インフラ案件における「システム基盤テスト」(アプリが乗る前のインフラだけのテスト)
  • 説明:
    • 契約上のスコープ定義の一つ。
    • 自システム内の機能・サブシステム同士が、設計通りに連携し正しく動作するかを確認する。
  • 例: 開発した販売管理システム内の受注機能、在庫管理機能、請求機能が連携して、一連の業務フローが正しく処理されることを確認する
システムテスト(System Test)
  • 定義: システム全体が、統合された状態で要件を満たしているかを検証するテストのこと。
  • 略語: ST
  • 同義語: 総合テスト
  • 説明:
    • 結合テスト後に実施され、機能要件・非機能要件の両方が、実際の運用環境に近い状態で正しく動作するかを確認する。
    • 性能試験、負荷試験、セキュリティテストは、すべてこの工程に含まれる(IPAの「システム適格性確認テスト」のうち、ユーザー側が主体になる運用テスト以外のテストのこと)。
  • 例: システム全体を通じて、ユーザー登録から注文処理、請求書発行までの一連の業務フローが、性能要件やセキュリティ要件を満たしながら正しく動作することを確認する
運用テスト(Operation Test)
  • 定義: システム管理者の視点で、本番環境での実際の運用を想定し、運用手順や保守作業が正しく実行できるかを検証するテストのこと。
  • 略語: OT
  • 説明:
    • システムテスト後に実施され、バックアップ・リストア、監視、障害対応、データメンテナンスなどの運用業務が問題なく行えるかを確認する。
    • ユーザー受入テストとは目的や観点が異なる別のテストだが、工程上は「リリース前の最終確認」として隣接または一部重なることもある。
  • 例: システムの日次バッチ処理、ログ監視、障害発生時の切り戻し手順、データバックアップとリストアが、運用マニュアル通りに実施できることを確認する
ユーザー受入テスト(User Acceptance Test)
  • 定義: ユーザーの視点で、システムが実際の業務要件を満たしているかを検証するテストのこと。
  • 略語: UAT
  • 同義語: 受入テスト
  • 説明:
    • システムテスト後に実施され、実際の業務シナリオに基づいて、要件定義書に記載された要件が正しく実現されているかを確認する。
    • 運用テストとは目的や観点が異なる別のテストだが、工程上は「リリース前の最終確認」として隣接または一部重なることもある。
  • 例: 実際の業務担当者が、日常業務で使用する画面操作、帳票出力、データ入力などを実施し、業務要件通りにシステムが動作することを確認する

解説

運用テスト(OT)とユーザー受入テスト(UAT)の違い

UAT(User Acceptance Test)と運用テスト(Operational Test)は、目的や観点が異なる別のテストである。
ただし、工程上は「リリース前の最終確認」として隣接または一部重なる
こともある。

同時期に行うこともあるが、目的・担当・合格基準は明確に分けておくのが望ましい。

どちらのテストも、ユーザー企業(顧客)が主体であることに注意。

項目 運用テスト UAT
目的 運用が成立するか? 業務要件を満たしているか?
観点 運用手順・体制中心 業務シナリオ中心
実施主体 情報システム部門(運用) 利用者・業務部門
成果 運用引継ぎの可否 受入判定(検収可否)
実施時期 リリース直前(本番移行前) リリース前(検収前)
ベンダの役割 運用立ち上げの実行支援+技術支援 技術支援者+品質保証責任者