Engineer Blog

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

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

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

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


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

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

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

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

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

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

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

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

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

PLAIDのインターンを振り返って ~ 開発環境の改善がもたらす新機能リリースの効率化 ~

<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を支える技術

Engineer Blog

Recent Article