第21章 製品仕様の検証
価値があって、使いやすくて、実現可能であるという確証を得る
ここまでのいくつかの章では、私が製品の検証作業などと呼んできたことについて説明してきた。製品の検証とは、製品仕様が、売れる商品となること間違いなし、との確証が得られている製品のプロフィールを描写しているのかどうかを検証することである。ただ、この検証では、実際にその製品を作り上げてユーザーに披露する、ということはやらない。
以前なら、製品仕様の検証にはえらく費用がかかった上に、やるのも難しかったので、自動車のように、組み立てや製造に莫大な費用がかかる製品以外ではやらないのが普通だった。でも、今となっては、ほとんどの種類の製品で、ずいぶん少ない費用で効果的なプロトタイプを作ったりシミュレーションをやったりすることができるようになっている。それなのに、プロトタイプの制作やシミュレーションをやらない製品開発チームにいまだに出くわすのだから、あきれてしまう。
製品開発チームがよくやるミスの中でも最大の間違いは、自分たちの製品仕様を過信してしまうことだ。もし変更が必要なら、ベータ版をテストしてから修正すればいいと考えて、どんどん開発を進めてしまうのである。でも、当然のことながら、ベータ版を出す時期というのは、大がかりな変更をやるには遅すぎる。こんなことでは、新製品としてリリースされるものが見当違いな代物となってしまうのは無理もない。
こんなことが起こらないようにするのが、プロダクトマネジャーの仕事である。大事なことは、自分を含む製品開発チーム全員に、チームのみんなに示した製品仕様が成功する製品のプロフィールになっているということを、プロダクトマネジャー自身とチーム全員が確認することだ。これは十分に可能なことだし、思っているほどコストもかからない。
最終的に製品仕様をエンジニアリングチームに渡す前にやるべきことは、3種類の重要な検証である。
フィージビリティ (実現可能性) の検証
まず問題になるのは、現時点で利用可能な技術と時間と資金でもって、その製品を作ることができるのかどうか、ということだ。これについては、チーム内のエンジニアやアーキテクトがしっかり首を突っ込んで、技術を調査し、どういうアプローチができるかを検討するべきである。どういう方向性を取るべきかの選択肢の中には、出口のないものもあるけれど、他の選択肢の中に実現可能なものがあってほしいものだ。
この製品開発に与えられた時間の中では克服できない、とエンジニアリングチームが判断するような障害があるなら、開発が進んでしまってから、つまり、時間とお金をつぎ込んでしまった後ではなくて、今、それを知ることが重要なのだ。
他の製品に比べて技術的なリスクが高い製品もある。でも、実現できるかどうかに大きなリスクがあるなら、早いうちに対処しておいてほしい。
ユーザビリティ (使いやすいかどうか) の検証
インタラクションデザイナーは、プロダクトマネジャーと緊密に連携しながら、ユーザーが製品の使い方を理解できるようにするには、製品の中でその機能をどうやって表現すればいいかと知恵を絞る。
ユーザビリティテストをやることで、これまで見落としていた製品要求が明らかになることも多いし、うまくいけば、当初考えていたほどには必要でもない製品要求が見つかることだってある。ユーザーエクスペリエンスをいいものに仕上げるまでには、こういうテストを何度もやるように段取りしなければならない。
プロトタイプを作る目的は、現実のユーザーでテストできる試作品を用意することである。ユーザビリティテストとは、対象としている顧客から製品についての貴重なコメントを得るための技術であり、また科学である。もちろん、プロダクトマネジャーやデザイナーは、プロトタイプを使うことで、多くのことを学ぶことができるというメリットもある。でも、対象としている顧客企業で実際に製品を使うことになる人の前にプロトタイプを持って行って、これを試してもらった上でフィードバックをもらえるということが、プロトタイプの何物にも代えられないメリットなのである。
ユーザビリティテストの目的から考えて、複雑なバックエンド処理については、間に合わせのものでまったく構わないことは覚えておいてほしい。大事なことは、あくまでもユーザーエクスペリエンスを評価することなのだから。
価値 (買いたいと思ってもらえるかどうか) の検証
最終的には、製品が開発可能であってユーザーにとって使いやすいものだ、ということを確かめるだけでは十分ではない。本当に重要なのは、ユーザーがこの製品の価値を認めてくれて、買いたいと思ってくれるかどうかなのだ。つまり、ユーザーと顧客が開発中の製品をどれだけ気に入ってくれて、どれだけ評価してくれるか、なのである。
この検証は、通常、ユーザビリティテストの作業の中で一緒にやることができ、検証に使うプロトタイプも同じでいい。ただ、ユーザビリティテストでは、ユーザーが必要な処理をするための操作方法を理解できるかどうかを確認するのに対して、価値の検証では、ユーザーがそれらの処理 (タスク) に関心があるのかどうか、そして、このプロトタイプがどれくらいうまく問題を解決できているかを確かめているのだ。
小規模の製品開発であれば、自分のアイデアを紙に書き出すだけで十分な場合もあるだろう。でも、ほとんどの製品開発、特に、ユーザーインターフェースが複雑だったり、新しい技術を使ったりする製品開発では、その製品が目的を満たすものかどうかを評価するためには、プロトタイプは絶対に必要である。
たいていの場合、プロトタイプというのは、最終的なウェブサイトやソフトウェアサービスの外観を示すものであるけれど、マウスのクリックで操作できるようなページ (画面) をあまり時間をかけずに組み合わせたものでしかない。でも、その他のある種の製品では、プロトタイプは、物理的な機器かもしれないし、機器とソフトウェアの組み合わせであるかもしれない。重要なのは、対象となる顧客とテストすることができて、彼らから有用なコメントをもらうことができるぐらいには、プロトタイプが現実の製品に近いものでなければならない、ということだ。
つい最近まで、ハイフィデリティプロトタイプ (製品の正式版が正確にイメージできる試作品で、私がこの本で説明しているもの) には、精度の低いプロトタイプ (紙に書かれた絵や図) に比べてどんなメリットがあるのかをめぐる議論があった。今となっては、この議論には意味がないと思う。というのは、ずいぶん少ない費用でハイフィデリティプロトタイプを作れるようになっている上、ハイフィデリティプロトタイプからは、より質の高いフィードバック得られるようになっているからだ。
かつては、プロトタイプを使うというアプローチをするには、大きな障害が 2つあった。1つは、プロトタイプを作る手頃なツールがなかったため、その作成にはかなりの時間がかかったことである。もう 1つの問題は、経営陣が無知で、プロトタイプと実際の製品の違いを理解してくれなかったことだ。そのような状況では、製品開発チームに対しては、正式版の製品のベースとしてプロトタイプを使い、実装の質が予想通りの結果になるようにしろ、という圧力がかけられる。
今では、非常に優れたプロタイプ作成用のツールが使えるため、エンジニアやデザイナーは、時間をかけずに (たいていは数時間か数日で)、非常に実用的なプロトタイプを作ることができる。そのプロトタイプは、この先できあがる製品を効果的に模倣することができるし、現実的なユーザーテストをするための土台となる。それに、今時の経営陣の多くは、家の縮尺模型を作るのが実際に家を建てるのとは違うように、シミュレーション用の試作品を作ることは実際の製品を作り上げることとはまったく違う作業である、と理解している。
このようにしてプロタイプを作ることは、製品の仕様を検証するための唯一の方法というわけではない。特に、インターネットサービスの開発であれば、簡単で効果的な検証の手法は他にもある。けれども、実際に開発を進めて製品を作ってしまう前に製品のアイデアを検証することが、どれほど重要で価値があるかについては、いくら強調しても足りないぐらいだ。製品開発では、いつも不測の事態が起こる。そうした事態に遭遇するのは、ベータ版や正式版の製品をリリースする時になってからではなくて、もっと早い時期であるほうがずっといい。しかも、実際にエンジニアリングが始まってしまうと、ある種の独特な慣性が作用するようになって、大幅な変更をするのがものすごく困難になってくるし、また、そういう変更の費用もぐんと上昇する。
第22章「プロトタイプの検証」では、ユーザビリティと価値を検証する手法を詳しく説明しよう。
参考事例
ハイフィデリティプロトタイプの具体例やその作成用のツールのリストは、次のウェブページで閲覧できる。
www.svpg.com/examples
Inspired日本語版 