システム開発の発注者であるユーザー側が負う協力義務とは

システム開発の仕事は、開発されるシステムが大規模であればあるほど、多数の人手や工数をかけて行う必要が出てくるものです。したがってそこでは、開発を引き受けるベンダー側だけでなく、システム開発を発注するユーザーの側にも一定の協力義務が課せられるものです。

これは、通常の受発注関係とは異なるものです。例えばITシステムではなくオーダーメイドのスーツの作成をスーツ屋に頼む場合、発注者である顧客（ユーザー）側は、特に「義務」を負いません。「義務」を負うのは、専ら受注者であるスーツ屋（ベンダー）側です。多数の人手や工数が必要なITシステムだからこそ、ユーザーもベンダーに「協力」する必要がある、という構造です。

本記事では、ベンダー任せでは済まされないシステム開発というものについて、発注者側にどのような法的義務があるかについて解説します。

自社のシステムである以上、すべて「丸投げ」では済まされない

ひとつのシステム開発プロジェクトであっても、そこには多数の人と組織が関与している場合が多いものです。コーディング技術に長けたエンジニア・プログラマはもちろんのこと、そうした人員のアウトプットを一つの成果にまとめあげるためには、プロジェクトマネージャーの役割も重要になります。

しかし、ベンダー側がどれだけ高い技術力と組織力をもってしても、ベンダー側だけの力でシステム開発がやり遂げられるわけではありません。たとえば、その会社内部でのみ用いられる社内用語や、その会社に固有の業務知識といったものについては、ベンダー側のみの一方通行の努力では知る由もありません。大規模なシステムの開発であればあるほど、一般的な傾向として、そのシステムが活用される会社自体も多数の人と業務を抱えた大企業であることが多いものです。システムを開発のプロジェクトの成功に導くためには、実はパソコン仕事以前に、こうしたビジネスロジックの整理こそが大きなウェイトを占めている場合も多いものなのです。

したがって、ユーザー側も「自分はIT技術の専門家ではないから」という理由で受け身になるのではなく、むしろ積極的に情報提供を行うことで、プロジェクトの進行がスムーズにいくことがあるのです。この意味では、システム開発プロジェクトにおいてユーザー側が負っている役割というのは、実は決して小さなものではないのです。

判例を踏まえたユーザー側の協力義務とは

では具体的に、システム開発プロジェクトにおいて、ユーザーの側が負っている協力義務とはどのようなものでしょうか。この点については、過去の判例に多くのヒントが残されています。

裁判では、ベンダー側（被告）の納期が遅れた件について、ユーザー（原告）の意思決定の遅延等があったことから、ユーザーの開発に対する協力義務の有無が争点となりました。この件につき裁判所は、ユーザー側の協力義務違反をみとめ、ベンダー側の債務不履行責任を否定しました。（契約の解除に関しては認められたものの、こちらも六割の過失相殺が認められました。）

本件電算システム開発契約は，いわゆるオーダーメイドのシステム開発契約であるところ，このようなオーダーメイドのシステム開発契約では，受託者（ベンダー）のみではシステムを完成させることはできないのであって，委託者（ユーザー）が開発過程において，内部の意見調整を的確に行って見解を統一した上，どのような機能を要望するのかを明確に受託者に伝え，受託者とともに，要望する機能について検討して，最終的に機能を決定し，さらに，画面や帳票を決定し，成果物の検収をするなどの役割を分担することが必要である。

東京地裁平成１６年３月１０日判決

本判決は、システム開発それ自体がユーザー側との共同作業である旨を判示するのみならず、「具体的にどのような点において協働すべきなのか」という点について言明している点が、非常に示唆に富んでいるように思われます。

試みに上記判決文の文言を、システム開発のIT用語に翻訳してみましょう。

といった具合に整理することができます。これらはいずれも、ITシステムに対する専門性がどれほど高度であろうとも、ユーザーの協力なしに単独になしうるものではありません。求めている機能や、画面のレイアウトがどのようなものであるかは基本的にユーザーが明確化すべきものであり、また求めたとおりのものが実現されているか否かもユーザーにしか確認することはできないからです。 　

なお、ベンダーにプロジェクトマネジメント義務が課せられているのと同じように、ユーザーにも協力義務が課せられていることからすれば、ユーザーが上記のようなプロセスで協力義務違反を働ければ、逆にベンダーからユーザーに債務不履行や不法行為に基づく損害賠償請求を行われてしまう可能性もあると考えられます。

事後の仕様変更のリクエストはどのように解されるのか

また、システム開発プロジェクトがユーザーとベンダーの共同作業である点を前提とすれば、ここからさらに発展的な議論へと話は進んでいきます。それは、「ユーザーが事後的に、機能の追加や修正を依頼し、それによって納期のクリアが困難となったような場合は、はたして誰の責任になるのか」といった問題です。

システム開発は一般的に、要件定義に始まり、基本設計・詳細設計・製造（プログラム実装）・テストといった順序で、極力手戻りが起きることがないように進めていくことを目指すものです（一般的にウォーターフォールモデルと呼ばれる）。しかしなにかしらの事情により、前工程に不備があることが発覚すると、なにかと工程に手戻りが発生するということも、現実にたびたび起きるものです。

こうした事案において、納期に間に合わなかった場合はどのように考えるのでしょうか。過去の判例を読み解くに、追加作業が発生したタイミングによって結論に差異があるものと見受けられます。

追加作業が外部設計等の仕様の明確化より前であった場合

前掲の判例は、基本設計中（プログラム実装段階よりも前）にユーザーから受けた追加開発の依頼があった点につき、そうした要望をあげること自体は、とくに協力義務違反にあたるわけではない旨も同時に示しています。

ユーザーがベンダーに対し，基本設計作業中に構築するシステムに関する様々な要求をするのは，本件のようなシステム開発の工程では当然のことであり，しかも，専門的知識のない原告ユーザーにおいて，当該要求が追加の委託料や納入期限の延期等を必要とするものであるかどうか，作業工程に支障をもたらすものであるかどうかなどを，的確に判断することは困難であったということができるから，原告ユーザーにおいて，追加の委託料や納入期限の延期等をもたらす要求を自制すべきであったなどということもできない。むしろ，原告ユーザーが追加の委託料や納入期限の延期等を必要とする要求をしたのであれば，プロジェクトマネージメント義務を負う被告において，原告ユーザーにその旨伝えて，要求の撤回や納入期限の延期等に関する協議を求めるなどし，開発作業に支障が生じないようにすべきであったということができる。

東京地裁平成１６年３月１０日判決

当該判決では、ユーザー側にも一定の協力義務があることを肯定するとともに、決してユーザー自身はシステム開発の専門家ではない点を斟酌すべき旨が判示されました。すなわち、発注するユーザーはシステム開発の専門家でもない以上、開発するシステムの内容が明確になるまでの期間は、（場合によったら発注することにさえ慣れておらず）小出しにバラバラと注文をつけてくることだってあっておかしくないし、ましてその注文内容が納入期限などの見直しを要する場合に「そのことに自力で気がつくべき」などというのは酷だという話だと考えられます。

もっとも、ここでのベンダーの側に課せられている義務とは、つまるところ納期の延期等を要望したり（もしくは、納期を動かせないなら、追加の要求そのものを取り下げるように提案したり）といったコミュニケーションの努力を指すものと考えられます。したがって、ユーザーの要求をすべて受け入れたうえで、当初の期日通りに納品することまですべて義務として含んでるという意味ではないと考えられるので、この点には注意が必要でしょう。

追加作業が製造やテスト工程の仕様確定よりも後であった場合

上記の判決の内容を裏返せば、仕様をすでに確定し終えた場合の追加開発であればどんな結論となっていたかも同時にある程度予測することができます。その場合には、こうした要求は通りにくくなるでしょう。たしかに、ユーザー側とベンダー側で、開発業務に対する理解度が大きく開きがあるという点は、仕様確定の前だろうが後だろうが変わるものではありません。

しかし、仕様が確定した後に注文内容を変えたり追加したりすることは、作業のやり直しを強いる可能性が高いものです。こうした場合にまで発生した納期遅延について、「お客さんなのだからあれこれ要望をあげるのは当然」と擁護するのは苦しい場合が多いでしょう。さらには、多くの仕様変更や機能追加が事後で発生するといった事態は、そもそも事前にすでに完了していたはずの基本設計等の上流工程でもユーザー側の協力義務違反があったのではないかという疑問をも生じさせるものです。

こうした点からも、仕様が一度確定した後に行った仕様変更については、それが原因の納期遅延をベンダー側の責任とすることは現実的ではないと考えられます。前掲の判決文からは、そういった意味合いも同時に読み取るのが妥当といったところでしょう。

また、こうした判断は、契約書だけではなく、システム開発の進捗に合わせた議事録なども証拠として行われる傾向があります。議事録に関しては下記記事にて詳細に解説しています。

関連記事：法律的観点からみたシステム開発における議事録の残し方とは

まとめ：要件定義がユーザーの側のプロセスであることを忘れないことが大切

要件定義はベンダー側の腕の見せ所である反面、そもそもはユーザーの側の業務であるということを意識しておくべきでしょう。それが自社で用いるシステムである以上、たとえ外部の専門家の力を借りて作り上げるのだとしても、前提として自社のガバナンスが及んでいてしかるべき領域であると法律上は考えられます。

ユーザー側が開発工程に協力的でない場合には、たとえプロジェクトが炎上しようとも、裁判所はユーザー側にも厳しい見解を示してくる可能性が大いにあるのだという点を、まずは認識しておくべきでしょう。