Engineer Blog

Anri Nakamura

Kakemu Fujii

Kento Kaseda

Reo Hakuta

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

3ヶ月の開発インターンで取り組んだタスクや、そこから得た学びについて紹介します。

プレイドインターン体験記：管理画面から配信基盤までを横断した機能開発

<p>こんにちは、 プレイドでソフトウェア開発者をしているtakurintonです。</p>
<p>プレイドは、2025年10月25日(土)に開催された<a href="https://vuefes.jp/2025/">Vue Fes Japan 2025</a>にゴールドスポンサー、学生支援スポンサーとして協賛しました。</p>
<p>当日はブースの出展に加え、プレイドのユニークな技術とインターンの紹介をさせていただきました。</p>
<h2>ブースの紹介</h2>
<p>プレイドは大規模データを扱う会社である一方で、配信を誰でも簡単に行うことができるUIにも力を入れています。</p>
<p>ブースではフロントエンドの以下のトピックに関するアンケートを実施しました。</p>
<ul>
<li>型、どうしてる？</li>
<li>CSSは何派？</li>
<li>1番重要視するのは？</li>
<li>UI状態管理は？</li>
<li>ビルド&amp;Dev環境を教えて！</li>
<li>推しパッケージマネージャーは？</li>
</ul>
<p>プロダクトの歴史的背景や、場合によっては意思決定者の好みが出る話題で、さまざまなバックグラウンドの方の話や事情を聞くことができ、大変学びになりました。</p>
<p>また、併せて今回のVue Fes Japan 2025に向けて作成した冊子や、プレイドのリアルタイム解析基盤や内製OLAP DBについて技術評論社様と作成した冊子などを配布しました。</p>
<p><img src="https://ik.imagekit.io/plaid/e93f049b-91b9-4a6b-9360-97552fc1f36c/IMG_2541.jpg" alt="Vue Fes Japan 2025の株式会社プレイドのブースの様子。パンフレットやモニター、アンケートボードが並べられている。"></p>
<h2>セッションの感想</h2>
<p>同じ学生支援スポンサーで登壇されていたお二方のセッションの感想を書いていきたいと思います。</p>
<p>お二方とも大変ユニークで面白く、それぞれの抱えている課題について端的に発表されていることが印象的でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/lycorp"><strong>LINE公式アカウントの技術スタックと開発の裏側</strong></a></h3>
<p>LINEヤフー株式会社の佐野友亮さんの発表です。</p>
<p>LINE公式アカウントのプラットフォームを題材に、デザインシステムの取り組みについてお話しされていました。<br>
デザインシステムの中核部分はWeb Componentsで実装されており、それをReactやVue.jsなど複数のライブラリへ適用できる仕組みになっているとのことでした。具体的には、CEMというツールを用いて中間表現を生成し、ReactやVue.js向けのコンポーネントはその生成物を配布する形を取ることで、メンテナンス対象をWeb Components部分に集約している構成が紹介されていました。</p>
<p>Web Componentsを本番環境で活用している事例は個人的に初めてで、以前から関心を持っていたテーマだったこともあり、とても学びの多い内容でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/studio"><strong>Vue.jsを8年間使ってきた会社が今考えていること</strong></a></h3>
<p>Studio株式会社の齊藤広野さんの発表です。</p>
<p>Vue.jsを1系の頃から8年間にわたって活用されており、その間にコード量は7年間で13倍に増加していたそうです。発表では、大規模アプリケーションにおけるStore設計の重要性を、単一責任の原則や依存性逆転の原則を題材に、具体的なサンプルコードを交えて丁寧に解説されていました。</p>
<p>また、プロジェクトのデータ構造がボトルネックとなり、パフォーマンスが大きく低下していたアプリケーションをマイグレーションする難しさや、その過程で発生した不具合から得た知見をもとに改善へとつなげていく姿勢が印象的でした。実践的かつ学びの多い内容だったと思います。</p>
<h2>スポンサーセッション</h2>
<p><a href="https://vuefes.jp/2025/sponsors/plaid">プレイドのユニークな技術とインターンのリアル</a></p>
<p>弊社のスポンサーセッションでは、プレイドが提供するKARTEの紹介をはじめ、開発文化やユニークな技術についての紹介を行いました。また、途中では<a href="https://blocks.karte.io/">KARTE Blocks</a>のデモを挟みながら、実際の画面や配信についても触れました。</p>
<p>フロントエンドという領域から離れてしまいましたが、リアルタイム解析基盤や内製しているOLAP DBについての紹介も行いました。</p>
<p>セッション後にブースに立ち寄ってくださった方々からは技術面の面白さを感想としてお伝えいただいたり、時には議論に発展したりと、大変学びになる時間になりました。</p>
<p>よろしければ登壇資料もご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="プレイドのユニークな技術とインターンのリアル" src="https://speakerdeck.com/player/0ee327d57ec64e71b058a9a777c71d51" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>おわりに</h2>
<p>Vue Fes Japan 2025では主にフロントエンドの分野に深い知見をお持ちの方が多く参加されており、自分自身その領域への知見や経験が足りないと感じていたのでさまざまなお話を聞くことができ大変有意義な時間になりました。</p>
<p>最後になりますが、素晴らしいカンファレンスを主催・運営してくださった皆様、本当にありがとうございました！また、ブースの出展に携わった皆様、登壇者・参加者の皆様も本当にお疲れ様でした！</p>
<p>来年のVue Fes Japanも楽しみです。</p>


プレイドはVue Fes Japan 2025にゴールドスポンサー、学生支援スポンサーとして参加しました。セッションの感想やブースの運営についてレポートとして紹介します。

Vue Fes Japan 2025レポート | 現地で感じた技術の熱とつながり

<p>こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。</p>
<p>振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。</p>
<p>この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。</p>
<h2>導入</h2>
<h3>インターン参加の経緯</h3>
<p>最初のきっかけは、プレイドで働く友人から、仕事がとても充実していると聞いたことでした。<br>
面談や面接でお話を伺う中で、カルチャーなどに加えて、技術的に難易度の高い大規模データを扱う挑戦に魅力を感じました。<br>
「自分もこの環境に飛び込み、挑戦したい」と強く感じ、このインターンシップに参加しました。</p>
<h3>Journeyとは？</h3>
<p>プレイドが提供するプロダクト「KARTE」において、ユーザーの辿る行動に応じて、異なる施策を実行することができる機能です。例えば、ECサイトで「カートに商品を入れたまま迷っているユーザーに、2時間後にクーポンの通知を送る」といった、ユーザーの状況に応じたシナリオを自動で実行してくれます。</p>
<p>参考：<a href="https://karte.io/product/journey/">KARTE Journey</a></p>
<p>現在、Journeyチームでは配信基盤周りの改善を行なっています。その中核としてユーザーのイベントが発火した瞬間に処理を行う「イベント処理基盤」と、指定時間の経過や条件の評価などをバッチ処理で行う「定期実行基盤」を開発しています。<br>
今回は「定期実行基盤」にまつわるタスクを行いました。</p>
<h2>業務内容紹介</h2>
<h3>時間経過の判定の処理のリアーキテクチャ</h3>
<p>Journeyにおいてシナリオは、ユーザーの行動や通知の配信などといった1つ1つのステップに分けられます。その中には、「指定時間までユーザーを待つ」といったものもあります。そこでは、「2時間後」「毎週金曜の18:00」「月末の12:00」など、様々な条件でユーザーが留まる時間を指定することができます。</p>
<p><img src="https://ik.imagekit.io/plaid/7bd172a8-fccb-4f88-b8c7-932f98ea5b8c/blog_image_1.png" alt="blog_image_1.png"></p>
<p>定期実行基盤の主要な部分として、各ステップの遷移対象となるユーザーを抽出するコンポーネントと、遷移対象のユーザーを実際にデータベースに書き込んで次のステップへ移すコンポーネントがあります。</p>
<p>従来の実装では、データ更新を担うコンポーネント（下図右側）が、ユーザーを待つ処理がある時には「ユーザーの待ち時間の終了時刻を計算する」という処理も行なっていました。本来書き込みに専念すべき場所に、時刻計算のビジネスロジックが混在して責務が曖昧になり、全体の見通しの悪さが課題となっていました。</p>
<p><img src="https://ik.imagekit.io/plaid/d14465ef-2fd8-43d2-9d4b-02e3d39884e8/blog_image_2.png" alt="blog_image_2.png"></p>
<p>そこで、遷移を実行するコンポーネントで書き込み処理に専念できるよう、遷移対象を抽出する段階で動的にSQLを生成するように実装を変更しました。*1<br>
具体的には、TypeScript側で「現時点でいつの時刻まで流入してきた人が遷移対象となるべきか」を計算し、それを用いてクエリを書くといった実装でした。</p>
<p>*1: BigQueryのUDF(User defined function)も検討しましたが、行数を少なく実装できる一方で可読性やメンテナンス性が低かったため見送りました。</p>
<p><img src="https://ik.imagekit.io/plaid/72d50f67-2cbf-4a7a-9682-c6fb7d3d5a83/blog_image_3.png" alt="blog_image_3.png"></p>
<p>大変だったことは、網羅すべきパターンが多く、単純な計算なのにも関わらずコード量が膨大になったことです。初めはパターンごとにクエリを実装していましたが、SQLの構造が2つのパターンに集約できるのを見抜いて、計算部分を切り出しました。まだまだSQLの動的生成の可読性は課題ではあるものの、コードの見通しはある程度良い状態で実装ができました。</p>
<p>実装の細部にまで目を配ってレビューしていただき、非常に勉強になりました。例えば、待ち時間のパターンに対して Discriminated Union の導入を提案いただいたことで、より型安全に整理できました。このように、今まで知らなかった技術を活かして実践的なコード改善に繋げるという貴重な体験は、自身の成長に大きくつながりました。</p>
<h3>定期実行基盤の負荷検証</h3>
<p>次に、クラウドインフラのリソースを増やすことによって定期実行基盤が本番トラフィックを処理可能か、そのスケーラビリティを検証するための負荷テストを行いました。</p>
<p>目標実行時間を2分半以内と設定し、大量の検証用データを投入してテストを開始したのですが、現実は甘くありませんでした。実行時間は常に目標を大幅に上回り、ボトルネック探しの調査が始まったのです。</p>
<p>以下の流れで負荷検証を行いました。</p>
<ol>
<li>データ大量投入スクリプトの準備</li>
<li>検証</li>
<li>デプロイ設定の変更(複数回)</li>
<li>Datadogメトリクスの導入</li>
</ol>
<p><strong>仮説1：ユーザー抽出時のリソース不足</strong></p>
<p>まず疑ったのは、コンピューティングリソースの不足です。</p>
<p>実際に、テストの初期段階ではcpu使用率が頭打ちしていて、メモリにも余裕がない状況でした。GKEのpod数を10程度まで増やしてリソースを潤沢に確保しました。しかし、CPU使用率は安定したものの、実行時間は依然として5分を超過したままでした。</p>
<p><img src="https://ik.imagekit.io/plaid/fd0a8e70-2268-408f-b9f2-a133f8398704/blog_image_4.png" alt="blog_image_4.png"></p>
<p><strong>仮説2：データベース処理の遅延</strong></p>
<p>次に目を向けたのは、データベース、特にBigQuery(BQ)の処理です。Temporalのワークフローの実行記録(上の画像)から、BQでの一時テーブル作成やSpannerへのエクスポートの処理に時間がかかっている可能性が浮かび上がりました。</p>
<p>これを検証するため、Datadogで各BQクエリの実行時間を計測可能にしました。その結果、クエリの実行時間は最長で10秒程度であることがわかりました。5分以上の実行時間を説明するには不十分でした。</p>
<p><img src="https://ik.imagekit.io/plaid/39f98e76-7cac-4acf-bb7a-1911ff967d40/blog_image_5.png" alt="blog_image_5.png"></p>
<p><strong>真相：直列実行の罠</strong></p>
<p>八方塞がりかと思われた中で、GKEのログを見てみたところ、驚くべき事実が判明しました。<br>
調査の結果、検証環境では本来並列で実行されるべき多数のタスクが、なぜか直列に一つずつ処理されていたのです。すなわち、BQやSpannerのIO待ちが積み重なっていたということです。<br>
今回のボトルネックの正体は、「デプロイされた環境における並列処理の不具合」だったのです。<br>
最終的に問題を完全に修正するところまで至りませんでしたが、この調査プロセスは非常に大きな学びとなりました。<br>
「仮説を立て、データを用いてそれを検証し、次の打ち手を考える」というサイクルを高速で回すことの重要性を肌で感じました。巨大なシステムにおける問題解決のリアルな一端に触れられた、非常に価値のある経験でした。</p>
<h2>インターン生活について</h2>
<h3>プレイドでの働く環境</h3>
<p>全体的にオープンな雰囲気で、誰にでも気軽に質問や相談ができました。特に印象的だったのは、タスクに関する何気ない相談が、次第にプロダクトの設計といった、より深い議論に発展していく光景でした。1人の思考がチームとしての思考に拡張されてゆくような、新鮮な体験でした。<br>
また、ランチの時間には他のチームの方とも交流することができ、毎日楽しく過ごすことができました。インターン生同士や新卒の方などとの繋がりもできてよかったです。</p>
<h3>インターンを通しての学び</h3>
<p>この1ヶ月で、エンジニアとして多方面にわたり大きく成長できたと感じています。<br>
実装における細かい技術的な側面から、プロダクトの提供する価値といったビジネス的な側面まで、幅広い視点でインプットできました。<br>
その中でも特に、データを大量に投入してパフォーマンスを観察するといったことは、自分一人ではできない新たな経験でした。大規模なデータを処理するアプリケーションのインフラの一端を覗くことができ、非常に勉強になりました。</p>
<h2>最後に</h2>
<p>この1ヶ月は、手厚いサポートを受けながらも手応えのあるタスクに没頭することができ、非常に充実した時間でした。改めて、Journeyチームの皆様には心から感謝しています。<br>
このインターンは、刺さる人には深く刺さるものだと感じています。「手応えのあることに挑戦したい」「新しい技術に触れてみたい」といった方には最高の環境です。<br>
そのワクワクするような経験を、ぜひ次はご自身で体験してみてください。</p>


こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。  振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。  この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。

プレイドインターン体験記：大規模システムのリアーキテクチャと負荷検証

<p>KARTE for Appチームのエンジニアの悴田です。</p>
<p>プレイドは、2025年9月19日〜21日に開催された <a href="https://iosdc.jp/2025/">iOSDC Japan 2025</a> にゴールドスポンサーとして協賛し、ブース出展も行いました。<br>
本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。</p>
<h2>ブースのご紹介</h2>
<p>プレイドでは、モバイルアプリ向けのSDKを開発・提供しています。</p>
<p>現在は、モバイルアプリのエンゲージメント向上を目的とする「<a href="https://karte.io/package/app/">KARTE for App</a>」と、Native UIの開発生産性向上を目的とした新規プロダクト (本記事公開時点ではクローズドベータ)、の2つを提供しています。<br>
今回のブース企画・運営は、これら2チームの開発メンバーを中心に行いました。</p>
<p>ブースでは、「<strong>アプリグロースの課題に関するパネルアンケート</strong>」と「<strong>マーケティングSDKの利用状況に関するWebアンケート</strong>」の2つを実施しました。</p>
<p><img src="https://ik.imagekit.io/plaid/b4be8f0a-852a-4130-8084-919d5678507c/IMG_0075.jpg" alt="IMG_0075.jpg"></p>
<p>アンケートにご協力いただいた方々には、弊社のノベルティグッズをプレゼントしました。<br>
ノベルティグッズとして「ラムネ」「歯磨きセット」「携帯式のコップ」「米 (2合)」を用意し、特に「米」は物珍しさもあって好評でした。</p>
<p>また、Webアンケートは弊社の「KARTE」を用いて作成し、アンケートの回答後にはくじを引けるようにしました。<br>
見事当たりを引いた方には、弊社のエンジニアが厳選した技術書の中から、お好きな一冊をプレゼントさせていただきました。</p>
<p><img src="https://ik.imagekit.io/plaid/740576ff-fc73-4bc2-ab3b-544df4b54c73/%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-09-2915.02.17.png" alt="スクリーンショット2025-09-2915.02.17.png"><br>
当選者の方々 (ブログ掲載許諾取得済み)</p>
<h2>印象に残ったセッション</h2>
<p>テストやビルドといったMobile SDK開発にも関係するセッションや、個人的に興味のある低レイヤー寄りのセッションを聴講しました。</p>
<h3>1. 半自動E2Eで手っ取り早くリグレッションテストを効率化しよう</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="半自動E2Eで手っ取り早くリグレッションテストを効率化しよう" src="https://speakerdeck.com/player/b2991526951744758463d4663866c514" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>タイミー社での、E2Eテストの効率化に向けた現実的なアプローチが紹介されました。</p>
<p>当初、同社ではCI/CDとSaaSを活用した全自動のE2Eテストを目指していましたが、SaaSを使いこなす難しさや、SMS認証・QRコード読み取りといった実機特有のテスト項目が障壁となり、1年以上かけても安定運用には至らなかったそうです。</p>
<p>そこで、全自動化を諦め、以下のような「<strong>簡単にできる部分だけ自動化する</strong>」という半自動の方針に切り替えました。</p>
<ul>
<li>ローカルPCでアプリをビルドし、実機にインストールしてテストを実行する。</li>
<li>テスト自動化ツールとして、Railsで使い慣れている「Ruby」で記述できるAppiumを使用する。</li>
<li>自動化できない処理は、手動で操作する。スクリプト内にsleepメソッドを入れ、一時停止中に手動で操作する。手動操作のタイミングは、音を鳴らす仕組みで伝える。</li>
<li>うまく検出できないUI要素は、OCRを利用した画面タップで対応する。</li>
</ul>
<p>このアプローチにより、<strong>わずか1ヶ月で運用を軌道に乗せることに成功</strong>したそうです。</p>
<hr>
<p>私たちのチームにおいても、Mobile SDKのテスト自動化は重要な課題の一つです。<br>
本セッションで語られている、完璧を求めず、最小の労力で最大の成果を得ることを目指すアプローチを取り入れたいと思いました。</p>
<hr>
<h3>2. Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム" src="https://speakerdeck.com/player/89fc533243314e52a7bca2e17d6a4c23" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>XcodeならびにSwift Package Manager (SPM) において、Swiftコードがビルドされる流れと、その際に利用される各種ツール (`xcodebuild`, `swiftc`, `llbuild`など) の役割が紹介されています。</p>
<p>Xcodeでのビルドの場合、まずはXcodeが*.xcodeprojから「<strong>llbuildマニフェスト</strong>」を作成します。llbuildマニフェストとは、<strong>ビルドに必要なタスク一覧とそれらの依存関係を記述したファイル</strong>です。<br>
続いて、llbuildマニフェストは「llbuild」に渡され、実際のビルド処理をコンパイラ (swiftc/clang) やリンカ (ld) を用いて実行します。</p>
<p>一方、SPMでのビルドの場合には、SPMがPackage.swiftからllbuildマニフェストを生成し、llbuildに渡します。<br>
このような、<strong>llbuildマニフェストを生成するツールの違いが、XcodeとSPMの機能差の一因</strong>となっています。</p>
<p>その前提知識を踏まえた上で、最近新たに登場した「Swift Build」の立ち位置と可能性について解説されています。<br>
<strong>Swift Buildは、XcodeおよびSPMの両方において「llbuildマニフェストの生成」を行えるツール</strong>です。これにより、機能差の軽減や新たな機能追加が見込まれています。</p>
<hr>
<p>Swiftのビルドシステムの仕組みを、馴染みのない人でも難なく理解できるよう、丁寧に解説されています。<br>
このテーマがここまで分かりやすく解説されるのは希少だと思いますので、ぜひアーカイブが公開されたら視聴をお勧めしたいです。</p>
<hr>
<h3>3. Embedded Swiftで解き明かすコンピューターの仕組み</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.2903%;"><iframe title="Embedded Swiftで解き明かすコンピューターの仕組み | ドクセル" src="https://www.docswell.com/slide/5QX77N/embed" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen></iframe></div>
<p>このセッションは、<strong>Embedded Swift</strong>と<strong>MMIO (メモリマップドI/O)</strong> を使い、OSのないベアメタル環境でコンピューターをゼロから動かす仕組みを紹介しています。</p>
<p>コンピューターの中心には<strong>CPU</strong>があり、機械語で書かれた命令を実行して動作します。<br>
このCPUが実行できる命令セット (ISA) は、画面表示やネットワーク通信といった複雑な機能を直接含んでいる訳ではありません。</p>
<p>画面表示やネットワーク通信といった、周辺機器 (GPUやストレージなど) の制御に使われるのが、<strong>MMIO (メモリマップドI/O)</strong> です。<br>
MMIOは、GPUなどの周辺機器をメモリ上の一領域とみなし、特定アドレスへデータの読み書きを介して、周辺機器をコントロールする技術です。</p>
<p><strong>Embedded Swift</strong>を使用することで、特定のメモリアドレスを直接操作できる、すなわちMMIOが可能となります。Embedded SwiftによるMMIOの実演として、Raspberry Piの画面を操作して、Swiftのロゴを画面に表示するデモが行われました。</p>
<hr>
<p>コンピュータの動作原理の核心に迫る内容で、個人的に非常に面白かったセッションです。<br>
説明が丁寧、かつ実演もあり、低レイヤに詳しくない人でも知的好奇心を満たされる内容かと思います。</p>
<hr>
<h3>4. アセンブリで学ぶCPUアーキテクチャ</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Learn CPU architecture with Assembly" src="https://speakerdeck.com/player/6220b9f1e63846039dad83abc0dfcba8" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>Intel Macのサポート終了が発表され、Apple Siliconへの完全移行という転換点を迎えた今、<strong>アセンブリ言語を通じて、CPUアーキテクチャの仕組みを学ぼう</strong>というセッションです。</p>
<p>まず、これまでのMacにおけるCPUの歴史を振り返っています。<br>
Macはこれまで、<strong>Motorola 68k (CISC)</strong> → <strong>PowerPC (RISC)</strong> → <strong>Intel x86 (CISC)</strong> → <strong>Apple Silicon (RISC)</strong> のように、命令セット (ISA) が複雑な<strong>CISCアーキテクチャ</strong>と、命令が単純な<strong>RISCアーキテクチャ</strong>の間を行き来してきました。このアーキテクチャ移行を裏で支えてきたのが、Rosettaのようなエミュレーション技術です。</p>
<p>続いて、アセンブリ言語の基礎が解説されています。アセンブリとは、機械語と1対1で対応する低レベルなプログラミング言語です。<br>
このセッションでは、<strong>「Hello, World!」の出力をアセンブリで行うことで、CPUの動作原理を解説</strong>しています。同じ処理でも、 CISC と RISC でアセンブリの記述が変わることも示されました。</p>
<p>最後に、実務的な応用例として、アプリがクラッシュした際のスタックトレースを読む際に、アセンブリの知識がどのように役立つかが紹介されました。</p>
<hr>
<p>3.のセッション (Embedded Swiftで解き明かすコンピューターの仕組み) と同様、コンピュータの動作原理を解説した内容ですが、異なるレイヤーにフォーカスした解説となっています。<br>
両方のセッションを聴講したことで、コンピュータの動作原理をより立体的に理解できました。</p>
<p>アプリ開発をしていると、時たま「あるライブラリがApple Siliconでは動かない」など、CPUアーキテクチャを意識せざるを得ない場面に遭遇するかと思います。そういった場面に備えて、低レイヤーの理解を深める上で良いセッションかと思います。</p>
<hr>
<h2>おわりに</h2>
<p>iOSDC Japan 2025の3日間、弊社ブースへ多くの方々にお立ち寄りいただきました。<br>
アプリのグロースに関する課題感から、KARTEのご紹介まで、皆さんと直接お話しできたことは、私たち開発チームにとって大変有意義でした。</p>
<p>本記事でご紹介したセッションは、私の個人的な興味から低レイヤー寄りの内容が多くなりました。<br>
私と同じくコンピュータサイエンスの探求が好きなモバイルエンジニアの方がいらっしゃいましたら、ぜひカジュアル面談でお話ししましょう！</p>
<p>プレイドでは、以下のポジションで<strong>モバイルエンジニアを積極的に採用</strong>しています。<br>
ご興味のある方は、ぜひリンク先の募集要項をご覧ください。</p>
<ul>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/102069">Mobile App SDK Engineer</a></li>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/106290">アプリエンジニア（新規プロダクト開発）</a></li>
</ul>
<p>最後に、この素晴らしいカンファレンスを企画・運営してくださったスタッフの皆様、そして私たちのブースに足を運んでくださった全ての参加者の皆様に、心より感謝申し上げます。</p>


プレイドは、2025年9月19日〜21日に開催された iOSDC Japan 2025 にゴールドスポンサーとして協賛し、ブース出展も行いました。 本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。

iOSDC Japan 2025参加レポート｜ブース出展の裏側と印象に残ったセッション4選

巨大モノレポ環境でのDeveloper Experience改善に挑戦したプレイドのサマーインターン体験記。CI効率化や社内ESLintプラグイン開発、pnpm catalog移行など技術的成果と、柔軟な労働・開発環境のリアルな様子を詳しく紹介します。

プレイドインターン体験記：巨大モノレポとDeveloper Experienceの改善

<h2>自己紹介</h2>
<p>初めまして、プレイドでエンジニアインターンをしている小林雅史と申します。プレイド内ではあだ名である<a href="https://x.com/mercy34mercy">mercy</a>(マーシー)で呼ばれています。</p>
<p>立命館大学の修士2年生で、大学は情報理工学部、大学院は情報理工学研究科とコンピュータやプログラミングについて学び、研究しています。詳細な自己紹介については、過去に書いた<a href="https://tech.plaid.co.jp/deprecated-fcm-send-all-api">ブログ</a>を覗いてみてください。</p>
<p>プレイドでは2023年の4月からインターンとして勤務していて、最初は<a href="https://tech.plaid.co.jp/platform-engineering-kaigi-2024-report">認証基盤の開発</a>を行いました。その後Redisの監視を簡単にDatadogで行うための社内向けツールを開発し、2023年10月ごろから<a href="https://karte.io/package/message/">KARTE Message</a>というプロダクトの開発を行うチームに加わり開発を行ってきました。これまでは、インフラやバックエンドを中心に開発してきましたが、2024年10月からは<a href="https://karte.io/package/app/">KARTE for App</a>というプロダクトで初めてモバイルSDKエンジニアとして、働くこととなりました。</p>
<h2>KARTE for Appについて</h2>
<p>KARTEは企業などが蓄積したユーザーの行動データなどの1st Party Customer Dataを基に、リアルタイム解析やそれに応じたユーザー毎のパーソナライズ配信が可能なプロダクトです。KARTE for Appは、モバイルアプリ向けの機能をSDKを通じて提供しています。KARTE for Appについては、自分のMobile SDK Engineerとしてのメンターをしてくださった長さんの<a href="https://blog.plaid.co.jp/n/nfa1372970b2e">インタビュー記事</a>も見ていただくと、より理解できると思います。</p>
<p><a href="https://karte.io/package/app/">KARTE for App | モバイルアプリのエンゲージメントを次のレベルへ</a></p>
<h2>取り組んだ内容</h2>
<p>今回私が担当したのは、KARTE for Appが提供するSDKの中でも、設定値配信の新機能の社内検証前の初期実装になります。</p>
<h3>設定値配信の新機能の概要</h3>
<p>KARTEの管理画面から設定するだけで、モバイルアプリ内に画像を用いたカルーセルを表示できる機能を、KARTEにすでに存在する設定値配信の実装をベースに新しく作成しています。カルーセルの画像、サイズ、画像間のスペースなどを管理画面上で柔軟に変更でき、アプリのコードを直接変更することなく、見た目やコンテンツを更新できる点が特徴です。</p>
<p>※設定値配信自体については、<a href="https://cxclip.karte.io/products/info/setteichi-haishin/">KARTE for App 設定値配信機能｜ 管理画面からネイティブ要素の変更が可能に！開発工数も削減可能！</a>を参照ください。</p>
<h3>具体的なタスク</h3>
<p>KARTEの管理画面で設定された通りの見た目（画像サイズ、スペースなど）で、Androidアプリ上にカルーセルが正確に表示されるようにSDKを実装・修正することでした。</p>
<h3>AIの活用</h3>
<p>私はこれまでバックエンドやインフラを中心に開発しており、Androidネイティブアプリ開発の経験はほとんどありませんでした。そこで、この未経験の分野に効率的にキャッチアップし、開発を進めるという目的で、積極的にAIツールを活用しました。<br>
具体的には、開発の初期段階でDevinに大まかな実装方針を伝えてコード生成を依頼し、基本的な構造や必要なメソッドを把握しました。その後、Cursorを用いて、Devinが生成したコードや既存コードをベースに、細かいロジックの実装、エラーの修正、リファクタリングなどを、AIと対話しながら進めました。</p>
<h2>活用したAIツール</h2>
<p>弊社のMobile SDKはオープンソースであり、コード流出リスクがないためAIの導入ハードルが低いため、さまざまなAIツールを試験導入しています。今回の実装には、主に2つのAIツールを使用しました。自律的にタスクを遂行しPull Requestの作成までを行ってくれるDevin、そして、エディター上でAI Agentを使用することができるCursor Agentです。プレイドのインターンでは、インターン生にも大きな裁量や権限が与えられることもあり、AIに関しても社員と同じように導入、使用することができます。</p>
<h2>AIの活用ポイント</h2>
<p>ツールの棲み分けとして、初動でDevinでPRまで作り、その後の改善をCursor Agentで行う形をとることが多かったです。</p>
<h3>1.まずDevinにPRを作ってもらう</h3>
<p>DevinはSlackから命令するだけで、branchのcheckoutからPR作成までを自動で行ってくれるため、イシュー着手時の初動のコード作成に役立ちます。</p>
<p>具体的には、issueの実装方針を決め、それをそのままSlack経由でDevinに伝えるだけで、早ければ5分ほどでPRを仕上げてくれます。気持ち的には初めての部下を持った感覚でした。</p>
<p>今回の実装は、サーバーから受け取った値を動的に参照する点や、カルーセルという動きがあるUIの実装だった点より、コーナーケースや細かいスタイリングが求められました。結果として、Devinが初動で完璧な実装をしてくれることは少なかったです。</p>
<p>したがって、Devinに先にPRを作ってもらい、使うライブラリや実装戦略の当たりをつけつつ、ライブラリなどの情報をキャッチアップしながらその後の修正は後述のCursor Agentでのバイブコーディング、という流れを取ることがメインでした。</p>
<p><img src="https://ik.imagekit.io/plaid/2b0bd875-cb96-40b0-8b69-19843401079d/Frame3.png" alt="Frame3.png"></p>
<h3>2.Cursor Agentとの共同作業</h3>
<p>Devinに初動のPRを作ってもらった以降は、主に素早くコード改善が可能なCursor Agentと一緒にVibe Codingをしながら開発を進めました。</p>
<p>Android開発の代名詞でもあるAndroid Studioは主にビルドに留め、基本的なコード修正はCursor上で用いました。Cursor Agentでは、Claude 3.5 Sonnetを最初は使っていましたが、最近では新しく登場した、Claude 3.7 SonnetやClaude 3.7 Sonnet thinkingを使用しています。</p>
<p>Devinは依頼を出してからPRへの反映まで、どんな軽微なものでも1分以上かかってしまいます。問題箇所がある程度特定できていたり、実装内容が明確な追加実装の場合は、Cursor Agentがローカルで生成するコードを確認しながら再度依頼を出したり、自分でコードを補完したりする方が効率的と感じました。</p>
<p><img src="https://ik.imagekit.io/plaid/ecfc61ba-2105-4013-a8e9-361ebe0836b0/image.png" alt="image.png"></p>
<p>なお、Android開発における難しさとして、CursorはVSCodeベースのためAndroid Studioと同等の静的解析を適用するのが難しく、AI Agentの強みである静的解析を活用したコーディング支援を最大限に活かせないという点がありました。そのため、Android Studioで検出されたエラーをプロンプトとしてCursorに与えたり、「そのメソッドは存在しない」といった具体的なフィードバックを与えたりする必要がありました。このように、現状の私の開発環境では、Android開発においてAI Agentのポテンシャルを最大限に引き出すには課題がありました。これは、私の開発環境構築に改善の余地があることも一因と考えています。</p>
<p><img src="https://ik.imagekit.io/plaid/45be9214-819a-4da9-9722-f709b0a8d36f/image.png" alt="image.png"></p>
<h2>感想と今後</h2>
<p>Android開発経験の浅いバックエンドエンジニアでしたが、AIを活用することで、Android SDK開発タスクを遂行できました。自分としても、AIを活用することで自分の専門分野以外でもvalueを発揮できキャリアやエンジニアとしての幅を広げられるとても良い機会となりました。プレイドのインターンでは、このように自分の得意領域以外にも挑戦できる機会をいただけることがよくあります。今回は約3ヶ月ほどだけ、Mobile SDK Enginnerとして働きましたが、プレイドでは自分のようにさまざまな開発領域にチャレンジしたいインターン生も大歓迎しています！</p>
<p><a href="https://open.talentio.com/r/1/c/plaid/pages/106581">【26卒/27卒】エンジニアサマーインターン / 株式会社プレイド</a><br>
<a href="https://open.talentio.com/r/1/c/plaid/pages/90783">新卒採用 &amp; インターン (Engineer) / 株式会社プレイド</a></p>


プレイドでのエンジニアインターン体験記。バックエンド出身の未経験者が、AIツールを活用してモバイルSDK開発に挑戦。学習の壁を壊し即戦力になるまでのリアルな成長ストーリーを紹介します。

プレイドインターン体験記：AIが学習の壁を壊す、未経験エンジニアがモバイルSDK開発で即戦力になるまで

<h2>はじめに</h2>
<p>プレイドのApp Teamでエンジニアをしている市川です。</p>
<p>App Teamとは『KARTE for App』は分析から施策実行までをワンストップで提供し、モバイルアプリのエンゲージメントをより高めるためのプロダクトを提供するチームです。</p>
<p>今回はApp Teamのエンジニアだけで1日ハッカソンを開催し、KARTE for Appが提供するSDKから送信されるイベントデータをリアルタイムに近い速度で閲覧可能にする新機能を作りました！ 🥳</p>
<h2>なぜハッカソン？</h2>
<p>App Teamの開発は、「大きなIssue＝エピックでチーム対応、小さなIssue＝月1回のスプリントで個人ごとにIssueをアサイン」というスタイルで進めています。ただ、ちょうど中間レベルのIssueで「これがあったら便利だよね」と言われつつ、誰も手をつけられずにいたものが、なかなか実行に移されない課題がありました。そこで、チームビルディング観点も含めて「1日ハッカソンで一気に作ってしまおう！」というでハッカソンを決行しました 😎</p>
<h2>当日の流れ</h2>
<p>1日ハッカソンにはApp Teamのエンジニア4名、デザインエンジニア1名、そしてインターン生1名が参加しました。朝から集まって開発するというのは、なかなかない機会なので学園祭感で面白かったです！</p>
<p><strong>9:00〜</strong></p>
<ul>
<li>ブリーフィングと質問対応</li>
<li>タスク分担やざっくり設計の打ち合わせ</li>
</ul>
<p><strong>12:00〜</strong></p>
<ul>
<li>ランチ（お弁当を食べながら雑談＆進捗共有）</li>
</ul>
<p><strong>16:30〜</strong></p>
<ul>
<li>Pull Request作成・レビュー・動作確認</li>
</ul>
<p><strong>18:00〜</strong></p>
<ul>
<li>チーム内でデモ共有</li>
<li>「早く使いたい」というフィードバックに盛り上がるw</li>
</ul>
<p><strong>18:30</strong></p>
<ul>
<li>解散</li>
</ul>
<h2>作成したかった機能</h2>
<p><strong>概要</strong></p>
<ul>
<li>KARTE for Appが提供するSDKから送信されるイベントデータを、<strong>ほぼリアルタイム</strong>でKARTE管理画面から閲覧できるようにする</li>
</ul>
<p><strong>制約</strong></p>
<ul>
<li>従来の仕組みではイベントデータが送信されてから、KARTE管理画面で閲覧するまでに数秒遅延があるため別の仕組みを考える（詳しくは後述）</li>
<li>社内検証から始めて、将来的にはクライアントにも提供する想定</li>
<li>保守性・拡張性・セキュリティを担保した設計にすること</li>
</ul>
<h2>背景/課題</h2>
<p>KARTE for Appの提供するSDKは、モバイル向けのネイティブアプリ上でのユーザー行動を計測したり、アプリ内メッセージやプッシュ通知でのアクションを行うことが可能にするものです。</p>
<p>実際にアプリを操作すると、そのイベントデータをKARTE管理画面で閲覧できますが、閲覧タイミングには数秒のラグが発生します。プレイドの強みでもあるリアルタイム解析基盤「Blitz」を通し、BigQueryに保存されたデータをKARTE管理画面で参照し表示しているためです。Blitzについて、詳しく知りたい方はこちらをご覧ください！<br>
<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a></p>
<p>実際の運用上、「イベントデータが正しく送信されているかをテストしたいだけ」の場面があり、その数秒が意外と煩わしいという声があがっていました。</p>
<h2>成果物</h2>
<ul>
<li>送信されたイベントデータを閲覧するための画面（React）</li>
<li>SDKから送信されるイベントデータを受け取るエンドポイントとロジック（express）</li>
<li>イベントデータを新しく作成したエンドポイントに送付するモジュールの作成（iOS/Android）</li>
</ul>
<h3>実装の仕組み</h3>
<p><strong>従来のフロー</strong></p>
<p><img src="https://ik.imagekit.io/plaid/85f19485-7f93-4445-bddd-e89169efc517/%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-02-269.56.02.png" alt="スクリーンショット2025-02-269.56.02.png"></p>
<p>従来は、SDKからのイベントデータが「Blitz」で解析され「BigQuery」に保存されてから、KARTE管理画面から参照しています。数秒の遅延が発生する原因でした。</p>
<p><strong>新しく作成したフロー</strong></p>
<p><img src="https://ik.imagekit.io/plaid/7d1276bf-05b1-4afa-959b-28648c07f69a/%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-02-269.56.20.png" alt="スクリーンショット2025-02-269.56.20.png"></p>
<h3>工夫した点</h3>
<ul>
<li>「SSE（Server-Sent Events）」を使い、サーバーがイベントを受け取ったタイミングでフロントエンドに即通知する設計を採用した</li>
<li>「KARTE」はマイクロサービスアーキテクチャを採用しており、イベントデータ受信用サービスとKARTE管理画面は別サービスになっている
<ul>
<li>ここを「Redis」の<a href="https://redis.io/docs/manual/pubsub/">Pub/Sub機能</a>で接続して、リアルタイム通知を実現した</li>
</ul>
</li>
<li>クライアントの本番環境には要らない機能なので、コアのSDKのモジュール群とは別のモジュールとして開発し、コア側はイベントビューワーのモジュールを「知らない」状態を実現した</li>
<li>フロントエンド側は、<a href="https://tech.plaid.co.jp/analyze-internal-ui-library-usage">弊社デザインシステムSourのReactJS用ライブラリである「sour-react」</a>を使うことで、フロントエンジニアだけで綺麗なUIを実現した</li>
</ul>
<h3>デモ</h3>
<p>今回開発したUIでは、アプリ操作（ボタンクリックなど）からリアルタイムにイベントデータがKARTE管理画面で表示され、イベントデータをその場で確認できます。<br>
<img src="https://ik.imagekit.io/plaid/b4b580dc-5ecd-417a-b576-a0d364d0d7bc/ScreenRecording.gif" alt="ScreenRecording.gif"></p>
<p>従来の画面（数秒の遅延があるため、テスト時には待ち時間が発生していました）</p>
<p><img src="https://ik.imagekit.io/plaid/be922b0a-d55f-417d-ba98-da8ba318b9a9/%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-02-0619.30.46.png" alt="スクリーンショット2025-02-0619.30.46.png"></p>
<p>この機能によって「誤ったフィールドを送っている」「イベント自体が飛んでいない」といったミスを即座に発見できるようになりました！この改善によってデバッグやテスト作業が劇的に楽になり、チーム内外のメンバーから「便利になった」と好評です！</p>
<h2>まとめ</h2>
<p>1日ハッカソンという短い時間でしたが、集中力とモチベーションを高められたのも大きな成果です。実際にメンバーからは「丸一日コードに没頭できて最高」「少し重いなと思っていたIssueも意外と完成できた」といった声があがりました。</p>
<p>App Teamでは、クライアントSDKの開発と運用からKARTE管理画面の開発をしています。スタートアップからメガバンクまで、幅広いクライアントが利用できるマーケティング機能を提供するSDKを開発し、日々数千万人を超えるエンドユーザーへの価値提供ができる環境です。<br>
興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


この記事ではMobile SDK発火のKARTEイベントをリアルタイムに閲覧する機能をハッカソンで１日で作った話を掲載します

Mobile SDK発火のKARTEイベントをリアルタイムに閲覧する機能をハッカソンで１日で作った話

<p>こんにちわ、プレイドでエンジニアをしている塩澤（<a href="https://github.com/hshiozawa">@hshiozawa</a>）です。</p>
<p>プレイドはミッションとして「データによって人の価値を最大化する」を掲げています。私たちにとって「データ」は会社のミッションに掲げるほどの重要な存在です。プレイドは多種多様なデータを扱っていますが、データから価値を生み出すためにはその品質（Data Quality）が非常に重要となります。</p>
<p>この記事では Google Cloud Dataplex の<strong>自動データ品質（Auto Data Quality）機能</strong>を使ったデータ品質向上の取り組みについてご紹介します。</p>
<h1>データ品質</h1>
<p>プレイドでは Google Cloud の BigQuery を利用して多種多様な大量のデータを扱っています。データパイプラインやテーブルも数多くあり、マイグレーションも頻繁に行っています。このような大量のデータから価値を生み出すために、データ品質の向上は必要不可欠なものです。</p>
<p>たとえば、ユーザーの Web サイト上での行動データを考えてみます。サイトの運営者はサイトでのユーザー体験をよりよくするためにデータを使ってユーザーを理解しようとします。その時、行動データが次のような状況だとどうなるでしょうか？</p>
<ul>
<li>ユーザー ID が含まれていないレコードが存在する</li>
<li>行動イベントのレコードが一部抜け落ちている</li>
<li>購入イベントのレコードが重複して存在する</li>
</ul>
<p>このような状況ではデータからユーザーを正確に理解することはできませんし、ユーザー体験を向上することもできません。これはあくまで一例ですが、ユーザーのイベントに限らずデータの品質が低い場合には、そこから価値を生み出すことが難しくなります。</p>
<h2>定義</h2>
<p>ここまでは曖昧に「データの品質」という言葉を用いてきましたが、『データマネジメント知識体系ガイド 第二版』（通称 DMBOK）ではデータ品質を次のように定義しています。</p>
<blockquote>
<p>データ品質は、データ品質の各評価軸が要件を満たす度合いとして定義できる。これは要件を、（関連する）それぞれの評価軸ごとに策定する必要があることを意味する。データ品質の定義を簡潔にすると、「目的に適合している」となる。</p>
</blockquote>
<p>このようにデータ品質を考えるためにはデータを評価するための一定の軸を定める必要があります。DMBOK では一般的な合意が得られているデータの評価軸として次のようなものを挙げています（抜粋しています）。</p>
<ul>
<li>有効性（Validity）：定義された領域と一致しているかどうか</li>
<li>完全性（Completeness）：必要なデータが存在するかどうか</li>
<li>一貫性（Consistency）：同じルールで表されているかどうか</li>
<li>適時性（Timeliness）：ユーザーがデータにアクセスできるまでの時間</li>
<li>一意性（Uniqueness）：一意であるべきデータが重複してないかどうか</li>
</ul>
<p>データ品質を向上させるためには、データの特性に応じてこれらがどの程度満たされるべきかの要件を定める必要があります。その後、この評価軸がどれだけ満たされているかを実際に測定し、必要な修正を行います。そして最も重要な点は、この一連の活動を継続して続けていくことです。</p>
<h1>課題</h1>
<p>ここからはプレイドにおけるデータ品質に対しての課題について述べます。話を簡単にするため以下のようなシンプルなパイプラインを想定してみます。</p>
<p><img src="https://ik.imagekit.io/plaid/062cadf1-e172-4bfb-8608-2eea59633cfb/pipelines.png" alt="pipelines.png"></p>
<p>データソースで発生したデータは BigQuery に書き込まれます。その後、解析などのアプリケーションによってデータが変換され、他のテーブルに書き込まれます。このような構成のパイプラインはプレイドに多く存在します。</p>
<p>このようなパイプラインに対していくつかの方法でデータの正しさをチェックしていました。</p>
<p><img src="https://ik.imagekit.io/plaid/de391f90-7578-4620-b522-675d0b19ac9a/checks.png" alt="checks.png"></p>
<ol>
<li>データソースがデータを書き込む際に、書き込む側がデータを確認</li>
<li>データを変換した後に Transformer がデータの正しさを確認</li>
<li>テーブルのチェックジョブが定期的にデータのぬけもれを確認</li>
<li>他のパイプラインがデータを使う前にデータの整合性を確認</li>
</ol>
<p>このようにして様々な箇所で独自のデータのチェックが行われていました。また、これらはすべてのパイプラインで実現されていたわけではなく、それぞれのパイプラインの特性や重要度に応じて実装されていました。</p>
<p>これらの手法は必要に応じて要求に特化したチェックができるのでメリットもありますが、本質的には次のような問題を抱えていました。</p>
<h2>評価軸が不明瞭</h2>
<p>データ品質の定義で述べたように、データ品質には評価軸という考え方があります。しかし、この確認方法では、それぞれがどの評価軸に対応したチェックなのかが不明瞭です。この曖昧さによって問題を正確に捉えることが困難になり、効果的な施策が実行されない要因となっていました。</p>
<p>また、評価軸が不明瞭であることでデータ品質という概念自体をチームに浸透させることが難しいという面もありました。</p>
<h2>要求が分かりづらい</h2>
<p>評価軸の問題に加えて、それぞれのデータに求められている要求が明らかになっていないことは大きな問題でした。これらの方法によって「データに問題がない」ことは確認できています。しかし、データが満たすべき要求が明確になっていません。</p>
<p>これは要求をコード上に手続き的に記述したり、確認用の SQL クエリの実行で実現していることも要因です。手続き的なコードや確認用の長いクエリを見ただけでは、何が満たすべき基準なのかを判断することは難しくなってしまいます。</p>
<h2>観測可能性が低い</h2>
<p>既存の確認方法では「データがテストケースを満たしたかどうか」の単純な事柄しか分かりません。「テストケースは満たしているが品質が徐々に劣化している」ようなケースが把握できません。そのため、問題が起きる前に早めに手を打つことができません。また、過去の履歴を統一的に記録する仕組みがないため昔の品質や、品質の推移を確認できていません。</p>
<h2>仕組みの乱立</h2>
<p>それぞれの部分で独自の仕組みを作ったことで、プロダクトを横断する統一的な基準を作ることが難しくなってます。また、それぞれでデータの確認の実現方法が異なるため、あるチームは SQL クエリとして実現し、あるチームは API を利用して確認する、といったように確認方法が乱立しました。</p>
<p>実現方法が異なることでメンテナンスコストが高くなり、最悪の場合はメンテナンスされなくなり放置される可能性もあります。こうなるとデータ品質を保つことは難しくなります。</p>
<h1>Dataplex 自動データ品質の採用</h1>
<p><a href="https://cloud.google.com/dataplex?hl=ja">Google Cloud Dataplex</a> はデータを管理・統合するためのデータファブリックです。BigQuery に限らず分散したデータを統合・統制するためのデータカタログやデータメッシュなど、様々な機能を提供しています。</p>
<p>自動データ品質はこの Dataplex 内の機能の一つです。BigQuery のテーブルに対してルールを定義し、ルールを満たしているかどうかを確認することができます。</p>
<p>ここからは Google Cloud Dataplex の自動データ品質機能（以下、自動データ品質）を採用した理由について述べます。ここでは自動データ品質の利用の仕方については詳しく書きません。利用方法はドキュメント等を参考にしてください。</p>
<p><a href="https://cloud.google.com/dataplex/docs/auto-data-quality-overview?hl=ja">自動データ品質の概要  |  Dataplex  |  Google Cloud</a></p>
<h2>理由1：ルールを YAML で記述できる</h2>
<p>自動データ品質ではルールを下記のような YAML で記述することができます。</p>
<pre><code class="language-yaml">rules:
- uniquenessExpectation: {}
  column: transaction_id
  dimension: UNIQUENESS
- nonNullExpectation: {}
  column: amount
  dimension: COMPLETENESS
  threshold: 1
- setExpectation :
    values :
    - 'USD'
    - 'JPY'
    - 'INR'
    - 'GBP'
    - 'CAN'
  column : currency_id
  ignoreNull : true
  dimension : VALIDITY
  threshold : 1
</code></pre>
<p>データが満たすべきルールを宣言的な形で記録できるのは大きな利点です。これによってそれぞれのカラムが満たすべき要求を把握することが簡単になります。また、Single Source of Truth となっているので、満たすべき要求を変えたい場合はこの YAML を変えるのみです。</p>
<h2>理由2：スコアリング</h2>
<p>自動データ品質のチェック結果には <code>0~100</code> のスコアが含まれています。これまではテストの成功か失敗しか把握できませんでしたが、ある程度の尺度で品質を評価できるようになりました。また、全体のスコアに加えて YAML で設定した dimension（評価軸）ごとのスコアも取得することができるため、評価軸ごとの品質評価も可能となります。</p>
<h2>理由3：シンプルな仕組み</h2>
<p>BigQuery のデータ品質を確認するツールは自動データ品質以外にもいくつかあります。dbt や dataform などがありますが、これらはデータ管理ツールの一種でテーブル自体をそれらのフレームワーク上で管理するのが一般的です。</p>
<p>その点、自動データ品質は BigQuery のデータ品質を確認する部分だけで利用できることができます。すでにある BigQuery のデータに対して変更を加える必要はありません。また、自分でインスタンス等のリソースを準備する必要もありません。これらは自動でデータ品質を採用した大きな理由です。</p>
<h2>理由4: BigQuery との親和性</h2>
<p>自動データ品質は BigQuery を前提に作成されているので BigQuery との親和性が非常に高いです。弊社は多くのデータを BigQuery で扱っているのでこの点はとても重要です。</p>
<p>具体的にはパーティションごとのインクリメンタルスキャンや、ネイティブテーブル以外にも多く対応しています。また、BigQuery の既存のテーブルをスキャンし、自動でそれを満たすようなルールを作成してくれるような便利な機能もあります。</p>
<h2>理由5：実行履歴の記録</h2>
<p>チェックの結果は Google Cloud コンソールから GUI で確認できます。それ以外にも結果を BigQuery のテーブルに保存することもでき、ほぼ永続的にデータ品質の推移を保持することが可能です。</p>
<p>また、前述したスコアリングに加え、カラムごとの細かいチェック記録も保存されているで、あとからカラムごとの品質推移を追うこともできます。</p>
<h1>アーキテクチャ</h1>
<p>ここからは構築したシステムのアーキテクチャについて説明します。</p>
<p>Dataplex の自動データ品質が持っているマネージドな機能をベースにして、プレイドの状況に合わせて補助的なアプリケーションを作成してシステムを構築しました。構築したアーキテクチャの全体像は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/433c59d4-7c53-4e52-9607-299d0081a796/architecture.png" alt="architecture.png"></p>
<h2>スキャン実行アプリケーション</h2>
<p>自動データ品質を実行するためのアプリケーションは独自に実装しました。このアプリケーションは API を利用して自動データ品質を実行します。自動データ品質はマネージド機能なので実行アプリケーションを作らずとも利用することもできます。ただ、プレイドの状況に合わせるため、下記のような機能を実装して自動データ品質を補完していますました。</p>
<ul>
<li>複数のルールを指定可能にし、同時並行で実行できるようにした</li>
<li>日付を指定可能にして、日付シャーディングテーブルに対応した</li>
<li>リージョンを指定可能にして、同じルールを異なるリージョンでチェックできるようにした</li>
</ul>
<p>このように独自のアプリケーションを作ることで、自動データ品質の機能を補ってより柔軟なチェックが可能になりました。</p>
<h2>ルールの管理</h2>
<p>上述したようにテーブルの満たすべきの仕様は YAML ファイルとして定義しています。この YAML はスキャン実行アプリケーションのソースコードと同一の Git リポジトリでバージョン管理しています。こうすることであるべき仕様とルールの管理が一元的に管理できるようになっています。また、Git を利用するため変更履歴の確認が容易になっています。</p>
<h2>Google Kubernetes Engine で実行</h2>
<p>作成したスキャンアプリケーションは Docker Image としてビルドしたあと Google Kubernetes Engine で実行しています。Docker Image にはルールの YAML も含めて実行に必要な一式がすべて含まれているので再利用が容易になっています。通常、このアプリケーションを CronJob として実行することで定常的な品質チェックに利用しています。</p>
<p>現時点ではチェックアプリケーションは GKE で動作させていますが、Cloud Run などのよりマネージドな環境で動作させることも可能です。また、ルールの更新（コミット＆プッシュ）と、そのデプロイは分離されているため検証環境での検証も容易になっています。</p>
<p>プレイドでは GKE 上で使えるワークフローツールを利用してパイプラインを構築しています。作成したスキャンアプリケーションはこのパイプラインとも連携可能です。こうすることで特定のジョブワークフローの最後にスキャンを実行し、パイプライン実行の結果に対する品質をすぐにチェックすることもできます。</p>
<h2>モニタリングツール</h2>
<p>実行アプリケーションを独自に実行したことで、外部のモニタリングツールと連携することが可能です。プレイドでは横断的なモニタリングツールとして Datadog を用いています。Datadog にすべての結果を送ることは現実的ではないため、結果の一部をカスタムメトリクスとして送信してモニタリングに利用しています。</p>
<h1>成果</h1>
<h2>データ品質の導入</h2>
<p>既存のデータパイプラインを変更せずにデータ品質を観測するための仕組みを導入することができました。これに伴ってデータに対する要求を明確にし YAML 形式で表すことができました。評価軸がきちんと明確になったことでデータ品質に対する精度が高まりました。また、スコアリング値によって以前よりもより品質をより詳細に把握できるようになったことも大きな利点です。</p>
<h2>観測可能性の向上</h2>
<p>品質チェックを定常的で統一的に実行できるようになりました。スキャン結果は Google コンソールや Datadog 上で確認できるようになっています。このような定常的で統一した仕組みがあることでチームでの品質のコミュニケーションが円滑になっています。</p>
<p>また、データ品質の劣化を検知できるようになりました。その結果、問題が発生する前にアクションをとれるようになっています。実際にいくつかのテーブルで品質の劣化は検知することができアクションをとることができました。このように、間違いなく観測可能性が高まりました。</p>
<h2>スケーラブルな仕組み</h2>
<p>これまでばらばらだったデータのチェックの仕組みを統一的な仕組みに変更し、プロダクトの種類が増えた場合にも対応できるようなスケーラブルな仕組みになりました。統一された仕組みを活用することで、チェックの導入コストを大幅に削減し、チェックに一貫性が生まれています。新しい品質チェックの導入と運用の負荷を大幅に削減することができましたし、ルールを作るときは YAML ファイルを作るだけですむため開発者体験も向上しています。</p>
<h1>まとめ</h1>
<p>今回は Google Cloud Dataplex の自動データ品質を用いて、データ品質管理の仕組みを構築しました。Dataplex を活用することで既存のデータパイプラインに影響を与えることなく、アドインの形でデータ品質を測定し、品質改善の仕組みを整えることができました。この仕組みによって、データに対する一貫した品質チェックが可能となり、異常検知・品質の劣化への迅速な対応によって信頼性を向上させることができました。</p>
<p>今後もこうした取り組みをさらに加速させ、プレイドが提供するデータへの信頼を着実に高めるとともに、データによる価値を最大化するように取り組んでいきます。</p>


この記事では Google Cloud Dataplex の自動データ品質（Auto Data Quality）機能を使ったデータ品質向上の取り組みについてご紹介します。

Google Cloud Dataplex を使ったデータ品質の向上

Rollupのビルド時間を10倍高速化することでプレビュー表示を改善した話

プレイドインターン体験記：インターンを通じて得た技術力と開発力の学び

<h1>はじめに</h1>
<p>この記事は <a href="https://qiita.com/advent-calendar/2024/datadog">Datadog Advent Calendar 2024</a> の 18 日目の記事です。<br>
こんにちは、プレイドの Developer Experience &amp; Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は <a href="https://docs.datadoghq.com/continuous_integration/">CI Visibility</a> と <a href="https://docs.datadoghq.com/dashboards/widgets/split_graph/">Split Graph</a> です。</p>
<p>Datadog の CI Visibility は CI のパフォーマンスを可視化できるプロダクトです。 GitHub Actions や CircleCI など多くのインテグレーションがサポートされていますが、GCP の CloudBuild はサポートされていません。また、CloudBuild には継続的にパフォーマンスを可視化できるような機能がありません。</p>
<p>そこで、CloudBuild のパフォーマンスを <a href="https://docs.datadoghq.com/api/latest/ci-visibility-pipelines/">CI Visibility の API</a> を活用して計測することにしました。</p>
<h1>CI Visibility とは</h1>
<p>CI Pipeline のパフォーマンスを可視化します。APM のように、Pipeline トレースを可視化できるところが大きな利点だと思っていて、他にもさまざまな機能がサポートされています。サポートされる機能は、プロバイダごとに異なり、<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#supported-features">こちら</a>で確認することができます。弊社では主に GitHub Actions と CircleCI を利用していますが、GitHub Actions では Step spans や Queue time、Infrastructure metric correlation がサポートされているのに対して、CircleCI ではそれらがサポートされておらず、ボトルネックの特定が難しかったりします。GitHub Actions や CircleCI 自体にもこのような Insight の機能は備わっているのですが、Datadog では使い慣れたクエリで柔軟に集計したり、Dashboard や Monitor との連携もできるので、なるべく Datadog を使うようにしています。</p>
<p>ちなみに CloudBuild は Integration はサポートされていないので OTHER CI PROVIDER というところに書いてある機能が使えます。</p>
<h1>CI Visibility Event の Level について</h1>
<p>CI Visibility には Event という形でデータを送ります。Event には Pipeline, Stage, Job, Step の4段階の Level があります。</p>
<p>Pipeline は Stage をまとめたもの、Stage は Job をまとめたもの、Job は Step をまとめたもの、というように階層構造になっています。<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#terminology">こちら</a>にプロバイダごとの対応づけが書かれています。例えば GitHub Actions であれば下記の対応になります。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>GitHub Actions</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Workflow</td>
</tr>
<tr>
<td>Job</td>
<td>Job</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>CloudBuild のパフォーマンスを可視化するにあたっては、下記のように Level を対応づけました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>CloudBuild</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Build</td>
</tr>
<tr>
<td>Stage</td>
<td>キューに格納・ソースの取得・全てのビルドステップ・（ある場合は）イメージの PUSHの4つのステージ</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>Pipeline や Step に関しては議論の余地はあまりなさそうです。Stage という単位は別に使わなくても良いのですが、実際に可視化してみると最初の Step が実行されるまでにかなり時間がかかっていて、その内訳も知れた方が良いと感じたので導入しました。</p>
<p>また、階層構造さえあっていれば可視化はできるので、Stage ではなく Job としてこれらを表現してもよかったのですが、CircleCI や GitHub Actions における Job とはかなり別物という感覚があったので Stage として表現しました。</p>
<p>CircleCI や GitHub Actions では Job は1つのコンテナ（もしくは VM）実行環境という単位になっています。そのため異なる Job 間ではボリュームの永続化などは明示的に書く必要があります。CloudBuild においては、1つの Build 内で複数の実行環境を立ち上げることはなく、前の Step で書き込まれたディスクには後続の Step でアクセスすることができます。</p>
<p>Stage がしっくりくるかというとわからないのですが、消去法で決めました。</p>
<h1>実装</h1>
<p>各所要時間をどの Level として送るかが決まったので、実装のステップに入ります。</p>
<p>CloudBuild は、実行の各タイミングで Cloud PubSub にイベントを送っています。PubSub イベントをトリガーに Cloud Run Functions を実行することができるので、今回は Cloud Run Functions で実行することにしました。他の方法としては、定期実行して特定の期間内に実行された CI Pipeline の結果を送るというやり方もありそうですが、パフォーマンス改善タスクに取り組む際にはなるべく早く結果が可視化できた方が良いというのもあり、上記の手法にしました。</p>
<h2>Queue Time</h2>
<p>Queue Time は startTime から createTime を差し引いた時間としています。また、Pipeline の attribute にも queueTime がありますが、GitHub Actions のような良い感じの可視化がされなかったので、Stage としても実装しました。</p>
<p>GitHub Actions の Queue time の良い感じの可視化:<br>
<img src="https://ik.imagekit.io/plaid/97e233cd-f4e8-4928-8c08-220bed39e581/github-actions-queue.png" alt="github-actions-queue.png"></p>
<h2>Status</h2>
<p>Cloud Build における Status と、CI Visibility Pipeline で定義されている Status はちょっと違うので、注意が必要です。</p>
<p>Ci Visibility Pipeline で定義されている status は下記になります。</p>
<table>
<thead>
<tr>
<th>Level</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>Step</td>
<td>success, error</td>
</tr>
<tr>
<td>Stage, Job</td>
<td>success, error, canceled, skipped</td>
</tr>
<tr>
<td>Pipeline</td>
<td>success, error, canceled, skipped, blocked, running</td>
</tr>
</tbody>
</table>
<p>Cloud Build の場合、 <code>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED, EXPIRED</code> があります。</p>
<p>今回のユースケースとしては実行中の Pipeline に関しては対象外としても良いかなと思ったので、完了後のステータス（ <code>SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED</code> ）のイベントが来た時だけ処理を実行するようにしました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>Cloud Build</th>
</tr>
</thead>
<tbody>
<tr>
<td>success</td>
<td>SUCCESS</td>
</tr>
<tr>
<td>error</td>
<td>FAILURE, INTERNAL_ERROR, TIMEOUT</td>
</tr>
<tr>
<td>canceled</td>
<td>CANCELED</td>
</tr>
<tr>
<td>処理しない</td>
<td>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, EXPIRED</td>
</tr>
</tbody>
</table>
<h2>Git</h2>
<p>CI Visibility Pipeline では git というフィールドに git repository の url や commit sha、authorEmail などを入れることができます。sha や repo url は Cloud Build のイベントに入ってるのですが、authorEmail は取り出せなかったので適当に入れました。GitHub API を叩いて commit sha から authorEmail を取得する方法もあると思いますが、実行者が気になったら commit のページに飛べば良いのでそこまでしなくても良いと判断しました。</p>
<h2>ソースコード</h2>
<p>最終的なソースコードは下記のようになります。依存ライブラリをインストールしてビルドすれば別の環境でも動くと思うので、ぜひ試してみてください。注意点としては <code>DD_API_KEY</code> と <code>DD_APP_KEY</code> を secret として Cloud Run Functions で読み込めるようにする必要があるのと、Datadog で us1 以外のリージョンを使っている場合には <code>DD_SITE</code> 環境変数を指定する必要があります。</p>
<pre><code class="language-typescript">/**
 * Cloud Build 終了後に Datadog にイベントを送る
 */

import { PubsubMessage } from '@google-cloud/pubsub/build/src/publisher';
import { google } from '@google-cloud/cloudbuild/build/protos/protos';
import { client, v2 } from '@datadog/datadog-api-client';

type Build = google.devtools.cloudbuild.v1.Build;
type Status = keyof typeof google.devtools.cloudbuild.v1.Build.Status;

export async function main(event: PubsubMessage): Promise&lt;void&gt; {
  const jsonstr = Buffer.from(event.data as string, 'base64').toString();

  const data = JSON.parse(jsonstr) as Build;

  if (!isFinishedStatus(data.status as Status)) {
    console.log('event does not meet conditions.');
    return;
  }

  // pipeline
  const { status, createTime, startTime, finishTime, id, logUrl } = data;
  const triggerName = data.substitutions['TRIGGER_NAME'];
  const commitSha = data.substitutions['COMMIT_SHA'];
  const repositoryUrl = data.substitutions['REPO_FULL_NAME'];
  const queueTime = startTime
    ? new Date(startTime as string).getTime() - new Date(createTime as string).getTime()
    : undefined;

  const configuration = client.createConfiguration();
  configuration.unstableOperations['v2.createCIAppPipelineEvent'] = true;
  const apiInstance = new v2.CIVisibilityPipelinesApi(configuration);
  const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
    body: {
      data: {
        attributes: {
          resource: {
            end: finishTime ? new Date(finishTime as string) : new Date(),
            start: new Date(createTime as string),
            name: triggerName,
            status: getDatadogPipelineStatus(status as Status),
            level: 'pipeline',
            uniqueId: id,
            url: logUrl,
            git: {
              sha: commitSha,
              repositoryUrl,
              authorEmail: 'unknown@example.com',
            },
            partialRetry: false,
            queueTime,
          },
          service: 'cloud-build',
        },
        type: 'cipipeline_resource_request',
      },
    },
  };
  const result = await apiInstance.createCIAppPipelineEvent(params);

  // stage
  const stages = Object.entries(data.timing).map(([key, timing]) =&gt; {
    return {
      id: key,
      startTime: timing.startTime,
      endTime: timing.endTime,
    };
  });

  const stagesIncludeQueueTime = [
    ...stages,
    {
      id: 'QUEUE',
      startTime: createTime,
      endTime: startTime,
    },
  ];

  for (const stage of stagesIncludeQueueTime) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: stage.endTime ? new Date(stage.endTime as string) : new Date(),
              start: new Date(stage.startTime as string),
              name: stage.id,
              status: 'success',
              level: 'stage',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              id: stage.id,
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // step
  for (const step of data.steps) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: step.timing?.endTime ? new Date(step.timing.endTime as string) : new Date(),
              start: new Date(step.timing!.startTime as string),
              name: step.id!,
              status: getDatadogStepStatus(step.status as Status),
              level: 'step',
              id: step.id!,
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'BUILD',
              stageName: 'BUILD',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // image
  for (const image of data.results?.images ?? []) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: image.pushTiming?.endTime ? new Date(image.pushTiming.endTime as string) : new Date(),
              start: new Date(image.pushTiming!.startTime as string),
              name: image.name!,
              id: image.name!,
              status: 'success',
              level: 'step',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'PUSH',
              stageName: 'PUSH',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }
}

function isFinishedStatus(status: Status): boolean {
  return ['SUCCESS', 'FAILURE', 'INTERNAL_ERROR', 'TIMEOUT', 'CANCELLED'].includes(status);
}

function getDatadogPipelineStatus(status: Status): 'success' | 'error' | 'canceled' {
  if (status === 'SUCCESS') {
    return 'success';
  } else if (status === 'CANCELLED') {
    return 'canceled';
  } else {
    return 'error';
  }
}

function getDatadogStepStatus(status: Status): 'success' | 'error' {
  if (status === 'SUCCESS') {
    return 'success';
  } else {
    return 'error';
  }
}

</code></pre>
<h1>Datadog CI Visibility でみてみる</h1>
<p>こんな感じで Cloud Build のパフォーマンスを可視化することができました。Critical Path を特定し、最もボトルネックになっている step を効率的に改善することができるようになりました！</p>
<p><img src="https://ik.imagekit.io/plaid/56474a37-da8b-423f-bbf9-965d86aee2c3/datadog-ci-visibility.png" alt="datadog-ci-visibility.png"></p>
<p>具体的な改善ポイントとしては下記のようなものがありそうです。Stage を可視化することで、よりパフォーマンス改善の選択肢が増えると思います。</p>
<table>
<thead>
<tr>
<th>時間がかかっている Stage</th>
<th>改善手段の例</th>
</tr>
</thead>
<tbody>
<tr>
<td>QUEUE</td>
<td>Cloud Build の同時実行数を増やす、Private Pool を使う</td>
</tr>
<tr>
<td>FETCH_SOURCE</td>
<td>リポジトリを分割する</td>
</tr>
<tr>
<td>BUILD</td>
<td>キャッシュを使う、並列化する</td>
</tr>
<tr>
<td>PUSH</td>
<td>イメージサイズを小さくする、Artifact Registry と Cloud Build の実行のリージョンを合わせる</td>
</tr>
</tbody>
</table>
<h1>最後に</h1>
<p>Cloud Build のパフォーマンスを Datadog CI Visibility で可視化する方法を紹介しました。</p>
<p>Datadog は各種 Integration 対応が充実していると思いますが、未対応であってもこんな感じで提供されてる API を使って気軽に実装できるのが嬉しいところです。</p>
<p>Cloud Build と Datadog を使っていて、パフォーマンスの改善をしたいと考えている方がいたら参考にしていただけると幸いです！</p>


この記事は Datadog Advent Calendar 2024 の 18 日目の記事です。 こんにちは、プレイドの Developer Experience & Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は CI Visibility と Split Graphです。

Datadog CI Visibility で Cloud Build のパフォーマンスを可視化する

プレイドでエンジニアをしている塩澤です。今回は MongoDB から BigQuery へのリアルタイムレプリケーションシステムをマネージドサービスのみを用いて開発したので紹介します。

MongoDB to BigQuery: フルマネージドなリアルタイムレプリケーションの実現

<h1>はじめに</h1>
<p>初めまして、<a href="https://github.com/jdkfx">田添春樹</a>と申します。2024年9月から12月までの3ヶ月間、KARTE Webチームでエンジニアとしてインターンシップを行なっておりました。</p>
<p>インターンシップに参加する以前、趣味で関わっていたOSSプロジェクトにおいて、Vueを用いた開発を行なっておりました。その際の開発経験が楽しかったことと、これからもVueを用いて開発を行いたいことなどを、プレイドに勤務している親友と話した際に、このインターンシップに誘っていただきました。</p>
<p>私はどちらかと言えば、縁の下の力持ちとして物事に取り組むことが多く、開発においても、開発者が今後の開発をストレスなく、より良い環境で行えるようにリファクタリングなどを行なってきました。面談の際に、その旨を伝え、インターンシップとして開発体験を向上させるための業務をすることとなりました。</p>
<p>このインターンシップで行った内容は以下のようになっております。</p>
<ul>
<li>KARTEのエレメントビルダーのViteバージョンアップ</li>
<li>KARTEのユーザーリストや行動チェーン、ユーザーストーリーといった機能（以下、これらの機能をまとめてinsight-frontと呼称します。）における、開発体験向上を目的としたViteへの移行と、Vueのバージョンアップやそれらに伴う依存パッケージのバージョンアップ</li>
</ul>
<p>本記事ではインターンシップで行ってきたことの内容について、上記の二点をお伝えします。</p>
<h1>エレメントビルダーのViteバージョンアップ</h1>
<h2>課題</h2>
<p>KARTEの<a href="https://support.karte.io/post/67aMq2qoqXQMw6WaDL22Vl">エレメントビルダー</a>は、顧客⼀⼈ひとりに合わせて、最適なコミュニケーションができるように、顧客の行動に基づいてポップアップ表示などのアクションを作成・カスタマイズできる機能です。</p>
<p><img src="https://ik.imagekit.io/plaid/f1201e44-6886-48d6-ba49-83231770813a/action-editor.png" alt="action-editor.png"></p>
<p>しかし、これまでのエレメントビルダーには以下のような課題がありました。</p>
<ul>
<li>開発環境がメンテナンスされていないため、ここ最近のフロントエンド環境と乖離が生じてきて、開発しにくい状況になってきていた</li>
<li>Viteのバージョンが古いため、KARTEのデザインシステムの導入に特別な対応が必要になる</li>
</ul>
<p>特に、一点目の課題が大きく、これまでのエレメントビルダーの開発環境におけるViteやVitestなどのパッケージはエレメントビルダーが開発されていた当時の状態のままになっておりました。これまでの開発環境のままでも開発はすることができますが、フロントエンド周りの環境は日々変わっていきます。今後新たな機能を実装する際、または新たなパッケージを導入する際、開発環境の遅れによって、それらの新しい機能の実装やパッケージの導入により多くの時間をかけてしまうことになります。</p>
<p>これらの課題を解決するために、エレメントビルダーのViteのバージョンを上げることになりました。</p>
<p>これまでエレメントビルダーで使用していたViteのバージョンは<code>3.2.5</code>で、今回のバージョンアップで<code>4.5.3</code>になりました。これまで使用していたVite 3系から一気にViteの最新バージョンへ上げるのではなく、小さくアップデートを行いたかったため、今回は4系へアップデートしました。</p>
<p><a href="https://v4.vite.dev/">https://v4.vite.dev/</a></p>
<p>また、それに伴って、Vitestのバージョンも上げることとなり、<code>0.24.3</code>から<code>0.34.6</code>にアップデートしました。</p>
<p>これまで使用していたVitest 0系から1系に上げるには、Vite 5系が必要となっており、先述のVite 4系を使う方針のために、1系ではなく0系の最新バージョンへアップデートしました。</p>
<p><a href="https://v0.vitest.dev/">https://v0.vitest.dev/</a></p>
<h2>テストが動かない</h2>
<p>ViteとVitestのバージョンアップを行ったことで、テストが動かなくなってしまったため、関連するパッケージのバージョンアップも行っていきました。</p>
<p>エレメントビルダーは細分化されたモジュールで作られており、それぞれに対応するパッケージの管理が複雑になっています。バージョンを上げたパッケージが他のパッケージのバージョンをサポートしていないことや、メンテナンスされていないパッケージを使用していることなど、複数の要因でテストが動かなくなってしまいました。</p>
<p>たとえば、<code>@testing-library/react-hooks</code>というパッケージでは、React 18で<code>renderHook</code>APIが<code>react-testing-library</code>と<code>react-native-testing-library</code>の両方に追加されたことにより、<code>@testing-library/react-hooks</code>を<code>@testing-library/react</code>に書き換える必要があります。</p>
<p><a href="https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support">https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support</a></p>
<p>他にも、<code>@sveltejs/vite-plugin-svelte</code>というパッケージにおいて、Vitest は基本的に<code>node_modules</code>配下にあるモジュールは<code>alias</code>で設定していなくても、モジュール依存を解決してくれるのですが、テスト内でコンポーネントをレンダーした際に<code>onMount</code>が実行されないというバグを解決するために、以下のように明示的に設定しないといけませんでした。</p>
<pre><code class="language-js">import { defineConfig } from 'vitest/config';
import { svelte } from '@sveltejs/vite-plugin-svelte';
import { dirname, resolve } from 'node:path';

export default defineConfig({
  // ...
  resolve: process.env.TEST ? {
    alias: [{
      find: /^svelte$/,
      replacement: resolve(__dirname, &quot;node_modules/svelte/index.mjs&quot;) 
     }]
  } : {
    alias: {
      '@plaidev/karte-action-sdk/templates': resolve(__dirname, './src/templates.ts'),
    },
  },
  // ...
});
</code></pre>
<p><a href="https://github.com/testing-library/svelte-testing-library/issues/222">https://github.com/testing-library/svelte-testing-library/issues/222</a></p>
<p><a href="https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components">https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components</a></p>
<h2>小さく解決する</h2>
<p>先述の通り、エレメントビルダーは細分化されたモジュールで作られており、それぞれにテストが用意されています。（以下は一部抜粋）</p>
<pre><code class="language-text">.
├── api
├── asset-builder
├── core
│   ├── action-compiler
│   ├── action-sdk
│   └── action-utils
├── front
└── internal
</code></pre>
<p>これらのテストのほとんどが動かなくなってしまったので、それぞれのモジュールごとに小さくテストが通るよう修正を行い、最終的に全てのテストが通るようにパッケージのバージョンアップやパッケージの置き換えを行いました。</p>
<p>パッケージのバージョンアップを行った結果、パッケージの破壊的変更によってテストコードの修正を行う必要がありました。修正を行うためには、どこに問題があるのか探す必要があり、使用しているパッケージのソースコードを実際に動かしてみて、意図的にエラーを発生させ、エレメントビルダーのテストにおける問題のある箇所を発見することができました。</p>
<h1>insight-front開発体験改善</h1>
<h2>課題</h2>
<p>insight-frontを開発する際、他のシステムからイベントを飛ばしてデータを作る必要があり、フロントエンドのデバッグに時間を要するという課題がありました。</p>
<p><img src="https://ik.imagekit.io/plaid/a1d7ef2d-33b6-475a-b520-5a8df50adac6/insight-front.png" alt="insight-front.png"></p>
<p>この部分の課題を解決することで、今後新たな機能を開発する際や修正を行う際に素早く対応できるため、これまで使用されていたWebpackからViteへ移行することになりました。</p>
<p>Viteに移行することによって具体的にどんな点がより良くなるのかというと、開発サーバーの立ち上がりがWebpackよりも早くなるのでデバッグに要する時間が少なくなります。</p>
<p><a href="https://vite.dev/guide/why.html#slow-server-start">https://vite.dev/guide/why.html#slow-server-start</a></p>
<h2>Vite移行に向けて</h2>
<p>WebpackからViteへ移行するために、以下のような手順を踏んでいきます。</p>
<h3>Vue 2.7へアップデート</h3>
<p>insight-frontはVue 2で開発されており、ViteではVueアプリケーションのバンドルをするために、Vueの単一ファイルコンポーネントのサポートを提供している<code>@vitejs/plugin-vue2</code>を導入する必要があります。</p>
<p>insight-frontで使用されていたVueのバージョンは<code>2.6.12</code>だったため、<code>@vitejs/plugin-vue2</code>が要求するVue 2の最新バージョンであるVue 2.7へアップデートする必要がありました。</p>
<p>また、Vue 2はすでにサポートが終了しているため、セキュリティパッチを当てたVue 2を使用しています。</p>
<p><a href="https://v2.vuejs.org/v2/guide/migration-vue-2-7.html">https://v2.vuejs.org/v2/guide/migration-vue-2-7.html</a></p>
<h3>ES ModulesとCommonJSによるデュアルパッケージ化</h3>
<p><code>localDependencies</code>というプレイド独自の依存関係の解決機構を使用しており、ここに使用される社内の共通パッケージはCommonJSでビルドされていました。これまではWebpackを使用してバンドルしていたので、CommonJSで書かれた共通パッケージも問題なくバンドルし、アプリケーションを動作させることが出来ました。（Webpackを用いてバンドルしている場合でも、使用しているパッケージがNode.js依存である場合、手動でpolyfillを挿入するように設定する必要があります。）</p>
<p>しかし、この<code>localDependencies</code>の解決機構を使っていることにより、Viteで共通パッケージのCommonJSの依存解決ができずバンドル出来ないため、これらの共通パッケージをES ModulesとCommonJSでバンドルする必要がありました。</p>
<pre><code class="language-json">&quot;localDependencies&quot;: {
  &quot;@plaidev/xxx-common&quot;: &quot;../../../common&quot;,
  &quot;@xxx/insight-front-common&quot;: &quot;../front-common&quot;
},
</code></pre>
<p>insight-frontにおいて、<code>localDependencies</code>という解決機構で依存解決を行なっている共通パッケージ内には大量のコードが存在しており、その中からinsight-frontを動かすために必要なコードを調査する時間や、それらのコードをES ModulesとCommonJSでデュアルパッケージ化するための時間、実際にES ModulesとCommonJSでデュアルパッケージ化した後に、関連するシステムが動くかどうか確認するための時間など、多くの時間を費やすことになるだろうと予想しました。</p>
<p>ES ModulesとCommonJSによる共通パッケージのデュアルパッケージ化をするには多くの時間がかかってしまうため、Viteの機能を利用してES ModulesとCommonJSでバンドル出来ないか試してみることにしました。</p>
<p><a href="https://vite.dev/config/build-options#build-lib">https://vite.dev/config/build-options#build-lib</a></p>
<h3>Viteでビルドする</h3>
<p>上記に書いた通り、insight-frontを取り巻く依存関係の問題は大きく、それらを解決するために大量に時間を要することが予想されました。また、私自身がフロントエンドについての知識がまだまだ浅く、一気にこれらを解決させようとしてどこに問題が発生しているのか調査すること自体にも多くの時間を使ってしまいました。</p>
<p>この失敗を受けて、小さく小さく課題に取り組むことを意識し、最初からアプリケーションのソースコード全体をビルドさせることは考えないようにしました。まずは、小さなHTMLファイルのビルドから行い、実際にアプリケーションを動かした際に問題がないことを確かめることから始めました。そこにVue 2で書かれた小さなコードを追加するような形で、必要なプラグインなどを細かく追加していくなど、インクリメンタルな実装を行なっていくことで自身のViteに対する解像度も上がってきました。</p>
<p>しかし、ここでインターンシップ期間が終わってしまい、insight-frontをWebpackからViteに移行することが出来ませんでした。複雑な問題が絡み合い、この課題を解くのは難しかったのですが、自身が普段のめり込むことが無いような部分にのめり込み、様々なことを学ぶことが出来ました。</p>
<h1>インターンシップを終えて</h1>
<h2>総括</h2>
<p>インターンシップとして主に二つの内容に取り組んできました。</p>
<p>開発環境をメンテナンスをしないまま、放置してしまうことにより、今後のバージョンアップで大きな障壁となってしまうことを避けるためにも、日頃からメンテナンスを怠らないようにしたいです。</p>
<p>しかし、プロダクトの開発において、メンテナンスをすることにより、本来先に実装したかった内容に遅れが生じてしまうことがあります。その実装の遅れとメンテナンスをすることによる恩恵を考えて、両方を天秤にかけ、どちらがプロダクトにより大きなインパクトを与えられるのか考え続けなければなりません。</p>
<p>そして、目の前の難しい課題に対して、直線的に解決策を取ろうとするのではなく、回り道をしつつ、小さく小さく問題を区切りながら解決に向かうことを意識していきたいです。</p>
<h2>成長</h2>
<p>これまでは、主にPHPを用いたバックエンドの開発を行なっており、フロントエンドの開発は自作のブログや先述のOSSプロジェクトの小さな機能の開発以外ではほとんど触ったことがなく、こんなにもガッツリとフロントエンドの領域にのめりこむのは初めてでした。</p>
<p>フロントエンドの技術について、あまり知識がない状態からキャッチアップを行いつつ、大きな成果を出すことが出来て、とても学びのあるインターンシップだったと感じております。</p>
<p>もちろん、一人では抱えきれない悩みや課題などが生じた際に一緒に解決してくださったメンターの方やKARTE Webチームの方々のおかげだと感じております。</p>
<p>KARTEの強みを理解し、どうすればその強みをプロダクトに機能として実装できるのか。そして、顧客に大きなインパクトを与えられるか、という思考のサイクルを止めることなくプロダクトに向き合っているプレイドの方々の姿勢に感銘を受けました。</p>
<p>そして、インターンシップを行なっていく中で自分に何が足りないのか、プロダクト開発やその会社に属する人間としてどんな視点を持てば良いのか、深く考えることのできたインターンシップでした。</p>
<h2>最後に</h2>
<p>インターンシップ期間中は広島からフルリモートでの勤務をしていました。フルリモートでなかなか顔を合わせてお話しする機会がない中、広島から東京のオフィスに出社した際には、他のインターンシップ生とのランチに誘っていただいたり、多くの方々とお話しさせていただく機会に参加させていただいたりと、社内の雰囲気もとても良かったです。</p>
<p>3ヶ月という短い間でしたが、メンターの方やKARTE Webチームの方々など、多くの方々のおかげで濃密な3ヶ月を過ごすことが出来ました。本当にありがとうございました。</p>
<hr>
<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>

プレイドインターン体験記：開発体験の向上を目指し行なったこと

Developer Experience & Performance チームでエンジニアをしている大矢です。今回は JavaScript の非同期処理で使われている callback を Promise に移行する手法について、具体的な事例をもとに紹介します。

Mongoose の callback を Promise に移行する手法

KARTEの複数のシステム間で共有する定数ファイルを、これまで社内向けのnpmパッケージとして配布していたところから、代わりとなる独自の仕組みを構築して管理する方式に切り替えたことと、その移行プロセスについて。

npmパッケージの代わりに独自の仕組みを構築して定数ファイルを配布する運用に切り替えた経緯と移行プロセス

Engineer Blog

Recent Article