---
title: ②要求定義からPOC・DEV・テスト・PROリリースまで.pptx
tags:  #システム工学  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GEWGV1X3J2.jpg?width=480
description: ②要求定義からPOC・DEV・テスト・PROリリースまで.pptx by Yukiko
published: August 10, 26
canonical: https://image.docswell.com/s/yukiko_it/57NLJN-2026-08-10-231826
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GEWGV1X3J2.jpg)

うさうさ先生の開発工程図解シリーズ
要求定義から POC・DEV・テスト・ PROリリースまで
システム開発の一連の流れを、はじめての方にもわかる図解でたどる研修教材
新人向け
文系出身の方向け
Usausa Training Workshop / うさうさ研修工房
中堅の振り返りにも
査読済み文献ベース


# Page. 2

![Page Image](https://bcdn.docswell.com/page/47ZL4P6GJ3.jpg)

INTRODUCTION
なぜ「全体の流れ」を先に知るべきか
工程の後半で見つかった手戻りほど、直すコストが大きくなりやすい
修正コストの相対的な大きさ（イメージ）
うさうさ先生 1980年代にBarry Boehmが分析した
データでは、要求定義の段階で見つかる誤りは修
正が軽く、リリース後に見つかると数十〜百倍のコ
ストがかかると報告されました。 2001年のBoehmと
Basiliの再検証では、小規模でアジャイル・ CI/CDを
使うプロジェクトほど、この差はゆるやかになるとも
指摘されています。「早く見つけるほど得」という向
きは今も変わりません。だからこそ、私たちは工程
の全体像を先に押さえます。
要求定義
設計
開発
テスト
リリース後
出典：Boehm, Software Engineering Economics (1981) ／ Boehm & Basili, “Software Defect Reduction Top 10 List,” IEEE Computer, 2001
うさうさ研修工房｜要求定義から PROリリースまで
02


# Page. 3

![Page Image](https://bcdn.docswell.com/page/YJ6W3M2QJV.jpg)

ROADMAP
全体マップ： 8つのステップ
このあと1ステップずつ、ゆっくり図解していきます
1
2
3
4
5
6
7
8
要求定義
要件定義
PoC
設計
開発
(DEV)
テスト
環境昇格
リリース
(PRO)
困りごとを聞く
作るものを言葉に
する
小さく試す
作り方を決める
コードを書く
品質を確かめる
DEV→STG→PRO
利用者に届ける
うさうさ先生 現場ではPoCが要件定義の前後どちらに来るかは案件によって違いますが、「言葉にする」 →「小さく試す」 →「本格的に作る」 →「確
かめる」→「届ける」という骨組みは共通しています。まずはこの骨組みを覚えましょう。
うさうさ研修工房｜要求定義から PROリリースまで
03


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GJ5MLZ22J4.jpg)

1
STEP 1
要求定義（ようきゅうていぎ）
「何にこまっているか」をお客さまの言葉で聞き出す工程
やること
アウトプット
• 業務の現状（現行業務）をヒアリング
• 要求仕様書 / 提案依頼書（ RFP）への回答
• 困りごと・実現したいことを整理
• 業務フロー図・現状の課題一覧
• 「なぜそれが必要か」という背景を確認
• 経営層・現場それぞれの要望の整理
• 予算・納期など前提条件を確認
• 次工程（要件定義）での確認事項リスト
うさうさ先生 ここではまだ「どう作るか」は決めません。文系出身の方が最も力を発揮しやすい工程で、専門用語よりも「相手の困りごとを聞く
力」が問われます。ここでのズレは後工程すべてに影響するため、曖昧な言葉（『使いやすく』『速く』など）は具体的な数字や場面に置き換えて
確認しましょう。
うさうさ研修工房｜要求定義から PROリリースまで
04


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LE3WL9K1E5.jpg)

2
STEP 2
要件定義（ようけんていぎ）
要求を「機能要件」と「非機能要件」に翻訳し、作るものを言葉と数字にする
機能要件（何ができるか）
非機能要件（どう動くべきか）
• 画面・帳票・データの入出力仕様
• 性能（応答◯秒以内 等）・可用性
• 業務フローに沿った処理の流れ
• セキュリティ・アクセス権限
• 他システムとの連携仕様
• 保守性・拡張性・運用ルール
• 「ログインできる」「一覧が検索できる」等
• IPA「非機能要求グレード」等が参考になる
うさうさ先生 研究では、要件定義フェーズの品質がプロジェクトの成否と予算遵守に強く影響し、この段階の欠陥は見つからないまま放置され
るほどコストが指数的に増えると報告されています（ Requirements quality研究のレビューより）。「言った／言わない」を防ぐため、要件は文書
化し、依頼主と合意（サインオフ）を取るのが基本です。
うさうさ研修工房｜要求定義から PROリリースまで
05


# Page. 6

![Page Image](https://bcdn.docswell.com/page/8EDKNG3K7G.jpg)

3
STEP 3
PoC（Proof of Concept・概念実証）
本格開発の前に、リスクの高い部分だけを小さく試して「できるか」を確かめる
なぜ行うか
• 新しい技術・外部連携の実現可能性を確認
• 性能が要件を満たせそうか小規模に検証
• 「作れないものを大きく作り始める」リスクを回避
• 投資判断（Go / No-Go）の材料にする
PoCと似た言葉の違い
• PoC＝技術やアイデアが『成立するか』の検証
• プロトタイプ＝画面や操作感を『見て試す』もの
• MVP（実用最小限の製品）＝実際に利用者へ届け反応を見るも
の
• 目的が異なるため、混同せず使い分ける
うさうさ先生 PoCは数日〜数週間の短期間で行い、反復して作り込むものではありません。「うまくいかない」という結果も PoCの立派な成果で
す。ここで技術的な不安を先につぶしておくことで、後工程の設計・開発が安定します。
うさうさ研修工房｜要求定義から PROリリースまで
06


# Page. 7

![Page Image](https://bcdn.docswell.com/page/V7PK5343J8.jpg)

4
STEP 4
設計（基本設計・詳細設計）
要件定義で決めた「何を作るか」を、「どう作るか」に落とし込む
基本設計（外部設計）
詳細設計（内部設計）
• 画面レイアウト・帳票の見た目
• プログラムの内部構造・処理ロジック
• 業務フローとシステムの役割分担
• テーブル定義・ API仕様など技術詳細
• データベースの大まかな構造
• 開発者がそのまま実装できるレベルの資料
• 依頼主が読んで確認できるレベルの資料
• 設計変更はここまでに収めるのが理想
うさうさ先生 Boehmのコスト曲線が示すとおり、設計段階での見直しは開発・テスト段階よりずっと軽くすみます。『とりあえず作りながら考える』
のではなく、設計書に一度言葉として落とし、レビューを挟むことが手戻りを防ぎます。
うさうさ研修工房｜要求定義から PROリリースまで
07


# Page. 8

![Page Image](https://bcdn.docswell.com/page/2JVVP4XNJQ.jpg)

5
STEP 5
開発（DEV環境での実装）
設計書をもとにプログラムを書き、動くものにしていく工程
この工程での役割分担
DEV環境とは
• エンジニア：設計に沿って実装
• 開発者だけが使う『実験用の作業場』
• PO / ブリッジ担当：仕様の疑問点を都度確認
• 本番データは置かず、壊れても影響が小さい
• 文系出身の方も、仕様の橋渡し役として活躍できる
• 自由に試し、失敗しながら組み上げる場所
• コードレビューで書いた人以外の目を通す
• ここでの動作確認だけでは本番相当を保証しない
うさうさ先生 「DEV」は開発（Development）の略で、環境の名前でもあります。次のテスト工程・環境昇格の話とあわせて覚えると、
『DEV→STG→PRO』という環境の流れがすっきり理解できます。
うさうさ研修工房｜要求定義から PROリリースまで
08


# Page. 9

![Page Image](https://bcdn.docswell.com/page/5EGLP1V5JL.jpg)

6
STEP 6
テスト①：テストピラミッドという考え方
「小さいテストをたくさん・大きいテストは少なめに」が定石
遅い・高い（少数）
E2E（受け入れ）テスト
画面から実際の操作で確認・少数
結合（統合）テスト
機能同士の連携を確認・中程度
単体テスト
関数・部品単位を確認・数が最も多い
速い・安い（多数）
出典：Mike Cohn, “Succeeding with Agile” (2009) を Martin Fowler が体系化した Test Pyramid の考え方
うさうさ先生 画面をポチポチ確認するテスト（ E2E）だけに頼ると、遅くて壊れやすくなりがち。土台となる単体テストを厚くするのが安定の近道で
す。
うさうさ研修工房｜要求定義から PROリリースまで
09


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4JQY2D6L7P.jpg)

6
STEP 6
テスト②： 4つのテスト工程
小さい単位の確認から、利用者目線の確認へと段階的に広げる
開発側が行うテスト
利用者側が行うテスト
• 単体テスト：部品（関数・クラス）ごとの確認
• 受け入れテスト（ UAT）：依頼主・現場担当者が確認
• 結合テスト：部品同士をつないだ確認
• 実際の業務シナリオに沿って操作してみる
• システムテスト：システム全体を要件どおりに確認
• ここでの合格が、本番リリースの最終ゲート
うさうさ先生 テストは『バグ探し』であると同時に『要件定義どおりに作れているかの答え合わせ』でもあります。だからこそ、要件定義の言葉が
曖昧だとテストの合格基準も曖昧になります。工程は独立しておらず、すべてつながっています。
うさうさ研修工房｜要求定義から PROリリースまで
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/K74WLZ45E1.jpg)

7
STEP 7
環境の昇格： DEV → STG → PRO
同じプログラムを、段階を踏んで『本番に近い場所』へ動かしていく
1
2
3
DEV環境
STG環境
PRO環境
開発環境
ステージング環境
本番環境
開発者が自由に試す作業場。頻繁に壊れてよ
い場所。
本番とほぼ同じ構成でリハーサル。最終テスト
の舞台。
実際の利用者が使う場所。変更は最も慎重
に。
うさうさ先生 PoCやテストのやり直しが『 DEVでの実験』だとすれば、 STGは『本番の本番前リハーサル』。 PROに近づくほど変更は重くなる
ため、Boehmの曲線と同じ理屈で、早い段階＝ DEVでしっかり試すことが安全です。
うさうさ研修工房｜要求定義から PROリリースまで
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LJ1YLR42EG.jpg)

8
STEP 8
リリース（ PRO環境）と運用
作って終わりではなく、利用者に届けたあとも工程は続く
リリース時に行うこと
リリース後（運用・保守）
• 本番データへの移行・切り替え作業
• 稼働監視、障害対応
• リリース手順書に沿った公開
• 利用者からの問い合わせ・改善要望の受付
• 問題発生時に前の状態へ戻す『切り戻し』準備
• 軽微な改修は次の要件定義サイクルへ
• 利用者・関係者への周知
• 『作って終わり』ではなく循環していく
うさうさ先生 PROは本番（Production）の略。ここでの障害は利用者に直接影響するため、事前のテストと環境昇格が丁寧であるほど、リリー
ス後の安心につながります。ここまでの 8ステップは一直線ではなく、改善のたびに繰り返すサイクルです。
うさうさ研修工房｜要求定義から PROリリースまで
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GJWGV1X272.jpg)

SUMMARY
まとめ： 8ステップはひとつながりの物語
1
要求定義：困りごとを聞く
5
開発（DEV）：手を動かして形にする
2
要件定義：作るものを言葉と数字にする
6
テスト：要件どおりか答え合わせする
3
PoC：小さく試してリスクをつぶす
7
環境昇格：DEV→STG→PROへ慎重に進む
4
設計：作り方を決める
8
リリース（PRO）：届けて、また次の要求へ
早く言葉にし、早く小さく試し、早く確かめる ―― それがどの工程にも通じる合言葉です。
うさうさ研修工房｜要求定義から PROリリースまで
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4EZL4P6473.jpg)

REFERENCES
参考文献・出典
本資料は査読済み論文・一次情報をもとに構成しています
• Boehm, B. W. Software Engineering Economics. Prentice-Hall, 1981.
• Boehm, B. W., & Basili, V. R. “Software Defect Reduction Top 10 List.” IEEE Computer, 34(1), 2001, pp. 135–137.
• Cohn, M. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009.
• Fowler, M. “The Practical Test Pyramid.” martinfowler.com, 2018.
• Frattini, J. et al. “Requirements Quality Research: a harmonized Theory, Evaluation, and Roadmap.” Requirements Engineering, 2023.
• 情報処理推進機構（IPA）「システム構築の上流工程で使う 非機能要求グレード」
うさうさ先生 事実と印象を分けてお伝えするのが、うさうさ研修工房の原則です。断定できない部分は『〜と報告されています』のように出典つき
で表現しています。
うさうさ研修工房｜要求定義から PROリリースまで
14