観点一覧
検討項目カテゴリの樹形図(中カテゴリまでのサマリ)
プロジェクト共通項目

システム化個別項目
オンプレミス

A1.構築プラットフォーム

収集対象データ種別

B1.データ収集
クラウド

収集インターフェース

ハイブリッドデータの到達性保証

システム環境のポータビリティ(可搬性)

データ流入

データソース・データ基盤間のスコープ

通信経路

データ基盤-データ活用間のスコープ

初期データ移行・コピー

見積範囲

収集スケジュール

A2.「データ基盤」のスコープ

A3.コスト見積もり
データ基盤そのものにかかるコスト

データ容量

B2.データ蓄積
初期検討・構築要員にかかるコスト

データのライフサイクル

必須体制

バックアップ

必要のロール

蓄積プラットフォーム

A4.推進体制

処理パターン（データマート作成）

データソースとの連携

A5.別システムとの連携

B3.データ加工活用先との連携

処理パターン（機械学習の前処理）

その他

処理パターン（その他）

データ収集

加工スケジュール

データ蓄積

実装インタフェース

データ加工

処理プラットフォーム

A6.機能・サービスのスコープ

データ活用

可視化・BI

B4.データ活用
AI/機械学習

ストリーム収集/処理

データの到達性保証
通信提供I/F

提供スケジュール

メッセージ(送受信データ)

B5.ストリーム収集
収集I/F

データ流入
バックアップラインストリーム収集プラットフォーム

データの受信B6.ストリーム処理
データの処理運用

ストリーム処理プラットフォーム© 2021 NTT DATA Corporation

プロジェクト共通項目
項番

大カテゴリ

中カテゴリ
オンプレミス

中カテゴリの説明
オンプレミス環境にデータ基盤を構築する

小カテゴリ

構築プラットフォーム-

小カテゴリの説明-

検討における注意点、補足事項
データ活用基盤をオンプレミス上に構築するか、クラウド上に構築するか。

クラウド

パブリッククラウド環境にデータ基盤を構築する--

既存システムのクラウドシフトを検討することも多く、比較を求められる場合がある。

A.1.3

ハイブリッド構成

オンプレミス/クラウドを組み合わせた構成--

オンプレミスのデータソースとクラウド上のデータ基盤を繋ぐ構成をとるケースが多い。
オンプレミス-クラウド間の通信経路のセキュリティ、データ転送に掛かる時間を考慮すること。

A.1.4

システム環境のポータビリティ(可搬性)パブリッククラウド-オンプレミス間のシステム移行性--

ポータビリティを考慮するかどうかは、主にパブリッククラウドを利用する場合のコンポーネント選択に影響を与える。一概に良し悪しではなく、プロジェクト特性に合わせて検討すること。

A.1.1
A.1.2

■ポータビリティ重視の場合
パブリッククラウドが提供するSaaS型のサービスを多く利用すると他のプラットフォームでの動作が難しいケースがある(※)。一例として、各種コンピューティングのインスタンス上にOS/ミドルウェア/アプリケーションを構築する設計が挙げられる。
※パブリッククラウドなどのベンダが他の著名プロダクトと互換性のある仕様・プロトコルを謳うこともあり一概には言えないケースもある。
■ポータビリティ重視でない場合
パブリッククラウドのSaaS、マネージドサービスを積極的に採用することも考慮する。マネージドサービスを利用することで、構築コストや性能不足時のスケールアウトなどの運用コストを低減できる可能性がある。一方で、利用されるSaaSがアプリケーションレイヤ寄りであるほど、独自のAPIやサービス特性など求められるスキルセットが希少なものになることが多い。要員確保の難易度への影響も考慮すること。
A.2.1「データ基盤」のスコープ

A.2.2

A.3.1

コスト見積もりデータソース-データ基盤間のスコープ

データ入力部分の責任分界点--

データ基盤は既存システムに後から接続されるケースが多く、組織や運用主体が分離しているケースが多い。
データ収集のインターフェース仕様など合意すべき部分を然るべきステークホルダーと合意すること。

データ基盤-データ活用間のスコープ

データ活用(出力)部分の責任分界点--

BIツールまでデータ基盤側に含まれる構成とするパターンも多い。利用者に提供する機能の責任分界点に注意すること。

見積もりの方針

見積もり全体の注意点や方針について--大前提として、以下のような理由からデータ活用プロジェクトについての将来像も含めた精緻なコスト見積もりは難しい。
・ビジネス要求(外的・内的)の月単位での変化
・データ容量の増大
・処理要求の増大・採用する技術要素(プロダクト)そのものの多様性・変化への追従
上記を勘案して以下のような観点も考慮し、プロジェクト全体のリスク低減を行うことが望ましい。
・外部委託を含むプロジェクトとする場合はプロジェクトの要件定義・設計等に適宜判断のためのマイルストーンを設け、外部委託時はフェージング契約も考慮する
・技術難易度の高い、実績の少ない技術要素の採用に対するPoC(Proof of Concept)の実施
・データ容量、処理コストの見積もり精度を上げるためのサイジング向け事前検証の実施

A.3.2

データ基盤そのものにかかるコスト

ハードウェア費用やパブリッククラウド利用料金など基盤にかかるコスト--

一般的なシステム開発同様イニシャルコスト、ランニングコストを検討する必要があるが、オンプレミス/クラウドで主要な注意点が異なる。
■オンプレミス採用時の注意点の例
・HW関連のイニシャルコスト(データセンタ、サーバ等)
・データセンター運用保守など作業のコスト
・個別のHW・SW保守費用、ライセンス費
・固定資産/減価償却の取り扱い■パブリッククラウド採用時の注意点の例
・計算リソースにかかるランニングコスト
・長期で考えた際のランニングコスト
システム運用に関連する運用コストについてはSaaS利用などその他条件に大きく依存するため、プロジェクト毎に精緻化すべき項目となる。

A.4.1.1

推進体制

必須体制

プロジェクトとして確実にアサインされるべき体制

意思決定ロール

プロジェクトに対する責任者

一般的なシステム開発プロジェクトと同様に、プロジェクト初期では想定されない課題や問題に対する意思決定、判断のポイントが多数発生する。発生する課題に対して、QCDを考慮した意思決定をタイムリーに行う責任者が必須である。また、タイムリーに判断を行うための要素として、ビジネス理解に加えてデータ分析手法やデータ分析システムについての一定の理解が求められる。
■適切にアサインされない場合のリスク例
・最終的に組みあがったシステムがビジネス的価値を生まずに、利用されない基盤(負債)となる。
・定期的な判断ポイントで妥当な判断が行えない。または判断に時間を要し、スケジュールが遅延する。

A.4.1.2

既存業務に詳しいメンバーのアサイン

データ分析基盤として接続する業務システム、およびそのシステムで実現する ビジネス・業務に対するデータ分析機能、基盤の価値の妥当性を評価するために、既存の業務に対する実際業務内容を詳細に把握したメンバーの課題感を持っているメンバーのアサインが必要となる。システム開発を推進するのが情報システム部門だとしても、実際に活用するユーザーが事業部門の場合は、事業部門担当者も交えて検討を進めることが望ましい。
■適切にアサインされない場合のリスク例
・最終的に組みあがったシステムがビジネス的価値を生まずに、利用されない基盤(負債)となる。
・分析要件が出てこず、要件定義フェーズでのQCDの問題が発生する。
・分析者(アナリスト)からのアイデアに対するビジネス観点での評価ができない。

A.4.1.3

既存データ仕様に詳しいメンバーのアサイン

既存システムで扱うシステム・データの特性やデータ仕様を詳細に把握したメ 既存システムで扱うシステム・データの特性や細かなデータ仕様について把握し、新規データ基盤担当者からンバーのQ&Aに対して優先的に対応可能なメンバーがアサインされていること。多くのケースでは既存システムの設計や運用担当者などエンジニアロール。
■適切にアサインされない場合のリスク例
・データ加工の処理設計のロジックが確定せず、スケジュールが遅延する。
・想定されないデータ仕様・特性が本番データ連携時に発覚し、データ加工プログラムの修正が多発する。

A.4.2.1

必須のロール

データ基盤を構想・設計・活用するにあたり体制全体で担保できている役割・ロール。また、プロジェクトや基盤規模によってはあるロールをチームや複数メンバで分担したり、複数のロールを同一の担当者が担うケースもある。

A.4.2.2

データ分析リーダーのアサイン

各種データ分析手法についてのスキルを有し、主にデータ分析機能の検討・ 想定している分析の用途・性質によって求められるスキルが大きく異なる。（例: BIによる分析、統計・機械設計・実現を推進するリーダー。
学習アルゴリズムを用いた分析、音声や画像を入力とした分析などは手法が大きく異なる。）

データアーキテクト(チーフアーキテクト)のアサイン

基盤・プラットフォーム全体を統括し、性能対コスト最適化や運用性、保守性、セキュリティなど主に非機能面についての設計・検討・実現を推進するリーダー。

データ基盤は多くの機能・コンポーネントにより成り立つ。各機能・コンポーネントの特性、適材適所を把握してシステムアーキテクチャを検討するための経験・スキルを有したメンバーをアサインすること。
■適切にアサインされない場合のリスク例
・各種機能やプロダクトの適材適所を考慮できず、機能や非機能、コストの観点で無駄が多いアーキテクチャデザインとなる。

A.4.2.3

ソリューションアーキテクトのアサイン

特定の製品群や周辺システムとの連携方式などのノウハウをもったエンジニア。(パブリッククラウドベンダのソリューションアーキテクトも本項に含まれる)採用を検討している、あるいは確定している製品やSaaSサービスなどがあれば、その仕様や周辺システムとの連携方式などのノウハウをもったソリューションアーキテクトのアサインが必要になる。
■適切にアサインされない場合のリスク例
・個別プロダクトの利用ノウハウが不足し、誤った設定・バッドノウハウなどを実践してしまう。
・問題発生時の対処が個別対処となり、解決できない。または必要以上に時間を要する。

A.4.2.4

A.4.2.5

分析アプリケーションエンジニア

データ分析機能の検討・設計・実現を実施するメンバー。

分析業務の開発が想定される場合、当該メンバーのアサインが必要。
初期システム開発以降も分析要件は発生する可能性があるため、継続開発のための開発スキル移管を求められるケースが多い。

基盤エンジニア

基盤の検討・設計・実現を実施するメンバー。

基盤検討を実施するメンバーのアサインが必要。場合によっては、利用する製品のベンダとのやりとりを踏まえて設計を担当する。

データソースとの連携

データ収集元となるシステムなどの連携先・RDB(ホスト基盤)
・ファイルシステム

-

-

■調整内容
対象となる連携先と調整の上、どのようなデータが収集されるのか、データサイズはどの程度か、連携方法をどうするかを調整する。
データを収集するタイミングによって、アーキテクチャ構成を検討する。データが発生する度にリアルタイムで収集するのであれば、ストリーム処理をスコープに追加する。

A.5.2

活用先との連携

データ提供先システムなどの連携先
・BI基盤
・ファイルシステム

-

-

■調整内容
対象となる連携先と調整の上、どのようなデータを提供すべきなのか、連携方法をどうするかを調整する。
データを連携するタイミングによって、アーキテクチャ構成を検討する。データが発生する度にリアルタイムで処理結果を連携するのであれば、ストリーム処理をスコープに追加する。

A.5.3

その他

共通基盤としてあらかじめ設けられているもの。連携先・ジョブ管理・監視/障害検知
・名前解決
・認証

-

-

■調整内容
対象となる連携先と調整の上、どのような機能を利用するか、連携方法をどうするかを調整する。

データ収集

データ基盤で提供する機能・サービスとしての「データ収集」の有無--

データ活用基盤のためデータ収集はほぼ必須となる機能だが、データ収集チーム、データ蓄積/加工チームが別々で、対応するベンダも異なるといったケースも存在する。

A.5.1

A.6.1

別システムとの連携機能・サービスのスコープ

その他、プロジェクトによっては利用しないケースもあるため、以下をプロジェクトごとに記載する。
■サービスの有無■利用する前提と考えているプロダクト及びその理由
A.6.2

データ蓄積

データ基盤で提供する機能・サービスとしての「データ蓄積」の有無--

データの蓄積機能を提供する。大容量・長期間の蓄積となるケースが多く、コストバランスを考慮した大容量、スケーラブルなストレージの選定、方式設計が必要となる。
その他、プロジェクトによっては利用しないケースもあるため、以下をプロジェクトごとに記載する。
■サービスの有無■利用する前提と考えているプロダクト及びその理由

A.6.3

データ加工

データ基盤で提供する機能・サービスとしての「データ加工」の有無--

蓄積したデータをデータ基盤内部で一時加工する機能。
その他、プロジェクトによっては利用しないケースもあるため、以下をプロジェクトごとに記載する。
■サービスの有無■利用する前提と考えているプロダクト及びその理由

A.6.4

データ活用

データ基盤で提供する機能・サービスとしての「データ活用」の有無

--

A.6.5

ストリーム収集/処理

データ基盤で提供する機能・サービスとしての「ストリーム収集/処理」の有無--

蓄積、一時加工したデータを活用先向けに提供する機能で構成される。BIシステムによる可視化やイベント通知機能などが該当する。
その他、プロジェクトによっては利用しないケースもあるため、以下をプロジェクトごとに記載する。
■サービスの有無■利用する前提と考えているプロダクト及びその理由
データの発生から活用まで一気通貫、低レイテンシで行いたい場合に必要なサービスとなる。ストリーム処理がスコープに含まれると、バッチ処理ベースの設計・実装と考え方を異にする部分が多く、システム設計・実装の難易度が大幅に増すことに注意。
また、ストリーム処理基盤の実現有無は「データ収集」の実現方式に大きく依存する部分があることにも注意。(例: 活用対象データのデータ収集が日次バッチでは、低レイテンシの活用は実現不可能。)
検討初期段階ではスコープに含めない場合も、将来的に検討する場合はデータ収集部分でストリーム処理を考慮した設計が必要となる。
その他、プロジェクトによっては利用しないケースもあるため、以下をプロジェクトごとに記載する。
■サービスの有無■利用する前提と考えているプロダクト及びその理由© 2021 NTT DATA Corporation

システム化個別項目
項番

大カテゴリ

中カテゴリ

B.1.1.1

データ収集

収集対象データ種別

B.1.1.2

データ収集

B.1.1.3

中カテゴリの説明
データソースからデータ基盤内に取り入れるデータの種別

小カテゴリ
構造データ(Structured Data)

小カテゴリの説明
RDBMSのテーブルやCSVなど、テーブル構造で表すことが可能なデータ
例:・CSV(Comma Separated Values)
・TSV(Tab Separated Values)・システムログ

収集対象データ種別

半構造データ(Semi-Structured Data)

XMLやJSONなど、内部で多次元の構造を保持可能なデータ。厳密な定義はないが、ここでは以下の性質をもつものとする
・(不可能ではないが)SQLでの扱いが難しい・後方互換性を保ちながらのスキーマの変更や、前後スキーマの混在が可能
・情報量を失わずにテキストで表すことが可能

データ収集

収集対象データ種別

非構造データ(Unstructured Data)

テキストファイル(*.txt)、画像(JPG, PNG, BMP, GIF)や音声(WAV、MP3、AAC)、動画(AVI、MP4、etc...)などセンサーなどのIoTデバイスにみられる、独自フォーマットによりシリアライズされたフォーマット。シリアライズ/デシリアライズのためにビットアサイン表など別途フォーマットが必要

B.1.1.4

データ収集

収集対象データ種別

特定のアプリケーション向けフォーマット

Word(*.docx)やExcel(*.xlsx)、PDFなど用途が限定的なアプリケーションで扱うための形式

B.1.2.1

データ収集

収集インターフェース

バッチ連携

対向システムで一定期間データを蓄積し、データ基盤側に送信する
例: 日次(夜間)バッチによる連携、時次バッチでの連携

B.1.2.2

データ収集

収集インターフェース

ストリーム連携

システムログ1行 、RDBMSのトランザクションログ、センサーデータの発生など、対向システムでのデータ発生と同時にデータ基盤へデータが送信される連携方式

B.1.2.3

データ収集

収集インターフェース

PUSH型/ PULL型■PUSH型
データソースがデータを送信
例 : データ基盤はデータを受信するための口を持ち、データソースのタイミングでデータを送信する。

データソース毎に、どのようなインターフェース経由でデータを収集するか■PULL型
データ基盤がデータソースにアクセスしデータを取得
例 : ETLツールがRDBMSにアクセスしデータ基盤にデータを格納する
B.1.2.4

データ収集

収集インターフェース

対向システムへの負荷

収集時の対向システムへの負荷(CPU負荷、I/O負荷、通信量)

B.1.2.5

データ収集

収集インターフェース

プロトコル■ミドルウェアに依存しない汎用的なプロトコル例
・FTP、SFTP(ファイル転送)
・HTTP,HTTPS(主にRestAPI)
・MQTT、MQTTS(IoTなどデバイス向け)■ミドルウェア依存のプロトコル例
・JDBC/ODBC・FluentdやKafkaなどミドルウェアによる転送

B.1.3.1

データ収集

データの到達性保証

連携するデータ毎にデータ連携時の欠損・重複についての対応・責任
分界点

データ到達の責任分解

データ送信の責任をデータソースとデータ基盤どちらが持つか

B.1.4.1

データ収集

データ流入

利用するデータの流入量

データ流入量データソースから収集する収集対象データ量(〇TByte/day、〇GByte/hourなどで表される)

B.1.4.2

データ収集

データ流入

データ流入量のゆらぎ

データ流入量が時間軸で変動するか

B.1.5.1

データ収集

通信経路

帯域

データソースのシステム～データ基盤間のネットワーク帯域

B.1.5.2

データ収集

通信経路

暗号化

通信経路の暗号化

B.1.6.1

データ収集

初期データ移行・コピー

B.1.6.2

データ収集

初期データ移行・コピー

B.1.6.3

データ収集

B.1.7.1

データ収集のための外部システムとの接続経路

既存システムから移動させるデータの総量

初期データ移行・コピー

既存システムがある場合、システムからデータ基盤へのデータ移行につい 移行データ量ての検討項目
収集元がデータ基盤と平行で継続運用される業務システムの場合は、 移行スケジュール
移行ではなくコピーという表現もできる
移行方式

データ収集

収集スケジュール

データ収集のスケジュール

ジョブ管理システム連携

データ収集を起動する機能との連携

B.1.7.2

データ収集

収集スケジュール

業務SLA確認

データ収集の開始終了時間など業務的な要件

B.2.1.1

データ蓄積

データ容量

元データの容量

データソースから収集するデータの容量

B.2.1.2

データ蓄積

データ容量

活用データの容量

データを加工し、活用先に受け渡す状態のデータの容量

B.2.1.3

データ蓄積

データ容量

中間データの容量

元データから活用データに加工する間で、アプリケーションで必要になる中間状態のデータの容量

B.2.1.4

データ蓄積

データ容量

データの圧縮元データ、活用データ、中間データをそれぞれ圧縮するか

B.2.2.1

データ蓄積

データのライフサイクル

データ保管期間

元データ、活用データ、中間データをそれぞれの保管期間

B.2.2.2

データ蓄積

データのライフサイクル

アーカイブの有無

低コストかつI/O性能の低いストレージにデータを連携するか

B.2.2.3

データ蓄積

データのライフサイクル

アーカイブ保管期間

アーカイブデータの保管期間

B.2.3.1

データ蓄積

バックアップバックアップの有無

データのバックアップを取得するか否か

B.2.3.2

データ蓄積

バックアップ

チェックポイント

特定の時点のストレージの状態をチェックポイントとして記録し、切り戻すことを可能とする機能
アプリケーションエラー、オペレーションミス等によるデータ消失からデータを復旧させることが可能になる場合がある

B.2.3.3

データ蓄積

バックアップ

災害復旧(DR)の有無

災害対策用サイトを用意するか否か

B.2.3.4

データ蓄積

バックアップ

DRサイトへの転送方式、保存期間、ロケーション

本番環境からDRサイトへのデータ転送方式、データの保管期間、DRサイトを構築する地理的な場所

B.2.4.1

データ蓄積

蓄積プラットフォーム

蓄積機能を実現するためのプラットフォーム

導入製品

データ蓄積基盤の中心として採用するストレージ製品

B.3.1.1

データ加工

処理パターン(データマート作成)

データ基盤上で中間処理を行う処理の代表的パターン

フィルタリング

条件に合うデータを抽出

B.3.1.2

データ加工

処理パターン(データマート作成)

集計・一時集計処理

時間帯やグループ別の集計処理を行う。

B.3.1.3

データ加工

処理パターン(データマート作成)

名寄せ

複数のデータから、同一人物や同一企業のデータを1つにまとめる

B.3.1.4

データ加工

処理パターン(データマート作成)

マスターデータ結合

複数のマスターデータの統合

B.3.1.5

データ加工

処理パターン(データマート作成)

順序制御

項目に応じたデータの並べ替え

B.3.1.6

データ加工

処理パターン(データマート作成)

重複排除

重複データを取り除く

B.3.2.1

データ加工

処理パターン(機械学習の前処理)

B.3.2.2

データ加工

処理パターン(機械学習の前処理)

B.3.2.3

データ加工

処理パターン(機械学習の前処理)

B.3.3.1

データ加工

処理パターン(その他)

B.3.4.1

データ加工

B.3.5.1
B.3.5.2

データ基盤で蓄積・保持する最大容量

データ毎にどの期間データを保存するか、削除するかシステム障害等に対するデータ消失を防ぐ

機械学習等の分析アルゴリズムで処理する前に必要となる前処理の代 (機械学習アルゴリズムのインプットとするための)前処理表的パターン
テキスト(自然言語)処理

既存システムからの移行計画
既存システムからのデータ移行方式

クレンジング、正規化、標準化、ベクトル化など
特徴量抽出

非構造データ処理

画像や音声、動画等のデータからの特徴量抽出上記パターンに含まれないデータ加工処理パターン

検索インデックス作成

検索インデックスの作成

加工スケジュール

バッチ処理のワークロードでの加工処理が必要な場合、どのようにスケジュールを割り当てるか

--

データ加工

実装インターフェース

データ加工処理を実装するためのアプリケーション実装インターフェース

SQL

SQLまたはSQLライクな実装言語による開発

データ加工

実装インターフェース

プログラム

SQL以外の実装言語による実装。ノートブックなどUI経由で実装したものも含む。

B.3.5.3

データ加工

実装インターフェース

ETLツールETLツールに内包されたデータ加工機能

B.3.6.1

データ加工

処理プラットフォーム

加工で実施する内容

クレンジング、前処理、結合処理、フィルタリング処理、DM作成処理など、処理パターンで定義した内容。

B.3.6.2

データ加工

処理プラットフォーム

導入製品

加工基盤に導入する製品(ETL,DWH,Hadoop,...)
実施したい処理に応じて、複数選定することもある

B.3.6.3

データ加工処理プラットフォーム

製品の使い分け複数の製品を導入する場合の使い分け指針© 2021 NTT DATA Corporation

加工機能を実現するためのプラットフォーム

システム化個別項目
項番

大カテゴリ

中カテゴリ

B.4.1.1

データ活用

可視化・BI

B.4.1.2

データ活用

B.4.1.3

データ活用

B.4.1.4

小カテゴリ
BI機能有無小カテゴリの説明
BI機能を利用するか

可視化・BI

BIツールの種類

エンタープライズBI/セルフBIといった分類が存在する

可視化・BI

BIデータアクセス経路

アクセス対象のデータが格納されるDBはデータ基盤の内か外か

データ活用

可視化・BI

BIアクセス制御

アクセス元のユーザのアクセス制御

B.4.2.1

データ活用

AI/機械学習

AI/機械学習機能有無

AI/機械学習機能を利用するか

B.4.2.2

データ活用

AI/機械学習

学習環境

学習モデルを生成する環境

B.4.2.3

データ活用

AI/機械学習

推論環境

学習モデルをデプロイし予測を実行する環境

B.4.2.4

データ活用

AI/機械学習

機械学習提供ツール/プラットフォーム

どのようなツール/プラットフォームをベースとしてライブラリ/機能開発を実施する
か

B.4.3.1

データ活用

データの到達性保証

データ欠損・重複時の対応

活用先へ提供するデータに問題があったときどう対応するか

B.4.3.2

データ活用

データの到達性保証

対向システムへの負荷

活用先へ提供時の対向システムへの負荷(CPU負荷、I/O負荷、通信量)

B.4.3.3

データ活用

データの到達性保証

データ流出量

活用先への提供データ量

B.4.4.1

データ活用

通信帯域

確保すべきネットワーク帯域

B.4.4.2

データ活用

通信

暗号化

暗号化要件があるか

B.4.5.1

データ活用

提供I/F

活用先毎に、どのようなインターフェース経由でデータを提供するか--

B.4.6.1

データ活用

提供スケジュール

活用先毎のデータ提供スケジュール--

B.5.1.1

ストリーム収集

メッセージ(送受信データ)

ストリームデータ(断続的・連続的に生成されるデータ)

メッセージサイズ

1メッセージ当たりの容量

B.5.1.2

ストリーム収集

メッセージ(送受信データ)

データ形式

メッセージのファイルフォーマット
ファイルの中身の構造

B.5.1.3ストリーム収集

メッセージ(送受信データ)

圧縮有無

メッセージの圧縮の有無

B.5.1.4

ストリーム収集

メッセージ(送受信データ)

メッセージ種別

収集するメッセージの種類

B.5.1.5

ストリーム収集

メッセージ(送受信データ)

メッセージの順序保障

所定のメッセージ順序を守って処理をするかどうか

B.5.1.6

ストリーム収集

メッセージ(送受信データ)

メッセージのカーディナリティ

データの取り得る値のばらつきと偏り

B.5.1.7

ストリーム収集

メッセージ(送受信データ)

メッセージのスキーマの変化

スキーマの変更（カラム増減、型の変更など）があるかどうか

B.5.1.8

ストリーム収集

メッセージ(送受信データ)

メッセージの保存メッセージハブ内のメッセージの保存

B.5.1.9

ストリーム収集

メッセージ(送受信データ)

収集時のメッセージ加工

収集するタイミングでメッセージを加工するか

B.5.2.1

ストリーム収集

収集I/F

プロトコル

ストリーム収集で利用するプロトコル

B.5.2.2

ストリーム収集

収集I/F

送信クライアント数

データソース側のメッセージ送信を行うクライアント数

B.5.2.3

ストリーム収集

収集I/F

基盤・フレームワーク

データソース側のメッセージ送信を行うAPの基盤・フレームワーク

B.5.2.4

ストリーム収集

収集I/F

リアルタイム性の担保

高スループット、低レイテンシをどの程度実現するか

B.5.2.5

ストリーム収集

収集I/F

メッセージ送達保証のセマンティクス

送達保障のレベルとメッセージロストの責任分界

B.5.2.6

ストリーム収集

収集I/F

リアルタイム性とメッセージ送達保証のバランス

リアルタイム性(高スループット、低レイテンシ)とメッセージ送達保証は特にトレードオフであることがあるため、そのバランスを考慮する

B.5.2.7

ストリーム収集

収集I/F

タイムアウト設計

送信元のタイムアウト設計と受信側のタイムアウト設計

B.5.3.1

ストリーム収集

データ流入

スループット

単位時間あたりに送信するメッセージ数

B.5.3.2

ストリーム収集

データ流入

データ流入のワークロード

メッセージ送信の間隔

B.5.3.3

ストリーム収集

データ流入

データ流入量の考え方

ワークロードに応じて、データソース側とスループットの考え方があっているか

B.5.3.4

ストリーム収集

データ流入

拡張性

データ流入量にあわせた拡張性

B.5.3.5

ストリーム収集

データ流入

バーストトラフィックの有無

バーストトラフィックが発生する可能性があるか

B.5.3.6

ストリーム収集

データ流入

メッセージ遅延メッセージが遅れて送信・受信されることがあるか

B.5.4.1

ストリーム収集

バックアップライン

ストリーム収集の副系統--

B.5.5.1

ストリーム収集

ストリーム収集プラットフォーム

ストリーム収集機能を実現するためのプラットフォーム

導入製品

ストリーム収集基盤として採用する製品

B.6.1.1

ストリーム処理

データの受信メッセージハブからのデータ受信

スループット

単位時間あたりに受信するメッセージ数、量B.6.1.2

ストリーム処理

データの受信メッセージ受信のワークロード

メッセージハブからのメッセージ受信のワークロード

B.6.1.3

ストリーム処理

データの受信大量メッセージ流入

想定以上のメッセージ流入への対応

B.6.1.4

ストリーム処理

データの受信チェックポイント

途中経過を記録するための一時的なデータ保存をするかどうか

B.6.2.1

ストリーム処理

データの処理ステート管理処理の状態管理B.6.2.2

ストリーム処理

データの処理バックプレッシャー

バーストに対する処理抑制ないし抑制の伝搬

B.6.2.3

ストリーム処理

データの処理アプリケーションの更新

継続的に動作し続けるアプリケーションのアップデート

B.6.2.4

ストリーム処理

データの処理順序保証

所定の順序を守り処理をするかどうか

B.6.2.5

ストリーム処理

データの処理メッセージ処理保証のセマンティクス

ストリーム処理では故障発生時などに仕掛中の処理が途絶えることがある。そういった際にどのように処理継続するかを決める必要がある。（例：最大でも1回処理する、最低1回処理する、ただ一度処理する）

B.6.2.6

ストリーム処理

データの処理性能

ストリーム処理の性能（例：スループット、レイテンシ）

B.6.2.7

ストリーム処理

データの処理処理の並列度

スループットを向上するため処理を並列化することがあるがその度合い

B.6.2.8

ストリーム処理

データの処理データ流入量

データ流入量に合わせた拡張

B.6.2.9

ストリーム処理

データの処理データ永続化の有無

ストリーム処理対象のデータ、中間データ、処理した結果を永続化するかどうか

B.6.2.10 ストリーム処理

データの処理処理ロジックストリーム処理のロジック

B.6.3.1

ストリーム処理運用

ストリーム処理基盤の運用

業務閉塞の有無

メンテナンス等で業務閉塞するか

B.6.4.1

ストリーム処理

ストリーム処理プラットフォーム

ストリーム処理を実現するためのプラットフォーム

導入製品

ストリーム処理基盤として採用する製品© 2021 NTT DATA Corporation中カテゴリの説明
データを分析し、経営上の意思決定に役立てる

データから学習モデルを生成し、推論(予測)を行う

活用先毎のデータ提供時の欠損・重複についての対応

活用先へデータ提供時のネットワーク

データソース毎に、どのようなI/F経由でデータを収集するか

上流システムから受信するデータの流入条件受信したデータの処理