「ドメインにディープダイブする」「最速でループを回す」　LayerX・榎本氏が考える、価値を生むエンジニアになるために必要なこと

LayerX・榎本悠介氏の自己紹介

榎本悠介氏：よろしくお願いします。LayerXの今CPOで、取締役CTOの榎本と申します。「mosa」と呼ばれています。技育祭に出るのが初めてなので、楽しみにしていました。よろしくお願いします。

さっそくなんですけど、僕の自己紹介から始めます。ちなみにLayerXっていう会社を知っている人はいますか？　さっそくチャット欄を……（コメントを見て）あっ、ありがとうございます。ありがとうございます！　うれしいです。聞いたことだけある。いや、うれしいです。ありがとうございます。

あとから会社紹介するんですけれども、LayerXはいくつか事業をやっていて、僕は「バクラク」事業というSaaSを作っている事業の執行役員のCPO（Chief Product Officer）兼創業CTOという役職にいます。

経歴としては、最初ディー・エヌ・エーに新卒入社して、そこからGunosyというニュースアプリの会社に行って、そこでエンジニアやプロダクトマネージャーとして、新規事業をいろいろ立ち上げたりして、そこからLayerXを立ち上げた、というかたちになります。

バクラクというSaaSにはいくつかシリーズがあるのですが、そちらの新規プロダクトの開発を全部主導しているという動き方を今しています。

『ボンバーマン』ってゲーム知っているかな？　爆弾を扱う謎のゲームがあるんですけど、それを学生時代にやりすぎて、あまりにも極めすぎて、テレビでキスマイさんとか、タレントさんと一緒に『ボンバーマン』をやったことがあります。

あと、「ニコニコ生放送」という古の実況配信者だったりと、けっこういろいろな活動をしていました。「YouTube」にいろいろ動画が上がっているので、もしよかったら、という感じです（笑）。

「すべての経済活動を、デジタル化する。」をミッションに掲げている

では、LayerXの紹介ですね。「すべての経済活動を、デジタル化する。」というミッションでやっています。今はもう従業員は300名近いです。

どんな事業をやっているかで言うと、3つですね。今僕がいるバクラク事業というBtoBのSaaSを開発する事業と、三井物産さんと合弁で、不動産関係のアセットマネジメント。不動産を運用して、個人の投資家さん向けに安定したアセットとしてアクセスしやすく購入できるかたちにするという事業をやっていたり、生成AIに関する事業をやっていたり、いくつかの事業をやっています。

まぁ、正直、今は関係なくていいやくらいの覚悟で3つやっています。

その中で、僕は今「バクラク」というものをやっています。これらは、ラインナップが5つあって、今1万社以上に導入されているSaaSです。

例えば、法人向けのクレジットカードを提供したり、「会食したよ」とか、そういうのを申請したり、承認したり、請求書を受け取ったり発行したりというのを楽にするいくつものプロダクトを提供しています。

請求書とかは、もしかしたらなじみが薄いかもしれませんが、けっこうコーポレート業務、企業の業務にとって本当に大切かつ大変なプロセスをカバーしています。

そこを技術の力で……まさに今の生成AIもそうですし、OCRもそうですし、そういったのをベースに、これまである種しんどかった、けれどもミスは許されなかったところを、本当に「バクラク」にしようと、楽にしようというプロダクトを提供しています。

たくさんのお客さまに使っていただいているプロダクトを提供している会社です。

プロダクトの価値って何でしょう？

では、さっそくですが、今日の話ですね。価値のあるプロダクトを作るエンジニアになるための話と、自分がどういうキャリアでそうなっていったか、あるいは、そういう考えをするようになったかというのを話していきます。

目次もそんな感じでいきます。

じゃあ、質問です。いきなり抽象的な質問なんですけど、プロダクトの価値って何だと思いますか？　チャット欄で欲しいんですけど。何でしょう？　たぶん、何を書いていいかわからないと思うので、いくつかちょっと書いてみました。

例えば、「機能数が多いこと？」「バグがないこと？」「デザインが美しいこと？」「最新技術が使われていること？」「ソースコードがきれいなこと？」「自動テストがたくさんある？」「ドキュメントが整備されている？」……ありがとうございます、チャット欄、どんどんください。

いいですね。そうですね。「存在するだけで価値がある」「機能性」「『めんどい』の解決」「安全性」「使いやすい」。いいですね。めっちゃいい。ありがとうございます。

ちなみに（スライドの）右下は、本当に意味もなくAIによって、僕が「シンキングタイム」と入れたら出てきたイラストです。ちょいちょい意味のないイラストが出てきます。

直接ユーザーに結びつかないところは全部手段にすぎない

じゃあ、答えというか、僕が考えることなんですけれども、みなさんさすがですね。まさにチャット欄に出てきた、どれだけユーザーの課題や要望を解決しているかとか、ニーズやペインを解消しているか。それが一致していること。いや、本当にそのとおりでございます。

先ほど挙げたやつって、ある種手段にすぎないんですよね。1個1個とても大事ですが、どれだけ課題や要望を解決しているかの手段にすぎなくて、機能が多ければ、解決する機能もあるかもね、みたいなくらいの話でしかない。

逆に言うと、（機能が）多すぎると、逆に訳わからないプロダクトになってしまう。社内では、「キメラになる」と言ったりするのですが、キメラみたいなプロダクトになってきて、逆に誰も使いこなせない、みたいになってくるかもしれない。

あとは、バグがないことを求めすぎると、逆に変なQAになってくる。「よくわからないけどこのボタンを連打したらバグるぞ」とか、「いや、誰も連打しないわ」みたいなのとか（笑）、そういうのは極端な例にしても、手段と目的はやはりちょっと違うよねという話です。

デザインの美しさもとても大事ですし、技術的に攻めていることも大事だと思うんですけど。直接ユーザーに結びつくわけではないところは、全部手段にすぎないと思うことが大事なのかなと思います。

フェーズとプロダクト特性によっては、僕はけっこう無視するものも正直あります。「開発したての時は、ドキュメントは一切書かない」とかはぜんぜんあるかなと思います。

どれだけがんばって美しく作っても、使われなければ正直意味がないので、価値を生めるエンジニアであってほしいというのがあります。

もちろん、最新技術のキャッチアップのために自分向けのプロダクトを作ってみたとかは、ぜんぜんありだと思います。そうじゃなくて、本当に使われるプロダクトをみなさんには生んでほしいし、（生める）エンジニアであってほしいし、僕もそうありたいと思っています。

とにかくユーザーを理解することが大事

「じゃあ、そのためにどうすればいいですか？」というので、はい、どんどんいきます。

よく言われることかもしれませんが、僕は本当にこれが一番大事だと思っていて、とにかくドメインにディープダイブすること、ユーザーを理解することにつきると思っています。これを軽視すると、本当にもう誰にも使われないプロダクトになってしまいます。

例えば、経理領域だったら会計業務について理解するとか、SaaSだったら対象としている業務について理解するとか、toCでもそうですね、ゲームだったらそのゲームを使っているユーザーの気持ちをどれだけ深く知れるかとか、いろいろなタイプのユーザーがいることを理解するだとか。

料理アプリだったら、料理をしているいろいろな属性の方の気持ちを理解するとか。いつ、どういう時間に、どういうテンションで料理のことを考えているか、みたいなところを本当に徹底的に知るところから始まると思います。

会計業務だったら、本当に実際にその業務をしてみる。「経理やらせてください」みたいなかたちでやってみるとか、それに関する本を読み漁るとか、あとはもうわかりやすく、ひたすらユーザーヒアリングをする。ヒアリングも本当に技術が要るので、そこもおもしろいです。

あとは、作ったものを触ってもらうとか、見てもらうとか。実際、「バクラク」というSaaSは、リリース前に100社近く回ってヒアリングしたり、デモさせてもらったりしました。

競合プロダクトをドン引きされるくらいリサーチする

あとは、競合プロダクトをドン引きされるくらいリサーチするのが大事かなと思っていて、競合、ないしは似ている、ないしは参考になるプロダクトを（リサーチする）。

ドン引きされるってどういうレベル？　という感じなんですけど、toCは触りやすいですよね。toBだとなかなか触りにくいところがあると思うんですけど、toCだったら、すべての機能を知っているのは当たり前ですし、すべてのアップデートをいち早く検知しているのも当たり前ですし、「この設定、こういじったらこう変わる」みたいなところを知っているのも当たり前ですし。

あとは、toBであまり触れないとしても、海外プロダクトだとしても、サポートサイトを見ればだいたいわかるとか、いろいろ技があるので、徹底的にやれることはやって、そのドメインについて理解していくことが大事になってきます。

機能はなるべく作らないという精神が大事

その上で、やらないことをどんどん決めていく。先ほど言ったように、キメラになっていくので、機能はなるべく作らないという精神が大事かなと思っています。

逆に、作れば作るほど人は安心しちゃって、「俺たち仕事しているぜ」みたいな気分になっちゃうんですけど、そういうのをビルドトラップとよく言うんですよね。作る罠にはまっちゃっている。むしろ、作らないことが大事だという話があります。

なので、ここはもう、エンジニアとか、プロダクトマネージャーとか、デザイナーとかまったく関係なくて、むしろエンジニアだからこそドメインにめっちゃダイブしてほしいと思っています。

ドメインを知らないで、「よくわからないけど、この要件を満たすために設計しました」とかって、絶対いい設計にならないんですよ。だいたい、次の仕様変更で崩壊します。

今のスナップショットだったらいい設計かもしれないけれど、ドメインのことを知らないで設計したことによって、次の仕様変更で「あっ、前提崩れました」みたいなことがめっちゃあるので、ドメインをめちゃくちゃ知りましょうというのが、まずあります。

プロダクト開発で大事なのは最速でループを回すこと

次に、最速でループを回すことがプロダクト開発ではめっちゃ大事だと思っています。

「最速でループとは何ぞや？」って感じなんですけど、プロダクト開発って、いわゆるウォーターフォールとかスクラムとかはいいんですけど、それ以上の細かい単位の話で、スクラムにおける1スプリントよりもさらに細かい営みによってされています。画面設計を作る、API・DB設計をする、フロントエンド開発する、バックエンド開発する、できたのを触るとか。

そのへんがけっこうグルグル回るのが、僕はいいプロダクト開発だと思っています。もちろん最高なのは、仕様を決めて、画面を作って、DB設計して、バックエンド作って、フロントエンド作って、触って、OK、なんですけど、まぁそれは、無理なので。

むしろ、リリースまでいかに早く手戻りをするかが大事だと思っています。画面を起こしてみたら、「なんか違和感あるな」と言って、仕様を決めるプロセスにちょっと戻ったり。

あとは、DB設計してみたら、「なんかこのスキーマおかしいな」、「ここ、NULLになったらどうなるんだっけ？」みたいなところで、仕様がおかしいと気づいて戻ったり。

ほかにも、実装フェーズに入ったら、「あれ？　ここ、影響範囲あるじゃん」みたいな、「このメソッドいじる必要あるけど、ここのメソッドを呼び出している箇所がほかにもあるから、つまりこの機能に影響するってことじゃん」みたいな感じで戻るとか。

そういった、すごく細かいループがあるんですよね。もちろん、動いたものを触ってバグを見つけて戻ることもあります。各スポットスポットで手戻りポイントがあって、いかに早く手戻るかが、僕は大事だと思っています。手戻ることは、すごくいいことだと思っています。

その中で、エンジニアだから気づけることがすごくたくさんあって、例えばコードベースで抜け漏れに気づける。

「このメソッド、ほかでも呼び出されているからここにも影響あるじゃん」とか、あとは、データベースレベルで、先ほどのNULLの話とか、あるいは、「ユニーク制約上、変なことになるぞ」ということに気づくとか、リレーションで、「あれ？　これ実はN対1じゃないとおかしくない？」と気づくとか。

実装・設計両面において、エンジニアだからこそ気づく仕様の抜け漏れや違和感があったりするんですよね。

あとは、ローカルですぐ触れるので、ローカルで自分で作ったのをすぐ触ってすぐ気づくみたいこともあるし、最強のプロダクトマネージャーとか仕様を作る人は全部想定できるかもしれませんが、そんな人いないので、いかに速く細かいループを回せるかが大事だと思っています。

（次回へつづく）