2025-01-23

Zoom Phone APIを活用した業務改善の反省点と学び

支払い.com 開発

UPSIDERでエンジニアをしている太田です。 (@Hide55832241)

私たちのチームでは、CS業務などにZoom Phoneを活用しています。
今回はZoom Phoneを用いた業務改善の取り組みについて、経験した反省とそこから得た学びを共有します。

前提

Zoom Phone

Zoom Phoneとは、オンライン会議ツール「Zoom」に組み込まれたクラウド電話サービスです。電話番号を利用した発着信が可能で、多彩な機能を提供し企業の電話業務を効率化します。

www.zoom.com

コールキュー

Zoom Phoneの機能のひとつで、着信をユーザーグループにルーティングできます。
たとえば、問い合わせ受付用のコールキューに割り当てられた電話番号に着信があった場合、コールキューに所属する複数のメンバーに同時に転送されます。
その中で都合の良い任意のメンバーが応答できるため、顧客を待たせる時間を短縮し迅速に対応することができます。
主な特徴は以下の通りです。

電話番号割り当て: コールキューには電話番号が割り当てられる
複数メンバーの所属: コールキューには複数のメンバーを登録可能
転送ルール: 着信時に所属メンバーへの転送ルールを設定できる
- 応答できなかったら次のメンバーへ着電、メンバー全員に同時に着電など選択可能

課題

私たちのチームでは、CS業務を複数のメンバーで分担しています。
しかし、状況によっては誰も電話に応答できず不在着信が発生する場合があります。
この不在着信が発生した際に以下の点が課題として見えてきました。

不在着信をメンバー間で共有しづらい
不在着信を取りこぼすことがある
不在着信に対する折り返しが複数メンバーで重複してしまう

これらの課題を解決するため、不在着信の通知をSlackで共有できないかと考えました。

プロトタイプ作成

Zoom Phoneを知らなかったこと、Zoom Phoneに関する開発知見がなかったことから、まずは実現可能性を確認する必要がありました。
不在着信イベントをSlack通知する事例の記事を見つけたため、同様の設計で実装を試みました。
また以下の検証を行い、すべて問題なく実行できたため技術的な課題はクリアできたと判断しました。

Zoom App Marketplaceでアプリケーションの作成
Zoom Appからリクエストを受けるためのアプリケーションの作成
Zoom Appの認証
Webhookイベントの取得
Slack通知

これらを踏まえ、不在着信イベントを受け取りSlack通知を行うプロトタイプを実装し、運用を開始する準備を進めました。

プロトタイプでの運用を始めてみたら、思わぬ誤算が浮き彫りになりました。
以下に具体的な内容を紹介します。

誤算1: Zoomアカウントの権限問題

開発者のZoomアカウントに管理者権限を付与して開発を進めましたが、運用段階で管理者権限を外した結果、作成したアプリケーションが使用できなくなりました。
管理者権限はZoom組織の重要な操作を実行できるため、開発者へ管理者権限を付与することはリスクが高まります。
他のクラウドサービスなどと同様に、最低限の権限のみを付与する必要がありました。

問題解決の試み

1. 開発者権限の付与

社内で開発者権限を申請しましたが、Zoom APIを利用した経験がないため手続きに時間がかかりました。

2. アプリの譲渡

アプリを管理者に譲渡しようとしましたが、ドキュメント記載の Transfer App Owner が利用できませんでした。（記載されているTransfer App Ownerというボタンが表示されない）
アプリの種類により譲渡に制限がある可能性があります。

3. 管理者によるアプリ作成の依頼

管理者にアプリを作成してもらう案も検討しましたが、管理者が運用に直接関与しないため最適解ではありませんでした。

解決方法

結果的に時間は要しましたが、開発者権限を付与して問題を解決しました。

反省点

適切な権限を付与して開発を始められたらよかったかもしれません。
Zoom APIを使用した開発の知見がなく様々な検証をする必要があったため、それがはじめからできたかはわかりませんが、すべて実装する前に権限の問題も解消しておくべきだったと思います。
実装完了した後に権限の問題で運用が開始できなくなったら意味がありません。
この問題の解決に1週間以上かかったので、当初考えていた期間内に運用を開始することはできなくなりました。

誤算2: 応答したのに不在着信のWebhookリクエストが発生している

運用開始後、応答したにもかかわらずSlackに不在着信通知が送信される問題が発生しました。
また、1着信に対して複数回の不在着信通知が送信されることがありました。

問題の原因

不在着信のWebhookリクエストは phone.callee_missed というイベントで受信します。

developers.zoom.us

このイベントはCSチームが応答前にカスタマーが電話を切った際に発生することを想定していました。
しかしこのイベントが応答した際にも発生していることや、1着信に対して複数回発生していることがわかりました。
調査をすすめるとコールキュー内のメンバーに対してそれぞれイベントが発生していることがわかりました。
具体的には以下です。

カスタマーが電話をかける
メンバーAへ着電
メンバーAが出られなかった → イベント発生
メンバーBへ着電
メンバーBが出られなかった → イベント発生
メンバーCへ着電
メンバーCが応答

解決方法

リクエストのパラメータ handup_result を使用して判定できました。 (これも後で大きな問題になりますが)
handup_resultは以下のように定義されています

handup_result string
The reason the call was missed. Values: No Answer | Busy | Call Cancel

handup_result には No Answer Busy Call Cancel のいずれかが入ります。
Call Cancel は応答前にカスタマーが電話を切った場合、それ以外はコールキュー内の次のメンバーへ着信が移った場合に発生することがわかりました。

応答した場合、イベントは以下のような順で発生し handup_result: Call Cancel イベントは発生しません
- メンバーAが不在 (handup_result: Busy または Answer イベントが発生)
- メンバーBが応答 (イベントは発生しない)
応答しなかった場合、イベントは以下のような順で発生し handup_result:Call Cancel イベントが発生します
- メンバーAが不在 (handup_result: Busy または Answer のイベントが発生)
- カスタマーが電話を切った (handup_result: Call Cancel イベントが発生)

このことから handup_result: Call Cancel が発生した場合のみSlackへ通知すれば解決できそうだと考えました。

反省点

実運用環境での検証不足
不在着信の動作確認をWebhookリクエストでしか行っていませんでした。
CSチームが普段使用している環境と同じまたは似たものを作成しておけば運用開始前に把握することができました。

誤算3: `Call Cancel` が発生していないけど実際には不在着信

誤算2の解決方法に handup_result から判定できると書きました。
しかし Call Cancel が発生していない (Slack通知されない) けど実際には不在着信となっているケースがありました。
理由はわかりませんが、Webhookリクエストと実際の不在着信がずれているのは事実です。

解決方法

1つのWebhookリクエストで通知判定が行えないので頭を悩ませました。
システムが複雑になってしまいますが以下のようにスケジュール通知を行うことにしました。

phone.callee_missed リクエストが発生した場合、Call Cancel だったらSlack通知する
Call Cancel 以外の場合、保存しておいてスケジュール通知する
- 今回はWebhookリクエストを受けるアプリケーションにCloudflare Workersを使用していたため、ストレージはCloudflare Workers KVを使用した
phone.callee_answered イベント (電話応答した際にリクエストされる) も取得するようにする
同一のCall ID (着信ごとに一意の値。1つの着信に対するイベントはすべて同一のCall IDとなる。) を持つイベントが発生した場合は、保存済みのリクエストを削除する
5分毎にスケジュールイベントを実行し、ストレージにイベントが残っていたら通知して削除する (直近登録されたイベントはまだ後続イベントが発生するかもしれないので対象外)
- スケジュールイベントはCloudflare WorkersのCron Triggersを使用した

当初考えていたものに対して複雑な設計になってしまいました。
また Call Cancel が発生しないリクエストはリアルタイム通知できなくなってしまいましたが、なんとかSlack通知が実現できそうな目処が立ちました。

反省点

誤算2と同様、実運用環境で動作検証をしていれば事前に気づけました。

誤算4: 応答したけど `phone.callee_answered` が発生していない

誤算3同様、応答したにもかかわらず phone.callee_answered が発生しないケースがあることがわかりました。
こちらも原因がわかりません。
後述しますが、コールキューの転送ルールの設定を途中で変えたことなどが影響していたかもしれません。

解決方法

ここで開発を仕切り直すことになります。
phone.callee_missed イベントを受け取ってSlack通知をすることを考えていましたが、他のイベントを使えないか検討することにしました。
ドキュメントを参照また動作確認していくと phone.callee_call_history_completed とphone.callee_call_log_completed が使えそうということがわかりました。
どちらでも問題なさそうだったので今回は phone.callee_call_log_completed を使うことにしました。

反省点

誤算2と同様、実運用環境での事前検証が不足していた
- phone.callee_answered イベントが発生していないけど、応答済みということは環境を整えていれば把握できました。
初期に検討した phone.callee_missed イベントを使用することに固執し、複雑な設計をおこなったこと
- スケジュール通知の設計をした際にphone.callee_missed 以外のイベントを確認しませんでした。
- なんとかしないといけない焦り、当初参考にした記事といかにも不在着信っぽいイベント名に囚われてしまったと感じています。

最終的な設計

コールキュー内の特定のメンバー以外へのイベントは無視する
Webhookリクエストで phone.callee_call_log_completed イベントを受け取る
- このイベントは通話が終了した際にコールキュー内の全メンバーに対してリクエストされるため、すべて対象とすると1不在着信に対してメンバー数分Slack通知されてしまいます
リクエストパラメータの result が Call Connected (応答した) または Answered by Other Member (他のメンバーが応答した) 以外の場合、Slack通知する

最終的にとてもシンプルな設計になりました。

あとがき

今回の開発は反省点が多いものとなりましたが、学びも多いものとなりました。
最終的な設計はシンプルになりましたが、まだここにもいくつか課題があります。
コールキューの転送ルールの設定を 同時 にしていないとSlack通知が動きません。
これに関しても反省点です。
開発当初転送ルールの設定はメンバー1 → メンバー2 というように順番につながる設定となっていると聞いていました。
しかし運用していくと不在着信が発生しやすかったため、途中で全メンバーへ同時に着信するよう変更したと開発途中で聞きました。
この設定によりWebhookリクエストのふるまいが変わったため、開発者と運用者のコミュニケーションが必要であったと感じています。
また特定のメンバーに対して常にWebhookイベントが発生する設定にしておく必要があります。
Zoom Phoneはコールキューのメンバーであってもコールキューの着信を受け付けない設定にできます。
実際に他の業務を行っている際は、コールキューを受け付けない設定に変更しているメンバーがいました。
これに関して今回は開発者のZoomアカウントをコールキューに追加し、常時コールキューを受け付ける設定とし解決しました。
しかし前述の転送ルールの設定を変更した場合、この運用は使えません。
このようにまだ課題はありますが、少しずつ電話業務の改善を続けていければと考えています。

We Are Hiring !!

支払い.comをはじめUPSIDERでは現在積極採用をしています。ぜひお気軽にご応募ください。

herp.careers

カジュアル面談はこちら！

herp.careers

Culture Deckはこちら📣

speakerdeck.com

2025-01-15

データ分析からリリースまで丸ごと担う――自給自足するモバイルチームを目指すエンジニアリングマネージャーの挑戦

Mobile 組織

こんにちは！HRのmahoです。今回はMobile App TeamでEM(エンジニアリングマネージャー)として活躍するTanakaさんにUPSIDERでのこれまでの挑戦やUPSIDERならではのモバイル開発について取材しました！

社会意義の大きさとグローバル視点に惹かれUPSIDERに入社
モバイル×バックエンド×データ分析を完結させる“自給自足”チーム
新規事業でのチャレンジと既存アプリとの相乗効果
「挑戦を歓迎するカルチャーが根付いている」エンジニアとしての裁量とUPSIDERの組織風土
We’re Hiring 〜UPSIDERのMobile App Teamで新たな挑戦を〜

社会意義の大きさとグローバル視点に惹かれUPSIDERに入社

Maho: 今日はよろしくお願いします！まずは自己紹介をお願いします。

Tanaka: UPSIDERのMobile App TeamでEMを務めているTanakaと申します。2023年3月に入社し、既存サービスである法人カード「UPSIDER」のモバイルアプリと、新規事業のアプリ開発を担当しています。エンジニアとして実装を担う一方、チームのマネジメントにも携わっています。

Maho: もともとFintech分野に関心があったと伺いましたが、UPSIDERへ入社した背景を詳しく教えていただけますか？

Tanaka: 以前から「お金を扱うサービスに携わりたい」という想いが強く、過去にもFintech企業で働いた経験があります。そこから別のスタートアップへ転職し、Flutterなどの新しい技術スタックに挑戦していました。その後、自分のキャリアを改めて考えていたときに、声をかけてもらったのがUPSIDERでした。スタートアップの財務面を支えるプロダクトは、社会的意義が非常に大きいと感じましたし、グローバル志向を掲げるUPSIDERの企業姿勢にも魅力を感じました。OSS活動を積極的に行う文化や、会社のミッション・組織への強い共感があったのも入社の大きな理由です。

Maho: 社会的意義の大きさやグローバル視点は、UPSIDERならではですよね。実際に入社してからの印象はいかがでしょうか？

Tanaka: 入社当初はまず、モバイルアプリのコードベースを理解するところから始めました。アプリはFlutterで書かれており、自分自身も経験があったため、すぐに馴染むことができました。入社後すぐにAndroid版のリリースに向けた作業に取り掛かったのですが、その過程で強く感じたのは、「自分が思った以上に、開発の裁量が大きい」ということです。もともと金融機関ならではの厳密な運用ルールが多いと想像していたのですが、むしろ提案はどんどん歓迎される風土だったのは嬉しいギャップでした。

モバイル×バックエンド×データ分析を完結させる“自給自足”チーム

Maho: 具体的に、Mobile App Teamの役割と体制について教えてください。

Tanaka: 一般的には、モバイルエンジニアはあくまでアプリ部分に注力し、バックエンドやデータ分析は別部署が担当するケースが多いと思います。ですがUPSIDERでは、アプリ開発だけでなくアプリ開発に関連するバックエンド実装・デプロイ、さらにGoogle AnalyticsやRedashを使ったデータ分析まですべて一貫して行います。たとえばKPIの測定やイベント設計、ダッシュボード構築まで自分たちで責任を持ち、アプリ改善につなげます。このスタイルを私は“自給自足”と呼んでいます。

Maho: それだけ幅広い工程を担うからこそ、やりがいも大きそうですね。

Tanaka: そうですね。私自身、データ分析をメインで担当する機会はこれまで多くはありませんでした。しかし、実際にやってみると面白さに気づくことばかりで、「こういうデータを取ってみよう」「この数字がこう変わったら、こういう仮説が成り立つよね」といった形で、プロダクトの改善にダイレクトに関われる手応えがあります。さらに、GoやKubernetesを用いたバックエンドの運用も含めて扱うため、技術的なスキルセットを広げられる点もモチベーションになっています。

Maho: チームで自給自足をしているとのことですが、他部署とのコミュニケーションはどういった形で行われているのでしょうか？

Tanaka: ここまでの話で「孤立しているチーム」というイメージを抱かれるかもしれませんが、実際には常に他チームと連携しながら進めています。 たとえば新機能を導入する際は、PdM(プロダクトマネージャー)やデザイナー、セールス担当などともレビューやフィードバックを重ねます。データをどう見るかという観点でも、アナリストチームや他のエンジニアと積極的にコミュニケーションを取っています。おかげで、視点が偏ることなくリリースまでの意思決定をスピーディーに行えています。

新規事業でのチャレンジと既存アプリとの相乗効果

Maho: 最近は、新規事業のアプリ開発に注力されていると伺いました。これはどのような経緯で着手されたのでしょう？

Tanaka: 最初は既存サービスである「UPSIDER」のモバイル領域に集中していました。しかし、会社として「新規事業をより早く世に出そう」という方針が固まり、そこでモバイルアプリをどう作るかが大きなテーマになりました。チームとしては、既存アプリの基盤やバックエンドの資産を活用できる部分をしっかり使いつつ、まったく新しいUXを設計したいという強い思いがありました。既存資産の活用と新しい挑戦を両立させるため、複数のプロジェクトが同時進行しながら高度な判断が求められる状況で進めています。

Maho: 実際に新規アプリをゼロから作るうえで、苦労した点や面白かった点はありますか？

Tanaka: まず、「リリースをとにかく早くしたい」というモチベーションが強かったので、既存の基盤をうまく活かす必要がありました。とはいえ、機能のすべてをそのまま流用するのではなく、UIやユーザー体験は再検討が必要です。既存の基盤を引き継ぎながらも、新しい体験をどう実装するかに知恵を絞ることで、アプリ設計の引き出しが増えましたね。また、その過程で得た知見をUPSIDERのアプリに活かすことができるのも面白いところです。

Maho: 新規事業のノウハウが既存サービスにも還元されるわけですね。

Tanaka: そうなんです。「既存アプリから得られたアイデアを新規事業へ」「新規事業のUI/UXを既存アプリへ」という形で、互いの強みを取り入れることができます。スタートアップらしく柔軟でスピーディーな開発文化があるからこそ、この“行ったり来たり”がスムーズに進められているんですよね。「学んだことを次につなげる流れがとてもスムーズ」というのが、UPSIDERの強みの一つでしょうね。

「挑戦を歓迎するカルチャーが根付いている」エンジニアとしての裁量とUPSIDERの組織風土

Maho: チーム内での意思決定の速さや裁量の広さが、UPSIDERの魅力としてよく挙げられますが、改めて感じているポイントはありますか？

Tanaka: 一番大きいのは、「提案からリリースまでを一貫して担える」という点ですね。特にMobile App Teamの場合、データドリブンな改善案を自分たちで出して、自分たちで実装まで落とし込み、モニタリングできる仕組みが整っています。他社であれば「データ分析は別部署がやる」「バックエンドには他チームが携わる」などで調整コストがかかりがちですが、UPSIDERではエンジニアが全体を俯瞰して動けるので、アイデアが形になるまでがとても早いんです。

Maho: スタートアップならではのスピード感をさらに加速させる組織だと言えそうです。

Tanaka: そうですね。UPSIDERのミッションである「挑戦者を支える世界的な金融プラットフォームを創る」という考え方が根底にあるので、社内での挑戦を歓迎するカルチャーがしっかり根付いています。新しいサービスや機能が生まれる際も、まずは「どうやったらスピーディーにリリースできるか」を議論しますし、エンジニアリングチーム同士で技術的な知恵を出し合う体制ができています。結果として、お客様にとって価値のあるサービスをより早く提供できるわけです。

We’re Hiring 〜UPSIDERのMobile App Teamで新たな挑戦を〜

Maho: 今後、Tanakaさんご自身はどんな挑戦をしたいですか？

Tanaka: 個人的には、今後もMobile App TeamのEMとしてチームビルディングに力を注ぎつつ、アプリとバックエンド、そしてデータ分析の三つの観点をさらに磨いていきたいと思っています。また、新規事業で得たUXの知見や最新技術を既存の「UPSIDER」のモバイルアプリにどんどん導入して、両サービスを高め合う好循環を作りたいです。

Maho: 最後にUPSIDERに興味を持っていただいている方へメッセージをお願いします。

Tanaka: Mobile App Teamでは一緒に働く仲間を募集しています。Flutterの経験がなくても、Android/iOS アプリ開発経験があれば応募大歓迎です。もちろんFlutterに触れたことがある方は、さらにスキルを深められると思います。UPSIDERのMobile App Teamは、提案からリリースまでの一連の流れに携われるうえ、実際にバックエンドやデータ分析にも関われるので、「エンジニアとして成長したい」「責任ある立場で挑戦したい」という方にはピッタリでしょう。

何より、リモート中心でも積極的にコミュニケーションをとる文化があるので、「とりあえず話してみよう」「疑問を感じたら即相談」といったフットワークの軽さで前へ進める雰囲気があります。

挑戦を面白がってくれる方や、自分の専門を生かしつつ新しいスキルも身につけたい方には、最高の環境です。私たちと一緒に、新しいサービスを作り上げながら、どんどん世界にチャレンジしていきましょう。カジュアル面談でお話しできるのを楽しみにしています！

herp.careers

speakerdeck.com

2025-01-07

UPSIDERのアプリケーションを支える、高セキュリティ・高可用・高スケーラブルなプラットフォーム #CNDW2024 イベントレポート

組織開発

こんにちは！UPSIDERでHRをしていますNarisaです。 VP of Engineering 泉が『CloudNative Days Winter 2024』に登壇しましたので、イベントレポートをまとめます！

CloudNative Daysとは

CloudNative Daysは、クラウドネイティブ技術に関心を持つ開発者を対象としたカンファレンスです。毎年、シーズンやエリアを変えて、複数回にわたり開催されることで、最新技術の共有やコミュニティの活性化を目的としています。

本イベントは「クラウドネイティブ技術の普及と活用促進」をテーマに掲げ、Kubernetes、マイクロサービス、DevOps、Observabilityなど、クラウドネイティブに関連する多様なトピックが取り上げられます。

基調講演や技術セッションに加え、実務的なハンズオンやネットワーキングの機会も用意されており、参加者が実践的な知識を深められる場となっています。

UPSIDERのアプリケーションを支える、高セキュリティ・高可用・高スケーラブルなプラットフォーム

『CloudNative Days Winter 2024』（以下CNDW2024）のテーマは、”小さな一歩、大きな飛躍〜クラウドネイティブを継続する〜” でした。

”小さな一歩、大きな飛躍〜クラウドネイティブを継続する〜” とは

クラウドネイティブをこれから始める人、今まさに取り組んでいる人、一定の成果を達成して次のステップに迷っている人、CloudNative Daysには様々な人が集まります。

エンジニアも組織も、そしてシステムもクラウドネイティブから実りを得るには、一度きりではなく、学びと改善を何度も繰り返す継続的な取り組みが重要です。

小さな一歩を踏み出すのをためらわないでください。小さくても歩みを止めないでください。

継続することをやめなければ、変化と経験の蓄積がやがて大きな飛躍をもたらします。そしてコミュニティが知見とモチベーションの交換を通してあなたの一歩を後押しします。

CloudNative Daysは、クラウドネイティブへの小さな一歩を踏み出し、大きな飛躍へと前進するエンジニアと共に歩んでいきます。

出典：イベント当日スライドより引用

CNDW2024は2日間にわたり、TrackA〜Dと4つのエリアで登壇が披露されていました。イベントブースも多く出展し、懇親会やLTイベントも開催されるなど、とても盛り上がっていました！

2日間の様子がまとめられていますので、ぜひこちらをご覧ください。 https://togetter.com/li/2471982 https://togetter.com/li/2471983

UPSIDERが登壇した際のまとめは以下にまとめていただいています。 https://togetter.com/li/2471984?page=6#h135_0

CNDW2024のテーマをもとに、UPSIDERのVPoE泉は「UPSIDERのアプリケーションを支える、高セキュリティ・高可用・高スケーラブルなプラットフォーム」をテーマに登壇しました。

speakerdeck.com

登壇した資料を掲載しつつ、当日に口頭でお話しした内容の一部をご紹介します。

What’s Happening in Financial Systems around the world!?

泉：他領域に比べると「金融」って「地味な領域」「堅い領域」と思われがちですが、実際、主に台帳管理に使われる「メインフレーム」と呼ばれる基幹システムはカスタムのプロセサーを利用した基盤に独自のSystem/360や、zSystemと呼ばれるOSを搭載して、COBOLをベースにアプリケーションが書かれるようなアーキテクチャーが主流です。いまも多くの銀行やカード会社など、いわゆる「取引台帳」を業務の中心に置く会社ではまだぜんぜん現役のシステムです。

泉：なぜこれらのシステムが現役のシステムなのかというと、金融において最も重要な情報資産は「残高」と「取引履歴」です。これらは絶対に破損できないデータです。その正確性が絶対担保されないと、金融システムそのものが破綻します。（入金したのに残高が変わらなかったら、その瞬間に信用なくなりますよね？）

（特筆するまででもないですが）金融取引は、シンプルにいうと取引のINSERTと、残高のUPDATEを常にアトミックな処理で行う必要があります。

泉：例えばクレジットカードだと、100万円の与信がある会社が、20万円の決済をおこなったとします。すると20万のINSERTをするとともに、Balanceである100万を80万にするというアップデート処理を必ず一つの切り離せない処理にする必要があります。

泉：エンジニアの皆さんは多分「あーなんだ、そんなのTransactionをしかけりゃいいだけの話じゃないか」と思うかもしれませんが、それは今の話しで、昔はハードウェアの故障や磁気ストレージの外界からの電磁波からの影響、あるいは電源さえ不安定な時代なので、その背景を考えるとこの処理を確実に、しかも大規模に行う、ということが如何に大変だったか、少しご理解いただけるのではないかと思います。

メインフレームの筐体自体が日本においては、免震フロアに設置されないといけない、とか含めとんでもなく大変なことでした。（この対策が当時の強固な安全性を担保したシステムの実現であり、この構造を作った先人たちをリスペクトしています！）

泉：一方でこの10年くらいで、海外でもBREXやRampなど、スタートアップ企業がOSSやクラウドネイティブなテクノロジーを駆使して、独自に決済システムを作っています。ブラジルのNubankはカードではないですが銀行システムを基本Cloud-Native Technologyで実現しており、Clojureでマイクロサービスを作ったり、パーシステンスにはDatomicやCockroachDB等を利用して非常にResilientでスケーラブルなアーキテクチャーを実現しています。

しかもこれがメインフレームの初期導入コストに比べると100分の1とはいかないものの、10分の1くらいのコストで実現できていることは非常にすごいことです。

このように金融領域にもかなりCloud Native Technologyが広がっている、ということを頭の片隅において、UPSIDERが実際どういう仕組みを作っているのかをご紹介したいと思います。

金融システムに求められるScalability, Security, Resiliencyの実体

泉：システムの全体像からご紹介します。これでもまだシンプルにしたのですが、少し細かいですね。

まずUPSIDERのシステムは主に大きく２つの機能がある、と見ていただければ良いかなと思います。

一つは、「決済領域」で加盟店からVISAのネットワークを経由して入ってくる決済電文の処理を行う領域と、「管理業務領域」でカードの発行や失効、あるいは会員情報や請求回収などのカードにまつわる情報や取引の管理を行う領域が別々に分かれています。

参考：プロダクトの性質から考えるシステムと組織のアーキテクチャー

それぞれThemisとChronosと呼んでいますが、決済領域をThemis、管理領域をChronosと呼んでおります。今、Node数でいうと130、Workloadの数でいうと現在500近い規模のマイクロサービスアーキテクチャになっております。

泉：例えば交際費の支払いで飲食店でカード決済をするとします。するとその瞬間、加盟店の端末からVISAのネットワークを通じて、最終的にUPSIDERのGCP上のネットワークにメッセージが入ってきます。いわゆる「オーソリ」と呼ばれる電文です。その処理を行うのがこのThemisという決済領域になります。

文字にするとシンプルに見えますが、このオーソリ電文を受け取ると、我々のシステムの中でまず電文のカテゴリーを調べ、どのコンポーネントにその処理を任せればよいか、という分岐が行われます。

その後、

カード番号が有効なものであるのか？
これから行う決済は利用可能額の範囲に収まるのか？
カード自体の不正利用ではないのか？*1

の確認を行なったあとにVISAにこの決済はOK、この決済はNG、というレスポンスを返す仕組みになっています。

これ以外にもオンライン取引であれば不正利用対策でもある、3DセキュアのプロンプトをSlackやアプリ通知、メール等で行ったりすることもあります。

これ以外にも、最も重要な部分の一つですが、「利用可能残高から決済金額分を引く」といった作業も行います。

これらの一連の処理はまさにこの図にあるようなマイクロサービスが連鎖して最終的な決済の処理を行い、ピーク時では一日約10万件以上の決済を処理しております。

例えばこれがマイクロサービスではなく、すべての処理がモノリシックになってしまうと、一つの変更ですべてが動かなくなってしまう可能性もあります。あるいはボトルネックがある一部に集中しているだけなのに、すべてをスケールアップさせないといけなかったりします。

なので、この決済の仕組みをマイクロサービス化して分割し、必要な場所だけReplicaを作って増殖させていくことで、ホリゾンタルスケーリングを可能にします。新しい機能をリリースする際は、全体の一部だけアップデートし、決済トラフィックの一部をルーティングして、問題ないことを確認しながらリリースするといった、Canaryリリース的なことが可能になっています。

泉：これらのシステムの分離は、基本的にはクラスター単位の分離であり、GCPのプロジェクトレベルでも分離しています。その背景としては、クレジットカード業界には「PCI-DSS」という割と有名な情報セキュリティスタンダードが存在します。

基本的にカードの発行を行う信販会社も取引を扱うマーチャントも、VISA自体も、クレジットカードの番号やPIN番号、CVV等を扱う業種はほぼすべからくPCI-DSSの認証を受けないと業務ができません。

PCI-DSSは、約250件くらいのセキュリティ要件に加えて、細則が400件近くあります。いわゆるISMSのような、自分たちでセルフガバナンス（つまり規律を自分たちで作って自分たちで守る）といったセキュリティマネジメントシステムではなく、厳密にこのようにシステムを実装しなさい、といった細則があります。

例えば「この種のデータは、データベース丸ごと暗号化するのではなく行レベルで暗号化しないといけませんよ」といったイメージです。

他にも内部ペネトレーションテストや、外部脆弱性試験などの要件などもあります。

これらの要件が、管理領域のシステムも含めて、システム全体に適用されてしまうと、そのセキュリティ要件を満たすのにかなり苦労することになります。

そのため、実際のカード番号を扱うような領域とカード情報が不要な領域を分けることによって、PCI-DSSの監査対象になるシステム領域をぐっと小さくしてその中で対応しております。

実際これをやることで、８チームある開発チームのうち、５チームくらいはPCI-DSSの要件を気にせずに開発ができる、というメリットがあります。

なので確かに１つのクラスターを用意すれば、全部カバーできるという考え方もありますが、あえてマルチクラスター化することによって利用者の情報をより強固に守ることが可能です。

泉：次にScalabilityの話を少ししたいと思います

ちょうど先週水曜日に154億円の調達のプレスリリースが出ましたが、事業の立ち上がりからここまで、利用者や取引数はどんどん増加傾向にあります。とりわけDay 1を1とすると約1000倍くらいには成長しています。このようなScalingを可能にしているのはまさにこCloud Native Technologyが理由です。

GoogleのシステムアーキテクトのJeff Deanさんが「10倍、 20倍は予測してデザインするべき。しかし、ほとんどの場合そのアーキテクチャでは100倍には適さない」と言ってますが、つまり100倍になったらアーキテクチャは見直さないといけません。

UPSIDERはこれまで1000倍の成長をしていますが、ベースのアーキテクチャは変わっていません。（まさに今回のテーマ「小さな一歩から大きな飛躍」！）

もちろん、自前でEC2みたいなComputingリソースを構築して、そこからスケールアップのたびにインスタンスを増やして、LBとかの設定などをやりくりしながら、しかもアプリケーションもどんどん拡大していく…を行なっていたら Jeff Dean さんの予想通りに「これもう無理や」となり、1年くらい新規開発を止めてリアーキテクチャをしないといけない状況が起こり得る可能性はあると思います。

「金融は堅い！」というイメージをお持ちの方もいらっしゃると思いますが、「僕らが愛して止まないOSSだけで、ここまで事業が作れる」あるいは「堅そうな金融もCloud Native Technologyでどんどん生まれ変われる」という印象を持っていただけたのではないかと思っております。

泉：というところで、ここまでが、KeyNoteのメインの話しでCloud Native Technologyの持つ、Scalability、Security, Resiliencyという特性が、如何に我々の事業で生きているかという美しい話をさせていただきましたが、

もちろん、まぁまぁ厄介なこともあるので、ここからはもう赤裸々に我々まだまだ課題だらけの現状をお話しできれば、と思います。

泉：まずひとつは、これだけの事業成長を伴って発生するスケーラビリティに関する課題です。

他社の事例はわからないのですが、当社の決済領域では季節性の波がでてきています。特に某社のスマートフォン発売のタイミングになると予約が受付開始になったタイミングで注文が一気に決済されて、洪水のようにリクエストが押し寄せてくるといったことが起きております。

このようなスパイクによって我々の決済システムが予期せぬトラフィックに耐えられず、一部データベースのTransactionのロックが開放するのをまったりして、タイムアウトを起こすという事象が発生したこともありました。

このようなことが行われると何が起きるかというと、突然決済が通らなくなるわけではなく、VISAのStand-In-Process、通称STIPと呼ばれる仕組みが作動して、これまでの決済の可否の実績をもとに機械学習ベースのシステムが、決済を通すか通さないかを判断する仕組みを発動してくれます。それ自体は非常にありがたい仕組みなのですが、いかんせんさっき説明した様々な細かい制限設定が無視される可能性が出てきてしまうので、不正利用の取引が混じっても弾くことができず、結果お客様の迷惑になってしまいます。

なのでここはKubernetesのHPAの設定をチューニングして、特に繁忙期のタイミングではより瞬時にスケールできるようにPodのスケーリングポリシーを見直したり、瞬時に増加するリクエストに対応できるようにしております。

あと、単純にPodを増やすだけでは不十分で、背後にあるデータベースのボトルネックなども解消する必要があり、そもそもSpannerのロック待ちみたいなこともあり得るので、ロックがおきる前に書き込みの処理を非同期にするなど、そのような対応もアプリケーションレベルで対応する必要があるので、すべてがホリゾンタルスケーリングで解消できるわけでもない、というのが現状です。

これ以外にもローカルで開発したものをCluster上でテストしたいとかでmirrordを使ってみたかったり、Prometheus辞めてOpenTelemetryに寄せるのにGrafana Alloy使ったり、いろいろアジェンダは山の様にあります。

CloudNative Technologyの恩恵

泉：今日のまとめですが、やはりCloud Native Technologyは、事業をスケールさせるためのテクノロジーとして作られたものですが「金融」という領域にもめちゃくちゃ滲み出てきており、今後どんどんこの領域でも活躍していくことが予想されます。

ライトなウェブアプリケーションを構築したいだけならCloudRunとかを使ってサーバーレスにやるほうが圧倒的に早いしコストも抑えられます。

が、今日話したような基幹システム、とくにミッションクリティカルな領域においてこそ、CloudNative Technologyの良さが生きると思っており、まさに冒頭話した数百億したシステムがオープンソースでここまで作れるようになったことは本当に時代の恩恵だし、これが回り回ってより利用者が安全・安心して使える経済インフラに発展することができたことは、本当にコミュニティによる貢献から成り立っているとしみじみ思っているので、皆さんへの感謝とともに本Keynoteを締めたいと思います。

We’re Hiring !

株式会社UPSIDERは絶賛採用中です！ Platform team でのSREポジションや、Backend Engineerの開発ポジションなど幅広く募集中です！応募前には泉によるカジュアル面談も実施可能ですので、ご希望の方は以下よりお申し込みください！

herp.careers

この度は貴重な機会をいただきまして、ありがとうございました！！！

UPSIDER Engineering Deckはこちら📣 speakerdeck.com

*1:*不正利用防止のための制御として、利用限度額や加盟店、決済通貨の制限を設定することができるので、一連のチェックを行う

2024-12-27

Empowering Finance with AI: How OCR Refinement and AI Integration Revolutionize User Experience #UPSIDER年末リレーブログ2024 [日本語訳有]

技術 AI

※日本語は下部に記載しています。

UPSIDER is transforming how companies manage their finances with its corporate card and integrated financial platform. From credit limits of up to 10 billion yen to streamlined accounting workflows and the AI-driven “UPSIDER Coworker,” UPSIDER has rapidly become a go-to financial partner for businesses of “challenging companies”. Beyond simplifying payments, UPSIDER offers an end-to-end solution that includes pre-approval workflows, automated expense reconciliation, immediate Slack-based notifications, and more. These capabilities enable robust financial governance, accountability, and efficiency, making it particularly appealing to publicly listed companies.

Today, we speak with Khai, a machine learning engineer at UPSIDER who has significantly improved the company’s OCR accuracy, cost efficiency, and chatbot performance. Khai shares insights into the technical challenges encountered, the collaborative culture that underpins his team’s success, and the excitement of contributing to a platform that’s redefining corporate finance management.

Khai Nguyen -san's Profile
After earning a Ph.D. from The Graduate University for Advanced Studies, SOKENDAI, he advanced his career as a researcher and engineer at the National Institute of Informatics and Cinnamon AI, contributing to cutting-edge projects in natural language processing, computer vision, and data science. As a Senior AI Engineer at UPSIDER, he works on developing AI solutions to address various complex challenges.

Achievements in 2024 ─95% OCR Cost Reduction via AI Integration

Narisa: Could you tell us about your achievements this year, Khai? We’ve heard that you made significant improvements in OCR accuracy, cost, and speed, and also refined the chatbot for Slack users.

Khai: Certainly. When I joined the team, our OCR solution was already established but needed further refinement to meet production-level standards. My initial focus was on boosting OCR accuracy—by analyzing meticulous details of the model's performance, training pipeline, and introducing advanced post processing algorithms, , we created a more robust pipeline. This allowed us to roll out the “receipt-attaching AI,” enabling users to submit evidence documents with efficiency and far greater accuracy.

In the second half of the year, we turned our attention to operational costs and speed. With extensive experimentation, we integrated Generative AI components with our legacy OCR model. This helped us reduce OCR costs by 95% while maintaining the same accuracy. We also improved processing speed by around 20%, which made the user experience even smoother.

For the chatbot, we improved request classification to minimize unnecessary clarifications. This led to a roughly 30% reduction in situations where the chatbot had to ask the user for more details to understand the user’s intention.

Combined, these improvements reduced manual workloads, enhanced user satisfaction, and delivered tangible value to our customers.

Overcoming Challenges ─Adapting to a Unique Domain and AI Integration

Narisa: Were there any challenges in achieving these results, and how did you overcome them?

Khai: Absolutely. Adapting to UPSIDER’s unique domain was the first hurdle. I spent time on hands-on experiments, reviewing documentation. I got lots of support from my engineering manager and team members and was able to get used to the new system quickly.

Integrating generative AI into the existing OCR pipeline was also challenging—we had to ensure the new approach wouldn’t introduce errors or slow down the system.

Refining the task classification process required analyzing past user interactions to understand why the chatbot sometimes couldn’t respond effectively. By thoroughly examining user logs and trying different models, we identified a better classification strategy.

Throughout these processes, team collaboration was crucial. Regular discussions, code reviews, and open communication helped us iterate quickly, validate our assumptions, and ensure that the solutions truly added value for our users.

Future Initiatives and Goals ─Scalability and AI in Future Products

Narisa: What are your future plans? Any particular technologies or goals you’d like to pursue?

Khai: I want to enhance our OCR to handle more complex documents, such as various invoice formats.

As UPSIDER’s user base grows, scalability becomes paramount.

I also look forward to applying my machine learning expertise to upcoming products, such as “UPSIDER Coworker,” to deepen automation, provide richer insights, and refine risk analyses.

On a personal note, I’m aiming to strengthen my skills in Go, a key language for our backend infrastructure. Becoming more proficient in backend engineering will help me design even more efficient and cohesive AI-driven systems that can handle increasing user demands.

Why UPSIDER ─Applying AI for Tangible Business Impact

Narisa: Why were you interested in joining UPSIDER?

Khai: UPSIDER’s mission of empowering businesses through advanced financial solutions resonated with me. I wanted to apply my AI skills where they could have a practical impact—reducing manual workloads, improving accuracy, and streamlining operations is deeply rewarding.

Additionally, UPSIDER provides opportunities across a broad technical spectrum, from backend systems to applied AI. The company’s inclusive and collaborative culture, with English support and comprehensive documentation, gave me confidence that I could contribute to meaningful solutions.

Excitement about UPSIDER

Narisa: What excites you most about working at UPSIDER?

Khai: The financial domain is evolving rapidly, and we’re at the forefront. We’re building tools that simplify financial operations and enhance governance. The potential for growth—both for the company and for me personally—is substantial. Whether it’s scaling infrastructure or refining AI models, each challenge encourages learning and improvement.
Moreover, the team environment is supportive and open. Issues are resolved quickly thanks to effective communication, and everyone’s willingness to help ensures we move forward together. It’s both challenging and deeply fulfilling.

AI, Teamwork, and the Future of Finance

Khai’s journey at UPSIDER underscores the company’s commitment to innovation, user value, and a truly collaborative work environment. From improving OCR accuracy and cost efficiency to refining chatbot interactions, his contributions exemplify how engineering, AI, and teamwork converge to shape the future of corporate finance. For engineers eager to drive meaningful change in the fintech space, UPSIDER provides an environment where every contribution counts.

At UPSIDER, we're not only focused on "UPSIDER Cowoker," but we're also launching multiple new businesses. If you're interested, let's have a casual meeting!

herp.careers

[Japanese Version]

こんにちは！Dev HRのNarisaです！
今回は、UPSIDERで機械学習エンジニアとして活躍し、OCR（文字認識）機能の精度向上、コスト削減、チャットボット改善などに大きく貢献しているKhai Nguyenさん（以下、Khai）にインタビューしました！技術的な課題や組織内でのコラボレーションの重要性、そして企業財務の新たな姿を切り拓くプロダクト開発へのスタンスなど、Khaiさんの仕事に対する考え方にも注目します。

（ちなみに私個人として初めて、英語でのインタビューに挑戦しました！）

Khai Nguyen さん
ホーチミン市科学大学（UNIVERSITY OF SCIENCE, VIETNAM）を卒業後、総合研究大学院大学にて博士号を取得。国立情報学研究所の研究員として従事したのち、Cinnamon AIにてリサーチャーとして勤務。機械学習、自然言語処理、コンピュータービジョン、データサイエンス領域の知見があり、UPSIDERでは機械学習エンジニアとしてUPSIDER Cowoker事業に従事。

2024年の成果 ─ AI統合とOCRコスト95％削減

Narisa: 今年の成果について教えてください。OCRの精度向上やコスト削減、スピード改善、さらにはSlack上で動作するチャットボットの強化に尽力されたと聞いています。

Khai: 私がチームに参加した時点でOCR基盤はある程度整っていましたが、OCRを活用した新機能としてプロダクション要件を満たすにはさらなる精度向上が必要でした。モデルの解析やアノテーションとPost Processingの改善を行い、より堅牢なOCRパイプラインを構築しました。その結果、「証憑自動紐付け機能」をリリースし、ユーザーが証憑書類を効率的に提出できるようになりました。

2024年後半には、運用コストと処理速度の改善にも取り組みました。OCRモデルと生成AIを組み合わせた結果、コストを約95％削減しつつ、同等の精度を維持。処理速度も約20％向上し、ユーザー体験がさらにスムーズになりました。

チャットボットについては、ユーザーリクエストの分類精度を改善し、ユーザーからの依頼に対して、チャットボットがユーザーの意図を理解するために再質問しなければいけない状況を30%ほど減らすことに成功。これらすべての改善によって、手動対応作業が軽減され、ユーザー満足度も向上しています。

課題の克服―フィンテック領域のドメインキャッチアップとAI統合

Narisa: この成果を達成するにあたって、課題はありましたか？どのように克服したのでしょうか？

Khai: もちろんありました。まず、UPSIDER特有のビジネスドメインに慣れる必要がありました。ドキュメントを読み込み、マネージャーや同僚に質問し、実際に手を動かしてシステムアーキテクチャを理解しました。

さらに、既存のOCRパイプラインに生成AIを組み込む際には、精度やパフォーマンスを損なわないよう、何度も試行錯誤が必要でした。チャットボットの改善では、なぜ誤回答が発生するのかを過去ログから分析し、より適切な分類ロジックを模索しました。

こうした試行錯誤のプロセス全体では常にチーム内のコミュニケーションと協働が極めて重要でした。定期的な議論やコードレビューを通じて迅速に仮説検証を行い、ユーザー価値を高めるプロダクトへとつなげることができたと感じています。

今後の取り組みと目標 ─拡張性と新サービスへのさらなるAI活用

Narisa: 今後の展望や目標として、取り入れたい技術や取り組みたい領域はありますか？

Khai: OCRをさらに高度化し、複雑な請求書など、より多様な書類にも対応できるようにしたいと考えています。また、UPSIDERは今後ますますユーザー数が増えるため、スケーラビリティが極めて重要です。

「UPSIDER Coworker」などの新プロダクトに対して、機械学習の専門知識を活かし、さらなる自動化や高度なインサイト提供、リスク評価の強化など、AIを活用した新たな価値創出を目指します。

個人的には、バックエンドを支えるGo言語のスキルを磨き、AIとバックエンドが密接に連携した効率的なシステム設計を可能にすることで、ユーザーのニーズに応え続けたいです。

Why UPSIDER？ ─ UPSIDERの使命と成長環境への共感

Narisa: なぜUPSIDERに興味を持ち、入社を決めたのでしょうか？

Khai: UPSIDERは先進的な金融ソリューションを通じて企業を強化することをミッションとしており、その中で自分のAIスキルを実際の価値創造に活かせる点に魅力を感じました。手動作業を削減し、精度と効率を高めることで、実用的なインパクトを与えられることにやりがいがあります。

また、バックエンドからAIまで、幅広い技術領域に挑戦できる環境と、英語ドキュメントやグローバルなコミュニケーションをサポートする企業文化があるので、私が成長し、貢献できる環境だと感じ入社しました。

印象に残ったエピソード ─全員参加のブレインストーミング

Narisa: UPSIDERで特に印象に残っているエピソードはありますか？

Khai: 証憑自動紐付け機能をリリースした後のブレインストーミングセッションが印象的でした。エンジニアやプロダクトマネージャーなど、さまざまなバックグラウンドを持つメンバーが集まり、技術的課題、ユーザーインパクト、保守性など、多面的な観点で改善策を検討しました。誰の意見も尊重され、建設的な議論が展開されるこの姿勢は、UPSIDERのカルチャーそのものです。

UPSIDERで働く魅力

Narisa: UPSIDERで働く上で、何が最も刺激的だと感じますか？

Khai: 金融業界は急速な変革期にあり、UPSIDERはその最前線で企業の財務管理を再定義しています。高度なツールを提供することで、経費管理やガバナンスを強化し、顧客に新たな価値を届ける点は非常にやりがいがあります。
また、スケーラビリティの強化やAIモデルの高度化など、エンジニアとして挑戦すべき課題が常に存在します。開発チーム以外のメンバーも非常に協力的で、迅速なコミュニケーションや互いのサポートにより、困難な課題にも前向きに取り組むことができます。

AIとチームワークで築く新しい金融

Khaiさんは2024年、OCR精度やコスト効率の向上、AI証憑自動紐付けをはじめとする新機能開発などに取り組み、ユーザーへ新たな価値を届けました。エンジニアリングとAI、そしてチームワークが有機的に結びつき、スピーディに新サービスを立ち上げ、市場を切り拓く原動力となっています。

UPSIDERでは「UPSIDER Cowoker」だけではなく、複数の新規事業を立ち上げています。興味を持ってくださった方はぜひカジュアルにお話ししましょう！

herp.careers

Culture Deckはこちら📣

speakerdeck.com

2024-12-26

不正利用対策チームがつくる”当たり前の安心感” #UPSIDER年末リレーブログ2024

開発組織

※この記事は、「年末リレーブログ」企画の3日目のブログです。明日は、UPSIDER Coworkerで機械学習領域を担当するKhaiさんによるブログです！

こんにちは！Dev HRのNarisaです。
今回は2024年11月に新設した「不正利用対策チーム」において、Tech Leadとして活躍するRyutaroさんに、安心・安全な決済環境を支えるため奔走する日々を取材しました！

Ryutaro Kobayashi
合同会社 DMM.comに新卒で入社したのち、DMMのプラットフォームを支える決済基盤プロダクトの開発従事。その後UPSIDERに入社後は、電子帳簿保存法対応機能やSlack上で動くチャットボット機能の立ち上げに従事し、決済基盤開発チームに異動。2024年11月から新設した不正利用対策チームのテックリードに抜擢。

不正利用対策チームを新設した2024年

Narisa:今日はよろしくお願いします！ UPSIDERで不正利用対策を担当されていると伺いましたが、まずはチームの概要から教えていただけますか？

Ryutaro:よろしくお願いします。私たち不正利用対策チームは、2024年11月に立ち上がったばかりの専任チームです。背景には、クレジットカード業界全体で年々深刻化している不正利用被害の増加があります。たとえば、経済産業省の公表資料でも、オンライン決済の拡大とともにクレジットカードの不正利用被害額が毎年上昇していることが指摘されています。さらに、2025年3月までに国内EC加盟店への3Dセキュア（3DS）導入を義務化する動きも進み、業界として対策強化が急務なんです。

UPSIDERとしてもしっかりと不正利用対策に取り組む必要があり、これまで社内の複数チーム（決済システム・与信管理・サポートなど）が部分的に行っていた対策を一本化し、明確なオーナーシップを持って取り組もう、というのがチーム新設の主な経緯ですね。
私たちの最終的な目標は、「世界最高水準の不正利用対策」を実現すること。そのためにまずは日本国内で最高水準の仕組みをつくりたいと考えています。

日々の業務と3つの大きな柱

Narisa:「世界最高水準の不正利用対策」という表現が印象的ですね。具体的には、どのような業務を日々こなしているのでしょうか？

Ryutaro:私たちの業務は大きく分けて3つあります。

24時間365日のモニタリング
不審なトランザクションが発生していないか、常に監視し、怪しい決済を早期にブロックします。
万が一の被害対応・保証
不正利用が見つかった場合は、できるだけ早く被害を食い止め、お客さまに返金するまでのプロセスを整えています。特にスタートアップ企業様などはキャッシュフローへの影響が大きいので、迅速な補償対応が重要です。
安全性とUXの両立
不正を防ぐために過度に厳しいルール設定をすると、正規のユーザーが決済しづらくなる恐れがあります。そこでルールベースと機械学習モデルの両方を活用し、誤検知を極力減らしながら、ユーザー体験を損なわないラインを模索しています。

特に3に関してはあまりイメージを持たれないかもしれませんが、例えば先日、本人認証サービス（3Dセキュア）の認証方法をアップデートしました。メール、Slack、モバイルアプリに送信される通知ボタンを通じてワンタップで取引を承認できる仕組みを導入するなど、できる限りユーザーにとって負担のない体験提供を心がけています。

チームのKPIはどう考える？安全を“当たり前”にする難しさ

Narisa:チームのKPIはどのように考えていますか？不正利用対策は“安全に使えること”を当たり前にするチームだと思うので、いわゆるインフラ領域でも議論にあがるような、目標設定の難しさを感じます。

Ryutaro:その通りです。目標指標に関しては、“被害発生件数”や“被害金額”といった分かりやすい指標もある一方で、「被害が発生しなかったこと」は数値化しにくいんですよね。たとえば、不正利用を未然にどれだけブロックできたかは、実際に起きていないと把握しづらい部分がある。
そこで私たちは、“誤検知率”や“ブロックのスピード感”を重視しています。具体的には「怪しい決済を検知したとき、何分以内にブロックできるか」「正規の決済を誤ってブロックしない率をどう上げるか」といった定量的な目標を設定しています。

また、ビジネスKPIにも関連しています。ユーザーが安心して使える環境を整えることで、カード利用額や企業数の拡大につながるはずなので、その数字の伸びにも関与できればと考えています。
要するに、リスクを最小化するだけでなく、事業成長にとっても重要なレイヤーであるという認識をチーム全員が共有している感じですね。

不正利用対策の検知ルールをさらに改善

Narisa:不正利用をゼロにするには厳しいルール設定が有効そうですが、それではユーザー体験が損なわれますよね。そこを両立するための技術的挑戦は、どのように行っているのでしょうか？

Ryutaro:現在はルールベースの判定と機械学習モデルによる判定がメインですが、今後は独自の機械学習モデルを用いた高度なリスク判定をさらに強化する予定です。UPSIDERでは事業拡大に伴い、これまでにかなりの決済データが蓄積されているので、まずはデータ基盤の整備から始めています。将来的にはリアルタイムで不正を検知し、自動ブロックできるレベルを目指しています。

加えて、不正利用が発生した原因分析も重要です。ログを細かく見ながら「どのタイミングで情報が漏洩したのか」「どういう商品や加盟店で決済されたのか」を突き止め、それをルールやモデルに反映していきます。

最近はフィッシング詐欺が増えていることもあり、ユーザーがどんな心理状態や行動フローで引っかかってしまうのかまで想定して対策を講じるようにしています。特定の詐欺サイトに誘導された結果、不正にカード情報を入力してしまうケースもあるので、そこをUXを損なわずどうアラートを出すかなど、今まさにチームで取り組んでいるところですね。

エンジニアとビジネスメンバーが混在するチーム。全員でロードマップを策定

Narisa:なるほど。では、不正利用対策チームが設立されたことで、どのような組織的なメリットがありますか？

Ryutaro:一番大きいのは、責任の所在が明確になったことです。以前は、決済システム開発を担当するプロセッサーチーム、与信管理を担うクレジットチーム、そしてユーザー対応をするサポートチームなど、複数部署で分担していました。結果、指揮系統が分散しがちでした。
今は、不正利用対策チームがオーナーシップを持って意思決定できるので、スピーディに新ルール導入や機能開発を進められています。

Narisa:チームの雰囲気はいかがですか？エンジニアとビジネスメンバー、プロダクトマネージャーが混在しているUPSIDERでも珍しいチームだと聞いています。

Ryutaro:はい、メンバー構成はエンジニアに加えて、ビジネス職、PDM（プロダクトマネージャー）が在籍していて、不正利用対策のKPIを全員で共有しています。
エンジニアから機能改善のアイデアを出すだけでなく、ビジネスサイドからは「ユーザーがどこで使いづらいと感じているか」という観点でのフィードバックが来るので、それをもとにより効果的な機能や運用を作り上げられるのが面白いですね。

Narisa:エンジニアとビジネスメンバーが混在しているからこそ、事業メリットから逆算する本質的な目標設定が可能なんですね。

Ryutaro:まさにそうです。立ち上げフェーズのチームだからこそ、1年先のロードマップをチーム全員で策定し、経営陣やマネージャーに提案する形で進めています。やりたいことを自由に形にできるスタートアップらしさがあって、運用の中でロードマップを都度アップデートしていける柔軟性もUPSIDERの魅力ですね。

2年前のオンボーディングはわずか半日 ─スタートアップらしい大胆さを体感

Narisa:2年を振り返って、UPSIDERで一番印象に残っている仕事はありますか？ハードモードだったエピソードを含めて、その内容と印象に残っている理由を教えてください。

Ryutaro:私が入社したのは2023年3月ですが、当時のオンボーディングがわずか半日で終わり、すぐに新しい電子帳簿保存法対応機能の開発に取りかかったことですね（今はもっとオンボーディング整備されていますが！）。
そのときは法律の要件把握が大変でしたが、エンジニアとビジネスメンバー、合わせて3人ほどで条文やガイドラインを読み込んで要件定義を行い、社内の既存システムとの連携仕様に落とし込んだんです。でも開発が思うように進まないときもあって、ほかのチームにヘルプを出したら一気に人が集まってくれたんですよ。

結果的に6名体制ほどになり、短期間で開発を仕上げることができました。最初は大変でしたが、社内リソースを柔軟にシェアする文化や、大きな裁量を新人にも任せてくれるスタンスは「UPSIDERらしいな」と感じました。

不正利用対策チームへの異動 ─ 決済やインフラが持つ奥深さ

Narisa:スタートアップらしい大胆さですね。そこからどのようにして不正利用対策チームに異動しましたか？

Ryutaro:入社からしばらくはWebチームでの新機能開発や、Slackアプリ連携のプロジェクトに携わっていました。その後、決済基盤（プロセッサーチーム）へ異動し、クレジットカードのトランザクション処理やカード決済に関わるシステムの開発を経験したんです。
私はもともと決済領域に強い関心があったので、プロセッサーチームでの経験はとても刺激的でした。

“不正利用対策”に抱く興味 ─ なぜ面白い？

Narisa:“不正利用対策”には元々興味があったのですか？

Ryutaro:はい、前職でも決済基盤に携わっていたことが大きいですね。決済は社会インフラの一部で、止めてはいけないし、安全性も求められる。その「当たり前」をどう維持し続けるかがすごく奥深いんです。
不正利用対策も同様で、攻撃者側が常に新しい手口を開発しているので、我々も日々アップデートしていかないといけない。ある意味“イタチごっこ”でもあるんですが、だからこそ面白いと感じています。さらに、不正を防ぐだけでなく、ユーザーの利用体験を阻害しないようにするというバランス感覚も、技術者として大きな挑戦なんです。

UPSIDERらしさ ─ 自由度の高さ、望むキャリア、新規事業の立ち上がりスピード

Narisa:KobayashiさんからみてUPSIDERの面白さを教えてください。

Ryutaro:3つ挙げるとすると、まず1つ目は「自由度の高さ」ですね。UPSIDERはまだ規模的にも急拡大中で、組織変更や新規プロジェクトの立ち上げが頻繁に行われています。自分がやりたいと思ったアイデアを遠慮なく提案できるし、チームとしても「やってみよう！」というカルチャーが根付いている。

2つ目は「望んだキャリアを実現できること」です。私自身、エンジニアとして開発を極めつつ、チームリーダーやマネジメントにもチャレンジしたいという希望がありました。UPSIDERでは、そういったプレイングマネージャー的な働き方もできるし、周囲のサポートを受けながらキャリアを形作っていける環境だと思います。

3つ目は「新規事業の立ち上がりスピード」でしょうか。UPSIDERでは既存の法人カードだけでなく、「UPSIDER Coworker」や「UPSIDER BLUE DREAM Fund」など、さまざまなプロダクトやサービスを矢継ぎ早にリリースしています。実際にリリースされるまでが圧倒的に早いので、社内に常に新しい刺激がありますね。新しいテクノロジーやサービス形態にも積極的なので、エンジニアとしても面白いと思います。

今後の挑戦とビジョン

Narisa:今後、Ryutaroさんご自身はどんな挑戦をしたいですか？

Ryutaro:まずは、不正利用対策チームが最初の目標として掲げる「日本最高水準の不正利用対策」を実現したいです。開発サイクルをさらにスピードアップし、独自の機械学習のモデルの強化にもチャレンジしていくつもりです。
最終的には、世界規模で通用する“不正利用対策”を築き上げ、UPSIDERを「日本企業がグローバルで戦えるようにサポートする金融プラットフォーム」へと進化させる一助になれれば、と考えています。

Narisa:素晴らしいビジョンですね。UPSIDERは、AI業務ツール「UPSIDER Coworker」やスタートアップ向けのデットファンド「UPSIDER BLUE DREAM Fund」など、新領域にも積極的に進出していますが、その変化に合わせて組織も発展していきそうですね。

Ryutaro:そうですね。組織もプロダクトも常に進化しているので、これから新しいサービスやチームが次々と生まれていくはずです。その変化の中心で、当たり前の安全性を当たり前に提供する──不正利用対策チームの存在意義はまさにそこにあります。常に新しい手口と戦いながら、UXを守り抜き、事業にも貢献していきたいです。

We’re Hiring! 〜裏方で支える不正利用対策チームの挑戦

不正利用対策は、利用者にとっては「特に意識しなくても安全に使える」という裏方の部分。しかし、その裏には日々アップデートし続ける技術や、ユーザー視点を忘れない運用体制があるからこそ、スムーズな決済体験が成り立ちます。

UPSIDERは、これからも法人カード「UPSIDER」の機能拡充だけでなく、「支払い.com」や「UPSIDER Coworker」など多様なサービスを展開し、常に新たな挑戦を続けていきます。そして、その裏側には不正利用対策チームがいて、決済の安心・安全を下支えしています。

「不正利用対策」をはじめとする社会インフラを支える技術開発に興味がある方、キャリアの自由度が高く新しい事業にも積極的にチャレンジできる環境を求めている方は、ぜひカジュアル面談へお越しください。私たちと一緒に、“日本一、そして世界一”の決済インフラを支えていきませんか？

以上、年末リレーブログ3日目は不正利用対策チーム Tech Lead・Ryutaroさんのインタビューをお届けしました！
明日は、UPSIDER Coworkerで機械学習領域を担当するKhaiさんによるブログです。ぜひお楽しみに。

UPSIDERでは、一緒に挑戦する仲間を募集しています。気軽にお声かけください！

herp.careers

Culture Deckはこちら📣

speakerdeck.com

2024-12-06

ユーザーの利便性にチームで向き合うエンジニアとカスタマーサポート #UPSIDER_Tech

組織

今回はチームを超えて協業している2チーム、法人カード事業「UPSIDER」の開発チームにおいて顧客対応の改善業務をミッションとするエンジニアとカスタマーサポートチームの紹介です！ユーザーの声を起点に連携する両チームは、相互作用によってどのような顧客メリットを生んでいるのしょうか。

法人カード「UPSIDER」事業のCardチームでPO/EM & Backend Engineerを務めるRyo（早坂涼以下、Ryo）とカスタマーサポートチームでマネージャーを務めるYumiko（川手裕美子以下、Yumiko）に、当社VPoEのYusuke Izumi（泉雄介 @yizumi 以下、Yusuke）が話を聞きました。

プロダクト開発チームと密に連携するカスタマーサポートチーム

──まずはおふたりの自己紹介をお願いします。

Ryo： 早坂涼と申します。北海道出身です。上京してからエンジニアとしてSIerに2年ほど勤めたあと、前職では動画配信サービスを運営するビデオマーケットで約5年、プロダクト開発に取り組みました。そこで開発の面白さを知ったのですが、一段落したところでサービスをより育てられる別業種の仕事に挑戦してみたいと思い、UPSIDERに入社しました。挑戦者を応援するサービスを提供していることに魅力を感じ、自分も一緒にチャレンジできるのではと思ったのが理由です。

Yumiko： 川手裕美子です。出身は長野です。UPSIDERに入る前は、宿泊業界で長く仕事をしていました。宿泊施設で5年ほど、施設の立ち上げや運営に携わったあと、宿泊領域のサービスを手がけるスタートアップへ転職しました。主に宿泊施設に導入いただく、予約キャンセル料を回収するtoBプロダクトのセールス兼カスタマーサクセスとして、ユーザーのオンボーディングをサポートしていました。

コロナ禍をきっかけにサービスはクローズしてしまったのですが、ユーザーに近い立場で課題解決をする面白さを体感しました。そんななかでUPSIDERのことを知り、ミッションをはじめ興味をもったので、入社を決めました。

お客様に安心して使い続けていただくための顧客体験を提供するCX Engineering

──まずはCardチームにおけるCX Engineering領域について、紹介をお願いします。

Ryo： CX Engineering領域（通称、CXE）のミッションは、カスタマーサポートや社内の運用の改善を通して、ユーザーにプロダクトを安心して使い続けていただくための体験を提供することです。

これまではユーザーから改善の要望があってもなかなか開発に着手できないケースがあり、「改善の要望や不具合の指摘に対して率先して取り組むチームがあれば…」と考え、生まれました。当初はいちチームとして独立していたのですが、現在はUPSIDERのウェブ機能を開発するチームと合併し、チームの一つの取り組みとして注力しています。

──現在取り組んでいるタスクや技術的なチャレンジについて、具体的に教えてもらえますか。

Ryo： CXE領域では、UPSIDER運用オペレーション管理システムを提供することによって、開発・ビジネスチームを問わず社内メンバーがプロダクト運用をしやすい環境を作ることを目指しています。その際、運用業務の全体をふまえて「どうすればより活動がしやすいのか」をエンジニアが検討し、開発に取り組んでいます。

最終的にユーザーや社内メンバーがハッピーになれる施策は何なのか、常に自分たちで考えて行動する必要があるのが、このチームの面白いところでしょうか。自ら考えて自由に提案して開発に取り組めるのは醍醐味だと思います。

──立ち上げ以降、目指していた取り組みは実現できていますか。

Ryo： 2024年2月頃に一度チームとして「CXEチーム」を立ち上げ、そこから機能リリースを徐々に増やしていました。経理チーム、カスタマーサポートチーム、PRチームなど、それぞれのチームから改善の要望があるため優先順位をつけながら、業務を効率化させるなどのインパクトの大きなものから着手し、着実にリリースを続けられていると実感しています。2024年11月からは、チームとしての機動性を担保することを目的に、UPSIDERのウェブ機能開発チームと合流しました。

ユーザーの声を起点にプロダクト体験を進化させるカスタマーサポートチーム

──続いてYumikoさん、所属のチームについて教えてください。

Yumiko： カスタマーサポートチームに所属しています。ミッションはユーザーの困りごとを解決することなのですが、UPSIDERの体験をユーザーの声を起点に進化させていくチームでありたいと考えています。日々のユーザーからの問い合わせに対応するだけではなく、「長期的にユーザーにとってどう改善をしたら「挑戦者を支える」ことができるのか？」を考えながら施策を検討、実施しています。

──UPSIDERのカスタマーサポートチームは、事業開発部門のなかでエンジニアチームに併設されました。開発とカスタマーサポートの密な連携がその狙いかと思いますが、組織変更を経て何か感じていることはありますか。

Yumiko： カスタマーサポートはユーザーの声がいちばん多く集まるチームなので、さまざまな角度から問い合わせが寄せられますし、その結果プロダクトに対する解像度も高まります。そのため、プロダクトの改善について考えることも多いのですが、エンジニアと連携することでその本質的な解決策を技術的に講じられると感じています。

開発側もカスタマーサポート側もユーザー体験全体をふまえた解決策を考えようという共通意識があるので、より課題解決に向けて取り組みやすくなっていますね。

特にCXE領域に携わるメンバーは、ユーザーからのフィードバックへ真摯に向き合ってくれるので、とても救われていると感じています。例えば、カスタマーサポートからユーザーの声を伝える前に、エンジニアの方々がすでにその声を把握していて解決策まで考え始めてくれていたりするんです。

一次情報に触れる重要性を理解して、積極的に対応しようと動いてもらえるのは、とても嬉しいです。また、ユーザーから具体的な機能改善の要望があっても、その要望の目的をふまえてよりよい改善策を実現しようと動いてくれるのもありがたいですね。

システムやガイドラインの不完全性をチームで解決する

Izumi： システムには必ず不完全性があると考えていて、それはUXやシステム機能的な不完全さもあれば、一方で要件を満たすシステムを提供していても、ガイドラインの不完全性によってユーザーに届かないこともある。いずれもお客様の不安や不満に繋がってしまうので、開発やカスタマーサポートなど、職種にかかわらず誰かが解決しないといけないと思っています。それをチームや役割を超えて、連携しながら解決していきたいですよね。

Ryo： そうですね。またYumikoが話してくれたように、一次情報をいかに取りに行けるかは長い間考えてきた個人的なテーマでした。そして今は、その姿勢をチームや会社の文化として落とし込みたいと考えています。自分ひとりでユーザーの声をすべて拾い上げることは難しいですが、まわりを巻き込んだり仕組み化したりすることでそれも実現できますよね。

また、Yumikoと対等に「こうしたらプロダクトはもっとよくなるよね」と会話しながらユーザーの抱える悩みの解消に取り組めていることは、自分のなかで希望を感じています。開発とカスタマーサポートを一体化させて仕組みや文化から変えていく動きは、自分の入社当時と比べてもどんどん進んでいますし、これから先がとても楽しみです。

エンジニアとカスタマーサポートの連携で心がけていること

──エンジニアチームとカスタマーサポートチームが信頼し合って連携しているのだなと感じます。普段はどういったことを心がけてコミュニケーションをとっていますか。

Ryo： ビジネスサイドのメンバーのもつ「もっとこうしたい」「こうなったらハッピー」「ここにストレスを感じる」といった課題意識を、開発側がどれだけ解消できるかが鍵だと考えています。私たちは彼ら・彼女らのいちばん近くにいるエンジニアチームなので、定期的なヒアリングを通じてその課題意識をキャッチアップし、開発に反映していますね。ビジネスと開発を棲み分けるのではなく、お互いに協力し合える組織体制になっています。

──Yumikoさんは、開発チームの動きをどのように見ていますか。

Yumiko： 本当にありがたいです。Ryoさんのコミュニケーションスタイルは特に、論理と感情のバランスがいいんです。正論を振りかざすこともなく、ビジネスサイドに寄り添ったヒアリングをしてくれます。細かく言わずともビジネス上の重要度を理解したうえで対策を考えてくれるので、とても信頼しています。気持ちのいいコミュニケーションをとれていると感じますね。

Ryo： 一緒に働いているメンバーは、AIとちがって感情をもっています。言葉を受け取った人がどう感じるのか、何かいやな気持ちをもたないかという点は、コミュニケーションするうえで常に気をつけています。そこに注意しないと、ゆくゆくはユーザーへの対応も誤ってしまう可能性があるので。

いちばん大事にしなければいけないのは、信頼ではないでしょうか。それはユーザーからの信頼だけではなく、社内のメンバーからの信頼もそうです。そのためにも、一緒に働きやすいと思える環境をつくり続けるのが大切だと考えています。

ルールを遵守しつつユーザーの期待に応えたい

──カスタマーサポートチームは、最前線でユーザーと向き合うチームです。Yumikoさんはマネージャーとして、そしてチームメンバーとともに、どのような意識で向き合っていますか。

Yumiko： UPSIDERの取り組む金融業は規制業種なので、運営にあたってさまざまな社内ルールがあります。そのルールを遵守しつつ、ユーザーの抱える課題に向き合い続けることが大事だと考えています。ただルールで決められたことでも、ユーザーの要望にもとづいて幅広く対応策を検討するといったことは、意識して取り組んでいますね。「ルールに沿うことがすなわち運用ではない」と、チームメンバーにも伝えています。

──カスタマーサポートチームの考えや動きをふまえ、開発チームはどのようにプロダクトを改善していくのでしょうか。

Ryo： 不具合がある場合に直すのは前提として、改善要望についてもしっかり応えていきたいと考えています。そこでは、言われたことにただ対応するのではなく、本質に立ち返ることを常に意識してプロダクトに反映していけたらと。そしてさらに先には、要望をもらう前に潜在的な課題を解決できるようにしたいですね。データの分析を通じて、ユーザーが抱えている悩みや不満を拾い上げ、改善していく。チームとして心がけながら、実践していきたいです。

AIをはじめとするテクノロ ジーの活用と顧客メリットの創出

──生成AIなどの先進的な技術によって、カスタマーサポートをはじめどのような変化が生まれると考えていますか。

Ryo： チャットボットによるユーザーからの課題のヒアリングなど、すでに多くの企業が導入している技術は、自分たちも当たり前のように採用していきます。運用面についても、システム化を通してどんどん自動化していきたい。一方、AIの得意な領域は頼り、苦手とする領域は人が考えるなど、エンジニア、カスタマーサポート、AIの共存がかなう文化をつくりたいですね。

実際、DevOps的な取り組みを行ったり、開発中にGitHub Copilotを活用してエンジニアの書くコードの品質を担保でき始めているので、これまで気づけなかった不具合も拾い上げて改善することでユーザーからの問い合わせが減り、カスタマーサポートチームの負担も少なくなっていくでしょう。

Yumiko：カスタマーサポートには、プロダクトの機能に関する質問がユーザーからたくさん届きます。回答文章の構成や要点整理にAIを活用できれば、よりわかりやすくスピーディに回答できる日がくるのではないでしょうか。業務の効率化によって生まれた時間は、ユーザーの体験向上について考えるために使えますし、人だからこそ解決できる課題に向き合っていきたいですね。

──今後、よりチームを成長させていくために、どんな仲間にUPSIDERに来てほしいですか。

Yumiko： 役割や業務が異なっても、同じ目的意識をもってゴールに向けて協力できる人でしょうか。カスタマーサポートチームはユーザーの問い合わせから問題に気づいて、関係各所とやりとりしながら対応をリードしていく必要があります。それにはコミュニケーション能力も重要ですし、自分のチームに限らない全体的な視点で考えながら物事を進められるといいですね。

あとはルールにとらわれ過ぎないという話を先にしましたが、前例のない事象を解決できることを面白いと思える人、カオスな状況で能動的に動ける人にとって、当社はとても楽しめる環境だと思います。

Ryo： UPSIDERカードの開発チーム、特にCXE領域には、信頼を守れる人にいちばん来てほしいです。ユーザーやチームのメンバーに対してリスペクトをもてること、そして嘘をつかないことが大切です。あとは物事を自分ごととして考え、自律的に動ける人ですね。自ら余地を見つけて改善するのがチームの文化になっているので、同じように動けることに喜びを感じていただける方にマッチするのではないでしょうか。

Yumikoがカオスという言葉を使っていましたが、当社はまだ整っていないことも多いです。やることがたくさんあるのですが、その環境を面白い、挑戦しがいがあると思ってくれる人だと、一緒に仕事を楽しめるのではないでしょうか。

今回対談した2名のチームは絶賛採用中です！

herp.careers herp.careers herp.careers

ご興味を持っていただいた場合はぜひカジュアル面談にて詳細をお話しできればと思います！お申し込みお待ちしております。

herp.careers

UPSIDER UPSIDER Company Deckはこちら📣

speakerdeck.com

UPSIDER Engineering Deckはこちら📣

speakerdeck.com

2024-11-29

🚧👷👷‍♀️🚧支払い.comで整備中のデザインシステムについて

支払い.com 組織開発 Design Frontend

こんにちは！！

株式会社UPSIDERの「支払い.com」でフロントエンドエンジニアをしていますOkahashi（@akaneburyo）です！

今回は、支払い.comチームで進めているデザインシステムの整備についてご紹介します！

きっかけ

これまで支払い.comチームの開発では、デザイナーにデザインをお願いすることもあれば、フロントエンドエンジニアやPdMがデザインを手掛けることもありました。

これにはデザイナー不在の期間があったことも大きく影響しています。

結果として、次第に以下のような課題が目立つようになってしまいました😢

使い捨てのデザインファイルが乱立している
ページごとに微妙に異なる配色やレイアウトになっている箇所があり、統一感が無い

Figma上には100以上のページがあり、ワイヤーフレームや検討段階で作られた使い捨てのものも多く含まれています🔥

（ちなみに、このファイルはカジュアルに利用できるPlaygroundとして残しています）

そんな中、デザイナーのNaoyaさんが参画してくださったのをきっかけに、2024年9月頃から少しずつデザインシステムの整備を始めました。

支払い.comでデザインシステムを作る目的

支払い.comチームでは、主に以下の点を目指してデザインシステムを整備しています。

プロダクト全体の統一感を高め、使い心地を向上させる
デザイナーとエンジニア双方の実装コストを削減する
実装とデザインファイル双方のメンテナンス性を向上させる

単純な使い心地の向上だけでなく、実装コストの削減とメンテナンス性の向上は将来的にユーザーへ提供できる価値の最大化につながると考えています。

やっていること

UPSIDERには、すでにカード事業で利用しているデザインシステムがあります。

これをベースに、Naoyaさんとフロントチームが主体となって以下を進めています。

コンポーネントの定義
デザイントークンの定義

（まずは小さく、できることから💪）

コンポーネントの定義

各コンポーネントが持つスタイルや振る舞いを実装が可能なレベルに明文化し、Figma上で整理しています。

整理はフロントエンドエンジニアが主体となって行いつつ、デザイナーがレビューを行うことで認識をそろえながら進めます。

再利用されるコンポーネントの整備を丁寧に行い、エンジニアが「よしなに」実装する余地を減らすことで開発の効率化につながると考えています。

将来的にはコンポーネントの外側に発生している制約についても、AutoLayoutやDevModeを駆使して表現したいと考えています💪

デザイントークンの定義

まずは色から整備を進めています。

支払い.comでは、以下の2種類のトークンを定義しています。

Base Token: 特定の要素に紐づかない汎用的なトークン
Alias Token: Base Tokenを継承し、特定の要素に紐づいたトークン

これらは、Figma上でローカルバリアブルとして、それぞれ別々のコレクションに定義しています。

さらに、Base Tokenを直接利用してしまったり、Alias Tokenを意図しない用途で利用してしまうことを防ぐため、可能な限りカラーのスコープも制限しています。

フロントエンドではTailwind CSSを利用しており、トークンはテーマとして表現します。

ここでもFigmaと同様に、用途に応じてスコープを絞って定義します。

const BASE_COLOR_TOKENS = {
  primary: {
    [500]: '#08979C'
  },
  ...{そのほかの色定義}
}

const ALIAS_COLOR_TOKENS = {
    text: {
        primary: {
            dark: tinycolor(BASE_COLOR_TOKENS.primary).darken(7.5).toHexString(),
            base: BASE_COLOR_TOKENS.primary,
            light: tinycolor(BASE_COLOR_TOKENS.primary).lighten(7.5).toHexString(),
        }
    }
    ...{そのほかの色定義}
}

export default {
  theme: {
        colors: {
      // グローバルで利用可能な色は定義しない
        },
        textColor: ALIAS_COLOR_TOKENS.text,
        backgroundColor: ALIAS_COLOR_TOKENS.background,
        borderColor: ALIAS_COLOR_TOKENS.border,
        divideColor: ALIAS_COLOR_TOKENS.border,
        outlineColor: ALIAS_COLOR_TOKENS.border,
    }
    ...{そのほかの設定}
}

また、ここでは:hover :active などの一時的な状態で利用する色として、dark やlight の色も定義しています。

これらの色はtinycolorを利用してフロントエンドで計算を行っており、デザインファイル上のAlias Token には定義していません。

デザインファイルと実装のそれぞれでメンテナンスコストを最小化しつつ、全体で統一するために簡略化する意図で、実験的に取り入れています。

これらを元に、少しずつフロントエンドへ反映しています。

これから

まだまだ反映しきれていない箇所も多く、日々のプロダクトの開発と並行して段階的にリリースを行なっていきます💪

また、試験的な内容も少し含んでいるため、記載した内容からアップデートする可能性も大いにあります。

最終的な完成形についても、改めてブログでご紹介できればと思います🔥

乞うご期待ください！

前提

Zoom Phone

コールキュー

課題

プロトタイプ作成

誤算1: Zoomアカウントの権限問題

問題解決の試み

1. 開発者権限の付与

2. アプリの譲渡

3. 管理者によるアプリ作成の依頼

解決方法

反省点

誤算2: 応答したのに不在着信のWebhookリクエストが発生している

問題の原因

解決方法

反省点

誤算3: Call Cancel が発生していないけど実際には不在着信

解決方法

反省点

誤算4: 応答したけど phone.callee_answered が発生していない

解決方法

反省点

最終的な設計

あとがき

We Are Hiring !!

社会意義の大きさとグローバル視点に惹かれUPSIDERに入社

モバイル×バックエンド×データ分析を完結させる“自給自足”チーム

新規事業でのチャレンジと既存アプリとの相乗効果

「挑戦を歓迎するカルチャーが根付いている」エンジニアとしての裁量とUPSIDERの組織風土

We’re Hiring 〜UPSIDERのMobile App Teamで新たな挑戦を〜

CloudNative Daysとは

UPSIDERのアプリケーションを支える、高セキュリティ・高可用・高スケーラブルなプラットフォーム

What’s Happening in Financial Systems around the world!?

金融システムに求められるScalability, Security, Resiliencyの実体

CloudNative Technologyの恩恵

We’re Hiring !

Achievements in 2024 ─95% OCR Cost Reduction via AI Integration

Overcoming Challenges ─Adapting to a Unique Domain and AI Integration

Future Initiatives and Goals ─Scalability and AI in Future Products

Why UPSIDER ─Applying AI for Tangible Business Impact

Excitement about UPSIDER

AI, Teamwork, and the Future of Finance

2024年の成果 ─ AI統合とOCRコスト95％削減

課題の克服―フィンテック領域のドメインキャッチアップとAI統合

今後の取り組みと目標 ─拡張性と新サービスへのさらなるAI活用

Why UPSIDER？ ─ UPSIDERの使命と成長環境への共感

印象に残ったエピソード ─全員参加のブレインストーミング

UPSIDERで働く魅力

AIとチームワークで築く新しい金融

不正利用対策チームを新設した2024年

日々の業務と3つの大きな柱

チームのKPIはどう考える？ 安全を“当たり前”にする難しさ

不正利用対策の検知ルールをさらに改善

エンジニアとビジネスメンバーが混在するチーム。全員でロードマップを策定

2年前のオンボーディングはわずか半日 ─スタートアップらしい大胆さを体感

不正利用対策チームへの異動 ─ 決済やインフラが持つ奥深さ

“不正利用対策”に抱く興味 ─ なぜ面白い？

UPSIDERらしさ ─ 自由度の高さ、望むキャリア、新規事業の立ち上がりスピード

今後の挑戦とビジョン

We’re Hiring! 〜 裏方で支える不正利用対策チームの挑戦

プロダクト開発チームと密に連携するカスタマーサポートチーム

──まずはおふたりの自己紹介をお願いします。

お客様に安心して使い続けていただくための顧客体験を提供するCX Engineering

──まずはCardチームにおけるCX Engineering領域について、紹介をお願いします。

──現在取り組んでいるタスクや技術的なチャレンジについて、具体的に教えてもらえますか。

──立ち上げ以降、目指していた取り組みは実現できていますか。

ユーザーの声を起点にプロダクト体験を進化させるカスタマーサポートチーム

──続いてYumikoさん、所属のチームについて教えてください。

──UPSIDERのカスタマーサポートチームは、事業開発部門のなかでエンジニアチームに併設されました。開発とカスタマーサポートの密な連携がその狙いかと思いますが、組織変更を経て何か感じていることはありますか。

システムやガイドラインの不完全性をチームで解決する

エンジニアとカスタマーサポートの連携で心がけていること

──エンジニアチームとカスタマーサポートチームが信頼し合って連携しているのだなと感じます。普段はどういったことを心がけてコミュニケーションをとっていますか。

──Yumikoさんは、開発チームの動きをどのように見ていますか。

ルールを遵守しつつユーザーの期待に応えたい

──カスタマーサポートチームは、最前線でユーザーと向き合うチームです。Yumikoさんはマネージャーとして、そしてチームメンバーとともに、どのような意識で向き合っていますか。

──カスタマーサポートチームの考えや動きをふまえ、開発チームはどのようにプロダクトを改善していくのでしょうか。

AIをはじめとするテクノロジーの活用と顧客メリットの創出

──生成AIなどの先進的な技術によって、カスタマーサポートをはじめどのような変化が生まれると考えていますか。

──今後、よりチームを成長させていくために、どんな仲間にUPSIDERに来てほしいですか。

きっかけ

誤算3: `Call Cancel` が発生していないけど実際には不在着信

誤算4: 応答したけど `phone.callee_answered` が発生していない

チームのKPIはどう考える？安全を“当たり前”にする難しさ

We’re Hiring! 〜裏方で支える不正利用対策チームの挑戦