『コーディングはできるが PM ができない』壁
エンジニアがミドル→シニア→テックリードと昇格する過程で最大の壁になるのが『プロジェクト管理スキル』です。コーディングはできてもPJをスケジュール通り完了させられないと、本人の評価とチーム全体の成果が頭打ちになります。本記事では編集部の取材ベースで、3〜6ヶ月の中規模PJを管理する5つの実務を整理します。
PJの遅延を引き起こす5つの典型原因
- 見積もりの楽観: 「2週間で終わる」が4週間かかる
- 依存関係の見落とし: 他チームの作業待ち・外部APIの仕様変更
- スコープクリープ: 進行中の要件追加
- ステークホルダー巻き込み不足: 関係者の事前合意が不十分
- 進捗管理の手抜き: 週次レビューが形骸化
実務1: 見積もりの精度を上げる
(1) WBSの粒度: 1タスク = 1〜3日で完了する粒度に分割
(2) 3点見積もり: 最良・最頻・最悪の3つで見積もる（PERT法）
(3) 過去実績との照合: 類似タスクの実績工数と比較
(4) バッファ40%: 中規模PJで40%のバッファを持つ
(5) 不確実性の明示: 「曖昧な部分は調査タスク」として分離
実務2: 依存関係を可視化する
- 依存関係マップ: 図でステークホルダー・外部要因を可視化
- クリティカルパス: 遅延が全体に影響する経路の特定
- 外部依存の早期確認: PJ開始時に外部チーム・ベンダーとMTG
- 並行作業の最大化: 直列で良いタスクをWaterfall化しない
- 定期同期: 週1で依存先チームと同期
実務3: スコープクリープの管理
(1) 初期スコープの合意: PJ開始時に明示的にIn/Outを定義
(2) 変更要求の手続き: 追加要件は『次フェーズへ』を基本ルール
(3) 例外時の影響分析: 追加した場合のスケジュール影響を提示
(4) ステークホルダー合意: 影響を理解した上でGO/NoGo判断
(5) 追加内容のドキュメント化: スコープ変更の経緯を記録
実務4: 進捗管理の習慣化
- 毎日のスタンドアップ: 15分・昨日/今日/ブロッカー
- 週次の進捗共有: ステークホルダー全員にプログレスレポート
- マイルストーン管理: 月次・四半期の節目で評価
- リスク管理: 中・高リスクをトラッキング
- 遅延の早期報告: 隠さず・早めに・対策案と共に
実務5: ステークホルダー管理
- 関係者マップ: 全ステークホルダーをリスト化・役割明示
- コミュニケーション計画: 誰にいつ何を伝えるか
- 意思決定者の明確化: 最終判断者を最初に決める
- 非エンジニアへの説明: 技術用語を業務言語に翻訳
- 営業・PMとの連携: クライアント向け説明への対応
PJ失敗の典型パターン
- パターン1: 見積もり甘い: 当初4週間想定→ 実際12週間
- パターン2: 隠れた仕様変更: 営業がクライアントに約束した追加要件
- パターン3: チームメンバー離脱: 中盤でキーマン退職
- パターン4: 外部依存の遅延: ベンダーAPI仕様変更
- パターン5: 経営判断による中止: ROI低下で中止判断
テックリード昇格への投資
(1) 1on1で上司に相談: 自分がPJリーダー候補かを確認
(2) 小規模PJで実績: 2〜4週間の小規模PJから始める
(3) PMP/Scrum認定資格: 業務直結なら投資価値あり
(4) 関連書籍: 『SCRUM BOOT CAMP THE BOOK』『プロジェクトマネジメントの教科書』
(5) 過去PJのRetrospective: 自分が関わったPJの振り返り
関連リンク
テックリードロードマップは テックリードへの道、EMロードマップは EMロードマップ、テックリードキャッチアップは テックリードキャッチアップ術 を参照してください。コードレビュー文化は コードレビュー文化 もどうぞ。