Bitbucketの発注は、要件と委託範囲を決めてから、発注形態と契約を固め、PoC、移行、引き継ぎの順に進めます。
発注先を選ぶ前に、どこまでを任せるかを決めておくと、費用と責任のずれを防げます。
▼全体ガイドの記事
・Bitbucketのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Bitbucketのシステム発注・外注の意味
Bitbucketの発注は、リポジトリの作成だけでなく、開発の流れ全体の設計と構築を委託することです。
委託の範囲は、開発チーム、リポジトリ、ブランチの設計から始まります。さらに、レビューやCI/CD、Jiraや認証基盤との連携、移行後の運用まで範囲に含められます。
開発基盤としてのBitbucket
Bitbucketは、業務システムそのものではなく、開発の土台です。その働きは、コードの管理、自動化・追跡、アプリの稼働の3つの層に分かれます。
- コード管理：AtlassianのGitサービスで、ソースコード、ブランチ、プルリクエストを扱います。
- 自動化・追跡：Pipelinesによるビルド・テスト・デプロイと、Jira課題との連携による変更の把握。
- アプリの稼働：販売・顧客管理の画面とデータはクラウドや社内サーバーに置き、Bitbucketはリリース経路にします。
RFPの冒頭でこの切り分けを示しておくと、アカウント発行と、CI/CDを含む基盤構築の見積もりを区別できます。
Cloud・Data Center・Hybridの選び方
形態を選ぶときは、保守を任せたいか、データやネットワークを自社で管理したいか、既存環境を残すかを先に考えます。
- Cloud：Atlassianが基盤の保守とアップグレードを担うSaaS。
- Data Center：自社が選んだインフラに置き、運用方針を自ら管理する形態。
- Hybrid：既存のData Centerを残しながら、Cloudの機能も取り入れる構成。
Cloudは、早く始めたい小規模から中規模のチームにふさわしい形態です。一方で、ネットワーク分離、データ管理、可用性、更新時期を自社の方針で管理したい場合は、Data Centerが選択肢になります。
Atlassianは、Cloudを継続的な更新を任せられる形態、Data Centerを複雑な運用要件がある組織や、すぐに移行するのが難しい組織向けと説明しています（出典：Atlassian「Bitbucket Pricing」、2026年8月確認）。
発注先には、データの置き場所やSSOの扱いを含めて、形態を選んだ理由を示してもらいます。監査、バックアップ、障害対応についても、同じように踏まえた説明を求めます。
Bitbucketの発注形態と委託範囲の選び方
発注形態は、成果物がどこまで確定しているか、自社に管理者やDevOps担当者がいるか、要件が変わりそうかで選びます。さらに、設定だけを頼むのか、移行やCI/CDまで頼むのか、運用支援も含めるのかを分けておくと、費用と責任のずれを防げます。
完成物が明確な場合の請負型による一括発注
成果物と完了条件が明確なら、請負型が候補になります。たとえば、指定したリポジトリの移行、ブランチ保護と標準Pipelineの設定、受入テストの合格を成果物として扱えます。
請負で依頼するときは、成果物と責任範囲を一覧にして、発注側と開発会社で合意しておきます。
- 構築・移行：初期導入、移行ツールの設定、Pipeline定義。
- 引き渡し：設計書、運用手順書、教育資料。
- 責任と変更：完成の範囲と発注者の判断範囲を分け、追加見積もりのルールを定めます。
請負型であっても、Bitbucketの導入効果や開発文化の定着までは保証されません。発注者側にレビュー責任者がいない場合や、既存リポジトリの棚卸しが終わっていない場合は、作業の途中で前提が変わります。
要件が変わる場合の準委任型・伴走型の組み合わせ
調査や設計を進めながら最適解を探す場合は、準委任型の伴走が候補になります。たとえば、CloudとData Centerの比較、現行環境の調査、運用設計、段階的なPoCに使えます。
月単位またはスプリント単位で、アーキテクト、DevOpsエンジニア、プロジェクトマネージャーなどの役割を決めます。あわせて、稼働時間、会議体、成果報告の形式も契約に含めます。
工程ごとに契約形態を分ける場合は、次のように組み合わせます。
- 準委任：要件定義と移行計画。
- 請負：確定した設定・開発と受入試験。
- 準委任：運用監視と改善。
経済産業省のモデル契約書は、企画支援や要件定義支援を準委任型とし、外部設計や開発は要件の確定度に応じて請負型か準委任型とする構成を示しています（出典：経済産業省「ソフトウェア開発委託基本モデル契約書」）。
標準機能の活用と不足部分の追加開発
まず標準機能で業務を組み立て、標準機能では解決できない部分だけを追加開発する方針をおすすめします。
- 標準機能：リポジトリ、プルリクエスト、ブランチ権限、Pipelines、Jira連携。
- 追加開発：承認、監査、社内ポータル、通知、台帳連携などの不足機能。
追加開発には、Forge、REST API、Webhookなどを使えます。ただし、独自ポータルや複雑なワークフローを作り込むと、更新や担当交代のたびに保守の負担が増えます。
将来は標準機能で置き換えられるか、ソースコードやIaC、設定値を引き渡せるか、仕様変更時に誰が修正するかを確かめておきます。独自開発を小さく保つと、委託先を変えやすく、総保有コストも抑えられます。
RFPと要件整理の進め方
RFPは製品の機能一覧ではなく、自社の開発・リリース上の課題と、外注で実現したい状態を伝える資料です。
現状と目的、対象範囲、非機能要件を書きます。さらに、移行条件と成果物、予算の考え方を書き、提案依頼事項も添えます。
現状と導入目的の数値化
まず、開発者数と管理者数、リポジトリ数と容量を整理します。次に、利用中のGitサービス、ブランチ数、月間プルリクエスト数を数えます。さらに、デプロイ先とリリース頻度も書き出します。
レビューが特定の人に偏る、本番反映の承認者を追えない、Jira課題と変更履歴が結び付かないといった課題は、発生頻度や確認時間も記録しておきます。
目的は、Bitbucketの導入そのものではなく、達成したい状態と評価指標で表します。
- 達成する状態：mainへの直接反映の廃止、リリース前テストの記録、退職者の権限の当日中の無効化。
- 評価指標：リードタイム、変更失敗率、復旧時間、レビュー実施率など、品質と安全性も測る項目。
機能要件と非機能要件の分け方
RFPには、機能要件と非機能要件を分けて書き、利用者の役割ごとの操作範囲も示します。
- 機能要件：階層と命名規則、レビュアーとブランチ保護、Jira・Confluence連携、Pipeline、Webhook・API連携。
- 非機能要件：可用性と復旧時間、監査ログとバックアップ、秘密情報とIP制限、SSOと個人情報、データ所在地とサポート時間。
管理者と開発者、レビュー担当者と運用担当者、外部委託先ごとに操作権限を整理すると、設計の漏れを減らせます。
Cloudの場合も、SaaS側と自社の責任を分けて考えます。自社が管理するのは、アカウントと権限、設定、削除操作です。
Atlassianによると、Cloudのバックアップは災害復旧用で、利用者が削除したリポジトリの復元に、そのまま使えるものではありません（出典：Atlassian Support「Differences administering Bitbucket Data Center and Cloud」、2026年8月確認）。
移行対象と受入条件の明文化
移行対象はRFPに列挙し、移行の前後で照合する方法と完了条件を決めておきます。
- 対象データ：リポジトリとブランチ、タグ、コミット履歴、プルリクエストとコメント。
- 関連設定：課題連携、Webhook、権限、アプリ設定。
- 照合項目：ハッシュ値とリポジトリ数、主要ブランチとタグ数、代表的なプルリクエスト。
移行元としては、Bitbucket Server・Data Center、GitHub、GitLab、Perforceなどが想定されます。Data CenterからCloudへの移行には、Bitbucket Cloud Migration Assistantが推奨される無償ツールです。
プロジェクト設定と権限、ブランチ権限、Marketplaceアプリ、プルリクエストの添付などは、自動では移行されない制限があります（出典：Atlassian Support「Cloud migration methods for Bitbucket」、2026年8月確認）。RFPでは、ツールを実行するだけでなく、権限とレビュー運用を再現し、受入テストに合格することを完了条件にします。
発注後の進行工程
発注後は、要件定義から運用引き継ぎまで、次の工程を順に進めます。
- 要件定義
- PoC・設計
- 構築・移行
- テスト・教育
- 運用引き継ぎ
代表例で検証してから段階的に広げると、全リポジトリを一度に移す場合より、開発停止のリスクを抑えられます。
代表リポジトリでのPoCと基本設計
PoCでは、代表リポジトリを一つから三つ程度選び、主要な開発・リリース手順と失敗時の対応を実地で確かめます。
- clone、ブランチ作成、プルリクエスト、レビューの一連の流れ。
- テスト、ステージングデプロイ、失敗時の再実行とロールバック。
- mainへの権限のない反映、テスト失敗、外部API停止、秘密情報の誤登録も対象にします。
基本設計では、プロジェクトとリポジトリの階層、ブランチモデル、レビュー人数、マージ条件を決めます。加えて、環境別の承認者、秘密情報、通知先、監査ログの確認方法も決めます。
標準設定を変えた理由を設計書に残しておくと、運用担当者が設定の意味を理解しやすくなります。
構築・移行・テストの小単位での繰り返し
設計の後は、構築、移行、テストをチームやプロジェクトごとに進め、旧環境の切り替え時期も計画します。
- ワークスペースとユーザー、グループ、リポジトリ、ブランチ権限の構築。
- Jira連携、Pipelines、デプロイ環境の構築。
- 移行前の凍結時間、DNS・Webhookの切り替え、旧環境を読み取り専用にする期間。
- 閲覧・push・merge、レビューとPipeline、本番承認、変更者と時刻の記録のテスト。
画面の操作だけでなく、適切な利用者だけが操作できるか、レビューとPipelineの成功を必須にできるかを確かめます。
Atlassian Supportによると、CloudのPremiumでは、マージチェックを強制でき、環境ごとのデプロイ権限も設定できます（出典：Atlassian Support「Use branch permissions」「Set custom deployment permissions for your environments」、2026年8月確認）。
教育と運用引き継ぎによる定着
教育は役割別に分け、設定の知識が管理者だけに偏らないようにします。
- 管理者：ユーザーとグループ、権限、課金、監査。
- 開発者：ブランチ、レビュー、Pipeline、障害時の再実行。
- 運用担当者：デプロイ承認、アカウント停止、バックアップ確認。
教育が足りないと、古いブランチ運用が続いたり、Bitbucketが単なるファイル置き場になったりします。
引き継ぎ成果物には、構成図、設定一覧、リポジトリ台帳、ロール一覧を含めます。さらに、Pipeline定義と秘密情報の登録手順、監視・通知、障害対応手順、月次点検表も含めます。
発注先への問い合わせ方法と、Atlassianサポートへ問い合わせる条件を決めておくと、障害時に担当者を探す時間を減らせます。
Bitbucketの外注における契約形態と契約書の記載事項
製品ライセンスの購入と、導入・移行・開発・保守の委託契約は、分けて考えます。ライセンス費を含む場合でも、契約主体、管理者、解約時のデータや設定の返却を確かめておきます。
一般的な整理として、契約書は自社の法務担当者や弁護士にも確認します。
完成責任と作業支援に応じた請負・準委任の選択
成果物を完成させる責任を求める業務か、作業支援そのものを求める業務かで、契約形態を選びます。
- 請負：成果物を完成させて引き渡す業務。
- 準委任：調査と助言、設計支援、運用支援など、状況に応じて調整する業務。
請負では、対象リポジトリや設定、Pipelineを具体化するほど、完成責任と検収条件が明確になります。移行結果、文書、受入基準も、同じ程度まで具体化しておく必要があります。
要件整理は準委任、確定した設定の構築は請負、運用改善は準委任と、工程ごとに分ける方法もあります。
IPAのモデル契約書は、報酬請求と契約不適合責任、中途解除を論点にしています。さらに、セキュリティとプロジェクト管理義務にも触れています（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。
成果物、知的財産、アカウントの帰属
仕様書には、成果物と権利の扱い、アカウントの管理主体を明記しておきます。
- 成果物：構成図と設定一覧、リポジトリ台帳、Pipeline定義、Infrastructure as Code（IaC）、テスト記録と手順書、教育資料。
- 権利：Forgeアプリ等の著作権、既存ライブラリ、OSS、汎用部品、改修・二次利用の範囲。
- 情報管理：再委託、アクセス記録、持ち出し禁止、事故連絡、削除証明。
Infrastructure as Code（IaC）があると、環境設定を再現しやすくなり、別の会社への保守の引き継ぎにも役立ちます。
成果物は発注者のAtlassian組織やクラウドアカウントの中に作成し、委託先には最小限の権限だけを与える方法もあります。
個人情報や機密情報を扱う場合は、契約終了後の利用権とデータ削除も定めておきます。権利とアカウントが曖昧なまま値引きを優先すると、委託先を変える時点で追加費用が発生します。
保守範囲・変更管理・終了条件
保守契約では、受付時間、回答と復旧の目標、障害の優先度を定めます。あわせて、対象作業、変更時の費用、終了時の処理も決めておきます。
- 保守範囲：Pipeline・連携アプリ、Atlassian仕様変更、脆弱性通知、ユーザー・権限変更。
- 変更管理：新しいリポジトリや環境の追加を見込んで、追加単価と月次作業時間、承認者、緊急対応費を決めます。
- 終了条件：管理者変更、トークン失効、文書・設定の返却、バックアップの扱い、委託先データの削除。
24時間対応が不要な会社であれば、高額な監視は必要ありません。ただし、本番デプロイを止めたときに、誰が何時までに判断するかは明確にしておきます。
Bitbucketのシステム発注費用の相場
費用は、Atlassianへのライセンス費・従量費と、開発会社への費用に分けて考えます。開発会社への費用は、導入支援、移行、連携のほか、教育や保守も含みます。
ライセンス費は、人数やプランで決まります。受託費は、移行の履歴や権限、CI/CD、セキュリティ要件などで変わります。
プラン・人数・追加利用量で変わるライセンス費用
プランは、ユーザー上限、料金、管理機能、追加利用量ごとに比べます。
- Free：5ユーザーまでの利用。
- Standard：LFSとPipelinesを含むプラン。
- Premium：マージチェック、IP許可リスト、デプロイ権限、必須の二段階認証などを備えたプラン。
2026年8月確認の案内では、6〜100ユーザーのStandardは1ユーザーあたり月額3.65米ドル、Premiumは7.25米ドルです。
10人なら、Standardは月36.50米ドル、Premiumは月72.50米ドルです（出典：Atlassian「Bitbucket Pricing」、2026年8月確認）。
実際の支払額は、請求通貨や税、契約期間によって変わります。為替や追加利用量によっても変わります。
追加ビルド時間やGit LFSが必要な場合もあります。さらに、パッケージ保存、セルフホストランナー、Atlassian Guardが必要になることもあります。
月間ビルド時間、LFS容量、同時実行数、SSOの要否を前提にして、試算を依頼します。
規模別の導入支援費の目安
この導入支援費は、類似の業務システムの人月単価と必要な作業量から算出した、編集上の推定です。公式の価格ではないため、初期予算の目安として使い、同じRFPをもとに見積もりを取ります。
- PoC・現状診断：利用者・リポジトリ・権限の棚卸しとCloud／Data Center比較で50万〜150万円程度、2〜4週間。
- Cloud標準導入：ワークスペースと権限、ブランチルール、Jira連携、基本Pipeline、手順書と教育を含み100万〜300万円程度、1〜2か月。
- 数十〜数百リポジトリの移行：SSO、権限再設計、秘密情報、テスト・ステージング・本番デプロイ、リハーサル込みで300万〜800万円程度、2〜4か月。
- Data Center・Hybrid等：複数拠点、高可用性、ネットワーク分離、独自アプリ連携込みで800万〜2,000万円以上、4〜9か月となることもあります。
これらは、要件の重さに応じた概算のレンジで、事例価格を断定するものではありません。各レンジに含まれる作業範囲は、見積書で照合します。
運用費の内訳と比較の観点
運用費は、日々の作業、基盤の維持、見積項目に分けて比べます。
- 運用作業：ユーザー追加・削除、権限棚卸し、Pipeline失敗調査、ランナー・依存ライブラリ更新。
- Data Center基盤：サーバーとデータベース、冗長化、監視、バックアップとアップグレード。
- 見積項目：初期構築とライセンス、クラウド基盤、保守、追加開発と緊急対応を、それぞれ分けて示します。
保守費を初期構築費の年15〜25％程度とする一般論もあります。ただし、Cloud本体と独自連携では、保守の内容が異なります。
運用では、監査ログの確認、脆弱性への対応、Atlassianや連携アプリの仕様変更にも備えます。
保守費は、率に加えて、月の対応時間、変更件数、障害対応の時間帯を確認したうえで比べます。
Bitbucketの委託先選定と見積比較の観点
委託先は、販売パートナーかどうかではなく、対応の中身で比べます。同じ質問を各社に投げ、製品実績、移行、CI/CDを比べます。さらに、セキュリティ、連携開発、教育、障害対応も比べます。
製品名ではなく案件内容で見る実績
「Bitbucketを扱えるか」だけでなく、案件の規模や移行元、連携設計、運用体制まで確かめます。
- 移行経験：チーム人数、リポジトリ数、移行元の環境。
- 設計経験：Pull RequestとJiraの連携、本番承認、ロールバック。
- 運用経験：導入後の担当者、匿名化構成図、納品物サンプル。
提案営業と設計・移行・保守の担当者が異なる場合は、技術判断をどう引き継ぐのかも確かめます。
再委託やオフショアがある場合は、担当範囲や日本語レビュー、アクセス情報を回答に含めてもらいます。
品質管理者と障害時の連絡経路も、同じ回答で示してもらいます。
同じRFPによるスコープと前提条件の統一
相見積もりでは、各社に同じ前提を渡し、必須作業と自由提案の範囲を分けて示します。
- 共通資料：RFPとリポジトリ台帳、ユーザー数、移行対象、テスト環境。
- 見積条件：「含む」「含まない」「前提」「追加時の単価」。
総額だけでなく、工程別の金額も比べます。要件定義と設計、構築と移行の金額を、それぞれ並べて見ます。さらに、テストと教育、保守の金額も、同じ並びで確かめます。
安い提案では、移行リハーサルや権限の再設定、失敗系テストが抜けていないかを確かめます。さらに、文書、コードの引き渡し、稼働後の問い合わせも含まれているかを見ます。
高い提案では、独自開発や監視が過剰になっていないかを確かめます。
見積書の工数・成果物・責任分界の照合
妥当性は、工数の大小よりも作業の中身で判断します。たとえば、リポジトリ数が少なくても、権限が複雑で、複数環境へのデプロイや監査、SSOが必要なら工数は増えます。
リポジトリ数が多くても、構成が標準化されていて段階移行を自動化できるなら、1件あたりの作業量は抑えられることがあります。
提案を比べるときは、工程別の条件と自社の評価配分をそろえておきます。
- 比較表：工程と担当、工数と期間、成果物、発注者作業、前提と除外、検収と保守開始日。
- 評価配分の例：価格40点、技術提案25点、移行・テスト15点、体制10点、引き継ぎ・保守10点。点数は自社リスクに合わせます。
よくある質問
Bitbucketの外注では、発注範囲、費用、移行、契約について疑問が生じます。発注前によく出る疑問を、次の見出しで答えます。
Bitbucketの導入だけを開発会社に依頼できますか？
依頼はできますが、アカウント発行やリポジトリ作成だけなら、委託の範囲は限られます。権限とブランチルール、Pipeline、Jira連携を委託に含めるか、運用や教育を自社で行うかを、RFPで明示します。
Bitbucket CloudとData Centerはどちらを外注すべきですか？
どちらが合うかは、インフラの保守とアップグレードを誰が受け持つか、データや運用の要件を自社でどこまで決めるかで変わります。
- Cloud：自社でインフラやアップグレードを管理する必要がなく、早く標準機能を使いたい場合に向いています。
- Data Center：データ管理、ネットワーク分離、既存基盤との接続、独自の運用要件が強い場合に向いています。
- Hybrid：既存環境を残しつつCloudも評価したい場合は、この構成も比較の対象に含めます。
- 比較の進め方：発注先に比較表とPoCを作ってもらう方法もあります。
Bitbucketの外注費用を抑えるにはどうすればよいですか？
目的と対象リポジトリ、ユーザー数、移行範囲、受入条件を先に整理し、標準機能で実現する範囲を広げます。
PoCで不確かな点を減らし、導入、移行、教育、保守を分けて、複数社から見積もりを取ります。金額だけでなく、除外事項と将来費用も比べます。
移行作業を開発会社に任せればデータはすべて移りますか？
すべてが自動で移るとは限りません。移行元の版やリポジトリサイズ、権限とグループ、ブランチ権限を事前に確かめます。Marketplaceアプリやプルリクエストの添付も、事前の確認が必要です。
移行後の再設定と照合も作業範囲に含めます。
契約前に法務やセキュリティ部門へ相談すべきですか？
相談すべきです。個人情報や営業秘密、委託先アクセス、再委託が関係するなら、RFPの段階から参加してもらいます。
SSO、ログ保存、知的財産、終了時のデータ返却が絡む場合も、同様に相談が必要です。
開発会社には、技術提案に加えて、責任分界と事故時の連絡フローも提出してもらいます。
まとめ
発注では、Bitbucketを開発基盤として定義したうえで、形態と委託範囲、RFPを一つの計画にまとめます。契約、費用、運用責任も、同じ計画に含めます。
レビューやテスト、デプロイ、権限を含めるかで、費用と必要な専門性が変わります。
移行と教育を含めるかでも、費用と必要な専門性は変わります。
最初に作る資料：リポジトリ・権限・リリースの一覧
まず、ユーザー数、リポジトリ数と容量、Git環境、ブランチを一覧にします。レビューの方法とデプロイ先も書き出します。さらに、管理者、移行対象、個人情報の有無も書き加えます。
次に、改善したい業務指標と守るべきセキュリティ条件を決めます。この資料があれば、各社から同じ前提で提案と見積もりを受け取りやすくなります。
発注先と相談する技術設定と運用定着
候補会社には、設定の経験に加えて、移行、CI/CD、SSOの経験を確かめます。さらに、監査とセキュリティ、教育と保守、契約終了時の引き継ぎも確認します。
標準機能を活用し、必要な部分だけを追加します。そのうえで、PoCで確かめ、工程別の見積もりと責任分界を合意してから発注します。
▼全体ガイドの記事
・Bitbucketのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。