Inspired日本語版

How To Create Products Customers Love

第22章 プロトタイプの検証

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

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

この投稿の続きを読む

広告

第21章 製品仕様の検証

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

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

この投稿の続きを読む

第20章 必要最小限までそぎ落とされた製品

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

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

この投稿の続きを読む

第19章 設計 vs. 実装

第19章 設計 vs. 実装
実装の前にユーザーエクスペリエンスを設計する

ソフトウェア開発の作業では、同時に進められることや同時に進めるべきことがたくさんある。たとえば、私は、長い間、機能要件とデザイン (ユーザーエクスペリエンスの設計) は、お互いに関連し合っているので、並行して進めるべきだと主張してきた。私は、プロダクトマネージャーが要件を定義してから、これをインタラクションデザイナーに渡して設計してもらうという、従来のウォーターフォールモデルは好きではない。今や、多くの製品開発チームの人たちは、このモデルは時代遅れだと思っている。

この投稿の続きを読む

第18章 製品仕様はどうあるべきかを考える

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

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

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

この投稿の続きを読む

第17章 プロダクトマネジメントのためのペルソナ

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

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

この投稿の続きを読む

第16章 市場調査

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

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

この投稿の続きを読む

第15章 ユーザーモニター制度

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

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

この投稿の続きを読む

第14章 製品委員会

第14章 製品委員会
製品開発の重要意思決定をタイムリーに行う


たとえ中小企業においても、意思決定を行うことはたいてい時間がかかりフラストレーションのたまるものである。製品開発企業であれば、重要なステークホルダーと意思決定者が一同に会してタイムリーに情報を共有して製品決定を行うためメカニズムを必要としている。

これを可能にする私のお気に入りの方法が、製品委員会を設置することである。

この投稿の続きを読む

第13章 製品理念

こんにちわ。

13章は、Product Principlesについて書かれています。Martyのブログをみると、Product Manifestoとも呼ぶようです。ここでは製品理念と訳しています。

製品理念ではありませんが、日本企業が掲げる「理念」として思い浮かべるものがふたつあります。ひとつは、ソニーの設立趣意書です。この冒頭文、「真面目なる技能者の技能を最高度に発揮せしむべき自由闊達にして愉快なる理想工場の建設」は有名ですね。もうひとつは、三菱商事の三綱領「所期奉公、処事光明、立業貿易」です。また、この10年くらいでとても話題になったものに、グーグルのDon’t be evilがあります。

経営や製品サービスに関して何か判断をする時、何を大切にして決めるかという判断の拠り所となるもので、ソニーにしてもグーグルにしても三菱商事にしても創業者の哲学が表れていると思います。

それでは、どうぞお楽しみください。

==========
第13章 製品理念
何が大切かを決める

製品理念とは、製品開発のための一連の原則を定めたもので、両立させるのが難しいものがうまく折り合うところを見極めて何を優先させるかを決めるときに、大きな拠り所となる。製品理念は、信念や目的を社内の人たちに宣言するものでもある。私が製品開発をやるときは、製品理念を決めて公表することにしている。というのは、きちんとした製品理念をみんなに知ってもらえれば、それは、製品戦略を効果的に補ってくれるし、製品を見つけ出すプロセスがぐんとはかどるからである。

この投稿の続きを読む

%d人のブロガーが「いいね」をつけました。