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