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

Amazon DocumentDBのシステム開発は、発注要件、契約・費用、選定・手順の三つを押さえたうえで、要件を整理し、互換性をPoCで確かめ、段階的に開発を進めると要件に合いやすくなります。運用まで設計に含めることも欠かせません。

詳しい全体像は、完全ガイドにまとめています。

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

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

Amazon DocumentDBのシステムを発注・外注する前に知っておきたい全体像

Amazon DocumentDBは、MongoDB互換のAPIや開発ツールを使えるフルマネージド型のドキュメントデータベースです。JSON形式で項目の増減が多い業務データを扱う基盤の候補になります。

顧客プロフィール、商談、問い合わせ履歴、メール開封、Web行動などを扱うシステムで利用できます。ただし、MongoDBと完全に同じ動作になるとは限らないため、クエリとアプリの互換性検証も発注範囲に含めます。

DocumentDBを業務システムのデータ基盤に使う範囲

発注前に、DocumentDBに持たせる業務データと周辺システムの役割を整理しておきます。

• 業務データ：顧客情報や商談、営業履歴、行動イベントが対象です。
• アプリ構成：React、Node.js・Java・Python、Amazon Cognitoや既存IdPを組み合わせた構成です。
• 役割分担：顧客単位はDocumentDB、集計・マスタはRDB、検索・分析は別サービスが候補です。

業務単位のドキュメントは、顧客ごとの情報をまとめて持てるうえ、将来の項目追加にも対応しやすい構造です。

複雑な横断集計や厳格な会計トランザクションが中心の場合は、AuroraなどのRDBを併用するほうが適切なこともあります。DocumentDBの採用自体を目的にせず、業務要件から発注後の設計を決めます。

MongoDB互換の意味と検証範囲

MongoDBから移す場合は、見積の前に互換性の検証範囲を具体的に決めておきます。

• 互換性の確認：演算子、集計、トランザクション、索引、ツール、接続が対象です。
• クエリの分類：実行可能、書き換えが必要、別ストアへ移行に分けます。
• 検証成果物：チェックリスト、実行結果、性能条件、未対応機能の代替案を提出してもらいます。
• RFPの条件：検索条件、集計頻度、接続数、データ量、許容時間を示します。

既存のクエリはPoCで検証します。ただし、MongoDB用ドライバーを再利用できる場合でも、完全に同じ動作になるとは限りません。

互換性を確かめないまま本番の見積を取ると、後からアプリ改修やテストが増えやすくなります。

発注形態の選び方

発注形態は、業務の標準度と独自ロジックの必要性で選びます。社内に残す技術知識、利用開始までの期間、将来の保守体制も合わせて判断します。

標準的な顧客管理を早く始めたい場合は、SaaSやパッケージが候補になります。一方で、既存システムとの連携や独自イベント処理が競争力に直結する場合は、アドオン開発またはスクラッチ開発が候補です。

SaaS・パッケージを中心にDocumentDBを限定利用する形態

標準機能を使う発注では、独自開発として残す領域を見極めます。

• 標準機能：SaaSやパッケージを中心に据え、DocumentDBは独自イベントや連携に限って使います。
• 導入負担：標準機能を広く使うほど開発と保守の負担を抑えられ、利用者も操作に早く慣れられます。
• 製品条件：API上限、エクスポート範囲、契約終了時の返却を確かめます。料金改定と個別開発の扱いも見ます。
• 見積項目：利用料、初期設定、連携開発、移行、運用支援を分けてもらいます。

DocumentDBとSaaSのどちらをデータの正本にするかを決めておかないと、二重入力や不整合が起きます。

AWS標準サービスを組み合わせたクラウドネイティブ開発

AWS構成は、処理の特性と、稼働後に誰が運用を担うかを踏まえて決めます。

• 基盤構成：DocumentDBを中心に、VPC、ECSまたはLambda、SQS、S3などを組み合わせます。
• 処理特性：変動の大きいイベント処理はServerlessやLambda、安定した画面はコンテナが候補です。
• 運用設計：ネットワーク、認証、監視、バックアップ、障害対応をまとめて発注できます。

構成要素には、CloudWatch、Secrets Manager、KMSなども含めます。

AWSは2026年5月、DocumentDB 8.0でServerlessが利用可能になったと発表しています（出典：AWS「Amazon DocumentDB Serverless is now available on DocumentDB 8.0」、2026年5月）。

この機能は、需要に応じて容量を自動で調整し、ピーク容量を常時確保する場合と比べて最大90％の削減をうたっています。ただし、利用可否はエンジン版、リージョン、最低・最大DCU、ワークロードで変わるため、実測で試算します。

フルスクラッチと段階発注の組み合わせ

発注前に、独自要件の実現範囲と、次の開発へ進むための判断条件を整理します。

• スクラッチの条件：顧客データ、商談、イベント、権限、基幹連携が競争力に関わる場合に検討します。
• 長期管理：要件定義、互換性、試験、人材、更新、ベンダー交代を長く管理します。
• 発注段階：調査・要件定義からPoC、代表部署のMVP、本番展開へと分けて発注します。
• 次工程の条件：代表データ移行、許容時間内の主要検索、権限、バックアップが確認条件です。

フルスクラッチであれば、業務に合わせた独自仕様を実現しやすくなります。

RFPと要件整理に盛り込む内容

RFPは、機能一覧に加えて、現状課題、対象ユーザー、データ量を同じ条件で伝える文書です。そのうえで、連携条件と非機能要件、成果指標を示します。予算と日程も含めます。

理想と現状を分けて、現在の手作業や例外処理を記しておくと、提案と見積の前提がそろいます。

業務フローとデータ項目の整理

現場の手順は、顧客登録、名寄せ、担当変更、商談作成、活動記録、問い合わせを図にします。さらに、メール配信、スコアリング、失注・解約、再アプローチも、現場の流れどおりに描きます。そのうえで、各工程の作業者、更新データ、更新時点、連携先を明確にします。

データは、顧客、企業、担当者、案件を中心に分類します。活動、行動イベント、商品、契約なども、同じ考え方で分けます。その際、将来の属性追加を見込みつつ、検索・集計項目の型、必須条件、許容値、更新者を定義します。

個人情報や機密情報は項目ごとに区分し、その区分ごとに保持期限、削除方法、マスキング、閲覧可能な役職を要件に含めます。

RFPに書くMongoDB互換性と性能のPoC条件

PoCの対象と合格条件をRFPでそろえておくと、各社の提案を同じ基準で比べられます。

• 機能試験：CRUD、複合検索、集計、ソート、ページング、同時更新を検証します。
• 移行試験：既存クエリや索引、ドライバー、バッチ、データ量、日次増分量が対象です。
• 性能条件：ピーク時の同時接続、秒間の読み書き、検索結果件数、許容応答時間を設定します。
• 測定項目：CPU、メモリ、I/O、クエリ時間、エラー率を、自社データを使って記録します。

バックアップ・復元、障害切り替え、監視もPoCで検証します。そのうえで、機能の可否と書き換えにかかる工数を記録しておきます。

PoCでは、データ量が増えた後も、代表ユーザーの一連の操作を再現して性能を確かめます。

発注範囲に含めるセキュリティ・可用性・運用条件

セキュリティ、可用性、運用の条件を、発注範囲に含めて整理します。

• セキュリティ：プライベートサブネット、セキュリティグループ、TLS、KMSによる保存時暗号化、IAMの最小権限を定めます。
• 権限・復元：管理者と営業の権限分離、監査ログ、バックアップと復元試験。
• 可用性：RTO（目標復旧時間）、RPO（目標復旧時点）、保守時間、障害通知、切り戻し、不整合時の照合を決めます。
• 運用・納品：アラート担当、増減条件、バックアップ確認頻度、障害後の報告、設計書・IaC・ソース等を取り決めます。

AWSの機能を使っても、個人情報保護法や社内規程への適合が自動で済むわけではありません。そのため、納品範囲にはテスト結果と運用手順書も含めます。

契約形態の選び方と発注後の管理事項

要件が固まった開発は請負、調査・要件定義・PoC・アジャイルの初期は準委任、稼働後の監視や改修は保守契約に分けるのが一般的です。そのうえで、工程ごとに成果物と作業責任を明確にします。

工程ごとの請負契約と準委任契約の使い分け

請負契約は成果物の完成と検収を重視するため、画面、API、移行ツール、テスト結果などの完成物と受入基準を定められる工程に向きます。

互換性検証を含む場合は、対応クエリ、未対応機能の扱い、性能基準、再試験条件を検収項目にします。一方で、準委任契約は、専門家の作業や支援を受ける契約です。

現状調査、要件定義、PoC、技術調査、優先順位の見直しが多い段階では、準委任が合う場合があります。また、会議体、報告書、検証結果、意思決定事項も合意しておきます。

契約書で確認する成果物・権利・変更管理・再委託

契約書に記す内容と、変更管理の進め方を整理しておきます。

• 成果物・検収：成果物と検収基準を確かめます。
• 権利・情報：知的財産権、第三者ソフトのライセンス、秘密情報、個人情報、再委託が対象です。
• 責任・返却：障害時の責任分界と、契約終了時のデータ返却。
• アカウント：DocumentDBクラスターやAWSアカウントの保有者、請求先、アクセス権の削除時期を決めます。
• 変更管理：口頭の依頼は、理由、影響、追加工数、納期、費用、テスト範囲を記録・承認したうえで進めます。

データモデルやインデックスの変更は、アプリ画面だけでなく、移行、性能、バックアップ、運用監視にも影響します。そのため、月次定例で課題、リスク、判断待ち、予算消化、次の承認事項を確認します。

監視だけでなく改善とアップグレードを含む保守契約

保守の見積では、稼働後に必要になる更新や対応が契約範囲に入っているかを確かめます。

• 保守範囲：監視、問い合わせ、障害、バックアップ、脆弱性を含みます。月次報告と軽微な改修は、別に分けて書きます。
• 更新作業：エンジン、ドライバー、周辺ライブラリの互換性試験も含めます。
• 費用条件：定期保守に含む更新と、別途見積もる更新を明確にします。

DocumentDB 5.0には長期サポートがあり、重要な安定性・セキュリティ修正を受ける選択肢になります（出典：AWS「Amazon DocumentDB long-term support on 5.0」、2026年2月）。

これに対し、DocumentDB 3.6は2026年3月30日に標準サポートが終了し、一定期間のExtended Supportには追加料金がかかります（出典：AWS「Amazon DocumentDB Extended Support」、2026年確認）。そのため、既存環境では現行版と更新計画を保守・移行費用に含めます。

Amazon DocumentDBのシステム開発費用・AWS利用料の相場

費用は、AWS利用料と開発会社への委託費に分けます。委託費は、要件定義、設計、開発、移行の工程ごとに見ます。テスト、教育、保守の委託費も、同じ形で分けます。

AWS料金は、インスタンス、DB I/O、ストレージ、バックアップが基本要素です。I/O最適化を選ぶ場合はI/O課金を含む構成になります（出典：AWS「Amazon DocumentDBの料金」、確認日2026年8月）。そのうえで、開発会社の見積とAWS請求を合算し、初期費用と月額費用を比べます。

構成とワークロードで変わるAWS利用料

AWS請求は利用環境と構成で変わるため、料金例と個別試算の前提を分けて見ます。

• 料金例：AWS公式の米国東部例はdb.r5.large 2台、DB・バックアップ各50GB、月2億I/Oです。
• 検証環境：リサーチ時点では、単一インスタンス、少量データ、利用時間を限ったDocumentDB単体で、月3万〜10万円程度が初期予算の目安になります。
• 小規模本番：2〜3インスタンス、バックアップ、監視、アプリ実行基盤を含むAWS全体で、月15万〜50万円程度になるケースがあります。

この標準構成は月449.42米ドル、I/O最適化は月459.86米ドルです（出典：AWS「Amazon DocumentDBの料金例」、確認日2026年8月）。1米ドル=150円で単純換算すると、約6.7万〜6.9万円になります。

ただし、日本リージョンの価格、為替、転送、CloudWatch、アプリ基盤、サポート料金は含まれておらず、日本円の確定見積ではありません。これらは個別設計前の概算で、アクセス量、インデックス、I/O、可用性、転送量、リージョンによって変わります。

PoCから大規模連携までの段階別の開発費目安

開発委託費は規模や実装範囲で変わるため、条件ごとの目安を見ておきます。

• PoC：100万〜300万円、1〜2か月程度が目安です。
• 小規模：新規業務システムは500万〜1,500万円、3〜6か月程度です。
• 中規模：CRM・MA連携は1,500万〜5,000万円、6〜12か月程度です。
• 大規模：5,000万円〜数億円、12〜24か月以上となる可能性があります。

DocumentDB専用の公的な開発費統計はありません。そのため、次の目安は、営業・CRM・MA業務システムの相場と、一般的なクラウド開発をもとにした発注前の概算です。

実際の見積では、機能数に加えて、移行データの品質、連携先の数、非機能要件、利用者数、現場への展開範囲を確認します。

PoCでは、MongoDBデータの一部移行、主要クエリ、負荷を検証します。さらに、バックアップ・復元、権限、TLS、監視も対象にします。

小規模開発は、顧客・案件・活動管理を中心とする業務機能を含む想定です。加えて、権限や検索の機能、簡易ダッシュボードも入ります。AWS基盤とテストも想定に入れます。

大規模化する要因には、複数拠点やリージョン、DR、複雑な権限、数千万件以上の移行があります。また、SFA、MA、基幹、会計とのAPI連携、クレンジングを加えると工数が増えます。段階移行、監査ログ、運用設計も工数に加わります。

保守費と移行費を含めた総額の比較

初期費用だけでなく、運用期間にかかる費用も含めて比べます。

• 保守・改修：初期開発費の年10〜20％程度を見込む方法があります。
• 総保有コスト：AWS利用料の増加、ログ・バックアップ、サポート、ドメイン・証明書、転送、外部SaaS契約費を含めて、3年程度で試算します。
• 費用配分：要件定義10〜15％、設計25〜35％、開発・単体試験30〜40％が参考です。
• 試験・移行：結合・総合テスト15〜20％、移行・教育5〜10％が参考です。
• 見積確認：移行、教育、クレンジング、切り戻し、更新が別料金かどうかを確認します。

保守費は、24時間監視、SLA、セキュリティ対応、追加開発の量によって変わります。費用配分は固定の正解ではありません。移行や教育がきわめて少ない見積には、注意が必要です。

委託先の選び方と見積比較のポイント

委託先は、互換性検証、業務アプリ開発、移行、セキュリティ、運用のどこまでを担当できるかで選びます。ただし、AWSに強い会社でも、CRMや営業要件を別会社へ再委託する場合があります。提案の段階で、責任分界と再委託先を開示してもらい、発注側に残る判断を把握します。

AWS導入件数ではなくDocumentDB案件の中身で見る実績

公開されている実績の数値に加えて、検証や移行をどこまで担ったかを確認します。

• 案件内容：規模、データ量、MongoDB移行、エンジン版、クエリについて尋ねます。
• 提示資料：匿名構成図、PoC評価項目、移行リハーサル、引き継ぎ資料を見せてもらいます。
• 対応力：障害・性能課題への対処と、自社条件への適用方法を見ます。

顧客名を開示できない場合でも、提示資料から経験の具体性は判断できます。

WhatsApp向けマーケティング基盤のAiSensyは、MongoDB AtlasからDocumentDBへ120TBを移行したと報告しています。移行には3週間かかり、停止はありませんでした。

この事例では、文書DBの費用を20％削減し、クエリ性能を95％改善しています（出典：AWS「Improving performance and lowering document database costs with AiSensy」、確認日2026年8月）。

大規模事例の数値を、自社の見積にそのまま当てはめることはできません。そのため、AWS DMS、負荷試験、データ照合、段階切り替え、CloudWatch監視を、自社条件に照らして確かめます。

作業範囲・前提・除外項目をそろえた見積の比較

各社の見積条件が異なると金額を比べにくいため、依頼の段階で前提をそろえておきます。

• 共通条件：同じRFP、データ項目、サンプルクエリ、ピーク負荷、目標時期を渡します。
• 工程別見積：現状調査・要件定義・PoC、設計・開発・基盤、移行・試験・教育・保守を示します。
• AWS料金：算定条件、構成、バックアップ、ログ、転送、サポートの違いを見ます。
• 対象範囲：含む作業と除外項目をそろえ、完成条件ごとの総額を比べます。

AWS利用料では、ServerlessとProvisioned、StandardとI/O-Optimizedのどちらを選んだかと、その理由を確認します。加えて、見積には人数、期間、成果物、検収条件も示してもらいます。

工程ごとの工数を比べて、作業量の多い箇所を把握します。開発費を「一式」とだけ書く見積では、要件追加や移行データの不備が、あとから追加請求になりやすくなります。

提案時の質問で見る発注後のリスク

提案の具体性から、発注後の対応と現場への定着を任せられるかを見ます。

• 技術リスク：非互換クエリの代替案と移行差分の照合方法を尋ねます。
• 障害対応：切り戻しの基準と一次対応者。
• 引き継ぎ：IaC・ソースの納品範囲と担当交代時の方法を聞きます。
• 現場定着：最小入力、役割別画面、品質管理、利用状況の測定案を見ます。

回答がAWSサービス名だけで終わらず、検証方法、成果物、責任者、期限まで具体的に示されている会社を評価します。

入力が多すぎたり、Excelやメールでの処理が残ったりすると、画面が使われない場合があります。そのため、検索速度、品質担当者、利用率・入力漏れの測定方法も確かめます。

発注からリリースまでの進め方

発注後は、次の順に進めます。各工程で、成果物と次の工程へ進む条件を決めておきます。

1. 現状調査
2. 要件定義
3. PoC
4. 基本設計
5. 詳細設計・開発
6. テスト
7. 移行リハーサル
8. 本番切り替え
9. 教育
10. 保守

DocumentDB案件では、データモデルとクエリを設計の早い段階で検証します。

現状調査とPoCによる採用可否の確認

現場の実態に沿って調べたうえで、PoCで採用可否を判断する基準を定めておきます。

• 現状の規模：利用者数、企業・顧客件数、1日のイベント数、データ増加量を整理します。
• 既存環境：MongoDBの版、主要クエリ、連携先、個人情報区分、障害履歴を確認します。
• 業務実態：名寄せ、CSV加工、二重入力、承認、削除依頼の実態も調べます。
• PoC内容：代表データ移行、検索・更新・集計、負荷・障害、バックアップ・復元を試します。
• 完了条件：クエリ成功率、応答時間、データ件数と内容の一致、切り戻し時間、運用手順の実行。

既存画面や帳票も調べて、業務とシステムの現状を把握します。

PoCの結果は本開発の見積に反映し、未解決の課題を残したまま本番契約へ進まないようにします。

リハーサルと照合を繰り返す移行と切り替え

切り替え後に移行結果を判断できるよう、照合手順を先に設計します。

• 移行対象：企業、顧客、担当者、商談、活動を含みます。イベント、商品、契約も整理します。
• データ照合：件数、必須項目、重複、関連、更新日時、機密区分を確かめます。
• 切り替え手順：停止、差分取込、最終照合、通知、旧環境への復帰を決めます。
• 段階移行：AWS DMSなどを使い、負荷試験とデータパリティ確認を行います。

旧コードと新コードの対応表を作り、対象外の履歴をどこに保管するかも決めます。データクレンジングは、発注側と委託先のどちらが担うかを明確にします。

AiSensyの事例では、クラスターを順に移行し、各段階で負荷試験とデータ照合を行っています。ただし、規模は違っても、段階移行と照合を発注条件に含める考え方は参考になります。

教育と運用設計による現場への定着

教育は、営業、マネージャー、マーケティング、データ管理者、システム管理者ごとに業務演習を分けます。そのうえで、顧客登録、名寄せ、商談更新、行動イベント確認、権限申請、エラー再処理を、実データに近い環境で練習します。

操作手順と問い合わせ先も残します。稼働後は、入力率、重複率、検索時間、商談更新の遅延を定期的に確認します。さらに、連携エラー、バックアップ成功率、障害対応時間、AWS利用料も見ていきます。

導入効果は、開発が終わった時点ではなく、作業時間、データ品質、意思決定の速さで評価します。また、社内にデータ品質の責任者と、クエリ・インデックスの見直し担当を置くと、外注後も改善を続けやすくなります。

よくある質問

発注時は、機能だけでなく、費用、MongoDB互換性、移行、セキュリティ、保守も確認しておきます。

MongoDBからAmazon DocumentDBへそのまま移行できますか？

データやドライバーの一部は再利用できる可能性がありますが、完全にそのまま移行できるとは限りません。

そのため、クエリ、集計、トランザクション、インデックスをPoCで検証します。ツール、版、データ量も確かめ、書き換えと移行方式を見積に反映します。

Amazon DocumentDBのシステム開発費用はいくらですか？

発注前の目安として、PoCは100万〜300万円、小規模な新規業務システムは500万〜1,500万円、中規模のCRM・MA連携は1,500万〜5,000万円程度です。

DocumentDB専用の公的な相場はなく、一般的なクラウド業務システム開発をもとにした概算です。AWS利用料、移行、連携、試験、教育、保守の有無で変わるため、同じRFPを複数社に渡して比べます。

ServerlessとProvisionedはどちらを選べばよいですか？

アクセス変動が大きく、未使用時間のある検証環境やイベント処理では、Serverlessが候補です。一方、安定した処理量と応答時間を重視する本番では、Provisionedが候補になります。

最低・最大容量とピーク時間をもとに試算します。そこに、I/O、マルチAZ、リードレプリカの条件を加えます。リージョン対応も確かめたうえで、PoCの負荷結果とAWS料金の見積から決めます。

Amazon DocumentDBに強い委託先は何を基準に選べばよいですか？

AWSの設計・構築に加えて、互換性検証、業務要件の整理、アプリ開発、移行、セキュリティ、保守を担当できるかを確認します。分担する場合は、その境界を明確にします。

実績の数だけでなく、PoCの成果物、データ照合、切り戻し、IaC・ソース納品、障害時の責任者を尋ねます。そのうえで、自社の業務とデータ規模に近い提案を比べます。

まとめ

発注では、データ構造、互換性、移行、AWS利用料、開発費、運用保守を、一つの計画として比べることが大切です。

発注前にPoCとRFPでそろえる判断条件

業務データ、検索、集計を整理しておきます。連携、個人情報、可用性の条件も定めます。運用体制も、発注前に決めておきます。互換性は、主要クエリと実データでPoC検証し、その結果を開発費と移行費の見積に反映します。

RFPには、現状業務、データ項目、連携、非機能要件、成果指標、納品物を記載します。

費用と責任範囲を含むTCOによる委託先の選び方

SaaS・パッケージ、クラウドネイティブ開発、フルスクラッチ、段階発注を比べます。そのうえで、PoC、開発、移行、教育、保守、更新を含めた3年程度のTCOで検討します。

価格だけでなく、互換性、移行、セキュリティ、運用、現場定着まで担える委託先を選ぶことが、長く使えるシステムにつながります。

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

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