企業内に大規模なデータ基盤を構築するにあたり、進め方に関して重要だと思われることを説明します。
一部、[都合のいい利用者を想定してはならない] でも少し触れた内容になりますが、それを含めた補足となります。
データを高次元で統一しない
これは、[大規模な組織の現状] で述べた通りです。
大規模な組織では、顧客や事業が多様です。つまり、ビジネスアーキテクチャとデータアーキテクチャを無理に統一して硬化させてはなりません。不毛な挑戦は、ITが営利活動の足かせになる懸念すらあります。
すべてが完成しないと使えないシステムを計画しない
企画し、計画し、設計し、製造する、という完成品を目指すつくり方にしてはいけません。この考え方は完成系がありながら、その完成をゴールとする場合にのみ正解です。
組織の成熟度、投資額、課題認識レベル、システムの新しさ、運用作業員のレベル等、ITを取り巻く環境はさまざまです。また、これらも常時変化を続けています。
すべてを同じレベルに揃えてからヨーイ、ドン!で始まるシステムは空想の産物です。現実的なアプローチとしては、異なるレベルの組織とシステムを混在可能にしながら、段階的にレベルをそろえて行く方式が有効です。
すべてを知っていると思ってはならない
大規模な組織では、局所だけを見ても規模の大きなITシステム群があり、一見不都合に見える仕組みがあったとしても、もっともな存在理由があります。
「これがぼくのつくったさいきょうのデータ基盤！」志向に走るのは、特定ドメインで活躍してきたIT技術者、狭い視野になりがちなIT開発者が陥る罠です。
良かれと思って誰でも使えるデータセットを作ろうとすると、結果的に誰にも使えないデータセットを作ることになります。すべての人に都合よく作られたシステムはできません。ある人にとっての「便利」は、別の人にとっての「不便」であることも心すべきです。
方針は明示するが、即時実行は強要しない
方針を周知した後、今すぐこの通りに実装しろ、という強制を行わないことが重要です。
スタート時には一部の部門が従わない、準備ができていない状態に腹を立てることになります。それと同時に、知らなかった多様性や課題に出くわし、度々プロジェクトの進行はストップします。
業務の多様性という言葉を常に理解しておくことが必要です。重要なのは、データ基盤というITに都合のいいシステムを作ることではなく、長期的に利益を上げるビジネス上の仕組みを維持することです。「ガバナンス」に強硬実施という意味はありません。
後で紹介しますが、目指す目標のみ示してそこまでの道筋をステップ論的な成熟度として設定し、各部門における現状と次のステップを明示します。そして、当事者が必要だと思う段階に来たら自発的に次のステップに進む、というのを繰り返します。
コメント