はじめに
1980年代半ば、私は、ヒューレット・パッカード (HP) で、 若手のソフトウェア開発担当者として、 ある重要な製品開発プロジェクトに携わっていた。当時は人工知能がブームであったが、業界屈指の企業の中で、しかも、最強のソフトウェアエンジニアリングチームの一員として働くことができたのだから、本当に運がよかったと思っている (このチームのメンバーの何人かは、その後、IT業界のさまざまな企業で大成功を収めている)。その製品開発で私たちが取り組んだ仕事は、困難なものだった。当時の汎用ワークステーションといえば、特定の用途のハードウェアとソフトウェアをセットでそろえる必要があり、ユーザーは10万ドル以上も負担しなければならなかったので、おいそれと買える代物ではなかった。そこで、HP は、低コストの汎用ワークステーションを開発することとし、私はそのソフトウェア開発を担当したのである。
この開発では、長時間くたくたになるまで働くことを強いられる日々が 1年以上も続き、数えきれないほどの夜や週末を犠牲にした。開発の途中では、私たちは、いくつかの特許を生み出すことで HP の知的財産を充実させることにも貢献した。そして、私たちは、HP の厳格な品質基準を満たすソフトウェアを開発することができた。製品の海外展開や多言語化も行い、営業担当者の教育もやった。発売前にはマスコミに製品を公開し、すばらしい評価を得た。こうして、私たちは、万全の準備をして、華々しく製品の発売に臨んだ。
ただ、1つだけ問題があった。だれもこの製品を買ってくれなかったのである。
要するに、市場では受け入れられず、このプロジェクトは完全な失敗に終わったのだ。そう、技術的には深い感銘を与える出来映えで、発売前の製品公開でも大好評だった。けれども、みんながほしがったり、必要としてくれたりするものではなかったのだ。
チームのメンバーは、みんなこの結果に苛立ったが、すぐにいくつかの重要な問題に気づき始めた。どんな製品を実際に作り上げるべきかを、だれが決めるのか。また、どうやって決めるのか。できあがった製品が役に立つものだということを、どうやって知ればいいのか。
私たち若いチームは、非常に深遠なこと、たぶんそれは多くのチームが苦労の末に理解できるようになった真理を学んだのだった。いくらエンジニアのチームが優秀でも、作る意味のあるものを与えられなければ何にもならない。
もっとわかりやすく言うと、技術的にいい仕事をするだけではダメなのだ。それと同じくらい、あるいはそれ以上に大事なのは、価値があって (valuable)、使いやすくて (usable)、実現可能な (feasible) 製品を「見つけ出す」ことである。
失敗の原因を徹底的に突き詰めていくうちに、何を作るかを決めたのは、プロダクトマネージャーと呼ばれる人だということがわかった。プロダクトマネージャーは、通常はマーケティング部門に所属していて、私たちエンジニアが作り上げる製品のプロフィールを決める人であった。ところが、さらにわかったのは、プロダクトマネジメントは、HPにとってあまり得意な領域ではないということだった。そして、後になって気づいたのだけれど、ほとんどの会社はプロダクトマネジメントが得意ではなく、その状態は今も変わっていない。
私は、これからは、ユーザーや客先が望んでいると確信できる製品のためでなければ、絶対にこんなしんどい仕事なんかするものか、と心に誓ったのであった。
その後20年間、非常に幸運なことに、私は、その時その時でいちばんよく売れたハイテク製品の仕事をする機会に恵まれた。まず、HP 時代にパーソナルコンピューターの台頭を経験し、その次には、インターネットが急成長した時期に、Netscape/AOL でプラットフォームやツールを担当し、最後に、Eコマースが急拡大した時期にあって、eBay でプロダクトマネジメントとデザインの責任者を務めた。
私が関わった製品開発がすべて成功をしたわけではないが、幸いにも、失敗作は 1つもなかった。そうした製品のいくつかは、世界中の何百万もの人々に愛され、使われるようになった。
eBay を辞めてまもなく、自社の製品開発を改善したいと考えている会社から相談を受けるようになった。こうしたコンサルティングの仕事を通じて、私は、超一流企業の製品開発とその他大勢の企業の製品開発との間には、雲泥の差があることを知った。また、最先端の製品の開発手法は、従来から広く使われている開発手法とはずいぶん違っていることもわかった。製品を設計して作り上げるのに、ほとんどの会社がいまだに古くて効率の悪い方法を使い続けている。この点に関しては、一流ビジネススクールの教育プログラムやその他の学問分野も業界団体も、ほとんどあてにできないこともわかった、彼らも、過去の破綻したモデルにしがみついている状態なので、どうしようもないのだ。まさに、私がHPにいた頃そうであったように。
幸い、私は、すばらしい経験を積むことができたし、業界トップクラスの才能を持った人たちといっしょに仕事ができたことに深く感謝している。この本に書かれている最高のアイデアは、こうした人たちから得たものである。巻末では、彼らの名前を挙げて謝辞を述べさせていただいた。私は彼らのすべてから多くのことを学んだのであり、その 1人1人に感謝している。
私はソフトウェアエンジニアを経てプロダクトマネジメントの道に進んだが、それは、みんなに愛される製品、つまり、みんなをワクワクさせる、本当に価値のある製品のために働きたいと思ったからである。多くの製品開発チームのリーダーたちもまた、みんなの心を揺り動かし、みんなが買ってくれる製品を作りたいと願っている。ただ、現実には、心を揺り動かすような製品は多くはない。でも、ダメな製品につきあっているほど人生は長くない。
私がこの本を書いたのは、多くの人々から支持される製品を生み出した会社の最良の手法 (ベストプラクティス) をみなさんと共有することに一役買いたいと思ったからである。その結果、人々の心を深く揺り動かし、人々に愛される製品がたくさん作られるようになってくれれば、私としては光栄である。
この本を読んでいただきたい方
この本は、個人向け、企業向けを問わず、ソフトウェア製品、特に、インターネットソフトウェア製品の開発に携わる人を対象としている。つまり、製品のプロフィールを決める (製品を定義する) ことを任されている人たちである。こうした製品開発のリーダーは、プロダクトマネージャーと呼ばれることが多いが、会社の創業者、経営陣、主任エンジニア、デザイナーといった人がプロダクトマネージャーを兼ねる場合もある。
この本は、プロダクトマネージャー以外にも、ユーザーエクスペリエンスデザイナー、ソフトウェアエンジニア、ソフトウェアアーキテクト、プロジェクトマネージャー、プログラムマネジャー、プロダクトマーケティングマネージャー、そして製品開発のチームに参加しているその他のマネージャーにも読んでいただければと思う。
また、この本の内容は、私の経験では、さまざまな製品開発チームにとって役に立つと思う。
たとえば、ベンチャー企業、多様な製品を扱う大手企業、その中間の中小企業などである。また、新発売の製品を開発している場合でも、既に発売されている製品の改良版を開発している場合でもいい。製品開発チームがスクラムなどのアジャイル開発手法を使っている場合でも、あるいは、従来のウォーターフォール型の手法を使っている場合でも構わない。
さらに、個人向け、中小企業向け、大企業向けを問わず、インターネットサービス、パッケージソフト、端末や周辺機器、プラットフォームといったさまざまな製品の開発にも役立つだろう。たとえば、Eコマース用ウェブサイト、ネット上で対戦するスポーツやゲームのウェブサイト、家電、企業向けのホスト型サービス、ある種のインターネットアプリケーションやインターネットサービス (ソーシャルネットワーキングや動画共有など) のためのプラットフォーム、といった類の製品である。
ただ、1つはっきりさせておきたいのだけれど、この本は、医薬品などソフトウェア以外の製品の開発に関わっている人や、製品ソフトウェア以外のシステム開発 (ソフトウェアのカスタマイズなど) をやる人を想定して書かれているものではない。この本で述べる手法や戦略が他の分野では使えないということではないけれど、私がこの本で紹介する考え方 (コンセプト) を展開、実践してきたのは製品ソフトウェアの分野であるため、それ以外の分野で同じように有効とは限らないということをあらかじめお断わりしておきたい。
本書の構成
私は、Netscape に転職してからシニアマネージャーとして働くようになったのだが、そこでまず気づいたのは、管理職としての日常業務は3つの領域に分けられる、ということだ。それは、人、プロセス、製品である。
「人」とは、製品開発のための組織、すなわち、製品を定義、開発するためにチームのメンバーが果たすべき役割や責任を指す。
「プロセス」とは、たくさんの人をワクワクさせることができて、たくさんの人が買ってくれる製品を見つけ出して作り続けることを可能にする作業工程、活動、およびベストプラクティスを指す。
「製品」とは、たくさんの人をワクワクさせる製品を定義する特性 (製品のプロフィール) を指す。
この 3つの領域は、すべて、たくさんの人をワクワクさせる製品を発見して創造するために欠かせないものである。すべては人から始まる。で、この人たちが、みんなの心を動かし、みんなに受け入れられる製品を作り続けることを可能にするのが、プロセスなのである。
この本では、この3つの領域について三部構成で説明している。それぞれの部は、いくつかのトピックに分かれている。トピックの順番はそれほど重要ではないので、どのトピックから読んでもらっても構わない。それぞれのトピックは、自己完結していて読み切りの形になっている。この本の最後では、私がいちばん大切だと考えている 10の仕事の仕方やテクニックが説明されているが、ここがすべてのトピックの要約ともなっている。
この本のあちらこちらのトピックで、世界最高の企業が使っているベストプラクティスが紹介されている。業界屈指の製品開発担当者へのインタビューに基づいて書かれたトピックもある。私がかつて在籍した企業での経験や、私の顧客企業との仕事での経験に基づいたトピックもある。
覚えておいてほしいのは、この本が現実に有益となるのは、実際によりよい製品を生み出すことに役に立った場合だけなので、まず私が意図したのは、それぞれのトピックが、みなさんの議論を巻き起こし、みなさんにとって意味のあるものとなり、また、みなさんが行動を起こすきっかけとなるようにする、ということだ。
この本の内容が、もっと売れる製品を作り出すのに役立つことを願っている。そして、ぜひみなさんの経験も聞かせてほしい。また、ぜひシリコンバレープロダクトグループのサイト (www.svpg.com) を訪れて、みなさんの考えを聞かせてほしい。
それでは、みなさんの製品開発がうまくいって、多くの人がワクワクして大好きになってくれるような製品が生まれることを祈って。
コラム(1)
デザインが優れた製品
私は、みんなをワクワクさせるような製品が偶然には生まれるとは思っていない。みんなの心を動かしみんなが買い求めた製品の裏側には、必ずある種の真実が隠されている。ここで、私が製品開発に取り組むときにいつも気をつけている10の真理を挙げてみよう。
1. プロダクトマネージャーの仕事は、価値のある、使いやすい、実現可能な製品を「見つけ出す」ことである。
2. 製品を見つけ出すのは、プロダクトマネージャー、インタラクションデザイナー、ソフトウェアアーキテクトの共同作業である。
3. エンジニアリングは、重要で困難な仕事である。でも、もっと重要なのがユーザーエクスペリエンスデザインであり、それは、たいていの場合エンジニアリングよりも困難である。
4. エンジニアは、たいていユーザーエクスペリエンスデザインが不得意である。エンジニアは実装モデルで考えるが、ユーザーは概念モデルに基づいて考える。
5. ユーザーエクスペリエンスデザインとは、インタラクションデザインとビジュアルデザインの両方 (そしてハードウェア端末のインダストリアルデザイン) を意味する。
6. 機能性 (製品要求) とユーザーエクスペリエンスデザインは、本質的に連関している。
7. 価値のある使いやすい製品を生み出すためには、実際のターゲットユーザーに対して、早い時期から、事あるごとに、製品のアイデアを検証しなければならない。
8. 現実的なユーザーエクスペリエンスを使って、実際のユーザーに対して自分たちのアイデアをすばらく、簡単に、何度でも検証するためには、製品の正式版が正確にイメージできる試作品 (ハイフィデリティプロトタイプ) が必要である。
9. プロダクトマネージャーの仕事は、価値があって、使いやすくて、実現可能という目的を満たす上で必要最小限の (余計なものが一切そぎ落とされて洗練された) 製品を特定することである。これによって、製品化までの時間と製品の複雑さを最小限にするのである。
10. 必要最小限までそぎ落とされた機能の製品であって、多くの人が買ってくれそうなものを見つけ出し、その検証が終わると、もはや、その製品については、製品を構成する機能をばらばらにしてしまうと元の製品と同じような目的を果たすことはできなくなる。
あまりにも多くの製品開発チームが、いまだに古くて誤った手法を使い続けている。ともかく、この本で、この 10項目を理解してもらえればいい。
コラム(2)
参考事例
よい例であれ悪い例であれ、私は、参考事例というものが大いに役に立つと確信している。でも、IT業界はあまりにも変化が速いので、こういう本を書くときは、どうすれば適切な事例をタイムリーに提供できるかと悩んでしまう。さらに悩ましいのは、自分の気に入った事例をすべて紹介しようとすると、何百ページあっても足りないのである。
そこで、事例の多くは、シリコンバレープロダクトグループのウェブサイト (www.spvg.com/examples) に掲載した。そうすれば、この本を改訂することなく、参考事例を更新したり追加したりすることができる。ウェブサイトの情報は無料で自由に閲覧できる。
ウェブサイトの参考事例では、市場性の評価、製品理念、製品戦略、製品ロードマップ、製品仕様、製品プロトタイプ、ペルソナ、プロトタイプテストなどに関する質問項目や課題を紹介している。
なお、ウェブサイトを閲覧するにはインターネット接続が必要なことや、ウェブサイトを見にいくことで読書が中断される不便さなどについては、あらかじめお詫びしておきたい。ただ、そうした不便さを上回るメリットがあると期待している。
ぜひ、各章の参考事例をウェブサイトで読んでみてほしい。
Inspired日本語版 