今一度、"愛記"について記載を開始したい。どのように実装していけばよいのか、概念的なところからアプローチ方法を記載していく。
システム評価とは、このシステムを導入して成功だったか失敗だったかという効果検証という意味だ。概念設計をする上で必ず抑えておくべきポイントということだ。それには各項目があり、それぞれの項目を見ていくことで、その結果が得られる。そのシステム評価項目を1つずつ見ていきたい。
システム構築の品質評価のポイント1：理解可能性（Understandability）
システム構築の品質評価のポイント2：完全性（Completeness）
システム構築の品質評価のポイント3：簡潔性（Conciseness）
システム構築の品質評価のポイント4：移植性（Portability）
システム構築の品質評価のポイント5：一貫性（Consistency）と構造化の度合い
システム構築の品質評価のポイント6：保守性（Maintainability）
システム構築の品質評価のポイント7：試験性（Testability）
システム構築の品質評価のポイント8：ユーザビリティ（Usability）
システム構築の品質評価のポイント9：効率性（Efficiency）
システム構築の品質評価のポイント10：セキュリティ（Security）
システム構築の品質評価のポイント5：一貫性と構造化の度合い②
先にシステム評価の一貫性について記載した。システム開発中の開発者たちでの一貫性だけでなく、バージョンアップ時の一貫性もそうであり、ユーザビリティの一貫性もしかり、すべてを考慮して設計していかねばならない。一貫性という項目もまた極めて重要な要素であることが良く分かった。今度は構造化の度合いについても見ていきたい。そのためにも、今一度、構造化データと非構造化データの違いから見ていく。以下、こちらより抜粋。
非構造化データとは
データとは、構造化データと非構造化データによって構成されるデータ群で、そのうちの非構造化データはネイティブな形式のまま保存されている。また、使用する時まで何も処理されないという特徴がありながら、使用する時は比較的自由にデータを処理できるため柔軟性が高く、用途の幅が広い点がメリットである。そのままでも人間が認識、理解しやすいのも特徴である。ネイティブな形式では保存する際のデータ形式に指定はない。そのため、幅広い範囲のファイル形式で保管することができる。さらに、データの定義をする必要がないことから収集を素早く行える点もメリットと言えるだろう。加えて、非構造化データは膨大な量（容量）になる傾向にあるため、大容量の保存が可能なクラウドストレージやクラウドのデータレイクを活用する。それらは、容量無制限であったり、使用状況に合わせて従量課金できるため、コストを抑えられる。
非構造化データにはEメールやソーシャルメディアの投稿、音声、画像、文書、ログ等のセンサーデータなどが含まれ、構造化データよりも多種多様でデータ量も膨大である。それぞれの活用方法については、以下で詳述する。
テキストデータ
インターネット上にある非構造化データの中でも膨大な量を誇るテキストデータの形式は、小説のような長文からTwitterなどの短い文章の投稿などまで多岐に亘る。テキストデータを読み取ることで、口コミやSNSの投稿からブランドに対するイメージの調査や、顧客が抱えている課題の発見、要約生成技術による議事録などの文書自動作成、言語の自動翻訳など幅広く活用されている。
センサーデータ
ネットワーク化に伴うIoTやビッグデータ分析、OT分野やセンサー技術の発展により、工場内での製造過程のデータや室内の温度、位置情報といった情報まで幅広く取得できるようになった。センサーデータを活用すれば、どのような場所でどのようなタイミング等の予測など、様々な用途で利用できる。いわゆる画像やMicrosoft Officeドキュメント等のファイルと区別するため、半構造化データや準構造化データと呼ばれることもある。
構造化データとの違い
形式が定められておらず、処理がされていない非構造化データに対して、構造化データはSFAやCRM、ERPなどの業務管理システムのアプリケーション内やRDBに蓄積されるデータを指す。Excelのような表計算ソフトのように「列」と「行」で情報がまとめられている点が特徴である。データもネイティブな状態ではなく、事前定義された状態で格納されているため、誰でもデータを扱えるようになっている。ただし、人間は構造化データをそのまま見ても理解しにくく、コンピュータが処理や計算がしやすくなっている。よって、構造化データを利用するには専門的な処理を行う必要があり、データを扱う人にはある程度の専門知識が必要になる。
構造化データ自体は、予め定義されている、つまり処理が施されていることで扱いやすくなっているメリットがあり、例えば、機械学習での利用にも適している。また、多くのITツールに対応している点も大きな特徴である。また、構造化データは、データをそのままの状態で保存するスキーマオンリード(Schema on Read)ではなく、特定のデータ利用を想定したデータスキーマオンライト(Schema on Write)のデータベースに保存される。
半構造化データとは
半構造化データとは、構造化データと非構造化データの中間に位置するデータである。大きく分類すると非構造化データに含まれるが、特定の特性を明確化するメタデータの構造が決まっていることから、処理すればすぐに構造化データとしても扱える点が特徴である。列と行で明確に構造化されているわけではないが、規則性のある要素があり、階層化されているため、扱いやすいデータ群と言える。.csvや.tsvが例となる。.csvは、CSVファイルと呼ばれる一方で、カンマ区切りで項目が分けられ構造化されている点が中間的な位置づけで、構造化データのようにも扱えるのだろう。
非構造化データの分析はこれからの時代に必要
企業が自社に保有しているデータの大部分が非構造化データである。これは企業が事業を推進していく中で発生するメールや提案書、企画書、請求書、画像、音声などのデータが非構造化データに分類されるからである。非構造化データはIT/ICTの広がり、業務管理システムの普及やコミュニケーション基盤のデジタル化などを背景に膨大な量に膨れ上がってきた。また、e-文書法や電子帳簿保存法などの法整備も行われ、紙書類が電子データ化されたことも非構造化データが増加した大きな要因であろう。人が目にするもの、触れるもの全てが非構造化データとなって蓄積されてもおかしくない世の中になっているのである。反面、非構造化データは、人間は理解できてもコンピュータには扱いにくいデータでもあり、これまで構造化データほど活用が進んでこなかった。
今後、デジタルシフトがさらに進むことで非構造化データの総量はより一層増加すると予測されており、データの有効活用に対する重要性が増していくと予想される。そのため、非構造化データの分析基盤がますます注目されていくだろう。
非構造化データには課題もある
デジタルトランスフォーメーションの推進やテレワークの普及、ビジネスのグローバリゼーションなどにより、企業が保有するデータ量は増加の一途をたどっている。特に非構造化データはデータ量が大きく、管理体制や活用する基盤作り、セキュリティ対策などへの対応が求められる。
具体的に環境整備の中で課題となるのが、データ管理のための大規模なストレージ確保にともなって発生するコストである。保存されるデータ量の増加に応じたストレージの拡張が必要になると、維持コストが増加する。また、非構造化データの増加によって扱うファイル形式の数やコンテンツの種類が多岐に亘り、管理が難しくなる。そのため、管理体制の構築をする際に管理システムを導入するコストもかかる。さらに、組織が保有する非構造化データを自由に扱えるようにすると、その分情報漏えいや改ざんなどのセキュリティ面や情報ガバナンス面でのリスク対策も必要になる。
非構造化データを活用するために
非構造化データを扱うには実際にデータを構造化データでデータレイクやDWH（Data Warehouse）等に集約したように、ファイルやコンテンツも一元的に集約し、適切に管理し、活用できる文書管理やコンテンツ管理の知識が必要になる。まずはデータ活用ができる人材の育成や支援ができるコンサルとの協業が求められる。また、ストレージやプラットフォームの構築など、データを保管、管理する環境構築への投資も必須である。世界中がDXに動く中で、非構造化データのビジネスにおける活用方法を明確化し、中長期的なコンテンツ管理戦略の観点から構造化データとともに効率的かつ効果的な管理体制を整えられるかは、その後の成否を分けるのだろう。
では、愛記システムの場合、構造化の度合いをどうするのか？という問題が発生する。愛記システムの中に、様々な分析ツールを用意しておくのであれば、構造化データがほとんどでも良いのであろう。しかし、分析の用途は多様だ。そのような多様な分析に耐えられる分析ツールをすべて用意するのも困難だ。それであれば、半構造化データである.csvでの出力は絶対条件であろう。いつ、誰に、どこで、何を、どうやって、という5W1Hは当然分析していくのであろうから。
他には、日時、位置情報、などの非構造化データも当然に分析していくのであろう。位置情報は用途によって様々な形式がある。
- CSV形式
- JSON形式
- XML形式
- KML形式
CSV形式は、Excelなどの表計算ソフトで簡単に開くことができるため、扱いやすい形式である。JSON形式は、Webアプリケーションなどでよく使われる形式で、データのやり取りに適している。XML形式は、Webサービスなどでよく使われる形式で、データの構造を明確に示すことができる。KML形式は、Google Earthなどで利用される形式で、地図上に位置情報を表示することができる。
さらには、行動内容が悩ましい。愛の行動をして愛貨をやり取りすると、次のような仕訳がなされるのだが、その際の行動内容はテキストのみか、それとも画像やファイルや音声も有りとするのかが悩ましい。
・借方（発信先）：第3次元：輸送機事業部_社長、Lv3：目標に向かい行動する、70愛貨が渡される
→詳細内容を備考欄に記入（←ここに愛の行動内容が入る）
・貸方（受信側）：第3次元：輸送機事業部_Aさん、自主的にアイデアを提案する、70愛貨を受け取る
→ 背景等を備考欄に記入（←ここに愛の行動内容が入る）
この仕訳時に、詳細内容をいちいち入れなくても仕訳はできるが、備忘録のために詳細内容を入れておきたいというニーズも多いので、ここは入れることが出来るようにしておきたい。なお、仕訳はブロックチェーンで成されるので後から加筆修正はできないが、詳細内容覧は、後から修正できるようサーバーで別管理できるような設計が出来うるのか？も検証したい。仕訳の意味合いが変わってくるのなら難しいかもしれないが。
いずれにしても、詳細内容にはテキストのみか？それとも画像やファイルや音声も有りとするのかによって、データ量も変わるし、設計も大きく変わってくる。出力をどうするのか？という問題もある。これらを改めて設計していかねばならない。
いかがであろうか、今回はシステム評価の構造化の度合いについて記載した。なかなかに悩ましいことだらけだ。どうするのか、今一度深く考え、検証していきたい。