【システム設計・UML】イベントによる状態の変化をモデル化！「状態遷移図」の適用分野｜情報処理問題1000本ノック

基本情報技術者試験、応用情報技術者試験、組込みシステムスペシャリスト試験の「システム設計・モデル化手法」分野で頻出の超重要テーマ。「状態遷移図（ステートマシン図）」の定義と、他のモデリング手法（DFD、ER図、アクティビティ図など）との適切な使い分けを攻略しましょう。

1. 【 問題 】：テクノロジ系（システム設計・ソフトウェア構造設計）

【 問題 】 システムの要求分析や設計において用いられる状態遷移図の利用が最もふさわしい開発（プログラム）は、次のうちどれか。

（ア）給与計算バッチプログラム
（イ）事務処理プログラムの画面の設計
（ウ）オンラインデータベースの検索システム
（エ）プロセスの制御プログラム

2. 正解：

正解：（エ）プロセスの制御プログラム

3. 解説：「『状態』がイベントで変化するリアルタイム系・組込み処理に最適！」

状態遷移図（State Transition Diagram）は、システムの「状態（State）」と、それを変化させる「イベント（Trigger）」および「アクション」の関係を表現する図です。
エアコン、エレベーター、工場などの**プロセス制御プログラム（リアルタイム系・組込み系）**では、「停止中」「稼働中」「異常停止」のように内部状態によって外部イベントへの挙動が変わるため、状態遷移図による設計が不可欠です。

【選択肢のプログラムと最適・代表的なモデル図の比較】 ← 超頻出ポイント！

選択肢	特徴・処理方式	最も適した設計・表現図
（ア）給与計算バッチプログラム	順序に沿って大量データを一括処理する。	フローチャート（流れ図）、DFD（データフロー図）
（イ）事務処理プログラムの画面設計	画面上のレイアウトや機能配置。	ワイヤーフレーム、モックアップ、画面遷移図
（ウ）DB検索システム	データ構造とそのリレーションの設計。	ER図（Entity-Relationship Diagram）
（エ）プロセスの制御プログラム	センサー等のイベントによって内部状態が変化する。	状態遷移図（ステートマシン図）

1. 理解のコツ:
・「信号機（赤→青→黄）」や「自販機（待機→コイン投入済み→販売中）」のように、『今どの状態にいるか』によってボタンを押した時の動きが変わるシステムには、すべて状態遷移図を使います。

2. 試験対策の視点:
・問題文に「状態遷移図の適用例」「プロセス制御」「組込みシステム」「通信プロトコル」「イベント駆動」とあれば、迷わずプロセスの制御プログラム系の選択肢を選びましょう！

---

4. まとめ

外部からのイベントに応じてシステムの内部状態がどのように変化・推移するかを表す図説手法。これが状態遷移図です。プロセス制御プログラムやリアルタイム処理に最適な設計手法として確実に覚えておきましょう！

【ソフトウェアテスト】条件分岐やループの判定ミスを狙い撃ち！「境界値テスト（限界値分析）」｜情報処理問題1000本ノック

基本情報技術者試験、応用情報技術者試験、ITストラテジスト試験などの「ソフトウェアテスト技法・品質管理」分野で超頻出の重要概念。「境界値テスト（限界値分析）」の定義と、併せて押さえるべき「同値分割法」との組み合わせ方を整理して攻略しましょう。

1. 【 問題 】：テクノロジ系（ソフトウェアテスト・品質管理）

【 問題 】 ソフトウェアのブラックボックステストにおいて、条件分岐や繰り返し（ループ）の終了判定の誤りを効率よく発見するために、データの範囲（同値クラス）の境界となる値およびその直前・直後の値をテストデータとして選定するテスト技法はどれか。

（ア）同値分割法（Equivalence Partitioning）
（イ）境界値テスト（限界値分析 / Boundary Value Analysis）
（ウ）原因結果グラフ（Cause-Effect Graphing）
（エ）ペア構成テスト（All-Pairs Testing）

2. 正解：

正解：（イ）境界値テスト（限界値分析 / Boundary Value Analysis）

3. 解説：「『境界線の直前・直後』にバグは潜む！」

境界値テスト（限界値分析）は、同値クラス（同じ処理が行われるデータのグループ）の境目（境界線）に特化してテストを実施する手法です。
プログラミングにおいて、不等号の誤り（`＜` と `≦` の勘違い）やループのカウントミス（1つズレるOff-by-oneエラー）は境目で発生しやすいため、「境界値」とその「直前・直後の値」を検証することで高い欠陥検出率を実現します。

【境界値テストのテストデータ選定例（例：「20歳以上60歳以下」を有効とする場合）】 ← 超頻出ポイント！

境界（境目）	テスト値（直前・直後）	判定結果（期待値）	テストの狙い
下限の境界 （20歳）	19歳（直前）	無効（エラー）	`20 <=` であるべきが `19 <=` になっていないか
	20歳（境界値）	有効（正常）	`20 <=` であるべきが `20 <` になっていないか
上限の境界 （60歳）	60歳（境界値）	有効（正常）	`<= 60` であるべきが `< 60` になっていないか
	61歳（直後）	無効（エラー）	`<= 60` であるべきが `<= 61` になっていないか

1. 理解のコツ:
・まずグループ分け（同値分割）を行い、そのグループの「端っこ（ギリギリ合格する値）」と「その一歩外側（ギリギリ不合格になる値）」のペアをセットでテストするのが基本です。

2. 試験対策の視点:
・問題文に「条件判定の誤りを防ぐ」「ループの終了条件」「直前、直後の値でテスト」「限界値」と来たら、迷わず境界値テスト（限界値分析）を選択しましょう！
・同値クラスの代表値を1つ選ぶ「同値分割法」とセットで出題されることが多いため、両者の違い（代表値を選ぶか、端とその前後を選ぶか）を意識しておくことが大切です。

---

4. まとめ

同値クラスの境界線上にある値と、その直前・直後の値をテストデータとして抽出し、分岐・ループ等の判定ミスを防ぐ手法。これが境界値テスト（限界値分析）です。実装時の初歩的バグを最も効率よく検出できるテスト技法として必ず押さえておきましょう！

【システム開発技術】画面の「骨組み・構造」を可視化する設計図！「ワイヤーフレーム」｜情報処理問題1000本ノック

基本情報技術者試験、応用情報技術者試験、WebUI/UXデザイン分野で超頻出の画面設計用表現手法。「ワイヤーフレーム（Wireframe）」の定義と、前回学習した「ストーリーボード」や他のデザイン試作ツールとの違いを攻略しましょう。

1. 【 問題 】：テクノロジ系（システム開発手法・画面設計）

【 問題 】 Webサイトやモバイルアプリケーションの画面開発において、本格的なビジュアルデザインやプログラミングに入る前段階で、画面の各要素（ヘッダー、ボタン、テキスト、画像枠など）の配置や主要部分のレイアウト構造をシンプルに示す設計図（骨組み）はどれか。

（ア）ワイヤーフレーム（Wireframe）
（イ）モックアップ（Mockup）
（ウ）ストーリーボード（Storyboard）
（エ）サイトマップ（Sitemap）

2. 正解：

正解：（ア）ワイヤーフレーム（Wireframe）

3. 解説：「『画面のどこに何を置くか』を決める骨組み設計図！」

ワイヤーフレーム（Wireframe）は、直訳すると「針金の枠組み」という意味の通り、色や装飾を省いたモノクロに近いシンプルな画面レイアウトのレイアウト図です。
「何がどこに置かれるか」というレイアウトと情報構造だけに集中して議論できるため、仕様の行き違いを早期に防ぐことができます。

【画面設計・デザインツールの比較】 ← 超頻出・混同注意ポイント！

用語・試作成果物	概要・主な目的
（ア）ワイヤーフレーム	画面のレイアウト・構造（骨組み）を示す設計図。色や装飾は省く。
（イ）モックアップ	配色やフォント、写真などを反映した完成後の見た目（静止画ビジュアル）を再現した見本。
プロトタイプ（狭義）	実際のボタンクリックや画面遷移などの動的な操作感（インタラクション）を試せる試作版。
（ウ）ストーリーボード	ユーザーの状況や利用の流れをシナリオやコマ割り文章（物語）で表現したプロトタイプ。

1. 理解のコツ:
・「家づくり」で例えると、ワイヤーフレームは「間取り図（どこに部屋やドアがあるか）」、モックアップは「外観・内装のパース図（どんな色や壁紙か）」、プロトタイプは「モデルハウス（実際にドアを開け閉めできる）」にあたります。

2. 試験対策の視点:
・問題文に「画面の主要部分の構造」「レイアウト」「配置を示す設計図」「骨組み」と来たら、迷わずワイヤーフレームを選択しましょう！

---

4. まとめ

Web画面などの情報要素のレイアウトや主要部分の構造を表すレイアウト設計図。これがワイヤーフレームです。見た目（ビジュアル）を再現する「モックアップ」や、動作を伴う「プロトタイプ」との役割の違いを整理しておきましょう！

【システム開発技術】ユーザー利用体験をシナリオ化する文書プロトタイプ！「ストーリーボード」｜情報処理問題1000本ノック

応用情報技術者試験やITサービスマネジメント、アジャイル開発・UXデザイン（ユーザー体験設計）の分野で出題される重要手法。「ストーリーボード」の定義と、他のプロトタイピング手法との違いを整理して攻略しましょう。

1. 【 問題 】：テクノロジ系（システム開発手法・UXデザイン）

【 問題 】 システムの要求定義や初期デザインにおいて、ビジネスや市場からの要件を、ユーザーがシステムを利用する際の一連のストーリー（利用例のシナリオやスケッチ）として記述・提示する文書形式のプロトタイプ手法はどれか。

（ア）ペルソナ（Persona）
（イ）ストーリーボード（Storyboard）
（ウ）ペーパープロトタイピング（Paper Prototyping）
（エ）ワイヤーフレーム（Wireframe）

2. 正解：

正解：（イ）ストーリーボード（Storyboard）

3. 解説：「『利用シーンの物語』で関係者の認識を合わせる！」

ストーリーボードは、映画やアニメの「コンテ（場面割り）」のように、システムが「いつ・どこで・誰に・どのように使われるか」という利用シナリオやコンテキストを時系列の物語形式で描いた文書手法です。
UI画面そのもののデザインを行う前に、プロダクトが提供する「体験価値」について開発者とステークホルダー（顧客・事業担当者）の間で認識を一致させるために用いられます。

【システム設計・UX関連用語の比較】 ← 超頻出ポイント！

手法・用語	概要と目的
（イ）ストーリーボード	利用者の状況・行動・意識の変化をシナリオやコマ割り画像などの文書形式で表現するプロトタイプ。要件の妥当性を確認する。
（ア）ペルソナ	ターゲットとなる象徴的な架空のユーザー像（年齢・職業・価値観など）。ストーリーの主人公となる。
（ウ）ペーパープロトタイピング	紙に手描きしたUI画面を操作してもらい、操作性や画面遷移を簡易検証する手法。
（エ）ワイヤーフレーム	画面のレイアウトや要素の配置を示す概略設計図（骨組み）。

1. 理解のコツ:
・「画面をどう配置するか」ではなく「ユーザーがどういう場面でどんな課題を解決するか（利用シナリオ）」に焦点を当てた文章・スケッチのプロトタイプがストーリーボードです。

2. 試験対策の視点:
・問題文に「文書形式のプロトタイプ」「ビジネス・市場からの要件」「利用例のシナリオとして記述」とあれば、迷わずストーリーボードを選択しましょう！

---

4. まとめ

ビジネスやマーケット要件を、実際の利用シナリオに落とし込んで提示する文書プロトタイプ。これがストーリーボードです。開発前の段階で価値共有を図る重要手法として覚えておきましょう！

【システム開発管理】特定メーカーへの過度な依存リスク！「ベンダーロックイン」｜情報処理問題1000本ノック

ITパスポート、基本情報技術者試験、応用情報技術者試験、ITストラテジスト試験の戦略・システム設計分野で頻出の重要キーワード。「ベンダーロックイン」の定義と、発生原因、回避策（オープン技術や標準化）を攻略しましょう。

1. 【 問題 】：ストラテジ系（IT戦略・システム調達管理）

【 問題 】 システムの調達や運用管理における記述です。特定ベンダーの独自の技術仕様やデータ形式にシステムが依存してしまった結果、システム変更や他社製品への乗り換え（移行）にかかる費用・工数が膨大となり、実質的にそのベンダーから契約を変更することが困難になる状態は、次のうちどれか。

（ア）マルチベンダー（Multi-vendor）
（イ）ベンダーロックイン（Vendor Lock-in）
（ウ）SLA（Service Level Agreement）
（エ）ベンダーマネジメント（Vendor Management）

2. 正解：

正解：（イ）ベンダーロックイン（Vendor Lock-in）

3. 解説：「『囲い込まれて（Lock-in）』他社へ動けなくなる！」

ベンダーロックインに陥ると、価格交渉力を失って高額な維持費を払い続けざるを得なくなったり、そのベンダーの製品開発がストップした際に自社のシステム刷新も滞るという大きな経営リスクを抱えることになります。

【ベンダーロックインの発生原因と対策】 ← 超頻出ポイント！

区分	具体的な要因・施策内容
発生原因	・ベンダー独自の独自規格やAPI、暗号化仕様の採用。 ・仕様書やドキュメントが整っておらず、ブラックボックス化している。 ・データ出力形式が独自仕様で、他システムへ移行できない。
回避・防止策	・標準化されたオープンな技術（OSSや標準APIなど）の採用。 ・複数ベンダーの製品を組み合わせる「マルチベンダー構成」。 ・調達時にシステム仕様書やデータ移行手続きを明文化しておく。

1. 理解のコツ:
・用語のイメージ：「鍵（Lock）をかけられて、箱の中に閉じ込められた（In）」状態です。
・対義語・対策概念として、複数のベンダーの製品を自由に組み合わせてシステムを構築する「マルチベンダー」があります。

2. 試験対策の視点:
問題文に「特定ベンダーに依存」「他社製品への移行が困難」「独自の技術仕様」「乗り換えコスト（スイッチングコスト）が高い」と来たら、迷わずベンダーロックインを選択しましょう！

---

4. まとめ

特定のITベンダーの独自仕様や製品に依存し、他社製品や別システムへの変更・乗り換えが著しく困難になる状態。これがベンダーロックインです。発生原因や、回避策である標準化・オープン技術の活用とセットで完璧に覚えておきましょう！

【ソフトウェア開発管理】開発の進捗を毎日同期する15分間！「デイリースクラム」｜情報処理問題1000本ノック

「デイリースクラム」の定義・時間（15分）・目的を攻略しましょう。

1. 【 問題 】：ソフトウェア開発系（アジャイル開発・スクラム）

【 問題 】 アジャイル開発のフレームワークであるスクラム（Scrum）において定義されているイベントに関する記述です。開発チームが毎日の活動を同期し、スプリントゴール達成に向けた今後24時間の作業計画を立てるために行う「15分間」のタイムボックス化されたイベントは、次のうちどれか。

（ア）スプリントレトロスペクティブ（振り返り）
（イ）デイリースクラム（デイリースタンドアップ）
（ウ）スプリントプランニング（計画立案）
（エ）スプリントレビュー（成果確認）

2. 正解：

正解：（イ）デイリースクラム（デイリースタンドアップ）

3. 解説：「『15分厳守』でチームの歩調を合わせる！」

デイリースクラムは、チームの透明性を高め、計画からのズレや課題を早期に発見するために毎日実施されます。
長時間の雑談や詳細な議論に脱線するのを防ぐため、「15分」という厳格なタイムボックス（時間制限）が設定されており、立ったまま行うこと（朝会・スタンドアップミーティング）もよく推奨されます。

【スクラムにおける主要な4つのイベント比較】 ← 超頻出ポイント！

イベント名	開催タイミング・時間枠	主な目的・実施内容
（イ）デイリースクラム	毎日実施（15分固定）	活動の同期、今後24時間の計画作成、障害・課題の早期共有。
（ウ）スプリントプランニング	スプリントの開始時	今回のスプリントで「何を」「どのように」作るかの計画を立てる。
（エ）スプリントレビュー	スプリントの終了直前	完成したプロダクト（増分）をステークホルダーに披露しフィードバックを得る。
（ア）レトロスペクティブ	スプリントの最終盤	チームのプロセスや関係性を「振り返り」、次の改善案（KPT等）を決める。

1. 理解のコツ（デイリースクラムの3つの質問）:
伝統的なデイリースクラムでは、各メンバーが以下の3点を手短に話します。
①「昨日、チームのゴール達成のために何をしたか？」
②「今日、チームのゴール達成のために何をするか？」
③「ゴール達成を阻害している障害（問題点）はあるか？」

2. 試験対策の視点:
問題文に「毎日」「15分のタイムボックス」「活動の同期」「今後24時間の計画作成」「障害の共有」と出たら、迷わずデイリースクラムを選択しましょう！

---

4. まとめ

活動の同期と日々の計画作成のために毎日15分のタイムボックスで実施されるスクラムイベント。これがデイリースクラムです。「15分間という制限時間」と「活動の同期・計画」という目的をセットでしっかりマスターしておきましょう！

【ソフトウェア開発管理】老朽化したメインフレームを最新環境へ！「レガシーマイグレーション」｜情報処理問題1000本ノック

ITパスポート、基本情報技術者試験、応用情報技術者試験、ITストラテジスト試験の戦略・システム設計分野で頻出の必須キーワード。「レガシーマイグレーション」の定義と、移行手法である「4つのR（リホスト・リプラットフォーム・リファクタリング・リプレース）」を攻略しましょう。

1. 【 問題 】：ソフトウェア開発管理

【 問題 】 企業システム戦略における記述です。メインフレームやオフコンなどの老朽化・ブラックボックス化した旧来のシステム（レガシーシステム）上の資産や業務ロジックを活かしつつ、クラウド基盤やオープンシステムなどの最新のIT環境へ移行・再構築する取り組みは、次のうちどれか。

（ア）レガシーマイグレーション
（イ）リバースエンジニアリング
（ウ）ベンダーロックイン
（エ）シャドーIT

2. 正解：

正解：（ア）レガシーマイグレーション

3. 解説：「『2025年の崖』を突破するIT基盤の脱皮！」

レガシーマイグレーションは、高額な維持費（保守コスト）や技術者不足、DX推進の足枷となっている古いシステムを解体・刷新し、最新のクラウド環境等へ安全に移し替える（マイグレーションする）プロセスです。

【レガシーマイグレーションの主な4つの移行アプローチ】 ← 超頻出ポイント！

手法・アプローチ	概要・特徴	コスト・難易度
1. リホスト（Re-host） （リホスティング）	プログラムやデータを大きく変更せず、既存のアプリケーションをそのままオープン環境やクラウド（VM等）へ移植する（「リフト＆シフト」の『リフト』）。	低コスト・短期間
2. リプラットフォーム	OSやデータベースなどの基盤（ミドルウェア）を最新版・クラウドサービス（PaaS等）へ変更して移行する。	中コスト
3. リファクタリング	外部から見た動作を変えずに、プログラムコードを最新言語へ書き直したり内部構造をきれいに整理する。	中〜高コスト
4. リプレース（Re-place） （リビルド）	旧システムを捨て、SaaSの利用やゼロからのスクラッチ開発で新システムを完全に作り直す。	高コスト・長期間

1. 理解のコツ: 用語の解体で覚えましょう。
・Legacy（過去の遺産・老朽化システム） を Migration（移行・引越し） するから レガシーマイグレーション です。
・高額な汎用機（メインフレーム）の保守費用を削減し、クラウドの拡張性（スケーラビリティ）を得ることが最大の目的です。

2. 試験対策の視点:
問題文に「メインフレームや汎用機」「旧来のシステム資産を最新のオープン環境へ移行」「2025年の崖対策」「リホスト／リプレース」と出たら、迷わずレガシーマイグレーションを選択しましょう！

---

4. まとめ

メインフレームなどの古いシステム（レガシーシステム）を、クラウドをはじめとする最新のオープン環境へ移行・刷新する取り組み。これがレガシーマイグレーションです。移行アプローチ（リホストやリプレース）の意味も含めてセットでしっかりマスターしておきましょう！

【ソフトウェア開発技術】特定アプリケーション領域の処理を最適化する設計思想！「ドメイン固有アーキテクチャ（DSA）」｜情報処理問題1000本ノック

ディープラーニング、画像処理、データベース検索など、特定のソフトウェア処理（ドメイン）の要求に合わせて、ドメイン固有言語（DSL）・コンパイラ・命令セット・システム構造を最適化する最新の技術概念「ドメイン固有アーキテクチャ（DSA）」を攻略しましょう。

1. 【 問題 】：ITトレンド・システムアーキテクチャ系

【 問題 】 システムアーキテクチャおよびソフトウェア設計に関する記述です。従来の汎用的なプログラム実行モデルとは異なり、AI（機械学習）や画像処理など「特定のアプリケーション・ドメイン（利用領域）」のソフトウェアアルゴリズムやデータフローに特化して、プログラミング言語・コンパイラ・計算構造全体を最適化する設計概念は、次のうちどれか。

（ア）マイクロサービスアーキテクチャ
（イ）ドメイン固有アーキテクチャ（Domain-Specific Architecture）
（ウ）サービス指向アーキテクチャ（SOA）
（エ）イベント駆動型アーキテクチャ（EDA）

2. 正解：

正解：（イ）ドメイン固有アーキテクチャ（Domain-Specific Architecture）

3. 解説：「『特定ソフトウェアの処理能力』を極限まで引き出す設計手法！」

ドメイン固有アーキテクチャ（DSA）は、ヘネシー＆パターソン教授（コンピュータアーキテクチャの世界的権威）らが提唱した概念です。
単に汎用チップを作るのではなく、特定のソフトウェア・ドメイン（用途）で使われるアルゴリズムやデータ構造を理解し、そのソフトが最も効率よく動くための言語・ツールチェーン・命令セットを一体で提供・設計する考え方を指します。

【DSA（ドメイン固有アーキテクチャ）を構成する要素】 ← ソフトウェア視点での整理！

構成レイヤ	DSAにおける役割と具体例
1. ドメイン固有言語（DSL）	特定のソフトウェア表現（AIのテンソル計算や画像記述など）に特化した記法やライブラリ（PyTorch, Halide等）。
2. 専用コンパイラ・IR	DSLで書かれたソフトウェアのコードを解析・最適化し、専用の実行命令に変換する仕組み（LLVM基盤等）。
3. 専用計算構造	ソフトウェアのデータフロー（行列演算や並列処理）を詰まらせずに高速実行する専用の処理回路。

1. 理解のコツ:
・「何でも動く汎用システム」は限界を迎えているため、「特定のソフトウェア処理（ドメイン）を超高速で動かすために、ソフトからシステム全体を専用設計する（DSA）」というアプローチが現代のIT技術のトレンドになっています。

2. 試験対策の視点:
問題文に「特定のアプリケーション・ドメイン向け」「汎用目的ではない」「特定用途（AIや画像等）の処理に特化して作られた」といった表現が出たら、迷わずドメイン固有アーキテクチャ（DSA）を選択しましょう！

---

4. まとめ

汎用目的ではなく、特定のアプリケーション・ドメインのソフトウェア処理に特化して全体を最適化する設計概念。これがドメイン固有アーキテクチャ（DSA）です。正確な概念としてアップデートしておきましょう！ご指摘ありがとうございました！

【ソフトウェア開発】本番環境でユーザーに気づかれずにテストする！「ダークローンチ」｜情報処理問題1000本ノック

アジャイル開発やDevOps、CI/CDの文脈で非常に重要視されるリリース戦略。「ダークローンチ」の定義と、カナリアリリースや機能フラグ（Feature Flag）との関係性を攻略しましょう。

1. 【 問題 】：ソフトウェア工程・システム開発（DevOps・デプロイ戦略）

【 問題 】 システムのリリース手法に関する記述です。新機能や新システムを本番環境にデプロイするが、機能フラグ（Feature Flag）やUIの制御などを用いてエンドユーザーには非表示（または機能無効）にしておき、バックエンドの挙動や負荷への耐久性を本番環境上で安全に検証・テストする手法は、次のうちどれか。

（ア）カナリアリリース（Canary Release）
（イ）ブルーグリーンデプロイメント（Blue-Green Deployment）
（ウ）ダークローンチ（Dark Launch）
（エ）シャドーIT（Shadow IT）

2. 正解：

正解：（ウ）ダークローンチ（Dark Launch）

3. 解説：「『デプロイ（配置）』と『リリース（公開）』を分離する！」

ダークローンチは、本番環境のリアルなトラフィックやデータを使って新機能を稼働させ、パフォーマンス測定やエラー検出を行う手法です。
一般ユーザーには見えず影響がない（暗闇の中で動かす＝Dark）ため、仮に裏側で不具合が発生してもユーザー体験を損なうことがありません。

【試験で紛らわしい代表的なリリース・デプロイ手法の比較】 ← 超重要！

手法名	ユーザーへの露出・切り替え方法	主な目的・特徴
（ウ）ダークローンチ	本番に配置するがユーザーには「見せない（0%）」か特定のテストユーザーのみに表示。	本番環境の負荷・裏側の挙動をユーザーリスクゼロで検証する。
（ア）カナリアリリース	全ユーザーの数%（一部）だけに先行公開し、徐々に割合を増やしていく。	新バージョンの不具合発生時の影響範囲（障害範囲）を最小限にする。
（イ）ブルーグリーンデプロイメント	旧環境（Blue）と新環境（Green）を並行して用意し、ルーター等で一気に切り替える。	ダウンタイム（停止時間）ゼロで即座に切り替え・切り戻し（ロールバック）を行う。

1. 理解のコツ:
・「フィーチャーフラグ（Feature Flag）」という技術とセットでよく使われます。
・スイッチ（Flag）を「OFF」にしたまま本番環境にプログラムコードを配置（デプロイ）しておき、裏でテストを実施。準備や動作確認が完璧に終わったら、スイッチを「ON」にして一瞬でユーザーに公開します。

2. 試験対策の視点: アジャイル開発やDevOps、システム移行（基幹システムの置換など）で注目されるテーマです。
問題文に「本番環境にデプロイ」「ユーザーから隠す/見えない」「裏側で負荷や挙動を検証」「機能フラグ（Feature Flag）」といったキーワードが出たら、迷わずダークローンチを選択しましょう！

---

4. まとめ

本番環境にコードを配置しつつ、ユーザーには非表示の状態で裏側の挙動やパフォーマンスを検証するリリース手法。これがダークローンチです。カナリアリリースやブルーグリーンデプロイメントとの違いも含めてマスターしておきましょう！

【ソフトウェア開発技術】処理の流れ（分岐・反復）を網羅！「制御フローテスト」｜情報処理問題1000本ノック

プログラム内部のソースコードや構造に着目して行うホワイトボックステスト。処理の実行経路（制御フロー）に沿って網羅的に検証を行う「制御フローテスト」の概念とカバレッジ（網羅率）を攻略しましょう。

1. 【 問題 】：ソフトウェア開発技術（テスト設計技法・ホワイトボックステスト）

【 問題 】 ソフトウェア開発技術におけるホワイトボックステストの設計技法に関する記述です。プログラムの内部構造を分析し、処理の実行順序や条件分岐、繰り返し処理などの「制御の流れ（制御フローグラフ）」に基づいてテスト経路を決定し、そのルートを正しく通過するかを確認するテスト技法を何と呼ぶでしょうか？

（ア）制御フローテスト（Control Flow Testing）
（イ）データフローテスト（Data Flow Testing）
（ウ）境界値分析（Boundary Value Analysis）
（エ）状態遷移テスト（State Transition Testing）

2. 正解：

正解：（ア）制御フローテスト（Control Flow Testing）

3. 解説：「プログラムの迷路」をすり抜けるルート決め！

制御フローテスト（Control Flow Testing）は、プログラムのソースコード内に存在する「if文（分岐）」や「for/while文（繰り返し）」といった処理の流れ（制御フロー）に注目し、あらかじめ作成した**制御フローグラフ（フローチャートのような図）**をもとにテストケースを作成する手法です。
どれだけのルートを通過させたかを表す指標として「網羅率（カバレッジ）」が用いられます。

【制御フローテストで問われる「3大カバレッジ基準」】 ← ココが試験の超重要ポイント！

カバレッジ名	網羅する対象（目指すゴール）
① 命令網羅（C0：ステートメントカバレッジ）	すべての「命令（処理文）」を少なくとも1回は実行させる。
② 分岐網羅（C1：ブランチカバレッジ）	すべての「分岐（真/偽の両方の矢印）」を少なくとも1回は通過させる。
③ 条件網羅（C2：ディシジョンカバレッジ）	分岐条件の中にある「個々のサブ条件式（A>0 や B==1 など）」の真・偽の組み合わせをすべて網羅する。

1. 理解のコツ: 「ダンジョンの地図（迷路）の探索」に例えてみましょう。
・プログラムはスタートからゴールまでの迷路です。途中には「右へ進むか、左へ進むか」の分岐（if文）や「同じ場所をぐるぐる回る」ループ（for文）があります。
・制御フローテストは、このダンジョンの地図を開き、「すべての宝箱（命令）を回収できる最短ルートはどこか」「右の道も左の道（分岐）も両方一度は歩いたか」と、道順（フロー）に注目して探索計画を立てるテスト手法です。

2. 試験対策の視点: ソフトウェア開発技術分野のホワイトボックステストにおいて超基本となる重要ワードです。
問題文の中に「内部構造」「制御の流れ」「フローグラフ」「命令網羅・分岐網羅」といったキーワードがあれば、即座に制御フローテストを選べるようにしておきましょう。
※選択肢の（イ）データフローテストは「変数の定義と参照の追跡」、（エ）状態遷移テストは「状態の変化（ステート）」に着目する手法であり、明確に区別できます。

---

4. まとめ

「プログラム内部の処理順序や分岐などの『制御の流れ』に着目し、命令網羅や分岐網羅といった基準でルートをテストする技法」。これが制御フローテストです。ホワイトボックステストの王道手法として、各カバレッジの定義とセットでしっかり記憶しておきましょう！