1. リテールトーク / RETAIL TALK - 中小小売経営のリアル -
  2. データ基盤の内製化をお勧めし..
データ基盤の内製化をお勧めしない理由
2026-06-20 17:17

データ基盤の内製化をお勧めしない理由

中小小売企業におけるデータ分析基盤の内製化に潜むリスクと、ストアレコードのような外部SaaSを活用するメリットを解説します。自社開発に伴う莫大な開発・保守コストや、軽減税率・按分計算といった小売特有の複雑なデータ設計を自社で行う難しさを指摘します。ストアレコードのように、各カートやPOS、倉庫システムを滑らかに連携し、安価に精緻な利益管理環境を構築できるシステムの有効性については話しました。
■MC紹介
樋口幸太郎 / 山梨県甲府市出身。ストアレコード株式会社代表取締役。新卒で伊藤忠商事入社→就職活動生向けWebメディアで起業→人材系ベンチャー企業にM&Aで売却→子供服D2Cブランド「pairmanon」運営会社の取締役就任→アダストリアグループにM&Aで売却。
小売企業向け経営データ一元管理SaaS「ストアレコード」提供中
⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://service.storerecord.jp/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠
戸部祐理 / 株式会社HERP HR / アパレル企業で取締役 → アパレル×ITスタートアップ → デジタルマーケ支援企業HR・PR → 現職 / 11年在籍したアパレルでは店舗現場からバイイング、ブランド立ち上げ、バックオフィスにも広く携わり5年間取締役

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

本エピソードでは、中小小売企業がデータ基盤を内製化することの難しさとリスクについて解説します。大規模な投資が可能な企業や、システム事業化を目指す場合を除き、内製化は開発・保守コストの高さ、小売特有の複雑なデータ設計の難しさ、適切な開発会社の選定の困難さから推奨されないと指摘します。代わりに、ストアレコードのような外部SaaSを活用することで、より安価かつ効率的に精緻な経営データ管理環境を構築できるメリットを強調しています。

オープニングとドンキでの買い物体験
この番組は、中小小売企業の取り締まり役経験のある2人が、 そのリアルについて緩くお話しします。
人事に軸足を置いたジェネラリスト、私戸部有利が、 インドのM&A経験がある連続企業家、樋口幸太郎さんに話を聞いていきます。
既に小売企業を経営している方、これから小売ビジネスで 企業を考えられている方に役立つ情報を楽しく語っていきます。
リテールトーク116回目です。よろしくお願いします。
お願いします。
今日はデータ基盤の内製化をお勧めしない理由というお話です。
この間ですね、地元に急遽帰らなきゃいけないということが起こって、 ごたんだのオフィスに行ったんで、そのまま品川行って、
オフィスにいるバッグだけを持って地元、 私三重県なんですけど三重県に帰ったんですね、新幹線で。
で、ちょっと泊まることになったんで、服が必要だっていうので、 その時に空いてるのがドンキだけだったんで、ドンキ法庭に行ったんですよ。
で、ドンキで初めて服を買うっていう経験をしたんですけど、 結構面白くて、ドンキ法庭行きます?行きます?っていうか、大人になってから行ったことあります?
大人になってからで言うと、子供と花火買いに行くぐらいで、ちょろちょろと行ってます。
ただ僕、大学生の頃新宿に住んでたんで、
あ、そうなんだ。
そうなんですよ。
新宿歌舞伎町のドンキはパーティーグッズを仕入れるのと、
あと当時金のない貧乏学生だったんで、
食料品とかを買ってた記憶がありますね。
おお、ていうかそうなんだ。
私、あのドンキの隣の隣ぐらいのビルで働いてましたよ。
ものすごいど真ん中じゃないですか。
そう、でしかも、
歌舞伎町の。
麻雀のアルバイト先が焼肉屋さんで、
5階が焼肉屋で、
6階がジャンソーで、
ジャンソー行っちゃうって前にお話したあれです。
はいはい。
そこなんですね。
ものすごい通ってましたよ、多分学生の時。
ちょっとじゃあ、かすってるかもしれないですね。
今度見てみます。
新宿行く機会があったら。
多分もうお店ないと思うんですけど、
そう、あの辺にいました。
なんでそうですね、ドンキは結構、
学生の頃は行ってたけど直近ではほとんど寄らないですかね。
そう、私もあんまり行く機会なかったんですけど、
この間行ったらすごい楽しいなと思って、
端から端まで見たくなりました。
何が楽しかったですか、ラインナップですかやっぱ。
そう、今子どもがシールにハマってるんで、
ぷくぷくシールみたいなやつとかも、
めっちゃあるんですよ、とにかくキラキラしたのが。
ガーって思ったらコスメ、もう流行りのコスメがブワーってあったりとか、
香水もブワーってあったりとか、
とにかく物の量が多いのが楽しくて、
端から端までちょっと時間潰したいです、あれは。
まさにあの侵略方法ですよね、ドンキならではの。
今度行く頻度が増えるかもしれないですね、じゃあ。
ちょっと時間があったら行きたいなと思った。
ドンキのアパレルはどうなんですか、服は。
だから無くて、黒いTシャツに黒いスウェットで、
たまたま私オフィスサンダルだったんですよ。
だからすごいヤンキーみたいな格好で新幹線乗って帰ってきました。
山梨の伊沢温泉のドン協定になんかいたような気がしますね。
ドン協定もそんな感じなんじゃないかなっていう。
キティちゃんのブツブツのサンダルでしたよね、昔のヤンキー。
なんか覚えがあるかもしれないですね。
健康サンダルか。
我々世代の。
問題いきたいと思います。
データ基盤内製化を推奨するケース
データ基盤の内製化をお勧めしない理由っていう話ですね。
これ先に言っとくと完全にポジショントークです。
パスコアレコードのポジショントークです。
本心からデータ基盤の内製化をお勧めしないので、その理由を話そうかと思ってます。
一方で最初にデータ基盤の内製化をすべきケースについて話しちゃおうかなと思ってます。
そうですよね。データは資産だから内製化すべきみたいな考え方もあると思うんですけど、
向いてる向いてない側って向いてるケースから教えてもらえると。
向いてるケースの1個目は規模が1000億以上とか大きくて、
自社独自のデータ基盤構築することで投資を回収できる企業はやったほうがいいと思ってます。
やっぱシステム投資の金額って売り上げのだいたい1から2%ぐらいなんですよね。
上場企業、IR見てると。
1000億の企業であれば1%であれば10億の投資。
2%であれば20億の投資ができるので、これだけ予算あると取れる選択肢も豊富。
かつ自社で内製化したり、こういうのが足りないからやっていこうよっていうところが
かなり柔軟にできる金額感かなと思っているので、いいのかなと思います。
なるほど。
一方で売り上げ規模小さくなればなるほど、この売り上げに対するパーセンテージの使える費用ってどんどん小さくなるので、
システムと開発、内製化で取れる選択肢がだいぶ減っちゃうなっていうところが
1個目の内製化すべき理由の裏返しのところですね。
これは分かりますね。売り上げが大きくて、それなりの独自データ活用が向いてるっていうのも分かるなって感じです。
2個目はシステム事業を立ち上げて外販するようなケースですね。
どういうケースかっていうと、ネクストエンジンさんってもともとハミーっていう会社の社内システムでスタートして
外販することで主要事業の1つとなりましたみたいな形で、
小売事業をやっているものの経営として将来的にはこういうシステム事業を立ち上げて、
SaaSを立ち上げて外販していくみたいな、そういったところを施行するケースは内製化してもいいんじゃないかなと思ってます。
ハミーさんって私、なんでiFace売ってるんだろうと思ってたけど、そっちがスタートなんですね。
逆なんですよ。iFaceを売っている中で苦労したこと、在庫の管理であったり複数のモールの管理をしていくっていうためにスタートして、
でも今遠隔張ってますけど、2007年に社内稼働を開始して2008年の5月にもう売り始めているんで、
もともと売るつもりで構築したんだろうなっていうのがこれ見ると伺えますね。
うん、確かに。
やっぱ自社の困りごとを解決することがどうしても今あるSaaS、ストアレコードではどうしてもできない。
でもここを責めればもっと困ってる人の解決につながるよね。
で、IT事業立ち上げてやっていきたい場合には内製化もありだろうなっていうのは思います。
でもそういうケースは稀だと思うんで。そうすると大規模でもないし、IT事業展開を目指していない場合はお勧めしないってことなんですね。
データ基盤内製化を推奨しない3つの理由
そうですね。基本的にはお勧めしてないです。高いし、難しいし、やりきれないんですよね。
結構相談も受けますけど、この3つの理由でお勧めしていなくて。
1個目、データ基盤の構築の難易度って相当高いと思います。
どこまでをデータ化の対象にするかっていうスコープの設計。
どこまでをデータ化していくかっていう売り上げだけでいいのか。
発注とか納品なんかの仕入れも入れるのか。
在庫の転換移動のための履歴も入れるのか。
在庫も入れるのか。あとは費用も入れるのかみたいな感じで。
どこまでを対象にして要件定義を行ってシステム化していくのかっていうのを考えるだけでも、
かなり難易度高いなと思ってます。
業務の大部分をスプレッドシートとかでデータ化していて、
じゃあこれを一旦はシステム化すればいいやって考えたとしても、
それも結構大変だなっていう感じですね。
そんなよくわかってないんですけど、スプシをそのままシステム化すればいいっていう単純なことではなさそうですね。
スプシ上でやってるかわかんないんですけど、
例えば、税率計算とかってまあまあややこしいんで、
これをゼロから構築するかどうか、
まあ税率は無視してもいいんだっていう形にするかどうかみたいなのを意思決定するのも大変ですと。
税率計算の仕組みって僕らも入れたんですけど、そこそこ大変でやっぱり。
経験のある開発会社さんでも大変だし、経験なかったら相当大変かなというふうに思います。
お勧めしない理由の2つ目としては、開発費用とラーニング費用が高くなりますよっていうところですね。
作って終わりじゃないし、そもそも作るのに開発費用で、
僕自身全職ペアマノンの時は内製化というか、他になんかいい感じのデータ基盤がなかったんで、
構築しようと思って、最初僕がやろうかなと思ったんですよね。
一社目の時はRuby on Railsとかやってたんで。
ただもう相当錆びついてるしわかんないなと。
じゃあビッグクエリーとか使えばなんか簡単にできるらしいなっていうのでビッグクエリー見たんですけど、
ちんぷんかんぷんだったんですよね。
で、これは何かと思って、そうは言っても費用がないから、
ワンテッドリーで副業エンジニアの方をお願いして、
その方結構優秀だったんで、こういうのやりたいみたいなので作ってくれたんですけど、
税率計算とか全く入れずに売り上げと在庫と発注の管理をするシステムを作ったんですけど、
それでもやっぱり1000万ぐらいかかりましたかね。
そうなんだ。
という感じで、まずはそもそもの開発コストが結構かかりますよと。
さらに外注してしまうと、その外注会社に対する保守運用の費用がかかるし、
例えばあとはZOZOTOWNで提供しているデータのカラムが変わりました、
なんていう時には開発が必要になるんで、
結構継続的なメンテナンス開発の工数と費用がかかるなっていう形です。
周りの環境に合わせて進化していかなきゃいけないっていうのもあると思うんですけど、
かつその各機能を作って、それの運用コストみたいなのも考えるとすごい大変そうですね。
そうなんですよね。組み合わせてデータ基盤を構築するっていうのが普通になっているんで、
ビッグクエリと前話しましたけど、ETLって呼ばれるトロッコとか、
そういうサースを組み合わせて使ったとしても、結構気が付くと大きいコストになってるっていうこともあり得ますと。
ビッグクエリだけだとそんなにかかんないんだけれども、ETLの部分で数十万かかってしまう。
で、BIのツールの流し込みの方にも結構かかってしまうみたいな形で、
費用がかかるのと、そもそもこれを内製化してやろうとすると、
自社内にそれをできる人、エンジニアないしPDMみたいな人の人件費がかかるので、
そこは別途数十万円から百万円単位でかかってきてしまうっていうのが、
二つ目の費用がかかるっていうところですね。
三つ目は適切な開発会社を見つける難易度がものすごい高いかなと思ってます。
やっぱりデータ基盤を構築するってなると、データを自動で収集する部分、
ETLっていうトロッコさんみたいなのが担当している部分と、
データをためるデータウェアハウス、ビッグクエリとかスノーフレークとかが担当する部分と、
データを可視化するBIツールと呼ばれる機能のそれぞれの部分の開発がいりますよと。
これらを一貫してやっている会社ってなかなかないんじゃないかなと思っていて、
データ基盤を専門にしている会社さんっていうのがあるかもしれないんですけれども、
そういったところを見つけてお願いして、
さらに予算感があって引き受けてもらうっていうところが結構大変かなと思ってます。
よくあるあるが自社EC、ショーピファイ構築してますみたいなときに、
ショーピファイの構築会社さんにデータ基盤を依頼しようみたいな形のケースがあるんですけれども、
これ全く別の専門領域だなっていうところなので、
自社ECを構築できるからといってデータ基盤を構築できるがイコールじゃないので、
ここが難しいかなと思います。
やっぱり構築会社さんだと小売の専門的な知識もないケースが多くて、
売上総利益とは、限界利益とは、在庫日数とは、在庫回転率とはみたいな、
こういった指標を適切に扱うとか、そこの計算式をロジックに組み込むみたいなところに、
結構苦労されるんじゃないかなとは思います。
確かに、小売の専門性が必要となると結構むずそうだし、
でもこれ自宅企業側はできますって言っちゃいそうですよね。
多分言っちゃうでしょうね。
そんな感じがする。
内製化する場合の代替案とSaaS活用の推奨
山野さんもやってたように、それでも自前でやりたいっていう企業さんもいるかなと思うんですけど、
そしたらどうするんですか。
そしたらですね、フルスタックのエンジニアを内製化しましょうっていうのが結論になるかなと思ってます。
データ基盤をしっかり構築できて、データベースの知識が詳しくて、
BIとのつなぎ込み、デザインはできないけれども、そこらのロジックについては自分で実装できるみたいな、
そういう人を1名雇うのが失敗しない最低条件みたいなところかなとは思ってます。
ただそういうのがしっかり構築できるフルスタックのエンジニアさんって、
年収1000万で取れるんだっけっていうレベルだと思うんで、
そこの費用対効果はよく考えた方がいいかなとは思いますね。
基本的に考え方としては、このシステム構築の部分が自社の競争要因につながるのかどうかっていうのを考えて、
つながるなら採用すべきだけれども、基本的に多くの公立企業にとってはシステムが優れてるっていうことよりも、
商品力が優れていることが競争要因につながるので、システムはSaaSの組み合わせで作って、
ある程度社内で分かる人が1名いて、そこをサポートしてくれればなんとかなるっていう設計の方が適してるのかなと思ってます。
しかもエンジニアだけを内製化してもあんまり意味がなくて、
プロダクトマネージャーって呼ばれるこのやりたいことを紙砕いて、
エンジニアに要件定義として渡して、プロダクトとして担保するみたいな人も、
もしエンジニアとスムーズに会話できる方が経営人とか社内のリーダーにいないとしたら、
そういう人も合わせて取らないといけないので、そうするとまた月額のランニング費用っていうのはかなり高くなってしまうと。
ここに投資してまでやるべきかどうかっていうところは、
結構それはストアレコード使ったらもっと安くできますよっていう提案をかなりいっぱいしてます。
今私エンジニア採用やってますけど、エンジニアそんなシュッと採用できないですからね。
僕らも苦労してるんですけど、シュッと採用できないじゃないですか、そもそも優秀な人を。
本当にエンジニア採用にもコストがかかりますからね。
そうなんですよね。そこに年収の35から場合によっては45とか、結構もっとかかるんですよね。
多分このスカウトバイトじゃない、エージェントだと。
ここが見合うかはよく考えてほしいなっていうのは思ってますね。
そうですね。確かにそこにお金投資するぐらいだったら、ブランドづくりとかマーケティングとかもあるし、
その投資する選択肢も他にあるわけで、エンジニア内製化ってなると、またそれはそれで多分俗人化しちゃったりとか、
そういう話も出てきそうで、確かにそのデータ基盤の内製化は見極める必要がありそうだなという感じを受けました。
そもそもなんでストアレコード開発したかっていうと、僕自身、電子職ペアマーノンっていう中小企業をやっていて、
同じようにデータ基盤の構築で困ってる会社ものすごいいるだろうなと思ったんですよね。
そういう売上10億とか20億ぐらいの会社さんがこの金額なら払ってもいいよねっていう金額で、
パッとデータの自動収集、データウェアハウス、BIツールっていうのがパッと作れるっていうところを目指してやってますと。
やっぱり費用感的にもそこまで負担のある金額ではないかな、その規模感の会社さんであれば。
重量課金、売上規模に応じた課金で、ここまでだったら経営者だったら投資判断として払うだろうみたいな金額でやっているので、合うんじゃないかなと勝手に思ってますと。
最近だと前回でも話した通り、AIエージェントとのつなぎ込みっていう強力な機能っていうのもリリースできそうなので、
そうするとデータ基盤が整っているからAIにやって構築できますっていう、AI自体に即した業務フローの構築っていうのもできるようになります。
AIレディになりますっていうところで選択してもらえるといいなと思って作ってますと。
さらにぶっちゃけものすごいプロダクトに自信ができてきたんで、データ基盤構築している会社さんにはデータ基盤構築するのものすごい年数かかると思うんで、
まずはストアレコード試しましょうと。お試し期間も与えるので、この期間で満足しなかったらもうそこで打ち切りでいいですと。
一方でやってみて内製化しなくていいじゃんってなったら、気に入ってもらったら使ってくださいと。
やっぱり内製化したいってなったら、このストアレコードの構成っていうのがそのままデータ基盤構築するときに役立つんで、
悪く言うと満足いかなかったらパクって改良してくださいっていう営業をしてます。
パクっていいんですね。
パクれるものならっていうあれはありますけどね。
ものすごい参考にはなると思います。こういうデータを入れていて、こういう管理をしていて、こういうカラムでデータ入れないといけないんだ、
めんどくさいなストアレコードでいいなっていう風になるのが、たぶん1回入れてもらえればなると思うんで、それを目指してます。
すごい、いい自信です。
ちょっとね、だいぶできました。
いや、めちゃくちゃいいことです。
ありがとうございます。
エンディング
今日はデータ基盤の内製化をお勧めしない理由という話でした。
ありがとうございます。
はい、ありがとうございます。
ディテールトーク、ここまでお聞きいただきありがとうございます。
番組の詳細欄にGoogleフォームのURLがあるので、質問やメッセージはそちらからお送りいただけると嬉しいです。
番組内でご紹介させていただくかもしれません。
次回もぜひよろしくお願いします。
17:17

コメント

スクロール