「要件定義」「設計」「テスト」などの工程名を聞いて、自分の作業が全体のどこにあるのか迷ったことはありませんか。
システム開発は、必要なことを決め、設計し、作って確認し、利用できる状態にする活動です。利用開始後も運用や改善が続きます。
この記事では、その流れを7つの工程に整理して解説します。各工程の役割と、前後のつながりをつかみましょう。
💡 このページでわかること
- システム開発の全体像と7つの工程の役割
- 基本設計と詳細設計の違い
- システムテストと受入テストで確認すること
- 工程を順に進める方法と、繰り返す方法
システム開発の流れ｜7つの工程で全体像をつかもう
システム開発の流れは、必要なことを決める → 設計する → 作る → 確認する → 利用を始める → 使い続けながら改善すると考えると理解しやすくなります。
この記事では、主な活動を次の7つに分けます。
| 工程 | 主な役割 | 決めること・作るものの例 |
|---|---|---|
| 1. 要件定義 | 何が必要か、どの条件を満たすか合意する | 必要な機能、速さや安全性などの条件 |
| 2. 設計 | 要件を実現する方法を具体化する | 画面や機能、内部の処理の設計 |
| 3. 実装 | 設計を動く形にする | プログラムや設定 |
| 4. テスト | 必要な動きや品質を備えているか確かめる | 確認結果、見つかった問題の記録 |
| 5. リリース | 利用者が使える状態にする | 利用開始の準備と切り替え |
| 6. 運用・保守 | 安定して使い続けられるようにする | 日々の確認、不具合の修正など |
| 7. 改善・追加開発 | 新しい要望や変化に対応する | 機能の追加、使いやすさの改善など |
7工程は、この記事で全体像を説明するための分け方です。決まった唯一の分類ではありません。 会社やプロジェクトによって、名前や区切り、進める順番は変わります。
要件定義より前には、導入の目的や予算、実現できるかを考える企画・計画があります。また、旧システムからの移行や、役割を終えたシステムの利用終了・廃棄を独立して扱うこともあります。7つの外にも必要な活動があると押さえておきましょう。
工程1：要件定義｜必要なことや条件を合意する
要件定義では、システムの目的、必要な機能、満たすべき条件を関係者で整理し、合意します。
飲食店の予約システムなら、次のような内容です。
- お客さんが空いている日時を選んで予約できる
- 店舗スタッフが予約の確認・変更・キャンセルを扱える
- 予約できる人数や、受付を締め切る時刻のルールを守れる
- 利用が集中しても必要な速さで動き、個人情報を適切に扱える
欲しい機能だけでなく、今回作る範囲や予算・期限も確認します。「使いやすくする」だけでは判断できないので、誰が何をできればよいかを具体的にすることが大切です。
整理や合意の進め方は、要件定義の解説で詳しく紹介しています。
工程2：設計｜実現する方法を具体化する
設計では、要件をどのような画面、機能、データの扱い、システムの仕組みで実現するかを決めます。
基本設計と詳細設計に分けて説明されることがありますが、その名前や境界はプロジェクトによって異なります。2つを分けない場合もあります。
基本設計
基本設計では、要件を実現する画面や仕組みを具体化します。画面や操作の流れに加え、扱うデータや外部サービスとの連携なども対象になります。
予約システムなら、日時・人数の入力欄、予約内容を確認する画面、予約できない場合の案内などを決めます。
決める内容の具体例は、基本設計の解説を参考にしてください。
詳細設計
詳細設計では、実装に必要な内部の処理をさらに詳しくします。
たとえば、入力内容の確認、空き状況の確認、予約情報の保存を、プログラム内でどう組み立てるかを決めます。失敗したときの処理も具体化します。
ただし、失敗時に利用者へ何を表示するかなど、基本設計で決める内容もあります。作業名だけで機械的に分けず、何をどこまで決めるかを確認します。
工程3：実装｜設計を動く形にする
実装とは、設計をもとにプログラムや設定を用意し、実際に動くシステムを作る作業です。「製造」と呼ぶ職場もあります。
予約システムなら、画面を作り、予約を受け付ける処理を書き、予約情報を保存・検索する仕組みであるデータベースを用意します。必要に応じて、メール送信サービスなどにも接続します。
実装した部分を動かして確認したり、ほかの担当者に内容を確認してもらったりしながら進めます。
工程4：テスト｜必要な動きや品質を確かめる
テストでは、作ったものが要件や設計で決めた内容を満たすか確認します。代表的な分け方は次のとおりです。
| テスト | 主に確かめること |
|---|---|
| 単体テスト | 個々のプログラムの部品が、単独で意図した動きをするか |
| 結合テスト | 部品や機能をつないだとき、情報の受け渡しや処理の連携が正しいか |
| システムテスト | システム全体が、要求された機能や速さ・安全性などを備えているか |
| 受入テスト | 利用者の仕事や目的に合い、合意した条件に照らして受け入れられる状態か |
結合テストには、対象システムと外部サービスのつながりを確認する「システム結合テスト」もあります。分類や名称、実施時期はプロジェクトによって変わります。
システムテストと受入テストの違い
予約システムのシステムテストでは、予約から変更・キャンセルまでが決めたとおりに動くか、利用が集中しても必要な速さで処理できるかなどを確認します。
受入テストでは、店舗スタッフが実際の仕事の手順に沿って予約を確認し、席の準備などに必要な情報を得られるかといった点を確かめます。受け入れ基準、つまり「どの状態なら受け入れてよいか」という条件が判断の土台になります。
同じ操作を試すこともありますが、重点を置く目的や判断基準が違います。担当者が開発側か利用者側かだけでは区別できません。受入テストには、利用者による確認だけでなく、運用の準備や契約上の条件を確かめるものもあります。
全体の動作・品質についてはシステムテストの解説、受け入れ判断については受入テストの解説で詳しく紹介しています。
テストの準備は早い段階から進める
テストをこの位置で紹介していますが、すべてを実装後に始めるわけではありません。何をどう確認するかは、要件定義や設計の段階から考えられます。資料を読み、抜けや矛盾を探す確認も重要です。
問題が見つかったら原因を調べ、必要な箇所を直して再確認します。修正した部分だけでなく、関連する機能への影響も確認します。
工程5：リリース｜利用者が使える状態にする
リリースとは、開発・テストしたシステムや機能を、利用者が使える状態にすることです。
実際の利用者が使う「本番環境」への反映だけでなく、次のような準備を伴う場合があります。
- 既存の予約情報を新しいシステムへ移す
- 利用者の登録や、操作できる範囲の設定を行う
- 操作方法や問い合わせ先を案内する
- 問題が起きたときの復旧・切り戻しの方法を用意する
切り戻しとは、新しい状態で問題が起きたときに、以前の状態へ戻すことです。データの更新状況によっては単純に戻せないため、対応方法を事前に確認します。
テストを終えても、不具合が一切ないとは保証できません。確認結果、残っている問題、利用への影響、運用の準備状況を踏まえ、関係者が利用開始の可否を判断します。
工程6：運用・保守｜使い続けられる状態を保つ
利用開始後は、日々の運用と、必要な保守を続けます。
運用｜日々の利用を支える
運用は、システムやサービスを日々提供し続ける活動です。動作状況の確認、データの控えを取るバックアップ、利用者の登録・変更、問い合わせ対応などがあります。
予約システムなら、予約を受け付けられる状態かを確認し、問題が起きたときに担当者へ知らせる仕組みを使います。
保守｜修正や変化への対応を行う
保守では、不具合の修正や、利用しているソフトウェアの更新への対応などを行います。将来の問題を防いだり、性能や使いやすさを改善したりする変更も含まれることがあります。
運用と保守の分担は、会社や契約によって異なります。どこまでを誰が担当するかを確認しておくことが大切です。
工程7：改善・追加開発｜要望や変化に対応する
利用を続ける中で、「予約日前日にお知らせを送りたい」「入力しにくい画面を直したい」といった要望が出ることがあります。
改善・追加開発では、必要性と影響を確認し、優先順位を決めて対応します。変更する範囲について、再び要件定義、設計、実装、テスト、リリースを行います。
ここでは利用後の変化を説明するために独立させていますが、改善を保守の一部として扱う場合もあります。運用・保守を終えてから改善へ進むという意味ではなく、使い続けながら変更を加えていきます。
開発の進め方｜ウォーターフォールとアジャイル
各工程は、必ず一方向に一度だけ進むわけではありません。代表的な進め方を見てみましょう。
ウォーターフォール開発
ウォーターフォール開発は、全体の計画を立て、工程ごとの結果を確認しながら、原則として順に進める方法です。
作成した資料などを工程の区切りで確認できますが、後から大きな変更が入ると、前の工程から見直す範囲が広がることがあります。前の工程へ戻れないという意味ではありません。
アジャイル開発
アジャイル開発では、小さな単位で作って確かめ、利用者の反応や状況の変化を受けて調整します。短い期間で設計・実装・テストなどを繰り返す進め方が代表的です。
たとえば、まず予約受付の機能を作って確認し、次に変更・キャンセルの機能を加える進め方が考えられます。何を先に作るかは、利用者にとっての重要度や機能同士の関係を見て決めます。
計画や設計が不要になるわけではありません。関係者と協力し、分かったことに合わせて見直します。実際のプロジェクトでは、進め方を組み合わせることもあります。
初心者が工程を見るときのポイント
工程名を暗記するより、次の3点を確認すると、自分の作業の位置付けが分かります。
- 今は何を決め、何を確かめる段階か：必要な機能の合意なのか、作った機能の動作確認なのかを区別する
- 前後と何でつながるか：要件が設計やテストの基準になり、設計が実装の手がかりになることを意識する
- その職場では何を指すか：「開発」が全体を指すのか実装だけを指すのかなど、言葉の意味を確認する
業務を知る人、開発担当者、テスト担当者、運用担当者など、多くの人が関わります。設計中やテスト中に不足が見つかったら、変更の理由と影響を共有して見直します。
まとめ
システム開発は、必要なことを決めて作り、確認して利用を始め、その後も支えながら改善する活動です。
この記事では、要件定義、設計、実装、テスト、リリース、運用・保守、改善・追加開発の7つに整理しました。
工程の区切りや順番は、開発の進め方によって変わります。まずは「今は何を決め、何を確認し、次へ何を渡すのか」を意識してみましょう。