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