FIVE Inc. / ファイブ株式会社 | FIVE エンジニア座談会
18027
page-template,page-template-full_width,page-template-full_width-php,page,page-id-18027,page-child,parent-pageid-26,ajax_fade,page_not_loaded,,side_area_uncovered_from_content,qode_popup_menu_push_text_top,qode-theme-ver-9.0,wpb-js-composer js-comp-ver-4.11.1,vc_responsive
 

FIVE エンジニア座談会

FIVEのエンジニアリングチームが圧倒的なスピードで成長を実現する
スタートアップとしての開発思想を語りました。
2015年に入社したソフトウェアエンジニアの佐藤を主な聞き手として、
小西、松本、類地の4人での座談会です。

FIVEのエンジニアリングチームが圧倒的なスピードで成長を実現するスタートアップとしての開発思想を語りました。2015年に入社したソフトウェアエンジニアの佐藤を主な聞き手として、小西、松本、類地の4人での座談会です。

聞き手:佐藤 喬之 Software Engineer
2009年大阪大学大学院生物科学科修了後、ヤフー株式会社、グリー株式会社を経てGlossom株式会社に入社。広告配信システムの開発及び最適化、ビッグデータ分析やアプリ開発等に従事し、2015年にFIVEへ参画。
小西 祐介 Co-founder, CTO
東京大学大学院修士課程にてコンピューターサイエンスを修了後、2009年に Google Japan に入社。Google Play、Android、Google ショッピングのエンジニアリング、製品開発を担当。2014 年にFIVE を設立。ICPC や TopCoder Open など、国内外のプログラミングコンテストで多数入賞。IPSJ Science Research Award for Young Scientists 受賞。
松本 大介 Co-founder, VP of Engineering
東京工業大学大学院修士課程にてコンピューターサイエンスを修了。ワークスアプリケーションズの研究開発部門にて関数型プログラミング言語 Haskell によるオープンソースプロダクトの開発を担当し、同社の技術力向上に貢献。その後、広告関連のスタートアップにてリードエンジニアとして動画広告DSPおよび配信アルゴリズムを開発。2014年にFIVEを設立。
類地 孝介 Software Engineer
2010年東京工業大学大学院修士課程修了。株式会社オルトプラスの創業、東証一部上場、ベトナム支社の設立に関わり、サーバサイドの開発、運用、継続拡張、最適化を行う。2016年にFIVEへ参加。関数型言語Haskellを好む。
聞き手:佐藤 喬之
Software Engineer
2009年大阪大学大学院生物科学科修了後、ヤフー株式会社、グリー株式会社を経てGlossom株式会社に入社。広告配信システムの開発及び最適化、ビッグデータ分析やアプリ開発等に従事し、2015年にFIVEへ参画。
小西 祐介
Co-founder, CTO
東京大学大学院修士課程にてコンピューターサイエンスを修了後、2009年に Google Japan に入社。Google Play、Android、Google ショッピングのエンジニアリング、製品開発を担当。2014 年にFIVE を設立。ICPC や TopCoder Open など、国内外のプログラミングコンテストで多数入賞。IPSJ Science Research Award for Young Scientists 受賞。
松本 大介
Co-founder, VP of Engineering
東京工業大学大学院修士課程修了。ワークスアプリケーションズにてオープンソースのAWS SDK Haskell バインディング等を開発。その後、広告関連のスタートアップにて、リードエンジニアとして動画広告DSPの配信システムおよびアルゴリズムを開発。2014年にFIVEを設立。
類地 孝介
Software Engineer
2010年東京工業大学大学院修士課程修了。株式会社オルトプラスの創業、東証一部上場、ベトナム支社の設立に関わり、サーバサイドの開発、運用、継続拡張、最適化を行う。2016年にFIVEへ参加。関数型言語Haskellを好む。
zadannkai_all

FIVE の開発環境について


佐藤
ということで、FIVEのエンジニアリングについて知ってもらおうというエンジニア座談会です。FIVE の開発の特徴や考え方を聞いていきたいと思います。
まず、FIVE の開発環境を教えてください。

小西
まず言語についてですが、サーバーはすべて Scalaで書いてます。Scalaを採用している理由は至ってシンプルで、 Twitter がオープンソースにしている Finagle というフレームワークが使いたかったからです。実は、それ以外にScalaを使いたい理由は特になくて、運用や他のライブラリとの親和性を考え、JavaっぽいScalaを書くようにみんな心がけてます。 データ構造は Thrift で、 ScroogeというScala 用のbindingを使っています。RPCライブラリとしてFinagle を使っていて、バックエンドのデータベースは高速なレスポンスが必要なところではRedis 、そうでないところはMySQLという構成です。 あとはLinux サーバ で nginx がフロントに立っていて、SDK は Android がJavaで、iOSがObjective-C ですね。

松本
ストレージは AWS S3 と Google Cloud Storage にログをためてて、今のところ BigQuery にデータを入れてキャンペーンのレポーティングとかデータ分析をやっています。

小西
もうすぐ Spark のバッチができる予定。

松本
もうすぐとは。

小西
本当だろうか、、、そんな感じです。

佐藤
BigQuery の採用理由ってなんだったんですか?使い始めたときから安定してた感じですか?

松本
Google の社内で実績があると伺っていますのでそこはまあ。

小西
ノーコメントでお願いします(笑)

佐藤
Finagle を使ってみたいと思った経緯は?日本で採用実績は多くないと思うのですが。

小西
Twitter で使われていて安定してトラフィックを捌いているという評判を聞いて、ですね。 あとは、Google とか Twitter とかシリコンバレーは人の流動性が高くて、あのへんの会社で使われている RPC ライブラリは割とよく似ているので、 Google出身の僕にはすごく使いやすかったというのが裏事情としてはあります。

佐藤
SDK側(フロントエンド)でどっちかっていうとモバイルの開発もできるエンジニアも大募集という状況だと思うのですが、SDK作っててどこが辛いとか気を付けてることとかっていうのを。

小西
SDKの難しい点は、サーバーと違って一度外に出しちゃうと気軽に置き換えができないので、慎重に作らないといけない点ですね。 アプリケーションを作ってるならいいんですけど、僕らはSDKを作っているので外部ライブラリをバインディングしたりできない。まぁやってもよいのですが、サイズが大きくなっちゃうのでしない方針でやっていて、とはいえ開発速度は落とさずにやるのがしんどいところですかね。 あとはアプリケーション側からSDKのAPIが任意のタイミングでぐっちゃぐちゃに呼ばれたとしてもクラッシュはしない、想定されてない使い道だったらその順番じゃないよみたいなエラーを返すとかが難しい。そうするとSDKが使いにくいみたいに聞こえるかな。

松本
でもそういうものじゃないですか?

小西
そうですね。

松本
ちゃんと想定された使い方をしないとSDKとかライブラリはちゃんとした動きができないっていう、それはそういうもんですよね。

小西
まあ想定されてない順番で叩かれても、一応どんな順番で叩かれてもアプリが落ちたりだとか想定外のステートに落ち込まないように注意して作ってるって感じですかね。 あとはパフォーマンス出すためにバックグラウンドスレッドを多用しているのでそのスレッドまわりのシンクロナイゼーションとかにすごく慎重に。

松本
気を使いますね。

小西
こんな話を聞いたら誰もやりたがらないか。

類地
まだギリギリ大丈夫だと思います(笑)

初期の設計思想とスケーラビリティ


佐藤
FIVEの動画広告配信システムでローディング時間を極小化する仕様や、サーバーサイドの通信と仕組み上工夫したところ、難しいところは。

小西
身も蓋もないですけど、それは営業秘密ですかね。色々なことをやっています。可能な限り、無駄な配信をしないように。広告キャンペーンの要件にしたがって、ユーザーへの負荷、デベロッパーやメディアの負荷が少なくなるようなコントロールはしています。

佐藤
規模感とかトラフィックはどうですか?創業初期から構成がほとんど変わってないと思うんですけど。

小西
フロントサーバーの台数って6台になったんだっけ?

松本
はい。最初の最初は2台から始めて、そのときもふつうにAWS EC2 に載せて ELBがフロントで受けて、それぞれのサーバーのnginx に振ってって感じですけれども。そこから基本は変わってないですね。

小西
開発優先のためにサーバーをコピーして並べたりはしたけれど、ちょっとするとじゃあキレイにしようかっていって間引いていく感じですね。

佐藤
スケールするにあたってどのへんがネックになりそうなんですかね?

小西
そういう意味でいうと、あまりネックになるようには作っていないです。

松本
まあデータベースがまず最初に詰まるっていうのが大体どのサービスでも同じだと思うんですけど、そのときにちゃんとスケールするようにできてるかって話ですかね。

小西
いまも一応シャーディングはできていて。

松本
一応キーごとにどのデータベースをひくかというのはロジックはある。ただし全部同じデータベースを引いている。

類地
データベースは Redis にはアトミックみたいのがあったと思うけどそういうのは使っていない?

松本
Thriftのバイナリをそのまま突っ込んでいるので Redis の機能ってあまり使えていないっていうのが正直なとこですね。Redis ってかなり高機能な Set とか使えてびっくりするんですけどね。例えば、O(log(N)) で Set の中の上から10個を取ってくるみたいのができちゃうんですけど、そういう高機能は使ってないんですよ。最悪ほかのデータベースに乗り換えられるようにも作ってあるし。

小西
創業したときになるべくスケールするように気をつけて作っていて、なおかつあまり難しい機能使いすぎるとスケールしなくなったりだとか、後々大変になったりするので、極力シンプルにシンプルに作ってる感じですかね。

松本
一応、Redis のベンチマークで一通りの機能試してこのオペレーションはこうでした!っていうのは出ますけど、それをどこまで信用できるかって話もありますし。

“クソハック” と 技術的負債


佐藤
僕が入社してからの印象なんですけど、けっこうFIVEの開発ってボトムアップというか、問題がきちんと顕在化してからそれに対応していくことが多いと思うのですが。いきなりトップダウンでこれやるみたいな感じにはならない場合が多いと思うんですけど、そういうのは意識的にやってます、よね?

松本
過度の抽象化はしないということですね。

小西
やってもしょうがないことはやってもしょうがない。

佐藤
そのへんの開発スピードあげるために、必要なことだけやるっていう風になってると思うんですけど、それをやり続けると逆に負の遺産がたまりすぎてみたいな話もあるじゃないですか。

松本
そうですねぇ。まず、ちゃんと捨てられるようにしておくのはけっこう大事かなと思っています。コードって腐っちゃうんで、どこかのタイミングで、リファクタリングし続けるか、根本から捨てちゃって同じインターフェースを提供するものを作るかの二択になるじゃないですか。で、それは考え方次第な気もしますけども、まあどっちもできるようにしとくのが正しいんでしょうけども。

小西
とりあえず開発スピード優先のときはクソハックでいいんですよね。クソハックはクソハックでいいんだけど、何回も似た要望が出てきたらクソハックはちょっとしんどいので作り直す。2回作るときれいなものができるんで。2回作るのも必要な工数なのかなと。

松本
ウォーターフォール開発って言葉あるじゃないですか、あれももともと2回作ることを想定されていたみたいな話があるらしくて、2回作るといいものができるって、まぁそうだよなぁと思った記憶がありますね。
それを多分、「2回作る工数無駄じゃね?」って作ったことない人が思ってしまったらしくて、今のその、SIerとかの開発にもなっているって・・・。

類地
それって「人月の神話」に書いてある?

松本
どうだったかなあ。たぶんウォーターフォール開発が最初に提唱されたときにうんぬんとかそういう感じだと。

佐藤
ソフトウェア開発でウォーターフォール開発って出てきたんですか?多分もっと建築とかハードウェアだとプロトタイプ作って、そこから量産みたいな形になるから最低2回は作らないといけないみたいな状況があったんじゃないかな。

類地
FIVEは今まで2回作ってます?

松本
そんなこともないですね。まだ2回つくるフェーズまで来てないっていう感じですかね。クソハックを塗り固めてそれっぽくなってるからまだ本格的に2回目は作らなくていいよねというタイミング。

小西
まあ、わりとみんな綺麗なクソハック書いてますよ(笑)クソハッククソハックって言ってますけど、なんて言い換えればいいんでしょうね。

類地
その場しのぎ・・・?あまりクソハック感がぬぐえてない(笑)Quick and dirtyとかそういうやつですかね。

レイジーにやるかどうかは、ビジネスインパクト次第。
つまり儲かるかどうか


類地
さっきの話だと色々なことを可能な限りスピード上げるためにレイジーにやってます、って話でしたけど、レイジーにやるタスクかそうじゃないかを決めるポリシーとか判断軸はどうですか?

小西
ずばり金になるかどうかですね。

類地
それがまさにビジネスをちゃんと見てるかどうかってことじゃないですか。

小西
まあそうですね。言い換えると、金になるということは世の中に需要があるってことなので、需要があるんだったら、継続して使われるのであればきちんと作り込めば良い。逆に、今回だけお願い、みたいなケースではちょっと汚いコード入れておいて、2週間くらいしたら消すか、みたいな判断ですかね。

松本
ビジネス要件って基本的に予期できないものだと思うんですよね。そもそもスタートアップが開拓する市場の要件って基本的に決まらないじゃないですか。なので、やってみないとわからない。やってみないとわからないからそこにコストかけるのバカじゃねえのっていう方針ですね。できるだけ手を抜いて、すぐにできてかつすぐに取り外せてみたいな、そういうものを作る感じですね。
2〜3回同じ要求が発生してきたらそろそろ面倒くさいねってなるので、真剣に作るかっていうタイミングですね。

“安全側に倒す”


類地
実装をレイジーにやるか作りこむかという判断や、さっきのクソハックみたいなところだったり、捨てられるように実装するみたいな開発思想は結構重要になる気はしますね。ビジネスを見据えてどのようにインプリメントしていくかということ。他になにか気をつけていることてあります?

小西
仕様とかはしょっちゅう変わるので。本番で流す前にきちんと確認するとかですかね。

佐藤
変な事故り方をしないようになるべく安全な方へ。

松本
安全側に倒すっていうのはけっこうやってますよね。
ここもしかしたらうまく動かないかもしれないな、という場合には基本的に安全側に倒す。その安全の定義もコンテクストによって変わるんですけど、まず関係者が損をしなくて、僕たちもできるだけ損が少ない方向を模索する。誰かが一方的に得するのは基本的にそれは安全ではないと思ってて、誰も損をしないものは一番安全なのかな。

類地
安全側に倒すっていうと、具体的にはたとえばエラーハンドリングをするときにビジネス要件が正確に見えていないとどっちに倒すか分からないということが発生するわけですよ。それをちゃんとやってるのは僕は凄いなと思いますね。当たり前だとは思うんですけど、それができてる開発チームはあまりないんじゃないかな。

エンジニアはもっとビジネスに関心があってもよい


佐藤
一応、この対談はFIVE のウェブサイトを見てくれている人に向けてなんですけど(笑)、読んでくれるエンジニアの方に何か一言ありますか?

松本
エンジニアってほんと基本ビジネスに興味ない人が多いので、もっともっとビジネス知ったら良いのになって僕は見ていて感じます。

類地
僕も思います。ビジネス構造を知っていたほうが色々と有利。

松本
結局のところ、お金作れる人が強いんですよね。お金作るためにはビジネスも分かってないとできないと思っていて。そうじゃないと、「それ誰にとって価値があるの?」っていう話で。俺、金稼げますよって言ったほうが絶対強いはず。

類地
そりゃそうだ。

小西
技術だけに興味がある人が大半で、ビジネスとエンジニア両方に興味がある人は非常に少ない。ちょっともったいないですね。

類地
FIVE にいるとコンピューターサイエンスとか工学出たとかそういう人が多いのに、みんなビジネスに非常に関心が強い(笑)。お金になる=需要がある、つまり使われるということですよね。

小西
まあそうですね。エンジニア的には、需要があればお金にならなくてもいいやとは思うんですけどね。いまは資本主義なので。世の中に必要だったらやる、必要なかったらやらない、以上。

松本
そうですね。世の中に必要かどうかを判断するのに、ビジネス理解が必要と。

小西
一緒に市場を開拓していくエンジニアを募集しています。