会社活動

PHPを使う成長するサービスにおけるエンジニア採用の視点

BASEは、昨年末のメルカリ社との関係性が高まったことを期に改めて採用を強めている。中心となるのは、強力に事業を推進するところにコミットしてくれるエンジニアの募集だ。

先日、リブセンスの桂さんに当社にお越しいただいて、結構ハードな対談を収録した。

BASEえふしん×リブセンス桂 CTO対談（前編）―今求められるエンジニアは、自分の会社から「はみ出ている人」―

桂さん、バシバシ、突っ込んでくるもんだからついついハードな発言をしているかもしれない。

最近、思っているのがどうやってPHPを扱う会社で優れた人材に来ていただけるか？という部分。

PHPは、多分、今も昔も中心なんだか周縁なんだかわからない立ち位置にいる。PHPをPHP市場だけで捉えると、高トラフィックなサービスを経験するという、「良い経験をしてきたエンジニア」は、藤本さんところのグリー社、グリー出身者、最初からPHPを活用していたYahoo!社などがパワフルな経験をしているエンジニアのターゲットになる。自ら起業しながらも、それら全ての会社を経験してきたメルカリのCTOのSotarok氏が理想的なタイプと言えよう。

しかし、それだけでなく他の言語からのスイッチ組も期待している。PHP自体の言語仕様は決して難しくないのだから、どの言語であろうとWebプログラミングに精通した人に興味さえ持ってもらえれば、PHPでサービスをガシガシ作るのも難しくないだろう、という考え方だ。Perlでがっつりやってきた会社などは、PerlとPHPは似ている部分が多いと思っているし、どっちも人気のピークを超えたことによるジレンマを持っている言語で、そこにコミットしてきている人は非常に好印象である。

ー・ー

現状、若いスタートアップ層は、Ruby on Railsを扱っている人たちが多い印象を持っている。それであれば、技術者としての成長はRailsで過ごすことになる。
例えば22歳ぐらいからWebプログラミングを始めて、一人前になるまで4〜5年をどういう言語で業務に集中するか？と考えると、最初にRailsを始めた人が次のプログラミング言語にいくとしても27〜28歳ぐらいが適切ではないだろうか。

逆に言えば、この時期にころころ言語を変えて一からやりおすのは得策ではないとも考えられる。（あ、その人のスペックが超高ければ、この辺の話は適用されない話です。例えばGunosy社の松本さんみたいな人とかですかね。）

Ruby言語からC言語体系のPHPにいくのは、文法的に若干、面倒くさい方向に行くことになるので、もう少し別の言語を経験しても良いのかもしれない、などとも思ったり思わなかったり。でも、Objective-Cは相当面倒くさかったけど、ベネフィットが高かったので沢山書いてる人がいることを考えると、やっぱり実現するもので素敵な成果を残せるか？というのが一番大事なのだろう。

そんなことを考えながら、今、PHPで良いエンジニアを採ろうとすると、やっぱり30代になるのかなと思っていたりする。それは、単純にオッサンというわけではなく、それなりに多数の言語や、言語の栄枯盛衰などを経験して、開発言語の良し悪しだけにこだわらずに、肩の力を抜いて、Webのサービスや、Webのテクノロジを俯瞰して見えるようになるのが、20代後半から30代前半になるのではないか？という考え方だ。

ー・ー

開発言語に関わらず重要なのが、やっぱり高トラフィックでヒーヒー言った経験だ。最近は、お金さえあればAWSのインスタンスのスペックを上げることで、簡単にスケールアップできてしまうので、効率の悪いプログラムをカリカリにチューンすることなく、富豪的に解決することで、それなりの性能を得てしまうこともあるのでよくわからなくなっているが、それでも、いろんな人に話を聞いていると、ソーシャルゲームなどのリアルタイム性の高いサービスが成功すると尋常でなないトラフィックに巻き込まれ、数撃ちゃ当たるゲームの世界で、作品が成功してしまったが故に、徹夜でデータベースの負荷対策に対処する話などを聞いたりするので、やっぱり、そんなに簡単ではないと考えられる。

とにかく目の前のコードを、どうにかトラフィック要求に合わせこむというアプローチにおいて、O/Rマッパーが無駄なんじゃないか？と考えた経験や、既存のフレームワークを壊してでも立ち向かった経験をしてきた人は、今どきのオープンソースのフルスタックのフレームワークは、特定の価値観に基き、マーケティングも伴った「プロダクト」であった、ということを知ることになる。

それ故に、Railsにコミットするならとことんコミットしなくてはいけなくて、カジュアルかつ中途半端に付き合うと数年後の更新のコストが取れずにサービスが継続できない、なんて話がでてきたりする。

トラフィックが高いサイトにおいては、DBにアクセスしたら負けかな、みたいなケースも出てきて、そうなると構造化されたフレームワークをハックして挙動を変え始めて、どこか本末転倒感を抱き始めるとかが大切な経験だったりする。そういう視野と、そういう視野での改善方法を知っていることが何よりも重要だという話になる。

つまり、そこに言語仕様やフレームワークの良し悪しなどはほとんど関係なく、むしろどれだけコードをシンプルにし、HTTPプロトコル、ApacheやDBなどのミドルウエア、メモリやディスクI/Oを効率的に回すか？というレイヤーで物事を考えるようになる。

そのような経験を通ると、言語やフレームワークは一つの実装手段にしか見えなくなる。そこまで見えてきたエンジニアであれば、きっとPHPでそれなりに回っていて、その次の展開に人が足りなくてサービスに対して、ポジティブな目線で見てくれるんじゃないかな？なんて思ったりもしていて、そういう人を探すというのが、今の僕の仕事だ。

ー・ー

AWSに囲い込まれる文脈とRailsに囲い込まれる文脈は多分似ていて、どちらも作り手からするとすごく羨ましい状況だ。僕らもAWSをフル活用してサービスを運用しているが、もう少しプリミティブなレイヤーの方がいいんじゃないか？と葛藤を覚えることも少なくはない。しかし、そうは簡単にAWSから離れるのはできなくなってしまっている。例えば、メールひとつ送るのも、今更postfixですか？みたいな話になってしまう。postfixが当たり前の人から言わせれば、軟弱者という話だと思うが、クラウド、フレームワークの時代というのはそういうものだと思う。

こういったサービスは、１レイヤー上に利用者を持ち上げることで、スイッチングコストを高めてしまう。下のレイヤーとは、世界観や見えている世界が違うので、そこでお互いが相容れない場合は、もう手も足も出ない。しかし、いくらかの割合でマトリックスの世界から脱出してくる人も必ずいると思うので、そういう視座を持っている人とお知り合いになるというのが、今の時代のPHPを操る会社においての採用戦略としては、非常に重要なポイントであったりする。

そして、少なからずエンジニアは最新技術を使いたいと思うものだと思うので、そこを昔からある言語にスイッチしてもらうのにあたって事業の魅力は不可欠である。具体的にはグルーとしての言語に捕らわれるのではなく、コアにあるサービスの思想をどうやって技術で解決するか？という部分は、出来る限り面接の時に言っているような気がする。

ー・ー

BASEはCakePhP, PAY.JPはPythonに、FlaskやPyramidなどを組み合わせている。別にこの先も単一の言語に依存していくつもりはさらさらないが、もはや、そんな簡単に言語などを変更できる規模ではないので、この道を維持していくのが現実解として正しい。それでも次世代アーキテクチャの検討をするにあたって、他の言語技術を導入したり模索したいわけだが、両方の技術、現状のプロダクトの実装を理解してる人がいないと、ほいほい新しい技術を導入するのも難しいわけで、将来は何もお約束できませんが、アナタ次第で未来は変えられますし、是非暴れてください、というのが現状の状況だと思っている。

おそらく合理的な判断をすれば、カルチャーフィットを重視している以上、大体、僕らと同じような結論にしちゃうであろうと思うが、それが故にチャレンジできない組織になるのは最悪なので、人それぞれ、振れ幅はあったほうが良いかなと思っています。

【PR】BASE株式会社 17職種、仲間を絶賛募集中！