User Experience Design in Product Ownership （プロダクト・オーナーシップにおけるユーザエクスペリエンス・デザイン）
AgileUX のパイオニアである Jeff Patton 氏が弊社にて2日間に渡る「Product Ownership Training（プロダクト・オーナーシップ研修）」を開講してくださいました。アジャイル開発を推進するための目的として開催されましたが、プロダクト・オーナーシップ・チームを対象としたセッションということでユーザエクスペリエンス・デザイナーとして参加してまいりました。
アジャイルは、昨年開催された Web Director's Meetup というイベントでも「アジャイルときどきUX」として発表したことがあり馴染みはありましたが、この研修ではデベロッパー観点からの Agile Experience Design を突きつけられたような衝撃を受け、今後のユーザエクスペリエンス・デザイナーとしての立ち振る舞いに少し焦りが生じ始めました。Jeff Patton 氏も元々は純粋なソフトウェア・デベロッパーではありますが、User-Centered Design（ユーザ中心設計）をはじめ Design Thinking（デザイン思考）や Lean Startup（リーン・スタートアップ）などのエッセンスをアジャイル開発に取り入れ、独自の進化を遂げてきた様子が伺えます。
Jeff Patton 氏が定義する、アジャイル開発には3つの特徴がありました。この研修では、それぞれの「価値」を実感できるように様々なエクササイズや演習が盛り込まれていました。
Agile Values（アジャイルの価値）
- Focus on building shared understanding（ビジネスが直面している課題、解決するための戦略、該当のサービスまたはプロダクトを利用しているユーザをチーム全員が理解すること）
- Leverage collaboration to share ownership（チーム全員がアクティビティに参加することで当事者意識をメンバー内で共有すること）
- Emphasize working software（共通のソフトウェア、ツールを利用することによって課題の特定を容易にすること）
Product Centricity（プロダクト中心）
- Product Centric organisation places more emphasis on product success measurements（成功するプロダクトを目指し、費用対効果、顧客満足度、事業利益などにフォーカスをあてること）
Design Thinking（デザイン思考）
- Design thinking is a way of approaching problem solving. It requires a bit more rigor than approaches that rely on pure intuition.（問題解決アプローチを可能にするデザイン思考を取り入れ、分析からデザインまでユーザのコンテキストに従ったデザインをすること）
- Problem identification（課題特定）
- Ideation: Identify many possible solutions（アイディア発想）
- Iteration: Evaluate and refine and repeat（評価の繰り返し）
- Solution development planning（開発計画立案）
プロダクト・オーナーシップ研修と題されているとおり、この研修ではプロダクト・オーナーシップ・チームを構成するメンバー要員によってグループ分けされています。プロダクトマネージャー1名、リードエンジニア含めエンジニア2名、そしてユーザエクスペリエンス・デザイナー1名の計4名から5名によってチームが組まれています。また、実際のアジャイル開発ではプロダクト・オーナーシップ・チームに加え、スクラムを組むエンジニアとUIデザイナーによって構成されるデリバリー・チームの2つにグループ分けすることを推奨されていました。プロダクトマネージャーはともかく、リードエンジニアはデベロッパーとして対象となるサービスまたはプロダクトのオーナーシップ（当事者意識）に則ってチームにコミットしているため、オーナーシップのチームにジョインすることへの理解はできます。では一方で、ユーザエクスペリエンス・デザイナーはどうでしょう。
Jeff Patton 氏が提唱するアジャイル開発では、プロダクトマネージャーはビジネスにとって価値のあるサービスまたはプロダクト（Valuable）を実現することをミッションとし、リードエンジニアはその理想に近づけていくために技術的観点からの実現可能性を検証・計画すること（Feasible）にフォーカスをあてています。ユーザーエクスペリエンス・デザイナーは対象のプロダクトのユーザビリティ面を担うプロフェッショナル（Usable）として位置づけられているため、本来我々が担うべきユーザエクスペリエンスの改善や向上にはなかなかコミットしにくい環境にあるのではないかという懸念を抱いています。
ISO 92401-210 でも定められているとおり、ユーザエクスペリエンスはユーザ中心設計が達成すべき目標として位置づけられているため、ユーザ中心設計のエッセンスを注入、導入することを我々（少なくとも私）の存在意義として謳ってきました。ところが、アジャイルはメンバーが誰でも役職や責任範囲を超えて平等にコミットできるようにと仕組みづくられているため、本質的にはロールの仕分けなどはあまり存在しません。そのため、以下のアジャイル開発の原則を眺めていてもわかるとおり、アジャイル開発には既にユーザ中心設計のエッセンスが盛り込まれています。
Agile Principles（アジャイル原則）
- Good products are intentional（良いデザインは意図的につくられている）
- Design is a collaborative decision making process（デザインはコラボレーションしながら意思決定を進めていくプロセスである）
- Understanding and describing the problem context is essential（特定するだけではなく、直面している課題を表現することが重要である）
- Better solutions come from ideation – considering multiple diverse ideas（より良いソリューションはアイディえーションなど、複数の発送法を用いて導き出される）
- Solutions are hypothetical until proven through success after delivery（ソリューションはマーケット・インするまで仮説に過ぎない）
- Risk is a function to time to solution validation（リスクは時間によって特定・検証されていくものである）
- Ultimately the quality of a product is subjective（プロダクトの品質は主観的である）
- Great products emerge from aligned collaborative teams of individuals（素晴らしいプロダクトは協力的なチームによって生み出される）
ユーザ中心設計のメリットはチームのメンバーが共通のユーザに着眼点を置くことでビジネスとデベロッパー間の共通言語として確立させることでありますが、デベロッパーサイドからも同様の発想からビジネスサイドにアプローチすることは想定できたといえば想定できました。かつ、体制面における環境が個々によって異なるため必ずしもこのステートメントが全部にあてはまるとは思っていませんが、ユーザ中心設計アプローチは中立性を維持しなければいけない故、冒頭のオーナーシップにはあてはまりにくいことも事実かと思います。この環境下では我々は Usable を担保する要員として、プロダクト・オーナーシップからは少し離れたUIデザイナーとして立ち振舞うことを余儀なくされてしまいます。
Jeff Patton 氏が紹介した「ユーザストーリーマッピング」は XP（エクストリーム・プログラミング）から生まれた発想です。ユーザエクスペリエンスのモデリング手法として、対象とするユーザ、ユーザの行動とタスク、各種タッチポイント、ユーザのゴール、ユーザが満足または躊躇するポイントをマッピングしていく作業は「ユーザエクスペリエンス・ジャーニーマップ」に通ずるところがあります。
加えて、プロダクトの可能性を広げながらも解決しなければいけない正しい課題を特定するために「Assessing Product Opportunities（プロダクトの可能性を査定する）」をプロジェクトの冒頭でチーム・ビルディングも兼ねて取り入れることを推奨されていました。お気づきかもしれませんが、これらの設問から得られるインサイトは、「Business Model Canvas（ビジネス・モデル・キャンバス）」で網羅されている内容に等しいです。
- Exactly what problem will this solve? （ずばりどのような課題を解決しますか？value proposition）
- For whom do we solve that problem? （誰のためにその課題を解決しますか？target market）
- How big is the opportunity? （可能性はどれくらいありますか？market size）
- What alternatives are out there? （他に代案は存在していますか？competitive landscape）
- Why are we best suited to pursue this? （他と比較して我々が優れているのはなぜですか？our differentiator）
- Why now? （なぜ今なのですか？market window）
- How will we get this product to market? （どのようにマーケットに投入しますか？go-to-market strategy）
- How will we measure success/make money from this product? （どのように対象のプロダクトの成功や収益性を計測しますか？metrics/revenue strategy）
- What factors are critical to success? （成功するためには何が必要ですか？solution requirements）
- Given the above, what’s the recommendation? （上記を踏まえて、いま何を実施すべきですか？go or no-go）
デザイン思考のフレームワークに従い、ユーザ中心設計の各種技法をミニマムに取り入れ、スクラムを組みながら開発の効率性を実現し、リーン・スタートアップに見習った MVP（最小限持続可能性）を特定後、イテレーションを繰り返しながら評価と改善を促しリリースする。これが正に Jeff Patton 氏が提唱する理想のアジャイル開発（もはや開発ではないかもしれません）であり、私個人も昇華させていきたい「Agile Experience Design」だと思います。ユーザエクスペリエンス・デザイナーとしてできることとしてはユーザのプロファイリングからユーザからのインサイト（視座）を如何に効率よくチームにインプットをするか、如何にユーザビリティ上の観点から品質の高いプロダクトを目指せるのか、の2点に全力を注げるに他ならないのではないでしょうか。
年初に参加したアメリカはニューヨークにて開催された「AgileUX NYC 2012」でも同じような問題提起がありました。AgileUX NYC はユーザエクスペリエンスの改善や向上に携わる責任者の集まりによって開催されたイベントではありますが、彼らも「We(UX) must adapt to Agile（我々がアジャイルに適応すべきである）」と口を揃えて締めくくりました。逆に我々のようなポジションが不在になることで、ユーザエクスペリエン・デザインの重要性を実感していただくチャンスかもしれません。同時に、我々もアジャイルの知識をより深めていく必要がありそうです。
