システム開発を発注する側に立つと、最初の壁は「全体の流れが見えない」ことです。要件定義、外部設計、内部設計、テスト、リリース。言葉だけは耳にするものの、それぞれの工程で何が行われ、どこに自分が関わり、どのフェーズで何を判断すればいいのか。発注経験のない担当者にとっては、霧の中を歩くような感覚があります。この記事では、システム開発の工程と流れを、発注側・経営側の目線で整理します。ウォーターフォール型とアジャイル型の違い、それぞれの工程で起きていること、失敗しやすい局面、開発会社の選び方まで、実務で必要な順序で網羅します。読み終えたとき、発注の意思決定に必要な土台が頭の中に組み上がる構成にしました。
システム開発とは何を指すのか
システム開発とは、業務上の課題や事業上の機会に応えるために、ソフトウェアと運用のしくみを設計して構築する一連の活動を指します。Webサービスの構築、業務システムの開発、基幹システムの刷新、社内向けの業務アプリの内製、いずれもシステム開発の領域に含まれます。
混同されがちな言葉として「アプリ開発」や「ソフトウェア開発」もありますが、これらは対象範囲の違いです。アプリ開発はスマートフォン向けの単体アプリを指すことが多く、ソフトウェア開発はより広い概念です。システム開発は、これらを含みつつ「業務や事業のしくみとして動かす」前提が入る点が特徴です。単なるプログラムの作成ではなく、業務フローと一体で設計する活動だと理解してください。
システム開発の代表的な進め方：2つのアプローチ
システム開発の進め方には、大きく2つのアプローチがあります。ウォーターフォール型とアジャイル型です。それぞれ得意な領域が違うため、プロジェクトの性質によって使い分けます。
| 項目 | ウォーターフォール型 | アジャイル型 |
|---|---|---|
| 進め方 | 工程を順番に直列で進める | 短い反復で機能を積み上げる |
| 仕様の扱い | 最初に確定させる | 走りながら学んで調整する |
| 向いている案件 | 要件が明確で変更が少ない | 不確実性が高く検証を重ねたい |
| 代表例 | 基幹システム、業務システムの刷新 | 新規Webサービス、PoC |
| ドキュメント | 重視（設計書を厚く作る） | 必要最小限 |
| 工程の戻り | 後戻りのコストが高い | 反復を前提に設計 |
実務では、両者をきれいに分けるのではなく、ハイブリッドで進めるケースも増えています。基幹部分はウォーターフォールで堅く作り、UI周辺はアジャイル的に走らせる、といった使い分けです。プロジェクトの不確実性を見極めて、適切な進め方を選ぶ判断が、発注側にも問われます。
ウォーターフォール型の工程：9段階で見る全体像
ウォーターフォール型は、上流から下流へ順に工程を進めていく方法です。代表的な工程を、発注側が知っておくべき視点とあわせて整理します。
1. 要件定義
プロジェクトの最初に行う、最も重要な工程です。業務上の課題を整理し、システムに何をさせるか、何をさせないかを文書化して合意します。発注側の関与が最も問われる局面で、ここの精度がプロジェクト全体の成否を決めます。
要件定義が甘いと、後の工程で「言った・言わない」が頻発し、追加開発のコストが膨らみます。当社の支援現場でも、要件定義に十分な時間を取れたプロジェクトとそうでないプロジェクトでは、最終的な品質と納期の振れ幅がまるで違います。「ベンダー任せで進めてはいけない工程」の筆頭がこの要件定義です。
2. 基本設計（外部設計）
要件定義の内容を、画面・帳票・データの観点から具体化する工程です。画面のレイアウト、入出力項目、帳票の様式、外部システムとの連携方法を決めます。利用者の視点で「どう使えるか」を定義する設計です。
発注側は、ここで画面のモックアップやワイヤーフレームを確認し、業務フローと合っているかを点検します。デザインの好みではなく、業務が回るかという観点でレビューしてください。
3. 詳細設計（内部設計）
基本設計をもとに、システムの内部構造を設計する工程です。プログラムの構成、データベースのテーブル設計、処理ロジックの詳細を決めます。ここは技術的な設計が中心で、発注側が直接関わる場面は減ります。
ただし、データベースのテーブル構造は、将来のデータ活用に影響します。たとえばCRMや業務システムと連携する予定があるなら、その視点を詳細設計に反映してもらうよう依頼するのが安全です。
4. 製造（プログラミング）
設計書に沿ってプログラムを実装する工程です。エンジニアが手を動かす中心的なフェーズで、発注側は進捗確認が主な関わりになります。
製造工程の長さは、プロジェクト全体の規模と比例しますが、ここを短縮するために設計をおろそかにすると、結局テスト工程で問題が噴出します。製造を急がせる前に、設計が固まっていることを確認するのが鉄則です。
5. 単体テスト
実装したプログラムが、設計通りに動くかを部品単位で検証する工程です。エンジニア自身が行うことが多く、発注側が直接関わることは少ない工程です。
ただし、単体テストの実施状況とテスト密度（カバレッジ）を確認することで、品質管理が機能しているかの目安になります。発注側として「テストカバレッジを共有してほしい」と依頼するのは正当な要求です。
6. 結合テスト
複数のプログラムを組み合わせて、想定通りに連携するかを検証する工程です。データの受け渡し、画面遷移、外部システムとの連携が正しく動くかを確認します。
ここで設計の見落としが顕在化することがあります。たとえば、別々のチームが作った機能を組み合わせたら処理が重複していた、といったケースです。結合テストでの不具合は、設計工程の品質を映す鏡でもあります。
7. システムテスト（総合テスト）
実際の業務シナリオに沿って、システム全体が想定通りに動くかを検証する工程です。性能、セキュリティ、運用面まで含めて確認します。
発注側にとっては、業務シナリオを提供し、想定通りに動くかを確認する役割が中心になります。「自社の実際の業務でこの操作をしたとき、どう動くか」をシナリオで示せると、テストの精度が上がります。
8. 運用テスト（受け入れテスト）
利用者である発注側が、本番運用に近い環境で実際に操作し、業務で使えるかを確認する工程です。ここで合意したものがリリースに進みます。
受け入れテストは「動くか」だけでなく「業務が回るか」を見る場です。マニュアルが整備されているか、運用上の例外パターンに対応できるか、トラブル時の手順が想定されているかも含めて確認します。
9. リリースと本番運用
合格判定が出たら、本番環境に展開して運用を開始します。リリース直後は監視を強化し、想定外の挙動がないかを確認します。
リリースは終わりではなく、運用の始まりです。運用フェーズで発生する保守、追加機能の開発、データのメンテナンスをどう設計するかも、開発計画の段階で決めておくべき項目です。
アジャイル型の工程：反復で学ぶ進め方
アジャイル型は、ウォーターフォールのように上流から下流へ一方通行ではなく、短い反復（スプリント）を繰り返してシステムを育てていく進め方です。
スプリントという単位
アジャイルでは、1〜4週間程度のスプリントを単位に、計画・実装・テスト・レビューを一通り行います。各スプリントの終わりには動くソフトウェアが手に入り、ユーザーや関係者がフィードバックを返します。次のスプリントは、そのフィードバックを反映して進みます。
向いているプロジェクト
新規のWebサービス、要件が固まりきっていない領域、ユーザーの反応を見ながら磨き込みたい機能などに向いています。「最初から完璧な仕様を定義することが難しい」プロジェクトでは、アジャイル型の柔軟性が活きます。
逆に、規制対応や基幹システムのように「最初に決めたものを正確に作る」プロジェクトでは、アジャイルの柔軟性がノイズになることもあります。プロジェクトの性質を見て選ぶことが重要です。
発注側に求められること
アジャイル型では、発注側の関与がウォーターフォールより深くなります。スプリントレビューに参加し、優先順位の判断を継続的に行う必要があります。ベンダー任せにしておけば良い、という進め方は成立しません。
工程設計で最も重要なのは「要件定義」
ここまで9つの工程を順に見てきましたが、最初の要件定義の質が、後の8工程すべての品質を決めます。これは強調しすぎることはありません。
要件定義の段階で、業務フローが整理され、システムが解決すべき課題が明確で、関係者の合意が取れていれば、後の工程は計画通りに進みやすくなります。逆に、要件定義が曖昧なままだと、設計のたびに前提が揺れ、製造の段階で手戻りが発生し、テストで仕様の解釈の違いが噴出します。
当社が支援するプロジェクトでは、業務フローを整理し、最適なシステムアーキテクチャを提案するところを得意領域としています。ステークホルダーが複数組織にまたがる場合、ほぼ必ずデータ連携が発生するため、要件定義の段階でその設計を含めて議論することが、後の運用品質を左右します。要件定義に時間とコストをかけることをためらわないでください。後の工程で支払うコストに比べれば、はるかに安い投資です。
業務改善の進め方とも密接に関わる工程で、業務改善で整理した業務フローを、そのまま要件定義のインプットに使えるのが理想です。
開発工程でつまずく代表的なパターン
工程ごとに、つまずきやすい局面があります。事前に知っておくことで、回避できる失敗が多数あります。
ひとつめは、要件定義が「ベンダー任せ」になるパターンです。業務の細部は発注側にしか分かりません。それを丸投げすると、ベンダーは類似プロジェクトの経験から推測で要件を埋めることになり、最終的に「思っていたのと違う」が頻発します。
ふたつめは、設計レビューを形だけで通すパターンです。設計書が分厚くて読む気がしない、専門用語が多くて分からない、という理由でハンコだけ押してしまうと、後の工程で発覚した問題のコストを発注側が負うことになります。理解できない設計書には承認しない、という姿勢が必要です。
みっつめは、テスト工程を軽視するパターンです。「動いているから大丈夫」で受け入れテストを早々に切り上げ、本番運用に入った後で重大な不具合が発覚するケースは少なくありません。テストは保険ではなく、品質を保証する最後の砦です。
よっつめは、リリース後の運用設計が抜けているパターンです。誰が監視するのか、不具合発生時に誰がどう対応するのか、追加開発をどう進めるのか。これらが決まっていないと、リリース直後から運用が混乱します。
開発を発注する会社の選び方
開発工程を理解した上で、次に問われるのが「どこに発注するか」です。判断軸を整理します。
過去の実績と得意領域
業種・規模・技術領域の実績を確認します。自社と近い案件の経験があるベンダーは、要件定義の段階から的確な提案ができます。逆に、まったく未経験の業種では、業務理解の段階でロスが生じます。
当社の場合、マーケティング・セールス領域とDX領域にまたがる支援が可能な点が特徴です。入口がWebサイトやMA、SFAであっても、後続の販売管理や在庫管理のDXまで網羅的に対応できる体制を持っています。逆に入口が業務システムの構築であっても、前工程のマーケティング、セールスまでクロスセルできる設計です。プロジェクトの全体像を見渡せる体制かどうかも、選定の重要な軸になります。
技術的な対応範囲
プラットフォームを使った構築と、アプリ開発のようなスクラッチ開発の両方に対応できるか、という視点も重要です。HubSpot、monday.com、kintone、Salesforce、Zoho、Shopifyなど、多様なプラットフォームの取り扱い経験があり、要件によってプラットフォーム選定まで対応できる体制が望ましいです。当社では、これらのプラットフォーム経験に加えて、スクラッチ開発の体制も持っているため、要件に応じて最適なアプローチを選べます。
体制と継続性
開発体制の規模、エンジニアの経験、運用フェーズの保守体制を確認します。リリース後に保守の窓口がなくなる、担当者が変わってナレッジが引き継がれない、といった事態は珍しくありません。長期的に付き合えるかどうかを、選定の段階で見極めてください。
名古屋や地方拠点での選定ポイント
地域で開発会社を選ぶ場合、地元での実績や対面でのコミュニケーション頻度を重視する企業も多いです。名古屋や地方都市でシステム開発を検討する場合、地元の業界事情に詳しいベンダーが有利になるケースもあります。一方で、リモートでの開発体制が普及した現在、所在地よりも実績と体制で選ぶ判断軸も強まっています。両方を比較して、自社のプロジェクトに合うパートナーを選ぶことをおすすめします。
AIを活用したシステム開発のいま
近年、生成AIをシステム開発に組み込む案件が急速に増えています。コードの自動生成、設計書のドラフト作成、テストケースの生成といった開発支援の領域から、システムの一機能として生成AIを組み込むケースまで幅が広がっています。
発注側として留意すべきは、AI活用は手段であって目的ではない、という当たり前の点です。「AIで開発を効率化したい」という相談はよく受けますが、何を効率化したいのか、それで業務がどう改善するのかを先に定義しないと、流行を追っているだけになります。当社でも生成AIを活用した開発・コンサルティングを提供していますが、まず業務課題を明確にし、その解決にAIが適しているかを判断する順序を大切にしています。
システム開発と業務改善・DXの関係
システム開発は、業務改善やDXの推進手段のひとつです。業務改善で整理した業務フローを、システムとして実装することで、属人化が解消され、データが蓄積され、次の判断材料が得られます。
業務改善の進め方の段階で、将来のシステム化を見据えてプロセスを設計すると、要件定義がスムーズに進みます。逆に、システム化を意識せずに業務改善だけ進めると、後でシステムに乗せようとしたときに、磨き込んだ運用がシステムの標準機能と合わず、作り直しになることがあります。
業務効率化の打ち手としてシステム導入を検討する場合も、ツール選定の前に業務フローの整理と要件定義を済ませることが、ROIの分かれ目になります。
よくある質問
システム開発の工程と「行程」「流れ」「プロセス」は同じ意味ですか？
ほぼ同じ意味で使われます。「工程」は製造業由来の用語、「流れ」は一般的な表現、「プロセス」は業務全般で使われる広い言葉、「行程」は道のりや旅程を含む文脈で使われることもあります。システム開発の文脈ではいずれも同じ意味で用いられているため、文書内で表記を統一する程度の意識で問題ありません。
ウォーターフォール型とアジャイル型はどちらを選ぶべきですか？
プロジェクトの不確実性で判断してください。要件が明確で変更が少ない案件はウォーターフォール、要件が固まりきっていない案件や検証を重ねたい案件はアジャイルが向きます。両者をハイブリッドで使う進め方も増えています。発注時に「うちはウォーターフォールしかやらない」「アジャイル一択」と決めつけるベンダーより、プロジェクトに合わせて柔軟に組めるベンダーのほうが、実用的な選択肢になります。
要件定義はどのくらい時間をかけるべきですか？
プロジェクトの規模によりますが、全体工程の20〜30%を目安にする考え方が一般的です。要件定義に時間を惜しんで後の工程で手戻りが発生するコストを考えると、ここに投資する判断は理にかなっています。発注側の業務担当が時間を確保できる体制も、要件定義の質を左右します。
開発期間はどのくらいかかりますか？
機能範囲と複雑さによって幅があります。小規模な業務システムで3〜6か月、中規模なら6か月〜1年、基幹システムの刷新では1〜3年規模になることもあります。重要なのは「いつ動かしたいか」を逆算して、要件の優先順位を整理することです。すべてを一度に作ろうとせず、段階的にリリースする計画にすると、開発期間を現実的な範囲に収められます。
開発を内製するか外注するか、どう判断すればいいですか？
判断軸は、コア業務との距離、社内のエンジニア体制、長期的な保守体制の3つです。コア業務に近く、継続的に改修が発生する領域は内製化のメリットが大きい一方、社内に体制がなければ外注で立ち上げ、徐々に内製に移すアプローチも現実的です。最初から完璧な内製を目指すより、外注で立ち上げてナレッジを移管する設計のほうが、立ち上げのリスクを下げられます。
開発費用はどのように見積もられますか？
人月単価で見積もるのが一般的です。エンジニアの単価に必要な工数（人月）をかけて算出します。要件の複雑さ、使う技術、開発期間、保守の有無で大きく変動します。複数社から見積もりを取る場合、単価だけで比較せず、工数の見積もり根拠や前提条件をそろえて比較してください。安く見えても工数が少なすぎる見積もりは、後で追加費用が発生する可能性があります。
開発会社を選ぶときに、最も重視すべき軸は何ですか？
要件定義に十分な時間をかけてくれるか、という点が最も重要です。すぐに見積もりと提案書を出してくるベンダーより、まず業務を理解しようとするベンダーのほうが、結果としてプロジェクトの成功率が高くなります。技術力や価格は二次的な軸で、要件定義への向き合い方が一次的な判断材料だと考えてください。
