システム開発とは？工程と手法と依頼時の注意点をわかりやすく解説

システム開発とは、業務の課題をITの仕組みで解決するために、企画から運用までを一連で進める取り組みです。プログラムを書く作業は、その一部にすぎません。

発注する側の中小企業にとっては、工程、手法、費用の決まり方、依頼前の準備を押さえるだけで、見積もりの読み方や依頼先との会話が変わります。

本記事では、公的機関の資料をもとに、システム開発の基本を発注者の視点で整理します。

システム開発とは何か？ソフトウェア開発との違いと全体像

システム開発とは、業務上の課題を、コンピュータなどの仕組みを組み立てて解決する一連の活動です。

システムという言葉が指す範囲は、プログラム（ソフトウェア）だけではありません。

機器、データ、それを使う人の手順や運用ルールまで含めた全体がシステムです。

業務の課題をITの仕組みで解決する一連の活動

在庫管理システムを例に考えます。この場合、在庫を計算するプログラムが必要になるのはもちろんですが、在庫データをどの単位で持つか、誰がいつ入力するか、棚卸しの手順をどう変えるかまでが検討の対象です。

プログラムだけを作っても、運用の手順が決まっていなければ現場では使われません。

このため、システム開発は「何を作るかを決める段階」から「作ったものを使い続ける段階」までを含む活動として捉える必要があります。

プログラミングはその途中の一工程であり、システム開発の成否は、前後の工程の質にも左右されます。

ソフトウェア開発やアプリ開発との違い

ソフトウェア開発は、コンピュータ上で動くプログラム自体を作り、改良していく活動を指すのが一般的です。

アプリ開発は、スマートフォンやパソコンで動く特定のアプリケーションを作る活動を指します。

これに対してシステム開発は、これらの開発を含みつつ、業務全体の仕組みを対象にする、より広い言葉として使われます。

なお、この区別は一般的な整理で、会社によって使い分けが異なります。

発注の場面では、言葉の定義よりも、依頼範囲の確認が重要です。

公的な枠組みでの捉え方（共通フレーム）

システム開発の全体像は、公的な枠組みでも整理されています。独立行政法人情報処理推進機構（IPA）が公開しているSLCP（共通フレーム）は、システムやソフトウェアを企画・開発・運用・廃棄する一連の過程として整理し、多様な関係者が対話するための共通言語として位置づけています。

この枠組みは、JIS X 0160:2021（ISO/IEC/IEEE 12207:2017、ソフトウェアライフサイクルプロセス）とJIS X 0170:2025（ISO/IEC/IEEE 15288:2023、システムライフサイクルプロセス）に対応しています。

ウォーターフォールやアジャイルといった特定の手法に依存しない点も特徴です。

つまり、手法が違っても、企画から廃棄までに必要な作業の全体像は共通しているということです。

システム開発の工程とは？要件定義から運用保守までの流れ

システム開発の工程は、一般に要件定義、設計、実装、テスト、リリース、運用保守の6つに整理できます。

資料や会社によって、設計を外部設計と内部設計に分けたり、リリースを引き渡しと呼んだりするなど、名称は異なります。ただし、順序と目的は大きく変わりません。

工程を理解しておくと、見積書に書かれた項目が何を指すのかを読み取れるようになります。

要件定義は発注側の責任が大きい工程

要件定義は、システムに何をさせたいのかを決める工程です。

結論として、この工程は開発会社に任せきりにせず、発注側が主体となって進める必要があります。

その理由は、業務の実態を最もよく知っているのが発注側だからです。経済産業省の「情報システム・モデル取引・契約書」〈第一版〉（2007年4月）は、発注側（ユーザ）には、情報システムに求める要件（機能要件と非機能要件）を、社内の役割分担のもとで明確に定義する責任があると述べています。

機能要件は、システムに持たせる機能です。非機能要件は、処理の速さ、安全性、使いやすさなど、機能以外の条件を指します。

実際に、この文書は超上流工程の重要性を明らかにするため、要件定義を契約書の中で独立したフェーズとし、契約類型を準委任型としています。

準委任とは、成果物の完成ではなく、業務を行うこと自体を委託する契約の形です。要件定義を独立した準委任型としたのは、システム化の方向性を決める責任が発注側にあることを、契約の上でも明確にする狙いがあるためです。

したがって、要件定義では「発注側が決める、開発会社が整理を支援する」という役割分担が基本になります。

なお、この文書は2007年の第一版で、その後に改訂版が公表されています。実際の契約では、最新の版もご確認ください。

設計・実装・テストは開発会社が中心になる工程

設計は、要件定義で決めた内容を、どのように作るかに落とし込む工程です。

利用者が見る画面や操作を決める外部設計と、システム内部の構造や処理を決める内部設計に分けて進めることが多いです。

実装は、設計書に沿ってプログラムを書く工程で、テストは、想定どおりに動くか、不具合がないかを確認する工程です。

これらの工程は開発会社が中心ですが、発注側にしかできない作業もあります。

画面の設計案への意見出しや、業務の目線でテスト結果を確認する受け入れテストなどです。

確認を求められたときに、担当者がすぐ判断できる体制が、工程を滞らせない条件になります。

リリースと運用保守は使い続けるための工程

リリースは、完成したシステムを実際の業務で使える状態にする工程です。

運用保守は、リリース後に、システムを安定して動かし続け、不具合の修正や、業務の変化に合わせた改修を行う工程を指します。

運用保守は、見積もりの段階で見落とされやすい項目です。システムは作って終わりではないため、開発費だけでなく、リリース後に毎月かかる運用保守費用も含めて、総額で検討する必要があります。

関わる人と役割

システム開発には、一般にプロジェクトマネージャー（PM）、システムエンジニア（SE）、プログラマーが関わります。

PMは全体の進行管理、SEは設計や仕様の取りまとめ、プログラマーは実際のプログラム作成を担う、という分担が典型的です。

発注側にも、役割が必要です。

業務の判断ができ、開発会社との窓口になる責任者を決めておくことが、前述の要件定義を発注側が主体で進めるための前提になります。

担当者が頻繁に変わる、あるいは兼務で時間が取れない状態では、確認が滞り、工程全体に影響が及びます。

システム開発の手法の種類と選び方

システム開発の手法には、代表的なものとして、ウォーターフォール、アジャイル、スパイラル、プロトタイピングがあります。

結論として、どの手法が優れているかではなく、自社の案件の性質に合う手法を選ぶことが重要です。

代表的な手法の特徴

ウォーターフォールは、要件定義から運用保守までの工程を、上から下へ順番に進める手法です。

計画を先に固めるため、スケジュールや費用を見通しやすい一方で、工程の途中での仕様変更には対応しにくい面があります。

アジャイルは、短い期間で開発とリリースを繰り返し、利用者の反応を見ながら改善を重ねる手法です。

変更に強い反面、全体の完成像や総額が最初に確定しにくいという特徴があります。

スパイラルは、小さな単位で設計から評価までを繰り返しながら、システムを段階的に大きくしていく手法です。

プロトタイピングは、本格的な開発の前に試作品を作り、利用者に確認してもらいながら要件を固める手法です。

このほか、設計とテストを対応させて確認するV字モデルという考え方もあります。

案件の性質から手法を選ぶ

手法の選び方は、要件の固まり具合と、変更の見込みで整理すると判断しやすくなります。

次の表は、本記事での整理です。

案件の状況	向きやすい手法	理由
要件が明確で、途中の変更が少ない	ウォーターフォール	先に計画を固めた方が、費用と期間を管理しやすい
要件が流動的で、利用者の反応を見たい	アジャイル	小さく作って確かめ、改善を重ねられる
完成のイメージを共有しにくい	プロトタイピング	試作品で認識のずれを早く減らせる
大きなシステムを段階的に広げたい	スパイラル	範囲を絞って評価しながら拡張できる

手法が違っても要件定義は欠かせない

ここで注意したい点があります。アジャイルなら要件定義が不要になるわけではありません。

共通フレームは、手法に依存しない枠組みとして、企画から廃棄までの作業を整理しています。

手法は進め方の違いであり、何を実現するのかを決める作業そのものは、どの手法でも必要です。

アジャイルでは、要件を最初に全部決めるのではなく、優先度の高いものから順に決めて進めます。

このため、発注側が継続的に判断する負担は、むしろ大きくなる場合があります。自社が関われる時間も、手法を選ぶ際の重要な条件です。

システム開発の費用はどう決まる？人月と契約形態の考え方

システム開発の費用は、結論として、作業に必要な人の量と、契約の形で決まります。

金額の相場を暗記するよりも、見積もりの構造を理解した方が、依頼先との比較に役立ちます。

費用は人月の考え方が基本になる

システム開発の費用は、一般に、人月と呼ばれる単位で見積もられます。

1人のエンジニアが1か月働く作業量が1人月で、必要な人月に単価を掛けた金額に、諸経費などが加わるのが基本の考え方です。

システム開発は、機械を使った大量生産ではなく、人の作業が中心になるためです。

目安となる数値を、公的な統計から確認してみます。

経済産業省の平成30年特定サービス産業実態調査（概況）によると、ソフトウェア業は21,953事業所、従業者70万7,642人（2018年7月1日時点）で、年間売上高は14兆8,401億円（2017年実績）でした。

年間売上高を従業者数で割ると、1人あたり約2,097万円、月に直すと約175万円になります（本記事での概算）。

この数値は、営業や管理部門の従業者も含めた業界全体の平均で、エンジニアの人月単価そのものではありません。

また、2018年の調査であり、現在の価格とは異なる可能性があります。

ただし、1人の従業者が1か月に生み出す売上が百数十万円の規模であることを知っておくと、極端に安い、あるいは高い見積もりに気づく手がかりになります。

準委任と請負で責任の範囲が変わる

費用と並んで確認したいのが、契約の形です。

請負は、完成した成果物に対して報酬を支払う契約で、完成の責任を開発会社が負います。

準委任は、前述のとおり、業務を行うこと自体に対して報酬を支払う契約です。

経済産業省のモデル契約書は、要件定義を準委任型とした理由を、成果物の特定について、当事者同士の共通理解が事前に十分に成立しているかによると説明しています。

さらに、準委任型としなかった場合には、ユーザ自身の要件定義やステークホルダとの調整の責任が曖昧になる傾向があり、要件定義の見落としも生じやすくなるという指摘が多いとしています。

契約の形は、費用だけでなく、責任の所在にも直結するのです。

多段階契約で見積もりのリスクを分ける

もう一つ、同じモデル契約書が採用している考え方が、多段階契約と再見積りです。

多段階契約とは、工程ごとに個別の契約を結ぶ方法です。再見積りは、曖昧さが残る段階の見積もりを、要件が明確になった段階で出し直すことを指します。

この仕組みが採られている理由は、見積もりの時期とリスクの関係にあります。

要件が固まらないうちに全体の金額を確定させると、発注側も開発会社も大きなリスクを抱えます。

工程ごとに契約を区切り、要件が明確になってから次の見積もりをする方法は、双方のリスクを確認する機会を確保できるのです。

発注側にとっては、最初の見積もりが「確定額」なのか「暫定額」なのかを確認する視点が持てるようになります。

見積書で確認したい項目

見積書を受け取ったら、次の点を確認してください。

– どの工程までが含まれているか（要件定義と、リリース後の運用保守を含むか）
– 人月の数と単価が示されているか
– 見積もりの前提条件は何か（機能の範囲、データ移行の有無など）
– 仕様変更が発生したときの費用の扱いはどうなるか

なお、本記事では、具体的な金額の相場は掲載していません。

費用は規模、要件、手法、依頼先で大きく変わり、一次情報で確認できる統一的な相場の数値がないためです。

システム開発を依頼する前に決めること

システム開発を依頼する前に、自社の現状を整理することが、結論として最も効果的な準備になります。

何から手をつけるかは、自社のデジタル化の段階によって変わります。

自社のデジタル化の段階を確認する

中小企業庁の2025年版中小企業白書は、デジタル化の取組を4つの段階に分けています。

段階1は、紙や口頭による業務が中心で、デジタル化が図られていない状態です。

段階2は、電子メールの利用や会計業務の電子処理など、デジタルツールを使った業務環境に移行している状態です。

段階3は、売上や顧客、在庫の情報をシステムで管理しながら、業務フローの見直しを行っている状態です。

段階4は、蓄積したデータを活用して販路拡大や新商品開発を実践するなど、ビジネスモデルの変革に取り組んでいる状態です。

白書によると、2024年は2023年の調査に比べて、段階1と答える事業者の割合が大きく減少しました。

一方で、デジタル化に取り組めていない事業者も一定数存在すると指摘しています。

比較の基準になった2023年調査は、帝国データバンクが全国29,491社の中小企業を対象に実施したもので、有効回答は6,255社（回収率21.2%）でした。

調査間で母集団が異なるため、割合を単純に比較できない点にも注意が必要です。

自社の段階が分かれば、必要なシステムの規模も見えてきます。

たとえば、段階1や段階2であれば、いきなり大規模な基幹システムを作るのではなく、まず業務の流れを整理し、小さな範囲から始める方が現実的です。

費用と人材の不足を前提に計画する

白書は、DXに向けた取組を進める際の問題点として、どの段階の事業者でも「費用の負担が大きい」と「DXを推進する人材が足りない」の回答割合が高いことを挙げています。

中小企業がシステム開発を考えるときに、費用と人材の制約は避けて通れません。

この制約を前提にすると、範囲を絞って小さく始め、効果を確認しながら広げる進め方が適していると考えられます。

前述の多段階契約や、アジャイルのような段階的な手法は、この考え方と相性がよいといえます。

必要最小限から始めた事例

白書は、必要最小限の取組から進めた事例として、熊本県嘉島町の株式会社倉岡紙工（従業員30名、紙製品の製造業）を紹介しています。

同社は、約3,000個の木型にRFIDタグを付けてIoTで管理する取組から始めました。その結果、木型を探す時間がゼロになったとされています。

さらに、人手の掛かる作業を機械化し、「カス取り作業」は時間が3分の1に、梱包作業は3人で行っていた作業が1人で可能になりました。

この事例は、多額の投資で一度に全てを解決するのではなく、社内のボトルネックを特定し、できるところから始めた点が特徴です。

システム開発でも、最初に解決する課題を1つに絞る考え方は参考になります。

依頼前に整理しておきたい項目

開発会社に相談する前に、次の項目を社内で整理しておくと、見積もりの精度が上がります。

– 解決したい課題と、現在の業務の流れ
– システム化したい範囲と、今回は対象外にする範囲
– 開発会社との窓口になる担当者と、判断できる責任者
– 予算の上限と、リリースしたい時期の希望
– 既存のデータや、連携が必要な既存のシステムの有無

内製にするか外注にするかも、この段階で検討します。

社内に開発を進められる人材がいない場合は外注が現実的ですが、その場合でも、要件を決める役割は社内に残ります。

システム開発に関するよくある質問

システム開発とWeb制作は何が違いますか？

Web制作は、Webサイトの見た目や情報の掲載を中心に作る活動です。システム開発は、会員管理や受発注管理のように、データの処理や業務の流れを実現する仕組みを作る活動を指すのが一般的です。ただし、境界は明確ではないため、依頼する際は、必要な機能を具体的に伝えることが重要です。

見積もりが依頼先によって大きく違うのはなぜですか？

主な理由は、見積もりに含まれる工程の範囲、人月の数、単価、前提条件が、会社ごとに異なるためです。たとえば、要件定義や運用保守が含まれているかどうかで、総額は大きく変わります。金額だけを比べるのではなく、前述の確認項目で、前提をそろえて比較してください。

内製と外注はどちらがよいですか？

社内に開発と運用ができる人材がいるかどうかが、判断の目安です。白書が示すように、中小企業ではDXを推進する人材の不足が課題になりやすく、外注を選ぶ場合が多くなります。外注する場合でも、要件を決める役割と、運用を引き受ける役割は、社内に必要です。

契約は請負と準委任のどちらがよいですか？

工程によって異なります。要件定義は、モデル契約書で準委任型とされています。成果物が明確になった後の開発工程では、請負が選ばれることもあります。契約の形は、責任の範囲に影響するため、依頼先と内容をよく確認することが大切です。

システム開発とは何かを理解して、自社に合った依頼につなげるために

システム開発とは、業務の課題をITの仕組みで解決するために、企画から運用までを一連で進める活動です。工程は要件定義から運用保守までの流れで整理でき、手法は案件の性質に合わせて選びます。

費用は人月と契約の形で決まり、依頼前には、自社のデジタル化の段階と、決めておくべき項目の整理が欠かせません。

特に、要件定義は発注側の責任が大きい工程です。多段階契約や再見積りの考え方を知っておけば、見積もりの金額を冷静に判断できます。

AI開発やシステム開発を相談したいけれど、何から整理すればよいか分からないという場合は、Dimebizに気軽にお問い合わせください。要件の整理の段階からご相談いただけます。