はじめに 英国最大級の銀行である NatWest Group にとって、一貫したカスタマーエクスペリエンスの提供はビジネス上の優先事項であると同時に、規制上の要件でもあります。カスタマーエクスペリエンス業務を中断なく維持することは、事業継続と災害復旧の義務を果たすための基盤です。 NatWest は当初、AWS のヨーロッパ (ロンドン) リージョンに Amazon Connect Customer で カスタマーエクスペリエンスプラットフォームを構築しました 。Amazon Connect Customer は単一リージョンのアーキテクチャの場合も、少なくとも 3 つのアベイラビリティーゾーン (AZ) でアクティブ-アクティブ-アクティブ構成で稼働し、さらに各 AZ は 1 つ以上のデータセンターで支えられています。このマルチ AZ 設計により、大多数のケースにおける Amazon Connect Customer の利用で高いレジリエンスと可用性を達成しています。一方、さらに最高レベルのレジリエンスが必要な場合や、厳格なコンプライアンス要件および地理的冗長性を満たす必要がある場合に向けて、Amazon Connect Customer は Amazon Connect Customer Global Resiliency (ACGR) を提供しています。NatWest は厳格なコンプライアンスとレジリエンス要件を持つ金融機関として、 AWS と連携して Amazon Connect Customer Global Resiliency (ACGR) を導入し、Amazon Lex を活用した会話 AI 体験を含む、完全なアクティブ-アクティブのマルチリージョンカスタマーエクスペリエンスプラットフォームのアーキテクチャへの変革を実現しました。本記事では、その実現までの道のり、構築した自動化ユーティリティ、克服した課題、そして得られた教訓を紹介します。 「NatWest にとって、レジリエンスはオプションではなく、毎日何百万人ものお客様にサービスを提供するための基盤です。Amazon Connect Customer Global Resiliency と Amazon Lex Global Resiliency によるマルチリージョンコンタクトセンターへの移行は、リージョン障害時でもサービスを中断させないために不可欠でした。この変革により、お客様からの信頼を守り、自信を持ってスケールし、大手金融機関に求められるレジリエンス基準を満たせるようになりました。」 ビジネスコンテキストと推進要因 NatWest の Amazon Connect Customer インスタンスは月間 300 万件以上の音声通話を処理し、重要な銀行業務を支えています。お客様はこのシステムを不正行為の報告、影響を受けたカードのブロック、緊急資金へのアクセス、その他の時間的制約のあるリクエストの解決に利用しています。さらに、カスタマーエクスペリエンスプラットフォームは 26 の異なるサービスと連携しており、必要な時に有人エージェントが対応できるようエージェントのスケジューリングを支援するワークフォース管理、不正防止のための音声バイオメトリクス認証、定型的なリクエストをセルフサービスで処理する会話 AI などが含まれます。これらのミッションクリティカルな業務の性質と、金融サービスの可用性に対する規制上の厳しい監視を踏まえると、あらゆるシナリオでのサービス継続性の維持は譲れない要件です。 本取り組みの主な推進要因は以下のとおりです。 規制コンプライアンス: 英国の金融規制当局は、目標復旧時間 (RTO) の定義を含む、実証可能な事業継続・災害復旧 (BCDR) 能力を要求しています 単一リージョンへの依存軽減: ロンドンの単一リージョンに限定された運用では、万一リージョン障害が発生した場合、サービス継続性に関する厳格な規制要件を持つ組織にとって課題となります お客様の信頼保護: お客様は、特にストレスの高い状況において、銀行サービスへの中断のないアクセスを期待しています ミッションクリティカルな業務: NatWest のカスタマーエクスペリエンスプラットフォームは、機密性の高い銀行取引の主要チャネルであり、サービス継続性がお客様の成果に直結します ソリューションアーキテクチャ NatWest は AWS ヨーロッパ (ロンドン) リージョンの既存のコンタクトセンターを拡張し、AWS ヨーロッパ (フランクフルト) リージョンに完全に同期されたレプリカを作成しました。両リージョンはアクティブ-アクティブ構成で同時に稼働します。つまり、エージェントとお客様からの通話はどちらのリージョンでも処理可能です。一方のリージョンで障害が発生した場合も、もう一方を通じてトラフィックが流れ続け、お客様やエージェントが体感できる影響はありません。このアーキテクチャは 2 つの主要な AWS 機能を活用しています。 Amazon Connect Customer Global Resiliency (ACGR) ACGR により、組織は 2 番目の AWS リージョンに Amazon Connect Customer のレプリカインスタンスを作成できます。NatWest が活用した主な機能は以下のとおりです。 自動構成レプリケーション — Amazon Connect Customer リソースのネイティブな準リアルタイム双方向レプリケーション。リージョン間で一貫したエクスペリエンスを提供するために不可欠です。 Traffic Distribution Groups (TDG) — 設定可能な割合に基づいて、電話番号とエージェントのトラフィックを ACGR インスタンス間で分配します。 グローバルエージェントサインイン — エージェントはグローバルサインイン URL を使用して ACGR インスタンス間で認証を行い、代替リージョンに容易に移動できます。 レプリカのリザーブドキャパシティ — 制約なくトラフィックを移動できるよう、2 番目の AWS リージョンにキャパシティを予約します。 Amazon Connect Customer Global Resiliency は会話 AI レジリエンスにも対応しており、Lex V2 ボットをリージョン間で準リアルタイムにレプリケートします。これにより、対話型音声応答 (IVR) とセルフサービス体験の一貫性を、アクティブ-アクティブデプロイメント全体で保つことができます。 図 1: AWS ヨーロッパ (ロンドン) と AWS ヨーロッパ (フランクフルト) リージョン間で Amazon Connect Customer Global Resiliency を使用した NatWest のマルチリージョンアーキテクチャ。Traffic Distribution Groups が通話とエージェントを両リージョンにルーティングする様子を示しています。 カスタム自動化ユーティリティ ACGR は Amazon Connect Customer と Amazon Lex の構成レプリケーションをネイティブに処理しますが、NatWest は Traffic Distribution Groups を大規模に管理するための運用ツールの必要性を認識しました。6 つの TDG 管理ユーティリティと 1 つの Amazon Lex 有効化ユーティリティを開発し、ネイティブの Amazon Connect Customer API を使用してカスタム自動化機能を構築しました。すべてのユーティリティは複数の環境 (dev、test、preprod、prod) にわたる CI/CD パイプラインステージとして実装され、効率的なリージョン切り替えを可能にしています。 ユーティリティ 目的 エージェントの TDG への関連付け エージェントを Traffic Distribution Group (TDG) に追加 電話番号の関連付け 電話番号を TDG にリンク エージェントの TDG からの関連付け解除 エージェントを TDG から削除 TDG 更新 ロンドンとフランクフルト間のトラフィック分配率を変更 TDG 一覧表示 すべての TDG と現在のトラフィック分配状況を表示 Amazon Lex Global Resiliency (ALGR) ボット有効化 Lex V2 ボットの Amazon Lex Global Resiliency をリージョン間で有効化 各ユーティリティは環境パラメータとインスタンスパラメータを受け取り、手動の構成変更なしにすべてのデプロイメントステージで一貫した運用を可能にしています。 導入の道のり NatWest は 20 週間で実装を完了し、その後 3 か月間のフェーズ分けした番号ポーティング期間を設けました。 フェーズ 期間 主なアクティビティ フェーズ 1: 計画と現状把握 1〜4 週 運用準備の要件分析、チーム編成、サービスクォータのレビュー、AWS Well-Architected レビュー フェーズ 2: 開発環境のセットアップ 5〜8 週 Dev 環境での ACGR 設定、シングルサインオンの検証、Terraform パイプラインの更新 フェーズ 3: テストとプレプロダクション 9〜16 週 非レプリケートリソースの処理、TDG テストシナリオ、モニタリングの設定、ステージング環境での検証 フェーズ 4: 本番デプロイ 17〜20 週 サービスクォータの調整、本番環境での ACGR 有効化、段階的なトラフィック移行 フェーズ 5: 番号ポーティング 本番後 3 か月間にわたる電話番号の TDG への段階的なポーティング 「非本番環境で開始したことで、統合の問題、特に非レプリケートリソースに関する問題を、お客様への影響が出る前に早期に発見できました。」 「Amazon Connect Customer Global Resiliency はコアのコンタクトルーティング機能をリージョン間で自動レプリケートする強力な基盤を提供してくれますが、マルチリージョン戦略の真の成功は責任共有モデルの理解と実践にあります。NatWest にとってそれは、Amazon Connect Customer の境界を超えるすべてのものに対してオーナーシップを持つことを意味しました。AWS が管理する部分と自社が管理する部分を明確に分離することで、運用上および規制上の期待に応える、レジリエントで再現性のある、厳密に管理されたグローバルアーキテクチャを構築できました。」 技術的な課題とその解決方法 非レプリケートリソース Amazon Connect Customer Global Resiliency (ACGR) は責任共有モデルで運用されます。AWS は、リージョン間で音声トラフィックをルーティングするために必要な特定の Amazon Connect Customer 構成リソースを自動的にレプリケートしますが、DynamoDB や AWS Lambda など Amazon Connect Customer のリソース境界外にあるリソースについては、お客様が外部でレプリケーションパイプラインを維持する必要があります。 NatWest のマルチリージョンデプロイメントでは、この責任共有モデルによりいくつかの主要コンポーネントの準備が必要でした。 サーバーレスインフラストラクチャ: AWS Lambda 関数は、環境間で一貫した Infrastructure-as-Code (IaC) デプロイメントを維持するため、拡張された Terraform CI/CD パイプラインを使用してレプリカリージョンに独立してデプロイが必要でした。 静的コンテンツ: オーディオプロンプトや静的アセットを含む Amazon S3 のコンテンツは、S3 クロスリージョンレプリケーションを使用してリージョン間で効率的にレプリケートしました。これにより、元のバケットとレプリケーション先のバケット間でオブジェクトが自動的に同期されます。 リアルタイムストリーミング: Nuance Gatekeeper の音声バイオメトリクス機能の統合などをサポートするため、各リージョンに個別の Amazon Kinesis Video Streams の構成が作成されました。これらは ACGR の自動レプリケーション範囲外のためです。 言語と語彙リソース: Amazon Lex カスタム語彙と Amazon Connect Customer カスタム語彙の両方とも、リージョン間で同期するための外部のレプリケーションパイプラインが必要でした。これらのリソースは標準的な ACGR および ALGR のレプリケーション範囲を超えており、お客様側でオーケストレーションの管理が必要です。 カスタム Contact Control Panel (CCP) の修正 NatWest は Amazon Connect Customer Streams API を使用して構築されたカスタム CCP を運用しています。チームは認証ロジックをリージョンに依存しない形に適応させ、エージェントがアクティブなリージョンに容易に接続できるようにしました。 メトリクスとモニタリング NatWest が ACGR をデプロイした当時、Amazon Connect Customer はネイティブな統合クロスリージョンメトリクスビューを提供していませんでした。このギャップに対処するため、NatWest はカスタムの Amazon CloudWatch ダッシュボード と Amazon QuickSight レポートを構築し、両リージョンの運用メトリクスを単一の運用ビューに統合しました。 現在、ACGR は統合されたエージェントメトリクスとコンタクトメトリクスをネイティブに提供しており、効率的なコンタクトセンター運用のための統合コンタクト検索ページも含まれています。 セキュリティに関する考慮事項 セキュリティは AWS とお客様の間の責任共有で実現されます。NatWest は ACGR 実装全体を通じて以下のセキュリティベストプラクティスを適用しました。 NatWest は EU のデータレジデンシーコンプライアンスを維持するためにフランクフルトをレプリカリージョンとして選択しました。これは組織の規制上の義務における重要な要件です。NatWest は転送中および保存時のすべてのデータを AWS マネージドキーで暗号化し、暗号化キー管理のさらなる制御がポリシー上必要な場合にはカスタマーマネージド KMS キーを適用しています。 すべての自動化ユーティリティと Lambda 関数は最小権限の IAM ロールで動作し、各オペレーションに必要な最小限の権限にスコープされています。ロールを設定する際は、IAM ベストプラクティスガイドを参照して、実装が AWS のセキュリティ推奨事項に従っていることを確認してください。チームはリージョン間のトラフィック切り替え時の認証失敗を防ぐため、本番デプロイ前に非本番環境で ID プロバイダーの設定を検証しました。 NatWest は両リージョンで AWS CloudTrail を有効化し、構成変更とリージョン切り替えイベントの完全な監査証跡を維持しています。これにより、コンプライアンスとトラブルシューティングの目的ですべてのアクティビティを追跡できます。 「セキュリティと規制コンプライアンスは、AWS でのクロスリージョン実装の基盤でした。EU データレジデンシー要件を満たすためにフランクフルトを選択し、転送中および保存時のデータの暗号化の徹底、包括的な CloudTrail 監査により最小権限の IAM を適用することによって、レジリエンスや俊敏性を損なうことなく厳格な規制要件を満たすことができました。厳密な本番前検証により、最高のセキュリティ基準を維持しながらスムーズなリージョン間トラフィック切り替えを実現しました。」 2 番目の AWS リージョンの依存サービス設定の一環として、NatWest は定期的に代替リージョンへのトラフィック切り替えを実施し、設定が正確でビジネスが 2 番目のリージョンで一貫して運用されることを確認しました。この取り組みは設定が常に同期されていることを検証し、リージョン切り替えが発生した場合にビジネスが一貫したエージェントおよびお客様体験を提供できると確証を得るために不可欠でした。NatWest はこのフェイルオーバーテストを四半期ごとに実施し、ランブックを最新の状態に保ち、リージョン切り替えへの自信を維持しています。 成果 この実装により、レジリエンス、コンプライアンス、運用全体にわたって測定可能な改善が実現しました。 ほぼ瞬時の RTO — Traffic Distribution Groups により、Recovery Time Objective を 30 分超からほぼ瞬時に短縮しました。手動介入なしに通話が自動的に再ルーティングされます。 負荷下でのフルキャパシティ — シミュレーションされたリージョン障害テスト中に 3,500 件以上の通話のフルキャパシティを維持しました。 規制コンプライアンス — コンプライアンス義務を満たす、文書化されテスト済みのマルチリージョンアーキテクチャを実装し、BCDR 要件を達成しました。 エージェント体験の簡素化 — 単一のグローバルサインイン URL により、3,500 人以上のエージェントが必要に応じてリージョンや ACGR インスタンス間をスムーズに移動できるようになりました。 運用オーバーヘッドの削減 — 自動構成同期が手動のマルチリージョンデプロイメントに取って代わり、エンジニアリングチームを反復的な管理タスクから解放しました。 エンドツーエンドのサービス継続性 — 両リージョンで 26 の統合サービス全体の継続性を維持し、リージョン切り替え時も依存するアプリケーションが正常に動作し続けました。 得られた教訓 NatWest の事例に基づき、同様の実装を計画するチームに以下をお勧めします。 1. 非本番環境で開始 — レプリケートされていないリソースにおける統合の問題を本番環境に到達する前に発見する 2. SAML/SSO の早期検証 — ACGR レプリカ作成とグローバルサインインの開始前に、ID プロバイダーの設定を完了しテストする 3. すべての統合を監査 — Amazon Connect Customer と統合するすべてのサービスを文書化し、開始前にレプリケートされる対象とされない対象を分類する 4. 本番稼働前にモニタリングを構築 — 本番トラフィックの移行前にクロスリージョンの運用ダッシュボードを整備する 5. 定期的な障害注入テストを実施 — 定期的なフェイルオーバー訓練を予定し、トラフィックの再ルーティング、エージェントのサインイン、 すべての統合サービス (NatWest の例では 26 のサービス) がシミュレーションされたリージョン障害時に正しく機能することを検証する。NatWest は四半期ごとに障害注入演習を実施し、現実的な条件下で RTO 目標を検証しています。 6. 段階的なトラフィック移行を実施 — ハードカットオーバーではなく、TDG 更新ユーティリティを使用してレプリケート先リージョン (フランクフルト) のトラフィック割合を徐々に増加させ、ロールアウトを制御 7. 各フェーズゲートで AWS Well-Architected レビュー を適用し、信頼性の柱およびレジリエンスレンズに照らしてアーキテクチャ決定を検証 まとめ NatWest による Amazon Connect Customer Global Resiliency と Amazon Lex Global Resiliency の実装は、大規模な金融機関がオペレーションの簡素さを犠牲にすることなく、金融規制基準を満たすコンタクトセンターレジリエンスを実現できることを示しました。AWS ネイティブのレプリケーション機能と、目的に応じた自動化ユーティリティ、そして規律あるフェーズアプローチを組み合わせることで、NatWest は単一リージョンアーキテクチャを完全にレジリエントなマルチリージョンコンタクトセンターへと変革し、規制要件を満たしつつカスタマーエクスペリエンスを保護しました。 この取り組みには 20 週間の集中的なエンジニアリング作業が必要でしたが、その結果、完全なリージョン障害にも、お客様が体感できる影響なしに、手動介入せずとも耐えられるアーキテクチャを確立しました。 次のステップ Amazon Connect Customer コンタクトセンターにマルチリージョンレジリエンスを組み込む準備はできましたか？まずは Amazon Connect Customer Global Resiliency のドキュメント と Amazon Lex Global Resiliency ガイドをご確認ください。また、 AWS Well-Architected 信頼性の柱 を活用して現在のアーキテクチャを評価し、実装開始前にレジリエンスのギャップを特定することもできます。 筆者について Prateek Guleria は NatWest の DevOps リードです。自動化の実行、CI/CD パイプラインの開発・実装の監督、AWS プラットフォーム上のクラウドインフラの維持を担当しています。 Srinath Chandrasekharan は NatWest のリリーストレインマネージャーです。プログラム実行の戦略的オーケストレーターとして、すべてのテクノロジーデリバラブルがビジネスおよびテクノロジー OKR に直接整合する形で、正確に計画・同期・実行されることを確保しています。 Baraa Elkosh はイギリス・ロンドン拠点の AWS シニアテクニカルアカウントマネージャーです。エンタープライズ顧客と連携してクラウド導入を加速させ、コンタクトセンターのモダナイゼーションと AI 統合を専門としながら、大規模な運用安定性を確保しています。 Abhay Kumar は NatWest のエンジニアリングディレクターです。コンタクトセンタープラットフォームのアーキテクチャ、開発、保守、品質、セキュリティを担当しています。 Kapil Arora は NatWest のプリンシパルエンジニアで、ソフトウェア業界で 21 年以上の経験を持ち、多彩な技術的バックグラウンドが特徴です。ソフトウェアエンジニアリング、ソリューション設計、データエンジニアリング、クラウドエンジニアリング、DevOps、コンテナ化、AI エージェントおよびエージェンティックアプリケーションフレームワークにわたる経験があります。 Manoj Srinivas はアメリカ・ワシントン州シアトル拠点の Amazon Web Services のプロダクトマネージャーです。Amazon Connect Customer Global Resiliency の開発を推進しており、これは企業が事業継続性とコンプライアンスのために AWS リージョン間でシームレスに Amazon Connect Customer を運用できる機能です。仕事以外では、旅行とサッカーを楽しんでいます。 Abilashkumar P C  はロンドン拠点の Amazon Web Services の Applied AI シニアスペシャリストソリューションアーキテクトです。サーバーレステクノロジーを活用したコンタクトセンター全体で、レジリエントな AI 搭載ソリューションの設計・構築を顧客と共に行っています。 Prabhakar Rajasekar はドイツ・アーヘン拠点の Amazon Web Services WWSO の Applied AI ソリューションアーキテクトです。顧客のデジタルトランスフォーメーションを支援する傍ら、庭や森で子どもたちと過ごす時間を大切にしています。 本記事は 2026 年 7 月 9 日 に公開された「 How NatWest built multi-region resilience with Amazon Connect Customer 」を翻訳したものです。 この記事はテクニカルアカウントマネージャーの高橋が翻訳しました。

はじめに この記事は、BASEテックブログ夏のブログリレー11日目の記事です。 BASE Dept. Product Divにてバックエンドエンジニアをしている オリバ です。 ショップオーナーの発送領域を担当しており、バックエンドを中心に、フロントエンドやNew Relicなども触っています。 2026年5月、担当する「送り状一括印刷 App」の一部機能をリリースしました。しかし、リリース後に分かったのは、想定していた使われ方をされていないということでした。機能自体は動いていますが、開発チームが想定していた操作と、ショップオーナーの実際の操作が違っていました。 Appの概要や使い方は以下をご覧ください。 送り状一括印刷 App（BASE Apps） apps.thebase.com 発送作業の時間を大幅削減！「送り状一括印刷 App」の使い方解説（BASE U） baseu.jp 本記事では、顧客の声を開発の意思決定に組み込むために実践した3つの取り組みと、その効果について共有します。 顧客中心主義とは 私は仕事の中で「顧客中心主義」という考え方を心掛けています。『みんなでアジャイル』で知った言葉です。 この本では、組織全体でアジャイルを実践するための原則として、次の3つが紹介されています。 「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」 引用：みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた｜O'Reilly Japan www.oreilly.co.jp もともと私はDDDやクリーンアーキテクチャが好きで、設計に関心がありました。これらは変更容易性を高めるための手段でもあり、いわばHOWにあたります。ただ、HOWをいくら磨いても、何を作るかというWHATとなぜ作るのかというWHYが定まっていなければ成果にはつながりません。自分にはこのWHATが足りていないと感じ、顧客中心主義を実践しようと思いました。 とはいえ、言葉として知っていることと、日々の開発で実践できているかは別です。 なぜ顧客の声を聞きに行ったのか 以下の3点が理由です。 1. 開発チームだけではユースケースの想像に限界がある 新機能の開発時、その機能が使われるユースケースを開発チームだけで想像していました。しかし、ショップオーナーが発送作業の際にどの画面を見て、何を基準に判断しているのかは把握できていませんでした。 2. チームが向かう方向を決めるきっかけにしたかった 私は送り状一括印刷App開発のPJMを務めており、チームが向かっていく方向づけも担っています。「この機能を今すぐ開発すべきなのか、本来の趣旨から外れているから後に回すべきか」といった判断を、顧客の実態をもとに行いたいと考えました。 3. AIの導入で実装スピードが上がり、PDCAを回したかった 開発にAIを導入したことで、実装スピードが上がりました。ただし、作るスピードが上がっても、何を作るかの精度が上がらなければ効果は限定的です。リリース後の反応を早く拾い、次の改善につなげるサイクルを回したいと考えました。 実践① ユーザーインタビューに同席する PdM・デザイナーが実施するショップオーナーへのユーザーインタビューに、3〜4回同席しました。聞くだけではなく、私からもいくつか質問をしています。 想定していた動線と実際の動線が異なっていた 送り状一括印刷 Appでは、お届け先住所の初期値に購入者がカートで入力した住所情報が、送り主情報の初期値にAppの設定画面で登録した住所情報が設定されます。個別に変更したい場合は、注文画面の送り状印刷アイコンからモーダルを開いて変更できます。 しかしインタビューでは、このモーダルの存在に気づいてもらえておらず、「お届け先住所と送り主情報の初期値は変更できない」と認知されていることが分かりました。 注文画面の送り状印刷アイコン（2026年9月時点） 送り状印刷アイコンから開く「送り状内容」モーダル（2026年9月時点） 発送通知の失敗が把握しづらく、独自運用で補われていた 発送通知に失敗しても、ショップ側で後から把握しづらい状態になっていました。そのため、注文メモなどを使った独自運用で補っているケースがありました。 エラーの有無だけでなく、対象の注文・失敗理由・次に取るべき行動を後から確認できる必要があると考えています。 注文画面が発送判断の中心的な画面になっている インタビューを通じて、注文画面がショップの梱包・発送を判断するための中心的な作業画面になっていることが分かりました。メンバーシップ特典など、発送判断に必要な情報は注文画面上で確認・検索できるとよいと考えています。 発送判断の中心となる注文画面（2026年9月時点） 細かな改善でも現場の制約を解消できる 問い合わせで挙がっていた要望をもとに、送り状一括印刷 Appで印刷位置を指定できるようにしました。その後のユーザーインタビューでは、この改善についてショップオーナーから感謝の声をいただきました。大きな機能追加ではなくても、現場の制約を解消する改善には実用的な価値があると感じました。 同席して分かったこと 開発者には自明なアイコンや操作でも、初めて使うショップには意図が伝わらない場合がある UIだけでなく、ツールチップや画像付きヘルプなども含めて使い方を伝える必要がある ショップオーナーの利用実態や反応を直接知ることが、開発の目的と価値の再認識につながる 実践② 問い合わせ内容を定期的に確認する BASEのショップ管理画面には問い合わせフォームがあります。このショップオーナーから寄せられた問い合わせを、定期的に確認するようにしました。 開発中・リリース直後の機能は週に数回確認する 開発中の機能やリリースしたばかりの機能については、週に数回確認しています。ユーザーインタビューと違って日程調整が不要なため、リリース直後の反応をすぐに拾えます。 SLI/SLO振り返り会のアジェンダに組み込む 個人が気の向いたときに見るだけでは、見る人と見ない人が分かれ、チームの判断材料になりません。そこで、Order Sectionで月1回実施しているサービスレベル（SLI/SLO）振り返り会のアジェンダに、顧客の声を確認する時間を組み込みました。 SLI/SLOの数値は、システムがどれだけ安定して動いているかを示します。しかし、その数値が顧客にとって十分かどうかは、数値だけでは分かりません。同じ場で顧客の声を扱うことで、指標と実態を突き合わせて話せることを狙っています。 見つけた声はSlackでチームに共有する 送り状一括印刷 Appについては、PdMと私が問い合わせ内容を見て、気になった声をSlackでチームメンバーに共有しています。現状はこの形で回っており、メンバー全員がDBを見に行く状態にはなっていません。 実践して分かったこと 送り状一括印刷 Appにおいて、想定した使い方がされていないことをすぐに認知でき、改修からリリースまでのサイクルを短く回せた。アジャイルの利点が出た部分だと感じている SLI/SLOのエラーバジェットの数値が安定していても、ショップオーナーの希望を満たせているとは限らないことが分かった 実践③ CXチームにヒアリングする CXチームは、ショップオーナーと継続的にコミュニケーションを取りながら、ショップ運営の課題解決や「BASE」の活用を支援するチームです。このCXチームにMTGの時間をもらい、ヒアリングをしました。 非機能要件の課題を見つける目的で声をかけた CXチームが担当するショップオーナーの中には、規模の大きいショップも多く含まれます。注文・発送領域のパフォーマンスなど、非機能要件の課題を見つけられるのではないかと考え、声をかけました。 実践①のユーザーインタビューや、実践②の問い合わせ内容で拾えるのは、使い方や機能に関する内容が中心です。一方で、表示速度のような非機能要件の話は、問い合わせとして上がってこないこともあります。 開発チームからは見えていなかった課題を把握できた ヒアリングを通じて、開発チームからは見えていなかった非機能要件の課題を把握できました。具体的な内容はここでは割愛しますが、実践②で書いたとおり、SLI/SLOを見ているだけでは気づけない内容でした。 単発のMTGから継続的なやり取りへ ヒアリングのMTG自体は一度だけですが、その後もCXチームとのやり取りは続いています。 実践して分かったこと 非機能要件の課題は、ショップオーナーと日常的に接しているチームのほうが実態を把握している場合がある エンジニアから他部署に声をかけることで、一度のヒアリングだけでなく継続的な相談先ができる 何が変わったか 改善タスクの起票数が増えた Order Sectionには複数チームがあり、私が所属するチームでは、注文画面や発送領域に関する改善タスクの起票数は、以下のように変化しました。 2〜6月：月2〜4件 7月以降：月7〜8件 7月ごろにユーザーインタビューを実施し、そこで得た内容をもとに課題の洗い出しから起票、実装、リリースまでを行いました。顧客の声を聞くことで、これまで見えていなかった課題が可視化され、タスクとして起票できるようになったことが大きいと考えています。 エンジニアから提案してタスク化する場面が増えた これまでは、Bizチームや顧客問い合わせの多さを鑑みて、別部署から依頼された案件をタスク化していくことが多かったです。顧客の声を直接知るようになってからは、エンジニアからPdMやデザイナーに提案し、タスク化して改善につなげる場面が増えました。 職種を越境して、主体的に改善タスクを推進できるようになったことが、今回の一番大きな変化だと感じています。顧客の声が、何を作るかを決める際の材料として開発の意思決定に入るようになった、とも言えます。 うまくいかなかったこと 課題が可視化され、AIによって実装も速くなっていたため、タスクを並列で進めようとしてしまいました。結果、自身が疲弊しました。 顧客の声を聞くと、改善すべきことは確実に増えます。実装スピードが上がったことで、「やれるはず」と思ってしまったのも原因だと考えています。声を集める仕組みだけでなく、集まったものを絞る側の判断も必要だと感じています。 これからやりたいこと BASEコミュニティ Meetupに参加する 弊社ではショップオーナー向けのコミュニティポータルを運営しており、その一つの取り組みとしてBASEコミュニティ Meetupを開催しています。 BASEコミュニティポータル community.thebase.com 前回はこちら：BASEコミュニティ Meetup vol.15 大阪（2026年8月開催） community.thebase.com 今後は運営側としてこの場に関わり、ショップオーナーの声を直接聞いて発送領域の改善につなげていきたいです。 非機能要件の課題をもっと洗い出す CXチームへのヒアリングで、非機能要件の課題は開発チームから見えにくいことが分かりました。機能要件だけでなく、非機能要件の課題を洗い出して改善していきたいと考えています。 おわりに 本記事では、顧客中心主義を開発の意思決定に組み込むために実践した3つの取り組みを紹介しました。 開発チームの中だけで顧客の使い方を想像していた状態から、顧客の実態をもとに改善を提案できる状態に変わりました。ただし、可視化できてきたのは機能要件に関する要望が中心です。非機能要件の課題はまだ隠れているものが多く、これをどう見つけていくかが今後の課題です。 弊社では、顧客の声をもとにプロダクトを改善していくことに関心のあるエンジニアを積極採用しています。興味を持っていただけたら、ぜひ下記からご応募ください！ binc.jp 明日は、BASEテックブログ夏のブログリレーのラストを飾る、rerenoteさんの記事です。お楽しみに！

Antigravityとは？ Google Antigravityは、AIエージェントを活用して、開発業務に限らず、様々なナレッジワークを進めるためのエージェントプラットフォームです。現在のAntigravityは一つのアプリだけを指すものではなく、「Antigravity 2.0」「Antigravity CLI」「Antigravity SDK」「Antigravity IDE」など、用途に応じた複数のインターフェースが用意されています。今回取り上げるのは、その中の Antigravity 2.0 です。