ソフトウェア・ベンダにおけるプロダクト・ マネジメントの役割とは：The Rational Edge

» 2002年06月19日 12時00分 公開
[Dean Leffingwell，Software Entrepreneur and Former Rational Software Executive ]

　ソフトウェア業界にはある1つの共通目標がある。市場で独占的な地位を確立できる強力な製品を開発し、販売する、ということだ。開発チームがこの目標を達成するには、ユーザー1人1人のニーズを満足させるさまざまな機能を搭載することのみならず、その製品を市場に投入することで、ユーザー、はたまた株主が経済的な恩恵にあずかれるメリットを検討することが必要とされる。

　たとえその企業が、マーケティング活動で非常に優秀な実績を持っていようが、あるいは豊富な資金による非技術的資産の数々を誇ろうが、結局、その製品が市場における激烈な競争を勝ち抜き、開発企業の立場を維持しうるほどの「十分に優れた製品」でなければ意味はないのである。

ALT 本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　多くの企業は、自社の開発チームが「適切なソフトウェア」を「適切な手法」で確実に構築できるよう、「Rational Unified Process（RUP）」に代表される標準的なソフトウェア開発手法を採用している。RUPはユースケースや要件テクニックの適用を通じて、自社製品が満たさなくてはならないユーザーニーズの理解を助け、開発チームに適切なソフトウェア構築作業の支援を提供してくれる。RUPはまた、その包括的アーキテクチャ、デザイン、コーディング、そしてテスト手法によって、チームが円滑にソフトウェアを構築できるよう支援し、変化する顧客のニーズに対する信頼性、拡張性、そして適応性を保証してくれる。

　しかし、RUPをはじめとする各種プロセスは、価格設定やライセンス戦略、ブランド展開、商標登録、ポジショニング、そしてサポート＆サービスといった、商品の成功にとって必要なそのほかの要因はカバーしていない。これらの要因がすべて検討され、アプリケーションに統合されることで、ユーザーのニーズ、株主など利害関係者のニーズ、そして顧客のビジネス要件を満たす完全なソリューション製品が生まれるのだ。これから本稿で述べるように、それを実現するのが主にプロダクト・マネージャの役目となる。

プロダクト・マネージャの役割

　バラバラの断片を寄せ集めて完全なソリューション製品を作り出すのは容易なことではない。それには技術に関する相当深い知識（「ホスティングされたWebベースの外部ヘルプシステムに対する誘導に頼ってもよいのだろうか？」といったこと）や市場の要因（「自社にとっては重要な機能に思えないが、ライバル各社は必須のものとして位置付けており、これなくしては自社の成功もないだろう」といったこと）が必要である。

　チームがビジネス的な成功を収めるよう誘導するに当たっての決定はだれが下すのか？ 顧客の成功を保証するために必要なサービスの理解を深めるため、時間を割くのはだれなのか？ 多くのソフト・ベンダではプロダクト・マネージャがこれらの判断を下す権限を持っている。図1に示すように、実績のあるプロダクト・マネージャは、エンジニアリング関連の一部の知識とマーケティング関連の一部の知識、そして市場の現実の一部をうまく組み合わせて考えることで、多様なニーズを満たす完全なソリューション製品を作り出すことができる。

ALT 図1　プロダクト・マネージャとして成功するための原則

プロダクト・マネージャの主な仕事

　優秀なプロダクト・マネージャになるには何が必要なのだろうか？ 当然、製品の成功に集中できるような人物でなくてはならない。これは単純なことだと思う。だが、その一方で、ソフトウェア技術を理解し、開発チームとうまく連携することができ、マーケティングや顧客に対する事前売り込みをそつなくこなし、コミュニケーションを取ることに長け、社内外の利害関係者たちと交渉できる、という「応用自在な」スキルセットも必要なのである。

　RUPでは、（プログラマをはじめとする）開発担当者は、種々の事例やガイドライン、各種コンポーネントの存在によって、開発プロセスの中で果たす自分たちの役割を自然と誘導してもらえる。ちなみにRUPで、プロダクト・マネージャの役割を示すガイドラインを拡張する場合は、下の図2のような結果になるだろうか。以下の各セクションでは、このチームもしくは個人が演じる重要な役割について理解を深めることができるよう、これらの個々の作業について簡単に説明する。

ALT 図2　RUPの構成*1の中で示されるプロダクト・マネージャの作業

■ビジョンの推進

　かつて、米国のある大統領が指摘したように、「ビジョンというやつ」はそれほど単純なものではない。用意すべきものであることは確かだが、どうやって用意したらよいのだろうか？ そもそも（製品にとっての）ビジョンとは、最初に入力される情報ではない。要件、制約、アイデア、技術的なチャンスが凝集された全体の中に合成するプロセスの結果として出力される情報、である。図3はプロセスに入力される各種情報を示している。

ALT 図3　製品のビジョンに対する入力情報

　プロダクト・マネージャの役割は、入力される情報の引き出しと分析活動を促進し、適切な結論を確実に導き出すことだ。チームが一丸となってこれらの結論を導き、そのビジョンを正確に共有するのが理想だが、活動範囲を管理しなくてはならないとき、相反する制約の中で自分が考える最適経路に基づいて「重要な決断を下す」必要があるのはプロダクト・マネージャなのだ。プロダクト・マネージャが顧客を熟知し、技術を熟知していれば、チームはそのマネージャが下す判断を信頼できるという確信を持つことができる。結局のところ、マネージャの仕事（そしておそらくメンバーの仕事）はそれによって決まるのである。

■製品ロードマップの維持

　次の作業は、製品ロードマップ（各種コードのグラフィカルな表示、主要リリース予定日、ソフトウェアの配布に向けた主要な節目など）にビジョンを加味することである。このプロセスに対する入力情報は、製品要件の優先順位、エンジニアリング・チームが用意するリソースの概算、そしてマーケティングやプロモーションの機会、セールストレーニングの機会、カスタマのスケジュール中の重要な日程をはじめとする外的要因の認識、などが考えられる。

　プロダクト・マネージャの役割は、すべきこととできることについて同意を得て、その情報を利用しながら内外の環境における制約に基づいて市場投入への最善経路を作り上げることだ。作業自体は簡単ではないかもしれないが、その結果を図4に示すようなシンプルなグラフィカル・モデルで表現すれば分かりやすいだろう。

ALT 図4　製品ロードマップのサンプル

■全体的な製品計画の定義

　これまでは、ビジョンに関するドキュメントや製品ロードマップの開発と保守におけるプロダクト・マネージャが果たす役割について説明してきた。ビジョンドキュメントは包括的なものだが、その量を多くする必要はない。相当数の利害関係者が実際にこれを読んで理解できなくてはならないため、その長さは管理のしやすい20〜40ページに抑えることが重要なテクニックとなる。しかし、ビジョンドキュメントがカバーする範囲は（実際のところ広範囲に及ぶが）先に言及した完全なソリューション製品を定義するほど広範なものでもない。完全なソリューション製品には、その製品自体に加え、すべての付属品（つまり、人々が製品をうまく利用もしくは応用できるよう支援してくれるもの）が含まれる。

　それらを見いだすための質問を以下に示す。

  • この製品によって顧客の成功を支援するために会社はどのようなサービスを具体的に　提供するのか？
  • 会社のサポート・チームは顧客の成功を保証するためにどのような役割を果たすの？
  • この製品にはコンフィグレーションが1つしかないのか、それとも購入可能なコンフィグレーションは複数あるのか？
  • この製品はスタンドアロンで動作するのか、それとも一緒に使うサードパーティのソフトウェアアプリケーションを顧客が購入しなくてはならないのか？
  • この製品は専用のハードウェア、広大な帯域幅、セキュリティの確保されたアクセスといった各種コンピューティング資源を必要とするか？
  • この製品に対し、顧客はどの程度の期間で、いくらならば快く支払うか？

　これらと同じような質問については、カスタマソリューションを成功させる4つの側面をカバーした全体的なプロダクトプランの中に解答がある。

  • 製品自体
  • 付随サポートやサービス
  • 会社と顧客との間の取引関係を定義するビジネス条件
  • 顧客の確実な成功を支援するために会社が提供するドキュメント

　以下は、チームが顧客に提案するソリューションを定義するのに役立つ注釈付きのテンプレートとなっている。

全体的な製品計画の準備用テンプレート

■概要

目的

提案された完全なソリューション製品の4つの側面（製品コンフィグレーション、サービスおよびサポート、ビジネス条件、マニュアル）について記述する。

参考資料

ソリューションを定義する付属ドキュメント（ビジョンドキュメント、ユースケースモデル、アーキテクチャドキュメント等）を一覧にする。

■ソリューションの概要

解決する問題や動作の内容といった製品の概要を提供する。

製品のコンフィグレーション

コンポーネント

コンポーネントの一覧（部品リスト）などを提供する。

コンフィグレーション

該当する場合は導入やコンフィグレーションに当たってのオプションを記述する。

顧客が用意するコンポーネント

用意しなくてはならないサードパーティ・アプリケーションやコンポーネントについて記述する。

システム要件

アプリケーションのサポートに必要なシステム要求を明記する。

■サービスとサポート

サービス

製品ソリューションの一部となるサイト調査、インストレーション、製品トレーニング、指導教育、Webサービスなど、あらゆるサービスについて記述する。

カスタマサポート

カスタマサポート計画の要素を定義する。

■ビジネス条件

ライセンス

該当する場合は、ライセンス供与とライセンス・メカニズムについて記述する。

価格設定

提案価格モデルについて記述する。

マニュアル

ユーザーマニュアル、オンラインヘルプ、“Read Me”ファイル、インストールガイド、ヘルプ、およびリリースノートなどの関連マニュアルについて記述する。


■ユースケースモデルの準備支援

　リリースに向けたビジョンは通常、製品機能セットに置き換えられる。次のステップでは、ある目的を達成するためにあるユーザーが、どのようにシステムと対話するのか、をさまざまなパターンを想定して記述する。全ユーザーと全ユースケースを組み合わせることで、ビジョンがソフトウェアの各インプリメンテーションにマッピングされ、詳細に描写されるようになる。

　プロダクト・マネージャがユースケースモデルの定義で開発チームを助けることにより、潜在ユーザー全員のニーズが確実に満たされ、結果的に特定のユースケースに反映されるようになる。プロダクト・マネージャはさらに、開発の支援、詳述、およびユースケース自体の見直しに積極的にかかわることができる。しかし、気を付けなくてはならない点は、プロジェクトチームが多数のユースケースを作り出すことで、チームが加味しなくてはならない特異性のレベルによっては作業負荷が小さな管理チームを苦しめることになりかねないことだ。つまり、プロダクト・マネージャは関与レベルをうまくコントロールして、経営陣が木ではなく森を見るよう確実に仕向けなくてはならない。

■製品コンセプトのテスト

　効率的な製品開発プロセスでは、機会のあるごとに顧客やユーザー・コミュニティと一緒に製品コンセプトをテストする。その必要性は明らかだと思えるが、経験から言えばこれが常に行われているわけではなく、結果的には製品と顧客の期待やニーズの間にかなりのズレが生じる。推奨されるユーザーの「確認ポイント」と、各ポイントでプロダクト・マネージャが分担する作業を下記の表にいくつか示す。

確認ポイント プロダクト・マネージャの役割
コンセプトの展開 要件に関する話し合いの場を設け、ストーリーボードやプレゼンテーションなどの“ソフト”モデルを用意して顧客からフィードバックを引き出す
ビジョン ビジョンドキュメントの用意を中心となって引き受け、これを利害関係者全員に配布してチェックしてもらう。入力情報を集めてまとめ、意見の一致を引き出す
ユースケースモデルの整備 ユースケースモデル全体の整備と考察を推進する。重要なユースケースには直接関与する。ユースケースの作成者を指導し、すべての作業をチェックする
アルファテスト（社内使用および初期導入顧客向けプログラム） このテストプロセスを定義し監視する。手続きの定義や評価基準を監督し、確実にすべてのユースケースがテストされ、フィードバックが集まるようにする
ベータテスト（最初の正式な顧客評価プロセス） 営業部隊と協力してベータ版を試用する顧客を選定・確保する。ビジネス条件を定義し、それを文書化する。発表や顧客の期待をうまく管理する。フィードバックを集めて開発部隊に戻す

操作性の完成

　完全なソリューション製品を作成するには、これまで述べてきた作業に加え、ユーザーの操作性に直接影響を及ぼすほかの無数の成果物に詳細に注意を払わなくてはならない。マニュアルやオンライン・ヘルプ・システムの一部には明確なニーズがあるものの、著作権の通知、起動時のスプラッシュ画面、ロゴの順守といった当初は重視されないものもある。だが、これらが組み合わさるとユーザーの操作性に大きな影響がある。表2にいくつかの重要な成果物に関するチェックリストを示し、それぞれに対するプロダクト・マネージャの役割を説明する。

項目／成果物 プロダクト・マネージャの役割
ユーザー向けのドキュメント コンセプトの展開、設計、およびコンテンツ立案に参加する
マニュアル、オンラインヘルプ　 コンセプトの展開、設計、およびコンテンツ立案に参加する
そのほかのサポート資料（ReadMe、ヘルプ、アプリケーション情報、リリースノート、管理／セットアップノート） コンセプトの展開、設計、およびコンテンツ立案に参加する
サポートソフトウェア：インストールプロシージャ、外部スクリプト、組込チュートリアル、各種ユーティリティー コンセプトの展開、設計、およびコンテンツ立案に参加する
ユーザー向けプレゼンテーション
企業ロゴ、製品ロゴ、グラフィックスの規格		 標準を提示もしくは定義し、インプリメンテーションチームと連絡を取って準拠状況を監視する

■ビジネス条件の定義

　製品を市場に投入する準備を整える前に下さなくてはならないもう1つの判断は、会社と顧客との関係に関するビジネス条件を定義するものだ。これらは、製品の成功にとって製品の機能自体と同じくらい重要なものとなる可能性が高い。これらの判断の中にはプロダクト・マネージャの担当外だったり、権限外だったりするものもあるが、製品を先頭に立って擁護する者として、プロダクト・マネージャはコンセンサスの形成や意思決定作業を推進する際に「自分が全責任を負う」ことを明確に自覚していなくてはならない。以下の表3では、これらの作業と、それぞれに対応するプロダクト・マネージャの役割を浮き彫りにする。

項目／成果物 プロダクト・マネージャの役割
ライセンス供与 ライセンスの供与や強制を明確化する。開発チームと協力してライセンス供与のユースケースを定義し、インプリメントする。法務部門と協力してライセンス規定の草案を起こす。業務部門と協力してライセンスのメカニズムを定義し、インプリメントする
価格設定ポリシー　 製品の価格設定やディスカウント体系を円滑に展開し、定義する。営業や業務部門と協力して提案価格を確立する
カスタマサポート アクセスメカニズム、サポートレベル、SLA（サービスレベル契約）、アップグレードポリシー、価格設定などのサポートポリシーを定義する

■ポジショニングとメッセージを伝えること

　プロダクト・マネージャはマーケティング部門の臨時メンバーとして製品のポジショニングも担当する。また、小売業界のことわざにもあるように、成功へのカギは「1にも2にもロケーション」である。成功する可能性は通行人たちを自分の店舗の中に呼び入れる能力に大きく依存する。人々が店舗を訪れるのは、顧客獲得策やプロモーション手法のせいではなく、その店舗が便利なロケーションにあったからなのだ。

　これと同じことがソフトウェアにもいえる。しかし、われわれの業界におけるロケーションは物理的なものというよりむしろ仮想的なものであるため、ポジションの概念がロケーションの代役を務める。あなたの会社が引き受けるのは、顧客の心の中にロケーション、つまり製品の長所を強調し、その短所をできるだけ目立たないようにし、最終的には顧客に他社のではなくあなたの会社のソフトウェアを選ばせるようにするポジションを作り出す作業だ。換言すれば、あなたの会社の製品やサービスを市場内の他社と差別化する手法がポジショニングなのだ。

　あなたや、あなたの製品、マーケティング部門の同僚が会社の製品に関して何と思おうと、購入するかどうかを最終的に決めるのは潜在顧客である。

　ポジショニングを整理するテクニックとして、Geoffrey Moore氏*2が以下のような出発点を推奨している。

対象 ターゲット顧客
用途 必要性や可能性の記述
タイトル（製品名） 製品（製品カテゴリ
ポイント 重要な利点、つまり説得力のある購入理由の説明
他製品 主要競合製品
自社製品 主要差別化要素

　このシンプルな目的説明に関してあなたとチームの意見が一致すれば、堅牢なメッセージ伝達プラットフォームを構築できる可能性が高い。

　もちろん、簡潔で、なおかつ忘れられないようなものでなければポジションの確立には役に立たない。会社のポジションを言葉で裏付け、顧客に対する販売プランの説明に利用可能なプラットフォームを構築するということがメッセージ伝達の役割なのである。

　故に、そのメッセージに「てきとうな言葉」を使うわけにはいかない。そのメッセージには、あなたとチームが製品に込めたコンセプトをあらゆる手段（紙媒体、ラジオ、営業プレゼンテーションなど）を用いて市場に伝えるための具体的な言葉や言い回しが含まれる。さらに、今日のような情報過多の時代では、製品に関与する人々が製品やサービスについて説明をするときに利用する言葉をできるだけ絞る必要がある。社外に対して会社の説明を行うときには、業界紙、地方のマスコミ、業界アナリスト、カスタマー、パートナーなど、相手にかかわらずあなたの会社の社員全員が同じ言葉を同じように使うことを学ぶ必要がある。そうしないと、顧客がすぐに混乱し、プロモーション力で上回るライバル会社の執拗（しつよう）な攻撃によってメッセージが伝わらなくなってしまう。

　メッセージを伝えることでチームの同意を得られたら、メッセージの核となるプラットフォームに伝えるべき内容を記述しておくとよい。このドキュメントは、基本的なメッセージのほかに、製品やソリューションの機能を簡潔かつ的を絞った形で要約してくれる。これにより、メッセージの核となるプラットフォームは、Webサイト、データシート、デモといった各種営業資料を含む製品マーケティング関連のすべての成果物に対する基本的な入力情報の役目を果たすことになる。

支援活動

　一般にはほかの担当者が主導するものだが、効果的かつ完全なソリューション製品を作り出すためにプロダクト・マネージャが関与しなくてはならない作業はほかにも多数ある。以下にそれらの例を示す。

■ブランドの展開と製品の商標

　この作業は通常マーケティング部門の独擅場だが、プロダクト・マネージャも結果を定義し、完成に向けて一役買うことで、重要な役割を果たす。具体例としては、通常は製品管理部門が製品のネーミングに関与し、マニュアル全体、スタートアップ画面、メニュー、そしてアプリケーション内のそのほかの各種ユーザーインターフェイス・アイテム全体に対して名称やロゴが確実に適用されるようにしていく。

■エンドユーザー向けトレーニングマニュアル

　大半のアプリケーション・ソフトウェアが何らかの新しい手法を取り入れている。それが製品データをほかの言語に変換するためのプロセスであれ、オブジェクト指向デザインのための新たな手法であれ、より少ない在庫で製造工場を運営する方法であっても、あなたの会社のソフトウェアにはおそらく製品の使い方と手順の両方に関するユーザー・トレーニングが必要になるだろう。有能なユーザーは製品成功のための必要条件であるため、通常はプロダクト・マネージャが、トレーニングを展開する中でアドバイザー的な役割を果たすことになり、必要な内容についての専門知識を提供する（もしくは見いだす）作業に関与することになる。

■製品のデモ

　整理されておらず、伝え方も悪い製品のデモほど潜在顧客の関心を短時間で失わせてしまうものはない。典型的なエンジニアリング手法である製品の機能に関する「一通りの説明」は、あなたの顧客を死ぬほど退屈させてしまう可能性が高い。もっと悪いのは、デモ担当者の話があちこちに飛び、顧客が流れについていけなくなってしまったり、混乱することによって、あなたのいう「簡単に使える」ソフトウェアにおじけづいてしまうことだ。しかし、製品のデモがうまくいけば、自社製品を使うことでどれだけ作業を改善できるのかを潜在顧客に示したり、重要なポジショニングやメッセージを示す（もしくは強調する）のにこれ以上のチャンスはない。デモが確実に効果を発揮し、潜在顧客向けにソリューションを適切にポジショニングしてくれるようにするため、プロダクト・マネージャは指導力を発揮して具体的なデモのスクリプトやサポート・データ、そしてインターフェイスやデータセットを提供しなくてはならない。

■営業／マーケティングツール

　通常、営業／マーケティング関連のものは製品マーケティング部門が牛耳っているが、新製品の機能やメリットを適切に分析できるのはプロダクト・マネージャ以外に思いつかない。また、技術知識の高いいくつかのチームのメンバー代表として、プロダクト・マネージャがセールストレーニング資料の開発と提供に直接関与する場合もある。

大仕事に対する大きな見返り

　これまで見てきたように、成功するソフトウェア製品を開発するには単にアプリケーションをCDにパッケージングし、インストール・スクリプトを付加しただけでは到底不十分だ。個人ユーザーのほか、そのユーザーの会社のビジネス・ニーズにも対応する完全なソリューション製品を作り出すために一緒に組み合わせなくてはならない条件としては、技術的なもの、ビジネス上のものなど、ほかにも多数ある。これらの追加条件を定義し、決定する権限をプロダクト・マネージャ（製品管理チーム）に与えることで、ソフトウェアチームは完全なソリューション製品を適切に定義し、開発し、ポジショニングを行って、最終的には市場に適切に配付されるよう支援できるようになる。

　このことは、プロダクト・マネージャにかなり広範囲に及ぶ責務と相当な努力が必要になることを意味するが、それに対しては大きな見返りがある。製品がこれだけの配慮とサポートを受ければ成功への道は遠くないのだ。

[参考資料]
「Rational Unified Process 2001」米Rational Software Corporation刊（2001年）
「Managing Software Requirements: A Unified Approach」（ソフトウェア要求管理：新世代の統一アプローチ）Dean Leffingwell、Don Widrig共著、Addison-Wesley刊（1999年）
メモ
1.この図は著者が用意したものであり、正式にRUPの一部となっているものではない。
2.「Crossing the Chasm: Marketing and Selling Technology Products to Mainstream Customers」（キャズム：ハイテクをブレイクさせる「超」マーケティング理論）Geoffrey A Moore著、HarperCollins刊（1991年）
本記事は「The Rational Edge」に掲載された「The Role of Product Management in a Software Products Company」をアットマーク・アイティが翻訳したものです。
「The Rational Edge」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.