要求の焦点、あるいはUX的なアプローチをいつ使うべきか

ソフトウェア開発の企画や要件定義といった工程で、UX(ユーザエクスペリエンス)あるいはUCD(ユーザ中心設計)のアプローチを用いることが話題となっている。Apple製品などを引合いに出して、競争力の高いソフトウェアを検討することは場合によっては重要かもしれないけれど、使い所の判断は必要だと思う。なお、本エントリについてはわたしの不勉強によりUXやUCDについて誤りがある可能性がある(自信が無い)ので注意。

要求の焦点がどこにあるのか

要求の焦点というのはわたしが勝手に作った造語で、ソフトウェア要求の中心点をイメージしている。ソフトウェア開発のプロジェクトを始めた段階では、「何を作るのか」がぼやけた状態だけれども、検討を進めていくとだんだんと焦点が当たってきて、凸レンズで光を集めるように、次第に像がはっきりとしていく。

この焦点が、組織のうちにあるのか外にあるのかで、ソフトウェア開発の企画や要件定義のアプローチは変わってくると思う。焦点が組織のうちにある場合は、UXのようなアプローチではなく要求工学知識体系(REBOK)や要求開発のプロセスを適用したほうが良いと思う。利害関係者がはっきりとしており、プロジェクトに関する暗黙知・形式知の多くが組織内に存在するからだ。企画や要件定義の成否はたとえば「網羅性」とか「優れた合意形成」などにかかっていて、あまりUXの出てくる出番は無いような気がする。逆に、無理にUXを推進していくのは手段と目的が逆転している印象もある。

(もちろん、ユーザビリティに関する非機能要求を検討することは大事だけれども、UX的なアプローチをとらなければいけないということは無いと思う。ユーザビリティを向上させなければいけない背景や要求があれば、そこから詳細化していくプロセスで充分に要求は明確化できると思う)

逆に、焦点が組織のそとにある(顧客側にある)場合は、プロジェクトに関する暗黙知・形式知の多くが組織の中に無く、かつ重要な利害関係者である顧客そのものに直接アクセスすることが難しいためにUXのアプローチはとても有効だと思う(むしろ、要求工学知識体系(REBOK)や要求開発のプロセスは害になると思う)。「仮説と検証」とか「マーケティング」がプロジェクトの成否のポイントであって、網羅的に検討をしても適切なアウトプットは出せないだろう。

なお、明らかに要求の焦点が企業内にあるようなケースでも、UXのアプローチを取るという話は時々聞く。でも実際にやっている事は新たなテクノロジーやデバイスの使い方に関するものだったりする。この場合は(あくまで私見として)やっぱりUXアプローチは冗長だと思う。最近は消費者市場で新しいデバイスやテクノロジーが生まれており、これを企業内に取り込むいわゆるコンシューマライゼーションという流れはある。しかし、あくまで企業内で検討するのであれば、全ての利害関係者に直接アプローチすることは充分に可能なので、「網羅性」とか「優れた合意形成」重視の従来の検討方法論でもいいのじゃないだろうか。