インフラPMは、scope、schedule、cost、quality、risk、stakeholderを管理し、技術leadと協力してprojectを完了させます。全configを自分で作る役割ではありませんが、設計・試験・移行の依存関係とriskを判断できる技術理解が必要です。
けんと＠設計構築チャンネル
PM経験は会議参加だけでは伝わりません。課題・制約・自分が決めたこと・関係者への説明・結果を一つの事例で示すと、担当範囲を判断しやすくなります。
インフラエンジニアPMは何を担当する？
先に答えると、インフラPMは、scope、schedule、cost、quality、risk、stakeholderを管理し、技術leadと協力してprojectを完了させます。全configを自分で作る役割ではありませんが、設計・試験・移行の依存関係とriskを判断できる技術理解が必要です。
技術lead・PMOとどう違う？
仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| PM | 全体scope・schedule・cost・合意 | project plan、risk、decision |
| 技術lead | architecture・品質・技術判断 | design review、technical risk |
| PMO | 進捗・標準・report支援 | status report、会議運営 |
| member | 担当成果物を作成 | 設計・config・test結果 |
顧客/利用部門 <--> PM <--> 技術lead <--> NW/Server/Cloud team
<--> vendor/procurement/operation一日の会議と判断をどう進める？
一日の会議と判断をどう進める？では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 朝にcritical pathとblockerを確認 | 期限影響を更新 |
| 2 | 会議でdecision ownerと期限を確定 | 保留を放置しない |
| 3 | 設計・test・移行の品質gateを確認 | 入口・出口条件 |
| 4 | 終業前にriskと翌日のactionを共有 | escalationを早める |
# risk register例
ID: R-12
Risk: circuit delivery delay
Impact: integration test slips 10 business days
Owner: PM / Carrier lead
Trigger: order acceptance not received by YYYY-MM-DD
Response: temporary circuit option / steering decisionStatus: Amber
Critical path: Circuit -> connectivity test -> migration rehearsal
Decision needed: temporary line by Friday
Evidence: carrier response / updated schedule v1.8障害・遅延riskをどう管理する？
一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 進捗率だけを見る | 完了定義が曖昧 | 成果物とacceptance criteria |
| 課題とriskを混同 | 対応時期を誤る | 発生済み/未発生を分ける |
| 技術判断をPMだけで断定 | 専門review不足 | technical ownerを明記 |
| 会議が増え続ける | decision権限不明 | RACIとagendaを整理 |
PM求人で何を確認する？
PM経験を職務経歴書へ書くときは、project規模を誇張せず、自分が管理したscope、人数、vendor、予算権限、最終承認者を分けます。技術leadとしての経験をPM経験へ言い換えません。
- 対象機器・interface・VRF/VLAN
- 取得日時・timezone・software version
- 変更前後の同一command出力
- 期待値・実測値・判定者
- 異常時の停止条件とrollback結果
けんと＠設計構築チャンネル
求人では役職名より、予算・進捗・品質・顧客調整のどこまで任されるかを確認します。入社後に作る成果物とレビュー相手も聞いてください。
関連する仕組みを次に確認する
定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。
まとめ：進捗表ではなく、依存関係・risk・decisionを管理する
進捗表ではなく、依存関係・risk・decisionを管理することが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。
