プロジェクトマネジメントの限界
野崎:アトラシアンでは、プロダクトマネジメントを効率化するためのツールとして、プロダクトチームとビジネスチーム、技術チームの様々なアイディアを融合させ、合意形成と意思決定を行うための製品「Jira Product Discovery」の提供を先日より開始しました。そこで、日本のプロダクトマネジメントに携わる方々が、いま、どのような状況に置かれ、どういった課題と対峙しているかを改めて紐解きたいと考え、今回の企画に至りました。
浪川氏(以下、敬称略):なるほど。お声がけいただき、ありがとうございます。
野崎:こちらこそ、ありがとうございます。
浪川さんは、プロジェクトマネージャーやプロダクトマネージャーの学びの場である「開発PM勉強会」を主催されています。また、ご自身もプロダクトマネージャーとして活躍されています。その浪川さんに、プロダクトマネジメントの現場の状況をさまざまにお聞かせいただこうと考え、この場を設定した次第です。
浪川:承知しました。よろしくお願いします。
野崎:さて、浪川さんはプロダクトマネージャーとしてはかなり異色の経歴をお持ちであるように思えます。確か、音楽関係のお仕事から、エンジニアに転身され、そこからプロジェクトマネジメントやプロダクトマネジメントに携わるようになったと拝見しました。
浪川:おっしゃるように、私のキャリアのスタートは音楽関係の仕事で、楽器の販売や音楽教室のマーケティングに3年ほど携わっていました。その中でWebサイトを使ったデジタルマーケティングやSNSマーケティングに興味を抱き、この領域の技術スキルを身につけようと2014年にIT企業に転職し、エンジニアとして働き始めました。
野崎:なるほど、その転職がプロダクトマネージャーへの道のファーストステップとなったわけですね。
浪川:そういえます。2014年に入社したIT企業は、いわゆるシステムインテグレーター(以下、SIer)です。その会社で開発のタスクをこなしているうちに、自分の作った成果物がユーザーにどう使われるのか、ということが気になるようになり、お客さまとやり取りしながらプロジェクトを回していく仕事に従事するようになりました。要するに、プロジェクトマネージャーの立場で開発案件にかかわるようになったということです。その経験を糧に独立してPeerQuestを起業し、様々な業界のソフトウェア開発現場に携わるようになりました。その仕事を通じて、プロダクトマネジメントに携わるようになったというのがこれまでの経緯です。
野崎:PeerQuestでは、当初からプロダクトマネージャーとしてお客さまの開発案件にかかわっていたのですか。
浪川:いえ、当初はプロジェクトマネージャーの立場で案件にかかわっていました。
野崎:とすると、何をきっかにプロダクトマネージャーの役割を担うようになったのでしょうか。
浪川:転機となったのは新型コロナウイルス感染症(以下、コロナ)の流行です。ご存知のとおり、コロナ禍によってウェディング業界や飲食業界は相当の打撃を被りました。結果として、これらの業界のお客さまから「デジタル技術(IT)を活用して何か新しいサービスを始めたい。企画から伴走して支援して欲しい」といったご相談がPeerQuestのもとに数多く寄せられるようになりました。そうしたお客さまの要望におこたえしようとする中で、プロジェクトマネジメントの限界に気づいたことが、プロダクトマネジメントを意識し始めたきっかけです。
野崎:そのお話は、プロジェクトマネジメントとプロダクトマネジメントの違いを端的に示すものと言えそうです。プロジェクトマネジメントのどこに限界を感じたかを、もう少し具体的にお聞かせいただけますか。
浪川:プロジェクトマネジメントは基本的に、決まった目標に向けて開発の「QCD:Quality(品質)、Cost(コスト)、Delivery(納期)」をマネージする取り組みです。一方、コロナ禍のときにウェディング業や飲食業のお客さまが私たちに求めてきたのはITによって何らかの新しいサービスを生み出すことです。つまり、そこには「どのような仕組みを作り、どういった成果を手にするか」の明確な目標がなかったわけです。ゆえに、プロジェクトマネジメントとは異なるアプローチでことに当たる必要がありました。そうした案件をマネージするための方法論や手法をさまざまに探した結果として、行き着いたのがプロダクトマネジメントの方法論であり、手法であったということです。
プロダクトマネジメントに対するニーズは時代の要請
野崎:いまお話しいただいたIT業界における浪川さんのご経歴 ── つまりは、ソフトウェア開発のエンジニアを経て、プロジェクトマネージャーに転身し、プロダクトマネージャーに至るまでのご経歴は、興味深いと感じます。2015年ごろから2019年にかけて、プロジェクトマネージャーとして浪川さんがソフトウェア開発にかかわっておられた中で、その役割に何らかの変化を感じられましたか?
浪川:確かにプロジェクトマネージャーの役割はかなり変化しましたね。私がプロジェクトマネージャーになりたてのころ、あるいは、それより少し前までは、決められた品質のソフトウェアを、決められた納期までに完成させることがプロジェクトマネージャーの役割のすべてでした。ゆえに、QCDについてお客さまと折衝を重ねることにかなりの時間をとられていたんです。その役割が2016年ごろから徐々に変化し始め、どのようなシステムを作るかの企画段階からプロジェクトにかかわり、システムの開発目標を定める作業も支援するといったコンサルタント的な役割をプロジェクトマネージャーが担うようになっていきました。
野崎:いま、おっしゃられた役割の変化は、いわゆる「デジタルトランスフォーメーション(DX)」の流れの中で、ITシステムに対して日本企業が求めることが変化したのとリンクしているように思えます。
浪川:なるほど。
野崎:ご存知のとおり、SoE*に類するシステムは、目まぐるしく変化する顧客のニーズや課題に対応しなければならず、企画開発の段階でシステムの機能面でのゴールを明確にできないことがほとんどです。ゆえに、仕様をきっちりと固めてから、開発の作業を行い、テストしてリリースするといったウォーターフォール型のアプローチではSoEのシステムづくりは行えず、開発とリリース、改善のプロセスを短サイクルで回しながらシステムを作り上げていくアジャイル開発のアプローチが必要になったわけです。
そして、そうしたSoEのシステムづくりが活発化し、コロナ禍をきっかけに本格化したことが、先ほど浪川さんが触れたプロジェクトマネージャーの役割の変化や、プロダクトマネジメントの必要性の高まりにつながったのでないかと考えました。浪川さんがプロダクトマネージャーになったのは時代の要請とも言えますし、DXの潮流が浪川さんに求めた変化とも言えるのかも知れません。
*SoE: Systems of Engagementの略で、顧客ニーズを充足し、満足度を高めることを目的として設計されるシステム。ITをより戦略的に活用する流れのなかで、IT戦略・IT投資の軸足を、社内業務の合理化や効率化を主眼にした「SoR(Systems of Record)」の整備・維持から、SoEに移そうとする企業が増えた。
浪川:おっしゃるとおりかもしれません。実際、2016年ごろから、私がかかわったプロジェクトの開発手法が、ウォーターフォール型からアジャイル型へとどんどん切り替わっていきました。その背景にはDXの潮流や顧客を中心に据えたシステムづくりの活発化があったと言えますね。
機能の「なぜ」を追求する姿勢がプロダクトマネジメントの重要ポイント
野崎:ここで、プロダクトマネージャーに必要とされるスキルについても、浪川さんの見解をお聞きしたいと思います。
先ほど、プロジェクトマネージャーの役割がコンサルタント的になったとお話しいただきました。その変化は、ある意味で、プロジェクトマネージャーの役割が、プロダクトマネージャーのそれに近づいたとみなすこともできます。また先日、書籍『プロダクトマネジメントのすべて』の共著者である小城(久美子)さんと対談させていただいたのですが、その際に、小城さんは、日本のプロジェクトマネージャーは優秀で、プロダクトマネージャーの役割をすでに担っている方が多いとおっしゃっていたのが印象的でした。その言葉と、浪川さんのお話を総合すると、日本のプロジェクトマネージャーとプロダクトマネージャーのスキルには重複する部分が多く、プロジェクトマネージャーからプロダクトマネージャーへの転身は、自然である印象も受けます。プロジェクトマネージャーとプロダクトマネージャーの双方を経験されたお立場として、この点についてどうお考えですか。
浪川:おっしゃるとおり、プロジェクトマネージャーとプロダクトマネージャーの間では重複するスキルが多くあると感じています。ただし、異なる部分もあります。
野崎:なるほど、それはどういった部分でしょうか。
浪川:プロジェクトマネージャーは、顧客との折衝を通じてQCDを調整したり、開発チームのタスクを管理したり、ステークホルダーとのミーティングを重ねるなど、内部的なコミュニケーションに多くの時間がとられがちです。それに対して、プロダクトマネージャーは、システムのターゲットユーザーのニーズや課題を探索し、システムの仮説検証を行う「プロダクトディスカバリー」の作業がきわめて重要な仕事になります。
野崎:なるほど、プロダクトマネジメントでは、プロダクトディスカバリーがカギとなるわけですね。浪川さんの経歴をお伺いしていますと、そうしたプロダクトディスカバリーの仕事がお好きであるように感じますが、実際いかがでしょうか?
浪川:はい、好きですし、楽しいですね。実を言えば、音楽教室の運営に携わっているころも、生徒(=顧客)と直接接するようなポジションにいて、音楽教室というサービスプロダクトを使う顧客が、サービスに対して、どう感じていて、何を求めているかを探求し、それによって得られたインサイトにもとづいて新しいコースの企画案を策定したりしていました。それはまさにプロダクトディスカバリーの作業といえますが、その仕事が楽しかったからこそ、エンジニアとしてどうユーザーに使ってもらえるモノを開発できるかに興味を持ち、結果として、プロダクトマネジメントに携わるようになったと言えます。
野崎:確かに、あらゆる提供サービスには「プロダクトディスカバリー的な」側面はありますね。ただ、なかにはエンジニアとして完成度の高いプログラムを記述するのが好きな人や、性格的にプロダクトマネジメントよりも、プロジェクトマネジメントのほうに向いている人がいると考えます。その観点から言って、プロダクトマネージャーに向いている人の性格的な特徴はなにかありますか。
浪川:例えば、使用しているアプリケーションに新しい機能が追加され、それをインストールして使ってみたとします。そのときに「なぜ、この新機能が追加されたか」を探求しようとする姿勢があるかどうかが、プロダクトマネージャーの大切な資質のように感じています。プロダクトマネジメントでは、顧客の課題を見い出し、それを解決するためにどのような機能を提供するかを決める作業が発生します。その過程ではさまざまな機能のアイデアが想起されますが、そこから適切な機能をより抜くうえでは「どうして、その機能にたどりついたか」を事実(ファクト)にもとづいて示せるようでなければなりません。ゆえに、ソフトウェアの「機能」について、その「なぜ」を追求できる資質が、プロダクトマネージャーには求められると考えます。