はじめに
この記事はVoicy Advent Calendar 2022の1日目の記事です。
みなさんこんにちはVoicyで技術部門の責任者をしています山元(@yamageniii)です
みなさん始まりましたアドベントカレンダー2022！
Voicyはブログリレーもやっていまして11月はたくさんのアウトプットが出ました。 tech-blog.voicy.jp
そんな中で以下のような質問をしてしまいました。
山元「え、11月に毎日ブログ書いてたのに、アドベントカレンダーもやるの？」 「「もちろんやります！！」」
お恥ずかしい。視座が下がっていた山元だったのですが、発信意識が最高に高いメンバー達に背中を押されて、最初のバトンを受け取りました！
Voicyは12月もマッチョにブログをアウトプットするので楽しみにしてください
Voicyの開発組織の紹介
今日はVoicyの 2022/12 現在の開発組織を紹介します。
開発組織は会社によってそれぞれ違うと考えています。 それはトップから考えると経営状況開発注力領域、ボトムから考えればリソースやスキル、カルチャーなどのビジネスのコンテキストに制約を受けて設計されるからです。
ただ、その中でも共通で使える考え方や設計は存在しており、TeamTopologieはより広い範囲にあてはめられる設計を紹介した書籍になっている考えています。
VoicyではTeamTopologieの考え方に影響を受けながら、現在のコンテキストに合わせた設計でチームを構成しており、 それを紹介することで開発組織を作る際の参考になればと思って、今回筆を取りました。
開発組織全体像
大きく7つのチーム+1つのチームで構成されています
Personalityチーム
これはVociyの発信者であるパーソナリティさんの体験を最大化するチームです。
Voicyは発信する人に審査性をとっていることもあり、パーソナリティさんの体験を重要視しています。 そのため、パーソナリティさんに関する機能開発を最重要視するチームを作っています。
プラットフォームでありがちな鶏卵問題のように、プラットフォーム全体からプロダクト設計をするとどちらを重要視して考えればいいのかわかりにくくなるところを、パーソナリティさんの体験に絞ることで見るべきデータや考えるべきことを絞ることで パーソナリティさんの新しい体験を創出するという難易度の高いミッションにフォーカスするようにしています。
実際はパーソナリティさんの新しい体験を増やす大規模開発中です。
こちらはStream-aligned teamとなっています
Listenerチーム
これはいわばVoicyのユーザのボリュームゾーンである音声を聞くリスナーさんの体験を最大化するチームです。
プラットフォームビジネスにとって、リスナーさんは常に使い続けて欲しいユーザであり、 その体験を最大化するチームとなっています。
Personaliityチームと二つ分けた理由としては、 体験の主語になる人物を分けることで見るべき重要指標を減らすことができます。 パーソナリティさんの一人当たりのデータと、リスナーさんの一人当たりのデータでは、 見えるインサイトも変わり、意思決定も変わります。 その優先度を両方を鑑みながら意思決定するよりは、 両方重要なステークホルダーと置くことで、それぞれのチームに優先度付けの権限を委譲することでそれぞれの体験改善の速度を向上するのが狙いです。
現在ListenerチームではVoicyの音声を聴き続けたくなるために、データを分析して、仮説を立てて、その仮説をプロダクトで実証しています。
こちらはStream-aligned teamとなっています
Qualityチーム
このチームは品質面の問題のイシューを解決するために立ち上がりました。
具体的には不具合の対応や、ユーザビリティが低くなっている点を解消することを目的としたタスクフォースチームです。
CREに近い動き方をしながら、重要度の高いイシューを解決しつつも、ソフトウェアを分析して将来課題になるであろう箇所を未然に潰しています。 Voicyは大きく負債解消のリソースを今までとっていなかったからこそ、現在はそのエラーバジェットを消すためのチームになっています。
現在はタスクフォースなチームではあるものの、QualityControleの点ではこのチームのロールは必要で、ソフトウェア負債を未然に防ぎながら、 ユーザと開発者にソフトウェア開発を通してバリューを出すことが大きなミッションと考えています。
こちらはTeamTopologieではあてはまるチームはないかもしれないです。
Yugun team
このチームは主に二つの主語で体験改善をしています。それは「企業さん」「社内」です。
Voicyは新しい音声市場を作る上で、企業さんと一緒に開発をしていくことが重要と捉えて、その体験を作るチームとなっています。
また社内での運用面でもいわゆる「出来たらいいこと」「出来るけど時間がかかること」はある中で、社内の開発などもこのチームで行っています。
こちらはStream-aligned teamとなっています
QAチーム
このチームはVoicyのQAプロセス全般を管理するチームになっています。 QAチームはVoicyのあるべき姿を定義し、リリースするプロセスで新しい不具合を埋め込まないような開発プロセスにコミットしています。
上記の目標を達成するためにチームにQA文化を根付かせたようなスケールするQA組織が必要なため、QAの民主化やテストプロセスの整備を行っていつつも、QAチームでもテストを行っています。
こちらはEnabling teamになっています
Dataチーム
データチームは主に3つの方向性で活躍しています。 - BI (Bussiness intelligence) - AI - Platform
BIでは主にデータ分析をしながらビジネスの意思決定をサポートします。 AIはレコメンドのロジックを修正しながらも、長期的な実験的投資(R&D)をしながら、新しいマッチング体験を探っています。 PlatformはVoicyの膨大なビッグデータを処理できるデータ基盤の開発と整備を行います。
こちらはComplicated Subsystem/ Platform teamになっています
SRE / Platformチーム
SRE / Platformチームはインフラの開発運用やリリースプロセスの改善など、DevOpsのOps部分を改善開発したり、 音声処理やプッシュ通知などの共通基盤の開発改善を行うチームです。
普段はインフラの運用しつつメトリクスを監視しながら問題がないことを確認しており、必要となればサーバサイドも開発しにいきます。 Voicyはプラットフォームサービスで様々な人に利用されているからこそシステム上でも様々問題が起こるために、 サービスを落として信頼を失わないようにコントロールしています。
また最終的にはembedとしてチームにSRE的な機能を持たせてスケールしないといけないと考えており、運用を楽にしつつ布教できると良いと考えています。
こちらはComplicated Subsystem / Platform teamになっています
Developer Cultureチーム
このチームは誰かが専任でいるチームではなくて、 全員のエンジニアが強制で所属するチームになっています。 「組織も一つのプロダクト。全員でアップデートを」という行動指針があるように、 自分たちでエンジニア文脈の組織開発を行って欲しくて、このチームを作りました。
実際に取り組んでいる内容を紹介すると
- 11月のブログリレー
- voicyエンジニアの音声発信チャンネル「voi-chord」運用
- 社内勉強会の運用
- 社外へのイベント発信の運用
- 社内大型ハッカソンの企画
などを今のエンジニア全員が参加してアイディアを出しながら作っています。 エンジニアはどんどん発信が大事でDeveloperRelationなどの文脈でも重要と捉えており しっかりリソースを取ることで実現しています
まとめ
いかがでしたでしょうか？ チームの構成は会社において変わると思われますが、 実際解決したい課題は共通点は多く、開発組織も似た形で解決できるものと思います。
実際の開発組織の事例を見ることで少しでも参考になれば幸いです。
