- 問 3〜問 8 の 6 分野が、小問数・解答形式・計算の量でどう違うか
- 10 年分の題材から見た、分野ごとの「出る場面」と繰り返す論点
- 分野ごとの読む順序・書く順序と、1 問 25〜30 分の内訳
- 採点講評が名指しした失点型と、その場で潰すチェック項目
- 単位換算・消去法・トレース表・図の読み取りという分野横断の技
科目 B は 11 問出題・5 問解答で、問 1 の情報セキュリティが必須、問 2〜問 11 から 4 問を選びます。本章が扱うテクノロジ系 6 分野は問 3〜問 8 に固定されており、直近 10 年(19 回)で 1 度も入れ替わっていません。配置が動かないので、どの 4 問を仕込むかは学習開始時に決められます。各問 20 点、基準点は 100 点満点中 60 点です。
6 分野の性格を数字で比べる
科目 B の選択問題は「どれを選ぶか」で得点が決まります。分野の好き嫌いではなく、解答形式の内訳(穴埋め・用語記述・字数記述・記号選択・計算)で選ぶのが確実です。19 回分の小問を形式ごとに数えた実数を見ると、6 分野は 2 つの軸できれいに分かれます。書く量(字数記述の比率)と、計算の量です。
| 問 | 分野 | 小問数(19 回計/1 問平均) | 解答形式の内訳 | 字数記述の上限 | 計算の量 | 知識の土台 |
|---|---|---|---|---|---|---|
| 3 | プログラミング | 85/4.5(最少) | 穴埋め 58%・計算 20%・記号 7% | 30 字(19 回で 5 設問のみ) | 約 17 小設問 | 第 3 章 |
| 4 | システムアーキテクチャ | 123/6.5 | 字数 28%・記号 24%・計算 23%・用語 20%・穴埋め 5% | 40 字 | 28 小設問(19 問中 14 問) | 第 5 章 |
| 5 | ネットワーク | 117/6.2 | 用語 41%・字数 28%・記号 21%・穴埋め 9%・計算 6% | 40 字 | 7 小設問 | 第 10 章 |
| 6 | データベース | 98/5.2(最少タイ) | 穴埋め 53.1%・用語 25.5%・字数 15.3%・記号 6.1% | 40 字 | 集計に記載なし | 第 9 章 |
| 7 | 組込みシステム開発 | 119/6.3 | 用語 24.2%・計算 22.5%・字数 20.8%・穴埋め 18.3%・記号 14.2% | 40 字 | 27 小設問(ゼロは 2 回だけ) | 第 7 章 |
| 8 | 情報システム開発 | 114/6.0 | 字数 33%・記号 28%・用語 25%・穴埋め 12%・計算 7% | 40 字 | 8 小設問(直近 4 回はゼロ) | 第 13・14 章 |
この表から読める設計方針は 3 つです。第 1 に、問 3 と問 6 は「短く正しく埋める」試験で、書く総量が最も小さくなります。第 2 に、問 4 と問 7 は計算が主役で、単位換算を型で持っていないと 1 問で 3 つ落とします。第 3 に、問 5 と問 8 は用語と短文の量産で、図表から字句を拾う速さが得点になります。
| 問 | 分野 | 講評の全体正答率(19 回の内訳) | 選ぶ理由 | 捨てる理由 |
|---|---|---|---|---|
| 3 | プログラミング | 高 9・やや高 1・平均 7・やや低 1・記載なし 1 | 正答率が最も高く、作文が要らない | 添字を取り違えると連鎖して全滅する |
| 4 | システムアーキテクチャ | 平均 12・低 2・高 1・記載なし 4 | 用語知識で確実に取れる設問が多い | 1 問に計算が 3〜5 個並ぶ回がある |
| 5 | ネットワーク | 高 3・やや高 2・平均 7・やや低 1・低 1・記載なし 5 | 用語と穴埋めで半分(58/117)を稼げる | 構成図とルール表の往復が遅いと時間切れ |
| 6 | データベース | 低 5・やや低 2・平均 7・高 2・記載なし 3 | 穴埋めと用語で 78.6%、長文論述がない | 「低」が 6 分野で最多。SQL を書けないと崩れる |
| 7 | 組込みシステム開発 | 高 4(H28秋・H29秋・H30秋・R4秋)・低 1(R6秋) | 計算の型 5 つで実務経験なしでも取れる | 記述系が 63.3% で消去法が効かない |
| 8 | 情報システム開発 | 平均 10・高 4・やや低 2・低 3 | 直近 10 回はすべて「平均」で安定 | 字数記述が 19 問中 18 問。書く量が多い |
正答率の内訳まで見ると、問 3 は 19 回中 10 回が「平均より上」で最も安定し、問 6 は「低」5 回・「やや低」2 回で最も荒れています。「SQL は読めるから問 6」という選び方が危険なのは、構文を書かせる試験だからです。
当日 5 分で 4 問を決める
選択に使ってよいのは冒頭の 5 分だけです。本文を読み始めると引き返せなくなるので、図の種類・設問形式の内訳・計算の個数の 3 点だけを見て機械的に決めます。分岐の入口は「擬似言語を追えるか」です。ここが分かれ目になるのは、問 3 が 19 問中 18 問まで純粋なアルゴリズム題材で、本文からの推測が一切効かないためです。
5〜6 分野を仕込み、当日 1〜2 分野を捨てるのが安全です。予備をゼロにすると、その 1 問が例年になく重かったときに逃げ場がなくなります。
問 3 プログラミング ― 擬似言語を書き下す
直近 19 回とも問 3 に置かれ、19 問中 18 問が純粋なアルゴリズム題材です(業務の場面が出たのは H31春の券売機だけ)。本文から常識で推測する戦法が効かない代わりに、講評の全体正答率は「高」9 回・「やや高」1 回と 6 分野で最も良好です。当たれば満点、添字を取り違えれば全滅という、分散の大きい分野です。
| 回 | 題材 | 主要論点 |
|---|---|---|
| H28秋 | 魔方陣アルゴリズム | 2 次元配列の添字/番兵値/while と for の条件 |
| H28春 | ライフゲームの実装 | 盤面の 1 次元配列表現/境界の例外処理/テスト関数 |
| H29秋 | ナップザック問題 | 動的計画法/2 次元表による解の構築/計算量オーダ |
| H29春 | 木構造の探索 | キューとスタックの探索順序/枝刈り/事前ソート |
| H30秋 | ウェーブレット木の構築 | ビット列生成/シフトと論理積/計算量オーダ |
| H30春 | ナイトの巡歴問題 | 再帰による深さ優先探索/移動量配列/外周パディング |
| H31春 | 券売機の値引き判定 | 状態遷移図と遷移表/構造体配列/表変更での対応可否 |
| R1秋 | パーセプトロン | 線形と非線形の分類/演算式からプログラムへの変換 |
| R210月 | 誤差拡散法の減色処理 | 誤差の拡散計算/走査方向の反転/実行回数の見積り |
| R3秋 | 有向グラフの一筆書き | 隣接リスト/深さ優先探索/境界値 |
| R3春 | k-means 法のクラスタ分析 | 距離計算と重心再計算の反復/初期コアの選択 |
| R4秋 | 迷路探索の再帰関数 | 再帰とバックトラック/スタックによる経路管理 |
| R4春 | パズル解法の深さ優先探索 | 1 次元配列の盤面と div・mod/データ構造の選定 |
| R5秋 | AVL 木の回転操作 | 2 分探索木の探索・挿入/平衡条件と左右回転/O 記法 |
| R5春 | 多倍長整数の演算 | カラツバ法/1 の位から格納する配列/層別の添字 |
| R6秋 | エラトステネスの篩 | オーダ記法/配列と実データの対応/実行回数の比較 |
| R6春 | ダイクストラ法 | 更新起点ノード/確定済み配列/直前ノードで経路を逆順出力 |
| R7秋 | 最長共通部分列の動的計画法 | 再帰的な場合分け/表の更新式/計算量 |
| R7春 | スライドパズルの探索 | 幅優先探索/キューによる探索管理/盤面の配列表現 |
題材の型は 5 つに割れます。盤面・パズル系の探索とバックトラックが 7 問(37%)、グラフと木が 4 問、動的計画法が 2 問、数値・整数・信号処理が 3 問、データ分析と業務モデルが 3 問です。探索系とグラフ・木で 11 問(58%)を占めるので、選ぶなら深さ優先探索・幅優先探索・バックトラックの骨格を最優先で仕上げます。動的計画法は 2 問と少ないものの、直近の R7秋で再登場した第 3 の軸です。
設問の型。設問番号ベースで合計 69(平均 3.6)、枝番まで展開すると 85(平均 4.5、範囲 2〜6)です。内訳は穴埋めが約 49 小設問(約 58%)で主戦場、計算が約 17(約 20%)、記号選択が 6(約 7%)、用語・字句記述が 4(約 5%)。字数記述は 19 回でわずか 5 設問(約 6%)しかなく、40 字以上は 10 年で 1 問もありません。作文力ではなく、擬似言語を正確に書き下す力とトレース精度だけで決まります。
前提知識は第 3 章です。擬似言語の記法(宣言・「←」による代入・for と while・要素番号の起点・構造体のメンバアクセス・div と mod)、配列によるデータ構造の写し取り、探索アルゴリズムの骨格、計算量の数え方を先に固めてください。答案も擬似言語で書くので、記法の正確さがそのまま得点になります。
解き方の手順
- 設問だけを先に見る(2 分)。空欄の個数と、それがどの図・どの行に属するかを把握する
- 「実データ ↔ 配列」の対応表を余白に作る(6 分)。「配列の k 番目が何を表すか」を 1 行で書く。これができないまま進むと後半が総崩れになる
- 図表の小さな具体例で 1 周トレースする(6 分)。設問 1 はたいていこれ自体なので、検算と得点を兼ねる
- 空欄は前後 2〜3 行だけ見て埋める(12 分)。「この行が何を確定させるか」を決めてから書く。代入の空欄は必ず「←」を含む完全な文にする
- 検算 4 分。境界値に具体値を代入し、更新式が「元の値に足す形」になっているかを確認する
トレースは頭の中でやらず、必ず表にします。列は「変化する変数」だけにし、行を 1 反復ずつ増やします。図 24-3 は 2 分探索を 7 要素の配列(1 始まり)で追った表です。
○整数型: binarySearch(整数型の配列: a, 整数型: x)
整数型: low ← 1
整数型: high ← a の要素数
整数型: mid
while (low ≦ high)
mid ← (low + high) div 2
if (a[mid] が x と等しい)
return mid
elseif (a[mid] が x より小さい)
low ← mid + 1
else
high ← mid - 1
endif
endwhile
return -1
採点講評から見た失点と対策
| 失点の型 | 講評が指摘した実例 | 対策 |
|---|---|---|
| 机上での再現不足(最頻) | R5秋 設問 2(2)、R6春 設問 2、R210月 設問 1(2) | 値の変化を必ず紙の表に落とす |
| 再帰の「戻り」を追えない | R4秋 設問 4(1)(2)。呼出し元へ戻った後の引数を再現できない | コールスタックを縦に描き、各段に「戻るとき何を元に戻すか」を書く |
| 境界値を詰めない | R3秋 設問 4(等しい場合を含めない誤り)、H28秋 設問 2(1) | 「未満か以下か」「0 始まりか 1 始まりか」を先に紙へ書く |
| 配列と実データの対応を取り違える | R6秋 設問 3、R7秋 設問 3、R5春 設問 3 | 対応表を作ってから空欄に入る |
| 式の一部だけ書き、加算や向きを落とす | R210月 設問 2(元の値への加算漏れ)、R6春 設問 2(距離を加えず始点距離だけ/判定が逆) | 更新式は「元の値 + 増分」の形かを最後に確認する |
| データ構造の役割理解と表記の不正確さ | H28春 設問 3・設問 5(スペルミス・閉じ括弧)、H29春 設問 3(スタック) | 宣言部のコメントから語をそのまま借りる |
選択の判断基準。擬似言語をコードとして読み下せる人、机上トレースを苦にしない人に向きます。逆に、文章から推論して部分点を拾う戦い方はできません。撤退ラインは明快で、着手 10 分で「実データ ↔ 配列」の対応表が書けなければ他の問題に移ります。問 3 を選ぶ人は、必須の問 1 の直後に問 3 を置いてください。終盤に始めると撤退の判断そのものが遅れます。
問 4 システムアーキテクチャ ― 条件表から設計を計算する
19 回とも問 4 に固定です。性格は「構成図と条件表を読み、四則演算と短文で設計判断を答える」。計算を含む問題は 19 問中 14 問(含まないのは H29秋・H30春・H31春・R4秋・R5秋)で、1 問に計算が 3〜5 個並ぶ回もあります。字数記述は 1 問平均 1.8 設問と軽く、記述が苦手でも計算と選択で稼げるのが選ぶ最大の理由です。
| 回 | 題材 | 主要論点 |
|---|---|---|
| H28秋 | クラウドでの災害復旧対策 | RTO・RPO/DNS の TTL/切替手順のクリティカルパス |
| H28春 | 業務ネットワークの更新 | 直列・並列の稼働率式/CPU とスループット/リンクアグリゲーション |
| H29秋 | Web API の設計 | REST の URI とメソッド/HTTPS 必須化/ステータスコード |
| H29春 | 会計事務所の仮想化基盤 | 仮想化機能名/リソースプール使用率/冗長化と負荷平均化 |
| H30秋 | POS データの並列分散処理 | 分散ファイルシステム/単一障害点/ディスク I/O のボトルネック/台数計算 |
| H30春 | 保険代理店のクラウド移行 | SaaS・PaaS・IaaS と責任範囲/要件と形態の対応/仕様変更と再選定 |
| H31春 | 電子書籍システムの構成見直し | フロントとバックの AP 分離/稼働率/KVS の分散配置/バッチ分離 |
| R1秋 | ホームセキュリティの実証実験 | 映像圧縮/帯域と容量の計算/機能配置 3 方式の比較/既存システムへの影響 |
| R210月 | ヘルスケア機器のクラウド連携 | 非機能要件/稼働率とデータ量の計算/方式の評価軸/データ消失対策 |
| R3秋 | クラウドストレージへの移行設計 | 頻度別のストレージ容量/料金体系/VPN 帯域と転送時間/段階的移行 |
| R3春 | IoT 駐車場管理システム | LPWA/送信データ量と速度/料金プラン/保存領域/MQTTS |
| R4秋 | コンテナ型仮想化技術 | コンテナ型とサーバ型の違い/イメージのバージョン管理/起動オプション |
| R4春 | クラウドを活用した名刺管理 | PaaS と FaaS の性質/運用責任/CDN/台数と料金の試算/実行時間上限の回避 |
| R5秋 | 家具メーカーの合併システム統合 | 存続と廃止の判断/連携インタフェース新設/マスタコード統一 |
| R5春 | IT ニュース配信の再構築 | SPA/API 別の応答時間試算/キャッシュサーバ/CPU 使用率でのスケールアウト |
| R6秋 | 動画配信のデータ処理配置 | 整数と浮動小数点/回線速度からの所要時間/CPU と GPU/拡張性 |
| R6春 | CRM のフロントエンド分離改修 | 静的ファイル最適化/JSON/UI とデータ処理の分離/MIPS 計算 |
| R7秋 | サッカー動画配信のエッジ設計 | RISC/解像度と fps からの帯域計算/ハードウェア圧縮/消費電力/エッジ分担 |
| R7春 | BEMS のクラウド移行 | 非機能要件/アクティブ-スタンバイ/ライブマイグレーション/SLA の稼働率と減額 |
題材の重心は動いています。クラウド移行・利用形態の選定が 6 問、IoT・エッジ・動画が 5 問、Web システムの構成と性能改善が 4 問、仮想化・分散処理基盤が 3 問、純粋なオンプレ性能評価は H28春の 1 問だけです。R1秋以降の 11 問は IoT 系 5 問とクラウド系 4 問で 8 割強を占めます。場面はほぼ毎回「中堅企業の情報システム部門が新サービスや移行を検討する」形です。
設問の型。小設問は合計 123、1 問平均 6.5(最頻値 7 が 11 問、最小 4、最大 8)。内訳は字数記述 35(28%)、記号選択 29(24%)、計算 28(23%)、用語記述 25(20%)、穴埋め 6(5%)です。解答欄 39 本の字数は 30 字が 11・40 字が 8・20 字が 7・35 字が 6・15 字が 5 で、50 字以上は 1 つもありません。15〜20 字なら名詞句、30〜40 字なら「〜だから」「〜する」の一文で足ります。計算 28 個の型は、帯域・転送・所要時間が 8、稼働率が 4、使用率と台数が 4、容量が 4、応答時間が 2 です。
前提知識は第 5 章です。稼働率の直列・並列、クラウドの形態と責任分界、仮想化 3 方式とライブマイグレーション、性能改善の手段(スケールアウト/アップ・キャッシュ・データ配置変更・バッチ分離)、非機能要件の分類と RTO・RPO を押さえてください。
計算の型: 稼働率の合成と SLA の許容停止時間
直列(どちらか止まると全体が止まる) = α × β / 並列(片方生きていれば動く) = 1 - (1 - α) × (1 - β)
- 構成図を「直列の鎖」と「並列の束」に分解する。束は先に 1 つの値へ潰す
- 例題: 稼働率 0.9 の AP サーバ 2 台を並列にし、その後段に稼働率 0.99 の DB を直列で置く
- 並列部分 = 1 - (1 - 0.9)2 = 1 - 0.01 = 0.99
- 全体 = 0.99 × 0.99 = 0.9801(約 98.0%)
- SLA 側へ落とす: 30 日の月は 30 × 24 × 60 = 43,200 分。SLA 99.5% なら許容停止は 43,200 × 0.005 = 216 分
- 検算: α に 0 と 1 を入れて、全体が 0 と 1 になるかを確かめる
解き方の手順
- 設問を先に全部読む(4 分)。計算は「求める量(速度・容量・時間)と単位」に丸を付ける
- 構成図に矢印と役割を書き込む。機器・端末・回線を列挙し、DNS・ロードバランサ・キャッシュの役割を 1 語でメモする
- 本文の数値と制約に下線(6 分)。件数・周期・サイズ・速度・単価・稼働率と、「〜できない」「上限 10 分」の制約を拾う。表は単位を確認してから読む
- 計算は「式 → 単位 → 検算」。台数は「合計 ÷ 1 台分」を切り上げ、容量は「日量 × 保存日数」。検算では加算対象が 2 系統ないか(PC 分とサーバ分、収集とアクセス)を必ず疑う
- 「全て選べ」型は各肢に ○ × を付ける。本文の条件で × の理由を言える肢だけを消す
- 字数記述はテンプレートで書く。理由型は「〔本文の条件〕なので、〔帰結〕だから」、対策型は「〔対象〕を〔どこで〕〔動作〕する」。本文の固有名詞か数値を必ず 1 つ入れ、境界値は「20 分未満」のように明示する
採点講評から見た失点と対策
| 失点の型 | 講評が指摘した実例 | 対策 |
|---|---|---|
| 本文・表の条件を拾い切れず計算が欠ける | R3秋 設問 1(PC 分の欠落)、R3春 設問 3(1)(収集とアクセスの両方)、R5春 設問 2 | 足す対象を列挙してから式を立てる |
| 設問が問う対象・量を読み違える | H28春 設問 4(L2 スイッチの性能要件を問われて無関係な解答)、R3春 設問 4(1)(データ量を問われて速度を答える) | 設問の名詞(量・速度・機器名・理由)に丸を付ける |
| 構成図の各要素の役割を把握せず答える | H28秋 設問 2、H30秋 設問 1(2)、H31春 設問 1(1) | 図に役割を書き込んでから本文に入る |
| 技術用語・分類の混同 | R5秋 設問 3(SaaS を PaaS・IaaS と混同)、R4秋 設問 1(2)(仮想化 3 方式) | 責任分界の層で覚え、名前だけで覚えない |
| 抽象的で具体性が欠ける記述 | R210月 設問 3(用語だけの解答)、H30春 設問 4(2)(仕様変更と形態を関連付けよ) | 本文の固有条件を 1 つ埋め込む |
| 境界値・検算の詰めが甘い | R4春 設問 4(2)(実行間隔の境界値)、H28春 設問 1(2)(極端値で検算せよ) | 0 と 1、上限ちょうどの値を代入する |
| 業務・運用の視点が欠落 | R1秋 設問 3(既存システムへの影響)、R6秋 設問 3(2)(どの業務で使うか)、R3秋 設問 2(2)(移行リハーサル) | 本文に「業務時間・営業日・将来の追加」があれば、それが解答の核 |
| 「増強」以外の手段が出てこない | R6秋 設問 2(4)(配置変更やキャッシュ)、R7秋 設問 4(2)(不要情報の除去) | 改善策のカタログを事前に持つ |
正答率が高いと明記されたのは RTO・RPO、REST、仮想化機能名、要件と形態の組合せ、方式選定です。用語知識は取れており、失点は「本文との突き合わせ」と「一歩踏み込んだ説明」に集中しています。
選択の判断基準。インフラ・クラウドの実務感覚があり、単位換算を落ち着いて処理できる人に向きます。問 5・問 6 ほどの専門知識は不要です。逆に、計算を避けたい人や用語暗記だけで通したい人は避けてください(コンテナ・FaaS・LPWA・SPA・GPU・エッジと、毎回新しい技術が題材になります)。当日は計算の個数を数え、3 個を超える回は他の候補と比べてから決めます。
問 5 ネットワーク ― 構成図の上でパケットをなぞる
19 回とも問 5 に固定です。用語記述 48 と穴埋め 10 を合わせた 58 小問(50%)が「図と本文に答えがある」形式で、知識で確実に稼げます。講評の全体正答率も「高」3 回・「やや高」2 回・「平均」7 回と安定しており、極端な難問は HTTP/2 を扱った R1秋だけです。
| 回 | 題材 | 主要論点 |
|---|---|---|
| H28秋 | IP 電話の導入と QoS | SIP と RTP/音声帯域計算/ルータの優先制御/拠点内 QoS の要否 |
| H28春 | STP とリンクアグリゲーション | ブロードキャストストーム/タグ VLAN とポート VLAN/VLAN 不一致 |
| H29秋 | SDN によるネットワーク設計 | SDN/MAC 転送制御テーブル/故障時の動的書換え |
| H29春 | L3 スイッチの故障対策 | ping/スタブリゾルバ/OSPF/ICMP リダイレクト/VRRP/経路表 |
| H30秋 | Web 負荷分散の不具合切分け | ロードバランサと VIP/ログ突合せ/TCP ポート枯渇/NTP/送信元 IP の置換 |
| H30春 | Web システム構成変更と DNS | DNS ラウンドロビン/ゾーン転送/レコード種別/VIP/WAF の迂回防止 |
| H31春 | 無線 LAN 導入と VLAN 分離 | チャネル設計/IEEE 802.1X と RADIUS/ダイナミック VLAN/PoE |
| R1秋 | HTTP/2 による性能改善 | ソケット枯渇/複数 TCP コネクション/3 ウェイハンドシェイク |
| R210月 | VDI 導入による通信変化 | VDI/多要素認証と SSL-VPN/DHCP リレー/デフォルトゲートウェイ/帯域見積り |
| R3秋 | LAN のゾーン分割と VLAN 設計 | ACL と CIDR/ケーブル規格/PoE/タグ VLAN とトランク |
| R3春 | 旅行販売システムのチャット機能 | NAPT 環境の IP/HTTP と WebSocket/プロキシの TLS トンネリング/証明書の設置機器 |
| R4秋 | テレワーク環境への移行 | HTTPS と IPsec/証明書とワンタイムパスワード/Web 会議の帯域換算/UTM |
| R4春 | SaaS 通信経路の見直し | プロキシと DNS の役割/FW 許可ルール/IPsec と NAPT/経路表の追加 |
| R5秋 | 広報用メールサーバの構築 | NAPT のポート転送/MX・CNAME・A/POP3/OP25B/ネットワークアドレス |
| R5春 | Web サイトの増設 | DNS ラウンドロビン/ゾーン転送/TTL/デフォルトルート/NAT/メンテナンスの影響 |
| R6秋 | セキュア Web ゲートウェイ | NAPT/送信元 IP 制限/URL レピュテーション/サンドボックス/FW ルール |
| R6春 | IoT 気象情報システムの構築 | MQTT と HTTP/FW 許可ルール/スループットとコネクション数/負荷分散 |
| R7秋 | クラウド環境へのサーバ移行 | DHCP/内部・外部・キャッシュ DNS/オープンリレー防止と OP25B/NAT/経路表 |
| R7春 | 社内 LAN の障害対応 | ARP と IP 重複/サブネット分割/802.1X/DNS 多重化/SNMP トラップ/QoS |
設問の型。小問は合計 117、平均 6.2(最少 4、最多 9)。R3秋以降の 9 回は平均 7.0 で、前半 10 回の 5.4 から増えています。内訳は用語記述 48(41%)、字数記述 33(28%)、記号選択 24(21%)、穴埋め 10(9%)、計算 7(6%)。字数指定 32 本のうち20〜30 字が 21 本(66%)で、「主体 + 固有条件 + 結果」の 3 要素がちょうど収まる長さです。
繰り返し出る論点は明確です。DNS 関連が 9 問で最頻、ポート番号とプロトコル識別が 7 問、NAT・NAPT と中継装置のアドレス変換が 7 問、FW 許可ルールの設計が 6 問、デフォルトゲートウェイと経路表が 6 問と続きます。直近 6 回は「社内のプロキシやサーバを廃止してクラウド・SaaS へ寄せる」場面が定番です(R4春・R6秋・R7秋)。前提知識は第 10 章で、DNS 一式・アドレス変換・FW ルールとポート番号・IP アドレス設計を先に固めます。
解き方の手順
この分野の核心は、構成図の上で 1 本の通信をなぞり、境界ごとに送信元 IP アドレスがどう書き換わるかを追うことです。図 24-4 のように、機器を通るたびに「変わる/変わらない」を確定させます。
- 設問の先読み(3 分)。大設問の見出しと本文の節は 1 対 1 に対応する。解答条件(「図 1 中の機器名で」「全て」「40 字」)に印を付ける
- 構成図を 4 領域に区切る(5 分)。インターネット・DMZ・社内・拠点を線で囲み、機器ごとに L2/L3/FW/プロキシ/DNS/LB の役割を書き込む。アドレス変換を行う機器に星印を付ける
- 本文で 5 種類の情報をマークする(8 分)。具体値(IP・マスク・VLAN 名)/「〜から〜宛ては〜を経由」の経路記述/現状と変更後を分ける語(導入後・移行後・廃止後)/「誰が何を検証するか」/数値(M ビット毎秒・台数・同時利用率)
- 用語記述と穴埋めを 1 周目で確保する。「図中の名称で」は図の表記をそのまま写し、「全て」は候補を列挙して本文で消し込む
- 変更・移行問題は経路を 2 本描く。変更前と変更後を並べ、消える通信・増える通信・IP が変わる箇所を差分で答える
- 記述で詰まったら 3 分で捨てる。用語と記号を先に埋め、残り時間で戻る
採点講評から見た失点と対策
- 類似用語の混同。オープンリレー防止を OP25B で説明する(R7秋 設問 1(2))、MAC 認証と IEEE 802.1X の弁別(R7春 設問 1(4)。講評は両方式の理解を求めています)、TLS 証明書の設置機器をルータやプロキシと誤答(R3春 設問 3(2))
- 基本用語を書けない。PoE、タグ VLAN、nslookup、SNMP トラップ、MQTT、ゾーン。IPA は毎回「覚えておいてほしい」と書いています
- 中継装置でアドレスが変わる/変わらないの読み違え。ロードバランサ通過後の送信元 IP は LB のもの(H30秋 設問 3(2))、IPsec のトンネルでは変わらない(R4春 設問 1(1))
- アドレス設計の基礎が曖昧。端末の IP を書いてネットワークアドレスを外す(R5秋 設問 4)、ACL の CIDR 表記(R3秋 設問 1)、追加すべき経路情報の内容(R4春 設問 3(1))
- 変更後の状態を想像せず現状で答える。LB 導入後の接続先は VIP(H30春 設問 2)、クラウド移行後も業務運用と PC 操作は変わらない(R7秋 設問 2(2))
正答率が高いと明記されたのは帯域計算、MAC 転送制御、TCP/IP 基本の記号選択です。計算と記号は落とさない前提で、記述と用語で差がつきます。
選択の判断基準。社内 LAN やクラウドのネットワークを触った経験があり、構成図上で「このパケットはどこを通るか」をなぞれる人に向きます。IP アドレス計算に抵抗がある人、L3 スイッチ・FW・プロキシの役割がイメージできない人には向きません。当日は読図量(構成図の機器数とルール表の行数)を見て決めます。
問 6 データベース ― E-R 図から SQL へ一本道で進む
19 回とも問 6 に固定で、構成も毎回同じです。①E-R 図 → ②SQL 穴埋め → ③設計判断の記述という三部構成が 10 年間変わっていません。小問は合計 98、1 問平均 5.2 と 6 分野で最少、穴埋め 53.1% と用語記述 25.5% を合わせた 78.6% が「短く正しく書けるか」だけを見る設問です。字数記述 15 問の上限は 40 字で、30 字以下が 10 問。長文論述はありません。
それでも講評の全体正答率は「低」5 回・「やや低」2 回と 6 分野で最も荒れています。理由は単純で、正規形の定義ではなく SQL の構文そのものを書かせるからです。「SQL は読める」という理由で選ぶと失敗します。
| 回 | 題材 | 主要論点 |
|---|---|---|
| H28秋 | ネットショップの会員管理 | 多重度/副問合せ/カーソル |
| H28春 | コンビニの分析用データベース | 外部結合/副問合せ/COALESCE |
| H29秋 | 青果卸売の取引改修 | 代用キー/発生タイミング/派生属性 |
| H29春 | 稟議申請システム | 相関副問合せ/自己結合/履歴保持 |
| H30秋 | 入室管理システム | 多対多の判定/複合主キー/GRANT |
| H30春 | 備品購買システム | エンティティ分割/相関副問合せ |
| H31春 | 薬剤管理システム | 業務と表の対応/UNION と EXISTS |
| R1秋 | 健康応援システム | 埋込み変数/相関 UPDATE/主キー |
| R210月 | 宿泊施設の予約 | NOT EXISTS/HAVING/UNIQUE |
| R3秋 | 企業向け電子書籍 | 埋込み変数/UNION/排他ロック |
| R3春 | カーシェアの経営分析 | スタースキーマ/データマート |
| R4秋 | スマートデバイス管理 | 1 対 1 の見極め/自己参照/DDL |
| R4春 | クーポン発行の排他制御 | UNIQUE と NULL/ALTER TABLE/CRUD |
| R5秋 | 予約注文の引当て改修 | エンティティ追加/BNF/窓関数 |
| R5春 | KPI 達成状況の集計 | 内部結合と外部結合/BETWEEN/COALESCE |
| R6秋 | カードの個人間売買サイト | 交差エンティティ/再帰問合せ/B 木 |
| R6春 | 人事評価 SaaS のテナント統合 | スキーマ分割/同名ビュー |
| R7秋 | 英会話講座の受講管理 | スーパータイプとサブタイプ/CASCADE |
| R7春 | 釣具販売管理システム | 主キーの表記/外部結合/集計粒度 |
題材は小売・EC・販売購買が 6 回、社内業務の管理が 5 回で、この 2 群だけで 11 回を占めます。骨格は「注文―明細―商品―在庫」か「組織―従業員―資産/申請」のどちらかです。分析・データウェアハウス系の 5 回は E-R 図が薄い代わりに集計粒度を問われます。前提知識は第 9 章で、E-R 図の記法、結合と NULL、副問合せ、集計、DDL・DCL の構文、設計原則を押さえてください。
解き方の手順
読む順序が決まっています。①E-R 図と表定義を先に見て主キー・外部キーを把握する(設問 1 の半分はここで解けます)→ ②設問文を全部読んで何を書かされるかを確認する → ③設問が参照する段落だけを読む。SQL 穴埋めの根拠は、直前に置かれた「処理内容」の説明文です。
| 本文の言い回し | 設計・SQL 側で対応するもの |
|---|---|
| 「年月ごとに」「日次で」 | 主キーの構成列・GROUP BY・集計粒度 |
| 「〜が無い場合も」 | 外部結合 + COALESCE |
| 「複数の〜が」 | 多重度(1 対多・多対多) |
| 「変更の可能性がある」 | 代用キー・履歴保持のための属性追加 |
| 「重複を認めない」 | UNIQUE 制約(ALTER TABLE で後付け) |
| 「対応するレコードが無い」 | NOT EXISTS などの相関副問合せ |
SQL 穴埋めは前後の句から絞ります。FROM の後なら表名か結合、GROUP BY の後なら列並び、HAVING の後なら集計関数の条件です。列は必ず別名付きで修飾し、外側の別名を内側が参照していれば相関副問合せと判断します。時間配分は「図表把握と設問先読み 5 分 → 設問 1 に 4 分 → SQL 12 分 → 記述 6 分 → 見直し 3 分」。空欄 1 つに 3 分以上かけず飛ばすのが鉄則です。
採点講評から見た失点と対策
| 失点の型 | 講評が指摘した実例 | 対策 |
|---|---|---|
| E-R 図の向き・記法を機械的に決めていない | H30秋 設問 1(矢印が逆)、R7春 設問 1(実線の下線なし)、R7秋 設問 1(1 対 1 と誤答) | 図 24-5 の 3 手順を必ず踏む |
| 業務要件の「管理の軸」を読み落とす | R4秋 設問 1(「年月ごと」を落として部署 ID だけ)、R3春 設問 4 | 粒度を示す語に下線を引く |
| DDL・DCL の構文を暗記していない | R4秋 設問 3(GRANT と CREATE TABLE を「覚えておく必要がある」と明記)、R4春 設問 1(2) | 制約句・ALTER TABLE・GRANT をテンプレートで覚える |
| 結合・集計の意味を取り違える | R210月 設問 2(HAVING)、R5春 設問 2(2)(外部結合の NULL) | 結果行を数えてから句を選ぶ |
| SQL だけ見て処理内容の説明文を読まない | H28春 設問 2(「販売実績が無い商品を考慮した外部結合」の語が欠落)、R7春 設問 3 | 穴埋めの前に直前の説明文を音読する |
| 抽出条件の要素が 1 つ欠ける | R210月 設問 3(MIN の欠落)、R6秋 設問 2(LIKE のエスケープ) | 条件を箇条書きにしてから 1 行にまとめる |
| 設計原則の知識が無く記述が浅い | H29秋 設問 2(2)(代用キー)、R6秋 設問 1(交差エンティティ)、R3春 設問 2(1)(スタースキーマ) | 原則の名前と「何のために使うか」を対にして覚える |
選択の判断基準。SQL を実際に書いた経験がある人に向きます。記述量が少なく、穴埋めと用語で得点が安定するのが利点です。読んだことしかない人、E-R 図の記法(矢印の向き、実線の下線が主キー)を覚えていない人は避けてください。当日の見極めは「設問 1 の E-R 図の向きが 1 分で読めるか」です。
問 7 組込みシステム開発 ― 時間・容量・状態を突き合わせる
19 回とも問 7 に固定です。勝負どころは組込み固有の知識量ではなく、本文と図表の仕様を読み取り、時間・容量・状態を突き合わせる力です。小問は合計 119、平均 6.3。形式は用語記述 24.2%、計算 22.5%、字数記述 20.8%、穴埋め 18.3%、記号選択 14.2% で、記述系(用語 + 字数 + 穴埋め)が 63.3%。記号選択は 6 小問に 1 問弱しかなく、6 分野で最も消去法が効きません。
| 回 | 題材 | 主要論点 |
|---|---|---|
| H28秋 | 腕時計型脈拍計 | 外乱光除去/輝度補正/最短・最長所要時間 |
| H28春 | タッチ式注文端末 | 初期化時間/タスク優先度/タスク間通知 |
| H29秋 | ドライブレコーダ | 状態遷移/リングバッファ容量/時刻未設定 |
| H29春 | スマートウォッチ | メールボックス/音声データ量/割込みマスク |
| H30秋 | 電子扉システム | 識別コード/イベント駆動/タイマの取消し |
| H30春 | 見守り防犯ブザー | 登録周期の状態遷移/16 ビットタイマ/省電力 |
| H31春 | 浴室給湯システム | 多数決サンプリング/通信時間/状態遷移図 |
| R1秋 | 赤外線リモコンの学習 | バンドパスフィルタ/イベントキュー/桁あふれ |
| R210月 | 多言語多通貨の両替機 | ポーリング/通信速度/状態の解除条件 |
| R3秋 | IoT 養殖システム | 構成要素の設計/動画の容量/しきい値判定 |
| R3春 | ディジタル補聴器 | A/D 変換とバッファサイズ/最適クロック |
| R4秋 | 傘のシェアリング | 確定値判定/カウントダウンタイマ/タスク間通信 |
| R4春 | Wi-Fi 防犯カメラ | 状態遷移図の設計/撮影時間/上書きによる不具合 |
| R5秋 | トマト収穫ロボット | 状態遷移図/タスク間通知/PWM/超音波センサ |
| R5春 | 位置通知タグ | 平均消費電流と使用可能時間/間欠動作 |
| R6秋 | スマートイヤホン | 機能排他/クロック周波数と消費電力/優先度 |
| R6春 | 業務用コーヒーマシン | カップ判定/4 回連続での確定/安全優先の優先度 |
| R7秋 | 猫の自動給餌・健康監視 | 受信率の判定基準/パルス数/上書きによる欠落 |
| R7春 | 電動キックボードのシェア | 状態遷移図/BLE のシーケンス/時間の積算 |
繰り返し出るのは「無人サービス機の貸出/返却サイクル」と「イベント検出前後の記録・通知」で、いずれも複数タスクが並行し、タイマとサーバ通信が絡みます。頻出論点はタスク間通信・通知設計が 10 回で最多、状態遷移図の読解と設計が 9 回、タイマ設定とカウント値計算が 8 回、不具合の発生条件の推論が 6 回と続きます。前提知識は第 7 章で、リアルタイム OS のタスク状態と優先度、状態遷移の記法、タイマとカウンタ、割込みとイベント駆動、センサとアクチュエータ、省電力とバッファ設計を固めます。
字数記述 25 件の内訳は 40 字が 8・20 字が 7 で、この 2 つで 6 割です。40 字は「不具合の発生条件」か「理由」、20 字以下は空欄内の短い条件や現象を書かせます。計算がゼロだったのは H30秋と R6秋の 2 回だけなので、計算を捨てる戦略は取れません。逆に言えば、次の 5 つの型を持てば実務経験がなくても得点源になります。
計算の型: 組込みで出る 5 つ
- タイマのカウント値 = 設定時間 ÷(分周比 ÷ クロック周波数)。16 ビットなら 65,535 以内か検算する
- データ量 = 横 × 縦 × 画素あたりビット数 × フレーム毎秒 × 秒数。台数・チャネル数を掛け忘れない(ステレオを 1 台分で計算した誤答が講評で名指しされました)
- 通信時間 = (1 ÷ ビットレート) × (データビット + スタート・ストップビット) × バイト数
- 最短・最長所要時間。最短は最少経路、最長は最悪経路 + 待ち時間を別立てで足す
- 平均消費電流 = Σ(電流 × 時間) ÷ 周期。使用可能時間 = 電池容量 ÷ 平均消費電流
例題: 分周比 64、クロック 8 M ヘルツのタイマで 200 ミリ秒を計るときのカウント値は、8,000,000 ÷ 64 = 125,000 回毎秒、125,000 × 0.2 = 25,000。16 ビットの上限 65,535 以内なので設定できます。
解き方の手順
- 最初の 3 分で設問だけを全部読む。何を答えるか(数値/字句/条件/理由)を把握する
- 次の 8 分で本文と図表を 1 往復し、5 種類をマークする。数値と単位/タスク名・状態名・イベント名・メッセージ名(定義語は解答でそのまま使う)/「〜のとき」「〜中は」「〜を除く」の条件句/時間の起点と終点/構成図の矢印の向き
- 残り 15 分で計算 → 穴埋め・記号 → 字数記述の順に解く
- 最後の 2 分で単位・指定桁数・字数超過・本文の用語を使ったかを見直す
採点講評から見た失点と対策
- 並行性・タイミングの想像力不足(最大の壁)。H30秋 設問 3 は「施錠処理中に扉を開け、規定時間が経過した」場合を、H28春 設問 3 は「初期化中は OS もタスクも動かない」ことを問いました。処理中に別の事象が割り込む絵を必ず描きます
- 問題文をそのままコピーする。H28秋 設問 3、R3春 設問 3(2)(式をそのまま書いた解答)。説明になっているかを読み返します
- 問う対象・視点を取り違える。H30春 設問 3(2) はメインタスク自身ではなくタイマタスクへの要求内容を、H31春 設問 3(1) は遷移条件であって処理内容ではないものを問いました
- 単位換算・桁数・ビット幅のミス。H30春 設問 2(1) は 16 ビットの上限超過。講評が繰り返し名指しする失点源です
- 計算の前提条件を一部しか使わない。R3秋 設問 2(1)(ステレオを 1 台分で計算)、R3春 設問 1(1)(ブロック長とバッファ長の混同)
- リアルタイム OS の理解不足。H29春 設問 3(3) は優先度の問題をデッドロックと誤認した解答が目立ちました。優先度による待ちとデッドロックは別物です
- 複数要素・順序を一部しか書かない。R4春 設問 3(3) は三つの処理を全て挙げる必要がありました
全体正答率が「高」だったのは H28秋・H29秋・H30秋・R4秋、「低」は R6秋の 1 回だけです。落とす設問は毎回、40 字記述と計算 1 問に集中します。
選択の判断基準。計算を落ち着いて処理でき、状態遷移図やタイミングチャートを読め、「処理中に別事象が来る」並行性を想像できる人に向きます。字数記述で仕様文を書き写してしまう人、単位換算や桁数指定を軽視する人には向きません。問 3 との同時採用は避けます。どちらもトレースと計算に集中するため、40 点分を同じリスクに賭けることになります。
問 8 情報システム開発 ― 設計成果物を読んで理由を書く
19 回とも問 8 に固定です。性格は「クラス図・アクティビティ図・状態遷移表・画面定義といった設計成果物を読み、設計判断の理由を 20〜40 字で書く」。計算を含む問題は 19 問中 6 問だけで、しかも最後は R5秋。以降の 4 回(R6春・R6秋・R7春・R7秋)は計算がゼロです。計算を避けたい人の第 1 候補になります。
| 回 | 題材 | 主要論点 |
|---|---|---|
| H28秋 | SaaS のモジュール分割 | 分割技法の使い分け/モジュール強度と結合度/再利用性 |
| H28春 | 通販の決済処理設計 | アクティビティ図の分岐とフォーク/継承と抽象クラス/自社と相手側の切分け |
| H29秋 | ソフトウェア適格性確認テスト | 境界値分析/ドメイン分析/複数条件網羅/テストケースの過不足 |
| H29春 | コンビニ SNS のアジャイル開発 | バックログ/ペアプログラミング/タスクボード/CI サーバ連携 |
| H30秋 | 継続的インテグレーションの導入 | CI の目的/フォークとジョイン/境界値テスト/回帰テストの自動化 |
| H30春 | サイクロマティック複雑度 | 複雑度の算出/ホワイトボックステストと条件網羅/リファクタリング |
| H31春 | レスポンシブ Web デザイン | UA 判定方式との比較/メディアクエリ/画像切替えと遅延 |
| R1秋 | 信号機制御の状態遷移設計 | 状態遷移表と図の「処理」と「状態」/タイマ並行制御/フェールセーフ |
| R210月 | スクラムの導入と運用 | 役割分担/ドライバとナビゲータ/バーンダウンとベロシティ/価値観の差 |
| R3秋 | ネットスーパーのデータ中心設計 | プロセス中心との比較/多重度と包含・排他・共存/テーブル分割の是非 |
| R3春 | クーポン券発行システム | ブロッキングとノンブロッキング/コンテキストスイッチ/完了順序 |
| R4秋 | 設計レビュー | レビュー技法の識別/モデレータらの役割/二次欠陥/指摘密度と管理限界 |
| R4春 | バス空席情報の連携方式 | 固定長・CSV・XML の比較/API とスクレイピング/欠落検知/未応答時の表示 |
| R5秋 | 美容室アプリのスレッド設計 | ネイティブと Web/プロセスとスレッド/待ち合わせ/総処理時間 |
| R5春 | バージョン管理ツールの運用 | ロック方式とコピー・マージ方式/ブランチの役割/リバートの順序/競合 |
| R6秋 | データ連携ハブの設計 | カプセル化・継承・多相性/オーバーライドとアクセス制御/最小修正での拡張 |
| R6春 | Observer パターンのダッシュボード | 通知機構/多重度 0..*/メソッド仕様の変更/通知の間引き |
| R7秋 | カフェのモバイルオーダー画面設計 | 画面コンポーネントの選定/正規表現/非活性化/SQL インジェクション対策 |
| R7春 | CRM のエラーハンドリング | 抽象クラスの継承/シーケンス図/エラー種別ごとの対応/ログの参照者 |
現在の主軸はオブジェクト指向・設計パターンです。ジャンル別ではオブジェクト指向が 5 問、開発プロセス・開発環境が 5 問、方式・構造設計が 4 問、画面と制御の振る舞い設計が 3 問、テストと品質メトリクスが 2 問。直近 5 回のうち 3 回がオブジェクト指向で、クラス図を読んで継承・多相性・メソッド仕様を答える形が定番です。テスト技法単独の大問は H30春を最後に 7 年途絶えています。前提知識は第 13・14 章です。
設問の型。小設問は合計 114、平均 6.0(最頻値 6 が 9 問)。内訳は字数記述 33%、記号選択 28%、用語記述 25%、穴埋め 12%、計算 7%。字数記述は 19 問中 18 問で出題され(ゼロは R6秋のみ)、1 問あたり平均 2.0 設問あります。解答欄 44 本の字数は 20 字が 15 本で最多、次いで 40 字が 8 本。10〜20 字なら要素は 1 つ、40 字なら「条件 + 結果」の 2 要素と、字数枠そのものが要素数を教えてくれます。
解き方の手順
この分野は本文が長く図が多いので、先に設問を通読してから本文に戻ります。用語記述と記号選択は図と用語表の対応だけで解けることが多く、先に片づけて時間を確保します。次に冒頭 2 段落で「主体」を確定させ、自社側と相手側、メインスレッドとワーカースレッド、main と develop といった境界線を紙上に引きます。主体の取り違えは講評で繰り返し指摘される失点型です。
| 図の種類 | 読み方の型 | 問われ方 |
|---|---|---|
| クラス図 | 矢印の向き(子 → 親)と多重度を先に確定する | 空欄補充、該当クラスを「全て」答える |
| アクティビティ図 | フォークの本数とジョインの合流点を数える | 待ち合わせを外して並行化する対策を 40 字 |
| シーケンス図 | 呼出しの往復と戻りを 1 本ずつ追う | メッセージ名の穴埋め、処理の順序 |
| 状態遷移表 | 行が状態、列がイベント、セルが遷移先 | 空欄補充。「処理」を状態と混同させる |
字数記述は 2 つのテンプレートで書きます。理由を問われたら「〜(本文の条件)なので、〜(結果)となるから」(25〜40 字)、対策や操作を問われたら「〜を、〜する」の動詞終止形(15〜35 字)。本文・図の字句をそのまま使うのが原則で、自分の言葉に言い換えると採点で落ちます。「全て答えよ」型は図を上から走査して候補を列挙し、除外条件で削ってから書きます。1 つで止めると落とします。
採点講評から見た失点と対策
- 用語を名前でしか覚えていない(最頻)。H28秋 設問 1 はモジュール分割技法を逆に理解した解答が目立ち、IPA は「名称や順序を暗記するだけでなく特徴を十分に理解してほしい」と明記しました。R3春 設問 1(2) はコンテキストスイッチを「スレッドスイッチ」と誤答
- 設問が問う対象・範囲を取り違える。R6春 設問 5 はメソッド呼出しの仕様変更を問われて、クラス間の関連構造まで変える解答が出ました
- 主体を取り違える。H28春 設問 3 は相手側システムの処理を自社側として挙げ、R5秋 設問 3(1) はどの処理をメインスレッドで実行すべきかを外しました
- 順序・タイミングの考慮が抜ける。R5春 設問 3 はリバートを行う順序(変更が加えられた順番)の理解不足
- 図を静的にしか読めない。H30秋 設問 4(3) はフォークとジョインの理解不足で「業務・処理の流れをモデル化するスキルが必要」と指摘されました
- 網羅的な書き出しを面倒がる。H29秋 設問 4 は不等号を含めて 8 ケースを地道に書き出せば解ける問題でした
- 「作った後」の視点が欠ける。R3秋 設問 4(1) はテーブル追加がリリース時の限られた時間内の作業になるリスク、R7秋 設問 3(1) はモバイル通信の帯域という利用環境を想定できませんでした
全体正答率は「平均」10 回・「高」4 回で、「低」「やや低」は R3春までに集中し、R3秋以降の 10 回はすべて「平均」です。近年は極端に落とす問題ではなくなっています。
選択の判断基準。実務で設計書・クラス図・バージョン管理・レビューに触れている人、図を読んで「誰が・いつ・どの順で」を追うのが得意な人、そして計算を避けたい人に向きます。逆に、記述を避けたい人には向きません。当日は図の種類(クラス図なら易しめ、状態遷移表なら混同に注意)を見て決めます。
分野をまたいで効く 4 つの技
6 分野の解き方は違っても、失点の原因は共通します。ここでは分野をまたいで効く技を 4 つに絞ってまとめます。
技 1: 単位換算を 1 本のフローで通す
計算が絡む問 4・問 5・問 7 で最も多い失点は、桁と単位です。バイトとビット、秒と月、記憶容量と転送速度を行き来する道筋を 1 本のフローとして覚えます。途中で丸めず、切上げ・切捨ては最後に 1 回だけ行うのが原則です。
| 変換 | 掛ける・割る値 | 出やすい分野 |
|---|---|---|
| バイト → ビット | × 8 | 問 4・問 5・問 7 |
| ビット毎秒 → M ビット毎秒 | ÷ 1,000,000 | 問 4・問 5 |
| ミリ秒 → 秒 | ÷ 1,000 | 問 7 |
| 1 日 → 1 か月(30 日) | × 30 | 問 4 |
| 稼働率 → 月間の許容停止時間 | 30 × 24 × 60 = 43,200 分 に (1 - 稼働率) を掛ける | 問 4 |
| クロック周波数 → タイマの 1 カウント時間 | 分周比 ÷ クロック周波数 | 問 7 |
| 必要台数 | 必要量 ÷ 1 台分 を切り上げ | 問 4 |
技 2: 穴埋めと記号選択は消去法で潰す
穴埋めと記号選択は 6 分野の全小問の約半分を占めます。次の順序で当たりを付けます。
- 空欄の前後 2〜3 行だけを読む。SQL なら直前の処理内容、擬似言語なら宣言部のコメント、FW ルール表なら同じ表の別の行が根拠になる
- 同じ図・同じ表の他の行の書き方に合わせる。日本語で書く回と記号式で書く回があり、書式がずれるだけで減点されます
- 「全て選べ」型は各肢に ○ × を付ける。× の理由を本文の語で言えるものだけを消し、言えない肢は残す
- 「この方式で実現できない要件はどれか」型は、要件を 1 つずつ方式に当てはめる。方式の欠点を先に 1 語で書いておくと速い
- 1 つの空欄に 3 分以上かけない。飛ばして次に進み、他の空欄が埋まってから戻る
技 3: 字数枠が要素数を教えている
6 分野の字数記述はすべて 40 字以下です(50 字以上は 10 年で 1 問もありません)。字数は「いくつ要素を入れるか」の指示だと考えます。
| 字数 | 要素の数 | 書き方 | 例 |
|---|---|---|---|
| 10〜15 字 | 1(名詞句) | 文にしない。設問の語尾に合わせる | 「〜となる経路」「〜する処理」 |
| 20〜25 字 | 2(主体 + 結果) | 「〜が〜する」 | 「送信元 IP がロードバランサのものになる」 |
| 30〜35 字 | 3(条件 + 主体 + 結果) | 「〜なので、〜が〜だから」 | 「共通の処理を一か所で定義できるから」 |
| 40 字 | 3〜4(+ 時間や範囲) | 「〈処理〉中に〈事象〉が起き、〈時間〉が経過したとき」 | 不具合の発生条件(問 7 の定番) |
共通のルールは 3 つです。本文の固有名詞か数値を必ず 1 つ入れる(一般論で答えると落ちます)。本文・図の字句をそのまま使う(自分の言葉に言い換えない)。字数枠の 8 割以上は埋める。
技 4: 見直し 10 分で 6 点を確認する
150 分の内訳は「0〜5 分で 4 問を決定 → 5〜32 分で必須の問 1 → 32〜140 分で選択 4 問(各 27 分)→ 140〜150 分で全体見直し」です。最後の 10 分でやることは決まっています。
- 空欄が残っていないか(最優先。空欄は必ず 0 点)
- 主体が設問の主語と一致しているか
- 文末が問い方に対応しているか(理由 →「〜から」、目的 →「〜ため」)
- 字数は上限の 8 割以上あるか
- 単位・桁数・切上げ/切捨ての指示に従ったか
- 「本文中の字句を用いて」の条件を守ったか
ひっかけポイント
演習問題(科目 B 形式)
本試験と同じ形式で、代表的な 3 分野のミニ演習を用意しました。時間を計り、1 題 12 分を目安に解いてください。解答例には採点で見られる点を添えています。
演習 1 プログラミング(問 3 形式)― 昇順配列の併合走査
音楽配信サービスを運営する M 社では、利用者ごとに「再生したことのある楽曲 ID」を昇順に整列した配列として保持している。M 社は 2 人の利用者の趣味の近さを測るため、共通して再生した楽曲の数を求める関数 countCommon を作ることにした。
単純な方法は、配列 a の各要素について配列 b を全て調べる二重ループである。しかし両方が昇順に整列していることを使えば、先頭から 1 回ずつ走査するだけで数えられる。添字 i と j を 1 から始め、a[i] と b[j] を比べて、等しければ両方を 1 進めて件数を数え、等しくなければ小さい方の添字だけを 1 進める。どちらかの添字が要素数を超えたら終了する。
配列の要素番号は 1 から始まる。次のプログラムは、この考え方で共通の楽曲数を返す。
○整数型: countCommon(整数型の配列: a, 整数型の配列: b)
整数型: i ← 1
整数型: j ← 1
整数型: cnt ← 0
while ( 〔 a 〕 )
if (a[i] が b[j] と等しい)
cnt ← cnt + 1
i ← i + 1
j ← j + 1
elseif ( 〔 b 〕 )
i ← i + 1
else
〔 c 〕
endif
endwhile
return cnt
- a = {102, 205, 311, 428}、b = {205, 311, 500} を与えたとき、while ループが何回実行され、返却値がいくつになるかを答えよ。各回の i、j、cnt の値も示すこと。
- 空欄 〔 a 〕〜〔 c 〕 に入れる字句を答えよ。
- 配列 a または b が昇順に整列していない場合、この関数の結果はどうなるか。30 字以内で述べよ。
- a の要素数を 4、b の要素数を 3 としたとき、二重ループによる方法での a[i] と b[j] の比較回数を答えよ。
演習 1 の解答例と採点ポイント
設問 1 while ループは 4 回実行され、返却値は 2 である。1 回目は i = 1、j = 1、cnt = 0 で 102 < 205 なので i が 2 になる。2 回目は i = 2、j = 1 で 205 が一致し cnt = 1、i = 3、j = 2。3 回目は 311 が一致し cnt = 2、i = 4、j = 3。4 回目は 428 < 500 なので i = 5 となり、i が a の要素数 4 を超えて終了する。
設問 2 〔 a 〕は「i ≦ a の要素数 and j ≦ b の要素数」、〔 b 〕は「a[i] が b[j] より小さい」、〔 c 〕は「j ← j + 1」。
設問 3 解答例「小さい側の添字だけが進み、共通する楽曲を数え落とす。」(26 字)
設問 4 4 × 3 = 12 回。併合走査では while ループが 4 回で、1 回あたりの比較は最大 2 回なので 8 回以下に収まる。
採点ポイント ① 設問 2 の 〔 c 〕 は代入文の形で書く。「j + 1」だけでは代入になっておらず、講評でも「代入文になっていない」誤答が指摘されている。② 〔 a 〕 は「かつ」で 2 条件を結ぶ。片方だけだと配列の範囲外を参照する。③ 設問 3 は「昇順でなくなる」という前提の言い換えで止めず、数え落とすという結果まで書く。④ 終了条件は「どちらかが要素数を超えたとき」であり、「両方が超えたとき」ではない。
演習 2 ネットワーク(問 5 形式)― SaaS 直結化に伴う通信経路の変更
D 社は動物病院を 3 院運営している。各院には拠点ルータが置かれ、院内の PC には私設 IP アドレスが割り当てられている。拠点ルータはアドレス変換を行い、複数の PC の通信を 1 つのグローバル IP アドレスに集約してインターネットへ送出する。
従来、院内 PC のインターネット向け通信は、いったん本院のプロキシサーバへ送られ、そこから外部へ出ていた。D 社は電子カルテを SaaS へ移行するにあたり、各院の PC が SaaS へ直接 HTTPS で接続する方式に変更する。移行後はプロキシサーバを廃止する予定である。
本院の FW には、移行の第 1 段階として次のルールが設定された(上から順に評価し、いずれにも該当しない通信は拒否する)。戻りの通信は FW が自動的に許可するため、ルールには書かない。
| 項番 | 送信元 | 宛先 | 宛先ポート番号 | 動作 |
|---|---|---|---|---|
| 1 | 各院の PC | 電子カルテ SaaS | 〔 a 〕 | 許可 |
| 2 | 各院の PC | プロキシサーバ | 8080 | 許可 |
| 3 | 〔 b 〕 | インターネット | 80、443 | 許可 |
| 4 | 本院のメールサーバ | インターネット | 25 | 許可 |
- 空欄 〔 a 〕 に入る宛先ポート番号を答えよ。また 〔 b 〕 に入る機器名を答えよ。
- プロキシサーバを廃止した後、不要になるルールの項番を全て答えよ。
- 各院の PC から SaaS へ接続したとき、SaaS 側で記録される送信元 IP アドレスは何か。機器名を用いて 25 字以内で述べよ。
- 拠点ルータが行っているアドレス変換の名称を答えよ。
演習 2 の解答例と採点ポイント
設問 1 〔 a 〕は 443(HTTPS)。〔 b 〕はプロキシサーバ。
設問 2 項番 2 と項番 3。項番 2 は PC からプロキシサーバへの通信、項番 3 はプロキシサーバがインターネットへ出る通信であり、プロキシサーバが無くなればどちらも発生しない。項番 4 はメールサーバの通信なので残る。
設問 3 解答例「各院の拠点ルータのグローバル IP アドレス」(21 字)
設問 4 NAPT(IP マスカレードでも可)。
採点ポイント ① 設問 3 で「各院の PC の IP アドレス」と答えると誤り。アドレス変換を行う機器を通った後は送信元が変わるという、講評で繰り返し指摘される論点そのものである。② 設問 2 で項番 3 を落とす誤答が出やすい。「誰が・どこへ」の両方向で不要になる行を探す。③ 設問 1 の 443 を 80 と書かないこと。設問文に「HTTPS で接続する」と明記されている。④ 戻りの通信を許可する行を新たに書き足す必要はない。
演習 3 データベース(問 6 形式)― 醸造所の樽貸出管理
クラフトビールを製造する B 社は、飲食店へ貸し出す樽(ケグ)の管理システムを構築している。ケグは B 社が所有し、取引先である飲食店へ貸し出す。返却されるまでは「貸出中」として扱う。表定義は次のとおりで、各表の先頭の属性が主キーである。
醸造所(醸造所コード, 醸造所名, 所在地)
ケグ(ケグ番号, 容量, 製造年月, 醸造所コード)
取引先(取引先コード, 取引先名, 与信限度額)
貸出(貸出番号, ケグ番号, 取引先コード, 貸出日, 返却予定日, 返却日)
B 社は「ケグごとの貸出回数」を調べ、稼働していないケグを洗い出したい。一度も貸し出されていないケグも 0 回として結果に含める必要がある。次の SQL 文は、その一覧をケグごとに貸出回数の多い順で得るものである。
SELECT K.ケグ番号, COUNT( 〔 a 〕 ) AS 貸出回数
FROM ケグ K
〔 b 〕 JOIN 貸出 KA ON K.ケグ番号 = KA.ケグ番号
GROUP BY 〔 c 〕
ORDER BY 貸出回数 DESC
- ケグと貸出の関連について、E-R 図の矢印はどちらの表からどちらの表へ向くか。判断の根拠とともに 30 字以内で述べよ。
- 空欄 〔 a 〕〜〔 c 〕 に入れる字句を答えよ。
- 空欄 〔 a 〕 に「*」を書いた場合、結果はどうなるか。40 字以内で述べよ。
- 取引先の与信限度額を変更した履歴を残せるようにしたい。追加すべきエンティティの名称と、その主キーを構成する属性を全て答えよ。
演習 3 の解答例と採点ポイント
設問 1 解答例「ケグの主キーを貸出が外部キーで持つので、ケグから貸出へ向く」(29 字)
設問 2 〔 a 〕は「KA.貸出番号」、〔 b 〕は「LEFT OUTER」、〔 c 〕は「K.ケグ番号」。
設問 3 解答例「一度も貸し出されていないケグの貸出回数が 0 ではなく 1 になる」(30 字)
設問 4 与信限度額履歴(名称は「与信履歴」等でもよい)。主キーは取引先コードと適用開始日の 2 つ。
採点ポイント ① 設問 2 の 〔 a 〕 で「*」を選ぶのが最も多い誤りで、設問 3 がその確認になっている。外部結合で相手が無い行も 1 行として残るため、数える対象は結合先の列にする。② 〔 b 〕 を INNER と書くと、貸出実績の無いケグが結果から消え、要件を満たさない。③ 〔 c 〕 は SELECT 句の集計対象でない列をそのまま並べる。別名 K で修飾すること。④ 設問 4 で主キーを「取引先コード」だけにすると、履歴が 1 件しか持てない。いつからの値かを主キーに含めるのが履歴保持の型である。
まとめ
テクノロジ系 6 分野は問 3〜問 8 に固定されており、選ぶ 4 問は学習開始時に決められます。最後に、当日その場で確認できる形に圧縮しておきます。
| 問 | 分野 | 主戦場となる形式 | 計算 | 当日の見極めライン |
|---|---|---|---|---|
| 3 | プログラミング | 穴埋め 58% | 約 17 小設問 | 着手 10 分で「実データ ↔ 配列」の対応表が書けなければ撤退 |
| 4 | システムアーキテクチャ | 字数 28%・記号 24%・計算 23% | 19 問中 14 問 | 計算が 3 個を超えたら他の候補と比べる |
| 5 | ネットワーク | 用語 41%・字数 28% | 7 小設問 | 構成図の機器数とルール表の行数(読図量)で決める |
| 6 | データベース | 穴埋め 53.1%・用語 25.5% | 集計に記載なし | 設問 1 の E-R 図の向きが 1 分で読めるか |
| 7 | 組込みシステム開発 | 用語 24.2%・計算 22.5%・字数 20.8% | 19 問中 17 問 | 問 3 と同時に選ばない(リスクが重なる) |
| 8 | 情報システム開発 | 字数 33%・記号 28% | 19 問中 6 問(直近 4 回ゼロ) | 図の種類を見る。クラス図なら読みやすい |
- 選ぶ基準は分野名ではなく形式の内訳。書く量(字数記述の比率)と計算の量の 2 軸で並べると、6 分野は図 24-1 のようにきれいに散らばる
- 1 問 25〜30 分、5 問で 150 分。冒頭 5 分で 4 問を決め、最後の 10 分は空欄潰しに使う
- どの分野も読む順序は「設問 → 図表 → 本文の該当箇所」。本文から読み始めると時間が溶ける
- 計算は式・単位・検算の 3 段。足す対象が 2 系統ないか、境界値で破綻しないかを必ず確かめる
- 字数枠が要素数の指示。20 字なら 1 要素、40 字なら条件と結果の 2 要素。本文の固有名詞か数値を 1 つ入れる
- 5〜6 分野を仕込み、当日 1〜2 分野を捨てる。予備をゼロにすると逃げ場がなくなる
ここまでで、必須の問 1(第 23 章)とテクノロジ系の選択問題が揃いました。続く第 25 章では、経営戦略・情報戦略、プロジェクトマネジメント、サービスマネジメント、システム監査という計算がほとんど出ない 4 分野を扱います。本章の 6 分野で 4 問を埋めきれない場合の予備として、少なくとも 1 分野は仕込んでおいてください。