Inspired日本語版

第20章 必要最小限までそぎ落とされた製品
機能を減らすか、それとも発売を遅らせるか？

こんな場面を観たことはないだろうか。プロダクトマネージャーが、いろんな機能が満載のすごい製品の仕様を思いつく。すべての機能には、P1 (絶対必要)、P2 (ぜひほしい)、P3 (あれば嬉しい) のどれかがきちんとマークされている。プロダクトマネージャーは、この仕様をエンジニアリング部門に手渡す。エンジニアリング部門は、それぞれの機能の開発にかかるコストを見積り、スタッフの稼動状況を考えながら機能の優先順位を決め、開発のスケジュールを作る。だいたいは、プロダクトマネージャーの想定より何ヶ月も長いスケジュールになる。そして、社内のあちらこちらとの交渉が始まる。見積りは妥当か、機能を減らすか、品質保証やベータテストの回数・期間を極力減らせないか、追加の派遣社員は必要か、といったことを議論するのである。そうしている間にも、時間は刻々と過ぎていく。

こんな場面を観たことはなくても、どこかで聞いたことはあるはずだ。結末もおわかりだろう。最終的に発売された製品は、すべての機能がきちんとまとめられた製品と呼ぶには程遠い代物だ。そして、だれにとってもハッピーエンドではない。プロダクトマネージャー、エンジニア、そしてもちろんエンドユーザーにとっても。

多くの製品開発チームは、製品開発なんてそんなもの、と思っているかもしれない。でも、この結末は、開発のプロセスに欠陥があるために、起こるべくして起こったものなのだ。

ここで、まったく別のやり方を提案しよう。

第一に、プロダクトマネージャーがまずやることは、デザイナーと協力して、その製品としての目的を達成するために必要最小限の機能を備えたハイフィデリティプロトタイプ (製品の正式版が正確にイメージできる試作品) を作ることである。このプロトタイプのユーザーエクスペリエンスは、ユーザーにとって使い方がわかりやすくて、実際に使ってみたいと思わせるようなものでなければならない。製品開発チームとしては、機能をそぎ落として最小限に抑えることが重要なのだけれど、その理由は、実装に必要な時間を極力短くして、使う側にとっての複雑さを最小限にするためである。

第二に、デザインが始まる当初から、エンジニアリングチームからもだれか加わってもらって (普通はアーキテクトか主任エンジニア)、プロトタイプで表現される製品のアイデアをいっしょにレビューしてもらう必要がある。この人は、プロダクトマネージャーやエンジニアがそれぞれの製品アイデアに必要なコストを把握して、コストの比較をするのを手伝うのである。また、製品開発がおかしな方向に行きそうな時はそれを指摘することもできるし、自分自身がよくわからないところを調べることもできる。ただ、プロトタイプが完成するまでには、このエンジニアは、残すことに決まった機能についてコストの詳細な見積りを出しておかなければならない。つまり、この時点までに、関係者の間では、何を採用する、何を捨てる、あるいは後回しにする、といった調整は終わっていて、コンセンサスも得られている。この時点で、エンジニアリングチームは、詳細な確定見積りを用意しておかなければならない。

第三に、現実のターゲットユーザーとともにプロトタイプの検証を行うことが欠かせない。製品開発チームが製品開発に全精力を注ぎ込んでしまう前に、プロダクトマネージャーとデザイナーは、自分たちが考えた製品は絶対に売れると確信していなければならない。製品定義がよくできたと思っているだけでは不十分で、それを確かめるためにテストする必要がある。これは、プログラムを書いた本人がいいと思っているからといってそのコードをそのままリリースできないのと同じで、その前にまずはコードをテストしなければならないのだ。

こういうわけで、いったん必要最小限の機能の製品を定義して、ターゲットユーザーといっしょに検証を続けて、これでうまくいくという確証が得られたら、その後はもう機能のどれかを落とすことはできないし、また、それをやってもユーザーからはお墨付きをもらえるなどと思ってはいけない。もしこれができるとすれば、実は、そもそも初めから必要最小限の機能の製品にはなっていなかったということだ。

それでもまだ、難しい決断をしなければならない場面は出てくるだろう。よくあるのは、機能の中のあるものについて、予想よりも実装に時間がかかるという場合だ。でも、私がここで説明しているモデルでは、機能を減らすのではなく、スケジュールをずらすのがまっとうな対応である。とっくに機能は必要最小限までそぎ落としてしまっていることを思い出してほしい。このモデルのいいところは、他のよくある手法に比べて、見積りが正確だということである。その理由は、ドキュメント形式の仕様書ではなく、ハイフィデリティプロトタイプを基にして見積もっているので、エンジニアリング部門は十分時間をかけて機能を評価済であり、しかも、より当事者意識を持って見積りをするし、開発する機能もそれほど多くはないからである。そのため、スケジュールが後ろにずれたとしても、私たちがいつも現場で感じているほどには深刻でもないし、そうしょっちゅう起こっているわけでもないのだ。

また、基本的に同じ理由で、いったんエンジニアリングの作業が始まると、プロダクトマネージャーは、気軽に新しい要件を追加し続けることなどできないのである。プロダクトマネージャーが仕様を変更する原因の中でも圧倒的に多いのが、そもそも要件についてじっくり検討していなかったというものだ。ハイフィデリティプロトタイプを使うことで、こういう問題の多くは、かなり早い段階であぶり出せるだろう。

スクラムのようなアジャイル開発手法では、ここで私が説明している方法とは違ったやり方ではあるけれど、こういった問題に対応できている、と考えている人もいるようだ。私は、明日からでも、たくさんの製品開発チームがアジャイルに乗り換えればいいのに、と思っている。そうすれば、間違いなくいい方に変わるはずだ。けれども、アジャイル開発手法でも、ここで述べている問題には実は対応しきれていないことがわかるだろう。また、アジャイル特有の問題もないわけではない。この点については、第26章「アジャイル開発手法をうまく使う」で詳しく説明する。

ぜひとも、製品の要件として考えているものや、どれが重要な要件かについて、優先順位をつけることをやって、仕様が確定するまでに、可能な限り最小限の機能になっていることをしっかり確かめてほしい。そして、仕様書からは、P1、P2、P3 というような注釈は全部外して、今あるものがこの製品のすべてだということを、製品開発チームのみんなに言い切ってほしい。もし後から機能のどれかを外したりしようものなら、かつての私の上司がよく言っていたようなことになってしまうだろう。足をもぎ取られた犬は、狩りをしない、と。