【プロダクトヒストリーカンファレンス2024 】LayerX&Nealle セッション書き起こしレポート

この記事はニーリーアドベントカレンダー2024の3日目の記事です。今日は2本出てます！

こんにちは、ニーリーの菊地(@_tinoji)です。

先日、YOUTRUST社主催の大規模カンファレンス「プロダクトヒストリーカンファレンス2024」が開催され、ニーリーはスポンサーとして、LayerXさん(のVPoE 髙橋さん)と 事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談 というタイトルで登壇をさせていただきました！当日ご来場いただいた方、オンライン視聴をしていただいた方、ありがとうございました。立ち見も出るほどの盛況でした、、、！ 🎉 lp-a.youtrust.jp

登壇直後にスライドを公開したのですが、今のところアーカイブ配信の予定はないらしく、トーク主体のセッションでスライドだけ見てもキャッチアップできないな、、、と思い、大急ぎでこのレポートを書いています😎 長編ですので、ぜひ気になるセクションだけでも読んでいってください！

※質問が多く寄せられたのでそれに追加でお答えすることも考えたのですが、長すぎるのでそちらは追って投稿します！！！

スライド全体

speakerdeck.com

本編トーク書き起こし

余談ですが、トークの書き起こしには社内の生成AI活用を加速させた、CTO無茶振り登壇駆動開発から生まれたAIによる動画文字起こしツールを使いました。危うく1万字を超える書き起こしを手でやることになりそうだったので助かりましたw

本編への導入

菊地:
事前にイベントの紹介として作成したメッセージ動画で、三宅さんが「賢者は歴史に学ぶ」というワードを使っていて、これが今回のプロダクトヒストリーカンファレンスの趣旨と一致していると思っています。高橋さんをお誘いした時に、歴史に学ぶべく「失敗」にフォーカスするのがいいのではという話になりました。ただ50分枠で失敗の話ばかりすると「この人たち失敗しかしてないな」と思われかねないので、半分は成功の話をしようということになりました(笑) ということで、成功と失敗というのが1つ目の切り口です。

タイトルに「爆速」という言葉が入っているのは、2社にスタートアップという共通点があるためです。スタートアップもフェーズで状況が変わるので、立ち上げ期と急成長期に分けてお話ししたいと思います。概ねPMF(プロダクトマーケットフィット)前後という解釈でよいかと思います。これが2つ目の切り口で、合計4つのパートに分けてお送りします。

1. 立ち上げ期 x 成功談

髙橋:
私たちは約1年でオルタナを作りましたが、管理画面のフロントエンドでSaaSを使用したことが良い意思決定だったと思います。管理画面は往々にしてユーザー向け画面より優先順位が下がりがちです。

前職では管理画面のフロントエンドのスタックが古くなってEOLになっても、リソース不足で交換できない状況になっていました。今回はSaaSを使うことで、私たちの仕事はAPI作成に集中できました。

また新規開発では際限なくこだわりたいことが出てきますが、僕たちは投資サービスなので、口座開設の部分と実際に買っていただく商品が綺麗に見えるという体験の根幹を設定して、それ以外はやらないという整理をしました。これによって工数を節約でき、根幹の体験を何度もレビューして磨き上げることができました。

菊地:
前職でフロントのスタックが古くなって苦労したという部分、まさに過去の失敗、プロダクトヒストリーから学んだということだと感じました。具体的に当時はどんな苦労をしたのでしょうか？

髙橋:
フロントエンドの技術はバックエンドに比べてライフサイクルが短いことが多いかなと。当時はAngularを書いていたんですが、時代がVueになりReactになっていくというなかで、Angularをメンテできる人が減っていってしまったし、「メンテをしたい」というモチベーションもチームの中で下がってしまうという課題がありましたね。

三宅:
私たちは、スタートアップだと珍しいかもしれませんが、初期は完全にオフショアで開発をして、その後速やかに日本の内製に切り替えた、というところが結構うまく行ったエピソードだと思っています。ビジネスの要求とデザインだけをオフショアの会社さんにお渡しし、インフラからアプリケーションまで全てお任せ開発をお願いしました。

サービス立ち上げ後は日本でエンジニアを集め、ハイブリッド開発のような形の過渡期を経て、なるべく早く内製に切り替えていきました。

オフショア開発のメリットとしてコスト圧縮がよく挙げられますが、それ以上に時間を確保できたことが良かったです。私たちはVertical SaaSなので、MVPを小さく作ってお客さんに導入してもらうというのが難しく、最初から検索・オンライン申し込み・契約・決済まで一通り作る必要がありました。さらにカスタマーサービスの立ち上げや営業も必要で、少人数のスタートアップでやることが多かったです。

そんな中で開発の大部分を任せることで、事業を伸ばすために必要な他の部分に注力できました。その後速やかに内製化したことで、リリースサイクルを早めることもスムーズにできました。

菊地:
私も入社した時、Park Directのソースコードを読んだら変な文字が入っていて、「これ文字化けしてますよ」と言ったら、実はベトナム語だったという思い出があります(笑)。

オフショア開発のトピックについて、高橋さんからなにか質問ありますか？

髙橋:
オフショア開発とはいっても、さすがにコードレビューとか何らかのレビューはあったのかなと。実際どうでした？

三宅:
CTOの僕が言うのもアレですが、本当にレビューしていませんでした(笑)。サービスインするまではQA・テストの方で品質を担保していて、機能が動いているか、体験が実装されているかを確認していました。

あとベトナムの方に作ってもらうと日本語が間違っていることが多いので、そういうところのチェックは結構やっていました。サービスイン後は少しずつプルリクエストを見るようになりました。

菊地:
ちなみに高橋さん、オルタナの初期開発では外部委託やオフショア開発は検討されなかったんですか？

髙橋:
私たちは元々運用していたサービスを、最初は半分くらいの人数で作り始め、3ヶ月後に元の事業を一旦停止して全てこちら側に移行する形で開発していました。そのため、QA以外の領域ではオフショアや外注はあまり行いませんでした。

2. 立ち上げ期 x 失敗談

髙橋:
私たちは一般的な「株取引」とは異なる投資サービスを作っているのですが、初期には一般的な証券会社のようなデータモデリングをしていました。そのため運用してみると、「このデータはここにあるべきじゃないよね」というような話が出てくるようになり、凝集度であるとか、実運用上の課題を抱えることになってしまいました。

初期開発では、正直エンジニアは要件を決めたりデータモデリングをする程度しかやることがないと思っていたのですが、それをやりすぎてしまい複雑になっちゃったというようなところ。

現在は必要になったタイミングで必要なレビューを行うようにしています。設計面のレビューは、何を作るか、どういう要件なのかをちゃんと理解したタイミングで行わないと、実運用に耐えるものにならないという学びがありました。

菊地:
「レビューは対象の理解度が高い状態でするべき」という学びがあったとのことですが、そのためにはレビュアーがドメイン知識を高めるための施策が必要かと。実際そういう方向性で練度を上げていった感じなんですか？

髙橋:
いくつかありますね。例えば「税金」って、僕らが考えてやることではなくて、仕組みがあってそれをキャッチアップしないといけないので、適切な専門家に聞くというのがひとつ。あとはチームの中で要件を読み解いて、我々のチームではこれで行って専門家にレビューをお願いしましょう、というようなことを最近やり始めていますね。

三宅:
さきほどの話の裏返しになりますが、オフショア開発で任せすぎてしまい、言語設定や開発環境を任せきりにした結果、開発が詰まって今も苦労しています。

特にデータモデルはペインが大きく、LayerXさんの方では作り込みすぎて〜というお話がありましたが、僕らは逆に十分な作り込みができていなかったため開発が非常にしづらくなってしまいました。去年約1年かけてソースコードの40%くらいを作り直すことになりました。

先を見据えすぎるのも良くないですが、何も考えないのも良くありません。後から変更が大変なもの、つまり不可逆性が高いものについては、「本当にやらなくていいのか」「ここまではやった方がいいのでは」という判断が必要です。ただし、事業を伸ばすことが一番大事なので、悩むくらいならスピードを優先して突っ込むという判断も時には必要だと思っています。

菊地:
両社ともデータモデルで苦労したという話が出ましたね。爆速で開発しようとしてもデータモデルだけは慎重に、という教訓が得られそうです。

ニーリーの場合、お金周りのドメインで1年かけてソースコードの40%を作り直すという大変な作業をしましたが、LayerXではそういった作り直しはどのように進めているのでしょうか？

髙橋:
私たちの投資商品は販売期間が2ヶ月程度なので、たまたま投資商品がないというタイミングが数日あったりします。そこでリファクタリングを入れて、次の投資商品が来る時には改善できるようにしています。

菊地:
なるほど、ちょうどいい「休憩」がある感じなんですね(笑)。

三宅さんにお聞きしたいんですが、1年かけて作り直しをしつつ「機能開発スピード優先を変えない」という部分、一見矛盾しているようにも感じました。どうやって両立したのでしょう？

三宅:
一番大きな工夫は「2つに分けた」ことですね。お金周りのドメインを作り直す際、お金関連の機能の要望が来ても「申し訳ない！」と謝り続けてプロダクトバックログを溜めておきました。その代わりお金関連以外の開発はちゃんと続けることを約束して、お金周りを作り直す組織とそれ以外を開発し続ける組織という形で、アジェンダと組織をセットで2つに分けました。

3. 急成長期 x 成功談

菊地:
つぎに、急成長期のパートに入っていきたいと思います。立ち上げ期をクリアして事業が伸び始め、組織も拡大し、エンジニアもどんどん入ってくるフェーズです。立ち上げ期とは少し種類の違うお話が聞けるのでないかと思います。では、高橋さんからお願いします。

髙橋:
私たちはPdMが1名しかいないチームで仕事をしていたんですが、エンジニアが要件定義まで染み出して行うことで、販売額を上げることができました。

toCサービスは何が当たるか分からない世界なので、チームとしては最速でリリースして価値検証をしていく方針でやっています。PdMにはすごく深いドメイン理解が必要な部分に集中してもらい、エンジニアは例えば「商品ページを見たけど購入していない人にメールを自動送信する」といった、思いつきやすい範囲の施策を高速に実装する方向で企画をしてもらいました。

結果として、一つの施策で何千万円の売上アップを実現できることもありました。企画には専門性が必要な領域もありますが、アイデアを出して実際にコードを書けるのはエンジニアの強みだと思います。

企画リソースが増えたので、エンジニア全員に企画をしてもらい、1〜2日でリリースできる改善施策を数多く出しています。サービスの1行目のコードが書かれてから2年半ほどで、プルリクエストが6,000個くらい出ているので、まあまあ頑張って開発できているかなと(笑)。

菊地:
何千万の改善施策というのも、1〜2日でやったことなんですか？

髙橋:
そうですね、例えばローンチ直後ってマーケティングのメールを手動で送るじゃないですか。そういうのを自動化したりとか、領域広げたらどうなる？ということをシンプルにやっていきました。さっき言った「商品ページを見たけど購入していない人に1時間後にメールを送る」という施策は結構効果ありました。

菊地:
ありがとうございます。このセクションなんですが2社の共通点が多いので、先にニーリーのパートもお聞きして、後でまとめて色々ディスカッションしたいと思います。ということで三宅さんお願いします。

三宅:
私たちも似ていて、エンジニアが事業に染み出すカルチャー・プロセスにこだわったことはうまくいっていると感じています。今年になるまではPdMがいない状態で3、4年ほど開発していたんですが、何を作るかはエンジニアが決めようという思いでやってきました。

ビジネス側と一緒にというのは当然ですが、プロダクト側の人間がユーザーインタビューをしたり、実際に業務を体験したりと、一次情報に当たることを大事にして、それを高速にプロダクトにフィードバックしていきました。作る人自身がユーザーや業務改善の必要性を理解して、自分で考えて開発するのが一番速いと、本当かどうかはさておき僕はそう思ってます。

SaaSだとあまり個別にカスタマイズしないことが多いと思いますが、僕らの場合は、機能が足りないからと導入を見送られそうな時に、エンジニアが一時的なツールやパッチを作ってしのいでおこうという意思決定もすることがあります。

そういうことを言ってもエンジニアの人たちがついてきてくれて、営業の勢いを止めることなく進められました。また、実際にやってみないと本当に必要なものが分からないことも多く、結果的に無駄なものを作らずに済んだのもよかったです。

菊地:
何をつくるか、からエンジニアが入るという大きな共通点がありますね。高橋さんからなにか聞いてみたいことありますか？

髙橋:
とあるクライアントさんが「これが欲しいです」を仰ってなにか作ったとして、例えばチャーンになるなどして機能が使われなくなるとかって起きてないんですか？

三宅:
今のところチャーンしてないので、、、(笑)

まずニーズドリブンで作るので、作ったのに使われないというのはあまり起きてないですね。ただ、エンジニアが作るもの決めているので、ビジネスサイドに説明不足というのがときどきあって。せっかくリリースしたのに有効活用されていないという。

あとは「この機能作ればこれぐらいKPIが上がるから」と言われて開発をしたけど、やってみたらそこまで伸びなかったとかはあります(笑)。営業とプロダクトの仕切りというのは大事だと感じます。

菊地:
2社で共通点が多いとはいえ、一方でどこかに違いはあるはずなんじゃないかと思います。お二人から見て「ここは違うかも？」というところはありますか？

髙橋:
私たちはユーザーインタビューとかはやったりするんですが、特定の企業に物を売っているわけではないので、BtoBと違ってこの機能を作ったらこの会社さんが購入してくれる、という確実性がない状態で仕事をしています。そのため、簡単に作って出して、良ければさらに改善し、ダメならロールバックするということを意識して開発しています。

三宅:
ここまで話を聞いていて、プロダクトアウトなのかセールスが先行するのかという違いなのかなと思いました。僕たちは逆にtoBでは「ユーザーに解を聞ける」ということがやりやすいと思っていて、toCのユーザーにはちゃんとA/Bテストなどで聞いていかないといけないと感じました。

菊地:
ありがとうございます。ここでちょっと意地悪な質問をさせてください(笑)。エンジニアが企画までやるとなると、PdMは一体何をやるのか、ポジション自体必要ないんじゃないかという話になってもおかしくないなと思いました。エンジニアが強く事業に染み出す環境の中で、エンジニアとPdMの差はどこにあるのでしょうか？

髙橋:
僕たちのチームの場合、PdMはドメインに深く入り込んで専門的な企画ができる点が重要です。例えば投資サービスでは金融商品取引法などの法律の知識が必要で、要件を外すと即座に報告事案になるリスクがあります。こういうものはPdMの範囲ですね。あとは、力を入れないとできない企画、つまりエンジニアが片手間では対応できない規模の企画もあるので、そういったものは専任のPdMの方にお願いしています。

菊地:
なるほど、いわゆるドメインエキスパートを兼ねているという感じなんでしょうか。

髙橋:
そうですね。とはいえめちゃくちゃドメインに詳しい方が入社するというわけではないので、勉強しつつですね。

菊地:
三宅さん、ニーリーではどうでしょうか？

三宅:
僕らがよく言うのは、エンジニアが事業に染み出すならPdMはもっと事業に染み出せということです(笑)。具体的にはPLや事業KPIにコミットするのはプロダクトマネージャーのミッションだよ、と伝えています。

例えばtoC側のPdMはマーケティングと密に連携していますし、toB側のPdMはユーザーヒアリングだけでなく営業も一緒に行ったり、オプションサービスのマネタイズを考えたりと、かなり事業寄りの活動をしています。

4. 急成長期 x 失敗談

髙橋:
先程も少し触れたんですが、専門性が高い領域での課題がありました。具体的には税金の計算で、税金の計算って素人がキャッチアップして作っていい領域ではないというか、作るのはいいとしてもちゃんと専門家が正しいことを保証しなければ皆さんにお返しするお金が間違ってしまいます。そういう領域を1人の担当者がずっと担当してくれていて、属人化していました。

リリース直前になって問題が発覚し、税理士や弁護士、社内のコンプライアンス部門にレビューを依頼する必要性に気づきました。専門性が高い領域を、開発しながらキャッチアップするのは無理があります。見積もりが面倒だからとすぐにコードを書き始めてしまうことがあったんですが、これは反省しています。

どういう開発をする際にどういうレビューが必要か、制約条件をきちんと理解しておく必要がありました。例えば景表法が関わっているなら適切な人に相談する、などですね。また、税金や法律といった「決まりきった仕様」については無理にアジャイルにせず、きちんとした仕様書に基づいて開発した方が品質は上がると実感しています。

菊地:
ありがとうございます。三宅さんは前職が金融系ですが、こういった税金などの専門的なところはどういうプロセスが整備されていて、最終的には誰がGoサインを出すことになっていたんですか？

三宅:
専門性がレビューするというところは同じなんですが、それに加えてPMと開発の責任者の3人が必ずレビューするというのが特徴でしたね。あくまで届けたい価値や体験におけるロジックの部分って一部なので、どれだけロジックが合っていてもインとアウトが間違っていたら意味がないんです。そこを担保するためにPMと開発責任者が入ってました。

僕から高橋さんに1つ聞いてみたいことがあります。そういったレビューをしてもらった人は当然勉強になって身につくと思いますが、その経験の数によってメンバー間で知識ギャップは生まれるはずですよね。例えば何年もいる人と最近入社した人とか。そういった知識ギャップがあっても品質を担保する仕組みってあったりしますか？

髙橋:
まずプロセスと知識を分けて考えることが大切だと思っています。プロセスさえ通していればちゃんとリリースできる、というのが赤点を取らないやり方です。専門家のレビューなどですね。

知識については、資格など一般的な金融の知識を勉強する方法もありますが、僕たちのサービスは株とは違うので一度案件を運用してみることが重要です。一定キャッチアップが進んだら運用に実際に参加してもらうという取り組みをやっています。

三宅:
繰り返すことへの投資が遅かったというのが失敗でした。CI/CDなどの自動化は「リリースしてから作ればいい」と思って後回しにし、手動での対応が長く続きました。

また、エンジニアがどんどんプロダクトを作っていったため、仕様が分からないというビジネス組織からの問い合わせが多発し、それへの対応で開発時間を奪われてしまいました。それに加えて、組織が倍になればもそういった問い合わせも倍になるような形で、指数関数的に負荷が増えていきました。

もし過去に戻れるなら、エンジニアがエンジニアリングに集中できる時間を可視化して、やばいことにちゃんと気づく。そのうえで本番作業（トイル）を撲滅する開発を優先的にやるなど、そういった判断をしたいと思います。

菊地:
ありがとうございます。僕も入社した当時は三宅さん含めて3人で深夜メンテをローテーションしていたので、なかなか大変でした(笑)。

高橋さん、LayerXでもそういった運用作業の問題は発生しましたか？

髙橋:
証券のオペレーションのようなことをやるのでトイル作業はあります。外部プラットフォームを使用しているためCSVを扱う作業が多いんですよね。これに対して2週間に1回「改善DAY」を置いて、トイル撲滅のための時間を設けています。そこで収まらないものはチケットを切ってバックログに入れ、POと相談して優先順位を決めています。

僕から1つお聞きしたいんですが、「エンジニアリングに費やせる時間を可視化すべき」というところについて、どのくらいの時間がエンジニアリングに使えれば理想的だと考えていますか？

三宅:
何%という具体的な数字ではなく、事業の状況や組織の状況によって変わるものだと考えています。事業を伸ばすために今はエンジニアが開発に集中する時期なのか、それとも手を動かす時期なのか、全体最適で考えることが大切です。

ただし、エンジニアリング以外の時間が20%とかを超えるとさすがにしんどくなってくるので、その辺のリミットは意識した方がよいと思います。ウチはQA組織が品質だけじゃなくアジリティも守備範囲にしているので、QAと僕が数値をチェックしていたりします。

Q&A

セッションの最後に、Slidoで募集していた質問に対して回答させていただきました。

Q：管理画面のフロントエンドには何のSaaSを利用したのでしょうか？

髙橋:
BaseMachinaというサービスを使用しています。直接データベースにSQLを実行して内容を表示することもできますし、僕たちが作ったAPIをBaseMachina経由で叩くこともできます。例えば証券の分配時にCSVをアップロードして、サーバーでデータを処理するといったことも可能です。

また、良い感じに制約がかかっているため、エンジニアが作りがちな複雑なUIを防ぐことができ、非常に助かっています。

三宅:
実はニーリーでも使ってます(笑)。僕たちも開発者の作業でSQLを実行することがあるんですが、クロスチェックが大変なんです。BaseMachinaは権限周りの機能がちゃんとしているので、手動作業を代替するものを作って他の部署に実行してもらう、ということがやりやすいです。

Q：エンジニアがドメイン知識をつけて提案していくのはまさに理想系だなと思うのですが、そのようなマインドへ持って行ったマネジメント術を教えていただきたいです。

三宅:
カルチャーが一番大事だと思っています。知識や方法論より重要なので、まず採用時にそういう組織カルチャーであることを全面に押し出しています。

その次に「背中で見せる」、「一緒にやっていく」という形で、体験していただきながらフィードバックを繰り返していくことが大切だと考えています。

髙橋:
ステップ・バイ・ステップで物事を大きくしていくことが大切です。いきなり新規事業を作れと言われても難しいですが、2日で1本のメールを作る、という話なら大半の人がイメージできます。そこから1週間のもの、2週間のものへと広げていきます。

その結果に対して1on1などでプロセスの振り返りをし、「これは良かった」「これは良くなかった」というフィードバックを気兼ねなく伝えるようにしています。

Q：事業が爆速に成長していく中で、人材確保は必要かと思います。どんな人材を採用しているのでしょうか。また、新卒採用などは考えているのでしょうか？

髙橋:
LayerX自体は新卒採用もしています。どういう人が多いかというと、私たちは金融を扱っていますが、社員に金融経験者は少なく、僕自身もDeNA出身のように、Webエンジニアというキャリアの人が多いです。

どういう人が欲しいかというと、、、めちゃくちゃ難しいんですが(笑)。分からないことが出てきた時に「やってみよう」と思える人が良いと考えています。一度解いたことがある問題ばかりではないので、知らないことを調べて解決したり、チームで解決しようとする人を求めています。

三宅:
新卒に関しては、インターンから入ってきてくれている人はいますが、新卒採用を本格的に始めるのはこれからです。今日、会場に新卒の方がいらっしゃったら、ぜひ声をかけてください(笑)。

採用については、カルチャー面は当然大事にしていますが、私たちは事業を伸ばすことをやりたいということをよく言っています。技術は本当に素晴らしく楽しいものですが、技術を使いこなして課題を解決したいという思いを持っている人に入ってほしいと思っています。

また、爆速で進めていく時は少人数で大きなことをしていかなければならず、「自分はこれしかやらない」という人だとどうしても隙間が問題になります。スペシャリティのある人にも来ていただきたいですが、最初のフェーズは「やれないかもしれないけどやってみる」という形で隣接領域に幅広く染み出していける方に入っていただきたいと思っています。