GitLab における Service Design
Service Design とは
Service Design は、タッチポイント、チーム、システムをまたいで エンドツーエンドの体験 を形作るプラクティスです。ビジネス戦略、ユーザーニーズ、デリバリーチーム の間の橋渡しとして機能し、以下を見ていきます:
- フロントステージ: ユーザーが見たり操作したりするもの
- バックステージ: それらのインタラクションを可能にするプロセス、ポリシー、システム
GitLab 固有の例として、Service Design の発想を使って理解できるジャーニーがあります:
| ステップ | GitLab について聞く | プロダクトを試す | 自組織にお客様として導入することを説得する | 組織全体のテックスタックに採用する |
|---|---|---|---|---|
| フロントステージ | カンファレンス | gitlab.com | 社内および社外のミーティング | 更新ミーティング、gitlab.com |
| バックステージ | DevRel | Product | Sales | Customer Success |
Service Designer が協働する相手
Service Design は、プロダクトデザイン、プロダクトマネジメント、エンジニアリングマネジメント、UX リサーチと並んでアクセラレーターとして機能し、インサイトとソリューションをジャーニー全体の包括的なビューに結びつけます。戦略、デザイン、実行を整合させることで、各分野のインパクトを高め、GitLab が一貫したエンドツーエンドの体験を提供できるよう支援します。
Service Design に期待できること
Service Design は、特に以下の場合にチームを停滞させる調整・整合の課題を解決するのに役立ちます:
- ジャーニーが 複数のタッチポイント やチームにまたがるが、エンドツーエンドの体験を所有する人がいない。
- Service Design がエンドツーエンドのジャーニーをマッピングし、ハンドオフ、ギャップ、誰がその場に必要かを特定できます
- 機能横断のステークホルダー アライメントが必要 だが、優先順位や理解に対立がある。
- Service Design は、共通言語を生み出す機能横断ワークショップで成果物の共有を通じてアライメントを促進します。
- デジタルソリューションだけでは問題が解決しない。例: プロダクト／機能の成功がオフラインのプロセスや人間によるタッチポイントにも依存する。
- Service Design は舞台裏で何が起こる必要があるかを明らかにし、サービス提供全体の設計を支援します。
- リサーチインサイトが チーム横断の戦略 に反映される必要がある
- Service Design は断片化したナレッジを戦略的成果物（例: ブループリント、体験ビジョン、未来のユースケース）に統合し、優先順位付けを導きます。
手法と成果物
Service Design の手法
効果的な Service Design はリサーチから始まります。明示的に言及していなくても、これらすべての手法は、ユーザー、ステークホルダー、システムからのエビデンスを共通理解に統合することに依存しています。
- ジャーニーマッピング: タッチポイントをまたぐユーザー視点のエンドツーエンド体験を視覚化
- サービスブループリンティング: 体験を提供するためのフロントステージ（ユーザー対面）とバックステージ（内部プロセス、システム、ポリシー）で起こることをマッピング
- ステークホルダーマッピング: サービスの提供に関与する、または影響を受けるすべての関係者とその関係を特定
- 体験ビジョン／フューチャーキャスティング: 理想的なサービス体験の理想像を作成し、チームの方向性を整合
- 共創ワークショップ: 機能横断チームを集めてインサイトを統合し、アイデアを生み出し、ソリューションについて整合させるセッションをファシリテーション
こちらは SD 手法を探索するのに良いリソースです。プロダクト開発プロセスのどこにいるかに応じて使えます。
典型的な成果物
- ジャーニーマップ（as-is、to-be）
- サービスブループリント
- ステークホルダーマップ／エコシステムマップ
- 体験ビジョン
- リサーチ統合（例: インサイトレポート、機会マップ、テーマ別サマリー）
GitLab での私たちのアプローチ
Service Design は GitLab の Experience Research の一部です。これは、リサーチが Service Design に不可欠であり、機能横断の体験とインサイトへのアクセスが Service Design のプラクティスとしての成否を決定づける要因だからです。同じ機能内に存在することで、Service Design は進行中のリサーチに直接アクセスでき、それらのインサイトを素早くシステムレベルの成果物に統合してチーム間の調整に使えます。これにより、実際のユーザーインサイトではなく仮定に基づくアライメント成果物を作成するという、よくある間違いを防ぎます。
現在のフォーカス領域
GitLab において Service Design を UX の一分野として確立する中で、私たちは共通の視点を構築するためのマインドセットの普及、プラクティスを確立するための機能横断のコラボレーション、そして即座に価値を加えるための Growth セクション への深堀りに注力しています。
- Growth: Growth セクションと協力してトライアル体験をマッピングし、異なるユーザータイプにとっての主要な価値モーメントの全体像を持ちます。戦略やデザインコンセプトに貢献します。
- 機能横断のコラボレーション: 異なる分野やチームとつながりを確立し、既存の基盤（ジャーニー、プロセス、顧客概要など）を再利用できるようにします。
- マインドセットの普及: PD、PM、UXR が Service Design マインドセットをさらに採用できるよう、Service Design をハンドブックに組み込み、ウォークインのオフィスアワーを提供し、SD 専用テンプレートを UX ツールキットに追加することでエンパワーします。
誰が何に取り組んでいるかは、Experience Research のハンドブックページを参照してください。
Service Design があなたのチームをどう支援するか
Service Design は、ユーザーに提供する価値が他のチームに依存している、ステークホルダーが整合していない、または構築前にエンドツーエンドで機能する戦略を検証する必要がある場合に役立ちます。
🔎 コミットする前に明確化
優先順位を決めているが、他のチームが構築しているものとどう適合するか、または本当の問題を解決するかが不明な場合、Service Design は次のように支援できます:
- as-is ジャーニーをマッピングして、ギャップ、重複、ユーザーが実際に苦労している箇所を明らかにする
- 新しいリサーチを始める前に既存のナレッジを表面化する
- 最もリスクの高い仮定の周りでリサーチをスコープする
得られるもの:
- プロダクトマネージャー: ロードマップにコミットする前に、仮定を検証し、問題空間をスコープできる
- プロダクトデザイナー: 機能がより広いユーザージャーニーにどう適合するかを見て、デザインの注意が必要なハンドオフを特定できる
- エンジニアリングマネージャー: スプリント計画前にシステム間とチーム間の依存関係を理解できる
💬 優先事項についてチームを整合
あなたのチーム、ピア、ステークホルダーが何を起こすべきかについて異なる理解を持ち、手戻りや見落とされた依存関係のリスクを抱えている場合、Service Design は次のように支援できます:
- 現在の状態と望ましい状態を全員に可視化する共有成果物（サービスブループリント、ストーリーボード、システムマップ）を作成
- リサーチ結果をロードマップ決定を支援する共有の体験ビジョンに変換
- 機能横断ワークショップをファシリテーションして、懸念を早期に表面化しアライメントを構築
得られるもの:
- プロダクトマネージャー: リサーチを、リーダーシップにロードマップ決定を正当化する明確なプロダクトビジョンに変換
- プロダクトデザイナー: デザイン意図を伝え、ステークホルダーの賛同を得るための成果物を共創
- エンジニアリングマネージャー: 技術的な依存関係を早期に表面化し、アーキテクチャとリソース配分を適切に計画
✨ 戦略的決定のデリスク
大きな賭け（新プロダクト領域、AI 機能、プラットフォームシフト）をしているが、エンドツーエンドの体験がうまく機能するか、正しいユーザーをターゲットにしているか自信がない場合、Service Design は次のように支援できます:
- ビジネス目標をソリューション設計に結びつける戦略的トピックのビジネスケースを構築
- 正しい顧客セグメント向けに解決していることを保証するユースケースとシナリオを作成
- タッチポイント全体にわたるプロトタイピングで、UI だけでなくサービスフロー全体を検証
得られるもの:
- プロダクトマネージャー: ユーザーニーズをビジネス目標と ROI に結びつけるシナリオでビジネスケースを強化
- プロダクトデザイナー: 実際のワークフローに対してコンセプトを検証し、すべてのタッチポイントにわたる一貫性を確保
- エンジニアリングマネージャー: アーキテクチャ決定がユーザー体験と運用に及ぼす下流影響を予測
Service Design を日常業務に取り入れる方法
あなたの役割で Service Design の帽子をかぶる
たとえ Service Designer でなくても、Service Design マインドセットを適用できます。以下は実践できる事柄です:
プロダクトマネージャーの場合、次の質問を頻繁にしてください:
- 自分が担当しているタッチポイントの前後で何が起こっているかについて、何を知っているか？
- [機能を追加する] がエンドツーエンドで機能するために、他に誰が関与する必要があるか？
- ユーザーのコンテキストについて、私たちはどんな仮定を置いているか？
プロダクトデザイナーの場合、次のことを頻繁に考えてください:
- 自分のデザインはユーザーのジャーニーの他の部分とどうつながるか？
- この体験を可能にするために、バックエンド／オフラインで何が起こる必要があるか？
- 私たちは望ましい体験を設計しているか、それとも今ある制約のために設計しているか？
GitLab で Service Design と協働する
Service Design の作業は、戦略的優先事項に基づき UX Research Manager が Service Designer と協力して優先順位付けします。週 2〜4 時間の継続的なサポートも提供したいと考えています:
- Slack: クイックなサポート／質問のため、#ux-research で自分の領域の Service Designerにタグ付けする
- Issues: 大きな取り組みについては、ミーティング／非同期ディスカッション後に Service Designer と合意の上で Issue を作成し、優先順位付けします
リソース
GitLab における Service Design を紹介する紹介スライドデッキと UX Forum の動画があります。さらに役立つ外部リソース:
このページにフィードバックを提供
提案やアイデアを共有するには、フィードバック Issue にコメントを残してください。ご意見をお待ちしています！
bfd74782)