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

Amazon ECSのシステム開発を発注・外注するなら、ECSの構築費だけではなく、業務要件、データ移行、セキュリティ、運用まで含めた総額と責任分界を先に決めることが重要です。

Amazon ECSは顧客管理や営業管理そのものを提供する業務パッケージではなく、コンテナ化したWebアプリケーションやAPI、バッチをAWS上で動かす実行基盤です。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先と見積書の比較方法、失敗しにくい進め方を、2026年時点の情報をもとに解説します。

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

Amazon ECSのシステム開発はどのように発注しますか？

Amazon ECSのシステム開発は、ECSの設定だけを切り出して頼むのではなく、業務アプリケーション、データ、AWS基盤、移行、監視をどこまで委託するか決めてから発注します。特に営業・CRM・MA用途では、現場の入力や承認の流れを曖昧にしたまま技術仕様を先に決めると、完成後に使われないシステムになりやすいです。

Amazon ECSには、Dockerイメージを保管するAmazon ECR、CPUやメモリ、ポート、環境変数、IAMロールを定めるタスク定義、タスクをまとめるクラスター、常時稼働数や更新を管理するサービスがあります。外部公開にはVPC、サブネット、セキュリティグループ、Application Load Balancer、Route 53、TLS証明書を組み合わせ、顧客情報や商談データはAmazon RDSやAurora、S3などに分離する構成が一般的です。

そのためRFPに「ECSでCRMを作る」とだけ書くと、アプリの機能、データベースの設計、認証、外部SFAや会計システムとの連携、ログ保持、バックアップの範囲が会社ごとに異なります。発注対象を「業務アプリ」「クラウド基盤」「データ移行」「運用設計」「定着支援」に分け、成果物と対象外を明記することが最初のポイントです。

発注前には、誰が何をできるようになると成功なのかを数値で置きます。例えば、営業担当が顧客情報を登録してから承認までの時間、既存データの移行完了率、ピーク時の同時接続数、障害から復旧するまでの目標時間、月間AWS利用料の上限などです。「ECS上で稼働すること」だけを合格条件にせず、業務KPIと運用KPIをセットにすると、技術的には動くが現場では使えない問題を抑えられます。

既存のモノリスや仮想マシンをコンテナ化する場合は、ソースコードやDBをそのまま移すだけでは済まないことがあります。セッション管理、ファイル保存、バッチの二重実行、固定IPへの依存、認証方式、外部APIのタイムアウトを洗い出し、PoCで検証する範囲を決めておくと、後から追加費用になりやすい論点を早期に把握できます。

発注形態はどれを選ぶとよいですか？

発注形態は、既製サービスを使うか、独自開発するか、既存システムを段階的に移行するかで考えます。営業管理や顧客管理の一般機能までECS上で作り直す必要はなく、SaaSやパッケージを利用し、独自性の高いAPI、データ連携、バッチ、周辺業務だけをECSで開発する方法も有力です。

顧客台帳、案件管理、メール配信など、他社でも共通しやすい機能はSaaSに寄せ、ECSには独自の審査フローや外部システム連携を配置する方法です。開発範囲を小さくできるため、納期と初期費用を抑えやすく、SaaS側の標準アップデートも利用できます。ただし、データの正本がどこにあるか、APIの利用上限、解約時のエクスポート形式、個人情報の委託先を契約前に確認します。

競争力に直結する独自の営業プロセス、スコアリング、見積承認、顧客ポータルなどをWeb、API、非同期ワーカーに分けてECSへ配置します。Fargateを使えばホストOSやEC2インスタンスの管理をAWSに寄せられるため、少人数チームや負荷が変動する業務に向きます。Kubernetesの標準APIや大規模なマルチクラウド運用が必須でなければ、ECSのほうが運用設計を単純化しやすいです。

既存の仮想マシンやオンプレミスシステムを一度に置き換えず、まず1機能をコンテナ化してECR、ECS、ALB、RDS接続、CI/CD、監視、ロールバックを検証します。PoCの合格条件に、デプロイ成功だけでなく復旧時間、月額、運用手順、データ整合性を含めることが重要です。段階移行なら現場の変更負担を抑えながら、問題のある機能やデータを発見できます。

RFPと要件整理は何を書けばよいですか？

RFPは、機能一覧だけでなく、業務上の目的、現状の課題、データの流れ、非機能要件、納品物、選定基準、予算とスケジュールをまとめる文書です。ECSの構成を発注者が決め切る必要はありませんが、達成したい状態を具体化し、提案会社が同じ前提で見積もれるようにする必要があります。

営業・CRM・MAシステムなら、顧客、リード、商談、活動履歴、メール配信結果のどれを管理するか、誰が登録・参照・承認・削除するかを整理します。顧客情報の正本が既存SFAなのか新システムなのか、会計や基幹システムへ何をいつ連携するのかも明記します。重複データや表記揺れを放置したまま移行すると、ECSの性能を上げても誤った情報を高速に処理するだけです。

画面一覧を作るときは、現場が毎日行う操作と例外時の操作を分けます。入力項目を増やしすぎると、完成後にExcelへ戻る原因になります。現場担当者、情報システム部門、法務・セキュリティ担当者からヒアリングし、必須項目と将来候補を分離することが、予算の膨張を抑える方法です。

同時接続数、ピーク時間帯、レスポンスタイム、可用性、RTO、RPO、バックアップ保持期間、ログ保持期間、監査証跡、対応リージョンを数値で書きます。例えば「通常時のAPI応答を何秒以内にするか」「障害時に何時間以内に復旧するか」「何日前までのデータを復元できる必要があるか」を決めると、Fargateのタスク数、ALB、RDSの構成、監視範囲を比較しやすくなります。

AWS公式のECSセキュリティ資料では、AWSが担うクラウドの安全性と、利用者が担うIAM、コンテナ、アプリケーション、データの安全性を分ける責任共有モデルが示されています（出典：AWS「Security in Amazon Elastic Container Service」、2026年確認）。RFPでは「AWS側で安全にしてもらう」と書かず、誰がイメージの脆弱性対応、権限レビュー、ログ監視、復旧テストを担当するかまで記載します。

各社へ同じRFP、同じ質問票、同じ見積フォーマットを渡します。提案書には、想定アーキテクチャ、Fargate・EC2・ECS Managed Instancesの選定理由、移行方法、テスト方針、監視と障害対応、体制、前提条件、除外事項、納品物、保守料金を含めてもらいます。口頭説明だけで済ませず、回答を文書に残すことが後の認識違いを防ぎます。

候補会社には、ECSやFargateの構築実績だけでなく、既存アプリのコンテナ化、データ移行、CI/CD、FinOps、24時間監視、内製化支援の実績を確認します。AWSの認定やパートナー登録は参考になりますが、認定だけで業務アプリの品質やプロジェクト管理まで保証されるわけではありません。匿名化した設計書や運用手順、失敗時の改善例を見せてもらえるかも判断材料です。

契約形態と責任分界はどう決めますか？

契約は、要件が固まっている部分を請負契約、変化が多い部分を準委任契約やラボ型開発に分けるなど、工程ごとに組み合わせる方法が現実的です。契約名だけで判断せず、仕様変更の扱い、検収条件、瑕疵対応、知的財産権、再委託、秘密情報、AWSアカウントの所有者を契約書と個別仕様書で確認します。

請負契約は、要件定義書や基本設計書、タスク定義、IaC、アプリケーション、テスト結果、運用手順など、納品対象を確定しやすい工程に向きます。「本番環境を構築する」だけでは検収できないため、想定負荷での性能、バックアップ復元、ロールバック、権限設定、アラート通知など、合格条件を試験項目に落とします。

要件が動いている段階で請負にすると、変更のたびに追加見積もりになり、発注者と受託者の双方が疲弊します。画面や業務フローを試す企画・PoCは準委任で進め、合意した機能の開発を請負に切り替えるなど、工程に合う契約を提案してもらいます。

準委任契約は、稼働時間や体制に対して業務を委託し、要件調整や設計検証を柔軟に進める契約です。既存コードの調査、移行方式の検討、性能検証、運用改善のように、最初から成果物の形を固定しにくい工程で使いやすいです。月ごとの作業内容、会議体、成果の記録、未消化時間、追加要員の単価を定めておくと、費用を追跡できます。

準委任でも品質責任が曖昧になるわけではありません。発注者が業務判断を行い、受託者が技術検証や設計を担うなど、意思決定者と作業責任者を分けて、議事録や課題管理表に残します。特に障害時の一次対応、AWSへの問い合わせ、アプリの修正、データ復旧の担当者は、契約開始時に決めておくことが大切です。

AWSアカウントは、原則として発注者が所有し、受託者へ必要な権限だけを付与する形が引き継ぎやすいです。受託者のアカウントで構築して後から移管する場合は、移管費用、請求先の変更、ログとバックアップの移行、ドメインや証明書の名義、解約時のデータ返却を事前に確認します。

ソースコードだけでなく、TerraformやAWS CDKなどのIaC、ECSタスク定義、CI/CD設定、監視ダッシュボード、アラート一覧、運用手順、障害履歴、テストデータ、アクセス権一覧まで納品物に含めます。これらがなければ、別会社への保守移管や内製化のたびに再調査費用が発生し、ベンダーロックインが強くなります。

Amazon ECSのシステム開発費用とAWS利用料の相場は？

Amazon ECSにはサービス自体の構築費という一律の定価があるわけではありません。開発会社へ支払う初期開発費、AWSのコンピュートと周辺サービスの利用料、保守・監視費、社内の運用工数を分けて見積もる必要があります。以下は、リサーチノートのクラウド業務システム開発相場とAWS公式料金を組み合わせた企画段階の目安であり、個別案件の確定金額ではありません。

技術検証のPoCで、1サービスのECR・ECS/Fargate、簡易CI/CD、基本監視を確認する場合は、100万〜300万円、期間は1〜2か月が目安です。Web・APIを1〜3サービスに分け、ALB、RDS、認証、バックアップ、基本監視まで含む小規模本番は、300万〜800万円、2〜4か月程度が一つの目安になります。

CRM・MA連携、複数環境、権限、非同期処理、データ移行、冗長化まで含む中規模業務システムは、800万〜3,000万円、4〜9か月程度です。複数拠点、複数AWSアカウント、レガシー移行、災害復旧、サービスレベル合意、24時間運用まで含む大規模案件は、3,000万〜1億円超、9〜24か月以上になる可能性があります。これらはECSの利用料を含まない開発費の推定です。

保守費は、初期開発費の年10〜20％程度を置く考え方がありますが、24時間365日監視、障害対応、脆弱性対応、改善開発の有無で大きく変わります（出典：リサーチノート内の営業・CRM・MA関連Q&A整理、2026年）。最低月額、対応時間、含まれる工数、AWS利用料の請求代行手数料を分けて確認します。

AWS公式によると、Fargateはコンテナイメージのダウンロード開始からタスク終了まで、要求したvCPU、メモリ、OS、CPUアーキテクチャ、追加ストレージを基準に秒単位で課金され、1分の最低課金があります（出典：AWS「AWS Fargate Pricing」、2026年確認）。Fargate Spotは中断を許容できるECSタスクで通常料金から最大70％割引、Compute Savings Plansは1年または3年の利用コミットメントで最大50％の節約余地がありますが、可用性要件を満たす範囲で適用します。

リサーチノートの米国東部リージョンの料金例を、1ドル150円、730時間稼働という仮置きで換算すると、0.25 vCPU・0.5GBを1タスクで約9ドル、約1,400円、0.5 vCPU・1GBを2タスクで約36ドル、約5,400円、1 vCPU・2GBを2タスクで約72ドル、約10,800円というコンピュート部分の規模感になります。これは東京リージョンの請求額ではなく、為替も固定した試算です。契約前にはAWS Pricing Calculatorでリージョン、タスク数、稼働時間を入れて再計算します。

本番では、ALB、NAT Gateway、ECR、CloudWatch Logs、Container Insights、RDSまたはAurora、S3、ElastiCache、Route 53、データ転送、パブリックIPv4、AWS Supportが加わります。小規模本番は月3万〜15万円、中規模は月15万〜80万円、大規模・高可用性・大量ログや大量転送は月80万〜数百万円以上という概算レンジを置けますが、これは一般的な構成からの推定です。AWS利用料だけでなく、ログ削減、DBのバックアップ、夜間のタスク数、障害対応の人件費もTCOに入れます。

FargateはインスタンスやホストOSの管理工数を減らしやすく、変動負荷や少人数チームに向きます。EC2起動タイプは常時高負荷のタスクを集約しやすく、GPUや特殊なネットワーク・ストレージ、インスタンスタイプを細かく選べますが、パッチ、キャパシティ、障害対応を自社または委託先が担います。料金だけでなく、月次の運用時間と障害時の対応費まで比べます。

ECS Managed Instancesは2025年10月にすべての商用AWSリージョンで利用可能になった選択肢です。AWSがEC2インスタンスのプロビジョニング、配置最適化、運用の一部、14日ごとのセキュリティパッチを管理し、GPUなどのインスタンスタイプも指定できますが、通常のEC2料金に管理料金が加算されます（出典：AWS「Amazon ECS Managed Instances now available in all commercial AWS Regions」、2025年10月）。2026年の発注では、Fargate、EC2、Managed Instancesを同じ負荷条件で試算し、管理工数を含むTCOで比較します。

委託先選定と見積比較で何を確認しますか？

委託先は「AWSが使える会社」ではなく、ECSの設計・移行・アプリ開発・運用を、どこまで一貫して担えるかで選びます。提案の見栄えや単価だけで決めると、データ移行や監視、運用引き継ぎが別料金になり、最終的な金額と責任者が見えなくなります。

確認したいのは、ECS/Fargateの経験年数だけではありません。既存システムをコンテナ化したか、データ件数と移行停止時間はどの程度だったか、RDSや外部SaaSと連携したか、IaCとCI/CDを納品したか、障害時に誰が何分以内に対応したかを質問します。可能なら類似した業界・利用者数・個人情報の有無・24時間運用の事例を見せてもらいます。

体制表では、営業担当ではなく実際に設計と運用を担当する責任者を確認します。AWSアーキテクト、アプリ開発者、データ移行担当、プロジェクトマネージャー、運用担当の役割と稼働率を明記してもらい、再委託の有無、担当者交代時の引き継ぎ、内製化支援の内容を比較します。

見積比較では、要件定義、基本設計、詳細設計、アプリ開発、AWS基盤、テスト、データクレンジング、移行リハーサル、本番移行、教育、保守を行単位に分けてもらいます。「一式」だけではなく、人月や作業量、期間、担当者、成果物を確認します。単価が安くても、要件定義や移行が抜けていれば、後工程で追加費用になるためです。

相見積もりでは、価格を単純に合計して順位付けしません。機能の充足度、非機能要件の充足度、移行計画、運用体制、納品物、変更管理、発注者側の負担を同じ評価表に入れます。例えば、価格30点、提案内容25点、実績15点、体制15点、運用・引き継ぎ15点のように、社内で重みを決めてから採点すると、最安値だけに引っ張られにくくなります。

極端に安い見積もりでは、要件定義、データクレンジング、テスト環境、ログ保管、バックアップ復元、監視、教育、リリース後の不具合対応が含まれているかを確認します。反対に、高額な見積もりでも、過剰なカスタマイズや不要な常時稼働、必要以上のログ保持が入っている場合があります。要件を変えずに削れる項目と、削ると品質が下がる項目を分けて説明してもらいます。

追加費用の条件も重要です。API仕様の変更、データ件数の増加、移行リハーサルの回数、AWS利用料の高騰、担当者の追加、休日作業、脆弱性対応、AWS障害の扱いを契約前に確認します。変更要求の受付方法、影響分析、承認者、見積有効期間を決めておくと、開発途中の認識違いを抑えられます。

発注からリリースまでの進め方はどうなりますか？

発注後は、企画・要件定義、PoC・基本設計、開発・移行、テスト・リリース、運用引き継ぎの順に進めます。各工程の終わりに、次の工程へ進む条件を設定しておくことが重要です。要件が未確定のまま開発へ進めない、PoCで月額と復旧手順が確認できなければ本番設計を確定しない、といった判断基準を共有します。

要件定義では、業務フロー、データモデル、権限、連携先、非機能要件、移行対象を確定します。PoCでは、代表的な1機能をECRからECS/Fargateへデプロイし、RDS接続、ALB経由の通信、秘密情報の注入、ログ、オートスケーリング、ロールバックを確認します。既存システムとの接続やバッチの二重実行など、机上で判断しにくい部分を優先します。

PoCの成果物には、採用した構成だけでなく、採用しなかった構成と理由、発生した課題、推定AWS利用料、残課題、運用手順を含めます。検証が終わったから本番へ進むのではなく、費用、性能、セキュリティ、運用性の合格基準を満たしたかを発注者側が判断します。

本番化では、開発・検証・本番の複数環境、IaC、ローリングまたはBlue/Greenデプロイ、デプロイサーキットブレーカー、オートスケーリング、マルチAZ、DBバックアップを整えます。移行前にはデータ件数と整合性を確認し、リハーサルで所要時間とエラー時の戻し方を検証します。新旧システムを並行稼働する期間を設けると、現場の切り替えリスクを下げやすいです。

リリース判定では、機能テストだけでなく、ピーク負荷、権限、ログ、アラート、バックアップ復元、ロールバック、個人情報の取り扱いを確認します。担当者が手順書を読んで実際に復旧できるかを訓練し、受託者だけが復旧できる状態を残さないことが重要です。

稼働後は、ECSのCPU・メモリ使用率、タスク再起動、デプロイ失敗、RDSの負荷、ログ量、外部APIのエラーを監視します。月次で未使用リソース、タスクサイズ、ログ保持期間、夜間のタスク数、データ転送を確認し、AWS利用料を予算と比較します。コスト削減を優先しすぎて冗長性や監視を削るのではなく、業務上許容できる停止時間とセットで判断します。

営業現場の入力負担や利用率も、システムの成功指標です。利用されない項目を削り、入力補助や権限を調整し、現場の声を小さな改善へ反映します。運用委託を続ける場合でも、月次報告に障害件数、復旧時間、改善提案、コストの変化を含めてもらうと、単なる保守費ではなく成果を見ながら契約を更新できます。

セキュリティ・データ移行・運用を委託するときの注意点は？

顧客情報や認証情報を扱うシステムでは、「AWSだから安全」と考えず、設定と運用の責任を発注者と委託先で分けます。ECSではIAMの最小権限、タスクロールと実行ロールの分離、Secrets Managerや暗号化したParameter Storeの利用、ECRイメージの脆弱性スキャン、非root実行、TLS、CloudTrailやCloudWatchの監視を要件化します。

パスワードやAPIキーをDockerイメージやソースコード、通常の環境変数へ直接書かないことが基本です。タスク起動時に秘密情報を取得する方式、誰が更新するか、ローテーション時に再デプロイするか、ログへ値が出ないかを確認します。ネットワークでは、公開サブネットと非公開サブネットを分け、ALBからECSタスク、タスクからRDSという通信経路をセキュリティグループで限定します。

AWS公式のネットワークセキュリティ資料では、Fargateで利用できるawsvpcネットワークモード、タスク単位のセキュリティグループ、必要に応じたAWS PrivateLinkやVPC Flow Logsが説明されています（出典：AWS「Network security best practices for Amazon ECS」、2026年確認）。委託先には、設計図だけでなく、許可通信一覧、例外申請、ログの確認方法、脆弱性が見つかった場合のSLAを提出してもらいます。

日本の個人情報を扱う場合は、保管リージョンだけでなく、AWSや委託先の運用担当者がデータへアクセスする可能性、サポート時のアクセス、再委託先、バックアップ、契約上の取扱いを確認します。個人情報保護委員会のFAQでは、外国にある事業者が国内サーバーに保存された個人データを取り扱う場合、外国にある第三者への提供に該当し得ると説明されています（出典：個人情報保護委員会「外国にある事業者が運営するクラウドを利用していますが、サーバは国内にある場合」、2026年確認）とされています。

これはAWS東京リージョンを選べば法務確認が不要になるという意味ではありません。個人情報保護法上の委託先監督、本人への説明、外国にある第三者への提供に関する対応、アクセス制御、暗号化、漏えい時の報告手順を、法務・セキュリティ担当者と確認します。RFPには、データ分類、利用目的、保管期間、削除方法、再委託、国外アクセスの可否を記載すると、提案会社の回答を比較しやすいです。

データ移行では、抽出、変換、重複排除、名寄せ、検証、差分移行、切り替え、旧環境の扱いを工程化します。移行対象の件数だけでなく、顧客IDや商談IDの対応表、失敗レコードの再処理、個人情報の一時ファイル削除、移行後の照合方法を決めます。リハーサルを1回で終わらせず、データ量と停止時間が本番条件に近づくまで確認します。

障害対応では、ECSタスクが停止したとき、デプロイが失敗したとき、RDSに接続できないとき、外部APIが遅延したときの手順を分けます。アラートの通知先、一次切り分け、AWSへの問い合わせ、利用者への告知、復旧判断、再発防止の担当者と期限を決め、受入テストで実際に訓練します。運用開始日に手順書を渡すだけでは、緊急時に使える状態とは言えません。

よくある質問

Amazon ECSのシステム開発を発注するときに、特に質問されやすい内容をまとめます。費用だけでなく、業務要件、契約、運用責任まで含めて判断することが大切です。

技術検証だけなら100万〜300万円程度、小規模本番なら300万〜800万円程度が企画段階の目安です。対象機能、既存システムの状態、移行データ、セキュリティ、運用時間によって変わるため、ECSの設定費だけでなく、要件定義、テスト、移行、保守を含めた見積書で確認します。

少人数でホストOSの管理を減らしたい、または負荷が変動する場合はFargateが候補です。常時高負荷、GPU、特殊なストレージ、細かなインスタンス選定が必要ならEC2、EC2の選択肢と運用負荷削減を両立したい場合はECS Managed Instancesも比較します。発注先には、同じ負荷条件でAWS利用料と運用工数を比較した資料を提出してもらいます。

ECS/Fargateの構築実績だけでなく、業務アプリ開発、データ移行、CI/CD、監視、障害対応、内製化支援まで同じ条件で確認します。成果物としてソースコード、IaC、タスク定義、設計書、テスト結果、運用手順を納品するか、AWSアカウントを誰が所有するか、再委託や解約時の引き継ぎを明確に答えられる会社が候補になります。

まとめ

Amazon ECSのシステム開発を成功させるには、ECSを採用すること自体を目的にせず、業務要件、データ、セキュリティ、運用体制、総コストを一つの発注条件として整理します。SaaS・パッケージ併用、ECS上の独自開発、段階的なモダナイズを比較し、必要な範囲だけを外注することが、費用と納期をコントロールしやすい方法です。

RFPには、利用者と業務フロー、データの正本、既存システム、連携先、ピーク負荷、RTO・RPO、個人情報、希望納期、予算、成果物、運用体制を記載します。見積書は工程別の金額と工数、前提、除外事項、追加費用の条件、AWS利用料、保守費を分け、複数社を同じ評価軸で比較します。

いきなり全機能を本番開発へ進めず、代表機能を使ったPoCで、ECSの起動方式、連携、監視、復旧、月額費用を確認します。その結果をRFPへ反映して2〜3社へ相見積もりを依頼し、価格だけでなく、技術・業務・移行・運用・引き継ぎを含めて委託先を選びます。発注後も、現場の定着とTCOを継続的に見直すことが大切です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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