システム開発プロジェクトにおける経営目標・数値目標の法的意味とは

システム開発プロジェクトは、企業や職場の大規模な業務改善と密接に結びついたものとなる場合も多いものです。そこでは、ユーザー側の企業の経営課題の解決や、数値目標の達成などにむけて貢献する姿勢が求められることもあるでしょう。しかし、こうした経営上の目標にコミットすることは、果たして法律上の義務なのでしょうか。数値目標や経営目標のもつ法的意味がいかなるものであるかが問題となってきます。本記事では、そうしたシステム開発に関する種々の「目的」や「目標」に付随する法律問題について解説していきます。

システム開発の目的や目標が紛争の火種となるのはなぜか

ユーザーの協力義務とベンダーの裁量の狭間に位置する課題だから

商取引のあり方として見た場合、システム開発プロジェクトにはいくつか特色ともいうべき点があります。ひとつは、ベンダーによるシステム開発プロジェクトというもの自体が、ベンダー単独によってなしうるものではなく、ユーザー側からの協力を要する点です。この義務の存在は、「協力義務」という呼称で判例法上も明確なものとなっています。主に、①要件定義②基本設計③成果物の検収などのフェーズで、ユーザーもシステム開発に協力することが求められているのです。

またもうひとつは、ベンダー側に通常、大きな裁量を発揮して業務にあたることが求められる点です。ベンダー側が一連のシステム開発プロジェクトにおいてなすべきことを総括した法律用語として「プロジェクトマネジメント義務」というものがあります。これについては、以下の記事で詳細に解説しています。

以上の内容をまとめると、ここで重要な点を二つ指摘することができます。

• ユーザーは、ベンダーに適宜必要な情報を提供し、ベンダー側の開発業務に協力していくことが実務上求められる。
• ベンダーは、ユーザーにとってのプロジェクトの目的や目標を理解し、それに合致した取り組みを行うことが実務上求められる。

以上の二点の事情により、事前にユーザーからなされた説明のうち、経営目標や数値目標の達成が、法律上どこまでベンダー側の義務となりうるのかという点も問題となるのです。すなわち、ベンダーがなすべきことを（目標などという曖昧なものではなく）仕様にまとめて提示することがユーザーの義務であるという側面もある一方で、ベンダーも専門家として（相手の言われたことを言われたとおりにやっただけで満足するのではなく）ユーザーが本質的に求めるものを提供する義務を負っているという側面もあるのです。このようにして相反する両者の言い分が衝突しあうことが、システム開発の「目標」や「目的」をめぐる紛争の特徴でもあります。また法律という観点からは、両者の公平に資する紛争解決の指針を提示することが、実務上の課題となるのです。

ユーザー側の目標がプロジェクトに影響する具体的場面

システム開発のプロジェクトは、企業や職場の大規模な業務の改善・効率化の施策と結びついている場合も多く、事前の企画・提案段階でも、経営課題や経営目標についてのヒアリングがなされる場合も多いものです。そこでは、システムを開発することに伴う費用対効果についてのやりとりや、さまざまな数値目標を介したやりとりがなされることが考えられます。

• 省力化に伴って削減される人件費
• 売上や収益の増大
• 業務時間の短縮

たとえば上記のような項目がプロジェクトの最終的な目的となっている場合について、ベンダー側は事前にコンサルタントのような立ち位置で、システム開発の投資効果について説明し、営業を行うといったことも考えられます。

ユーザー側の掲げる経営目標が問題となった裁判例とは

しかし、ベンダーは通常、あくまでシステム開発の専門家です。ユーザー側の経営上の目標に対して、すべての責任がのしかかってくるとなればあまりにも酷な話ともなりかねません。

業務のスピードの向上が目標として掲げられていた事案

この件に関連して、以下に引用する判決文の事案では、プロジェクト発足時に作成された企画書に、システム開発プロジェクトを発足させる目的や目標が記されていました。ところが実際にシステムが完成し、運用を開始したところ、その目的や目標を達成することができなかったとし、争いに発展しました。当初の企画書には、システムが完成し実際に活用されるようになって以降、次のような状態を実現することを目指す旨が記されていました。

• 人間による手入力の時間を50%削減すること
• 当該ITシステムを使った事務処理を、所定期間内に完遂させられるようにすること

ユーザーはこれらを結果的に実現できなかったことから、ベンダーに対して債務不履行責任や瑕疵担保責任の追及を試みました。しかしこの主張を裁判所は認めませんでした（下線部、太字は筆者が追記したものである）。

そして、（中略）弁論の全趣旨によれば、①本件目的は「業務の効率アップ」「ＣＲＭの基盤作り」「『見える経営』を行う」など抽象的なものであり、目標値も、「顧客との接点を増やす」「事務職の労力を内部統制・営業支援に振り分ける」「売上予想がより正確にできる」「過度な売上値引を抑制する」など、抽象的なものが多い上、「入力時間を５０％削減する」「見積作成時間を５０％削減する」「法定開示が法定日数内に行える」などという目標値は、SBO導入後の被告の経営管理や業務方法の在り方にかかっているものであって、パッケージソフトウェアの導入を支援するシステム開発会社である原告が，その達成を請け負うことができる性質のものではないこと、②本件プロジェクトのキックオフ後の打合せ議事録には、本件目的や目標値の達成について具体的に話し合った旨の記載がないこと、③本件プロジェクト計画書には、「上場会社になるため」など、それ自体が契約の性質を有するものとはいえない表現が用いられていること、（中略）などの事情を考慮すれば，原告が被告の説明を基に本件プロジェクト計画書において本件目的の記述を作成したのは、本件プロジェクトが失敗しないようにするため、本件プロジェクトの目的と成果について共通認識を得るためのものであったと認められ、被告が、原告に対し、本件目的を達成するためのシステム開発を委託したものとまで認めることはできない。（中略）したがって、原告が被告から本件目的を達成するためのシステム開発を請け負ったものとは認められないから、（中略）債務不履行責任及び瑕疵担保責任の主張はいずれも理由がない。

東京地判平成22年12月28日

裁判例から読み取れる経営目標・数値目標の法的意味とは

本判決でも言及されているように、システム開発の目的や、数値で定量化された目標が達成できるかどうかは、そのシステムを活用するユーザー側の経営努力などの要因が様々が介在するのが通常です。したがってベンダー側の責任とするハードルは非常に高いものであると考えるべきでしょう。そもそも、もしベンダー側の債務不履行責任や瑕疵担保責任が認められるなら、それは「目的」や「目標」の達成が契約内容の一部として織り込まれていたということを意味します。しかしながら本件における「目的」や「目標」は、

• 抽象的で漠然としたものについては、法律上の義務というものの性質に馴染まないため、契約内容の一部であったとみることには無理がある
• ユーザー側の、とりわけ経営サイドの自助努力を要するものについては、ベンダー側のコントロールが及ばないものである以上、ベンダー側に帰責することも失当であり、契約上の義務の一部であったとみることには無理がある

といったような評価を法的に受けることとなりました。

本判決からさらに読み取れること

本判決には他にも、いくつか興味深い内容が含まれています。

• システム開発プロジェクトの「目的」や「目標」を共有するということが、単にユーザーとベンダーで「共通認識」を得るためのコミュニケーションの努力の一環にすぎない可能性があることを裁判所も考慮している点。
• 一連のプロジェクトにおいて、それらの「目的」や「目標」がどれほど本質的な要素であったかを考慮するにあたり、会議の議事録なども参考にしている点。

なお、システム開発プロジェクトに付随する法律問題について、文書管理や議事録の重要性という観点からは、以下の記事で解説を行なっています。

経営目標・数値目標をめぐる法律問題の諸注意

もっとも、こうした「目的」や「目標」をめぐる法律問題については、以下のような補足事項もあわせて押さえておきましょう。

コンサルティングが有償か無償かでも話は変わる

もしシステム開発プロジェクトのみならず、有償でコンサルティング契約まで交わしていたような場合であれば、事情は大きく変わってくる可能性があります。ユーザー側がどれほどの経営資源を有しているかなどを踏まえることなく、実現可能性の乏しい実行計画を策定していたなどの事情があれば、当該有償のコンサルティング契約の部分で債務不履行責任などを追及されることはありうるでしょう。

成果物の瑕疵や、機能や仕様要件の不整合とは別問題

また、もし一連の「開発」プロジェクトそれ自体に瑕疵がある場合、すなわち不具合やバグが成果物に確認されるような場合は、こうした問題とは分けて理解する必要があります。その場合には、経営上の「目的」や「目標」の話はするまでもなく、もっぱら成果物と求められる機能要件や仕様との整合性が問題となります。たとえば、システムに事後的に瑕疵が発覚した場合のユーザー側の対応策は以下の記事で解説しています。

ほかにも関連する話題としては、要件に盛り込まれてはいないものの、ベンダー側の裁量で実装を行う義務があると認められるものもあります。これについては以下の記事で詳細に解説を行なっています。

いずれの場合も、「目的」や「目標」をめぐる紛争とは似て非なるものとして理解すべきものだといえます。

責任や契約といったテーマへの根本的な理解も問われる

以上、システム開発の「目的」や「目標」をめぐる法律問題の解説を行いました。こうした点をめぐる紛争では、裁判所もユーザー・ベンダー相互に足並みを揃えるための取り組みとして、あくまでコミュニケーションの努力の一環として相互に共有がはかられる場合が多い点は十分理解してくれているものと考えられます。もっとも、結論そのものの妥当性は実務者としての現場感覚によっても十分理解できるとしても、そこに至るプロセスでは、「責任」や「契約」といったものへの根本的な理解が問われます。こうした点については、以下の記事にて解説しています。

法律上の責任が、漠然とした道義的な責任とは異なるものであること、両当事者の確たる「意思の合致」が契約上の責任を生じさせるものであることなどを踏まえて、より本質的な理解を得ることが大切であると考えられます。