②要求定義からPOC・DEV・テスト・PROリリースまで.pptx

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

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

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

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

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

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

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

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

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

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

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

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

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

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