契約書に書かなかった仕事を、誰がするのか

架空事例：青葉機材が予約システムを外部委託する。契約条項や検収条件は説明用の仮定であり、法的助言や実際の契約解釈を示さない。法的類型は契約書の名前だけでなく、合意内容と実態に依存する。

「仕様のとおり完成した」と「使える」の間

新しい在庫システムが納入された。委託先は仕様書の機能がすべて実装されたと説明した。しかし、納品書の番号体系が旧システムと異なり、配送部門は翌日の出庫を開始できなかった。

委託先は言う。「データ変換は別契約です」。発注者は答える。「移行まで含めて使えるようになると思っていました」。

技術的な問題が、契約上の責任問題に変わる瞬間である。どちらか一方の説明だけで正誤を決めることはできない。何を取得する契約だったか、前提となるデータと移行をどの文書に定義し、どの時点で合意したかを見る必要がある。

IPAのモデル取引・契約書（第二版）は、ユーザ企業とベンダ企業の各段階での責務、契約内容、検収の共通理解を深めるための資料を提供する。2 モデルをそのまま貼るだけで責任分界が確定するのではない。案件ごとの実際の合意が必要になる。

RFPは、機能の買い物リストではない

青葉機材のRFPには「予約」「在庫」「請求」が列挙されていた。ところが、既存の台帳をどの範囲まで移すか、外部配送会社と誰が調整するか、稼働後に誰が障害へ対応するかは書かれていない。

発注者は機能の名前を伝えたつもりでも、提案する側には複数の解釈がある。データ移行を含む見積と含まない見積を金額だけで比較しても、同じ対象を競争させたことにならない。

RFPでは、目的、対象業務、範囲、制約、品質、移行、外部インタフェース、受入条件、契約条件を必要な粒度で示す。提案してほしい技術方式まで先に固定する必要はなく、業務上の必須条件と供給者が工夫できる部分を分ける。

シラバス1-1は、取得側がシステム要件や契約条件、技術的制約などを整理する活動を扱う。1 供給者の提案書作成は別の責務であり、要求を出すことと相手の提案を評価することも異なる。

提案の価格には、同じ範囲が入っているか

A社は初期費用が安く、B社は高い。B社には移行リハーサルと運用者教育が含まれ、A社には含まれない。単純な初期費用だけでA社を採用すると、追加の発注や移行時の停止が生じるかもしれない。

提案評価では、機能数だけでなく、必要な環境、体制、テストの対象、品質保証、サポート、移行と保守を揃えて比較する。安い案のリスクを整理したうえで採用すること自体は誤りではない。しかし、そのリスクを見積書の外に隠したまま決めるのは評価とは言えない。

技術要件に対する適合も単純な丸印で判定しない。性能目標が書かれていても、どのデータ量・同時利用数で測るかが異なれば、比較できない。ベンダーの「対応可能」という言葉が何の前提に依存するかを問う。

完成を約束することと、仕事を遂行すること

青葉機材が、要件と成果物を具体的に定め、その完成を約束してもらう契約を考える。これは請負の基本的な考え方と関係する。成果物の完成、契約への適合、受入条件が重要になる。

一方、業務が変わりやすく、専門家による設計・開発活動を継続的に委ねる場合は、準委任という契約類型が候補になる。準委任は、当然に特定の成果物の完成を約束するものではなく、受託した事務を遂行することが中心となる。契約で定める義務、報酬、成果物の扱いは個別に確かめる必要がある。3

労働者派遣では、派遣先の指揮命令の下で労働が行われる点が制度上の特徴になる。実際の指示系統を見ずに「人月計算なので派遣」「常駐しているので派遣」と決めることはできない。名目ではなく実態が問題になる。

IPAのアジャイル開発版モデル取引・契約書は、変更に対応するアジャイル開発の性質を踏まえ、準委任契約を前提としている。3 これはすべてのアジャイル開発が法律上必ず準委任でなければならないという一般則ではなく、そのモデル契約が選ぶ前提である。

指示は誰から届くのか

発注者の現場担当が、委託先の個々の作業者へ毎日直接命令していた。契約書には「準委任」と書いてある。しかし、現場の作業指示の流れが契約上・法令上の区分と整合するかは、別に確認する必要がある。

発注者が求める業務上の結果と、委託先が作業者へ行う具体的な指示を切り分ける。成果物の受入れについて意見を伝えることと、委託先の個々の労働者へ直接の業務指示をすることは同義ではない。

また、委託先との窓口を一本化したからといって、必要な情報共有まで禁じる理由にはならない。品質上の課題や仕様の疑問を、どの責任者へ報告し、どの会議で判断するかを明確にする。

契約類型の名称を覚えるだけの勉強から、実際の責務と指揮命令を説明する勉強へ進む。ここに午前Ⅱと午後の接点がある。

仕様変更は、当初の約束を消さない

運用部門が、新しい配送業者との連携を追加してほしいと言った。重要な変更である。しかし、重要だから当初の契約に含まれていたことになるわけではない。

変更によってどの機能、納期、費用、検証、運用へ影響が出るかを評価し、必要な合意を取り直す。ベースラインは変更を禁止するためのものではなく、合意したものと変更したものの差を追跡する基準となる。

同じく「アジャイルなので要件定義は不要」とは言えない。詳細な実現方法を反復の中で学ぶことと、事業目的、リスク、当面の判断責任がなくなることは違う。アジャイル開発の契約では、変更の扱いと優先順位の決め方を明確にする意味が大きい。

検収は、相手の仕事を採点するだけではない

システムの受入れでは、契約上の納入物と合意した基準への適合を確認する。発注者がいつ、どの環境・データで、何を合格と判断するかを明らかにする。

「使ってみたら不便だった」という指摘には、合意した要件を満たしていない場合と、当初明文化していなかった業務課題が見つかった場合がある。両者を区別せずに責任を押し付ければ、修正する対象も合意しにくい。

逆に、形式的なテストが通ったから事業上の課題が消えるわけではない。システム適格性確認と受入れ、業務での妥当性確認は、対象と判断主体が異なる。シラバス15-1は取得者の受入れレビュー・テストを支援する技能を要求する。1

合意できる文章は、技術と契約の両方に必要なインタフェースとなる。どこまでを誰が確かめるのか。それを書かなかった仕事は、納品日に消えてくれるわけではない。

知識を答案へ戻す

午前Ⅱ。 RFPと提案書、請負と準委任と派遣、固定価格と時間精算を別軸で区別する。完成責任と直接の指揮命令を混同しない。

午後Ⅰ。 指定範囲、受入条件、移行・連携・教育の役割を本文から抽出し、契約外の作業を勝手に要件へ追加しない。

午後Ⅱ。 委託方式と調達範囲の選択理由、仕様変更の合意方法、受入れまでの責任分界を具体的に述べる。

立ち止まって考える：準委任契約であれば、委託先の作業者へ発注者が直接指示できるか

準委任という名称から直接指揮命令権が生じるわけではない。適切な契約・実際の労務管理と指示系統を個別に確認する必要がある。

出典と照合範囲

[1] コンプリートテキスト第2・8・9・24章、IPA SAシラバスVer.5.2：RFP・提案、契約類型、受入れ支援を出発点とする。公式シラバス

[2] IPA「情報システム・モデル取引・契約書（第二版）」：ユーザ・ベンダ間の責務と検収などの共通理解を目的とする公開資料を参照した。契約本文の個別条項を逐条検証したものではない。IPA公開ページ

[3] IPA「情報システム・モデル取引・契約書（アジャイル開発版）」：同モデルが準委任を前提とする理由と協働の考え方を参照した。法的な適否は個別の契約・実態に依存する。IPA公開ページ