「全サービスをひとつに」と打ち出したダスキンが、社内では顧客を一人として見られていなかった話｜SEとして歩んだ30年を振り返る⑧-1

「ダスキンの全サービスを、ひとつの番号でご利用ください」

テレビCMでそう打ち出した会社が、社内では同じお客様をブランドごとにバラバラに管理していた。

このギャップを解決するのが、私たちの仕事だった。

前回の続き

前回はワールドのアパレル物流システムの話をした。

1990年代に入り、私のキャリアは少し違う種類の仕事へ向かった。個別システムを作るのではなく、会社全体のシステム開発の「基盤」を設計するという仕事だ。

ダスキンという会社の構造

ダスキンはフランチャイズビジネスを主軸にした企業だ。

事業の柱は大きく三つ——レンタル・サービス・フード。この三本柱のそれぞれに、約10ブランドずつのフランチャイズビジネスが展開されていた。

レンタル事業では家庭向けの掃除用品や床材のレンタル。サービス事業ではハウスクリーニングや害虫駆除などの生活サービス。フード事業ではミスタードーナツをはじめとした飲食フランチャイズ。

これだけ多様な事業を、それぞれのブランドが独立して展開していた。そしてそこに問題の種があった。

「100・100」キャンペーンが露わにした問題

当時、ダスキンはテレビCMで「100・100（ひゃく・ひゃく）」サービスを打ち出していた。

「ダスキンの全サービスを、ひとつの番号でご利用ください」——という趣旨のキャンペーンだ。

レンタルを使っているお客様に、ハウスクリーニングも紹介できる。サービスを使っているお客様に、関連商品をご案内できる。一人のお客様に、ダスキンのあらゆるブランドの価値を届ける——そういうビジョンだった。

ところが実際には、これができなかった。

なぜか。ブランドごとにシステムが完全に独立していたからだ。

レンタル事業の顧客情報はレンタルのシステムにある。ハウスクリーニングの顧客情報はサービス系のシステムにある。ミスタードーナツの会員情報はフード系のシステムにある。

「この方はレンタルのお客様です」はわかる。でも「この方がすでにハウスクリーニングもご利用かどうか」は、会社全体として把握できない。

100・100キャンペーンで「全サービスをひとつに」と打ち出しながら、社内では顧客を「ひとつ」として見られていなかった。

なぜそうなったのか——データサイロの構造

これは当時のシステム開発の典型的な問題だ。

事業ごと、ブランドごとに「このシステムが必要だ」という要件が生まれ、それぞれが個別に開発される。担当するエンジニアも、使うデータ構造も、管理する部門も別々だ。

一つひとつのシステムは機能する。でも横につながらない。

現代では「データサイロ」と呼ぶ。当時はそういう言葉はなかったが、現象はまったく同じだ。

ダスキンの場合、三つの事業柱に十ブランドずつ——合計で多数のシステムが乱立していた。「同じお客様」を会社全体として認識する仕組みが、そもそも存在していなかった。

解決策——「データを先に設計する」という発想の転換

このプロジェクトで私たちが採用したのが、データ中心アプローチ（DOA：Data Oriented Approach）だ。

当時の主流はプロセス中心アプローチ（POA）だった。発想はシンプルだ——「業務の流れ（プロセス）をまず定義して、そのプロセスに必要なデータを設計する」。受注処理があるから受注テーブルを作る、という考え方だ。

この考え方でシステムを作り続けると、どうなるか。各業務に特化した「島」がいくつも生まれる。島の中では機能するが、島と島はつながらない。データが重複し、矛盾が生まれ、統合しようとすると莫大なコストがかかる。

DOAはこれを逆転させる。

「まずデータを設計する。プロセスはその後だ」

会社全体を横断する統一的なデータモデルを先に作る。「顧客とは何か」「商品とは何か」「取引とは何か」——これを会社全体で統一して定義する。その上に個々のシステムを乗せていく。

こうすることで、レンタルのシステムもサービスのシステムも、「同じ顧客定義」を共有できる。同一人物が複数ブランドを利用していれば、それが一人のお客様として見えてくる。

開発標準という成果物

このプロジェクトの具体的な成果物は「開発標準書」だ。

個別のシステムを作ることではなく、今後ダスキンが開発するすべてのシステムが従うべきルールと手順を定めること——それがこのプロジェクトのゴールだった。

これは今まで経験してきた仕事とは、性質が根本的に違う仕事だった。

「作る」ではなく「決める」。

全社に適用されるルールを決めるには、各ブランドの担当者・各システムの開発者・経営層——それぞれを説得しなければならない。技術を作るだけでなく、組織を動かす必要があった。

「システムは変わる。データは残る」

このプロジェクトを通じて、私は一つの確信を得た。

システムは変わる。データは残る。

業務プロセスは経営判断や市場の変化によって変わる。あるシステムが廃止されることもある。しかしデータそのものは、事業の歴史として残り続ける。

だからこそ、データ設計を先に、丁寧に行う必要がある。場当たり的に作られたデータ構造は、後から修正するときに莫大なコストがかかる。正しく設計されたデータ基盤は、新しいシステムを乗せる土台になり続ける。

2026年に見ると——DXとAIの本質は変わっていない

現代のDX議論で「データガバナンス」「データマネジメント」「マスターデータ管理」という言葉が頻繁に使われる。

これらは本質的に、DOAが30年前に問いかけていたことと同じ問題だ。

「全社でデータを統一的に管理する基盤をどう作るか」——この問いは1990年代から変わっていない。

そして今、AIがデータを食べて価値を生む時代になった。良質なデータ基盤があるかどうかで、AIの活用可能性が大きく変わる。

ダスキンで取り組んだ問題は、むしろ今の方が切実になっていると感じる。

まとめ

• ダスキンは「100・100キャンペーン」で全サービス統合を打ち出したが、ブランドごとの顧客データサイロが障壁に

• 解決策としてデータ中心アプローチ（DOA）を採用——まず全社横断のデータ基盤を設計し、その上にシステムを構築する

• 成果物は個別システムではなく「開発標準書」——以後の全開発が従う設計原則を策定

• 「システムは変わる。データは残る」——この原則は今のDX・AI時代にもそのまま通用する

次回⑨-1では、初めての公開入札——ゴールデンウィーク全日出勤で10億円の提案書を作った話を書く。

あなたに聞いてみたい

「情報がバラバラで、横につながらない」という問題、あなたの職場や日常で感じたことはありますか？

会社のシステムでも、チームのツールでも、家庭の情報管理でも。「サイロ化」の問題はあらゆる場所にあります。ぜひコメントで教えてください。

元大手SIerのSE。50代で退職後、両親の認知症介護に5年間専念。現在は在宅でのAIエージェントビジネス構築に取り組み中。

#SE #システムエンジニア #ダスキン #データ中心アプローチ #DOA #データサイロ #DX #1990年代 #50代 #データガバナンス #AI活用