こんにちは！カオナビ採用広報チームです。
「エンジニアの役割定義って、一度決めたら終わりじゃないの？」「ロールを変えるだけで、組織は本当に変わるの？」そんな疑問に真正面から答えてくれたのが、プロダクトデベロップメント本部でエンジニアリングマネージャー（EM）を務める佐野元気さんです。
佐野さんは自らEMロールの再定義に取り組み、そのほか職能の役割設計にも関わってきました。そして今回、エンジニアロール全体の大幅アップデートを主導しています。
「やることリストの消し込み」から「アウトカムへの責任」へ。この転換の裏には、組織が大きくなるにつれて見えてきた課題と、それでも変えることをやめなかった覚悟がありました。ロール設計に込めた設計思想、現場のリアルなプロセス、そしてまだやれていないことまで、率直に語ってもらいました。
【登場人物】
佐野 元気（さの げんき）
プロダクトデベロップメント本部 TalentHRカイゼン部 部長 兼 エンジニアリングマネージャー（EM）。前職での開発経験を経てカオナビに入社。開発者としてチーム開発に携わる中で組織づくりへの関心を深め、EMロールへ。一度テックリードを経験した後、再びEMに戻り、エンジニアロール全体の設計を主導。プロダクトデベロップメント本部横断でエンジニア組織の組織開発を担う。
便利屋じゃない、戦略的な存在にしたかった - EMロール再定義の原点
── まずは現在のお仕事について教えてください。
今はプロダクトデベロップメント本部のTalentHRカイゼン部で部長をしています。ユーザーの方々がカオナビをより使いこなせるように、オンボーディング周りなどのさまざまな障害を取り除いていく。カオナビが目指す「タレントインテリジェンス」や「インフィニットモデル」といった世界観を、より多くのお客様に体感していただくための開発を行っている部署です。
それと並行して、EMロールとしてプロダクトデベロップメント本部全体のエンジニア組織開発にも携わっています。こちらは部署を横断してのミッションで、組織設計や制度設計といった領域を担っています。
── EMのロールは兼務なんですね。それは意図的なのでしょうか？
はい、意図的にそうしています。今、EMと呼ばれるロールの人は全員がマネージャー以上の役職と兼務する形です。
EMのミッションを実現するには、社内的な権限、評価権限なども含めてを持っていた方が振る舞いやすいんです。同時に情報も入ってきやすい。だからなるべくマネージャー、もしくはそれ以上の役職と兼任してもらうようにしています。EMロールの設計段階でも、そこは意識していた部分ですね。
── だからこそ、マネージャー以上の役職と兼任してもらう形を意識しているんですね。
そうですね。ただ、実はこれにはちょっとした背景があります。私たちは「エンジニア組織の役割定義」を、あえて会社の硬直的な職務規程に縛られない「本部内独自のロール」として運用しています。変化の激しいプロダクト開発の現場において、ロールの定義を柔軟に、かつスピーディーにアップデートし続けるためです。
ただ、その副作用として、会社全体で定義された「特定の職務権限」を取りづらいという側面がありました。
それをクリアし、EMが本来のミッションである「チームの成果最大化」に集中できる環境をつくるための現実的な解が、マネージャー職との兼任でした。EMが権限と情報を持って振る舞いやすくするための、私たちなりの工夫です。
── そもそもカオナビのEMは何をする人なんですか？
一言で定義すると、「担当組織のエンジニアの成果と成長に最終責任を持つ人」です。
1人のEMが1つの部をスコープとして持ち、そこでエンジニアが最大の成果を出せる環境を整え、メンバーが持続的に成長し続けられる状態を実現していく。手段は多岐にわたりますが、全員がエンジニアリングをバックグラウンドとして持っているメンバーで構成されています。
環境が変わると、人の体験は変わる - 組織づくりへの目覚め
── 組織設計への興味はどこから生まれたのでしょうか？
前職からカオナビに転職した時に、開発者体験がすごく変わったんです。大げさな話ではなく、本当に地味なことなんですけど──たとえば、ソースコードのインデントのスペースが規約に沿っているかを前の会社では目視で確認していた。カオナビに来たら「いや、それは自動で見てくれるよ」と。人間が頑張って見なくていいものを、ちゃんと仕組みで解決していたんです。
組織の中で取り組んでいることや環境の違いで、中にいる人の体験がこんなに変わるんだなと。それが原体験として1つありました。
もう1つは、もっと直接的な体験です。チーム開発をやっていく中で、チームの動かし方を工夫するとパフォーマンスが大きく変わるということを実感したんです。一緒に働いた人から「一緒に働けて良かった」と言ってもらえたり、自分が色々やったことで人に良い影響を与えることができたという手応えがあった。自分1人でやるよりも大きな成果が出せる。その面白さを見出してから、より大きい範囲でもやってみたいなと思うようになりました。
── 技術者だと「組織にはあまり興味がない」という方も少なくないと思いますが、佐野さんの場合はどうだったのでしょうか？
少し特殊かもしれません。テックリードをやっていた時期に、同じテックの仲間と「今、何にモチベーションがあるか」を話し合ったことがあるんです。他のメンバーは技術的なことやプロダクトを作ることに取り組めること自体をモチベーションにしていた。でも自分は、そういうことをできる環境を作ることの方にモチベーションがあるんだなと気づきました。
技術を深掘りすること自体にめちゃくちゃ強い関心があるわけではなくて、環境づくりや仕組みづくりの方にやりがいを感じやすい。自分の中でその志向性がはっきりした瞬間でした。
── ご自身のことを「組織の環境を作る人」と定義されている？
いや、実はそこまで自分を定義してはいないんです。
カオナビで歩んできたキャリアって、半年ごとに「半年前にこれをやっていると思わなかった」ということの連続なんですよ。会社から「こういうのやってみない？」と提案してもらって、「面白そうだからやってみよう」と受ける。嫌だと言えばそのロールは任せられないし、やってみたいベースで色々なことに関わってこれた。だから自分はこういう人だって定義してしまうと、むしろもったいないかなと思うようになっています。
── カオナビはなぜ、そうした柔軟なロール提案ができるのでしょうか？
うちの異動って、トップダウンで「これをやってください」という話はあまりないんです。「こういう話があるんだけど、やってみたい？」と聞かれて、嫌だと言えば異動されないという文化がある。
会社は社員にとって選ばれる存在であるし、社員も会社にとって選ばれる存在である。相互選択の関係が前提にあるので、その人の興味や強みに合ったものを提案しやすいんだと思います。興味の連鎖がちゃんと伝わっていて、「それだったらこういうロールもあるかもね」とちゃんと定義してくれる。そういう環境ですね。
自分が何の人かわからない - ふんわりしたロール定義が生んだ迷走
── EMロールを最初に再定義しようと思ったきっかけは何でしたか？
元々ロールは色々あったんですが、だんだん形骸化してきていた部分もあった中で、私自身のキャリアとして、EMからテックリードに移り、またEMに戻るという経験をしているんです。
はじめにEMとして動いていたときはロール定義がふんわりしていて、組織の間に落ちるボールを拾う「便利屋」のような立ち位置になってました。
── 具体的にどんな業務が「便利屋」だったのでしょうか？
チーム間のコミュニケーションがうまくいっていなければ、その間に立って調整する。勉強会がうまく回っていなければ運用を引き受ける。新卒研修の設計もやる。どれも悪いことじゃないんですけど、都度スポットで対応していく感じで、戦略的な動きは全然ありませんでした。
しかも、見る人によって期待値がバラバラだったんです。Aさんから見たEMの期待値とBさんから見たEMの期待値が全然違う。どちらに従えばいいんだろうと悩むし、「自分で定義しなきゃいけないのかな」とも思うけど、それって組織から求められていることと合っているのかもわからない。そういう迷走があったので、もう一度EMに戻るなら、まず「EMって何する人だよ」を定義してから戻りたかったんです。
── EMの「あるべき像」はどうやって形作られたのですか？
最初のEM時代に本当に何もわからなくて、外部のコミュニティにたくさん出るようになりました。EMと名乗って仕事をしている人、それに準ずる仕事をしている人たちの悩みや取り組みを聞きまくりました。なので特定の1人をベンチマークしたというよりは、大量のインプットから自分の中に像が積み上がっていった感じです。「このやり方はうちに合いそうだ」「ここはちょっと違うな」と取捨選択しながら、自分たちの組織に必要なEM像を組み立てていきました。
やっていなかったら、自分の立ち位置すらわからなかった
── EMの再定義に続いて、プロジェクトリードやテックリードのロールも整備していったのですか？
はい。EMとして戻った最初の仕事として、この辺のロールも整えていこうという動きをしました。テックリードは元々いましたが、全チームには置けない状況だったり、プロジェクトリードとテックリードの違いがだんだんわからなくなっていたりしていました。なので、それらの役割も整備していきました。やり方としては、現場でやりながら、だんだん定義を変えて、動き方も変えてもらう。現場発信でまず動けるというのは、カオナビらしいところだと思います。
── もしその時にロール定義をやっていなかったら、どんな世界線が待っていたと思いますか？
やっていなかったら、「自分はどんな役割なのか」「組織から何を期待されているのか」がわかりにくいままだったと思います。主体的なスタンスが取りづらかった。
逆に、定義があることで周りからも「ああ、こういう感じの人なんだな」と理解してもらいやすくなる。人数が多い組織だと、お互いの役割を全部把握するのは難しい。そういう意味では、定義してよかったなと思います。
小さく直すほど、混乱が広がる - 全面再設計に踏み切った理由
── 今回、部分的な修正ではなく「全体で見直す」という判断をされました。その背景を教えてください。
実は、最初はもっと小さくやろうとしていたんです。名前を変えるだけ、くらいのことをやろうとしていた。
でも、これまで小さく改善してきた結果、逆に混乱を生んでしまうことがあったんです。自分はその先の未来が見えているからいいけど、見えていない人からすると途中経過だけ見せられても困る。「小さすぎてもダメなのかもしれない」と思うようになっていました。
もう1つは、今回やりたかったのが全体のロール間のコミュニケーション設計だったことです。EMとテックリードの連携はどうあるべきか、テックリードとその上位ロールとの関係はどうか。ロール間の違いや役割分担が曖昧なままだと、「結局このロールの人は何が違うの？」という疑問が減らない。そこを整理しようとすると、部分的な修正ではどうしても限界がある。
加えて、今回は本部長・部長ラインまで含めた上位ロールにも定義を広げたかった。これまではEMとエンジニアの間で完結していたロール体系を、経営層に近いレイヤーまで接続させる設計にしたので、少し大きめにやらざるを得なかったというのが正直なところです。
「これをやれ」じゃなくて「この世界線を目指してくれ」- アウトカムベースの設計思想
── 今回のロール設計で最も大事にした考え方は何ですか？
具体的に「やってほしいこと」を並べるのではなく、各ロールが「どんなアウトカムに責任を持つか」「どんな世界線を目指すか」を定義することです。たとえばテックリードなら、「メンバーの技術力が向上して、以前はテックリードが介入していた判断をメンバーが自律的に行えるようになっている状態」。EMなら「メンバー自身が成長を実感していて、チームから不本意な離職が発生していない状態」など。数値目標までは落とし込んでいませんが、そのくらいの抽象度で、そのロールに就いた人が「自分はどういう判断基準を持って動けばいいのか」がわかるように定義しています。
── なぜ具体的なタスクリストではなく、アウトカムベースにこだわったのでしょうか？
元々は具体的なアクションも定義していたんです。でも、具体だけだと「ここにこれをやるって書いてあるからこれをやりました」で終わってしまう。ロールとしてのスタンスが醸成されづらいし、こちらが意図した振る舞いが引き出せなかった。
たとえば組織的にこういうことが足りなかったからテックリードの定義を修正したのに、そのアクションが起こされなかった、ということがあった。それだと定義している意味がないんですよね。アウトカムベースにすることで、「このロールに就いている以上、こういう世界線に向かって自分で判断して動いてほしい」というメッセージがより伝わるようになったと思います。
あと、今回のロールは一定のシニアレベルに達したエンジニアが担うものとして設計しています。そういう人たちに対して具体のアクションを細かく指定するのも、正直ちょっと失礼かなと。判断基準さえ共有できていれば、あとはその人自身が考えて動けるはず。その信頼を前提にした設計にしたかったんです。
── アップデートのプロセスはどう進めましたか？
まず自分の方で叩きを作って、EMや各ステークホルダーに「これどう思う？」と持っていくところから始めました。各メンバーとそこからすり合わせして精度をあげていきました。
反応がない、は「高品質」のサインかもしれない - 変革のリアル
── ロール定義を変えた後、現場からはどんな反応がありましたか？
正直に言うと、すごいリアクションがあったわけではなくて…。その状態をどう捉えるか、自分もまだ見極めているところです。
今までは新しいロール定義を出すと「でもこれはどうなってるんですか？」と質問がたくさんきていた。今回はそれがあまりない。クオリティが高いから疑問が出ないのか、関心が低いのか。ちょっと見分けがつかない。
ただ、定義して終わりではなく運用はこれからです。実際に回してみて課題が出てくればまた改善する。そういう地道な繰り返しをしていきます。
── 正直に聞きたいのですが、まだやれていないことは？
たくさんあります。でも、「全部完璧にしてから出す」ではなく、まず出して運用して改善する。そのサイクル自体は崩さないつもりです。完成を待っていたらいつまでたっても出せないし、現場は待ってくれない。不完全だとわかった上で出す勇気みたいなものは、これまでの経験で身についた部分かもしれません。
「個人をないがしろにしない」組織づくりを、一緒に
── EMとして入社する方には、どんな素養があるといいですか？
メンバー個人に対して関心を持てる人がいいですね。カオナビはパーパスにも「個の力」を掲げている通り、個人への理解を大切にしている会社です。集まって話すと、思ったよりも個人の話が出てくるんですよ。
300人弱のプロダクトデベロップメント本部の中で、EMが集まると「この人はこういうタイプだよね」と全員わかるようになっている。これはカオナビの特色だと思います。
チーム編成を考える時も、「この人とこの人は相性がいい」「ここは組み合わせたらダメ」と、個人ベースの会話が普通に出てきます。小学校のクラス替えみたいな感覚に近いかもしれません（笑）
戦略的に組織を考えることと、一人ひとりの個性を積み上げて考えること。その両方ができる人が合っていると思います。「組織戦略」と言ったとき、人をパーツとしてしか見られない方だと、正直カオナビのEMには合わない。泥臭く個人と向き合える人にこそ来てほしいですね。
── EMとして入社した場合、最初はどんな動き方をするのでしょうか？
いきなりマネジメントだけをやるのではなく、まず現場に入って開発してもらうことが多いです。実際のチームに入って手を動かして、現場のメンバーと一緒に働く。その過程で組織の実態を肌で感じたり、個人に触れたり、信頼関係を築いていく。そこからキャリアを広げていくイメージです。
── 最後に、組織開発に興味のある方へメッセージをお願いします。
こういう仕事をやりたい人って、多分けっこう稀だと思うんです。実際、EMの人数もまだ組織の規模に対して全然足りていない。もっと多くのメンバーで、一人ひとりへの解像度を上げられるようなEM体制にしていきたい。
「組織設計って言うけど、個人がないがしろにされてるな」そういうモヤモヤを感じたことがある方がいたら、ぜひ一緒に働けると嬉しいです。
カオナビのエンジニア組織に興味がある方、ぜひ一度話しましょう。
