カルチャーを維持し続けることの重要性
広木大地氏（以下、広木）：次のテーマは、今日のメインになるのかなと思います。どのようにしてメンバーの成長や自立を促す仕組み作りをしてきたのかについて、何か知見があればうかがいたいのですが、名村さんいかがでしょうか。
名村卓氏（以下、名村）：そうですね。けっこう長い間このことばかり考えてやってきたので、話し出すとたぶんキリがないんですけど。シニアをたくさん採用して、かつジュニアも採用してとなると、やはりどうしても空気が変わります。
最初の50〜100人ぐらいでやっていた時は、やはり似たような価値観とお互いを認め合っているような価値観でやっていたので、明文化しなくても、なんとなくそういう雰囲気や空気みたいなものがありました。
そこから倍にしていくといろいろな人が入ってくるので、だんだん空気が変わってきます。そういう時に一番大事だと感じたのは、やはりカルチャーをきちんと維持し続けることと、明文化したりしてみんなに伝え続けることです。
「この会社では何を大事にしています」「こういうことをしてほしい」ということをきちんと伝え続けるのは、すごく大事だなとは思っていました。
あと、育成のカルチャーに関してはなかなかまだ作りきれていない。やはりまだシニア比率も高くて、入ってきたジュニアを受け入れる許容はなかなか組織でも作りきれていないです。
しかし、自立を促すという意味では、組織がけっこう大きくなって、メルカリという1つのプロダクトを大人数で作っていくとなると、やはり担当する領域がどうしてもだんだん狭まっていくので、ここに抗っていく必要があります。
例えば、プロダクトを作って何か1つの機能を出すことに対して影響がすごく大きいので、計画もきちんと立てるし、プロダクトマネージャーやエンジニアの役割分担もきちんとする。
そういう中でものを出していくので、狭い領域の中の仕事をしていると、全体として1つの機能を作るために何が必要なのか、もしくは何か新しいサービスを作る時に何が必要なのかという観点の能力が、どうしてもどんどん衰えていく気がしました。
だから、メルカリの時にやったのは、例えばHACK WEEKをつくってエンジニアが自分で考えた機能を自分で作ることに時間を使って、かつ、ふだん関わらないチームで一生懸命関わって、ふだん触れない技術に触れてみたりして、実際に何か新しい機能や仕組みを1から作ってみることを促してみたりはしていました。
他にも評価の仕組みを変えたり、組織を変えたり、アプローチしたことはたくさんあります。エンジニアが積極的に自分で考えて決めるトライをいろいろできるような枠組みを一生懸命作ってきたようなのもあります。
大きい組織になってくると、だんだん自分で決めなくても誰かが決めてくれるし、自分が決める範囲もそもそも狭くなってくる。そうなると、やはり自立心や成長がどんどん阻まれていきます。できるだけ何か自分で決めて作ってみるとか、動いてみる機会を増やすことを、いろいろとトライしていた気がします。
バリューで会社のカルチャーを伝える
広木：ありがとうございます。今たくさん話してもらって、いろいろ気になることが出てきたので一つひとつ聞かせてもらえればと思います。
1つ目は、「文化を繰り返し伝えるようにして、こういうカルチャーなんだと伝えていったんです」と言われると、「そうなんだ」と思うものの、「それはけっこう難しくない？」 と思ってしまいました。
入って来た人にカルチャーを繰り返し伝えるための仕組みじゃないですけど、工夫として「どうやってカルチャーを伝えるの？」と疑問に思うことが多いのではないかなと思います。
メルカリさん、ソウゾウさんの中ではもしかしたら当たり前なのかもしれませんが、「こういうふうにカルチャーを伝えているよ」みたいな仕掛けみたいなものが聞けるとうれしいなと思いました。
名村：メルカリは「Go Bold」と「Be a Pro」と「All for One」というバリューがあります。けっこういろいろなところで話しているのでそれなりにみんなも把握しているし、よく社内のワードにも出てくるので、そういう意味では価値観はみんなの中でけっこう共通してあります。
エンジニアの中の課題であったのは、バリューの適用範囲がすごく広くて。そのバリューに対するエンジニアリング的な解釈が必要でした。「エンジニア的にGo Boldはどういうことなんだ」「Go Boldといったからと、なんでもやってとにかくぶっ壊しまくればいいという話じゃない」とか、そういうのはありました。
「最初に我々のバリューをエンジニア的に解釈するとこういうことなんだ」と具体的なことを記述しながら作りました。それは実際にEngineering Principlesでちょっと公開しています。そういう作成のプロセスを、けっこう人が増えてきた後にボトムアップでみんなを巻き込みながら作っていくことはやりました。
とはいえそれがすごく浸透したかといわれれると、一応評価の軸には使っているので浸透はしたと思いますが、みんながふだん口にしてるというほど浸透はしなかったので、ちょっと難しかったなぁと感じてはいます。
バリューの汎用性の高さも浸透を後押しした
広木：僕はメルカリさんとこうやってイベントをするくらいの仲ですが、ちょくちょくGo BoldやAll for One、Be a Proの話は出てきます。この3つだったら空でも言える感じにはなっています。なので、繰り返し発信するのをやり切ったところが重要なポイントだったのでしょうか。
名村：そうですね。バリュー的な観点でいうと、わりとどういう行動であっても“いい行動”であればある程度当てはまる許容の広さみたいなものがあって、それがいろいろなSlackのスタンプなどにちょこちょこ出てきます。そういう意味でいうと、バリューがふだんの日常的な会話の中に出てくるのは、やはりすごく大事だとは思っています。
結局、Principlesはエンジニアの日常の会話になかなか出てこなかったので、単語が難しかったのもあると思うのですが、そこはすごく苦戦した感じがします。
広木：文化を日常会話に盛り込む工夫をうまく繰り返しやっていく中で、エンジニアの人はけっこうこういうバリュー系のことは照れてしまいそうな気がします。僕もけっこう照れちゃうと思います。
でもメルカリの方と交流していると、自然に使うなと思っています。なのでバリューを言葉にするチャンスが多いとか、それを推奨しているとか。その姿を見せるのがうまかったのかなと外から見ていると思うのですが、それは自然とそうなった感じですか。
名村：Go Bold、Be a Pro、All for Oneといったバリューがだいたいどういう行動に対しても適用できるので、そうした汎用性の高さもあったとは思いますね。
全体を広く見ることのできるエンジニアと、専門的知識を持つエンジニア
広木：ありがとうございます。もう1点、名村さんの話を聞いていて、エンジニアが自分の領域を飛び越えてハックできるようになったこととして、HACK WEEKを設けてやりましたと言われた時に、ハッと思ったことがあります。
名村さんたちがマイクロサービス化を随分進めていた中で、一つひとつの認知コストを下げて、いろいろな領域についてそれほど把握しないでも、そのプロダクトのマイクロサービスのドメイン知識さえしっかり持っていれば取り組める状況になることは、ぜんぜんあると思います。
一方で、全体から把握するのはちょっと難しくなると思っています。アーキテクチャの話と、より広い範囲が見られるエンジニアとしてバリューを出しやすくする話の交差点で、何か発見したことや思うことがあれば教えてください。
名村：そうですね。やはり組織が大きくなったりサービスが大きくなると、常にドメイン知識との戦いになってくるので、やはり専門的な知識や、ある領域に特化した知識は絶対に出てきます。
その領域をできるだけマイクロサービスにすることによって、全体がインターフェースになるので、何かをしたいと思った時にそれができるマイクロサービスがあれば、それをそのままコールすれば使えます。
そういったチームのインタラクションでいうところのエンジニアが一緒になって同じコードを開発するというよりは、お互いの領域をきちんとサービス to サービスでコールできるようにしていく。デカップリングしてくるというか、分離していくのはけっこう大事だなとは思っています。
ドメイン知識がたくさん出てくると、やはり全体を把握するのはもはや不可能になってきます。そんな中で、エンジニアが1人とはいわずとも、例えばアジャイルでいうスクラムを回すぐらいのチームが、1つの機能を達成するためにどれぐらいのインタラクションを作らなければいけないのか。ドメイン知識が増えれば増えるほど、インタラクションの数が増えていくので。質問の意図からちょっとずれてしまいますが。
広木：そのインタラクションにかかるコストを下げる仕組みみたいなのをまた作る。例えばインターフェースが検索しやすくなるとか、それぞれのやっていることの共有会が開かれるとか。そういうふうに、インタラクションが多少発生しても、目的達成する時のコストが下がるような工夫をしている感じですか。
名村：それを目指しているという感じです。前もそこまではうまく分割できなかったのですが、「何か機能を作るべきだ」と思っているチームが、すでにあるサービスや開発した成果物を使ってうまく組み合わせてものを作れるのが、本来は理想だとは思います。
コンポーネントや何か足りないドメインの機能があれば、それを新しく開発してほしいと依頼していくような。そういうインタラクションのあり方があるといいなとは思ってやってはいます。でもまだそういう領域には到達していません。
広木：目指している感じになる？
名村：そうですね。
活躍するロールモデルを作ることも大切
広木：ありがとうございます。では芹澤さんにもうかがいたいなと思います。メンバーの成長や自立を促す仕組みで、先ほど文化とアーキテクチャの交差点みたいな話もしてもらいましたが、それも含めてSmartHRさんの現在位置を教えていただければと思います。
芹澤雅人氏（以下、芹澤）：そうですね。今、大変興味深く名村さんの話を聞かせてもらっていて、けっこう似てるなと思いました。先ほど話したとおり、私たちも新卒の育成は未経験ですが、もちろん中途で入ったシニアの方にも成長は求めていて、そこはきちんとマネジメントをしています。
やはり重要なものとして、まずはカルチャーやバリューの浸透はおっしゃるとおりだと思います。企業においてコア人材を定義するのはやはり非常に重要だと思っています。
日本に多くのいろいろな会社がある中で、「弊社で活躍する人はこういう人ですよ」というモデルを作ってあげるのは、やはり一人ひとりにとっての成長の軸になると強く思っています。
僕も会社がまだ3人ぐらいだった時は、そもそも活躍するロールモデルがなかったので、それをとにかく模索しました。「こういう人がうちの会社で活躍しそうだぞ」というのを探索するフェーズもあったのですが、最近は固まりつつあるというか、「だいたいこういうタイプの人が今のフェーズだと活躍できる」というのがわかってきているので、それをきちんと明文化します。
それを明文化する方法は、先ほどお話したとおり、コンピテンシー評価に組み込まれているバリューへの共感の行動パターンみたいなところです。そういったエンジニア向けの行動パターンみたいな文言を、半年に1回ぐらいアップデートして整備して反映させたりします。
あとは私たちには等級というグレードがあるのですが、「3等級はこういう人ですよ」「4等級はこうですよ」という要件も1年に1回ぐらい見直しています。そこにきちんと反映させていくことはやっています。
それが私たちの組織におけるコア人材の定義にもなるし、そこを目指していけば成長できる指針にもなっています。そのため、こういうのを整備してきちんと伝えていくことは、かなり大切なのではないかと思っています。
ロールモデルは1on1を繰り返して模索する
広木：ハイパフォーマーな人の特性としてコンピテンシー、言語化するところまでは人事制度のプロセスとしては作りやすいかなと思いますが、その後の「こういう人がロールモデルなんだよ」と伝えていくのは、メチャクチャ難しくなっていくところだと思います。
そのグレードに求めることとか、「ハイパフォーマーのコンピテンシーに求めるものはこういうことなんだよ」というものを伝えられた仕掛けはありましたか？
芹澤：けっこう難しいですね。このあたりは本当にケース・バイ・ケースというか、やはり人それぞれ個性があって。本当にマネジメントの真髄というか、おもしろいところだと思います。
その人と1on1を繰り返すことによって、私たちの作ったコア人材の定義をベースにした時にどうやったらそこに導けるのかを、画一的ではなく、一人ひとりきちんと向き合って模索していくのは、僕もすごくやっていましたが、おもしろいところだと思います。
すごく申し訳ないのですが、回答としては人それぞれきちんと話すことなのではないかと思います。
広木：これは先ほどの名村さんの話ともすごく通ずる話です。こういった伝える活動は、泥臭い部分がどうしてもあるから結局一つひとつやっていくしかないし、それがきちんと徹底できることが強さにつながる気もします。徹底して伝えてくれるようにするのも、人の自立をうまく誘導していかないと、なかなか自分だけで言い続けても伝わらないところがあると思います。
今はそういう発信したいことや、繰り返しコミュニケーションを取ってくれるミドル層や周りの人は育ってきているというか、いっぱいいる感じなんですか。
芹澤：そうですね。いわゆるEM（エンジニアリングマネージャー）みたいな人たちをいかに育てて配置していくかはかなり重要だと思っています。
僕たちはそこにかなり力を割いていると思います。エンジニアをしている人でマネージャーをやりたい人はやはりかなり少ないのですが、いろいろな工夫をして、きちんとそういったところを目指したくなるような環境を作ったり、マネージャーになった後も、マネージャー自体の育成支援もきちんとやっています。
「1on1はこういうふうにやったほうがいいです。やりましょう」とか、「目標設定はこういうふうにやるといいですよ」とか、コーチングの基礎を教えたりしています。あと、マネジメントするうえでの悩みみたいなことを日々共有し合ったりする体制作りは、かなり気を遣っています。
なので一番スケーラブルなのは、そういったエンジニアマネージャー一人ひとりをきちんとマネージャーとして一人前の状態にしていくところなのかなとは思います。
広木：ありがとうございます。そこもすごく興味があるところだと思います。
（次回につづく）
