hidekのエンジニアと長話 第10-3回【全文書き起こし】~ゲスト：LayerX 取締役 榎本悠介氏~
stand.fmで配信中の「hidekのエンジニアと長話」10人目のゲストは、LayerX 取締役 榎本悠介さんです。
「hidekのエンジニアと長話」は、メルペイVPoEのhidek（木村秀夫）さんをメインパーソナリティにお招きし、ゲストエンジニアとともに作っていくスペシャルトーク番組です。
第10-3回の今回は、LayerX 取締役 榎本悠介さんをお招きして、今の事業にたどり着いた経緯やtoBとtoCの違い、GraphQLなどについて語りました。
※本記事は、2021年10月22日にstand.fmで配信を開始した番組を書き起こしたものです。
ゲスト
榎本悠介 氏 @mosa_siru
株式会社LayerX 取締役
メインパーソナリティ
hidek（木村秀夫）氏 @hidek
株式会社メルペイ VPoE（Vice President of Engineering）
パーソナリティアシスタント
gami（池上）氏 @jumpei_ikegami
株式会社プレイド エンジニア
今の事業にたどり着いた経緯
hidekさん（以下、敬称略）：で、今、「ブロックチェーンの会社じゃないよ」ってところをアピールしつつ、改めて3事業というと？
榎本さん（以下、敬称略）：SaaSを作っている「LayerX インボイス」ワークフローとか、その先もいろいろ展開しようとは思っているんですけど、っていう、DX事業部っていう僕が見ているところと、あとは、さっきチラッと出した、三井物産さんとのジョイントベンチャーで「アセットマネジメント」っていう領域ですね。不動産だとかインフラだとか、いろいろなファンドを、物件を買って、で、投資家を集めて投資する、みたいな。その一連のプロセス、ファンドを組成して、それを運用して、Exitする、みたいな一連のプロセスが結構非効率なところが、今、あるので。そこをデジタル化して、めちゃくちゃ効率的なファンド運営ができるぜ、みたいな、そういう事業を作っている事業部と、あとは研究開発。組織として、匿名性とか秘匿みたいなところに、今、フォーカスを絞っていて。たとえば、電子投票とかですね。めちゃくちゃ安全で秘匿性に配慮しているけれども、不正が行われていないことは証明される、みたいな。そういう秘匿性と透明性を両立する仕組み、みたいなのを、TEE（Trusted Execution Environment）っていうハードウェアの仕組みがありまして、そういうのを利用してやっていたりだとか。っていう、今、3事業があってですね。で、松本さんと僕の分業で言うと、僕が1個目のDX事業部を見ていて、2個目と3個目を松本さんが見ている、って感じですね。
hidek：そうなんだ。じゃあ、事業単位でわけてるんですね？
榎本：そうですそうです。
hidek：そうなんだ。じゃあ、結構、mosaがやってるDX事業部のところの技術選定みたいなところは、あんまり松本さんは関与してない？
榎本：そうです。ですです。
hidek：そうなんだ。へー。じゃあ、一般的なCTOと役割分担としてはちょっと変わってますね。
榎本：そうですね。なので、社内の公式ポジションではないですけど、言うなれば、僕が事業部CTOをやっている、みたいな感じですね。
hidek：って感じですよね。へー。おもしろい。そうなんだ。僕、昔のmosaを知っているので、「toBやってる」っていうのが、めちゃめちゃ違和感があって（笑）。
榎本：（笑）。
hidek：「あのハッカドールやってたmosaが？」って。しかも、経理だとか請求書だとか、「え、本当に？」っていう。そこにたどり着いた経緯とかってなんかあるんですか？
榎本：そうですね。話をピボットのところまで遡ると、ブロックチェーンでビジネスを立ち上げようとしてました、と。で、みんな、いろいろな会社さん、特に大きい企業さんとか、ブロックチェーンに興味あるんですけど、紐解いていくと、「ブロックチェーン以前の問題だよね」みたいなのがやっぱり多いんですよね。
hidek：うん。
榎本：ブロックチェーンって、複数の主体が集まって、データとかプログラムを共有して、はじめて活きる技術なんですけど、そもそも個社個社が全くデジタル化されていない、データも電子化されてないし、そもそも紙だし、みたいな、っていう状態の中で「ブロックチェーンと言われましても」みたいな。DXのレベル1・2・3・4とか、僕ら、分類してたりするんですけど、ブロックチェーンがレベル4だとしたら、「まだ、レベル1とか2のところを解決しないといけないね」みたいな、っていう整理をして。「じゃあ、1とか2の課題を解決するプロダクトってなんだろう」みたいなところを模索しだしたのが去年の夏とかなんですよね。
hidek：うんうん。
榎本：ただ、ブロックチェーンっていうので、結構、「証券」とか「お金の流れ」みたいなところの話は、僕らも結構詳しくなっていたので、その領域で「何かペインないかな？」みたいなのを、ひたすらヒアリングさせていただいて。それこそ、メルカリさんのところにも行って、「どういうコーポレートでペインありますか？」みたいなのを、何もお土産がないのに聞きに行ったりだとかさせていただいて（笑）。
hidek：（笑）。
榎本：それで、いろいろな会社さんに聞いたところ、実は「請求書を受け取って会計上の処理をして支払う」みたいな、そこのプロセスって、結構、ぽっかり空いていることがわかってきて。
hidek：あー。
榎本：で、そこにフォーカスしたプロダクトをプロト的に作ったりだとか、デモしたら、相当ウケがよかった、というところもあって。
hidek：へー。
榎本：で、かつ、三井物産さんとのジョイべのところでもめちゃめちゃほしがられた、とか。なんか、そういう諸々もあり、「一旦、そこに絞ってやってみたら結構いい感じ」みたいなのが現状ですね。
hidek：へー。
toBとtoCの違い
榎本：で、toB話なんですけど、思ったよりこだわりなかったですね、やってみたら（笑）。
hidek：あ、そうなんだ。話長かったけど、意外とあれだね（笑）。
榎本：すみません（笑）。結局、「プロダクト作ってお客さんに喜んでもらう」っていうのは何も変わんねーな、みたいなのがあって。
hidek：なるほどね。へー。
榎本：特に、意外かもしれないですけど、toBの方がお客さんに近いんですよね。
hidek：あー。濃いよね。
榎本：そうですそうです。toCって、実は全部数字で見たりするじゃないですか？
hidek：はい。
榎本：もちろん、ユーザーインタビューとかするときもあるんですけど。結構、ABテストだとか、なんかそれで数字でシビアに判断して「リテンションが」みたいなので、実は、お客さんの生の声よりダッシュボード見ている時間の方が長い、みたいな。とかはありがちですけど、toBは、特にまだ、僕ら、出して1年経ってないようなプロダクトなので、いかに生の声を吸い上げるかが大事、みたいなので。今、商談だとか全部録画させていただいていて、Zoomで。で、それを本当にエンジニアが生で見る、みたいなのとか。
hidek：へー。
榎本：っていうので、本当にお客さんとの距離が近い中で、喜んでもらっている様も、「使いづらい」って言ってもらえる様も、生のまま受け止められるので、それはすごくおもしろいな、と思っていますね。
hidek：前回の近澤さんの話で、「Burning needsの大切さ」みたいな話があったんですよ。で、「マーケットインとプロダクトアウトのバランス」みたいな話をちょうどしてて。
榎本：うん。
hidek：で、たぶん結構、Autifyにたどり着くまで、いろいろチャレンジする中で、徹底的にニーズを聞いていったら、そこにBurning needsがあって、で、そこに対してプロダクトを出したら、それが今のAutifyにつながった、みたいな話があって。
榎本：はい。
hidek：結構、似たようなことをやっている。
榎本：そうですね。
hidek：で、彼も、「今、セールスにめっちゃ力入れています」と。
榎本：うん。
hidek：お客様の話を、とにかくとことんまで聞く、ってところに、CEO自らを突っ込んでいく、みたいなところが重要なんだ、って。
榎本：うん。
hidek：だから、結構、今の話、近しいところがあるな、と思って。
榎本：最初、fukkyy、めちゃくちゃ営業していましたね。
hidek：そうなんだ。
榎本：うん。めちゃくちゃお客さんの目の前に行って、ペインをひたすら聞く、みたいなのを、fukkyyがやってましたね。
hidek：ふーん。かつ、今、それをCTOがやっている、今はCTOじゃないんだけど、っていうのはおもしろいな、って。前回の話の続きとしておもしろいな、と思いましたね。なるほど。
榎本：うん。
hidek：toBって、そうなんですよね、声がすごく近い分、これも前回、近澤さんとも話したんだけど、声をあまり聞きすぎると……。
榎本：あー。ですです。
toBの機能開発は足し算
hidek：キメラができあがっちゃって、得体の知れないものができあがっちゃって、プロダクトとしての訴求するポイントがわかりにくくなる、ってありがちなんだけど。その辺って、なんかバランス取ってます？
榎本：いやー、本当にそこはいくらでも語りたいところで（笑）。
hidek：いいよ（笑）。
榎本：前提として、toCと比べてtoBって足し算だと思ってるんですよ。機能の開発が。
hidek：うん。
榎本：toCって、結構、「いかにそぎ落として、一番尖りたいところにフォーカスできるか」みたいな。そこをちゃんとお客さんに届けられるか、みたいなところで、引き算が結構あると思うんですけど。toBは、個社個社で業務フローが違うので、ノックアウトファクターが違う、みたいな、導入における、っていうので、どうしても足し算にならざるを得ないので。で、かつ、顧客の獲得コストが高いので、「あるノックアウトファクターが、結構、事業者クリティカルだ」みたいなところがあると思っていて。なので、相当そこの最大公約数的な、仕様を抽象化して、個別カスタマイズしないで、こういう一歩引いた仕様にすれば10社くらい要望満たせるよね、みたいな。っていうところにする力みたいなのがすごく求められると思いますね。
hidek：それ、すごく難しくないですか？
榎本：すげー難しいです（笑）。
hidek：言い方あれですけど、結構、この領域って、各社入って来てる領域じゃないですか？
榎本：はいはい。
hidek：だから、差別化・区別化も一定必要な中で、ただ、業務としては、みんな近しいことをやっているわけで。最大公約数を取るのがめちゃくちゃ難しいな、と思うんですけど。
榎本：はい。
hidek：なんか意識していることとかってあったりとかするんですか？
榎本：そうですね。差別化うんぬんで言うと、なんだろうな、結構、僕ら、ある意味素直に、お客さんが喜んでもらえるプロダクトを……。toC出身のエンジニアがほとんどなんですよね、僕らって。
hidek：うん。
榎本：で、かつ、会計ドメインの知識とか一切ないチームだったんですけど（笑）。「GREE出身です」とか「DeNA出身です」とか「エウレカ出身です」とか、そういう人が多いチームだったんですけど。結構、真摯にドメイン知識を勉強して、お客さんの声を聞いて、「こうやって使えるのが便利じゃないかな」みたいなのを向き合って作ったら、実は差別化になってたんですよね。
hidek：へー。
榎本：ある意味、素直な心って言うとあれかもしれないですけど、当たり前のユーザー体験の水準が高いな、とちょっと思うところがあって。toC出身の人って。結構、言うなれば、コーポレート系プロダクトって、ちょっと使って「うっ」ってなるの多いじゃないですか？ あんまり悪口みたいになるとあれなんですけど。そういうところを自然に、たとえば、SPA的に作るだけでも、サクサク体験がよくなる、だとか。そういうローディングが全然ない、だとか。そういうところを当たり前に作っただけで、実はすごく差別化になっているところもあったりとかしました。
hidek：なるほどね。そう。toB向けのやつって、UI/UXって、結構、「もうちょっと進化してもいいのかな」って思うこともままあって（笑）。
榎本：うんうん。
hidek：なるほどねー。へー。じゃあ、そういうところをちゃんと突き詰めていくと、toCの感覚でしっかり突き詰めていくと、それ自体が差別化になって、みたいな感じですかね？
榎本：ですね。で、優先度をつけるところも、結構、うちのチーム、変わってて。絶対的なプロダクトマネージャーみたいなのがいないんですよ。今、うちのチームって。2ヶ月前にようやくプロダクトマネージャーを立てた、みたいなチームでして。それまでは、かなり民主的にやっていて。セールスのチームの人が「お客さんがこういうことを温度感高く言ってたよ」とか、カスタマーサクセスの人が「こういう要望、既存のお客さんから来てるよ」だとか、そういうのを持ち寄って、ワーワー言いながら優先順位つけていく、みたいな。で、エンジニアも参加して、「いや、それめっちゃコスパ悪いっす」とか「これはこういう仕様に変えたらこれも解決できます」みたいな形で、結構、みんなの持ち味を活かして、バックログを作っていく、みたいなプロセスでやってて。
hidek：ふーん。
榎本：で、バックログの消化、ユーザーストーリーに落として、それを仕様に落とすところも、もうエンジニアがやっちゃうんですよね。うちのチームって。PDMが、ほぼその細かいところはやんなくて、ユーザーストーリーをもとにエンジニアが「こんな感じじゃね？」みたいなのを作っちゃう、みたいな。
hidek：へー。
榎本：で、社内の経理に詳しい人と壁打ちしたりとかお客さんの実際の声を聞いてみたりとかして、エンジニアが割りと半分ノリで作っちゃう、みたいな（笑）。で、ノリで作ったものを、みんなで、毎週デモ会みたいなのでワーワー言ってよくしていく、みたいな。
hidek：ふーん。
榎本：うん。っていうプロセスでやってて。この前、近澤さんにその話をしたら、すごくおもしろがってくれて。たぶん、今日、紹介いただいたのかな、と思っています（笑）。
hidek：なるほど（笑）。PDM不在で、toBのこのプロジェクトを作っていくって、結構、斬新ですね。
榎本：結構、たぶん斬新ですね（笑）。
hidek：っていうか、しかも、toBってこだわるつもりはないんだけど、そこに対してエンジニアが肌感を持ってやっていくっていうのは、結構、すごいね。
榎本：（笑）。なんだろうな。ドメイン知識を得るのをいとわない、っていうか、そういうのを貪欲にキャッチアップして、お客さんに喜んでほしいな、って思うマインドのエンジニアが集まっているとは思っていて。
hidek：なるほどね。
最短の開発手法
榎本：ですね。あとは、デザインのプロセスとかもあんまり挟んでないんですよ、今。
hidek：えっ？
榎本：エンジニアが、フロントもサーバーサイドも一気通貫でできる人が集まってて。っていうか、そういう風にコンバートして。で、1ユーザーストーリー、本当にひとりが一気に作る、みたいな。
hidek：へー。
榎本：で、Bootstrap的にフロントもとりあえず作っちゃって。で、デザイナーに最終的に渡すと、デザイナーの人がコーディングもある程度できる人なので、なんかいい感じになって、「はい、できた！」みたいな感じでやってる、っていう。半分、めちゃくちゃなプロセスでやってます（笑）。
hidek：でも、ある意味、それ、最短っちゃ最短かもね。
榎本：最短です。めちゃくちゃ早いっす。
hidek：フィジビリティがちゃんと確認された上で作っていくので、すごく最短と言えば最短だけど、求められる力量っていうのが、結構大変だね（笑）。
榎本：思います（笑）。
hidek：それは、意識してそういうチームにしてったの？ それとも、結果、なったって感じ？
榎本：結果、なりましたね。とにかくスピード…….。インセプションデッキみたいなのを最初にチームでやったんですよ、スクラムの。始めに「何をチームとしてやって、何をやらないか」みたいなので。「スピード」っていうキーワードを、死ぬほど、そこで出たんですよね。やっぱり、僕らも「業界としては最後発だ」っていう意識があって。
hidek：うん。
榎本：で、そこで、「デリバリーで負けてたら何も話にならないよね」みたいなところで、「じゃあ、どうやったら一番早く開発できるか」っていうのをやってって。たとえば、「プルリクが止まるとかもないよね」みたいなムードができたりとか。
hidek：おー。
榎本：要は、ノーレビューでマージしまくってたんですけど（笑）。
hidek：おー（笑）。
榎本：一人ひとりがユーザーストーリーの責任者なので、フロントもバックエンドも、その人が何かあったら責任持つし、みたいな。で、背中預け合って開発するよね、みたいなので、本当に能力マージをしまくる、みたいなチームにしてたりしてて。今ではもうちょっと、さすがにやんちゃさは抑えられてやってるんですけど。スピードに、とにかく意識していった結果、そういうスタイルになった、って感じですね。
hidek：へー。じゃあ、結構、エンジニア文化としても、スピードってところは、文化としては根づいてる？
榎本：ですです。なので、お客さんにも、すごくそこがポジティブに喜ばれることが多くて。
hidek：なるほどね。
榎本：商談中に、「あ、それも、次、リリースする予定です」だとか、次の商談になったときに「あ、もう、それできてます」みたいな話になったりとか。だから、「LayerXはこのスピードで開発してくれるんだったら、今、まだ足りてない機能そこそこあるけど、でも、まあどうせ作ってくれるっしょ」みたいな感じで導入いただいたりとか。その辺がすごくいいループになっているな、と思いますね。
hidek：じゃあ、逆に、プロダクトロードマップみたいなのは引いてない？
榎本：最近、引くようにした、って感じです（笑）。
hidek：そうなんだ（笑）。すごくスタートアップっぽい、って言ったらあれだけど……。でも、それ、結構、理にかなってるし、おもしろいですね。それ自体が差別化になってる、っていうのは、すごくいい話ですね。
榎本：うん。僕ら、正直、「この領域、ど素人だな」っていう自覚があって。本当に、「お客さんの声を聞きながらやるしかないね」っていう、ある意味、割り切りがあったので、下手に長期的なロードマップ引いて逆算、っていうよりは、作って、当てて、その機能の結果、「じゃあ、次、何ほしい？」みたいなのとか。あとは、結構、IT系、リファラルが多いんですよね。そこから、徐々に、IT系の外に今、行ってたりとか。ミドルサイズの企業に行く、だとか。そういった中で、顧客の要望とかって、全然変わってくるので。業務フローとかも。
hidek：うんうん。
榎本：なので、あんまりわからないうちから大きな絵を引いて逆算する、っていうよりは、足元から登っていこう、っていうチームの意思決定をしましたね。
hidek：ふーん。今って、何人くらいのチームなんですか？
榎本：ビズサイド、エンジニア全部あわせて25人くらいですね。
hidek：あ、それはフットワーク軽いし、できるわ。
榎本：ですね。
hidek：えー。めっちゃ楽しそう。
榎本：めっちゃ楽しいっすよ。いいっすよ、hidekさんも来ていただいて（笑）。
GraphQLが手に馴染んだ話
hidek：ちょっと危ないんで話を変えて（笑）。技術的に、今、チャレンジしていることって何かあったりとかするんですか？
榎本：そうっすね。ある意味、スタンダードな技術は使っていて。サーバーサイドはGoですし、フロントエンドはTypeScriptで、ReactじゃなくてVueなんですけど。とか、ある意味、スタートアップとしては普通の技術を使っていて。で、もし、あるとしたら、最近、GraphQLを始めたらめちゃくちゃ手に馴染んだ、みたいなのがありますね。
hidek：使いどころってどの辺になるんですか？
榎本：そうですね。SaaSが、フロントエンドがあって、それ、SPA的にあって、それがバックエンドを叩くところに使っているんですけど。
hidek：なるほどね。うんうん。
榎本：もともと、LayerX インボイスとワークフローってふたつのプロダクトがあって。で、インボイスの方が1月に出て、完全にRESTで作ってました、と。で、ワークフローを4月に出して、それをGraphQLで作ってみたんですけど、インボイスにあった「つらみ」みたいなのが全部解決された、みたいなくらいになりまして。
hidek：ふーん。
榎本：たとえば、「オーバーフェッチが防げる」っていうのがすごいな、と思ってて。よくあると思うんですけど、RESTとかでとりあえず全部詰め込んで返しちゃう、みたいな。
hidek：はい。
榎本：いろいろなエンベッドしたオブジェクトをとりあえず返しちゃう、みたいな。で、フロントエンドでよしなに使ってね、みたいなのとかって、結構、裏側で大変なことになってたりするじゃないですか？
hidek：はいはい。
榎本：DBから必要なもの全部フェッチして、詰め込んで、で、使わないのにリストの画面でも全部それを詰め込んで返す、みたいな。で、LayerX インボイスとか、よくよくクエリ数を数えてみると大変なことになっていて。それって、「toBって足し算だよね」みたいなところから、もう、しょうがないとは思いつつ。「すごくリッチなことやってんなー」とか、裏側で「コードもすげーことになってきたなー」っていうので、すごくやめたかったんですよね。
hidek：うんうん。
榎本：で、そこをGraphQLでしたら、もう、クライアントサイドがほしいものを「これくれー」って言ったフィールドだけ返せて。で、ほかのフィールドは一切オブジェクトを作る必要がないので。
hidek：はいはい。
榎本：で、しかも、ちょっと、Goの「gqlgen」っていうフレームワークだからできていることかもしれないんですけど、そのエンベッドしたフィールドを、本当にコーディング上、切り出して書けるんですよね。
hidek：うーん。
榎本：すげー説明しづらいな。アルバム一覧を返します。アルバム一個一個にはCDがn個紐づいてます。ってなったときに、一旦、アルバムを全部返しておいて、で、アルバムの中にCDのIDみたいなのがプロパティにあるとして、「このCDのIDは何のCDのオブジェクトだ」っていうのを、別途一個書いておけば、それだけが使われる、みたいな感じなんですよ。
hidek：はいはい。
榎本：伝わります？ ごめんなさい。すげー説明が下手な気がする（笑）。なので、定義するコードを、すごく、2種類に分割できて、アルバム一覧を返すだけ。で、CDのIDが来たらCDのIDを返すだけ。って2種類のすげー独立したコードを返すだけでそれが実現できる、みたいなのが、めちゃくちゃコードの見通しがよくなって、「最高やん」みたいな気持ちになったりですねー。
hidek：結構、うちも、GraphQLのガチ勢が何人かいて、tenntennさんとかvvakameさんっていうのがいて。
榎本：vvakameさん、やばいっすね。うん。
hidek：啓蒙活動を社内でめっちゃするんで。そうそう。で、メルペイで、まだ、GraphQLを使えるところはすごく限られていて。今後もちょっと……。特に外向けのAPIで使っていこうかな、って、なんか、してますね。
榎本：はいはい。そうですね。GitHubとかも、外向けでGraphQL使ってますし。
hidek：そうそう。
榎本：Shopifyとかもかな。うん。vvakameさんのGraphQLのオンラインイベント・座談会みたいなのは僕も入らさせていただいて。
hidek：はい。
榎本：で、「マジもんだな」とビクビクしながら話しました（笑）。
hidek：うちに入社したのが2018年とかで、そのときからGraphQL って言ってたからね。
榎本：うんうん。いや、RESTに比べて大好きになりましたね。
hidek：RESTはねー。僕はあまり、もともと、REST好きじゃない、って言うとあれなんだけど……。
榎本：うん（笑）。
hidek：そっかそっか。今、じゃあ、GraphQLに置き換える、みたいなことは考えてるの？
榎本：RESTから？
hidek：うん、GraphQLに置き換える。
榎本：そうです。徐々にやろうとしてます、そこは。ただ、LayerX インボイスは、結構、ファットというか、機能も増えてきたので、あんまり一足飛びにやる気はない、って感じですね。
hidek：なるほどね。なかなか、その辺の移行も、さっきのマイクロサービスの話じゃないけど、ちょっと、遅くなればなるほどつらくなるし。
榎本：そうですね。
hidek：かと言って、「事業スピード的に今？」っていうのもあったりとかして。その辺の判断も難しいですよね。
榎本：うん。なので、「新しくこれから作るところに関してはGraphQLやってもいいかもね」みたいな、それくらいのテンションでまずはやってます。
hidek：うんうん。その辺も、今、DX事業部のところは、mosaが判断してやってる？
榎本：そうです。はい。
hidek：なるほどね。
この記事が気に入ったらサポートをしてみませんか？