TL;DR（この記事でわかること）
- 途中参画 PM が最初にやるべきは “システム全体を俯瞰”
- 責任転嫁は厳禁。「全部、自分ごと」で信頼を最速獲得
- トラブル初動は “あとで” ではなく “いま”
- PM の武器は「情報」と「人間関係」だけ
- メンバーの限界を先読みし Plan B を常備
これだけ押さえれば、途中引継ぎでもプロジェクトを炎上させず、安全運転から立て直しまで一気に回せます。
対象読者
- スタイルに悩んでいるマネージャー職の方
- IT業界未経験でPM、PMOへのジョブチェンジを検討している方
- IT歴はあるがマネジメント経験がない方
前提
要件定義が完了している状態からプロィエクトマネージメントを途中から引き継いで実施するという前提になります。
※経験浅い方が真っさらな状態でPMになることは、私の知ってる限りほとんど存在しません...
5つのマネジメント習慣
誰よりもシステムを俯瞰すること
PMが正しい判断をするためにはシステムを俯瞰できなければ務まりません。
システムを俯瞰するという意味を理解いただくために、
私の頭の中のシステムを理解するための切り口が以下の図になります。
全ての領域に対して詳しくなる必要はないですが、
概要レベルで理解して傾向や流れを掴んだ状態で関係者と対話することを心がけなければ
正しい意思決定ができません。
次に、各領域について何をどの程度理解すれば良いのかを解説していきます。
ビジネス領域
具体例
- クライアントについて
- 資本関係
- 提供サービス
- 企業文化 - プロジェクトについて
- 立ち上がり背景
- 目的
- 実現したいこと
- 予算
ポイント
資金を提供して頂いている会社についてよく知ることで、
お客様の判断基準を自身に刷り込むことに繋がります。
調べ方や粒度は、
webに出ている範囲で調べたり、自社の営業さんに知っている全ての情報をヒアリングでわかる範囲で問題ありませんが、
その情報を使ってプロジェクトについて5W1Hを自分の腑に落ちる形で推測しておくことが大切です。
5W1Hの例
何を達成したいのか
いつまでにリリースしたいのか
誰が使用するサービスなのか
なぜ、このPJが発足したのか
どこのサービスを使用するのか(AWS等)
どのように実現しようと考えているのか
システム領域
具体例
- システムアーキテクチャ
- 必要技術領域
ポイント
システムのアーキテクチャはビジネス領域の次にシステムを俯瞰するために必要な情報です。
アーキテクチャを知れば、どのような技術領域の知識が必要になるかがわかります。
また、webに転がっている情報を組み合わせればナレッジが多量にあるところと、ほぼナレッジがないところがわかるので、人員配置や採用、計画立案の根幹になる情報が詰まってます。
例
- アプリケーションサーバーはAWSのEC2
- アプリケーションはruby on railsで実装
- RDBMSはAWSのRDSでmysql
- その他、AWSの各種サービスを使用(ALB, S3, Route53 etc..)
- ソース管理はgithub
- プロジェクト管理はbacklog
ドキュメントレベルの仕様領域
具体例
- 要件定義書
- 基本設計書
ポイント
全て丸暗記する必要はないです。
「〜をしたいから、この機能が必要なんだな」と機能を覚え、
「〜をしたいから、この非機能要件になるんだな」と非機能要件を覚えるくらいで良いです。
ドキュメントを暗記するのではなく、ビジネス要件やアーキテクチャから設計書ができたストーリーを自身の腑に落ちる形で理解するのが重要です。
実装領域
具体例
- コード
- 設定ファイル
ポイント
全てのファイルを見る必要はないです(不可能な量)。
現場のエンジニアに以下の観点でヒアリングしつつ、ランダムサンプルして以下を自身の目で確認して運用保守性(途中で入った人が直ぐに理解でき改修可能か? 運用中のトラブルに対して、どの程度考慮しているのか?)に当てをつけておきます。
- 命名規則
- ログ出力
- 設定ファイルへの切り出し
- CI/CD
- インフラコード化されてるか
トラブル責任の一切を自責として対応する覚悟を持つこと
「自分は途中参加だから前任 PM のせい」「開発チームの技術力不足だから」と言い訳した瞬間、プロジェクトはあなたを“責任者”として見なくなります。
Why?
途中参画 PM がまず獲得すべきは 信頼 です。
信頼を得る最短ルートは「すべて自分ごととして引き受ける姿勢」を見せること。
How?
存在しない人の責任にしたり、予算・採用の責任にしたりしてもプロジェクトが悪い方向に行くだけです。
現在/未来に存在する人のための、トラブル原因・恒久対策・是正対策を立案して関係者全員に納得させる姿勢が大切です。
この姿勢を 3 回ほど示せば、クライアントもチームも“決める人”としてあなたを扱ってくれます。
トラブル解決の初動は可能な限り早く行うこと
「あとで」ではなく「いま、この場で」。
予定にないアドリブでも、その場で手足を動かすことが一番費用対効果が高いケースがたくさんあります。
即時のアクションが PM の信用を底上げします。
即アクションの判断基準
- 1 分以内に 目に見える アクションができるか
- 影響が大きいトラブルか
具体例
| 典型シーン | 具体的にどう動く？ | なぜ効果的？ |
|---|---|---|
| MTGダブルブッキング／ドタキャン | カレンダーを見て別室へ直行し、 「この案件どっちを優先する？」と その場で意思決定をもらう |
10 分後に Slack で追うより、 “直接” 1 回で済む → 時間ロスゼロ |
| 会議中に“◯◯さんが触れば直りそう”なバグ発覚 | 発言しながらスマホで当人にコール。 スピーカーフォンで経緯共有→即タスク化 |
“確認して後で連絡” を消し込み、 会議時間＝解決時間 になる |
| 運用事故を偶然キャッチ | 顧客に呼ばれる前に テンプレ事故報告書 を下書き → 上長に即レビュー依頼 | 「言われる前に動いた」 → 顧客の心理コストを先に削減 |
システム関係者を人として知ること
PM が握る“パワー”は 2 つだけ。
情報 と 人間関係 です。
仕様書を読み込むのと同じ熱量で、メンバーのバックグラウンドや価値観にもダイブしましょう。
週 1 バーチャル 1on1（15 分）
- 仕事の進捗 5 分、好きな技術・キャリアの話 10 分
- プライベートは 2 ステップまで踏み込む(家族構成・趣味くらいで十分)
-> 体調や子供のイベントでリソースが揺れそうな日を先に把握できる。
メンバーごとの“得意技”を知る
- 「ログ解析が爆速」「CSS が神」など特徴を知って全体に共有する
-> 他メンバーが自然に相談し合う“助け合いネットワーク”が生まれる。
配下メンバーの限界を見極めること
“伸ばすべきタイミング”と“守るべきタイミング”を誤ると、
プロジェクトもメンバーも同時に潰れます。
1人1人を知り、適度なコミュニケーションを通して限界値を見極めることが大切です。
限界を引くために必要な情報
- 物理的体力(運動してるか、部活してたか)
- 精神的体力(炎上経験、 失敗時の考え方傾向)
- 工数尺度(平均に比べ、どの程度の作業効率で進められるか)
- 限界前に相談できるタイプか否か
限界と判断する基準
- 当人ができないと強く思い込んでいる
- 当人からの能動的なコミュニケーション頻度が異常に低下している
- いつもと比べ明らかに作業効率が落ちている
本当に重要なのはプランBを建てておくこと
限界近くまで働かせるケースは、以下の2パターンしかないと思います。
- ステップアップのために敢えて難しいタスクを任せる
- プロジェクト自体が炎上しており人手が足りない
必要な情報を事前に得ておけば、限界が来そうなメンバーの当てがつきます。
そのメンバーを注視して限界近くなってきた時に入れ替えられるプランBを事前に検討しておくことが大切です。
終わりに
未経験から約2年の地獄のようなPM経験を記事にすることで、私自身の供養をしております。
続編に興味を持って頂けた方は こちらのxアカウント をフォロー頂けると幸いです。
なお、"いいね" により私の供養が進みます🪦