このページの目的は、ITストラテジスト「午前Ⅱ（専門知識）」で押さえておきたい頻出語を、1語＝定義（1行）＋ひっかけ＋午後で使える1文に圧縮しました。
- 学習の順序：午前Ⅱの語彙を固め、午後に突破の布石とする → 午後（科目B）頻出論点 一問一答
- 全体戦略（勉強時間・難易度・合格率）：ITストラテジストとは？（総合ガイド）
- 使い方：過去問で見た語をこのページで検索（Ctrl+F）→「定義1行＋ひっかけ」だけ拾えばOKです。
1. 事業環境分析・競争戦略（10）
SWOT分析
定義：強み・弱み・機会・脅威を整理し、戦略オプションを導く枠組み。
午前Ⅱのひっかけ：
- 内部（S/W）と外部（O/T）の取り違え。
- 分析で終わり、戦略（SO/WO/ST/WT）に落ちない。
午後での使い所：「SWOTで課題を特定し、CSF/KPIに落として施策と効果測定を設計する。」
関連記事：総合ガイド／午後一問一答／関連：PEST・5フォース・VRIO
PEST分析（参考：PESTEL分析）
定義：政治・経済・社会・技術のマクロ環境変化を整理する分析。
午前Ⅱのひっかけ：
- 業界内の競争（5フォース）と混同。
- 列挙で終わり、機会/脅威に接続しない。
午後での使い所：「PESTの変化（規制/技術）を前提に、ロードマップと投資優先度を決める。」
関連記事：総合ガイド／午後一問一答／関連：SWOT・5フォース
ファイブフォース（5 Forces）
定義：業界収益性を「新規参入・代替・買い手・売り手・競争」の5要因で見る。
5フォースの要素と呼び方
ポーターが提唱したこのフレームワークは、業界の「収益性（儲かりやすさ）」を決定する5つの圧力を分析するものです。
| 要素名（日本語） | 要素名（英語） | 内容のポイント |
| 既存競合者同士の敵対関係 | Industry Rivalry | 同業者とのシェア争い。価格競争が激しいと利益が減る。 |
| 新規参入者の脅威 | Threat of New Entrants | 異業種やベンチャーが参入してくる壁（参入障壁）の高さ。 |
| 代替品の脅威 | Threat of Substitutes | 既存製品を「不要にする」別カテゴリの製品。 |
| 買い手の交渉力 | Bargaining Power of Buyers | 顧客（販売先）の強さ。値引きを迫られる力。 |
| 売り手の交渉力 | Bargaining Power of Suppliers | 部品メーカーやクラウドベンダーなどの強さ。仕入価格を上げられる力。 |
勘違いしないための3つのコツ
試験中に「あれ、どっちが脅威だっけ？」となったら、以下の視点を思い出してください。
1. 「交渉力」は「自分たちが苦しくなる方」が脅威
一番多いミスが、買い手（顧客）の力が強くなったときに「売上が上がる」と勘違いすることです。
-
買い手が強い ＝ 「安くしないと買わないよ」と言われる ＝ 自社の利益が減る（脅威）。
-
売り手が強い ＝ 「高く買わないなら売らないよ」と言われる ＝ 自社のコストが上がる（脅威）。
コツ： 常に「相手がワガママを言える立場かどうか」で考えましょう。
2. 「競合」と「代替品」をハッキリ分ける
ここも混同しやすいポイントです。
-
競合： 同じ土俵のライバル（例：コカ・コーラ vs ペプシ）
-
代替品： 土俵そのものを変えてしまうもの（例：コーラ vs コンビニのコーヒー、あるいは「喉を潤す」ためのスマホゲームへの課金時間）
コツ： 「ユーザーがその製品を買わなくて済むようになる別の手段」が代替品です。
3. 分析の目的は「自社の弱点探し」ではない
5フォースは、自社の強み・弱み（SWOT）を出すためのものではなく、「その業界がそもそも儲かる場所なのか？」という構造を客観視するためのものです。
-
全ての矢印（圧力）が自分たちに向かっているイメージを持つと、理解がブレません。
ITストラテジスト試験での対策
ST試験では、午後Ⅰ（記述式）や午後Ⅱ（論文）において、「デジタル技術（DX）が5つの力にどう影響を与えたか」という文脈でよく出題されます。
-
新規参入： クラウドの普及で初期投資が下がり、参入障壁が低くなった。
-
買い手の交渉力： 比較サイトの普及で、顧客が価格を比較しやすくなり、買い手の力が強まった。
-
代替品： SFA/CRMの導入により、従来の「足で稼ぐ営業」がデジタルツールに置き換わった。
午前Ⅱのひっかけ：
- 自社の強み弱み（SWOT）と混同。
- 「競争」だけ見て他4要因を落とす。
午後での使い所：「5フォースで構造要因を整理し、差別化/コスト優位に効くIT施策を選ぶ。」
関連記事：総合ガイド／午後一問一答／関連：PEST・バリューチェーン
3C分析
定義：顧客（Customer）・競合（Competitor）・自社（Company）で戦略の前提を揃える。
午前Ⅱのひっかけ：
- 市場（環境）と顧客の混同、競合不在の分析。
- 分析結果がSTPや施策に繋がらない。
午後での使い所：「3Cで前提を揃え、ターゲット/提供価値/差別化要因を一貫させる。」
関連記事：総合ガイド／午後一問一答／関連：STP・ターゲティング
STP
定義：セグメント化→ターゲット選定→ポジショニングで市場攻略の骨格を作る。
午前Ⅱのひっかけ：
- セグメンテーションとターゲティングの境界が曖昧。
- ポジショニングが「価格」だけになる。
午後での使い所：「STPを明確化し、KPIと顧客価値（提供機能/UX）を整合させる。」
関連記事：総合ガイド／午後一問一答／関連：セグメンテーション・ポジショニング
セグメンテーション
定義：市場を意味のある基準で分割し、異なるニーズ群を可視化する。
午前Ⅱのひっかけ：
- 「分ける」だけで、測定可能/到達可能などの条件を落とす。
- ターゲット選定（評価・選択）と混同。
午後での使い所：「セグメント別の課題差を踏まえ、優先ターゲットへ施策を集中する。」
関連記事：総合ガイド／午後一問一答／関連：ターゲティング・STP
ターゲティング
定義：魅力度と自社適合を評価し、狙うセグメントを選ぶ意思決定。
午前Ⅱのひっかけ：
- 「誰に」だけで「なぜ勝てるか」（優位性根拠）が抜ける。
- ポジショニング（提供価値の位置づけ）と混同。
午後での使い所：「ターゲットの課題に合わせ、CSF/KPIとIT施策（機能・業務）を整合させる。」
関連記事：総合ガイド／午後一問一答／関連：ポジショニング・KPI
ポジショニング
定義：ターゲットにおける「選ばれる理由」を競合比較で明確化する。
午前Ⅱのひっかけ：
- 差別化軸が曖昧（誰に/何で/なぜ）を落とす。
- 機能列挙だけで顧客価値に繋がらない。
午後での使い所：「ポジショニングを起点に、業務・データ・システムの優先度を決める。」
バリューチェーン
定義：主活動・支援活動に分け、どこで価値/コストが生まれるかを特定する。
午前Ⅱのひっかけ：
- 活動の羅列で終わり、優位性（差別化/コスト）に繋がらない。
- 業務プロセス（BPM）と混同して目的がズレる。
午後での使い所：「価値が出る工程にデータ/IT投資を集中し、KPIで効果を検証する。」
関連記事：総合ガイド／午後一問一答／関連：5フォース・BPR
VRIO
定義：資源・能力が価値/希少/模倣困難/組織活用の条件を満たすかで競争優位を判断。
午前Ⅱのひっかけ：
- 「価値がある」だけで競争優位と誤判定。
- O（組織）が抜け、実行体制の論点を落とす。
午後での使い所：「強み（資源）をVRIOで裏付け、実行組織とガバナンスを設計する。」
関連記事：総合ガイド／午後一問一答／関連：SWOT・ITガバナンス
2. 戦略実行・指標（10）
KGI
定義：最終的に達成したい成果指標（ゴール）を数値で定義したもの。
午前Ⅱのひっかけ：
- プロセス指標（KPI）をKGIと誤る。
- 測定不能・期限なしで“目標”になっていない。
午後での使い所：「KGI→KPI→施策→データ収集の順で、効果測定可能な計画に落とす。」
関連記事：総合ガイド／午後一問一答／関連：KPI・KPIツリー
KPI
定義：KGI達成に効く途中経過（プロセス）を測る指標。
午前Ⅱのひっかけ：
- 成果（売上など）だけでKPIを作り、行動に落ちない。
- 指標が多すぎて“管理不能”になる。
午後での使い所：「KPIを業務・ITの両面に割り当て、責任部署と測定方法まで定義する。」
関連記事：総合ガイド／午後一問一答／関連：KGI・CSF・KPIツリー
CSF（重要成功要因）
定義：成果を出すために「ここが決まれば勝ち」が成立する要因。
午前Ⅱのひっかけ：
- CSF（要因）とKPI（指標）を混同。
- 抽象的すぎて施策・データに落ちない。
午後での使い所：「CSF→KPI→施策→データ収集を一気通貫で設計する。」
OKR
定義：達成したい目的（Objective）と成果指標（Key Results）で目標管理する手法。
午前Ⅱのひっかけ：
- KPI（運用管理）とOKR（挑戦目標）の性質差を混同。
- KRが活動（ToDo）になってしまう。
午後での使い所：「OKRで方向性を揃え、KPIで運用・効果測定を回す。」
BSC（バランススコアカード）
定義：財務・顧客・業務プロセス・学習成長の4視点で戦略を指標に落とす枠組み。
午前Ⅱのひっかけ：
- 財務指標だけで評価し、4視点を落とす。
- 戦略マップ（因果）とKPI（測定）を分けて考えられない。
午後での使い所：「BSCでKPIを偏らせず、業務・IT・人材の改善をバランスよく設計する。」
PDCA
定義：計画→実行→評価→改善を短サイクルで回す改善プロセス。
午前Ⅱのひっかけ：
- Do偏重でCheck/Actが形骸化。
- KPIが無く、評価（C）ができない。
午後での使い所：「KPIとデータ収集を先に定義し、PDCAが回る運用設計にする。」
KPIツリー
定義：最終指標（KGI）を分解し、因果関係でKPI群を構造化する。
午前Ⅱのひっかけ：
- 分解が“思いつき”で、因果が成立していない。
- 測定単位・頻度・責任者が曖昧。
午後での使い所：「KPIツリーでボトルネックを特定し、改善施策と効果測定を結び付ける。」
ROI
定義：投資に対してどれだけ利益（または効果）が得られたかを示す指標。
午前Ⅱのひっかけ：
- コスト削減/売上増の前提（期間・範囲）が抜ける。
- TCO（総保有コスト）との混同。
午後での使い所：「ROIで投資優先度を説明し、KPIと運用で継続的に効果を検証する。」
TCO（総保有コスト）
定義：導入費だけでなく運用・保守・更新・教育など含めた総コストで評価する考え方。
午前Ⅱのひっかけ：
- 初期費用だけで意思決定し、運用費を落とす。
- ROI（利益側）と混同して比較が崩れる。
午後での使い所：「TCOで運用を含むコストを見積り、効果（KPI/ROI）とセットで説明する。」
関連記事：総合ガイド／午後一問一答／関連：ROI・費用対効果
EVA（経済的付加価値）
定義：税引後営業利益から資本コストを差し引いた“真の付加価値”。
午前Ⅱのひっかけ：
- 会計利益と経済価値（資本コスト控除）の違いを落とす。
- 短期利益だけで評価し、中長期投資を誤る。
午後での使い所：「資本コストも踏まえ、投資効果を中長期で説明できる指標としてEVAを参照する。」
3. ビジネスモデル・DX・業務改革（10）
DX（デジタルトランスフォーメーション）
定義：デジタル技術で業務・組織・ビジネスモデルを変革し、競争優位を作る取り組み。
午前Ⅱのひっかけ：
- IT化（紙→電子化）だけでDXと誤認。
- 「ツール導入」が目的化し、価値（KGI/KPI）に繋がらない。
午後での使い所：「DXの目的（KGI）を定義し、業務改革・データ戦略・ガバナンスまで一体で設計する。」
関連記事：総合ガイド／午後一問一答／関連：データ戦略・BPR・ITガバナンス
ビジネスモデル
定義：「誰に・何を・どう提供し・どう収益化するか」の仕組み。
午前Ⅱのひっかけ：
- 施策（広告・アプリ等）とモデル（収益構造）を混同。
- 顧客価値と収益のつながりが説明できない。
午後での使い所：「提供価値・収益源・コスト構造を明示し、IT投資の優先度を説明する。」
関連記事：総合ガイド／午後一問一答／関連：DX・バリューチェーン・ROI
BPR（Business Process Re-engineering）
定義：既存業務を前提にせず、プロセスを抜本的に再設計して成果を出す改革。
午前Ⅱのひっかけ：
- 部分改善（小改善）をBPRと誤る。
- システム更改＝BPRになり、業務要件が曖昧。
午後での使い所：「As-Is/To-Beでギャップを示し、KPI・体制・段階導入で実行可能性を担保する。」
関連記事：総合ガイド／午後一問一答／関連：As-Is・To-Be・BPM
BPM（Business Process Management）
定義：業務プロセスを可視化し、継続的に設計・実行・改善するマネジメント。
午前Ⅱのひっかけ：
- BPR（抜本改革）と混同し、目的・スコープが崩れる。
- 可視化だけで改善（KPI/統制）が無い。
午後での使い所：「BPMでプロセスを標準化し、KPI・統制・運用をセットで回す。」
関連記事：総合ガイド／午後一問一答／関連：BPMN・業務プロセス
BPMN
定義：業務プロセスを標準記法で表現するモデリング表記（プロセス図の共通言語）。
午前Ⅱのひっかけ：
- 「図を書くこと」が目的化し、KPI・統制に繋がらない。
- 例外処理・分岐・責任境界（レーン）を落とす。
午後での使い所：「BPMNで業務と責任分界を可視化し、統制点と改善点を明確化する。」
関連記事：総合ガイド／午後一問一答／関連：BPM・業務プロセス
As-Is
定義：現状の業務・仕組み・課題を事実ベースで整理した状態。
午前Ⅱのひっかけ：
- 理想や推測が混ざり「現状」が歪む。
- 課題が定性的で、改善効果が測れない。
午後での使い所：「As-Isでボトルネックを定量化し、To-BeとKPIで改善の筋道を示す。」
関連記事：総合ガイド／午後一問一答／関連：To-Be・BPR
To-Be
定義：目指すべき将来像（あるべき業務・仕組み・価値提供の姿）。
午前Ⅱのひっかけ：
- 理想の羅列で、実行手段・移行計画がない。
- KPIが無く、到達判定ができない。
午後での使い所：「To-BeをKPIで定義し、移行ロードマップとリスク対応で実現可能性を示す。」
関連記事：総合ガイド／午後一問一答／関連：As-Is・ロードマップ
業務プロセス
定義：業務の一連の流れ（入力→処理→出力）を、役割と手順として捉えたもの。
午前Ⅱのひっかけ：
- 個別作業（タスク）とプロセス（流れ）を混同。
- 責任分界（誰が）と統制点（チェック）が抜ける。
午後での使い所：「プロセスの標準化と統制点の設計で、品質・リスク・効率を同時に改善する。」
関連記事：総合ガイド／午後一問一答／関連：BPM・BPMN・職務分掌
RPA
定義：定型作業をソフトウェアロボットで自動化し、作業時間・ミスを減らす技術。
午前Ⅱのひっかけ：
- 例外が多い業務に適用し、運用が破綻する。
- BPRせずに自動化して“ムダを高速化”する。
午後での使い所：「RPAはBPRとセットで対象業務を絞り、KPI（工数/品質）で効果測定する。」
生成AI
定義：文章・画像・コード等を生成するAIで、業務の支援・自動化に活用できる。
午前Ⅱのひっかけ：
- 精度（もっともらしさ）と正確性を混同する。
- データ持ち出し・権限・ログ等の統制が抜ける。
午後での使い所：「利用範囲・権限・監査ログ・品質確認（人のレビュー）を設計し、リスクを統制する。」
関連記事：総合ガイド／午後一問一答／関連：ITガバナンス・ログ管理・認証・認可
4. IT戦略・全体最適（10）
IT活用事業戦略
定義：事業戦略を実現するためにITをどう使うか（価値・競争優位に直結する使い方）を定める。
午前Ⅱのひっかけ：
- システム導入計画（手段）だけで、事業価値が不明。
- KGI/KPIが無く、効果が説明できない。
午後での使い所：「事業のCSFを起点に、IT施策・データ・体制を一気通貫で設計する。」
関連記事：総合ガイド／午後一問一答／関連：CSF・KPI・データ戦略
情報システム戦略
定義：IT資産・人材・運用を含め、情報システムをどう構築・活用するかの中長期方針。
午前Ⅱのひっかけ：
- 個別案件の寄せ集めになり、全体最適が無い。
- 標準化・共通化・ガバナンスの論点が抜ける。
午後での使い所：「全体アーキテクチャとロードマップを示し、投資優先度と統制を担保する。」
関連記事：総合ガイド／午後一問一答／関連：アーキテクチャ・ロードマップ・ITガバナンス
全体システム化計画
定義：複数システムを俯瞰し、あるべき全体像・段階移行・投資配分を決める計画。
午前Ⅱのひっかけ：
- 現場要望の優先度付けが無く、泥沼化する。
- データ連携・共通基盤・標準化が抜ける。
午後での使い所：「全体像→段階ロードマップ→ガバナンスで、個別最適の乱立を防ぐ。」
関連記事：総合ガイド／午後一問一答／関連：標準化・共通化・データ戦略
ロードマップ
定義：目標に至るまでの段階・時期・依存関係を示す計画（施策の時系列設計）。
午前Ⅱのひっかけ：
- マイルストーンが無く進捗が測れない。
- 依存関係（前提案件）が抜け、遅延が連鎖する。
午後での使い所：「段階導入の狙いとKPIを各フェーズに紐付け、実行可能性を示す。」
関連記事：総合ガイド／午後一問一答／関連：To-Be・変更管理
標準化
定義：手順・ルール・仕様を統一して、品質・効率・統制を高めること。
午前Ⅱのひっかけ：
- 現場の例外が多く、標準が形骸化する。
- 標準化の目的（品質/コスト/リスク）が曖昧。
午後での使い所：「標準化でプロセスとデータ定義を揃え、監査・運用を容易にする。」
関連記事：総合ガイド／午後一問一答／関連：共通化・ITガバナンス
共通化
定義：機能・基盤・データ・手続きを共通化し、重複投資と運用負荷を減らすこと。
午前Ⅱのひっかけ：
- 共通化で柔軟性が落ちるリスク（例外処理）を無視。
- 全体最適の意思決定（ガバナンス）が無い。
午後での使い所：「共通基盤を整備し、標準化・データ連携・運用統制を同時に効かせる。」
関連記事：総合ガイド／午後一問一答／関連：標準化・アーキテクチャ
アーキテクチャ
定義：システム全体の構造・設計原則・要素間関係（全体設計の骨格）。
午前Ⅱのひっかけ：
- 技術選定だけに寄り、業務・データ・運用の整合が無い。
- 例外が多く、原則が守られない（ガバナンス不足）。
午後での使い所：「標準アーキテクチャで再利用と統制を効かせ、ロードマップで段階移行する。」
関連記事：総合ガイド／午後一問一答／関連：ITガバナンス・全体システム化計画
データ戦略
定義：データを資産として整備・活用し、意思決定・業務・価値提供を強化する方針。
午前Ⅱのひっかけ：
- 「データ集め」だけで、利用目的（KPI）が無い。
- データ定義・品質・権限・責任（ガバナンス）が抜ける。
午後での使い所：「収集→整備→活用→効果測定まで定義し、データ品質と統制を設計する。」
関連記事：総合ガイド／午後一問一答／関連：標準化・ログ管理・ITガバナンス
IT動向分析
定義：技術・市場・規制などの動向を捉え、機会・リスクと投資判断に繋げる分析。
午前Ⅱのひっかけ：
- 流行語の羅列で、事業価値・適用領域が不明。
- リスク（セキュリティ/運用/法務）評価が抜ける。
午後での使い所：「動向を機会/脅威に整理し、ロードマップとガバナンスを前提に適用判断する。」
関連記事：総合ガイド／午後一問一答／関連：PEST・DX・サイバーセキュリティ経営
グリーンIT
定義：ITの利用・運用で省エネ・環境負荷低減を図る取り組み。
午前Ⅱのひっかけ：
- 電力削減だけで、最適化（TCO/運用）視点が抜ける。
- クラウド移行＝必ずグリーン、の短絡。
午後での使い所：「運用コスト（TCO）と環境負荷を指標化し、投資判断と運用設計に落とす。」
関連記事：総合ガイド／午後一問一答／関連：TCO・キャパシティ管理
5. ガバナンス・内部統制・リスク（10）
ITガバナンス
定義：IT投資・運用が事業価値とリスク管理に沿うよう、意思決定と統制の仕組みを整えること。
午前Ⅱのひっかけ：
- ルールだけ作って運用が無い（形骸化）。
- 投資判断（優先度）と統制（監査）が切れている。
午後での使い所：「権限・責任・基準・監査を明示し、全社最適とリスク統制を両立させる。」
関連記事：総合ガイド／午後一問一答／関連：内部統制・監査証跡・サイバーセキュリティ経営
内部統制
定義：業務の適正・効率・法令遵守・財務報告の信頼性を確保する仕組み。
午前Ⅱのひっかけ：
- 「監視」だけで、業務プロセスに統制が組み込まれていない。
- 職務分掌や証跡が無く、検証不能。
午後での使い所：「統制点をプロセスに組み込み、職務分掌・証跡・監査で担保する。」
関連記事：総合ガイド／午後一問一答／関連：J-SOX・職務分掌・監査証跡
J-SOX（内部統制報告制度）
定義：財務報告の信頼性を確保するための内部統制を評価し報告する制度。
午前Ⅱのひっかけ：
- 内部統制全般と同義だと誤る（焦点は財務報告）。
- IT全般統制（ITGC）と業務プロセス統制が混線する。
午後での使い所：「権限管理・変更管理・ログ等のIT統制を明示し、財務報告の信頼性を担保する。」
関連記事：総合ガイド／午後一問一答／関連：認証・認可・ログ管理・変更管理
コンプライアンス
定義：法令・規程・社会規範を遵守し、企業活動の健全性を保つこと。
午前Ⅱのひっかけ：
- ルール整備だけで、教育・監査・是正が無い。
- 委託先・クラウド等の範囲が漏れる。
午後での使い所：「規程・教育・監査・是正を運用プロセスに組み込み、継続的に担保する。」
関連記事：総合ガイド／午後一問一答／関連：個人情報保護・ISMS
リスクアセスメント
定義：リスクを識別し、発生可能性と影響度で評価して優先度を決めること。
午前Ⅱのひっかけ：
- 脅威だけ見て、資産・脆弱性・影響の視点が抜ける。
- 評価して終わり、対応策に落ちない。
午後での使い所：「重要資産のリスクを優先度付けし、統制（回避/低減/移転/受容）を選択する。」
関連記事：総合ガイド／午後一問一答／関連：リスク対応・脆弱性管理
リスク対応（回避・低減・移転・受容）
定義：評価したリスクに対し、対策方針を選ぶフレーム（回避/低減/移転/受容）。
午前Ⅱのひっかけ：
- 低減＝ゼロにする、という誤解（残余リスクが残る）。
- 移転（保険/委託等）でも責任が残る点を落とす。
午後での使い所：「優先度の高いリスクは低減策を実装し、残余リスクは受容基準で管理する。」
関連記事：総合ガイド／午後一問一答／関連：リスクアセスメント・BCP
三線モデル（Three Lines Model）
定義：1線（業務部門）2線（リスク/コンプラ）3線（内部監査）の役割分担で統制する考え方。
午前Ⅱのひっかけ：
- 「監査が全部やる」と誤解し、1線の責任が曖昧。
- 2線のルール策定・助言機能が抜ける。
午後での使い所：「役割分担を明確にし、統制の運用責任と監査の独立性を担保する。」
関連記事：総合ガイド／午後一問一答／関連：ITガバナンス・監査証跡
職務分掌（牽制）
定義：不正や誤りを防ぐため、権限と業務を分離し相互牽制する仕組み。
午前Ⅱのひっかけ：
- 小規模組織で分離不能な場合の代替統制（上長承認等）を落とす。
- 権限（承認）と実務（実行）が同一人物になる。
午後での使い所：「権限分離と承認フロー、ログ証跡で不正リスクを低減する。」
関連記事：総合ガイド／午後一問一答／関連：認証・認可・監査証跡
監査証跡（Audit Trail）
定義：誰がいつ何をしたかを追跡できる記録（ログ等）で、検証可能性を担保する。
午前Ⅱのひっかけ：
- ログが取れても保全（改ざん耐性）や検索性が無い。
- 権限変更や重要操作のログが漏れる。
午後での使い所：「重要操作のログを保全し、監査・不正検知・事後対応を可能にする。」
関連記事：総合ガイド／午後一問一答／関連：ログ管理・J-SOX
サイバーセキュリティ経営（経営視点）
定義：サイバーリスクを経営リスクとして扱い、方針・体制・投資・説明責任を整える考え方。
午前Ⅱのひっかけ：
- 現場任せで、経営の関与（責任・意思決定）が無い。
- インシデント対応だけで、予防・監視・復旧が弱い。
午後での使い所：「経営方針・役割分担・投資判断・監査で、継続的なセキュリティ運用を担保する。」
関連記事：総合ガイド／午後一問一答／関連：ITガバナンス・BCP・ゼロトラスト
6. 投資評価・効果測定（10）
費用対効果
定義：投資コストに対して得られる効果（収益増・コスト減・リスク低減等）を評価すること。
午前Ⅱのひっかけ：
- 効果の範囲・期間・前提が曖昧。
- 定量化できない効果（品質/リスク）を無視して比較が崩れる。
午後での使い所：「効果をKPIに落とし、TCO/NPV等で投資判断の筋を示す。」
関連記事：総合ガイド／午後一問一答／関連：NPV・TCO・KPI
NPV（正味現在価値）
定義：将来キャッシュフローを割引率で現在価値に直し、投資価値を評価する指標。
午前Ⅱのひっかけ：
- 割引率（資本コスト）の意味を落とす。
- キャッシュフローと会計利益を混同する。
午後での使い所：「投資効果を期間と割引率の前提付きで示し、優先度の根拠を明確化する。」
IRR（内部収益率）
定義：NPVが0になる割引率（投資の利回りの目安）。
午前Ⅱのひっかけ：
- 比較対象の規模・期間が違う投資をIRRだけで比較する。
- 複数解や再投資前提など、使いどころの限界を落とす。
午後での使い所：「NPVで意思決定を補強しつつ、IRRは直感的な説明材料として使う。」
回収期間（Payback Period）
定義：投資額を回収するまでに要する期間（回収の速さを見る指標）。
午前Ⅱのひっかけ：
- 回収後の利益（長期価値）を無視する。
- 割引（時間価値）を考慮しない点を落とす。
午後での使い所：「短期の資金制約がある場合の補助指標として使い、NPVと併用する。」
関連記事：総合ガイド／午後一問一答／関連：NPV・費用対効果
ROIC
定義：投下資本に対してどれだけ利益（NOPAT等）を生んだかを見る資本効率指標。
午前Ⅱのひっかけ：
- ROI/ROEと混同し、分母（資本）の意味が崩れる。
- 短期の改善だけ追い、中長期投資を毀損する。
午後での使い所：「資本効率の観点でIT投資の説明を補強し、NPVと併用して妥当性を示す。」
ROE
定義：自己資本に対してどれだけ利益を生んだかを見る指標（株主資本効率）。
午前Ⅱのひっかけ：
- 財務レバレッジで見かけ上上がる点を落とす。
- IT投資評価でROEだけを根拠にする。
午後での使い所：「資本構成の影響に触れつつ、投資評価はNPV/ROIC等で補強する。」
CVP分析（損益分岐点分析）
定義：固定費・変動費・販売量の関係から利益構造や損益分岐点を把握する分析。
午前Ⅱのひっかけ：
- 固定費/変動費の区分が曖昧で計算が崩れる。
- 単価や数量の前提が現実と乖離する。
午後での使い所：「コスト構造を説明し、IT投資による固定費化/変動費化の影響を示す。」
差異分析
定義：計画（予算）と実績の差を要因分解し、改善アクションに繋げる分析。
午前Ⅱのひっかけ：
- 差が出た事実だけで、要因（単価/数量/ミックス）に落ちない。
- 改善責任（誰が何を変えるか）が曖昧。
午後での使い所：「KPIの差異を要因分解し、次の施策（Act）に直結させる。」
ベンチマーク
定義：優良事例や競合の水準を基準に、自社の改善目標やギャップを明確化すること。
午前Ⅱのひっかけ：
- 条件が違う数値を比較して誤判断する。
- ベンチマークの“理由（プロセス）”が掘れない。
午後での使い所：「同条件で比較可能な指標を揃え、目標水準と施策の妥当性を示す。」
関連記事：総合ガイド／午後一問一答／関連：5フォース・KPI
効果指標（業務・IT両面）
定義：業務成果（時間短縮・品質等）とIT成果（性能・可用性等）を測る指標設計。
午前Ⅱのひっかけ：
- IT指標（稼働率等）だけで業務価値が測れない。
- KPIが多すぎて、意思決定に使えない。
午後での使い所：「業務KPIとITKPIを結び、施策の効果を説明可能にする。」
関連記事：総合ガイド／午後一問一答／関連：KPI・可用性管理
7. 調達・契約・ベンダ管理（10）
RFI
定義：情報提供依頼。市場や製品の情報を集めるための問い合わせ。
午前Ⅱのひっかけ：
- RFP（提案依頼）と混同し、要件が固まっていないのに提案要求する。
- 比較観点（評価軸）が無く情報が集約できない。
午後での使い所：「RFIで選択肢を把握し、要件と評価軸を固めてRFPに繋げる。」
関連記事：総合ガイド／午後一問一答／関連：RFP・ベンダ選定
RFP
定義：提案依頼書。要求事項・範囲・評価基準を示し、提案を募る文書。
午前Ⅱのひっかけ：
- 要件が曖昧で比較不能、後から追加が続出する。
- 評価基準が無く、価格だけで選んで失敗する。
午後での使い所：「SOW/SLA/受入基準まで見据えてRFPを整備し、契約不適合を防ぐ。」
関連記事：総合ガイド／午後一問一答／関連：SOW・SLA・受入テスト
提案依頼
定義：ベンダに対し、課題・要求・制約を提示して解決案（提案）を求める行為。
午前Ⅱのひっかけ：
- 課題が整理されず「何でもできますか？」になる。
- 提案の比較観点（評価軸）を欠き、選べない。
午後での使い所：「課題→要求→評価基準を揃え、提案の比較・契約条件まで一貫させる。」
関連記事：総合ガイド／午後一問一答／関連：RFP・ベンダ選定
ベンダ選定
定義：評価基準に基づき、委託先ベンダを比較・選定するプロセス。
午前Ⅱのひっかけ：
- 価格偏重で品質・運用・体制リスクを見落とす。
- PoCの結果を本番品質と誤解する。
午後での使い所：「評価軸（機能・品質・運用・体制・コスト）と受入基準を明示して選定する。」
関連記事：総合ガイド／午後一問一答／関連：SLA・SOW・TCO
SLA
定義：サービスレベル合意。可用性・応答・復旧等のサービス水準を合意する契約要素。
午前Ⅱのひっかけ：
- 測定方法・集計周期・例外条件が無く揉める。
- 運用責任分界（どこまでが誰の責任）が曖昧。
午後での使い所：「可用性・復旧時間・監視体制をSLAで明確化し、運用リスクを低減する。」
SOW
定義：作業範囲記述書。成果物・範囲・体制・前提・除外を明確にする文書。
午前Ⅱのひっかけ：
- 範囲が曖昧で追加要求が止まらない（スコープクリープ）。
- 成果物の品質基準（受入条件）が無い。
午後での使い所：「成果物・範囲・除外・責任分界をSOWに明記し、変更管理で統制する。」
関連記事：総合ガイド／午後一問一答／関連：スコープ管理・変更管理
請負契約
定義：成果物の完成が目的で、完成責任を負う契約形態。
午前Ⅱのひっかけ：
- 準委任と混同し、責任範囲（成果/善管注意）が崩れる。
- 要件変更が多い案件で請負にして紛争化する。
午後での使い所：「成果物と受入基準を明確化し、変更管理で契約リスクを下げる。」
関連記事：総合ガイド／午後一問一答／関連：準委任契約・受入テスト
準委任契約
定義：業務遂行（善管注意義務）が目的で、成果の完成責任は原則負わない契約形態。
午前Ⅱのひっかけ：
- 請負と混同し、成果責任を期待して揉める。
- 作業範囲（SOW）や成果物定義が曖昧で工数膨張する。
午後での使い所：「SOWと体制・役割を明確化し、成果物の定義と検収条件を実務上整える。」
契約不適合責任
定義：引き渡された目的物が契約内容に適合しない場合に、売主等が負う責任（補修等）。
午前Ⅱのひっかけ：
- 瑕疵担保と混同し、要件・仕様の明確化を怠る。
- 受入基準が曖昧で「不適合」を主張できない。
午後での使い所：「要件・SOW・受入テスト基準を明記し、不適合の判断可能性を担保する。」
関連記事：総合ガイド／午後一問一答／関連：受入テスト・RFP
受入テスト
定義：利用者側が、要件・仕様どおりに動くかを確認し受領（検収）するテスト。
午前Ⅱのひっかけ：
- 受入基準が無く「動いたからOK」になる。
- 業務シナリオ（例外・権限）を落として本番で事故る。
午後での使い所：「受入基準を契約文書に明記し、品質・性能・運用要件まで検証する。」
関連記事：総合ガイド／午後一問一答／関連：SLA・請負契約・契約不適合責任
8. プロジェクト・プログラム管理（10）
PMBOK
定義：プロジェクトマネジメントの知識体系（プロセス・領域・原則）をまとめた枠組み。
午前Ⅱのひっかけ：
- 手順の暗記で終わり、実務の統制（スコープ/変更/リスク）に落ちない。
- プロジェクト憲章・ステークホルダーの重要性を落とす。
午後での使い所：「スコープ・変更・リスクを中心に統制設計し、炎上要因を先回りで潰す。」
関連記事：総合ガイド／午後一問一答／関連：スコープ管理・変更管理・リスク管理
WBS
定義：作業を成果物単位で分解し、範囲と責任を明確にする構造（作業分解構成図）。
午前Ⅱのひっかけ：
- タスクの羅列で、成果物が不明（粒度が揃わない）。
- 受入基準や責任者が紐付かない。
午後での使い所：「成果物ベースのWBSでスコープを固定し、変更管理で増殖を防ぐ。」
関連記事：総合ガイド／午後一問一答／関連：スコープ管理・受入テスト
クリティカルパス
定義：遅れるとプロジェクト全体の完了が遅れる、最長の作業経路。
午前Ⅱのひっかけ：
- 余裕（フロート）を見ず、優先順位が誤る。
- 依存関係の定義が曖昧でパスが成立しない。
午後での使い所：「依存関係とクリティカル作業を明確化し、リスク監視と資源配分を最適化する。」
関連記事：総合ガイド／午後一問一答／関連：ロードマップ・リスク管理
EVM（出来高管理）
定義：進捗（出来高）とコストを統合し、計画との差を可視化する管理手法。
午前Ⅱのひっかけ：
- PV/EV/ACの意味が曖昧で指標が使えない。
- 出来高（EV）の定義が主観でぶれる。
午後での使い所：「成果物ベースで出来高を定義し、遅延・超過を早期検知して是正する。」
スコープ管理
定義：プロジェクト範囲（やること/やらないこと）を定義し、統制すること。
午前Ⅱのひっかけ：
- 範囲が曖昧でスコープクリープが起きる。
- 成果物・受入基準が無く、検収できない。
午後での使い所：「WBSと受入基準で範囲を固定し、変更管理で統制する。」
変更管理
定義：要求・仕様・計画の変更を、影響評価と承認プロセスで統制すること。
午前Ⅱのひっかけ：
- 口頭変更が横行し、遅延・品質低下が連鎖する。
- 影響評価（コスト/納期/品質/リスク）が無い。
午後での使い所：「変更要求を一元化し、影響評価→承認→反映→周知で炎上を防ぐ。」
関連記事：総合ガイド／午後一問一答／関連：スコープ管理・ロードマップ
リスク管理（プロジェクト）
定義：プロジェクトの不確実性を識別・評価し、対応策で影響を抑えること。
午前Ⅱのひっかけ：
- リスク登録簿だけ作って運用しない。
- 「問題（発生済）」と「リスク（未発生）」を混同する。
午後での使い所：「重要リスクを早期に潰し、残余リスクは監視KPIと対応策で管理する。」
関連記事：総合ガイド／午後一問一答／関連：リスクアセスメント・問題管理
品質管理
定義：品質要求を満たすために、計画・保証・管理で品質を作り込む活動。
午前Ⅱのひっかけ：
- テストだけで品質を担保できると誤解（上流品質が弱い）。
- 受入基準が曖昧で品質判断ができない。
午後での使い所：「品質要求と受入基準を定義し、レビューとテストで作り込みを担保する。」
関連記事：総合ガイド／午後一問一答／関連：受入テスト・SLA
ステークホルダーマネジメント
定義：利害関係者を識別し、期待・影響力に応じて関与と合意形成を設計すること。
午前Ⅱのひっかけ：
- キーマンが曖昧で意思決定が止まる。
- 期待値調整を怠り、後から要件が増える。
午後での使い所：「影響力と関心で整理し、合意形成の場（会議体）と意思決定ルールを明確化する。」
関連記事：総合ガイド／午後一問一答／関連：変更管理・プログラムマネジメント
プログラムマネジメント
定義：複数プロジェクトを束ね、事業成果（ベネフィット）を実現する管理。
午前Ⅱのひっかけ：
- 単一プロジェクトの延長で扱い、成果（ベネフィット）管理が無い。
- 依存関係・優先度・資源配分が統制できない。
午後での使い所：「ベネフィット/KPIを定義し、ロードマップとガバナンスで全体最適を担保する。」
関連記事：総合ガイド／午後一問一答／関連：全体システム化計画・ITガバナンス
9. サービスマネジメント・運用（10）
ITIL
定義：ITサービスマネジメントのベストプラクティス集（運用の型）。
午前Ⅱのひっかけ：
- 用語の暗記で終わり、運用プロセス設計に落ちない。
- 現場の実態に合わず形骸化する。
午後での使い所：「インシデント・変更・構成を中心に運用プロセスを整備し、SLAを守る。」
関連記事：総合ガイド／午後一問一答／関連：インシデント管理・変更管理（運用）・CMDB
インシデント管理
定義：サービス停止や品質低下を迅速に復旧し、影響を最小化する運用プロセス。
午前Ⅱのひっかけ：
- 原因究明（問題管理）と混同し復旧が遅れる。
- 優先度（影響×緊急度）の判断基準が無い。
午後での使い所：「復旧を最優先しつつ、再発防止は問題管理へ切り分ける。」
問題管理
定義：インシデントの根本原因を分析し、恒久対策で再発防止を図るプロセス。
午前Ⅱのひっかけ：
- 復旧を止めて原因究明に集中し、影響が拡大する。
- 暫定対策（ワークアラウンド）と恒久対策を混同。
午後での使い所：「根本原因と恒久対策を管理し、再発防止をKPIで継続監視する。」
関連記事：総合ガイド／午後一問一答／関連：インシデント管理・ログ管理
構成管理（CMDB）
定義：構成アイテム（CI）と関係性を管理し、影響分析や障害対応を容易にする仕組み。
午前Ⅱのひっかけ：
- 更新されず陳腐化し、使えない台帳になる。
- CIの粒度が不適切で影響分析ができない。
午後での使い所：「変更管理と連動させ、影響分析・復旧・監査を実務で回せる形にする。」
関連記事：総合ガイド／午後一問一答／関連：変更管理（運用）・監査証跡
変更管理（運用）
定義：本番環境への変更を計画・承認・実施・記録し、サービス品質を守る運用プロセス。
午前Ⅱのひっかけ：
- 緊急変更の乱発で事故が増える。
- 影響分析・ロールバック・周知が不足する。
午後での使い所：「影響分析とロールバックを標準化し、監査証跡とSLAを担保する。」
可用性管理（Availability Management）
定義：必要なときにサービスを使える状態を維持し、可用性目標（SLA等）を満たすための管理。
午前Ⅱのひっかけ：
- 可用性＝「壊れないこと」と誤解（冗長化・監視・復旧時間など運用設計まで含む）。
- 信頼性（Reliability）・保守性（Maintainability）・耐障害性（Fault Tolerance）を混同。
午後での使い所：「可用性要件（SLA/SLO）を定義し、冗長化・監視・フェイルオーバー・復旧手順（DR）で担保する。」
関連記事：
総合ガイド／
午後一問一答／関連：DR（災害復旧）・BCP・ログ管理
キャパシティ管理（Capacity Management）
定義：性能・処理能力・リソース（CPU/メモリ/帯域/DB等）を需要に見合うよう計画・最適化する管理。
午前Ⅱのひっかけ：
- 性能問題を「サーバ増強」だけで解決しようとし、ボトルネック特定（DB/ネットワーク/アプリ）を落とす。
- ピーク需要・成長率・季節性を見ずに設計し、SLA未達やコスト過多を招く。
午後での使い所：「需要予測とボトルネック分析に基づき、スケール方針（縦/横）と監視指標を設計する。」
関連記事：
総合ガイド／
午後一問一答／関連：可用性管理・SRE・ログ管理
SRE（Site Reliability Engineering）
定義：信頼性を“工学”として扱い、SLO/エラーバジェット等で開発と運用を接続する実践アプローチ。
午前Ⅱのひっかけ：
- 「運用担当の別名」と誤解（SLO設計・自動化・継続改善が核）。
- SLA（対外約束）とSLO（内部目標）とSLI（指標）を混同。
午後での使い所：「SLOと監視指標（SLI）を定義し、エラーバジェット内でリリースと安定性を両立する。」
関連記事：
総合ガイド／
午後一問一答／関連：可用性管理・キャパシティ管理・インシデント管理
BCP（事業継続計画）
定義：災害・障害・事故等が起きても重要業務を継続・早期復旧するための計画。
午前Ⅱのひっかけ：
- BCPを「ITだけ」の話に矮小化（業務・人員・拠点・サプライヤ等を含む）。
- 計画を作って終わり（訓練・見直し・代替手段の実効性が問われる）。
午後での使い所：「重要業務と許容停止時間を定義し、代替手段・体制・訓練まで含めてBCPを実装する。」
関連記事：
総合ガイド／
午後一問一答／関連：DR・可用性管理・リスクアセスメント
DR（災害復旧：Disaster Recovery）
定義：大規模障害や災害時に、システム・データを復旧しサービスを再開するための仕組みと手順。
午前Ⅱのひっかけ：
- BCP（事業）とDR（IT復旧）の守備範囲を混同。
- RTO（復旧時間目標）とRPO（復旧時点目標）を取り違える。
午後での使い所：「RTO/RPOに合わせて冗長化・バックアップ・切替手順を設計し、訓練で実効性を担保する。」
関連記事：
総合ガイド／
午後一問一答／関連：BCP・可用性管理・ログ管理
10. セキュリティ・プライバシー（10）
CIA（機密性・完全性・可用性）
定義：情報セキュリティの三要素（Confidentiality, Integrity, Availability）。
午前Ⅱのひっかけ：
- 可用性を軽視（「守る＝機密性だけ」になりがち）。
- 完全性（改ざん防止）と真正性（本人性）を混同。
午後での使い所：「CIAの観点で要求を整理し、対策（アクセス制御・改ざん検知・冗長化）を選定する。」
関連記事：
総合ガイド／
午後一問一答／関連：ISMS・ゼロトラスト・可用性管理
ISMS（情報セキュリティマネジメントシステム）
定義：情報セキュリティを組織的・継続的に管理する仕組み（方針、体制、リスク管理、監査、改善）。
午前Ⅱのひっかけ：
- 「認証を取ること」が目的化（運用・改善が本体）。
- 技術対策だけで完結させ、規程・教育・監査を落とす。
午後での使い所：「リスク評価に基づき管理策を選び、教育・監査・是正で継続改善する（PDCA）。」
関連記事：
総合ガイド／
午後一問一答／関連：脆弱性管理・ログ管理
ゼロトラスト（Zero Trust）
定義：「社内は安全」を前提にせず、すべてのアクセスを検証し最小権限で守るセキュリティモデル。
午前Ⅱのひっかけ：
- VPN導入＝ゼロトラストと誤解（継続的な検証・最小権限が核）。
- 境界防御（ファイアウォール中心）と目的・設計思想を混同。
午後での使い所：「ID中心のアクセス制御（MFA/認可）と端末・ログの継続監視で“検証し続ける”設計にする。」
関連記事：
総合ガイド／
午後一問一答／関連：MFA・認証・認可・ログ管理
脆弱性管理
定義：脆弱性を発見・評価し、優先度を付けて修正・緩和・監視する一連の運用。
午前Ⅱのひっかけ：
- 検出（スキャン）で満足し、修正計画・再発防止が抜ける。
- CVSS等の深刻度だけで優先度を決め、資産重要度・露出度を見ない。
午後での使い所：「資産重要度×脅威×脆弱性で優先度を決め、パッチ適用と例外管理を運用設計する。」
関連記事：
総合ガイド／
午後一問一答／関連：ISMS・ログ管理
認証・認可
定義：認証＝本人確認、認可＝アクセス権限の付与・制御。
午前Ⅱのひっかけ：
- 認証（ログイン）さえすれば良いと誤解し、最小権限（認可）を落とす。
- RBAC/ABAC等の制御設計と運用（棚卸し）が抜ける。
午後での使い所：「重要データは最小権限で認可し、MFAとログ監査で不正を早期検知する。」
関連記事：
総合ガイド／
午後一問一答／関連：MFA・PKI・ゼロトラスト
暗号化
定義：データを第三者が読めない形に変換し、漏えい時の被害を抑える技術（通信/保存）。
午前Ⅱのひっかけ：
- 暗号化すれば安全と誤解（鍵管理・権限・ログがセット）。
- 通信暗号（TLS）と保存暗号（DB/ディスク）を区別できない。
午後での使い所：「重要情報は保存・通信の両方を暗号化し、鍵管理とアクセス制御を運用に組み込む。」
関連記事：
総合ガイド／
午後一問一答／関連：PKI・認証・認可
PKI（公開鍵基盤）
定義：公開鍵暗号と証明書を用いて、相手の正当性や通信の安全性を保証する仕組み。
午前Ⅱのひっかけ：
- 公開鍵暗号＝暗号化だけ、と誤解（署名・証明書・失効が重要）。
- 証明書の有効期限・失効（CRL/OCSP）を落とす。
午後での使い所：「証明書管理（発行/更新/失効）を運用設計に含め、なりすましを防ぐ。」
関連記事：
総合ガイド／
午後一問一答／関連：暗号化・MFA
MFA（多要素認証）
定義：知識・所持・生体など複数要素で本人確認を強化する認証方式。
午前Ⅱのひっかけ：
- SMSだけで十分と誤解（リスクに応じて方式を選ぶ）。
- 導入して終わり（例外運用・復旧手順・ログ監査が必要）。
午後での使い所：「重要操作にMFAを必須化し、ゼロトラストとログ監査で不正アクセスを抑止する。」
関連記事：
総合ガイド／
午後一問一答／関連：認証・認可・ゼロトラスト・ログ管理
ログ管理
定義：操作・アクセス・障害等のログを収集・保全・分析し、監査・検知・追跡可能性を確保する運用。
午前Ⅱのひっかけ：
- 「取っている」だけで満足（保全期間・改ざん耐性・監視ルールがない）。
- 個人情報や機密情報をログに出してしまい二次被害を招く。
午後での使い所：「監査証跡としてログ要件（項目/保全/改ざん防止）を定義し、インシデント対応に活用する。」
関連記事：
総合ガイド／
午後一問一答／関連：ISMS・インシデント管理・DR
個人情報保護
定義：個人情報を適正に取得・利用・保管・提供し、漏えい等を防ぐための法令順守と運用。
午前Ⅱのひっかけ：
- 同意取得だけで安心し、目的外利用・第三者提供・委託管理を落とす。
- 匿名加工/仮名加工などの区分や、取り扱いルール（保管期間・削除）を曖昧にする。
午後での使い所：「利用目的とデータフローを明確化し、アクセス制御・暗号化・ログ監査で漏えいリスクを低減する。」
関連記事：
総合ガイド／
午後一問一答／関連：暗号化・ログ管理・認証・認可
次の一手：午前Ⅱの語彙はここで固め、午後は「書ける型」に変換してください →
午後（科目B）頻出論点 一問一答
／全体の戦い方 →
ITストラテジストとは？（総合ガイド）
コメント