相談する

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

GitLab CIの発注は、現状整理、要件整理、委託先選定、契約締結、PoC、段階移行の順に進めると、運用を社内へ引き継げます。

各段階で何を決めるか、発注側と委託先がどこまでを受け持つかを、見出しの順に見ていきます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

GitLab CIのシステム発注・外注の範囲

GitLab CIの発注は、コードのビルドやテストを自動化する仕組みを専門会社に頼むことです。さらに、安全に継続リリースできるDevOps・DevSecOps基盤について、設計、構築、移行、運用支援までを依頼します。

アプリケーション本体の開発契約とは、納品するものも責任の範囲も異なるため、依頼の前に対象を分けておきます。

発注範囲に含める機能

CI/CDの発注範囲を決めるときは、運用に必要な機能が範囲に入っているかを確かめます。

  • 基盤と保存：Gitリポジトリ、.gitlab-ci.ymlテンプレート、Runner、コンテナレジストリ、Artifactsとログ
  • デプロイ：開発・検証・本番環境へのリリースとロールバック
  • 統制と安全性：マージ承認、Protected Branch・Protected Environment、秘密情報、脆弱性スキャン、監査証跡

これらは実運用に欠かせないため、パイプライン設定だけを依頼範囲にすると、運用に必要な部分が範囲から漏れてしまいます。

GitLab.com・Self-Managed・Dedicatedの提供形態

提供形態によって委託先に求めるインフラ技術と運用責任が変わるため、形態ごとの管理範囲を先に比べておきます。

  • GitLab.com：GitLab側がホスティングするSaaSで、初期構築と更新の負担を抑えやすい形態
  • Self-Managed：自社クラウドやデータセンターに構築し、データ、ネットワーク、Runner、バージョンを自社で管理
  • Dedicated：単一テナント型のマネージドサービスで、データ所在地や分離性を重視する企業が検討しやすい形態

GitLab CIの発注形態の選び方

発注形態は、社内の運用人材、移行対象の数、本番環境の責任者を基準に決めます。設定だけを外注して運用設計が抜けると、導入後に社内の負担が増えることがあります。

一括外注が向いている企業

専任チームがなく、Self-ManagedやKubernetesを含む環境を短期間で整えたい企業には、一括外注が適しています。依頼できる工程を、次の区分ごとにまとめて確かめます。

  • 設計と構築：現状調査、アーキテクチャ設計、Runner構築、パイプライン標準化
  • 移行と定着：GitLab契約支援、既存ツールからの移行、教育
  • 継続支援：保守と運用支援

本番承認、秘密情報の管理、障害時の判断は、丸投げしてはいけません。そのため、委託する作業と社内に残す判断を、RFPと契約書で分けて書きます。

社内に技術者がいる場合の部分外注

社内に開発者やインフラ担当者がいるなら、要件定義と運用方針は自社で決め、難易度の高い部分を専門会社へ依頼できます。

  • 委託する作業：Runner構築、Jenkins移行、セキュリティスキャン、テンプレート整備
  • 社内に残るもの：内製の知識を保ち、不足する専門性を短期間で補える

ただし、担当会社が作ったパイプラインの理由を社内が理解できていないと、小さな変更にも再委託が必要になります。

納品物として、設計書、設定一覧、変数の用途、障害対応手順、教育記録を受け取ります。さらに、社内担当者が変更できる状態も受入条件に加えます。

マネージドサービスによる継続運用

導入後も運用作業が続くなら、MSP型の継続支援を検討します。GitLabは2026年2月にMSPプログラムを発表し、次の支援範囲を示しています（出典: GitLab公式「GitLabマネージドサービスプロバイダー（MSP）パートナープログラム」、2026年）。

  • 定期運用：GitLabのアップグレード、Runnerのパッチ、容量監視、証明書更新
  • 障害・安全対応：失敗ジョブの調査、脆弱性対応

見積を比べるときは、単発で構築する会社か、SLAとエスカレーションを備えて運用まで担う会社かを、分けて見ます。

ポイント

一括外注と部分外注のどちらを選ぶかは、社内に技術者がいるか、本番運用を社内で持つかで決まります。運用の判断まで外に任せると、社内で変更できず再委託が必要になるおそれがあります。

RFPと要件整理で決める事項

RFPで整理する開発状況、運用実績、既存ツール、目標を4枚のパネルで示した図。
現状の記録と目標指標を分けて並べています。

RFPは、各社の提案を同じ条件で見比べるための書類です。そのため、現状課題や対象範囲、納品物、責任分界を一つの文書にそろえて書いておきます。YAMLの細部を書き込むより、成果と条件を明確にしておくほうが、提案の違いを比べやすくなります。

リポジトリと運用負荷の現状調査の項目

直近1〜3か月の実績を、可能な範囲で数字にまとめ、現状と目標を分けて記録します。

  • 開発状況：リポジトリ数、サービス数、利用言語、ビルド時間、テスト種別、デプロイ先
  • 運用実績：リリース頻度、失敗率、復旧方法、失敗原因の調査時間、アップグレード工数
  • 既存ツール：Jenkinsなどのジョブ、認証情報、スケジュール、Artifacts、通知先、担当者

目標には、DORA指標を使えます。ビルド時間、デプロイ頻度、変更リードタイムに、変更失敗率や平均復旧時間を加えた指標が候補になります。

数字の改善そのものが目的になると、テストを省くなどの逆効果が起こりえます。そのため、速度と品質、安全性と運用工数のバランスを評価指標にします。

目標環境と技術要件の書き方

RFPには、候補環境とセキュリティ要件を分けて明記します。加えて、Runnerの設計と見積に影響する条件を伝えます。

  • 環境要件：利用形態とインフラ条件を指定
  • 実行要件：コンテナ、Kubernetes、オンプレミス試験の有無を整理
  • 安全要件：権限分離、スキャン、SBOM、監査の要件を定義

環境の候補は、GitLab.com、Self-Managed、Dedicatedです。RFPには、クラウドかデータセンターか、リージョン、ネットワーク接続を記載します。さらに、SSO、バックアップ、可用性、ログ保存期間の条件も書き添えます。

RFPの安全要件には、Protected Environmentと本番承認の分離を含めます。また、Runnerのタグ・実行基盤の分離と最小権限も入れます。

スキャン要件には、Secret DetectionとSASTを含めます。依存関係、コンテナ、IaCのスキャンに加え、SBOMと監査ログも入れます。GitLab公式も、秘密情報の保護、通信の暗号化、十分なログ保存を推奨しています（出典: GitLab公式「Hardening – CI/CD Recommendations」、2026年8月確認）。

納品物と受入条件の定義

GitLab上の設定だけを納品してもらうと、自社資産と委託先のノウハウの境界が曖昧になります。そのため、納品物と動作確認の条件を具体的に決めておきます。

  • 設定・構成：GitLab設定、.gitlab-ci.yml、共通テンプレート、IaC、Runner、環境変数・権限一覧、セキュリティ設定
  • 運用資料：移行対応表、テスト結果、監視設計、バックアップ・復旧手順、運用マニュアル、教育資料
  • 受入確認：対象リポジトリでBuild・Test・Security Scanが成功する
  • 動作確認：承認付きStagingデプロイ、権限分離、原因追跡、ロールバック実演ができる

教育は説明会だけで終わらせず、社内担当者が小さな変更と障害対応を実際に行う実技で評価します。そうすると、教育の内容が社内に定着します。

ポイント

RFPでは、現状や目標、制約、納品物、受入条件をそろえ、各社の提案を同じ条件で比べます。YAMLの細部よりも、成果と条件を明確にしておくと迷いにくくなります。

GitLab CIの外注契約の形態

契約は、納品物を明確に決められるか、調査に不確定な要素が多いか、運用を続けるかで選びます。

既存アプリやクラウド、ネットワーク、テスト品質に左右される部分が大きいため、全工程を固定価格にすると、前提が変わったときに揉めることがあります。

成果物と受入条件を固めてから使う請負契約

請負は、納品物を納期までに完成させ、検査と受入を行う案件に向いています。範囲と完了条件を挙げられる段階で使うと、扱いやすい契約です。

  • 適した作業：PoC後の標準テンプレート構築、対象リポジトリの移行、Runner環境の構築
  • 契約で定める事項：仕様変更、追加費用の算定、検収期間、瑕疵対応の期間

リポジトリの品質や本番要件がまだ分からない段階で、調査や設計まで請負に含めると、委託先がリスクを価格に上乗せしやすくなります。

現状調査は準委任か時間単価で行い、納品物と実装範囲が決まってから請負へ移る二段階契約も選択肢になります。

調査・伴走・運用支援に向いた準委任契約

準委任は、専門家が合意した業務を遂行することに重きを置く形態です。対象や対応内容が変わる業務に合う契約です。

  • 対象業務：現状調査、要件整理、アーキテクチャ検討、社内教育、障害解析、継続的なパイプライン改善
  • 定める条件：作業時間、稼働する役割、定例会、報告内容、対応時間帯

準委任は完成を保証するものではないと、発注側も理解しておく必要があります。運用保守では、月次稼働時間に加えて、重大障害の一次応答とエスカレーション先を定めます。さらに、脆弱性対応の期限、アップグレード方針、バックアップ復旧の責任者も決めておきます。

MSP型の契約では、構築費と月額運用費、ライセンス費、クラウド費を分けて書き、更新時に変動する項目を確かめます。

納品物の権利と再委託の条件

契約が終わった後に内製化するか委託先を変えるかに備えて、権利と引渡し条件を決めておきます。

  • 対象の納品物：.gitlab-ci.yml、共通テンプレート、Runner設定、IaC、スクリプト、設計書、運用手順書
  • 契約条件：著作権移転、利用許諾、第三者OSSの表示、契約終了後の引渡し
  • 終了時の処理：認証情報の削除、バックアップの消去

再委託がある場合は、会社名か範囲、アクセスできるデータを確かめます。加えて、秘密保持、事故時の責任、海外拠点へのデータ移転も見ます。

Self-Managedの管理者権限や本番クラウドの認証情報を複数社が持つ場合は、RFPで権限期限、操作ログ、緊急停止手順を質問します。

GitLab CIのシステム外注費用の相場

小規模PoC、標準導入、全社DevSecOps基盤について、本文記載の初期費用の推定レンジを横棒で比較した図。
導入範囲が広がるにつれて推定額の幅も大きくなります。

GitLab CIの国内受託費用を網羅した公的な相場表は、確認できません。

次の金額は、リサーチノートにある業務システムの人月単価と工程配分、導入範囲をもとにした推定です。ライセンス、導入支援、クラウドとRunner、保守は分けて見積もります。

100万円から5,000万円以上までの初期導入費の幅

初期費用は、対象数や環境、移行の難易度によって変わります。次に挙げる金額は、いずれも確定価格ではなく推定レンジです。

  • 小規模PoC：100万〜300万円程度
  • 標準導入：300万〜1,000万円程度
  • 全社DevSecOps基盤：1,000万〜5,000万円以上の可能性

小規模PoCは、1〜3サービスが対象です。GitLab.comか小規模なSelf-Managedを使い、Build・Test、1環境へのデプロイ、基本教育までを含めます。

標準導入には、Jenkinsの移行、複数チームの標準化、Runnerの冗長化が含まれます。加えて、複数環境の権限設計と運用手順も入ります。

全社基盤では、多数のリポジトリやKubernetes、SSOが対象になる場合があります。さらに、監査やSBOM、セキュリティポリシー、複数クラウドやオンプレミスとの連携も含まれることがあります。

金額は、対象数、既存資産の品質、環境数によって決まる推定レンジです。移行の難易度や教育、保守の有無も、金額に影響します。

期間の目安は、標準導入が3〜6か月、全社展開が6〜12か月以上です。段階に分けて発注すると、予算の精度を上げやすくなります。

ライセンス・基盤・Runnerの費用の内訳

ライセンス料金は、プラン、Compute枠、実行環境ごとの条件を確かめます。

  • 契約料金：契約形式とユーザー数
  • Compute枠：付属分と追加利用の料金
  • 基盤費用：環境とRunnerの構成
  • 見積項目：ライセンスから教育・保守までの区分

GitLab公式のPricingを2026年8月に確認しました。GitLab.com Freeは0ドルです。さらに、Premiumは年契約で1ユーザーあたり月29ドル、Ultimateは個別見積です（出典: GitLab公式「Pricing」、2026年8月確認）。

Premiumには月10,000コンピュート分、Ultimateには月50,000コンピュート分が含まれます。また、追加Computeは1,000分10ドル、GitLab Creditは1クレジット1ドルと表示されています。

実際の支払額は、為替や税、ユーザー数、利用量で変わります。販売パートナー経由の条件でも変わるため、公式の表示だけで年間の総額は断定できません。

Self-ManagedではGitLabの契約に加えて、仮想マシン、Kubernetes、データベースの費用が発生します。さらに、バックアップやログ保管、ネットワーク、監視、Runner実行基盤にも費用がかかります。

GitLab.comでも、自前のRunnerを使うか共有Runnerを使うかで、Compute消費とクラウド費の構造が変わります。見積書では、ライセンスと構築、移行を分けて書きます。クラウドやRunner、監視、保守、教育の費用も、同じように分けて示します。

初期開発費の15〜25％程度と推定する保守費

保守・運用費は、初期開発費の年15〜25％程度と推定する方法があります。ただし、これは公定相場ではなく、リサーチノートに基づく計画上の目安です。

PoCでは、金額の安さだけで決めず、次の指標を測って続行を判断します。

  • 保守範囲：月次定例・問い合わせか24時間監視まで含むかで変わる
  • 対応内容：障害・脆弱性対応、更新、パイプライン改善
  • 移行方法：全件を一度に移行せず、代表的な1〜3サービスのPoC後に横展開
  • 続行判断：ビルド、調査、デプロイ、変更失敗、復旧、社内工数を測る

ポイント

費用は、ライセンス、導入支援、クラウドとRunner、保守に分けて見積もると比べやすくなります。金額は導入範囲で大きく変わるため、本記事の数字は推定レンジとして見るのが妥当です。

GitLab CIの委託先選定と見積比較の観点

委託先の技術力、見積の比較条件、対応時間、引継ぎを確認する4枚のチェックカード図。
提案書の金額以外も同じ観点で照合できます。

委託先は、販売資格の有無だけでなく、パイプラインを設計・移行・運用できるかで選びます。

販売会社や総合SIer、GitLab専任の技術会社、クラウド運用会社では、得意な領域が異なります。そのため、納品物と責任範囲をそろえて比べます。

設定例と障害対応による技術力の確認

匿名化したサンプルでも構わないので、設計例と障害対応の説明を求めます。

YAMLを書けるかだけでなく、リポジトリ間で標準化し、安全に変更を広げる仕組みを確かめます。

  • 構成例：共通CIテンプレート、include、needsによる依存関係、キャッシュ、並列実行
  • リリース例：環境別デプロイ、手動承認、ロールバック
  • 質問例：Runner遅延の計測、秘密情報漏えい時の停止、Jenkins資格情報の移行、本番承認、Kubernetes障害時の切り戻し

回答に、調査手順、判断基準、担当者、記録方法まで含まれていると、実務への対応力を評価しやすくなります。

作業・前提・除外範囲を同じ表で比べる見積書

各社の合計額だけでなく、作業と条件を同じ単位にそろえて比べます。

  • 作業行：現状調査、要件定義、設計、環境・Runner構築、CIテンプレート、セキュリティ設定、移行、テスト、教育、運用引継ぎ
  • 比較条件：対象リポジトリ数、環境数、担当ロール、工数、納品物、検収方法、前提条件、除外作業

極端に安い見積では、既存資産の洗い出しやテストデータ、クラウドとライセンスの費用が除外されていないか確かめます。脆弱性対応や説明、文書、導入後の問い合わせも同様に見ます。

高い見積でも、全社展開を一括で計上しているだけなら、PoCと標準化を分けて比べられる場合があります。

体制・SLA・引継ぎの確認

営業担当に加えて、実際に設計と構築を担うリーダーを確かめます。さらに、Runnerやクラウドの担当者、セキュリティ担当者、運用窓口も確認します。

  • 体制：再委託先、担当交代の方法
  • 対応時間：問い合わせ受付、重大障害の一次応答、エスカレーション、夜間対応の有無

代表的なリポジトリを使う短いPoCや、設計ワークショップも選択肢になります。納品物の読みやすさ、リスクの指摘、社内への説明を見ます。想定外の失敗への対応も見ると、提案書だけでは分かりにくい相性と実力が見えてきます。

ポイント

委託先は、作業・前提・除外範囲を同じ単位でそろえた見積書で比べると、金額差の理由が見えてきます。技術力は、設定例と障害対応への答えで確かめます。

GitLab CIの発注から導入・運用開始までの流れ

候補会社には同じ情報を渡して比べ、PoCで検証してから段階的に移行します。納品後に社内で直せない状態を避けるため、各段階の出口条件を決めておきます。

候補会社の選定と契約の準備

決裁者と開発責任者に加え、インフラ・セキュリティ担当者や調達・法務担当者を、初期段階から集めます。RFPと質疑の条件をそろえたうえで、各社を比べます。

  • RFPの記載：現状課題、対象範囲、制約、期待効果を書き、希望時期や予算の考え方、質問期限、提案書の形式も示す
  • 説明会と質疑：各社に同じ説明会と質疑応答を行う
  • 契約書類の準備：選定後は、契約書と個別仕様書、作業計画、体制図をそろえ、連絡先とアクセス権限も用意する
  • 契約条件：秘密保持、再委託、納品物の権利を定め、検収、変更管理、保守SLAも決める

ライセンスの販売会社と構築会社が別々の場合は、障害時の一次窓口と責任分界を図にしておくと、切り分けが早くなります。

PoCと段階移行

技術面と業務面で代表性があり、失敗時の影響を抑えられる1〜3サービスから検証を始めます。PoCのあとは、標準を文書にまとめ、リスクの低いサービスから移行します。

  • 検証：Build、単体テスト、脆弱性スキャンを行い、Review AppかStagingにデプロイして、本番相当の承認とロールバックを確かめる
  • 運用性の確認：実行時間とログの追跡性、権限設定、失敗時の復旧を確かめる
  • 標準化：テンプレートと命名規則、Runnerタグ、変数管理を標準化し、ブランチ戦略、承認ルール、環境作成手順もそろえる
  • 並行稼働と切り替え：Jenkinsとの並行稼働期間を設け、全件を切り替える前に、納品物、通知、デプロイ、監査ログ、切り戻しを確かめる

運用引継ぎとKPI測定による導入効果の確認

運用開始の前に、保守や統制の作業を誰が担うかを決めます。そのうえで、社内へ移すときは、委託先の作業を横で見ながら、社内の担当者が同じ手順を実行できるかを確かめます。

  • 保守作業：Runnerパッチ、GitLab更新、バックアップ、容量監視、証明書更新、脆弱性対応
  • 統制作業：アクセス権の洗い出し、ログの保管・削除、障害時の切り戻し

導入の前後で、ビルド待機時間、デプロイ頻度、変更リードタイムを比べます。さらに、変更失敗率、復旧時間、失敗ジョブの調査時間、ツールの保守工数も比べます。

GitLab公式のAgoda事例では、ビルド待機時間が98%以上短縮され、開発者の作業時間は四半期で3,000時間削減、満足度スコアは17%向上したと紹介されています（出典: GitLab公式「Agoda」、2026年8月確認）。

これはAgoda社の結果で、自社の効果を保証するものではありません。ツールの統合だけでなく、標準化と教育、運用改善が組み合わさった成果として読むのが適切です。

ポイント

進め方で迷ったら、各段階を次へ進めてよい条件が決まっているかを確かめます。出口条件がないまま進むと、納品後に社内で直せない状態になるおそれがあります。

GitLab CIのシステム発注・外注に関するよくある質問

発注前には、導入費用だけでなく、社内に残す責任と導入後の運用も確かめておきます。

GitLab CIのシステムは内製と外注のどちらがよいですか？

GitLab、クラウド、安全性、運用設計の経験者が社内にいて、小さく始められるなら、内製も可能です。

Jenkinsの移行、Self-Managed、Kubernetesが重なる場合や、本番権限と監査要件まで絡む場合は、初期設計と難所を外注し、社内へ引き継ぐ方法が現実的です。

技術者の有無だけでなく、導入後に誰が更新と障害対応を担うかで判断します。

GitLab CIの外注費用を見積もるときの最低限の情報は何ですか？

リポジトリやサービスの数、Jenkinsなどの利用ツール、デプロイ環境を伝えます。加えて、GitLab.com・Self-Managed・Dedicatedの希望、対象チーム数、テスト種別も必要です。

セキュリティや監査の要件、希望時期、導入後の保守範囲も共有します。未確定の項目を明記しておけば、調査フェーズを含む提案を受けられます。

GitLab CIを外注するときセキュリティで何を確認しますか？

秘密情報の扱いと本番承認、Runnerの分離を確かめます。通信の暗号化と監査ログも確かめ、要件はRFPと契約に明記します。

  • スキャンと記録：SAST、依存関係・コンテナ・IaCスキャン、SBOM
  • 運用条件：脆弱性の修正期限、Artifacts保存期間、再委託先のアクセス範囲、事故時の報告手順

GitLab CIの外注前にPoCを依頼するべきですか？

対象環境や移行に不確定な要素が多い場合は、PoCを依頼する価値があります。代表的なサービスでBuildとTest、Security Scanを試し、Stagingへのデプロイ、承認、ロールバックまで確認します。

設定例に加えて、実行時間、失敗時の調査、社内への引き継ぎやすさを評価します。そのうえで、納品物と本導入へ進む条件を、最初の見積書に記載してもらいます。

まとめ

発注で押さえる範囲・費用・責任分界

発注前には、範囲と要件、費用を確かめます。契約と引き継ぎの条件も、同じ時点で確かめておきます。

  • 発注範囲：提供形態やRunnerの設計から、移行、安全性、デプロイ、監査、保守まで含める
  • RFP：現状を洗い出したうえで、目標、制約、納品物、受入条件、責任分界をそろえる
  • 推定費用：1〜3サービスPoC 100万〜300万円、標準300万〜1,000万円、全社1,000万〜5,000万円以上
  • 内訳：ライセンス、導入支援、クラウド、Runner、保守を分ける
  • 契約と引継ぎ：請負・準委任、段階移行、設定と運用手順を引き渡す

小さなPoCから始める社内の運用知識づくり

委託先を比べるときは、価格の差より、同じ質問に対する答えの差に目を向けます。Jenkins移行、共通テンプレート、クラウドやKubernetesへの対応は、どの会社にも同じ質問で聞きます。安全性と障害対応、教育、SLA、再委託体制についても、答えを並べて比べます。

  • 安全性と障害対応
  • 教育
  • SLA
  • 再委託体制

開発速度だけでなく、変更失敗率、復旧時間、運用工数、監査可能性を継続して測ります。そのうえで、導入後も改善できる開発基盤として育てます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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