案件の終盤が近づくと、日々の稼働報告をどう出すかよりも、それを誰がどう受け止めるのかという点で迷う場面が増えてきます。報告は出しているのに、相手の反応がはっきりしないまま日程だけが進んでいく状況は、参画する現場でたびたび見られる悩みです。この記事では、IPAの資料をもとに、業務の終わりがどのような手続きで閉じられているかを整理します。報告と確認がどう対になっているかを知ることで、案件の締めくくり方の見通しが立ちやすくなります。

1. 報告の話は役割分担から始まる

稼働報告が受け止められないまま終わる背景

案件の終盤になるほど、誰が何を確認して締めくくるのかという線引きが曖昧になりがちです。日々の稼働報告を出していても、それを受け止める側の役割がはっきりしていなければ、報告そのものが宙に浮いた状態になってしまいます。

この背景には、報告を受け止める役割が最初から言葉にされていないという事情があります。誰が確認して、誰が次の判断を下すのかが決まっていなければ、業務が終わったのかどうかを誰も言い切れない状態が続きます。

IPAの資料は、こうした状態を軽く見ていません。責任関係や作業分担等が明確になっていないと、損害賠償請求の訴訟などのトラブルに発展するケースもあるとしています¹。曖昧さは、単なる気まずさではなく、契約上の争いにつながりうる論点として扱われています。

役割分担を先に明確にしておく効果

役割分担が曖昧なまま進める案件より、最初に受け止める側と伝える側を決めておく案件のほうが、終盤の手続きは落ち着いて進みます。確認する相手が分かっていれば、報告は宛先のある連絡になります。

この違いは、報告の書き方を工夫することでは埋まりません。書式を整えるより先に、誰が受け止める役割を持つのかという合意を作ることのほうが、終わり方の見通しに直結します。役割分担は、報告を出す前に済ませておきたい土台の部分です。

次章では、案件の途中で提出する資料の承認が、この役割分担とどうつながっているかを見ていきます。稼働報告だけでなく、途中の資料も同じ土台の上に置かれています。

出典：IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」（2025年4月）をもとに作成

2. 途中の資料の承認にも効果がある

途中で出す資料の位置づけ

案件の間に作成する設計メモや進捗資料は、最終的な成果物ではないという理由で、確認を後回しにされがちです。しかし、これらをどの段階で承認してもらうかという点は、終盤の確認のしかたに直結する要素として扱われています。

IPAの資料が示す第二版のポイントには、中間資料の承認の効果を明確化することが挙げられています²。途中で出す資料を都度確認してもらうことは、単なる進捗共有ではなく、後になって食い違いを防ぐ手続きとして位置づけられています。

効果が明確になっているということは、承認を受けた資料がその時点の合意として扱われる、という意味合いを持ちます。前の段階で確認された内容を、後になって覆さない土台になる点は、途中の資料を軽く扱わない理由になります。

中間の承認が終盤の確認に持つ意味

途中の資料を確認しないまま進める案件より、区切りごとに承認を得ながら進める案件のほうが、終盤の業務終了の確認はすんなり進みます。積み重ねた合意があれば、最後に確認する内容はこれまでの延長線上のものになります。

逆に、中間の資料が承認されないまま積み上がっていると、終盤になって初めて内容のずれに気づく場面が出てきます。業務終了の確認は、経緯を一つずつ確かめ直す作業ではなく、積み上げてきた合意を最後にまとめる作業であることが望ましい形です。

途中の資料の扱いが役割分担の話とつながっていることが見えてくると、次に気になるのは、その役割分担そのものが何を対象にしているかという点です。

出典：IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」（2025年4月）をもとに作成

3. 役割分担そのものが明確化の対象

何を明確にする対象として挙げられているか

役割分担という言葉は広く使われますが、IPAの資料が挙げているのは、ユーザ側とベンダ側それぞれが持つ役割を明確にすることです。責任関係として、ユーザ・ベンダの役割分担の明確化が挙げられています³。

この明確化は、案件が始まる前の一度きりの取り決めではなく、途中の資料の承認や、終盤の報告・確認とも地続きの話です。誰が何を確認する立場にあるかがはっきりしていれば、前章で見た中間資料の承認も、次に見る進行の責任も、同じ線の上に並びます。

役割分担が明確化の対象として挙げられているということは、決めずに進めても案件は動いてしまうという実情の裏返しでもあります。動いてしまうからこそ、明確にしておく価値があるという位置づけです。

役割が分担されている状態とされていない状態の違い

役割が分担されていない状態では、確認の連絡が誰に届くのか、誰が答えを持っているのかが案件ごとに変わってしまいます。分担されている状態では、連絡の宛先も答えを持つ立場も、あらかじめ決まっています。

この違いは、報告する側にも影響します。宛先が決まっていれば、報告は特定の相手に向けた連絡になり、受け止められたかどうかも確かめやすくなります。宛先が定まらないまま出す報告は、出したはずなのに確認された実感を持ちにくいものです。

役割分担が明確化の対象になっているという点を踏まえたうえで、次に見ていきたいのは、案件を進める責任がどこに置かれているとされているかという点です。

4. 進行の責任はどこに置かれるのか

進行管理の責任として挙げられている内容

案件を進める中で、日程の調整や作業の割り振りといった進行管理は、誰の役割になるのでしょうか。責任関係として、プロジェクトマネジメントの責任が挙げられています⁴。進行そのものを管理する立場が、明確化の対象の一つとして位置づけられています。

進行管理の責任がどこに置かれているかは、稼働報告の受け止め方にも関わります。進行を管理する立場が明確であれば、報告はその立場に向けて出す連絡になり、確認の返答もその立場から返ってくるという流れが作られます。

逆に、進行管理の責任がはっきりしないまま案件が進むと、報告を受け止める人が案件ごとに変わり、確認の基準も揺れやすくなります。プロジェクトマネジメントの責任という言葉が明確化の対象に挙げられているのは、この揺れを防ぐためだと読み取れます。

参画する側から見た進行の責任

参画する立場から見ると、進行管理の責任がどこに置かれているかは、日々のやり取りの相手を決める情報でもあります。指示、要請、依頼等の連絡は、各企業の実施責任者を介するという流れが挙げられています¹⁰。連絡の経路が決まっていることは、途中で相手が変わる不安を減らす材料になります。

進行の責任が曖昧な案件より、実施責任者を介する経路が決まっている案件のほうが、途中の連絡も終盤の報告も迷わず届けられます。経路が決まっているということは、報告の宛先に迷う場面が少ないということでもあります。

進行の責任が置かれる場所が見えてきたところで、次は、案件の途中で決まりきらない事項がどう扱われているかを見ていきます。

5. 決まっていない事項の扱い

未決事項として挙げられている内容

案件を進めていると、その場では判断できず、後回しにせざるを得ない事項が出てきます。責任関係として、未決事項の確定手続・時期の明確化が挙げられています⁵。決めきれない事項があること自体が問題ではなく、いつ、どの手続きで確定させるかが明確化の対象です。

未決事項を先延ばしにしたまま進める案件より、確定させる時期をあらかじめ決めておく案件のほうが、終盤になって慌てる場面は少なくなります。決める時期が分かっていれば、それまでは判断を保留にしておいても見通しは立ちます。

この明確化は、前章で見た進行管理の責任とも重なります。未決事項をいつ確定させるかを決める立場は、進行を管理する立場と同じ線上にあることが多く、責任関係の明確化という一つの話の中に含まれています。

明確化の対象を一覧で見る

ここまで見てきた責任関係の明確化は、役割分担・進行管理の責任・未決事項の確定手続という三つの視点に整理できます。それぞれが独立した論点ではなく、稼働報告を受け止め、業務の終了を確認する一連の手続きを支える土台になっています。

三つの視点を個別に覚えておくより、表としてまとめて手元に置いておくほうが、案件ごとの状況と照らし合わせやすくなります。以下に、それぞれの視点と挙げられている内容を整理します。

視点	挙げられている内容
役割分担の明確化	ユーザ・ベンダの役割分担の明確化3
進行管理の責任	プロジェクトマネジメントの責任4
未決事項の確定手続	未決事項の確定手続・時期の明確化5

表を確認したうえで次章に進むと、この明確化が実際にどのような場で話し合われているのかが見えてきます。

6. 話す場と、業務の終了・確認の条

話す場として置かれている仕組み

役割分担や進行の責任が明確になっていても、それを話す場がなければ、確認は個別の連絡に頼ることになります。個別契約で定める取引条件には、連絡協議会の運営に関する事項が挙げられています⁶。定例で話す場そのものが、取引条件の一部として位置づけられています。

連絡協議会のような話す場が置かれている案件では、稼働報告や途中の資料の扱いについても、その場で確認し合う機会が生まれます。話す場がない案件より、定例の場が用意されている案件のほうが、確認の機会は自然と増えます。

この話す場は、業務の終了だけを扱う場ではありません。しかし、途中で積み重ねた確認が終盤の手続きにつながるという前提に立てば、話す場が置かれていること自体が、終わり方の見通しを支える要素になります。

出典：IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」（2025年4月）をもとに作成

契約書のひな型に置かれている条項

業務の終わりをどう締めくくるかについても、契約書のひな型には位置づけが用意されています。契約書のひな型には、業務の終了・確認の条が置かれています⁷。終わり方が個々の案件ごとに一から決められるのではなく、ひな型の中に条項として組み込まれている点は押さえておきたいところです。

条項が置かれているということは、業務が終わったと言えるかどうかを、感覚や自己判断で決めるのではなく、決まった手続きに沿って確認するという前提があるということです。話す場と、この条項とは、どちらも終わり方を型として支える仕組みです。

話す場と条項を並べて見る

話す場と条項は、それぞれ別の書類の中に置かれているため、案件に参画すると別々に把握することになりがちです。ここで一度、どの文書にどのような事項が挙げられているかを並べて確認しておきます。

表にすることで、話す場の運用と、終わりを締めくくる条項が、同じ責任関係の明確化という土台の上に置かれていることが見えやすくなります。

置かれている文書	挙げられている事項
個別契約で定める取引条件	連絡協議会の運営に関する事項6
契約書のひな型	業務の終了・確認の条7

話す場と条項の位置づけが分かったところで、次章では、実際にどのような帳票を通じてこの確認が行われるのかを見ていきます。

7. 報告と確認の帳票と、確かめる項目

出す側の報告と、受け取る側の確認

業務の終わりは、報告する側の申告だけで閉じるものではありません。ドキュメントモデルには、業務終了報告書と業務終了確認書が置かれています⁸。報告する書類と、確認する書類が対になって用意されている点が、この手続きの特徴です。

業務終了報告書は、稼働してきた側から出す書類です。業務終了確認書は、その内容を受け取った側が確認したことを残す書類です。出す側の報告と、受け取る側の確認が対で用意されているということは、どちらか一方だけでは業務の終わりが確定しないということでもあります。

帳票が対になっていない状態で進める案件より、報告書と確認書がそれぞれ用意されている案件のほうが、業務が終わったと言えるかどうかの見通しは立てやすくなります。書類が対で揃っているかどうかは、確かめておきたい項目の一つです。

帳票名	作成する側	確認する側	位置づけ
業務終了報告書	稼働してきた側	確認する側	業務が終わったことを伝える書類8
業務終了確認書	確認する側	稼働してきた側	内容を確認したことを残す書類8

あわせて論点になっている事項

この資料では、ベンダのプロジェクトマネジメント義務およびユーザの協力義務について、モデル契約上の手当てによって紛争の予防に資することはできないかが論点として挙げられています⁹。帳票が整っているだけでなく、双方の義務をどう手当てするかという点も、あわせて議論されている論点です。

連絡の経路についても、指示、要請、依頼等の連絡は、各企業の実施責任者を介するという形が挙げられています¹⁰。誰から誰へ、どの経路で連絡が届くのかは、報告書・確認書の内容と同じくらい、確かめておきたい項目です。

ここまで見てきた帳票・論点・連絡の経路を、確かめる項目として一覧にすると、案件ごとの状況と照らし合わせやすくなります。以下の図に整理します。

出典：IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」（2025年4月）をもとに作成

初めて参画する案件でも、業務終了の確認の考え方は同じですか

初めての案件かどうかにかかわらず、業務の終了を報告と確認が対になった手続きで締めくくるという考え方は変わりません。役割分担や話す場の置かれ方は案件によって異なるため、まずはその案件でどのような形が用意されているかを確かめることが、見通しを立てる出発点になります。

業務終了報告書を出したあとに確認の連絡がない場合、どう考えればよいですか

報告書と確認書が対で用意されているという位置づけを踏まえると、確認が届いていない状態は、手続きがまだ完結していない段階にあると考えられます。個別の状況が問題にあたるかどうかを判断するのではなく、決まっている連絡の経路や話す場を通じて、確認の状況を確かめておくことが、記録を残す形につながります。

週3日稼働のような働き方でも、報告と確認の手続きは変わりますか

稼働の日数や進め方は案件によって異なりますが、業務の終わりを報告と確認が対になった手続きで締めくくるという型そのものは、稼働の形によって変わるものではありません。実施責任者を介する連絡の経路や話す場の運用も、稼働日数にかかわらず確かめておきたい項目です。

業務の終わりを型として理解しておくと、次に参画する案件でも、報告と確認の流れを落ち着いて追えるようになります。Remoguはリモートワーク案件に特化したエンジニアマッチングで、案件の90%以上がフルリモート可能です。まず登録して、自分の経験に合う案件でどのような確認の形が用意されているかを、実際に見てみることから始められます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」起点の問題（2025年4月・2026年9月確認）
＊2 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」途中の承認（2025年4月・2026年9月確認）
＊3 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」役割の線（2025年4月・2026年9月確認）
＊4 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」進行の責任（2025年4月・2026年9月確認）
＊5 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」未決の扱い（2025年4月・2026年9月確認）
＊6 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」話す場の条件（2025年4月・2026年9月確認）
＊7 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」終了の条（2025年4月・2026年9月確認）
＊8 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」終了時の帳票（2025年4月・2026年9月確認）
＊9 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」双方の義務（2025年4月・2026年9月確認）
＊10 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」連絡の通し方（2025年4月・2026年9月確認）