ROI事件ファイル No.314｜『Koike社の見えない知識』

第一章:分断という迷宮——探すのに1日、見つからない

AquaCallのKPT事件が解決した翌週、今度は千葉から化学品卸企業の情報管理に関する相談が届いた。第二十六巻「再現性の追求」の第314話は、バラバラのデータベースを意味で繋ぎ、探す時間を考える時間に変える物語である。

「探偵、我々の社内には6つのデータベースがあります。顧客情報、在庫情報、製品仕様、過去の取引記録、クレーム履歴、技術資料……。しかし、部署ごとに管理されていて、横断検索ができません。営業が『過去にこの製品をどの顧客に納入したか』を調べるのに、丸1日かかります」

Koike Data Systems社 の情報システム部長、市川出身の小池誠一は疲弊しきった表情でベイカー街221Bを訪れた。彼の手には、6つのシステムの構成図と、それとは対照的に「検索できず」と記された業務効率化プロジェクトの報告書が握られていた。

「我々は千葉で化学品・工業薬品の卸売業を営んでいます。製造業、研究機関、大学向けに、約8,000種類の化学品を扱っています。従業員は62名。しかし、情報が部署ごとに分断されています」

Koike社の情報検索停滞: - 設立:1985年(化学品卸) - 年間売上:38億円 - 従業員数:62名 - 取扱製品数:約8,000種類 - データベース数:6つ(部署ごとに独立) - 平均検索時間:1件あたり2.5時間 - 月間検索依頼:約180件 - 問題:部署間でデータが共有されず、意思決定が遅延

小池の声には深い焦りがあった。

「問題は、各部署が独自にデータベースを構築してきたことです。営業部は『顧客DB』、物流部は『在庫DB』、技術部は『製品仕様DB』……。それぞれが異なるシステム、異なる命名規則で管理しています。横断検索しようにも、データの形式が違いすぎて統合できません」

典型的な検索の困難:

ある日の営業担当者Aさん:

顧客から問い合わせ: 「5年前に貴社から購入した『触媒X』と同じ性能の製品はありますか? できれば価格を抑えたいのですが」

営業Aさん: 「分かりました。調べてお返事いたします」

検索作業開始(午前10:00):

ステップ1:過去の取引記録を調べる(営業部の顧客DB) - システムにログイン - 顧客名で検索 - 5年前の取引を探す - 発見:「触媒X、製品コード:CAT-2018-45」

ステップ2:製品仕様を調べる(技術部の製品仕様DB) - 別のシステムにログイン - 製品コード「CAT-2018-45」で検索 - 結果:「該当なし」

Aさん: 「おかしい……なぜ見つからない?」

技術部に電話: 「すみません、CAT-2018-45の仕様を教えてください」

技術部担当者: 「CAT-2018-45? うちのシステムには『CAT2018-45』(ハイフンなし)で登録されています。命名規則が違うんです」

Aさん: 「……そうですか」

ステップ3:製品仕様を確認(ハイフンなしで再検索) - 発見:「触媒X、主成分:白金、純度95%、粒径1μm」

ステップ4:類似製品を探す(製品仕様DBで条件検索) - 条件:「主成分=白金」「純度≧90%」「粒径≦2μm」 - 結果:28件ヒット

ステップ5:価格を調べる(物流部の在庫DB) - また別のシステムにログイン - 28件それぞれの価格を確認 - 所要時間:1時間

ステップ6:過去のクレーム履歴を確認(品質管理部のクレームDB) - 28件のうち、過去にクレームがあった製品を除外 - 所要時間:30分

検索完了(午後2:30) 所要時間:4.5時間

Aさんは疲弊しきった。

「やっと見つけた……。でも、こんなに時間がかかるなんて……」

第二章:形式という壁——データは繋がらず、知識は眠る

「小池さん、これまでに、データベースの統合を試みたことはありますか?」

私の問いに、小池は答えた。

「2年前に試みました。6つのDBを1つの統合DBに移行しようとしました。しかし、失敗しました。データの形式、命名規則、項目名……全てが異なりすぎて、統合できなかったのです。費用も1,200万円かかると見積もられ、断念しました」

現在のアプローチ(統合型): - 対策:全DBを1つに統合 - 問題:コストが高く、技術的に困難 - 結果:断念

私は情報の再構成の重要性を説いた。

「統合する必要はありません。繋げばいいのです。LOGIC——Link、Observe、Group、Interpret、Connect。データの形式を変えずに、意味で繋ぐ。これが、情報検索の本質です」

⬜️ ChatGPT｜構想の触媒

「統合するな。繋げ。LOGICでデータを意味で結べ」

🟧 Claude｜物語の錬金術師

「探す時間を減らすことは、考える時間を増やすこと。情報は繋がって初めて知識になる」

🟦 Gemini｜理性の羅針盤

「LOGICは情報再構成の技術。Link・Observe・Group・Interpret・Connectの5段階で、問いの質を上げよ」

3人のメンバーが分析を開始した。Geminiがホワイトボードに「LOGICフレームワーク」を展開した。

LOGICの5ステップ: 1. Link(関連付け):データ項目間の関連をマッピング 2. Observe(観察):検索ログを分析し、利用傾向を把握 3. Group(分類):属性ごとにクラスタリング 4. Interpret(解釈):自然言語で意味ベース検索 5. Connect(接続):結果をBIに接続し、即レポート化

「小池さん、Koikeの6つのDBを、LOGICで再構成しましょう」

第三章:関連という地図——バラバラのデータに橋を架ける

Phase 1:Link(関連付け) - データ項目のマッピング(4週間)

まず、6つのDBの項目を洗い出し、関連を整理した。

6つのDB: 1. 営業部:顧客DB(顧客情報、取引履歴) 2. 物流部:在庫DB(製品コード、在庫数、価格) 3. 技術部:製品仕様DB(製品コード、主成分、純度、粒径) 4. 品質管理部:クレームDB(製品コード、クレーム内容) 5. 経理部:売上DB(顧客、製品、売上額) 6. 総務部:技術資料DB(製品、PDF資料)

問題点: - 製品コードの命名規則が異なる - 営業DB:「CAT-2018-45」(ハイフンあり) - 技術DB:「CAT2018-45」(ハイフンなし) - 在庫DB:「CAT/2018/45」(スラッシュ区切り) - 顧客名の表記揺れ - 営業DB:「株式会社ABC製作所」 - 経理DB:「(株)ABC製作所」 - クレームDB:「ABC製作所」

関連マッピングの作成:

製品コードの正規化ルールを定義:

CAT-2018-45 = CAT2018-45 = CAT/2018/45
→ 全て「CAT201845」に正規化して検索

顧客名の正規化ルールを定義:

株式会社ABC製作所 = (株)ABC製作所 = ABC製作所
→ 全て「ABC製作所」に正規化して検索

関連テーブルの作成: - 製品コード関連テーブル:各DBの製品コードを相互変換 - 顧客名関連テーブル:各DBの顧客名を相互変換

4週間後: 6つのDB間の関連マッピング完成

Phase 2:Observe(観察) - 検索ログの分析(2週間)

次に、過去6ヶ月の検索ログを分析した。

検索ログ分析の発見:

よく検索される組み合わせ: 1. 「製品名」+「顧客名」(42%) 2. 「製品名」+「仕様」(28%) 3. 「顧客名」+「取引履歴」(18%) 4. 「製品名」+「クレーム」(8%) 5. その他(4%)

検索の目的: - 見積作成のため(38%) - 顧客問い合わせ対応のため(32%) - 在庫確認のため(18%) - クレーム調査のため(12%)

発見: 営業部の検索が全体の68%を占める。製品と顧客の情報を横断的に調べるニーズが高い。

Phase 3:Group(分類) - 属性ごとのクラスタリング(2週間)

製品を属性ごとに分類し、類似製品を自動的にグルーピングした。

製品の分類軸: - 主成分(白金、パラジウム、酸化物……) - 用途(触媒、研磨剤、溶媒……) - 純度(90%以上、95%以上、99%以上……) - 価格帯(1万円未満、1〜5万円、5万円以上……)

クラスタリング結果: 8,000製品を約80のグループに分類

例: - グループ12:「白金系触媒、純度95%以上、価格2〜4万円」(製品数:38) - グループ23:「酸化物研磨剤、粒径1μm以下、価格5千円未満」(製品数:52)

Phase 4:Interpret(解釈) - 自然言語検索の実装(3ヶ月)

自然言語で検索できる仕組みを構築した。

従来の検索(形式検索):

製品コード:CAT-2018-45
主成分:白金
純度:≧95%

新しい検索(意味検索):

「5年前に納入した白金触媒と同じ性能で、価格が安いもの」

AIによる解釈: 1. 「5年前に納入した」→ 取引履歴DBから該当製品を検索 2. 「白金触媒」→ 主成分=白金、用途=触媒 3. 「同じ性能」→ 純度・粒径が近い製品 4. 「価格が安い」→ 価格が低い順にソート

検索結果: - 該当製品:「CAT-2023-12」(白金触媒、純度94%、粒径1.2μm、価格28,000円) - 元の製品:「CAT-2018-45」(白金触媒、純度95%、粒径1.0μm、価格35,000円) - 価格差:7,000円安い(20%削減)

Phase 5:Connect(接続) - BIツールとの連携(1ヶ月)

検索結果を即座にレポート化できる仕組みを構築した。

BIツール(Tableau)との連携: - 検索結果をワンクリックでグラフ化 - 「この製品の過去5年の売上推移」 - 「この顧客の購入製品トップ10」 - 「クレーム発生率の高い製品ランキング」

第四章:意味という力——4.5時間が5分に変わる

6ヶ月後の成果:

検索時間の劇的削減:

Before: 営業Aさんが「5年前の触媒Xと同じ性能で価格が安い製品」を探す: - 6つのDBを個別に検索 - 所要時間:4.5時間

After: 同じ検索を統合検索システムで実行: - 自然言語で入力:「5年前の触媒Xと同じ性能で価格が安い製品」 - AIが自動的に6つのDBを横断検索 - 結果表示:5分 - 削減率:98%

営業Aさんの1日の変化:

Before: - 検索作業:1日3件 × 平均2.5時間 = 7.5時間 - 顧客対応:0.5時間 - 提案書作成:ほぼゼロ

After: - 検索作業:1日10件 × 平均5分 = 50分 - 顧客対応:3時間 - 提案書作成:4時間

営業Aさんの声: 「以前は、検索だけで1日が終わっていました。今は、検索は5分。空いた時間で、顧客に提案書を作れます。売上も上がりました」

組織全体の成果:

業務効率: - 月間検索依頼:180件 - 従来の総検索時間:180件 × 2.5時間 = 450時間/月 - 新システムでの総検索時間:180件 × 5分 = 15時間/月 - 削減時間:435時間/月(97%削減)

営業成果: - 提案書作成数:月30件 → 月120件(+300%) - 成約率:15%(変わらず) - 月間成約数:4.5件 → 18件(+300%) - 平均受注額:850万円 - 月間売上:3,825万円 → 1億5,300万円(+300%)

財務効果: - 投資:統合検索システム開発2,800万円 - 年間売上増:約12億円 - 投資回収期間:2.8ヶ月

意思決定の質の向上:

経営会議での活用:

社長: 「今期、売上が好調な製品は?」

小池(情報システム部長): 統合検索システムで即座に検索: 「白金系触媒が前年比+42%です」

社長: 「その顧客層は?」

小池: ワンクリックでBIレポート表示: 「自動車部品メーカーが68%を占めています」

社長: 「では、自動車向けの新製品を開発しよう」

従来なら、このデータ収集に2週間かかっていた。今は5分。

第五章:探偵の診断——問いの質が意思決定を変える

その夜、LOGICの本質について考察した。

Koike社は、6つのDBに知識が眠っていた。バラバラのデータは、単独では価値を生まない。しかし、意味で繋がった瞬間、知識に変わった。

LOGICで情報を再構成したことで、検索時間は98%削減された。そして、空いた時間は顧客対応と提案書作成に使われた。

「探す時間を減らすことは、考える時間を増やすこと。LOGICが、データを知識に、知識を戦略に変える」

次なる事件もまた、LOGICが情報の価値を解放する瞬間を描くことになるだろう。

「統合するな、繋げ。形式ではなく意味で結べ。LOGICが、バラバラのデータを知識に変える」——探偵の手記より

関連ファイル