01:49会社活動PHPを使う成長するサービスにおけるエンジニア採用の視点ツイートBASEは、昨年末のメルカリ社との関係性が高まったことを期に改めて採用を強めている。中心となるのは、強力に事業を推進するところにコミットしてくれるエンジニアの募集だ。先日、リブセンスの桂さんに当社にお越しいただいて、結構ハードな対談を収録した。桂さん、バシバシ、突っ込んでくるもんだからついついハードな発言をしているかもしれない。最近、思っているのがどうやってPHPを扱う会社で優れた人材に来ていただけるか?という部分。PHPは、多分、今も昔も中心なんだか周縁なんだかわからない立ち位置にいる。PHPをPHP市場だけで捉えると、高トラフィックなサービスを経験するという、「良い経験をしてきたエンジニア」は、藤本さんところのグリー社、グリー出身者、最初からPHPを活用していたYahoo!社などがパワフルな経験をしているエンジニアのターゲットになる。自ら起業しながらも、それら全ての会社を経験してきたメルカリのCTOのSotarok氏が理想的なタイプと言えよう。それだけでなく他の言語からのスイッチ組も期待している。PHP自体の言語仕様は決して難しくないのだから、どの言語であろうとWebプログラミングに精通した人に興味さえ持ってもらえれば、PHPでサービスをガシガシ作るのも難しくないだろう、という考え方だ。Railsを扱っている人たちが多い印象を持っている。それであれば、技術者としての成長はRailsで過ごすことになる。22歳ぐらいからWebプログラミングを始めて、一人前になるまで4〜5年をどういう言語で業務に集中するか?と考えると、最初にRailsを始めた人が次のプログラミング言語にいくとしても27〜28歳ぐらいが適切ではないだろうか。逆に言えば、この時期にころころ言語を変えて一からやりおすのは得策ではないとも考えられる。(あ、その人のスペックが超高ければ、この辺の話は適用されない話です。Gunosy社の松本さんみたいな人とかですかね。)Ruby言語からC言語体系のPHPにいくのは、文法的に若干、面倒くさい方向に行くことになるので、もう少し別の言語を経験しても良いのかもしれない、などとも思ったり思わなかったり。Objective-Cは相当面倒くさかったけど、ベネフィットが高かったので沢山書いてる人がいることを考えると、やっぱり実現するもので素敵な成果を残せるか?というのが一番大事なのだろう。そんなことを考えながら、今、PHPで良いエンジニアを採ろうとすると、やっぱり30代になるのかなと思っていたりする。関わらず重要なのが、やっぱり高トラフィックでヒーヒー言った経験だ。最近は、お金さえあればAWSのインスタンスのスペックを上げることで、簡単にスケールアップできてしまうので、効率の悪いプログラムをカリカリにチューンすることなく、富豪的に解決することで、それなりの性能を得てしまうこともあるのでよくわからなくなっているが、それでも、いろんな人に話を聞いていると、ソーシャルゲームなどのリアルタイム性の高いサービスが成功すると尋常でないトラフィックに巻き込まれ、数撃たないと当たらない開発スピードが求められるゲームの世界で、作品が成功してしまったが故に、徹夜でデータベースの負荷対策に対処する話などを聞いたりするので、やっぱり、そんなに簡単な話ではないと考えられる。目の前のコードを、どうにかトラフィック要求に合わせこむというアプローチにおいて、O/Rマッパーが無駄なんじゃないか?と考えた経験や、既存のフレームワークを壊してでも立ち向かった経験をしてきた人は、今どきのオープンソースのフルスタックのフレームワークは、特定の価値観に基き、マーケティングも伴った「プロダクト」であった、ということを知ることになる。それ故に、Railsにコミットするならとことんコミットしなくてはいけなくて、カジュアルかつ中途半端に付き合うと数年後の更新のコストが取れずにサービスが継続できない、なんて話がでてきたりする。トラフィックが高いサイトにおいては、DBにアクセスしたら負けかな、みたいなケースも出てきて、そうなると構造化されたフレームワークをハックして挙動を変え始めて、どこか本末転倒感を抱き始めるとかが大切な経験だったりする。いう視野と、そういう視野での改善方法を知っていることが何よりも重要だという話になる。そこに言語仕様やフレームワークの良し悪しなどはほとんど関係なく、むしろどれだけコードをシンプルにし、HTTPプロトコル、ApacheやDBなどのミドルウエア、メモリやディスクI/Oを効率的に回すか?というレイヤーで物事を考えるようになる。そのような経験を通ると、言語やフレームワークは一つの実装手段にしか見えなくなる。そこまで見えてきたエンジニアであれば、きっとPHPでそれなりに回っていて、その次の展開に人が足りなくてサービスに対して、ポジティブな目線で見てくれるんじゃないかな?なんて思ったりもしていて、そういう人を探すというのが、今の僕の仕事だ。ー・ーAWSに囲い込まれる文脈とRailsに囲い込まれる文脈は多分似ていて、どちらも作り手からするとすごく羨ましい状況だ。僕らもAWSをフル活用してサービスを運用しているが、もう少しプリミティブなレイヤーの方がいいんじゃないか?と葛藤を覚えることも少なくはない。簡単にAWSから離れるのはできなくなってしまっている。メールひとつ送るのも、今更postfixですか?みたいな話になってしまう。postfixが当たり前の人から言わせれば、軟弱者という話だと思うが、クラウド、フレームワークの時代というのはそういうものだと思う。いったサービスは、1レイヤー上に利用者を持ち上げることで、スイッチングコストを高めてしまう。下のレイヤーとは、世界観や見えている世界が違うので、そこでお互いが相容れない場合は、もう手も足も出ない。いくらかの割合でマトリックスの世界から脱出してくる人も必ずいると思うので、そういう視座を持っている人とお知り合いになるというのが、今の時代のPHPを操る会社においての採用戦略としては、非常に重要なポイントであったりする。少なからずエンジニアは最新技術を使いたいと思うものだと思うので、そこを昔からある言語にスイッチしてもらうのにあたって事業の魅力は不可欠である。具体的にはグルーとしての言語に捕らわれるのではなく、コアにあるサービスの思想をどうやって技術で解決するか?という部分は、出来る限り面接の時に言っているつもりだ。そこに共感いただければこそ、「言語にこだわらない」という判断ができるものと考える。PAY.JPはPythonに、FlaskやPyramidなどを組み合わせている。別にこの先も単一の言語に依存していくつもりはさらさらないが、もはや、そんな簡単に言語などを変更できる規模ではないので、この道を維持していくのが現実解として正しい。それでも次世代アーキテクチャの検討をするにあたって、他の言語技術を導入したり模索したいわけだが、両方の技術、現状のプロダクトの実装を理解してる人がいないと、ほいほい新しい技術を導入するのも難しいわけで、将来は何もお約束できませんが、アナタ次第で未来は変えられますし、是非暴れてください、というのが現状の状況だと思っている。合理的な判断をすれば、カルチャーフィットを重視している以上、大体、僕らと同じような結論にしちゃう人だけがジョインすることになると思うが、それが故に同一方面の視点に偏ってチャレンジできない組織になるのは最悪なので、人それぞれ、振れ幅はあったほうが良いかなと思っています。Garageは、Webを中心としたビジネス&テクノロジーに関する思いつきを綴ったブログです。初代モバツイ開発者インターネットと日常の生活が融合された「何か楽しいもの」/「便利なもの」を作ることを目標に活動中。Fujikawa(@fshin2000)。