公開2026.07.25更新2026.09.27 DX

システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】

システム開発のプロジェクト管理とは、限られた予算・人員・納期のなかで開発の目標を達成するため、計画から実行・監視・完了までを統制する取り組みです。この記事では、品質・コスト・納期（QCD）を軸にした管理の全体像、ウォーターフォールとアジャイルで異なる工程・進捗の管理、WBSとEVMで遅れを数値で判定する手順、品質・課題・リスク・変更という4つの管理領域、そして受託開発で成否を分ける発注者と開発ベンダの役割分担までを実務目線で整理します。開発を外注する事業会社の担当者が、案件を破綻させないために自社が何を管理し何をベンダに任せるべきかを判断できる状態を目指します。

まとめ：システム開発のプロジェクト管理の進め方と発注側の要点

システム開発のプロジェクト管理は、QCD（品質・コスト・納期）の3つを同時に守る意思決定の連続です。要件が固まりきらないまま走り出し、無形の成果物が完成間際まで見えないという特性があるため、工程を区切って進捗と品質を早期に可視化する設計が成否を分けます。管理対象は進捗・品質・課題・リスク・変更・コミュニケーションに整理でき、どれか1つが崩れると納期遅延やコスト超過へ連鎖します。

進捗は「予定より遅れている気がする」では管理できません。WBSで作業を数日単位に割り、EVMでSPI（スケジュール効率）とCPI（コスト効率）を週次で出せば、遅れと超過を数字で把握できます。

受託開発では、この管理を発注者と開発ベンダで分担します。要件の確定・意思決定・受入検査は発注者の責任、進行・品質作り込み・報告はベンダの責任という線引きが基本で、IPAのモデル契約もベンダのプロジェクトマネジメント義務とユーザの協力義務を条項で分けています。丸投げや意思決定の遅延は、ベンダのPMがどれだけ優秀でも埋められない失敗の典型です。社内にPMを置けない場合は、PMO支援を含めて外部に委ねる判断が現実的になります。

システム開発のプロジェクト管理の定義とQCD・PMの役割の全体像

最初に「何を管理する営みなのか」を定義します。ここが曖昧なままツール選定に入ると、進捗表を作ること自体が目的化し、肝心の意思決定が遅れます。

QCDの達成を統制するシステム開発のプロジェクト管理の定義と範囲

システム開発のプロジェクト管理とは、決められたゴール（動くシステムの完成と稼働）へ向けて、品質・コスト・納期の3条件を満たしながら開発を統制する営みです。この3条件はQCDと呼ばれ、片方を優先すると他方が犠牲になるトレードオフの関係にあります。納期を詰めれば品質検証の時間が削られ、品質を上げれば工数（コスト）が膨らむという具合です。プロジェクト管理の本質は、この3つの綱引きを毎日の判断でバランスさせ続けることにあります。管理範囲は着手前の計画立案から、実行中の進捗・品質の監視、完了時の受入・引き渡しまでの全期間に及びます。

計画から実行・監視まで担うプロジェクトマネージャーの管理範囲

この統制を担う役割がプロジェクトマネージャー（PM）です。PMはスケジュールとタスクを設計し、メンバーへ作業を割り当て、進捗と品質を監視し、発生した課題やリスクをさばきます。国際的な知識体系であるPMBOKガイド（PMI）は、第6版までスコープ・スケジュール・コスト・品質・資源・コミュニケーション・リスク・調達・ステークホルダー・統合の10知識エリアで管理対象を整理していました。第7版で原則とパフォーマンス・ドメイン中心の構成へ移り、2025年11月公開の第8版ではプロセスの整理が再び加わっています（2026年9月時点）。版が変わっても、すべてを同じ濃度で管理しなくてよい点は共通です。案件の性質に応じて、崩れやすい領域へ管理の重心を寄せる判断がPMの腕になります。開発規模が小さい案件では、開発リーダーがPMを兼務する体制も一般的です。

システム開発特有の要件の不確実性と無形の成果物が生む管理の難しさ

システム開発のプロジェクト管理が、建設や製造の管理と決定的に違う点が2つあります。1つは要件の不確実性です。着手時点で仕様が完全に固まることはまれで、開発の途中で「思っていた業務と違う」という食い違いが表面化します。もう1つは成果物が無形である点です。建物なら現地を見れば進捗が分かりますが、ソフトウェアは動かして初めて実態が見えるため、完成間際まで遅れや品質問題が隠れやすい構造を持ちます。この2つが、後述する工程の区切りと早期の可視化を必要にする根本の理由です。QCDのうちコスト（工数）の見える化については、工数の記録と案件別採算の仕組みを整理した工数管理システムとは？工数の単位・機能・勤怠管理との違いと選び方を解説もあわせて参照してください。

ウォーターフォールとアジャイルで異なる工程・進捗管理の進め方

進捗の管理方法は、採用する開発手法によって形が変わります。手法を取り違えたまま管理の型だけ真似ると、現場と管理がかみ合いません。

ウォーターフォール開発で工程ごとに区切る進捗と品質の管理方法

ウォーターフォール開発は、要件定義・基本設計・詳細設計・実装・テスト・リリースの各工程を上流から順に完了させて進める手法です。工程の切れ目に「前工程の成果物が基準を満たしたか」を確認するレビューを置き、合格してから次へ進みます。プロジェクト管理の観点では、各工程の開始・終了日と成果物（ドキュメント・プログラム）を基準に進捗を測るため、計画と実績のズレを工程単位で把握しやすいのが持ち味です。一方で、後工程になるほど前工程への手戻りコストが跳ね上がるため、要件定義と設計の品質をレビューで作り込む設計が生命線になります。工程ごとの成果物と工数比率はシステム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説で、最上流の進め方は要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説で詳しく扱っています。要件が比較的固まっている業務システムの受託開発では、いまも主流の進め方です。

アジャイル・スクラムで短い反復を回しながら進める進捗管理の違い

アジャイル、なかでもスクラムは、短い反復（スプリント）を繰り返し、動くソフトウェアを小刻みに作りながら進める手法です。スクラムガイド（2020年11月版）は、スプリントを1か月以内の固定期間と定め、プロダクトオーナー・スクラムマスター・開発者の3つの責任と、プロダクトゴール・スプリントゴール・完成の定義という3つの確約を置いています。進捗はドキュメントの完成度ではなく「完成の定義を満たした機能がいくつ積み上がったか」で測ります。要件の不確実性が高く、作りながら仕様を確かめたい新規事業やプロダクト開発と相性が良い進め方です。管理の勘所は、スプリントごとに優先順位を見直し、完成した機能を発注者が毎回確認する点にあります。手戻りを小さく早く回収できる反面、全体の完成時期と総コストが読みにくく、発注者が継続して関与することが前提条件です。どちらの手法が向くかを含めた比較はプロジェクト管理の手法とは？主要7手法の比較と選び方【2026年版】で詳しく整理しています。

WBSとガントチャートで進捗の遅れを早期に検知する管理の仕組み

手法を問わず進捗管理の土台になるのがWBSとガントチャートです。WBS（作業分解構成図）は、成果物を作るために必要な作業を漏れなく細かく分解した一覧で、見積もりと担当割り当ての基礎になります。分解の手順と具体例はWBSとは？作り方5ステップとガントチャートとの違いを具体例で解説にまとめています。分解した作業を時間軸に並べ、依存関係と担当を可視化したものがガントチャートです。ガントやダッシュボードでの進捗の見える化と会議の運用はプロジェクト進捗管理とは？遅延を防ぐ見える化の方法と会議運用の実務で詳しく扱っています。プロジェクト管理では、この計画線に対する実績を定期的に更新し、遅れている作業を早い段階で見つけて手を打ちます。遅れの検知が締め切り直前になるほど選べる対策は減るため、日次または週次での更新頻度を最初に決めておく運用が有効です。作業を細かく割ると更新が負担になり、粗く割ると遅れが見えません。1タスクが数日で終わる粒度に揃えるのが実務的な落としどころです。

EVMの計算でSPIとCPIを出し遅延とコスト超過を数値で判定する手順

ガントの線だけでは「どれだけ遅れているか」を比べられません。そこで使うのがEVM（アーンド・バリュー・マネジメント）です。WBSの各タスクに計画工数を割り当て、基準日時点の計画価値（PV）・出来高（EV）・実績コスト（AC）の3つを出します。SPI＝EV÷PV、CPI＝EV÷ACで、どちらも1を下回れば遅れ・超過を意味します。次のPythonはWBSの表をそのまま入れて計算する例で、標準ライブラリだけで実行可能です。

# WBSのタスクごとに(タスク名, 計画工数[人日], 予定進捗率, 実績進捗率, 実績工数[人日])を入れる
tasks = [
    ("画面設計", 10, 1.0, 1.0, 12),
    ("API実装", 20, 0.6, 0.4, 9),
    ("結合テスト", 15, 0.0, 0.0, 0),
]
bac = sum(t[1] for t in tasks)          # 完成時総予算
pv = sum(t[1] * t[2] for t in tasks)    # 計画価値
ev = sum(t[1] * t[3] for t in tasks)    # 出来高
ac = sum(t[4] for t in tasks)           # 実績コスト
spi = ev / pv
cpi = ev / ac
eac = bac / cpi                        # 今の効率が続いた場合の完成時見積もり
print(f"PV={pv:.1f} EV={ev:.1f} AC={ac:.1f}")
print(f"SPI={spi:.2f} CPI={cpi:.2f} EAC={eac:.1f}人日 (BAC={bac}人日)")

実行すると「SPI=0.82 CPI=0.86 EAC=52.5人日 (BAC=45人日)」と出ます。計画45人日の案件が、このままだと約7.5人日の超過で着地する見込みだという読み方です。SPIが0.9を下回ったら定例で原因と挽回策を確認する、といった閾値を着手前に発注者と決めておくと、報告が感想でなく数字になります。

品質・課題・リスク・変更を統制する4つの管理領域と実務の勘所

進捗管理と並行して、品質・課題・リスク・変更の4領域を回します。この4つは相互に連鎖するため、どれか1つを軽視すると他へ波及します。

各工程のレビューとテストで品質を作り込む品質管理と品質指標の見方

品質管理は、完成後の検査で不良を弾く発想ではなく、各工程で不良を作り込ませない発想で設計します。上流では設計レビューで仕様の抜け漏れをつぶし、下流では単体テスト・結合テスト・システムテスト・受入テストと段階を踏んで検証する流れです。テスト工程の種類とV字モデルの対応はシステム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸で整理しています。管理指標としては、テスト項目数に対する消化率、検出したバグの件数と修正状況、レビューで指摘した密度などを追い、想定より極端に少ない・多い数値の背後にある原因を見に行きます。バグ件数がゼロに近いテスト工程は、品質が高いのではなくテストが甘い可能性を疑うのが実務の目線です。品質は納期・コストと綱引きになるため、どこまで検証すれば出荷可能とみなすかの基準を、発注者とベンダで着手前に合意しておきます。

課題管理表で担当と期限を決め放置を防ぐエスカレーションの運用

開発中は、仕様の確認待ち・環境の不具合・他システムとの調整など、その場で解決できない事項が日々発生します。これらを課題として一覧化し、内容・担当者・期限・状態を記録して追跡するのが課題管理です。課題管理表を運用する狙いは、担当と期限を明示して「誰かがやるだろう」という放置を防ぐことにあります。運用のコツは、期限を過ぎた課題や現場で判断できない課題を上位の意思決定者へ上げるエスカレーションの経路を、あらかじめ決めておく点です。発注者の回答待ちで止まる課題は、ベンダ側だけでは解消できません。定例会議で未解決の課題を発注者に示し、意思決定を促す運用がプロジェクトを止めない条件になります。

品質・納期・技術・要員の4分類で先手を打つリスク管理の進め方

リスク管理は、まだ起きていないが起きればQCDを脅かす事象を先回りで洗い出し、対策を準備する活動です。システム開発で発生頻度が高いリスクは、品質・納期・技術・要員（コミュニケーション含む）の4系統に大別できます。洗い出した各リスクは、発生確率と影響度の2軸で評価し、両方が高いものから対策を講じます。

リスク分類	典型例	先手の対策
品質リスク	要件の認識ずれ	設計レビューで早期確認
納期リスク	仕様変更の頻発	変更管理の手順を明確化
技術リスク	未経験技術の採用	試作で実現性を先に検証
要員リスク	主要人員の離脱	属人化を避け情報を共有

対策には、発生を防ぐ回避策と、発生後の被害を抑える軽減策の両面を用意します。特に、まだ使ったことのない技術を採用する案件では、本格開発の前に小さな試作で実現性を確かめるプロトタイピングが、後戻りできない段階での破綻を防ぐ効果を持ちます。

仕様変更の影響を見積もりスコープを管理する変更管理の判断手順

開発が進むと、発注者から仕様変更の要望が出ます。変更管理とは、この要望を無条件に受け入れるのでも門前払いするのでもなく、影響を見積もったうえで採否を判断する仕組みです。変更依頼を受けたら、追加で必要な工数・コスト・納期への影響を算定し、その結果を発注者に提示して、費用と納期を再合意したうえで着手します。この手順を飛ばして現場判断で変更を飲み込むと、スコープが少しずつ膨らむスコープクリープが起き、当初の見積もりのまま納期とコストだけが崩れます。前章のEVMで出したEACを変更の前後で比べれば、影響の大きさを発注者に数字で提示することが可能です。変更は悪ではありません。影響を見える化し、対価と納期をその都度精算する規律こそが、変更管理の核心です。

受託開発の成否を左右する発注者と開発ベンダの役割分担と責任範囲

ここまでの管理を、受託開発では発注者と開発ベンダで分担します。この線引きが曖昧な案件は、管理手法が優れていても破綻しがちです。ここは判断を明確にしておきます。

要件確定・意思決定・受入検査まで担う発注者側の責任と関与の範囲

外注する側にも、外注できない責任が残ります。発注者が担うのは、業務要件を確定させること、開発中に上がってくる仕様確認や課題に期限内で意思決定を返すこと、そして納品物が要件を満たすかを受入検査で判定することです。とりわけ意思決定のスピードは、発注者にしか動かせない領域です。ベンダは業務の当事者ではないため、どの業務ルールを正とするかを最終的に決められるのは発注者だけになります。要件定義の工程に業務を知る担当者を出せるか、開発期間中に確認へ即応できる体制を組めるかが、外注案件の質を左右します。

進行・品質・報告・課題対応に責任を持つ開発ベンダ側の役割分担

開発ベンダ側は、確定した要件をもとに設計・実装・テストを進行させ、成果物の品質を作り込み、進捗と課題を定期的に報告する責任を負います。優れたベンダのPMは、進捗を数字で正直に報告し、遅れやリスクの兆候を早い段階で発注者に共有します。逆に、遅れを隠して終盤で一気に噴出させる報告は、発注者が打てる手を奪う最悪のパターンです。発注者はベンダを選ぶ段階で、定例報告の頻度・形式と、課題やリスクをどう可視化して共有するかを確認しておくと、進行中の見通しが安定します。報告の質は、契約前に過去案件の進め方を具体的に聞くことである程度見極められます。

IPAモデル契約で見る請負・準委任とプロジェクトマネジメント義務

役割分担は口約束ではなく契約で固めます。雛形として参照されるのが、IPAの情報システム・モデル取引・契約書（第二版）です。2020年12月22日に公開され、2020年4月施行の改正民法に合わせた契約不適合責任の見直しに加えて、ベンダのプロジェクトマネジメント義務とユーザの協力義務の明確化が改訂論点に挙がっています。要件定義は準委任、設計から実装・テストは請負、というように工程ごとに契約類型を分ける多段階契約の考え方も、この雛形の前提です。アジャイルで進める場合は、同じくIPAの情報システム・モデル取引・契約書（アジャイル開発版）が準委任を前提にした条項と解説を出しています。契約書で「誰が何をいつまでに決めるか」を書き、定例の議事録で守られているかを確かめる運用が、責任の押し付け合いを防ぎます。

丸投げと意思決定の遅延が招く受託開発でありがちな失敗パターン

失敗する受託案件には共通の型があります。最も多いのが、発注者が「専門家に任せた」として要件確定と意思決定を放棄する丸投げです。要件が曖昧なまま開発が進み、完成物を見て初めて「これではない」となり、大規模な手戻りが発生します。次に多いのが意思決定の遅延で、ベンダからの確認が発注者側で滞留し、待ち時間の分だけ納期が押します。ここははっきり言い切れる論点です。プロジェクト管理ツールを入れても、報告を密にしても、発注者が要件を決めきれず意思決定を返さない案件は成功しません。管理手法の巧拙以前に、発注者が当事者として関与する体制を組めるかが、外注の成否を最初に決めます。関与できる体制を用意できないなら、要件定義から伴走する支援者を立てる前提で進めるべきです。

プロジェクト管理ツールの選定と内製PMか外部委託かの判断基準

最後に、管理の道具立てと体制の判断に落とします。ツールも体制も、自社の案件規模と社内リソースから逆算して選びます。

課題管理・工数・ガントで選ぶプロジェクト管理ツールの選定観点

プロジェクト管理ツールは、課題管理・進捗の可視化（ガントやカンバン）・工数記録・情報共有を1か所に集約する道具です。選ぶ際は、自社案件で崩れやすい領域が厚い製品を選ぶのが基本になります。課題の放置が問題なら課題管理と通知が強い製品、採算把握が課題なら工数集計が細かい製品、というように重心で選び分けます。EVMまで回したいなら、タスクごとの計画工数と実績工数を両方記録できるかも確認点です。多機能な製品ほど入力項目が増え、現場が入力しなければ形だけの導入に終わる点は共通の注意です。機能・種類・既製と自作の判断軸はプロジェクト管理ツールとは？機能・種類・選び方と既製か自作かの判断軸を解説で整理しているので、製品選定の前段に確認してください。無料トライアルを実際の案件で試し、入力から報告までの手数を確かめてから本採用に進む流れが堅実です。

内製でPMを立てるか開発ベンダにPMごと委託するかの判断基準

体制の判断は、社内にプロジェクトを管理できる人材がいるかで分かれます。業務要件を理解し、ベンダと対等に進捗・品質を管理できるPMを社内に置けるなら、内製PMがベンダを統制する体制が主導権を保ちやすい形です。一方、管理を担える人材がいない、または担当者が本来業務と兼務で工数を割けない場合は、発注側に立って要件整理と進行管理を支える外部のPMOを入れる判断が現実的になります。当社（株式会社一創）の要件定義・RFP作成・PMO支援では、要件の整理とRFPの作成からベンダ選定、開発中の進捗・課題の管理までを発注者側で支援しています。判断の分かれ目は、社内のPMが割ける工数と、扱う技術・業務の難度です。難度が高く社内工数も薄いなら、無理に内製せず外部の支援を前提に、報告と課題共有の質でベンダを選ぶ順番が失敗を減らします。逆に、社内に経験者がいて案件が小規模なら、外部PMOは過剰です。

よくある質問

システム開発のプロジェクト管理を検討する際に、発注側から寄せられることの多い質問へ、本文の要点を踏まえて簡潔に回答します。

システム開発のプロジェクト管理とは何を管理することですか？

品質・コスト・納期（QCD）を満たしながら開発を完了させるために、進捗・品質・課題・リスク・変更・コミュニケーションを統制することです。無形の成果物と不確実な要件という特性上、工程を区切って進捗と品質を早期に見える化し、日々の判断でQCDのバランスを取り続ける営みだと捉えると実態に近くなります。

ウォーターフォールとアジャイルはどちらを選ぶべきですか？

要件の固まり具合で選ぶのが基本です。業務要件がある程度確定していて、工程ごとに成果物を検収したい業務システムの受託開発はウォーターフォールが向きます。要件が流動的で、作りながら仕様を確かめたい新規プロダクトはアジャイルが向きます。ただしアジャイルは発注者の継続的な関与が前提のため、社内体制と合わせて判断してください。

進捗の遅れはどうやって数字で把握すればよいですか？

WBSで作業を数日単位に分け、タスクごとに計画工数を置いたうえで、EVMのSPI（出来高÷計画価値）とCPI（出来高÷実績コスト）を週次で出す方法が扱いやすい手段です。どちらも1を下回れば遅れ・超過を示します。閾値と報告の頻度を着手前に発注者とベンダで合意しておくと、定例の議論が数字に基づくものになります。

発注側が最低限やるべき管理は何ですか？

要件を確定させること、開発中の確認や課題に期限内で意思決定を返すこと、納品物を受入検査で判定することの3つです。この3つは外注できません。特に意思決定の遅延は納期遅延へ直結するため、確認へ即応できる担当と体制を、着手前に用意しておくことが案件を止めない条件になります。ツールを入れても、この3つを返さない案件は成功しません。

社内にPM経験者がいなくても開発を発注できますか？

発注できます。要件定義から進行管理までをPM込みで請け負えるベンダに委託するか、発注側に立つPMO支援を入れれば、社内に専任PMがいなくても開発は進みます。その場合でも、業務要件の確定と意思決定は発注者の責任として残るため、業務を知る担当者を要件定義に出せる体制は必要です。契約時には、IPAのモデル契約を参考に双方の義務を条項で確認しておくと安心です。