Webシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Webシステム開発は、要件整理、方式と開発会社の選定を経て、設計・開発に進みます。そのあと、テスト、稼働、定着と続き、全体は6段階です。各段階で決めることを押さえると、抜け漏れを抑えやすくなります。

費用相場と内訳、見積もりの取り方も、続けて取り上げます。

▼全体ガイドの記事
・Webシステム開発の完全ガイド

Webサービス開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

Webシステム開発の全体像

Webシステムは、ブラウザやスマートフォンからネットワーク経由で使う仕組みです。ログインや入力、検索、承認、決済などを行い、データを更新します。Webサイトは情報を読むことが中心ですが、Webシステムは利用者の操作に応じて、データを保存・計算・連携する点が異なります。

WebサイトとWebシステムの違い

両者は、利用者が情報を見るだけか、操作してデータを扱うかで区別できます。

• Webサイト：会社案内や商品情報、ニュースを閲覧者に届けるための仕組みです。
• Webシステム：会員登録や権限別の表示、予約と在庫の更新、請求と決済など、データを扱う処理を持ちます。
• 連携・管理：外部APIやデータベース、認証、復旧、操作履歴、管理画面も設計の対象です。

問い合わせフォームだけなら、Webサイトの機能拡張で足りる場合があります。一方で、問い合わせの自動配分や対応状況、顧客履歴の管理が必要なら、システムとして検討します。また、見積もりの依頼では、「何ページ作るか」だけでなく、誰がどのデータをどの条件で処理するかも伝えます。

SaaS・パッケージ・スクラッチの使い分け

業務をどこまで方式に合わせられるか、独自の要件がどれだけ強いかを見て、候補となる方式の特徴を比べます。

• SaaS：標準機能に業務を合わせる前提で、短期間に始めたい場合に向きます。
• パッケージ：業務テンプレートをベースに、自社固有の差分を足したい場合に合います。
• ローコード・ノーコード：対象の範囲が限られる業務に有効で、申請や台帳、簡易なワークフローが例です。
• カスタム・スクラッチ：独自業務が競争力に直結し、既存サービスでは重要な要件を満たせない場合の選択肢です。

いきなり作り始める前に、標準機能、API連携、追加開発のどれで満たせる範囲かを分けておきます。そのうえで、月額費やユーザー数、APIの制限も確かめます。

バージョンアップの扱いや、サービス終了時のデータ返却も比べます。また、クラウド上のカスタム開発も、独自要件が強い場合の選択肢です。

Webシステム開発の進め方・流れ

開発は要件整理から定着までを一続きのプロジェクトとして進めます。発注者も各段階の成果物を確認しておくと、現場で使えない、移行データが足りないといった問題を防げます。

1. 要件整理：目的・業務・データの決定

要件整理では、まず目的と業務範囲を決めます。そのうえで、必要な成果物と、データやセキュリティの扱いを定めます。

• 目的とKPI：業務をどの指標で、どこまで改善するかの目標を置きます。
• 業務と成果物：利用者と例外処理を洗い出し、業務フロー、画面・機能一覧、権限表、移行一覧、非機能要件、受け入れ条件をまとめます。
• 機能の優先順位：MUST・SHOULD・COULDの区分で、初回に作る範囲と将来に回す範囲を分けます。
• 情報と対策：個人情報や決済、機密データの有無を確かめ、認証や権限は後付けにせず最初から要件に含めます。

受発注なら、入力時間やミスをどれだけ減らすか、処理状況を何分以内に見えるようにするかをKPIに置けます。また、要望をすべて採用すると優先順位が定まらず、予算と納期を守れなくなります。

個人情報保護委員会のガイドラインでは、個人データを扱う情報システムに、正当なアクセス権を持つ従業者の識別と認証を求めています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。

洗い出しの対象は、利用者と業務フロー、例外処理を中心に、データ項目や権限、外部連携、端末、ピーク時の件数までです。また、現状と理想の業務フローも成果物に残します。

2. 選定：方式と開発会社の比較

選定では、同じ要件に照らして、方式と開発会社を比べます。

• 方式：SaaS、パッケージ、ローコード、クラウドカスタム、スクラッチについて、どこまで要件に適合するかを比べます。
• 費用・拡張性：同じ条件で、導入期間や初期・月額の負担、上限、APIやカスタマイズ、将来拡張、保守窓口を評価します。
• 会社・契約：業務実績や要件定義の力量、診断範囲、稼働後の監視・障害対応を確かめます。そのうえで、移行・連携や引き継ぎ支援を含めて、資産の扱いを取り決めます。

RFPを渡す会社は3社程度に絞り、同じ前提で提案を求めます。そのため、価格差が工数によるものか、対象範囲の違いによるものかを比べられます。

成果物と検収条件がはっきりしている工程は請負が、変更を前提とする要件探索や継続改善は準委任が合いやすいです。

契約書には、ソースコード、設計書、クラウドアカウント、データの所有権と返却方法を明記します。さらに、再委託や脆弱性が見つかった場合の対応も決めておきます。

3. 設計・開発：使える画面と安全な基盤づくり

設計・開発では、まず基盤を固めたうえで、画面と外部連携を順に決めます。また、開発方式とレビューの運用も、この段階で固めます。

• 基盤と画面：データや権限、API、エラー処理、ログを決めます。加えて、バックアップと監視、環境構成も定め、画面案を現場と確かめます。
• 外部連携：認証や制限、タイムアウト、再送、重複防止のほか、障害時の代替運用まで設計に含めます。
• 進め方：変更が多い新規サービスならMVPとアジャイル、範囲や納期が固い案件ならウォーターフォールが候補になります。

画面の文言や必須入力のほか、検索条件、一覧の並び、CSV出力項目まで具体化すると手戻りを減らせます。また、連携先が止まったときの業務手順も決めておきます。

NISTのSP 800-228改訂版は、クラウドネイティブなAPIのリスクを開発前から実行時まで整理しています。さらに、API GatewayやWebアプリケーションファイアウォールなど、段階的な保護策も示しています（出典: NIST SP 800-228 upd1、2026年3月最終更新）。

開発中は週次会議に加えて、動く画面をレビューします。また、意思決定者やレビュー日、変更時の費用と納期も、あらかじめ決めておきます。

MVP（Minimum Viable Product）は、最小限の機能をまず出して反応を確かめる進め方です。その結果を見て機能を広げるため、要件の変化が多い新規サービスに適しています。範囲と納期が固く、承認を重ねる必要がある場合は、ウォーターフォールのほうが進めやすいです。

4. テスト：受け入れ条件への適合確認

テストでは、受け入れ条件を要件整理の段階で決めておき、複数のテストと現場確認で合格を判断します。

• 受け入れ条件：「担当者の承認でステータスが変わる」「同じ注文番号は二重登録されない」などをテストケースにします。
• テスト範囲：単体、結合、総合、負荷、脆弱性診断、ユーザー受け入れを、担当を分けて行います。
• 異常系：空欄の入力や権限外のアクセス、通信断、API遅延、連続操作、過去データの検索で、動きを確かめます。
• 受け入れ判定：現場代表者が実業務と同じデータ量と手順で操作し、合格条件や不具合、暫定対応、延期の判断者を記録に残します。

個人情報を扱う場合は、ログに機密情報が残らないことや、バックアップから復元できることも検証します。

受け入れの結果は、口頭の承認だけで終えず文書に残します。なお、テスト工程が見積全体の5％以下の場合は、どのテスト範囲が含まれるかを開発会社に確かめます。

5. 稼働：移行とリリースの安全な実施

稼働では、データ移行の検証とリリース計画を立てたうえで、TLSの設定と公開範囲を確かめます。

• データ移行：旧システムや表計算から移す対象と期間、重複や欠損、変換、件数の照合、個人情報の扱い、失敗時の切り戻しを決めます。
• リリース：日時や担当者、連絡先、手順、確認項目、切り戻し条件を、計画に記しておきます。
• 通信・公開範囲：TLSの方針や証明書の更新、古い暗号方式の扱い、本番・管理画面・検証環境をどこまで公開するかを確かめます。

まずテスト環境で少量を移行し、現場で照合してからリハーサルを行います。

顧客向けのサービスでは、アクセスの少ない時間帯を選び、告知や問い合わせ窓口、決済とメールの疎通を確かめます。一方、社内業務では、旧運用の停止時期と暫定運用を現場と合意します。

TLSの設定については、IPAのガイドラインに用途別のセキュリティ水準とチェックリストがあります（出典: IPA「TLS暗号設定ガイドライン」2025年4月25日版）。

6. 定着：運用と改善の仕組みづくり

開発は、稼働したあとの定着まで含めて完了します。利用者が手順を理解して使い、改善要望をシステムに反映して、はじめて成果が出ます。

• 利用者支援：手順を周知し、マニュアルや研修、問い合わせ窓口、管理者権限、連絡網、部署ごとの担当者を用意します。
• KPI確認：ログイン率や処理時間、エラーや問い合わせの件数、手戻り率を、定期的に追います。
• 保守と引き継ぎ：更新や脆弱性の確認、監視、バックアップ、復旧訓練、費用の見直しを続け、運用資料は自社で保管します。

毎週は障害と問い合わせ、毎月は利用状況と改善候補を確かめます。四半期ごとには、費用や性能、権限、バックアップ、契約を見直します。

改善の契約では、月の稼働枠や優先順位、緊急対応の条件も決めておきます。

保守会社が変わっても運用を続けられるよう、構成図や手順書、アカウント一覧は自社でも保管します。ソースコードやデータ定義、障害履歴も残しておきます。定着を見積と契約に含めておくと、ベンダーロックインを防ぎやすくなります。

Webシステム開発の費用相場と内訳

費用は、方式や機能数、利用者数によって変わります。外部連携やデータ移行、性能、セキュリティ、運用体制も、費用を左右します。ここで示すのは予算を組むためのレンジで、要件確定後の金額を保証するものではありません。特定の金額だけで比べず、初期費用と3年程度の総保有コストを合わせて判断します。

規模別の費用と開発期間の目安

公開されている相場や案件規模ごとの費用・期間を並べると、予算の幅と見積もりの前提をつかめます。

• 方式別の公開相場：クラウド・SaaS型は無料〜100万円程度、パッケージ型は100万〜300万円、スクラッチは300万円以上です。
• 簡易案件：会員、予約、申請、業務アプリでは100万〜300万円、期間は1〜3か月程度です。
• 設定・API連携中心：初期費用は50万〜300万円、期間は数週間〜3か月程度が目安です。
• 中規模案件：権限や複数部署、顧客管理、受発注、在庫を含む場合、500万〜1,500万円、3〜8か月程度を想定します。
• 大規模案件：1,500万〜5,000万円以上、6〜18か月程度になることもあります。

上の金額は公開目安で、独自処理や複数の外部連携が増えると、費用と期間は変わります（出典: 秋霜堂株式会社「システム開発の費用相場」2026年7月更新）。中規模以上の金額は、公開相場や、複数領域のスクラッチ開発が半年〜1年以上かかるという情報、一般的な工程量から推定した目安です。公定価格や統計上の平均ではありません。

大規模ECや金融・公共系、複数拠点の基幹連携、24時間運用、厳格な監査などの条件を添えて、開発会社に確認します。利用者数やピーク時のアクセス、データ量も、あわせて伝えます。

見積書で確認する費用項目

費用は、基本的に「工数×人月単価」で考えます。リサーチノートでは、エンジニアの月額単価を80万〜120万円程度としています。

PM、要件定義担当、設計者、テスト担当、インフラ担当では単価が異なります。見積書では、人月や担当役割、期間、工程、管理費、テスト費を確かめます。

見積もりでは工程を分け、公開例の比率と照らして、費用の偏りや「一式」にまとめられた内訳を確かめます。

• 要件定義：全体の15〜20％
• 設計：全体の20〜25％
• 実装：全体の30〜40％
• テスト：全体の15〜20％
• 移行・管理：それぞれ全体の5〜10％

比率は案件によって変わるため、数値そのものより、工程が「一式」に隠れていないかを確かめます（出典: 秋霜堂株式会社「システム開発の外注費用相場」2026年更新）。

初期費用のほかに、クラウドのサーバーやDB、ストレージ、監視の費用がかかります。ドメインと証明書、メールやSMS、決済手数料も発生します。

バックアップ、脆弱性診断、保守、追加開発も予算に含めます。SaaSの場合は、ユーザー数や保存容量、API利用、サポート、最低利用期間を確かめます。

スクラッチは初期費用が高くても、利用者が増えたときの従量課金やライセンス費を抑えられる場合があります。

3年TCOと予備費を含めた予算化

予算は、総額の見方と予備の置き方に分けて考えます。

• 3年TCO：初期費に、36か月分のクラウドやライセンス、保守、追加開発、移行、教育の費用を積み上げます。
• 従量費：決済を使うなら取引手数料を、通知を使うならメールやSMSの使用料を加えます。
• 復旧費：販売停止や手作業への切り戻しが大きな損失になるなら、冗長化や監視、復旧目標にかかる費用も比べます。
• 予備枠：仕様変更やデータ品質の問題に備えて、発生条件と上限を決めておきます。

予備枠の条件には、データ欠損や外部APIの仕様変更、追加の負荷試験などを置けます。ただし、根拠のない予備費を総額に上乗せせず、発生条件と上限を記載しておきます。

見積金額が低い会社には、何が含まれていないかを尋ねます。

Webシステムの見積もりを取る際のポイント

見積もりの精度は、発注者が渡す前提条件の精度で決まります。そのため、RFPには利用者や業務フロー、データ、外部連携の条件を記載します。さらに、品質や運用、納期、予算上限も書いておきます。要件が未確定なら、開発費をすぐには確定させず、要件定義やプロトタイプの費用を先に見積もる方法もあります。

RFPに入れるべき項目の整理

見積もりの前提をそろえるため、RFPには、目的から連携の条件までを記載します。

• 背景と業務：目的や対象業務、利用者数、現行の課題、希望するKPIを書きます。
• 機能と前提：画面や権限、外部システム、端末、納期、予算を示し、機能の優先度と受け入れ条件も添えます。
• 非機能要件：性能や安全性、運用に関する条件を示します。
• 移行・連携：データの形式や履歴、API仕様、認証情報、再送、連携先の保守時間をまとめます。

非機能要件では、ピーク時の同時利用者数や1日の処理件数、表示時間、稼働時間を定めます。加えて、復旧目標やバックアップ頻度、ログの保存期間も決めます。

認証や権限、監視、脆弱性診断、アクセシビリティ、個人情報の保管場所も決めておきます。なお、数値を決められない項目は、開発会社に確認します。

データは、コード体系や顧客名の揺れ、日付形式、削除済みの分、添付ファイル、過去履歴まで整理しておきます。同じ前提を各社へ先に共有しておけば、会社ごとに異なる条件で見積もられる事態を防げます。

複数社の見積もりの比較方法

各社の提案は、同じ条件に並べて比べます。

• 見積内訳：3社程度に同じRFP、納期、範囲で提案を求め、工程別の費用と「一式」の作業、工数、成果物を確かめます。
• 提案姿勢：曖昧な要件への質問、優先順位、リスクを見ます。代替案、段階導入、保守、将来拡張も評価します。
• 体制・実績：責任者や要件定義、開発、運用の担当者が契約後も継続して参加するか、再委託の有無、近い案件の課題・規模・連携・期間・成果を確かめます。

質問が少なく、すぐに安い金額を示す会社は、後から仕様が追加される可能性があります。そこで面談では、契約後も担当者が継続して参加するかを尋ねます。再委託がある場合は、品質や情報管理、障害時の責任を確かめます。

実績は、社名や件数だけでは判断しにくいため、上の項目で挙げた点まで確かめます。

低すぎる見積もりと追加請求を防ぐチェックリスト

見積もりの抜けや追加請求は、契約の前に確かめておくことで防げます。

• 対象範囲：画面や権限、連携数、移行件数、ブラウザを確かめます。テストや環境、マニュアル、研修、保守期間も見ます。
• 仕様変更：変更の定義、無償修正の範囲、追加単価、納期への影響、承認者、契約ごとの扱いを決めておきます。
• 稼働後と資産：障害対応やパッチ、復元、報告、改修の窓口、コードやデータの取得、返却の形式を確かめます。

請負なら承認の遅れや外部サービスの変更時、準委任なら時間単価や稼働上限、成果物、品質確認の扱いを確かめます。障害の受付から初動、復旧目標、原因の報告までの流れも、契約前に決めておきます。

開発・検証・本番の3環境や、バックアップ、監視、ログ保存が含まれるかも見ます。また、クラウドの契約者も明確にしておきます。

よくある質問（FAQ）

発注前に判断しやすいよう、相談の多い疑問に答えます。業務やデータの条件に合わせて、開発会社への質問にも使ってください。

Webシステム開発にはどのくらいの期間がかかりますか？

小規模な会員・予約・申請システムは1〜3か月、権限や複数連携を含む中規模案件は3〜8か月が目安です。大規模な基幹連携や高い可用性を求める案件は、6〜18か月程度が目安です。ただし、要件整理や意思決定、データ移行、受け入れテストに時間がかかると、実装期間を短くしても全体の納期は縮みません。

予算が少ない場合はどの方式から検討すべきですか？

まずSaaSやパッケージ、ローコードで業務を満たせる範囲を確かめ、独自性の高い部分だけを追加開発します。また、新規サービスならMVPの必須機能に絞り、利用データを見て段階的に拡張すると、初期投資を抑えやすくなります。

データ移行やAPI制限、ライセンス費、セキュリティ要件を確かめないまま安さだけで選ぶと、後から高額な作り直しになる場合があります。

開発後の保守費用は何を見て比較すればよいですか？

保守費用は、障害対応や問い合わせ、監視、バックアップ、セキュリティパッチのうち、どこまでが保守に含まれるかで比べます。クラウド運用や軽微な修正のほか、受付時間や初動、復旧目標も確かめます。対応時間帯や緊急連絡、月の改修枠、対象外の作業も見ます。

会社によっては、初期費用に対する月額保守料を示すこともあります。その場合は、サービス内容と利用規模を合わせて判断します。

個人情報を扱うWebシステムで最低限確認することは何ですか？

利用者の識別・認証や役割別の権限、通信・保存データの暗号化、操作ログを要件に含めます。また、脆弱性対策やバックアップ・復旧、委託先の管理も要件に加えます。

管理者権限の分離や多要素認証、不要アカウントの無効化、ログの保存期間と閲覧権限も確かめます。

個人情報保護委員会のガイドラインや、IPAのTLS暗号設定ガイドラインを参照します。そのうえで、情報の種類とリスクに応じて診断範囲を決めます。

まとめ

Webシステム開発は、要件整理と選定を経て、設計・開発に進みます。そのあと、テスト、稼働、定着と続き、全体は6フェーズです。まず目的とKPIを定め、機能をMUST・SHOULD・COULDに分けます。そのうえで、SaaSやパッケージで満たせる範囲を確認してから、必要な部分に開発投資します。

発注前に確認する6フェーズの責任者と成果物

要件整理の責任者と受け入れ条件、選定の基準、設計レビューの参加者、テストの合格条件を決めておきます。また、移行と切り戻しの手順、稼働後の問い合わせ窓口も定めます。

見積書は、外部連携、移行、セキュリティ、クラウド、保守、追加開発に分けて、3年TCOで比べます。

最初に作る現行業務と理想の状態の整理表

現行業務と困っている作業、利用者、データ、外部連携を、改善したいKPIとあわせて1枚にまとめます。この1枚が、方式や開発会社を比べる前提になります。

そのうえで、標準サービスで足りるか、追加開発が必要かを資料に沿って検討します。そうすると、曖昧な見積もりや稼働後の追加請求を抑えやすくなります。

▼全体ガイドの記事
・Webシステム開発の完全ガイド

▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。