情シスの働きが鍵？「つながらない権利」実現までの壁と対策を考える
本シリーズは、漫画を楽しんだ後に残る「で、これは自分の仕事だとどういうこと？」というモヤモヤを、実務の言葉に変換していく解説シリーズです。各話で起きたトラブルや決断をデータ活用・分析の目線で読み替え、現場で使えるヒントとして持ち帰れる形にしていきます。
まだ本編を読んでいない方は、先にこちらからどうぞ。↓
まずは、第6話の状況を整理してみます。漫画の中の出来事を職場での出来事に置き換えると、今起きていることの本質が見えてきます。
| 観点 | 漫画での出来事 | 職場での出来事に置き換えると |
| 何が起きた？ | 森の魔獣フンババが現れ、突然4体に分身した | 同じ顧客・企業・商品などのデータが複数存在している |
| 何が問題？ | 4体のうち、本物はひとつだけらしい | どのデータを正しい情報として扱えばいいのかわからない |
| どう動いた？ | イチが分身の1体を倒した | 重複していると思われるデータのひとつに対処した |
| さらに何が起きた？ | 残ったフンババが再び分身した | 重複が生まれる原因が残っていれば、同じ問題が繰り返される |
| 鍵は？ | ゼロが「データのまなざし」を使おうとする | 集計結果だけでなく、元になっているデータそのものに目を向ける |
第1章では、ゼロたちがデータ活用という新しい考え方に触れ、見えない課題に気づき、現場の声を拾い、集めた情報をつなぎながら次の一手へと変えていく姿が描かれました。
そして第6話から、第2章が始まります。第1章でゼロたちは、データを見ること、集めること、つなげること、そして行動に変えることを経験してきました。
でも、ここで新しい問題が出てきます。
そもそも、目の前にあるデータは正しいのか。
データを使えるようになったからこそ、次はデータそのものの状態に向き合わなければならない。第6話は、そんな次の段階へ進む回だと言えそうです。
第6話は、データの精霊プティとの契約を終えたゼロとイチが、アーチ村をあとにするところから始まります。第1章を通して探してきた「データの精霊」を、ついに仲間にすることができました。
これでギルドも変わる。そう考えてもよさそうですが、イチの表情は晴れません。「でもこのまま帰ったところで、ギルドが変わるとは思えない」。第5話の最後には、真の意味でデータを扱うための伝説の鍵「ラストマイル」という、新たな問いも提示されていました。
このイチの不安は、データ活用を提案した本人だからこそのものにも見えます。新しいやり方を提案する側は、導入すること自体が目的ではありません。「これで本当に現場は変わるのか」「かえって仕事を増やすだけにならないか」「使われないまま終わらないか」。提案したからこそ、その先まで気になってしまうものです。
これは仕事でもよくあります。データを集められるようになった。BIツールを導入した。CRMに顧客情報を集約した。ダッシュボードもできた。そこまで進むと、データ活用が一気に進みそうに思えます。
でも、実際に使い始めると、今度は別の疑問が出てきます。「この数字、本当に合っているのか？」「同じ顧客が何件も登録されていないか？」「部署によって見ている数字が違うのはなぜか？」。データを持っていなかったときには見えなかった問題が、データを使おうとしたからこそ見えてくるのです。
データ活用は、「データを手に入れること」で完成するわけではありません。むしろ、そこから何が見えてくるのか。第2章は、その先の冒険として始まります。
森を歩いていたゼロたちの前に、突然巨大な魔物が現れます。地面が揺れるほどの衝撃。姿を現したのは、森の魔獣フンババでした。
ゼロは以前にもフンババと戦ったことがあります。ところが、本来はもっと人里から離れた山奥に生息するはずの魔物が、なぜかこの森にいる。プティは「もしかして生態系が変化してきているのかもね」と話し、ゼロも魔神ブーカの影響を疑います。
知っている相手なのに、以前とは何かが違う。この感覚は、複数のデータを扱う仕事でもよくあります。
私自身、データを集めたり統合したりする中で、「同じものとして扱えると思っていたのに、実際にはそう簡単ではなかった」という場面に何度も出会ってきました。
たとえば、人名や会社名に旧字体・新字体、異体字が混在している。全角と半角が混ざっている。文字コードの違いによって文字化けしている。アンケート結果をまとめようとしたら、同じ「満足度」という項目なのに、片方は3段階評価、もう片方は5段階評価だった。
見た目には同じようなデータでも、作られた時期やシステム、入力ルールが違えば、そのままひとつにまとめられるとは限りません。
たとえば、3段階評価の「3」と5段階評価の「3」では意味が違います。項目名が同じだからとそのまま結合してしまえば、集計自体はできても、解釈を間違える可能性があります。
データを統合するときに必要なのは、きれいにひとつの表へまとめることだけではありません。「このデータは、どんなルールで作られたものなのか」まで見ることです。
フンババが本来の生息地とは違う場所に現れたように、知っているはずのものにも、以前とは違う前提が入り込んでいるかもしれない。データそのものを見るときにも、そんな違和感に気づく視点が必要になります。
そして、第6話の大きな転換点がやってきます。フンババが、突然4体に分身します。
見た目は同じ。どれも動く。どれもこちらに襲いかかってくる。ゼロとイチは手分けして戦い、イチは魔法剣で1体を消すことに成功します。
ここまでなら、「4体いるなら、4体とも倒せばいい」と思うかもしれません。でも、この状況を仕事に置き換えると、急に厄介さが見えてきます。
たとえば、CRMやMA（マーケティングオートメーション）などに、こんな会社名が登録されていたとします。
人が見れば、すべて同じ会社なのではないかと考えるでしょう。でも、システムにとっては文字列が違います。外部システムからデータを取り込んだり、CRMとMAを連携したりした結果、それぞれに別の顧客IDが発行されていれば、5社として扱われてしまうこともあります。
では、「データワールド株式会社」というデータが出てきたらどうでしょう。
単なる入力ミスなのかもしれない。でも、実際にその名前の別会社が存在するのかもしれない。会社名だけを見て「同じ会社だ」と決めてしまうのも危険です。住所、法人番号、電話番号、ドメイン、担当者、取引履歴など、ほかの情報も見ながら判断する必要があります。
こうした会社名や氏名の表記ゆれによって、同じ顧客が複数のデータとして登録されてしまうことは、顧客データを扱う現場では珍しいことではありません。
本当は1社なのに、顧客数は5社。売上や商談履歴も別々の顧客IDに分散する。本当は重要な顧客なのに、CRM上では小さな取引をしている複数社のように見えてしまう。MAでは同じ相手に似たメールが何度も送られてしまうかもしれません。
こうした、同じ対象を別々のデータとして持ってしまっている状態が、重複データです。
ここで怖いのは、集計できなくなることではありません。むしろ、普通に集計できてしまいます。顧客数も出る。顧客あたりの売上も出る。グラフも作れる。ただ、その前提になっているデータが重複していれば、出てきた数字と現実は少しずつズレていきます。
重複によって顧客数や顧客あたりの売上、商談数、LTVなどの見え方がズレれば、どの顧客を優先するのか、どの施策に予算を使うのかといった判断にも影響します。
重複データの怖さは、数字が出なくなることではありません。間違ったデータでも、それらしい数字が出てしまうことです。
だから、「数字が出たから正しい」とは限りません。フンババが4体見えているからといって、本当に4体の魔物が存在しているわけではない。第6話は、この厄介さをとてもわかりやすい形で描いています。
イチの攻撃によって、分身したフンババの1体が消えます。ところが、残ったフンババたちはそのまま動き続けます。
プティによると、分身した4体のうち、本物はひとつだけらしい。では、その本物だけを見つければいい。そう思ったところで、さらに厄介なことが起こります。フンババが、また分身したのです。
この場面は、重複データの問題を考えるうえでも象徴的です。
重複しているデータを見つけると、「同じものなら、まとめてしまえばいい」と考えたくなります。データの世界では、同じ人や会社だと考えられる複数のデータをひとつに整理する「名寄せ」や、データを統合する「マージ」といった作業を行います。
でも、本当に怖いのは、重複を残すことだけではありません。別のものを、同じものだと判断してしまうことです。
私自身、重複だと思ってデータをまとめたあとで、「これ、もしかして別の対象だったのでは」と気づき、冷や汗をかいた経験があります。こういう記憶は、重複データを見るたびに思い出します。
たとえば、同姓同名の別人をひとりの顧客としてマージしてしまえば、メールアドレスや電話番号、購入履歴まで混ざってしまいます。よく似た社名の別法人をまとめれば、商談履歴や売上もひとつになってしまう。あとから間違いに気づいても、「どの情報が誰のものだったのか」をもう一度切り分けるのは簡単ではありません。
だから名寄せは、単に似ている文字列を見つけてまとめる作業ではありません。
住所は同じか。電話番号はどうか。メールドメインは一致しているか。法人番号は同じか。更新日時はいつか。どのシステムから入ってきたデータなのか。複数の情報を見ながら、「これは本当に同じ対象なのか」を判断する必要があります。
そして、重複が起きた原因にも目を向けなければなりません。営業部とサポート部が別々のシステムで同じ顧客を登録している。データ移行のたびに既存顧客との照合をせず新しいIDを発行している。入力ルールが担当者によって違う。そうした状態のままでは、今日重複を解消しても、明日また新しい重複が生まれます。
さらに、どれか1件を「正しいデータ」として残せば済むとも限りません。Aのデータには新しい住所がある。Bには正しい電話番号がある。Cには過去の取引履歴が残っている。必要な情報が複数のレコードに散らばっていることもあります。
大切なのは、単にデータの数を減らすことではありません。同じものを正しく「同じもの」として扱える状態にすることです。
ゼロも、増え続けるフンババを前に立ち止まります。「まいったな どうしたらコイツを倒せ……」。そこで思い出したのが、自分には今、データの精霊プティがいるということでした。
「『データのまなざし』を使えば ヤツを倒す方法が見つかるはずだ！」
第2話では「データのまなざし」を使っても光が見えず、戸惑っていたゼロが、第6話では問題にぶつかったとき、自分からデータを見ようとしています。第1章を通した変化が、ここにも表れています。
ただし、第6話では「データのまなざし」を使った先に何が起こるのかまでは描かれていません。遠く離れたアーチ村では、ノイマンが「苦しんでいないと良いがな」「『データのまなざし』の洗礼に……」と意味深な言葉を口にします。
データを見れば、すぐに答えが出るのでしょうか。それとも、データを見るからこそ、新たに向き合わなければならないものがあるのでしょうか。その答えは、まだ先です。
第6話でゼロたちを苦しめたのは、ただ強い魔物ではありませんでした。同じ姿をしたフンババが複数存在し、どれが本物なのかわからない。しかも、ひとつ消しても、また増えてしまう。
これを仕事の現場に置き換えると、重複データの厄介さがよく見えてきます。
同じ顧客が複数登録されている。CRMとMAで別々の顧客IDがついている。システムを統合したら、同じ会社のデータが複数できた。部署ごとに持っている顧客情報が少しずつ違う。そして、どのデータを正しい情報として扱えばいいのか、すぐには判断できない。
こうした状態のまま分析を進めれば、元になるデータのズレが、その先の判断にも影響します。そして厄介なのは、その結果が必ずしも「明らかにおかしい数字」になるわけではないことです。
普通に集計できる。グラフもできる。それらしい結果も出る。
だからこそ、気づかないまま使ってしまうことがあります。
さらに今は、AIを使って大量のデータを整理・分析することも身近になりました。処理できるデータが増えたからこそ、その前に「何をひとつの顧客、ひとつの商品、ひとつの事実として扱っているのか」を確認する重要性は、むしろ高まっているのかもしれません。
派手な分析や新しいツールの前に、「このデータ、同じものを別々に数えていないだろうか」「逆に、別のものを同じものとしてまとめていないだろうか」「そもそも、なぜ重複が生まれたのだろう」と、一度立ち止まってみる。
第1章でゼロたちは、データを「見る」ためのまなざしを身につけました。そして第2章で最初に現れたのは、その先にある問いです。
見えているデータを、そのまま信じていいのか。
数字がきれいに並んでいるから正しいとは限らない。グラフが作れたから正しいとも限らない。
皆さんの職場にも、もしかすると「分身したフンババ」が潜んでいるかもしれません。まずは身近な顧客リストやCRMを見ながら、「同じ人や会社が、別々のデータとして存在していないだろうか」と確認してみる。
そこから、「データのまなざし」の次の冒険が始まるのかもしれません。
（執筆：尾﨑 元）
分身するフンババを前に、ゼロが頼ろうとしたのは「データのまなざし」。しかし、遠く離れたアーチ村では、ノイマンが「データのまなざしの洗礼」という意味深な言葉を口にしていました。
データを見ることで、ゼロたちは何に気づくのか。増え続けるフンババを攻略する糸口は見つかるのか。
お楽しみに！
最新話は、毎月25日に『データのじかん』と公式SNSで公開します。
気になったタイミングで、いつでも冒険を追いかけてください。
かつて仲間と共に魔王を倒し、冒険者ギルドを設立した男。いまは魔神ブーカとの戦いに苦戦し、これまでのやり方に限界を感じはじめている。
冒険者ギルドの現体制に限界を感じ、再建のために奮闘する勇者課のリーダー。「データ活用」という新しい力を、ゼロに提案する。
「見えざる魔物」との対峙の末に、ゼロたちの前に現れた精霊。数字やグラフだけではないデータの力を示しながら、見えない問題を見える化する手がかりへと、ゼロたちを導いていく。
2010年より、会社員と漫画家のパラレルワーカーとして活動。専門知識を「物語」に落とし込む、ストーリーテリングを活かしたビジネス漫画を制作している。著書に『マンガでわかる！幼稚園児でもできた!!タスク管理超入門』・『やる気クエスト』などがあり、累計ダウンロード数は15万を超える。自分をカード化してキャリア戦略に活かす『じぶんデッキ』を提唱・発信中。
X | Facebook | Instagram | note | stand.fm
ウイングアーク１ｓｔ株式会社 メディア事業室 室長。広告代理店でデザイン・アートディレクション・マーケティングを担当した後、上場企業や外資系IT企業での事業開発を経て、現在は同社で『データのじかん』・『情シスのじかん』・『UpdataTV』を統括。上智大学プロフェッショナル・スタディーズ、情報経営イノベーション専門職大学、SSH（スーパーサイエンスハイスクール）などで講師を務めるほか、東京大学大学院博士課程でセレンディピティを研究している。
LastResort合同会社 CEO／マーケティングテクノロジスト／クリエイティブディレクター。国内外の上場企業からスタートアップまで、企業のマーケティングをテクノロジーとクリエイティブで整える。2023年に同社を設立。2026年、AI時代におけるアートの再定義をテーマに、アート支援事業「LastResort Mecenat」を始動。
メルマガ登録をしていただくと、記事やイベントなどの最新情報をお届けいたします。
学びをシェアする
30秒で理解！インフォグラフィックや動画で解説！フォローして『1日1記事』インプットしよう！
デジタル・DX・データにまつわる4コマ劇場『タイムくん』 
データのじかんをもっと詳しく データのじかんフィーチャーズ 
「47都道府県47色のDXの在り方」を訪ねる『Local DX Lab』 
DXの1次情報をを世界から 『World DX Journal』 
データで越境するあなたへおすすめの 『ブックレビュー』 
BIツールユーザーによる、BIツールユーザーのための、BIツールのトリセツ 
CIOの履歴書 by 一般社団法人CIOシェアリング協議会 
なぜ、日本企業のIT化が進まないのか――日本のSI構造から考える 
日本ビジネスの血流である帳票のトレンドを徹底解説 
データを武器にした課題解決家「柏木吉基」のあなたの組織がデータを活かせていないワケ 
BI（ビジネスインテリジェンス）のトリセツ 
入社1年目に知っておきたい 差が付くKPIマネジメント 
CIOLounge矢島氏が紐解く トップランナーたちのDXの“ホンネ” 
データのじかん Resources 越境者のためのお役立ち資料集 AI実装の現在地点-トップITベンダーの捉え方 
データでビジネス、ライフを変える、 面白くするDATA LOVERS 
データマネジメント・ラジオ by データ横丁 データのじかんNews 
データ・情報は生もの！ 『DX Namamono information』 ちょびっとラビット耳よりラピッドニュース 
AI事務員宮西さん（データ組織立ち上げ編） 藤谷先生と一緒に学ぶ、DXリーダーのための危機管理入門 
生情報取材班AI時代に逆行？ヒトが体感した「生情報」のみをお届け！ 
データはともだち 〜怖くないよ！by UpdataTV Original 
データ飯店〜データに携わるモノたちの2.5thプレイス by UpdataTV〜 
インサイトーク〜データで世界を覗いてみたら〜by WingArc1st + IDEATECH 
データの壁を越え、文化で繋ぐ。データ界隈100人カイギ データ越境者に寄り添うメデイア「データのじかん」が提供する便利ツールです。
本ツールは、JavaScriptを用いてお客様のブラウザ上で処理を行います。サーバーとの通信は行われず、入力データはお客様のみの端末内で処理されます。
