プロジェクトマネジメントの闇と光

誰でも(?)年収1000万を狙えるプロジェクトマネジメントについて書いていきます。出来れば毎週更新したい。。。

プロジェクトマネージャー vs プロダクトマネージャー

プロジェクトマネージャーとプロダクトマネージャーの違い

 前回(以下)でも少し触れたが、プロジェクトマネージャーと聞くと、何となく、少なくともプロジェクトに関わったことがある人であれば、その役割について想像できるだろう。ppt-life.hatenablog.jp

 

PMBOKなどでは、プロジェクトマネージャーの定義について、

Project managers are organized, goal-oriented professionals who use innovation, creativity, and collaboration to lead projects that make an impact.

https://www.pmi.org/about/learn-about-pmi/who-are-project-managers

※ ちなみに私はPMPを持っていますが、PMBOK聖典とは思っていません。

等と書かれているが、要するに定められたゴール/スコープに対して、必要なことは何でも実施し、その実施のためにフレームワークを活用したり、関連するソフトスキル等のコンピタンスを積極的に活用する人のことをプロジェクトマネージャーと呼ぶのだろう。従って、ちょっと違った見方をすると、プロジェクトマネージャーは、『goal oriented』と書かれている通り、『決まったゴール』に向かって『プロジェクトを回す』人とも言える。

 では、この『決まったゴール』というのは誰が定めるのだろうか。時には顧客から提示された仕様書であったり、あなたの上司の指示であったり、上位のシステム要求であったりするだろうが、もっと能動的に価値起点/組織視点でのゴールを策定しようとするのがプロダクトマネージャーである。

 プロダクトマネージャーの役割について、例えばMelissa Perriの『プロダクトマネジメント』では、以下のように述べられている。

組織におけるプロダクトマネージャーの本当の役割は、チームと協力して、ビジネスニーズとユーザーの問題解決を同時に満たす適切なプロダクトを作ることです。そのためには、さまざまな帽子をかぶる必要があります。プロダクトマネージャーとして仕事を効率的に進めたいなら、会社のさまざまな側面を理解しなければいけません。マーケットとビジネスの仕組みを理解する必要もあれば、会社のビジョンと目標を本当の意味で理解する必要もあります。また、プロダクトのユーザーを理解するには、ユーザーに対する深い共感も必要です。

 当たり前やんけ、と思われる方もいるかもしれないが一方で、プロジェクトマネージャーの役割イメージとはそれなりに異なりそうだ、という感覚を持たれた方も多いのではないかと思う。

 上記の通り、プロダクトマネージャーは、『ビジネスニーズとユーザーの問題解決を同時に満たす適切なプロダクトを作ること』をミッションとしており、goal orientedといよりかはどちらかと言うとpurpose orientedな活動を行う。何か決まったゴール(製品スコープ等)に対してアプローチする、というよりかは、ビジネスニーズとユーザーの問題解決を同時に満たすためには何をすべきか?なぜそれが必要なのか?というような、方向性を定める活動に比重を置く。

 勿論、プロダクトマネージャーの活動の中には、プロジェクトマネージャーとしての仕事も含まれるのだが、プロダクトマネージャーは定まった方向性に対してプロジェクトを回す、プロダクトマネージャーは、方向性を定める、といった点に大きな違いがあると思う。

プロジェクトマネジメントにプロダクトマネジメントの風味を加える

 従って、今あなたが置かれている状況に応じて、今はプロダクトマネジメントが求められているのか、あるいは、プロジェクトマネジメントが求められているのかをはっきりさせ、その前提に応じた取組を実施することが重要だと考える。プロジェクトマネジメントを実施している中で、『この製品(またはサービス等)をこのまま作ってしまってよいのだろうか』、あるいは、『仕様書のこの部分は自社のビジネスに合わない』ということを感じたことがある人も多いと思うが、そういうタイミングでほんのわずかでもプロダクトマネジメント的な活動ができれば、顧客や上司の納得性もあがるし、製品やサービスの横展開のチャンスも生まれる。どちらが偉いという訳ではないが、もし今プロジェクトに携わっているが、プロダクトマネジメントについて余り意識したことが無い、という方がいれば、書籍などで調べてみることをお勧めする。

あなたが経営者だったら

 上で述べていることと相反するかもしれないが、プロジェクトマネジメントとプロダクトマネジメントの境界はあるようで無い。あなたが経営者だったら、今会社にとって必要なものがプロダクトマネジメントなのかプロジェクトマネジメントなのか考えながら、部下や部門に仕事を任せると良いだろう。逆に部下や部門が、プロセスやリソースだけでなく、プロジェクトマネジメントやプロダクトマネジメントに関する進めにくさや困りごとを訴えきたら、同じように整理をするチャンスなのかもしれない。

次回以降:以下のあたりのどれかについて書きます

  • プロダクトマネージャーとプロジェクトマネージャー
  • プロジェクトマネージャーのスキルセット
  • プロジェクトマネージャーに対する経営層からの期待
  • パワーポイントエンジニアリング
  • 私の大失敗プロジェクト
  • 最近のプロジェクトマネジメントの流行り
  • 機能品質とPOC
  • 他に何かあったらコメントで教えてください

プロジェクトマネージャー vs ラインマネージャー

プロジェクトマネージャーとラインマネージャーの違い

 企業というのは営利活動を目的として運営(?)されている訳であるから、大体の方が何らかのプロジェクトに関わったことがある、または、現在進行形で関わっていることと思う。このプロジェクトの運営というのは本当に山あり谷ありで、顧客や社内他部門等によって定義されたプロジェクトの成果物を、計画に則ってdeliverするのが原則となるが、人・モノ・金・時間等が足りないということにしばしば陥る。

 プロジェクトマネージャーは、一般的には(例えばPMBOK等を参照すると)この複雑怪奇なプロジェクトを成功させるために、東奔西走する。例えば、定義されたプロジェクトスコープを達成するための人・金・時間の計画を立てたり、顧客等の強いステークホルダーとの要求調整を行ったり、時には自分自身がエンジニアになって成果物を作成する、というようなことも個人事業主の方だったりすると行っていることだろう。

 一方で、ラインマネージャーは別の切り口でプロジェクトの成功に貢献している。プロジェクトを成功に導くためには、プロジェクトマネージャーの活躍だけでは足りなくて、プロジェクトを構成する人自身や、その人によって提供される機能(時によってはプロセス)の高度化が必要不可欠であり、そのような高度化の役割を担うのがラインマネージャーである。組織によって大分ちがうと思うのだが、プロジェクトマネージャーとラインマネージャーの概念が存在する組織においては、一版的にはラインマネージャーは、部門に属する人のコンピタンス向上を行ったり、その人たちを通じて提供される機能の品質を担保したりする役割を担っていることが多いように思う。

 もう少し端的に、かつ、誤解を恐れずにまとめてみると、以下のような役割の違いがあると私は感じている。

  • プロジェクトマネージャー
    • プロジェクトにハンズオンで関わり、その実行/結果説明に責任を持つ
  • ラインマネージャー
    • プロジェクトに提供される人や機能の高度化/品質担保に責任を持つ

※ 待て待て、うちの会社/私は違うぞ、という方も多数おられると思いますが、それについては次項で述べます。

※ いやいや私はプロダクトマネージャーです、いえアカウントマネージャーで・・・等という方も多数おられると思いますが、実行スコープが存在すると仮定すると、広義の意味でのプロジェクトマネージャーとも捉えられると思いますので一旦その目線で見て頂きたい。

会社/組織によって異なるプロジェクトマネージャーの役割や立ち位置

 上述の通り、凄くざっくり言うと、組織(個人事業主の方も含む)には2タイプのマネージャーがいて、プロジェクトマネージャーかラインマネージャーのいずれかに分類されるものだと私は考えているが、ここで注意(?)したいのは、組織によってその役割や立ち位置が大きく変わる、という点だ。

 日本のTraditionalな組織に多くみられるのが、ラインマネージャーがプロジェクトマネージャーを兼務し、独立採算制をとっている各事業部/各製品部門において、縦割りっぽく製品/サービス開発を行っているパターンだ。これは複雑なようで分かりやすくて、売りたい、または、作りたい製品/サービスとそれをハンドリングする部門が大体1対1対応していて、その対応関係の中で、部門長がプロジェクトマネジメントを行いつつ、人やコンピタンスの育成を行っていく。従って、あなたの上司(居ないよ、という人もいるかもだが)は、その部門が受け持つ製品に関するプロジェクトマネジメントの知識も、部下や後輩を育成するための方法論にもたけていることが多い。

 海外の組織や、各プロジェクトに横断的なコンピタンスを配置したがる組織が採用しているのが、マトリックス型と呼ばれる組織だ。何がマトリックスなのかというと(例の弾丸を横になってよけるやつではない)、縦串が例えば機能ごとに細分化された部門、横串が各プロジェクト、と言ったイメージだ。単純化した例で言うと、ある自動車会社の部門として、エンジン部門、タイヤ部門、車体制御部門、ハンドル部門・・・等があったとして、これらが縦軸である。各部門は専門特化/機能特化した集団のイメージで捉えて頂きたい。では横軸は何かというと、各プロジェクトであり、例えば『軽自動車プロジェクト』、『セダンプロジェクト』、『軽トラプロジェクト』と言った形だ。『軽自動車プロジェクト』のプロジェクトマネージャーである貴方は、エンジン部門から二人、タイヤ部門から三人、・・・等と、各部門から人を募り(集めて)、プロジェクトの運営を行っていく(イメージがついただろうか・・・)。 

 また、機能ごとに細分化された部門がほぼ存在せず、プロジェクトが中心となり組織が構成されている会社も存在する(プロジェクト型組織)。これは例えば一部のコンサルティング会社のように、機能ごとに組織を細分化する必要がなく(例えば『戦略コンサル』等と社内の専門性が割と一元化されていたりして)、顧客プロジェクトごとに括っているような場合である。割と小数精鋭のイメージがあるが、これも会社/組織としての合理性の判断からそうなっているものと思われる。

 このように、各組織によって、プロジェクトマネージャーの役割や動き方は大分ことなる。あなたがラインマネージャー兼プロジェクトマネージャーなら(私はこれが"プレイングマネージャー"と呼ばれるやつだと思っているが)、余り他の部門の心配はせず、自分の属する組織内で色々と調整や実行を行うだろう。逆に貴方がマトリックス型の組織におけるプロジェクトマネージャーであったなら、各機能ごとに細分化された組織との調整や異なる部門から集まってきた人々を束ねるための工夫を行うだろう。

 本当はもっと色々あり、私も不正確なことを書いている気もまぁまぁするので、詳しく勉強してみたい人は、とりあえずPMBOKの記事を参照されることをお勧めする。また、これらの概念と違う組織概念を持たれている/知っている方については、是非コメント等で教えて頂きたい(私はエンジニアリング界隈、それらに関わるプログラムマネジメントや経営管理中心に働いてきており、組織設計は専門外のため)。

The Matrix Organization

https://www.pmi.org/learning/library/matrix-organization-structure-reason-evolution-1837

 

Figure 2. Simple matrix organization

 

もし貴方がプロジェクトマネージャーなら:貴方はどんな組織に属しているか?

 もし貴方がプロジェクトマネージャー、または、プロジェクトに関わるメンバーだとしたら、一度、貴方の組織がどういうタイプの組織なのか考えてみて欲しい。ラインマネージャーがプロジェクトマネージャーを兼務しているだろうか?あるいは、マトリックス型のようにその役割が分かれているだろうか?そうだとしたら、その権限バランスはどうなっているだろうか?

 ある程度答えが出たら、今度はその組織タイプに応じて期待されている役割や動き方のイメージと、貴方の現在の動き方や方針が合っているか、ざっくりでいいので確認してみて欲しい。例えば、マトリックス型の組織であった場合、プロジェクトマネージャーである貴方は、各機能部門からのアウトプット品質に文句をつける必要はあるが、その品質を高めるための、ラインマネージャーの部門員育成方針に変に口を出したりしていないだろうか?また例えば、プロジェクト型組織であるのに、ラインマネージャーとしてのoutputに力を入れすぎたりしていないだろうか?

 必ずしも組織タイプに合わせて自分の権限や役割を狭める必要はないが、得意不得意の役割分担と、連携する観点からもし気づきや改善すべき点がありそうなら実行してみて欲しい。きっと、貴方の上司や経営層から、ある種模範となるプロジェクトマネージャーだと認められるだろう(恐らく、多分。)。

次回以降:以下のあたりのどれかについて書きます

  • プロダクトマネージャーとプロジェクトマネージャー
  • プロジェクトマネージャーのスキルセット
  • プロジェクトマネージャーに対する経営層からの期待
  • パワーポイントエンジニアリング
  • 私の大失敗プロジェクト
  • 最近のプロジェクトマネジメントの流行り
  • 機能品質とPOC
  • 他に何かあったらコメントで教えてください