UX Cloud Sandbox

UX リサーチ調査のテスト環境

User Experience (UX) チームは、Infrastructure チームがプロビジョニングした「サンドボックス」領域を使用して、ユーザビリティとワークフローをテストするためのリソースを開発しました。これにより、gitlab.com における重要なデータの損失やセキュリティ侵害のリスクなしに、実際の GitLab インスタンスで厳密に制御されたテストを実施できます。このページでは、サンドボックスへのアクセスに必要な手順と、サンドボックス内での調査の構成に関するガイドラインを説明します。

UX Cloud Sandbox とは？

UX Cloud Sandbox は、独自の「プライベート」空間で実行される GitLab の予約済みインスタンスです。本質的には、自己管理型クライアントのものと似た、完全に独立した GitLab のインストールとして機能します。その空間は現在、https://ux.gitlabdemo.cloud/にあります。

UX チームは、この空間をユーザビリティテスト、ワークフロー調査、ユーザビリティベンチマークに使用します。サンドボックスは 2 つの問題を解決します。1) 外部参加者がセキュリティやプライバシーに関する懸念を侵害せずに画面を共有できる安全な環境を作ること、2) gitlab.com では容易にアクセスできない Admin と Ultimate プランの機能をテストできるようにすることです。

次に関心がある場合は、UX Cloud Sandbox の使用を検討するとよいでしょう。

• 現在のワークフロー、JTBD、ユーザージャーニーマップなどの評価
• Admin 権限、Ultimate プランの機能、またはより複雑な機能（CI/CD パイプライン、脅威の監視など）を必要とするユーザー調査の実施
• 自己管理型のユーザー向けの調査の実施
• ユーザビリティベンチマーク調査の実施
• すでにプロダクトへリリースされたソリューションの検証
• 問題検証調査の実行

このインスタンスは毎週土曜日に自動アップグレードが予定されています。

UX Cloud Sandbox へのアクセス

UX Cloud Sandbox へのアクセスを取得する最初の手順は、認証情報を生成することです。このハンドブックページの「Access Shared Omnibus Instances」にある手順に従うことで、セルフサービスで実行できます。

認証情報を生成してサンドボックスインスタンスにアクセスすると、自分の名前の付いたグループ空間が自動的に付与されます（下の画像を参照）。このグループは GitLab の他のグループと同様ですが、自分の名前が付いており、サンドボックスで行うすべての作業のコンテナとして機能します。

調査の構成

繰り返しますが、行うすべてのことは自分のグループ内で行う必要があります。 自分のグループには名前が付いており、すべての作業の「ルート」にあります。この構造を維持するため、共有インスタンスで他のトップレベルグループ（自分の名前のグループと同じレベル）は作成しないようにしてください。

グループ内では、サブグループとプロジェクトを自由に構成できます。これを考えるよい方法の 1 つはファイルシステムです。グループは「フォルダー」、プロジェクトは「ファイル」です。構造は次のようになる場合があります。

グループ／サブグループ構造を調整する必要がある場合は、次の手順でサブグループを移動できます。

1. 変更したいグループページに移動します。
2. Settings -> General に移動します。
3. Advanced セクションで Transfer group を見つけます。
4. Select parent group ドロップダウンを使用して、このグループを配置したい親グループを見つけます
5. Transfer group をクリックします。
6. 編集したグループが、ドロップダウンで選択したフォルダー／親グループのサブグループになっているはずです。（注: これは再帰的であるため、移動するグループの下にあるものもすべて移動します）

サンプルデータを含むプロジェクトの作成

グループまたはプロジェクト内でサンプルデータを生成したい理由はいくつかあります。これらのプロジェクトはデフォルトでは空であり、空のプロジェクトでユーザー行動をテストしても正確でも現実的でもありません。プロジェクト全体のサンプルデータを手作業で作るのは時間がかかり面倒な場合があるため、Ruby スクリプトを通じてプロジェクトにサンプルデータを投入するいくつかの選択肢を作成しました。

注: すべての種類のデータを生成できるわけではなく、特により複雑な設定ではそうです。可能なことと不可能なことを把握するには、GitLab Ruby gem のドキュメントを確認してください。

質問やトラブルシューティングについては、Slack で @leducmills に連絡してください。

選択肢 1: GDK があり、軽微なコード編集に慣れている場合

注: 既存のプロジェクトにサンプルデータを投入するよりも、プロジェクトを作成してサンプルデータを投入するほうが簡単です。ただし、問題なければ以下にリンクしたサンプルデータの Ruby スクリプトを編集できます。

1. サンプルデータスクリプトリポジトリに移動します。このプロジェクトには、異なる種類のデータをどのように投入できるかを示す複数の Ruby スクリプトがあります。必要に応じてアクセスをリクエストしてください。
2. ローカルのマシンにクローンします（GDK ディレクトリ内ではありません）。
3. まだインストールしていない場合は、‘Faker’ Ruby gemをインストールします。 $ gem install gitlab faker
4. ローカルの GDK インスタンスから、API スコープを持つアクセストークンを作成します（まだ持っていない場合）。
5. 異なる Ruby スクリプトを確認し、ユースケースに最も近いものを新しいファイルにコピーします。
6. スクリプトの先頭にローカルエンドポイントとアクセストークンを追加します。

#this sets up our connection to our gitlab instance
client = Gitlab.client(
    endpoint: 'Add the endpoint URL here',
    private_token: 'Add your token here'
)

1. Ruby ファイル内の # Global Variables for instance setup というセクションを見つけます（おそらく 95 行目あたりです）。
2. 要件に合わせて変数を変更します（例えば、必要な Issue、ラベル、ブランチなどの数）。
3. ターミナルからファイルを実行します: ruby your_file_name.rb。ステータスを知らせる複数のメッセージがターミナルに表示されます。スクリプトが停止したら、データ作成は完了です。
4. ローカルインスタンスで結果を確認します。結果に満足したら、Settings に移動してプロジェクトをエクスポートします。
5. UX Cloud Sandbox に戻り、プロジェクト用ディレクトリに新しいプロジェクトを作成し、選択肢から Import project を選択して、ローカルプロジェクトからエクスポートしたファイルを選択します。
6. アップロードしたプロジェクトを確認し、期待するデータが存在し正しいことを確認します。注意: すべてのデータがエクスポートされるわけではありません。

すべてが適切に機能していれば、すべてのサンプルデータがそのままの状態で、インポートしたプロジェクトがサンドボックス内に表示されます。

重要: プロジェクトのフォークは、プロジェクトを新しい空間にコピーする（または「セッション」プロジェクトを作成する）最も迅速な方法です。ただし、マージリクエスト、ラベル、Issue などのデータはコピーされません。一方、ブランチ、コミット、ファイル、コミットメッセージはコピーされるため、それだけが必要ならフォークしてください。

MR、Issue、ラベルのデータが必要な場合は、新しいプロジェクトを作成し、インポートを選択し、gitlab export からインポートして、アップロードごとに .tar.gz ファイルを選択するというインポートプロセスを、実施したいセッションごとに繰り返す必要があります。

選択肢 2: サンプルデータをリクエストする

サンプルデータを含むプロジェクトを作成してほしい場合は、「Sample Data Request」テンプレートを使用して、新しい UX Research Issueを作成してください。注: Issue を開く前にプロジェクトを作成しないほうがチームにとって簡単です。プロジェクトを同時に作成してデータを投入しやすくなるためです。

これらのプロジェクト作成のリクエストを満たすには、次の情報が必要です。

• グループと調査の名前（例: Q1FY23 Create Stage Benchmarking）
• 調査を実施する日付
• 必要なプロジェクトとサブグループの数
• プロジェクトに必要な次の各項目の数:
  • ラベル
  • マイルストーン
  • Issue
  • ブランチ
  • ファイル
  • マージリクエスト（ブランチごとに 1 件まで）
• 上記データタイプに特定の名前または値があれば記載（例: 「staging」という名前のブランチ）
• 有効化する必要があるフィーチャーフラグ（本番にリリース済みのものだけが利用可能であることに注意してください）

さまざまなコンテンツタイプのデフォルト例は、このサンプルプロジェクトで確認できます。

テストプロジェクトを作成してリサーチサンドボックスにインポートする場合、次の項目はエクスポートされないことに注意してください。

• Job ログとアーティファクト
• コンテナレジストリイメージ
• CI 変数
• パイプライントリガー
• Webhook
• 暗号化されたトークン

スクリプトを通じてユーザーとユーザー認証情報を作成できますが、サンドボックスが偽のユーザーアカウントで肥大化することを避けたいため、一般に推奨しません。幸い、UX Research チームには、使用できるテスト専用のユーザーアカウントがあります。

テストユーザーアカウントへのアクセス

サンドボックスにログインしたら、User Test Accounts というグループに移動します。そのグループには testing accounts という名前のプロジェクトがあります。このプロジェクトの main ブランチには、accounts.md というファイルがあります。このファイルには、すべてのユーザーテストアカウントの認証情報と、必要に応じてさらにアカウントを作成する方法の手順が含まれています。

調査でテストアカウントを使用する場合、環境を保護するため、参加者のセッションごとにパスワードを変更する責任があります。 最後に更新したパスワード（最後のユーザーの後）は、次の人が使用できるよう accounts.md ファイルに記録する必要があります。

すべきこととすべきでないこと

すべきこと:

• 調査の構成セクションに示したガイドラインに従って空間を整理します。つまり、適切な命名規則で正しい場所に調査を配置します。
• 後片付けをします。使用しない、誤って作成した、古くなった調査やプロジェクトなどを削除します。
• 参加者ごとに、使用しているテストアカウントのパスワードを変更することを忘れないでください。これはサンドボックス上のデータの安全性と正確性を維持するために重要です。

すべきでないこと:

• 何をしているかを絶対に確信している場合を除き、プロジェクト、調査、設定を操作しないでください。疑問がある場合は、ux_research Slack チャンネルに投稿するか、Slack で @leducmills に直接連絡してください。
• 他人の後片付けをしないでください。現在誰も使用しておらず、将来もアクセスする必要がないと確信できる場合を除き、他のプロジェクトを削除または移動しないでください。

FAQ

Q: ユーザビリティ調査で参加者ごとに異なるパスワードを使用できるよう、UX サンドボックスでユーザーパスワードを変更するにはどうすればよいですか？

A: この動画に示されている、ユーザープロフィールでパスワードを変更する手順に従ってください

Q: モデレーターなしのユーザビリティテストに UX サンドボックスを使用することは可能ですか？可能な場合、どのようにしますか？

A: はい！サンプルプロジェクトと、正しい権限を設定したテストアカウントを用意したら、UserTesting を使用して各テストを 1 件ずつ実行できます。ユーザーのログイン認証情報と UX サンドボックス環境へのリンクを必ず含めてください。テストが完了したら、テストプロジェクトに必要な更新を行い、テストユーザーのパスワードを更新して、最後にテストスクリプト内のログイン認証情報を更新します。調査の目標参加者数に達するまで、これらの手順を続けてください。

ページのソースコードを見る - ページの編集 - please contribute.