Web制作案件でバックエンド開発が必要になったとき、どこまで外注できるか
- 3 日前
- 読了時間: 11分
更新日：3 日前
Webサイト制作として受注した案件に、会員登録、予約、決済、外部API連携などの機能が追加された。デザインやフロントエンドは自社で対応できても、バックエンドまで内製するのは難しい。そんなとき、バックエンド部分だけを別の開発会社へ外注することはできるのでしょうか。
結論から言えば、制作会社側でデザインやフロントエンドを進めながら、バックエンド部分だけを外部へ切り出し、並行して開発することは可能です。 重要なのは、「画面側」「サーバー側」と単純に分けるのではなく、両者が接続する境界と、仕様を誰が決めるのかを先に整理することです。
はじめに：Web制作案件は、途中から「システム開発」になることがある
当初はコーポレートサイトやサービスサイトの制作案件だったとしても、顧客との打ち合わせが進むにつれて、
会員登録・ログインを付けたい
マイページを作りたい
予約や申込を管理したい
クレジットカード決済を導入したい
問い合わせ内容を社内システムへ連携したい
外部のSaaSやAPIとデータをやり取りしたい
管理者用の画面が必要になった
といった要望が追加されることがあります。
ここまで来ると、HTML・CSS・JavaScriptやCMSの設定だけでは完結しません。
ユーザー情報を保存するデータベース、認証、業務ロジック、外部APIとの通信、定期処理など、バックエンド開発が必要になります。
このとき、
「バックエンドまで自社で対応できないなら、案件全体を別会社へ渡さなければならない」
と考える必要はありません。
デザイン、フロントエンド、顧客との進行管理は制作会社側で持ったまま、必要なバックエンド機能だけを外部へ依頼するという分担ができます。
結論：バックエンドだけ外注し、画面制作と並行して進められる
たとえば会員制Webサイトであれば、
制作会社側
UI / UX設計
デザイン
HTML / CSS
フロントエンド
顧客との進行管理
バックエンド会社側
会員登録API
ログイン・認証
データベース
業務ロジック
外部API連携
決済処理
AWS等の実行環境
バックエンド側の試験
という分担が考えられます。
この形なら、バックエンドの完成を待ってから画面制作を始める必要はありません。
先に、
どのAPIを用意するか
どのデータを送受信するか
正常時・エラー時に何を返すか
認証をどう扱うか
といった接続条件を決めておけば、制作会社とバックエンド会社が並行して開発を進められます。
納期が限られているWeb制作案件では、この「並行できるかどうか」は重要です。
分業の目的は単に作業を外へ出すことではなく、制作会社側の進行を止めず、自社が得意な領域へ集中できる状態を作ることです。
Web制作案件で外注しやすいバックエンド領域
Web制作案件からバックエンド開発へ広がりやすい代表例が、予約・申込・問い合わせ機能です。
予約・申込・問い合わせは「フォームの延長」に見えて複雑になりやすい
最初は、
希望日時と氏名を入力して送信するだけ
というフォームに見えていても、顧客との打ち合わせが進むと、
予約枠ごとに定員を設定したい
満席の場合は受け付けたくない
同じ人の重複予約を防ぎたい
キャンセルしたら枠を戻したい
申込内容を管理画面で検索したい
ステータスを変更したい
受付完了メールを送りたい
社内システムにも登録したい
といった要件が増えてきます。
この段階になると、単純なフォーム制作ではなく、
「入力された情報をどのような業務ルールで処理し、どこへ保存し、その後どう管理するか」
というシステム開発になります。
Web制作会社が画面を担当し、予約判定、DB、管理処理、通知、外部連携などをバックエンド会社へ依頼する形に分けやすい領域です。
そのほか、会員・認証、外部API連携、決済、バッチ処理などもバックエンドとして外注できます。ただし、それぞれの切り出し方は案件によって異なります。
成果物単位でどこまで外注できるかについては、関連記事「バックエンド開発を外注するとき、どこまでを成果物として切り出せるのか」で詳しく解説しています。
API連携部分については、「API連携開発を外注するときに確認すべきポイント」も参考にしてください。
フロントエンドとバックエンドで「分けきれない部分」がある
ここが、Web制作案件を複数社で進めるときに重要なポイントです。
技術的にはフロントエンドとバックエンドを分けられても、1つの機能として見れば両方にまたがっている処理があります。
入力チェック
たとえば会員登録画面では、
メールアドレスが正しい形式か
必須項目が入力されているか
といったチェックは、画面側でも行えます。
しかし、
このメールアドレスは、すでに会員登録されていないか
という判断には、データベースを確認する必要があります。
つまり、
形式チェックはフロント側、登録済み判定はバックエンド側
と分かれることがあります。
さらに、バックエンドが「登録済み」というエラーを返したとき、画面のどこへどのメッセージを表示するかは制作会社側の実装です。
「入力チェック」という一つの機能だけでも、両社の作業が接続しています。
ログイン・認証
ログイン画面はフロントエンドですが、ID・パスワードを確認する処理はバックエンドです。
そのうえ、
ログイン状態をどう保持するか
未ログインならどこへ遷移するか
管理者と一般会員をどう区別するか
セッションが切れた場合に画面側でどう扱うか
といった仕様は、どちらか一方だけでは決められません。
ファイルアップロード
ファイルを選択する画面は制作会社側でも、
最大ファイルサイズ
許可するファイル形式
保存先
保存後のURL
エラー条件
などはバックエンドやインフラと関係します。
「ファイルをアップロードできるようにする」という一つの要望でも、フロントとバックをまたぐ仕様になります。
決済
決済も典型的です。
決済画面のUIは制作会社側でも、
決済事業者との通信
注文情報との紐付け
決済結果の保存
エラー時の処理
などはバックエンド側で行います。
その一方で、決済結果に応じて完了画面やエラー画面を表示する処理は、再びフロントエンド側へ戻ってきます。
つまり、
「決済をバックエンド会社へ頼んだから、制作会社側では何もしなくてよい」
とは限りません。
外注する際には、「どの会社が担当するか」だけではなく、機能の中で両社がどこで接続するかを見る必要があります。
分業で重要なのは「どちらが正しい仕様を持つか」
バックエンド会社へ外注するとき、技術上の担当範囲以上に重要なのが、仕様決定の責任を曖昧にしないことです。
たとえば顧客から、
会員登録の会社名を必須にしてください。
と変更依頼が来たとします。
この変更は、
画面の必須表示
フロント側の入力チェック
API仕様
バックエンド側の入力チェック
データベース
へ影響する可能性があります。
ここで、
制作会社「バックエンド側で対応していると思っていた」 バックエンド会社「画面仕様なので制作会社側で決まっていると思っていた」
となると、担当会社を分けたこと自体がトラブルの原因になります。
そのため、少なくとも次の3点は決めておきたいところです。
顧客との仕様調整を誰が行うか。
制作会社が元請けとして取りまとめるのか、技術的な相談ではバックエンド会社も打ち合わせへ参加するのか。
バックエンド側の技術仕様を誰が決めるか。
API、DB、認証、AWS構成などについて、バックエンド会社にどこまで設計を任せるのか。
変更を誰が取りまとめるか。
顧客から要件変更があった場合に、フロント・バック双方への影響を誰が確認するのか。
分業では、作業範囲だけではなく、情報と判断がどのように流れるかまで設計する必要があります。
バックエンド会社へ相談する前に、5つだけ整理しておく
詳細な仕様書を完成させてから相談する必要はありません。
まず、次の5点を分かる範囲で整理しておくと進めやすくなります。
自社で担当する範囲。
デザイン、HTML / CSS、フロントエンド、CMS、顧客窓口など、制作会社側で担当したい範囲を伝えます。
バックエンドが必要になった機能。
「システム開発が必要」という説明ではなく、「予約」「会員」「決済」「API連携」など機能単位で伝えます。
現在想定している接続方法。
APIで接続する、WordPressから利用する、既存CMSは変更したくない、フロント側のコードは自社管理など、決まっている条件を共有します。未定でも問題ありません。
顧客とどこまで要件が決まっているか。
詳細要件が未確定でも相談できます。特にバックエンドの方式が分からない場合には、要件整理から外部へ依頼する方法もあります。
全体を取りまとめる担当者。
制作会社のPMが全体を管理するのか、技術面ではバックエンド会社も顧客との打ち合わせへ参加するのかを整理します。
この段階で重要なのは、完璧な仕様を作ることではなく、「自社で持ちたい範囲」と「外部へ相談したい範囲」を説明できる状態にすることです。
具体例：会員制Webサイトを制作会社とバックエンド会社で分担する
たとえば、Web制作会社が会員制サイトを受注したとします。
制作会社側では、
UI / UX
デザイン
HTML / CSS
フロントエンド
顧客との進行管理
を担当します。
バックエンド会社へは、
会員登録API
ログイン・認証
会員情報DB
マイページ用データ取得・更新API
決済連携
管理機能用API
AWS環境
バックエンド側の試験
を依頼します。
このとき、両社で先に次の条件を共有します。
確認事項 | 整理例 |
API | 会員登録、ログイン、会員情報取得・更新 |
入出力 | 各APIで送受信するデータ |
認証 | ログイン後のAPI利用方法 |
エラー | エラーコードと画面側の表示 |
開発環境 | 両社が接続して確認できる環境 |
結合試験 | フロントとバックを接続して誰が確認するか |
仕様変更 | 制作会社のPMが顧客要望を取りまとめる |
接続条件を先に決めれば、バックエンド会社がAPIを実装している間にも、制作会社側は想定したAPI仕様を前提として画面開発を進められます。
分業のポイントは、「別々に作ること」ではなく、「最後につながる条件を先に決めておくこと」です。
バックエンドだけを切り出しにくい案件もある
すべてのWeb制作案件が、きれいにフロントエンドとバックエンドへ分離できるわけではありません。
たとえば、
CMSのテンプレート内に業務ロジックが大量に埋め込まれている
フロントとサーバー側が一体化した既存システムを大きく改修する
誰も現在の仕様を把握していない
顧客要望が頻繁に変わり、担当範囲を固定しにくい
既存不具合について、フロントとバックのどちらに原因があるか分からない
といったケースです。
このような案件では、最初から担当範囲を固定するより、まず現行調査や要件整理を行い、技術的にどこで分けられるかを確認してから外注範囲を決める方が安全です。
また、
画面は一切変更せず、バックエンドだけ変更してほしい。
という希望があっても、実現したい機能によってはフロントエンド側の修正が避けられない場合があります。
発注側が分けたい場所と、技術上きれいに分けられる場所は必ずしも一致しません。
この判断を外注前に行うことも、バックエンド会社へ相談する意味の一つです。
プレイリーソリューションズでは、制作会社側の領域を残した分業に対応しています
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、Web制作会社・Web開発会社が受注した案件について、デザインやフロントエンド、顧客との関係を制作会社側に残したまま、バックエンド領域を担当する形に対応しています。
二次請けを含め、他社が取りまとめる案件の中でバックエンド機能群を担当してきた経験があり、案件全体を引き取ることを前提とはしていません。
たとえば、
会員・認証
予約・申込
API
外部サービス連携
決済連携
データベース
バッチ処理
AWS
などについて、要件整理から設計・実装・試験まで対応します。
顧客から機能追加を求められ、
バックエンドが必要なのは分かるが、どこから外部へ任せればよいか分からない。
という段階でもご相談いただけます。
制作会社側の進め方を前提に、フロントエンドとの接続点、担当範囲、成果物を整理し、バックエンド部分を成果物単位の請負として担当する進め方が可能です。
まとめ：バックエンド外注では「境界」と「仕様の責任」を先に決める
Web制作案件でも、バックエンド部分だけを別の開発会社へ外注することは可能です。
デザイン、フロントエンド、顧客との窓口を制作会社側に残し、
API、認証、データベース、業務ロジック、外部連携、決済などを外部のバックエンド会社へ依頼する
という分担ができます。
接続条件を先に整理すれば、制作会社側の作業を止めず、両社で並行して開発を進めることもできます。
ただし重要なのは、
「フロントは自社、バックは外注」と会社を分けることだけではありません。
どこで両者が接続するのか
分けきれない機能をどう担当するのか
顧客との仕様調整を誰が行うのか
技術仕様を誰が決めるのか
変更時に誰が影響範囲を確認するのか
最後の結合確認を誰が担当するのか
まで整理することで、分業しやすくなります。
Web制作案件を受注しているものの、「会員機能や予約、API連携などのバックエンド部分を社内で対応できない」「案件全体ではなく必要な領域だけ外部へ依頼したい」という場合は、プレイリーソリューションズへご相談ください。
Java / AWSを中心としたバックエンド開発、API連携、決済連携、既存Webシステム改修について、成果物単位での請負開発に対応しています。
