2019年10月3日（木）、FLEXYの主催する【CTOmeetup】JavaScript　～進化し続けるフロントエンドエンジニア～が原宿のFor PROビルにて行われました。

2019年の今、最前線で技術を研鑽し続けるエンジニアはJavaScriptの現在や未来をどう見ているのか。 フレームワークの選定基準や、フロントエンドエンジニアに求められる資質、採用手法なども網羅しています。

前編記事は、こちらからご覧ください。

フロントエンドエンジニアの採用と教育

スタートアップでも大手企業でも、技術広報の効果は非常に高い

井原　正博さん（以下、井原）：では後半は、フロントエンドエンジニアの採用や教育についてディスカッションしたいと思います。 どうすれば優秀な人が来てくれるのか、一番大手のリクルートさんの場合はいかがでしょうか。

古川　陽介さん（以下、古川）：私が見ている基準からすると、前半で言及したように何か軸があるかどうかですね。 例えばReactでアプリケーションを作りましたというだけでは特に面白みはありません。 こういう意図が合って作ったのだというこだわりポイントを聞きたいです。パフォーマンスを出すためにここまで頑張ったとか、最終的にブラウザの仕様がどうなっているか理解できたといったことを語れるなら、良い人材と言えると思います。

井原：どうやって母集団形成をしていくのか、ノウハウはありますか？

古川：リクルートはリクルートですから、もちろんスカウティングの基盤があります。 エージェントを使うことが多いですよ。ただ実際のところ人を集めるために工夫しているのは、ブログでフロントエンドエンジニアの技術をアピールしたり、こういったイベントに登壇したりすることですよ。 地道なPRですが、結果的にそれがフロントエンドエンジニアとして一緒に働いてみたいという気持ちにつながると思うので、積極的に取り組んでいます。 案外馬鹿にならないんですよ。ブログを見て応募したという子も多いです。

菅原　孝則さん（以下、菅原）：小規模な企業における採用活動における壁は、認知がないのでそもそも組織に魅力を感じてもらう機会が少ない事なんですよ。 だからまずは昔一緒に仕事をしたことのある優秀な人に声をかけていくことになります。リファラルですね。そのストックも1～2年もすれば尽きるので、やはりイベントに登壇したり、技術広報でPRします。 私の場合そこで意識したのは、いかにイケてる企業に見せるかということです。 今後、流行の波が来るだろうとあたりをつけたアーキテクチャをプロダクトに実際にプロダクションで活用して、こんなに最先端なことをしているんだよと言ってしまいますね。感度の高い人にはアプローチできると思います。

井原：その場合、サービスへのリスクはありますよね。

菅原：小規模組織だからこそできることかもしれませんね。 どんな技術でもそうですが、一度導入してみないと上手くいくかは実際のところわかりませんし、だったらよりカッコ良く見せた方がいいだろうという考えです。それで問題なく動けばいいわけですし。

林　優一さん（以下、林）：以前LIGという会社に所属していたのですが、採用方法が少し特殊でしたね。 エージェントなどはなるべく使わずにインバウンドでの採用が一番多かったんです。 当時は技術ブログしかり、ちょっと面白そうなことをしている会社というブランディングが流行っていて、実際に非常に効果がありました。 ただ今はそれもすっかり乱立状態で、「とりあえず技術ブログを作っておけばいいだろう」という企業も多いです。 情報が多いし質もバラバラなので、とても見きれません。記事がSNSのTLに流れてきてもタイトルだけ流し見してしまいます。 だから技術ブログで広報しようと思ったら、ライティング能力も必要です。 LIGの場合は技術記事であろうと何であろうと、全て編集者がチェックして、素人が見ても読みやすいレベルの平易な言葉に手直ししていたくらいです。 ほかの例ではやはりリファラル採用が一番多いですね。仲の良い知り合いを引っ張ってくるだけではなく、こういうイベントの場で知り合って誘います。 やはりコミュニティに参加しているような人はアンテナの感度が高いですし、優秀なエンジニアを捕まえたかったら直接会いに行くのが一番だと思いますよ。 このイベントの後に行われる懇親会も同じで、良い人がいたらその場でスカウトします。

右側：林　優一さん 株式会社ZIKU Technologiesフロントエンド開発担当者執行役員/UXエンジニア 株式会社Emotion Tech プロダクトアドバイザー 株式会社GIG プロダクトアドバイザー 左側：ファシリテーター　井原　正博さん 株式会社ビットジャーニー 代表取締役

フルスタックエンジニアになるか、ピーキーなスペシャリストになるか

井原：特にフロントエンドエンジニアに特化した採用基準はあったりしますか？

古川：当社の場合はフルスタック寄りのフロントエンドエンジニアを採用しています。 リクルートにおいてフロントエンドエンジニアは、HTML、CSS、JSを触るだけの人ではないんですよ。裏側のNode.jsも見なければいけませんし、そこからバックエンドのAPIを叩くのでAPIにも詳しくなければいけません。 一方でインフラをどうするのかにも口を出してほしい。さらにデザインや企画の領域で、何をやりたくてどう進めたいのかをやり取りする必要もあります。 もともとフロントはコミュニケーションのハブとなることが多いのですが、当社の場合は全般的に何でもしなければならないので、フルスタック的な能力が求められるんです。

井原：インフラエンジニアよりも求められる条件が広い感じですね。 フロントエンドエンジニアという枠で括りきれない感じがします。一方で本当にフロントしか触れない、という人も居るには居ますよね。

菅原：それならWebGLやWasmなどレアな技術を持っていて、その領域に関しては一番キツい作業を投げられても良いクオリティを出せますというくらいじゃないと今時スペシャリストじゃないかなと思います。 自分も含めそうでないので近接領域くらいは拾っておくべきと。

井原：林さんにはこんなフロントエンドエンジニアを採用したいという理想はありますか？

林：フロントエンドに限らずですが、採用したいという点で言えば技術よりもサービス理解がどれくらいあるか、あるいはどれくらい好きかということを一番重視しますね。本音を言えば、技術がそこそこでもサービスが好きな人ならいくらでも教えたいです。 逆にサービスに興味はないけどこの技術だけやりたいと言われても教える気にはならなくなります。飽きたらどこかへ行ってしまうんだろうなと思いますし。 私の場合は自社サービスに対して自前で最新機材を用意して、そこそこお金使ってます。もちろん真似をしろというわけではありませんが、それくらい私はサービスに入れ込んでいますし、だからこそ採用するのもサービスを愛してくれる人がいいです。

右側：古川　陽介さん 株式会社リクルートテクノロジーズ・グループマネージャー 左側：菅原　孝則さん STUDIO株式会社 技術顧問

優れたエンジニアは世にあるサービスとその設計を常にリサーチしている

井原：JavaScriptのエンジニアを採用するときに面接で設計力を知りたいと思ったらどうしますか？

古川：私は応募者の経験を深堀りする過程で、「こういうときはどうしますか」という想定外の質問をしますね。それに対してどこまでリアルに答えられるかを見ます。

林：例えばTwitterやSlackなど、SPAを利用しているサービスは多いと思うのですが、TwitterがどういうState設計で作られているのかすぐに想像できるエンジニアは非常に優秀です。 Slackなんかは最近Reactで作り直されていますが、それも瞬間的にState設計を想像できる、あるいはあのサービスを作ってくれと言われて作るイメージが湧くのなら、設計力はずば抜けていますよね。 そういう人はそもそも世の中のサービスがどうやって作られているのか興味を持って、常にリサーチしているんです。実際にSlackのStateを見に行くことはできますしね。

古川：私もTwitterは一度見たことがありますよ。ツイートするフォームの仕組みが面白かったです。打ち込んで何文字かはあえてReactでStateを回していて、ある程度バッファが出来たら流すという形にしていました。

井原：具体的なサービスに対して自分だったらどう設計するだろうという思考を常日頃から持って、実際にトライしてみると大きな学びになりますしね。

古川：そういうところに興味があるといいですよね。

何を学び、何にこだわるのかを見定めることでエンジニアとしてのレベルが上がる

井原：フロントエンドエンジニアが生き残っていくために、自分も含めたエンジニアの教育は非常に大事だと思うのですが、何をしていくべきなのでしょうか。

古川：ちゃんと勉強の時間を確保すべきですよね。軸を作るべきと再三お伝えしていますが、勉強するにしてもデザインならデザイン、パフォーマンスならパフォーマンスと、こだわりポイントを作った上でした方がいいでしょう。

井原：会社なら組織としてそういう学びの環境を用意するということですよね。 古川さんご自身としてはどんなことをしていますか？

古川：仕事としては今マネジメントなどをしているのですが、フロントエンドエンジニアとしてのプロ意識は絶対に忘れないようにしようと思っています。 決めているのは、毎日1つは何かしらにコミットすることですね。リクルート内部では、不備を改善していくことを常に意識しています。ReactにしろAngularにしろVue.jsにしろ、組み合わせで開発を進めると必ず不備が生まれるんです。 コンシューマードリブンの例で言えば、JSON Schemaが書きづらかったりもします。そういう負債を少しずつライブラリに書いて改善するといったことを行なっています。

菅原：人の成長という視点から言えば、自分で考えて試しに作って、フィードバックをもらってまた作るというサイクルをどれだけ数多くこなせるかというだけの話ではあります。マネジメント側もしっかりオーナーシップを渡して、失敗する機会を与えてあげればいいだけです。 フロントエンドエンジニアという部分に限って言うなら、この領域はユーザーの触り心地を左右する最後の砦だと自覚を促すことです。だから私はひたすらダメ出しします。ここフレームレート落ちてるぞ、60FPSにしないとダメだと注文をつける。ユーザーがプロダクトに触れたときにどういう気持ちや感覚を抱くのか、意識をしっかり植え付ける感じですね。

井原：自分自身で心がけていることは何ですか？

菅原：何も考えない場合は最低60fpsを出すことです。そのためなら技術選定から変えます。と言っても重視しているのは速さよりも気持ち良さで、遅くても演出で結果心地よければいいんですよね。誤魔化し方はいろいろありますから。

井原：林さんはいかがですか？

林：フロントエンドエンジニアとしてプロフェッショナルでいたいと思うのなら、デザイン視点は必須だと思います。菅原さんもおっしゃっていましたが、ユーザー体験の最後の砦がフロントエンドです。例えばデザイナーがデザインしきれない非機能要件であったり、エラー発生時にどういうメッセージをどのタイミングでどこに出すのかといったデザインで漏れがちな部分を考えようと思ったら、デザイン経験の有無が非常に大きな要素になります。自分でデザインしたものを人に触ってもらうという経験です。トライしてみても最初はきっと上手くいきませんし、操作性やレスポンスが悪いと言われます。でもそこで初めてエンジニアとして一段階レベルアップするのではないでしょうか。

井原：教育という意味ではいかがでしょうか。

林：自社サービスをリデザインしてみるのがおすすめです。使いづらいところを直して、それを実際にメンバーに見てもらう。 自社サービスなら社内でフィードバックしやすいですし、各エンジニアにデザインを上げてもらい、投票してみてもいいと思いますよ。

最後の懇親会では、今回のイベントのPMのFLEXY若色と共に記念に写真を取っていただきました！ご登壇有難うございました！

企画/編集：FLEXY編集部