課題解決ではなく、価値創造を求めるVoicyの開発チームの組織設計と立ち上げの勘所

Transcript

1. 課題解決ではなく、 価値創造を求めるVoicyの開発チームの 組織設計と立ち上げの勘所 2023/07/27 株式会社Voicy 灘脇裕一 (@natacoon) Developers Summit 2023 Summer
2. 自己紹介 灘脇 裕一 Backend Engineer 機能開発チームリーダー スクラムマスター 2012.04 - HRTech 2020.07 - Voicy 本日はよろしくお願いします！ @natacoon 好きなモノ: 服とねことスプラ トゥーン 株式会社Voicy
3. アジェンダ • 自己紹介 • Voicyの事業紹介 • 組織の変遷 • プロジェクト開発か、プロダクト開発か • 組織変遷とアーキテクチャの意図 ◦ 3年前 ◦ 前年度 ◦ 今年度 • 私たちが選択した今後のアーキテクチャ方針 • まとめ • おまけ
4. Voicyのサービス
8. ここ数年のエンジニア組織の変遷
9. 3年前のプロダクト開発組織 Backend Frontend iOS App Android App PdM Designer Project Project 縦割り組織から、プロジェクトごとにメンバーをアサインして進めるプロジェクトサイロ化した形 態
10. 前年度のプロダクト開発組織 Cross Functional Team Feature Team A Feature Team B QA Team Data Team SRE/PF Team Task Force Team Feature Team ユーザに向き合い、特定ミッションにつ いて開発をしていくチーム Crossing Team Feature Teamが高速で開発を回すため専 門性の高いタスクをするチーム Task Force Team Feature Teamのミッション達成を妨げる 特定のミッションを掲げて解決するチーム
11. 今年度のプロダクト開発組織 P Mission
 TL/BE
 iOS/SM
 Android
 UX/UI
 PM/PO
 PM
 L Mission
 BE
 iOS/SM
 Android
 UX/UI
 PM
 Refactoring1
 Android/SM 
 EM1
 SRE
 iOS(委)
 BE
 BE
 Refactoring2
 BE
 EM2
 BE/SM
 Yugun
 FS
 FS
 WebFE
 WebFE
 PM
 UX/UI
 Data
 DE
 DA
 DA
 SRE
 SRE
 SRE
 SRE(委)
 QA
 QA
 App Enabling
 iOS/SM
 Android
 iOS/SM
 iOS(委)
 Android
 Android
 BE Enabling
 SRE
 BE
 TL/BE
 BE
 BE
 BE
 Web Enabling
 FS
 WebFE
 FS
 WebFE
 EM2
 EM2
 EM2
 EM1
 EM1
 EM1
 EM1
 EM1
 Stream aligned Platform Enabling Platform Enabling Enabling
12. Voicyのサービスの登場人物
13. Voicyのサービスの登場人物 アクター 音声コンテンツを聴く人 音声コンテンツを配信 する人 Voicy管理者 （toB向け機能など）
14. Voicyのサービスの登場人物 再生App 再生サー ビス 収録App 収録サー ビス 課金 サービス 収録Web 再生Web 管理Web 管理サー ビス スマート スピー カー 音声コン テンツ 音声処理 サービス
15. 3年前のプロダクト開発組織
16. 3年前のプロダクト開発組織 Backend Frontend iOS App Android App PdM Designer Project Project 縦割り組織から、プロジェクトごとにメンバーをアサインして進めるプロジェクトサイロ化した形態
17. 3年前のプロダクト開発組織 Backend Frontend iOS App Android App PdM Designer Project Project 縦割り組織から、プロジェクトごとにメンバーをアサインして進めるプロジェクトサイロ化 した形態 Eng B Eng A PM
18. なぜ縦割りでプロジェクトごとの形態だったか 性質上、投資すべき事業モデルが見えづらい側面 わかりやすい一般的なアプローチ 「世の中にはこんな課題がある！こういう事業モデルでいこう！」 →投資→利益
19. なぜ縦割りでプロジェクトごとの形態だったか Voicyの事業性質上、なかなかこの対象を定義できていなかった 組織だけでなく、アーキテクチャもどのような想定をすべきかが判断できていなかった
20. プロジェクトか、プロダクトか
21. 向き合う対象がプロジェクトか、プロダクトか プロジェクト はじめとおわりが明確に存在し、それが効果を上げて終了することが目的 つまり、納期を超過してしまうことと、完成の目処が立たなくなることが最 大のリスクになる。 →スケジュール不安を減少させられるようにものごとを進める傾向が強くな る
22. 向き合う対象がプロジェクトか、プロダクトか プロダクト 製品・サービスが継続的に収益を上げ続け、終了しないことが目的 顧客やマーケットに受け入れられず、採算が取れずにサービスを提供できな くなることが最大のリスク →マーケット不安を減少させられるようにものごとを進める傾向が強くなる
23. 向き合う対象がプロジェクトか、プロダクトか プロジェクト プロダクト 目的 終了すること 作ること 終了しないこと 使ってもらうこと 抱えている不安 スケジュール不安 マーケット不安 対処したい不確実性 方法における不確実性 目的における不確実性
24. 向き合う対象がプロジェクトか、プロダクトか プロジェクトは終了する できあがったモノをグロースするのはだれ？ 作ったものに向き合う人たちがいなくなる or 交代する 施策を考える人→依頼→プロジェクト ↺↺↺ この流れが本当に正しいのか？
25. 向き合う対象がプロジェクトか、プロダクトか プロダクト 終了させないこと →プロダクトの価値を継続的に向上させる ここに向き合うチームが必要になる
26. （余談）3年前のプロダクト開発組織 Project ① Project ② プロジェクト型で組織を設計しているとよくあること・・・ Eng B Eng A
27. （余談）3年前のプロダクト開発組織 Project ① Project ② Eng B Eng A コードレビュー
28. （余談）3年前のプロダクト開発組織 Project ① Project ② Project②のことよくわかんないんだけど・・・ まぁ変じゃないっぽいし、いっかー Eng B Eng A Eng A コードレビュー
29. （余談）3年前のプロダクト開発組織 Project ① Project ② Project②のことよくわかんないんだけど・・・ まぁ変じゃないっぽいし、いっかー LGTM!!! Eng B Eng A Eng A コードレビュー
30. 向き合う対象がプロジェクトか、プロダクトか ここ数年で、ソフトウェア開発の前提が変化した プロジェクト型開発 → プロダクト型開発
31. 改めて「不確実性」とは
32. 改めて「不確実性」とは 不確実性を減らして、開発を行っていこう！ そんな振り返りが出たことはないだろうか？
33. 改めて「不確実性」とは この「不確実性」ってなんだろうか 不確実性って言うと、いまだにちょっと難しく聞こえる
34. 改めて「不確実性」とは 「不確実性」＝「わからないこと」
35. 未来に関すること 方法の不確実性 目的の不確実性 「わからないこと」
36. 他人に関すること（通信不確実性） コミュニケーション 情報の非対称性、限定合理性 「わからないこと」
37. 「わからないこと」 これらは「不安」を作り出すサイクルを助長する 不安はコミュニケーションで埋めようとする引力が働くので、 未来に対しても、他人に対しても不確実性が増大する
38. 「わからないこと」 未来への不確実性 特に、目的の不確実性が多方面に表出化してきたことにより、 Whatをなるべく踏み間違えず、最短で価値を検証する流れが主流になった
39. 「わからないこと」 最短で価値を検証するには かなりの小規模なプロダクトと組織でない限りは単純なコミュニケーションだけではうま くいかない
40. そもそもなぜ組織に構造が作られるのか
41. そもそもなぜ組織に構造が作られるのか 少人数で相互に深いコミュニケーションをとっていけば、問題を解決することはできる が、コミュニケーションに費やす時間が増えすぎると何もできなくなってし まう
42. そもそもなぜ組織に構造が作られるのか 誰と誰がコミュニケーションし、誰と誰はあまりコミュニケーションしないのかという形が必 要になる →組織化と構造化
43. そもそもなぜ組織に構造が作られるのか このときの問題点 コミュニケーションが多いと想定していたのに本来必要がなかっ た または コミュニケーションが少ない想定の関係性に誤りがあった
44. そもそもなぜ組織に構造が作られるのか コミュニケーションが多いと想定していたのに本来必要がなかっ た コミュニケーション量は勝手に必要量に近づくが、 同じチームに属している場合、双方に余分な時間が生まれる
45. そもそもなぜ組織に構造が作られるのか コミュニケーションが少ない想定だったが、実は多かった 普段の活動とは別の軸での会議などが頻繁に必要になる
46. そもそもなぜ組織に構造が作られるのか コンウェイの法則の話 組織構造とそれが作り出すソフトウェア設計との間の関連性を示す原則 組織が設計するシステムは、組織のコミュニケーション構造を必然的に反映する
47. そもそもなぜ組織に構造が作られるのか 逆コンウェイ戦略 コンウェイの法則で生まれる制約を逆手に取ろうという戦略 組織の構造を意図的に変更することで、その結果として生まれるシステムの アーキテクチャを制御するというもの ※作りたいアーキテクチャ、モジュールを一緒に定義すべき（でないと余分なコミュニ ケーションが多々必要になる）
48. 閑話休題
49. Voicyで実現したかったこと 組織の形態を通じて、価値に向き合うことのできる形を作りたかった
50. 3年前のプロダクト開発組織 Backend Frontend iOS App Android App PdM Designer Project Project
51. どうして縦割り組織のプロジェクト型開発だったか？ チームでなにかに向き合うというより、機能特化な体制と意識だった （ので、この当時は開発もウォーターフォールで行っていた）
52. どうして縦割り組織のプロジェクト型開発だったか？ なにが正解になりえそうか判断ができなかった プロダクト組織全体としてユーザ体験に向き合えていなかった ので、メンバー各々がこれらを考えられるようにしたかった →事業がもたらす価値に対してチームが駆動できるように
53. 我々のサービスにとっての価値とは？？？
54. 我々のサービスにとっての価値とは？？？ サービスを利用するメインのアクターである、 以下の登場人物にフォーカスすることからはじめることにした • リスナー さん • パーソナリティ さん
55. 我々のサービスにとっての価値とは？？？ プロダクト = 終了させずに価値を届け続ける
56. 我々のサービスにとっての価値とは？？？ サービスを利用するメインのアクターである、 以下の登場人物にフォーカスすることからはじめることにした • リスナーに価値を生み出すプロダクト開発 • パーソナリティに価値を生み出すプロダクト開発
57. 前年度のプロダクト開発組織
58. 前年度のプロダクト開発組織 Cross Functional Team Feature Team A Feature Team B QA Team Data Team SRE/PF Team Task Force Team Feature Team ユーザに向き合い、特定ミッションにつ いて開発をしていくチーム Crossing Team Feature Teamが高速で開発を回すため専 門性の高いタスクをするチーム Task Force Team Feature Teamのミッション達成を妨げる 特定のミッションを掲げて解決するチーム
59. アーキテクチャ視点でも、サービスの単位に近い形に 再生App 再生サー ビス 収録App 収録サー ビス 課金 サービス 収録Web 再生Web 管理Web 管理サー ビス スマート スピー カー 音声コン テンツ 音声処理 サービス
60. 前年度のプロダクト開発組織 この組織形態である程度は各チームが駆動できるようになった
61. 前年度のプロダクト開発組織 技術的負債などの影響により、アウトプットに問題が出てきた
62. 前年度のプロダクト開発組織 一部のサービスのリプレイスを視野に入れていきたい
63. 今年度のプロダクト開発組織
64. 今年度のプロダクト開発組織 P Mission
 TL/BE
 iOS/SM
 Android
 UX/UI
 PM/PO
 PM
 L Mission
 BE
 iOS/SM
 Android
 UX/UI
 PM
 Refactoring1
 Android/SM 
 EM1
 SRE
 iOS(委)
 BE
 BE
 Refactoring2
 BE
 EM2
 BE/SM
 Yugun
 FS
 FS
 WebFE
 WebFE
 PM
 UX/UI
 Data
 DE
 DA
 DA
 SRE
 SRE
 SRE
 SRE(委)
 QA
 QA
 App Enabling
 iOS/SM
 Android
 iOS/SM
 iOS(委)
 Android
 Android
 BE Enabling
 SRE
 BE
 TL/BE
 BE
 BE
 BE
 Web Enabling
 FS
 WebFE
 FS
 WebFE
 EM2
 EM2
 EM2
 EM1
 EM1
 EM1
 EM1
 EM1
 Stream aligned Platform Enabling Platform Enabling Enabling
65. Team Topologiesの登場 「マシュー・スケルトン, マニュエル・パイス『チームトポロジー 価値ある ソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメン トセンター）」
66. Team Topologiesの登場 組織は、機械的で線形なシステムではな く、複雑で適応性を持つ有機体として見る べきである 「マシュー・スケルトン, マニュエル・パイス『チームトポロジー 価値あるソフトウェアをす ばやく届ける適応型組織設計』（日本能率協会マネジメントセンター）」
67. 組織図の問題 ソフトウェアアーキテクチャのドキュメントが 実際のソフトウェア開発が始まるとすぐに陳腐化するのと同様に、 組織図も常に現実と一致していない
68. チームトポロジーで定義しているチームタイプをおさらい • Stream aligned team • Enabling team • Complicated sub-system team • Platform team
69. Stream aligned team 価値のある単一の仕事のストリームに 沿って働くチーム ストリームとは、仕事やサービスの場合 もあるし、機能一式のこともあり、ユー ザージャーニーやユーザーペルソナの１ つのような場合もある なるべくそのチームだけですばやく安全 に顧客やユーザーに価値を届けられるよ うに、チームに権限が委譲されている。 他のチームへの仕事の引き継ぎは必要な い
70. Enabling team 特定のテクニカル（プロダクト）ドメイ ンのスペシャリストから構成され、能力 ギャップを埋めるのを助ける。 複数のストリームアラインドチームを横 断的に支援し、適切なツール、プラク ティス、フレームワークなどアプリケー ションスタックのエコシステムに関する 調査、オプションの探索、正しい情報に 基づく提案を行う ストリームアイランドチームへのテクニ カルコンサルティングチーム
71. Complicated sub-system team 複雑なサブシステムを含んだり利用する システムの担当となるストリームアライ ンドチームの認知負荷を減らす。 習得や育成の難しいスキルや専門能力を 活かして、担当するサブシステムの複雑 さに取り組む コンポーネントの共有可能性ではなく、 チームの認知負荷に応じて必要になる
72. Platform team ストリームアラインドチームが自律的に 仕事を届けられるようにする。 ストリームアラインドチームは本番環境 のアプリケーションの開発、運用、修正 を含む全体のオーナーシップを持つ。 プラットフォームチームは、内部サービ スを提供することで、ストリームアライ ンドチームが下位のサービスを開発する 必要性をなくし、認知負荷を下げる
73. 今年度のプロダクト開発組織 P Mission
 TL/BE
 iOS/SM
 Android
 UX/UI
 PM/PO
 PM
 L Mission
 BE
 iOS/SM
 Android
 UX/UI
 PM
 Refactoring1
 Android/SM 
 EM1
 SRE
 iOS(委)
 BE
 BE
 Refactoring2
 BE
 EM2
 BE/SM
 Yugun
 FS
 FS
 WebFE
 WebFE
 PM
 UX/UI
 Data
 DE
 DA
 DA
 SRE
 SRE
 SRE
 SRE(委)
 QA
 QA
 App Enabling
 iOS/SM
 Android
 iOS/SM
 iOS(委)
 Android
 Android
 BE Enabling
 SRE
 BE
 TL/BE
 BE
 BE
 BE
 Web Enabling
 FS
 WebFE
 FS
 WebFE
 EM2
 EM2
 EM2
 EM1
 EM1
 EM1
 EM1
 EM1
 Stream aligned Platform Enabling Platform Enabling Enabling
74. 今年度のプロダクト開発組織 特徴 • ベースの考え方はチームトポロジー • 横軸のファンクションが必要だったため、Backend, App, Webにおいて、プロジェクトとし てEnablingを配置（各チームから兼務）
75. 課題 • 技術的負債への向き合い方は組織形態として噛み切れてはいない • Enablingチームをプロジェクトとして配置しているため、全員が兼務 • エンジニアがスクラムマスターを兼任している • チーム感のインタラクションモード（コラボレーション、X-as-a-Serviceなど）を明確に 決めてやりとりをするまでには至っていない
76. アーキテクチャはモジュラーモノリスへ
77. アーキテクチャはモジュラーモノリスへ モジュラーモノリスへのリプレイスを進行中・・・！ どうして？
78. アーキテクチャはモジュラーモノリスへ 技術的負債が溜まってきてしまったことによる開発スピード低下
79. アーキテクチャはモジュラーモノリスへ P Mission
 TL/BE
 iOS/SM
 Android
 UX/UI
 PM/PO
 PM
 L Mission
 BE
 iOS/SM
 Android
 UX/UI
 PM
 ストリームアラインドチームは2つ存 在するが、横断してのコミュニケー ションはそれなりに密な現状
80. アーキテクチャはモジュラーモノリスへ 再生サー ビス 収録サー ビス 課金 サービス 管理サー ビス 音声コン テンツ 音声処理 サービス サービスごとにDB分割もできていないまま、現在のアーキテクチャがある
81. アーキテクチャはモジュラーモノリスへ 再生サー ビス 収録サー ビス 管理サー ビス サービスごとにDB分割もできていないまま、現在のアーキテクチャがある
82. アーキテクチャはモジュラーモノリスへ ではどうする？
83. アーキテクチャはモジュラーモノリスへ ただただモノリスに戻してしまうと、容易に大きな泥団子になる懸念 →モジュラーモノリス
84. アーキテクチャはモジュラーモノリスへ • サービス境界を見極めたい ◦ モジュール境界のほうが、誤っていたときに戻しやすい • マイクロサービスへの可能性はできるだけ残したい
85. アーキテクチャはモジュラーモノリスへ モジュール① モジュール② モジュール③ なにかしらの利用者
86. アーキテクチャはモジュラーモノリスへ モジュール① モジュール② モジュール③ なにかしらの利用者
87. アーキテクチャはモジュラーモノリスへ 一部からDB分割していってもいい
88. アーキテクチャはモジュラーモノリスへ モジュール① モジュール② モジュール③ なにかしらの利用者
89. アーキテクチャはモジュラーモノリスへ サービス境界を切るべき部分を軽量に見定めたい いきなり垂直分割すると、適切でなかったときのコストが高い 事業モデルの行き先を探索している段階においては、相性が良さそう マイクロサービスへ移行する足がかりにもなる
90. まとめ
91. まとめ • ユーザーへの価値と向き合う仕組みのために、組織形態を定期的にみなおし、 編成してきている • 何が価値になりえそうかを、チームで駆動させる • 判断を遅らせたい段階においては、守備的な選択（＝モジュラーモノリス）を 取るのも選択肢の一つ
92. おまけ
93. お知らせ VoicyでエンジニアのVoicyのエンジニアメンバーが テックニュースや日々の活動をお届けしています！ 私は水曜日に配信しています💡
94. ご清聴ありがとうございました