プロダクトチーム

UXタスク管理の3つの方法

読了目安：3分

2016年7月5日公開

私はこれまで、仕事でこのような会話を何度も聞いてきました。

エンジニア：「UXチームが何をしているのか、全然わからないのですが。」
UX：「じゃあ、UX関連作業のチケットをJiraに追加しましょうか」
エンジニア：「えっ、こんなにたくさんあるんですか？一気にタスクのチケットが増えるので困ります。」
UX：「プロダクトチームさん、私は次に何をしておくのがいいでしょうか？」
プロダクト：「では、Googleドキュメントがあるので、見てもらえますか？」
エンジニア：「次はどうしよう？これは作業してもいいのかな？」

私はこんな状況を改善するため、チームが次の3つの方法を試すのを見てきました。

方法1：UX作業を別のシステムに保持する

プロダクトとUXのチームが、主要なチケットシステムの外で、デザインや調査のための複雑なToDoリストを管理する方法。

メリット：チケットシステムが「すっきりと整理された状態」に保たれます。

デメリット：UXチームが何に取り組んでいるのか誰も分からず、依存関係を確認できません。バックログが不明瞭なため、「全体像」を把握するのが難しくなります。

注：UX担当者にとって、自分の仕事のリズムを説明するのは難しいものです。彼らは定期的に今後の仕事を探し、調査、モックアップの作成や調整などを行うことでその仕事を「先回り」します。こうしたやり方は非常に属人的です。この作業を、デザイナーがTrello、Basecamp、Google ToDoリスト、付箋、ノートブックを使って管理しているのを見てきました。しかし、そうした作業は多くの場合、目に見えないため、評価されないことが課題です。

方法2：チケットシステムでUXの作業を個別のチケットとして追跡する

UXが取り組んでいる作業は、エンジニアリングの仕事と共に「進行中」と示される。

メリット：進行中の作業と現在のUXの負担が明確にわかります。

デメリット：チケットが乱雑になったり、増えすぎたりします。また、UXの作業はリリースサイクルと合わないこともよくあります。

注：ここで問題になるのが、デザイン作業自体はリリースするものではなく、また、エンジニアリング作業のフローと同じようにはいかないということです。そのため、スプリントが終わると、デジタルであれ物理的なものであれ、ボードがデザイン関連のチケットでごちゃごちゃになってしまいます。「リリース済み」ステータスになるのが理想的ですが、そこにも問題があります。このデザイン作業が顧客の消耗品やリリース可能な品目に関連していない限り、本当の「完了」にはなりません。この問題はユーザーストーリー全般に言えるという人もいるでしょう。機能的な役割（バックエンド/フロントエンドなど）に基づいてストーリーを分割すると、ストーリーの内容が希薄になり、依存関係を管理する作業が必要になります。

方法3：ユーザー中心のチケットに関連する作業としてUX関連作業を追跡する

UXチームの作業を、初期段階のバックログの確認からリリース/完了に至るまで、ユーザー中心のストーリーに紐付ける。

メリット：依存関係が明確に記述され、デザインと調査の「プル型」システムが実現し、ジャストインタイムの作業が促進され、ユーザーの目標を重視し続けることができます。

デメリット：サブタスクが必要になったり、特定のチケットに複数の担当者を割り当てなければならない可能性があります。このアプローチには、確固としたストーリーとストーリー分割の実践が必要です。

注：UXがエンジニアリングより前の、分析/デザイン/調査の段階でチケットに関与しているのであれば、その作業を文字通り「分析/デザイン/調査」と呼ぶのが妥当でしょう。これは、エンジニアリングアーキテクトやビジネスアナリストなどの仕事に似ています。LeanUXのような一部のモデルでは、先行作業を減らし、時差のあるスプリントアプローチを避けます。他のチームは、エンジニアリングに引き渡す前に、十分な事前計画とデザインを行っています。作業が開始されると、通常はQAやエンジニアリングのタスクとともに多くのデザインタスクが放棄され、これらがストーリーに残ります。

私は方法3が良いと思います。これが以下の点で最もバランスが取れていると思うからです。