User Experience

シンプルなものはシンプルであるべきだし、複雑なものは可能であるべきだ

– Alan Kay

ユーザーエクスペリエンス(UX)の概要

使いやすさ、可用性、人-マシンのインターフェースの効率性といったシステムの側面をユーザーの視点で見ることはユーザーエクスペリエンス(UX)である。ユーザーエクスペリエンスの設計は、エンドユーザーの必要なもの、価値のあるものに対する深い理解を反映したシステムの構築に重点を置く。また、エンドユーザーの能力と限界に対する理解もシステム構築に反映する。

アジャイルにおける共通のチャレンジとして、素早い反復サイクルにどのようにしてビジュアルデザイン、ナビゲーション及びユーザーインタフェース(UI)要素といったユーザーエクスペリエンス(UX)を組み込むかというものがある。インクリメンタルな納品物の開発やテストと同時に複雑なユーザーとのやり取りの解決をチームが試みると、多くの反復にわたる「混乱」に陥ることも多いだろう。これはアジャイルプロセスに対する不満の源となる可能性がある。ユーザーエクスペリエンステスティングの必要に迫られると、UX/UIの実装はさらにややこしくなる。ユーザーエクスペリエンステストの実行は、通常新機能の完了も試みている1回の反復内に収めることはできない。結果は今後の反復に影響を与える遅延したフィードバックとなり、生産性を低下させ、納品に対する遅れをもたらす。

幸いなことに、アジャイルチームは、これらの重要な設計要素に対応するためのプラクティスを多く見出している。対処方法は以下を含む:1.システムのためのアーキテクチャー滑走路の一部として、UX設計はちょっとだけ早めに開始する、2.設計ガイダンスを集中し、実装はしない、3.迅速なユーザーフィードバックを通じ、不確実性とリスクを取り除くため、反復と動作するコードを活用する。

詳細

役割の概要

SAFeでは、アジャイルチームはユーザーインタフェース(UI)要素を含むソリューションの実装に責任を持つ。しかしながら、大規模ソリューションにおいて、コンポーネントとシステムを渡る一貫性のあるユーザーエクスペリエンスを提供するため、通常、ユーザーエクスペリエンス設計者はアジャイルリリース列車 (ART)に専属する。新しいプログラムインクリメント機能に共通のガイダンスを提供するために、一般的に、この役割は少し早めに作業を開始し、必要な設計ガイドライン、ワイヤフレーム、スタイルシート、アーキテクチャー滑走路の一部とする他の成果物を準備しなければならない。

責務

UX設計者は通常以下の責務を持つ:

  • ユーザー-システム間のやり取りの裏にある特定のビジネス目標を理解するために、利害関係者と一緒に作業をする
  • ジャストインタイムで(十分適時に)、次のインクリメント向けのUI設計、UXガイドライン及び設計要素をアジャイルチームに提供する
  • ユーザーエクスペリエンステストを通じ、ユーザーエクスペリエンスを継続的に検証する
  • リアルタイムUX検証、フィードバック、データ追跡などのために、システムとソリューションアーキテクト/エンジニアリングやチームと一緒に作業し、技術的な基礎を構築と維持する。
  • プログラムを渡り、UXガイドラインを共有する。よいUI設計を維持するためのベストプラクティスに関して、開発者を教育する。
  • UXテストとテスト自動化について、テストエンジニアとシステムチームを支援する
  • UI設計ワークショップやUX/UIの専門技能コミュニティをリードする
  • 重要なUI関係の作業に関連する反復計画、バックログの手入れ、システムデモ、及びソリューションデモを参加する

アジャイルにおけるUX設計

事前大きな設計(BUFD)を取り除く、アジャイルにおけるUX設計のフローがある程度異なって、通常以下の特徴がある:

  • 将来の実装に向けた滑走路を開発するため、忠実度の低いプロトタイピングを利用する
  • 極度にインクリメンタルに行う
  • 素早いコードの実装を介して、迅速かつ頻繁なフィードバックに依存する
  • ユーザーとチームは高度な協調性を持つ
  • UX調査活動のためにイネイブラーストーリー(スパイク)を利用する
  • UI基準は「完了の定義」 (リリースページにある「Doneの定義をスケールアップする」をご参照)と「ユーザーストーリー受け入れ基準」に含まれる

システム設計とテストに関連するUX

効果的なUX設計プロセスと迅速かつ信頼性のあるUI実装を可能にするため、下記の設計基準は重要である:

  • 明確なUIとアプリケーションロジックの分離
  • 効果的なUIコーディング規約
  • 効果的なUI資産の編成、再利用の容易さ及びスタイルの拡張性と修正可能性
  • 利用統計データの収集、UIエラーログの取得及びフィードバックのメカニズムに対するサポート

ほとんどのUXガイドラインと要求が直接にテスト可能である。一部は他の機能テストと比べ、簡単に自動化できる。(例えば:1つ簡単なテストスクリプトは「すべての画面上に水平のメニューを利用する」をチェックすることができる。これによって、開発者は誤ってこの基準から逸脱することを防ぐことができる。)

アジャイルリリース列車におけるUX設計者

数多くのシステム要素はなんらかの形でユーザーとやり取りするので、適切なUX設計は、特に大規模なシステムや複数のシステムからなるシステムにおいて、よいソフトウェアとシステムエンジニアリングの他の側面と比べ、同様に重要である。デバイスのUX設計(外観の美しさ、形、大きさ、主さを含む)も重要な要素である。これはUX設計者とプログラムの他の部分との協調に影響を与える。一般的に下記の2つの組織モデルがある。

集中されたUXガイダンスと実装

アジャイルチームへの権限委譲とベロシティーという観点からは魅力的に思えるかもしれないが、完全に分散したUX開発はチームにとって実際には非常に問題になりかねない。複数のチームに基づくUI設計アプローチはユーザーにとってはよくない。このことに対応するために、組織によっては開発チームと独立に反復する中央ユーザーインタフェース設計チームを作る(図1に示す)。

Figure 1. Centralized User Experience development
図1.集中されたUX開発

これらのチームは共通のリズムと反復モデルを実行するが、これらのチームのバックログにはユーザーエクスペリエンスイネイブラーストーリースパイク、テスティング、プロトタイピング、及び共通のユーザーエクスペリエンスの定義に使われる実装作業が含まれるだろう。

分散され、統制されたUX開発

この場合、中央チームが開発チームのボトルネックになることもありえるし、大規模だと対処すべき依存性が増えるので、問題はさらに大きくなる。この問題を軽減するために、より大きなシステムではハイブリッドモデルが効果的に適用できるようである。図2に示す。

Figure 2. Distributed, governed User Experience development
分散され、統制されたUX開発

「分散しているが、統制された」モデルでは、小さく、集中したUX設計チーム(あるいは個人)を作り、そこが基本の設計アプローチと各UIに対する予備的なモックアップ(あるいはプロトタイプ)を提供し、チームは実際の実装を行う。この場合、UX実装スキルはチームに分散するが、集中した設計専門家がウェアフレーム、スタイルシート、ブランド制御、ガイダンス、モックアップ、物理的なハードウェアプロトタイプ、ユーザビリティーガイドライン、及びソリューション全体を横断してUXに概念的な統一性をもたらす他の成果物を提供する。このUX設計チームは、チームデモとシステムデモにも参加し、全体的なシステム設計がどのように進行しているかを見守る。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 7. (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

Last update 15 October 2015