Froglog

このポストについて ​ DMBOK2 を読み進めていくシリーズ。 今回は第13章「データ品質」について。 これまで業務で「データ品質」という言葉が使われることがあったが、意味が限定的だったり人によって定義が違ったりしていた。 そのあたりクリアにできるとよい。 ​ 内容紹介 ​ データ品質の定義 ​ データ品質の簡潔な定義は「目的に適合している」。 データ品質管理の定義は「データを収集し扱うための技法を適用し、企業や地域のデータ利用者の、ニーズや利用に適したデータとすることを保証する活動を計画し、実施し、管理する」。 ​ データ基盤担当の仕事柄、データ品質というとどちらかというと上流であるデータソース側の定義が重要だと思っていたが、そうではなく下流であるデータ利用においての観点が起点になるというのが気づきだった。(でも考えてみれば当たり前) ​ ビジネス上の意義 ​ ステークホルダーの体験と組織の評判を高める ex. データが正しいことを顧客が信頼し、組織との取引に自信を持てる 組織がより有効な成果を出せるようにする ex. ビジネスチャンスの特定と効果的な請求により売上を獲得できる 低品質なデータによるリスクとコストを削減する ex. データが正しいかどうかをスタッフが見極める時間が減る ex. 誤ったデータによる誤った意思決定 組織の効率と生産性を向上する ex. カスタマーサービスにかかってくる電話が減り、問い合わせを解決できるようになる ​ 重要なデータ ​ データ品質管理における第一の原則は、組織とその顧客にとって最も重要なデータに改善努力を集中させること。 ​ ex. 顧客のメールアドレス欄のデータが不完全であれば、顧客にメールで商品情報を送ることができず、潜在的な売上を失う 1通のメールを送るごとに100円の収益が得られることが知られている → データ品質の改善に明確な価値があると言える ​ 重要なデータは組織や業界によって異なるが、以下のような用途で使用されることが多い。 ​ 規制、財務、経営報告 事業運営上のニーズ 製品の品質と顧客満足度の測定 事業戦略、特に競争上の差別化への取り組み ​ データ品質評価軸 ​ データ品質評価軸は、測定可能なデータの特徴または特性。 一般的な評価軸は次のとおり。 ​ No. 評価軸 説明 例 1 有効性Validity データの値が定義された領域の値と一致しているかどうか。 - 数値、日付などのデータ範囲- 電話番号などの書式 2 完全性Completeness 必要なデータがすべて存在するかどうか。カラム, レコード, データセットのレベルがある。 - カラム: 必須カラムにデータが入っているか？- データセット: 都道府県マスタに47都道府県の情報はあるか？ 3 一貫性Consistency データ値が同じアプローチ、評価、価値基準を用いてコード化されていることを保証すること。レコード内、レコード間、経時的な一貫性などがある。 - すべての顧客企業の住所は本社住所となっているか？- 生徒の成績評価は時を経ても同じか？ 4 整合性Integrity データに非一貫性や破綻した関係性がないこと。 - 顧客住所の国がカナダの場合、州としてカナダの州が記載されているか？ 5 適時性Timeliness データの取得または更新後、ユーザーがデータにアクセスできるようになるまでの時間を指す。 - 電力会社は電力需要データを数秒以内に利用して需給調整する必要がある- 政府機関が四半期末の2ヶ月後に GDP 報告書を作成 6 最新性Currency データが最後に更新されてから現在までの期間と、それがまだ正しいという可能性。データセットによって期待される最新性は異なる。 - 国コードは比較的静的- 銀行口座残高は変動的 7 妥当性Reasonableness データパターンが期待に合致しているかどうか。 - 先週のクリック数と比較して今日のクリック数は普通か否か？ 8 一意性/重複排除Uniqueness/Deduplication 現実世界の実体がデータセット内に2つ以上存在しないこと。 - ユーザー ID は重複していないか？- ユーザー ID は異なるが、同一の人物を表していないか？ 9 正確性Accuracy データが「現実の」実体を正しく表している程度。 - ユーザー名は現実世界の個人の名前なのか？- 顧客は実際にそのメールアドレスを使用しているのか？ ​ ここでようやく「データ品質」が具体的なものとして見えてきた。 測定が比較的容易なものもあれば困難なものもある。 ​ ...

このポストについて Data Contract CLI を触ってみたところ、面白かったのとこれからのデータパイプライン開発について思うところがあったので書いてみる。 Data Contract CLI とは？ datacontract/datacontract-cli Data Contract CLI は data contracts を運用するためのオープンソースのコマンドラインツールである。 data contracts の概念については以前の記事で詳しく書いているのでそちらをご参考いただければと。 ただしこちらの記事は1年前のものであり、今回取り上げる Data Contract CLI の登場などを含めて現在では data contracts を取り巻く状況も変わっている可能性があることに注意。 Data Contract CLI は Python で開発されており、pip でインストールすることができる。 この記事を書いている時点では v0.10.3 が最新であり、この記事の内容はこのバージョンに基づいている。 Data Contract CLI で扱う data contracts は YAML で定義される前提となっており、その仕様は datacontract/datacontract-specification で決められている。 この data contracts に対して Data Contract CLI では次のようなことが行える。 lint によるフォーマットチェック データソースに接続した上での schema やデータ品質のテスト data contracts の破壊的な変更の検出 JSON Schema や dbt など、他の形式からの／へのインポートとエクスポート 以下の図がイメージしやすい。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第8章「データ統合と相互運用性」について。 業務で扱っているデータ基盤はデータ統合が不完全であるため、なんとかしたいと考えている。 以降、特に注釈のない引用は DMBOK2 第8章からの引用とする。 データストレージと相互運用性とは データ統合と相互運用性 (DII: Data Integration and Interoperability) は次のように定義されている。 アプリケーションや組織内および相互間におけるデータの移動と統合を管理する データの移動を効率的に管理することがそのビジネス上の意義となる。 ほとんどの組織には数多くのデータストアがあり、組織内・組織間でデータを移動させることは IT 組織の重要な任務となっている。 複雑さとそれに伴うコストを管理するために、全社的な視点からデータ統合を設計しなければならない。 データウェアハウスなどのデータハブによりアプリケーション間のインターフェースの数を削減することができる。 DII のゴールは以下 法令を遵守しながら、必要とするフォーマットと時間枠でデータを安全に提供する。 共有のモデルとインターフェースを開発することでソリューションを管理するコストと複雑さを軽減する。 重要なイベントを特定し、アラートとアクションを自動的に起動する。 ビジネスインテリジェンス、アナリティクス、マスターデータ管理、業務効率化の取り組みをサポートする。 概念・用語など 抽出、変換、取込 DII の中心にあるのが、抽出 (Extract)、変換 (Transform)、取込 (Load) のいわゆる ETL という基本プロセス。 抽出 ソースから必要なデータを選択し、抽出する 抽出されたデータはディスク上やメモリ上にステージングされる 業務システムで実行される場合は、少ないリソースを利用するように設計する 変換 ソースデータを変換してターゲットデータストアの構造と互換性を持つようにする フォーマット変更、構造の変更、意味的変換、重複排除、並べ替えなどがある 取込 ターゲットシステムに物理的に格納されるか、提供される ELT ターゲットシステムにより多くの変化機能がある場合は、プロセスの順序を ELT にすることができる データレイクへの取込を行うビッグデータ環境では一般的 レイテンシ ソースシステムでデータが生成されてから、ターゲットシステムでそのデータが利用可能になるまでの時間差。 アプローチによってレイテンシの高低が異なる。 バッチ 利用者や自動的な要求に応えて、定期的にアプリケーションや組織間を一定量まとまって移動させる レイテンシは高いが大量データを処理するときのパフォーマンスがいい 低レイテンシを実現するためのマイクロバッチもある 変更データキャプチャ データの変更 (挿入・変更・削除) のデータセットを監視し、その差分をターゲットのシステムに渡す DBMS のアクティビティログをコピーし、処理する形で行われることもある 準リアルタイムとイベント駆動 設定された予定により1日を通して分割された少量のデータセットで処理されたり、データ更新などのイベントが発生したときに処理されたりする 一般的にエンタープライズ・サービス・バスを利用して実装される 非同期 データ提供側は受信側の更新確認を待たずに処理を続行する リアルタイム、同期 次のトランザクションを実行する前に、他のアプリケーションからの確認を受け取るまで実行プロセスが待機する 非同期と比べて状態管理の負担が少ないが、他のトランザクションをブロックしたり遅延させたりすることもある 低レイテンシまたはストリーミング イベントが発生したときにシステムからリアルタイムで連続して流れる リプリケーション 分析やクエリによるパフォーマンス低下を防ぐために、トランザクション処理環境にリプリケーション (複製) を使用することがある。 多くの DBMS にはリプリケーションを作るためのユーティリティ機能がある。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データストレージとオペレーション」について。 主にデータベースの運用に関する内容となっており、いわゆるデータベースエンジニアの人には当たり前の話？が書かれている。 以降、特に注釈のない引用は DMBOK2 第6章からの引用とする。 データストレージとオペレーションとは 以下のように定義されている。 データの価値を最大化するために、永続化されるデータを設計し、実装し、サポートすること 主にデータベース管理者 (DBA: Database Administrators) が行うことになる。 次の2つのアクティビティが含まれる。 データベースサポート: データベース環境の初期実装からデータの取得、バックアップ、廃棄までのデータライフサイクル関連アクティビティ データベース技術サポート: 技術要件を決め、技術的なアーキテクチャを定義し、技術を実装・管理する 事業がデータに依存する企業においてはデータストレージとオペレーションのアクティビティは事業の継続性のために必要不可欠である。 ゴールは次のとおり データライフサイクル全体にわたるデータの可用性を管理する データ資産の完全性を保証する データ処理の性能を管理する 概念・用語など データベースアーキテクチャの種類 集中型データベース: 単一システム内で使うデータを一箇所にまとている 分散型データベース: 多数のノードにデータが配置される 連邦型データベース: 自立した複数のデータベースシステムを単一の連邦型データベースに割り当てる 仮想化／クラウドプラットフォーム: クラウド上のデータベースを実装 データベース処理のタイプ ACID: トランザクションの信頼性のための制約 原子性 (Atomicity): 操作はすべて実行されるかまったく実行されないかのどちらか 一貫性 (Consistency): トランザクションはシステムが定義するすべてのルールを常に満たさなければならない 独立性 (Isolation): 各トランザクションは実行中の他のトランザクションの影響を受けない 永続性 (Durability): トランザクションは完了すると元に戻せない BASE: データの量と多様性を受けた、ACID とは異なる考え 基本的に利用可能 (Basically Available): ノードの障害発生時もあるレベル以上の可用性を保証する ソフトステート (Soft State): データは一定の変動状態にある 最終的な一貫性の確保 (Eventual Consistency): データは最終的にすべてのノードで一貫性を保つが、各トランザクションの一貫性が常に確保されているわけではない CAP: 分散システムでは以下のどれか2つしか満たせない 一貫性 (Consistency): システムは常に想定どおり動作できなければならない 可用性 (Availability): システムは要求時に利用可能でなければならに 分断耐性 (Partition Tolerance): システムは部分的な障害の発生時に運用を続行できなければならない データベース構成 上から順により制御された構造であり、かつ古くからあるものとなっている。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データモデリングとデザイン」について。 第4章でデータモデリングについて言及されていたが、ここで詳しく見ていく。 以降、特に注釈のない引用は DMBOK2 第5章からの引用とする。 データモデリングとは データモデリングとは、データ要件を洗い出し、分析し、取扱スコープを決めるプロセスであり、データ要件を記述し伝えるために、明確に定義されたデータモデルと呼ばれる様式が用いられる。このプロセスは反復的であり、概念、論理、物理モデルが含まれる。 第4章 データアーキテクチャ ではエンタープライズ・データモデルという言葉が登場したが、この第5章ではそのデータモデルがより具体的に解説されている。 データモデルは効果的なデータマネジメントを行うにあたり必要なものとされている。 次のような意義がある。 データに関する共通語彙を提供する 組織のデータや情報システムに関しての明示的な知識を捉え文書化する プロジェクトにおいて主なコミュニケーションツールとして使われる アプリケーションをカスタマイズ、統合、リプレースする際の出発点となる データモデルは組織が把握した現状、またはあるべき姿として組織のデータを記述する。 カテゴリー情報、リソース情報、業務イベント情報、詳細取引情報がその対象となる。 データモデルの構成要素 ほとんどのデータモデルはエンティティ、リレーションシップ、属性、ドメインにより構成される。 エンティティ エンティティとはある組織が情報を収集する対象のこと。 組織が使う名詞。 以下は Marmaid の Entity Relationship Diagrams でエンティティを表現した例。 学校を例にしており、学生、コース、インストラクタがエンティティとして表されている。 --- title: Entity --- erDiagram Student Course Instructor リレーションシップ リレーションシップはエンティティ間の関連性を表す。 以下の例は学生はコースを “履修する”、インストラクタはコースを “教える” ことを表している。 --- title: Relationship --- erDiagram Student }|--|{ Course : take Instructor }|--|{ Course : teach 線の両端の形はリレーションシップの cardinality (多重度) を表している。 この場合ではそれぞれカラスの足状になっているが、それぞれ「1またはそれ以上」という意味で、「学生は1つ以上のコースを履修する」「コースは1人以上の学生に履修される」ということを表している。 リレーションシップの arity (項数) は一般的には二項型 (バイナリリレーションシップ) であることが多く、2つのエンティティ間の関係を表す。 一方で線の両端が同じエンティティにつながっている単項型、3のエンティティが関連する三項型もある。 以下は単項型の例で、前提となるコースの履修が必要であることを示す。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第4章「データアーキテクチャ」について。 やや抽象度が高い内容となっており、理解が難しいと感じた。 以降、特に注釈のない引用は DMBOK2 第4章からの引用とする。 データアーキテクチャとは データアーキテクチャの定義は以下のとおり。 企業の (組織構造に関係なく) データニーズを明確にし、ニーズに合うマスターとなる青写真を設計し、維持する。マスターとなる青写真を使ってデータ統合を手引し、データ資産をコントロールし、ビジネス戦略に合わせてデータへの投資を行う。 業務戦略と技術実装の間を橋渡しすることがデータアーキテクチャの目的。 以下が成果物、つまり前述の定義の「マスターとなる青写真」となる。 データの保存と処理の要件 企業の現在のデータ要件と長期のデータ要件を満たす構造や計画の立案 これらを記述するためにエンタープライズ・データモデル (EDM) とデータフロー設計が必要となる。(後述) エンタープライズアーキテクチャ データアーキテクチャとビジネス、アプリケーション、テクニカルなど他の領域のアーキテクチャとの違いは下表のようになる。 それぞれが影響を及ぼし合う関係となっており、データアーキテクチャはビジネスアーキテクチャによって決められる。 ドメイン エンタープライズ・ビジネスアーキテクチャ エンタープライズ・データアーキテクチャ エンタープライズ・アプリケーションアーキテクチャ エンタープライズ・テクニカルアーキテクチャ 目的 企業が顧客や他のステークホルダに どのように価値提供しているかを 明らかにする データがどのように整理・管理されるべきか記述する 企業内アプリケーションの 構造と機能を記述する システムを稼働して価値を 提供するために必要な 物理実装技術を記述する 要素 ビジネスモデル、業務プロセス、業務能力、サービス、イベント、戦略、語彙集 データモデル、データ定義、データマッピング仕様、データフロー、構造化データの API ビジネスシステム、ソフトウェアパッケージ、データベース テクニカルプラットフォーム、ネットワーク、セキュリティ、統合ツール 依存関係 他のドメインに対する要件を設定する ビジネスアーキテクチャによって作られ、要求されるデータを管理する ビジネス要件に基づいて特定されたデータに対応する アプリケーションアーキテクチャを提供し実行する 役割 ビジネスアーキテクトとアナリスト、ビジネス・データスチュワード データアーキテクトとモデラー、データスチュワード アプリケーションアーキテクト インフラストラクチャアーキテクト DMBOK2 表6 アーキテクチャ領域 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第15章「データマネジメント成熟度アセスメント」について。 データマネジメントの導入において重要な役割を果たしそうなので早めに確認しておきたかった。 以降、特に注釈のない引用は DMBOK2 第15章からの引用とする。 データマネジメント成熟度アセスメントとは データマネジメント成熟度アセスメント (DMMA: Data Management Maturity Assessment) はその名の通り、組織のデータマネジメントのレベルの評価に基づくプロセス改善の取り組みのこと。 能力成熟度アセスメント (CMA: Capability Maturity Assessment) というものがあり、それのデータマネジメント版が DMMA。 CMA では 成熟度モデルは進化の観点から定義され、それにはプロセスの特性を表すレベルが使用される。組織がプロセスの特性を理解すると、組織は成熟度を測り、その能力を向上させるための計画を立てることができる。(中略) 新しいレベルに上がる度にプロセスの実行はより一貫性を増し、予測可能な状態となり、信頼性が高くなる。 レベルは通常0~5の6段階で表される。 DMMA は 全体的なデータマネジメントを評価するために使用したり、単一の知識領域や、単一のプロセスに焦点を当てて使用したりできる。どのような点に焦点を当てたとしても、DMMA はデータマネジメント業務の健全性と有効性について、業務と IT の視点のギャップを埋めるために役立つ。 組織が DMMA を実施する理由は、規制への対応、データガバナンス、プロセス改善、etc. DMMA の第一のゴールはデータマネジメント活動の現状を評価することであり、それにより改善計画を立てることができるようになる。 アセスメントレベル 以下はアセスメントレベルの概要。 データマネジメントの各知識領域 (ex. データガバナンス、メタデータ管理、etc.) ごとにレベルが評価される。 level 0: 能力が欠如した状態 データマネジメントの取り組みがない level 1: 初期／場当たり的な状態 限られたツールセットを用いた一般的なデータマネジメント ガバナンスは低レベル データ処理は一部の専門家に依存し、役割や責任は部門別に定義されている level 2: 反復可能な状態 組織は一元化された共通ツールを使い始める 役割は明確化されており、一部の専門家のみに依存しない level 3: 定義された状態 拡張可能なプロセスの導入と制度化 組織全体である程度統制されたデータの複製 データ品質全体の総体的な向上 組織的なポリシー定義と統制 level 4: 管理された状態 新しいプロジェクトやタスクから得られる結果が予測され、リスクの管理が始まる データマネジメントに成果に対する評価尺度が含まれる データマネジメント用の標準ツールが集中管理計画とガバナンス機能に組み合わされている level 5: 最適化された状態 活動の成果は十分予測可能に 組織は継続的な改善に重点を置く 十分理解された評価尺度を使ってデータ品質とプロセスが管理・測定される 次のように各知識領域ごとに可視化することができる。 現状ランクと求められるランクの乖離が大きいところが組織にとってのリスクとなる。 ...

このポストについて 前回の記事 dlt 入門 - ELT の Extract と Load を担う data load tool では dlt の概要を説明した。 この記事ではそれを踏まえ、dlt を使って CSV ファイルを BigQuery に load するという一連の開発作業をやってみる。 現実の CSV はそのまま使えなかったりするので、BigQuery に入れるまでに泥臭い前処理のような作業があることが多い。 そのへんもまとめて dlt でやってみるとこんな感じ、というのが示せるとよい。 やりたいこと 個人で管理しているお金の情報を個人用の BigQuery に置きたい、という要件を想定。 データ概要 具体的には MoneyForward のデータを load していく。 個人では API を利用できないので、web UI から export できる CSV のデータで収入・支出詳細と資産推移月次を対象とする。 CSV の export 方法は以下を参照。 入出金履歴はダウンロードできますか – マネーフォワード MEサポートサイト データの内容は次のようになっている。 収入・支出詳細_2023-11-01_2023-11-30.csv "計算対象","日付","内容","金額（円）","保有金融機関","大項目","中項目","メモ","振替","ID" "1","2023/11/30","AMAZON.CO.JP","-2830","楽天カード","食費","食料品","","0","EPv92ZjQcOxgWQx_cLbhD1" "1","2023/11/24","東京ガス","-4321","楽天カード","水道・光熱費","ガス・灯油代","","0","r6wuQPfrIRS6aFpNYZE5Eh" "1","2023/11/24","給与 カ) フロッグログ","700000","みずほ銀行","収入","給与","","0","doettKpYyNp0Tml9KQQXm1" ヘッダーがあり、各列に名前が付いている。 encoding が CP932 であることに注意。 ID の列があるので、行の識別に使えそう。 ...

このポストについて このポストは datatech-jp Advent Calendar 2023 の18日目の投稿です。 web の記事で見かけた dlt というツールが気になったので調べてみた。 dlt の概要について書いていく。 What is dlt? https://dlthub.com/ dlt とは “data load tool” の略。 雑に言うとデータパイプラインにおける ELT の Extract と Load を行う ものとなっている。 主にベルリンとニューヨークに拠点を持つ dltHub 社によって開発されており、OSS の Python ライブラリとして提供されている。 次のような特徴を持つ。 プラットフォームではなくあくまでライブラリであることが強調されている つまり Airflow, GitHub Actions, Google Cloud Functions, ローカル環境などどこでも動かすことができる スケールアウト可能な分散処理ではない extract と load にまつわる反復的で平凡な作業をなくすことを目指している schema 推論や schema evolution をサポート 宣言的なコードでメンテナンスを楽にする incremental loading をサポート 豊富な source GA, Salesforce, Kinesis などいろいろ例が挙げられている 要は API からの取得も含めて JSON-like な形式で Python で読めるものなら何でも 豊富な destination BigQuery, Snowflake など主要なクラウド DWH DuckDB はローカルでの動作確認に便利 Airflow, dbt などとの連携がある CLI の提供もある その他、Glossary を見ておくとドキュメントが読みやすくなる。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第12章「メタデータ管理」について。 仕事でメタデータを扱い始めたので読んでおきたかった。 以降、特に注釈のない引用は DMBOK2 第12章からの引用とする。 メタデータとは 一般的な説明としては「データに関するデータ」とよく言われている。 データに関するデータはすべてメタデータなので、メタデータはとても幅広い内容となっている。 DMBOK2 ではメタデータの説明として図書館の例を挙げている。 そこには数十万の書籍と雑誌があるのに、図書目録がない。図書目録がなければ、読者は特定の本や特定のトピックの検索を開始する方法さえ分からないかもしれない。図書目録は、必要な情報 (図書館が所有する本と資料、保管場所) を提供するだけでなく、利用者が様々な着眼点 (対象分野、著者、タイトル) から資料を見つけることを可能にする。 (中略) メタデータを持たない組織は、図書目録のない図書館のようなものである。 データという資産を管理するためにも、データを利用するためにも、リスクマネジメントのためにもメタデータは必要となる。 メタデータの種類 メタデータはビジネス、テクニカル、オペレーショナルの3つに分類することができる。 ビジネスメタデータ 主にデータの内容と状態に重点を置く。 IT からは独立している。 dataset, table, column の定義と説明 業務ルール、変換ルール、計算方法、導出方法 データモデル etc. テクニカルメタデータ 技術的詳細やシステムに関する情報。 主に IT に関連している。 物理 database の table, column の名称 column のプロパティ アクセス権 etc. オペレーショナルメタデータ データの処理とアクセスの詳細を示す。 運用で得られる情報とも言える。 バッチプログラムのジョブ実行ログ データの抽出とその結果などの履歴 運用スケジュールの以上 etc. 以上、各種のメタデータで例に挙げたのはあくまで一部であり、現実にはもっと多くのメタデータが存在する。 メタデータを管理する意義 図書館の例からもわかるとおり、メタデータなしではデータを管理することはできない。 信頼性が高く管理されたメタデータにより、次のようなことができるようになる。 データのコンテキストを提供し、それによりデータ品質を測定可能にして信頼性を向上させる 業務効率の向上、および古いデータや誤ったデータの利用防止 データ利用者とエンジニアの間のコミュニケーションの改善 法令遵守の支援 etc. メタデータの管理が不十分だと次のようなことが起こる。 一貫性のないデータ利用と誤った定義によるリスク メタデータは複製されて保管されることによる冗長性 利用者の信頼性低下 etc. メタデータアーキテクチャ メタデータの内容は幅広いがしたがってその取得元も幅広く、ビジネス用語集、BI ツール、モデリングツール、等々が挙げられる。 これらを何らかの方法で集約し、一箇所のメタデータポータルで閲覧できるようにする必要がある。 つまり「ここに来ればデータについてのことがわかる」という入り口を設けることになる。 そのためのアーキテクチャの構成が4つ挙げられている。 ...