「KARTE Message」が取り組む、急成長しているフェーズならではの難しく面白い課題の数々
「KARTE Message」は、メールやLINE、アプリプッシュ通知といった「Webサイト外のコミュニケーション施策」の実行を支援するマーケティングオートメーションツールです。CXプラットフォーム「KARTE」の情報と連携することで、ユーザーの特徴に応じた配信セグメントの絞り込みができます。また、ユーザーごとのパーソナライズを行い、メッセージの本文をカスタマイズすることが可能です。
KARTE Messageの開発チームに所属するエンジニアの土田雄輝は、プロダクト開発に加えて、ドキュメントの整備やコードのリファクタリング、組織づくり・人材育成にも尽力しています。今回は土田に、これまでのキャリアやKARTE Messageの特徴、今後のビジョンなどを聞きました。
「働く環境の大切さ」を痛感したアルバイトの経験
――まずキャリアについて、学生時代から話を聞かせてください。
プログラミングを始めたのは中学3年生の頃でした。「マインクラフト」に熱中しており、ゲームのプラグインを作るためにJavaを勉強し始めたのがきっかけです。その後、体系的にプログラミングを学びたいと思い、情報系の高等専門学校に進学しました。コードを書くことに没頭したくて、高専プロコンに出場する部活に入りました。チーム戦でプログラミングのスキルを競う大会ということもあり、入部当初は全然勝つことができませんでした。
なんとかして部を強くしようと、同じ学年で一番頭が良い人に声をかけて入部してもらいました。すると、2年目に全国大会の準優勝まで進むことができたんです。そこから、メンバーの教育コンテンツを充実させたり、仲間を増やしたりして、高専生活最後の年に優勝できました。これが、プログラミングにおける大きな成功体験になりました。
高専を卒業した後は、大学に編入しました。その頃には将来はプログラミングで飯を食うと決めていたので、実務経験を積みたいと思いエンジニアのアルバイトをしましたが、正直あまりうまくいかなかったんですよね。
当時の私は「たくさんコードを書いて成長する」と意気込んでいたんですが、扱っていたプロダクトはかなり歴史が長く、コードが複雑に入り組んでいました。技術的負債も溜まっていて、ちょっとしたバグの修正に1ヶ月かかることもありました。それがカルチャーショックで、戸惑いがありました。
開発チームのプロジェクトマネージャーともうまくいきませんでした。その方はプロダクトを20年近く見ている大ベテランだったんですが、私は「このスパゲッティコードをすぐにリファクタリングしましょう」とか「新しい技術をどんどん取り入れて開発しやすくしましょう」など、率直に思ったことをスバズバ言ってしまっていました。自分も良くなかったのですが、当時のチームでは自分の意見や考えを真剣に検討してもらえることが少なかった。目の前に解決すべき課題があるのに何も前に進められない感覚を覚え、悔しいし悲しかったですね。
その経験は、私の今の価値観にかなり影響しています。仮にどれだけ意欲のあるエンジニアがいたとしても、環境が合わなければ成長することも、フルに実力を発揮することもできません。だからこそ、私のキャリアにおいては「意欲や可能性のある人がつぶれないような環境を、積極的に作っていくこと」を常に考えて仕事をしています。
プレイドはとにかく“人”を重視する会社
――大学卒業後は、合同会社DMM.comに新卒入社したそうですね。
DMM.comには、私の競技プログラミング関係の知り合いがいました。その人の紹介でインターンシップを経験したところ、先ほど述べたアルバイトとは真逆の体験になったんです。開発がすごく楽しくて、ここならやっていけそうだと思い、入社しました。
DMM.comでは、各種APIへのゲートウェイの役割を果たすAPI-Gatewayの開発を担当しました。せっかく仕事でシステム開発に携わるならば、個人開発では絶対にできないような大量トラフィックを経験したいと思ったんです。API-Gatewayへのアクセス量はとてつもなく、かつ認証・認可の機能も提供しているシステムであったため、パフォーマンスやセキュリティの要件がシビアな環境で、鍛えられました。
チームビルディングにも力を入れており、インターン生や中途の採用面接に出たり育成をしたりといったことも経験しました。徐々にチームが成長してきたので「次のチャレンジをしたい」と、転職を考えるようになりました。
その頃、技術としてはGoogle Cloud Platform（以下、GCP）によく触れており、より本格的に学びたいと思いました。GCPを活用している会社を探したところ、プレイドが良さそうだとわかったんです。面接で、人材にかなりの投資をしていることや、人を大切にしていることがわかり、私の価値観ともマッチすると感じました。
それから、プレイドのCo-Founder/CPOである柴山と採用面接で話したんですが、人の話を聞く力が強いなと感じました。そのスキルを学びたくもあり、プレイドに行こうという気持ちになりましたね。
KARTE Messageのプロダクト概要
――ここからはKARTE Messageの概要について教えてください。
KARTE Messageは、「KARTE」の分析基盤で集めた行動データをもとにして、ユーザーにメールやプッシュ通知、LINEのメッセージを配信できるプロダクトです。たとえば、特定のWebサイトで商品ページをクリックしたり、カートに入れたりという行動をした人に対してメッセージを送るといった、パーソナライズができるのが強みです。
全ユーザーに向けて大量にメッセージを送るような施策と比べて、クライアントに大きなメリットがあります。前提として、KARTEで行動データを集めて分析したうえで、条件に当てはまるユーザーにだけメッセージを送るので、配信のコスト単価が安く抑えられます。そして、迷惑メールに登録されるなどのリスクも低下します。エンドユーザーもクライアントも、双方が得をするようにメッセージを送ることができるんです。
さらに、配信の基盤をプレイドが独自で開発しており、高速なメッセージ配信ができるように設計されています。KARTEを導入しているクライアントは1000万規模のユニークユーザーを抱えている企業もあり、そうしたユーザーに向けてなるべく短時間で大量配信を実現できるプロダクトにしています。
採用している技術についても触れると、バックエンドの言語としてはNode.js+TypeScriptとGoを、フロントエンドはVue3+TypeScriptを使っていますが、Vue.jsは徐々にReactへとリプレイスしています。
インフラはGCPで構築しており、サーバーは主にGoogle Kubernetes Engine（GKE）上にホスティングしています。他には、配信結果などのログを集めるためのデータベースとして、BigQueryを使っていますね。また、KARTE Messageではメールの購読停止機能を提供しており、そのシステムはサーバーレスのコンテナ実行環境であるCloud Runで動かしています。
――Kubernetesを採用されている意図があれば伺いたいです。
Webアプリケーションを動かすだけならCloud Runで十分だと思いますが、KARTE Messageでは特定の時間に動き出す配信処理などがたくさんあります。そうした処理で大量のメッセージを配信する場合には多くのサーバーを立ち上げることが必要になりますが、そんなときにKubernetesは便利です。
また、KARTEシリーズのプロダクトでは多数のマイクロサービスを使っています。マイクロサービスのなかにはユーザーの情報やログイン情報を管理するシステムがあり、社内のありとあらゆるアプリケーションからのアクセスが来ています。そうしたシステムがGKEの同じクラスタ内に乗っていることで、プライベートIPで通信できオーバーヘッドが少なくなるため、パフォーマンス向上に寄与しています。
これを、もしCloud Runなどで実現しようと思うと、コールドスタートのオーバーヘッドがあったり、通信が一度外部に出てから再び内部に戻るという経路をたどったりするので、パフォーマンスを良くすることが難しくなります。それから、Kubernetesはシステムの挙動をマニフェストベースで管理でき、性能のチューニングや設定の再利用がしやすいのも優れています。
システム要件で面白いポイントとしては、大量の配信を高速に捌かなければならない一方で、特定の条件に該当するユーザーに対して数通だけしか送らないという少量の配信もあるというように配信パターンの幅が広く、柔軟なスケールが求められることです。また、大量の配信を行う場合でも、「短時間でたくさんのメッセージを送ってほしい」とリクエストされることもあれば「ゆっくり時間をかけてたくさんのメッセージを送ってほしい」というケースもあります。こうした多種多様なユースケースに対応できるように、運用の工夫が凝らされています。
――「ゆっくり時間をかけてたくさんのメッセージを送ってほしい」というのは、どのような理由からなのでしょうか？
仮に、エンドユーザーを1億人抱えている企業がいるとします。それらのユーザーに向けて一斉にメールを送り、みんなが本文中のリンクをクリックしたら、クライアント企業のWebサイトに相当な負荷がかかってしまうんですよ。そこで、あえてゆっくり送ることによって、Webサイトへのアクセスや負荷を適切にコントロールしたいなどの理由です。
――大量のメッセージ配信を行う場合はたくさんのサーバーを用意する必要がありそうですが、コスト最適化のための工夫はありますか？
実はコストについては特別な工夫をしていないですね。というのも、配信が行われる瞬間にKubernetesのPodがバーッと急に立ち上がって、配信が終わればPodが停止するような仕様になっています。だからそれが、自然とコスト最適化につながっています。
――他にも運用の工夫などを教えてください。
先ほど述べたように、KARTE Messageではいろいろな配信パターンのシチュエーションが考えられるため、シミュレーションが容易ではありません。それから、大量配信を実現するために非同期処理workerが立ち上がるようになっていますが、そのときに行われていた他の配信の数や立ち上がったworkerの台数など、さまざまな要因によってworkerの挙動が細かく変わるため、問題を完全には再現できないか、再現できても時間がかかる場合が多いです。状況を可視化するために各種のメトリクスを取ったり、アラートを仕掛けたりという運用技術が求められます。
他にも、KARTE Messageでは「メッセージを深夜に送りたくない」など、クライアントから各種の要望が寄せられます。それらに対応する実装を行いつつ、かつ配信速度が下がらないようにパフォーマンスも大切にしています。
これから、さらに多くの企業に導入してもらうためには機能改善のスピードが要求されます。かつ、そのプロダクトを長期的に安定して運用していくために品質も向上させる必要があります。その両立が難しいところですね。
そしてメールの配信を行っているため、メールに関する専門知識も習得できます。送信ドメイン認証に関することとか、送信元メールサーバーのIPアドレスのレピュテーションを向上させるための取り組みといったノウハウは、こうした環境で働かなければなかなか身に付かないと思います。
――「メールについての専門知識」の部分を、詳しく教えてもらえますか？
メールの送り方や本文のフォーマットについてRFCに定義があるのですが、ルールが非常に膨大なので全てに準拠するだけでも骨の折れる仕事です。また、プロバイダによっては、RFCに準拠していないメールを受け取れてしまうという問題があります。例えば、Eメールの改行コードは"\r\n"を使うという規定がRFC 5322にありますが、実際には"\n"でも問題なく受け取れるプロバイダが多くあります。このように、プロバイダによってバリデーションの厳しさが違っており、場合によってはRFCに記載のない独自のバリデーションが行われているケースもあるため、到達率を上げるためにはマメな監視と経験則が重要になってきます。
それから、メールの世界ではサーバーのIPアドレスに対する信頼度のようなものがあって「このIPアドレスは信頼できる会社のものだからたくさんメールを受け取っていいけれど、このIPアドレスはそうではないから受け取りを制限する」という概念があり、それをレピュテーションといいます。
KARTE Messageではそうした送信元メールサーバーのIPアドレスを大量に持っているんですが、クライアントごとにそれらの割り当てを考えたり、各IPアドレスのレピュテーションを向上させてメールの到達率をより向上させたりといった運用をしています。クライアント企業からすれば、「IPアドレスを育てる作業をKARTE Messageのエンジニアたちが担ってくれる」という安心感はあると思いますね。
――現在注力しているプロジェクトについて教えてください。
LINE関連の開発に一番力を入れています。KARTE Messageでは、以前はメールとプッシュ通知の配信しかできなかったんですが、LINEでの配信ができるように開発を進めています。
KARTE MessageでLINEの配信を行う場合、ユーザーはLINE Messaging APIで利用するメッセージオブジェクトをJSON形式で記述する必要があります。多くのユーザーにとって難易度が高い操作であるため、私たちはLINEのメッセージを組み立てられるGUIのエディタの開発に注力しています。
そして、LINEのメッセージ内のいずれかの箇所をクリックした場合のイベント情報を取得できるように対応を進めています。そのイベントのデータはKARTE Messageのログ基盤に格納され、その情報をもとに次の施策に活用されています。
誰もが活躍できる組織へ
――今後はどのような体制にしていきたいですか？
私個人としては、KARTE Messageはまだまだ開発環境が整備されていないと感じています。新しい人が入ってきたとしても、スムーズに開発に取りかかれない事態が起き得るはずです。これからは、エンジニアが参画したらすぐ開発に着手してアウトプットを出せるような環境にしていきたいです。
たとえば、私はKARTE Messageの配信基盤のオーナーなんですが、もともと配信基盤はTypeScriptで書かれており、ロジックが分散して凝集度が低い状態になっていました。何年もシステムを見ている私でも、直すのが大変な状態だったんです。そこで、重要なロジックに関してはAPI化して、かつ言語をGoに置き換える作業を進めています。
かつてこの配信基盤では、配信を開始するためにはデータベースにデータを投入する必要があるという、運用しづらい設計になっていました。API化することによって、運用が楽になり、システム単体で検証しやすくなります。加えて、将来的にKARTE Messageの開発チーム以外にAPIを提供するのも容易になります。
Goを選んだ理由としては、もちろん言語として優れているのもありますし、インターン生に「Goを書きたい」という人が多いんですよね。彼らが活躍して、事業成長に貢献できる場所を提供したいという思いからGoを採用しました。そして書き換えに伴って、分散しているロジックをしっかりと1ヶ所に集約して、かつ自動テストをたくさん書いて壊れにくくしています。
KARTE Message全体でこうした流れを踏襲し、開発環境を積極的に整え、リアーキテクチャや技術的負債解消を進め、ドキュメントも整備して、インターン生のような若いメンバーもより活躍しやすい環境にしていきたいです。
――若いメンバーには、どのようなエンジニアに成長してほしいですか？
やはり人を育てられる人になってほしいですね。私自身、インターン生と接するときには技術の細かい話よりも、私の根底にある人や組織についての考え方を伝えるようにしています。そして、「みんなが活躍できる組織を作っていく」という思いに共感してくれるメンバーを集めています。プレイドが今後さらに成長するためにも、人を育てられる人が増えるのは重要ですね。
――最後にKARTE Message開発の今後の意気込みをお願いします。
KARTE Messageは立ち上げを終え、これからクライアント数もユーザー数も急激に増えていくフェーズです。1ヶ月前と比較して、2倍ほどの配信数になるケースもあるほどです。
だからこそ、難易度が高くて、かつ面白い課題がたくさん出てきます。課題解決や目標を達成するためには、色々な手段やアプローチがあると思いますが、個人的には、色々なことができるスキルの高い人に業務を属人化させるのではなく、様々な専門性を持つより多くのメンバーとコラボレーションしてプロジェクトを前に進められるようにしていきたいですね。
また、KARTE Messageは顧客体験の良し悪しを実感しやすいタッチポイントの一つなので、今後もマルチチャネル化を進めることで顧客体験においてより大きいインパクトを出すことがチームの目標です。今はそれに向けたチームビルディングを進めている最中なので、この記事で興味を持った方はぜひ応募してほしいです（笑）。