navigating-design-jira-process

プロダクトおよびデザインの Jira プロセスについて

このスキルでは、エンジニアリングの Jira ワークフローに組み込むための、デザインチームの現在の実践に沿って Jira 上の作業を進めます。目標は、並行するデザイン用トラッカーを管理することなく、エンジニアリング作業と並べてデザイン上の意思決定を見える状態にすることです。デザインは関連するエンジニアリングチケットに直接添付し、実質的な内容（30/60/90 の批評イテレーション、コピー、注釈）はすべて Figma に置きます。

以下のステータス名について。 Jira のステータスラベルは、Jira で使われている大文字・小文字の表記のまま記載しています。チケットのステータスを変更するときは、IN DESIGN、IN PROGRESS、DONE、DESIGN NEEDED、Ready for Dev をそのままコピーしてください。

構造上のルール

デザインはチケットに直接添付します。 Figma ファイルはエンジニアリング Epic の「Design」フィールドに置きます（単発のエンジニアリングストーリーの場合は、ストーリーの「Design」フィールドに置きます）。デザイン専用の並行プロジェクト、並行するデザイン用カンバン、ステージごとのデザインタスクはありません。

これが、デザインチームの Jira 運用をひとことで表したものです。それ以外はすべて、このルールに沿って進めるための調整です。

Epic 主導のフロー

初期設定

• PM は、作業中の各 Product Initiative ドキュメントに付随する Epic を少なくとも 1 つ作成します。
• PM は Epic を指定のデザイナーに割り当てます。

デザイン中

• デザイナー（または PM）が Epic を IN DESIGN に移動します。
• デザイナーは 30/60/90 の批評サイクルをFigma 内で進めます。ステージごとの Jira タスクは作成しません。ステージのイテレーション、添付資料（ステークホルダー向けプレゼンテーション、リサーチ）、イテレーションをまたぐフィードバックはすべて、作業とあわせて Figma ファイルに置きます。

デザイン完了

• Figma で、ストーリーレベルの各画面を示す名前付きセクションを作成し、最終デザインを 1 つのページにまとめます。
• デザイナーは Figma ファイルを Epic の「Design」フィールドにリンクします。
• デザイナーは Figma のセクションを 「Ready for Dev」 に設定します。
• エンジニアリングが作業に着手できることを示すため、EM が Epic を Ready for Dev に移動します。（一部のチームではこれを処理する自動化が導入されていますが、現時点では EM の責任として扱います。）

エンジニアリングの技術的な細分化

• エンジニアリングが技術的な細分化の際にストーリーを作成したら、デザイナー、PM、細分化を担当するエンジニアが一緒にストーリーを確認します。
• 各ストーリーについて、正しい Figma セクションがリンクされていること、またセクションの内容がそのストーリーだけを対象としていることを確認します。1 対 1 で対応させます。

進行中（および開発サポート）

• 開発開始時に、PM または EM が Epic を IN PROGRESS に移動します。
• PM/EM は [project name] - dev support というタイトルの開発サポートタスクを作成してプロジェクトのデザイナーに割り当て、デザインサポートが必要なすべてのエンジニアリングストーリーに「relates to」としてリンクします。（ほかのデザイン専用タスクの運用は終了しましたが、当面はこのルールを続けます。）
• このタスクにより、プロジェクトが開発に入ったことをデザイナーに知らせ、期間中に必要となる各種サポートをまとめて示します。
• 最後のエンジニアリングタスクが完了したら、開発サポートタスクも DONE にします。

単発のエンジニアリングストーリー

Epic に紐づかないストーリーもあります。UI Foundation チームではよく見られるケースです。この場合、フローはより短くなります。

• Epic の外でエンジニアリングストーリーが作成され、PM または EM がデザインサポートの必要性に気づきます。（または、UIF のコンポーネント改善に取り組むデザイナー自身がストーリーを作成します。）
• PM または EM がストーリーを DESIGN NEEDED に移動し、フィーチャーチームのデザイナーに割り当てます。
• デザイナーは Figma でデザイン作業を行います。デザイン専用タスクは作成しません。
• デザインが完了したら、デザイナーは次の操作を行います。
  1. Figma ファイルをストーリーの「Design」フィールドにリンクします。
  2. ストーリーの担当者から自分を外します。
  3. デザインの準備ができ、作業に着手できることをチケットにコメントします。

最後の 3 つのステップ（リンク、担当解除、コメント）は必須です。どれかを省略すると、ストーリーが誰かのキューに滞留したり、見えていても見つけてもらえなくなったりします。

他のスキルとの連携

• preparing-design-handoff. In Design の終わりに行う移行（Figma のリンク、セクションを Ready for Dev に設定、EM による Epic の移動）は、ハンドオフプロセスの前段階です。ハンドオフスキルはゲート／チェックリストであり、このスキルは正規のライフサイクルです。
• evolving-design-system-components. Component Library の作業では、Component Library ボードに Jira の課題が作成されます。これらも同じルール（デザインをチケットに添付）に従いますが、機能チームが所有するレシピでは、Component Library プロジェクトではなく機能チームのプロジェクトにストーリーが作成されます。この違いをデザイナーに明確に伝えてください。

よくある間違い

• Figma のセクションを「Ready for Dev」に設定し忘れる。 エンジニアが最終版を見つけられなくなります。これは Design Done の一部であり、省略できません。
• セクションとストーリーが対応していない。 エンジニアがストーリーを作成するとき、各ストーリーは、そのストーリーだけの内容を含む Figma セクションに対応させる必要があります。不一致があると、レビュー時に曖昧さが生じます。
• デザイン完了時に、単発のエンジニアリングストーリーが未完了のまま残る。 完了時には3つの手順すべてを実施する必要があります。Figma をストーリーの「Design」フィールドにリンクし、自分の担当を解除し、デザインの準備ができたことをコメントします。どれか1つでも欠けると、チケットの状態が曖昧になります。
• PM が開発サポートタスクを作成するのが遅すぎる、または作成しない。 Epic 上で開発サポートが確認できないと、デザイナーは予告なしに開発サポートを依頼されます。プロジェクトの Jira の状態を確認するときに、この不足を指摘してください。

出力形式

Jira プロセスを設定する、または作業を進めるよう依頼された場合：

1. プロジェクトの形態 — Epic 主導のプロジェクトか、単発のエンジニアリングストーリーか。
2. 現在の状態 — 存在する Jira エンティティ（Epic、ストーリー、開発サポートタスク）と、それぞれの現在のステータス。
3. 実施する移行 — 適用する具体的なステータス遷移と Figma リンクを、担当者（デザイナー、PM、EM）ごとに明記します。
4. Figma リンク — どこに何を添付するか（Epic の「Design」フィールド、ストーリーの「Design」フィールド）。
5. 注意点 — 上記のよくある間違いのうち、このプロジェクトに当てはまるもの。