職場における多様性を守るのはとても大事なことなのだけれど、スタートアップの場合、否応なしに多様性が生まれることがあります。テック企業の経営者といえば何かというとすぐにプログラマ不足を嘆くことで知られていますが、前職で率いていた開発チームでは人材が不足したことは一度もありませんでした。なぜなら、もちろん技術的な問題を解決するためにトンネルを掘ってエルフにアドバイスを求める人材を求めていたわけではなかった上に、何よりとても待遇が良かったこと、それに他の会社よりも少しだけ人材獲得のための間口を広げたからです。普通、転職市場にアクセスするチャンネルは知り合いや友人、社内の誰かや投資家からの紹介、それからエージェントからの売り込みと求人への応募と相場が決まっています。でも、身近に転職の意思がある人なんてそんなに簡単には見つからないし、一般公募するのもなかなか当てにならないですよね。

転職エージェントとの対話

そんなある日、投資家の紹介で転職エージェント各社の皆さんの前でお話しする機会を作ってもらうことになりました。これはチャンスだと意気揚々と出かけて並み居る皆さんの前で一席ぶってきたわけですが、簡単な資料を用意して、まずこれまでの開発者としての経験からエージェントの方々に一番伝えたかったことをお話ししました。第一に、大抵の開発者は皆さんのことが嫌いです。技術的なことは何もわからないし評価も当然できないのに、一体われわれの何を売り込むというのでしょう。ただでさえ普段から台湾のアイドルの顔をした転職エージェントを名乗るアカウントがLinkedInで熱心にコンタクトを取りたがってくるし、Githubに公開したメールアドレスには全て同じ文面のメールがアルファベット順に届き続けているのです。単純に転職市場にいるプログラマの数が需要と比べて足りていないというだけで適当に仕事をしてもバレないだけという人も珍しくはない世界ですから、疑い深くなるのも当然です。この断絶の存在を理解することから始めようじゃありませんか。では一体どうやってこの断絶を埋めることができるのでしょう。皆さんが今から急に付け焼き刃で技術のことを勉強しても仕方がないのは明白です。そんな上手い方法が果たして存在するのでしょうか。

諦めてはいけません。と、ここで二番目にお伝えしたかったことを記載したスライドに移ります。ここに一冊の本があります。「ピープルウェア」というタイトルで、80年代から読み継がれているベストセラーです。皆さんだって全員が全員、好き好んでソフトウェア開発者に関わる仕事を始めたわけではないと思います。むしろ嫌いになってしまっている方も大勢いらっしゃるかもしれません。でも、もしそうならなおさら、連中を理解してうまく扱える方が心の健康のためにもいいと思いませんか?そのためには、これを読むべきです。電子書籍化もされています。難しい漢字が苦手なら原書もすぐ手に入ります。弊社はこの本に書かれたことにかなり忠実に運営していくつもりです。なので、弊社にぴったりの人材を提供していただけるということであれば、この本を読めば余計な手間はみんな省けます。それに、こっそり教えちゃいますけど、この本は私たちの他にも、GAFAでしたっけ?MAGA?とにかくなんかアメリカのでっかいソフトウェア会社の人たちはほぼみんな知っています。だから、そっち方面のでかいクライアントとの話もうまくできるようになるかもしれませんよ。

プレゼンが終わり、名刺交換の時間になりましたが、この本について質問してきたエージェントは1社しかありませんでした。ちょっと正直に喋りすぎたのかもしれません。

ハードルを下げる前に

こうして国内のソフトウェア技術者の転職市場を扱うエージェントの大半から見放されてしまったわけですが、人材が必要な事情は変わらず、ここで選択を迫られることになりました。求人のハードルを下げるなら、もちろん人材獲得はより簡単になります。でも、特にスタートアップは人材で決まるということはよく知られています。というかむしろ人材がほぼ全てであって、間違った人を入れてしまえば簡単に失敗します。なので、人が足りないからと求人のハードルを下げることだけは絶対に避けるべきです。

東京には日本国内で働く外国人のソフトウェア開発者を多数扱うエージェントがいます。なので、こっちがバイリンガルで仕事するだけで他の多くの企業との競争に優位になることに気づきました。英語なんて中学生の頃からやってるんだからプログラミングよりずっと長い経歴があります。言語の壁さえ取り除けば、優秀なプログラマにアクセスするチャンスが増えるなら迷う必要はありません。それに、個人的にTokyo Rubyist Meetupのようなイベントに何度か顔を出したこともあるので、人材がいるというのは知っているのも手伝って、さっそく話を聞いてみることにしましたが、すぐに何人か非常に興味深い人材の候補を教えてもらうことができました。また、そのエージェントの担当者いわく、もしダメなら理由はできるだけストレートに伝えて欲しい、婉曲に候補に伝えるのはこちらの仕事だから、とのこと。それは大変助かります。もちろん、その代わりとてもアグレッシブに営業してくるので、評価も間髪入れずすぐ伝えないと矢のように催促されますが、候補者の皆さんには頼もしいですよね。

実際に面接を進めてみると

何人かとインタビューした感触はこんな感じでした。技術力が高い人はそれなりに見つかります。ということは、もちろんちょっと物足りない人もいます。日本語能力は、ちょっとこっちがドン引きするくらい高い人もいます。日本語ネイティブの社内のクオンツから上がってくる文法も語法も言いたいことも不明瞭でめちゃくちゃなGIthubのissueを読んで理解してすぐ返信するのだから驚きです。それに、他社ではコミュニケーションに問題ありとされた人材も、話していると全くそんなことがなかったりします。もちろん、こっちも気楽に話してもらう工夫はしました。例えば、大抵の人は面接には就業時間の後に来るので、もう誰もオフィスにいないしいいスコッチもあるからこのまま飲んじゃおうぜとグラスを渡して飲みながら話したりとか、そのまま一緒に飲みに行っちゃうとか。お酒が入ると外国語って数倍話しやすくなりますよね。もちろん相手の思想や信仰に合わせて対応する必要がありますけれど。それから、どんな言語も大抵は読むより書く方が難しいのでそこはサポートする必要があります。というかこっちだって書くのは英語にしてもらって構わないし喋るのも特に込み入ったことなら日本語でも英語でもどちらか慣れている方で話してもらえると助かります。

それから、ちょっとした副作用でこれは便利だなと思ったのは、その国の言葉や文化を知らないと名前を見ただけでは性別がさっぱりわからないことですね。事前に偏見を排除できるのはなかなか良いなと思いました。今後は名前や性別それから顔写真なんかを隠した状態で書類選考できたら良いですね。

役に立った面接の手法

色々試す中でやっぱり一番面白かった面接のやり方は、その人のコードを持ってきてもらって、開発チームみんなでそれを改善するという疑似プロジェクトをやってみることです。数年前に作りかけたRailsの基本的な部分しかないへっぽこなコード群でも構いません。それをみんなでワイワイガヤガヤと改善していくミーティングをするのです。ただし、人格の非難とかは当然禁止です。それだけでなく、こんなコードダメだろ!みたいな非難をするのもルール違反とするべきですね。なぜなら、意味がないからです。ここは改善できるとか、ここは改善するべきとか、そういうのは価値のある意見ですが、それがいいかダメかみたいな感想は家で便所で勝手に出しておけばいいものです。またオリジナルのコードが考課の対象とならないことも明言しておくべきですね。そうじゃないと勿体ぶってコードを出してもらえなくなります。もちろんすごいのを出されたら加点はしますが。

人を選ぶ際の基準

大事なのは、その時、ほんの少しでも、あれ?なんかこの人とうまくやり取りできないな、と感じたら、その候補者は迷わず落とすことです。いざというときに必ず問題になるからです。もちろん、その人が本当はとても優秀だということは有り得ます。可能性は無限です。でも、諦めも肝心なのです。他のチームメンバーが良いと言っていた、なんてことを言い訳にしてはいけません。最終的に責任を負うのは経営者であり上司でありマネージャーであり同僚ですが、無責任な「はい」は責任ある「いいえ」に勝るものでは決してありません。ベンチャー企業ではどうしても人が足りないというプレッシャーを受ける時期が何度かやってきます。その時に基準を下げてしまうと後で悔やんでも悔やみきれない事態が必ず待っています。そんな事態が来ない場合は単に来る前に会社が潰れたのでしょう。絶対にダメです。絶対にしないと約束できる人だけが続きを読んでください。大丈夫、人材は決して枯渇はしません。ちゃんとした待遇を用意して、マネージメントを頑張れば、普通のレベルの人材不足なんかすぐ解消されます。ちなみに弊社の場合はこのやり方のおかげで予算を獲得するまでは希望者に入社を待ってもらう状態がしばらく続きました。

怖いのは「有能な敵より無能な味方」です。覚えましたね?

コード改善のテーマはどんな内容でも構いませんが、なるべく自分の事業とリンクした方が良いですね。スケーラビリティに問題を抱えるサービスを提供する会社ならそのコードをよりスケールさせる方法を突き詰めてみるのがいいでしょう。パフォーマンス改善なんかは関連する広い知識が求められるのでどんな場合もおすすめです。ひとしきり案を出し合って会話が収束していったタイミングで、ふと何かに気付いた顔で「あ、でもこれもう少し改善できるよね?」と質問しましょう。もちろん何の腹案もなくて構いません。そんな時、どんな狼狽え方をするのかもよく見ておきましょう。頭が良くて問題解決能力に優れた人はこんな時にとても面白い答えを返してくれるはずです。もちろん当意即妙な答えを返す人だけが優秀とは限りません。しばらく別の話題に移ってから、時間をおいて答えを出してくれるタイプの人もいます。面接者は自分と同じタイプの人を過大評価してしまうので、その点をきちんと自覚しましょう。できればそういったルールは事前に全員に配布して同意を得るべきですね。これと全く同じことがコードレビューにもいえます。このルールを守らないと、レビューにコードを出してもらえなくなり、事前にミーティングで調整するような訳のわからない文化が生まれます。そんな事態になれば最初の意図は完全に形骸化しているので、どんなにレビューをしても報われないだけになります。

こうして、前職では得難い人材を何人も揃えることに成功しました。ところが、これだけではうまくいかないのが会社というものなのです。次回、かどうかはまだわかりませんが、この後には必ず、それでどうなった?というエントリを投稿したいと思います。