本記事では、システム開発における一連のプロセスと、それぞれの段階で登場する重要な用語を整理します。要件定義から設計・プログラミング、テスト、導入・保守までの流れをイメージしながら読むことで、ITパスポート試験で頻出のキーワードを無理なく整理できるようにしていきます。
1. システム開発プロセスの全体像
この章では、システム開発の全体の流れを俯瞰します。どのような順番で作業が進み、それぞれのプロセスがどんな役割を持つのかをざっくりとつかんでおきましょう。
システム開発では、まず「何を実現したいのか」を明確にする要件定義から始まり、その内容をもとに設計を行い、プログラムを作成します。作成したプログラムは、個別にテストしたあと統合し、システム全体として正しく動くかを確認します。その後、実際の業務環境に導入して受入れテストを行い、問題がなければ本番運用に移行します。運用開始後も、システムやソフトウェアの修正・改善を続ける保守のプロセスが続きます。
この一連の流れを意識しておくと、各フェーズで登場する用語の位置づけが分かりやすくなります。
2. 要件定義フェーズ：必要な機能と品質を決める
この章では、システム要件定義・ソフトウェア要件定義の段階で決める内容と、関連する用語を整理します。ここでの決定が、その後の設計・開発の土台になります。
機能要件
機能要件とは、「システムが何をできる必要があるか」を示す要件です。たとえば販売管理システムであれば、「受注登録ができる」「請求書を発行できる」「売上レポートを出力できる」といった、具体的な機能のことを指します。
要件定義では、業務フローや利用者のニーズをもとに、必要な機能を漏れなく洗い出していきます。機能要件が曖昧なままだと、完成したシステムが「欲しかったものと違う」という結果になりかねません。
非機能要件
非機能要件とは、「どのように動くべきか」「どの程度の品質が必要か」といった、機能以外の観点に関する要件です。代表的なものに、性能、信頼性、安全性、操作性、保守性などがあります。
たとえば「ピーク時でも3秒以内に画面を表示する」「24時間365日連続稼働する」「誤操作が起きにくい画面構成にする」といった要求が非機能要件です。非機能要件をしっかり決めておかないと、機能は揃っていても「遅くて使いものにならない」「すぐ落ちる」システムになってしまいます。
品質特性
品質特性とは、システムやソフトウェアの品質を評価するための観点のことです。ITパスポート試験では、機能性、効率性、使用性（ユーザビリティ）、信頼性などがよく登場します。
機能性は「必要な機能を正しく提供できるか」、効率性は「資源（CPU、メモリなど）を無駄なく使えているか」、使用性は「利用者が直感的に扱えるか」、信頼性は「故障せず安定して動作するか」といった観点です。要件定義では、どの品質特性をどの程度重視するかを決めておくことが重要です。
共同レビュー
共同レビューとは、要件定義書などの成果物を、関係者が一緒に読み合わせて内容を確認する活動です。利用者側、開発側、運用側など、さまざまな立場のメンバーが参加し、「解釈の違い」や「抜け漏れ」を早い段階で見つけます。
レビューの時点で問題点を修正しておけば、後続工程での手戻りを大幅に減らすことができるため、品質向上とコスト削減の両面で重要な取り組みです。
3. 設計フェーズ：システムの具体的な形を決める
この章では、要件定義をもとにシステムの構造を決める設計フェーズと、関連する用語を説明します。ここで決まった内容に従って、後のプログラミングが行われます。
機能設計
機能設計は、要件定義で決めた機能要件をもとに、「画面や帳票、バッチ処理などをどのような機能単位に分けて実現するか」を決める設計です。業務フローとシステム機能の対応関係を整理し、「このボタンを押すとどんな処理が走るか」「どのタイミングでどのデータを更新するか」といった点を明らかにします。
機能設計は、主に利用者から見える動きや業務の流れに近いレベルの設計であり、「何をどう実現するか」を分かりやすく整理する役割を持ちます。
詳細設計
詳細設計は、機能設計で決めた内容を、プログラムがそのまま実装できるレベルまで細かく落とし込む設計です。具体的には、テーブルの項目定義、データの型や桁数、処理の分岐条件、ループの構造、画面の項目配置などを詳細に記述します。
詳細設計が丁寧に作られていれば、プログラマは迷わずにコーディングでき、ソースコードの品質も安定しやすくなります。逆に、詳細設計が不十分だと、プログラムごとにばらつきが出てしまいます。
4. プログラミングと単体テスト
この章では、設計に従ってプログラムを作り、個々のプログラムに誤りがないかを確認する段階について、関連用語と合わせて説明します。プログラミングと単体テストはセットで考えると理解しやすくなります。
コーディング
コーディングとは、プログラマが設計書をもとに、プログラミング言語でソースコードを書く作業です。機能や詳細設計の内容を、コンピュータが理解できる形に翻訳していくイメージです。
読みやすく保守しやすいコードを書くために、命名規則やコメントの書き方、インデントなどのコーディング規約を守ることが大切です。
単体テスト
単体テストとは、作成したプログラムを「部品（モジュール）」ごとに取り出し、その部品単体として正しく動作するかを確認するテストです。設計どおりの入力を与えたときに期待どおりの結果が返ってくるか、異常な入力に対して適切にエラー処理が行われるかなどをチェックします。
単体テストの目的は、バグをできるだけ早い段階で見つけて修正することです。後の工程に進んでから不具合が見つかると、手戻りの影響範囲が大きくなるため、単体テストでしっかり品質を確保しておくことが重要です。ホワイトボックステストやテストデータの作成といった活動は、この単体テストを効果的に行うための手法・準備だと捉えると理解しやすくなります。
テストデータの作成及び分析
単体テストを行うためには、さまざまなパターンの入力値を用意する必要があります。これがテストデータの作成です。正常なケースだけでなく、わざと異常な値や境界値を入れることで、プログラムが想定外の入力でも正しく処理できるかを確認します。
テスト結果を分析し、どの入力でどのような不具合が起きたのかを整理することで、効率的にバグの原因を特定し、修正につなげることができます。
ホワイトボックステスト
ホワイトボックステストは、プログラムの内部構造（分岐やループなど）を意識しながら行うテストです。ソースコードの中の全ての分岐を最低1回は通るようにテストケースを作る、などの方法があります。
単体テストでは、ホワイトボックステストを使って、コードの書き間違いによるバグを細かく洗い出していきます。
デバッグ
デバッグとは、テストで見つかったバグ（誤り）の原因を調査し、修正する作業です。ログの確認や、デバッガを使ったステップ実行、変数の中身の確認などを行い、「どこで期待と違う動きをしているのか」を特定します。
デバッグは時間がかかりやすいため、そもそもバグを入れない設計・コーディングを心掛けることも重要です。
コードレビュー
コードレビューは、他の開発者がソースコードを読み、設計との整合性やコーディングルールの遵守状況、潜在的なバグの有無などを確認する活動です。自分一人では気づきにくい問題点を、第三者の目で見つけてもらうことで、品質向上につながります。
レビューは教育の場としても有効で、チーム内でノウハウを共有する効果もあります。
5. 統合テストとシステムテスト
この章では、単体テスト済みのプログラムを統合し、システム全体が要件どおりに動作するかを確認するテストの段階について説明します。テストには「計画 → 実施 → 評価」のサイクルがある点も重要です。
統合テスト
統合テストは、個々のプログラム同士を組み合わせて動かし、連携部分で問題がないかを確認するテストです。たとえば、「画面で入力した値が正しくデータベースに保存されるか」「別のシステムに正しいデータが渡るか」などを確認します。
単体テストでは見つからない、「プログラム同士のつながり方」に起因する不具合を検出するのが目的です。
ブラックボックステスト
ブラックボックステストは、システムの内部構造を意識せず、外部からの入力と出力だけを確認するテスト手法です。利用者の視点に近く、「この入力に対してこの結果が返ってくるか」をチェックします。
統合テストやシステムテストでは、ブラックボックステストを用いて、要件どおりの機能が提供されているかを確認することが多くなります。
性能テスト
性能テストは、応答時間や処理速度など、システムの性能に関する要件を満たしているかを確認するテストです。多数の利用者が同時にアクセスする状況を再現し、「ピーク時でも一定時間以内に処理できるか」などを検証します。
性能要件は非機能要件の一つなので、このテストは非機能要件が満たされているかを確かめるための重要な工程です。
負荷テスト
負荷テストは、システムに通常よりも高い負荷をかけたときの振る舞いを確認するテストです。たとえば、短時間に大量のアクセスを集中させ、システムがどの程度まで耐えられるか、どこでボトルネックが発生するかを調べます。
負荷テストにより、運用開始後に発生しうるアクセス集中やバッチ処理のピークに対して、事前に対策を検討できます。
回帰テスト
回帰テスト（リグレッションテスト）は、システムの一部を修正したときに、他の部分に悪影響が出ていないかを確認するテストです。バグの修正や機能追加を行うたびに、関連する機能を再度テストし、以前は正常だった処理が壊れていないかを確認します。
システムの寿命が長くなるほど変更回数も増えるため、回帰テストは品質を維持するうえで欠かせない作業となります。
6. 導入と受入れ：本番運用への橋渡し
この章では、完成したシステムを実際の運用環境に導入し、受入れテストを行う段階について説明します。取得者（委託側）と供給者（受託側）が協力して確認を行う場面です。
利用者マニュアル
利用者マニュアルは、システムの使い方をまとめた説明書です。画面の意味やボタンの役割、入力ルール、エラーが出たときの対処方法などが記載されます。
導入時には、このマニュアルを使いながら利用者への教育・訓練が行われます。分かりやすいマニュアルがあれば、問い合わせや誤操作を減らすことにもつながります。
受入れテスト
受入れテストは、取得者（委託側）が主体となって行うテストで、システムが契約どおりに作られているか、業務で問題なく使えるかを確認します。ここで重大な問題がなければ、システムの納入が行われます。
受入れテストは、システムの「最終確認」の役割を持つため、テスト観点やテストケースを事前にしっかり準備しておくことが重要です。
妥当性確認テスト
妥当性確認テストは、システムが意図した用途を達成しているかどうかを確認するテストです。単に機能が動くだけでなく、「業務目的を達成できる仕組みになっているか」を見る点が特徴です。
たとえば、「在庫の適正化を目的として導入したシステムが、本当に在庫管理業務を改善しているか」といった観点で評価します。
移行
移行とは、旧システムから新システムへデータや業務を切り替える作業です。マスタデータや履歴情報の移行、運用手順の切り替え、並行稼働期間の設定など、多くの調整が必要になるプロセスです。
移行作業でトラブルが起きると、業務に直接影響が出るため、事前の計画立案とリハーサルが非常に重要になります。
7. 保守フェーズ：システムを育て続ける
この章では、運用開始後に行われる保守の役割について説明します。システムは稼働し始めてからが本当のスタートとも言えます。
保守とは、システムの安定稼働を維持しつつ、ITの進展や経営戦略の変化に対応するために、システム・ソフトウェアの修正、変更、改善を行うことです。具体的には、障害対応、法制度改正への対応、新しい業務への対応、性能改善などが含まれます。
保守の過程では、変更による影響を確認するための回帰テストも重要になります。計画的な保守を続けることで、システムを長く安全に使い続けることができます。
まとめ
本記事では、システム開発のプロセスとして、要件定義・設計・プログラミングと単体テスト・統合テスト・導入と受入れ・保守という一連の流れを整理しました。それぞれの段階で、何を決め、どのような作業を行うのかを理解しておくことが、システム開発全体を正しくイメージするうえで重要です。
あわせて、機能要件・非機能要件・品質特性・共同レビュー、機能設計・詳細設計、コーディング・ホワイトボックステスト・デバッグ・コードレビュー・テストデータの作成及び分析、統合テスト・ブラックボックステスト・性能テスト・負荷テスト・回帰テスト、利用者マニュアル・受入れテスト・妥当性確認テスト・移行といった用語を、それぞれのプロセスの中で位置づけて説明しました。
システム開発の用語は単独で覚えると混乱しがちですが、「どのフェーズで、何のために使う考え方か」という流れとセットで理解すると整理しやすくなります。ITパスポート試験では、プロセスの順番や各段階の役割、そこに登場する用語の意味がよく問われるので、本記事の内容を頭の中で開発のストーリーとしてイメージできるようにしておきましょう。
コメント