モダンなプロジェクトマネージャーの役割

昨今、プロダクトを中心にした、実質的な事業責任者であるプロダクトマネージャー(以下、PdM)の必要性と重要性がよく言及されます。一方、プロジェクトマネージャー(以下、PjM)は、名前としては以前から存在する役割です。

PdMとPjMの違いは役割の違いであって、そこには上下もなく、ましてや、PdMは新しくてイケてる/PjMは古臭くてなんかイケていない、ということも全くありません。ただ、最近、社内でいろんな人と対話をしていると、世間的にはPjMはつまらない役割に思われているかもしれない、という印象を覚えます。が、それは全くの誤解だと思いますw

ということで、私の周りにいる活躍しているPjMを思い浮かべながら、その人たちをモダンプロジェクトマネージャーと勝手に定義しw、その役割や持つべき視点について書いてみたいと思います。

1. PjMとは何をする人か？

PjMに対してネガティブなイメージを持つ方にとって、TypicalなPjMのイメージは以下のような人かもしれません。

・ガントチャートとにらめっこする人
・Excelのタスク管理表をにらめっこする人

プロジェクトのゴールが定まっており、その決まった要件に対して、タスクに分解する。そして、それぞれのタスクの依存関係を整理してスケジュールを引き、それぞれのタスクの期日とステータスを管理する人。

こう書くと、全然、面白くないですね。しかし、私が知る限りですが、PjMとして管理系のお仕事だけをやっている人はいません。それは何故か、理由は簡単です。そのような管理系の仕事だけで完遂するような、簡単なプロジェクトはもはや存在しない、からです。

プロジェクトを難しくする要因は何か、その最も大きい要素は不確実性です。そして、この不確実性に向き合うこと、これが1つ目の役割です。

(1) 不確実性に向き合う

PjMは2つの不確実性に向き合う必要があります。1つ目はゴールの不確実性、2つ目は実現性の不確実さ、です。

1つ目のゴールの不確実さについて。"プロジェクト"と言う以上、初期的な完了基準はあってしかるべきですが、それを取り巻く事業環境が変わる中では、当然、プロジェクトのゴールも変わります。妥当な理由で変わるゴールに対して、PjMはそれに追随する必要があります。そのためには、弾力性の高いプロジェクトマネジメントが求められます。

ソフトウェア開発のプロジェクトにおいて、弾力性を高めるのは、アーキテクチャやソフトウェアの設計における弾力性と、それを生み出すチームの弾力性の2つがあります。

前者のソフトウェアとしての弾力性は、私自身がup-to-dateな内容で語れないため、スキップさせてください。後者のチームの弾力性については、下記の記事の一部が、弾力性を生み出す方法論なので、ぜひご参照くださいませ。(どちらも簡単に記載できる内容ではなく、ご容赦くださいませ)

そして、2つ目の実現可能性の不確実さについて。例えば、AI系の機能であれば、その品質・精度には、ほとんどの場合において不確実性が存在しています。音声認識の精度、予測モデルの精度、など。事前に期待した精度・挙動にすぐに到達しないことは日常茶飯事です。ゴールを決めて正しく管理すれば達成できる、などということはほとんどありません。

このような場合においては、回転を早くしてリスクを下げることが重要です。回転を早くするためには、3つのステップがあります。
1. 不確実性が内在する要素を正しく把握すること
2. その要素の品質を測る仕組みと、改善する仕組みを構築しすること
3. その改善サイクルを可能な限り短くすること

私が知る限り、優秀なPjMは、エンジニアリングマネージャー(EM)とともに(同じ人の場合もあります)、目に見えるアウトプットを早く出したい誘惑を抑え、真っ先にスマートなデリバリープロセスを整えることが多いです。

そしてさらに、実現性のリスクを下げるのとは別に、不確実性をマネジメントするために必要な要素があります。それは、ステークホルダーの期待値コントロールです。社内の場合もありますし、社外のプロジェクトであれば、クライアントになるかと思います。

コミットメントできるボトムラインを正確に捉えた上で、不確実性に対して、ステークホルダーの理解を得ること。もし不確実性に対する理解が得られない、つまり、理不尽なコミットメントを求められる場合は危険な匂いが擦るので、そもそも始めるかを冷静に考えた方が良いかと思われます。

以上は、プロジェクトの不確実性と、それをマネージするためのアプローチについて説明しました。

そしてこの不確実性は、それ自体に対応することだけでなく、別の難しさを生みます。それは、不確実性は、アウトプット(結果物)とアウトカム(事業として意味のある成果物)のズレを起こす、ということです。もし不確実性がなければ、プロジェクト開始時点で定義したアウトプットは、アウトカムに直結しているはずです。ただ、内外の不確実性により、アウトプットとアウトカムは容易にずれていきます。

それでは、アウトプットとアウトカムのズレが生まれる中で、何にコミットするか、それはアウトカムです。このアウトカムにコミットすること、それがPjMの2つ目の役割です。

(2) アウトカムにコミットする

初期的に与えられたゴール、そして、そのゴールを具体化したアウトプットの定義があったとしても、その事業的な意味を捉え、PjMが自らアウトカムを定義する必要があります。

したがって、"当初に決められたアウトプットを出しました"というのは、全く良くない状態です。むしろ、アウトプットがアウトカムとして適切かを常に意識し、もしズレが生じているようであれば、アウトカムを表すアウトプットを再定義する、ということが求められます。

PjMの意識は常にアウトカムに向いているべきですし、PjMをアサインする人は、PjMとともにアウトカムを定義し、アウトプットをPjM自身が決める権限と裁量を与えるべきだと思います。

以上をまとめると、PjMの役割は、
アウトカムにコミットし、ゴールを達成するために必要なタスクとスケジュールを管理するのは当然のこと、チームの弾力性を高め、デリバリープロセスを整備し、ステークホルダーの期待値をコントロールしながら不確実性に向き合っていくこと
となります。

それでは、次にPjMはどんな人が向いているのか、書いてみたいと思います。

2. PjMが持つべき視点

PjMが持つべき視点は3つあると考えています。ユーザーとチーム、そしてプロダクトです。

(1) ユーザーの視点

前項で、PjMはアウトカムにコミットすべき、という話を書きました。アウトカムへの意識を向き続ける一番の方法は、ユーザーの視点を持つことです。

ここでのユーザーとは、エンドユーザーの場合もあれば、クライアント企業の場合もあります。いずれにせよ、価値を提供する先の視点を持ち続けられれば、適切なタイミングでアウトプットをアップデートしていくことができます。

常にユーザーを意識し続けることは、PdMの役割においても当然のこととして重要視されます。それと同様、PjMも初めに決めたアウトプットに縛られず、常にユーザーの価値に意識を向ける必要があります。

(2) チームの視点

不確実性に対応するために、チームの柔軟性を高める必要がある、と書きました。チームの柔軟性を高めるためには、プロセスを見るだけはなく、チーム・人に目を向けることも必要不可欠です。

人事評価などのヒューマンマネジメントは、組織のマネージャーに任せるにしても、プロジェクトをスムーズに進めるためには、それぞれの人に専門性と動機付けを理解し、適切なコミュニケーションをとっていく必要があります。

そして、決められたから行う、ではなく、PjM自身の言葉で何故やるのか、何がゴールかを説明しながら、プロジェクトをリードしていく必要があります。

(3) プロダクトの視点

ユーザー価値の視点とともに、プロダクトの視点もとても重要です。プロダクトはユーザー価値を具体化したものであり、アウトカムそのものです。したがって、決められた仕様に沿って作るのではなく、作っているプロダクトが、本当にユーザーや事業としての価値になっているかを自問自答し続ける必要があります。(上の図のアイコンが !(びっくり)になっているのは、ユーザーがびっくりするプロダクトを作る、という意味を込めていますw)

そしてさらに、PjMは、価値に対して責任を持つだけでなく、プロダクトを構成する中身とそれが生み出されるプロセス、つまりエンジニアリングにまで踏み込んで深く理解する必要があります。

それを理解するためには、シンプルにエンジニアとしての経験があると圧倒的に有利です。それも表層的な開発経験ではなく、なるべく低レイヤーな技術要素やその原理を理解していれば、さらに有利です。何故なら、根本を理解していると、多少表層的な技術が変わっても、直感を働かせることができるからです。

PjM自身が、コードをかけるのが理想的ですが、そうでない場合、少なくともエンジニアと対等に会話できるだけの、知識と経験は備えておく必要があります。

以上、PjMとして持つべき視点として、ユーザー、チーム、プロダクトの3つを紹介しました。次の項では、少し話題を変えて、PjMとPdMの違いについて書いてみます。

3. PdMとPjMの関係性は？

前項で書いたユーザー、チーム、プロダクトの視点については、よくPdMの役割の中でも説明されます。

では、PdMとPjMはどういう関係であるべきか？

その役割を説明するのに、よくWhy, What, Howが用いられます。PdMはWhy/What、つまり何故それをするのか、何をするのかを決める。PjMはHow、つまりどうやって実現するのかを決める、という説明ですね。

ただ、この説明は、半分は正解で、半分は間違っていると思います。それでは、適切な表現はどうなのか。簡単に図で書くと、下のようになると思います。濃い部分が必須、薄い部分があるととても良い視点です。

まず、軸として、PdM : Why/What, PjM : Howというのは正しいと思います。軸というのは、最終的な意思決定を誰がするのかというのと、物事を捉える視点です。

前者はシンプルですね。迷った時やコンフリクトがある時の意思決定は、Why, WhatについてはPdMが、HowについてはPjMが行うべきです。

もう一つは物事を捉える視点。例えば、PdMに必要な視点として、ビジネス、UX、テクノロジーという3つで語られますが、テクノロジーに対する捉え方として、PdMはそのトレンドと変化がもたらす事業的なインパクトを理解すべきです。一方、PjMは、その中身、具体的な方法論を理解すべきです。このようにベクトルは同じでも、捉える視点が異なります。

一方で、その役割は分断されるべきではない、ということも忘れてはならないと思います。

例えば、ユーザー視点については、PdMでも最も必要な要素ですが、PjMでも必要な視点としてあげました。重複しているからどちらかに寄せるべきは？と思われるかもしれませんが、それは絶対的に間違いです。

何故かというと、不確実性が高く流動的な状況においては、ある瞬間において整った役割分担は、それを取り巻く状況が変わった瞬間、境界部分に"隙間"ができます。隙間が生まれると途端にチームがワークしなくなります。そのため、意図的に重なりを作って、PdMとPjMの関係にも高い柔軟性を持たせる必要があります。

上の図にも書いたのですが、PdM/PjMだけでなく、プランナー、エンジニア、デザイナー、ビジネスデベロップメントなど、そこに関わる全ての人が重なるべきです。メンバー全員が、Why, What, Howの全ての視点を持っていると、それはとても強いチームになります。そう考えると、PjM/PdMで重なりを作るのは当然のことと言えます。

まとめると、PdM : Why/What, PjM : Howという軸を明確にした上で、可能中な限り重なりを持つこと、これがPdMとPjMの最適な関係性になるかと思います。

4. プロジェクトマネジメントのトレンド?

プロジェクトマネジメントを体系的にまとめたものといえば、プロジェクトマネジメント協会 (PMI)が発行している、PMBOKガイドが有名かと思います。インターネット企業にいると、あまり触れる機会はなかったのですが、少し見てみると、第7版の発行準備が進められているようです。

Coming in 2021: The PMBOK® Guide – Seventh Edition
https://www.pmi.org/pmbok-guide-standards/about/current-projects

まだドラフトかと思いますが、第7版では、Project Performance Domainsとして、以下の8つが定義されています。
https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/pmbok-project-performance-domains.pdf

Project Performance Domains
- Uncertainty
- Stakeholder
- Team
- Development Approach & Life Cycle
- Planning
- Project Work
- Delivery
- Measurement

今までのPMBOKとかなり違う印象です。逆に、ここまで記載してきた内容に近いです。世の中のプロジェクトマネジメントのトレンドが、変化が激しいインターネット企業で活躍しているPjM像に近づいてきたということでしょうかw

いずれにせよ、決められたゴールに対して、Howのみに着目して、スケジュールとタスクを管理すれば良い、ということは、もはやなさそうですね。

5. PjMの面白み

あくまで私が知っている範囲ですが、社内で活躍しているPjMの何人かにインタビューしてみたところ、PjMの面白みは、以下の2つに集約されていました。

1. 不確実性自体が、やりがいのあるチャレンジになっている
2. そのチャレンジを楽しめるチームがある

1つ目はそのままですが、難しさ自体が楽しみ、ということですね。もちろん、楽(簡単)ではないのですが、チャレンジするのが当たり前と思えるカルチャーがあれば、答えないチャレンジはシンプルに楽しいと思います。

2つ目、そのチャレンジを楽しめるチームがある、ということ。今の私の周りを見ても、圧倒的な個のパフォーマンスを持った人が数多くいます。そのような人達と一緒に仕事をすると、追いつくのが大変なぐらいの早さで試行錯誤できます。しかも、その1回1回のトライはとても深いです。このような人達とともに、チームとしてプロジェクトを進行できるのは、とても面白いと思います。

つまり、まとめると、圧倒的な個のパフォーマンスを持った人とともに、不確実性を試行錯誤しながらアウトカムに繋げること、私の周りをみる限り、PjMの面白みはこれに尽きるかなと思います。

6. 最後に

以上、モダンなプロジェクトマネージャーの役割や、持つべき視点について書いてみました。

昨今、プロダクトマネージャーが注目されがちですが、優秀なプロジェクトマネージャーがいなければ、適切に社会に実装することもできません。どちらも重要ということが、このポストを通じて伝われば良いなと思います。