前回より柱シリーズから専門領域に踏み込んでいます。ただ、このインフォメーション（情報）つまりデータの分野は底なし沼とも言われており、踏み込むと足をとられることになりかねません。コラムとしては、専門性よりは、少しマネジメント面の方に焦点をあて、綴っていきたいと思います。
まず、ITABoKのP269の以下の記述に対して、言及していきます。
概要
統合アーキテクチャは多くの熱⼼な統合アーキテクトを持つ専⾨領域ですが、全ての IT アーキテクトはデータ統合に関与する 基本的なデザインのプリンシプルを⼗分に理解する必要があります。
中略
データ統合の要件に応じて、データは始めに様々なソースから抽出された後に、⼀般的には何らかの⽅法でフィルターされ、集結、集約、変換され、最後にはターゲットとなるユーザーやシステムに提供されなければなりません。
アーキテクトとして、あなたはキャリアを通じて多くのデータ統合のプロジェクトに必然的に関与するでしょう。⾃社運営型システム、クラウド上のホスト型システム、サードパーティサービス、ビッグデータを含むまでに IT の⾵景が拡⼤するにつれ、データ統合は益々複雑にもなりつつあります。データ統合は、より具体的にサービスや API に取り組むシステム統合と密接に関係しています。
(ITABoK V2 日本語訳P269より)
まず、ここで出てくるのが、基本的なデザインのプリンシプルと言う記述です。ラウンドテーブルでも話題となった、５ゲン主義のうちの「原理・原則」です。さらに記述は、ターゲットとなるユーザーやシステムに提供されなければなりません。
となり、このことは、普遍的であり、まさにプリンシプルと言えるでしょう。
ただ、このことを実践するのも、データ統合は益々複雑にもなりつつあります。との記述にあるように、ハードルは高くなる一方です。
解決のためにはどうすれば良いかは、古今東西で言及されてきていますが、ITABoKでは成熟度によりアプローチが異なると主張しています。
■ 情報マネジメントケイパビリティの成熟度
効果的な情報マネジメントは⼀度に訪れません。特定のあるアプローチを採⽤する前に、情報マネジメントのケイパビリティの現在の成熟度を評価する事が重要です。
指標（１）ー 未着手状態
公式の情報マネジメントのプロセス/プリンシプルは⼀切存在しない。情報はその場限りか、必要性に応じて対処される
指標（２）ー 初期状態
情報に対する権限が IT には存在するが、ビジネス・プロセスへの影響は限られている（または、その逆）
ビジネスと IT のコラボレーションに⼀貫性はなく、それは各 LOB のビジネス内の個々のデータ通のメンバーやインフォメーション・アーキテクトに⼤きく依存している
指標（３）ー 管理された状態
職務や責務が個々の LOB で定義されている可能性がある
⼤まかに定義されたプロセスが LOB 内の主要なアプリケーションの周囲に存在する。⼀般的に、情報マネジメント上の問題 は根本原因への体系的な対処を伴わずに反応的に処理されている
LOB の間で標準化のプロセスが初期段階にある
指標（４）ー 標準化された状態
ビジネスが参加して機能横断的なチームが形成され、インフォメーション・アーキテクトには明確な責務が与えられる
標準化されたプロセスと⼀貫性が LOB 全域で確⽴する
中央化され容易に利⽤できる、データ⽅針のレポジトリーが設⽴される。情報の品質が定期的に監視・測定される
指標（５）ー 進化している状態
情報マネジメントに対する組織構造が制度化され、機能全域でビジネスに不可⽋なものとして認識される
情報のコンテンツやポリシーの作成に対する全責任をビジネスが担う
プロセスとメンテナンスでの定量的な品質上のゴールが設定される
指標（６）ー 最適化された状態
情報マネジメントは中核的なビジネス・プロセスであり、意思決定は定量的な便益 - 費⽤ - リスク の分析によって⾏われる
組織向けの定量的なプロセス改善上の⽬標が確⽴される。それらは変化するビジネスの⽬標を反映するべく継続的に改定され、マネジングのプロセス改善での基準として使⽤される。
(ITABoK V2 日本語訳P277-278より)冒頭で効果的な情報マネジメントは⼀度に訪れません。と言い切っています。皆さんの所属する組織の成熟度は、どうでしょうか？
成熟「インフォメーション・アーキテクトには明確な責務が与えられる」という、指標４の標準化された状態まで持っていかなければ、「具体的にサービスや API に取り組むシステム統合」を実現することが難しくなり、公的機関、民間機関ともに競争優位から脱落していくことになるのでしょう。
成熟度のなかで度々登場するLoBは知る人ぞ知る用語かと思いますので、少し説明させてください。LoBとは「Line of Business」の略で、もともとの意味は企業業務に直結するライン部門です。多角経営企業でいうところの、「事業部」にも相当します。
しかし、昨今は拡大解釈されて、「企業が業務をするうえで主要な、基幹アプリケーション」として認知されています。現在ではこちらのほうがLoBの意味としては主流となっています。
ところで、競争優位を確実にしていくにはどのような手立てがあるのでしょう？
IT はデータを作成、更新、蓄積するために⽤いられるシステムを保持するため、ビジネスのリーダー達は、初めは IT を情報の所有者として⾒なしているかもしれません。
しかし、アプリケーションの全責任が IT からビジネスに移⾏するように、それらのアプリケーションから⽣成される情報も同じ観点から捉えられるべきです。ガバナンスを⽀援するために使⽤されるテクノロジーは、情報マネジメントのケイパビリティと⼀致します。(ITABoK V2 日本語訳P283より)データは誰のもので、ガバナンスの責任者は誰であるかは、成熟度により変遷するとも言え、ＩＴ部門から最終的にはビジネスサイドに落ち着いていくことを示しています。
また、ガバナンスが機能するのは、以下の事項によって達成するとしています。
・価値を得るためのゴールと⼿段に合意する
・ロードマップと成熟度レベルへの理解
・ガバナンスグループに対する⽅針、⼿順、情報
・ガバナンスによって設⽴されたイニシアティブとプロジェクトに資⾦とリソースを供給する
(ITABoK V2 日本語訳P283より)つまり、タスクフォースやプロジェクトを立ち上げる際に、ガバナンスを機能させるためには、基本的な手順を踏むことが、重要であるとも言えます。インフォメーション・アーキテクチャーについては、泥沼に足を取られないように、道を見極めながら着実に成熟度を上げていくことが肝要であると考えます。