「御社のプロジェクトマネージャーはどなたですか」。初めてシステム開発を外注したとき、開発会社からこう聞かれて戸惑った経験はないでしょうか。提案書には「PM」という役割が当たり前のように記載されているのに、その意味も、自社が何をすべきかも、よく分からないまま話が進んでいく。専門知識のない発注担当者にとって、これは決して珍しい状況ではありません。
システム開発の成否は、技術力だけでなく「プロジェクトの進め方」に大きく左右されます。その進め方を統括するのがプロジェクトマネージャー（PM）です。ところが、PMについて解説する記事の多くは「PMになりたい人」や「開発会社の中の人」に向けて書かれており、発注する側が知りたい「自分は何を任せ、何を自分でやるべきか」という視点はほとんど語られていません。
そして、ここを理解しないまま「開発会社にPMがいるなら、あとは任せておけば大丈夫だろう」と考えてしまうと、いわゆる「丸投げ」による失敗に陥りやすくなります。期待していたものと違うシステムが納品される、追加費用が想定外に膨らむ、納期が大幅に遅れる——こうしたトラブルの背景には、発注者側の関わり方の問題が潜んでいることが少なくありません。
この記事では、プロジェクトマネージャーとは何かという基本から、PMの仕事内容、混同されやすいPMO・PLとの違いまでを発注者にも分かる言葉で整理します。その上で、開発会社のPMに任せきりにせず、発注者として「何をどこまで担うべきか」の判断基準を具体的に解説します。読み終えたとき、開発会社との役割分担を自信を持って決められる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
プロジェクトマネージャー（PM）とは｜システム開発における役割
プロジェクトマネージャー（PM）とは、システム開発プロジェクトを成功に導くために、全体を統括する責任者のことです。発注者として最初に押さえておきたいのは、「PMはプロジェクトの結果に責任を持つ司令塔である」という点です。
PMの定義｜プロジェクトの責任者としてQCDを管理する
PMの役割を一言で表すなら、「QCD（品質・コスト・納期）を管理し、プロジェクトを計画通りに完遂させること」です。
- Q（Quality／品質）: 求められた機能や性能を満たすシステムを作る
- C（Cost／コスト）: 予算の範囲内で開発を収める
- D（Delivery／納期）: 決められたスケジュール通りに完成させる
この3つは互いにトレードオフの関係にあります。たとえば品質を高めようとすればコストや期間が増え、納期を急げば品質が犠牲になりやすくなります。PMは、刻々と変化する状況の中でこの3つのバランスを取りながら、プロジェクト全体が破綻しないように舵取りをします。
発注者にとって重要なのは、PMが「単なる進行係」ではなく「プロジェクトの結果に責任を負う立場」だということです。何か問題が起きたとき、その対応方針を決め、関係者を調整し、ゴールに向けて軌道修正するのがPMの仕事です。
PMはどこにいる？｜開発会社側に置かれるのが一般的
システム開発を外注する場合、PMは開発会社（受注側）に配置されるのが一般的です。開発チームを率い、エンジニアの作業を管理し、発注者との窓口になるのが受注側のPMです。
発注者から見ると、PMは「開発に関するやり取りの主な相手」になります。定例会で進捗を報告するのも、仕様の確認を求めてくるのも、課題が発生したときに相談してくるのも、多くの場合このPMです。つまりPMは、発注者と開発現場をつなぐ接点として機能します。
ここで一つ、発注者が誤解しやすいポイントがあります。「開発会社にPMがいるのだから、自社は何もしなくていい」というわけではないという点です。受注側のPMが管理するのはあくまで「開発作業」であり、「発注者側の意思決定や社内調整」までは管理できません。なぜ発注者側にも関与が必要なのかは、のちほど詳しく解説します。
プロジェクトマネージャーの主な仕事内容
PMの仕事は多岐にわたりますが、発注者の立場では「会議でどんなことが報告されるのか」「どこを見れば異変に気づけるのか」をイメージできることが大切です。ここでは、開発の流れに沿ってPMの業務を整理します。
フェーズ別に見るPMの業務
システム開発は、おおまかに以下のフェーズで進みます。各フェーズでPMが担う代表的な業務を見てみましょう。
フェーズ | PMの主な業務 |
|---|---|
企画・計画 | プロジェクトの目標設定、全体スケジュールと体制の策定、予算計画 |
要件定義 | 発注者の要望のヒアリング、実現すべき機能の整理、仕様の取りまとめ |
設計・開発 | 開発タスクの割り振り、進捗管理、品質チェック、課題の管理 |
テスト | テスト計画の管理、不具合対応の進行、品質の最終確認 |
リリース・運用 | 納品スケジュールの管理、リリース対応、運用への引き継ぎ |
これらを通じてPMが一貫して行っているのが、次の管理業務です。
- 進捗管理: 計画と実績のズレを把握し、遅れがあれば対策を打つ
- コスト管理: 予算の消化状況を見ながら、想定外の費用が出ないよう調整する
- 品質管理: 成果物が要求水準を満たしているかをチェックする
- リスク管理: 問題が起きそうな箇所を事前に察知し、先回りで手を打つ
- ステークホルダー調整: 発注者・開発チーム・関係部署の間に立って合意形成を進める
発注者との接点が生まれる場面
PMの業務のうち、発注者が直接関わるのは主に次の3つの場面です。
- 要件の確認: 「この機能はこういう動きで良いか」「優先順位はどうするか」といった確認を求められる場面。発注者の回答が遅れると、開発全体が止まることもあります。
- 仕様の承認: 設計内容や画面イメージを示され、「これで進めて良いか」の判断を求められる場面。ここで承認したものが開発の前提になるため、慎重な確認が必要です。
- 課題のエスカレーション: 開発中に判断が必要な問題が発生したとき、PMから発注者に相談・報告が上がってくる場面。
これらの場面で発注者がどう振る舞うかが、プロジェクトの進行に直結します。PMがどれだけ優秀でも、発注者からの回答や判断が滞れば、プロジェクトは前に進みません。この「発注者の関与が成否を分ける」という構造は、のちほど改めて掘り下げます。
PMとPMO・PL（プロジェクトリーダー）の違い
開発会社の提案書や体制図には、PM以外にも「PMO」「PL」といった役割名が並ぶことがあります。これらは混同されやすいのですが、責任範囲が明確に異なります。体制図を読み解くために、違いを整理しておきましょう。
PMとPMOの違い｜意思決定する人か、支援する人か
PMO（Project Management Office／プロジェクトマネジメントオフィス）とは、PMやプロジェクトを支援する役割・組織のことです。両者の最大の違いは「意思決定するかどうか」にあります。
項目 | PM | PMO |
|---|---|---|
役割 | プロジェクトの統括・推進 | PM・プロジェクトの支援 |
意思決定 | する（最終責任者） | しない（支援が中心） |
主な業務 | QCD管理、課題解決、関係者調整 | 進捗の取りまとめ、ルール整備、資料管理、複数プロジェクトの横断管理 |
配置されるケース | ほぼすべてのプロジェクト | 大規模・複数同時進行のプロジェクト |
PMが「決める人」だとすれば、PMOは「決めやすくする人」と言えます。PMOは進捗データの集約やドキュメント整備などの裏方業務を担い、PMが意思決定に集中できるよう環境を整えます。小〜中規模の開発ではPMOが置かれないことも多く、その場合はPMがPMOの役割も兼ねます。
発注者として体制図を見るときは、「PMOがいる＝それだけ大きく複雑なプロジェクトとして体制が組まれている」というシグナルとして読み取れます。
PMとPL（プロジェクトリーダー）の違い｜全体責任者か、現場リーダーか
PL（プロジェクトリーダー）とは、開発現場のチームを率いる現場リーダーのことです。PMがプロジェクト「全体」に責任を持つのに対し、PLは開発チームの「現場」をまとめる立場です。
項目 | PM | PL |
|---|---|---|
視点 | プロジェクト全体（経営・予算・対外調整） | 開発現場（技術・チーム運営） |
主な相手 | 発注者・関係部署・上層部 | 開発メンバー・エンジニア |
主な業務 | 計画立案、予算管理、対外調整、最終責任 | チームの作業管理、技術的な指示、現場の進捗把握 |
イメージとしては、PMが「監督」、PLが「現場のキャプテン」に近い関係です。規模の小さいプロジェクトでは、1人がPMとPLを兼任することもあります。
発注者がやり取りする主な相手はPMですが、技術的な細部の話ではPLが同席することもあります。役割の違いを知っておくと、「誰に何を聞けばよいか」が分かりやすくなります。
発注者側にもプロジェクトマネージャーが必要な理由
ここが本記事の核心です。「開発会社にPMがいるのに、なぜ自社にも管理する人が必要なのか」——この疑問に正面から答えます。結論から言えば、開発会社のPMがいかに優秀でも、発注者側に「意思決定と社内調整を担う責任者」がいなければ、プロジェクトは高い確率でつまずきます。
「丸投げ」が失敗を招く構造
システム開発における「丸投げ」とは、要件や判断を開発会社に任せきりにし、発注者が主体的に関与しない状態を指します。一見、専門家に任せるのは合理的に思えますが、実際には失敗の典型パターンです。
失敗が起きる構造は、次のようなものです。発注者側の担当者が自社の業務要件を十分に言語化できないまま開発が始まると、開発会社は「発注者の頭の中にあるはずの正解」が分からないまま作業を進めることになります。たとえば「Excelでやっている業務をシステム化したい」という依頼は、発注者には明確な要件に思えても、開発側からすると「Excelの何を、どうシステム化するのか」がまったく分からない状態です（参考: システム開発を外注先に丸投げは危険！発注者が果たすべき責任とは？（Rabiloo））。
この認識のズレを放置したまま開発が進むと、次のような問題が連鎖します。
- 要件が曖昧なまま設計・開発が進み、完成したものが期待と食い違う
- 途中で必要な機能が次々と発覚し、追加費用が想定外に膨らむ
- 手戻りが発生し、納期が大幅に遅れる
つまり「丸投げ」の本質的な問題は、開発会社の能力不足ではなく、発注者と開発会社の間でコミュニケーションが断絶し、要件がズレたまま進んでしまうことにあります。
発注者側PM（窓口責任者）の役割
この断絶を防ぐために必要なのが、発注者側に立つ「窓口責任者」、いわば発注者側のPMです。専任である必要はなく、発注担当者がこの役割を兼ねることも多いのですが、果たすべき機能は明確です。
- 社内意見の取りまとめ: 各部署から出てくる要望や、しばしば矛盾する意見を整理し、開発会社に渡せる一つの方針にまとめる
- 迅速な意思決定: 開発会社から確認や判断を求められたとき、社内を調整して期限内に回答を返す
- 優先順位の判断: 予算や期間の制約の中で、「何を作り、何を諦めるか」を決める
開発会社のPMは「どう作るか」のプロは担えても、「自社にとって何が正解か」を決めることはできません。自社の業務やゴールを最もよく知っているのは発注者自身だからです。だからこそ、開発会社のPMと発注者側の窓口責任者が車の両輪のように機能することで、はじめてプロジェクトは前に進みます。
発注者側PMが担うべき具体的な仕事内容・フェーズ別の動き方・必要なスキルについては、発注者側PMの役割とは？で詳しく解説しています。
発注者の「協力義務」という考え方
発注者の主体的な関与は、単なる心構えの問題ではありません。法的にも「発注者には協力義務がある」と考えられています。
システム開発をめぐる裁判では、ユーザー（発注者）は自ら積極的にベンダー（開発会社）との打ち合わせに応じ、開発に協力すべき信義則上の義務を負うと判断された例があります。具体的には、要望する機能を適時に明確に伝えること、開発会社からの質問や確認に適時に回答すること、要件定義や設計に必要な資料・データを提供することなどが、協力義務の内容として挙げられています（参考: システム開発のプロジェクトマネジメント義務と協力義務（弁護士法人クラフトマン）、「ベンダー任せ」が招く経営危機（PwC））。
実際の裁判例でも、発注者側の協力不足が開発失敗の原因と認定されたケースがあります。たとえば、仕様確定後に大量の追加要望を出し続けたことが発注者の協力義務違反にあたると判断された事例（旭川医大対NTT東日本事件）も存在します（参考: ユーザの協力義務違反に当たるとした札幌高裁判決について（イノベンティア））。
「発注したのだから、あとは開発会社の責任」という考え方は、法的にも実務的にも通用しません。プロジェクトの成功は、発注者と開発会社の協働があってこそ成り立つものだと理解しておくことが、失敗回避の第一歩になります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
発注者がPMとの連携で確認すべきポイント
発注者側にも関与が必要だと分かっても、「専門知識がない自分に何ができるのか」と不安に感じるかもしれません。心配は要りません。発注者に求められるのは技術的な判断ではなく、「自社にとっての正解を決めること」と「異変に早く気づくこと」です。ここでは、開発会社のPMと協働する際の実務ポイントを具体的に整理します。
定例会・進捗報告で確認すべき項目
多くのプロジェクトでは、週次や隔週で定例会が開かれ、PMから進捗が報告されます。専門用語が飛び交って圧倒されがちですが、発注者として最低限おさえたいのは次の5点です。
確認項目 | 見るべきポイント |
|---|---|
進捗 | 計画に対して予定通り進んでいるか。遅れがあるなら、その原因と挽回策は示されているか |
課題 | 現在抱えている問題は何か。誰が、いつまでに対応するのか |
リスク | 今後つまずきそうな箇所はどこか。先回りの対策はあるか |
スケジュール変更 | 納期に影響する変更はないか。あるなら理由と影響範囲は妥当か |
コスト | 予算の消化状況は計画通りか。追加費用が発生しそうな兆候はないか |
ポイントは、「順調です」という報告を鵜呑みにせず、「課題はないか」「想定通りか」を自分から確認する姿勢です。問題は早く把握できればできるほど、軌道修正が容易になります。報告内容が曖昧だったり、毎回「特に問題ありません」で終わったりする場合は、むしろ注意が必要なサインかもしれません。
発注者が判断・承認を担う場面とスピードの重要性
プロジェクトの中で、発注者にしか決められないことがあります。
- 機能の仕様や優先順位の決定
- 設計内容・画面イメージの承認
- 仕様変更の可否判断
- 社内の関係部署との調整・合意形成
これらの判断において、見落とされがちですが決定的に重要なのが「スピード」です。開発はチームで動いているため、発注者の回答待ちで作業が止まると、その間ずっと工数（＝コスト）が空費されます。回答が遅れれば遅れるほど、納期の遅延や追加費用に直結します。
すべてを発注者一人で即断する必要はありませんが、「いつまでに、誰が、どう決めるか」という社内の意思決定の流れをあらかじめ整理しておくことが、結果的にプロジェクトをスムーズに進める鍵になります。開発会社から確認が来てから社内調整を始めるのではなく、確認が来ることを見越して準備しておく——この姿勢こそが、発注者側PMに求められる実務です。
優れたPMがいる開発会社を見極めるには
ここまで読んで、「PMの質が高い開発会社を選びたい」と感じた方も多いはずです。プロジェクトの成否はPMの力量に大きく左右されます。では、発注前にPMの質をどう見極めればよいのでしょうか。
発注前にPMの質を見極める観点
契約前の提案・商談の段階でも、PMやチームの質を推し量る手がかりはあります。次の観点で確認してみてください。
- 体制の説明が具体的か: 「誰が、どの役割で、どう関わるのか」を明確に説明できるか。役割分担が曖昧な会社は、プロジェクト管理も曖昧になりがちです。
- こちらの課題を言語化してくれるか: こちらが漠然と伝えた要望を、整理して言い換え、本質的な課題を引き出してくれるか。これはPMの重要なスキルである「要件を引き出す力」の表れです。
- コミュニケーションが誠実か: 都合の悪いことやリスクも正直に伝えてくれるか。「何でもできます」とだけ答える相手より、できないことや懸念を明示してくれる相手の方が信頼できます。
- 発注者の関与の必要性を説明してくれるか: 「お任せください」だけでなく、「御社にはこの場面で判断をお願いします」と協働の前提を示してくれるか。
これらは専門知識がなくても、提案時のやり取りから十分に感じ取れる観点です。
発注者と伴走する開発会社の特徴
優れた開発会社は、発注者を「丸投げの相手」ではなく「一緒にプロジェクトを進めるパートナー」として扱います。前述の通り、発注者の主体的な関与なしにシステム開発は成功しません。それを理解している会社は、発注者が判断しやすいように情報を整理して提示し、専門知識がなくても意思決定に参加できるよう支援します。
秋霜堂株式会社では、Web開発・業務システム開発において、発注者と開発会社が同じゴールに向かって協働できるよう、要件の整理段階から伴走することを大切にしています。発注者の業務や狙いを丁寧にヒアリングし、専門用語に頼らず判断材料を提示することで、初めて開発を外注する企業でも安心してプロジェクトを進められる体制を整えています。
開発会社を選ぶ際は、技術力や費用だけでなく、「この会社のPMとなら、二人三脚でプロジェクトを進められそうか」という視点を持つことをおすすめします。
プロジェクトマネージャーに関するよくある質問
最後に、発注者からよく寄せられる質問に答えます。
PMとPMOはどちらを置くべきですか？
まずPMは、ほぼすべてのプロジェクトに必要です。PMがいなければ、プロジェクトの統括や意思決定を担う責任者が不在になってしまうためです。一方PMOは、PMを支援する役割であり、複数のプロジェクトが同時進行する場合や、関係者が多く調整が複雑な大規模プロジェクトで効果を発揮します。小〜中規模の開発であれば、PMがPMOの役割も兼ねるのが一般的で、PMOを別途置く必要はないことが多いです。
小規模な開発でもPMは必要ですか？
必要です。規模が小さくても、計画・進捗・品質・コストを管理する役割は欠かせません。ただし小規模の場合は、PMが専任ではなく、PLやエンジニアがPMを兼任することがよくあります。重要なのは「PMという肩書きの人がいるか」ではなく、「プロジェクト全体を見て判断・調整する機能が存在するか」です。発注者側でも、規模に関わらず社内の意思決定をまとめる窓口担当を一人決めておくことをおすすめします。
発注者側に専門知識がなくてもPMの役割は果たせますか？
果たせます。発注者側に求められるのは、技術的な判断ではなく「自社にとって何が正解かを決めること」と「社内の意見を取りまとめて期限内に回答すること」です。これらは自社の業務に詳しい発注者だからこそできる役割であり、技術の専門知識は必須ではありません。むしろ、分からないことを開発会社のPMに率直に質問し、納得できるまで確認する姿勢の方が大切です。誠実な開発会社であれば、専門知識のない発注者でも判断できるよう、分かりやすく情報を提示してくれます。
まとめ
プロジェクトマネージャー（PM）とは、システム開発のQCD（品質・コスト・納期）を統括し、プロジェクトを成功に導く責任者です。外注の場合、PMは開発会社側に置かれ、発注者にとっては開発のやり取りの主な相手になります。
しかし、開発会社にPMがいるからといって「あとは任せておけば安心」とはなりません。開発会社のPMが担えるのは「どう作るか」であり、「自社にとって何が正解か」を決められるのは発注者だけです。要件を明確に伝え、判断を期限内に返し、社内の意見を取りまとめる——こうした発注者側の主体的な関与があってこそ、プロジェクトは前に進みます。これは法的な協力義務としても認められている考え方です。
「丸投げ」を避け、開発会社のPMと二人三脚で進めること。そして、発注前にはPMやチームの質を見極め、発注者と伴走してくれる会社を選ぶこと。この2つが、初めてのシステム開発を成功させる最も確実な道筋です。本記事で整理した役割分担の考え方を手がかりに、自社の関わり方を具体的に描いてみてください。
参考・出典
- システム開発のプロジェクトマネジメント義務と協力義務（弁護士法人クラフトマン）
- 「ベンダー任せ」が招く経営危機 ユーザー企業の協力義務とは（PwC）
- ユーザの協力義務違反に当たるとした札幌高裁判決（旭川医大対NTT東日本事件）について（イノベンティア）
- システム開発を外注先に丸投げは危険！発注者が果たすべき責任とは？（Rabiloo）
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
