Inspired日本語版

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

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

この投稿の続きを読む

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

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

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

この投稿の続きを読む

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

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

この投稿の続きを読む

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

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

この投稿の続きを読む

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

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

この投稿の続きを読む

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


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

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

この投稿の続きを読む

こんにちわ。

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

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

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

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

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

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

この投稿の続きを読む

第12章 製品を見つけ出す
正しい製品を定義する

ソフトウェア製品を開発するプロジェクトは、まったく別の 2つの段階に分けることができる。作るべきものを決める (正しい製品を定義する) 段階と、それを作る (正しくその製品を作り上げる) 段階である。最初の段階でいちばん重要なのは、製品を見つけ出すことであり、2番目の段階は、ひたすら実行である。

この投稿の続きを読む

この第11章から第２編「プロセス」に入ります。この「プロセス編」では、最先端のインターネットソフトウェア企業において、顧客をわくわくさせ、売れる製品を繰り返し「見つけ出し」、具体的な形に作り上げていくために用いられているプロセスやベストプラクティスを説明していきます。

第11章は、プロダクトマネージャーの役割のひとつ「製品の市場性評価」について説明します。第1章では、プロダクトマネージャーの役割について以下のように書かれていました。少し長いですが、大枠を確認するために引用します。

プロダクトマネージャーの主な任務は二つある。製品の市場性を評価することと、開発すべき製品を定義することである。通常、新しい製品のアイデアは至るところから飛び出してくる。たとえば、経営陣、顧客との議論、使用感テスト、製品開発チーム自身、営業担当者、業界関係者などだ。しかし、次に、誰かがそのアイデアを吟味して、さらに先に進める価値のあるものかどうかを決めなければならない。この目利きをやるのが、プロダクトマネージャーである。（多くの企業では、これを市場要求仕様(MRD, Market Requirement Document)という書類にまとめるが、この本では、後ほど、その軽量版である市場機会評価(Opportunity Assessment)について説明する。)

十分に市場性があって、自社でそのアイデアを実現できる可能性が高いと判断されれば、その次には、誰かが、そのアイデアの具体的な形、つまり、どういう製品にするのか（必要とされる特性と機能、ユーザーエクスペリエンス、発売の基準など）を「見つけ出す」必要がある。ここで、再びプロダクトマネージャーの出番となる。この任務は、プロダクトマネージャーの仕事の核心部分である。こうして形になっていく仕様は、製品要求仕様(PRD, Product Requirement Document)、あるいは、製品仕様、機能仕様などと呼ばれる。ここで、私は、紙ベースではなく、プロトタイプに基づく軽量なアプローチを勧める。しかし、肝心なのは、その仕様書が記述すべきことは、開発されるソフトがどういう機能を備えて何をするものかということであり、どのように動くかではないということだ。

どうぞお楽しみください。

＝＝＝＝＝＝＝＝＝＝
第11章 製品の市場性評価

解決すべき問題を特定する

新しい製品が登場するチャンスは、あらゆる市場の至るところにある。成熟した市場であっても例外ではない。というのも、何が実現可能であるかが絶えず変化しているからだ。新しい技術が次から次へと生まれ、競争相手も入れ替わっていく。そして、会社も、新しい才能やアイデアを持った新たな人間がやって来ることで変わっていく。

この投稿の続きを読む