Upgrade to Pro — share decks privately, control downloads, hide ads and more …

事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談

Avatar for Nealle Nealle
November 29, 2024

 事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談

Avatar for Nealle

Nealle

November 29, 2024
Tweet

More Decks by Nealle

Other Decks in Programming

Transcript

  1. 自己紹介 株式会社ニーリー 執行役員 CTO / Enterprise AccountmangentG GM Katsuhide Miyake

    三宅 克英 2017年にニーリーに2人目で参画。 CTOとしてプロダクト組織を統括しつつ、 toB/toCのカスタマーサクセス→BizOps→マーケティングの責 任者を兼任。最近はエンタープライズ カスタマーサクセスに挑 戦中。 以前は、証券会社や銀行に向けた、FXシステムやリスク管理シ ステムの開発PMを担当。
  2. ①立ち上げ期 x 成功談 - LayerXの場合 管理画面を自前で用意しない / こだわる部分とそうでない部分を決めた • 以前の職場で管理画面のフロントのスタックが古くなり苦労した経験があったので、ALTERNAでは

    管理画面のフロントエンドにSaaSを活用 。 • 投資案件が見える部分と、口座開設を重要ファネルとして設定して、体験の根幹 を決めた。 • 「あったら良いかも」というアイデアを「やらない」という意思決定をした。 • アーキテクチャ含めた考慮の時間が不要になり1-2ヶ月程度の工数短縮 に繋がった。 • 根幹の体験が担保でき、狙いのKPIを達成 することができた。
  3. ①立ち上げ期 x 成功談 - Nealleの場合 オフショア開発の活用と内製開発への早期切替 • 初期開発はインフラからアプリまで全てオフショアで開発 を実施。要求とデザインのみ日本で。 •

    ローンチ後から日本内製開発とのハイブリッド開発に、その後完全内製 へ。 • エンジニアリソース確保とコストメリットだけではなく、“時間”の確保 ができた。 • 早めに内製にシフトしたことにより、コミュニケーションやドメイン知識理解のオーバーヘッドを 抑えることができた。
  4. ②立ち上げ期 x 失敗談 - LayerXの場合 「だろう設計」によりデータモデリングが理想から乖離 • 「一般的な証券システムならこのようなデータだろう」という想定でテーブルを初期設計 。 •

    実際に運用してみると後から「このテーブルのカラムは別のテーブルにあるべき」といった凝集度 や取り回しが課題 になることが散見された。 • (当たり前だが)必要になったタイミングで必要になった設計 をすべき。 • 設計面のレビューは対象の理解度が高い状態 でするべきだった。
  5. ②立ち上げ期 x 失敗談 - Nealleの場合 コアとなる設計が甘く、今も苦労中・・・ • 言語選定、開発環境構築、アーキテクチャ、データモデル、全てオフショア開発にお任せ した。 •

    特にデータモデルはペインが大きく 、解消のために去年約1年かけてお金関連のドメイン(ソース の40%)を作り直した。 • 後から変更することが大変な部分についてはやる・やら、どこまでやるかをちゃんとジャッジ すべき。 • とはいえ、事業グロースのための機能開発スピード優先は変えない。
  6. ③急成長期 x 成功談 - LayerXの場合 エンジニアが要件定義をやることで取り扱い高アップ! • より投資していただくための施策の開発が必要だったが、PdMは一人しかいなかった。 • PdMは役割と割り切り、エンジニアがドメイン知識をキャッチアップ

    して企画もする方向性に切り替 えた。 • エンジニアが周囲を巻き込みながら複雑な施策の要件定義・プロジェクトマネジメント全般を進行、 大玉の開発を並列で実行 できた。 • 企画リソースが増えた事で、1,2日でリリースできる改善施策から成果が出た。
  7. ④急成長期 x 失敗談 - LayerXの場合 法律周りのレビュープロセスが属人化していて品質が悪化 • 専門家のレビューが必要な複雑な処理において、レビュープロセスが属人化 していて品質問題に発 展。

    ◦ 配当における税金の扱い→税理士、法定書面の記載内容の正誤→弁護士 etc… • 専門性が高い部分において、開発しながら仕様を理解しようとしてしまった。 • 事前に「どのような開発物」ならばレビューを受ける必要があるのか明確 にしておくべきだった。 ◦ 例: 金商法、景表法など • ウォーターフォール的に仕様がカッチリ決まっているものは明確にしてから開発すべきだった。
  8. ④急成長期 x 失敗談 - Nealleの場合 繰り返すコトへの投資が遅かった • CI/CDをちゃんと作るのが遅く、手動対応や深夜メンテを長く続けて しまった。 •

    組織が拡大し、エンジニアに対する問い合わせ が爆増。 • 開発する時間が奪われる + 事業が伸びて組織が拡大 → 指数関数的に苦しく なっていく。 • エンジニアリングに費やせている時間を可視化 すべき。 • 時間を生み出す施策 に投資をすべき。