No.01
システム企画
System Planning
経営課題・業務課題を解決するために、システム化の目的・効果・概略要件・概算予算を整理する工程。要件定義の前段で、「そもそも作るべきか」を決める意思決定の場でもあり、ここを飛ばすと後工程で迷走しやすい。
IT Glossary
SI 工程・成果物・モダン開発手法 用語集
50 のキーワード
SI プロジェクトの会話で日常的に飛び交う「基本設計」「結合テスト」「カットオーバー」──同じ言葉でも、ベンダー・お客様・新人メンバーの頭の中にある「その工程で何が決まり、何が成果物として残るか」のイメージは想像以上に揺れています。
本ページでは、ウォーターフォール開発の各工程（要件定義 → 設計 → 開発・テスト → リリース・運用）を骨格に、それぞれの工程で作成される代表的な成果物と、最後に近年の主流であるアジャイル・DevOps 等のモダン手法を加えた 5 つのカテゴリ・50 語 に整理しました。
PHASE 01
要件定義
RFP / 要件定義書 / 業務フロー
PHASE 02
設計
基本設計書 / 詳細設計書 / ER 図
PHASE 03
開発・テスト
ソースコード / UT・IT・ST 仕様書
PHASE 04
リリース・運用
移行計画書 / 運用設計書 / SLA
PHASE 05
モダン手法
V字 / アジャイル / DevOps / SRE
01
要件定義 — Requirements
REQUIREMENTSNo.02
業務要件
Business Requirements
「どんな業務を、どんな手順で、誰が行うか」という業務側からの要求。As-Is 業務フローと To-Be 業務フローを描き、業務がどう変わるかを定義する。システム要件はこの上に乗せて初めて意味を持つ。
No.03
機能要件
Functional Requirements
システムが「何をするか」を定義した要件。画面・帳票・処理・連携・データなどの単位で記述する。あいまいさをなくすため、ユースケース／業務シナリオ／一覧表の組み合わせで構造化するのが定石。
No.04
非機能要件
Non-Functional Requirements
機能以外の性能・可用性・セキュリティ・運用性・拡張性に関する要件。IPA の「非機能要求グレード」を物差しにすると論点漏れを防げる。後工程で揉めるのはたいていここの定義不足が原因。
No.05
RFP / RFI / 要件定義書
RFP / RFI / Requirements Document
RFI（情報提供依頼書）で候補ベンダーから情報収集し、RFP（提案依頼書）で提案を受ける。要件定義工程の最終成果物として要件定義書（RD）を確定し、以降の設計・見積りの土台となる。
No.06
ユースケース図
Use Case Diagram
「アクター（利用者）がシステムを使って何を実現するか」を、楕円のユースケースと矢印で表す UML 図。業務要件と機能要件の橋渡しに使われ、関係者の合意形成にも役立つ。
No.07
業務フロー（As-Is / To-Be）
Business Flow Diagram
業務の「現状の流れ（As-Is）」と「目指す流れ（To-Be）」を可視化したもの。レーン分け（スイムレーン）で部署や役割を明示し、システム化対象・人手対応・例外処理を浮かび上がらせる。
No.08
ステークホルダー
Stakeholder
業務部門・経営層・情シス・利用者・運用保守・監査・外部ベンダーなど、システムに影響を与え・受ける関係者の総称。要件は「誰の要件か」によって優先度も内容も変わるため、洗い出しは初期工程の必須作業。
No.09
スコープ定義
Scope Definition
プロジェクトで「やること」と「やらないこと」の境界線を明示すること。後工程の見積り・スケジュール・契約の根拠となるため、要件定義書には「対象外（Out of Scope）」も同等に明記する。
No.10
要件トレーサビリティ
Requirement Traceability
業務要件 → 機能要件 → 設計書 → テストケースまでをID で紐づけて追跡できる状態にすること。変更要求の影響範囲特定・テストカバレッジ証明・監査対応に効くため、規模が大きいほど重要になる。
02
設計 — Design
DESIGNNo.11
基本設計（外部設計）
Basic Design / External Design
要件定義の内容をシステムの外側から見える形に落とす工程。画面遷移・帳票レイアウト・データ項目・他システム連携・処理方式を決める。利用者・業務部門が読めるレベルの設計書が成果物。
No.12
詳細設計（内部設計）
Detailed Design / Internal Design
基本設計を受けて、プログラム単位の処理ロジック・データ構造・モジュール分割を定義する工程。エンジニアが直接コーディングできる粒度に落とすのがゴール。クラス図・シーケンス図・処理フローが中心成果物。
No.13
画面設計書（UI 仕様書）
UI Specification
画面のレイアウト・入力項目・バリデーション・遷移条件・権限を定義した文書。最近はワイヤーフレームと Figma のプロトタイプを正本として扱う現場も増えている。
No.14
ER 図
Entity Relationship Diagram
データの実体（Entity）と関連（Relationship）を表現したデータモデル図。論理 ER と物理 ER に分け、業務概念モデルから DB 物理設計までの橋渡しを担う。データの一貫性・拡張性を左右する重要成果物。
No.15
DB 物理設計
Physical DB Design
論理データモデルを実際の RDBMS に落とし込む設計。テーブル定義（DDL）、インデックス、パーティション、文字コード、データ型、制約、命名規則などを決める。性能・保守性に直結する。
No.16
クラス図 / シーケンス図
Class / Sequence Diagram
UML の代表図。クラス図は静的な構造（クラスと関連）、シーケンス図は時系列のメッセージのやりとりを表す。複雑な処理ロジックの設計や、レビューでの認識合わせに有効。
No.17
インターフェース設計
Interface Design
他システムや外部 SaaS とどのプロトコル・形式・タイミング・粒度でやり取りするかを決める設計。REST API、SOAP、ファイル連携、メッセージキューなどの選定、API スキーマや I/F 仕様書として残す。
No.18
バッチ設計
Batch Design
夜間・日次・月次で大量データを一括処理する仕組みの設計。実行順序・依存関係・リカバリ・タイムアウト・並列度を決める。バッチウィンドウ内に収まらない問題はプロジェクト終盤の典型的炎上要因。
No.19
アーキテクチャ設計書
Architecture Design Document
システム全体の構成要素・配置・通信・技術選定の根拠を記す設計書。論理アーキテクチャ／物理アーキテクチャ／配置図（デプロイメント図）を組み合わせ、SRE・運用・セキュリティの目線が揃う。
No.20
非機能設計（性能・セキュリティ）
Non-Functional Design
レスポンスタイム・同時接続数・スループット・可用性 SLO・バックアップ・脆弱性対策・監査ログなど、非機能要件を実装方針まで落とす設計。ここで決めた数字がそのまま受け入れ基準となる。
03
開発・テスト — Development & Test
DEVELOPMENT & TESTNo.21
製造（コーディング）
Implementation / Coding
詳細設計に沿って実際にプログラムを書く工程。SI 用語では「製造」と呼ばれるが、本質はソフトウェアの創造活動。最近は AI コーディング支援（Copilot 等）で生産性と品質の双方に変化が生じている。
No.22
コーディング規約
Coding Standards
命名規則・インデント・コメント・例外処理・セキュリティ留意点などを定めた開発チームの共通ルール。Linter/Formatter で自動チェックすることで運用負荷を下げ、レビューを「人にしかできない論点」に集中させる。
No.23
コードレビュー
Code Review
プルリクエスト単位で仲間がコードを読み、設計・品質・読みやすさを点検する活動。バグ抑止と知見共有・属人化解消の三役を担う。GitHub・GitLab・Bitbucket がデファクトプラットフォーム。
No.24
単体テスト（UT）
Unit Test
関数・クラス・モジュール単位で仕様どおりの入出力が得られるかを検証するテスト。多くは開発者が JUnit / pytest / Jest 等で書く自動テストとして実装される。CI に組み込むのが現代の標準。
No.25
結合テスト（IT）
Integration Test
複数のモジュール・サブシステム・外部 API をつなげた状態で動作を検証するテスト。基本設計の単位がスコープになることが多く、I/F・データ受け渡し・トランザクション境界が主な確認ポイント。
No.26
システムテスト（ST）
System Test
本番相当環境でシステム全体の機能・非機能を検証するテスト。性能・負荷・障害復旧・セキュリティ・運用シナリオまで含めることが多く、ベンダー側で完結する最終工程に相当する。
No.27
受入テスト（UAT）
User Acceptance Test
発注者・業務部門が実際に操作して受入可否を判断するテスト。要件定義書・業務シナリオに沿って合否判定し、ここで合格 → 検収 → 本番リリースという流れになる。契約上の重要マイルストーン。
No.28
テスト仕様書
Test Specification
テストの観点・ケース・期待結果・前提条件・データを構造化した文書。テスト観点表・ケース表・結果記録表の 3 点セットが一般的。要件・設計とトレーサビリティを取って初めて品質保証の証跡となる。
No.29
バグ管理（チケット）
Bug / Issue Tracking
検出されたバグや要修正事項をチケットとして登録・優先度付け・担当割当・状態管理する仕組み。Jira / Backlog / Redmine / GitHub Issues などを使う。日次でバグ件数・重要度・滞留時間をモニタリングする。
No.30
テストカバレッジ
Test Coverage
テストがコードや仕様のどの程度をカバーしているかを定量化する指標。命令網羅 (C0) / 分岐網羅 (C1) / 条件網羅 (C2) などがある。高いほど良いとは限らず、「重要箇所が網羅されているか」が本質。
04
リリース・運用 — Release & Operations
RELEASE & OPERATIONSNo.31
移行計画
Migration Plan
既存システム・業務から新システムに切り替えるための計画。データ移行・並行稼働・段階移行・一斉移行などの方式選定、リハーサル、移行リハ計画書まで含む。ここの精度がリリース成功率を決める。
No.32
リリース手順書
Release Runbook
本番リリース当日に誰が・何を・どの順番で・どの判定基準で行うかを時系列で書いた手順書。事前点検・実施・確認・切り戻しまで網羅する。1 行ずつチェックして進めるのが基本動作。
No.33
カットオーバー
Cut-over / Go-Live
旧システム停止・新システム稼働開始の切替の瞬間。週末・夜間・GW などの停止可能タイミングで実施することが多い。事前リハーサル、当日体制、判定基準、コミュニケーションプランがセットで必要。
No.34
切り戻し（ロールバック）
Rollback
リリースで重大障害が発生した際に旧状態に戻す手順。「実施判断基準・実行手順・終了判定」を事前に文書化し、リハーサルで時間計測することで「迷わず判断できる」状態を作る。
No.35
運用設計書
Operations Design Document
運用フェーズで何を・誰が・どのタイミングで行うかを定義した文書。監視・バックアップ・障害対応・定例作業・申請フロー・運用体制を網羅する。リリース前にこれが空白なまま本番に行ってはいけない。
No.36
SLA / SLO / SLI
SLA / SLO / SLI
サービス品質の約束（SLA）・社内目標（SLO）・観測指標（SLI）の三層構造。可用性 99.9% といった数字の裏にあるエラーバジェットの考え方は、SRE 文化の中核を成す。
No.37
インシデント管理
Incident Management
本番障害・サービス停止が発生した際の検知・初動・復旧・連絡・事後分析のプロセス。ITIL の用語で、重大度（Severity）と優先度（Priority）を分けて運用する。事後の Postmortem で組織学習する。
No.38
変更管理（ITIL）
Change Management（ITIL）
本番環境への変更を計画・評価・承認・実行・記録する一連のプロセス。標準変更／通常変更／緊急変更を区別し、変更諮問委員会（CAB）で審議する。リスクと監査の双方を担保する仕組み。
No.39
監視 / アラート
Monitoring / Alerting
システムの状態を継続的に観測し、しきい値を超えたら通知する仕組み。インフラメトリクス・APM・ログ監視・合成監視・SLO 監視のレイヤーがあり、Datadog / New Relic / Grafana / CloudWatch などが代表ツール。
No.40
保守
Maintenance
本番稼働後の修正・改善・機能追加・OS/MW アップデート対応などの活動。是正保守・予防保守・適応保守・完全化保守の 4 分類が ISO/IEC 14764 で定義され、保守契約の根拠となる。
05
モダン開発手法 — Modern Approaches
MODERN APPROACHESNo.41
V 字モデル
V-Model
要件 → 設計 → 製造 → テストの工程を V 字に対応付けたモデル。要件と UAT、基本設計と ST、詳細設計と IT、製造と UT が左右対称の関係になる。ウォーターフォール時代の品質保証の基本フレーム。
No.42
W 字モデル
W-Model
V 字モデルを発展させ、各工程と並行してテスト設計を進めるモデル。要件定義時に UAT 観点を、基本設計時に ST 観点を、というように左右の山が「W」を描く形でテスト設計を前倒しする。
No.43
アジャイル / スクラム
Agile / Scrum
短い反復（スプリント）で動くソフトウェアを作りながらフィードバックで方向修正する開発思想と、その代表フレームワーク。プロダクトオーナー・スクラムマスター・開発チームの 3 役で運営される。
No.44
DevOps
DevOps
開発（Dev）と運用（Ops）の連携・自動化・文化を統合する考え方。CI/CD・モニタリング・インフラ自動化・Blameless な振り返りなどで、ソフトウェアを安全かつ高速に届けるための実践群。
No.45
CI/CD
Continuous Integration / Continuous Delivery
コード変更を継続的にビルド・テストし、自動でデプロイ可能な状態にしておく仕組み。GitHub Actions・GitLab CI・Jenkins・CircleCI などが代表ツール。リリースを「特別なイベント」から「日常」に変える。
No.46
シフトレフトテスト
Shift-Left Testing
テスト活動を従来より早い工程（要件・設計・コーディング段階）に前倒しする考え方。早期発見ほど修正コストが安く、品質も上がる。テスト自動化・静的解析・コードレビュー・契約テストが具体策。
No.47
テスト駆動開発（TDD）
Test-Driven Development
「失敗するテストを書く → 通すコードを書く → リファクタする」というサイクルでコードを育てる開発手法。設計を導く副作用としても重要で、ユニットテストが自然と充実するため、後続のリファクタコストを下げる。
No.48
Infrastructure as Code（IaC）
IaC
サーバー・ネットワーク・クラウドリソースをコードで定義し、Git で管理する考え方。Terraform・AWS CDK・Bicep・Ansible・Pulumi が代表ツール。手作業の構築から、レビュー＆再現可能な構築へと運用を変えた。
No.49
SRE
Site Reliability Engineering
Google 発の「ソフトウェアエンジニアリングで運用問題を解く」職種・方法論。SLO・エラーバジェット・トイル削減・ポストモーテムなどの実践で、「壊れにくく速く直せる」サービスを育てる。
No.50
ハイブリッド開発（WF＋アジャイル）
Hybrid Development
日本の SI 現場で最も実態に近い形。要件定義はウォーターフォール、開発はアジャイル、運用は DevOps/SREのように、フェーズや特性ごとに最適な手法を組み合わせるアプローチ。「正解はひとつではない」現実解。