設計から逆算して採用する発想が大切
佐藤将高氏（以下、佐藤）：さっそく登壇者の紹介に入れればと思います。まずは今村さん、よろしくお願いいたします。
今村雅幸氏（以下、今村）：株式会社BuySell Technologiesの取締役CTOをやっています、今村と申します。ヤフー株式会社だったり、スタートアップだったり、株式会社ZOZOテクノロジーズだったり、いろいろなところでCTOをやってきました。よろしくお願いします。
佐藤：よろしくお願いします。では松本さん、お願いいたします。
松本勇気氏（以下、松本）：株式会社LayerX代表取締役CTOの松本です。今、CTO協会の理事や、「クラシル」を運営しているdely株式会社の社外取締役をやっています。本日はエンジニアリングマネジメントや、組織作りの話をさせてもらえたらなと思います。よろしくお願いします。
佐藤：よろしくお願いします。本日モデレーターを務めるファインディ株式会社取締役CTOの佐藤と申します。Twitterで「筋肉CTO」でやっていますので、よかったらぜひTwitter探してみてください。
本日のパネルディスカッションのアジェンダは、「組織作り・チーム作り」と「組織管理・評価」についてです。プラスアルファで、技術へのキャッチアップ方法をお話しできればなと思っています。
さっそく入っていきたいと思います。「組織作り・チーム作り」について、今3つのトピックが上がっています。読み上げていくと、開発組織立ち上げ、拡大期にやること、チームの作り方、組織マネジメントでやりがちなミスとその回避方法、マネジメント責務は機能ごとに分けるべきかどうか。
松本さん、何かこのあたりで、取り上げてみたいものはありますか。
松本：ちょうど今、うちも拡大中なので、この一番上は（開発組織の立ち上げ、拡大時に最初にやること、チームの作り方）話すものがいろいろあるかもしれないですね。
佐藤：ではこのあたりをお聞きしたいんですけども。今、組織規模、開発組織、エンジニア組織だと、どれくらいの人数がいらっしゃいますか。
松本：今LayerXは、エンジニアがだいたい20名前後ぐらいかな。ただ3つの事業にわかれているので、1事業あたりは6〜7人とか、もっと少ないチームもあります。これを3桁にまで拡大していくかぐらいのことも考えながら、真面目に準備を着々としている感じですね。
佐藤：なるほどですね。3桁に人を増やしていく、もしくは今20人くらいの段階である中で、拡大初期にどういうことをやったとか、どういうことを今チャレンジしているとかがあればちょっとおうかがいしたいんですが、何かありますか。
松本：拡大って言うのは簡単で、すごく雑なことを言えば、お金があれば採用できるんですよ。エージェントさんとか、いろいろなところのお金をゴニョゴニョするだけでも紹介は増えるので。ただ、その中で予算があって採用していくので、そこはいったん置いといて。
一番大事なのは、拡大した先の組織ってどうなってるんだっけ？ に対するビジョンだと思っています。今のかたちで拡大しようと思っても難しかったりするわけですよね。人が増えるってことは、コミュニケーションの数がそれだけ増えるってことですよね。
例えば1チームで6〜7人ぐらいで考えた時に、階層も考えてだいたい100人いると、多いと中に10チームとかいるわけですよ。中でうまく連携していかなきゃいけません。これを分けずに「1チームで30人でやります」という手もあるんですが、それを続けていくとスケーラビリティがなくなってきます。
その組織をどう構成して、その組織の間でどういうコミュニケーションがあるべきみたいな設計が先にあって、それから逆算して採用していくという発想をもたないと、人が増えてきても組織はスケールしない状態に陥るなと思います。
いろいろなところでコミュニケーションの交通事故が起きて、言ってることがぶつかったり、意思決定としてふわふわと「こっちの時はAって言ったのに、ここではAじゃなくてBって言い始めたぞ」みたいなことが起きたり。チームが混乱して、人数増えたとしてもその分のパフォーマンスが出なくなるということが起きます。
なので、一番大事にしたいのは、例えば18ヶ月後の我々はその時どういう組織になっていて、そこからどういう拡大を目指していて、事業フェーズはどうなっていて、その時にマネジメントはどう置かれていて、今はどういう状態で、その間を埋める順序ってどうなるんだっけみたいなところを、先に考えて動き始めるのがまずあるべきなのかなって思っています。
これはソフトウェア作りと一緒だと思っていて、将来どういうふうに拡大していくかをある程度にらみながら設計していくのと、組織も同じなのかなと思っています。
採用周りの仕組み化が意外とできていない会社は多い
佐藤：なるほどですね。過去に、どういうふうにあるべきかを考えずに失敗したことはあったんですか。例えば「こういうふうに人を増やしたけど、あれ？ なんかうまくいかないな」みたいな、場当たり的というか、そういう経験はありますか。
松本：一番は、やっぱり自分が最初に大きな組織のCTOをやって苦しんだ場所ですね。株式会社Gunosyが上場したあと、組織がけっこう混乱してしまった時期がありました。その時は、1チーム30人を僕が見る状態になっていて、当然スケールしないし、その時はマネジメントのスキルもそんなに高いわけでもないので、いろいろな人に混乱を与えたり、負荷の高い人がすごく出てきたりして、そういった人たちをきちんとケアできなくて苦しんだことがありました。
そのあとに、ミドルマネージャーをお願いしつつ、組織作りをしていって、それが1年とちょっとかかってやっと平定できました。
佐藤：うんうん。
松本：けっこうエネルギーと時間がかかるミスをその時にやらかしました。
佐藤：うーん、なるほど。その時の経験から、こうあるべきっていう理想を、遠い将来じゃなかったとしても作ったうえで、それに向かってこうしていこうねと考えていくのが大事だと思われたんですね。ありがとうございます。
松本：そうです。
佐藤：今村さん、チーム作りは拡大初期において何回もご経験があると思うんですが、いかがですか。
今村：そうですね。スタートアップもZOZOも、BuySellも、それぞれぜんぜん規模感が違うんですが、大事なことはだいたい一緒かなと思っています。さっき、松本さんも言っていましたが、やっぱり逆算がすべてだなって思っています。
向こう3ヶ月後、半年後じゃなくて、2〜3年後に、自分たちと自分たちのプロダクトってどうなっているんだっけ？ っていうのを定義して、プロダクトのロードマップをある程度考えます。そこから組織を作っていくというか、一般的に言われるような逆算して作っていくというのがなんだかんだで一番うまくいっていたかなと思っています。
今のBuySellには、40人ぐらいのエンジニアがいるんですが、ちょうど僕が2021年4月に入って、既存のエンジニアもいて、プロダクトもあるっていう状態で、これをどうやって拡大させていこうかと考えた時に、プロダクトの中長期の未来ですね。
ビジョンを定義して、そこに向かうために現状の組織はどうなってるんだっけ、どういう役割が足りないんだっけとしっかり洗い出して「じゃあこの穴を埋めましょう」「ギャップを埋めていきましょう」と採用計画や、求人の整理をしていくのが一番やりやすいのかなと思っています。
とりあえずなんか優秀そうな人を採用してなんとかなるっていうのが、あまりうまくいかなかったのは、自分自身の経験でもありますし、入った人も不幸になってしまうので、やっぱりこの会社、この事業、プロダクトでどういう活躍をしてもらうんだっけみたいなところをきちんと定義して、きちんとターゲット決めて採用することが重要なのかなと思っています。
意外と、採用周りの仕組み化がぜんぜんできていない会社がけっこう多いかなと思うので、その採用周りの仕組み化ですね。
人事との連携もそうですし、募集要項を整理して、どの媒体に出すのか、採用フロー自体や面接をどうするのか、リファラル採用はどうするかとか、採用に関するありとあらゆることをきちんと仕組み化して、運用できるようにしていくのも、同時並行でやらないといけないかなあと思います。
問題は、お金があれば採用できるけど、採用したら既存の組織とのバランスが崩れるとか、なんかいろいろとあるんですが、そこを評価制度やグレードを全部同時に見直して、そういう人たちをきちんと採用できる下準備というか、そのあたりのグレードは簡単に変えられないので、こうあるべきだろう、っていうのを想定して考えておくのがすごく重要かなとは思っていますね。なので、けっこういろいろなことを同時並行でやっていかないといけないかなと思います。
佐藤：お二方のお話聞いて、やっぱり現状のオペレーションを淡々と回していくことがすごく大変だと痛感される方はたくさんいるのかなと思います。
やっぱりエンジニア組織を作っていく中で「将来がこうだよね」っていうところから逆算して作っていかないことには、うまくいくケースは多くはない。失敗することのほうが多くて、逆にそれが学びとなって、次の「こういうふうにありたいよね」「じゃあそれに対してやりましょう」っていうところになったりする。
そのうえで「じゃあ採用はこうしてこうね」って今、今村さんからお話があったようなところとか、具体的にどうしていくという、マクロとミクロの両方をやっていかないといけないっていう、非常に難しいことにチャレンジされてるんだなとお話を聞いていて思いました。
まずは「マネジメントはなんぞや」を丁寧に説明する
組織が拡大する中で、次のマネージャーやミドルマネージャーの育成のお話がありましたが、「この育成の方法や仕組みなどはどうされているでしょうか」というご質問をいただいてるんですが、こちらはいかがですか。
松本：マネージャーを育てるっていう時に、マネジメントをやった経験がある人とそうじゃない人の間で「マネジメントってなんぞや」にすごくギャップがあると思ってるんですよ。マネジメントってやってみると、プロダクト作りとすごく密接じゃないかということに気づき始めるし、技術も必要やじゃないかと思うんですが、コーディング中心にやってきたメンバーに「マネジメントに上がってよ」って言う時に、「マネジメントって何をやるんだっけ？ 管理職だっけ？」みたいになってしまって、うまく育たないケースが多いなと思っているので、第一歩は丁寧に「マネジメントって何をやるの？」みたいな話を必ず伝えるようにしています。
例えば前職では、新卒研修でもそのマネジメント研修やっていたんですよね。そういうことやることで「マネージャーとはなんぞや？」っていうのを、ある程度像をつかんでもらいます。みんなのいいものを作りたいっていう思いに対して、地続きにあって、そこでやることはこういうことで、開発しないっていうことではないんだよみたいな話をきちんと伝えてあげて、キャリアパスの中にちゃんと組み込めるように認識をまずもってもらいます。
そこからテクニック的な1on1をこうやってきちんとやろうとか、評価制度はこういうものだよとか伝えていったり、一緒に1on1に入ったりしてもらいながら、面倒を見てもらって、最終的にマネージャーのラベルを付けさせてもらうみたいな感じをよくやっています。
佐藤：そうですよね、マネジメントって体系化されていて、「この本を見れば全部が書いてあるよ」っていうのはそんなに多くはなくて、やっぱりやってみて自分の肌感で知ることが多いのかなって思うので、確かにそういった研修をされているのはとても素敵だなと思いました。ありがとうございます。
もう1つ、今村さんにぜひお聞きしたいんですが。刻々とそのプロダクトの目指す姿やゴールなどが状況に応じて変わる中で「こういう人が欲しいよね」に対してギャップが出てきたりするケースもあるかなと思うんですが、逆算で衝突したことってありますか。それに対して何かアプローチしているとかがあれば教えていただきたいんですが、いかがでしょうか。
今村：そうですね。基本的に四半期ごとに全部を見直しているので、求人票もかなり変えます。
例えば、やってたプロダクトが止まっちゃって、そこで採用した人たちの行き場がないみたいなことって往々にしてあるんですが、ZOZOの場合はけっこうな人数がいたので、かなりヒアリングして、他のチームへの異動をやっていました。もう衝突するのが当たり前というか、それぐらいの前提でした。採用する時に、極力その事業がなくなるかもしれないような専門性の人はあんまり採用しないみたいな感じにはしていますね。
仮にプロジェクトなくなったとしても、他のチームで「きっとこの人は活躍できるだろう」みたいなところで採用するしかないかなと、個人的には思っています。
佐藤：ありがとうございます。採用がすごく大事というところがメッセージとして伝わってきました（笑）。
松本：急に方向性が変わって、衝突するのを避けるのが僕はけっこう大事かなと思っています。プロダクトに対しても、方向性が変わるにしても、いきなり明日「いや、もうこっちなんだよ」って言われるより「こういうことも模索しなきゃいけないよね」っていうのを常に議論されている中で、だんだん「やっぱりこっちじゃなきゃだめだよね」って認識して、大きく舵取りしないと、なかなか衝突は避けられないのかなと思いますね。
佐藤：確かにそうですね。黄色信号の段階で、言ってもらったほうがやっぱり受ける側としても気持ちは覚悟できるというか、「そっか、こっちをやるか」とできそうな気はしますね。ありがとうございます。
その人の成長を測る行動評価を大事にしている
次のテーマにいければと思っています。組織管理・評価というところで、こちらも質問が多かったんですが、「リモートワークでのマネジメントの課題とその対応。人事評価する際にどういうところに着目していますか。専門外のスキルの評価について、どうしていますか。エンジニアの目標管理の方法があれば教えてください」というところで、質問をいただいています。今村さん、トピックとして中心に話したいところはありますか。
今村：そうですね。みなさん気になるトピックだらけだと思うんですけど。
佐藤：（笑）。全部話したい、話してもらいたいっていう雰囲気はなんかありますね（笑）。
今村：永遠の課題だろうなと思うのは、人事評価の際に着目する点ですかね。
佐藤：ありがとうございます。じゃあ、人事評価の際に着目する点っていうお話なんですが、スキルって人によっては「こうだ」とわかりやすい方もいると思うんですが、例えば「新しい機能を作って、こういうふうにたくさん貢献してるよ」っていう方もいるし、「運用保守で、安全にエラーが起きない」っていう状態を評価しなきゃいけないんだけれども「エラーは起きなくて当然」みたいなエンジニアの方もいる中で、どういうふうにバランシングするかとか、もしくはこういうところをきちんと見ていますとか、あればおうかがいしたいんですが、何か今村さんはありますか。
今村：そうですね。基本的に評価制度をどうするかっていうことだと思うんですが、まず大前提として、評価制度を用意するんだったら、個人的には、成果評価と行動評価がいいんじゃないかな思っています。いわゆるOKRみたいなものと、行動評価ですね。その会社のバリューに沿った行動がどれぐらいできているかみたいなものが大前提で、その両面で判断するのが個人的にはいいのかなと思っています。
特にOKRみたいなものは、恐らく各社でそこまで大きな違いはもうないのかなと思ってはいるんですが、大事なのは行動評価みたいなところです。その評価は、単純に給与を決めるというよりは、その会社のビジョンやミッションやバリューに沿った行動がどれだけできるようになったかみたいなところで、その人の成長を測るものかなあと思っています。
だいたいの会社にバリューはあるじゃないですか。バリューをエンジニア観点で見た時に、どういう行動をやるべきかを定義して、グレードが上に行くほど難易度が高くなる感じの評価制度を作ってやると、いいのかなと思っています。
例えば、前職だとChange・Commit・Collaborateみたいなバリューがあるんですが、Changeだと、エンジニア観点では、自分自身が変化、つまり成長できたかみたいなところだったり、どういうふうに技術的な挑戦をしてきたかみたいなものだったり、そういう観点で全部グレードごとに定義して、きちんと自分の役割に見合う活動ができたかどうかで評価していきます。
次のグレードに行くにはどういう行動が足りていないんだっけみたいなところを、ある程度確認しながら成長していけるところが、すごくハマってやりやすかったかなと思っています。実際、3年前と3年後を比べて、そのエンジニアの中での行動評価のレベル感が平均で全部上がってるみたいにすると、定量化できるようになるので、そういう観点で、バリューと紐付けて、バリューをエンジニア的に解釈できるようにして、それをしっかり評価していくのはすごくうまく機能してたかなと思っています。
佐藤：ありがとうございます。グレードを定義して構成に当てはめていくっていうところで、ワクワクしたっていうお話があったかなと思うのですが、5人10人ぐらいの規模でもグレードを定義していたんですか。
それとも前職のZOZOさんだと、けっこうな人数がいるのかなとは思うんですが、どれくらいの人数規模でそういう定義をした時に「あ、ちょうどよかったな」とか、もしくは「もうちょっと早めに作っとけばよかったな」とかありますか。
今村：スタートアップの時から作っていましたね。ただ、スタートアップの時と大企業の時では、多少グレードの数が違います。スタートアップの時は5個とかでしたけど、ZOZOだとそれが9個になったりとか。やっぱり組織が拡大すると役割も増えてくるので、それによって、より細かくなっているってところが違ったぐらいで、始めからあったほうがよかったなと思っていますね。
それは今さっき言ったみたいに、単純に給与を決めるってものじゃなくて、行動指針の軸で、別に規模関係なくあったほうがよかったなと思っています。
佐藤：ありがとうございます。これは弊社の組織もどうしようかなっていうところでした。
（次回へつづく）
