Engineer Blog

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

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


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

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

<p>プレイドが提供するKARTEでは、エンドユーザの行動データを活用するためにさまざまな分析機能を提供しています。データベースの裏側を支えるデータ構造も多種多様で、それらを正しく理解し活用していくことは分析サービスを提供する上で非常に重要です。</p>
<p>この記事ではBitmap Indexにフォーカスし、ナイーブなBitmap IndexとRoaring BitmapやBit-Sliced Indexについて解説します。</p>
<p>弊社の記事で手前味噌ですが、分析向けデータベースの技術全般については以下の記事も非常に参考になるのでオススメです。<br>
<a href="https://tech.plaid.co.jp/fundamentals_of_olap_db_technology">OLAP DBの技術要素の基礎</a></p>
<h2>ナイーブなBitmap Index</h2>
<p>最も基本的なBitmap Indexは、カラム内の特定の値ごとに一つのビットマップを持つ構造です。このビットマップでは、各ビットがテーブル内の一つの行（行番号）に対応します。その値を持つ行であればビットを1、持たなければ0とします。</p>
<p>例えば商品テーブルに「商品カテゴリ」というカラムがあり、以下のデータが入っているとします。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>商品カテゴリ</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>トップス</td>
</tr>
<tr>
<td>1</td>
<td>トップス</td>
</tr>
<tr>
<td>2</td>
<td>トップス</td>
</tr>
<tr>
<td>3</td>
<td>ボトムス</td>
</tr>
<tr>
<td>4</td>
<td>ボトムス</td>
</tr>
</tbody>
</table>
<p>この商品カテゴリカラムに対してBitmap Indexを作成すると、以下のようになります。</p>
<ul>
<li>トップス: <code>11100</code> (0, 1, 2番目の行がトップス)</li>
<li>ボトムス: <code>00011</code> (3, 4番目の行がボトムス)</li>
</ul>
<p>最大の利点はANDやORをBit演算で高速に計算できることです。<br>
例えば、「トップスまたはボトムスの商品を抽出する」場合、<code>11100</code> OR <code>00011</code> = <code>11111</code><br>
となり、全ての行が該当することが分かります。</p>
<p>また、該当するエントリ数の算出はpopcntでできてしまいます。</p>
<p>主な弱点は以下です。</p>
<ul>
<li>サイズが大きくなりやすい
<ul>
<li>カーディナリティ(カラム内のユニークな値の数)の分ビットマップを持たなければならず、特にカーディナリティが高い時に大きくなります。</li>
<li>値がスパースな時に非効率です。例えば100万行の商品テーブルで「虹色」の商品が1つだけある場合、「虹色」のビットマップは「00...010...00」のようにほとんどが0で占められます。これなら、単に対応する行番号のリスト（例：<code>[2500]</code>）で持つ方がはるかにコンパクトです。</li>
<li>(基本的にはカーディナリティが高いカラムはスパースな値が多いです。多値型の場合はその限りではありませんが)</li>
</ul>
</li>
<li>範囲検索が非効率
<ul>
<li>例えば商品価格のような値に対してBitmap Indexをそのまま使って「1000円以上の商品」を検索する場合、1000円、1001円、1002円… といった個別の価格に対応する全てのビットマップを取得し、ORを取らなければなりません。</li>
</ul>
</li>
</ul>
<h2>Roaring Bitmap</h2>
<p>Bitmapの良さを活かしつつ弱点を克服するためのフォーマットがいくつかあります。有名なものがWAH (Word Aligned Hybrid), Concise Bitmap, そしてRoaring Bitmapです。<br>
雑にまとめるとどの手法も、決まった方針でBitmapを分割して、1と0が満遍なく混在するパーツは純粋なBitmapとして扱いつつ、スパースなパーツは行IDのリストやRun-Length Encodingで保持する、という仕組みです。</p>
<p>OLAP分野だとRoaring Bitmapが特に人気なようで、IndexにはRoaring Bitmapが優先されることが多いと思います。以下はRoaring Bitmapについて説明します。</p>
<h3><strong>Roaring Bitmapの仕組み</strong></h3>
<p>Roaring Bitmapでは、Bitmapを最大65,536(2^16)個の要素で構成されるコンテナに分けます。コンテナはBitmap / Arrayのどちらかで表現します。</p>
<ul>
<li>Bitmap: スパースではない場合、65,536ビット（8KB）のビットマップとして格納します。</li>
<li>Array: スパースな場合(デフォルトでは1が4096個以下)、要素の値を整数のソート済み配列としてそのまま格納します。</li>
</ul>
<p>(進化版ではRun-Length Encodingという3種類目のコンテナもありますが、今回は割愛します。)</p>
<p>AND/ORなどの論理演算はコンテナ単位で行われ、コンテナの組み合わせごとにアルゴリズムがあります。例えばAND演算は以下です。</p>
<ul>
<li>Bitmap vs Bitmap: 通常のビットワイズAND演算。</li>
<li>Bitmap vs Array: Array内の各要素について、Bitmapの対応するビットを確認。</li>
<li>Array vs Array: ソート済み配列同士のマージ処理に似た方法で共通要素を探索。</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ddb8044b-db50-493c-9d73-918bafb04060/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-05-2322.50.10.png" alt="Roaring Bitmap"><br>
(int32を扱うとして、実際にはcontainerの要素には下位16bitを入れ、上位16bitはコンテナ毎に持ちます。足し合わせることで元のint32に復元できます。)</p>
<p>Arrayコンテナが関わる演算はBitmapコンテナ同士の演算と比べると非効率ですが、そもそも要素数が少ないため大して問題にならない、というのが良くできているところだと思います。また、WAHやConcise Bitmapではワード単位でBitmapかRun-lengthかを区別しますが、Roaring Bitmapでは大きい固定サイズで分けたことで、オーバヘッドが少なくなったことがポイントだと思います。</p>
<p>余談ですが、OSSのOLAP DBであるApache Druidでは、デフォルトで文字列型の全カラムに対してRoaring Bitmap Indexが作られます。大胆ですね。実際KARTEで扱うような行動データをDruidにロードして試したことがありますが、Bitmap Indexのサイズはカラムナ部分と同程度に収まり、フィルタリングもかなり早くなりました。</p>
<p>また、数値型に対して作らない理由は以下だと思います。</p>
<ul>
<li>カーディナリティが高いことが多い(年齢や会員ランクなど、反例も多そうですが)</li>
<li>固定長で値が小さいためカラムナフォーマットだけでも十分早い(SIMD / CPUキャッシュ / CPUレベルでの並列化が効きやすい)</li>
</ul>
<h2>Bit-Sliced Index</h2>
<p>Bitmap Indexの弱点に対応するフォーマットとして、Bit-Sliced Indexもあります。ざっくり言えば数値型に向いてるIndexです。(Roaring BitmapはBitmap単体のフォーマットですが、Bit-Sliced Indexはindex全体のフォーマットです。組み合わせることもできます。)</p>
<p>Bit-Sliced Indexは、カラムの値を特定の基数で分解（スライス）し、各ビット位置ごとにビットマップを作成します。</p>
<p>以下は商品価格を基数2で表現(=2進数)する例です。B[i]は2進数表現の、i bit目を意味します。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>価格</th>
<th>B[7]</th>
<th>B[6]</th>
<th>B[5]</th>
<th>B[4]</th>
<th>B[3]</th>
<th>B[2]</th>
<th>B[1]</th>
<th>B[0]</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>1</td>
<td>230</td>
<td>1</td>
<td>1</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>2</td>
<td>130</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>3</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
</tbody>
</table>
<p>Bit-Sliced Indexでは、物理的には縦方向のBitmapを持ちます。この例では行数が4で桁数が8(bit)なので、長さ4のBitmapが8個作られます。</p>
<p>ナイーブなBitmap Indexでは行番号を指し示すBitmapが値ごとに作られますが、今回は値自体もBitmapでエンコーディングするのでこんがらがりがちです。上記の表を行列と捉えて、横方向のBitmapは値自体の表現であり、縦方向のBitmapは値の特定の桁が一致する行番号を指し示すBitmapと言えます。</p>
<p>価格が最大で255円だとすると、基数2のBlit-Sliced Indexで必要なビットマップは8個です。ナイーブなBitmap Indexなら最大256個のビットマップが必要になることと比べると、大幅にサイズを抑えられることが分かります。</p>
<h3>Bit-Sliced Indexによる合計計算（基数2の場合）</h3>
<p>応用のアルゴリズムとして、Bit-Sliced Indexでカラムに含まれる値の合計値が計算できます。元々の目的である索引以外にも使えるのが面白いです。</p>
<pre><code class="language-cpp">/**
 * B: 特定カラムCのBit-Sliced Index (B[i]はi番目のビットに対応するビットマップ)
 * Bf: 条件を満たす行を示すビットマップ (Foundset)
 * num_bits: 値を表現するのに必要なビット数(横方向のBitmapのビット数)
**/
int sum = 0;
for (int i = 0; i &lt; num_bits; ++i) {
    // i番目のビットが立っている行だけを対象に、2^i を加算
    sum += 2^i * POPCOUNT(B[i] AND Bf);
}
return sum;

</code></pre>
<h3>基数</h3>
<p>ここまで基数2を例にしてきましたが、他の基数を取ることもできます。例えば基数10とすると、1000未満の整数であれば100,10,1の位の3つの10bitのスライスで表現し、位の値がNならスライスの右からN番目に1を立てます。</p>
<p>例えば230は100の位が2、10の位が3、1の位が0なので、以下のようになります。<br>
<code>0000000100</code>(100の位) <code>0000001000</code>(10の位) <code>0000000001</code>(1の位)</p>
<p>基数は単一である必要はなく、位ごとに変えることもできます。</p>
<p>基数の増減に伴うトレードオフはサイズとクエリ効率にあるようです。基数を増やすサイズは増えますが、例えば等価検索の効率が良くなることは明らかです。</p>
<h3>Encodingと検索</h3>
<p>値のBitmap(横方向)のEncodingのバリエーションとして、Equality EncodingとRange Encodingがあります。</p>
<p>Equality Encodingは値がNならN番目のbitに1を立てるもので、ここまでで説明してきた方法です。<br>
Range Encodingでは、値がNならN番目のbitとその左のbit全てに1を立てます。</p>
<p>例えば基数10で230を表現すると、100の桁が2、10の桁が3、1の桁が0ですから、以下のようになります。<br>
<code>0000000100 0000001000 0000000001</code>(Equality Encoding)<br>
<code>1111111100 1111111000 1111111111</code>(Range Encoding)</p>
<p>Range Encodingはその名の通り範囲検索に強いエンコーディングです。</p>
<p>それぞれのエンコーディングで等価検索と範囲検索のアルゴリズムがあります。複雑なので、範囲検索の大雑把な方針のみ説明します。</p>
<p><strong>Equality Encodingの範囲検索</strong><br>
例えば特定の値より大きいデータを取る場合、位だけを見て対象の値より大きいと分かる行を取るステップと、同じ位の中で対象の値より大きい行を取るステップがあります。</p>
<p>例えば基数2で <code>価格 &gt;= 5 (バイナリ: 00000101)</code> を検索する場合、以下の2つの結果の和集合が結果です。</p>
<ul>
<li>8以上255以下の行
<ul>
<li>B[7]からB[3]までのうちどれか一つでも1が立っている(ORで取得)</li>
</ul>
</li>
<li>5以上7以下の行
<ul>
<li>B[2]が立っていて、B[1]かB[0]のうちどちらか一つでも1が立ってる(ANDとORで取得)</li>
</ul>
</li>
</ul>
<p><strong>Range Encodingの範囲検索</strong><br>
特定の値より大きいデータを取る場合、その値のbitだけをチェックします。例えば基数10で値が200以上のデータを取る場合、100の位のスライスの右から1番目のbitが0である行を取得します。</p>
<h2>まとめ・感想</h2>
<p>Bitmap Indexと言えばデカいイメージがありますが、対策としていろいろなアイデアが提案されています。こんなにアイデアを凝らすほどAND/ORが効率的に処理できるBitmapが魅力的ということですね。</p>
<p>Roaring Bitmapに比べるとBit-Sliced Indexはそこまで流行っていないような気もします。カラムナDBであれば数値型はカラムナだけで十分早いからでしょうか。行指向のDBでは有用な気もしますが、更新が重いからかもしれません。</p>
<p>また、Bit-Sliced Indexの基数とエンコーディングについては、クエリやデータパターンに応じて選ぶのが重要な気がします。それぞれの特性・トレードオフを整理するところまでは今回は辿り着けませんでしたが、興味があれば各種論文を見てみると良いかもしれません。</p>
<h2>参考資料</h2>
<p><a href="https://dl.acm.org/doi/10.1145/253262.253268">Improved query performance with variant indexes | ACM SIGMOD Record</a><br>
<a href="https://dl.acm.org/doi/10.1145/276305.276336">Bitmap index design and evaluation | ACM SIGMOD Record</a><br>
<a href="https://arxiv.org/abs/1004.0403">[1004.0403] CONCISE: Compressed 'n' Composable Integer Set</a><br>
<a href="https://roaringbitmap.org/">Roaring Bitmaps</a></p>


いろいろなBitmap Indexの紹介

<h2>はじめに</h2>
<hr>
<p>こんにちは。プレイドのKARTE Datahubチームでエンジニアをしている安海です。</p>
<p>この記事は「<a href="https://tech.plaid.co.jp/multi-product-audit-log-collection">マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装　- 収集編</a>」の続編です。<br>
前回は監査ログの収集基盤について解説しましたが、今回は収集した監査ログをどのように抽出し、ユーザーに提供しているのか、そのアーキテクチャと技術的な工夫について詳しく解説します。<br>
監査ログの抽出基盤を設計・運用する際に直面した課題と、それに対する解決策を共有することで、同様の課題に取り組むエンジニアの一助となれば幸いです。</p>
<h2>抽出基盤のアーキテクチャ</h2>
<hr>
<p>監査ログの抽出基盤は、「他プロジェクトのデータが混在しない安全性」と「開発者の実装のしやすさ」を両立することを目指して設計されています。具体的には、以下のようなアーキテクチャを採用しています。</p>
<p><img src="https://ik.imagekit.io/plaid/ffa4aa6f-b680-42f2-ace3-661e65c9dfa1/auditlog_table_function_architecture.png" alt="auditlog_table_function_architecture.png"></p>
<h3>なぜテーブル関数を採用したのか</h3>
<p>まず、監査ログの抽出基盤でなぜ <a href="https://cloud.google.com/bigquery/docs/table-functions?hl=ja">BigQueryのテーブル関数</a> を採用したのかについて説明したいと思います。テーブル関数は、SQLクエリをカプセル化し、関数として再利用できるBigQueryの機能です。通常のテーブルと同様にクエリ内で参照でき、さらに引数を受け取れる点が大きな特徴です。<a href="https://cloud.google.com/bigquery/docs/views-intro?hl=ja">ビュー</a>と異なり、実行時にパラメータを渡せるため、同一のロジックを様々な条件で使い回すことができます。</p>
<p>例えば、以下のようにシンプルなテーブル関数を定義できます。</p>
<pre><code class="language-sql">CREATE OR REPLACE TABLE FUNCTION project_dataset.get_project_logs(project_id STRING, start_date DATE, end_date DATE)
AS (
  SELECT *
  FROM `logs.audit_logs`
  WHERE project_id = project_id
    AND DATE(timestamp) BETWEEN start_date AND end_date
);

</code></pre>
<p>このテーブル関数は、クエリから次のように参照できます。</p>
<pre><code class="language-sql">SELECT *
FROM project_dataset.get_project_logs('project-123', DATE('2023-01-01'), DATE('2023-01-31'))
WHERE severity = 'ERROR'
ORDER BY timestamp DESC
LIMIT 100;

</code></pre>
<p>テーブル関数を採用した主な理由は、クエリ実行時にパラメータを受け取れる柔軟性にあります。特に監査ログでは、ユーザーが任意の期間のログを抽出できることが重要な要件でした。テーブル関数を使用することで、日付範囲などのパラメータを実行時に指定でき、ユーザーは必要なデータだけを効率的に取得できます。</p>
<p>さらに、生ログは日時でパーティショニングされているため、日付範囲を指定することでパーティションプルーニングが働きます。この仕組みにより、不要なデータスキャンを最小限に抑え、クエリのパフォーマンスを向上させることが可能です。</p>
<p>また、SQLのロジックをテーブル関数内にカプセル化できるため、クエリの再利用性が高まることもメリットです。これにより、複雑なロジックを一箇所に集約し、メンテナンス性を向上させることができます。</p>
<h3>テーブル関数の役割と設計</h3>
<p>抽出基盤の中核となるのは3種類のテーブル関数です。これらの役割と設計思想について解説します。</p>
<h4>1. プロジェクトログ抽出テーブル関数</h4>
<p>この基盤層のテーブル関数は、引数で指定されたプロジェクトIDに対応するログだけを抽出する役割を担っています。他プロジェクトのログが露出するリスクを最小化するため、この関数は変更頻度が低くなるような設計としています。</p>
<p>単一の責務に特化することで、SQLの複雑性を抑制し、堅牢性を高めています。この層がセキュリティの要となるため、変更する際にはGithubで指定された <code>CODE_OWNER</code> のコードレビュープロセスを経る必要があります。</p>
<h4>2. プロダクト別変換テーブル関数</h4>
<p>プレイドでは複数のプロダクトを展開しており、各プロダクトでクライアント向け監査ログへの変換方法が異なります。そこで、プロダクトごとに専用の変換テーブル関数を用意し、それぞれのデータ構造に合わせた変換ロジックを定義できるようにしています。</p>
<p>実際のデータ変換の例はこのような感じです。例えば、以下のような生ログのJSON構造があるとします：</p>
<pre><code class="language-json">{
  &quot;jsonPayload&quot;: {
    &quot;user&quot;: {
      &quot;id&quot;: &quot;user_12345&quot;,
      &quot;name&quot;: &quot;山田太郎&quot;,
      &quot;email&quot;: &quot;yamada@example.com&quot;
    },
    &quot;http_request_meta&quot;: {
      &quot;ip&quot;: &quot;192.168.1.1&quot;,
      &quot;user_agent&quot;: &quot;Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...&quot;
    },
    &quot;resource&quot;: {
      &quot;type&quot;: &quot;dataset&quot;,
      &quot;id&quot;: &quot;dataset_789&quot;,
      &quot;action_type&quot;: &quot;update&quot;
    },
    &quot;detail&quot;: [
      {
        &quot;detailType&quot;: &quot;diff&quot;,
        &quot;new&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット2023&quot;},
        &quot;old&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット&quot;}
      },
      {
        &quot;detailType&quot;: &quot;fields&quot;,
        &quot;value&quot;: {&quot;created_at&quot;: &quot;2023-05-01T09:00:00Z&quot;}
      }
    ],
    &quot;timestamp&quot;: &quot;2023-05-01T10:15:30Z&quot;
  }
}

</code></pre>
<p>このような生ログから、ユーザーに見せる監査ログとして以下のような形式に変換したいとします：</p>
<table>
<thead>
<tr>
<th>user_id</th>
<th>ip_address</th>
<th>action</th>
<th>resource_type</th>
<th>resource_id</th>
<th>timestamp</th>
<th>before_edit</th>
<th>after_edit</th>
</tr>
</thead>
<tbody>
<tr>
<td>user_12345</td>
<td>192.168.1.1</td>
<td>update</td>
<td>dataset</td>
<td>dataset_789</td>
<td>2023-05-01T10:15:30Z</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット&quot; }</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット2023&quot; }</td>
</tr>
</tbody>
</table>
<p>このような変換を行うために、各プロダクトチームはどのフィールドをどのように抽出・変換するかをマッピング定義として記述します。これにより、生ログの複雑なネスト構造から必要な情報だけを取り出し、ユーザーにとって理解しやすい形式に整形できます。</p>
<p>この層では宣言的なアプローチを採用しており、各プロダクトチームは変換マッピングを定義するだけで、自動的にSQL文(テーブル関数)が生成される仕組みを整えています。これにより、SQLを意識しなくても監査ログの変換ロジックを実装できます。</p>
<p><strong>マッピングの仕様：</strong></p>
<ul>
<li><strong>基本構造</strong>
<ul>
<li><code>map</code> 内の key は整形後の監査ログのカラム名を指定します</li>
<li><code>columnName</code> には生ログのデータパスを指定します</li>
<li><code>type</code> にはデータ型（STRING, JSON など）を指定します</li>
</ul>
</li>
<li><strong>detail フィールドの処理</strong>
<ul>
<li><code>detail</code> フィールドには比較的自由な形式のデータが格納されるため、特殊なマッピングを指定できます：
<ul>
<li><code>detailType</code> - 処理対象のデータタイプ（<code>diff</code>/<code>fields</code>/<code>error</code> など）</li>
<li><code>detailFieldsKey</code> - オブジェクト内の抽出したいキー名</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>実際に <code>detail</code> に格納されるデータの例<br>
※ 同一 detailType のオブジェクトが複数入らないようにしています</p>
<pre><code class="language-jsx">[
  {detailType: &quot;diff&quot;, new: {dataset_name: &quot;hoge&quot;} old: { dataset_name: &quot;fuga&quot; }},
  {detailType: &quot;fields&quot;, value: { hoge: 1, fuga: &quot;piyo&quot; }},
  {detailType: &quot;error&quot;, message: &quot;this is error&quot; }
]

</code></pre>
<p>以下は変換マッピングの例です。このマッピングでは、ユーザーID、IPアドレス、編集前の値などを抽出する方法を定義しています。</p>
<p>また、より柔軟なデータ抽出が必要な場合には、<code>custom</code>セクションを利用してカスタムの<code>SELECT</code>文を記述できます。これにより、既存のパターンでは対応できない特殊な要件にも対応可能です。例えば、特定の条件に基づいてデータを加工したり、集約した結果を取得することができます。</p>
<pre><code class="language-jsx">{
  map: {
    user_id: { columnName: 'user.id', type: 'STRING' },
    ip_address: { columnName: 'http_request_meta.ip', type: 'STRING' },
    before_edit: {
      columnName: detail,
      type: 'JSON',
      detailType: 'diff',
      detailFieldsKey: 'old',
    },
  },
  custom: {
    selectQueries: [
      `TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value`,
    ],
  },
  version: '1'
};

</code></pre>
<p>このマッピング定義から、以下のようなSQLが自動生成されます。</p>
<pre><code>SELECT
  CAST(jsonPayload.user.id AS STRING) AS user_id,
  CAST(jsonPayload.http_request_meta.ip AS STRING) AS ip_address,
  TO_JSON(ANY_VALUE(IF(detail.detailType = 'diff', detail.old, NULL))) AS before_edit,
  TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value
FROM
  sampleTableFunction(api_key, start_date, end_date)
  ...

</code></pre>
<h4>3. プロジェクト別テーブル関数</h4>
<p>最終的なデータ提供層として、プロジェクトごとにデータセットを分け、その中にプロダクトごとのテーブル関数を配置しています。この設計には二つの利点があります。</p>
<ol>
<li>将来的に<a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction?hl=en">BigQuery sharing</a>経由などでデータセットごとユーザーに提供する可能性への対応</li>
<li>マッピング変更時の影響範囲の局所化</li>
</ol>
<p>このテーブル関数は基本的に中間層（プロダクト別変換テーブル関数）を参照するだけの構造になっています。そのため、中間層の変換ロジックが変更された場合でも、すべてのプロジェクトデータセット内のテーブル関数を更新する必要がなく、運用負荷を大幅に削減できます。</p>
<h3>テーブル関数の自動生成と管理</h3>
<p>続いて、テーブル関数の作成・更新プロセスについて説明していきます。構成としては、以下のようになっており、基本的に自動化されています。</p>
<p><img src="https://ik.imagekit.io/plaid/47096b33-1545-48e9-aa3d-2269ef407723/auditlog_table_function_automation.png" alt="auditlog_table_function_automation.png"></p>
<h4>プロジェクトログ抽出テーブル関数の管理</h4>
<p>基盤層のテーブル関数は、リポジトリ内のコード変更をトリガーにGitHub Actionsを通じて更新されます。(構成図の左側参照) この重要なコンポーネントはCODE_OWNERで厳格に管理されており、特定のレビュアーの承認がなければ変更できない仕組みになっています。</p>
<h4>プロダクト別テーブル関数の自動生成</h4>
<p>各プロダクトチームは、マッピング定義を更新するだけで、GitHub Actions経由でSQLが自動生成され、対応するテーブル関数が更新されます。(構成図の左側参照)</p>
<h4>プロジェクト別データセット・テーブル関数の自動生成</h4>
<p>新しいプロジェクトのデータが生ログに追加された場合、自動的に対応するデータセットとテーブル関数が作成される仕組みを実装しています。(構成図の右側参照) 具体的には、Cloud Schedulerで定期的にCloud Run関数を起動し、直近の生ログをスキャンして新規プロジェクトを検出します。</p>
<p>検出された新しいプロジェクトに対しては、データセットの作成とテーブル関数の生成が自動的に行われます。データセット・テーブル関数が作成済みのプロジェクトに関する情報は、BigQueryの簡易的なテーブルを使い以下のように管理しています。</p>
<table>
<thead>
<tr>
<th>project_id</th>
<th>product</th>
<th>version</th>
<th>created_at</th>
</tr>
</thead>
<tbody>
<tr>
<td>xxx</td>
<td>talk</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>1</td>
<td>2025-04-30 02:51:19.420000 UTC</td>
</tr>
</tbody>
</table>
<h2>保守運用の工夫</h2>
<hr>
<p>監査ログ基盤の運用には、データの安全性確保と長期的な保守性の両立が求められます。ここでは、その課題に対応するための技術的な工夫を紹介します。</p>
<h3>効率的なデータダウンロード機構</h3>
<p>監査ログは大量のデータを扱うため、効率的なダウンロード機構が必要です。そこで、BigQueryのストリーミング機能を活用し、データを10MBごとに圧縮してクライアントに送信する仕組みを実装しています。</p>
<p>また、ユーザビリティ向上のための工夫として、生ログに含まれる<code>projectId</code>などの単なる識別子を、ストリーミング処理中にアプリケーションのデータベースから取得したプロジェクト情報と結合し、 <code>株式会社プレイド検証環境</code> のようなユーザーが理解しやすい表記に変換しています。</p>
<p>この仕組みは現状は十分に対応できていますが、予期せぬ大量データなどによりエラーが発生した場合は、Datadogにエラーを通知するようにしているため、迅速に対応できるようになっています。</p>
<h3>多層的なセーフティネット</h3>
<p>他プロジェクトのデータが混入するリスクを最小化するため、複数のセーフティネットを設けています。</p>
<p>まず、テーブル関数のセキュリティ監視として、Cloud Scheduler と Cloud Run 関数を組み合わせ、定期的にテーブル関数にアクセスして返されるデータを検証しています。他プロジェクトのデータが検出された場合は、即時 Datadog のアラートが発報される仕組みです。</p>
<p>さらに、ユーザーがデータをダウンロードするストーリミング処理にも、BigQueryで二重チェックを行い、他プロジェクトのログが含まれていないことを確認しています。万一の混入が検出された場合は、ダウンロード処理を中止する安全機構を導入しています。</p>
<h3>継続的なサービス監視</h3>
<p>監査ログは機能的な性質上、月に一回ダウンロードされるなど、日常的に頻繁に使用される機能ではありません。そのため、問題が長期間気づかれず放置されてしまうリスクがあります。この課題に対応するため、<a href="https://www.datadoghq.com/ja/dg/apm/synthetics/synthetic-monitoring/">Datadog Synthetics (外形監視ツール)</a>を活用して、画面から定期的にダウンロードを行い実際にファイルがダウンロードできるかのチェックしています。</p>
<p>これにより、実際のユーザーが機能を使用する前に問題を発見し、迅速に対応することができる体制を整えています。</p>
<h3>テーブル関数のバージョン管理</h3>
<p>監査ログのカラム構成や形式は、プロダクトの進化に合わせて変更される可能性があります。変更があった場合でも、既存のシステムやユーザーの利用を妨げないために、テーブル関数にはバージョン管理機能を導入しています。</p>
<p>マッピング定義に<code>version</code>パラメータを指定することで、新しいバージョンのテーブル関数を追加しつつ、既存のバージョンも並行して維持できます。これにより、ユーザーは自身のニーズに合わせたバージョンを選択できるようになり、互換性を保ちながら監査ログを変更させることができるようになっています。</p>
<h2>まとめ</h2>
<hr>
<p>監査ログの抽出基盤は、セキュリティとユーザビリティのバランスを取りながら、開発者が容易に実装・拡張できる設計を目指しています。多層構造のテーブル関数、自動生成の仕組み、複数のセーフティネットにより、安全かつ柔軟な監査ログ提供を実現しています。</p>
<p>マルチプロダクト環境では、新しいプロダクトの追加や既存プロダクトの変更が頻繁に発生しますが、この基盤により、各プロダクトチームは複雑なセキュリティ実装をほとんど意識せずに、安全に監査ログを拡張できます。プロダクト間の監査ログの一貫性を保ちながらも、それぞれのプロダクト特有の情報を柔軟に取り込める設計が、マルチプロダクト戦略を支える重要な要素となっています。</p>
<p>今後も新たな要件やプロダクトの追加に対応しながら、監査ログ基盤の進化を続けていく予定です。また、さらなる活用方法として、機密情報を適切に除去した上で社内の調査・分析用途に監査ログを活用することも検討しています。例えば、長期間使用されていないアカウントの洗い出しやプロダクト使用状況分析などを通じて、セキュリティの強化やサービス改善に繋げていくことが可能です。このように監査ログは単なる記録としてだけでなく、データドリブンな意思決定を支える貴重な情報源となる可能性を秘めています。</p>


マルチプロダクト環境における監査ログ抽出基盤のアーキテクチャと技術的な工夫を解説。BigQueryのテーブル関数を活用し、「安全性」と「開発のしやすさ」を両立する設計思想、自動生成の仕組み、運用時の工夫を紹介します。

監査ログ抽出基盤の設計と実装：BigQueryテーブル関数による安全性と柔軟性の両立

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

<h1>はじめに</h1>
<p>こんにちは。プレイドのKARTE Messageチームでエンジニアをしている林(<a href="https://x.com/smoothbronco">Twitter</a>)です。</p>
<p>この記事では、動的にSQLを生成する機能の実装を無事故で改善し、その後の開発スピードを向上させたことについてお話しします。</p>
<h1>KARTE Messageについて</h1>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。</p>
<p><a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信サービスの運用について紹介している記事</a> があるので、こちらもぜひ併せてご覧ください。</p>
<h2>配信対象抽出機能について</h2>
<p>KARTE Messageでは、SQLが書けないマーケターでもGUIベースでメールやLINEの配信対象を抽出できるための機能を提供しています。</p>
<p>配信対象はデータ統合・利活用プラットフォームである<a href="https://developers.karte.io/docs/about-datahub">KARTE Datahub</a>内のテーブルまたはクエリをベースにしており、「リスト」と呼びます。</p>
<p>リストには配信対象のメールアドレスやユーザーID、クーポンコード等のコンテンツに埋め込むデータが入っています。</p>
<p>たとえば、会員マスタのうちGOLDランクの会員にだけメールを送りたい場合は、以下のような操作で対象を絞り込むことができます。ある対象を除外する、パーソナライズした値をコンテンツに埋め込む、施策内で1ユーザーに対してx回まで配信する、といったこともこの機能で実現しています。</p>
<p>※ データはすべてダミーです。</p>
<p><img src="https://ik.imagekit.io/plaid/ab4a4133-596b-42e1-986a-164fa2a444fb/merge_list.webp" alt="merge_list.webp"></p>
<p>配信対象抽出の裏側では、クライアントの設定した値から動的にSQLを生成しています。</p>
<p>先ほどのGOLD会員の例では、以下のようなSQLを生成します。</p>
<pre><code class="language-sql">WITH result AS (
	WITH master_{list_id} AS (
		-- &quot;【デモ】マスターデータ_メール&quot;のクエリ
		SELECT * FROM demo_master_mail
	),
	subset_{list_id} AS (
		-- &quot;gold会員&quot;のクエリ
		SELECT * FROM demo_master_mail WHERE rank = 'gold'
	),
	merge_list AS (
		WITH master AS (
			SELECT * FROM master_{list_id}
		),
		subset AS (
			SELECT user_id FROM subset_{list_id}
		)
		SELECT
			master.user_id AS user_id,
			master.email AS target
		FROM master
		LEFT JOIN subset ON master.user_id = subset.user_id
		WHERE subset.user_id IS NOT NULL
	)
	-- (中略)
)
SELECT * FROM result;
</code></pre>
<p>このSQLは配信する時とクライアントが対象ユーザーをプレビューする時にKARTE Datahubのテーブルに対してクエリします。</p>
<p>対象抽出のデータ結合に用いるキーはユーザーIDか配信先 (メールアドレスやLINE ID) を使っており、ユーザーIDのカラムがある場合はユーザーIDで結合します。</p>
<p>クライアントの持っているデータによってはユーザーIDカラムのないデータもあるので、その場合は配信先のカラムで結合します。</p>
<p>また、一部のユーザーIDがnullになっていることもあります。</p>
<h2>改善前の課題</h2>
<p>たとえば以下のようなケースだと、メールアドレスが一致していても一部でuser_idがnullになっている場合はパーソナライズする値が落ちてしまいます。</p>
<p><img src="https://ik.imagekit.io/plaid/acd9c458-90cd-404f-a92d-bc3f94f36254/user_id_null.png" alt="user_id_null.png"></p>
<p>このようなケースを含め、配信対象抽出機能を改善する前は以下のような課題がありました。</p>
<ul>
<li>データに関する課題
<ul>
<li>targetやuser_idという一般的な名前が予約語になっており、クライアントの設定次第でカラム名が衝突する</li>
<li>user_idがnullableなので、対象抽出やパーソナライズする値を結合する際にレコードが落ちる場合がある</li>
</ul>
</li>
<li>ロジックに関する課題
<ul>
<li>配信時のクエリとプレビュー時のクエリを返すロジックの共通化ができておらず、出力に差分が生じてしまう</li>
<li>コードが複雑で処理の分割がうまくできておらず、キャッチアップコストが高い</li>
</ul>
</li>
</ul>
<p>配信対象抽出機能はKARTE Messageの中でもコアになる機能であることや、今後も頻繁にアップデートがかかることが想定される機能でした。この状態のまま運用していくと予期せぬバグやインシデントを起こしかねないので、機能全体に手をいれることにしました。</p>
<h2>やったこと</h2>
<p>以下2つのアプローチを取って行いました。</p>
<ol>
<li>リストの元データを view table にし、クエリするときは view table を参照する</li>
<li>既存の仕様からデータモデルを再定義し、コードをまるっと作り替える</li>
</ol>
<p>1つ目に関しては、view tableにすることでクライアントのデータに一定の前提を設けられるので、データに関する課題を解決することができると考えました。</p>
<p>2つ目に関しては、仕様が明確だったこと、既存のコードに対してテストが不十分だったことなどから、改めてデータモデルから作り替えた方がメンテナブルになるだろうと考えました。</p>
<h3>view tableにする対応について</h3>
<p>先に、viewのクエリを示します。</p>
<pre><code class="language-sql">SELECT
  *,
  cast(
    ifnull(
      cast(`user_id` as string),
      concat('null_embedded_', `email`)
    ) as string
  ) as masspush_user_id,
  cast(`mail` as string) as masspush_target,
FROM
  (
    -- リストの元データのクエリ
    SELECT
      *
    FROM
      demo_master_mail
  )
</code></pre>
<p>ポイントは2つです。</p>
<ul>
<li>予約語はクライアントが設定する可能性が限りなく低い命名にする</li>
<li>user_idがnullの時は<code>null_embedded_{配信先}</code> で埋める</li>
</ul>
<p>こうすることで、カラム名が重複することや最終的に配信対象が抜け落ちてしまうことが減りました。リストの元データのクエリは数百〜数千行になることもあるので、最終的なクエリをシンプルに保つことができるようにもなりました。</p>
<p>移行する中で難しかったのが、viewのクエリが参照するデータの鮮度を保つことです。</p>
<p>リストの中には、「先月10,000円以上購入した人」や「30分前にカゴ落ちした人」などの相対日時を条件に含むものがあります。これらは絶対日時に変換してクエリにしているので、配信やプレビューが実行される直前でviewのクエリを更新する必要がありました。</p>
<p>また、KARTE DatahubはBigQuery上にテーブルを保持しています。BigQueryのテーブル更新オペレーションは10秒で最大5つまでというクォータがあるので、都度viewを更新するのは現実的ではありません。</p>
<p>そこで、以下のような実装で更新オペレーションを極力減らすことにしました。</p>
<pre><code class="language-tsx">export const updateListViewQueryIfBaseSQLModified = async (
	baseSQL: string;
	list: List;
) =&gt; {
  const tableName = createTableName(list);
  const cachedQueryHash = await findCachedQueryHash(tableName);
  const newQueryHash = hashQuery(baseSQL);
  // 最新のqueryとcacheしたqueryのhashが一致してれば処理を終える
  if (cachedQueryHash === newQueryHash) {
    return;
  } else {
    // BigQueryに問い合わせてviewのqueryを比較する
    const isEqualBaseSQL = await compareViewToBaseSQL({
      list_id: list.id,
      baseSQL: baseSQL,
    });
    // queryが異なればviewのqueryを更新する
    if (!isEqualBaseSQL) {
      const viewQuery = buildQuery(list, baseSQL);
      await updateView(viewQuery, list.id);
    }
    // table名をkeyに、queryのhashをvalueにしたcacheを保存する
    await cacheQueryHash({ key: tableName, query: baseSQL });
  }
}
</code></pre>
<p>まず、BigQueryにリクエストする手前にcacheを挟むようにしました。同じリストを使い回して同時刻に複数個の配信を実行するクライアントは多いです。このようなケースはcacheのおかげでBigQueryへのリクエストを減らすことができました。</p>
<p>次のステップでは、BigQueryに問い合わせて最新のviewのqueryを取得し、比較するようにしました。テーブル取得のクォータは更新に比べて制約が緩いので、更新前に最終チェックをしています。</p>
<p>このようなステップを踏むことで、配信が集中する時間帯でもクォータを超えることなくviewのクエリを最新の状態に保つことができました。</p>
<h3>コードの作り替えについて</h3>
<p>コードの作り替えはTDDライクに行いました。まず仕様からテストケースを起こし、そのテストケースに従ってテストが通るようにコードを書くようにすることで、仕様の抜け漏れやエッジケースの見落としなどがないかを確認しながら進めることができました。</p>
<p>また、リリースに関してはview table対応とは別で行う、一部のテナントから段階的に行うなど、万が一問題があったときの影響範囲を最小限に抑えながら進めました。</p>
<h2>結果</h2>
<p>かなり大規模かつ問題が起きた時のリスクが大きい修正でしたが、配信に影響なくすべてリリースすることができました。</p>
<p>またこのリリース後、キャッチアップコストが大幅に減り、開発工数がより正確に見積れるようになりました。新しくチームに入ってきたエンジニアの方が新規に機能拡張をすることになった時も、キャッチアップが大変という感覚は無かったそうです。改善前に比べてテストも充実する形になったので、変更を加える際の影響範囲やエッジケースのバグ取りこぼしも見えやすくなりました。</p>
<p>課題の種類をデータとロジックに分けて、それぞれを解決するアプローチにしたことでシンプルになったと個人的には思っています。</p>
<h2>最後に</h2>
<p>私が所属するKARTE Messageチームでは、大量配信を支える配信基盤の改善や、より良いMAツールにしていくための機能開発など、まだまだやりたいことがたくさんあります。</p>
<p>少しでもこのような領域に興味を持ってくださった方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。応募待ってます！</p>


非エンジニアでも直感的に動的なSQLを生成できる、GUIのノーコードツールの改善方法の紹介

動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話

<p>こんにちは！プレイドでエンジニアをしている土佐といいます。</p>
<p>先日、社内で「生成AI」をテーマにしたLightning Talk（LT）会が開催されました！🎉プレイドだけでなく、グループ会社のRightTouchメンバーも集結し、総勢なんと約80名が参加する、とっても賑やかなオンラインイベントになりました。</p>
<p>ここ数ヶ月、社内でもCursorやCline、Vertex AI経由のGPTモデルなど、さまざまな生成AIツールの活用がどんどん進んできて、「お、そろそろ各チームで溜まってきた知見や『こんなことやってみた！』をシェアする良いタイミングじゃない？」ということで、今回のLT会が企画されたんです。</p>
<p>この記事では、当日の熱気や発表の面白さ、そして私たちが感じた「これから」の可能性を、少しでも皆さんにお届けできればと思います。LT会の雰囲気や学びが伝わると嬉しいです！</p>
<h2><strong>当日の熱気：オンラインでも伝わる一体感！</strong></h2>
<p>会場はオンライン。それぞれの場所から参加する形でしたが、画面越しにも伝わる熱気…！🔥 発表が始まると、みんな真剣な表情で聞き入り、Slackのスレッドも質問や感想、「なるほど！」「それ面白い！」といったコメントで、めちゃくちゃ盛り上がっていました。</p>
<h2><strong>発表ハイライト 🚀</strong></h2>
<p>今回のLT会では、本当に多種多様なテーマで10件の発表がありました。どれも興味深く、刺激的な内容ばかりでした！すべての発表をダイジェストでご紹介します。</p>
<ul>
<li><strong>「採用面談の日程調整をAIにやってもらうワークフローを構築しました」</strong>
<ul>
<li>候補者と複数面接官の複雑なカレンダー調整を、Zapier AIとDifyを駆使して自動化！ Slackから使える「Google Calendar 日程提案くん」で、面倒な調整業務をスマートに解決する実用的な工夫が光りました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://note.com/kantetsu/n/n00958cea908d">https://note.com/kantetsu/n/n00958cea908d</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「お客さんの商品データを検索するMCPサーバー作ってみた」</strong>
<ul>
<li>通常のキーワード検索だけでなく、ベクトル検索で&quot;似ている商品&quot;も提案できるAPIサーバーを自作。ユーザーの「見つからない…」を減らす、既存技術を組み合わせた価値創造の好例でした。</li>
</ul>
</li>
<li><strong>「Cline + ChatGPT 4o 画像生成を使ったOSS開発をしてみた」</strong>
<ul>
<li>自作OSS「Gunshi」の開発で、Clineによるコーディング支援やドキュメント生成、ChatGPT 4oによるロゴ・OGP画像作成までAIを活用！ 開発プロセス全体でのAI活用スタイルが新鮮でした。</li>
<li><a href="https://gunshi.dev/">https://gunshi.dev/</a></li>
</ul>
</li>
<li><strong>「生成AIにサポートサイトドキュメントを書かせて公開してみた」</strong>
<ul>
<li>Cursor等のAIツールを使い、コードベースからサポートサイトのドキュメントを効率的に生成・公開。人間には手間のかかる表作成などもAIに任せる、実践的なノウハウが共有されました。</li>
</ul>
</li>
<li><strong>「ボランティアのイベント告知サイトの更新をClineを使ってほぼ自動化した件」</strong>
<ul>
<li>ボランティアで運営するWordPressサイトの更新作業を、Cline、RPA、ChatGPT生成HTMLで見事に自動化！ Gutenberg記法を活用することで、ビジュアルエディタとの互換性を持たせる工夫を行い、大幅な効率アップを実現した、技術による社会貢献の素敵な事例でした。</li>
</ul>
</li>
<li><strong>「AI開発基盤を作ってみた」</strong>
<ul>
<li>AI機能をより簡単に開発できる基盤を開発中。AIエージェント開発の知見集約や再利用性を高める土台作りのお話にワクワクしました。</li>
</ul>
</li>
<li><strong>「code-bugsというCLIツールを作った」</strong>
<ul>
<li>複数ファイルにまたがる定型的なコード修正を、AIが自動で行ってくれるCLIツール「code-bugs」を開発。簡単なレシピで面倒な作業を効率化する、開発者の頼もしい味方になりそうです！</li>
</ul>
</li>
<li><strong>「AI Agentにセキュリティレビューをやってもらう」</strong>
<ul>
<li>Copilot AgentやCursorにセキュリティルールを学習させ、コードレビューを補助させる試み。AIをセキュリティチェックの「心強い相棒」として活用する可能性が示されました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://tech.plaid.co.jp/security-review-by-ai-agent-101">https://tech.plaid.co.jp/security-review-by-ai-agent-101</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「誰でもできるvibe-coding」</strong>
<ul>
<li>エンジニア以外の職種の方がAIで機能を実装！顧客解像度の高い人が直接開発できる可能性と、レビュー負荷軽減のためのプロセス改善（仕様レビュー、PR分割）というリアルな試行錯誤が共有されました。</li>
</ul>
</li>
<li><strong>「Codatumで組織サーベイの分析にLLMによる要約を埋め込んでみた」</strong>
<ul>
<li>BigQueryとVertex AIを連携し、SQL関数 <code>ML.GENERATE_TEXT</code> を活用して従業員サーベイの大量の自由記述回答をグループ別に要約。SQLだけで高度なテキスト分析を実現するパワフルな活用事例でした。</li>
<li>Codatumとは
<ul>
<li><a href="https://codatum.jp/">https://codatum.jp/</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2><strong>LT会を終えて：見えてきた景色と、これからの私たち</strong></h2>
<p>本当に刺激的なLT会でした！</p>
<p>個人的に最も印象的だったのは、「誰でもできるvibe-coding」の発表です。プロダクトやお客様に一番近いメンバーが、AIを使って直接価値を生み出せる。これって、開発のあり方やスピード感を根本から変える可能性を秘めていると感じました。</p>
<p>もちろん、「じゃあ、私たちソフトウェアエンジニアの価値ってどこにあるんだっけ？」という問いも同時に生まれます。AIがコードを書けるようになった今、私たちはより本質的な課題解決や、アーキテクチャ設計、そしてAIを最大限に活用するための環境構築といった領域で、さらに価値を発揮していく必要があるのかもしれません。今回のLT会は、そんなことを考える素晴らしいきっかけになりました。</p>
<p>プレイドでは、**「技術はトレンドを追うためではなく、長期的なインパクトと組織的な再現性を生み出す原動力である」**と考えています。今回のLT会で見られた多様なチャレンジは、まさにその思想を現場レベルで体現しているように感じました。</p>
<p>単に「生成AIが流行っているから使う」のではなく、「<strong>どうすれば顧客への価値提供や、私たちの働き方を本質的に良くできるか？</strong>」という視点で、みんなが主体的にAIと向き合い、試行錯誤を楽しんでいることがわかったイベントでした。</p>
<p>参考</p>
<p><a href="https://blog.plaid.co.jp/n/nb08d947606f3">https://blog.plaid.co.jp/n/nb08d947606f3</a></p>
<h2><strong>おわりに：<strong>プレイド</strong>のAI環境</strong></h2>
<p>実は、あまり大々的には言っていませんが、プレイドでは、エンジニアは <strong>Cursor、Cline、Vertex AI経由の各種モデルといった生成AIツールを、かなり自由に試せる環境</strong>が整っています。これ、個人的にはものすごい「福利厚生」だなと思っていて…（だって、個人で契約したら、日に数万円かかることもありますからね！）</p>
<p><strong>「生産性のための環境投資は死ぬほど安い」</strong> というのがプレイドのエンジニアのマインドセットの一つ。セキュリティには最大限配慮しつつも、これからも価値創出につながる新しい技術は積極的に取り入れていくんだろうな、と感じています。</p>
<p>そんなプレイドでは、一緒に未来のプロダクトを作るソフトウェアエンジニアを絶賛募集中です！</p>
<p>今回のLT会のような、技術への探求心や「やってみよう！」の精神を大切にする環境に興味のある方は、ぜひ採用ページを覗いてみてくださいね。</p>
<p>👉 <strong>プレイド採用ページ：</strong> <a href="https://recruit.plaid.co.jp/product">https://recruit.plaid.co.jp/product</a></p>
<p>最後まで読んでいただき、ありがとうございました！</p>
<p>P.S. このブログ記事も、実はGoogle MeetのGemini議事録とGemini 2.5 Proの力を借りて、構成案から執筆までサポートしてもらいました！</p>


プレイド社内で開催された生成AIのLT会レポート。グループ会社RightTouchも参加し、CursorやVertex AI経由GPT等の活用事例や開発知見を共有。当日の発表をサマリでお伝えします

生成AI、どう使う？ プレイド社内LT会で活用のヒントを探ってみた！

<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開発から学んだテストの重要性と設計

<p>こんにちは、エンジニアの中間です。<br>
普段はKARTEのネイティブアプリ向けSDKの開発をしています。</p>
<p>React Nativeで遊んでみたことを紹介します。<br>
こちらの投稿は<a href="https://qiita.com/advent-calendar/2018/plaid">PLAID Advent Calendar 2018</a>の6日目の記事でもあります。</p>
<p>KARTEではWebサイトやアプリを通してユーザ一人一人に合わせたコミュニケーションをリアルタイムに取ることを大事にしています。<br>
例えばKARTEのSDKは、管理画面でHTML/CSS/JavaScriptで記述されたアクションをアプリ内メッセージ（ポップアップやバナー、アンケート等）として表示する機能を持っています。<br>
アプリ内メッセージの見た目や挙動を柔軟にカスタマイズできるので、様々な訴求を行えます。</p>
<p>今回は、よりリッチでネイティブライクな見た目のメッセージを出せないか、という可能性を探るために、React Nativeを使いアプリ内メッセージのような機能の実装・実験をします。<br>
ポイントは以下の点です。</p>
<ul>
<li>主となるアプリ上に、アプリ内メッセージを模した第二のアプリを読み込み表示できるか</li>
<li>第二のアプリをリアルタイムに（アプリアップデートの必要なく）変更できるかどうか</li>
</ul>
<h2>概要</h2>
<p>以下の構成のサンプルアプリを作り正常に起動・表示できるかを試します。</p>
<ul>
<li>メインのReact Nativeアプリの上にサブのReact Nativeアプリを表示する。サブのアプリではサーバからfetchしたbundleを使う（プロダクションを想定し、DeveloperSupportは使わない）</li>
</ul>
<p>通常React Nativeのアプリをリリース用にビルドするとassetsにbundleファイルが配置されますが、<code>ReactInstanceManager.setBundleLoader</code>によりbundleの読み込み方法は自由に指定できるようです。</p>
<p>メインのアプリは通常通りassetsに配置し、サブのアプリはサーバからInternal Storageにダウンロードしたbundleを使います。</p>
<p>今回はAndroidのみで試しました。</p>
<h2>React Nativeプロジェクト</h2>
<p>以下のようにプロジェクトを用意し、index.jsをメインのアプリ、index.sub.jsをサブのアプリとします。</p>
<pre><code class="language-plaintext">├── android/ (Androidのプロジェクト)
├── index.js
├── index.sub.js
├── node_modules/
└── package.json
</code></pre>
<p>index.jsは<code>Main App</code>の文字列を中央に表示するだけのアプリです。index.sub.jsも同じように、少しだけ見た目を変えたものを用意します。</p>
<pre><code class="language-jsx">class HelloWorld extends React.Component {
  render() {
    return (
      &lt;View style={styles.container}&gt;
        &lt;Text style={styles.hello}&gt;Main App&lt;/Text&gt;
      &lt;/View&gt;);
  }
}

var styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
  },
  hello:{
    fontSize: 30,
    textAlign: 'center',
  },
});
</code></pre>
<h2>設定</h2>
<p><code>build.gradle</code>の<code>project.ext.react.entryFile</code>に<code>index.js</code>を指定します。これによりindex.jsのビルドファイルがassets/下にindex.android.bundleとして配置されます。</p>
<pre><code class="language-jsx">project.ext.react = [  
        entryFile: &quot;index.js&quot;,  
        bundleInDebug: true,  
        bundleAssetName: &quot;index.android.bundle&quot;
]  
</code></pre>
<p><code>index.sub.js</code>は手動でビルドし、サーバから配布します。ビルドファイルは<code>index.sub.bundle.js</code>という名前にします。</p>
<pre><code class="language-shell">&gt; react-native bundle --platform android --entry-file index.sub.js --bundle-output index.sub.bundle.js --dev false
&gt; http-server ./  #https://www.npmjs.com/package/http-server
</code></pre>
<h2>Androidアプリの実装</h2>
<p>Androidアプリは単一のActivityを持ち、Activity上に二つの<code>ReactRootView</code>と<code>ReactInstanceManager</code>を保持して、二つのReactNativeアプリを読み込む構成にします。サブアプリはメインアプリの上に小さく重ねて表示させます。</p>
<pre><code class="language-java">public class TopActivity extends AppCompatActivity {
  public static final String SUB_BUNDLE_URL = &quot;http://172.16.1.58:8080/index.sub.bundle.js&quot;;

  private ReactRootView mainReactRootView;
  private ReactRootView subReactRootView;

  private ReactInstanceManager mainReactInstanceManager;
  private ReactInstanceManager subReactInstanceManager;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_top);
    final FrameLayout rootLayout = findViewById(R.id.root_layout);

    //mainReactInstanceManagerのセットアップ
    mainReactRootView = new ReactRootView(this);
    mainReactInstanceManager = ReactInstanceManager.builder()
      .setApplication(getApplication())
      .setBundleAssetName(&quot;index.android.bundle&quot;)
      .addPackage(new MainReactPackage())
      .setCurrentActivity(this)
      .setInitialLifecycleState(LifecycleState.RESUMED)
      .build();

    mainReactRootView.startReactApplication(mainReactInstanceManager, &quot;MainReactNativeApp&quot;);
    //メインAppは全画面表示
    rootLayout.addView(mainReactRootView, new FrameLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT));


    //index.sub.bundle.jsをダウンロードし、subReactInstanceManagerをセットアップ
    new AsyncTask&lt;Void, Void, Boolean&gt;() {

      @Override
      protected Boolean doInBackground(Void... voids) {
        return fetchSubBundle();
      }

      @Override
      protected void onPostExecute(Boolean isSuccessful) {
        if (!isSuccessful) return;

        subReactInstanceManager = ReactInstanceManager.builder()
          .setApplication(getApplication())
          .setJSBundleFile(getSubAppBundleFile().getAbsolutePath())
          .addPackage(new MainReactPackage())
          .setCurrentActivity(TopActivity.this)
          .setInitialLifecycleState(LifecycleState.RESUMED)
          .build();

        //サブAppは画面上部に小さく表示
        FrameLayout.LayoutParams params = new FrameLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, 600);
        params.gravity = Gravity.TOP;
        params.setMargins(30, 30, 30, 0);

        subReactRootView = new ReactRootView(TopActivity.this);
        subReactRootView.startReactApplication(subReactInstanceManager, &quot;SubReactNativeApp&quot;);
        subReactRootView.setLayoutParams(params);

        rootLayout.addView(subReactRootView);
      }
    }.execute();
  }

  private File getSubAppBundleFile(){
    return new File(TopActivity.this.getFilesDir(), &quot;index.android.sub.bundle&quot;);
  }

  private boolean fetchSubBundle() {
    try {      
      ResponseBody body = new OkHttpClient()
        .newCall(new Request.Builder().url(SUB_BUNDLE_URL).build())
        .execute()
        .body();
      if (body == null) return false;

      BufferedInputStream input = new BufferedInputStream(body.byteStream());
      OutputStream output = new FileOutputStream(getSubAppBundleFile());

      byte[] data = new byte[1024];
      int count;
      while ((count = input.read(data)) != -1) {
        output.write(data, 0, count);
      }

      output.flush();
      output.close();
      input.close();
    } catch (IOException e) {
      return false;
    }
    return true;
  }

  @Override
  protected void onPause() {
    super.onPause();
    mainReactInstanceManager.onHostPause(this);
    if (subReactInstanceManager != null) {
      subReactInstanceManager.onHostPause(this);
    }
  }

  //onResume, onDestroyも同様に両方のmanagerにdispatchする
</code></pre>
<p>アプリを起動すると、正しくメインアプリの上にサブアプリが重なって表示されるのを確認できました。</p>
<img width="300" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3cfc0dba-9117-46c2-b6fd-b0c7f884420f/screenshot-1543926720606.jpg"/>
<p><code>ReactInstanceManager</code>のインスタンス毎にJSのコンテキストが作られるようで、実際、index.jsでglobalに定義した変数をindex.sub.jsからは参照できませんでした。</p>
<p>実際に活用するためには考えるべきことがまだまだ沢山ありますが、複数のReactNative アプリの共存を動かして試すことができました！</p>
<p>今回作ったサンプルアプリは以下にあげました。<br>
<a href="https://github.com/takaaki7/MultiReactNativeApp">https://github.com/takaaki7/MultiReactNativeApp</a></p>
<h2>最後に</h2>
<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
<p>_IgY4VF5ukBo_EUKZLg&quot; data-width=&quot;300&quot; data-height=&quot;60&quot;&gt;</div></p>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


React Nativeで複数のアプリを共存させられるか試してみた | PLAID engineer blog

React Nativeで複数のアプリを共存させられるか試してみた

<p>こんにちは。エンジニアの@kei-tamiyaです。2018年4月に新卒で入社して8ヶ月ほど経ちましたが、エンジニアとして実際に何を学んだのか、入社する前に思っていたイメージは実際働いてみてどうだったのか、について振り返ってみたいと思います。<br>
　こちらの記事は<a href="https://qiita.com/advent-calendar/2018/plaid">PLAID Advent Calendar 2018</a> 4日目の記事でもあります。</p>
<h2>想定読者</h2>
<p>PLAIDの「人」や「考え方」に興味を持っている方<br>
PLAIDにはエンジニアとしてどんな成長機会があるか知りたい方</p>
<h2>入社前に抱いていたイメージ</h2>
<p>入社する前には累計2,3ヶ月ほどインターンをしていました。その間に、入社すると思考面と技術面に関して以下のようなことが経験できて得られそうだなと考えていました。</p>
<h3>思考面</h3>
<p><strong>(A) 物事の本質を捉える力を高められそう</strong></p>
<ul>
<li>常に目的に対して正しいと思う意見をぶつけ合う</li>
<li>間違っているものや考えはガンガン捨てる</li>
</ul>
<p><strong>(B) 自分が最高に楽しいと思える何かを見つけられそう</strong></p>
<ul>
<li>プロダクト愛と熱量を持っている人が多い</li>
<li>その環境でのめり込んで開発すると気づきがありそう</li>
</ul>
<h3>技術面</h3>
<p><strong>(C) 全般的な開発技術を習得できそう</strong></p>
<ul>
<li>フロントエンド・サーバーサイドで職種を分けていない</li>
</ul>
<p><strong>(D) サーバーサイドの開発力をしっかり高められそう</strong></p>
<ul>
<li>これまでフロントエンドの経験が多めだったのでサーバーサイドを強めたい</li>
<li>高トラフィックを前提にして、多種のDBを扱う経験ができそう</li>
<li>GCPをメインで使い倒していて、かなりのトラフィック・データ量がありそうなのも面白そう</li>
</ul>
<p><strong>(E) 早い段階で高難易度な経験を積めそう</strong></p>
<ul>
<li>KARTEが機能単位でプラガブルな（拡張性の高い）実装になっている</li>
<li>一人で丸ごと実装を担当できそう</li>
</ul>
<p>これらそれぞれが実際にはどうだったのかを振り返ってみます。</p>
<h2>実際にはどうだったのか</h2>
<h3>思考面</h3>
<p><strong>(A) 物事の本質を捉える力を高められそう</strong></p>
<p>実際にこの考え方を感じる場面・実践する場面は非常に多いです。「これってなんでやってるんだっけ？」「そもそも何を解決したいんだっけ？」という問いに立ち返り、元来の目的を再認識した上で現状で取りうるより良い方針に修正をし、トライするといった改善を行えるのは非常に建設的で面白い環境だなと思います。</p>
<p>そもそも私は人の感情を考えてなるべく不快な気持ちにさせないように発言・行動することを大切に生きているので、言葉を意識しすぎて逆にわかりにくくなったり、わざわざ議論しなくてもいいかと問題解決から遠のいてしまうことが多い人間だったのですが、「ああ、ここまではっきり言っていいんだ」と気付かされたのは大きな驚きでした。</p>
<p>「自分たちが解決したいことは目の前の課題および長期的な目標であり、それは達成すべき非常に重要なものである」という前提に立って考えると、事実ベースで課題の本質を認識して発言・共有することでチームとして向き合って解決していくことが重要で、目先の考えすぎな気遣いや感情等は不要なものである場面がほとんどなのだと認識できたのは思っていた以上に自分が成長できたことだなと感じています。</p>
<p><strong>(B) 自分が最高に楽しいと思える何かを見つけられそう</strong></p>
<p>私はそもそも何か特別にやりたいことがある人間ではありませんが、最高にのめり込めることを見つけることが目下の人生の目標だったりします。弊社のメンバーは前職までの経験でWeb上のユーザー体験に対して疑問や課題を感じたために、KARTEの「多様なデータをひとりの人として理解し、一人ひとりに合わせた体験づくりをする」という世界観に共感しているメンバーが多く、そのモチベーションを間近で感じて自分の探したい「何か」の参考にしたいなという思いがありました。</p>
<p>最近では月に1度エンジニア全体で、長期的な未来にKARTEを通して成し遂げたい理想像を全員でディスカッションするような場を設けています。普段の開発で精一杯になって視野が狭くなっていましたが、一歩引いて開発している意義を理解することによって、以前よりも主体的な立場で将来を見据えて開発に取り組めるようになりつつあると感じています。<br>
　<br>
自分の中でまだ「何か」は見つかってはいませんが、何かを成し遂げていくということは「圧倒的な熱量」と「覚悟」が必要なんだなと学んでいます。</p>
<h3>技術面</h3>
<p><strong>(C) 全般的な開発技術を習得できそう</strong></p>
<p>経験できています。役割を完全に分離して開発する形態は、どこか一部門の開発が遅れることでボトルネックになった場合に開発全体が滞ってしまったり、効率が悪くなってしまうような状態が好きではなかったので、機能ごとにIssueを切ってプロジェクトの進行状況やチームの状況次第で誰がどのIssueを担当してもある程度開発できる点はストレスフリーで良いです。</p>
<p>しかしながらまだまだ自分の開発速度も遅く、機能単位で担当する分、大きな機能を丸ごと実装する際はかなり時間がかかってしまって自分がチームのボトルネックになってしまうケースは多いです。この点は課題ですが、割と重要な機能であっても、実力がある程度伴っている場合においては自分で手を挙げれば任せてもらえるので、もっとできることを増やしていこうというモチベーションは高まります。</p>
<p><strong>(D) サーバーサイドの開発力をしっかり高められそう</strong></p>
<p>これも経験できています。学生の頃はフロントエンドの開発をメインで行っていましたが、先述したように幅広く開発技術を習得したい思いもあり、大規模トラフィックを考慮したDBの設計・運用ができて、開発速度の速い環境が良いなと考えていました。実際に規模の大きい配信機能の修正を担当する機会もあり、使われている諸々のDBの仕様を色々調べてキャッチアップし、コードを順に追いつつ理解して実装することで少しずつ実装力が上がってきていると感じています。<br>
　<br>
今年特に多く触れた機能の例としては、Node.jsからのBigQueryやSpannerの操作、QueueとしてのMongoDB, Spanner, Redis, Cloud Pub/Subの活用、Redisを用いた重複配信の制御などの実装・修正・レビューを行い、課題の解決手段の幅が非常に広がりました。</p>
<p><strong>(E) 早い段階で高難易度な経験を積めそう</strong></p>
<p>開発要件が多い新規の機能を少人数のチームで実装していたこともあり、大きな機能単位で担当する機会は早い段階で得られました。方針が定まっていない状態で大きめの機能を担当した際は、必要要件は何があるのかを誰に聞いて、どの粒度でIssueを分割してどの順で開発を進めれば良いのかがわからず相当な時間がかかってしまいました。技術力が至らなかったのはもちろんですが、どちらかというと仕事の進め方・コミュニケーションの取り方の点で圧倒的に力不足を感じて悔しかったので、「エンジニアリング組織論への招待」を読むなどして自分の何が問題だったのかについて冷静に理解して、不確実性と向き合う日々を絶賛送っています。</p>
<h2>学んだこと</h2>
<p>ここまでの内容を一度まとめると、以下のことを学び、徐々にできるようになってきているなと実感しています。</p>
<ul>
<li>目的を達成するために、不要な感情を切り離して、本質的な課題に対して向き合うこと</li>
<li>適切なコミュニケーションによって課題を理解し、解決可能な単位に分割すること</li>
<li>目の前の課題と長期的な課題を適切に捉えることで、主体的に開発に参加すること</li>
<li>Node.js, Vue.js, 各種DB（MongoDB, Redis, BigQuery/BigTable/Spanner等のGCP周り）を用いた開発力の向上
<ul>
<li>大規模トラフィックを考慮した実装</li>
<li>実装力（適切な実装方法を考える力、コーディング速度や可読性）</li>
<li>知らない技術を使用する際のキャッチアップ力</li>
</ul>
</li>
</ul>
<p>思考に関しては、入社前に体験できそうだと思っていたことを実践し自分なりの解釈をすることで新たな発見と学びを獲得し、技術に関しては新たな「学び」というよりは着々とできることが広がっている感覚です。</p>
<h2>逆に自然には学べていないこと</h2>
<p>もともと得たかったものは意識して取り組んでいることでもあり、ある程度身につくのは当然なので、逆にあまり伸びていない能力や課題感についても触れておきます。</p>
<ul>
<li>フルスクラッチでの開発力・企画力</li>
<li>厳密なスケジュールや方針を立てる力・厳格なテストを書く力</li>
<li>確実に予定通りに達成していく力</li>
</ul>
<p>現状での開発は基本的にKARTEの開発がメインで、新規事業としては<a href="https://karte.io/product/app/">KARTE for App</a> や<a href="https://karte.io/product/datahub/">KARTE Datahub</a>などの規模感の大きい機能を実装する形式なので、新規プロダクトを完全にゼロから開発する機会はまだ経験していません。現状で稼働している環境との親和性を考えてアーキテクチャを考える機会は多いですが、フルスクラッチでアーキテクチャ・フレームワーク等を考えて実装したり、ビジネスプランそのものを考えるなどの機会は少ないです。</p>
<p>また、スピード感をかなり重視し、今書いているコードは全て壊すぐらいのつもりで書く文化なので、全体の完全な設計や綿密なスケジュールを立てたり、仕様書通りに実装をするといったスキルは身についていません。テストに関しても、サーバーサイドのユニットテストがメインでコア部分をしっかり守る程度で、厳格に取り組んだ対象とは言えないです。</p>
<p>綿密な計画を立てないのは、より良い方針が浮かぶことでの仕様変更があったり、差し込みがあることを前提としていたり、「その場しのぎの実装」ではなく「少し時間をかけても根本的解決・より良い状態となる実装」を選ぶ傾向があるため、決められた時間内にある一定量のタスクを確実にこなしていくようなスキルは意識しないと高まらないと感じています。社内の開発スピードは非常に早いので、現状では成長余地を見込んで任せてもらえる内容も、「より良いものを作るためならどれだけ時間をかけてもいいんだ」といった勘違いをしてズルズルと長引かせていては自分がボトルネックになってしまいます。</p>
<p>そのため、意識的にミニマム機能を実装する期限を設定したり、この時間内にこれだけの機能を実装し終える、といった目標設定を都度しながら開発する必要性を感じています。</p>
<h2>まとめ</h2>
<p>本記事では、PLAIDの新卒エンジニアとして8ヶ月働いたことで私が学んだことを、入社前に抱いていたイメージと実際に感じたこととを比較することで考察しました。<br>
特に、課題への向き合い方や適切なコミュニケーションの重要性についての思考の変化と、KARTEの開発を通して経験できた技術/あまり自然には学べてはいない能力の一例を紹介しました。</p>
<p>なお、この記事の内容は完全に私の主観によるものですが、チーム環境や開発時の状況によって得られる経験も違うため、あくまでも1人のエンジニアの体験記として捉えていただけますと幸いです。</p>
<h2>最後に</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するPLAIDでは、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に入社して何を学んだのか、入社する前に思っていたイメージは実際働いてみてどうだったのか、について振り返りました。

新卒エンジニアから見たPLAID、そこで得られた経験と学び | PLAID engineer blog

新卒エンジニアから見たPLAID、そこで得られた経験と学び

<p>はじめまして、エンジニアの nito です。PLAID Advent Calendar 2018 の三日目の記事でもあります。</p>
<p>最近は KARTE の開発者向けのプラットフォーム開発を主戦場に、API の仕様策定や開発者向けの管理画面の実装、ドキュメンテーションなどを担当しています。</p>
<p>今回は <a href="https://support2.karte.io/update/2018/12/12347/">12/3 にリリースした KARTE の開発者向けプラットフォーム「Developer Portal」</a> の開発をおこなううえで、大切にしていた <strong>Developer Experience (DX)</strong> という考え方をご紹介します。</p>
<h1>KARTE Developer Portal とは?</h1>
<p><a href="https://developers.karte.io">KARTE Developer Portal</a> は KARTE が提供する開発者向けプラットフォームです。主に次の2つの機能で構成されています。</p>
<ul>
<li>ドキュメント: 具体的なユースケースに則した使いかの説明をするガイド・技術仕様を網羅するリファレンス</li>
<li>管理コンソール: KARTE の API や Webhook など開発者向けの機能にアクセスし管理する。</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e45005b-8956-41e9-bad1-6f5a928e5788/Screen-Shot-2018-12-03-at-4.49.26.png" alt="Screen-Shot-2018-12-03-at-4.49.26"></p>
<h1>Developer Experience とは?</h1>
<p>DX は、2011年に UX Magazine で投稿された <a href="http://uxmag.com/articles/effective-developer-experience">Effective Developer Experience</a> という記事で紹介されています。<br>
以下は一部引用したものになります。</p>
<blockquote>
<p>Platform product owners must be concerned with assisting developers in accomplishing this if end users are to have a good user experience overall. Attention to these details is called developer experience (DX), ...</p>
</blockquote>
<blockquote>
<p>(訳) エンドユーザーに、そのプラットフォーム上で、優れた体験をさせたいと考えているならば、プラットフォーム・オーナーは開発者がこれを達成するのを手助けしなければならない。そして、こうした開発者への細やかな配慮のことを Developer Experience (DX) と呼ぶ</p>
</blockquote>
<p>続けて、次のように言っています。</p>
<blockquote>
<p>and enabling app developers to be successful through better DX will create a more successful UX for the platform product.</p>
</blockquote>
<blockquote>
<p>(訳) より優れた DX を通して開発者を成功させることで、プラットフォームのユーザー体験をさらに成功させるだろう</p>
</blockquote>
<p>また、<a href="https://www.infoq.com/news/2015/10/api-developer-experience">What is API Developer Experience and Why It Matters</a> では、API 設計に対して DX という考え方を拡げ、</p>
<blockquote>
<p>API developer experience is a relatively novel focus aimed to improve API design so it provides a seamless experience to developers when writing software. It can help increase programmers’ efficience and make it easier for developers to achieve goals on behalf of end users.</p>
</blockquote>
<blockquote>
<p>(訳) API Developer Experience は、API 設計を良くするための目標としては比較的新しく、開発者にシームレスな開発を可能とします。そして、プログラマーの効率をあげ、開発者がエンドユーザーの利益になるように目標達成するのを簡単にすることができます。</p>
</blockquote>
<p>と伝えています。</p>
<p>DX は、開発者が気持ちよく生産的に開発できるかどうかに注意を向け、開発者の体験を良くすることで、それが結果としてエンドユーザーの良い体験につながるという考え方です。</p>
<h1>KARTE Developer Portal で実際に注意したこと</h1>
<p>この考え方は、タイトルにもあるように、KARTE Developer Portal を開発する上で非常に大事にしています。<br>
ここからは、実際に DX を意識したところ、ここでは、とくにドキュメンテーションに関して気をつけたところを、いくつか紹介していきます。</p>
<h2>実際のユースケースに合わせたガイド</h2>
<p>KARTE Developer Portal のドキュメントでは、KARTE が提供している API やフロントエンドから利用できる JavaScript モジュールなどの仕様をリファレンスとして網羅しています。しかし、(開発者の方なら経験があるかと思いますが、) リファレンスだけで、すべてを理解するのはかなり厳しいと思われます。</p>
<p>そのため、リファレンスで記載されている各API や関数の使い方としてガイドを提供しています。ガイドは、どのような目的で、どのように使うのかを例 (サンプルコード) を交えて紹介しているので、開発者が迅速に開発に取り掛かることができます。</p>
<p>たとえば、以下は [ガイド] &gt; [基本的な使い方] の「チャットボット連携」に関するドキュメントのタイトルですが、目的から記事にたどり着けるようにタイトルをユースケースを表すようにしています。また記事ごとに目的をもったシナリオと捉えて、動詞をタイトルにしているのも工夫のひとつです。</p>
<pre><code class="language-plaintext">チャットボットと繋げる
├── チャットボット連携のセットアップ
├── ユーザーにメッセージを送信する
├── ユーザーのメッセージを受け取る
├── ユーザーの担当者を変更する
└── ユーザーの担当者変更情報を受け取る

</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/82c73a32-efa4-4018-81f1-13173007a1a7/Screen-Shot-2018-12-03-at-22.16.04.png" alt="Screen-Shot-2018-12-03-at-22.16.04"></p>
<h2>コンセプトを最小限で理解するためのチュートリアル</h2>
<p>また、そもそもプラットフォーム上で開発する場合、そのプラットフォームがどのようなプロダクトで、どのようなコンセプトを持ったプロダクトであるかを理解することも非常に重要になります。そこで、[クイックスタート] というチュートリアルを設けて、KARTE の最小限の基本的な機能をさらいながら、そのコンセプトを理解できるコンテンツも提供しています。</p>
<h1>おわりに</h1>
<p>本記事では、Developer Experience という考え方を紹介しました。KARTE Developer Portal では、DX をもとに、紹介したドキュメントをはじめ、API 設計などにも適用しており、開発者、ひいては KARTE ユーザーに良い体験を提供することを目指しています。</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
<p>_IgY4VF5ukBo_EUKZLg&quot; data-width=&quot;300&quot; data-height=&quot;60&quot;&gt;</div></p>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方; KARTE の開発者向けプラットフォーム「Developer Portal」の開発をおこなううえで、大切にしていた Developer Experience (DX) という考え方をご紹介します。


開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方 | PLAID engineer blog

開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方

<h1>0. はじめに</h1>
<p>PLAIDのEngineerの 大平和史 (<a href="https://twitter.com/tai_hey2?lang=ja">@tai-hey</a>) です。</p>
<p>前職でSEとして金融系超大規模プロジェクト(数年、数十億円規模、最大数百人)を経験し、現在は真逆となる小規模プロジェクト(4人チームでのサービス開発)でスタートアップのエンジニアとして経験を積んでいます。</p>
<p>ミッションクリティカルな、一つのエラーでも業務影響が存在する大規模な品質最重要のシステムと、toBではあるものの、攻めの開発かつスピード重視のSaaSスタートアップでの開発手法に目的と手法にかなりの差異を感じる毎日です。</p>
<p>それぞれのシステムは価値を提供するビジネスに合わせて作られるため一長一短であり、スピード重視・品質重視か、またそのバランスは生み出すビジネスの価値や目的に沿って特徴があります。その中でプレイドのこだわりはスピード重視の攻めの開発です。社員数を増やし、日々開発を進めていく中で、プロジェクトの規模が大きくなってもいかに開発スピードを落とさずにいれるかの対策を考察していきたいと思います。</p>
<p></p>
<h4>メッセージ</h4>
<p>今回のブログのメッセージをここで先にお伝えしたいと思います。「構造が硬直しがちなシステムを、肥大化する前に最適な単位に疎結合・高密度にアップデートし続け、 開発スピードを維持する」となります。</p>
<h1>1. ビジネスモデルと社会インパクトの特徴について</h1>
<p>まず、そもそもの品質重視の大規模システムと、スピード重視の開発では、ビジネスモデルの生まれや経緯が違うことが大きな源流となります。今後の考察にも役に立ちますので先に整理しておきたいと思います。<br>
両者には大きなビジネスモデルの差異(受託開発かプロダクト・アウトか)と社会インパクトについての観点から分析します。</p>
<h3>1.1 ビジネスモデル</h3>
<p><strong>大規模システム開発のビジネス(基本受託開発となる)</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b8de494-eac4-41ab-94f1-0767eb28fb8b/biz_jutaku-1.png" alt="biz_jutaku-1"></p>
<p>大規模システムは基本的に顧客から外部に開発を外注します。大規模システムの目的はミッションクリティカルで、SLAが他の業界にくらべ高く、求められる品質も高い傾向にあります。</p>
<p>そのため顧客の社内では開発要員の調整や、品質の保持を実現が難しいため、開発手法はウォーターフォールで実施し、顧客から求められた仕様でガチガチにシステム構築を行い、受託会社が顧客のシステムを構築します。</p>
<p>受託開発では顧客が仕様を決めてそれ通りに作るため、ソースコードなどの資産は顧客のものになり、顧客のものを修正することになるので修正一つ一つに契約の合意形成のプロセスが発生します。また、顧客のビジネスにほぼ100％アジャストすることが求められます。</p>
<p>作った後の話にはなりますが品質を求める実例としては下記のようなケースがあります。これで温度感をイメージしていただければと思います。</p>
<p>例えば</p>
<ul>
<li>業務を止められないので業務停止中に原則で夜10時〜朝の間に作業を行わなければならない</li>
<li>夜間一つのジョブが落ちてしまったら業務開始までに必ずリカバリする</li>
</ul>
<p>等があります。<br>
　　　　　<br>
　　　　　<br>
　　　　<br>
<strong>SaaSのビジネス</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7502ecca-8ffb-4e46-ae0b-70f0a4554c36/biz_SaaS-1.png" alt="biz_SaaS-1"></p>
<p>SaaSプロダクトは自社製品としてプロダクトを開発し、顧客のシステムと連携する形になるため、プロダクトの仕様は自社で決めてそれに顧客の業務やシステムが、ある程度アジャストする方針になります。プロダクトのソースコードも自社資産になるのでコストの払い出しや修正の要否は自社で検討することになります。個別の顧客ビジネスに必ずしも100％アジャストしなくてもよいですし、プレイドの場合はKARTEを用いて新たな接客の形態や業務を提案することが弊社ビジネスの価値となります。</p>
<h3>1.2 社会インパクト</h3>
<p>次に社会インパクトについて比較してみます。</p>
<p><strong>大規模システムの社会インパクト</strong></p>
<p>受託大規模開発では顧客のビジネスや業務を理解し、深く入り込んでいくことがビジネスの強みです。個社適用でシステムを構築しており、システム作成当時から顧客数やデータ量が元々多いため、一つのミスのインパクトが社会的に大きいケースが多く、構造の変更よりも社会インフラとしての現状をいかに守るかの判断が重要視されます。</p>
<p><strong>SaaSスタートアップでの社会インパクト</strong></p>
<p>スタートアップも同様ではじめは小さい容量や機能でスタートすることが大半です。そのため始めは社会インパクトが小さいため実現可能性のスピードが重視される傾向にあります。ただし、今後利用顧客数も増え、インパクトが少なからず大きくなり、データ量も増大していく（弊社の場合既に大きくなっています）傾向にあります。<br>
また、利用機能やソースコード量も増えてきます。それにより既存の顧客を守るために保守的になりすぎてしまうのはビジネスの成長を考えた時に足かせとなる可能性があります。スピード減は事業リスクとなりうるので、そうならないような事業推進について考えることが必要です。</p>
<h1>２． 構造が硬直しがちなシステムを、肥大化する前に最適な単位に疎結合・高密度にアップデートし続ける</h1>
<p>いよいよビジネスモデルの前提を1章で踏まえた上でSaaSスタートアップがプロダクト規模、開発規模が大きくなってきた場合、2.1のモデルを使って、どのようなリスクがあり方向性が必要かを考察したいと思います。前職で超大規模システムに携わってきた際に感じた反省から、プレイドでも同様のデメリットを発生させないために攻めのアクションを考察していきたいと思います。</p>
<h3>2.1 価値創造のためのシステムとその構造について</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8ed7388f-7fe3-44a2-806a-3152c5671296/model.png" alt="model"></p>
<p>システムとビジネスを取り巻く環境は「価値、顧客のビジネス、管理/ ルール、処理、構造」を構成要素として把握することができます。構造(アーキテクチャ)を構築して、処理(ソースコード)として記載し、管理(インプットから出力されるアウトプットデータの管理)します。そこに顧客のビジネスが乗り価値が生まれる。このモデルを元に各ビジネスとシステムの構造を考えます。</p>
<h3>2.2 超大規模システムの特徴と変遷について</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0dc46a52-a512-4342-8473-639ec072124c/2daikibo.png" alt="2daikibo"></p>
<h4>構造と処理を変えられないシステムは硬直化・肥大化する</h4>
<p>構築したシステムは10〜20年前のシステムが多いと思いますが、当時の最新のアーキテクチャで作られているはずです。ただ、そこからアーキテクチャの構造を変化させることはほとんどなく現在業務を行っています。<br>
ビジネス要件が追加された場合、処理を追加するためにソースコードは増大するのが普通です。複数サブシステムを一つのモジュールに入れてしまうようなモノリシックで構築したものはそのままとなります。</p>
<p>アーキテクチャを更改するタイミングは5年に一度サーバリプレース案件が発生する時があるのですが、サーバを単純リプレースするだけでかなりのコストとリスクがかかるので、ソースコードを見直してリファクタリングするような活動はされづらいです。その時の判断と企業には寄りますが、業務上最低限の移行（保守が切れるサーバを新しいものに移行する）で遂行されることが多いと思います。</p>
<p>このようにミッションクリティカルなシステムなためどうしても現行業務を死守しなければならないと、<br>
・処理（ソースコード）複雑性が上がってしまうが、ひとまず動くように処理を増大させる方向に傾きやすい<br>
・構造（アーキテクチャ）をドラスティックに変えるチャレンジが数年に一度のチャンスしかない<br>
※但し顧客の予算とリスクテイクの関係で最低限のリプレースしか行われないことが多い。<br>
　<br>
という選択肢を取らざるを得なくなってしまいます。<br>
　<br>
　<br>
そうすると構造を変えられないので、それを補うために処理（ソースコード）を分岐処理や冗長なコードで増大していきます。（今はクラウド化の流れが来ているが）サーバもオンプレミスのままで、アップスケールで対応するのがメインとなります。</p>
<p>また、増える仕様を管理するためにエクセルでの管理資料を増大させることになります。顧客のビジネス要件を満たすきめ細やかな処理を追加するたびにシステムやその管理が増大し、図の各階層のバランスが肥大化するようになります。</p>
<p>早い段階でアーキテクチャやソースコードの最適化や分割を行わないと、構造を硬直させたまま肥大化させてしまうことが私の経験上での反省です。</p>
<h4>顧客のビジネスとの密着度が硬直化の要素の一つ</h4>
<p>また、顧客のビジネスとシステムとの密着度も要因の一つと考えます。大規模システムはミッションクリティカルが多いため、システム停止などが顧客のビジネスに直結します。そのため無闇にシステム構造を変更させることもできないため硬直した巨大システムは肥大化を続けていき、構造の変革が更に難しくなってきます。</p>
<p></p>
<h2>2.3 KARTEのシステム構造としての特徴について</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/656a26a4-30c0-406d-86b3-e07d41777b53/2plaid.png" alt="2plaid"></p>
<h4>現状は最適に近いシステム構成</h4>
<p>相対してスピード重視のプレイドはどうでしょうか。<br>
　<br>
現状私が把握できているプレイドでの構造は上記のように認識しています。プロダクトリリースから3年半が経っていて、構築にあたって2010年代に作られたこともあり、最近技術を取り入れていると感じています。構造（アーキテクチャ）を見てみるとインフラはマルチクラウドで構成され、スモールスケールで増大が可能です。処理（ソースコード）に関しても日常的にリファクタリングが行われ、日々モジュール化が行われています。</p>
<p>構造も処理もそれぞれモジュールとして分割して、余計なソースコードは日々削除するようになっているので、余計な関数などは積極的に集約する活動が行われているように感じます。</p>
<p></p>
<h4>今後の勝負は既存のデータを守りつつ積極的に構造と処理を変革させることができるか</h4>
<p>現状はうまく行っているように見えますが、今後のリスクもはらんでいます。それぞれの処理は現状のコード量と実現したいビジネスのバランスがある程度取れている状態ではありますが、ソースコードの全体量とそれぞれのコード量が増大しているのは間違いないです。更に既存データ量も増大しているため、サーバ上にはかなりのデータ量が格納され続けています。</p>
<p>そうすると大規模開発の状態にもあった顧客に対するインパクトが少なからず増大する傾向になります。本当はアーキテクチャやソースコードをドラスティックに変えていきたいですが、KARTEに入っている既存データや既存顧客のビジネスを守りつつ開発を進めることになるので、そこを考慮しつつ開発することが必要となります。</p>
<p>ソースコードが肥大化する前に構造を硬直化させずに、アーキテクチャやモジュールを分割、共通化、最適化を積極的に行うべきと思っています。マイクロサービス的に細かくすればよいというわけではなく、構造を変革することを直近のコストを考えすぎて先送りにするのは問題と思っているので、都度最適な粒度を検討して分割するべきと思っています。</p>
<h4>顧客ビジネスとの密着度は疎結合でありつつ、顧客のビジネスにインパクトを与える機能実装が必要</h4>
<p>既存のデータを守りつつ構造と処理を変革させることが必要ですが、受託大規模開発と比べKARTEは汎用的な業務を提案していくスタイルなので、顧客業務との密着度を疎結合的にそのままキープしつつ、開発スピードを上げていくことが事業の価値と直結すると私は考えています。少なくとも密着度を上げすぎるような特定の顧客向けに個別の実装をするなどは避けたいと思っています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a70c3377-2169-4022-81ad-753353813224/2hikaku.png" alt="2hikaku"></p>
<h1>３． 直近の構造を変革させる攻めの活動</h1>
<p>1章の前提の比較、2章までの考察を踏まえて、最後に開発スピードを落とさないために必要であった、<br>
構造と処理を積極的に変革させていく例がありました。その例を紹介します。</p>
<h4>リポジトリの分割による構造と処理の最適化</h4>
<p>直近の活動としては肥大化した特定のリポジトリを分割する活動を行っています。現在プロダクトリリースから開発をしている既存の大きくなりがちなリポジトリを分割し、機能ごとにデプロイを行えるようリポジトリ分割の活動を始めています。</p>
<p>ディレクトリ構成の変更や、共通的に使用するモジュールの集約化や、最適化を行っています。</p>
<p>実際に分割直後の機能を触ってみたのですが、buildも十数秒かかっていたものが体感で一瞬で終わるまでになっています。今後のプロジェクトは常に構造を変革することを念頭に入れながら開発をしていきたいと思っています。</p>
<h4>エンジニアとして必要なのは開発時のプロジェクト判断は、構造と処理の変革を常に頭に入れておくこと</h4>
<p>今後様々な開発プロジェクトを推進していく立場になっていくと考えると、特に既存機能が関わる箇所については、顧客と常に相対している、ビジネスサイドとのコミュニケーションを今回の考察を元に推進していきたいです。</p>
<p>機能開発を進めていく際に既存顧客を守りすぎて開発スピードを落とす方向に開発を進めることは避けたいです。既存顧客は守りつつ、開発スピードを落とさない方向、または長期的に見た時に構造や処理をそもそも作り変える着想を持ちつつ、プロジェクト判断をしていこうと思います。</p>
<h2>仲間を募集しています</h2>
<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>みなさま初めまして！<br>
PLAID Engineer Blog初投稿の韓 徹（<a href="https://twitter.com/sskt0809">@sskt0809</a> ）です。</p>
<p>プレイドは、2018/11/3(土)に秋葉原UDXで開催された<a href="https://vuefes.jp/">Vue Fes Japan 2018</a>にプラチナスポンサーとして協賛しました。<br>
私はスポンサーセッションで参加者全員の前で登壇する機会もいただき、Vue Fes Japan参加者の皆さんに<a href="https://karte.io/">KARTE</a>について伝えることができました。</p>
<p>今回のブログでは、Vue Fes Japanの様子や、スポンサー参加の裏話などをお伝えします。</p>
<h2>会場の様子</h2>
<p>自分が会場入りした午前9:00の時点でPLAID以外の各スポンサー企業さんも準備が整っていて、すでに会場はほぼ完成していました。</p>
<p>ヘイ株式会社さんはトイレットペーパーをノベルティに、株式会社リブセンスさんはガチャガチャを用意したりと、ユニークなブースもあり、見るだけで楽しいブースもいくつかありました。</p>
<p>私たちはKARTEのバナーや50インチのディスプレイに公式動画を写し、ノベルティは弊社デザイナーが用意してくれたPLAIDとKARTEのステッカーとメッセージカードを同梱した渾身のステッカーセットを用意しました。<br>
（結果ステッカーセットを渡すと「こんなにステッカーもらえるの？！」って反応がもらえて、大成功でした。）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b9e49923-c8ae-483e-b779-4add5e8163be/45B2B854-035A-48D4-B649-5C62402E9464-2.JPEG.jpg" alt="45B2B854-035A-48D4-B649-5C62402E9464-2"><br>
<em>ブースの準備は整った！の様子。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b5999bcf-07d2-4d4c-b631-d90023827bd0/IMG_0875.JPG.jpg" alt="IMG_0875"><br>
<em>ノベルティのステッカーセット。来場者の皆様に好評でよかったです！</em></p>
<h2>そして開幕</h2>
<p>会場には続々と参加者が入場し、キーノート開始までに約300人の方が集まり会場は熱気に溢れていました。（会場スタッフやスポンサーの方を含むと400人強はいました。）<br>
そして、10:20にVue Fes Japan 2018主催のkazuponさんの開会の挨拶でイベントが開催されました。<br>
まず一発目のプレゼンはVue.jsクリエイターのEvan Youさんのキーノートです。Vue.js 3.0が登場する話、どこが2.x系と変わるかをプレゼンしていました。</p>
<p>そのEvanさんのプレゼンの次がお待ちかねのプラチナスポンサーセッションで弊社PLAIDの登壇です。登壇前はEvanさんの登壇の後であるのと会場の人数の多さのプレッシャーがありましたが、いっぱい練習したんだから大丈夫！大きい声で伝えたいことは強くゆっくり話す！って自分に言い聞かせてましたw</p>
<h2>登壇内容</h2>
<p>今回は「KARTEが1,000サイト以上でVue.jsを動かしている話」という内容で発表しました。以下がスライドです。</p>
<script async class="speakerdeck-embed" data-id="98c6724ce2c94580aa22383431fd7ba3" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>主な内容は以下です。</p>
<ul>
<li>プレイドでは、Vue.jsがリリースされた2014年からVue.jsをKARTEの開発で使用している</li>
<li>お客様がKARTEの管理画面で作成したアクション（エンドユーザーに出すポップアップなどのコンテンツのこと）もVue.jsで作られている
<ul>
<li>それらがお客様のWebサイト上（1,000サイト以上！）で動いている</li>
</ul>
</li>
</ul>
<p>プレゼンする前は緊張しましたが、話し始めるとちゃんと練習した甲斐があり、プレゼン自体は大きなミスなく話せたと思います。ただし、最後に言い間違って「ちゃいます、ちゃいます」というお茶目な関西弁が出てしまいました...。その関西弁についてのツイートが2ツイートくらいありました。今やいい思い出です！</p>
<p>発表後はツイートを見ると「KARTEの管理画面すごい！触ってみたい！」「650コンポーネントもあるんだ！」「2014年から使ってるんだ！」「関西弁に安心感を感じる」といったポジティブなツイートばかりだったので、安心と嬉しさがこみ上げました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7f2096f0-68a7-4413-84d9-343d334e7d25/04AA081E-AF0A-4C38-9D07-CFAC5F1F162F.JPEG.jpg" alt="04AA081E-AF0A-4C38-9D07-CFAC5F1F162F"><br>
<em>登壇時の様子。我ながら顔が硬いですね...。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3837230f-2643-47f6-8a33-e817229ae73f/Image-from-iOS.jpg" alt="Image-from-iOS"><br>
<em>聞いていただいた方々ありがとうございました！</em></p>
<h2>PLAIDのブースの様子</h2>
<p>プレゼンが終わったからと安心してはいけません。本当に会場の皆さんに魅力を伝えるのは発表の合間合間のブース対応なのです。<br>
発表見てブース来ていただいた人も多数いました。（弊社エンジニアであり、<a href="https://shiganai.org/">しがないラジオ</a>パーソナリティの池上に会いに来た方も多数いました。）</p>
<p>Vue.jsをどのように使われているかという質問はもちろん、KARTEがどういうことができるのか、サービス自身に興味を持っている方も多い印象を受けました。<br>
改めまして、ブースに来ていただいた方ありがとうございました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/78c2e7b4-783a-43a7-b933-9035f9acf530/Image-from-iOS--1-.jpg" alt="Image-from-iOS--1-"><br>
<em>ブースに多数の方々が来てくれました！</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bc056c5d-6cb1-49cd-85c0-3fa9d8367276/FC51D036-7939-4D81-9EA0-604039015FBD.JPEG.jpg" alt="FC51D036-7939-4D81-9EA0-604039015FBD"><br>
<em>エンジニアの民谷（タミー）もブース対応に参戦。ありがとう！</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2f677bec-23b4-44b6-946a-f71836d3a550/18C158A2-317C-48BC-BAD6-67730DD67073.JPEG.jpg" alt="18C158A2-317C-48BC-BAD6-67730DD67073"><br>
<em>エンジニアの野田(@positiveflat)はVue Fes Japanのスタッフとして大活躍していました！</em></p>
<h2>プレゼンで割愛した内容を一部紹介</h2>
<p>今回の発表はアクションの配信する箇所をメインに話しましたが、この内容にfixするまでにプレゼン内容に紆余曲折あり、説明したくても残念ながら割愛した部分を紹介したいと思います。</p>
<h3>Vue.jsをなぜ採用したか</h3>
<p>KARTE ではVue.jsがバージョン0系で登場した2014年から採用しています。当時、様々なフレームワークと比較しましたが、軽量でシンプルなフレームワークであること、状態管理のしやすさなどを理由にVue.jsに決めました。</p>
<p>実際には、学習ハードルが低く一部のデザイナーやフロント経験の浅いエンジニアでも直感的に使えるという特徴から、スピード感を持った開発を続けられています。また、ドキュメントやライブラリの充実など、Vue.jsコミュニティが活発である点もメリットを感じるところです。</p>
<h3>デザインシステムの導入</h3>
<p>PLAIDでは今年の頭からデザインシステム「BAISU（バイス）」の構築プロジェクトが始まりました。BAISUプロジェクトはKARTEのユーザー体験を良くし強いプロダクトを作るのが目的です。内部的にはデザイナーとエンジニアがよりスピード感を持って協業するために、デザイン原則、スタイルガイド、パターンライブラリを用意しました。</p>
<p>実際に一部の画面ではBAISUのガイドラインに沿ったリニューアルしたりと積極的にアップデートしています。弊社ではデザイナーもVue.jsを書くのでBAISUによりスピードを上げて開発できます。BAISUの詳細は後日、弊社デザイナーが書いてくれることを期待。</p>
<h2>最後に</h2>
<p>今回はVue Fes Japanの運営の方々、会場に来ていただいた皆さん、準備を手伝ってくれた弊社スタッフには本当に感謝しています。<br>
自分はこのような大規模なテックカンファレンスに登壇することは初めてで、新しい学びも多く、そして精神面でも色々鍛えられました！<br>
またこのような機会があれば、どんどん積極的に手を上げていこうと思います。</p>
<p>あと、Vue Fes Japanのアフターパーティは非常に豪華でEvan Youさんとも2ショット撮れたので最後まで大満足のカンファレンスでした！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5877741e-8196-4d88-a823-4f732167fc71/34C704BC-FFA2-4E37-8F73-5FAF34B4A683.JPEG.jpg" alt="34C704BC-FFA2-4E37-8F73-5FAF34B4A683"><br>
<em>アフターパーティの料理めちゃくちゃ豪華でした。とても美味しかったです。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3bd4258d-5878-48df-8317-b5dc7ea6cce8/IMG_1339.JPG.jpg" alt="IMG_1339"><br>
<em>Evanさんとの2ショット！寿司トークも盛り上がり、楽しかったです。</em></p>
<h2>仲間を募集しています</h2>
<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>


プレイドは、2018/11/3(土)に秋葉原UDXで開催されたVue Fes Japan 2018にプラチナスポンサーとして協賛しました。
Vue Fes Japanの様子や、スポンサー参加の裏話などをお伝えします。

Vue Fes Japan 2018に登壇してきました！#vuefes | PLAID engineer blog

Vue Fes Japan 2018に登壇してきました！#vuefes

Engineer Blog

Recent Article

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

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

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

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

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

React Nativeで複数のアプリを共存させられるか試してみた

新卒エンジニアから見たPLAID、そこで得られた経験と学び

開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方

超大規模システム経験者が考える、攻めの開発を続けるために大切なこと

Vue Fes Japan 2018に登壇してきました！#vuefes

Popular Articles

Popular Tags

Archives

Writers

Recent Article

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

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

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

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

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

React Nativeで複数のアプリを共存させられるか試してみた

新卒エンジニアから見たPLAID、そこで得られた経験と学び

開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方

超大規模システム経験者が考える、攻めの開発を続けるために大切なこと

Vue Fes Japan 2018に登壇してきました！#vuefes

Popular Articles

Popular Tags

Archives

Writers

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