第18章 製品仕様はどうあるべきかを考える
PRD よ、安らかに眠れ
製品仕様については、旧態依然とした仕様書が延々と使われているように思う。完全に製品仕様書をなくして、アジャイル開発手法を使えばいい、という人たちもいる。これには、他の問題がいろいろあるが、この主張は多くの点で外れてはいないと思う。
でも、ここは先走らずに、現在使われている紙ベースの仕様書の問題点から議論しよう。
もちろん製品仕様書と言ってもさまざまだ。まずは呼び方だが、製品要求仕様書 (Product Requirements または PRDs)、市場要求仕様書 (Market Requirements または MRDs)、ビジネス要求仕様書 (Business Requirements または BRDs)、機能仕様書 (Functional Specs または FS) などがある。これらの文書は、扱うトピックもまったく違う (これらはもともと同じ目的のために作られたわけではないが、時が経つにつれて合体したり、形を変えていったりして、当初の違いの多くは失われた)。また、どこまで細かく書くかも違うし、もちろん仕様書としての質も一様ではない。形式だってさまざまだ。たいていの人はマイクロソフトのワードを使うが、スプレッドシートを使う人もいれば、ウィキサイトを使う人もいるし、市販の要件管理ツールを使う人もいる。
これまでに、本当に出来のいい製品仕様書をいくつか見たことがある。でも、ほとんどの仕様書は、書くのに時間がかかり過ぎていて、めったに読んでもらえないし、必要なことが詳しく書かれていないし、難しい問題点を取り上げることもないし、問題点に取り組むのに必要な重要情報も書かれていない。さらにまずいのは、仕様書が存在するというだけで、すべてはうまく進んでいるという間違ったサインを経営陣や製品開発チームに与えることになりやすい、という点だ。
プロダクトマネージャーの重要な役割は、人々に買ってもらえるような製品のプロフィールを仕様書にまとめて、これをエンジニアリングチームに渡すことであるはずだ。これに賛同してもらえるなら、仕様書を作る典型的な作業方法ではどこがまずいのかを認識して、製品をどうやって定義していったらいいのかをじっくり検討しなければならない。
ここで、出来がよくて役に立つ製品仕様書であるための条件として私が考えているものを挙げてみよう。
• 仕様書には、ユーザーエクスペリエンスをすべて記述しなければならない。つまり、製品要求だけでなく、ユーザーインタラクションやビジュアルデザインも必要ということだ。そろそろ、製品要求がユーザーエクスペリエンスデザインとどれほど密接に結びついているかということを、みんなが理解してくれていればいいのだけれど。
• 仕様書では、ソフトウェアの動作を正確に表現しなければならない。そして、言葉やきれいな絵だけでは、製品の動作を表現するには大きな限界があることも認識しなければならない。
• 仕様書を必要としているのは、エンジニアリング、品質保証、顧客サービス、マーケティング、サイト運用、営業、そして経営陣である。というわけで、仕様書は、それぞれのグループにとって必要な内容が全部盛り込まれるような形で、製品の動作を伝えるものでなければならない。
• 仕様書というのは、変更が加えられていくものである。いったんエンジニアリングが始まれば、変更はぐんと少なくなる。それでも、新たに決められることや新たな問題が出てくるので、最新の決定事項を反映するように仕様書をアップデートしていかなければならない。
• 仕様書を作る過程では、重点要件リスト、ワイヤーフレーム、モックアップなど、さまざまな素材が作られるが、混乱、曖昧さ、複数の人が手を加えたり複数の場所で編集作業が行われたりすることで起こるバージョンの混同などを極力なくすために、マスター版仕様書を 1セット用意する必要がある。
私の考えでは、これらの条件をすべて満たす仕様の形式はたったひとつしかない。それは、ハイフィデリティプロトタイプである。
ハイフィデリティとは、提案されているユーザーエクスペリエンスを正確に再現するということである。どうでもいいようなユーザーインターフェースは別にして、私はいわゆるペーパープロトタイプは好まない。今はいいツールが使えるので、ほとんどのソフトウェア製品については、簡単に、あまりコストをかけずに、すぐハイフィデリティプロトタイプを作ることができるから、これをやらない手はない。これは所詮プロトタイプなので、ユーザーエクスペリエンスがもっともらしければ、バックエンド処理やデータはそれらしいもので間に合わせることで構わない。
ここ数年間で私の考えは変わった。以前は、単にユーザーエクスペリエンスの中でも重要な要素だけプロトタイプすればいいと思っていたが、今は、基本的に全部 (すべてのページとスクリーンショット、主なユースケースすべて) をプロトタイプするべきだと考えている。もちろんエラー状態やたいしたことがないケースまでプロトタイプする必要はないだろう。でも、ハイフィデリティプロトタイプを用意すれば、製品開発チーム全員が、これをいじりながら、これから作る製品をよく理解できるようになる。このメリットは本当に大きいので、このために追加コストがかかっても十分元は取れる。
それでも、プロトタイプだけでは十分ではないというのもまた、そのとおりである。提案されている製品の動作の中には、プロトタイプでは表現しづらいものもあるからだ。たとえば、ビジネスロジック (税率表や輸送料など)、リリース要件 (信頼性、性能、拡張性など)、プラットフォーム提供の要件 (インストール要件やサポートされるブラウザバージョンのリスト) といったようなものである。プロトタイプを補足する方法としては、ユースケースも役に立つ。ユースケースとは、製品の中でもいちばん重要なフロー (ユーザーとソフトウェアとの間のやりとり) を言葉で説明するものである。
ここで、やはり、プロトタイプを補完するものをどうやって表現するのがいちばんいいかが問題になる。プロトタイプに注釈をつけられれば、それがいちばんいいと思う。でも、今のところ、それを簡単にやれる技術がないので、Wiki などイントラネット (企業内ネットワーク) を利用するのがいいだろう。いちばんの理由は、製品開発チームの全員が、いつでも最新版がどこにあるかを知ることができるからだ。あっちこっちにいろんなバージョンの文書が出回ったりするよりずっといい。イントラネットであれば、質問や回答を掲載したり、仕様が更新されるたびに自動的にメールで通知するように設定したり、決定事項の履歴をたどったりすることも簡単にできる。
それでも、製品仕様の大半は、ハイフィデリティプロトタイプとするべきだ。これは、機能要求、情報アーキテクチャ、インタラクションデザイン、ユーザーエクスペリエンスのビジュアルデザインなどを表現するものなのだ。
ハイフィデリティプロトタイプは、ここで挙げた条件に合っていることに加えて、紙ベースの仕様書と違ってテストできるところが最大のメリットだと思う。実際のターゲットユーザーの前に置いて、使い方がわかりやすいかどうか (ユーザビリティ) を確認することができるし、ユーザーが使いたいと思うかどうか (バリュー) も判定できる。プロトタイプがこの 2つのテストをパスするまでは、エンジニアに渡す意味のある製品仕様にはなっていない、ということだ。こういうテストは、品質保証やベータ版のテストの段階になってからやるのでは、製品化のための作業全体から見てもあまりにも遅すぎる。
ぜひハイフィデリティプロトタイプを作って、提案したい機能やユーザーエクスペリエンスをそこで再現する、ということをやってみてほしい。製品開発チームは、間違いなくそのやり方を大歓迎するだろう。まずはエンジニアたちが喜ぶ。というのも、自分たちがこれから作る製品をわかりやすくはっきりと表現してくれる仕様をやっと手に入れたわけで、どういう操作になるのかわからなくなったときは、いつでもその仕様を見ればわかるからだ。品質保証の仕事もやりやすくなる。製品の正式版をテストするときに、何がどうなればいいのかということがわかるからだ。マーケティング、営業、顧客サポートといった人たちも、ずっと早い段階から製品の使い方を知りたいと思っている。経営陣だって歓迎するだろう。投資家、取締役、取引先に対して、パワーポイントなんかでプレゼンするよりもずっと効果的に、今何を作っているのかを説明することができるからだ (プロトタイプで実演してみせることだってできるし)。
でも、待ってほしい。プロトタイプのいいところは他にもあるのだ。
仕様書代わりとなるプロトタイプを作ることで、普通は、製品発売までの時間を格段に短くできるのだが、多くのチームがいちばん驚くのはこの点である。そうなのだ。直感的にはそうは思えない、というのはわかる。なぜ発売までのトータルの時間が短くなるのかを理解するために、ソフトウェア開発で必ずと言っていいほど起きていることを、少し詳しく見てみよう。よくある紙ベースの仕様書はあまりにもお粗末で (不完全、曖昧、おまけにテストされていない)、難しい問題や重要な詳細部分がほとんどフォローされていないので、チームは、エンジニアリングの段階でこうした課題に取り組まざるを得なくなる。この結果、エンジニアリングはすさまじくかき回される (仕様書がひっきりなしに変更されるせいで、開発が遅れてエンジニアに不満がたまりまくる) か、あるいは、エンジニアたちが精いっぱい想像を巡らしながら作業を進める。そして、発売にこぎ着けた製品はめちゃめちゃなものになり、アップデートを出してようやく顧客がまともに使えるものとなる。どっちにしろ、無駄に長い時間がかかってしまう。
こういうわけなので、みなさんも、次の製品開発のときには、ぜひ仕様書代わりのプロトタイプを作ってみてほしい。何週間もかけて 50ページもあるワード文書を作っても、どうせだれも読んでくれないし、だいたいこれではテストができない。それよりも、提案しようとしている製品のプロトタイプをデザイナーといっしょに作ってみよう。そして、そのプロトタイプをターゲットユーザーと製品開発チームのメンバーに披露しよう。その後もこれを何回かやることになるだろう。(エンジニアが何ヶ月もかけてひどい製品を作ってしまっては後の祭りだから、今の方がいい！) プロダクトマネージャーが正しいレシピをプロトタイプの形で用意すれば、それは、エンジニアに手渡す仕様のベースとして使えるのだ。さあ、これで何が起こるか見ていてほしい。
参考事例
ハイフィデリティプロトタイプと製品仕様のサンプルは、次のウェブページで閲覧できる。
www.svpg.com/examples
Inspired日本語版 