受け入れテストの進め方｜発注側が確かめる項目と手順

2026年8月9日

＠SOHO編集部

この記事のポイント

✓受け入れテストの進め方を
✓目的と他のテストとの違い
✓合格の判断と検収後の扱いまで

システムの開発を外部に頼み、納品の前に受け入れテストをしてほしいと言われたものの、発注側として何をどこまで確かめればよいのか分からない、という担当者は多いはずです。受け入れテストとは、完成したシステムやソフトウェアが、発注側が求めた内容を満たし、実際の業務で使えるかどうかを、発注側が自分で確かめるテストのことです。この記事では、受け入れテストの目的と他のテストとの違い、契約と検収との関係、計画の立て方、確かめる項目、テストケースの作り方、不具合の記録と判定、合格の判断と検収後の扱いまでを、発注側の担当者が順に進められるように説明します。テストの作業と不具合の対応を複数人で共有する道具として、プロジェクト管理ツールのPinatecaにも後半で触れます。

受け入れテストとは何か

受け入れテストは、英語ではUAT（User Acceptance Test、利用者による受け入れのテスト）と呼ばれます。システム開発の会社の解説記事は、次のように説明しています。

受け入れテストとは、完成したシステムやソフトウェアが要件を満たしているかを検証するためのテストです。実際の運用環境もしくはそれに近い環境で、ユーザーのニーズを満たし、実務上の不具合や使いにくさがないかを確認します。出典: skygroup.jp

ここで使われている「要件」とは、発注側がシステムに求める機能や性能、使い方の条件をまとめたもののことです。開発の最初の段階で、要件定義書などの文書にまとめられます。

受け入れテストの特徴は、開発した側ではなく、発注した側が行うことです。開発の会社は、納品の前に自分たちでもテストを行いますが、それは「設計どおりに作れているか」を確かめるものです。受け入れテストは、「自分たちの業務で本当に使えるか」を、実際に使う人の目で確かめるものです。

受け入れテストの目的

受け入れテストの目的は、大きく3つあります。

要件を満たしているかを確かめる：要件定義書や仕様書に書いた機能が、そのとおりに動くかを確かめる
実際の業務で使えるかを確かめる：書類の上では要件を満たしていても、実際の業務の流れで使うと手順が多すぎる、画面が分かりにくい、といった問題がないかを確かめる
納品を受け入れるかを判断する：テストの結果をもとに、納品物を受け取って代金を支払うかどうかを判断する

前述の解説記事は、受け入れテストを軽く扱う危険について、次のように注意しています。

受け入れテストの目的は、納品されたシステムがユーザーの要件やニーズを満たし、実際の利用環境で成果物として認められるかを見極めることです。受け入れテストを軽視してしまうと、実務を行う段階になって初めて予想外の不具合に悩まされる、といった事態が起こりかねません。出典: skygroup.jp

システムの本番の利用が始まってから問題が見つかると、業務が止まり、直すための費用や時間の負担も大きくなります。受け入れテストは、その前の最後の関門です。

他のテストとの違い

システムの開発では、受け入れテストの前に、開発の会社がいくつかの段階のテストを行います。それぞれの違いを整理します。

テストの種類	行う人	確かめること
単体テスト	開発の会社	プログラムの部品が1つずつ正しく動くか
結合テスト	開発の会社	部品を組み合わせたときに正しく動くか
システムテスト（総合テスト）	開発の会社	システム全体が設計どおりに動くか
受け入れテスト	発注側	業務で使えるか、要件を満たしているか

システムテストと受け入れテストは、どちらもシステム全体を確かめる点では似ています。違いは、システムテストが「設計どおりか」を開発の会社の目で確かめるのに対し、受け入れテストは「業務で使えるか」を発注側の目で確かめる点です。設計そのものが業務に合っていなかった場合、システムテストでは見つからず、受け入れテストで初めて見つかることがあります。

受け入れテストの中に、運用の担当者が運用の手順を確かめる運用テストや、本番に近い量のデータで性能を確かめる性能のテストを含めることもあります。どこまでを受け入れテストに含めるかは、契約で決めておきます。

受け入れテストと検収と契約の関係

受け入れテストは、契約の上では「検収」と深く結び付いています。検収とは、納品されたものが契約の内容に合っているかを発注側が検査し、受け取ることを確認する手続きのことです。多くの契約では、検収が終わったことで納品が完了し、代金の支払いの時期が決まります。

民法の決まり

システムの開発の契約は、多くの場合、民法の請負（仕事の完成を約束し、その結果に対して報酬を支払う契約）として結ばれます。民法では、請負の報酬は、原則として仕事の目的物の引渡しと同時に支払うとされています。

納品されたものが契約の内容に合っていない場合（契約不適合）について、民法は、発注側（注文者）がその不適合を知った時から1年以内に受注側（請負人）に知らせなければ、修補の請求などができなくなる、と定めています。

前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。出典: e-Gov法令検索民法第637条

履行の追完とは、足りない部分を直して契約どおりの状態にすることです。システムであれば、不具合の修正にあたります。ただし、契約でこれと違う期間や条件を決めることもでき、実際のシステムの開発の契約では、検収の完了から一定の期間に限って責任を負う、と定めることが多くあります。

モデル契約書での検収の決まり

情報処理推進機構（IPA）は、システムの開発の契約の参考になる「情報システム・モデル取引・契約書」を公開しています。そのひな型では、発注側（甲）が検査の基準となるテストの項目、テストのデータ、テストの方法、テストの期間などを定めた検査仕様書を作り、その仕様書に基づいて、決められた検査期間の中で納品物を検査する流れが示されています。

ひな型の中で、発注側が特に気をつけたいのが次の決まりです。

3.　検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を明示して異議を述べない場合は、本件ソフトウェアは、本条所定の検査に合格したものとみなされる。出典: IPA 情報システム・モデル取引・契約書（第二版）

つまり、検査期間の中に、不合格の理由を書面で伝えなければ、合格したとみなされる、という決まりです。これを「みなし合格」と呼ぶことがあります。受け入れテストが忙しくて期間内に終わらなかった、問題に気づいていたが連絡が遅れた、という場合でも、合格として扱われるおそれがあります。自社の契約に同じような決まりがあるかを、受け入れテストを始める前に必ず確かめてください。

契約の条項の解釈や、個別の紛争の判断は、契約の内容や事情によって変わります。判断に迷うときは、弁護士などの専門家に相談してください。

受け入れテストの計画の立て方

受け入れテストは、納品の直前になってから考え始めると、時間も人も足りなくなります。計画は、開発の途中、遅くともシステムテストが始まる頃までに立てておきます。

計画に書くこと

目的と範囲：何を確かめるか、どの機能を対象にするか
体制：テストの責任者、テストを行う人、不具合を判定する人、開発の会社の窓口
日程：テストの期間、再テストの期間、検収の期限
環境：テストに使う機器、ネットワーク、テストの環境のURL、利用者のアカウント
データ：テストに使うデータ。本番に近いデータを使う場合は、個人情報の扱いを決める
合格の基準：どんな状態なら合格とするか
不具合の扱い：不具合の記録の方法、重さの分け方、修正の依頼の流れ

期間の見積もり

テストの期間は、テストケースの数と、テストを行う人の数から見積もります。1件のテストケースを確かめるのに平均15分かかり、テストケースが200件あれば、確かめるだけで50時間になります。不具合が見つかった場合の再テストの時間も加えると、余裕を持った期間が必要です。

期間の目安を2週間と見積もった場合でも、不具合の修正を待つ時間と再テストの時間を加えると、全体ではその1.5倍から2倍ほどを見込んでおくと安心です。受け入れテストを行う人は、普段の業務と並行してテストをすることが多くなります。テストを行う人の業務の調整を、計画の段階で上司と相談しておきます。

発注側の体制と役割

受け入れテストは、発注側の誰か1人が抱えて進めるものではありません。次の役割を決め、誰が受け持つかを計画に書きます。

テストの責任者：テストの全体を管理し、合格かどうかの最終の判断を行う。検収の書類に署名する立場の人か、その人に判断の材料を渡す人
テストの担当者：テストケースを実際に確かめる人。システムを日々使う部署の人を必ず含める
業務の専門家：業務の流れや例外の処理に詳しい人。テストケースの作成と、結果の判断に加わる
情報システムの担当者：テストの環境、アカウント、データの準備を受け持ち、開発の会社との技術の面のやり取りを担う
開発の会社の窓口：不具合の連絡を受け、修正の予定を返す人。発注側の窓口と1対1で決めておく

小さな会社では、1人が複数の役割を兼ねることになります。その場合でも、実際にシステムを使う現場の人には、必ずテストに加わってもらいます。情報システムの担当者だけでテストをすると、操作に慣れた人の目でしか確かめられず、初めて使う人がつまずく箇所を見落とします。

テストの担当者の人数は、テストケースの数と期間から決めます。担当者ごとに受け持つ業務の範囲を分けると、確かめる範囲の重なりや漏れを防げます。

受け入れテストで確かめる項目

受け入れテストで確かめる項目は、システムの種類によって違いますが、おおむね次のように分けられます。

機能

要件定義書や仕様書に書いた機能が、すべてそろっているか
入力、登録、検索、変更、削除、出力などの操作が、正しく動くか
計算の結果（金額、税、日数など）が正しいか
誤った入力をしたときに、分かりやすい案内が出るか

業務の流れ

実際の業務の手順どおりに、最初から最後まで操作できるか
月末の締め、年度の切り替えなど、時期によって変わる処理が正しく動くか
例外的な場面（取消し、返品、差戻しなど）の処理ができるか

使いやすさ

画面の文言や配置が、実際に使う人に分かりやすいか
よく使う操作が、少ない手順でできるか
スマートフォンやタブレットで使う場合、画面の表示が崩れないか

性能

本番に近い量のデータで、画面の表示や検索に時間がかかりすぎないか
多くの人が同時に使ったときに、動きが遅くならないか

権限と安全

利用者の役割ごとに、見られる情報と操作できる範囲が正しく分かれているか
ログインやパスワードの扱いが、決めたとおりになっているか

周りのシステムとのつながり

会計、在庫、顧客の管理など、他のシステムとのデータのやり取りが正しく行われるか
古いシステムからのデータの移行が、漏れなく正しく行われているか

帳票と出力

請求書、納品書、報告書などの帳票が、決めた様式どおりに出力されるか
印刷したときに、文字の欠けやページの区切りの崩れがないか

テストケースの作り方

テストケースとは、「どの条件で、何を操作したら、どういう結果になれば正しいか」を1件ずつ書いたものです。受け入れテストの質は、テストケースの質で決まります。

テストケースに書く項目

番号
確かめる機能や業務
前提の条件（どの利用者で、どのデータがある状態か）
操作の手順
期待する結果
実際の結果
判定（合格、不合格）
確かめた日と確かめた人

テストケースの例

受注のシステムで、注文を登録する機能のテストケースの例を示します。

番号：UAT-012
確かめる業務：電話で受けた注文の登録
前提の条件：営業の担当者の権限でログインしている。在庫が10個ある商品Aが登録されている
操作の手順：1. 注文の登録の画面を開く、2. お客様を検索して選ぶ、3. 商品Aを3個入力する、4. 配送の希望日を入力する、5. 登録のボタンを押す
期待する結果：注文が登録され、注文の番号が表示される。商品Aの在庫の表示が7個になる。注文の一覧に、今日の日付で表示される

この例のように、期待する結果は「正しく登録される」とまとめずに、画面に何が表示され、どのデータがどう変わるかまで書きます。期待する結果があいまいだと、テストの担当者によって合否の判断が分かれます。

業務の流れから作る

テストケースは、仕様書の機能の一覧から作るだけでなく、実際の業務の流れから作ります。たとえば受注のシステムであれば、「お客様から電話で注文を受け、在庫を確かめ、注文を登録し、出荷を指示し、請求書を発行する」という一連の流れを、1つのシナリオとしてテストします。機能ごとのテストでは問題がなくても、流れでつなげると、前の画面の入力が次の画面に引き継がれない、といった問題が見つかります。

普段と違う場面を入れる

正常な操作だけでなく、次のような場面のテストケースも作ります。

入力の欄を空のまま登録しようとする
決められた桁数を超える数字を入力する
同じデータを二重に登録しようとする
処理の途中で画面を閉じる、戻るボタンを押す
権限のない利用者で、見てはいけない画面を開こうとする

テストケースの数は、多ければよいわけではありません。すべての組み合わせを確かめようとすると、件数が膨らんで期間内に終わらなくなります。業務への影響が大きい機能、よく使う機能、お金の計算に関わる機能を優先し、影響の小さい機能は代表的な操作に絞ると、限られた期間で重要な問題を見つけやすくなります。

こうした場面は、開発の会社のテストでも確かめられていることが多いですが、業務の現場でよく起きる誤った操作は、現場をよく知る発注側のほうが思いつきやすくなります。

受け入れテストの進め方

受け入れテストは、次の流れで進めます。

ステップ1：テストの環境とデータを確かめる

テストを始める前に、テストの環境が使えるか、利用者のアカウントがそろっているか、テストのデータが入っているかを確かめます。環境の準備が整っていないと、テストの初日から作業が止まります。

ステップ2：テストを行う人に説明する

テストを行う人に、テストの目的、テストケースの見方、結果の記録の方法、不具合を見つけたときの連絡の方法を説明します。

ステップ3：テストケースを順に確かめる

テストケースを順に確かめ、結果を記録します。期待した結果と違う場合は、画面の写しと、操作の手順と、そのときのデータを記録します。

ステップ4：不具合を記録して判定する

見つかった問題を不具合として記録し、重さを判定します。判定の方法は次の節で説明します。

ステップ5：修正を依頼し、再テストする

不具合の修正を開発の会社に依頼し、修正されたら、その部分と、修正の影響を受けそうな部分を再テストします。

ステップ6：合格を判断する

すべてのテストケースの結果と、残っている不具合の状況を見て、合格かどうかを判断します。

不具合の記録と重さの判定

受け入れテストで見つかった問題は、不具合の一覧に記録します。記録する項目は次のとおりです。

番号と見つけた日
見つけたテストケースの番号
問題の内容と、再現の手順
画面の写し
重さ
担当と、修正の状況（未対応、修正中、修正済み、再テスト済み）

重さの分け方

不具合の重さは、業務への影響の大きさで、たとえば次の3段階に分けます。

重さ	内容	扱い
重大	業務が止まる、データが壊れる、計算が誤る	修正するまで合格にしない
中	業務はできるが、手間がかかる、回避の方法がある	本番の利用の開始までに修正する
軽微	文言の誤り、表示の小さな崩れ	時期を決めて修正する

不具合か要望かを分ける

受け入れテストで出る指摘の中には、不具合ではなく、新しい要望が混ざることがあります。要件定義書や仕様書に書いていないことを「こうしてほしい」と求めるのは、不具合の修正ではなく、仕様の変更です。仕様の変更は、追加の費用や納期の延長につながることがあります。

指摘を記録するときは、「仕様書のどこと違うか」を書くようにすると、不具合と要望を分けやすくなります。仕様書に書いていない指摘は、要望として別の一覧に分け、本番の利用の開始後に対応するか、追加の契約で対応するかを、開発の会社と話し合います。

開発の会社との進め方

受け入れテストは発注側が行うテストですが、開発の会社との協力なしには進みません。次の点を、テストの前に開発の会社と決めておきます。

連絡の方法と窓口：不具合をどの方法で、誰に連絡するか。電話や口頭ではなく、記録が残る方法にする
回答の期限：不具合の連絡を受けてから、修正の予定を返すまでの期限
修正の版の受け渡し：修正したものをテストの環境にいつ反映するか。反映するたびに、修正した不具合の番号の一覧をもらう
判定が分かれたときの話し合い：不具合か仕様の変更かで意見が分かれたときに、誰と誰が話し合って決めるか
定例の打ち合わせ：テストの期間中、週に1回か2回、進み具合と残っている不具合を確かめる場を設ける

開発の会社との関係を良く保つことも、受け入れテストを円滑に進めるために大切です。不具合の連絡は、責める言葉ではなく、事実と再現の手順を淡々と伝えます。修正が早かったときは感謝を伝えると、次の修正も早く返ってきやすくなります。

合格の判断と検収

受け入れテストの最後に、合格かどうかを判断します。判断の基準は、計画の段階で決めておきます。たとえば次のような基準です。

すべてのテストケースを確かめ終えている
重大な不具合が残っていない
中の不具合は、修正の時期が決まっている
業務の流れのシナリオが、すべて最後まで通る

合格の判断は、テストの責任者が1人で決めるのではなく、テストの担当者と業務の専門家の意見を聞いてから行います。テストの結果の数字だけでは見えない「現場で使えるか」という感触は、実際に操作した人がいちばんよく知っているためです。

合格と判断したら、検収の書類（検査合格書、検収書など）を開発の会社に渡します。不合格の場合は、不合格の具体的な理由を書面で伝え、修正を求めます。前述のとおり、契約によっては検査期間の中に理由を書面で伝えないと合格とみなされるため、期限を必ず守ります。

検収の後に見つかった不具合

検収が終わったあとに不具合が見つかった場合の扱いは、契約で決まります。IPAのモデル契約書のひな型では、検収の完了の後に、納品物とシステムの仕様書との不一致（バグを含む）が見つかった場合、発注側は修正などを請求でき、その責任を負う期間を契約で定める形になっています。自社の契約で、責任を負う期間と、知らせる方法を確かめ、不具合を見つけたらすぐに書面で知らせます。

テストのデータの準備と個人情報

受け入れテストでは、本番に近いデータを使うほど、実際の業務で起きる問題を見つけやすくなります。一方で、本番のデータには、お客様や社員の個人情報が含まれていることがあります。テストのデータの準備では、次の点に気をつけます。

架空のデータで足りるかを先に考える：多くの機能は、架空の名前や住所のデータで確かめられる。架空のデータを作るときは、実在しない値であることが分かる形にする
本番のデータを使うときは加工する：名前、住所、電話番号、メールアドレスなどを、別の値に置き換えてから使う。置き換えた結果、データの件数や桁数の特徴が変わらないようにする
扱える人を限る：テストの環境に入れる人と、データを見られる人を限る
テストが終わったら削除する：テストの環境のデータは、テストが終わって不要になったら削除する

テストのデータに含まれるメールアドレスには、特に注意が必要です。テストの環境で通知のメールを送る機能を確かめたときに、実在のお客様のアドレスにメールが届いてしまう事故が起こりえます。テストの環境からはメールが外に送られない設定になっているかを、テストを始める前に開発の会社と確かめておきます。

本番の利用の開始に向けた準備

受け入れテストに合格したら、本番の利用の開始に向けた準備に移ります。受け入れテストの結果は、この準備にもそのまま生かせます。

利用者への説明：テストで多くの人がつまずいた操作は、利用者向けの説明資料で重点的に説明する
操作の手引きの見直し：テストケースの操作の手順は、そのまま操作の手引きの下書きになる
残っている不具合の周知：時期を決めて修正する軽微な不具合や、回避の方法がある不具合は、利用者に事前に知らせる
データの移行の確認：古いシステムから本番のデータを移す場合は、移したあとに件数と主な値を確かめる手順を決めておく
問い合わせの窓口：本番の利用の開始の直後は、使い方の問い合わせが増えるため、社内の窓口と開発の会社の連絡の体制を決めておく

本番の利用の開始の日は、業務が忙しい時期を避けて決めます。月末の締めや繁忙期の直前に切り替えると、問題が起きたときの影響が大きくなります。古いシステムを一定の期間並行して動かし、問題があれば戻せるようにしておく方法もあります。

受け入れテストでつまずきやすい点

受け入れテストでよくある失敗を挙げます。

開発の会社に任せきりにする：テストケースの作成も実施も開発の会社に任せると、「設計どおりか」の確認にとどまり、業務で使えるかが確かめられない
期間が足りない：納品の直前に始めて、テストが終わらないまま検収の期限を迎える
実際に使う人が参加しない：情報システムの担当者だけでテストをして、現場の使いにくさを見落とす
不具合と要望が混ざる：仕様にない要望を不具合として扱い、開発の会社ともめる
記録が残っていない：口頭で不具合を伝え、修正されたかどうかが分からなくなる
再テストを省く：修正された部分だけを確かめ、修正の影響でほかの部分が動かなくなったことに気づかない

テストの作業と不具合を管理する道具

受け入れテストでは、テストケースの一覧、不具合の一覧、修正の状況を、発注側の複数の担当者と開発の会社の間で共有する必要があります。小さなシステムであれば、表計算ソフトの一覧を共有するだけでも十分に回ります。

一方で、テストを行う人が多い、不具合の件数が多い、開発の会社とのやり取りが頻繁になる、といった場面では、担当と期限と進み具合を複数人で共有できるプロジェクト管理ツールを使う方法があります。選択肢の1つが、ボードで仕事を進めるプロジェクト管理のPinatecaです。公式サイトによると、カンバン、ガントチャート、カレンダー、リストなど8種類のボードとチャットが無料のプランから使えます。不具合を1件ずつカードにして、「未対応」「修正中」「再テスト待ち」「完了」の列で動かす使い方ができます。カードには「重さ」や「テストケースの番号」などの項目を自由に追加でき、画面の写しを添付できます。カードごとのコメントで、再現の手順の確認や修正の内容のやり取りを残せます。表の形で全件を並べ、絞り込んで一括で直せるリストのボードもあり、不具合の一覧を重さごとに確かめるのに使えます。権限の役割を細かく決められ、社外のゲストの招待にも対応していると案内されているため、開発の会社の担当者と同じボードを見ることもできます。公式の料金ページでは、5人までのチームなら期限なしで無料、ボードは10個まで、クレジットカードの登録は不要とされています。6人目、または11個目のボードからはスタンダードプランになり、料金は1人あたり月額500円（税抜）で、閲覧だけのゲストは人数に数えないと案内されています。合格かどうかの判断や契約の上の手続きは発注側の責任者が行うもので、Pinatecaは作業と不具合の状況を共有するための道具です。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

受け入れテストの力を仕事に生かす

受け入れテストで作ったテストケースと不具合の記録は、検収が終わったあとも大切な資料になります。システムの改修のたびに、同じテストケースで主な機能を確かめれば、改修の影響で以前の機能が動かなくなっていないかを確かめられます。記録は捨てずに保存しておきます。

受け入れテストを計画し、テストケースを作り、不具合を判定できる力は、発注側の担当者にとっても、テストの仕事を専門に受ける人にとっても、価値のある力です。システムの品質を確かめる仕事の内容は、QA・テスト・コードレビューのお仕事で紹介されています。

介護や福祉の事業所で記録のシステムを入れ替える場合のように、業種に特有の業務の流れがあるシステムでは、現場の職員が受け入れテストに加わることが特に大切です。介護や福祉の事業所のシステムの導入については、介護・福祉事業所のDX化2026｜IT導入補助金で介護記録を完全デジタル化で詳しく説明しています。

在宅ワークや業務委託の仲介を2004年から続けてきた運営者として見てきた限りでは、外部の人に制作や開発を任せて満足のいく結果を得ている発注者ほど、最後の確認の基準を最初の段階で受け手と共有しています。何をもって完成とするかが先に決まっていれば、受け手は迷わずに作業でき、発注者も確認の時間を短くできます。仲介の手数料が乗らない直接の取引であれば、その分の予算を、テストや確認の時間に回すこともできます。サイトや画面のデザインを任せる場合の報酬の目安は、デザイナーの年収・単価相場でまとめています。

よくある質問

Q. 受け入れテストとシステムテストの違いは何ですか？

システムテストは、開発の会社がシステム全体を設計どおりに動くかどうか確かめるテストです。受け入れテストは、発注側が自分の業務で実際に使えるか、要件を満たしているかを確かめるテストです。設計そのものが業務に合っていなかった場合は、システムテストでは見つからず、受け入れテストで初めて見つかることがあります。

Q. 受け入れテストのテストケースは誰が作りますか？

受け入れテストは発注側が行うテストなので、テストケースも発注側が作るのが基本です。IPAのモデル契約書のひな型でも、発注側が検査の基準となるテストの項目や方法を定めた検査仕様書を作る流れが示されています。開発の会社に作成の支援を頼むことはできますが、業務の流れや現場でよく起きる誤った操作は、発注側が加えます。

Q. 受け入れテストが期間内に終わらないとどうなりますか？

契約によっては、検査期間の中に不合格の理由を書面で伝えないと、合格したとみなされる決まりがあります。IPAのモデル契約書のひな型にも同じ趣旨の条項があります。テストが終わらない見込みのときは、期間の延長を早めに開発の会社と書面で合意してください。契約の解釈に迷うときは、弁護士などの専門家に相談してください。