境界線が極めて曖昧に語られているプロジェクトマネージャー（PM）とプロダクトマネジャー（PdM）の比較を行うことで、プロダクトマネジャー（PdM）の職責の解像度をあげていきたい。その先には私が2017年から名乗っている新しい職種、プロジェクトデザイナー（ Project Designer ）の解像度をあげていく為でもあります。

プロダクトマネジャー（PdM）についてはこちら

プロジェクトマネージャー（PM）が担うべき役割とは何か？

プロジェクトマネージャー（PM）ととは何か？その存在理由は何か？私の理解はこれ

"How"&"When"どうやって何時までに

期日までに形にするには「どういう順番か？何を優先すべきか？」
期日までに形にするには「チームメンバーのリーダーシップをどう引き出すか？」
期日までに形にするには「当初の計画に縛られず、必要に応じて柔軟に変更することが可能になっているか」

1.どういう順番か？何を優先すべきか？

リソースは通常無限ではない。期限も限られている。そのため優先順位を決め、どの順番にプロジェクトを進めていくか?しっかりと見極めさせる必要がある。

優先順位は、関わってる人それぞれバラバラなことが多い。（バラバラであることが当たり前の事と言っても良いかもしれない）
・デザイナーはUIを複数のパターンでテストしながら作りたい。理由は良いモノを作りたいから。
・マーケティングは他社との差別化として人目を引く機能が欲しい。
・カスタマーサポートはお問い合わせ機能を充実させたい。
・エンジニアはじっくり時間をかけて設計したい。

自分にとっての優先順位はそれぞれ異なる。
だから「どういう順番か？何を優先すべきか？」をあらかじめしっかりと決めていく必要がある。繰り返すけど、リソースは通常無限ではないからね。

ファンクショナリティマトリクス

参考までに私がやっている方法「ファンクショナリティマトリクス」以下のような表で管理します。

機能グループに機能をグルーピングして、それぞれに3つ軸を記載し、そこから全体の優先度を決めていく。

詳しくはケンブリッジ・ファシリテーション研究所より
・「ファンクショナリティ・マトリクス」～あいまいさの排除なしに、プロジェクトの成功はなし～
・「ファンクショナリティ・マトリクス」～納得感のない優先順位は長続きしない～

ちなみに過去の運用経験上、「ファンクショナリティ・マトリクス」はファシリテーションが結構難しい。難易度が高い。その理由の多くは「声が大きい人に引きずられてしまう」「議論、対立をさけ、玉虫色の結論にしようとする人が多い」から。

参考までにファシリテーションが楽になる仕組みとして、ゲームの駆け引きを取り入れた、「ファンクショナリティ・マトリクスPlus」という手法を開発しました。（ケンブリッジさんにも逆伝授済み）

2. チームメンバーのリーダーシップをどう引き出すか？

何の為に集まっているチームなのか？それぞれの役割は何か？そしてチームメンバーのリーダーシップをどう引き出すか？

チームの力を最大限に活かすためには、プロジェクトマネージャーなどリーダーに任命された人のみが発揮すれば良いという訳ではない。チームメンバー全員にリーダーシップが必要。

リーダーシップは「関係性」起点

従来のリーダーやリーダーシップの話の多くは「個」に焦点・「個」が前提
その先は「他人に対して働きかけるための何か」という話。一例だけど「優秀なリーダーになるためのチェックリスト」を作り、それでリーダーシップを育てようとする。「個」から考えるから組織にリーダーシップが育たない。

リーダーシップを語る場合、「周囲の人々との関係性（リーダーと、リーダーが率いる皆との関わり）」をその前提にする

チームと個人の「強み」

チームメンバーの「強み」を活かそうとするマネジメントは多い。でも私が薦めたいのはチームメンバーの「弱み」をカバーするという視点。

なぜならチームの視点で「強み」にフォーカスすると声が大きい人に引きずられてしまう。役職などに引きずられてしまう。チームの総合力が弱くなる。

やることが決まっている通常業務、オペレーション業務ならそれでもよい。でもプロジェクトは何が起こるか分からない。皆の力を結集する必要がある。

だから

チームビルディングという概念

・新しいスタッフがうまくやってくれるか？
・思いをうまく伝えられるか？
・マネジメントがうまくできるか？
そんな悩みを解決するキッカケの1つがチームビルディング

チームビルディングの必要性

「チームビルディング」とは、あらゆる組織活動のベースを「人」に置き、人と人のつながりをデザインする手法。

ゴールに向けて活動するチームの進化「タックマンモデル」

「チームは生き物である」チームは、一気に活気づいたり、逆に勢いを失ったり、場合によっては危機を迎えたりと、さまざまな段階を経て成長していきます。チームビルディングを語るとき、こうしたチームの進化を示すモデルとしてよく取り上げられるのが「タックマンモデル」です。

チームの発展段階を４つに分けています。ゴールに向かって活動を続ける中で、チームはどんどん変化していくということです。

・形成期（メンバーを集めて関係を構築する）
・混乱期（メンバー間の衝突が生じる）
・統一期（秩序や一体感が生まれる）
・機能期（チームとして有効に機能する）

チームは必ず混乱する、メンバー間の衝突が生じる

私はよく「タックマンモデル」を引き合いに出します。
その理由は、
1）チームとして機能する前に必ず「混乱（メンバー間の衝突が生じる）」する。
2）その「混乱」は大事な過程と言うこと。
3）だから「混乱」しても焦るな、正常なチームとしての進化だ。
って事を伝えるため。

なぜなら、チームは最初・形成期、まだ遠慮している人も多い。相手を伺っている。でもある程度慣れてくると「言いたいことが言えるようになる」「主義主張がでてくる」。すなわち「混乱期」。

この過程をしっかり通過しないとチームとしては機能不全になる。言いたいことが、ちゃんと言えないチームは多いだろう。大体が声の大きい人中心でチームが回っている。

不確実性の高いプロジェクトワーク。チーム全員のリーダーシップが必要。新人プロジェクトマネージャーは「メンバー間の衝突が生じる」と焦る。でもそれが正常。「混乱期」をいかに早く起こして、早く次のステップに行くのか？が大事だ。

3.当初の計画に縛られず、必要に応じて柔軟に変更することが可能になっているか

当たり前の事だけどできない組織は多い。不確実性の高いプロジェクトワーク。とりあえず進めて、違ったら方向性を臨機応変に変えてプロジェクトの成功確率を上げていく。これができない組織は多い。

最初から100％の計画を求める。
一度決めたことは中々変えられない。

最初から「変更」することを、どうプロジェクトに組み込んでいくか？
プロジェクトの不確実性に対してどう組み込んでいくか？例えば定期的に優先度を組み変える会議を設定してあるか。優先度を組み替える時の定義をあらかじめ設定してあるか。

先見性をもって探求し、対応する

「チェンジ・マネジメント」の領域、PMBOK 第7版、プロジェクト・マネジメント標準（12の原則）に記載さている。

プロジェクトマネージャー（PM）とは何か？

まずこれがあればプロジェクトマネージャー（PM）として成立すると言うのが私の考えだ。