Webアプリ開発の進め方：企画から公開までの工程と発注者の役割

Webアプリの開発を依頼するとき、発注者が知っておくべきことは「工程の名前」よりも「各工程で自分が何を決め、何を確認しなければならないか」です。開発会社はプロとして工程を進めてくれますが、事業の目的、業務のルール、優先順位、受け入れの判断は発注者にしか決められません。そこが曖昧なまま進むと、開発会社は推測で作るしかなく、完成してから「思っていたものと違う」という事態になります。

Webアプリ開発の工程は、大まかに「企画 → 要件定義 → 設計 → 開発 → テスト → 公開 → 運用・改善」と進みます。各工程の終わりには、発注者が確認して次に進むかどうかを判断する区切りがあります。この区切りで何を見ればよいかを知っていれば、開発の知識がなくても、プロジェクトの舵を取ることができます。

この記事は、Webアプリの開発を初めて外部に依頼する事業責任者や担当者に向けて書いています。工程ごとに発注者が決めること・確認することを整理し、手戻りを減らす進め方、架空の例、よくある失敗と避け方までを説明します。依頼前の会社選びや契約の流れはシステム開発を外注する流れで扱っているので、ここでは依頼した後の進め方を中心にします。

Webアプリ開発の工程と発注者の役割：全体像

まず全体像を一枚の表で示します。左から順に進み、各工程の終わりに「発注者が確認すること」を満たしてから次の工程に進むのが基本です。

この表を見ると分かるとおり、発注者の仕事は最初と最後に重くなります。企画と要件定義で「何を作るか」をはっきりさせ、テストと公開で「使える状態になったか」を判断する。中間の設計と開発では、開発会社からの質問に素早く答え、途中の成果物を見て早めにずれを指摘することが主な役割です。

工程は「一直線」とは限らない

上の表は順番に進む形で書いていますが、実際の進め方は開発会社や案件によって違います。すべての要件を最初に固めてから作る進め方もあれば、機能の塊ごとに要件定義・設計・開発・テストを短い周期で繰り返す進め方もあります。後者の場合は、上の表の工程が機能ごとに何度も回るイメージです。どちらの進め方でも、発注者が決めること・確認することの中身は変わりません。違うのは、それを一度にまとめて行うか、少しずつ繰り返し行うかです。

企画：目的と範囲を決める

企画は、発注者がもっとも主体的に関わる工程です。ここで決めることは次の四つです。

• 目的：このWebアプリで何を実現したいのか。「予約の電話対応を減らしたい」「取引先との受発注をWeb化して入力ミスをなくしたい」のように、事業や業務の言葉で書きます。
• 利用者：誰が使うのか。社外の顧客、社内のスタッフ、取引先、管理者など、立場ごとに書き出します。
• 成功の基準：公開後、何がどうなっていれば成功と言えるのか。数値でなくても構いませんが、後から振り返れる形にします。
• 制約：予算と時期の上限、使い続けたい既存のシステム、守るべき社内ルールなど。

この段階で「作らないもの」を決めておくことも大切です。最初の版に何でも入れようとすると、予算も期間も膨らみ、公開が遅れて目的の達成も遅れます。最初の版は目的に直結するものに絞り、それ以外は公開後の改善に回すという方針を、企画の段階で関係者と合意しておきます。

企画の終わりに確認すること

企画の終わりには、目的・利用者・成功の基準・制約・作らないものを一枚にまとめ、社内の関係者（経営者、利用部門の責任者、情報システムの担当者など）に見せて合意を取ります。ここで社内の意見がそろっていないと、要件定義の途中で別の部署から新しい要望が出てきて、範囲が膨らむ原因になります。

要件定義と設計：何を作り、どう作るかを決める

要件定義で発注者が担うこと

要件定義は、企画で決めた目的を、具体的な機能と業務のルールに落とし込む工程です。開発会社が主導して進めることが多いですが、中身を決めるのは発注者です。

発注者が用意・判断するのは、主に次のものです。

1. 業務の流れ：今どのように業務を行っていて、Webアプリでどう変わるのか。
2. 機能の一覧と優先度：何ができる必要があり、そのうち何が最初の版に必須か。作り方は機能一覧表の作り方で解説しています。
3. 業務のルール：料金の計算方法、承認の条件、締め日、キャンセルの扱いなど。
4. 例外の扱い：入力ミス、二重登録、途中でやめた場合、権限のない人が操作した場合など。
5. 非機能の条件：利用者数の見込み、求める表示速度、セキュリティの条件、バックアップなど。

要件定義の成果物は要件定義書としてまとめられます。何を書けばよいかは要件定義書の書き方にまとめています。発注者は書かれた内容を読み、自社の業務と合っているかを確かめます。分からない言葉や曖昧な表現があれば、遠慮なく質問してください。ここで理解しないまま承認すると、後で「書いてあったはず」という食い違いの原因になります。

設計で発注者が見るべきこと

設計は、要件をどう実現するかを決める工程で、開発会社の専門性がもっとも発揮される部分です。発注者がすべてを理解する必要はありませんが、次の点は確認します。

• 画面の構成と遷移：どの画面があり、どうつながっているか。業務の順番と合っているか。
• 入力項目と表示項目：入力する項目に過不足がないか。一覧画面に表示される情報で業務が回るか。
• データの持ち方：たとえば「一人の顧客が複数の住所を持てるか」「一つの注文に複数の配送先があり得るか」のように、業務の実態とデータの持ち方が合っているか。

最後の点は見落とされやすいのですが、非常に重要です。データの持ち方は後から変えるのがもっとも大変な部分の一つだからです。開発会社から「この情報は一つだけ持てる設計にしていますが、よいですか」と確認されたら、例外的なケースがないかを業務担当者に確かめてから答えてください。

開発とテスト：進捗の確認と受入テスト

開発中に発注者がすること

開発中は、開発会社が主に作業を進めます。発注者の役割は、次の三つです。

• 定例の打ち合わせに出る：週に一度など、決まった頻度で進捗と課題を確認します。
• 質問に素早く答える：開発中には必ず、要件定義で決めきれていなかった細部の確認が出てきます。回答が遅れると開発が止まるか、開発会社の推測で進むことになります。回答期限を決めておくと進めやすくなります。
• 途中の成果物を触る：動く画面ができたら、早い段階で実際に触ってみます。完成してからのずれの指摘は手戻りが大きくなりますが、途中の指摘なら小さな修正で済みます。

進捗の確認や課題の管理を開発会社任せにしない方法は、発注側のプロジェクト管理で詳しく解説しています。

開発中に新しい要望を思いついたり、業務のルールが変わったりすることもあります。そのときは、すぐに作業に加えてもらうのではなく、費用と期間への影響を確認したうえで、今の版に入れるか公開後に回すかを判断します。要望を口頭で伝えて済ませると、後で費用や範囲の認識がずれる原因になります。

テストで発注者がすること

テストは、開発会社が行うテストと、発注者が行う受入テストに分かれます。開発会社のテストは「設計どおりに動くか」を確かめるもので、受入テストは「業務で使えるか」を確かめるものです。受入テストは発注者の責任で行うものと考えてください。

受入テストの準備として、次のことを行います。

1. 業務のシナリオを書き出す（例：新規の顧客が登録して最初の注文をし、管理者が出荷処理をするまで）。
2. シナリオごとに、正常なケースと例外のケースを用意する。
3. テストする人を決める。実際にそのアプリを使う業務担当者に入ってもらうのが理想です。
4. 不具合を見つけたら、再現の手順、期待した結果、実際の結果を記録して開発会社に伝える。
5. 受け入れの基準（どの不具合が残っていたら公開できないか）を事前に決めておく。

受入テストの具体的な進め方とテストケースの作り方は、受入テストの進め方で解説しています。

公開と運用：使い始めてからが本番

公開前の準備

公開の直前は、システムそのもの以外の準備が多くなります。発注者が中心となって進めるのは次のようなことです。

• データの移行：既存の顧客情報や商品情報を新しいWebアプリに移す場合、移すデータの範囲と、移した後の確認方法を決めます。
• 利用者への案内：使い方の説明、ログイン情報の通知、問い合わせ先の案内を用意します。
• 業務の切り替え：いつから新しいアプリで業務を行うか、旧来の方法とどれくらいの期間並行させるかを決めます。
• 公開後の体制：公開直後の問い合わせや不具合に誰が対応するか、開発会社とどう連絡を取るかを決めます。

公開の前には、本番と同じ構成の検証用の環境で、実際のデータに近い量のデータを入れて最終確認を行うのが理想です。テスト用の少ないデータでは問題なく動いていたのに、本番のデータ量では一覧の表示が遅くなる、といったことは珍しくありません。また、公開当日に問題が起きた場合に旧来の方法に戻す手順（切り戻しの手順）も決めておくと、いざというときに慌てずに済みます。

公開日は、問い合わせが集中しにくい時期や、関係者が対応できる日を選びます。週末や長期休暇の直前の公開は、問題が起きたときの対応が遅れやすいため避けるのが無難です。

公開後の運用と改善

Webアプリは公開して終わりではありません。むしろ、実際に使われ始めてから分かることが多くあります。公開後は、次のサイクルを回します。

• 利用状況を確認する（どの機能が使われ、どこで利用者が止まっているか）
• 不具合と要望を集め、一覧で管理する
• 改善の優先順位を決め、開発会社と次の改修の範囲を合意する
• セキュリティの更新や、使っている部品の更新を定期的に行う

保守の範囲（不具合の修正はどこまで含むか、問い合わせへの対応時間、更新作業の頻度）は、公開前に契約で決めておきます。曖昧なまま公開すると、不具合の修正が無償か有償かで揉める原因になります。

具体例：架空の部品メーカーの受発注Webアプリ

架空の例として、部品メーカーが、取引先からのFAXと電話による注文をWebアプリに置き換える場面を考えます。

企画では、目的を「注文の転記ミスをなくし、受注担当者の入力作業を減らすこと」としました。利用者は取引先の購買担当者、自社の受注担当者、管理者の三種類です。作らないものとして、請求書の発行は既存の会計ソフトで続けることを決めました。

要件定義では、取引先ごとに異なる単価や、締め日の扱いが論点になりました。業務担当者に確認すると、特定の取引先だけ月の途中で単価が変わる例外があることが分かり、単価に有効期間を持たせる設計が必要になりました。これは要件定義の段階で見つかったため、小さな影響で済みました。

設計では、注文一覧の画面に「納期の近い順」で並べることと、取引先の名前で絞り込めることを確認しました。データの持ち方では、一つの注文に複数の納品先があり得るかを問われ、実際には年に数回あることが分かったため、複数の納品先を持てる設計にしました。

開発とテストでは、定例で途中の画面を触り、注文の確認画面に「前回と同じ内容で注文する」ボタンがほしいという要望が出ました。費用と期間への影響を確認したうえで、公開後の改善に回すことにしました。受入テストでは、受注担当者が実際の過去の注文を使ってシナリオをなぞり、締め日をまたぐ注文で表示が想定と違う不具合を見つけて修正しました。

公開では、まず協力的な取引先数社から使い始めてもらい、残りの取引先には一か月かけて順次案内しました。FAXによる注文も当面は並行して受け付け、問い合わせ窓口を受注担当者に一本化しました。

よくある失敗とその避け方

Webアプリ開発で、発注者側に原因がある典型的な失敗を挙げます。

• 企画の合意を取らずに進める：要件定義の途中で別部署から新しい要望が出て、範囲が膨らみます。企画の段階で関係者の合意を取ります。
• 要件定義書を読まずに承認する：専門用語が多くても、業務の部分は発注者が読んで確かめるべきです。分からなければ説明を求めます。
• 質問への回答が遅れる：開発が止まるか、推測で進んで手戻りになります。回答期限と窓口を決めておきます。
• 完成まで画面を見ない：途中で触っていれば小さな修正で済んだずれが、完成後に大きな手戻りになります。動くものができたら早めに触ります。
• 受入テストを開発会社任せにする：業務で使えるかどうかは、業務を知る発注者にしか確かめられません。
• 口頭で追加の要望を伝える：費用と範囲の認識がずれます。要望は記録に残し、影響を確認してから判断します。
• 公開後の体制を決めていない：公開直後の問い合わせや不具合に誰も対応できず、利用者の信頼を失います。

工程ごとの発注者チェックリスト

• 企画：目的・利用者・成功の基準・制約・作らないものを一枚にまとめ、関係者の合意を取った
• 要件定義：機能一覧と優先度、業務のルール、例外の扱いを確認し、要件定義書を読んで承認した
• 設計：画面の構成と遷移、入力・表示項目、データの持ち方が業務と合っているかを確認した
• 開発：定例に参加し、質問に期限内で回答し、途中の画面を触った
• テスト：業務のシナリオで受入テストを行い、受け入れの基準を満たしたことを確認した
• 公開：データ移行、利用者への案内、業務の切り替え方法、公開後の体制を決めた
• 運用：保守の範囲を契約で決め、改善の優先順位を定期的に見直す場を設けた

よくある質問

Q. 開発の知識がなくても、発注者として役割を果たせますか？

果たせます。発注者に求められるのは、技術の知識よりも、事業の目的と業務のルールを正確に伝え、判断を素早く下すことです。分からない技術用語は、その都度開発会社に説明を求めて構いません。説明を丁寧にしてくれるかどうかは、良い開発会社を見分ける目安にもなります。

Q. 発注者側には、どれくらいの時間が必要ですか？

案件の規模によって違いますが、企画・要件定義と、テスト・公開の時期は、担当者がまとまった時間を割く必要があります。開発中も、定例への参加と質問への回答の時間は確保してください。担当者が本業で忙しく時間が取れない状態は、遅れや手戻りの大きな原因になります。

Q. すべての要件を最初に決めないと、開発を始められませんか？

必ずしもそうではありません。最初の版に必須の機能だけを固めて開発を始め、公開後の利用状況を見ながら機能を足していく進め方もあります。特に新規事業では、最初からすべてを決めるより、小さく作って確かめる方が結果的に早く目的に近づけることが多いです。ただし、どの範囲を最初に作るかの合意は必要です。

Q. 開発の期間はどう決まりますか？

機能の量と複雑さ、外部サービスとの連携の有無、発注者側の判断や確認にかかる時間などで決まります。期間の考え方と短縮できる部分はシステム開発の期間で解説しています。

Otsumuに相談できること

目的と利用者がはっきりしていて、業務のルールも整理されており、社内に開発会社とのやり取りに時間を割ける担当者がいる場合は、この記事の工程表とチェックリストを手元に置いて、開発会社と一緒に自社で十分に進められます。発注者の役割を理解して臨むだけで、プロジェクトの進みやすさは大きく変わります。

一方で、目的は決まっているが何を最初に作るべきか絞り込めない場合、社内に開発の経験がある人がおらず要件定義書や設計の妥当性を判断できない場合、新規事業で作りながら仕様を決めていく必要がある場合は、企画の段階から伴走できる外部の力を借りた方が、手戻りを減らせます。

Otsumuは自らも事業を手がける立場から、企画・要件定義から開発・公開・運用改善までを一気通貫で支援しています。目的から逆算して必要な機能に絞り、AIを活用した少人数・短期間の開発で、早く使い始められる形を目指します。Webアプリの開発はWebアプリ開発、開発全般はシステム開発をご覧ください。新規事業の最初の版を短期間で作る場合は新規事業の爆速MVPシステム開発もご用意しています。

企画がまだ固まっていない段階でも構いません。目的と利用者を伺いながら、最初の版の範囲を一緒に整理するところから始められます。まずは30分の無料相談でお気軽にご相談ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01