プロダクトエンジニアを支えるための開発生産性向上施策

Transcript

1. 株式会社スマートラウンド
 プロダクトエンジニアを支えるための 
 開発生産性向上施策 
 塚本 啓太(@tsukakei1012)


2. 01 自己紹介 & プロダクト紹介 
 02 プロダクトエンジニア 
 03 プロダクトエンジニアの開発生産性

   
 04 横断チーム 
 05 今までやってきた生産性向上施策 
 06 まとめ
 目次


3. 01 自己紹介 & プロダクト紹介 


4. 01 自己紹介
 株式会社スマートラウンド
 プロダクト部チーフテックリード
 塚本 啓太（つかもと けいた）
 4
 経歴
 大学院修了

   → 起業 → スタートアップ1人目エンジニア → 現職
 今年1月から現職でテックリード
 テックリード歴は前職含めて 2年弱
 
 好きな技術領域
 Kotlin / TypeScript / Playwright
 CI/CD / DevOps / A11y
 Software Testing / QA
 各種SNS
 普段はチーバくんに擬態しています 
 X: https://twitter.com/tsukakei1012
 GitHub: https://github.com/tsukakei
 
 千葉県出身 1992年生まれ 1児の父
 最近タコスにハマっています！！ 


5. 01 事業紹介
 ミッション
 スタートアップが可能性を最大限に発揮できる世界をつくる 
 5
 あるべき姿
 現実
 事務作業時間（手続き、書類作成など） 


   事業にかける時間
 スタートアップ A
 投資家 X
 スタートアップ B
 投資家 Y
 投資家 Z
 バラバラな形式・誤ったデータ・何度も共有が必要 😱
 あるべき姿
 現実
 事務作業時間（手続き、書類作成など） 
 事業にかける時間
 スタートアップ A
 投資家 X
 スタートアップ B
 スタートアップ C
 投資家 Y
 投資家 Z
 統一された形式・正しいデータ・共有は一度だけ 😉
 一元管理
 smartroundが実現する世界
 統一化・標準化されたデータ管理によって、スタートアップと投資家双方の業務を効率化
 スタートアップ C


6. 01 プロダクト紹介 
 スタートアップ向け
 経営者が事業に向き合う時間を生み出すための投資家にまつわる複雑な管理を全て集約するための SaaS
 投資家向け
 スタートアップへの投資や支援をもっとスマートに管理するための CRM
 


   プロダクト自体が多機能なのが特徴です！ → 後ほど回収する伏線です！
 6
 会社経営支援・IRサービスを提供 
 投資先・投資案件管理サービスを提供 
 スタートアップ
 投資家
 IRデータ共有
 コミュニケーショ ン


7. 02 プロダクトエンジニア 


8. 02 エンジニア組織の組織構造 
 8
 プロダクト部 スタートアップ側 プロダクトエンジニア イネーブルメントエンジニア 投資家・アドバイザー側 プロダクトエンジニア

   インフラ部 SRE/CorporateIT エンジニア プロダクト部にプロダクト開発を行うエンジニアが在籍
 インフラ部にシステム運用管理とプロダクト開発をサポートするSREが在籍
 ※インフラ部にご興味ある方は ”2023/9 CTOオープン社内報vol.2 『エンジニア組織のSRE/CorporateITグループとは』”
 https://note.com/smartround/n/n6d596d26c81e?magazine_key=md372615ad168 をご覧ください！


9. 02 プロダクトエンジニアの役割 
 9
 プロダクト部 スタートアップ側 プロダクトエンジニア イネーブルメントエンジニア 投資家・アドバイザー側 プロダクトエンジニア

   インフラ部 SRE/CorporateIT エンジニア プロダクトの新機能開発はプロダクトエンジニアが
 PdM・デザイナーとコラボレーションしながらオーナーとなりプロジェクトをリード


10. 02 プロダクトエンジニアとは？ 
 10
 プロダクト部 スタートアップ側 プロダクトエンジニア イネーブルメントエンジニア 投資家・アドバイザー側 プロダクトエンジニア

    インフラ部 SRE/CorporateIT エンジニア プロダクトの新機能開発はプロダクトエンジニアが
 PdM・デザイナーとコラボレーションしながらオーナーとなりプロジェクトをリード
 → ねえ、プロダクトエンジニアってなぁになぁに？？ 


11. 02 一般的なプロダクトエンジニアの定義 
 11
 出典： プロダクトエンジニアとは何者か https://note.com/niwa_takeru/n/n0ae4acf2964d
 プロダクトエンジニアが持つ 3領域
 テクノロジー


    １機能を単独で実装できる技術力
 UXデザイン
 UI + 良い体験へのコミットメント
 ドメイン
 解像度の高い顧客理解とそれを源泉とする優れた体験の創出
 プロダクトエンジニアが持つ 5つの特性
 顧客ドメインやビジネスに対する高い好奇心
 努力する人は夢中な人に勝てない
 専門領域の越境とキャッチアップの素早さ
 　　実践的で目的意識のある技術学習
 探索的かつ迅速な仮説検証サイクル
 全てを仮説と捉え検証に基づく学び
 アンラーンを受け入れる素直なコミュニケーション
 課題解決を中心とした素直さ
 課題解決に対する強いオーナーシップ
 顧客課題の解決を自分事とする


12. 02 スマートラウンドなりのプロダクトエンジニア 
 12
 出典
 プロダクトエンジニアの役割とは？／ Product Engineer Career Talk

    イベントレポート 
 https://blog.lab.kepple.co.jp/entry/2024/07/16/080000
 2024/05 CTOオープン社内報vol.10 『smartroundにおいて技術が果たす役割』 
 https://note.com/smartround/n/n0f338c6a3234?magazine_key=md372615ad168
 スマートラウンドのプロダクトエンジニアに求められること 
 エンジニアリングのプロフェッショナル
 ユーザーの課題を解決できる技術力を有すること
 プロダクトへの強いオーナーシップ
 技術領域に限らず、プロダクトの提供する価値にコミットすること
 事業貢献への取り組み
 エンジニアリングを通して事業に貢献すること
 “スマートラウンドの小山さんからはプロダクトの成功に貢献するあらゆることに取り組むエンジニアと いう話がありました。会社が事業を存続させるための手段としてプロダクトやエンジニアリングがあるこ とから、技術領域に限らず、リリースされた機能や提供している価値に興味や関心を持ち、オーナー シップを持って事業貢献に取り組むことが重要です。”


13. 02 スマートラウンドで特に重要視されていること 
 13
 プロダクトエンジニアが持つ 3領域
 テクノロジー
 １機能を単独で実装できる技術力
 UXデザイン
 UI

    + 良い体験へのコミットメント
 ドメイン
 解像度の高い顧客理解とそれを源泉として優れた体験の創出
 プロダクトエンジニアが持つ 5つの特性
 顧客ドメインやビジネスに対する高い好奇心
 努力する人は夢中な人に勝てない
 専門領域の越境とキャッチアップの素早さ
 　　実践的で目的意識のある技術学習
 探索的かつ迅速な仮説検証サイクル
 全てを仮説と捉え検証に基づく学び
 アンラーンを受け入れる素直なコミュニケーション
 課題解決を中心とした素直さ
 課題解決に対する強いオーナーシップ
 顧客課題の解決を自分事とする


14. 03 プロダクトエンジニアの開発生産性 


15. 03 エンジニア組織に求められる責任 
 15
 『プロダクト資産・負債』という "プロダクト B/S"に責任を持つ 
 自組織内の努力により、（資産・負債ひっくるめた）トータルのプロダクトB/Sの改善速度を向上させる 義務がある


    
 資産
 • ユーザ提供価値（＝リリースした資産の価値） 
 • 開発速度（＝資産を作る速さ） 
 • 安定性（バグ・障害の少なさ）（＝資産価値の減少の防止） 
 負債
 • 技術的負債（顕在）（＝ユーザ体験への負の影響（例：パフォーマンス劣化）） 
 • 技術的負債（潜在）（＝開発速度や安定性への負の影響要因） 
 • 仕様負債（＝複雑な仕様、ユーザ貢献度の低い仕様の残存など） 
 出典： 2023/8 CTOオープン社内報vol.1 『CTOとCPOの役割分担』 https://note.com/smartround/n/n23bafd60cc93?magazine_key=md372615ad168
 
 いかに資産を増やし、負債を減らすことができるかが重要 


16. 03 スマートラウンドで特に重要視されていること（再掲） 
 16
 プロダクトエンジニアが持つ 3領域
 テクノロジー
 １機能を単独で実装できる技術力
 UXデザイン
 UI

    + 良い体験へのコミットメント
 ドメイン
 解像度の高い顧客理解とそれを源泉として優れた体験の創出
 プロダクトエンジニアが持つ 5つの特性
 顧客ドメインやビジネスに対する高い好奇心
 努力する人は夢中な人に勝てない
 専門領域の越境とキャッチアップの素早さ
 　　実践的で目的意識のある技術学習
 探索的かつ迅速な仮説検証サイクル
 全てを仮説と捉え検証に基づく学び
 アンラーンを受け入れる素直なコミュニケーション
 課題解決を中心とした素直さ
 課題解決に対する強いオーナーシップ
 顧客課題の解決を自分事とする


17. 03 扱うドメインが多い！！ 
 スタートアップ向け
 株主総会・資本政策・経営管理・ SO管理・優待特典 etc.
 投資家向け
 投資先管理・投資案件管理・ファンド管理・顧客支援・チャット・優待特典 etc.


    
 プロダクト自体が多機能なのが特徴だけど多すぎぃ！ 
 17
 会社経営支援・IRサービスを提供 
 投資先・投資案件管理サービスを提供 
 スタートアップ
 投資家
 IRデータ共有
 コミュニケーショ ン


18. 03 扱うドメインが多いだけじゃない！！複雑ぅ！！（一例） 
 18
 投資先管理
 • 投資元のVCと投資先の会社で通貨が異なる • 投資先評価⼿法（マルチプル‧純資産‧etc.） •

    キャピタルコール 資本政策
 • 完全希薄化後株数持分⽐率 • 新株予約権発⾏による資⾦調達 • 株式転換 株主総会
 • 定時株主総会‧臨時株主総会‧種類株主総会 • 普通決議‧特別決議 • 電磁的⽅法による招集通知の送付 証券データ
 • 種類株 • 残余財産優先分配権 • 希薄化防⽌条項 扱うドメインが多い&複雑だとどうなるか
 → 頭が爆発する 🤯🤯🤯


19. 03 認知負荷理論における 3つの認知負荷 
 19
 課題内在性負荷
 取り扱う課題自体の難しさ
 内容が複雑であればあるほど
 負荷は高くなる
 基本的には減らせない負荷


    
 
 課題外在性負荷
 取り扱う課題とは
 直接関係のない負荷
 減らした方がいい負荷
 
 
 学習関連負荷
 知識の構築に必要な認知負荷
 長期記憶の中に取り込む重要負荷 であり、最大化していきたい負荷
 
 


20. 03 スマートラウンドにおける 3つの認知負荷 
 20
 課題内在性負荷
 ≒
 複雑なドメイン
 取り扱う課題自体の難しさ
 内容が複雑であればあるほど


    負荷は高くなる
 基本的には減らせない負荷
 
 
 例: 
 株主総会の手続き
 希薄化防止条項の発動タイミング
 J-KISS転換など
 
 課題外在性負荷
 =
 減らしたい負荷
 取り扱う課題とは
 直接関係のない負荷
 減らした方がいい負荷
 
 
 
 例: 
 ツールの使い方
 開発プロセスのご作法
 人間関係など
 学習関連負荷
 =
 増やしたい負荷
 知識の構築に必要な認知負荷
 長期記憶の中に取り込む重要負荷 であり、最大化していきたい負荷
 
 
 
 例: 
 ユーザーヒヤリング
 ドメイン知識の習得
 既存ソースコードの理解など


21. 03 課題外在性負荷を増やし学習関連負荷を減らす 
 21
 課題内在性負荷
 ≒
 複雑なドメイン
 取り扱う課題自体の難しさ
 内容が複雑であればあるほど
 負荷は高くなる


    基本的には減らせない負荷
 
 
 例: 
 株主総会の手続き
 希薄化防止条項の発動タイミング
 J-KISS転換など
 
 課題外在性負荷
 =
 減らしたい負荷
 取り扱う課題とは
 直接関係のない負荷
 減らした方がいい負荷
 
 
 
 例: 
 ツールの使い方
 開発プロセスのご作法
 人間関係など
 学習関連負荷
 =
 増やしたい負荷
 知識の構築に必要な認知負荷
 長期記憶の中に取り込む重要負荷 であり、最大化していきたい負荷
 
 
 
 例: 
 ユーザーヒヤリング
 ドメイン知識の習得
 既存ソースコードの理解など
 いかに増やしたい負荷を増やし、減らしたい負荷を減らすことができるかが重要 


22. 04 横断チーム 


23. 04 エンジニア組織の組織構造（再掲） 
 23
 プロダクト部 スタートアップ側 プロダクトエンジニア イネーブルメントエンジニア 投資家・アドバイザー側 プロダクトエンジニア

    インフラ部 SRE/CorporateIT エンジニア プロダクト部にプロダクト開発を行うエンジニアが在籍
 インフラ部にシステム運用管理とプロダクト開発をサポートするSREが在籍
 ※インフラ部にご興味ある方は ”2023/9 CTOオープン社内報vol.2 『エンジニア組織のSRE/CorporateITグループとは』”
 https://note.com/smartround/n/n6d596d26c81e?magazine_key=md372615ad168 をご覧ください！


24. 04 横断チームの役割 
 24
 プロダクト部 スタートアップ側 プロダクトエンジニア イネーブルメントエンジニア 投資家・アドバイザー側 プロダクトエンジニア

    インフラ部 SRE/CorporateIT エンジニア イネーブルメントエンジニア 
 他のチームに対して新しいケイパビリティの獲得を
 支援するチーム
 SRE
 プロダクトエンジニアが機能を高速に開発・リリース
 できるように支援するチーム


25. 04 横断チームによるプロダクトエンジニアのサポート 
 25
 プロダクト部 スタートアップ側 プロダクトエンジニア イネーブルメントエンジニア 投資家・アドバイザー側 プロダクトエンジニア

    インフラ部 SRE/CorporateIT エンジニア SRE
 インフラ周りやDevOpsに関する課題外在性負荷の解消
 
 • CI/CDの整備
 • アプリ監視環境の構築
 • インフラリソースの管理など
 イネーブルメントエンジニア 
 開発全般に関する課題外在性負荷の解消
 & 学習関連負荷の向上
 • 開発方針やプロセスの統一
 • デザインシステムの導入
 • 勉強会・輪読会の奨励など


26. 05 今までやってきた生産性向上施策 


27. 05 開発方針やプロセスの統一 
 27
 ポストモーテムテンプレートの整備
 やったこと 
 ポストモーテムテンプレートを整備し、どう いうときにポストモーテムを行った方がい いか基準を示した

    
 
 今までの問題点 
 ポストモーテムをやる基準や内容が人に よって異なり、バラバラだった 
 
 
 改善されたこと 
 どういうときにポストモーテムをやるべき で、その内容も様式化されたことで開発 チーム全体への知見化が進んだ 
 機能モジュールのアーキテクチャ
 やったこと 
 既存機能モジュールのアーキテクチャを 整理し、方針を統一した 
 
 
 今までの問題点 
 統一感はあったものの、不文律状態と なっており、こういう時はどうしたらいいん だろうという悩みがあった 
 
 改善されたこと 
 統一方針があるため、それをベースに行 動・議論することができるようになり悩む 時間が減った
 ログレベルの導入
 やったこと 
 アプリケーションで使われるログレベルの 基準を整理し、明記した 
 
 
 今までの問題点 
 ログレベルの認識が人によってバラバラ なため、ログアラートが大量発生したりし ていた
 
 改善されたこと 
 開発チーム全体でログレベルの共通認 識が取れ、不要なアラート頻発が減った 


28. 05 デザインシステムの本格的導入 
 28
 レイアウトコンポーネントの導入
 やったこと 
 EVERY LAYOUTにあるようなレイアウトを 行うためのコンポーネントを実装

    
 
 今までの問題点 
 マージンがいろんなコンポーネントに散逸 したり、flexboxを習得しないといけな かった
 
 改善されたこと 
 Storybookを元にほとんど学習コストなし でUIをマークアップできるようになった 
 Figmaにあるデザインを
 実装に落とし込む
 やったこと 
 Figmaにあるデザインを実装で使えるコ ンポーネントとして実装 
 
 今までの問題点 
 デザインと実際のプロダクトで見た目の 乖離や開発者がデザインに合わせるた めに工数を使っていた 
 
 改善されたこと 
 デザインとプロダクトの乖離が減り、開発 者のUIにかける工数も削減できた 
 
 基本コンポーネントの整備 
 やったこと 
 TextやBoxといった基本コンポーネントを 実装
 
 今までの問題点 
 よく使われるコンポーネントだが同じよう なCSSを何度も書かないといけなかった 
 
 改善されたこと 
 Storybookを元にほとんど学習コストなし でUIをマークアップできるようになった 


29. 05 勉強会・輪読会の奨励 
 29
 詳解 Kotlin Coroutines [2021]を一緒に完全理解
 発案のきっかけ 


    実際の業務でCoroutinesを使うことがあり、実装についてき ちんと理解したい
 
 やってみて 
 なんとなくで書いていたCoroutinesについて、ある程度自信 を持って書けるようになった
 「なっとく！関数型プログラミング」読書会 
 発案のきっかけ 
 関数型プログラミングの基本的な知識を学び、理解を深めた い
 
 やってみて 
 関数型プログラミングについて基本的な理解ができた
 
 クリーンアーキテクチャ勉強会 
 発案のきっかけ 
 難解なクリーンアーキテクチャ本を読破して
 クリーンアーキテクチャに関する理解を深めたい
 
 やってみて 
 クリーンアーキテクチャに関する理解が深まり、
 アーキテクチャに関する話題に入れるようになった
 データ指向アプリケーションデザイン 
 発案のきっかけ 
 アプリケーション外のミドルウェアについて興味があり、良書と いうことで読んでみたい
 
 やってみて 
 RDBMS自体の構造やクラウドで動いている分散システムの仕 組みについて学べてよかった


30. 06 まとめ


31. 06 まとめ
 31
 • エンジニア組織は『プロダクト資産・負債』という"プロダクトB/S"に責任を持つ
 • スマートラウンドのプロダクトエンジニアは大変
 ◦ エンジニアリング以外にドメイン知識とプロダクトへのオーナーシップ
 ◦

    扱うドメインが多くて複雑
 • 横断チーム（イネーブルメント・SRE）はプロダクトエンジニアのサポート役
 ◦ 複雑なドメインに立ち向かうため、課題外在性負荷を下げ、学習負荷を上げる
 • 課題外在負荷を下げる施策
 ◦ インフラ周りやDevOpsの環境整備
 ◦ 開発方針やプロセスの統一
 ◦ デザインシステムの本格的導入
 • 学習負荷を上げる施策
 ◦ 勉強会・輪読会の奨励


32. https://jobs.smartround.com/
 
 一緒に働くエンジニアを大募集中です！！