目次
はじめに
「プロジェクトマネジメント義務とは、開発会社が具体的に何をしなければならない義務なの？」
「システム開発が遅れたり頓挫したりした場合、裁判ではどのような点から責任が判断されるの？」と気になっていませんか。
システム開発のトラブルについて調べていると、仕様変更への対応や進捗管理、発注者への説明などが問題となった裁判例が出てきますが、自社のケースとどこが共通するのか判断しにくいこともありますよね。
この記事では、プロジェクトマネジメント義務が争われた主な裁判例を取り上げながら、裁判所がどのような事情を重視したのか、責任を考える際に確認したいポイントまで解説します。
プロジェクトマネジメント義務とは？
システム開発では、ベンダーが契約で定められた作業を行うだけでなく、プロジェクト全体の進行状況を把握し、必要に応じてユーザーへ説明や提案を行ったかが問題になることがあります。
ここでは、プロジェクトマネジメント義務の基本的な考え方と、システム開発で義務違反が問題になりやすい場面について説明します。
プロジェクトマネジメント義務の基本的な考え方
プロジェクトマネジメント義務とは、ベンダーがシステム開発を円滑に進めるため、進捗や課題を把握し、必要な対応をユーザーへ説明・提案する義務です。
仕様の未確定や作業の遅れが生じた場合は、納期や開発範囲への影響を確認し、ユーザーへ伝えることが求められます。
また、ユーザーの判断が必要な事項について、何をいつまでに決める必要があるのかを示すことも大切です。
システム開発で義務違反が問題になる場面
プロジェクトマネジメント義務違反は、仕様の確定が遅れていたり、追加要望によって作業量が増えていたりする場面で問題になることがあります。
ベンダーがこうした状況を把握しながら、納期や費用への影響を説明せずに開発を続けた場合、適切に対応していたかが問われます。
開発が遅延・頓挫した際は、問題を把握した時点で状況を説明し、仕様の確定や要望の見直しを求めていたかなどが判断材料になります。
プロジェクトマネジメント義務が争われた裁判例
プロジェクトマネジメント義務の内容や範囲を理解するには、実際の裁判でベンダーの対応がどのように問題とされたのかを確認することが重要です。
ここでは、プロジェクトマネジメント義務が争われた3つの裁判例を取り上げ、それぞれで問題となったポイントを説明します。
東京地裁平成16年3月10日判決｜進捗管理や阻害要因への対応が争われた事例
東京地裁平成16年3月10日判決では、ベンダーが開発工程を適切に管理し、作業を妨げる要因に対応する義務を負うかが問題となりました。
裁判所は、ベンダーには開発状況を把握し、作業の遅れや仕様上の問題などを発見した場合には、必要な対応を取ることが求められると判断しました。
そのため、契約上の作業を行うだけでなく、進捗を確認しながら適切に対応していたかが判断のポイントとなりました。
東京地裁平成28年4月28日判決｜問題の予防や注意喚起が争われた事例
東京地裁平成28年4月28日判決では、ベンダーが開発中の問題を予測し、事前にユーザーへ注意を促す必要があったかが争われました。
専門的な知識や経験から問題を予測できる場合には、その影響をユーザーへ伝え、必要な対応を求めることが重要とされました。
そのため、問題が起きた後の対応だけでなく、事前に注意喚起などを行っていたかも判断のポイントとなりました。
札幌高裁平成29年8月31日判決｜開発遅延とベンダー側の対応が争われた事例
札幌高裁平成29年8月31日判決では、システム開発が予定どおり進まないなかで、ベンダーが遅延を防ぐために必要な対応を取っていたかが問題となりました。
裁判所は、遅延という結果だけでなく、ベンダーが進捗や原因を把握し、ユーザーへ状況を伝えながら対応していたかを検討しました。
そのため、遅延が生じるまでの経緯や、問題を把握した後の対応も判断材料となりました。
裁判所はプロジェクトマネジメント義務をどう判断する？
裁判所がプロジェクトマネジメント義務違反の有無を判断する際は、開発が遅延・頓挫したという結果だけでなく、プロジェクトの進行中にベンダーとユーザーがどのように対応していたかが問題になります。
ここでは、裁判所がプロジェクトマネジメント義務を判断する際に確認する主なポイントについて説明します。
進捗状況を適切に把握・管理していたか
裁判所は、ベンダーが工程ごとの進捗を把握し、予定と実績のずれを確認していたかを検討します。
作業が遅れている場合は、その原因や後続工程、納期への影響まで確認していたかがポイントです。
進捗を確認するだけでなく、状況に応じて工程を見直すなど、必要な管理を行っていたかも判断材料になります。
問題や遅延の兆候を把握した後に対応したか
仕様の未確定や作業の遅れなどを把握した後、ベンダーが問題を放置せずに対応していたかも確認されます。
問題が分かった時点で原因や開発への影響を整理し、必要な対応を取っていたかがポイントです。
問題を認識しながら対応せず、後続工程まで遅れた場合には、その対応が適切だったかが問われることがあります。
ユーザーに必要な情報や注意喚起を伝えたか
ベンダーが開発上の問題やリスクについて、ユーザーが判断できるように必要な情報を伝えていたかも確認されます。
ユーザーの対応が必要な場合は、何を決める必要があるのか、対応が遅れるとどのような影響があるのかを具体的に説明することが大切です。
問題を把握していても十分な情報を伝えていなければ、適切な注意喚起を行っていたかが問われることがあります。
追加・変更要求による納期や費用への影響を説明したか
ユーザーから仕様の追加や変更を求められた場合は、ベンダーが作業量や工程への影響を確認し、納期や費用の変化を説明していたかも検討されます。
追加・変更要求をそのまま受け入れるのではなく、必要な作業や既存工程への影響を整理して伝えることが大切です。
影響を把握しながら説明せずに作業を続けた場合には、ベンダーの対応が適切だったかが問われることがあります。
ユーザー側の協力不足が開発遅延に影響していないか
開発が遅れた場合は、ユーザーが必要な情報提供や仕様の確定、意思決定を期限までに行っていたかも確認されることがあります。
ユーザーの回答や判断が遅れ、ベンダーが次の作業へ進めなかった場合は、それが工程や納期にどの程度影響したかがポイントです。
そのため、遅延という結果だけでなく、ユーザー側の対応との関係も含めて判断されます。
裁判例から分かるプロジェクトマネジメント義務の判断ポイント
プロジェクトマネジメント義務について裁判例を確認すると、開発が予定どおり完了したかという結果だけでなく、問題が生じるまでの経緯や、その後にベンダーが取った対応も重要な判断材料になります。
ここでは、裁判例から読み取れるプロジェクトマネジメント義務の主な判断ポイントについて説明します。
単に納期に遅れたことだけで義務違反とは限らない
システム開発が納期までに完了しなかったとしても、その事実だけでプロジェクトマネジメント義務違反になるとは限りません。
裁判では、遅延の原因だけでなく、ベンダーが進捗を確認し、問題を把握した段階で必要な対応を取っていたかも確認されます。
そのため、遅延という結果だけではなく、そこに至るまでの経緯や対応を踏まえて判断されます。
開発中の問題を認識した後の対応が重要になる
ベンダーが開発中の問題を認識した場合は、その後にどのような対応を取ったかが重要になります。
問題の原因や開発への影響を確認し、対応方法を検討したうえで、必要な措置を取っていたかが判断のポイントです。
問題を把握しながら対応せず、遅延や作業の停滞が広がった場合には、その対応が適切だったかが問われることがあります。
専門家として予見できた問題への対応が問われる
ベンダーにはシステム開発の専門家として、知識や経験から予測できる問題に対応することが求められる場合があります。
問題が起こる可能性を把握できた場合は、開発への影響を確認し、必要に応じてユーザーへ説明や注意喚起を行うことが大切です。
そのため、問題が起きた後だけでなく、事前に予測して必要な対応を取っていたかも確認されます。
ベンダーとユーザーの双方の対応を踏まえて判断される
プロジェクトマネジメント義務違反は、ベンダー側の対応だけで判断されるとは限りません。
裁判では、ベンダーの進捗管理や問題への対応に加えて、ユーザーが必要な情報提供や仕様の確定、意思決定を行っていたかも確認されます。
そのため、双方がどのように対応していたのかを整理し、遅延や頓挫との関係を踏まえて判断されます。
プロジェクトマネジメント義務とユーザーの協力義務の関係
システム開発の遅延やトラブルについて責任を判断する際は、ベンダーのプロジェクトマネジメント義務だけでなく、ユーザーが必要な協力を行っていたかも確認されます。
ここでは、プロジェクトマネジメント義務とユーザーの協力義務の関係について説明します。
ベンダー側の義務だけで判断されるわけではない
システム開発の遅延や頓挫については、ベンダーがプロジェクトマネジメント義務を果たしていたかだけでなく、ユーザーが必要な協力を行っていたかも確認されます。
ベンダーが情報提供や判断を求めても、ユーザーの対応が遅れれば、予定していた工程を進められないことがあります。
そのため、双方が必要な対応を行っていたかを踏まえて責任が判断されます。
ユーザー側の情報提供や意思決定が遅延に影響する場合
ユーザーから必要な情報が提供されなかったり、仕様に関する判断が遅れたりすると、ベンダーが次の工程へ進めない場合があります。
裁判では、ユーザーに何が求められ、いつ対応したのかを確認し、その遅れが開発に与えた影響を検討します。
ユーザー側の対応が原因で工程が後ろ倒しになった場合は、開発遅延との関係も判断材料になります。
双方の行為が損害や開発遅延にどう影響したかが重要
ベンダーとユーザーの双方に問題がある場合は、それぞれの行為が開発遅延や損害にどのように影響したかが確認されます。
たとえば、ベンダーの進捗管理や注意喚起が不十分で、ユーザー側の情報提供や意思決定にも遅れがあった場合は、双方の対応と結果との関係が検討されます。
そのため、どちらか一方だけでなく、開発中の経緯を踏まえて責任が判断されます。
裁判例から見るプロジェクトマネジメント義務の実務上の判断ポイント
裁判例で示された考え方を実務に生かすには、開発中にどのような管理や情報共有を行うべきかを具体的な行動に落とし込むことが大切です。
ここでは、裁判例を踏まえ、システム開発の現場で確認しておきたいプロジェクトマネジメント義務の実務上のポイントを説明します。
進捗・課題・リスクを記録して共有する
ベンダーは、各工程の進捗や課題、今後想定されるリスクを記録し、ユーザーと共有することが大切です。
予定より作業が遅れている場合は、その原因や後続工程への影響も整理して伝えます。
議事録や進捗報告書に内容と日時を残しておけば、いつ問題を把握し、どのような情報を共有したのかを後から確認できます。
追加要望や仕様変更による影響を具体的に伝える
ユーザーから追加要望や仕様変更を受けた場合は、必要な作業を確認し、納期や費用への影響を具体的に伝えることが大切です。
作業が増える場合は、どの工程に影響し、当初の納期や費用からどのように変わるのかを整理して説明します。
そのうえでユーザーの判断を求め、変更内容や条件を確認してから作業を進めましょう。
問題発生時の対応方針と期限を明確にする
開発中に問題が発生した場合は、内容や影響を確認したうえで、対応方針と期限を明確にします。
誰が何を担当し、いつまでに対応するのかを決め、関係者で共有しておくことが大切です。
期限までに解決できない場合は、後続工程への影響を確認し、必要に応じて対応方針や期限を見直します。
ユーザーの判断や協力が必要な事項を明確にする
ユーザーの判断や協力が必要な場合は、求める対応と期限を分かりやすく伝えることが大切です。
仕様の確定や情報提供が必要であれば、何をいつまでに回答・提供してほしいのかを具体的に示します。
対応が遅れた場合に止まる工程や納期への影響も伝えておくと、ユーザー側も必要な対応を判断しやすくなります。
まとめ
プロジェクトマネジメント義務では、開発が遅延・頓挫したという結果だけでなく、ベンダーが進捗や課題を把握し、必要な説明や対応を行っていたかが重要になります。
また、システム開発にはユーザーの協力も欠かせないため、情報提供や意思決定など、双方の対応を踏まえて考えることが大切です。
トラブルを防ぐためにも、日頃から進捗や課題を共有し、仕様変更による影響や対応方針、判断が必要な事項を記録しておきましょう。
ベンダーとユーザーが状況を確認しながら進めることで、問題が起きたときにも対応しやすくなり、プロジェクトをより円滑に進めやすくなります。