「ハサミの使い方がわかっても作り方がわからないとダメ」　及川卓也氏×葛岡宏祐氏が、採用側も基礎的な部分を学ばないといけないと思う理由

成長し続けるエンジニアリング組織を作るための施策

司会者：では続いて、その話を受けながら聞きたいのが3つ目ではないでしょうか。3つ目はこちらです。「明日からできる、成長し続けるエンジニアリング組織を作るための施策」ということで、これは「明日からできる」というところがポイントだと思います。及川さんはいかがですか？

及川卓也氏（以下、及川）：さっきの話とけっこう重なるところがあって、先ほど強いエンジニアリング組織はどうあるべきかは、現状をいったん無視してあるべき論を述べた感じになっているかと思いますが。でもすでにその組織があって、みなさんその組織課題にいろいろ取り組んでいる中でも、あるべき論を1回やってみたらいいと思うんです。

本当は、自分たちの組織はどうあるべきかということを考えて、さっき言った組織デザインであったり、構成メンバーはどういう人であるべきかであったり、その人のジョブディスクリプションは何であったりするのかを考えてみたらいいと思います。

ジョブ型雇用のジョブディスクリプションとは何かというと、組織がこんな人間になってほしいということを職種ごとに決めているわけです。なので、それと現状の自分との差分を見て、その差分を埋めるように努力するわけですし、組織は本人がその差分を埋めるために努力できるように、育成というかたちでサポートするわけですね。なので既存の組織であったとしても、同じことを同じようにまずはやってみるのがいいんじゃないかなと思います。

司会者：それを受けて、葛岡さんはいかがですか？

葛岡宏祐氏（以下、葛岡）：そうですね。私もそのあるべき論ではないですが、まずは自社でものすごく強いエンジニアリング組織を作りたいというのであれば、やはり参考にすべき会社などはあると思うので、そういったところが実際にやっている良いところを真似しながらやるのがいいかと。

ただし、必ずしもそれが自社に合うとは限らないと思います。例えばですが、Googleだとけっこうコーディングテストみたいなものをメチャクチャやったりしていると思うんです。僕も実際に受けたことがあるんですが、丸1日現地に行くみたいなことは、他の会社は真似できないじゃないですか。なのでそこらへんの理想像が何で、自分たちが今どこで、じゃあこのギャップを埋めるためには何をすればいいのかみたいなところを考える必要があります。

例えばコーディングテストをちょっと短くみるとかであったり、そういったところから始めてみてトライ＆エラーをするのがいいのかなと思っています。

司会者：成長をし続けるというのは、確かにそういったスモールスタートでやっていくというのが肝心なんですかね。

葛岡：そうですね。

Googleのマネをする必要はない

及川：今の葛岡さんの話を聞いて、やはり自分の経験をすごく思い出したんですね。私がGoogleを辞めて最初はフリーランスで、そのあと先ほど紹介したように自分の会社を持っているんですが。特に辞めた直後というのは「Googleのやり方を教えてください」と言われるんですね。実はGoogleのやり方は、かなり公開されているんですよ。

『How Google Works』という本があったり、あとは『WORK RULES！』であったり、いろいろなところで発信しているんですね。なので「それを見ればいいじゃん」とかと思ったんですが、とはいえ書かれているのと同じであっても、自分の言葉で説明しても、できないんですよ。

できる必要もないのかもしれないですね。今言ったみたいに、GoogleはIPOの時に「自分たちは普通の会社になるつもりはないし、これからもなるつもりはない」と言っている会社なんですね。

なので、そんな会社を真似する必要もないかもしれない。だからGoogleがやっていること、これは開発プロセスとかのフレームワークも一緒なんですが、そのフレームワークをそのまま真似するんじゃなくて、その裏側の本質は何かというのを見て、自分たちならばそれをどうやって実現するかというのを考えていくのがいいと思うんですよ。

葛岡さんが言われたみたいに、私はGoogle本社のマウンテンビューに「飛行機代とホテル代を出すから来い！」と言われて、1日缶詰で全部インタビューを受けたわけですが、そんなことができるわけがないんですよね。でも、じゃあそこでGoogleがやっていることの中身は何で、自分たちの今のコンディションならばどうすればいいかを考えるのが、とても大事だと思いますね。

スペシャリストとしてのスキルの深掘りが甘い

葛岡：今はちょっと採用にフォーカスして、このあとたぶん育成とかにも話が移るかなと思うのですが、やはりその採用のところが非常に大事だと思うんです。今のその本質の部分を捉えて、真似をすればいいみたいなところがあったと思いますが、コーディングテストの本質は、私の理解だと、Googleだとやはりソフトウェアエンジニアとして基礎的なところを理解しているかや、地頭などそういったところを見るというところかなと。そこはまず合っていますか？

及川：合っています。

葛岡：ではそれをGoogleはマウンテンビューに招きましたけど、まぁどこの会社も候補者を招けるわけではないので、それを自社でやろうとした時に、もう少し軽めのテストをやる。本質はそこを見るというところなんだけど、Googleとは同じやり方ができない、じゃあどうすればいいのか、みたいなところのギャップを埋めていくことは、明日からできるんじゃないのかなとは思ったりしましたね。

及川：そうですね。先ほどジョブディスクリプションみたいな話をして、葛岡さんはスキル採用と言ったんですよね？

葛岡：はい。

及川：やはりジョブディスクリプションの中に、スキルがあるわけです。でも今の日本の企業がジョブ型雇用をトライし始めていて、全部が全部知っているわけではないんですが。相談を受けたり見たりした中で、やはりスペシャリストとしてのスキルのところの深掘りが甘いな、と感じることがあるんです。

今のソフトウェアエンジニアでいうと、ソフトウェアエンジニアなんですが、やはりどこかにジェネラリスト的なところがあって。要はソフトスキル以外にコミュニケーション力だったり、そういった要素が多すぎるんですよ。じゃあ「技術者としてのスキルは？」と言われた時に、それを自社で定義できないという問題もあるし、定義したとしても評価・判定ができないんですね。

そこはだから、例えば「うちもGoogleみたいに優秀なエンジニアをたくさん雇いたいです」と言っても、誰が採用するんですか、採用面談は誰がするんですか、そこで判定を下せますか、という話を考えないといけない。今までは、そういう時に「じゃあ外部の人にアドバイザーで入ってもらって、採用面のお手伝いをしてもらおうか」というのがあったわけです。

そういったところで、コーディングテストみたいなのが米国でもあるわけですが、そういったプラットフォームで、まずは必要最低限のスキルを持っているかどうかは、あえてある意味ちょっとわかりやすく言っちゃうと、機械的に判定できるようにしようと。そういうところが、特にスクリーニングという段階では機能するとは思いますね。

スクリーニングで一番楽なのは「学歴フィルター」

葛岡：その機械的なところでもう1個あるのが、やはりGoogleの採用フローや私も前職のメルカリを非常に参考にしていたりしたんですけど、バイアスを圧倒的に排除するところを、かなり徹底しているところじゃないですか。やはりそういったところで、ある程度機械的に定量的にやることで、バックグラウンドはある意味考慮しないことができると思います。

なので私も、現状はソフトウェアエンジニアの採用なのに、ビジネス職と同じような採用方法をしている企業さんは、実は採用方法がわからないことが多かったりするんですよ。そういったところで、やはりGoogleまで一気にジャンプしなくても、明日からできるところとして、ちょっとそのコーディングテストなどを採り入れるのは非常に有効なんじゃないのかなと思っていますね。

及川：そうですね。日米問わずというか、おそらくグローバルにおいてスクリーニングで一番楽なのは何かというと、学歴フィルターなんですよ。でも日本企業はこれを見直しているかたちになって、それはとても良いことだと思うんですね。ただあえていうと、学歴フィルターって、大量にレジュメが送られてくる会社にとっては、実はとてもスマートなやり方なんですよ。

やはり学歴だけじゃないことはもちろん、学歴フィルターで落としちゃっている人たちの中に山ほど優秀な人たちがいることもわかっているんだけれども、大量にレジュメが送られてきたら、学歴でフィルタリングをかけたところから探すほうが、絶対に楽だったりするんですね。これはある種の今葛岡さんが言われていた、やはりバイアスなんですよ。事実にある程度基づいちゃっているかもしれないバイアスなんですが。

だから学歴フィルターに変わるフィルタリングがあれば良く、それが別に出た学校などではなく、高卒だろうが中卒だろうが、何だろうが、人種も何も関係なく優秀なら本当は良いわけです。そういうのに機械的な部分は非常に機能するわけですよね。なので、スクリーニングにおけるコーディングテストというのは、非常に有効な手だとは思います。

葛岡：そうですね。そういった定量的な、ある意味その方のバックグラウンドを考慮しないけっこう冷酷なところと、あとは人間味のある定性的な評価みたいなもののダブルで、ミスマッチみたいなところは減っていくと、我々もそう感じていますね。

コーディングテストが有効なもうひとつのこと

及川：ちょっと1個だけ。このコーディングのところで、今のスクリーニング的なところでのスキルチェックというある種機械的なところがあり、これはGoogleでも行われている一方、もうひとつコーディングテストが有効なのは、入社したあとのシミュレーションなんですよ。

これは職種に関係ないんですが、エンジニアの場合だと非常によくわかるんですね。今のハイヤールーさんがやられているのは、オンラインでのコーディング試験なんですが、コロナ以前だと、実際にGoogleなどの企業がやっていたのは、やはり確実にオフィスに来てもらって、1つのホワイトボードを囲んで「私が今らからあるクイズを出します」と。クイズというか試験ですね。

それを「文法とか細かいのは間違えてもけっこうですから、ホワイトボードにプログラムを書いていってください」と。それで「わからなかったら聞いてください。一緒に解いていくようなかたちでいいです」と言って、そこで対話していくんですね。けっこう難しい問題だったならば、すんなりいかないのでいろいろ聞いたりするし、あとはいったん「できました」と言われても、間違っていたならば「ここをもっと最適化できませんか？」とかを聞くわけです。

これって、もしその人が採用されて実際にチームで一緒に働くことになったら、日々起こることなわけです。その時はホワイトボードではなく、もしかしたら単にコードレビューツールかもしれないんだけれども、こういったことが行えるのが、そのコーディングテストのもう1つの利点だと思うんですよ。ハイヤールーさんは、こういうのはどう実現されるんですか？

葛岡：我々は、まさに言われたとおりスクリーニングと、今まさに及川さんがお話ししたGoogleで行われているオンサイトインタビューみたいなことをやっています。リモートでインタビューするところは2個の別のソリューションがあったりはするんですが、そのスクリーニングのところは、ある程度自動で評価されるというところが大事だと思うんです。インタビューのところは、先ほどお話があったとおり、自動で評価される必要はまったくない。

どちらかというとインタビュアーもトレーニングをしないといけないんだけど、完全にもう定性的に評価するところかなと思っています。我々はGoogle Docsみたいなものをイメージしていただくとわかりやすいかなと思うんですが、そういったもので実際に候補者と会話をしながらインタラクティブに行って、その履歴が全部見られるところを用意しています。

及川：そうか、じゃあホワイトボードに書いているのと同じようなことをリモート間でやれるわけで。

葛岡：そうです。

及川：かつ、それがオンラインだから記録に残るわけですよね。

葛岡：そうです。実際に私がGoogleを受けた時も、書き終わってホワイトボードの写真をみんな撮って帰っていくことがあって。あれは「そこってけっこう属人化しているんじゃないの？」というのを実は思ったりしていて、我々のソリューションの場合は、書いた履歴みたいなものももちろん全部見られますし、他の方もそれを見て評価したりして、キャリブレーションができるみたいなところはあったりします。

及川：評価者によって、厳しめにいつも評価する人がいたりするのでキャリブレーションが必要なんだけれども、実際にその時どういう会話がなされたかも見ることができるということ？

葛岡：そうですね。ビデオも見られますね。

及川：おもしろいですね！　なるほど。

採用後の海外と日本の違い

司会者：いろいろな事例がありましたが、ここで質問が来ていますので、お答えいただきましょうか。今回のテーマは採用が重視されているかと思いますが、「定着率ということを考えると技術以外の部分も重視するべきだと思います」という意見があります。そこで「採用のその後のポイントで、海外と違いが何かあれば事例が知りたいです」ということでした。このあたりはいかがですか？

葛岡：海外だと、まずは及川さんですかね。

（一同笑）

司会者：ですね。お願いします（笑）。

及川：わかりました（笑）。まず「テクニカルなスキル面も重視するべきです」というのはそのとおりです。それで私が最初に採用・評価・育成で、個人的には採用が一番大事だと思ったのは、やはりまずは一緒に働きたい仲間を、ちゃんと先ほどの定義をして集めていたならば、定着率は良くなるんです。

どういうことかというと、そのソフトスキル面、テクニカルなスキルも含めて、あとはマインドセットも含めてディスクリプションの要件を決めるじゃないですか。それが一緒の人というのは、やはり一緒に働いていて楽しいんですよ。

私は中学受験を例に出すんですけど、今でも四谷大塚とかはあるのかな？SAPIXかもしれないんですけど、あそこで勉強している子たちは、僕もやったんですけど大変なんだけれども楽しいんですよ。やはり勉強がどんどんできるようになって、自分の目標校の受験で合格率が何パーセントまでいった、隣の子はどこまでいった、今回は負けた、次はがんばろうかなと。

エンジニアの成長って、やはり隣に机を並べている連中が、同僚でありライバルなんですよ。そういったようなことをできる仲間が集まっていたならば、必然的にこれは強いエンジニア組織になっていきます。その面において、先ほど言われたテクニカル以外のところ、当然コミュニケーションであったり「HRT原則」というのがあるんですけれども。これが何かは、まぁググってください（笑）。

要は『Team Geek』という本に書いてあるんですが、道徳みたいなやつで、それにはやはり相手をちゃんとリスペクトしようなどということが書いてあって、そういうのが当たり前にあった上で、でも良いものを作るために妥協せずにそれを実現する技術力がある人間というのを、だいたいの企業は自分たちの言葉で定義をしているわけです。

しっかりとマネージャーが、この人たちが集まっていて継続的にパフォーマンスを出すような仕掛けや文化作りをしていたならば、定着率は上がります。

司会者：しっかりと会社のエンゲージメントも高まっていけば「がんばるぞ！」という気持ちになってモチベーションが上がると思うんですが、そのあたりは、葛岡さんは聞いていてどうですか？

葛岡：たぶん僕は及川さんとはちょっと違う。及川さんの意見もまったくそのとおりだなと思うんですが、ちょっと違う観点でいうと、採用後でけっこう必ず起きるのが評価だと思うんです。我々も事業を立ち上げる時にいろいろヒアリングをしたんですが、そこの評価の目線合わせが（評価を）する側とされる側であまりにも合っていなくて、それで「だったら転職してやるわ」みたいに辞めた人がけっこう多かったんですよね。

なので、離職率みたいなところを下げるみたいなところは、もちろん評価できる人というのが必要だと思うんですが、そこの透明性みたいなものが（評価を）する側とされる側で非常に明確になっている必要があるのかなと思っています。

実際にそのあとにさらにヒアリングもしたんですが、かなり大事になってくるのが、技術力とあとはコミュニケーション能力だったりするんですが、現状は、けっこう特に受託開発企業だったらアサインされた案件によってぜんぜん良い評価がもらえない。その方のスキルとは関係なくもらえない、みたいな現状がけっこう起きていたりしますと。

なのでそういったところを何か見える化して、お互いにメイクセンスするような評価をすることによって、お互いに満足して退職みたいなことにはならないのかなと思っています。

経営やビジネスサイドのマネージャーとしてできること

司会者：なるほど。確かに評価もきちんとしてあげないと、気持ちとしてもちょっと「がんばろう」とかのエンゲージメントが高まらないところがありますよね。たくさん質問が来ているので、まだまだお答えいただきたいと思います。現場で働かれている方でしょうか。「リーダーエンジニアとして現場に近いわけではなくて、連携する経営やビジネスサイドのマネージャーとして、エンジニアリング組織を強くするためにできることは何ですか？」という質問です。

及川：難しいですね。

葛岡：難しいですね。僕も今考えていたんですけど、何も出てこない。

（一同笑）

及川：その方がどこまでエンジニアリングなどのバックグラウンドがあったり、もしくはそれを理解しているかだとは思うんです。やはり採用に帰着してしまうところがあるんですが、きちっと採用ができていて、自社が理想とする、現状じゃなくて本来あるべき理想のかたちのエンジニアが集まっているならば、もっとエンジニアに権限委譲してみるというのがいいのかなと思うんですね。

だから、本当にどういうエンジニアが集まっているかなんですけど。エンジニアは本当に自由を与えられたならば技術を単に使うだけではなくて、よく私が言うのは「ソフトウェア開発よりもプロダクト開発のほうがおもしろいです」ということ。ソフトウェア開発は、私も昔よくコードを書いていたので、プログラミングって自分の前のコンピューターをすべて操っている全能の神みたいじゃないですか。

そこの満足感はメチャクチャあって、それがソフトウェアの開発の楽しいところはあるんだけれども、プロダクトはさっきからずっと言っているように、実際に社会課題を解決したり、コード一行一行の向こう側にユーザーが喜んでいる顔が見えるようになるわけですよ。こっちのほうが絶対に楽しいんですね。なので、ここまで視座を高く持てるエンジニアがいたならば、基本的にどんどんエンジニアの現場サイドのほうに権限委譲をしてみたらいいんじゃないかなと思います。

司会者：葛岡さんはいかがでしょう。

葛岡：私も、まずは大前提でテクノロジーのバックグラウンドやエンジニアとしてのバックグラウンドがない方がチームのマネジメントをするのって、比較的難しいと思っていて、そこがない方は、まずちゃんと勉強をしてエンジニアとの共通言語を身に付けるということが必要だと思うんです。

だけどそれがある前提で、基本的に弊社のエンジニアとかもそうなんですが、エンジニアは本当にフリーダムを好むので、そこの権限委譲みたいなところから。そのエンジニア一人ひとりを理解して、その方の強み・弱みみたいなもので、程良い裁量権を与えるところなのかなと思いました。

プログラミングのテストはどの程度の量と時間をかけるべきか

司会者：ご回答ありがとうございます。もう1ついきましょうか。「プログラミングのテストはどれぐらいの難易度でどの程度の量と時間をかけるべきでしょうか？」というお悩みです。こちらも採用面です。

葛岡：それは企業側の質問ですか？

司会者：ということだと思います。

葛岡：それは、まずはどういったエンジニアを求めているか。例えば想定年収とかもそうですけど、例えばリーダークラスなのか、現場でどんどんコードを書くエンジニアなのかみたいなところでも異なりますし、スクリーニングなのかインタビューなのかみたいなところでも異なってくるかなと思うんです。難易度みたいなところは、及川さんはどう思っているのかを最後に聞きたいなと思うんですけど。僕は個人的にGoogleとかは逆かもしれないんですが、難しい問題は出す必要はないかなと個人的には思っています。

どちらかというと、情報系で習うような本当にコアな部分、基礎的な部分を絶対に理解している必要はあると思うんですよ。これはなんでかというと、そこを理解している人と理解していない人では、アウトプットの質がぜんぜん異なってくるんですよね。わかりやすいところでいうと、ハサミの使い方は知っているんだけれどもハサミの作り方を知らないと。

プロダクトの優位性というのを作りたかったら、ハサミを自分で作らないといけない時が出てくるんです。そこを作る時に絶対に必要な知識というのは、そういったコアなところ。そこを理解していれば、そこの知識で意外と教科書で習えるようなところだったりするので、そこさえちゃんと抑えていればいいんじゃないのかなと思っていて。なのであまり難易度がそんなに難しいものじゃなくてもいいとは個人的には思っていますが、及川さんはいかがですか？

及川：まったく一緒です。基本的に、やはり4年制のコンピューターサイエンスで普通に教科書に出てくるようなもので十分かなと。絶対に避けたほうがいいのが、もう知っているかどうかみたいなところの話。昔出ていたこともあるんじゃないかと思うのが「電子メールアドレスを判定する正規表現を書け」みたいなやつって、こんなのはChatGPTか何かに一発吹き込めば、今は返してくれる可能性が高いわけですよ。こういうのは、もはや必要ない部分だなとは思いますね。

お二人から最後にメッセージ

司会者：ありがとうございました。まだまだ聞いていきたいところですが、そろそろお時間が近づいて参りました。最後にお二人から今視聴されている方へメッセージを一言ずついただきたいと思います。まずは葛岡さんからお願いします。

葛岡：私は最初に及川さんからあったとおりで、国力が下がっているみたいなのはけっこう私も感じていて、ものづくりでかつて一番になった国なので、そういうソフトウェアの業界とかでは、またビッグテックとか海外とかに負けないような組織とかプロダクトが日本から出てくるのではないかなと思っています。何かそこにメラメラ燃えるものがあったりするので。今後もそういった強いエンジニアリング組織とかを作る上で、ちょっとでも参考になればよいと思います。ありがとうございました。