インフラPMとは何をする仕事なのか｜技術と現場の判断をつなぐ役割

こんにちは。Lamb です。 PMの仕事を見ていると、進捗表より先に「誰が決めるのか」が気になってきます。

インフラPMは、スケジュールや課題を管理するだけの役割ではありません。 技術、顧客、チーム、運用、リスクをつなぎ、関係者が判断できる状態を作る仕事です。 この記事では、AWS移行やサーバ更改の現場で何を見ているのか、技術担当との違いはどこにあるのかを整理します。 PMを目指す人だけでなく、設計や構築を担当するエンジニアにも役立つ視点です。

インフラPMという言葉を聞くと、最初は少し分かりにくいかもしれません。

PMというと、進捗表を見て、会議をして、課題を管理する人。そんなイメージを持つ人も多いと思います。

もちろん、それも仕事の一部です。ただ、インフラ案件のPMは、単にスケジュールを追いかけるだけでは回りません。

私自身、以前はインフラの仕事というと、もっと技術寄りのものだと思っていました。

• Linuxのコマンドを覚える
• AWSのサービスを理解する
• ネットワークの仕組みを押さえる
• アーキテクチャを考える
• 設計して、構築して、テストする

もちろん、どれも大事です。技術がなければ、設計も構築も運用もできません。

ただ、実務で案件を進めていると、技術に入る前に整理しなければならないことがたくさんあります。

たとえば、AWS移行やサーバ更改では、技術的に正しいだけでは足りません。

• いつ止められるのか
• 止めてはいけない時間帯はいつか
• 誰が判断するのか
• 何を移行対象にするのか
• どこまでを今回のスコープにするのか
• 障害時に誰へ連絡するのか
• 切り戻しは本当にできるのか
• リリース後に誰が見るのか

こうした話を整理しないまま進めると、案件を無事に終わらせることが難しくなります。

設定としては合っている。手順も間違っていない。でも、その作業をしてよい時間帯ではなかったり、影響を受ける人へ事前連絡ができていなかったり、最終判断者が曖昧だったりする。

そうなると、技術的には問題がなくても、現場としては「それは困る」となってしまいます。

インフラPMの仕事は、まさにこのあたりにあります。技術、顧客、チーム、運用、リスクの間に立ち、判断しやすい状態を作る。

この記事では、インフラPMの仕事を「管理する人」ではなく、技術と現場の判断をつなぐ人として考えてみます。

☑️ インフラPMは、何を見ているのか

インフラPMが見ているものは、かなり広いです。

ざっくり言うと、次のようなものを同時に見ています。

ここで大事なのは、PMが全部を自分で作業するわけではないことです。

設計は設計担当がします。構築は構築担当がします。運用引き継ぎは、運用担当と一緒に進めます。

ただし、作業がばらばらに進むと、案件全体としてつながらなくなります。インフラPMは、その接続点を見ます。

• 設計内容が顧客の要件と合っているか
• 構築手順が切替計画と矛盾していないか
• テスト観点が運用開始後のリスクを拾えているか
• 顧客説明の資料が、相手の判断材料になっているか

たとえばAWS移行案件では、設計書だけ完成していても、それだけではリリースできません。

移行対象は整理されているか。現行環境との接続関係は分かっているか。切替当日に誰が作業するのか。失敗したときに切り戻せるのか。切替後、誰が正常性を確認するのか。顧客側で最終判断する人は誰なのか。

このあたりがつながっていないと、個々の作業は終わっているのに、プロジェクトとしては前に進まない状態になります。

インフラPMは、個別作業の中身だけでなく、作業同士の接続点を見る仕事でもあると思います。

☑️ 技術担当とPMの違い

技術担当とPMの違いは、見ている時間軸と責任範囲に出やすいです。

技術担当は、担当領域を深く見ます。

• この設計で要件を満たせるか
• この設定で動作するか
• この手順で安全に作業できるか
• このログから何が分かるか
• この構成で障害に耐えられるか

一方でPMは、担当領域をまたいで見ます。

• この判断は誰がするのか
• この作業が遅れると何に影響するのか
• 顧客にいつ説明する必要があるのか
• 運用開始後に誰が困るのか
• 決まっていないことが、どこに残っているのか
• チーム内で負荷が偏っていないか

表にすると、こんなイメージです。

どちらが上という話ではありません。役割が違います。

最近、見聞きして改めてそうだなと思ったのが、技術担当にはテスト結果や手順書などの「目に見える成果」がある一方、PMにはスコープ管理、調整、期待値のコントロール、判断といった目に見えにくい成果が求められることです。

そこが、難しいところでもあり、成果が伝わりにくいところでもあると思います。

ただ、インフラ案件では、技術の話とPMの話がかなり近い距離にあります。たとえば、バックアップ設計ひとつでも、技術だけでは決まりません。

• どのデータを守るのか
• どの時点まで戻せればよいのか
• 復旧にどれくらい時間をかけられるのか
• コストとのバランスをどう見るのか
• 誰が復旧判断をするのか
• 復旧手順を誰が実行するのか
• 復旧後の業務確認を誰がするのか

これは技術の話でもあり、業務の話でもあり、顧客判断の話でもあります。

インフラPMは、こうした論点を分け、関係者が判断できる形にする必要があります。

技術的にできるかどうかだけではなく、現場として進められるかどうか。ここを見るのが、インフラPMらしい仕事だと感じます。

☑️ 実務でつまずきやすいところ

インフラPMの仕事でつまずきやすいのは、「管理しているつもりでも、実は決まっていないことが残る」ことです。

進捗表だけを見ると、案件は順調に見えることがあります。

設計は完了。構築も完了。テストも完了。課題も起票されている。会議も定期的に実施し、報告に対する顧客の反応も上々。

でも、よく確認すると、肝心なことが決まっていない。

• 移行対象は決まっているが、除外対象が曖昧
• 切替日は決まっているが、切り戻し条件が曖昧
• 設計方針はあるが、顧客が承認した証跡がない
• 監視項目はあるが、誰が見るのか決まっていない
• テストは完了しているが、何をもってOKとしたのか説明しづらい
• 課題は起票されているが、誰がいつ決めるのか決まっていない
• 会議では合意した雰囲気があるが、正式な判断者が分からない

この状態では、案件全体を前に進めにくくなります。

PMとしては「進捗率」を見たくなります。でも、未決事項が残っていることや、前提条件が欠けている・崩れていることのほうが、よほど注意したい状態です。

特にAWS移行やオンプレからクラウドへの移行では、現行環境の前提があとから出てくることがあります。

• 古いバッチが残っている
• 整理できていた範囲以外の端末からも接続がある
• 運用担当者しか知らない手順がある
• ドキュメントにない依存関係がある
• ネットワーク経路が想定より複雑
• 夜間だけ動く処理がある
• 月末月初だけ使われるシステム連携がある

こうした情報は、最初から全部きれいに出てくるとは限りません。

私も、移行計画を考える中で、業務によっては年間数回しか行わない処理があると分かり、「これはもっと早く確認しておけばよかった」と感じたことがあります。

特に切替作業では、技術的な手順だけでなく、判断の流れが大事になります。

• 作業を開始してよいのか
• 切替を続行してよいのか
• 想定外のエラーが出たとき、何分まで調査するのか
• どの条件になったら切り戻すのか
• 切り戻しを判断するのは誰なのか
• 顧客側の業務確認は誰が行うのか

ここが曖昧なままだと、作業者は手を動かせても、プロジェクトとして判断できません。

「手順はある。でも、判断の流れがない」

この状態は、かなり危ないです。

だからこそ、PMは「何が分かっていて、何がまだ分かっていないのか」を整理し続ける必要があります。

☑️ 現場での判断基準

インフラPMとして最低限確認したいのは、次の5つです。

この5つが曖昧なまま進むと、あとから手戻りが出やすくなります。

目的が曖昧だと、設計の優先順位を決めにくくなります。

コストを優先するのか。可用性を優先するのか。運用負荷を下げたいのか。セキュリティを強化したいのか。将来の拡張性を見ておきたいのか。

ここが見えないと、技術選定も説明しづらくなります。

範囲が曖昧だと、「それも今回やるんでしたっけ？」が増えます。小さな追加が積み重なると、スケジュールも品質も崩れます。

判断者が曖昧だと、会議では合意したように見えても、あとから判断が覆ることがあります。

会議では誰も反対しなかった。資料にも大きな指摘はなかった。だから進めてよいと思っていた。

でも、リリース前に別の人から「その判断は誰が承認したのか」と聞かれる。こうなると、一気に手が止まります。

リスクが曖昧だと、トラブルが起きたときに「想定していなかった」となります。

もちろん、すべてのリスクを事前に潰すことはできません。ただ、主要なリスクを認識しているかどうかで、現場の動きやすさは変わります。

運用が曖昧だと、作って終わりになります。

インフラはリリース後からが長いです。監視アラートが出たときに誰が見るのか。バックアップ失敗時に誰が対応するのか。証明書更新やOSパッチ適用を誰が管理するのか。障害時にどこまで一次対応するのか。

ここを軽く見ると、あとから困ります。

PMがすべてを決める必要はありません。ただし、誰が決めるのか、何を決める必要があるのかは、見えるようにしておく必要があります。

☑️ PM視点を持つと、エンジニアの仕事も変わる

PMにならない人でも、PM視点を持つ意味はあります。

設計や構築を担当しているときでも、少しだけ視点を広げると、仕事の質が変わります。

• なぜこの構成にするのかを説明できる
• 設計の前提条件を残せる
• 課題を早めに共有できる
• 顧客や運用担当が判断しやすい資料を作れる
• あとから困りそうな点を先に言える
• 技術的な選択肢と、その影響をセットで説明できる

これは、すごく派手なスキルではありません。でも現場ではかなり助かります。

たとえば、設計レビューで見られるのは、設定値そのものだけではありません。

なぜその設定にしたのか。他の選択肢をどう見たのか。どのリスクを許容したのか。運用上の負荷はどうなるのか。障害時にどう動く想定なのか。

こうした説明ができると、レビューの質も上がります。

逆に、設定値は正しくても、判断理由を説明できないと不安が残ります。

「たぶんこれで大丈夫です」「これが良いと思いました」だけでは、顧客もチームも判断しづらいです。

AWSのサービス選定でも同じです。

この構成で動く。このサービスを使えば実現できる。この設定で要件を満たせる。

それは大事です。ただ、それに加えて、次の点まで説明できると、技術的な提案が判断材料になります。

• なぜこのサービスを選んだのか
• 運用は誰が見るのか
• 障害時の影響はどこまでか
• コストはどれくらい増えるのか
• 将来的に変更しやすいのか

PM視点とは、全部を管理することではありません。自分の作業が、案件全体のどこにつながっているかを見ることだと思います。

☑️ まず意識したい確認ポイント

インフラPMの仕事を理解するうえで、まずは次の観点を押さえると分かりやすいです。

• 作業ではなく、判断が止まっていないか
• 技術的な説明が、相手の判断材料になっているか
• 決まっていないことを、決まったように扱っていないか
• リスクを隠さず、対応方針とセットで出せているか
• 運用開始後に誰が困るかを考えているか
• 会議の合意が、議事録や課題表に残っているか
• 切替時の続行条件と切り戻し条件が明確か
• 最終判断者が誰かを確認できているか

特に「決まっていないことを、決まったように扱わない」は大事です。

現場では、雰囲気で進んでしまうことがあります。

会議で誰も反対しなかった。なんとなく了承された気がする。たぶんこの方針でよさそう。前回も似たような流れだったから大丈夫そう。

でも、あとから確認すると、実は誰も正式には判断していなかった。判断していても、エビデンスが残っていなかった。これでは困ります。

だから、PMは決める人である前に、決まっていることと決まっていないことを見えるようにする人でもあります。こうした積み重ねが、プロジェクトを進めやすくします。

作業が遅れているのか。判断が止まっているのか。情報が足りないのか。関係者の合意が足りないのか。

同じ「進んでいない」でも、原因が違えば打ち手も変わります。

インフラPMは、その違いを見つけて、次に進める状態を作る仕事だと思います。

☑️ まとめ

インフラPMは、単に進捗を管理する人ではありません。

技術、顧客、チーム、運用の間に立ち、プロジェクトを判断しやすい形に整理する仕事です。

実務では、次のような動きが求められます。

• スコープを明確にする
• 未決事項を見える化する
• リスクを早めに共有する
• 技術的な内容を相手が判断できる言葉にする
• 設計、構築、テスト、運用をつなげて見る
• 切替時の判断ポイントを整理する
• 誰が何を決めるのかを明確にする

PMという言葉だけを見ると、少し遠い仕事に見えるかもしれません。

でも、インフラエンジニアがPM視点を持つと、日々の設計や運用の見え方も変わります。

「この設定で動くか」だけでなく、「この判断を誰がどう受け取るか」まで考える。

「この手順で作業できるか」だけでなく、「想定外のことが起きたときに、誰がどう判断するか」まで考える。

技術を深く見ること。現場の流れを見ること。判断しやすい状態を作ること。

インフラPMの仕事は、この3つをつなぐ役割なのだと思います。

☑️ 次に読みたい記事

このテーマは、要件定義、設計レビュー、AWS移行計画の話にもつながります。

インフラ要件定義で最初に確認したい7項目では、案件の目的、スコープ、優先順位、意思決定者を最初にそろえる方法を整理しています。

AWS移行プロジェクトで最初に決めることでは、目的・範囲・停止時間・切戻し・判断者を、移行初期に確認する順番で紹介しています。