システム開発のトラブルを防ぐ責任分担の3つの見立て

📘 この記事でわかること
- ベンダのPM義務とユーザの協力義務がかみ合わずトラブルが起きる仕組みと、参画時に確かめる責任分担の項目
- 準委任でも善管注意義務を負い怠れば債務不履行になることと、請負で重大な過失が責任の重さを分ける仕組み
- 工程をまたいで責任が遡る紛争を防ぐ変更管理の手続きと、責任分担を見立てられる人が案件で信頼される理由
システム開発の案件でトラブルが起きると、責任の所在を巡って双方の主張が食い違う場面があります。契約書に書かれた文言だけでなく、参画する時点でどこまでの義務を引き受けているかの見立てが、後々の負担を大きく左右します。本記事では、IPAが示すモデル契約の考え方をもとに、システム開発のトラブルを防ぐための責任分担の見立て方を整理します。準委任・請負それぞれの責任の性質と、工程をまたいで責任が波及する仕組みを押さえれば、参画前に確認しておく点が明確になります。
1. システム開発のトラブルは、責任の隙間で起きます
紛争は片方の落ち度でなく、ベンダのPM義務とユーザの協力義務のかみ合わせ
システム開発の案件でこじれる場面を思い返すと、進捗の遅れや仕様の未確定の裏側に、双方の対応のずれが重なっていることに気づきます。IPAのモデル契約の解説でも、ベンダが担うプロジェクトマネジメント義務と、ユーザが担う協力義務の双方について、契約上の手当てを通じて紛争を防ぐ整理が検討されています1。つまり紛争の芽は、どちらか片方の義務ではなく、双方の義務がかみ合う場所、あるいはかみ合わない隙間に生まれます。たとえば、仕様の確定が遅れている場面では、ユーザ側の資料提供が滞っているのか、ベンダ側の確認が追いついていないのかを、双方が同じ前提で共有できているかが問われます。
だから参画時に責任の分担を見立てる
参画が決まった直後は、開発の中身に気持ちが向きやすく、責任の分担まで確認する余裕は後回しになりがちです。しかし、開発の技術的な難しさよりも、責任の線引きが曖昧なことのほうが、後のトラブルを大きくします。参画時にPM義務と協力義務の双方がどう手当てされているかを見立てておくことが、紛争予防の出発点になります。
責任分担が曖昧なまま参画すると、進捗が遅れた原因を巡って、どちらの対応が不足していたのかを後から言葉にする作業に時間を取られます。特に参画したばかりの案件では、既存のメンバーが当然と思っている運用が、契約書には明文化されていないことがあります。契約書を読み合わせるだけでなく、実際の運用でPM義務と協力義務がどう機能しているかを、参画の早い段階で確かめておくと、こうした後戻りを防ぎやすくなります。
出典:IPA『情報システム・モデル取引・契約書』解説(2025年4月24日)をもとに作成
表1:参画時に確かめる責任分担の項目
参画前に、責任分担に関わる項目を一つずつ確認しておくと、後からの認識のずれを防ぎやすくなります。ここでは、ベンダのPM義務とユーザの協力義務のかみ合わせという視点から、参画時に確かめておきたい項目を整理しました。契約書の条文だけでなく、実際の運用でどちらがどこまで担うのかを、事前に言葉にしておくことが大切です。特に契約形態が準委任型か請負型かによって、確認したい比重も変わってきます。
| 項目 | 確認すること | 関わる義務 |
|---|---|---|
| 進捗の報告方法 | 報告の頻度と様式を事前に合意しているか | PM義務 |
| 資料・データの提供 | ユーザ側の提供時期と担当者が明確か | 協力義務 |
| 仕様確定の期限 | 未確定のまま着手した場合の扱いを決めているか | 協力義務 |
| 意思決定の窓口 | 変更や判断を誰が最終決定するか合意しているか | PM義務・協力義務 |
| リスクの共有 | 遅延リスクを察知した際の報告ルールがあるか | PM義務 |
表にある項目は、契約書の条文を確認するだけでなく、参画時のキックオフの打ち合わせで実際にすり合わせておくと、後から「言った・言わない」になりにくくなります。
まず確かめておきたいのは、自分の契約が準委任型であるときに、責任がどう扱われるかという点です。
2. 「準委任だから責任は軽い」は思い込みです
準委任でも受任者として善管注意義務を負う
準委任型の契約だから、成果物の完成責任を負わない分、責任は軽いと感じている場面があります。ですが、準委任型であっても、受任者としては善良な管理者の注意義務、いわゆる善管注意義務を負っています2。業務の遂行そのものに、専門家として求められる注意の水準がある、という理解が出発点になります。たとえば、要件のヒアリングだけを任された案件でも、聞き取った内容に矛盾がないか確認する注意までは、善管注意義務に含まれると考えられます。
怠れば債務不履行責任になる
契約書に成果物の定義がないと、責任を問われる場面が想像しにくくなります。成果物の有無よりも、業務の遂行過程で注意を怠ったかどうかのほうが、準委任型では責任の分かれ目になります。善管注意義務を怠れば、債務不履行責任を負うことになります2。参画時には、どの業務についてどこまでの注意が求められるかを、契約書や業務内容の合意から読み取っておくと安心です。
準委任型の案件に参画するフリーランスエンジニアにとって、善管注意義務の水準は、これまでの経験や専門性に応じて変わってきます。難易度の高い設計判断を任されるほど、求められる注意の水準も上がると考えておくと、業務範囲の合意がしやすくなります。フリーランスとして複数の案件を掛け持ちする場合でも、それぞれの案件で善管注意義務の水準は独立して発生します。一つの案件への対応に追われて、別の案件への注意が薄れることは、双方にとって望ましくありません。
出典:IPA『情報システム・モデル取引・契約書』解説(2025年4月24日)をもとに作成
では、請負型の契約では、責任の重さはどこで変わるのでしょうか。
3. 請負では「重大な過失」が責任の重さを分けます
契約不適合責任と重大な過失
請負型の契約で成果物に不具合が見つかると、責任の範囲がどこまで及ぶのか気になります。請負型の契約不適合責任などでは、重大な過失があったかどうかが、損害賠償の責任制限条項が適用されるかどうかの分かれ目になっています3。通常の過失と重大な過失とでは、負う責任の重さが変わってくるということです。たとえば、テストを一部省略して納品した場合、その省略が業務上やむを得ない判断だったのか、注意を怠った結果だったのかで、責任の重さが変わってきます。
予測可能性を高めるために合意しておく
「重大な過失」がどこからを指すのか、感覚だけで判断するのは心もとないものです。感覚に頼るよりも、想定される作業内容や判断基準をあらかじめ契約や仕様書のやり取りに残しておくほうが、後の予測可能性を高めます。参画時に、成果物の受け入れ基準や不具合対応の手順を確認しておくと、重大な過失に該当するかどうかの線引きが見立てやすくなります。
重大な過失の判断は、結果の重さだけでなく、事前にどこまで注意を払っていたかという経緯も踏まえて行われます。作業のログや確認のやり取りを残しておくことは、後から重大な過失にあたらないことを示す材料にもなります。フリーランスとして請負型の案件に参画する場合、重大な過失に該当するリスクを抑えるために、判断の根拠となったやり取りを都度残しておくことが助けになります。
出典:IPA『情報システム・モデル取引・契約書』解説(2025年4月24日)をもとに作成
表2:義務の種類と内容の整理
準委任型と請負型では、負う義務の性質が異なります。ここでは、これまで触れたPM義務・協力義務・善管注意義務・契約不適合責任に関わる義務を一覧にし、それぞれどのような内容を含むのかを整理しました。契約形態の違いを比べるためではなく、義務の中身を理解することが、参画時の見立てに役立ちます。特に善管注意義務と契約不適合責任は、性質が異なるため、混同しないように整理しておくと理解しやすくなります。
| 義務 | 内容 | 関わる契約の性質 |
|---|---|---|
| PM義務 | 進捗管理・品質管理・リスクへの対応 | ベンダ側が担う |
| 協力義務 | 資料提供・意思決定・体制整備 | ユーザ側が担う |
| 善管注意義務 | 専門家として求められる注意の水準での業務遂行 | 準委任型で受任者が負う |
| 契約不適合責任 | 成果物の不適合に対する責任。重大な過失で重さが変わる | 請負型で受注者が負う |
特に請負型の案件では、契約不適合責任の対象となる期間や範囲も、参画時に確認しておく項目として押さえておくと安心です。
責任は一つの工程だけで完結するとは限りません。工程をまたいで波及していく場面もあります。
4. 責任は工程をまたいで遡ります:変更は手続きで守る
多段階契約で上流工程まで遡って追及される紛争が頻発
下流の工程で問題が表面化すると、その工程の担当者だけに目が向きがちです。多段階契約では、下流工程でトラブルが生じた際に、ユーザが上流工程まで遡って解除や損害賠償を追及する紛争が頻発しています4。自分が担当する工程より前の合意内容にも、無関係ではいられない場面があるということです。たとえば、運用後に不具合が見つかった場合、その原因が要件定義の段階での認識違いにさかのぼって議論されることがあります。
変更管理手続を決めておく
着手後に「ここだけ直してほしい」という依頼が来ると、その場で応じるかどうかを個人の判断で決めてしまいがちです。その場の判断に頼るよりも、変更をどう扱うかをあらかじめ手続きとして決めておくほうが、後戻りを防げます。個別契約書では、変更管理手続の詳細化が図られています5。参画時には、変更の申し出をどこに、どう記録するかを確認しておくと、工程をまたぐ責任の遡及に備えられます。
変更管理の手続きが曖昧なまま作業を進めると、口頭で了承したはずの変更が、後になって「聞いていない」という対立に発展することがあります。小さな変更であっても、記録を残す習慣を早い段階からつけておくと、工程をまたぐ責任の遡及に巻き込まれるリスクを抑えられます。変更の依頼を受けたときに、まず合意した手続きに沿って進めたいと伝えられるかどうかも、参画先との信頼関係を左右します。
出典:IPA『情報システム・モデル取引・契約書』解説(2025年4月24日)をもとに作成
表3:トラブルを防ぐ合意・変更のチェック
変更管理は、口頭でのやり取りだけに頼ると、後から「言った・言わない」の対立を招きます。ここでは、参画時から工程の途中まで、トラブルを防ぐために合意・記録しておきたい項目を整理しました。契約書の条文に加えて、実務の運用ルールとして共有しておくことが有効です。特に変更の規模が小さいときほど、記録を省略しやすいため注意が必要です。
| 場面 | 合意・確認しておくこと |
|---|---|
| 参画開始時 | 各工程の完了基準と、上流工程の合意内容の引き継ぎ方 |
| 仕様の未確定時 | 未確定のまま着手する場合の責任の扱い |
| 変更の申し出時 | 変更を記録する窓口と手続き、影響範囲の確認 |
| 工程の切り替え時 | 前工程からの申し送り事項と、遡って問われうる論点 |
責任分担が明確な開発案件をチェックする →
ここまで見てきた責任の見立ては、参画する案件で信頼される材料にもなります。
5. 責任分担を見立てられる人が、案件で信頼されます
参画前に責任と変更の扱いを確かめられる人は任されやすい
契約書を読み込むことは、開発そのものの作業とは違うので、後回しにしたくなる気持ちも分かります。しかし、参画前にPM義務・協力義務・善管注意義務・変更管理の扱いを確かめられる人は、任される場面が広がっていきます。責任の見立ては、法律の専門家だけの仕事ではなく、参画するエンジニア自身が持てる備えです。
こうした見立ては、案件ごとに得た経験を次の参画先に伝える言葉にもなります。「どの工程でどこまでの責任を担ったか」を自分の実績として言語化できると、次の案件でも早い段階から任される範囲が広がっていきます。
リモート中心でも見立ては示せる
リモートで参画すると、対面で細かく確認する機会が限られると感じることがあります。ですが、責任分担の見立ては、対面かどうかよりも、参画前にどれだけ言葉にして確認したかで決まります。Remoguが取り扱う案件の90%以上がフルリモート可能です6。場所に縛られずに参画しながらも、こうした責任の見立てを一つずつ確かめていくことができます。
参画前にこうした見立てを言葉にして示せると、クライアントとの最初のやり取りから、任せられる相手だという印象につながります。責任の扱いを曖昧にしたまま進める人よりも、事前に確認する人のほうが、次の案件でも声がかかりやすくなります。
フルリモートで参画できる開発案件を見る →
自分の経験に合う条件で、責任の分担が明確な案件を選びたいときは、まず登録して具体的な案件の条件を確かめてみることが、次の一歩になります。
6. まとめ
ここまでの内容を振り返ります。
- システム開発の紛争は、ベンダのPM義務とユーザの協力義務がかみ合わない隙間で起きます。参画時に双方の義務の手当てを見立てておくことが出発点です。
- 準委任型でも善管注意義務を負い、怠れば債務不履行責任につながります。成果物の有無で責任の軽重を判断しないことが大切です。
- 請負型では、重大な過失の有無が責任の重さを分ける分水嶺になります。判断の根拠を残しておくと予測可能性が高まります。
- 責任は工程をまたいで上流まで遡って問われることがあり、変更管理の手続きが備えになります。
- こうした責任分担を参画前に見立てられることは、案件で信頼される材料になります。
システム開発の案件は、技術力だけでなく、責任の見立て方でも信頼を積み重ねていくことができます。契約書を読み直すことから始めても、これまでの案件を振り返ることから始めても構いません。まずは今関わっている、あるいはこれから参画しようとしている案件について、責任の分担を一つずつ言葉にしてみることが、次の一歩になります。Remoguで自分の経験に合う条件を確かめながら、参画前に見立てる習慣を積み重ねていきましょう。
7. よくある質問
準委任なら責任は軽いですか
準委任型は成果物の完成そのものを約束する契約ではありませんが、受任者として善管注意義務を負っています2。業務の遂行過程で注意を怠れば、債務不履行責任を負うことになるため、責任が軽いとは限りません。「準委任だから安心」という思い込みだけで契約内容を確認しないまま参画すると、後から想定外の責任を問われる場合があります。参画前に、自分が担う業務の範囲と、その中でどこまでの注意が求められるのかを言葉にしておくと安心です。
参画前に何を確かめればよいですか
PM義務と協力義務がどう手当てされているか、成果物の受け入れ基準、変更を申し出る窓口と手続きを確かめておくと、参画後の認識のずれを防ぎやすくなります。特に成果物の受け入れ基準は、参画後に認識のずれが生まれやすい部分なので、早い段階で言葉にしておくと安心です。Remoguでは、案件ごとの契約内容や条件を確認しながら参画先を選ぶことができます。個別の契約内容の解釈に迷う場合は、当事者間での確認や専門家への相談も選択肢になります。
変更を頼まれたらどう対応すればよいですか
その場で口頭のみで応じるのではなく、変更管理の手続きに沿って記録に残すことが有効です5。口頭でのやり取りだけに頼ると、変更の範囲や責任の扱いについて、後から双方の記憶が食い違う場合があります。影響範囲や責任の扱いを、変更の申し出とあわせて確認しておくと、後戻りを防げます。小さな変更でも記録に残す習慣は、参画先との信頼関係を積み重ねることにもつながります。返信のメールやチャットに要点を残すだけでも、後から振り返れる記録になります。
リモートで開発案件に関われますか
Remoguが扱う案件は90%以上がフルリモート可能です6。働く場所を選べることは、責任分担を確かめる時間の確保にもつながります。場所に縛られずに参画しながら、責任分担の見立てを一つずつ確かめていくことができます。まずは登録して、自分の経験に合う案件の条件を確認してみることをおすすめします。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
任される責任の範囲は案件によって変わります。まずはリモート中心の開発案件が、いまどんな条件で並んでいるかを見てみてください。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 情報処理推進機構「情報システム・モデル取引・契約書」(2025年4月24日)
*2 情報処理推進機構「情報システム・モデル取引・契約書」(2025年4月24日)
*3 情報処理推進機構「情報システム・モデル取引・契約書」(2025年4月24日)
*4 情報処理推進機構「情報システム・モデル取引・契約書」(2025年4月24日)
*5 情報処理推進機構「情報システム・モデル取引・契約書」(2025年4月24日)
*6 Remogu(株式会社LASSIC運営)公開情報:扱う案件の90%以上がフルリモート可能