これはアソビュー！ Advent Calendar 2023の25日目です🎅
今年のアドベントカレンダーは2面公開なので、ぜひそちらも御覧ください！
アソビューでVPoE兼Tech Leadをしているdisc99🐼です！
今年のアドベントカレンダーは1日に技術的取り組みを紹介させてもらったので、最後の今日は組織的な取り組みの紹介をできればと思います🎁
はじめに
現在アソビューでは、プロダクト開発を行っているプロダクト組織(*1)が110名、会社全体では300名(*2)を超えています。
また、中心事業であるマーケットプレイスやパートナープラットフォーム他、ギフトやふるさと納税などの新規事業を展開しており、提供サービスはBtoC、BtoB、BtoBtoCなど10以上あります。
www.asoview.co.jp
更に自社でサービスを展開しているため、プロダクト組織以外にも、営業やマーケティング、カスタマーサクセスやサポートデスク、人事や経理、法務などのコーポレート部門などの多数の組織が存在します。
この規模になってくると単一事業や単一チームであれば起こらないような問題が発生してきます。
*1. エンジニア以外にもプロダクトマネージャーやデザイナー、QAなども含む
*2. 従業員他、業務委託、協力会社を含む
起こる問題
コミュニケーションパスの問題
組織の規模が大きくなると、ステークホルダーが社内外に増え、意思決定をするためのコミュニケーションが複雑化します。
対象者が増えるほど、コミュニュケーションパスが劇的に増加していきます。
【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com
またダンバー数で考えると、人間が円滑に安定して維持できる関係である150人前後を既に会社全体で大きく超えています。 ja.wikipedia.org
これらに対して、チームや組織のサイズを適切にコントロールし、コミュニケーションパスや認知負荷を抑える必要があります。
100名を超え、フルリモートが中心となるプロダクト組織では、チーム内だけでなくチーム外のコミュニケーションをどのように設計するかが重要になっています。
組織構造の問題
チームや組織のサイズをコントロールするのも重要ですが、同時に企業として向かう方向性を揃える必要もあるため、意思伝達やガバナンスが取れる構造が必要になります。
これ踏まえてチームや組織を扱う最もオーソドックスなアプローチは事業別や機能別のピラミッド組織で、組織図上はこの形状になっている企業が多いと思います。
一方でピラミッド組織は組織内での上下や、事業/機能を超えようとすると、コミュニケーションコストが高まったり、裁量権の固定化が進み部分最適が起こりやすくなります。
これらに対し、組織図とは別に事業と機能などを組み合わせを行った、マトリックス組織の構造を適用した体制を取っている企業も多いと思います。
アソビューでもガバナンス体制を整えるため組織図上はピラミッド型になっていますが、実態としてはマトリックス構造の組織体制をとっています。
プロダクト組織内でも似たような構造として、フィーチャーチームやコンポーネントチームで分かれてはいるものの、実態としてフィーチャーとコンポーネントのマトリックス構造のようなコミュニケーションを取っている企業も少なくないと思います。
このアプローチの代表として有名なのがSpotifyモデルです。
Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds
Spotifyモデルでは、SquadとChapterのマトリックスに加え、GuildのようなChapterを超えたコミュニティ、大きな組織などではTribeによるグルーピングも紹介されており、多様化するプロダクト組織における指針の参考になります。
また、最近では最近ではチームトポロジーで紹介されている、4つのチームタイプを参考にしている企業の話もよく聞くようになりました。 pub.jmam.co.jp
組織設計として様々な枠組みや分類がある一方で、Spotifyは "Spotifyモデル "を使っていないというのも有名な話です。 www.agility11.com
詳細は解説されている記事が多数存在するので割愛しますが、私自身が感じる部分としてSpotifyモデルが上手くいなかったのと同様に"現実の組織は全てをきれいに分類するのは難しく歪な部分は存在する"ということです。
もちろんそれぞれの考え方は非常に重要で適用できる部分も多くありますが、全く同じ事業や組織が無いように、個々の状況に合った枠組みを考える必要性を感じています。
多様性
多くの人が関わることになれば、それだけ多彩なスキル、キャリア、思考性、ライフステージなどに向き合うことになります。
エンジニアのスキルとして考えてみても、プロダクトやプロジェクトマネジメント、ピープルマネジメントに代表されるようなマネジメントスキル、スペシャリストとして、フロントエンド、バックエンド、ネイティブアプリ、機械学習、インフラ他多数のスキルセットがあり、それぞれの中でも強弱が存在します。
人それぞれのグラデーションがある中で力を発揮してもらうにはガチガチの枠を規定してしまうと活躍や成長機会を減らしてしまいかねません。
一方で組織全体で見たときにあまりにも枠組みがない状態だと、指針が見えず個人のスキルに依存しすぎたり、目指すものが見えづらくなります。
変化への適応
アソビューの事業、プロダクトは年々成長しており、それに伴って直近3年でプロダクト組織も倍近い人数に成長しています。
組織を取り巻く環境は、人、事業、プロダクト、社会状況、時間経過など様々な要因により変化しており、それに対し適応していく必要があります。
これらは複雑で非常に不確実性の高いパラメーターの掛け合わせになるため、一人で正確な答えを予測することは困難です。
例えばアソビューでもコロナ禍では売上昨年対比で95%減少の危機的な状況を経験しました。
一方で逆境を逆手にとり、そこから数ヶ月間で昨年対比230%成長を生み出した新機能リリース、巣ごもり消費に向けた新サービスのリリース、競合の買収による体制やプロダクト戦略の変更など、予め予想が困難な目まぐるしい変化が起こることもあります。
signal.diamond.jp
目的
非常に前置きが長くなってしまいましたが、会社の成長に伴い見えてきた課題に対し、以下を目指しています。
- 組織規模拡大に対応する
- 組織構造に柔軟性を持たせる
- 1人1人の活躍、成長機会を最大化する
- 変化に素早く適応できる組織を作る
その為の具体策として、プロダクト組織内のロール(役割)に対して以下の取り組みを始めました。
- 目的や責任、領域の見える化
- アップデートプロセス定義
長々と書いた割には当たり前の内容です😆
しかしこの2つが非常に重要だと考えています。
組織体制を変更する場合には、多くの組織ではその目的や責任を明文化したり説明すると思います。
しかし、その場限りになってしまったり、体制に対する決定権がある人物が現場の詳細な課題を理解しきれていないことも少なくありません。
結果的に、実際の運用時で曖昧になったり、実態と合わなくなってしまうことがあると思います。
この関係性は、作る人(Dev)と運用する人(Ops)が別れて発生するサイロ化によく似ています。
DevOpsを実現する上では、作る人(マネージャーなど)と運用する人（メンバーなど）が同じモニタリング情報（可視化）を確認し、継続的に協力して変更を繰り返すサイクル（アップデートプロセス）を作る必要があります。
そのため、アソビューではHoraspiritを利用したロールの可視化とアップデートプロセスに従った運用を開始しました。
Holaspirit
Holaspiritはホラクラシー組織管理ツールです。
導入に当たって、LAPRASさんの事例は非常に参考になりました。
hr-tech-lab.lapras.com
今回導入ではホラクラシー組織にするわけではなく、あくまでもその考え方を取り入れ、ロール(役割)やそのロールに対する目的（パーパス）、責任（アカウンタビリティ）を可視化するために利用しています。
理由として、
- Wikiやスプレッドシートと比べ柔軟性が高く今回の目的を達成するための可視化ツールとして適していた
- ホラクラシー自体は非常に重要な考え方である一方で、厳密なルール(ホラクラシー憲章)があり、それらに従った組織運営を最初から行うにはハードルが高かった
などがあります。
期待する効果
可視化による効果
ホラクラシーにはロール（役割）という考え方があります。
分かりやすい例で言うと、CTOやエンジニアリングマネージャー、テックリードなどはその代表です。
一方で、これらの責務は企業によって大きく異なってきます。
例えば、エンジニアリングマネージャーを例にとってみても企業により大きく責務が異なってることが見えてきます。 qiita.com
組織の状態が異なれば同じ名称でも目的や責任が変わるのは当然ですが、それ故にそのミッションが曖昧なまま定義されたロールは、名称が一般的なほど個々の認識が異なりが独り歩きしやすくなります。
本来着目すべきはその目的や責任で、それに適切な名前をつけることが重要です。
その点においてHolaspiritでは、そのロールに対する、目的（パーパス）、責任（アカウンタビリティ）、領域（ドメイン）などを定義することができ、曖昧性を排除する手助けをしてくれます。
また、ロール自体は企業内で定義されている役職に囚われることなく定義することができます。
これを可能にすることにより、会社の状況や個々の能力に合わせた、柔軟な役割、権限設計が可能です。
以下の例はロールが持つ責務や人数は同じですが、ロール名や担当が異なります。
エンジニアリングマネージャーに集中していた責務や、分割されていた開発・運用が新たなロールとして変わっています。
組織全体として果たさなければならない責任や目的は同じですが、分解方法を変え複数のロールを担うことで、個々のグラデーションに最適化し、成長や活躍の機会へと繋げることができます。
一方で、分割したことでロールが増え関係性も複雑化するのも事実なので、誰がどのようなロールと責務を担っているかの可視化が重要となります。
これらの情報はHolaspirit上で全て確認することができ、一緒に働いたことがないチームや組織内でどのようなロールがあるか、誰が担当しているかをいつでも知ることができます。
アップデートプロセスによる効果
ホラクラシーには、ガバナンスミーティングとタクティカルミーティングというプロセスが存在します。
これらは、組織内で発生するひずみ（現実と理想のギャップ、課題）をロールの再定義や責務の変更により解決していく定期ミーティングです。
従来の組織変更は、月単位や場合によっては年単位になりやすいですが、これらをより短い間隔で実施することで、素早く変化に適応していくことを目指せます。
また、小さく試し失敗したらやり直すなどのチャレンジもしやすくなります。
実際のところこの考え方は特別なものではなく、多くの企業では組織図上の役割とは別に施策を進めるときに、役割分担をすることは多いと思います。
しかし、これらに対して決まったルールがない場合も多く、々の組織やチームのスキルに依存することになるため、そのプロセスを明確化、かつ定期実施するとが重要と考えています。
定期に行う重要性に関しては、プロジェクトスプリントの考え方が非常に参考になりました。 www.projectsprint.org fukabori.fm
これらの変更は誰か1人で行うわけではなく、各サークルごとに行い、よりその領域の解像度が高いメンバーが主体的に実態にあったロールの変更を繰り返すことができます。
また、各々のサークルで自由に変更を繰り返すとカオスな状態になりかねないため、スーパーサークルやサークルリードと協力してガバナンス管理をすることも可能です。
最後に
今回はアソビューにおける、組織面での取り組みについて紹介させてもらいました！
これらは私が過去に大規模なプロダクト組織に所属していたときに感じた、1人1人の役割が小さくなり歯車のようになっている状態を解決したいという気持ちから来るものでもあります。
私が以前書いた技術面での取り組み記事として以下のように記載していました。
“個々の能力を最大化し、一人でもサービスを作り変えられるだけの大きな権限と裁量を与えること”
このときから変わらず、組織が拡大しても1人1人が活躍できる組織を目指しています！
この取り組みは始めたばかりで、不安な部分もありますし、今後色々な課題も出てくると思います。
しかし、より良い組織を作るため一歩づつでも理想に向かって前進し、それらの積み重ねが将来の大きな成功へと繋がると信じています！
まだまだ成長過程の組織ですが、こういった組織を一緒に作っていきたい、チャレンジしてみたい方を大募集しています！
カジュアル面談もありますので、少しでも興味があればお気軽にご応募いただければと思います。
