この記事は RevComm Advent Calendar 2022 の 15 日目の記事です。
はじめに
こんにちは。RevComm シニアエンジニアマネージャーの瀬里です。
普段はエンジニアリング組織づくりをメイン業務として行っています。
「組織づくり」というと聞こえが良いですが、実際は年間数百人の方と面談して一緒に働きたいと思える優秀な方をアトラクトするということがとても重要な業務だったりします。
早いもので、RevComm で働き始めてこの 12 月で 5 年目に突入しました。
この間に自分の働き方がどのように変わったのか、そしてエンジニア組織としてもどのように変わってきたのか、今後どのような組織を目指しているのかについて今回は書いていきます。
マネジメント論やスタートアップ組織論だとかいうものはネットや本を探せばいくらでも出てくるのでほぼ割愛して、リアルにやってきたこと、感じたことを書くことで多少なりとも誰かの役に立てればと思います。
2018～2019 年：組織未満
1 ヶ月の業務委託を経て 2018 年 12 月に入社した際、エンジニアリング組織は業務委託と社員で合わせても 5-6 名くらいだったかと思います。既に MiiTel という主力製品が世に出てから数ヶ月経った頃です。
当時は明確な部署やチームというものもなく、とにかく各々が貢献できる部分を全力でやるという感じでした。 スタートアップでよくあるような障害や、予想もしていない問題が起きて徹夜でやりきるということを一番体験した期間だったりします。
この頃の課題の 1 つは、過去の自分のインタビュー記事でも書いていますが個人事業主の集まりという感じでチームとしてのまとまりが少なかったことです。ただ、今となって振り返ると、少ない人数で事業を急成長させるために、それぞれのメンバーが個別に動いてとにかく目の前の課題に全力を尽くすという働き方は当時の最適解であったとも思えます。 少人数なのにチーム制であるとかフォーマットが統一された正確なドキュメント化だとか、不確定な未来について語り合うといったことは時間をとられるだけで開発の速度は上がりません。
一方で反省点があるとすれば、最初期から最低限文書化だけははじめからある程度ルールを設けておけばよかったな、ということです。 技術者としては README.md や ARCHITECTURE.md などで導入や技術選定、機能の開発の意図などをごく簡単にでも残しておくと後で楽です。このちょっと面倒くさくて省いてしまいたくなる作業は、後々になって人数が増えてくるとかなり効いてきます。
小まとめ
実際の業務 / 立場
- サーバーサイド・フロントエンド・インフラの設計・実装（がんがんプログラミングする）
- 入社後半年も過ぎない頃から採用面談もしていた
組織の形
- 未形成。かろうじてマイクロサービスという単位でオーナーが決まっている程度
- 全社的に「部署」というものがなかった
求める資質
自ら課題を発見し、率先して取り組めること
重要な課題
人が足りない
組織運営の上での施策例
- 特になし。そもそも「部署」という概念が存在せず、必要なかった
- とにかく全員ができることを全部やって会社の成長を図る
2020 年：担当範囲の決定
エンジニア全体の人数が 20 名程度になりました。
徐々にマイクロサービスを起点としたチーム制が成り立ってきた感じです。自分自身も明確にWebアプリケーションを担当するという形で Web チーム全体（バックエンド・フロントエンド）のリーダーとして動いていました。
毎月、徐々にメンバーが増えるという状況でしたが大きな混乱はなく、オンボーディングはメンバーの入社時に適宜行うスタイルでした。工夫していたのは、例えば障害対応の方法について、一度説明を受けたメンバーが次に入ってきたメンバーに説明するようにする、といった後任を育てるという点です。
オンボーディングやKT（Knowldege Transfer）の内容を録画して見てもらうようにするということも考えましたが、ほぼ浸透しませんでした。完全リモートワークなのにここまでやってしまうと人間味がなくなるという理由もあります。
小まとめ
実際の業務 / 立場
- Webチームのマネージャー
- と言いつつ、サーバーサイド・フロントエンド・インフラの設計・実装（がんがんプログラミングする）
組織の形
マイクロサービスチーム
求める資質
自ら課題を発見し、率先して取り組めること
重要な課題
人が足りない
組織運営の上での施策例
- オンボーディング用質問チャンネル
この頃に社内で分からないことがあるメンバーを積極的に助ける Slack チャンネルとして、QA チャンネルというものがたちあがりました。
（Question & Answerの略）
フルリモートワークということで、隣のメンバーの肩を叩いて「ねぇ、これどうやるの？」と気軽に聞くことができない環境において、みんなが助け合うという趣旨の場所は重要です。
※今は QA = Quality Assuarance（品質）のチームが内部で立ち上がったこともあり、チャンネル名は 「helpme」チャンネルとなっています。
helpme チャンネルに今でもピン留めされている初期の自分の投稿をそのまま転載します。
- RevComm特有の開発プロセスとか資料どこ、とかについては即質問。（悩むな。わかりやすく用意できていない先達たちが悪い。あなたのせいじゃない）
- １時間調べて悩んで試してもわからなかったら、すぐ訊くべし。
リモートワークだからこそ、困ったときは同僚を頼れる場を作っておくことが安心感に繋がります。また、皆が回答をしているのをみて「自分も何か手伝えることはないか」と自発的に行動してくれるようになる副次的効果があったりします。
- エンジニア独自の評価プロセス
明確な評価制度というものが全社で導入され、全社共通で行われるバリューを基にした 360 度評価と、テック独自のスキルも加味した MBO（目標管理 : Management by Objectives）と評価期間内に取り組んだことのプレゼンテーション評価というものを組み合わせて行うようになりました。
2021 年：明確な組織化
エンジニアが 30 人を超えました。いわゆる 30 人の壁というものが出てきます。
実際に様々な技術レベル・価値観の方が入ってくることによって、全員が同じレベル、モチベーションで働くということが難しくなってきます。
良いか悪いかは別として、休日に Slack のメンション通知が少なくなってきたのもこの頃です。以前は四六時中 Slack 通知が届き、自分も含めて「この人いつ寝てるの？」とか思うメンバーもちらほらいました。
今回の Advent calendar で初日を担当した、リサーチディレクターの橋本さんがジョインしたのもこの頃で、リサーチ部門がテクノロジー部門と明確にわかれました。
小まとめ
実際の業務 / 立場
- テクノロジー部門の組織づくり
- 障害対応の場合は手を動かすことも
組織の形
マトリックス型組織
求める資質
自ら課題を発見し、率先して取り組めること
重要な課題
人が足りない
組織運営の上での施策例
- 技術領域単位でチーム組成
コーポレートエンジニアリング（社内システム向けの業務ツールを担う）という特殊な領域以外に関して、プロジェクトにはそれぞれのチームからメンバーがアサインされてプロジェクトを推進するマトリックス型組織と呼ばれる形を採用しました。
1 チームは極力 5 名以下。経験上、非定型的なエンジニアの業務では 5 名程度までが 1 人のマネージャーが見れる限界だと思います。
- 採用プロセスの整備
エンジニアの採用には、該当技術領域のチームのメンバーが一度は必ず面談する技術領域単位での採用プロセスを取り入れています。例えばフロントエンドならフロントエンドの現場メンバーが出ます。
スカウトも各チームが責任を持って行う体制へと移行。
これには良い面と悪い面の両方があります。現場メンバーが出ることで、候補者の技術レベルや「一緒にプロジェクトをやっていけそうか」など判断し易くなる一方で、エンジニアの開発時間が面接に割かれて開発が遅れることにも繋がります。
2022 年：常に改善中
さて、人数がだいぶ増えました。
いつのまにか 50 名を突破し、いまこの記事を書いている時点でエンジニアの総数は 80 名。その数が 100 名に近づこうとしています。
組織的には順調に人数も増え、開発やQAなどのプロセスもしっかりとまとまってきています。
日々の技術的課題への自発的な取り組みはもちろんですが、Tech Talkという社内ライトニングトークやもくもく会といったものがエンジニアから自発的に企画されて行われています。
会社全体ではフットサル・アウトドア・ゲームといった各種クラブ活動も続々と生まれてきています。
もちろん、ここまできても課題は出てきます。
主なところでは以下のようなことです。
- メンバーは増えているが、開発スピードをさらに高めたい
- 様々なミッションを担当しているメンバーが全員納得するような評価制度を目指してアップデートを図りたい
課題は解決するしかないので日々改善施策を試す日々が続いています。
小まとめ
実際の業務 / 立場
- テクノロジー部門のマネジメント・執行役員
- たまに設計・コーディングなども
組織の形
マトリックス型組織
求める資質
自ら課題を発見し、率先して取り組めること
重要な課題
人が足りない
組織運営の上での施策例
- マネジメントとプロフェッショナルの分離
従来はシニアエンジニアやテックリードといった、プロフェッショナルなメンバーが管理職（ラインマネジメント）も兼務しているケースが多かったです。
しかし、事業成長速度を出すために 1on1 や評価といったマネジメント業務よりも技術的な課題解決、エンジニアリングなどにプロフェッショナルとして集中してもらう方が良いと判断し、マネジメント業務から離れてもらう方向を取っています。
マネジメントとプロフェッショナルの職種は取り組む課題に違いがあるだけで、どちらが上ということはありません。興味がある分野でそれぞれが最高の成果をあげれば組織としても成長して大きくなり、より大きなことに取り込むことができるようになった結果としてそれぞれが望むキャリアを歩んでいけると思っています。
RevComm ではエンジニアのキャリアアップとして組織的な課題に取り組むマネジメントか、技術的な課題を専門として取り組むプロフェッショナルどちらにより興味があるかヒアリングし、それぞれに合ったキャリア形成を行っていけるように取り組んでいます。
- 評価制度の見直し
組織の拡大に伴って評価対象の人数も増え、マネージャーの負担が増えてきています。マトリックス型組織においてありがちな課題として、MBO やスキルベースのマネージャーによる評価だけではプロジェクトの貢献度に対する評価がおろそかになりがちということがあります。
現在は、この点を改善をすべく正当な評価をより低負荷で行うことを目標に制度の見直しを行っています。
さいごに
RevComm のエンジニア組織は 100 名に近づいてきていますが、まだまだ組織的には「これがベストのやり方である」とか「こういう方が必ずフィットする」という答えはありません。
必要なのはその時々においてベストだと思える状態に組織を持っていくことであり、組織、そして中にいるメンバーのマインドも変わり続けることだと思います。
最後まで目を通していただき気づいた方がいるかもしれませんが、初期から今まで組織的として「求めている資質」と「重要な課題」は同じです。
組織がいくら拡大したとしても一緒に働く仲間に最も求めていることは一貫して同じであり、自ら課題を発見して率先して取り組んでいくような自走力です。
個人的には、プログラミングやビジネスマインドは後からでも鍛えようがありますが、自走力というものは価値観や長年の経験などからくるものであり、一朝一夕では身につくものではないと考えています。そのため、採用の段階で必ず重視してみています。
また、不思議なことにエンジニアが 100 名近くまで増えた現段階においても、やりたいことすべてを行うためにはまだ人が足りていない状況は変わっていません。おそらくこれは人が増えるに伴い会社としてやりたいことも際限なく出てくるので、永久にこの課題は解決されないのかもしれないと思っています。
ここまでで、本の引用を避けてこれまでに体験してきたこと、その時点で感じたことなどを書いてきました。重要なことは、本の内容は知識として活用しつつ組織の実情に応じて必要な仕組みを作り出すこと、組織の全員が自分ごとと捉えて自発的に動ける場を作り出すことだと思っています。
急拡大しながら日々変わり続ける組織で働くことに興味をもっていただいたら、是非弊社の採用サイトを覗いてみてください。エンジニアだけではなく様々なポジションで募集しています。
是非一度気軽に話しましょう。
