大規模システム開発訴訟にみる「仕様凍結」

ＩＴ判例

　旭川医大×ＮＴＴ東の訴訟（第一審：旭川地判平成28年3月29日、控訴審：札幌高判平成29年8月31日）は、スルガ銀行×日本ＩＢＭの訴訟に次ぐ、典型的な大規模システム開発訴訟でしたが、控訴審でのベンダ（ＮＴＴ東）の逆転勝訴（約１４億円の請求認容）という形で決着しました。主な争点はベンダのプロジェクトマネジメント義務とユーザの協力義務でしたが、その背景には仕様凍結の問題がありました。本稿では、この点に注目してみます。

「仕様凍結」合意の意義

　本事案では、開発の早い段階で「仕様凍結」の合意がなされましたが、その意義については争いがありました。旭川医大は、要件定義書等の提出がなかった段階で画面等に関わる要望までが許されなくなるものではないと主張しましたが、判決は「技術仕様書によって開発対象が基本的には明確になっていた」というかなり微妙な判断の下、以下のようにＮＴＴ東の主張に沿った認定をしました。

本件仕様凍結合意が、開発対象を確定し、以後、ユーザは、ベンダに対し、新たな機能の開発要望はもちろん、画面や帳票、操作性に関わるものも含め、一切の追加開発要望を出さないとの合意（一般的な意味での「仕様凍結」 の合意）を意味すると見るのが相当である……。

　本事案では、両者とも上記の意味を前提とした言動があったという事情もありましたが、仕様凍結はユーザの関心事である外部仕様を（たとえユーザに不満な点が残るとしても、プロジェクト進行のためにあえて）確定したものとして扱うことに狙いがあるわけですから、この結論自体は判決が述べるように「一般的な意味」どおりと言えます。
　もっとも、個々の事案では、開発プロジェクトの状況により、「一般的な意味」から離れた「合意」がなされることも少なくありません。実際、今回の旭川医大の主張に近い認定がなされたこともあります。

ユーザの委託の趣旨が、当初仕様である基本機能設計書に示された処理機能……に変更を加えるものである場合には、原則として仕様変更に該当し、……。もっとも、ソフトウエア開発においては、その性質上、外部設計の段階で画面に文字を表示する書体やボタンの配置などの詳細までが決定されるものではなく、詳細については、仕様確定後でも、当事者間の打合せによりある程度修正が加えられるのが通常であることに鑑みると、このような仕様の詳細化の要求までも仕様変更とすることは相当でないというべきである。（大阪地判平成14年8月29日）

　本事案でも、仕様凍結後にユーザの指摘を受けて一定の修正がなされた事実はありましたが、「ユーザによる追加開発要望をベンダが拒否し切れなかったというにとどまり」と例外扱いされています。現実には、凍結後にも大なり小なりの要求が出され、それらのうち比較的小さなもにについては要求が容れられてしまうことが普通です。仕様凍結とはその限度のことをいうのか、それは例外と見るのかは、実際には微妙なところがあります。ただ、たとえ操作性等の細かな要求でも、既にそのレベルでの確定仕様があって、それを変更することになる場合は、許されないとするのが有力な考え方でしょう。

仕様凍結後の追加変更の取扱い

　仕様凍結後の追加変更の取扱いは、必ずしも（全ての）遮断と（軽微なものの）許容の二者択一ではありません。したがって、後の追加変更をどのように取り扱う予定としていたのかも、「合意」の内容として重要です。本事案でも、仕様凍結後の追加要望は遮断するものの、それまでに出されていた（ＮＴＴ東から見れば既に過剰な）一定の追加開発を取り込むことと引換えとする合意でした。この点では、かなりのバリエーションがあります。
　例えば、対応の有無や時期について、ある時期までペンディングにするのみ（作業が進んだ時点で再考する余地を残す）、最終的には当初のスケジュール内で（あるいは若干遅らせて）対応する、二次開発として対応する、確定的に対応しない、といったバリエーションがあり得ます。これと合わせて、費用その他の条件も問題となりますが、当初スケジュール内の対応であればむしろそちらに主眼がありますし、二次開発であれば費用は当然に別途ということになります。実際、ひとまずペンディングにするだけといった、「凍結」のニュアンスから外れる例は少なあらずあり、注意が必要です。以下の裁判例も、まさにそのような場合です。

ここで「凍結」といわれているのは、「確定」と同義とは解し難い。このことは、上記システム連絡会議において、凍結後にも仕様の追加変更があり得るものとされていることからも明かであり、凍結とは、基本設計書に盛り込む内容を決定するために、その時点における到達点をもって仮の結論とし、最終結論は別途検討する余地を残すことを意味するものと解するのが相当である。（東京地判平成16年3月10日）

　そもそも「凍結」は「確定」以上に、後の追加変更を遮断したい（既に出ている追加変更も遮断したい）場合に用いるのが通常でしょうから、名称に囚われるとむしろ誤解を招くと言えそうです。いずれにしても、実務で仕様凍結の話となった場合は常に、その後の追加変更の対応範囲、対応時期、費用その他の条件とセットで合意内容を十分に確認しておくべきでしょう。

仕様凍結とプロジェクトマネジメント義務

　本事案では、「一般的な意味」の仕様凍結合意を前提として、後に１７１項目に及ぶ追加開発要望を出した旭川医大に、協力義務違反が認定されました。

この協力義務は、本件契約上ユーザの責任とされていたもの（マスタの抽出作業など）を円滑に行うというような作為義務はもちろん、本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、ベンダにその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。しかるに、……ユーザが本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、ベンダがこれに対応せざるを得なかったことから、本件システム開発が遅延した。

　他方で、この追加開発要望の取扱いにかかるＮＴＴ東のプロジェクトマネジメント義務については、以下のように（ベンダにとって）非常に「現実的」な判断より義務違反が否定され、これが控訴審での逆転の決定打となりました。

ベンダは、プロジェクトマネジメント義務の履行として、追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で、追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる。これを越えて、ベンダにおいて、納期を守るためには更なる追加開発要望をしないよう注文者（ユーザ）を説得したり、ユーザによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず、ベンダにプロジェクトマネジメント義務の違反があったとは認められない。

　前に引用した平成１６年の事案では、以下のようにベンダに非常に厳しい判断がなされています。この事案では、仕様凍結の位置付けが異なり、いまだ仕様は確定してなかったことを前提にしていることもありますが、その点は本事案でも微妙なところがあったことは、既に述べたとおりです。役割や責任の切り分けが相当に違うことが見て取れます。

本件基本設計書により機能が確定したと認められない以上、その後の作業は実質的には基本設計作業に当たる内容を含むものであったということができるところ、ユーザーであるユーザがベンダに対し、基本設計作業中に構築するシステムに関する様々な要求をするのは、本件のようなシステム開発の工程では当然のことであり、しかも、専門的知識のないユーザにおいて、当該要求が追加の委託料や納入期限の延期等を必要とするものであるかどうか、作業工程に支障をもたらすものであるかどうかなどを、的確に判断することは困難であったということができるから、ユーザにおいて、追加の委託料や納入期限の延期等をもたらす要求を自制すべきであったなどということもできない。むしろ、ユーザが追加の委託料や納入期限の延期等を必要とする要求をしたのであれば、プロジェクトマネージメント義務を負うベンダにおいて、ユーザにその旨伝えて、要求の撤回や納入期限の延期等に関する協議を求めるなどし、開発作業に支障が生じないようにすべきであったということができる。（東京地判平成16年3月10日）

　プロジェクトマネジメント義務に関して言えば、スルガ銀行×日本ＩＢＭの控訴審判決が認定した中止進言義務違反も、理屈としてはそのとおりという面があったにせよ、（ベンダにとって）非常に「現実的」でないものでした。パッケージの不適合とユーザ要求の過剰ではユーザ側のリスク認識に違いがあったと思われますが、この種の事案における判断の振幅の大きさには注目すべきものがあります。

カスタマイズ開発におけるテコの原理と仕様凍結

　本事案は、パッケージをベースとするカスタマイズ開発の事案でした。こうした開発では、例えば、当初想定したカスタマイズ率５％が１０％に増加すると、システム全体の規模からすれば僅か５％の増加であるにもかかわらず、開発工数ないしコストは２倍に膨れ上がる、というテコの原理が働きます。仕様凍結後の追加要求の相当部分は当初は標準機能で行くと想定していた部分でしょうから、このテコの原理の影響を直に受けます。
　そのため、カスタマイズ開発では、仕様凍結を徹底し、より厳しい変更管理を行わなければなりません。本事案では、技術仕様書上で「パッケージ標準機能」と分類されていた機能でもカスタマイズは排除されない、との主張が旭川医大からなされていました。機能としては新規に開発するのではなくパッケージ・ベースであるが、仕様レベルでは必要に応じてカスタマイズする、という理屈なのでしょうが、まさにテコの原理が大きく働いてしまう場面です。ユーザの心情としては理解できないものではないとも言えますが、本事案でのユーザに厳しい判断はこうした背景によるのかも知れません。