ITエンジニアが裁判例から学べる教訓 第3回「プロジェクト・マネジメント義務-仕様変更要望」​


前回(第2回)に引き続き、ユーザーからの仕様変更要望に関する裁判例をみていきたいと思います。まずは下記の裁判例をみてみましょう。

■東京地判平成25年11月12日判タ1406号334頁

あるスポーツの団体が、チケット販売のプラットフォームとなるシステムを開発することにしました。このプロジェクトは、要件定義と基本設計が完了して、詳細設計からテストまでの個別契約(開発契約)が締結されたところでスケジュール通り進まなくなってしまいました。開発契約の作業期間は3ヶ月半とされていたのですが、納期までにシステムは完成せず、一度納期の延長をしたにもかかわらず、その延長した納期にも間に合わず、最初の納期から半年が経ったところでようやくシステムは完成しました。

納期までに契約で定められた仕事を完成できなかったのですから、ベンダーは債務不履行責任を負うことになります(このように期限までに義務を果たせなかったことを「履行遅滞」といいます)。

しかし、ベンダーは、納期までに成果物を納入できなかったのは、発注者による仕様確定の遅延や度重なる仕様変更があったことなどが原因であるとして、ベンダーには帰責性がないと主張しました。

裁判所は、「システムの設計・開発業務の受注者として、本件システムの仕様を確定するにあたって、各仕様の項目について注文者から十分にヒアリングを行った上、納期までの開発の段取りを決定して詳細スケジュールを確定し、その進捗状況を管理しながら開発を進める義務を負っていた」としました。

その上で、「(開発契約では)開発の途中で仕様の変更追加の申出がされることも前提とされていたのであり、発注者から仕様の変更追加の申出があった際に、それによってスケジュールに遅延をもたらす場合にはその旨説明するなどして発注者と協議し、その都度納期を見直すなどした上で、最終的に決められた納期に間に合うように仕様を確定させていく義務」がベンダーにはあるとしました。

そして、ベンダーが上記のような義務を十分果たしたとはいえないとして、履行遅滞について、ベンダーに帰責性がないとはいえないと判断しました。

ベンダーが負うべき義務

少しラフにまとめると、上記判決では、ベンダーは、以下のような義務を負っているとしています。

  1. ベンダーは開発の進捗状況を管理しなくてはならない

  2. 変更要望があった場合、ユーザーにスケジュールへの影響を説明し、協議をしなければならない

  3. 変更要望に応じていたのでは納期に間に合わないようであれば、リスケも検討・提案し、ユーザーと合意した納期に間に合うように仕様を確定させなければならない

仕様変更要望があった場合、ベンダーとしてはまずユーザーにリスクを説明して、本当に変更すべきかを協議すべきであり(2)、仕様変更を受け入れると納期に間に合わないようであればリスケも検討して、合意した納期に間に合うようにすべき(納期に間に合わないようなら納期を遅らせることをユーザーに認めてもらうべき)(3)ということです。

ユーザーはお客様であり、多少無理な要望であっても受け入れる必要もあるのだから、協議を申し出たり、リスケをお願いしたりするのは難しいかもしれません。ただ、この判決のいわんとしていることは、きちんとリスクをユーザーに説明して、リスクを分かった上でユーザーに判断してもらうべきと理解することができ、当然といえば当然といえます。

*ただし、本件は元請業者と下請業者との争いであり、下請業者側の説明責任の程度は軽くてもよいのではないかという疑問はあります。

ユーザーが適切に意思決定できるようにすべき

プロジェクトのオーナーはユーザーなのですから、プロジェクトをどのようにするかは究極的にはユーザーが決めるべきことです。ただ、ユーザーはベンダーと比べて専門知識や経験に乏しく、自分で判断するのは難しい場合が多いといえます。そうであれば、ベンダーはきちんとユーザーに説明をすべきであり、ユーザーが状況を理解した上で、意思決定をすることができていたのかが重要であるということになります。上記の裁判例はそのように理解することができると思います。どのように意思決定がなされていたのかに注目して判断をした事例として、下記の裁判例があります。

■東京地判平成25年12月19日公刊物未登載(West Law Japan)

就職活動の支援サイトの構築のプロジェクトで、やはり度重なる変更要望により作業が遅延したという事案です。

このプロジェクトでは、変更管理のために、ベンダーとユーザーの担当者から構成されるCCB(Control Changing Board :変更管理委員会の略)という組織が置かれ、ベンダーの作成した変更管理表がCCBの構成員全員にメーリングリストで共有され、CCB構成員全員が出席する重要課題検討会議で変更管理を検討するという体制が組まれていました。そして、重要課題検討会議では、度重なる変更要望への対応のため作業が遅延しているとの報告がベンダーからなされていました。

判決は、「原告(注:ベンダー)は、被告(注:ユーザー)からの度重なる変更要請への対応のために作業が遅延していることを会議の席上で被告に伝えていたにもかかわらず、被告の従業員を含むCCBの構成員全員の判断により、作業内容が決定されていたのであって、それ以上に、原告の立場で、スケジュールを遵守するため作業内容の変更を行わないように依頼者である被告を説得すべき義務までを負うとは解されない」としています。

また、実際には、CCBとしての会議は(重要課題検討会議とは別に)開催されていませんでしたが、判決は、「変更管理表がCCBの構成員全員の参加するメーリングリストに投稿され、また、CCBの構成員全員が参加する重要課題検討会議の場において、変更管理について検討されていたことからすれば、形式的にCCBの会議を開催しなかったことをもって、プロジェクト・マネジメント義務違反と評価することはできない」としています。

CCBや重要課題検討会議といった組織によってプロジェクトが運営されていたという事案であり、ユーザーに十分な情報が提供されており、おそらくユーザーも十分な能力を持っていたと思われることから、ベンダーはユーザーを説得する義務まではないというのは妥当な結論だと思います。東京地判平成25年12月19日のプロジェクトは、数億円規模の比較的大きいものであり、このプロジェクトほどの体制を組めないという場合も多いと思います。ただ、○○委員会というような組織を作ることそのものが重要なのではなく、ユーザーがリスクを認識した上で、それでも仕様変更をすべきと判断していたのかという実質面こそが重要です。

ベンダー担当者の方は、そのような手続を踏めているか(また、そのような説明をしたことを文書で証拠として残せているか)、ユーザー担当者の方は、ベンダーから説明を受けた以上、自身の責任で判断するという自覚を持てているかを見直してみてはいかがでしょうか。

参考文献 「裁判例から考えるシステム開発紛争の法律実務」(共著)(商事法務、2017)

*今回取り上げた東京地判平成25年11月12日判タ1406号334頁については、参考文献の101頁、東京地判平成25年12月19日については、参考文献の103頁にて取り上げています。

特集記事
最新記事
アーカイブ
タグから検索
ソーシャルメディア
  • Facebook Basic Square

© 2016-2020 ILRI