【 問題 】 半導体メモリ（RAM）の物理的な構造と構成要素に関する記述のうち、正しいものはどれか。
（ア）SRAMは、トランジスタのみで構成されている
（イ）DRAMは、トランジスタのみで構成されている
（ウ）SRAMは、コンデンサのみで構成されている
（エ）DRAMは、コンデンサのみで構成されている
正解：（ア）SRAMは、トランジスタのみで構成されている
SRAM（Static RAM）は、複数のフリップフロップ回路（スイッチの役割を果たすトランジスタのみ）を用いて1ビットのデータを記憶します。コンデンサを持たないため、電源が供給されている限りデータが消えず、リフレッシュ動作が不要で極めて高速に動作します。
一方、DRAM（Dynamic RAM）は、電荷を蓄えるコンデンサ1個と制御用のトランジスタ1個の組み合わせで構成されています。
| メモリ種別 | 構成素子・回路 | リフレッシュ | 主な用途・特徴 |
|---|---|---|---|
| SRAM (Static RAM) |
トランジスタのみ （フリップフロップ回路） |
不要 | ・キャッシュメモリに利用 ・高速／高価格／大面積（集積度低） |
| DRAM (Dynamic RAM) |
コンデンサ ＋ トランジスタ （1セル＝各1個） |
必要 （電荷の再充電） |
・主記憶（メインメモリ）に利用 ・低速／安価／小面積（大容量化可能） |
1. 理解のコツ:
・「SRAM＝Switch（スイッチ＝トランジスタのみで電気をカチカチ切り替えるイメージ）」
・「DRAM＝Dripping（水滴が漏れるバケツ＝コンデンサに電気を溜めるが漏れるので定期的に補給（リフレッシュ）が必要）」
と覚えるとイメージしやすくなります。
2. 試験対策の視点:
・「SRAM＝フリップフロップ＝トランジスタのみ＝キャッシュメモリ＝リフレッシュ不要」
・「DRAM＝コンデンサ＋トランジスタ＝主記憶（メインメモリ）＝リフレッシュ必要」
この連鎖的なキーワードの繋がりが試験で最も問われます！
フリップフロップ回路によりトランジスタのみで構成され、リフレッシュ不要で高速動作するメモリ。それがSRAMです。コンデンサとトランジスタの組み合わせで構成されるDRAMとの対比構造をしっかり押さえておきましょう！
【 問題 】 共通鍵暗号（ブロック暗号）に対する解読攻撃手法に関する記述です。複雑な暗号化関数や処理を一次式（線形関数）で近似した確率的モデル（近似式）を作成し、大量の平文と暗号文のペアを統計的に分析することによって暗号鍵の特定・解読を試みる攻撃手法はどれか。
（ア）差分解読法
（イ）総当たり法（ブルートフォース攻撃）
（ウ）高階差分解読法
（エ）線形解読法
正解：（エ）線形解読法
線形解読法（Linear Cryptanalysis）は、松井充氏によって提案されたブロック暗号に対する著名な攻撃手法です。
暗号の内部処理を「平文のビット ⊕ 暗号文のビット ＝ 鍵のビット」のような**線形一次式（近似式）**として表現し、入力と出力の関係性がどの程度の確率で成立するか（偏り）を調べることで、鍵のビット情報を解析します。
| 解読手法 | 概要とアプローチ | 特徴・キーワード |
|---|---|---|
| （エ）線形解読法 | 暗号化関数を一次式（線形関数）で近似した確率式を作り、平文と暗号文のペアから鍵を推定する。 | 近似式 統計的分析 |
| （ア）差分解読法 | 2つの平文の「差分（入力変化）」と「暗号文の差分（出力変化）」の伝播確率を追跡して鍵を分析する。 | 入力の差分と出力の差分 確率分布 |
| （ウ）高階差分解読法 | 差分解読法をさらに発展させ、高階の差分（高次多項式）を用いて特定の暗号関数構造を破る手法。 | 差分解読法の発展型 |
| （イ）総当たり法 (ブルートフォース) |
考えられるすべての鍵パターン（全選択肢）を試して正解の鍵を力任せに探す。 | すべての組み合わせ 全片っ端テスト |
1. 理解のコツ:
・複雑に絡み合った曲線グラフ（非線形な暗号処理）を、直線（一次式・近似式）にあてはめて見当をつけるイメージです。
2. 試験対策の視点:
・問題文に「近似式」「一次式」「線形関数」「統計的」と来たら、迷わず線形解読法を選択しましょう！
・対となる「入力の差分と出力の差分の関係」というフレーズがあれば差分解読法になります。両者は現代の暗号アルゴリズム（AESなど）の安全性を評価する際の2大基準となっています。
暗号化処理を一次式（線形近似式）で近似し、大量の平文・暗号文ペアから統計的に鍵を特定・推測する解読攻撃。これが線形解読法です。差分解読法や総当たり法との定義の違いをはっきり区別して覚えておきましょう！
]]>【 問題 】 データベースにおけるデータ同士の関係（関数従属：一方を決めるのにもう一方が決まる関係）に関する記述のうち、適切なものはどれか。
（ア）BがAで決まり、CがAで決まれば、CはBで決まる
（イ）BがAの一部であり、CがAで決まれば、CはBで決まる
（ウ）BがAの一部であれば、AはBで決まる
（エ）BとCのセットがAで決まれば、BとCは、それぞれAで決まる
正解：（エ）BとCのセットがAで決まれば、BとCは、それぞれAで決まる
関数従属（かんすうじゅうぞく）とは、難しく聴こえますが**「Aが決まれば、自動的にBがただ1つに決まる関係」**のことです。
例えば、「学籍番号（A）」が決まれば、「名前（B）」も「学部（C）」も1つに特定できるという関係のことを指します。
| 選択肢 | 現実のデータに置き換えた例 | 判定と理由 |
|---|---|---|
| （ア） | 「学籍番号(A)」が決まれば「名前(B)」と「学部(C)」が決まるなら、「名前(B)」を決めれば「学部(C)」が決まる。 | 間違い。 同姓同名の人がいるかもしれないので、名前だけでは学部を特定できません。 |
| （イ） | 「学籍番号とクラス(A)」の一部である「クラス(B)」だけで、「学部(C)」を特定できる。 | 間違い。 「A組」という情報だけでは、どの学部の何さんか特定できません。情報が足りません。 |
| （ウ） | 「学籍番号とクラス(A)」の一部である「クラス(B)」を決めれば、「学籍番号とクラス(A)」が決まる。 | 間違い。 正しくは逆です。「学籍番号とクラス(A)」が分かっていれば、その中の「クラス(B)」も分かります。 |
| （エ） | 「学籍番号(A)」が決まれば「名前と学部(BとCのセット)」が決まるなら、「名前(B)」も「学部(C)」も個別に特定できる。 | 正しい！ 学籍番号でセットの内容が決まるなら、当然その中の名前単体も、学部単体も特定できます。 |
1. 理解のコツ:
・「セットで特定できるものは、バラバラにしても当然特定できる」という「分解のルール」を言っているのが（エ）です。
2. 試験対策の視点:
・試験問題で「関数従属」という言葉が出たら、自分の頭の中で「A＝学籍番号」「B＝名前」「C＝学部」のように実際のデータに置き換えて考えると、数式を使わずに直感で正解が選べます！
セットの情報がAによって特定できるなら、その中の1つひとつの項目（BやC）も当然Aによって特定できる（分解のルール）。これが関数従属の基本的な性質です。難しそうな言葉に惑わされず、身近なデータに置き換えて解くコツをマスターしておきましょう！
]]>XPは「変化を受け入れる」ことを前提としたアジャイル開発手法の代表格です。短期間の反復（イテレーション）の中で、以下の5つのアクティビティを繰り返し実行しながらシステムを成長させます。
| アクティビティ | 主な活動と内容 | 試験対策の重要キーワード・補足 |
|---|---|---|
| (1) 計画 (Planning) |
・機能要求を示したユーザーストーリー（要件カード）を作成する。 ・ユーザーストーリーに対する受け入れ基準（テスト条件）を定義する。 ・ストーリーの優先順位と工数見積もりに基づき、反復計画（イテレーション計画）を作成する。 |
・オンサイト顧客：開発チーム内に顧客（ユーザー）が常駐し、ストーリーの作成や優先順位決定を即座に行う。 |
| (2) 設計 (Design) |
・CRCカード（Class, Responsibility, Collaboration）などを用いて、オブジェクト指向のクラス設計を行う。 ・技術的な疑問やリスクを解消するため、スパイクソリューションと呼ばれる実験的なプロトタイプを作成して検証を行う。 |
・シンプル設計（YAGNI原則）：「今必要な機能だけを設計・実装し、将来の予測で余計な機能を組み込まない」という原則。 |
| (3) コーディング (Coding) |
・プログラムのコーディングおよびユニットテスト（単体テスト）を行う。 ・常に動作可能なコードを維持し、継続的にコード品質を高める。 |
・ペアプログラミング：2名で1台のPCを操作して開発。 ・TDD（テスト駆動開発）：コードを書く前にまずテストを作成。 ・リファクタリング：外部挙動を変えずにコードをキレイに整理。 |
| (4) テスト (Testing) |
・計画フェーズで策定した受け入れ基準に基づき、受入テスト（システムテスト）を行う。 ・顧客とともに要求通りの動作を満たしているかを検証する。 |
・継続的インテグレーション（CI）：作成したコードを頻繁に統合・自動テストし、欠陥を早期発見する。 |
| (5) リリース (Release) |
・完成したソフトウェアを頻繁にリリース（本番展開または評価）する。 ・プロジェクトのベロシティ（消化作業量）を測定し、過去実績として次の反復計画へ生かす。 |
・スモールリリース：小さな単位で頻繁にリリースし、ユーザーからの早期フィードバックを得る。 |
※例えるなら、XPのアクティビティは「料理の新メニュー開発」です。大がかりなレシピを作る前に『試し作り（スパイクソリューション）』を行い、2人で味見しながら調理し（ペアプログラミング）、少量ずつ試食（スモールリリース）してもらいながらお客様の感想を次の試作（ベロシティ測定・反復）に活かしていくアプローチです。
]]>トップダウンで機能を細分化（機能分解）していく構造化アプローチは、小規模開発には有効ですが、システムの大型化や要件変更の頻発に伴い以下の深刻な限界に直面しました。
| 限界・課題の項目 | 概要と発生する問題点 | 具体的な症状・影響 |
|---|---|---|
| 1. 数量的爆発 (Document / Combinatorial Explosion) |
システムやビジネスロジックが複雑化・大規模化するにつれて、作成・管理すべき仕様書（DFD、モジュール仕様書、データ辞書など）の数が爆発的に増大する現象。 | ・ドキュメントの維持管理が不可能な状態（管理不全）に陥る。 ・仕様変更時の整合性チェック（影響範囲追跡）が極めて困難になる。 |
| 2. 保守の困難性 (Maintenance Difficulty) |
仕様変更やバグ修正を繰り返すうちに構造が崩れ、システムの複雑性が増大して全体構造の理解が困難（スパゲティコード化）になる現象。 | ・一部を修正すると予期せぬ箇所に影響（副作用）が出る。 ・開発当初の設計思想が失われ、改修コストやリスクが急増する。 |
| 3. データと処理の分離 (Data & Process Separation) |
「処理（機能）」と「データ」を個別に分析・設計するため、データの構造変更が広範囲のモジュールに影響を及ぼしやすい弱点。 | ・共通のグローバル変数やDB構造が変わると、それを参照する大量のプログラム修正が必要になる。 |
| 4. 再利用性の低さ (Low Reusability) |
特定のシステム手順に依存した機能分割を行うため、他のプロジェクトや機能へ部品（モジュール）を再利用することが難しい。 | ・似たような処理を毎回ゼロから作成（車輪の再発明）することになり、開発効率が上がらない。 |
※例えるなら、構造化設計は「巨大なプラモデルの説明書」です。作品が巨大になるほど説明書のページ数も爆発し（数量的爆発）、途中でパーツの形を1つ変えると全体の組み付け手順が狂って直せなくなる（保守の困難性）問題が起きます。これをパーツごとに完結させた「ブロック（レゴ）」のように組み替えやすくしたのが、現代のオブジェクト指向です。
【 問題 】 プロジェクトマネジメントにおけるチーム育成の手法に関する記述です。コミュニケーションの円滑化やチームの一体感向上、問題解決の迅速化を図るために、プロジェクトメンバーが物理的に同じ1箇所（同じ部屋やオフィス）に集まって作業を行うことを何と呼ぶか。
（ア）一括ロケーション
（イ）集中ロケーション
（ウ）コロケーション
（エ）セントラル・ロケーション
正解：（ウ）コロケーション（Colocation / Co-location）
コロケーション（Co-location）は、プロジェクトの全員またはコアメンバーを物理的に1つの作業場所に配置するチーム編成手法です。
対面（Face to Face）による口頭コミュニケーションが容易になるため、誤解の防止、意思決定の高速化、チームワークの強化に絶大な効果を発揮します。
| 手法・概念 | 特徴・メリット | 課題・考慮すべき点 |
|---|---|---|
| （ウ）コロケーション （Co-location） |
物理的に1箇所に集まる。 対面会話で意思決定が早く、一体感が生まれやすい。 |
移動コストやオフィス確保の費用がかかる。地理的制約を受ける。 |
| バーチャルチーム （Virtual Team） |
地理的に離れた場所で共同作業する。 Web会議やチャットツールを活用し、世界中から専門家をアサイン可能。 |
対面より誤解が生じやすく、コミュニケーションツールの整備が必須。 |
1. 理解のコツ:
・英語の接頭辞「Co-（共に、共同の）」＋「Location（場所）」で、『同じ場所で一緒に作業する』という意味になります。
2. 試験対策の視点:
・問題文に「物理的に1箇所に集まる」「同じ場所で作業」「チーム育成・コミュニケーション活性化」と来たら、迷わずコロケーションを選択しましょう！
・アジャイル開発（スクラムなど）においても、コロケーションはチームのベロシティ向上に寄与する重要プラクティスとして重視されます。
プロジェクトメンバーが物理的に同じ1場所に集まって作業を進めるチーム形成手法。これがコロケーションです。対面でのスムーズな意思決定やチームの一体感醸成に欠かせないマネジメント用語として確実に覚えておきましょう！
]]>【 問題 】 システムの要求分析や設計において用いられる状態遷移図の利用が最もふさわしい開発（プログラム）は、次のうちどれか。
（ア）給与計算バッチプログラム
（イ）事務処理プログラムの画面の設計
（ウ）オンラインデータベースの検索システム
（エ）プロセスの制御プログラム
正解：（エ）プロセスの制御プログラム
状態遷移図（State Transition Diagram）は、システムの「状態（State）」と、それを変化させる「イベント（Trigger）」および「アクション」の関係を表現する図です。
エアコン、エレベーター、工場などの**プロセス制御プログラム（リアルタイム系・組込み系）**では、「停止中」「稼働中」「異常停止」のように内部状態によって外部イベントへの挙動が変わるため、状態遷移図による設計が不可欠です。
| 選択肢 | 特徴・処理方式 | 最も適した設計・表現図 |
|---|---|---|
| （ア）給与計算バッチプログラム | 順序に沿って大量データを一括処理する。 | フローチャート（流れ図）、DFD（データフロー図） |
| （イ）事務処理プログラムの画面設計 | 画面上のレイアウトや機能配置。 | ワイヤーフレーム、モックアップ、画面遷移図 |
| （ウ）DB検索システム | データ構造とそのリレーションの設計。 | ER図（Entity-Relationship Diagram） |
| （エ）プロセスの制御プログラム | センサー等のイベントによって内部状態が変化する。 | 状態遷移図（ステートマシン図） |
1. 理解のコツ:
・「信号機（赤→青→黄）」や「自販機（待機→コイン投入済み→販売中）」のように、『今どの状態にいるか』によってボタンを押した時の動きが変わるシステムには、すべて状態遷移図を使います。
2. 試験対策の視点:
・問題文に「状態遷移図の適用例」「プロセス制御」「組込みシステム」「通信プロトコル」「イベント駆動」とあれば、迷わずプロセスの制御プログラム系の選択肢を選びましょう！
外部からのイベントに応じてシステムの内部状態がどのように変化・推移するかを表す図説手法。これが状態遷移図です。プロセス制御プログラムやリアルタイム処理に最適な設計手法として確実に覚えておきましょう！
]]>【 問題 】 ソフトウェアのブラックボックステストにおいて、条件分岐や繰り返し（ループ）の終了判定の誤りを効率よく発見するために、データの範囲（同値クラス）の境界となる値およびその直前・直後の値をテストデータとして選定するテスト技法はどれか。
（ア）同値分割法（Equivalence Partitioning）
（イ）境界値テスト（限界値分析 / Boundary Value Analysis）
（ウ）原因結果グラフ（Cause-Effect Graphing）
（エ）ペア構成テスト（All-Pairs Testing）
正解：（イ）境界値テスト（限界値分析 / Boundary Value Analysis）
境界値テスト（限界値分析）は、同値クラス（同じ処理が行われるデータのグループ）の境目（境界線）に特化してテストを実施する手法です。
プログラミングにおいて、不等号の誤り（`＜` と `≦` の勘違い）やループのカウントミス（1つズレるOff-by-oneエラー）は境目で発生しやすいため、「境界値」とその「直前・直後の値」を検証することで高い欠陥検出率を実現します。
| 境界（境目） | テスト値（直前・直後） | 判定結果（期待値） | テストの狙い |
|---|---|---|---|
| 下限の境界 （20歳） |
19歳（直前） | 無効（エラー） | `20 <=` であるべきが `19 <=` になっていないか |
| 20歳（境界値） | 有効（正常） | `20 <=` であるべきが `20 <` になっていないか | |
| 上限の境界 （60歳） |
60歳（境界値） | 有効（正常） | `<= 60` であるべきが `< 60` になっていないか |
| 61歳（直後） | 無効（エラー） | `<= 60` であるべきが `<= 61` になっていないか |
1. 理解のコツ:
・まずグループ分け（同値分割）を行い、そのグループの「端っこ（ギリギリ合格する値）」と「その一歩外側（ギリギリ不合格になる値）」のペアをセットでテストするのが基本です。
2. 試験対策の視点:
・問題文に「条件判定の誤りを防ぐ」「ループの終了条件」「直前、直後の値でテスト」「限界値」と来たら、迷わず境界値テスト（限界値分析）を選択しましょう！
・同値クラスの代表値を1つ選ぶ「同値分割法」とセットで出題されることが多いため、両者の違い（代表値を選ぶか、端とその前後を選ぶか）を意識しておくことが大切です。
同値クラスの境界線上にある値と、その直前・直後の値をテストデータとして抽出し、分岐・ループ等の判定ミスを防ぐ手法。これが境界値テスト（限界値分析）です。実装時の初歩的バグを最も効率よく検出できるテスト技法として必ず押さえておきましょう！
【 問題 】 Javaなどのプログラミング言語において、ソースコードをコンパイルした際に作成されるコードに関する記述です。特定のOS（Windows、Mac、Linuxなど）やCPU（x86、ARMなど）の命令セットに依存しない形式に変換された、仮想マシンが解釈して実行するための中間コードはどれか。
（ア）ソースコード（Source Code）
（イ）オブジェクトコード（Object Code）
（ウ）バイトコード（Bytecode）
（エ）ネイティブコード（Native Code）
正解：（ウ）バイトコード（Bytecode）
バイトコード（Bytecode）は、人間が書いた「ソースコード」と、CPUが直接理解できる「機械語（ネイティブコード）」の中間に位置する汎用的な中間表現（中間コード）です。
バイトコード自体は特定のCPUの命令形式（ネイティブコード）ではないため、各OS用に用意された仮想マシン（Java仮想マシン: JVMなど）が、実行時にその環境に適した機械語へと翻訳・実行（JITコンパイルや解釈実行）します。
| コード種別 | 概要と特徴 | ポータビリティ（可搬性） |
|---|---|---|
| （ア）ソースコード | プログラマがテキスト形式で書いたプログラム命令。 | 人間が読める状態 |
| （ウ）バイトコード （中間コード） |
コンパイラによって生成されるOSやCPUに依存しない形式の中間命令。 | 極めて高い （仮想マシンがあればどこでも動作） |
| （エ）ネイティブコード （機械語/オブジェクト） |
特定ハードウェア（CPU/OS）の命令セットに直接変換された機械語。 | 依存度が極めて高い （別のOSでは動かない） |
1. 理解のコツ:
・「日本語（ソースコード）」を一旦「世界共通の英語（バイトコード）」に直しておき、各国（各OS・CPU）の通訳さん（仮想マシン）にその国の言葉に直して実行してもらう仕組みです。これにより、世界中（どのOS・CPU環境でも）で同じプログラムを動かせるようになります。
2. 試験対策の視点:
・問題文に「OSやCPUに依存しない」「中間コード」「仮想マシン（VM）が解釈」「Javaなどで使用」と来たら、迷わずバイトコードを選択しましょう！
・実行時にバイトコードを瞬時に機械語へ変換して実行速度を上げる技術「JIT（Just-In-Time）コンパイラ」もセットで出題されやすい重要概念です。
OSやCPUなどのハードウェア環境に依存しない中間形式のプログラムコード。これがバイトコード（中間コード）です。仮想マシンを介して実行することで、高い環境ポータビリティを実現する技術としてしっかり覚えておきましょう！
【 問題 】 アジャイル開発（スクラム）において、チームの生産性や進行速度を表す指標に関する記述です。過去に実施したスプリントで実際に完了（完成）させたストーリーポイントの平均値（実績データ）をもとに、今後のスプリントで消化可能な作業量やプロジェクト完了時期を見積もるために用いる指標はどれか。
（ア）バーンダウンチャート（Burn-down Chart）
（イ）ベロシティ（Velocity）
（ウ）ストーリーポイント（Story Point）
（エ）リードタイム（Lead Time）
正解：（イ）ベロシティ（Velocity）
ベロシティ（ベロシティ / 開発速度）は、アジャイル開発においてチームが単位期間（1スプリント）あたりに達成できる成果の量を数値化したものです。
開発初期は予測値で始めますが、スプリントを何回か回すと「チームの実力（平均ベロシティ）」が固まってくるため、過去の実績に基づく極めて精度の高い予測・見積もりが可能になります。
| 指標・手法 | 概要と主な目的 | 活用例 |
|---|---|---|
| （イ）ベロシティ (Velocity) |
1スプリント内で完了した作業量（ポイント）の過去実績値。チームの開発速度を示す。 | 次スプリントの計画作成や、プロダクト全体の完成時期の見積もり |
| （ウ）ストーリーポイント (Story Point) |
タスクの相対的な大きさ・複雑さ・難易度を表す見積もり単位（単位時間ではない）。 | 機能ごとの作業見積もり（プランニングポーカー等） |
| （ア）バーンダウンチャート (Burn-down Chart) |
残作業量を折れ線グラフで視覚化し、進捗遅れを一目で把握する図表。 | 日々の進捗モニタリング |
1. 理解のコツ:
・車で言えば、ストーリーポイントが「距離（km）」で、ベロシティは「時速（km/h）」です。「1時間に30km走れるチーム（ベロシティ=30）」だと分かれば、残りの150kmを走るのに「あと5時間（5スプリント）」かかると簡単に見積もれます。
2. 試験対策の視点:
・問題文に「過去のスプリント」「実績をもとに見積もる」「1スプリントあたりの消化作業量」と来たら、迷わずベロシティを選択しましょう！
・「ベロシティは他チームと比較する数値ではなく、そのチーム自身の計画精度向上のために用いる」という原則も出題ポイントです。
過去のスプリントで完了した作業実績（ストーリーポイント）をもとに、今後の開発ペースや完了時期を予測する指標。これがベロシティです。アジャイル開発の進捗管理における中心概念としてしっかり押さえておきましょう！