Engineer Blog

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

<h1>はじめに</h1>
<p>こんにちは。<a href="https://twitter.com/calloc134">calloc134</a> といいます。<br>
情報工学系の学生で、普段は Web アプリケーション開発について学習しています。</p>
<p>今回、2024年2月から3月の5週間、プレイドでソフトウェアエンジニアとしてインターンシップを行いました。<br>
この記事では、インターンシップの振り返りとともに、学んだことや感じたことをまとめていきたいと思います。</p>
<h1>インターンシップ開始まで</h1>
<p>当インターンシップは、知り合いから紹介をいただいたことがきっかけで始まりました。<br>
自分は今までインターンシップを経験したことがなく、実務経験もありませんでした。<br>
プレイドのインターンでは、任される開発業務に必要な範囲で、社員さんと同じ環境・同じシステムに対して開発・コーディングを行うことができるという特徴がありました。<br>
この特徴は、実際の開発現場でどのように開発が進められているかを知りたい自分にとって、非常に魅力的でした。<br>
そのほか、技術領域が自分の普段の学習と近いことや、エンジニアインターンではフルリモートでも勤務でき、都心住みでない自分でも働きやすいことなどが決め手となりました。</p>
<p>インターン開始前にカジュアル面談を行い、簡単な技術スタックと業務内容について説明を受けました。<br>
プレイドでは、担当するプロダクトによって開発チームが分割されています。<br>
自分はMessageチームに入ることになったので、そのチームでの業務内容について説明を受けました。</p>
<p>Message チームは <a href="https://karte.io/package/message/">KARTE Message</a> というプロダクトを開発しています。<br>
当プロダクトは、データを元にメールやプッシュ配信、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<h1>技術スタック</h1>
<p>Message チームの技術スタックについては、同じ Message チームの方が書かれた<a href="https://tech.plaid.co.jp/intern-at-plaid-yurihttps://tech.plaid.co.jp/intern-at-plaid-kenshin">こちら</a>のブログ記事が参考になると思います。</p>
<p>簡単に解説すると、下記のような技術スタックになっています。</p>
<ul>
<li>フロントエンド
<ul>
<li>Vue(メイン)</li>
<li>React (一部メニュー)</li>
</ul>
</li>
<li>バックエンド
<ul>
<li>サーバサイド Node.js / Express.js</li>
<li>Golang</li>
<li>Java</li>
</ul>
</li>
<li>インフラ
<ul>
<li>MongoDB (データベース)</li>
<li>Redis</li>
<li>Cloud Pub/Sub</li>
<li>GKE (Google Kubernetes Engine)
<ul>
<li>ArgoCD (デプロイ)</li>
</ul>
</li>
</ul>
</li>
<li>DevOps
<ul>
<li>GitHub Actions</li>
<li>CircleCI</li>
</ul>
</li>
<li>監視
<ul>
<li>Sentry</li>
<li>Datadog</li>
</ul>
</li>
</ul>
<p>また、開発については、下記の技術を使用していました。</p>
<ul>
<li>Git/ GitHub (コード管理)</li>
<li>Docker Compose (開発環境)</li>
<li>Kind (Kubernetes in Docker)</li>
</ul>
<p>自分にとって、このインターンが初めてのエンジニアとしての実務経験となります。<br>
そのため、技術レベルも含めて最初はインターンで活躍できるかすごく不安でした。</p>
<h1>インターンの内容</h1>
<h2>最初の二日間</h2>
<p>インターン開始してすぐの二日間は、自分の開発環境を整えることから始まりました。</p>
<p>まず開発環境セットアップの資料を確認してインストールを行ったのですが、リポジトリの更新や仕様の変更により、資料と異なる部分がありました。また、資料に存在しないような issue に遭遇することがしばしば起こりました。</p>
<p>そこでSlack に開発環境構築専用のチャンネルが存在したため、そこにスレッドを立てて技術チームに質問を行いながら、一つずつ課題を解決していきました。<br>
フルリモートで意思疎通が難しくなるかもと心配していましたが、チームメンバーの皆さんが迅速に対応してくれたため、スムーズに進めることができました。<br>
また、解決した課題は、times と呼ばれる自分専用のメモ書きチャンネルにまとめていくことで、後から振り返りが容易になるようにしました。</p>
<p>一通り開発環境の構築が完了した後、開発環境構築の手引きとして社内ドキュメントを執筆しました。新しく入ったインターン生が同じような問題に遭遇した際に、自分の経験が役立つことを願っています。</p>
<h2>タスク</h2>
<p>開発環境の構築が完了した後、実際に開発に取り組むことになりました。</p>
<p>5週間という比較短い期間の中でもさまざまなタスクに着手してきましたが、ここでは一番印象に残ったタスクをピックアップし、振り返りたいと思います。</p>
<h3>LINEコンテンツのサムネイル生成機能</h3>
<p>KARTE Messageでは、メール、プッシュ配信、またはLINEを用いてユーザにコンテンツを送信することができます。</p>
<p>コンテンツの保存時に自動的にコンテンツのサムネイル画像を生成し、プレビューすることができる機能が存在するのですが、この機能が実装されているのはメール配信とプッシュ配信のみであり、LINE には実装されていませんでした。</p>
<p>そこで、LINEコンテンツのサムネイル画像を生成する機能を実装することになりました。</p>
<p><img src="https://ik.imagekit.io/plaid/f65747e2-4ff0-4320-ac33-48a8f6cd8c5e/Untitled(1).png" alt="Untitled(1).png"></p>
<p>タスクに取り組むにあたり、はじめに現状のサムネイル生成機能を理解するところから始めました。</p>
<p>まず管理画面上でコンテンツが保存されたタイミングでpubsubのキューにHTML と CSS の情報がメッセージとして登録されます。<br>
サムネイル生成用サービスがそのメッセージをsubscribeしており、メッセージの内容からサムネイル画像を生成する、というシンプルな構成でした。<br>
具体的には、メッセージから取り出した HTML と CSS の情報をpuppeteerでレンダリングし、レンダリング結果のスクリーンショットを生成、S3のsignedURLを用いてS3に保存します。</p>
<p><img src="https://ik.imagekit.io/plaid/b7ded338-bbcd-49b9-a48e-b50fa26298fd/Untitled(2).png" alt="Untitled(2).png"></p>
<p>ではLINEコンテンツのサムネイル生成機能を実装するためにはどのような実装が必要なのでしょうか。</p>
<p>現状の構成では、サムネイル生成用サービスのインターフェースはHTMLとCSSとなっています。</p>
<p>一方で、管理画面で表示しているコンテンツのプレビューはReactやTailwind CSSといったフレームワークを用いて描画しているため、ここからなんとかして等価のHTMLやCSSを生成する必要があります。<br>
あるいは、サムネイル生成用サービスを改修し、Reactコンポーネントを描画する方法もとりえます。<br>
<img src="https://ik.imagekit.io/plaid/3e8f31ec-5a52-4e93-9deb-30b69085fbf7/Untitled(3).png" alt="Untitled(3).png"></p>
<p>上記に加え、さらにいくつか設計の選択肢をリストアップし、メリットとデメリットを比較してみました。<br>
<img src="https://ik.imagekit.io/plaid/4edc16e3-5bc3-45fc-85d7-a02d22801e60/Untitled(4).png" alt="Untitled(4).png"></p>
<p>まず、一番目と二番目の選択肢は実装が難しいと感じたため、採用を見送りました。</p>
<p>そこで三番目の選択肢で実装を進めていましたが、画像がロード中の表示のままサムネイル生成されてしまう可能性があるという問題が発生しました。</p>
<p>これはサーバサイドでのReactコンポーネントのレンダリングの場合、画像の描画に時間がかかってしまうことが原因でした。<br>
従って、最終的に四番目の解決策である、クライアント側の React コンポーネントの HTML を取得してレンダリングする方法を採用しました。</p>
<p>クライアントサイドにおいて、React Componentの描画結果のHTMLはuseRefを利用することで簡単に取得できました。</p>
<pre><code class="language-tsx"> 	const previewHTMLRef = useRef&lt;HTMLDivElement&gt;(null);
 	const previewHTML = previewHTMLRef.current?.innerHTML

  return (
    &lt;&gt;
      &lt;LineEditorPreview controller={controller} previewHTMLRef={previewHTMLRef} /&gt;
    &lt;&gt;
  )
</code></pre>
<p>またスタイリングにはTailwindCSSを用いていたため、プレビューのコンポーネントで適用されているTailWindCSSのクラスをあらかじめビルドしておけば、プレビューに使われているCSS を生成することができます。</p>
<p>TailwindCSS は CLI での呼び出しに対応しており、構成ファイルを指定して手動コンパイルを行いました。</p>
<p>今回は、LINE プレビューに関連するコンポーネントを全て指定した構成ファイルを作成し、TailwindCSS CLI でビルドを行うことで、CSS を生成しました。</p>
<pre><code class="language-tsx">// 構成ファイル

/** @type {import('tailwindcss').Config} */
module.exports = {
  presets: [require('@plaidev/sour-react/tailwind')],
  content: [
    './src/page/template-edit/line-editor/preview.util.tsx',
    './src/page/template-edit/line-editor/preview.tsx',
  ],
  variants: {
    extend: {},
    animation: [],
  },
};
</code></pre>
<pre><code class="language-bash"># TailwindCSS CLI
tailwind -o path/of/output -c path/to/config -m
</code></pre>
<p>最終的にあらかじめ生成しておいたCSSをサーバー側で保持しておき、クライアントサイドから送られてくるHTML情報と合わせてpubsubに登録することで、LINE コンテンツのサムネイル画像を生成することができました。</p>
<p><img src="https://ik.imagekit.io/plaid/ec4733fa-d507-427b-bf8d-1bdd8cbdb5be/Untitled(5).png" alt="Untitled(5).png"></p>
<h1>インターンを振り返って</h1>
<p>社員さんと同じ環境で開発を行っていくことで、自分の中における仕事に対する解像度が上がったと感じています。<br>
これまでは個人的な開発しかしてこなかったため、自身のスキルが社会に出てから実際に活かすことができるのか不安でした。<br>
しかしプレイドのインターンシップを通じて、今まで学習してきたスキルが仕事に活かせることを実感し、また必要なスキルをどのように向上させていけばよいのかを学ぶことができました。</p>
<h2>インターンから得た学び</h2>
<h3>コーディングについての学び</h3>
<p>一例としては、コードの可読性やコメントの重要性を学びました。<br>
これまでの開発では自分がわかりやすいようなコメントや変数名を付けることが多かったのですが、プレイドではロジックの背景を意識したコメントや変数名を付けることが求められ、普段の開発でもこれらの意識を持って開発を行うようになりました。</p>
<h3>ロジックの理解</h3>
<p>また、ロジックを理解する大切さについても学習しました。<br>
挙げられた issue に関して場当たり的な修正は簡単に見えても、その根本的な原因は別のところにあることが多く、ロジックを含めて全体を理解することが重要であると感じました。</p>
<h3>issueの理解</h3>
<p>タスクの内容を深く理解することも重要です。</p>
<p>タスクは基本的に ~ ができない　のような課題形式で書かれているのですが、その解決には様々な方法が考えられます。その中でもどういった仕様が良いのかを正しく導くためには、既存ロジックの理解に加え、ドメインや顧客の理解も非常に重要となってきます。<br>
プレイドでは仕様に関するディスカッションも頻繁に行われるため、こういった能力も養うことができました。<br>
コーディングならAIでもできるようになってきている時代において、仕様設計はますます重要になると考えており、今後も磨いていきたいと思っています。</p>
<h1>インターンの特徴</h1>
<p>プレイドのインターンの特徴を以下にまとめました。</p>
<ul>
<li>実際のエンジニアと同じチームでプロダクト開発を行う</li>
<li>社員と同じ一連の開発フロー(issue アサインと方針の整理、修正とデプロイ、動作確認まで)</li>
<li>技術力に応じてコア開発に近いタスクへのアサインも可能</li>
</ul>
<h2>こんな人におすすめ</h2>
<ul>
<li>実際の開発現場で、開発のサイクルを学びたい</li>
<li>技術力を向上させたい・フルスタックで活躍したい</li>
<li>課題解決力の向上・設計・実装・運用までの幅広い業務経験を積みたい</li>
</ul>
<h1>まとめ</h1>
<p>自分にとって初めてのインターンでしたが、実際の開発を通して色々なことを指導していただき、無事やり遂げることができました。<br>
お世話になった社員さん、インターン生の皆さん、本当にありがとうございました。<br>
今後もこの経験を活かして、さらに活躍できるようなエンジニアを目指していきたいと思います。</p>
<p>プレイドの開発インターンに興味のある方はぜひ下記から応募してみてください。</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot の仕組みとその中で利用されている Azure サービスの役割について説明します。

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot

<p>こんにちは、エンジニアの白木です。</p>
<p>2023年4月 - 2024年2月までインターンとして開発に携わりました。</p>
<h2>自己紹介</h2>
<p>分散システム、データベースについて勉強しています。<br>
最近は、NewSQL、MPPデータベース、io_uring に最適化したデータベースの勉強をしています。</p>
<h2>プレイドのインターンに参加した理由</h2>
<p>プレイドの存在を知ったきっかけは<a href="https://bootjp.me/2023/independence_for_next/">ブログ記事</a>で、そこで大規模な分散システムを開発・運用していることを知りました。<br>
今まで分散システムを プロダクトに応用している例を身近で見たことがなかったため、 CX （Customer Experience）プラットフォームである KARTE を提供しているプレイドに興味を持ちました。そのような中、プレイドがインターン募集をしているを知り、是非参加したいと思い応募しました。</p>
<h2>インターンに入る前の前提知識の話</h2>
<p>インターンに入る以前は データ処理に関する知識は深く持っていませんでした。<br>
大規模データにおける分散処理フレームワークの Apache Hadoop、Apache Spark を用いたデータ処理について少しだけ知っていました。そのため、バッチ処理、ストリーム処理に関する 何となくのイメージがついていました。ただ、データ解析基盤を手を動かして作った経験はなく、どういったアーキテクチャで実装しているかのイメージが全くついていませんでした。<br>
データベースに関しては、MySQL、PostgreSQL などのOLTP(Online Transaction Processing) の処理向けのデータベースについては知識はありましたが、BigQueryのようなDWH (Data Warehouse) や OLAP（Online Analytical Processing) 向けのデータベースの知識は持っていませんでした。<br>
そのため、大規模データを処理するためにどのようなアーキテクチャで構築しているのか、大規模な解析用途で使われている データベースを扱えることが非常に楽しみにして参加しました。</p>
<h2>インターンで開発した内容の話</h2>
<p>インターン開発タスクの一つとして、KARTEのリアルタイム解析基盤に関わるAPIの改善を行いました。具体的にいうと、ユーザーの行動解析結果を取得するAPIが常に最新情報を返すようにするというものです。リアルタイム解析基盤の詳細については以下記事を参考にしてください。</p>
<ul>
<li><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a></li>
<li><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析</a></li>
</ul>
<p>タスクの説明を受けた際に、該当のAPIについて「強整合性モード」を実現したいという話を聞き、「結果整合性」、「強整合性」という概念を正しく理解するところから始めました。<br>
結果整合性では、データ読み込み時に最終的に全ての更新が反映されることを保証するものの、即時ではないため古いデータを返す可能性があります。強整合性においては、データ読み込み時に全ての更新が反映されたデータが返ってくることを保証します。<br>
今までビッグデータの処理の文脈で見る BASE特性、また、Apache Cassandra が採用している整合性モデルであることから概念自体は理解できました。しかし、どう実装するかについてイメージができていませんでした。<br>
最初はリアルタイム解析基盤の実装部分やインフラの構成図を元にどう実装するかを考えようとしましたが、どう実装するかのイメージはつかないばかりでした。そこでリアルタイム解析基盤の概略について書かれた<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">こちらの記事</a>を読み直し、大枠のロジックの理解に努めました。</p>
<p><img src="https://ik.imagekit.io/plaid/e52a44f2-f17c-467e-86c4-71e04bdbaeb4/Untitled.png" alt="Untitled.png"><br>
<em>Blitz の強整合を実現している図</em></p>
<p>結果、この図に強整合を実現するロジックが詰め込まれていることが理解できました。Realtime Queue にイベントを書き込んでおき、 Backend Servers で まだユーザーデータに反映されていないイベントを動的に遡求していくことで常に最新のデータを読み込めるという強整合性を実現していました。このアーキテクチャは今まで自分では想像ができなかった部分だったので、すごい仕組みだなと興奮しました。<br>
一度コンセプトを理解してしまえば、APIの実装部分も未反映のイベントを Realtime Queue から取得をして動的にユーザーデータを最新化すればいいという実装イメージが湧き、強整合性モードの実現も無事行うことができました。</p>
<h2>インターンで開発してみて得られた知見・経験</h2>
<h3>分散システムを用いた設計についての知見を得られた</h3>
<p>KARTE では秒間最大 13万4千イベント、月間 180PB を超える解析を行なっています。それを支えるプレイド独自のリアルタイム解析基盤は大規模な分散システムであり、アーキテクチャ上の工夫が随所に見られます。<br>
例を挙げると、リアルタイム解析で結果を同期的に配信するレイテンシー重視な処理と裏側でデータを溜めて一気に更新するスループット重視な処理を完全に分けて考えている点です。ここまで大規模かつシビアなパフォーマンスが求めれる環境だと、目的別にコンポーネントを分離することで、コスト最適化や柔軟なスケーラビリティが可能になっているなと感じました。<br>
分散システムを本で学習していても設計意図を肌で理解できず、中々身につかないなと思っていました。今回、インターンで実務を通じて分散システムに携わることでプロダクトと分散システムが結び付き、理解が深まりました。また、分散システムを通じて価値提供できる面白さを感じることができました。</p>
<h3>プロダクト・ビジネスへの貢献を意識した開発ができる</h3>
<p>プレイドのエンジニアは、技術的にかなり尖っています。しかし、技術だけを見ているだけでなく、プロダクト・ビジネスにも強くフォーカスしています。そのため、日々のタスクに関してもどのようにすれば最もプロダクト・ビジネスに貢献できるかを強く意識しています。例えば、単にプログラムを修正してタスクを完了するのではなく、将来的にどういった構想になっていれば良いかを意識してタスクに取り組んでいます。これによって、アーキテクチャの複雑度を下げています。ただ単にタスクを素早く終わらせる簡単な方法を取るだけでなく、将来までを意識して必要なコストは割いているのは、今後エンジニアとして働く上で学ぶべきことがありました。</p>
<h3>現場のエンジニア・ビジネスの方とディスカッションできる</h3>
<p>プレイドのインターンでは社員と同様の裁量を与えられてタスクに取り組めます。そのため、タスクに関しても現場の社員と同様にディスカッションできます。ディスカッションをすることでプレイドの社員の方の考えが分かり、タスクを進めるにあたりどういったことを意識すればいいのかを知れます。例えば、将来的に見ると価値は高いが直近だと賛否両論が生まれる機能をリリースする攻めの手を打つか、そういった手は打たず保守的な実装をするべきかについて、トレードオフを意識してタスクに取り組むことの重要性、締め切りが迫っている場合にどういったマインドでタスクに取り組むべきかなど、今後のエンジニア人生で大事なことをディスカッションを通じて学べました。</p>
<h3>仕事にやりがいを持っている社員と働ける</h3>
<p>プレイドの社員の方は仕事にやりがいを持っています。社員の方とお昼を一緒にしていると、どの方も楽しそうに仕事に関する話をします。楽しそうにやっている方、事業を本気で成長させようとしている方々と働ける経験は大事です。自分もこのように仕事に対してやりがいを持って働けるようになりたいと思えるようになりました。</p>
<h3>目的達成のためならばどのような技術でも扱う</h3>
<p>手を動かす Web エンジニアは大きく「フロントエンド」、「バックエンド」、「インフラ」などに分かれているところが多いと思います。プレイドでは、プロダクト・ビジネスにインパクトを与えるためならば、エンジニアはこれらの役割に囚われません。どのような領域の技術であっても役割に依らずタスクに取り組みます。役割に囚われずに 貢献していく姿勢は、人にタスクを依頼するコストを減らすことができ、高い生産性を出す上で大事だと感じました。このマインドは私も今後も続けていきたいです。また、どのような技術でも扱うため技術的な刺激を受ける機会がたくさんあります。自身も成長できる素晴らしい環境でインターンできました。</p>
<h2>最後に</h2>
<p>インターンを通じて、分散システムなどの技術的な成長を得られただけでなく、タスクを進めるにあたって考えるべきこと、エンジニアとしてのマインド、モチベーション高く働ける環境への解像度が高くなりました。</p>
<p>プレイドのインターンではエンジニアとして大きく成長できると思います。<br>
興味のある方は下記から応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び

<p>株式会社プレイドのCore Platformチームに所属しているBrownです。今回のブログでは2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。</p>
<h1>前提となるプレイド社内でのデータの管理方法</h1>
<p>プレイドでは、CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」の計測タグ経由で収集したイベントデータを元にWeb上のユーザーの行動を分析するサービスに加え、クライアント企業が社内外に保有する多種かつ大量なデータをKARTEに統合・連携して利活用できる<a href="https://karte.io/feature/integration/">KARTE Datahub</a>（以下、Datahub）を提供しています。<br>
KARTEの内外に散らばったサイロ化されたデータをDatahubに集約して、KARTEのプロダクトの中でユーザーのセグメントに活用したり、WidgetやKARTE内のアクション機能から参照したりすることができます。<br>
<img src="https://ik.imagekit.io/plaid/46c800d9-dd3d-4ff1-a605-a2cd7272ace9/datahub_case01_image-1.webp" alt="datahub_case01_image-1.webp"><br>
<em><a href="https://cxclip.karte.io/casestudy/tips/datahub_case01/">「KARTE Datahubに蓄積した様々なデータを活用する｜KARTE Datahub事例集 vol.1</a>」より引用</em></p>
<p>Datahubでは、KARTEに関わらず様々なデータの統合・利活用するプラットフォームであるため、他のKARTEのProductとデータの取り扱いを区別する必要があります。</p>
<h1>プレイドでのデータ共有</h1>
<p>データへのアクセスの安全性を高めるために、Datahub以外のKARTEのプロダクトから、クライアント企業の許諾なく直接Datahubに連携されたデータを参照することはできません。<br>
そのため、クライアント企業から許諾を受けたデータのみを、Datahub以外のプロダクト側に共有することで、イベントデータと組み合わせて使用したり、加工済みデータを生成しています。</p>
<p>また、データ連携の際に使用するBigQueryのDataset（以下、Dataset）やGCPのサービスアカウント（以下、SA）はクライアント企業ごとに分離されており、例えば、企業AのSAではその企業AのDatasetのみが操作でき、それ以外のクライアント企業のDatasetへの権限は一切持ちません。</p>
<h1>従来のDatasetの共有方法の問題点</h1>
<p><img src="https://ik.imagekit.io/plaid/26051d0a-c445-4260-90ff-0c084d3f9bfc/image1.png" alt="image1.png"></p>
<p>従来の仕組みでは、クライアント企業がDatahubを通じてKARTEにインポートしたデータを、Datahub以外のプロダクトから利用する場合には、KARTE Data LayerのSAがDatahub Data Layerに直接アクセスできないため、そのDatasetのデータを含めてKARTE Data Layerにコピーする必要がありました。<br>
この方法では、明示的に必要なDatasetだけをKARTE Data Layerに共有できる反面、以下の二点の問題があります。</p>
<ul>
<li>KARTE Data Layerにコピーされた後のDatasetへのアクセス権限を持つSAの管理・監視が煩雑</li>
<li>Origin DatasetからShared Datasetへ定期的にデータをコピーする必要がある</li>
<li>Origin Dataset・Shared Dataset双方でストレージコストがかかる</li>
</ul>
<h1>Analytics Hubを用いて問題点を改善</h1>
<p>まず前提として、Analytics Hubでは以下の構成によりDatasetを共有することができます。各権限の詳細は<a href="https://cloud.google.com/bigquery/docs/analytics-hub-grant-roles?hl=ja">公式ドキュメント</a>をご覧ください。<br>
<img src="https://ik.imagekit.io/plaid/c0d7cca4-fe2a-4291-90c9-24d0d260a7e4/image3.png" alt="image3.png"><br>
<em><a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction#subscriber_workflow">Introduction to Analytics Hub</a>より引用</em></p>
<ul>
<li>Publisher : 共有元となるDatasetを持つGCP Project</li>
<li>Data Exchange : Publisherが共有対象となるListingを作る場所</li>
<li>Listing : PublisherがData Exchange内に作成した、共有対象となるDatasetのリストで、SubscriberはこのListingへの <code>roles/analyticshub.subscriber</code> 権限を持つ</li>
<li>Subscriber : Analytics Hub経由で共有されたLinked Datasetを使う側を指し、このSubscriberはListingをSubscribeすることでLinked Datasetを自分のGCP Project内に作成する</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ea657c14-c835-4176-8c15-616c4be357dc/image2.png" alt="image2.png"></p>
<p>Analytics Hubを通じてDatasetを共有することで、Datasetのデータ実体はKARTE Data Layerに共有することなく、Origin Datasetの内部にあるデータと同じものをShared Datasetに対してクエリを実行することで取得できます。この時、Origin Datasetに対して権限を持っているGCPのService Accountのみが共有対象のAnalytics HubのListingを作ることができるように権限管理をしているため、Data ExchangeはDatahub Data Layerに置いています。<br>
Analytics HubでDatasetを共有することで、従来のSAで直接共有する形式では見えずらかった、共有先での使用状況や、共有先が明確になりました。<br>
また、データコピーの必要がなく、かつストレージはOrigin Datasetにのみ課金されるため、上記の2点の問題点が両方とも解決できます。</p>
<h1>セキュアなデータガバナンスの取り組み</h1>
<p>KARTE Data Layerに一度共有されたDatasetは、そのクライアント企業がKARTEの他のプロダクトから利用することができます。しかし、一度共有したDatasetであっても、何かの事情がありそのDatasetをKARTEの他のサービスへ共有停止したいというケースもあります。<br>
そのような際には、Analytics HubのPublisher側でそのDatasetのSubscriptionを削除する、Subscriber側で共有されているDatasetを削除するなど、いずれの方法でも瞬時に共有を停止できます。<br>
また、現在共有されているDatasetをListingから取得できるため、共有中のDatasetのListingへ監視を入れておくことで、意図せずDatasetが共有されてしまっているという状態をすぐに検知することも可能です。</p>
<h1>実際にAnalytics Hubを使ってみて</h1>
<p>Analytics Hubでは、一般公開されているDatasetをSubscribeして使うことや、異なる組織間でDatasetをセキュアに共有しつつ、クエリに対する課金も分離するという用途のみならず、同一組織内でもデータガバナンスの観点で、データへのアクセス権限を管理したり、特定のDatasetのみを特定の目的で他のGCPのプロジェクトへ共有して使うという用途でも使いやすい機能だと思いました。<br>
しかし、まだAnalytics Hubも出たばかりの機能ということで、以下の機能に関して改善が行われると、より使いやすい機能になると感じました。</p>
<ul>
<li>Listingを消した時に自動でLinked Datasetも削除されること</li>
<li>共有用URL経由でLinked Datasetを作成できるGCPプロジェクトを限定したい
<ul>
<li>Service Accountの権限で制限をかけることもできるが、Service Accountの権限設定ミスで想定外のGCPプロジェクトのSAが権限を持ってしまった場合に備えて、Listingごとに共有先として許可するGCPプロジェクトを指定したい</li>
</ul>
</li>
<li>Node.js API Clientの拡充</li>
</ul>
<p>上記のように改善点はいくつかあるものの、KARTEのデータガバナンスを強化する機能としては非常に有効な機能なので、今後も使用箇所を増やしていこうと思っています。</p>


2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。 

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有 - PLAID engineer blog

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

OLAPデータベースにおける高速化の技術 - PLAID engineer blog

OLAPデータベースにおける高速化の技術

<p>こんにちは、エンジニアのmkataigiです。</p>
<p>突然ですが、PLAIDエンジニアブログをリニューアルしていました！</p>
<p>このブログは2016年4月から、プレイドのエンジニアが日々の開発業務のなかで得たさまざまな知見を、社内外の皆さんへと共有する場として運営されてきました。おかげさまで公開済みの記事は100件を超え、各記事を通じてたくさんの方々に私たちのパーソナリティについて知ってもらうことができたのではないかと感じています。</p>
<p>今回は、そんなPLAIDエンジニアブログを（なんとフルスクラッチで！）リニューアルしたので、その経緯や感想について簡単にまとめてみたいと思います🚀</p>
<h2>リニューアルの動機</h2>
<h3>ページビューや採用ページへの流入数が思った以上に多いことが判明</h3>
<p>このブログは、「社外の人にプレイドの中のエンジニアのユニークなパーソナリティを知ってもらうこと」を目的として運営されてきました。（参考: <a href="https://tech.plaid.co.jp/start-engineerblog">プレイドのエンジニアブログを始めました！</a>）</p>
<p>そのため（？）当ブログは、基本的にはエンジニアが書きたいことを自由に書くという風土のもと、良くも悪くもなんとなく運営されていたところがあります。</p>
<p>そんな中で、最近あらためて調べてみると、どうやら思った以上に当ブログからの採用ページをみに来てくれる人が多いということが判明しました。また、社内メンバー数名に話を聞いてみたところ「入社前にブログを見てエンジニアチームの雰囲気を知れたことでプレイドに興味を持った」という声もあがってきました。</p>
<p>こうしたことから、エンジニアが書きたいことを自由に書くというスタンスは活かしながら、ブログ本体の読みやすさや体験を改善することで、このブログのポテンシャルをもっと活かせるのでは？という認識を持つようになりました。</p>
<h3>旧ブログは実質メンテナンス不可能で入稿以外では放置状態だった</h3>
<p>旧ブログは、<a href="https://ghost.org/">Ghost</a> というブログサービスを使って作りました。プレイドでは、Ghostをセルフホストする形で運用しており、デザインは<a href="https://themeforest.net/item/cedar-responsive-ghost-theme/13127587">良い感じのサードパーティ製テーマ</a>を購入して適用しました。こうすることで、時間と手間をかけずにクオリティの高いオリジナルのブログを立ち上げることができました。</p>
<p>ただ、時間が経つにつれてデザイン面やパフォーマンス面での課題感も目立ち始めていました。具体的には、「文字や画像のサイズ感がおかしい」「記事の一覧性が悪い」「記事の表示速度が遅い」など、いくつかの課題が出てきたのです。</p>
<p>しかし、これを改善しようにもそれをできる人が社内に誰もいないという問題がありました。社内にGhostテーマの書き方を知っているエンジニアはいませんし、これからそれを学びたいと思うエンジニアもいませんでした。</p>
<p>こうして旧ブログはある種の放置状態へと陥っていきました。</p>
<h3>プレイドの元同僚チームが、ヘッドレスCMS「Newt（ニュート）」を立ち上げた！</h3>
<p>そんな状況のなか、昨年4月にプレイドから独立し新たな会社を創業していた元同僚のチームから、新たな国産ヘッドレスCMS「Newt（ニュート）」がリリースされました。Newtは、従来のヘッドレスCMSをより使いやすく、誰にでも不自由なく扱えるものにしようというコンセプトで開発をしているようです。ヘッドレスCMSという枠を飛び越えていろいろと挑戦していこうと思っているみたいなので、今後にも期待ですね。</p>
<p><a href="https://prtimes.jp/main/html/rd/p/000000002.000095676.html">国産ヘッドレスCMS「Newt（ニュート）」3月8日より無料プランの提供開始</a></p>
<p>彼らが今後何に挑戦しようとしているのかについての記事も公開されていました。WordPressを置き換えるという目標は壮大だなwとも思いましたが、そういうチャレンジ精神はプレイド社で育まれたものなのでしょう笑。頑張ってもらいたいなと思っています。</p>
<p><a href="https://www.newt.so/blog/creating-the-next-wordpress">WordPressの次を担うサービスを作る</a></p>
<p>プレイドとして（私個人として..？）は、こういう元同僚のチャレンジは応援していきたいと思っていたので、エンジニアブログをリニューアルするのであればNewtを使ってやってみようと思っていました。そして、去年末に先行ユーザーを募集していたので、このブログ改善にNewtを活用してみることにしました。</p>
<h2>Jamstack構成でブログを実装する</h2>
<p>そんな経緯でスタートしたエンジニアブログ刷新プロジェクトですが、まずはどんな技術構成で作っていくのかを決めなくてはいけません。今回は、最近フロントエンド界隈でよく耳にするJamstackと呼ばれる構成で作ることにしました。</p>
<h3>Jamstackとは？</h3>
<p>Jamstackとは、 <code>JavaScript/API/Markup</code> の頭文字をとったアーキテクチャパターンです。</p>
<p>ポイントは、フロントエンドとバックエンドを分離してAPIを通じてデータ通信を行うということです。Jamstackはあくまで考え方のようなものなので、これが正解！といった作り方はないようですが、多くは静的サイトレンダリング（SSR）や静的サイト生成（SSG）などの文脈で使われることが多いようです。</p>
<p>詳細は割愛しますが、詳しくは知りたい方は <a href="https://jamstack.org/">jamstack.org</a> を確認してみると良いと思います。</p>
<p>せっかく新しい技術を試すなら、本業として開発しているKARTEでも活用できる技術を使いたいなと思い、このJamstackは今後重要になってくる技術だと思っているため、実際に使ってみて、使い所をキャッチアップしてみることにしました。</p>
<h3>フロントエンドはNext.jsで実装</h3>
<p>次に決めなくてはいけないのは、フロントエンドを何で作るかということです。今回は次のような要件に沿って考え、Next.jsを選択しました。</p>
<ol>
<li>静的サイトレンダリング（SSG）が可能であること</li>
<li>本業のプロダクト開発に活かせること</li>
<li>（個人的にキャッチアップしたい技術であること）</li>
</ol>
<p><a href="https://jamstack.org/generators">https://jamstack.org/generators</a> に大量の静的サイトジェネレータが紹介されているので、これから検討を始める方はこの中からご自身のニーズに合ったジェネレータを探してみてください。</p>
<p><img src="https://ik.imagekit.io/plaid/61ab4b07-262b-473d-a715-5372692f1398/1000x1000/%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%882022-03-1419.18.05.png" alt="スクリーンショット2022-03-1419.18.05.png"></p>
<h3>Newtを使って記事データを管理</h3>
<p>記事管理はNewtを使って行います。</p>
<p>Newtでは、1つのスペースの中にAppというコンテンツ管理のユニットを何個でも追加していくことができます。今回は<code>PLAID, Inc.</code> スペースを作成して、その中に<code>Engineer Blog</code>Appを作ることにしました。</p>
<p>また、リニューアル後のブログはパフォーマンスにもこだわったものにしたく、特に重たい画像の最適化にもこだわりたかったため、専用のGCSバケットを作成しNewtの外部ストレージ機能を使い、ImageKitと連携させて利用することにしました。Newtでは外部ストレージ機能を使うことで、<a href="https://imagekit.io/">ImageKit</a>や<a href="https://imgix.com/">imgix</a>のような画像最適化のツールを入れられます。今回はより管理画面が軽快だったImageKitを選択しました。</p>
<p><img src="https://ik.imagekit.io/plaid/f8de7fec-546c-407f-a72b-353d02faeddf/1000x1000/%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%882022-03-1419.15.46.png" alt="スクリーンショット2022-03-1419.15.46.png"></p>
<h3>Netlifyを使ってホスティング</h3>
<p>フロントエンドをNext.jsで作ることにしたため、当初はNext.jsの開発元であるVercelを利用することにしていたのですが、ブログ公開の直前に後述する問題が発生したため、Netlifyでのホスティングに切り替えました。現状では、特に大きな問題はなくホスティングすることができています。</p>
<p>NetlifyでもVercelでも、静的サイトのホスティングサービスにそのまま連携することで、めちゃくちゃ簡単にWebサイトをホスティングすることができたので感動しました。</p>
<p><img src="https://ik.imagekit.io/plaid/67d2b891-5bf8-4b64-aa8e-c76a55963f3a/1000x1000/%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%882022-03-1422.00.41.jpg" alt="スクリーンショット2022-03-1422.00.41.jpg"></p>
<h2>大変だったこと・課題</h2>
<h3>記事データの移行作業が大変だった..</h3>
<p>一番大変だったのは、Ghostからの記事の移行作業です。Ghostからエクスポートした記事データを、1件ずつ手作業でNewtに移していく必要がありました。</p>
<p>Newt社のメンバーに聞いたところ、コンテンツのPOST APIやCSVインポート機能は提供予定とのことだったので、今後はこのような辛い作業を行わなくても良くなっていくのだろうと思います。今回に限ってはデータ移行が一番大変でした。。</p>
<h3>Superの影響で、Vercelを使うことができなかった</h3>
<p>これはあまり一般的な問題ではありませんが、Notionのホスティングサービスである<a href="https://super.so/">Super</a>を社内の別プロジェクトで利用していたことで、Vercelでホスティングできなくなるという問題が発生しました。</p>
<p>SuperはNotionから静的なWebページをホスティングすることのサービスです。プレイドではSuperを使って <code>recruit.plaid.co.jp</code> というドメインのWebサイトを立ち上げていました。そして、これが原因でVercel上で <code>tech.plaid.co.jp</code> というドメインのWebサイトをホスティングすることができなくなってしまいました。</p>
<p>これは、下記のような原因によるものだと思われます。</p>
<ol>
<li>SuperがVercelを使ってホスティングを行なっていること</li>
<li>Vercelでは、同じドメイン配下の違うサブドメインを、別々のプロジェクトで使用することができないということ</li>
</ol>
<p>つまり、SuperのインフラとVercelのドメイン扱いに関する仕様が、コンフリクトを起こしてしまったような状況にあるのだと思います。</p>
<p>今回のケースでは、単にVercelからNetlifyへと置き換えることで回避することができました。これもいずれVercelで改善されるかと思いますが、Vercelを前提に実装等を行う場合は注意が必要だと思います。</p>
<h3>ビルド時間への慣れが少し必要</h3>
<p>Ghostをはじめとする一般的なブログサービスを利用する場合、記事を保存すればWebサイト側に即反映されるのが当たり前でした。ですが、今回のようにCMSをバックエンドにSSGで構築する場合は、記事を保存してからCMSのデータを元に静的ファイルへのビルドが実行され、ビルド結果が新たにホスティングされるため、Webサイトとしてみえるようになるまでにタイムラグが生じてしまいます。</p>
<p>このタイムラグへの慣れというのは少し必要になるかなという感覚を得ました。個人的には、保存ボタンを押すタイミングをちょっと考えてしまいました。</p>
<p>ただ、そうしたビルドによる事前レンダリングによってWebサイトのパフォーマンスがかなり改善されるので、よほどのことがない限りはタイムラグの方に自分を慣らしてしまうのが賢明なのではないかなと思います。</p>
<h2>良かったこと</h2>
<h3>Appテンプレートとスターターで開発工程をスキップできた</h3>
<p>Newtでは、モデル設定とサンプルコンテンツのプリセット（Appテンプレート）をインストールしてコンテンツ管理をスタートすることができます。AppテンプレートにはそれぞれNext.jsとNuxt.jsのスターターキットが用意されているため、今回はこれをベースに実装とデザイン（デザイナーさんにも協力してもらいました）を行うことにしました。</p>
<p>モデル設計やヘッドレスCMSとの繋ぎ込み、ブログの基本機能の実装といった作業は、思いのほか手間のかかる作業だと思うので、そうした作業をスキップすることができたのは良い体験でした。</p>
<p><a href="https://www.newt.so/docs/app-template">Appテンプレートについて</a>はこちらのドキュメントをご参考ください。</p>
<p><img src="https://ik.imagekit.io/plaid/67bd8d81-449f-4822-a40b-5dee031f0522/1000x1000/Group2.png" alt="Group2.png"></p>
<h3>パフォーマンスが大幅に改善</h3>
<p>一番良かったと思えたのは、体感値としても計測値としても、ブログのパフォーマンスが大きく改善されたことです。今この記事を書きながらLighthouseを使って測定してみたところ、全ての項目で90点を超える結果になっていました。</p>
<p>社員からも「爆速！」「dev.toかと思った」などと表示速度に関するポジティブな感想が多く出てきました。</p>
<p><img src="https://ik.imagekit.io/plaid/d4fbb069-edc5-4be4-bc01-dbd43aa013bf/1000x1000/%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%88_2022-03-11_15.17.10.png" alt="スクリーンショット_2022-03-11_15.17.10.png"></p>
<h3>エンジニアやデザイナーがコードを書いてメンテナンス可能に</h3>
<p>ヘッドレスCMSを使って、フロントエンドを自前で実装したことによって、不具合などがあった場合に社内のエンジニアがPull Requestを作成して修正できるようになりました。</p>
<p>以前のブログだと、何かを修正したくても修正の仕方が分からないという状態でしたが、リニューアル後は普段から仕事で利用しているReact.jsのコードを書くことによって簡単に修正を行うことができます。Pull Requestをマージすれば、即座にデプロイが実行され、普段の開発と同じフローでブログの修正をできるのもかなり楽です。</p>
<p>このように自分達のブログを自分達でメンテナンスできるようになったことで、今後何かしらの改善点が出てきた時にそれを放置してしまわずに済みます。</p>
<p><img src="https://ik.imagekit.io/plaid/3ff6a693-75f5-4403-908a-36a9dbbece84/1000x1000/%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%88_2022-03-11_17.09.35.png" alt="スクリーンショット_2022-03-11_17.09.35.png"></p>
<h3>飛び火的に社内の別プロジェクトで採用され始めた</h3>
<p>Newtでは、1つのスペースにAppというコンテンツ管理ユニットを何個も作っていくことで、組織内のあらゆるコンテンツや情報を集約していくことができると謳っています。そして、プレイド社において実際にそういう現象が起きています。</p>
<p>最初はエンジニアブログだけのために作成したNewtスペースですが、少し時間が経つと風の噂を聞いた他チームの社員が何人も参加してきて新たなAppが次々と作られています。</p>
<p>スペースへの参加者は3月11日現在で20名近くになっていて、次々に横展開が進んでいるような状況になっています。個人的にも、今まであまり知ることができなかった他のチームの動きを知ることができて面白いなーと思って眺めています。</p>
<p><img src="https://ik.imagekit.io/plaid/a837ec80-b95a-46c2-ae56-7ac2b24a7e20/1000x1000/mosaic_20220311154807.png" alt="mosaic_20220311154807.png"></p>
<h3>最近のフロントエンド技術のキャッチアップができた</h3>
<p>個人的には、最近のモダンなフロントエンド開発についてキャッチアップできたことが良かったなと思っています。</p>
<p>どうしてもメインの仕事としてとなると、自分のパフォーマンスが出やすい領域に集中してしまいがちですが、こういった機会を利用して今後重要になるけどまだ詳しくない領域にも手を出していくと良いのではないかなと感じました。</p>
<h2>終わりに</h2>
<p>今回は、PLAIDエンジニアブログのリニューアルプロジェクトについてご紹介しました。</p>
<p>PLAIDエンジニアブログでは、今後もより一層、社内外のエンジニアに面白いと思ってもらえるような記事を公開していきたいと思っています！</p>
<p>プレイドでは（普段はバリバリと開発しながらも）新しくなったエンジニアブログに面白い記事を公開してくれるエンジニア（インターンも！）を募集しています。詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


PLAIDエンジニアブログをJamstackでリニューアルしました🚀

「KARTE Blocksリリースの裏側」はKARTE Blocksが2021年9月14日に正式リリースされたことを記念して開始した連載シリーズです。 2021年11月8日に公開した「KARTE Blocksを支える技術」から11月19日に公開した「KARTE Blocksにおけるポジショニングの考え方とその狙い」まで10本の記事を公開しました。  このように複数人での連載記事を書く場合にどのように進めるべきか、「KARTE Blocksリリースの裏側」という連載ではどのように進めていったのかについて紹介します。

「KARTE Blocksリリースの裏側」の裏側 - 複数人で連載記事を書く方法

リリース後に落ちないように、新規サービスで備えておいたこと

CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方

爆速で価値あるプロダクトをリリースするためのチームビルディング

AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術

セカンドパーティコンテンツをもつサードパーティスクリプトの作り方

インクリメンタルに新しい技術を取り入れる方法。TypeScriptへの移行を例にしたプロセス

2021年9月14日に正式リリースしたKARTE Blocksの裏側を紹介する連載の第一弾です。
KARTE Blocksを支える技術とその技術を選んだ理由について紹介します。

KARTE Blocksを支える技術

プレイドの dev インターンに参加した記録をまとめました！

PLAIDのインターンでやったこと ~ KARTE接客の施策の基盤改善の試み | PLAID engineer blog

PLAIDのインターンでやったこと ~ KARTE接客の施策の基盤改善の試み