システム開発の発注で最初に作るものは分厚い仕様書ではありません。現場で止まっている一つの処理、変えられない条件、予算と期限の幅をそろえます。その材料を同じ形で開発会社へ渡し、提案と見積の前提を比べます。
受注管理を例にすると、画面だけを発注しても仕事は終わりません。FAXやメールを誰が受け取り、商品コードをどこで照合し、在庫不足を誰へ戻し、月末に新旧の数字を誰が確かめるのか。発注ではこの一連の仕事を契約と受入へつなげます。
システム開発を発注する五つの段階。画像を押すと拡大できます
システム開発の発注は、何から進めればよいか？
現場の実物と制約を集め、要件整理、依頼先比較、見積、契約、受入の順に一つずつ判断します。
デジタル庁のデジタル社会推進標準ガイドラインは、サービス・業務の企画、要件定義、調達、設計・開発、受入までを別の工程として扱っています。政府情報システム向けのルールですが、発注判断を一度に済ませない考え方は民間の業務システムにも使えます。
| 段階 | 社内で決めること | 開発会社へ確認すること |
|---|---|---|
| 要件整理 | 変えたい業務、変えられない条件、判断者 | 調査範囲、要件整理の成果物 |
| 依頼先比較 | 任せる工程、社内に残す判断 | 体制、責任者、類似業務の経験 |
| 見積 | 予算幅、後回しにできる範囲 | 前提、対象外、再見積の条件 |
| 契約 | 成果物、変更承認、検収責任者 | 責任分界、知的財産、引き継ぎ |
| 受入 | 業務シナリオ、合否、延期条件 | 受入環境、証拠、修正と再テスト |
最初の相談で五段階をすべて確定する必要はありません。分からない項目を「未確認」と残し、誰がいつ確かめるかを決めます。
相談前には、何を社内から集めるべきか？
通常と例外の実物、件数、利用者、停止時間、判断者、予算、期限を一枚のメモへまとめます。
IPAのユーザのための要件定義ガイドは、業務要件や運用、移行、テストを含めてユーザ側が判断する役割を示しています。自社だけで完成した要件書を書くという話ではありません。何を変えたいか、何を受け入れるかを発注者が判断できる状態にするということです。
発注前に決める7項目には、実物の集め方と初回相談の文面例があります。補助金を検討する場合は、同じ時点で2026年のデジタル化・AI導入支援制度の対象経費、契約日、事業完了期限を確認してください。採択前の発注や支払いが対象外になる制度もあるため、開発の都合だけで契約日を決めません。
依頼先は、何をそろえて比べればよいか？
契約の形、担当工程、責任者、成果物、引き継ぎ条件を同じ列へ並べ、会社名より役割を比べます。
採用、準委任、受託、継続型の外部チームでは、任せられる範囲と完成責任が違います。開発体制の比較を使い、要件整理だけを準委任で頼むのか、要件が固まった範囲を請負で頼むのかを分けます。
提案書では営業担当者の説明だけでなく、実際の責任者が誰かを確認します。週次会議へ出る人、要件の質問をまとめる人、障害時に判断する人が見えない提案は、開始後の動きも読めません。
見積は、どの条件をそろえて比較するのか？
対象業務、データ、連携、移行、テスト、運用準備、対象外、再見積条件を同じ表で比較します。
金額だけを横に並べると、範囲を狭く置いた提案が安く見えます。見積書に「データ移行一式」とあれば、抽出、変換、投入、照合、差分時の再実行まで含むかを聞きます。
既存システムから移る案件ではデータ移行の手順も先に確認してください。kintone固有の記事ですが、移行対象の決め方、変換、照合、切り戻しはほかの業務システムでも同じ論点になります。複数社の見積を読む手順はシステム開発の見積比較で、比較表の形まで整理しています。
契約には、何を残しておくべきか？
成果物、役割、変更手続、検収条件、知的財産、終了時の引き継ぎを契約書と別紙へ記載します。
IPAの情報システム・モデル取引・契約書（第二版）は、開発段階ごとの責務と複数契約の関係を解説し、契約書のひな型を公開しています。ひな型をそのまま貼るのではなく、自社の工程と成果物へ合わせて確認します。法律判断が必要な条項は専門家へ相談してください。
仕様変更が起きたときの手続も欠かせません。誰が変更を承認し、費用と納期をいつ見直し、合意前の作業をどう扱うか。口頭依頼のまま作業が進むと、受入時に契約範囲をたどれません。
受入条件は、いつ決めればよいか？
見積を比べる前に業務単位の合否を置き、契約時に受入責任者、証拠、延期条件まで明確にします。
「画面が動く」ではなく、「営業事務が匿名化したFAXを登録し、在庫不足を担当営業へ戻し、月末集計が旧システムと一致する」と業務で書きます。開発会社のテストと、発注者の受入は別です。
受入テストの進め方では通常、月末、承認者不在、連携先停止を分けています。納品日の前日に初めて試すのではなく、修正と再テストの日程を契約前から確保します。
発注前チェックリストは、どう使うか？
空欄を推測で埋めず、未確認の項目、確認する人、決める期限を一枚に残して打ち合わせへ持ち込みます。
打ち合わせ前に次の欄を確認します。
- 変えたい業務と、今の開始・終了地点
- 通常例と例外例の実物
- 件数、利用者、停止できない時間
- 正式なデータと外部連携先
- 社内の説明役と最終判断者
- 予算幅、希望期限、後回しにできる範囲
- 依頼先へ任せる工程と社内へ残す判断
- 見積の前提、対象外、再見積条件
- 契約の成果物、変更手続、引き継ぎ
- 受入責任者、業務シナリオ、延期条件
十項目がすべて埋まってから相談する必要はありません。空欄をそのまま見せれば、調査が必要な場所と社内で決める場所を分けられます。Heygoodへの相談では、現場の実物を見ながら最初の調査範囲を決めます。
システム開発 発注前チェックシートは、確認する人と期限まで書き込める印刷用の一枚です。フォーム入力はなく、ブラウザ上で確認してそのまま印刷できます。