楽天のUsability Assurance完全解説 — 70超サービスの品質を守る「リリース前必須プロセス」の全貌

この記事で得られること

楽天CRD（クリエイティブデザイン戦略部）の3層構造と役割分担
UA（Usability Assurance）の具体的な8ステッププロセス
SUSスコアによる定量的な品質基準の設定と運用方法
2013年〜2025年の10年の変遷（立ち上げ期→成長期→成熟期）
個人開発者が取り入れられる実践的なエッセンス

楽天CRDとは何か

楽天グループのクリエイティブデザイン戦略部（CRD: Creative Design Strategy Department）は、グループ横断のクリエイティブ専門組織だ。70を超えるサービス（楽天市場、楽天トラベル、楽天モバイル、楽天カードなど）に対して、UI/UX、ブランドロゴ、カラーなどのアセット制作・管理を担う。

CRDのジェネラルマネージャー鍋嶋靖弘氏は「グループが持つ顧客接点ごとにブランディングの企画から実際のクリエイティブ制作までワンストップで行う」と述べている。

出典: 宣伝会議ブレーン — 楽天のイラストシステム共創 2025/04

3層構造の全体像

楽天のデザイン品質を支えているのは、3つのレイヤーの組み合わせだ。

レイヤー	名称	役割	対象
①作る	ReX（Rakuten Experience）	デザインシステム。UIコンポーネント・ガイドライン	全サービスのデザイナー
②守る	UA（Usability Assurance）	リリース前の品質保証。ユーザビリティテスト＋SUS	新規プロダクト・大規模リニューアル
③統括する	CRD	横断組織。ガバナンス・品質管理・ブランド統制	グループ全体

ReX（Rakuten Experience）

IDEOの監修のもと2017年に構築。楽天ブランドが提供する体験価値を言語化し、各クリエイターが「表現に迷ったときに立ち返る指針」として機能する。デザインシステムとしてUIコンポーネントを標準化し、効率的な制作を可能にしている。

ReX Design Reviewとして、デザイン段階でのレビュー体制も整備され、楽天グループ規程に必須プロセスとして掲載されている。

出典: 楽天公式 — ReX: Rakuten Experience

UA（Usability Assurance）

本記事の主題。詳細は後述。

CRD

各事業部のデザイナーは「事業の目標」を追い、CRDは「統一感・品質コントロール・ガバナンス」を担う。この役割分離が、70以上のサービスを持つ楽天のデザイン一貫性を支えている。

UA（Usability Assurance）の全貌

UAの目的

UAは2つのリスクに対処するために存在する。

リスク	内容
ビジネスリスク	ユーザビリティの問題による機会損失の防止
ブランドリスク	批判的な評判のリスク軽減

UAの対象

新規プロダクトのリリース前
大規模リニューアルのリリース前

日常的な小さな改善は対象外。「強力なゲート」として、リリース前の最後の砦の役割。

UAの8ステッププロセス

UAは以下の8ステップで構成されている。

Step 1: 要件定義
  → テスト範囲・目的の設定
  → 「前後の体験も含めた範囲」を設定
  
Step 2: テストユーザーのリクルーティング
  → 従業員パネル制度（5万人）を活用
  → 表層的な条件でなく、実際の利用状況に基づく要件
  
Step 3: テスト環境の準備
  → 「リリース時に近い体験ができる環境」を構築
  → 不自然な体験でテストしない
  
Step 4: シナリオ設計
  → タスク指示ではなく、想定状況の共有
  → 「あなたはまだ契約していません。検討中にこのサイトを訪れました」
  → 行動はユーザーに委ねる
  
Step 5: ユーザビリティテスト実施
  → UX Research Room（マジックミラー付き観察室30人収容）
  → Zoomウェビナーでリモート見学可能
  → 行動を制限せず観察
  
Step 6: SUSスコア測定
  → テストユーザーにSUS回答を依頼
  → ネガティブ回答の要因もヒアリング
  → 定性/定量の両面から課題への共感を促す
  
Step 7: レポート作成・報告
  → SUSスコア + 主な課題 + 改善提案
  → 経営陣にメールで報告（必須）
  → テストを見学できなかった関係者への共有
  
Step 8: 改善・効果検証
  → 改善計画の策定
  → プロジェクトの振り返り
  → 改善後の効果検証（SUS再測定含む）

年間実績: 平均40〜50プロジェクト、テスト対象は年間240〜300名

SUSスコアによる品質基準

**SUS（System Usability Scale）**は、ユーザビリティを100点満点で数値化する世界標準の手法。10の質問に回答してもらい、スコアを算出する。

楽天がSUSを採用した理由:

「データや数字が重要視される楽天の文化」に合致
定性的な結果だけでなく、結果のスコア化＋目標基準を定められる
経営陣への報告に客観性を持たせられる
長期的なトレンドを追跡できる

成果: 楽天グループ全体のSUSスコア平均は年々上昇傾向。顧客調査における「使いやすさ」の満足度指標も改善。

従業員パネル制度

UAの実行力を支える仕組みの一つ。

項目	内容
対象	楽天グループ国内従業員（間接雇用含む）
登録数	約5万人（2024年9月時点）
仕組み	入社時に自動追加。自分の意思でいつでも退会可能
利用頻度	年間150件程度のメール配信
用途	UA用のテストユーザーリクルーティング + 他部署のリサーチにも活用

条件に合うユーザーを迅速にリクルーティングできるため、開発スケジュールの変更にも柔軟に対応できる。

10年の変遷：立ち上げ期→成長期→成熟期

立ち上げ期（2013年〜）

状況	対応
UAの存在や必要性を知らない人が多い	草の根活動。「UX」という言葉をあえて使わず、事業課題の解決を通じて価値を実証
ユーザビリティテストの場所がない	UX Research Room を設立（2013年）
経営層の理解が不足	「役員キャラバン」を実施。役員参加率 70%超
ビジネス成果との紐付けがない	楽天トラベルでCVR向上・クーポン発行数史上最多を実現

ターニングポイント: 地道な実績づくりを経て、社長承認によるUA必須化を発表。

成長期

状況	対応
UA必須化後もUAを実施せずリリースするプロジェクトが存在	楽天グループ規程にUA必須化を掲載
経営陣への報告体制が不十分	UA結果のメール報告を制度化。ビジネス意思決定の判断基準の一つに

結果: 対象プロジェクトで漏れなくUAが実施できる状態を実現。SUSスコア目標を上回るプロジェクトが増加。

成熟期（現在）

取り組み	内容
ReX Design Review	デザインシステムを活用した、デザイン段階でのレビュー。グループ規程に必須化
Fundamental UA	リリース後のプロダクトにもUAを実施する新たな仕組み
事業部側の自走化	UA以前に事業部自身でユーザビリティテストを実施するケースが増加
ツールキット開発	サービスデザインプロセスに活用できるツールキットの開発
研修・トレーニング	UXリサーチの文化を組織に根付かせるための教育

将来ビジョン: 「UAが必要ない状態」＝デザインプロセスが洗練され、UA以前の段階であらゆるリリースの品質基準が高いレベルで満たされている状態。

楽天モバイルでの具体的な適用例

楽天モバイルは2020年に携帯キャリアサービスを本格開始。2024年10月時点で800万回線を突破。ユーザビリティ保証チームは12個のプロダクトの評価に関わってきた。

実際のテスト設計の考え方

悪い例: 「お申し込みページ」だけを単体テスト

良い例: 「プラン理解 → 申し込み → SIM初期設定」の前後の文脈を含めたフロー全体をテスト

ユーザーにとっては「申し込み」がゴールではなく、「理解しやすく利用できること」がゴール。

テストの進行方法

やらないこと: 「〇〇をしてください。その次に〇〇をしてください」とタスクを指示する

やること: 「あなたはまだ楽天モバイルの契約をしていません。契約を検討している時に、このサイトを訪れました。」と想定状況を共有し、自由に操作してもらう

発見された課題と改善の例

課題	内容
必須項目の未入力	未入力であることに気づきにくいUI → エラー表示の改善
氏名入力の煩わしさ	漢字とフリガナの二重入力 → 入力支援の導入
キーボード切替の手間	数字入力時にキーボードを手動切替 → inputmode属性による自動切替

一見地味だが、800万回線のサービスでは影響範囲が膨大。

3つの成功要因：大義・ルール・基準化

楽天のUA仕組みが10年にわたって機能し続けている理由は、この3つの要素にある。

1. 大義

「なぜこの仕組みが必要なのか」を、組織の全員が腹落ちできる理由として示し続ける。ユーザビリティが楽天グループのビジネスとブランドに対して極めて重要な課題であることを、あらゆる場面で発信。

2. ルール

大義だけでは不十分。楽天グループ規程にUA必須化を明記し、強制力を持たせた。プロセスの細部に至るまで明確なロジックを示すことで、正当性を担保。

3. 基準化

ユーザビリティという定性的な概念を、SUSスコアで数値化。全員が同じ基準で良し悪しを判断できるようにすることで、形骸化を防止。

個人開発者への示唆

楽天の仕組みをそのまま個人で再現するのは不可能だが、エッセンスは取り入れられる。

1. 「リリース前の最小限チェック」を必須化する

5項目でいい。リリース前に必ず確認するチェックリストを作るだけで、ユーザビリティ問題は大幅に減る。

最小限チェックリスト例:

主要タスクを初見ユーザーが完了できるか（3人に試してもらう）
エラー状態が明確に伝わるか
戻る操作が常にできるか
重要なアクションに確認ステップがあるか
モバイルで主要操作が片手でできるか

2. SUSを使って定量化する

SUSは10問のアンケートだけで実施可能。無料。友人や家族に使ってもらった後に回答してもらうだけで、プロダクトのユーザビリティを数値化できる。スコアの推移を追うことで、改善の効果を客観的に確認できる。

3. 「タスク指示」ではなく「状況設定」でテストする

楽天の「想定状況を共有して自由に操作してもらう」方法は、個人開発者のユーザーテストでもそのまま使える。「このボタンを押してください」ではなく「あなたは〇〇したいと思ってこのサイトに来ました」と設定する。

4. テストは「見学」させる

楽天のUX Research Roomの観察室のように、チームメンバーや関係者にテストを見学させることで課題への共感が生まれる。個人開発者でも、Zoomで画面共有しながらテストを実施し、パートナーやメンターに見てもらうだけで効果がある。

まとめ

楽天CRDのUsability Assuranceは、10年かけて「なくてはならないプロセス」にまで育て上げた事例だ。

核心にあるのは、「品質は作るだけでは守れない。守る仕組みが別に必要」という認識。そしてその仕組みを定着させるために必要なのが、大義（なぜ必要か）・ルール（強制力）・基準化（数値化）の3本柱。

個人開発者にとって最も参考になるのは、**「完璧なプロセスを作ること」ではなく「最小限のゲートを設けて、リリース前に必ず通すこと」**という発想。5項目のチェックリストと、3人のテストユーザーから始めれば十分だ。

参考文献:

エンジニア

楽天のUA 8ステップのうち、個人開発者がすぐ真似できるのはStep 4（シナリオ設計）とStep 6（SUS測定）。特にSUSは、Googleフォームで10問のアンケートを作るだけで実装できる。スコアの算出もExcelで自動化可能。「数字で品質を語れる」ようになるだけで、改善の説得力が全く違ってくる。

デザイナー

「タスク指示ではなく状況設定」でテストするという楽天のアプローチは、デザイナーがよく陥る罠を避けている。「このボタンを押してください」と言った瞬間、テストは「ボタンが見つかるか」のテストになってしまう。本当に知りたいのは「ユーザーがそのボタンを押したいと思うか」。この違いは決定的に重要。

マネージャー

楽天が「グループ規程にUA必須化を明記」したのは非常に重要なポイント。UAの仕組みが10年間形骸化しなかった最大の理由は、ここにある。個人開発者にとっての「規程」はGitのpre-commitフックやCIパイプラインだろう。チェックリストをPRテンプレートに組み込むだけで、「必ず通すゲート」になる。

デスク

この事例の本質は「品質保証を属人化させない」こと。楽天は10年かけて、個人の能力ではなく仕組みで品質を担保する体制を作った。個人開発者は一人で全てをやる分、仕組み化の重要性はむしろ高い。SUSスコアの記録、リリース前チェックリスト、テスト動画のアーカイブ。この3つがあるだけで、半年後の自分が救われる。

✏️ 編集部メンバーを見る →