第１ 準委任でも開発の進め方が問われる
システムが動かないのに，「準委任だから完成の責任はない」「作業時間を使ったので報酬は全額必要」と説明されたときは，契約の名称だけで結論を出さず，約束した業務と実際の進め方を確認する必要がある。
準委任では，当然に完成品の引渡しが約束されているとは限らない。
しかし，専門業者として引き受けた調査，設計支援，進捗管理や技術上の問題への対応を適切に行う義務までなくなるわけではない。
確認する順序は，①何を行う契約だったか，②その業務にどのような不履行があったか，③それによってどの費用が無駄になったか，の３段階である。
成果が出なかった事実と，契約違反及び損害の立証を分けると，返金交渉や追加費用への対応を整理しやすい。
第２ 完成義務，注意義務と報酬条件を分ける
１ 契約書の表題と具体的な約束を照合する
民法６３２条の請負は仕事の完成を目的とする。
準委任では，同６５６条により委任の規定が準用され，同６４４条の善管注意義務や同６４５条の報告義務が問題となる。
ただし，「準委任」と書かれているだけで，すべての作業について同じ結論になるわけではない。
要件定義の支援，設計書の作成，プログラムの開発，移行支援やクラウド利用を工程・契約ごとに分け，仕様書や提案書を含めて何を約束したかを読む。
報酬についても，期間に応じて支払うのか，作業の履行後に支払うのか，得られた成果に対して支払うのかを確認する。
現行民法６４８条と６４８条の２は，通常の報酬と成果等に対する報酬を分けて定めている。
成果報酬型の準委任も，名称だけで請負と同じ責任になるわけではない。
２ 業務の終了確認と最終システムの稼働確認を混同しない
IPAの開発モデル契約では，要件定義作成支援について，個別契約，要件定義検討会，要件定義書の確定，業務終了報告書による確認を区別している。
また，準委任型の支援業務であっても，善管注意義務違反による債務不履行責任が問題となる旨を解説している。
これは，モデル契約の条項・解説である。
自分の契約に同じ条項があるか，終了確認が何を対象とし，何を留保していたかは別に確認する。
設計書の承認や一工程の支払が，後の設計・開発上の問題をすべて解消するという意味にはならない。
第３ 文化シヤッター事件の東京地裁判決
１ 準委任という条項があっても不完全履行が認められた
東京地裁令和４年６月１７日判決は，販売管理等に用いるシステムの開発・構築支援が頓挫した事件である。
共通約款には，顧客の管理・監督の下で業務を完成させることや，契約の性質が請負ではなく準委任であることが記載されていた。
裁判所は，ユーザーに提供された成果物について，技術的な制約等により社会通念上運用可能なものとして完成させることが困難で，合理的な期間内の本番稼働を見通せる状態になかったと判断した。
そして，履行済みの一部を除く個別契約について不完全履行を認め，ベンダーの責任を認めた。
この判断を，「準委任でも必ず完成を保証する」と一般化することはできない。
契約上引き受けた支援業務と，本番稼働を見通せない状態に至った原因を具体的に検討した事例として読む必要がある。
２ ユーザー側の遅れも損害額に影響した
同判決は，ユーザー側の仕様に関する意思決定の遅れや追加変更等も考慮し，損害額について１５％を減じた。
認容額は１９億８３３１万６０１６円である。
１５％という割合は，この事件の事情に即した判断であり，他の開発案件の基準ではない。
ベンダーの開発管理上の問題を指摘する場合も，ユーザー側の資料提供日，回答期限，実際の回答日及びその後の対応を一緒に検証する必要がある。
本記事の具体的な理由の紹介は，判例秘書で裁判所の判断部分を確認した第一審判決に基づく。
文化シヤッター社の令和６年５月１６日付適時開示は，同日の東京高裁判決により認容額が２０億０５６４万９４６１円に変更されたと公表している。
この控訴審の経過・金額は会社開示で確認した情報であり，控訴審判決の理由の原文を確認したものではない。
第一審の過失相殺や各費目の判断が控訴審でもそのまま維持されたとは断定せず，確定の有無も未確認としている。
第４ 開発管理義務を具体的な出来事に落とす
１ 技術的な制約を把握し，計画へ反映したか
同判決では，採用したクラウド基盤の制約と，個別開発を重ねたシステムの構造が問題になった。
標準機能を利用すれば容易に開発できるという提案と，実際にどの程度の個別開発が必要になったかの食い違いにも注意が必要である。
契約審査や開発中の協議では，処理件数，同時利用，画面の応答，外部システムとの連携，運用・保守に必要な条件を具体化し，検証結果と計画を対応させる。
これは本記事の実務上の提案であり，判決がすべての案件に同一の試験項目を命じたという趣旨ではない。
この事件当時の製品上の制約を，現在のクラウドサービスの仕様として引用することはできない。
現に利用する製品，契約プラン，時点及び構成について，提供元の資料と検証結果を確認する。
２ ユーザーの判断が遅れたときに何をしたか
「回答待ちだった」という説明だけでは，どの工程に何日影響したのかが分からない。
必要な資料・判断をいつ求めたか，期限と影響を伝えたか，暫定案や代替案を示したか，計画を見直したかを記録する。
ユーザーも，社内の意思決定者を決め，未決事項を放置せず，業務上必要な情報を整理して提供する。
技術上の専門性と業務上の知識を双方が持ち寄る必要がある。
第５ 返金，報酬精算と損害賠償を分ける
１ 前の工程の費用が全部戻るとは限らない
開発全体が頓挫しても，既に適切に履行された前工程まで，自動的に不履行になるわけではない。
上記判決も，二次要件定義に関する個別契約１自体については不完全履行の立証を認めず，その後の設計・開発に係る費用等と区別した。
契約の解除に伴う返還，途中まで行った業務の報酬精算，不履行により無駄になった費用の賠償は，根拠と計算が異なる。
同じ支出を返還と損害賠償の両方へ重ねて計上しないよう，契約，請求書，支払，対応する工程及び請求の根拠を一覧にする。
２ 「使った時間」と「請求できる金額」は別である
上記判決は，追加の工数が生じたことだけから追加報酬の合意を認めたわけではない。
工数の増加には，作業の見積りや技術力に起因するものもあり得るためである。
他方で，本来の契約範囲を超える業務について合意した場合には，追加報酬が問題となる。
変更の内容，誰が依頼・承認したか，費用条件及び着手の経緯を確認する。
詳しくは，システム開発の仕様変更と追加費用―依頼・影響評価・合意・中止時の確認事項（AI作成）を参照されたい。
３ 責任制限条項は対象と計算を読む
上記判決は，責任制限条項を重大な過失のため無効とした事例ではない。
対象となるサービスの料金相当額による上限を検討し，過失相殺後の認容額がその上限を下回ることから，さらに減額する必要がないとした。
責任制限がある案件では，対象となる損害，関連するサービス・個別契約，上限の算定方法及び例外条項を先に特定する。
高額な賠償が認められたという結論だけから，責任制限は機能しないと考えることはできない。
第６ 相談前にそろえる記録
契約書や最終版の設計書だけでなく，その時点で何が分かっていたかを示す資料を残す。
以下は，交渉・相談のために本記事が提案する整理項目である。
① 基本契約，工程別の個別契約，提案書及び仕様書の版と優先順位。
② 要件の質問・回答，未決事項，回答期限及び承認者が分かる議事録・メール。
③ 不具合又は変更を管理するチケットの本文，添付，コメント，変更履歴及び対応結果。
④ 試験時の構成，設定，データ量，操作手順，ログ及び再現結果。
⑤ 請求書，外注契約，支払資料，作業記録及び費目ごとの損害計算。
チケットに「仕様変更」と記載されていても，過去の合意や指摘を反映しなかった修正が含まれることがある。
逆に，従前の仕様を超える追加要望である場合もある。
ラベルの件数を集計するだけでなく，元の要求から対応結果までを時系列で照合する。
検証環境やログを終了時に失うおそれがある場合は，保存できる期間，取得方法及び担当者を早めに確認する。
相手方の内部資料は自由に取得できるわけではない。
必要性と所在を特定し，取得の可否や適法な手続を検討する。
第７ 関連記事と出典
コンサル契約で提案書だけが残ったとき―成果物，実行支援，検収，KPI及び中途解約の契約設計（AI作成）では，実行支援や報酬条件を契約書にどう落とすかを扱う。
発注確定と言われて要員を確保したのに破談になったら―個別契約の成立と交渉上の損害賠償（AI作成）は，契約成立前の要員確保を扱う。
本記事のような，成立した開発契約の履行をめぐる問題とは請求の前提が異なる。
出典は，①民法（e-Gov法令検索），②IPA情報システム・モデル取引・契約書（第二版）の受託開発モデル及び解説（２０２５年４月８日更新ファイル），③東京地裁令和４年６月１７日判決（平成２９年（ワ）第３９８５９号・平成３０年（ワ）第９２３９号，判例秘書の判例番号 Ｌ０７７３２１２３），④文化シヤッター社の控訴審判決に関する適時開示である。
現行民法の説明と，改正前に締結された契約を扱う上記判決の判断は区別している。
古い契約に現行条文をそのまま適用する趣旨ではない。
IPAのモデル契約も，個別の契約に自動的に適用される法令ではない。