目次
はじめに
「システム開発を発注したら、あとは開発会社に任せておけばいいの？」
「発注者にも協力する義務があると聞いたけれど、具体的に何をすればいいの？」と疑問に感じていませんか。
開発が始まると、仕様の確認や必要な資料の提供、担当者からの質問への回答などを求められ、どこまで対応する必要があるのか判断に迷うこともありますよね。
この記事では、システム開発におけるユーザーの協力義務とは何かを整理したうえで、発注者に求められる具体的な対応や、協力が不足した場合に生じる問題、対応する際の注意点まで順を追って説明します。
システム開発におけるユーザーの協力義務とは？
システム開発では、開発作業を行うベンダーだけでなく、発注者であるユーザーにも、プロジェクトを円滑に進めるための協力が求められる場合があります。
ここでは、なぜ発注者にも協力が求められるのかを確認したうえで、ユーザーとベンダーそれぞれの義務の違いを説明します。
なぜ発注者にも協力が求められるのか
システム開発では、ベンダーだけでは判断できない要件や業務上の確認があるため、発注者の協力も必要です。
発注者が必要な情報を提供し、要件や仕様を確認することで、ベンダーは設計や開発を進めやすくなります。
また、社内関係者との調整など、発注者側で対応する作業もあります。
ユーザーの協力義務とベンダーの義務はどう違うのか
ユーザーの協力義務は、情報提供や要件の確認、仕様に関する意思決定など、開発に必要な対応を行うことです。
一方、ベンダーには、契約内容に沿って設計や開発を進め、システムの完成を目指す役割があります。
双方の義務は内容が異なるため、それぞれが担う範囲を分けて考えることが大切です。
発注者に求められる協力義務の具体的な対応
発注者に求められる協力は、ベンダーへ開発を任せるだけではなく、プロジェクトの各段階で必要な対応を行うことです。
ここでは、システム開発を進めるうえで発注者に求められる具体的な協力内容を説明します。
必要な情報や資料を提供する
発注者は、ベンダーが要件を把握して設計や開発を進められるように、業務内容が分かる資料や情報を提供します。
情報が不足していると、業務の流れや必要な機能を正しく把握できず、開発が進まないことがあります。
そのため、ベンダーから資料や情報を求められた場合は、内容を確認したうえで提供しましょう。
社内の意見を調整して意思決定する
システムの仕様について社内で意見が分かれた場合は、発注者が関係者の意見を整理して方針を決めます。
部署ごとの要望をそのままベンダーへ伝えると、どの内容を採用すればよいのか判断できず、開発が止まることがあります。
発注者側で意見をまとめ、決定した内容を明確に伝えることが大切です。
要件や仕様を確認・確定する
発注者は、ベンダーから提示された要件や仕様を確認し、実際の業務に必要な内容が反映されているかを判断します。
確認が不十分なまま開発が進むと、完成後に想定していた機能との違いが見つかることがあります。
修正が必要な部分は早めに伝え、双方で確認しながら要件や仕様を確定しましょう。
ベンダーからの質問や判断依頼に対応する
ベンダーから要件や仕様について質問や判断を求められた場合は、発注者側で内容を確認して回答します。
回答が遅れると、その判断に関係する設計や開発を進められず、作業が止まることがあります。
必要に応じて社内でも確認し、決定した内容をベンダーへ伝えることが大切です。
成果物を確認して検収する
発注者は、納品された成果物を確認し、契約や確定した要件・仕様に沿っているかを判断します。
問題がなければ検収を完了し、不備が見つかった場合は該当箇所をベンダーへ伝えます。
合意した内容がきちんと反映されているかを確認したうえで、検収を進めましょう。
発注者が協力義務を果たさないとどうなる？
発注者が必要な情報提供や意思決定を行わない場合、ベンダーが次の作業へ進めず、開発スケジュールに遅れが生じる可能性があります。
ここでは、協力義務を果たさなかった場合に起こり得る影響と、責任を考える際のポイントを説明します。
開発スケジュールが遅れる可能性がある
発注者からの情報提供や仕様に関する回答が遅れると、ベンダーが次の設計や開発へ進めないことがあります。
その状態が続けば、予定していた作業開始日や完了日が後ろへずれ、開発全体のスケジュールにも影響します。
特に発注者の判断が必要な作業では、できるだけ早めに対応することが大切です。
追加費用や損害賠償が問題になることがある
発注者側の対応の遅れによって作業のやり直しや開発期間の延長が発生すると、追加費用を求められることがあります。
また、協力義務を果たさなかったことでベンダーに損害が生じた場合は、損害賠償が問題になることもあります。
実際に責任を負うかどうかは、契約内容や双方の対応、損害との関係などを踏まえて判断されます。
ベンダー側の責任も含めて判断する必要がある
開発の遅延や作業のやり直しが発生しても、必ずしも発注者だけに責任があるとは限りません。
ベンダーが必要な情報や判断事項を適切に伝えていたか、開発をきちんと管理していたかも確認する必要があります。
問題が起きた経緯や双方の対応を整理し、それぞれの責任の範囲を判断することが大切です。
仕様変更や追加要望がある場合の注意点
システム開発の途中で仕様変更や追加要望が発生した場合は、当初から予定されていた要件と、新たに追加・変更された内容を分けて整理することが大切です。
ここでは、仕様変更や追加要望が生じた際に確認しておきたいポイントを説明します。
当初の要件と追加・変更された要望を区別する
仕様変更や追加要望が出た場合は、契約時に合意した要件と、開発開始後に追加・変更された内容を分けて確認します。
区別が曖昧なまま進めると、当初の契約範囲に含まれるのか、追加作業になるのか判断しにくくなります。
変更前の要件と新しい要望を照らし合わせ、どこが変わったのかを明確にしておくことが大切です。
変更内容と双方の対応を記録に残す
仕様を変更する場合は、変更内容だけでなく、発注者とベンダーが合意した対応も記録に残します。
追加作業の範囲や費用、納期などを残しておけば、後から双方で合意した内容を確認できます。
認識の食い違いを防ぐためにも、話し合って決めた内容は確認できる形で残しておきましょう。
ユーザーの協力義務を果たすために発注者が注意したいこと
ユーザーの協力義務を適切に果たすには、必要な対応をその都度行うだけでなく、誰が判断し、いつまでに回答するのかを発注者側で整理しておくことが大切です。
ここでは、担当者と意思決定者の明確化、回答期限の管理、契約内容や開発経緯の記録について説明します。
担当者と意思決定者を明確にする
発注者側では、ベンダーとの連絡を担当する人と、仕様や要件について最終判断する人を明確にします。
誰が判断するのか決まっていないと、確認や回答に時間がかかり、開発が止まってしまうことがあります。
判断が必要になったときにスムーズに対応できるよう、それぞれの役割や確認先を決めておきましょう。
回答期限と確認事項を管理する
ベンダーから質問や確認依頼を受けた場合は、確認する内容と回答期限を記録して管理します。
複数の依頼が重なると、回答漏れや遅れによって設計や開発に影響することがあります。
未回答と回答済みの内容を整理し、期限までに対応できるようにしておくことが大切です。
契約内容と開発経緯を確認できる状態にする
契約書や議事録、メールなどは整理して保管し、合意した内容や開発中のやり取りを後から確認できるようにします。
記録が残っていれば、仕様変更やトラブルが起きたときも、いつ、どのような内容に合意したのかを確認しやすくなります。
必要なときに振り返れるよう、契約内容や開発の経緯をきちんと残しておきましょう。
まとめ
システム開発におけるユーザーの協力義務とは、発注者が必要な情報を提供し、要件・仕様の確認や意思決定などを行うことです。
対応が遅れると、開発スケジュールの遅延や追加費用につながることがあります。
トラブルが起きた場合は、発注者だけでなく、ベンダー側の説明や進行管理も含めて双方の対応を確認することが大切です。また、仕様変更や追加要望は当初の契約範囲と分け、費用や納期を含む合意内容を記録しておきましょう。