翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# データ戦略フレームワーク
このガイドで紹介するデータ戦略フレームワークは、モダンデータおよび分析アーキテクチャに関する以下の基本原則に基づいています。
1. **統合された、費用対効果の高い、スケーラブルなストレージレイヤー**を使用することで、すべてのデータプロデューサーとデータコンシューマーが、データを操作するための技術的能力を持つことができます。
1. **セキュリティは必須です**。データプライバシールールを適用し、暗号化によるデータ保護を提供し、監査を有効にし、自動化されたコンプライアンスを提供します。
1. 会社全体で**共有するためにデータを管理**します。ユーザーが必要なデータを見つけて使用できるように、一意のデータカタログとビジネス用語集を提供します。
1. **適切なジョブに対して適切なサービス**を選択します。コンポーネントを選択する際は、機能性、スケーラビリティ、データレイテンシー、サービスの実行に必要な労力、耐障害性、統合性、および自動化を考慮します。
1. **人工知能 (AI) と機械学習 (ML)** を使用します。
1. **データリテラシー**と、**ビジネスユーザー向けに抽象化**されたツールを提供します。
1. データイニシアチブの**仮説をテスト**し、**その結果を測定します**。
データフレームワークでは、[顧客から逆算する](https://docs.aws.amazon.com/whitepapers/latest/building-cloud-operating-model/step-1.-work-backwards-from-the-customer.html)アプローチを使用します。この手法は、Amazon および AWS で使用されており、次の 5 つのステップに従います。
1. 自社の各ビジネス領域のユーザーにインタビューします。データイニシアチブによって対処できる可能性のあるビジネス上の問題や機会を選択します。
1. それらのビジネス領域内で期待されるビジネス成果を定義します。
1. ビジネスへの影響が最も大きいイニシアチブから順に優先します。
1. ビジネス成果を達成するために必要なデータ共有および技術的能力を特定し、それらをイネーブルメントプロジェクトとしてまとめます。
1. データ駆動型イニシアチブを実現するためのロールと責任を明確にし、学際的なチーム構築について議論します。
以下のセクションでは、このプロセスの主なステージについて説明します。
+ [ビジネスディスカバリー](business-discovery.md)
+ [データ可用性の評価](data-availability.md)
+ [技術的評価](technical-assessment.md)
+ [ビジネス目標に沿ったストーリーの調整](align-stories-goals.md)
# ビジネスディスカバリー
ビジネスインタビューを効果的に行うには、データに依存する****自社の目標を大まかに理解することが重要です。例えば、これらの目標には以下のようなものが含まれます。
+ ビジネスの俊敏性の向上
+ 高度なイノベーションの有効化
+ 顧客中心の実現
+ 市場シェアの拡大
+ グローバル市場への展開
+ 新しいカスタマープラットフォームの立ち上げ
会社の目標についての認識を合わせたら、各ビジネス領域のチームメンバーと話し合う必要があります。少なくとも、会社の主要な目標に影響を与える領域に焦点を当ててください。ただし、機会があれば、すべてのビジネス領域のチームメンバーと話してください。
このディスカバリー会話では、各ビジネス領域またはビジネスユニット (BU) の目標、それらの領域の測定に使用するメトリクス、およびデータの使用が目標にどのような影響を与えるかを把握します。いくつかの質問の例を以下に示します。
+ BU の主な目標は何ですか?
+ BU は会社の目標を達成するためにどのように貢献しますか?
+ BU の主要なプロジェクトは何ですか?
+ 各プロジェクトはどのようにデータに依存しますか?
主要なプロジェクト、そのタイムライン、それらがデータにどのように依存しているか、それらが会社の目標とどのように整合しているか、または会社の目標をどのようにサポートしているかについて、可視化することが重要です。プロジェクトの例として、次のようなものが挙げられます。
+ 一貫したオムニチャネルインタラクションを通じてカスタマーエクスペリエンスを向上させ、最新の顧客アクションと問題についての認識を深める
+ 顧客の行動に基づいてレコメンデーションエンジンを作成し、コンバージョン率とエンゲージメントを高める
+ オンライン金融商品において、顧客の与信を承認するためのリスク計算を高速化し、時間がかかりすぎて顧客が他の金融機関に流出するのを防ぐ
+ 販売予測の精度を向上させ、供給損失を削減する
+ リアルタイムでの不正検出を最適化することにより、不正による損失を削減する
# ビジネスにおけるデータの使用可能性を評価する
次のようなフォローアップの質問を使用して、現在のデータ使用可能性の状態と、BU が達成したいこととの間にあるギャップを把握します。
+ データは、プロジェクトと現在のビジネス目標をどのようにサポートしていますか?
+ 意思決定に使用するための適切なデータを取得することは難しいですか?
+ データを取得するプロセスはどの程度自動化されていますか? どのような手動のステップ (ある場合) が含まれますか?
+ データが使用可能になったときに、チームはそのデータを理解して処理できますか、それともビジネス領域に合わせてデータを変換する必要がありますか?
+ ビジネス上の意思決定をサポートするために、タイムリーにデータを受け取っていますか?
+ データを迅速に取得することで、どのようにビジネスが改善されますか? 改善を推進するためには、どの程度迅速にデータが使用可能になる必要がありますか?
+ 意思決定者に不足しているデータはありますか?
+ 「はい」の場合、どのデータが不足していますか?
+ このデータを持つことには、どのような利点がありますか?
+ 不足しているデータによって、主要プロジェクトはどのような影響を受けますか?
+ 一般データ保護規則 (GDPR) やその他の標準などのコンプライアンス規制に関連する課題はありますか?
+ BU には、アプリケーションがアクションを実行できるようにするために使用可能なデータ製品がありますか?
+ あなたの領域では、ビジネスを向上させるための機械学習モデルを提供できますか? 提供できない場合、この領域において他の BU があなたのビジネスをサポートしていますか?
+ 現在はあなたの BU で使用できないが、あなたのプロジェクトをサポートする、またはあなたの領域における改善を推進すると思われる社内データは何かありますか?
+ それは何ですか?
+ あなたの領域で使用できるデータの品質を信頼していますか?
+ チームは、データの使用前に独自のデータクレンジングプロセスを実行していますか?
+ チームは、データの使用前に独自の品質プロセスを実行していますか?
+ チームがデータ使用可能性に取り組み、分析、エンリッチメント、および集約されたビジョンのために新しいデータ製品を生成する場合、それらの製品を社内の他の BU と共有できますか?
# 技術的評価
技術的評価は重要です。これは、技術的評価によって、会社が現在導入している技術的能力のマップが明らかになるためです。この評価では、データガバナンス、データインジェスト、データ変換、データ共有、機械学習 (ML) プラットフォーム、プロセス、および自動化が対象となります。
技術的評価中に尋ねることができる質問の例を、チーム別に以下に示します。コンテキストに応じて質問を追加できます。
## データエンジニアリングチーム
+ あなたのチームで、データの取り込みに関連する現在の課題は何ですか?
+ あなたのチームが必要とする外部または内部のデータソースのうち、取り込みに使用できないものはありますか? それらを使用できないのはなぜですか?
+ どのタイプのデータソース (例: MySQL データベース、Salesforce API、受信したファイル、ウェブサイトナビゲーションデータ) からデータを取り込みますか?
+ 新しいデータソースからデータを取り込むのにどれくらいの時間がかかりますか?
+ 新しいソースからデータを取り込むプロセスは自動化されていますか?
+ 開発チームがアプリケーションから分析用のトランザクションデータを公開する難易度はどの程度ですか?
+ データソースから (バッチまたはマイクロバッチで) 全ロードまたは増分ロードを行うためのツールはありますか?
+ データベースから継続的なロードを行うための変更データキャプチャ (CDC) ツールはありますか?
+ データインジェスト用のデータストリーミングオプションはありますか?
+ バッチデータおよびリアルタイムデータのデータ変換をどのように実行しますか?
+ データ変換ワークフローのオーケストレーションをどのように管理しますか?
+ データ検出とカタログ化、データインジェスト、データ変換、ビジネスアナリストの支援、データサイエンティストの支援、データガバナンス、チームやユーザーのトレーニングのうち、最も頻繁に実行するアクティビティはどれですか?
+ データセットを作成する場合に、データプライバシーについてそれらのデータをどのように分類しますか? また、社内コンシューマーにとって意味のあるものにするために、どのようにクリーンアップしますか?
+ データガバナンスとデータスチュワードシップは一元化されていますか、それとも分散されていますか?
+ データガバナンスはどのように適用しますか? 自動プロセスはありますか?
+ データパイプラインの各フェーズ (データインジェスト、データ処理、データ共有、データ使用) において、データオーナーおよびスチュワードは誰ですか? 所有者とスチュワードを決定するためのデータドメインの概念はありますか?
+ 組織内でアクセスコントロールを伴ってデータセットを共有する際の主な課題は何ですか?
+ データパイプラインのデプロイと管理に Infrastructure as Code (IaC) を使用していますか?
+ データレイク戦略はありますか?
+ データレイクは組織全体で分散されていますか、それとも一元化されていますか?
+ データカタログはどのように編成されていますか? 全社的ですか、それとも領域ごとですか?
+ データレイクハウスアプローチを導入していますか?
+ データメッシュの概念を使用しているか、または使用する予定がありますか?
これらの質問は、「[AWS Well-Architected Framework Data Analytics Lens](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/analytics-lens.html)」で補完できます。
## ビジネス分析チーム
+ あなたの業務に使用できるデータについて、以下の特性をどのように説明しますか?
+ クリーンさ
+ Quality
+ 分類
+ メタデータ
+ ビジネス上の意味
+ あなたのチームは、自分の領域のデータセットに関するビジネス用語集の定義に参加していますか?
+ 業務遂行に必要なデータが必要なときにない場合、どのような影響がありますか?
+ データにアクセスできない、あるいはデータの取得に時間がかかりすぎるというシナリオの例はありますか? 必要なデータを取得するのにどのくらいの時間がかかりますか?
+ 技術的な問題や処理時間が原因で、必要なデータセットより小さいデータセットを使用することはどのくらいの頻度でありますか?
+ 必要なスケールとツールを備えたサンドボックス環境はありますか?
+ 仮説を検証するために A/B テストを実行できますか?
+ ジョブの実行に必要なツールは不足していませんか?
+ どのタイプのツールですか?
+ それらを使用できないのはなぜですか?
+ 実行する時間がない、重要なアクティビティはありますか?
+ 最も時間を消費するアクティビティはどれですか?
+ ビジネスビューはどのように更新されますか?
+ それらのスケジュールと管理は自動で行われますか?
+ 取得したデータよりも新しいデータが必要になるのはどのシナリオですか?
+ どのように分析を共有しますか? 共有にはどのツールおよびプロセスを使用しますか?
+ 新しいデータ製品を作成し、それを他のチームが使用できるようにすることは頻繁にありますか?
+ 他のビジネス領域と、あるいは会社全体でデータ製品を共有するプロセスはどのようなものですか?
## データサイエンスチーム (モデルのデプロイを決定するため)
+ あなたの業務に使用できるデータについて、以下の特性をどのように説明しますか?
+ クリーンさ
+ Quality
+ 分類
+ メタデータ
+ 意味
+ 機械学習 (ML) モデルをトレーニング、テスト、およびデプロイするための自動ツールはありますか?
+ ML モデルを作成およびデプロイする各ステップにおいて、マシンサイズのオプションはありますか?
+ ML モデルは本番環境にどのように導入されますか?
+ 新しいモデルをデプロイする際にはどのようなステップがありますか? それらはどれくらい自動化されていますか?
+ バッチデータとリアルタイムデータに対して ML モデルをトレーニング、テスト、およびデプロイするためのコンポーネントはありますか?
+ モデルの作成に必要なデータを代表するのに十分な大きさのデータセットを使用および処理することができますか?
+ モデルをどのようにモニタリングし、再トレーニングするためのアクションをどのように実行していますか?
+ モデルがビジネスに与える影響をどのように測定していますか?
+ ビジネスチームの仮説を検証するために A/B テストを実行できますか?
その他の質問については、「[AWS Well-Architected Framework Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html)」を参照してください。
# ビジネス目標に沿ったストーリーの調整
ビジネス評価と技術的評価を実行したら、データ使用の成熟度の各レベルに対応する一連のストーリーを含む図を作成することをお勧めします。この可視化により、データ使用を会社のビジネス目標と整合させることが容易になります。例えば、「ほぼリアルタイムでの不正検出」というビジネス成果を得るには、「ほぼリアルタイムでアクションを実行する能力」に関するストーリーが必要です。
ストーリーは、ビジネス目標を達成するために必要な技術的能力、データ共有メカニズム、人材、およびプロセスです。ビジネスディスカバリーインタビューに基づいて図の右側にビジネス成果を書き込み、技術的評価に基づいて各ストーリーのステータスを入力します。その後、会社が取り組むべきストーリーを選択して、ロードマップを作成できます。
次の図には、ビジネス成果に基づいて、各ストーリーが必要かどうかが示されています。また、技術的評価で収集した情報に基づいて、各ストーリーの現在のステータスも示されています。通常は、この図の後に各ステータスの詳細を説明するレポートが続きます。
![\[各データ成熟度フェーズのイネーブルメントストーリーの可視化\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-aws-data/images/enablement-stories.png)
ストーリーを実現するために、右側 (*ビジネス成果*) から左側へと逆方向に作業を進めます。例えば、第 3 ステージ (*インサイトとレポート*) のストーリーを実現するには、第 2 ステージ (*データレイク*) および第 1 ステージ (*データ基盤*) でその依存ストーリーを実現する必要があります。
評価およびビジネス成果の要件に基づいて、各ストーリーは緑色、黄色、灰色、または赤色に分類されます。
+ 緑色は、そのストーリーが導入済みであり、ビジネス成果を達成するためにスケール可能であることを意味します。例えば、この図において、第 1 ステージ (*データ基盤*) の CDC 取り込みストーリーは緑色です。これは、会社が保有するデータソースに対して、そのストーリーを達成するためのツールとプロセスを持っていることを意味します。「*カスタマーエクスペリエンスの向上*」というビジネス成果を実現するには、関連する顧客データを取り込み、それを社内の他のデータによって強化することで、顧客の理解を深めて、パーソナライゼーションを提供する必要があります。
+ 黄色は、当該機能またはプロセスは存在しているが、完全には機能していないか、あるいはビジネス成果に必要なスケールをサポートしていないことを意味します。例えば、この図において、第 2 ステージ (*データレイク*) の「*一元化されたデータカタログ*」というストーリーは黄色です。これは、会社は中央データカタログを持っているが、そのカタログに他のステージで必要なメタデータが完全に取り込まれていないか、あるいはカタログがごく一部のビジネス領域でしか使用されていないことを示しています。この分類は、次のステージ (*インサイトとレポート*) のデータ共有機能に影響します。
+ 灰色は、ストーリーが必要ではないことを意味します。
+ 赤色は、ビジネス成果にストーリーが必要だが、まだ実装されていないことを意味します。例えば、この図において、*インサイトとレポート*ステージの「*データ共有*」というストーリーが赤色です。顧客レコメンデーションのための包括的な機械学習モデルを作成するには、データセットをグループ化する必要があります。これを行うには、データ共有機能が必要です。しかし、このストーリーはまだ実装されていません。この例では、データ共有には、少なくともモデルの一部である*データレイク*に対して、データレイクステージの能力が完全に機能していることが必要ですが、*データスチュワードシップ*が実装されていないことがわかります。
「*データプライバシー、保護、コンプライアンス*」というストーリー (*データレイク*ステージ) は常に必要であり、新しいデータ保護要件によってデータプライバシー規制が強化されるにつれて、さらに重要性が高まります。例えば、[一般データ保護規則 (GDPR)](https://gdpr.eu/what-is-gdpr/) は、米国では[バージニア州消費者データ保護法 (CDPA)](https://law.lis.virginia.gov/vacodefull/title59.1/chapter53/) および[カリフォルニア州消費者プライバシー法 (CCPA)](https://oag.ca.gov/privacy/ccpa) で始まり、ブラジルの[個人データ保護一般法 (LGPD)](https://www.serpro.gov.br/privacidade-protecao-dados)、メキシコの[メキシコデータ保護](https://www.dataguidance.com/notes/mexico-data-protection-overview)、コロンビアのデータ保護、ペルーの[法律 29733](https://www.leyes.congreso.gob.pe/Documentos/Leyes/29733.pdf)、および[アルゼンチン個人データ保護法](http://servicios.infoleg.gob.ar/infolegInternet/anexos/320000-324999/323901/norma.htm)など、ラテンアメリカの一部の国では既に導入されています。