1:47 - 3:50

Foundry：集中したデータから顧客成果へ

この章の要点

この章では、講演者が説明する Palantir の Foundry を手がかりに、データ基盤（data platform）がどのように顧客の仕事を支えるかを見ます。大切なのは、データを一か所に集めること自体が最終目的ではない、という点です。

顧客が本当に欲しいのは、データが整理された状態ではなく、そのデータを使って仕事の成果を出すことです。たとえば、商品を適切な棚に置くことや、販売の流れを速くすることです。そこで講演者は、ソフトウェア製品だけでなく、顧客の事情を理解して実装するサービスも組み合わせる考え方を説明します。

Foundryを三つの層で考える

講演者の簡略化した説明では、Foundryは組織のデータを集め、意味を整理し、その上にアプリケーションを作るためのソフトウェア・プラットフォームです。ここでいうプラットフォームとは、個別の一つの画面だけではありません。複数の顧客や用途で使える、共通の技術的な土台です。

流れを簡単に書くと、次のようになります。

組織内に分かれているデータを集める
そのデータに、業務上の意味を与える
意味のあるデータを使ってアプリケーションを作る
アプリケーションで顧客の業務上の成果を出す

1. 分かれている表を集める

企業のデータは、最初から一つの形になっているとは限りません。販売、在庫、顧客、物流などの情報が、別々の表やシステムに保存されていることがあります。同じ商品を指していても、システムごとに名前やIDが違うかもしれません。

講演者は、こうした複数の表を一つの場所に集め、組織全体で参照できる 唯一の信頼できる情報源（single source of truth） を作る、というイメージを示します。これは、全員が同じデータを見て判断できるようにするためです。

ただし、「一つの場所に置く」だけでは、まだ業務の意味が十分に分かりません。数字が集まっていても、それがどの商品を指すのか、どの顧客や注文と関係するのかが明確でなければ、利用者はそのまま仕事に使えません。

2. 業務上の対象に名前を付ける

そこで使われるのが オントロジー（ontology） です。この講演での簡略化された意味では、オントロジーはデータの中にある業務上の対象に、名前と関係を与える仕組みです。たとえば、「商品」「店舗」「注文」「顧客」といった対象を識別し、それらがどう結び付くかを扱います。

ここで注意が必要です。講演者は、Foundryの実際のデータ構造や、オントロジーのすべての専門的な意味を説明していません。この章で扱うのは、ばらばらの表を業務で理解しやすい対象として整理する、という説明の範囲です。

例（説明のための例）：

在庫の表にある A-17 を「商品A」として扱う
店舗の表にある S-03 を「東京の店舗」として扱う
「商品Aが東京の店舗に何個あり、最近どれだけ売れたか」を同じ関係の中で見る

この例で重要なのは、単に列を追加することではありません。利用者が「商品」や「店舗」という業務の言葉でデータを考えられるようになることです。これにより、技術的な表の違いを毎回読み解かなくても、次のアプリケーションを作りやすくなります。

3. アプリケーションを作る

整理されたデータと業務上の対象の関係があれば、その上にアプリケーションを作れます。アプリケーション層（application layer）とは、データを表示したり、分析したり、業務の手順を実行したりする部分です。

たとえば、店舗ごとの在庫と販売状況を表示する画面を作れます。その画面は、在庫の表、販売の表、店舗の表を利用者が手作業で突き合わせる代わりに、すでに整理された情報を使います。ここでアプリケーションは、データ基盤の上に作られる具体的な仕事の道具です。

データの整理は、まだ顧客の成果ではない

ここからが講演者の中心的な指摘です。データを整理し、唯一の信頼できる情報源を作ることには価値があります。しかし、顧客が購入を決める理由は、普通は「データがきれいに整理されるから」だけではありません。

顧客は、その整理されたデータを使って、業務上の問題を解決したいと考えます。講演者は例として、商品をどの棚に置くか、販売の処理量や流れをどう増やすか、といった成果を挙げています。つまり、顧客が求めるのは次のような変化です。

データが一つに集まる → 業務上の対象と関係が分かる → 使えるアプリケーションが動く → 顧客の業務上の成果が改善する

この最後の矢印がなければ、プラットフォームの機能を導入しただけで終わる可能性があります。データを集めることは手段であり、顧客が評価するのは、その手段によって仕事がどう変わったかです。

顧客が負う「導入の負担」

プラットフォームに機能があっても、顧客がすぐに成果を得られるとは限りません。講演者は、顧客がプラットフォームの料金を支払い、使い方を学ぶための研修を行い、その後で初めて、社内の人が役に立つアプリケーションを作れる、という負担を指摘します。

この負担を、ここでは 導入の負担（adoption tax） と呼びます。税金という文字が示すのは、製品の価格以外にも、導入に必要な時間や労力があるという比喩です。顧客が負うものには、少なくとも次の要素があります。

プラットフォームを購入する費用
データを準備し、組織の事情に合わせる時間
社員が使い方や作り方を学ぶための研修
実際のアプリケーションや業務フローを作る人手

研修を用意するだけでは、この負担は消えません。研修を受けた人が、自分の業務を理解しながら、データを正しく扱い、必要なアプリケーションを完成させなければならないからです。特に、技術的に深いプラットフォームでは、機能を知っていることと、顧客の業務で成果を出せることは同じではありません。

例（教師による例）：

ある小売企業が、在庫と販売のデータをまとめるプラットフォームを購入したとします。社員が研修を受けても、どの商品をどの店舗へ移すべきかを判断する画面が自動で完成するわけではありません。社員はデータの意味を確認し、店舗の業務を理解し、画面や処理を作る必要があります。もしその作業を進められる人がいなければ、データが整理されても、棚の配置や販売の改善にはつながりません。

この例は、講演者の構造を説明するための教師作成の例です。特定の顧客で実際にこの結果が出た、という主張ではありません。

製品、サービス、成果をどう組み合わせるか

この話では、三つの売り方を区別すると理解しやすくなります。

ソフトウェア製品を売る

製品としては、データを集め、意味を整理し、アプリケーションを作れるプラットフォームを提供します。これは再利用できる技術的な土台です。しかし、顧客がその土台から自分で成果を作れるとは限りません。

作業する人の時間を売る

反対に、顧客ごとに人を送り、顧客のための作業を行うだけなら、技術者の労働を提供する形に近くなります。この方法は顧客の事情に対応しやすい一方で、毎回一から作ると、後で保守しにくくなります。これは、単純な開発会社や受託開発に近いモデルです。

顧客の業務上の成果を届ける

顧客が欲しいのは、通常、製品そのものでも作業時間そのものでもなく、その結果としての業務上の成果です。講演者が説明する考え方は、製品とサービスを組み合わせ、その成果を実現しようとします。

プラットフォームは共通の技術的基盤を提供します。サービス側の人は、顧客の業務を理解し、必要な設定やアプリケーション作りを進めます。こうして、顧客は「使い方を学んで自分たちだけで作る」ことを最初から完全に求められません。同時に、提供側も、顧客ごとに別の技術基盤を作る必要がありません。

したがって、このモデルは「ソフトウェアだけ」でも「人を貸すだけ」でもありません。再利用可能な製品の土台と、顧客の状況に合わせて実装するサービスを組み合わせるモデルです。後の章では、このサービスを担う顧客対応のソフトウェアエンジニアが、どのように働くかを詳しく見ます。

よくある誤解

誤解1：整理されたデータがあれば、価値は自動的に生まれる

データが一つの場所にあり、対象の名前が付いていても、顧客の業務が自動で改善するわけではありません。利用者が必要なアプリケーションを作り、そのアプリケーションを実際の業務で使う必要があります。データ基盤は重要な土台ですが、成果そのものではありません。

誤解2：研修をすれば、顧客は自力で導入できる

研修は導入を助けます。しかし、顧客の業務知識と、プラットフォームを使って実装する力の両方が必要です。顧客が何を改善したいのかを具体化し、適切なデータを結び付け、実際の仕事で使える形にするところまでが課題になります。

誤解3：顧客ごとの作業は、すべて受託開発である

顧客に合わせた実装があるからといって、必ず一から別のシステムを作るわけではありません。講演者の説明では、共通のプラットフォームがあるため、その上に顧客向けの解決策を作ります。サービスの個別性と、技術基盤の再利用性を両立させる点が重要です。

この章で確認できること

講演者の説明を、次の因果関係としてまとめられます。

組織のデータは、複数の表やシステムに分かれている。
Foundryのようなプラットフォームは、データを集め、業務上の対象と関係を整理する。
整理されたデータの上に、顧客の仕事で使うアプリケーションを作る。
顧客が望むのは、整理そのものではなく、棚の配置や販売の流れなどの業務上の成果である。
その成果まで届けるには、製品だけでなく、顧客の業務を理解して実装するサービスが必要になる場合がある。

ここで述べた顧客例や価値の説明は、講演者の説明に基づくものです。Foundryの実際のアーキテクチャや、個々の顧客での成果を、この講演だけから詳しく検証することはできません。次章では、どのような製品と顧客の組み合わせで、このような顧客対応エンジニアリングが必要になるのかを見ていきます。