見出し画像

Project Management と Product Management の違いと今後の展望

Management形態の違い

この2つに携わることが増えてきた。情報整理と情報共有のためにテーマ化した。
プロジェクトマネジメントとプロダクトマネジメントは、プロジェクトで生み出される成果物に対する責任という意味においては役割として重なる部分はあるものの、本質的には別々のものなのであろうか。

工業国としての日本は過去、良い製品を作れば売れる時代があった。そこではジャパンクオリティが世界を席巻していた。「トヨタ式カイゼンで効率化」というオペレーショナルエクセレンスが素晴らしいというマインドセットであるため、プロジェクトマネジメントとの相性が良かった。

現代は、GAFAに代表されるデジタルサービスにより、「他社との差別化はユーザ体験」であったり「小さく始め、クイックに改良する」いうアプローチが善とされるようになり、結果、成果物をリリースした後のGrowthに対してどうコミットしていくかの意識が強くなってきている。

プロジェクトマネジメントとプロダクトマネジメントは、その役割の性質上、前者は外部から人員調達できるところがあるが、後者はそのプロジェクトのオーナー側が担わねばならない。

本質的に違うこの二つの思想の連携と融合を実現できると、その企業のプレゼンスを高めることになるだろう。

それぞれの役割と曖昧さ

日本においては、プロダクトマネジメントの認知と理解は低いと言える。その理由は、先に挙げた工業国としての成り立ちが主な要因だと思うが、定義としての曖昧さも付いて回る。

「プロダクト」や「マネジメント」の意味する日本語が、本質的な認識と理解を妨げている。プロダクト (≒ または ≠) 製品、マネジメント (≒ または ≠) 管理、プロジェクト (≒ または ≠) 計画であるし、更には、「プロジェクトマネジメント」と「システム開発管理」も同一ではない。

また、「プロダクトマネジメント」についても、その成果物が「物理製品」(例えば、ウェアラブルデバイス)なのか「論理サービス」(例えばWEBサービス)なのかによっても、マネジメントアプローチが異なるところが更にややこしい。

プロダクトマネジメントとしては、製品またはサービスを成功させるためのフレームワークとして「4P分析」(Product、Price、Place、Promotion)があるが、プロジェクトマネジメントとしては製品またはサービスの「QCD分析」(Quality、Cost、Delivery)を突き詰めることにモチベーションがある。
そして、この両者の思想の違いにより現場において一番争うことになるであろうポイントは、「リリーススケジュール」だ。

プロダクトマネジメントは、製品やサービスの「What・Why」に責任を持ち、そのプロダクトが生み出す価値や、世の中に対するインパクトがどれくらいなのかを重視する。
一方プロジェクトマネジメントは、製品やサービスの「When・How」に責任を持つ。それが実績が無い物や予算制約があるような場合には、いかに着実にプロジェクトを進行させるかに心血をそそぐ。その為、成果物のリリースに対する全く違った認識が発生するのだ。

実はプロダクトマネジメントは、ハードウェアデバイスなどの「物理製品」場合の開発アプローチは「ウォーターフォール文化」だ。しかし、WEBやモバイルアプリなどの「論理サービス」であれば「アジャイル文化」なのである。
その為、一番複雑なのは、「物理製品」と「論理サービス」「モバイル開発」を併せ持ったプロジェクトを進める場合だ。

 

ハードウェア開発はウォーターフォールである

ハードウェア開発が絡む場合は、ソフトウェア開発のように簡単にはスクラップ&ビルドはできない。なぜならば、「物理製品」を取り扱う場合において、その開発、生産プロセスは後戻りできない性質のものであり、かつ、金型や生産ラインの構築に多額の費用が発生するからだ。
そしてそれが電子媒体であれば、技適など様々なレギュレーションや製造物責任法などのリーガルな責任も発生する。

 

モバイル開発はアジャイルである

一方で、そういった物理制約の無いソフトウェアの世界では、実用最小限の製品(Minimum Viable Functionally)を作ることが良しとされている。また、デザイン思考を用い、ユーザ中心主義としての改良アプローチを推奨してもいる。

 

プロジェクトマネジメントは、段取りと地雷除去の連続である

プロジェクトマネジメントの知識体系としてPMBOKがあり、マネジメントフレームワークとして、5つのプロセスと10の知識エリアが定義されている。
分かりやすく言えば、「首尾よく段取りよく着実に仕事を遂行すること」を目的にしたテクニックの集まりである。
そして、この目的を妨げるものは全て悪であり、プロジェクトとして地雷を踏んでダメージを受けないようにする為の回避策が実は一番重要だったりする。

//5つのプロセス
・立上げプロセス群
・計画プロセス群 
・実行プロセス群 
・監視・コントロール・プロセス群
・終結プロセス群

//10の知識エリア
・統合マネジメント
・スコープマネジメント
・スケジュールマネジメント
・コストマネジメント
・品質マネジメント
・資源マネジメント
・コミュニケーションマネジメント
・リスクマネジメント
・調達マネジメント
・ステークホルダーマネジメント
出典: フリー百科事典『ウィキペディア(Wikipedia)』

  

システム開発管理は、バイモーダルである

昨今のデジタルディスラプションというワードに代表されるデジタル化の波は激しく、企業の情報システム部門の存在意義を問われるようになっている。
以前から使っている業務システムや基幹システムなどを代表とする「開発予算の大きいウォターフォール開発」と、コンシューマ向けサービスの「アジャイル開発」が企業の中で混在するようになってきており、その両方をうまく使いこなすことが大事な方法論となってきている。


「プロダクト」「マーケティング」「システム」が協力することで生まれるもの

これらを見るだけでも相当の守備範囲であることが分かるだろう。
「物理製品」と「論理サービス」と開発アプローチとしての「モバイル開発」の融合は、かなりハードルが高いものであるが、逆に言いえば、それが実現できれば、その企業の相当の差別化要因にはなるだろう。
実現方法のベストプラクティスはまだ見つからないが、「プロダクト」「マーケティング」「システム」の異なる思想同士の3つが鼎立・協調できると良い何かが生まれそうだ。


そして更に、その製品やサービスが事業化できると判断した時には、企業として利益を産むための仕組み作りと業務設計も関わってくる。


リアルとデジタルの融合というトレンドは、プロダクトマネジメントとプロジェクトマネジメントの融合も強制する

製品やサービスを生み出し、成功させるための領域とステップを改めて整理してみると果てしなく大変なものだと思う。
しかしイノベーションを起こすための勘所は、「異分野・異思考・異スキル」の組み合わせが良いようであるから、だからこそこれらがかみ合った時のインパクトは大きいものだろう。GAFAの中でも、AppleとAmazonが突出しているように見えるのは、この「物理製品」と「論理サービス」の両方を実現しているからだ。

Photo by Fancycrave.com from Pexels

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

3

Takuma Sato

リベラルアーツとテクノロジーに興味がある。 ITアーキテクト/SREエンジニア
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。