当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
要件定義を担当することになったものの、その先の設計やテスト、運用までの流れがつかめず不安になっていませんか。
結論から言うと、要件定義から運用までは「決める、作る、確かめる、移す、使う」の順に進み、要件定義で決めたことが最後まで物差しとして使われます。
この記事を読むと、工程ごとにやることと、要件定義の内容がどの工程で確かめられるのかが一つの表でつかめます。
要件定義から運用までの流れを全体で見る
システム開発は、要件定義、設計、開発、テスト、移行、運用の順に進みます。上流で決めたことを下流で作って確かめる、という関係を押さえると全体が見えてきます。
まずは全体の流れを見てみましょう。
工程の名前は会社によって少しずつ違いますが、おおよそ次の順番で進みます。
- 要件定義：何を実現するかを決めて合意する
- 基本設計（外部設計）：画面や帳票など、利用者から見える部分をどう作るか決める
- 詳細設計（内部設計）：プログラムの中身をどう作るか決める
- 開発・構築：プログラムを作り、サーバーなどの環境を用意する
- テスト：小さい単位から順に、要件どおりに動くか確かめる
- 移行：旧システムからデータを移し、新しいシステムに切り替える
- 運用・保守：使いながら見守り、直したり改善したりする
工程ごとに、決めることと残すものを表にするとこうなります。
| 工程 | 主にやること | 主な成果物 |
|---|---|---|
| 要件定義 | 業務要件・機能要件・非機能要件を決める | 要件定義書、業務フロー、機能一覧 |
| 基本設計 | 画面・帳票・外部とのつながりの作りを決める | 基本設計書、画面の設計、帳票の設計 |
| 詳細設計 | プログラムごとの処理を決める | 詳細設計書 |
| 開発・構築 | プログラムを作る、環境を用意する | プログラム、構築した環境 |
| テスト | 単体から受入まで順に確かめる | テストの計画と結果 |
| 移行 | データを移し、切り替える | 移行の計画、移行した結果 |
| 運用・保守 | 日々の運用、問い合わせ、改修 | 運用の手順書、障害の記録 |
『こんなに工程があるなら、要件定義はほんの入口なのでは？』と思った方もいるかもしれません。
実は逆で、ここに並んだすべての工程が、要件定義で決めた内容を前提に進むんです。
工程の並びは公的な枠組みでも決まっている
日本で広く使われるIPAの「共通フレーム2013」でも、企画から要件定義、設計、実装とテスト、導入、運用・保守までの工程が順に並べられています。
この枠組みでは、要件定義の段階で、機能だけでなく運用や廃棄に関する要件も考えることが大事とされています。
工程の中での要件定義の位置づけは、要件定義プロセスとはで詳しく解説しています。
ウォーターフォールとアジャイルで流れはどう変わる？
- 工程を上から順に一度ずつ進める
- 前の工程の成果物を確定させてから次へ進む
- 要件定義を最初にまとめて行う
- 短い期間で作って確かめるを繰り返す
- 期間ごとに優先する要件を見直す
- 要件はプロダクトバックログで管理する
この記事では、工程の流れがつかみやすいウォーターフォールを前提に説明していきます。
ウォーターフォールでの要件定義については、ウォーターフォール開発の要件定義も合わせて読んでみてください。
要件定義・設計・開発はそれぞれ何をする？
要件定義は「何を作るか」、設計は「どう作るか」、開発は「実際に作る」工程です。同じ要望が、工程を進むごとに具体的な形へ変わっていきます。
要件定義、設計、開発はよく並べて語られますが、違いがあいまいなままの方も多いはずです。
社内の勤怠管理システムを入れ替える場合を例に、同じ要望がどう変わっていくかを見てみます。
| 工程 | 決めること・やること（例） |
|---|---|
| 要件定義 | 残業は前日までに申請し、上長が当日中に承認する |
| 基本設計（外部設計） | 申請画面に日付・時間・理由の入力欄と送信ボタンを置く |
| 詳細設計（内部設計） | 申請を受けたら承認者を探し、承認待ちとして登録する |
| 開発・構築 | 申請と承認の処理を作り、動かすためのサーバーを用意する |
要件定義
要件定義では、利用者の要望を聞き取り、システムで実現する内容として決めて合意します。
業務をどう変えるかを決める業務要件、システムが何をするかを決める機能要件、どのくらいの品質で動くかを決める非機能要件が中心です。
移行要件と運用・保守要件も、ここで決めておきます。後の工程で慌てないための準備も、要件定義の役目なんです！
基本設計（外部設計）
システム開発では、システム要件定義の次に外部設計を行います。外部設計は基本設計とも呼ばれ、利用者から見える部分をどう作るかを決める工程です。
画面の項目や並び、帳票の形、他のシステムとのデータの受け渡しなどを決めます。
『要件定義と基本設計、どこで線を引けばいいの？』と迷った時は、「利用者が何をしたいか」までが要件定義、「それを画面でどう見せるか」からが基本設計と考えてみてください。
詳細設計（内部設計）
詳細設計は、プログラムの中身をどう作るかを決める工程です。
利用者からは見えない部分なので、主に開発側が担当します。
開発・構築
要件定義、設計、開発と進んだ先で、プログラムを作り、動かす環境を用意します。
アプリケーションを作る作業を「開発」、サーバーやネットワークなどの環境を用意する作業を「構築」と呼び分けることが多いです。インフラの案件では、要件定義、設計、構築という言い方をよく耳にします。
要件定義・基本設計・詳細設計の違いは、要件定義・基本設計・詳細設計の違いで表にして比べています。
テスト・移行・運用で何をする？
テストは小さい単位から順に確かめ、最後に発注側が受入テストで要件どおりかを確かめます。移行で旧システムから切り替え、運用・保守で使い続けられる状態を守ります。
作ったら終わり、ではないのがシステム開発です。
ここからは、作った後の工程を見ていきます。
テスト
テストは、小さい単位から大きい単位へ、段階を踏んで進めます。
| テストの種類 | 確かめること | 主に行う人 |
|---|---|---|
| 単体テスト | プログラム一つひとつが設計どおりに動くか | 開発側 |
| 結合テスト | プログラム同士をつないだ時に正しく動くか | 開発側 |
| システムテスト | システム全体が要件どおりに動くか、性能は足りるか | 開発側 |
| 受入テスト | 業務で使えるか、要件定義どおりか | 発注側（利用部門） |
受入テストは、発注側が「これで受け取ってよいか」を判断する大事な場面です。
ここで物差しになるのが、要件定義書なんです。
受入テストの計画は、要件定義書の項目を一つずつ拾って作るのがおすすめです。どの要件をどの手順で確かめるかを表にしておくと、確かめ漏れが減ります。
移行
移行は、旧システムから新しいシステムへ切り替える工程です。
対象のデータを決め、件数を把握し、変換のルールを決めて、移行のテストをしてから切替日を迎えます。
- 移すデータと移さないデータを決める
- データの件数と中身を把握する
- 旧システムから新システムへの変換ルールを決める
- 本番と同じ手順で移行のテストをする
- 切替日を決めて、業務を止める時間を利用部門と合意する
システムの入れ替えでは、「今と同じでいい」で済ませないことも大切です。今の機能を棚卸しして、新しいシステムで要るものと要らないものを判断しておきましょう。
移行は最後の工程だから、と要件定義で何も決めずに進めてしまう。どのデータを移すか、いつ切り替えるかは、業務の止め方にも関わります。要件定義の段階で、移行要件として方針だけでも決めておきましょう。
運用テスト
移行の前後には、運用テストを行うことがあります。
実際の運用と同じ手順で、バックアップを取る、障害の連絡を回す、問い合わせを受けるといった流れを試してみる工程です。
「障害の連絡は誰から誰へ回すんでしたっけ？」という声がここで出れば、運用の手順書を直すきっかけになります。
運用・保守
運用は、システムを日々動かし続ける仕事です。バックアップや利用者からの問い合わせ対応などがあります。
保守は、不具合を直したり、業務の変化に合わせて改修したりする仕事です。
『運用のことは、使い始めてから考えればいいのでは？』と思うかもしれません。
ただ、問い合わせの窓口や障害時の連絡の流れが決まっていないと、使い始めた初日から困ることも。要件定義の段階で、運用・保守要件として決めておくのがおすすめです。
- 問い合わせの窓口をどこにするか決める
- 障害が起きた時の連絡の流れを決める
- バックアップをどの単位で取るか決める
- データをどれくらいの期間残すか決める
- 保守として対応する範囲を決める
要件定義で決めたことは、どこで確かめられる？V字で見る対応表
要件定義で決めた一文一文は、テスト・移行・運用のどこかで「本当にそうなっているか」を確かめられます。確かめる場面が思い浮かばない要件は、書き方を見直すサインです。
左側の上流工程と、右側のテスト工程を向かい合わせて考える見方を、V字モデルと呼びます。
要件定義は受入テストと、基本設計はシステムテストと、詳細設計は結合テストや単体テストと向き合う、という関係です。
この見方を一歩進めて、要件の種類ごとに「どこで確かめるか」をまとめたのが次の表です。
| 要件定義で決めたこと | 確かめる工程 | 確かめ方の例 |
|---|---|---|
| 業務要件（業務の流れ・ルール） | 受入テスト | 利用部門が実際の業務の手順でシステムを操作してみる |
| 機能要件（画面・帳票・処理） | システムテスト、受入テスト | 機能一覧の項目ごとに動きを確かめる |
| 非機能要件（性能） | システムテスト | 利用が集中する時間帯を想定して、待ち時間を測る |
| 非機能要件（セキュリティ） | システムテスト | 権限のない人が見られない画面を確かめる |
| 移行要件 | 移行テスト、切替当日 | 移したデータの件数と中身を旧システムと照らし合わせる |
| 運用・保守要件 | 運用テスト、運用開始後 | 障害を想定して連絡の流れを試す |
非機能要件は、IPAの「非機能要求グレード」の6つの大項目で考えると漏れにくくなります。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーです。
各項目のレベルを0〜5の段階で選ぶ方式なので、テストで何を確かめればいいかも決めやすくなります。
確かめられる要件と確かめにくい要件
例えばこんな会話が、受入テストで起こりがちです。
「もっと速く表示されると思っていました」「要件定義では、表示の速さの条件を決めていませんでした」
こうならないために、要件は検証できる書き方にしておきましょう。国際規格のISO/IEC/IEEE 29148でも、良い要件の性質として、あいまいでないことや検証できることが挙げられています。
| 確かめにくい書き方 | 確かめやすい書き方（例） |
|---|---|
| 画面は速く表示する | 利用が集中する時間帯でも、決めた秒数以内に表示する |
| 誰でも使いやすくする | 初めて使う人が説明書なしで申請を終えられる |
| データは安全に保管する | 決めた権限の人だけが申請データを見られる |
この表の書き方は、架空の勤怠管理システムを題材にした例です。具体的な値は、関係者と話し合って決めていきます。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
発注側と開発側、工程ごとに誰が何をする？
要件定義と受入テストは、発注側が主役になる工程です。設計から結合テストまでは開発側が中心になり、運用・保守は契約によって分担が変わります。
要件定義から運用まで、すべてを一つの立場で担うことはあまりありません。
工程ごとの主な役割を表にすると、次のようになります。
| 工程 | 発注側（利用部門・情報システム部門） | 開発側（SE・PMなど） |
|---|---|---|
| 要件定義 | 業務の要望を伝え、要件に合意する | 要望を要件の形に言い換え、実現できるか判断する |
| 基本設計 | 画面や帳票の案を確認する | 利用者から見える部分を設計する |
| 詳細設計・開発 | 進み具合の報告を受ける | プログラムの中身を設計して作る |
| 結合・システムテスト | 結果の報告を受ける | テストを計画して行う |
| 受入テスト | 業務で使えるかを確かめる | 不具合を直し、確認を支える |
| 移行 | 業務の切り替えを準備する | データを移し、切り替えを行う |
| 運用・保守 | 日々の利用と問い合わせの受付 | 契約の範囲で保守や改修を行う |
どの立場が要件定義を担うかは、契約の形や会社によって変わります。
一般論として、受託開発では要件定義を準委任契約、設計以降を請負契約に分けて契約する例があります。何が決まっているかによって、頼み方を変える考え方ですね。
工程の境目で渡すものをそろえる
担当が分かれるほど、工程の境目での受け渡しが大事になります。
『前の工程の人に聞けば分かるから大丈夫』と思っていても、その人が別の案件に移っていることもありますよね。
| 工程の境目 | 渡すもの（例） | 渡す時に確かめたいこと |
|---|---|---|
| 要件定義から設計へ | 要件定義書、業務フロー、課題一覧 | 未決事項に担当と期限があるか |
| 設計から開発へ | 基本設計書、詳細設計書 | 要件定義書のどこに対応するか追えるか |
| 開発からテストへ | プログラム、テストの計画 | 確かめる項目が要件と結びついているか |
| テストから運用へ | 運用の手順書、移行の結果 | 問い合わせと障害の連絡の流れが決まっているか |
要件定義書の項目に番号を振っておくと、設計書やテストの計画から「どの要件のためのものか」をたどれるようになります。良い要件の性質として挙げられる「追跡できる」状態ですね。
システム開発全体の中での要件定義の考え方は、システム開発における要件定義とはでまとめています。
よくある相談に答えます
要件定義から運用までの流れについて、よく寄せられる相談を要点だけまとめて答えます。
企画から運用・保守までは、一つの会社でやることが多い？
『全部一つの会社がやるものなの？』という疑問は、勉強を始めたばかりの方からよく出ます。
答えは、案件によってさまざまです。
一つの会社が要件定義から運用までまとめて請け負うこともあります。要件定義は元請けの会社、開発は別の会社、運用は社内の情報システム部門、と分かれることもあります。
分かれる場合ほど、工程の境目で何を渡すかが大事になります。要件定義書や設計書が、次の担当者へのバトンになるからです。
自分が担当する工程の前後で、誰から何を受け取り、誰に何を渡すのかを最初に確かめておくと安心です。
要件定義と設計と開発は、どう違うの？
この記事の前半で見たとおり、要件定義は何を作るか、設計はどう作るか、開発は実際に作る工程です。
担当する時期は、会社や本人の経験によって大きく変わります。テストや開発から入って、少しずつ上流の工程を任されていく形がよく見られます。
要件定義は準委任、設計以降は請負と聞いたけど本当？
資格の勉強で、要件定義と運用テストは準委任、内部設計や結合は請負の契約がふさわしい、という考え方に出会った方もいるはずです。
一般論として、要件定義のように完成させる物の中身がまだ決まっていない工程は準委任、作る物がはっきりしている工程は請負、と分けて契約する例があります。
ただ、実際の契約の形は会社や案件ごとに決まるので、断定はできません。契約の場面では、工程ごとの成果物と責任の分け方を確かめるようにしましょう！
よくある質問
要件定義から運用まで、どの工程がいちばん大事ですか？
どれも欠かせませんが、要件定義は後のすべての工程の物差しになるため、特に影響が大きい工程です。ここで決めたことが、設計の材料にもテストの合格基準にもなります。
外部設計と基本設計は同じものですか？
多くの現場で同じ意味として使われています。どちらも、画面や帳票など利用者から見える部分をどう作るかを決める工程です。呼び方は会社によって揺れます。
要件定義の内容は、どのテストで確かめますか？
主に受入テストで、発注側が確かめます。V字モデルでは、要件定義と受入テストが向き合う関係として考えます。
要件定義、設計、構築という言い方はどんな時に使いますか？
サーバーやネットワークなどの環境を用意するインフラの案件でよく使われます。アプリケーションを作る案件では、構築の代わりに開発と呼ぶことが多いです。
運用が始まってから要件を変えることはできますか？
保守として改修することはできます。その場合も、変える内容を要件として書き、影響する設計やテストを確かめてから進めると安心です。
まとめ
- 要件定義から運用までは、要件定義、設計、開発、テスト、移行、運用の順に進む
- 要件定義は何を作るか、設計はどう作るか、開発は実際に作る工程
- 要件定義で決めたことは、受入テストや移行、運用の場面で確かめられる
- 確かめる場面が思い浮かばない要件は、書き方を見直すサイン
- 工程ごとに発注側と開発側の役割を分けて考えると、全体の流れがつかみやすい
コメント