Bitbucketのシステム開発は、6つのフェーズを順に進めます。最初に要件を整理して製品構成と導入方法を選び、そのうえで設計・開発とテストに進みます。各フェーズの中身は、下の見出しごとに説明します。この順に進めると、チームは安全に変更を続けられます。
▼全体ガイドの記事
・Bitbucketのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Bitbucketのシステム開発の全体像
Bitbucketのシステム開発は、リポジトリの置き換えに加えて、開発の流れを社内ルールとして決める作業です。変更はブランチで分け、プルリクエストでレビューします。そのうえで、テストに合格した変更だけを環境へ反映します。
「Bitbucketのシステム」の範囲と役割
開発基盤では、各ツールの役割と連携先を先に整理しておくと、予算と担当範囲を切り分けられます。
- 実行先：販売管理や基幹業務アプリは、AWS、Azure、社内サーバーなどで動きます。
- Bitbucketの役割：ソースコードと設定ファイルを管理し、変更を検証してから各環境へ届けます。
- 基本構成：Gitの管理はBitbucket、課題の管理はJira、設計・運用ナレッジの管理はConfluenceです。
- 自動化：ビルド、テスト、デプロイの実行は、Bitbucket Pipelinesが担います。
Bitbucketは、業務アプリそのものを動かす場所ではありません。ただし、Webhook、REST API、Forgeアプリを使えば、社内ポータル、承認ワークフロー、監査ダッシュボードとも連携できます。
Cloud・Data Center・Hybridの選び方
構成は、セキュリティ条件、管理したい範囲、運用体制をもとに選びます。
- Bitbucket Cloud：SaaSを使える小〜中規模チームにとっての第一候補です。
- Bitbucket Data Center：保管場所、ネットワーク、認証、監査、高可用性を細かく管理したい場合に検討します。
- Hybrid：自己管理環境をすぐには手放せず、クラウドの運用負荷も減らしたい場合の候補です。
Cloudは、インフラの構築やアップグレードを自社で抱えずに始められます。チームの増減にも合わせやすい構成です。
Hybridでは、二つの環境の権限、バックアップ、監視、移行方針をそれぞれ管理します。そのため、両方の環境を管理するぶん、管理コストが増えます。
判断するときは、データ分類、利用者数、リポジトリ数を確認します。加えて、ネットワーク制約と運用担当者数も見ます。機能が多いからという理由だけで選ぶと、運用の条件に合わなくなることがあります。
Bitbucketのシステム開発の進め方
Bitbucketの導入は、契約の後も作業が続きます。要件整理を出発点に、製品構成の選定、設計・開発、テストへと進み、その後に稼働と運用の定着まで、設定と運用ルールを順に整えていきます。
移行を先に進めると、旧環境で曖昧なままだった権限やレビューの慣行も、新しい環境へそのまま引き継がれます。そのため、要件整理に時間をかけることが、結果的に手戻りの短縮につながります。
フェーズ1：要件整理
まず、関係者の役割と、現在の開発・運用の状況を確認します。
- 役割：開発者、レビュー担当者、プロダクトオーナー、情シス、セキュリティ担当者の立場と関わり方を確認します。
- 規模と環境：利用者数、チーム数、リポジトリ数、容量、Gitサービス、Jira・Confluenceの有無を一覧にします。
- 運用状況：デプロイ先、リリース頻度、機密情報の扱い、mainへの直push、レビューやテストを経ない本番への経路を調べます。
画面の設定を見ただけでは、実際の運用は分かりません。そこで、設定に加えて、関係者への聞き取りを行います。
要件は、機能要件と非機能要件に分けて整理します。機能要件では、リポジトリ、ブランチ、プルリクエストのレビューを確認します。さらに、Pipelines、Jira連携、成果物の保存も見ておきます。
非機能要件では、認証、権限分離、監査ログを定義します。バックアップと復旧目標、データ所在地も決めておきます。加えて、可用性、脆弱性対応、退職者のアカウント停止も定めます。
要件整理で残す成果物は、構成図、利用者と権限の一覧、リポジトリの一覧表です。さらに、現状と目標の差分、優先順位、PoCの合格条件もまとめます。
JUAS「企業IT動向調査2026」では、システム開発の品質が予定どおりにならない要因として、計画時の考慮不足や仕様変更が挙げられています。また、現行の業務やシステムの複雑さも要因です。
Bitbucketの設定作業でも同じ傾向があるため、最初から全機能を盛り込まず、守る開発ルールと対象チームを先に定めます（出典：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2026」）。
フェーズ2：製品構成と導入方法の選定
Cloud、Data Center、Hybridを比べながら、Free、Standard、Premiumのどのプランまで必要かを検討します。
- 検証：小規模な検証であれば、Freeで試せる場合があります。
- 本番統制：レビュー必須化、IPアドレス制限、デプロイ権限、組織認証には、上位プランやAtlassian Guardなどの確認が要ります。
無料枠だけで選ぶと、監査や承認の要件を満たすために、あとから設計をやり直すことがあります。
既存環境から移行する場合は、移行ツールで運べる対象を先に確かめます。Bitbucket Cloud Migration Assistantは、その移行を支援します。
ユーザー、グループ、プロジェクト設定、ブランチ権限は、同じ条件のまま移るとは限りません。さらに、プルリクエストの添付やMarketplaceアプリも、移行先で同じように扱えるとは限りません。
移行対象の確認は、Atlassianの公式資料で行います（出典：Atlassian「What gets migrated with Bitbucket Cloud Migration Assistant」）。
移行対象と再設定対象を分けます。そのうえで、移行の前後でコミットハッシュ、ブランチ、タグを照合する計画を作ります。さらに、権限とレビュー履歴も照合の対象に含めます。
候補は、代表リポジトリを1〜3個使って検証します。機能表の確認だけでなく、実機でも確かめます。また、PoCの合格条件は事前に合意しておきます。
- 開発者がcloneし、プルリクエストを作れるか試します。
- テスト失敗時にマージを止め、ステージングへ配布できるか確かめます。
- 失敗時にロールバックできるか検証します。
- 権限不足、秘密情報の誤登録、外部サービス停止、同時実行数超過の場面も再現します。
フェーズ3：リポジトリとCI/CDの設計・開発
リポジトリの構成と変更の承認ルールを定め、画面の設定と運用手順の両方に反映します。
- 構成：プロジェクト階層と命名、所有者と公開範囲、ブランチ戦略を決めます。
- レビュー：承認者の人数、作業者本人の承認の可否、テスト成功を条件にするかを定めます。
- 例外：緊急修正を誰が承認するかを決めておきます。
たとえば、feature、release、mainの役割を定義します。あわせて、mainへの直pushを禁止し、プルリクエスト経由で変更を入れる形にします。
bitbucket-pipelines.ymlで、プルリクエスト時の静的解析と単体テスト、マージ後の結合テストを構成します。さらに、ステージングへの配布と、本番承認後のデプロイも設定します。
接続先は、AWSやAzure、GCPなどのクラウドと社内サーバーに分かれます。そのため、ホスト型とセルフホストのランナーを使い分けます。
秘密情報はコードに書かず、変数や外部のシークレット管理サービスで管理します。ログにトークンが出ないことも確認します。本番では、誤配布を防ぐために、利便性より権限の統制を優先します。
Bitbucket Cloudでは、環境ごとにデプロイできる利用者やグループを制限できます。例として、開発はチーム全員、ステージングはリリース担当、本番は責任者と運用担当に分けます。
出典：Atlassian「Set custom deployment permissions for your environments」
フェーズ4：テストと移行リハーサル
画面表示に加えて、権限と変更承認、監査、秘密情報の扱いを確認します。さらに、パイプラインの失敗時の動作も確かめます。
- アクセス制御：開発者が権限どおりに操作でき、レビューなしではmainへ入れないことを確かめます。
- 品質と監査：テスト失敗時にマージやデプロイが止まること、監査ログをたどれること、秘密情報がログに出ないことを調べます。
- 例外時の動作：実行時間や同時実行数の超過、ステップの再実行、デプロイ先の一時停止を試します。
移行の予行演習は、低リスクのリポジトリで行います。そのうえで、移行にかかる時間と停止の時間を測ります。
移行前には、リポジトリ、ブランチ、タグを確定します。Git LFS、サブモジュール、Webhookは、移行の前に確かめておきます。さらに、デプロイキー、環境変数、ユーザー・グループも確定させておきます。
移行後は、利用者とともにcloneや過去コミット、ブランチ保護を確認します。そのうえで、プルリクエストとJira課題キーを確かめます。さらに、Pipelinesの動作と成果物の取得も確認します。
結果を記録し、やり直しの条件を決めておくと、本番移行のときの判断が速くなります。
受入条件は感想ではなく、検証できる形で書いておきます。たとえば、対象リポジトリの100％で、権限表と設定が一致することを確認します。
mainへの直接変更は拒否し、本番デプロイは許可グループだけに限定します。さらに、障害時に30分以内で切り戻しを開始できる条件も設定できます。
復旧にかかる時間や許容できるデータ損失の範囲は、会社ごとに異なります。そのため、数値は担当部署と合意したうえで設定します。
フェーズ5：稼働と切り替え
移行責任者、技術責任者、業務側の承認者を決めたうえで、切り替え計画を作ります。さらに、連絡先と判断期限も計画に入れます。
- 切り替え条件：変更凍結、最終バックアップ、開始と完了の時刻、旧環境を読み取り専用にする時期を定めます。
- 切り替え作業：DNSと接続先の変更、問題発生時のロールバック条件を、一つにまとめます。
- 展開順：影響の小さいチームで先に稼働させ、問題がなければ対象を広げます。
稼働当日は、設定を変える人を限定し、作業ログを残します。
まず、新しいリポジトリへのpushとプルリクエストを確かめます。続いて、レビュー、テスト、ステージングデプロイを見ます。最後に、本番承認とロールバックを確認します。
手順書と画面が一致するかを確かめます。旧環境は、すぐには削除せず、参照専用またはバックアップとして一定期間残します。その後、保持期間と廃棄の責任者を決めたうえで、旧環境を終了します。
初期監視では、Pipelinesの失敗率と平均実行時間、レビューの滞留時間を見ます。さらに、デプロイとロールバックの回数、権限エラー、問い合わせ件数も見ます。
導入前の値がない場合は、最初の2〜4週間をベースラインとして記録します。この数値は、開発者を監視するためではなく、設定やレビュー・テストの効果を判断するために使います。
フェーズ6：運用と開発文化の定着
研修は、操作研修と開発ルールの研修に分けます。あわせて、管理者にも運用の教育を行います。
- 操作研修：clone、ブランチ作成、プルリクエスト、レビュー、Pipelinesの確認。
- 開発ルール：コミット粒度、レビュー観点、緊急リリース、脆弱性連絡、障害時の切り戻し。
- 管理者教育：ユーザー追加、グループ権限、監査ログ、ランナー、請求、バックアップ。
運用を開発者だけに集中させず、管理者も必要な作業を担える体制を作ります。
月次または四半期ごとに、不要アカウント、過剰権限、休眠リポジトリを点検します。管理者は、古いアクセストークンやPipelinesの失敗を確認します。さらに、秘密情報の検知とブランチ保護の例外も確かめます。
新しいチームや外部委託先を加えるときは、既存の権限をそのままコピーしないようにします。
契約が終わるときは、アカウントの停止とリポジトリの所有権を確認します。さらに、ソースコードの返却・削除、再委託先の管理も確かめます。
NISTのSecure Software Development Frameworkは、安全な開発の進め方を組織のプロセスに組み込む枠組みです。開発組織は、これを参照枠として使えます。
ルール違反が続くときは、現場だけを責めず、設定や手順を見直します。たとえば、レビューが遅ければ担当を調整し、テストが不安定なら原因を直してから必須にします。
ゴールは、変更を禁止することではなく、安全に変更できる経路をチームが使い続けられる状態です。
Bitbucketのシステム開発にかかる費用相場と内訳
費用は、ライセンスと周辺サービス、導入・移行・CI/CD支援に分けて考えます。さらに、教育と稼働後の保守・運用も含めて見ます。公式料金と開発会社の作業費は、別の費用です。
ここに示すのは、2026年8月時点の公開情報とリサーチノートによる目安です。実際の見積もりを保証するものではありません。
ライセンス料金の見積もり方
Cloudの料金は、プランやユーザー数に加えて、追加のビルド時間やストレージによって変わります。
- プラン：Free、Standard、Premiumなどから選びます。
- 利用規模：ユーザー数に応じて、料金が変わります。
- 追加利用：ビルド時間やストレージの追加分を確かめます。
公式料金では、6〜100ユーザーの場合、Standardは1ユーザー月額3.65米ドル、Premiumは月額7.25米ドルです。
10人の場合、基本料金はStandardが月36.50米ドル、Premiumが月72.50米ドルです（出典：Atlassian「Bitbucket Pricing」2026年8月確認）。
仮に1米ドル=150円で換算すると、10人のStandardは月約5,500円、Premiumは月約10,900円です。これは為替による概算で、実際の額は契約形態や税によっても変わります。
料金は、ユーザーの定義、他のAtlassian製品、追加ビルド時間によっても変わります。さらに、Git LFS、セルフホストランナー、Atlassian Guardの有無も関わります。円に換算するときは、換算日と為替の前提を併記します。
導入・移行・CI/CD構築の費用相場
PoCから複数拠点の導入まで、支援範囲と期間に応じて費用の目安が異なります。
- 小規模PoC・現状診断：50万〜150万円程度、2〜4週間が目安です。
- Cloud標準導入：100万〜300万円程度、1〜2か月が目安です。
- 既存Git移行・CI/CD整備：300万〜800万円程度、2〜4か月が目安です。
- 複数拠点・高可用性など：800万〜2,000万円以上、4〜9か月となる場合があります。
PoC・診断には、現状の洗い出し、CloudとData Centerの比較、代表リポジトリでのプルリクエストとPipelinesの検証を含む想定です。さらに、運用課題の整理も含みます。
作業範囲が狭ければ金額は下がり、複数の認証基盤やネットワーク接続も検証すれば上がります。
Cloud標準導入には、ワークスペース、プロジェクト、権限の設定を含む想定です。さらに、ブランチ保護とJira連携、基本的なPipelineを含みます。また、手順書や管理者・開発者教育も対象になります。
移行・CI/CD整備では、数十〜数百リポジトリ、SSO、秘密情報の再配置を含むと工数が増えます。さらに、複数環境へのデプロイや段階移行を含む場合も、工数は膨らみます。
複数拠点、高可用性、ネットワーク分離を含む案件は、上記の高額帯になる場合があります。監査、Data Center・Hybrid、独自のForge・API開発を含むときも、同じように高額になることがあります。
これらはBitbucketの定価ではなく、導入支援費の推定です。導入支援費には、要件定義、設計、実装が含まれます。さらに、移行、テスト、教育、プロジェクト管理も含みます。
JUAS「企業IT動向調査2026」では、人材確保の難しさや価格の高騰が、システム開発のQCDに影響するとされています。そのため、過去の単価だけで現在の予算を断定しないことが大切です。
稼働後のランニングコストの内訳
稼働後の費用は、CloudかData Centerかで必要なサービスや運用作業が変わります。
- Cloud：ライセンス、追加ビルド時間・ストレージ、ランナー、認証・監査サービスが中心です。
- Data Center：ライセンスに加え、サーバーやクラウド基盤、冗長化、バックアップ、監視、パッチ適用、アップグレード、障害対応を自社か委託先が担います。
- 保守費の目安：初期構築費の年15〜25％程度とする一般論がありますが、固定のルールではありません。
管理者が不足すると、運用費は膨らみます。あわせて、月次の作業時間も人件費として見積もります。
問い合わせ対応や24時間監視の有無で、費用は変わります。さらに、脆弱性対応とPipeline改修、利用者追加とリポジトリ整理の扱いによっても、金額が違ってきます。
見積書では、月次作業と障害対応時間を分けて確認します。さらに、追加作業の単価と、契約終了時の引き継ぎも確かめます。
Bitbucketのシステム開発で見積もりを取るポイント
対象範囲、成果物、検収条件をそろえたRFPで依頼すると、抜け漏れのある提案を見分けられます。逆に、ユーザー数だけで見積もりを比べると、条件の違いを見落としがちです。
比較条件には、リポジトリ数、移行元、権限の複雑さを含めます。さらに、接続環境、Pipeline数、テスト自動化も比べます。加えて、認証と監査、教育、運用保守も条件に入れます。
作業範囲と成果物の切り分け
見積書では、工程と納品物を対応させ、「作業一式」に含まれる範囲をはっきりさせます。
- 工程：現状調査と要件定義、設計と設定・開発、移行とテスト、稼働支援と教育、保守に分けます。
- 成果物：構成図と権限一覧、命名規則とブランチ運用規約、Pipeline定義とテスト・移行計画を明記します。
- 運用資料：切り替え・障害対応手順と教育資料を、納品物に含めるか確認します。
移行リハーサルと照合、権限の再設定、Marketplaceアプリの代替は、抜けやすい作業です。委託先アカウントと秘密情報の入れ替えも、見積もりから漏れやすい作業です。また、ロールバックや利用者教育も、見積もりに入れ忘れやすい点です。
別途扱いになる作業は、費用と判断期限を記載してもらいます。さらに、著作権、ソースコード、Pipeline定義の引き渡しを、契約前に確認します。加えて、Infrastructure as Codeと管理者アカウントの引き渡しも確かめます。
要件と工数の前提
同じリポジトリ数や「CI/CD構築」でも、工数は変わります。差が出るのは、移行元と履歴、テストと接続先といった前提が異なるためです。
- 移行条件：100リポジトリの場合でも、移行元がBitbucket ServerかGitHubか、レビュー履歴、Git LFSとサブモジュールの有無で異なります。
- CI/CD条件：テストが1種類か、複数クラウドへの承認付き配布か、社内接続かで難易度が変わります。
見積もりには、リポジトリの重要度、言語、ビルド時間を添えます。さらに、テスト数と環境数、デプロイ頻度と利用者数を示します。加えて、認証、運用時間帯、復旧水準も添えます。
作業量は、人日や人月で示してもらいます。役割も、管理者とPM、インフラとCI/CD、移行と教育に分けます。デジタル庁の標準ガイドラインは、工数と単価で積算し、20人日を1人月とする考え方を示しています。
開発会社の体制とリスク分担
技術経験、担当体制、契約上の分担は、開発会社と一緒に確認します。
- 技術経験：Bitbucketの構成、移行、運用に必要な技術を確認します。
- 担当体制：パートナーランクだけでなく、同規模の実績や担当者の所属、再委託、障害時の連絡時間を確かめます。
- 引き継ぎ：契約終了時の支援と、社内に残す運用スキルを決めます。
技術の確認では、Cloud・Data Centerの経験と、Pipelines・本番デプロイの設計経験を見ます。さらに、GitHub・GitLab・Perforceからの移行実績も確かめます。
加えて、ForgeやREST APIの開発力と、SSO・監査・秘密情報管理の知識も質問します。
提案書には、顧客側の作業、外部契約、ネットワーク開通を記載してもらいます。さらに、アカウント準備とデータ整理、テストデータ、承認者の参加時期も書いてもらいます。
顧客側の意思決定やレビューの工数を見込まないまま納期だけを決めると、追加費用や延期の原因になりがちです。
仕様変更、受入基準、瑕疵対応の扱いを、契約書と見積書で一致させます。保守の範囲も揃えます。
ユーザーや権限の変更を外注するか、Pipelineの修正と障害の一次対応を内製するかを選びます。さらに、設計書と設定を自社で更新するかも決めておきます。
外注を増やしても、運用の知識が社内に残るとは限りません。JUASの2026年調査では、内製化の課題として開発やプロジェクトマネジメントの人材不足が挙げられています。そのため、教育と引き継ぎも見積もりに含めることが現実的です。
Bitbucketのシステム開発に関するよくある質問
費用、移行、運用について、よくある質問に答えます。規模やセキュリティ要件に応じて、要件整理の確認項目としてお使いください。
Bitbucket CloudとData Centerはどちらを選べばよいですか？
SaaS利用とクラウド保管が社内規程に合い、自社での基盤運用が不要ならCloudが選びやすいです。
データ所在地、ネットワーク分離、独自の可用性設計、自己管理が必須ならData Centerを検討します。
迷う場合は、利用者数や料金に加えて、審査とバックアップの担当を比べます。さらに、障害対応とアップグレードの担当も確かめ、代表リポジトリでPoCを行います。
既存のGitHubやGitLabからBitbucketへ移行できますか？
既存のGitHubやGitLabからも移行できますが、リポジトリをコピーするだけで完了するとは限りません。
移行では、コミット、ブランチ、タグを分けて確認します。さらに、LFSとサブモジュール、レビュー履歴も確かめます。加えて、Webhookとデプロイキー、権限と課題管理連携も見ます。
ツールで扱えない項目は、再設定や手動照合の対象にします。本番の前にリハーサルを行い、ハッシュと権限を確かめます。さらに、テストやデプロイ、ロールバックも確認してから切り替えます。
Bitbucketの導入は無料で始められますか？
検証や小規模チームであれば、Freeで試せる場合があります。ただし、本番導入まで無料になるわけではありません。
レビューや権限の設定、CI/CDや認証が必要なら、ライセンス以外の費用も発生します。移行、教育、運用監視にも、費用がかかります。
代表リポジトリでPoCを行い、必要な機能と運用の工数を把握します。そのうえで、StandardやPremium、周辺サービスを含めた年間予算に置き換えます。
開発会社へ依頼するときは何を確認すればよいですか？
初期設定に加えて、要件定義、移行、CI/CDに対応できるかを確認します。さらに、本番デプロイ、認証・監査、教育、保守まで対応できるかも見ます。
CloudとData Centerの経験、同規模の移行実績、障害体制を質問します。さらに、再委託管理、設定・ソースコードの引き渡し、契約終了時の支援も質問します。
リポジトリ数と環境数、移行履歴と教育範囲をそろえて見積もりを取り、工程と成果物で比べると判断しやすくなります。
まとめ
Bitbucketの開発基盤では、レビューとテスト、デプロイを一つの工程として設計します。さらに、認証と監査、運用教育も、同じ流れに組み込みます。
要件と非機能要件を書き出し、Cloud・Data Center・Hybridから構成を選びます。代表リポジトリでPoCを行ってから段階移行すると、手戻りを抑えられます。
最初に確認する項目
打ち合わせでは、規模、移行元、機密性を確認します。さらに、認証、デプロイ先、テスト、レビュー・ブランチ保護を確かめます。加えて、本番承認、復旧、教育担当者も見ておきます。
費用は、ライセンスと追加サービス、導入と移行、教育と保守に分けて確認します。そのうえで、工数や成果物、前提を確かめます。さらに、別途作業と契約終了時の引き継ぎも確認します。
無理なく進めるための次の一歩
全社展開の前に、代表リポジトリで検証して、運用ルールと見積もり条件を固めます。
- 1〜3個の代表リポジトリで、ブランチ保護とレビュー、テスト、ステージング、失敗時の復旧を試します。
- 検証結果をもとに運用ルールと見積もり条件を固め、必要ならBitbucketに詳しい開発会社へ相談します。
ツールを入れるだけで終わらせず、安全な変更経路をチームが使い続けられる状態を目指すことが、成功への近道です。
▼全体ガイドの記事
・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を創業。