こんにちは！Nstock でエンジニアをしています、jagaです 🥔
4/15 に開催されました、CEOとエンジニアが「会社の魅力」と「開発のおもしろさ」を同時に語り尽くす会 vol.1のイベントレポートになります。
CEOとエンジニアがタッグになって、互いの事業やエンジニアリングの話を聞くイベントです。
オフレコトーク大盛りで盛り上がったイベントから、一部を切り取ってお届けします！
パネルディスカッション
CEOのプロダクト開発への関わり方
dinii CEO 山田(@maochil): グラデーションが時期によってすごくあるな、という風に思っています。
ダイニーの場合って1個のプロダクトでガッとスケールしていくよりは、その同じ顧客に求められている色んなプロダクトを積んで積んで積んで、お客様は1人なんですけど、そのお客様がめちゃめちゃたくさんの単価を払う、ことによってマネタイズしていくというモデルになってます。ですので、もう永遠にプロダクト開発をし続けなければならないという命題を背負っております。
思い返すと、コロナ前ぐらいですね。モバイルオーダーやいわゆるPOSの仕様を書いたりしてました。当時まだFigmaじゃなくてSketch使ってたんですけど、Sketchでデザインを自分で書いて...というゴリゴリ現場の時代がありました。
最近だと、お客様さんがお金を払ってくれる新しいプロダクトをどう当てていくかに時間を投下してますね。ディスカバリーチームという3人の少数精鋭のチームを組成してまして、僕がプロダクトオーナー兼プロダクトマネージャーみたいな形で、あとデザイナー1人とエンジニア1人っていう本当にスタートアップの創業期にあるような理想的なチームを組成して、ひたすらこれは当たりそうだぞ！みたいなところをテストしまくる、みたいなことを今はやっています。
当たったら新しいプロダクトとして本実装するチームに引き継ぎますし、逆にお金を払ってでも解決したい課題じゃないよねみたいなところは機能として何かのプロダクトにつけてリリースに回す、みたいなことをやっています。
Nstock CEO 宮田 (@miyata_shoji): まずちょっと前置きなんですけど、私もともと起業する前はウェブディレクターって言われる仕事をしてまして、もともとはプロダクトが本業でしたし、作るの好きでした。
SmartHR時代はプロダクト関わってたんですけど、途中でこのSmartHRのドメインに詳しい人が入ってきたタイミングでバトンタッチしたらうまくいったんですよね。何なら自分が関わってた時代に意思決定した仕様のバグみたいなのが後を引きずっちゃって、その人が入ってきたからそういうのが生まれなくなったので、これは早めにバトンタッチしたほうがいいなっていうのを成功体験的に、かつ失敗も踏まえてSmartHR時代に学びました。
Nstockを始めますっていうブログを見たその日に株式報酬のプロから連絡が来ました。メルカリの株式報酬の責任者の方だったんですけど、一緒にやりたいですと言ってくださったんで、最初からその人にプロダクトのコンセプトとか仕様の壁打ちみたいなのも任せることにしました。実はNstockのSaaSプロダクトにはほぼノータッチっていう感じです。
2個目のセカンダリ事業もほぼほぼチームに任されてる感じです。3つ目のスタートアップへの最投資事業は、ここは逆に僕がおそらく会社の中で詳しい人であるので、3つ目の事業にしてようやくプロダクトに関われるというか一人で今始めてる感じです。なので基本的にはそのジャンルに詳しい人であったりエンジニアチームのメンバーに任せるっていうスタイルでやっています
山田: 手放して、怖いと思うことはありますか？
宮田: 逆に自分が持ってるととんでもない仕様のバグ見そうで怖いって思っちゃうんで、任せてる方が楽かもしれません。
山田: 僕の場合、どうしても年間やっぱりお店に500件とか行ってますし、一番その飲食店の社長なり営業部長なりいろんなステークホルダーと僕が一番話しちゃってるんですよね。どうしても持ってるインプットの量だと僕が常にトップを走り続けてるみたいな。逆に新しく入ってくるプロダクトマネージャーの方に僕を超えてくださいみたいなお題出すのって結構残酷だなっていう気がしてて...。
宮田: 業界とか市場によって変わりそうと思いつつ...。
採用とは何のためにするかというと、一人ではできないことを実現するためにやっていくっていう感じだと思います。一人ではできないことを実現するために手数を増やしたり、考える頭を増やしていくっていう感じなので、適宜自分が詳しいと思っていても渡せるところ、かつ自分よりもこの人の方がうまくできそうだなっていう人に渡していくのがいいかなとか思ってますかね。
フェーズごとに向き合ってきた技術課題
宮田: 開発チームはどれくらいの規模なんですか。
dinii Tech Lead 谷藤 (@HiroIot): 開発チームは今、業務委託を合わせて20名くらいですかね。フルタイムがだいたい12とかでやっています。プロダクトをメインに開発しているチームが1つなので、そこだけで言うと5名とかで、全てのダイニーの事業の機能開発をしているっていう感じですね。
Nstock エンジニア じゃが (@jagaimogmog): Nstockは今、エンジニアが全部で6人います。先ほどのSaaSの事業に5人で、セカンダリの事業に今1人いて、今立ち上げをしている感じですね。そんな中でフェーズごとに立ち向かってきたみたいなところで、フェーズの移り変わりのところで苦労された経験とかを聞けたらと思うんですけど、ダイニーさん、どうですか。
谷藤: そうですね、ダイニーは今シリーズB後半くらいになってきていますが、シリーズAの話をすると...。フィーチャーチームという、機能をメインで開発していくチームが1チームでやってました。プロダクトも結構徐々に大きくなりつつあったし、顧客も徐々に増えていた中ですね。機能開発を結構メインでやっていて、技術負債とかサービスの安定性みたいな一番大事なところに関心が寄せづらい状況でした。
そういった中で、忘れもしないんですけど、結構大きなインシデントを引き起こしてしまいまして...
(オフレコ)
そういうこともあり、安定性には投資していかないといけないよねと、プラットフォームチームという安定性と開発の生産性をみるチームを組成しました。
じゃが: Nstockの話でいうと、そこまでのハードシングスは今のところ経験してないんです。最近ついに、PMF、0→1が終わりつつある感覚をチームで持ってます。
山田: リアーキとかリファクタとかしたい欲と、どう向き合ってますか?
というのもダイニーの場合ってコロナ前とコロナ後でやっていることってほぼ変わってないんですね。でも飲食店側がテクノロジーを使って何とかしていこうというムーブメントがコロナ後に起きたんで、僕らPMFできたんですよ。エンジニアにはPMF前に作ったものは片付けないといけないっていう葛藤があるのかなと思っていて。
じゃが: リアーキでいうと最近大きめの変更をしました。ただそれはビジネス的に必要だったという側面が大きいですね。
私たちが考えていた仕様では入力できないデータを持っているお客さんがたくさん発見されたんです。もともとはシンプルな形で保存していたんですけど、もっと複雑なデータがあることが、お客様に使われるようになって分かってきまして...
3ヶ月くらいかけて、その仕様をデータベースのスキーマから全部書き換えるっていうのをやりました。これはPMFの過渡期においてなかなか攻めたと思いますし、僕たち自身として思ったより長くかかっちゃったなという反省があります。
一方で、これがないと、これから作る大きな機能が成り立たないんですよね。なんで今やんないとダメだよねって歯を食いしばりながらやったっていう感じです。
宮田: それでいうと、仕様の負債が(SmartHRに比べて)ちょっと少なめなんですよね。
(オフレコ)
Nstock社は幸いなことにプロがDay 1から入ってたんで仕様の負債が結構少なめっていうのと、SmartHRのカスタマーサクセスやってた人がPdMをやってるんですよね。権限回りとか負債になりそうな場所を結構早めに潰せてたんで、負債が少なめにできてるっていう前提はあるかもしれないなとか思いました。
山田: Day 1からプロを雇えってことですね。
宮田: Day 1からプロとあと2週目のPdMを雇えですかね。難しすぎる（笑）。でも「SmartHR時代の仕様のバグとか僕が生んだんです、すみません...」みたいな話をたまにエンジニアの人たちにするんですけど、すごい優しくて。「踏み抜いてったからこそ今があるんじゃないですか」みたいに言ってくださるんです。負債は大変ですが、勲章みたいなもの、だとも思います。
プロダクトと組織のこれまでとこれから
山田: (オフレコ)
ダイニーの場合ってプロダクト数がどうしても多くなってしまうし、逆に言うとプロダクトを複数分けてポートフォリオ経営していった方が事業進捗の安定性は担保できると思っています。なのでとにかくプロダクトラインがめちゃくちゃ増える、お客さんにお金を払ってもらうっていうプロダクトがめちゃくちゃいっぱいある。そんなプロダクト組織、事業群にしていきたいなという風に思っております。
谷藤: 今ダイニーではフィーチャーチームっていうプロダクトをメインに開発するチームは1個なんですよね。
1個のフィーチャーチームがモバイルオーダー、POS、CRMとか。あとは別事業でいうと決済の事業も含め、すべて直列でやってるんですよね。そろそろ切り出して並列に進めないといけないと思ってます。複数プロダクトがどんどん立ち上がるので、0→1やりたい人でもいいですし1→10やりたい人でもいいし、10→100やりたい人でもいろんな人が活躍できる場があるなと思ってます。
そうなると、複数プロダクトに知識がある人に結構価値が出てくると思うんですよね。なので職能問わずいろんなことを幅広くやっていけるエンジニアに来ていただけると、めちゃくちゃ嬉しいなと思ってます。
じゃが: NstockのSaaSチームでもフィーチャーチームを分けていかなければ、というのをちょうど話してます。どう複数チームに分けていかれるんですか？
谷藤: 今まさに取り組んでいます。
単純に事業ベースでモバイルオーダーチーム、POSチーム、決済チームみたいに分けるのはあんまり良くないなと思ってます。ダイニーって、POSがあってそのデータを使ってモバイルオーダー出してモバイルオーダーの中で決済する、みたいな感じに繋がってるんです。そういう風に分けちゃうと1チームがいろんなプロダクトを触ることになって、たぶん開発の生産性は上がんないんですよね。
山田: 最近流行りのマルチプロダクトとかコンパウンドとかって聞いたことありますか？ 僕なりの解釈は、例えばプロダクトAが存在しているからこそ、新しく出した同じ領域のプロダクトBがめちゃくちゃ輝く。プロダクトBが単体で出せる価値の2倍になるし、逆にもともと存在していたプロダクトAもプロダクトBを出したことで2倍の価値になったりするんですよね。
ダイニーの場合、お客様の消費者のデータが取れるCRMがあるからこそPOSの価値が際立つと思っています。ダイニーのPOSがあるからこそ、普通のCRMよりも多分10倍ぐらい提供価値が増やせるんですよね。
コンパウンドならではの強さを、データ的に担保できるようなドメインの切り分け方をしていくと、我々は幸せになれるんじゃないかな、みたいなことを話してます。
宮田: いいですね。ちなみに僕ダイニーさんのモバイルオーダーの大ファンです。すげえいいって山田さんにも直接何回も言ってるんですよ。
この前、衝撃の事実を聞いたんですけど、「実はダイニーのモバイルオーダーのアプリ、2年間ぐらい改修してないんですよ」って聞いてマジで!?って思ったんですよ。あんな体験がいいものを2年前から作れてたんですか?もそうですし、そこまでリソース切迫してるんですか?という。これあと何人ぐらい入ったらさらにモバイルオーダーのアプリ良くなるんですか。
谷藤: 僕らとしてはめっちゃ悔しいですよね。
いいって言われてるのはもちろん嬉しいんですけど、もっとよくできるんですよ。そこに今リソースが避けてないみたいなところがあるんで...。もっといい体験絶対作れるんですよ。
山田: 本当に答えはないんですけど、とにかく今すぐチーム組成してリソース投下したいなっていう風に思ってるぐらいなんです。
ダイニーって珍しい事業の伸び方をしてきてて。飲食店に行くとモバイルオーダーを消費者として使うじゃないですか。だから飲食店のオーナーさんが別の飲食店でお客様としてダイニーを体験するわけですよ。で、「めっちゃいいじゃん！これうちの店でも使いたいわ」ってお問い合わせをいただくっていうケースが年々というか月々でめっちゃ増えていってて。
とにかく店舗に導入すればするほどダイニーの認知度が上がっていくという。プロダクトが2B SaaSのリード獲得にこれだけ寄与できるって、めちゃめちゃレアだなと思って。だからこそ悔しいです。
宮田: アップデートされるのを楽しみにしてます。じゃあ次Nstockのターンということで。
実は結構似てまして、我々も複数プロダクトやっていく前提の会社です。ただ割とそのプロダクトはもちろん連動してるんですけど独立しながら作ってる感じがちょっと強めです。それぞれフェーズが全然違います。
まず1つ目の株式報酬SaaS事業はPMFしてる感じを肌で感じてます。昨年の10月に有料化したんですよ。それからいいペースでお客さん増えていってますし、「これが機能として追加されたら導入します」みたいなお客さんがたくさん積み上がってき始めています。ある意味一番楽しい、バーッと作っていくタイミングにあるプロダクトだと思ってます。
2つ目のセカンダリ事業はまだリポジトリもないんですよね。この事業は自分たちが証券会社にならないといけないですし、法律とうまく付き合っていきつつ、ちゃんと使いやすいプロダクトを作っていく必要があります。まさに自分が一番最初からコードを書くところに携われる、めちゃくちゃいいタイミングだと思ってます。
じゃが: 私が株式報酬SaaSのエンジニアなのでSaaSについてもう少しお話しします。
先ほどチーム分割の話がありました。私たちもそろそろチーム分割したいねという話をしています。今考えているのは、プロダクト開発チームを2ラインに分けるというものです。
新機能開発ももちろん大事ですが、いかにリファクターや既存機能の改善を回していくか、そしてより安全で品質の高い開発をし続けるための投資していくのかというのももちろん大事ですよね。フィーチャーを開発するチームに加え、バグフィックスや改善を主眼とした守りの開発をするチームを作ります。
一方で、完全にチームを固定化してしまうと結構つらいだろうなと思っていて...新規開発ってやっぱり楽しいじゃないですか。ずっとバグフィックスするのって結構大変だと思うんですよね。なのでバグフィックスを一定期間やったら次は新規開発、新規開発を一定期間やったらバグフィックス、みたいに役割をぐるぐる回せないかと考えています。
谷藤: めちゃくちゃいいですね。やっぱり大きめのリファクターってやんないんですよ。もう仕組みでやんないと、いつかやりますで、絶対やんないんですよね。なのでそういう仕組みを作らないとやらないなってダイニーも思ってるんです。
一方で、ダイニーは作るときにめっちゃこだわってます。新機能開発するときも、仕様面から結構エンジニアが入ってですね、技術的にコスパはいいかとか技術的な差別化になるかみたいなフィードバックをします。また、フィーチャーチームがコードを書くんですけど、コードレビューはもっと初期メンバーのめちゃくちゃドメイン知識があるメンバーがやることで品質を担保しています。
あとは経験として、いらない機能を作った時の大変さは身にしみてます。開発速度落とすし、顧客が1人でも使ってると機能って消せないじゃないですか。なのでこの機能消したいけど...みたいなのがあるんです。いらない機能を作ったときは大変だよね、というのはダイニーのエンジニアの共通認識としてあるかなと思ってます。
じゃが: いいですね、めちゃめちゃ分かります。いかに作らないかっていうところから考えるっていうのは大事ですよね。
おわりに
お互いの開発や事業について聞くことができ、登壇者としても大変楽しいイベントでした！
懇親会も大盛り上がりで、事業や開発について登壇者と参加者でさまざまなお話がされていました。
オフレコトーク込みで味わい尽くしたい！という方は、ぜひ会場にいらしてみてください！
気になる方はconnpassのNstockページをフォローお願いします。
Discussion