第三者検証と業務委託契約で気にすること

はじめに

今回は第三者検証 を委託することで発生する問題などを記載しようと思います。
単純にテスト丸投げされることが多いと思いますが、それだけでは品質を維持することや上げることは契約上難しくなることが多々あるため、第三者検証として気にしておくべきポイントをまとめます。

    1.「準委任（SES）」か「請負」か

多くの上手くいかない理由がここにあり、トラブルを生んでいると思います。
この二選はどちらが正しいかというより、ケースに併せて使い分けられているか？が重要となると思います。そして、使い分けが上手くいっておらず何をするべきかを見失う現場があります。

• 請負契約
• 特徴：成果物（テスト結果報告書など）に対して対価を支払う
• 問題：仕様変更が発生するなど成果物への影響が多い場合、上手く進まない。
• 準委任契約
• 特徴：工数（人月）に対して対価を支払う
• 問題：最後までテストが完了しなかったとしても支払いが発生する。

    2.責任分界点のあいまいさ
「テストをやってくれるはず」という契約元からの期待値のズレが、後から業務の障壁となります。例えば、バグ修正後の「再テスト」費用に関して、バグが見つかるのは良いことですが、その修正を確認するテストや、他に影響がないか見るリグレッションテストは工数に含まれているか？ここが漏れると追加で費用がかかり揉めることがあります。
また、テスト環境の準備と維持に関して、「テスト端末の用意」「OSのアップデート」「テストデータの流し込み」はどちらの責任か？など、特に実機検証が必要なスマホアプリなどは、端末代金や通信費の負担を明確にする必要があります。

    3.知的財産の帰属
意外と注目されていないのが、業務終了後の資産についてです。こちらは公正な契約関係となれなくなり、生産性のない活動に対して業務が発生し続けるケースの元についてです。

• テストケース（手順書）の所有権
  

  契約が終了した後、そのテストケースを委託元で使い回せますか？「委託先のノウハウだから」という理由で、著作権が委託先に残る契約になっていると、契約を継続せざる負えない状況を作りパワーバランスが悪くなります。

• スクリプトの権利
  

  自動テストを導入した場合、そのコードの所有権が自社にないと、他社への切り替えや内製化ができなくなり顧客の自由選択の幅を減らします。

第三者検証は開発チームと密に連携するため、法律上のリスクが生じやすくなります。

• 直接指示の禁止
  

  「請負」や「準委任」の場合、発注者が委託先のスタッフに直接「明日の朝までにこれやって」と指示を出すと「偽装請負」とみなされる可能性があります。

• 注意点

  必ず委託側のリーダー（もしくは窓口の担当者）を通して指示を出す仕組みをしてもらう必要があります。多くの場合これが難しくなることがありますが、問題ないことなのか問題あることなのかは理解しておくべきです。

第三者検証の価値は「客観的な指摘」ですが、これが「開発チームとの対立」を生むことが多々あります。

• 報告ルートの不備
  

  バグ起票ルールが曖昧だと、開発側が「そんな書き方じゃ直せない」と反発し、修正のサイクルが遅れます。

• 会議体への参加
  

  進捗会議への参加費用が契約に含まれているか。情報共有が漏れると、QAチームが「古い仕様」でテストを続けるという最悪のロスが発生します。