Slide 1

Slide 1 text

アウトカム最大化のための プロダクト開発と組織 三島 和人 2022/11/2

Slide 2

Slide 2 text

Kazuto Mishima(@kaa_a_zu) 2015年からフリーランスエンジニアとして仕事を始める。 色々な縁があってサンフランシスコやバンコクでの開発も 経験。2021年にエンジニアとしてGaudiyに入社。Webや SDKなど様々なレイヤーの開発を行った後、2022年にPdM に転向。現在は開発組織の生産性向上とアウトカム最大化 に注力をしている

Slide 3

Slide 3 text

アジェンダ Gaudiyとは 01. アウトカム最大化のための大きな変更 02. 開発具体例 03. 今後のアップデート 04.

Slide 4

Slide 4 text

Gaudiyとは

Slide 5

Slide 5 text

会社名 株式会社Gaudiy 本社 東京都渋谷区笹塚1-64-8Daiwa笹塚ビル6階 (笹塚駅から徒歩8分) 代表者 石川裕也 設立 2018年5月2日 資本金 37億円(準備金含む・2022年8月時点) 累計調達額 39億円(2022年8月時点) 社員数 45名(2022年8月時点・内定者含む) 主な事業内容 ブロックチェーン技術を活用したアプリケーション開発や 大学機関と連携した研究開発事業 GaudiyはWeb3とエンタメを掛け合わせ グローバルに挑戦する、 日本発のWeb3スタートアップです。 COMPANY 1

Slide 6

Slide 6 text

ファンの熱量を最大化する、Web3時代のファンプラットフォーム Gaudiy Fanlink

Slide 7

Slide 7 text

2 多種多様なドメインを扱うGaudiy Fanlink G a u d i y Fa n l i n k f o r a v a r i e t y o f d o m a i n s コミュニティを起点に、自律分散的なファンによる経済圏を実現し、ファンが自分のIPを常に感じて暮らせる社会を作ろうとしている SNS t 投稿・コメント・いいねなどの基本機r t チャットやDMなどのメッセージ機能 SNS t 投稿・コメント・いいねなどの基本機r t チャットやDMなどのメッセージ機能 SNS t 投稿・コメント・いいねなどの基本機r t チャットやDMなどのメッセージ機能 ID連携・決済 t 外部サービスとのID連携を低コストで実‰ t サービスを横断したファン体験の構築 ID連携・決済 t 外部サービスとのID連携を低コストで実‰ t サービスを横断したファン体験の構築 ID連携・決済 t 外部サービスとのID連携を低コストで実‰ t サービスを横断したファン体験の構築 現在準備中 t メタバーª t De-F¦ t グローバルローカライズ etc... 現在準備中 t メタバーª t De-F¦ t グローバルローカライズ etc... 現在準備中 t メタバーª t De-F¦ t グローバルローカライズ etc... NFT・ブロックチェーン t NFTの販売/配布/パブリックチェーンへの書き出à t 動画/音声/投票券など多様なユーティリティ付与 NFT・ブロックチェーン t NFTの販売/配布/パブリックチェーンへの書き出à t 動画/音声/投票券など多様なユーティリティ付与 NFT・ブロックチェーン t NFTの販売/配布/パブリックチェーンへの書き出à t 動画/音声/投票券など多様なユーティリティ付与 ファン投票/DAO t ファン活動で得たNFTを使った投票が可r t ファンを意思決定に巻き込むDAO構築を実現 ファン投票/DAO t ファン活動で得たNFTを使った投票が可r t ファンを意思決定に巻き込むDAO構築を実現 ファン投票/DAO t ファン活動で得たNFTを使った投票が可r t ファンを意思決定に巻き込むDAO構築を実現 トークングラフマーケティング t SNSやイベント、商品購入など 様々なファン活動にNFTを配布。 IP独自のトークングラフ形成と
 マーケティング活動が可能 トークングラフマーケティング t SNSやイベント、商品購入など 様々なファン活動にNFTを配布。 IP独自のトークングラフ形成と
 マーケティング活動が可能 トークングラフマーケティング t SNSやイベント、商品購入など 様々なファン活動にNFTを配布。 IP独自のトークングラフ形成と
 マーケティング活動が可能

Slide 8

Slide 8 text

Gaudiyは、Web3の「冬の時代」と呼ばれた2018年にマンションの一室で創業しました。 同年10月には、今のサービスの前身となるブロックチェーン技術を活用したコミュニティサービス “Gaudiy Community” を公開しました。 当時はブロックチェーンを信じる人が少ない中で、Gaudiyはその可能性を信じ、 地道にサービス開発や研究を続けてきました。 そして徐々に、Web3の世界観や可能性が世の中にも認知されはじめ、 多くの方々の支えもあり、今のGaudiyがあります。 2022年8月、シリーズBにて34億円の資金調達を実施しました。 世界に向けた挑戦を、これから加速していきます。 創業4年で累計約 の資金調達を実施、 日本のWeb3領域を牽引 40億 COMPANY HISTORY 2018.05 株式会社Gaudiyを創業 2018.10 コミュニティアプリβ版”Gaudiy Community”を公開 ブロックチェーン技術を活用したコミュニティをリリース 2018.10 シード調達 JAFCO、エンジェル投資家から1500万の資金調達 2019.04 数社のブロックチェーンゲームにコミュニティを提供 2020.03 NFTオークション理論「Gaudiy-Sakai方式」を発表 新しいNFTオークション理論を慶大・坂井教授と共同発表 漫画 × BCゲームコラボで世界初の実証実験を実施 2020.03 笹塚オフィスに移転 2020.10 シリーズA調達 STRIVEから約3億円の資金調達 2021.03 「Gaudiy Fanlink」サービス提供開始 Sony Musicや集英社、アニプレックスなどの国内大手エンタメ企業と 業務提携し、サービスを展開 2021.03 Microsoft for Startupsに採択 2021.10 Sonyと共同でNFTチケットの開発・実証実験 8万人規模の国内最大のアイドルフェス「TOKYO IDOL FESTIVAL 2021」で実証実験 2022.08 シリーズB調達 評価額約160億で34億円の資金調達を実施 投資家:JAFCO・STRIVE・バンダイナムコ・Sony Music・Sanrio・SBI・ 三菱UFJイノベーションパートナーズ・みずほキャピタル 3

Slide 9

Slide 9 text

etc... エンタメ業界を代表する企業に提供(一部) PARTNER 4

Slide 10

Slide 10 text

5 現在のGaudiy Fanlinkアーキテクチャ G a u d i y Fa n l i n k A r c h i t e c t u r e Frontend Next.js TypeScript Apollo Client BFF TypeScript Apollo Server Backend Kotlin Go Send Tx GraphQL REST・gRPC Sync On-Chain data Cloud Spanner Cloud Run Vercel Ethereum Polygon etc... NFT service BE services

Slide 11

Slide 11 text

ブロックチェーンをはじめとした先進的なテクノロジーを駆使し、 誰もが創作や貢献のできる未来を、世界中のファンたちと、つくりあげる ファン国家を創る

Slide 12

Slide 12 text

私たちがしないといけないことは、完璧なプロダクトを作ることではない VISIONを実現させるためにユーザーの行動を変化させることである アウトプット最小化 アウトカム最大化 7

Slide 13

Slide 13 text

アウトカム最大化のための 大きな変更

Slide 14

Slide 14 text

組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure アウトカム最大化のための大きな変更 Major changes to maximize outcomes アウトカム最大化のためには開発組織を大きく変え、それに併せた開発プロセスを整える必要がある tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス

Slide 15

Slide 15 text

組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure アウトカム最大化のための大きな変更 Major changes to maximize outcomes アウトカム最大化のためには開発組織を大きく変え、それに併せた開発プロセスを整える必要がある tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス

Slide 16

Slide 16 text

10 開発組織の変遷 C h a n g e s i n d e v e l o p m e n t o r g a n i z a t i o n st r u c t u r e 2022年11月までに2度、戦略的な変化を遂げている PO(1人) UI Designer UX Designer Engineer(3-5人) Engineer(3-5人) Project1 Project2 PO(1人) Engineer(3-5人)

 FrontendEngineer中心 UI Designer UX Designer PjM(1人) Engineer(3-5人) BackendEngineer中心 PjM(1人) 機能チーム 基盤チーム 現在

Slide 17

Slide 17 text

がむしゃらにプロダクトを作る開発組織 Output-oriented development organization ローンチ期 ~ 2021年前半 ・戦略的にSLG(Sales-Led Growth)での開発をする(クライアントニーズに合わせた開発) ・Engineerは必要最小のスコープであるProjectという単位に別れる ・POとDesignerが大まかな仕様を作り、PO中心に話しながら各Projectごとに開発をする
 (基本的に1Project、多い時に2Projectが動いていた) ・戦略的にSLG(Sales-Led Growth)での開発をする(クライアントニーズに合わせた開発) ・Engineerは必要最小のスコープであるProjectという単位に別れる ・POとDesignerが大まかな仕様を作り、PO中心に話しながら各Projectごとに開発をする
 (基本的に1Project、多い時に2Projectが動いていた) PO(1人) UI Designer UX Designer Engineer(3-5人) Engineer(3-5人) Project1 Project2

Slide 18

Slide 18 text

がむしゃらにプロダクトを作る開発組織 Output-oriented development organization ローンチ期 ~ 2021年前半 ・戦略的にSLG(Sales-Led Growth)での開発をする(クライアントニーズに合わせた開発) ・Engineerは必要最小のスコープであるProjectという単位に別れる ・POとDesignerが大まかな仕様を作り、PO中心に話しながら各Projectごとに開発をする
 (基本的に1Project、多い時に2Projectが動いていた) ・戦略的にSLG(Sales-Led Growth)での開発をする(クライアントニーズに合わせた開発) ・Engineerは必要最小のスコープであるProjectという単位に別れる ・POとDesignerが大まかな仕様を作り、PO中心に話しながら各Projectごとに開発をする
 (基本的に1Project、多い時に2Projectが動いていた) <課題> ¶ 「SaaSとしての急成長」に備えた地盤を整えることができていなかっ° ¶ 人数が増えてきて、POが全てを管理することはできなくなってきた <課題> ¶ 「SaaSとしての急成長」に備えた地盤を整えることができていなかっ° ¶ 人数が増えてきて、POが全てを管理することはできなくなってきた PO(1人) UI Designer UX Designer Engineer(3-5人) Engineer(3-5人) Project1 Project2

Slide 19

Slide 19 text

13 地盤を整えるための開発組織 D e v e l o p m e n t o r g a n i z a t i o n t o l a y t h e g r o u n d w o r k 2021年前半~2022年7月 ・EngineerはFrontendEngineerが中心の機能開発チームと、BackendEngineerが中心の
 基盤開発チームに分かれる ・各チームの開発スケジュールを管理するPjMという役割が生まれる ・POとDesignerが詳細の仕様を作り、各チームがそれらに沿った開発する ・EngineerはFrontendEngineerが中心の機能開発チームと、BackendEngineerが中心の
 基盤開発チームに分かれる ・各チームの開発スケジュールを管理するPjMという役割が生まれる ・POとDesignerが詳細の仕様を作り、各チームがそれらに沿った開発する PO(1人) Engineer(3-5人)

 FrontendEngineer中心 UI Designer UX Designer PjM(1人) Engineer(3-5人) BackendEngineer中心 PjM(1人) 機能チーム 基盤チーム

Slide 20

Slide 20 text

14 地盤を整えるための開発組織 D e v e l o p m e n t o r g a n i z a t i o n t o l a y t h e g r o u n d w o r k 2021年前半~2022年7月 ・EngineerはFrontendEngineerが中心の機能開発チームと、BackendEngineerが中心の
 基盤開発チームに分かれる ・各チームの開発スケジュールを管理するPjMという役割が生まれる ・POとDesignerが詳細の仕様を作り、各チームがそれらに沿った開発する ・EngineerはFrontendEngineerが中心の機能開発チームと、BackendEngineerが中心の
 基盤開発チームに分かれる ・各チームの開発スケジュールを管理するPjMという役割が生まれる ・POとDesignerが詳細の仕様を作り、各チームがそれらに沿った開発する <課題> „ 仕様 策定者のPOとDesignerの リソースが 足り ない、か つコミュ ニケー ションパスを 減ら す
 た めに 社内受託的な開発が 行われ てしまっ てい „ „ 何の 目的でこの機能を作るのかを 高解像度で全員が理 解してい ないた め意見が しづら œ „ この機能が 今後どう なるのかを 全員が理 解してい ないた め次の 改善で手戻りが発生す b „ 仕様 決定プロセスに エンジ ニア視点が 入ら ないた め技術的な手戻りが発生す b „ Saa Sと して大事な汎用性に つい て考え抜けておら ず、 特定の コミュ ニティ特化の機能 が
 出来てしまっ „ — チームがアウトカムに責任を持たなくて良い(持ちにくい)状態だったため
 最大のアウトカムを出すことが出来ていなかった <課題> „ 仕様 策定者のPOとDesignerの リソースが 足り ない、か つコミュ ニケー ションパスを 減ら す
 た めに 社内受託的な開発が 行われ てしまっ てい „ „ 何の 目的でこの機能を作るのかを 高解像度で全員が理 解してい ないた め意見が しづら œ „ この機能が 今後どう なるのかを 全員が理 解してい ないた め次の 改善で手戻りが発生す b „ 仕様 決定プロセスに エンジ ニア視点が 入ら ないた め技術的な手戻りが発生す b „ Saa Sと して大事な汎用性に つい て考え抜けておら ず、 特定の コミュ ニティ特化の機能 が
 出来てしまっ „ — チームがアウトカムに責任を持たなくて良い(持ちにくい)状態だったため
 最大のアウトカムを出すことが出来ていなかった PO(1人 ) Engineer (3-5人)

 FrontendEngineer中心 UI Designer UX Designer PjM(1人 ) Engineer (3-5人) BackendEngineer中心 PjM(1人 ) 機能チーム 基盤チーム

Slide 21

Slide 21 text

チームにタスク完結性がある状態へ ・チームが意思決定権を有している ・チームがアウトカムに責任を持てる タスク完結性がある ->チームがそのタスクにおいて、最初から最後まで担うことができる 15

Slide 22

Slide 22 text

16 アジリティ高く、タスク完結性を持って遂行可能な開発組織 O u t co m e - o r i e n t e d d e v e l o p m e n t o r g a n i z a t i o n 2022年7月~現在 ¤ 仕様策定/リリース/検証 の 責任を一貫して担える クロスファンクショナルなチームに移™ ¤ PdMという意思決定者をチーム内に作m ¤ UI/UX Designerはチームに所” ¤ EngineerはチームとしてFrontend~Backendの知識を持っているメンバーで構m ¤ 1プロダクト開発において、特定の開発領域境界は存在しないため、チーム名が寿司の名前になる ¤ 仕様策定/リリース/検証 の 責任を一貫して担える クロスファンクショナルなチームに移™ ¤ PdMという意思決定者をチーム内に作m ¤ UI/UX Designerはチームに所” ¤ EngineerはチームとしてFrontend~Backendの知識を持っているメンバーで構m ¤ 1プロダクト開発において、特定の開発領域境界は存在しないため、チーム名が寿司の名前になる PdM(1人) UX Designer UI Designer Engineer(3-6人) UI Designer UI Designer UX Designer UX Designer PdM(1人) PdM(1人) Engineer(3-6人) Engineer(3-6人) PO(1人)

Slide 23

Slide 23 text

組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure 開発組織の変遷 Transition of Organizational Structure 開発組織体制を大きく変える際の背景詳細や工夫に興味があったら以下のブログを見ていただきたいです

Slide 24

Slide 24 text

組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure アウトカム最大化のための大きな変更 Major changes to maximize outcomes アウトカム最大化のためには開発組織を大きく変え、それに併せた開発プロセスを整える必要がある tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 2. アウトカム最大化のための開発プロセス (チームがアウトカムにより責任を持てる状態作り) 2. アウトカム最大化のための開発プロセス (チームがアウトカムにより責任を持てる状態作り) 2. アウトカム最大化のための開発プロセス (チームがアウトカムにより責任を持てる状態作り)

Slide 25

Slide 25 text

19 POは作りたい体験の優先順位を決め、チームは最大のアウトカムを追う B e a t e a m t h a t i s a cco u n t a b l e f o r o u t co m e s PO(1人) Engineer(3-5人)

 FrontendEngineer中心 UI Designer UX Designer PjM(1人) Engineer(3-5人) BackendEngineer中心 PjM(1人) 機能チーム 基盤チーム 組織体制移行前の図を再掲 トップダウン的に各チームに以下のようなやることが伝わっている状態だっž ¯ POの頭の中にある作りたい機– ¯ 新規コミュニティ開設のために作りたい機– ¯ 既存コミュニティのために作りたい機能 トップダウン的に各チームに以下のようなやることが伝わっている状態だっž ¯ POの頭の中にある作りたい機– ¯ 新規コミュニティ開設のために作りたい機– ¯ 既存コミュニティのために作りたい機能

Slide 26

Slide 26 text

19 POは作りたい体験の優先順位を決め、チームは最大のアウトカムを追う B e a t e a m t h a t i s a cco u n t a b l e f o r o u t co m e s 各方面からのオポチュニティアイテムを一元管理する

Slide 27

Slide 27 text

20 POは作りたい体験の優先順位を決め、チームは最大のアウトカムを追う B e a t e a m t h a t i s a cco u n t a b l e f o r o u t co m e s POが優先順位を定めて各チームに割り振る(この時点での仕様詳細度はかなり低い状態)

Slide 28

Slide 28 text

21 POは作りたい体験の優先順位を決め、チームは最大のアウトカムを追う B e a t e a m t h a t i s a cco u n t a b l e f o r o u t co m e s 各チケットのステータスは大きく3つに分けて進捗を管理

Slide 29

Slide 29 text

22 デュアルトラックアジャイルの導入 D u a l -Tra c k A g i l e CPF(Customer/Problem Fit) -> ユーザーが本当にその課題を持っているのか PSF(Problem/Solution Fit) -> 課題を解決するための方法として妥当かどうか SPF(Solution/Product Fit) -> 課題を解決するための方法をプロダクトとして提供するのが妥当かどうか ② In Discovery 目的: 課題解決の不確実性を下げる ③ In Delivery 目的: 課題解決策の確度を高める Learn Build Measure Learn Build Measure Learn Build Measure Learn Build Measure 以下のそれぞれを達成するために最小アウトプットで不確実性を下げ、提供するアウトカムの確度を高め最大化する

Slide 30

Slide 30 text

23 In Discovery で 不確実性を下げ、仮説を明確にする I n D i s co v e r y f 私たちが本当に解決するのはどのような問題かy f 私たちの会社と製品を採用する顧客にとって価値のあるソリューションはどのようなものかy f 使えるソリューションはどのようなものかy f 使える時間とツールから考えて実現可能なものは何か? f 私たちが本当に解決するのはどのような問題かy f 私たちの会社と製品を採用する顧客にとって価値のあるソリューションはどのようなものかy f 使えるソリューションはどのようなものかy f 使える時間とツールから考えて実現可能なものは何か? チーム内のメンバーを In Discovery のフェーズから上手く巻き込むことを意識 して、本格的な開発(In Delivery)にスムーズに入れるような状態を作る

Slide 31

Slide 31 text

24 In Delivery で きちんとしたプロダクトを作り、効果検証を行う I n D e l i v e r y SPF を達成させg p 機能を開発してユーザーに届け、プロダクトを用いて仮説検証を行う SPF を達成させg p 機能を開発してユーザーに届け、プロダクトを用いて仮説検証を行う Deliveryで立てた仮説に対しての検証を行い、チームで振り返る

Slide 32

Slide 32 text

開発具体例

Slide 33

Slide 33 text

25 オポチュニティを集める M a n a g i n g O p p o r t u n i t i e s

Slide 34

Slide 34 text

26 オポチュニティを集める M a n a g i n g O p p o r t u n i t i e s 各方面からのオポチュニティアイテムが集まる 毎週の定例でそのアイテムについて共有をする

Slide 35

Slide 35 text

27 アイテムを各チームに割り当てる A s s i g n i t e m s t o e a c h t e a m

Slide 36

Slide 36 text

28 アイテムを各チームに割り当てる A s s i g n i t e m s t o e a c h t e a m 以下4つの要素からスコアを算出し、Discovery(不確実性解消)の優先順位を決定す— VU 影響力、インパクト(ImpactA 8U 信頼度(ConfidenceA 1U 容易性(EaseA @U 緊急(Emergency)

Slide 37

Slide 37 text

29 デュアルトラックアジャイルの実行 D u a l -t ra c k a g i l e e xe c u t i o n In Discovery ユーザーとして、クイズを作成/回答できる In Delivery 特定のNFT所有を持っているユーザーとして、限定チャットルームに参加できる チームが持っているアイテムは以下のようになっている場合、Discovery と Delivery が並走します

Slide 38

Slide 38 text

30 特定のNFT所有を持っているユーザーとして、限定チャットルームに参加できる I n D e l i v e r y NFT所有者限定チャットルームについてDiscoveryで立てていた仮説: 「今までチャットを使っていなかったユーザーにとって、同じステータスを持つユーザーのみがいる空間があれば、チャットを使うだろう」 リリースしたNFT所有者限定チャットルーム NFT所有者限定チャットルームに対しての仮説検証

Slide 39

Slide 39 text

31 ユーザーとして、クイズを作成/回答できる I n D i s co v e r y クイズ作成者のValue Proposition Canvas クイズのユーザーストーリーマッピング クイズのExampleMapping

Slide 40

Slide 40 text

32 補足: High Integrity な Commitment のために H i g h I n t e r i t y C o m m i t m e n t アジャイルチームの立場からすると「その機能はいつ出るの?」と問われるのは嫌なことである。
 何故なら、その機能にフィジビリティやユーザービリティがあるのか分からないことが多く、
 また、技術的にも実現可能なのかも考えきれていないことがあるからだ。しっかりとした
 コミットメントをするためにも Discovery に時間をかけ不確実性を出来るだけ落とすことが
 大事である。 アジャイルチームの立場からすると「その機能はいつ出るの?」と問われるのは嫌なことである。
 何故なら、その機能にフィジビリティやユーザービリティがあるのか分からないことが多く、
 また、技術的にも実現可能なのかも考えきれていないことがあるからだ。しっかりとした
 コミットメントをするためにも Discovery に時間をかけ不確実性を出来るだけ落とすことが
 大事である。

Slide 41

Slide 41 text

33 開発体制とプロセス変更の結果 R e s u l t s チームで意思決定ができるようになったため、開発スピードが上がった 仕様決め段階からEngineer含めチームメンバーを巻き込むことが出来ているので、その仕様になった背景が分かるようになった 仕様決め段階からEngineer含めチームメンバーを巻き込むことが出来ているので、手戻りが減った メンバー全員が「これでアウトカムが最大になるのか」に意識を持てる状態になった 目的意識を持った開発をするようになったのでDelivery中でも多くの意見が出るようになった 2つアイテムを並走することがあるので、スプリント内の時間の使い方が難しくなった 各チーム ごとの開発 領域境界を定 義できないため、 コン フリ クトが 生じる 可能性が 高まった

Slide 42

Slide 42 text

アウトプット最小化、アウトカム最大化 タスク完結性がある状態が必要 開発組織とプロセスをアップデート アウトカム最大化が出来ていない組織 7

Slide 43

Slide 43 text

今後のアップデート

Slide 44

Slide 44 text

34 2ヶ月前に語った今後のアップデート予想... U p d a t e s

Slide 45

Slide 45 text

35 本日本格始動するアップデート U p d a t e s 今までにない組織体制へのアップデートについてGaudiyのブログがでます ※冗談でやっている訳ではないです

Slide 46

Slide 46 text

ありがとうございました