CI/CDツール開発の発注/外注/依頼/委託方法について

CI/CDツールの発注では、まず現状と要件を整理し、代表的なサービスでPoCを行ってから範囲を決めて本番展開します。この流れで進めると、失敗と予算のぶれを抑えやすくなります。

依頼範囲から委託先の選び方まで、順に見ていきます。全体像はCI/CDツール開発の完全ガイドもご覧ください。

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

CI/CDツールの発注・外注で依頼する作業範囲

CI/CDツールの外注範囲は、初期設定から要件定義、設計、移行、運用教育まで広がります。そのため、発注前に何を作るかだけでなく、誰が運用するか、納品後に自社でどこまで変更するかも決めておく必要があります。

外注する作業範囲の切り分け

外注範囲は、設計から既存基盤の移行、納品後の運用支援まで、必要な作業を具体化して決めます。作業の中身が曖昧なままだと、どこまでを委託先が受け持つかで食い違いが生じやすくなります。依頼の対象は、設計、自動化、運用基盤、既存資産の整理、クラウド連携の5つの領域に分かれます。

設計：現状調査、ツール選定、基本設計、ネットワークや認証の設計
自動化：Git連携、ビルド、単体・結合・E2Eテスト、デプロイ、承認フロー
運用基盤：成果物保管、Secrets管理、監査ログ、ロールバック、手順書作成
既存資産の整理：JenkinsジョブのGit管理、各種CI/CDサービスへの移行
クラウド連携：AWS CodePipelineとCodeBuildなど、既存サービスの接続

社内の品質基準や障害時の判断、機密データの扱いは、リリース承認者とあわせて発注者が決める事項です。これらは社内の判断に関わるため、RFPで担当を分けます。そのうえで、最終承認者は発注者側に置きます。

本番自動デプロイだけをゴールにしない考え方

CIは、共有ブランチへの統合時にビルドやテストを実行する仕組みです。CDは、検証済みの成果物をリリース可能な状態に保ち、承認後に環境へ反映する仕組みを指します。

承認なしで本番へ自動反映する方法は継続的デプロイメントと呼びます。ただし、業務システムでは初期段階からそこを目指す必要はありません。

自動化は次の順に広げると、テスト不足や環境差異を確かめながら投資を進められます。

プルリクエストごとのビルドとテストの自動化
検証環境への自動デプロイ
承認を付けた本番環境へのデプロイ

導入前にデプロイ頻度、変更リードタイム、変更失敗率、復旧時間を測っておき、導入後に同じ指標を比べて効果を確かめます。

ポイント

外注範囲は設計から運用教育まで広がるため、作業の切り分け、運用の担当、納品後の変更範囲を発注前に決めておくと、委託先との食い違いを減らせます。

CI/CDツールの発注形態の選び方

発注形態は大きく、SaaSを導入する形、OSSやセルフホスト環境を構築する形、複数製品を組み合わせた専用基盤の形に分かれます。

形態を選ぶときは、機能の数だけでなく、データの所在や運用体制も見ます。閉域網への接続、監査要件、将来の移行しやすさも判断材料になります。そのうえで、社内の要員が担える運用負担と合わせて比べます。

SaaS・クラウド導入型の特徴と利用料の確認

SaaS・クラウド導入型では、サービスごとの運用負担と課金条件を比べます。候補にはGitHub Actions、GitLab CI/CD、Azure Pipelines、CircleCIがあり、導入型の特徴は、導入の速さや一体運用といった利点と、利用料が条件によって変わる点にあります。

導入の速さ：サーバー構築や更新を抱えず標準パイプラインを始めやすい
一体運用：同じサービス群なら権限や通知をまとめて設計できる
専任者不在時：導入支援会社にテンプレートと運用手順の作成を頼める
利用料：ユーザー数、実行時間、Runner、同時実行数、成果物ストレージ、ログ保管、追加のセキュリティ機能で変動する

たとえば、GitHubの公式料金ページでは、Teamは1ユーザー月額4米ドル、Enterpriseは同21米ドルです。Actionsの無料枠も、プランにより月2,000分、3,000分、50,000分と分かれています（出典: GitHub公式料金ページ、2026年8月確認）。

利用料の見積を比べるため、RFPには月間実行回数と平均実行時間を示します。見積は、ライセンスと従量課金を分けて出してもらいます。

セルフホスト・ハイブリッド型の制約と運用負担

セルフホストとハイブリッドは、接続の制約と継続運用の両面から、自社の条件に合うかを確かめます。

対応しやすい条件：閉域網、オンプレミスの基幹システム、社内認証、独自の承認ルール
運用負担：サーバーの可用性、Runnerのパッチ、プラグインの脆弱性、バックアップ、ログ保管、障害時の復旧
比較項目：データ所在、Secrets保管、OIDCなどの短期認証、Runnerの分離

自社で運用する選択肢には、JenkinsなどのOSSを使う方法があります。GitLab Self-ManagedやセルフホストRunnerも候補になります。いずれの場合も、可用性などの運用を発注者と委託先のどちらが担うかを明確にします。

ハイブリッド型では、ソースコード、ログ、成果物、実行環境の配置先をRFPに記載します。納品物には構成図のほか、移行、復旧、Runner追加の手順も含めます。

専用基盤の構築範囲と既製機能との差分

CI/CDツールをゼロから作るより、既製のSaaSやOSSを活かす方が現実的です。

専用開発は、社内標準テンプレートや承認アダプターなど必要な部分に絞ると、保守負担を抑えやすくなります。判断では、既製品をどこまで使うか、専用開発をどこに限るか、開発の境界、移行性を見ます。

既製品を活用：標準機能を使い、必要な差分だけを追加開発
専用開発：閉域、多段承認、特殊なデプロイなど、標準製品で満たせない要件に限る
開発の境界：標準機能、追加開発、将来の更新で影響を受ける箇所の切り分け
移行性：Pipeline as Codeを発注者のリポジトリで管理

成果物の所有権は契約に記載します。設定ファイルやテストコードなどを発注者側が持つと、ベンダーロックインを避けられます。

ポイント

形態は機能数だけでなく、データの所在、閉域網接続、監査要件、社内で担える運用負担を並べて選びます。将来の移行しやすさも、判断材料に加えます。

RFPと要件整理で決めておく事項

4項目の前提をそろえると、各社の提案を同じ条件で見比べられます。

RFPは、各社の提案を同じ条件で比べるための資料です。対象範囲や制約、期待効果を書いたうえで、納品物と評価方法も示します。

現状の説明が曖昧なままだと、各社の見積前提がずれます。その結果、選定後に追加費用が増えることがあります。

リポジトリと運用を対象にした現状の棚卸し

リポジトリの構成と手動リリースの流れを合わせて記録すると、自動化の範囲と実行環境の条件を判断できます。棚卸しでは、開発情報からテスト・実行、環境、リリース運用、接続・情報管理まで、5つの領域を押さえます。

開発情報：リポジトリ数、主要言語、ビルドツール、ブランチ戦略、Gitサービス
テスト・実行：テスト種別、テストデータ、月間リリース回数、1回の実行時間
環境：デプロイ先、環境数、接続先とネットワーク上の制約
リリース運用：承認者、操作画面、ログの場所、失敗時に戻す時点
接続・情報管理：オンプレミスDB、社内プロキシ、固定IP、ライセンスサーバー、秘密鍵、テスト用個人情報

手動リリースは時系列で書き出し、誰が承認し、どの画面で作業するかを記録します。あわせて、ログの保存場所と失敗時に戻す時点も確認します。

CI/CD環境から接続できる範囲と禁止する範囲は、ネットワーク図にまとめます。そのうえで、クラウドRunnerかセルフホストRunnerかを、これらの条件に基づいて選びます。

RFPのMUST・SHOULD・WANTの区分

要件は、導入に必須のMUST、できれば実現したいSHOULD、将来検討するWANTに分けます。MUSTには認証や承認、監査ログなど導入の前提になる要件が入り、SHOULDには並列実行や通知などの改善機能、WANTには将来の拡張が入ります。

MUST：指定クラウド・オンプレミスで動作、SSO・多要素認証、本番承認、実行履歴・監査ログの一定期間保管、失敗時の前回成果物への復元
SHOULD：並列実行、キャッシュ、通知、テスト集約、脆弱性検査、SCA・SAST・SBOM
WANT：チーム向けセルフサービス、テンプレート配布、DORA系指標のダッシュボード

優先度を分けておくと、初期導入と将来拡張の見積を切り離せます。そのため、予算の調整もしやすくなります。

セキュリティと監査要件の具体化

「セキュリティ対応」と書くだけでは、会社ごとに解釈が分かれてしまいます。そこで、必要な制御、運用担当、保管期間を次のとおり具体的に示します。

秘密情報：Secretsをログや成果物に出さない仕組み
検査：依存ライブラリ、SAST、コンテナ・IaCのスキャン、成果物の署名
権限：Runnerの分離、承認者と実行者の分離
監査・対応：ログ保管期間、アラート時の連絡先

NISTは2024年公開のSP 800-204Dで、CI/CDのDevSecOpsにサプライチェーン安全性を組み込む考え方を示しています。扱う範囲は認証・認可から成果物の完全性までで、ビルド環境や秘密情報、依存関係も含みます（出典: NIST SP 800-204D、2024年）。

EU市場へデジタル要素を持つ製品を出す場合は、EU Cyber Resilience Actの対象となる可能性があります。対象になれば、積極的に悪用された脆弱性や重大インシデントについて、認知後24時間以内の早期警告と72時間以内の通知などが定められています（出典: 欧州委員会CRA報告義務ページ、2026年7月更新）。

ただし、日本企業すべてに直接適用されるとは限りません。そのため、対象製品と販売地域を法務・セキュリティ部門で確認します。

ポイント

RFPには現状の棚卸し結果、MUST・SHOULD・WANTの区分、セキュリティと監査要件の具体的な中身を書き、各社が同じ前提で見積もれる状態にしておきます。

CI/CDツール開発の契約形態と請負・準委任の使い分け

要件の変わりやすさと受入条件の明確さが、契約を分ける目安です。

初期調査は要件が変わりやすい一方で、本番展開では納品条件を明確にできます。そこで、現状調査、PoC、本番展開、運用改善に段階を分け、各段階の成果物と継続条件を設定します。

準委任が向く調査・改善フェーズ

要件が固まりきらない段階では、作業を柔軟に変えられることと、進捗を追えることを契約に含めます。内容は、稼働時間への対価、検証の見直し、月次の報告、設計書やコードの保管の4つに分かれます。

契約の対象：稼働時間や役割に対価を払う形で、現状調査、ツール選定、PoC、改善、運用支援を依頼
柔軟な検証：対象リポジトリやテストの優先順位を、発注者と委託先で見直しながら進める
月次報告：作業時間だけでは成果が見えにくいため、目標、対象リポジトリ、テンプレート、テスト、残課題、次月の判断材料を共有
作業の再現性：担当者のスキルや稼働が変わる場合に備え、設計書やコードを発注者の環境へ随時保管

請負が向く、範囲と受入条件が固まった段階

請負は、合意した成果物を完成させて引き渡す契約です。そのため、納品範囲と変更管理を発注前に固めておきます。決めるのは、作業の種類、受入条件、運用の確認、変更管理の4点です。

適した作業：標準化したパイプライン、指定環境への展開、手順書と教育資料の納品
受入条件：対象ブランチからの実行、成功時の成果物生成、承認後デプロイ、失敗時の通知
運用確認：ロールバックとログ保管をテストケースに含める
変更管理：変更単価、納期への影響、追加受入テスト、第三者製品の仕様変更時の扱い（契約書と別紙で定める内容）

テストの追加や接続先の変更は起きやすいため、範囲を広げすぎると変更管理が複雑になります。

業務システム一般の傾向では、請負の見積が準委任より1.3〜1.5倍程度高くなる場合があります。ただし、これは案件条件による推定で、固定相場ではありません。

契約書に入れる所有権・移行・保守の条件

CI/CDはサービス運用中も使い続ける基盤です。そのため、契約書では次の項目を明確にします。

成果物：ソース、スクリプト、テンプレート、テストコード、設計書、構成情報、ログ
共通部品：複製・変更の範囲、第三者ライセンス表示、契約終了後の利用可否
保守：問い合わせ先、障害優先度、初動時間、復旧目標、夜間対応、脆弱性報告、メジャー更新
契約終了：データ返却・削除、移行支援、保守の追加費用条件

保守契約を分けて結ぶ場合も、追加費用の条件は見積書と契約書で一致させます。

ポイント

要件が変わりやすい段階は準委任、範囲と受入条件が固まった段階は請負が合っています。段階ごとに成果物と継続条件を決めておく必要があります。

CI/CDツールの外注費用相場とコストの内訳

導入範囲が広がるにつれて、見積レンジも段階的に大きくなります。

CI/CDの費用は、ツール利用料と導入・開発・運用の人件費に分けて考えます。公開価格だけで見積もると、Runnerやクラウド、ストレージの費用を見落としがちです。ログやセキュリティ、教育や保守も、同じように抜けやすくなります。

規模ごとの金額は、リサーチノートに基づく受託構築の推定レンジです。税や製品ライセンス、クラウド利用料、既存システム改修費は別途で、この推定には含まれません。

小規模PoCの費用目安（100万〜300万円）

小規模PoCは対象を絞って行うと、費用と期間の目安が立ち、本番展開の判断材料として使えます。PoCでは、対象、納品範囲、成功条件、安全性の4つを押さえておきます。

対象：1リポジトリ、1言語のビルドと単体テスト
納品範囲：検証環境へのデプロイと基本的な引き継ぎ
成功条件：変更検知、成果物作成、安全な配置、実行時間、失敗通知、ログ
安全性：Secretsの非表示、再実行、ロールバック

このPoCの目安は100万〜300万円、2〜6週間です。ただし、これは業務システム一般の人月単価を当てはめた推定で、CI/CD案件の一律の統計ではありません。

PoCの成果をテンプレート化しておけば、本番展開の見積を具体的に組み立てられます。

標準導入の費用の推定レンジ（300万〜800万円程度）

標準導入の費用幅は、対象環境と作業量によって変わります。見積では、対象、導入内容、費用変動の要因、見積明細、追加費用の比較の5点を確認します。

対象：複数リポジトリと開発・検証・ステージング・本番環境
導入内容：承認、Secrets、成果物管理、基本的な脆弱性検査、権限、手順、教育
費用変動：チーム数、共通テンプレート、例外処理、権限棚卸し、既存ルールとの調整
見積明細：共通基盤、ネットワーク、認証、テストデータ、移行、受入支援、教育
追加費用の比較：共通部分と個別差分を分けて、2本目以降の費用を判断

費用は300万〜800万円、期間は2〜4カ月程度の推定です。

大規模導入の費用幅（800万〜2,000万円以上）

大規模導入では、見積の前提と段階的な展開計画を合わせて見ます。確認するのは、対象範囲、費用と期間、費用増の要因、展開順、見積の確認の5点です。

対象範囲：オンプレミスとクラウド、Kubernetes、複数部署、閉域網、監査ログ、高可用性、Jenkins移行
費用と期間：教育・運用設計を含め800万〜2,000万円以上、6〜12カ月程度の推定
費用増要因：air-gapped環境、規制対応、複数リージョン、24時間監視、高度なテスト基盤で増額
展開順：標準アーキテクチャを決め、代表、優先、残りのシステムへ広げる
見積確認：移行不能なジョブ、別会社の監視、ライセンス更新の管理漏れを調べる

月額運用費の目安（10万〜100万円程度）

月額の運用保守費は、製品やインフラの利用料と分けて見積もります。費用例には、保守の規模ごとの目安と、AWS CodePipelineやCircleCIの利用料があります。

小規模保守：月10万〜30万円が推定目安
複数環境の保守：Runner保守、監視、障害対応、改善込みで月30万〜100万円
AWS CodePipeline：V1は稼働パイプライン1本で月1米ドル、V2は実行1分0.002米ドル
CircleCI：無料枠は月6,000ビルド分、Performanceは月15米ドルからで30,000クレジット込み

ライセンス費やクラウド費は別明細です。ログやRunnerのインフラ費も、別に見積もります。

保守費は、対応時間や対象リポジトリ数に加え、SLAや夜間・脆弱性対応でも変わります。

AWSはS3の成果物保存などが追加料金になる場合があります（出典: AWS CodePipeline公式料金ページ、2026年8月確認）。CircleCIの消費量はリソースクラスや同時実行数で変わります（出典: CircleCI公式料金ページ、2026年8月確認）。そのため、使用量の前提も見積に入れ、月額の利用料だけで判断しないようにします。

ポイント

規模ごとの推定レンジを目安にしたうえで、税やライセンス、クラウド利用料が別途かかるかを、見積の内訳で見分けます。周辺の費用も含めて比べると、予算のずれを抑えられます。

CI/CDツールの委託先選定と見積比較のポイント

委託先は、知名度や資格よりも、既存環境を調べてパイプラインを定着させる力で選びます。情報システムやセキュリティ、品質保証、運用の部門も関わるため、技術担当者と管理者の両方に確認します。

導入条件の近さで見る実績

自社に近い条件での導入実績は、提案が合うか、納品後に運用できるかを見極める材料になります。実績では、環境、運用、実績資料、引き渡しの4つを確かめます。

環境：クラウド、言語、データベース、ネットワーク制約
運用：リリース承認、監査要件、障害時の対応例
実績資料：匿名化した構成図、移行前後の課題、運用体制
引き渡し：発注者へ渡した成果物と教育内容

PoCの失敗基準や、YAMLやJenkinsfileの変更教育についても質問します。契約終了後の移行や仕様変更時の責任分界も、あわせて聞いておきます。導入を急ぐ場合ほど、納品後の運用と移行性を確かめておく必要があります。

前提条件・作業・成果物をそろえた見積比較

見積は合計額だけで比べず、まず各社の前提条件をそろえます。そのうえで、対象範囲と作業量を同じ項目で比べます。

規模：リポジトリ数、環境数、Runner、同時実行数、実行分数
作業：テスト種別、クラウド連携、移行、教育時間、検収回数
期間・保守：納期、保守期間、対応時間

安い見積は、テスト自動化や本番移行を含まない場合があります。見積は、現状調査、要件定義、設計、構築の工程を明細にします。テストや移行、文書、教育、管理も含めます。予備費と保守も、見積に明記します。

工数は人日か人月で示し、単価や担当ロール、期間、追加作業の条件も記載します。金額に幅がある場合は、低・標準・高の各ケースの条件を確かめます。

PoCと提案プレゼンによる実装力の確認

運用力は、提案書の内容だけでは見極めにくいため、PoCや提案の場で確かめます。可能なら代表アプリか匿名サンプルを使い、プルリクエストからテストと成果物の固定を経て、検証環境へのデプロイと承認後の本番相当環境への反映まで試します。

秘密情報がログに出ないか、失敗したジョブを再実行できるか、結果を見やすいかも確かめます。評価では、次の観点を見ます。

品質：可読性、実行時間、変更のしやすさ、文書
運用：障害切り分け、最小権限、監査証跡
引き継ぎ：自社担当者が設定内容を説明できるか

特定の担当者がいないと変更できない仕組みは、数カ月後に運用リスクになりかねません。

発注前に決める追加費用と運用リスクの管理方法

アプリや接続条件が変わると追加費用につながるため、対象範囲と環境上の制約を先に確認します。

対象の増加：アプリ、テスト、移行できない既存ジョブ
接続・性能：レガシー接続、閉域網申請、Runner性能不足
運用要件：ログ保管延長、夜間対応

追加対応は「必要に応じて対応」と書かず、単価、見積の提出時期、発注者の承認方法を決めておきます。

障害時の連絡経路や一次切り分け、ツール障害とアプリ障害の責任分界を合意します。脆弱性対応の期限やバックアップの復旧テストも、加えて決めます。

SaaSの停止や料金変更に備えて、パイプラインの定義と成果物は別の場所にも保存します。移行先の候補も、定期的に検証します。

GitHubは2025年末、ActionsのセルフホストRunnerへの新課金について、再評価するため延期しました。また、ホステッドRunner価格は2026年1月から最大39％引き下げると公表しています（出典: GitHub公式発表、2025年12月）。そのため、契約前と更新前に料金を見直します。

よくある質問（FAQ）

CI/CDツールの発注・外注について、よくある質問に答えます。費用や自社体制、契約に加えて、セキュリティや運用の観点からも回答します。

CI/CDツールの外注費用はどのくらいですか？

1リポジトリのPoCは100万〜300万円が推定レンジです。複数環境と承認・セキュリティを含む標準導入は、300万〜800万円が推定レンジです。

さらに、大規模移行や閉域・監査対応を含むと、800万〜2,000万円以上になる場合があります。

税やライセンス、クラウドの費用は別に考えます。既存システム改修や保守も別です。そのため、見積の前提条件と明細を確かめてください。

社内に専門人材がいなくても外注できますか？

外注は可能ですが、最終的な運用責任者と意思決定者は社内に置く必要があります。委託先から設計書とパイプラインコードを引き継ぎ、手順、教育、障害切り分け表も受け取ると、専門人材の採用前でも運用を始められます。

継続改善を準委任で頼むか、保守契約で支援を受けるかは、社内体制に合わせて決めます。

SaaSとセルフホストはどちらを選ぶべきですか？

短期の標準化とサーバー運用の軽減を優先する場合は、SaaSが向いています。一方で、閉域網やデータ所在、特殊認証に加えて、オンプレミス接続や細かな監査を優先する場合は、セルフホストやハイブリッドが候補になります。

セルフホストでは、パッチやバックアップ、可用性、Runner隔離を継続して管理します。また、初期費用に加えて、5年程度の運用負担も比べます。

RFPには最低限何を書けばよいですか？

RFPには、対象リポジトリ数、言語、ブランチ戦略、環境数、デプロイ先を記載します。実行回数と時間、同時実行数のほか、テスト、認証、Secrets、監査ログも含めます。

承認者と移行対象、納期に加えて、納品物と保守条件も記載します。

MUST・SHOULD・WANTに加えて、手動の手順や制約も添えると、各社の見積条件をそろえられます。

まとめ

発注前の要件・費用・責任分界のそろえ方

RFPに対象や環境、テスト、承認を書き、セキュリティと移行範囲も加えます。そうすると、各社が同じ前提で見積できる状態が整います。

PoC、本番展開、保守を段階に分け、作業範囲と受入条件を明確にすると、追加費用や責任分界のずれを抑えられます。

導入後の内製化と継続改善の設計

導入後も改善と引き継ぎを続けられるよう、確認する指標と社内で扱う成果物を決めておきます。取り組みは、効果測定、内製化、発注準備、委託先選定の4つに分けて進めます。

効果測定：デプロイ頻度、変更リードタイム、変更失敗率、復旧時間を測り、テストやテンプレートの改善につなげる
内製化：設計書やパイプラインコード、手順、教育の引き継ぎと、日常変更の自社対応
発注準備：現状の棚卸し、MUST・SHOULD・WANTの設定、形態ごとの制約と運用負担の比較
委託先選定：利用料や保守、教育、移行の切り分け、成果物の所有権と契約後の移行条件の確認

進め方の一例として、準委任で要件やPoCを詰め、請負で本番展開する方法があります。費用の推定レンジは、PoCが100万〜300万円、標準導入が300万〜800万円、大規模導入が800万〜2,000万円以上です。

▼全体ガイドの記事
・CI/CDツール開発の完全ガイド

▼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を創業。