1. リテールトーク / RETAIL TALK - 中小小売経営のリアル -
  2. プログラミング経験が小売企業..
2024-10-12 26:45

プログラミング経験が小売企業経営に活きたこと

起業した1社目で学んだプログラミングが小売企業の経営にどう活きたのか、特にデータベース設計・業務の標準化に大きく役立った話をしました。


樋口幸太郎: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/happytarou0228⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

戸部祐理: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/yuuritobe⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠


■リテールトーク質問・メッセージフォーム

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://docs.google.com/forms/d/e/1FAIpQLSePaafkg7l4K-cm-SSZkQZGYJFfT4xscc6eH_3ws-xTCVKohA/viewform⁠⁠

サマリー

このエピソードでは、プログラミングの経験が小売企業の経営にどのように役立つかを話します。特に、独学でプログラミングを学び、内製化を進めることでビジネスを成長させた経験が強調されます。また、プログラミングの経験が経営に役立つ具体的な事例が多数紹介されます。RPAを活用した業務の自動化やデータ管理の重要性、さらにシステム化や標準化の過程について詳しく解説しています。プログラミングの経験を活かして、業務の標準化やシステム化の重要性が強調されており、この過程でエンジニアとの協力によって効率的な業務プロセスが構築されます。

プログラミング経験の重要性
この番組は、中小小売企業の吊り締まり役経験のある2人が、 そのリアルについて緩くお話しします。
人事に軸足を置いたジェネラリスト、私砥部有利が、 2度のM&A経験がある連続企業家、樋口幸太郎さんに話を聞いていきます。
既に小売企業を経営している方、これから小売ビジネスで 企業を考えられている方に役立つ情報を楽しく語っていきます。
リテイルトーク第34回になりました。よろしくお願いします。
今日はですね、プログラミング経験のお話をしたいなと思っているんですけど、 プログラミングってやりたかったなってずっと思っていて、
でもなんかまだやれるかな、みたいな気持ちもちょっとあって、って考えると、 子供に習わせて一緒に勉強すればいいじゃん、みたいなのもちょっと思ってたと。
で、習い事、今はプログラミングとかありますけど、何やってました?って聞こうと思って。
あんまりやってなくてですね、子供の頃空手を習わせられて、すぐ辞めたり、みたいな、そういうのしかなくて。
小学校の高学年ぐらいから塾に行って、中学も行ってて、そのぐらいですかね。
塾さんが空手やってるイメージないですね。
いやもう苦痛でしょうがなかったです。夜も制作させられるし、ちょっと昭和の香りが残ってた感じなんで、
本当になんか結構、そういう感じの空手をやってたっていう感じですね。
怒られる感じだったんで、めちゃくちゃ嫌ですぐ辞めた記憶があります。
なんか自分がやってたことを子供にやらせたりとか、自分のルーツのことを子供にやらせるみたいな親が多いような気がしてるんですけど、
お子さんなんかやってたりします?
うちの子はチェアリーディングをやっていて、僕はほとんど関与してないというか、
子供が言ったことを妻が準備してくれて、非常に感謝してます。
素晴らしい。
ノータッチですなんで僕は。
で言うと、うちも娘2人なのにサッカーを最近始めて、
めっちゃいいじゃないですか。
完全に父親の趣味なんで、私は本当にノータッチですね。
そうなんですね。そういうタイプもあるんですね。
スパイクって言うほどちゃんとしたやつじゃないんですけど、なんか知らない靴が増えてるなとか、
サッカーボールがなんか2個あるなとか、そんな感じで家に物が増えているのは見たんですけど。
いいですね。チームスポーツをちっちゃい時からやるのは。
いいんですかね。私チームスポーツの経験がない。
球技全然ダメで運動神経が皆無なんで、やっといたらいいんだろうなとは思うんですけど、
自分ができないからね。
一緒に楽しめないですね。
全然楽しめないですね。
ありがとうございます。
プログラミングから習い事の話を聞きましたが、本題に行きたいと思います。
起業時のプログラミング学習
プログラミング経験が小売り経験に生きたっていうお話なんですけど、
さっきもプログラミングをやりたかったって言ったんですけど、
身につけておくべきだったなというのが、
ナンバー1が営業で、ナンバー2がプログラミングだと思ってて、なんでめちゃくちゃ興味があります。
それでいくとちょっとポッドキャストで話したことがあるかどうか覚えてないんですけど、
実は僕自身1回目の起業の時にプログラミングを独学で勉強して、
もともと外注して就職活動性向けのウェブメディアを作ってたんですけれども、
外注してシステム会社にお願いしてましたと。
ただ外注していると全然伸びないだろうなっていうタイミングがあったので、
結構年間の登録者数も3万人で、月間PVも300万超えるようなサイトだったんですけれども、
それを内製化して自分で運営できるようになったっていうところがあって、
その経験がペアマノン時代もすごい生きたし、今も生きているっていう感じなので、
そのあたりのことを話せるといいかなと思っています。
私も知ってる限りというか、樋口さんエンジニア職の時代ってなかったと思うんですけど、
そもそもどのタイミングで習得したんですか?
1社目はもともと僕自身伊藤中っていう商社出身で、大学時代の1個下の後輩も野村証言っていうところ出身で、
本当に文系でエンジニア経験ない2人で就職活動性向けのウェブメディアを運営する会社を起業しましたと。
当然2人ともできないので、システムを開発してもらう会社に外注してスタートした感じですと。
ただ本当にウェブメディアを外注で伸ばすのって難しくて、
本当にメルマガを配信する機能を追加したいみたいなことをやっていくと、
じゃあこれ10万円です、20万円です、データベースにこういうのを追加してこういうことをやりたいですみたいになると、
どんどんどんどん重ねていってしまって、このままだと周り聞かずに全然ユーザーの要望に応えられないなと思っていたのが、
本当起業して1、2年ぐらいですかね。
当時僕も思ってたんですけど、iPhoneが多分2011年ぐらいからどんどんどんどん出てきて、
スマホシフトみたいなのが話題になったタイミングだったと。
スマホみんなが持つようになるだろうなっていうのは多分みんな思っていて、その感覚は僕らも一緒で、
一方でこのまま外注したままだとスマホシフトにも対応できないし、そもそもユーザーのニーズにも対応できないっていう形だったので、
じゃあこのタイミングで1年放棄してプログラミング勉強して内製化しよう、スマホ対応、レスポンシブサイトみたいな感じで、
スマホもウェブサイトも一緒にみたいなのを一緒に対応しちゃおうみたいなところを、
2012年の後半起業した1年後、2年後ぐらいから始めたっていう形ですね。
外注だとコストがかかるし、小回り効かないから内製化するために、みたいな経緯で勉強し始めたんですね。
内製化の成功
2013年ぐらいって、私2009年卒なんで、アパイル4年目でもう服のことしか考えてなかったので全然全くわかんないんですけど、スマホシフトっていう時代がその頃なんですね。
2013年頃にはスタートアップも徐々に盛り上がりを始めた時期かなと思っていて、プログラミング勉強しましょうみたいな機運も結構高まってきてたかなと思います。
僕自身読んで勇気づけられたのは、Wantedlyの中さんとかもプログラミング経験ないけれども自分で勉強して、
それも僕も勉強したルビオン・レイルスで勉強してプロトタイプ作って資金調達してみたいなのをブログに書いてくれていて、そういった人が結構企業家でも何人かいて、そういったブログは結構読んだりしてましたね。
2013年ってWantedly今ほど普及してないんですよね。全然初期ですよね。
そうですね、本当に初期の初期で調達してみたいなタイミングだったかなというふうに思ってます。
勉強する時も本当プログラミングなんて全くやったことなかったんで、大丈夫かなというふうに思ってたんですけれども、やらないと潰れるなっていうのが一番最初にありました。
やる時もある程度の正解があって、勉強するための書籍もあるし、外注先にコードは納品してくださいみたいな形で全部ソースコードをもらっていたので、答えがあるような状態だったので、勉強すればなんとかなるでしょうっていうのは結構思ったりしてました。
他の企業家もやってるし、WantedlyほどFacebookと連携してデータ取ってきてみたいな難しいプロダクトじゃないなというふうに思ってたので、これやれなきゃ恥ずかしいかなぐらいな感じで始めました。
1年間毎日大井町のマクドナルドがあるんですけど、コーヒーいっぱいで粘りに粘って、数時間勉強して最終的には内製ができたっていう感じでしたね。
すごい今話題になってますよね、カフェで粘る人。
そうですね、まさにやってました。迷惑かけました。
マクドナルドしかも。それで結局独学で学んで内製化できたんですか?
内製化できて、さくらのVPSでサーバー渡ってたんですけれども、そこで初めてデプロイっていうサーバーに乗せてアプリケーションを動かすみたいなところをやったときは結構感動しましたね。
ただ内製化するとそこの運用の責任も負わなきゃいけなくて、売却の交渉しているときかその前ぐらいに山手線に乗っているときにサイトがダウンしたみたいな連絡を社員からもらって、アクセスカタで止まってしまっていたんですけども、原因を突き止めて回収するのは結構泣きながらやる感じでしたね。
その日に専攻司令のエンジニアさんにちょっと見てもらって、ここがダメそうですねって言われて、じゃあこれ直さなきゃいけないんだっていうのをものすごい書籍とかまた読み直して、これでなんとかなるのかなみたいな感じでやってました。
映画ソーシャルネットワークみたいな、リアルソーシャルネットワークみたいな話ですね、フェイスブックの。
そんなすごくないですけどね、もっとしょぼい感じですけれども、やってる方は必死でしたね。
面白い。言語はさっきRuby on Railsって教えてましたっけ?
そうですね、勉強したのはRubyとRuby on Railsで、SakuraのVPSも勉強したというか、たまたまコンテンツがちゃんとあったのでそれでやってましたと。
選んだ理由もガイチュウ先がRuby on Railsで僕らのシステムを作ってくれていたので、必然的にそれを勉強するようになったと。
やり方としては愚直に本を買って、パーフェクトRuby on Railsか、Ruby on Railsの有名な本があるんですけれども、
それを2冊ぐらい買って、いわゆる書いてあるコードをそのまま書いて、実際に動かしてみてっていうふうにやる社教と呼ばれる勉強方法をやってましたと。
2冊別のものを買って、2、3週それぞれやって、全然わかんなかったので、複数の本に共通して書かれていることは大事なことなんだろうみたいな感じで、
ちょっと注目して吸収するみたいな、そんなやり方をしてましたね。
すごい、本当に知識がないスタートで学んでいけるものなんですね。
あとは本に加えてドットインストールっていう動画のサイト、動画で学べるサービス、無料でも学べるんですけれども、それはかなり良かったですね。
Ruby on Railsの講座、Rubyの講座、SakuraのVPS講座みたいなのを選んで勉強してましたと。
プログラミングの応用
本でやってドットインストール見て、ある程度Ruby on Railsってこうやって動くんだみたいなのがわかってきたタイミングで、
外注先にもらっていたソースコードを読み解いて、この処理って何やってて、これ真剣ゼミで出たやつだみたいな感じで読み解いていくみたいな感じでやっていて、
これちょっと変な動き方してるなみたいなのを見ながらやると、実際に僕らが要件定義して動いているコードだったので、理解も早いっていう感じは恵まれていたかなっていう風に思いました。
だいたいのコードの内容がわかって、自分でいけるだろうっていうタイミングで、本番環境に載せて、じゃあこんなタイミングで切り替えちゃうっていうので連絡して切り替えたっていうそんな感じですね。
結果も内製化してるのめちゃくちゃすごいですね。ここでもなんかやりきる力というか、前井口さんはやりきる力がすごいですねみたいな話をしたと思うんですけど、それだなと思います。
そして一つ、学ぶと他にもなんかいろいろ役立ちそうですよね。
そうですね。今の社員のエンジニアさんとかも言ってるんですけど、本当に言語を一個深く学ぶと横展開とか別の言語であったりフレームワークになっても応用が効くっていう話をしていて、
僕自身まですごく深く学んでないので応用効く範囲狭いですけれども、それでも毎個勉強するといろいろ活かせるところがあるなと思っていて、後ほど話すRPAみたいな業務の自動化みたいなところはRubyで学んで、
それはやってる時も結構学んでいて、ペアマノン時代もストアレコードにかなり生きているので、そこはかなり応用が効いてるなという感じで思いますね。
これプログラミング経験が小売に来たっていう話ですけど、考え方とか成り立ちが分かっているだけでも大いに役立ちそうですよね。
意外に小売って結構システム化というかデータベースが大事だなっていうのを改めて思っていて、やっぱり商品がSKUがどういうふうになっていて、そこに在庫が紐づいて販売数が基づいてっていうデータをかなり扱う仕事なので、プログラミングのデータベースの知識を含めて持っているのはすごい大事だなと思いました。
僕自身が前職でやってたペアマノンっていう低価格帯の子供服ブランドだったので、Tシャツ1枚790円とかで売ってるようなブランドだったので、競争力維持するというか利益出すためにはローコストオペレーションをしないといけないと。
ローコストオペレーションってかっこよく言ってますけど、少ない人員でたくさん仕事をこなせるような、そういった土台が必要になるっていうのをすごい思ってました。
しかもEC専業での販売だったので、業務の多くは本当にシステム上でクリックしたり、データベースを流し込んでやり取りするようなことが多かったので、非常にプログラミングを勉強していると省力化が効くなっていうのは今でも感じているところですね。
山野さんでもガツガツいかせたわけですね。
そうなんですよ。入社して最初に取り組んだんですけど、いきなり、コンサルでも一緒なんですけど、いきなりプログラムを書いて解決しましょうっていうことはあんまりやらないです。
まずはスプレッドシートとかエクセルで業務をきれいにする。標準化して、ちゃんとデータの設計から2回繰り返すことがないようにとか、処理が間違わないようにスプレッドシートの関数を組むみたいなところをやっていくっていうのが大事だなと思ってます。
ペアマノン時代は、幸い代表がペアマノンをやる前に子ども服のECモールのスマービーというところを経てから起業したので、結構データは整っていたのが幸いだなっていうのを、今のコンサルのクライアントさんとかでデータが結構汚くて現場の方がすごい苦労しているみたいなところを見ると、そこは恵まれていたというか標準化とかシステム化しやすいところを代表が整えてくれていたんだなっていうのは思います。
なるほど、その後システム化とかに展開できるように土台を整えていくみたいなのが最初にやったことってことですね。
具体的には元々整っていたというか汚くはなかったってことですけど、何をどう整えていくんですか?
いわゆる商品マスターと呼ばれる品番、SKUのマスターというのは整備されていたので、それを基に発注納品をスプレッドシート上で管理できるようにして、発注がこういうふうにあります。それに対して納品が紐づくようにっていうのを作っていって、発注算の管理ができるようにします。スプレッドシート上でみたいな。
各種ECモールであったりNextEngineみたいなOMSみたいなシステムへの商品登録フローをこういうふうに整備しましょうみたいな。品番マスターと商品のマスターとSKUのマスターにこう登録されたら各種モールにこういうふうに登録していきますというフローを作ったという形ですね。
それも本当に登録された商品のマスターを入れるとバババーっと自動で各種モールの商品フォーマットに展開するようなスプレッドシートをゴニャゴニャ完成を作って書いて、一発で終わるみたいなところを結構重視してやってました。
あとは、結構セールの価格をこれはリアル店舗でも買えるとは思うんですけれども、ECとかだと本当に終時でタイムセールがあって、そこに向けてセール価格を商品ごとに変えるみたいなのはかなりあるので、その辺のオペレーションをパッと終わるように本当に今の商品データと在庫データと販売データを入れて、それを見ながらセール価格を入れると、
各種ECモールのセール設定フォーマットに転換されてあげるだけで終わるみたいな、そういう便利スプレッドシートをものすごいいっぱい作ってました。
便利スプレッドシートいいですね。
この遊業も本当に代表が一人で気合でやっていて、毎回同じ作業なんだけれども、コピー&ペースト、ビールカップ当てるみたいなのをやっていたのを全部自動である程度回るような形にするっていうので、僕とアルバイトの人でも回るような感じにして、運営を巻き取ったっていうところが一番最初のスタートだったかなというふうに思います。
一番最初の頻繁にスケールがある程度整備されていたっていうのは結構大きそうですね。
これは大きいですね。今コンサルをし始めてもない会社さんが結構多いので、そこは代表が本当にやっててくれたところなんだなというふうに思いました。
データ収集と分析の仕組み
次はですね、RPAで自動でデータを収集するみたいなところも取り組んでました。
MD業務を行う上で結構やっぱり他社で何の商品がどれだけ売れているか、どの時期に売れているかみたいなデータは欲しいって言われていて、楽天であったりZOZOではランキングっていう形で出ているので、そのデータをかなり収集していくのにRPAを作って、本当にサイトに負荷をかけないようにデータを自動で収集するシステムみたいなところは自分自身で書いて作ってました。
そんな市場調査みたいなのが自動でできちゃうんですね。
2019年当時もですね、RPAツールとかあったんですけど、そこを学習するよりは僕自身RPAやっていたので、就職活動性向けのウェブメディアの時に、自分で書いた方が早いかなと思ってパパパッと書いてやってましたと。
一方でこれ、今思うと僕がいなくなったらできなくなる運用なので大手企業とかではめちゃくちゃ嫌がられるやり方なんだろうなと思いながら、それより目先の成長と目先の本当に課題を解決するっていう意味で、しばらく僕いるしと思っていたので、そこは本当最短最速最高効率でやっていくみたいな形でやってましたね。
最初は俗人的でいい場合もあるって思ってるんですけど、何事も最初は俗人的でそこから仕組み化されていくものだよなっていう感覚は強いんですけど、仕組みを最初から考えることも当然大事だけど、スピードを重視したってことですよね。
これで失敗かなと思ったことが1個あるとすると、僕のPCだけで回すんじゃなくて、社員みんなのPCで回せるようにしようみたいな形で、RPAの本当にRubyをインストールしてこのコードを実行してくださいっていうのをマニュアル化してみんなに配ったんですけど、
インストールするところでみんなつまずいちゃうっていうのと、アップデートがあるたびにみんながRPAが壊れたって言って全然うまくいかないっていうので、これは各個人のPCでやるもんじゃないだっていうのを思った思い出がありますね。
土台の所要みたいなのが足りないってことですかね。
そうですね、本当にプログラミング全然わかんない人にもとりあえずわかんないかもしれないけど、このコマンドを叩いてねみたいなマニュアルだったんで、理解がないままポチポチ叩いちゃうみたいな感じの運用で、これは長続きしないだろうなと思ってました。
私もSNSのフォロワー数を自動でスプシに記録するみたいな、GASでガスって読むのかな?を見ながらやったことがあって、うわーすげーってなったんですけど、途中で通知が来るようになっちゃって、そこから触れてないです。わからなくて。
ガスもめちゃくちゃ動いてました。会社のスプレッドシートで。
この通りやってくださいねって言われても、その次の応用が効かないっていうのが私はよくわかります。
それもストアレコードのヒントになったというか、そういうややこしいところはやっぱりSaaSとか全部お任せしちゃって、っていう方がユーザー体験としてはいいんだろうなっていうのをすごい思いましたね。
自分たちでは別にメンテナンスしなくてもちゃんとデータが自動で来ると、それに対して対価を支払っていただくっていうのは、ビジネスとしてもいいんじゃないかなというふうには思ってますね。
全然違う話しちゃったんですけど、あれですよね、RTって他社の分析室にいちいち見に行かなきゃいけないのを自動で取ってきてくれて、パッと見られるようにしたっていうことですよね?
そうですね、もう本当に各種ECモールのランキングデータみたいなのを自動で収集して、スプレッドシートにAPI連携で転記して、転記されたデータをクエリ関数とかでゴニョゴニョってやって、見やすい形にダッシュボードにするみたいな、そんなことをやってました。
結果的に自社でもシステム作ったっておっしゃってますよね?
業務の標準化とシステム化
そうですね、入社して1年半ぐらいで業務の標準化も進んだし、そもそも売上が伸びすぎてっていうのも変なんですけど、だいぶ多くなったので、SKMも増えてしまって、人も増え始めましたみたいな形で、
ちょっとスプレッドシートで発注納品したり、タイムセールのこれを変更したりするっていうのに限界を感じるようになってきて、システム化を検討したという形でした。
自分自身も書けるんですけど、既に日々のモールの運用とか、反則の意思決定、リピートのMDの発注数量の決定とか、オペレーションがっつりやっていたので、僕自身も。
これで書いてたら全然スピード出ないなと思って、ある程度売上利益に余裕が出てきたタイミングで、業務委託で副業のエンジニアさんだったんですけど、協力してもらってシステム化をすることになったという形です。
りゅうちさんがある程度書けるというか、分かる人が中にいるっていうことは、共通言語で話せる人がオーダーしてくれるっていう状態だと、エンジニアさんにとってもありがたいんじゃないですかね?
多分ありがたいと思うんですけど、僕自身気を使って要件定義してるんで、ありがたいんじゃないかと思いながらやってるんですけど、それ以前にシステム化したい内容っていうのは、業務の標準化とスプレッドシートでこういうことがしたいんですみたいなところが目に見えてできていたので、要件定義してもらうためにスプレッドシート見てもらって、運用見てもらうと分かるみたいな形だったので、そこはすごい良かったかなと思ってます。
これはストアレコードの開発も同じようなことをやっていて、自動化したい業務があるけれども、まず最初はスプレッドシートで手作業でやっていて、ここの作業を自動化すると全部自動で行けますよねみたいな依頼の仕方をエンジニアさんにしてます。
お願いした業務委託のエンジニアさんもかなり優秀な方だったので、半年ぐらいで形になって、社員の方にも自社の管理画面を使いながら諸々の作業を行えるようになったというような形です。
これはストアレコードとはまた違って、自社に最適化したシステムだと思うんですけど、具体的にどんな機能を作ったんですか?
基本的にはストアレコードに近しいところでなかった機能みたいなところで行くと、共通したところから行くと商品のマスターの管理、発注納品の管理、売上洗い販売数の管理みたいなところをやれるようなシステムだったのと、
独自の部分で行くと、ショップファイとか楽天とかとAPI連携して楽天とかだと特定のお客さんにこのメール、要は大量の納期遅れが発生したときに、
該当するお客さん番号を抽出してその方だけにメールを送るみたいな、これできないと楽天の管理画面からポチポチ送らなきゃいけないっていうのを一括でちゃんとお送りできるみたいなところをやっていたっていうのが一個と、
ショップファイとAPI連携してセールの価格を何時に変えて何時に戻すみたいな、そういうところの業務に深く根付いたところが結構今のストアレコードに比べると細かいところでいっぱいあったなっていうそんな形ですね。
じゃあその時に作ったものがやっぱりストアレコードの元になっているわけですね。
だいぶそうですね、元になっている感じがしますね。で、今後こういうのは先ほど言ったようなセール価格の設定とかはちょっとストアレコード内に盛り込むのかは考えながら、もうご要望としてはやっぱりいただくことが多いので、やっていこうかなどうしようかなっていうのは悩んでいます。
楽天のスーパーセールが終わって、翌日10時に手作業で価格を変えて回すみたいな会社さんがめちゃくちゃ多いので、こういう会社さんまだまだあるので、そういったところのご要望にもお答えするのか、そういったところを解決するシステムもあったりはするので、そっちをご紹介するのがいいのかっていうのはちょっと今悩んでいるところですね。
ありがとうございます。今日はプログラミングのお話でしたけど、私もやっぱりどっかでやってみたいなと思います。ありがとうございます。
エンジニアとの協力
ありがとうございました。
リテールトークここまでお聞きいただきありがとうございます。
番組の詳細欄にGoogleフォームのURLがあるので、質問やメッセージはこちらからお送りいただけると嬉しいです。
番組内でご紹介させていただくかもしれません。次回もぜひよろしくお願いします。
26:45

コメント

スクロール