Webアプリを外部に依頼するとき、意外と重要になるのが「ソースコード、公開環境、データベースをどのアカウントで管理するか」です。
たとえばNext.jsで作ったWebアプリをGitHubに置き、Vercelで公開し、Supabaseをデータベースとして使う場合、これらの所有者をお客様側にするのか、開発者側にするのかで、納品後の扱いが大きく変わります。
結論から言うと、受託開発として納品するWebアプリでは、原則として 所有者はお客様、開発者は共同作業者として参加 する形が分かりやすいです。
所有者: お客様
開発・保守担当: 開発者
作業方法: GitHub経由
本番反映: Vercelなどのデプロイサービスで自動化
DB・APIキー: お客様環境内で管理
この形にすると、お客様の資産として残ることと、開発者が保守しやすいことを両立できます。
お客様のPCやパスワードを預かる必要はない
よくある不安として、「お客様側のGitHubにコードを置くと、開発者が修正できなくなるのではないか」というものがあります。
実際には、開発者がお客様のPCにリモート接続したり、お客様のGitHub IDやパスワードを預かったりする必要はありません。
基本形は次のようになります。
お客様のGitHubアカウントまたはOrganization
└─ Private Repository
└─ 開発者のGitHubアカウントを共同作業者として招待
開発者は自分のGitHubアカウントで招待を承認し、自分のPCにリポジトリを取得して作業します。
git clone https://github.com/customer-company/project-name.git
修正後は、通常の開発と同じようにcommitしてpushします。
git add .
git commit -m "注文登録機能を修正"
git push
プライベートリポジトリであっても、所有者が開発者をcollaboratorやmemberとして招待すれば、権限の範囲内でコードを閲覧、編集、pushできます。コードを一般公開する必要はありません。
所有者と作業者を分ける
受託開発で大事なのは、所有者と作業者を分けて考えることです。
| 項目 | おすすめの整理 |
|---|---|
| ソースコードの所有者 | お客様 |
| GitHubリポジトリの所有者 | お客様 |
| デプロイ環境の所有者 | お客様 |
| データベース環境の所有者 | お客様 |
| 実際に開発・修正する人 | 開発者 |
| 保守時の作業権限 | 開発者へ必要な範囲で付与 |
この整理にすると、システム一式はお客様の資産として残ります。一方で、開発者は必要な権限をもらって通常どおり作業できます。
お客様側のアカウントで管理するメリット
お客様側のアカウントで管理する最大のメリットは、Webアプリが明確にお客様の資産として残ることです。
- ソースコードがお客様の管理下に残る
- データベースやデプロイ環境の所有者が明確になる
- 将来的に他の開発者へ引き継ぎやすい
- 契約終了後に開発者の権限を整理しやすい
- 事業用システムとして管理責任を明確にしやすい
特に、業務データや顧客情報を扱うWebアプリでは、データベースの所有者が曖昧な状態は避けた方がよいです。
開発者側のアカウントで全てを管理すると、開発者にとっては保守しやすくなります。ただし、お客様から見ると「ソースコードはどこにあるのか」「別の業者へ引き継げるのか」「解約時に何が残るのか」が分かりにくくなります。
そのため、開発者側アカウントで運用する場合は、納品型ではなく、運用代行型や月額管理サービスに近い位置づけとして契約内容を明確にしておく必要があります。
GitHubへpushすると自動デプロイできる
VercelなどのデプロイサービスとGitHubを連携しておくと、開発者がGitHubへpushしたタイミングでWebアプリを自動更新できます。
開発者のPCで修正
↓
GitHubへpush
↓
Vercelなどが自動デプロイ
↓
Webアプリが更新
この流れにすると、修正のたびにZIPファイルを送ったり、お客様のPCで操作したりする必要がありません。
お客様所有の環境に置いたまま、開発者が保守しやすい状態を作れます。
DBやAPIキーはGitHubに直接書かない
Webアプリでは、ソースコードだけでなく、API_TOKENやDB接続情報の扱いも重要です。
基本的には、役割を次のように分けます。
GitHub: ソースコード
Vercel等: 環境変数
Supabase等: データベース本体
環境変数に入れる値や、強い権限を持つSecret Key、Service Role Keyを、GitHubのソースコードへ直接書くのは避けます。
特にブラウザ側のJavaScriptへ強い権限のキーを出すと、利用者から見えてしまう可能性があります。サーバー側だけで扱う値は、Vercelなどの環境変数に設定し、必要な処理だけをサーバー側で行う構成にします。
納品型と運用代行型を分ける
受託開発では、納品型と運用代行型を分けて考えると説明しやすくなります。
| 項目 | 納品型 | 運用代行型 |
|---|---|---|
| アカウント所有 | お客様 | 開発者 |
| 保守のしやすさ | 権限付与で対応 | 開発者側で対応しやすい |
| 引き継ぎ | しやすい | 移管作業が必要 |
| お客様の管理負担 | ややあり | 少ない |
| 契約の性質 | 単発開発 + 必要に応じた保守 | 月額管理・運用代行向き |
どちらが常に正しいという話ではありません。
お客様側で技術アカウントを持つのが難しい場合は、開発者側で運用を代行する形もあります。その場合は、月額費用、解約時の移管、DBやドメインの扱い、ソースコードの引き渡し条件を事前に決めておく方が安全です。
保守契約の有無で権限を整理する
開発中は、開発者にある程度の権限が必要です。
たとえば、GitHubはWriteまたはAdmin、VercelはDeveloperまたはAdmin、SupabaseはDB設計や確認ができる権限が必要になることがあります。
納品後は、保守契約の有無で整理します。
- 保守契約がある場合: 修正依頼に対応できるよう、必要な権限を残す
- 保守契約がない場合: 開発者の権限を削除してもよい状態にする
- 再依頼がある場合: 必要なタイミングで再度招待してもらう
保守契約がない状態で権限を削除するなら、README、起動手順、デプロイ手順、環境変数一覧、使用サービス一覧、DB構成の概要などを納品しておく必要があります。
開発者側で用意しておきたい納品物
Webアプリを納品するときは、アプリ本体だけでなく、将来の保守や引き継ぎ資料も重要です。
- README
- ローカル起動手順
- デプロイ手順
- 環境変数一覧
- 使用サービス一覧
- DB構成の概要
- 権限設定のメモ
- バックアップ方法
- 保守時の連絡・対応範囲
- 再デプロイ時の注意点
このあたりを整えておくと、お客様が将来的に別の開発者へ引き継ぐ場合も説明しやすくなります。
開発相談時に確認したいこと
Webアプリの開発相談では、機能だけでなく、運用環境についても最初に確認した方がよいです。
- お客様側でGitHubやVercelのアカウントを作れるか
- データベースをどちらのアカウントで持つか
- ドメインを誰が管理するか
- 納品型なのか、運用代行型なのか
- 保守契約を付けるか
- 将来的に他業者へ引き継ぐ可能性があるか
- APIキーや認証情報をどこで管理するか
ここを曖昧にしたまま開発すると、完成後に「コードはどこにあるのか」「データは誰のアカウントにあるのか」「解約したら使えなくなるのか」という不安につながります。
最初にアカウント設計を決めておくと、開発後のトラブルを減らせます。
関連記事
- 既存ソフトの販売終了・サポート終了で代替開発依頼が増えている背景
- 「伝わっているはず」の落とし穴: 開発請負・要件定義・心理学から考える認識ズレ
- 開発の相見積もりで気を付けたいポイント
- 生成AIを活用した新しいシステム導入サービスの考え方
- GoogleフォームかGAS Webアプリかを選ぶ判断材料
- GAS Webアプリ納品時の導入サポート
- Power Apps受託開発の流れを解説
- ElectronアプリのソースコードをGitHubへワンクリックで納品する方法
まとめ
Webアプリ受託開発では、GitHub、デプロイ環境、データベースを誰のアカウントで管理するかが重要です。
最もバランスが良いのは、原則として次の形です。
所有者: お客様
開発者: 共同作業者として参加
作業方法: GitHub経由
本番反映: デプロイサービスで自動化
DB・APIキー: お客様環境内で安全に管理
この形なら、お客様にとってはWebアプリが自分の資産として残り、開発者にとっては保守や修正も行いやすくなります。
当方では、Excel VBA、Google Apps Script、Webアプリ開発において、納品後の保守や引き継ぎまで見据えた構成を重視しています。GitHub、デプロイ環境、データベースの管理方法も、案件内容に合わせて整理しながらご提案します。