プロジェクトマネージャー、いわゆるPMと聞くと、どのような仕事を思い浮かべるでしょうか。
よくあるPMのイメージ
- スケジュールを作成する。
- タスクを割り振る。
- 進捗を確認する。
- 会議を設定し、議事録を残す。
もちろん、これらもPMの重要な仕事です。
しかし、私たちはプロジェクトマネージャーを、単にプロジェクトを「管理する人」だとは考えていません。
PMの本当の仕事は、自ら動き、周囲を巻き込み、人と組織を動かしながら、プロジェクトをゴールまで推進することです。
クライアントから聞かれたことを担当者に確認し、その回答をそのまま返す。問題が起きてから対応を始める。誰かから指示されるまで、次に何をすべきかを待つ。
これでは、PMがプロジェクトを動かしているのではなく、PMがプロジェクトに動かされています。
同じ時間を使い、同じだけ忙しく働いていたとしても、自発的にプロジェクトを推進しているのか、周囲から動かされているのかでは、その仕事が持つ意味や価値は大きく異なります。
私たちは創業当初から、PMの仕事を大きく5つの役割に分けて考えてきました。
PMの5つの役割
- チームビルディング
- ディレクション
- 進捗・タスク・各種調整
- クオリティチェック
- クライアントコミュニケーション
今回は、ECサイト構築やグロースハック支援をはじめとするさまざまなプロジェクトを通じて、私たちが大切にしているPMが生み出す価値についてお話しします。
プロジェクトの成否は、チームビルディングで半分決まる
PMの仕事の中で、私たちが最も重要だと考えているのが、チームビルディングです。
プロジェクトのゴールを理解し、その達成に必要な能力を見極め、最適なメンバーを集める。
非常にシンプルな話ですが、ここを正しく設計できれば、プロジェクトは半分成功したようなものです。
反対に、必要な能力を持ったメンバーをアサインできなければ、その後にどれだけ緻密なスケジュールを作り、何度も会議を行い、メンバーが無理をして頑張ったとしても、クライアントの満足度を高めることは難しくなります。
重要なのは、単純に優秀な人を集めることではありません。
プロジェクトによって、必要とされる能力は異なりますし、現実的な話で言えば予算という絶対的な制約条件があります。
構築という意味で言うなら化粧品や健康食品などのECとアパレルのECでは、それなりに違う機能やUI/UXが求められますし、同様にマーケティング手法も大きく異なります。
また、類似業界の実績があるメンバーでも、月商100万円のサイトと月商1億円とでは課題感なども大きく異なりますので、必然的にクライアント要望を満たすための経験は変わってきます。
案件の性質を見抜き、メンバーそれぞれの強みや相性まで考えながら、勝てるチームを設計する。これもPMの重要な仕事です。
ただし、最適な体制を考えるだけでは十分ではありません。その体制がなぜ必要なのかを、プロジェクトオーナーであるクライアントに理解してもらう必要があります。適切なチームを組むためにも、PM自身がクライアントとの信頼関係を築けることが前提になります。
成長期待だけで、クライアントのプロジェクトを設計しない
人に成長の機会を与えることは、会社組織を運営するうえで非常に重要です。
しかし、できないことを「この機会に成長してほしい」という期待だけで任せても、できないものはできません。
もちろん、プロジェクトの中で人が成長することはあります。しかし、クライアントから預かった仕事を、誰かの成長機会のためだけで設計することはできません。
経験が足りないメンバーをアサインする場合でも、その不足を補える体制を組む必要があります。
- 誰がレビューするのか。
- 誰が判断を支援するのか。
- どこまでを任せ、どこからは経験者が責任を持つのか。
そこまで設計することがPMの仕事です。
アサインを誤った状態でプロジェクトが始まると、現場のメンバーは不足している能力を、労働時間や根性で埋めようとします。
結果として、納期は守れたとしても品質が落ちる。成果物は完成しても期待した成果が出ない。一部の人に負荷が集中し、チーム全体に余裕がなくなる。
そして、その余裕のなさはクライアントにも伝わります。
アサインミスを、現場の努力で解決させてはいけません。
PMの最初の仕事は、始まったプロジェクトを管理することではなく、ゴールから逆算して勝てるチームをつくることです。
良いディレクションとは、バランスだ
ディレクションとは方向という意味です。つまりプロジェクトの方向を決める人をディレクターというわけですが、方向を決めると言われてもちょっと抽象的だと思うので、具体的には壁打ちや提案を行うという意味合いでご理解いただければと思います。飛躍のPMは基本的にディレクターとしての役割も担います。
チームビルディングの話が重要度が高いため先に書きましたが、実際のプロジェクトはまず相談から始まり、クライアントに対して簡単なディレクションを行うところから始まります。ここで実現したいことを5W1H的にヒアリングし、価値提供が出来そうな条件を提示し、それらをすり合わせます。
PMには、編集者のような役割がある
PMの仕事は、出版社の編集者にも似ています。
漫画家は、作品を生み出す才能と専門性を持っています。読者は、その作品を受け取る側です。そして編集者は、漫画家と読者の間に立ちながら、双方をつなぎます。
それだけでなく、「この雑誌の読者は何を期待しているのか」「その作品の魅力をどう引き出すのか」「今の展開は作品全体にとって適切なのか」といった視点から、作品の方向性にも関わります。
では、PMは何を基準にプロジェクトを編集していくのか。私たちがその判断軸としているのが、「三方よし」です。
EC関連のプロジェクトにおいて、私たちが思う良いディレクターとは、「三方よし」を実践できるバランス感覚に優れていることです。この場合の三方とは、クライアント、弊社、そして社会、社会とは多くの場合でECサイトの利用者を指します。
この三方の常に真ん中に立ち、様々な判断をしていくことが重要だと考えています。
つまり、クライアントから「これがやりたい」と相談を受けた場合に、それをそのまま見積もりいくらです、という会話をするのではなく、クライアントにとって投資に見合う成果が期待でき、ユーザーにとっても価値のある体験になり、私たちも必要な体制と品質を持続的に提供できる。
その三者が無理なく成立する選択肢になっているかを、論理的に検討する必要があります。
経験豊富であれば、それを更に初期のコストだけでなく、運用コストやリスク、その分散ノウハウまで提案に盛り込むことも可能になってきますが、何よりも重要なのはそのスタンスで仕事が出来ているかどうかです。
さらに、大きな目標や実現難易度が高いシステム開発などにおいては、プロジェクト全体としてどんな段階を経て進むべきかを示します。この階段設計は悪戯にプロジェクトを細かく区切れば良いというものでもなく、プロジェクト体制やリスクを考慮してバランスよく設計しなければいけません。
オンスケで進めるとは、期限を催促することではない
ここで、一般的にPMの仕事として認識されているプロジェクトマネジメントの話に入ります。
- スケジュール管理
- タスク管理
- 課題管理
- リスク管理
- 関係者間の調整
- 意思決定期限の管理
- 各工程の依存関係の整理
これらはすべて、プロジェクトをオンスケジュールで進めるために欠かせません。
ただし、スケジュール表を作り、期限が近づいたら担当者へ催促するだけでは、プロジェクトマネジメントとは言えません。
プロジェクトが遅れる理由は、作業スピードだけではないからです。
- クライアント社内の意思決定が止まっている。
- 前工程の確認が終わらず、次の担当者が動けない。
- 必要な素材やデータがそろっていない。
- 外部システムの仕様確認に想定以上の時間がかかっている。
- 関係者の間で、完成イメージが共有できていない。
こうした問題を放置したまま、担当者だけに期限を守るよう求めても、プロジェクトは前に進みません。
PMは、どのタスクが次の工程を止める可能性があるのか、誰の判断が必要なのか、いつまでに何を決めなければならないのかを把握し、先回りして働きかける必要があります。
今は問題になっていなくても、数週間後に問題になる可能性があるものを見つける。
遅れてから報告するのではなく、遅れる可能性が見えた段階で共有する。
そのうえで、当初の予定を守る方法だけでなく、スコープを調整する、順番を入れ替える、別の方法を選ぶなど、現実的な選択肢を用意します。
PMの価値は、どれだけ多くの作業を処理したかでは測れません。問題になる前に誰へ働きかけ、止まりかけた意思決定をどのように前へ進めたか。そこにPMとしての価値が表れます。
想定外は起きる。だから前倒しする
また、重要なことなので付け加えておきたいのが、プロジェクトというものはどれだけ経験を積もうと、どれだけ準備を行っても、かなりの確率で想定外のことがおきるということです。
メンバーが別案件の緊急対応に追われることもあれば、開発期間中にテクノロジーや外部システムの仕様が変わることもあります。
だからこそ、進められるものは可能な限り前倒しで進めておく。何かが起きたときには、役割を越えて支え合えるチームの関係性をつくっておく。
想定外をゼロにするのはコントロール出来ないことも多いので、想定外が起きてもプロジェクトを止めない状態をつくることも、PMの仕事です。
クオリティチェックは、完成後の検品ではない
クオリティチェックという言葉から、完成した成果物を最後に確認する工程を想像する方も多いと思います。
しかし、最後に確認して大きな問題が見つかったとしても、修正するための時間や予算が残っていない可能性が高いです。
品質は、プロジェクトの最後に確認するものではありません。
プロジェクトの途中で何度も確認し、必要に応じて軌道修正しながらつくり込んでいくものです。
特にECの場合、画面の見た目が良ければ品質が高いとは限らず、商品登録、在庫、決済、受注、出荷、返品、キャンセル、顧客対応、CRM、広告、データ連携など、サイト公開後の業務まで含めて成立している必要があります。
PM自身が、すべての専門領域で最も詳しい必要はありません。
ただし、どこにリスクがあり、誰に何を確認するべきかを判断する必要があります。
そして最終的に、「この状態でクライアントに提示してよいのか」「この品質で世の中に出してよいのか」を見極める責任があります。
専門家に任せることと、専門家へ丸投げすることは違います。
PMは各分野の専門性を尊重しながらも、プロジェクト全体の品質に責任を持たなければなりません。
コミュニケーション品質がすべての土台になる
私たちは、基本的にプロジェクトごとに定例ミーティングを設けています。
もちろん、進捗を確認し、マイルストーンを管理する目的もあります。
しかし、進捗の共有だけであれば、タスク管理ツールやチャットでもある程度は代替できます。
それでも私たちが定例ミーティングを重視しているのは、会話を通じてプロジェクトを前へ進め、その会話自体から価値を生み出したいと考えているからです。
プロジェクトを進めていると、資料やチャットの文章だけでは見えてこないことがあります。
- クライアントが何に不安を感じているのか。
- 社内でどのような意見の違いがあるのか。
- 当初から優先順位が変わっていないか。
- まだ言語化されていない期待がないか。
- 意思決定を難しくしている事情は何か。
- プロジェクトを通じて、新たにどのような課題が見えてきたのか。
こうした情報は、会話の中で初めて見えてくることがあります。
PMはそれを捉え、必要な提案を行い、チーム編成や進め方、スケジュール、成果物へ反映します。
ECサイトは、公開してからが本番
ECサイトの構築は、制作して納品すれば終わる仕事ではありません。
公開後に実際のユーザーが訪れ、商品を購入し、運用担当者が商品やコンテンツを更新し、売上や顧客の反応を見ながら改善を重ねていく必要があります。
つまり、公開はゴールではなくスタートです。
私たちの事業においても、ECサイトの構築だけでなく、既にECを運営している企業へのグロースハック支援は、大きな比率を占めています。
グロースハック支援では、最初から完成形が決まっているわけではありません。
クライアントとゴールを握り、データや顧客の反応を見ながら仮説を立て、実行し、検証し、次の施策へ進みます。
その過程では、継続的な対話と信頼関係が欠かせません。
数か月に及ぶ開発プロジェクトも、その後のグロース支援も、単に成果物や施策を提供する期間ではありません。
クライアントと一緒に事業を考え、互いの考え方や判断基準を理解し、次の挑戦に向けた信頼を積み重ねる時間でもあります。
私たちの仕事は、デザインや開発を扱うという意味ではクリエイティブ業です。
一方で、プロジェクト期間中にクライアントが感じる安心感や、相談のしやすさ、意思決定のしやすさまで含めると、サービス業に近い側面も持っています。
クライアントが受け取るものは、完成した成果物だけではありません。
- 完成までの対話。
- 問題が起きたときの対応。
- 提案によって意思決定が進む感覚。
- このチームとなら一緒に走れるという安心感。
それらを含めたプロジェクト体験全体が、私たちが提供する価値だと考えています。
成果物の品質も重要ですが、それを担保する土台となるのがコミュニケーション品質であると私たちは考えています。
同じカロリーでも、「動かすPM」と「動かされるPM」は違う
PMは、非常に忙しくなりやすい職種です。
多くの人と会話し、さまざまなタスクを確認し、問題が起きれば調整しなければなりません。
しかし、忙しく動いていることと、プロジェクトを推進していることは同じではありません。
- クライアントに聞かれてから担当者へ確認する。
- メンバーから問題を指摘されてから調整を始める。
- 期限が過ぎてから遅延を報告する。
- 会議で決まった内容を、関係者へそのまま転送する。
これらの仕事にも、時間と労力はかかります。
ただし、それは周囲から動かされた結果として発生している仕事です。
推進するPMは、自ら次に必要なことを考えます。
- 問題になる前に確認する。
- 意思決定に必要な選択肢を用意する。
- 誰かから声を掛けられる前に、自分から関係者へ働きかける。
- 対立する意見を整理し、着地点をつくる。
- チームの停滞を察知し、必要な人を巻き込む。
- プロジェクトが目的を見失いそうになったとき、方向を戻す。
同じ時間を使い、同じだけのカロリーを消費していたとしても、受け身で処理しているのか、自ら働きかけて周囲を動かしているのかでは、仕事の意味がまったく異なります。
PMの価値は、どれだけ多くの作業を処理したかだけでは測れません。
自ら動くことで、どれだけ多くの人と意思決定を前へ進めたか。
プロジェクトが止まりそうな場面で、誰に働きかけ、どのように再び動かしたか。
そこにPMとしての本当の価値が表れます。
PMの専門性は、専門知識ではなく総合力にある
PMは、デザイナーやエンジニアのように、特定の制作技術だけで専門性を説明できる職種ではありません。
チームワークやコミュニケーションに高い素養があれば、専門領域の経験が浅くても、PMとして仕事を始めることはできます。
しかし、プロジェクトを成立させることと、安定して高い成果を出し続けることは別です。
PMには、状況を俯瞰する力、人の能力や特性を見抜く力、優先順位を決める力、相手に応じて言葉を変える力、品質を評価する力、そして責任を引き受ける力が求められます。
そのため、プロジェクトリーダーとしての立ち回りを求められることからも、PMには継続的な文脈理解と、チームを動かすための権限が必要です。そのため、業務の一部だけを外部へ切り出すよりも、受託企業の中核メンバーとしてプロジェクトに深く関わる方が機能しやすい職種です。
そしてPMとして身につけた能力は、特定の業界や技術に依存しません。
- 人を集める。
- 方向を示す。
- 物事を整理する。
- 周囲を巻き込む。
- 品質を判断する。
- 相手の不安を理解し、信頼を築く。
- ゴールまで物事を前へ進める。
これらの力は、業界や職種が変わっても応用できます。
特定のツールや技術が変化しても、人と組織を動かす能力は簡単には腐りません。
PMは、誰でも始めることができる一方で、極めることが難しい。
そして、一度身につければ、生涯にわたってあらゆる仕事に応用できる職能だと考えています。
おわりに｜プロジェクトマネージャーは、人と組織を動かす仕事である
今回、PMの仕事を5つの役割に分けて紹介しました。
- 最適なチームをつくる。
- 進むべき方向を示す。
- 時間とタスクを管理する。
- 品質を守る。
- 対話を通じて信頼を築く。
しかし、この5つを別々にこなすことがPMの目的ではありません。
すべては、クライアントと握ったゴールに向けて、人と組織を動かし、プロジェクトを前へ進めるためにあります。
良いPMがいると、それぞれの専門家が自分の強みを発揮しやすくなります。
PMの成果は、PM自身がつくった成果物だけでは測れません。
- チームが生み出した成果。
- クライアントが感じた安心感。
- プロジェクトを通じて生まれた信頼。
- そして、そこから始まる次の挑戦。
そのすべてが、PMの仕事の結果です。
だから私たちは、プロジェクトマネージャーを管理者ではなく、人と組織を動かす推進者だと考えています。
関連コラム：AI時代に勝つのは専門特化かワンストップサービスか？（専門性を顧客課題に接続する統合責任と全体判断の価値）
関連コラム：アイゼンハワーマトリクスが教えてくれないこと（目の前の仕事を処理することと、人が成長することは同じではない）
関連コラム：「失敗を許容する文化」という言葉への違和感（失敗・実験・準備を切り分け、成果に誠実であるとは何かを考えたコラム）
