アーカイブ2017年

    • その51：　今年もデータモデリングコンテスト開催。出題と応募要領発表。奮って応募を！
    • このコラムで何度も触れているJEMUG（日本エンタープライズデータモデリング・ユーザーズグループ）活動ですが、今年も昨年に引続きJEMUG主催のデータモデリングコンテストが開かれます。出題内容や応募要領は、こちらのJEMUGのWebページに公開されていますので、この分野に関心のある方は是非回答投稿を検討下さい。ささやかながら賞品も提供されます。 JEMUG会員に限らずどなたでも応募できますし、また締切り後の2月に行われる予定（日程未定）のJEMUG定例会を兼ねた審査ミーティングには会員であれば誰でも参加可能で、他の方々の応募したモデル結果内容を見てそれぞれの評価を行ったり、また審査そのものにも加わることができます。JEMUG会員には誰でも希望登録するだけでなることができます（現時点、会費無料）。これについても同じくJEMUGのGUESTページを参照下さい。ちなみに筆者は既報の通り、2016年度の最優秀賞を受賞しました。
    • ここで取り扱うのは募集要項では「概念データモデル」と呼んでいますが、対象となる領域の概要を意味を踏まえてER図表によりモデル表現しようという試みです。制約としては、25エンティティ以内でモデル図を表現し、主要な属性とそれらに係わるメタデータ定義情報を加えるというものです。それとモデル作成のツールとして米国ERwin Inc.のモデリングツール”erwin Data Modeler”を利用する（erwinファイル形式で作成）するということです。同社から提供されているこのツールの無料試用版を利用することができます（実は「25エンティティ」という条件は、この無料版で作成可能な数というところから来ています。また、エンティティ数が多ければ、必ずしも良いモデルであるとは限りませんし）
    • このエンティティ数の制約条件というのは案外、モデルを作成する上では面白い条件となっており、限られた数で対象課題内容を表現しようとすると、いわゆる「抽象化」という、同様の概念を整理して要領よくエンティティ表現するという考え方が必要になってきます。それによりモデル対象世界をうまく表すにはどのように要約し捉えれば良いかということを熟考するという訓練にもなるといえるでしょう。この辺りは自分で頭と手を動かしてみることで良く分かります。そいういう意味で、試しに応募してみることを想定してモデル作りにトライしてみることをお勧めします。Web利用向けプログラム作り主体の方々には、案外このデータモデル指向という見方が余り重視されていないことも少なくないというのが経験から来た筆者の見方でもあります。
    • それともう一つ大切だと思うのが、データモデル上でエンティティや属性の定義、および必要とされているモデル上のコード体系をきちんと押えて、それをモデルの中でメタデータ表現するということです。ER図が単純に書けていれば良いというだけでなく、そこで表現されているキーや属性項目、利用コード概念をきちんとモデルの中に書き加えておくということです。この表記があるからこそ、モデル作成者以外の第3者も図で表されているモデル観がより正確に伝わって行くということになります。表現が正しく伝わらない限り、設計者とレビューア、プログラム作成者、QA担当者、利用者に情報が正しく伝えられる保証が得られないということになります。これが最終的には、成果物の正確性・信頼性、再利用性、将来の生産性といったあらゆる場面に影響を与えることになるといえます。第3者だけでなく、過去の自分は現在あるいは未来の自分とは異なるという視点からいえば、自分のためでもあるという点が重要です。
    • このような内容を意識しながら、是非このコンテストにチャレンジしてみて下さい。（勿論、筆者も連覇を目指して、応募する予定でいます!!）
      　　　（先頭に戻る）
    • その50：　DMBOK 第2版におけるデータモデリングの位置付けの再確認
    • 少々時間が経ちましたが、前回前振りした10月のJEMUG（日本エンタープライズ・データマネジメントグループ）の勉強会で話題にした、DMBOK　第2版の特に第5章のエッセンスについて概要を紹介したいと思います。第５章は、「データモデリングとデザイン」と題され、データモデリングの概念と位置付けの基本などを中心に整理したものです。特に筆者が今回着目したのは、その中でもデータモデリングスキーマと物理的な実装環境との関係を示す部分でした。
    • ここ数年のIT開発と実装環境は、それ以前と比較して技術的および実装環境という点で大きく変わったということができます。特にいわゆるクラウド環境の現実的な台頭による利用者意識の変化と、それを背景としたアプリケーション開発上の技術的進歩および開発者意識の変化といったことが上げられるでしょう。こういった変化の中でもシステム作りの本来の中核となる「データ」をしっかりと捉えておくことは益々重要な要素であるべきだと筆者は考えています。そのための手段として必要なのが、これまでのメッセージでも取上げてきたようにデータモデリングという考え方です。但しここで必要なのは、従来のようにリレーショナルデータベース主体の物理データベース（DB)とそのためのERスキーマという固定された考え方から、様々なデータベース種類に応じて利用するスキーマの考え方も多様性が生まれるという点です。
    • この辺りの一つの考え方を整理しようという試みが、冒頭に掲げたデータモデリングスキーマの種類と物理DB実装の部分といえます。ここではスキーマの利用階層は、「概念」「論理」「物理」という３つの階層で整理されています。そしてその各階層への適用のスキーマの形が、ターゲットとする物理DBによって組合せが異なるという考え方です。この詳細はDMBOK　第2版を直接参照頂くのが良いと思いますが、ポイントとしてはビジネス的に取り扱うデータの本質（在り方）を捉えるのが概念と論理データモデルの部分であり、これは共通デザインとして捉え、そうした上で多岐に渉り変化に富んだ実装形式となる物理モデルの部分が、それぞれの特性に応じたスキーマ形態を利用するという具合に捉えることができます。これはある意味まっとうな考え方で、それを再確認することできるという点で、大切な視点を提供しているということができるものと考えられます。
    • また、データマネジメントおよびモデリングの成熟度診断と管理という点をスコアカードという形で紹介している部分が、もう一つの着目点であると考えています。CMMIを始めとして成熟度の視点により、現状とあるべき姿を考えビジネス環境を改善の方向に導くというのは基本的な方法論ということができますが、これをデータモデリングにも導入し、概念的な評価レベルではなく、幾つかの具体的な判定項目によって整理しようとした点に着目しておきたいものです。ここの部分は、第5章の中心的な執筆者であるHobermanの考え方が色濃く出ているということができます。
    • 筆者は、現在Dama Japanという非営利団体組織のデータ管理成熟度を考えるという分科会に参加していますので、そちらの話題に関しても、今後この欄で紹介してゆきたいと考えています。ご期待下さい。 　　（先頭に戻る）
    • その49：　AI或いは機械学習（Machine Learning）によって、どのような職業が影響を受けるだろうか？
    • 前回紹介した10月19日開催のJEMUGの勉強会の概要と、その先にあるデータマネジメント領域に関する今後への期待の様子については、近いうちにご報告したいと思います。今回は、この台風の中で受講した「機械学習入門」の中で話題となった「AI/機械学習（Machine Learning）技術の台頭により、どのような職業が影響を受けるだろうか」という議論点を考えることにします。尚、ここでの機械学習は所謂ディープラーニングの領域を想定し、決定木などの学習アルゴリズム適用以上のものを指すことにします。ディープラーニングの仕組み（ニューラルネット）は、他の機械学習の仕組みとは大きく異なるとも言えますが、ここではその点に深くは立ち入りません。
    • この話題は様々なWeb上の記事で話題にされていますが、元々は、“The future of employment: How susceptible are jobs to computerisation ?”(Frey and Osborne, Oxford Univ.(Sep.,2013)) 、機械学習(ML)とモバイル・ロボティクス(MR)技術の発展を対象に考察を行ったこの論文が「AIの発達で雇用がなくなる」という日本での話題の一端となっていることが理解できます。この論文の内容については紙面の関係上、ここでは触れません。pdf形式でダウンロードできますので興味のある方は、それを参照下さい。702の職種についてモデル評価を行いスコア化が行われています。
    • 従来のいわゆるコンピュータ導入による社会への影響の大きさは、定型的でルーチン集約的な業務、つまりうまく手順を定義できアルゴリズム化が可能な領域が主体だったということができます。一方、人的サービスで高度の対人的柔軟性や物理的適応性が必要な業務は、コンピュータ化の影響を受けにくいとされてきました。この定型的～柔軟性という対向軸での影響業務分類が、AI/ML技術の発展により、どのように面或いは立体的な分類軸で広がりができるかということが検討の一つの焦点でしょう。特に影響の大きな技術領域として、センサリングによる対象認識技術（画像処理・音声認識を含む）、センサにより生み出された大量の末端時系列的な状況データを受け入れ適時に処理する技術、画一的で事前定型的処理から周辺条件や環境を元に新たなアクションを生み出すことを期待されるAI/ML技術といった内容が上げられます。つまり、(1)周辺状況の認知・取得（入力）、(2)処理判定（柔軟性を備えた対応処理）、(3)アクション（出力）、(4)行動の結果をフィードバックし次の行動の改善につなげる（帰還と出力変換）という一連の連続的流れが満たされることで、技術利用による現実社会への影響が大きくなると考えられます。
    • 現時点で捉えると、入力および対応処理技術には大きな進展が見られるといって良いと思われます。一方、アクションとフィードバック部分に関してAI/ML技術がどの程度実用的であるかという点が検討課題といるでしょう。ルールの決まったゲーム性の高い領域（チェス・将棋・囲碁など）では既にAI/MLの処理能力が十分に適用できることが示されています。また音声利用の対話を通じた状況対応実験というレベルでは、呼び掛けに対して何らかの応答が返されることができていますが、意味を踏まえた十分な対話実現の形式には至っていないというのが実情でしょう。これらはゲーム感覚や遊びの領域では面白がられても、切実な現実環境での実用にはまだ時間が必要という状況といえます。一方で問いかけ（検索要求など）に応じた何らかの情報抽出・提示といったレベルでの利用には役立ちます。しかし、一刻を争う場面で、機械を相手に要領を得ないやり取りを延々とさせられることがあれば、相手（人間）は怒り出す結果を生むでしょう。まして安全性に影響がある場合には、まだまだ力不足と考えられます。
    • このように見ると、現時点で社会生活面、特にクリティカルな場面でAI/MLを本格活用するには、かなりの距離がある段階と考えられます。一方、大量のデータを限られた時間で処理し、論理を交えて分類・判定するための道具としての実用度は期待できると考えられます。そのような場合でも、感情的な面も踏まえて最終的にどのようなアクションに繋げるかの介在をして最終決定を下すのは人間の役割でなければならないことはいうまでもありません。全てをAI任せにすることは、寧ろ危険ともいえます。
    • 現実的には、目先の利益に直結する事例を期待し、新技術導入の積極的展開を嫌い、文化・心理的側面、既得権者の反発（時間軸での影響）の想定される国内の利用環境を考慮すると、AI/MLの利用は表面に出にくいところから、起こると考えられます。勿論一部の研究領域では、先進的な応用例が生まれる可能性はあります。そのような実験レベルの一部が成功事例として声高にマスコミを通じて紹介されることも想定できます。しかし実用例という観点から考えれば、製造や管理現場での工程や品質改善領域、ヘルプデスク等でのトランザクション仕訳け、各種交通案内・状況予測、エンタテイメント領域といったところを当面着目したいと考えます。勿論大資本企業による大掛かりな実験報告も目にするかもしれません。
      　　　（先頭に戻る）
    • その48：　ビジネス実務者視点とIT担当者視点から見た要件ギャップに関するレビュー
    • これまでデータモデルの作成や活用について、主にビジネス側から捉えたモデルの考え方の大切さを考えてきましたが、今回は改めてIT担当者からみたモデルの位置付けを考察し、そこから生まれる認識ギャップを見直すことにします。
    • ビジネス実務者から捉えるシステムへの要件整理の流れを「トップダウン」視点、これに対して仮想的に実現したシステムとその運営を司るIT担当者から見える実現要件としての捉え方を「ボトムアップ」視点として表すことにします。ビジネス実務者から生まれるシステムへの期待要件は、担当者の係わる業務範囲（サブジェクトエリア）での整合性を元に提示されることになります。このサブジェクトエリアに関係する範囲でデータモデルを描く、という流れがトップダウンの基本になります。このトップダウン要件をベースにして、広義のコンピュータシステムで仮想化を実現する訳です（ここで「広義」としたのは、一つのシステムだけで構築するということでは必ずしもなく、ネットワークで接続された複数のシステム、或いはクラウド上の既存アプリを活用する場合もあるという意味です）。
    • 一方で、システムの新規構築実施、或いは既存のシステム環境を運営するIT実務担当者が見ているデータ（またはデータベース）というのは、「先に示した業務範囲のデータモデルよりも広いものになることに注意する必要がある」ことを再認識したいです。これは、システムによる仮想化を実現するためには少なくともシステム内（或いはサブシステム間）のデータ項目やプロセスを管理するためのメタ情報（上位概念の管理情報）が必須であり、こう考えただけでも、トップダウン視点から生まれたデータモデルの範囲よりもボトムアップ視点でカバーするデータモデルのカバー範囲の方が広いことが理解できます。実際にはこのメタ情報以外にも、ビジネス要件を越えた様々なデータがあり、カバー範囲のギャップが広がります。これがITの担当者が必要な理由の一つだということが分かります。この認識を経営者はしっかりと持っている必要がある、というのが今回の趣旨です（ここでは簡単のためにデータモデルの範囲で考えます）。
    • 「トップダウンとボトムアップ視点から生まれるデータモデルとの間にギャップがある」ことを認識した上で、これが費用に与える影響について簡単に触れることにします。トップダウン要件（新規・更改）からの変更要求は、その関係するサブジェクトモデルの範囲に影響が出ます。しかし、ボトムアップ側のモデル（物理モデルという言い方もある）から見るとその変更から生まれる影響範囲は、一般的には「より広い」ものになります。その広さの大小が、変更要件費用へと直接繋がることになります。つまり、このギャップの大きさをどれだけ短期間に明示できるかという不断の努力が「変更費用」に影響を与える。更に、このギャップの大きさが費用に与える影響は正比例ではなく、幾何級数的に大きくなるはずである（この辺りは文章だけで理解頂くのは難しいかもしれません）。従って、データモデルに対する継続的な整合性維持のための「データマネジメントとそのためのガバナンス構築」が必要であるという意味付けが、ここから生まれることが分かります。この点をしっかりと認識し活動できるかどうかというのがシステム視点から経営者に求められる鍵と言えます。システム投資費用の判断にも大きな影響が出ます。
    • 整理すると、(1)トップダウン要件とボトムアップ（対応）データ要件との間には、必然的なギャップが存在する。(2)システム変更に必要となる費用はそのギャップの大きさに依存する。(3)この影響度はギャップの大きさの幾何級数的な比例度で表される（正比例ではない。(4)従って、日常的な課題として前記のギャップが広がり過ぎないための対応を行うことが経営者視点として大切である。これがデータマネジメントのためのガバナンスへの必要性を費用面から考える議論の流れです。これまでは費用の観点から議論しましたが、要件変更対応完了までに要する「必要時間」から見ても同様なことが言えます。
    • 尚、今回のメッセージに関連する話題を、JEMUGの勉強会として、10月19日（木）午後に開催予定となっています。会場など興味ある方は別途「お問合せページ」により確認下さい。（その時の様子は、後日のこの欄で紹介予定です） 　　　（先頭に戻る）
    • その47：　分析における統計の役割と利用の一大変革およびササヤカナ疑問（２）
    • 前回に引き続き、ビッグデータ時代におけるベイズ統計台頭の兆しと、その事例として取り扱われる例題への疑問について紹介します。
    • 「その46」で紹介した3囚人問題では、「『囚人Aが恩赦される確率は1/2である』と回答する人が圧倒的に多いことが知られている」と記したが、これを「直観解」と呼ぶことにする（前記、豊田教授説明による）。一方でこの問題をベイズの定理を使って考察すると、（詳細については省くが）囚人Aが恩赦される確率は、1/3のままで変化せず、一方で囚人Cが恩赦される確率が1/3から2/3に増えて2倍になる。ここでこの囚人Aが恩赦される確率1/3を「模範解」と呼ぶ（同様）。ベイズの定理は、客観的なデータに基づく尤度によって、事前分布が修正されるというメカニズムを表現しており、外界の客観的事実によって、人の確率的信念が変化していくメカニズムを模している。
    • この多くの人が当初奇妙に感じる「模範解（1/3）」の問題について豊田教授は以下のように説明している。事前信念である1/3（A、B、Cの３者共に恩赦されると期待される確率）は、主観確率ではあるけれども問題文にも記載され、回答者に自然に意識される、正論の正当な出発点である。ところが客観的データに基づくべき尤度のパート（＝「Aが恩赦されるときに、看守が囚人Bを処刑者と指摘する確率」）の確率評価をも、３囚人問題では主観的に評価しなくてはならず、ここが3囚人問題の奇妙さの源泉である。主観に主観を重ねる推論が、データという事実によって確率的信念を変化させる人の自然な推論メカニズムに反しているからであって、この主観確率に主観確率を掛ける方法は、ベイズの定理によるデータ解析法として「禁忌」であり、けっして真似をしてはいけない。
    • そして、この直観解と模範解とのずれを説明する具体的方法として、確率的に議論する上で、数学的により緩やかな無情報的事前分布を仮定し、確率の定義域の区間［０、１］の一様分布を上記尤度のパートに適用し、100万個の一様乱数発生により確率密度関数の近似を与え、「乱数による「囚人Aが恩赦される確率」の事後分布を図示する。ここではその図は省略するが、結果として0～0.5の母数θ区間で、平均値：約0.30678、中央値：1/3、最頻値：1/2を得る。つまり、「模範解」1/3は事後分布の中央値であり、それも正解の１つであるが、一方事後分布の最頻値はMAP推定値と呼ばれ、ベイズ統計学の正当な推定値の１つであり今回の3囚人問題の正解の１つとして「直観解」1/2が許容される。この直観に合わないと思われる説明こそが問題の持つ奇妙さの元であった、という点を分かり易く説明している。ここまで説明されると初めて元の問題を通じた課題提起が理解でき、とても良い説明をされていると感じた。この問題について、筆者の経験的に、ここまで丁寧な説明をする解説者はまれである。問題に対し、ただ正解が1/3とだけ説明して、「何故1/2ではないのか？」という説明に答えられる人は多くはないのであった。
    • ここまで書いておいて、筆者の持つこの問題へのささやかな疑問についても触れておきたい。それは、囚人Bが処刑されるという情報を得た上で、囚人Aが恩赦される確率は1/3のままで変化しない（模範解）点は納得の範囲に入れることができたとしても、何故「囚人Cの恩赦される確率だけが1/3から2/3に増える」ことになってしまうのかという点である。この点の納得性が生まれないのである。恐らくそれは、問題文の説明（仮定）の解釈が読者に曖昧性を生むからではないかと筆者には思われる。筆者の推論過程では、囚人Aが恩赦されるときには、囚人Bかつ囚人Cは「双方共に」処刑者になると理解される。つまりこの、囚人Bが処刑者とされる確率も、囚人Cが処刑される確率も共に、確率は100%（＝1）と推論するのである。ところがここをベイズの定理を適用した計算過程では、1/2として処理しようとしている（つまり合計が１となる）。この論理部分が囚人Cの恩赦される確率が2/3に増えるという結果を生んでいると考えられるのである。
    • 上記のような疑問が残るものの、ビッグデータ分析と統計解析のもつ、今後の潮流におけるベイズ統計の役割増大に期待し、継続してこの方法論を研究したいと考えるこの頃である。（今回の参考文献として以下を参考に致しました。「新訂　心理統計法」　2017年3月、第１刷、豊田秀樹著、放送大学教育振興会発行） 　　　（先頭に戻る）
    その46：　分析における統計の役割と利用の一大変革およびササヤカナ疑問（１）
  • 今回は、ビッグデータ時代の統計パワー利用の大きな変化について記述します（今回の内容は、実践的な統計利用で著書が多く、活躍されている豊田秀樹先生（現早稲田大学教授）の講義解説を元にしたものです）。
  • データの分析・活用に当たって、基本的な記述統計の利用に加えて統計の力を使ったデータの利用という点が注目されていることは間違いないが、その統計の世界に大きな変革が起きてきているらしい。それは「ベイズの定理（ベイズの公式）」の出現である。出現というよりは、正確には再発見／見直しという方が正しい。少し進んだ統計によるデータ利用では、1925年のフィッシャー（R.A.Fischer）論文発表以来、統計的優位性検定の利用が当たり前のこととされてきていた。しかし、その世界がベイズ統計の再評価により常識が大きく変化しつつある。元来ベイズ統計は、1940年代に提示されていたものだが、コンピュータ計算の出現により本領が発揮されるようになったという訳である。ビッグデータ解析においては、元々優位性検定の考え方が存在しないと言っても良いのである。
  • 多くの１次データは事実を表現する客観データとして収集され、データの分布として表現し分析される。それはデータ生成分布という理論分布の視点が利用される。その際には収集したデータが多くの場合、正規分布に従うものとして取り扱われる。標本平均（μ）と標本標準偏差（σ）を得て、それを正規分布の母平均と母標準偏差と看做して、その優位性をある信頼範囲（通常、5%や1%が利用される）で評価し、仮説の信頼性を論ずるという具合である。しかし、そこには大きな不都合を抱えているとも言える。それは、母数を点として考えてしまって良いものだろうかということであった。つまり、あるデータ値aを得たときに、それはN（μ1、σ1）に信頼性95%で評価され得るとしても、本当はN（μ2、σ2）の分布のデータ集合であっても観察されるし、或いはN（μ2、σ2）でも出てくることもある。でもN（μ3、σ3）の分布では出現しにくいかもしれないということで、実際の世界では、多くの可能性、つまり母数そのものが分布しているのであり、それを１つの点で母数を仮定してしまって良いのだろうかという疑問が起きてくるということになる。
  • これに対して、「データという情報が与えられた後に、母数の条件付き分布を導く」という考え方を用いているのがベイズの定理である。統計的推論の多くを「母数の分布」を通じて行うという、これまでとは逆の発想といえる。データが与えられた後（観察された後）の母数の条件付分布を事後（確率）分布として推定の材料とする。データを固定したものとして母数を動かし、尤度（ゆうど）が最大になる値を探す。こうして見つかった尤度を最大にする母数の値が「その値の下で、観察されたデータが確率的に最も観察されやすい」ということである。その時の値を母数の推定値として利用することになる。この考え方の詳しい解説は、豊田秀樹教授の著書を参考にして頂きたい。ここではデータ分析変革という点に絞る。実は、この話題に関連して「３囚人問題」というものがある。著者が初めてこの話題を聞いた時に、意味が良く理解できなかった。豊田先生の説明を知り、少し分かった気になったという訳である。少し長くなるが、読者の便を考えて、その問題を以下に記述してみる。
  • 【３囚人問題】　ある監獄で、罪状はいずれも似たりよったりである3人の死刑囚A、B、Cがそれぞれ独房に入れられている。3人まとめて処刑される予定であったが、1人が恩赦になって釈放され、残り2人が処刑されることとなった。だれが恩赦になるか知っている看守に「私は助かるのか」と囚人が聞いても看守は答えない。そこで、Aは「BとCのうち少なくとも1人処刑されるのは確実なのだから、2人の中で処刑される1人の名前を教えてくれても私についての情報を与えることにはならないだろう。1人を教えてくれないか」と頼んだ。看守はAの言い分に納得して、「囚人Bが処刑される」と答えた。それを聞いたAは、「これで自分の助かる確率は1/3から1/2に増えた」と喜んだ。実際には、この答えを聞いたあと、Aの釈放される確率はいくらになるか。
  • この問題を読んだ読者は、果たしてどのように考えるであろうか？この問題は「囚人Aが恩赦される確率は1/2である」と回答する人が圧倒的に多いことが知られている。そして一方で、ベイズの定理の適用例として出てくる解説では、確率1/3と説明されるのである。皆さんは一体この説明に満足されるであろうか？筆者の疑問は続いた。スペースの関係で今回はここまでとするが、その疑問内容と結果について次回に説明したい。
    　　（先頭に戻る）
    • その45：　DAMA DMBOK 第2版の全体構成概要について
    • 前回、DAMA　DMBOK第２版の位置付けについて少し説明しました。今回は、第１版との違いを交えながら、概要構成を確認します。
    • DMBOK　第２版は、全体構成17章から成ります。第１章は、DAMAの考える、ビジネスにおいてデータを資産として捉えた場合のデータマネジメントの果たす役割と重要性について改めて整理したものとなっています。そして３章以下で説明するデータマネジメントの構成要素をフレームワークとして取上げ、各章の進め方を解説する。フレームワークの要素はコンテキストダイアグラムとして纏めています。第２章はデータ取扱いに当たっての取扱いに関する心構え（Data Handling Ethics）。個人情報の取扱いや企業としての取組みについての姿勢を考え、データガバナンスとの関連について触れています。
    • 第３章から第１３章までが、データマネジメントを構成する１１の要素をそれぞれ一つの章を使いながら必要知識として説明します。その要素とは、以下の１１となり、列挙しておきます。第３章「データガバナンス（Data Governance）」、第４章「データアーキテクチャ（Data Architecture）」、第５章「データモデリングと設計（Data Modeling and Design）」、第６章「データストレージと操作（Data Storage and Operation）」、第７章「データセキュリティ（Data Security）」、第８章「データ統合と相互運用性（Data Integration and Interoperability）」、第９章「文書およびコンテンツマネジメント（Document and Content Management）」、第１０章「リファレンスおよびマスターデータ（Reference and Master Data）」、第１１章「（データウェアハウジングとビジネスインテリジェンス（Data Warehousing and Business Intelligence）」、第１２章「メタデータマネジメント（Metadata Management）」、第１３章「データ品質（Data Quality）」。第８章の「データ統合と相互運用性」は第２版で追加された項目です。また、第５章の「データモデリングと設計」は第１版では「データ開発（Data Development）」となっていたものが、よりデータを資産としてデータモデル管理面を強調するものとして変更されています。更に第６章「データストレージと操作」は第１版では「データベースオペレーション管理（Database Operations Management）」となっていたものが、データベースに限らずいわゆるビッグデータ環境を支えるストレージの管理として拡大説明する形で変更されています。
    • そして、第１４章では「ビッグデータとデータサイエンス（Big Data and Data Science）」を新しく取上げ、近年のデータ活用の領域の広がりを捉えています。そしてこの要素がデータマネジメントのフレームワーク要素と密接に繋がっていることが説明されます。第１５章は「データマネジメント成熟度アセスメント（Data Management Maturity Assessment）」を取上げ、段階的にデータマネジメント環境を向上させるための評価視点を取上げます。次に、第１６章「データマネジメント組織とロール期待事項（Data Management Organization and Role Expectations）」では、データマネジメントを確実に組織に根付かせるための組織構成や、その中で活動する人材の役割などを概説します。最後に、第１７章「データマネジメントと組織的変更管理（Data Management and Organizational Change Management）」では、継続的にデータマネジメントを遂行する上で必要となるデータ仕様変更などの重要な変更管理プロセスの在り方や、組織的コミニュケーションなどに触れたものとなっている。
    • 以上のように、DMBOK　第２版は、企業が資産としてのデータをライフサイクル視点を踏まえて、組織的に成功裏に管理し、活用を進めるために必要となる全体像を概観したものとなっています。個別技術の具体的な詳細内容やツール、アプリケーションなどにつていは、各技術を説明する別途の資料を参照し読み込む必要がありますが、企業のマネジメント層が本来知っておくべき「データマネジメント」というものを改めて認知するという上で、一度は目を通し概要理解をする、その上で自社および関連企業との連携を進めることができるように取組んで行く必須の内容であると、筆者は考えています。
    • 今回は、データマネジメントの全体像を捉える上での知識体系DMBOK構成を概説しました。尚、日本語版の出版はまだ未定であるとのことです。また筆者は、１０月に開催予定のJEMUG（日本エンタープライズ・データモデリング・ユーザーズグループ）の勉強会で第５章の内容を中心に、具体的内容などを説明しメンバと議論を進める予定にしています。この内容に興味のある方は、筆者宛（お問合せページから（またはJEMUGで検索して、ユーザー会のゲストページから）照会頂ければと思います。 　　　（先頭に戻る）
    •  
    • その44：　データマネジメント知識体系、第２版（DAMA DMBOK 2nd. Edition）の発行について
    • 今回は、データマネジメントへの組織的な取組みを支援する団体の動向の話題を取上げます。
    • 米国DAMA Internationalの発行するDMBOK（Data Management Body Of Knowledge）の第２版が、過日ようやく発行されました。第１版が発行されたのは2009年ですから、8年振りの改訂となります。筆者はDAMAが米国で主催する（現）Enterprise Data Worldに４回程出席し、米国を中心とした企業レベルでのデータマネジメントへの積極的な取組みに関心させられたものでした。その８年前と比較すると、企業のITシステム利用環境は大きく変わってきており、今回の第２版発行において、それらの環境変化がどのように取り扱われているかという点に、筆者としては第一の焦点がありました。
    • データマネジメント知識体系としてのフレームワークには大きな変化はありませんが、個々の要素項目の内容は大きく書き換えられています。更に、データマネジメント組織（運営や関与する人々の役割など）、データ利活用への専門家としての取組み倫理、ビッグデータとデータサイエンスの話題、成熟度アセスメントといった点が追加されています。英文600ページを越える大部の資料であり、細かい内容の把握はこれからという状態ですが、ここ数年の環境変化を踏まえたデータマネジメントへの取組みの在り方がどのように知識として反映されているかを確認することが、筆者としての楽しみでもあります。そこから得られる知識内容については、このコラムで適宜お伝えできればと考えています。（関心のある方は、ご期待下さい）
    • 今後の内容の話題に入る前に、こういったデータマネジメント知識体系というのは誰のためのものなのか、という点について少し考えておきたいと思います。第一に上げられるのは、IT環境への投資を積極的に行おうとする経営者です。今後ITシステムとそこから生まれるデータを活用することを企業戦略として考える人たちにとっては、このような知識体系をある意味常識として捉えておくことが大切です。IT導入を業務アプリ利用目的で行ったという方々に取っては「ITシステムは動いていれば良い」と考えることもあるでしょうが、その次の段階を検討する目先の利く経営者にとって必須の知識体系となるでしょう。全ての内容を細かく知るところまでは必要ないとはいえ、技術者との間の戦略的視点での会話を成りたたせるためには重要な考え方といえる点がポイントとなります。
    • 第二には、ITCを戦略的・戦術的に活用支援する技術マネージャが上げられます。日々のITC技術領域の変化にだけ惑わされることなく、自社の目的にとって、今そして将来的に必要となる環境がどのようなものか、そしてその基盤構築・運営に関して核となる「データマネジメント」のあり方をどうするのか、という点を思索するためのイメージ作りに大切な視点が掲載されていると考えれば分かり易いといえます。ここにあるような視点を持たずに、場当たり的なITCの導入・運営を続けていく組織は、いずれ大きな壁に突き当たることになるでしょう。そこではITCシステム関係への費用の過半が単なるシステム維持のためだけに費やされているという状態で、人的資源も日常業務に埋もれてしまいかねないことになる恐れがあります。ITCシステム作りを行おうとする比較的若いシステム要員にとっても、将来的なキャリア方向性を考える良い材料となります。従ってマネージャがこういった知識を常識として備えることを推奨する共通話題として提供できる訳です。そういった利用方法もある。
    • 第三には、今やもて囃される方向にあるといって良い「データサイエンティスト」と言われる人たちも対象です。自分たちが生み出すデータおよび情報のための基礎となる元データの源流がどういったもので、どのように生み出されているか、などのデータ品質、データライフサイクルといった点などが特にポイントになるでしょう。また、使いやすいデータ利用環境作りのための、メタデータ管理、マスタデータ管理といった話題などは環境要件検討という意味で、大切な知識領域となるはずです。データセキュリティ、活用指針なども重要視点であることは言うまでもありません。
    • データマネジメントは多様な領域が対象となり、最初から完璧な環境作りをするという訳には行きませんが、カバーする領域の範囲を理解した上で、自分たちの立ち位置を整理し、次に向うべき方向とそのステップを検討するという点で成熟度を考えて行くことが大切です。「こういったデータマネジメントへの取組みを大切にしたいと考えている人たち」への積極的なお手伝いができればと、筆者は考えています。 　　（先頭に戻る）
    •  
    • その43：　データの活用（データと手法）の話題について
    • 今回は、データ利活用に関連する最近の動向を考えることにします。
    • ここのところ「オープンデータ」といわれる形でのデータ開示や、統計への導きおよびAI（機械学習）といった分野で、いわゆるベンダー主導での情報提供以外の内容が増えてきています。そこにはGaccoなどのMOOC形式の（無料での）オンライン学習講座などでの学習機会増大といったことが含まれます。この学習機会増大は、データのビジネスや社会的利用という視点で大変喜ばしい方向であると思います。これからは学習内容の質の向上や、積極的学習者の増加と応用例の可能な範囲での公開といったことが、社会的に要求されてくるというところでしょうか。
    • 情報のボリュームが拡大し、その利用者が増えるに従い、その次には提供されるデータの質への要請や利便性管理などの期待へ、人々の目が向けられてくることは必然的な流れであると思います。単なるインターネット上の情報検索環境提供から、情報管理プラットフォーム環境提供の巨人となったGoogle社の成功の流れもこのような期待に沿い、環境構築を行ってきた結果ともいえるでしょう。但し、提供する情報の正確性や質に関しては実際の所の課題は少なくないと筆者は感じています。特に、利用者（単に「検索者」ということでなく、そのビジネス的利用者（スポンサーやアフィリエィト参加者など））の増大に従い、結果として出力される情報の客観的期待と比較した正確性は、反って降下しているのではないかと感じます。また、一部には情報開示に制約が課せられるという方向が生まれる可能性もあります。
    • こういった流れはさておき、情報の質と利用の利便性を考慮した「データマネジメント」という領域の重要性は、今後ますます深まるものと考えられます。正確な背景情報（＝メタデータ）に基づく「データの活用」こそが重要であるといえるからです。単に見た目での綺麗さや新奇さだけでは、到底社会的に役立つ情報利用環境が生まれるとはいえません。また、データの利用者についても、利用者層の拡大に伴い様々な利用者インタフェースの柔軟性提供が求められます。これは単に提供されるアプリケーションソフトウェアの数が多ければ良いというものではありません。アプリの存在を知らせると共に、利用者の知識や経験に応じた利用方法が提供されることが望ましいという方向性です。また技術面での変革や社会習慣・常識の移り変わりへの対応という課題もあります。
    • 繰り返しになるようですが、今後はオープンデータ増大に伴い、その量と質への対応を可能とする「データマネジメント」手法が注目を集めることになるでしょう。ここでは考えるべき「アーキテクチャ発想」ということが含まれます。これはトータル利用コストを下げるためにも経営的優先度上、必要なことであるということができます。次回以降、そういった話題への考え方を提示できればと、筆者は考えています。 　　（先頭に戻る）
    • その42：　アプリケーション利用者インタフェース考
    • 前回は５月の「JEMUG定例ミーティング」プレゼン実施内容を元にＡＰＩについての話題を取上げましたが、今回は最近特に気になっているアプリケーション利用者インタフェースの課題を取上げます。
    • 現在、一般の方々を含めて最も多く利用されている情報機器はスマートフォンおよびタブレットタイプのものであることは疑いありません。特に世代が若くなるほどスマートフォンの利用度が高まっているといえます。従って、企業がビジネス目的で一般の消費者や様々な世代向けの情報提供手段としてスマートフォンをターゲットとすることが避けられない状況です。そしてそのような利用者向けにいわゆる利用者インタフェースがスマートフォン上のアプリケーション向けに提供され、これが利用者の使用感・利用満足度に直接的に影響することになります。因みに前回話題にしたＡＰＩは、データをやり取りするための手段などに使用されており、今回のアプリケーション利用者インタフェースとはやや位置付けの違いがあると考えて下さい。
    • スマートフォン上のアプリケーションは特に提供機能を実現するために、共通のプログラムモジュール部品を活用する所に開発者にとってのメリットがあるといえます。特に基本機能部分に関しては、都度モジュールを開発するよりも効率性などの点で利点が高いといえるでしょう。しかし、著者が最近経験したスマートフォンでのアプリケーション（複数）を利用して疑問に思った点があったため、それを今回の話題としようと考えたのでした。異なった企業の提供するスマホアプリ上で同様の使い勝手の悪さが使われていたという点に課題を感じたということです。つまり開発者は、表面的な機能の提供（それを提供するインタフェース）で満足していて、利用者の使用感には考えが及んでいないのだろうという話。
    • そのインタフェースというのはこのようなものでした。アプリ利用者の識別を目的に、特に会員制のための利用者登録や識別に生年月日を利用することは（現在の所）少なくないケースだといえます。その生年月日入力にカレンダ形式を使用するのですが、そのカレンダを選択するのに、月単位で移動する手段しか提供されていないという形であったのです。つまり既定値として表示されている現在の年月から５年前の月に移動するのに、６０ページ（月）ほど移動しなければならない。もし１０年なら１２０ページということ。この不便さを開発者は気付いていないだろうと感じた訳です。直接、年および月を入力できるなら、このような不便感を利用者に与えずに済むはずと筆者は考えます。しかも、複数のアプリケーションで同じようなことが起きたということで問題と感じたのでした。共通の利用者アプリインタフェースの設計またはモジュールの選択で、こういった利用者の利用場面を考慮して選択実施して欲しいものです。是非、利用者のもつ時間を大切にする発想をして欲しい。
    • この生年月日入力ほどひどくはありませんが、例えば交通機関の乗換えアプリでも同様の不便を感じることがあります。例えば、時刻を入れるのに直接入力するインタフェースではなく、数字をスライドしなければならないなどは、この不便な例に該当する。直接数字が入れればこの不便さへのストレス感を低減できるはず。恐らく、キー入力に慣れていない人を想定したインタフェースであるとも感じられますが、そういった方法が誰にも便利とはいえない。こういった設計への考え方は、いわゆるビジネスインテリジェンス（ＢＩ）ソフトウェア利用においても存在します。そこではツールの利用初心者向けには、出来るだけ単純さ・分かりやすさを優先したインタフェース提供を行う。しかしツール利用に慣れてきた中級者以上向けには、ショートカットやキーコマンド、あるいは利用者個別のメニュー変更設定ができるようにするという考え方です。様々な利用者レベルが存在する環境においては、インタフェースとしての「One fits all」の考え方はしない方が良いということです。
    • 共通のモジュールを利用して機能を提供するアプリケーションにおいては、開発者には是非この考え方を胆に命じた設計方針を採って欲しいものです。表面的な機能が提供できればそれで良しとするのは、素人考えといっても言い過ぎではないと考えます。一つの利用者インタフェース選択が、アプリケーションの利用度選択に大きな影響を与え得ることを想定して欲しいものです。言い換えれば、アプリを使いたければ、そのインタフェースが如何に不便であっても、利用者は使わざるを得ないといった考え方は、厳しい言い方をすれば、如何にも提供者の傲慢さを象徴するといえるでしょう。
    • 今回は、筆者の最近の経験を元に、少々辛口のコメントの回となりました。 　　　（先頭に戻る）
    • その41：　データ活用とコンテキスト作りあれこれ
    • 今回は先日開催された「JEMUGの定例ミーティング」で行った表題のプレゼン内容を元に話題を投げ掛けることにします。
    • 表題の趣旨は、昨今のデータ利用の話題がクラウド的な意味的ブラックボックスを元にしたAPI（アプリケーション・プログラミング・インターフェース）によるコミニュケーションが主流になっていることへの疑問から生まれたものです。システムまたはアプリケーション提供者への盲目的な依存状態を続けることが、長期的な視点から見て利用者にとっては必ずしも利益にはならないという視点から投げ掛けた問題提起であるといえます。
    • 現在様々に話題として取上げられる二大領域と問われれば、「IoT」と「AI」のキーワードが出てくることは、システムに係わる人々にとっての共通認識であると思います。データ利用の視点から捉えた場合、前者は「データの出所の増大と多様化」であり、後者は「集積されたデータを解釈・利用するための技術領域」と見るのが妥当だと筆者は考えています。そして、冒頭に書いたAPIの話は、蓄積したデータ或いはその結果を利用するために提供される手段という位置付けと捉えることができるでしょう。IoTの視点からすると蓄えられるデータは、従来のシステムよりも遙かに粒度が細かく、流入頻度が高いものが多いということです。そしてそれを利用するには余りにも物理量が大きいため人手だけでは処理しきれない。それでAIの技術を利用するという関係になる。また多様なデータ利用インタフェースが氾濫しているためこれを何とかしたいという要望が高まるためです。
    • このAPIインタフェースは対応するクラウドアプリ提供者の数だけ存在し、それらの間には整合性が保証されていない。特定のアプリの管理する対象範囲（これを「意味ドメイン」と呼ぶことにする）でだけデータの意味の整合性が確保されている（と信じて）利用するというのが実態であろうと考えられます。そしてこの不便さを少しでも補おうとしてEAI連携のソフトウェアが生まれてきているといえます。因みに、その代表例として、Asteria Warp(インフォテリア社）、ｃDataソフトウェア社やマジックソフトウェア社の各種アダプター製品などがあります。
    • このような環境において必要とされるのが従来の「データマネジメント」であると共に、更に「ビジネスモデルマネジメント」の考え方であろうという点を指摘することを目的としたのが、筆者の今回のJEMUGプレゼンテーションでの要点でした。つまり、クラウド連携時代のデータ活用において要求されるデータモデルへの期待役割は、次のように変化している。そして、①記述厳密性から意味ドメイン横断的なコンテキスト整合性の重視へと向う、②RDB（リレーショナルデータベース）を意識した実装主体から、実装の多様性と混在環境を表現する必要性が増大する、③外部データやクラウドサービス（Web環境）連携の必要性が更に高くなるといった点です。
    • このためにはそれぞれ以下の見方が必要とされるといえます。(1)意味境界記述のドメイン世界として、物理モデル記述は概念整理の方向に近づき、物理構築は更に実装整理が要求される。(2)個別企業としての記述標準選択の必要性が高まり、これを規定整理することが重要である。(3)論理的な意味コンテキストを整理し、更にそういったコンテキストを付与する場面が増える。そして全体俯瞰的な高度視点からのアーキテクチャ指向性を確実に導入する必要がある。これらをデータモデル記述面での期待として捉えると、①データモデル対象の多様性の高まりに応じて、多層的・多次元的モデル表現を取入れる必要がある。そして、②ビッグデータやイベント事象発生表現を拡大するために、「インスタンスを捉える考え方・表現法を工夫」し、「個別的意味表現の利用可能性を高める」ことが求められるということです。
    • そのための方向性として、(1)多様なデータモデルを活用すること、(2)ビジネスモデルマネジメントへの期待内容、への取り掛かり要素を取上げたというのが、今回のプレゼン内容の全体像ということになります。これらについては、ここでは紙面の関係上省略します。内容に興味のある方は、筆者宛ご連絡を頂ければと思います。
    • 今回は、5月下旬に行ったJEMUGグループの勉強会での筆者のプレゼン話題を中心に記載しました。 　　（先頭に戻る）
    •  
    • その40：　「割り切り」を考えるということ
    • ある本を目にしながら、不意に有限と無限（∞）ということが疑問として浮かんできました。そのきっかけになったのが循環小数と数列の話でした。思えば有限と∞との距離は大変に遠い。存在の次元が全く異なる話題のようにも思われます。その行き着く先は果ての見えない大宇宙にも繋がる。今回は結論のない話題になる、という前振りをしておきます。
    • 例えば「１＋２＋３＋４＋・・・（無限界の整数の足し算）（Σｉ（n=1～∞））」と「１／２＋１／２＋・・・（１／２を無限界の足し算」は行き着く先が無いが、その表現される値（記号）は何れも「∞」です。しかし、その値の大きくなる程度は明らかに前者の方が大きいように（筆者には）感じられる。しかし、問題は何故そのように感じられるのであろうか？それが疑問となったのでした。大きくなる程度を想像するためには、そこに「時間経過」あるいは「シリアルな手続きの存在」という内容が同時にイメージされていなければならないと思ったのです。
    • そこで次に疑問に思ったのが、単純に「１＋２」と「１＋２＋３」の違いは何かという点。もし、この計算をコンピューターに教えようとすると、それはアルゴリズムという形で手続き的にプログラミングし答えを出すようにするだろうということ。そうすると結果（回答）を得るために、前者は１回の足し算、後者は２回の足し算を実行することになり、仮に同じ条件で実行すると回答が出るまでに時間的な違いがあると想像できます。それが計算量という考え方に繋がるわけです。消費するリソース量の違いという表現もできる。記述された式を素直にそのまま処理しようとすると冒頭に掲げた整数の足し算の回答は永久に得ることができずに終わらない。まるでアキレスと亀の競争のパラドックスのように。従って、割り切りを考える（何らかの条件を設定するか、近似で物事を捉えて納得する）ことが現実的であるということ。（これが今回の表題の元になっています。）
    • このように捉えると「四則演算」には初めから手続き的（時間経過的）な概念が含まれていることが分かります。言い換えると、「操作」を意識している。従って計算記述としては「１÷３＊３」と「３＊１÷３」とは同じモノではない、と考えることができますね。下手をすると前者は永久に答えを得ることができない可能性があるし、後者は瞬時に答えを得られる。一般の人間はその違いを認識すること無く同じ内容として感じてしまう（だろう）というのも不思議な話です。
    • つまり、AIと付き合うには何らかの割り切り概念が必須であろうし、AIの掃き出す結果には人間の感覚とは異なった出力が生まれる可能性があるだろうということも想像できます。その割り切り方は、人間が教えている可能性があるし、或いは限度の把握の仕方として何らかの条件設定を行っているということでもある。こういった意味で直観的に物事を捉えることには大きな意義があるといえます。人間の利用するヒューリスティックは時には錯覚（勘違い）も含まれるが、有限の計算量として大事でもある。そしてその結果に対して責任を取ることができるのも人間であるということかも知れません。
    • 今回は、取り留めのない、論理も時間空間をも大きく越えた話となりました。（因みに、最初に上げた本というのは「相事象学」という話題の本でした） 　　　（先頭に戻る）
    • その39：　クラウド利用に伴い増大するAPI（アプリケーション・プログラミング・インタフェース）指向
    • 前回のAI・機械学習利用編に続き、手軽に導入できるクラウドサービス増大に伴い、本来の経営者が考えるべき視点を思考します。
    • クラウドサービスの利用は、コンピュータ資源（物理的機器、利用アプリケーションなど）の様々なレイヤで進んできている状況です。得意領域を持つクラウドサービスベンダーが提供する業務アプリケーションの種類と、それに伴うデータの分散化も目立つようになってきています。そしてそれらを合体して利用したいという要求も増加してきています。更に「オープンデータ」の利用という見方がそれに拍車を加える状況です。
    • このクラウド上に分散したデータを繋げて新しいデータ活用局面に対応するために現在着目されているのが、APIインタフェースを通じたデータ（或いはメッセージ）連携とその管理のためのEAI（Enterprise Application Integration）技術というものです。これは言ってみれば、各クラウド上の業務アプリケーション処理の出力するデータをやり取りするための「接着剤」であるインタフェース・アダプタを利用して連携しようというものです。各クラウドサービスが提供するデータ形式は様々な形となるため、連携しようとするそれぞれのポイント毎にアダプタが必要となり、またそれぞれをうまく繋げるためのデータ/メッセージ変換が必要となります。企業内のデータを統合してデータ活用を行おうとしたデータウェアハウス・アーキテクチャの中で「ETL」と言っていた領域のクラウド版ということもできるでしょう。
    • これらの利用技術は個別実装に依存するため、実際に流通するデータの約束に応じたいわば抽象レベルの取扱いということになります。それはブラックボックス的に漠然とした期待の元に、ネットワーク上を流れてくるデータとして利用する形を生んでいるといえます。つまり実態を良く理解できないままに、何となくの期待感でデータ処理を行う可能性を高めているということです。足元がどうなっているかが理解できないままに、「何となくこうなっていて欲しい」という期待感だけで処理を行ってしまうというリスクが存在するということです。うまく物事が運んでいる（らしい）と思っている間はそれが問題とはならないかも知れませんが、話が大事になった時点で慌てても後の祭りという可能性を潜在させているという意味です。
    • このような意味で経営者が考えておいて欲しいことは、(1)全体観をもって自分たちが利用している技術がどのようなものであるかを、常に捉えておいて欲しい、(2)活用しようとしているデータの意味と出所を、論理的に整合性を持って管理しておいて欲しい、(3)背景となる環境（特にクラウド環境では）は常に変化しているため、状況を正しさをもって把握している責任者を備えて欲しい、という点です。気が付いたら「砂上の楼閣の上」でいつの間にかビジネスが進んでいたということにならないようにしたいものです。これらをうまく進めるために「論理データモデル」および「メタデータ（コンテキスト）管理」という考え方があるのです。 　　　（先頭に戻る）
    • その38：「AI技術導入による意思決定」での経営責任について
    • 今回は少し目線を代えて、昨今のAI導入盛んなこの時期に、今後現れてくるであろう大きなビジネス上の課題について考えます。
    • 昨年位から、技術優先的にAI（人口知能／機械学習）技術の導入・応用が声高に喧伝されるのがベンダー企業を中心に目立ってきています。これは当該技術が実用的に利用可能になってきつつあり、また大手ベンダーの参入から分かるように、将来拡大するであろうビジネスとして期待度が大変高い領域として看做されているということの現れであるといえます。このような中で、まだ余り注目されていない課題の一つを考えることにします。
    • その課題というのは「AI技術導入により実施されたビジネス上の判断」についての責任者は誰なのかという点です。実験研究的に技術が利用されている間は、余りこういった結果責任について問題となることはないと言えますが、技術導入がビジネスの中核領域に近づけば近づくほど、この視点が重要な意味を持つであろうというのが著者の論点です。技術導入に関する投資判断に関する責任は、経営者あるいは役員会といったところにあるのは基本です。それでは、いわゆる機械学習を通じて論理決定し、実行したビジネス判断についての結果責任を持つのは、誰なのでしょうか？
    • AI・機械学習技術というのは、実は論理的な明確性を付けにくいというところに特徴があります。数学的なロジック（例えば仮想的な空間上の変数距離）や、人間の神経細胞の活動をモデル化した方式などにより、行動判断における意思決定支援情報を作り出すのが現在の趨勢です。この流れからするとこのプロセスを通じてAIコンピュータから出力された結果を実際のビジネス活動における実践に用いるかどうかは、やはりそれを利用する側の（人の）意思決定を交える必要性があることが分かります。そうでなければ、AI計算機が出した結果なのだからそれを鵜呑みにしたということに成らざるを得ない状態が発生します。その場合、AI計算機が結果責任を取るのか。ビジネス上それはあり得ないでしょう。
    • 無尽蔵の経営資源を使うことができる場合を除いて、AI技術を利用したビジネス活動の経営責任を誰が取るかという点は、本格導入に入る以前から、企業経営の基本方針としてルール作りをしておく必要があるということです。これは所謂CIOと言われる立場の人間だけでは取り扱えない領域の課題であろうと筆者には思われます。その結果のビジネス的影響は、技術導入部門だけに止まらないからです。こういう視点からすると、当初から人間介在を意識しておく必要がある。こうしておかないと、経営者は（論理的に）訳の分からないままに結果だけを受け入れなければならない状況に陥る羽目になってしまいかねません。技術導入の意思決定作りと共に、その活用限界点をどこに置いて、利用変更点をどのように設けるか、定常的な経営者への報告体勢をどのように作っておくかということを、今から（経営者は）AI技術本格活用に備えて考えておくべきです。
    • ベンダーや技術者の宣伝だけを信じてしまうことは大きなリスクを伴う、というのがこの新しいAI技術導入においても経営者には求められるというのが、今回の結論です。ビジネスインパクトが大きければ大きいほど、この考え方が大切です。 　　　（先頭に戻る）
    • その37：「鳥の目」と「虫の体験」を支援する経営環境について
    • 今回は、先に書いた「鳥の目」と「虫の体験」の利用性を向上する環境について考えます。
    • 前回は「鳥の目」が管理者からの視点であり、「虫の体験」が個別的かつ現場的な取組みの視点であることを示しました。これは言ってみれば、管理的な視点というのは、全体の方向性を見て行くための最適性選択を支えることを意味するものといえます。そして前記に対して、現場的視点は一つ一つの事情に応じて、時には柔軟性を伴う行動を必要とする局面であると考えることができます。「管理と個別対応」このどちらを優先させるかといえば、保有している資源量と、その利用可能許容値に依存するといえるでしょう。
    • これを顧客対応といったビジネス直結の点から見ると、一人一人の顧客とそれぞれ個々の対応局面を重視する場合には、現場の行動を優先するという考え方になる。一方省資源を重視するという管理的な立場からすれば、画一的・マニュアル対応優先の考え方になるといえます。筆者の見方としては、過度の管理視点導入方針から進めると、それは所謂「お役所仕事」的な方向に偏る可能性が高くなり、固定化された柔軟性に欠ける現場対応を生む可能性を高めることになると見ています。望ましい方向としては、適度な管理をしながら、現場の柔軟な対応を許すというのが日本でのあるべき顧客対応の姿であるといえます。
    • 技術的な考え方を取り入れると、「鳥の目」は対象の全体像を捉える考え方を支援することであり、「虫の体験」は個別事情を理解するためのコンテキストを支える情報の収集・提供といえるでしょう。これらの期待を支えることを目的に、許容できる投資と時間軸の範囲でシステム発想を導入するというのが、当面の投資に関する望ましい経営者判断であるといえるのではないでしょうか。従って、これらの「最適性」判断というのは「経営哲学」に属する重点課題であるといえます。経営者の価値基準を抜きにしては、投資判断の方向性を測ることができないという基本に戻る。そこでは、技術はあくまで利用するための環境を提供することであり、どの技術を利用するかという選択肢は、当然ながら人の側にあるということです。
    • この見方からすると、やたらとセンサーデータだけを増大する方向でのIoT技術導入の傾向は、混乱を生む状況に繋がるものだと考えることができます。まず経営センスからの基本方針があってこそ「大きなデータ収集」が生きる。その際に、余りベンダーの大きな声に惑わされると遠回りをしたり、過度の投資といった結果につながるということが想定されます。勿論、先頭を走る企業としては、失敗するリスクを踏まえた余裕のあるR&D投資的考え方が役立つことも有り得るでしょう。そこは企業体力に依存する部分といえます。
    • 更には、一般的にありがちな「成功事例を求める考え方」に理解はできるものの、失敗事例が実際には役立つことも少なくないということでもあります。他社の動きに目移りするよりは、自社の土台を固めることが重要ということになります。こういったバランスをどのように置くかというのが、個別企業における経営戦略の要であるといえます。 　
    • 少し抽象的な話題が続きましたので、今後、ツールに目を移して具体的に考えることにします。 　　（先頭に戻る）
    • その36：　改めて、データ管理視点での「鳥の目（Bird's eyes view)と虫の体験（Insects' Experience)」
    • 前回は、データ活用環境という方向から「鳥の目と虫の体験」を述べてみました。この延長として、今回は同様のキーワードを「データ管理」の点で考えます。
    • データ管理での表題の視点というのは、如何に自分たちのビジネス環境に存在するデータを捉えて、継続的に有効なデータとしてマネジメントし続けることができるかという見方です。
    • まず「鳥の目」の視点からです。この視点とは、今自分が着目しているデータ領域（これはビジネスに係わるものばかりと限りませんが）に関する利用または保有データの全体像を捉えるという意味です。従って、ビジネス領域データとして考えると、そこに関係するデータの論理的な視野を整理するという見方が必要になります。このためのデータ表現は「論理的（人によっては『概念的』と表現することもある）」な見方で示すのが便利であるということができます。このために利用する技法が「論理データモデル」です。このためにER図を利用することができます。物理的な実装を行う前に、利用するデータのビジネス的な意味の整理、或いは利用データのコンテキストを押える段階ということもできます。論理的な設計者の見方です。この見方を約束として取り扱うデータの意図する意味論が制約されるという大事な考え方です。
    • この制約により規定されるデータの範囲を「ドメイン」と呼ぶならば、互いに異なったドメインを前提に設計されたデータというのは、同一条件で扱うことができず、必ずといって良いほどに相互ドメイン間のデータの意味の整合性を確認する手続きが必要とされます。計算機技術の発展当初はこの同一ドメインに属するデータの範囲（集合）を「データベース」と呼んでいたということができると考えています。つまり、データベース内データは同じコンテキストの中で取り扱うことができる「安全圏」といって良いでしょう。所謂「統合データウェアハウス」という考え方が必要になった理由は、この異なったドメインにあるデータを集めてきて、同じ制約に基づいて同じコンテキストで見ることができるようにしたいという欲求から出たものといえます。従って、複数のシステムから単純に一箇所にデータを集めてきただけでは「統合」という言葉は、本来の意味で使うべきではないというのが、筆者の意見です。
    • 次に「虫の体験」について説明しましょう。これは、個別のトランザクションデータ／情報に着目した「データの利用者」からの見方ということができると考えられます。そこでは、個別的な一纏まりのデータとして、手軽にデータを扱えるようにしたいという利用者欲求に応えることが重視されます。従って、ある事柄（場合によってはこれを「ファクト」とも呼ぶ）について、それに付随する属性的なデータを一緒に扱いたいという要望が起きます。更に、あるファクト１とファクト２について、その時間・空間的な関係性を知りたいということになります。場合によって対象データが「ファクト」つまり「事実」と呼べない場合は、個別の一情報として、その情報の裏付け／背景を知りたいということになります。このためのデータ表現としては、データ群の単なる集まりとしての「表形式」データでは物足りない。つまり表形式では、利用者にとって意味を捉えるデータ群として扱いにくい、言い換えれば利用者から見た意味合いに合わせるための作業を、全て利用者が行う必要性が生まれるということです。
    • 従って、虫の体験に適したデータというのは利用者から見た理想的なデータ実装は、属性とデータ間の関係が扱いやすいものということになります。つまりリレーショナル型のＤＢよりも、ネットワーク型（或いは表形式とネットワーク型表現の混在）として扱うことができるものが望ましいといえるでしょう。最近のネットワーク型ＤＢ基盤が見直されていうという流れは、この辺りの背景があるものと筆者は捉えています。後はそういった形の実装データベースを容易に取扱うことができる照会言語や仕掛けがあると更に利用者への利便性が生まれるといえます。
    • 今後、更にこの要求に応えることができる利用環境というのがどのようなものか、考えて行きたいと筆者は考えています。　　（先頭に戻る）
    •  
    • その35：鳥の目（Bird's eyes view)と虫の体験（Insects' Experience)
    • 今回は、鳥の目と虫の体験として、昨今このキーワードが無ければ始まらない程のAI（機械学習）およびビッグデータ喧騒との関わりを考えます。
    • ここで「鳥の目」とは、経営者視点のこと。言ってみれば「戦略を設けるための対象への見方」と言い換えることができます。対象課題の包括的な構成を捉えて、今後の世間（外部）と自社（内部）の方向性を探ることを目的に、必要となる情報を備えた上でどのような目標設定を行い、また資源投資を決定するということになります。この意味で「経営者視点」としています。或いはもう少し現場に近いという意味では「管理職（マネージャ）」視点と言っても良いかもしれません。
    • このために必要な情報／データへの主要要件は、幅の広さと正確性。ここでの正確性とは、情報の出所や背景（コンテキスト）が判断できる内容を含むことが条件になります。単なる量の問題ではない点に注意。データの源によっては必ずしも正確性が判断し難い場合もあるでしょうから、その際にはデータを見る人の意思決定が必要になります。このためにリスク要素を踏まえることも条件となる。余りに対象（データ）が多い場合には、機械学習の仕組みを活用してみることも有り得るでしょう。但し最終的には経営者の意思決定と責任感が大切です。もし全ての決断を機械に任せるなら、そこでは「経営者（人）などいらない」かつ「誰も責任を取らない」という世界感が生まれることになりかねない。
    • それでは「虫の体験」とは何かというと、実行者の見方と体験のことです。医学的な言葉で言えば「臨床」のことになります。これは、一つ一つの事案（ケース）と言い換えてみることができます。商売に喩えれば、顧客との間の一回一回の触れあいの体験ということが出来るでしょう。顧客の担当者を設けるということを考えれば、仮にその担当者が変わった場合には、それまでの顧客との接点情報を引継ぐという流れが必要とされるということです。
    • このためにそれまでの取引体験を管理できることも要望される。この意味で個別取引やその状況を押さえておくためのデータが利用される。従って取引規模が大きくなれば、それを保存するための技術的活用が期待要素となる。しかしここでのポイントは、個別の顧客接点を自分たちがどのように価値付けるかということにあるといえるでしょう。その価値付けの方針によって利用するデータと活用の方向性が変わるということです。ここでも量に対しての機械学習の利用が期待できますが、但し力点は顧客との接点に置かれるべきであり、こちらでも人がどういった役割を果たすかが重要なのではないでしょうか（少なくとも、日本的文化ではと書いておきます）。
    • 結局、経営者視点、および担当者視点／体験のどちらにおいても、情報の背景と人の役割が重要であるという結論になりました。大量なデータもAI（機械学習）も、ビジネスを円滑に進める上での味付けであり、価値付けの源泉は人を抜きに語ることは本末転倒であると言っておきたいと思います。ここでは、効率性や技術的論理だけで流行に載るのは、ビジネスの長期的ビジョンと相反する可能性を高めることだと指摘しておきます。　　　（先頭に戻る）
    •  
    • その34：中小企業へのセキュリティ推進シンポジウム2017に参加して思うこと
    • 昨日、ベルサール日本橋で開かれた表題のセキュリティ関連のシンポジウムに参加しました。その際に感じたことを書いてみたいと思います。
    • シンポジウム前半は、近頃一般に話題として上がっているIoTやAI関連の講演で、情報セキュリティというこのシンポジウムとしての内容としては、正直なところポイントがずれていると感じました（講演の内容そのものがどうこうということではなく、あくまでもシンポジウムテーマとの関連としてという意味です。誤解の無いよう、念のため書いておきます）。比較的面白かったのは、後半のディスカッション部分で、特に企業経営者視点での情報セキュリティに関して普段から感じているというご意見の部分でした。このシンポジウム内容については、新聞や関連のウェブサイトで告知されるということでしたので、ここでは内容そのものについての記述はしません。
    • 規模の大小に限らず、多くの企業においては何らかの形で情報セキュリティと個人情報の取扱いを避けることができない状況になってきているのは事実だと思います。既に所謂マイナンバ制度が開始され、また改正個人情報保護法も今年の５月から運用されます。但し、セキュリティへの負担費用に関しては、企業経営者にとって効果が見えにくいために、どこまで対応すべきか、そしてどれくらいの費用を掛ける（人的なものも含む）かが見えにくいというのが本音でしょう。一方、関係省庁においては、対策を広めたいという思惑もある。そういった中で、情報セキュリティ対策を進める上での、大切な経営者視点について書きます。
    • 第１のポイントは、自社にとっての重要情報というのは何かを、棚卸しして見えるようにしておくこと。この際には最初から全ての情報一覧を隈無く網羅するというよりは、情報種類や発生場所に基づいて分類化して整理するというのが良いと思います。最初から漏れなくリストアップしようとすると、行きつく先が見えなくなるのでお勧めできません（勿論最終的には一覧が出来上がることが望ましいですが。そしてその分類毎に重要性・優先性を付加する。対象が見えないと、対策の起てようがないというのは大切な視点です。これらの作業においては、一先ず技術的対応は脇においておくことです。セキュリティベンダーなどが色々ツールなど利便性を言っているでしょうが、一先ずそれは無視する。
    • 第２番目として、棚卸しと自社にとっての大まかな重要度が見えた時点で、対策と人の視点に目を移す。この中には情報のフローについて見渡すことも大切になります。情報の流れを描くことで、クリティカルな対応点が見えるようになってくる。これは特に脆弱性を捉える上で大切になってきます。情報に係わる「人」についても、この時点で明確化してゆきます。その上で具体的対策を考えて行く。対策の基本的な方法については類型化して捉えると効率よく処理できるでしょう。ここで初めてツールの話が出てくることになります。
    • 第３番目に、情報の正確性の確保と、データのバックアップを検討する。最近はランサムウェアといった情報の改竄や破壊を意図している所謂「攻撃」が目立ってきているので、いつでも（ほぼ）最新で正確な情報に戻すことができるための対策を立てておくことが重要度を増してきています。その上で、リスクを踏まえた回避方針を適用する。クラウドサービスの利用というのは、対策リスクの転嫁の一つの手法とも考えることができますが、オリジナルの情報の維持や復元に関しての責任は自社にあることを忘れてはいけないところです。
    • こういった対策を立てて行く中で、自社の持つ情報が整理できて、次第にその情報やデータを積極的に活用できる方向に進められると良いというのが、次のビジネス視点であることはいうまでもありません。以上、概要として情報セキュリティ対応視点に触れました。具体的な方法に興味を抱いた方があれば、是非ご連絡を。これらは、データモデル発想が基礎となっています。　　　（先頭に戻る）
    • その33：　論理データモデルの元になる発想について
    • ネットワークグラフ利用のためにも論理データモデルから考え、そして概念的なデータの構造を考えることの必要性を説明してきましたが、今回は少し視点を変えて論理データモデルの元となる発想を検討します。 （先のパナマ文書DBのモデル図は、こちらを参照下さい（JEMUGゲストページ）　2016年12月31日付）
    • 筆者は放送大学（オープン・ユニバーシティ・オブ・ジャパン）の学生として、最近の知見に基づく講義内容に関心を持っています。その中で「言葉と発想」（伊藤笏康聖徳大学教授）の講義内容に、英語を含む欧米的な発想への興味を喚起された点があったため、それとデータモデルとの関係を踏まえた読者への投げ掛けを行いたいと思います。なおこの講義の詳細は、同名の講義テキストを参照下さい（「言葉と発想」2011年3月、放送大学教育振興会発行、伊藤笏康著）。
    • この話題について筆者が特に、データモデルに関連する視点で興味を抱いたのは、次の２点でした。つまり、(1)英語（基本的には欧米系語で共通。以下同様）の普通名詞の基礎となる発想、(2)統語論（syntax）と意味論（semantics）から見る英語文の構造、についてです。
    • まず(1)について、端的に言えば英語の普通名詞は「概念を表すものとしてできている」という点です。これはつまり辞書の見出し語となっている普通名詞単語は、概念を表すものであって、個別のモノやヒトを表していない。これは日本語で使われる名詞の役割と大きく異なる性質です。具体的には「cat」という単語は、英語を使用する人にとっての「猫概念（内包と外包で説明される）」を示しているが、具体的な個別の「猫」を指すことができない、という発想に基づくということです。個別の猫を指し示す時には必ず「不定冠詞（a）」や「定冠詞（theなど）」が必要となる。つまり、目の前にいる猫を示す場合には「cat」ではなく、必ず「a cat」や「the cat」などのような語の使い方になります。英語圏の母親が子供に猫のことを言葉で教える際には、必ず「cat」ではなく例えば「a cat」として教える。これに対して日本語では「猫」という名詞を用いるだけで「猫概念」も示せるし、「公園で見つけたノラ猫」、「目の前の飼い猫」などを表せ、それは言葉の使われる場面場面でイメージ可能となるという訳です。私たち日本語圏に住む者にとっては当たり前のことが、英語を使う人たちとの発想の違いの元となっているということになります。データモデルを考える上で、エンティティ（Entity）という概念箱、および個別的例示としてのインスタンス（Instance）という構成要素は、上記のような言葉の背景に基づくものだと改めて考えさせられました。
    • また(2)についてですが、これはエンティティとエンティティの間の「関係」を表す「述語」の使い方や、RDF（Resource Description Framework）の三つ組み表現に、その性質が表れていると捉えられます。「主語」＋「動詞句」＋「目的語」、或いは「主語」＋「述語」＋「目的語」というモデルでの表現関係は(2)の英語の発想の性質を元にすると良く理解できます。詳細は上記のテキスト本を見て頂くとして、データモデル表現（論理データモデルやセマンテッィクWebなどの意味ネットワークモデル表現）が、この英語的な発想に基づくものであるということを改めて感じる。英語のデータモデルを見て英語圏の人たちが、そのモデルを文章として捉える根拠が、これらの言語発想に基づくということを理解すると、より一層データモデルを考える上で役立つと思った次第です。
    • この短文に興味を抱いた方は是非一度、上記のテキスト本を図書館ででも目を通して頂ければ役立つことがあると思います。データモデルに関心が薄くても、英語の発想そのものの理解を目指す方にも有用でしょう（笑）。　　　（先頭に戻る）
    •  
    その32：　ネットワークグラフ利用の考慮点（その１）
  • 今回は、ネットワークグラフ利用のための要点について触れることにします。
  • （先のパナマ文書DBのモデル図は、こちらを参照下さい（JEMUGゲストページ） 2016年12月31日付）
  • 企業や個人のデータ活用において、対象となるデータが持っている構造、あるいはそのデータを見る視点を考察する上で、そのデータモデルをER図を用いて概念整理することが大切であることは、これまで繰り返し説明しています。一方、ER図によるデータ構造のモデル表現だけでは、ネットワーク型関係データ理解の上で足りない点があるのではないかということを前回のメッセージで示唆しました。データ同士の関係性を表現しようとするネットワークグラフ利用では、特にネットワークグラフ・データベース（DB）は、いきなりインスタンスの羅列から始まる傾向があるからだと筆者は捉えます。つまり概念的な捉え方がデータ構造から把握しにくい状態になるという訳です。
  • その直接的なデータ構造表現だけで足りないものを補う手段として必要な考え方が「オントロジー指向」を取り入れるということです。これは意味の概念化を図り、全体的な基本構造を把握しやすくする、いわば一段階上からの俯瞰的整理をして、ネットワークグラフデータ（またはDB）を用いて表現する意味を、第三者と正確に共有可能にしたいという考え方を元にしています。設計者本人だけでなく、第三者にデータ構造で表す意味を共有できるという点がここでの主張の意図ということです。
  • この具体的な整理表現は、対象となるデータ構造に依存するものと考えられます。ここでの要点は、その基本的考え方がオントロジーやERモデル図を記述する方法論を元にするという意味です。具体例として説明した例が、前回記述したパナマ文書DBを題材にしたデータ構造表現の取組みでした。また、オントロジーに加えて、DBを構成するインスタンスデータのデータ量などを視覚的に補足表現することで対象データがカバーしている領域のイメージ観を把握しやすくなります。これがネットワークグラフ利用の要点の第２点になることを付記します。
  • 今回は、ネットワークグラフを表現し活用する上で、（１）概念モデル表現が大切であり、このためにオントロジー指向やＥＲ図などのデータモデル技術が役に立つこと、（２）その意味理解や設計趣旨を関係者間で共有する上で、対象データの意味的な関係やデータボリュームイメージを視覚的に表現する手法が有用であること。以上の２点をここでの議論として説明しました。次回も更に具体的内容を説明してゆきたいと考えています。　　（先頭に戻る）