問屋さんが、なぜPOSを見るのか
私は今、ある商社さんに、週に1日出航しています。
最初に不思議に思ったのは、なぜ問屋がPOSデータ——お店のレジを通った記録——を欲しがるのか、でした。仕入れて卸す商売なら、自社の出荷データを見れば足りそうなものです。
理由は、その会社がPB（プライベートブランド）の開発を請け負っていたからでした。
小売のお店の棚に並ぶ、その店の名前がついた商品。あれを企画して、形にするところまでやっている。だとすると見るべきは自社の出荷ではなく、お店で実際に何がいくつ売れたか、の方です。棚の前で起きていることが見えないと、次に何を作るかが決められない。
要件定義の前に、何に困っているのかを聞いた
いきなり要件定義には入りませんでした。まず、何に困っているのかを聞く時間を取ります。ここは急ぎません。ここで外すと、後の全部が外れるので。
出てきたのは、大きく2つでした。
ひとつは、POSデータを持っている（買っている）のに、分析しきれていないこと。データは届いている。ただ量が多くて形もばらばらで、開いて整えるところで一日が終わってしまう。結果として、PBの開発案が「たぶんこれが売れるだろう」の勘に寄っていく。的確な案が出せなくなれば、そのまま収益の細りにつながります。
もうひとつは、すでに世に出した商品が、前年の数字を超えられない状態が続いていたことです。作った後を振り返る材料がないと、次の一手も前の年の焼き直しになりやすい。
PBは、当たれば大きい。外れれば在庫として残る。ここが鈍ると、じわじわ効いてきてしまう。
最初のご要望は「資料づくりの自動化」だった
そのうえでいただいたご要望は、はっきりしていました。
提案書やプレゼン資料の作成を、自動化してほしい。
分析の結果を、お店に持っていける形にするまでに時間がかかっている。だからそこを仕組みで巻き取ってほしい、という話です。切実さはよく分かりました。
ただ、聞きながら僕が思っていたのは別のことでした。
そこは、生成AIを少し工夫して使うだけで、だいたい足ります。
わざわざ開発するところではありません。資料を作る機能を基盤の中に抱え込むと、作るときにも直すときにも費用がかかり続けます。それなら、いまある道具の使い方を現場に渡した方が早いし、後から自分たちで変えられる。
なので、その部分は機能から外しました。同じように「あった方が良さそうだけれど、目的には効かない」ものを一つずつ落としていった結果、最初にお出しした見積もりを1/3に落としました。
自分の売上を3分の1にする話なので、迷わなかったと言えば嘘になります。ただ、僕自身も小さな会社で判こを押す側に座っているので、効くかどうか分からない金額の紙を前にする、あの落ち着かない時間は知っているつもりです。あれを短くしたかった。
逆に、生成AIでは無理だと分かったところ
削る一方で、はっきり逆の答えが出た部分がありました。
土台になるPOSの分析です。
POSは、とにかく量が多いデータかつ機密性のあるデータです。ひとつの商品が、ひとつのお店で、一日に何個売れたか。これが一行になります。商品の数と、店舗の数と、日数を掛け合わせると、行数はあっという間に人が開ける量を超えます。
市場全体の動きを見るデータなら、買えば手に入ります。ただ、それは競合も同じものを見ているので、そこから出てくる話はどうしても浅くなる。差がつくのは、取引先のPOSを自分たちで扱えたときです。
そして、ここが肝でした。POSは、取れたとしても、そのままでは扱えません。そもそもデータセキュリティ的にも扱えない。
生成AIにまるごと渡して分析してもらう、ということができない量です。工夫の余地はほとんどありませんでした。整えて、集めて、意味のある単位にまとめる——この部分は、作らないとどうにもならない。
「これはAIでは無理です」とはっきり言えたことが、この案件では大きかったと思っています。できないと分かるのは、後ろ向きな結論ではありません。探す範囲がひとつ減ったということなので。無理な部分がはっきりしたからこそ、そこに開発を入れる判断ができました。
枝葉は生成AIで足りる。土台は作らないと無理。この2つが対で出てきたので、どこにお金を置くかが決まりました。
AIに何を期待するかを、先に揃えた
開発に入る前に、もうひとつやったことがあります。
AIへの期待値を揃えることです。
AIは、100個の作業を全部100点でこなす道具ではありません。得意なところでは人よりずっと速くて、苦手なところでは平気で外します。ここが曖昧なまま作り始めると、動いた後に「思っていたのと違う」が必ず出てくる。
なので要件定義の場で、できることとできないことを一つずつ分けて置きました。
そこでもう一つ、混ざりやすいものも分けました。「やりたいこと」と「できるようになること」は、同じではない、ということです。
やりたいことは希望から出てきます。できるようになることは、いま手元にあるデータと業務の形から決まります。この2つを重ねたまま話すと、要件がふくらんで、金額もふくらむ。分けて並べると、「今回できるようになること」と「次の段階で取りにいくこと」に自然と収まります。また、人間がやりたいことをできるようにする補助をすることがAIであり、やりたいことを一気通貫でできるようになるわけではないですよね。AGは魔法のように見えて実は人間が思うような魔法ではないということをしっかりと認識させました。
この整理を先にやったので、開発が始まってからの手戻りはほとんどありませんでした。期待値を下げたのではなくて、期待の置き場所を決めた、という感覚に近いです。
「分析したい」の下から出てきたもの
そして、いちばん大事なものが最後に出てきました。
なぜ分析したいのかを掘っていったときに出てきたのは、「レポートをきれいにしたい」ではありませんでした。
取引先の要望に応えるだけの立場から、自分たちから提案できる立場になりたい。
言われたものを仕入れて納める。それも大切な仕事です。ただそれだけだと、話はどうしても価格に寄っていく。そうではなく「御社の棚なら、次はこれが効くと思います」と自分から言える問屋でありたい、と。
これを聞いて、作るものの形が決まりました。
問屋には、その会社にしか集まらないものがあります。競合の動き。複数のメーカーから届く分析データ。取引先ごとの棚の事情。そこに、取引先のPOSを重ねる。自社の中だけで完結しないデータの重ね方ができるのは、間に立っている会社だけです。
そうして出てきた分析は、他の誰かが同じ精度では出せません。PBの開発案も、勘ではなく、重なった事実の側から立てられるようになる。土台が整っていれば、その分析を資料の形にするところは、生成AIで足ります。
いちばん効いたのは、技術だった
いま振り返ると、この案件で効いたのは技術でした。
ただ、効かせる場所を決めるまでの順番の方が、たぶん大事だったと思っています。
もし最初のご要望どおり、資料という成果物から入っていたら、資料を作る機能を開発して終わっていました。そうではなく、その下にある土台のデータをどう扱いたいのかから入ったので、どこが工夫で足りて、どこは技術を入れないと無理なのかが見えた。
見積もりを削れたのも、技術の話が分かるからです。どこは作らなくていいかを言えるのは、どこは作らないと無理かが分かる人だけなので。
もし、いま手元に見積もりがあって、これでいいのか決めきれずに止まっているなら。並んでいる機能を眺める前に、その下にあるデータを自分たちがどう扱いたいのかを、一度だけ言葉にしてみるといいかもしれません。そこが決まると、削れる場所と、削ってはいけない場所が分かれてきます。
