システム開発の案件管理｜要件から納品までの流れ

2026年1月31日

＠SOHO編集部

この記事のポイント

✓システム開発の案件管理を
✓納品までの流れに沿って解説
✓工程ごとに管理すること

システム開発の案件管理は、要件定義から納品までの長い道のりの中で、「今どこまで進んでいて、何が決まっていて、何が問題なのか」を発注する側と開発する側の両方が同じ理解で持ち続けるための仕事です。管理が崩れると、納期の遅れ、追加費用の行き違い、「言った言わない」の争いが起きやすくなります。

この記事では、システム開発の案件管理を、要件から納品までの工程の流れに沿って整理します。工程ごとに何を決め、何を記録すればよいか、契約の形によって管理がどう変わるか、変更や課題をどう扱うかを、独立行政法人情報処理推進機構（IPA）が公開している資料を手がかりに解説します。作業の担当と期限と進み具合を共有する道具の1つとして、ガントチャートやカンバンのボードを持つPinatecaにも触れます。

システム開発の案件管理とは

システム開発の案件管理とは、1つの開発案件について、範囲（何を作るか）、日程（いつまでに作るか）、費用（いくらで作るか）、品質（どの水準で作るか）を、最初に決めた計画と照らし合わせながら進める仕事です。一般には「プロジェクト管理」と呼ばれることも多く、2つの言葉はほぼ同じ意味で使われます。違いを挙げるなら、案件管理は「受注した1件1件の仕事」を単位に、契約や請求まで含めて追う場面で使われやすい言葉です。

システム開発の案件管理が他の仕事より難しいのは、次の3つの理由があるからです。

作るものが目に見えにくい。完成するまで、発注する側が中身を確かめにくい
途中で要望が変わりやすい。業務を見直すうちに、新しい要望や変更が出てくる
関わる人が多い。発注する会社の業務部門、情報システム部門、開発会社、その下請けや業務委託の技術者が関わる

この3つが重なると、同じ言葉でも人によって違うものを思い浮かべるようになります。案件管理の役目は、決まったことと決まっていないことを記録に残し、関わる人全員が同じ理解に立てるようにすることです。

要件から納品までの工程の流れ

システム開発の進め方には、最初に全体の要件を決めてから順番に作っていくウォーターフォール型と、小さな単位で作って確かめることを繰り返すアジャイル型があります。まずは、工程の区切りが分かりやすいウォーターフォール型の流れで、全体像を押さえます。

工程	すること	主な成果物
企画	開発の目的、範囲、予算、期間の大枠を決める	企画書、提案依頼書（RFP）
要件定義	業務の流れと、システムに求める機能と性能を決める	要件定義書
基本設計	画面、帳票、データ、外部とのつなぎ方など、利用者から見える部分を設計する	基本設計書
詳細設計	プログラムの作りなど、開発者から見た内部の設計をする	詳細設計書
実装	プログラムを作る	ソースコード
テスト	部品ごと、つないだ状態、システム全体の順に動作を確かめる	テスト計画書、テスト結果報告書
受入テスト・検収	発注する側が、求めたとおりに動くかを確かめて受け取る	検収書
納品・運用開始	本番の環境で使い始める	運用手順書、引き継ぎ資料

工程の名前や区切り方は会社によって少しずつ違いますが、「決める、設計する、作る、確かめる、受け取る」の順番はどの開発でも共通です。案件管理では、この工程のそれぞれに「終わったと言える条件」を決めておくことが出発点になります。

要件定義で管理すること

要件定義は、システム開発の案件管理で最も大切な工程です。ここで決めたことが、後の工程すべての基準になるからです。要件定義で管理するのは、主に次の4つです。

機能の要件。システムで何ができるようにするか
機能以外の要件。応答の速さ、同時に使う人数、セキュリティ、停止してよい時間など
範囲の外のこと。今回は作らないものをはっきり書く
決まっていないこと。持ち越した論点と、いつまでに誰が決めるか

特に「範囲の外のこと」と「決まっていないこと」を書き残しておくのが、後の争いを防ぐ鍵です。要件定義書に書かれていない機能を後から求められたとき、それが最初から範囲の外だったのか、単に書き漏れていたのかで、追加費用の扱いが変わります。

設計の工程で管理すること

基本設計では、画面の一覧、帳票の一覧、データの項目、ほかのシステムとのつなぎ方を決めます。発注する側が中身を確かめられる最後の機会なので、画面の見た目や操作の流れを、紙やデモで確かめてもらう場を設けます。詳細設計は開発する側の内部の作業ですが、設計の途中で要件のあいまいさに気づくことがよくあります。そうした疑問は課題として記録し、発注する側に確かめます。

実装とテストで管理すること

実装の工程では、機能ごとの作業の進み具合を追います。ここで役立つのが、作業を細かく分けた一覧と、作業の期間を横棒で並べるガントチャートです。テストの工程では、テストの項目数、終わった数、見つかった不具合の数と直した数を追います。不具合が見つかり続けて減らない場合は、設計や要件に問題が残っている可能性があるので、工程を戻して原因を確かめます。

受入テストと検収で管理すること

受入テストは、発注する側が自分たちの業務で使えるかを確かめる工程です。検収は、発注する側が成果物を受け取ったことを正式に認める手続きで、多くの契約では検収をもって代金の支払いが決まります。受入テストの基準と、検収の期限を契約や計画で決めておかないと、「確かめているうちに期限が過ぎた」「どこまで直せば検収なのか分からない」という状態になります。

工程ごとの「終わった」の条件の例

工程の区切りで「終わった」と言える条件を、先に決めておく例を挙げます。条件は案件ごとに調整しますが、何も決めずに進めるより、たたき台があるほうが話し合いが早く進みます。

工程	終わったと言える条件の例
要件定義	要件定義書を発注する側の責任者が確認し、未決の課題に期限と担当が付いている
基本設計	画面と帳票の一覧と見た目を発注する側が確認し、変更の要求が整理されている
詳細設計	開発する側の内部で設計を確かめ、実装の作業の一覧ができている
実装	予定した機能のプログラムができ、部品ごとのテストが終わっている
テスト	予定したテストの項目がすべて終わり、重い不具合が残っていない
受入テスト	発注する側が業務の流れに沿って確かめ、検収の判断をした

条件を決めておくと、工程の終わりに「本当に次に進んでよいか」を判断できます。条件を満たさないまま次の工程に進むと、問題を後ろへ送るだけになり、後の工程で直すほど手間と費用が大きくなります。

契約の形で変わる管理の考え方

システム開発の案件管理は、契約の形によって管理の重点が変わります。代表的な契約の形は、請負と準委任の2つです。

契約の形	対価を払う対象	管理の重点
請負	完成した成果物	範囲と完成の基準、検収
準委任	専門家として業務を行うこと	作業の内容と時間、報告

請負は、決められたものを完成させることに対して代金を払う契約です。完成させる責任は開発する側にあるので、範囲と完成の基準を最初に細かく決めることが管理の中心になります。準委任は、専門家として業務を行うことに対して代金を払う契約で、完成そのものを約束するものではありません。作業の内容と時間を記録し、定期的に報告することが管理の中心になります。

IPAは、システム開発の契約のひな型と解説を「情報システム・モデル取引・契約書」として公開しています。アジャイル開発を外部に委託する場合の版について、IPAは次のように説明しています。

本版は、あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としています。出典: IPA「情報システム・モデル取引・契約書（アジャイル開発版）」

一方、ウォーターフォール型の開発については、IPAの「情報システム・モデル取引・契約書（第二版）」が、プロジェクトマネジメント義務及び協力義務、システム開発における複数契約の関係などの論点を整理しています。工程ごとに契約を分け、要件定義のように内容が固まっていない工程と、設計後の作る工程とで契約の形を使い分ける考え方は、案件管理の上でも役に立ちます。工程ごとに契約を区切れば、前の工程の成果を確かめてから次の工程の範囲と費用を決められるからです。

契約の細かな判断は案件ごとの事情で変わるので、実際に契約を結ぶときは、ひな型をそのまま使うのではなく、法務の担当者や専門家に相談しながら内容を決めます。

ウォーターフォールとアジャイルで変わる管理

ウォーターフォール型とアジャイル型では、案件管理で追うものが違います。

ウォーターフォール型では、最初に決めた計画との差を追います。工程ごとの開始日と終了日、作業ごとの予定と実績を比べ、遅れが出たら原因を確かめて手を打ちます。計画書に書いた日程と実際の進み具合を定期的に比べることが、遅れに早く気づく基本です。

アジャイル型では、短い期間（多くは1週間から4週間）を区切りに、その期間で作る機能を決め、作って確かめることを繰り返します。IPAのアジャイル開発版はスクラム（短い期間を区切って、計画、開発、確認、振り返りを繰り返す進め方）を採用しています。管理で追うのは、残っている作業の一覧と、期間ごとにどれだけ進んだかです。最初の計画との差よりも、次の期間で何を優先するかを、発注する側と開発する側が一緒に決め続けることが重視されます。

どちらの進め方でも共通するのは、作業の一覧と、その担当、期限、状態を、関わる人全員が見られる場所に保存しておくことです。進め方の違いは、その一覧をどの単位で区切り、どの間隔で見直すかの違いだと考えると整理しやすくなります。

案件管理で記録しておく5つのもの

システム開発の案件管理で、工程を問わず記録しておくべきものは次の5つです。

1. 作業の一覧

作業を、1人が数日で終えられる大きさまで分けて一覧にします。作業を階層に分けて一覧にしたものは、WBS（作業分解構成図）と呼ばれます。作業ごとに担当、開始日、期限、状態を付けておくと、ガントチャートやカンバンで全体の進み具合が見えるようになります。

2. 課題

「この画面の項目は何文字までにするか」「既存のシステムのデータをどこまで移すか」のように、作業の途中で出てきた未解決の論点です。課題ごとに、誰が、いつまでに答えるかを決めます。課題が答えられないまま残ると、その先の作業が止まります。

3. 変更の要求

要件定義の後に出てきた、範囲や内容の変更の要望です。変更の要求は、受け付けた日、内容、影響（日程と費用と品質への影響）、判断の結果を記録します。変更を受けるかどうかは、影響を見積もってから、発注する側と開発する側の決める権限を持つ人が判断します。

4. リスク

まだ起きていないが、起きると案件に影響する出来事です。「担当の技術者が1人しかいない」「外部のシステムとのつなぎ込みの仕様が未確定」などを、起きる可能性と影響の大きさとともに記録し、起きたときの手を先に考えておきます。

5. 決まったことの記録

会議で決まったことを、日付と決めた人とともに残します。議事録の全文よりも、「何が決まったか」を1行ずつ残す一覧のほうが、後から探すときに役立ちます。

変更管理と追加費用の扱い

システム開発の案件管理で最も揉めやすいのが、途中の変更と追加費用です。要件定義の後に「ついでにこの機能も」と頼まれ、口頭で引き受けているうちに、作業が膨らんで納期に間に合わなくなる、という流れはよく起きます。

これを防ぐには、変更を受け付ける手順を最初に決めておくことです。

変更の要望を、決まった様式で受け付ける（メールやチャットの一言で受けない）
開発する側が、日程、費用、品質への影響を見積もる
発注する側の決める権限を持つ人が、受けるかどうか、時期をずらすかを判断する
判断の結果を記録し、計画と契約に反映する

小さな変更でも、この手順を通すことが大切です。1つ1つは数時間の作業でも、10件たまれば数日分の作業になります。記録が残っていれば、後から追加費用の話し合いをするときにも、事実に基づいて話ができます。

振り返りで次の案件に生かす

案件が終わったら、予定と実績を比べて振り返ります。Backlogを提供するヌーラボのブログでは、プロジェクトの終わりに行う評価について、次のように書かれています。

完了したプロジェクトを評価し、実際の工数、品質、予算を検証します。予定工数と実際の差異、品質目標の達成度、予算の消化状況を詳細に分析し、問題点を洗い出します。出典: backlog.com

振り返りで特に役立つのは、工程ごとの予定と実績の差です。「要件定義が予定の1.5倍かかった」「テストで見つかった不具合の半分は要件のあいまいさが原因だった」といった事実が分かれば、次の案件の見積もりと計画の精度が上がります。案件管理の記録をきちんと残しておくことは、その案件のためだけでなく、次の案件の見積もりの根拠を作ることでもあります。

振り返りは、責任を問う場にしないことが大切です。「誰が悪かったか」を話し始めると、関わった人は事実を出しにくくなり、本当の原因にたどり着けません。「何が起きたか」「なぜ起きたか」「次はどうするか」の3つの問いに絞り、出てきた改善の案は、次の案件の計画のひな型や確認の一覧に書き加えます。振り返りの結果が次の案件の手順に反映されて、はじめて振り返りの時間が生きてきます。

発注する側が担う役割

システム開発の案件管理は、開発する側だけの仕事だと思われがちですが、発注する側にも担う役割があります。IPAのモデル契約の第二版が「プロジェクトマネジメント義務及び協力義務」を見直しの論点に挙げているように、開発の成否は、発注する側がどれだけ協力するかにも左右されます。

発注する側が担う主な役割は次のとおりです。

業務の要件を決め、決めたことに責任を持つ
開発する側からの質問や課題に、期限までに答える
社内の関係する部署の意見を取りまとめ、窓口を1つにする
受入テストを計画し、期限までに検収の判断をする
変更の要望を出すときは、影響の見積もりを受けてから判断する

この中で特に遅れが出やすいのが、2つ目の「期限までに答える」です。開発する側から出た課題に発注する側が答えないまま1週間、2週間と過ぎると、その間の作業が止まり、最後に納期のしわ寄せが来ます。課題の一覧に「回答の期限」と「回答する人」を書き、定例会で必ず確かめる運用にしておくと、答えが滞るのを防げます。

社内の窓口を1つにすることも大切です。営業部門と経理部門が別々に開発会社へ要望を伝えると、要望どうしが食い違い、開発する側はどちらに従えばよいか分からなくなります。発注する側の中で意見をまとめてから伝える役割の人を、案件の最初に決めておきます。

見積もりと計画の立て方

案件管理の出発点になるのが、見積もりと計画です。見積もりが甘いと、どれだけ丁寧に管理しても計画どおりには進みません。

見積もりは、作業の一覧から積み上げて作るのが基本です。作業を1人が数日で終えられる大きさまで分け、それぞれにかかる時間を見積もって合計します。大きな単位のまま「この機能は1か月」と見積もると、中に含まれる細かい作業を見落としやすくなります。

見積もりには、次のような見落としやすい作業も含めます。

打ち合わせと議事録の作成
設計書やテストの記録などの文書の作成
発注する側の確認を待つ時間
既存のシステムからのデータの移行
本番の環境の準備と、運用の手順書の作成

これらは「開発」そのものではないため見積もりから漏れがちですが、実際には案件全体の時間のかなりの部分を占めます。

計画を立てるときは、見積もりに余裕を持たせます。全ての作業が予定どおりに進むことはまずないので、工程の区切りごとに予備の日を設け、どこかで遅れが出ても全体の納期を守れるようにします。予備の日を作業ごとに少しずつ足すと、作業する人がその余裕を使い切ってしまいがちです。工程の終わりにまとめて確保しておくほうが、遅れの吸収に使いやすくなります。

定例会と進み具合の報告

案件の進み具合は、定例会と報告で関わる人に共有します。システム開発では、週に1回の定例会を開き、進み具合、課題、変更、リスクを確かめるのが一般的です。

定例会の議題は、毎回同じ順番にしておくと、短い時間で漏れなく確かめられます。

全体の進み具合。工程ごとの予定と実績の差を確かめる
遅れている作業。理由と、取り戻すための手を確かめる
課題。回答の期限が来たものと、新しく出たものを確かめる
変更の要求。見積もりが終わったものの判断と、新しく出たものの受付をする
リスク。状況が変わったものを確かめる
決まったこと。会議で決まったことを読み上げて確かめる

報告の資料は、定例会のためにわざわざ作り直すのではなく、日々の管理に使っている一覧をそのまま映すのが効率的です。資料を作るための時間がかかると、報告そのものが負担になり、実際の状況より遅れた情報が共有されることになります。

報告の中で、遅れを隠さないことも大切です。遅れは早く共有されるほど、取れる手が多くなります。人を加える、範囲を後の工程に回す、納期を相談するといった判断は、遅れが分かった時点が早いほど選択肢が広がります。

システム開発の案件でよくある3つの失敗

システム開発の案件管理で、よく見られる失敗を3つ挙げます。どれも、記録と共有の仕組みで防げるものです。

失敗1 要件があいまいなまま設計に進む

日程を守ろうとして、要件定義で決まっていない点を残したまま設計に進むと、設計や実装の途中で何度も確認が発生し、手戻りが増えます。結果として、要件定義を延ばしたほうが早く終わった、ということになりがちです。決まっていない点は課題として記録し、いつまでに決めるか、決まらなかったときにどう扱うかを先に決めておきます。

失敗2 変更を口頭で受けてしまう

変更管理の節で書いたとおり、小さな変更を口頭で受け続けると、作業が膨らんで納期に間に合わなくなります。しかも記録が残っていないため、追加費用の話し合いもできません。変更は必ず決まった手順を通す、という原則を、案件の最初に発注する側とも共有しておきます。

失敗3 テストの時間を削る

実装が遅れると、しわ寄せはテストの工程に来ます。テストの時間を削って納期を守っても、本番で不具合が出れば、直すための時間と信用を失います。テストの時間は計画の段階で確保し、実装が遅れたときは、テストを削るのではなく、範囲を後に回すか納期を相談するかを判断します。

納品後の運用と保守への引き継ぎ

案件は、納品して終わりではありません。システムを使い始めた後の運用と保守に、案件の記録を引き継ぐことも案件管理の一部です。

引き継ぐものは、設計書、運用の手順書、未解決の課題の一覧、既知の不具合の一覧、案件中に決まったことの記録です。特に「なぜこの仕様にしたのか」という経緯は、後から仕様を変えるときに欠かせない情報ですが、担当者の頭の中にしか残っていないことが多くあります。案件の途中から、決まったことを経緯とともに記録しておけば、引き継ぎの資料をわざわざ作る手間も減ります。

保守を別の会社や別の担当者が受け持つ場合は、引き継ぎの打ち合わせを開き、資料だけでは分からない点を質問できる機会を設けます。保守の契約の範囲（不具合の修正だけか、小さな改修も含むか）も、この時点で確かめておきます。

案件管理のツールの選び方

システム開発の案件管理に使う道具は、案件の規模と関わる人数で選びます。

小さな案件なら表計算で始められる

関わる人が3人から5人程度で、期間が数か月の小さな案件なら、表計算で作業の一覧、課題の一覧、変更の一覧の3つのシートを作るだけでも十分に管理できます。日付の列からガントチャート風の表示を作ることもできます。

課題管理型のツール

開発の現場でよく使われるのが、課題（チケット）ごとに担当、期限、状態、やり取りを記録する課題管理型のツールです。代表的なBacklogは、2027年1月1日からプランを改定すると公式ブログで告知しています。現在のプランの新規契約は2026年12月31日で終わり、フリープランのユーザーの上限は10名から5名に変わります。Backlogで案件を管理している開発チームは、年内に人数と契約の更新時期を確かめておく必要があります。

ボード型のツール

作業をカードとして並べ、カンバンやガントチャートで進み具合を見るボード型のツールは、開発者以外の人も参加する案件で使いやすい道具です。発注する側の業務部門の人にも、カードの並びで進み具合が伝わります。

その候補の1つがPinatecaです。公式サイトによると、Pinatecaはカンバン、ガントチャート、カレンダー、リストなど8種類のボードとチャットを持つプロジェクト管理の道具で、5人まで、ボード10個までなら期限なしで無料で使えます。ガントボードではカードの期間が横棒で並び、バーをドラッグして開始日や締め切りを変えられ、今日の線で遅れている作業が分かります。カードにはサブタスク、担当者、ラベル、添付、カスタムフィールド（見積工数や優先度など独自の項目）を持たせられ、カードごとのコメントに経緯が残ります。ワークスペースごとにメンバーと見える範囲を分けられ、社外ゲストの招待にも対応しています。

業務委託の技術者の稼働を記録したい場合は、追加のオプションの稼働タイムシート（1人あたり月額980円、年払いなら月額780円、税抜）で、0.5時間刻みの稼働の入力、担当者別と案件別の集計、稼働報告書や業務完了報告書の印刷ができます。時間単位、案件単位、月額固定の3つの契約の形に対応しているため、準委任の稼働の報告と、請負の完了の報告を同じ場所で扱えます。6人目、または11個目のボードからは、スタンダードプランで1人あたり月額500円（年払いなら月額400円、税抜）です。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

フリーランスや業務委託で開発案件に関わるとき

システム開発の案件には、フリーランスや業務委託の技術者が加わることが多くあります。受ける側の立場で案件管理に関わるときに、気をつけたい点を挙げます。

まず、契約の形を確かめます。請負なのか準委任なのかで、求められる報告の中身が違います。請負なら完成と検収の条件を、準委任なら作業の範囲と稼働の報告の方法を、契約の前に確かめます。

次に、指示を受ける窓口を1つに決めてもらいます。発注する会社の複数の人から別々の指示が来ると、どの指示を優先すべきか分からなくなります。指示の窓口と、変更を判断する人を確かめておくと、作業の手戻りが減ります。

そして、自分の作業の記録を自分でも残します。発注する側の管理の道具に記録していても、契約が終わると見られなくなることがあります。作業の内容と時間、受けた指示と変更の経緯を手元にも控えておくと、請求や後の確認のときに困りません。

準委任の契約で働く場合は、稼働の報告の形を最初に決めておきます。1日ごとの時間と作業の内容を、どの単位で、いつまでに、誰に提出するかを確かめます。月末にまとめて思い出しながら書くと、作業の内容があいまいになり、発注する側から説明を求められたときに答えにくくなります。毎日の終わりに5分ほどで記録する習慣をつけておくと、報告の精度が上がり、契約の更新の際にも、どの作業にどれだけ時間をかけたかを根拠に話ができます。

請負の契約で働く場合は、完成の条件と検収の期限を確かめます。検収の期限が決まっていないと、確認が長引いて支払いが遅れることがあります。

業務委託で働く人を守るルールとしては、2024年11月に施行されたフリーランス法（特定受託事業者に係る取引の適正化等に関する法律）があり、発注する側に取引の条件をはっきり示すことなどを求めています。詳しくは厚生労働省や公正取引委員会の案内で確かめてください。

在宅の仕事の現場から見えること

2004年から在宅ワークとフリーランスの仲介を続けてきた運営者として見てきた限りでは、開発案件で発注する側と受ける側の関係が長く続くのは、要件と変更の記録をきちんと共有しているケースです。開発の腕前が同じでも、決まったことと決まっていないことを毎回書き残す技術者は、発注する側から「この人に任せると安心」と見られ、次の案件の相談が自然に来るようになります。

仲介の手数料が乗らない直接の取引では、同じ予算でも発注する側はより多くの作業を頼め、受ける側の手取りは厚くなります。手数料0%で直接取引できる関係では、範囲や変更を当事者同士で直接すり合わせるので、案件管理の丁寧さがそのまま信頼と報酬に表れます。

システム開発の案件に関わる仕事の種類と働き方は、アプリケーション開発のお仕事で紹介しています。業務の流れを整理してAIや道具の活用を支援する仕事はAIコンサル・業務活用支援のお仕事が、開発の現場でセキュリティやデータ活用に関わる仕事はAI・マーケティング・セキュリティのお仕事が参考になります。発注する側として業務とシステムの両方を見渡す力をつけたい人には、経営と業務の改善を体系的に学べる国家資格の中小企業診断士も選択肢になります。要件から納品までの流れを記録で支える案件管理は、発注する側にとっても受ける側にとっても、開発を成功に導くための土台です。