全員フルリモートのエンジニア組織が最重要視するメンバーの採用軸とその理由は？――シングラー・三角勇紀さん
採用に特化した人材分析サービス「HRアナリスト」を提供しているシングラー株式会社。 HRアワード2019で、プロフェッショナル部門に入賞しました。 同社は2018年5月にパーソルキャリアのグループ傘下に入っており、2019年1月にdodaと連携したことでサービスの提供範囲を広げています。
今回は同社の執行役員COO三角 勇紀さんにインタビュー。 FLEXYを利用した背景と、重要な採用軸とお話しするエンジニア必見のリモート案件の採用ポイントについてお伺いしました。
目次
採用応募者への的確なアプローチをサポートするサービス
FLEXYを利用した背景
| 当初抱えていた課題 | ・アプリケーションサイド（Ruby）の開発経験がある方が欲しい ・社員教育が必要 |
|---|---|
| 採用軸 | ・コミュニケーションスムーズで、ビジネスレベルでの理解が可能な方 ・開発の技術レベルが高くても、変化に対応するためのコミュニケーションが必要、リモートのためコミュニケーションを正しく取れること ・リモートでの開発している場合は、自ら考えて、自ら提案する。自ら働く必要がある。 |
| FLEXYからご支援に入っている方のご稼働時間 | 週16時間～24時間程 平日夜や土日対応でも構いません。 |
| 働き方 | 基本リモート可能 |
まずは、御社のサービス「HRアナリスト」の特徴を教えていただけますか？
三角 勇紀さん（以下、三角）：人材分析を行うサブスクリプションのサービスなのですが、「この人を採用すべき」と人を選別したり、足切りをしたりするようなものではありません。あくまで採用の意思決定をサポートする存在です。
具体的な内容としては、まず応募者に対して面接前に31問のWebアンケートを配信します。例えば「上司や同僚と意見が対立したら、あなたはどういう行動をしますか」といった質問に対して、選択肢で答えてもらうというものです。 これは応募者に得点をつけるのではなく、その人の性格や行動特性、潜在的な意思決定のポイントを見るためのものです。 どのような軸で会社を選ぶのか、といったことにもつながりますね。事前にこれらの情報を得ることで、限られた面接時間の中で相手のことを理解して質問をする、あるいは相手が聞きたい内容を提案するといったアプローチが可能になります。
営業に例えるとわかりやすいと思うのですが、営業先の担当者がどんな考えを持ってどういうポイントで意思決定をするのかがわかっていれば、提案の角度は180度変わりますよね。 それを採用の現場でやっていこうとしているのが、当社のプロダクトです。
シングラー株式会社 執行役員COO / Founder 三角 勇紀さん
上智大学経済学部卒業後、モバイル広告代理店にて、システム部の部門長としてシステム開発やBIツールの導入、技術戦略立案などに従事。同社退職後、システムコンサルティング、システム開発事業をスタートさせ、スタートアップ企業にて、執行役員として、新規ビジネスの立ち上げ、システム外注のマネージメント、人材採用などに従事する。
2016年3月に執行役員を退任後、フリーランスのエンジニアとして人事系システム開発などに従事。
2016年11月にシングラー株式会社を創業しCOO就任。エンジニア組織の戦力増強と社内教育を図るためにFLEXYを利用
今回FLEXYを利用することになった経緯を教えてください。
三角：私自身がFLEXYさんに登録していましたし、CEOの熊谷はもともと担当コンサルタントの野谷さんと知り合いでした。 当社の課題を熊谷から野谷さんにお話したことをきっかけに人材を提案してもらったのですが、実際にお会いしたら良さそうだったのでご依頼した感じですね。
今回はRubyのエンジニアの方を採用されていますが、どのような課題や目的があったのでしょうか？
三角：Rubyの実戦経験を持つメンバーにジョインしてもらうことで、戦力増強を図りたかったのがまず一点です。私自身はRubyやRailsのエンジニアとしての経歴が長いのですが、ほかのアプリケーションサイドを担当しているメンバーは、Rubyには軽く触れたことがある程度でした。
もう一点は、Rubyの開発経験者にジョインしてもらうことで社内教育を促すことです。知識的には私に聞いてもらうだけでも事足りるのですが、立場の違いがあるため技術力をもっと高めていこうというパワーは働きにくくなります。 メンバーと同世代でレベルの高い人材が外部に存在することで、さらに上を目指そうというモチベーションが高まる。そんなポジティブな環境を作る狙いがありました。
「いかにコミュニケーションコストを抑えられるか」を軸に採用
Ruby開発経験者は多いかと思うのですが、採用軸は何だったのでしょうか？
三角：今稼働いただている方を採用したのは、直接お会いしてもリモートでやりとりしても一番コミュニケーションがスムーズだったからです。
我々のプロダクトはまだまだ未完成なので今後も日々成長していきますし、方向性もどんどん変わっていくはずです。激しい変化に対応していくとなるとメンバー同士のコミュニケーションコストは高くなりますし、その途中で何のために開発をしていたのか目的を見失うかもしれません。そういった事態を防ぐためにも、正しくコミュニケーションが取れることはかなり重要視していました。
また、当社は社員も含めて基本的に全員リモートで開発を進めています。チームは業務委託の方も含めて10名弱で、このうち社員は4名なのですが、それぞれ岐阜、横浜、広島で働いているような状況です。
ですから自ら考えて提案できることや、監視されていない中でもモチベーションを持って働けることも採用軸の一つとなっています。そういった当社の考え方へのシンクロ率が高かったですし、すぐに順応できるタイプだろうと判断しました。
技術レベルはどのように判断しましたか？
三角：コードレビューをするなどいろいろと方法はあると思うのですが、私は基本的にこれまでの経歴を見て、どういう考えを持って意思決定をしてきたのかといった点を聞いています。正直、技術レベル自体は蓋を開けてみないとわからない部分が多いんです。ただ、FLEXYの野谷さん経由でのご紹介だと、こちらも応募者への理解がすぐにでき、ご紹介いただける方にミスマッチが無い印象です。
当社はプロダクトに高度な技術を利用しているわけではないので、一般レベルの技術力と知識欲さえあれば概ね問題なく業務をこなせます。むしろ技術的な問題にぶつかったら自ら動いて勉強するといった、当たり前の行動習慣が身についていることの方が大切です。
1～2ヶ月ですぐに成果を出してほしいとも思っていないので、多少レベルが追いついていなくても、半年から1年ほどかけて正しく技術をキャッチアップして、プロジェクトを推進してくれればそれで問題ありません。
業務委託のメンバーであってもとにかく自由に技術的挑戦をしてほしい
稼働状況は、週16～24時間程度とお伺いしています。
三角：組織としては、まだ開発やプロダクトに慣れていない社員がいる状況でした。 そこにさらに新しい人材が増えたらどれくらいフォローできるのか不透明だったので、やや少なめからスタートしました。今は、可能であればもっと稼働してもらいたいと思っているくらいです。
ただ今入っていただいている方は別の企業で正社員として働いていて、土日や平日の夜の稼働となるので、現状も同じくらいの稼働時間です。
実際の仕事の進め方や、案件の役割分担について教えてください。
三角：カウンターパートは私ですが、細かいコミュニケーションは完全に現場の社員に任せています。 役割分担としては、既存プロダクトの細かい修正は社員が行い、FLEXYからご稼働している方にはRubyやRailsのバージョンアップをお願いしています。既存プロダクトのソースコードの再整理や、アップデートに必要な内容の整理などですね。 業務の中でお伝えしているのは、とにかく自由にやってほしいということです。 合理性さえあればどんな技術を使っても構いませんし、自分の成長のために触れてみたい技術にもどんどん挑戦してほしいと思っています。 全てをプロダクトに反映できるかは置いておいても、自由に技術選定をしてもらうことで当社の開発チームや社員個人に良い影響を与えてくれることを期待しています。
リモートワークは積極的に推進されているのでしょうか？
三角：推進しているというよりは、リモートでも問題がないから、リモートワーク前提で経営をしているという感じですね。 ただ、フェイス・トゥ・フェイスのコミュニケーションも重要な場面も多々あるので、雇用か業務委託かに関わらず必要に応じて定期的に面談をしたり食事に行くなどリアルな接点を持つようにしています。
直接お会いする場合はどんな話をしますか？
三角：コードをその場で見て検討することもありますが、基本的には人間関係の構築が大きな要素です。 例えば、最近の状況を改めて確認したり、困っていることがないか、成長するために今後うちでやりたいことはないかといった話をしますね。FLEXYからご稼働いただいている方は、リアルでもお会いできる距離にお住まいなので、私の中でうれしいポイントです。
最小単位のチームでスピーディにプロダクトの改善を繰り返していく
今後の企業の展望について教えてください。
三角：目先の課題は、パーソルキャリアと提携して進めている部分をさらに軌道に乗せていくことです。プロダクト自体は正しく使えば効果が出ることを概ね実証できているのですが、「正しい使い方」の部分に若干ハードルがあります。どんな対策が必要なのかは正直まだ不透明で、お客様の声を聞きながら日々仮説検証を繰り返しているところです。
スピード感を持ってスクラップアンドビルドを繰り返し、細かい修正を続けることになるでしょう。 その上で、エンジニア組織としてはもっとビジネスの課題をキャッチアップできるようにしていきたいですね。どのようにビジネスサイドの情報を伝達するのか、さらにモチベーションをどう保っていくのかという部分にも注力しています。
エンジニア組織の規模は拡大予定ですか？
三角：社員自体は、2020年に4名から6名に増やす程度で良いのかなと思っています。現在の事業サイズを鑑みると、あまり人を増やしすぎるよりも、リモートによる最小限のコミュニケーションコストで開発を進めた方が良いだろうという判断です。今後事業ドメインが増えて組織の拡大を図るとしても、最小単位のチームを複数作っていくイメージです。
