Content last updated 2026-07-22

プロダクトデザインオペレーション

“Issue 管理、チーム運営、管理プロセスを含む、Product Designer および Product Design Manager 向けの運用ガイダンス。”

Product Design は、GitLab のフルスタックエクスペリエンス組織である Upstream Studios の一部です。上流に位置する戦略的パートナーとして、私たちは最初から計画に関与し、これらの運用プラクティスを使用して、プロダクト開発プロセス全体を通じてデザインが統合されるようにします。

デザインプロセス、協働プラクティス、クラフトに関するガイダンスについては、Product Designer のワークフローを参照してください。

Issue 管理

UX Issue のトリアージ

すべての Product Designer は、~UX、~Deferred UX、~UI polish のラベルが付けられた Issue をトリアージできます。自分がトリアージ担当でない場合でも、担当の PM と EM がフィードバックを求める際に含めるべきです。Issue をいつ解決すべきかを提案するには Priority ラベルを使用し、ユーザーへの影響を示すには Severity ラベルを使用してください。割り当てられたラベルについては、常に PM および EM と調整してください。

マイルストーン内の Issue のスケジューリング

戦略的パートナーシップとは、最初から計画に関与することを意味します。UX が必要な Deliverable のラベルが付いたすべての Issue は、キックオフまでに Product Designer に割り当てられます。Stretch のラベルが付いた Issue は、キックオフまでに割り当てられる場合と、そうでない場合があります。Workflow ラベルの使用方法の詳細については、GitLab Docsを参照してください。

スケジュールされた UX Issue をステージグループに伝える

チームのプランニング Issue に User Experience セクションを追加することを検討してください（例 1、例 2）。このセクションには、マイルストーンのアクティブなデザイン項目（リサーチプロジェクト、Deferred UX、UI polish、Pajamas コンポーネントなど）を含めることができます。Product Designer のプランニングとキャパシティについて詳しく学んでください。

プランニング Issue にデザインの問題を含めることで、デザインの取り組みが可視化され、workflow::problem validation、workflow::design、workflow::solution validation の段階でクロスファンクショナルな協働が促進されます。

主な利点:

月次プランニングディスカッションの一部にすることで、ステージグループ内で UX を擁護する
マイルストーンキックオフ時に Product Manager とプランニング Issue を使用する
現在のデザインとリサーチの取り組みを、顧客やカウンターパートに定期的に伝える
チームと Product Designer のキャパシティを共有する
デザインフェーズ中のカウンターパートとの早期協働を促進する

ワークフローラベル

Product Designer は、ワークフローラベルを使用して、Issue が開発ライフサイクルのどこにあるかを追跡します。これらのラベルは、検証、デザイン、実装フェーズに私たちが関与しているタイミングを示すことで、戦略的位置づけを維持するのに役立ちます。

Product Development Flow のラベル:

Issue は必要に応じてこれらのラベル間を移動します。すべてのラベルがすべての Issue に当てはまるわけではありません。

workflow::validation backlog
workflow::problem validation
workflow::design
workflow::solution validation
workflow::planning breakdown
workflow::scheduling
workflow::ready for development

ワークフローラベルの詳細については、Product Development Flowを参照してください。

特定のラベルを適用するタイミング:

workflow::planning breakdown: ソリューションを実装のために小さな Issue に分割する必要があります。提案したソリューションを PM と Engineering に説明して、関与を続けます
workflow::scheduling: ソリューションを PM および/または EM がスケジュールする必要があります。担当 Product Managerにメンションし、割り当てられたエンジニアと連絡を取ります
workflow::ready for development: Issue は現在のマイルストーンでの実装を意図しており、エンジニアはソリューションに納得しています

Build フェーズへの早すぎる移動の取り扱い:

デザインの DRI として、私たちは品質の線を守ります。Product Manager が、UX 基準を満たす前に Issue を Build フェーズに移動するよう依頼することがあります。そのような場合、フォローオン Issue を作成し、かつ/または Deferred UX ラベルを適用して、プロダクトが UX 要件を満たしておらず即座のイテレーションが必要であることを示します。

ソリューションの提供

Issue の説明を更新する

作業が完了し、フィードバックに対応したら、Issue の説明（SSOT）を「Solution」セクションで更新します。これは、何をどのように実施すべきかの参照点となるべきです。

デザインを含める

「Solution」セクションにデザインを追加します。小さなデザインの場合、モックアップで十分かもしれません。より詳細な変更では、Figma ファイルへのリンクを含めてください。

デザインハンドオフのチェックリストを使用する

デザインハンドオフのチェックリストに従って、すべてのデザイン仕様が文書化され、エンジニアが成功できる準備が整っていることを確認します。

協働ツールを活用する

Figma の協働ツールを活用して、チームからフィードバックを集め、ディスカッションを進めます。

新しい UX パラダイムを慎重に検討する

新しいパターンやパラダイムを提案する際:

新しいパターンが他の領域と一貫性がなくなるかを評価する
一貫性を維持するために他の領域を更新する必要があるかを判断する
新しいパターンがユーザーエクスペリエンスを大幅に改善するかを評価する
変更が必要な場合、コンポーネントライフサイクルのドキュメントに従う

フォロースルー

機能のスコープを縮小する

レビューをより簡単かつ効率的にするため、エンジニアに機能を複数のマージリクエストに分割するよう促す
部分的な変更をマージすることの UX への影響を考慮する。部分的な変更が UX に悪影響を及ぼす場合は、フィーチャーブランチまたはフラグを使用して、完全なスコープがまとめて出荷されるようにする

最終目標を伝える

ソリューションを小さな部分に分ける際は、開発の取り組みを整合させるために、チーム全体が最終的なデザイン目標を理解していることを確認します。

SSOT を維持する

Issue の説明を最新に保つ:

Issue の説明（SSOT）を、画像やデザイン作業へのリンクを含む、合意したすべての要素で更新する
SSOT を明確に保つため、古いコンテンツを削除またはアーカイブする
明白な変更については、判断を用いて、合意を待たずにSSOT を直接更新する

関与を続ける:

自分のプロダクト領域の Issue を購読し、定期的にレビューする
適切な優先順位付けを確実にするため、プランニングミーティングに積極的に貢献する
アクティブな Issue に割り当てられ、購読されたままにする
関連する MR をフォローし、発生する追加の UX 問題に対処する

デザインが確定した後のフォローアップ

Pajamas に影響する変更の場合

デザインシステムに影響する変更について:

新しい UI コンポーネント: GitLab Design で UX Pattern Issue を作成し、チェックリストに従う
ドキュメントの更新: Design System で Issue および/または MR を作成する
アプリケーションの更新: アプリケーションの影響を受ける領域を更新するための Issue を作成する
変更を周知する: #upstream-studios などの Slack チャンネルを通じて、チームに変更を通知する

変更がライブになった後

フィードバックを集める:

ソーシャルメディア、Slack、フォーラム、内部および外部のソースからのフィードバックに耳を傾ける
フィードバックを追跡し対処するための Issue を作成する

これらの運用プラクティスに従うことで、Upstream Studios の戦略的パートナーシップと高品質な提供へのコミットメントに沿った、効果的なコミュニケーション、協働、継続的改善を確保できます。

Manager の運用

チームメンバーの更新

Product Categories ページなどでチームメンバーがサポートしているプロダクト領域を更新する必要がある場合は、通常、次のページとプロジェクトを更新またはレビューする必要があります。すべての更新について、名前がチームページで使用されている名前と一致することを確認してください。

セクションレベルの更新:

www-gitlab-com プロジェクト > Repository > Files に移動する
data ディレクトリを選択する
下にスクロールして sections.yml ファイルをクリックする
任意のエディタータイプを選択する
更新する人を見つけ、変更を加え、コミット/MR を作成して、そこから MR プロセスに従う

グループレベルの更新:

www-gitlab-com プロジェクト > Repository > Files に移動する
data ディレクトリを選択する
下にスクロールして stages.yml ファイルをクリックする
任意のエディタータイプを選択する
更新する人を見つけ、変更を加え、コミット/MR を作成して、そこから MR プロセスに従う

チームメンバーの更新（UX MR Reviewer Roulette からの削除または追加など）:

www-gitlab-com プロジェクト > Repository > Files - Documentation に移動する
data/team_members/person/product ディレクトリに移動する
チームメンバーのファーストネームの頭文字に応じたアルファベットのフォルダを見つける
その人の .yml ファイルをクリックする
任意のエディタータイプを選択する
UX MR Reviewer Roulette ボットから削除する場合:
- projects: セクションの下にある gitlab: reviewer UX 行を削除する
- コミット/MR を作成して、そこから MR プロセスに従う
UX MR Reviewer Roulette ボットに追加する場合:
- チームメンバーが削除された元の MR を元に戻すか、上記の手順に従ってその人の .yml ファイルを再度見つける
- projects: セクションの下に gitlab: reviewer UX 行を戻す
- コミット/MR を作成して、そこから MR プロセスに従う

トリアージレポート:

triage-ops プロジェクトで、チームメンバーをトリアージレポートの受信対象に追加または削除する MR を開きます。編集するファイルは group_definition.yml です。

レトロスペクティブ:

GitLab team retrospective グループでチームメンバーのセクションとグループを見つけ、そこでチームメンバーを追加または削除します。この手順は、チームメンバーが機密 Issue を見られるようにするために必要です。

また、async-retrospectives の team.yml ファイルで、チームメンバーを追加または削除する MR を開いてください。

Growth & Development

Growth & Development のリクエストでチームメンバーと作業する際は、Growth and Development Benefit のガイドラインを参照してください。

人材評価

Product Design と Design System では、マネージャーと直属の部下の間で人材評価と成長に関する対話を促進するために、パフォーマンスファクターワークシート（🔒 内部限定）を活用しています。これらのワークシートは Google Sheets 形式で利用でき、年央および年末レビューのタブに加え、年間を通じた成果、強み、機会を一覧にするタブを含んでいます。

各チームメンバーには、会計年度の開始時に自身のワークシートを作成し、年間を通じてツールとして使用することを強く推奨します。

パフォーマンスファクターワークシートは、Workday 内の年末の全社人材評価プログラムを効率的に完了するために活用できます。

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)

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