ブロックチェーンSNS概念設計：システム構築の品質評価のポイント5：一貫性と構造化の度合い② | 続・ティール組織　研究会のブログ
AmebaAmeba 20th Anniv.ホームピグアメブロ
芸能人ブログ人気ブログ
新規登録
ログイン

続・ティール組織　研究会のブログ

ティール組織が話題になっているが、具現化するにはどうしたらよいか？
その研究を続けるにあたり、さらに次の形態である、続・ティール組織なるものまで視野に入れ、具体的な施策・行動内容を研究・支援する会。

ブロックチェーンSNS概念設計：システム構築の品質評価のポイント5：一貫性と構造化の度合い②

先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。大まかな概念としてはひとまず終えた。次は、ブロックチェーンの概念設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。

愛記システムのシステム評価について

システム評価とは、つまりは、このシステムを導入して成功だったか失敗だったかという効果検証という意味だ。概念設計をする上で必ず抑えておくべきポイントということだ。それには各項目があり、それぞれの項目を見ていくことで、その結果が得られる。そのシステム評価項目を1つずつ見ていきたい。

システム構築の品質評価のポイント1：理解可能性（Understandability）

システム構築の品質評価のポイント2：完全性（Completeness）

システム構築の品質評価のポイント3：簡潔性（Conciseness）

システム構築の品質評価のポイント4：移植性（Portability）

システム構築の品質評価のポイント5：一貫性（Consistency）と構造化の度合い

システム構築の品質評価のポイント6：保守性（Maintainability）

システム構築の品質評価のポイント7：試験性（Testability）

システム構築の品質評価のポイント8：ユーザビリティ（Usability）

システム構築の品質評価のポイント9：効率性（Efficiency）

システム構築の品質評価のポイント10：セキュリティ（Security）

システム構築の品質評価のポイント5：一貫性と構造化の度合い②

先にシステム評価の一貫性について記載した。システム開発中の開発者たちでの一貫性だけでなく、バージョンアップ時の一貫性もそうであり、ユーザビリティの一貫性もしかり、すべてを考慮して設計していかねばならない。一貫性という項目もまた極めて重要な要素であることが良く分かった。今度は構造化の度合いについても見ていきたい。そのためにも、今一度、構造化データと非構造化データの違いから見ていく。

非構造化データとは

データとは、構造化データと非構造化データによって構成されるデータ群で、そのうちの非構造化データはネイティブな形式のまま保存されている。また、使用する時まで何も処理されないという特徴がありながら、使用する時は比較的自由にデータを処理できるため柔軟性が高く、用途の幅が広い点がメリットである。そのままでも人間が認識、理解しやすいのも特徴である。ネイティブな形式では保存する際のデータ形式に指定はない。そのため、幅広い範囲のファイル形式で保管することができる。さらに、データの定義をする必要がないことから収集を素早く行える点もメリットと言えるだろう。加えて、非構造化データは膨大な量（容量）になる傾向にあるため、大容量の保存が可能なクラウドストレージやクラウドのデータレイクを活用する。それらは、容量無制限であったり、使用状況に合わせて従量課金できるため、コストを抑えられる。

 

非構造化データにはEメールやソーシャルメディアの投稿、音声、画像、文書、ログ等のセンサーデータなどが含まれ、構造化データよりも多種多様でデータ量も膨大である。企業が自社に保有しているデータの大部分が非構造化データである。これは企業が事業を推進していく中で発生するメールや提案書、企画書、請求書、画像、音声などのデータが非構造化データに分類されるからである。非構造化データはIT/ICTの広がり、業務管理システムの普及やコミュニケーション基盤のデジタル化などを背景に膨大な量に膨れ上がってきた。また、e-文書法や電子帳簿保存法などの法整備も行われ、紙書類が電子データ化されたことも非構造化データが増加した大きな要因であろう。人が目にするもの、触れるもの全てが非構造化データとなって蓄積されてもおかしくない世の中になっているのである。反面、非構造化データは、人間は理解できてもコンピュータには扱いにくいデータでもあり、これまで構造化データほど活用が進んでこなかった。

 

今後、デジタルシフトがさらに進むことで非構造化データの総量はより一層増加すると予測されており、データの有効活用に対する重要性が増していくと予想される。そのため、非構造化データの分析基盤がますます注目されていくだろう。

非構造化データには課題もある

デジタルトランスフォーメーションの推進やテレワークの普及、ビジネスのグローバリゼーションなどにより、企業が保有するデータ量は増加の一途をたどっている。特に非構造化データはデータ量が大きく、管理体制や活用する基盤作り、セキュリティ対策などへの対応が求められる。

 

ブロックチェーンやDAppsにおいても、非構造化データやファイル、コンテンツを一元的に集約し、適切に管理して活用するためには文書管理やコンテンツ管理の知識が必要であろう。以下は、その理由や関連するポイントについて記載する：

  1. データの整理と構造化:

    • ブロックチェーンやDAppsでは、トランザクションデータやスマートコントラクトによって生成されるデータが非構造化であることがある。この非構造化データを適切に整理し、構造化データとして扱うためには、文書管理やコンテンツ管理の知識が必要である。非構造化データを適切に整理し、構造化データとして扱うためには、下記のような具体的な手順や方法が考えられる。

    • データモデリング:

      • データモデリングは、データの構造や関係を定義し、整理するプロセスである。非構造化データを構造化するために、データモデルを設計し、それに基づいてデータのフィールドや関係性を把握する。この際、データの種類や属性、関連性などを考慮する。

    • データのタグ付けとメタデータ管理:

      • データに適切なタグやメタデータを付与して、データの属性や特性を明示化する。これにより、データをより効果的に分類し、検索可能にする。例えば、トランザクションデータの種類や発生時刻、関連するスマートコントラクトなどに関するメタデータを追加する。

    • スキーマの定義:

      • データのスキーマを定義し、それに基づいてデータの構造を整理する。スキーマは、データのフィールドや型、制約を示すものであり、構造化データの整合性を保つために役立つ。スキーマに基づいてデータを整形し、統一されたフォーマットで保存する。

    • データの正規化:

      • データの正規化は、冗長性を減らし、データの整合性を向上させる手法である。非構造化データから冗長な情報を排除し、正規化された構造化データを生成する。

    • データベースの活用:

      • 構造化データを効果的に管理するためには、データベースを活用する。トランザクションデータやスマートコントラクトからの情報をデータベースに格納し、クエリや分析が容易になるようにする。

    • データ統合:

      • さまざまなデータ源からの非構造化データを統合し、一元的に管理する。データ統合を行うことで、異なるデータソースから得られた情報を組み合わせて利用できるようになる。ブロックチェーン上でのトランザクションは一貫性を保つために検証される。これにより、異なるノード間でのデータの整合性が維持され、データ統合が信頼性を持って行われる。
      • ブロックチェーンSNSでは、一部のデータはオフチェーンに存在することがある。例えば、大容量のメディアファイルやプライベートな情報などである。これらのオフチェーンデータを適切に統合し、ブロックチェーン上のデータと関連づける必要がある。

    • 分析と可視化:

      • 構造化データに変換された情報は、データ分析や可視化ツールを使用して効果的に活用できる。これにより、洞察を得ることや意思決定をサポートすることが可能である。

    • これらの手法を組み合わせて、ブロックチェーンやDAppsにおいて生成される非構造化データを適切に整理し、構造化データとして効果的に利用することができる。

    •  

  2. データの保管とバージョン管理:

    • ブロックチェーンにはデータの不変性があるが、一方で大量のデータやファイルが発生する可能性がある。これらのデータやファイルを適切に保管し、バージョン管理するためには、文書管理やコンテンツ管理のベストプラクティスが必要である。以下に具体的な手法を記載する：

    • 分散型ファイルシステムの活用:

      • データやファイルを分散型ファイルシステムに保存することで、各ノードがデータにアクセスできるようになる。分散型ファイルシステムは冗長性を持ち、データの不変性を保つのに役立つ。

    • ハッシュ値の利用:

      • データやファイルに対してハッシュ値を計算し、そのハッシュ値をブロックチェーンに格納することで、データの不変性を確認できる。変更がある場合は新しいハッシュ値が生成され、それが新たなブロックに含まれる。

    • スマートコントラクトによるアクセス制御:

      • ブロックチェーン上のスマートコントラクトを使用して、データやファイルへのアクセスを管理する。アクセス権の制御をスマートコントラクトで定義し、ユーザーによる不正な変更を防ぐ。
      • スマートコントラクト内でユーザーが特定のデータやファイルにアクセスする際に、そのユーザーが所定のアクセス権を持っているかを確認する。これには、ユーザーのアクセス権限情報とリクエストされたアクションに対する権限が一致するかどうかの判定が含まれる。
      • アクセス権の変更や新しいユーザーの追加などが必要な場合、スマートコントラクトを更新する。これには、ブロックチェーン上でのアップグレードや新しいバージョンのデプロイが含まれる。

    • オフチェーンデータの適切な管理:

      • 大容量のデータやファイルは、必ずしもすべてをブロックチェーン上に格納する必要はない。重要なメタデータやハッシュ値をブロックチェーンに保存し、実際のデータはオフチェーンに保存することで、ブロックチェーンの効率を向上させる。以下に例を示す。
      • IPFSは分散型のファイルシステムで、ハッシュ値を使用してデータを識別します。ブロックチェーン上にはIPFSハッシュを保存し、実際のデータはIPFS上に格納する。IPFS APIを使用して、データの追加、取得、削除などの操作を行う。
      • Storjは分散型のオブジェクトストレージプラットフォームで、ファイルを分散して保存する。Storj APIを使用して、ファイルのアップロードやダウンロード、ストレージの管理を行う。ブロックチェーン上にはStorjオブジェクトのハッシュやメタデータを保存する。
      • OrbitDBは分散型のデータベースで、IPFSを基盤としている。ブロックチェーン上にはOrbitDBのデータベースのハッシュやメタデータを保存し、実際のデータはOrbitDB上に格納する。OrbitDB APIを使用してデータベースの操作を行う。

    • 分散型ストレージの利用:

      • データやファイルを分散型のストレージシステムに格納することで、冗長性や耐障害性を確保する。データの不変性を保ちながら、分散ストレージでの管理がブロックチェーンの原則と合致する。

    • データのエンクリプション:

      • データやファイルをエンクリプトして保存することで、セキュリティを向上させます。特にプライバシーが重要な場合は、エンクリプトされた形でブロックチェーン上に格納する。これには、選んだ暗号アルゴリズムと鍵を使用してデータを暗号化する手順が含まれる。通常、対称鍵暗号方式（AESなど）がデータの高速なエンクリプションに適している。
      • エンクリプションに使用する鍵を適切に管理する。鍵の生成、保存、更新、削除などについての適切な鍵管理ポリシーを定義し、これを実施する。また、公開鍵暗号方式を用いて鍵の配送を行う場合、公開鍵を安全に共有する仕組みも構築する。

    • イミュータブルなアーカイブの作成:

      • 定期的にデータやファイルのイミュータブルなアーカイブを作成し、ブロックチェーン上に格納する。これにより、特定の時点のデータの状態を確認でき、バージョン管理が容易になる。これには、アーカイブ自体をブロックチェーンのトランザクションとして扱う方法や、アーカイブのハッシュ値をブロックチェーン上に保存する方法がある。ハッシュ値を保存する場合、実際のデータはオフチェーンに格納されることが一般的である。
      • ブロックチェーン上には、イミュータブルなアーカイブに関するメタデータを追加する。これにはアーカイブの作成日時、作成者の情報、バージョン番号などが含まれる。これにより、ブロックチェーン上で特定の時点のデータの状態や変更履歴を確認できる。

    • データの削除と廃棄方針の策定:

      • ブロックチェーン上のデータは不変性があるため、誤ってアップロードされた情報や不要になったデータを削除することは難しい。データの管理ポリシーや廃棄方針を策定し、不要なデータを保管しないようにする。

    • これらのベストプラクティスを適用することで、ブロックチェーン上でデータやファイルを適切に保管し、バージョン管理することが可能である。

    •  

  3. アクセス権限とセキュリティ:

    • ブロックチェーン上のデータやファイルにはアクセス権限の管理が必要です。文書管理やコンテンツ管理の知識があれば、適切な権限設定やセキュリティ対策を行い、機密性を確保することができる。
    • Verifiable Credentialsを使用する。これにより、各ユーザーに一意の識別子が与えられ、そのユーザーの認証情報をブロックチェーン上で確認できる。
    • マルチシグネチャは、複数の秘密鍵が必要な署名プロセスを通じてアクセスを認可する仕組みであるが、複数の関係者が協力してデータにアクセスする場合に有用であり、権限の分散管理が可能である。
    •  

  4. 検索と分類:

    • 大量のデータやファイルが蓄積された場合、それらを効果的に検索し、分類することが求められる。文書管理やコンテンツ管理の手法を活用することで、データの探索性や可視性を向上させることが可能である。
    • ブロックチェーン上での検索を向上させるために、分散型の検索インデックスを構築する。これにより、データを効率的に検索し、特定の条件に基づいて分類することが可能になる。
    • ユーザーがデータを検索する際には、キーワード検索やフィルタリング機能を提供する。これにより、特定のキーワードや条件に一致するデータを検索しやすくなる。
    • ブロックチェーン上での分散型機械学習や分散型人工知能を活用して、データやファイルを自動的に分類する仕組みを構築する。これにより、大量のデータを自動的に整理しやすくなる。
    •  

  5. データの利活用:

    • データが一元管理され、適切に構造化されていれば、そのデータを分析や活用に役立てることができる。文書管理やコンテンツ管理の知識は、データを有効に利活用するための基盤を提供する。愛記システムやブロックチェーンSNSにおいて、適切なデータ構造はプロジェクトの性質や目的によって異なる。以下は、愛記システムに関連する可能性のあるデータ構造の例である：

    • トランザクションデータのリレーショナルデータベース:

      • ユーザーの愛の行動に関するトランザクションデータをリレーショナルデータベースに格納することが考えられる。ユーザーアカウント、トランザクションの種類（愛の行動）、日時、関連ユーザーなどの情報を含むテーブルが構築される。

    • 分散型IDと認証のNoSQLデータベース:

      • ユーザーの分散型IDや認証情報は、NoSQLデータベースに格納される可能性がある。ユーザーごとに異なる属性や認証情報を柔軟に管理することができる。

    • 愛貨の取引履歴のデータウェアハウス:

      • 愛貨に関する取引履歴や統計データはデータウェアハウスに格納され、分析やレポートに活用されるだろう。愛貨の発行量、取引履歴、ユーザーごとの保有量などが含まれる。

    • ユーザー関係のグラフデータベース:

      • ユーザー間の関係や相互作用はグラフデータベースに格納され、ユーザー同士のつながりやネットワーク構造を効果的に表現する。例えば、ユーザー同士の愛の行動に基づくつながりや共通の興味を示すグラフが構築される。グラフアルゴリズムを使用して、コミュニティの検出や重要なノードの同定なども可能である。

    • 愛の行動に基づく時系列データベース:

      • 愛の行動に関する時系列データは時系列データベースに格納され、特定の期間や傾向に基づく分析が行われるだろう。時間の経過に伴うユーザーの活動や変化を効果的に管理する。
      • 時系列データを効果的に管理するためには、時系列データベースを選定する。代表的な時系列データベースには、InfluxDB、Prometheus、TimescaleDBなどがある。これらのデータベースは、高いパフォーマンスと時系列データに特化した機能を提供する。
      • 時系列データの分析結果を可視化するために、専用の可視化ツールを活用する。これにより、ユーザーの活動の時間変化や特定の傾向を直感的に理解できる。Grafana、Kibana、Tableauなどのツールが利用可能であろう。
      • 時系列データベースを使用して、異常検知や将来の傾向を予測するための分析を行う。これにより、異常な愛の行動や将来の傾向に対する洞察を得ることができる。

    • ドキュメントデータベース:

      • ユーザーのプロフィールや愛の行動に関する詳細な情報はドキュメントデータベースに格納される可能性がある。個々のユーザーに対する情報が柔軟に管理される。ドキュメントデータベースでは、通常、JSON形式のドキュメントを使用してデータを表現する。各ユーザーに関する情報は一つのドキュメントとして格納される。これにより、情報を柔軟かつ階層的に管理できる。
      • ドキュメントデータベースでは、特定のフィールドに対してインデックスを作成することができる。これにより、クエリのパフォーマンスを向上させ、検索や絞り込みを迅速に行えるようになる。例えば、ユーザー名や生年月日に対してインデックスを作成することが考えられる。
    •  

  6. 法規制やコンプライアンス:

    • 特にビジネスや金融分野においては法規制やコンプライアンスへの適合が求められる。文書管理やコンテンツ管理のノウハウを活用して、データの保存期間や適切な情報開示などの要件に対応することが必要である。
    • 重要な文書や契約には電子署名や認証を導入し、デジタル上での取引や契約が法的に有効であることを確認する。これにより、法的要件に対応できる。
    • 業界や地域の法的保持要件に合わせてデータの保持期間を管理する。重要な文書やデータは、法的に求められる期間だけ保管し、期限が切れたら適切に廃棄する。
    • 法的な要求や訴訟に対応するために、必要な情報を適切に開示できるように準備する。文書やデータの検索性やアクセス可能性を確保することが重要である。

ブロックチェーンやDAppsにおいても、非構造化データの適切な管理は重要であり、そのためには文書管理やコンテンツ管理の原則や手法を理解して実践することが役立つことが上記で理解できるだろう。このようなことを具体的に設計していきたい。

 

非構造化データを活用するために

非構造化データを扱うには実際にデータを構造化データでデータレイクやDWH（Data Warehouse）等に集約したように、ファイルやコンテンツも一元的に集約し、適切に管理し、活用できる文書管理やコンテンツ管理の知識が必要になる。まずはデータ活用ができる人材の育成や支援ができるコンサルとの協業が求められる。また、ストレージやプラットフォームの構築など、データを保管、管理する環境構築への投資も必須である。世界中がDXに動く中で、非構造化データのビジネスにおける活用方法を明確化し、中長期的なコンテンツ管理戦略の観点から構造化データとともに効率的かつ効果的な管理体制を整えられるかは、その後の成否を分けるのだろう。

 

では、愛記システムの場合、構造化の度合いをどうするのか？という問題が発生する。愛記システムの中に、様々な分析ツールを用意しておくのであれば、構造化データがほとんどでも良いのであろう。しかし、分析の用途は多様だ。そのような多様な分析に耐えられる分析ツールをすべて用意するのも困難だ。それであれば、半構造化データである.csvでの出力は絶対条件であろう。いつ、誰に、どこで、何を、どうやって、という5W1Hは当然分析していくのであろうから。

 

他には、日時、位置情報、などの非構造化データも当然に分析していくのであろう。位置情報は用途によって様々な形式がある。

  • CSV形式
  • JSON形式
  • XML形式
  • KML形式

CSV形式は、Excelなどの表計算ソフトで簡単に開くことができるため、扱いやすい形式である。JSON形式は、Webアプリケーションなどでよく使われる形式で、データのやり取りに適している。XML形式は、Webサービスなどでよく使われる形式で、データの構造を明確に示すことができる。KML形式は、Google Earthなどで利用される形式で、地図上に位置情報を表示することができる。

 

位置情報の解析において、様々な形式の位置情報がある。具体的な位置情報の形式は、用途やデータの収集手法によって異なるが、一般的な例を示す。

  1. 緯度経度座標 (Latitude-Longitude Coordinates):

    • 最も一般的な形式で、地球上の特定の位置を指定するために使用される。例えば、35.6895° N, 139.6917° E のように表現される。これは地球上の緯度と経度を示している。

  2. 住所 (Address):

    • 住所は、位置を特定するために広く使用される形式である。都市、町、通り、建物番号などが含まれる。例えば、「東京都港区六本木6-10-1」などである。

  3. 標高 (Elevation):

    • 特定の地点の高度や標高情報も位置情報の一部として使用される。これは海抜ゼロ地点からの高さを示し、3D空間における位置を補完するのに役立つ。

  4. 国別の位置コード (Geocoding):

    • 国や地域ごとに異なる位置コードが存在する。例えば、日本の郵便番号や国際的な地域コードなどがこれに該当する。

  5. Wi-FiやBluetoothのビーコン情報:

    • 屋内での位置情報を特定するために、Wi-FiやBluetoothのビーコン情報が使用されることがある。これにより、建物内の特定の場所における位置情報を取得できる。

  6. IPアドレス (Geolocation by IP):

    • デバイスのIPアドレスを使用して、大まかな位置情報を特定することができる。ただし、この方法は正確性に制約がある。

  7. ポイント・ライン・ポリゴン (Point, Line, Polygon):

    • GIS (地理情報システム)でよく使用される形式で、地図上の点、線、面を表現する。ポイントは単一の座標、ラインは複数の座標をつなげた線、ポリゴンは閉じた領域を表す。

  8. 地名データベースのID:

    • 地名データベースに登録されている特定の地名や場所に対するIDが使用されることがある。これにより、統一された形式で位置情報を参照できる。

これらの形式は、位置情報を収集・解析する上で一般的なものである。使用するデータの種類や解析の目的によって、これらの形式を組み合わせたり変換したりすることがある。

 

なお、位置情報を格納するためには、他のデータ同様、データモデルを設計しておく必要がある。これには、位置情報の座標、タイムスタンプ、ユーザーIDなどが含まれるだろう。モデルはプロジェクトのニーズに応じて調整される。そして、収集した位置情報をデータベースに格納する。この際、ユーザーIDやタイムスタンプなどを組み合わせて、一意のエントリを作成する。適切な索引を設定して検索を効率的に行えるようにする必要がある。

 

さらに、ユーザーのプライバシーを保護するために、適切な暗号化や匿名化手法を適用する必要がある。位置情報が個別のユーザーに関連付けられる場合は、十分なセキュリティ対策が必要であるのだから。データベースへのアクセス制御を導入し、必要なユーザーだけが必要な情報にアクセスできるようにし、不正アクセスから保護する。

 

また、位置情報データの重要性を考慮して、定期的なバックアッププロセスを確立し、データの復旧が迅速かつ信頼性が高いことを確認する。データを可視化するためのツールやダッシュボードも導入する。これにより、位置情報を分析しやすくし、プロジェクトの進捗や傾向を把握できるようになる。

 

 

いかがであろうか、今回はシステム評価の構造化の度合いについて記載した。なかなかに悩ましいことだらけだ。具体的な設計を詰めていきたい。