【26/5学習メモ】基本情報科目A　システム開発技術の正答率56.1%でやばい

💡 この記事について
私の科目Aシステム開発技術分野の全体正答率56.1%で課題です。
この分野で特に重要な概念（ホワイトボックステスト、UML、モジュール設計等）について、実装経験と結びつけた詳細解説を整理します。

📋 目次

5月の学習全体像
学習実績と課題分析
システム開発技術分野の詳細解説
計算問題パターン

学習実績と課題分析

強化必須分野：7分野が60%未満

下表は、特に学習強化が必要な分野です。本記事では🔴システム開発技術（正答率56.1%）に焦点を当てます。

領域	正答率	主要学習内容
🔴 システム開発技術	56.1%	V字モデル、テスト手法、UML、設計品質、アジャイル
🔴 ソフトウェア	55.6%	マルチタスク、メモリ管理、ファイルシステム、仮想メモリ
🔴 ネットワーク	46.4%	TCP/IP層構造、DNS、ルーティング、セキュリティプロトコル
🟠 システム企画	56.2%	IS計画、業務分析、要件定義、RFP
🟠 コンピュータ構成要素	58.6%	CPU・メモリ・キャッシュ、バス幅、クロック周波数
🟠 ハードウェア	58.8%	ストレージ、入出力装置、電源管理
🟠 プロジェクトマネジメント	59.3%	スコープ・スケジュール・リスク管理

システム開発技術分野の詳細解説

システム開発技術（56.1%）を逆転させるために、各項目の本質的な理解を整理しました。

テスト技法の体系化

テスト手法は大きく「どこまでテストするか」と「何をテストするか」の2つの軸で分類されます。

回帰テストの本質

定義：保守作業やバグ修正によってシステムに変更を加えた場合、以前まで正常に機能していた部分に不具合や影響が出ないか検証するテスト

エラー埋め込み法（Seeding）

定義：意図的にテストプログラムにエラーを埋め込み、テストケースの検出能力を評価する手法

以下の関係式：

埋込エラー発見率 ÷ 真のエラー発見率 = 埋込エラー総数 ÷ 発見された埋込エラー数

この式から、テストの有効性を定量評価できます。

直感的な理解：

埋め込んだエラーを 100個 設置
テストで見つかった埋め込みエラー：80個
テストが見つけた真のエラー（発見済み）：5個

→ テストの検出能力は「埋め込みエラーの80%を発見できるなら、真のエラーの大部分も発見できる」という信頼度が生まれます

ホワイトボックステストの詳細

ホワイトボックステストは「プログラムの内部構造を白い箱として見て、すべての経路をテストする」手法です。

① 命令網羅（Statement Coverage）

定義：プログラムの全ての命令を少なくとも1回は実行するテストケースを設計する方法

条件分岐がある場合：

if (x > 10) {
    y = x * 2;        ← ここを最低1回実行
} else {
    y = x / 2;        ← ここも最低1回実行
}

特徴：

✅ テストケースが少なくて済む
❌ 最も網羅性が低い（分岐を両方実行しないかもしれない）
❌ 条件分岐の細かい値には対応しない

② 判定条件網羅（Branch Coverage）

定義：全ての分岐について分岐先の全ての経路を最低1回は実行する設計方法

if (x > 10 && y < 5) {
    process_A();      ← 条件が真のとき
} else {
    process_B();      ← 条件が偽のとき
}

テストケース：

Case 1: x=15, y=3 → 両条件真 → process_A() 実行 ✓
Case 2: x=5, y=8 → 両条件偽 → process_B() 実行 ✓

重要な性質：

判定条件網羅を満たせば、必ず命令網羅も満たされる

命令網羅 ⊂ 判定条件網羅  （判定条件網羅の方が上位）

ソフトウェア品質メトリクス

テスト効果の定量評価

テスト効果率 = テストで検出したエラー数 ÷ (テストで検出したエラー数 + 運用で発見されたエラー数)

例：
テストで100個検出、運用で5個発見 → 100 ÷ 105 ≈ 95%
テストが十分に機能している状態

オブジェクト指向設計

汎化と特化の関係（Generalization-Specialization）

汎化-特化関係：クラス間の上下関係を示す

基底クラス
    ↑
    │（継承）
    ↓
派生クラス

例：
[動物]（基底）
  ↑
  ├─ [犬]（派生）
  ├─ [猫]（派生）
  └─ [鳥]（派生）

→ 「下位クラス（犬）は上位クラス（動物）である」という関係

集約-分解関係（Aggregation-Composition）

集約：弱い結合
[Company] --○-- [Employee]  ← 社員は会社から独立して存在可能

合成：強い結合
[House] --◆-- [Room]  ← 部屋は家から独立して存在できない

UML の実装との関連づけ

UML(Unified Modeling Language)　：オブジェクト指向設計を図で表現するための標準的な記号・ルールのセット

ユースケース図

目的：システムに要求される機能を利用者の視点から記述

                    [システム境界]
         ┌─────────────────────────┐
         │  共有家管理システム      │
         │  (WorkProduct-LaravelCRUD) │
         └─────────────────────────┘
                    △
        ┌───────────┼────────────┐
        │           │            │
    [居住者追加]  [物件検索]  [予約管理]
        △           △            △
        │           │            │
      [管理者]  [一般ユーザー]  [オーナー]

実装経験との結びつけ
Laravelのルートやコントローラーがユースケース図に対応：

// routes/web.php
Route::get('/properties', [PropertyController::class, 'search']);    // [物件検索]
Route::post('/residents', [ResidentController::class, 'store']);     // [居住者追加]
Route::patch('/bookings/{id}', [BookingController::class, 'update']); // [予約管理]

シーケンス図

目的：オブジェクト間のメッセージ交換を時系列に表す

時刻 →

[クライアント]    [Laravelサーバー]    [データベース]
      │                 │                  │
      │ HTTPリクエスト    │                  │
      ├────────────────>│                  │
      │                 │ SQLクエリ送信     │
      │                 ├────────────────>│
      │                 │ クエリ結果      │
      │                 │<────────────────┤
      │ HTTPレスポンス    │                  │
      │<────────────────┤                  │
      │                 │                  │

アクティビティ図

目的：ビジネスプロセスの流れや制御フローなど手続きを可視化

      [開始]
        │
        ↓
   [ユーザー入力]
        │
        ↓
   [バリデーション] ──偽──> [エラー表示]
        │真                    │
        ↓                     ↓
   [DB保存]◄─────────────────┘
        │
        ↓
   [確認メール送信]
        │
        ↓
      [終了]

状態遷移図

目的：時間経過や事象の発生に応じて状態が変わるシステムを表現

[予約申込待ち] 
    │
    │(申込)
    ↓
[確認待ち] ◄────────────(キャンセル)
    │
    │(承認)
    ↓
[予約確定]
    │
    │(チェックイン当日)
    ↓
[入居中]
    │
    │(チェックアウト)
    ↓
[終了]

コンポーネント図

目的：システムの構成要素（コンポーネント）の依存関係を表現

┌─────────────┐     ┌──────────────┐     ┌──────────┐
│  UIコンポ    │────>│  Controllerコンポ │────>│  DBコンポ │
│ (Blade)     │     │  (Laravel)   │     │(MySQL)  │
└─────────────┘     └──────────────┘     └──────────┘

モジュール設計と結合度

モジュール結合度（Coupling）

定義：モジュール同士の関連性の強さを示す概念

結合度が低い（良い設計）
┌─────┐    ┌─────┐
│ A   │────│ B   │  → 必要最小限のデータだけやり取り
└─────┘    └─────┘

結合度が高い（悪い設計）
┌─────────────────────┐
│  A とB が複雑に     │
│  絡み合っている     │
└─────────────────────┘

結合度の強さ順序：

① 内容結合度（最悪）
   あるモジュールが別モジュールの内部変数を直接参照・変更

② 共通結合度（悪い）
   複数モジュールが共通のグローバル変数を使用

③ 外部結合度
   モジュール間で外部変数を使用

④ 制御結合度（中程度）
   ある関数が別の関数に「どうしろ」と制御情報を渡す

⑤ スタンプ結合度
   モジュール間で構造体の一部だけをやり取り

⑥ データ結合度（最良）
   パラメータと戻り値だけでやり取り
   └─ これを目指す！

実装経験との結びつけ
LaravelのDependency Injection（DI）は「データ結合度」を実現：

// 悪い例（高い結合度）
class UserController {
    public function store(Request $request) {
        global $database;  // グローバル変数に依存
        $database->insert(...);
    }
}

// 良い例（低い結合度）
class UserController {
    private $userRepository;

    public function __construct(UserRepository $userRepository) {
        $this->userRepository = $userRepository;  // 注入される
    }

    public function store(Request $request) {
        $this->userRepository->create($request->all());
    }
}

モジュール凝集度（Cohesion）

定義：モジュール内の要素がどれだけ関連しているか

凝集度が高い（良い設計）
┌──────────────────┐
│ Userコントローラ │
│ - 作成()         │
│ - 更新()         │ ← すべてユーザー関連
│ - 削除()         │
│ - 検証()         │
└──────────────────┘

凝集度が低い（悪い設計）
┌──────────────────┐
│ MixedController  │
│ - ユーザー作成() │
│ - メール送信()   │ ← 関連性薄い
│ - ログ出力()     │
│ - 支払い処理()   │
└──────────────────┘

目指すべき形：

✅ 高い凝集度 （関連する機能を1つのモジュールに）
✅ 低い結合度 （モジュール間の依存を最小化）

計算問題パターン

システム開発技術での計算問題は以下の2パターンが頻出です。

パターン1：テスト段階での不具合率から本番運用時の推定

問題例：

テスト段階で発見されたバグ：25個
運用開始後1ヶ月で発見されたバグ：2個

テストの効果率（完全性）は？

解き方：

テスト効果率 = テストで発見したエラー数 ÷ 
              (テストで発見したエラー数 + 運用で発見されたエラー数)

= 25 ÷ (25 + 2)
= 25 ÷ 27
≈ 92.6%

→ テストが92.6%のバグを検出できている
  まだ0.4%のバグが未検出の可能性

パターン2：エラー埋め込み法の検出率計算

問題例：

テストプログラムに意図的に50個のエラーを埋め込んだ。
テスト実行後、埋め込まれたエラーのうち40個が発見された。
この同じテストで実際に発見された真のバグは10個。

真のバグの検出率は推定いくつか？

解き方：

埋込エラーの検出率 = 40 ÷ 50 = 80%

エラー埋め込み法の基本仮説：
「テストが埋め込みエラーの80%を検出できるなら、
 同じ確率で真のエラーも検出できる」

したがって、発見された真のバグ（10個）が全体の80%だとすると：
全体のバグ数 = 10 ÷ 0.8 = 12.5個 ≈ 13個

→ 推定で約13個のバグが存在し、10個は検出済み、
  3個程度はまだ未検出の可能性

まとめ

システム開発技術の56.1%を逆転させるためのポイント：

項目	学習ポイント
テスト手法	命令網羅 ⊂ 判定条件網羅の包含関係を理解
UML	6つの主要図を「何を見るか」で使い分ける
オブジェクト指向	汎化-特化、集約-分解の関係を図で描画できる
モジュール設計	「低結合・高凝集」を常に意識
計算問題	テスト効果率とエラー埋め込み法の2パターン必出

実装を通じて、設計原則を体験的に理解することが、試験突破と実務の両方に繋がります。