経営情報システム（令和元年度）

概要

---

形式層の分布

---

第1問　タッチパネルのユーザビリティ

Feedback
タッチパネルのメリット：
• 直感的操作（学習コストが低い）
• スペース効率（キーボードやマウス不要）
• スタンドアロン利用が可能（kiosk型など）
Feedback
デメリット：
• 正確性が低い（指の太さ、接触位置のズレ）
• 手の疲労（立ったまま長時間操作は困難）
• 環境依存（湿度、汚れで誤反応）
Feedback
適切な使用場面：
• POSシステム：定型選択肢が中心、操作者訓練がある
• 情報キオスク：顧客セルフサービス、直感性重視
• ATM：操作選択肢が限定的
Feedback
非適切な場面：
• 長時間の細かい入力作業（テキスト入力が主）
• 正確性が重要な業務（財務システム等）

Feedback
「タッチパネル＝常に最適」と誤認（デメリットが大きい場面もある）
Feedback
「スタンドアロン＝必ずタッチパネル」と限定（他の入力方法も存在）
Feedback
環境要因（画面反射、手の冷え）による操作性低下を見落とし

---

第2問　クラウドコンピューティングの展開モデル

Feedback
SaaS（Software as a Service）：
• アプリケーションを提供（Gmail、Salesforce、Office 365）
• ユーザーは：アクセスと設定のみ
• クラウド事業者が：インフラ、OS、アプリケーション、データを管理
Feedback
PaaS（Platform as a Service）：
• 開発環境を提供（App Engine、Heroku、Azure App Service）
• 開発者が：アプリケーションを作成（コード）
• クラウド事業者が：インフラ、OS、ミドルウェアを管理
Feedback
IaaS（Infrastructure as a Service）：
• サーバー・ストレージを提供（EC2、Azure VMs）
• ユーザーが：OS、アプリケーション、データを管理
• クラウド事業者が：ハードウェア、ネットワーク、仮想化を管理
Feedback
責任分担のイメージ：
• SaaS：クラウド事業者の責任が最大（ユーザーは最小）
• PaaS：中間的
• IaaS：ユーザーの責任が最大

Feedback
各モデルを「コスト」でのみ比較（実はスケーラビリティ、管理負荷で判定）
Feedback
「IaaS＝最も安い」と誤認（責任が大きい分、管理コストは高い可能性）
Feedback
オンプレミスとの比較を見落とし（IaaS でもオンプレミスより運用負荷が少ない）

---

第3問　データベース管理システム（DBMS）の機能

Feedback
DBMS の主要機能：
• データ一元管理：複数のユーザーから同じデータへのアクセス
• 並行制御：複数トランザクションの同時実行管理（ロック機構）
• データ整合性：トランザクションの ACID 特性（Atomicity, Consistency, Isolation, Durability）
• セキュリティ：ユーザー認証、権限管理（誰がどのテーブルにアクセスできるか）
Feedback
ファイルシステムとの比較：
• ファイルシステム：個別ファイルの保管と検索（複数プログラムでの操作時に重複・矛盾の危険）
• DBMS：共有データの一貫性を保証
Feedback
トランザクション管理：
• コミット（確定）：すべての更新を確定
• ロールバック（取消）：エラー時に直前の状態に戻す
Feedback
バックアップと リカバリー：
• 定期的なバックアップ
• 障害時の復旧手順（ジャーナルログの利用）

Feedback
「データベース＝単なるデータ保管」と限定（並行制御と整合性が本質）
Feedback
「ロック＝常に必要」と誤認（デッドロックのリスクもある）
Feedback
セキュリティを「OSレベル」だけと誤認（DBMS 内の権限管理が重要）

---

第4問　プロセッサ（CPU）とメモリの役割

Feedback
CPU の性能指標：
• クロック周波数（GHz）：高いほど高速だが、消費電力↑
• コア数（マルチコア）：並列処理能力向上、複数プロセスの同時実行
• キャッシュ容量：頻繁にアクセスするデータを高速に取得
Feedback
メモリ（RAM）の役割：
• 作業領域：実行中のプログラムとデータを保有
• 容量不足の場合：仮想メモリ（HDD/SSD）を使用（速度低下）
Feedback
CPU とメモリのバランス：
• CPU が高速でもメモリ不足では性能発揮できない
• メモリが豊富でも CPU が遅いと全体として遅い
Feedback
用途別の要求：
• オフィスアプリケーション：8GB RAM で十分
• ビデオ編集：32GB 以上が必要
• サーバー：CPU コア数、メモリ容量が重要

Feedback
「GHz が高い＝常に高速」と誤認（メモリと他要因に依存）
Feedback
「メモリが大きい＝速い」と単純化（効果は容量不足を避けること）
Feedback
マルチコアの効果を「単純に倍速」と誤認（プログラムが並列対応しない限り効果がない）

---

第5問　ストレージ（記憶装置）の種類と特性

Feedback
HDD（ハードディスク）：
• 原理：回転磁気ディスク
• 容量：多い（1TB～4TB 標準、低コスト）
• 速度：遅い（回転待機時間）
• 耐久性：機械部品のため故障リスク（衝撃に弱い）
• 用途：大容量保管、アーカイブ
Feedback
SSD（ソリッドステートドライブ）：
• 原理：フラッシュメモリ（電気的記憶）
• 容量：限定的（1TB が高い）
• 速度：速い（機械部品なし）
• 耐久性：電気的寿命（書き込み回数制限）
• 用途：OS/アプリ（速度優先）、ノートパソコン
Feedback
USB メモリ：
• 原理：フラッシュメモリ
• 容量：32GB～256GB（携帯性重視）
• 速度：中程度
• 用途：ファイルの持ち運び
Feedback
選択基準：
• バッチ処理（毎月の大量データ処理）：HDD
• システムドライブ：SSD
• バックアップ：HDD + クラウド

Feedback
「SSD ＝常に最適」と誤認（容量当たり高コストのため、大容量保管に非効率）
Feedback
「HDD は古い技術」と過小評価（コスト面で大容量なら今も有用）
Feedback
耐久性で「SSD が優れている」と誤認（書き込み寿命がある）

---

第6問　SQL による INSERT・UPDATE・DELETE

Feedback
INSERT：新しい行を追加
INSERT INTO customers (customer_id, name, city)
VALUES (1001, '山田太郎', '東京');
• すべての列を指定しない場合は、NOT NULL 制約が問題化
Feedback
UPDATE：既存の行を更新
UPDATE products
SET price = 1500
WHERE product_id = 100;
• WHERE 句がない場合は「すべての行が更新される」（危険）
Feedback
DELETE：行を削除
DELETE FROM orders
WHERE order_date < '2020-01-01';
• WHERE 句がない場合は「全データ削除」（致命的）
Feedback
トランザクション：
• COMMIT：変更を確定
• ROLLBACK：変更を取消
• ROLLBACK で誤操作の復旧が可能

Feedback
UPDATE や DELETE で WHERE 句を忘れた場合のリスクを軽視
Feedback
列名と値の対応を誤り（名前 = '田中' ではなく、name = '田中'）
Feedback
NULL 値の処理（IS NULL で判定する）

---

第7問　テーブル結合（JOIN）と多表検索

Feedback

INNER JOIN（内部結合）：

• 両テーブルに存在するレコードのみを返す
• 結果行数：A テーブルの行数 ≤ 結果 ≤ B テーブルの行数（通常は減少）

SELECT c.customer_id, c.name, o.order_date
FROM customers c
INNER JOIN orders o ON c.customer_id = o.customer_id;

Feedback
LEFT JOIN（左外部結合）：
• 左テーブル（FROM の後のテーブル）のすべての行を返す
• 右テーブルに対応がなければ NULL
• 結果行数：左テーブルの行数以上
Feedback
RIGHT JOIN、FULL OUTER JOIN：
• RIGHT：右テーブル優先
• FULL：両テーブルのすべての行
Feedback
結合キー（ON 句）の指定が重要：
• 誤ったキー指定は意図しない結果（デカルト積）

Feedback
「JOIN ＝必ず行数減少」と誤認（LEFT JOIN では増加可能）
Feedback
NULL 値の出現を予測できない
Feedback
複数キーでの結合時に条件不足

---

第8問　インデックス（索引）と検索性能

Feedback
インデックスの役割：
• 特定の列（例：customer_id）で高速検索
• 原理：ソート済みの索引テーブルを参照（全行スキャン回避）
• 検索速度：O(log n)（全行検索 O(n) より高速）
Feedback
インデックス作成のコスト：
• ストレージ使用量増加（索引テーブルを保有）
• INSERT・UPDATE・DELETE が遅くなる（索引も同時に更新）
Feedback
インデックス設定の判断：
• 頻繁に検索される列（WHERE 句で使用）
• 大規模テーブル（1万行以上）
• 更新頻度が低い列
• NOT：頻繁に変更される列、カーディナリティが低い列（一意性が低い）
Feedback
複合インデックス：
• 複数列の組み合わせでインデックス
• 順序が重要（最初の列で効果が大きい）

Feedback
「すべての列にインデックスを作成 = 最速」と誤認（INSERT・UPDATE が極端に遅くなる）
Feedback
インデックスを作成後、クエリが「自動的に最速化」と期待（オプティマイザの選択に依存）
Feedback
ディスク容量増加を考慮しない

---

第9問　データベース正規化と異常現象

Feedback

非正規化テーブルの例：

| 注文ID | 顧客ID | 顧客名 | 商品ID | 商品名 | 金額 |
| 001 | 101 | 山田太郎 | 10 | 本 | 1,000 |
| 001 | 101 | 山田太郎 | 20 | ペン | 100 |

Feedback
異常現象：
• 更新異常：「山田太郎」の名前変更時、すべてのレコードを更新する必要（矛盾リスク）
• 削除異常：注文を削除すると、顧客情報（山田太郎）も削除される可能性
• 挿入異常：新規顧客を登録しようとしても、注文がないと登録できない
Feedback
正規化による改善：
• 第1正規形：繰り返しグループを排除し、各属性が原子値（分割不可能な単一値）を持つ
• 第2正規形：部分関数従属性を排除（複合キーの一部のみに依存する属性を別テーブルに分離）
• 第3正規形：推移関数従属性を排除（非キー属性が他の非キー属性を経由してキーに依存する関係を解消）
Feedback
正規化のトレードオフ：
• メリット：異常排除、保守性向上
• デメリット：JOIN が必要となり検索複雑化（パフォーマンス低下可能性）

Feedback
「正規化＝絶対に必要」と過度に強調（実装では柔軟な判定）
Feedback
各正規形の定義を正確に理解していない
Feedback
検索パフォーマンスのための「逆正規化」という選択肢を知らない

---

第10問　ファイアウォールと不正アクセス防止

Feedback
ファイアウォールの機能：
• 許可ルール設定：許可されたトラフィックのみ通過（例：ポート 80, 443）
• 拒否ルール設定：特定の送信元 IP からのアクセス遮断
• ステートフル検査：接続状態を確認（単なるパケット判定でなく）
Feedback
ファイアウォールの限界：
• 既に内部に侵入した攻撃者には無効
• アプリケーション層の攻撃（SQL インジェクション等）には対応できない
• 暗号化されたトラフィックの内容検査不可
Feedback
IDS・IPS との組み合わせ：
• IDS（Intrusion Detection System）：不正アクセスを検出・アラート
• IPS（Intrusion Prevention System）：検出と同時にブロック
Feedback
多層防御（Defense in Depth）：
• ネットワーク層：ファイアウォール
• アプリケーション層：WAF（Web Application Firewall）
• エンドポイント層：アンチウイルスソフト
Feedback
エアギャップ：
• 物理的に隔離（最強のセキュリティだが利便性喪失）

Feedback
「ファイアウォール＝完全な防御」と誤認（内部脅威に無効）
Feedback
IDS と IPS を「同一視」（IPS は能動的ブロック機能）
Feedback
セキュリティを「1 つのツール」に依存（多層防御が必須）

---

第11問　暗号化とデジタル署名

Feedback
共通鍵暗号（対称鍵）：
• 同じ鍵で暗号化・復号化
• 利点：高速、短い鍵長で十分（128 ビット ≒ RSA 3072 ビット相当）
• 課題：鍵配送が危険（鍵をどうやって安全に送るか）
• 用途：ファイル全体の暗号化、ストレージ暗号化
Feedback
公開鍵暗号（非対称鍵）：
• 公開鍵（公開）で暗号化、秘密鍵（秘密）で復号化
• 利点：鍵配送が安全（公開鍵は公開してよい）
• 課題：計算量が多い、鍵長が長い必要（RSA 2048 ビット）
• 用途：通信セッション確立（TLS）、デジタル署名
Feedback
デジタル署名：
• 送信者の「秘密鍵」で署名、受信者の「公開鍵」で検証
• 効果：送信者認証（本当に本人か）、改ざん検出、否認防止
Feedback
ハイブリッド方式（実務的アプローチ）：
• 公開鍵で暗号化した「共通鍵」を送信
• 共通鍵でデータ本体を暗号化（高速化）

Feedback
「公開鍵が公開 = 暗号化される側が暗号化できる」と誤認（実は反対）
Feedback
デジタル署名が「完全な改ざん防止」と誤認（秘密鍵が漏洩すれば無効）
Feedback
TLS（HTTPS）での鍵交換の実装詳細を曖昧に理解

---

第12問　認証方式と多要素認証

Feedback
パスワード認証：
• 特性：安価、汎用的
• 課題：推測可能（弱いパスワード）、流出リスク、再利用
• 対策：強力なパスワード要件、定期変更（ただし効果は議論がある）
Feedback
バイオメトリクス認証：
• 指紋、顔認識、虹彩スキャン
• 利点：本人の身体的特徴（複製困難）
• 課題：プライバシー、エラー率（偽陰性・偽陽性）
Feedback
多要素認証（MFA）：
• 2 つ以上の異なるタイプの認証を組み合わせ
• 例：パスワード + SMS コード、パスワード + 生体認証
• セキュリティ向上：1 つが破られても他で守られる
Feedback
認証サーバー：
• LDAP、Kerberos（企業 AD）
• OAuth、SAML（クラウドサービス連携）

Feedback
「複雑なパスワード＝安全」と誤認（暗号化保管、ハッシュ化が本質）
Feedback
バイオメトリクスが「絶対安全」と過大評価（スプーフィング攻撃の可能性）
Feedback
MFA による利便性低下を軽視（セキュリティと利便性のバランスが鍵）

---

第13問　ウイルスとマルウェア対策

Feedback
ウイルス：
• 特性：他のプログラムに寄生、実行時に感染
• 被害：データ破壊、個人情報窃取
• 感染経路：メール添付、ダウンロードファイル
Feedback
ワーム：
• 特性：独立して動作、自己複製（ネットワーク経由で拡散）
• 速度：ウイルスより高速な蔓延
• 例：Conficker（2008 年）
Feedback
トロイの木馬：
• 特性：有用なプログラムを装う（ユーザーが実行）
• 被害：バックドア開放、情報窃取、遠隔操作
Feedback
ランサムウェア：
• 特性：ファイルを暗号化し、復号化の対価を要求
• 被害：ビジネス停止、金銭被害
• 感染経路：メール、不正サイト、脆弱性（RDP）
Feedback
防御策：
• アンチウイルスソフト（既知マルウェアのシグネチャ検出）
• ホワイトリスト（許可したプログラムのみ実行）
• サンドボックス（疑わしいプログラムを隔離実行）
• バックアップ（ランサムウェア対策）

Feedback
「アンチウイルスソフト＝完全な防御」と誤認（未知マルウェアに無効）
Feedback
「ウイルス＝すべてのマルウェア」と誤称（カテゴリが異なる）
Feedback
ランサムウェア被害時に「身代金支払い」を推奨（足がかりを与えるだけ）

---

第14問　DDoS 攻撃と防御

Feedback
DDoS 攻撃の仕組み：
• 通常のアクセスに見えるトラフィックを大量に送信
• ボットネット：マルウェアに感染した複数台のコンピュータを操作（通常、所有者は気づかない）
• スケール：1Tbps を超える攻撃も報告
Feedback
攻撃の種類：
• Layer 3/4 攻撃（ネットワーク層）：SYN flood、UDP flood
• Layer 7 攻撃（アプリケーション層）：HTTP flood（ウェブサーバーを標的にした攻撃）
Feedback
防御・緩和方法：
• ISP・CDN レベル：トラフィック分散、異常検知
• ファイアウォール：トラフィックフィルター（ただし大規模攻撃では突破される）
• DDoS 対策サービス（Akamai、Cloudflare）：トラフィック吸収
• レート制限：アクセス数制限
• キャッシング：キャッシュサーバーを盾にする
Feedback
被害軽減：
• 攻撃停止を待つ（身代金払わない）
• 通常トラフィックの優先化
• インシデント対応体制の事前準備

Feedback
「ファイアウォール＝DDoS 完全防御」と誤認（大規模攻撃では無力）
Feedback
「DDoS ＝ネットワークトラフィック攻撃のみ」と限定（L7 攻撃も DDoS）
Feedback
「ボットネットは他組織のもの」と他人事化（自社が踏み台になっていないか監視必須）

---

第15問　システム開発の V モデル

Feedback
V モデルの構造：
• 左側（上流）：要件定義 → 基本設計 → 詳細設計
• 頂点：実装（プログラミング）
• 右側（下流）：単体テスト → 統合テスト → システムテスト → ユーザー受け入れテスト
Feedback
各段階のテスト：
• ユーザー受け入れテスト（UAT）：要件定義を満たしているか（ユーザーが確認）
• システムテスト：全体の機能が動作するか
• 統合テスト：複数モジュール間の連携が正常か
• 単体テスト：個別プログラムの動作確認（開発者が実施）
Feedback
上流テスト・下流テスト：
• レビュー（要件定義、設計段階）：文書の正確性確認（早期に不備発見）
• テスト（実装後）：実行による動作確認
Feedback
品質への影響：
• 上流段階でのバグ検出＝修正コスト低
• 下流段階で検出＝修正コスト高（多くのモジュールに波及）

Feedback
「テスト＝実装後だけ」と限定（要件定義・設計段階のレビューも重要）
Feedback
各テスト段階の「責任者」を曖昧に（システムテストはベンダー、UAT はユーザー）
Feedback
テスト計画の不足（何をテストするか事前に決定が必須）

---

第16問　アジャイル開発と反復的改善

Feedback
ウォーターフォール型：
• 段階順序：要件定義 → 設計 → 実装 → テスト → リリース
• 特性：各段階が順次進行、後工程への影響を避けるため前段階で完璧を目指す
• メリット：計画性、予算管理
• デメリット：要件変更への対応困難、顧客フィードバックが遅い
Feedback
アジャイル型：
• サイクル：1～4 週間のスプリント内で、計画 → 実装 → テスト → デモ
• 特性：短サイクル、顧客フィードバックを頻繁に受ける、変更受け入れ
• メリット：柔軟性、顧客満足度、リスク軽減
• デメリット：計画管理が難しい、ドキュメント不足、大規模プロジェクトでの適用困難
Feedback
スクラム：
• アジャイル実装フレームワーク
• 役割：プロダクトオーナー（要件決定）、スクラムマスター（プロセス管理）、開発チーム
• イベント：スプリント計画、デイリースタンドアップ、スプリントレビュー
Feedback
適用シーン：
• ウォーターフォール：要件が明確（大規模インフラ、金融システム）
• アジャイル：要件が不確実（スタートアップ、消費者向けアプリ）

Feedback
「アジャイル＝常に最適」と誤認（大規模プロジェクトでは向かない）
Feedback
「アジャイル＝ドキュメント不要」と誤認（最小限のドキュメントは必須）
Feedback
スプリント中の「要件追加」による予定の変更を無視

---

第17問　ソフトウェア保守と技術債

Feedback
保守の分類：
• 改善保守：パフォーマンス向上、セキュリティ パッチ
• 適応保守：OS バージョンアップ、法改正への対応
• 拡張保守：新機能の追加
• 是正保守：バグ修正
Feedback
保守コスト：
• 初期開発：全体コストの 20～30%
• 保守フェーズ（5～10 年）：70～80%（デバッグ、機能追加の繰り返し）
Feedback
技術債（Technical Debt）：
• 定義：急速な実装のため、後から払うべき「品質負債」
• 例：テストが不十分なコード、ドキュメント不足、古いライブラリの使用
• 利息：保守効率低下、バグ増加、新機能追加が困難
Feedback
現代化（Modernization）：
• リフト&シフト：既存システムをクラウドに移行
• リホスティング：プラットフォーム変更（COBOL → Java など）
• リアーキテクチャー：アーキテクチャ全体の再設計
• 段階的廃止：サービスを段階的に停止、置き換え

Feedback
「技術債＝排除すべき悪」と単純化（一定範囲の技術債は戦略的）
Feedback
保守予算の削減が「長期的には高くつく」ことを認識していない
Feedback
レガシーシステムの「実装資産価値」と「技術的負債」の両面を考慮しない

---

第18問　プロジェクト管理と WBS（Work Breakdown Structure）

Feedback
WBS（作業分解構造）：
• 大規模プロジェクトを「階層的に細分化」
• 最下層：「見積もりと割り当てが可能なタスク」レベル
• 目的：漏れ防止、責任明確化、進捗管理
Feedback
スケジュール管理：
• ガントチャート：各タスクの期間を視覚化
• クリティカルパス：全期間を決める最長経路
• 余裕時間（フロート）：遅延しても全体に影響しないタスク
Feedback
予算管理：
• 予算配分：タスクごとに労力・コストを見積もり
• 予算執行：実績と予算の差分を監視
• EV（Earned Value）管理：計画値、実績値、出来高を管理
Feedback
リスク管理：
• 識別：何が問題になるか
• 分析：確率と影響度で優先順位付け
• 対応：回避、軽減、受容、転嫁
Feedback
進捗報告：
• 定期レビュー（週次、月次）
• ステークホルダーへの報告

Feedback
「詳細な WBS ＝完璧な計画」と過度な期待（環境変化への対応能力喪失）
Feedback
スケジュール遅延を「発見後に対応」と遅延（早期警戒が重要）
Feedback
リスク管理を「起きた後の対応」と誤認（事前予防が本質）

---

第19問　ベンダー選定と RFP（提案依頼書）

Feedback
調達段階の確認：
• RFI：市場情報や実績を広く集める段階
• RFP：自社要件を示して提案を比較する段階
• RFQ：仕様を固めて価格を比較する段階
Feedback
RFP（Request for Proposal）の要素：
• 現状分析：現在のシステム、問題点
• 要件定義：必須機能、非機能要件（性能、セキュリティ）
• スケジュール：導入時期、マイルストーン
• 予算：想定額と支払い条件
• 評価基準：機能、価格、実績、サポート体制
Feedback
ベンダー評価基準：
• 機能適合性：要件への対応度
• 価格：初期導入コスト＋5 年間の総所有コスト（TCO）
• 実績：類似プロジェクト経験、参考企業
• サポート体制：SLA（Service Level Agreement）、サポート料金、24/7 対応
• 財務健全性：ベンダーの経営状態（継続性）
Feedback
契約条項：
• 機能・性能保証：未達時の対応
• データ移行責任：既存データの引き継ぎ
• 保守期間：サポートの期限
• ペナルティ：納期遅延、品質不足時の減額
Feedback
複数社の比較検討：
• スコアリング：定量的評価
• プルーフオブコンセプト（PoC）：試験導入で実装確認

Feedback
「最安値ベンダー＝最適」と誤認（TCO、サポート品質を考慮）
Feedback
「大手ベンダー＝安全」と誤信（プロジェクトの失敗事例も多い）
Feedback
RFP の要件が曖昧（ベンダー間での解釈相違）
Feedback
RFI / RFP / RFQ をすべて 提案依頼 と雑に捉え、情報収集段階と価格比較段階を混同する

---

第20問　デジタル戦略と IT 投資の ROI

Feedback
投資評価指標：
• ROI（Return on Investment）= (投資効果 - 投資額) / 投資額 × 100%
• 投資回収期間：投資額を回収するまでの期間（年数）
• TCO（Total Cost of Ownership）：導入から運用・更新・廃棄までの総コスト
• NPV（Net Present Value）：将来キャッシュフローを現在価値に割引
• IRR（Internal Rate of Return）：NPV が 0 になる割引率
Feedback
定量効果：
• コスト削減：人員削減、業務効率化（残業削減）、設備コスト低下
• 売上増加：新機能による顧客獲得、サービス向上による利用者増
• エラー率低下：品質向上による修正コスト削減
Feedback
定性効果：
• ブランドイメージ向上
• 顧客満足度向上
• 従業員のモチベーション向上
• リスク低減（セキュリティ向上など）
• 定量化困難だが経営価値は大きい
Feedback
導入後の効果測定：
• KPI（Key Performance Indicators）を事前に設定
• 定期的な測定と改善
• 期待値と実績の差分分析
Feedback
隠れたコスト：
• ユーザー教育・訓練
• 業務プロセス改変（混乱期間）
• サポート体制構築
• レガシーシステム廃止コスト

Feedback
「ROI ＝投資判断の唯一の基準」と誤認（定性効果も重要）
Feedback
ROI と投資回収期間を同じだと思い、利益率と回収年数を混同する
Feedback
TCO を 初期導入費だけ だと誤解し、運用・教育・更新費を落とす
Feedback
定性効果を「数値化できないから無視」と判定（経営戦略上の価値を見落とし）
Feedback
導入後の「実績 vs 計画」の差分を分析せず、改善機会を逸する

---

第21問　データ駆動経営と BI（ビジネスインテリジェンス）

Feedback
データウェアハウス（DW）：
• 複数の業務システムから「歴史データ」を統合
• 分析用に最適化（質問に高速に応答）
Feedback
BI ツール：
• OLAP：多次元分析（日時、地域、商品の組み合わせ）
• ダッシュボード：KPI の可視化
• レポート：定期的な経営情報提供
Feedback
分析プロセス：
• 仮説：「○○に関連性があるか」
• データ検証：相関分析、統計検定
• 洞察：なぜそうなったのか
• 行動：意思決定と改善施策
Feedback
データ品質：
• 分析の精度は「入力データの質」に依存
• ガベージイン、ガベージアウト（GIGO）
Feedback
組織文化：
• 「経験と勘」から「データ駆動」への転換
• 分析結果の受け入れ可能性

Feedback
「BI ツール導入 = 自動的に経営改善」と期待
Feedback
データ品質の重要性を軽視（不正確なデータからの分析は無価値）
Feedback
分析結果が「正解」と誤信（統計的結論には信頼区間・限界がある）

---

第22問　クラウドコンピューティングの課題と選択

Feedback
クラウドのメリット：
• 初期投資削減：CAPEX → OPEX への転換
• スケーラビリティ：需要変動に対応（オートスケーリング）
• 保守管理の簡素化：ベンダーが OS、セキュリティパッチ対応
• 地理的分散：バックアップ、災害対応が容易
Feedback
クラウドのリスク：
• ベンダーロック：異なるクラウドへの移行困難（API、データフォーマットの差）
• セキュリティ：クラウド上でのデータ処理、通信暗号化
• コスト：使用量に応じた課金、思わぬ超過料金
• ネットワーク依存：インターネット遅延・障害の影響
Feedback
オンプレミス vs クラウド：
• オンプレミス：初期投資大、カスタマイズ柔軟、管理負荷大
• クラウド：初期投資小、標準機能が中心、スケーラビリティ優秀
Feedback
ハイブリッド：
• 高機密情報：オンプレミス
• 定型業務：クラウド
Feedback
オーバークラウド（複数クラウドの利用）：
• ベンダーロック回避
• 相互運用性の課題

Feedback
「クラウド＝常に安い」と誤認（高利用なら高額になることも）
Feedback
「クラウド＝完全に安全」と誤信（ユーザー責任も大きい）
Feedback
「レガシーシステムもクラウドに簡単に移行」と楽観視

---

第23問　IoT・AI・ブロックチェーンの可能性と限界

Feedback
IoT の応用：
• 監視・制御：工場の設備監視、建物のエネルギー管理
• 予防保全：センサーデータから故障予測
• 新サービス：スマート家電による利用パターン分析
• 課題：セキュリティ（膨大なデバイス管理）、通信遅延、電力消費
Feedback
AI・機械学習：
• 応用：画像認識（不良品検出）、自然言語処理（チャットボット）、需要予測
• 課題：データ品質、モデルの解釈性（ブラックボックス）、バイアス、運用コスト
Feedback
ブロックチェーン：
• 応用：金融取引、サプライチェーン透明化、知的財産管理
• 課題：処理速度、エネルギー消費、法的枠組み整備遅れ
Feedback
導入の現実：
• 投資額が膨大（初期学習、人材育成）
• 技術者不足（市場での獲得競争）
• 規制対応（特に AI、個人データ活用）
Feedback
成功事例の特性：
• 小さく始める（PoC → パイロット → 本格導入）
• ビジネス課題が明確（技術ありきではなく）
• リーダーシップと予算確保

Feedback
「最新技術 = 導入すべき」と盲目的推進（ROI 検証が必須）
Feedback
「難しい技術 = 導入困難」と過度に悲観（小規模導入から学習可能）
Feedback
メディアの誇大報道をそのまま信じ（実現には時間がかかることが多い）

---

第24問　サイバーセキュリティ体制と CISO（最高情報セキュリティ責任者）

Feedback
CISO の役割：
• セキュリティ方針の策定・推進
• リスク評価と優先付け
• 経営層への報告（取締役会に定期報告）
• 全社的なセキュリティ文化醸成
Feedback
セキュリティ体制：
• セキュリティ委員会：経営層が参加（取締役、CISO、事業部長）
• セキュリティチーム：技術的実装を担当
• インシデント対応チーム（CSIRT）：攻撃対応
Feedback
セキュリティポリシー：
• 情報分類（機密度別）
• アクセス制御（誰が何にアクセス可か）
• 入退社手続き（離職時のアクセス削除）
• 持ち出し禁止ルール
Feedback
インシデント対応：
• 準備段階：ツール導入、人材教育、対応計画
• 検出・分析：何が起きたか（攻撃か、誤操作か）
• 隔離・制御：被害拡大防止
• 復旧：システム復旧、データ復元
• 事後対応：原因分析、再発防止、ステークホルダー報告
Feedback
コンプライアンス：
• 個人情報保護法、GDPR
• 業界規制（金融、医療）
• 監査（内部・外部）

Feedback
「セキュリティ = IT 部門の責任」と誤認（経営層のガバナンスが基盤）
Feedback
「セキュリティ = 技術対策」と限定（ポリシー、組織体制が重要）
Feedback
インシデント発生を「失敗」と見なし、隠蔽しようとする（透明性が重要）

---

第25問　デジタルトランスフォーメーション（DX）の実現

Feedback
DX の段階：
• デジタイゼーション：紙の電子化（単純な置き換え）
• デジタライゼーション：業務プロセスの自動化
• DX：ビジネスモデルの根本的変革
Feedback
DX の特性：
• 顧客体験の変革：デジタルチャネル拡充、パーソナライゼーション
• ビジネスモデル変革：製品販売 → サービス提供、新規市場開拓
• 運営効率化：業務の自動化、意思決定の高速化
Feedback
実現に必要な要素：
• 経営戦略：何をなぜやるか、ビジネス目標が明確
• 技術投資：クラウド、AI、データ分析基盤
• 人材・文化：デジタルマインドセット、組織柔軟性
• ガバナンス：セキュリティ、コンプライアンス
Feedback
DX 推進の課題：
• レガシーシステムの負債（既存システムに足かせ）
• 人材不足（デジタルスキル保有者）
• 組織文化の抵抗（既存事業への執着）
• 投資判断の困難性（効果測定が難しい）
Feedback
成功事例の共通点：
• トップの強いコミットメント
• 小さく始める（full-scale ではなく）
• 失敗を許容（学習文化）
• エコシステム構築（協業パートナー）

Feedback
「DX ＝IT 導入」と誤認（ビジネスモデル変革が本質）
Feedback
「デジタル化すれば自動的に成功」と期待（戦略と組織変化が鍵）
Feedback
既存事業との「共存」を目指し、DX が中途半端に終わる

---

分類タグの凡例

知識種類（K）

思考法（T）

形式層（L）

落とし穴パターン（Trap）

分類タグ凡例