第１章：製品開発の鍵を握る担当者とその役割
－現代のソフトウェア製品開発のための組織とは？
この本全体を通して、製品開発チームにおいて鍵を握る担当者の役割について述べていく。まずこの第１章では、私がそれぞれの肩書や役割の名称をどういう意味で使っているのかを明確にしておこう。すべての企業がこれとまったく同じ呼び方で同じ役割を持たせているとは限らないことは承知の上である。ただ、呼び方はどうあれ、いちばん成果を挙げている企業には、間違いなくこうした役割を担当する人たちがいるはずだ。彼らがそれぞれの役目を果たさなければ、製品の成功はあり得ない。
この本の中で、「ソフトウェア製品」、「ソフトウェア」または、「ソフト」といった言葉を使っているが、これは、必ずしも企業向け、消費者向けのパッケージソフトだけを指すのではない。こうした言葉には、インターネット上で提供されるサービス、家庭用電子機器、ソフトウェアが中心的な役割を持つ機器なども、含まれることに注意されたい。
プロダクトマネージャーの役割
プロダクトマネージャーの主な任務は二つある。製品の市場性を評価することと、開発すべき製品を定義することである。通常、新しい製品のアイデアは至るところから飛び出してくる。たとえば、経営陣、顧客との議論、使用感テスト、製品開発チーム自身、営業担当者、業界関係者などだ。しかし、次に、誰かがそのアイデアを吟味して、さらに先に進める価値のあるものかどうかを決めなければならない。この目利きをやるのが、プロダクトマネージャーである。（多くの企業では、これを市場要求仕様(MRD, Market Requirement Document)という書類にまとめるが、この本では、後ほど、その軽量版である市場機会評価(Opportunity Assessment)について説明する。)
十分に市場性があって、自社でそのアイデアを実現できる可能性が高いと判断されれば、その次には、誰かが、そのアイデアの具体的な形、つまり、どういう製品にするのか（必要とされる特性と機能、ユーザーエクスペリエンス、発売の基準など）を「見つけ出す」必要がある。ここで、再びプロダクトマネージャーの出番となる。この任務は、プロダクトマネージャーの仕事の核心部分である。こうして形になっていく仕様は、製品要求仕様(PRD, Product Requirement Document)、あるいは、製品仕様、機能仕様などと呼ばれる。ここで、私は、紙ベースではなく、プロトタイプに基づく軽量なアプローチを勧める。しかし、肝心なのは、その仕様書が記述すべきことは、開発されるソフトがどういう機能を備えて何をするものかということであり、どのように動くかではないということだ。
ユーザーエクスペリエンスデザイナーの役割
ユーザーエクスペリエンス（ユーザー体験）を設計する組織の中には、いくつもの役割がある。それぞれの役割については、後デ詳しく説明するが、その中で重要なのはインタラクションデザイナーである（インフォメーションアーキテクト、ユーザーインターフェースデザイナー、またはユーザーエクスペリエンスアーキテクトともいう）。彼らの任務は、製品が対象とするユーザー（ペルソナ、すなわち、その製品がターゲットとし、ニーズを満たしたいと対象とする架空のユーザー像）深く理解した上で、有効で生産性の高いワークフロー（作業、指示、および順序）を作り上げることである。彼らは、プロダクトマネージャーと協力して、ユーザーのニーズに合うように要求仕様とデザインの調和を図ろうとする。つまり、その製品が使いやすく（ユーザーが使い方を理解できる）価値のある（ユーザーが使いたいと思う）ものとなるはずだ、というところまで導くのである。
プロジェクトマネジメントの役割
製品が定義されれば、製品開発チームがプロジェクトを引き継ぎ、製品の開発に取りかかる。プロジェクトのスケジュールや工程・進捗の管理することが、プロジェクトマネジメントの中心的な作業となる。スケジュール管理や進捗管理を誰が担当するかについては、いくつかのモデルがある。専任のプロジェクトマネージャーが置かれることもあるし、エンジニアリングマネージャーがプロジェクトマネジメントを担当することもある（というのも、プロジェクトのメンバーの多くはエンジニアリング部門から投入されるためである）。また、プロダクトマネージャーがプロジェクトマネージャーを兼任する場合もある。誰がプロジェクトマネジメントを担当するかは、企業の文化やプロジェクトの規模で決まることが多い。プロジェクトが大きくなれば、経験豊富な専任のプロジェクトマネージャーを置く必要性が高まる。
エンジニアリングの役割
製品開発やソフトウェア開発（者）ともいうが、彼らは実際に製品を開発する人たちである。「IT」(Information Technology)などという言い方をする会社もあるが、外部の顧客向けに開発するソフトウェアと、人事管理アプリケーションなど社内向けに開発するソフトウェアを明確に区別することが重要である。通常、ITという言葉は、社内のサポートをする部門を指す場合に使われ、それに対して、エンジニアリング部門は、外部の顧客に提供する製品を開発、サポートする場合が多い。
サイト運用の役割
インターネットサービス企業が提供する製品は、通常、中央のサーバーで稼働していて、ユーザーはウェブ上でその製品を利用する。そのウェブサイトを運用するチームは、ウェブ上のサービスを常時稼働させる任務を負っている。エンジニアリングチームが運用まで担当することもあるが、多くの企業は、サイト運用というのは、それに見合った技量が必要とする任務であって、その責任は非常に重く、片手間でやれるようなことではない、ということを認めている。
プロダクトマーケティングの役割
プロダクトマーケティングチームの任務は、製品を世界中に知らしめること、製品を対外的に発表すること、販売チャネルで製品を売り込むためのツールの提供、そして、オンラインでのマーケティングや市場関係者に対する製品のマーケティングといったような主要なマーケティング活動を指揮することである。しばしば、一人の人間にプロダクトマネジメント（製品の定義）とプロダクトマーケティングの両方を担当させている会社を見かける。実は、この二つの役割にはまったく異なる技能が必要なので、兼務するのは非常に難しい。にもかかわらず、このような役割分担を行っている企業が少なくない。
メモ
マイクロソフトでは、製品を定義し、スケジュールを管理する人をプログラムマネージャーと呼んでいたが、これは非常に残念なことだ。というのは、業界内では、すでに、この言葉は、複数のチームが関与するプロジェクトの管理をする人の肩書きとして広く使われているからである。しかし、マイクロソフトは、代わりにプロダクトマネージャーという言葉を使うこともできなかった。なぜなら、その言葉は、すでにプロダクトマーケティングの役割を表すものとして使われていたからだ。マイクロソフトがこういう言葉の使い方をしていることを残念に思うけれども、彼らは、製品を定義するというプロダクトマネージャー本来の役割をかなりうまくこなしていたと思う。
コラム１
アジャイルなチームとは何か？
私が関わってきた製品開発の組織のほとんどが、「アジャイル(Agile)」な手法を用いている。特に、最もよく使われているのは、スクラム(Scrum)だろう。こうした言葉を聞いたことがなくてもご心配なく。「アジャイルな手法で成功する」の章で詳しく説明する。
スクラムを使っているソフトウェア開発の組織では、プロダクトマネージャーが製品開発の最終責任者であり、また、通常、プロジェクトマネージャーがスクラムマスターとなる。この章で説明してきた他の役割については、基本的にそのままでよい。
しかし、製品開発の組織がユーザーエクスペリエンスや製品の発売まで担当する場合においては、アジャイルな手法をうまく使うために、十分に注意しなければならないことがいくつかある。この点については、この本全体でおいおい説明していく。
コラム２
それぞれの担当者の適切な割合は？
ソフトウェア開発の組織には、プロダクトマネージャーとデザイナーとエンジニアの適正な割合があることが分かっている。というのは、エンジニアリングチームが高付加価値の使えるソフトの開発に専念するためには、プロダクトマネージャーとデザイナーが一定量の仕事をこなす必要があるからである（つまり、一定の人数のプロダクトマネージャーとデザイナーが必要ということである）。
もちろん、これ以外にも、担当者の適正な割合に影響を与える要素としては、開発するソフトウェアの種類、そしてメンバーの経験や技量といったものがあるが、適正値の目安を以下に示す。
Q: プロダクトマネージャーは何人ぐらい必要か？
A: 一般的に、5人から10人のエンジニアに対して、1人のプロダクトマネージャーが必要になる。
Q: ユーザーエクスペリエンスデザイナーは何人ぐらい必要か？
A: ユーザーエクスペリエンスデザイナー1人でプロダクトマネージャー2人をサポートし、ビジュアルデザイナー1人で4人のインタラクションデザイナーをサポートできる。
Q: 専任のプロジェクトマネージャーは必要か？
A:エンジニアが5人以上のプロジェクトなら、専任のプロジェクトマネージャーが必要。もし、「トレインモデル」を使っているなら、トレインごとにプロジェクトマネージャーが絶対に必要。（トレインモデルとは、一週間から四週間ごとに機能を追加しながら継続的に製品をリリースする手法で、追加機能の実装が間に合わなければ、その機能は次のリリース、つまり、次のトレインに回される。一回のリリースで、複数のプロジェクトが開発しているソフトウェアをがカバーしていることも多い。）
Inspired日本語版 