mcpField
D
data-architect

data-architect

github.com/rade-nugrohoデータ・データベース1241 回インストール24 週間前に更新
リポジトリ

data-architect について

企業やソリューションレベルのデータアーキテクチャにおける意思決定、モデリング、プラットフォーム選定、ガバナンスを支援するスキルです。ADR、データモデル、比較表、ポリシーテンプレートなどの成果物を作成します。

主な機能

  1. 01重み付けによるアーキテクチャ評価
  2. 02概念から物理までのデータモデリング
  3. 03データウェアハウス、レイク、基盤の選定
  4. 04ガバナンスとコンプライアンス計画
  5. 05ADRテンプレートと関係者レビュー

活用シーン

  1. 01レイクハウスとデータウェアハウスを比較
  2. 02業務ドメインのエンティティをモデル化
  3. 03GDPR要件に向けたガバナンスを計画
  4. 04データ基盤の決定を文書化

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rade-nugroho/agentic-enteprises-skill --skill data-architect

インストール後、Claude Code で/data-architectを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
data_modeling.md
enterprise_architecture.md
governance_frameworks.md
platform_selection.md

詳細

データアーキテクト

概要

エンタープライズおよびソリューションレベルでデータアーキテクチャを設計します。このスキルでは、データメッシュ、レイクハウス、ガバナンス、ドメイン駆動設計、概念／論理／物理データモデリング、プラットフォームの選定、コンプライアンスフレームワークを扱います。ADR、データモデル図、プラットフォーム比較マトリクス、ガバナンスポリシーのテンプレートを作成します。

使用する場合

  • データウェアハウス、データレイク、レイクハウス、メッシュ、ストリーミングファーストのパターンから選択する場合
  • 概念、論理、物理データモデルやADRを作成する場合
  • データガバナンス、カタログ、品質、コンプライアンスのフレームワークを定義する場合
  • データプラットフォームや長期的なTCO、ベンダーのトレードオフを評価する場合

使用しない場合

  • 日々のパイプラインのオンコール、SLA違反、シフトの引き継ぎ → data-system-ops-lead を使用してください
  • 単一プラットフォームのSQLチューニングやスタースキーマの実装詳細 → data-warehouse-engineer を使用してください
  • dbtプロジェクトの実装、マートのテスト、分析のCI → analytics-data-engineer を使用してください
  • チームのロードマップ、スプリントの進行、ガバナンス運用の実行 → data-manager を使用してください
  • OWL/RDFオントロジーやナレッジグラフの構築 → ontology-engineer を使用してください
  • アプリケーション統合パターンやデータ以外のシステムADR → senior-system-architecture を使用してください
  • LLM/RAG/コパイロットのソリューションアーキテクチャやAI関連のADR → applied-ai-architect-commercial-enterprise を使用してください

機能

  • 重み付けした基準による評価を備えたアーキテクチャ意思決定フレームワーク
  • 段階的なデータモデリングワークフロー（概念 → 論理 → 物理）
  • データウェアハウス／データレイク／レイクハウス／メッシュ／ストリーミング向けのプラットフォーム選定判断ツリー
  • ツールの推奨を含むガバナンスの柱の計画
  • ADRテンプレートの生成とステークホルダーレビュープロセス

使用方法

  1. ユーザーのデータアーキテクチャに関するニーズ（プラットフォームの選定、モデリング、ガバナンス、意思決定フレームワーク）を特定します
  2. 以下の該当するワークフローに従います
  3. ADR、データモデル図、プラットフォーム比較マトリクス、ガバナンスポリシーなど、構造化された成果物を作成します

例

  • ユーザー：「分析にはデータレイクとデータウェアハウスのどちらを使うべきですか？」 エージェント：プラットフォームとテクノロジーの選定ワークフロー（ワークフロー3）を実行し、構造化データと生データのニーズを評価したうえで、トレードオフを示しながらデータウェアハウス／データレイク／レイクハウスを推奨します

  • ユーザー：「顧客ドメインをモデル化したいです」 エージェント：データモデリングワークフロー（ワークフロー2）を実行し、概念モデル（エンティティ、関係）から始めて、論理ER図へ進み、最後に物理DDLを作成します

  • ユーザー：「GDPRに準拠するためにデータガバナンスを整えるにはどうすればよいですか？」 エージェント：ガバナンスとコンプライアンスの計画（ワークフロー4）を実行し、GDPRの要件をガバナンスの柱に対応付け、ツールと統制を推奨します

主要なワークフロー

1. アーキテクチャ意思決定フレームワーク

あらゆる重要なデータアーキテクチャ上の意思決定に、この5段階のプロセスを使用します。

  1. 意思決定の背景を定義する

    • ビジネス上の推進要因（規模、レイテンシ、コスト、コンプライアンス）
    • 制約（予算、スケジュール、既存技術、チームのスキル）
    • ステークホルダー（データエンジニア、アナリスト、プロダクト、法務）

  2. 選択肢を特定する

    • 少なくとも3つの選択肢（何もしない、最小限の変更、抜本的な変更）
    • クラウドネイティブ、ハイブリッド、オープンソースの選択肢を含める

  3. 基準に照らして評価する

    基準重み各選択肢のスコア（1～5）
    スケーラビリティ高
    コスト（3年間のTCO）高
    価値実現までの時間中
    運用の複雑さ中
    チームとの適合性中
    ベンダーロックインのリスク低

  4. リスクと軽減策を評価する

    • 移行リスク、人材リスク、運用リスク
    • 上位2つの選択肢についてPOC計画を立てる

  5. 意思決定を文書化する

    • 背景、決定、結果を記載したADR（アーキテクチャ意思決定記録）
    • ステークホルダーと共有し、四半期ごとに見直す
2. データモデリングのワークフロー

ビジネスから実装へ段階的に詳細化します：

段階成果物対象者主なアクティビティ
概念エンティティ一覧、リレーションシップ、ビジネス用語集ビジネス関係者ワークショップ、ドメインイベント
論理正規化されたER図、属性、キーデータアナリスト、アーキテクトエンティティの特定、多対多の解消
物理DB固有のDDL、パーティション、インデックスエンジニアプラットフォームの最適化、非正規化

主な原則：

  • 技術ではなく、ビジネス上の問いから始めます
  • 物理モデルでは代理キーを、論理モデルでは自然キーを使用します
  • パフォーマンス要件がある場合に限り、非正規化します
3. プラットフォームとテクノロジーの選定

判断ツリー：

  • 構造化分析とBIを大規模に行う必要がありますか？ → データウェアハウス（Snowflake、BigQuery、Redshift）
  • 生データ、ML、柔軟なスキーマが必要ですか？ → データレイク（S3 + Athena/Spark）
  • ACID保証を備えた両方が必要ですか？ → レイクハウス（Databricks、Iceberg、Hudi）
  • ドメインごとのオーナーシップとフェデレーション型ガバナンスが必要ですか？ → データメッシュ（ドメインごとに複数のウェアハウス／レイク）
  • リアルタイム性と低レイテンシが必要ですか？ → ストリーミングファースト（Kafka + Flink + マテリアライズドビュー）
4. ガバナンスとコンプライアンスの計画

ガバナンスの柱：

柱アクティビティツール
データ品質プロファイリング、検証ルール、異常検知dbt tests、Great Expectations、Monte Carlo
データカタログメタデータ、リネージ、探索DataHub、Collibra、Alation
アクセス制御RBAC、ABAC、マスキング、暗号化プラットフォーム標準機能 + Immuta/Okera
マスターデータ管理ゴールデンレコード、重複排除Informatica、Reltio、カスタムMDM
コンプライアンスGDPR、CCPA、HIPAA、SOC 2法務レビュー + 技術的制御

コメント

Markdown 対応