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

by natacon

Slide 1

Slide 1 text

課題解決ではなく、価値創造を求めるVoicyの開発チームの組織設計と立ち上げの勘所 2023/07/27 株式会社Voicy 灘脇裕一 (@natacoon) Developers Summit 2023 Summer

Slide 2

Slide 2 text

自己紹介灘脇裕一 Backend Engineer 機能開発チームリーダースクラムマスター 2012.04 - HRTech 2020.07 - Voicy 本日はよろしくお願いします！ @natacoon 好きなモノ: 服とねことスプラトゥーン株式会社Voicy

Slide 3

Slide 3 text

アジェンダ ● 自己紹介 ● Voicyの事業紹介 ● 組織の変遷 ● プロジェクト開発か、プロダクト開発か ● 組織変遷とアーキテクチャの意図 ○ 3年前 ○ 前年度 ○ 今年度 ● 私たちが選択した今後のアーキテクチャ方針 ● まとめ ● おまけ

Slide 4

Slide 4 text

Voicyのサービス

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

ここ数年のエンジニア組織の変遷

Slide 9

Slide 9 text

3年前のプロダクト開発組織 Backend Frontend iOS App Android App PdM Designer Project Project 縦割り組織から、プロジェクトごとにメンバーをアサインして進めるプロジェクトサイロ化した形態

Slide 10

Slide 10 text

前年度のプロダクト開発組織 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のミッション達成を妨げる特定のミッションを掲げて解決するチーム

Slide 11

Slide 11 text

今年度のプロダクト開発組織 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

Slide 12

Slide 12 text

Voicyのサービスの登場人物

Slide 13

Slide 13 text

Voicyのサービスの登場人物アクター音声コンテンツを聴く人音声コンテンツを配信する人 Voicy管理者（toB向け機能など）

Slide 14

Slide 14 text

Voicyのサービスの登場人物再生App 再生サービス収録App 収録サービス課金サービス収録Web 再生Web 管理Web 管理サービススマートスピーカー音声コンテンツ音声処理サービス

Slide 15

Slide 15 text

3年前のプロダクト開発組織

Slide 16

Slide 16 text

Slide 17

Slide 17 text

3年前のプロダクト開発組織 Backend Frontend iOS App Android App PdM Designer Project Project 縦割り組織から、プロジェクトごとにメンバーをアサインして進めるプロジェクトサイロ化した形態 Eng B Eng A PM

Slide 18

Slide 18 text

なぜ縦割りでプロジェクトごとの形態だったか性質上、投資すべき事業モデルが見えづらい側面わかりやすい一般的なアプローチ「世の中にはこんな課題がある！こういう事業モデルでいこう！」 →投資→利益

Slide 19

Slide 19 text

なぜ縦割りでプロジェクトごとの形態だったか Voicyの事業性質上、なかなかこの対象を定義できていなかった組織だけでなく、アーキテクチャもどのような想定をすべきかが判断できていなかった

Slide 20

Slide 20 text

プロジェクトか、プロダクトか

Slide 21

Slide 21 text

向き合う対象がプロジェクトか、プロダクトかプロジェクトはじめとおわりが明確に存在し、それが効果を上げて終了することが目的つまり、納期を超過してしまうことと、完成の目処が立たなくなることが最大のリスクになる。 →スケジュール不安を減少させられるようにものごとを進める傾向が強くなる

Slide 22

Slide 22 text

向き合う対象がプロジェクトか、プロダクトかプロダクト製品・サービスが継続的に収益を上げ続け、終了しないことが目的顧客やマーケットに受け入れられず、採算が取れずにサービスを提供できなくなることが最大のリスク →マーケット不安を減少させられるようにものごとを進める傾向が強くなる

Slide 23

Slide 23 text

向き合う対象がプロジェクトか、プロダクトかプロジェクトプロダクト目的終了すること作ること終了しないこと使ってもらうこと抱えている不安スケジュール不安マーケット不安対処したい不確実性方法における不確実性目的における不確実性

Slide 24

Slide 24 text

向き合う対象がプロジェクトか、プロダクトかプロジェクトは終了するできあがったモノをグロースするのはだれ？作ったものに向き合う人たちがいなくなる or 交代する施策を考える人→依頼→プロジェクト ↺↺↺ この流れが本当に正しいのか？

Slide 25

Slide 25 text

向き合う対象がプロジェクトか、プロダクトかプロダクト終了させないこと →プロダクトの価値を継続的に向上させるここに向き合うチームが必要になる

Slide 26

Slide 26 text

（余談）3年前のプロダクト開発組織 Project ① Project ② プロジェクト型で組織を設計しているとよくあること・・・ Eng B Eng A

Slide 27

Slide 27 text

（余談）3年前のプロダクト開発組織 Project ① Project ② Eng B Eng A コードレビュー

Slide 28

Slide 28 text

（余談）3年前のプロダクト開発組織 Project ① Project ② Project②のことよくわかんないんだけど・・・まぁ変じゃないっぽいし、いっかー Eng B Eng A Eng A コードレビュー

Slide 29

Slide 29 text

（余談）3年前のプロダクト開発組織 Project ① Project ② Project②のことよくわかんないんだけど・・・まぁ変じゃないっぽいし、いっかー LGTM!!! Eng B Eng A Eng A コードレビュー

Slide 30

Slide 30 text

向き合う対象がプロジェクトか、プロダクトかここ数年で、ソフトウェア開発の前提が変化したプロジェクト型開発 → プロダクト型開発

Slide 31

Slide 31 text

改めて「不確実性」とは

Slide 32

Slide 32 text

改めて「不確実性」とは不確実性を減らして、開発を行っていこう！そんな振り返りが出たことはないだろうか？

Slide 33

Slide 33 text

改めて「不確実性」とはこの「不確実性」ってなんだろうか不確実性って言うと、いまだにちょっと難しく聞こえる

Slide 34

Slide 34 text

改めて「不確実性」とは「不確実性」＝「わからないこと」

Slide 35

Slide 35 text

未来に関すること方法の不確実性目的の不確実性「わからないこと」

Slide 36

Slide 36 text

他人に関すること（通信不確実性）コミュニケーション情報の非対称性、限定合理性「わからないこと」

Slide 37

Slide 37 text

「わからないこと」これらは「不安」を作り出すサイクルを助長する不安はコミュニケーションで埋めようとする引力が働くので、未来に対しても、他人に対しても不確実性が増大する

Slide 38

Slide 38 text

「わからないこと」未来への不確実性特に、目的の不確実性が多方面に表出化してきたことにより、 Whatをなるべく踏み間違えず、最短で価値を検証する流れが主流になった

Slide 39

Slide 39 text

「わからないこと」最短で価値を検証するにはかなりの小規模なプロダクトと組織でない限りは単純なコミュニケーションだけではうまくいかない

Slide 40

Slide 40 text

そもそもなぜ組織に構造が作られるのか

Slide 41

Slide 41 text

そもそもなぜ組織に構造が作られるのか少人数で相互に深いコミュニケーションをとっていけば、問題を解決することはできるが、コミュニケーションに費やす時間が増えすぎると何もできなくなってしまう

Slide 42

Slide 42 text

そもそもなぜ組織に構造が作られるのか誰と誰がコミュニケーションし、誰と誰はあまりコミュニケーションしないのかという形が必要になる →組織化と構造化

Slide 43

Slide 43 text

そもそもなぜ組織に構造が作られるのかこのときの問題点コミュニケーションが多いと想定していたのに本来必要がなかったまたはコミュニケーションが少ない想定の関係性に誤りがあった

Slide 44

Slide 44 text

そもそもなぜ組織に構造が作られるのかコミュニケーションが多いと想定していたのに本来必要がなかったコミュニケーション量は勝手に必要量に近づくが、同じチームに属している場合、双方に余分な時間が生まれる

Slide 45

Slide 45 text

そもそもなぜ組織に構造が作られるのかコミュニケーションが少ない想定だったが、実は多かった普段の活動とは別の軸での会議などが頻繁に必要になる

Slide 46

Slide 46 text

そもそもなぜ組織に構造が作られるのかコンウェイの法則の話組織構造とそれが作り出すソフトウェア設計との間の関連性を示す原則組織が設計するシステムは、組織のコミュニケーション構造を必然的に反映する

Slide 47

Slide 47 text

そもそもなぜ組織に構造が作られるのか逆コンウェイ戦略コンウェイの法則で生まれる制約を逆手に取ろうという戦略組織の構造を意図的に変更することで、その結果として生まれるシステムのアーキテクチャを制御するというもの ※作りたいアーキテクチャ、モジュールを一緒に定義すべき（でないと余分なコミュニケーションが多々必要になる）

Slide 48

Slide 48 text

閑話休題

Slide 49

Slide 49 text

Voicyで実現したかったこと組織の形態を通じて、価値に向き合うことのできる形を作りたかった

Slide 50

Slide 50 text

3年前のプロダクト開発組織 Backend Frontend iOS App Android App PdM Designer Project Project

Slide 51

Slide 51 text

どうして縦割り組織のプロジェクト型開発だったか？チームでなにかに向き合うというより、機能特化な体制と意識だった（ので、この当時は開発もウォーターフォールで行っていた）

Slide 52

Slide 52 text

どうして縦割り組織のプロジェクト型開発だったか？なにが正解になりえそうか判断ができなかったプロダクト組織全体としてユーザ体験に向き合えていなかったので、メンバー各々がこれらを考えられるようにしたかった →事業がもたらす価値に対してチームが駆動できるように

Slide 53

Slide 53 text

我々のサービスにとっての価値とは？？？

Slide 54

Slide 54 text

我々のサービスにとっての価値とは？？？サービスを利用するメインのアクターである、以下の登場人物にフォーカスすることからはじめることにした ● リスナーさん ● パーソナリティさん

Slide 55

Slide 55 text

我々のサービスにとっての価値とは？？？プロダクト = 終了させずに価値を届け続ける

Slide 56

Slide 56 text

我々のサービスにとっての価値とは？？？サービスを利用するメインのアクターである、以下の登場人物にフォーカスすることからはじめることにした ● リスナーに価値を生み出すプロダクト開発 ● パーソナリティに価値を生み出すプロダクト開発

Slide 57

Slide 57 text

前年度のプロダクト開発組織

Slide 58

Slide 58 text

Slide 59

Slide 59 text

アーキテクチャ視点でも、サービスの単位に近い形に再生App 再生サービス収録App 収録サービス課金サービス収録Web 再生Web 管理Web 管理サービススマートスピーカー音声コンテンツ音声処理サービス

Slide 60

Slide 60 text

前年度のプロダクト開発組織この組織形態である程度は各チームが駆動できるようになった

Slide 61

Slide 61 text

前年度のプロダクト開発組織技術的負債などの影響により、アウトプットに問題が出てきた

Slide 62

Slide 62 text

前年度のプロダクト開発組織一部のサービスのリプレイスを視野に入れていきたい

Slide 63

Slide 63 text

今年度のプロダクト開発組織

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Team Topologiesの登場「マシュー・スケルトン, マニュエル・パイス『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター）」

Slide 66

Slide 66 text

Team Topologiesの登場組織は、機械的で線形なシステムではなく、複雑で適応性を持つ有機体として見るべきである「マシュー・スケルトン, マニュエル・パイス『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター）」

Slide 67

Slide 67 text

組織図の問題ソフトウェアアーキテクチャのドキュメントが実際のソフトウェア開発が始まるとすぐに陳腐化するのと同様に、組織図も常に現実と一致していない

Slide 68

Slide 68 text

チームトポロジーで定義しているチームタイプをおさらい ● Stream aligned team ● Enabling team ● Complicated sub-system team ● Platform team

Slide 69

Slide 69 text

Stream aligned team 価値のある単一の仕事のストリームに沿って働くチームストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの１つのような場合もあるなるべくそのチームだけですばやく安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。他のチームへの仕事の引き継ぎは必要ない

Slide 70

Slide 70 text

Enabling team 特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行うストリームアイランドチームへのテクニカルコンサルティングチーム

Slide 71

Slide 71 text

Complicated sub-system team 複雑なサブシステムを含んだり利用するシステムの担当となるストリームアラインドチームの認知負荷を減らす。習得や育成の難しいスキルや専門能力を活かして、担当するサブシステムの複雑さに取り組むコンポーネントの共有可能性ではなく、チームの認知負荷に応じて必要になる

Slide 72

Slide 72 text

Platform team ストリームアラインドチームが自律的に仕事を届けられるようにする。ストリームアラインドチームは本番環境のアプリケーションの開発、運用、修正を含む全体のオーナーシップを持つ。プラットフォームチームは、内部サービスを提供することで、ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる

Slide 73

Slide 73 text

Slide 74

Slide 74 text

今年度のプロダクト開発組織特徴 ● ベースの考え方はチームトポロジー ● 横軸のファンクションが必要だったため、Backend, App, Webにおいて、プロジェクトとしてEnablingを配置（各チームから兼務）

Slide 75

Slide 75 text

課題 ● 技術的負債への向き合い方は組織形態として噛み切れてはいない ● Enablingチームをプロジェクトとして配置しているため、全員が兼務 ● エンジニアがスクラムマスターを兼任している ● チーム感のインタラクションモード（コラボレーション、X-as-a-Serviceなど）を明確に決めてやりとりをするまでには至っていない

Slide 76

Slide 76 text

アーキテクチャはモジュラーモノリスへ

Slide 77

Slide 77 text

アーキテクチャはモジュラーモノリスへモジュラーモノリスへのリプレイスを進行中・・・！どうして？

Slide 78

Slide 78 text

アーキテクチャはモジュラーモノリスへ技術的負債が溜まってきてしまったことによる開発スピード低下

Slide 79

Slide 79 text

アーキテクチャはモジュラーモノリスへ P Mission  TL/BE  iOS/SM  Android  UX/UI  PM/PO  PM  L Mission  BE  iOS/SM  Android  UX/UI  PM  ストリームアラインドチームは2つ存在するが、横断してのコミュニケーションはそれなりに密な現状

Slide 80

Slide 80 text

アーキテクチャはモジュラーモノリスへ再生サービス収録サービス課金サービス管理サービス音声コンテンツ音声処理サービスサービスごとにDB分割もできていないまま、現在のアーキテクチャがある

Slide 81

Slide 81 text

アーキテクチャはモジュラーモノリスへ再生サービス収録サービス管理サービスサービスごとにDB分割もできていないまま、現在のアーキテクチャがある

Slide 82

Slide 82 text

アーキテクチャはモジュラーモノリスへではどうする？

Slide 83

Slide 83 text

アーキテクチャはモジュラーモノリスへただただモノリスに戻してしまうと、容易に大きな泥団子になる懸念 →モジュラーモノリス

Slide 84

Slide 84 text

アーキテクチャはモジュラーモノリスへ ● サービス境界を見極めたい ○ モジュール境界のほうが、誤っていたときに戻しやすい ● マイクロサービスへの可能性はできるだけ残したい

Slide 85

Slide 85 text

アーキテクチャはモジュラーモノリスへモジュール① モジュール② モジュール③ なにかしらの利用者

Slide 86

Slide 86 text

アーキテクチャはモジュラーモノリスへモジュール① モジュール② モジュール③ なにかしらの利用者

Slide 87

Slide 87 text

アーキテクチャはモジュラーモノリスへ一部からDB分割していってもいい

Slide 88

Slide 88 text

アーキテクチャはモジュラーモノリスへモジュール① モジュール② モジュール③ なにかしらの利用者

Slide 89

Slide 89 text

アーキテクチャはモジュラーモノリスへサービス境界を切るべき部分を軽量に見定めたいいきなり垂直分割すると、適切でなかったときのコストが高い事業モデルの行き先を探索している段階においては、相性が良さそうマイクロサービスへ移行する足がかりにもなる

Slide 90

Slide 90 text

まとめ

Slide 91

Slide 91 text

まとめ ● ユーザーへの価値と向き合う仕組みのために、組織形態を定期的にみなおし、編成してきている ● 何が価値になりえそうかを、チームで駆動させる ● 判断を遅らせたい段階においては、守備的な選択（＝モジュラーモノリス）を取るのも選択肢の一つ

Slide 92

Slide 92 text

おまけ

Slide 93

Slide 93 text

お知らせ VoicyでエンジニアのVoicyのエンジニアメンバーがテックニュースや日々の活動をお届けしています！私は水曜日に配信しています💡

Slide 94

Slide 94 text

ご清聴ありがとうございました