CTOやエンジニアリングマネージャーなど、エンジニアに関わる機会が多い方に向け、エンジニア組織拡大に伴う課題と対策、エンジニア組織のカルチャー醸成、エンジニアの評価制度について、実施した施策の事例を共有するオフラインイベントを開催しました。今回は、そのイベントのレポートをお届けします。

<登壇者>（写真左より）
・株式会社タイミー / CTO / 亀田 彗
エンジニア組織規模：40名
テックブログ：https://tech.timee.co.jp/
・LAPRAS株式会社 / CTO / 興梠 敬典
エンジニア組織規模：外部パートナーを含め約20名
テックブログ：https://tech-blog.lapras.com/
・株式会社Progate / CTO / 島津 真人
エンジニア組織規模：外部パートナーを含め約15名
テックブログ：​https://tech.prog-8.com/​
・株式会社ワンキャリア / CTO / 田中 晋太朗
エンジニア組織規模：外部パートナーを含め約50名
テックブログ：https://note.com/dev_onecareer

エンジニア組織拡大に伴う課題と対応

亀田さん：弊社も、組織拡大に伴って課題を感じたフェーズが何度かあります。ひとつのスクラムチームで全体を回せている時期はスタートアップらしい楽しさに溢れていると思うのですが、プロダクトが成長してエンジニアの数も10名を超え、チームをふたつに分けるタイミングで最初の課題が出てきました。

結果的にはサーバーサイドとモバイルという、リソース効率を最大化するようなチームの組み方をしたのですが、プロダクトに対するオーナーシップが……という雰囲気もありました。

2段階目の課題が出てきたのは、エンジニア組織が20名を超えたあたりのタイミングです。当時はプロダクトマネジメントとエンジニアリングマネジメントを、区別せずに運用していました。プロダクト開発をディレクションしながら進めていく役割に、ピープルマネジメントの要素も持たせてしまっていたんです。

そのため、人材育成の文脈を重視して組織を動かしていくべきシーンであっても、プロダクトの目指す方向に合わせてマネジメントをするケースが出てきました。リソースの奪い合いのような状況にもなったため、エンジニアリングマネジメントとプロダクトマネジメントの分離をおこないました。

エンジニアが40名になった今その形で落ち着いていますが、最近は3段階目の課題の気配を感じていて、技術の推進をどうおこなっていくか、マイクロサービスにするべきかといった議論に向き合っているところです。

組織拡大に伴う、最近の施策についての記事はこちら

島津さん：エンジニア組織を再構築するにあたって、変えるスピードや施策、エンジニアやPMといった職能ごとのメンバーの割合などについてうかがいたいです。

亀田さん：変えるスピードはシステムと一緒で、ビッグバンリリースではなく目指す方向に向けて、段階的にリリースしていく形がいいと思っています。そのなかでPMやEM、スクラムマスターなど、組織に対して影響力がある人を早い段階で巻き込むことも重要です。段階的に変更していくことで、次の打ち手も見えてきます。

職能バランスの理想を固めておくのは大切ですが、そのままいきなり切り出しても「何をすればいいのかわからない集団」が生まれてしまいます。まずはプロジェクトありきのチームとして編成して、終わった後も維持していく形で定着を目指す流れがいいのではないでしょうか。

興梠 ：課題の発生に合わせて段階的に対応されていますが、課題の検知はどのようにおこなっていますか？　　

亀田さん：最初の課題は、メンバーからの「やりづらい」という声を受けて対応しました。ふたつめは、創業メンバーのひとりの退職がきっかけです。エンジニアとして技術を深めたい方に対して、エンジニアリングよりもプロダクトマネジメントの要素が強い役割を任せていた結果「タイミーではやりたいことを実現できない」と思わせてしまったので、このままでは更なる人材流出も起こり得ると考えて改革に取り組みました。

田中さん：弊社のエンジニア組織拡大に伴う課題は、マネージャー不足です。正社員エンジニアの数が10〜15名ほどになり、プロダクトを増やし始めた段階でチーム分けをしたのですが、マネージャーは自分が兼務するという状態が続いていました。結局ひとりで複数のチームを見るので、チーム間の癒着が起きたり、プロダクトが密結合になったりする時期がありました。

乗り越えるためにやったことは、愚直な手立てではありますが、マネージャーレイヤーの採用と社員の引き上げのふたつです。弊社はエンジニアリングの面白さをアピールしてきた会社ではなかったので、興味を持ってくださる母数が圧倒的に少ない点がネックになりましたが、LAPRASさんにもお世話になりながら数名のマネージャーを採用できました。

引き上げについては、弊社は正社員の平均年齢が29歳と若く、経験豊富な社員も少ないため、資質や可能性を見極めて抜擢する形です。社内のベストプラクティスの蓄積もまだ不足している状態なので、みんなで模索しながら進めています。約1年半前から採用と引き上げの両面に注力した結果、現在は一応落ち着いた状態にあります。

エンジニア組織構築における課題と、解決のための施策について書かれた記事はこちら

島津さん：弊社の場合は、エンジニアの人数が20名ほどに増えたタイミングで、チーム内で会社のビジョンに対する思いが揃わなくなりました。

弊社のバリューに「Deliver the best」というものがあるのですが、プロダクトマネージャーからの依頼に対して、エンジニア側が「それはDeliver the bestじゃないのでできません。技術的負債です」と返すような形で、エンジニア組織VSその他の構図になってしまったんです。

出典：Progate Cuiiture Book

僕がCTOに就任して半年ぐらいなのですが、就任前からその構図に課題感を感じていて、経営層の指針を示すためのツールのひとつとして、Deliver the bestなどのバリューに紐付けるわかりやすい評価制度をつくって組み込みました。

それまでマネージャーの判断に委ねられていた部分が大きかったところを、グレードごとの期待値の詳細を表にしてマトリックスにすることでグレード間の差分が明確になるように。結果としてよりきちんと評価していきたい動き方を明確にでき、徐々に目線が揃うようになってきました。

例えば、深刻なバグが出た際、以前であれば特定のコンポーネントごとにそれについて詳しい方が対応してくださっていましたが、今はチームで一丸となって対応できるようにしていこうという価値観が醸成され、過去の経緯なども追いつつみんなでプロダクトをよくしていく体制ができました。属人化しかけていた状況を改善し、組織として強くなれたと感じています。

エンジニア組織におけるカルチャー醸成

島津さん：弊社は今、組織がガラッと変わったフェーズで、カルチャーをどう植え付けるかという観点で考えています。エンジニア組織のカルチャーと言えば、技術特化などいろいろありますが、僕としては「Rustに詳しいです」「コミッターです」のような特定の領域を深めていく方向性より、「チームとしてみんなで一緒に強くなっていこう」「プロダクト開発のためにはなんでもやります」というノリの醸成がすごく大事だと思っています。

また、勉強会をやるにしても、コミュニケーションのためなのか、知識を深めるためなのか、きちんと目的意識を持ったうえで開くことが重要です。弊社では勉強部というチームをつくり、例えばLT会の開催時には横のつながりを重視することを明言してもらうなど、目的が明確化されるよう働きかけています。勉強会はまだ数回しか開催していませんが、うまくいきそうな手応えを感じているところです。

亀田さん：カルチャー醸成の仕組みづくりに、行動指針などのツールは取り入れていますか？

島津さん：そうですね。行動指針は、先ほどお話しした等級評価と同時につくりました。弊社の3つのバリューに対して行動指針を5つずつ設定し、浸透させるために毎月の全社会で繰り返し伝えています。

田中さん：最終的に辿り着きたいカルチャーの理想形については、何か想定されていますか？

島津さん：弊社はエンジニアへのスカウト文を送る際に必ずお伝えしている「いろんなアイデアを爆速で形にし続ける」という言葉を実践できる環境が、カルチャーとしての理想形だと考えています。適当なアイデアでもポンポンと出し合える環境も大事ですし、アイデアを爆速で形にし続ける継続性も重要視しています。自発的に挑戦し続け、成長し続けるカルチャーを創出していきたいです。

田中さん：弊社の目指すカルチャーを私なりに言語化すると「ビジネス感覚を持ち合わせた、ギークなエンジニアであろう」です。そこを目指すための施策としては、Progateさんと比較的近いと感じています。週3回ほど業務時間を割いて勉強会を開催し、それぞれがインプットした情報を共有したり、議論したりすることで、ひとりで勉強するよりも深く思考する場を設けています。

ビジネス感覚を育てる部分については、まだ仕組み化できていない状態です。ただ、マネージャーや経営陣からのフィードバックで「PLにフィットするものよりも、資産になるものをつくろう」と口うるさく指摘されるので、自然と身についている気はしていますが、今後は仕組み化していきたいと思っています。

亀田さん：カルチャーは「自分たちとそれ以外」を決める行為だと思っていて「どんなエンジニアと働きたいか」が明確になっていない状態で明確にするのは難しいと感じています。そのためあまり言語化できていないのですが、エンジニアの最終面接では、僕と同じようにモノづくりが好きで、そこに自己実現を重ねて、自分の専門性を増やしているかを見ています。また、性善説で組織を回せるかどうかで運用コストが大きく変わるので、最終面接では誠実さも重視しています。

弊社のプロダクトは、ゲーミフィケーション的なものから給与支払いに関する財務管理まで幅が広いので、どんなバックグラウンドを持つエンジニアでも活躍できる場所があると思っています。そのため、弊社のエンジニアは技術的なスキルもさまざまですし、ヒューマンスキル面においてもリーダーシップに優れた方もフォロワーシップに強い方もいます。多方面に分散している状況そのものが、自然とカルチャー醸成に繋がっているのかもしれません。

エンジニアの評価制度

亀田さん：エンジニア組織に向けた評価制度は現在制作中ですが、各チームが狙うべき、ビジネス成果として運用しているプロダクトマネジメント上のKPIを設定しています。複数のサービスでチームを組んだ際にも、個人に責任や評価が偏らないように、チームとしての成果として評価することを意識しています。

もうひとつ意識しているのは、品質に関する指標です。問題なくクリアしているかを厳しく判断して、問題が起きた場合は強制力をもって介入するためにKPIを運用しています。

エンジニアの評価制度はまだない状態ですが、弊社の人事評価は成果評価は一切織り込まない完全能力評価なので、OKRに関してもストレッチなゴールを決めてもらいながら進めています。完全能力評価をする理由としては、成果は不確実性が伴うからです。「プロダクトをリリースする」という成果評価を置いたとしても、何かしらを犠牲にするトレードオフが強く入ってくると思うので、それは避けたいと考えているためです。

興梠：弊社も割と能力的な部分と、ソフトスキル寄りな部分で評価をしているのですが、エンジニアの納得感はどのように醸成していますか？

亀田さん：エンジニアの納得感を醸成していくことは、エンジニアリングマネジメントの重要な仕事だと思っています。そのため、等級は敢えて抽象度を高く設定し、対話のなかで解釈を定めて、決めていくようにお願いしています。

ただ、エンジニアマネジメントはいろいろな仕事が混じりやすいので、しっかり専念するための組織づくりが必要です。

島津さん：先ほどお話ししたDeliver the bestなど、それぞれバリューに紐付けた評価制度を運用しています。KPIやOKRを評価制度と完全に分離して、個人の行動を元に、継続性と再現性を重視しながら評価する形です。例えば1億円の事業を1日で立ち上げたとして、毎年同じ規模の事業を立ち上げられるのであれば年収での評価、1回で燃え尽きてしまった場合は賞与での評価になるように設計しています。

どのポジションであっても、経営陣の考えるバリューを正しく理解して事業に落とし込める方であれば高いグレードで評価されます。逆にだれかに伴走してもらう必要があるようなケースでは、おそらくジュニア評価です。スタンスや影響範囲などを踏まえ、何ができたら次のグレードに行けるのか、グレード間の差分を評価軸として明文化し、行動に基づく評価をじっくりおこなっています。

OKRに関しては、今何をすべきなのかを判断するガードレールとして機能させています。

売上目標を1億円に設定したとして、1億円を達成するために石油を掘ろうとする方が出てきた場合に、「うちは石油を売る会社じゃないからダメだよ」と止めるための指標です。

指標となる数値をDAUにするのか、総ユーザー数にするのかでも大きく変わってくるので、かなり注意深く調整しながら、社員がある程度自走できる環境をつくるためにガードレールはしっかり設置しています。弊社では3ヶ月、年間、3年と、それぞれの期間に適したガードレールがあり、3年のガードレールは決算期の半年以上前から、年間のガードレールは四半期の4期で構想に着手します。

各チームのOKRのトラッキングは、リード陣が中心となってデイリーで行っていますが、手動で更新する形では面倒で運用が滞ってしまうので、基本的には自動で更新されるダッシュボードをメインに管理しています。現状を軸にOKRを立てると3ヶ月後にはズレている可能性があり、そうなるとガードレールとして機能しないので、設定する範囲の見極めが大切です。

田中さん：弊社は全社がMBOベースで、エンジニアもデザイナーもディレクターも同じ部署だった経緯があり、エンジニア組織が独立した後もMBOベースで評価しています。そのため、基本的に成果評価です。

成果評価ではありますが、開発における課題を解決するための誘導はおこなっています。アウトプットを継続的に増やしてFour Keysを伸ばす、各個人やリーダーレイヤーのKPI目標にデプロイ回数頻度を盛り込んで重点的に追っていくなど、開発組織全体の共通目標を揃えて取り組んでいます。

それでも、MBOの限界を感じるシーンは時々あります。半期ごとの評価で、半期のうち1〜2回は目標を変えられるのですが、難易度を変えずに方向を軌道修正するための変更だけでなく、出た成果に合わせての変更も、成果が出ていない場合の下方修正もできてしまうんです。マネージャーがそこを上手くコントロールできれば、今後もMBOでやっていけるかなと考えています。

まとめ

当日はこの他にも質疑応答や懇親会も実施させていただき、各社CTOによる組織拡大の悩みや、マネジメントに関する情報交換等が活発に行われていました。登壇いただいた方、現地で実際にご参加いただいた方、ありがとうございました。

的確なチーム分けや自走できる環境づくり、評価制度の構築、納得感を醸成するコミュニケーションなど、本イベントで共有された事例を貴社のエンジニア組織の成長にお役立ていただけますと幸いです。

（ライター：成澤綾子）