Engineer Blog

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

プレイドでエンジニアをしている田宮です。今回は Cloud Logging と BigQuery 用いて開発した 監査ログ の紹介をします。

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

<h1>はじめに</h1>
<p>こんにちはプレイドの<a href="https://cxclip.karte.io/products/info/message-beta/">KARTE Message</a>チームでエンジニアをしている<a href="https://x.com/prooooograming">土谷</a>です。</p>
<p>今回は大量メール配信を実現するためにKARTE Messageで取っている仕組みを紹介していきます。</p>
<h1>KARTE Messageについて</h1>
<p>本題に入る前に、まずKARTE Messageについて説明します。</p>
<p>KARTE Messageはマルチチャネル(Mail/アプリPush/LINE *)での大量配信を行えるMAツールとなっており、主に以下の機能を備えています。</p>
<ul>
<li>配信の管理
<ul>
<li>配信対象抽出の設定</li>
<li>配信コンテンツの設定・コンテンツへの埋め込み</li>
<li>配信速度・頻度の管理</li>
</ul>
</li>
<li>配信対象の管理
<ul>
<li>誰に配信するのかを取り扱うための配信対象を管理するためのリスト機能</li>
<li>リストに対するフィルタリング機能</li>
<li>リスト同士を組み合わせて配信対象を絞り込む機能</li>
</ul>
</li>
<li>配信コンテンツの管理
<ul>
<li>配信コンテンツをテンプレートとして管理</li>
</ul>
</li>
</ul>
<p>これらの機能に加えてKARTEの特有の機能を利用した配信対象の抽出などもできるようになっています。</p>
<p>* LINEとの連携機能は現状β版として提供しています。</p>
<h1>このブログで出てくる用語</h1>
<p>まずメール配信においてよく使われる用語の説明をします。理解している人は読み飛ばしてください。</p>
<p><code>Eメール</code> : 一般的にEメールはマーケティングメールとトランザクションメールに大別できます。</p>
<p><code>マーケティングメール</code> : 受信者がアクションをしていなくても送信者側が能動的に送信するメールです。メルマガ配信やクーポンメールなど。</p>
<p><code>トランザクションメール</code> :  受信者が何かしらのアクションを起こした時に受等的に送信するメールです。ログインメールやパスワードリセットメールなど。</p>
<p><code>メールバウンス</code> : 送信したメールが何らかの理由で相手のメールサーバーに拒否されて、送信者に戻ることです。メールバウンスはハードバウンスとソフトバウンスに大別できます。</p>
<p><code>ハードバウンス</code> : メールの拒否理由が恒久的な問題の場合のメールバウンスのことです。メールアドレスが存在しないなど。</p>
<p><code>ソフトバウンス</code> : メールの拒否理由が一時的な問題の場合のメールバウンスのことです。受信者のメールボックスがいっぱいなど。</p>
<p><code>IP/ドメインレビュテーション</code> : メール送信時に利用するサーバーのIPアドレスやFromドメインに対して付けられる評価をレピュテーションと呼びます。スパムメールのようなメールをたくさん配信しているとレピュテーションが下がり、メールプロバイダー(GmailやYahoo!メールなど)から受信を拒否される場合があります。レピュテーションの管理はメールプロバイダーがやっていたり、第三者機関がやっていたり、さまざまなパターンがあります。</p>
<p><code>SPF</code> : SPFレコードというDNSレコードを利用して、送信されたメールの送信元IPを確認することで送信者がなりすましをしていないかを確認する仕組みです。</p>
<p><code>DKIM</code> : DKIMレコードというDNSレコードを利用して、送信されたメールの内容が第三者に改竄されていないことを確認する仕組みです。</p>
<p><code>DMARC</code> : SPF/DKIMの確認に引っかかった時に、どのように対応すべきかを送信元のサーバーが表明しておく仕組みです。</p>
<h1>大量メール配信の運用における課題</h1>
<p>マーケティングメールが大量に送信されている現在の環境では、同様に大量のスパムメールも送信されています。メールプロバイダーはメールの大量送信に対して、スパムメールかどうか・送信者がスパマーではないかという判定を厳しく行なっています。</p>
<p>そのためマーケティングメールをエンドユーザーに届けるためには、送信したメールがスパムメールでないことを証明する必要があります。</p>
<p>メールプロバイダーは送信されたメールがスパムメールでないことを確認するために、以下のような項目を確認しています。</p>
<ul>
<li>SPF/DKIM/DMARCの設定確認
<ul>
<li>これらのDNSレコードの設定がされていないとスパムメールと判断される場合があります。</li>
</ul>
</li>
<li>IPレピュテーション・ドメインレピュテーションの確認
<ul>
<li>送信元のIPレピュテーションやドメインレピュテーションが低いと、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メールコンテンツの正当性の確認
<ul>
<li>メール内のコンテンツにhttpのセキュアではないリンクがあったり、不審なスクリプトなどが含まれていたりすると、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メール配信量の急増の検知
<ul>
<li>特定IPからのメールの配信量が急増すると、スパムメールと判断される場合があります。</li>
</ul>
</li>
</ul>
<p>上記のようなスパムメールかどうかの大量のチェックが各メールプロバイダーごとで設定されているため、マーケティングメールをエンドユーザーに届けることが簡単ではないことが課題となっています。</p>
<h1>KARTE Messageにおける大量のメールをエンドユーザーに届けるための仕組み</h1>
<p>ここからは、KARTE Messageで行なっているマーケティングメールを正常にエンドユーザーに届けるための仕組みを紹介します。</p>
<h2>AWS SESを利用したマルチテナント構成</h2>
<p>大量メール配信においてIPレピュテーションを高く保つことは、上述した通り非常に重要です。これを実現するには、スパムメールと判定される可能性のある質の低いメールの送信を極力避け、メールプロバイダーに確実に受信される質の高いメールを送信する必要があります。</p>
<p>そのため、質の高いメールの配信量を最大限に増やすことが有効なアプローチの一つです。これにより、仮に少量の質の低いメールが送信されたとしても、全体におけるその割合を低く抑えることができ、結果としてIPレピュテーションを高く維持することにつながります。</p>
<p><img src="https://ik.imagekit.io/plaid/913abcd7-570a-481a-bc9b-b9cb0c8ff3e4/blog_image1.png" alt="blog_image1.png"></p>
<p>KARTE Messageでは、それを実現する仕組みとしてマルチテナントなメール配信を行なっており、KARTE Messageが所有しているIPアドレスをクライアントごとに固定せず、全てのIPに均等に振り分けて送信しています。</p>
<p><img src="https://ik.imagekit.io/plaid/c3e46daa-6c2d-4f66-b27e-b7a349813334/blog_image2.png" alt="blog_image2.png"></p>
<p>結果として冒頭で述べた通り、KARTE Messageを利用しているクライアント全配信量が母数となるので、特定のクライアントで質の低いメールが多少送信されても影響を小さくすることができます。</p>
<p>また、複数のクライアントの配信をKARTE MessageのIPで送信しているため、配信はほぼ24時間常に行われています。そのため、1クライアントが急な大量配信をしたとしてもKARTE Message全体では配信量の急増にはなりにくく、メール配信量の急増によるIPレピュテーションの低下を防ぐことができ、送信されたメールもスパムメールと判定されづらくなります。</p>
<p>こういったIPレピュテーションの運用は、1クライアントでやろうとすると配信量や配信時間の問題で運用が難しくなる場合があります。KARTE Messageではマルチテナント配信にすることで、その運用負荷をクライアントから取り除いています。</p>
<h2>まとめ</h2>
<p>マルチテナント配信以外にも、KARTE Messageではメール配信の細かなモニタリングを行ったり、SPF/DKIM/DMARCの設定の補助機能なども提供することで、なるべくマーケティングメールの運用負荷を下げるような機能提供を行なっています。</p>
<p>KARTE Messageでは、メールという長年コミュニケーションツールとして中心になっている技術であるからこそ難しくなっている部分を管理することで、価値を届けるプロダクトを作っています。</p>
<p>興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


KARTE MessageというMAツールでメールの大量配信を安定的に行うためのシステム設計やIP運用の考え方などを説明

KARTE Messageで採用している大量配信を実現するためのアーキテクチャ

KARTE Messageの大量メール配信を支える技術

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

<p>こんにちは、monoi &amp; komukomo &amp; tik-sonです。<br>
11/18-11/21にかけてサンディエゴで開催された <a href="https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/">KubeCon + CloudNativeCon North America 2019</a>に参加してきたので、その様子をご紹介したいと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a7eaaca0-b5f9-470d-ae8d-2235c892f22a/image--5-.png" alt="image--5-"><br>
サンディエゴの景色。めちゃくちゃ過ごしやすい気候でした。</p>
<h2>Anthos Day</h2>
<p>メインカンファレンス前日のDay Zeroには、様々な企業がイベントを開催していました。<br>
私たちはその中でAnthos Dayに参加しました。</p>
<p><a href="https://cloud.google.com/anthos">Anthos</a>はGoogle Cloudが開発しているプラットフォームで、特定のクラウドに依存しないアプリケーション開発・実行環境を提供しています。<br>
例えば<a href="https://cloud.google.com/kubernetes-engine">GKE</a>をオンプレミスで動かすサービスなどを提供しています。</p>
<p>&quot;Anthos Day&quot;と言いつつも意外とGKE本体についてのアップデートの発表もあり、GKEユーザーである私たちに有意義な内容が多かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/04915593-5d9b-476e-95c0-7f84dc02b3f1/image--6-.png" alt="image--6-"><br>
Anthos Dayでのセッション</p>
<h2>日本人交流会</h2>
<p>Day Zeroの夜には<a href="https://kubecon-jp.connpass.com/event/145278/">日本人交流会</a>が開催されました。<br>
一昨年は30人程度だった参加者も今年は150人ほどまで増えたようで、ここからもKubernetesの盛り上がりが感じられました。</p>
<p>Kubernetesの知見を持った多くの方と情報交換ができ、また日本に帰ってからも継続できる繋がりを作ることができたのは非常に良かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/02e6efd5-5802-438b-b5fb-5ae77ceb1c05/image--7-.png" alt="image--7-"></p>
<h2>Kubecon開幕</h2>
<p>今年のKubeconには1万人以上が参加していたようで、会場は熱気に包まれていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b5d72ae-a5a4-4e4f-b29f-69b6c058e7e0/image--8-.png" alt="image--8-"></p>
<p>Kubernetesのユーザーというより、Kubernetesシステムまわりの開発者やプラットフォーム提供者によるセッションが多かったです。<br>
データベースやログ・監視系、セキュリティやサービスメッシュなどをはじめとした、あらゆる分野のプレイヤーがKubernetesエコシステムに参加しており、Kubernetesの柔軟性や拡張性の高さを感じるとともに、エコシステムの広げ方のうまさも改めて感じました。</p>
<p>意外なところでは、米国では金融機関や政府もKubernetesやCI/CDのオートメーションなどを活用したモダンなアーキテクチャを構築している事例も発表されてました。<br>
また、オンプレミスで運用している事例も多かったことも驚きました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ace13e0-de61-491f-9b1b-f4091d3d1ace/image--9-.png" alt="image--9-"><br>
会場には卓球台やレトロなゲームマシンもありました</p>
<h2>Anthos / GKEのPMとのミーティング</h2>
<p>Anthos / GKEの機能に関するフィードバックや、高速にスケールアウトすることが求められるKARTEにおいてKubernetesをどのように使うべきかなどに関してディスカッションしました。<br>
アーキテクチャの構成に関する事例や内部仕様、自分たちが気づいていなかった他機能との連携など、公式ドキュメントを見るだけでは得にくいような情報も得ることができ大変有意義でした。</p>
<p>ミーティング後には、<a href="/google-cloud-next-tokyo-19/">毎度恒例</a>のPLAIDオリジナルの漢字Tシャツをプレゼントし喜んでいただけました。（笑）</p>
<h2>まとめ</h2>
<p>KubeConに参加した中で、PLAID社員がどのような動きをしていたかについて紹介いたしました。<br>
セッションの内容自体はWebで公開されているものが多いですが、どのようなセッションが人気で何に対して盛り上がっているのかを体感したり、実際に開発者やユーザと交流したりできたため、多少コストは高め（フライト時間は往復で約1日..!）ですが、意味のある時間を過ごすことができたかと思います。機会があればまた参加したいと思います。</p>
<h2>最後に</h2>
<p>PLAIDではKubernetesなどのインフラの特性をフルに生かし、魅力的なプロダクトを作るエンジニアを募集しております。もし興味があれば、<a href="https://www.wantedly.com/projects/234957">こちら</a>からカジュアルに話を聞きに来てください！<br>
また、エンジニアだけではなく、KARTEの技術的・機能的サポートを行うプロダクトスペシャリストも募集しております。プロダクトスペシャリストに関しては、<a href="https://www.wantedly.com/projects/332135">こちら</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>


KubeCon in San Diegoに参加してきました！

KubeCon in San Diegoに参加してきました！ | PLAID engineer blog

Our seeking to stable k8s deployment.

<p><a href="https://qiita.com/advent-calendar/2019/plaid">PLAID Advent Calendar 2019</a> 3日目担当の <a href="https://twitter.com/algas">@algas</a> です。今年は量子コンピュータを個人的に勉強しています。最近では量子スプレマシーが話題になりましたね。会社の業務では量子コンピュータを直接使っているわけではないので今のところは完全に個人の趣味です。ソフトエンジニアとして生きていれば遠くない将来に業務で量子コンピュータを使うこともあると思っています。</p>
<h2>概要</h2>
<p>本記事では Google の論文 <a href="https://www.nature.com/articles/s41534-019-0141-3.pdf">“Universal Quantum Control through Deep Reinforcement Learning”</a> の中で使われている技術とそれが必要な背景を解説したいと思います。論文自体の内容に関する考察までは本記事では扱いません。論文の概要は <a href="https://ai.googleblog.com/2019/10/improving-quantum-computation-with.html">Google AI Blog &quot;Improving Quantum Computation with Classical Machine Learning&quot;</a> でも紹介されています。</p>
<h2>対象読者</h2>
<p>量子コンピュータや機械学習に多少の知見がある読者を対象とします。アドベントカレンダーのネタなのにそんなに軽くないです。それぞれの技術の専門家の方はぜひ元論文を読んでみてください。</p>
<h2>背景</h2>
<p>現状の量子コンピュータを使って実用的な問題を解くための主な課題として以下の3つがあります。</p>
<ol>
<li>量子ビット数が少ない<br>
量子ビットの数が多いほど高い精度の計算や多くのパターンの組み合わせの計算ができるようになります。</li>
<li>量子状態を維持できる時間が短い<br>
量子コンピュータで問題を解いている間は量子状態を維持する必要があります。<br>
量子状態を長い間維持できる方がより複雑な問題を解くことができます。</li>
<li>ノイズやエラーのために信頼性が高くない<br>
古典コンピュータではノイズの除去やエラー訂正が実用上で十分なレベルに達しています。<br>
それに比べて量子計算でのエラー訂正は簡単ではありません。量子状態を維持する時間が短いので大規模計算で訂正処理をするのが困難です。量子ビットを測定すると量子状態が壊れるので測定せずに訂正する方法が必要です。</li>
</ol>
<p>この3つ目の課題を解くのが紹介する論文の手法です。</p>
<h2>論文の解説</h2>
<h3>量子コンピュータのノイズ</h3>
<p>量子コンピュータのノイズには主に以下の２つがあります。</p>
<ol>
<li>量子ビット自体への干渉
<ul>
<li>量子コンピュータでは量子ビットに情報が保持されます。光子や音量子が量子ビットの近くを通ることによって量子力学的に干渉することがあります。</li>
<li>量子ビットの値を確定するためには「測定」する必要があります。測定の精度によって量子ビットの値が間違っていることがあります。</li>
</ul>
</li>
<li>量子ビットを制御する道具によるノイズ
<ul>
<li>量子ビットが載ってる物理基板の電気信号や電磁場によってアナログのノイズが混じってしまうことがあります。</li>
<li>熱によるホワイトノイズ以外にも、外部の電波源、DAコンバータなどもノイズの発生源になります。</li>
</ul>
</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ba139dd5-672d-4e91-956e-9a5ec344c666/57f6b41cba3d6eafb00633637f064550-png.png" alt="ノイズの図"></p>
<h3>論文の概要</h3>
<p>量子コンピュータのノイズ問題を解決するために「深層強化学習を使った新しい量子制御フレームワーク」を作りました、という内容の論文です。<br>
フレームワークの応用用途には以下があります。</p>
<ul>
<li>量子シミュレーション</li>
<li>量子化学</li>
<li>量子スプレマシー</li>
</ul>
<p>量子計算中の情報の漏れがノイズの主な原因の1つです。理論的には情報の漏れを完全に予測できればノイズを改善できます。量子コンピュータ全部をシミュレーションできればこれが実現できます。しかし現実的には量子コンピュータ全部をシミュレーションするのは計算効率の問題や大規模な計算においては難しいので完全には予測できません。その代わりに物理モデルを改良することで量子計算のいくつかのパラメータを最適化してノイズを減らすことができます。</p>
<h3>論文の結論</h3>
<p>既存の手法の確率勾配降下法(SGD)よりも桁違いで良い結果が得られたそうです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a9dac92a-2c98-4f71-afd0-e51469b438b2/fcf78285bc840c1f345fd76fdaf599b9-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 4)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 4)</p>
</blockquote>
<h3>On-Policy Trusted-region Deep Reinforcement Learning</h3>
<p>深層強化学習の図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13ee3c26-1495-4af7-8148-f4ff5f349d9e/571328050131bfec2920c9d5bb86e4e4-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 1)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 1)</p>
</blockquote>
<p>深層強化学習の技術については以下によくまとめられています。本記事と合わせてお読みください。<br>
<a href="https://qiita.com/shionhonda/items/ec05aade07b5bea78081">深層強化学習アルゴリズムまとめ</a></p>
<ul>
<li>深層学習(Deep Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df1bac60-9d83-4662-97f3-6d069eab6166/efc3e5c080b5b8fb30e96b5fbf22c1df-png.png" alt="DeepLearning"></li>
<li>強化学習(Reinforcement Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/436aea15-bd98-45ad-be1e-f77e2966da05/a487c561028d9bf9783570645d39d350-png.png" alt="a487c561028d9bf9783570645d39d350-png"></li>
<li>深層強化学習(Deep Reinforcement Learning)<br>
= 深層学習(Deep Learning) + 強化学習(Reinforcement Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cc5e3a4d-9001-4d76-aa8c-31a145ad6c9d/f09e4543ebfe850c4b2daa220cb1b97b-png.png" alt="f09e4543ebfe850c4b2daa220cb1b97b-png"></li>
</ul>
<blockquote>
<p><a href="http://people.csail.mit.edu/hongzi/content/publications/DeepRM-HotNets16.pdf">http://people.csail.mit.edu/hongzi/content/publications/DeepRM-HotNets16.pdf</a></p>
</blockquote>
<ul>
<li>Trust Region Policy Optimization<br>
論文: <a href="https://arxiv.org/pdf/1502.05477.pdf">https://arxiv.org/pdf/1502.05477.pdf</a><br>
解説記事: <a href="https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9">RL — Trust Region Policy Optimization (TRPO) Explained</a><br>
信頼できる領域内にステップを抑えることで状態の急激な悪化を防ぎます。急な勾配を崖に例えると、崖を飛び降りない手法といえます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/605a19c8-0032-4b80-ba8f-e8092362973b/----------2019-12-02-17.15.43.png" alt="崖から飛び降りない図"></li>
</ul>
<blockquote>
<p><a href="https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9">https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9</a></p>
</blockquote>
<ul>
<li>On-Policy<br>
解説記事: <a href="https://qiita.com/ABmushi/items/83a639506fcbc4050ce8">強化学習のOn-PolicyとOff-Policy</a><br>
現在の方策(Policy)に則って(on)将来の行動が選択されることを前提に学習します。崖の近くの道が選ばれにくくなります。On-Policy とは逆に方策に依存しない Off-Policy もあります。</li>
<li>Policy Neural Network<br>
解説記事: <a href="https://towardsdatascience.com/policy-networks-vs-value-networks-in-reinforcement-learning-da2776056ad2">Policy Networks vs Value Networks in Reinforcement Learning</a><br>
現在の方策(Policy)を改善するのが目的です。行動空間が高次元でも連続でも使えます。確率論的な方策も学習できます。局所解に陥りやすく評価が非効率的であるというデメリットもあります。</li>
<li>Value Neural Network<br>
最適行動価値(Value)関数を推定するのが目的です。局所解には陥りにくいアルゴリズムもあります。行動空間が高次元の場合には計算負荷が大きくなります。</li>
<li>確率勾配降下法(Stochastic Gradient Descent Method)<br>
解説記事: <a href="https://postd.cc/optimizing-gradient-descent/">勾配降下法の最適化アルゴリズムを概観する</a><br>
目的関数を最小化する問題を解く方法の1つです。局所解に陥りにくいメリットと最適解をいつまでも得られない可能性があるデメリットを持ちます。</li>
</ul>
<h3>Quantum Unitary Gate</h3>
<p>量子回路図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/352383d0-03df-4b28-8d76-a93872a44ae8/b0028cd46b91048d89f779df10bfcdb8-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 2)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 2)</p>
</blockquote>
<p>量子コンピュータに知見がない方は以下も合わせてお読みください。<br>
<a href="https://www.slideshare.net/techblogyahoo/ss-138380151">ゲート方式量子コンピュータの概要</a><br>
<a href="https://en.wikipedia.org/wiki/Quantum_logic_gate">Quantum logic gate</a></p>
<ul>
<li>量子ビット(qubit)<br>
古典ビットは0か1の2つの状態しかありません。量子ビットは測定した時に初めて値が確定し、その状態によって確率的に0か1のどちらかの値になります。複数回測定するとその出現確率の状態に近づきます。
<ul>
<li>古典ビットの「0」: 0が100%測定される状態<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/89e4b213-6b8e-4c21-b5a8-6f7d3459ff2c/ket0-2.png" alt="ket0"></li>
<li>古典ビットの「1」: 1が100%測定される状態<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a7885ef-f000-4459-8eb8-a8ed076fe6e5/ket1-2.png" alt="ket1"></li>
<li>一般的な量子1ビット<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/af71b94d-f1c5-4da3-ad69-0deefdf30da5/qubit1-2.png" alt="qubit1"></li>
<li>ブロッホ球:量子ビットの状態を仮想的に表した球<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e9594ab5-73d9-4f1d-9608-62543a689458/quantum_gates_bloch_sphere.png" alt="bloch-sphere"></li>
</ul>
</li>
<li>量子ゲート演算の基本
<ul>
<li>nビット量子ゲート演算<br>
2^n x 2^n の行列=ゲート( U )を 2^n 要素のベクトル = 量子nビットに作用させます。</li>
<li>1ビットの場合には以下の式で書けます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/35eab83e-6b2c-42f7-a79b-79edc54648f1/quantum1_u_gate.png" alt="quantum1_u_gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e7f633ef-3745-4a0e-99ac-7770757e24de/quantum1_u-1.png" alt="quantum1_u"></li>
</ul>
</li>
<li>1ビット量子ゲート
<ul>
<li>RYゲート: ブロッホ球のY軸の周りに位相をθだけ変化させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ddc4adf9-d2b9-42cb-bc16-755dbf9dc023/ry-gate-1.png" alt="ry-gate"></li>
<li>RZゲート: ブロッホ球のZ軸の周りに位相をθだけ変化させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c0bbdf6c-6650-41e0-8a10-4ad3fe7f45ce/rz-gate-1.png" alt="rz-gate"></li>
</ul>
</li>
<li>2ビット量子ゲート
<ul>
<li>CNOT(Controlled Not)ゲート: コントロールビット(下図の上側のビット)が1の時だけターゲットビット(下図の下側のビット)の値を反転させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/114d84fa-5c20-4ff6-b3dc-c5b02c4c6f27/cnot-gate-1.png" alt="cnot-gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/96cdff24-43c8-4f7e-bc5c-1d68d0cfea75/cnot-circuit.png" alt="cnot-circuit"></li>
<li>SWAPゲート: 2つのビットの値を交換します。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bbd5349e-a253-429b-af9f-5791bf45754d/swap-gate-1.png" alt="swap-gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ac550bb8-01b2-40be-a472-58deaf0a553f/swap-circuit.png" alt="swap-circuit"></li>
</ul>
</li>
<li>Quantum Unitary Gate
<ul>
<li>たとえば簡単のために α=π/4,γ=π/4 と仮定すると、U は以下のような演算になります。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aa05c59b-70fc-405f-86ec-409a6acf6333/ui-simple.png" alt="ui-simple"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7bfbc15b-d980-48c1-9e5a-d03e22ef0318/rz0.png" alt="rz0"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2e4ec040-3d83-4165-a3c9-3118cb82094c/rz1.png" alt="rz1"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/14929f10-dc99-47ee-b8d9-02e7048c96ea/ui-result.png" alt="ui-result"><br>
SWAPゲートと一緒になります。ちょっと簡単にしすぎました。</li>
<li>論文による測定結果<br>
α を横軸にして γ=π/2,π/6,π/3 の場合の単位時間あたりのゲート実行時間を縦軸にした図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f72780d3-32fd-4f72-bd30-0bebabd94ce8/5dacd6723662c60dec0d909e5a2f9c6a-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Figure 3)"></li>
</ul>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Figure 3)</p>
</blockquote>
</li>
</ul>
<h2>本記事のまとめ</h2>
<p>量子コンピュータの直近の主な課題の1つであるノイズ問題を改善する手法を提案する論文の背景と論文内に登場する技術を紹介しました。背景の状況や要素技術が理解できると論文の内容にも興味を持てるのではないでしょうか。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://www.nature.com/articles/s41534-019-0141-3.pdf">“Universal Quantum Control through Deep Reinforcement Learning”</a></li>
<li><a href="https://ai.googleblog.com/2019/10/improving-quantum-computation-with.html">&quot;Improving Quantum Computation with Classical Machine Learning&quot;</a></li>
<li><a href="https://www.shoeisha.co.jp/book/detail/9784798159928">現場で使える! Python深層強化学習入門 強化学習と深層学習による探索と制御</a></li>
<li><a href="https://book.mynavi.jp/ec/products/detail/id=90706">つくりながら学ぶ! 深層強化学習 PyTorchによる実践プログラミング</a></li>
<li><a href="https://www.shoeisha.co.jp/book/detail/9784798157467">絵で見てわかる量子コンピュータの仕組み</a></li>
</ul>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<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>


PLAID Advent Calendar 2019 3日目 論文 “Universal Quantum Control through Deep Reinforcement Learning” の背景と要素技術の解説

深層強化学習は量子猫の夢を見るか？ | PLAID engineer blog

深層強化学習は量子猫の夢を見るか？

<p>@otolab です。</p>
<p>ITP 2.2, 2.3に関する調査を行いましたので、検証ツールの解説を行いたいと思います。</p>
<p>今回の検証では、ITP 2.2のリンク装飾（Link Decoration）されたランディングページによるcookieの保存期間短縮と、ITP 2.3で追加されたリファラへのリンク装飾に対する制限について調べています。</p>
<p>2つとも、広告流入時にIDを1st partyとして保存するようなケースを想定しており、流入元から対象サイトへの情報伝達・保存を制限するものです。</p>
<p>なお、localStorageに制限が掛かったことが2.3での変更の大きなポイントですが、制限の元となる条件は2.2のcookieと同様であるのと、localStorageの寿命を簡単に見る方法がないため今回はテストを行っていません。</p>
<p>この記事はITPについての基本的な知識がある前提で書いています。</p>
<h2>意外だったこと</h2>
<ol>
<li>リンク装飾に対する制約は2PV目以降にも引き継がれる</li>
<li>trackerドメイン上でのインタラクションによる猶予の影響は受けない</li>
<li>レスポンスヘッダによる遷移はリンク装飾とみなされない（？）</li>
</ol>
<p>詳細は後述します。</p>
<h2>ツール</h2>
<p>実験しつつ書きつつだったので、コードやテスト内容は結構場当たり的ですが……。手元では再現性のあるテストを実行できるようになったので、公開します。</p>
<ul>
<li><a href="https://github.com/otolab/itp2.3-test">検証ツール</a></li>
</ul>
<p>また、cookieの寿命(expire)をJavascriptから取得する手段がないので、適宜、Webインスペクタを開いてcookieの有効期限を確認してください。</p>
<p>mochaを使っていますが、上記の理由からタスクランナーとしてのみ使っている状態です。</p>
<h2>検証内容</h2>
<p>検証に使ったのはSafari 13.0.1と、Safari Technology Preview Release 93です。</p>
<p>テストはコンソール(<code>localhost</code>), SiteA(対象サイト、<code>1stparty.localdomain</code>), SiteB(トラッカードメイン、<code>3rdpartytestwebkit.org</code>)の3つのホストにまたがって実行します。</p>
<p>コンソールはテスト実行の起点になるページで、遷移の関係をシンプルにするために導入しました。このページからのpopupはブロックしないように設定しておいてください。</p>
<p>SiteBはSafariがテスト用に最初からトラッカードメインとして判定しているドメインです。このドメインから対象サイトへの遷移が今回の検証のテーマになります。</p>
<p><code>3rdpartytestwebkit.org</code>, <code>1stparty.localdomain</code>は/etc/hostsなどにあらかじめ127.0.0.1として登録しておいてください。ローカルホストの別名として登録された状態になります。</p>
<p>テストは条件を変えてSiteB =&gt; SiteAの遷移を繰り返しながら、cookieを設定していきます。</p>
<h3>検証手順</h3>
<ol>
<li>初期設定
<ol>
<li>SiteA, page1にアクセスして、Cookieを設定(key1, key2)</li>
</ol>
</li>
<li>リンク装飾付き遷移
<ol>
<li>SiteB, page1にアクセス<br>
metaタグによってSiteA, page2に装飾付きで遷移</li>
<li>SiteA, page2でCookieを設定(key3, key2)<br>
手動でリンクをクリックしてSiteA, page3に装飾なしで遷移</li>
<li>SiteA, page3でCookieを設定(key4, key1)</li>
</ol>
</li>
<li>リンク装飾なし、referrer装飾あり遷移
<ol>
<li>SiteB, page2にアクセス<br>
metaタグによってSiteB, page3に装飾付きで遷移</li>
<li>SiteB, page3にアクセス<br>
metaタグによってSiteA, page4に装飾なしで遷移</li>
<li>SiteA, page3でCookieを設定(key5)</li>
</ol>
</li>
<li>リンク装飾あり手動遷移
<ol>
<li>SiteB, page4にアクセス<br>
手動でリンクをクリックしてSiteA, page5に装飾付きで遷移</li>
<li>SiteA, page5でCookieを設定(key6)</li>
</ol>
</li>
</ol>
<p>Cookieはいずれも8日間で設定します。</p>
<h2>検証結果</h2>
<h3>1. 初期設定</h3>
<p>1-1でCookie(key1, key2)を保存します。</p>
<p>document.cookieにjavascriptで値を保存しているので、8日間の有効期限を設けても7日間にまで制限されます。これはITP 2.1の効果ですね。</p>
<h3>2. リンク装飾付き遷移</h3>
<p>リンク装飾されたランディングページによる制限のテスト(2-2)。および2PV目での制限の継続をチェックするテスト(2-3)です。</p>
<p>2-2では新規のkey3の寿命が1dayまで短くなることが確認できます。また、1-1で設定したkey2を上書きすると同様に寿命が縮むのが確認できます。</p>
<p>ついでにリファラの短縮が起こらないことも確認しています。ここではSiteB, page1にリンク装飾がないため、このリファラ短縮の処理は起きていません。</p>
<p>2-3のテストを見てみましょう。ここで明文化されていない現象が観測できます。SiteA, page3はランディングページではなく、SiteA内で手動でリンクを踏んだ場合の遷移です。にもかかわらず、key4, key1の寿命は1dayに制限されます。</p>
<p>「意外だったことその1」です。</p>
<p>2PV目以降で再保存することで寿命が伸ばせてしまうと効果がない。ということなのでしょう。</p>
<h3>3. リンク装飾なし、referrer装飾あり遷移</h3>
<p>ITP 2.3で追加されたリファラの短縮とリンク装飾の関係を調べます。</p>
<p>3-1, 3-2の遷移でSiteB, page3にリンク装飾を付け、そのままSiteA, page4にリンク装飾なしでランディングします。</p>
<p>すると、リファラの短縮が観測できます。また、Cookie(key5)の寿命が縮まないことも確認できました。2つは別のものとして扱われているようです。</p>
<p>また、詳細は不明なのですが、もう一度同じテストを流すとリファラの短縮が発生しないことがあります。毎回cacheを消すとリファラ短縮が安定して発生しするのですが……。バグなのか正しい挙動なのかは不明です。</p>
<h3>4. リンク装飾あり手動遷移</h3>
<p>トラッカードメイン上でのユーザインタラクションによってCookieの寿命を延長する処理があるので影響を調べましたが、リンクデコレーションの処理とは連携していないようです。</p>
<p>4-1でSiteB上でリンクをクリックした際に、ログを見るとインタラクションを検出したというログは出るようなのですが、4-2でCookieを保存すると1dayの制限がかかります。</p>
<p>今回はSiteB上でのインタラクションは影響してこないようです。広告のクリックの追跡を想定した制限のようなので、そういうものなのかもしれません。</p>
<p>「意外だったことその2」です。</p>
<h3>extra. レスポンスヘッダによるページ遷移</h3>
<p>「意外だったことその3」です。</p>
<p>テストツールのindex.jsの<a href="https://github.com/otolab/itp2.3-test/blob/e4cc3994a7e4fa74b2c40f5b8b3f5a1596e8b8e3/index.js#L16-L33">16-33行のコメントアウト</a>を外します。そうすると、SiteBでのページ遷移がmetaタグではなく、レスポンスヘッダによるリダイレクトに置き換わります。</p>
<p>この状態でテストすると、じつはリンク装飾によるCookieの寿命短縮が発生しません。テスト方法が悪いのかブラウザのバグなのかはちょっとわからないのですが……。</p>
<p>どうも、現在のページのURLとリファラのURLの比較のみでリンク装飾の制約を掛けているのではないかなと言う印象を持ちました。レスポンスヘッダによる遷移だと、referrerの値がもう一つ前のページになるんですよね。今回のテストケースだとコンソール(<code>localhost</code>)がリファラになります。</p>
<h2>まとめと感想</h2>
<p>ページ遷移の状態やキャッシュの影響を受けるらしく、挙動がなかなか安定しないため苦労しました……。</p>
<p>さて。</p>
<p>ITP 2.2, 2.3は、ランディングページにクエリ・フラグメントがつくケースすべてを対象としているために、「サイトの作り方」自体を制約して方向づけるような仕様変更であると言えます。たとえば、商品詳細ページに<code>?item=abc123</code>のようにクエリをつけて表現するサイトは、トラッカードメインとみなされたサイト上からのアクセスで、常時cookieやlocalStorageの保存に不安定さを抱えることになります。</p>
<p>今回の変更で不安定化するフェアユースの例としては、ログイン無しでのお気に入り機能などですね。実装方法を変えれば安定化は可能なので、Safariでの動作が必須ならばサイト自体に修正をいれることになるでしょう。</p>
<p>今後も機能の更新が想定されますので、注目していきたいと思います。</p>
<h2>参考</h2>
<ul>
<li><a href="https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/">Intelligent Tracking Prevention 2.2</a></li>
<li><a href="https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/">Intelligent Tracking Prevention 2.3</a></li>
</ul>
<h2>いつもの</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、顧客体験をよりよくするとはどういうことなのか、Webの未来はどう在るべきか、深く考えたいというエンジニア（インターンも）を募集しています。</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>


ITP 2.2のリンク装飾に関する制限と、ITP 2.3のリファラへのリンク装飾に対する制限について検証を行いました。検証のためのツールを作ったので解説します


ITP 2.2, 2.3の検証ツールを作ってみた | PLAID engineer blog

ITP 2.2, 2.3の検証ツールを作ってみた

Vue.js の設計地図を作成しました。設計概念の依存関係の図式化して理解し、
フロントエンド設計をモデリング起点で考えたブログです。

Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜

<p>こんにちは、makinoy &amp; positiveflat &amp; tik-son &amp; nichimuです。<br>
7/30-8/1にかけて開催された Google Cloud Next Tokyo ’19に参加してきたので、その様子をご紹介したいと思います。紹介と言いつつも、Cloud Nextでのセッションの内容のシェアではなく、Cloud Next開催中にPLAID社員がどのような動きをしていたかについてシェアしたいと思います。</p>
<h2>Google PM陣とのミーティング ＠PLAIDオフイス</h2>
<p>PLAIDでは<a href="https://cloud.google.com/bigtable/?hl=ja">Cloud BigTable</a>を始め、NoSQLのデータベースを多く使っているということもあり、<a href="https://cloud.google.com/bigtable/?hl=ja">Cloud BigTable</a>、<a href="https://cloud.google.com/memorystore/?hl=ja">Memorystore</a>など、NoSQLサービスのProduct Managerの方々をPLAIDオフィスに招き、ディスカッションを行いました。<br>
このディスカッションはGoogle Cloud Next Tokyo ’19 開催前日に実施し、</p>
<ul>
<li>PLAIDでどのようにこれらのNoSQLを使っているのか/使い分けているのか</li>
<li>既存のGCPのサービスに求めることは何なのか</li>
<li>サービスの特性をより活かしたアーキテクチャとは</li>
</ul>
<p>などのテーマについて議論を行いました。<br>
限られた時間だったので議論は尽きず、続きはビデオ会議などを駆使しリモートでやっていく予定です。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/2841f03f-6dbb-4631-9f54-b59066eda7f0/google-cloud-next-tokyo-19.jpeg" alt="google-cloud-next-tokyo-19.jpeg"><br>
Cloud BigTable、Memorystoreなど、NoSQLサービスのProduct Managerの方々との写真</p>
<h2>Meet the Expert ＠Google Cloud Next Tokyo’19</h2>
<p>Google Cloud Next Tokyo ’19が開催されている最中も、Googleの開発者とのミーティングを行なっていました。<a href="https://cloud.google.com/bigquery/?hl=ja">BigQuery</a>、<a href="https://www.kubeflow.org/">Kubeflow</a>、<a href="https://cloud.google.com/dataflow/?hl=ja">Cloud Dataflow</a>の開発者との議論を行いました。</p>
<p>実は5月に開催された<a href="/google-cloud-next-19-in-sf/">Google Cloud Next San Francisco ’19</a>の際にも、既に我々はKARTEのアーキテクチャについてGoogleの開発者と共有した上で議論をしていました。そのため、特にBigQueryなどに関しては、それを念頭に置いた上で今後の開発に役立ちそうなトピックを中心に議論をすることができました。<br>
また、機械学習基盤についてもディスカッションを行うことができました。現在、PLAIDでは、エンドユーザーのデータを大量に保持していますが、十分に活用できているとはまだまだ言えない状況です。機械学習などの技術をKARTEにも取り入れはじめている段階で、どういったデータの流れをどう作るべきなのか、データのvalidationをどうするべきか、ということなどをKubeflowの開発者に伺えたことは非常に良かったです。短い時間ではありましたが、プロジェクトの初期の段階で開発者とディスカッションできたことは、設計に取り組む上で大きなアドバンテージとなりそうです。</p>
<p>ミーティング後には、PLAIDオリジナルの漢字Tシャツをプレゼントしました！２種類あり、「hotfix: 迅速」「analytics: 解析」が書かれています。PLAIDデザイナーが心を込めて作った甲斐もあり、喜んでいただけました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_495C088E061F4CCFCB2EDF25134394B291C83E750D9DE3EC3C286EBBF71A4BB4_1565080407452_iOS+.jpg" alt="BigQuery、Kubeflow、Cloud Dataflowの開発者との写真" title="BigQuery、Kubeflow、Cloud Dataflowの開発者との写真"><br>
BigQuery、Kubeflow、Cloud Dataflowの開発者との写真</p>
<h2>Google Cloud Billing teamとのミーティング ＠PLAIDオフイス</h2>
<p>また、Google Cloud Next Tokyo ’19 開催後にGoogle Cloud Billing Teamとミーティングを行いました。<br>
組織が大きくなる中どのようにコストを管理していくべきなのか、GCPの考え方をシェアしてもらいつつ、PLAIDの現状をお伝えし、あるべき姿についてディスカッションしました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_495C088E061F4CCFCB2EDF25134394B291C83E750D9DE3EC3C286EBBF71A4BB4_1565080391497_W8051119.jpg" alt="Google Cloud Billing Teamの皆さんとの写真" title="Google Cloud Billing Teamの皆さんとの写真"><br>
Google Cloud Billing Teamの皆さんとの写真</p>
<h2>CTO 牧野とエンジニア 竹村の登壇 ＠Google Cloud Next Tokyo’19</h2>
<p>Cloud Nextのセッションでは、エンジニアサイドからは2人登壇しました。</p>
<p>CTOの牧野からは、「秒間6万イベントの大規模リアルタイムデータを活用する機械学習基盤の実現」を発表いたしました。GCPには、<a href="https://cloud.google.com/bigquery-ml/docs/bigqueryml-intro?hl=ja">BigQuery ML</a>、<a href="https://cloud.google.com/automl-tables/?hl=ja">AutoML Tables</a>、<a href="https://cloud.google.com/ai-platform/?hl=ja">AI Platform</a>などの機械学習サービスがありますが、それらのサービスをどのように活用しているかについて発表いたしました。</p>
<p>詳細につきましては、プレスリリースをご確認ください。<br>
<a href="https://press.plaid.co.jp/data/20190801/">https://press.plaid.co.jp/data/20190801/</a></p>
<p><img src="https://paper-attachments.dropbox.com/s_B4301733157BC4E8942C126B98488C9A0747D29A0340FB43A199BCCC760D822F_1566799637362_IMG_20190801_144105.jpg" alt="PLAIDの牧野祐己" title="PLAIDの牧野祐己"><br>
PLAIDの牧野祐己</p>
<p>また、竹村からは「PLAIDがGCPを使い、続ける理由」というテーマで発表しました。<br>
GCPのTokyoRegionが出来る前から使い始め、現在も数あるクラウドサービスの中で何故ヘビーに利用し続けているのかというお話をいたしました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_495C088E061F4CCFCB2EDF25134394B291C83E750D9DE3EC3C286EBBF71A4BB4_1565181257794_IMG_20190731_192125.jpg" alt="PLAIDの竹村尚彦" title="PLAIDの竹村尚彦"><br>
PLAIDの竹村尚彦</p>
<h2>BizDev 宮原とプロダクトスペシャリスト 池上の登壇 ＠Google Cloud Next Tokyo’19</h2>
<p>また、ビジネスサイドからはPLAIDで事業開発からプロダクトマネジメント、アライアンスを担当する<a href="https://speakerdeck.com/miyashino">宮原</a>と開発から採用、技術広報を担当するプロダクトスペシャリストの池上が登壇しました。</p>
<p>「GCP をフル活用した<a href="https://karte.io/product/datahub/">「KARTE Datahub</a>」で挑む次世代のデータ活用」というテーマで、PLAIDのストラテジックパートナーである<a href="https://www.nri-digital.jp/">NRIデジタル</a>様との取り組みである、リアル接点を活用した次世代のデータ活用事例「リアル・デジタルマーケティング」を発表しました。</p>
<p>詳細につきましては、プレスリリースをご確認ください。<br>
<a href="https://press.plaid.co.jp/data/20190731/">https://press.plaid.co.jp/data/20190731/</a></p>
<p><img src="https://paper-attachments.dropbox.com/s_4728A931DD51A7808A452108583713580BBAA209584910654C1CC5512171042D_1565733233501_image.png" alt="PLAIDの宮原忍" title="PLAIDの宮原忍"><br>
PLAIDの宮原忍</p>
<p><img src="https://paper-attachments.dropbox.com/s_4728A931DD51A7808A452108583713580BBAA209584910654C1CC5512171042D_1565733287627_image.png" alt="NRIデジタルの倉澤様" title="NRIデジタルの倉澤様"><br>
NRIデジタルの倉澤様</p>
<p><img src="https://paper-attachments.dropbox.com/s_4728A931DD51A7808A452108583713580BBAA209584910654C1CC5512171042D_1565733408737_image.png" alt="パネルディスカッションの様子（NRIデジタルの萩村様、PLAIDの池上純平）" title="パネルディスカッションの様子（NRIデジタルの萩村様、PLAIDの池上純平）"><br>
パネルディスカッションの様子（NRIデジタルの萩村様、PLAIDの池上純平）</p>
<h2>PLAIDのブースについて</h2>
<p>会場では、様々なパートナー・スポンサー企業によるブース展示が行われていました。弊社PLAIDも、ブースで来場者の方に向けてKARTEの紹介をさせていただきました。開催期間を通して、多くの来場者がKARTEに興味を持ってブースに立ち寄っていただきました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566797495978_76ZdkLYET8yF0DYRIH05ig_thumb_2.jpg" alt="PLAIDブースの様子" title="PLAIDブースの様子"><br>
PLAIDブースの様子</p>
<p>今回も様々な種類のノベルティを用意して臨みました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566660933793_image.png" alt="Google Cloud x KARTEマウンテンボトル" title="Google Cloud x KARTEマウンテンボトル"><br>
Google Cloud x KARTEマウンテンボトル</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566660950286_image.png" alt="Google Cloud x KARTEノート" title="Google Cloud x KARTEノート"><br>
Google Cloud x KARTEノート</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566661102642_image.png" alt="Google Cloud x KARTEコンパクト充電器" title="Google Cloud x KARTEコンパクト充電器"><br>
Google Cloud x KARTEコンパクト充電器</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566660965124_image.png" alt="ハンドスピナー型 USB &amp; Lightningケーブル！" title="ハンドスピナー型 USB &amp; Lightningケーブル！"><br>
ハンドスピナー型 USB &amp; Lightningケーブル！</p>
<h2>まとめ</h2>
<p>Google Cloud Next Tokyo ’19に参加した中で、PLAID社員がどのような動きをしていたかについて紹介いたしました。今後も、Googleと密に連携を取りながら、KARTEとGCPの価値を高めていきます。</p>
<h2>最後に</h2>
<p>PLAIDではGCPなどのインフラの特性をフルに生かし、魅力的なプロダクトを作るエンジニアを募集しております。もし興味があれば、<a href="https://www.wantedly.com/projects/234957">こちら</a>からカジュアルに話を聞きに来てください！<br>
また、エンジニアだけではなく、KARTEの技術的・機能的サポートを行うプロダクトスペシャリストも募集しております。プロダクトスペシャリストに関しては、<a href="https://www.wantedly.com/projects/332135">こちら</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>


Google Cloud Next Tokyo ’19に参加してきた中で、PLAIDエンジニアがどのような動きをしていたかについてご紹介いたします！

Google Cloud Next Tokyo ’19に参加しました！ | PLAID engineer blog

Google Cloud Next Tokyo ’19に参加しました！

<p>（このブログ記事は、<a href="https://l.facebook.com/l.php?u=https%3A%2F%2Fmedium.com%2F%40aavondet%2Finterning-at-plaid-for-2-5-months-fc2d8c6a3a17%3Ffbclid%3DIwAR39SIv4MHPB4gyO1HOQvGwuXOJvLgO7bZjK-Wlgg4-XBYIrNe83owfROIs&amp;h=AT0dg2wvphvSMKOhzD03eL6-R97JyjOepJ7X8Gs43x4GyFx7EsBXRkepVPa58f-XjSTRVdiVFu-B9am-yQJzRGjyMNSaHNQ0co4kjJty2OfSq8zUfotoeCIbJ-Q0vIp5BNJ-fW3T">Interning at PLAID for 2.5 Months</a>の本人による翻訳記事です）</p>
<p>こんにちは！<br>
プレイドで5月中旬から8月までDevインターンとして働かせてもらっていたアボンデット(@arnaud_avondet)です。僕は日本育ちのハーフで、今は米国ペンシルベニア州のカーネギーメロン大学で数学を専攻している大学2年生です。大学ではCMU日本学生会や、CMUブロックチェーングループで活動をしています。プログラミングは2年前に興味を持ってPythonの学習で始め、ウェブ開発は一年ぐらいの経験を持っています。</p>
<p>今回のインターンシップはプログラマーとして初めての仕事であり、フロントを書いたり多国化対応（i18n; Internationalization）の仕事を通して色々学べました。今回は開発プロセスとプレイドの文化について振り返ってみました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3e81e6b5-f5fa-4d53-878b-8d8dccd47c77/pic1.jpeg" alt="pic1"></p>
<h1>フロントエンド</h1>
<p>JSのコードを書いて来たこの一年間、僕は色々なアニメーションのライブラリに触れたり、UI/UXの記事などを読んでフロントエンドに興味を持ちました。プレイドに来て二週間目、早速フロントエンド関連のチームのタスクをもらい、初めてのフレームワークを習う事になりました。プレイドが提供しているCXプラットフォームKARTEはVueを使っているので、それを通してコンポーネント式のフロントエンドの書き方を勉強しました。</p>
<p>僕にとってKARTEのような大きなプログラムの開発プロセスに関わるのは新しい経験でした。普段であればHTMLを早く書いて、長時間かけて下手なCSSでスタイリングをし、最後にロジックを書くという作業を毎回繰り返していました。全部に触れられる事が楽しいのは確かですが、一つ一つの段階で全力を尽くせていない感じがしました。会社での開発は一味違い、綺麗なUIをInVisionで作るデザイナー、HTMLでそれを実装するコーダー、それでロジックをJSで書く僕、とそれぞれの仕事を得意な人が担当するようになっていました。一人一人が独自のタスクに集中出来るため、より良いプロダクトが出来上がりました。その上、プレイドではタスクにより違う役割を任せてくれるので色々な得意分野を生かせるようになっていました。自分でコードする時よりも効率的な仕事が出来た気分になり、気持ち良かったです。</p>
<p>画面の組み込み作業をやっていく上で、一番重要性を感じたのがデザイナーとプログラマー関係性です。特にフロントだけを書き換えるタスクでは既存のバックエンドの資産をそのまま活用しつつ、機能の互換性や網羅性を担保するためにはコミュニケーションをうまくとる事が大切です。デザイナーとプログラマーの観点をよく活用し、直面している制限を乗り越えられる解決案を生み出すのが何よりも貴重だと思いました。<br>
アサインされた仕事の一つは、アカウント設定ページの組み込みでした。最初はどのユーザーでも何回かは使う画面を自分が担当する事に対してとても緊張していましたが、エンドユーザーと直に接する楽しみもありました。コードの動作チェックをする時、様々なユーザーの行動を予測して作業をしていくと色々な行動パターンに気づき、新しい案などが思い付いてきました。この画面の開発はやった仕事の中でも一番楽しく、ユーザーがそのページと接する事を考えると嬉しいです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6265ca5a-3602-4872-9038-908137c49136/pic2.jpeg" alt="pic2"></p>
<h1>多国化対応（i18n）</h1>
<p>インターンを始めて3週間目に会社内で2週間に一度行われる「Dev Demo Day」に参加しました。「Dev Demo Day」とは各エンジニアチームがここ二週間でやった仕事のデモをしたりその開発に対して振り返る場でした。僕がそれぞれのチームの発表を見て一番興味を持ったチームは、多国化対応を担当するi18nチームでした。18年間日本で育ったハーフとして、僕は日本と西洋の文化や言語によく触れていて、お互いの違いや類似点を深く理解しています。これなら自分も何かを貢献できると思い、チームに入りたいと決意しました。</p>
<p>当初は多国化対応の難しさを知らず、ただ小さなリファクタリングを掛けたり、多言語のリソースファイルを用意するだけだと思っていました。プラグインはvue-i18nを使い、簡単に通貨のフォーマットや言語を変換出来るようになっていました。そのライブラリを作った@kazuponさんも同じチームで一緒に作業をしていて、多国化対応のどんなチャレンジも乗り越えられる自信がありました。ですが、チームに入ってから数日後、早くも先の道のりが思ったより長く見えてきました。</p>
<p>i18nをやってきた上で一番印象に残ったのが、特定の言語や文化のUIへの影響でした。チームとしてよく見かけたのが日本人のユーザーを意識して作られていた画面で多国化対応には難しいものがたくさんありました。その中でも一番困難だったのが日本語の文の構造を中心としたデザインであり、そういう場合には簡単なリファクタリングだけでは綺麗に対応出来ず、デザイン自体を再検討する必要がありました。</p>
<p>このようなチャレンジと向き合い始め、僕は色々なグローバルなウェブサイトはどうやって効率的に多国化対応をしているか気になって調べた結果、一つの会社が僕にとって際立っていました。Githubは世界中で使われているサイトでもありますが、驚いた事に言語のサポートは英語しかないのです。UIをより顕密に見るとラベルのほとんどがユーザー側でインプットされたものが表示されていて、そのためユーザーのネイティブ言語になっています。その他の細かいタブなどは「issue」や「pull request」のように短くて簡単に覚えられる単語を使用しているため、英語が流暢でなくても慣れやすくなっています。Githubのコア部分には英語の長くて難しい文章がないため、誰でも使えるようになっています。</p>
<p>Githubを例とし、i18nの作業でできるだけユニヴァーサルな表記法を使うようにしました。例えば「9時30分」とUIに書いてあるものを「9:30」にしたり、どこの国の人でも理解できるように気を使いました。今だとこういう細かい修正は小さく感じますが、将来的にグローバル化したいソフトウェアとしては長い目で見ると今から標準的に対応する必要があります。</p>
<p>多国化対応をソフトウェアエンジニアリングの観点から考えたことがなかったですが、プレイドのi18nチームと共に活動をした結果、グローバル化する企業にとってはとても重要な要因であることに気付きました。国際化はラベルを一旦全部翻訳して一度きりで終わるものではなく、開発フローを修正したり、品質チェックを導入し管理する動的なプロセスだと分かりました。KARTEのi18nで直面した様々な困難を考えるとさらに大きいソフトウェアの多国化対応の難しさが想像できないです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/100bb83d-e75c-48e5-bf6c-a3b55afad2b5/pic3.jpeg" alt="pic3"></p>
<h1>プレイドの文化</h1>
<p>この2ヶ月半で一番印象に残ったのがプレイドのカルチャーでした。インターンとして僕は小さいissueや面倒なデバッグをすると想像していました。実際には2週間目にはもう新しい画面の組み込みタスクを渡され、3週間目には正社員と一緒のエンジニアチームに入れさせてもらいました。色々なミーティングに参加したり、他の社員と協力したりと没入的な経験が得られました。</p>
<p>プレイドがインターンにとって最高な会社である一番の理由としては会社のフラットな構造がある事だと思いました。僕は他のエンジニアと一緒のように扱われ、自分の意見や提案を悩まずに言える環境で仕事ができました。入社した当時、フロントへの興味を少し表しただけですぐに画面の組み込み作業をくれました。僕が助けられるi18n関連のタスクがあるか聞いてみたらチームに加入させてもらい、席もチームの横で作業出来るように動かしてもらいました。フロントとi18nに手をつけ始め、画面の組み込みと一緒に多国化対応もしていく提案をしたらそれも受け止めてくれて、二つのチームと一緒に同時に作業を進められるようにしてくれました。</p>
<p>時にはこのフラットな構造の問題点にも気づきました。場合によってはチーム同士のコミュケーションが良くとれていなく、具体的に他のチームがソフトウェアのどこの部分の作業をしているのかがはっきりしていなかったです。i18nチームとしては近い将来に使われないコードを対応しないように新しく作られる画面や機能などについて知っておきたいところですが、それでも時々もったいない仕事をしてしまいました。このようなコミュニケーションのずれを防ぐためにプレイドのエンジニア部門も2週間に一回は最近やっている仕事について発表する「Dev Demo Day」があります。それでも、これは任意であり、発表をしても5分間のデモだけで重要な点を見逃してしまう事がよくありました。このミーティングはきちんとした構造がないため、ポテンシャルを最大限に発揮できていない感じはしましたが、コミュニケーションを良くする一歩としてはとてもいいと思いました。長所や短所関係なく、僕はプレイドのような日本にとってはユニークに動いている会社の一部として働けた事に感謝しています。</p>
<p>ベンチャー企業であるため、プレイドの開発速度はとても速かったです。週ごとにリリースされる新しい機能の数が見事で、自分の書いたコードが短時間で使われる事に満足ができ、終わった仕事に対しての価値観が強く感じられるのが好きでした。僕はすぐにこのペースに慣れて、いつの間にか好きになってしまいました。特にいつもやる事がたくさんあったため、自分でも次にやるタスクが簡単に見つけられ、退屈であった一日はなかったです。タスクを選択する事で自分の能力にあった仕事、もしくは一番良いチャレンジになる仕事を選ぶ事ができました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/31d10c97-c2c4-4fd2-abe1-61ffaa63c4ba/pic4.jpeg" alt="pic4"></p>
<h1>最後に</h1>
<p>当初インターンを始めた時、2ヶ月半は長い期間だと考えていましたが働くほどすぐに時間がたってしまいました。自分を「プログラマー」と呼ぶことができるかどうかわからない状態から、どこのエンジニアチームでも自分の能力を発揮できる自信を持てるようになりました。インターンシップならではの経験を得ながら、会社のために何かを貢献できて嬉しいです。短い時間であっても、プレイドでのインターンシップは僕にとって素晴らしい経験であり、これからの会社の進歩を見るのがとても楽しみです！</p>


こんにちは！プレイドで5月中旬から8月までDevインターンとして働かせてもらっていたアボンデット(@arnaud_avondet)です。今回のインターンシップはプログラマーとして初めての仕事であり、フロントを書いたり多国化対応(i18n)の仕事を通して色々学べました。今回は開発プロセスとプレイドの文化について振り返ってみました。

プレイドでのインターンを振り返って | PLAID engineer blog

プレイドでのインターンを振り返って

<p>最近またpokemon goをやり始めた kataigi です。</p>
<p>プレイドで開発しているKARTEはユーザーのアクセス情報を分析するサービスの一種です。KARTE以外にも、Google AnalyticsやAdobe SiteCatalystなどユーザーのアクセス情報を分析するサービスは多くあり、使ったことある人も多いでしょう。ただ、そんなサービスでもどんな方法でデータを取得・トラッキングしているか知らないと、データの正しい意味がわからず、使いこなすことは難しいかと思います。ここではそんな分析の前提となるデータのトラッキングの方法をざっくりまとめてみました。</p>
<p>トラッキングの方法には様々な種類があります。どんな状況でも正確にデータが取れる方法というのはないため、それぞれの方法の特徴を知った上で、環境とデータに合わせて使い分けるのが大事です。今回は、ページやコンテンツの表示回数を測るインプレッショントラッキングと、クリック回数を測るトラッキングについて詳しくみてみたいと思います。</p>
<h1>インプレッショントラッキング</h1>
<p>一つ目は表示回数のトラッキングです。ページが表示される時はページビューですが、例えば商品レコメンドなどでは、同じページでも表示される商品情報が変わるなど、ページ閲覧回数とコンテンツ表示回数は異なってくるため、コンテンツの表示回数も計測したい場合は、より一般的にインプレッション（露出回数）という用語が使われます。トラッキング技術としてはページビューはインプレッションに含まれるので、ここでは合わせてインプレッショントラッキングとします。</p>
<p>基本的にはページ/コンテンツが表示された回数を測ることになります。コンテンツが自分の管理下にあるか、計測タイミングがコンテンツ表示前か後か、というあたりで使う技術が変わってきます。</p>
<h2>アクセスログ</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e665a42d-9f4a-413f-a96b-57b0556d838a/image1.png" alt="image1"></p>
<p>一番シンプルな方法は、サーバ自体のアクセスログを使う方法です。コンテンツを表示する時のブラウザからのアクセスをサーバ上でログに残しておく方式になります。原理的に、コンテンツ配信サーバ自体を自社で管理していないと計測できません。</p>
<h3>メリット</h3>
<p>概ねどのサーバでもアクセスログは出力されるため、準備不要で計測でき、最も手軽。</p>
<h3>デメリット</h3>
<p>アクセスログを計測するため、自社管理対象のサーバしかカウントできない。<br>
アクセスがあった ≠ 表示されたではない（ブラウザで描画される前に離脱してるかも）ので、計測値は真の値より多くなる。</p>
<h2>ピクセル（ビーコン）</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c5b88637-a42c-45e5-a16c-e88980ba3ff4/image2.png" alt="image2"></p>
<p>２つ目はピクセルトラッキングとかビーコントラッキングと呼ばれる方法です。この方法は、ページやコンテンツと一緒に極小の画像（ピクセル）を読み込ませ、その画像へのアクセスを計測する方法になります。読み込ませる画像は自社のサーバ外に置いても良いため、多くのアクセス解析システムで用いられている方法です。</p>
<h3>メリット</h3>
<p>自社管理外のサーバでもカウント可能。<br>
HTMLメールなど、配信されるコンテンツでも計測可能。</p>
<h3>デメリット</h3>
<p>コンテンツが表示されても即離脱するとカウントされないため、滞在時間が短いなど一部指標の計測が難しい。<br>
メーラーなどのJavaScriptが使えない環境だと、ピクセルが描画されてしまい、コンテンツが崩れる可能性がある。</p>
<h2>スクリプト</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a34d47fb-e4e9-4951-8c6e-01212b8c21f9/image3.png" alt="image3"></p>
<p>ピクセルトラッキングでは画像にアクセスしていましたが、実際は画像ではなくても特定のURLにアクセスさえしてくれれば同じことが実現できます。そのためページやコンテンツの表示に合わせてJavaScriptで計測用のURLへアクセスする方法も取られます。<br>
JavaScriptを使用できるため、好きなタイミングで計測できるようになります。例えば、滞在10秒後・20秒後・30秒後…にトラッキングして滞在時間を計測したり、ページのスクロール率100%のタイミングでトラッキングして、ページの読了率を計測したりもできます。<br>
IAB（ <a href="https://www.iab.com/guidelines/iab-measurement-guidelines/">https://www.iab.com/guidelines/iab-measurement-guidelines/</a> ）が提示しているような、厳密な計測（コンテンツが50%以上表示されていること、など）を行う場合は、JavaScriptによるタイミングの制御が必須となってくるため、必然的にこの方法が用いられます。</p>
<h3>メリット</h3>
<p>ページの50%以上読み込んだらなど、集計タイミングを柔軟に作れる。</p>
<h3>デメリット</h3>
<p>JavaScriptが必須なため、メーラーなどJavaScriptの実行を制限された環境だと使えない。</p>
<h1>クリックトラッキング</h1>
<p>続いてはクリックトラッキングについてです。ページやコンテンツの効果を測りたい場合、インプレッション数に加えて、実際にコンテンツをクリックした回数を計測することが必要になります。その時のクリックの計測方法も複数あります。</p>
<h2>リダイレクタ</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/367fa81d-167f-48cc-9909-5280545f3d42/image4.png" alt="image4"></p>
<p>クリックした時に目的のページへすぐに遷移せず、一旦別のサーバを挟む計測方法です。httpのstatus code 302を活用します。リンクをクリックした時に一旦リダイレクトサーバにアクセスし、そのクリック情報を記録したのち、ブラウザのstaus code 302のリダイレクト機能を使って目的のサーバへ遷移させる方法です。<br>
短縮URLと呼ばれる機能とほぼ同じ動きをするため、合わせて実装されていることが多い印象です。</p>
<h3>メリット</h3>
<p>一般的なWebの仕組みに乗っているので、だいたいどこでも動く。</p>
<h3>デメリット</h3>
<p>余計な遷移を挟むため、ページ遷移が少し遅くなる。</p>
<h2>イベントハンドラ</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9cf48347-7b15-49b5-9b3c-a15583995563/image5.png" alt="image5"></p>
<p>２つ目はリンクのclickのイベントハンドラを使う方法です。JavaScriptを使うことで、リンククリック時の処理(onclickなど）に介入して、ページ遷移をする前にアクセス情報を記録用のサーバへ飛ばす方法になります。クリック情報記録用のアクセスとページ遷移を非同期に行えるようになるので、前述のリダイレクトのような不要なページ遷移をせずに実行できます。</p>
<h3>メリット</h3>
<p>余計なページ遷移を発生させないで済む。</p>
<h3>デメリット</h3>
<p>別途clickハンドラが設定されているとかち合うことがある。<br>
JavaScriptが使えない環境では動かない。</p>
<h1>まとめ</h1>
<p>アクセス情報やクリック情報を計測するための技術を駆け足で見てきました。複数の計測の仕組みを作るのは大変ですが、正確な計測を行うためには環境に応じて技術を使い分ける必要があります。環境と計測内容から適切な計測方法を探し出してみてください。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<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>


ウェブ上でのデータを解析する前に、まずはデータを正しく計測したい！ユーザーのインプレッションとクリックのイベントを収集する方法をまとめました。

計測したいものに合わせてイベントトラッキングをする方法 | PLAID engineer blog

計測したいものに合わせてイベントトラッキングをする方法

<p>こんにちは！エンジニアの@g0eです。4月1日にPLAIDに入社して、約4ヶ月が経過しました。<br>
まだまだ勉強することだらけですが、ようやくKARTEの開発環境にも慣れてきました。</p>
<p>本記事ではプレイドエンジニアの組織文化について、入社4ヶ月目のフレッシュな目線で書いてみようと思います。<br>
転職活動中でプレイドに興味がある、KARTEというプロダクトの裏にあるエンジニア文化に興味ある、といった人にとってなにかの参考になれば、と思います。</p>
<p>入社直後にも<a href="https://blog.plaid.co.jp/n/nc8cabf281d1e">この記事</a>でもプレイドという組織について少し話をさせてもらっているので、もし興味がある方はこちらも合わせて読んでみて頂けると嬉しいです。</p>
<h2>プロダクトファースト</h2>
<p>プレイドでは<a href="https://karte.io/">KARTE</a>というマーケティングツールの開発を行っています。自分が転職活動をする時にまず第一条件としてあげていたのが、自社開発の強いプロダクトを持っているという点だったのですが、やはりエンジニア文化を語るにあたっても、このKARTEというプロダクトを中心にエンジニア文化が形成されているという点は外せないかと思っています。</p>
<p>入社後の研修プログラムでも、まずはKARTEについての理解を深めるところから始まります。<br>
また、社内では<strong>ガチャ</strong>と呼んでいる仕組みがあって、プロダクトに関する不具合が見つかった場合や、エンジニア側での調査が必要な問い合わせがあった際に、その担当をエンジニアにランダムに割り当てる仕組み（厳密には順番なのでランダムではないのですが）があります。</p>
<p>普通に開発をしていると自分自身が書いたコードやその周辺領域以外はブラックボックスということが多いと思うのですが、それを意識的にバラしにいくという仕組みになっています。<br>
以下はガチャの担当が回ってきた時に自動的に割り当てられるissueにかかれているメッセージの一部です。</p>
<blockquote>
<p>bugfixを実際開発した人に回すのは基本的に最小限にする。キャッチアップも兼ねてbugfixは受け取った人がやること。分からない場合、どうしても時間がない場合はしょうがない</p>
</blockquote>
<p>自分も入社してしばらくしてこのガチャの担当に入れてもらったのですが、最初は初見のコードになかなか苦戦したものの、以下のようなメリットを感じています。（この仕組みは自社プロダクトを開発している会社では導入を検討する価値のある仕組みだと思います）</p>
<ul>
<li>自社プロダクトの（実装面だけではなく）仕様や使い方に対する理解が促進される</li>
<li>普段自分が担当している領域以外も含めたシステム全体像の理解が促進される</li>
<li>最初の実装を担当していたエンジニアへの確認などエンジニア間でのコミュニケーションが促進される</li>
<li>（クライアントからの調査依頼も含まれるので）、クライアントからの声に直接触れる機会を持てる</li>
</ul>
<h2>変化に対する柔軟性</h2>
<p>マーケティングの世界はとにかく変化が激しい世界で、KARTEを取り巻く外部環境の変化も激しく、市場に合ったプロダクト開発を進めていくためには柔軟性やスピード感が非常に重要になってきます。プレイドでは、その変化に柔軟に対応できるようにいくつかの仕組みがあります。</p>
<p>まず最初に挙げられるのが、開発を行う際のサイクルについてです。社内では開発期間を2ヶ月毎に区切ってその1区切りを<strong>フォーカス</strong>と呼んで、フォーカス毎に各チームで達成したい目標を設定して、開発に取り組んでいます。2ヶ月という比較的短いサイクルで区切ることによって、短期間のうちに成果を出せるように意識的に動くことになります。<br>
当然、2ヶ月では終わらないような開発を行うこともあるのですが、その場合はフェーズを切る形で対応するなどして、短期・長期のバランスをとっています。</p>
<p>フォーカスは2〜5人程度で担当する機能毎にチームを組んで進めていくのですが、チームの組み換えもフォーカス毎に行うこととなり、人によっては2ヶ月で新しい機能開発を終えて、次の新規機能の開発に着手していくことになります。一部高い専門性が必要となる領域ではある程度メンバーが固定化されている部分もありますが、それでも一部のメンバーを入れ替えることで変化やチーム間での交流を促すような仕組みになっています。<br>
（席替えも月1回の頻度であり、基本的にはチームごとに近い席に座ることが多いのですが、毎月周りの景色が変わるというのもなかなか新鮮でした。）</p>
<p>次に挙げられるのが、<strong>創造のための破壊</strong>という点です。どのような会社やプロダクトであっても、技術トレンドの変化によって技術的負債の返済とは付き合い続けるものだと思います。特に技術的負債によって苦労したことがある人は、なるべく負債にならないようにと、技術選定にかなり時間をかけてしまうのではないでしょうか。</p>
<p>プレイドのエンジニア文化として強く感じたのは、『<strong>とりあえずやってみる</strong>』からの、『<strong>違うと思ったら作り直す</strong>』という文化です。同期入社の@kazuponさんの<a href="/pug_to_html/">エントリー</a>でもあったような、大規模な変更についても、かなりアグレッシブに取り組んでいます。<br>
これまで作ってきたものを躊躇なく破壊（作り直すことが）することができ、それを『<strong>承認より謝罪</strong>』の文化に則って進めることができることは、変化に対応し続けるためにも、スピード感を持ち続けるためにも、非常に重要な役割を担っているように感じます。<br>
（影響範囲の大きい変更を加えることは、なかなか大変で責任も伴うことですが、変え続けていくことを是として、失敗してもフォローし合える空気感を作ることが重要なのだと再認識しました。）</p>
<h2>生産性を高め続けること</h2>
<p>最後に、入社して感じたこととして、生産性を高めることへの意識が（これはエンジニアに限らず）全社的に非常に高いということです。</p>
<p>自社で（マーケティング）のツールを開発しているだけあって、世の中のSaaSサービスに対するアンテナが非常に高いというのもあると思うのですが、とにかく社内で色々なサービスを使って、色々な業務を自動化したり効率化したりという取り組みが行われています。（入社して一番最初の仕事がPCと社内で使っているサービスのセットアップなのですが、ここでまず社内で使っているサービスの豊富さに驚きました）</p>
<p>また、既存のサービスをうまく利用するだけでなく、無いものは自社で開発してしまったり、会社の制度も含めていかに効率化するか、というのが非常によく考えられています。<br>
一例にはなりますが、社内で生産性を高めるために行われている取り組みや制度を次に挙げてみました。リモートワークについては、突発的な問題への対応に限らず、集中作業日としてうまく活用している人も多いように感じます。（心なしか大雨の日はオフィスに人が少ないような気も…）</p>
<ul>
<li>毎日勤怠をつけるのが大変
<ul>
<li>→　会社のNWに繋ぐと自動的に勤怠を記録するシステムを自社開発</li>
</ul>
</li>
<li>毎月の経費精算が大変
<ul>
<li>→　前もって手当として定額を支給する<a href="https://atengagement.com/jinji-zukan/allowance/">制度</a>を運用</li>
</ul>
</li>
<li>家庭の事情や天候不順で通勤が困難
<ul>
<li>→　リモートワークの制度をうまく活用</li>
</ul>
</li>
</ul>
<p>エンジニア(プログラマ)の美徳として『<strong>怠惰</strong>』であること、がよく挙げられ、自分自身もルーチンワークは苦手な方なのですが、いまのところ不満を感じずにエンジニアの美徳を貫いて作業に集中できる環境になっているように感じます。</p>
<p>やや働き方や働く環境的な話に寄ってしまったのですが、エンジニアとしての業務の進め方に関しても、上記の様な生産性を強く意識した環境になっています。最初の項目で挙げたガチャの仕組みはslack上のボットにより自動化されていたり、ビジネス職の方からの依頼や相談もすべてgithub上のissueに集約される形になっていて、基本的にはコードとgithubとslackがあれば通常の業務は回せるようになっています。</p>
<p>良い側面ばかりを書いてきたのですが、当然、これらの生産性を高めるための取り組みの裏側には、それだけのアウトプットが求められ続けていることや、そのためのセルフマネージメントが要求されるということを、忘れてはいけないな、とも思います。</p>
<h2>最後に</h2>
<p>最後まで読んで頂いてありがとうございます！<br>
いかがでしたでしょうか？プレイドのエンジニア文化に興味を持って頂けたでしょうか？</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<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>


こんにちは！エンジニアの@g0eです。4月1日にPLAIDに入社して、約4ヶ月が経過しました。
本記事ではプレイドエンジニアの組織文化について、入社4ヶ月目のフレッシュな目線で書いています。

入社4ヶ月で感じたプレイドエンジニアの組織文化 | PLAID engineer blog

入社4ヶ月で感じたプレイドエンジニアの組織文化

1,100 超えコンポーネントの Jade / Pug テンプレートを移行した話 | PLAID engineer blog

1,100 超えコンポーネントの Jade / Pug テンプレートを移行した話

Engineer Blog

Recent Article

KubeCon in San Diegoに参加してきました！

Our seeking to stable k8s deployment.

深層強化学習は量子猫の夢を見るか？

ITP 2.2, 2.3の検証ツールを作ってみた

Vue.js設計地図〜設計概念の依存関係からフロントエンド設計を見つめ直す〜

Google Cloud Next Tokyo ’19に参加しました！

プレイドでのインターンを振り返って

計測したいものに合わせてイベントトラッキングをする方法

入社4ヶ月で感じたプレイドエンジニアの組織文化

1,100 超えコンポーネントの Jade / Pug テンプレートを移行した話

Popular Articles

Popular Tags

Archives

Writers

Recent Article

KubeCon in San Diegoに参加してきました！

Our seeking to stable k8s deployment.

深層強化学習は量子猫の夢を見るか？

ITP 2.2, 2.3の検証ツールを作ってみた

Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜

Google Cloud Next Tokyo ’19に参加しました！

プレイドでのインターンを振り返って

計測したいものに合わせてイベントトラッキングをする方法

入社4ヶ月で感じたプレイドエンジニアの組織文化

1,100 超えコンポーネントの Jade / Pug テンプレートを移行した話

Popular Articles

Popular Tags

Archives

Writers

Vue.js設計地図〜設計概念の依存関係からフロントエンド設計を見つめ直す〜