- その149 ： エンタープライズ・データモデリングを考えるために(2)
前回、エンタープライズ・データモデル構築というのは「目標」ではなく「結果」として捉えることが望ましい活動形に近いと考えることでした。それを分かり易く言えば、二種類のモデル基礎作り方法を例えて用いて説明するのが一つの方法だ思っています。その第一は、「ピラミッド型で、類似した直方体型の材料を利用して基礎から一段・一段と階層的に組立て、基礎建造物として構築する方式です（ここではモジュール方式と呼びます）。第二は「石垣方式」で、必ずしも同一形状でない違いを持つ石材を利用して、噛み合わせや組立て強度を考慮しつつ堅固な土台に仕上げる石垣型で基礎を組み上げる方式です（ここではそのまま石垣方式と呼びます）。
モジュール方式の基本として、まず取り上げられる事は、類似構造の組立てにより速やかに立ち上げられる点でしょう。この要点は、最終的な構造物をどのような単位で区切り、また切り分け組み立てるかという設計です。これにより素材を作る過程を分かり易くし、組立の時間効率を上げる役割を持たせることができるということが期待されます。課題としては、先に書いた「適切な区分設計」をどのように行う点にあります。初めに設計した区分が妥当なものであれば、割合スムースに組立を行い稼働状態に持ち込むことが期待されます。途中で設計（或いは仕様）変更が必要になった場合には、他のモジュールへの影響度合いをレビューし、場合によっては根本的な見直しを図る必要も出てくるでしょう。ピラミッドの下位（ベースとなる基本部分）への大きな変更発生の場合には、上段への影響度が拡大する可能性も存在します。
一方、石垣方式の考え方を見る場合の、モジュール方式との違いに着もすした特徴を考えます。ここでの構成要素の基本は、要求される機能を構築する中で並行的に把握し、周囲の組立の構造との接合点（インタフェース）を整備しながら組立を行ってゆく点だと考えます。この手順に伴い、関連する周辺の組立要素範囲を把握・整理し易いのではないかというのが筆者の考え方です。要領よく整備・構築する前提ですが、途中または後日発生する変更点に対しても対応をしやすくなる設計構造にすることが期待できるという意味です。つまり、機能的に関係のあるデータを整理し、把握しやすくできる点です。こうして組立て構築して出来上がった生成物が有機的なものとして働くことになることを期待します。
両者のどちらに関しても重要な役割を果たすのは、「コード設計」の面です。ここでは所謂マスタデータ（広義・狭義の両者）設計であり、この定義・設計が成功の肝になることには変わりありません。このマスタデータ設計で大切な点は、構築物（システム）の利用者目線をどう取り込むかということであると筆者は考えています。それは利用者／部署の視点（分類視点、活用視点）の双方であり、これが前回現れていた、業務系および分析系の2種類のモデルが実務上必要とされるという議論のベースにあると考えています。このコード設計の共通部分および（利用者／部署）独自部分をどう切り分け、更に将来の変更要求に応えられるようにするかという点が重要性を持ちます。
- このようにして一旦出来上がった成果物（システム）の設計情報を電子的に整備し、また後日の変更要求に合わせて維持・管理してゆくことが、稼働後の重要な活動になることはいうまでもありません。設計・構築者の異動や退職に伴い、現在の稼働状態を把握できる担当者がいないという状況は避けるべく、常に維持活動を継続してゆくという点を忘れることはできません。これを継続する仕掛け作り、及び人／ツールを含めた環境と資源配分を行うことが経営者および管理者の重要な役割であることを強調して、この回を終了します。
- （先頭に戻る）
- その148： エンタープライズ・データモデリングを考えるために
現在参加している日本データマネジメント協会(Dama-Japan)の第１０分科会の月次勉強会(11月19日(火)開催)で「エンタープライズ・データモデリング」を話題に、議論が交換されました。この議論の中で、筆者がそのモデリング検討について感じた幾つかの要点をここで記述しておきたいと考えます。
まず、エンタープライズ・データモデルを取り上げる際に、現在のその位置付けには、幾つかの見方があるといえます。「エンタープライズ」と言う位ですから、個人やローカルの視点ではなく、企業の利用を目的に作られるデータモデルであることを想定しているということでしょう。違いが生まれるのは、整備されるモデルはどういうものか(その構築の仕方を踏まえて)という点の方針に関わると考えられます。専門家が集まる当日の議論では、全社的な取り込み・利用データを一つの大きなデータモデルとして整理し表現するものだという考え方が中心であったと捉えられます(実際には、メインでの発表者からは、一つの業務系のデータモデルと、もう一つの分析系用途のデータモデル、つまり2分類のモデルの組合せとして説明されました)。経験的には、この形が現在企業レベルのデータモデルに携わる多くの関係者が持つイメージと捉えられます。また、海外で(業界別)多くのベンダー系企業からエンタープライズの「参照データモデル」として紹介する場合も、このベース構成が多いようです。
先の議論では、その位置付けを説明するのに一つの日本地図を作るようなものとして例示されていました。しかし最近の筆者の見方では、この一つの(或いは2分類を基準とした)モデル構築を行うという見方とは少々異なってきていると考えています。その理由の一つは、仮に一つのモデルの完成形を作り出すのに極端に言って、100年経って(以前の)完全なデータモデルを完成しても、実用的な利用には間に合わないためです。このため、データモデル構築の期間や投資資源の適切性に関する説得材料に欠け、更にこれを作り上げる技術者目線でも実際的なプロジェクトとして参画意欲をそそるものとはならないでしょう。また、情報システムの技術基盤とそれを利用／表現するビジネスそのものについても、環境（或いは状態）が絶えず変化するという悩みもあります。従って、時間と労力を掛けて1つの大きなデータモデルを作り上げ、その後更にそれを維持し続けることは、企業活動の実用性からかけ離れたものと写ります。そもそも当該企業が存続していない可能性が大きい。
つまり、実用的なエンタープライズ・データモデルというのは、企業活動の実践を支援し、その活動成果を上げるために役立てるためにあるという意味であり、初めから単一性をイメージして構築するものではないだろうということです。企業活動の時間軸と並行して、限られた自社資源を回転させながら、実用的なコストで作り上げるという視点を前提としているということが必要でしょう。その結果として1つのデータモデルが出来上がったということはあり得るでしょう。つまりそれは目標ではなく、結果であるという認識が大切という点です。また先に、データモデルは一つの日本地図として例えられていましたが、これも見方によっては大きな誤解を生じさせる表現とも、筆者には捉えられます。なぜなら現実に作られている日本地図、そのモデルというのは一つで作り、運用されている訳ではないからです。しかし、利用する立場（位置）の応じて、その複数の構成情報によって実用的にモデル化され、認識を共有する姿が、エンタープライズ・データモデルの構築・維持に役立つ視点だと筆者は考えます。
- その内容について、筆者の考え方を説明したいのですが、紙面の関係で今回はその課題を取り上げるまでとして、次回以降のこの欄で補足説明することにします。
- （先頭に戻る）
- その147： グラフ・データベース利用を考察する（3）
現在のグラフ・データベースの利用場面を大別すると3種類位に分類できるようです。1つ目はトリプル（三つ組み）を格納する入れ物としての利用。2つ目は、オントロジー構築中心の構造管理を主目的とした使い方。3つめは知識データベースとしての利用を目的とする知識グラフといった方向です。それぞれの特徴と注意点に関する考察を記述します。
1つ目のトリプル格納バケツとしての代表格は、所謂リンクト・オープンデータ(LOD)の取込みを目的としたものです。コレは広範囲な全体構造を把握・管理するよりは、外部で公開されたデータとの情報的拡張・接続性を主な期待値として利用するものと考えられます。ここでは基本的にはインスタンスの集合という形態であり、データの拡張利用においては語彙の一致性が鍵になると云えます。但し語彙というモノは、同じ名称を使っていても意味合いが異なるという「同音(名)意義」、また異なる語彙であっても実は同じ意味を表しているという「異語同義性」といった現象を表すことが頻繁にあり、正確性の揺らぎを生じる傾向があります。その上で三つ組みレベルの集合という点が、対象データの急激な増加を生むという現象に繋がります。異なった言語で表現されたトリプルを結合する場合、更にこの三つ組み集合の表す結果の正確性／品質が問題となる訳です。この点を許容する範囲で納める結合の工夫が重要性を持ちます。
2つ目の活用方向は、オントロジー構築の基盤としての利用です。1つめの利用との関連としては、三つ組みの単なる大規模集合に意味の基礎を与えるという役割と
云えます(これはボトムアップ的アプローチということになり、手間も掛かるものになるでしょう)。一方データで表したい意味構造を概念レベルから設計するという方向もあり、これはトップダウン的アプローチという正攻法です。このオントロジー構築の過程で、所謂マスタデータの設計と、その構成コード体系具体化という意味でマスタに属するインスタンス群の生成という流れが生まれるでしょう。こうして構築されたオントロジー構造が意味メタデータとして位置づけられ、品質を伴ったグラフデータが生まれることになります。この手法でビッグデータの機械学習連携が精度を向上するという効果を生むでしょう。
3つ目の方向は知識グラフの構築基盤という事ですが、この有効利用においては、2つめのオントロジー構築に加えてグラフデータベースを元にした推論規則構築の仕方と、これを用いた探索言語の整備という点が重要性を持ちます。これに関しては既に様々な試みが行われている状況ですが、基本的には対象領域（例えば、製造、金融、物流管理など）に特化した構築方法が主体になるでしょう。大域的な基本構造と、それを利用する
個 別プロセスの場面依存という課題があるためです。こうなると、探索された知識を反映して知識グラフにフィードバックするという方向の技術が、更に意味をもつことになるでしょう。
この分野においては、機械学習／AI技術の連携として、現在LLM（Large Language Model;大規模言語モデル )やRAG(Retrieval
Augmented Generation)技術の連携利用が試みられていますが、筆者の理解ではまだ実証実験段階であるように捉えられます。
- (備考) グラフ技術に関連する話題は、これまで游悠レポート資料の中で扱っているため、興味ある方は参照下さい。
- （先頭に戻る)
- その146： グラフ・データベース利用を考察する（2）
グラフ・データベースの利用、特に当該データをうまく管理・活用できるようにするためには、構成するオントロジー、モデルと語彙の管理が大切である点について前回の最後で触れました。その中でも（日本の）データモデル作成において余り重要視されているとは云えない関係性(グラフデータベース用語では「プロパティ」と呼ばれる事が多い）の精密な命名付与と・漏れ／重複のない管理が必要となります。更に英語語句での名称付与は、英語圏文化の成り立ちという点で取扱をし易いという特徴があるといえますが、日本語語句を用いる場合の名称付けには様々な工夫が必要になると考えておいた方が良いでしょう。これは検索言語の使い勝手にも影響します。
また、グラフ・データベースの基盤の中には、属性項目群を纏めてモデル化し管理可能なものが存在しますが、三つ組み(トリプレット)をベースにするアーキテクチャを採用している基盤の場合には属性項目の設計への取り入れ方を十分考慮に入れなければなりません。更にデータ読取り専門のモデルでなく、データ更新や追加を許す設計にする場合には、その更新手順等の十分な検討を行う必要があると云えます。簡単にいえば、三つ組み形式で表現されただけのLODデータは、基本的に表形式のデータが表頭項目と各行の集まりと考えられるため、集合的な意味や表同士の関係(結合キーの把握等)は、それぞれの表に現れる名称に頼らざるをえない形です。これを機械学習や推論技術で問題なく利用するにはモデル情報が不十分ということになるでしょう。
それを補う技術としてオントロジーといった概念世界の表現が必要とされるという訳です。いわば機械に概念の意図と構造を伝える手段としての位置付けがあるということです。勿論それは形式的な意味付けであり、本当の意味は人間が理解し判定するべきものと云えます。この辺りが機械利用の信頼性に関わる難しさともいえるでしょう。機械学習では、0～1の間の隙間を統計的に片寄せすると考える方が正しいのかもしれません。少し乱暴に語れば、ニューラルネットワーク(NN)のさまざまな技術は、その精度を上げるための手段であると考えることもできるでしょう。人間の判断に比べて幾ら精度が上がったと言っても、AIに百パーセント頼り切ることの危うさを忘れてはならないというのが現時点での筆者の考え方です。
グラフデータとオントロジーの話題から少々離れてしまいましたので、今回の話題に戻します。オントロジー設計に関していえば、実はその考え方はリレーショナルモデルやUMLモデルとそれ程大きく違うということではありません。基本的構造上の考え方においては類似しているため、リレーショナル型でのモデル構築に慣れた技術者に取っては、初めの用語や概念的な違いを乗り越えさえすれば、案外近寄り易い分野だともいえるでしょう。但しこれまでにも触れたように「精密さ」と一層の「概念指向」が要求される分野だということを心得ておく必要性があるでしょう。それを支えるツール技術としては、今後大きな改善が生まれる領域であるでしょう。この辺りは、グラフ利用の場面が増えることで次第に解決されることが期待されます。
(備考) グラフ技術に関連する話題は、これまで游悠レポート資料の中で扱っているため、興味ある方はそちらを参照下さい。
- （先頭に戻る)
- その145： グラフ・データベース利用を考察する（1）
グラフ・データベースが登場してから、既に20年以上の歴史があります。筆者の認識では、ここ数年になって注目度が一段上がってきたように思われます。データの視覚的イメージを元にした表現形式としては以前から利用されてきましたが、アプリケーションによる利用技術としてはネットワーク型の関係分析、インターネット等での個物の距離や結合度の強さ把握と云った領域で暫く注目されていた技術であったと考えています。またリンクト・オープンデータ(LOD)のような記述的データ表現(主語、述語、目的語のトリプル)を利用したデータの共有、連携のような点に着目し、その中から特徴を見出そうという流れがあったように思われます。
更に注目度が向上してきたのは、ここ数年のAI人気が貢献していると云えるでしょう。グラフ表現技術の利用により、機械による大量データの取込み、そして意味表現の標準化と、そこから派生する意味取り・推論への連携といったことが高い精度で可能になりつつあるといった点だと思われます。ただこの推論品質の高いデータ利用を実現するには、単なるトリプル(三つ組み)表現データの大量集合というだけでなく、データの類似性、意味表現の高度化といった点をカバーする要求への対応性を上げる必要性に迫られることになります。これを行う技術がオントロジーを導入したモデル表現の取り入れになります。
このオントロジー表現の取り入れというのは、使用するデータがリレーショナル・データベースに存在するきちんと整理・モデル化されたテーブル表現をそのまま利用する範囲であれば、ある程度の精度で利用可能でしょう(リレーション情報が体系化された上できちんと設計し、DBMS内のスキーマとして構築されたという前提があります）。そうでない場合、データの品質、精度といったものが犠牲にされ、利用者の信頼感を維持するのが難しいといった状況を生むことになりかねません。この意味で、既存のデータベースのモデル化適用が当初から行われていることが大切であり、後付けでオントロジー設計を行うという方針では立ちゆかないという現象が発生するといっても過言ではないといえます。
実際には、オントロジー設計というのはリレーショナル・モデル設計と根本的な違いがあるということではありません。クラス、サブクラス(リレーショナルでは、エンティティ、サブタイプ)、プロパティまたは関係性と属性(リレーションルではリレーションシップと属性)、インスタンス化(リレーショナルではロウの識別）といった類似性があります。またどちらのモデル化方式でも、ロール(役割)の適切な把握が大切な位置付けとなります。ややもすれば(特に日本では)「動詞句」として扱われ、余り語彙管理が疎かにされていた部分では、オントロジーを用いた設計では、管理上重要視される点に注意が必要です。
- 今後 分科会の議論の中で認識された考慮点等、折に触れこの欄で紹介したいと考えています。 游悠レポートとして関連資料を紹介していますので、当話題に興味ある方は合わせて参照下さい。
- （先頭に戻る）
- その144： 現在のユーザ・デジタル環境考（近頃の経験を通したレビュー）
- サービスサイエンスという研究領域の始まりは1980年代に遡ります。応用領域の中心はマーケティング分野に始まり、顧客満足を取り込む流れでのサービス指向の形で適用領域が広がってきたというのが著者の認識です。今回この話題冒頭に持ってきたのは、最近筆者のスマートフォンを利用機種変更のための作業をしながら浮かんだ考えに端を発します。DXの推進というのが経産省を初めとして様々な官公庁の音頭で進められ、その際の一般利用者に向けたインタフェース領域の主役は主にスマートフォンであると言って過言ではないでしょう（総務省統計によれば、2022年の個人のスマートフォン普及率は84.9%に上ると報告されている）。この機器基盤をベースに、例えばマイナンバー基盤を用いたスマートフォンのアプリケーション(アプリと略)を通じて、様々な利用者情報管理を次々と行おうという流れが進んでいます。
しかし一般利用者視点で改めて眺めて見ると、アーキテクチャやアプリケーション開発といった基本的な部分で、現在かなり無理が通されているのではないかと筆者は感じています。例えばスマートフォン上のアプリは、様々な企業が個別に自社サービスへの取込を狙う形で開発提供しているのが実情でしょう。この結果、利用者に取っては色々な会社のサービスを利用しようとすればするほど、際限のないアプリ導入を余儀なくされてしまいます。アプリというソフトウェアだけでなく、利用基盤であるスマートフォン(ハードウェア)は、電気を利用するという制約がある以上、バッテリー寿命を考慮せざるを得ないことにより2～5年程度といった比較的短期間でのユニット交換を迫られます(勿論、不便を受け入れた形で限界まで利用するという場合、もう少し利用期間は長くできるでしょう。新しい機種ではバッテリー充電量を大容量化しようという流れになっています)。また私企業によりOS開発側の都合により更新されたOS版を使うには、既存のスマホ資源(メモリ、CPU、グラフィックス機能等)が非力になってしまうことにもなります。
新しい機種に容易に乗り換えられる一部の利用者を除 いて 、残された一般的スキル及び経済的環境に置かれる他の利用者にとって、率直に言って経済的・時間的・技術的・
精神的負担は、もはや小さいものだと言い切れない状況と筆者は考えます。アプリ移行においても個別対応により、必要なIdやパスワード、承認方式が異なり、移行に際しての時間負担も小さいとはいえないのが現在のスマホ基盤提供の実態といえるでしょう。勿論、新機能が次々と開発され、それをスムーズに利用可能な「一部の利用者」に取ってはメリットが大きいという意見が出るのは承知の上ですが、ここでは残された(大多数ともいえる)利用者視点からの意見です(実際、筆者の周りの利用者の意見を聞くと、同様な意見をそれほど時間を使わずに集めるこができます。
- また、アプリ提供・開発者側から見ても本当の意味での一般利用者を想定したサービスデザインという点は少しおざなりにされているのではないかと疑いたくなります。話題先行、不具合が起きた場合、後追いで対応すれば良いという傾向もあるように思えます(典型的にはマイナンバーの暗証番号を高齢者向けにはなくそうという変更の話題に突然仕様変更が起きるなど。これはアプリそのものだけの話ではありませんが)。この稿で筆者が述べたいことは、様々なリテラシーおよび経済レベルの多数の利用者が混在する環境向けには、必ずしも「最新の技術に則ったアーキテクチャやインタフェースを導入して環境として放り出せば良い」という訳にはいかないことを十分考慮した方策・設計が必要であり、その点が十分検討されてない状況という点です。
（先頭に戻る）
- その143： オントロジー設計視点とデータモデルの課題考
今回の話題は、6月18日に(財)データマネジメント協会(旧・米Dama日本支部)の月次勉強会で筆者が次の表題で発表した内容を概要紹介するものです。「オントロジー視点と データモデル課題探訪
(誘い編）」（本内容に興味のある方は、「お問い合わせ」ページから筆者宛連絡を下さい） 昨今、リポジトリーといった用語管理や知識グラフとの連携といった点から「オントロジー」に関する技術知識領域に目を向ける人たちが徐々に増えてきています。元来「オントロジー」は哲学領域の「存在論」から始まり、情報学や人工知能の分野では工学的な技術領域として1990年代から研究されてきたものです。その概要的定義は「大雑把にいえば、概念化に現れる個物や関係をインスタンスとしてもつ
クラス（概念）を同定して、それらを上位下位関係に基づいて組織化したもの」と説明されています(※1)。
このオントロジー表現の構成要素の第1は、制約的集合で表される「概念クラス」。これは概念階層の親・子関係で示されます。親クラスの基本属性は子クラスに引き継がれます。その他の要素として、「意味リンク」。このリンクには「全体-部分リンク」「一般-特殊リンク」「抽象-具体リンク」といった代表的なものがあります。更に「属性」「関係」といった基本要素があります。また項目の果たす重要な捉え方に「ロール(役割)」があり、この考え方はデータモデルのエンティティ、リレーション、属性の捉え方(表現)にも影響を与えているといえます。
次にオントロジー設計を考える上で必要な要素は、(1)どのようなクラスを定義すべきか(クラス分類の推奨基準)、(2)本質属性の簡単な基準、(3)作成される対象ドメイン(分類)、(4)ロール(役割)概念の整理と表現、などが上げられます。但しオントロジーは表現レベルや研究者の捉え方により必ずしも同一の標準的表現で表されてはいない点に注意が必要です。またオントロジー設計ツール(エディター)に何を使用するかによって表現の制約が生まれます。オントロジーは表現する概念の構成と構造を表すものであり、実際のデータベースとして利用するには、具体物(インスタンス)群を作成追加することになります。
オントロジーを理解する上での逆の見方として、「オントロジーは何でないか？」を分かることも役立つでしょう。それを列挙すると、(a)オントロジーは単なる語彙集合ではない、(b)
オントロジーは単なる概念階層ではない、(c)オントロジーは知識表現ではない、といった項目が上げられます。そして、このオントロジー設計を支援するツールの代表
的なものには、「法造」(大阪大学溝口研究室開発、2023年現在は、大阪電気通信大学古崎研究室にてサポート)「Protégé 」(スタンフォード大学開発)があります。いずれもインターネットページからダウンロード利用が可能です。以上の内容は、主に溝口教授及び研究室著書を参考に説明したものです(※2)。
最後に、 このオントロジー視点から考察する筆者の捉えるデータモデルの課題点について項目列挙しておきます。(1) データモデル記述方式との類似性と差異は？
(2)用語の異同/類似性比較
(3)ER図 動詞句の果たす役割とその管理
(4)パーティモデルは過度な汎化（一般化）
(5)製造物のオントロジーとインスタンス視点
(6)オントロジー組立て妥当性の考慮例
(7)マスタデータ、リファレンスデータ等、コード系情報整理への活用
- 注※1 知の科学 オントロジー工学 p.6 溝口理一郎 著 人工知能学会 編 2005年 オーム社
注※2． －オントロジー構築入門 古崎晃司 他3名著 溝口理一郎 編 2006年 オーム社
－知の科学 オントロジー工学の理論と実践 溝口理一郎著 人工知能学会 編 2012年 オーム社
- (先頭へ戻る）
- その142： 「デジタル・サニハ」というスキルの重要性を考える
諸々の筆者都合により原稿休載していましたが、久々の話題を投稿します。今回はMLB（メジャーリーグ・ベースボール）の世界で起きた晴天の霹靂とも言うべき話題を題材にしたものです。この話題は、野球というスポーツのルールに詳しくない方々でもドジャースの大谷選手に興味のある人なら世界的に誰でも知っている内容と言って過言ではないものでしょう(大谷選手が米国での活躍をする上で、最も信頼していると思われたM氏(通訳)による大規模横領の件)。ここは内容自体を詮索することが目的ではないため、これ以上の事件詳細は割愛します。
ここでデータマネジメント、特にセキュリティの視点で着目したいポイントは以下の点です。 (1)他者の発するメッセージについて、元情報およびその出所を含めた信頼性の評価が必要(2)受け取ったメッセージについて、元情報およびその出所を含めた正確性の確認が必要
(3)起きている現象、プロセスに関して定期的、継続的なログ管理を行うことが必要 (4)現実的・物理的世界以上に「デジタル世界」では(1)～(3)を一層重要視したアクションが必要
(1)については、どこから、どのように、何を根拠に発生したデータ/情報を見ているのかを、信頼性評価の目で捉えることが常に必要であることを示します。ここでは常日頃、データ/情報の出所がどこまで信頼して良いモノであるかを観察しておくという努力が求められます。(2)については、自分に届けられたメッセージそのものの内容がどのようなものであり、どこまで受け入れて良いモノなのかを見極める習慣が必要だということです。そのためには、なにを元にしてデータ/情報が正しいと判断できるかの判別基準を常日頃鍛えておくことが求められます。ここで課題となるのが、(1)も(2)も100％間違いない答えを得ることが大変難しいという点です。その意味で確率的判断にならざるを得ない
。
そこで必要になるのが項目(3)であり、それを支える事象確認のための手段を用意することと、それが確実にアクション結果として表れていることを定期的にチェックすることが求められます。これが「管理する」という習慣です。過去・現在・未来の流れとして事象がどのように、いつ行われたかを確実に記録し、その結果がどうなったかを見定めることです。ここでは、予期しない事象が発生していないかを予防保守的に確認するという行動が含まれます。そして仮想的に構築された昨今のデジタル世界での事象(例えば金融取引、日常に的ショッピング等)については、より一層の管理習慣が必要であるというのが今回の事件を通じた教訓と言えるでしょう。この一連の習慣ポイントを、ここでは「デジタル・サニハ」習慣と呼んでおきます。
- 実際、今回の事件を有名選手に偶々起きた出来事と見過ごしてしまうことなく、自分の行動習慣として見直しておきたいというのが筆者自身へのメッセージです。（また、事件捜査の経緯を通じて、数年に渡る様々な取引記録(トランザクション処理内容、メッセージ往来記録、電話音声等)が数年に渡って記録され、レビュー可能な状態が裏面で行われていることを確認できた事も、筆者の収穫です。)
- (先頭に戻る)