平成２６年９月１１日判決言渡同日原本領収裁判所書記官平成２３年（ワ）第１７４２号，同第２３２９０号請負代金等請求本訴，損害賠償請求反訴事件口頭弁論の終結の日平成２６年７月１日判決金沢市＜以下略＞原告・反訴被告株式会社リンクネット（以下「原告」という。）同訴訟代理人弁護士内田清隆久保田 康 宏同訴訟復代理人弁護士渡辺数磨東京都台東区＜以下略＞被告・反訴原告クレヨンソフト株式会社（以下「被告」という。）同訴訟代理人弁護士木戸伸一主文 １ 被告は，原告に対し，１５９万２６６７円及びこれに対する平成２２年６月１日から支払済みまで年６分の割合による金員を支払え。 ２ 原告の主位的請求及びその余の予備的請求並びに被告の反訴請求をいずれも棄却する。 ３ 訴訟費用は，本訴反訴を通じてこれを５分し，その２を原告の負担とし，その余を被告の負担とする。 ４ この判決は，第１項に限り，仮に執行することができる。 事実 及び理由第１ 請求 １ 本訴 被告は，原告に対し，６９２万１８５７円及びこれに対する平成２２年６月１日から支払済みまで年６分の割合による金員を支払え。 ２ 反訴原告は，被告に対し，６６５万５６９１円及びこれに対する平成２３年２月１日から支払済みまで年５分の割合による金員を支払え。 第２ 事案の概要本件は，原告が被告か え。 ２ 反訴原告は，被告に対し，６６５万５６９１円及びこれに対する平成２３年２月１日から支払済みまで年５分の割合による金員を支払え。 第２ 事案の概要本件は，原告が被告から請け負ったコンピュータープログラムの開発に関し，本訴において，原告が，被告に対し，主位的に，被告の責めに帰すべき事由により原告の債務が履行不能になったと主張して，民法５３６条２項前段に基づき，請負代金６９２万１８５７円（当初の請負代金３０４万５０００円とその後の増額分３８７万６８５７円の合計額）及びこれに対する上記プログラム成果物の引渡し後である平成２２年６月１日から支払済みまで商事法定利率年６分の割合による遅延損害金の支払を，予備的に，信義則又は民法６４１条に基づき，出来高分の報酬相当額又は損害賠償金４０１万４２１４円及びこれに対する上記と同様の遅延損害金の支払を求め反訴において，被告が，原告に対し，原告の債務の不完全履行があったと主張して，民法４１５条に基づき，損害金６６５万５６９１円及びこれに対する弁済期（納期）の後である平成２３年２月１日から支払済みまで民法所定の年５分の割合による遅延損害金の支払を求める事案である。 １ 前提事実（当事者間に争いがないか，後掲の証拠及び弁論の全趣旨により容易に認めることができる事実） 原告及び被告は，いずれもコンピュータープログラムの作成などを業とする株式会社である。 原告は，平成２２年１月１５日，被告との間で，業務委託基本契約を締結した上，被告が原告に対して，「警視庁向けＬＰシミュレーションソフト」なるコンピュータープログラム（以下「本件プログラム」という。）の開発 を，契約金額を３０４万５０００円（消費税１４万５０００円を含む。），納期を平成２２年３月１５日 ミュレーションソフト」なるコンピュータープログラム（以下「本件プログラム」という。）の開発 を，契約金額を３０４万５０００円（消費税１４万５０００円を含む。），納期を平成２２年３月１５日に被告にて受け入れテスト開始，同月３１日に被告にて検収完了，代金支払方法を同年４月３０日銀行振込とする内容で委託する旨の請負契約（以下「本件契約」という。）を締結した。これにつき作成された「個別契約書」（甲２。以下「本件契約書」という。）７条２項には，瑕疵から派生した二次的損害については，原告は保証しなくてよいものとする旨の定めがある。 本件プログラムは，明治安田ライフプランセンター株式会社（以下「訴外会社」という。）が警察職員生活協同組合警視庁支部向けにライフプラン支援を行うためのもので，①必要保障額算出，②生涯生活設計シミュレーション，③退職金シミュレーションシステム，④年金シミュレーションシステムの４つの機能からなり，年齢，収入，家族構成など様々な項目を入力することで，本人が死亡した場合に家族にとって必要となる金員の額（必要保障額）を算出し（上記①），今後の収入，支出の変動（生涯生活設計）のシミュレーションを行い（上記②），退職金額を算出し（上記③），年金の受領金額を算出し（上記④），これらをグラフ化することなどを主な内容としていた。 （甲１，２，乙４） 原告と被告は，平成２２年２月１０日頃，覚書（甲１０。以下「本件覚書」という。）を作成して，本件契約の納期について次のとおり変更する旨の合意（以下「本件変更合意」という。）をした。 ア原告は，平成２２年４月１日に被告に第１次動作検証版を提供し，被告は，原告の開発と平行してテストを開始する。 イ原告は，テスト結果をもとに，同月８日に被告に第２次動 。）をした。 ア原告は，平成２２年４月１日に被告に第１次動作検証版を提供し，被告は，原告の開発と平行してテストを開始する。 イ原告は，テスト結果をもとに，同月８日に被告に第２次動作検証版を提供する。 ウ訴外会社において，同月１５日に受入れテストを開始し，原告は，その結果を受けて修正を行う。 エ原告は，同月２２日，被告に完成版のディスク又はファイル一式を納品する。 （甲１０） 原告は，平成２２年３月２日，被告に対し，作成した詳細設計書をメールで送信し，被告は，同月９日，原告に対し，上記詳細設計書に被告が添削，修正を加えたものをメールで送信した。 （乙１３の１ないし３，乙２６） 被告は，平成２２年４月９日，原告に対し，計算仕様書である「ライフプランシミュレーション必要保障額計算仕様」，「ライフプランシミュレーション退職手当額計算仕様」，「ライフプランシミュレーション退職共済年金計算仕様」及び「ライフプランシミュレーション生涯生活設計計画表計算仕様」（以下，それぞれ「必要保障額計算仕様」のようにいう。）をメールで送信した。 その後，被告は，原告に対し，同月２１日に生涯生活設計計画表計算仕様の改訂版を，同月２３日及び２６日に必要保障額計算仕様の改訂版をそれぞれメールで送信した。 （甲６，７の１及び２，１２，２９，３３ないし３５） 被告は，平成２２年４月２１日，原告に対し，「ＬＰＦＰシミュレーションチェックシート（警察版）．ｘｌｓ」（以下「本件チェックシート」という。）をメールで送信し，その後，同月２８日までの間に，原告に対し，複数回にわたり本件チェックシートの改訂版を送付した。 （甲１７，３８の２及び３） 本件プログラム ックシート」という。）をメールで送信し，その後，同月２８日までの間に，原告に対し，複数回にわたり本件チェックシートの改訂版を送付した。 （甲１７，３８の２及び３） 本件プログラムは，最終的に原被告間で納期とされた平成２２年４月３０日の時点で未完成であり，これに必要な修正を施すには相当期間を要する状況にあった。原告は，同日をもって，本件プログラムの制作作業を中止した。 被告は，平成２２年５月１日から，前日までの原告の成果物（以下「本件 成果物」という。）を補充，修正する方法で本件プログラムの制作作業を行った。 原告は，平成２２年５月１４日付けで，被告に対し，原告は本件プログラムの制作作業を継続する意思を有しているが，この点や追加代金の清算について，被告がどのような方針で臨むのかを１０日以内に回答するよう求める「請求書」を送付した。 （甲３） 被告は，原告を関与させないまま本件プログラムを完成させ，平成２２年５月１９日に訴外会社に本件プログラムを納品した。 平成２２年１０月頃，本件プログラムにバグがあることが見つかって，訴外会社がこれを修正したＣＤ－ＲＯＭを新たに焼き直す必要が生じたため，被告は，訴外会社に対し，同社が配布したＣＤ－ＲＯＭの修正版の制作費等合計６６５万５６９１円（制作費６６４万６２４１円及びサンプルディスク制作費９４５０円の合計額）を支払った。 （乙２８ないし３０） ２ 争点 本訴ア原告の被告に対する請求の当否 民法５３６条２項前段に基づく請求の当否（争点１） 信義則に基づく報酬請求権の有無（争点２） 民法６４１条に基づく請求の当否（争点３）イ上記アが認められる場合に原告が被 ３６条２項前段に基づく請求の当否（争点１） 信義則に基づく報酬請求権の有無（争点２） 民法６４１条に基づく請求の当否（争点３）イ上記アが認められる場合に原告が被告に請求することのできる金員の額（争点４） 反訴被告の原告に対する請求の当否，すなわち，民法４１５条に基づく請求の当否（争点５） ３ 争点に関する当事者の主張 争点１（民法５３６条２項前段に基づく請求の当否）について（原告）ア原告は，本件契約に基づき，本件プログラムを完成させて被告に引き渡す債務（以下「本件債務」という。）を負っていたが，本件プログラムは，納期とされた平成２２年４月３０日の時点でも完成していなかったから，原告の本件債務は履行不能になった。また，被告は，その後，原告を関与させないまま本件プログラムを完成させてこれを訴外会社に納品したから，やはり原告の本件債務は履行不能となったといえる。 イ本件契約においては，原告が被告から指示された仕様（概要設計）に基づいて詳細設計を行い，これを基にプログラム開発，単体テスト及び結合テストを順次行って成果物を被告に提供し，被告及び訴外会社が受入れテストを行って，バグ等が見つかれば，原告がこれを修正して被告に提供するという一連の過程を経ることによって，本件プログラムを完成させることになっており，被告が仕様を確定しなければ，原告は次の工程に進むことができなかった。そうであるから，被告は，原告の制作作業が滞りなく進むよう，本件プログラムの仕様を早期に確定させ，明確な仕様が確定されていないときは，訴外会社と交渉して抜本的なリスケジュールの調整を行うべきであった。また，本件契約においては，原告が，被告の提供するチェックシートにより計 仕様を早期に確定させ，明確な仕様が確定されていないときは，訴外会社と交渉して抜本的なリスケジュールの調整を行うべきであった。また，本件契約においては，原告が，被告の提供するチェックシートにより計算エンジンが正常に動くかどうかをテストすることになっていたが，このチェックシートが不正確であると，原告がチェックシートとプログラムのいずれが誤っているのかを調査するという本来不要な作業を余儀なくされてしまうのであるから，被告としては，訴外会社との交渉を通じて正確なチェックシートを作成し，これを早期に原告に提供すべきであった。 しかるに，被告は，原告に対し，別紙仕様変更一覧表記載１のとおり仕 様変更を繰り返した末，平成２２年４月９日になってようやく最終仕様として計算仕様（甲６）を出したが，その後も同記載２のとおり仕様変更を繰り返し，訴外会社に対して抜本的なリスケジュールの申入れをすることもしなかったし，納期直前の平成２２年４月２８日に本件チェックシートの修正を行い，翌２９日にはチェックシートが正確なものであることを前提に作業をする必要はないなどと述べて開き直るなどして，原告に協力しなかったので，原告は，本件プログラムの開発を同月３０日までに完了することができなかった。また，被告は，自ら本件プログラムを完成させようとするのであれば，本件契約書８条の規定に従って本件契約を合意解除し，仕掛品の引取りについて別途合意した額の金員を原告に支払うことで原告との契約関係を終了させることができたのに，原告を関与させないまま本件プログラムを完成させ，これを訴外会社に納品してしまった。 ウしたがって，本件債務は，被告の責めに帰すべき事由により履行不能になった。 （被告）ア本件プログラムの仕様は，原告が平成２２年３月２ ，これを訴外会社に納品してしまった。 ウしたがって，本件債務は，被告の責めに帰すべき事由により履行不能になった。 （被告）ア本件プログラムの仕様は，原告が平成２２年３月２日に被告に送信した詳細設計書に被告が添削，修正を加えて同月９日に原告に送信したものでほぼ確定し，以下のとおり，その後大きな変更はなかった。本件債務は，履行不能になったのではなく，原告が被告に不完全なプログラムを納入してその後の業務を放棄したという債務不履行があるだけである。 被告は，原告に対し，本件契約締結前に本件プログラムの基本的な仕様を示し，平成２２年２月上旬頃までに画面の仕様についても示した。 原被告間の定まっている基本的な仕様の細部を確定していく作業に過ぎず，依頼内容を根本的に変更するような仕様変更には当たらない。 ａ 計算仕様（甲６）は，原告が同月２日に提出したプログラムのできが悪かったために被告が危機感を抱き，従来の仕様を訴外会社の確認を得てわかりやすくまとめ直したもので，新たな仕様を指示したものではなく，変更点も一部に過ぎない。グラフを単年型から積上型に再度仕様変更した事実もない。 同月２１日の生涯生活設計計画表計算仕様の変更は，子供の年齢計算に関する一部の仕様に過ぎず，同月１７日に東京の被告事務所で作業をしていた原告スタッフ（派遣社員）Ａが修正を済ませていた。 同月２３日の必要保障額計算仕様の変更は，老齢年金の計算方法に関する軽微な点のみであり，同月２６日の必要保障額計算仕様の変更は，被告がその修正を反映したプログラムを原告に送付しているから，仕様変更を指示したものではない。 ｂ に関する軽微な点のみであり，同月２６日の必要保障額計算仕様の変更は，被告がその修正を反映したプログラムを原告に送付しているから，仕様変更を指示したものではない。 ｂ 原告主張の変更は，未熟な原告のパート作業員がプログラミングをしたためにエラーが発生し，大幅な設計変更を余儀なくされたもので，被告の都合で変更をしたものではない。 イ本件チェックシートについて本件チェックシートは，一部のプログラムで使用されていたに過ぎず，本件プログラムのチェックはこれとは別のテストツールを用いて行われていたのであるから，本件チェックシートの不具合やその修正により作業が遅れた事実はない。 ウこのように，被告は，原告に対し，遅滞なく適切な内容の資料等を提供し，仕様を示し，原告が本件プログラムを開発するのに必要な役割を果たした。原告が，同月３０日までに本件プログラムを完成することができな かったのは，専ら管理態勢の不備，技能不足，人員不足等，原告の能力の欠如という原告の責めに帰すべき事由によるのであって，被告の責めに帰すべき事由によるものではない。 争点２（信義則に基づく報酬請求権の有無）について（原告）本件債務の履行不能は，原告の責めに帰すべき事由により生じたものではなく，被告は，原告が開発した本件プログラムの仕掛品を基に本件プログラムを完成させ，訴外会社から報酬を受領して，上記仕掛品の価値に応じた利益を得ているのであるから，原告は，被告に対し，信義則に基づき，上記仕掛品の価値に応じた報酬請求権を有する。 （被告）争う。 争点３（民法６４１条に基づく請求の当否）について（原告）原告は，被告に対し，平成２２年５月１４日 掛品の価値に応じた報酬請求権を有する。 （被告）争う。 争点３（民法６４１条に基づく請求の当否）について（原告）原告は，被告に対し，平成２２年５月１４日付け請求書で原告の行うべき業務について被告に指示を仰いだにもかかわらず，被告は，これを無視して本件プログラムを完成させたのであり，かかる被告の行為は，民法６４１条に基づき本件契約を解除する旨の意思表示と評価することができる。 （被告）争う。 争点４（原告が被告に請求することのできる金員の額）について（原告）ア被告は，平成２２年４月８日までに別紙仕様変更一覧表記載１ないしの各仕様変更を行い，原告は，これに応じて本件プログラムの修正をした。原告は，４月に入っても仕様面が流動的になっている異例な状況にあったことから，同月９日， 被告に対し，メールで当初見積の約２倍の工数がかかる予定であること及び同日までに４５人日の業務が追加になっていることを伝えて追加予算の検討を要請し，所要の追加工数に対応する相当額を当初の代金額に上乗せするよう申し込んだ。被告は，平常取引をする原告からその営業の部類に属する契約の申込みを受けたのであるから，原告に対し遅滞なく諾否の通知を発すべきであったのに，諾否の通知を発しなかったから，原告の上記申込みを承諾したものとみなされる（商法５０９条の適用又は類推適用）。 仮にこれが認められないとしても，本件システムの開発が被告における仕様の確定を不可欠の前提とするものである以上，本件契約締結当時，原告において，度重なる仕様変更が指示されて仕様の確定が遅延し，最終的に納期が１か月以上も延期されることになるとは予測することができず，こうした事情の変更を原告の責めに帰する 上，本件契約締結当時，原告において，度重なる仕様変更が指示されて仕様の確定が遅延し，最終的に納期が１か月以上も延期されることになるとは予測することができず，こうした事情の変更を原告の責めに帰することはできない。原告はこれにより当初予定されていた工数の２倍超の工数を要したものであり，当初の代金額を維持することは著しく信義に反するから，原告は，被告に対し，事情変更の法理によって追加業務代金の支払を求めることができるというべきであるし，そうでなくとも商法５１２条に基づき相当額の支払を求めることができる。 イ相当額は１３９万０１０８円（＝４５人日×３万５０００円×２９０万円／３４５万円当額は１９７万７０４３円（＝６４人日×３万５０００円×２９０万円／３４５万円額は５０万９７０６円（＝１６．５人日×３万５０００円×２９０万円／３４５万円×１．０５）となり，これらの合計額は３８７万６８５７円となる。 したがって，原告は，被告に対し，請負代金又は損害賠償として，本件 契約締結当時の代金額３０４万５０００円と上記３８７万６８５７円の合計額である６９２万１８５７円の支払を求めることができるし，仮にこれが出来高分にとどまるとしても，仕様変更後の部分については結合テストのうち全体の４分の１程度を終えていたから，４０１万４２１４円（＝３０４万５０００円＋３８７万６８５７円×１／４）の支払を求めることができる。 （被告）本件のようなプログラムにおいては，作業の進展に応じて仕様が確定していく部分が多く，ある程度の変更はもともと想定されているところ，被告は，原告に対し，本件契約の趣旨を逸脱するような仕様変更を指示したことはなく，追加報酬が発生するような作業の増加もなかった。 そして，被告は，原告の 変更はもともと想定されているところ，被告は，原告に対し，本件契約の趣旨を逸脱するような仕様変更を指示したことはなく，追加報酬が発生するような作業の増加もなかった。 そして，被告は，原告のメールによる代金額追加の要望を訴外会社に伝えて相談するつもりであったので，その旨を原告に伝えたが，代金額の上乗せを了承したわけではない。翌日になって原告の作業について重大なミスが発見され，プログラムの大がかりな修正が必要となることが判明したため，追加代金を支払うどころではなくなり，結局，訴外会社と相談することもなく，原告からの催促もなかった。 争点５（民法４１５条に基づく請求の当否）について（被告）ア納期とされた平成２２年４月３０日の時点においても，原告は未だ多くの作業をやり残しており，また，外見上作業が完了したように見える部分についてもテストを行うと多数のエラーが発生する状態であって，プログラムは不完全なものであった。原告は，不完全なままのプログラムを被告に納入してその後の業務を放棄したから，原告には債務不履行（不完全履行）がある。 被告は，同年５月頃，原告から納入されたプログラムの一部を利用して， 不眠不休で必要なプログラムの作成，修正等の作業を行って本件プログラムを完成させ，同月１９日に訴外会社に納品したところ，原告作成部分の計算プログラム中，被告がそのまま利用した日付計算専用のプログラムである「CustomDate.as」ファイルの２７９行目と２８０行目の間に必要な「retVal="";」という文字列が欠落しているというバグ（以下「本件バグ」という。）があり，コンピューターのシステム時刻の月が２桁（１０月ないし１２月）となる場合に生年月日等の日付がエラーとなる重大な不具合が発生するこ う文字列が欠落しているというバグ（以下「本件バグ」という。）があり，コンピューターのシステム時刻の月が２桁（１０月ないし１２月）となる場合に生年月日等の日付がエラーとなる重大な不具合が発生することが判明したので，被告は，訴外会社に対し，６６５万５６９１円を支払い，同額の損害を受けた。 イ本件契約書７条２項は，原告が契約の本旨に従い誠実に債務を履行し，原告側で十分にテストをした上で納品することを前提とする規定であり，本件のように，原告が債務を誠実に履行せず，十分なテストも行わないまま本件プログラムを納入した場合には適用されない。 （原告）ア被告が主張するプログラムの不具合が，原告の責めに帰すべき事由により生じたものであるとはいえない。仮に上記不具合が原告のミスによるものであったとしても，それは本件契約に基づいて，原被告間でテストと修正を繰り返しながら解消すべきものであった。被告が，原告からかかる修正の機会を一方的に剥奪しておきながら，原告のミスを奇貨として原告に対し責任を追及することは許されない。 イ本件契約書７条２項は，本件プログラムをＣＤ－ＲＯＭに焼き付けることについて原告が責任を負わない趣旨で合意されたものであるから，原告は，同項により，被告主張の損害賠償責任を負うことはない。 第３ 当裁判所の判断 １ 前記前提事実に，証拠（甲２３，乙３８，原告代表者，被告代表者のほか後掲のもの）及び弁論の全趣旨を総合すれば，次の事実を認めることができる。 訴外会社は，平成２１年９月頃，被告に対し，本件プログラムの開発を依頼した。本件プログラムは，訴外会社が以前に別の顧客のために制作した類似のシステムを参考にしつつ，一から新たに制作する必要があったが，被告は，同年１１月３０日，原告に対 し，本件プログラムの開発を依頼した。本件プログラムは，訴外会社が以前に別の顧客のために制作した類似のシステムを参考にしつつ，一から新たに制作する必要があったが，被告は，同年１１月３０日，原告に対するメールで本件プログラムの概要の説明をし，その後平成２２年１月７日頃までに，「ライフプランシミュレーション構成図（案）Ｖｅｒ．１」など本件プログラムの構成と画面のイメージを示した図（乙２），本件プログラムの基本構成を示す「ライフプランシミュレーション構成図（案）Ｖｅｒ．３」と画面イメージを具体的に示した画面説明図を含む訴外会社作成に係る２００９年１２月１６日付け「「ライフプラン支援ソフト」開発打合せ資料」（乙４），「ライフプランシミュレーション構成図（案）Ｖｅｒ．５」などを含む上記開発打合せ資料の同月２２日付け改訂版（乙６），入力するデータの項目や処理要領等を具体的に記載した「データ項目説明書【入力】（案）」（乙５），退職金計算の方法をまとめた書面（乙７），年金シミュレーションの計算に関連するエクセルファイルや，別の団体向けに作成された類似プログラムの「ｗｅｂ仕様書」（甲２４，乙３）を交付又はメールで送信し，原告との間でメールや面談などにより打ち合わせを行った。 （甲２４，乙１ないし７，１４ないし１９） 原告と被告は，平成２２年（以下，同年については年の記載を省略する。）１月１５日，本件契約を締結した。原告が作成し被告に提出した見積書（甲２２。以下「本件見積書」という。）によれば，本件契約における具体的な作業工程（各末尾括弧内の数字は工数と税抜き金額）システム分析（実装方法検討）（１０．０人日，４５万円）概要設計（０．０人日，０円）詳細設計（２０．０人日，９０万円）製造・テスト（４５．０人日，１５７万５０ 字は工数と税抜き金額）システム分析（実装方法検討）（１０．０人日，４５万円）概要設計（０．０人日，０円）詳細設計（２０．０人日，９０万円）製造・テスト（４５．０人日，１５７万５０００円）結合テスト（１５．０人日，５２万５０００円） 作業は，① メインメニュー（２．０人日，７万円），②－１ 計算情報入力（５．０人日，１７万５０００円），②－２ 退職金シミュレーション（５．０人日，１７万５０００円），②－ ３ 年金シミュレーション（５．０人日，１７万５０００円），②－４ 生涯生活設計シミュレーション（７．０人日，２４万５０００円），③ 情報ＢＯＸ（０．５人日，１万７５００円），④ 計算情報保存・読み込み（２． ０人日，７万円），⑤－１ ヘルプ画面表示（０．５人日，１万７５００円），⑤－２ 動画再生（３．０人日，１０万５０００円），⑤－３ 帳票出力（５．０人日，１７万５０００円），⑤－４ テスト自動化（５．０人日，１７万５０００円），⑥－１ 家計診断（計算情報入力）（２．０人日，７万円），⑥－２ 家計診断（診断結果表示）（３．０人日，１０万５０００円）に分けられ，総工数は９０．０人日と見積もられていた。なお，本件見積書では，上記の合計額３４５万円から５５万円を値引きした２９０万円が税抜きの請負金額とされていた。 本件契約書７条には，原告が，本件プログラムの開発完了後といえども，その後３か月以内に開発成果に瑕疵が発見されたときは，無償にてこれを修補し，同期間経過後に発見される瑕疵については，被告の要求に応じ有償で修補するが，瑕疵から派生した二次的損害については，原告は保証しなくてよいものとする旨の定めがあり，上記二次的損害に関する定めは，万一ＣＤ－ＲＯＭの焼き直しや再配布が必要となった場合に原告がその で修補するが，瑕疵から派生した二次的損害については，原告は保証しなくてよいものとする旨の定めがあり，上記二次的損害に関する定めは，万一ＣＤ－ＲＯＭの焼き直しや再配布が必要となった場合に原告がその損害賠償を免れる趣旨で定められたものであった。 また，被告は，この頃，１月末に仕様が決定することを見込んでいて，その旨を原告に通知していた。 （甲２，１６，２２） 被告は，２月初め頃，原告に対し，２００９年１２月２２日付け「「ライフプラン支援ソフト」開発打合せ資料」（乙６）に添付されていた画面説明 図をより詳細にしてデザインの変更をした画面仕様書（乙８）や「データ項目説明書【入力】（案）」の改訂版（乙９）を送付した。 （乙６，８，９） 被告は，２月１０日，原告に対し，必要保障額算出や年金シミュレーション，退職金シミュレーションに必要な資料のエクセル等のファイル（甲３０，乙１０）をメールで送信し，また，家計診断部分を除く部分の仕様や画面サイズは同月１２日に確定する予定であること，家計診断部分は未確定なので開発を待機すべきこと，最終納期は４月２２日となること，情報ＢＯＸについて未決定の部分は多いが，画面数と構成の決定を翌週に決定するが，コンテンツについては今後決めていくことなど，訴外会社との打合せ内容を原告に通知した。 そして，原告と被告は，本件覚書を作成して，本件変更合意をした。 （甲１０，３０，乙１０，２１，２２） 被告は，２月１２日，原告に対し，「データ項目説明書【入力】（案）」の改訂版，各種シミュレーションにおける判定基準及びコメントの一覧（乙１１）をメールで送信するとともに，上記判定基準及びコメントについては変更がありそうだが翌週には確定する予定である旨を通知 案）」の改訂版，各種シミュレーションにおける判定基準及びコメントの一覧（乙１１）をメールで送信するとともに，上記判定基準及びコメントについては変更がありそうだが翌週には確定する予定である旨を通知した。 また，原告と被告は，同日から４月６日までの間，課題管理表を作成し，原告が確認事項を記載して被告がその回答を記載するといった方法で，仕様の具体的内容等について多数回にわたり調整を行った。 （甲４，乙１１，２３） 被告は，２月１６日，原告に対し，「必要保障額入力画面③（教育・結婚費用）」等の高校卒業後のラジオボタン選択に「就職」のボタンを，「必要保障額入力画面④（保険）」のラジオボタン選択に「なし」のボタンをそれぞれ追加するよう指示した。 （甲４） 被告は，２月１７日，原告に対し，必要保障額算出に当たり，採用年月日からの数え月により遺族共済年金の額が異なることから，「必要保障額入力画面①（家族構成）」に採用年月日の項目を追加したほか，必要保障額算出において，必要保障額に住宅リフォーム予定金額を，収入金額に本人の死亡時退職金をそれぞれ加算し，また，「中高年寡婦加算」制度を必要保障額の計算に組み込むといった仕様への変更を指示した。 （甲４） 被告は，２月２３日，「ライフプラン支援ソフト構成図（案）Ｖｅｒ．１１」や画面仕様書の改訂版等を含む訴外会社作成の２月１２日付け「「ライフプラン支援ソフト」開発打合せ資料」（乙１２）をメールで送信し，家計診断において「世帯人数」を入力項目として追加する旨を指示したほか，３月２日頃までに背景画像ファイル等の資料をメールで送信した。上記開発打合せ資料上は，家計収支の推移グラフは年ごとに単年の収入及び支出を表示する単年型で記載されていた。 加する旨を指示したほか，３月２日頃までに背景画像ファイル等の資料をメールで送信した。上記開発打合せ資料上は，家計収支の推移グラフは年ごとに単年の収入及び支出を表示する単年型で記載されていた。 また，被告は，同日，原告に対し，退職金シミュレーションシステムの退職手当額試算データ入力画面において，「表」，「級」及び「号給」を別々のテキストボックスに入力する形式から，「表」及び「級」についてはプルダウンから選択して１つのコンボボックスに入力する形式に変更するよう指示した。 （甲４，乙１２，２４，２５） 被告は，３月２日，原告に対し，必要保障額算出に当たり，収入金額に含まれる配偶者の公的年金は手入力ではなく計算により算出するようにし，それに伴い画面構成も変更し，死亡時退職金の計算方法を，年金計算の上昇率を使用した算出方法で推定給与を算出し，それをベースとした退職金を算出する方法に変更し，収入増加分の考慮方法を変更し，また，年金算出処理において，賞与支給率につき「組合員種別」ではなく「退職時の職種」を入力 する形式に修正し，入力の選択項目を「警視以上」，「警察官（警部以下）」及び「一般職員」から「警視以上（相当職）」，「警察官（警部以下）及び「一般職員」に変更するよう指示した。 原告は，同日，被告に対し，それまでに被告から示された資料，指示に基づき原告が作成した詳細設計書をメールで送信した。 （甲４，乙１３の１ないし３） 被告は，３月９日，原告に対し，原告から送信された詳細設計書に被告が添削，修正を加えたものをメールで送信し，これにより，本件プログラムの具体的な仕様がほぼ確定した。 （乙２６） 被告は，３月１０日，原告に対し，詳細設計書の補充資料をメールで送信した 削，修正を加えたものをメールで送信し，これにより，本件プログラムの具体的な仕様がほぼ確定した。 （乙２６） 被告は，３月１０日，原告に対し，詳細設計書の補充資料をメールで送信した。 （乙２７） 被告は，３月１９日，原告に対し，必要保障額において，グラフは積上型とし，「シミュレーションシステム計算式＿ｓｐｅｃ．ｐｄｆ」のｐ．１００の平均余命テーブルに従い本人及び配偶者の余命を取得し，その余命までの分で算出すると指示したが，同月２３日には，グラフは単年型とし，必要保障額を「２０１００３１９－生涯生活設計計画表サンプル．ｘｌｓ」の単年で算出している部分の計算式（ただし，死亡時退職金が考慮されていないので考慮する。）で算出するよう変更を指示した。 （甲４，１３，１４） 被告は，３月２９日，原告に対し，生涯生活設計シミュレーションシステムにおいて，本人の年収手取りを算出する際，職種により給与の上昇率が異なる問題を解決するため，「必要保障額入力画面①（家族構成）」に職種によるリストダウンを追加するよう指示した。 （甲４） 被告は，４月１日，原告に対し，必要保障額算出において，中高年寡婦加算について，「経過的寡婦加算」制度を計算式に組み込むよう指示し，遺族共済年金について，原告が２月１０日に受領した仕様に基づく計算式から平成２１年１２月８日に受領したＰＤＦの仕様に基づく計算式に変更し，更に平成１５年法改正前後の値を算出するように変更を指示し，また，生涯生活設計シミュレーションシステムにおいて，初年度は生活費（月額）×１２として計算していたのを，別途「生涯生活設計・必要保障額の収入，手取り，生活費算出０４０１．ｘｌｓ」に基づき算出するよう指示した。 原告は，同日 ステムにおいて，初年度は生活費（月額）×１２として計算していたのを，別途「生涯生活設計・必要保障額の収入，手取り，生活費算出０４０１．ｘｌｓ」に基づき算出するよう指示した。 原告は，同日，被告に対し，製造・テスト」に該当）に関する達成率が６０％であり，必要保障額算出に関するプログラム制作の達成率が０ないし５０％の部分があることや家計診断に係る部分が手付かず（達成率０％）であること，全体の進捗具合が約３ないし４日遅れであること，既に仕様は凍結したものと考えているが，原告側から確認して明確となった部分もあるので，まだ原告に明確にしていない仕様がないか確認してほしいことなどをメールで伝えるとともに，「動作確認用ｅｘｅ」ファイル一式を被告に送信しようとしたが，画面遷移部分で不具合があるため翌日提出する旨を通知した。 （甲４，乙３９の１及び２，４０） 原告は，４月２日，被告に対し，同月１日分の「動作確認用ｅｘｅ」ファイル一式を送付したが，これは第１次動作検証版には至らないものであった。 被告は，同日，原告に対し，必要保障額のグラフは積上型とする旨再度の変更を指示した。 （甲１５，３１，乙３９の１及び２） 被告は，４月５日，原告に対し，同月１９日に「最終・計算結果提出」とする等のスケジュールの変更を訴外会社に提案することなどを記載したメールを送信した。 （乙４１の１及び２） 被告は，４月６日，上記スケジュールの変更を訴外会社に提案し，納期を同月３０日とすることについて訴外会社から了承を受け，原被告間において，この頃までに，原告の最終納期を同月３０日とする旨の合意が成立した。 また，被告は，４月６日，原告に対し，年金シミュレーションシステムにおいて，夫死亡 会社から了承を受け，原被告間において，この頃までに，原告の最終納期を同月３０日とする旨の合意が成立した。 また，被告は，４月６日，原告に対し，年金シミュレーションシステムにおいて，夫死亡時の妻の年金取得方法につき「遺族共済年金＋妻の老齢基礎年金」で計算することとし，これに伴い検証用出力項目の必要保障額の項目に「配偶者公的年金」の項目を追加するよう指示した。 （甲４，乙４１の１及び２） 原告は，４月８日，被告に対し，年金シミュレーション及び退職金シミュレーションのソフト成果物（以下「４／８のリリース版」という。）を送付し，必要保障額については仕様の確定が遅れている影響で実装をしただけの状況であってテストには至っていない旨を告げた。被告がこれをテストしたところ，８点のエラーが発生したため，被告は，同日，原告にエラー内容の修正を求めるとともに，原告と，上記エラーの修正は同月３０日までに行うこと及び原告の技術者が東京の被告事務所で被告の管理下において本件プログラムの制作作業をすることを合意した。 （甲２６） 原告は，４月９日，被告に対し，４月に入っても仕様面が流動的になっている異例な状況で非常に苦戦しており，同月２０日までの間に当初予定の倍の工数がかかる見込みであるとして，追加予算（請負代金額の追加）の検討を依頼したところ，被告は，もう少し早く言ってもらえれば仕様変更のストップや追加見積の交渉をすることができたところだが，訴外会社に一度相談してみたいので，仕様変更，追加のあった部分のリストと工数を示すよう応じたため，原告は，被告に対し，更により１９人日追加，必要保障額算出処理の実装に２０人日追加など，そ れまでの仕様変更の内容と追加された工数（合計４５人日）を示すリストを送信した。 じたため，原告は，被告に対し，更により１９人日追加，必要保障額算出処理の実装に２０人日追加など，そ れまでの仕様変更の内容と追加された工数（合計４５人日）を示すリストを送信した。 被告は，同日，原告に対し，甲６の計算仕様（必要保障額計算仕様，退職手当額計算仕様，退職共済年金計算仕様及び生涯生活設計計画表計算仕様）をメールで送信したが，これにより，臨時の支出は計算する年のみ入力する，遺族基礎年金について詳細な場合分けをする，遺族共済年金を短期要件と長期要件に分ける，老齢年金は年金シミュレーション計算仕様から求める，本人の死亡退職金の算出方法を場合分けする，配偶者の年収につき初年度とｎ年後に分けて算出し，配偶者の私的年金につき支給期間で限定するなど，従前不明確であった仕様が明確化されたり変更が加えられたりした。 原告は，同日，被告に対し，４／８のリリース版の修正版を送付したが，これは第１次動作検証版には至らないものであった。 （甲５，６，１２，２５，２７，３０，３２） 原告従業員のＢ及び原告スタッフ（派遣社員）Ａは，４月１２日頃から，Ｂについては同月１７日まで，Ａについては同月２３日まで，東京の被告事務所で本件プログラムの制作作業を行った。 被告は，４月１６日，画面処理について，入力項目単位でデータを保存していたのを，一画面ごとに入力したデータを保存する方式に変更する等の仕様変更を指示した。 被告は，４月１７日，Ａに対し，教育費等を計算するための４月１日時点での子供の年齢について，６歳を小学１年，１２歳を中学１年，１５歳を高校１年などとするよう改めた生涯生活設計計画表計算仕様の改訂版（甲７の１）を交付し，Ａはその変更に応じた修正を行った。 （甲７の１） 被告 歳を小学１年，１２歳を中学１年，１５歳を高校１年などとするよう改めた生涯生活設計計画表計算仕様の改訂版（甲７の１）を交付し，Ａはその変更に応じた修正を行った。 （甲７の１） 被告は，４月２１日，Ｂに対し，改めたことを伝えるとともに，念のためとしてその旨修正した生涯生活設計計画表計算仕様の改訂版 （甲７の１）をメールで送信し，また，テスト用の「ｉｎｐｕｔ．ｔｘｔ」ファイル及び訴外会社作成に係る必要保障額の計算ツール（計算エンジンが正常に動作をするかどうかを検証するための資料）である本件チェックシートをメールで送信した。原告は，これ以降，本件チェックシートを用いて本件プログラムの必要保障額に係る部分の開発を進めた。 被告が同日に本件プログラムについて，ファイル入出力のテストをしたところ，６点のエラーが発生したため，被告は，同日，原告にその修正を依頼し，原告は，同月３０日までに修正を完了することを確認した。 （甲７の１，３３，３８の１） 被告は，４月２２日，原告に対し，本件チェックシートの改訂版である「ＬＰＦＰシミュレーションチェックシート（警察版）・計画表組込版．ｘｌｓ」をメールで送信した。 （甲３８の２） 被告は，４月２３日，原告に対し，配偶者の老齢基礎年金及び老齢厚生年金の算出方法について，本人の計算ロジックを使用して年金シミュレーション計算仕様から求めるとされていたのを，老齢基礎年金については一定額とし，老齢厚生年金については特定の式により算出する等の修正を加えた必要保障額計算仕様の改訂版（甲７の２）をメールで送信した。 被告代表者は，同日，原告代表者に対し，Ａに引き続き被告事務所で作業させるよう依頼したが，原告代表者は，これを断った。 （甲７の 障額計算仕様の改訂版（甲７の２）をメールで送信した。 被告代表者は，同日，原告代表者に対し，Ａに引き続き被告事務所で作業させるよう依頼したが，原告代表者は，これを断った。 （甲７の２，３４） 被告代表者は，４月２５日，原告代表者に対し，原告スタッフに東京の被告事務所で制作作業を行わせるよう依頼したが，原告代表者は，これを拒絶した。被告代表者がゴールデンウィークの連休前までに本件プログラムの制作作業が終わらなかったら連休中も作業をしてもらえるか原告代表者に尋ねると，原告代表者は，連休前に終わらせるよう努力するが，終わらなかった 場合は連休中も協力するとの趣旨を述べた。 被告は，同日，訴外会社との間で，納期を同月３０日から同年５月８日に変更する旨の合意をしたが，その旨を原告には伝えなかった。 被告は，４月２６日，原告に対し，配偶者の老齢基礎年金及び老齢厚生年金の算出方法について，老齢基礎年金は本人の計算ロジックを使用して年金シミュレーション計算仕様から求める方法に戻し，老齢厚生年金は６０歳から６４歳までと６５歳以上に分け，かつ，定額部分，報酬比例部分，職域加算部分及び経過的加算等を分けて計算する等の方法に変更した必要保障額計算仕様の改訂版（甲２９）及び上記変更点について被告の方で修正したプログラムをメールで送信した。 （甲２９，３５） 被告は，４月２８日，原告から提出された疑問点に対応するなどして，原告に対し，３度にわたり本件チェックシートの改訂版をメールで送信した。 （甲１７，３８の３） 原告は，４月２９日，被告に対し，本件チェックシートの不具合が進捗遅れの原因となっているので，これ自体のテストをしてほしいことや，本件チェックシートの計算式が頻繁に変わ 甲１７，３８の３） 原告は，４月２９日，被告に対し，本件チェックシートの不具合が進捗遅れの原因となっているので，これ自体のテストをしてほしいことや，本件チェックシートの計算式が頻繁に変わっている現状からすると，ＣＤ７万枚を焼く本件プログラムを同月３０日に納品することは困難であり，仕様を完全に凍結した上，２週間はテストを行うべき旨などを記載したメールを送信した。 これに対し，被告は，本件チェックシートを正とせず，これは計算思想の参考程度として取り扱い，４月２６日までに送付した必要保障額計算仕様を正として進めてほしい，今日はできるところまで進めることだけを考えてほしいなどと回答した。 原告は，これを受け，実際は本件チェックシートの中の計算式をそのまま実装しているわけではなく，被告から提示されている仕様をベースとしたも のを実装しており，本件チェックシートは見やすさの点で参考にしているなどとした上，いずれにしても４月３０日にＣＤに焼けるレベルの品質は保てないとの見解は変わらないと応じた。 （甲１８ないし２０） 被告代表者は，４月３０日，原告代表者に電話を掛けて，ゴールデンウィーク中に作業を行って同年５月６日までに完成させ，納品をするよう強く求めたが，原告代表者は，絶対に間に合わないからリスケジュールが必要であるとして，これを拒絶した。原告代表者は，同日，被告代表者に対し，同日中にテストパターン一つを通せるところまで対応して被告に提出すること，ゴールデンウィーク中は被告と訴外会社がテストを行うとのことであるから，仕様を凍結し，バグ出しを行ってほしいこと，原告はゴールデンウィーク明けにバグに対する対応を行うこと，スケジュール遅延の主たる原因は，仕様が出るのが遅すぎ，その後の仕様変更も多す のことであるから，仕様を凍結し，バグ出しを行ってほしいこと，原告はゴールデンウィーク明けにバグに対する対応を行うこと，スケジュール遅延の主たる原因は，仕様が出るのが遅すぎ，その後の仕様変更も多すぎることにあること，労務管理上，働かせすぎなのでゴールデンウィーク中は従業員らを休ませることなどを記載したメールを送信した後，しばらくの間連絡を絶ち，実際に，翌日以降は制作作業を中止した。 この時点で原告が制作し被告に納入した本件成果物は未完成で，完成させるには相当期間を要する状況にあったが，本件見積書の作業工程の分類のう 製造・テスト中の① メインメニュー，③ 情報ＢＯＸ，④ 計算情報保存・読み込み，⑤－１ その他（ヘルプ画面表示），⑤－２ その他（動画再生），⑤－３ その他（帳票出力），⑤－４ その他（テスト自動化），⑥－１ 家計診断（計算情報入力），⑥－２ 家計診断（診断結果表示）については既に完成した状態にあり，それ以外の部分は，概ね 製造・テスト中の②－２シミュレーション（計算情報入力），②－２ 退職金シミュレーション，②－３ 年金シミュレーション及び②－４ 生涯生活設計シミュレーションが各１０％の完 結合テストは行われていなかった。 なお，本件成果物のうちの日付計算専用のプログラム「CustomDate.as」ファイルの２７９行目と２８０行目の間には，本件バグがあった。 （甲８，９，１１，乙３１ないし３５） 被告は，５月１日から，本件成果物を補充，修正する方法で，本件プログラムの制作作業を行った。 （乙３１ないし３４） 原告は，５月６日，被告に対し，本件プログラムの制作作業の続行を申し入れたが，被告は，これを拒絶した。 原告は，５月１４日，被告に対 作作業を行った。 （乙３１ないし３４） 原告は，５月６日，被告に対し，本件プログラムの制作作業の続行を申し入れたが，被告は，これを拒絶した。 原告は，５月１４日，被告に対し，原告は本件プログラムの制作作業を継続する意思を有しているが，この点や追加代金の精算について，被告がどのような方針で臨むのかを１０日以内に回答するよう求める「請求書」（甲３）を送付した。 （甲３） 被告は，原告を関与させないまま，最終的なテストも全て行って本件プログラムを完成させ，同月１９日，訴外会社に本件プログラムを納品した。 １０月頃，本件プログラムに本件バグがあることが判明し，訴外会社はこの点を修正したＣＤ－ＲＯＭを新たに焼き直す必要が生じたため，被告は，訴外会社に対し，同社において配布したＣＤ－ＲＯＭの修正版の制作費等合計６６５万５６９１円を支払った。 （乙２８ないし３０） ２ 争点１（民法５３６条２項前段に基づく請求の当否）について 本件プログラムは，原告が４月３０日に未完成のまま制作作業を中止した後，被告が本件成果物を補充，修正して完成させ，５月１９日に訴外会社に納品したのであるから，原告の本件債務は，これにより，社会通念上，履行不能となったものと認められる。 なお，原告は，４月３０日の時点で本件プログラムが完成していなかったから，本件債務が履行不能になったと主張するが，本件契約の性質上，同日までに本件プログラムを完成させて被告に引き渡さなければ契約をした目的を達することができないとは認め難く，原被告間でその趣旨の合意があったとも認められないから，同日までに本件プログラムの完成，引渡しがされなかったとしても，このことから直ちに，本件債務が履行不能になったとはいえ ができないとは認め難く，原被告間でその趣旨の合意があったとも認められないから，同日までに本件プログラムの完成，引渡しがされなかったとしても，このことから直ちに，本件債務が履行不能になったとはいえない。原告の上記主張は，採用することができない。 ア被告は，本件成果物を補充，修正して本件プログラムを完成させて訴外会社に納品したが，本来原告が行うべき作業を被告が行うことになったのは，原被告間で合意された納期である４月３０日になっても本件プログラムが未完成で，完成させるには相当期間を要する状況にあったのに，原告が同日をもって本件プログラムの制作作業を中止して，その後しばらくの間連絡も絶ってしまい，訴外会社との間で合意された納期である５月８日に間に合わせるためには，被告自身が本件成果物を補充，修正して本件プログラムを完成させるほかない状態に陥ったことにある。このことに鑑みれば，本件契約に基づく原告の債務の履行不能が，被告の責めに帰すべき事由によるものであるとは認められないというべきである。 イ原告は，被告が，仕様変更を繰り返し，４月９日に最終仕様として計算仕様（甲６）を出したが，その後も仕様変更を繰り返していながら，訴外会社に対して抜本的なリスケジュールの申入れをすることもせず，また，納期直前に本件チェックシートの修正を行うなど，原告に協力しなかったと主張する。 しかしながら，被告が３月９日に原告から送信された詳細設計書に添削，修正を加えたもので本件プログラムの具体的な仕様はほぼ確定し，その後，変更等はされたものの，原告は，４月１日時点で全体の進捗具合が３ないし４日程度遅れていると認識していたに過ぎない。同月９日には被告から 原告に計算仕様（甲６）が送付されて従前不明確であった仕様が明確化されたり，変 は，４月１日時点で全体の進捗具合が３ないし４日程度遅れていると認識していたに過ぎない。同月９日には被告から 原告に計算仕様（甲６）が送付されて従前不明確であった仕様が明確化されたり，変更が加えられたりし，同月１６日には画面処理におけるデータの保存方法等の変更がされたが，原告代表者尋問の結果に照らすと，原告はこれらの変更等には何とか対応していたことが窺われる。被告が同月２１日にＢに送付した生涯生活設計計画表計算仕様の改訂版（甲７の１）による変更部分は同月１７日以降にＡにより修正作業が既に行われていたし，同月２３日の必要保障額計算仕様の改訂版（甲７の２）による修正部分は老齢基礎年金及び老齢厚生年金の算出に係る箇所のみの単純な変更に過ぎず，同月２６日の必要保障額計算仕様の改訂版（甲２９）による変更部分は被告がプログラムの修正を行っている。本件証拠に照らして，４月３０日までに本件プログラムが完成しなかったことが，ひとえに被告の仕様変更等によるとは断じ難い。また，被告が訴外会社に対して抜本的なリスケジュールの申入れをしたとは認め難いが，それを行わないと４月３０日の時点でその後の作業が行えなくなるというものでもない。さらに，本件チェックシートの修正があったとしても，原告は，本件チェックシートの中の計算式を実装しているわけではなく，これを見やすさの点で参考にしていたにとどまっていたというのである。 そうすると，被告がこれらの仕様変更等を繰り返し，訴外会社に対して抜本的なリスケジュールの申入れをすることもせず，また，本件チェックシートの修正を行ったからといって，原告が４月３０日の時点で本件プログラムの制作作業を中止したことがやむを得なかったとは認め難く，これらの点が，本件債務の履行不能についての被告の帰責性を基礎付けるとい トの修正を行ったからといって，原告が４月３０日の時点で本件プログラムの制作作業を中止したことがやむを得なかったとは認め難く，これらの点が，本件債務の履行不能についての被告の帰責性を基礎付けるということはできない。原告の上記主張は，採用することができない。 ウ原告は，被告が本件契約を合意解除し，仕掛品の引取りについて別途合意した額の金員を原告に支払って原告との契約関係を終了させることができたのに，原告を関与させないまま本件プログラムを完成させこれを訴外 会社に納品してしまったと主張する。 しかしながら，証拠（甲２）によれば，本件契約書８条は，原被告間で協議をすることにより本件契約を解除することができること等を定めるものに過ぎず，原告が一方的に本件プログラムの制作作業を中止した場合に，被告が当然に本件契約の合意解除をしなければならないとはいえないのであって，この点の原告の主張も，採用することができない。 ３ 争点２（信義則に基づく報酬請求権の有無）について 結合テストに分けられており，また，証拠（乙１３の１ないし３，３７の２）及び弁論の全趣旨によれば，本件プログラムは多数のプログラムの集合体であると認められるから，本件契約に基づき原告が行うべき業務の内容は可分であるといえる。また，被告は，本件成果物を利用して本件プログラムを完成させて訴外会社に納品したのであるから，被告は，本件成果物により利益を有するということができる。そして，出来高分の報酬を請求することが相当でないとする特段の事情は窺えないから，信義則上，原告は，被告に対し，本件プログラムの出来高分の報酬を請求することができると解するのが相当である。 ４ 争点３（民法６４１条に基づく請求の当否）について前記１認定 えないから，信義則上，原告は，被告に対し，本件プログラムの出来高分の報酬を請求することができると解するのが相当である。 ４ 争点３（民法６４１条に基づく請求の当否）について前記１認定の事実によれば，原告は，５月１４日，被告に対し，本件プログラムの制作作業の継続等に関し回答を求める「請求書」（甲３）を送付したところ，被告は，原告を関与させないまま本件プログラムを完成させたことが認められるが，このことをもって，被告が原告に対して本件契約を解除する旨の意思表示をしたと認めることはできないし，他に被告が解除の意思表示をしたと認めるに足りる証拠はないから，この点の原告の主張は，採用することができない。 ５ 争点４（原告が被告に請求することのできる金員の額）について 原告は，４月９日に所要の追加工数に対応する相当額を当初の代金額に上乗せするよう申込みをし，被告が遅滞なく諾否の通知を発しなかったから，これを承諾したものとみなされると主張する。しかしながら，前記１認定の事実によれば，原告は，被告に対し，追加予算の検討を要請したにとどまるのであって，原告が上記の申込みをしたとは認められず，他にこれを認めるに足りる証拠もないから，原告の上記主張は，その前提を欠くものであって失当である。 原告は，最終的に納期が１か月以上延期されることになるとは予測することができなかったし，こうした事情の変更を原告の責めに帰することはできず，当初の代金額を維持することは著しく信義に反すると主張する。しかしながら，プログラム制作請負契約において，仕様変更が行われて納期が変更されることが希有であるとは考え難いし，前述のとおり，４月３０日までに本件プログラムが完成しなかったのがひとえに被告の仕様変更等によるものとも断じ難いところで において，仕様変更が行われて納期が変更されることが希有であるとは考え難いし，前述のとおり，４月３０日までに本件プログラムが完成しなかったのがひとえに被告の仕様変更等によるものとも断じ難いところであり，結局，代金額の追加について原被告間で合意が成立しないまま，原告が制作作業を一方的に中止したことをも併せ考慮すると，本件契約締結当時の代金額を維持することが著しく信義に反するものとは認め難いから，この点の原告の主張も，採用することができない。 なお，原告は，商法５１２条に基づき追加作業分の代金額を請求することができるとも主張するが，本件契約において，契約締結当時に予定されていた仕様と追加された仕様とを明確に区別することができないことは原告が自認するところであり，本件契約は仕事の完成を目的とする請負契約であることに照らしても，原告の上記主張を採用する余地はない。 そうすると，本件契約における請負代金額は，本件契約締結当時の代金額である３０４万５０００円（税抜きで２９０万円）であり，原告は，被告に対し，このうちの出来高に相当する部分を請求することができることになる。 のとおり，一部の仕事を完成 させていたところ，本件契約締結の際に用いられた本件見積書は，作業工程ごとに工数と金額を定めていたから，原告が請求することができる出来高相当の報酬額は，本件見積書上の各作業工程のそれぞれの金額に完成度を乗じ，値引き分を考慮するために実際の税抜き請負金額２９０万円を値引き前の税抜き見積金額３４５万円で除したものを乗じ，最後に５％の消費税分を付加して算出するのが相当であり，その計算結果は，別紙認容額算定表のとおりである。 したがって，原告が，被告に対し請求することができる出来高相当の報酬額は，同表「税込み合計 ％の消費税分を付加して算出するのが相当であり，その計算結果は，別紙認容額算定表のとおりである。 したがって，原告が，被告に対し請求することができる出来高相当の報酬額は，同表「税込み合計」欄「認容額」欄記載のとおり，１５９万２６６７円となる。 原告は，結合テストの４分の３を除き，本件プログラムは完成していたと主張するが，これを認めるに足りる証拠はないから，採用することができない。 ６ 争点５（民法４１５条に基づく請求の当否）について本件成果物に本件バグがあり，被告が訴外会社に納品した完成品にも本件バグ含まれていたために，訴外会社がこれを修正したＣＤ－ＲＯＭを新たに焼き直す必要が生じたものであるが，本件成果物は，全体として未完成であり，原告が制作した部分についてもバグの有無等について十分なテストを行う必要があって，被告もこのことを認識していたことは明らかである。そして，本件バグの発見が困難であったことを認めるに足りる証拠はないから，被告は，最終的なテストを行っていながら，本件バグを見逃したものといわざるを得ない。 そうすると，被告が完成させた本件プログラムに本件バグが残ったのは，専ら被告の行ったテストが不十分であったためであるから，本件バグにより訴外会社がこれを修正したＣＤ－ＲＯＭを新たに焼き直す必要が生じ，これに関して被告が出捐をしたとしても，原告がこのことについて本件契約上の責任を負うべきであるということはできない。 ７ 以上の次第であるから，原告の本訴請求は，主位的請求が理由がなく，原告の予備的請求が，出来高分の報酬１５９万２６６７円及びこれに対する本件成果物引渡しの後である平成２２年６月１日から支払済みまで商事法定利率年６分の割合による遅延損害金の支払を求める限度で理由がある の予備的請求が，出来高分の報酬１５９万２６６７円及びこれに対する本件成果物引渡しの後である平成２２年６月１日から支払済みまで商事法定利率年６分の割合による遅延損害金の支払を求める限度で理由があるが，その余は理由がなく，被告の反訴請求は理由がない。 よって，上記の限度で原告の予備的請求を認容し，原告の主位的請求及びその余の予備的請求は失当として棄却し，被告の反訴請求は失当として棄却することとして，主文のとおり判決する。 東京地方裁判所民事第４７部 裁判長裁判官高野輝久 裁判官三井大有 裁判官藤田壮 仕様変更一覧表 １ 平成２２年４月８日までの仕様変更 平成２２年２月１６日，必要保障額入力画面④においてラジオボタン選択に「なし」のボタンを，同画面③において高校卒業後に「就職」のボタンをそれぞれ追加。 平成２２年２月１７日，必要保障額算出に当たり，採用年月日のからの数え月により遺族共済年金の額が異なるため，採用年月日の項目を追加。 平成２２年２月１７日，必要保障額算出において，本人の死亡時退職金が収入に加算される仕様に変更。 平成２２年２月１７日，住宅リフォーム予定金額を必要保障額に加算する仕様に変更。 平成２２年２月１７日，「中高齢寡婦加算」制度を必要保障額の計算に組み込む仕様に変更。 平成２２年２月２３日，退職金シミュレーションシステムにおいて，「表」，「級」，「号給」を別々のテキストボックスに入力する形式から，「表」及び「級」に関してプルダウンから選択 仕様に変更。 平成２２年２月２３日，退職金シミュレーションシステムにおいて，「表」，「級」，「号給」を別々のテキストボックスに入力する形式から，「表」及び「級」に関してプルダウンから選択してコンボボックスに入力する形式に変更。 平成２２年３月２日，年金算出処理において，賞与支給率につき「組合員種別」ではなく「退職時の職種」を入力する形式に修正し，入力の選択項目を「警視以上」，「警察官（警部以下）」及び「一般職員」から「警視以上（相当職）」，「警察官（警部以下）及び「一般職員」に変更。 平成２２年３月２日，必要保障額算出に当たり，配偶者の公的年金を手入力ではなく計算により算出するように変更し，それに応じて画面構成も変更。 平成２２年３月２日，必要保障額算出に当たり，死亡時退職金の計算方法につき，年金計算の上昇率を使用した算出方法で推定給与を算出し，それを ベースとした退職金を算出する方法に変更し，また，収入増加分の考慮方法を変更。 平成２２年３月１９日，退職金シミュレーションシステム及び年金シミュレーションシステムにおいて，給与の入力単位を「万円」から「円」に変更。 平成２２年３月１９日，必要保障額において，グラフは積上型とし，「シミュレーションシステム計算式＿ｓｐｅｃ．ｐｄｆ」のｐ．１００の平均余命テーブルに従い本人及び配偶者の余命を取得し，その余命までの分で算出すると指示したが，同月２３日には，グラフは単年型とし，必要保障額を「２０１００３１９－生涯生活設計計画表サンプル．ｘｌｓ」の単年で算出している部分の計算式（ただし，現時点では死亡時退職金が考慮されていないので考慮する。）で算出するよう変更。 平成２２年３月２９日，生涯生活設計シミュレーションシステムにお ｓ」の単年で算出している部分の計算式（ただし，現時点では死亡時退職金が考慮されていないので考慮する。）で算出するよう変更。 平成２２年３月２９日，生涯生活設計シミュレーションシステムにおいて，本人の年収手取りを算出する際，職種により給与の上昇率が異なる問題を解決するため，職種によるリストダウンを追加。 平成２２年３月３１日，生涯生活設計シミュレーションシステムにおいて，初年度は生活費（月額）×１２として計算していたのを，別途「生涯生活設計・必要保障額の収入，手取り，生活費算出０４０１．ｘｌｓ」に基づくよう変更。 平成２２年４月１日，必要保障額算出において，「経過的寡婦加算」制度を計算式に組み込むよう変更。 平成２２年４月１日，必要保障額算出において，原告が同年２月１０日に受領した仕様に基づく計算式から平成２１年１２月８日に受領したＰＤＦの仕様に基づく計算式に変更し，更に平成１５年法改正前後の値を算出するように変更。 平成２２年４月６日，年金シミュレーションシステムにおいて，夫死亡時の妻の年金取得方法につき「遺族共済年金＋妻の老齢基礎年金」で計算する よう変更し，また，検証用出力項目の必要保障額の項目に「配偶者公的年金」の項目を追加。 ア平成２２年４月９日，必要保障額，退職手当額，退職共済年金及び生涯生活設計計画表について，計算仕様（甲６）を最終仕様書として交付し，これにより，必要保障額算出において作成されるグラフを単年型から積上型に再度仕様変更するなど従前確定した仕様を大きく変更。 イ生涯生活設計計画表に関しては同月２１日に，必要保障額に関しては同月２３日に再び最終仕様（甲７の２）を交付し，同月２６日には必要保障額に関して更なる最終仕様を交付し，これにより生涯 更。 イ生涯生活設計計画表に関しては同月２１日に，必要保障額に関しては同月２３日に再び最終仕様（甲７の２）を交付し，同月２６日には必要保障額に関して更なる最終仕様を交付し，これにより生涯生活設計計画を立てるに当たり，子供の学年を年齢から概算で計算するのではなく生年月日から正確に計算したり，必要保障額算出における配偶者厚生（共済）年金の計算で，本人の年金計算ロジックを使用せずに新たに老齢基礎年金と老齢厚生年金の計算式が決められたりするなどの変更。 平成２２年４月１６日，画面処理につき，入力項目単位でデータを保存していたのを，一画面ごとに入力したデータを保存する方式にする等の大幅なロジックの変更。
▼ クリックして全文を表示