システム開発の進め方｜発注側が知っておくべき工程・役割・注意点

公開日：2025年1月27日　更新日：2026年7月14日

システム開発を検討し始めると、多くの担当者が最初につまずくのは「技術」ではなく「進め方」です。企画から要件定義、ベンダ選定、設計・開発、テスト、運用まで、開発工程を知るだけではプロジェクトはうまく進みません。各段階で発注側が何を決め、何を承認し、どこまでをベンダに任せるかを理解しておくことが、失敗を避ける鍵になります。

本記事で分かることは、次の3点です。

• システム開発の全体像（企画から運用まで7段階）
• 各段階で発注側が担う役割
• 発注側が陥りやすいよくある失敗

システム開発は、大きく分けて次の7段階で進みます。まず全体像を押さえてから、各段階の詳細を見ていきましょう。

段階	主な内容	発注側が決めること
1. 企画	目的・課題の整理	なぜシステムが必要か
2. 予算・体制	投資上限と推進体制	誰が責任者か
3. 要件整理	業務・データ・機能整理	何をシステム化するか
4. ベンダ選定	RFP・見積・提案比較	どの会社に任せるか
5. 設計・開発	仕様確定・実装	何を承認するか
6. テスト・移行	受入テスト・データ移行	稼働可能か
7. 運用・改善	保守・改善	成果が出ているか

システム開発の全体的な流れ

一般的なシステム開発は、企画からリリース後の運用改善まで、次のような工程で進みます。それぞれの工程で「何を決めるか」「何が完成の目安（成果物）か」を先に知っておくと、進捗の善し悪しが判断しやすくなります。

企画・目的設定

「なぜシステムが必要か」を言語化する段階です。目的が曖昧なまま次工程に進むと、後々の予算・仕様がぶれる原因になります。

予算・体制づくり

投資上限を決め、社内の意思決定ルートと責任者を確保します。

要件定義

業務要件・機能要件・非機能要件を整理し、システムに何を実装するかを固めます。

ベンダ選定・契約

RFPをもとに複数社から提案・見積もりを受け、契約形態（請負・準委任）を決めます。

基本設計・詳細設計

画面・帳票・データ構成などを設計します。発注側は内容の妥当性を確認・承認する役割を担います。

開発・単体テスト

実装が進む段階です。発注側が直接関与することは少ないですが、進捗確認は欠かせません。

結合テスト・総合テスト

機能間の連携、実運用に近いシナリオでの動作を検証します。

データ移行・リリース

既存データの移行とリリース準備を行います。移行は後回しにされがちですが、早期の計画が重要です。

運用保守・改善

稼働後は、保守体制の維持と、利用状況に応じた改善を続けます。

期間の目安は、開発規模によって大きく異なります。

開発規模	想定期間
小規模な業務ツール	2～4か月
部門システム	6～12か月
基幹システム刷新	1～3年以上

各工程の主な成果物

工程	主な成果物
企画	プロジェクト計画書、課題一覧
要件定義	業務要件・機能要件・非機能要件
基本設計	画面一覧、帳票一覧、データ構成
開発	プログラム、単体テスト結果
総合テスト	テスト計画、結果、障害一覧
移行	移行計画、リハーサル結果
運用	運用手順書、保守体制

システム開発を始める前に決めること

システムづくりの動機は、「今のたいへんさから逃れたい」から「こんなことができたらいいな！」まで様々ですが、共通するのは目的が曖昧なまま進んでしまいやすいことです。まず「システムで何を満たしたいか」を決めることから始めます。

システムで解決する経営・業務課題

「スピード化」「大量処理」なのか、「人手の省力化」なのか、あるいは「複数スタッフ間のサービスレベルの均質化」なのか、「リアルタイムな情報把握」なのか。何を期待するのかをはっきりさせます。

誰のためのシステムか

「顧客サービスのレベルアップのため」なのか、「スタッフが効率良く作業するため」か、「経営の武器にするため」なのか。誰にとっての利便性を優先させるのかをはっきりさせます。

最低限達成すべき目標

理想目標の明確化と併せて、最低限クリアしなければならない目標も設定しておきます。目標が定まらないと、次工程の予算も決まりません。

本当に新規開発が必要か

「システムを開発する」と決めつける前に、次の順で検討する価値があります。

• 既存のSaaSで対応できないか
• パッケージを設定・拡張できないか
• ローコード・ノーコードで作れないか
• それでも難しい部分だけをスクラッチ開発するか

パッケージと自社開発のどちらが自社に合うかの判断軸は、「パッケージか？自社開発か」で詳しく整理しています。要件が固まっていない段階からご相談いただくシステム構想策定支援もあわせてご案内しています。

予算と投資範囲を決める

初期開発費だけで判断しない

「どれだけの費用であれば見合うか」を、自社の財務状態から割り出します。予算をシステム会社に伝えたうえで、内容を両者で詰めていくのが基本です。

運用・保守・移行費も含める

全体予算を決める際、「設計・開発」以外の予算構成、つまり運用保守やデータ移行にどれだけシステム会社の支援を求めるかを見落としがちです。あらかじめ考えをまとめておきましょう。

予算を伝えるべき理由

開発費の内訳や、見積もりの「高い・安い」をどう判断するかについては、「システム開発の費用相場とは？見積もりが高い・安いを判断する実務ポイント」で詳しく解説しています。予算配分の考え方は「IT投資計画の立て方｜限られた予算をどのシステムに配分すべきか」もあわせてご覧ください。

発注側の推進体制を整える

プロジェクト責任者

業務に精通し、社内的な権限のあるマネジメント職が窓口を担うのが理想です。多忙な場合は、別の担当者を置くこともあります。

現場キーマン

関係部門のキーマンに、①ベンダ選定プロセスへの参加、②打ち合わせへの出席、③現場の取りまとめ、④受入テストへの参加、など協力を依頼します。

意思決定ルート

決裁権限のある人がその場で意思決定できるのが理想です。そうでなければ代理決裁権や社内の決裁ルートを確保し、原則として数営業日、遅くとも1～2週間以内に意思決定できる体制を整えます。

ベンダとの役割分担

発注側が最も不安に感じるのは、「どこまで自社でやるのか」「どこからベンダがやるのか」です。次の表を目安にしてください。

項目	発注側	ベンダ側
経営課題の定義	主体	支援
業務要件の整理	主体	ヒアリング・構造化
システム要件	承認	主体
設計	確認・承認	主体
開発	原則関与しない	主体
受入テスト	主体	支援・修正
運用設計	共同	共同

システム化する範囲を決める

システムの費用対効果を高めるためには、「開発内容」をできる限り小さくすることがポイントです。開発期間の短縮だけでなく、変化に強いシステムになるという利点もあります。

業務をそのままシステム化しない

業務には、システム化しやすい「定型業務」と、人間の判断が多く必要な「非定型業務」があります。非定型業務は、人手の作業支援の部分だけをシステム化するか、使用頻度の低いものは思い切ってシステム化をあきらめるという割り切りが必要です。

人が判断する業務を残す

課題を「システムで改善できる部分」と「業務手順の変更で改善できる部分」に分けて考えることも大切です。システムと業務を一体化しすぎると、システムを変えないと業務を変えられなくなり、ビジネス変化への柔軟性が損なわれます。人力作業の部分を極力残し、ボトルネックの大きい部分だけをシステムに任せる考え方のほうが、開発コストを抑え、投資対効果も高くなります。

データと業務フローを整理する

自社のデータとして必要な項目を洗い出します。例えば顧客データであれば、氏名、住所、電話番号、メールアドレスなどですが、さらに必要な情報を取捨選択します。この作業をデータの塊単位に行い、誰が入力し、誰が保有しているかを明確にします。そのうえで、どのタイミングで、誰に提供・共有するかを明確にしていきます。データの属性や流れが分かることで、ベンダがデータベース構造を定義できるようになります。

並行して、実際に使う人は誰で、使用頻度はどれくらいか、システムに慣れているかどうかも明確にしておきます。これはこのあとの設計に深く影響します。

ベンダを選び、契約する

RFPが必要なケース

複数社から提案を受ける場合や、数千万円以上の投資になる場合は、口頭説明だけでなくRFP（提案依頼書）として条件を整理することが望ましいです。RFPがあることで、各社の提案・見積もりを同じ条件で比較できます。

RFPに記載すべき項目や作成手順については、RFP作成・ベンダ選定支援のページや関連コラムでも解説しています。作成の型を確認したい場合は、RFPテンプレート資料もあわせてご利用ください。

自社に合うベンダのタイプを見極める

ベンダにも様々なタイプがあります。金額だけで分類すると誤解を招くため、「自社で決められる範囲」と「外部に任せたい範囲」で考えるのが実務的です。

• SaaS・パッケージ導入会社
• ノーコード・ローコード開発会社
• クラウドインテグレーター
• SIer／IT総合会社
• オフショア開発会社
• アジャイル開発会社
• ITコンサルティング会社
• 内製化支援会社

目的、予算、自社の体制についてベンダに伝え、担当者からのヒアリングにはできる限り丁寧に情報提供してください。信頼できる相手かどうかは、「システム完成後の運用にまで話が及ぶかどうか」「担当者との相性はよいか」が判断材料になります。

見積もり比較で確認する項目

複数社の提案・見積もりを比較する際は、金額だけでなく次の項目も確認してください。

確認項目	見るポイント
対象工程	要件定義、設計、開発、移行のどこまで含むか
成果物	設計書、テスト結果、操作手順書など
前提条件	発注側で用意する資料・人員・環境
追加費用	仕様変更やデータ移行への対応
運用保守	稼働後の支援範囲と費用
体制	PM、設計者、開発者の役割
スケジュール	各工程の期間と発注側の作業

請負契約と準委任契約

契約タイプ	内容
準委任契約	役務の提供に対して、対象業務・料金・期間を定める契約。コンサルティングや要件定義など、業務主体が自社にある場合に用いる。
請負契約	成果物の提供に対して、内容・料金・納期を定める契約。開発作業など、業務主体がベンダにある場合に用いる。

そのほか、契約前には機密保持契約（NDA）を結ぶのが一般的です。運用保守サポート契約はケースバイケースでどちらのタイプにするか決めます。

価格だけで選ばない

ベンダ選定そのものの進め方は、「システム開発会社・ベンダ選定で失敗しない7つのポイント」および「7割の落とし穴を避けるベンダ選定術とコントロール術」でより詳しく解説しています。

設計・開発中に発注側がやること

要件と設計内容を承認する

ベンダが準備した検討資料をもとに、発注側は内容をチェックしながら、取捨選択や修正要望を伝えます。前工程でどれだけ細かく詰めていても、この段階で要件がブレたり内容が膨らむことは多々あります。予算やスケジュールはそれを見越して、事前に合意しておくことも大切です。

課題・変更を管理する

製造工程の管理は請負側の責任で行うのが通常ですが、任せきりにはせず、発注側も何らかの形で監督業務に関与します。希望を的確に反映するため、そして間違いを防ぐためです。

定例会で確認すべきこと

定例ミーティングや定例報告会で、状況連絡と問題点の提起・検討を行います。頻度は日単位・週単位・隔週などケースバイケースですが、ベンダと調整して決めます。

テスト・移行・利用者教育

発注側が受入テストを行う

実運用を想定したテストです。システムが仕様どおりに出来上がっているかのチェックに加え、運営を問題なく回していくための予行演習も兼ねます。実際の業務データ（または実際に即したデータ）を入力し、可能な限り業務の全ケースを試して不具合を炙り出します。

データ移行を早期に計画する

データ移行は後回しにされがちですが、既存システムとの連携が複雑な場合、想定以上に時間がかかります。移行計画とリハーサルは早い段階から着手しておくことをお勧めします。

利用者教育と業務切替

総合テストが進み、システムが落ち着いてきた段階で、関係者向けの説明会や利用者向けトレーニングを行います。開発窓口の担当者、あるいはそれに準ずるメンバーが説明者を担うのが一般的です。

システム開発でよくある失敗

発注側が知っておきたいのは、正しい進め方以上に「何を間違えるとつまずくのか」です。特に注意したい4つを、理由とあわせて紹介します。

要件が固まる前に見積もりを取る

要望が抽象的なほど、ベンダはリスクを見積もりに上乗せします。各社が異なる前提で見積もるため、相見積もりを取っても単純比較できません。

現場の要望を全部システム化する

個別要望を積み上げると、開発費だけでなく、テスト・教育・保守の負担も増えます。要望数ではなく、業務成果への貢献度で優先順位を決める必要があります。

受入テストをベンダ任せにする

ベンダは仕様どおりに動くことは確認できますが、実際の業務が回るかどうかを最終判断できるのは発注側だけです。

運用保守費を予算に含めない

初期開発費だけで予算を確定させると、稼働後の保守・改善に充てる費用が不足しがちです。開発と運用は別会計になりやすいため、企画段階から合わせて見積もっておく必要があります。

そのほか、次のような点にも注意が必要です。

• ベンダ選定を価格だけで決める
• 発注側の責任者が不在、または権限が曖昧
• データ移行を後回しにする
• 稼働日を先に決めてから計画を逆算する

ウォーターフォールとアジャイルの違い

ここまでの解説は、工程を順番に進めるウォーターフォール型を前提にしています。ただし、工程は必ず一方向に進むとは限りません。要件が固まりきらない場合は、小さく設計・開発・検証を繰り返すアジャイル型の進め方もあります。

	ウォーターフォール	アジャイル
向いているケース	要件がある程度固まっている	要件が固まりきらない・変化しやすい
進め方	企画から運用まで順に進める	小さな単位で設計・開発・検証を繰り返す
予算・納期の見通し	立てやすい	初期段階では立てにくい

まとめ

システム開発で重要なのは、工程を知ることではありません。各工程で、発注側が適切な判断を下せる状態をつくることです。
目的・予算・体制を先に固め、ベンダに任せる範囲と自社で決める範囲を明確にしておけば、途中でのブレは大きく減らせます。

システム開発を進めたいものの、要件・予算・発注範囲の整理に悩んでいる場合は、発注前の整理からご支援することも可能です。