Inspired日本語版

第24章 ユーザーにやさしい緩やかなバージョン移行
ユーザーに苦痛を与えないために

「ユーザーに苦痛を与える」というのは、製品のユーザーに対してユーザーが歓迎しない変更をリリースすることで、意図せずに (だといいのだけれど) 無用な負担をユーザーにかけてしまうことだ。ユーザー全員が製品の変更を歓迎してくれるわけではないとは信じたくないかもしれないが、それが現実である。ユーザーがそう感じる理由はいくつかある。



この投稿の続きを読む

第23章 現在の製品を改善する
改善とは機能を追加することではない

できあがってしまった製品の開発を続けるという話になると、多くのプロダクトマネージャーは、何をすればいいのかわからないでいる。たいていは、詳細な製品ロードマップがあって、そこには、製品開発チームが追加したいと思っているあらゆる機能のすばらしいアイデアが示されている。あるいは、ロードマップには、特定の顧客からの「もしこの製品を買ってほしいなら、次の 6つの機能を追加してもらいたい・・・」というような要求で埋め尽くされている。

この投稿の続きを読む

第22章 プロトタイプの検証
製品のアイデアを実際のユーザーの前でテストする

これまでの章で、私が、ハイフィデリティプロトタイプをどう位置づけているかはわかってもらえただろう。ハイフィデリティプロトタイプというのは、作るべき製品を表現して説明するためのいちばん基本的な方法であって、従来の紙ベースの仕様書よりも、製品開発チームにとってははるかに役に立つものだ。でも、このメリットは、あくまでもおまけのようなものにすぎない。ハイフィデリティプロトタイプを作るいちばんの目的は、製品についての理解をより深めて、最終的には、製品のアイデアを実際のユーザーといっしょに試すことにある。これをあらかじめやらないと、製品がその目的を果たせるかどうかを確実に証明できるものがない状態のまま、そんな製品をエンジニアリング部門に何ヶ月もかけて作らせることになってしまうからである。

この投稿の続きを読む

第21章 製品仕様の検証
価値があって、使いやすくて、実現可能であるという確証を得る

ここまでのいくつかの章では、私が製品の検証作業などと呼んできたことについて説明してきた。製品の検証とは、製品仕様が、売れる商品となること間違いなし、との確証が得られている製品のプロフィールを描写しているのかどうかを検証することである。ただ、この検証では、実際にその製品を作り上げてユーザーに披露する、ということはやらない。

この投稿の続きを読む

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

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

この投稿の続きを読む

第18章 製品仕様はどうあるべきかを考える
PRD よ、安らかに眠れ

製品仕様については、旧態依然とした仕様書が延々と使われているように思う。完全に製品仕様書をなくして、アジャイル開発手法を使えばいい、という人たちもいる。これには、他の問題がいろいろあるが、この主張は多くの点で外れてはいないと思う。

でも、ここは先走らずに、現在使われている紙ベースの仕様書の問題点から議論しよう。

この投稿の続きを読む

第17章 プロダクトマネジメントのためのペルソナ
ターゲットユーザーを理解する

プロダクトマネジメントというのは、要は、何かを選択すること、これに尽きる。どの市場機会を追求するべきか、解決するべき課題はどれか、どんな機能がいちばん大きな価値につながるのか、製品化までの時間との折り合いをつけるために最適なポイントはどこか、どの顧客がいちばん重要なのか、といったことを決めるのである。すべてにわたって正しい選択をすることはできなくても、その多くで正しいものを選択しなければ、製品を成功に導くことはできない。

この投稿の続きを読む

16章　市場調査
その可能性と限界を理解する

たいがいの会社では、マーケティング部門と製品開発部門との間には何らかの緊張関係があるものだ。よく意見が分かれるのは、さまざまな市場調査 (マーケットリサーチ) の手法は、製品を見つけ出すプロセスで使えるのか、という点だ。たとえば、フォーカスグループ、顧客アンケート、サイト分析 (site analytics)、訪問調査 (site visits)、使用感テスト、実地テスト、競争的分析といったものである。

この投稿の続きを読む

第15章 ユーザーモニター制度
製品開発のパートナーたち

マーケティングの人たちなら、製品を発売するときは、確実に製品を買って製品レビューなども公開してくれる顧客 (リファレンスカスタマー)、プラットフォーム製品であるならは、そこで動くアプリケーションで目玉となるもの (リファレンスアプリケーション) ほど重要で説得力のあるものはない、と口をそろえるだろう。それなのに、実に多くの製品が、リファレンスカスタマーやリファレンスアプリケーションがないまま発売されていることには、相変わらず驚かされる。

この投稿の続きを読む