GitLabのシステム開発を外部に発注する進め方は、目的と成果指標を決めるところから始まります。要件とRFPを整理し、PoCから移行・運用へ段階的に進めると、自社の開発基盤として根づいていきます。
発注形態、RFP・要件整理、契約と費用、委託先選定の順に、各段階で決めることを見ていきます。
▼全体ガイドの記事
・GitLabのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
GitLabのシステムを発注・外注する前の前提
GitLabはGitリポジトリだけを置くサービスではなく、DevSecOps基盤です。計画、Issue、マージリクエスト、コードレビューをつなぎます。さらに、ビルド、テスト、デプロイ、脆弱性検査、リリース後の分析も同じ基盤でつながります。
CI/CDに関する公式の説明でも、DevSecOpsのライフサイクル全体を一つのアプリケーションで扱う基盤とされています（出典: GitLab公式、2026年8月確認）。
GitLab導入とアプリ開発の発注の分け方
導入とアプリ開発の発注は、見積もりの内訳をそろえて、どこまでを誰が受け持つかを確認できるようにしておきます。
- GitLab基盤：現状の洗い出し・リポジトリ移行・SSO・Runner・CI/CD
- 業務アプリ開発：要件・画面・データモデル・API・テスト・クラウド
権限、監査、教育、運用設計の要件を整理し、CI/CDテンプレートの内容も具体化します。
両方を依頼する場合は、見積書を「GitLab導入一式」と「業務アプリ開発」に分けてもらいます。分けないまま発注すると、ライセンス販売会社とアプリ開発会社の担当範囲が曖昧になります。さらに、パイプラインの不具合や移行後の運用は別料金になりやすいため、分けて確認しておくと、後から料金の食い違いが起きにくくなります。
目的と成果指標の設定
導入後に達成度を確かめられるよう、測定できる目標を先に決めておきます。
- 成果指標の二つか三つへの絞り込み
- 目標から必要なGitLab機能の判断
「GitLabを導入すること」だけを目的にすると、既存ツールとの役割分担が決まらず、ツールが増えるだけになる場合もあります。そのため、GitHub、Jenkins、Redmine、Slack、クラウド基盤との役割を先に整理します。
目標の候補は、リードタイム短縮、デプロイ頻度の向上、レビュー滞留時間の削減です。ほかにも、脆弱性の検出から修正までの時間を縮めることや、監査証跡をまとめることが候補になります。
たとえば、本番リリースの承認をGitLabに集約する目標や、主要リポジトリの80％で自動テストを実行する目標を立てます。重大な脆弱性の検知から対応方針の決定までを1営業日以内にする目標も設定できます。
目標に照らして、Premiumが必要かを判断します。そのうえで、Ultimateの脆弱性管理やコンプライアンス機能は、業務上の必要性から検討します。
GitLabの発注形態の選び方
発注形態は、GitLabのライセンス契約、導入支援、移行・CI/CD構築、運用保守、アプリケーション開発に分けて考えると選びやすくなります。
一社にまとめて任せる方法もあります。ただし、契約上の責任範囲と成果物を分けておくと、相見積もりや将来の乗り換えに役立ちます。
GitLab.comとSelf-Managedの選び分け
運用の負担やデータの要件を踏まえて、提案の前提をそろえます。
- 三つのサービス形態の比較
- RFPへの判断条件の記載
GitLab.comは、GitLabが運用するSaaSで、初期構築やアップグレードの負担を小さくできます。
GitLab Self-Managedは、オンプレミスや自社契約のクラウドに、自社または委託先が構築・運用する形態です。ネットワーク、バックアップ、データの所在、認証、Runner、障害対応を自社の基準に合わせられる一方で、運用の責任が増えます。
GitLab Dedicatedは、GitLabが管理する単一テナントのSaaSです。データレジデンシーや分離を重視する企業の選択肢になります（出典: GitLab公式Pricing、2026年8月確認）。
RFPには、ソースコードやCI/CD変数の保管地域と閉域接続の要否を明記します。さらに、可用性と復旧目標、確保できるGitLab管理者の人数、アップグレードの許容時間、監査ログの保管先も記載します。そのため、提案会社の回答を同じ前提で比べられます。
ライセンス販売と導入支援の分担
会社ごとの支援内容と、案件でどこまでを担うかを照合します。
- 販売と導入支援それぞれの役割
- 見積依頼での担当範囲と実績の確認
ライセンス販売会社が、移行やCI/CD設計も担当するとは限りません。また、GitLab公式のパートナー制度では、支援内容ごとに役割が分かれています。
GitLab公式のプロフェッショナルサービスは、導入、移行、助言、加速化、教育を支援します。DevSecOpsワークショップやセキュリティコンサルティングも含まれます（出典: GitLab公式「プロフェッショナルサービス」、2026年8月確認）。
見積もりの前提がそろわないと、提案どうしを比べにくくなります。そこで、ライセンス調達先、契約主体、導入責任者、クラウド・ネットワーク構築とアプリ開発の担当を書いてもらいます。問い合わせ窓口と障害時の一次切り分け担当も確認しておきます。
NRI、カサレアル、SB C&S、TDCソフトなどは、国内で販売・導入・教育・運用支援を公表しています。ただし、同じ会社でも案件ごとに実装範囲は異なります。
PoCから段階的に外注する進め方
全社移行の前に、非本番の1〜3リポジトリでPoCを行います。移行と検証の対象は、次の順に定めます。
- Git履歴、Issue、Wiki、LFSを移します。ブランチ保護、CI/CD変数、Runner、Webhook、権限も移行対象です。
- テストとステージングへのデプロイが安定して行えるかの確認。
- 成果物は、移行手順書、運用ルール、残課題、次段階の見積もり。
PoC後は、共通CI/CDテンプレートを整えたうえで、対象チームを増やします。
GitLab導入を組織改革と同時に進める場合は、最初から全社標準を完成させようとせず、利用者のフィードバックを標準に反映できるよう、契約期間と変更管理の方法を設けます。
準委任で検証と改善を進め、確定した移行作業や成果物は請負で切り出す組み合わせも考えられます。
RFP・要件整理の内容
RFPは、同じ条件で提案と見積もりを比べるための基準です。現状、対象範囲、制約、期待成果を書き、納品物、体制、契約条件、評価方法も一つにまとめます。未確定の項目は、無理に決めず、提案会社への確認事項として残します。
現状のツールと移行対象の一覧化
現行ツールと移行対象の情報を、一覧にして整理します。
- 現行ツールと実行基盤の情報
- リポジトリと移行に関する情報
リポジトリはGitHubやBitbucketなど、CI/CDはJenkinsやGitHub Actionsなど、課題管理はJiraやRedmineなどが対象です。
通知はSlackなど、実行基盤はAWS・Azure・Google Cloudなどが対象になります。リポジトリについては、数に加えて言語、容量、LFS利用、ブランチ数も整理しておきます。
IssueやWikiの移行要否、デプロイ先、利用者と権限を記録したうえで、外部とつながる部分と秘密情報の置き場所も整理します。
- 外部連携
- 秘密情報の保管場所
移行時は、CI/CD変数、Runnerの実行権限、Webhook、コンテナレジストリ、成果物の保存期間も、移行後に動くかどうかを確認します。
秘密情報はそのまま移さず、保護された変数やクラウドのSecrets Managerへ移す方針をRFPに記載します。旧環境は、停止する時期と参照専用で残す期間もあわせて決めます。
機能要件と非機能要件の書き分け
機能要件と非機能要件を分けて記載します。
- 機能要件
- 非機能要件と監査ログ
機能要件には、プロジェクト・グループ構成、ブランチ保護、マージリクエスト承認を記載します。Issue、マイルストーン、CI/CDステージ、テスト、成果物も含めます。
ステージング、本番デプロイ、脆弱性スキャン、Slackやチケット管理との連携も書きます。標準フローには、lint、単体テスト、ビルドを含めます。さらに、SASTや依存関係検査、コンテナスキャン、ステージング、承認、本番という流れも、提案依頼に含めます。
非機能要件には、可用性、バックアップ、復旧目標、ログ保管を記載します。さらに、監視、性能、利用者数、同時実行数も含めます。データの所在、MFAやSSO、権限の見直し方法も、要件として書きます。
脆弱性対応時間と障害時の連絡体制も定めます。
GitLab.com、Self-Managed、Dedicatedでは監査イベントが提供されており、ユーザーやプロジェクトの権限変更などを追跡できます（出典: GitLab公式Docs「Audit events」、2026年8月確認）。そのうえで、監査ログの確認担当と頻度、SIEMへの送信も要件に入れます。
セキュリティ・個人情報・AI利用のルール
契約書や開発標準に書き込む判断材料を、先に整理します。
- 個人情報・機密情報の管理：Issue・ログ・テストデータ・アーティファクト
- AI機能の利用・確認ルール
金融、公共、医療、製造などでは、開発記録に機微な情報が含まれる場合があります。
RFPと契約書には、委託先・再委託先の管理、国外での取扱い、データの削除・返却、アクセス権を記載します。さらに、暗号化、インシデント通知、監査協力も含めます。
個人情報保護委員会のガイドラインも、委託先の選定、契約、取扱状況の把握を委託元の確認事項としています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。
GitLab DuoなどのAI機能では、コードやIssue情報をどこまで処理させるかを決めておきます。そのうえで、利用を許可するプロジェクトと、生成コードのレビュー担当も定めます。
脆弱性検査、OSSライセンス確認、AI操作の監査ログも決めておきます。特に、認証・認可、決済、秘密情報、監査ログに関わるコードは、AI出力だけで本番に入れないことを開発標準に明記します。
GitLab導入の契約形態の選び方
GitLabの発注では、ライセンスのサブスクリプション契約と、導入・開発・保守の業務委託契約を組み合わせて結ぶことになります。
契約形態によって、成果物を完成させる責任、作業時間への対価、仕様変更の扱い、検収方法が変わります。そのため、プロジェクトの不確実性に合わせて選びます。契約書の最終確認は、社内の法務や専門家と行います。
請負・準委任・ライセンスの役割の違い
成果物の確定度と作業内容の変化に合わせて、契約条件を決めます。
- 請負の成果物と検収の定義
- 準委任とライセンスの条件の確認
移行手順書、標準CI/CDテンプレート、SSO連携、バックアップ設定、PoC環境は、完了条件を具体化しやすい成果物です。
成果物の定義が曖昧だと、検収時に「動く」の基準が食い違い、追加費用や納期遅延につながります。
準委任は、要件検証、現状調査、アーキテクチャ検討、運用改善、伴走支援など、作業内容が進行中に変わる業務と相性がよい形態です。そのうえで、稼働時間、担当者、作業報告、会議体、意思決定者、成果物の扱いを決めます。
ライセンスはGitLabまたは販売パートナーとのサブスクリプション契約になります。ユーザー数、プラン、契約期間、追加利用量を確認し、さらに更新、解約、サポート範囲も確かめます。
契約書の成果物と引き渡し条件
作業が終わった後も、社内で構成を再現し、移管できる状態にしておきます。
- 納品する成果物の明記
- 契約・保守・終了時の条件の確認
成果物の例は、要件定義書、構成図、権限一覧、移行計画、テスト計画・結果です。
CI/CD定義、IaC、運用手順書、教育資料、ソースコード、設定情報も納品対象にできます。特に、画面設定だけでは再現できない構成が残る場合があるため、教育資料、ソースコード、設定情報の納品有無を定めておきます。
設定は可能な限りコード化し、リポジトリで管理して引き渡してもらいます。
知的財産権、OSSライセンス、再委託の可否・開示、秘密保持を確認します。脆弱性対応、障害時のSLA、バックアップと復旧も定めます。
契約終了時のデータ返却・削除と、管理者アカウントの引き渡しも決めておきます。
Self-Managedでは、GitLab本体に加えて、Runner、データベース、ストレージ、監視、バックアップが保守対象かどうかを分けて書きます。
GitLabのシステム発注・外注費用の相場
GitLab導入に特化した日本円の統一相場は公開されていません。ここで示す費用目安は、NotebookLMの業務システム全般に関する調査で示された規模別の目安と、GitLab公式のライセンス価格を組み合わせた推定です。会社や要件によって大きく変わるため、価格を断定せず、ライセンス費用と導入支援・開発費は分けて比べます。
プランとユーザー数によるライセンス費用
ユーザー数や利用量をもとに、継続費用の前提をそろえます。
- プラン別の料金・クレジット
- 為替換算と追加利用料金
GitLab公式Pricingでは、GitLab.comのFreeは0米ドルです。Premiumは年払いで29米ドル／ユーザー／月、Ultimateは個別見積もりです。
PremiumにはDuo Agent Platform用クレジットが1ユーザーあたり月12米ドル分含まれます。Ultimateについては、月24米ドル分が含まれると表示されています。
Duo追加クレジットは1米ドル／クレジットで、追加Compute minutesは10米ドル／1,000分、ストレージは月5米ドル／10GiBです（出典: GitLab公式Pricing、2026年8月確認）。
Premiumの公開価格を1ドル160円として単純換算すると、10ユーザーは年約56万円、50ユーザーは年約278万円、100ユーザーは年約557万円です。ただし、これは為替、税、販売パートナーの価格、契約条件、ユーザーの数え方で変わる参考値で、導入支援費やクラウド費用は含みません。
Freeでも自社Runnerを使えますが、監査、セキュリティ管理、承認、サポートなどの必要性を確認してプランを選びます。
導入支援・移行・CI/CD構築の費用目安
対象範囲をそろえ、規模ごとの見積もりを比較します。
- 小規模PoCの費用・期間
- 複数チーム標準化の費用・期間
- 大規模Self-Managed移行の費用・期間
想定する作業は、契約、数件のリポジトリ移行、基本的なブランチルール、単純なテスト・ビルド、利用者教育です。対象は1〜3チームです。
初期費用は50万〜300万円程度、期間は2週間〜2か月程度が目安です。認証連携、本番デプロイ、複雑な既存CI/CD移行を含むと、費用は上振れします。
複数チームの標準化は、初期300万〜1,000万円程度、3〜6か月程度が目安です。SSO、Runner、アーティファクト管理、ステージングに加え、自動テスト、脆弱性スキャン、クラウド・チケット連携、移行、教育も含む想定です。
この標準化は、複数部門、閉域網、HA・DR、SIEM連携を伴う場合もあります。数百〜数千リポジトリを移すSelf-Managedでは、初期1,000万〜5,000万円以上、6〜12か月程度となる可能性があります。
業務システム全般の調査では、人件費がシステム費用の約60〜80％を占めるとの一般論があります（出典: NotebookLM Q&A「業務システム全般_15」、2026年8月確認）。
GitLabでも総額は、移行対象の数、CI/CDの複雑さ、セキュリティ要件によって変わります。さらに、社内の意思決定の速さや、教育・運用設計の工数も影響します。
見積もりは「GitLab導入一式」にせず、要件定義、現状調査、ライセンス、移行、認証に分けてもらいます。さらに、Runner、CI/CD、セキュリティ、テストを分けます。教育、保守、予備費も別に示してもらいます。
保守費用と追加費用の見積もり
継続費用と追加費用の項目を分けて見積もります。
- 継続する利用・運用費
- 保守費と追加作業の条件
ランニングコストには、GitLabのサブスクリプション、追加クレジット、Compute minutes、ストレージが含まれます。
Self-Managedでは、クラウド、データベース、バックアップ、監視も対象になります。
保守には、Runnerの実行環境、サポート、アップグレード、脆弱性対応も含まれます。GitLab本体に加えて、OS、ミドルウェア、Runnerの保守担当も必要です。
一般的な業務システムの推定では、初期導入費の年15〜25％程度を保守運用費の検討レンジに置くことがあります。ただし、これはGitLab公式の料金ではありません。
保守費は、問い合わせだけか、24時間監視か、アップグレードや復旧訓練まで含むかで変わります。
見積もりには、追加リポジトリやユーザー、ストレージ増加、移行のやり直し、セキュリティ是正、教育の追加などの変更条件も記載してもらいます。
GitLabの委託先選定と見積比較のポイント
委託先を選ぶときは、GitLab.com、Self-Managed、Dedicatedの経験と、GitHubやJenkinsからの移行実績を確認します。知名度やライセンス価格は、判断材料の一つとして見ます。
AWS・Azure・Google CloudやKubernetesの知識に加え、SSO・SIEM・監査への対応力も比較します。また、アプリ開発力、日本語の運用支援、再委託管理も同じ基準で確認します。
担当範囲に基づく実績の確認
質問項目をそろえて、各社が案件で実際に担った作業を確かめます。
- GitLab導入・移行の実績の確認
- 自社条件に照らした担当範囲と事例の評価
「GitLab導入の実績はありますか」という問いに加えて、移行ユーザー数とリポジトリ数を聞きます。さらに、サービス形態と移行元のCI/CDも確認します。
SSOや権限の設計、本番デプロイの承認とロールバック方法も質問します。そのうえで、導入後の保守担当も確認します。
事例の内容が自社に合うかを見極めるため、可能であれば、匿名化した構成図や移行計画のサンプルも見せてもらいます。
みんなの銀行は、GitLab Ultimateを使って金融要件に沿う基盤を構築しました。コンプライアンス・パイプラインと内製化の事例です。この事例はGitLab公式が紹介しています（出典: GitLab公式「みんなの銀行がGitLabで実現した金融システムの内製化とDevSecOps」、2026年8月確認）。
他社の成功は自社の成果を保証しません。そのため、自社の組織体制とデータ要件に置き換えた提案を求めます。
見積書の工数・前提・除外項目の比較
見積もりの条件をそろえ、内訳と評価軸を比べます。
- 見積もりの作業と契約条件の統一
- 価格差の理由と評価配点の確認
相見積もりでは、合計金額の前に、作業項目、工数、単価、期間、担当者を同じ形式にそろえます。さらに、前提条件、納品物、検収条件、除外項目もそろえます。
たとえば、A社は移行費にIssueとWikiを含め、B社はGit履歴だけを含めているなら、まず移行範囲をそろえて比べる必要があります。そのため、ライセンス、クラウド、導入支援、アプリ開発、保守を別行にし、同じ前提で再見積もりを依頼します。
安い見積もりは、その理由を確かめます。要件定義やテストが少ないのか、既存設定をそのまま使うのか、教育や運用設計を除外しているのか、再委託が多いのかを尋ねます。
逆に高い見積もりも、セキュリティ設計、移行リハーサル、バックアップ復旧テスト、引き継ぎ、保守SLAを含むなら、単純な過剰請求とは限りません。
評価は、価格40点、技術・移行実績25点、体制20点、契約・保守15点のように社内で先に配点を決めておくと、価格だけに引っ張られにくくなります。
委託先への運用・撤退の質問
運用時の役割と、契約後に自社で引き継げる条件を確かめます。
- 運用担当と引き継ぎ条件の確認
- 契約終了時のデータと設定の確認
提案書には、障害時に最初にログを確認する担当者と、GitLabのアップグレード検証の頻度を示してもらいます。Runnerの脆弱性修正担当者と、権限の見直しの承認者も明記してもらいます。
自社への移行を予定する場合は、見積もりに管理者教育、手順書、演習、問い合わせ期間を含めます。
返却対象はGit履歴、Issue、Wiki、アーティファクト、CI/CD設定、監査ログです。データの返却形式と出力可否も契約時に定めます。
管理者アカウントやIaCの引き渡しも決めます。設定と運用を社内で再現できる状態を納品条件にすると、ロックインを抑えられます。
GitLabの発注・外注に関するよくある質問
費用や期間は、ユーザー数だけでなく、移行対象、セキュリティ、運用責任、既存ツールとの連携によって変わります。そのため、各質問の答えも自社の条件に置き換えて読むと役立ちます。
GitLabの導入を小規模に外注できますか？
外注できます。1〜3リポジトリのPoCを使えば、全社移行の前にリスクを確かめられます。
PoCではGitLab.comの契約、基本権限、ブランチ保護、テスト・ビルド、ステージングへのデプロイ、利用者教育を依頼します。
PoCで終わらせず、移行手順書と次段階の見積もりも成果物に含めます。
GitHubやJenkinsからの移行も依頼できますか？
依頼できます。Git履歴に加えて、Issue、Wiki、LFS、ブランチ保護、CI/CD変数の移行範囲を決めます。Runner、Webhook、成果物、権限、通知も、同じように範囲を決めます。
移行前に一覧を作ってバックアップを取り、少数のリポジトリでリハーサルしてから本番移行します。
旧環境の停止時期と、問題発生時の切り戻し条件も契約に記載します。
PremiumとUltimateはどちらを選べばよいですか？
コラボレーション、Advanced CI/CD、優先サポートが中心ならPremiumを候補にします。
アプリケーションセキュリティ、ソフトウェアサプライチェーン、脆弱性管理、コンプライアンス、ガバナンスが必要ならUltimateを候補にします。
GitLab公式PricingではPremiumは公開価格、Ultimateは個別見積もりです。そのうえで、必要な統制、監査、承認、セキュリティ運用をRFPに記載します。
GitLabの委託先は何社に見積もりを依頼すべきですか？
比較可能な提案を得るには、少なくとも2〜3社に同じRFPを渡す方法が現実的です。
製品元のプロフェッショナルサービス、ライセンス販売会社、移行・クラウド・アプリ開発に強いSIerなど、異なる役割の会社を含めます。これにより、候補ごとの分担が見えやすくなります。
発注側は、価格だけでなく、移行範囲、成果物、体制、保守、契約終了時の引き渡しも比べます。
まとめ
発注前の最終確認
発注前に、対象範囲、移行対象、サービス形態、プラン、成果物、検収条件を社内で確認します。そのうえで、契約終了時の引き渡しと保守範囲も確認し、見積書の前提条件と除外項目を読み合わせます。
情報システム、開発、セキュリティ、法務の承認者を決めておくと、提案比較から契約まで進めやすくなります。
導入後の定着までの委託範囲
導入後の運用状況と改善の進み具合を確かめます。
- 運用品質の継続的な確認
- 発注要件の整理
- 契約と費用を分けた比較
- 自社運用を再現できる委託先の選定
導入後は、パイプラインの成功率、デプロイ頻度、レビュー時間、脆弱性対応時間、権限の見直しを定期的に追います。
教育、問い合わせ、テンプレート改善、アップグレード検証の担当を明確にします。
GitLabの利用だけでなく、開発品質とリリースの安定性が改善しているかを継続的に見直します。
発注では、GitLab導入と業務アプリ開発を切り分けます。GitLab.com、Self-Managed、Dedicatedは、データ所在、閉域性、運用体制、監査要件から選びます。
RFPには、現行ツール、移行対象、CI/CD、認証、セキュリティ、AI利用の情報を整理します。さらに、非機能要件と成果物も盛り込みます。
確定した成果物は請負、検証や伴走は準委任、ライセンスはサブスクリプションに分けると、責任範囲がはっきりします。
費用は、公開ライセンス価格だけでなく、PoC、社内標準化、Self-Managedの規模別に検討します。要件定義、移行、CI/CD、教育、保守、予備費まで分けて、相見積もりを比べます。
最終的に目指すのは、リポジトリ、パイプライン、セキュリティ、承認、監査、運用を自社のルールとして定着させることです。GitLabの導入は、その手段にあたります。
PoCで実現性を確かめ、設定・IaC・手順書・権限を自社へ引き渡せる委託先を選ぶと、導入後の改善や将来の契約見直しにも備えられます。
▼全体ガイドの記事
・GitLabのシステム開発の完全ガイド
▼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を創業。