スタートアップと大規模サイトの最適なアーキテクチャの違いなどビジネス的な視点から見たJSについて

1. スタートアップと大規模サイトの
JavaScript
柳澤 直

2. リクルートホールディングス (住まいカンパニー出向)
新卒2年目 (23さい) 柳澤 直 (やなぎさわ なお)
アプリケーションエンジニア
(Webフロント◎、サーバー○、インフラ△)
2012/03: 人材DBベンチャー(アルバイト) クビになる
2013/05: ソーシャルゲーム会社にて3Dランゲーム開発(アルバイト)
2014/10: 知り合いと起業 http://www.ineeza.com/
2015/10: Youtuber向けポータルサイトUUUM Network開発
2015/05: フリーランス開業 海外スポーツ賭博自動化システムなどグレー
なシステムの受託開発
2015/08: クラウドサービス口コミサイトBoxil開発
2016/02: 自動ネイティブアド生成第三者配信タグシステムの開発
2016/04: Recruit Holdings入社 RSC配属 SUUMOの開発
短期インターンとか含め関わった会社、プロダクト
好きな or 気になってる技
術

3. JS Conf 2016
JSのためにアイスランドへ出張

4. JSのスター数 115 /
201
結構JSのことは好きかもしれない、、 ///

5. 大規模
※ 現時点でのやなぎさわの主観です
※ だいたいです
※ 勝手にロゴ使ってすいません、ダメだったら連絡くださいw
※ 他にもいくつかありますが一般公開されてるサイトということで
急成長ベンチャー0 -> 1
ソースを読んだことがあるサイトのプロット

6. 注意
・所属組織等は関係なく全部僕個人の考え方です。
・まだまだ若造です。 経験はそれなりにあるつもりですが会社でも問題児扱いさ
れたりして、まだまだ足りない視点がいくつかあるっぽいのでお気づきの際はこ
っそり教えてください笑
・技術とビジネス両方好きで織り交ぜて話してます。純粋に技術の話を聞きたか
った方はすみません。
・JSって書いてありますがフロントエンドの話題が多いです。フロントに興味の
ない方はすみません。

7. 0 -> 1 フェーズで感じたこと
Wordpressから自社システムへの移行案件
・0 -> 1 なので少ない工数でのビジネス的仮説検証がメイン
・お金のことをもっと身近にというコンセプトのお金に関するメディア
※ 現在絶賛開発中でWordpressから新システムへ移行中

8. ジョイン時のアーキテクチャ
本体、API
Rails
一般ユーザー
管理画面
フロント
React
API
ライター

9. MVPのプロダクト
のためにAPI作る
必要性って？
週１、２ヶ月
という短納期
管理画面そんなに
かっこいい必要な
い。。
React Redux
触るファイル多いし
やっぱ面倒かも、、

10. 変更後のアーキテクチャ
本体、管理画面
Rails
一般ユーザー
ライター

11. ・仮説を検証するだけのMVPにマイクロサービス的な高尚な
ものは不要なのでは
・Reactよりどう考えてもjQueryの方が簡単。設定とか諸々
あるし工数はReact等を採用すると上がる
・0 -> 1のフェーズの場合はjQueryでいいじゃん

12. エンジニア的に楽しい（新しい技術使いたい的な）と
ビジネス要求は時に異なる
最初ノリで作ると後で本当に後悔するから技術選定は
たとえ副業でもちゃんとやる、、、

13. 大規模急成長ベンチャー0 -> 1
とはいえ、、
多分ここら辺でお金を投入して一気にスケールさせるタイミングとかくる

14. とはいえ、、、
・チャットワークにみるScala再構築事件とか、、
・ベンチャーで数万UUくらいの規模のサイトだったらそんなに機能もないだろう
し、シリーズA, Bくらいの調達のタイミングで丸っと作り直しとかあり？
・マイクロサービスアーキテクチャはシリーズA, Bくらいのタイミングで検討し
始めるのがいいんじゃなかろうか

15. 大規模プロダクトのJSで思ったこと
・世界１の売り上げの不動産検索サイト
・住む場所を探している人に情報を提供している不動産メディア
※ 開発に携わったことがあるのはPCサイトの賃貸

16. ソースを読む人が異常に多い
(実装者以外や他のチームの人も参照したりする)

17. Linterやformatterをフル活用
コードレビューもかなり入念にやる

18. 共通部分がサワレナイ、、、
-> 影響範囲が大きすぎる

19. E2Eテストなど、なんらかの方法でコンバージョン
までの導線を自動テストする
何がどこにあるのかすぐわかるようになっておく
→ 影響範囲の把握
→ フォルダ構成がかなり重要

20. E2Eテスト
Nightwatch.jsWebdriverIO
JSでかける、、、 ///

21. テストケースの設計 -> 何をテストするのか
とはいえE2Eむずい

22. 何をテストするのか
リスク
E2Eの
コスト
手動テスト
コスト
ログ 高 低 高
検索機能 中 低 低
... ... ... ..
リスクが高くて
E2Eテストのコストが低くて
手動テストのコストが高いもの からやる

23. CIに組み込むのが大変 → ブラウザ動かすの大変
とはいえE2Eむずい

24. DockerHubにあるWebdriverIOのコンテナ構成
E2Eコンテナ
Hubコンテナ
ブラウザコンテナ
(Firefox)
ブラウザコンテナ
(Chrome)
Webサーバー
ブラウザコンテナ
(...)
コンテナ多い、、、
リソース足りなくて落ちたりする、、、
参考
https://hub.docker.com/r/casperlai/docker-
webdriverio/

25. 当たり前だけど大規模サイトは難易度が高いこと
を要求されることが多い
大規模サイトのJSは慎重に開発をする必要がある
→ 当然スタートアップとは違った開発になる

26. まとめ
・0 → 1の段階のプロダクトは凝ったことしないで仮説検証のために本当に必要
最低限の技術で最小工数の実装
・シリーズA, Bらへんで開発リソースに余裕が出てきたら徐々に新しい技術を検
討すると技術を生かしてプロダクトがグロースできそう
・大規模なプロダクトは影響範囲を把握しやすくしておくことがかなり大事。ま
たデグレの検知をする仕組みがかなりバリューを発揮しそう