バックエンド開発を外注するとき、責任分界はどう決めるべきか
- 2 日前
- 読了時間: 11分
バックエンド開発を外注するとき、「API部分をお願いします」「バックエンド一式をお願いします」と担当範囲を決めるだけでは、責任分界が十分とは限りません。
業務ルールを誰が決めるのか、どこまで試験するのか、本番リリースや障害時の一次切り分けを誰が担うのかまで整理しておくことが重要です。
はじめに：「バックエンドを任せる」だけでは責任分界は決まらない
バックエンド開発は、比較的切り出して外注しやすい領域です。
たとえば、
JavaによるAPI開発
外部サービスとのAPI連携
データベース設計・改修
決済連携
AWS上のバックエンド構築
既存Webシステムの機能追加
などは、機能や成果物として範囲を定義できます。
どこまでを成果物として切り出せるかについては、バックエンド開発を外注するとき、どこまでを成果物として切り出せるのかでも解説しています。
しかし、成果物が決まっても、それだけで案件の責任分界が決まるわけではありません。
たとえば「外部サービスと連携するAPIを開発する」という依頼でも、
外部APIがエラーになったとき、業務上どう扱うのか
データが食い違った場合、どちらを正とするのか
フロントエンドまで含めた結合試験を誰が行うのか
テスト用アカウントやデータを誰が準備するのか
本番環境へのリリースを誰が実行するのか
リリース後にエラーが発生した場合、最初に誰が調査するのか
といった判断が残ります。
「何を作るか」と「その周辺で誰が何を担うか」は、分けて考える必要があります。
結論：責任分界は「決める・作る・確認する・本番で切り分ける」の4つで整理する
バックエンド開発を外注するときは、責任分界を次の4つに分けると整理しやすくなります。
１．誰が決めるのか
業務ルール、仕様、例外時の振る舞いなどを誰が決定するか
２．誰が作るのか
ソースコード、API、DB変更、設計書、手順書など、何を成果物として担当するか
３．誰が確認するのか
単体試験、結合試験、システム全体の試験、受入試験をどこまで担当するか
４．本番で誰が動くのか
リリース、本番確認、障害発生時の一次切り分けを誰が担当するか
たとえば「設計から試験までバックエンドをお願いします」と決めても、業務ルールの最終決定者や、本番リリースの実行者までは決まっていません。
責任分界は、工程名だけで区切るのではなく、案件を進めるために必要な判断と作業を具体的に分解して決めることがポイントです。
1. 業務ルール――「実装する人」と「決める人」を明確にする
バックエンドでは、画面から見えにくい業務ルールを数多く扱います。
たとえば外部APIとの連携であれば、
タイムアウトしたら自動で再実行するのか
同じリクエストが複数回来た場合はどうするのか
外部APIは成功したが、自社DBの更新に失敗した場合はどうするのか
外部サービスと自社システムでデータが違った場合、どちらを正とするのか
一度完了した処理を取り消す場合、どこまで元に戻すのか
といった判断が必要になることがあります。
開発会社から技術的な選択肢や影響を提示することはできます。しかし、業務上どの振る舞いが正しいのかは、発注側や元請側で判断しなければ決められないケースもあります。
逆に、要件整理そのものをバックエンド開発会社へ依頼するのであれば、それも担当範囲として定義できます。
重要なのは、
「仕様が決まっているか」だけではなく、「未決事項が出たときに誰が最終判断するか」が決まっていることです。
仕様確認のたびに「エンド顧客へ聞かないと分からない」「誰が決めてよいか分からない」という状態になると、実装そのものより確認待ちで工程が止まりやすくなります。
2. 試験――「テストをするか」ではなく、どこまでを合格範囲にするか
バックエンド開発の責任分界で見落とされやすいのが試験範囲です。
「試験込み」と書かれていても、その意味は案件によって異なります。
たとえば、
バックエンド内部の単体試験
DBを含めた結合試験
外部APIとの接続試験
フロントエンドとバックエンドをつないだ試験
システム全体の業務シナリオ試験
発注側による受入試験
は、それぞれ別の範囲です。
バックエンド開発会社が担当するAPI自体は正常に動いていても、フロントエンドから送信される値が想定と異なれば、システム全体としては正常に動きません。
このような場合に備えて、発注前に少なくとも、
どの試験まで外注範囲に含めるか
試験環境を誰が準備するか
テストデータを誰が準備するか
外部サービスのテスト用アカウントを誰が用意するか
何を確認できれば納品・検収とするか
を整理しておくと、責任範囲を明確にできます。
特に成果物単位で請負開発を行う場合は、成果物と検収条件をセットで考えることが重要です。
成果物単位での外注については、システム開発を「人月」ではなく「機能・成果物単位」で外注するにはでも詳しく解説しています。
3. リリース――「開発完了」と「本番反映」は分けて考える
開発会社が実装を完了したあと、誰が本番環境へ反映するのかも事前に決めておきたいポイントです。
バックエンドのリリースでは、案件によって、
リリース手順書の作成
アプリケーションのデプロイ
DBマイグレーション
AWSなどの設定変更
リリース前後の確認
問題発生時の切り戻し
リリース実施可否の最終判断
などが必要になります。
ここで「リリース対応もお願いします」とだけ決めるのではなく、手順を作る人、実際に操作する人、最終判断する人を分けて整理すると明確になります。
たとえば、セキュリティ上の理由から外部ベンダーへ本番AWSの操作権限を付与しない案件であれば、
バックエンド開発会社がリリース手順を作成する ↓ 発注側の担当者が本番環境で実行する ↓ バックエンド開発会社が結果を確認する
という分担も考えられます。
反対に、本番作業まで外注するのであれば、必要な権限や作業時間、切り戻し方法まで含めて範囲を決めます。
4. 障害対応――「誰の責任か」より先に、一次切り分けを決めておく
本番稼働後に問題が発生したとき、最初から原因が分かっていることは多くありません。
たとえば、画面上で「処理に失敗しました」と表示されたとしても、原因は、
フロントエンド
バックエンド
データベース
AWSなどのインフラ
外部API
既存システム
他ベンダーが担当した機能
のどこにあるか、調査してみなければ分からない場合があります。
このとき重要なのは、障害が発生した瞬間に「誰の責任か」を決めることではありません。
まず、
問い合わせを最初に受けるのは誰か
最初にどのログや状態を確認するのか
バックエンド側でどこまで調査するのか
他システムが原因と考えられる場合、誰へ引き継ぐのか
引き継ぐ際にどの情報を渡すのか
という一次切り分けの流れを決めておくことが実務上は重要です。
たとえばバックエンド開発会社が、担当機能のアプリケーションログとDB状態まで確認し、担当範囲に問題が見つからなければ、確認結果を添えて元請側へ返す、といった分担です。
これなら、原因が確定する前から責任の押し付け合いになることを避けつつ、調査を前へ進められます。
責任分界は「責任分担表」だけで終わらせず、発注条件へ落とす
責任分界を打ち合わせで決めても、議事録の中だけに残してしまうと、見積や開発条件とずれることがあります。
実際の発注条件へ落とすときは、次のように整理します。
項目 | 決める内容 |
対象範囲 | 外注先が担当する機能・工程 |
対象外 | 発注側、元請側、別ベンダーなどが担当する作業 |
前提条件 | 必要な仕様、環境、アカウント、テストデータ、外部サービス契約など |
成果物 | ソースコード、設計書、API仕様、試験結果、設定値、リリース手順など |
検収条件 | 誰が、どの環境で、何を確認したら完了とするか |
仕様変更時の扱い | 追加見積やスケジュール再調整を行う条件 |
つまり責任分界は、契約書の一項目だけで決めるものではありません。
対象範囲・対象外・前提条件・成果物・検収条件を一貫させることで、実際に運用できる責任分界になります。
具体例：API連携部分だけをバックエンド開発会社へ外注する場合
たとえば、SIerやWeb開発会社がエンド顧客からWebシステムを受注し、フロントエンドは自社で開発し、バックエンドのAPI連携部分を外注するケースを考えます。
一例として、次のような分担が考えられます。
発注側・元請側
エンド顧客との要件確認
業務ルールの最終決定
フロントエンド開発
顧客による受入試験の調整
本番リリース日時の調整
バックエンド開発会社
API・DBの設計
バックエンド実装
外部API連携
担当範囲の単体・結合試験
API仕様や試験結果など、合意した成果物の納品
両者で事前に決める部分
フロントエンドとバックエンド間のインターフェース
異常時の業務ルール
システム全体を使った試験範囲
本番リリース時の役割
障害発生時の一次切り分け方法
もちろん、これが唯一の正解ではありません。
案件によって、バックエンド開発会社が要件整理から担当することもあれば、本番リリースまで一括して担当することもあります。
大切なのは、「バックエンド」という技術領域の境界と、「誰が判断・確認・運用するか」という責任の境界を別々に確認することです。
決済連携のように、外部サービスの契約・審査、3Dセキュアを含む画面遷移、既存業務との状態連携など固有の境界が加わるケースについては、顧客案件の決済連携部分だけを外部開発会社へ委託するときの切り出し方で詳しく解説しています。
責任分界がまだ決められないなら、無理に固定価格へ押し込まない
相談段階では、責任分界をすべて決められない案件もあります。
特に、
既存システムの仕様が分からない
外部APIの制約をまだ調査できていない
どこまで改修が必要か判断できない
発注側でも業務ルールを整理している途中
他ベンダーとの境界がまだ決まっていない
といった状態では、最初からすべてを固定価格の請負範囲へ入れると、前提条件を多く置かざるを得ません。
ここでは、未確定事項があるかどうかではなく、その未確定事項が金額・責任・納期へどこまで影響するかで判断します。
たとえば、軽微な未確定事項で、採用する前提を見積書へ明記すれば工数や責任範囲を合理的に見通せるのであれば、「条件付き」で固定価格の見積へ進むことができます。
一方で、既存システムを調べなければ改修範囲そのものが分からない、外部APIの技術検証をしなければ方式を決められないなど、調査結果によって工数や責任範囲が大きく変わる場合は、固定価格を出す前に「調査先行」とするほうが安全です。
プレイリーソリューションズでは、固定価格の見積を行う前に、対象範囲・対象外・成果物・検収条件・環境・外部依存・責任分界などを確認しています。
工数や責任範囲へ大きく影響する不明点が残っている場合には、それを無理に見積金額へ飲み込むのではなく、調査・要件整理を小さく切り出し、その結果をもとに成果物単位の請負開発へ進む方法も取れます。
「まだ責任分界を決められない」こと自体が問題なのではなく、未確定な部分を未確定のまま固定価格の範囲へ入れないことが重要です。
発注前に使える責任分界チェックリスト
バックエンド開発を外注する前に、次の項目を確認してみてください。
業務ルールの最終決定者が分かっている
外注先が担当する機能・工程を説明できる
外注先が担当しない範囲を説明できる
納品される成果物が決まっている
外注先が実施する試験範囲が決まっている
試験環境・データ・アカウントを誰が用意するか決まっている
誰が何を確認して検収するか決まっている
本番リリースの手順作成者・実行者が決まっている
障害発生時の一次切り分け方法が決まっている
仕様変更や追加要望が出た場合の扱いが決まっている
すべてが発注前に確定している必要はありません。
決まっていない項目がある場合は、誰が、いつまでに決めるのかまで整理しておくと、開発開始後の停滞を減らせます。
まとめ：最初に決めるべきなのは「どこまで作るか」だけではない
バックエンド開発を外注するとき、まず成果物として切り出せる範囲を決めることは重要です。
ただし、実際に案件を進めるには、その周辺にある、
誰が業務ルールを決めるのか
誰が何を成果物として作るのか
誰がどこまで試験・検収するのか
誰がリリースし、障害時に最初の切り分けをするのか
まで整理する必要があります。
そして、その内容を対象範囲・対象外・前提条件・成果物・検収条件へ反映させます。
責任分界とは、「問題が起きたときに誰の責任にするか」を決めるためだけのものではありません。案件を止めずに進めるために、誰が何を判断し、何を実行するのかを事前に整理するものです。
SIer・Web開発会社の方で、顧客案件のバックエンド領域を成果物単位で切り出したいものの、対象範囲や責任分界がまだ整理しきれていない場合は、プレイリーソリューションズへご相談ください。
要件整理・技術調査から、Java / AWS、API連携、決済連携、既存Webシステム改修の設計・実装・試験まで、案件に合わせて切り出し方を整理します。
