システム開発のプロセス

システム開発の全体像

システム開発とは、利用者の要望を実現するために、ソフトウェアやハードウェアを含むシステムを作り上げる一連の作業のことです。開発は行き当たりばったりで進めるのではなく、あらかじめ決められた工程（プロセス）を順番に進めていきます。

システム開発のプロセスは、大きく次の6つの段階に分けられます。

1. システム要件定義・ソフトウェア要件定義（何を作るか決める）
2. 設計（どう作るか決める）
3. プログラミング（実際に作る・単体テストを含む）
4. 統合・テスト（組み合わせて確かめる）
5. 導入・受入れ（実際に使い始める）
6. 保守（使い続けながら改善する）

それでは、各工程を順番に見ていきましょう。

① システム要件定義・ソフトウェア要件定義

開発の最初のステップは、要件定義です。「このシステムに何をさせたいか」を明確にする工程です。

システム要件定義とソフトウェア要件定義の違い

システム要件定義は、ハードウェアやネットワークも含めたシステム全体として実現すべきことを定義します。一方、ソフトウェア要件定義は、そのうちソフトウェアで実現する部分に絞って要件を詳細化します。

たとえば、ある会計システムを開発する場合を考えてみましょう。

• システム要件定義：「処理時間は3秒以内とする」「同時に100人が利用できる」「サーバーは二重化する」
• ソフトウェア要件定義：「仕訳入力画面では勘定科目をプルダウンから選択できる」「月次決算レポートをPDFで出力できる」

試験で出るポイント

「処理時間の目標値を明確にした」「応答速度を定めた」のような記述があれば、それはシステム要件定義の段階です。設計ではなく要件定義であることに注意しましょう。

機能要件と非機能要件

要件は、機能要件と非機能要件の2種類に分けられます。

区分	意味	具体例
機能要件	システムが「何をするか」に関する要件	商品検索ができる、注文履歴を表示する
非機能要件	性能・安全性・使いやすさなど、「どのように動くか」に関する要件	応答時間は2秒以内、稼働率99.9%以上

機能要件は「できること」、非機能要件は「どれくらいのレベルで動くか」と覚えるとよいでしょう。

共同レビュー

要件定義の内容に漏れや誤りがないかを確認するために、発注者（利用者側）と開発者が一緒に内容を確認する場が共同レビューです。開発が進んでから「こんなはずではなかった」とならないよう、早い段階で認識を合わせることが大切です。

品質特性

ソフトウェアの品質を評価するための基準として、品質特性があります。これはISO/IEC 25010という国際規格で定められた8つの分類です。

品質特性	意味	具体例
機能適合性	求められた機能を正しく提供できるか	計算結果が正確である
性能効率性	処理速度や資源の使用量が適切か	画面の応答が2秒以内
互換性	他のシステムと情報をやり取りできるか	他社システムとデータ連携できる
使用性	利用者にとって使いやすいか	画面が直感的に操作できる
信頼性	障害が起きにくく、安定して動作するか	24時間365日止まらない
セキュリティ	不正アクセスや情報漏えいを防げるか	パスワード認証がある
保守性	修正や改善がしやすいか	プログラムの構造がわかりやすい
移植性	別の環境へ移しやすいか	WindowsでもMacでも動作する

試験で出るポイント

「銀行ATMが誰でも迷わず操作できる」→ 使用性、「RPAツールが直感的に設定できる」→ 使用性 のように、具体的な場面がどの品質特性に当てはまるかを問う問題が頻出です。

② 設計

要件定義で「何を作るか」が決まったら、次は「どう作るか」を決める設計の工程に入ります。

設計は大きく2段階に分かれます。

機能設計（外部設計）は、利用者から見えるシステムの外側の振る舞いを設計する段階です。画面のレイアウト、帳票のフォーマット、データベースの構造などを決めます。

詳細設計（内部設計）は、プログラムの内部構造を設計する段階です。具体的な処理の手順やデータの流れなど、プログラマがコードを書くために必要な情報を決めます。

設計段階	視点	決めること
機能設計（外部設計）	利用者視点	画面、帳票、データ構造
詳細設計（内部設計）	開発者視点	処理手順、モジュール分割

③ プログラミング（単体テストを含む）

設計書をもとに、実際にプログラムを作成する工程です。この工程には単体テストの実施までが含まれます。

コーディングとは、設計書の内容をプログラミング言語で記述してプログラムを作成する作業のことです。

作成したプログラムを、他の開発者が読んで確認する作業をコードレビューといいます。プログラムの誤りや改善点を早期に発見する効果があります。

プログラムの誤り（バグ）を見つけて修正する作業をデバッグといいます。テストでバグが見つかったら、原因を特定して修正し、再度テストを行います。

単体テストは、プログラムを構成する個々のモジュール（部品）が、それぞれ正しく動作するかを確認するテストです。単体テストでは、主にホワイトボックステストという手法が用いられます。

試験で出るポイント

シラバスでは「プログラミング」工程に単体テストの実施まで含むと明示されています。単体テストは「テスト工程」ではなく「プログラミング工程」の一部であることを押さえましょう。

テスト手法 ── ホワイトボックステストとブラックボックステスト

テストの手法は大きく2つに分かれます。

テスト手法	着目点	テスト内容	主な使用工程
ホワイトボックステスト	プログラムの内部構造	すべての処理経路を通るかを確認	単体テスト
ブラックボックステスト	プログラムの入出力	入力に対して正しい出力が得られるかを確認	統合テスト・システムテスト

ホワイトボックステストは、プログラムの中身（ソースコード）を見ながらテストする方法です。「白い箱＝中が見える」と覚えましょう。条件分岐やループなど、すべての処理経路が正しく動くかを確認します。テストデータの作成及び分析を行い、漏れなくテストケースを設計することが大切です。

ブラックボックステストは、プログラムの中身は見ずに、入力と出力だけで正しさを判断する方法です。「黒い箱＝中が見えない」と覚えましょう。利用者の視点に近いテスト方法です。

試験で出るポイント

「内部構造に着目」→ ホワイトボックステスト、「入力と出力の関係に着目」→ ブラックボックステスト です。名前と着目点の対応を確実に覚えましょう。

④ 統合・テスト

個々のモジュールが正しく動くことを確認したら、次はそれらを組み合わせてテストする工程に進みます。

統合テスト（結合テスト）は、複数のモジュールを組み合わせたときに、モジュール間のデータの受け渡しや連携が正しく行われるかを確認するテストです。

システムテストは、システム全体が要件定義で定めた通りに動作するかを確認するテストです。

統合テストやシステムテストの段階では、さまざまな観点からテストを実施します。

テスト名	目的
性能テスト	システムの処理速度や応答時間が要件を満たしているかを確認する
負荷テスト	大量のアクセスやデータを与えたときに、システムが正常に動作するかを確認する
回帰テスト（リグレッションテスト）	プログラムを修正した後、修正していない部分に悪影響が出ていないかを確認する

回帰テストは特に重要な概念です。バグを修正したり機能を追加したりした際に、その変更が他の部分に思わぬ不具合を引き起こしていないかを確認します。

⑤ 導入・受入れ

テストが完了し、システムが要件を満たしていることが確認できたら、実際に利用者が使える状態にする工程です。

ソフトウェア導入とは、開発したソフトウェアを本番環境にインストールし、実際に稼働させることです。

システムの操作方法を利用者向けにまとめた文書が利用者マニュアルです。

受入れテストは、発注者（利用者側）が主体となって、納品されたシステムが自分たちの要件を満たしているかを確認するテストです。

妥当性確認テストは、ソフトウェアが利用者のニーズや要求に合致しているかを確認するテストです。

旧システムから新システムへ切り替える作業を移行といいます。

試験で出るポイント

受入れテストの**主体は発注者（利用者側）**です。開発者が行うテスト（単体テスト・統合テスト・システムテスト）とは立場が異なることを押さえましょう。

⑥ ソフトウェア保守

システムは完成して終わりではありません。運用を開始した後も、さまざまな理由でシステムの修正や改善が必要になります。この活動をソフトウェア保守といいます。

ソフトウェア保守に含まれる作業の例を見てみましょう。

• 運用中に見つかったバグの修正
• 法律や制度の改正に伴うプログラムの変更（例：税率変更への対応）
• 将来的に問題になりそうな潜在的な不良の予防的修正
• 業務の変化に合わせた機能の追加・改善

試験で出るポイント

「法律改正に伴う修正」もソフトウェア保守に含まれます。保守＝バグ修正だけではなく、制度変更への対応や予防的な修正も含む広い概念であることを理解しておきましょう。

テスト工程の全体像

システム開発では、段階的にテストの範囲を広げていきます。

テスト段階	対象範囲	主な実施者	含まれる工程
単体テスト	モジュール単体	開発者	③ プログラミング
統合テスト（結合テスト）	モジュール間の連携	開発者	④ 統合・テスト
システムテスト	システム全体	開発者	④ 統合・テスト
受入れテスト	要件への適合	発注者（利用者）	⑤ 導入・受入れ

品質管理の手法

開発したソフトウェアの品質を客観的に評価するために、数値やグラフを使った品質管理の手法が用いられます。

不良密度とは、プログラムの規模に対してどれだけの不良（バグ）が見つかったかを示す指標です。たとえば「1,000行あたり5件の不良が見つかった」のように表します。不良密度が極端に高い場合は品質が低いことを示しますが、極端に低い場合も「テストが不十分なのでは？」と疑う必要があります。不良密度の詳しい計算方法については「ソフトウェアの見積り」のページで解説します。

管理図とは、不良の発見状況などを時系列で記録し、品質が安定しているかを視覚的に確認するためのグラフです。上限と下限の管理線を設け、データがその範囲内に収まっているかを監視します。

まとめ

工程	主な活動	キーワード
① 要件定義	何を作るか決める	機能要件、非機能要件、品質特性、共同レビュー
② 設計	どう作るか決める	機能設計、詳細設計
③ プログラミング	作る＋単体テスト	コーディング、ホワイトボックステスト、デバッグ、コードレビュー
④ 統合・テスト	組み合わせて確認	統合テスト、ブラックボックステスト、性能テスト、負荷テスト、回帰テスト
⑤ 導入・受入れ	使い始める	ソフトウェア導入、受入れテスト、妥当性確認テスト、利用者マニュアル、移行
⑥ 保守	改善し続ける	ソフトウェア保守（バグ修正・法改正対応・予防修正）

試験で出るポイント

各工程の順序と、それぞれの工程で行うテストの種類を正確に覚えましょう。特に「単体テストはプログラミング工程に含まれる」「受入れテストの主体は発注者」の2点は頻出です。