Bitbucketのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Bitbucketのシステム開発は、Bitbucket上に業務アプリを置くことではなく、Gitリポジトリ、コードレビュー、CI/CD、課題管理、認証、監査をつないだ開発・運用基盤を設計することです。

「何から決めればよいのか」「CloudとData Centerのどちらが自社向きなのか」「導入や移行にいくらかかるのか」と迷う担当者に向けて、要件整理から定着までの進め方を6フェーズで解説します。実務で使える確認項目、費用の考え方、見積書の読み方、失敗を防ぐ判断基準までまとめています。

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

Bitbucketのシステム開発の全体像

Bitbucketのシステムは、リポジトリを置き換えるだけの導入ではありません。開発者が変更をブランチに分け、プルリクエストでレビューし、テストに合格した変更だけを環境へ反映する一連の流れを、会社のルールとして再現できるようにする取り組みです。

「Bitbucketのシステム」とは、Bitbucketを中心に開発工程を管理する仕組みを指します。業務データを登録する販売管理システムや基幹業務アプリそのものは、AWS、Azure、社内サーバーなど別の実行基盤で動きます。Bitbucketは、そのアプリケーションのソースコードや設定ファイルを管理し、変更を安全に検証して各環境へ届ける役割を担います。

代表的な構成は、BitbucketのGitリポジトリ、Jiraの課題管理、Confluenceの設計・運用ナレッジ、Bitbucket Pipelinesのビルド・テスト・デプロイです。WebhookやREST API、Forgeアプリを使えば、社内ポータルや承認ワークフロー、監査ダッシュボードとも連携できます。ここを最初に整理しておくと、「Bitbucketに業務システムを開発する」という誤解を防ぎ、必要な予算と担当範囲を正しく切り分けられます。

小規模から中規模のチームで、SaaSを利用できるセキュリティ条件ならBitbucket Cloudが第一候補です。インフラの構築やアップグレードを自社で抱えずに始められ、チームの増減にも対応しやすいからです。一方、データの保管場所、ネットワーク分離、社内認証、独自の監査基準、高い可用性を細かく管理する必要がある場合はBitbucket Data Centerを検討します。

既存の自己管理環境をすぐには手放せないものの、クラウドの運用負荷低減も取り込みたい場合はHybridが候補です。ただし、二つの環境で権限、バックアップ、監視、移行方針を持つため、単純に両方を使うより管理コストが増えます。判断時は「どちらが高機能か」ではなく、データ分類、利用者数、リポジトリ数、ネットワーク制約、運用担当者の人数を並べて決めることが重要です。

Bitbucketのシステム開発の進め方

Bitbucket導入は、製品を契約した時点では完了しません。要件整理、選定、設計・開発、テスト、稼働、定着の順で、ツールの設定と開発現場の運用ルールを同時に作ります。特に、リポジトリの移行だけを先に進めると、旧環境の曖昧な権限やレビュー慣行まで引き継ぐため、最初の要件整理に時間をかけることが結果的な短縮につながります。

最初に、開発者、レビュー担当者、プロダクトオーナー、情シス、セキュリティ担当者の役割を確認します。次に、利用者数、チーム数、リポジトリ数、容量、利用中のGitサービス、JiraやConfluenceの有無、デプロイ先、リリース頻度、ソースコードに含まれる機密情報を棚卸しします。現在のmainへの直push、レビューの有無、テストを通さず本番へ出せる経路なども、画面設定だけでは把握できないため、実際の運用を聞き取ることが必要です。

要件の確認項目は、機能要件と非機能要件に分けます。機能要件ではリポジトリ作成、ブランチ、プルリクエスト、レビュー、Pipelines、Jira連携、成果物保存を確認します。非機能要件では認証方式、権限分離、監査ログ、バックアップ、復旧目標、データ所在地、可用性、脆弱性対応、退職者のアカウント停止を定義します。要件整理の成果物は、構成図、利用者・権限一覧、リポジトリ棚卸し表、現状と目標の差分、優先順位、PoCの合格条件です。

2026年のJUAS「企業IT動向調査」では、システム開発の品質が予定どおりにならない要因として、計画時の考慮不足や仕様変更、現行業務・システムの複雑さなどが示されています。Bitbucketの設定作業でも同じ傾向があるため、最初から全機能を盛り込まず、まずは守るべき開発ルールと対象チームを定めることが安全です（出典：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2026」）。

選定では、Cloud、Data Center、Hybridの比較に加えて、Free、Standard、Premiumのどこまで必要かを検討します。小規模な検証だけならFreeでも試せますが、本番でレビューの必須化、IPアドレス制限、デプロイ権限、組織の認証統制が必要なら、上位プランやAtlassian Guardなど周辺サービスの確認が必要です。無料枠の有無だけで決めると、監査や承認の要件を満たすために後から再設計することになります。

既存環境から移行する場合は、移行ツールが何を運べるかを先に確認します。Bitbucket Cloud Migration Assistantは移行を支援しますが、ユーザーやグループ、プロジェクト設定、ブランチ権限、プルリクエストの添付、Marketplaceアプリなどが同じ条件で移るとは限りません。移行対象と再設定対象を分け、移行前後でコミットハッシュ、ブランチ、タグ、権限、レビュー履歴を照合する計画を作ります（出典：Atlassian「What gets migrated with Bitbucket Cloud Migration Assistant」）。

選定のチェックでは、候補を機能表だけで比較しないことが大切です。代表リポジトリを1〜3個選び、既存の開発者がcloneできるか、プルリクエストを作れるか、テスト失敗時にマージを止められるか、ステージングへ配布できるか、失敗時にロールバックできるかを実機で試します。PoCの合格条件を事前に合意し、成功系だけでなく権限不足、秘密情報の誤登録、外部サービス停止、同時実行数超過も検証します。

設計では、プロジェクトとリポジトリの階層、命名規則、所有者、公開範囲、ブランチ戦略を決めます。たとえば、feature、release、mainの役割を定義し、mainへの直pushを禁止してプルリクエスト経由だけにします。レビュー担当者を最低何人にするか、作業者自身の承認を認めるか、テスト成功をマージ条件にするか、緊急修正の例外を誰が承認するかまで、画面設定と運用手順の両方に落とし込みます。

Bitbucket Pipelinesでは、bitbucket-pipelines.ymlをリポジトリで管理し、プルリクエスト時の静的解析・単体テスト、マージ後の結合テスト、ステージング配布、本番承認後のデプロイという流れを構成します。AWS、Azure、GCP、社内ネットワーク内のサーバーなど接続先に応じてホスト型ランナーとセルフホストランナーを使い分けます。秘密情報はソースコードに書かず、リポジトリや環境の変数、外部のシークレット管理サービスで管理し、ログにトークンが出ないことも確認します。

本番環境には、誰でも実行できる便利さより、誤配布を防ぐ仕組みを優先します。Bitbucket Cloudでは、環境ごとにデプロイできる利用者やグループを制限できます。開発環境はチーム全員、ステージングはリリース担当、本番は責任者と運用担当だけというように、環境ごとに権限を分けます（出典：Atlassian「Set custom deployment permissions for your environments」）。

テストは、画面が表示されるかだけを見る工程ではありません。開発者が権限どおりに操作できるか、レビューなしでmainへ入れないか、テスト失敗時にマージとデプロイが停止するか、監査ログを追跡できるか、秘密情報がログに露出しないかを確かめます。さらに、Pipelinesの実行時間や同時実行数が想定を超えた場合、失敗したステップを再実行した場合、デプロイ先が一時停止した場合の挙動も確認します。

移行を伴う場合は、低リスクのリポジトリで予行演習を行い、移行時間と停止時間を測ります。移行前には対象リポジトリ、ブランチ、タグ、Git LFS、サブモジュール、Webhook、デプロイキー、環境変数、ユーザー・グループの一覧を確定します。移行後は開発者のclone、過去コミットの参照、ブランチ保護、プルリクエスト、Jiraの課題キー、Pipelines、成果物取得を実際の利用者で確認します。検証結果を記録し、やり直し条件を決めておくと本番移行時の判断が速くなります。

受入テストでは、担当者の「使えそう」という感想だけで合格にしないことが重要です。受入条件を「対象リポジトリの100％で権限表と実設定が一致する」「mainへの直接変更が拒否される」「本番デプロイは許可グループだけが実行できる」「障害時に30分以内に切り戻し手順を開始できる」など、確認可能な形で記述します。復旧時間やデータ損失の許容範囲は会社の要件で異なるため、数値は担当部署と合意してから設定します。

稼働前には、移行責任者、技術責任者、業務側の承認者、連絡先、判断期限を決めた切り替え計画を作ります。変更凍結の期間、最終バックアップ、移行開始と完了の時刻、旧環境を読み取り専用にするタイミング、DNSや接続先の切り替え、問題時のロールバック条件を一枚にまとめます。重要な開発チームから一斉に切り替えるのではなく、影響の小さいチームで先行稼働し、問題がなければ対象を広げる方法が安全です。

稼働当日は、設定を変更できる人を限定し、作業ログを残します。新しいリポジトリへのpush、プルリクエスト、レビュー、テスト、ステージングデプロイ、本番承認、ロールバックを順に実施し、手順書の記載と実際の画面が一致するかを確認します。移行直後は旧環境をすぐ削除せず、参照専用やバックアップとして一定期間保持し、保持期間と廃棄責任者を決めてから終了します。

稼働後の初期監視では、Pipelinesの失敗率、平均実行時間、レビュー滞留時間、デプロイ回数、ロールバック回数、権限エラー、問い合わせ件数を見ます。導入前の値が取れない場合は、最初の2〜4週間をベースライン期間として記録します。数字を取る目的は開発者を監視することではなく、設定が業務を妨げているのか、レビューやテストが品質向上に役立っているのかを判断することです。

定着化では、ツールの操作研修と開発ルールの研修を分けます。操作研修ではclone、ブランチ作成、プルリクエスト、レビュー、Pipelinesの確認を扱い、ルール研修ではコミットの粒度、レビューの観点、緊急リリース、脆弱性発見時の連絡、障害時の切り戻しを扱います。管理者にはユーザー追加、グループ権限、監査ログ、ランナー、請求、バックアップの教育を行い、開発者だけに運用を集中させない体制を作ります。

月次または四半期ごとに、不要アカウント、過剰な権限、休眠リポジトリ、古いアクセストークン、Pipelinesの失敗、秘密情報の検知、ブランチ保護の例外を点検します。新しいチームや外部委託先を追加する際は、既存の権限をコピーするだけでなく、契約終了時のアカウント停止、リポジトリの所有権、ソースコードの返却・削除、再委託先の管理を確認します。NISTのSecure Software Development Frameworkも、組織の開発プロセスに安全な開発プラクティスを組み込む参照枠として活用できます。

運用開始後にルール違反が続く場合は、現場の意識だけを責めず、設定や手順が現実に合っているかを見直します。レビューに時間がかかり過ぎるなら担当者の割り当てを調整し、テストが不安定なら失敗原因を直してから必須化します。変更を禁止することが目的ではなく、速く安全に変更できる経路をチームが自然に選べる状態を作ることが、Bitbucketのシステム開発のゴールです。

Bitbucketのシステム開発にかかる費用相場と内訳

費用は、Bitbucketのライセンス料金、Atlassianの周辺サービス料金、導入・移行・CI/CD構築の支援費、教育費、稼働後の保守・運用費に分けて考えます。公式のユーザー料金と、開発会社へ依頼する作業費は性質が違うため、一つの「Bitbucket導入費」として比較しないことが重要です。以下の金額は2026年8月時点の公開情報とリサーチノートをもとにした目安で、実際の見積もりを保証するものではありません。

Bitbucket CloudはFree、Standard、Premiumなどのプランで提供され、ユーザー数とプラン、追加のビルド時間やストレージなどで料金が変わります。Atlassian公式料金ページでは、Standardは6〜100ユーザーで1ユーザー月額3.65米ドル、Premiumは同じ人数帯で1ユーザー月額7.25米ドルと案内されています。10人で単純計算すると、基本料金はそれぞれ月36.50米ドル、月72.50米ドルです（出典：Atlassian「Bitbucket Pricing」2026年8月確認）。

日本円は為替で変わるため、仮に1米ドル=150円と置く場合、10人のStandardは月約5,500円、Premiumは月約10,900円という概算になります。ただし、実際には契約形態、税、ユーザーの定義、他のAtlassian製品、追加ビルド時間、Git LFS、セルフホストランナー、Atlassian Guardの有無で変動します。円換算を見積書に記載する場合は、換算日と為替前提を必ず併記します。

小規模なPoCや現状診断は50万〜150万円程度、期間は2〜4週間が一つの目安です。ユーザーとリポジトリの棚卸し、CloudとData Centerの比較、代表リポジトリでのプルリクエストとPipelines検証、運用課題の整理までを含む想定です。実際の作業範囲が狭い場合は下がり、複数の認証基盤やネットワーク接続を検証する場合は上がります。

Cloudの標準導入は100万〜300万円程度、期間は1〜2か月が目安です。ワークスペースやプロジェクトの初期設定、権限、ブランチ保護、Jira連携、基本的なPipeline、運用手順、管理者・開発者教育を含める場合のレンジです。既存Git環境からの移行とCI/CD整備は300万〜800万円程度、2〜4か月が一つの目安です。数十〜数百リポジトリ、SSO、秘密情報の再配置、複数環境へのデプロイ、段階移行を含むと工数が増えます。

複数拠点、高可用性、ネットワーク分離、監査、Data CenterやHybrid、独自のForge・API開発を含む案件は、800万〜2,000万円以上、4〜9か月のレンジになることがあります。これはBitbucketの定価ではなく、要件定義、設計、実装、移行、テスト、教育、プロジェクト管理を含む導入支援費の推定です。JUAS「企業IT動向調査2026」でも、人材確保の難しさや価格高騰がシステム開発のQCDに影響しているとされているため、過去案件の単価だけで現在の予算を断定しないことが安全です。

Cloudではライセンス、追加のビルド時間やストレージ、ランナー、認証・監査の周辺サービスが中心です。Data Centerでは、ライセンスに加えてサーバーやクラウド基盤、冗長化、バックアップ、監視、パッチ適用、アップグレード、障害対応を自社または委託先が担います。導入費が安く見える構成でも、管理者を確保できなければ運用費が膨らむため、月次の作業時間を人件費として見積もります。

保守費を初期構築費の年15〜25％程度と置く一般論もありますが、これは固定ルールではありません。問い合わせ対応だけか、24時間監視まで含むか、脆弱性対応やPipelineの改修を含むか、利用者追加やリポジトリ整理を含むかで変わります。見積書では、毎月の定常作業、障害時の対応時間、追加作業の単価、契約終了時の引き継ぎを分けて確認します。

Bitbucketのシステム開発で見積もりを取るポイント

Bitbucketの見積もりは、ユーザー数だけでは比較できません。リポジトリ数、移行元、権限の複雑さ、接続する環境、Pipelineの本数、テスト自動化、認証、監査、教育、運用保守を同じ前提で提示して、初めて各社の差が見えます。依頼前に対象範囲を整理し、成果物と検収条件まで含めたRFPにすると、安いが抜け漏れの多い提案を見分けやすくなります。

見積書では、現状調査、要件定義、設計、設定・開発、移行、テスト、稼働支援、教育、保守を工程ごとに分けてもらいます。各工程には、構成図、権限一覧、命名規則、ブランチ運用規約、Pipeline定義、テスト計画、移行計画、切り替え手順、障害対応手順、教育資料など、納品物を明記します。作業一式とだけ書かれている場合は、何が含まれ、何が別途になるのかを質問します。

特に抜けやすいのは、移行リハーサル、移行後の照合、権限の再設定、Marketplaceアプリの代替、外部委託先のアカウント管理、秘密情報の入れ替え、ロールバック、利用者教育です。これらが別途扱いなら、別途費用と必要な判断期限を記載してもらいます。成果物の著作権、ソースコード、Pipeline定義、Infrastructure as Code、管理者アカウントの引き渡し条件も、契約前に確認しておくとベンダーロックインを抑えられます。

同じ「100リポジトリの移行」でも、移行元がBitbucket ServerなのかGitHubなのか、過去のレビュー履歴を残すのか、Git LFSやサブモジュールを使うのかで工数は変わります。同じように「CI/CD構築」でも、テストを1種類だけ実行するのか、複数のクラウドへ承認付きでデプロイするのか、社内ネットワークへセルフホストランナーで接続するのかで難易度が異なります。

そのため、見積もり依頼では、リポジトリ数を重要度別に分類し、開発言語、ビルド時間、テスト数、環境数、デプロイ頻度、利用者数、認証方式、運用時間帯、必要な復旧水準を添えます。作業量は「人日」や「人月」で示してもらい、管理者、PM、インフラ担当、CI/CD担当、移行担当、教育担当の役割を分けます。デジタル庁の標準ガイドラインでも、工数と単価の掛け算を基本に費用を積算し、20人日を1人月とする考え方が示されています。

候補企業には、Bitbucket CloudとData Centerの経験、GitHub・GitLab・Perforceからの移行実績、Pipelinesと本番デプロイの設計経験、ForgeやREST APIの開発力、SSO・監査・秘密情報管理の知識を質問します。Atlassianのパートナーランクだけでなく、今回の規模に近い担当者の実績、設計者と運用担当者の所属、再委託の有無、障害時の連絡時間、契約終了時の引き継ぎを確認します。

提案書には、前提条件、顧客側の作業、外部サービスの契約、ネットワーク開通、アカウント準備、データクレンジング、テストデータ、承認者の参加時期を記載してもらいます。納期だけが固定され、顧客側の意思決定やレビュー工数が書かれていない場合は、後から追加費用や延期が生じやすい状態です。仕様変更の手続き、受入基準、瑕疵対応、運用保守の範囲を契約書と見積書で一致させます。

社内に残すスキルも決めます。日々のユーザー追加や権限変更まで外注するのか、Pipelineの修正や障害一次対応は内製するのか、設計書と設定を自社で更新できるようにするのかを選びます。外部委託を増やすだけでは、運用知識が社内に蓄積されません。JUASの2026年調査でも、内製化の課題として開発・プロジェクトマネジメント人材の不足が示されているため、教育と引き継ぎを見積もりに含めることが現実的です。

Bitbucketのシステム開発に関するよくある質問

Bitbucketを導入するときに多く寄せられる質問を、費用、移行、運用の観点から回答します。自社の規模やセキュリティ要件によって正解は変わるため、回答をそのまま採用するのではなく、要件整理の確認項目として利用してください。

インフラを自社で運用する必要がなく、SaaS利用とクラウド保管が社内規程に合うならBitbucket Cloudが選びやすいです。データ所在地、ネットワーク分離、独自の可用性設計、自己管理が必須ならData Centerを検討します。判断に迷う場合は、利用者数や料金だけでなく、セキュリティ審査、バックアップ、障害対応、アップグレードを誰が担うかを比較し、代表リポジトリでPoCを行うと決めやすくなります。

移行できますが、リポジトリのコピーだけで完了するとは限りません。コミット、ブランチ、タグ、LFS、サブモジュール、レビュー履歴、Webhook、デプロイキー、権限、課題管理との連携を分けて確認し、移行ツールで扱えないものは再設定や手動照合の対象にします。重要なリポジトリは本番前にリハーサルを行い、移行後のハッシュ、参照権限、テスト、デプロイ、ロールバックを確認してから切り替えます。

検証や小規模チームならFreeプランで試せる場合がありますが、本番導入の費用が無料になるわけではありません。レビューや権限、CI/CD、認証、移行、教育、運用監視が必要なら、ライセンス以外の費用が発生します。最初は代表リポジトリでPoCを行い、必要な機能と運用工数を把握してから、StandardやPremium、周辺サービスを含む年間予算に置き換える方法が安全です。

Bitbucketの初期設定だけでなく、要件定義、移行、CI/CD、本番デプロイ、認証・監査、教育、運用保守まで対応できるかを確認します。CloudとData Centerの両方の経験、同規模の移行実績、障害時の体制、再委託管理、設定やソースコードの引き渡し、契約終了時の支援を質問してください。見積もりは同じリポジトリ数、環境数、移行履歴、教育範囲で依頼し、作業一式ではなく工程と成果物で比較すると判断しやすくなります。

まとめ

Bitbucketのシステム開発は、Gitリポジトリを作るだけではなく、レビュー、テスト、デプロイ、認証、監査、運用教育までを一つの開発プロセスとして設計することです。要件整理で現在の課題と非機能要件を可視化し、Cloud・Data Center・Hybridを選び、代表リポジトリのPoCで確かめてから段階的に移行すると、導入後の手戻りを抑えられます。

最初の打ち合わせでは、利用者数、チーム数、リポジトリ数、移行元、データの機密性、認証方式、デプロイ先、レビューとブランチ保護のルール、テスト自動化の範囲、本番承認者、復旧要件、教育担当者を確認します。費用はライセンス、追加サービス、導入・移行支援、教育、保守に分け、見積書では工数、成果物、前提条件、別途作業、契約終了時の引き継ぎを確認します。

いきなり全社展開を目指すのではなく、1〜3個の代表リポジトリで、ブランチ保護、レビュー、テスト、ステージングデプロイ、失敗時の復旧を一通り試してください。検証結果をもとに運用ルールと見積もり条件を固め、必要に応じてBitbucketに詳しい開発会社へ相談します。ツールの導入ではなく、チームが安全な変更経路を継続して使える状態を目標にすることが、Bitbucketのシステム開発を成功させる近道です。

▼全体ガイドの記事
・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を創業。