システム開発の工程は成果物と承認でつなぐ
システム開発では、工程名だけを並べても、誰が何を確認すれば次へ進めるのかが分かりません。各工程について、目的、最小成果物、承認者、完了条件を一緒に決めると、発注者と開発者の認識を揃えやすくなります。
IPA「共通フレーム2013」は、システム、ソフトウェア、サービスの構想から開発、運用、保守、廃棄までに必要な作業項目や役割を、共通の枠組みとして整理しています。IPAの現行SLCP案内では、国際規格の改訂とともに、上流工程や運用から上流へのフィードバックも重視されていることが説明されています。
本記事の7工程は、小規模から中規模のWebシステム開発で合意点を見つけやすくするための実務整理です。共通フレームがこの工程名や順番を一律に推奨している、という意味ではありません。開発手法や契約、システムの重要度に合わせて、成果物の粒度と承認方法を調整してください。
7工程を一つの表で確認する
承認者は個人名ではなく、その成果物を業務・技術・運用の観点から判断できる役割を置きます。兼務する場合も、どの立場で承認したのかを記録します。
表は横にスクロールできます
| 工程 | 目的 | 最小成果物 | 承認者 | 完了条件 |
|---|---|---|---|---|
| 企画 | 解決する業務課題と投資判断の前提を揃える | 目的、対象業務、現状課題、制約、判断基準 | 事業責任者 | 目的、対象、対象外、継続判断者が合意されている |
| 要件定義 | 利用者が必要とする機能・品質・運用を合意する | 要件一覧、業務フロー、受入条件 | 業務責任者、発注責任者 | 要件ごとの優先度、確認方法、未決事項が記録されている |
| 基本設計 | 利用者から見える仕様とシステム境界を具体化する | 画面一覧、画面遷移、外部連携、権限、データ概要 | 業務責任者、技術責任者 | 要件と画面・連携・権限の対応が確認されている |
| 詳細設計・実装 | 実装可能な構造へ分解し、動く成果物を作る | 実装方針、コード、変更履歴、レビュー記録 | 技術責任者 | 設計との対応、レビュー、静的検査が完了している |
| テスト | 要件と受入条件を満たすか確認する | テスト計画、テストケース、結果、未解消事項 | 品質責任者、業務責任者 | 受入条件を確認し、残課題の扱いが合意されている |
| 移行 | 業務とシステムを安全に本番へ切り替える | 移行手順、切戻し手順、移行判定、連絡体制 | 業務責任者、運用責任者 | 実施可否、切戻し条件、担当者、連絡先が確認されている |
| 運用保守 | 稼働後の監視、問い合わせ、障害、変更を管理する | 運用手順、連絡先、権限台帳、変更・障害記録 | 運用責任者、システム責任者 | 定常作業、異常時対応、変更受付、終了条件が引き継がれている |
費用と作業範囲を先に揃える場合は「システム開発の見積もり」、運用保守で受け渡す情報は「システム保守の引継ぎチェックリスト」も参照してください。
小規模改修で使う一枚の記入例
工程ごとに別の資料を作る必要はありません。次は「問い合わせフォームに確認画面を追加する」という仮定の改修例です。要件、画面、受入条件をIDで結び、移行時に必要な未決事項を同じ資料へ残します。実案件では、既存の仕様と承認方法に合わせて記入してください。
案件: 問い合わせフォームの確認画面追加（仮定例）
要件 R1:
利用者: 問い合わせフォームの利用者
目的: 送信前に入力内容を確認・修正できる
対象: 確認画面と、入力画面へ戻る操作
対象外: 入力検証・送信先・保存先の変更
前提: 既存の送信処理と表示部品を利用する
承認者・承認日: 未決定／未承認
画面 S1（R1に対応）:
画面名: 問い合わせ内容の確認
表示: 入力済みの問い合わせ内容
操作: 「戻る」で入力画面へ、「送信」で既存送信処理へ進む
エラー表示: 既存の送信失敗時の表示方法を調査して合意する
受入条件 A1（R1・S1に対応）:
前提: 必須項目を入力済み
操作: 確認画面から「戻る」を押す
期待結果: 入力内容を保持した入力画面へ戻り、修正できる
確認環境・判定者: 未決定
判定結果・証跡: 未実施
移行判定:
対象・予定日時: 未決定
業務停止・制限: 未確認
バックアップ・反映手順・移行後の確認: 未確認
切戻し条件・手順: 未決定
実施可否の判定者・連絡先: 未決定
判定日時・結果: 未実施
未決事項:
- 既存送信処理のエラー表示と再操作時の挙動
- 確認環境、承認者、移行手順、切戻し条件
各項目の担当者・確認期限: 実施前に決める
受入条件は一例です。送信成功、入力不備、二重操作など、変更が影響する条件を追加して確認します。未確認欄が残っているこの例を、そのまま移行承認済みとして使ってはいけません。
工程を省略するときのルール
小規模な改修では、工程ごとに別の文書を作る必要はありません。上の例のように関連する情報をまとめます。ただし、次の情報は省略しないようにします。
- 何を対象にし、何を対象外にしたか
- 誰が承認するか
- どの条件で完了とするか
- 未決事項と残課題を誰が引き取るか
- 障害時に誰が止め、切り戻すか
AIや業務改善のPoCも本開発と同様に、目的、成果物、承認者、完了条件が必要です。PoCから本番化へ進む判断は「中小企業DXの業務選定と評価」の評価表と組み合わせると整理しやすくなります。
参照元
確認日: 2026年8月27日
- IPA「国際規格SLCP：システム＆ソフトウェアのライフサイクル・プロセス」（2025年9月30日公開、2026年8月3日最終更新）
- IPA「SEC BOOKS：共通フレーム2013」（2013年3月4日発行、公開ガイダンスと図表を2026年8月27日確認）