アジャイルと"ユーザ中心設計"の調和

作者 Mike Bria , 翻訳者 吉田 英人 投稿日 2010年3月22日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

Delivering Value ,

ビジネス/ITアライメント ,

Agile ,

UX ,

エンタープライズアーキテクチャ

共有 |

原文(投稿日：2010/03/17)へのリンク

UX のスペシャリストである Anthony Colfelt 氏はアジャイルについて，それが単独では不完全なものであることを論証するとともに，ユーザ中心設計のアジャイルへの統合の可能性とあるべき姿に関して，詳細かつ興味深い検証を行っている。

ビジネス の要件定義支援という課題の解決手段として，果たしてアジャイルが適当であるのかどうか。Colfelt 氏の メッセージ はそれに疑問を呈するものだ。

アジャイルそれ自体は，状況の変化に柔軟に対応する手段として有効なものです。しかしアジャイルが，より大きな課題である「ビジネス自体が要件を定義できない」ということの解決手段として考案されたものであるか，という点には疑問が残ります。確かにアジャイルによって，開発チームがこの課題に対応するのは容易になります。しかしそれで問題が解決するわけではなく，ほとんどの場合には新たな問題が生み出されることになるのです。

氏は UX 的センスにおいて，アジャイルに不足していると考えられる６つの "地雷原(minefield)" について説明している。

• "地雷その１：設計の役割が不明確":
  “ビジネス関係者と開発者は，プロジェクトを通じて毎日，共同で作業しなければならない” というアジャイル主義の定理には，UX 設計者から見て，必要なスキルを持たない開発者に仕事が任せられてしまうのではないか，という不安要素があるのは事実だ。
• "地雷その２：要求収集プロセスが定義されていない":
  「製品ビジョンに関する戦略的アウトラインの設定」という非アジャイル的作業を嫌うあまり，"要求は空から魔法のように降ってくるものだ" という考え方を採用するアジャイルチームが少なくない。
• "地雷その３：開発費削減への圧力":
  [経費節約のために] UX 設計と実開発を同じイテレーションに組み込むことによって，ユーザにデザインアイデアを評価してもらう機会が失われ，どうしようもない設計を生み出す結果になる。もちろんアジャイルでは，実運用をユーザビリティテストとすることも可能ではある。しかしこのようなフィードバック対応は逆に多くの時間を必要として，期待に反して満足できない結果に終わるかも知れない。
• "地雷その４：“これで十分” にすることの誘惑":
  アジャイルが有効に機能していても(あるいはそのような時にこそ)，チームは　'製品への新たな機能の追加' よりも '既存の機能を改良するためのイテレーション' の方を優先する必要に直面する。Cofelt 氏の観察によると，

  エキサイティングな新機能の方を優先するがために，改訂作業が取り残されてしまうことがあまりに多すぎます。結果として，制約というものに無縁なほど機能満載の製品が出来上がることになるのです。

• "地雷その５：リスクのない[事前]概念検討時間の不足":
  ほとんどのアジャイルチームがプロジェクト初日からビルド作業を始めたり，それに非常に近いことをしている。事前の計画と設計のための "イテレータ０" を使用することもある。これで本当に十分なのか，Cofelt 氏は疑問を呈している - コード作業の前にラフスケッチをいくつか使って評価する方法と比べて，実開発の場でアイデアを試すようなアジャイル的アプローチの方が常に優れていると言えるのだろうか，と。
• "地雷その６：ブランドへのダメージ":
  (UX デザイン的アプローチを通じての) ロードテストをしていない機能を市場に出すことは，たとえそれがフィードバック収集を 意図したもの であっても，企業の一貫した開発能力に対する顧客の信頼を一瞬にして損ねる。これはブランド - 獲得することが難しく，一度失った後に取り戻すのはさらに難しい - に対するダメージとなる。

Colfelt 氏は，アジャイルそれ自身は "改良(refining)には有効である。[しかし]定義(defining)には向いていない"，という興味深い結論を出している。氏の主張によれば，アジャイルはそれだけで，"既存のプロダクトを次のレベルまで改良する" ためならば十分なものかも知れない。"しかし，特に何か新しいことを始めようとするとき"，最高の設計ソリューションに対する別々の視点を，フランケンシュタイン的に寄せ集めたような状況を回避するためには，いくつかのレベルでの計画が必要である。

伝統的/"典型的" な UCD プロセスについて説明する中で，氏はそれがプロダクト "戦略" に関する事前調査を包含している点について，読者の注目を求めている。(氏は後日，これを "コンセプトデザイン" として，その典型である iPod を引き合いに出しながら説明している。) 氏の主張の重要性は，たとえアジャイルメソッドを適用した場合にも損なわれることはない。さらに，このような事前検討を 阻んでいる のがアジャイルそのものだ，という言い方を意識的に回避する一方で，それがアジャイルにおける正しい行動として明確に推奨されているだろうか，と問いかけている。

Colfelt 氏の最終目標は，UCD の持つ "戦略的"/"概念"発見への視点とアジャイルの "改良" 能力とを結合する方法，あるべき姿への意識を高めることだ。

要するにこの２つを一体化するためには，それぞれのアプローチの独善的な特性を回避することが必要なのです。忘れないでください，アジャイルはコンセプトの定義や全体的な設計方針の面では何ら指標を与えてくれませんが，確立された設計方針と十分に検討された計画を実践するためには，本当に素晴らしい方法なのです。一方 UCD には，実装チームが問題に直面して別の設計ソリューションが必要になった場合など，現場での要請に応じられる柔軟性が求められます。そのためにはメッセージを伝えるのに必要なものだけをドキュメント化するようにして，可能であればそれを共有場所に配置しましょう。作業領域を横断するコラボレーション，顔と顔を突き合わせてのコミュニケーション，この２つは非常に重要なものだからです。また，設計チームが開発チームに先んじて sprint を実行することで，テストとイテレーションの十分な時間を確保できるようになります。これらの行動ルールが守られれば，２つのアプローチはともに，非常にうまく機能ことするでしょう。

強行突破の判断を下してしまう前に，Colfelt 氏のアーティクル全体を読む時間を確保した方がよいだろう。John Holland 氏の 関連アーティクル も確認しておいた方がよいかも知れない。これはアジャイル(Scrum)における UX 設計者の作業形態について扱ったもので，Colfelt 氏と同様に "戦略" をテーマとして議論しているが，開発チームとの対話やイテレーションレベルの活動とダイナミクスにより注目している。