健司Tweet今回はユーザ企業・ベンダー企業間の関係について考えてみたいと思います。DX研究会の議論の中では、「ユーザ・ベンダーがパートナーとして新たなことにチャレンジするプロセスをつくっていくことが、今後のビジネスを発展させる原資となる。」「デジタルトランスフォーメーション推進において、再レガシー化を防ぐためにユーザ企業側にITエンジニアが必要であり、ビジネス企画主体とITエンジニアが一体的な検討を行う必要がある。」というような指摘がありました。「ユーザ企業とベンダーの関係」と言われると、まず契約の在り方を考えてしまいがちですが、その前にそれぞれの役割の見直しが必要であるようです。以前、筆者はあるプロジェクト(CRM導入や基幹系システム見直しに合わせて、データHUBを構築しました)に参画しておりましたが、そこでは体制(IT部門要員の経験値の違いや、システム子会社・複数ITベンダー混在)やシステム構築方法(SaaSやERP、スクラッチ開発)や配置(クラウド、オンプレミス)の違いもあり、様々な関係性を見ることができました。日本特有の、欧米企業に比べてIT部門要員数が著しく少ないという事情を抱えつつ、要件定義と設計以降で契約形態を分ける、アジャイル開発...等の様々な取組みが行われ、IT部門は色々な工夫をしながらシステム導入プロジェクトをマネジメントされていました。(今になって)システム構築方法やITベンダーの特色の違いに気を付けながら状況を振り返ると、ひょっとしたら、「これ」を誰が担当するか宙に浮いてしまっていたのでは?と感じた点がありました。それは「対象事業や業務の形をデータで表現する」ということです。具体的に考えてみます。システム導入の前提として「対象事業や業務の形を明確にする」必要があります。色々なお客様の企画書を拝見する機会に恵まれておりますが、どれを見ても当然のように対象事業や業務に関しての説明が記されています。「対象事業や業務の形をデータで表現する」ことが、企画段階で行なわれているケースは殆どありません。「システムはITベンダーが造るものであり、データはシステムに付随している」と考えてしまっているのでしょうか?そう考えてしまうとデータ設計はITベンダーの仕事になってしまい、それに疑問を持つことは殆ど無いでしょう。個別システム内でプロジェクトが完結するのであれば、或いは企業情報システム全体が、重厚長大な基幹系システムと一部機能を補う個別システム(例えば請求書発行システムのような)で構成されているのであれば、それで上手くいくのかも知れません。SaaS等により自企業内の考え方で統一できないシステムとの連携を考え始めたり、アジャイル開発への取り組みを進めたりしようとすると、そうはいきません。前者の場合はシステム間I/F設計やデータ移行に思ってもみなかった時間を費やす事になるでしょう。後者であればアジャイル開発への取り組み自体が成立しないように思われます。(イテレーションの度にTABLE構造が変わってしまうのを想像してみて下さい。そのシステムから産み出されるデータを、誰も活用しようとは思わないはずです。)「対象事業や業務の形をデータで表現する」ことが企画段階で行なわれていれば、システム導入(設計やデータ移行等)の難易度を見極めることができます。アジャイル開発に取り組む場合でも、イテレーションの外側でおおよそのデータ構造設計を完了できるため、アジャイル開発の利点を享受できるはずです。DX研究会の議論では、ユーザ企業側ITエンジニアの必要性やビジネス企画主体との一体的な検討の必要性を指摘していましたが、まずは「対象事業や業務の形を明確にし、その形をデータで表現する」役割を誰が担うのかを、明確にするべきです。(いずれにしろ、ユーザ企業が担うべきですが...)DX推進に向けた第一歩として、弊社では「データHUB」を導入し、徐々に企業全体のデータ品質を上げていくことをお勧めしています。データ総研1985年創立。データ設計と標準化を専門とするITコンサルティングファーム。データ中心アプローチ(DOA)における先駆的企業であり、独自開発の設計技法と開発方法論をベースとしたコンサルティング事業を展開。業務要件定義、データ視点による業務プロセスの改善、データカタログに代表されるビジネス資源の整備に関するコンサルティングサービス、および、企業のデータマネジメント実践を目的とした教育サービスを提供。