システム開発を外注する手順｜失敗しない発注の進め方

システム開発を外注する手順は、目的整理、対象範囲の決定、依頼資料の作成、開発会社の比較、契約、開発・検収、運用準備の7段階です。小規模な開発では、詳細な仕様書を最初から完成させる必要はありません。「何を改善したいか」「初回リリースで何を実現するか」「誰が判断するか」を発注側で決め、開発会社と確認できる形にします。

機能数や見積金額の低さだけを比べても、失敗は防げません。見積もりの前提、対象外の作業、双方の役割、完成とみなす条件、リリース後の責任まで比較する必要があります。では、相談前に発注者はどこまで決め、どこから開発会社と詰めればよいのでしょうか。

執筆：株式会社adding編集部

システム開発を外注する手順は7段階

1. 解決したい業務課題と目的を言葉にする

最初に、現在の業務と変えたい状態を書き出します。機能一覧は、その目的に合う解決策を検討してから具体化できます。誰が、どの場面で、何に困っているのか。システム導入後にどの業務がどう変われば、投資を続ける判断ができるのかを整理します。

「申請システムが欲しい」という要望だけでは、入力画面に加えて承認経路、通知、集計のどこまで必要なのか判断できません。先に次の項目を一枚に整理すると、解決手段を比較しやすくなります。

• 対象となる利用者と業務
• 現在の手順、利用中のツール、困りごと
• 開発によって変えたい状態
• 必ず守る期限や社内ルール
• 導入後の責任者と評価方法

この五項目から新規開発の必要性も判断します。既存サービスの導入や運用変更で目的を満たせるなら、それも有力な選択肢です。

2. 初回リリースの範囲と優先順位を決める

要望をすべて同じ重要度で並べると、見積金額を見てから慌てて機能を削ることになります。必須、できれば必要、将来対応の三つに分け、初回リリースで検証したい価値を絞ります。MVPで選ぶのは、事業上の仮説を確かめるために必要な最小範囲です。機能数の少なさそのものを目的にすると、検証に必要な機能まで失うおそれがあります。

業務システムでは、画面とともに利用人数、権限、扱うデータ、既存システムとの連携、バックアップ、障害時の連絡、利用端末などを確認します。IPAの非機能要求グレード2018は、可用性や性能、セキュリティなどについて、利用者と開発者の認識違いを防ぐための確認項目と要求レベルを示しています。全項目を最高水準にすると決めず、事業への影響に応じた水準を合意するために使います。なお、IPAは同ページを2023年8月時点のアーカイブ情報としています。

AI機能を組み込む場合は、期待する入出力、誤った出力が起きたときの扱い、人が確認する箇所、利用データ、外部AIサービスへ送る情報、ログの保存方針を決めます。AIが速くできるのは実装作業です。要件定義、設計、レビュー、テストは人が責任を持ちます。

3. 相談・見積もりに必要な資料をそろえる

小規模開発で大部のRFP（提案依頼書）が常に必要とは限りません。ただし、各社へ異なる説明をすると見積条件がそろわず、金額を比較できなくなります。最低限、次の内容は同じ資料で渡します。

• 開発の背景、目的、対象利用者
• 現行業務と希望する業務の流れ
• 必須機能と優先順位
• 非機能要件、データ、外部連携の条件
• 希望時期と予算上限の有無
• 依頼したい範囲と自社で担う範囲
• 提案書や見積書に記載してほしい項目

この七項目を各社へ共通で渡せば、提案内容の差を案件への理解や進め方の差として比較できます。デジタル庁のデジタル社会推進標準ガイドラインでは、2026年7月15日更新の要件定義書と調達仕様書の標準テンプレートが公開されています。政府情報システム向けの資料なので、小規模案件では見落としを探すチェックリストとして必要な欄を参照すると実務的です。

4. 開発会社を同じ条件で比較する

候補先には、MVP、業務システム、既存システム改修、AI機能組み込みなど、今回の領域に対応できるかを確認します。既存システムの改修では、使用技術に加え、ソースコード、設計資料、インフラ、外部サービスの契約状況を調査できるかも重要です。

提案と見積もりでは、総額に加えて次を横並びにします。

• 見積もりの前提と不確定な項目
• 要件定義、設計、テスト、リリースの作業範囲
• 納品物と検収条件
• 発注者に求める情報提供、確認、承認
• 追加費用が生じる条件と変更手順
• 開発後の保守、障害対応、データ移行の範囲
• 担当体制と意思決定の進め方

この七項目がそろって初めて、総額の差を判断できます。安い見積もりでも、要件定義やデータ移行、リリース作業が対象外なら、発注後の負担が増えます。項目が多い提案についても、目的に不要な範囲が含まれていないかを確かめます。質問への回答が具体的で、未確定事項とその決め方を説明できる会社を選ぶのが妥当です。

5. 作業を始める前に契約と責任範囲を合意する

契約書では、契約類型の名称だけで安心せず、実際の作業と責任が一致しているかを確認します。対象業務、成果物、スケジュール、報告方法、検収方法、変更管理、再委託、秘密情報、個人情報、セキュリティ、知的財産権、保守の扱いを具体化します。

要件が固まっていないのに、開発全体を確定額・確定納期として扱えば、どこかで前提の食い違いが表面化します。要件定義と実装を分けて契約する、一定期間ごとに対象範囲を見直すなど、不確実性に合った進め方を双方で選ぶべきです。

IPAは情報システム・モデル取引・契約書（第二版）で、受託開発や保守運用のモデル契約とひな型を公開しています。同ページでは、仕様、プロジェクト管理方法、検収方法などを契約時に双方で確認する考え方も示されています。参照法規は公表当時の版に基づくとの注意書きがあるため、ひな型を案件に合わせ、必要に応じて法務の専門家へ確認してください。

6. 開発中も発注者が判断を止めない

開発会社に任せるのは、合意した範囲の設計や実装です。業務上の優先順位、許容できる運用負荷、社内ルールとの整合は発注者が判断します。

定例会では進捗率に加えて、動く画面や試作品を確認し、未決事項、リスク、変更要求、次回までの決定者と期限を記録します。決定を口頭だけで残すと、後から仕様変更なのか認識違いなのかを判別できません。特にAI機能は、期待する回答例、許容できない出力、人へ切り替える条件を実データに近い形で検証します。

IPAのユーザのための要件定義ガイド 第2版も、業務部門のユーザが要件定義へ主体的に関与する必要性を示しています。発注者が関与する目的は、事業判断を実装へつなぐことです。

7. 検収と運用開始を別々に考えない

完成の判定条件は契約前に決めます。必須機能の受入テスト、権限ごとの操作、データ移行結果、エラー時の動作、必要な文書を確認し、不具合と追加要望を分けて記録します。納品直前に条件を決めると、見積もりの前提と検収基準を結び付けられません。

運用開始までに、管理者、問い合わせ窓口、障害時の連絡経路、アカウント発行・削除、バックアップ確認、外部サービスの契約名義、保守範囲を明らかにします。ソースコードを受け取るだけでは、別の担当者が保守できる状態とは限りません。環境情報、権限、更新手順、既知の制約も引き継ぎ対象です。

失敗しない発注の判断基準

発注前の最終確認では、次の五つに答えられるかを見ます。

1. 解決したい業務課題と初回リリースの目的は何か
2. 必須範囲と後回しにする範囲はどこか
3. 発注者と開発会社は、それぞれ何を決めるか
4. 見積もり、納品、検収、変更の条件は何か
5. リリース後に誰が運用し、どこまで保守を依頼するか

五つのうち答えが曖昧な項目は、「未確定」と明示し、確定する工程・担当者・期限を合意します。未確定事項が残ること自体より、決め方がないまま作業が進む状態を避けるべきです。

相談前に発注者がそろえるのは、目的、優先順位、制約、決定者です。詳細な画面仕様まで完成している必要はありません。実現方法と技術上の詳細は、開発会社と詰めます。冒頭の問いに対する境界はここにあります。システム開発の外注手順をこの境界に沿って進めれば、発注後も事業側の判断を保ち、見積もり・契約・検収を同じ目的につなげられます。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る