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

by Keita Tsukamoto

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

01 自己紹介 & プロダクト紹介   02 プロダクトエンジニア   03 プロダクトエンジニアの開発生産性   04 横断チーム   05 今までやってきた生産性向上施策   06 まとめ  目次 

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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児の父  最近タコスにハマっています！！  

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

01 プロダクト紹介   スタートアップ向け  経営者が事業に向き合う時間を生み出すための投資家にまつわる複雑な管理を全て集約するための SaaS  投資家向け  スタートアップへの投資や支援をもっとスマートに管理するための CRM    プロダクト自体が多機能なのが特徴です！ → 後ほど回収する伏線です！  6  会社経営支援・IRサービスを提供   投資先・投資案件管理サービスを提供   スタートアップ  投資家  IRデータ共有  コミュニケーション 

Slide 7

Slide 7 text

02 プロダクトエンジニア  

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

02 プロダクトエンジニアの役割   9  プロダクト部スタートアップ側プロダクトエンジニアイネーブルメントエンジニア投資家・アドバイザー側プロダクトエンジニアインフラ部 SRE/CorporateIT エンジニアプロダクトの新機能開発はプロダクトエンジニアが  PdM・デザイナーとコラボレーションしながらオーナーとなりプロジェクトをリード 

Slide 10

Slide 10 text

02 プロダクトエンジニアとは？   10  プロダクト部スタートアップ側プロダクトエンジニアイネーブルメントエンジニア投資家・アドバイザー側プロダクトエンジニアインフラ部 SRE/CorporateIT エンジニアプロダクトの新機能開発はプロダクトエンジニアが  PdM・デザイナーとコラボレーションしながらオーナーとなりプロジェクトをリード  → ねえ、プロダクトエンジニアってなぁになぁに？？  

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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  スマートラウンドのプロダクトエンジニアに求められること   エンジニアリングのプロフェッショナル  ユーザーの課題を解決できる技術力を有すること  プロダクトへの強いオーナーシップ  技術領域に限らず、プロダクトの提供する価値にコミットすること  事業貢献への取り組み  エンジニアリングを通して事業に貢献すること  “スマートラウンドの小山さんからはプロダクトの成功に貢献するあらゆることに取り組むエンジニアという話がありました。会社が事業を存続させるための手段としてプロダクトやエンジニアリングがあることから、技術領域に限らず、リリースされた機能や提供している価値に興味や関心を持ち、オーナーシップを持って事業貢献に取り組むことが重要です。” 

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

03 エンジニア組織に求められる責任   15  『プロダクト資産・負債』という "プロダクト B/S"に責任を持つ   自組織内の努力により、（資産・負債ひっくるめた）トータルのプロダクトB/Sの改善速度を向上させる義務がある    資産  ● ユーザ提供価値（＝リリースした資産の価値）   ● 開発速度（＝資産を作る速さ）   ● 安定性（バグ・障害の少なさ）（＝資産価値の減少の防止）   負債  ● 技術的負債（顕在）（＝ユーザ体験への負の影響（例：パフォーマンス劣化））   ● 技術的負債（潜在）（＝開発速度や安定性への負の影響要因）   ● 仕様負債（＝複雑な仕様、ユーザ貢献度の低い仕様の残存など）   出典： 2023/8 CTOオープン社内報vol.1 『CTOとCPOの役割分担』 https://note.com/smartround/n/n23bafd60cc93?magazine_key=md372615ad168    いかに資産を増やし、負債を減らすことができるかが重要  

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

03 扱うドメインが多い！！   スタートアップ向け  株主総会・資本政策・経営管理・ SO管理・優待特典 etc.  投資家向け  投資先管理・投資案件管理・ファンド管理・顧客支援・チャット・優待特典 etc.    プロダクト自体が多機能なのが特徴だけど多すぎぃ！   17  会社経営支援・IRサービスを提供   投資先・投資案件管理サービスを提供   スタートアップ  投資家  IRデータ共有  コミュニケーション 

Slide 18

Slide 18 text

03 扱うドメインが多いだけじゃない！！複雑ぅ！！（一例）   18  投資先管理  ● 投資元のVCと投資先の会社で通貨が異なる ● 投資先評価⼿法（マルチプル‧純資産‧etc.） ● キャピタルコール資本政策  ● 完全希薄化後株数持分⽐率 ● 新株予約権発⾏による資⾦調達 ● 株式転換株主総会  ● 定時株主総会‧臨時株主総会‧種類株主総会 ● 普通決議‧特別決議 ● 電磁的⽅法による招集通知の送付証券データ  ● 種類株 ● 残余財産優先分配権 ● 希薄化防⽌条項扱うドメインが多い&複雑だとどうなるか  → 頭が爆発する 🤯🤯🤯 

Slide 19

Slide 19 text

03 認知負荷理論における 3つの認知負荷   19  課題内在性負荷  取り扱う課題自体の難しさ  内容が複雑であればあるほど  負荷は高くなる  基本的には減らせない負荷      課題外在性負荷  取り扱う課題とは  直接関係のない負荷  減らした方がいい負荷      学習関連負荷  知識の構築に必要な認知負荷  長期記憶の中に取り込む重要負荷であり、最大化していきたい負荷     

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

04 横断チーム  

Slide 23

Slide 23 text

04 エンジニア組織の組織構造（再掲）   23  プロダクト部スタートアップ側プロダクトエンジニアイネーブルメントエンジニア投資家・アドバイザー側プロダクトエンジニアインフラ部 SRE/CorporateIT エンジニアプロダクト部にプロダクト開発を行うエンジニアが在籍  インフラ部にシステム運用管理とプロダクト開発をサポートするSREが在籍  ※インフラ部にご興味ある方は ”2023/9 CTOオープン社内報vol.2 『エンジニア組織のSRE/CorporateITグループとは』”  https://note.com/smartround/n/n6d596d26c81e?magazine_key=md372615ad168 をご覧ください！ 

Slide 24

Slide 24 text

04 横断チームの役割   24  プロダクト部スタートアップ側プロダクトエンジニアイネーブルメントエンジニア投資家・アドバイザー側プロダクトエンジニアインフラ部 SRE/CorporateIT エンジニアイネーブルメントエンジニア   他のチームに対して新しいケイパビリティの獲得を  支援するチーム  SRE  プロダクトエンジニアが機能を高速に開発・リリース  できるように支援するチーム 

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

06 まとめ 

Slide 31

Slide 31 text

06 まとめ  31  ● エンジニア組織は『プロダクト資産・負債』という"プロダクトB/S"に責任を持つ  ● スマートラウンドのプロダクトエンジニアは大変  ○ エンジニアリング以外にドメイン知識とプロダクトへのオーナーシップ  ○ 扱うドメインが多くて複雑  ● 横断チーム（イネーブルメント・SRE）はプロダクトエンジニアのサポート役  ○ 複雑なドメインに立ち向かうため、課題外在性負荷を下げ、学習負荷を上げる  ● 課題外在負荷を下げる施策  ○ インフラ周りやDevOpsの環境整備  ○ 開発方針やプロセスの統一  ○ デザインシステムの本格的導入  ● 学習負荷を上げる施策  ○ 勉強会・輪読会の奨励 

Slide 32

Slide 32 text

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