本気でプロダクトに向き合うCTOになるために必要な事 (技育祭2024春)

技育祭2024春のスライドです。

価値のあるプロダクトをつくるエンジニアになるための話と、自分がどういうキャリアでそうなっていったかを話します。

Transcript

1. © LayerX Inc. 本気でプロダクトに向き合うCTOになる為に 必要な事 LayerX CPO/創業CTO 榎本悠介 ( @mosa_siru ) 2024/03/16 (技育祭2024春)
2. © LayerX Inc. 2 LayerX バクラク事業部執行役員 CPO/創業CTO 東京大学工学部卒。株式会社ディー・エヌ・エーに新卒入社後、 株式会社Gunosyに入社し、両社にて複数の新規事業立ち上 げをリードエンジニアやPdMとして牽引。 2018年にLayerXを取締役CTOとして立ち上げ。現在はバ クラクシリーズ全ての新規プロダクトの開発を主導。 ボンバーマンの実力のみでテレビに出ました。 自己紹介
3. © LayerX Inc. 3 全ての経済活動を、デジタル化する。 会社概要 会社名 株式会社LayerX（レイヤーエックス） 代表取締役 代表取締役CEO　福島 良典 代表取締役CTO　松本 勇気 創業 2018年 8月1日 資本金 約132.6億円 拠点 東京本社　〒103-0012 東京都中央区日本橋堀留町１丁目９−８ 人形町PREX 関西支社　〒530-0003 大阪府大阪市北区堂島1-1-5 関電不動産梅田新道ビル 中部支社　〒453-6111 愛知県名古屋市中村区平池町4-60-12 グローバルゲート 九州支社　〒810-0801 福岡県福岡市博多区中洲3-7-24 従業員数 250名 （2023年12月末日時点）
4. © LayerX Inc. 4 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 事業紹介 バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン
6. © LayerX Inc. 6 B2B SaaS としてコンパウンドなプロダクト群を提供
7. © LayerX Inc. 7 ※一部企業様を抜粋して掲載しています（2023年5月時点）。 製造 不動産・物品賃貸 情報通信 建設・運輸 施設・店舗運営 金融・保険 卸売・小売 士業事務所 非営利法人 シリーズ累計導入社数 10,000社以上
8. © LayerX Inc. 8 価値のあるプロダクトをつくるエンジニアになるための話と、 自分がどういうキャリアでそうなっていったかを話します。 今日の話
9. 目次 Agenda 1. プロダクトの価値を生むエンジニアになるために 2. キャリアに対する考え方と、どういうキャリアを 歩んできたか 3. もしアドバイスをするとしたら
10. 質問：プロダクトの価値とは？
11. © LayerX Inc. 11 プロダクトの価値とは何だと思いますか？ • 機能数が多いこと？ • バグがないこと？ • デザインが美しいこと？ • 最新技術が使われていること？ • ソースコードが綺麗なこと？ • 自動テストがたくさんあること？ • ドキュメントが整備されていること？ 意味もなくAIによって作られたイラスト
12. プロダクトの価値は どれだけ課題や要望を解決しているか！
13. © LayerX Inc. 13 プロダクトの価値は、どれだけ課題や要望を解決しているか 以下は、そのための手段に過ぎない。 • 機能数が多いこと • バグがないこと • デザインが美しいこと • 最新技術が使われていること • ソースコードが綺麗なこと • 自動テストがたくさんあること • ドキュメントが整備されていること (むしろフェーズとプロダクト特性によっては意図的に軽視するものもある)
14. © LayerX Inc. 14 使われないプロダクトは、どれだけ綺麗につくっても…ということに なります。 “価値”（アウトカム）を生めるエンジニアであってほしい！ ※これは1つの評価軸にすぎません！例えば最新技術のキャッチアップのために、自分向けのプロダクトを開 発するとかは全然ありだと思います！
15. 価値を生むエンジニアになるためには？
16. ドメインにディープダイブする
17. © LayerX Inc. 17 ひたすらドメインにディープダイブする、ユーザー理解をする ドメインとは、例えばSaaSなら、対象としている業務領域のこと。 • 実際にその業務をしてみる、本を読み漁る • ひたすらユーザーヒアリングする、作ったものを触ってもらう ◦ バクラクはリリース前に100社近くヒアリング・デモしました • 競合プロダクトをドン引きされるくらいリサーチし、触る（特にtoC） ◦ 海外プロダクトのサポートサイトを見るなど、やれることはいくらでもある その上で、バシバシやらないことを決める。どれだけ機能を作っても、使われるものしか価値はない （ビルドトラップ）。 エンジニアだからPdMだからとかは関係ない。むしろドメインを知らないで良い設計はできない。
18. 最速でループを回す
19. © LayerX Inc. 19 最速でループを回す 以下の作業と手戻りを、細かくループすることでプロダクトはつくられていく。 • ヒアリングする • 仕様をつくる • 画面設計・紙芝居をつくる • API・DB設計をする • フロントエンド実装する • バックエンド実装する • 動くものを触る スクラム開発のイテレーションとかいうレベルではない、超細かいループを回しまくる。
20. © LayerX Inc. 20 この細かい単位のループこそが、プロダクトを良くする本質的なプロセス。 細かい手戻りは悪じゃない！
21. © LayerX Inc. 21 ループの中で、エンジニアだからこそ気付けることが沢山ある • 実際に開発することで、ぬけもれに気づける ◦ 修正箇所の周辺コードを読み、考慮漏れに気づく（めっちゃある！） ◦ 修正箇所のメソッドを呼び出しているところを見て、他の仕様への影響に気づく（めっちゃあ る！） • 実際に設計することで、ぬけもれに気づける ◦ 例： DB設計するときに、NULLがありうるのかどうかで大きく分かれることに気付く。 ◦ 例： リレーションを考える時に、考慮漏れに気付く • 開発中のものを触ることで、ぬけもれや体験の違和感に気付ける これらを事前にすべて想定しておくことは人間の能力を越えるので、いかに速くループを回し、仕様再 考に戻ることができるかが鍵。
22. © LayerX Inc. 22 最速でループを回すために、フルスタックになろう！ フロントやバックエンド、インフラ等をまたいで一気通貫で開発ができるようになると、一人でループを高速 にまわせるようになります。 さらに言うと、手を動かさなくても脳内である程度のループをまわすことができます。 複数人で分業して行うと、どうしても1つ1つのループにコストがかかってしまいます。 • 前提を揃えるコスト • 資料作成コスト、コミュニケーションコスト • 実行して確認し合うコスト • 合意形成コスト ドメイン知識をベースに、「このユーザーストーリーは自分が主役だ！！！」くらいの覚悟で開発しましょう。 そして、デザインやその他の技能があると、さらに高速にループを回すことができます。要は全部やろう。
23. その他、大事な考え方
24. © LayerX Inc. 24 シンプルな仕様にしよう！ • 複雑なものは伝わらない、使われない • 複雑な仕様は開発が大変、負債も巨大 • 複雑な仕様は品質が低くなる 複雑な仕様は何かが間違っているという嗅覚を持とう。 もっと工夫して考えれば、それに準じた体験を満たせるはず。 仕様をシンプルにすることは妥協ではない！
25. © LayerX Inc. 25 エンジニアリングのもと、コスパの良い仕様に落とそう！ 見積もりができる • 概算で問題なし。脳内で「やばいか」「やばく ないか」肌感でわかることが大事 • 短期だけでない、長期の負債にならないか 判断できる • 既存のシステム仕様に追加したときのやば さの嗅覚がある アウトカムがわかる • この仕様にしたときに、ユーザーにどれだ けのメリットがありペインが解決できるか わかる • どこまで仕様を簡易にしてもユーザー体験に影響しないかわかる • 一方で、妥協してはいけないポイントがわかる • 既存のシステムと整合性がとれ、負債になりにくい仕様に落とすことができる コスパの良い落とし所がわかる ＋
26. © LayerX Inc. 26 ユーザーに言われた通り作らない • 顧客の本当のお気持ち、真のペインを解決するものを作る。 ◦ そもそも、その業務フロー・使い方はあるべき姿か？ ◦ お客様はHowのプロではない。WhyからWhat, Howを作るのはこちらの役割。 • 複数の要望を抽象化して満たせるものを作る。カスタマイズをしない。 ◦ 作れば作るほど訳のわからないプロダクトになっていく。
27. 次に、どんなキャリアのもと、 今の考え方に辿り着いたかを見ていきます
28. キャリアに対する考え方
29. © LayerX Inc. 29 今から計画しないと… キャリアに対してどう考える…？ 3年後にCTOになるには… なにもわからん…
30. © LayerX Inc. 30 キャリアに対する考え方は2つある 1. 目標型 計画を立てる。強い目標を定義して逆算する。戦略 的に動く。 例: 3年後に◯◯領域で起業するために、まずはメ ガベンチャーに入ってスキルを得て、etc.. 登るべき大きな山を定義して、計画的に登る。 2. 場当たり型 計画は立てない。目の前のことに注力し続ける。 面白そうなところに飛びつく。 目の前の坂を場当たり的に登る。
31. © LayerX Inc. 31 キャリアに対する考え方は2つある 1. 目標型 2. 場当たり型 計画を立てる。強い目標を定義して逆算する。戦略 的に動く。 例: 3年後に◯◯領域で起業するために、まずはメ ガベンチャーに入ってスキルを得て、etc.. 登るべき大きな山を定義して、計画的に登る。 計画は立てない。目の前のことに注力し続ける。 面白そうなところに飛びつく。 目の前の坂を場当たり的に登る。 皆さんはどっちになりたいですか？
32. © LayerX Inc. 32 目標型と場当たり型、どちらが良いとかではない。 「計画的じゃないといけない…」、なんてことはないよ！ 伝えたいこと
33. © LayerX Inc. 33 1. 目標型 • 絶対に絶対に目指すべき目標があるならこれ。 • 目標型でないと目指せない、目指しにくい場所 はある ◦ （極端な例）強い意思がないと、普通の学生 は政治家にはなれない • ガチガチに目標を固定する必要はない。仮決め でも良い。 ◦ 探索の中でフィードバックループを回して、 登るべき山を変えたり、登り方を変えても 良い。
34. © LayerX Inc. 34 いわゆる出世・活躍している人でも、計画的に動いていない人 は意外と多い。 • 「目の前のことを全力でやっていた」 • 「知り合いがいて、面白そうな会社だったので転職した」 全力で目の前の坂を登っていき、ふと景色を振り返ると、結果的 にでかい山に登っていたことに気付く。 2. 場当たり型
35. 自分は完全に場当たり型でした。 その場その場でどのように学んでいったか後述します
36. © LayerX Inc. 36 • 役職名・概念自体が次々に発明・細分化されている ◦ CTO, VPoE, EM, CPO, VPoP, PdM, PMM, PjM, UX Designer, UI Designer, Domain Expert etc… ◦ Data関係だけでも…、Data Engineer / Data Scientist / Data Analyst / Data Steward, Data Architect / Data Warehouse Engineer /Business Intelligence Analyst / Machine Learning Engineer / Data Product Manager / Data Governance Manager etc… • 技術の進歩によって生まれたものもあれば、体系化や細分化によって定義されたものもある • 目指すというより、結果的になっていることが多いのではないか。 ◦ 「真剣に向き合った結果、世の中的にはそうカテゴライズされるムーブになっていた」 役職は目標にするべきもの？
37. © LayerX Inc. 37 そもそも、このスピード感でAIが進化するってわかっていた人ってどれくらいいた…？ それくらい劇的に変わる世の中なんだし、場当たり的に向き合っても、楽しんでもいいじゃない！ 遠い目標をつくるのって難しい…
38. 自分のキャリアの場合
39. © LayerX Inc. 39 自分のキャリア 学生時代：最後の1年のみエンジニアしていた。誰も使わない自己満足Webサービスを独力で作る人。 DeNA新卒：サーバーサイドエンジニア • 1年目、信頼性の高い大規模APIを運用、そのアーキテクチャを知る • 2年目、新規事業の立ち上げ。狂気的なプロダクト愛と開発を目の当たりにする Gunosyに転職: フルスタックエンジニア → 新規事業開発室長, プロダクトマネージャー • 新規プロダクト開発を通してフルスタックになりながら、数値による意思決定とマーケを知る • ブロックチェーン開発チームを立ち上げ LayerX立ち上げ: 取締役CTO → SaaS事業部長 → 事業部CTO/CPO → 事業部CPO • ブロックチェーン事業に必要なことをなんでもやる人 • SaaS(バクラク)立ち上げのために開発しまくる人
40. © LayerX Inc. 40 DeNA新卒1年目 昔からインターネットが好きだったので、Web系の会社の選考をいくつか受け、最初に内定いた だいたので入社（場当たり的…）。 「一番技術力がつくところに配属してください！」という希望を出し、Platform APIを見る部 署に配属（嬉しい）。以下を学ぶ • 大規模アクセスを捌くAPIのアーキテクチャ • 信頼性の高いAPIの開発手法 ◦ めちゃくちゃテストとQAプロセスがあった その分開発は窮屈な面があった＆斜に構えて全然成果出ていなかったので異動に…
41. © LayerX Inc. 41 DeNA新卒2年目 新規事業の立ち上げ。ゲーム・アニメ好きな人向けにパーソナライズされたニュースアプリを作るプロジェクト にアサインさせてもらいました（運）。 精鋭エンジニア3-4名の少人数チームと、狂気的なスケジュールを課すプロダクトオーナーのもと、新規事業 立ち上げに必要なことを学ぶ • 少人数開発の圧倒的速さ • プロのエンジニアの考え方 • 「実装できないとか無いので、一番最高の仕様を考えてください」 • 各種トレードオフの判断 ◦ 立ち上げ時はテストもドキュメントもほぼ無い（当初衝撃だった） • 裁量とそれに伴う責任 ◦ コードレビュー文化はなく、運用も含めて自分の責任 • 狂気的なプロダクトへのこだわりと愛 ◦ 最終的にマスコットキャラクターが地上波アニメになった
42. © LayerX Inc. 42 Gunosyに転職 友人である代表のfukkyy(現LayerX代表の福島) にかねてから誘われていた。「これからはアドテクノロ ジーの時代だ！」と熱弁され、面白そうだったから転職（場当たり的）。もうちょいちゃんと説明すると、エンジ ニアスキルの幅を広げたかったのと、給与に関する野心もありました。 入社後はアドテクではなく新規事業開発をCTO松本とタッグでする形に。以下そこで得た学び • フルスタックな開発スキル • マイクロサービス設計経験と圧倒的辛さ • 数値による分析と意思決定文化 ◦ 例：「数値は神より正しい」という信念のもと、全てをABテストし、異常があったらロールバック • マーケティングやビジネス上の座組の大切さ ◦ プロダクトそのものだけじゃない勝負があることを学ぶ（それまで純粋だった…） • エンジニアが他職種に入る大切さ （xOps) ◦ 「自社での広告運用頑張ればCPA(ユーザー獲得費用)安くできるのでは？」と雑に発言したら、 マジで広告運用を担当することになった。エンジニア全く関係ないと思いきや、業務効率化できた り、データ分析によってアドネットワークの不正を発見できたり、かなり効果があった（場当たり的
43. © LayerX Inc. 43 LayerX 立ち上げ Gunosyで新規事業開発室長としてブロックチェーン研究開発チームを立ち上げたのが、LayerXの元になりました。（現在LayerXはブ ロックチェーン事業はしていません） 取締役CTOですが、最初から狙ってそうなったとかではありません・・・これも場当たり的。 LayerXでは事業に必要なことはなんでもする必要があり、「エンジニアだから」とか言っている場合ではなく、ただ必要なことをがむしゃら にやっていました。コトに向かうことで沢山の経験ができました。 • 海外に出張、仮想通貨のマイニングファーム探し ◦ 電気代が安い場所を探す旅 • インドのブロックチェーン案件の開発・コンサル ◦ 英語全然わからん • ブロックチェーンの監査、営業 • 銀行等大企業向けのプロジェクトの営業・コンサル、開発 • カルチャー作り • 採用、発信 ◦ 本当に大事…！ • 経営・マネジメント（ほぼやったことなかった）
44. © LayerX Inc. 44 LayerX (バクラク事業) 立ち上げ ブロックチェーン事業からピボットする中で、SaaS（バクラク）事業を立ち上げました。 新規プロダクト全てで、自分ふくめ少人数がヒアリング, 仕様, 設計, 開発 を行う動きが型化できています （めっちゃコードかいてる）。半年に１つのペースで新プロダクトを立ち上げられています。 この事業で奔走する中で、前述したプロダクト開発に関する学びと確信を得ることができました。 • 少人数で、フルスタックに開発するスピード感と精度 • ドメインにダイブして、「使われるもの」に徹底的にこだわる開発スタイル これまでにない規模のチームとともに、急成長する事業を作り続けられています。 …こんなこと、全く想像してなかった！！けど楽しい！
45. © LayerX Inc. 45 余談：toCとtoBの違いって？ 結論：お客様のために良いモノを作るという意味では全く同じ。 言うとしたら・・・ • toC ◦ リリース後は数字に向き合うのが重要 ▪ きちんとログを取る、分析できる基盤をもつ • toB ◦ 一社一社にセールスやカスタマーサクセスがつくプロダクトの場合、めちゃくちゃお客さんの距離 が近い ▪ 要望がリアルタイムにどんどん来る！ ▪ 良いモノをつくればダイレクトに喜んでもらい、微妙なモノをつくるとダイレクトに悲しい反 応が来る ◦ 業種業態・企業サイズによって業務フローが大きく異なることがある。要望の抽象化が大事
46. 最後に、もしアドバイスするとしたら
47. © LayerX Inc. 47 もしアドバイスするとしたら • 目の前のことを120%でやろう！ ◦ やるべきことをやるのは当たり前。コトに向かうと自然と120%の動きになる。（斜に構え て良いことないです…） • 仕事を選びすぎない。実は気づいていない得られるものがある。 ◦ 事業に必要なことだと思ったら、コンフォートゾーンを抜けて、慣れない領域でもやってみ よう！それがコトに向かうということ。 ◦ 究極、今はプロダクトの機能改善よりマーケが大事なフェーズなら、マーケをするか、マーケにレ バが効くようなエンジニアリングをする。そんな動きができるようになってくると、唯一無二の 「場当たり型」になれます。
48. © LayerX Inc. 48 複利を得よう！ • 結果を出すと信用を生み、信用が次の機会やアサインを生み、次の機会をモノにする と、さらなる信用と能力を生む。 • 機会は平等じゃない。能力と信用は雪だるま式に上がる。 成果・能力 機会 信用 超がんばる..！
49. © LayerX Inc. 49 • 成長は複利できくので、自分で自分を追い込むのも必要 ◦ mosaは新規プロダクトを作る時、「マジかよ」ってくらいの期限をとりあえず自分に 課す。目指さないと達成できない、結果できなかったとしても。 ◦ （とはいえ生存バイアスには注意。自分を守るのも自分…） • 裁量マジ大事。意思決定の数と密度が人を育てる。
50. © LayerX Inc. 50 補足：目の前のことをやるとはいえ… どこでも良いかでいうと、環境による違いがあるのは否定できない • 全体が伸びている環境だと、機会（打席やポジション）ができやすい。 • 情報が積極的にシェアされたり集まる環境、見晴らしの良い場所にいると良い。 ※とはいえ守備・撤退戦だからこそ学べることもたくさんある
51. 皆さんが”価値”のあるプロダクトをつくるエンジニアにな れることを応援しています！
52. © LayerX Inc. 52 最高のプロダクトと事業をつくっていきたい方を募集しています！ https://newgrads.layerx.co.jp/ LayerXでは絶賛採用中です！