外部資源活用と意思決定支援システム

アウトソーシング、クラウド、DWH、OLAP、BI、データマイニング、IoT、ビッグデータを体系的に整理

このページの役割

経営情報管理において、企業は以下の2つの課題に直面します。1つ目は、自社でできることと外部に委託すべきことをどう判断するかという「外部資源活用」の問題です。もう1つは、大量に存在するデータから、意思決定に必要な情報をどう抽出するかという「分析から経営判断への変換」の問題です。

このページは、この2つの課題を統合的に扱います。なぜなら、両者は密接に関連しているからです。クラウドサービスを選ぶときは「責任分界」を理解する必要があり、データ分析システムを導入するときは「DWH」「OLAP」「BI」が果たす役割をそれぞれ区別する必要があります。試験では、これらの概念を「どう使い分けるか」という実務的な観点で出題されることが多いため、定義だけでなく、「なぜそうなるのか」という背景を掴むことが重要です。

学習のポイント

外部資源活用の判断軸：アウトソーシング、クラウド、オンプレミスの違いを「責任分界」「コスト構造」「柔軟性」で整理する

クラウド責任分界の体系的理解：SaaS、PaaS、IaaS、FaaSの4層それぞれについて、ベンダとユーザの管理範囲を正確に言える

経営情報システムの発展段階：TPS（取引処理）→ MIS（中間管理）→ DSS（意思決定支援）→ SIS（戦略情報）→ EIS（エグゼクティブ）の段階で、誰が何に使うか区別する

DWH設計の4特性：サブジェクト指向・統合・非揮発性・時系列を実例で説明できる

分析手法の選択：OLAP（既知の指標の多角的分析）とデータマイニング（未知パターンの発見）の違いを踏まえて使い分ける

IoTとエッジコンピューティング：全データをクラウドに送るべき場合と、デバイス側で即座に処理すべき場合を判定する

試験で問われる観点

外部資源活用の選択肢（フルアウトソーシング、選択的アウトソーシング、クラウド）を、コスト・品質・リスク・柔軟性で比較説明できるか

SaaS・PaaS・IaaS・FaaSの責任分界図を自分で描き、各層の違いを言えるか

DWHの4特性（サブジェクト指向・統合・非揮発性・時系列）を具体例で説明できるか

OLAP操作（スライス・ダイス・ドリルダウン・ドリルアップ・ピボット）の定義と使い分けを、図解できるか

BI（既知指標の可視化）とデータマイニング（隠れたパターン発見）のどちらを使うべきかを判断できるか

TPS・MIS・DSS・SIS・EISの5段階で、各システムの利用者・目的・データ特性を対応させることができるか

バスケット分析（アソシエーション分析）の支持度・信頼度・リフトの意味と計算を説明できるか

第1章：外部資源活用の判断基準

アウトソーシングの定義と判断軸

アウトソーシング（Outsourcing）は、自社が実施している業務の一部またはすべてを外部の専門企業に委託することです。一見するとコスト削減が主目的に見えますが、実は責任分界（どちらが何を管理するのか）、契約期間の柔軟性、品質保証、セキュリティ管理など、多面的な判断が必要な経営戦略です。

なぜアウトソーシングを選ぶのでしょうか。その背景には、経営学の基本的な考え方があります。企業は限定された経営資源（人、金、時間）を持っています。その資源を「コア事業」（競争優位を生む業務）に集中させ、「非コア業務」（支援機能）は外部の専門家に任せることで、企業全体の競争力を高めることができます。たとえば、製造業の企業にとって製品開発・営業は「コア」ですが、給与計算・経理処理は「非コア」です。これらを外部委託すれば、管理部門のコスト・人員を削減でき、その分を製品開発や営業に投資できるわけです。

試験ではこの理論的背景と実務的判断（責任分界、契約内容、セキュリティ）の両方が問われるため、単なる「安いから外部委託」という理解では不十分です。

アウトソーシングの形態と判断軸

アウトソーシング（Outsourcing）とは、自社が実施している業務の一部またはすべてを外部の専門企業に委託する経営戦略です。試験では単なる「コスト削減手段」ではなく、「責任分界」「契約内容」「柔軟性」の観点で出題されます。

アウトソーシングの4つの形態

アウトソーシングは、委託する範囲（全体 vs 一部）と段階（一括 vs 段階的）で分類されます。

形態	定義	自社負担の程度	典型的な適用例
フルアウトソーシング	対象業務全体を外部に一括委託	最小（検収と支払いのみ）	給与計算、経理決算処理全般、データセンター運用
選択的アウトソーシング	業務の一部を外部に委託、残部は内製	中程度（外部側の進捗監理が必要）	システム開発の一部工程、コールセンター基盤、特定部門の経理
段階的導入	パイロット運用後、成功を確認して拡大	初期は高い→段階で軽減	新システムを1営業所で試行→全社展開；給与計算を一部拠点から全国展開

メリット・デメリット分析

アウトソーシングの判断は「コストだけでなく、品質・セキュリティ・柔軟性」で多軸的に評価します。

判断軸	メリット	デメリット
コスト	固定費→変動費化、スケール利益で単価低下	初期移行コスト発生、長期化で価格上昇リスク
品質	外部専門家による高度な知識・技術活用	ベンダ依存、属人化、品質監理の内部負荷
柔軟性	業務量増減への即時対応が可能	急な仕様変更への対応遅延リスク
セキュリティ・リスク	突発対応をベンダが担当	個人情報漏洩、情報セキュリティ（外部委託先の管理責任も顧客側）
内部人材	非コア業務から解放→コア業務集中	内部スキル喪失、ベンダへの長期依存

オフショア・ニアショア開発の選択

委託先の地理的位置によって、コスト・品質・リスクのバランスが変わります。

オフショア開発（Offshore Development）

海外、特に人件費の低い国（インド、フィリピン、ベトナムなど）にソフトウェア開発を委託する形態です。

特徴

コスト削減幅：大規模（時給が日本の1/3～1/5程度）

人材：開発エンジニアが豊富に存在

時間帯：時差を活用した24時間開発が可能（東京→インド→オフショア→東京と開発が回る）

課題と対応

言語・文化の障壁：要件打ち合わせが複雑化、誤解発生リスク → 綿密なドキュメント作成が必須

時差によるコミュニケーション遅延：東京とインドの時差は3.5時間だが、リアルタイムの議論が難しい

品質管理：成果物の品質バラツキが大きいことがある → テスト工程を強化する必要

知的財産保護：ソースコード、仕様書の流出リスク → NDA（秘密保持契約）の厳格化

ニアショア開発（Nearshore Development）

国内の地方都市（沖縄・福岡・北海道・東北地方など、首都圏以外）への委託です。

特徴

コスト削減幅：中程度（首都圏に比べて人件費が低い）

時差なし：国内のため時差がなく、リアルタイムコミュニケーションが容易

言語・文化の障壁なし：同じ言語・文化圏のため、コミュニケーションロスが少ない

結論：オフショアほどのコスト削減は期待しにくいが、コミュニケーション品質と時間効率が大幅に向上

ハウジング・ホスティングとクラウドの使い分け

インフラ設備を外部に委託する形態には、古い方式（ハウジング・ホスティング）と新しいクラウド方式があります。その違いを理解することが、試験で「どちらが最適か」を判断する際に重要です。

形態	定義	自社の管理範囲	費用負担	典型例
ハウジング	自社購入のサーバ機器をデータセンターに置き、物理管理を委託	サーバのセットアップ・運用・保守全て	機器購入費＋月額保管・電源費	自社開発したシステムをセキュアなデータセンターに設置
ホスティング	ベンダ所有のサーバを共有利用（共用サーバ）	OSレベルの設定のみ（通常はカスタマイズ限定）	月額利用料	小中企業のWebサイト、メール提供
IaaS	仮想インフラ（サーバ、ストレージ、ネットワーク）をクラウドで提供	OS、ミドルウェア、アプリケーション	従量課金＋管理コスト	AWS EC2、Azure仮想マシン

重要な違い

ハウジング・ホスティング：物理的な設備管理に特化。昔のデータセンター方式

IaaS：仮想リソースなので、必要に応じてスケーリング（拡張・縮小）が自動的・迅速に可能

試験では「機械的に物理機器を置いている」「費用が初期投資型」という特徴でハウジング・ホスティングと判別します。一方、「スケーラビリティ」「従量課金」という特徴が見えたらクラウド（IaaS）です。

ビジネスプロセスアウトソーシング（BPO）と過去のASP

BPO（Business Process Outsourcing）の定義と役割

BPOは、単なるシステム委託ではなく、業務プロセス全体を外部企業に委託する高度なアウトソーシングです。

対象業務の例

給与計算・人事労務：従業員データ管理、給与・賞与計算、税務申告

経理・会計：伝票入力、決算処理、請求書作成

コールセンター：顧客問い合わせ対応、営業サポート

データ入力・処理：帳票からのデータ変換、スキャニング

BPOの特徴

単なるコスト削減ではなく、プロセス改善が目標：ベンダは業界知識を持ち、業務フロー自体を改善する提案をすることがある

責任分界が明確：特にマイナンバー対応、個人情報保護法対応時は「外部に預けても、情報管理責任は発注側」と法律で定められている

試験での出題パターン

「給与計算をBPOで外部委託した場合、従業員の個人情報流出時の責任は誰か」→ 発注側企業

「システム障害時の復旧責任は」→ 契約内容に依存するが、SLA（Service Level Agreement）で明記

ASP（Application Service Provider）：歴史的背景

ASPは2000年代に流行した「インターネット経由でアプリケーションを提供する」サービスです。現在はSaaS（Software as a Service）に統合されています。

ASPの特徴（歴史的背景）

ユーザが個別にソフトを購入・インストールせず、ブラウザから利用

ASP企業がサーバとアプリを管理

「昔はシングルテナント型（顧客ごとにカスタマイズ可能）」が多かった

現在：SaaSが主流。SaaSはマルチテナント型（複数顧客が共通プラットフォームを利用）で、カスタマイズ性は低いが、更新・保守がベンダ側で自動実施される

試験での出題：主に過去問解説や古いテキストで「ASP という用語が出てきたら SaaS と考えて差し支えない」程度の理解で大丈夫です

第2章：クラウド責任分界モデルの体系

クラウドサービスの4層と責任分界

クラウドサービスは、「ベンダ側が何を提供するか」「ユーザ側が何を管理するか」によって4つの層に分類されます。試験ではこの責任分界を正確に理解し、「この企業の課題にはどのサービスが最適か」を判断する能力が求められます。

4つのサービス層の階層構造

クラウドサービスを下から積み上げると、次のような層構造になります。

┌─────────────────────────────────────┐
│    アプリケーション・ソフトウェア     │  ← ユーザ側の責任
├─────────────────────────────────────┤
│   SaaS: 完成したソフト提供           │  ← ベンダ側が提供（ユーザは利用のみ）
├─────────────────────────────────────┤
│   PaaS: 開発・実行基盤               │  ← ベンダが提供（ユーザがコード書き込む）
├─────────────────────────────────────┤
│   IaaS: サーバ・ストレージ・ネット   │  ← ベンダが提供（ユーザが OS 以上を構築）
├─────────────────────────────────────┤
│  ハードウェア・物理ネットワーク・施設 │  ← ベンダ側の責任（ユーザは見えない）
└─────────────────────────────────────┘

各層の定義と責任分界

サービス	ベンダ側が提供する物	ユーザ側が管理する物	ユーザ側が管理しない物	典型例
SaaS（Software as a Service）	完成したアプリケーション＋インフラ一式	データ入力、ユーザ管理、アプリ設定	アプリケーション本体、DB、OS、サーバ、ネットワーク	Salesforce（CRM）、Google Workspace（メール・ドキュメント）、Slack（チャット）
PaaS（Platform as a Service）	開発・実行環境（言語ランタイム、DB、API）	自身のアプリケーションコード、データ	OS、ミドルウェア、インフラストラクチャ	Heroku（Web アプリ開発）、Google App Engine、AWS Elastic Beanstalk
IaaS（Infrastructure as a Service）	コンピュート（仮想サーバ）、ストレージ、ネットワーク	OS、ミドルウェア、アプリケーション、データ	物理サーバ、物理ネットワーク機器、データセンター施設	AWS EC2、Microsoft Azure 仮想マシン、Google Compute Engine
FaaS（Function as a Service）	関数実行環境、インフラ自動スケーリング	イベント応答関数のコード、トリガー設定	インフラ、OS、スケーリング、監視	AWS Lambda、Google Cloud Functions、Azure Functions

各層の理解のポイント

SaaS の特徴

ユーザは「ログインして使うだけ」。データ入力と利用者管理のみ担当

ベンダがすべてのインフラ・ソフト更新を管理するので、ユーザは常に最新版を使用

カスタマイズ性は低い（共通プラットフォーム、設定項目限定）

例：給与計算 SaaS、経費申請システムなど

PaaS の特徴

企業が自社アプリをコード書き込み、ベンダのプラットフォーム上で実行

「開発者が OS やミドルウェアを気にせず、アプリ開発に集中できる」が利点

DB やランタイム環境はベンダが提供・管理

例：新規 Web サービス開発、モバイルアプリ開発時に採用

IaaS の特徴

ベンダが物理インフラ（サーバ、ストレージ）のみ提供

ユーザが OS、ミドルウェア、アプリ、データを全て管理する自由度が最高

自由度と引き換えに、管理責任・スキル要求が高い

例：自社開発アプリを動かしたい企業

FaaS の特徴

関数（小さなコード片）単位で実行

ユーザが「イベント発生時に何をするか」の関数を書く

インフラのスケーリングは自動（サーバレス）

例：API レスポンス、定期処理（毎日深夜のバッチなど）

マルチクラウド・ハイブリッドクラウドの選択

複数のクラウドを組み合わせたり、クラウドとオンプレミスを混在させたりする運用形態が、現代の企業では一般的になっています。試験ではこれらの選択が「なぜ必要か」を問われることが多いです。

マルチクラウド（複数のクラウドプロバイダを同時利用）

定義と目的

AWS、Microsoft Azure、Google Cloud など、複数のクラウドプロバイダを同時に利用

ベンダロックイン回避：特定クラウドベンダへの依存を減らしたい

サービス継続性向上：1つのクラウドが障害を起こしても、他のクラウドが補完

コスト最適化：各ベンダのサービス・価格から最適なものを選択（ストレージはA社が安い、計算はB社が得意、など）

機能選択の自由度：特定機能が必要な場合、その機能に強いクラウドを選べる

課題と実務的注意

運用複雑性：複数環境の監視・管理が複雑化 → 統一的な管理ツール(HashiCorp Terraform等)の導入必須

スキル確保困難：AWS、Azure、GCP それぞれのスキル人材が必要 → コスト増加

データ移行・統合：複数クラウド間のデータ連携が難しい

試験での出題パターン：「複数クラウド導入で何が達成されるか」「運用負荷は実際に増えるのか」

ハイブリッドクラウド（オンプレミス＋パブリッククラウドの混在）

定義と使い分け

機密性・規制要件が厳しい業務 → オンプレミス（自社データセンター）で管理

変動負荷への対応、新規サービス → パブリッククラウドで柔軟に対応

具体的な事例

分野	オンプレミスで実施	パブリッククラウドで実施	理由
銀行	勘定系システム（顧客資産管理）	インターネット取引、モバイルアプリ	勘定系は法令要件・セキュリティ要件が極めて高い
製造業	生産管理システム（機密設計）	Web サイト、市場分析	生産技術は企業秘密、Web は公開情報
小売業	在庫・POS システム	EC プラットフォーム、レコメンド	在庫管理は現場で安定稼働必須、EC は負荷変動が激しい

メリット

既存投資（オンプレ）の活用

セキュリティ・規制要件に対応

柔軟性（クラウドの利便性）と堅牢性（オンプレの安定性）を両立

課題

システム間の連携設計の複雑さ

運用責任の分担（社内 vs クラウドベンダ）を明確にする必要

試験での出題パターン：「レガシーシステムを生かしながら、新規機能をクラウドで実装する場合の課題は」

第3章：経営情報システムの5段階発展モデル

TPS・MIS・DSS・SIS・EIS の役割分担

企業内のシステムは、「誰が何を使うか」という観点で5つの段階に分類されます。これらは独立しているのではなく、下層が上層のデータ基盤となるピラミッド構造になっています。

5つのシステムの定義と使い分け

システム	正式名称	主な利用者	主な目的	扱うデータ	処理の特性
TPS	Transaction Processing System	現場担当者、事務職員	日々の業務実行と記録	リアルタイム取引データ（売上、仕入、在庫）	リアルタイム処理、高速応答（ミリ秒単位）
MIS	Management Information System	課長・部長などの中間管理職	部門の短期実績把握と日常的管理判断	集計・集約データ（日報、週報、月報）	日次～週次更新、1日単位の遅延許容
DSS	Decision Support System	課長以上の管理職・企画部門	複雑な問題の「仮説検証」「シナリオ分析」	過去実績＋仮定値＋シミュレーション結果	オフライン分析、秒～分単位の応答
SIS	Strategic Information System	経営層（取締役・事業部長）	経営戦略の立案・実行と競争優位構築	外部環境情報（市場、競合、規制、技術動向）	戦略志向、中長期（3～5年）
EIS	Executive Information System	経営トップ（CEO・会長）	経営全体の「今」の状況把握と即座判断	経営KPI（売上、利益、ROI）、ダッシュボード	リアルタイム更新、高度に要約

階層間の流れと特徴

【経営トップ】
   EIS: KPI ダッシュボード（売上、利益、顧客満足度）をリアルタイム表示
    ↑
【経営層】
   SIS: 外部環境分析（競合動向、市場機会）＋内部資源分析で戦略立案
    ↑
【管理職】
   DSS: 複数シナリオを比較（「値下げしたら利益はいくらか」等を分析）
    ↑
【中間管理職】
   MIS: 部門の日次・週次実績をレポート（営業成績、コスト対比等）
    ↑
【現場】
   TPS: 取引を記録（売上入力、在庫受け入れ等）

各層の詳細理解

DSS（意思決定支援システム）の役割

特徴

複雑な意思決定を支援するため、「What-If分析」（～した場合どうなるか）を繰り返し実行

ユーザが仮定値を入力 → システムがシミュレーション → 結果表示 → 条件変更を対話型で実行

使用場面と具体例

新製品投入シミュレーション：「販売価格を10%下げた場合、利益はいくら減るか」「売上が予想の3割減でも黒字が維持できるか」

在庫・発注管理：「発注点を1,000ユニットに設定した場合、年間保管コストはいくらになるか」「リードタイム短縮で在庫をいくら削減できるか」

営業戦略：「地域別にどう営業活動を配分すれば、全体 ROI が最大化されるか」

重要な点：DSS は「過去実績」だけでなく「仮定・シミュレーション」を含むため、結果の精度は入力仮定に大きく依存します。試験では「シミュレーション結果の信頼性は入力データの品質で決まる」という点が出題されることもあります。

SIS（戦略情報システム）の役割

特徴

単なる「情報提供」ではなく、企業の競争戦略を実行するツール

外部環境（市場、競合、技術、規制）と内部リソースを統合的に分析

中長期（3～5年以上）の視点で新しいビジネスモデルや競争優位を創出

事例で理解する

企業・事例	SIS の役割
Amazon	EC プラットフォーム構築により、「本の小売」から「あらゆる商品のマーケットプレイス」へ戦略転換
金融機関	顧客データを統合分析し、顧客ライフステージに応じた提案営業を実現（顧客生涯価値最大化）
製造業（IoT活用）	機械のセンサデータをクラウド分析することで、「予防保全サービス」という新事業モデルを創出

EIS（エグゼクティブ情報システム）の役割

特徴

ユーザ：CEO、会長などの経営トップ

目的：経営全体の「今」を把握し、即座に判断・指示

データ形式：最高度に要約・集約（図表、ダッシュボード）

更新頻度：リアルタイム（またはリアルタイムに近い）

典型的な EIS の表示例

日次ダッシュボード：本日の売上（対前年比）、営業利益率、顧客獲得数、クレーム件数

経営KPI：ROI、キャッシュフロー、顧客満足度、従業員満足度

計画 vs 実績：予算対比のギャップを色分け表示（赤：未達、黄：注視、緑：達成）

リスク指標：為替変動の影響、金利上昇リスク、規制変更への準備状況

試験での問われ方：「CEO が毎朝確認するべき指標は何か」「四半期目標達成状況の即座把握にはどのシステムが最適か」

第4章：データウェアハウス（DWH）と分析基盤

データウェアハウスの4つの特性

データウェアハウス（Data Warehouse）は、経営分析のために複数のシステムから集めたデータを統合・蓄積する仕組みです。通常の営業システムのデータベースと異なり、分析に特化した構造を持っています。試験では「DWH の4つの特性を具体例で説明できるか」が頻出です。

DWH の4つの定義特性

DWH の定義は、4つの特性で構成されています。これらはすべて揃ってはじめて「DWH」と呼びます。

特性	英語での定義	意味と実務的背景	具体例
1. サブジェクト指向性	Subject-Oriented	分析軸を明確にして整理。「顧客別」「製品別」「地域別」など、経営上の主体ごとにデータを構成	通常の営業 DB は「取引」を中心に記録（時系列で入力順）。DWH は「顧客」中心に再整理し、顧客ごとの売上推移を即座に集計可能に
2. 統合	Integrated	複数のシステムのデータを統一形式に統合。売上 DB、在庫 DB、会計システムなど、バラバラなデータを共通言語（顧客ID、日付形式など）で統一	営業システムの「顧客コード」と会計システムの「得意先コード」が異なっていても、統一マスタで対応付けして統合
3. 非揮発性	Non-Volatile	一度書き込まれたら変更されない。過去のデータは決して修正・削除されず、完全履歴を保有	2025年1月の売上が100万円と記録されたら、2026年8月に「修正で50万円に変更」はしない。過去データの完全性
4. 時系列性	Time-Variant	同じ対象の過去から現在までの履歴を保有。顧客の購買動向、製品の価格推移、在庫数の月次変化など、時間軸を含めて追跡可能	顧客A の購買履歴：2023年1月は10万円、2023年6月は15万円、2024年1月は8万円、という履歴すべてを保有

DWH と通常のトランザクション DB の比較

分析用 DWH と業務用 DB は、目的が異なるため、設計思想が全く逆になっています。

項目	通常の DB（OLTP：業務処理用）	DWH（OLAP：分析用）
主な目的	日々の業務実行（入力・更新・照会）	経営分析・意思決定支援
データ更新	頻繁（リアルタイム）	定期的（夜間バッチ、日次、月次等）
データの形状	最新値のみ（履歴なし）、修正・削除あり	完全履歴保有、追記のみ
データ構造	正規化（重複排除、整合性重視）	非正規化（検索速度重視、冗長許容）
応答速度	高速必須（ミリ秒単位）	やや遅くても許容（秒～分単位）
典型的なデータ量	中規模（GB～数 TB）	大規模（数 TB～PB）
典型例	売上入力システム、在庫管理、会計システム	月次営業分析、顧客セグメンテーション、経営ダッシュボード

OLTP、DWH、データマート、データレイクを一枚で整理する

試験では、これらがすべて データを扱う仕組み として並ぶため混同しやすいです。違いは、何のために使うか、どんな形でためるか、誰が使うか にあります。

用語	主目的	主なデータ	形の決め方	典型的な使い方
OLTP	日々の取引処理	受注、入金、在庫更新	先に厳密に設計	登録、更新、照会
DWH	分析用の統合蓄積	複数システムの構造化データ	分析しやすい形に整えてから格納	全社横断分析
データマート	部門別・用途別の分析	DWH の一部を切り出したデータ	利用目的ごとに設計	営業用、財務用の分析
データレイク	元データの広域蓄積	ログ、画像、IoT、SNS、構造化データ	後で読み方を決める	後段の分析・機械学習

判断の順番は、日々の更新か、分析用の統合か、全社か部門か、先に形を決めるか後で決めるか です。営業部門だけが見る集計基盤 ならデータマート、生ログをためて後から用途を考える ならデータレイクです。

DWH構築のプロセス（ETL）

DWH の物理設計：スター・スノーフレークスキーマ

DWH 内のデータは、単にまとめるのではなく、分析効率を高めるための特定の設計パターンで配置されます。

スター・スキーマ（Star Schema）

構造

中央に「ファクトテーブル」（売上、出荷、返品などの事実・取引）

周囲に「ディメンションテーブル」（顧客、製品、時間、地域などの属性）を配置

形が星に見えることから「スター」スキーマと呼ぶ

図解例

         ┌─ 顧客ディメンション ─┐
         │                      │
時間ディメンション ← ★ファクトテーブル（売上） → 製品ディメンション
         │                      │
         └─ 地域ディメンション ─┘

特徴

シンプル：直感的で理解しやすい

高速：ディメンションテーブル（小さい）とのジョイン（結合）が少ないため、クエリが高速

使用場面：一般的な経営分析、OLAP に最適

スノーフレーク・スキーマ（Snowflake Schema）

構造

スター・スキーマをさらに正規化した形

ディメンションテーブルを複数段階に分割

形が雪の結晶（スノーフレーク）に見えることから命名

例：顧客ディメンションを分割

顧客テーブル（顧客ID、顧客名）
    ↓
業種マスタ（業種ID、業種名）
    ↓
地域マスタ（地域ID、地域名）

特徴

ストレージ効率：正規化により、データ冗長性を削減

クエリ複雑性増加：複数テーブルの結合が増えるため、クエリが複雑化・遅延化の可能性

選択基準

ストレージが限定的 → スノーフレーク

分析速度が重要 → スター

データマート：DWH の部門別サブセット

定義

DWH から特定部門・ビジネステーマ用に抽出・加工されたデータベース

営業部門向けデータマート、財務部門向けデータマートなど

メリット

各部門の分析に特化した構造 → クエリが単純化、応答速度向上

部門別に異なるディメンションを持つことで、柔軟な分析可能

デメリット

部門ごとに構築・保守が必要 → コスト増加

データ一貫性の保証が難しい（営業と財務で売上定義が異なる、など）

ETL：DWH へのデータ移入パイプライン

DWH を構築・維持するために、複数のシステムからデータを取り込み、整形し、蓄積する一連のプロセスが ETL です。試験では「各フェーズの役割」を問われることが多いです。

フェーズ	英語	役割	具体的な作業例
E	Extract（抽出）	複数の源システムからデータを取り出す	販売 DB から日次売上、在庫 DB から在庫数、会計 DB から経費レコードを抽出
T	Transform（変換）	データを分析用に整形・統一・品質確保	日付形式を統一（"2025/1/1"と"01/01/2025"を統一）、通貨換算、空白・欠損値の補完、重複排除、不正値削除
L	Load（ロード）	加工済みデータを DWH に書き込み	ステージング領域で最終検証 → DWH 本体に反映（追記のみ）

実行タイミング

バッチ処理が一般的：毎夜間、毎週末、毎月末など

最近はストリーミング処理（リアルタイム近い）も増加

第5章：OLAP と BI による分析・可視化

OLAP（多次元分析）の5つの操作

OLAP（Online Analytical Processing）は、DWH に蓄積されたデータを「多次元」「対話的」に分析する仕組みです。ユーザが「この角度から見たい」と条件を変えるたびに、瞬時に結果が更新される点が特徴です。試験では「5つの操作の定義と使い分け」が頻出です。

5つの基本操作の定義と具体例

操作	説明	次元の動き	具体例
スライス（Slice）	1つの次元を固定して「切り出す」	1次元に固定値	「2025年1月」に固定し、製品別・地域別の売上を表示
ダイス（Dice）	複数の次元を同時に絞り込む「部分立方体」を取出	複数次元を範囲限定	「2025年1月～3月」「東京・神奈川」「飲食料品」に限定した売上
ドリルダウン（Drill-down）	粗い粒度から細い粒度へ「掘り下げる」	上位→下位へ階層移動	全国売上 → 地域別売上 → 営業所別売上 → 担当者別売上へ段階的詳細化
ドリルアップ（Roll-up）	細い粒度から粗い粒度へ「集約する」	下位→上位へ階層移動	担当者別売上 → 営業所別売上 → 地域別 → 全国売上へ段階的に要約
ピボット（Pivot）	行と列を入れ替えて「視点を回転」させる	軸の交換	「製品（行）×月（列）」の表を「月（行）×製品（列）」に転置

実務的理解：データ立方体を想像する

OLAP の基本は「3次元キューブ（立方体）」です。立方体の3つの面が「時間」「製品」「地域」で、それぞれの軸上でスライス・ダイス・ドリルダウンを行うと考えると理解しやすいです。

【時間軸（年/月/日）】
    ▲
    │
    ├─ 全国売上 ── 【地域軸（全国/地方/県/市区町村）】
    │      │
    │      └─【製品軸（全製品/カテゴリ/品種）】
    │
ドリルダウン：日別 → 時間軸を詳細化
スライス：2025年に固定 → 時間軸を固定し、地域×製品の 2次元表
ダイス：2025年 & 関東 & 飲料 → 複数軸を制限
ピボット：行列を交換 → 見方を変える

OLAP と OLTP：「何が異なるか」の本質

OLAP と OLTP（日常業務システム）は、根本的に目的が異なるため、あらゆる設計が逆になります。試験では「なぜこんな設計にするのか」の背景を問われることがあります。

観点	OLAP（分析用）	OLTP（業務用）	背景
目的	経営分析・意思決定支援	日々の業務実行（トランザクション処理）	分析は少量の複雑クエリ、業務は大量の単純クエリ
データ形式	多次元キューブ、DWH	リレーショナル DB	分析は複数角度から見たい、業務は単純なテーブル構造で十分
クエリ例	「過去3年間、顧客セグメント別に売上トレンドを表示」	「顧客A の請求額を更新」	分析は集計・複数テーブル結合、業務は単純 CRUD
応答時間	秒～数分単位でも許容	ミリ秒単位の高速応答必須	分析は時間かかっても成果が大事、業務は遅延で業務停止
更新頻度	低頻度（夜間バッチ、日次、月次）	高頻度（リアルタイム）	分析用データは古くても良い、業務データは最新必須
データ保持	完全履歴（過去データ削除・更新なし）	最新値のみ（古いデータ削除・修正あり）	分析は歴史必要、業務は現在値のみ必要
スキーマ	非正規化（ディメンションモデル）	正規化（3NF 等）	分析は検索速度重視、業務は更新の整合性重視

ROLAP、MOLAP、HOLAP の違い

OLAP は分析の考え方ですが、その実装方法には複数あります。過去問では リレーショナル DB を使うか、多次元キューブを使うか、両方をどう併用するか を問う形で出やすいです。

方式	どこに主にデータを持つか	強み	注意点
ROLAP	リレーショナル DB / DWH	明細データに強く、既存 DB 技術を活かしやすい	集計済みキューブより応答が遅くなりやすい
MOLAP	多次元キューブ	集計済みデータの分析が高速	明細データや大規模詳細更新には不向き
HOLAP	集計はキューブ、詳細は RDB	集計の速さと明細参照を両立しやすい	構成が複雑になる

MOLAP = Multi-dimensional、ROLAP = Relational、HOLAP = Hybrid と語尾で切ると覚えやすいです。集計中心で速さを優先 なら MOLAP、詳細データまで柔軟に扱いたい なら ROLAP、その折衷が HOLAP です。

BI（ビジネスインテリジェンス）の主要機能

BI は「データをいかに見える化し、理解しやすくするか」に特化した技術・プロセス・ツール群です。DWH で蓄積したデータを、OLAP で分析し、BI で「わかりやすく表現する」という流れです。

BI の4つの主要機能

機能	説明	対象ユーザ	具体例
ダッシュボード	重要指標（KPI）をリアルタイム表示。信号機のように色分け（赤：未達、黄：要注視、緑：達成）	経営層・管理職	CEO 朝礼用ダッシュボード：本日売上（対前年比）、利益率、顧客満足度スコア
定型レポート	定期的に自動生成・配信される報告書。毎日・毎週・毎月の集計	管理職・営業マネージャー	日次営業報告書（営業所別売上）、週次棚卸日報、月次決算サマリー
アドホッククエリ	ユーザが自由に条件を指定して分析。「この3年間で、東京営業所の顧客A の購買パターンはどう変わったか」	データ分析担当者・企画部門	営業報告：東京・2023～2025年・製品カテゴリ別・月別売上
可視化（ビジュアライゼーション）	グラフ・地図・散布図など直感的な表現で、パターン・トレンド・外れ値を素早く認識	全員（発表資料・会議資料）	売上トレンド折れ線グラフ、地域別売上分布地図、顧客満足度レーダーチャート

BI とデータマイニング：「見える化」 vs 「未知パターン発見」

試験では「BI とデータマイニングは何が違うか」がよく問われます。本質的な違いを理解することが重要です。

視点	BI（ビジネスインテリジェンス）	データマイニング
目的	既知の指標を「わかりやすく表示」	隠れた規則・未知パターン「自動発見」
事前の知識	見たい指標が明確に決まっている	何が隠れているか事前に不明
分析手法	集計、グラフ化、比較	統計手法、機械学習アルゴリズム
出力結果	わかりやすい報告書、ダッシュボード	意外な相関、新しい顧客セグメント、パターンルール
所要時間	短い（既知指標なので定型作業）	長い（試行錯誤、手法選択、検証）
具体例	「今月の売上は1,000万円で、対前月比+15%」を赤字で警告表示	「ビール購買者の30%がおむつを同時購入」という未知の関連パターンを発見

試験での出題パターン

「経営層が毎朝確認すべき売上数字 → BI」

「顧客購買パターンの未知相関を発見したい → データマイニング」

KPI 管理と BI ダッシュボード

KPI の定義と役割

KPI（Key Performance Indicator）は、企業の経営目標達成度を定量的に測定する重要指標です。抽象的な目標（「利益を増やす」）を、具体的で測定可能な指標（「営業利益率 5% 以上」）に落とし込みます。

企業 / 部門 / 施策別の典型的な KPI

対象	典型的な KPI
企業全体	売上高、営業利益、営業利益率（%）、ROI、株主収益率（ROE）
営業部門	営業売上、営業利益、新規顧客獲得数、顧客獲得コスト（CAC）、顧客生涯価値（LTV）
製造部門	生産効率、不良率、コスト原価、在庫回転率、リードタイム
顧客サービス	顧客満足度スコア（NPS）、対応時間、サポート品質スコア
人事部門	従業員一人当たり生産性、離職率、育成プログラム完了率

KPI ダッシュボードの実装

KPI ダッシュボードは、複数の KPI を「一覧で、わかりやすく」表示するツールです。

ダッシュボード表示の標準パターン

信号機形式：緑（達成）、黄（要注視）、赤（未達）で状況を色分け

数値表示：目標値 vs 実績値の並列表示＋達成度 %

トレンド：折れ線グラフで過去4週間～1年の推移を表示

アラート機能：閾値を逸脱したら通知（メール、SMS、画面ポップアップ）

実装例：CEO 日次ダッシュボード

売上：¥980万 / 目標¥1,000万 （達成度98%） [黄] ↓前日比-2%
利益率：4.5% / 目標5.0% （達成度90%） [黄]
顧客満足度：4.2/5.0 （達成度84%） [黄]
現金残高：¥50億 / 目標¥45億以上 [緑] ↑増加
新規顧客数：45件 / 月目標200件 （達成度22%） [赤]
→ 赤の指標「新規顧客数不足」について、営業部門に確認要

このダッシュボードにより、CEO は毎朝「どこに問題があるか」を 3 分以内に把握できます

第6章：データマイニングと応用技術

データマイニングの定義と5つの主要手法

データマイニング（Data Mining）とは、大量のデータから「隠れたパターン」「規則性」「傾向」を自動的に発見する技術です。BI が「既知の指標を見える化」するのに対し、データマイニングは「未知のパターン発見」に特化しています。

データマイニングの5つの主要手法：

手法	目的	適用例	出力
分類（Classification）	新しいデータをいくつかのカテゴリに分ける	与信審査（融資OK/NG）、メールスパム判定	カテゴリ予測、確信度スコア
クラスタリング（Clustering）	データを「似た者同士」でグループ化（カテゴリ不明事前）	顧客セグメンテーション、市場分割	グループの特性、顧客プロファイル
アソシエーション分析（Association）	「Aを買った人は B も買いやすい」という関連性を発見	バスケット分析、推薦システム	関連ルール、信頼度、支持度
回帰（Regression）	数値データの関係式を求める	売上予測、在庫需要予測	予測式（y = ax + b）、精度
異常検知（Anomaly Detection）	正常データから外れた異常値を検出	不正取引検知、機械故障予測	異常スコア、フラグ

バスケット分析（アソシエーション分析の応用例）

バスケット分析の定義

POS データ（購買履歴）から、「何と何が一緒に購入されやすいか」を分析

小売業、EC 事業で最頻出

主要指標

指標	計算式	意味
支持度（Support）	A と B が同時購買の割合 / 全取引	商品組み合わせがどれくらい頻繁に生じるか
信頼度（Confidence）	A と B が同時購買の割合 / A を購買した全取引（B 購買有無問わず）	A を買った人のうち何% が B も買うか
リフト（Lift）	信頼度 / B 全体購買率	A と B は独立的か、それとも正の相関があるか

事例

ビール＋おむつ：バスケット分析で「男親がビール買い物時におむつを同時購入」パターン発見 → 店舗レイアウト配置工夫

テキストマイニング

テキストマイニングとは、非構造化テキスト（顧客レビュー、ニュース記事、SNS投稿）から有用な情報を自動抽出する技術です。

主な応用

応用	内容	具体例
感情分析（Sentiment Analysis）	テキストのポジティブ・ネガティブ度合いを判定	商品レビュー「良い」「悪い」の自動分類、顧客満足度推測
キーワード抽出	テキストから重要な単語・フレーズを自動抽出	ニュース記事から「注目キーワード」を抽出、トレンド分析
文書分類	テキストを複数のカテゴリに自動分類	サポート問い合わせを「製品不具合」「操作方法」「販売」に自動振り分け
要約	長いテキストから要点を自動抽出	ニュース記事の要約生成、会議議事録の自動要点化

Web マイニング

Web マイニングとは、Web ページ、Web ログ、Web グラフから有用な情報を発掘する技術です。

主な形態

形態	対象	応用例
Web コンテンツマイニング	Web ページの内容（テキスト、画像、構造）	検索エンジン、推薦システム
Web 構造マイニング	リンク構造（どのサイトがどのサイトを参照）	PageRank（Google の検索順位アルゴリズム）
Web ユーザ behavior マイニング	ユーザのアクセスログ（訪問順序、滞在時間）	Webサイト最適化、ユーザ行動理解

第7章：IoT とエッジコンピューティング

IoT（Internet of Things）の定義と構成層

IoT（Internet of Things）とは、センサ・デバイスがデータを収集し、ネットワーク経由でクラウドに送信、分析・活用する仕組みです。試験では「単なる機器の話」ではなく、データの流れ全体と現場へのフィードバックまで含めて出題されます。

IoT の4層構成：

┌───────────────────────────────────────────┐
│  Layer 4: アプリケーション・サービス       │
│  ユーザへの価値提供（レコメンド、警告）   │
├───────────────────────────────────────────┤
│  Layer 3: クラウド・分析基盤              │
│  DWH・OLAP・機械学習・BI                 │
├───────────────────────────────────────────┤
│  Layer 2: ネットワーク                    │
│  WiFi・4G/5G・有線 LAN、セキュリティ     │
├───────────────────────────────────────────┤
│  Layer 1: デバイス・センサ層              │
│  温度センサ、カメラ、RFID タグ            │
└───────────────────────────────────────────┘

各層の詳細：

層	役割	具体例
デバイス・センサ	データ収集	工場の機械温度センサ、農業の土壌水分センサ、物流の GPS トラッカー
ネットワーク	データ伝送	5G、WiFi、LoRaWAN（低消費電力通信）、セキュアな通信路
クラウド・分析基盤	データ蓄積・処理	DWH への蓄積、OLAP による多次元分析、機械学習による異常検知
アプリケーション	ユーザへの価値提供	異常通知アラート、需要予測、最適な保全時期の提示

IoT の活用事例

製造業における IoT

課題：機械の故障・ダウンタイムを予防したい

実装：機械センサで振動・温度・音をリアルタイム収集 → クラウド分析 → 異常予兆を機械保守担当者に通知

効果：予防保全実現、ダウンタイム削減、保守コスト最適化

物流・流通における IoT

課題：在庫の可視化、配送の最適化

実装：商品に RFID タグ装着 → 倉庫・店舗の読み取り機で自動認識 → クラウドで在庫管理システムに反映

効果：棚卸作業削減、欠品防止、配送路最適化

農業における IoT

課題：灌漑・肥料のタイミング最適化、病害虫早期発見

実装：田畑に土壌水分・pH・光合成センサ設置 → データ分析 → 農家へ灌漑・施肥タイミングを推奨

効果：収量向上、農薬削減、労力削減

エッジコンピューティング

エッジコンピューティングの定義

すべてのデータをクラウドに送らず、デバイスやネットワークエッジ（末端）で処理

対比：クラウドセントリック（全データをクラウドに集める）

メリット/デメリット：

項目	メリット	デメリット
通信量・遅延	データ量削減、応答時間短縮、リアルタイム処理可能	エッジ側の処理負荷増加
セキュリティ	機密データをローカル保有（外部送信なし）	エッジ側の保全責任が増える
コスト	ネットワーク帯域幅コスト削減	エッジデバイスの計算能力向上コスト
シナリオ	工場での機械異常の即座対応、自動運転、遠隔地のセンサ処理	リアルタイム性が要求されない集計分析

クラウドとエッジの使い分け

処理内容	推奨場所	理由
機械異常の即座検知・停止	エッジ	遅延は許されない、リアルタイム重要
過去1年の季節トレンド分析	クラウド	大量データ蓄積・複雑計算に適する
画像認識による物体検出（カメラ → アクション）	エッジ	応答時間重要、通信量削減
KPI ダッシュボード用のデータ集約	クラウド	全社横断の統合分析に適する

第8章：ビッグデータと 5V フレームワーク

ビッグデータの定義と5つの V

ビッグデータとは、従来のデータベース管理ツールで処理困難な、大規模・複雑・高速変化するデータ集合です。

ビッグデータの5つのV：

V	説明	例
Volume（量）	データ量が大規模（GB → TB → PB）	SNS 100億件/日の投稿、EC サイトの全ユーザアクション
Velocity（速度）	データが高速で流入・更新	リアルタイムセンサデータ、高頻度トレーディング
Variety（多様性）	構造化・非構造化・半構造化データの混在	数値データ + テキスト + 画像 + 動画 + JSON ログ
Veracity（信頼性）	データの品質・正確性のばらつき	センサ故障時のノイズ、転記ミス、欠損値
Value（価値）	分析から生み出される価値	顧客セグメント発見、異常検知、売上予測精度向上

ビッグデータの処理基盤

従来の RDBMS（リレーショナルデータベース）の限界

単一サーバでは PB レベルのデータ量を処理できない

リアルタイム更新が困難

非構造化データ（画像、動画、テキスト）の扱いが苦手

分散処理基盤の登場

技術	説明	用途
Hadoop	分散ファイルシステム（HDFS）と MapReduce による大規模バッチ処理	大量ログの集計・分析（数時間かかっても OK）
Spark	Hadoop より高速なメモリ内分散処理	リアルタイムストリーム処理、機械学習
Kafka	ハイスループットなメッセージング・ストリーム処理基盤	IoT センサデータの連続流入処理
Data Lake	様々な形式のデータを一元蓄積	後から用途に応じたデータ加工・抽出

ビッグデータ活用プロセス

1. データ収集
   ↓（API、センサ、ログから大量取得）
2. 保存・蓄積（Data Lake、DWH）
   ↓
3. クレンジング・加工（欠損値補完、ノイズ除去）
   ↓
4. 分析（OLAP、データマイニング、機械学習）
   ↓
5. 可視化・インサイト生成（BI、ダッシュボード）
   ↓
6. アクション実行・フィードバック
   ↓（KPI 改善、新規施策立案）
7. 回る（continuous improvement）

ビッグデータと IoT・クラウドの統合

典型的なアーキテクチャ：

IoT センサ
  ↓（高速度データ流入）
ストリーム処理（Kafka・Spark Streaming）
  ↓（リアルタイム異常検知、簡易分析）
クラウド（AWS・Azure・GCP）
  ↓
 ├─ Data Lake（生データ保存）
 ├─ DWH（加工済み）
 └─ 機械学習パイプライン
  ↓
 BI・ダッシュボード
  ↓
ユーザへの価値提供（アラート、推奨）

事例：予測保全（Predictive Maintenance）

工場機械の温度・振動・電力消費を IoT センサで連続監視

クラウドで過去履歴から「故障のパターン」を機械学習

異常パターン検知時に保守チームに通知（ダウンタイム防止）

典型的なつまずき

つまずき1：クラウド層の混同

誤り：「SaaS も PaaS も IaaS も全部クラウドなんでしょ」

正解：

SaaS は「完成品ソフト」（管理項目最小）

PaaS は「開発基盤」（自社アプリは自分たちで書く）

IaaS は「インフラ貸し」（OS から上は自分たちで用意）

見分け方：「自社で管理する範囲は何か」を問題文から読み取る

つまずき2：DWH・OLAP・BI を同一視

誤り：「DWH、OLAP、BI って結局同じ分析ツールのことじゃん」

正解：

DWH：「何を蓄積するか」（データの倉庫・整理）

OLAP：「どう分析するか」（多次元集計・ドリルダウン）

BI：「結果をどう見せるか」（ダッシュボード・レポート）

流れ：DWH でデータ集約 → OLAP で分析 → BI で可視化

つまずき3：データマイニング＝ BI と思う

誤り：「データマイニングと BI は同じこと」

正解：

BI：見たい指標が事前に決まっている（売上トレンド、利益率）

データマイニング：何が隠れているか事前に不明（未知パターン発見）

見分け方：「隠れたパターン」「未知の相関」「新しいセグメント」とあれば データマイニング

つまずき4：アウトソーシングを単なるコスト削減と見る

誤り：「アウトソーシング＝ただ安い」

正解：責任分界、契約内容、セキュリティ、柔軟性を総合評価

試験での問われ方：「給与計算をアウトソーシングした場合、情報セキュリティは誰の責任か」

つまずき5：IoT を「センサ機械」だけと考える

誤り：「IoT は単に機械にセンサをつけるだけ」

正解：センサデータ → クラウド蓄積 → 分析 → 現場フィードバック → 改善

出題パターン：「IoT データをどう意思決定につなげるか」

つまずき6：ビッグデータ＝単に大量データ

誤り：「ビッグデータは要するにデータがでかいだけ」

正解：Volume + Velocity + Variety + Veracity + Value の5つ視点。特に Variety（非構造化混在） と Value（生み出される価値） が重要

つまずき7：オフショア＝常に最適解

誤り：「コストが低い海外委託が最高」

正解：

オフショアは時差・文化差による遅延・品質リスク

守秘性が高い業務、リアルタイムコミュニケーション必須 → 国内・ニアショア推奨

大規模開発・コスト重視 → オフショア検討

つまずき8：マルチクラウド＝常に推奨

誤り：「複数クラウド使うのが最新の優れた戦略」

正解：

マルチクラウドの利点：ロックイン回避、柔軟性

マルチクラウドの課題：運用複雑性、スキル確保困難、コスト増加の可能性

結論：戦略的必要性がある場合のみ。単一クラウド深掘りが先

つまずき9：OLTP と OLAP をどちらも「データベース利用」とだけ覚える

誤り：「どちらも DB を使うのだから同じ」

正解：OLTP は 日々の更新処理、OLAP は 分析処理 です。更新が頻繁か、履歴を持つか、応答に何を求めるか で切り分けます。

つまずき10：データマートとデータレイクを同じ「分析用保存先」と思う

誤り：「どちらも分析に使うので同じ」

正解：データマートは DWH から目的別に切り出した構造化データ、データレイクは 元データを形式のままためる場所 です。部門別の使いやすさ を重視するのか、後から広く活用する素材置き場 なのかで分かれます。

つまずき11：ROLAP、MOLAP、HOLAP の違いを語尾だけで流す

誤り：「全部 OLAP の種類だから、なんとなく高速分析用」

正解：ROLAP は リレーショナル DB ベース、MOLAP は 多次元キューブベース、HOLAP は 両者の併用 です。どこにデータを持つか と 集計の速さ / 明細の扱いやすさ を対で覚えてください。

問題を解くときの観点

観点1：どの「層」が問われているか

問題を読んだら、まず以下のどれか判別：

外部資源活用層：アウトソーシング、BPO、ASP、ハウジング、ホスティング、クラウド（IaaS/PaaS/SaaS）

データ蓄積層：DWH、データマート、ETL

分析層：OLAP、データマイニング、BI、KPI

現場データ層：IoT、センサ、エッジコンピューティング

→ 問題文のキーワード（「委託」「責任」「蓄積」「分析」「可視化」「予測」「発見」）で判別

観点2：「自社 vs ベンダ」の責任分界はどこか

クラウド関連問題では、以下を必ず確認：

インフラ（サーバ、ネットワーク）は誰が管理するか → IaaS ならユーザ側、SaaS ならベンダ側

アプリケーションは誰が開発するか → PaaS ならユーザ側、SaaS ならベンダ側

データのセキュリティは誰の責任か → 通常はユーザ側

アウトソーシング関連問題では：

マイナンバー・個人情報は委託先に預けても情報管理責任はユーザ側

システム障害時、どちらが対応するか → 契約に明記

観点3：「既知 vs 未知」で手法を区別

問題文に以下のキーワードがあれば：

キーワード	手法	理由
「見える化」「可視化」「トレンド表示」	BI	既知の指標を表示するため
「発見」「隠れた」「パターン」「相関」	データマイニング	未知の規則を発見するため
「どのくらい」「月別・地域別」「ドリルダウン」	OLAP	多次元分析のため
「1年分の実績を蓄積」「統合」	DWH	分析用データ蓄積のため
「日々の受注入力」「在庫更新」「会計記帳」	OLTP	日常業務の更新処理だから
「営業部門だけの分析基盤」	データマート	DWH の用途別サブセットだから
「ログや画像を元の形式でためる」	データレイク	後で読み方を決める保存先だから

観点4：IoT 問題は「流れ全体」で読む

IoT 関連問題では、以下の流れをたどる：

1. センサで何を計測するか
   ↓（問題文から確認）
2. データをどこに送るか（クラウド？エッジ？）
   ↓
3. どう分析するか（リアルタイム異常検知？長期トレンド分析？）
   ↓
4. 結果をどう活用するか（予防保全？需要予測？）
   ↓
5. 現場にどうフィードバックするか（アラート？ダッシュボード？）

→ この全流れ回答できると、出題者の期待に応える

観点5：複合的な選択肢は「比較表」で整理

試験問題で「SaaS・PaaS・IaaS・オンプレの中から最適なものを選べ」などの場合：

自社スキル（開発能力はあるか）

初期投資（予算制約）

運用負荷（24時間体制できるか）

セキュリティ要件（機密度が高いか）

この4軸で比較し、問題文の制約に合うものを選ぶ

観点6：DWH 関連問題は「4特性」で判別

「このシステムは DWH か、通常の DB か」と問われたら、以下4つをチェック：

サブジェクト指向か：顧客別・製品別に整理されているか → YES ならデータマート or DWH

統合されているか：複数システムから統合か → YES なら DWH 候補

非揮発性か：過去データは変更されないか → YES なら DWH 候補

時系列か：時間軸の履歴を保有しているか → YES なら DWH

4つとも YES なら DWH

観点7：OLAP 実装方式は「どこにデータを持つか」で切る

キューブ、リレーショナル、ハイブリッド のどれかが出たら、次の順で整理します。

集計済みの多次元キューブを主に使うか

明細データをリレーショナル DB に持つか

集計はキューブ、詳細は RDB という併用か

この順で見ると、MOLAP、ROLAP、HOLAP を語尾だけでなく構造で判定できます。

確認問題

問1：クラウド層と責任分界

問題

あるベンチャー企業は、新規開発するスマートフォンアプリを外部サービスで実現したいと考えています。以下の4つのサービス形態の中から、「アプリケーション開発企業がアプリのコード自体を書き、その実行環境と DB をベンダから借りる」というニーズに最適なものを1つ選んでください。

IaaS
PaaS
SaaS
ハウジング

解答

正答：2. PaaS

解説

SaaS（選択肢3）：完成したアプリケーションをベンダが提供。ユーザは設定・利用のみ。開発企業がコード自体を書く余地はない。
IaaS（選択肢1）：インフラ（サーバ、ストレージ）のみ。OS・ミドルウェア・アプリは全部ユーザが用意する。開発と運用の負担が大きく、DB 管理も自分たちで実施必要。
PaaS（正答）：開発実行基盤をベンダが提供。開発企業がコード書く → ベンダの基盤にアップロード → 自動実行。DB も基本機能付き。まさに「開発企業がコード書く＋基盤は借りる」のニーズ。
ハウジング（選択肢4）：物理サーバの管理受託。クラウドではなく、昔のデータセンター委託。

問2：DWH と OLAP の役割

問題

ある製造企業は、営業、製造、在庫の3つのシステムから月次で売上・原価・在庫データを集め、経営層向けに「月別売上推移」「製品別利益率」「地域別営業成績」などを分析する仕組みを構築しました。

以下の記述の中で、正しいものを2つ選んでください。

この仕組みで「複数システムのデータを統合し、分析用に蓄積する部分」を DWH と呼び、「多次元的にデータを切り出し、ドリルダウンして分析する部分」を OLAP と呼ぶ。
DWH があれば OLAP は不要である。
OLAP の「スライス」操作で「2025年1月」を固定し、製品別・地域別に売上を表示することが可能である。
経営層が「今月の営業成績をリアルタイム表示するダッシュボード」を見る場合、その背後の DWH は常にリアルタイム更新される必要がある。

解答

正答：1 と 3

解説

選択肢1（正）：DWH は複数システムから統合・蓄積、OLAP は多次元分析・操作。役割分担が正確。
選択肢2（誤）：OLAP は蓄積されたデータを「どう分析するか」の仕組み。DWH だけでは、分析操作ができない。
選択肢3（正）：OLAP の「スライス」は1つの次元を固定。「2025年1月に固定」して、他の次元（製品別・地域別）を分解できる。
選択肢4（誤）：DWH は分析用蓄積が目的。リアルタイム更新より「過去データの完全履歴保有」が重要。リアルタイムダッシュボードなら、別途オンプレ DB やキャッシュを使う（DWH ではなく）。

問3：BI・データマイニング・IoT の統合

問題

ある食品メーカーは、全国50の工場に温度・湿度・生産ラインの動作状態を監視するセンサを設置しました。このセンサデータを活用し、①製品品質低下の予防、②営業店舗への在庫配分最適化、を実現したいと考えています。

以下の施策の中で、①の予防と②の最適化にそれぞれ適切なものを組み合わせて選んでください（1つ選択）。

①BI による現在の工場状態ダッシュボード表示、②データマイニングで過去販売パターンから需要予測
①データマイニングで過去の異常データから故障パターン学習、②BI で在庫状況を日次表示
①エッジコンピューティングで工場内で異常検知、②データマイニングで在庫・販売相関パターン発見
①DWH にセンサデータ蓄積のみ、②OLAP で在庫の多次元分析

解答

正答：3

解説

①予防保全には「未知パターン発見」が必須 → データマイニングまたはエッジの異常検知
- BI は「すでに指標が決まっている」（現在状態表示）であり、予防保全は「故障パターン未知」なので不適切
- エッジコンピューティングで工場内で即座に異常検知できれば、クラウド依存せず高速対応可能（IoT のメリット活用）
②在庫配分最適化には「販売パターン分析」が必須 → データマイニング
- BI は「在庫数表示」のみで、配分最適化（どこに何を送るか）の判断まで支援しない
- データマイニングで「特定店舗の在庫・販売・季節パターン」の相関発見 → 配分予測可能

選択肢1：①BI は不適（現在状態のみ）選択肢2：①BI では予防パターン学習できない；②OLAP は確定データの多次元集計のみで、「新しいパターン発見」できない選択肢4：①DWH蓄積だけでは何も判断できない；②OLAP は多次元集計で「パターン発見」まで行わない

問4：OLTP・DWH・データマート・データレイクの判定

問題

次の説明に最も近い用語を答えてください。

日々の受注入力や在庫更新をリアルタイムで処理する仕組み
複数システムの構造化データを統合し、分析しやすい形で蓄積する仕組み
DWH から営業部門向けだけを切り出した分析用データ集合
IoT ログや画像を元の形式のまま蓄積し、後で分析方法を決める保存先

解答

OLTP
DWH
データマート
データレイク

ポイント

日々の更新、全社横断分析、部門別利用、素材のまま蓄積 のどれかに言い換えると判定しやすくなります。

問5：ROLAP・MOLAP・HOLAP の使い分け

問題

次の説明に最も近い方式を答えてください。

明細データをリレーショナル DB に持ち、既存 SQL 資産を活かして分析したい
集計済みの多次元キューブを使い、経営指標を高速に切り替えて見たい
集計は高速に見たいが、必要に応じて明細データも掘り下げたい

解答

ROLAP
MOLAP
HOLAP

ポイント

Relational、Multi-dimensional、Hybrid のどれかへ日本語で戻すと、語尾暗記より安定します。

外部資源活用と意思決定支援システム

関連マップ

このページは役に立ちましたか？

On this page