- システムエンジニアとは何か – 調整役ではなく技術責任を扱う仕事
SE という言葉を技術責任の観点から整理した記事です。 - エンジニアの仕事は一般職と何が違うのか – 技術判断と不確実性を扱う仕事
技術職が扱う判断と責任を整理した記事です。
プロジェクトマネージャーというと、進捗管理、課題管理、会議調整の仕事だと思われがちです。もちろんそれらは必要ですが、それだけではプロジェクトは安定しません。
本当に重要なのは、責任分界を設計することです。誰が決めるのか、誰が実装するのか、誰が確認するのか、何が未決なのか。ここが曖昧なまま進むと、進捗表だけが整っていてもプロジェクトは崩れます。
進捗管理は結果であり原因ではない
進捗が遅れる原因は、単に作業者の手が遅いことだけではありません。要件が決まっていない、前提が変わった、判断者が不明、依存関係が整理されていない、品質基準が曖昧。こうした構造的な問題が進捗遅延として表に出ます。
そのため、プロジェクトマネージャーは進捗を聞くだけでは足りません。なぜ詰まっているのか、誰の判断が必要なのか、どのリスクを今処理すべきなのかを見なければなりません。
PM が設計すべき責任分界
| 観点 | 曖昧な状態 | 整理された状態 |
|---|---|---|
| 意思決定 | 誰が決めるか分からない | 決裁者と判断期限が明確 |
| 作業範囲 | 担当外の作業が流れ込む | 担当範囲と例外処理がある |
| 品質基準 | できたら確認する | 完了条件と受入基準がある |
| 変更管理 | 現場判断で変わる | 変更の影響と承認経路がある |
| 障害・遅延 | 人の頑張りで吸収する | リスクとして早めに扱う |
良い PM は曖昧さを放置しない
良いプロジェクトマネージャーは、曖昧なまま進んでいる部分に気づきます。担当者が頑張ればなんとかなる、後で決めればよい、現場で調整すればよい。このような言葉の裏にある未決事項を拾い上げます。
特にシステム開発やインフラ構築では、曖昧さは後工程で増幅します。基本設計で決めるべきことを詳細設計へ送る。詳細設計で確認すべきことを構築へ送る。構築で見つかった問題を運用で吸収する。こうなると、最後に現場が苦しくなります。
会議を増やすことが管理ではない
プロジェクトが荒れると、会議や報告が増えることがあります。しかし、会議を増やしても、判断者が決まっていなければ前には進みません。課題表を厚くしても、誰がいつ何を決めるのかが曖昧なら、課題は閉じません。
PM の仕事は、情報を集めることだけではなく、判断できる状態を作ることです。必要な情報、判断者、期限、影響範囲、未決事項を整理する。これができると、進捗管理は単なる報告ではなく、プロジェクトを前に進める道具になります。
まとめ
進捗管理は大事ですが、進捗表を美しくすることが目的ではありません。プロジェクトを前に進めるには、責任、判断、制約、リスクを見える形にする必要があります。PM の仕事はそこにあります。
構造化思考のレッスン
業務や論点を分解し、前提、責任、判断軸を整理するための参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
- 求人票の「高いコミュニケーション能力」が危険な理由 – 要件定義できない組織を見抜く
求人票の言葉から組織構造を読む記事です。 - 日本企業でエンジニアが成長しにくい理由 – 技術より調整が評価される構造
技術者が成長しにくい構造を整理した記事です。 - エンジニアのキャリアは良い経験を積めるかで決まる
所属先より経験の質をどう見るかを整理した記事です。


