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

記事「社内に開発者がいない会社の外注先の選び方 ── 見積もりと契約の前に確かめること」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

情報システム・モデル取引・契約書は、工程ごとに個別契約を結ぶ多段階契約を軸にし、要件定義は発注側が要件定義書を作り外注先が準委任で支援する形をとる。開発は要件が確定してから行い、セキュリティ仕様も開発の前に書面で確定する案がある。確定した仕様の変更は変更管理手続で扱い、検収は発注側が外注先と協議して作った検査仕様書に基づいて行う。外注先が個人データの取扱いを再委託する場合、委託元は事前の報告や承認などで再委託先まで監督することが望ましい。

flowchart LR
    accTitle: 外注先の選び方の知識マップ
    accDescr: 情報システム・モデル取引・契約書の多段階契約と個別契約、要件定義と準委任契約、要件定義やセキュリティ仕様が開発に先行すること、変更管理手続、検収と検査仕様書、再委託と個人情報保護法の委託先の監督の関係を示します。
    multi_stage_contract["多段階契約"]
    requirements_definition["要件定義"]
    acceptance_inspection["検収"]
    subcontracting["再委託"]
    model_transaction_contract["情報システム・モデル取引・契約書"]
    individual_contract["個別契約書"]
    quasi_mandate_contract["準委任契約"]
    detailed_design_development["内部設計〜プログラミング〜テスト"]
    security_specification["セキュリティ仕様"]
    change_management_procedure["変更管理手続"]
    inspection_specification["検査仕様書"]
    personal_data_outsourcing_supervision["委託先の監督(個人情報保護法第25条)"]
    model_transaction_contract -->|"利用する"| multi_stage_contract
    multi_stage_contract -->|"利用する"| individual_contract
    quasi_mandate_contract -->|"推奨される対応"| requirements_definition
    requirements_definition -->|"より先に行うべき"| detailed_design_development
    security_specification -.->|"より先に行うべき"| detailed_design_development
    model_transaction_contract -->|"利用する"| change_management_procedure
    acceptance_inspection -->|"前提とする"| inspection_specification
    subcontracting -.->|"前提とする"| personal_data_outsourcing_supervision

概念間の関係(全8件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• 情報システム・モデル取引・契約書は多段階契約を利用します。情報システム・モデル取引・契約書は、開発の全工程を1本の契約にまとめず、工程ごとに個別契約を結ぶ多段階契約を軸にしている。 / 確度: 確立した関係 / 確認日: 2026-11-01 出典 出典
• 多段階契約は個別契約書を利用します。基本契約のもとで、要件定義作成支援、ソフトウェア開発、運用準備・移行支援などの業務ごとに個別契約を結び、作業内容や契約類型、委託料、納入物を定める。 / 確度: 確立した関係 / 確認日: 2026-11-01 出典
• 準委任契約は要件定義に対する本記事の推奨です。モデル契約では、要件定義書は発注側が作り、外注先は専門的な知識に基づき善良な管理者の注意をもって調査・分析・提案・助言などで支援する(要件定義作成支援業務)。完成を約束する請負ではなく、準委任の形をとる。 / 確度: 確立した関係 / 確認日: 2026-11-01 出典 出典
• 要件定義は内部設計〜プログラミング〜テストより先に行うべきです。モデル契約では、ソフトウェア開発業務は確定したシステム仕様書(要件定義書と外部設計書)に基づいて行い、開発部分は要件が決まってから見積もって個別契約を結ぶ。 / 確度: 確立した関係 / 確認日: 2026-11-01 出典 出典
• セキュリティ仕様は内部設計〜プログラミング〜テストより先に行うべきです。モデル契約のセキュリティの条項には、具体的な機能や管理体制、費用負担を協議し、ソフトウェア開発業務を開始する前までにセキュリティ仕様を書面で確定させる案がある。もう一つの案は確定の時期を定めていない。 / 確度: 条件付きの関係 / 確認日: 2026-11-01 出典
• 情報システム・モデル取引・契約書は変更管理手続を利用します。モデル契約では、確定した仕様書の内容の変更は変更管理手続によってのみ行う。変更の提案を書面で出し、費用や納期への影響を含めて協議して決める。 / 確度: 確立した関係 / 確認日: 2026-11-01 出典
• 検収は検査仕様書を前提とします。モデル契約では、発注側が外注先と協議して作った検査仕様書に基づいて、納品されたソフトウェアを検査期間内に検査し、合格なら検査合格書を、不合格なら理由を示した書面を交付する。 / 確度: 確立した関係 / 確認日: 2026-11-01 出典
• 再委託は委託先の監督(個人情報保護法第25条)を前提とします。外注先が委託された個人データの取扱いを再委託する場合、委託元は、再委託の相手方や業務内容について事前に報告を受けるか承認し、定期的な監査などで再委託先まで監督が及ぶことを確認することが望ましい。個人データを預けない委託には当てはまらない。 / 確度: 条件付きの関係 / 確認日: 2026-11-01 出典

主要概念の定義

多段階契約

システム開発の全工程を1本の契約にまとめず、工程ごと(または工程のまとまりごと)に契約を分けて結ぶ方式。

要件定義

システム開発の工程のうち、何を作るかを発注側が主体となって決め、ベンダがその検討を支援する段階。

検収

納品物が合意した内容どおりかを確認して受け入れる、契約上の手続き。

再委託

委託を受けた者が、委託された業務の一部をさらに第三者に委託すること。

情報システム・モデル取引・契約書

システム開発の委託契約と運用保守委託契約のひな形と解説をまとめた公的文書。経済産業省が2007年に第一版を、IPAが引き継ぎ2020年に第二版を公開した。

準委任契約

専門家として業務を行うことに対して報酬を支払う契約類型。受託側は完成責任を負わず、善管注意義務を負う。

セキュリティ仕様

情報システム・モデル取引・契約書で、開発するソフトウェアのセキュリティ対策について、具体的な機能、遵守方法、管理体制、費用負担などを協議して書面で定めたもの。システム仕様書の一部を構成する。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このデータセットについて

作成

合同会社小村ソフト

ライセンス

CC BY 4.0 ── 出典(合同会社小村ソフト)とライセンスへのリンクを明示し、改変した場合はその旨を示すことを条件に、再配布・改変を含めて再利用できます

最終確認日

2026-11-01 ── 収録する関係のうち、最後に出典と照合した日

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。