社内に開発者がいない会社の外注先の選び方 ── 見積もりと契約の前に確かめること

社内にシステム開発の分かる人がいないまま、業務アプリの開発を外部に頼むことがあります。候補の会社から提案書と見積もりをもらっても、技術の中身では比べられません。

この記事では技術の分からない発注側でも比べられる点として、外注先が「進め方」と「契約で決めること」にどう答えるかを取り上げます。要件定義の進め方、見積もりの前提と変更の扱い、納入物と著作権、検収、作業する体制と再委託、預けるデータの扱い、納品後の保守です。物差しにはIPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」などの公的な資料を使います。

対象は社内向けの業務アプリを受託開発で作ってもらう場面です。契約書の条文の解釈や法的な判断は扱わないので、契約を結ぶ前には法務の担当者や専門家にも確認してください。依頼する前に自社で整理しておくことは「Windowsアプリ 外注・受託開発を依頼する前に整理したいこと」に、契約の結び方は「受託開発・運用保守の契約はどう結ぶべきか」にまとめています。

技術を見なくても比べられるところ

発注側が外注先のコードの出来を事前に見分けるのは難しくても、外注先が仕事の進め方をどう説明するかは比べられます。説明が具体的か、書面で示されるか、発注側にも作業や判断が必要なことを隠さずに言うか、という点です。

IPA のモデル取引・契約書はユーザー（発注側）とベンダー（外注先）が結ぶ契約のひな型です。条文には要件定義の分担、納入物の権利、検収、再委託、変更の手続き、セキュリティなど、発注側が決めておくべき事柄が並んでいます¹。この並びをそのまま質問の一覧にすれば、技術の分からない発注側でも候補を同じ物差しで比べられます。

flowchart TB
        accTitle: 外注先の候補を比べる観点
        accDescr: 外注先の候補に同じ質問をして、要件定義の進め方、見積もりと変更、納入物と著作権、検収、体制と再委託、預けるデータ、保守の答えを比べる流れを示す。
        A["外注先の候補"] --> Q["同じ質問をする"]
        Q --> P1["要件定義の進め方"]
        Q --> P2["見積もりの前提と変更"]
        Q --> P3["納入物と著作権"]
        Q --> P4["検収と体制"]
        P4 -.-> P5["再委託・預けるデータ・保守"]
        P1 --> C["答えを並べて比べる"]
        P2 --> C
        P3 --> C
        P4 --> C

図1: 候補に同じ質問をして、進め方と契約の各点への答えを並べて比べる。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全8件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

要件定義の進め方

要件を決めるのは発注側

要件定義はシステムで何をするかを決める工程です。IPA の「ユーザのための要件定義ガイド」は、システムの要件を定義する責任は、そのシステムを使って事業に役立てるユーザー側にあると書いています²。モデル契約でも、要件定義書を作るのは発注側（甲）で、外注先（乙）は専門的な知識に基づいて調査・分析・提案・助言などで支援する、という分担になっています³。

開発者がいない会社でも、業務の流れ、例外の扱い、必要な帳票などを決めるのは自社です。外注先にはその決め方をどう手伝ってくれるかを聞きます。

• 誰がどのくらいの回数と期間で要件定義の打ち合わせを進めるか
• 要件定義の成果として、どんな文書を作り、誰が承認するか
• 発注側が用意する資料と、担当者が使う時間の見込み

発注側に必要な作業を具体的に挙げるか、「お任せください」とだけ答えるかは、比べる手がかりになります。

工程ごとに契約を分ける

モデル契約は開発の全工程を1本の契約にまとめず、工程ごとに個別契約を結ぶ多段階契約を軸にしています¹。要件定義は準委任の支援業務として契約し、要件が決まってから開発部分を見積もって契約する、という順序です。

flowchart TB
        accTitle: 多段階契約で工程ごとに個別契約を結ぶ流れ
        accDescr: 基本契約のもとで、要件定義の支援を準委任の個別契約で行い、要件が決まった後に開発を見積もって別の個別契約を結び、次に運用準備や移行の個別契約を結ぶ流れを示す。
        BASE["基本契約"] --> R["個別契約1: 要件定義の支援（準委任）"]
        R --> RD["要件定義書を発注側が確定"]
        RD --> EST["開発部分の見積もり"]
        EST --> D["個別契約2: 開発（請負または準委任）"]
        D --> M["個別契約3: 運用準備・移行"]

図2: 要件が決まってから開発を見積もり、工程ごとに個別契約を結ぶ。

要件が決まる前に、開発全体の金額と納期を確定する提案を受けることもあります。モデル契約の考え方とは違うので、その金額が何を前提にしているか、前提が変わったときにどう扱うかを聞きます。前提を書面で示せない提案は、後で追加費用の話になったときに比べる根拠がありません。

見積もりの前提と変更の扱い

見積もりの金額はどの機能をどこまで作るか、どの環境で動かすか、何を外注先がやり発注側が何をやるか、といった前提の上に成り立っています。候補ごとに前提が違えば、金額だけを並べても比べたことになりません。見積もりの内訳と、含まれない作業を書いてもらいます。

作り始めてから仕様を変えたくなることもあります。モデル契約では、確定した仕様書の変更は変更管理手続によってのみ行うとしています³。変更の提案を書面で出し、費用や納期への影響を含めて協議して決める手続きです。

flowchart TB
        accTitle: 変更管理手続の流れ
        accDescr: 仕様を変えたいときに変更の提案を書面で出し、費用や納期への影響を含めて協議し、合意した内容を記録してから作業に反映する流れを示す。
        A["仕様を変えたい"] --> B["変更の提案を書面で出す"]
        B --> C["費用・納期への影響を協議"]
        C --> D["合意した内容を記録"]
        D --> E["作業に反映"]

図3: 仕様の変更は書面の提案から始め、影響を協議して合意した内容を記録してから反映する。

候補には変更を頼まれたときの進め方を聞きます。口頭の依頼をその場で引き受けると説明する会社より、変更の内容と影響を文書にして確認する会社のほうが、どの変更でいくら増えたかを後から追えます。

納入物と著作権

納入物に含めるもの

モデル契約の定義では、開発するソフトウェアは、プログラム、コンテンツ、データベース類、関連資料など、個別契約で定めたものです³。何が納品されるかは、契約で書いた分だけだと考えたほうが安全です。

候補には次のものを納入物に含めるかを聞きます。

• ソースコード
• 設計書と、データベースの構造の説明
• ビルドと配布の手順
• 運用と障害対応の手順書

後で別の会社に保守を頼む可能性があるなら、ソースコードや設計書がないと困ります。ソースコードや仕様書がないシステムを引き継いだときに何が起きるかは「ソースコードも仕様書もないシステムを引き継いだら」に書いています。

著作権の扱い

モデル契約の「納入物の著作権」の条項（第45条）には、3つの案があります³。

flowchart TB
        accTitle: 納入物の著作権の3つの案
        accDescr: モデル契約の納入物の著作権の条項で、A案は外注先に帰属、B案は汎用的なプログラムを除き委託料の完済時に発注側へ移転、C案は新たに作ったプログラムを共有にすることを示す。
        CL["納入物の著作権（第45条）"] --> A["A案: 外注先に帰属"]
        CL --> B["B案: 完済時に発注側へ移転"]
        CL --> C["C案: 発注側と外注先の共有"]
        B -.-> BX["汎用的なプログラムは外注先に残る"]
        C -.-> CX["汎用的なプログラムは除く"]

図4: 納入物の著作権は外注先に帰属させるか、発注側へ移すか、共有にするかを選ぶ。

どの案がよいかは、ソフトウェアの性質や価格によって変わります。比べるときは、候補がどの案を前提にしているか、その理由は何かを聞き、将来ほかの会社に改修を頼むときにソースコードを渡して直してもらえるかを、合わせて確かめます。納入物の所有権がいつ移るかも、モデル契約では個別契約で定める時期としています³。

第三者のソフトウェアとオープンソース

業務アプリには、外注先が作る部分のほかに、OSやデータベースなどの第三者のソフトウェアや、オープンソースのソフトウェア（FOSS）が含まれます。モデル契約では、外注先がそれらを使うときは、利用の必要性や利用許諾の条件などを書面で示して提案し、発注側が採否を決めるとしています³。候補には使う予定の製品やライブラリと、その利用条件を一覧で示せるかを聞きます。

検収の進め方

納品されたものが要件どおりかを確かめて受け入れることを、検収と言います。モデル契約では、発注側が外注先と協議して、テスト項目、テストデータ、テスト方法、テスト期間を定めた検査仕様書を作ります。納品されたソフトウェアは、その検査仕様書に基づいて発注側が検査し、合格なら検査合格書を渡し、不合格なら具体的な理由を書面で示して修正を求めます³。

flowchart TB
        accTitle: 検査仕様書に基づく検収の流れ
        accDescr: 発注側が外注先と協議して検査仕様書を作り、納品後にそれに基づいて検査し、合格なら検査合格書を渡し、不合格なら理由を書面で示して修正を求める流れを示す。
        S["検査仕様書を協議して作る"] --> N["納品"]
        N --> T["検査仕様書に基づいて検査"]
        T --> J["合格か"]
        J -->|"合格"| OK["検査合格書を渡す"]
        J -->|"不合格"| NG["理由を書面で示して修正を求める"]
        NG --> T

図5: 検収は、事前に作った検査仕様書に基づいて発注側が検査し、合否を書面で返す。

開発者がいない会社にとって、検査仕様書を自分たちだけで作るのは負担です。候補にはテスト項目の洗い出しをどう手伝ってくれるか、納品前に外注先側でどんなテストをして、その結果をどんな形で渡してくれるかを聞きます。検収の期間内に確かめる時間を発注側が取れるかも、見積もりの段階で決めておきます。

作業する体制と再委託

窓口と打ち合わせ

モデル契約では、双方が責任者を決め、進捗やリスク、課題を話し合う連絡協議会を、個別契約で定めた頻度で定期的に開くとしています³。候補には発注側の窓口になる人、打ち合わせの頻度、議事録を誰が作るかを聞きます。

開発を1人の担当者に頼っている会社では、その人が抜けたときに作業が止まるおそれがあります。担当者が替わるときにどう引き継ぐか、ソースコードや文書がどこに置かれ、誰が見られるかも聞いておきます。

再委託

外注先が作業の一部を別の会社に任せることを再委託と言います。モデル契約の再委託の条項には再委託に発注側の事前の書面承諾を求めるA案と、外注先の裁量に任せつつ発注側が報告を求めたり中止を請求したりできるB案があります。どちらの案でも、外注先は再委託先にも同じ義務を負わせ、再委託先の作業について自ら作業した場合と同じ責任を負います³。

flowchart TB
        accTitle: モデル契約の再委託の2つの案
        accDescr: 再委託の条項で、A案は発注側の事前の書面承諾を求め、B案は外注先の裁量に任せつつ発注側が報告や中止を求められ、どちらも外注先が再委託先と同じ義務の契約を結び、自ら作業した場合と同じ責任を負うことを示す。
        SUB["再委託の条項"] --> A["A案: 発注側の事前承諾"]
        SUB --> B["B案: 外注先の裁量"]
        B -.-> BR["発注側は報告と中止を求められる"]
        A --> SAME["再委託先にも同じ義務"]
        B --> SAME
        SAME --> LIA["外注先が自ら作業した場合と同じ責任"]

図6: 再委託は事前承諾か外注先の裁量かを選び、どちらでも外注先が責任を負う。

候補には再委託をする予定があるか、あるなら相手と任せる範囲を聞きます。再委託の有無そのものより、聞かれたときに相手と範囲を示せるかが比べる手がかりになります。

預けるデータとセキュリティ

開発や保守の途中で、業務データや顧客の情報を外注先に渡すことがあります。IPA の「中小企業の情報セキュリティ対策ガイドライン」は、重要な情報を委託先に提供する場合、委託先がどのような対策をしているかを考慮する必要があるとしています。委託先の不備で情報が漏れても、委託元として管理責任を問われるからです。業務の一部を委託する場合は、契約書に情報セキュリティに関する委託先の責任や実施すべき対策を明記し、合意する必要があるとも書いています⁴。

渡すデータに個人データが含まれるなら、個人情報保護法の委託先の監督（第25条）も関わります。個人情報保護委員会のガイドラインは必要な措置として、適切な委託先の選定、委託契約の締結、委託先での取扱状況の把握を挙げています。委託先が再委託する場合も、事前に報告を受けるか承認することなどが望ましいとしています⁵。

flowchart TB
        accTitle: 外注先に渡すデータと確かめること
        accDescr: 外注先に渡すデータについて、委託先の対策を確かめ、契約で責任と対策を合意し、個人データを含む場合は委託先の選定、契約、取扱状況の把握と再委託の扱いまで確かめる流れを示す。
        D["外注先に渡すデータ"] --> M["委託先の対策を確かめる"]
        M --> K["契約で責任と対策を合意"]
        D --> PD["個人データを含むか"]
        PD -->|"含む"| S["選定・契約・取扱状況の把握"]
        S --> RE["再委託の報告や承認"]

図7: 渡すデータは委託先の対策と契約での合意を確かめ、個人データなら再委託まで監督する。

作るソフトウェアのセキュリティについては、モデル契約に、具体的な機能や管理体制、費用負担を協議してセキュリティ仕様を書面で確定する条項があります。条文の案の一つでは、ソフトウェア開発業務を始める前までに確定するとしています³。候補には渡したデータをどこに置き、誰が触れ、作業が終わったらどう消すかと、セキュリティ仕様をいつどう決めるかを聞きます。

納品後の保守

業務アプリは納品して終わりではありません。不具合の修正、OSや周辺ソフトの更新への対応、業務の変化に合わせた改修が続きます。IPA は開発用とは別に、保守運用の委託のためのモデル契約書も公開しています¹。保守で何を定額の範囲に含め、何を別に見積もるかは「受託開発・運用保守の契約はどう結ぶべきか」で取り上げています。

候補には納品後に保守を引き受けるか、引き受けるなら範囲と費用の決め方、問い合わせの窓口を聞きます。保守を別の会社に頼むことになっても困らないよう、前の節の納入物とあわせて考えます。

候補を同じ質問で比べる

ここまでの点を候補に同じ形で聞くための表にまとめます。相見積もりを取るときは、この表の質問を依頼の文書に入れておくと、答えを横に並べて比べられます。

答えを比べるときは、聞いたことに具体的に答えないこと、口頭の約束だけで書面にしないこと、発注側の負担を「不要です」と言い切ることに気をつけます。前の2つは、後で認識の違いが出たときに、何を約束したかを確かめる手段がなくなるからです。3つ目は、モデル契約が発注側と外注先の双方の作業を前提にしていること（第8条）と合いません³。

小さく始めて見極める

多段階契約では最初の個別契約を要件定義の支援などの小さな範囲で結べます。その工程で、外注先がどんな文書を作り、打ち合わせをどう進め、質問にどう答えるかを実際に見てから、開発の契約に進むかを決められます¹。

flowchart TB
        accTitle: 小さな個別契約で外注先を見極める流れ
        accDescr: 最初に要件定義の支援などの小さな個別契約を結び、成果物と進め方を確かめ、満足できれば開発の契約に進み、そうでなければ別の候補を検討する流れを示す。
        A["小さな個別契約（要件定義の支援など）"] --> B["成果物と進め方を確かめる"]
        B --> C["次の工程に進むか"]
        C -->|"進む"| D["開発の個別契約"]
        C -->|"見直す"| E["別の候補を検討"]

図8: 最初の工程を小さな契約にして、成果物と進め方を見てから次に進むかを決める。

既存のシステムを作り直す場合は、今のシステムの調査を最初の範囲にする方法もあります。どちらの場合も、最初の工程の成果物（要件定義書や調査の報告書）を発注側が受け取れるようにしておくと、別の会社に切り替えるときの材料になります。

関連記事

• Windowsアプリ 外注・受託開発を依頼する前に整理したいこと
• 受託開発・運用保守の契約はどう結ぶべきか
• 偽装請負にならないための準委任契約の正しい働き方
• ソースコードも仕様書もないシステムを引き継いだら
• 中小企業のセキュリティ対策、何から始めるか

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

社内に技術が分かる人がいなくても、外注先の良し悪しは判断できますか？

コードの出来を直接評価するのは難しくても、要件定義の進め方、見積もりの前提、変更の扱い、納入物と著作権、検収、再委託、預けるデータの扱い、保守について、候補ごとに同じ質問をして答えを比べることはできます。答えが具体的で、書面で示されるかどうかが比べる手がかりになります。

最初から開発全体の金額を確定してくれる会社のほうが安心ではないですか？

IPAのモデル取引・契約書は、工程ごとに契約を分け、要件定義が終わってから開発を見積もる多段階契約を軸にしています。要件が決まる前に総額を確定する提案を受けたときは、その金額が何を前提にしているか、前提が変わったときにどう扱うかを確かめます。

ソースコードは納品してもらうべきですか？

モデル契約では、納入物に何を含めるかを個別契約で定めます。後で別の会社に保守を頼む可能性があるなら、ソースコードや設計書を納入物に含めるか、納入物の著作権をどの案で扱うかを契約の前に確かめます。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。