「HadoopやRedshiftが使えて、数字を分析できる人」 スタートアップのCTOがいま一番欲しいエンジニアとは

アプリもサーバも全部作り変えているところ

今井雄太氏（以下、今井）：ではここまで皆様、サービスの現在の環境、そこに対してだんだんたまってくる不満とか改善したい点っていうのをお伺いしてきました。

ここから先は完全に仮定の話も含んでくるんですが、誰もが1回は考える「ガラッと作りかえられるとしたら？　もしくは作り変えたことありますか？」。

あと「作り変えようと思ったけどやっぱりやめた、ちゃんと検討してやらないほうがいいという判断をした」とかですね。そのへんについてもしエピソードがあればお伺いしたいなと思いますが。

これはどなたか、もし「俺が」っていう方がいらっしゃれば。高橋さん、話したそうだね。

高橋三徳氏（以下、高橋）：作り変えたいというか、いままさに作り変えていて、アプリもサーバも全部作り変えようと思ってます。横路さんのお話にもあったように、うちもマイクロサービス的に機能単位で絞ってサービスを作っていて、今その単位でチームを作ろうとしているところで。

アプリはもう本当に書き直さないといけないので、そこは今、死に物狂いでエンジニアをやっています。

今井：お忙しい問題です。

高橋：大変だなって。そうですね

今井：その作り変えにあたってすごい困ってるとか、そういうエピソードって何かあったりしますか？

高橋：設計思想とかコアな設計は、皆で決めるよりやっぱり1人に集中しちゃうなというところがあって、iOSをやっているリーダー的な人が主に設計をしてやってるんですけども、ちょっといろいろあって、いろんなプロジェクトが同時に動いちゃってその人がフン詰まってるっていう感じですね。そこが中々つらいなというとこです。

今井：ありがとうございます。これは多分次のディスカッションのテーマにもちょっと関連するかなと思うんですが、基本的にボトムアップというか、現場に権限・裁量を与えて、設計とか任せたほうがいいケースが多いんじゃないか？　って話があったんですが。

今のケースだと設計は実際の現場の人に任せて、それはチームとしてレビューするとかどういうポジションを持って行くプロセスがあるんでしょうか？

高橋：レガシーコード書いた原因は僕だったりするので、僕がやるのはよくないなっていうところですね。スペシャリストが入ってくれたので彼をメインに。

ただ同時に走っちゃうのはなかなか難しいので、ボトムアップする方向でレビューを細かくしながらやってるっていう状況ですね。だんだん皆慣れてくるので、レクチャーがどんどん少なくなっていくっていう状況です。

今井：ありがとうございます。

容赦ない毎年のアップデートで書き直す、何千ものコード

今井：今村さんいかがですか？　PHPからRailsに切り替えたっていうお話もありましたけど。

今村雅幸氏（以下、今村）：サーバ側は、やっぱりエンジニアってどんな言語を書くかによってモチベーションが左右されたり、今だったら「こう書きたいんですけど」とかって結構いると思うんですけど、そういうの意外と大事だなっていうのがあって。

ちょうど、1番初め立ち上げたときに、前職で書いたフレームワークをそのままで作ったんですけど、やっぱりどうせ転職してくるんだったら「違う言語書きたい」みたいな熱い奴が多かったのでRubyに変えたっていうのがありますし。

実際Webのアプリケーション言語ってほとんど同じようなところがあって、そこであんまり皆嫌がらずに書いたっていうのはありますよね。

Web側は何とかなるんですけど、僕らはアプリのほうも結構力入ってるんで、例えばAndroidアプリとiOSアプリと、もう今とんでもない膨大なソースコード量になっていて。AppleとGoogleは毎年毎年容赦ない感じで、SDKを丸ごとアップデートしてくるんで。

そうなってくると今までiPhoneだったらデバイスが2種類しかなかったりiPadだって1種類しかなかったんですけど、もう今意味わかんないくらいのサイズがでてきて、そもそもタブレット対応してないとダメですよとか、あとiPhoneだったらオートレイアウト対応とか。

しかもさっきのビューコントロールの話じゃないですけど、そもそも設計を全部変えないと何千というコードを全部書き直すようにならないといけなくなって。でもやらないとやっぱり、例えばAndroidで対応しないと明らかにもう周りのアプリの見栄えが変わっていって。

Webだったらあんまり見れないんですけど、アプリだったら明らかに対応してないとわかっちゃうじゃないですか。

そうなってくると、せっかくいいアプリ作っても意味がないのでそこはもう無理矢理プロジェクトを切ってタスクフォース組んで今回は一気に対応します、ってやったりしてますね。

そこはもう意地で、コースを隔離してやってます。

高橋：Swift（iOS・OS Xプログラミング言語）とかって？

今村：Swiftは、やっぱり現場も書きたいって思う瞬間はあるんですけど、さすがに今全部書き直すのはほぼ不可能なんで。ウォッチ対応とか、結局できるところからだけやるようにしました。

今井：ありがとうございます。僕自身がもともとサーバサイドのエンジニアだったので、結構サーバサイドの言語の切り替えとかってすっごい大変な話だなって思っちゃうんですが。

今聞いたお2人はやっぱりサーバサイド側はあんまり言語の切り替えとか、アーキテクチャの切り替えにそれほど大きな苦労はしていなくて、どちらかというとクライアントサイド。

まずスピードを持って作ったもののところに負債がたまっていって、それをどうするかっていうお話だったのかなと、お2人にお伺いして思いました。

インフラエンジニアの役割が変わってきている

今井：ではこちらのお2人にお伺いしていきたいんですが、横路さんからお願いできますか？

横路隆氏（以下、横路）：freeeではエンジニアが30名に増えて、しかも会計についてはもうかなり大きなモノリシックシステムになってしまっているので、今スクラッチから作り変えるのは結構難しいし、そこまで価値を生まないかなと思ってて。

その代わりに機能ごとにチームを分けて、アーキテクチャも完全には分けられないんですけどそこも分けていって。

それにあたって今インフラエンジニアが30名のうち2名なんですけど、各機能ごとに要件があったとき、例えば「OCRやりたい」って言ったらOCRサービスを動かすサーバを立てるとか、そういった要求に逐次対応してるんですけど、実はそういうのって今後はアプリケーションエンジニアの仕事なんじゃないかなっていうのがあるので。

どっちかっていうとインフラエンジニアは、各ファンクションごとのアプリケーションエンジニアが運用まで含めて見られるように、社内サービスの依存関係の解決をサポートする簡易社内PaaSのようなものを提供できるチームにして行きたいなっていうのはありますね。

それについては課題も多いし、やることは山積みなので、そういうのは数年かけてやっていきたいなと思います。

今井：ありがとうございます。今インフラエンジニアの役割が変わってきてるっていうのすごいおもしろいお話だったのかなと思ったんですが、これから作られるっていうお話ですけど、簡易社内PaaSって例えばどんな機能ですか？　

横路：例えば、課金と認証サービスっていうのはどのサービスからでも叩かれるんですけど、そういったものをうまく抽象化して、ただ入れるだけで使えるとか、ボタン一発で他の依存システムを上手く起動して利用できるようにするとか、簡素なHerokuプラグインみたいな感じで社内の他のシステムを使えるイメージです。

今井：ありがとうございます、すごくイメージがつきました。

メンテナンスの時間が難しいカップル達の事情

今井：では椎名さんお願いできますか？

椎名アマド氏（以下、椎名）：さっき結構ネイティブの話をしたんで、ここはサーバっていうかバックエンドの話なんですけど、うちは1番最初は全部EC2インスタンス1台だけでやっていました。その中にMySQL置いてて、そのあとMySQLをEC2インスタンスにして、それからRedisも別でEC2立ててみたいな。そこから今度はMySQLをRDSに変えた。

そのあとRedisの中身が肥大化していって、今度はRedisの中のチャットデータをDynamoDBに移管しました。バックエンド、結構コロコロ最近変えてるんですね。それは僕らとしてはやっぱりEC2自分らでやるよりAWSさんのマネージドのサービスに乗っかったほうが、人件費やセキュリティなどいろんな面で効率的だなって思ったからですね。

これからも多分それは続いていきます。、直近ではAuroraとかの様子は見ていたりして。もし、今プレビュー版ですけれど本リリースで結構いい感じだったら、それはもはやRDSのから乗り換えたいなっていう思いとかはあります。

ただそういうのにあたって悩みになってくるのは、特にマスターデータベースを定期メンテだとしても、うちのサービスって全然落とせないんですよね。朝4時に5分メンテするとか言っても、朝4時ってカップルによってはお互いベッドの中で「会いたい」ってチャットを送り合ってる時間なので。

（会場笑）

そのタイミングでPairyの代わりにLINEで送り合って、そのままユーザーが戻ってこない、なんて可能性もある。だから結構そこらへんがシビアで、バックエンドを考えるにあたって、いつメンテをしていいとか、絶対にしちゃダメとか、課題になってますね。

今井：クリティカルですね、ミッションクリティカル（笑）。平日の午前中とか、ダメなんですか？

椎名：うーん、ギリですね。そういうときも「今夜何時に待ち合わせる？」みたいな会話があったり。カップルにとってのコミュニケーションインフラになっている限りはどの時間でもすごく慎重に考えないといけないです。

今井：ありがとうございます。結構この質問、何かわりとガラッとっていうのが最初にあってわりと「ビッグバン的にドーンと取り換えた」みたいなエピソードが出てくるかな、もしくは「考えたけどそんなん絶対できない」みたいな話が出てくるかなと思ったんですが、結構皆さんサービスとかライブラリをすごく小さく管理されていて。

サーバ側・もしくはサーバ側の一部から切り替えて行くとか、アプリのネイティブ側のコードの問題はあるにせよ、キレイにコンポーネント化していて、そのおかげでシステムのアーキテクチャ的な柔軟性はすごく高い運用されているのかなというのが私の感想です。

各社それぞれの技術環境や負債への取り組み

今井：ちょうどご用意した質問というのは以上です。ラップアップしますと3件ですね。

皆様の今運用されているサービス自体のご紹介とその技術的な関係ですね。主に言語とフレームワーク等のお話をいただきました。このときは主にスタートアップする時に「人をいかに集めやすいか」もしくは「学習コストがいかに低いか」みたいなところが皆様の選定の背景だったのかなと思います。

次、今の環境への不満や改善したい点を教えて下さいということで、いわゆる技術的負債みたいなところに、今の質問を設定させていただいたんですが、ここに関して言いますと、今回特に目立ったのはネイティブアプリ側ですね。

特にここがやっぱり人のイシューというか、人の問題といっちゃあれですけど、そのチームとしての課題みたいなところが見えてきたのかなと思っていて。

ネイティブアプリは最初人とかすごい少ない人数で開発を始めてしまうので、それによってパートナーのコントローラーとかリファクターが必要な大きなアプリケーションができ上がってしまうっていうのが、ここで出てきた出来事になってきたお話だったのかなって思います。

一方Freeeさん、横路さんのケースだとサーバ側のアーキテクチャをマイクロアーキテクチャみたいなかたちにされ切って。あと高橋さん、SpotLightさんですね、マイクロアーキテクチャみたいな感じになっていると、サーバ側の構成変更みたいなことはすごく柔軟にできてきているのかなというのが感じたことです。

「ガラッとやったことありますか、やりたいですか？　・やりたくないですか？」という最後の質問に対しては、結構柔軟になってるんでそもそもガラッとってあんまりないよね、みたいなのがここで見えてきたお話かなと思います。

AWSクラウドからオンプレミスに移行した決定打は？

今井：お時間あと6分半くらいあります。会場の皆様から、4人の皆様に質問があればお受けしたいと思います。いかがでしょうか？

質問者：どうもありがとうございます。高橋さんに聞きたいんですけど、オンプレ行く前はAWSのを使ってたと思うんですけど、オンプレ行くぞみたいな、決定打になったっていう理由があれば教えてください。

高橋：そうですね、1番はスパイクするのはテレビ砲なんですけど、どうしてもDBのスケールアップが必要で、戻してっていうのをやるのがすごい苦になったっていうのがあってですね。あとインフラに詳しい人間がその時入ったっていうのもあって、ご存知の方だと思うんですけど、そこにお任せできたっていうのも「これはやろう」っていう感じです。

質問者：ありがとうございます。

今井：大丈夫でしょうか？　お答えになってますか？　ありがとうございます。

今インフラできる人がっていうQ&Aありましたけど、やっぱりチームとか人に依存する部分ってすごい多いのかなあと思いつつ、私たちも営業の努力がまだ足りていないっていうのもあるのかなと思いました（笑）。反省しました。

今採用したいエンジニアの人材像・スキルセットは？

今井：他に、何かご質問ありますか？

質問者：皆さんにお伺いしたいんですけど、直近でエンジニア・技術者を採用するとしたら、1番欲しいエンジニアってどういう方か？　っていうのをお願いします。

今井：直近で欲しいエンジニアの人材像とかスキルセットですね。どなたかお答え、ご意見ある方っていらっしゃいますか？

今村：僕らが今直近で1番欲しいのはデータ周りに強いエンジニアですかね。やっぱりRedshiftだったりとか、僕らも使わせてもらってたりするんですけど、そこから何を見い出せるか？　っていうところまで、ちゃんと考えてそれをサービスの価値に落とせる。ちゃんとデータから何か価値を見いだせる人。

データサイエンティストって言ってしまえばすごい一括りで楽なんですけど、そういう人ってなかなかいない。今ソーシャルゲーム業界とかに結構いると思うんですけど、そういう人たちが僕らの業界にも興味持ってくれるといいなっていうところが今僕らの課題であって。

Webのエンジニアだったりアプリケーションのエンジニアってすごいたくさんいるんですけど、僕もこの界隈にはすごい少ないと思うんで、そういう人が入ってくれると嬉しいなっていうところはありますね。

今井：それはやっぱりエンジニアでAWSならRedshift、あとHadoopとか、そのへんが使えつつ数字も読めるみたいな、両方できる人。

今村：そうですね。自分が分析したい数値の環境を自分で構築できるし、自分で分析もちゃんとできるっていうところ。スタートアップにはそれ1人でできるっていうエンジニアが欲しい人材っていうのが僕らも含めてありますけど。

今井：ありがとうございます。

欲しいのは「T字型スキル」を持ったエンジニア

今井：他のお3方はいかがですか？　じゃあ椎名さん。

椎名：僕らはさっき言ったようにまだ5、6人の少数なんで、次に欲しい人間っていうのは、やっぱり汎用性のあるスキルを持った人。サーバサイドも、ネイティブサイドも両方ともある程度出来る。

よく言われる話でT字型スキルみたいなものを考えています。1つの分野は突出してるけど、ちゃんと広くオールラウンドで、常にベースアップに近いかたちの成長ができるエンジニアが欲しいなと思ってます。

その裏にあるのは僕らスクラムを最近きちんと導入しているということがあって。

スクラムっていうのは、1つのユーザーストーリーに対して、そのユーザーストーリーをチームでこなすために何をするかを全員が協力して考えることで、「いや僕ネイティブしかできないから、このストーリーのネイティブのタスクだけ終わったからもういいや」という考え方にならずに、そのストーリーを解決するためにサーバのタスクがあるんだったらだったらサーバをやる。

ネイティブだったらネイティブやる。そんなふうに「皆でストーリーをこなす」っていう大きなミッションに向けて動ける。そんなチームにして行きたいなっていう思いがあるんですね。

今井：ありがとうございます。

ビジネス要求の進化にスピーディに対応できる人材

横路：freeeではアプリケーションエンジニアとインフラエンジニア、両方を募集してるんですけど、アプリケーションエンジニアでいうと、まずサービスとかプロダクトにコミットしてユーザに価値を届ける意思があって、それでインフラ以外は全部できる人っていうのを求めています。

今後ビジネス要求がどんどん進化していって、例えば「海外展開するぞ」ってなって今のアーキテクチャじゃダメだねってなったときに、またチームがガラッと変わったとしても、アプリケーションエンジニアは皆そのチームで高速キャッチアップ＆高速リリースしていけるっていうのを実現するために、そういう人を求めています。

あとインフラでいうとミッションクリティカルなサービスですので、サービスを落とさないことにエクスタシーを感じるというか、そういったインフラの方を求めています。

今井：ありがとうございます。高橋さん。

高橋：うち楽天グループなんで英語しゃべれるエンジニアが。

（会場笑）

高橋：嘘です（笑）。うち英語はいりませんけど、iOSとかAndroidのエンジニアが欲しいなと思ってます。

今井：ありがとうございます。お答えになってますでしょうか？　ちょうどお時間になりましたので、まだご質問ある方もしかしたらいらっしゃるかもしれませんが、パーティのときとか、個別にお声掛けいただければと思います。それでは最後、4人の皆様に拍手をお願いできればと思います。どうもありがとうございました。