システム開発の依頼のしかた｜依頼前の整理と依頼先の選び方

システム開発を外部に依頼するときは、開発会社を探し始める前に「何のために」「どこまで」「いくらで」「いつまでに」を自社の言葉で整理しておくことが、結果を最も大きく左右します。依頼先の選定や契約は、その整理が終わってから進めるほうが、見積もりの比較も契約内容の確認も格段にしやすくなります。

本記事では、2026年10月時点の情報をもとに、システム開発を初めて外部に依頼する企画・情報システム担当の方に向けて、依頼前に整理する項目、依頼先のタイプ別の向き不向き、依頼の進め方、契約と体制の考え方、失敗を避ける要点を順に解説します。

依頼前に整理すること

依頼前に整理すべきことは、目的と効果、範囲、予算、期限の4点です。ここが曖昧なままだと、どの開発会社に頼んでも見積もりの根拠がそろわず、比較ができません。

目的と効果

目的は「システムを作ること」ではなく「どの業務課題をどう変えたいか」で書きます。目的が業務の言葉で書かれていると、開発会社は機能の提案だけでなく、作らなくてよいものの提案もできるようになります。

効果は、可能な範囲で「何がどれだけ変われば成功か」を決めておきます。たとえば「月末の手作業での集計をなくす」「問い合わせの一次回答までの時間を短くする」のように、変化の方向が分かる書き方で十分です。厳密な数値目標が出せない段階でも、判断基準の候補を書いておくことが、後の検収や追加要望の線引きに役立ちます。

範囲と予算

範囲は「やること」と同じ重みで「やらないこと」を書き、予算は上限と使える時期をあわせて伝えます。この2つがそろうと、提案内容が自社の想定からずれにくくなります。

範囲では、対象とする業務、利用する部署、既存システムとの連携の有無、データ移行の要否を挙げます。予算では、初期開発の費用だけでなく、稼働後の保守・運用の費用も想定に含めます。費用の相場感はシステム開発費用の相場と見積もりの考え方で整理しています。

以上をまとめたものが、次の依頼前チェックリストです。記載例は架空の題材（社内の備品申請を電子化するケース）です。

整理する項目	書く内容	記載例（架空）
目的	解決したい業務課題	紙とメールで行う備品申請を一本化し、承認の滞留をなくしたい
効果	成功と言える変化	申請から承認までの流れが画面上で追え、総務の転記作業がなくなる
範囲（やること）	対象業務・利用者・連携先	備品の申請・承認・発注依頼までを対象とし、利用者は全社員
範囲（やらないこと）	今回は対象外とする事項	会計システムとの自動連携は今回は対象外とし、別途検討する
予算	上限額と、保守・運用の想定	初期開発の上限と、稼働後の年間の保守費の目安を社内で合意済み
期限	稼働希望時期と、その理由	新年度の申請開始に合わせて稼働したい（変更不可の理由として明記）
社内の体制	決裁者・窓口・業務の判断者	決裁は総務部長、窓口は担当者1名、業務判断は総務課の代表者

依頼前に整理する目的・効果・範囲・予算・期限の5項目を並べたチェックリスト風の図解

依頼先の種類

依頼先は、開発会社、フリーランス、コンサルを挟む選択の3つに大別でき、案件の規模と、自社で整理できている度合いによって向き不向きが分かれます。

依頼先	向いている場面	留意点
開発会社	要件がある程度固まっており、設計から運用までを一括で任せたい場合	体制は厚い一方、見積もりの前提条件が曖昧だと、追加費用の協議になりやすい
フリーランス	小規模で範囲が明確、または既存システムの改修など機動力を重視する場合	担当者が1人のため、稼働できない期間の備えと、引き継ぎ資料の扱いを決めておく必要がある
コンサルを挟む	要件が固まっておらず、依頼内容の整理や開発会社の比較を支援してほしい場合	開発そのものは別の依頼先が担うため、役割の線引きと費用が二重になりすぎない設計が必要

開発会社

開発会社は、設計・開発・テスト・運用までを組織として担える点が強みで、中規模以上の案件や、複数の担当者が必要な案件に向いています。

一方で、会社ごとに得意な業種や技術、標準的な進め方が異なります。同じ依頼でも、業務理解に時間をかける会社と、パッケージを活用して早く立ち上げる会社とでは提案の形が変わるため、比較の観点をそろえて聞くことが大切です。選定の観点はシステム開発会社の選び方でも詳しく扱っています。

フリーランス

フリーランスは、小規模で範囲がはっきりした案件や、既存システムの改修のように担当者の経験が直接効く案件で力を発揮します。

意思決定が早く、窓口が一本化される利点があります。そのぶん、病気や他案件の都合で稼働が止まったときの代替手段、ソースコードや設計書の引き渡し範囲を、依頼の時点で取り決めておく必要があります。契約の個別の条項は、専門家への確認をおすすめします。

コンサルを挟む選択

コンサルを挟む選択は、要件がまだ言語化できていない段階で、依頼内容の整理と開発会社の比較・選定を第三者に支援してもらう方法です。

編集部が実務経験者への取材で聞く範囲では、初めての依頼でつまずく原因は、開発会社の技術力よりも、発注側の整理不足から生じる認識のずれにあることが多いようです。要件整理や選定を支援する専門家を挟むと、開発会社に渡す提案依頼書の質が上がり、比較もしやすくなります。ただし、これは編集部の見方であり、すべての案件で当てはまるわけではありません。

コンサルタントは、法人のエージェントを介した三者間の契約で関わることが実務上の基本とされています（ドメイン知識ベース「案件獲得の基本ルート」）。依頼する側は、役割と費用の範囲をあらかじめ明確にしておくとよいでしょう。PMOやITコンサルタントの探し方はITコンサルタント・SIer系フリーランスエージェント比較が参考になります。

依頼先の選び方

依頼先は、自社の案件に近い実績があるかと、進め方を具体的に説明できるかの2点で見極めると、判断を誤りにくくなります。

実績の見方

実績は、件数や社名の知名度ではなく、自社の案件との近さで見ます。業種、規模、連携する既存システムの有無、稼働後の保守まで担当した経験があるかが、確認の中心です。

実績の説明を受けるときは、「その案件で難しかった点は何か」「どう解決したか」を尋ねます。成功した点だけでなく、想定外の出来事への対応を具体的に語れる依頼先は、実務の経験が厚いと考えられます。守秘義務で社名が出せない場合は、業種と規模、担当範囲の説明を求めれば判断材料になります。

進め方の確認

進め方の確認では、要件をどの段階で確定するか、進捗をどう共有するか、仕様変更が出たときにどう扱うかを事前に聞いておきます。

特に、仕様変更の扱いは契約後のトラブルの火種になりやすい項目です。変更の申し出から見積もり、合意までの手順が決まっているかを確認してください。システム開発全体の流れはシステム開発の流れを工程別に整理する記事で確認できます。

依頼の進め方

依頼は、提案依頼書の作成、提案の受領、見積もりの比較、選定、契約の順に進めます。最初に提案依頼書で条件をそろえることで、後の比較が成り立ちます。

提案依頼書の作り方

提案依頼書（RFP）は、依頼先に同じ条件で提案してもらうための書面で、前半の整理項目をそのまま転記する形で作れます。

記載する項目の目安は次のとおりです。

依頼の背景と目的、期待する効果
対象とする業務の範囲と、対象外とすること
利用者の数と利用部署、既存システムとの連携の有無
希望する稼働時期と、その理由
予算の上限と、保守・運用の想定
求める提案の内容（体制、進め方、見積もり、実績）と回答の期限
機密情報の取り扱いと、セキュリティに関する要求

性能、可用性、セキュリティなどの非機能要求は、機能と比べて後回しになりがちです。IPAが公開する「非機能要求グレード」は、ユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的に、非機能要求項目を網羅的にリストアップして分類し、それぞれの要求レベルを段階的に示したものです。提案依頼書に非機能要求を書く際の項目の抜けを防ぐ参考になります（IPA「非機能要求グレード」、2026年10月参照）。

提案書の構成の考え方はシステム開発提案書サンプルの構成、要件の書き方は要件定義書のフォーマット・書き方が参考になります。

見積もりの比較

見積もりの比較では、金額の大小より、見積もりに含まれる範囲と前提条件がそろっているかを先に確認します。前提がそろわない金額は、そもそも比較できません。

比較の際は、次の点を表に書き出して並べると違いが見えます。

確認する点	見るポイント
含まれる工程	要件定義、設計、開発、テスト、移行、教育、運用のどこまでか
前提条件	利用者数、データ量、連携先など、見積もりの前提が書かれているか
対象外の事項	含まれない作業が明記されているか
変更時の扱い	仕様変更が生じたときの見積もりの手順が決まっているか
稼働後の費用	保守・運用の範囲と費用が示されているか

見積もりの見方の詳細はシステム開発の見積もりの見方にまとめています。

提案依頼書の作成から提案の受領、見積もりの比較、選定、契約までの依頼の進め方を示す流れ図

契約と体制

契約では、契約形態の違いを理解したうえで責任の範囲を確認し、体制では、窓口と役割を文書で決めておくことが欠かせません。

契約形態の種類

システム開発の契約形態は、主に請負契約と準委任契約に分かれ、成果物の完成義務があるかどうかが大きな違いです。

請負契約は成果物の完成・納品が報酬の対象で、受託側に完成義務があります。準委任契約は業務の遂行そのものに報酬が発生し、成果物の完成義務はありません（ドメイン知識ベース「業務委託契約の形態」）。要件がまだ固まっていない上流工程では準委任、仕様が固まった開発工程では請負と使い分ける考え方もありますが、どちらが適切かは案件の内容によって異なります。

契約書のひな型としては、経済産業省とIPAが2020年12月22日に公表した「情報システム・モデル取引・契約書（第二版）」があります。ユーザ企業、ITベンダ、関連業界団体、法律専門家が参画して議論を重ね、ユーザ企業・ITベンダのいずれかにメリットが偏らない契約書作成を目指していることが特長とされています。見直しの論点には、セキュリティ、プロジェクトマネジメント義務及び協力義務、重大な過失の明確化、複数契約の関係、再構築対応が挙げられています（IPA「情報システム・モデル取引・契約書（第二版）」、2026年10月参照）。

個別の契約条項の是非や、自社の案件にどの形態が合うかの判断は、弁護士などの専門家に確認してください。

窓口と役割

窓口と役割は、発注側と受託側の双方で、担当者の名前と判断できる範囲まで決めておきます。窓口が曖昧だと、確認の往復が増え、判断が止まります。

発注側では、決裁者、窓口担当者、業務内容を判断できる現場の代表者の3つの役割を分けて置くと、判断の滞りを防げます。役割の整理にはシステム開発の体制図の作り方が使えます。モデル契約の論点にも「協力義務」が含まれているとおり、開発は発注側の協力があって成り立つものです。資料の提供や確認の期限を、体制の一部として決めておきましょう。

失敗を避けるために

失敗の多くは、要件の伝え方と進捗の確認という2つの運用面に集まるため、この2点を仕組みにしておくことが有効です。

要件の伝え方

要件は、「やりたいこと」だけでなく、判断の理由と優先順位、そして「やらないこと」をあわせて伝えます。これが抜けると、開発会社は善意で機能を補い、費用と期間がふくらみます。

伝えるときは、次の3点をそろえると誤解が減ります。

機能を「必須」「あれば望ましい」「今回は見送る」の3段階に分ける
それぞれの機能が必要な理由を、業務の言葉で一文添える
画面や帳票の例が手元にあれば、現行の様子を共有する

編集部が見聞きする範囲では、「やらないこと」を書面に残していたかどうかが、追加費用の協議の進めやすさに影響するようです。これは編集部の見方であり、案件によって事情は異なります。

進捗の確認方法

進捗の確認は、定例会の頻度と、確認する成果物をあらかじめ決めておくことで、早い段階のずれに気づけます。完成間際にまとめて確認するやり方は、手戻りが大きくなりやすい傾向があります。

定例会では、予定と実績の差、未決事項と決める人、次の期間の作業を毎回同じ形式で共有してもらいます。中間成果物（画面の試作や設計書など）を段階的に確認し、違和感があればその場で伝えることが、後工程の手戻りを小さくします。

依頼先の選定や進め方に不安がある場合は、依頼内容の整理を支援するコンサルタントやPMOの知見を借りる方法もあります。

出典・参考情報

IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2026-10-05参照）
IPA（独立行政法人情報処理推進機構）「非機能要求グレード」（2026-10-05参照）

本記事は2026年10月時点の情報に基づきます。契約・法令に関する記述は一般的な考え方の整理であり、個別の契約内容の是非については専門家にご確認ください。最終更新日: 2026年10月5日