システム開発のプロセス
システム開発の全体像
Section titled “システム開発の全体像”システム開発とは、利用者の要望を実現するために、ソフトウェアやハードウェアを含むシステムを作り上げる一連の作業のことです。開発は行き当たりばったりで進めるのではなく、あらかじめ決められた工程（プロセス）を順番に進めていきます。
システム開発のプロセスは、大きく次の6つの段階に分けられます。
- システム要件定義・ソフトウェア要件定義（何を作るか決める）
- 設計（どう作るか決める）
- プログラミング（実際に作る・単体テストを含む）
- 統合・テスト（組み合わせて確かめる）
- 導入・受入れ（実際に使い始める）
- 保守（使い続けながら改善する）
graph TB A["① 要件定義"]:::primary A -->|"要件定義書"| B["② 設計"]:::base B -->|"設計書"| C["③ プログラミング"]:::base C -->|"プログラム"| D["④ 統合・テスト"]:::base D -->|"テスト報告書"| E["⑤ 導入・受入れ"]:::base E -->|"利用者マニュアル"| F["⑥ 保守"]:::primary classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333; classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af; classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;
それでは、各工程を順番に見ていきましょう。
① システム要件定義・ソフトウェア要件定義
Section titled “① システム要件定義・ソフトウェア要件定義”開発の最初のステップは、要件定義です。「このシステムに何をさせたいか」を明確にする工程です。
システム要件定義とソフトウェア要件定義の違い
Section titled “システム要件定義とソフトウェア要件定義の違い”システム要件定義は、ハードウェアやネットワークも含めたシステム全体として実現すべきことを定義します。一方、ソフトウェア要件定義は、そのうちソフトウェアで実現する部分に絞って要件を詳細化します。
たとえば、ある会計システムを開発する場合を考えてみましょう。
- システム要件定義：「処理時間は3秒以内とする」「同時に100人が利用できる」「サーバーは二重化する」
- ソフトウェア要件定義：「仕訳入力画面では勘定科目をプルダウンから選択できる」「月次決算レポートをPDFで出力できる」
試験で出るポイント
「処理時間の目標値を明確にした」「応答速度を定めた」のような記述があれば、それはシステム要件定義の段階です。設計ではなく要件定義であることに注意しましょう。
機能要件と非機能要件
Section titled “機能要件と非機能要件”要件は、機能要件と非機能要件の2種類に分けられます。
| 区分 | 意味 | 具体例 |
|---|---|---|
| 機能要件 | システムが「何をするか」に関する要件 | 商品検索ができる、注文履歴を表示する |
| 非機能要件 | 性能・安全性・使いやすさなど、「どのように動くか」に関する要件 | 応答時間は2秒以内、稼働率99.9%以上 |
機能要件は「できること」、非機能要件は「どれくらいのレベルで動くか」と覚えるとよいでしょう。
共同レビュー
Section titled “共同レビュー”要件定義の内容に漏れや誤りがないかを確認するために、発注者（利用者側）と開発者が一緒に内容を確認する場が共同レビューです。開発が進んでから「こんなはずではなかった」とならないよう、早い段階で認識を合わせることが大切です。
ソフトウェアの品質を評価するための基準として、品質特性があります。これはISO/IEC 25010という国際規格で定められた8つの分類です。
| 品質特性 | 意味 | 具体例 |
|---|---|---|
| 機能適合性 | 求められた機能を正しく提供できるか | 計算結果が正確である |
| 性能効率性 | 処理速度や資源の使用量が適切か | 画面の応答が2秒以内 |
| 互換性 | 他のシステムと情報をやり取りできるか | 他社システムとデータ連携できる |
| 使用性 | 利用者にとって使いやすいか | 画面が直感的に操作できる |
| 信頼性 | 障害が起きにくく、安定して動作するか | 24時間365日止まらない |
| セキュリティ | 不正アクセスや情報漏えいを防げるか | パスワード認証がある |
| 保守性 | 修正や改善がしやすいか | プログラムの構造がわかりやすい |
| 移植性 | 別の環境へ移しやすいか | WindowsでもMacでも動作する |
試験で出るポイント
「銀行ATMが誰でも迷わず操作できる」→ 使用性、「RPAツールが直感的に設定できる」→ 使用性 のように、具体的な場面がどの品質特性に当てはまるかを問う問題が頻出です。
要件定義で「何を作るか」が決まったら、次は「どう作るか」を決める設計の工程に入ります。
設計は大きく2段階に分かれます。
機能設計（外部設計）は、利用者から見えるシステムの外側の振る舞いを設計する段階です。画面のレイアウト、帳票のフォーマット、データベースの構造などを決めます。
詳細設計（内部設計）は、プログラムの内部構造を設計する段階です。具体的な処理の手順やデータの流れなど、プログラマがコードを書くために必要な情報を決めます。
| 設計段階 | 視点 | 決めること |
|---|---|---|
| 機能設計（外部設計） | 利用者視点 | 画面、帳票、データ構造 |
| 詳細設計（内部設計） | 開発者視点 | 処理手順、モジュール分割 |
③ プログラミング（単体テストを含む）
Section titled “③ プログラミング（単体テストを含む）”設計書をもとに、実際にプログラムを作成する工程です。この工程には単体テストの実施までが含まれます。
コーディングとは、設計書の内容をプログラミング言語で記述してプログラムを作成する作業のことです。
作成したプログラムを、他の開発者が読んで確認する作業をコードレビューといいます。プログラムの誤りや改善点を早期に発見する効果があります。
プログラムの誤り（バグ）を見つけて修正する作業をデバッグといいます。テストでバグが見つかったら、原因を特定して修正し、再度テストを行います。
単体テストは、プログラムを構成する個々のモジュール（部品）が、それぞれ正しく動作するかを確認するテストです。単体テストでは、主にホワイトボックステストという手法が用いられます。
試験で出るポイント
シラバスでは「プログラミング」工程に単体テストの実施まで含むと明示されています。単体テストは「テスト工程」ではなく「プログラミング工程」の一部であることを押さえましょう。
テスト手法 ── ホワイトボックステストとブラックボックステスト
Section titled “テスト手法 ── ホワイトボックステストとブラックボックステスト”テストの手法は大きく2つに分かれます。
| テスト手法 | 着目点 | テスト内容 | 主な使用工程 |
|---|---|---|---|
| ホワイトボックステスト | プログラムの内部構造 | すべての処理経路を通るかを確認 | 単体テスト |
| ブラックボックステスト | プログラムの入出力 | 入力に対して正しい出力が得られるかを確認 | 統合テスト・システムテスト |
ホワイトボックステストは、プログラムの中身（ソースコード）を見ながらテストする方法です。「白い箱＝中が見える」と覚えましょう。条件分岐やループなど、すべての処理経路が正しく動くかを確認します。テストデータの作成及び分析を行い、漏れなくテストケースを設計することが大切です。
ブラックボックステストは、プログラムの中身は見ずに、入力と出力だけで正しさを判断する方法です。「黒い箱＝中が見えない」と覚えましょう。利用者の視点に近いテスト方法です。
試験で出るポイント
「内部構造に着目」→ ホワイトボックステスト、「入力と出力の関係に着目」→ ブラックボックステスト です。名前と着目点の対応を確実に覚えましょう。
④ 統合・テスト
Section titled “④ 統合・テスト”個々のモジュールが正しく動くことを確認したら、次はそれらを組み合わせてテストする工程に進みます。
統合テスト（結合テスト）は、複数のモジュールを組み合わせたときに、モジュール間のデータの受け渡しや連携が正しく行われるかを確認するテストです。
システムテストは、システム全体が要件定義で定めた通りに動作するかを確認するテストです。
統合テストやシステムテストの段階では、さまざまな観点からテストを実施します。
| テスト名 | 目的 |
|---|---|
| 性能テスト | システムの処理速度や応答時間が要件を満たしているかを確認する |
| 負荷テスト | 大量のアクセスやデータを与えたときに、システムが正常に動作するかを確認する |
| 回帰テスト（リグレッションテスト） | プログラムを修正した後、修正していない部分に悪影響が出ていないかを確認する |
回帰テストは特に重要な概念です。バグを修正したり機能を追加したりした際に、その変更が他の部分に思わぬ不具合を引き起こしていないかを確認します。
⑤ 導入・受入れ
Section titled “⑤ 導入・受入れ”テストが完了し、システムが要件を満たしていることが確認できたら、実際に利用者が使える状態にする工程です。
ソフトウェア導入とは、開発したソフトウェアを本番環境にインストールし、実際に稼働させることです。
システムの操作方法を利用者向けにまとめた文書が利用者マニュアルです。
受入れテストは、発注者（利用者側）が主体となって、納品されたシステムが自分たちの要件を満たしているかを確認するテストです。
妥当性確認テストは、ソフトウェアが利用者のニーズや要求に合致しているかを確認するテストです。
旧システムから新システムへ切り替える作業を移行といいます。
試験で出るポイント
受入れテストの**主体は発注者（利用者側）**です。開発者が行うテスト（単体テスト・統合テスト・システムテスト）とは立場が異なることを押さえましょう。
⑥ ソフトウェア保守
Section titled “⑥ ソフトウェア保守”システムは完成して終わりではありません。運用を開始した後も、さまざまな理由でシステムの修正や改善が必要になります。この活動をソフトウェア保守といいます。
ソフトウェア保守に含まれる作業の例を見てみましょう。
- 運用中に見つかったバグの修正
- 法律や制度の改正に伴うプログラムの変更（例：税率変更への対応）
- 将来的に問題になりそうな潜在的な不良の予防的修正
- 業務の変化に合わせた機能の追加・改善
試験で出るポイント
「法律改正に伴う修正」もソフトウェア保守に含まれます。保守＝バグ修正だけではなく、制度変更への対応や予防的な修正も含む広い概念であることを理解しておきましょう。
テスト工程の全体像
Section titled “テスト工程の全体像”システム開発では、段階的にテストの範囲を広げていきます。
| テスト段階 | 対象範囲 | 主な実施者 | 含まれる工程 |
|---|---|---|---|
| 単体テスト | モジュール単体 | 開発者 | ③ プログラミング |
| 統合テスト（結合テスト） | モジュール間の連携 | 開発者 | ④ 統合・テスト |
| システムテスト | システム全体 | 開発者 | ④ 統合・テスト |
| 受入れテスト | 要件への適合 | 発注者（利用者） | ⑤ 導入・受入れ |
graph TB D["受入れテスト<br>要件への適合を検証<br>（発注者）"]:::alert C["システムテスト<br>システム全体を検証<br>（開発者）"]:::primary B["統合テスト<br>モジュール間の連携を検証<br>（開発者）"]:::base A["単体テスト<br>モジュール単体を検証<br>（開発者）"]:::base A --> B --> C --> D classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333; classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af; classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;
品質管理の手法
Section titled “品質管理の手法”開発したソフトウェアの品質を客観的に評価するために、数値やグラフを使った品質管理の手法が用いられます。
不良密度とは、プログラムの規模に対してどれだけの不良（バグ）が見つかったかを示す指標です。たとえば「1,000行あたり5件の不良が見つかった」のように表します。不良密度が極端に高い場合は品質が低いことを示しますが、極端に低い場合も「テストが不十分なのでは？」と疑う必要があります。不良密度の詳しい計算方法については「ソフトウェアの見積り」のページで解説します。
管理図とは、不良の発見状況などを時系列で記録し、品質が安定しているかを視覚的に確認するためのグラフです。上限と下限の管理線を設け、データがその範囲内に収まっているかを監視します。
| 工程 | 主な活動 | キーワード |
|---|---|---|
| ① 要件定義 | 何を作るか決める | 機能要件、非機能要件、品質特性、共同レビュー |
| ② 設計 | どう作るか決める | 機能設計、詳細設計 |
| ③ プログラミング | 作る＋単体テスト | コーディング、ホワイトボックステスト、デバッグ、コードレビュー |
| ④ 統合・テスト | 組み合わせて確認 | 統合テスト、ブラックボックステスト、性能テスト、負荷テスト、回帰テスト |
| ⑤ 導入・受入れ | 使い始める | ソフトウェア導入、受入れテスト、妥当性確認テスト、利用者マニュアル、移行 |
| ⑥ 保守 | 改善し続ける | ソフトウェア保守（バグ修正・法改正対応・予防修正） |
試験で出るポイント
各工程の順序と、それぞれの工程で行うテストの種類を正確に覚えましょう。特に「単体テストはプログラミング工程に含まれる」「受入れテストの主体は発注者」の2点は頻出です。
過去問で実力チェック
Section titled “過去問で実力チェック”過去問に挑戦
Q. 会計システムの開発を受託した会社が，顧客と打合せを行って，必要な決算書の種類や，会計データの確定から決算書類の出力までの処理時間の目標値を明確にした。この作業を実施するのに適切な工程はどれか。
- ア システムテスト
- イ システム要件定義
- ウ ソフトウェア詳細設計
- エ ソフトウェア方式設計
解答（令和元年）
正解: イ
Q. システム開発後にプログラムの修正や変更を行うことを何というか。
- ア システム化の企画
- イ システム運用
- ウ ソフトウェア保守
- エ 要件定義
解答（令和元年）
正解: ウ
Q. ソフトウェアの品質を判定する指標として，機能単位の不良件数をその開発規模で割った値を “不良密度” と定義する。不良密度の下限値と上限値を設定し，実績値がその範囲を逸脱した場合に問題ありと判定するとき，A工程では問題がなく，B工程で問題があると判定される機能はどれか。ここで，不良密度の下限値は 0.25件／KS，上限値は 0.65件／KSとする。また，不良密度の下限値，上限値及び開発規模は，両工程とも同じとする。
| 機能 | 開発規模（KS） | A工程の不良件数（件） | B工程の不良件数（件） | |
|---|---|---|---|---|
| ア | 機能1 | 10 | 6 | 3 |
| イ | 機能2 | 20 | 14 | 10 |
| ウ | 機能3 | 50 | 10 | 40 |
| エ | 機能4 | 80 | 32 | 8 |
- ア 機能1 / 10 / 6 / 3
- イ 機能2 / 20 / 14 / 10
- ウ 機能3 / 50 / 10 / 40
- エ 機能4 / 80 / 32 / 8
解答（令和元年）
正解: エ
Q. 納入されたソフトウェアの一連のテストの中で，開発を発注した利用者が主体となって実施するテストはどれか。
- ア 受入れテスト
- イ 結合テスト
- ウ システムテスト
- エ 単体テスト
解答（令和2年）
正解: ア
Q. 次の作業はシステム開発プロセスのどの段階で実施されるか。
実務に精通している利用者に参画してもらい，開発するシステムの具体的な利用方法について分析を行う。
- ア システム要件定義
- イ システム設計
- ウ テスト
- エ プログラミング
解答（令和2年）
正解: ア
Q. 同一難易度の複数のプログラムから成るソフトウェアのテスト工程での品質管理において，各プログラムの単位ステップ数当たりのバグ数をグラフ化し，上限・下限の限界線を超えるものを異常なプログラムとして検出したい。作成する図として，最も適切なものはどれか。
- ア 管理図
- イ 特性要因図
- ウ パレート図
- エ レーダチャート
解答（令和3年）
正解: ア
Q. クラスや継承という概念を利用して，ソフトウェアを部品化したり再利用することで，ソフトウェア開発の生産性向上を図る手法として，適切なものはどれか。
- ア オブジェクト指向
- イ 構造化
- ウ プロセス中心アプローチ
- エ プロトタイピング
解答（令和3年）
正解: ア
Q. システム要件定義で明確にするもののうち，性能に関する要件はどれか。
- ア 業務要件を実現するシステムの機能
- イ システムの稼働率
- ウ 照会機能の応答時間
- エ 障害の復旧時間
解答（令和3年）
正解: ウ
Q. ブラックボックステストに関する記述として，適切なものはどれか。
- ア プログラムの全ての分岐についてテストする。
- イ プログラムの全ての命令についてテストする。
- ウ プログラムの内部構造に基づいてテストする。
- エ プログラムの入力と出力に着目してテストする。
解答（令和4年）
正解: エ
Q. ソフトウェア保守に関する記述のうち，適切なものはどれか。
- ア 本番環境で運用中のシステムに対して，ソフトウェアの潜在不良を発見し，障害が発生する前に修正を行うことはソフトウェア保守には含まれない。
- イ 本番環境で運用中のシステムに対して，ソフトウェアの不具合を修正することがソフトウェア保守であり，仕様変更に伴う修正はソフトウェア保守には含まれない。
- ウ 本番環境で運用中のシステムに対して，法律改正に伴うソフトウェア修正もソフトウェア保守に含まれる。
- エ 本番環境で運用中のシステムに対する修正だけでなく，納入前のシステム開発期間中に実施した不具合の修正もソフトウェア保守に含まれる。
解答（令和4年）
正解: ウ
Q. ソフトウェア開発における，テストに関する記述 a〜c とテスト工程の適切な組合せはどれか。
a 運用予定時間内に処理が終了することを確認する。
b ソフトウェア間のインタフェースを確認する。
c プログラムの内部パスを網羅的に確認する。
| 単体テスト | 結合テスト | システムテスト | |
|---|---|---|---|
| ア | a | b | c |
| イ | a | c | b |
| ウ | b | a | c |
| エ | c | b | a |
- ア a / b / c
- イ a / c / b
- ウ b / a / c
- エ c / b / a
解答（令和5年）
正解: エ
Q. ソフトウェア導入作業に関する記述 a〜d のうち，適切なものだけを全て挙げたものはどれか。
a 新規開発の場合，導入計画書の作成はせず，期日までに速やかに導入する。
b ソフトウェア導入作業を実施した後，速やかに導入計画書と導入報告書を作成し，合意を得る必要がある。
c ソフトウェアを自社開発した場合，影響範囲が社内になるので導入計画書の作成後に導入し，導入計画書の合意は導入後に行う。
d 本番稼働中のソフトウェアに機能追加する場合，機能追加したソフトウェアの導入計画書を作成し，合意を得てソフトウェア導入作業を実施する。
- ア a，c
- イ b，c，d
- ウ b，d
- エ d
解答（令和5年）
正解: エ
Q. ソフトウェア製品の品質特性を，移植性，機能適合性，互換性，使用性，信頼性，性能効率性，セキュリティ，保守性に分類したとき，RPAソフトウェアの使用性に関する記述として，最も適切なものはどれか。
- ア RPAが稼働するPCのOSが変わっても動作する。
- イ RPAで指定した時間及び条件に基づき，適切に自動処理が実行される。
- ウ RPAで操作対象となるアプリケーションソフトウェアがバージョンアップされても，簡単な設定変更で対応できる。
- エ RPAを利用したことがない人でも，簡単な教育だけで利用可能になる。
解答（令和6年）
正解: エ
Q. 開発が完了したソフトウェアを本番環境にインストールする手順を明確にし，それを実施する工程として，適切なものはどれか。
- ア ソフトウェア統合
- イ ソフトウェア導入
- ウ 妥当性確認
- エ 利用者教育
解答（令和7年）
正解: イ
Q. 利用者が銀行のATMのパネルを操作して入金処理を行う。この操作の要件を定義するときに，ソフトウェア開発の品質特性である使用性を考慮すべきインタフェースとして，最も適切なものはどれか。
- ア OSとパネルのインタフェース
- イ ソフトウェア間のインタフェース
- ウ ハードウェアとOSのインタフェース
- エ 利用者とパネルのインタフェース
解答（令和7年）
正解: エ