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

この領域について

中核となる能力

• 01スコープの定義と管理

  プロジェクトに何が含まれ、何が明示的に含まれず、それぞれについて完了が何を意味するかを定めること。スコープをめぐる争いの多くは作業についての意見の相違ではなく、誰も書き留めなかった境界についてのものであり、除外事項のほうが価値ある半分だと判明します。

• 02順序づけと計画

  見積りが意味を持つ粒度まで作業を分解し、現実の制約に沿って並べ、遅れが吸収されずに波及する経路を特定すること。存在すること自体が価値であるような計画は計画ではありません。有用な出力は、遅れると終了日が動く項目がどれかを知っていることです。

• 03依存関係の管理

  チームが制御できないすべての入力 — 他チーム、取引先、承認、環境、データ、人 — を、それぞれに「これ以上遅らせられない日付」を添えて追い、痛くなる前に働きかける習慣を持つこと。この分野で最も過小評価されている部分です。

• 04リスクの特定と対応

  現実に起こりうることを名指しし、発生可能性と影響を正直に見積もり、そして省かれがちな部分として、重要なものについて担当者と対応を合意すること。判断の集合ではなく文書として維持されるリスク一覧は、見返りのない事務負担です。

• 05障害の除去

  本当に前進を止めているものを突き止め、出向いて解消すること。所有者のいない環境、順番待ちのアクセス申請、自分が止めていると知らない人を待っている決定。プロジェクトマネージャーがこれを行うのか、単に記録するだけなのかが、この職種で最も明確な分かれ目です。

• 06関係者とのコミュニケーション

  誰がどの情報を、どの深さで、どの頻度で必要としているかを把握し、スポンサーには最も作りやすい版ではなく、行動に移せる版を渡すこと。相手が違えば本当に必要な報告も違い、全員に一斉配信される更新はたいてい誰の役にも立ちません。

• 07期間と予算の追跡

  合意された基準線に対して実際の進捗と実際の支出を追い、その差異の原因を説明できる程度に理解すること。価値は早期警告にあります。まだ対応の余地があるうちに特定された傾向は、後から届く正確な数字よりも価値があります。

• 08変更の管理

  計画が定まった後に届く依頼を扱うこと。スコープ、順序、費用、日付への影響を評価し、そのトレードオフを判断を所有する人の前に置きます。失敗の形は静かな吸収であり、妥当に見える追加の連なりが、誰も使うと決めていない余裕を消費してしまいます。

• 09見積りと予測の判断

  見積りが何であるかを忘れずに見積りを扱うこと。不確実性が実在する場面では点ではなく幅を用い、楽観よりも観測されたスループットを優先し、その場が聞きたいのが約束だからという理由で予測を約束に変える反射に抗うことです。

• 10統制と意思決定の衛生

  判断が実際に下され、根拠とともに記録され、影響を受ける人に伝わるようにすること。遅れの相当な部分は意見の対立ではなく、誰か他の人が決めたと全員が思っている決定です。

よくあるご質問

よくあるご質問

プロジェクトマネージャーとビジネスアナリストの違いは何ですか

プロジェクトマネージャーは作業が届くことに責任を負い、ビジネスアナリストはそれが正しい作業であることに責任を負います。プロジェクトマネージャーは順序、依存関係、リスク、期間、伝達を所有し、チームがそこへ到達できるかを問います。ビジネスアナリストは課題の定義、要求、受入基準を所有し、その成果が得られるために何が正確に存在する必要があるのかを問います。小規模なプロジェクトでは1人が両方を担うこともあり、その場合はたいてい、本人にとって不慣れな側の半分に注意が向かなくなります。

プロジェクトマネージャーとプロダクトオーナーやプロダクトマネージャーの違いは何ですか

想定される分担は、プロダクトが何をなぜ作るべきかを決め、プロジェクトマネジメントが約束された一連の作業を届けることです。プロダクトは価値、優先順位、ロードマップを所有し、プロジェクトマネジメントは順序、依存関係、リスク、日付までの経路を所有します。実際にはこの境界は業界全体で定まっていません。プロダクトマネージャーにデリバリーの運営を期待する組織もあれば、プロジェクトマネージャーにスコープの形成を期待する組織もあり、肩書きの使い方も企業ごとに一貫していません。どちらを採用する場合でも、御社の体制の中で誰が優先順位を決めるのかを明示的に合意しておく価値があります。曖昧さこそが摩擦の溜まる場所だからです。

アジャイルなチームにプロジェクトマネージャーは必要ですか

アジャイルの実践は、プロジェクトマネージャーがタスクを割り当て状況を集める必要をなくしました。これは本当に前進であり、しばしば役割そのものが不要になったと読まれます。しかし残る仕事は実在します。チームをまたぐ依存関係、外部の取引先、契約上・規制上の約束、予算への責任、チームの外にいる関係者とのやり取り。スクラムはそのいずれにも所有者を定めていません。単一チームを記述しており、多くの組織は単一チームではないからです。その仕事が割り当てられないままでも、なくなりはしません。テックリードやエンジニアリングマネージャーに降りかかり、たいていは本来の職務を犠牲にすることになります。

プロジェクトマネージャーはスクラムマスターやデリバリーマネージャーとどう違いますか

スクラムマスターは1つのチームの実践に向いています。そのセレモニーを進行し、働き方を改善し、妨害から守ることであり、日付や予算への責任は負いません。プロジェクトマネージャーの担当範囲は、通常複数のチームにまたがり、その外にある約束を含む一連の作業です。デリバリーマネージャーという呼称は両方に、そして両者の中間にも使われるため、肩書きだけでは候補者が実際にどちらの責任を担ってきたかは分かりません。何と呼ばれていたかではなく、何に責任を負っていたかを尋ねてください。

プロジェクトマネージャーに技術的な経歴は必要ですか

技術の実務経験ではなく、技術的な理解力が必要です。アーキテクチャの議論について行ける程度、本物の制約と好みを見分けられる程度、なぜ有意義に分割できない作業があるのかを理解できる程度、そして会話の外にいることが即座に伝わるような質問をしない程度です。エンジニア出身者がこの役割で優秀であることもありますが、その相関は思われているより弱いものです。技術的な議論に入れ込みすぎるプロジェクトマネージャーは、チームが必要としていた調整の仕事をしなくなりがちです。

プロジェクトマネージャーが価値を生んでいるかは、どう分かりますか

障害に何が起きているかを見てください。プロジェクトマネジメントが機能しているチームでは、障害はチーム自身が気づくより早く見つかり、何段ものエスカレーションを経ずに解消され、運営会議で驚きとして現れることはめったにありません。役割が事務的になっている場合の兆候は、よく整備された文書一式と、その傍らで同じ問題を毎週待ち続けているチームです。

プロジェクトマネージャーは既存の開発チームとどのように働きますか

開発体制の拡張という形態では、プロジェクトマネージャーはお客様のデリバリーの体制 — 計画サイクル、レポートライン、統制、エスカレーション経路 — の中で動き、作業を指示するのはお客様です。プロダクト、事業上の優先順位、ロードマップに対する責任はすべてお客様に残り、調整の体制が増えてもそれは移りません。Talent.IDが担うのは雇用に関する部分のみです — 雇用関係そのもの、給与支払い、従業員福利厚生、タレント管理、そして従業員の窓口であり続けること。