Bitbucketのシステム開発の発注/外注/依頼/委託方法について

Bitbucketのシステム開発を発注・外注する際は、Bitbucketを業務アプリそのものではなく、Git管理・コードレビュー・CI/CD・Jira連携を統制する開発基盤として定義し、要件・契約・運用範囲まで一体で決めることが重要です。

「Bitbucketを導入したいが、どこまで自社で決め、どこから開発会社に依頼すればよいのか分からない」「CloudとData Centerの違い、費用相場、見積書の比較方法を知りたい」という方も多いのではないでしょうか。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用の考え方、委託先選定、発注後の進め方まで、Bitbucketのシステム開発を外注する際の実務を順番に解説します。

▼全体ガイドの記事
・Bitbucketのシステム開発の完全ガイド

Bitbucketのシステム発注・外注とは何ですか？

結論からいうと、Bitbucketのシステム発注とは、リポジトリを作る作業だけを依頼することではありません。開発チームの構成、リポジトリの分け方、ブランチとプルリクエストのルール、テストとデプロイの自動化、Jiraや認証基盤との連携、移行後の運用までを含む開発ライフサイクルの設計と構築を委託することです。

BitbucketはAtlassianが提供するGitリポジトリ管理サービスです。ソースコードを保管し、ブランチを分け、プルリクエストでレビューし、Bitbucket Pipelinesでビルド・テスト・デプロイを実行できます。Jiraの課題キーとコミットやプルリクエストを結び付ければ、要件や不具合がどの変更に反映されたかを追跡しやすくなります。

そのため、販売管理や顧客管理の画面・データをBitbucket上に置くわけではありません。実際のアプリケーションはクラウドや社内サーバーなどに構築し、Bitbucketは開発からリリースまでの変更を安全に流す経路として利用します。この切り分けをRFPの冒頭に書いておくと、単なるアカウント発行と、CI/CDを含む開発基盤構築の見積もりが混同されにくくなります。

Bitbucket Cloudは、Atlassianが基盤の保守やアップグレードを担うSaaSです。小規模から中規模のチームで、早く利用を始めたい場合に向いています。一方、Bitbucket Data Centerは自社が選んだインフラに配置し、ネットワーク分離、データ管理、可用性、アップグレード時期を自社の方針で管理する選択肢です。

既存のData Centerを残しながらCloudの機能も取り入れたい場合は、Hybridも候補になります。Atlassianの価格案内では、Cloudはセットアップや継続的なアップデートを任せられる一方、Data Centerは複雑な運用要件やCloudへすぐ移行できない組織向けと説明されています（出典: Atlassian「Bitbucket Pricing」、2026年8月確認）。発注先には製品名だけでなく、データ所在地、SSO、監査、バックアップ、障害対応を踏まえた選定理由を提示してもらいます。

Bitbucketの発注形態と委託範囲はどう選びますか？

発注形態は、完成させたいものがどの程度決まっているか、自社に管理者やDevOps担当者がいるか、発注後に要件が変わる可能性がどのくらいあるかで選びます。Bitbucketの設定作業だけを切り出すのか、移行やCI/CDまで一括するのか、運用を伴走してもらうのかを最初に分けることが、費用と責任の不一致を防ぎます。

「指定したリポジトリを移行し、ブランチ保護と標準Pipelineを設定し、受入テストに合格した状態で引き渡す」というように、成果物と完了条件を明確にできる場合は、請負型の発注が候補になります。初期導入、移行ツールの設定、Pipeline定義、設計書、運用手順書、教育資料などを成果物一覧に記載し、何をもって完了とするかを合意します。

ただし、請負型でもBitbucketの導入効果や開発文化の定着まで保証されるわけではありません。発注者側のレビュー責任者が不在であったり、既存リポジトリの棚卸しが終わっていなかったりすると、作業途中で前提が変わります。完成責任を求める範囲と、発注者が決める範囲を分離して、変更時の追加見積もりルールも設けます。

CloudとData Centerの比較、現行環境の調査、開発チームとの運用設計、段階的なPoCなど、作業を進めながら最適解を探す場合は、準委任型で専門家に伴走してもらう方法が現実的です。月単位またはスプリント単位で、アーキテクト、DevOpsエンジニア、プロジェクトマネージャーなどの役割を定め、稼働時間、会議体、成果報告の形式を契約します。

実務では、要件定義や移行計画を準委任型、設定・開発と受入試験を請負型、運用監視と改善を準委任型に分ける組み合わせが使いやすい場合があります。経済産業省のモデル契約書も、企画支援や要件定義作成支援は準委任型、外部設計やソフトウェア開発は要件の確定度に応じて準委任型または請負型とする構成を示しています（出典: 経済産業省「ソフトウェア開発委託基本モデル契約書」）。

Bitbucket導入で最初から独自ポータルや複雑なワークフローを作り込むと、アップデートや担当者交代のたびに保守負担が増えます。まずはリポジトリ、プルリクエスト、ブランチ権限、Pipelines、Jira連携などの標準機能で業務を組み立て、標準機能で解決できない承認、監査、社内ポータル、通知、台帳連携だけをForge、REST API、Webhookなどで補う方針がおすすめです。

開発会社に依頼する際は、「カスタマイズできるか」だけでなく、「将来の標準機能で置き換えられるか」「ソースコード、IaC、設定値を引き渡せるか」「Atlassianの仕様変更時に誰が修正するか」まで確認します。独自開発を小さく保つことが、委託先を変更しやすくし、長期的な総保有コストを抑えます。

RFPと要件整理はどのように進めますか？

RFPは、製品の機能一覧を並べる資料ではなく、自社の開発・リリース上の課題と、外注で実現したい状態を伝える資料です。候補会社が同じ前提で提案できるように、現状、目的、対象範囲、非機能要件、移行条件、成果物、予算の考え方、提案依頼事項を一つの資料にまとめます。

最初に、開発者数、管理者数、リポジトリ数、リポジトリごとの容量、利用中のGitサービス、ブランチ数、プルリクエストの月間件数、デプロイ先、リリース頻度を整理します。たとえば「レビューが属人化している」「本番反映の承認者が追えない」「Jiraの課題と変更履歴が結び付かない」といった課題を、発生頻度や確認にかかる時間とともに書くと、導入効果を評価しやすくなります。

目的は「Bitbucketを導入する」ではなく、「mainブランチへの直接反映をなくす」「リリース前のテスト結果を必ず記録する」「退職者の権限を当日中に無効化する」のように表現します。開発速度だけをKPIにするとレビューを省略する方向へ流れるため、リードタイム、変更失敗率、復旧時間、レビュー実施率など、品質と安全性を合わせて設定します。

機能要件には、ワークスペースとプロジェクトの構成、リポジトリ命名規則、プルリクエストのレビュアー、mainやreleaseブランチの保護、Jira・Confluence連携、Pipelineのテストとデプロイ、WebhookやAPI連携を記載します。誰が何を操作できるかを、管理者、開発者、レビュー担当者、運用担当者、外部委託先などのロール別に整理すると、権限設計の抜けを減らせます。

非機能要件には、可用性、障害時の復旧時間、監査ログ、バックアップ、秘密情報の保管、IP制限、SSO、個人情報の取扱い、データ所在地、サポート時間を含めます。Cloudを選ぶ場合でも、SaaS側の責任に任せる部分と、自社がアカウント・権限・設定・削除操作を管理する部分を分けて記載します。Atlassianの説明でも、Cloudのバックアップは災害復旧用で、利用者が削除したリポジトリの復元にそのまま使えるものではないとされています（出典: Atlassian Support「Differences administering Bitbucket Data Center and Cloud」、2026年8月確認）。

既存のBitbucket Server・Data Center、GitHub、GitLab、Perforceなどから移行する場合は、リポジトリだけでなく、ブランチ、タグ、コミット履歴、プルリクエスト、コメント、課題連携、Webhook、権限、アプリ設定を対象にします。移行前後でハッシュ値、リポジトリ数、主要ブランチ、タグ数、代表的なプルリクエストを照合する方法までRFPに書いておきます。

Bitbucket Cloud Migration Assistantは、Data CenterからCloudへの移行で推奨される無償ツールですが、公式情報ではプロジェクト設定や権限、ブランチ権限、Marketplaceアプリ、プルリクエスト添付などが自動移行されない制限が案内されています（出典: Atlassian Support「Cloud migration methods for Bitbucket」、2026年8月確認）。したがって、RFPでは「ツールを実行すること」ではなく、「移行後に権限とレビュー運用を再現し、受入テストに合格すること」を完了条件にします。

発注後はどのような流れで進めますか？

発注後は、要件定義、PoC・設計、構築・移行、テスト・教育、運用引き継ぎの順に進めます。全リポジトリを一度に移行するより、代表的なチームや重要度の低いリポジトリで検証し、問題を解消してから段階的に広げる方が、開発を止めるリスクを抑えられます。

PoCでは、代表リポジトリを一つから三つ程度選び、clone、ブランチ作成、プルリクエスト、レビュー、テスト、ステージングデプロイ、失敗時の再実行とロールバックを実際に動かします。成功したケースだけでなく、権限のない利用者がmainへ反映しようとした場合、テストが失敗した場合、外部APIが停止した場合、秘密情報を誤登録した場合も確認します。

基本設計では、プロジェクトとリポジトリの階層、ブランチモデル、レビューの人数、マージ条件、環境ごとの承認者、変数と秘密情報の管理、通知先、監査ログの確認方法を決めます。Bitbucketの標準設定を変更した理由を設計書に残すと、運用担当者が設定の意味を理解しやすくなります。

設計が固まったら、ワークスペース、ユーザー、グループ、リポジトリ、ブランチ権限、Jira連携、Pipelines、デプロイ環境を構築します。移行対象が多い場合は、開発チーム単位やプロジェクト単位で順番を決め、移行前の凍結時間、DNSやWebhookの切り替え、旧環境を読み取り専用にする期間を計画します。

テストでは、画面を操作できるかだけでは不十分です。適切な利用者だけがコードを閲覧・push・mergeできるか、レビューとPipeline成功を必須にできるか、本番デプロイを承認者だけが実行できるか、ログから変更者と時刻を追えるかを確認します。Atlassian Supportでは、CloudのPremiumでマージチェックを強制でき、特定環境のデプロイ権限も設定できると説明されています（出典: Atlassian Support「Use branch permissions」「Set custom deployment permissions for your environments」、2026年8月確認）。

導入が終わっても、開発者が古いブランチ運用を続けたり、管理者だけが設定を理解していたりすると、Bitbucketは単なるファイル置き場になります。管理者向けにはユーザー・グループ・権限・課金・監査の手順を、開発者向けにはブランチ、レビュー、Pipeline、障害時の再実行を、運用担当者向けにはデプロイ承認、アカウント停止、バックアップ確認を分けて教育します。

引き継ぎ成果物には、構成図、設定一覧、リポジトリ台帳、ロール一覧、Pipeline定義、秘密情報の登録手順、監視・通知の設定、障害対応手順、月次点検表を含めます。発注先への問い合わせ方法と、Atlassianのサポートへ問い合わせる条件も決めておくと、障害時に担当者を探す時間を減らせます。

Bitbucketの外注で契約形態と契約書に何を記載しますか？

Bitbucketの外注契約では、製品ライセンスの購入契約と、導入・移行・開発・保守の業務委託契約を分けて考えます。ライセンス費を含む見積もりでも、誰が契約主体となり、誰が管理者となり、解約時にデータや設定をどう返却するのかを確認します。以下は一般的な整理であり、最終的な契約書は自社の法務担当者や弁護士に確認します。

請負契約は、合意した成果物を完成させて引き渡す業務に向いています。対象リポジトリ、設定、Pipeline、移行結果、ドキュメント、受入基準を具体化できるほど、完成責任と検収条件を明確にできます。準委任契約は、専門家の調査・助言・設計支援・運用支援など、作業の提供そのものに価値があり、状況に応じて内容を調整する業務に向いています。

一つの契約形態ですべてを処理しようとせず、要件整理は準委任、確定した設定構築は請負、運用改善は準委任という分け方も検討します。IPAの情報システム・モデル取引・契約書は、請負と準委任の報酬請求、契約不適合責任、中途解除、セキュリティ、プロジェクトマネジメント義務などを論点として整理しています（出典: IPA「情報システム・モデル取引・契約書（第二版）」）。

契約書や仕様書には、構成図、設定値一覧、リポジトリ台帳、Pipelineの定義ファイル、Infrastructure as Code、テスト記録、操作手順書、教育資料を成果物として明記します。ソースコードだけでなく、ビルドやデプロイを再現する設定がなければ、別の会社へ保守を引き継げません。発注者のAtlassian組織やクラウドアカウント内に作成し、委託先には必要最小限の権限を付与する運用も検討します。

開発したForgeアプリや連携サービスの著作権、既存ライブラリ、OSS、汎用部品の利用条件、改修・二次利用の範囲、契約終了後の利用権を整理します。個人情報や機密情報を含むリポジトリを扱う場合は、再委託の可否、アクセス記録、持ち出し禁止、事故時の連絡、削除証明も契約条件に入れます。権利とアカウントを曖昧にしたまま値引きを優先すると、将来のベンダー変更で大きな追加費用が発生します。

保守契約では、問い合わせ受付時間、一次回答と復旧の目標、障害の優先度、Pipelineや連携アプリの不具合対応、Atlassianの仕様変更への追随、脆弱性情報の通知、ユーザー追加や権限変更の上限を定めます。24時間対応が不要な会社に高額な監視を付ける必要はありませんが、本番デプロイが止まった場合に誰が何時までに判断するかは明確にします。

運用開始後に新しいリポジトリや環境が増える可能性があるため、追加作業の単価、月次の作業時間、変更要求の承認者、緊急対応費を確認します。契約終了時には、アカウントの管理者変更、アクセストークンの失効、ドキュメントと設定の返却、バックアップの扱い、委託先が保持するデータの削除を実施する終了チェックを設けます。

Bitbucketのシステム発注費用・相場はいくらですか？

Bitbucketの費用は、Atlassianへ支払うライセンス・従量費と、開発会社へ支払う導入支援・移行・連携・教育・保守費に分けて考えます。ライセンスの公式価格は利用者数やプランで変動し、受託費はリポジトリ数、移行履歴、権限の複雑さ、CI/CDの対象環境、セキュリティ要件で変わるため、特定の金額を一律に断定しないことが大切です。

AtlassianのBitbucket Cloud価格案内では、Freeは5ユーザーまでで、StandardとPremiumはユーザー数に応じた月額料金です。2026年8月に確認した案内では、Standardは6〜100ユーザーで1ユーザー月額3.65米ドル、Premiumは同じ人数帯で1ユーザー月額7.25米ドルとされています。10人で単純計算すると、Standardは月36.50米ドル、Premiumは月72.50米ドルですが、請求通貨、税、契約期間、為替、追加利用量によって実際の支払額は変わります（出典: Atlassian「Bitbucket Pricing」、2026年8月確認）。

StandardにはLFSやPipelinesが含まれますが、Premiumにはマージチェック、IP許可リスト、デプロイ権限、必須の二段階認証など、より細かな管理・監査機能が追加されます。追加ビルド時間、Git LFS、パッケージ保存、セルフホストランナー、Atlassian Guardなどが必要になる場合もあるため、候補会社には「月間ビルド時間」「LFS容量」「同時実行数」「SSOの要否」を前提にしたライセンス試算を依頼します。

導入支援費の目安は、リサーチノートに整理した類似業務システムの人月単価と、Bitbucket導入に必要な作業量から算出した編集上の推定です。公式の一律価格ではないため、予算検討の初期レンジとして利用し、最終的には同じRFPで見積もりを取得します。

利用者・リポジトリ・権限の棚卸しとCloud／Data Center比較を行うPoC・現状診断は、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の失敗調査、ランナーや依存ライブラリの更新、監査ログ確認、脆弱性対応、Atlassianや連携アプリの仕様変更への対応が発生します。Data Centerでは、サーバー、データベース、冗長化、監視、バックアップ、アップグレードの費用も必要です。

見積書では、初期構築費、ライセンス費、クラウド基盤費、保守費、追加開発費、緊急対応費を分けてもらいます。保守費を初期構築費の年15〜25％程度と置く一般論もありますが、Bitbucket Cloudの保守と独自連携の保守では内容が異なります。率だけで比較せず、月何時間の対応、何件の変更、どの時間帯の障害対応が含まれるかを確認します。

Bitbucketの委託先選定と見積比較のポイントは何ですか？

委託先は、Atlassianの販売パートナーであることだけで決めません。Bitbucket CloudまたはData Centerの実績、Git環境の移行経験、Pipelineと本番デプロイの設計力、SSO・監査・秘密情報の扱い、ForgeやREST APIの開発力、運用教育、障害時の体制を、同じ質問で比較します。

実績を尋ねるときは、「Bitbucketを扱えますか」だけで終わらせません。「何人規模のチームで、何リポジトリを、どの環境から移行したか」「Pull RequestとJiraをどのように結び付けたか」「本番デプロイの承認とロールバックをどう設計したか」「導入後に誰が運用しているか」を聞きます。可能であれば、公開事例だけでなく、匿名化された構成図や納品物のサンプルを確認します。

担当者の経験も重要です。提案時の営業担当者と、実際に設計・移行・保守を担当するエンジニアが異なる場合、プロジェクト開始後に技術判断が引き継がれる仕組みを確認します。再委託やオフショアがある場合は、担当範囲、日本語でのレビュー、アクセス可能な情報、品質管理者、障害時の連絡経路をRFPへの回答に含めてもらいます。

相見積もりでは、候補会社に同じRFP、同じリポジトリ台帳、同じユーザー数、同じ移行対象、同じテスト環境を渡します。各社に自由提案を求める部分と、必ず含めてほしい作業を分け、見積書には「含む」「含まない」「前提」「追加時の単価」を書いてもらいます。

比較するときは総額だけでなく、要件定義、設計、構築、移行、テスト、教育、保守の工程別金額を並べます。特に安い提案では、移行リハーサル、権限の再設定、失敗系テスト、ドキュメント、ソースコードの引き渡し、稼働後の問い合わせが抜けていないか確認します。高い提案でも、不要な独自開発や過剰な監視が含まれていないかを確認します。

見積書の工数が多いか少ないかだけでは、妥当性を判断できません。リポジトリが少なくても、権限ロールが複雑で、複数のクラウド環境へデプロイし、監査要件やSSOを満たす必要があれば工数は増えます。逆にリポジトリ数が多くても、構成が標準化され、段階移行の自動化ができれば、1件あたりの作業量を抑えられる場合があります。

比較表には、工程、担当ロール、工数、期間、成果物、発注者作業、前提条件、除外事項、検収条件、保守開始日を並べます。評価は価格40点、技術提案25点、移行とテスト15点、体制10点、引き継ぎと保守10点のように、事前に重みを決めておくと、営業資料の印象だけで選びにくくなります。点数の配分は自社のリスクに合わせて設定します。

よくある質問

Bitbucketのシステム開発を外注するときは、ライセンスの疑問だけでなく、発注範囲、費用、移行、契約の不安も生じます。ここでは、発注前によく寄せられる質問に直接回答します。

依頼できますが、アカウント発行やリポジトリ作成だけなら、開発会社に頼む範囲は限定されます。将来の手戻りを防ぐには、権限設計、ブランチルール、Pipeline、Jira連携、運用手順、教育までを含めるか、自社で実施するかをRFPで明示します。

自社でインフラやアップグレードを管理する必要がなく、早く標準機能を使いたい場合はCloudが候補です。データ管理、ネットワーク分離、既存基盤との接続、独自の運用要件が強い場合はData Center、既存環境を残しながらCloud機能も評価したい場合はHybridを含め、発注先に比較表とPoCを作ってもらいます。

最初に目的、対象リポジトリ、ユーザー数、移行範囲、受入条件を整理し、標準機能で実現する範囲を増やすことが基本です。PoCで不確実な点を減らし、導入・移行・教育・保守を分けた見積もりを複数社から取り、安い金額ではなく除外事項と将来の追加費用まで比較します。

すべてが自動で移るとは限りません。Bitbucket Cloud Migration Assistantを使う場合でも、移行元のバージョン、リポジトリサイズ、権限・グループ、ブランチ権限、Marketplaceアプリ、プルリクエストの添付などを事前に確認し、移行後の再設定と照合を作業範囲に含めます。

相談すべきです。特に個人情報や営業秘密を含むリポジトリ、外部委託先のアクセス、再委託、SSO、ログ保存、知的財産、契約終了時のデータ返却が関係する場合は、RFP段階から法務・セキュリティ部門を参加させます。開発会社には技術提案だけでなく、責任分界と事故時の連絡フローも提出してもらいます。

まとめ

Bitbucketのシステム開発を発注・外注するときは、Bitbucketを中心とした開発基盤の範囲を定義し、Cloud・Data Center・Hybridの選択、発注形態、RFP、契約、費用、運用責任を一つの計画として整理します。特に、リポジトリ作成だけでなく、レビュー、テスト、デプロイ、権限、移行、教育を含めるかどうかで、必要な費用と委託先の専門性は大きく変わります。

最初の一歩は、ユーザー数、リポジトリ数と容量、現在のGit環境、ブランチ、レビュー、デプロイ先、管理者、移行対象、個人情報の有無を一覧にすることです。そのうえで、Bitbucket導入によって改善したい業務指標と、必ず守るセキュリティ条件を決めます。この資料があれば、開発会社から同じ前提の提案と見積もりを受け取りやすくなります。

候補会社を選ぶときは、Bitbucketの設定経験だけでなく、移行、CI/CD、SSO、監査、セキュリティ、教育、保守、契約終了時の引き継ぎまで確認します。標準機能を活用しながら自社に必要な部分だけを追加し、PoCで確かめ、工程別の見積もりと責任分界を合意してから本発注へ進むことが、失敗しにくい進め方です。

▼全体ガイドの記事
・Bitbucketのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。