データ基盤の内製化をお勧めしない理由っていう話ですね。
これ先に言っとくと完全にポジショントークです。
パスコアレコードのポジショントークです。
本心からデータ基盤の内製化をお勧めしないので、その理由を話そうかと思ってます。
一方で最初にデータ基盤の内製化をすべきケースについて話しちゃおうかなと思ってます。
そうですよね。データは資産だから内製化すべきみたいな考え方もあると思うんですけど、
向いてる向いてない側って向いてるケースから教えてもらえると。
向いてるケースの1個目は規模が1000億以上とか大きくて、
自社独自のデータ基盤構築することで投資を回収できる企業はやったほうがいいと思ってます。
やっぱシステム投資の金額って売り上げのだいたい1から2%ぐらいなんですよね。
上場企業、IR見てると。
1000億の企業であれば1%であれば10億の投資。
2%であれば20億の投資ができるので、これだけ予算あると取れる選択肢も豊富。
かつ自社で内製化したり、こういうのが足りないからやっていこうよっていうところが
かなり柔軟にできる金額感かなと思っているので、いいのかなと思います。
なるほど。
一方で売り上げ規模小さくなればなるほど、この売り上げに対するパーセンテージの使える費用ってどんどん小さくなるので、
システムと開発、内製化で取れる選択肢がだいぶ減っちゃうなっていうところが
1個目の内製化すべき理由の裏返しのところですね。
これは分かりますね。売り上げが大きくて、それなりの独自データ活用が向いてるっていうのも分かるなって感じです。
2個目はシステム事業を立ち上げて外販するようなケースですね。
どういうケースかっていうと、ネクストエンジンさんってもともとハミーっていう会社の社内システムでスタートして
外販することで主要事業の1つとなりましたみたいな形で、
小売事業をやっているものの経営として将来的にはこういうシステム事業を立ち上げて、
SaaSを立ち上げて外販していくみたいな、そういったところを施行するケースは内製化してもいいんじゃないかなと思ってます。
ハミーさんって私、なんでiFace売ってるんだろうと思ってたけど、そっちがスタートなんですね。
逆なんですよ。iFaceを売っている中で苦労したこと、在庫の管理であったり複数のモールの管理をしていくっていうためにスタートして、
でも今遠隔張ってますけど、2007年に社内稼働を開始して2008年の5月にもう売り始めているんで、
もともと売るつもりで構築したんだろうなっていうのがこれ見ると伺えますね。
うん、確かに。
やっぱ自社の困りごとを解決することがどうしても今あるSaaS、ストアレコードではどうしてもできない。
でもここを責めればもっと困ってる人の解決につながるよね。
で、IT事業立ち上げてやっていきたい場合には内製化もありだろうなっていうのは思います。
でもそういうケースは稀だと思うんで。そうすると大規模でもないし、IT事業展開を目指していない場合はお勧めしないってことなんですね。
そうですね。基本的にはお勧めしてないです。高いし、難しいし、やりきれないんですよね。
結構相談も受けますけど、この3つの理由でお勧めしていなくて。
1個目、データ基盤の構築の難易度って相当高いと思います。
どこまでをデータ化の対象にするかっていうスコープの設計。
どこまでをデータ化していくかっていう売り上げだけでいいのか。
発注とか納品なんかの仕入れも入れるのか。
在庫の転換移動のための履歴も入れるのか。
在庫も入れるのか。あとは費用も入れるのかみたいな感じで。
どこまでを対象にして要件定義を行ってシステム化していくのかっていうのを考えるだけでも、
かなり難易度高いなと思ってます。
業務の大部分をスプレッドシートとかでデータ化していて、
じゃあこれを一旦はシステム化すればいいやって考えたとしても、
それも結構大変だなっていう感じですね。
そんなよくわかってないんですけど、スプシをそのままシステム化すればいいっていう単純なことではなさそうですね。
スプシ上でやってるかわかんないんですけど、
例えば、税率計算とかってまあまあややこしいんで、
これをゼロから構築するかどうか、
まあ税率は無視してもいいんだっていう形にするかどうかみたいなのを意思決定するのも大変ですと。
税率計算の仕組みって僕らも入れたんですけど、そこそこ大変でやっぱり。
経験のある開発会社さんでも大変だし、経験なかったら相当大変かなというふうに思います。
お勧めしない理由の2つ目としては、開発費用とラーニング費用が高くなりますよっていうところですね。
作って終わりじゃないし、そもそも作るのに開発費用で、
僕自身全職ペアマノンの時は内製化というか、他になんかいい感じのデータ基盤がなかったんで、
構築しようと思って、最初僕がやろうかなと思ったんですよね。
一社目の時はRuby on Railsとかやってたんで。
ただもう相当錆びついてるしわかんないなと。
じゃあビッグクエリーとか使えばなんか簡単にできるらしいなっていうのでビッグクエリー見たんですけど、
ちんぷんかんぷんだったんですよね。
で、これは何かと思って、そうは言っても費用がないから、
ワンテッドリーで副業エンジニアの方をお願いして、
その方結構優秀だったんで、こういうのやりたいみたいなので作ってくれたんですけど、
税率計算とか全く入れずに売り上げと在庫と発注の管理をするシステムを作ったんですけど、
それでもやっぱり1000万ぐらいかかりましたかね。
そうなんだ。
という感じで、まずはそもそもの開発コストが結構かかりますよと。
さらに外注してしまうと、その外注会社に対する保守運用の費用がかかるし、
例えばあとはZOZOTOWNで提供しているデータのカラムが変わりました、
なんていう時には開発が必要になるんで、
結構継続的なメンテナンス開発の工数と費用がかかるなっていう形です。
周りの環境に合わせて進化していかなきゃいけないっていうのもあると思うんですけど、
かつその各機能を作って、それの運用コストみたいなのも考えるとすごい大変そうですね。
そうなんですよね。組み合わせてデータ基盤を構築するっていうのが普通になっているんで、
ビッグクエリと前話しましたけど、ETLって呼ばれるトロッコとか、
そういうサースを組み合わせて使ったとしても、結構気が付くと大きいコストになってるっていうこともあり得ますと。
ビッグクエリだけだとそんなにかかんないんだけれども、ETLの部分で数十万かかってしまう。
で、BIのツールの流し込みの方にも結構かかってしまうみたいな形で、
費用がかかるのと、そもそもこれを内製化してやろうとすると、
自社内にそれをできる人、エンジニアないしPDMみたいな人の人件費がかかるので、
そこは別途数十万円から百万円単位でかかってきてしまうっていうのが、
二つ目の費用がかかるっていうところですね。
三つ目は適切な開発会社を見つける難易度がものすごい高いかなと思ってます。
やっぱりデータ基盤を構築するってなると、データを自動で収集する部分、
ETLっていうトロッコさんみたいなのが担当している部分と、
データをためるデータウェアハウス、ビッグクエリとかスノーフレークとかが担当する部分と、
データを可視化するBIツールと呼ばれる機能のそれぞれの部分の開発がいりますよと。
これらを一貫してやっている会社ってなかなかないんじゃないかなと思っていて、
データ基盤を専門にしている会社さんっていうのがあるかもしれないんですけれども、
そういったところを見つけてお願いして、
さらに予算感があって引き受けてもらうっていうところが結構大変かなと思ってます。
よくあるあるが自社EC、ショーピファイ構築してますみたいなときに、
ショーピファイの構築会社さんにデータ基盤を依頼しようみたいな形のケースがあるんですけれども、
これ全く別の専門領域だなっていうところなので、
自社ECを構築できるからといってデータ基盤を構築できるがイコールじゃないので、
ここが難しいかなと思います。
やっぱり構築会社さんだと小売の専門的な知識もないケースが多くて、
売上総利益とは、限界利益とは、在庫日数とは、在庫回転率とはみたいな、
こういった指標を適切に扱うとか、そこの計算式をロジックに組み込むみたいなところに、
結構苦労されるんじゃないかなとは思います。
確かに、小売の専門性が必要となると結構むずそうだし、
でもこれ自宅企業側はできますって言っちゃいそうですよね。
多分言っちゃうでしょうね。
そんな感じがする。
山野さんもやってたように、それでも自前でやりたいっていう企業さんもいるかなと思うんですけど、
そしたらどうするんですか。
そしたらですね、フルスタックのエンジニアを内製化しましょうっていうのが結論になるかなと思ってます。
データ基盤をしっかり構築できて、データベースの知識が詳しくて、
BIとのつなぎ込み、デザインはできないけれども、そこらのロジックについては自分で実装できるみたいな、
そういう人を1名雇うのが失敗しない最低条件みたいなところかなとは思ってます。
ただそういうのがしっかり構築できるフルスタックのエンジニアさんって、
年収1000万で取れるんだっけっていうレベルだと思うんで、
そこの費用対効果はよく考えた方がいいかなとは思いますね。
基本的に考え方としては、このシステム構築の部分が自社の競争要因につながるのかどうかっていうのを考えて、
つながるなら採用すべきだけれども、基本的に多くの公立企業にとってはシステムが優れてるっていうことよりも、
商品力が優れていることが競争要因につながるので、システムはSaaSの組み合わせで作って、
ある程度社内で分かる人が1名いて、そこをサポートしてくれればなんとかなるっていう設計の方が適してるのかなと思ってます。
しかもエンジニアだけを内製化してもあんまり意味がなくて、
プロダクトマネージャーって呼ばれるこのやりたいことを紙砕いて、
エンジニアに要件定義として渡して、プロダクトとして担保するみたいな人も、
もしエンジニアとスムーズに会話できる方が経営人とか社内のリーダーにいないとしたら、
そういう人も合わせて取らないといけないので、そうするとまた月額のランニング費用っていうのはかなり高くなってしまうと。
ここに投資してまでやるべきかどうかっていうところは、
結構それはストアレコード使ったらもっと安くできますよっていう提案をかなりいっぱいしてます。
今私エンジニア採用やってますけど、エンジニアそんなシュッと採用できないですからね。
僕らも苦労してるんですけど、シュッと採用できないじゃないですか、そもそも優秀な人を。
本当にエンジニア採用にもコストがかかりますからね。
そうなんですよね。そこに年収の35から場合によっては45とか、結構もっとかかるんですよね。
多分このスカウトバイトじゃない、エージェントだと。
ここが見合うかはよく考えてほしいなっていうのは思ってますね。
そうですね。確かにそこにお金投資するぐらいだったら、ブランドづくりとかマーケティングとかもあるし、
その投資する選択肢も他にあるわけで、エンジニア内製化ってなると、またそれはそれで多分俗人化しちゃったりとか、
そういう話も出てきそうで、確かにそのデータ基盤の内製化は見極める必要がありそうだなという感じを受けました。
そもそもなんでストアレコード開発したかっていうと、僕自身、電子職ペアマーノンっていう中小企業をやっていて、
同じようにデータ基盤の構築で困ってる会社ものすごいいるだろうなと思ったんですよね。
そういう売上10億とか20億ぐらいの会社さんがこの金額なら払ってもいいよねっていう金額で、
パッとデータの自動収集、データウェアハウス、BIツールっていうのがパッと作れるっていうところを目指してやってますと。
やっぱり費用感的にもそこまで負担のある金額ではないかな、その規模感の会社さんであれば。
重量課金、売上規模に応じた課金で、ここまでだったら経営者だったら投資判断として払うだろうみたいな金額でやっているので、合うんじゃないかなと勝手に思ってますと。
最近だと前回でも話した通り、AIエージェントとのつなぎ込みっていう強力な機能っていうのもリリースできそうなので、
そうするとデータ基盤が整っているからAIにやって構築できますっていう、AI自体に即した業務フローの構築っていうのもできるようになります。
AIレディになりますっていうところで選択してもらえるといいなと思って作ってますと。
さらにぶっちゃけものすごいプロダクトに自信ができてきたんで、データ基盤構築している会社さんにはデータ基盤構築するのものすごい年数かかると思うんで、
まずはストアレコード試しましょうと。お試し期間も与えるので、この期間で満足しなかったらもうそこで打ち切りでいいですと。
一方でやってみて内製化しなくていいじゃんってなったら、気に入ってもらったら使ってくださいと。
やっぱり内製化したいってなったら、このストアレコードの構成っていうのがそのままデータ基盤構築するときに役立つんで、
悪く言うと満足いかなかったらパクって改良してくださいっていう営業をしてます。
パクっていいんですね。
パクれるものならっていうあれはありますけどね。
ものすごい参考にはなると思います。こういうデータを入れていて、こういう管理をしていて、こういうカラムでデータ入れないといけないんだ、
めんどくさいなストアレコードでいいなっていう風になるのが、たぶん1回入れてもらえればなると思うんで、それを目指してます。
すごい、いい自信です。
ちょっとね、だいぶできました。
いや、めちゃくちゃいいことです。
ありがとうございます。