Engineer Blog

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

<p>デザインエンジニアの安田（<a href="https://x.com/_yuheiy">@_yuheiy</a>）です。</p>
<p>プレイドの多くのシステムでは、サーバーサイドの実行環境としてNode.jsを採用しています。そのため、サーバーサイドもクライアントサイドもまとめてnpmを使って依存パッケージ（dependencies）を管理している場合がほとんどです。</p>
<p>システムのメンテナンスにおいては、このような依存パッケージのバージョンを継続的にアップデートし続けることが重要です。そこで今回は、社内向けに実施した、依存パッケージのバージョンアップをテーマにした発表を一部再編集してご紹介します。</p>
<h2>なぜ依存パッケージのアップデートが必要か</h2>
<p>筆者が所属するDeveloper Experience &amp; Performanceチーム（通称: DXチーム）では、その活動の一つとして、さまざまなシステムの依存パッケージのバージョンをアップデートして回るような作業をする機会がよくあります。DXチームでは、現在アクティブに開発が行われていない一部システムのメンテナンスを担当したり、既存のチームの開発をヘルプしたりする場面があり、その一環として併せてこのような作業を行っています。</p>
<p>依存パッケージをアップデートすることには、おもに次のような理由があります。</p>
<p>まず最初は、Node.jsのバージョンアップに対応するためです。Node.jsのバージョンアップにともなって古いバージョンの依存パッケージが動作しなくなることがあるので、Node.jsに追従するために必要な作業です。</p>
<p>次は、一般的なソフトウェア品質や開発効率の向上のためです。多くのパッケージはバージョンアップにともなって、動作上のバグの修正やパフォーマンスの改善、セキュリティ上の問題の解決が行われているほか、便利な新機能が追加されたりしています。これによってソフトウェアの外部品質が改善したり、余計な実装が不要になって設計がシンプルになったりする可能性があります。また、古いバージョンのパッケージを使い続けていることで、それに携わる開発者が古いバージョンの使い方を調べたり覚えたりといった無駄な学習コストを払わなければならないという問題もあります。</p>
<h2>デザインシステムの最新化のために</h2>
<p>もう一つの理由は、利用されているデザインシステムを最新化するためです。社内向けのデザインシステムであるSourが多くのシステムに導入されていますが、Sour自体の内容は日々アップデートされ続けている一方、各システムで利用されているSourのバージョンはアップデートされずに古いものが使い続けられていることが少なくありません。</p>
<p>参考までに、<a href="https://karte.io/">KARTE</a>のリポジトリにおいて使用されているSourのバージョンは次の通りです（件数は発表時のもの）。</p>
<ul>
<li>4.x: 5件（うち3件はDXチームが管理するシステム）</li>
<li>3.x: 5件</li>
<li>2.x: 11件</li>
<li>1.x: 2件</li>
<li>0.x: 1件</li>
</ul>
<p>筆者の本務はSourの開発ですが、ユーザー側でのバージョンアップが行われなければ開発している意味がありません。そのため私自身がそのアップデート作業を担当することもありますが、それに併せてその周辺環境を整備しなければならない場面もあります。というのも、Sour自身が依存しているパッケージのアップデートにともなって、ユーザー側の関連するライブラリのアップデートをしなければならなくなったり、もしくは、そのようなアップデートにともなう問題が発生しないかをテストするための環境が必要になったりすることもあるからです。</p>
<h2>タイミングが遅れるほどアップデート作業が難しくなる</h2>
<p>一般的に、依存パッケージが古くなればなるほど対処が必要な問題が増えて複雑化し、作業が難しくなる傾向にあります。特に古いシステムをメンテナンスしていると、複数の古い依存パッケージ同士が絡み合う問題が発生してデバッグが難しくなったり、古いバージョンで想定されていなかった環境依存の問題が発生して解決のために余計な手間を取られたりすることがよくあります。</p>
<p>また、関連する機能を担当した当時の開発者がチームや会社を離れたりしていることもあります。アップデートにともなう動作確認が必要になることがありますが、そのような場合、期待される正しい仕様や動作確認の方法がわからなくなる可能性もあります。あるいは、当時の担当者にしか意図を理解できないトリッキーな実装が行われているような場合もあります。</p>
<h2>「システムのメンテナンスは天下の回りもの」</h2>
<p>これは昔から個人的に唱えている理論です。システム開発の仕事をしていると、知らない誰かが作ったシステムを回り回って自分が引き継ぐというような場面は珍しくありません。そして、自分が作ったシステムもいずれまた別の誰かに引き継がれていくことになります。</p>
<p>システムの出来の良し悪しにかかわらず、引き継いだ人にはそのすべてを引き受ける責任が生じます。だからこそ、後任の誰かのために、自分が今担当しているシステムはできるだけ良い状態にしておくという心づもりでいることが大事だと思います。</p>
<h2>作業の進め方</h2>
<p>具体的な話に移ります。</p>
<p>まず、これから説明するような作業にあたっては、さまざまな観点でのソースコードの変更をしなければならない場合があります。そのため、必ずしも1つのpull requestで一気に対応しようとするのではなく、適切な粒度に分解しながら作業を進めてください。これについては普段の機能開発と同じです。</p>
<p>次に、CIが不十分だと感じる場合はあらかじめ整備しておくのがよいです。作業を細かく分割するほど、人力ではチェックの抜け漏れが発生しがちです。変更にともなうテストを効率的に行うために、できるかぎり自動化してしまいましょう。</p>
<h3>不要な依存パッケージを削除する</h3>
<p>アップデートの前に、不要な依存パッケージがあればあらかじめ削除しておきます。使わないものをアップデートしても仕方がないからです。</p>
<p><a href="https://knip.dev/">Knip</a>を導入することで、未使用の依存パッケージやデッドコードの検出ができます。これらを削除することで余計な要素を削れます。さらに、KnipをCIに組み込むことで、今後余計なものが追加されないように予防することもできます。</p>
<p>また、そのほかにも不要な機能などが残っていれば削除しておきます。</p>
<h3>言語の標準機能に置き換える</h3>
<p>Node.jsのアップデートにともなって、これまでサードパーティのパッケージが必要だったことが、Node.jsのコアの機能として実現できるようになっていることがあります。「<a href="https://zenn.dev/morinokami/articles/npm-uninstall">Node.js の進化に伴い不要となったかもしれないパッケージたち</a>」などを参考にして置き換えてください。</p>
<p>また、ECMAScriptやDOM仕様のアップデートにともなって、同じくサードパーティのパッケージが不要になることもあります。「<a href="https://github.com/you-dont-need/You-Dont-Need">You-Dont-Need</a>」などが参考になります。</p>
<p>依存パッケージを減らしてコアの機能に置き換えていくことで、将来的なメンテナンスコストを削減できることになります。</p>
<h3>package.jsonのアップデート</h3>
<p><code>package.json</code>に記述されている<code>dependencies</code>や<code>devDependencies</code>のバージョンをアップデートする際には、次のようなコマンドを使用すると一気に書き換えができて便利です。<code>--interactive</code>オプションを指定することで、アップデートする対象をチェックボックス方式で選択できます。</p>
<p>npmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
npx npm-check-updates --workspaces --root --interactive
</code></pre>
<p><img src="https://ik.imagekit.io/plaid/9266d5fd-ceff-47f0-a94e-7d78bcfe707e/ncu.png" alt="新しいバージョンが存在するdependenciesのうち、必要なものを選択式でアップデートできる。パッケージごとに現在のバージョンとアップデート後のバーションが表示される。"></p>
<p>出典: <a href="https://github.com/raineorshine/npm-check-updates">raineorshine/npm-check-updates: Find newer versions of package dependencies than what your package.json allows</a></p>
<p>pnpmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
pnpm update --latest --recursive --interactive
</code></pre>
<p>pnpm 10.12以降であれば、catalogsで管理しているバージョンもいっしょにアップデートできます。</p>
<p>またロックファイルは壊れやすいので、インストールに際して問題が発生した場合は再生成してみるとよいです。</p>
<pre><code class="language-bash">rm -rf package-lock.json **/node_modules &amp;&amp; npm install
</code></pre>
<h3>破壊的変更への対応</h3>
<p>セマンティックバージョニングにおいては、メジャーバージョンが上がるか、もしくは1.0.0に満たない場合のバージョンアップでは、常に破壊的変更の可能性があります。そのためアップデートをする前には、ざっとでもいいのでパッケージのCHANGELOGに目を通しておくことをおすすめします。</p>
<p>また、最新版よりもいくつも古いバージョンを使っている場合は、破壊的変更が積み重なって簡単にアップデートできないことがあります。そのような場合、バージョンは一気に上げるのではなく、ある程度の区切りに分けて段階的にアップデートしたほうが作業が簡単になります。</p>
<h3>後継のライブラリに置き換える</h3>
<p>場合によっては、あるパッケージの代わりとなる後継のパッケージ（ライブラリ）が登場しているがあります。既存のパッケージがメンテナンスされなくなったり、アーキテクチャが古くなって根本的な刷新が必要になったりしたときに、それを置き換えるために別のものが開発されて、コミュニティでもそちらが主流になっていくというパターンです。</p>
<p>KARTEでよく使われているところで言えば、次のような後継のパッケージがあります。</p>
<ul>
<li>Jade → <a href="https://pugjs.org/api/getting-started.html">Pug</a>（参考: <a href="https://github.com/pugjs/pug/issues/2184">Renaming jade -&gt; pug · Issue #2184 · pugjs/pug</a>）</li>
<li><a href="https://github.com/TypeStrong/ts-node">ts-node</a> → <a href="https://tsx.is/">tsx</a>（もしくは、<a href="https://nodejs.org/api/typescript.html#type-stripping">Node.jsのtype stripping</a>を使う）</li>
<li><a href="https://jestjs.io/">Jest</a> → <a href="https://vitest.dev/">Vitest</a></li>
<li><a href="https://recoiljs.org/">Recoil</a> → <a href="https://jotai.org/">Jotai</a></li>
<li><a href="https://lodash.com/">Lodash</a> → <a href="https://es-toolkit.dev/">es-toolkit</a></li>
<li><a href="https://github.com/raineorshine/npm-check-updates">npm-check-update</a> + <a href="https://github.com/ds300/patch-package">patch-package</a> + <a href="https://github.com/open-cli-tools/concurrently">concurrently</a> → <a href="https://pnpm.io/">pnpm</a> CLI（同等の機能がpnpmに組み込まれている）</li>
</ul>
<p>既存パッケージのアップデートと併せて、後継のパッケージへの移行も行いましょう。</p>
<h3>気になる部分はついでに改善しながら進める</h3>
<p>パッケージのアップデート作業をしていると、それに関係するほかの部分が気になることもあります。気になった部分についても、そのままにしておかず、せっかくなのでついでに改善してしまうのがよいです。たとえば次のようなものです。</p>
<ul>
<li>CIの構成をきれいにする</li>
<li>いらないnpm scriptsを消す</li>
<li>冗長な設定ファイルをクリーンアップする</li>
<li>deprecatedなメソッドの使用箇所を直す</li>
<li>破壊的変更がある箇所の周辺のコードをリファクタリングする</li>
</ul>
<p>このようなメンテナンス作業は普段は軽視されがちで、ともすれば老朽化した仕組みがそのまま何年も動き続けていることになりがちです。だからこそ、みなさんにはぜひ<a href="https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html">ボーイスカウト・ルール</a>を意識してもらいたいです。</p>
<blockquote>
<p>ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです（このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています）。</p>
<p>これに倣ってコーディングに関しても同じルールを定めるとしたら「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」となります。最初にそのモジュールを書いたのが誰であるかに関係なく、皆がそうやって、たとえ少しずつでもモジュールを改善する努力を続けたとしたら、その結果どういうことが起きると思いますか?</p>
</blockquote>
<p>出典: Kevlin Henney編、和田卓人監修『プログラマが知るべき97のこと』、オライリージャパン、2010年</p>
<h2>こまめなアップデートを習慣化する</h2>
<p>アップデート作業は後回しにするほど面倒な問題を引き起こしがちです。善は急げと思って、まずは今日からやってみましょう。</p>
<p>いったんひと通りのアップデートができたら、それ以降も定期的にアップデートを続けられるように、次に作業する日を決めてしまいましょう。月に1回程度が目安です。もしくは、<a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot">Dependabot</a>などの自動化ツールを使って作業を自動化するのもよいと思います。</p>


Node.jsやフロントエンドのプロジェクトにおけるdependenciesをアップデートするうえでのよくある問題やうまく進めるためのコツなど。

package.jsonのdependenciesをアップデートする技術

Tailwind CSSのバージョンをアップグレードしてTailwind CSS 4に対応する際に作成した、Figmaのstylesをもとにして各種設定ファイルを自動生成する仕組みについての紹介。

Figmaのstylesをもとにして「Tailwind CSSのテーマ」「tailwind-mergeの設定」「Storybookのドキュメント」などの各種ファイルを自動生成する

<h2>はじめに</h2>
<p>こんにちは！</p>
<p>プレイドで６月から７月末までEngineerインターンとして働いていたアボンデットルイです。現在はアメリカのマサチューセッツ工科大学（MIT）でコンピューターサイエンスを専攻している大学生です。</p>
<p>高校でエンジニアリングに興味を持ち、知識を活かして価値のあるものを作り出せることに魅力を感じました。そこからプログラミングを始め、今ではコンピューターサイエンスのさまざまな分野を幅広く探求しています。</p>
<p>同じくCSを学んだ<a href="https://tech.plaid.co.jp/intern-at-plaid-avondet">兄が以前プレイドでインターンをした</a>ことがあり、とてもいい経験だったと聞いたので、僕も挑戦したいと思い今回応募しました。</p>
<p>今回が初めての日本の企業での実務経験で、エンジニアとして働くことの楽しさや難しさを実感しながら、たくさんのことを学ぶことができました。このブログでは、インターンでの経験を振り返りながら、自分が学んだことについて共有したいと思います。</p>
<h2>① UI基礎の習得</h2>
<p>インターンに参加する前から、個人でWebアプリをいくつか作っていたこともあり、特にフロントエンド開発にはある程度慣れていました。その経験を活かして、最初は<a href="https://karte.io/">KARTE</a>のフロントエンドに関わる開発に取り組みました。</p>
<p>インターン開始直後は、Vue.jsやKARTEのコードベースに慣れるため、比較的シンプルなUI改善のIssueをいくつか対応しました。たとえば、検索機能の追加、ツールチップによって長いタイトルを全文表示する対応、ユーザーの入力形式に応じて表示を変えるフォーマット処理など、ユーザー体験を少しずつ向上させるような細かい変更です。</p>
<p>このようなタスクは、一見すると単純で地味に思えるかもしれませんが、実際には多くの工夫が必要でした。どのように既存のコードと整合性を保ちながら変更を加えるか、パフォーマンスに影響がないように注意すること、そしてUIコンポーネントの再利用性を損なわないように設計することなど、意外と奥が深い作業でした。</p>
<p>また、Vue.jsを本格的に使うのは今回が初めてだったため、最初はコンポーネントの設計思想やReactとの違いに戸惑うことが多くありました。特にKARTEのコードベースは大規模で、どこに何が定義されているかを見つけるだけでも最初は時間がかかりました。</p>
<p>とはいえ、こういった小さなIssueを積み重ねる中で、だんだんとVue.jsの書き方にも慣れ、大規模なコードベースのスタイルや構造にも自然に馴染めるようになっていきました。レビューで指摘された内容を意識して、自分なりにルールやベストプラクティスを積み重ねていったことで、次第に自信を持ってコードを書けるようになりました。</p>
<p>この時期は、「まずは手を動かして学ぶ」ことの重要さを実感した期間でもありました。コードを書くこと自体は目的ではなく、ユーザー体験をより良くするための手段であるということを、タスクを通して実感できたと思います。</p>
<h2>② UI刷新の経験</h2>
<p>Vue.jsに慣れてきたころ、管理画面のあるページを新しいデザインに全面的に改修する、大きなUIの仕事を任されました。この仕事は、Figmaで用意されたデザインをもとに、今あるUIを最新の仕様に合わせて見た目を新しくするものでした。</p>
<p>この作業は、画面をゼロから作るのではなく、既存の構造をできるだけ活かしながら新しい条件を満たすという、バランスの難しいものでした。全てを作り直すか、一部だけ変えるか、既存のスタイルや使いやすさを考えて、自分で最適な方法を考えながら進めました。</p>
<p>特に苦労したのは、コードの中でどこにどんな処理やデザインが書かれているのかを見つけることでした。画面は複数のパーツに分かれていて、データのやりとりも複雑だったため、「どこをどう変えれば見た目も動きも正しくなるか」を理解するのに時間がかかりました。</p>
<p>最初は難しさを感じましたが、コードの中にある意図を理解する力が少しずつつき、「なぜこう書かれているのか」「どのパーツが何を担当すべきか」といった視点で実装の方針を決められるようになりました。自分なりに工夫した実装方法を考えながら進める中で、コードの理解が深まり、自信にもつながりました。</p>
<p>最終的にFigmaのデザインとぴったり合う画面が完成したときは、とても達成感がありました。そして何より、自分が作ったものが実際にユーザーに使われるという実感が、エンジニアとしてのやる気をさらに高めてくれました。</p>
<p>具体的なタスクとしては、<a href="https://support.karte.io/post/2lRnr05R5uTA0K8D5fDzBc">行動チェーン(β)</a>のフォルダ機能における改善と、<a href="https://support.karte.io/post/4MxyAWLgEopohX27lnCFjZ">ユーザー構成比</a>の画面改善でした。<br>
<img src="https://ik.imagekit.io/plaid/c59fea1b-53dc-4889-b32c-be2f20d3bdd1/2025-08-0616.49%E3%81%AE%E7%94%BB%E5%83%8F.jpeg" alt="2025-08-0616.49の画像.jpeg"></p>
<p><img src="https://ik.imagekit.io/plaid/075047ba-3bf1-410a-8726-09fa987a7e9a/2025-08-0617.05%E3%81%AE%E7%94%BB%E5%83%8F.jpeg" alt="2025-08-0617.05の画像.jpeg"></p>
<h2>③ バックエンドへの挑戦</h2>
<p>インターン後半では、「バックエンドにも挑戦してみたい」と相談し、データ周りのIssueを対応させていただきました。タスクの内容は、ある管理画面の既存のフィルター機能に新しい条件を追加するため、SQLクエリの生成ロジックを修正し、BigQueryを用いた集計処理に新しいフィルター条件を組み込むというものでした。</p>
<p>このタスクは、技術的にも認知的にも非常に難易度が高かったです。まず、BigQueryもSQLも初めて触る技術であり、構文や最適なクエリの書き方に慣れるまでにかなりの時間がかかりました。また、複数のイベントテーブルをJOINしたり、ユーザー単位で集約したりといった処理が必要で、そもそも「このデータがどうやって構成されているのか」を理解するところからのスタートでした。</p>
<p>特に苦労したのは、巨大なコードベースの中で「どこがボトルネックなのか」「この値はどこからきて、どこで使われているのか」といった、データの流れを追いかける作業です。関数が分散していたり、抽象化されているレイヤーが多かったりと、全体像を把握するには時間と根気が必要でした。</p>
<p>ただ、その分だけ得られる学びも大きく、「なぜデータ処理をこのように設計しているのか」「フィルター条件が一つ増えるだけでも、どのような設計的配慮が必要か」といった、普段の個人開発では触れない視点を身につけることができました。</p>
<p>最初は不安でしたが、バックエンド開発に興味を持てるようになったのは、自分にとって大きな成長の一歩でした。</p>
<h2>プレイドの文化</h2>
<p>今回のインターンで一番印象に残ったのは、プレイドの働きやすさとカルチャーでした。初めての実務経験だったので、最初はもっと簡単な作業ばかり担当するのかと思っていたのですが、実際には自分が関わったタスクはどれもプロダクトにしっかりと関係していて、やりがいのある内容でした。常にメンターの方がサポートしてくださり、困った時には丁寧に説明してくれたので、安心して新しいことに挑戦できました。最初はうまくいかないことも多く、戸惑うこともありましたが、その経験が逆に自分の成長につながったと感じています。</p>
<p>2ヶ月という短い期間だったので、自分が関われた範囲は限られていましたが、それでも多くの方が自分に声をかけてくれて、新しいツールや機能の開発に参加するチャンスを与えてくれました。タスクを進める中でも、自分の興味や学びたいことを考慮してくれる雰囲気があり、インターンとしてとても充実した経験ができたと感じています。</p>
<p>インターンに参加してから、一緒に機能開発を行うチームの定例ミーティングに参加し、他のメンバーがどのような仕事をしているのかを聞くことで、プロダクト全体の流れやチーム間の連携の重要性を学ぶことができました。日々のやりとりを通じて、インターンであっても一人のメンバーとして扱ってもらえる環境にとても感謝しています。</p>
<h2>最後に</h2>
<p>今回のインターンを通して、エンジニアとして働くことの楽しさや難しさをたくさん学びました。最初は不安もありましたが、周りの方がいつも助けてくれて、新しいことにも安心して挑戦できました。</p>
<p>実際にプロダクト開発に関わる中で、自分の書いたコードがプロダクトの一部になる経験はとてもやりがいがありました。うまくいかないこともありましたが、そのたびにサポートしてもらい、少しずつ自信を持てるようになりました。</p>
<p>2ヶ月という短い期間でしたが、いろいろな技術に触れ、チームの一員として働くことができたのはとても貴重な経験でした。今回の経験を通して、エンジニアとしてもっと成長したいという気持ちが強くなりました。これからもプレイドの成長を楽しみにしつつ、自分もこの経験を活かして努力を続けていきたいと思います！</p>
<hr>
<p>プレイドはエンジニアインターンを募集しています！　興味を持った方は是非応募してみてください！</p>
<p><strong>サマーインターン</strong></p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/106581"><div class="iframely-responsive" style="padding-bottom: 56.25%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/106581" data-iframely-url="https://cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F106581&key=878c5bef402f0b2911bf6d4ce6261abd">【26卒/27卒】エンジニアサマーインターン / 株式会社プレイド</a></div></div><script async src="https://cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p><strong>通期インターン</strong></p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/90783"><div class="iframely-responsive" style="padding-bottom: 30.2778%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/90783" data-iframely-url="https://cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F90783&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Engineer) / 株式会社プレイド</a></div></div><script async src="https://cdn.iframe.ly/embed.js" charset="utf-8"></script>


プレイドで2ヶ月間エンジニアインターンに挑戦した学生の体験記。Vue.jsでのUI改善・刷新からBigQueryを活用したバックエンド開発まで、幅広い技術領域で学んだ実務経験と成長の記録を詳しく紹介します。

プレイドインターン体験記：フロントエンドからバックエンドまで挑戦した2ヶ月

<h2>はじめに</h2>
<p>こんにちは、今年4月に新卒でプレイドに入社しエンジニアをしている佐藤と申します！普段は、社内で利用する<a href="https://open.talentio.com/r/1/c/plaid/pages/106299">内製のOLAPデータベースを開発するチーム</a>でお仕事をしています。</p>
<p>この度、プレイドは「<a href="https://sre-next.dev/2025/">SRE NEXT 2025</a>」にゴールドスポンサーとして協賛いたしました。当日はブース出展に加え、エンジニアの土谷が<a href="https://sre-next.dev/2025/schedule/#slot084">「大量配信システムにおけるSLOの実践 ：「見えない」信頼性をSLOで可視化」</a>というテーマでスポンサーセッションに登壇しました。</p>
<p>私自身もイベントに参加し、ブースの運営と多くのセッションを聴講しました。本記事では、当日のプレイドブースの様子や、個人的に特に印象に残ったセッションについてレポートします！</p>
<h2>ブースの紹介</h2>
<p>まずは、プレイドブースの様子からご紹介します。ブースでは、来場者の皆様と多岐にわたる技術的な議論ができるよう、以下の5つのトピックを用意しました。</p>
<ol>
<li>Production Readiness Reviewとは</li>
<li>リアルタイムユーザー解析エンジンのリアーキテクチャ</li>
<li>監査ログとは - なぜ重要なのか</li>
<li>KARTE BlocksのSLO</li>
<li>AIエージェントを用いたセキュリティレビュー</li>
</ol>
<p><img src="https://ik.imagekit.io/plaid/472905ef-0548-4eab-8787-fdf6eaf1ce62/IMG_4624.jpg" alt="IMG_4624.jpg"></p>
<p>ブースでは、来場者の方に興味のあるトピックへシールを貼っていただく企画を実施し、特にAI関連のテーマに多くの関心が集まっているようでした。</p>
<p>私はリアルタイムユーザー解析エンジンについて会話することが多かったので、そちらについて紹介します。プレイドでは、「KARTE」を通じて取得した膨大なデータを処理するために内製のリアルタイムの解析エンジン(「Blitz」と呼んでいます)を置いています。(<a href="https://tech.plaid.co.jp/deim_2025">このエンジンはデータ工学系のフォーラムであるDEIMに論文を投稿して</a>いたりします)。主にその内部の仕組みとリアーキテクチャについて議論させてもらいました。例えば、リアーキテクチャによってレイテンシが1500ms（結果整合性）からp95で200ms（強整合性）へと改善したことをお話しすると、プレイドの技術への投資姿勢とエンジニアの技術力について良い反応をもらうことができて嬉しかったです。</p>
<p>Blitzの詳細に関しては、論文以外にも以下のブログで紹介していますので、よろしければご覧ください。</p>
<ul>
<li><a href="https://tech.plaid.co.jp/blits_pre_aggregation"><strong>Blitz（前編）: 自由度と即時更新性を担保したAggregation</strong></a></li>
<li><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture"><strong>Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</strong></a></li>
<li><a href="https://tech.plaid.co.jp/blitz_performance_user_cache"><strong>Blitz: リアルタイムユーザー解析エンジンのボトルネックを解消したキャッシュ設計</strong></a></li>
</ul>
<p>また、現在私が開発に携わっているユーザー行動分析に特化した内製のOLAPデータベースについても、Kubernetesやコンテナランタイムといった技術を交えながらお話しでき、そちらに対する議論も大変盛り上がりました。</p>
<p>これらの技術的なコンテンツに加え、様々なノベルティ(カフェオレ、ラムネ、うちわ、歯ブラシなど)やSRE NEXT 2025のために作成したパンフレットも大変好評でした！</p>
<p><img src="https://ik.imagekit.io/plaid/47ac9bd5-c960-48a2-b847-6d4c5ec76de1/IMG_4578.jpg" alt="IMG_4578.jpg"></p>
<h2>参加セッションの感想</h2>
<h3><a href="https://sre-next.dev/2025/schedule/#slot044"><strong>Fast by Friday: Making performance analysis fast and easy(Brendan Gregg)</strong></a></h3>
<p>Brendan Gregg氏はフレームグラフを始めとした多くの可視化ツールの発案者であり、<a href="https://www.usenix.org/">USENIX</a>などの著名カンファレンスで基調講演をされており、私自身本セッションをとても楽しみしておりました。</p>
<p>このセッションでは、「Fast by Friday」——つまり、月曜日に発生したパフォーマンス問題をその週の金曜日までに解決するというコンセプトに基づき、システムパフォーマンスを迅速に分析・改善するための方法論が紹介されました。</p>
<p>例えば、「月曜日にはまず問題を定量的に分析する」「水曜日にはフレームグラフやeBPFを用いてプロファイリングを行う」といったように、1週間の各曜日で何をすべきかが具体的に語られました。第一線で活躍するエンジニアのパフォーマンスチューニングの過程を体系的に知ることができ今後の業務に大変活かせると感じました。</p>
<p>(SRE NEXT 2025での発表資料は見つけることができませんでしたが、<a href="https://www.brendangregg.com/Slides/eBPFSummit2023_FastByFriday/">こちらの資料</a>に内容は近いと感じましたので、ご興味ありましたら是非ご覧ください。)</p>
<p>セッション後のAsk the Speakerでは、私たちが開発しているOLAPデータベースのパフォーマンスについて少し相談してきました。特に印象的だったこととして、メモリ使用量の改善についてのアドバイスです。「プロダクション環境でメモリダンプを取得するとJVMのレイテンシが悪化してしまう」という課題に対し、「CPUのフレームグラフを分析してメモリ割り当てが多いコードパスを特定すれば、より低コストで問題の原因を突き止められるかもしれない」という助言をいただきました。また、データベースのような巨大で複雑なシステムのパフォーマンスを改善するためには、まずマイクロベンチマークを整備することが重要であると勧められました。実装には工数がかかりそうですが、コードを大量に生産することにはAIの活用も期待できるため、チームで検討し、整備を進めていこうと思います。</p>
<h3><a href="https://sre-next.dev/2025/schedule/#slot087">Intel SGXをAzureで本番運用するための構成事例と実践知見(株式会社Datachain SRE/テックリード 大久保 俊彦)</a></h3>
<p>TEE（Trusted Execution Environment）は、ハードウェア上の保護された領域でコードやデータを処理し、安全性を確保する技術です。例えば、メモリ上にデータを暗号化して保持し、CPU内部で復号化と処理を行うなどがあり、これにより、メモリを抜かれたとしても暗号が解読されない限りは、データを覗き見ることができなくなります。多くのCPU(ARM, AMD, etc.)がTEEをサポートしていますが、中でも強力なTEEの一つとして、Intel SGXがあります。</p>
<p>その仕組みの複雑さや具体的なユースケースのイメージが湧きづらい点から、私自身これまで深く学習できていませんでしたが、本講演では動作原理とユースケースに対する興味深い話を伺うことができました。(講演の後、大久保さんと2時間ほどお話しする機会をいただき、Intel SGXについてさらに深く学ぶことができ大変良い経験になりました。ありがとうございました。)</p>
<p>Datachain社では、異なるブロックチェーン間で資産やデータを安全に移動させるための「ブリッジ」という仕組みにIntel SGXを活用されています。このブリッジですが、暗号化が施されていない場合、内部の人間が直接メモリを盗み見ると仮想通貨の情報が見れてしまい、ユーザーの暗号資産を不正に操作できてしまうリスクがあります。(実際にブリッジの運用者の内部犯行によってユーザーの仮想通貨が<a href="https://www.chainalysis.com/blog/multichain-exploit-july-2023/">$120M抜き取られたという事件</a>が起きていたりします)。</p>
<p>Datachain社は、Intel SGXを用いることで運用者ですらアクセスできないセキュアな環境を構築し、ユーザーが安心して資産を移動できるサービスを提供しているとのことでした。</p>
<p>秘密計算という先進的な技術が、実社会の課題解決に貢献している様子を知ることができて、大変刺激を受けました。</p>
<h2>プレイドのセッションの紹介</h2>
<h3><a href="https://sre-next.dev/2025/schedule/#slot084">大量配信システムにおけるSLOの実践 ：「見えない」信頼性をSLOで可視化（プレイド 土谷）</a></h3>
<p>弊社エンジニアの土谷からは、「KARTE Message」をテーマに、月間10億通を超える大規模配信の信頼性をどのようにSLOに落とし込み、運用・改善してきたかについてお話ししました。</p>
<p>セッション後、弊社ブースにお立ち寄りいただいた方の中には、これからSLI/SLOを設定するという方も多くいらっしゃいました。技術的な側面に加え、「ビジネスメンバーへの理解をどのように促進したか」といった具体的な実践方法まで踏み込んで質問される方も多く、皆様との対話を通じて、私たち自身も多くの学びを得ることができました。</p>
<p>よろしければ登壇資料もご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化" src="https://speakerdeck.com/player/6e64b50718624605960a8f215fce51e7" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>おわりに</h2>
<p>SRE NEXT 2025には、SREやインフラ分野に深い知見をお持ちの方が数多く参加されており、弊社の取り組みに興味を持っていただき、活発な議論ができたことを大変嬉しく思います。私たちが知見を提供するだけでなく、皆様からも多くのことを学ばせていただき、非常に貴重な交流をすることができました！</p>
<p>今回、初めてカンファレンスのブース担当を経験しましたが、多様なバックグラウンドを持つ方々と直接技術的なお話しができ、とても楽しかったです。普段チームの中で開発している時には中々得られない刺激と知見を得ることができました。今後もこのような場に参加させていただきたいと思います！</p>
<p>最後に、このような素晴らしいカンファレンスを主催・運営してくださった皆様、本当にありがとうございました！ブース出展では、スタンプラリーなど来場者と話すきっかけを運営の皆様にご用意いただけたおかげで、非常に多くの方々とお話できました。そして、盛り上げていただいた参加者のみなさま、様々な知見をご共有いただいたスピーカー、スポンサー企業の皆様、ありがとうございました！</p>
<p>SRE NEXT 2026も楽しみにしております！</p>


新卒のエンジニアがSRE NEXTに参加しました。プレイドのブースの紹介や聴講したセッションレポートをお伝えします。

新卒エンジニアによるSRE NEXT 2025 イベントレポート　

<p>この記事は、社内の生成AI LT会（<a href="https://tech.plaid.co.jp/plaid-generative-ai-lt-report">LT会に関するブログ</a>）で「誰でもできるvibe-coding」と題した発表内容を基に、AIに執筆させています。</p>
<h2>はじめに</h2>
<p>こんにちは、プレイドのKARTE Messageチームでエンジニアをしている大内です。</p>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。</p>
<p><a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信の運用について紹介した記事</a>や、<a href="https://tech.plaid.co.jp/complex_logic_to_dynamically_generate_sql">機能改善により開発スピードが向上したことを紹介した記事</a>がありますので、そちらも併せてご覧ください。</p>
<p>私たちMessageチームでは、開発の生産性をさらに高めるために、エンジニア以外のメンバーもAIを活用して開発を行う取り組みを進めています。この試みは多くの可能性を秘めている一方で、「レビュワーの負担が増えすぎる」という課題も明らかになりました。</p>
<p>この記事では、その課題にどのように取り組み、改善を進めているかご紹介します。</p>
<h2><strong>AI開発の幕開けと、見えてきた課題</strong></h2>
<p>チームのプロダクトマネージャー（以下、PMとします）が生成AIを使い、次々と実装を始めたのがことの始まりでした。AIによってコードが効率的に生み出され、ローカル環境で動作確認ができれば、機能が形になるという事実は、開発のスピード感に大きなインパクトを与えました。</p>
<p>その結果、PMは多くのPRを作成。この1ヶ月だけでも、<strong>レポート機能の改善、AI連携機能の強化、リスト表示のUI刷新、多岐にわたる機能改善</strong>に関するPRがマージされました。</p>
<p>一方で、この新しい開発スタイルは、いくつかの運用上の課題も浮き彫りにしました。</p>
<ul>
<li><strong>エンジニアのレビュー負荷増大</strong>：エンジニアから見ると、「開発の意図や目的が必ずしも明確でない大量のコード」をレビューする必要が生じた。</li>
<li><strong>AI生成コードの品質</strong>：AIは既存のコードベースを完全に理解しているわけではないため、「動作はするものの、品質面では改善の余地がある」コードを生成してしまうことがあった。例えば、既存コードの再利用が不十分であったり、実装方針の変更時に古いコードが残ってしまったりするケースがある。</li>
</ul>
<p>レビュワーからは、特に以下の点が負担増の原因として挙げられました。</p>
<ul>
<li>PRにおける差分量の増加があった。</li>
<li>「まず実装してみる」という進め方だったため、設計やセキュリティリスクに関する検討がコードレビュー段階に集中し、レビューの負担が増した。</li>
<li>AIが生成したコードの意図を読み解くのに時間がかかることがあった。</li>
</ul>
<h2><strong>課題解決への道のり：プロセスの見直しと改善</strong></h2>
<p>これらの課題に対応するため、私たちは以下の改善策に取り組んでいます。</p>
<ol>
<li><strong>「仕様ドキュメント」の事前作成とレビュー</strong>：開発着手前に「仕様ドキュメント」を作成し、エンジニアがレビューするフローを導入。これにより、設計段階で問題点を洗い出し、セキュリティ懸念を事前に検討できるため、コードレビュー時には実装そのものに集中できるようになった。</li>
<li><strong>AIによる実装意図のコメント記載</strong>：AIが生成したコードには、可能な限り実装意図をコメントとして記述。これにより、レビュワーがコードの意図を理解しやすくなることが狙い。</li>
<li><strong>PRの適切な分割</strong>：AIによる大量のコード生成に対応するため、PRを機能単位や意味のある変更単位で細かく分割するルールを設けた。仕様ドキュメントで事前に粒度を決めておくことで、レビューの負荷軽減を図っている。</li>
</ol>
<h2><strong>レビュワーから見たAI開発：評価と今後の期待</strong></h2>
<p>AIが生成したコードをレビューする中で、その可能性と課題の両方が見えてきました。</p>
<p><strong>評価できる点</strong></p>
<ul>
<li>既存の複雑な実装がある中でも、動作するコードを生成できる点は注目に値する。特にテストコードの生成精度は高く、品質向上に貢献する可能性がある。</li>
<li>既存の制約がない新規開発の場合、AIが生成するコードは比較的標準的で読みやすい傾向にある。</li>
<li>コードを記述する速度は非常に速く、人間によるレビューがボトルネックになる場合もあるほどである。</li>
</ul>
<p><strong>今後の改善に期待する点</strong></p>
<ul>
<li>既存実装が複雑な場合や、多くの背景情報を理解する必要がある場合、生成されるコードの質がまだ高くないことがある。これは事前の設計ドキュメント作成である程度カバーできると考える。</li>
<li>PRの粒度調整や補足コメントの追加など、実装以外の部分では、まだ人間によるコントロールが必要である。</li>
<li>既存のコードアーキテクチャが一般的でない場合、AIの知識外となり精度が低下する可能性がある。AIを有効活用するには、既存コードも一般的なアーキテクチャに準拠している方が望ましいかもしれない。</li>
</ul>
<p>総じて、AIに開発を完全に任せるのはまだ難しい点が多いものの、工夫次第で品質を向上させることは十分に可能だと感じています。チームとしてこの新しい取り組みに前向きに関わり、改善を続けていくことが重要だと考えています。</p>
<h2><strong>現在の取り組みと、そこから得られた学び</strong></h2>
<p>現在、私たちは以下の対策を中心に進めています。</p>
<p>それは、<strong>「仕様ドキュメント」を事前に作成し、エンジニアのレビューを経たうえで開発に進むフローを確立すること</strong>です。</p>
<p><strong>具体的なフローのイメージ</strong></p>
<ol>
<li>PMが仕様ドキュメントに「背景」「期待する機能」「懸念点」を記述し、「実装方針」についてはAIの支援も受けつつ草案を作成。
<ul>
<li>この時点で、PM自身も実装の概要を把握。</li>
</ul>
</li>
<li>エンジニアが「仕様ドキュメント」をレビュー。
<ul>
<li>これにより、コードレビュー時に仕様の全体像が共有され、手戻りを削減。既存コードの活用など、エンジニアの知見を早期に反映する。</li>
</ul>
</li>
<li>レビュー結果を元に「仕様ドキュメント」を修正し、関係者間で合意。</li>
<li>修正された「仕様ドキュメント」を設計書としてAIに入力し実装。
<ul>
<li>より正確な仕様に基づいてAIがコードを書くことで、誤りを減らす。</li>
</ul>
</li>
</ol>
<p><strong>AI運用の工夫</strong></p>
<ul>
<li>作成した仕様ドキュメントをCursorやCopilotに一時的にルールとして登録し、開発中の参照を容易にしている。</li>
<li>PR作成前に必須のチェックリストを作成し、レビューの負担軽減に努めている。</li>
</ul>
<p>これらの取り組みにより、エンジニアからは「レビューの負担が軽減された」という声も聞かれるようになってきました。（もちろん、まだ改善の余地はあります。）</p>
<p><strong>得られた学び</strong></p>
<p>この経験から、ビジネスサイドとエンジニアが共同で仕様を定義し、開発を進めていくプロセスが、AIの登場によって大きく変わる可能性を感じています。</p>
<p>現在のAIの進化を見ると、いずれ「仕様書＝実装」という未来も現実のものとなるかもしれません。私たちMessageチームは、今後もこの新しい開発スタイルに積極的に取り組み、知見を深めていきたいと考えています。</p>


生成AIで書いたコードをどうレビューしていくか。AIと共存しながら開発しているMessageチームの取り組みを紹介します。

「生成AIで書いたコード、どうレビューする？」Vibe codingと共存する開発プロセス

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/81e6ad0d-7393-4edb-9ddf-8d6a74776c40/b169e8b6-b251-40e6-82a2-dfea82be77ff.png" alt=""></p>
<p>こんにちは！<br>
プレイドでインフラエンジニアをしている@ikemonnです。</p>
<p>本日は10/27(木)に開催しました「【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜」のレポートをお届けしたいと思います。</p>
<h2>発表タイトル</h2>
<ul>
<li>ペパボを支える大統一CI基盤と人々</li>
<li>KARTEを支えるCI環境</li>
<li>自動マルチブラウザテストを導入・運用した話</li>
<li>グーペのE2Eテスト運用事情</li>
<li>並行処理のテストは難しい</li>
</ul>
<h2>ペパボを支える大統一CI基盤と人々</h2>
<p>まずペパボ @ravelllさんから「ペパボを支える大統一CI基盤と人々」についてお話頂きました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0c5f4b9d8bc74e09ae75265cc73e9a8b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>ペパボさんのCI環境の変遷や現在の姿、現場の声、課題などについて発表して頂きました。<br>
各チームがそれぞれ <code>いいかんじに</code> CI環境を立てていた時代からdrone.ioを用いた社内統一CIができるまでのお話です。</p>
<p>CI環境を社内で統一することによって、「CI環境自体のトラブルが減ったり」「困ったときに誰にでも質問できて楽」といったメリットがあったそうです。<br>
とは言え、Dockerfileをメンテする人が有識者に限られたり、drone.io/Docker側の問題があったりと課題もあるので改善しつつ運用されているようです。</p>
<p>弊社も現在絶賛Dockerize中ですので、大変勉強になりました。</p>
<h2>KARTEを支えるCI環境</h2>
<p>次にプレイド @positiveflatから「KARTEを支えるCI環境」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="61d9c5aa1a3340e2b3a8510fd90ef810" data-ratio="1.29456384323641" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>プレイドでは、Web接客サービスKARTEのサービス開発当初から、CIの仕組みを強化し続けています。今回は、弊社のCIの全体像と、CI環境強化の途中で発生したいくつかの問題とその解決策について簡単に紹介しました。会場にいた方は、CIに取り組みたいけどまだ取り組んでいないという方が多かったので、今回の内容がCI導入のきっかけになれば幸いです。詳しくは<a href="/2016_08_24_uitest_automation/">こちらのブログの記事</a>でも説明していますので、是非ご覧ください。</p>
<h2>自動マルチブラウザテストを導入・運用した話</h2>
<p>次にプレイド @sdaikichiから「自動マルチブラウザテストを導入・運用した話」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="537b41d4a4434a58b6c69ebb1b701d07" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p><a href="/multi-browesr-test/">40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する</a> を元に、PLAIDでマルチブラウザ（クロスブラウザ）テストを導入・運用をした経験から、設定方法やハマりどころを紹介しました。<br>
（sdaikichiが挙手制アンケートをとったところ）会場にはほぼマルチブラウザテストを行っている人はおらず、CIのマルチブラウザテストはかなりハードルが高いことが伺えました。<br>
twitterでは「(BrowserStackに関して)テストを全て動画にしてくれるのはありがたい」などの感想がつぶやかれていました。</p>
<p>ポケモンやりすぎ！</p>
<h2>グーペのE2Eテスト運用事情</h2>
<p>続いてペパボ @hypermktさんから「グーペのE2Eテスト運用事情」の発表がありました。</p>
<div style="width: 100%">
 <script async class="speakerdeck-embed" data-id="d8b089ddbf864a848a0a88035eb4d176" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>自己紹介をPHPUnit(テストはちゃんとパスする)で書かれていて、掴みからバッチリでした！<br>
テストが全くなかったサービスにテストを導入されたお話で、チームメンバーにテストコードの必要性から実装方法までを説明し、今ではUTもE2Eテストも都度追加しておられるそうです。<br>
まずは正常閲覧テストから始めてみると簡単に実装できて良いとのことでした！</p>
<h2>並行処理のテストは難しい</h2>
<p>最後にペパボ @nakano_akihitoさんから「並行処理のテストは難しい」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0da601e2e2f1483b9cb21791d7bb0e0c" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>並列・並行処理が注目されている中、どのように並列・並行処理のテストをすればよいかを具体的にコードを見つつ説明して頂きました。<br>
<code>sleep 1</code> のように不安定な処理をいれるのではなく、<code>Humble Object pattern</code>で処理を切り出したり、<code>メッセージパッシング</code> を使うことでテストを上手く書くことが出来ます。</p>
<p>ご自身でもPHPの並列処理をするライブラリ<a href="https://github.com/ackintosh/snidel">ackintosh/snidel</a>を書かれておられるので、ご興味のある方はご覧ください！</p>
<h2>最後に</h2>
<p>今後も引き続き勉強会を開催したいと思っておりますので、一緒に勉強会を開いてくださる方を募集中です。</p>
<p>また、ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


drone.io, CircleCI Enterprise, BrowserStack等を使用したテスト環境について、ペパボとプレイドで勉強会を開催しました！

【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜を開催しました！

<p>こんにちは。プレイドの藤川(@atsushiss15)です。<br><br>
プレイドには学生時代よりインターンとして参加しており、今年の４月に新卒社員として正式に入社しました。現在に至るまで弊社の提供するKARTEの機能開発を担当しています。</p>
<p>今回はVue.jsを利用したコンポーネント指向のUI開発において、私たちが実際に遭遇した問題とその解決策として導入したStoreパターンについてご紹介したいと思います。<br>
Vue.jsというフレームワークが題材にはなりますが、Storeパターンの考え方自体は他のフレームワークを使った開発にも転用できると思うので、ぜひ読んでみていただければと思います。</p>
<h1>目次</h1>
<ul>
<li>Vue.jsとは？</li>
<li>アプリケーションの大規模化に伴って生じた問題</li>
<li>解決策としてのStoreパターン</li>
<li>サンプルコード他</li>
<li>Storeパターンに移行した感想</li>
<li>最後に</li>
</ul>
<h1>Vue.jsとは？</h1>
<p><a href="http://jp.vuejs.org/">Vue.js</a>を一言で表現するならば、「シンプルさが売りのMVVMフレームワーク」です。<br>
他の有名なMVVMフレームワークにはAngularJSやReactなどが挙げられますが、それらに比べてVue.jsはそのシンプルさ故に学習コストが低い上、あらゆる規模のアプリケーションで利用することができる設計になっています。</p>
<p>Vue.jsを知らない方でも、簡単なToDoアプリの実装例を見てみれば大体の使い方が理解できるのではないでしょうか。</p>

<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<script async src="//jsfiddle.net/atsushiss15/kj29sbh1/embed/js,html,result/"></script>
<p>上記のコードは、Vue.jsの公式サイトに掲載されているサンプルのコードを便宜上CoffeeScriptで書き直したものです。</p>
<p>簡単に解説をしてみます。<br>
id属性を用いてVueインスタンスと仮想DOMの紐付けを行い、<code>v-model</code>でデータの双方向バインディング、<code>{{ }}</code>構文でテキストのレンダリング、<code>v-for</code>でリストのレンダリング、<code>v-on</code>で要素にイベントリスナのアタッチをそれぞれ行っています。</p>
<p>Vue.jsはこの辺りさえ抑えておけば、とりあえずコードを書き始めることができるので便利です。</p>
<h1>アプリケーションの大規模化に伴って生じた問題</h1>
<p>Vue.jsの最も大きな特徴の一つにコンポーネントシステムがあります。<br>
この仕組みを利用して、アプリケーションのUIをコンポーネントレベルに分割し、組み合わせるように実装することで、コードの再利用性が向上し、ロジックも各コンポーネントの中にカプセル化することができます。</p>
<p>コンポーネントの状態は各コンポーネントがそれぞれ管理し、状態やイベントの共有は<a href="http://jp.vuejs.org/api/#props">props</a>や<a href="http://jp.vuejs.org/api/#vm-dispatch">$broadcast</a>/<a href="http://jp.vuejs.org/api/#vm-broadcast">$dispatch</a>といった仕組みを利用して行います。<br>
下図はコンポーネント間でのデータやイベントの伝達をイメージしています。propsを用いてデータを子コンポーネントへ明示的に受け渡したり、$broadcastや$dispatchを使って他コンポーネントへイベントの通知を送ることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ad51dcdd-703b-4f66-8255-89a89c6bdbcb/----------2016-10-12-19.27.58.png" alt=""></p>
<p>しかし、これらの仕組みを利用すると、アプリケーションの大規模化に伴い状態管理が複雑になってきてしまいます。<br>
状態が多くのコンポーネントに分散し、更にそれらが相互作用するようになるとpropsや$broadcastを使ったコンポーネント間でのデータやイベント伝達の仕組みが多用され、コンポーネント同士が密結合・複雑化し始めるのです。<br><br>
実際にKARTEの開発においても、これらが原因でコード変更の影響範囲が分かりづらく改修が困難になり、コードの重複やサーバーサイドとの無駄な通信などが散見されるようになっていました。</p>
<h1>解決策としてのStoreパターン</h1>
<p>そこで私たちはStoreパターンによって<strong>アプリケーションの状態（State）・処理（Actions）・イベントの共有</strong>を行うことで、密結合しているコンポーネントの分離、コードの重複や無駄な通信の削減を目指しました。</p>
<h2>私たちがStoreパターンと呼んでいるもの</h2>
<p>Storeパターンは、Storeというグローバルな共有オブジェクトに複数のコンポーネントから使用される共通の状態・処理・イベントを管理させることで、コンポーネント同士を分離する考え方です。</p>
<p>下図のように、ユーザーから何らかの入力を受けたコンポーネントはStoreの共有処理（Shared Actions）を直接Callすることで共有状態（Shared State）を更新します。各コンポーネントはこの共有状態を監視することでそれぞれの表示を変化させます。<br>
また、Storeには共有のイベントも管理させます。何らかのイベントをトリガにしてコンポーネントごとの処理を行いたいケースなどは、これを利用して各コンポーネントに通知を送信します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6593975e-2483-4c37-a10a-0c568d0ed4bd/----------2016-10-13-3.02.32.png" alt=""></p>
<h2>「Fluxとは何が違うの？」</h2>
<p>というご指摘が挙がってきそうなので、<a href="https://facebook.github.io/flux/">Fluxアーキテクチャ</a>との差分についても少し触れておきたいと思います。</p>
<p><a href="http://v1.vuejs.org/guide/application.html#State-Management">Vue.js公式ドキュメント</a>でも言及されていますが、store patternは共有の状態・処理をグローバルなオブジェクトに管理させることでコンポーネント同士が密結合・複雑化してしまうのを防止することを目的としています。</p>
<p>そういった意味で、Fluxはstore patternの考え方をベースに、Event Dispatcherによる一方向（one-way）の状態更新フロー以外は許容しないという制約を加えたアーキテクチャであることが分かります。<br>
対して、私たちがStoreパターンと呼んでいるものは、Fluxの思想自体は汲み取りつつ柔軟性とシンプルさを担保したものであるといえます。</p>
<p>具体的には、状態更新に関する制約を設けないことで柔軟性を確保し、Event Dispatcher等は介さず直接関数をCallして状態更新を行うことでシンプルさを保つようにしています。そのためTPOに応じてコンポーネントが直接Storeの状態を書き換えることも許容します。</p>
<p>このように私たちがFluxのように、制約によってキレイに整理された（しかし少し大げさな）アーキテクチャよりも、柔軟性やシンプルさといったものを求めたのは**「ルールをできるだけ作らずに属人的に判断する」**という企業文化を大切にしているからです。<br>
また別の観点からみれば、KARTEの管理画面がサブアプリごとにページを分けるような構造になっており、そもそもフロントエンドが大規模化しすぎないように設計されているということも、このような方針を採る際の後押しとなりました。</p>
<h1>サンプルコード他</h1>
<p>何はともあれコードで説明するのが一番です。<br>
せっかくなので、冒頭でご紹介したToDoアプリのコードをStoreパターン的に実装してみます。</p>
<script async src="//jsfiddle.net/atsushiss15/fgone3us/1/embed/js,html,result/"></script>
<p>この例ではStoreによって状態（state）と処理（addToDo, removeTodo）の共有を行っています。<br>
一見コードが増えたようにも見えますが、複数コンポーネントで状態や処理の共有が行われるようになるとStoreパターンによる恩恵を享受できるはずです。</p>
<h2>イベントの通知について</h2>
<p>イベントの通知については幾つかの手段が考えられますが、次の２つをケースにより使い分けるのが良いのではないでしょうか。</p>
<h3 style="color:#494a50;">1. StoreのEventEmitterを利用してEventの通知を行う</h3>
<pre><code># Store側
{EventEmitter} = require 'events'
class XxxYyyStore extends EventEmitter
# 省略...
</code></pre>
<pre><code># コンポーネント側
# ...省略
methods: -&gt;
    hogeAction: -&gt;
      # 別vueや別componentに変更等を通知
      xxxYyyStore.emit 'conditionChanged', {}

  compiled: -&gt;
    # 別vueや別componentからStore経由でイベントハンドリング
    xxxYyyStore.on 'conditionChanged', () -&gt;
      # handling
</code></pre>
<h3 style="color:#494a50;">2. watchやcomputedを利用して間接的にイベントハンドリングを行う</h3>
```
# Store側
# ...省略
watch:
  'xxxYyyStoreState.todos': ->
     # 共有状態に変更があった場合の処理
computed:
    isEmpty: ->
      @xxxYyyStoreState.todos.length is 0 
```
複雑な変更と明示的なタイミングの制御が必要なものは **1.** の方法で個別にハンドリングし、そうでない場合は **2.** の方法でハンドリングするといった要領で使い分けてみると良さそうです。
<h2>その他に留意すべき点</h2>
<p>また、Vue.jsでStoreパターンを構築する際には以下の点にも留意するようにしてください。</p>
<h3 style="color:#494a50;">1. XxxYyyStore.stateに余分なものを入れない</h3>
XxxYyy.stateは、Storeの外に公開されるオブジェクトです。Vueのデータ更新監視の対象になるので、あまり大きなものを入れないほうが良いです。
<h3 style="color:#494a50;">2. XxxYyyStore.stateを置き換えない</h3>
一つのStoreインスタンスを複数箇所で使い回す形になります。
constructorで作ったstateを、複数のVueコンポーネントで監視するようになるので、state自体を置き換えるコードがあると、値の追跡が正常に行われなくなります。
```
# まずい例
constructor: ->
  @state=
    value: ''
updateXxx: (newState) ->
  @state = newState # <- @stateを置き換えているので、更新が拾えなくなる
```
<h3 style="color:#494a50;">3. 基本的に$broadcast, $dispatch, $parent, $childは使用しない</h3>
これらの仕組みはほとんどStoreパターンで補うことができるので、コンポーネントの密結合・複雑化を防ぐためにも使うべきではありません。props（データを子コンポーネントに明示的に伝達する仕組み）に関しても使用を必要最小限に抑えてください。
<br>
さて、簡単なサンプルコードを使って説明してきましたが、なんとなく感覚は掴んでいただけたかと思います。実際にはもう少し考えなければならない事があるのですが、基本的には上記のシンプルなパターンを拡張していくイメージになります。
<h1>Storeパターンに移行した感想</h1>
<h2>良かった点</h2>
<ul>
<li>サーバーとの通信処理や複雑なロジックがStore側に集約されたことで、コンポーネント側はVueが本来担うべき表示系の処理に集中できるようになった。</li>
<li>コンポーネント間の密結合が解消され、コンポーネントの再利用性が高まった。</li>
<li>全体的に見通しが良くなるのでロジックの改修等が楽に行えるようになった。</li>
</ul>
<h2>考えるべき点</h2>
<ul>
<li>重い初期化処理に対しては適宜遅延させるなどの工夫が必要になる</li>
<li>Storeでの処理後にコンポーネント側で後処理を行う際は、コールバックで行うのか、状態の変更を監視して行うのか、イベントをハンドリングして行うのか、などを適宜使い分ける必要がある</li>
<li>状態の更新フローに関する制約をどこまで設けるかは再考する必要がある</li>
</ul>
<p>所感としては、Storeパターンへの移行の目的としていた点はおおよそ満たせたのではないかと感じています。もちろんまだまだ試行錯誤が必要な点はあると思うので、より良いアーキテクチャを目指して日々改善していきたいと考えています。</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>

Vue.jsを用いたコンポーネント指向のフロントエンド開発において弊社が導入したStoreパターンについてご紹介します。

コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する

<p>みなさん、ごきげんよう。プレイドの@akobaです。<br>
プレイドではCXチームのエンジニアとして、プロダクトの機能開発、ならびに弊社のウェブ接客プラットフォームKARTEで提供するアプリケーションの開発を行っています。<br>
今回は、KARTEでできることを広げる試みの一環として、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。<br>
具体的には、ユーザーの閲覧履歴、レビュー／コメント機能、今この記事をxx人が見ていますといった機能を作ってみました。<br>
通常ネイティブアプリ向けとして使われることが多いFirebaseですが、Webブラウザ上でも色々と面白いことができます。<br>
この記事が皆さんの開発の参考になれば幸いです。</p>
<h2>目次</h2>
<ul>
<li>Firebaseとは</li>
<li>Firebaseにデータを貯めていく</li>
<li>ページ内でユーザーの情報を共有する</li>
<li>リアルタイム機能を使う</li>
<li>KARTEを使ってアプリを配信</li>
<li>まとめ</li>
</ul>
<h2>Firebaseとは</h2>
<p><a href="https://firebase.google.com/">Firebase</a>とは、最近大きく注目を集めているMBaaS(Mobile Backend as a Service)、つまりモバイル開発のためのクラウド・ベースのバックエンドサービスです。2014年にGoogleに買収され、Google I/O 2016で新バージョンが発表されました。<br>
ここでのバックエンドとはDB、認証、ストレージ、解析、メッセージングプラットフォームなど（詳細は公式サイト参照）で、主にネイティブアプリ向けのプラットフォームとして提供されています。<br>
ただし、Web用のSDKも準備されており、今回はこのSDKをWebサイト上で使ってみたいと思います。</p>
<p>SDKといっても、Webページに下記のようなタグを貼るだけです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5c996e6-805a-4054-8eaa-d1d6bbab1717/-2016-09-29-7.23.18.png" alt="web-setup-code"><br>
（xxxの箇所はFirebaseのプロジェクトによって異なります。詳細は<a href="https://firebase.google.com/docs/web/setup">こちら</a>）</p>
<p>Firebaseには様々な機能が用意されていますが、今回は<a href="https://firebase.google.com/docs/database/">Realtime Database機能</a>にフォーカスして使ってみます。<br>
この機能、BaaSなので当然なのですが、自分でサーバーを立てる必要がなく、上記のタグを貼るだけでブラウザからアクセス可能なKVSとして利用できます。<br>
DBとしての特徴は主に下記となります。</p>
<ol>
<li>DB全体が1つのJSON treeとして扱える</li>
<li>データの更新時、データを使っている各クライアントにリアルタイムで同期される</li>
<li>オフライン時もクライアント側でデータを保持し、オンラインになった時点でオンラインデータとマージされる</li>
</ol>
<p>1のために、個別のデータを更新するにはそのパスを指定して更新、全体を更新するにはルートパスに大きなJSONを1つ送るだけで済みます。（ただし大きすぎるJSONについてはそのまま送信はできないので、細かく分割して送信する<a href="https://github.com/firebase/firebase-import">ツール</a>が公開されています。）また読み込みの際も、全体のデータが欲しいのか、一部のデータが欲しいのかを、参照するJSONのパスを指定することで細かく指定することができます。<br>
2は色々と面白いことができそうですね。<br>
3もかなり便利そうですが、今回は使いません。</p>
<h2>Firebaseにデータを貯めていく</h2>
<p>では、実際にFirebaseのDBを使ってみましょう。</p>
<p>FirebaseのDBはKVS(Key Value Store)なので、なんらかのキーを軸にデータを集めていくことになります。<br>
キーとして もっともよく使われるのはユーザーID（ユーザー軸）でしょう。それ以外にWebページのURLやWebページ上のアイテム・コンテンツID、もしくは地域やユーザー属性のようなものをキーにしても面白いかもしれません。<br>
今回は、ユーザー軸とWebページ軸の情報をFirebaseに集めることにします。</p>
<p>まず最初にWebページ軸の情報。</p>
<pre><code>var pagePath = 'page/' + encodeURIComponent(location.pathname).replace(/\./g, '%2E');
firebase.database().ref(pagePath)
  .set({
    image: image,
    title: title
  });
</code></pre>
<p>ページのURLパスをキーとして、ページ毎に、そのページのタイトルと画像URLを保存してみます。<a href="http://ogp.me/">Open Graph</a>の値などを入れておくといいですね。<br>
<code>page/</code>の部分はなんでもいいですが、RDBのテーブル名のように、データの種類を区別するためにつけておきます。また、Firebaseのキー名には<code>., $, #, [, ], /</code>は使えないのでパーセントエンコードしておきます。（が、以下では簡略化のためにエンコードのコードは記載しません）</p>
<p>次にユーザー軸の情報。単純に、閲覧したページのURLを保存しておきましょう。</p>
<pre><code>var userPath = 'user/' + userId;
firebase.database().ref(userPath + '/visit/' + location.pathname)
  .set({
    timestamp: parseInt(new Date() / 1000)
  });
</code></pre>
<p>ごちゃっとしていますが、<code>user/[ユーザーID]/visit/[URLパス]</code>に<code>timestamp</code>という値を書き込んでいます。<br>
<code>userId</code>の箇所は、なんらかの形で保持しているユーザー毎のIDを使用します。</p>
<p>ユーザーがページを見るたびにその情報をFirebaseに書き込んでいくと、FirebaseのDBには下記のようにデータが溜まっていきます。</p>
<pre><code>{
  &quot;page&quot; : {
    &quot;%2Fproducts%2Fdetail%2F12&quot; : {
      &quot;image&quot; : &quot;http://xxx.jpg&quot;,
      &quot;title&quot; : &quot;xxx&quot;
    },
    ...
  },
  &quot;user&quot; : {
    &quot;akoba&quot; : {
      &quot;visit&quot; : {
        &quot;%2Fproducts%2Fdetail%2F12&quot; : {
          &quot;timestamp&quot; : 1474968518
        }
      }
    },
    ...
  }
}
</code></pre>
<p>こうやって、ユーザー毎にそのユーザーが見たページのURL（パス）、ページ毎にそのページのタイトルと画像を保存しておくと、最近見たページのリスト（いわゆる閲覧履歴）が表示できます。</p>
<p>まず最初に、自分のユーザー情報を取得します。</p>
<pre><code>firebase.database().ref(userPath)
  .once('value')
  .then(function(snapshot) {
    var myUserData = snapshot.val();
    ...
  });
</code></pre>
<p><code>once</code>とは、このタイミングでデータを一度だけ取得するということです。更新の監視は行いません。</p>
<p>myUserDataには上記のJSONの一部、下記のようなデータが入っています。</p>
<pre><code>&quot;visit&quot; : {
  &quot;%2Fproducts%2Fdetail%2F12&quot; : {
    &quot;timestamp&quot; : 1474968518
  }
}
</code></pre>
<p>このvisit以下の各キーについて、ページの情報を取得すると、過去閲覧したページの画像とタイトルを表示できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/91964ea1-84de-4013-8086-3e5df2208773/-2016-09-28-19.07.08.png" alt="recent_items"></p>
<p>1点注意ですが、当然閲覧履歴はどんどん溜まっていきます。残念ながら、現状FirebaseのDBにはexpireの機能がないようなので、ある程度の数を超えたらtimastampの古いものから消していく等の対応が必要です。</p>
<h2>ページ内でユーザーの情報を共有する</h2>
<p>先ほどの例は、ユーザーを軸に、ページの情報を取得しましたが、その逆も可能です。<br>
たとえば、</p>
<pre><code>firebase.database().ref(pagePath + '/review/' + userId)
  .set({
    nickname: nickname,
    comment: comment,
    starCount: starCount,
    timestamp: parseInt(new Date() /1000)
  });
</code></pre>
<p>のような値を書き込むことで、ページにユーザーレビューを投稿する機能も実装できます。<br>
ユーザーレビューまで行かなくても、書き込みを例えばサイトのスタッフのみに制限しておけば、各ページ、そのページに表示されている商品や記事への、スタッフのコメント機能が実現できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2a0b8dd-d4d3-4a52-8478-60aa1ef0f73f/-2016-09-27-23.09.33.png" alt="staff_comment"></p>
<p>スタッフは、実際に自分のサイトにアクセスして、該当のページでコメントを入力するだけです。<br>
こういった機能はいかにもウェブ接客という感じですね。</p>
<h2>リアルタイム機能を使う</h2>
<p>Firebaseの特長でもある、リアルタイムのデータ同期機能を使ってみましょう。<br>
今度もページ軸で、</p>
<pre><code>firebase.database().ref(pagePath + '/visit/' + userId)
  .set({
    timestamp: parseInt(new Date() /1000)
  });
</code></pre>
<p>そのページを見ているユーザーをどんどんページ情報に追加していきます。<br>
ページ側では、そのページの情報を下記のように取得します。</p>
<pre><code>firebase.database().ref(pagePath + '/visit')
  .on('value', function(snapshot) {
    updateUserCount(snapshot.numChildren());
  });
</code></pre>
<p>先ほどの<code>once</code>と違い、<code>on</code>では対象の値が更新されるたびに都度、指定した関数が実行されます。<code>numChildren</code>でデータ内の子要素の数を取得し、<code>updateUserCount</code>で表示するユーザー数の値を更新します。<br>
こうしておくと、表示されているユーザー数が、新しくユーザーが来訪するたびに増えるようになります。</p>
<p>ということで、今このページに出ている↓は、実際にFirebaseで作っています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7e1e941a-c86e-4a93-8cd1-8c06e596093f/-2016-09-28-18.57.14.png" alt=""></p>
<p>なんか出てたけど消しちゃったよという方は、このページをリロードいただくともう一度出るかと思います。</p>
<p>こちらについても、timestampをチェックして一定時間以上前のユーザーは削除していく等の対応が必要です。このページに設置してあるものについては、ページの閲覧から10分以上経過したユーザーを削除しています。</p>
<h2>KARTEを使ってアプリを配信</h2>
<p>最後に、こうやって作ったアプリケーションを、弊社のウェブ接客プラットフォームKARTEで実際に配信してみます。<br>
上記のサンプルでは、ユーザー軸、ページ軸ともFirebaseのDBを使ったのですが、KARTE自体がユーザー軸の解析を行っているので、ユーザー軸のデータの管理はKARTEに任せることができます。<br>
したがって、KARTEを使って上記のアプリを配信する際は、下記のような役割分担となります。</p>
<ul>
<li>KARTE：いつ・誰に・どうやって配信するかを制御。ユーザー情報を管理</li>
<li>Firebase：ページ毎の情報を管理</li>
</ul>
<p>KARTEでは、通常あらかじめ用意されたテンプレートを利用し、色やテキスト、画像等を差し替えるだけでコンテンツが配信可能です。しかし、もちろんフルカスタマイズすることも可能で、HTML、CSSに加えてJavaScriptの実行も可能な自由度の高いプラットフォームとして作られています。<br>
したがって、今回のような外部のサービスを利用することも、そのためにそのサービスのタグを呼び出すことも可能です。また、今回の記事では触れていませんが、いわゆるウィジェットを作る用のAPIも用意されています。</p>
<p>実際に作成しているエディタの画面です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1462c55a-bbfe-4b20-b725-232def824886/-2016-09-27-16.44.49.png" alt=""><br>
HTML、CSS、JavaScriptが自由に編集できるので、ここにFirebaseを使用するコードを書きます。</p>
<p>先ほどご紹介した、このページで表示しているユーザー数のカウンターも、KARTEを使って配信しています。</p>
<h2>まとめ</h2>
<p>最後は少し駆け足になってしまいましたが、Firebaseを使って簡単にWebサイト上で動作するリアルタイムアプリケーションが作れる様子、またそれをKARTEを使ってWebサイト上に自由に配信できる様子が伝わりましたでしょうか。<br>
実際、Firebaseでアプリケーションを開発する際には、事前に用意する必要があるものもほとんどなく、思い立ったタイミングでサクッと簡単に機能を実装できてしまいます。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" id="wantedly-visit-buttons-wjs" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


今回は、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた | PLAID engineer blog

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた

<p>こんにちは。プレイドインターンの岡田です。</p>
<p>2月初めごろからエンジニアのインターンをさせていただいています。<br>
未経験で飛び込んだエンジニアでしたが、優しく面白い社員さん達に技術を教わりながらbugfixや機能追加などのお仕事をさせていただいてます。</p>
<p>さて、今回はプレイドの講演があったので、9月13日(火)に慶應義塾大学 日吉キャンパスで開幕した<a href="http://db-event.jpn.org/webdbf2016/index.html">WebDB Forum 2016</a>に参加してきました。その様子をご紹介します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ac15a42d-a576-45ce-a1ae-f45aeae42bc1/kanban-1.jpg" alt=""></p>
<h2>WebDB Forumとは</h2>
<p>WebDB Forumは情報処理学会データベースシステム研究会、日本データベース学会、電子情報通信学会データ工学研究専門委員会が主催で、WebとDB技術に興味のある研究者、大学院生、学部生、企業やオープンソースコミュニティの技術者が最新研究動向や成果について議論し、交流を行うイベントです。</p>
<p>参加者は例年300から400人で、半数以上はWebとDB技術において最先端の研究を行っている大学院生・学部生のようです。</p>
<p>プレイドはこのイベントのスポンサーをさせてもらっているので、受付後にもらえる紙袋やパンフレットの裏に社名が載っています！Googleや東芝と並んでいるのが嬉しいですね！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d862d412-986e-47a9-a635-aa28e0080d9e/IMG_8576.jpg" alt=""></p>
<h2>WebDB Forumの様子</h2>
<p>テーマはビッグデータ、IoT、機械学習、データ分析、データ構造など様々で、テーマごとにいくつかの会場に分かれて同時に複数のセッションが行われていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a152a6f-6d04-4002-9354-99b750da29eb/---2016-09-13-13-54-20.jpg" alt=""><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4899c171-7d8f-4c68-a894-113d7d18e1fc/---2016-09-13-12-35-04.jpg" alt=""></p>
<p>技術報告のほかに招待講演「ビッグデータと秘密計算」と「データ処理基盤」のセッションを聴講しましたが、どちらも質疑応答の時間にアツい議論が交わされていて圧倒されました。</p>
<p>休憩時間には大会議室前で飲み物と軽食が提供され、企業の方と学生が交流している様子や、聴講を終えた人たちがコーヒーを飲みながら意見を交わしている様子などが見受けられ、とてもいい雰囲気が漂っていました。</p>
<p>学生なら無料で参加できますし(学生証提示が必要です)、先生方の研究発表や企業の方の技術報告などが聞けて交流もできるなんて、とても素敵なイベントです。WebやDB技術に興味のある学生は次回、参加してみてはいかがでしょうか。</p>
<h2>プレイドの技術報告紹介</h2>
<p><a href="http://blog-plaid.com/event/2642/?draftsforfriends=7UMtQCI4RFrXGZAcwN4sUDkz8aMNHORC">「GCP NEXT World Tour in Tokyo」でプレイドのGCP活用事例を紹介</a>した@makinoyが「ビッグデータの高速・分散処理」というテーマでKARTEの解析エンジンについて技術報告をしました。(当ブログでも<a href="/streaming-algorithm/">大規模データを解析するストリーミングアルゴリズムをサクッと見てみる</a>の記事を書いています)</p>
<p>タイトルは <strong>「大規模分散リアルタイム解析エンジン Brook」</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0dec0269-574a-40b1-a62f-91662015435a/P9130345.jpg" alt=""></p>
<p>私たちが提供している「KARTE」は、Webサイトへの訪問者をリアルタイムに可視化し、会員登録や購買に繋げるためのウェブ接客を可能にするサービスです。</p>
<p>KARTEはリリースから1年半で累計ユーザー数<strong>5億UU</strong>を解析してきました。</p>
<p>今回は、そのKARTEを支える独自解析エンジン「Brook (ブルック)」の紹介をします。</p>
<p>Webサイト上で現実のようなコミュニケーションをするためには、 <strong>「いま」の来訪者がどういう人で、どういう行動をしているのか</strong>を知る必要があります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2e5045c6-5827-4b31-ae18-25f1a1090447/---2016-09-13-14-54-11.jpg" alt=""><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6f213078-db8c-483d-a6a5-89b43a3b4153/---2016-09-13-14-55-35.jpg" alt=""></p>
<p>それを実現するためには最新のユーザーの解析結果を計算し、結果に応じたアクションを決定するための時間を<strong>0.x秒</strong>にしなければなりません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/afdc84b2-5736-429c-a143-47f0bcaa48e8/P9130347-2.jpg" alt=""></p>
<p>通常、データの解析には大きく2つの方法があります。</p>
<ul>
<li><strong>数時間〜数十秒で大量</strong>のデータをMapReduceする<strong>バッチ処理</strong>
<ul>
<li>BigQuery、 Prest、Spark、Hadoop</li>
</ul>
</li>
<li><strong>1秒以内で直近の短期間少量</strong>のデータをMapReduceする<strong>ストリーミング処理</strong>
<ul>
<li>Spark Streaming、Storm</li>
</ul>
</li>
</ul>
<p>これらの技術では、<strong>Web上でリアルのようなおもてなしをするために1秒以内に大規模な蓄積データの解析結果を返すこと、またその結果を使ったアクションの実行を可能にしたいという想い</strong>を実現することができませんでした。</p>
<p>そこで、それを可能にするために開発したのが「Brook」です。</p>
<p>Brookでは<strong>あらかじめ解析軸を一つだけ定義しておく</strong>ことによって次のことを可能にしています。</p>
<ul>
<li>実時間(秒以内)で、イベントログ送信と同期的に結果整合性のある解析結果に基づいたアクションができる</li>
<li>解析軸は固定だが、スキーマレスな解析、次元数が多い大きめのデータを扱える</li>
<li>全てが分散化されているので大規模のデータを扱えスケーラブルである</li>
</ul>
<p>解析軸を複数設けずに1つに制限することで、<strong>0.x秒で全データの解析処理を行う</strong>ことができ、KARTEでのリアルタイム接客が可能になっているのです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d08565a2-5d40-4c83-ad48-017346c27445/P9130346-1.jpg" alt=""></p>
<p>20分の発表でしたが、他にもデータフロー、Hadoopと比較したBrookの特徴、スキーマレス統計処理、解析に用いているアルゴリズムなど、盛りだくさんの内容でした。<br>
学生さんをはじめ、聴講に来ていただいた方々ありがとうございました！</p>
<p>以上、WebDB Forumとプレイドの技術報告の様子をご紹介させていただきました。</p>
<p>KARTEやBrookのことを少しは伝えられたでしょうか。<br>
今回はあまり紹介できませんでしたが、KARTEやBrookの技術をもっと知りたい方は、ぜひプレイドのオフィスに遊びに来てください！</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>


WebDB Forum 2016でKARTEを支えるリアルタイム解析エンジン「Brook」の発表をしてきました。

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました | PLAID engineer blog

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました

<p>こんにちは。プレイドの@sdaikichiです。現在のトレーナーレベルは22、捕まえたポケモンは103種です。</p>
<p><a href="/2016_08_24_uitest_automation/">前回の@positiveflatの記事</a>ではプレイドにおける自動テスト環境をご紹介しました。</p>
<p>今回は、プレイドが</p>
<ul>
<li>__40通り以上の環境__を対象に</li>
<li>__すべて自動__で</li>
<li>ついでに__CircleCIのコンテナリソースもそんなに使わない__で</li>
</ul>
<p>マルチブラウザテストを実現している環境についてご紹介します。</p>
<h2>目次</h2>
<ul>
<li>なぜマルチブラウザテストが必要なのか</li>
<li>BrowserStackの紹介</li>
<li>運用してみてわかったコツ</li>
<li>まとめ</li>
<li>最後に</li>
</ul>
<h2>なぜマルチブラウザテストが必要なのか</h2>
<p>KARTEをお客様が利用する際には、来訪者をトラッキングしたり接客サービスを表示するためのscriptタグをお客様サイトに埋め込んでいただきます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ae5043c1-f735-4ca2-94e4-98f14d0f5371/2dd29a3e-b556-4503-afe4-04ac37414d8c.png" alt=""><br>
(接客サービス配信のイメージ)</p>
<p>お客様サイトには当然様々な環境(OS,ブラウザ,端末...)の来訪者がいらっしゃいます。</p>
<p>その際に特定のブラウザでのみ意図した挙動をしない、といった事態は当然避ける必要があります。<br>
世のフロントエンドエンジニアの皆様はIE対応というワードを聞いただけで__仕事を放り投げて目黒川にミニリュウを捕りに行きたくなる衝動に駆られる__かと存じますが、KARTEではそうはいきません。</p>
<p>全ての環境をトラッキングや接客サービス配信の対象としているわけではありませんが、どんな環境でもScriptの実行はされるため、古いブラウザとはいえエラーの発生などは防ぐ必要があります。</p>
<p>例えば有名なのがこちら。この構文が紛れ込んでしまうだけでIE6,7でSyntaxErrorが発生してしまいます。</p>
<pre><code>var data = { hoge:1, fuga:2, piyo:3, }; // オブジェクトリテラル末尾のカンマ
</code></pre>
<p>エンジニアが気をつけていても、例えば依存ライブラリの更新などでこういったエラーが入り込む可能性があります。<br>
かといってこういったエラーにエンジニアが過度に敏感になると開発スピードが著しく落ちてしまいます。</p>
<p>そこで、これまであったトラブルや考えうるケースを抽象化し、CircleCI上でマルチブラウザのテストを行おう！ということになりました。</p>
<h2>BrowserStackの紹介</h2>
<p>マルチブラウザテストの実行には<a href="https://www.browserstack.com/">BrowserStack</a>の<a href="https://www.browserstack.com/automate">Automate</a>を利用しています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cf010a08-183d-4aec-b779-074ac181b4e8/afefb92d-4bda-4f9f-a967-8dc6cc9d8c6e.png" alt=""><br>
このサービスの特徴として</p>
<ul>
<li>
<p><a href="https://www.browserstack.com/list-of-browsers-and-platforms?product=automate">かなり自由度の高い組み合わせのOS/ブラウザ/端末が用意されており</a>、設定ファイルに追記するだけで簡単にテスト対象を追加できます。</p>
</li>
<li>
<p>管理画面も非常に充実しており、Selenium testではなんと <strong>実行画面を全て録画し、動画として管理画面上で再生することができます</strong>。<br>
これにより不便になりがちなCI環境のSelenium Testのデバッグが格段に行い易くなりますし、コマンドラインに表示されるテスト結果からはわからない各ブラウザでの細かい表示の違いなどにも気付きやすくなります。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/daff3600-92f5-4f18-9a1f-d35592fedcce/1064fcae-374b-4b3e-b823-0c9794020dc4.png" alt=""></p>
</li>
<li>
<p>Javascript Testing(ブラウザ上で行うユニットテスト)、Selenium Testing(Selenium webdriverを利用したUIのテスト)に対応しています。</p>
</li>
</ul>
<p>テスト対象はブラウザ上で動作するJavascriptですが、メソッドごとのユニットテストはJavascript Test、接客サービスの表示・操作などUI的な部分はSelenium Testと、観点によりテストを分けています。</p>
<h2>Javascript Test</h2>
<p>BrowserStackのJavascript Testを利用するにあたり、様々なライブラリが公開されています。<br>
https://www.browserstack.com/javascript-testing-api<br>
プレイドでは<a href="https://github.com/browserstack/browserstack-runner">BrowserStack Runner</a>を利用しています。</p>
<p>BrowserStack Runnerはjsonの設定ファイルに</p>
<ul>
<li>実行するテスト対象ファイル</li>
<li>テストフレームワーク(mocha, jasmine, qunit)</li>
<li>対象ブラウザ</li>
</ul>
<p>などを指定するだけでテストを実行してくれるため、簡単に導入することができます。</p>
<p>jsonの設定ファイルを切り替えれば、たとえばサービスの対象ブラウザ用のテストと非対象ブラウザ用のテストを用意して、それぞれ別に実行することができます。</p>
<p>target.json</p>
<pre><code class="language-json">{
    &quot;username&quot;: &quot;yourusername&quot;,
    &quot;key&quot;: &quot;youraccesskey&quot;,
    &quot;test_path&quot;: &quot;target_browser_test.html&quot;,
    &quot;test_framework&quot;: &quot;mocha&quot;,
    &quot;browsers&quot;:[
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Firefox&quot; , &quot;browser_version&quot;: &quot;47&quot;},
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Chrome&quot;, &quot;browser_version&quot;: &quot;51&quot; },
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Edge&quot;, &quot;browser_version&quot;: &quot;13&quot; }
    ]
}
</code></pre>
<p>no_target.json</p>
<pre><code class="language-json">{
    &quot;username&quot;: &quot;yourusername&quot;,
    &quot;key&quot;: &quot;youraccesskey&quot;,
    &quot;test_path&quot;: &quot;no_target_browser_test.html&quot;,
    &quot;test_framework&quot;: &quot;mocha&quot;,
    &quot;browsers&quot;:[
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;IE&quot; , &quot;browser_version&quot;: &quot;7.0&quot;},
        { &quot;os&quot;: &quot;OS X&quot;, &quot;os_version&quot;:&quot;El Capitan&quot;, &quot;browser&quot;: &quot;Safari&quot;, &quot;browser_version&quot;: &quot;9.1&quot; },
        {&quot;os&quot;: &quot;ios&quot;, &quot;os_version&quot;: &quot;9.3&quot;, &quot;device&quot;: &quot;iPhone 6S&quot;},
    ]
}
</code></pre>
<p>設定ファイルはBROWSERSTACK_JSONという環境変数を読みにいきます。<br>
CircleCIではコマンド実行時の環境変数をcircle.ymlで簡単に指定することができるので、以下のように記述すればOKです。</p>
<pre><code class="language-yml">test:
  override:
    browserstack-runner:
      BROWSERSTACK_JSON: target.json
    browserstack-runner:
      BROWSERSTACK_JSON: no_target.json
</code></pre>
<p>実行すると管理画面にはこのように結果が表示されます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3a74810e-8958-499d-8678-1ea451173cf1/7741e0d3-ab45-4fa2-bebf-7683fde93f07.png" alt=""></p>
<h2>Selenium test</h2>
<p>Selenium testは、自サーバに用意したテストページにアクセスして行っています。<br>
このページにはお客様にサイトに埋め込んでいただくScriptが置かれており、実際の接客サービスの配信やエラーの有無などを確認することができます。</p>
<p>BrowsesrStackからローカル(この場合CircleCIのサーバー)にアクセスさせるために<a href="https://www.browserstack.com/local-testing#command-line">BrowserStack Local</a>をダウンロードし、実行しておきます。</p>
<pre><code class="language-YAML">dependencies:
  pre:
    - cd /usr/local/bin;
    sudo wget &quot;https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip&quot;;
    sudo unzip BrowserStackLocal-linux-x64.zip;
    sudo rm BrowserStackLocal-linux-x64.zip;
test:
  pre:
    - /usr/local/bin/BrowserStackLocal youraccesskey:
      background: true
</code></pre>
<p>テストコードの中でBrowserStackを利用するようにselenium webdriverのcapabilityを指定します。</p>
<pre><code class="language-coffee">CAPABILITIES = [
  { os: 'Windows', os_version:'10', browserName: 'Edge'}
  { os: 'Windows', os_version:'10', browserName: 'IE', browser_version: '11.0' }
  { os: 'OS X', os_version:'El Capitan', browserName: 'Safari' }
  { os: 'OS X', os_version:'El Capitan', browserName: 'Firefox' }
  { browserName: 'iPhone', platform: 'MAC', device: 'iPhone 6S Plus', emulator: true } #emulator: trueの理由は後述
  { browserName: 'iPhone', platform: 'MAC', device: 'iPhone 6S', emulator: true}
]

CAPABILITIES.forEach (capability) -&gt;
  before -&gt;
     @driver = new webdriver.Builder()
        .usingServer('http://hub-cloud.browserstack.com/wd/hub')
        .withCapabilities(capabilities)
        .build()
  #以下テストケースを記述。
  #ローカルへのアクセスが発生する部分のURLはlocalhostでOK
</code></pre>
<h2>運用してみてわかったコツ</h2>
<h3>BrowserStackでのテスト並列化</h3>
<p><a href="/2016_08_24_uitest_automation/">前回の記事</a> ではCircleCIのコンテナ追加による並列化・高速化について触れました。<br>
BrowserStackのSeleniumテストも、ローカルやCIで行う場合と同様、時間がかかります。<br>
しかしながらBrowserStack AutomateのSelenium Testは実行はBrowserStackのサーバ上で行われるため、手元のリソース(CircleCiのコンテナ)は必要ありません。</p>
<p>逆に言いますと、ボトルネックになるのはBrowserstack側の並列上限数です。<br>
1〜25の並列数で<a href="https://www.browserstack.com/pricing">Pricingが用意されています</a> 。サービス規模やリポジトリへのpush頻度にあわせて選ぶと良いでしょう。</p>
<p>プレイドでは契約した並列数に合わせてCircleCI上でテストを__すべてバックグラウンドで実行する__shell scriptを記述し、circle.yml上で実行しています。</p>
<h3>Mobileは自由度低め</h3>
<p>Mobileのテスト環境はPCに比べ、自由度が若干落ちます。<br>
PCがOS/Browser、それらのバージョンを自由に組み合わせて使えるのに対して、Mobileは端末/OS/Browser及びそれらのバージョンは固定です。それでも圧倒的なバリエーションですが。<br>
また、最近エミュレーターではなく実機でのテストがリリースされたようですが、こちらを試してみたところまだ動作が不安定だったため、プレイドでは導入を一旦見送っています。（これがSelenium Testでのemulator:true の理由）</p>
<h3>Retry機構は必要</h3>
<p>BrowserStackではたまにインスタンス・エミュレータの起動に失敗することがあるようで、1ケースも実行されずタイムアウトで落ちることがあります。<br>
そのため、プレイドでは各環境のテストが失敗した際には3回までのRetryを行っています。<br>
ここは開発速度とのトレードオフで現在も試行錯誤中です。</p>
<h2>まとめ</h2>
<p>以上、プレイドにおけるマルチブラウザテストについてご紹介いたしました。<br>
<code>{ os: 'OS X', os_version:'Snow Leopard', browserName: 'Firefox' }</code>  のような、シェアの低さゆえにもし問題が起こるとしたらかなり気付くのが遅れそうな環境でも手軽にテスト対象に加えられるようになったのは大きいと思います。</p>
<p>もちろん、まだまだテストケースをはじめテスト環境も改善を加えていきます。</p>
<p>ウチはこんなことやってるよ！といった事例がございましたらぜひぜひシェア時にコメントくださいませ！</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


CircleCI上で、BrowserStackを利用したマルチブラウザJavascript Test,Selenium Test を実現している方法についてご紹介します。Selenium webdriver, CircleCI, BrowserStack

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する| PLAID engineer blog

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

<p>こんにちは。プレイドの野田(<a href="https://twitter.com/positiveflat">@positiveflat</a>)です。<br>
弊社株式会社プレイドでは、ウェブ接客プラットフォームの<a href="https://karte.io/">KARTE</a>というサービスを開発・提供しています。今回は、私たちのチームの開発方針に触れ、その方針を実現するための取り組みの一部として行っている、我々の製品の品質を維持するGUIテストの仕組みについてご紹介いたします。</p>
<h2>目次</h2>
<ul>
<li>プレイドの開発方針とGUIテストの位置付け</li>
<li>GUIテストの自動化が進むにつれて起こる問題</li>
<li>CircleCI上でのテストの並列実行による総実行時間の短縮</li>
<li>CircleCI Enterpriseの導入によるテストの高速化</li>
<li>Ghost Inspectorを使ったGUIテストスクリプト開発の高速化</li>
<li>課題</li>
<li>最後に</li>
</ul>
<h2>プレイドの開発方針とGUIテストの位置付け</h2>
<p>弊社の開発チームでは、以下の方針のもと、フラットな組織でスピード感のある開発を目指しています。</p>
<ul>
<li>全員が自分で判断する</li>
<li>全員がゼロベースで考える</li>
<li>全員が成長する</li>
</ul>
<p>これらの実現のために、あえてマネジメントを置かずに自由でフラットなチーム体制で開発を行っています。</p>
<p>スピードを重視したまま各メンバーが自走するには、失敗を許容し、トライアンドエラーを許容する文化が必要であると考えています。とにかく試してみて、失敗したら考え直します。</p>
<p>一方で、お客様に安心して使っていただくために、当然品質は担保しなければなりません。KARTEは現在、大企業から中小企業、地方の商店まで、多数のお客様に導入いただいております。</p>
<p>私たちは日々KARTEの新機能の追加や既存機能の改善を行っており、ほぼ毎日本番環境に変更を反映させています。</p>
<p>本番環境に反映させた変更に問題があると、直接お客様の業務に影響を与える可能性があります。また、接客サービスの配信に関わる箇所に関しては、お客様のサイトを閲覧している来訪者にも正しく接客ができなくなる可能性があります。</p>
<p>ユーザーに安定的にサービスを提供し、一方で開発のスピードを高速化するためには、トライアンドエラーのサイクルの中に品質を保証する仕組みを導入していく必要があります。</p>
<p>そこで、我々は重要なシナリオに関してはGUIテストの自動化を行い、正しくアプリケーションの操作が行えることを自動でテストできるような仕組みを作っています。</p>
<h2>GUIテストの自動化が進むにつれて起こる問題</h2>
<p>日々の開発の中で、追加した変更が生む欠陥をできるだけ早期に発見できるようにするために、リモートブランチに変更がpushされる度にCIツールのプロセスが回り、ユニットテスト（UT）や自動化されたGUIテストが流れるようにしています。</p>
<p>ちなみに、GUIテストはSelenium webdriverを使用してテストスクリプトを書いています。リリース時にはCircleCI上でproduction buildを作成したりもしていますが、これについての説明は本記事の主題と外れるので割愛します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/eba4a7e4-148a-4033-8ab6-6e3a02ecfff2/flow-1.png" alt=""></p>
<p>自動化されたGUIテストを流すことには、以下のようなメリットがあります。</p>
<ul>
<li>人手よりも短時間でテストを実行することができる</li>
<li>人手では気が付きにくいバグも発見することができる</li>
<li>regressionの早期発見ができる</li>
</ul>
<p>一方で、GUIテストの自動化が進むにつれて、以下のような問題も起きます。</p>
<ul>
<li>テストコードが長くなると、テストを流すのに時間がかかり、テスト待ちが起きる</li>
<li>UIを変更した際に、テストコードのメンテナンスに時間がかかる</li>
</ul>
<p>弊社では、上記の課題を解決するために、様々な取り組みをしてきましたので、ここからはその取り組みを紹介します。</p>
<h2>CircleCI上でのテストの並列実行による総実行時間の短縮</h2>
<p>弊社では、上でも触れたように、githubのブランチへのpushごとにCircleCIのプロセスが走るようにしています。その中でGUIテストとUTが流れ、そのブランチを紐付けたPull Request上にテストの結果を表示して、レビュー前に確認できるようにしています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/045c0a75-c978-42fa-974a-191da5603361/CIProcess-1.png" alt=""></p>
<p>CircleCIの並列化は、CircleCIの管理画面でコンテナ数を増やした後に、circle.ymlで並列実行したいコマンドに以下のようにオプションを渡すだけで簡単にできます。</p>
<pre><code class="language-yml">test:
    override:
        [並列実行したいコマンド]:
           parallel: true
</code></pre>
<p>(参考: https://circleci.com/docs/parallel-manual-setup/ )</p>
<h2>CircleCI Enterpriseの導入によるテストの高速化</h2>
<p>テストやビルド、デプロイのためのCIツールとして、<a href="https://circleci.com/enterprise/">CircleCI Enterprise</a>を使用しています。当初はCircleCIのコンテナ数ごとの課金の通常プランを使用していましたが、テストの実行時間に課題がありました。</p>
<p><a href="https://codeship.com/">codeship</a>や<a href="https://travis-ci.org/">Travis CI</a>などの他のCIツールも試してみましたが、現在はマシンスペックをコントロールすることができるCircleCI Enterpriseを導入しています。</p>
<p>CircleCI Enterpriseですと、コンテナは独自にインスタンスを立てて管理する必要がありますが、pushが少ない深夜はインスタンス数を減らすなど、独自に工夫して管理しています。</p>
<h2>Ghost Inspectorを使ったGUIテストスクリプト開発の高速化</h2>
<p>新しい機能が頻繁に追加されたり、既存の機能が頻繁にアップデートされたりすると、更新すべきGUIテストのスクリプトが多くなり、更新が追いつかなくなります。</p>
<p>そこで、Ghost Inspectorというサービスを使い、テストスクリプト作成を簡易化する取り組みにもチャレンジしています。Ghost InspectorはSelenium IDEベースのウェブサービスで、実際の画面操作をレコーディングして、テストケースに落とし込むことができます。</p>
<p>Ghost Inspectorでは、下図のようにChromeの拡張機能を使ってレコーディングをスタートすることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/da4a6914-c5dc-4801-8574-5d4a589bf0f7/GI1-2.png" alt=""></p>
<p>レコーディングしたテストはAPI経由で実行可能なので、CircleCIなどのCIツールからも呼び出すことが可能です。  また、テスト結果はビデオで録画されているため、テストが失敗した場合はどこでテストが失敗したかを確認することができます。</p>
<p>ただし、CircleCIで使用しているインスタンスはプライベートネットワーク上にあるため、Ghost Inspectorからそのままアクセスすることはできません。</p>
<p>通常プランのCircleCIのインスタンスを使用する場合は、<a href="https://ngrok.com/">ngrok</a>などを利用してトンネルを掘り、外からアクセスを可能にする方法が便利です。CircleCIから実行する場合のcircle.ymlは、大まかに以下のようになります。</p>
<pre><code class="language-yml">test:
  override:
    - [環境変数の設定やビルドの設定コマンド];
    - [KARTE(テスト対象サービス)の起動コマンド];
          background: true
    - npm install ngrok -g #ngrokのインストール
    - ngrok authtoken &lt;auth_token&gt; #authtokenの設定
    - ngrok http -subdomain=&lt;testhostname&gt; 8020;
          background: true
    - sleep 120
    - curl &quot;https://api.ghostinspector.com/v1/suites/&lt;suite name&gt;/execute/?apiKey=&lt;api_key&gt;&amp;startUrl=https://&lt;testhostname&gt;.ngrok.io/&quot; &gt; ghostinspector.json
    - if [ $(grep -c '&quot;passing&quot;:false' ghostinspector.json) -ne 0 ]; then exit 1; fi
      fi
</code></pre>
<p>このサービスの便利なところは、レコーディングを使ってテストを追加するGUI操作ができれば誰でもテストを作ることができるようになるところです（ただし、実際はUIの更新の待ち時間の調整など、微調整が必要でした。）。</p>
<p>最終的にはテストコードを書いた方が良い場合でも、新しい機能や変更があった機能に対してGUIのテストをまず早い段階で用意しておくことは、回帰テストとしては有効だと考えられます。</p>
<h2>課題</h2>
<p>以上のように、プレイドでは攻めの開発方針を実現するために、CIによるテストの自動化など様々なことに取り組んでおります。</p>
<p>しかし、テストカバレッジは今後も上げていかなければならないですし、それと共にテストの実行時間は長くなるので、依然として課題は残ります。レコーディングによるテスト自動化も、レコーディング後に継続的に実行できるように微調整が必要なため、なかなかうまくフローに組み込めないなどの課題もあります。</p>
<p>今後もこれらの課題の解決の解決に取り組みつつ、開発方針を維持できるような仕組みづくりをしていきたいと考えています。</p>
<h2>最後に</h2>
<p>テスト自動化に関しては、この他にもPCやスマートフォンなどの複数端末上でのテストを自動化し、並列実行する取り組みなども行っていますが、それについても後日このブログで紹介させていただきます。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


スピード重視の開発体制を実現するために、KARTEの開発で取り組んでいるテスト自動化について紹介します。Selenium webdriver, CircleCI, Ghost Inspector

スピード重視の開発体制を実現するためのUIテスト自動化 | PLAID engineer blog

スピード重視の開発体制を実現するためのUIテスト自動化

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b1a2c506-1fcb-4018-910c-f4b365481cf1/80eb8949-86ff-4ffd-a522-c5fb93ff2926.jpg" alt="DSC00055.jpg (1.4 MB)"></p>
<p>本日は8/3(水) に開催しました「【FiNC×プレイド】Machine Learning Meetup #1」のレポートをお届けしたいと思います！<br>
機械学習を用いた画像認識の話、チャットBotの話等、面白い内容でした！</p>
<h2>発表内容</h2>
<ul>
<li>食事指導を機械学習技術で助ける話 (FiNC 小林さん)</li>
<li>ちゃんと使えるBotについて考える (プレイド CTO 柴山)</li>
<li>いまさら聞けない機械学習の評価指標 (dr_paradi さん)</li>
<li>データマイニングやってて思うこと (おおとや さん)</li>
</ul>
<h2>食事指導を機械学習技術で助ける話</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f98743bb-41f3-4d72-9645-8c34d8558cf8/9d316b23-3cda-4231-adef-862ccc5a06d9.jpg" alt="DSC00030.jpg (895.4 kB)"></p>
<p>まずFiNC 小林さんから「食事指導を機械学習技術で助ける話」についてお話頂きました。<br>
FiNCさんでは機械学習に力を入れておられ、<a href="http://www.nikkei.com/article/DGKKZO06187280X10C16A8TI5000/">ＡＩ特化の研究所を新設</a>されるそうです！</p>
<div style="width: 100%;">
<script async class="speakerdeck-embed" data-id="287f253add1f423496e837716ddf9d48" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>FiNCさんは、アプリを通じてダイエットのマンツーマン指導を受けることができるサービスを提供されています。その中で、機械学習を用いてユーザーが送った食事の写真の内容を自動で認識したり、食事の内容の偏りや睡眠、体重の時系列変化に異常があったりした際に自動でそれを検知するという取り組みをされているそうです。</p>
<p>どのような食べ物が写っているかに関しては、畳み込みニューラルネットワーク(CNN; Convolutional Neural Network)を用いて行っているそうです。また、Faster R-CNN; Faster Regions with Convolutional Neural Networkを用いて一つの写真の中に何種類の食べ物が写っているかを認識させ、食事内容をより高度に認識させることを検討されているそうです。</p>
<p>今後はさらに、Mechanical Turkを使って教師データを作成したり、自動で食事指導の文書を生成することも視野に入れられているとのことでした。</p>
<p>近年フィットネストラッカー等で日々の生活の記録を取ることができますが、健康を考える上で重要な食事の記録を、写真を撮影するだけで行えるようになれば便利そうですね！</p>
<h2>ちゃんと使えるBotについて考える</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/720be3c5-d846-47f5-8bbb-96bb8a926bd4/8d8f51e5-35e5-4e80-b116-7c52e5a854f1.jpg" alt="DSC00048.jpg (1.3 MB)"></p>
<p>次にプレイドCTOの柴山から「ちゃんと使えるBotについて考える」についての発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="a86a7e669718491db72207aa96633c11" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>Botを使ってコミュニケーションさせようとすると、大量のデータが必要になってきます。<br>
しかし、シナリオ/ビジネスロジックを覚えるには現状ではデータが足りないので、先人たちのアプローチとしては下記をとっているとのことでした。</p>
<ul>
<li>シナリオベース(Google/Facebook/Softbank/Apple)</li>
<li>自然言語から定型化されたクエリにして処理 (Google/Facebook)</li>
<li>Outputは定型化したUI(Google)
<ul>
<li>検索結果</li>
</ul>
</li>
<li>対応できなかった時の次善策(Facebook/Google)
<ul>
<li>人が対応する等</li>
</ul>
</li>
</ul>
<p>こう考えてみると結局検索の延長線上でしか、Botを活かしきれていないことがわかります。</p>
<p>柴山の持論だと、このような定型化された作業の中で最もシステムがレバレッジを効かせられる部分はDBだとのことです。</p>
<p>ですので、Botのストロングポイントである、<code>検索/DB</code> を活かして一次回答をしながら、拾えないところは人間が返すという形がわかりやすいのではないかとのことです。</p>
<p>一次回答でBotが解釈できるシナリオを拡大するのに <a href="http://superscriptjs.com/">superscritpt</a>が面白そうなので興味のある方は見てみてはいかがでしょうか！</p>
<h2>いまさら聞けない機械学習の評価指標</h2>
<p>続いて <a href="https://twitter.com/dr_paradi">@dr_paradi</a>さんから「いまさら聞けない機械学習の評価指標 」についてお話頂きました。</p>
<p><strong> <a href="//www.slideshare.net/keisukeosone/ss-64685474" title="いまさら聞けない機械学習の評価指標" target="_blank">いまさら聞けない機械学習の評価指標</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/keisukeosone">圭輔 大曽根</a></strong></p>
<iframe src="////www.slideshare.net/slideshow/embed_code/key/um9FdtijcinP9B" width="100%" height="533" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px">  </div>
<p>最近は機械学習が流行り周辺ツールやライブラリ、データが充実してきており、機械学習を試しやすくなっている一方で「どのような指標を設定すればよいか」「指標を評価する関数をどう選ぶか」がポイントになってきています。</p>
<p><a href="https://twitter.com/dr_paradi">@dr_paradi</a>さんの発表では、代表的な評価関数を説明してくださいました！</p>
<p><a href="http://data.gunosy.io/entry/2016/08/05/115345">Gunosyデータ分析ブログ</a>に詳しい説明を書いてくださっていますので興味のある方はぜひ御覧ください！</p>
<h2>データマイニングやってて思うこと</h2>
<p>最後におおとやさんから「データマイニングやってて思うこと」についてお話頂きました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="07f6770726dd4f24836ddfb65c369684" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>機械学習のツールを盲目的に信じてデータ解析しても意味がなく、「解析の目的」「データの種類」「データの分布」「解析方法」をしっかり考えてPDCAサイクルをまわしながらデータ解析をしていこうというお話でした！</p>
<h2>次回</h2>
<p>次回は<strong>9月下旬</strong>にFiNCさんのオフィスで**【FiNC×プレイド】Machine Learning Meetup #2**を開催します！<br>
<a href="http://plaidtech.connpass.com/">Connpass</a>でイベントの募集を行いますので、ご興味のある方は是非ご参加ください！</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。<br>
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました！

機械学習&チャットBotについて語る！【FiNC×プレイド】機械学習の勉強会を開催しました！| PLAID engineer blog

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

Service Workerの全体像の解説と、それがもたらすWebの未来を考察します。今後の動向を左右しそうなService worker meeting notesについても解説します。

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来 | PLAID Engineer Blog 

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来

<p>こんにちは、プレイドの@wikrshです。</p>
<p>プレイドが提供している<a href="https://karte.io/">KARTE</a>では、サイトに来訪するユーザに応じて様々な接客アクションを行う機能を提供しています。</p>
<p>接客アクションのようなウェブサイト上の施作の効果を検証する方法としてはA/Bテストが有名だと思いますが、今回のエントリーではA/Bテスト以外の手法としてバンディットアルゴリズムをざっくりと紹介したいと思います。</p>
<h3>A/Bテストとバンディットアルゴリズム</h3>
<p>バンディットアルゴリズムは、いくつかの施作を実験しながら実験中に得られる効果もできるだけ大きくしたい、という目的のためのアルゴリズムです。</p>
<p>例えばECサイトの商品画像としてAとBの2つの画像の内どちらを表示した方が購入確率が上がるかということを知りたい場合、ユーザによって画像をランダムに表示してどちらの画像を表示した方が購入確率が高いか(もしくは有意差がないか)を検証しますが、ある画像を表示した方が購入確率が高いのであればできるだけ多くその画像を表示した方が全体の購入確率は高くなります。</p>
<p>A/Bテストでは十分なサンプル数を集めるまであらかじめ決めた割合(例えば1:1)でランダムに表示することを繰り返すため劣っている案も一定数表示することが必要となりますが、劣っている案を表示することは結果的に（優れた案を表示するのと比較して）コストを払っているとも考えられます。<br>
バンディットアルゴリズムで対象としている問題はこのコストを小さくすることであり、その時点までに得られた結果の利用の仕方・次の案の表示のさせ方のアルゴリズムになっています。</p>
<h3>Epsilon-Greedyアルゴリズム</h3>
<p>ここでは具体的なアルゴリズムの例として、Epsilon-Greedyアルゴリズムを紹介します。</p>
<p>Epsilon-Greedyアルゴリズムは単純な動作のアルゴリズムになっていて以下のような動作となります。</p>
<ul>
<li>ある割合(0 &lt; ε &lt; 1)で選択肢からランダムに選択する</li>
<li>1-εの割合でこれまでの結果が最も良い選択肢を選択する</li>
</ul>
<p>例えばε=0.3とした場合、先の画像の例では以下のような動作となります。</p>
<ul>
<li>画像A、Bをそれぞれ15%ずつの割合で表示</li>
<li>残り70%はその時点での結果が良い画像を表示</li>
</ul>
<p>各画像は最低でも15%の確率で表示されるため、十分な回数繰り返せば各選択肢の効果を検証することが可能です。<br>
また、70%はその時点で最も良い結果の画像を表示するため、優れた案（最適な案）が正しく選択されれば全体の結果も向上する可能性があります。</p>
<p>このアルゴリズムについて簡易的な実装をしたのが以下のコードです。</p>
<pre><code class="language-coffeescript">_ = require 'lodash'

class EpsilonGreedyAlgorithm
  # @params {Number} nChoices 選択肢の数
  # @params {Number} epsilon ランダムに選択を行う割合
  constructor: (@nChoices, @epsilon) -&gt;
    @initialize()

  initialize: -&gt;
    @averages = _.fill Array(@nChoices), 0 # 選択肢ごとの得られた結果の平均値
    @counts = _.fill Array(@nChoices), 0 # 選択肢ごとの選択回数
    @nBest = 0 # 現状の最良の選択肢

  # 選択肢から一つ選択する
  select: () -&gt;
    if Math.random() &lt; @epsilon
      # 全ての選択肢からランダムに選択
      return Math.floor(Math.random() * @nChoices)
    else
      # その時点で最も良い結果の選択肢を選択
      return @nBest

  # 結果を受け取って状態を更新する
  # @params {Number} n 選択肢の番号(0..nChoices-1)
  # @params {Number} reward 得られた結果(報酬)
  update: (n, reward) -&gt;
    @counts[n] += 1
    c = @counts[n]
    @averages[n] = ((c - 1) / c) * @averages[n] + (reward / c)

    @nBest = n if @averages[n] &gt; @averages[@nBest]
</code></pre>
<p>バンディットアルゴリズムはその時点の結果を元にいずれかの選択肢を選択するという動作となっているため、結果を受け取るためのメソッド(コード上の<code>update()</code>)と選択したものを返すメソッド(コード上の<code>select()</code>)を実装しています。</p>
<p>以下のような形で動作します。（A案を0、B案を1としています。）</p>
<pre><code class="language-coffeescript"># A案,B案の2つのみ、e = 0.3
ega = new EpsilonGreedyAlgorithm 2, 0.3
ega.select() # =&gt; 1 (B案を選択)
... # B案を表示して結果(例えばユーザが購入したかどうか)を得る
ega.update(1, 1) # B案を選択した結果、ユーザが購入を行った
ega.select() # =&gt; 0 (A案を選択)
... # A案を表示...
</code></pre>
<h3>動作の検証</h3>
<p>バンディットアルゴリズムでは選んだ選択肢に対するフィードバックを受けて次の動作が決まっていくため、動作の検証のためにはシミュレーションが必要となります。</p>
<p>ここでは<a href="http://www.oreilly.co.jp/books/9784873116273/">「バンディットアルゴリズムによる最適化手法」</a>を参考に、一回の試行の結果はランダムに決定し、シミュレーションを繰り返すことで動作を検証するという形でどのような動作になるのかを見ていきたいと思います。</p>
<p>例えばあるA案、B案の2つをコンバージョンレートで比較したい場合は、ある一回の試行の結果を0（コンバージョンしなかった）、1（コンバージョンした）で表すことでシミュレーションが行えます。</p>
<pre><code class="language-coffeescript">class ConversionSimulator
  constructor: (@cvr) -&gt;

  # 設定したコンバージョンレートでランダムに0 or 1の結果を返す
  get_result: () -&gt;
    if Math.random() &lt; @cvr
      return 1
    else
      return 0
</code></pre>
<p>コンバージョンレートではなく購入金額で比較したい場合は、0/1ではなく購入金額を返すようにすればよさそうです。</p>
<pre><code class="language-coffeescript">class PurchasePriceSimulator
  constructor: (@cvr, @minPrice, @maxPrice) -&gt;

  get_result: () -&gt;
    if Math.random() &lt; @cvr
      return _.random @minPrice, @maxPrice
    else
      return 0
</code></pre>
<p>コンバージョンレートでの比較を行う場合のシミュレーションとして、A案を提示した場合は5%のCVR、B案を提示した場合は10%のCVRが得られる状況のシミュレーションを行ってみます。</p>
<pre><code class="language-coffeescript"># A案は5%のCVR、B案は10%のCVR
cvrs = [0.05, 0.10]
choices = cvrs.map (cvr) -&gt;
  new ConversionSimulator(cvr)

algo = new EpsilonGreedyAlgorithm 2, 0.3
algo.initialize()

# 1000回A/B案の選択・提示を繰り返す
results = _.times 1000, -&gt;
  n = algo.select()
  reward = choices[n].get_result()
  algo.update(n, reward)
  return n
</code></pre>
<p>このシミュレーションを1000回繰り返して、最適な案（B案)を提示した割合をプロットした結果が下の図です。（ε=0.3）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/75d53380-c2f0-4cb4-80a9-bdc0130e0eda/test-1.png" alt=""></p>
<p>コンバージョンレートの低いA案を最適と予想して始めているため、始めの方は最適な案を選んだ割合は低いですが、回数を増すごとに最適な案を選ぶ割合が増加していることがわかると思います。<br>
一方でEpsilon-Greedyアルゴリズムでは一定の割合でランダムに案を選びに行くため、回数が増加しても最適な手を選ぶ割合は85%付近で収束しています。</p>
<h3>その他の方法</h3>
<p>バンディットアルゴリズムは上で紹介したEpsilon-Greedyアルゴリズム以外にも多種多様なものが提案されており、詳細については割愛しますが代表的なものには</p>
<ul>
<li>Softmaxアルゴリズム</li>
<li>UCBアルゴリズム</li>
<li>Randomized Probability Matching</li>
</ul>
<p>などがあります。<br>
Epsilon-Greedyアルゴリズムよりは探索・活用を単純な動作で行っていますが、これらのアルゴリズムはこれまでの結果から優位性の程度を算出して探索・活用を行ったり、サンプル数の増加に合わせて活用の割合を下げていくなどの工夫が入っています。<br>
また、Epsilon-Greedyアルゴリズムのεのようなパラメータを試行回数に応じて切り替えていくことで、最適な案に最終的に収束させるような方法もあります。</p>
<h3>所感</h3>
<p>バンディットアルゴリズムはA/Bテストと比較して魅力的な点がある反面、<br>
実際の導入時に考慮する必要がある点は多いと感じました。<br>
今回はバンディットアルゴリズムの中でも最も単純なEpsilon-Greedyアルゴリズムを紹介しましたが、実際に導入する場合は</p>
<ul>
<li>結果として使用する値（コンバージョンや購入金額等）に対してどのような動作になるか</li>
<li>パフォーマンスの面から逐次更新ではなくバッチ更新とした場合にはどのような挙動となるか</li>
<li>パラメータの設定やテスト期間をどのように設定するか</li>
</ul>
<p>などを検討していく必要があると思います。<br>
バッチでの更新方法については実際の導入例もあるようですので、今後はこの辺りを検討していきたいと思います。</p>
<h3>最後に</h3>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。<br>
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


今回のエントリーではA/Bテスト以外の手法としてバンディットアルゴリズムをざっくりと紹介したいと思います。

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた / PLAID Engineer  Blog

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた

<p>こんにちは！プレイドでインフラエンジニアをしている@ikemonnです。</p>
<p>7/5(火)に<a href="http://plaidtech.connpass.com/event/33511/">【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 </a>を開催しました！</p>
<img width="100%" alt="DSC09468.JPG (2.1 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fc9574b8-7728-4ae0-8e17-9586da3f4a38/79d8af47-57eb-4b5f-a566-f4b5f117b497.JPG.jpg">
<h2>TechBlog Deep Dive Meetup とは</h2>
<p>色々な会社で書かれているTechBlogの人気記事の内容を深掘りしていく勉強会です！</p>
<p>実際にブログを書いたエンジニアに登壇してもらい、記事の内容+α(ブログに書ききれなかったこと、ブログを書いた後に行ったこと等)を発表してもらいます。</p>
<p>今回は、<a href="https://toreta.in/jp/">トレタ</a>さんと一緒に開催させていただきました！</p>
<p>トレタさんからは、<a href="http://tech.toreta.in/entry/2016/06/16/114919">EngineyardからAWSに移設してAuroraの運用を開始した</a>や<a href="http://tech.toreta.in/entry/2016/04/14/143248">トレタのインフラ運用、支えている道具(Packer, Terraform, Serverspec, Ansible, Roadworker, Circle CI)、考え方</a>を書かれた佐野氏に登壇して頂きました。</p>
<p>プレイドからは、<a href="http://tech.plaid.co.jp/autoscaling-ec2/">1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン</a>を書いた@tik-son が登壇しました。</p>
<img width="100%" alt="DSC09506.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8c104bf9-0e02-4714-8bdd-d25e4cbda26c/78916cc8-85a5-4c44-b80e-b7741cc565a2.JPG.jpg">
<ul>
<li><a href="http://tech.toreta.in/">トレタ開発者ブログ</a></li>
<li><a href="http://tech.plaid.co.jp/">PLAID TechBlog</a></li>
</ul>
<h2>発表内容</h2>
<h3>トレタのインフラ運用</h3>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/e3b4f649-f78c-43af-9fb5-38628244bf99/fc540804-45bb-425c-a2c2-1450070b8c29.JPG.webp" alt="fc540804-45bb-425c-a2c2-1450070b8c29.JPG.webp"></p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="14b8185b93b947d8891888a9b7323372" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>トレタのインフラ運用について具体的に「どのようなツールを使って」「どのように運用しているか」を話していただきました。</p>
<p>Terraform, Packer, Ansible等、導入理由と運用上押さえておくべきポイントが上手くまとまっており、大変勉強になりました。</p>
<p>弊社でもTerraformを利用しており、お話にあった<code>tfstateファイルの扱い</code>や<code>すべてをterraform管理下には置かない</code>という部分は気をつけて運用しております。</p>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">「すべてをterraform管理下に置かない」ほんとこれ <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a></p>&mdash; 謎の音 (@onigra_) <a href="https://twitter.com/onigra_/status/750294797047304192">2016年7月5日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>「この発表をTerraformを使い始める前に聞きたかった…」となるプレゼンでした！</p>
<h3>KARTEを支えるAutoScaling~SpotInstance編</h3>
<img width="100%" alt="DSC09536.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/141a12e6-f165-4baf-9726-3852c6a0d86c/6dbf2a11-f9b2-42a4-9dc1-6f50a6cd2280.JPG.jpg">
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="c05b6b27593443b29aef55eb4b58c24c" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>いかにAutoScalingとSpotInstanceを上手く活用して運用しているかを話してもらいました。</p>
<p>SpotInstanceと聞くと「一時的なバッチ処理に使う」「テスト環境に使う」というイメージがあるかもしれないのですが、弊社では本番環境のステートレスなサーバ全てに使用しています。(管理画面用サーバ、解析サーバ等)</p>
<p>この発表では、SpotInstanceの価格変更にあわせて自動的にondemand⇔spotを切り替える仕組みを実装した話をしてもらいました。</p>
<p>ポイントは、<code>ondemand, spot, static</code>の3種類のサーバ群を用意すること。</p>
<p>「どのようなフローで切り替えを行っているのか」「実装する時に気をつけないといけない点」が詳しく書かれております。</p>
<p>実際に運用にのせたところ、サーバコストが1/2ほどになっているので、「サーバコスト減らしてよ！」と言われているインフラエンジニアの方必見です！</p>
<h3>対談</h3>
<img width="100%" alt="DSC09597.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58866921-6538-4c73-a736-d5a7042aa481/36b32a79-67bb-4922-a011-c1e63d176994.JPG.jpg">
<p>以下の3つのテーマで対談を行いました！</p>
<ul>
<li>HashiCorp製品の何をどうやって使っている？</li>
<li>AWSで辛いところは？</li>
<li>今後の展望</li>
</ul>
<h4>HashiCorp製品の何をどうやって使っている?</h4>
<p>トレタさんではTerraform,Vagrant,Packerを、プレイドではTerraformを使っています。</p>
<ul>
<li>Terraform
<ul>
<li>トレタ
<ul>
<li>VPC</li>
<li>Security Group</li>
<li>EC2</li>
</ul>
</li>
<li>PLAID
<ul>
<li>AutoScaling Group</li>
<li>EC2</li>
<li>ELB</li>
<li>CodeDeploy等</li>
</ul>
</li>
</ul>
</li>
<li>Vagrant
<ul>
<li>トレタ
<ul>
<li>開発環境構築</li>
</ul>
</li>
</ul>
</li>
<li>Packer
<ul>
<li>トレタ
<ul>
<li>AMI作成</li>
<li>Vagrant box作成</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>AWSで辛いところは？</h3>
<ul>
<li>ELBのIPを固定できないのが辛い</li>
<li>ELBのスケールが遅い</li>
<li>AutoScaleのAPIの上限が低くてすぐRateExceededになる</li>
</ul>
<h3>今後の展望</h3>
<ul>
<li>その時点での最適で柔軟なインフラ構成にしたい</li>
<li>AWSやGCPのどちらか一方を使うのではなく、両方の良いサービスを取り入れたハイブリッドなインフラ構成にしたい</li>
</ul>
<h3>Railsアプリケーション郡の構成管理、デプロイ等の話</h3>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="80d97567b26a4ed3aded1d163c2458a4" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>サーバの構成管理とデプロイをどのように行っているのかを話していただきました。</p>
<p>構成管理で使っているのはTerraform。<br>
<a href="https://speakerdeck.com/hiroakis/toretafalseinhurayun-yong">トレタのインフラ運用</a>でもお話がありましたが、Terraformには<code>管理に向くリソースと向かないリソース</code>があります。<br>
具体的に<code>どのリソースを継続的に管理していて、どのリソースは構築時のみ使うのか</code>ということに触れられているので、何に使うべきか迷っている方は一読を！</p>
<p><code>AMI作成まで</code>や<code>LaunchConfig作るまで</code>等を調整出来る、独自Packerクローンを作られたとのこと。すごい…！</p>
<p><strong> <a href="//www.slideshare.net/AkiraMiki/dockerize" title="Dockerizeして 大変だった話、幸せになった話" target="_blank">Dockerizeして 大変だった話、幸せになった話</a> </strong> from <strong><a href="//www.slideshare.net/AkiraMiki" target="_blank">Akira Miki</a></strong></p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/W6DcWT9VRF9I3" width="100%" height="533" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px">  </div>
<p>Docker導入して大変だったことと、その後に訪れた幸せについて話していただきました。</p>
<p>どんなことが大変だったのかの話では、運用に乗せてみないとなかなか想像しづらかった部分について話しておられたので勉強になりました！</p>
<p>苦労を乗り越えた後の幸せの話では、<code>リソースの有効活用とデプロイ時間の短縮</code>など「よーし、明日からDocker入れるぞ！」という気にさせられました！<br>
次回はLTではなく、20分枠で是非！</p>
<h3>2つのAuroraクラスタを同期したお話</h3>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="4d8d787993894ddca228419997c9b6ba" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>暗号化対応していない時期から使っていたAuroraを、リードレプリカを作ることで暗号化させた話をしていただきました。</p>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">暗号化されてないAuroraから暗号化されたAuroraへの移行、つらそう <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a></p>&mdash; sue445 (@sue445) <a href="https://twitter.com/sue445/status/750312797397848064">2016年7月5日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>ぱっと聞いただけで大変そうな話で、工夫して<code>Binary Log</code>の位置を書き出されたりすることでレプリカセットを組み、無事暗号化されたとのことでした！</p>
<h2>まとめ</h2>
<p>AWS, Terraform, Docker等、サーバ構築からプロビジョニング、運用まで幅広く各社の取り組みを聞くことができた勉強会でした！<br>
使用しているツールや、実運用の際にハマっていたり気をつけている部分が似通っていたこともあり、定期的にこのような会を開いて「上手くいったこと」「失敗したこと」の共有をしていければ良いなと思いました！</p>
<p>一緒に勉強会を開催してくださる企業さまも絶賛募集中です！<br>
<a href="https://plaid.co.jp/#contact">弊社HPのお問い合わせフォーム</a>からご連絡いただくか、Twitterで #plaidtech をつけてツイートしてください！</p>
<h2>次回</h2>
<p>プレイドでは今後も色々なテーマで定期的に勉強会を開催する予定です！<br>
次回は「機械学習」に関する勉強会を8月頃に開催する予定ですので、是非ご参加ください。<br>
今回もイベント募集開催日に募集人数がオーバーしてしまいましたので、ご興味がある方は<a href="http://plaidtech.connpass.com/">connpassのPLAID tech</a>でメンバー登録を！</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）募集一覧をご覧ください。</p>


7/5(火)に開催した【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 の開催レポートです。


Engineer Blog

Recent Article

【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜を開催しました！

コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

スピード重視の開発体制を実現するためのUIテスト自動化

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜を開催しました！

Popular Articles

Popular Tags

Archives

Writers

Recent Article

【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜を開催しました！

コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

スピード重視の開発体制を実現するためのUIテスト自動化

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 を開催しました！

Popular Articles

Popular Tags

Archives

Writers

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜を開催しました！