こんにちは クラスター株式会社で Engineering Manager(EM) をしている kurain です。
今日は、クラスターのエンジニアが参加する会議体について紹介します。会議体の作り方について長々続くので、先にまとめを書いておくと
- エンジニアが自律的に開発プロセスを改善できるように、会議体を3つ定義しました
- それぞれの会議体には権限と責務が明示されています
- エンジニアは自ら発案して上記の会議体を開催できるので、業務改善が上手く回っています
という話です。
背景
なぜこのような会議体の定義が大切なのか背景から話を始めましょう。
クラスター株式会社はこの3年間で社員数が約6倍になりました（上図は2023年6月時点の資料）。エンジニアの数も6倍……とはいきませんが準ずる増え方をしています。同時に月1回の出社のみが求められるフルリモートに近い働き方が行われています。人が増え、かつ、リモートワークが前提になると何が起こるのか? それは、会議体が増えます!
人が増えているのでコミュニケーションパスは増えますし、リモートワークには立ち話のような概念がないので、つい会議体を設定して人の時間を拘束しがちです。
もちろん、そんな状況が放置される訳はなく、ある時期から「〇〇デイリーとか、XX定例とか全部やめましょう！」と社長からよく言われるようになりました。
こう言われる側としては「会議体が多いのは良くないが、全部やめていい訳ではない。すると会議体を残すならば何かしらの基準が必要だな。」ということになります。そこでシニアエンジニアの:kyokomi:と一緒に会議体の棚卸しを始め、会議体の基準を作ることにしました。気をつけていたのは以下のようなことです。
- エンジニアが所属しているチームのデイリーミーティングは全員必須のままにしたい
- チームを横断した会議体は人数を絞ることができそう
- 新しい改善や企画を始めるのは誰でもできるようにしたい
- だからといってミーティングが増えるのは嬉しくない
会議体を定義する
上記をふまえて、会議体の役割を整理したわけですが、まずは名前を3つに絞りました。Working Group(WG), 委員会, 勉強会 の3つです。いままでは、会議体ごとにバラバラな命名規則で役割が曖昧になることが多かったので、エンジニアが参加する会議体は原則この3つの種類にしぼりました。ただし、所属するチームでのミーティングはこの3つには含まれません。チームごとにデイリーミーティングや、チーム独自の催しがあります。
そしてこの会議体はどれも
- 自律的に始めることができる
- Engineer Manager(EM)が許可すれば、会議体をつくれる
- 自主性が尊重される
- Owner が運用方針を決める
- アウトプットを求める
- 会議体の活動報告が必要
- 目的を達成するか、達成できないことが明らかになったら粉砕する
- 必要性がなくなったら解散するのを良いことと捉える
- 粉砕はcluster社内用語で、何かを消したり終わらせることです。ポジティブな意味で使います。
という共通のルールを持っています。また、これらのルールは社内ドキュメントに明記されており誰でも参照できるようになっています。権限については、それぞれの会議体で異なるので順に紹介しましょう。
Working Group
まずは、Working Group (WG)です。WG は
- WG member 以外にもタスクをアサインすることができる
- チーム開発への影響がある時は 各EM <-> WG Owner (+CTO) で調整する
- 4人程度に収めることが望ましい。人が絞られていて、権威性がある。誰でも参加できるわけではない
こういった特徴をもつ会議体です。会議体に参加してない人にもタスクをアサインすることができるのが大きな特徴で、そのために強い権限をもつ会議体になっています。cluster の機能開発はチーム単位で開発を行っていて、そのリーダーはEMが担当しています。なのでチーム主導の開発とWG主導の開発は、優先順位を争うことがあります。その場合は、WG の Owner と EM が調整することになっており、新規機能開発よりWG発案のリファクタリングを優先する。といった判断もよく行われています。
具体的な WG には Server WG / Unity WG / iOS WG / Android WG / Web WG / Client Continuus Integration (CCI) WG などがあります。cluster が動く環境毎の専門家の集まりが多くなっています。たとえば Server WG は、cluster の server engineer の集まりですが、enginner のなかでもグレードの高いメンバーが集まっており、機能を横断して実装方法の guideline をつくったり、サーバー運用方法についてのルールを定める活動をしています。
委員会
つぎは、委員会です。一番 cluster の特徴が出ており、この会議体の設計で特に気に入っている部分です。委員会には次のような特徴があります。
- 発生したタスクは委員会の member が自分の時間を調整して行う
- 原則として委員会の外の人にタスクをアサインすることはできない
- タスクを人に振らないと改善できないような大きい課題が出た時は、期限付きで WG を結成する事をEMに提案する
WGとは違って会議体の member 以外にはタスクを任せることができません。一方で自分で賄える範囲であれば自由に開発プロセスの改善を行うことができ、その提案を全 engineer に広めることができます。
例としては、Onboarding 改善委員会、ユビキタス言語委員会などが活動しています。Onboarding は新しい engineer が入社したときに行われる初期研修のことです。新入社員が参照すべきドキュメントを整備したり、メンターが指名されていることを確認したりとOnboarding が上手く行えるように日々改善を行っています。Onboarding終了後にメンター・メンティーへヒアリングも行っており、Onboardingの満足度も高い状態を維持できています。
勉強会
そして最後が勉強会です。以下のような特徴があります。
- 同じ領域の開発者が集まって情報交換する。新しいタスクはアサインできない
- 開発に直接関わる内容を扱う
これは、社内勉強会を指しているので、実施している会社も多いのではないでしょうか。Unityの会, 完全に理解した会 と呼ばれる会が実施されています。完全に理解した会では、モバイル通知基盤のような全社共通技術についての知識共有であったり、Product Manager を完全に理解するといった職能についての理解を深める会が実施されています。
定義による効果
会議体の役割と始め方を明確に定義した効果もあって、エンジニア主体で新規に始める会議体が自然に発生するようになりました。最近始まったものとしては、Bug Bash 委員会があります。Bug Bash は QA Team によるテストの前にエンジニアが集まって、新規機能のテストをするイベントです。3年近く行われている開発プロセスの1つですが、Bug Bash自体の改善はほとんど行われていませんでした。エンジニアの有志がその改善のために委員会を立ち上げました。
粉砕された会議体もあります。code review 委員会がそれです。Pull Request に書いてほしいことや、Reviewer、 Reviewee に期待されることについて、プラットフォーム事業部全体で統一されたものがなかったのでその定義のために発足しました。成果としては、全 engineer 共通の項目については code review に求めることを定義できました。一方で、server や unity, mobile といった領域毎に課題は違うということも発見され、その解決はそれぞれのWGに委ねる形になりました。一定の解決を見つけた時点で会議体の粉砕(解散)を選ぶというのはとても良い判断で、だらだらと会議体を残さない文化がつくられていると考えています。
こういった新陳代謝があるおかげで、エンジニア組織全体での会議体の数は一定水準で抑えることができています。エンジニア一人あたりでは、自分の所属するチームのデイリーと、1つか2つのWGまたは委員会への参加で運用できているようです。
もっと効率的で楽しいリモートワークのために
ここまで、自律的で効率のよい会議体の話をしてきました。とてもうまく行っていますが課題もあります。それは、雑談機会の醸成です。雑談は会議体ではないですが、重要なコミュニケーションツールです。月1の出社日にランダムに選ばれた人と雑談するシャッフルブレイクを実施したり、チーム毎に夕食にでかけたりしています。月1以外にも、cluster 上にオフィスを作ってあつまるようにするなど工夫を凝らしていますが、なかなかオフィスですれ違って喋るような機会には追いつけません。VR空間での創造を仕事にしている我々としてはもっとうまい方法を見つけていきたいものです。
ということで、クラスター株式会社の会議体について紹介してきました。クラスター株式会社では開発プロセス改善に興味のあるエンジニアを募集しています。以下のリンクからご応募お待ちしています！
