インフラが分かる受託PMの市場価値：見積もりと障害対応での実例

職務経歴書に「ネットワークが分かります」と一行書いて、そこで手が止まる。受託でPM経験は積んできたけれど、案件規模は大きくない。インフラの経験は、そのPM経験を押し上げてくれるのか、それとも昔の話として流されるのか。

私はネットワークエンジニアを6年やり、整体師の5年をはさんで、いまは受託開発でPMと開発を同時にやっています（43歳、年収600万円）。案件は300万円から5,000万円くらいまで、社内と協力会社を合わせたチームで回してきました。

インフラの知識がはっきり効いたのは、クラウドのネットワーク構築に最初から入れたことと、通信が届かないときの切り分けで開発メンバーを手伝えたことです。設計書やパラメータシート、作業手順書やコンチプラン（うまくいかなかったときの手を先に決めておく計画）の考え方も、開発の仕事で大枠は同じでした。

ただ、それだけで受託のPMが務まったかというと、そうではありません。

では、インフラの外側で、何が足りなかったのか。

受託のPMで、「インフラが分かる」は何の強みになるのか

ネットワークエンジニアの頃も少し上流から下流の工程を経験していたので、開発に移ったときも、工程の全体像はまったく経験がない人よりは持てていたと思います。

移った先では、インフラはもうクラウドが主流でした。それでもAWSやAzure、GCPを触る仕事は多く、アプリ開発一筋の人よりサブネットやVPN、セキュリティ、FWまわりの知識はあったので、初手からインフラ構築で役に立てました。

では、ネットワークから開発に移った直後、ほかに何でつまずいたのか。

ここで大事だと思うのは、「インフラが分かる」を知識の名前のまま置いておかないことです。サブネットが分かる、ではなく、クラウドのネットワーク構築を移った直後から担当できた。設計書や手順書の考え方が、開発の工程でも大枠そのまま通じた。PM経験を棚卸しするときは、こうした「やった場面」に置き換えておくと、相手に伝わる形になります。

見積もりの前に、PMとして何を確かめているか

インフラの知識で見積もりの漏れを見つけた、と言い切れる場面までは、私には書けません。書けるのは、受注の前にPMとして何を確かめているかです。

うちの会社では、新しい案件の入口としてマッチングサイト（発注ナビ）の募集に応募しています。営業がまず明らかにNGなものをふるいにかけ、そのあと、案件の内容や要件にリスクがないかを私が確認する流れです。

営業が見ているのは、予算の有無、案件の確度、納期、企業の大きさ。私が見ているのは、要件の曖昧さ、求められている機能に対して納期が適切か、その納期に社内のリソースが足りるか、の3つです。

半年前ごろ、ブロックチェーンを使ったアプリ開発の案件で、面談まで進んだことがあります。先方からは、この部分は自社で開発するので、この部分だけお願いしたい、予算は十数万円で決まっている、と伝えられました。内容が暗号資産に関わりそうでリスクがあると判断したうえに、打ち合わせや要件確認の段階でコストオーバーになると見て、参考として見積もりを出し、そこで止まりました。

逆に、提案の前提が実際のシステムとずれたまま走り出すと、あとがどれだけ重くなるかは、5,000万円の案件で味わいました。提案が実際のシステムや運用の要件と合っておらず、事前調査の段階でメンバー全員が「こんなの無理だよ」となりました。顧客と合意を取り直す説明資料は、10回を超えて作り直しています。

では、案件の規模や関わる人の数で、忙しさはどれくらい変わるのか。

職務経歴書に書くなら、「インフラが分かる」と並べて、受注の前に何を確かめているかも書いておけます。

障害のとき：通信が届かない原因の切り分け

障害や不具合のときに、ネットワークの知識が分かりやすく役に立ったのは、通信まわりの切り分けでした。

アプリ開発をしてきたメンバーは、サーバーの知識はあっても、IPアドレスの考え方やルーティング、デフォルトゲートウェイといった所で、通信が届かないときにつまずくことが多かったんです。ネットワークエンジニアの頃の記憶が残っていたので、そこを私がサポートしました。

顧客への説明までインフラの知識で変わったか、と聞かれると、そこは自分の経験からは言えません。言えるのは、通信が届かないときの切り分けで、チームを支えられたということまでです。

協力会社との話：インフラの外側は、聞きながら覚えた

協力会社と一緒に作った最初のプロダクトでは、担当を実装のレイヤで分け、フロントエンドを協力会社のエンジニアに任せました。当時の私はバックエンドとフロントエンドの違いも分かっておらず、会話をしながら仕組みを少しずつ理解していった、というのが正直なところです。

インフラが分かるから協力会社との話がすぐ早くなった、とは言えません。

では、チーム開発もPMも初めての状態で、最初の3か月は何から手を付けたのか。

インフラだけでは足りなかったこと：開発側の知識

足りなかったのは、開発のやり方そのものでした。

世代管理はGitHubが主流で、その使い方も、Dockerでの開発環境づくりも、テストコードも、最初は分からず会社の人に聞いていました。ほかの人が作っていたバックエンドに一人で手を入れたときは、テストコードが足りずにCIに止められたこともあります。

PMとしても、開発側の理解が要る場面がありました。1,000万円の案件では、後輩の実装に多くの不具合が見つかったんです。指摘は伝えても、修正事項を明確に指示しないと正しく伝わらず、明後日の方向に修正が進んで手戻りが増えました。込み入った修正は、結局自分の手でやっています。

では、5年ITを離れていた人が、開発の現場にどうやって戻れたのか。

インフラの強みは、開発側の知識で補ってはじめて、受託のPMの仕事に乗りました。

職務経歴書と面接で、この強みをどう言葉にするか

私は今の会社で、PMとして採用面接をする側にも座りましたが、技術よりも、コミュニケーションと、自分から動ける人かどうかを見ていました。面談で見られるのは、人柄と実績くらいしかないのかな、と思っています。

では、指示待ちかどうかを、面接ではどんな質問で見ていたのか。

だからこそ、インフラの経験も、知識の名前ではなく実績の形で書いたほうが届くと思います。

会社として案件に応募するときも、同じ考え方をしています。完全に同じ実績というものはほとんどないので、要件の一部の機能を実装したことがあるなど、関係のある社内実績をプロフィールに載せるようにしています。

自分の経歴に置き換えるなら、たとえばこんな書き方です。

• クラウドのネットワーク構築（サブネット、VPN、FW）を、開発に移った直後から担当
• 通信が届かないときの切り分けで、開発メンバーをサポート
• 受注前に、要件の曖昧さ・機能に対する納期・社内リソースを確認

どれも、私がやった場面をそのまま一行にしただけです。

では、こうした経験を並べたとき、年収600万円は案件規模と比べて妥当なのか。

職務経歴書の「ネットワークが分かります」で手が止まっていたら、その一行を、自分がやった場面に書き換えるところから始めてみてください。書き換えた経歴にどんな会社から声がかかるのかは、スカウト型のサービスに経歴を置いて確かめる方法もあります。

では、届いたスカウトがPMばかりのとき、中身はどう見分ければいいのか。