データの"意味"を揃えると、組織の意思決定が変わる

DXプロジェクトは、なぜ「正しく作ったのにうまくいかない」のか

DXの失敗原因について、多くの人は「技術選定を間違えた」「要件が甘かった」「ベンダーの力量が不足していた」と考える。実際にそうした問題もある。しかし、私たちが2020年の創業以来、100社を超えるDX・AI・システム開発の支援を通じて見てきた限り、最も多い失敗パターンはもっと手前にある。

データの「意味」が、組織の中で共有されていない。

これを私たちは「意味のズレ」と呼んでいる。仕様書通りに作った。テストも通った。納品された。しかし使われない。効果が出ない。なぜか。作るべきものの前提がズレていたからだ。

「意味のズレ」の3つのパターン

意味のズレは、発見が難しい。なぜなら、関係者の全員が「自分は正しく理解している」と思っているからだ。ズレが表面化するのは、たいてい数ヶ月後——システムが稼働してから「思っていたのと違う」と気づく瞬間だ。

私たちの支援先で頻繁に遭遇する、3つの典型的なパターンを共有する。

パターン1: 同じ言葉が、違う意味で使われている

従業員400名規模のあるB2B SaaS企業で、「チャーンレート」という指標が3つの定義で使われていた。

• CSチームは「サポートチケットがクローズされずに解約に至った率」
• 経営企画は「月初ARRに対する当月解約ARRの比率」
• プロダクトチームは「一定期間ログインしなかったアカウントの比率」

毎月のレビュー会議で、3つの部門が別々の「チャーンレート」をもとに改善施策を議論していた。施策が噛み合わないのは当然だ。同じ言葉が、違う現実を指していた。

パターン2: データはあるが、意思決定と繋がっていない

従業員350名規模の専門商社で、データウェアハウスを構築した。売上、在庫、顧客データを一元化し、BIツールも導入した。しかし1年後、ダッシュボードを日常的に見ているのは情シスの担当者だけだった。

原因を掘り下げると、データの集計単位と意思決定の単位がズレていた。経営層が知りたいのは「商品カテゴリ別の粗利推移」だったが、DWHの設計は受注伝票単位だった。見たい切り口でデータが出ない。結果として、Excelでの再集計が復活した。

ツールの問題ではない。データと意思決定の間の導線が設計されていなかった。

パターン3: 現場の業務と、システムの前提が乖離している

従業員200名規模のEC企業で、受注管理システムを刷新した。新システムは「受注→出荷→請求」の標準フローを前提としていた。しかし、現場には「仮受注→在庫確認→顧客確認→本受注」という4段階のフローが存在していた。

新システムは仮受注のステータスを持っていない。結果として、現場は新システムに入力する前にExcelで仮管理するようになった。二重入力が発生し、DXの目的だった「業務効率化」は達成されなかった。むしろ、現場の業務体験は悪化した。以前のシステムではワンステップだった作業が、新旧2つのシステムを行き来する作業に変わったからだ。

要件定義の段階で現場の実態を正しく捉えられていなかった。正確に言えば、現場の業務が持つ構造——なぜそのフローが必要なのか、各ステップが誰のどんな判断を支えているのか——がシステム設計に翻訳されなかった。

なぜこの問題は見逃されるのか

これら3つのパターンに共通するのは、「仕様レベルでは正しいのに、前提レベルでズレている」ということだ。

従来のシステム開発プロセスでは、要件定義は「機能」と「データ」の定義に集中する。どんな画面が必要か。どんなデータベースを設計するか。どのAPIを叩くか。

しかし、「そのデータが組織の中でどんな意味を持っているか」「その機能が誰のどんな判断を支えているか」「その業務フローがなぜその形になっているか」は、仕様書に書かれない。

書かれないから、伝わらない。伝わらないから、ズレる。

これが、私たちがDXプロジェクトの失敗を「技術の問題」ではなく、認知の前提が共有されていない問題と捉える理由だ。

Semantic SIという考え方

この問題に対する私たちのアプローチを、「Semantic SI」と呼んでいる。

SIは System Integration の略だ。従来のSIerは「システムを統合する」ことにコミットする。Semantic SIは、それに加えて「データの意味を統合し、業務体験を改善する」ことにコミットする。

設計の起点を「機能」から「前提のギャップ」に移すことで、プロジェクトの方向性が根本的に変わる。

具体的にやることは3つだ。同じ言葉が違う意味で使われている状態を発見し、定義を統一する。データと意思決定の導線を明示的に設計する。現場の業務構造をシステム設計に正しく翻訳する。

地味な作業に見える。しかし、この作業を飛ばして作ったシステムが「使われない」事態になるコストと比べれば、先にやっておく方がはるかに合理的だ。

このアプローチを取る理由——私たちにとっての合理性

このアプローチを取る理由は、顧客のためだけではない。

私たち自身が、「作ったものが使われない」という経験を何度も見てきた。仕様書通りに作り、テストも通し、納品も完了した。しかし半年後に「あまり使われていません」と聞かされたときの虚しさは、受託開発に関わる人なら多くの人が知っているだろう。

前提の認知不一致を先に解消すれば、この事故を構造的に減らせる。手戻りが減り、作ったものが使われる確率が上がる。それは私たちにとっても、プロジェクトに関わるエンジニアにとっても、はるかに健全な状態だ。

Semantic SIの限界

正直に書いておくべきことがある。

Semantic SIは万能ではない。認知の前提を可視化するには、意思決定者がプロセスに参加する必要がある。現場担当者だけではデータの「使われ方」は語れても、「なぜその判断が必要か」の文脈は出てこない。権限者がプロセスに関与できない組織では、このアプローチは十分に機能しない。

また、定義の統一には組織的な合意が必要だ。「チャーンレート」の定義を1つに統一するということは、残りの2つの定義を使っていた部門に変化を求めるということだ。技術の問題ではなく、組織の問題になる。私たちはそこまでの合意形成を支援するが、最終的な決定は常にクライアントの経営層にある。

さらに、このアプローチが過剰なケースもある。仕様が明確で、関係部門が少なく、データの定義が既に統一されている場合は、従来型のSIの方が効率的だと私たちは考えている。

DXを始める前に、一つだけ確認してほしいこと

もしDXプロジェクトを検討しているなら、開発を始める前に一つだけ確認してほしい。

あなたの会社で「売上」という言葉は、全部門で同じ意味で使われているか。

もし答えに詰まるなら、前提のギャップはすでに組織の中に存在している。そして、その状態のまま数千万円のシステムを作っても、解決するのは表面だけだ。

DXプロジェクトの成否を分ける最も根本的な分水嶺は、技術でもベンダーでもなく、データの「意味」が組織の中で共有されているかどうかだ。

関連記事