🎯 このレッスンのゴール
- 要件定義から運用・保守までの開発工程を、順番と中身で言える
- 単体・結合・システム・受入の各テストと、ブラックボックス／ホワイトボックスの違いがわかる
- レビュー（ウォークスルー・インスペクションなど）の種類を区別できる
- ウォーターフォールとアジャイル（スクラム・XP・CI/DevOps）を対比して説明できる
こんにちは、案内役の「パスもん」です。システム開発は「家を建てる」のとそっくり。いきなり柱を立てず、まず「どんな家がほしい？」を聞いて、設計図を引いて、組み立てて、点検する。この流れと、最近よく出るアジャイルを、一緒にスッキリさせましょう！
1. システム開発の流れ（開発工程）
システム開発は、思いついた順に作るのではなく、決まった工程（プロセス）を上から順に進めていきます。まずは全体の流れをつかみましょう。各工程は次のように、前の工程の成果を受け取って次へバトンを渡します。
要件定義 → システム設計（外部設計 → 内部設計）→ プログラミング → テスト → 受入れ → 運用・保守
| 工程 | やること（中身） | 主役 |
|---|---|---|
| ① 要件定義 | 利用者の要望をヒアリングし、「システムで何を実現するか」を決めて文書（要件定義書）にまとめる。業務の流れや必要な機能・性能を固める。 | 利用者＋開発側 |
| ② 外部設計（基本設計） | 利用者から見える部分を設計する。画面のレイアウト、入力する帳票、出力するデータ、操作の流れなど。「使う人目線」の設計。 | 開発側（利用者も確認） |
| ③ 内部設計（詳細設計） | 利用者からは見えない内側を設計する。プログラムの分割（モジュール構成）、内部のデータの持ち方、処理の手順など。「作る人目線」の設計。 | 開発側 |
| ④ プログラミング | 設計をもとに、プログラム言語で実際にコードを書く（実装する）。書いたコードが正しく動くかを最初に確かめるのもこの段階。 | プログラマ |
| ⑤ テスト | 作ったものが設計・要件どおりに正しく動くかを、小さい単位から大きい単位へ順に検証する。 | 開発側 |
| ⑥ 受入れ（検収） | 完成したシステムを利用者（発注者）自身がテストし、「注文どおりにできているか」を確認して受け取る。OKなら検収となる。 | 利用者 |
| ⑦ 運用・保守 | 本番で動かし続け（運用）、不具合の修正・法改正への対応・機能追加などの手入れ（保守）を続ける。 | 運用・保守担当 |
要件定義＝「3LDKで日当たり重視」と希望を聞く段階。外部設計＝間取り図や外観など住む人が見る部分。内部設計＝柱や配管など壁の中の見えない部分。プログラミング＝実際の建築工事。テスト＝水道や電気の点検。受入れ＝施主の内覧チェック。家も「希望→設計→建築→点検」の順に進むので、システム開発も同じだとイメージできます。
外部設計＝利用者に見える側（画面・帳票）、内部設計＝見えない側（プログラム内部の構造）です。「外部＝外注先」のような意味ではありません。試験では「画面設計はどの工程か」のように問われ、答えは外部設計です。
2. テストの種類（小さい単位 → 大きい単位）
テストは、いきなり全体を動かすのではなく、部品から組み上げる順に行います。小さな単位で確実にしてから結合していくことで、不具合の原因を見つけやすくなります。
| テスト | 検証する範囲 | 対応する設計 |
|---|---|---|
| 単体テスト（ユニットテスト） | プログラムの最小単位であるモジュール1つ1つが正しく動くか。 | 内部設計 |
| 結合テスト | 複数のモジュールをつなげて、受け渡し（インタフェース）が正しいか。 | 外部設計 |
| システムテスト（総合テスト） | システム全体が、機能・性能・処理量などの要件を満たすか。負荷テストなども含む。 | 要件定義 |
| 運用テスト／受入テスト | 利用者が実際の業務の流れで使い、本番で問題なく使えるかを確認する。 | 要件定義（業務） |
「上流の設計」と「下流のテスト」は対になっています。要件定義 ↔ システムテスト、外部設計 ↔ 結合テスト、内部設計 ↔ 単体テスト。この対応をアルファベットのVの字で表したものをV字モデルといい、ITパスポートでもよく問われます。
テストの「中身の見方」：ブラックボックスとホワイトボックス
同じテストでも、どこに注目して確かめるかで2つの考え方があります。
| 技法 | 見るところ | イメージ |
|---|---|---|
| ブラックボックステスト | 内部の作りは見ず、入力に対して正しい出力が出るかだけを確認する。仕様どおりかを検証。 | 中身を開けない「箱」。料理を食べて味を確かめる。 |
| ホワイトボックステスト | プログラムの内部の処理（分岐・経路）に注目し、すべての道筋を通るかを確認する。 | 中が見える「透明な箱」。レシピの手順を1つずつ確認。 |
「年齢を入れると料金を返す」プログラムで、ブラックボックスなら「20歳→大人料金が返るか」と入出力だけを見ます。ホワイトボックスなら「子ども・大人・シニアの分岐をすべて通るテストになっているか」と内部の経路を見ます。一般に、利用者に近い単体テストやシステムテストではブラックボックスの考え方がよく使われます。
そのほかのテスト技法
| 用語 | 意味 |
|---|---|
| リグレッションテスト（回帰テスト） | プログラムを修正・追加したとき、これまで動いていた部分が壊れていないかを確かめるテスト。「直したら別のところが動かなくなった」を防ぐ。 |
| 負荷テスト（性能テスト） | 大量のアクセスやデータを与えて、性能や安定性が要件を満たすかを確かめる。 |
| ペネトレーションテスト | わざと攻撃を試みて、セキュリティ上の弱点がないかを確かめる。 |
3. レビュー（成果物をみんなで点検する）
テストはプログラムを「動かして」確かめる方法ですが、レビューは設計書やソースコードなどの成果物を人の目で読んで点検する方法です。早い工程の誤りを早く見つけるほど、修正コストが小さくてすみます。
| レビューの種類 | 内容 |
|---|---|
| デザインレビュー | 設計の成果物（設計書）が要件を満たすかを検討する会議。設計段階のレビュー全般を指す。 |
| コードレビュー | 書いたソースコードを他の人が読み、誤りや改善点を指摘する。 |
| ウォークスルー | 作成者が中心となり、関係者が成果物を順にたどって（歩いて）確認する、比較的ゆるやかなレビュー。 |
| インスペクション | 第三者の進行役（モデレータ）を立て、役割を決めて公式・厳密に欠陥を検出するレビュー。最も形式的。 |
どちらもレビューですが、ウォークスルー＝作成者主体で気軽、インスペクション＝第三者の進行役つきで公式・厳密、という違いで覚えると区別できます。
4. 開発手法（開発モデル）
「どんな進め方で開発するか」にもいくつかのモデルがあります。古くからのウォーターフォールと、近年主流のアジャイルが二大頻出です。
| 開発モデル | 特徴 |
|---|---|
| ウォーターフォール | 滝（waterfall）が上から下へ流れるように、要件定義→設計→…→テストと工程を後戻りせず順番に進める。各工程の区切りで成果物を固めるため計画・管理がしやすい。反面、後から要件が変わると手戻りが大きい。 |
| プロトタイピング | 早い段階で試作品（プロトタイプ）を作って利用者に見せ、評価をもらいながら要件を固める。認識のズレを早く防げる。 |
| スパイラルモデル | システムを部分（サブシステム）ごとに、「設計→開発→評価」をぐるぐる繰り返してらせん状（spiral）に完成度を高めていく。 |
| アジャイル | 短い期間で「設計→開発→テスト」を何度も反復し、動くソフトウェアを少しずつ作り上げる。変化に強く・素早いのが最大の特徴。 |
| DevOps（デブオプス） | 開発（Development）と運用（Operations）が協力し、自動化を活用して、リリースと改善を素早く繰り返す考え方。 |
アジャイル開発の中身（ここが頻出）
アジャイルは1つの決まった手順ではなく、「素早く・反復して・変化に対応する」考え方の総称です。代表的な用語をおさえましょう。
| 用語 | 意味 |
|---|---|
| 反復（イテレーション） | 短いサイクルを繰り返して開発を進めること。 |
| スクラム | アジャイルの代表的な手法。チームで役割を決め、短い期間の単位で計画・開発・振り返りを繰り返す。 |
| スプリント | スクラムでの1回の短い開発期間（数週間程度）。このサイクルを繰り返す。 |
| XP（エクストリームプログラミング） | アジャイルの手法の1つ。ペアプログラミング（2人で1台のPCで開発）や、テストを先に書く考え方などを重視する。 |
| 継続的インテグレーション（CI） | 各自が書いたコードを頻繁に1つに統合し、自動でビルド・テストする。不具合を早く見つけられる。 |
| リファクタリング | 動作（外から見た振る舞い）は変えずに、内部のコードを整理・改善してわかりやすくすること。 |
あるショッピングアプリを作るとき――ウォーターフォールなら「全機能の要件を最初に固め、設計→開発→テストと進めて、半年後にまとめて完成」。アジャイルなら「まず商品一覧だけを2週間で動く形にして見せ、次のスプリントでカート機能、その次に決済…」と少しずつ動くものを増やしていきます。途中で「やっぱりこの機能を先に」と変わっても対応しやすいのがアジャイルです。
ウォーターフォール vs アジャイル（対比）
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 工程を順番に1回ずつ（後戻りしない前提） | 短い反復を何度も繰り返す |
| 要件の確定 | 最初にすべて固める | 進めながら柔軟に変えられる |
| 仕様変更への強さ | 弱い（手戻りが大きい） | 強い（変化に対応しやすい） |
| 動くものが見える時期 | 終盤（最後にまとめて） | 早い段階から少しずつ |
| 計画・進捗管理 | しやすい（区切りが明確） | 全体の最終形は読みにくい |
| 向く場面 | 要件が固まっている大規模・堅い案件 | 要件が変わりやすい・素早さ重視の案件 |
5. 開発の見積り（規模・工数）
開発を始める前に、「どれくらいの手間（工数）・費用がかかるか」を見積もります。代表的な手法を、さわりだけおさえましょう。
| 手法 | 考え方 |
|---|---|
| ファンクションポイント法（FP法） | 画面・帳票・ファイルなど利用者から見た機能の数や複雑さを点数化し、その合計から規模・工数を見積もる。 |
| プログラムステップ法（LOC法） | 予想されるプログラムの行数（ステップ数）をもとに見積もる。 |
| 類推見積り | 過去の似たプロジェクトの実績を参考にして見積もる。 |
ファンクションポイント法は「利用者から見える機能」を基準に数えるのが特徴です。プログラムの中身（行数）ではなく、入出力する画面や帳票といった機能の量で測る、と覚えましょう。
6. ソフトウェアの保守と周辺の用語
システムは完成して終わりではありません。動かし続けるための保守や、開発の標準化に関わる用語もおさえておきましょう。
| 用語 | 意味 |
|---|---|
| ソフトウェア保守 | 本番運用後に、不具合の修正・性能改善・法改正対応・機能追加などを行うこと。システムの寿命の大半はこの保守の期間。 |
| リバースエンジニアリング | 既存のプログラムやシステムを分析して、設計書や仕様を逆に復元すること。出来上がったものから設計をたどる「逆向き」の作業。 |
| フォワードエンジニアリング | 逆に、復元・改善した設計から新しいシステムを作り直すこと。 |
| 共通フレーム（SLCP） | 企画・要件定義・開発・運用・保守など、ソフトウェアのライフサイクル全体で使う作業や用語を共通化した枠組み。発注者と開発者が同じ言葉で認識を合わせるための「共通のものさし」。 |
発注者と開発会社が、それぞれ違う言葉や手順で話すと「言った・言わない」のトラブルが起きます。共通フレーム（SLCP）は、両者が同じ用語・同じ工程の区切りで会話できるようにする「共通の地図」のようなもの。これがあると、役割分担や見積りの認識がそろいやすくなります。
〇か×で答えてみましょう。ボタンを押すと答えと解説が出ます。
Q1. システム開発は、要件定義 → システム設計 → プログラミング → テスト → 運用・保守の順に進む。
正解は 〇。要望を固める要件定義から始まり、設計・実装・テストを経て、最後に運用・保守へと進みます。
Q2. 画面のレイアウトなど、利用者から見える部分を決めるのは内部設計である。
正解は ×。利用者から見える部分（画面・帳票など）を設計するのは外部設計（基本設計）です。内部設計はプログラム内部の構造を決めます。
Q3. 単体テストはモジュール1つ1つ、結合テストは複数モジュールをつないだ受け渡しを確認する。
正解は 〇。テストは小さい単位（単体）から、つなげた単位（結合）、全体（システム）へと段階的に行います。
Q4. ブラックボックステストは、プログラム内部の分岐や経路をすべて通るかを確認するテストである。
正解は ×。それはホワイトボックステストの説明です。ブラックボックステストは内部を見ず、入力に対する出力（仕様どおりか）を確認します。
Q5. 修正によって、これまで正しく動いていた部分が壊れていないかを確認するのがリグレッションテストである。
正解は 〇。リグレッションテスト（回帰テスト）は、変更後に既存機能が影響を受けていないかを確かめます。
Q6. アジャイル開発は、短い期間の反復を繰り返すため、仕様変更に対応しやすい。
正解は 〇。アジャイルは反復しながら少しずつ作るため、途中の変化に柔軟です。逆にウォーターフォールは手戻りが大きくなりがちです。
Q7. 既存のプログラムを分析して設計書や仕様を復元することを、フォワードエンジニアリングという。
正解は ×。出来上がったものから設計を逆にたどるのはリバースエンジニアリングです。フォワードはその逆（設計から作り直す方向）です。
Q1. 利用者の要望を聞き、システムで何を実現するかを決める工程は？
Q2. 利用者から見えない、プログラム内部の構造を決める設計は？
Q3. 要件定義と対応し、システム全体が要件を満たすか確かめるテストは？
Q4. 設計とテストの対応関係をVの字で表したモデルは？
Q5. 第三者の進行役を立てて、公式・厳密に欠陥を検出するレビューは？
Q6. 工程を後戻りせず、上から順に1回ずつ進める開発モデルは？
Q7. スクラムでの、1回の短い開発期間を何という？
Q8. 利用者から見た機能の数や複雑さを点数化して規模を見積もる手法は？
📌 このページのまとめ
- 開発工程は要件定義 → 外部設計 → 内部設計 → プログラミング → テスト → 受入れ → 運用・保守の順。
- 外部設計＝利用者に見える側（画面・帳票）、内部設計＝見えない側（内部構造）。
- テストは単体 → 結合 → システム → 運用（受入）へ。設計と対応させたものがV字モデル。
- ブラックボックス＝入出力（仕様）を確認、ホワイトボックス＝内部の経路を確認。修正後はリグレッションテスト。
- レビューは、作成者主体のウォークスルーと、第三者進行で公式のインスペクションがある。
- 開発モデルはウォーターフォール（順番・変更に弱い）とアジャイル（反復・変更に強い／スクラム・スプリント・XP・CI・DevOps）が二大頻出。
- 見積りはファンクションポイント法（機能の量で測る）など。保守・リバースエンジニアリング・共通フレーム（SLCP）もおさえる。