【資格更新に:4学習ポイント映像型eラーニング】
・本セミナーの映像型eラーニングを受講いただけます。有資格者の方は資格更新ポイントも発行しています。ぜひ以下のボタンから詳細をご確認ください。
今回のオンラインセミナーも、多数のお申込みをいただき、満員御礼での開催となりました。引き続き、皆様方のご支援の程、心よりお願い申し上げます。
●18:30-18:35 開会ご挨拶
●18:35-20:15 講演:松島総合法律事務所 弁護士 松島淳也 氏
●20:15-20:30 閉会ご挨拶
ベンダーのプロジェクトマネジメント義務とユーザの協力義務 セミナー
システム開発の経験を活かし、弁護士としてご活躍されている松島様にお越しいただき、
ベンダー、ユーザーそれぞれの視点から実例を交えお話しいただきました。
本記事ではその概略をレポートいたします。
<講演項目>
1.プロジェクトが中途で頓挫した場合の攻防
2.プロジェクト・マネジメント義務とは
3.プロジェクト・マネジメント義務違反の類型
4.協力義務とは
5.裁判例に見るプロジェクト・マネジメント義務と仕様変更の関係
(1)東京地裁平成16年3月10日判決
(2)東京高裁平成26年1月15日判決
(3)札幌高裁平成29年8月31日判決
6.まとめ
<1>プロジェクト・マネジメント義務とは
まずはじめに、プロジェクト・マネジメント義務について、裁判例を用いてご説明頂きました。プロジェクト・マネジメント義務が問題となる場面を整理してみると以下が挙げられます。
①企画・提案段階での説明義務違反の問題類型
-パッケージソフトの事前検証
-データ移行の事前検証
-見積額の説明
②契約締結後の問題類型
-進捗管理(従業員管理)ができていない
-追加開発(仕様変更・機能追加)が不適切
-中止提言義務の不履行
ではプロジェクト・マネジメント義務に対応すべき部署はどこになるのでしょうか。
参考として以下が挙げられます。
①進捗管理(従業員管理)、追加開発(仕様変更・機能追加)、パッケージソフトやデータ移行の事前検証
→開発部門(PM)が対応
②見積額の説明
→開発部門(PM)のみならず営業部門も対応
③中止提言義務
→プロジェクトを中止するか否かの判断であり、取締役の責任等の問題となり得る。
<2>ユーザの協力義務とは?
つづいて、ユーザの協力義務について、裁判例を用いてご説明頂きました。
判例1:委託者の協力義務(東京地裁平成16年3月10日判決)
判例2:委託者の協力義務(東京地裁八王子支部平成15年11月5日判決)
<3>裁判例に見るプロジェクト・マネジメント義務と仕様変更の関係
次に、仕様変更のご説明と、なぜ仕様変更が問題になるのか、具体的に3つの裁判例を元にご説明頂きました。
判例1:東京地裁平成16年3月10日判決
判例2:東京高裁平成26年1月15日判決
判例3:札幌高裁平成29年8月31日判決
<4>最後に
最後にまとめとして、6つの重要なポイントをお伝えいただきました。
(1)仕様の確定作業を忘れずに実施する。
(2)面倒でも変更管理はしっかりと行う。
(3)ベンダに要求されるのは、ユーザの要望に全て応える能力ではなく、ユーザの要望を交通整理(二次開発にまわす、要望を撤回させる等)するコミュニケーション能力である。
(4)ベンダは、リスクの説明やユーザの要望を拒否する義務を負う場合もある。
(5)工程が進むにつれてユーザの責任が増大する。
(6)ベンダのエンジニアが交渉が苦手であれば、営業部門の助けを借りることも必要。
今回学んだスキルが、ご参加くださった皆様の日々の業務のお役に立てば幸いです。次回のセミナーは2023年9月に開催予定です。引き続き、弊会のセミナーへご参加くださいますようお願い申し上げます。
・契約締結前でもリスクを説明する義務があることを学べ、また実際の凡例をお聞きできたのが非常に良かったです。
・現在とても興味を持っている内容でしたので非常に有意義な時間でした。ありがとうございました。
・具体的凡例事例や、実際の現場で気を付けなければならないことが聞け、参考に訴訟の問題など今まであまり意識していない部分がありました。仕様変更もユーザーの言いなりになっていた場面も多くありましたが今後は慎重に判断をしたいと思います。
・実際にこれまでも体験したトラブルやアクシデントに対しての具体的な対応や考え方が、事例もわかりやすくご説明頂き、法制度ももっと知識が必要だと再認識することが出来て大変有意義な時間を過ごせました
・具体的な裁判事例を通して、システム開発のマネジメントについて、わかりやすくまとめられていた。私自身は何でも受け入れるかもしれない、自分だったらどのようにして裁判沙汰にならないようにするか、と考えられた。