最終更新日：2026年10月3日
fe fe-management project-management quality
まず結論
システム開発の品質管理では、自社で作ったプログラムだけでなく、設計書・テスト結果・性能・外部から導入した製品なども含め、システムとして必要な品質を満たしているかを確認することが重要です。
基本情報技術者試験では、次の2つをまず押さえると判断しやすくなります。
一部分の品質が良い
≠ システム全体の品質も必ず良い
プログラムだけを見る
≠ 品質管理の対象として十分
特に、応答時間や処理時間などの性能も品質の一部です。
品質管理は「作ったコードだけ」ではなく、「成果物とシステム全体」を見る。
直感的な説明
例えば、販売管理システムを次の3つのサブシステムに分けて開発するとします。
受注管理
在庫管理
請求管理
それぞれ単体でテストした結果、すべて問題なく動いたとします。
しかし、3つを接続すると、
受注データの受渡し形式が合わない
↓
在庫更新に失敗する
処理が集中する
↓
応答時間が大きくなる
市販パッケージとの連携条件が合わない
↓
請求処理が止まる
といった問題が起こることがあります。
つまり、
部品ごとには正常
↓
組み合わせると問題が出る
ことがあります。
品質管理では、各部分の品質だけでなく、統合したシステム全体として要求を満たしているかを見る必要があります。
定義・仕組み
システム開発における品質管理は、開発した成果物やシステムが、求められた品質を満たしているかを計画的に確認・管理する活動です。
FE試験では、細かな品質管理手法を丸暗記するより、
何が品質管理の対象になるのか
を判断できることが重要です。
品質管理の対象はプログラムだけではない
システム開発では、プログラム以外にも多くの成果物があります。
例えば、次のようなものです。
- 要件定義書
- 設計書
- プログラム
- テスト仕様書
- テスト結果
- 運用手順書
- 利用者向けマニュアル
設計書に誤りがあれば、その後に正しいプログラムを作ることも難しくなります。
そのため、品質管理では最終的なプログラムだけでなく、開発途中で作られる成果物も確認対象になります。
性能も品質の一部
品質というと、「正しく動くか」だけを考えやすいですが、それだけではありません。
例えば、
画面を2秒以内に表示する
1時間に1万件処理できる
一定数の利用者が同時に接続できる
といった性能も品質に関係します。
応答時間や処理時間が業務に大きな影響を与えるなら、性能を測定し、要求された水準を満たしているか確認する必要があります。
性能などの品質特性については、ソフトウェア品質特性とは？でも整理しています。
外部製品を使っても、システム全体の品質確認は必要
システムでは、自社開発プログラムだけでなく、市販ソフトウェアや外部サービスを組み合わせることがあります。
自社開発プログラム
+
市販パッケージ
+
データベース製品
+
外部サービス
↓
一つのシステムとして利用
この場合、自社が市販製品そのものの製造工程を管理するわけではありません。
しかし、導入した製品を含むシステム全体が要求どおり動くかは確認する必要があります。
試験では、
市販製品だから品質管理の対象外
と単純に考えないことがポイントです。
部分品質と全体品質は別に確認する
サブシステム単位で品質が確認できても、それだけでシステム全体の品質が保証されるとは限りません。
システムを統合すると、
- データ形式の不一致
- インタフェースの不具合
- 処理順序の問題
- 性能低下
- 障害時の連鎖
- 外部製品との相性
などが表面化することがあります。
単体で確認
↓
部分の品質
統合して確認
↓
システム全体の品質
この2段階を分けて考えることが重要です。
科目Aでどう出る？
科目Aでは、品質管理について対象を狭く考えすぎている選択肢が誤りになりやすいです。
次のように判断します。
| 選択肢の考え方 | 判断 |
|---|---|
| サブシステムごとに品質を確認すれば全体も自動的に保証される | 誤りを疑う |
| 応答時間や処理時間は性能なので品質管理とは無関係 | 誤りを疑う |
| プログラムだけでなく設計書などの成果物も確認する | 適切 |
| 市販製品を使う場合、自社開発部分だけ確認すればよい | 誤りを疑う |
「だけ」「自動的に保証」に注意する
品質管理の問題では、次のような表現に注意します。
〜だけを対象とする
〜さえ確認すればよい
自動的に全体の品質も保証される
対象外である
システム開発では、複数の成果物・部品・工程が関係します。
そのため、対象範囲を極端に限定する説明は誤りになりやすいです。
性能を品質から外さない
応答時間や処理時間は、単なる測定値ではありません。
要求された性能水準を満たしているかどうかは、システムの品質を判断する重要な材料です。
正しい結果を返す
+
必要な時間内に返す
↓
実際の業務で使える
この点は、非機能要件とは？の「どのくらい速く・安定して使えるか」という考え方ともつながります。
どんな場面で使う？
設計レビュー
設計書の段階で、要求を正しく反映しているか、不整合がないかを確認します。
プログラムを書く前に問題を見つけることで、後工程の手戻りを減らしやすくなります。
レビュー手法については、インスペクションとは？も参考になります。
テスト
単体テストでは個々のプログラムやモジュールを確認し、結合・システムテストでは、組み合わせた状態で動作や性能を確認します。
個別に正しいか
↓
単体レベル
接続して正しいか
↓
結合レベル
全体として要求を満たすか
↓
システムレベル
外部製品やサービスの導入
市販製品やクラウドサービスを導入するときも、単に「有名な製品だから大丈夫」とは考えません。
自分たちのシステムの要求、インタフェース、性能、運用条件に合うかを確認します。
よくある誤解・混同
サブシステムが全部正常なら、全体も正常
必ずしもそうではありません。
各サブシステムの接続部分や、同時に動かしたときの性能などは、統合後に問題になることがあります。
部分の品質
≠ 全体品質の自動保証
性能は品質管理ではない
違います。
性能は、システムが要求された時間や処理量で動けるかを見る重要な品質要素です。
特に、
- 応答時間
- バッチ処理時間
- スループット
- 同時利用者数
などは、要求と実測値を比較して確認します。
品質管理はプログラムのテストだけ
違います。
設計書やテスト結果、運用手順なども、システムを正しく作り運用するための成果物です。
品質管理を「完成したコードのテスト」だけに限定しないことが重要です。
市販製品は品質管理の対象外
「市販製品そのものの製造工程まで自社で管理する」という意味ではありません。
ただし、その製品をシステムへ組み込むなら、
要求を満たすか
正しく連携できるか
必要な性能が出るか
など、システムの一部としての適合性や品質を確認する必要があります。
品質特性と品質管理は同じ
同じではありません。
品質特性
→ どのような品質を見るか
例：性能効率性、信頼性、使用性
品質管理
→ 求める品質を満たすために
何を確認・管理するか
品質特性を整理したい場合は、ソフトウェア品質特性とは？を参照してください。
まとめ（試験直前用）
- 品質管理はプログラムだけではなく、設計書・テスト結果などの成果物も対象
- 応答時間・処理時間などの性能も品質の一部
- サブシステム単体の品質が良くても、システム全体の品質が自動的に保証されるわけではない
- 市販製品を使う場合も、組み込んだシステム全体として要求を満たすか確認する
- 選択肢の 「〜だけ」「対象外」「自動的に保証」 は、品質管理の範囲を狭くしすぎていないか確認する
公式の出題範囲やシラバスは、IPA：基本情報技術者試験から確認できます。