システムって、いきなりプログラムを書き始めるんですか？
いやいや、それは設計図なしで家を建てるようなものだよ。システム開発には決まった工程（手順）があるんだ。注文住宅づくりにたとえながら見ていこう。
注文住宅にたとえると
家を建てるときは、いきなり柱を立てたりしませんよね。システム開発もこれと同じ流れで進みます。
| 家づくり | システム開発の工程 |
|---|---|
| 「4人家族で、在宅勤務の部屋がほしい」と希望を伝える | 要件定義 |
| 間取り図・外観のデザインを決める | 外部設計 |
| 配線・配管・柱の位置など構造を決める | 内部設計 |
| 大工さんが実際に建てる | プログラミング |
| 水漏れや傾きがないか検査する | テスト |
| 施主が完成した家を確認して引き渡しを受ける | 導入・受入れ |
| 住みながら修理・リフォームする | 運用・保守 |
この工程を上から順番に一度だけ進めるのがウォーターフォールモデル、短い期間で何度も回すのがアジャイル開発です（進め方の違いは「ウォーターフォールとアジャイル」の単元で扱います）。どちらの進め方でも、「決める・作る・確かめる」という作業そのものは必要です。
要件定義 ― 「何を作るか」を決める
要件定義は、利用者（発注者）の要望を聞き取り、システムに求めること（要件）を決める工程です。ここで決めたことが、後の工程すべての土台になります。
要件は大きく2種類に分けられます。
| 種類 | 意味 | 例 |
|---|---|---|
| 機能要件 | システムで何ができるか | 商品を検索できる、注文履歴を表示できる、請求書を印刷できる |
| 非機能要件 | 機能以外の品質や制約 | 3秒以内に表示（性能）、24時間止まらない（可用性）、不正アクセスを防ぐ（セキュリティ）、操作がわかりやすい（使いやすさ） |
機能要件 ＝「何ができるか」、非機能要件 ＝「どれくらい良くできるか」。 家なら「部屋が4つある」が機能要件、「地震に強い」「冬も暖かい」が非機能要件です。
「〇〇できる」と書いてあっても、速さ・止まりにくさ・安全さ・使いやすさなどの「質」を表すものは非機能要件です。選択肢の文末だけで判断しないようにしましょう。
設計 ― 外側から内側へ
要件が決まったら、それを実現する方法を設計します。設計は外側（利用者から見える部分）から内側（中身）へと進めます。
- 外部設計：画面のレイアウト、帳票（印刷物）の様式、ほかのシステムとのやり取りなど、利用者から見える部分を決める。利用者にも確認してもらう
- 内部設計：外部設計の内容を実現するために、プログラムをどう分けるか、データをどう持つかなど、システム内部の仕組みを決める。主に開発者側の作業
設計が終わると、設計書に従ってプログラミング（コーディング）を行います。
レストランでいえば、外部設計は「メニュー表と料理の見た目」、内部設計は「厨房での調理手順と食材の仕込み方」です。お客さんが気にするのは前者、料理人が気にするのは後者ですね。
V字モデル ― 設計とテストは対になる
作ったものは、テストで確かめます。このとき、どの設計の内容を、どのテストで確かめるかを対応させた図が V字モデル です。
| テスト | 何を確かめる？ | 主に誰が？ |
|---|---|---|
| 単体テスト | プログラムの部品（モジュール）1つずつ | 開発者 |
| 結合テスト | 部品を組み合わせたときのデータの受渡し | 開発者 |
| システムテスト | システム全体が外部設計・要件どおりに動くか（性能なども含む） | 開発者 |
| 受入れテスト | 要件を満たしていて、受け取ってよいか | 発注者（利用者） |
受入れテストだけ、やる人が違うんですね。
そう！家の引き渡し前に施主さんが自分の目で確かめるのと同じだね。「受入れ ＝ 発注者が主役」は試験でよく問われるよ。テストの細かい技法は「テストの種類」の単元で詳しくやろう。
導入・運用・保守、そして廃棄
- 導入：完成したシステムを本番環境に移し、使える状態にする。利用者への操作教育やマニュアル整備も行う
- 運用：日々システムを動かし、利用者を支える
- 保守：稼働後に見つかった不具合の修正や、法改正・業務の変化に合わせた改良を行う
- 廃棄：使い終わったシステムを停止し、データを確実に消去する
システムは「作って終わり」ではなく、使っている期間のほうがずっと長いのが普通です。
工程をまたいで使われる道具
レビュー
各工程で作った設計書やプログラムを、複数の人で読んで誤りを探すことを レビュー といいます。誤りは早い工程で見つけるほど、直す手間（手戻り）が小さくなります。
| 方法 | 特徴 |
|---|---|
| ウォークスルー | 作成者が中心となり、関係者と一緒に成果物を順に追って確認する |
| インスペクション | 進行役（モデレータ）が主導し、役割と手順を決めて公式に行う |
共通フレーム
発注者と開発会社で「要件定義」などの言葉の意味や作業範囲がずれると、トラブルになります。そこで、システム開発の作業内容や用語を標準化した「共通の物差し」として 共通フレーム（SLCP-JCF）が作られています。
- 工程の順序は 要件定義 → 外部設計 → 内部設計 → プログラミング → テスト → 導入・受入れ → 運用・保守
- 機能要件は「何ができるか」、非機能要件は性能・可用性・セキュリティ・使いやすさなどの「質」
- 外部設計は利用者から見える部分（画面・帳票）、内部設計はシステムの中身
- V字モデル：要件定義↔受入れテスト、外部設計↔システムテスト、内部設計↔結合テスト、プログラム設計↔単体テスト
- 受入れテストは発注者（利用者）が主体
- 誤りは早い工程で見つけるほど修正コストが小さい（レビューが大事）
- 共通フレームは、取引の当事者が同じ言葉で話すための作業・用語の標準