活動概要お問い合わせプロフィールその他アクセスパートナーアーカイブアーカイブ2023年アーカイブ2022年アーカイブ2021年アーカイブ2020年アーカイブ2019年アーカイブ2018年アーカイブ2017年アーカイブ2016年アーカイブ2015年トップ›アーカイブ›アーカイブ2018年アーカイブ2018年ここでは、これまでの【所長の視点】を案内しています。データモデリングとオントロジーの関係性12月10日(月)に、筆者の所属する日本エンタープライズデータモデリング・ユーザーズグループ(JEMUG)の定例勉強会が行われました。筆者もその中で、メッセージその64で触れたTheBrainツールに関して1セッションの紹介説明を行いました(この時の資料については游悠レポートサイトで公開する予定です)。この時のもう一つの話題として「データモデリングvs.オントロジー」という題目で議論が繰り広げられました。今回はその時の内容について簡単に触れることにします。(また、今年もJEMUG主催による「データモデリングコンテスト2018」が開かれます。その要領は、JEMUGのWebページに掲載されていますので、興味のある方は是非チャレンジして下さい。こちらデータモデルを扱っていると、オントロジーと言っている領域との違いが曖昧になることが、筆者には良くあります。オントロジーを近年標榜する人達からすると、データモデリングに携わる人々とは大きな違いがあると意見する記事が見受けられます。今回の話題はそういった内容の議論資料を元に提供されたものでした。Language)の表現技術を利用した、意味ネットワーク系の考え方を主体としたものです。一方のデータモデリングの技術は、オントロジー論者からは、リレーショナル表現を用いた主にリレーショナルデータベース(RDB)向けの技術として捉えられている形です。この辺りに互いの認識の差異が生まれていると筆者には考えられます。リレーショナル表現を用いたデータモデル設計は、階層的に異なった設計視点レベルがあると考えられており(概念・論理・物理)、それぞれに設計表現の範囲の違いがあります。筆者の見方としては、概念モデルはモデル対象のスコープを表現するのが主目的であり、論理モデルは正規化を主軸としたデータ構造の在り方を記述するものであり、物理モデルは実装上の物理環境を考慮した設計変更の手段を表現するものです。論理レベルでの設計では、対象領域の「抽象化」という捉え方と「集合的なまとまり」を基礎に置いているのが特徴と言えます。実際はプロセスの部分は、エンティティ・リレーションシップ図(ER図)だけでは表現しきれないため、別途のプロセス表現をするための補足情報や、エンティティの表す内容を説明するコード値情報などが必要になります。単なるER図だけでなく、前記の情報を含めてデータモデルの意味が分かるというのが正確なところです。意味ネットワークの技術を介したオントロジー設計というのは、抽象化というより、実世界に存在する個別のオブジェクトに目を向けて設計表現を行うといった、敢えて表現すればボトムアップ式の捉え方をしているという具合に筆者には見えます。個別対象およびその振る舞いに主要着眼点があるという意味です。このような視点のオントロジー発想からすると、ER図式のデータモデリングは個別の構造表現を行っていないと映るようだということです。このような見方と互いの理解度の違いにより、今回の話題のような両者の「対立的」な議論が生まれているのではないか、というのが筆者の感じた点でした。実際には、元の資料での議論となるような大きな差異はないという意味です。以前にこのメッセージ欄で筆者が触れたように、(1)高い抽象化レベルをデータモデルに適用しすぎると、反ってモデルで表現しようとする対象領域が分かりにくくなる、(2)構造の分かりやすさの点では、具体的な個別インスタンスをER図で表現しておきたいことも生まれる、といった点がデータモデルへの要請としてあるのではないかというのも、議論の補足になります。いった部分を、意味ネットワークベースのオントロジー表現が補完することがあるという意味です。今回の話題に関して、両方の世界の技術者が全て納得するという状況にはならないでしょうが、こういった折衷的な視点を交えながら、モデル化とシステム構築の世界が発展してゆくと考えるのが筆者の結論ということにしておきます。2018(テーマ「データマネジメント組織を創る」)が開かれ参加してきました。今回はその中での主話題であったと筆者が考える「データマネジメントのための人・組織的役割の形」について書きたいと思います。組織におけるデータマネジメント実践の価値は、これまでも何度かこの場で触れてきたように、直接的な利益を生むというよりはデータを資産として捉え活用を継続してゆく上での生命線であるという点にあるといえます。短期的な利益を生むことを期待される経営者にとっては、その価値を認めにくいというのがこの点に深く関わるとも考えられます。長期的な意味でのビジネス継続性・データ品質に誰が責任を持って取組んで行けるのかということに関わります。ある意味で、経営者はそれを責任者として支援する立場でしかありません(後で触れますが、しかし重要な関係者です)。このための「組織を創る」というのは、何という名前(の組織)にするかということ自体が重要という訳ではありませんが、「名は体を表す」の言葉通り、名前を持った組織が生まれることで活動の実態が生み出されるという意味で重要性を持つといえます。今回のカンファレンステーマで出て来た言葉で目立つのは、欧米で言葉として出て来た「データスチュワード(シップ)」と「CDO(チーフデータオフィサー)」でした。これらは固定化された職務ではなく、実態としては柔軟に適用されている「期待役割」であるということが筆者には理解できました。いった職務名を作ることが目的ではなく、権限を踏まえた活動実態を生み出すための位置付けであるということです。これは当たり前のように聞こえますが、大切な視点であると筆者は考えます。従って、職名を備えた人(組織とすれば複数)を任命すると同時に「役割の定義」と「権限」を明らかにする必要があるということです。その活動を実質的なものとして回るようにすることと、効果を維持継続してゆく仕組みとして育てるという流れです。これによって、職場のAさんが退職して(データ管理上の)ノウハウが失われてしまうということを防ぐようにするということ。目で直接見ることができない電子化された、データや業務フローを相手にする上で大切なことといえます。この点をキッチリと理解して組織を支援することが「データマネジメントに対する経営者の責任と役割」であるということです。因みに、「データスチュワード」や「CDO」が固定した職務でないと筆者が感じた理由としては、今回「プロジェクト・データスチュワード」などという名称が導入されているという点でした。従来も「業務依りのデータスチュワード」あるいは「ITシステム系のデータスチュワード」など、この言葉の使われている役割の幅が大変広い点が気になっていましたが、「プロジェクト」の名を冠する語が出てくるに至って「必要性に従ってかなり『柔軟性を持って』言葉が利用されている」という結論を持ちました。「CDO」に関しても、対象とするデータ領域が人によって差がありそうだということも合わせて感じました。JapanのWebページを参考にして下さい。Japanから翻訳出版されたDMBOK2が一つの共通議論の出発点として参照できます。データマネジメントのための組織は、それぞれの企業が置かれた環境条件によってかなり幅を持たせたものであることが理解できるでしょう。言えることは、他社の事例等はあくまでも参考であって、それぞれの環境によって「自分たちのもの」として環境を準備する必要があるということです。重要なことは固定化したものではなく、時間の変遷と共に継続的に見直しを行ってゆく必要があるものだということです。このような考え方で組織化を行い、これまでは現場の担当者やシステム開発担当者任せにしてしまったデータ資産のあり方に関する議論を、目に見える形にすること、そしてそのデータマネジメント継続の実現をすることが期待できます。それで本当に、有効な仕事やくらしへの時間配分が満足にできてると宣言できますか?今回は、そういった課題を日常的に抱えていると感じ、それを何とかしたいと考えている方のために、情報ツールを活用した対策方法について簡単に紹介したいと考えています。資料は色々集まって来るし、ネット検索すれば何かと情報を手に入れられるが、量が多すぎて結局何から手を付けたらよいかを考える前にくたびれてしまう。確かに役に立ちそうなデータや資料があったはずだが、それを後から探し出すのに時間が掛かっている。様々なデータや資料についての関連性を整理したいが、パソコンの上であちこち行ったり来たりしているうちに、肝心の要点を忘れてしまって、思い出すのに一苦労させられた。以前に結論を出したときに利用した情報を見直していたら、別の新しい視点からそれを使えることが分かったが、コピーして使ううちに同じようなデータが(PCの)あちこちに散らばってしまった。どれがオリジナルで、どれが最新のものなのか見分けが付きにくくなってきた。これらは何れも、データや資料についての意味付けや、物理的な配置構造管理の問題と関わっています。今のパソコンやタブレット/スマートフォンなどが提供する基本機能が、必ずしも個人個人の必要としている情報の見方・使い方ニーズに合致していないという中途半端な状態であるからだといえます。いってみれば、データや情報を貯めるバケツにはなっているが、それを自由自在に操ることができるような仕掛けを十分に提供してくれてはいないということです。これは、筆者にとっても長年の悩みの種であったといえます。「TheBrain」というものでした。このツールの当初の発想は、マインドマップのような人の発想を支援するためのネットワーク図を管理するためのものであったと想像されます。Memory」を標榜しています。このツールの面白いところは、各利用者の発想で、個別に情報同士の関係性を自由に定義できることにあります。自分に合った意味のネットワークを作れることです。スケジュールやタスクの管理に結び付けることができるという優れものです。この紙面幅で、言葉だけで言われてもピンと来ないと想像しますが、YouTubeの動画サイトで「TheBrain」をキーワードにして検索すると基本的な機能や使い方、利用事例といったものを見ることができます。説明は英語だけですが、視覚的に動きを知れば理解が深まると思います。製品の価格もそれほど高くはありません。筆者は、次回のJEMUG勉強会でこのツールの利用について、少し時間を使って説明実施する予定です。ご興味のある方は参加してみて下さい。ついて昨日(10月9日)、ほぼ3ケ月ごとに開催しているJEMUG(日本エンテープライズデータモデリングユーザーグループ)の勉強会がありました。今回は、そこで話題になった内容について簡単に紹介します。一つ目の話題は、システムの見直し・再構築に当りデータモデルを中心に据えて、どのようにシステムの利用者部門とのコミニュケーションを正しく図れるようにできるかということでした。これはある大手のシステムベンダー企業に所属しているA氏からの体験に基づく事例紹介に近いものです。ここでは、その利用方法に加えてシステムの再構築に当ってのデータモデル利用をする方法論として、どうしたらそのステップが必要なものとして利用者部門、ひいてはスポンサーとなる経営者に理解を深めてもらえるだろうかという点も話題になりました。いう点では、筆者がこのコラム記事の中で何度か触れてきた内容と重なる部分が多いものでした。経済産業省が最近、2025年を目処に古いシステムは何とか再構築をしておかないと過去の遺産にシステム部門が押し潰されてしまうという危機について警鐘を鳴らし始めています。放っておくと旧来システムの維持だけでシステムを担当している人たちの時間が100%取られてしまうことになるということでしょう。これを回避するための中長期的手段としてデータモデリングの手法をうまく利用して、実質的な効果を生むプロジェクト進行をするようにしたいという関係者の思いということです。これには、本当の経営者の理解が必要です。世の中の流行だけに追い回されるような対応をしていると、いつの間にかドロ船に乗っていたことに気付かない状態(あるいは茹でカエルか?)になりかねないということです。二つ目の話題は、データモデルの中でエンティティのある属性項目を変更する必要が生まれたときの所謂マスタデータ管理に関連するものでした。具体的な話としては、商品マスタの中である商品について名称の変更が発生した時に生じうる不都合についてでした。主キーに日付けを入れてマスタ履歴として管理すればこの問題にうまく対応できるだろうかという点。下手するとマスタ内の変更が起き得る全ての属性項目に有効日付項目を対応させる必要が出てくるのではないかという点。これはアプリケーションプロセスで何らかの対応(ロジックの組み込み)が必要になるだろうということ、或いはトランザクション内に属性の必要項目として、発生時点情報として含めておけば良いといったような手段が議論されました。Dimension)の話題になるというのが一つの結論でした。三つ目の話題の投げ掛けは、データモデリングとオントロジー分野の連携性の話がありました。海外の医療関係領域で、病名と対処方法との間の関係としてオントロジー的な動詞句表現で整理表現する動きが出て来ているということ。この流れに日本語を乗せるのは難しいという話題にもなりました。その具体的な内容に関してはここでは触れませんが、オントロジーを専門としている人々とデータモデリングに携わる人々の意見の交流と理解度深化が必要となるだろうといった意見も生まれました。この話題は次回の勉強会で継続する予定になっています。筆者は、第四の話題として、前回にこのコラムで取上げた「データモデリングを支えるツール」について、一部のツールに関しては具体的な内容を取上げて説明し議論しました。この内容の一部は以下の「游悠レポートサイト」でのレポートを参照下さい。「2018-001参照」こういった勉強会への積極的参加者を増やして行きたいということで、この回(会)はお開きとなりました。このコラムに興味を持っている方であれば、できれば参加を促したいものです。紹介これまでデータモデルに関して、何度も話題を取上げました。今回はそういったデータモデル作成を支援するツール群の概要紹介をしたいと思います。ツール類の利用というのは、年月が経つ毎に変更が行われ、また流行廃りが起きるためそういったモノの選定に悩む利用者は多いでしょう。幾分かの投資をして導入されたツールが直ぐにサポートや提供終了ということになると目も当てられないといったことが気になります。使えるツールを活用せずに、全て手作業で対応するというのはもっと時間や手間ということで考えれば、余り良いこととも思えません。要するにツールは単なるツールとして捉えて、そういったサポート期限も考えながら利用ノウハウとして自分の中に蓄積される知識を大事にするという考え方で臨むのが、一番上手い方法ということができるでしょう。今回「データモデリングを支えるツール」は、3つの分類で捉えることにしました。第1番目はエンティティリレーションシップ図(ER図)による記述方法をメインで提供するツール群。これらは、ER図を単純に記述するだけでなく、そこで書かれた設計情報を元に、論理(考え方設計)・物理(実装)を支援する機能を提供する役割を果たすものが大部分です。リレーショナルデータベース(RDB)へのテーブル作成用DDLを自動作成する、或いはRDBに作成されているテーブルからモデル内にその定義情報を取込む(リバースエンジニアリング)ことができるといった具合です。設計情報のメタデータを保有するリポジトリという位置付けで広範囲に応用できる製品もあるのが特徴です。第2番目は、データモデル図として、UMLのクラス図での記述を中心に据えているツールです。これはどちらかというとオブジェクト指向によるシステム開発を支援する立場で考えられているツールといえるでしょう。クラス図以外のUML記法や、プラスアルファの機能を合わせて提供して、設計者や開発者の作業を手助けする立場といえるかも知れません(ER図記述も補完的に一緒に提供するものもあります)。第3番目は、システム開発の上流(要件収集)から下流(開発工程)までの流れを捉えて、データモデリングというより全体的な開発プロセスを支援する位置付けのツールです。データモデリング部分は全体プロセスの一部分として考えられているのが特徴といえます。どちらかといえば「方法論を含めて、開発全体の流れをを一つのベンダに依存しても良い」と考える利用者が取り得る選択肢と考えられます。そのベンダからの当該ツール環境の長期的サポートを期待できるという前提が期待できれば、良い考え方といえます。後はどれだけ費用の交渉力を維持できるかという点が鈎になるかもしれません。中にはマインドマップ表記を可能としているものがあります。提供機能範囲に比較して安価に入手できるものもあります。サポート(或いは製品のライフサイクル)について記述したのは、この分野のベンダやツールの移り変わりが、近年結構行われているという点にあります。前まで開発元であった会社がいつの間にか別会社に移っていて、その結果開発やサポート方針が大きく変わったという例も少なからずあります。Leadersで取上げられた記事を基準にして、その後の移り変わりという視点で整理してみました。(筆者としては、日本のツール開発・提供社が少ないというのは少々残念ではあります。)このため、例えばVisioのような描画ツールに近いと考えられるものは、検討対象から外して考えています。個別のツール情報に関しては紙面の都合上ここでは省いているため、具体的内容は以下の「游悠レポートサイト」でのレポートを参照下さい。メタデータ活用への第三歩(メタデータ活用に特別なツールは必要か?)前回、「メタデータ」利用の視点として人気のある見方に三種類位あるということを記述しました。これらの見方を実際導入する際に特別なツールが必要でしょうか?答えは、目的によって、「イエスでもありノーでもある」でしょう。メタデータの管理そのものは、いってみれば保持している情報/データについての論理的な手続きなので、管理する本人がそのデータの関係を理解できれば良く、それはスプレッドシート・ツール(例えばExcelなど)を使えば管理することができます。これが「イエス」の意味です。管理するメタデータの対象ボリュームが増大すると、中々スプレッドシートだけで対応することは難しくなります。保有内容の共有、或いは視覚的工夫により利便性を向上させるという点でも、スプレッドシートだけでは効果を上げるのが難しいといえます。これが「ノー」ということの意味合いです。「特別な」ということでいうと、その範囲はピンからキリまであるといえるでしょう。データベースや視覚化ツールにはオープンソースをベースにして用意されたものから、かなり専門的で大規模なメタデータ量までの対応を可能にするプロユースのものまで幅が広いということです。導入や管理に必要なコストも大きな違いがあります。手始めに簡単なツール利用の導入から始めて、要領やイメージを得た上で、自分たちに必要な機能を頭に描きながら拡張を考えて行くのが一般的な進め方だといえます。いずれにせよ、旧来の技術の考え方の範囲だけで収まってしまい、ツール利用の恩恵を得ない状態に止まるというのが最も良いとはいえない立場だということは間違いないでしょう。この点は、システムに携わる者として忘れて欲しくない点です。「メタデータ管理」は、ある意味データの関係性についての把握ということでもあるため、例えばデータのモデリングツールをうまく活用するという考え方もあります。「メタモデル」は当然のようにデータモデルツールを使って可視化をすることができるし、メタデータエンティティ間の関係性を図表現することにも使うことができます。後は一段と進んだ視覚化への要求、メタデータ共有の方法、維持継続性といった点を踏まえて、どのようなツールの組合わせを選択するかということです。コスト/費用の点も実際には外すことができない要素です。「メタデータを制する者は、データ活用の実態を制することができる」という意気込みで、是非取組むべき分野であると、筆者は考えています。後は、「実行あるのみ」ということができます。メタデータ活用への第二歩(メタデータの活躍の場はアラユル所に存在するということ)前回、「メタデータ」という用語の基本的な再確認と、それを管理することの大切さを考えてみました。データというのは、「メタデータ」と一緒に使ってこそ意味(データの表す背景)が理解できるということです。同じ文字・数値が並んでいても、それに付加されているメタデータの内容によって意味が大きく異なります。単位を誤解したために、大きな宇宙開発プロジェクトの活動が失敗に終わったという海外エピソードも、事例や教訓として流布しています。「この『メタデータ管理』をキチンと実施したからといって、一体どれだけの収益に繋がるのか?」といった点に明確な数値で応えることができない場合、その手間に掛かる活動時間や経営的投資を妨げる元になるという点を気にする人たち(特に経営者に少なくないと想定しますが)があれば、それは「データを活用するための投資」の意味を理解していないと言えると考えます。「数字で表せない事柄は管理できない」という言葉を耳にした方は少なくないと思いますが、それは所謂PDCAサイクルを回すという、プロセス管理や品質管理での話題です。戦術上の議論でアルということを示したい訳です。データやシステムの「活用」を目指すという議論の中では、「メタデータ管理」は「戦略議論」に位置すると考えるべきです。見返りを期待する投資発想ではなく、企業における前提となる基本態度であるという視点です。自分たちがどちらの方向に進んでいるかが分からないのに、精一杯動くということに不安を抱かない人があるでしょうか?あるとしたら、それはイエスマンだけの状況であるということに事ならず、そういった企業活動こそが効率性を欠く企業活動の原因になり得るといったら過言でしょうか?(これに対する意見は色々あることと考えますので、一先ずこのレベルで止めておくことにします)メタデータがコンテキストを支えるものだとしたら、基本は5W1H発想で考えることが一番分かりやすいといえるでしょう。データの持つ意味を考えるのにどういった内容をメタデータとして揃えて行くかということです。次に考えるのはその構成です。これは、データにデータモデルがあるように、メタデータにもモデルがあるということです。これを専門的には「メタモデル」と呼んでいます。三番目の要素が、集積し関係付けたメタデータをどのように利用するかという利用者としての視点です。これには、現在人気のあるシステム視点として、次の3つがあります。(1)グロッサリー(企業用語集)、(2)データリネージ(データ間の繋がりや関係性を捉える)、(3)影響分析(一つの修正が、連携している下流のプロセスにどのような影響があるかを知る)、といったような項目です。続きは、次回に考えることにしましょう。メタデータ活用への第一歩(データへのコンテキストを与え、管理することの重要性)6月26日に、ほぼ3ケ月ごとに開催しているJEMUG(日本エンタープライズデータモデリング・ユーザーズグループ)の勉強会が実施されました。そこでの議題項目は、(1)データモデリング・スコアカード、(2)エンタープライズ・アーキテクチャを指向する支援環境(ツール類)の動向、(3)データ分析活用におけるメタデータ処理の課題、といったようなものでした。それぞれ、興味深い話題でしたが(そのうちの一つは筆者によるものなので、尚更です(笑))、今回は(3)の「分析とメタデータ」で触れられた内容に関連して考察を加えます。「メタデータ」は単純には「データのデータ」、少し説明を加えると「データに関する情報を記述したデータ」として理解されています。「データ」は、言ってみれば単なる数値や文字の集まりですが、このデータが意味している内容および取扱い上の背景を説明するモノが「メタデータ」であるということです。「マスタデータ」という言葉もありますが、それはどちらかというと「同類のデータ集合」そのものの持つ意味合いや分類に着目した話です。これに対して「メタデータ」は「あるデータそのものの説明」及び「データ群の違い」を表現するといったかなり広い概念に用いられていると言えます(「メタ」という用語そのものが「上位概念を指す言葉です)。従って、「データのある所にメタデータが必ず付与されている」ということができます。このメタデータがデータ群についての意味を表しているのですから、その意味が正確に共有されないと「データ」の示す内容がうまく伝わらないことになります。単純には「123」という数字があっても、それが貨幣を指していて「円」なのか「米ドル」なのか、或いは重さを示していて「グラム」なのか「ポンド」なのか、といったことが全く議論できないということです。これだけでも如何にメタデータ無しの生活ができないということが分かるでしょう。実際、この単位を誤って処理したために、宇宙開発分野で大きな損失を蒙ったという例が存在しています。「曖昧なデータは取り扱うことができない」、寧ろ「曖昧なままに扱うと危険を伴う」ということです。企業には多種多様なデータが溢れているのですから、メタデータを管理していくことが非常に大切であるということが分かると思います。そのメタデータを管理するということは、かなり以前から「情報資源管理」という言葉で重要視され、ISO/IEC11179という技術標準などでも扱われています。図書館の分野では書籍類の管理についてのダブリンコア・メタデータ標準をベースに書誌管理を行う取組みとして早くから利用されています。データを資源として活用しよう、AI(人口知能)分野でビジネスを広げようという時代背景にあって、メタデータがキチンと管理されている状態というのが大前提になるという意味が、読者にはよく分かるのではないでしょうか?しかし、このメタデータをうまく取り扱えるようにするということは、一朝一夕にできることでない点を忘れることができません。何種類ものデータに関する辞書作り(維持)を行うということですから、その手間と継続性確保には「決意と持続する意思」が要求されるといって過言ではありません。小規模なメタデータであれば、表管理ソフトで個人的に扱うことができるでしょう。企業・組織レベルでのメタデータをうまく扱ってゆくには、そういった単純な手段だけでは継続が難しいと思います。昨今、メタデータの管理・活用をするためのツール類も出ていますので、そういったものを利用しながら、中長期的な視野をもってメタデータマネジメントに取組む企業が増えることを期待します。今後もこの話題は続けたいと考えています。Associatiton)日本支部#9分科会での活動について書いてみたいと思います。Design」に関しての内容の説明を担当しました。そこでの説明の中で、あらためて感じたことを中心に触れてみます。Development」という表題でした。Design」という名称に変わったことについての筆者の期待から説明を始めた訳です。この期待は、必ずしも原文の記述者の意図に合ったものかどうかは分かりませんが、敢えて期待として述べたのは次のようなことでした。Design」は「コンテンツ技術であり伝える技術である。」という考え方があります(出典は、文末の【参考】を参照)。これは、情報を如何にして第3者に分かり易く伝えるかという視点からの言葉です。Design」という呼び方に共通の考え方があって良いと感じたことを説明しました。「データに関するデザイン」は、設計・開発者のためだけのものではなく、利用者であるビジネスユーザや、後からメンテナンスを実施する担当者にも、その考え方がしっかりと伝わるものでなければならないだろうということです。設計者や開発者の満足で終わるのではなく、第3者にデザイン内容を継承できるようにしていなければ意味が半減してしまうという意味です。この考え方を設計や開発に携わる人々がしっかりと意識して、シッカリとした仕事として、作成物の仕様を伝えられるようにしていることにこそ「デザイン」の意味があるということ。その生成物が時代と共に変更される際にも、その変更情報がキッチリと伝えられる(ようにする)必要があるということです。そのためにも、標準化活用やガバナンス維持の考え方が必要です。中で伝わっていてこそ、品質の高いシステムが構築・維持できるという点がポイントです。大きく言えば、組織というのはややもすると既存の習慣に慣れてしまい、なかなか改革を推進することに難しさを伴いますが、ビジネスとシステムの継続性と安全性の視点から、是非ともこの考え方が根付くようにしていきたいものです。これが、開発コストやメンテナンスコストの大幅な改善に結びつくことは疑いがありません。経営視点からの達成すべきビジョンとして、システムを利用する人々が胆に命じて欲しいものです。その場しのぎの安易な設計や開発という考え方は、将来への禍根に結びつくと言って過言ではありません。いった考え方を、関係者に広めるためにも、このDMBOKの参照をお勧めしたいと思います。この資料は、現在Dama日本支部の有志の方々により、日本語化が進められています。近いうちに日本語版も発行されることが予定されています。ご期待の上、活用下さい。Designはコンテンツ技術であり伝える技術である。情報が伝わるか伝わらないかは受信者側の解釈や理解度に大きく依存するとはいえ、情報を作り出す発信者側の工夫に余地がないわけではない。