【SC試験・午前1】システム開発技術を攻略！開発手法・凝集度と結合度・テスト技法の頻出パターン完全ガイド

「モジュールの独立性を高めるために、凝集度と結合度はそれぞれどうあるべきか」

午前1（科目A-1）のシステム開発技術は、この手の「用語の定義さえ正しく覚えていれば即答できる」問題が中心です。計算はほとんど登場せず、暗記量も限られています。テクノロジ系の中で最も投資対効果が高い分野のひとつだと言い切れます。

なお、SC試験は2026年度からCBT方式へ移行し、試験区分の名称も変更されます。午前Ⅰが科目A-1、午前Ⅱが科目A-2、午後が科目Bという呼び方になります。これはIPAの試験要綱Ver.5.6（2026年10月の試験から適用）に反映済みで、出題範囲・出題数・試験時間に変更はありません。制度変更の詳細は「【2026年度版】情報処理安全確保支援士試験のCBT化で何が変わる？科目A/科目Bの新名称と対策の変え方」で解説しています。本記事では検索でたどり着きやすい「午前1」の呼称を主軸にしつつ、新名称を併記して進めます。

筆者はIT企業でインフラエンジニアとしてサーバーやルーターの設定・設計を担当し、その後、そこで培ったノウハウを持ち込むかたちで事業会社のCIOとして社内のIT統制に携わりました。開発の現場に立ち会うと、テスト工程で見つかる不具合の多くは「テストの腕」ではなく「工程の切り方」と「モジュールの分け方」で決まっていることがよく分かります。試験に並ぶ凝集度・結合度・網羅基準といった用語は、そのまま品質を守るための設計論そのものです。

本シリーズの全体戦略は導入記事「元CIOが実践するスタミナ温存術！「コスパ極振り」最短エスケープルート・完全版ロードマップ」に、前回のデータベースは「データベースを攻略！正規化・E-R図・SQL・ACID特性の頻出パターン完全ガイド」にまとめています。本記事はテクノロジ系の第7回、第1部の締めくくりにあたります。

この記事で学べること

• 午前1のシステム開発技術で「取る問題」と「捨てる問題」の線引き
• ウォータフォールモデルの工程とV字モデルの対応関係
• アジャイル・スクラム・XP・DevOpsの用語を、選択肢の中で見分ける基準
• 凝集度7段階と結合度6段階の順序を、意味から思い出す方法
• ホワイトボックステストの網羅基準（命令網羅・判定条件網羅・条件網羅・複合条件網羅）の違いと網羅率の数え方
• 同値分割と限界値分析でテストケースを設計する手順
• テスト工程の順序、トップダウン／ボトムアップとスタブ・ドライバの対応
• レビューの種類、信頼性成長曲線、ファンクションポイント法とCOCOMO、UMLの図の使い分け

午前1のシステム開発技術は「テスト技法・モジュール設計・開発手法」で取り切る

最初に投資先を決めます。この分野は範囲が広く見えますが、午前1で実際に問われる論点は驚くほど固定されています。

午前1は30問中18問で通過する試験

午前1は30問出題され、100点満点中60点以上で通過します。18問取れば十分です。テクノロジ系・マネジメント系・ストラテジ系の全分野から出るため、どの分野も満点は不要です。システム開発技術からの出題はおおむね2問前後で、そのほとんどが用語の定義か技法の選択です。計算問題が出るとすれば網羅率かファンクションポイントの単純な集計程度で、データベースやネットワークのような重い計算はまず出ません。

取る問題：凝集度と結合度、テスト技法、開発手法の用語

優先して押さえるのは次の4つです。

1つ目はモジュールの独立性です。 凝集度と結合度の段階を、どちらが望ましいかまで含めて答えられる状態にします。「凝集度は高く、結合度は低く」という結論だけでなく、各段階の名称と意味の対応が問われます。

2つ目はテスト技法です。 ホワイトボックステストの網羅基準と、ブラックボックステストの同値分割・限界値分析。これは毎年のように顔を出します。

3つ目はテスト工程と補助モジュールです。 単体テストから受入テストまでの順序、トップダウン統合とボトムアップ統合、スタブとドライバの対応。定型問題です。

4つ目は開発手法の用語です。 ウォータフォール、プロトタイピング、スパイラル、アジャイル、スクラム、XP、DevOps。それぞれの特徴を一言で言えれば足ります。

捨てる問題：見積り技法の細部と個別の設計技法

逆に、時間をかけない領域も決めておきます。ファンクションポイント法の調整係数の計算、COCOMOの係数モデルの詳細、構造化分析のDFD記法の厳密なルール、CMMIの成熟度レベルの細かい定義、UMLの全種類の図の暗記といった論点は、労力に対する見返りが小さい部分です。名称と一言の説明だけ押さえ、出たら消去法で当てにいく判断で構いません。

委託元の指示を現場に徹底させる難しさ

IT企業にいた頃は自社が外部の委託先になるケースが多く、委託元から開発の進め方について様々な指示がありました。対応しなければ仕事がなくなるという事情もあり、その指示を現場に徹底させるのに苦労した記憶があります。工程の区切り方、成果物の様式、レビューの実施記録。その後、事業会社のCIOとして発注する側に回ると、同じ約束事が今度は「委託先にどう守ってもらうか」という課題に姿を変えました。試験では「共通フレーム」や「開発プロセス」という言葉で無味乾燥に登場しますが、実態は発注側と受注側が同じ言葉で話すための共通語彙です。用語を暗記するときも「これは誰と誰の認識を揃えるための言葉か」と考えると定着します。

開発プロセスと開発手法：工程の切り方で品質が決まる

まずは開発全体の流れを押さえます。工程の名前と順序が頭に入っていないと、テスト工程の問題もモジュール分割の問題も足場を失います。

ウォータフォールモデルと基本的な工程

ウォータフォールモデル（waterfall model）は、要件定義から順に工程を進め、原則として前の工程へ戻らない開発モデルです。標準的な工程は次の順序です。

• 要件定義：利用者が何を求めているかを決める
• 外部設計（基本設計）：利用者から見えるインタフェース・画面・帳票を決める
• 内部設計（詳細設計）：システム内部の構造とモジュールを決める
• プログラミング（実装）：コードを書く
• テスト：単体・結合・システム・受入の順で検証する
• 運用・保守：稼働後の維持と改善を行う

最大の利点は、工程ごとに成果物が定まり進捗を管理しやすいことです。弱点は、要件の誤りが後工程で発覚したときの手戻りが大きいことです。上流の欠陥ほど修正コストが跳ね上がるという性質は、後述するレビューの重要性の根拠にもなっています。

V字モデル：どのテストがどの工程を検証するのか

V字モデルは、ウォータフォールの各工程と、それを検証するテスト工程を対応づけて示したモデルです。左側に設計工程、右側にテスト工程を配置し、同じ高さの工程同士が対応します。

• 要件定義 ↔ 受入テスト（発注者が要件どおりかを確認する）
• 外部設計 ↔ システムテスト（システム全体が設計どおり動くかを確認する）
• 内部設計 ↔ 結合テスト（モジュール間の連携を確認する）
• プログラミング ↔ 単体テスト（モジュール単体の内部ロジックを確認する）

この対応を押さえておくと、「結合テストで検証する設計書はどれか」といった問題が瞬時に解けます。学習を始めたばかりの頃につまずきやすいのは、システムテストと受入テストの主体の違いです。システムテストは開発側が実施し、受入テストは発注者・利用者側が実施すると整理してください。

反復型の系譜：プロトタイピングとスパイラルモデル

ウォータフォールの弱点を補う考え方が反復型です。

プロトタイピングモデルは、早い段階で試作品を作り、利用者に確認してもらってから作り込む手法です。要件が固まりにくい画面系の開発で有効です。

スパイラルモデルは、システムを部分に分割し、「設計→実装→評価」のサイクルを繰り返しながら段階的に完成度を高める手法です。リスクの高い部分から着手する点が特徴です。

RAD（Rapid Application Development）は、少人数のチームとツールを活用して短期間で開発する手法で、期限を優先して機能を調整するタイムボックスの考え方を伴います。

アジャイル開発とスクラムの用語

アジャイル開発は、短い期間の反復で動くソフトウェアを継続的に届ける考え方の総称です。アジャイルソフトウェア開発宣言では、プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする、と示されています。左側の項目に価値がないという意味ではなく、右側をより重視するという相対的な表明である点は押さえておいてください。

代表的な実践方法であるスクラムは、次の要素で構成されます。

• 役割：プロダクトオーナー（何を作るかの優先順位に責任を持つ）、スクラムマスター（プロセスの円滑化に責任を持つ）、開発者
• 作成物：プロダクトバックログ（要求の優先順リスト）、スプリントバックログ（そのスプリントで扱う作業）、インクリメント（完成した成果物）
• イベント：スプリント（短い固定期間の反復）、スプリントプランニング（スプリントの計画）、デイリースクラム（毎日の短時間の同期）、スプリントレビュー（成果物の確認）、スプリントレトロスペクティブ（進め方の振り返り）

XP（eXtreme Programming）は、ペアプログラミング、テスト駆動開発、リファクタリング、継続的インテグレーション、小さなリリースといったプラクティスを掲げる手法です。午前1では「ペアプログラミングはどの手法のプラクティスか」といった形で問われます。

ここでのつまずきポイントは、リファクタリングの定義です。リファクタリングは外部から見た振る舞いを変えずに内部構造を改善する作業であり、機能追加や性能改善そのものではありません。選択肢では「機能を追加しながらコードを整理する」といった形で誤りが混ぜられます。

要件が固まらないまま1年半をかけたプロジェクト

事業会社のCIOだった頃、CTI（電話をかける仕組み）とCRM（顧客管理の仕組み）を統合する新システム開発でプロジェクト責任者を務めたことがあります。要件定義をしても、現場の業務スピードが速く、要件がどんどん変わっていきました。結局1年半を費やしてプロジェクトは頓挫しています。今なら、業務改善や業務の共通化といったシステムの外側での対応をまず考えるところですが、当時は何でもシステムで吸収するという短絡的な思考回路でした。この経験は、後年ITコーディネータを志す動機の一つにもなっています。

ウォータフォールは「要件が固まること」を前提に置いた手法です。変化の速い業務にその前提をあてはめた時点で無理がありました。アジャイルが価値として掲げる「計画に従うことよりも変化への対応を」という一文は、試験では選択肢の暗記対象ですが、実際には要件が動く現場で計画を守り切ろうとした結果を知っている人ほど重く読める言葉です。手法の選択は、開発チームの好みではなく、要件がどれだけ動くかで決まります。

DevOpsとCI/CD

DevOpsは、開発（Development）と運用（Operations）が連携し、自動化と継続的な改善によってリリースの頻度と品質を両立させる考え方です。技術的な柱が次の2つです。

• CI（継続的インテグレーション）：コードの変更を頻繁に統合し、その都度ビルドと自動テストを実行する
• CD（継続的デリバリー／継続的デプロイメント）：テストを通過した成果物を、いつでもリリースできる状態に保つ、あるいは自動的に本番へ反映する

セキュリティの観点を開発プロセスの早い段階から組み込む考え方がDevSecOpsです。SC試験ではこちらが本丸で、詳しくは「手戻りゼロのシステム開発へ！セキュリティバイデザインとDevSecOpsの完全導入ガイド」で解説しています。

共通フレームとソフトウェアライフサイクル

共通フレーム（SLCP：ソフトウェアライフサイクルプロセス）は、ソフトウェアの企画から開発、運用、保守、廃棄までのライフサイクル全体について、作業内容と用語を共通化するためのガイドラインです。取得者（発注側）と供給者（受注側）が同じ言葉で話し、責任範囲の認識違いをなくすことを目的としています。特定の開発モデルを強制するものではない、という点が選択肢の引っかけになります。

モジュール分割：凝集度は高く、結合度は低く

ここからは設計の中身に入ります。午前1で最も出やすい定番論点です。

モジュールの独立性という考え方

モジュールの独立性が高いほど、変更の影響範囲が狭くなり、単体テストがしやすく、再利用もしやすくなります。独立性を測る2つのものさしが凝集度（cohesion）と結合度（coupling）です。結論は単純で、「凝集度は高く、結合度は低く」が望ましい状態です。まずこの一文を確実に覚えます。

凝集度の7段階

凝集度は、1つのモジュール内部の要素がどれだけ強く関連しているかを示します。弱い順に並べると次のとおりです。

1. 暗合的凝集（偶発的凝集）：関連のない処理をただ寄せ集めただけ
2. 論理的凝集：関連する複数の機能を持ち、引数で処理を選択して呼び出す
3. 時間的凝集：初期処理・終了処理など、同じタイミングで実行される処理をまとめた
4. 手続的凝集（手順的凝集）：順番に実行される複数の処理をまとめた
5. 連絡的凝集：手続的凝集に加え、処理間で同じデータをやり取りする
6. 情報的凝集：同じデータ構造を扱う複数の機能をまとめ、入口を分けている
7. 機能的凝集：単一の明確な機能だけを実現している（最も望ましい）

覚え方としては、両端の2つを確実に押さえるのが実戦的です。最悪が暗合的凝集、最良が機能的凝集。中間の順序は「時間→手続→連絡」と、まとまりの根拠が時間からデータへ移っていく流れで思い出せます。

結合度の6段階

結合度は、モジュール間の依存の強さを示します。強い（望ましくない）順に並べると次のとおりです。

1. 内容結合：他モジュールの内部を直接参照・書き換えする（最悪）
2. 共通結合：複数モジュールが共通のグローバルデータ領域を参照する
3. 外部結合：外部宣言した個々のデータを共有する
4. 制御結合：処理の流れを指示する制御用の引数を渡す
5. スタンプ結合：データ構造（レコード全体）を引数で渡し、一部だけを使う
6. データ結合：必要なデータ項目だけを引数で渡す（最も望ましい）

つまずきやすいのはスタンプ結合とデータ結合の区別です。レコードや構造体をまるごと渡していればスタンプ結合、使う項目だけを渡していればデータ結合と判断します。また、制御結合は「相手のモジュールの中でどう動くかを呼び出し側が決めてしまう」ため、論理的凝集と対になって現れやすい関係にあります。

分割の技法と関連用語

モジュール分割の代表的な技法として、データの流れに着目するSTS分割（入力・変換・出力の3つに分ける）、繰り返し現れる共通機能を切り出す共通機能分割、データ構造に基づいて分割するジャクソン法やワーニエ法があります。名称と着眼点の対応だけ押さえておけば十分です。

テスト技法：ホワイトボックスとブラックボックスの使い分け

出題頻度の最も高い論点です。ここは定義の暗記ではなく、簡単な例で数えられる状態を目指します。

ホワイトボックステストの網羅基準

ホワイトボックステストは、プログラムの内部構造（制御の流れ）に着目してテストケースを設計する技法で、主に単体テストで使います。網羅の水準は、おおむね弱いものから順に次のとおりです（後述のとおり、条件網羅と判定条件網羅は一方が他方を含む関係ではない点に注意してください）。

• 命令網羅（C0）：すべての命令を少なくとも1回実行する
• 判定条件網羅（分岐網羅、C1）：すべての判定について、真と偽の両方の結果を少なくとも1回ずつ通る
• 条件網羅（C2）：判定を構成する個々の条件について、真と偽の両方を少なくとも1回ずつ取る
• 複合条件網羅：個々の条件の真偽の組み合わせをすべて網羅する（最も強い）

ここが最大のつまずきポイントです。条件網羅は判定条件網羅を必ずしも満たしません。たとえば判定が A かつ B の場合、(A=真, B=偽) と (A=偽, B=真) の2ケースで条件網羅は達成できますが、判定結果はどちらも偽で、真になるケースを1度も通りません。「条件網羅のほうが番号が大きいから強い」と単純に考えると誤ります。両方を満たす基準は判定条件／条件網羅と呼ばれます。

網羅率の数え方

網羅率は「実行した対象 ÷ 全体」で求めます。命令網羅率であれば、テストで実行された命令数を全命令数で割った値です。分岐網羅率であれば、通過した分岐の方向の数を全分岐方向数で割ります。午前1で計算が出る場合はこの程度の単純な割り算で、フローチャートを読んで通過した経路を数えるだけです。

次の図解は、判定が真の場合にだけ処理があるプログラムを想定して、4つの網羅基準に必要なテストケースを並べたものです。

ブラックボックステストの技法

ブラックボックステストは、内部構造を見ず、入力と出力の仕様だけに着目してテストケースを設計する技法です。結合テスト以降やシステムテストで中心となります。

同値分割は、入力値を「同じ結果になるはずのグループ（同値クラス）」に分け、各グループから代表値を1つずつ選ぶ技法です。仕様上正しい値のグループを有効同値クラス、それ以外を無効同値クラスと呼びます。

限界値分析（境界値分析）は、同値クラスの境界とその前後の値をテストケースにする技法です。実装の誤りは境界に集中するという経験則が根拠です。たとえば「入力値は1以上100以下」という仕様なら、0、1、100、101がテストケースの候補になります。

その他、入力の原因と出力の結果の論理関係を整理する原因結果グラフ（決定表を導出する）、条件の組み合わせを表で網羅する決定表（デシジョンテーブル）、経験に基づいて誤りの多そうな箇所を狙うエラー推測があります。

学び始めの人がつまずくのは、限界値の取り方です。「1以上100以下」なら境界は1と100であり、有効側の1と100、無効側の0と101をセットで取ります。「100未満」であれば境界は99と100に変わります。仕様の日本語（以上・以下・未満・超）を正確に読み替える習慣をつけてください。

テスト工程・レビュー・品質管理：どこで何を検出するか

技法を知っていても、どの工程で使うかを取り違えると得点になりません。工程ごとの目的を整理します。

テスト工程の順序と目的

• 単体テスト：モジュール単体の内部ロジックを検証する。ホワイトボックステストが中心
• 結合テスト：モジュール間のインタフェースとデータの受け渡しを検証する
• システムテスト：システム全体として要求される機能・性能・セキュリティを開発側が検証する
• 運用テスト（受入テスト）：発注者・利用者が実際の業務手順で要件を満たすかを確認する

システムテストの中には、性能テスト、大量の負荷をかける負荷テスト、限界を超える負荷をかけるストレステスト、長時間の連続稼働を確認する耐久テスト、実際に攻撃を試みるペネトレーションテストなどが含まれます。改修後に既存機能が壊れていないかを確認するリグレッションテスト（回帰テスト）は、保守工程で必須の考え方です。

トップダウンテストとボトムアップテスト、スタブとドライバ

結合テストの進め方は2つあります。

トップダウンテストは、上位モジュールから順に結合していく方式です。まだ完成していない下位モジュールの代わりに、仮の値を返すスタブを用意します。

ボトムアップテストは、下位モジュールから順に結合していく方式です。呼び出す側の上位モジュールがまだないため、代わりに呼び出しを行うドライバを用意します。

両方を同時に進めて中間で合流させる方式をサンドイッチテスト、全モジュールを一度に結合する方式をビッグバンテストと呼びます。ビッグバンテストは不具合の原因箇所の特定が難しく、規模が大きいほど不利になります。

スタブとドライバの対応は取り違えが起きやすいポイントです。「上から攻めるとき下が足りない＝スタブ」「下から攻めるとき上が足りない＝ドライバ」と、方向とセットで覚えてください。

レビューの種類

テストの前段で欠陥を取り除く活動がレビューです。上流で見つけるほど修正コストが小さいという原則から、開発プロセス上きわめて重要視されます。

• ウォークスルー：作成者が主体となり、関係者を集めて成果物を説明しながら誤りを指摘してもらう。管理者は参加しないのが原則
• インスペクション：モデレータ（進行役）が主導し、事前に役割と手順を定めて公式に実施する。最も形式的で検出力が高い
• ラウンドロビンレビュー：参加者が持ち回りで責任者を務め、全員が主体的に参加する
• ピアレビュー：同僚同士で相互に確認する
• 机上デバッグ：作成者自身がコードを目で追って確認する

いずれの方式でも、レビューの目的は欠陥の検出であって、作成者の評価や人事考課ではありません。この原則が選択肢の正誤を分けることがあります。

信頼性成長曲線とバグ管理図

テストの進捗と品質を判断する道具が信頼性成長曲線（バグ曲線）です。横軸にテスト時間や消化したテスト項目数、縦軸に累積の不具合検出数を取ると、初期はゆるやかに立ち上がり、中盤で急増し、終盤で頭打ちになるS字型の曲線を描きます。この形状を表す代表的なモデルがゴンペルツ曲線とロジスティック曲線です。

曲線が頭打ちになれば、残存する欠陥が少なくなったと推定でき、テスト終了の判断材料になります。ただし、テスト項目の消化が進んでいないだけの場合も同じ形に見えるため、テスト消化件数と不具合検出数の両方を見る必要があります。両者を重ねて描いたものがバグ管理図です。

品質を定量的に見る関連指標としては、テスト密度（規模あたりのテスト項目数）、バグ密度（規模あたりの検出不具合数）があり、実績値と標準値の乖離から異常を検知します。

ソフトウェア見積り：規模から工数を導く

マネジメント系との境界にある論点ですが、午前1では用語の識別問題として出ます。

ファンクションポイント法

ファンクションポイント法（FP法）は、利用者から見える機能の数と複雑さから、ソフトウェアの規模を測る手法です。次の5つの要素を数え、それぞれの複雑度に応じた重みを掛けて合計します。

• 外部入力（EI）：データを登録・更新する入力機能
• 外部出力（EO）：帳票やレポートなど、加工した結果を出す機能
• 外部照会（EQ）：加工せずにデータを取り出して表示する機能
• 内部論理ファイル（ILF）：システム内部で保持するデータの集まり
• 外部インタフェースファイル（EIF）：他システムが保持し、参照するデータの集まり

最大の利点は、プログラム言語や実装技術に依存せず、要件定義の早い段階で見積もれることです。弱点は、数え方に主観が入り、評価者の熟練度に左右される点です。

LOC法・COCOMO・その他の技法

LOC法（プログラムステップ法）は、想定するソースコードの行数から工数を見積もる手法です。言語や書き方に強く依存し、設計が固まる前には使えません。

COCOMO（COnstructive COst MOdel）は、規模（KLOC）を基に、開発規模の指数と補正係数を用いて工数を算出するモデルです。組織固有の生産性データによる補正が前提となる点が特徴です。

そのほか、過去の類似案件から見積もる類推見積り、複数の専門家の意見を匿名で収束させるデルファイ法、作業を分解して標準時間を積み上げる標準タスク法（ボトムアップ見積り）があります。作業の分解にはWBS（Work Breakdown Structure）を用います。

オブジェクト指向とUML：用語の対応で得点する

最後にオブジェクト指向です。概念の深い理解より、用語の対応関係が問われます。

カプセル化・継承・多相性

• クラス：データ（属性）と操作（メソッド）をまとめた型の定義。インスタンスはクラスから生成した実体
• カプセル化：属性と操作を1つにまとめ、内部構造を隠して公開する操作だけで扱えるようにすること。情報隠蔽と併せて問われる
• 継承（インヘリタンス）：上位クラス（スーパークラス）の属性と操作を下位クラス（サブクラス）が引き継ぐこと
• 多相性（ポリモーフィズム）：同じメッセージを受け取っても、受け手のクラスによって異なる振る舞いをすること
• 汎化と特化：共通の性質を上位クラスにまとめるのが汎化、下位クラスへ細分化するのが特化。「is-a」の関係
• 集約：全体と部分の関係。「part-of」の関係で、より強い結び付き（部分が全体と生存期間を共にする）をコンポジションと呼ぶ

つまずきやすいのは、汎化（is-a）と集約（part-of）の混同です。「自動車は乗り物である」なら汎化、「自動車はタイヤを持つ」なら集約と判断します。

UMLの主要な図

UML（Unified Modeling Language）は、オブジェクト指向のモデルを表記する統一記法です。午前1で押さえるべき図は次の範囲で十分です。

• クラス図：クラスの構造と、クラス間の関連・汎化・集約を表す（構造図）
• ユースケース図：利用者（アクター）とシステムが提供する機能の関係を表す
• シーケンス図：オブジェクト間のメッセージのやり取りを時間の流れに沿って表す（振る舞い図）
• コミュニケーション図：同じ相互作用を、オブジェクト間の関連を主体に表す
• アクティビティ図：処理や業務の流れ、分岐と並行動作を表す
• 状態機械図：1つのオブジェクトが取る状態と、状態を遷移させる事象を表す

「時間の流れが縦軸に現れる図はどれか」といった問い方をされたらシーケンス図、「業務フローを表すのはどれか」ならアクティビティ図、と対応で答えられるようにしておきます。

開発を支える関連用語

リバースエンジニアリングは既存のソフトウェアから仕様や設計情報を導き出すこと、フォワードエンジニアリングは設計情報から新しいソフトウェアを生成すること、両者を組み合わせて既存資産を作り替えることをリエンジニアリングと呼びます。既存機能を再利用して新たなサービスを作るマッシュアップも、選択肢に混ぜられる用語です。

SC試験での出題パターンと対策

ここまでの内容が、実際の試験でどう問われるかを整理します。

午前1で繰り返される3つの型

第1の型は定義の言い換えです。「凝集度が最も高いものはどれか」「スタブの説明として適切なものはどれか」といった、用語と説明文を対応させる形式です。段階の順序と両端さえ覚えていれば消去法で決まります。

第2の型は技法の選択です。「内部構造に着目してテストケースを設計する技法はどれか」「境界付近の値を選ぶ技法はどれか」という形で、状況に対して技法名を答えます。

第3の型は簡単な数え上げです。フローチャートを読んで網羅率を求める、限界値分析でテストケースの個数を答える、といった形式です。落ち着いて数えれば確実に取れます。

いずれも過去問での出題形式は安定しており、午前1では類似の問題が繰り返し出題されています。過去問を分野で絞って解き、選択肢の言い回しに慣れておくのが最短の対策です。

SC試験の午前2・午後との接続

システム開発技術は、SC試験本体ではセキュア開発として姿を変えて登場します。午前2では、脆弱性を作り込まないコーディング、静的解析と動的解析、ファジングといった論点で問われます。午後では、開発工程のどこでセキュリティレビューを入れるか、テスト工程で脆弱性診断をどう組み込むか、委託先の開発プロセスをどう管理するかといった形で事例に埋め込まれます。

つまり、午前1で学ぶV字モデルやレビューの分類は、午後の「上流でセキュリティ要件を定義し、下流で検証する」という論理の土台です。関連する内容は「手戻りゼロの堅牢なコードを！セキュア開発と脆弱性対策の総復習」および「未知のバグをあぶり出す！ファジングと静的・動的解析の仕組みと使い分け」で扱っています。午前1の学習をそのまま午後の得点につなげられる、数少ない分野です。

【演習】システム開発技術 理解度チェック（全10問）

午前1では、凝集度と結合度の段階、テスト技法の識別、スタブとドライバの対応、開発手法の用語が定型で問われます。午後では、開発工程へのセキュリティレビューの組み込みや委託先の開発プロセス管理という形で、同じ知識が事例の中に登場します。定番の引っかけは、条件網羅が判定条件網羅を満たすと思い込む誤り、スタブとドライバの逆転、リファクタリングを機能追加と混同する誤りの3つです。以下の練習問題で本記事の理解度を確認してみましょう。

まとめ：システム開発技術は暗記量が少ない確実な得点源

午前1のシステム開発技術は、計算がほとんどなく、覚えるべき対応関係が明確な分野です。押さえるべき型は4つに集約されます。凝集度と結合度は「高く・低く」と両端の名称。テスト技法は「内部を見るか、仕様だけを見るか」。テスト工程はV字モデルの左右対応と、スタブ・ドライバの方向。開発手法は特徴を一言で言える状態。この4つを持って選択肢に向かえば、初見の言い回しでも消去法が効きます。

インフラエンジニアとして設定作業に携わり、その後は事業会社側でIT統制に関わってきた立場から見ると、この分野の用語はどれも「後で困らないための約束事」です。凝集度と結合度は変更の影響範囲を閉じ込めるための約束、レビューは手戻りコストを前倒しで潰すための約束、V字モデルは何を根拠に何を検証するかの約束。新卒エンジニアに教えていた頃も、用語の暗記より「なぜその決まりがあるのか」を先に伝えたほうが、結果的に定着が早いと感じていました。

これでテクノロジ系の第1部は完了です。基礎理論、コンピュータ構成要素、システム構成要素、ソフトウェアとハードウェア、ネットワーク、データベース、そしてシステム開発技術。午前1のテクノロジ系で問われる主要分野を一通り押さえたことになります。次回からは第2部としてマネジメント系に入り、プロジェクトマネジメント、サービスマネジメント、システム監査を扱います。テクノロジ系より暗記中心で、さらに短時間で仕上がる分野です。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• IPA 情報処理技術者試験・情報処理安全確保支援士試験 出題範囲・シラバス（一部改訂について）
• IPA 情報処理技術者試験 過去問題
• IPA SEC BOOKS：共通フレーム2013
• アジャイルソフトウェア開発宣言
• IPA 「情報処理安全確保支援士試験（レベル4）」シラバス（Ver.2.1）