未経験エンジニアがベンチャーに採用されるのは無謀なのだろうか？

タイトルはいい感じの内容が思いつかなかったのでダンまちっぽくしようとして失敗したので気にしなくていいです。

TL;DR

このエントリは上記の発言を今朝みてしまい申し訳なくなったので懺悔の気持ちで書いています。 グーメン。

ちなみに今回の件はリモートだからというのはあまり関係ないと思いますまる

発端

先日ひょんなことから下記のブログを拝見し、「ここは正しくないし誤解しているから直したほうがいいよ(意訳)」というコメントをしました。 そのあとで正直な気持ちをはてブしたところ思わぬ方向へバズってしまったらしく、 その一因を作ってしまったという反省の思いから「じゃあどうすれば良かったのか」を書いて許しを得ようという下衆い動機が出発点になります。

shimarisu-esa.hatenablog.com

問題の洗い出し

さてまずは問題点の洗い出しを行ってみようと思います。 あくまで伝聞なので、おそらくはこの5〜10倍くらい実際には問題があったんだろうと思うんですがまあそこはエスパーでもないとわからないので考えないこととします。

問題点その1

まず最初にはてブでも書いているのですが今回の件は応募者側と募集者側による意思疎通のミスマッチによるところが大きいと思っていて 期待値と実測値のズレがあったということに尽きるというのが個人的見解です。

なのでこの採用された会社の社長さんを悪くいうつもりではないのですが

企業はEdTeck（つまり教育×IT）をやろうとしていた

とあるので恐らくは「教育の現場を知っている」≒「ビジネスを理解している」という期待をそのまま勘違いしてしまったのか、 あるいは楽観視してしまったのではないかなと想像しています。

これが新卒正社員とかならまだ教育して期待値の方向に舵を切ることもできるのではないかと思うのですが フルタイムではないアルバイトで、かつ未経験者でリモートワーク、そして会社側も不慣れな言語だった？ということで悪条件がこれでもかと重なってしまったんじゃないかと思います。

それぞれ1つ1つの要素はそこまでネガティブな要因にはならないと思うのですがこれだけ重なると採用に踏み切るのはなかなか勇気がいるなと感じます。

ぼくなら絶対採用しない、ミスマッチになるのがわかりきっているので誰も幸せになれない未来しかみえない。

問題点その2

そもそも雇い主も普段はrubyをやってない

個人的に気になったのがこれです。 まずrubyやったことないのにいきなり戦力として未知数なアルバイト社員をアサインしたのが気になりました。

ありそうなストーリーとしては別の社員が普段はrails/rubyを理解していて普段はそちらに頼むんだけど別件で忙しく手が回らない。 そしてそこまで難しくないチケットなのでアルバイトでも出来るんじゃないか？ 最悪その理解している人をチューター役に据えてサポートすればいけるんじゃないか

と会社側が思ってしまったのではないか？…というのを考えていました。

もし、「誰もrubyとかわからんけどそんなコード量ないし、サクッと直せるっしょ！」みたいなノリか考えだったとしたら勇気を通り越して蛮勇の域に達していると思う。 とはいえさすがにこれは考えにくい。

なのでおそらくは上記のストーリーのほうが有り得そうだなと言う感じです。 そしてその目論見はチューター役の人がめちゃくちゃ忙しくなってしまってそこまで手が回らず机上の空論と化したみたいな展開じゃないかなという気がします……つらい。

問題点その3

バイト通過の際面談してくれたのは社長のみ

ブログ内では明確に言及はされていないので詳細はわからないのですが社長はエンジニアでなかったとしたらなかなか冒険したなという気がします。 少なくとも技術的な観点からエンジニアにアドバイス求めていればミスマッチが起こらなかったか、心構えはできるよう整えられたんじゃないかな。

一番最悪なケースとしてはかつて少し技術をかじっていたのでスキルレベルを測ることはできないが多少知識があって応募者のスキルレベルを見間違えてしまったパターン。 一言エンジニア職の人に面接時に相談とか質問してもらっていれば良かったのにな、という気持ちがあります。

ただそうするとその場合応募者の方は採用されなかった可能性が非常に高いのでそれが誰にとって良いのか？というのは難しいところですがプロダクトにとってはそちらのほうが良かったと思います。 一度書いてしまったコードを引っ剥がすのはコードを追加することの何倍も難しいですからね。

問題点その4

恐らくですがこの会社でリモートワークされる方はあまりいない、もしくは初の導入だったんじゃないかなという気がします。 「リモートワーク」というのは「言うは易く行うは難し」みたいなところがありますし、性格的に向いてたり向いてなかったりすることもあります。

ただなによりもリモートワークには「リモートワークするための能力」が絶対に必要になります。 リモートワークを実践している会社では多かれ少なかれ、この手の問題を認識しているので未経験の方をいきなりリモートワークで働いてもらうというのは考えにくいかなというのが根拠です。

これがフリーランスなどであれば、単純に出来たか出来てないかという成果だけをみれば何時間働いていようとどこで働いていようと働いていまいと関係ないのですが 今回はそういう方面での採用ではなかったようなので完全に謎、故にリモートワーク初導入かそれに近い状況だったんじゃないかと愚考する次第です。

問題点その5

これは主に会社側の問題だと思っているんですが「わからない」と伝えてきた人に対するサポートの仕方がかなり不足しているように文章から読み取れました。 実際のところはどうなのかわからないですが質問されたかたが「まず何がわからないかわからない」状態になっていることは恐らく伝わっていたと思います。

そのときに文章で伝えるのは立場的なものを考えるとかなり心理的ハードルが高くて現実的に難しいといって良いかと思います。 「わからないことがわからない」と伝えるのは非常に勇気がいりますが今回は未経験であるというある種の負い目などもあったためより言いにくい状況であっただろうと推測されます。そこはチューター役がいればチューター役が、会社の上司部下、先輩後輩の間柄であれば上位者側から「どこがわかりませんか？」と質問する必要があります。

そういえばこの手の「わからないことがわからない」空気って何故か一瞬で周りは理解できてしまうのですが何故理解できたのかを言語化するのは難しかったりします。

そういう意味ではサポートの仕方が信頼や愛が足りないなと感じました。 とはいえ、これは一方から見た、それも勝手に文章から読み取った内容なので大きくミスリードしている可能性は大いにあると思っています。 ただもう少しやりようがあったのではないかなというのが個人的に引っかかっています。

問題点その6

何の自慢にもならないのですがぼくは年齢の割に転職回数が多いです、いや本当になんの自慢にもならないのですが。 んで転職している回数が多いということはそれだけいろんな文化を持った会社やチームに触れてきたということでもあります(客先常駐やフリーランスとは比べない)

良いチーム悪いチーム、良い会社悪い会社それぞれいろんな特徴があり一概にこれがあったら駄目というのが難しいのですが 1点だけこれが担保されていない職場は悪いチーム、悪い会社になる傾向が非常に強いのでそこでは働かないという指標をぼくは持っています。

それが「HRTのないチームでは働かない」です。 このHRTが毀損していてもチームは良かったと思えたことがないですし、そもそもそういう環境下で自分のプレゼンスを最大限引き出せるとはとても思えないです。

ぼくは小心者なので萎縮してやれることだけやるという方向に逃げること間違いなしです。 TeamGeekでもHRTは大事って言ってたので多分そんなに外してないと思う。

社長は気さくに接したり、かわいいスタンプも使ってくれるけれど、 他の社員さんはそういうのゼロ。 必要最低限のことしか返ってこないし、絵文字顔文字を多用するのはこちらのみ。 うわ、もしかしてリス、嫌われてる？？

……おわかりですね？ この内容が真だとするならぼくの経験則でいうとチーム崩壊間近な空気感です。 信頼性皆無でただ言われたことを必要最低限やっている(と本人だけが思っている)チーム、これに近い経験が数回あるのですが正直そのときのことは思い出したくないです。

これはこの応募者のかただけの問題ではなかったとぼくは思っていて、恐らくはこのかたが入られる前から不穏な空気が流れていたか顕在化していたんじゃないかと思います。

そのあたりは完全に想像なので真偽の程はわかりませんが、未経験のかた1人入っただけで全てがぶち壊されるほど繊細なチームだとは思いにくいのでそっちのほうが妥当な予測かなという気がします、これが上位者だったら1人によってチームが破壊可能だったりするわけですが今回はそうではないのでその辺はないかなと。

恐らく社長さんはそういう空気を感じつつもなんとか孤軍奮闘したけどどうアプローチすればいいのかわからなかったんじゃないでしょうか、……めっちゃ胃に穴が空きそう。

以前働いた会社でも技術力の有無に関わらず、信頼関係のない職場というのはギスギスした雰囲気がありますしそこかしこで誰かしらの悪口が横行していました。 そういう環境に身を置き続けると心が萎縮してしまい、本来の能力に蓋をしてしまいます。 そうすると悪循環で以前よりパフォーマンスが落ちているのでそれを責められ、また消極的になりだんだんと生産性が下がってしまいます。

こうなるともう最悪です。

改善編

さて長々と問題を書き出してきましたが「ではどうすれば良かったのか？」を書いていこうと思います。

問題点その1

これはもう簡単で採用面接時にエンジニアと会話させる、面接という形でなくてもある程度時間を設けて話しをさせておけば回避できた状況だと思います。

slim？JSのエラーの出し方？gemを使わない検索システム？SQL外部結合？地図のAPI？例外処理？自動テスト？そもそもテストってなんぞ？？

とあるので恐らくなにかしらの予兆は感じ取れただろうと思います。 少なくとも依頼しようとしている内容に対してスキルレベルが足りていないぞ、という。

仮に依頼しようとしている内容を把握していなかったとしてもどういう状態であるかはなんとなく察することができそうなのでそのときに感じた違和感を社長さんに報告していればなにかが変わったんじゃないかなという気がします。

問題点その2

これも簡単。その道に通じているフリーランス雇いましょう、それで全て解決です。 ……とはいえエンジニアの採用は昨今かなり難しいと聞いているので筋のいいエンジニアは単価が高そうです。 次善の策としてはそもそもその慣れていないであろうrubyの案件を断るとかでしょうか？

それはそれでなかなか厳しいと思いますが受けてしまって出来ない、あるいは突っ込んで社員が燃え尽きているところに無理やりねじ込むよりはまだマシな気がします。

問題点その3

これは問題点その1とほぼ同じかなという気もするのですが他にもやりようがないか少し考えてみました。

面接前でも後でもいいのですがエンジニアと座談会っぽいものを求めて話をするというのは1つあってもいい気がします。 いけるなら飲み会ではなくランチだとよりよいですね。

あるいは「ホワイトボードコーディングを行う」というのは1つ解答としてありかなという気がします。 言語を問わず、なにか自分たちが抱えている問題の中で比較的簡単なものを解いてもらえばどういう能力が欠けているのかを知る機会はあったかなという気がします。

ぼくが過去に受けたホワイトボードコーディングだと有名なFizzBuzz問題やフィボナッチ数列、レシートからDB設計を考える、プロダクションコードを読んでどのあたりに改善の余地があるか考えるあたりはありました。 どれがより効果的であったのかは不明ですがレシートからDB設計を考えるやプロダクションコードのどのあたりに改善のよりがあるかを考えるテストは刺激的でした。 またそのような発想にいきついた論理的な思考や説明を聞くことでどのような分野に強みがあるのかなどが知れたのではないかなと思います。

そういえば1ヶ月くらい前にブラウザの仕組みを面接で説明してもらうのが実力を知るのにいいのではないかという話題がありましたがあれなんてまさにそうでプロトコルの中身は実装から語る人もいれば、そうではなくサーバーサイドの仕組みを語る人、フロントエンドの仕組みを語る人などいてなかなかいいリトマス試験紙なのではないかという気がします。

問題点その4

これに関してはうまくやれている会社もあるんだろうとは思うんですが個人的には信頼のない方とリモートワークするのは不可能だと思っています。 これは未経験であるかないかはあまり関係がないです。

ただ未知数であること、未経験者であることなどを考えるとリモートワークさせるべきでなかったというのが最終見解です。

よしんばやるとしても週5勤務だとしてフルタイムでなくてもいいので週2回は物理的に出社してもらい意見のすり合わせなどを行う必要があったかなという気がします。 そこから徐々にフルリモートへの移行というならば適正と会社に受け入れるだけの土壌があれば実現できたかもしれないです。

このあたりは個人の適性やスキルにも大きく依存するのでなかなか難しいですが文章を読んでいる感じだとまだセルフマネジメント能力が圧倒的に不足しているように思えたので時期尚早だったんじゃないかと思います。

問題点その5

ぼくなら文章で説明がなんかよくわからん！となったらビデオチャット使って説明してもらいます。 あるいはペアプログラミングするとかでもいいと思う。

とにかくやりようと伝え方に関してテキストだけでやり取りしているように見受けられるのでそこを改善したらもう少しマシになったんじゃないかなという気がする。

問題点その6

チームが崩壊しようとしているときにどうすればいいのか？……ぼくも知りたいです。 手っ取り早くチーム解散するくらいしか思いつかないけどそれって根本的になにも解決してないんですよね。

とにかく何が問題なのかチームメンバー集めてポストイットとかに貼っていってもらって本当に困ってることを見える化するところから始める、とかかなあ？

まとめ

今回の問題は未経験であるとかリモートワークだったことではないと思っていて、求人の不幸なミスマッチというただその1点につきると思う。 恐らくこの応募者のかたはそれなりに優秀なのだろうと思う、ポートフォリオを2つも作りきっているとのことなのでそれは純粋にすごいことだし評価されていいと思っています。

他方、オンラインプログラミング教室の問題であるチームで開発する能力が不足していたのではないかと思います。 会社というのは個人で開発することよりもチームで開発することのほうが多いと思うのですがそのためのスキルというのは実際にやらないとなかなか育たない、1人では育てられないという問題があるのでこれは仕方のないことなのかなという気がします。

応募者の方のまとめにも答えが書いてあるのですが…

そもそもプログラミングの本質って問題解決ですよね。 リモートってことは、あらかじめ決まった仕様が送られ、 それをコーディングしていくっていうのがイメージなんでしょうけど。 コーディングする側だって、実装するシステムが 本当に顧客の問題解決になるかを考えなきゃいけません。

結局のところ、そういうことだと思うのですよね。

プログラマーのライトスタッフとしてぼくが必要だと考えているものが3つあって

  1. 問題認識力
  2. 問題解決力
  3. 実現能力(プログラミング)

だと思っています。 そういうこの中で一番重要だと思っているのが問題認識する力で、問題を認識すればどう解決していくのかはある程度的が絞れます。

ぼくが見てきた中で優秀だと感じたかたはだいたい問題の捉え方が芯を喰っていました。 逆に言い方は悪いですが無能だと感じたかたは問題を問題として捉えることすら出来ていないことが多かったです。

そしてこの中ではプログラミング能力、問題を解決するために実現する能力というのは最後の最後に必要になるだけで実はこの3つの中では一番重要度が低いと思っています。 だからといって軽視してるわけじゃないよ！選択肢はあればあるだけ問題を認識する視野や解決する能力に幅をもたせてくれると考えていますからね！

そういう意味でいうと応募者のかたは今回の件はこの全てに問題がある、言い切ってしまえばプロとして必要な水準に達していなかったということではないかと思います。

ただこれは募集していた企業側にも言えることだと思っているのでどちらがより悪いということではなく、ミスマッチが生じていたのが時間がたつ毎に悪化してしまい非常に残念な結果になってしまったのが悔やまれるということです。

応募者のかたはいまSESとして働いているということなのでひとまず良かったのかなという気がします。 非常に珍しい経験をしたということで少しでも人生の糧にしてこのあとのエンジニアライフを謳歌していってくれるといいなと心よりお祈り……だと駄目なので期待しています。

ボク個人の感想としてはマジで↓な感じでアグレッシブさを忘れずに「ガンガンいこうぜ！」をこれからも実践してほしいなと思っております。

……はークソながかった。懺悔は時間がかかる、ちぃ覚えた。