発注者側PMの役割とは？仕事内容・受注側との違い・失敗しないスキルを解説

「開発会社に依頼したのに、思い通りのシステムができあがらなかった」という経験はありませんか？

要件をきちんと伝えたつもりでも、完成したシステムが現場の業務フローと合わない。追加の修正を依頼するたびに費用がかさみ、納期も大幅に遅れてしまった。このような状況に陥ったとき、多くの発注担当者は「開発会社の選択を間違えた」と感じるかもしれません。

しかし、開発プロジェクトが失敗する原因の多くは、実は発注者側にあります。具体的には、プロジェクトを管理する発注者側のPM（プロジェクトマネージャー）が機能していないことが大きな要因です。

本記事では、システム開発の外注を担当する方に向けて、発注者側PMの定義・役割・仕事内容から、フェーズ別の具体的な動き方、必要なスキル、そしてPMが機能しない場合に起きる失敗パターンまでを解説します。秋霜堂株式会社は受託開発会社として多くのプロジェクトに携わってきた立場から、「発注者側のPMにこう動いていただけるとプロジェクトが成功する」という実体験に基づくノウハウをお伝えします。

Contents — 目次

発注者側PMとは何か
発注者側PMの主な仕事内容5つ
プロジェクト各フェーズでの動き方
発注者側PMに必要な5つのスキル
発注者側PMが機能しないとどうなるか
受注側から見た「理想の発注者側PM」
まとめ

—Free Download / 資料ダウンロード

【サンプル】システム開発提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

発注者側PMとは何か

発注者側PM（プロジェクトマネージャー）とは、システム開発を外注する企業が自社側に設置する、プロジェクト全体を管理する責任者のことです。

システム開発プロジェクトには、開発を依頼する「発注者側」と、開発を担当する「受注者側（開発会社）」という2つの立場が存在します。多くの方は「PMといえば開発会社のもの」と考えがちですが、開発会社のPMはあくまでも請け負ったスコープの管理が役割です。プロジェクト全体を成功させるためには、発注者側にもPMが必要です。

特に、複数のベンダーに開発を発注する場合や、社内の複数部門が関わるプロジェクトでは、発注者側PMが全体を統括しなければ、誰も責任を持つ人間がいない状態になってしまいます。

システム開発の外注でよく聞かれる「丸投げ」——つまり開発会社に全て任せてしまうスタイルは、プロジェクトの成功率を大幅に下げます。発注者側PMが社内の業務要件を適切に管理し、開発会社と連携することが、プロジェクト全体のQCD（品質・コスト・納期）を守ることに直結します。

受注側PMとの役割の違い

受注側PM（開発会社のPM）と発注者側PMは、どちらも「プロジェクトマネージャー」と呼ばれますが、その役割の範囲が大きく異なります。

	発注者側PM	受注側PM
責任範囲	プロジェクト全体（複数ベンダー含む）	自社が請け負ったスコープ
主な相手	社内各部門・経営層・開発会社	発注者側PM・自社の開発チーム
重視する観点	業務要件の正確な定義・意思決定	技術要件の実現・工程管理
必要な専門知識	業務知識・コミュニケーション力	プロジェクト管理・技術知識

SCROLL→

わかりやすく言うと、「発注者側が全体、受注側が部分」という関係です。受注側PMがどれだけ優秀でも、発注者側の業務要件が曖昧だったり、意思決定が遅れたりすると、プロジェクトは必ず行き詰まります。

PMOとの違い

「PMO（プロジェクトマネジメントオフィス）」という言葉も耳にすることがあるかと思います。PMOはPMの補佐機能を担う組織または担当者であり、情報整理やルール策定、進捗レポートの作成などを担います。

PMとPMOを一言で区別するなら、「PMは意思決定、PMOは情報整理」です。中規模以下のプロジェクトでは、発注者側PMとPMOを1人が兼任するケースが多く、まずはPMとしての役割を担える人材を立てることが先決です。

発注者側PMの主な仕事内容5つ

発注者側PMが担当する業務は多岐にわたりますが、特に重要な5つを解説します。

社内の業務要件の取りまとめ

最も重要な仕事が、社内の業務要件を整理して開発会社に伝えることです。営業部門・経営管理部門・現場スタッフなど、立場によってシステムへの期待は異なります。その多様な意見をヒアリングし、矛盾を整理したうえで「何をシステム化すべきか」を確定させるのが発注者側PMの役割です。

業務要件の取りまとめは単なる意見収集ではありません。要望を全て実現することは予算的にも技術的にも不可能なため、「何を実現して、何を諦めるか」の優先順位を決める判断力が求められます。

開発会社とのコミュニケーション管理

開発会社との窓口として、定例ミーティングの設定・議事録の確認・質問への回答期限の管理などを担当します。

社内にはITの専門知識を持たない担当者もいるため、開発会社から届く技術的な内容を業務担当者に分かりやすく翻訳する「通訳機能」も重要な役割です。逆に、社内の業務用語を開発者に伝わる形で整理する作業も発注者側PMが担います。

スケジュール・予算の管理

開発計画書やスケジュールを確認し、予算超過のリスクを早期に検知することも重要な業務です。開発会社から出てくる「追加費用が発生します」という報告に対して、適切に判断できる体制を整えておく必要があります。

システム開発の費用相場を把握しておくことで、開発会社からの見積もりや追加費用の妥当性を判断しやすくなります。

成果物のレビュー・受入判断

要件定義書・設計書・プロトタイプ・テスト結果など、各フェーズで開発会社から提出される成果物を確認し、「業務要件を満たしているか」を判断します。

この判断を開発会社に任せてしまうと、技術的には完成しているが業務現場では使えないシステムが生まれます。発注者側PMは「ビジネス視点での受入判断」を主導する責任を持ちます。

社内調整・意思決定の主導

開発プロジェクトでは日常的に意思決定が求められます。「仕様変更の優先度をどうするか」「追加費用を承認するか」「納期を延ばすかスコープを削るか」——こうした判断を迅速に行えるのが、発注者側PMの最も重要なスキルです。

意思決定の遅れは、プロジェクトの遅延とコスト増に直結します。 開発会社からの質問に1週間以上回答がない状況が続くと、開発チームは待機状態になり、その分の費用が発生します。

プロジェクト各フェーズでの動き方

発注者側PMの動き方はプロジェクトのフェーズによって異なります。「いつ、何をすべきか」を把握しておくことが、プロジェクト成功の鍵です。

要件定義フェーズ（最重要）

要件定義フェーズは、プロジェクト全体の中で最も重要なフェーズです。この段階の曖昧さが、後のトラブルの8割を生むと言っても過言ではありません。

発注者側PMがこのフェーズで行うべきことは以下の通りです。

業務要件ヒアリングの主導 全部門の担当者から要望を収集します。経営層・管理職・現場担当者それぞれの視点でニーズが異なるため、個別ヒアリングと全体会議を組み合わせながら進めます。

優先順位の決定 収集した要望を全て実現することはできません。「リリース時に必須の要件」「あれば便利な要件」「将来的に追加する要件」に分類し、開発スコープを明確にします。

要件定義書のレビュー・承認 開発会社が作成した要件定義書を確認し、業務実態と一致しているかを検証します。技術的な内容は開発会社に任せてよいですが、業務フローの記載については発注者側PMが責任を持って確認します。

要件定義フェーズを終えた後、仕様変更が発生した場合は適切な変更管理プロセスで対応することが重要です。変更管理プロセスを事前に定めておくことで、スコープの際限ない拡大を防げます。

開発・設計フェーズ

開発フェーズでは、発注者側PMは「監視と調整」の役割を担います。開発作業そのものは開発会社に任せますが、以下の点を定期的に確認します。

週次進捗確認ミーティングの実施 進捗状況を週次で確認するミーティングを設定します。遅延が発生している場合は早期に検知し、対応策を協議します。

設計書・画面モックアップのレビュー 設計書や画面モックアップが業務要件を満たしているかを確認します。特に画面モックアップは、実際に業務を行う現場担当者も一緒にレビューする機会を設けると、後々の「使いにくい」という問題を予防できます。

追加要望の優先度判断 開発中に「やはりこの機能も追加したい」という要望が出ることは珍しくありません。発注者側PMは追加要望の必要性と影響（コスト・納期・既存開発との整合性）を判断し、取り込むかどうかを決定します。

テスト・受入フェーズ

テスト・受入フェーズは、「このシステムを本当に業務で使えるか」を最終確認するフェーズです。発注者側PMが主導すべき重要な段階です。

UAT（ユーザー受入テスト）の計画立案・実施主導 UAT（User Acceptance Test）とは、実際にシステムを使う業務担当者がテストを行う受入テストです。開発会社が作成したテスト計画をベースに、業務視点のテストケースを追加します。

テスト結果の業務部門への確認 テストの実施は発注者側PMだけが行うのではなく、実際に業務で使う担当者が参加することが重要です。「開発会社がテストしてOKだった」だけでは、業務現場での問題は発見できません。

Go/No-Goの最終判断 テスト結果を踏まえて、本番リリースするかどうかの最終判断を行います。軽微な不具合が残っている場合、リリースを延期するか予定通りリリースするかの判断は、発注者側PMが下す重要な意思決定です。

発注者側PMに必要な5つのスキル

「PMは専門家でないとできない」と思われがちですが、発注者側PMに最も必要なのは技術的な知識ではありません。以下の5つのスキルを意識することが重要です。

業務理解力（最重要）

発注者側PMに最も必要なスキルは、自社の業務をシステム化可能な粒度で説明できることです。「この業務をシステムで効率化したい」という要望を、開発会社が理解できる形で具体化する能力が求められます。

「Aという業務のどのプロセスを、どのようにシステム化することで、何が改善されるのか」——このレベルで語れる担当者がPMを務めると、プロジェクトは驚くほどスムーズに進みます。

コミュニケーション能力

社内の「技術に詳しくない業務担当者」と、「技術的な言語で話す開発者」の間をつなぐ橋渡し役が発注者側PMです。技術用語を業務担当者に分かりやすく説明し、業務用語を開発者に伝わる形で整理する「通訳機能」を担います。

また、経営層への報告や関係部門との調整など、社内の様々なステークホルダーと連携する能力も求められます。

意思決定力

「スピーディーかつ明確な意思決定」が、発注者側PMに最も期待されるスキルです。 開発会社からの問い合わせに対して、翌営業日中に回答できる体制を作ることが理想です。

「全ての情報が揃ってから判断する」という姿勢は、開発プロジェクトでは通用しません。6〜7割の情報で判断し、後から軌道修正できる体制を整えることが重要です。判断が遅れるほど、開発コストと納期への影響が大きくなります。

スケジュール管理

ガントチャートやプロジェクト管理ツールを読み解き、遅延の兆候を早期に検知できることが求められます。技術的な詳細の理解は不要ですが、「当初の予定からどれだけ遅れているか」「遅れが最終納期に影響するか」を判断できることが大切です。

また、社内の承認手続きや関係部門との調整に必要な時間を事前に見込んだスケジュール管理も、発注者側PMならではの重要な視点です。

リスク管理力

問題が起きた際に「誰に報告するか」「どう対処するか」を判断する能力です。リスク管理で重要なのは、問題が発生したときに隠さず、早期に報告・対処できる文化を作ることです。

開発プロジェクトでは何らかの問題が発生することはほぼ必然です。問題を早期に発見し、発注者・受注者双方で対応策を協議できる関係性を構築することが、プロジェクト成功の大きな要因になります。

発注者側PMが機能しないとどうなるか

受託開発会社として多くのプロジェクトを経験してきた秋霜堂株式会社から見ると、「発注者側に機能するPMがいないこと」は、プロジェクト失敗の最大の原因です。具体的にどのような問題が起きるのか、4つの失敗パターンを紹介します。

失敗パターン1: 「要件がどんどん変わる」

要件定義を曖昧にしたまま開発が始まると、開発中に「やはりこうしたい」という追加要望が際限なく出てきます。これを「スコープクリープ」と呼び、プロジェクトの予算超過・納期遅延の主要因の一つです。

発注者側PMがいないプロジェクトでは、要望の優先度判断をする人間がいないため、開発会社は全ての追加要望を受け入れるか、あるいは取捨選択の判断を求めて開発を止めるしかありません。いずれも発注者・受注者双方にとってデメリットが大きい状況です。

スコープクリープを防ぐためには、変更管理プロセスをプロジェクト開始前に確立し、仕様変更の申請・承認フローを定めておくことが有効です。

失敗パターン2: 「決裁に時間がかかって開発が止まる」

発注者側に意思決定できる担当者がいないと、開発会社からの問い合わせへの回答に数日から1週間以上かかることがあります。この間、開発チームは次の作業に進めず、実質的な待機状態になります。

開発チームの待機状態は、コスト増に直結します。 固定報酬契約であれば納期が延びるほど開発会社の負担が増え、時間単価契約であれば発注者側の費用が直接増加します。

「開発会社に全て任せているから、質問への回答はすぐにできなくても大丈夫」という意識が、プロジェクトを停滞させます。

失敗パターン3: 「完成品が現場に合わない」

業務部門へのヒアリングを十分に行わないまま要件を確定してしまうと、実際にシステムを使う現場担当者の視点が抜け落ちます。その結果、技術的には完成しているが「業務フローと合わない」「使いにくくてかえって非効率」というシステムが完成してしまいます。

このケースでは、リリース後に大量の修正依頼が発生し、追加費用と追加期間が必要になります。要件定義フェーズで現場担当者を巻き込んだヒアリングを行うことが、根本的な対策です。

失敗パターン4: 「受入テストが形骸化する」

受入テストの計画を立てず、開発会社が「テスト完了しました、リリースできます」と言ったらそのまま受け入れてしまうケースです。開発会社が行うテストは技術的な動作確認が中心であり、業務現場での使用シナリオを網羅していないことが多くあります。

その結果、リリース後に「この業務ではうまく使えない」「特定の操作をすると不具合が出る」という問題が多発し、業務担当者の信頼を失ってしまいます。受入テストを発注者側PMが主導することで、こうした問題を事前に検知できます。

受注側から見た「理想の発注者側PM」

受託開発会社として多くのプロジェクトに携わってきた秋霜堂株式会社の経験から、「プロジェクトが成功するとき」に共通している発注者側PMの特徴をお伝えします。

判断が早い

プロジェクトが成功するケースでは、必ずと言っていいほど、発注者側PMの判断が早いです。開発中に質問をすると、翌営業日中には回答が返ってきます。この「翌日に答えが出る」という体制が、開発チームのモチベーションを保ち、スケジュールを守ることに大きく貢献します。

現場の声を吸い上げてくれる

「経営層の方針」だけでなく「現場で実際に使う担当者の声」も丁寧に拾い上げてくれる発注者側PMとのプロジェクトは、リリース後の満足度が高い傾向があります。要件定義から受入テストまで、現場を巻き込む場を作ってくれる方と進めるプロジェクトは、受注者側としても安心して取り組めます。

「YES/NO」を明確に言える

「検討します」で終わらず、期限までに「YES/NO」の判断を返してくれる発注者側PMは、開発チームにとって非常に助かります。判断を保留したまま開発を進めると、後から大幅な手戻りが発生するリスクが高まります。

TechBandのような伴走型支援との相性

発注者側PM機能を自社で整えることが難しい場合、外部のサービスを活用する選択肢もあります。秋霜堂株式会社が提供する**TechBand**は、開発プロジェクトの発注者側PM機能を担う伴走型の支援サービスです。「社内にIT担当者がいない」「PMを担える人材がいない」という状況でも、スムーズな開発プロジェクトを実現するためのサポートを提供しています。