外に出せるのは開発で、決める役割は残る

アジャイルで進める前提で、見積もりが出てきました。要件を全部決めてから作るのではなく、動くものを見ながら決めていけます。そのほうが速い、という説明も付いています。

それで頼むことにします。ただし、外に出せるのは開発のほうだけです。公開されているモデル契約に、そう書いてあります。

モデル契約の前提は、完成義務のない契約

IPAと経済産業省が公開している「情報システム・モデル取引・契約書（アジャイル開発版）」です。アジャイル開発を外部に委託するときの契約条項と、その解説と、補足資料でできています（IPA・経済産業省、アジャイル開発外部委託モデル契約）。2020年3月に公開され、2025年4月に更新されています（同モデル契約、更新履歴）。

集計された数字は出てきません。書かれているのは、契約を結ぶ前に両者で決めておくことです。

前提が二つあります。ひとつは開発手法で、スクラムを前提にしています。もうひとつは契約の種類で、準委任契約が前提です。条文は「乙が開発対象プロダクトの完成義務を負うものではないことを確認する」と書いています（同モデル契約、第5条第1項）。乙は委託先です。モデル契約は委託先を「ベンダ」と呼んでいるので、引用と項目名はその表記のままにしています。

モデル契約は、想定している状況も表にしています。発注する側の準備として「経営上のニーズや解決すべき課題（プロジェクトの目的）、開発対象プロダクトのビジョンが明確」、知識として「アジャイル開発及びスクラムに関する基礎的な理解あり」（同モデル契約、Ⅱ. 本モデル契約が想定するアジャイル開発）。開発規模は、一つのスクラムチームで収まるくらいの比較的小規模なものを想定しています（同）。

請負契約にすると何が起きるかは、条文ではなく解説に書かれています。挙げられているのは二つで、対価と実際の工数が離れることと、両者の利害が対立することです（同モデル契約、第1条の解説）。

契約前に確かめる項目は、21ある

モデル契約には「契約前チェックリスト」が別紙で付いています。九つの項目に、21のチェックポイントが並んでいます（同モデル契約、Ⅲ. 2 契約前チェックリスト）。

原典は、この21を九つのカテゴリに並べているだけです。そこで、書かれている項目をもとに、誰が用意するものかで分け直してみました。以下、項目の名前は短くしています。

委託先で確かめるのは三つです。スクラムマスターを選任できるか、必要な能力を持つ開発チームを組めるか、その開発チームを固定できるか（同、9 ベンダの体制）。

発注する側が用意するのは七つです。プロジェクトの目的とゴール、関係者の範囲、目的の共有、プロダクトのビジョン、ビジョンの共有、プロダクトオーナーの選任と権限委譲、プロダクトオーナーへの協力（同、1・2・8）。

残る11は、両者で合わせるものです。アジャイル開発の価値観の理解、スクラムの理解、開発対象が向いているか、規模が一つのチームで収まるか、初期計画、基礎設計、完了基準と品質基準、初期バックログ、準委任契約であることの理解、役割分担、体制（同、3〜7）。

プロダクトオーナーは、発注する側が選ぶ

プロダクトオーナーは、スクラムの用語です。モデル契約はこの語を定義していません。アジャイル開発の方式としてスクラムを使うことは、条文に置かれています（同モデル契約、第2条第1項）。契約書の中でスクラムの用語を使っていることも、断ってあります（同、Ⅲ. 1）。

モデル契約が決めているのは、誰が選ぶかと、何をするかです。選ぶのは発注する側です（同、第4条第2項）。

役割は七つ挙げられています。ビジョンと意義を示すこと、要求の一覧を作って優先順位を変えること、会議に出ること、関係者からの反応を伝えること、完成と完了の確認、必要な情報提供と意思決定を適時に行うこと、関係者との調整（同、第4条第3項）。

そして責任の置き場所が書かれています。「プロダクトオーナーの行為（不作為も含む。）に関する責任は全て甲が負う」（同）。甲は発注する側です。

やらなかったことも責任に入ります。意思決定が遅れて開発が止まったとき、それは発注した側に置かれます。

社内にいないときは、補佐までは頼める

解説は、社内に適した人がいない場合にも触れています。委託先にプロダクトオーナー補佐の人員を出してもらい、補助してもらうことも考えられる、と書いています（同モデル契約、第4条第2項の解説）。

ただし、そこで線が引かれています。「プロダクトに対して責任を持つプロダクトオーナーの職務自体をベンダ側に委ねるべきでない」（同）。

補佐は頼めます。職務は残ります。ここが、外に出せる部分と出せない部分の境目です。

モデル契約は冒頭でも同じことを書いています。「本モデル契約を使えば、誰でも簡単にアジャイル開発の外部委託ができるというわけではない」（同モデル契約、Ⅰ. はじめに）。

よくあるのは、七つの役割が社内の何人かに分かれている形です。優先順位を変える人と、完成を確認する人と、関係者に話す人が別々になります。条文は、七つをまとめてプロダクトオーナーに担わせる形にしています（同モデル契約、第4条第3項）。委託先が情報と決定を求める相手も、その人になります（同）。

偽装請負の線は、どこに引かれているか

解説は、受発注の関係でアジャイル開発を行うときに議論されてきた点にも触れています。厚生労働省が2021年9月に公表した疑義応答集の第3集です（同モデル契約、第3条の解説）。

示されている考え方はこうです。密に連携して情報を共有し、技術的な助言や提案を行っていたとしても、「実態として、発注者と受注者の関係者が対等な関係の下で協働し、受注者側の開発担当者が自律的に判断して開発業務を行っていると認められる場合であれば、偽装請負と判断されるものではありません」（同）。

反対の場合も書かれています。発注者側が受注者側の開発担当者に対して、直接、業務の遂行方法や労働時間などの指示を行うなど、指揮命令があると認められる場合は、偽装請負と判断されることになります（同）。

そして防ぎ方として挙げられているのが、役割や権限、開発チーム内の業務の進め方を予め明確にして、両者で合意しておくことです（同）。先に挙げたチェックリストの「役割分担」と「体制」は、ここにもつながっています（同モデル契約、7 体制（共通））。

明日からできること

頼む前に決めるのは、二つです。

ひとつは、プロダクトオーナーを誰にするか。部署名や役職ではなく、個人を一人指名します。兼務でも構いませんが、その人が上の七つを担います。

もうひとつは、その人に渡す権限。チェックリストは「権限委譲ができるか」を項目に置いています（同、8 ユーザの体制）。渡すのは、要求の優先順位を変える権限と、関係者との調整を進める権限です。

決めたら、書きます。条文は、体制と役割分担を別紙に書く形にしています（同モデル契約、第3条第1項・第2項）。口で決めただけだと、開発が止まったときに、その作業が発注する側と委託先のどちらの担当だったかを確かめられません。

この二つが決まらないうちは、契約を結ばないほうが安全です。準委任契約なので、決まっていなくても開発は始まり、時間ぶんの委託料は発生します。

一方で、急がなくてよいこともあります。要件を全部書き出す必要はありません。チェックリストが求めているのは「十分な初期バックログ」で、全体の仕様ではありません（同、5 初期計画）。

手法を変えることも先ではありません。プロダクトオーナーが決まらないなら、アジャイルにしても請負にしても、優先順位を決める人はいないままです。