「Developers Summit 2019(2日目)」に参加してきました

event.shoeisha.jp

codezine.jp

タイムテーブル

10:00~10:45

タイトル 発表者
ドラゴンクエストXを支える失敗事例 青山 公士[スクウェア・エニックス]
エンジニアの知的生産術 ビフォー・アフター 西尾泰和[サイボウズ・ラボ]
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて - 澤田 雅彦[NTT]
プロダクトマネージャーという生き方 熊谷 亘太郎[楽天]
ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ― 資料1 資料2 市谷 聡啓 [ギルドワークス]
新井 剛 [ヴァル研究所・エナジャイル]

11:05~11:50

タイトル 発表者
IBM Q - 量子コンピューターの最前線 小野寺 民也[日本アイ・ビー・エム]
メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと 山本 学[ヤフー]
デベロッパーのためのAzureクラウドネイティブスタック 〜 提供したい価値からはじめる高速+高可用+高付加価値ソリューション 川崎 庸市[日本マイクロソフト]
デンソーのMaaS開発~アジャイル開発で顧客との協調・チームビルディング・実装概要~ 佐藤 義永[デンソー]
冨田 進[デンソー]
CI/CDを使い倒して数段上のソフトウェア開発をしよう! 金 洋国[CircleCI]

12:10〜12:40

タイトル 発表社
モンスターストライクにおける負荷対策 ~エンジニアリングチームの挑戦~ 白川 裕介[ミクシィ]
【導入事例】Lychee Redmineのユーザが語る!トラブル予防としての使い方 稲垣 哲也[フューチャーアーキテクト]
機械学習システムのアーキテクチャ アラカルト ~ BrainPad における実例を交えて~ 太田 満久[ブレインパッド]
外食の「明るい未来」にむけたトレタの新たな取り組み 吉田 健吾[トレタ]
Entertainment x Tech~多くのアーティストとファンを繋ぐ技術と組織~ 山田 真一[エイベックス]

13:05~13:50

タイトル 発表者
3周年に突入するAbemaTVの挑戦と苦悩 山中 勇成(みゆっき)[サイバーエージェント
エンジニアの皆さんに贈る最速キャリア戦略 松本 勇気 [DMM.com]
ゲームQAを支える技術~前処理・後処理は大変だが役に立つ~ 太田 健一郎[スクウェア・エニックス]
OSS開発スタイルを取り入れて、効率的な開発を!~InnerSourceのススメ~ 田中 裕一[GitHub]
中国・深センのテクノロジー最新事情 資料1 資料2 ちゃんとく[dotstudio]
寺尾 英作[SBクラウド]

14:10~14:55

タイトル 発表者
ゲーミフィケーションエバンジェリストが説く、アプリ開発で見落としがちな「おもてなし」とは~面白さを伝える × 面白く魅せる~ 仲 功児[ナノコネクト]
Site Reliability Engineering at Google 中井 悦司[グーグル・クラウド・ジャパン]
今からでも遅くない!?Azureで学ぶ実用Blockchain 廣瀬 一海(デプロイ王子)[日本マイクロソフト]
太田 寛[日本マイクロソフト]
これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ - 幾田 雅仁 [gumi]
Less Code & Have Fun! IoTアプリ開発をはじめる際のポイント 山崎 亘[ウフル]
IBM Q 量子コンピューターハンズオン 小林 有里 [日本アイ・ビー・エム]

15:15~16:00

タイトル 発表者
プロダクトをGrowthさせるデータ駆動戦略の基礎知識~DMM.comにおけるユーザーレビュー基盤のKPIツリー公開~ 石垣 雅人[DMM.com]
サーバーレスで最高に楽しめるアプリ開発 江藤 武司[Riotz Works]
「仕事なんか楽しいはずないやん」に反発し「ええと思うなら、やったらよろしいやん」を胸に歩んできた話 中村 洋[ギルドワークス]
ことばだけでは足りません、描いてシェアして伝えていこう! 高野 明子[Sider]
システムエンジニアは空を飛ぶ夢を見れるのか~普通のSEがドローン系SEになるまで~ 佐藤 明
Kubernetesを短時間で体験。IBM Kubernetesで遊んでみよう! 斎藤 和史[日本アイ・ビー・エム]
今関 靖一郎[日本アイ・ビー・エム システムズ・エンジニアリング]

16:20~17:05

タイトル 発表者
Webサーバー利用だけではないNGINXソリューション 田辺 茂也[NGINX]
無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜 池山 邦彦[Datadog]
GKEとIstioで構築するクラウドネイティブ・アプリケーション - What, Why, Where and How to use Istio? 福田 潔[グーグル・クラウド・ジャパン]
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング 森廣 隆行[リクルートテクノロジーズ]
セキュアな環境でDevOpsを実現する厳選ツール 根本 竜也[マクニカネットワークス]
上田 展生[セガゲームス]

17:25~18:45

タイトル 発表者
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方 よしおかひろたか[東京大学大学院]
Webアプリのチューニングバトル「(社内)ISUCON」の魅力と楽しさ 資料1 資料2 資料3 櫛井 優介[LINE]
古川 陽介[リクルートテクノロジーズ]
南 直[Wantedly]
とにかく明るい!「Fun! Done! Learn!」でデブサミを振り返ってみましょう! ヴァッサー ジャンバティスト[yamaneco]
安井 力
川口 恭伸[アギレルゴコンサルティング]
有野 雅士[アトラクタ]
エンジニア採用パネルディスカッション――困難きわまる人材確保、だが成功する方針・施策とは 【モデレーター】市古 明典[翔泳社]
小野 和俊[セゾン情報システムズ]
松尾 奈美[リクルートテクノロジーズ]
三木 明[Repro]
アウトプットのススメ ~技術同人誌・LT登壇・Podcast~ おやかた
ariaki
hekitter
mochikoAsTech
KANE
長村ひろ
erukiti
私たちはどんな課題を解決すべきなのか? - 自然災害救援のために開発者ができること「Call for Code」 戸倉 彩[日本アイ・ビー・エム]
関 治之[コード・フォー・ジャパン]
小和田 香

デンソーのMaaS開発~アジャイル開発で顧客との協調・チームビルディング・実装概要~

アジャイルチーム

  • 2年前にアジャイルチーム発足
  • 今では6チーム
  • プロジェクトが終わったら解散ではなくチームに対してプロジェクトをアサインしている

mobi-Crews

  • 採用技術
    • Beanstalk
    • Terraform
    • Docker
    • Rails
    • CircleCI

開発の立ち上げ

開発の進め方

  • 次スプリントのバックログにready/not readyの印をつけておく
  • カンバンの一番上は改善タスク
    • 改善することでその後の作業が効率化されるはずなので一番先に
  • プランニング
    • 速くて2時間長いと3,4時間
    • スプリントのサイクルは1週間
  • スプリントレビュー前日の午後は開発チーム内でレビュー
  • 動くものを見せることが大事
    • 出来てないからドキュメントでデモとかやりだすとダメ
    • 全部出来てなくても見せる
  • メンバの追加はせずにスコープ調整が理想
    • そうもいかないことが多い
    • 複数チームにして拡大
    • POは個別に割当

インフラ

  • コード化する
    • Terraformを採用
  • 横展開可能なテンプレート化
  • 極力マネージドサービスを使って負担をへらす
    • Beanstalkを採用

リリースが近づいて

  • 課題
    • 監視
      • 必要なメトリクス洗い出して横展開
    • 性能
      • 性能評価環境を要しし定期的に測定
    • セキュリティ
      • 外部機関と連携して評価
  • プロジェクト横断のチームを結成
    • SREチーム

3周年に突入するAbemaTVの挑戦と苦悩

AbemaTV

  • 特徴
    • 無料
    • 会員登録なし
    • 24時間
  • 2015/10 開発開始
  • 2016/3 仮開局

プロジェクト横断のチームを結成

  • 開発メンバー
    • 当初14人 -> 今90人超
  • Web/iOS/Android/新デバイス/Streaming Client
  • プロジェクト管理
    • クライアントは2週間のスプリントで開発リリース
  • 勤務体制
    • 週一リモート推奨

アプリケーション

GCP

  • 高機能L7ロードバランサ
  • GKE/K8s
  • ネットワーク帯域に対するコストの安さ
  • ログ収集サービスの充実

言語

  • CAのバックエンドはではJava -> Node -> Go
  • Goを採用

アーキテクチャ

  • Microservices
    • 約80サービス
    • コンテナ化でリソース有効活用
    • サービス間通信はgRPC
    • Gateway Pattern
  • Go + Microservicesの課題

    • パッケージ管理
    • Goのバージョン管理
    • 共通ロジックどこにまとめるか

      データベース

  • MongoDB

  • シャーディングによる分散とレプリカセットで冗長化
  • コネクションプール管理

キャッシュ

  • In-Memory
  • Redis
    • 開発当初GCPでマネージドなものがなかったから
    • セッション管理
    • ロック目的
    • ネットワーク負荷軽減

構成管理

  • Terraform
    • インフラ構築を自動化
  • Packer
    • マシンイメージの作成起動

ネットワーク

クライアント/サーバ間通信

  • gRPCも検討したが
    • 当時http2での通信に対応してなかった
  • 通信フォーマットはProtocol Buffers

CDN

  • Akamai Media Delivery
    • 映像配信に特化したものが少なかった
  • Cloud CDN

開発支援

CI/CD

  • Codeship
    • バックエンドのテストやイメージの作成
  • Deploykun
    • 内製のchatopsツール

モニタリング

監視

  • bugsnag
  • Google Cloud Monitoring
    • GCE/GKEの挙動監視
  • Slack連携
  • PagerDuty
    • インシデント管理ソリューション
    • SREチームで1次対応

ログ

  • アプリログ
    • Goの標準出力にJSONで出力
    • GKEのfluentdで収集
    • StackDriver Loggingで表示
  • アクセスログ
    • 当初はfluentd
      • Goとの相性
    • CloudPubSubとBigQueryへ変更
      • Streaming Insterterの運用管理
      • BigQueryのStreaming Insertのキャパシティ
    • => 今はCloud Dataflow + Apache Avroへ変更

メトリクス

  • Redis/MongoDBはStackdriver
  • 各アプリはPrometheus + Grafana

今後

  • サービス規模の拡大
  • さらなる安定化の追求
  • 既存システムの老朽化対応

目指すアーキテクチャ

  • 配信レイヤーの全二重化
    • サーバや回線等ユーザの直前まで全て
  • チャンネル別リソース
    • RedisやMongoDB等のリソースをチャンネルごとに分ける
  • 実績と予測に基づいたオートスケール
    • 過去実績や時間帯をもとにオートスケールさせたい

Site Reliability Engineering at Google

Googleについて

  • 担当していないサービスでも全てのコードを見ることができる
  • 目指すところ
    • 世界中の情報を整理し世界中の人ボトがアクセスできて使えるようにする
  • 世界中専用回線でつながってる
  • 世界中のデータセンターに巨大なk8sクラスタっぽいものがある
    • 標準化されていてどこも同じ
  • ミドルウェアのレイヤも標準化されている
  • GCPは社内で使われていたものをオープンにしたもの
  • プロジェクト外のソフトウェアもコード修正・改善案を自由に出せる

SRE

  • リリースしたサービスをいかに安定して運用し続けるか
  • システムを運用するだけでなく安定運用するために必要なソフトウェア開発をあわせて行うチーム
    • => Site Reliability Engineering

50%ルール

  • 50%以上をシステム安定に関わるプロジェクト活動にあてる
  • 障害対応等々は50%以下にする
  • 障害が多い/マニュアル作業が多すぎて50%ルールが厳しくなるシステム
    • 開発側に突き返す
    • システムを改善する

SREが見る範囲

  • 運用範囲
  • 運用範囲外
    • 小規模で重要度が低いアプリ
    • 安定運用できてるシステム

SREの活動原則

SLO

  • 何を持って「安定」というか
  • Service Level Objective
  • システムの安定稼働の目標値
  • エラーバジェット
    • エラーバジェット = 1.0 - SLO
    • 消費状況をモニタリング
    • エラーバジェットがなくなりそうになったら新機能の開発はストップして改善に注力

Toil

  • 労力のかかる作業の削減

Postmortem

  • 障害対応が終わった後の文書
    • 発生要因
    • 反省点
    • 改善点
  • 個人を非難する内容は絶対に書かない
  • 障害報告ではなく未来につなげるための知見とする

プロダクトをGrowthさせるデータ駆動戦略の基礎知識~DMM.comにおけるユーザーレビュー基盤のKPIツリー公開~

データ駆動戦略とは?

  • データドリブンで戦略を組み立てる
  • 不確実性につい良い組織にする

なぜデータ駆動戦略?

  • 直感に頼るとプロダクトバックログが肥大化し開発者を圧迫する
  • データがないとなぜうまくいった/いかなかったが分からない

データ駆動戦略のなにがいいか?

  • プロダクトの状態を可視化できる
  • 意思決定を高速化できる
  • 意思決定を定量的に共有できる
  • 未来を予測して戦略を作れる

どうやってデータ駆動戦略?

DMM.comのデータ駆動戦略

  • SoEとSoRな領域がある
  • 40種類以上のサービス
  • ドメインごとにスクラムチーム
  • データアナリストがPOを支える

データ分析基盤

  • データを提示できないといけない
    • 分析しやすいデータ分析基盤が必要

優れた指標

  • データが駆動する
    • データを見ることで次の行動につながること
  • 3つの土台
    • 比較できる
    • わかりやすい
    • 比率や割合である
  • 4つの指標
    • 定量的指標と定性的指標
      • 主観的/科学的数値
    • 虚栄の指標と本物の指標
      • 次の行動につながる/つながらない
    • 先行指標と遅行指標
      • 未来の予測/変動後の数値
    • 相関指標と因果指標
      • AとBが関係/Aが起こるとBが起こる
      • 因果関係を探すために相関関係のある数値をを観察

開発プロセス

最後に

タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング

背景

  • 入稿システムはリボンモデルの根幹の部分
  • ディフェンシブで既存システムに手を加えるのではなく新規で作ることが多い
  • 急激な性能劣化
  • リプレイスでは時間がかかりすぎる

性能改善

  • 過去の技術的負債を分析し改善
    • 泥臭い作業で改善を重ねた
  • 品質の担保
    • 本番データと突き合わせて確認
    • オフショア使って力技で

まとめ

  • リビルドリプレイスに頼らなくても効果は出せる
  • システム単体で最適だったとしても経年劣化を考えるとそうでない

Webアプリのチューニングバトル「(社内)ISUCON」の魅力と楽しさ

ISCONの誕生

  • 2011年の夏
  • tagomorisさんが発起人
    • 「言い訳できない環境で1番を決めたい」
  • 当時のライブドア

名前の由来

  • 当初lpc
  • パフォーマンス遅いと椅子投げるといっていた
    • ISU
  • Iikanjini Speed Up Contest

概要

  • 制限時間8時間
  • 与えられたWebアプリを高速化する

今年のISUCON

R-ISUCON

なぜR-ISUCONはじめたか

  • ISUCONで勝てない..
  • 過去出題している人たちが強い
  • やってみると方向性が変わってきた

本家ISUCONとの違い

  • 本家は出題する会社がそれぞれお題を出す
    • 会社の特色が出る
  • リクルートなりの問題を作った
    • 本家はバックエンドの要素が多いがフロントエンドの要素も入れた
      • CSS/JSをあえて重くしたり
    • 社内で実際に起きたり困ってたりすることをお題に
  • 本家は8時間だけどR-ISUCONは合宿で1泊2日
  • 教育的な側面も強いが障害振り返り的な側面も強い

これまでの振り返り

スピードハッカソン

  • 仮想サービスでなく本物のサービスでISUCONする
  • 実際のサービスでの制約を度外視して試せる

PIGICON

IMOCON

その後

  • みんなに学んでほしいことをコンテキスト形式にする流れができた
  • 実際のアプリにも効果が出せた

新卒研修でISUCON

  • Wantedlyで新卒研修でISUCONした
  • パフォーマンス改善は学ぶのが難しいし実践できる機会が少ない
    • ISUCONで体験してもらう
  • 幅広い技術にふれてほしい
    • 高速化にはあらゆるスキルが必要

新卒ISUCONの運営

  • 問題と環境があればできる
  • 問題
    • Webアプリとベンチマーカー
  • 環境
    • アプリを動かす環境
    • スコアボード
    • 場所

今後

  • 企業横断での新卒ISUCONとかできると面白うそう

「Developers Summit 2019(1日目)」に参加してきました

event.shoeisha.jp

codezine.jp

タイムテーブル

10:00~10:45

タイトル 発表者
❤一生エンジニアを楽しもう❤夢中が最高!! 漆原 茂 [ウルシステムズ]
エンジニアリングマネージャー・パネルディスカッション 織田 晃弘[富士通クラウドテクノロジーズ]
及川 卓也[Tably]
竹迫 良範[リクルートテクノロジーズ]
広木 大地[レクター]
ひらい さだあき[メルカリ]
是澤 太志[メルカリ]
イノベーションを支えるアマゾン文化 西谷 圭介[アマゾン ウェブ サービス ジャパン]
Scrum@Scale入門 原田 騎郎[アトラクタ]
Amazonの文化をハックせよ。AWSをフル活用して無人レジの仕組みを作ってみた~横田deGoプロジェクト~ 横田 聡[クラスメソッド]
始めてみようSalesforce - コード書かなくてもここまでできるクラウドアプリ開発 - 宮本 隆人[アクセンチュア]
小坂 駿[アクセンチュア]
本橋 孝昭

11:05~11:50

タイトル 発表者
GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化 池田 尚史[GitHub]
Cloud Native アプリケーションに最適!Oracle Cloud Infrastructureの魅力! 丸川 祐考[日本オラクル]
茂 こと[日本オラクル]
Hack your career! ― アカデミックからビジネスへ向かったワケ ― 宇都宮 聖子[アマゾン ウェブ サービス ジャパン]
Alexaスキルで収益化を目指そう 畠中 俊巳[アマゾンジャパン]
レガシー開発からモダン開発への挑戦 資料1 資料2 左近充 裕樹[ブロードリーフ]
松本 宏紀[ブロードリーフ]

12:10〜12:40

タイトル 発表者
GCPに恋してHashiCorpを愛して起業したエンジニアのお話 長谷川 祐介[grasys]
幸せなエンジニアのキャリアの組み立て方 泉 雄介[ラクスル]
サポートを、上手く使って迅速解決!‐現場が泣いて喜ぶ問い合わせ方法- 伊藤 裕史[アマゾン ウェブ サービス ジャパン]
インフラエンジニア様の時間を、単純作業にとられるなんてもったいない!機能的なインフラと管理ロボットを導入してみた! 宇野 素史[クララオンライン]
島崎聡史[ニュータニックス・ジャパン]
セキュリティ・テストの自動化によるDevSecOpsの実現 (デモ有) 吉井 雅人[日本シノプシス]
パネルディスカッション - 他では味わえない!? Salesforceエンジニアの世界 - 岡本 充洋[セールスフォース・ドットコム]
小坂 駿[アクセンチュア]
小林 亮理[フレクト]
前田 ゆり子[日本システムデザイン]
山田 真也[ウフル]

13:05~13:50

タイトル 発表者
Cloud Native時代における Docker / Kubernetes による開発 青山 真也[サイバーエージェント]
日経電子版のマイクロフロントエンドとPWAによる改善事例 宮本 将[日本経済新聞社]
大規模分散データベースサービス - 世界で使われるAmazon DynamoDBを改めて知る - 成田 俊[アマゾン ウェブ サービス ジャパン]
大学におけるイマドキのエンジニア教育 資料1 資料2 角 征典[ワイクル]
永瀬 美穂[アトラクタ]
ブロックチェーンでエコシステムはどう変わるのか - コミュニティのこれまでとこれからを徹底議論! 池内 孝啓[catabira]
生田 和希[LayerX]
上坂 明日香[Omise Japan]
石井 壮太[ALIS]
始めてみようSalesforce - No CodeでEinstein Botを構築してみよう - 山田 真也[ウフル]

14:10~14:55

タイトル 発表者
ビズリーチは新規事業でなぜKotlinを選んだのか〜企業をアップデートする「Human OS」の技術選定について〜 大谷 弘喜[ビズリーチ]
一エンジニアが伝えたい、プロジェクトや組織の運営を理想に近づけるための考え方 宮下 崇[ディライトワークス]
入社半年での開発ストーリー - 千人規模の顔認証受付サービスを1ヶ月で作った話 - 針原 佳貴[アマゾン ウェブ サービス ジャパン]
新技術導入を成功させる組織のつくりかた ~spanner、GKE導入の実体験から得たこと~ 廣本 洋一[コロプラ]
APIを活用したフォントの使い方 ~MR(Mixed Reality)の実例紹介~ 相川 晴俊[モリサワ]
堀尾 風仁[神戸デジタル・ラボ]

15:15~16:00

タイトル 発表者
レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜 福田 剛広[VOYAGE GROUP]
小林 徹也[VOYAGE GROUP]
駒崎 大輔[VOYAGE GROUP]
ヤフー株式会社におけるフロントエンドの取り組み 向井 咲人[ヤフー]
森本 恭平[ヤフー]
平山 涼也[ヤフー]
パケットの気持ちになってみよう -クラウドを支えるネットワーク- 荒木 靖宏[アマゾン ウェブ サービス ジャパン]
不安をFUNへ!VP of Engineeringとしての組織変革への挑戦 里山 南人[ビデオマーケット]
開発者の第三のキャリアパスエバンジェリスト/アドボケイトとは何者か?~ 中津川 篤司[MOONGIFT]
開発者に贈るSalesforceプラットフォーム概論と最新動向 齋藤 俊[フレクト]
小林 亮理[フレクト]

16:20~17:05

タイトル 発表者
ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話 塩崎 健弘[ZOZOテクノロジーズ]
★The DEMO Show★ Visual Studio & .NET Core の進化とクラウド ネイティブ開発 井上 章 (チャック)[日本マイクロソフト]
コンピュータビジョンを支える深層学習技術の新潮流 鮫島 正樹[アマゾン ウェブ サービス ジャパン]
【祝】k8sデビュー! エンタープライズ巨大アプリをマイクロサービス・コンテナ化。段階的移行(中)の全記録を追う。 石田 健亮[ドリーム・アーツ]
カオス化した組織とエンタープライズシステム群を、モダン化したい!ノンIT企業のシステム企画開発を、ドメイン駆動型に組織ごと変えるまでの道のり 内藤 千稔[パーソルキャリア]
Salesforceプログラミング - Web Componentsをベースにしたアプリの開発手順 - 岡本 充洋[セールスフォース・ドットコム]
稲葉 洋幸[セールスフォース・ドットコム]

17:25~18:45

タイトル 発表者
「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会 【司会】高柳 謙
【特別ゲスト】平木 啓太 [丸善ジュンク堂]
【特別ゲスト】瀬尾 傑[スマートニュース]
【特別ゲスト】永瀬 美穂[アトラクタ]
若手エンジニアの登竜門「Developers Boost」優秀セッション再演! Edward Fox [Repro]
本多 広晃 [ナビタイムジャパン]
五十幡 直洋 [パーソルキャリア]
みんなの暮らしを支えるAmazon S3の裏側、お伝えします 焼尾 徹[アマゾン ウェブ サービス ジャパン]
楽しい場所でカンファレンスをする~スタジアムと岡山城 小西 宏樹[エムオーテックス]
uzulla
身近な業務を改善して楽しもう! ~ 業務ハックLT 【司会】菅原 のびすけ
野秋 拓也[DMM.com]
ポキオ
廣野 美里[freee]
菊池 健人[ハンズラボ]
高山 和幸[ウェルスナビ]
髙木 咲希[SonicGarden]
やまちょ

Scrum@Scale入門

  • 原田 騎郎[アトラクタ]

Scrum@Scale

アジャイルチーム

  • 人数が多いとコミュニケーションパスが多い

Agilityをスケールさせるには

  • コピペチームは作れない
  • スケールアップ/スケールアウトしかできないなら膨張してるだけ

スケールする前に

  • うまくいってるチームを2つ育てること
    • プロダクト、プロセス、チームの改善方法を知って経験しているチーム

Scrum@Scaleの定義

スクラムマスター

  • Scrum of Scrums
    • Scrumをスケールさせる
    • Scrum of Scrum of Scrums...
    • EAT(エグゼクティブアクションチーム)
      • 経営層が入る
  • SAAB Technologies社の事例
    • 2000人を1.25時間で同期
    • 7:30 DailyScrum
    • 7:45 Scaled DailyScrum
    • ...
    • 8:30 Executive Action Team

プロダクトオーナー

  • POをスケール
    • プロダクトオーナー
    • チーフプロダクトオーナー
    • チーフチーフプロダクトオーナー

SMとPOのスケーリングの違い

  • SM
    • ベストプラクティスの共有
    • 協力して障害除去
  • PO
    • 意思決定
    • 上位のPOの決定が強い

GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS

GitHub

  • 2008年にPullRequestが登場
    • ソフトウェア開発に大きな影響を与えた
  • ツールが多くて使いこなすのが大変
    • なんとかしたい
    • ワークフローはモジューラ化されてるべき
    • => GitHub Actions

GitHub Actions

  • コンテナ技術ベース
  • ワークフローをモジューラ化して構築できる
    • 再利用できる
  • GUIでワークフローを組み立てられる
    • 実態はテキストだから管理できるしプルリクだしてレビューもできる
    • ワークフローasCode
  • 個々のActionは単なるDockerfile
  • ワークフローにhookできるイベントは26ある
    • pushとか

現状の仕様/制限

  • 実行時間max58分
  • ワークフロー1つにつきAction100個まで
  • 並列実行は1repoあたり2つまで
  • APIコールは1repoあたり1時間1000回まで
  • Dockerでできることはだいたいできる
  • 環境変数渡せる
  • ベータ版なのでどんどん追記されてる

便利なAction

まとめ

  • ワークフローは自由になる
    • モジューラ化され
    • OSSとして作り上げる
    • ソフトウェア開発の世界に新しい1ページ

日経電子版のマイクロフロントエンドとPWAによる改善事例

日経電子版のフロントエンド

  • SPAではない
  • ページ単位で性質がことなる
  • アプリケーションというよりドキュメント寄り

マイクロフロントエンド

アーキテクチャ

TS

  • TS入れた
    • tscするだけ
  • トランスパイルはbabelのままで
  • 型付け頑張りすぎない
    • 依存モジュールの扱いとか

JSX

  • handlebarsからJSXへ
    • Reactを使ってるわけでない
    • 補完が効く
    • 型で縛れる

PWA

  • 確実性
  • 速さ
  • 魅力

Fast and Engagement

マイクロフロントエンドとPWA

  • ServiceWorkerがモノリス化する
    • 修正時の影響が広くて怖い
  • ServiceWorkerをマイクロサービス化
    • それぞれScopeを区切った

ヤフー株式会社におけるフロントエンドの取り組み

  • 向井 咲人[ヤフー]
  • 森本 恭平[ヤフー]
  • 平山 涼也[ヤフー]

背景

メディアカンパニーの取り組み

  • lint/prettier
    • レビューの効率化
    • コーディングガイドはgitbookで管理
  • Danger
    • プルリクへのラベル付
  • TypeScript
    • 静的型付け
  • AtomicDesign
  • Storybook

コマースカンパニーの取り組み(Yahoo!ショッピング)

  • UIパーツを抽出して共通化
    • AtomicDesign
    • Storybook
  • 技術
    • React
    • TypeScript
  • UIパーツ集をnpmで社内に配信
    • Reactを使ってれば使い回せる
    • エンジニアも気軽にデザインを作れる
    • Material Designの社内版みたいな

Webフロントエンド技術室の取り組み

  • 横断的な組織
    • ヤフー全体のフロントエンドの課題を解決
    • フロントエンドエンジニアが少ないようなサービスもある
  • ライブラリの効率化
  • 統一的なパフォーマンス計測方法の検討
  • ヤフーのWebフロントエンドの状態把握
  • 技術選定と浸透

技術の統一

コンピュータビジョンを支える深層学習技術の新潮流

  • 鮫島 正樹[アマゾン ウェブ サービス ジャパン]

コンピュータビジョンとは

  • 人間のようにコンピュータに視覚をもたせようとする技術

コンピュータビジョンの動向

  • 精度やスピードが飛躍的に向上
    • 画像認識
    • 物体検出
    • セグメンテーション
  • 少量データに対する挑戦
  • 敵対的画像の生成と防御
    • DeepLearningのモデルはノイズに弱い

コンピュータビジョンの開発技術

ハイレベル実装を実現するFW

  • FW
    • TensorFlow
    • Gluon
    • Chainer
    • PyTorch
  • 実装/学習済みモデルを配布

ONNX

  • Open Neural Network Exchange
  • 各種FWのモデルをONNXに変換
  • ONNXから各種FWへ変換

Define-and-runとDefine-by-run

  • Define-and-run
    • ネットワークを定義してからデータを入力
  • Define-by-run
    • ネットワークを定義しながらデータを入力
  • Define-by-runの方が効率的
    • デバッグしやすさだけでなく実行効率も良い

AutoML

  • 必要なタスクを自動化うするAutoMLの研究が進む
  • 自動でデータ収集・整備
  • 自動で最適な機械学習を実行

コンピュータビジョンの運用技術

  • 運用の課題
    • モデルを効率よく推論する環境を容易に構築したい
    • モデルの推論結果の妥当性を評価できない
      • Interoretable ML

Model Server

  • 効率のいい推論環境を構築できる
  • REST/RPCでアクセスできる
  • TensorFlow Serving
  • MXNet Model Server

モデルコンパイラ

  • ハードウェアに応じてモデルを変換
    • 推論速度向上
  • 軽量なランタイムでも実行可
  • SageMaker Neo
  • TensorRT

Interoretable ML

  • 単純なモデル(決定木、SVM、GBT)
    • どのデータが予測/分類に有効か知ることができる
  • 深層学習(compute vision)
    • モデルの直接的な解析は困難
    • 画像を一部欠落させても正しく認識すれば残った部分が重要な箇所

コンピュータビジョンを支えるハードウェアの展開

  • 推論用チップ
    • AWS Inferentia
    • Intel Nervana
    • 学習用チップとは用途が違う
  • FPGA
  • エッジデバイス

まとめ

  • 精度速度の工場だけでなくアウリの幅も広がってる
  • 開発運用の効率化が注目されている
    • AutoMLといった自動化の研究も
    • AIの民主化
  • 深層学習によるコンピュータビジョンも実世界に応用するフェーズ
    • 推論チップエッジデバイスが今後活躍

みんなの暮らしを支えるAmazon S3の裏側、お伝えします

  • 焼尾 徹[アマゾン ウェブ サービス ジャパン]

Amazon S3の概要

  • Amazon Simple Storage Service
    • 安全に容量制限なくデータ保存可能
    • 2006/3リリース
  • Amazon Glacier(S3 Glacier)
    • 安全性とコスト効率を重視したアーカイブ向けストレージ
    • 2012/8リリース

Amazon S3の裏側

  • リクエストレート
    • 秒あたり100 PUT/POST/DELETE(書き込み)
    • 秒あたり300 GET(読み込み)
    • => 2018.7に大幅に上限上がった(3500 PUT*/5500 GET)
  • リクエストレートが上がってもレイテンシが直接的に短縮されるわけではない
  • S3の金額はオブジェクトの数とサイズ
  • ECRを使うと裏でS3が使われてる
    • ECR・・・コンテナイメージ置き場

「React.js meetup #6」に参加してきました

  • React.js meetup #6に参加してきました。

reactjs-meetup.connpass.com

  • @koba04さんのライブコーディングがいい刺激になりました!suspenseはまだunstableとのことですが早く使えるようになってほしいです!
  • Apolloはちょっとさわったことありましたが、Reduxの面倒なとこが減りそうだなという期待が広がりました!
タイトル 発表者
読みやすいコードの書き方のススメ @hmktsu
React HooksとReduxとProxy @dai_shi
ちょっと先のReact @koba04
ApolloとReactを使ったアプリケーション設計 @about_hiroppy

読みやすいコードの書き方のススメ

  • @hmktsuさん
  • 株式会社g&h

読みやすいコード

  • 他の人と作業する時流れが理解しやすい
  • 久しぶりに見ても迷わない

Reactのコードを読みやすくするポイント

eslint-config-airbnb

  • ルール厳し目
  • 誰が書いても似たようなコードになる
  • VSCodeの拡張と組み合わせてauto-fixもおすすめ

defaultProps

importの整理

  • 順番が適当だと分かりづらい
  • 順序のルールを決めておく

React HooksとReduxとProxy

  • @dai_shiさん

React HooksとReduxとProxy

  • function componentsで全て完結する仕組み

Redux とReact Redux

  • Reduxは99行だけ
    • React関係ない
  • React Redux
    • Reactに依存したライブラリ

React Reduxの代替

  • Reduxを使わずにHooksで同じようなことを実現
  • Reduxは使うけどReact Reduxは使わずに実現

Reduxの問題点

  • stateはグローバル
  • stateの一部の変更で関係ないcomponentまでレンダリングされてしまう
    • selector指定
    • memorizeする
    • auto-detectする

auto-detect

  • 何もしなくてもselectorを指定したときと同じように動かす
  • Proxyを使う
    • stateのうちどの部分が使われたか知ることができる
    • Proxyが重いけどなんとか使えるレベルでは動いてる

ちょっと先のReact

  • @koba04さん

ライブコーディング

コード

github.com

ApolloとReactを使ったアプリケーション設計

  • @about_hiroppyさん

GraphQL

  • サーバサイドでqueryを定義
  • エンドポイントは一つだけ

Apollo

Apollo Client

  • queryをサーバに投げる
  • 結果をUIに返す
  • キャッシュとかもやってくれる

apollo-link-state

  • ローカルの状態をGraphQLのクエリを使い処理する
  • mutation投げるときにローカルの処理もできる

ApolloとRedux

  • Reduxと比べてApollo
    • fetchのフラグ管理がとても楽
    • 部分更新が簡単
    • リモートとローカルを同一クエリで表現できる
    • 複雑な処理を書くのはあまり向いてない

まとめ

  • Apolloはエコシステム含めて充実している
  • Reduxのコード減らせる可能性高い

「Yahoo! JAPAN Tech Conference 2019」に参加してきました

  • Yahoo! JAPAN Tech Conference 2019に参加してきました。

techconference.yahoo.co.jp

  • 昨年参加してとても面白かったので今年も参加しました。
  • 技術の話だけでなく、それを使って何を目指しているかまで話してもらたえたセッションが多くありとても勉強になりました。
  • 講演中にも資料を見られるように事前に公開してくれたり、twitterのモーメントを即時に作成してくれたり参加者への配慮がありがたかったです。
タイトル 発表者 タイトル 発表者
13:00 基調講演 - (twitterまとめ) 藤門 千明 / 仲原 英之
14:00 もう道に迷わない! Yahoo! MAPにおけるAR体験 - (twitterまとめ) 徳元 健太 / 廣橋 孝紀 パスワードレス普及への取り組み/ヤフーのデータ戦略を支えるID連携 - (twitterまとめ) 三原 一樹 / 本間 洋光
15:00 ライブクイズ「ワイキュー」を生み出した"内因的モチベーションドリブン"/ワイキューが目指した"楽しい時間を作るデザイン" - (twitterまとめ) 善積 正伍 / 染矢 沙織 データの力で実現するYahoo!ショッピングのCRM - (twitterまとめ) 市丸 数明
16:00 ユーザーコミュニケーションの新たな武器、けんさくとえんじんの秘密 - (twitterまとめ) 武井 友里恵 ライブ動画配信サービス「ワイキュー」の作り方 - (twitterまとめ) 石井 直矢
16:25 LEAN XPを活用したユーザーの声を聞くものづくり 〜Yahoo! JAPAN タブレットアプリのリニューアル〜 - (twitterまとめ) 馬場 敬寛 豊かなスポーツライフの実現を目指す、スポーツナビのシステムアーキテクチャ - (twitterまとめ) 北村 央斗
17:00 拡張性あるデザインシステム構築から挑む、GYAO!のウェブリニューアル - (twitterまとめ) 浜田 真成 Kubernetesで実現したYahoo! JAPANの次世代開発環境 ~ 100以上のクラスタを少人数で運用する秘訣 ~ - (twitterまとめ) 稲津 和磨 / 勝田 広樹
18:00 CtoC配信サービスのバックエンドからiOSアプリまで ~ヤフオク!ライブの全貌とXP開発~ - (twitterまとめ) 出水 厚輝 / 大西 智也 / 山下 真一郎 Yahoo! JAPANの巨大インフラの運用と展望 - (twitterまとめ) 奥村 司 / 神尾 皓 / 安藤 格也

基調講演

テーマ

  • 未来につづく話をしよう

yahooの取り組み

  • インターネットを通じていろいろなサービスを提供している
    • Search, Know, Read, Pay, Notify, etc...

Technology

  • いろんな技術
    • Search-Tech
    • AD-Tech
    • UI/UX
    • Security-Tech
    • Recommend-Tech
    • Fni-Tech
  • 共通点はデータxAI
    • データからよりよいモデルを作る
    • よりよいコンテンツでユーザが増える
    • データが増えるのでよりよいモデルを作れる
  • 足りなかったもの

kukai

  • 2015年から開発してる
  • 2017年リリース
  • GPUのサーバ
  • 液体につけて熱を冷ましてる
    • どうしても電気代がかから
    • 電力使いすぎは持続性がない
  • スパコンのノウハウない
    • 「データとAI」でチューニングに挑戦

kukaiを使った効果

ヤフオク

  • 不適切な商品が出品される
  • kukaiでAIを使った
    • 排除の量が3.1倍
    • モデルのビルドが1.5hで終わる
      • 毎日モデルを変えられる
      • 従来は100h

yahoo知恵袋

  • 不適切な質問や回答がある
  • kukaiを使ってランキングが上に来ないようにとか隠すことができた
  • 全質問回答(6億)を学習させた

大切にしてる技術

  • Security-Tech
  • 安心して使ってもらうために必要

セキュリティの取り組み

  • セキュアな通信レベル向上
  • 2018/6~TLS1.2に切り替え
  • 暗号化すると通信量が増えるコストが増加する

yahooの取り組み

  • HTTPS
    • 2017年中に全サービス移行済み
  • TLS1.2
    • 2018/6までに決済サービス移行済み
    • 2018/10に全サービス移行済み

TLS1.2へ

  • TLS1.2にする不都合
    • 対応していなブラウザを使ってるとみれなくなる
    • 全体の3%
  • 移行の戦略
    • 売上よりも安全を優先
    • 全サービス移行
      • 決済系以外も
    • 早めに広く告知
  • 次はTLS1.3
    • OpenSSLのバージョンを1.1にあげないと使えない
    • 今後取り組んでいくことになる

CI/CDの重要性

  • セキュリティの対応はすぐに反映させないといけない
  • CI/CDがととのっているとすぐにリリースできる
  • CIの中で問題を事前に検知できる取り組みも進める
  • DevSecOps

パスワードレス普及への取り組み/ヤフーのデータ戦略を支えるID連携

  • 三原 一樹さん
  • 本間 洋光さん

Yahoo! Japan IDの現状

  • ヤフー
    • EC事業
    • メディア事業
  • ヤフーIDユーザ
    • 4587万

これまでのパスワードレスの取り組み

課題

  • セキュリティとユーザビリティの両立
  • パスワードを忘れたことがある:96%
  • パスワード使いまわしてる:73%
  • => ログインが手間、不正アクセスのリスク

解決策

  • パスワードレス化

SMS認証

  • パスワードをそもそも設定させない
  • ID入れるとスマホにメール
  • 確認コード入力しログイン
  • ユーザビリティ面でまだ改善余地あり

生体認証

  • FIDO
    • セキュリティと利便性の両立を目指す
  • パスワード認証
    • ユーザの入力とサーバが保持しているものを検証
  • FIDO認証
    • 端末で検証し端末上の秘密鍵で暗号化
    • サーバ側で公開鍵で復号できれば認証
    • サーバに生体情報が送られるわけではない
    • Webで実現する -> FIDO2

今後

  • パスワードレスログインの訴求
  • 対応デバイス拡大(今はAndroidでしか実現できない)

yahooのデータ戦略とID

  • 提供サービス100以上
  • ヤフーID連携で他サービスと連携
    • データの蓄積
    • データの活用

アプリ利用の促進

  • ブラウザのログインを引き継ぐ
  • ログインしてるからこその機能を提供
  • ヤフーIDを使うアプリのどれかでログインしてればそれが引き継がれる
  • 月間4587万ユーザ

ヤフーID連携

  • OpenID Connectを使っている
  • Webもアプリも同じIDでログインできる

他サービスでの利用

  • ヤフーIDでログインできるようになる
  • ヤフーIDに紐づく情報が連携可能

事例

  • ヤマト運輸
  • ヤフーIDでクロネコメンバーズにログインできる
    • ログイン時に住所等の提供の同意画面
    • クロネコ側でヤフーに登録してる情報を使える
  • クロネコ側での配送予定情報をヤフーに提供
    • ヤフーアプリのプッシュ通知で配送予定を知らせる
    • 配送情報の提供もID連携時に同意をとる

まとめ

  • データ活用にはログインしてもらうことが大切
  • 社外と連携することでできることが増えてくる

データの力で実現するYahoo!ショッピングCRM

  • 市丸 数明さん

Yahoo!ショッピングCRM

  • CRM - 顧客関係管理
  • ユーザの行動属性を分析
    • ユーザの買い物の満足度を上げる
    • 売上を最大化する
  • データをもとにユーザにフィットした対応をする
    • 通知を無視し続けるひとは自動で配信停止するとか
  • リアル店舗にはできないCRMを実現する
    • 1 to 1の対応はリアルに勝る

CRM実現の仕組み

  • CRM5w1hで考える
  • UI - 接点
    • Web、アプリ、通知
  • EDW - データ
    • ユーザのデータをためてる
  • CRM - 施策管理

Yahoo!ショッピングならではのしくみ

  • 一周たりともページを止めてはならない
    • フロントとバックのJSを分けてる
  • 非機能要件のSLAが高い
    • 数万qpsを捌く
    • 200ms以内
  • 数千万件のユーザにPush配信を行う
    • 同じオファーを二回送ってしまうとかは絶対ダメ

事例①

  • 離脱直前ユーザへのオファー
  • CVRを確認すると特定のPV数で一回落ち込む
    • 離脱しやすさにスコアをつける
    • スコアが一定以上になったらオファーを出す

事例②

  • 定期購入リマインド
  • 定期購入対象の商品の定義
    • 同じカテゴリに属する商品を2回以上
    • 多くのユーザが該当するもの
  • 再購買時期の予測
    • サンプルユーザのデータをもとに分析
    • 商品に応じて通知するタイミングをチューニング

これからのCRM

  • Whenの最適化
    • データ分析・利活用をリアルタイム化
    • 今は毎日バッチで処理
  • サービス間のデータを相互利用
    • 他サービスのデータをもとにオファー
    • 似たユーザの統計情報をもとにオファー
  • システムをマイクロサービス化
    • CRMはモノリシック
    • DDDでリプレイス中

まとめ

  • yahoo全てのデータを活用
  • リアルタイム化
  • 最新アーキテクチャで実現
  • 究極の1 to 1へ

ライブ動画配信サービス「ワイキュー」の作り方〜優れた社内技術で実現する、少人数のサービス開発〜

  • 石井 直矢さん

ワイキュー

  • 3人だけでで開発してる
  • ライブ動画配信
  • コメント
  • 出題/回答
    • 短時間にアクセスが集中する
  • Tポイント
    • リアルタイム性より堅牢性

まとめ

  • 多くの機能が社内のプラットフォームで提供されている
    • ライブ配信とか不正ワード検知とか
    • ログインとかCI/CDとかも
  • 機能ではない部分を考えることにも集中できた
    • どうやって楽しく使ってもらうか

豊かなスポーツライフの実現を目指す、スポーツナビのシステムアーキテクチャ

  • 北村 央斗さん

スポーツナビ

  • 月間平均PV:46億
  • 月間平均UB:5710万
    • UniquBrowser

スポーツナビのシステム

  • 豊富なデータを使うシステム
    • 幅広い競技の情報
    • 競技に特化した詳細な情報
  • データ提供元と連携して表示している

プロ野球速報アプリ

  • 一つの画面に様々なデータ
  • 一球ごとの結果をリアルタイムに届ける
    • 提供元から受け取ったデータをすぐにアプリへ届ける

今後

  • データが増えても保守し続けられる仕組み
  • 取り扱う競技を拡充しやすくする仕組み
    • 競技横断のシステム

スポーツナビの運用

  • 特定のタイミングで負荷増
    • オリンピックの羽生結弦の登場タイミングとか
  • CaaS/PaaSへの移行を進行中

拡張性あるデザインシステム構築から挑む、GYAO!のウェブリニューアル

  • 浜田 真成さん

GYAOのリニューアル

  • レガシーWebからの脱却
    • 10年続くモノリシック
  • 既存プロダクトを維持して事業目標を達成

課題

モノリシック(FatView)

  • ロジックとViewが混ざってる
    • リファクタできない
  • ロジックが局所化

テストの欠如と手動リリース

  • テストは手動で
  • リリース作業1時間

セマンティックWeb

UI一貫性の破綻

  • 同じような部品

パフォーマンス

  • 初期描画が遅い

仕様の複雑化

  • 暗黙の了解で仕様が分からない
  • ドキュメント内

複雑なワークフロー

  • 直列なやりとり

技術戦略

Webアーキテクチャの段階移行

  • 段階移行
    • 並行稼動期間がある
  • phase1
  • phase2
  • pahse3
    • PaaSへ移行
    • TypeScript導入

パフォーマンス改善

  • パフォーマンス指標
    • RAILモデルをベースにサービス固有のものを追加
      • 動画の開始は2秒以内
  • 初期表示の速度改善
    • TTIやFMPの指標を重視
  • APM採用

コンポーネントシステム

  • AtomicDesignの思想をベースに
    • Page - Layout - Components - Basic
  • 関数型的なinputに対してoutputが一意になるコンポーネント

デザインシステム

  • デザインをプロダクトに届けるまでのプロセスを「仕組み」にする
  • 仕様の更新と開発をあわせて行う
  • ポイント
    • 常にコンポーネントの粒度で考える
    • 信頼できる唯一の情報源を作る
    • UI/UXの意図を残していく

組織を変える

  • 運用を止めない
    • システムの考え方を普及させる
    • システムを学ぶバックアップ体制

まとめ

  • 負債を確実に解消
  • 技術選択と移行プロセスを見極めよう
  • デザインシステムによってプロセスを構築する

今後

  • マイクロサービス化
  • パフォーマンスのさらなる改善
  • PWA(キャッシュの有効活用)

CtoC配信サービスのバックエンドからiOSアプリまで ~ヤフオク!ライブの全貌とXP開発~

  • 出水 厚輝さん / 大西 智也さん / 山下 真一郎さん

ヤフオク

  • 1999年から続くCtoC ECの老舗
  • 一分間に2000個出品
  • 年間8800億円の流通

ヤフオクライブ

  • リアルタイムに動画配信しながらオークションできるサービス

バックエンド

リアルタイムコミュニケーションシステムをどう構成するか

  • 不特定多数ユーザの双方向通信
    • いいねとかコメントとか
  • サーバ側からのプッシュ送信
    • 商品の追加/入札/落札
不特定多数ユーザの双方向通信
  • WebSocketで双方向通信実現
  • 膨大なユーザをどう扱うか
    • 複数台のサーバどう同期するか
    • RedisのPubSubを使ってる
サーバ側からのプッシュ送信
  • RedisのPubの部分を使ってる

ヤフオク!の既存機能値どのように共存させるか

アーキテクチャ
  • モノリシック
    • 多人数で開発するとコンフリクト
    • 通信レイテンシは小さい
    • プログラム肥大化
  • マイクロサービス
    • 多人数での並行開発が容易
    • 各プログラムを小さく保てる
    • サーバ間の依存性の管理が複雑化
  • マイクロサービス化へ
バックエンドの構成
  • ヤフオクだけで40機能がある
    • そこにライブの機能を追加
    • 商品へ依存が集中してしまう
    • 更新がいらない情報は各機能がコピーを作ってそれを使う
  • 機能ごとにプラットフォームを選択できる
    • FaaS/PaaS/CaaS/IaaS
    • マイクロサービス化されたからそれぞれ選べる

iOSアプリ

  • WebSocketでやりとり
  • リアルタイムなUIの変化
    • タイミング
    • 画面の状態
    • 大量・連続
  • アニメーション
    • 自前で実装
      • ユーザのインタラクションが発生するもの
    • Lottie
      • jsonをもとに作る
      • デザイナーが自由にこだわることができる

分析の取り組み

  • 配信者の声をもとに改善したい
    • 全部見るわけにもいかない
    • 文字起こしする(Speech to Text)
    • それを分析にかける(形態素解析)

開発手法

課題

  • 開発効率低下
  • 品質低下
  • 属人化

解決法

まとめ

  • テストがあれば細かいバグにも気づける
  • テストがあるから自身を持ってリファクタできる

「Bonfire Frontend #3」に参加してきました

  • Bonfire Frontend #3に参加してきました。

yj-meetup.connpass.com

タイトル 発表者
技術刷新から考えるWeb開発のプロダクティビティ改善 竹野 峻輔 / Retty 株式会社
一休.comのフロントエンドパフォーマンス改善 宇都宮 諒 / 株式会社一休
パフォーマンス改善の具体例とサービスへの売上貢献 笹原 翼 / ヤフー株式会社

技術刷新から考えるWeb開発のプロダクティビティ改善

  • 竹野 峻輔さん(Retty 株式会社)

フロントエンド戦国時代

  • 一昔は
  • 今は
    • BFFとかFluxとか
  • 明らかなパラダイムシフト
    • サーバ主体からクライアント主体へ
  • Rettyの現状
    • モノリシックが不便になってきた
    • 中長期的な視点で改善したい
    • アーキテクチャ

なぜリアーキテクチャ?

  • なぜ?
    • パフォーマンス改善(UX)を持続的に行うための土壌(DX)を築いて行く取り組み
  • マイクロサービス化
    • ただ分割するだけではだめ
    • 境界に注目する
  • 凝集化と分割(modukaruze)
    • 性質が近いものをまとめる
  • 持続的な変更可能性の確保(sustainability)
    • 拡張削除がしやすいように
  • プロダクトもチームも作り変える
    • コラボレーション
    • 親和性
      • チームとして力を集約する

一休.comのフロントエンドパフォーマンス改善

一休のサービス

  • 一休.com
    • ユーザ単位でのコンテンツ出し分け
    • 広告はなし
  • 一休コンシェルジュ
    • WordPressベース
    • ログインなし全員同じコンテンツ

最適なパフォーマンス

最適化のものさし 

  • Lighthouse
    • いろんなところに組み込まれるようになってる
    • 毎回同じ環境で測定するのがいい
    • PageSpeed Insightsなど
  • PageSpeed Insights
    • URLを入れるだけ
    • 細かい設定はできない
  • WebPageTest
    • 環境の条件を設定できる
    • デフォルトで3回計測してくれる

Lighthouseのスコア

  • スコア
    • 0-49: Slow
    • 50-89: Average
    • 90-100: Fast
  • 指標
    • TTIが一番重みが強い
  • スコアと指標どっちみる?
    • スコアはいろんな指標の組み合わせ
    • 仕様変更でも変わる
    • 具体的な指標を見た方がいい
    • スコアは他のサイトとの相対評価で便利
  • ECサイトなら
    • 50こえれば速い方
    • 70超えたら業界トップクラス
  • メディアサイトは
  • 30-40くらいが多い
    • 最適化をあまり頑張っていないようなところがこの辺

Webサイトの一般的な最適化

  • 速くするより遅い要素を減らす
  • 遅い要素
    • サイズの大きな画像/フォント
    • JS
    • 大量のHTTPリクエス
    • 重いDBアクセス
  • 一休.comの場合
    • キャッシュきかせづらい
      • リアルタイム性が重要
      • 検索クエリ
    • 画像サイズ適正に
      • Imgix
      • 欲しいサイズのパラメータつけて取りに行くと加工して返してくれる
      • https://www.imgix.com/
  • 一休コンシェルジュ
    • 全員同じコンテンツを返すのでキャッシュしやすい
      • Fastlyでキャッシュ
      • TTFB最小化10-20ms
    • 画像最適化
      • Imgix
    • JSできるだけ使わない
    • AMPの活用

パフォーマンスのためのアーキテクチャ

  • パフォーマンスに影響のある要素
    • SPAかMPA
    • SSRするか
    • CDNキャッシュ戦略
    • ServiceWorkerの活用
  • JAMStack
    • サーバサイドはAPIのみ静的HTMLのみ
      • SSRしない
      • キャッシュがきくようになるから
    • レンダリングは全てJSということ
      • SEO問題
      • DynamicRendering
        • Googlebotに対してJS描画済みの静的HTMLを返す
        • 実験中

まとめ

  • パフォーマンス最適化は計測から始まる
  • パフォーマンスの伸びしろは要件次第
  • 大幅なパフォーマンス改善にはアーキテクチャレベルの変更が必要

パフォーマンス改善の具体例とサービスへの売上貢献

  • 笹原 翼(ヤフー株式会社)

ヤフーショッピングのパフォーマンス改善

  • ヤフーショッピングのパフォーマンス改善
    • => ページの表示速度アップ
  • 半年でCVRが110%へ

なぜパフォーマンス改善

  • 改善前
    • FirstViewをAmazon楽天と比べると3位
    • 表示速度0.1廟宇減ると売上1%増加(Amazon)
  • ヤフーショッピングでの進め方
    • 速度とKPIの相関をABテストで証明

どこでパフォーマンス改善

  • どのページ
  • Frontend/Backend
  • クライアント/サーバ

どのページ

  • アクセスが多いページ
  • そこを通って買う人が多いとこ

Frontend/Backend、クライアント/サーバ

  • SpeedCurve
    • 定期実行できる
    • グラフ化できる
    • 色んな指標とれる
    • 競合比較できる
    • 改善結果が見やすい
    • 5万回まで測定可で月5万

どんなパフォーマンス改善するか

  • どの指標を見ていくのか決める
  • 安定した測定環境を整える

遅い/直列APIの非同期化

  • ファーストビューの扱いは注意

間違った非同期

  • 画像は全部lazyloadingすればいいわけじゃない
  • 思考停止lazyよくない

画像のpreload

  • 読み込み開始が速い

JSとCSSのpreload

  • 前のページで次のページのリソースとっておく

JSとCSSの非同期読み込み

  • 無理なら1ファイルの容量を減らす

画像の最適化(画質)

  • 画質90 -> 85に変更
    • 容量40%減
    • 50ms減

画像の最適化(解像度)

  • Retina対応
  • 適したサイズを

ハードのリプレイスすけ^ルアウと

  • 高スペックで高速化

JSとCSSの軽量化

  • カバレッジを見て使ってないリソースは削る
    • Devtoolsで見られる

どんな効果があったか

  • 競合3社中2位に
  • CVRが110%へ
  • SEOにもいい影響
    • クロール量の増加

今後

  • 更にパフォーマンス改善
  • AMP?
  • 計測は実ユーザデータ使いたい