Inspired日本語版

How To Create Products Customers Love

第3章 プロダクトマネジメント VS. プロジェクトマネジメント

第3章:
プロダクトマネジメント VS. プロジェクトマネジメント
-インターネットがこの二つの役割分担をも変えた

第2章では、プロダクトマネジメントの役割とプロダクトマーケティングの役割を明確に区別することがいかに重要かについて述べた。多くの会社は、もう一つ似たような問題を抱えている。それは、プロダクトマネジメントとプロジェクトマネジメントを兼務する場合の問題だ。

多くのインターネット企業は、いまだにプロダクトマネジメントにプロジェクトマネジメントを含めているが、その理由は、こうした手法や流儀の多くはパッケージソフトの世界に由来しているからだ。パッケージソフト(たとえば、マイクロソフトを有名にしたOfficeのようなソフトウェア製品など)の世界では、プロダクトマネージャーがプロジェクトマネジメントもやるのが普通である。でも、パッケージソフトの場合はそれでよくても、このアプローチはインターネットの世界では通用しない。

その理由を知るために、まずインターネットの歴史をちょっと振り返ってみよう。インターネットサービスが1996年頃に登場した時、まず私たちは、プロダクトマネージャーと名乗り続けていいものかどうか悩んだ。というのも、旅行の予約のウェブサイトのようなものは、従来からのパッケージソフトよりもずっとサービス指向のソフトに思えたからだ。しかし、この悩みはすぐに解決した。

当初、私たちは、引き続きプロダクトマネージャーにプロジェクトマネージャーを兼務させようとした。ネットスケープやヤフーのような初期のインターネット企業はこのアプローチでやろうしたが、問題にぶち当たった。パッケージソフトの世界では、製品は。すべての機能を内蔵してパッケージにされているのが一般的であり、一度パッケージがリリースされると、次がリリースされるまでに数ヶ月、場合によっては数年かかる。だから、製品とプロジェクトは、一般的に作業の精度や頻度の点で一致していて、プロダクトマネージャーがプロジェクトマネージャーを兼ねることが比較的容易なのだ。でも、ウェブサービスの世界では、このやり方だと破綻を来す。

多くのインターネットサービス企業は、大きな共通のコードベースに対して小規模な改良をこまめにやる必要がある、と気づいた。そして、典型的なプロジェクトは、次のリリース(だいたい週単位から月単位)までに間に合わないほど大量の作業が必要となったので、並行して複数の開発プロジェクトを進めたり、改良版のリリースにトレインモデルを採用したりするようになった。ほとんどのインターネット企業は、スタートアップ段階を終えてもこのトレインモデルを使っている。

このトレインモデル自体がひとつのテーマになるのだが、この本でいちばん重要なポイントは、トレインというのは、積極的で強力なプロジェクトマネジメントで管理される必要があり、そうしたプロジェクトマネジメントは、特定のプロジェクトだけを対象とするのではなく、あるリリースでカバーされるプロジェクト全部を全体として管理するものである、という点だ。通常、トレインでは、多くのプロジェクトやプロジェクトマネージャーの諸事情を踏まえた上で、リリース管理、エンジニアリング、サイト運用、顧客サービス、プロダクトマネジメントといった重要な調整をやらなければならない。リリーストレインのプロジェクトマネージャーのことを、トレインコンダクターと呼んでいるインターネット企業もある。

トレインモデルを使っていて、リリースの対象となるトレインごとに専任のプロジェクトマネージャーがいるならば、普通は、プロダクトマネージャーはプロジェクトマネジメントまで担当する必要はなくなる。

歴史の話に戻ろう。ソフトウェア製品やウェブサイトの進化とともにヤフー、ネットスケープ、AOLといった企業のリリースプロセスが洗練されてくるにつれ、プロダクトマネジメントはプロジェクトマネジメントの担当範囲からは外れていき、こうした企業はみな、専任の担当者に強力にプロジェクトマネジメントを推進させる力を身につけていった。eBayやGoogleといったもっと新しいインターネット企業の多くは、プロダクトマネジメントからエンジニアリングやサイト運用まで担当する非常に強力なプロジェクトマネジメントチームがあったからこそ、あれほどの量と質のソフトウェア製品をリリースし続けることができたのだろう。

話をまとめると、インターネットサービス企業にとっては、プロダクトマネジメントとプロジェクトマネジメントの役割を明確に分けることが非常に重要だ。そうしないと、リリースの管理に悪戦苦闘する羽目になり、リリースは常に遅れ、必要以上に時間をかけなければならなくなるだろう。

パッケージソフトを作る場合でも、やはり役割を明確に分けることが有益だと思う。その理由は、プロダクトマネジメントとプロジェクトマネジメントの本質にある。プロダクトマネジメントの役割が、価値のある、使い勝手のいい、実現可能な製品を見いだすことにあるのに対して、プロジェクトマネジメントの役割は、製品を市場に送り出すことに尽きるからだ。


コラム 優れたプロジェクトマネージャーの7つの条件


製品開発に成功している企業を見ると、並外れて優秀で、それゆえに他の企業に差をつけることを可能にするような人たちがいることがわかる。ここに優れた製品とダメな製品の違いがあるのかもしれない。あるいは、ビジネスパートナーを得てお客様に製品を届けることができるか、世に知られることなく埋もれているかの違いかもしれない。あるいは、製品を世に送り出せるか、それとも、遅れが積み重なって製品開発が行き詰ってしまうかの違いかもしれない。

イーベイは、明らかに大成功を収めている会社である。そして、製品開発におけるそれぞれの役割を担うために、とてつもなく優秀な人たちが控えている。

イーベイでは、並外れた製品開発プロセスができあがっている。このプロセスには、三つの際立った特徴がある。それは、非常に生産性が高いこと、すこぶる要求が厳しいこと、そして、強力なプロジェクトマネジメントの力量に支えられていることである。

このイーベイが誇るプロジェクトマネジメント力を確立したのは、リン・リーディー(Lynn Reedy)である。彼女は、私が一緒に仕事をする機会を与えられた仲間の中でも、最高のプロジェクトマネジメントができる逸材だ。私は、イーベイに入るまでは、自分ではプロジェクトマネジメントがけっこう得意な方だと思っていたが、リンに出会って、優れたプロジェクトマネージャーの基準がどこにあるというものを教えられた。

たとえばマイクロソフトのような会社では、プロダクトマネージャーは、プロジェクトマネジメントの全部または一部についても担当する。卓越したプロジェクトマネジメントの能力を身につけることは、プロダクトマネージャーにとっても非常に有利なことであるのは確かだろう。少なくとも、製品をより早く市場に届けることができる。それは、結局のところ、開発した製品を市場に送り出すことができたという点で、失敗に終わった製品開発に差をつけることができる。しかし、ここでも強調しておきたいのは、プロジェクトマネージャーとプロダクトマネージャーは別の役割であるということだ。

私には、多くの人が、マイクロソフトと同じような捉え方でプロジェクトマネジメントを捉えているように思える。しかし、それでは、プロジェクトマネジメントの何たるかを見逃してしまう。ここで、リンのようなすばらしいプロジェクトマネージャーが備えていると私が考えている、7つのスキルを挙げてみよう。

緊迫感 リンは、歩いて入ってくるだけで、中はたちまち緊迫感が流れる。ミーティング前のおしゃべりはたぶん60秒ぐらい。そして、打合せが始まる。これは、彼女の砂糖とカフェインによるユニークなダイエットによるところもあるだろうが、実際のところ、緊迫感そして効率性がイーベイ社風の要であって、それを代表格がリンである。

立案者たること 目的のはっきりしない非建設的な会議になってしまうのには、多くの理由がある。その中でも最大の原因のひとつは、会議の目的は何か、何を解決しようとしているのか、具体的な課題や問題は何か、といったことが参加者に明確に示されていないことだ。優れたプロジェクトマネージャーは、問題を明確かつ簡潔に特定して整理し、建設的な会議を運営する方法を心得ている。

明晰な思考力 よくあるビジネス上の問題には、通常、複数の原因があって、そこに、関係者の力関係、個人的な問題、個性といったものがかなり入り混じっている。これらにうまく対処できなければ、製品開発が遅れてしまい、混乱を収める見通しも立たなくなる。プロジェクトマネージャーは、個々の問題をそれぞれ区別し、感情やしがらみをほぐすことで、根底にある問題を明らかにし、みんなが問題の解決に集中できるようにする必要がある。

データ指向 優れたプロジェクトマネージャーは、自分たちが現在どこにいて、これからどこに向かうべきかを正確に知る上で、データが重要な役割を果たすことを理解している。彼らは、常に製品開発プロセスとその結果を改善することを目指していて、そのための出発点がデータ測定にあることを理解しているのだ。よく考えずに反射的に行動することは、あまりにも安易であり、時間を気にしなければならない状況ではなおさらそうだ。だから、プロジェクトマネージャーにとって肝心なことは、データを求め、データの背後にある事実に裏付けられた意思決定をすることである。

決断力 多くの組織モデルにおいて、実際のところは、製品チームのメンバーたちはプロジェクトマネージャーに報告をしてくれないものだ。それでも、プロジェクトマネージャーはどんどん意思決定をしなければならない。この意思決定の局面で、プロジェクトマネージャーは、緊迫感を伝え、問題を明確にし、合理的で透明性のある理由付けをして、データに基づいた意思決定をしなければならない。また、プロジェクトマネージャーは、チーム内からのデータや意見をいつ集めればよいか、いつ問題を経営陣に上げればよいかを知っておく必要がある。

判断力 ここまで述べきたスキルのほとんどは、優れた判断に依存している。つまり、いつ他のメンバーのお尻を叩くのか、いつ経営陣に報告するか、いつ追加情報を集めるか、いつ場所を変えてちょっとプライベートおしゃべりをすればいいか、などを心得ている。こうした特性については、人から教わるのは難しく、経験がモノを言う。

姿勢 最後に。製品が出荷できないでいる時、いくらでも言い訳はできる。人が足りない、時間が足りない、資金が足りない、などなど。プロジェクトマネージャーの仕事とは、こうした障害をひとつひとつ乗り越えることである。優れたプロジェクトマネージャーは言い訳をしない。やり遂げるのだ。粘り強くて、とどまることを知らない。

リンがイーベイとその企業文化にもたらしたプロジェクトマネジメントの規律がなかったならば、イーベイに今日のような成功はなかっただろう、と私は堅く信じている。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

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