食べログのフロントエンドエンジニアってめっちゃ大変やねん･･･

食べログのフロントエンドエンジニアって
めっちゃ大変やねん...
株式会社カカクコム
食べログシステム本部システム開発1部 FEチーム
金野淑恵

Copyright © Kakaku.com Inc. All Rights Reserved.
今日話すこと
フロントエンドの開発体制作りにおける苦労

今日ほとんど話さないこと
技術的なノウハウ

お話の流れ
自己紹介
食べログの紹介
食べログのフロントエンドエンジニアって？
具体的にやっていること
まとめ

自己紹介
金野淑恵
（かねのよしえ）
@empitsu88
Profile
Career
食べログシステム本部FEチームリーダー
食べログのフロントエンド領域の設計・開発などを担当
2009～2015年某印刷会社入社
Flasher/フロントエンジニアとして受託Web制作
2015～2017年株式会社カカクコム入社
食べログのフロントエンドエンジニア

は
お店選びで
失敗したくない人のための
グルメサイトです

食べログってどんなサービス？
ネットで飲食店を探すときに起こりがちな
「想像とは違うお店だった」というような失敗をなくすために
ユーザーの口コミと共に全国のレストラン情報を掲載

基本データ
1億450万人約2,200万件約86万件
…という大規模なグルメサイト
月間利用者数口コミ数掲載店舗
※2017年12月現在のデータ

カカクコム社のミッション
ユーザー本位
サービスの原点は
生活者が感じる不便や社会的課題を解決すること

派生サイト

Ruby on Rails unicorn MySQL
使用技術
プロジェクト・タスク管理
(REDMINE)
ソースコード・バージョン管理
(GitHub)

HTML5 CSS3
jQuery + Backbone.JS ECMAScrip2015
Sass
使用技術 - フロントエンド
Gulp + webpack
+
SMACSS+BEM+FLOCSS compass
CSS3

アプリ構成
20以上のRailsアプリが存在
appliA
appliB
appliC
appliD
appliE
appliF
appliG
appliH
appliI
appliJ
appliK
appliL
main_service
hoge
fuga
fega
haga
base_api
faga
micro_service

お察しの通り･･･
とにかく規模が大きく
ソースコードもカオス

従来の食べログの開発体制

デザイナー
UI設計者＆デザイナー＆マークアップエンジニア
約20名体制

エンジニア
Rubyエンジニア＆インフラエンジニア＆ネイティブアプリエンジニア
約70名体制

エンジニアデザイナー
業務分担
インフラ JSDB CSSRuby HTML
バックエンド (server-side)
UI/
VS
フロントエンド (client-side)

エンジニア＋デザイナーで約100名の開発部隊
HTML/CSS/JS を俯瞰したスキルを持った人が少ない
1週間でデプロイされる Redmine のチケットの数は約80件

結果・・・
場当たり的な実装が繰り返されカオスに

そこで・・・
2016年
フロントエンドエンジニア
爆誕

担当領域
Server JSDB CSSRuby HTML
UI/
VS

FEチーム
今は約6名体制

「フロントエンドはFEが
全部つくれば安心だね！」

担当領域
Server JSDB CSSRuby HTML
UI/
VS
開発の主体はエンジニア・デザイナーのまま

あくまで食べログのFEは
監督者・サポーターの立場

なんで？完全分業にしないの？
チーム・人員間で意識や目的の共有が難しくなりがち
チーム間の利害の対立や局所最適化が発生しやすい
特定のチームしか実装しない・できない状態だと
そのチームが詰まったときに案件が進められなくなってしまう
事業会社ではデメリットも多い･･･
職能別組織の一般的な課題として･･･

あくまで目的は事業の成功
制作者一丸となることが必要
FEの存在意義は
食べログのフロントエンドに秩序をもたらし
正しい方向に導いていくこと

正直、ただ開発するより
めっちゃ大変

やってること
開発案件での方針策定・設計・サポート
フロントエンドの環境整備

1.開発案件での方針策定・設計・サポート

まず「キレイなコード」を考える
「キレイさ」とは
PREDICTABLE 予測しやすい
MAINTAINABLE 保守しやすい
REUSABLE 再利用しやすい
SCALABLE 拡張しやすい
Googleエンジニアフィリップ・ウォルトン氏のブログより

具体的に？
ready イベントの callback は
1つの Entry point につき1つだけ
Module ファイルは Entry point から初期化する

ready イベントの callback は 1entry point につき1つだけ
<html>
<head>
<script src=“smartphone/sidemenu.js”></script>
<script src=“smartphone/top_mainvisual.js”></script>
• smartphone/top.html
• smartphone/sidemenu.js
$(function(){
// ハンバーガーメニュークリックで
サイドメニューを表示する処理
});
$(function(){
// メインビジュアルをカルーセル化する処理
});
• smartphone/top_mainvisual.js

<html>
<head>
<script src=“smartphone/sidemenu.js”></script>
<script src=“smartphone/top_mainvisual.js”></script>
• smartphone/sidemenu.js
$(function(){
});
$(function(){
});
• smartphone/top_mainvisual.js

<html>
<head>
<script src=“smartphone/top.js”></script>
• smartphone/top.js
$(()=>{
});

Moduleファイルは Entry point から初期化する
<html>
<head>
<script src=“smartphone/top.js”></script>
• smartphone/top.js
import Sidemenu from “modules/smartphone/sidemenu.js”;
import TopMainvisual from “modules/smartphone/top-mainvisual.js”;
$(()=> {
Sidemenu.ready();
TopMainvisual.ready();
});

const Sidemenu = {
ready() {
// ready 時に必要な処理
}
}
export default Sidemenu;
• modules/smartphone/sidemenu.js
moduleファイル側では、呼び出した途端に初期化が始まらないように
Moduleファイルは Entry point から初期化する

設計のときに考えるべきこと
食べログの実態に即しているか
費用対効果は適切か
優先度は適切か
= 回せるか
= コスト
＝納期

例）見た目に関わる制御はなるべくCSSファイルに
$(window).on('scroll', (e) => {
if ($(window).scrollTop() >= 500 ){
// js で行うのは is-scroll の付け替えのみ
$('.js-header').addClass('is-scroll');
} else {
$('.js-header').removeClass('is-scroll');
}
});
• JS
• CSS
.header.is-scroll {
position: fixed;
top: 0;
width: 100%;
}

納期を最優先に考えた上で
「キレイさ」
「回せるか」
「コスト」
のバランスを考えて設計する

他には･･･
設計書の粒度に気をつけたり･･･
「なぜこの方針？」「なぜこうする必要があるの？」を
口頭で説明したり･･･
依頼する実装者によって説明の仕方を変えたり･･･

手を動かすのは
あくまで他部署のエンジニア
綿密なコミュニケーションと
サポートを心がける

正直、めっちゃめんどうくさい

悩みは多い･･･
どうしたら他部署であるエンジニア・デザイナーと
密な連携が取れるだろうか？
どうしたら気軽にJSやフロントエンドについて
質問しにきてくれるだろうか？
エンジニアが片手間で手がけているJSの経験値を
効率よく積んでもらえるには･･･？

エンジニアBチーム
エンジニアAチームFEチーム
エンジニアCチーム
こうした
部署ごとに窓口となるメンバーを決めた
エンジニア内にも兼任フロントエンジニアを作った
Aチーム担当
Bチーム担当
Cチーム担当
兼任FE
兼任FE
兼任FE

こうなった！
各部署の案件や仕様について誰が一番把握しているか明確に！
エンジニア・デザイナーも窓口が明確なら気軽に聞きやすく！
リーダーがぜんぶ問い合わせを請け負ってるとボトルネックに
なりやすかったがそれも解消！

2.フロントエンドの環境整備

フロントエンドコーディング規約

食べログスタイルガイド

コンパイル機構の整備
+
Rails 5.1 + Webpacker
+

ソースコードのリファクタリング
ECMAScript５ → ECMAScript6 化
CSS module の FLOCSS化
Pure module化 – entryPoint から全部呼び出す

正直、めっちゃ地道

まとめ
食べログのFEは開発というよりサポートに注力しているが
めっちゃ大変
「納期」「キレイさ」「回せるか」「コスト」のバランスを
考えて設計するのはめっちゃめんどうくさい
リファクタリングとかめっちゃ地道

でも･･･
地道ながんばりの結果
すこしずつ成果はでてきている

だから･･･
食べログを盛り上げるために
＼がんばる／

大変なことにも立ち向かえる
＼絶賛募集中！／

ご清聴ありがとうございました

食べログのフロントエンドエンジニアってめっちゃ大変やねん･･･

More Related Content

What's hot

Similar to 食べログのフロントエンドエンジニアってめっちゃ大変やねん･･･

食べログのフロントエンドエンジニアってめっちゃ大変やねん･･･