プロダクトヒストリーカンファレンス2024 - 登壇資料

ニーリー三宅さんと共同登壇した内容になります。

Transcript

3. 自己紹介 株式会社LayerX Fintech事業部 VPoE LayerX Fintech事業部にてエンジニアリング組織の マネジメント全般・エンジニア組織運営を担当。 ALTERNA(個人向け投資サービス)の開発も並行して実施。 以前はPairs(エウレカ) で開発責任者・バックエンドチームの EMやDeNAでソーシャルゲーム開発など。 Kentaro Takahashi 髙橋 健太郎
4. 自己紹介 株式会社ニーリー 執行役員 CTO / Enterprise AccountmangentG GM Katsuhide Miyake 三宅 克英 2017年にニーリーに2人目で参画。 CTOとしてプロダクト組織を統括しつつ、 toB/toCのカスタマーサクセス→BizOps→マーケティングの責 任者を兼任。最近はエンタープライズ カスタマーサクセスに挑 戦中。 以前は、証券会社や銀行に向けた、FXシステムやリスク管理シ ステムの開発PMを担当。
5. 自己紹介 株式会社ニーリー プラットフォーム開発グループ GM 2021年にニーリーに2人目エンジニアとしてジョイン。 SREチームとQAチームを立ち上げた後、プラットフォーム開発グ ループのマネージャーを担当。 以前はDMM.comにて動画配信基盤の開発や動画プレイヤーの UI/UX改善に従事。 Hiroaki Kikuchi 菊地 弘晃
7. 事業紹介 - LayerX Fintech事業の構成
8. 事業紹介 - LayerX
9. 事業紹介 - LayerX 全社 64名 (2023年7月時点)
10. 事業紹介 - Nealle
11. 事業紹介 - Nealle Nealleのプロダクト開発組織
14. ①立ち上げ期 x 成功談 - LayerXの場合 管理画面を自前で用意しない / こだわる部分とそうでない部分を決めた • 以前の職場で管理画面のフロントのスタックが古くなり苦労した経験があったので、ALTERNAでは 管理画面のフロントエンドにSaaSを活用 。 • 投資案件が見える部分と、口座開設を重要ファネルとして設定して、体験の根幹 を決めた。 • 「あったら良いかも」というアイデアを「やらない」という意思決定をした。 • アーキテクチャ含めた考慮の時間が不要になり1-2ヶ月程度の工数短縮 に繋がった。 • 根幹の体験が担保でき、狙いのKPIを達成 することができた。
15. ①立ち上げ期 x 成功談 - Nealleの場合 オフショア開発の活用と内製開発への早期切替 • 初期開発はインフラからアプリまで全てオフショアで開発 を実施。要求とデザインのみ日本で。 • ローンチ後から日本内製開発とのハイブリッド開発に、その後完全内製 へ。 • エンジニアリソース確保とコストメリットだけではなく、“時間”の確保 ができた。 • 早めに内製にシフトしたことにより、コミュニケーションやドメイン知識理解のオーバーヘッドを 抑えることができた。
17. ②立ち上げ期 x 失敗談 - LayerXの場合 「だろう設計」によりデータモデリングが理想から乖離 • 「一般的な証券システムならこのようなデータだろう」という想定でテーブルを初期設計 。 • 実際に運用してみると後から「このテーブルのカラムは別のテーブルにあるべき」といった凝集度 や取り回しが課題 になることが散見された。 • (当たり前だが)必要になったタイミングで必要になった設計 をすべき。 • 設計面のレビューは対象の理解度が高い状態 でするべきだった。
18. ②立ち上げ期 x 失敗談 - Nealleの場合 コアとなる設計が甘く、今も苦労中・・・ • 言語選定、開発環境構築、アーキテクチャ、データモデル、全てオフショア開発にお任せ した。 • 特にデータモデルはペインが大きく 、解消のために去年約1年かけてお金関連のドメイン（ソース の40%）を作り直した。 • 後から変更することが大変な部分についてはやる・やら、どこまでやるかをちゃんとジャッジ すべき。 • とはいえ、事業グロースのための機能開発スピード優先は変えない。
20. ③急成長期 x 成功談 - LayerXの場合 エンジニアが要件定義をやることで取り扱い高アップ！ • より投資していただくための施策の開発が必要だったが、PdMは一人しかいなかった。 • PdMは役割と割り切り、エンジニアがドメイン知識をキャッチアップ して企画もする方向性に切り替 えた。 • エンジニアが周囲を巻き込みながら複雑な施策の要件定義・プロジェクトマネジメント全般を進行、 大玉の開発を並列で実行 できた。 • 企画リソースが増えた事で、1,2日でリリースできる改善施策から成果が出た。
21. エンジニアが事業サイドに染み出すカルチャー/プロセスにこだわった • 何を作るかはエンジニアが決める！ ビジネスサイドとはヒアリングやディスカッションの場を設定。 • 機能が足りなくてもGo、業務をやりながらプロダクトへ高速にフィードバック 。 • エンジニアがユーザーや業務解像度を上げて、必要なものを自ら考え開発する のが一番いいモノを 早くデリバリーできると信じている。 • 営業の勢いを止めない 。 • やってみて気づくことも多いので、無駄なモノを作らない で済む。 ③急成長期 x 成功談 - Nealleの場合
23. ④急成長期 x 失敗談 - LayerXの場合 法律周りのレビュープロセスが属人化していて品質が悪化 • 専門家のレビューが必要な複雑な処理において、レビュープロセスが属人化 していて品質問題に発 展。 ◦ 配当における税金の扱い→税理士、法定書面の記載内容の正誤→弁護士 etc… • 専門性が高い部分において、開発しながら仕様を理解しようとしてしまった。 • 事前に「どのような開発物」ならばレビューを受ける必要があるのか明確 にしておくべきだった。 ◦ 例: 金商法、景表法など • ウォーターフォール的に仕様がカッチリ決まっているものは明確にしてから開発すべきだった。
24. ④急成長期 x 失敗談 - Nealleの場合 繰り返すコトへの投資が遅かった • CI/CDをちゃんと作るのが遅く、手動対応や深夜メンテを長く続けて しまった。 • 組織が拡大し、エンジニアに対する問い合わせ が爆増。 • 開発する時間が奪われる + 事業が伸びて組織が拡大 → 指数関数的に苦しく なっていく。 • エンジニアリングに費やせている時間を可視化 すべき。 • 時間を生み出す施策 に投資をすべき。
25. © LayerX Inc. 25 - それっぽい思い込みで開発せず、仕様をシンプルに保つ - 施策の開発は、1つの目的に対して１つの解決策 - ドメインを理解することによりコミュニケーション・実装の質を上 げる まとめ
26. ニーリー採用情報など