Engineer Blog

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

<h1>自己紹介</h1>
<p>初めまして、プレイドでエンジニアインターンをしている小林雅史と申します。プレイド内ではあだ名である<a href="https://x.com/mercy34mercy">mercy</a>(マーシー)で呼ばれています。</p>
<p>立命館大学の修士1年生で、大学は情報理工学部、大学院は情報理工学研究科とコンピュータやプログラミングについて学び、研究しています。プログラミングは大学入学と同時に授業で取り組んできました。プログラミングに関しては授業だけでなく、ハッカソンなどでさまざまなアプリケーションを作成しました。特に<a href="https://cup.hackz.team/">ハックツハッカソン</a>が大好きで2度優勝しています。また<a href="https://ritsumeikanunivpress.com/07/11/4430/">大学生向けのバス時刻表アプリ</a>を先輩から引き継ぎ運用していたりもしています。3年生の時には学生IT団体<a href="http://www.watnow.jp/">watnow</a>の代表として<a href="http://www.watnow.jp/2022/10/20/%E9%96%A2%E8%A5%BF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%AB%E3%83%B3%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B92022%E3%82%92%E9%96%8B%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/">企業様とのイベント</a>や<a href="http://www.watnow.jp/2022/08/24/watnow%e3%83%8f%e3%83%83%e3%82%ab%e3%82%bd%e3%83%b3-beginners-cup%e3%82%92%e9%96%8b%e5%82%ac%e3%81%97%e3%81%be%e3%81%97%e3%81%9f%ef%bc%81/">団体内ハッカソン</a>を立ち上げたりとコミュニティの運営も行いました。</p>
<p>プレイドでは2023年の4月からインターンとして勤務していて、最初は<a href="https://tech.plaid.co.jp/platform-engineering-kaigi-2024-report">認証基盤の開発</a>を行いました。その後Redisの監視を簡単にDatadogで行うための社内向けツールを開発し、2023年10月ごろから<a href="https://karte.io/package/message/">KARTE Message</a>というプロダクトの開発を行うチームに加わり、開発を行っています。</p>
<h1>KARTE Messageについて</h1>
<p>KARTE Messageは、データを元にメールやプッシュ通知、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<div class="iframely-embed" data-embedded-url="https://karte.io/package/message/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://karte.io/package/message/" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Fkarte.io%2Fpackage%2Fmessage%2F&key=878c5bef402f0b2911bf6d4ce6261abd">KARTE Message（マーケティングオートメーション/MA）｜顧客体験を磨きこみ、自動化のその先へ【KARTE（カルテ）】</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script> 
<h1>課題</h1>
<p>KARTE Messageの機能であるスマホアプリ向けのプッシュ通知配信では月間1億通を超える規模の配信を行っています。</p>
<p>今回、プッシュ通知に利用しているFCMの<a href="https://firebase.google.com/docs/reference/admin/node/firebase-admin.messaging.messaging.md?hl=ja#messagingsendall">sendAll API</a>が2024年の6月20日に廃止されることが決定し、この期日までに今後も引き続き使用できるAPIに乗り換える必要がありました。</p>
<p>また、これまで使用していたsendAll APIでは、最大500件の通知をバッチ的に送信することができましたが、これと完全に互換性のあるAPIは現在用意されておらず、1通1通を個別に送信する必要があります。</p>
<p>今回私はこのリプレース作業を担当することになりました。</p>
<h1>テスト送信の実装・切り替え</h1>
<p>最初に、移行時のリスクが小さいテスト送信から置き換えることとなりました。本番送信もテスト送信も1通1通を個別に送信するロジックは同じであり、違いは送信数です。そのため、テスト送信の実装を先に行いリリースすることで、バグがあった際の影響範囲をテスト送信のみに抑えつつ新しい実装の信頼性を検証することができます。テスト送信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>既存のコードとドキュメントを読み理解する</li>
<li>テスト送信の実装</li>
<li>テスト送信の実装の置き換え</li>
</ol>
<h3>1. 既存のコードとドキュメントを読み理解する</h3>
<p>既に動いているシステムをリプレースするため、まずは既存のコードを理解する必要がありました。コードを読むだけではなかなかコードの振る舞いを把握するのが難しいので、単体テストを新たに追加しました。</p>
<h3>2. テスト送信の実装</h3>
<p>リプレースする際のリスクを最小にするために、新規実装では既存の実装と同じケースの単体テストを書き、既存実装、新規実装ともにテストケースと結果が同じになることを確認することで、実装ミスがないかを検証しました。また、新規実装では、Goの実装が約1200行なのに対してテストコードは約5600行あります。テストはローカル環境で実行することができ、キャッシュがない状態でも30秒ほどで終了します。また、これらのテストはGithubActionsで自動で実行されており、生産性向上につながっています。</p>
<h3>3. テスト送信の実装の置き換え</h3>
<p>無事に実装が終わりテストも通ったら本番環境のテスト送信をリプレースしました。これまでの業務でバグの修正や新機能の実装をした事はあったものの、今正常に動いているものを全く新しいコードで作成されたシステムに置き換える経験は初めてでとても緊張しました。リリースの実行は社員さんに行ってもらい、検証環境で最終動作確認を行いました。テスト送信のリプレース後には、ユーザ企業様からバグ報告が数件ありました。その中でもGoへのリクエストのJSONのフィールドにnullがあった場合、Goのjson packageではnilに変換されるという仕様があり、nilのハンドリングがうまくできていないコードでバグが発生したのが印象的です。いくつかのバグを修正し、無事テスト送信の実装をsendAll APIからsend APIに切り替えることができました。</p>
<h1>本番配信の実装・負荷試験・切り替え</h1>
<p>テスト送信の置き換えが終了しバグの修正も終わると、本番配信も新しいAPIに置き換えます。本番配信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>本番送信の実装</li>
<li>負荷試験</li>
<li>カナリアリリース</li>
</ol>
<h3>1. 本番送信の実装</h3>
<p>本番送信の実装に関しては本番送信とテスト送信のロジックを共通化したため、基本的にテスト送信の実装を流用する形で実装しました。</p>
<h3>2.  負荷試験</h3>
<p>本番配信では、KARTE Messageを使用されている企業様が大量のアプリユーザに向けてプッシュ通知を送信します。また、お客様が設定した速度で正しく配信する必要があります。そのため、アプリケーションに負荷がかかっても正常に動作することを検証する必要がありました。KARTE MessageはインフラにGCPのGKEを使用しているため、正しい速度で負荷がかかっても送信できる適切なk8sのスケーリング設定を見つける必要がありました。</p>
<p>負荷試験の環境には本番環境とは完全に切り離された検証環境を使用しました。検証環境は本番環境と同じシステムが動作しており、スケーリングの設定などが違うだけで本番環境と同じようにシステムが動作します。</p>
<p>負荷試験に関しては、社員さんからは時間かかってもいいからとりあえずやってみよう！といった感じで言われたので、ほぼ初めてGKEとその設定が書かれたk8s用のyamlファイルと戦うこととなりました。本番配信は、データベース、配信サーバ(今回作成したもの)、配信準備サーバなどさまざまなシステムが連携して動くことで実行されます。サーバやデータベースの状況はリアルタイムでdatadogで確認しました。</p>
<p>負荷試験の目標値は16667rps(時速6000万)となりました。これはAPI置き換え前のシステムで過去に負荷試験をした際の最大値となっています。</p>
<p>最初はスケーリングの設定を何も変えずに、2.7prs、277rps、1667rps、5555rpsと上げて行きました。すると、時速5555rpsの試験では設定した速度で配信されず1100rpsほどでしか配信できませんでした。ここから数時間悩んで色々設定を見ているうちに、配信サーバのスケーリング設定が問題になっていることに気づきました。最大node数とpod数が非常に小さい数に設定されていて、一定以上の負荷に耐えられないようになっていました。そこで、podの最大数を500、nodeの最大数を250に設定し再度負荷試験を行ったところ、16667rpsを達成できました。この時、配信サーバのpod数は100台ほどにスケーリングしていました。</p>
<p>目標値をクリアしたので、次に最適な設定を探します。KARTE Messageではサービスの性質上、リクエストのスパイクが発生しやすいです。また、深夜帯などは配信がなくサーバに負荷がかからない状態になります。そのため、スパイクに耐えられる最小pod数と、最大負荷に耐えられる最大pod数を見つける必要があります。そこで、1podあたりどれくらいの配信数を捌けるのかを調査しました。調査するために、pod数を20台固定にし少しづつ少ない配信数から負荷試験を行い、限界の配信速度を見つけ出しました。20台のpodで2700万/hの配信を行うことができました。pod1台で約135万/hの配信が可能です。そこで、6000万/hの配信に耐えられるpod数より少し余裕を持たせた50を、最大pod数としました。</p>
<p>負荷試験だけで10営業日ほどかかりました、負荷試験の勘所やk8sの特性を理解するのに時間を要しました。初めてやることは、手探りで頑張ってみることも大事ですが、社員さんなど経験がある人にある程度、勘所を先に教わっておくともっと効率良くできたかなと感じました。学生が簡単に経験することができない、k8sを用いたシステムの負荷試験ができたことは非常に良い経験となりました。</p>
<h3>3. カナリアリリース</h3>
<p>負荷試験も終わり、ついに本番配信を新しいAPIに置き換えます。全ユーザに一斉に適用してしまうと、もしもバグなどがあった場合に影響範囲が広くなってしまうため、一部のお客様から順次新しいAPIを適用しました。APIの切り替えは環境変数で指定した特定のお客様の時のみ新しいAPIが実行されるように実装を行いました。環境変数で切り替えを行うことで、もし新しいAPIの実装に問題があった際に、修正やロールバックしたアプリケーションをデプロイすることなく、環境変数を切り替えるだけで既存のAPIの実装に戻せるため、環境変数を活用したカナリアリリースを行いました。カナリアリリースは、置き換え前と比べて、悪化している指標がないか確認しながら約1ヶ月かけて全てのお客様の配信APIを新しいAPIに切り替えました。</p>
<h1>リプレース結果</h1>
<p>リプレースは実装を始めてから約5ヶ月で終了しました。結果として、新しいAPIに切り替えたことによる大きな障害はありませんでした。そして、既存実装よりもエラー率も下がりました。</p>
<h1>最後に</h1>
<p>今回のプッシュ通知配信で使用するAPIのリプレースの実装、試験、移行は全て自分の手で行いました。もちろん社員さんの助けなしではできなかったです。今回のプロジェクトを通して長期インターンでしか体験できない貴重な経験ができました。また、自分は京都に住んでいるのでリモート勤務だったですが、地方に住んでいる学生についてはリモートでも受け入れてくれる環境は非常にありがたかったです。他のインターン生が行ったことについては、ぜひプレイドのエンジニアブログをご覧ください[1][2][3][4][5]。このような経験をしてみたい方、プレイドに興味を持った方は下記からプレイドのエンジニアインターンに応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>[1] <a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a></p>
<p>[2] <a href="https://tech.plaid.co.jp/intern-at-plaid-calloc">プレイドインターン体験記: はじめての開発インターンを通じて得た学び</a></p>
<p>[3] <a href="https://tech.plaid.co.jp/intern-at-plaid-kenshin">プレイドでの開発インターン: 3ヶ月のフルタイムエンジニアとしての挑戦を経て</a></p>
<p>[4] <a href="https://tech.plaid.co.jp/intern-at-plaid-shohei-shiraki">プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び</a></p>
<p>[5] <a href="https://tech.plaid.co.jp/mongo-atlas-to-bigquery">MongoDB AtlasからBigQueryへのリアルタイムレプリケーション</a></p>


KARTE Messageで使用しているFCMのsendAll APIが廃止となるため、APIの置き換えを行った後負荷試験を行なった。

FCMのSendAll API廃止対応

KARTE MessageにおけるFCMのSendAll API廃止対応について

カラムナフォーマットの利点を最大限活かすために書き込み処理、特にリアルタイムの書き込み処理における技術的な課題とOSS DBの具体的なアプローチを紹介しています

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 - PLAID engineer blog

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 

<h2>はじめに</h2>
<p>こんにちは，プレイドのCore Platformチーム<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>（プレイドで社内の全てのプロダクト基盤やリアルタイム解析基盤<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup><sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>を扱っているチーム）でインターンをしている<a href="https://lapla.dev/about/">lapla</a>といいます．プレイドでは2024年6月より働いており，この度社内で広く用いられているデータベースであるMongoDBのバージョンアップ業務に携わったので，その過程で得られた知見についてまとめようと思います．<br>
データベースのバージョンアップは，データベースを使用しているシステムにとって避け難いタスクであり，それはプレイドも同様です．そこでプレイドでは， 単に公式のアップデートドキュメントを読むだけではなく， MongoDBの内部構造も理解した上で作業することにより，安全なバージョンアップを継続的にかつサービス無停止で行っています．今回はその点について説明しようと思います．<br>
なお，本記事はデータベースのいわゆるHow To記事ではなく， データベースの構造に興味のある方や， 既に他のデータベースを使用していて， 今後MongoDBを使ってみようという方向けに記述を行っているため， 前半にデータベースのバージョンアップに関する一般的な話や，プレイドでの使用状況を述べ，後半にMongoDBの内部構造に触れるという構成を取っています．</p>
<h2>自己紹介</h2>
<p>現在，筑波大学情報学群情報科学類の4年生で，主にシステムプログラミングやクラウドネイティブな技術に興味がありますが，OSから機械学習までレイヤを問わずにプログラムを書きます．<br>
趣味のプログラミングについて触れると，学部1年の頃に手が滑って，主にC++でx86_64向けのTCP/IPプロトコルスタックが搭載されたGUI操作可能なOSを書いた結果，その後も手が滑り続けて学部3，4年の頃にはRustで64bit RISC-V向けのOSを書いていました．他にもRust言語が好きなので，RustでELFのタイムトラベルデバッガを書いたり，ELFバイナリ難読化器（ELFバイナリの実行時の動作を変えずに，解析からの妨害対策がなされたバイナリを作り出す）を作っていたりしました．最近は内部でRISC-VバイナリをエミュレートするようなOCIコンテナランタイムを開発しています．<br>
比較的高いレイヤも好きで，例えば学部2年の頃には文章から音を生成するCGANを研究していたりしました．</p>
<h2>プレイドにおけるMongoDBとその周辺ソフトウェアの利用</h2>
<p>プレイドでは，主力プロダクトであるCXプラットフォーム<a href="https://karte.io/">KARTE</a>の様々な場面で主にMongoDBを使用しています．また，ODM（Object Document Mapper）として<a href="https://github.com/Automattic/mongoose">Mongoose</a>を用いていて，Node.js経由でMongoDBを操作しています．プレイドではサーバーサイドがほとんどNode.jsで書かれており，MongoDBは内部的にデータをBSONで保持している点や非同期処理との相性の良さという点でNode.jsとの親和性が高いため，積極的にMongoDBを使用しています．この辺りについては弊社のgamiが書いた「 <a href="https://tech.plaid.co.jp/plaid_loves_nodejs">PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと</a>」 をご覧ください．</p>
<h2>データベースのバージョンアップ</h2>
<p>さて， 冒頭にも述べた通り，データベースの定期的なバージョンアップは，多くのソフトウェア企業に付いて回るタスクの1つです．<br>
主にOSSとして公開されているような一般的なRDBをセルフホストしている場合において，バージョンアップなどの作業を行うためには，データの整合性を取るために一旦データベースへの書き込み処理を停止した上でレプリケーションをおこなってから，アプリケーションが参照するデータベースの接続先を変更する手順を踏むのが一般的と思われます．しかし，いわゆるNewSQLに属するMongoDBでは内部で複数同じ状態のデータを持つノードが複数おり、この特性を活用することで，プレイドでは平日の昼間であっても安全にバージョンアップの作業を行うことができています．<br>
なぜMongoDBの場合にはサービスを停止させずに， 安全にバージョンアップできるのかに関しては，本記事後半で紹介する，MongoDBの内部構造を，論文などを元にして理解することにより達成されています．平日昼間など，通常は忌避される時間帯であっても，安全性の根拠を持ってメンテナンスウィンドウなどを設けずにバージョンアップを行うことは，開発速度の向上などの開発者体験の向上に繋がります．また， サービスを停止させる時間が不要なことは，KARTEをご利用いただくユーザー様にとっても大きな恩恵があると考えます．</p>
<h2>今回のバージョンアップ完了までの手順</h2>
<p>ここでは今回行ったバージョンアップの大まかな手順について説明します．大枠としては以前にMongoDBをバージョン4からバージョン5に上げた際のものと同様です．当時の記録については以前インターンされていた方が書いた「<a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a>」に詳しく記載されていますので，ぜひご覧ください．</p>
<ol>
<li>アプリケーションコードに影響を与えそうな変更の調査<br>
まずはMongooseやMongoDB Serverの現在のバージョンから，バージョンアップする目標のバージョンまでの変更を確認し，主にプロダクトの動作に影響を与えそうなものをピックアップして調査しました</li>
<li>社内ライブラリのアップデート<br>
プレイド社内には，様々なアプリケーションが共用するライブラリが存在します．その中にはMongoDBのラッパーなども含まれているため，これらの更新を行いました</li>
<li>各アプリケーションのアップデート<br>
新しくなった社内のライブラリを用いて，各アプリケーションが動作するように修正を行います．この作業は基本的に各アプリケーションチームに依頼し，書き換えを行なってもらいました</li>
<li>データベースのアップデート<br>
最初に検証環境のデータベースのバージョンを上げ，問題がなさそうであれば本番環境のデータベースもバージョンアップを行います．この際に，本記事後半で触れる内部構造の理解により，安心感をもったバージョンアップを行えています．</li>
</ol>
<h2>バージョンアップ作業の今後</h2>
<p>現在は，バージョン7へのバージョンアップに必要な調査や実装を行っています．バージョン7へのバージョンアップに伴う，現状の我々のユースケースに大きな影響を与えそうなMongooseでの変更をいくつか紹介すると，次のようなものがあります：</p>
<ul>
<li>callbackを用いた処理を書くことができないようになる（社内のアプリケーションコードには，比較的昔に書かれたものではしばしばcallbackが使われている）</li>
<li>社内実装で多く使われている関数を使用できなくなる（findOneAndRemoveなど）</li>
</ul>
<p>このように，今後に控えているアップデートではより困難なアップグレード作業が予想されますが，今回のアップグレードで得られた経験も積極的に用いて，無事に作業を成功させるべく動いています．</p>
<p>—</p>
<p>ここからはよりMongoDBの内部構造を理解したい方向けに記述します．</p>
<h2>MongoDBの内部構造を想像する</h2>
<p>さて，冒頭でも述べた通り，本記事の後半ではMongoDBの内部構造について見ていきます. ここではあくまでも公開論文などをもとに内部の仕組みなどを想像して書いているため， 間違っている可能性は否定できないことを述べておきます.<br>
MongoDBの内部では，分散合意アルゴリズムとして著名なRaftを独自に改良したアルゴリズムを用いて合意を取っています．この機序を理解するためには次の3つの論文が特に参考になります：</p>
<ul>
<li><a href="https://raft.github.io/raft.pdf">In Search of an Understandable Consensus Algorithm (Extended Version)</a>（以下論文1）: 分散合意アルゴリズムのRaftについて紹介されている論文です</li>
<li><a href="https://www.usenix.org/conference/nsdi21/presentation/zhou">Fault-Tolerant Replication with Pull-Based Consensus in MongoDB</a>（以下論文2）: MongoDBの内部では，純粋なRaftアルゴリズムではなく，後述するPull-Based Consensusと呼ばれるアルゴリズムを用いてノード間での合意を取っています．このアルゴリズムについて解説した論文です</li>
<li><a href="https://dl.acm.org/doi/10.14778/3352063.3352125">Tunable consistency in MongoDB</a>: MongoDBでは，書き込みと読み込みの整合性をある程度自由に設定することができます（Tunable Consistency）．これによりアプリケーション特性に合わせた整合性を取ることができます．この内容についての説明がなされています</li>
</ul>
<p>今回はスペースの都合上，論文1で紹介されている純粋なRaftの動作についての説明はある程度既知のものとし，以降は論文2で提案されているpull-based Raftの動作について説明を行うことにします．</p>
<h3>Pull-Based Consensus</h3>
<p>先に述べた通り，MongoDBの内部では純粋なRaftではなく，動作が改造されたRaftアルゴリズムが用いられていて，これは論文内ではPull-Based Consensusとされています．本記事では，純粋なRaftの改造版であるということを強調するために，Pull-Based Raftと呼ぶことにします．<br>
まず一般的なRaftアルゴリズムは，次の図のように，LeaderノードからFollowerノードに対してログが配信され，Followerノードはそれを個々に有しているという構造を取っています．Leaderノードで何らかの不具合が起きると，クラスターはvotingを行い，新たなLeaderノードを選出します：<br>
<img src="https://ik.imagekit.io/plaid/0bd8ed16-d589-473f-8b78-7f10558ba122/image1.png" alt="image1.png"><sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup><br>
また，次図に示すように，クライアント側からのリクエストに対しては複数のモジュールにログが分散して保存されます：<br>
<img src="https://ik.imagekit.io/plaid/77f8ba01-c659-4897-84a7-0d49418acd13/image3.png" alt="image3.png"><sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup></p>
<p>分散合意を取るという目的であればこれで十分ですが，スケーリングやバージョンアップの際など，クラスター内のノードが増減する場合においては，データの同期を柔軟に行うのが難しいといった課題があります．<br>
これに対して，MongoDBは独自のPull-Based Raftアルゴリズムを実装しており，これはFollowerノードが自律的にLeaderノードに対してログの配信を要求しにいくような構造になっています．<br>
<img src="https://ik.imagekit.io/plaid/72eac0ca-f319-44ab-9df9-46c81ce2ed6b/image2_1.png" alt="image2_1.png"><sup class="footnote-ref"><a href="#fn6" id="fnref6">[6]</a></sup></p>
<p>これはレプリカのデータ同期を任意の2つのレプリカで行うことができるという特徴があり，様々なネットワークトポロジーを取ることができるようになります．また，これによりネットワークの帯域幅を削減できるという特徴も存在します．<br>
また，バージョンアップの作業を行うにあたっては，クラスター内の古いバージョンのノードが1つ，新しいバージョンのものと入れ替わって，問題が無ければ他の古いバージョンのものも順々に取り替えていくという方式を取っているものと思われます．このことは， MongoDBの公式のドキュメントには記述がありませんが，バージョンアップ時のメトリクスを観察した結果得られたヒューリスティックな観測です．この挙動が可能なのは， Pull-Based Raftによって任意のレプリカ間でのデータ同期を柔軟に行えるためだと考えています．このような挙動は，バージョンアップ時に何か不具合が生じてもサービスを停止させることなくロールバックできるという点で利点があります．</p>
<h2>最後に</h2>
<p>ここまで見てきたように，論文などのある程度信頼できるソースを元にした，ソフトウェアの内部構造理解は，より安全なシステム設計・運用につながるものであると言えます．<br>
私自身は今回のバージョンアップ作業に際して，こういった理論面から実装までの理解を一気通貫で行うことができたので，貴重な経験を積めたと思います．<br>
本記事ではその一端をお伝えすることができたと思うのですが，プレイドは計算機的に面白い業務が様々な場所に存在する環境であると思います．プレイドで働くことに興味を持たれた方は，ぜひ次のリンクもご覧ください．</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/engineer"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://recruit.plaid.co.jp/engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Frecruit.plaid.co.jp%2Fengineer&key=878c5bef402f0b2911bf6d4ce6261abd">エンジニアについて | 採用情報 | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p><a href="https://blog.plaid.co.jp/n/nfa3642bf9871">“エンドユーザーに露出するプラットフォーム”をつくる。Core Platformチームの仕事はなぜチャレンジングなのか</a> <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a> <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a> <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>Diego Ongaro and John Ousterhout. 2014. In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX conference on USENIX Annual Technical Conference (USENIX ATC'14). USENIX Association， USA， 305–320. <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p><a href="https://www.yugabyte.com/tech/raft-consensus-algorithm/">What is the Raft Consensus Algorithm?</a> <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn6" class="footnote-item"><p><a href="https://www.usenix.org/system/files/nsdi21_slides_zhou-siyuan.pdf">Fault-Tolerant Replication with Pull-Based Consensus in MongoDB</a> <a href="#fnref6" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


社内で広く用いられているデータベースであるMongoDBのバージョンアップ業務に携わったので，その過程で得られた知見についてまとめようと思います．

MongoDBをサービス無停止で継続的かつ安全にバージョンアップしている話_プレイドエンジニアブログ

MongoDBをサービス無停止で継続的かつ安全にバージョンアップしている話

こんにちは。プレイドでWicleを開発しているchakeです。 Wicleはプロダクトを使うユーザーの行動を分析し、改善するサイクルを助けるプロダクトアナリティクスサービスです。先日パブリックベータ版をリリースし、だれでもオンライン上からサインアップすることができるようになりました。

新進気鋭の認証サービスClerkを実プロダクトで使いこなせ

こんにちは！6月から8月までの3ヶ月間、プレイドでエンジニアインターンとして勤務しておりました伊藤孝太朗です。私は現在、カナダ・バンクーバーにあるブリティッシュコロンビア大学（University of British Columbia, UBC）で学部3年生としてコンピュータサイエンスを専攻しています。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月_プレイドエンジニアブログ

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月

<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 テンプレートを移行した話

<p>こんにちは！プレイドのエンジニア採用/技術広報を担当しているmattyです。今回、2019/6/27(木)に完全招待制の技術イベント『#PlaidTechLounge』を開催しました。</p>
<p>プレイド主催での技術イベントは半年前の<a href="https://blog-plaid.com/event/5285/">#PlaidTechMeetup</a>以来です。</p>
<p>今回は、前回の反省を踏まえ、『ゲストの方が自由にLTを選べて、話したい人と話せる』ように意識しました！<br>
この記事では、イベントの様子をお伝えしていきます。</p>
<h1>オープニング</h1>
<p>今回の司会は、ポッドキャスト『しがないラジオ』パーソナリティであり、『完全SIer脱出マニュアル』の著者でもあるgamiさん。もはやプレイドの技術イベントではお馴染みです笑<br>
そのgamiさんからPlaid、リアルタイムユーザー解析プラットフォーム「<a href="https://karte.io/">KARTE</a>」、当日のLTについて紹介！<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bddc740e-ff8d-4b28-bba7-c6f5d45809d1/iOS------6-.jpg" alt="iOS------6-"></p>
<p>今回のLTは5つのテーマを用意。各登壇者からも一言ずつコメントをもらいました！</p>
<table>
<thead>
<tr>
<th>登壇者</th>
<th>タイトル</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="https://twitter.com/tarr1124">@tarr1124</a></td>
<td>KARTEの解析部分のアーキテクチャ</td>
</tr>
<tr>
<td><a href="https://twitter.com/otoan52">@otoan52</a></td>
<td>2016年からサービスインしているPush APIサービスのノウハウ</td>
</tr>
<tr>
<td><a href="https://twitter.com/kadoppe">@kadoppe</a></td>
<td>フラット型組織におけるエンジニアリングマネージメント</td>
</tr>
<tr>
<td><a href="https://github.com/komukomo">@komukomo</a></td>
<td>大規模なモノリシック・サービスを分割する理由と方針</td>
</tr>
<tr>
<td><a href="https://twitter.com/yohei_meguro">@yohei_meguro</a></td>
<td>はじめて1人チームで開発をするあなたへ</td>
</tr>
</tbody>
</table>
<h1>LT&amp;懇親会</h1>
<p>早速、LT&amp;懇親会スタートです。</p>
<p>今回、『ゲストの方が自由にLTを選べて、話したい人と話せる』を意識したので、タイムスケジュールや会場を工夫しました。</p>
<ol>
<li>LTと懇親会の時間はあえて分けず、LT中も懇親会エリアを解放したことで、好きな時間にLTを聞き、好きなタイミングでプレイド社員と話せるように！</li>
<li>LTのテーマ数を絞り、LT間の休憩時間を設け、自由に動けて話せる時間を多めに確保！</li>
<li>LTエリアと懇親会エリアの物理的な距離を取り、話に集中できるように会場設営！</li>
</ol>
<p>イベントによって会場を工夫できるのもプレイドの『<a href="https://blog.plaid.co.jp/n/n9e2a3faf72d7">完成しないオフィス</a>』ならでは！</p>
<h2>食事</h2>
<p>今回は、<a href="https://tomo-foodsense.com/profile/">FOOD SENSE</a>さんにケータリングをお願いしました。<br>
味はもちろん、見た目もとてもおしゃれで素敵です！<br>
串がついていて手が汚れない配慮までされていて、満足度がかなり高かったです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ef4a02b2-fe46-4bd3-8637-fbc47ae4f242/iOS------1-.jpg" alt="iOS------1-"><br>
余談ですが、あっという間になくなってしまったので、お寿司を30人前追加発注しました…笑</p>
<h2>LT</h2>
<p>プレイドのエンジニアからテーマ別に発表！<br>
それぞれ簡単にどのようなことを話したのかコメントを記載しています。</p>
<h3>KARTEの解析部分のアーキテクチャ</h3>
<pre><code>SREチームのtarrさん
KARTEによって解析されたデータがどのように格納されるのか、という流れで
トラッキングと解析部分のアーキテクチャを話しました。
</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f9ecefdb-30ee-434b-9eff-33e6c8ccd5aa/iOS------5-.jpg" alt="iOS------5-"></p>
<h3>2016年からサービスインしているPush APIサービスのノウハウ</h3>
<pre><code>i18nチームのotoanさん
Push APIとその前提となるService Workerについて、
機能やその背景などを解説し、Push通知機能をサービスインするにあたり難しかった点について簡単に解説しました。
Service Workerについて知っている方も思ったより多かったようなので、
もう少し突っ込んだ話もいずれできるといいですね。
</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d7675ccc-c0f6-4b7c-bae7-395d0bb449fc/iOS------2-.jpg" alt="iOS------2-"></p>
<h3>フラット型組織におけるエンジニアリングマネージメント</h3>
<pre><code>Head of Engineeringのkadoppeさん
世界に通用する強いプロダクトを作るために、プレイドのエンジニアチームで大事だと考えている
考え方やスタンスについてお話ししました。
</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13aa3416-172f-451c-9d65-fc8a4f8d9318/iOS------4-.jpg" alt="iOS------4-"></p>
<h3>大規模なモノリシック・サービスを分割する理由と方針</h3>
<pre><code>Performanceチームのkomaさん
１つのリポジトリで大きく成長したモノリシックなアプリケーションを分割し運用基盤を移行している話をベースに、
その分割の方針や、悩んだポイントとその対応策などについてお話しました。
</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4464fd94-c2bb-4f8a-aec1-c7dd4febb830/MVIMG_20190627_210432.jpg" alt="MVIMG_20190627_210432"></p>
<h3>はじめて1人チームで開発をするあなたへ</h3>
<pre><code>1人チームを卒業したguroさん笑
2ヶ月間1人チームで開発していたので、その時に感じた落とし穴やその乗り越え方についてお話させていただきました。
「ヒトとコトの分離が難しい」というスライドに多くの共感をいただけました。
</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/296bbb0d-ef27-4632-9754-eb6c531e79c8/iOS------3-.jpg" alt="iOS------3-"><br>
ゲストの方で1人チームを経験している方も多かったので、このスライドがこの日一番の笑いと共感を得ていましたね笑</p>
<p>今回、LTと懇親会を並行して行ってみて、多くの方がLTに集まってくれました。<br>
懇親会エリアと距離があったので、みなさん真剣に話を聞いてくれていた印象です。<br>
LT枠はそれぞれ10分でしたが、質問も多く飛び交い、枠をはみ出るほど、どのテーマも盛り上がりを見せていたのは素直に良かったです。</p>
<h2>懇親会</h2>
<p>懇親会エリアでは、それぞれのLTテーマについて話したり、そこから更に深い技術の話へ発展したり、ボードゲームをやるグループまで様々!<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/04a7878c-5d0e-44e7-8269-cfd4a71629cc/iOS------7-.jpg" alt="iOS------7-"><br>
懇親会後、元々知り合いではなかったプレイドメンバーとゲストで「今度別でご飯行きましょー！」という声も上がっていたのは嬉しかったですね。</p>
<h1>最後に</h1>
<p>参加された皆さんの声や一部資料が#PlaidTechLoungeで、<a href="https://twitter.com/search?f=tweets&amp;q=%23PlaidTechLounge&amp;src=typd">Twitter</a>から見ることができます。ぜひご覧ください！</p>
<p>今回、来ていただいたゲストのみなさま、ありがとうございました！<br>
今後も定期的にプレイドの技術発信の場を作っていきたいと思っています。</p>
<p>内容もどんどん濃くして、より良い場にしていければと思っていますので、引き続きよろしくお願い致します。</p>
<hr>
<p>リアルタイムユーザー解析プラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは弊社<a href="https://plaid.co.jp/recruit.html">採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>


技術イベント 『#PlaidTechLounge』を開催しました！

<p>こんにちは、PLAIDのエンジニアの<a href="https://twitter.com/jumpei_ikegami">gami</a>です。<a href="https://twitter.com/search?vertical=default&amp;q=%23%E3%81%97%E3%81%8C%E3%81%AA%E3%81%84%E3%83%A9%E3%82%B8%E3%82%AA&amp;src=tyah">趣味はポッドキャスト配信</a>です。</p>
<p>さて、先日2019/6/10(月)に、縁あってDeNAさん、Google Cloud Japanさんと共同でクローズドなGCP勉強会を開催しました。</p>
<p>PLAIDではリアルタイムユーザー解析サービス「<a href="https://karte.io/">KARTE</a>」の開発や提供に、GCPの各種サービスをヘビーに使っています。今回の勉強会では、同じく様々な事業でGCPを早くから採用してきたDeNAさんと、有意義なディスカッションをすることができました。</p>
<p>この記事では、そんなGCP勉強会の様子をご紹介します。</p>
<h1>乾杯から始まる勉強会</h1>
<p>クローズドでカジュアルな勉強会ということで、集まっていきなり乾杯をしました。PLAIDの人工芝での開催なので、野外フェス感があります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a1961b43-1563-4eea-8ebe-83577f196e46/001-1.jpg" alt="001-1"></p>
<p>司会は、PLAIDのエンジニア採用担当のmattyが務めました。笑顔が渋い。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/68508977-32c3-4b3e-b836-0d54cebab974/002.jpg" alt="002"></p>
<h1>各社からのLT</h1>
<p>次に、PLAID、DeNA、Googleの3社それぞれから、LTがありました。</p>
<h2>PLAID</h2>
<p>PLAIDからは、CTOの牧野からKARTEの紹介やGCPを使うことで得られるメリットなどについて話しました。</p>
<ul>
<li>KARTEでは、BigtableやBigQueryを中心にGCPの導入が進み、最近はDataflow、Cloud Spannerなど使うサービスの種類も増えている</li>
<li>扱うデータ量が膨大になっており、BigQueryでのStreaming Insertで1PB/monthほど</li>
<li>解析数やデータ量が増えてもコストはそこまで増えていないという点で、GCPの恩恵を受けている</li>
</ul>
<h4>参考記事:</h4>
<ul>
<li><a href="https://codezine.jp/article/corner/711">大規模解析サービスを支えるGCP活用事例連載一覧：CodeZine（コードジン）</a></li>
<li><a href="https://www.youtube.com/watch?v=8UuiJjTW12Y">Plaid's Journey to Global Large-Scale Real-Time Analytics With Google BigQuery (Cloud Next '19) - YouTube</a></li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/00a4a01c-0f6e-4dec-8933-c65fbdb6b7e4/003.jpg" alt="003"></p>
<h2>DeNA</h2>
<p>DeNAの菅原さんからは、DeNA San FranciscoでGCPに出会ってから、DeNA内でGCPの利用が広がっていった歴史についてお話しいただきました。</p>
<ul>
<li>Mobage WestでGoogle App Engine Javaを利用し、Auto Scaleによる安定運用を実現できた</li>
<li>2016年頃から、日本のDeNAでも<a href="https://www.andapp.jp/">AndApp</a>などでGCPの利用を本格的に開始</li>
<li>現在では様々な事業で GCP は活用されており、『逆転オセロニア』や自社のAI学習基盤などのAI分野でもGCP活用の幅が広がっている</li>
</ul>
<h4>参考記事:</h4>
<ul>
<li><a href="https://cloudplatform-jp.googleblog.com/2019/03/DeNA-Advanced-Solutions-Lab-GCP.html">Advanced Solutions Lab で培った知見を踏まえ Google Cloud Platform 上に AI 基盤を構築。『逆転オセロニア』のプレイヤー体験を向上</a></li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b241d38d-6179-4f5c-a8bc-d0ae4c9b64be/004.jpg" alt="004"></p>
<h2>Google Cloud Japan</h2>
<p>Google Cloud Japanの白川さんは、以前AWSでも働いていたことがあるとのことで、Amazon(AWS)とGoogle(GCP)を比較するというエッジの効いたトークをしていただきました。</p>
<ul>
<li>AWSは2006年にリリースされたS3から、GCPは2008年にリリースされたGAEから始まっている</li>
<li>Amazonの組織は一般にメンバーがセクションで明確に分かれているが、Googleはチームを超えて色々な人がつながっている</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24a49dce-9052-4cab-82e7-8b860679497b/005-1.jpg" alt="005-1"></p>
<h1>懇親会</h1>
<p>LTの後は、セミナースペースでお酒や食事を囲んで技術の話に花を咲かせました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/018f0952-7ca3-498c-b1a8-50f7adca0b14/006.jpg" alt="006"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2bf88d92-b961-4a80-a06f-45c8faed93bf/007.jpg" alt="007"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a2d7555d-fcf0-40b2-9c5c-4bfc2a079663/008.jpg" alt="008"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/56a67f6a-8829-4c8c-966c-c99999b5d152/009.jpg" alt="009"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d9c660df-0b30-4c88-b244-2f84dc09993d/010.jpg" alt="010"></p>
<h1>最後は集合写真！</h1>
<p>懇親会の最後は、参加者みんなで集合写真を撮りました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fbc3ed8b-7b40-4da7-9a24-62e9195efd77/011.jpg" alt="011"></p>
<p>普段、PLAIDのエンジニア同士で話すときはKARTEのアーキテクチャなどを暗黙の前提にしていることが多いです。今回は、全く違うサービスやアプリケーションを開発しているDeNAのエンジニアのみなさんと話すことで、かなり刺激を得ることができました。</p>
<p>このような技術交流の機会を定期的に持つことで、凝り固まった頭をほぐすことができてとても良いと思うので、ぜひまた開催したいです！</p>
<p>以上、GCP勉強会のイベントレポートでした。</p>
<p>なお、DeNAさん側でもこちらのイベントのレポートが公開されていました。あわせてご覧ください！</p>
<p><a href="https://engineer.dena.jp/2019/06/dena-plaid-googlecloud.html">DeNA x PLAID x Google Cloud 交流会を実施しました！ - Technology of DeNA</a></p>
<hr>
<p>リアルタイムユーザー解析プラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、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>


2019/6/10(月)に、縁あってDeNAさん、Google Cloud Japanさんと共同でクローズドなGCP勉強会を開催しました。様々な事業でGCPを早くから採用してきたDeNAさんと、有意義なディスカッションをすることができました。

DeNA、Googleと共同でGCP勉強会を開催しました！ | PLAID engineer blog

DeNA、Googleと共同でGCP勉強会を開催しました！

<h2>BigQueryの監査ログは役に立つ</h2>
<p>PLAID Engineerの 原田(@harada_hi) です。</p>
<p>弊社製品KARTEでは行動データという大量データの集計においてBigQueryを多用しています。<br>
今回はそのBigQueryのパフォーマンス確認やトラブル時の調査に利用しているBigQueryの監査ログの話を紹介します。</p>
<h3>集計を実施する上で確認したい内容</h3>
<p>BigQueryはSparkやHadoopを組み合わせて実施していた集計処理を賄うことが可能です。<br>
前述のとおりPLAIDにおいてもユーザーの行動データをBigQueryに収集し、クエリを実行して集計を実施しています。<br>
BigQueryで集計を行う上で次のような点を確認したい場面があります。</p>
<ol>
<li>各集計クエリの実行時間</li>
<li>時間帯ごとの集計クエリの同時実行数</li>
<li>各集計クエリで使用しているslot</li>
<li>動的に生成される集計クエリそのもの</li>
</ol>
<p>1を確認したい理由はパフォーマンス確認の一つとしてです。<br>
2,3を確認したい理由は、BigQueryの制限によるものです。</p>
<p>Bigquery &gt; Documentation &gt; Quotas &amp; limits<br>
<a href="https://cloud.google.com/bigquery/quotas">https://cloud.google.com/bigquery/quotas</a></p>
<p>この中での<br>
<code>Concurrent rate limit for interactive queries — 100 concurrent queries</code><br>
が理由です。<br>
この制限に掛かっている場合、新規のインタラクティブ クエリを実行しようとすると強制的にエラーとなります。<br>
2は同時実行の数そもそもを確認して、現状で危険な時間帯はないかを確認するために必要です。<br>
3はこの制限にかかる潜在的なリスクを確認するためのものです。<br>
slotを使いすぎている集計が存在するとその集計がボトルネックとなり他の集計が終わらず同時実行数が増えてしまうことがあります。</p>
<p>4を確認したい理由は、何らかのバグを確認した場合やパフォーマンスが悪いことを確認した場合に該当のクエリがわからないと対策が打てないためです。<br>
変更のないクエリであれば問題になりませんが、動的にクエリを変更・生成している場合は重要です。</p>
<h3>BigQueryのデータアクセスログ</h3>
<p>上記で確認したい点はシステムからクエリを実行する以上、自前のログに書き込むことで確認は可能です。<br>
しかしBigQueryの監査ログには自動的に上記の確認したい情報が入るので自前で用意する必要がありません。</p>
<p>BigQueryを含めたGoogle Cloud サービスの監査ログ(Cloud Audit Logging)の詳細は次の公式ドキュメントが存在しています。</p>
<p>Stackdriver &gt; Documentation &gt; Logging &gt; Cloud Audit Logging<br>
<a href="https://cloud.google.com/logging/docs/audit">https://cloud.google.com/logging/docs/audit</a></p>
<p>この監査ログの中には以下の3つが存在しています。</p>
<ul>
<li>管理アクティビティログ</li>
<li>システムイベントログ</li>
<li>データアクセスログ</li>
</ul>
<p>このうちの<code>データアクセスログ</code>が上で記載している確認したいことをカバーしています。<br>
データアクセスログは各CRUD処理が全てログとして残ります。<br>
こうした特徴から出力する対象のサービスは任意で指定する必要がありますが、<br>
BigQueryに関しては標準で出力されています。</p>
<p>Stackdriver &gt; Documentation &gt; Logging &gt; Configuring Data Access Logs<br>
<a href="https://cloud.google.com/logging/docs/audit/configure-data-access">https://cloud.google.com/logging/docs/audit/configure-data-access</a></p>
<p>実際の確認方法は以下の2つです。</p>
<ol>
<li>Google Cloudが提供しているログビューワーからの確認</li>
<li>監査ログをGoogle Cloudサービスにエクスポートして確認</li>
</ol>
<p>推奨は2番目の<code>監査ログをGoogle Cloudサービスにエクスポートして確認</code>で、BigQueryに監査ログをエクスポートして確認することです。<br>
クエリで確認する情報を絞ることで調査を容易にすることにも繋げられる他、調査クエリを残しておくことで誰でも調査しやすい環境を作ることができます。<br>
ただしBigQueryで監査ログを確認していくには次の対応が必要となります。</p>
<p>BigQuery &gt; Overview &gt; Stackdriver Logging exports<br>
<a href="https://cloud.google.com/bigquery/docs/reference/auditlogs/#stackdriver-logging-exports">https://cloud.google.com/bigquery/docs/reference/auditlogs/#stackdriver-logging-exports</a></p>
<p>1のログビューワーでの確認は監査ログのデータ構成を確認するのに利用するのにおすすめです。<br>
これはBigQueryで監査ログを確認するにあたって監査ログのデータ構成を理解する必要があるためです。<br>
ログビューワーは次のURLで移動できます。<br>
<a href="https://console.cloud.google.com/logs/viewer">https://console.cloud.google.com/logs/viewer</a></p>
<h3>実際に活用しているクエリの紹介</h3>
<p>実際弊社で利用しているクエリを簡単にしたものを2つほど紹介します。<br>
{{}}で囲んでいるところを変更していただければ使えるようにしています。</p>
<h4>slotを消費しているクエリを確認する</h4>
<pre><code class="language-sql">WITH
{{project_id}} AS
(
  SELECT 
    '{{project_id}}' project_name,
    protopayload_auditlog.servicedata_v1_bigquery.*,
    protopayload_auditlog.serviceName as serviceName,
    protopayload_auditlog.methodName as methodName,
    protopayload_auditlog.resourceName as resourceName,
    timestamp
  FROM
    `{{project_id}}.{{dataset}}.cloudaudit_googleapis_com_data_access_{{timestamp}}`
),

{{project_id}}_COMPLETED_EVENT AS
(
  SELECT
    project_name,
    jobCompletedEvent.job.jobConfiguration.query.query as query,
    jobCompletedEvent.job.jobStatistics.createTime as jobCreateTime,
    jobCompletedEvent.job.jobStatistics.startTime as jobStartTime,
    jobCompletedEvent.job.jobStatistics.endTime as jobEndTime,
    jobCompletedEvent.job.jobConfiguration.query.queryPriority queryPriority,
    REGEXP_EXTRACT(jobCompletedEvent.job.jobConfiguration.query.query, &quot;\&quot;user\&quot;:\&quot;([^\&quot;]+)\&quot;&quot;) mode_user,
    jobCompletedEvent.job.jobStatistics.totalSlotMs as totalSlotMs,
    timestamp
  FROM
    {{project_id}}
  WHERE
    methodName = 'jobservice.jobcompleted'
)

SELECT
  FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', timestamp, 'Asia/Tokyo') timestamp_jst,
  TIMESTAMP_DIFF(jobEndTime, jobStartTime, MILLISECOND) / (1000 * 60) act_span,
  TIMESTAMP_DIFF(jobEndTime, jobCreateTime, MILLISECOND) / (1000 * 60) job_span,
  project_name,
  queryPriority,
  query,
  totalSlotMs,
  totalSlotMs / (1000 * 60 * 60) totalSlotHour,
  totalSlotMs / (1000 * 60 * 60 * 24) totalSlotDay
FROM
  {{project_id}}_COMPLETED_EVENT
ORDER BY totalSlotMs DESC
</code></pre>
<p>slotを消費した順にクエリを並べています。<br>
このクエリを元にして同時実行数が多くなっている時間帯を確認するなども行なっています。</p>
<h4>エラーを発生させたクエリを確認する</h4>
<pre><code class="language-sql">WITH
{{project_id}} AS
(
  SELECT 
    '{{project_id}}' project_name,
    timestamp,
    severity,
    protopayload_auditlog.servicedata_v1_bigquery.*,
    protopayload_auditlog.serviceName as serviceName,
    protopayload_auditlog.methodName as methodName,
    protopayload_auditlog.resourceName as resourceName
  FROM
    `{{project_id}}.{{dataset}}.cloudaudit_googleapis_com_data_access_{{timestamp}}`
),

{{project_id}}_COMPLETED_EVENT AS
(
  SELECT
    project_name,
    timestamp,
    severity,
    jobCompletedEvent.job.jobConfiguration.query.query as query,
    jobCompletedEvent.job.jobConfiguration.query.queryPriority queryPriority,
    jobCompletedEvent.job.jobStatus.error.message error_message,
    jobCompletedEvent.job.jobStatistics.totalSlotMs as totalSlotMs
  FROM
    {{project_id}}
  WHERE
    methodName = 'jobservice.jobcompleted'
    AND severity = &quot;ERROR&quot;
)

SELECT
  project_name,
  timestamp,
  severity,
  queryPriority,
  error_message,
  query,
  totalSlotMs
FROM
  {{project_id}}_COMPLETED_EVENT 
ORDER BY timestamp DESC
</code></pre>
<p>ユーザーの設定によって動的にクエリが生成される場合は意図していないエラーが発生することがあります。<br>
用意しておくことで調査をスムーズに進めることができています。</p>
<h3>まとめ</h3>
<p>BigQueryでは自動的に出力されている監査ログでも多くのことを調べることができるという紹介でした。<br>
実際に確認いただくと上で紹介した以外のことも確認できるということが見えてくるかと思います。<br>
BigQueryを利用したサービスを開発する上での参考になれば幸いです。</p>
<h3>最後に</h3>
<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>


Google Cloudサービスが提供しているBigQuery監査ログの活用方法。
実際に弊社で利用しているクエリも併せて紹介します。

BigQueryの監査ログは役に立つ | PLAID engineer blog

BigQueryの監査ログは役に立つ

<p>こんにちは！ エンジニアの@junkusaです。先日、PLAID社内で<a href="http://karte.io/">KARTE</a>のセキュリティをテーマにしたセキュリティハッカソンを実施しました。</p>
<h2>セキュリティハッカソンの目的と背景</h2>
<p>PLAIDは<a href="http://karte.io/">KARTE</a>という「リアルタイムユーザー解析プラットフォーム」を提供していますが、KARTEではさまざまな種類のデータを扱います。<br>
KARTEのデータを安全に扱うために、PLAIDでは外部のセキュリティの専門家などとも協力して取り組んでいます。<br>
また“セキュリティ組“というセキュリティ強化に取り組むチームもできました。セキュリティ組では開発者自身がより深くセキュリティに取り組むのを手助けしています。</p>
<p>開発者自身で深くセキュリティに取り組むには、セキュリティについて深く理解する必要があります。<br>
そのため、まず自社のサービスであるKARTEにおいて何を防がなくてはいけなくて、どのようなセキュリティホールが生まれる可能性があるかを知る機会が必要と考えました。<br>
そのセキュリティの知識を得る一つの方法として、セキュリティ組が中心となってKARTEを攻撃、防御したりするハッカソンを開いてみることにしました。</p>
<h2>セキュリティハッカソンの開催</h2>
<p>セキュリティハッカソンでは、Issueに当日のアジェンダや目的などを共有してから実施しました。<br>
セキュリティハッカソンでは、ローカル環境や試験環境などを使い、本番環境には影響がでないようにするという前提を周知しました。<br>
それ以外については基本的に自由にして、各自がKARTEに対して攻撃方法や防御方法を考え試して、成功失敗どちらの結果もハッカソンの終わりに共有することにしました。</p>
<blockquote>
<p>セキュリティハッカソンのIssue<br>
今回のセキュリティハッカソンは試験的なものであっため、短めの時間設定にしました</p>
</blockquote>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2d87f832-c886-4be3-b9b6-d8e5ec108da2/agenda.png" alt="agenda"></p>
<p>セキュリティハッカソンでは各自が考えていた攻撃方法などを試して、実際に問題があるかや対策されているかを確認していました。<br>
他にも、気になっていたセキュリティツールを試したり、普段開発して気になっていた部分を調べてみたりと攻撃以外のことも試されていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b4baa9f6-23f0-47f9-bf16-d2bee76d4fff/image.jpg" alt="セキュリティハッカソンの様子"></p>
<h2>セキュリティハッカソンの結果</h2>
<p>セキュリティハッカソンの終了後に、各自(各チーム)が試したことなどを共有しました。<br>
ハッカソンの中で見つけた問題についてはその場でIssueを作成し、ハッカソン後に修正や対策などに取り組んでいます。<br>
また、実際の脆弱性にはつながらなかった攻撃についても共有し、その攻撃からどのような問題につながる可能性があるかを議論しました。<br>
最後に、これらの結果を社内のesaにまとめ、ハッカソンに参加できなかった開発者にも共有しました。<br>
開発者からは「成果を共有されることで勉強になった」、「セキュリティに注目を集めるきっかけにもなるので継続的に開催したい」といった声が上がっていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/799b17d5-ebe1-4407-b92c-bf525c9fb9fc/security_result.png" alt="security_result"></p>
<h2>セキュリティハッカソンの後</h2>
<p>セキュリティハッカソンの目的は、開発者自身がどのようなセキュリティの問題がおきるかの可能性を知る機会を作ることでした。<br>
そのため、セキュリティハッカソンで見つかった問題(既に修正済み)を、発見者が実際にどのように見つけたを学ぶハンズオン形式の社内イベントも実施しました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f47e72c2-e115-413c-b36b-25896f87b371/hands_on.png" alt="hands_on"></p>
<p>脆弱性の見つけ方を学ぶハンズオンでは、<a href="https://portswigger.net/burp">Burp Suite</a>などのツールも使いつつ実際にローカル環境に向けて攻撃を行い、<br>
その攻撃によってどのような仕組みで問題が発生するかを体験できるようにしました。</p>
<p>また、流行した攻撃手法や脆弱性によってどのような被害が想定されるかも交えたデモなども行いました。<br>
たとえば、管理画面などログデータが表示される場所を狙ったBlind XSSでは、どのように効率的にデータを集めているかなどを実際に動かしながら見ていきました。</p>
<ul>
<li><a href="https://medium.com/bugbountywriteup/blind-xss-for-beginners-c88e48083071">Blind XSS for beginners – InfoSec Write-ups – Medium</a></li>
</ul>
<p>自分自身で攻撃を体験してみることで、脆弱性をもっと身近に感じて貰えるようにして、それらを意識して開発するという目的もあります。</p>
<h2>まとめ</h2>
<p>「セキュリティ」はとても大事ですが、何かできたから「完成」といったゴールがあるわけではありません。<br>
そのため、「セキュリティ」は継続的に改善していき、リスクを軽減や発見できるようにフィードバックループを回していく必要があると思います。<br>
PLAIDではこれからも開発者を巻き込みながら、「セキュリティ」改善へ向けてのアクションを続けていきます。</p>
<h2>最後に</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、継続的にセキュリティ改善に取り組んでいきたいというエンジニアを募集しています。<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>こんにちは、<a href="https://twitter.com/tarr1124">tarr</a> &amp; <a href="https://twitter.com/positiveflat">positiveflat</a>です。つい先日サンフランシスコで開かれたGoogle Cloud Next '19にPLAIDメンバー6人で参加してきたので、その時の話を書きたいと思います。</p>
<p>…とは言うものの、実はセッションはほぼ聞けなかったのでセッションの内容のシェアではなく、２つのセッションの<strong>スピーカーとして登壇</strong>したり、サンフランシスコに様々な関係者が集まるのでそれを利用して、<strong>様々な深い会話</strong>をすることを目的として参加してきました。</p>
<p>今回は、先週にかけて行われたGoogle Cloud Next '19に「PLAIDのメンバーがどういった動きをしたのか」を中心として、PLAIDがGoogleと深く関わりながらGoogleの技術を生かしてKARTEを実現している理由について説明していきます。</p>
<h2>スケジュール</h2>
<p>実際のスケジュールとしてはこんな感じです。2つのセッションに登壇したこと、GCPのPM達と交流を持ったこと、spotifyなどのBigTableのヘビーユーザー達のmeetupに参加したこと、あたりがハイライトです。</p>
<p>約2ヶ月前〜 ... 日本での事前準備</p>
<ul>
<li>Weekly hangout meeting with a BigQuery PM, Tino</li>
</ul>
<p>4/8(月)</p>
<ul>
<li>ビジネスヒアリング(1), ビジネスヒアリング(2)</li>
<li>Run through in Google SF Office</li>
<li>Dinner with 3 Google Product Managers (Sandy, Chad, Tino), Seth and Jordan Tigani(ペルー料理　ピースコーサワー)</li>
</ul>
<p>4/9(火) イベント開幕</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6357c27f-379b-4cb8-888d-cc55d546e435/IMG_1358.jpg" alt=""></p>
<ul>
<li>Googleとビジネスミーティング (1)</li>
<li><strong>セッション登壇 “PLAID’s journey to Global large scale real-time analytics with Google BigQuery”</strong></li>
<li>Googleとビジネスミーティング (2)</li>
<li>(ステーキ)</li>
</ul>
<p>4/10 (水)</p>
<ul>
<li>Googleとビジネスミーティング (3)</li>
<li>Google CRE Meeting</li>
<li>ビジネスヒアリング (3), ビジネスヒアリング (4)</li>
<li>Googleとテックミーティング (1)</li>
<li><strong>セッション登壇 “Building What's Next Together: Google Cloud and Technology Partners”</strong></li>
<li>Dinner with Google Cloud Japan team</li>
</ul>
<p>4/11(木)</p>
<ul>
<li>Googleとビジネスミーティング(4)</li>
<li>Meeting with a BigQuery PM, Chad</li>
<li>ビジネスヒアリング(5)</li>
<li>Googleとテックミーティング(2)</li>
<li>Meeting with a BigTable PM, Sandy</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/33d48bc8-f91a-4c65-8adc-e58e1c617a81/IMG_2579.png" alt=""></p>
<ul>
<li>BigTable user meetup</li>
<li>Twitter訪問</li>
<li>Dinner with Google Japanese Partners / シーフード in fisherman's wharf</li>
<li>夜食 in and out burger</li>
</ul>
<p>帰国後</p>
<ul>
<li>ビジネスヒアリング (6) - NYのとある会社とonline mtg</li>
</ul>
<h2>Google Cloudをさらに”深く”使い倒す</h2>
<p>KARTEのコア機能を下支えしている大部分はGCPによって構築されています。KARTEのシステムはGoogleの技術を最大限に利用しており、そして最近では、システムのみならず、ビジネスなどの多くの場面でGoogleと一緒にKARTEの価値を最大限に高めています。</p>
<p>PLAIDがGCPを利用する一つ目の理由は、Googleの尖った技術を使うことができることです。例えば、KARTEのリアルタイム解析では、ユーザーの行動を、そのユーザーの過去の解析済みデータと突き合わせて、解析をして、1秒以内にレスポンスを返すということをします。これには、低レイテンシー高スループットでアクセスができるデータベースが必要です。我々の要件を高いレベルで実現しているのはGoogleのBigTableです。他にも、BigQueryやML系のサービスなど、他のクラウドプロバイダーでは置き換えられないサービスがGCPには多数存在しています。Webで培われた超大量データをさばく技術を利用できるのがGCPの利用目的です。</p>
<p>その超大量データが処理できるプロダクトの魅力に加えて、組織的な魅力もGCPを活用する理由です。GCPのチームはエンジニアがプロダクトの責任を持っており、内部のエンジニアとの距離が近く感じることができます。各プロダクトの強みを理解して、スピーディーにプロダクトに生かすことができることもGCPを利用する目的の一つです。新しい機能の認知なども、プロダクトマネージャー中心にエンジニアチームがクライアントに直接行っていたり、βの機能などもエンジニアとのコミュニケーションですぐに触れるようになったりします。このような組織はエンジニアドリブンでプロダクトを開発しているPLAIDと非常に相性がよく、お互いに信頼しながら開発をすることができます。</p>
<p>今回のイベント参加の目的は、実は、セッションでヘビーユーザーとして知見を共有することに加え、この辺りのメリットをより深いものにするところにも狙いがありました。</p>
<h2>Google Cloud NextでのCTO牧野の登壇</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23bd3197-7fd0-495e-89c7-551f126f9231/IMG_1378.jpg" alt=""></p>
<p><a href="https://cloud.withgoogle.com/next">Google Cloud Next'19</a>は4/9-11にUSのSan FranciscoのMoscone Center(Steve JobsがiPhoneを発表した場所、というと分かりやすいかもしれません)で開かれました。今年のGoogle Cloud Nextには、世界中から<a href="https://cloud-ja.googleblog.com/2019/04/google-cloud-next19-welcome-to-the-future-of-digital-transformation.html">3万人以上のGoogle Cloud Platformの顧客とパートナー</a>が参加していたようです。</p>
<p>牧野が登壇したセッションのタイトルは「PLAID's Journey to Global Large-Scale Real-Time Analytics With Google BigQuery」で、BigQueryを使ったサービスを構築する場合のパターンを5つ紹介しました。セッションの開始前から事前予約に間に合わなかった人たちの長い行列ができ、会場は満員となっていました。</p>
<p>発表内容にはBigQueryをサービスの中心に組み込まないと得られない知見も含まれており、聴衆の反応を見ても非常に注目を感じました。セッション終了後も牧野に直接質問を投げかける人たちの輪ができており、GoogleのBigQueryのPM陣からも多くの素晴らしい言葉をいただけました。</p>
<p>このセッションを通じて、PLAIDはBigQueryのユーザー視点での情報提供をすることで、Google主催のイベントを盛り上げる手助けをすることができ、PLAIDとしても世界に我々の技術をアピールすることができました。</p>
<p>セッションの様子は以下の動画をご覧ください。</p>
<iframe width="480" height="270" src="https://www.youtube.com/embed/8UuiJjTW12Y?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<h2>GoogleのPM陣との交流</h2>
<p>Google Cloud Nextのセッションの内容はYouTubeで公開されており、情報のキャッチアップのみであればわざわざ現地に足を運ぶメリットは少ないです。それでも我々が現地に足を運ぶ理由は、Google Cloud Nextには多くのGCPユーザーやGoogleの開発者が集まっており、日本では難しいミートアップが簡単に実現するからです。</p>
<p>牧野の登壇の前日には、GoogleのSan FranciscoオフィスのシアタールームでRun throughを行い、その後BigQueryやBigTableのPMや開発者、Google Japanの社員の方々とディナーを共にしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/236b483c-1aa5-40ba-8607-0aabc9b36115/image-2.png" alt=""></p>
<p>このディナーの場で、BigQueryのPMに対して我々が直接会って話をすると面白そうな人がいないか聞いてみたところ、とあるUSのクライアントにその場でメールを送ってスピーディーに繋いでくれました。翌日にはその企業のCTOとお会いして、我々のビジネスと彼らビジネスの共通点や、市場環境についてディスカッションをしました。</p>
<p>また、上記のディナーとは別に、GoogleのBigQueryのPMや、BigTableのPMとそれぞれディスカッションする時間をとり、我々のプロダクトの説明や、feature request、プロダクトのフィードバックなどを行いました。</p>
<h2>PLAIDとGoogle Cloudのパートナーシップ</h2>
<p>技術面での連携だけでなく、ビジネス面でもPLAIDとGoogleは様々な連携をしています。我々は上記のようにKARTEのコアとしてGCPを大量に使っており、KARTEのクライアント企業は間接的にGCPのサービスを大量に使っているという構造を持っているからです。また、KARTEとGCPはサービスを提供しているレイヤーが異なるため、KARTEを通してGCPが直接リーチできないクライアント企業にアプローチをすることも、もちろんその逆も可能です。その利用規模に関しても決して小さくなく、例えば、今回の登壇の中でも触れていますが、KARTEは秒間65,000イベントをリアルタイムに処理すると共に、1PB/month にもなる全イベントをBigQueryにStreamingInsertしています。これは、KARTEが基本的に日本でしか展開していない、かつまだまだ成長の余地が大いにあるサービスであることを考えると、GCPの間接的なユーザーを今後大量に獲得するチャンスでもあります。</p>
<p>そういった観点に加えて、KARTEが急成長しているサービスであることからも、PLAIDはGoogle CloudにおけるSaaS Sales Alignment Program（SSAP）に認定されていて、KARTEを国内だけでなく国外にも広げる活動もCo-workしています。</p>
<p>その一つの例として、パートナーセッションでは、山田がプレイドとGoogleとの取り組みについての話をしました。アジアからGCPを使い倒しているひとつの事例としてKARTEが注目されていることを再認識できました。また登壇後は他のパートナーの方々と今後の成長を更にドライブさせるためのディスカッションができ、ミートアップなどのネクストアクションに繋げることができました。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/74094935-8181-4d86-aeb0-b0d8a4c8bd35/image-3.png" /><figcaption><strong>Building What's Next Together: Google Cloud and Technology Partners</strong></figcaption></figure>
<h2>まとめ</h2>
<p>以上のように、価値観とプロダクトの性質、ビジネス上の双方のメリットから、PLAIDはGoogleと密に連携をして、KARTEとGCPの価値を高めようとしています。その考え方を、Google Cloud Nextというイベントでの我々の動きを通して説明しました。</p>
<h2>最後に</h2>
<p>また、PLAIDではGCPなどのインフラの特性をフルに生かし、魅力的なプロダクトを作るエンジニアを募集しております。もし興味があれば、<a href="https://www.wantedly.com/projects/234957">こちら</a>からカジュアルに話を聞きに来てください！</p>


今回は、先週にかけて行われたGoogle Cloud Next '19に「PLAIDのメンバーがどういった動きをしたのか」を中心として、PLAIDがGoogleと深く関わりながらGoogleの技術を生かしてKARTEを実現している理由について説明していきます。

プレイドのCTOが登壇しました！ 〜Google Cloud Next '19 in SFレポート〜  | PLAID engineer blog

プレイドのCTOが登壇しました！ 〜Google Cloud Next '19 in SFレポート〜

<p>こんにちは、エンジニアインターン尾澤です。<br>
本記事では、PLAIDで経験した1年7ヶ月のインターンについてまとめたいと思います。<br>
インターンをやろうとしたきっかけ、PLAIDを選んだ理由、インターン内容、インターンで学んだことについてまとめました。</p>
<h3>はじめに</h3>
<p>まず初めに軽く自己紹介です。<br>
自分は大学では主に情報分野の授業を受け、暗号通信の研究をしました。<br>
2017年8月からインターンに参加させていただき、1年半以上仕事をしました。<br>
この度大学の卒業と就職に伴い、インターンを卒業させていただきます。<br>
卒業後は自動車業界で自動運転開発に携わることで、次世代モビリティの開発に関わりたいと考えております。</p>
<p>っとなんだかすごいように聞こえるような言い方をしましたが、このような目標を抱けるようになったのは、PLAIDでのインターンの経験が大きいと考えます。</p>
<h3>なぜインターンに参加したのか　〜技術力を付けるという側面〜</h3>
<p>大学入学時にこれからエンジニアとしてキャリアを進めたいと考えていたため、早いうちから専門を絞ろうと決め、インターネットの父と呼ばれる先生のもとで学べる研究室に所属しました。<br>
研究室で知り合った同期の中にはプログラミングができるだけでなくネットワークやハードウェアなど、情報分野の知識が豊富な学生がいました。<br>
（世の中には情報の授業でC言語などを触れる高校があるらしいですね……。）</p>
<p>一方の自分は情報の知識はまったくなく、大学に入学してからプログラミングを始めました。<br>
初めは大学でプログラミングの授業を受けておりましたが、研究室に所属してからは周囲の学生と大きな差を感じ、悔しい思いをしながら2年間学生生活を過ごしました。</p>
<p>この技術力のない自分を改善するため、というのがインターンを始める１つの理由でした。<br>
インターンに参加することで、実際の開発に携わり、エンジニアの方々と接することで技術力を高めようと考えました。</p>
<h3>なぜインターンに参加したのか　〜就活という側面〜</h3>
<p>正直な話をすると、技術力を付けるという理由だけでなく、インターンを就活にも活かそうと考えていました。</p>
<p>3年生になり、院進か就職の選択を決める時期が近づいた頃、周りの学生と同じく自分も院進をしようと決めていました。</p>
<p>初夏あたりで、友人と食事をしている時に将来について話したことがありました。<br>
自分は院進すると話しましたが、友人にはなんとなく院進しようとしていて本気で考えていない、と指摘されてしまいました。<br>
友人は当時、既にベンチャー企業でのエンジニアインターンに参加していたため、インターンに参加してみれば何かわかることがあるかもしれないと言われました。</p>
<p>友人の指摘を受け、夏休みにインターンに参加してみて、院進・就職を決める参考にしようと考えました。<br>
今思うと、院進するならあの時期ではもう内部進学しか残されていなかったなぁ……と考えますが…。</p>
<h3>なぜPLAIDでインターンをしたのか</h3>
<p>インターン参加を決めてからは、参加する企業として様々なベンチャー企業で面接を受けてみました。<br>
その中でPLAIDを選んだ理由は、面接時にエンジニアの方からKARTEに対する思いを聞けたからです。</p>
<p>他の会社は開発するシステム自体より、インターンとして出来ることを重点的に話して下さいましたが、インターンをしたことがなく、どんなことでもしてみたかったため、どんなシステムの開発に携われるかに興味がありました。</p>
<p>また開発するシステムをインターン生にもきちんと説明してくれるということは、システムに対する愛情や自信があるのかなと感じました。<br>
これは実際にインターンに参加してから確信に変わりました。<br>
業務内容に関わらず、社員全体のKARTEに対する共通の認識が存在することは、学生の自分でも感じることが出来ました。</p>
<p>ある程度軌道に乗った自社サービスがあるということも決め手でした。<br>
KARTEでは既に大元となるシステムが確立しているため、様々なシステムについて知ることが出来ました。<br>
受託開発を行う会社で仕事をしていた知人がいますが、受託開発では次第に似た実装を繰り返すようになってくるため、自社サービス開発を選ぶべきと言っていました。<br>
ちなみにこの友人はこの春に自社サービスをもつ会社へ転職するそうです。</p>
<p>でも1年7ヶ月ではそのほんの一部しか触ることが出来なかったです…。<br>
それほどKARTEはデカい!!</p>
<h3>インターンでやった仕事について</h3>
<p>インターンとしてやった仕事は、簡単なバグの修正から始まり、旧ページから新ページへの移行、新ページの作成、新規機能の追加までその時々の自分のレベルに見合った（ホントは結構背伸びしてた…）様々な開発です。<br>
最終的には自然言語処理に関する外部APIとの連携という自分には割と大きめな実装に携わりました。</p>
<p>共通して言えることは、全て0から自分で考えることが出来るということです。<br>
問題背景をissueという形で教えてもらいますが、それに対してどういうアプローチで解決するかは参考程度に意見を頂くだけで、あとは自分で考えるという流れでした。<br>
もちろん実装についてわからないことは何でも教えてもらえますが、まずは自分で考えるようにしていました。<br>
上からの指示に従わず、自由に実装できるという方法は自分をより成長させることが出来たと考えています。</p>
<p>また実際の実装状況を伝え、社員の方に考えや方針を変えてもらうこともよくありました。<br>
最初の実装方針より良い実装法を考えた場合に、社員の方と相談し、その実装法に変更することもよくありました。<br>
すなわち、インターンかどうかは関係なく、エンジニアとして対等に対話をしてくださいました。</p>
<h3>インターンで何を学んだか</h3>
<p>インターンを通して一番学べたことは、エンジニアとしての問題に対する姿勢です。<br>
開発する際に必要となる、実装法の考え方、周囲とのコミュニケーション、プロジェクトマネージメントについて学ぶことができました。</p>
<p>問題背景に対しどのようなアプローチで問題解決するかを決め、そのアプローチを効率良く、時には期限までに、不足する自分の知識をどう補いながら実装を進めるかを経験することが出来ました。<br>
1年7ヶ月で様々な形で経験させていただきましたが、まだまだ全く上手く機能していなく、改善点と学ぶべきことが山積みですが…!!</p>
<p>また会社の成長を身を持って体験することが出来ました。<br>
インターンに参加しはじめの頃は五反田オフィスであり、社員さんの数も今ほどいませんでしたが、毎月いろいろな経歴を持つ社員さんが参加し、途中で銀座オフィスへの引っ越しも経験出来ました。</p>
<p>その過程で様々な経験を持つ方々が会社として機能するために、意見を言い合い、会社として共通の認識を実現する過程は特に勉強になりました。<br>
自分もリーダーシップをとるような際は、様々な意見が出て、その意見をもとに議論し、共通の認識が生じるような環境にしようと思います。</p>
<p>技術力に関しては、当然向上することが出来ました。<br>
フルスタック開発をすることが出来るため、バックエンド処理の実装も行いました。<br>
自分の普段の開発はクライアントサーバーモデルで実現することはなかったので、バックエンドの実装を経験出来たのはとても有益でした。<br>
実プロダクトの開発を通して、授業で話に上がるような実装上の問題や解決法を具体的に理解できるようなこともありました。</p>
<p>周囲の学生とはプログラミング能力という側面では差を縮めることが出来ましたが、まだまだ肩を並べたられたかな？という程度だと思います。</p>
<p>現在の自分には到底及ばない技術力を持った、世界中のエンジニアと対等に実装が出来るよう、もっと学び、経験を積まなければならない!!</p>
<h3>インターンでやり残したこと</h3>
<p>様々な開発を経験しましたが、開発中におけるコミュニケーションがもっとできた思います。<br>
社員さんに質問すればすぐわかることなのに、自分で考えることに固執することで、無駄なことも多かったです。</p>
<p>この背景として、はじめは社員の方とのコミュニケーションの仕方がわからなかったです。<br>
issue上のgithubアカウントしかわからない、顔がわからない人に話しに行くことに、初めはためらってしまいました…。<br>
口頭で会話をしないためにissueの解釈を間違えることもありました。</p>
<p>今思うと、issueに取り掛かる前に、内容について口頭での軽い説明があるだけでもコミュニケーションしやすくなったと思います。<br>
自分が社員の方に実装のレビューをお願いする場合は、初めにレビュワーの方に軽く口頭で説明してからレビューをお願いするようにしていました。</p>
<p>issueをやっているうちに必然的にコミュニケーションするようになりましたが、コミュニケーションをとらなかった初めの時間は無駄だったと思います。</p>
<p>また、誰でも感じることだと思いますが、勉強です。<br>
最近ITパスポートの参考書を読んでみましたが、Iパスの勉強だけでも、KARTEの開発においてなるほど〜となることがとても多くありました。</p>
<p>もっと開発上の背景で用いられている技術や、実装する方法の基本的な内容を勉強しながらインターンに参加すれば、エンジニアの方とのコミュニケーションに無駄が生ぜず、開発の効率が上がったと思います。<br>
そうすればもっと様々なシステムに触れたかな。</p>
<p>仕事と同時に裏で基礎的な部分を勉強することで、のちの可能性が変わるということを、これからの仕事で活かしたいと思います。</p>
<h3>来たる次のインターン生へ</h3>
<p>自分にとって、求めることはすべて実現することのできる環境でした。<br>
それを実現するかどうかは自分がどう行動するかどうかです。</p>
<p>インターン参加当初に自分がやりたいことは全て出来ましたが、もっと出来ることは山ほど残っています。<br>
これはこれからのエンジニアとして仕事をする上での課題ですね。</p>
<p>自分は技術力の向上と将来の方針を決めることができたので、PLAIDでインターンに参加してよかったです。<br>
企業が行うようなサマーインターンなどのインターンは会社を知るにはとても良い一方、仕事体験はあまりできないと思います。</p>
<p>自分は将来やりたいことはなんとなく決まっており、就活で受ける企業はある程度絞っていたため、会社の雰囲気はOBの方との交流で満足に知ることが出来ました。<br>
以前自分が就職する予定の会社のインターン内容について聞いたことがありますが、とても面白そうでしたが、インターンの経験を将来に活かすという側面では、自分はPLAIDのインターンを選択して良かったなと感じました。</p>
<p>インターンをやるからには中途半端に参加するより、インターンに生活のウェイトをかけるべきだ思います。<br>
自分の場合は、学校の授業後などで大体週2・3日出勤しました。<br>
研究＝インターン&gt;趣味のバンド&gt;（大学の授業）、としていましたが、それでもやり残したことは山ほどあります。</p>
<p>少しでも多くのことを経験するためにも、常にどういうことを学ぶかという目標を立てながらインターンに参加すると良いと思います!!</p>
<h3>最後に</h3>
<p>1年7ヶ月のPLAIDでの経験は、今の自分を形成していると思うし、これからの人生でより活かしていくつもりです。</p>
<p>今の自分は自動車のIT化に携わることで、次世代モビリティを開発し、世界の抱える問題を解決することに志向しています。<br>
自動車が100年に一度の変革期であると言われている今、次世代モビリティの実現で自動車に新たな変化を起こすことがとても楽しみです。<br>
個人的にはもっと運転の楽しさを共有できれば良いですが…。<br>
今のようにこれからの道を描けるようになったのはPLAIDでインターンしたからです。</p>
<p>正直このブログを読んだだけではインターンのことはほとんどわかりません。<br>
しかし少しでもPLAIDのインターンに興味を持っていただけると幸いです。</p>
<p>これだけ言えることは、PLAIDのインターンに参加することで、得られきれないほど学べることがあることは確実です。</p>
<p>言い訳して行動しない理由を探してないで、さっさと行動を!!</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/463f1b7a-a9ca-44a5-9fd3-4c84fa470023/IMG_0660-6.JPG.jpg" /><figcaption>メンターの韓徹さん、尾澤、メンターの野田さんです。本当にお世話になりました!!</figcaption></figure>


プログラミング経験もほぼなかった自分がプレイドで1年7ヶ月エンジニアインターン参加し、経験を積み、どう成長したかについて書きました。

プレイドでの1年7ヶ月のインターンでどう成長できたか| PLAID engineer blog

プレイドでの1年7ヶ月のエンジニアインターンでどう成長できたか

<p>おはようございます！プレイドのエンジニアの <a href="https://twitter.com/jumpei_ikegami">@jumpei_ikegami</a> です。<br>
趣味は<a href="https://twitter.com/search?vertical=default&amp;q=%23%E3%81%97%E3%81%8C%E3%81%AA%E3%81%84%E3%83%A9%E3%82%B8%E3%82%AA&amp;src=tyah">ポッドキャスト配信</a>です。</p>
<p>さて、プレイドでは定期的に、開発チームで合宿に行っています。</p>
<p>現在は開発チームの規模としても、エンジニア約30人、デザイナー約10人と大きくなってきました。<br>
そこで今回は、あえて普段の開発から離れた視点で、「プロダクト」や「事業」や「それらを作るための組織」について、各自が興味あるテーマに沿ってディスカッションをしました。</p>
<p>前回に引き続き、世にも珍しい（？）「開発をしない開発合宿」でした。</p>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/42f378ec-90e8-4cb3-a08f-3ef881c9c089/MVIMG_20190214_074807_1.jpg" alt=""/>
  <figcaption>開発合宿では初の新幹線移動にはしゃぐメンバー</figcaption>
</figure>
<p>(過去の開発合宿のブログ記事は下記）</p>
<p>2016年:秋<br>
<a href="https://blog-plaid.com/event/2772/">PLAID Engineer Camp 2016 Autumn（開発合宿）に行ってきました！</a></p>
<p>2017年:春<br>
<a href="/plaid-developpers-camp-2017-spring/">山梨県河口湖に開発合宿へ行ってきました！ | PLAID engineer blog</a></p>
<p>2018年:春<br>
<a href="/plaid_developpers_camp_2018_spring/">1泊2日ぶっ通しで議論する開発合宿をしに、館山に行ってきました！</a></p>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b4dbd032-0572-4639-854c-685c854604f3/IMG_20190214_104921-1.jpg" alt=""/>
  <figcaption>いまだ雪残る金沢</figcaption>
</figure>
<h1>目的</h1>
<p>今回の合宿の目的は、「普段、話してないことを話す/議論する」でした。</p>
<p>開発チームでは、普段はリアルタイムユーザー解析サービス『<a href="https://karte.io/">KARTE</a>』の開発をしています。日々の業務では、どうしても目先の開発タスクや短期的な売上の話に引っ張られがちです。プロダクトや事業を見る視点を変え、全体を俯瞰的な視座に立ってみたり、切り口を変えてみたりすることで、「自分たちが間違った方向に進んでいないか？」をチェックするいい機会になりました。</p>
<p>特に合宿という機会を議論の場として使うのは、以下の2点で良いと思います。</p>
<ul>
<li>参加メンバーを定常業務から切り離すので、まとまった時間を確保しやすい</li>
<li>オフィスから距離的に離れているので、発想を飛ばしやすい</li>
</ul>
<p>また、今回は温泉宿に泊まったのですが、思考を強制的にオフにする装置として、温泉は最高でした。</p>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d12d4d45-4253-4745-831c-0e338cfd5fa5/MVIMG_20190214_104926.jpg" alt=""/>
  <figcaption>金沢湯涌温泉の「湯の出旅館」</figcaption>
</figure>
<h1>議論したテーマ</h1>
<p>「プロダクトに関連するトピックならなんでもあり」というゆるい枠の中で、参加メンバー各自が議論テーマ案を考えました。その案をホワイトボードに貼り出し、投票やメンバーの熱意の高さで、以下の6つに絞りました。</p>
<ol>
<li>BtoCのサービス</li>
<li>世界を獲る方法</li>
<li>お金</li>
<li>心理的安全性/個人の成長と生産性</li>
<li>データへの感情移入</li>
<li>KARTEをディスラプトする破壊的イノベーション</li>
</ol>
<p>それぞれの議論の内容について、表に出せる範囲でご紹介します。</p>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7d0cfc57-7dc1-4537-b172-f0bc31c95356/IMG_20190214_105223-1.jpg" alt=""/>
  <figcaption>溢れ出る法事感</figcaption>
</figure>
<h2>BtoCのサービス</h2>
<p>プレイドが開発しているメインのプロダクトであるKARTEは、BtoBサービスとして提供しています。そこで、もしプレイドがBtoCのサービスを作るとしたら何をするか、どんなメリットがあるか、などを話し合いました。</p>
<ul>
<li>KARTEが目指す「エンドユーザー中心のサービス体験」を体現したWebサービスを、KARTEをフル活用して実現してみたい
<ul>
<li>さらには、カフェなど実店舗も運営して、オンラインとオフラインを統合した体験を全力で検証、提供してみたい</li>
</ul>
</li>
<li>KARTEを本気でドッグフーディングしたい
<ul>
<li>目的をもって実際に使ってみることで、KARTEの本質的な価値やユーザーのpainを実感できる</li>
<li>「KARTEの理想の使い方」を示すショーケースを自分たちで作って示すことで、良いKARTEユーザーを増やせる</li>
</ul>
</li>
</ul>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4935e455-455d-4fce-89c1-06ff72257fd1/IMG_20190214_151451.jpg" alt=""/>
  <figcaption>白熱する議論、減るお菓子</figcaption>
</figure>
<h2>世界を獲る方法</h2>
<p>KARTEのクライアントは、まだ日本の企業がほとんどです。そこで、もしプレイドが「世界を獲った」と言える状況になったとしたら、どのような手段によって実現できそうかをゼロベースで議論しました。</p>
<ul>
<li>そもそも「世界を獲れている会社」とはどこか？
<ul>
<li>GAFA</li>
<li>Slackは、世界を取るための挑戦権を獲得している印象</li>
</ul>
</li>
<li>toBで世界を獲るとしたら、どちらのアプローチを取るか？
<ul>
<li>ビジネス向け？ / デベロッパー向け？</li>
</ul>
</li>
<li>常識的なことをやっていても、成長角度を圧倒的に上げることはできない</li>
<li>事業やプロダクトに関する熱い議論を、もっとプレイドのメンバーとしたい</li>
</ul>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a0887d2e-660c-4732-9e46-66a8d1211794/IMG_20190215_114429.jpg" alt=""/>
  <figcaption>思ったより雪がない近隣</figcaption>
</figure>
<h2>お金</h2>
<p>プレイドのエンジニアは、普段の仕事では特に売上に対する直接の責任を追っているわけではありません。そこで、あえて「お金」という切り口でプロダクトや事業について考えました。</p>
<ul>
<li>KARTEの機能の中で、お金になる機能とならない機能の違いは？</li>
<li>KARTEの適正価格とはどのくらいか？
<ul>
<li>「その価格を払ってもいい」と思えるほど価値を感じてもらうにはどうするか？</li>
</ul>
</li>
</ul>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/af24ad1d-12fb-4c4d-a02e-9d417dfbb566/IMG_20190214_190246.jpg" alt=""/>
  <figcaption>夕食（美味しい）</figcaption>
</figure>
<h2>心理的安全性/個人の成長と生産性</h2>
<p>プレイドでは「メンバーの創造力を信じる」という価値観を標榜し、「信じて任せる」という文化があります。しかし、その文化に甘えすぎてしまうと個人の成長や心理的安全性を最大化できないのではないか、という懸念も一方であります。その辺りのモヤモヤについて、議論しました。</p>
<ul>
<li>心理的安全性と個人の成長は、必ずしも相関しないのではないか？
<ul>
<li>障害対応など、心理的な負荷が高いときの方が成長する気がする</li>
<li>ただし、心理的安全性が高い方が生産性が高いと感じる</li>
</ul>
</li>
<li>個人の成長を組織としてケアするとしても、最終的には、成長や生産性には自分で責任をもつしかない
<ul>
<li>ただし、フィードバックの仕組みは、もう少し厚めに用意してもいいかもしれない</li>
</ul>
</li>
</ul>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/eff200d1-2d99-4bf6-912d-e5810ee4109f/IMG_20190215_073232.jpg" alt=""/>
  <figcaption>朝食（美味しい）</figcaption>
</figure>
<h2>データへの感情移入</h2>
<p>プレイドやKARTEの大きなテーマは、「データを活用し人を徹底的に可視化すること」です。その過程で生まれた疑問である「データをどう集めてどう見せられたら、そのデータに感情移入できるようになるのか」について、議論しました。</p>
<ul>
<li>データは人の感情や行動を定量化したものなので、本質的には「好き」になれるはず</li>
<li>KARTEで人の「顔」が見えると、サイトやアプリのユーザーに対しても「人とやりとりしている」と思える</li>
<li>むしろ、人間側の感覚を拡張して、データの見方を変えることはできないか？</li>
<li>そもそも人間が人間に対するときに処理しているデータと比べて、圧倒的にデータが不足している</li>
</ul>
<figure style="text-align: center;">
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d5c10ee7-336c-40b9-bcc5-185a94103fc4/hanetsuki.gif" alt=""/>
  <figcaption>議論に煮詰まって、近所で羽根つきをする様子</figcaption>
</figure>
<h2>KARTEをディスラプトする破壊的イノベーション</h2>
<p>KARTEは技術やプロダクトデザインの観点で一定のユニークさを維持しています。もし別のスタートアップが破壊的イノベーションを実現し、KARTEを追い越すような存在になるとしたら、どのような手段によってか。そんな妄想を膨らませ、議論しました。</p>
<ul>
<li>KARTEがまだ実現できていないレベルで「ユーザーを圧倒的に知る機能」を実装されると厳しいかもしれない</li>
<li>そもそも、事業体毎に個別のWebサイトやアプリを作るのが当たり前じゃなくなったら、市場的にはシュリンクする
<ul>
<li>たとえば、全てのECサイトがAmazonに統合されるとか、すべてのメディアがFacebookに乗っかるとか</li>
</ul>
</li>
<li>KARTEの設定が複雑化しているので、シンプルさを保った上でやりたいことが自由にできる類似プロダクトが出てきたら大変かもしれない</li>
</ul>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/592c76a7-75cf-4f3e-b007-cb17b4f7a91f/IMG_20190215_163615.jpg" alt=""/>
  <figcaption>金沢名物のどぐろ（とても美味しい）</figcaption>
</figure>
<h1>まとめ</h1>
<p>上記を見てもわかるように、思考を立脚させる点を遠くに飛ばして、暗黙の前提や固定観念を取っ払った議論ができたと思います。それも、地理的に金沢という東京から遠い場所に来たということが大きな理由になっている気がしました。</p>
<p>日々の業務に囚われて近視眼的になりがちですが、プロダクトの本質的な価値は何か、自分たちが何を目指しているのか、常に立ち返って開発上の意思決定をできるように、これからも定期的に長期目線の議論をしていきます。</p>
<figure>
  <img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d2ceac63-3571-4552-96e2-42948eaea17e/IMG_6482-1.jpg" alt=""/>
  <figcaption>約30人の開発メンバーで集合写真</figcaption>
</figure>
<h4>最後に</h4>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、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>


金沢湯涌温泉に「開発をしない開発合宿」にいきました。プロダクトや事業に関する長期的な議論をすることで、「自分たちが間違った方向に進んでいないか？」をチェックするいい機会になりました。また、今回は温泉宿に止まったのですが、思考を強制的にオフにする装置として、温泉は最高でした。

開発合宿@金沢湯涌温泉で、目線を上げるための議論を2日間してきました！ | PLAID engineer blog

開発合宿@金沢湯涌温泉で、目線を上げるための議論を2日間してきました！

<p>こんにちは。エンジニアの mario です。こちらの記事は<a href="https://qiita.com/advent-calendar/2018/plaid">PLAID Advent Calendar</a> 2018 22日目の記事でもあります。<br>
普段の業務では、ネイティブアプリ向けのSDK (以降 KARTE SDK と呼ぶ) の開発をしています。</p>
<p>今回は、新卒の私がKARTE SDKの開発を通して感じた、テストコードを書くことの重要性とテスト設計について、そこに至った思考を交えながら書きたいと思います。<br>
また、私自身新卒としてSDKの開発を通して学んだこと、実際のテストコードの一部伐採したものもまとめたいと思います。</p>
<h2>KARTE SDKとは</h2>
<p>KARTE SDKとはアプリに組み込むことで、管理画面でHTML/CSS/JavaScriptで記述されたアクションをアプリ内メッセージ（ポップアップやバナー、アンケート等）として表示する機能を持っています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4434d4a7-2b68-4510-943d-77c4bdb084f1/----------0030-12-22-16.27.18.png" alt="----------0030-12-22-16.27.18"></p>
<h2>SDK開発におけるテストの重要性</h2>
<p>私は学生の時に、Q&amp;Aアプリのサービスを有志で集まった学生4人で開発した経験があります。その時は、開発スピードを優先し最低限動くアプリを作り、リリース後にバグを埋めていくという流れで開発を進めていました。</p>
<p>そんな経験もあり、新卒として4月に入社し、SDKの開発を行うことになりテストを書いてくれと言われた際、「なぜテストを書く必要があるんですか？」と生意気ながら質問したことがあります。この時の自分としてはただ純粋に、テストを書くより機能を充実させたいという思いがありました。<br>
しかし、「その気持ちはわかる。でも、土台が整わないうちに攻めてものちのち崩れるだけ。後からテストの必要性に気付いた時にはもう遅い」と実際の経験を踏まえた重い回答をもらい、テストを書くことを決めました。<br>
ただ、テストを書いたからと言ってバグの報告が全くなるなるということはなく、問い合わせがある度に、調査のため開発の手が止まってしまいます。その度に、しっかりテスト・確認をしていればと後悔します。</p>
<p>しかし、テストがなかった頃よりは明らかに問い合わせの量も減り、順調に開発を進めることができています。テストに対する意識がSDKの開発を通して大きく変わりました。</p>
<p>KARTE SDKの開発チームで決めたテストの方針と設計について以降述べていきたいと思います。</p>
<h2>テストの方針を決めるための背景・前提</h2>
<p>テストの方針を以下の４つの背景を前提として決定しました。</p>
<h4>(1) KARTE SDK が満たすべき品質レベルは、KARTE 内の他の機能と比べて高い</h4>
<ul>
<li>ネイティブアプリは Web アプリと比べて障害発生時のリカバリに時間がかかる<br>
（申請・リリース作業などに時間がかかるため）</li>
<li>ネイティブアプリは Web アプリと比べて障害発生時の機会損失が大きくなりやすい<br>
（起動しないような状態だと、アプリが全く使えない状態になってしまうため）</li>
</ul>
<h4>(2) 開発スピードはできるかぎり落としたくない</h4>
<ul>
<li>攻めの開発をすることを第一目的においた上で、守りのテストをしたい</li>
<li>サービスとしての勢いに乗るためには守りより攻めを第一におきたい</li>
</ul>
<h4>(3) KARTE SDK に手を入れなくても障害が発生するリスクがある</h4>
<ul>
<li>新規で始まったSDK開発に対する意識はエンジニア全体的にみるとまだ低いため、リクエスト・レスポンス形式に破壊的な変更が行われる可能性がある</li>
</ul>
<h4>(4) KARTE SDK の開発スキル・ナレッジは属人化しやすい</h4>
<ul>
<li>エンジニア全員がウェブとアプリ両方のプロダクト開発、テストが行える状態に近づけないとスケールしない</li>
</ul>
<h2>SDK のテスト設計</h2>
<p>テストの設計については色々と議論がありましたが、最終的には以下の6種類にまとめた設計となりました。</p>
<table>
<thead>
<tr>
<th>テストの種類</th>
<th>対象</th>
<th>観点</th>
<th>全体的な方針</th>
<th>タイミング</th>
</tr>
</thead>
<tbody>
<tr>
<td>単体テスト</td>
<td>クラスに定義された関数・メソッド</td>
<td>関数・メソッドが仕様通りに正しく実装されているか<br>  (ホワイトボックステスト)</td>
<td>- 関数の外部仕様（INPUT / OUTPUTのペア）に対してテストを書く<br>- 内部実装に依存したテストを書かないようにし、リファクタリングを行いやすくする</td>
<td>対象モジュールの修正コミットがPush されたタイミング</td>
</tr>
<tr>
<td>内部結合テスト</td>
<td>ビルドされたモジュール</td>
<td>モジュールがモジュール外部に公開された仕様通りの挙動をするかどうか (ブラックボックステスト)</td>
<td>モジュール外に公開されている仕様・インターフェースに対して正常形、異常形を含めた網羅的なテストを書く</td>
<td>対象モジュールの修正コミットがPush されたタイミング</td>
</tr>
<tr>
<td>外部結合テスト</td>
<td>複数モジュール間の連携</td>
<td>あるモジュールの修正によって、他のモジュールの動作に破壊的な影響を与えていないか</td>
<td>複数モジュール間の連携について、あるモジュールが別のモジュールを参照する際のパラメータに対して、期待した結果が別のモジュールから得られるかどうかに対してテストを書く</td>
<td>- 対象モジュールの修正コミットがPush されたタイミング<br>- 連携先モジュールの修正コミットがPushされたタイミング</td>
</tr>
<tr>
<td>E2Eテスト</td>
<td>システム全体</td>
<td>- システムを使って重要なユーザーシナリオを正しく実施できるかどうか<br>- サポート対象の OS /デバイス、過去バージョンのSDKでシステム全体が動作するかどうか</td>
<td>- 正しく動作しないとクライアント / プレイドが大きな機会損失を受けるリスクが大きい機能を「重要機能・シナリオ」として定義し、その機能が全てのサポートするデバイス / OS上で正常に動作していることを検証する。<br>- テストの実装コスト、メンテナンスコストが高いため、テストの量が増えすぎないようにする。他のテストで検証可能な観点はE2Eテストとして実装しない（モジュール・関数の細かい異常系テストなど）</td>
<td>コミットがPush されたタイミング</td>
</tr>
<tr>
<td>デプロイ前確認テスト</td>
<td>evaluation環境にデプロイされたシステム全体</td>
<td>- デプロイが正しく行われているかどうか<br>- 開発・テスト環境と環境差分が存在する設定項目についての挙動が正しいかどうか</td>
<td>ほとんど全ての不具合は E2Eテスト以前の修正がマージされる前の段階で検知されるべきであるため、デプロイ前確認にテストケースを追加するのは最終手段</td>
<td>本番デプロイ前</td>
</tr>
<tr>
<td>リリース後確認テスト</td>
<td>リリースされたSDK</td>
<td>- リリースされたSDKを開発者が正しくアプリに組み込めるかどうか<br>- 本番デプロイによって、本番のネイティブアプリに対して破壊的な影響を与えていないかどうか</td>
<td>モジュール / パッケージ管理システムから正しくSDKがダウンロードし、アプリに組み込めるか</td>
<td>本番デプロイ後</td>
</tr>
</tbody>
</table>
<h2>テストコード一部紹介</h2>
<p>内部結合テストの一部のコードを抜粋して掲載します。<br>
以下のテストは、KARTE SDKから画面遷移等のイベントをtrackする際に、自動で付与されるデバイスデータが公開されたドキュメント通り正しく付与されているかをテストしたコードになります。<br>
少しでも品質を上げるために、機能が追加されるたびにテストコードを書いているため、コストはかかりますが、絶対に必要な工程だと私はPLAIDにきて学びました。</p>
<pre><code class="language-obj-c">describe(@&quot;KarteTracker&quot;, ^{
    describe(NSStringFromSelector(@selector(track:values:)), ^{
        __block NSDate *now;
        __block NSString *versionName;
        __block NSString *versionCode;
        __block NSString *systemVersion;
        __block NSString *model;
        __block NSString *bundleIdentifier;
        __block NSString *uniqueIdentifier;
        __block NSString *version;
        
        __block id dateMock;
        __block id appProfileMock;
        __block id uuidMock;
        __block id idfaMock;
        __block id deviceMock;
        __block id bundleMock;
        __block id trackerMock;

        __block NSDictionary *values;
        
        beforeAll(^{
            now = [NSDate date];
            versionName = @&quot;1.0.0&quot;;
            versionCode = @&quot;1&quot;;
            systemVersion = @&quot;11.3&quot;;
            model = @&quot;iPhone&quot;;
            bundleIdentifier = @&quot;io.karte.tracker.empty&quot;;
            uniqueIdentifier = @&quot;0000000-0000-0000-0000-000000000000&quot;;
            version = @&quot;1.0.0&quot;;
            
            dateMock = OCMClassMock([NSDate class]);
            OCMStub([dateMock date]).andReturn(now);
            
            KarteTrackerAppProfile *appProfile = [[KarteTrackerAppProfile alloc] init];
            
            appProfileMock = OCMPartialMock(appProfile);
            OCMStub([[appProfileMock alloc] init]).andReturn(appProfile);
            OCMStub([appProfileMock currentVersionName]).andReturn(versionName);
            OCMStub([appProfileMock currentVersionCode]).andReturn(versionCode);
            
            id uuid = [NSUUID UUID];
            uuidMock = OCMPartialMock(uuid);
            OCMStub([uuidMock UUIDString]).andReturn(uniqueIdentifier);
            
            idfaMock = OCMPartialMock([ASIdentifierManager sharedManager]);
            OCMStub([idfaMock advertisingIdentifier]).andReturn(uuid);
            
            deviceMock = OCMPartialMock([UIDevice currentDevice]);
            OCMStub([(UIDevice *)deviceMock systemVersion]).andReturn(systemVersion);
            OCMStub([deviceMock model]).andReturn(model);
            OCMStub([deviceMock identifierForVendor]).andReturn(uuid);
            
            bundleMock = OCMPartialMock([NSBundle mainBundle]);
            OCMStub([bundleMock bundleIdentifier]).andReturn(bundleIdentifier);
            
            trackerMock = OCMClassMock([KarteTrackerVersion class]);
            OCMStub([trackerMock version]).andReturn(version);
            
            KarteTracker *tracker = [KarteTracker setupWithAppKey:kAppKey withConfig:[KarteTrackerConfig configureWithBuilder:^(KarteTrackerConfigBuilder * _Nonnull builder) {
                builder.enabledTrackingAppLifecycle = NO;
                builder.enabledTrackingAppOpen = NO;
            }]];
            
            NSString *name = @&quot;test_event&quot;;
            HookTracking(name, ^{
                [tracker track:name values:@{@&quot;num&quot;: @100,
                                             @&quot;str&quot;: @&quot;hoge&quot;,
                                             @&quot;date&quot;: [NSDate date],
                                             @&quot;dic&quot;: @{@&quot;key&quot;: @&quot;value&quot;},
                                             @&quot;arr&quot;: @[@&quot;value1&quot;, @&quot;value2&quot;]}];
            }, ^(NSURLRequest *request, void (^completionHandler)(NSData *, NSURLResponse *, NSError *)) {
                values = GetEventValues(name, request);
            });
        });
        
        afterAll(^{
            [dateMock stopMocking];
            [appProfileMock stopMocking];
            [uuidMock stopMocking];
            [idfaMock stopMocking];
            [deviceMock stopMocking];
            [bundleMock stopMocking];
            [trackerMock stopMocking];
            [KarteTracker teardownWithAppKey:kAppKey];
        });
        
        it(@&quot;イベント発生時刻が_event_local_dateパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect([values[@&quot;_event_local_date&quot;] doubleValue]).to.equal([now timeIntervalSince1970]);
        });
        
        it(@&quot;イベント発生時刻が_local_event_dateパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect([values[@&quot;_local_event_date&quot;] doubleValue]).to.equal([now timeIntervalSince1970]);
        });
        
        it(@&quot;バージョン番号がversion_nameパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;version_name&quot;]).to.match(versionName);
        });
        
        it(@&quot;ビルド番号がversion_codeパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;version_code&quot;]).to.match(versionCode);
        });
        
        it(@&quot;SDKバージョンがkarte_sdk_versionパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;karte_sdk_version&quot;]).to.match(version);
        });
        
        it(@&quot;OS名がosパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;system_info&quot;][@&quot;os&quot;]).to.match(@&quot;iOS&quot;);
        });
        
        it(@&quot;OSバージョンがos_versionパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;system_info&quot;][@&quot;os_version&quot;]).to.match(systemVersion);
        });
        
        it(@&quot;デバイス名がdeviceパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;system_info&quot;][@&quot;device&quot;]).to.match(model);
        });
        
        it(@&quot;バンドルIDがbundle_idパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;system_info&quot;][@&quot;bundle_id&quot;]).to.match(bundleIdentifier);
        });
        
        it(@&quot;端末識別番号がidfvパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;system_info&quot;][@&quot;idfv&quot;]).to.match(uniqueIdentifier);
        });
        
        it(@&quot;広告IDがidfaパラメータとしてtrackサーバに送信されること&quot;, ^{
            expect(values[@&quot;app_info&quot;][@&quot;system_info&quot;][@&quot;idfa&quot;]).to.match(uniqueIdentifier);
        });
...
</code></pre>
<h2>まとめ</h2>
<p>本記事では、PLAIDの新卒エンジニアとして8ヶ月働いたことで私がSDKの開発を通して学んだことや、SDK開発の中で行なっているテスト方針・設計についてまとめました。</p>
<p>この記事はPLAIDにおけるSDK開発のテスト思考についてまとめたものですが、サービスを開発する上での参考になればと思います。</p>
<h2>最後に</h2>
<p>リアルタイム解析を実現するCXプラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、アプリ・SDKエンジニア（インターンも！）を募集しています。</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>


新卒一年目エンジニアがSDK開発で学んだテストの重要性と設計 | PLAID engineer blog

新卒一年目エンジニアがSDK開発から学んだテストの重要性と設計

Engineer Blog

Recent Article

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

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

技術イベント『#PlaidTechLounge』を開催しました！

DeNA、Googleと共同でGCP勉強会を開催しました！

BigQueryの監査ログは役に立つ

社内セキュリティハッカソンと脆弱性体験ハンズオンを開催しました

プレイドのCTOが登壇しました！〜Google Cloud Next '19 in SFレポート〜

プレイドでの1年7ヶ月のエンジニアインターンでどう成長できたか

開発合宿@金沢湯涌温泉で、目線を上げるための議論を2日間してきました！

新卒一年目エンジニアがSDK開発から学んだテストの重要性と設計

Archives

Writers

Recent Article

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

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

技術イベント 『#PlaidTechLounge』を開催しました！

DeNA、Googleと共同でGCP勉強会を開催しました！

BigQueryの監査ログは役に立つ

社内セキュリティハッカソンと脆弱性体験ハンズオンを開催しました

プレイドのCTOが登壇しました！ 〜Google Cloud Next '19 in SFレポート〜

プレイドでの1年7ヶ月のエンジニアインターンでどう成長できたか

開発合宿@金沢湯涌温泉で、目線を上げるための議論を2日間してきました！

新卒一年目エンジニアがSDK開発から学んだテストの重要性と設計

Archives

Writers

技術イベント『#PlaidTechLounge』を開催しました！

プレイドのCTOが登壇しました！〜Google Cloud Next '19 in SFレポート〜