アウトカム最大化のためのプロダクト開発と組織

Transcript

1. アウトカム最大化のための プロダクト開発と組織 三島 和人 2022/11/2
2. Kazuto Mishima(@kaa_a_zu) 2015年からフリーランスエンジニアとして仕事を始める。 色々な縁があってサンフランシスコやバンコクでの開発も 経験。2021年にエンジニアとしてGaudiyに入社。Webや SDKなど様々なレイヤーの開発を行った後、2022年にPdM に転向。現在は開発組織の生産性向上とアウトカム最大化 に注力をしている
3. アジェンダ Gaudiyとは 01. アウトカム最大化のための大きな変更 02. 開発具体例 03. 今後のアップデート 04.
4. Gaudiyとは
5. 会社名 株式会社Gaudiy 本社 東京都渋谷区笹塚1-64-8Daiwa笹塚ビル6階 （笹塚駅から徒歩8分） 代表者 石川裕也 設立 2018年5月2日 資本金 37億円（準備金含む・2022年8月時点） 累計調達額 39億円（2022年8月時点） 社員数 45名（2022年8月時点・内定者含む） 主な事業内容 ブロックチェーン技術を活用したアプリケーション開発や 大学機関と連携した研究開発事業 GaudiyはWeb3とエンタメを掛け合わせ グローバルに挑戦する、 日本発のWeb3スタートアップです。 COMPANY 1
6. ファンの熱量を最大化する、Web3時代のファンプラットフォーム Gaudiy Fanlink
7. 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独自のトークングラフ形成と
 マーケティング活動が可能
8. 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
9. etc... エンタメ業界を代表する企業に提供（一部） PARTNER 4
10. 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
11. ブロックチェーンをはじめとした先進的なテクノロジーを駆使し、 誰もが創作や貢献のできる未来を、世界中のファンたちと、つくりあげる ファン国家を創る
12. 私たちがしないといけないことは、完璧なプロダクトを作ることではない VISIONを実現させるためにユーザーの行動を変化させることである アウトプット最小化 アウトカム最大化 7
13. アウトカム最大化のための 大きな変更
14. 組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure アウトカム最大化のための大きな変更 Major changes to maximize outcomes アウトカム最大化のためには開発組織を大きく変え、それに併せた開発プロセスを整える必要がある tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス
15. 組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure アウトカム最大化のための大きな変更 Major changes to maximize outcomes アウトカム最大化のためには開発組織を大きく変え、それに併せた開発プロセスを整える必要がある tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス 2. アウトカム最大化のための開発プロセス
16. 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人) 機能チーム 基盤チーム 現在
17. がむしゃらにプロダクトを作る開発組織 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
18. がむしゃらにプロダクトを作る開発組織 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
19. 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人) 機能チーム 基盤チーム
20. 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人 ) 機能チーム 基盤チーム
21. チームにタスク完結性がある状態へ ・チームが意思決定権を有している ・チームがアウトカムに責任を持てる タスク完結性がある ->チームがそのタスクにおいて、最初から最後まで担うことができる 15
22. 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人)
23. 組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure 開発組織の変遷 Transition of Organizational Structure 開発組織体制を大きく変える際の背景詳細や工夫に興味があったら以下のブログを見ていただきたいです
24. 組織体制移行時に意識した点 Points to be Conscious of when transitioning organizational structure アウトカム最大化のための大きな変更 Major changes to maximize outcomes アウトカム最大化のためには開発組織を大きく変え、それに併せた開発プロセスを整える必要がある tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 tv アウトカム最大化のための開発組織 2. アウトカム最大化のための開発プロセス (チームがアウトカムにより責任を持てる状態作り) 2. アウトカム最大化のための開発プロセス (チームがアウトカムにより責任を持てる状態作り) 2. アウトカム最大化のための開発プロセス (チームがアウトカムにより責任を持てる状態作り)
25. 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の頭の中にある作りたい機– ¯ 新規コミュニティ開設のために作りたい機– ¯ 既存コミュニティのために作りたい機能
26. 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 各方面からのオポチュニティアイテムを一元管理する
27. 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が優先順位を定めて各チームに割り振る(この時点での仕様詳細度はかなり低い状態)
28. 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つに分けて進捗を管理
29. 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 以下のそれぞれを達成するために最小アウトプットで不確実性を下げ、提供するアウトカムの確度を高め最大化する
30. 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)にスムーズに入れるような状態を作る
31. 24 In Delivery で きちんとしたプロダクトを作り、効果検証を行う I n D e l i v e r y SPF を達成させg p 機能を開発してユーザーに届け、プロダクトを用いて仮説検証を行う SPF を達成させg p 機能を開発してユーザーに届け、プロダクトを用いて仮説検証を行う Deliveryで立てた仮説に対しての検証を行い、チームで振り返る
32. 開発具体例
33. 25 オポチュニティを集める M a n a g i n g O p p o r t u n i t i e s
34. 26 オポチュニティを集める M a n a g i n g O p p o r t u n i t i e s 各方面からのオポチュニティアイテムが集まる 毎週の定例でそのアイテムについて共有をする
35. 27 アイテムを各チームに割り当てる A s s i g n i t e m s t o e a c h t e a m
36. 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）
37. 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 が並走します
38. 30 特定のNFT所有を持っているユーザーとして、限定チャットルームに参加できる I n D e l i v e r y NFT所有者限定チャットルームについてDiscoveryで立てていた仮説: 「今までチャットを使っていなかったユーザーにとって、同じステータスを持つユーザーのみがいる空間があれば、チャットを使うだろう」 リリースしたNFT所有者限定チャットルーム NFT所有者限定チャットルームに対しての仮説検証
39. 31 ユーザーとして、クイズを作成/回答できる I n D i s co v e r y クイズ作成者のValue Proposition Canvas クイズのユーザーストーリーマッピング クイズのExampleMapping
40. 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 に時間をかけ不確実性を出来るだけ落とすことが
 大事である。
41. 33 開発体制とプロセス変更の結果 R e s u l t s チームで意思決定ができるようになったため、開発スピードが上がった 仕様決め段階からEngineer含めチームメンバーを巻き込むことが出来ているので、その仕様になった背景が分かるようになった 仕様決め段階からEngineer含めチームメンバーを巻き込むことが出来ているので、手戻りが減った メンバー全員が「これでアウトカムが最大になるのか」に意識を持てる状態になった 目的意識を持った開発をするようになったのでDelivery中でも多くの意見が出るようになった 2つアイテムを並走することがあるので、スプリント内の時間の使い方が難しくなった 各チーム ごとの開発 領域境界を定 義できないため、 コン フリ クトが 生じる 可能性が 高まった
42. アウトプット最小化、アウトカム最大化 タスク完結性がある状態が必要 開発組織とプロセスをアップデート アウトカム最大化が出来ていない組織 7
43. 今後のアップデート
44. 34 2ヶ月前に語った今後のアップデート予想... U p d a t e s
45. 35 本日本格始動するアップデート U p d a t e s 今までにない組織体制へのアップデートについてGaudiyのブログがでます ※冗談でやっている訳ではないです
46. ありがとうございました