システム開発の発注とは？発注までの流れと発注者が決めることを解説
【結論】システム開発の発注とは、作りたいシステムの要件を発注者が決め、見積もりと契約を経て、開発会社に作業を依頼することです。
- IPAの資料は、要件定義を発注者の責任としています。
- 見積もりは、情報が増えるにつれて段階を分けて出し直すやり方が示されています。
- 超上流（企画・要件定義）とそのあとの開発では、契約の形が変わることがあります。
この記事では、システム開発を初めて発注する担当の方に向けて、発注までの流れと、発注者が決めることをまとめます。見積もりの対象と内訳は別記事「システム開発の見積もりとは？」に、概算と正式の使い分けは「概算見積もりとは？」にまとめています。
システム開発の発注とは
システム開発の発注とは、作りたいシステムの要件を発注者が決め、見積もりと契約を経て、開発会社に作業を依頼することです。
IPA-SEC（情報処理推進機構 ソフトウェア・エンジニアリング・センター）の開発プロセス共有化部会がまとめた資料「超上流から攻めるIT化の原理原則17ヶ条」は、原理原則9で「要件定義は発注者の責任である」としています。発注者が要件を決め、責任を持つという意識を社内に浸透させることが、行動規範の1つに挙がっています。
発注までの流れ（共通フレームの考え方）
IPA（情報処理推進機構）の資料「ソフトウェア開発の標準プロセス」（アーカイブ、2011年、室谷隆）は、共通フレームの考え方として、企画・要件定義・開発・運用・保守までをひとつながりのライフサイクルで捉えるとしています。発注は、このうち企画と要件定義の段階（超上流）を経て行います。
| 段階 | 主な中身 |
|---|---|
| 企画 | システム化の方向性とシステム化計画を決める |
| 要件定義 | 業務要件、機能要件、非機能要件を決め、発注者側の利害関係者で合意する |
| 発注・契約 | 見積もりを受け、契約の形と範囲を決める |
| 開発 | 設計・製作・テストを行う |
| 運用・保守 | 本稼働後の運用と、必要な保守を行う |
同じ資料は、要件定義プロセスの目的を「新たに構築する業務、システムの仕様を明確化し、それをベースにシステム化範囲とその機能を具体的に明示すること」と説明しています。
発注前に発注者が決めること
原理原則9は、要件定義を発注者の責任とする行動規範として、業務部門とIT部門が二人三脚で要件定義を進めること、発注者側に立った支援を受けることを挙げています。
原理原則17「要件定義は説明責任を伴う」は、発注者が受注者に要件を正しく説明し、受注者が理解した内容を発注者に確認する、という行動規範を示しています。
原理原則2「取り決めは合意と承認によって成り立つ」は、合意プロセスと承認ルールを明確にして行動することを挙げています。発注前に、誰が確認し、誰が決めるかを決めておくと、あとの合意がしやすくなります。
見積もりの受け方（多段階見積もり）
同じ標準プロセスの資料は、見積もりを「仮試算」「試算」「概算」「確定」の段階に分けて示す多段階見積り方式を紹介しています。情報が増えるほど、誤差のリスクは下がるという考え方です。
同じ資料は「不確定要素が多い中での見積りを、プロジェクトの目標値として設定すべきではない」と注意しています。発注前の早い段階の見積もりは幅のある数字として受け取り、要件が固まった段階で見積もりを取り直す前提で進めます。多段階見積もりの詳しい段階は、別記事「概算見積もりとは？」にまとめています。
原理原則5「多段階の見積もりは双方のリスクを低減する」も、事業リスクを減らすために多段階見積もりを使うこと、見積もりのリスクを避けるために多段階契約を使うことを挙げています。
契約の形（超上流と開発の違い）
標準プロセスの資料は、超上流（企画・要件定義）が発注者（ユーザ）の責任であるため、受注者にとって準委任契約とするのが合理的だとしています。請負契約にすると、発注者側の事情に結果が大きく影響されるためです。
| 段階 | 契約の形の考え方 |
|---|---|
| 超上流（企画・要件定義） | 準委任が合理的（発注者の責任が大きいため） |
| ソフトウェア開発 | 請負（成果物に対する責任が受注者側にあるため） |
原理原則6「システム化実現の費用はソフトウェア開発だけではない」は、依頼する範囲と内容を漏れなく洗い出して提示すること、見積もりに含まれる内容と根拠を明確にすること、運用・保守も見据えた計画と体制を作ることを行動規範として挙げています。
ミツモリーでの発注の進め方
ミツモリー（mitsumo.li）は、株式会社ワンオブゼムが運営する、AIでシステム開発の概算見積もりを出すサービスです。見積もりは無料で、会員登録はいりません。
- 作りたいものを一言で書く
- AIが依頼の文から必要な機能を読み取り、その場で概算の金額を出す
- 見積書を依頼すると、概算見積書（PDF）をすぐに受け取れる
- 担当者が内容を確かめ、正式見積書をお送りする
概算見積書はAIによる概算で、拘束力はありません。正式な金額は、担当者が内容を確認してお送りする正式見積書でお知らせします。正式見積書の受付は平日10:00〜18:00（締切17:30）で、17:30を過ぎたご依頼と休業日のご依頼は、翌営業日にお送りします。発注の判断や契約には、この正式見積書を使います。
よくある質問
システム開発の発注とは何ですか？
システム開発の発注とは、作りたいシステムの要件を発注者が決め、見積もりと契約を経て、開発会社に作業を依頼することです。IPAの資料では、要件定義は発注者の責任とされています。発注者が主体的に関わるほど、あとの手戻りを減らせます。
発注までにどのような流れがありますか？
企画、要件定義、発注・契約、開発、運用・保守という流れです。IPAの共通フレームの考え方では、これらをひとつながりのライフサイクルとして捉えます。発注は、企画と要件定義（超上流）を経たあとに行います。
要件定義は誰が決めるのですか？
IPAの「超上流から攻めるIT化の原理原則17ヶ条」は、原理原則9で「要件定義は発注者の責任である」としています。業務部門とIT部門が二人三脚で進め、受注者の支援をうまく活用することが行動規範として挙げられています。
見積もりは一度で確定しますか？
確定しないことが多いやり方です。IPAの資料は、見積もりを仮試算・試算・概算・確定の段階に分けて出す多段階見積り方式を紹介しています。早い段階の見積もりは、プロジェクトの目標値として固定しないほうがよいとされています。
発注の契約はどのような形になりますか？
超上流（企画・要件定義）は、発注者の責任が大きいため準委任契約が合理的とされています。そのあとのソフトウェア開発は、成果物に対する責任の所在から、請負契約とすることが合理的だとされています。
発注で決める費用は開発費だけですか？
開発費だけではありません。原理原則6は、依頼する範囲と内容を漏れなく洗い出すこと、見積もりに含まれる内容と根拠を明確にすること、運用・保守も見据えた計画と体制を作ることを挙げています。
発注前に何を準備すればよいですか？
誰が確認し、誰が決めるかを先に決めておくことです。原理原則2は、合意プロセスと承認ルールを明確にして行動することを挙げています。要件定義の内容も、発注者側で主体的に整理しておくと進めやすくなります。
要件が途中で変わったらどうなりますか？
原理原則10は、要件定義書を「バイブル」とし、以降の変更はすべて要件定義書をベースに議論するとしています。変更が増えると、発注時の見積もりや契約の前提が変わることがあります。
ミツモリーで発注の見積もりは取れますか？
取れます。ミツモリーは、作りたいものを一言で書くと、AIがその場で概算の金額を出す、無料のサービスです。会員登録はいりません。発注の判断には、担当者が内容を確認した正式見積書を使います。
参考にした資料
- IPA-SEC（情報処理推進機構 ソフトウェア・エンジニアリング・センター）「超上流から攻めるIT化の原理原則17ヶ条」
- IPA（情報処理推進機構）「ソフトウェア開発の標準プロセス」（アーカイブ、2011年、室谷隆）
- 関連記事: システム開発の見積もりとは？見積書の内訳と金額がぶれる理由
- 関連記事: 概算見積もりとは？正式見積もりとの違いと使い分け