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

Apache Kafkaのシステム開発は、業務イベントを棚卸しし、小さなPoCで動きを確かめ、RFPで各社を比べる順に進めると、要件と成果物をそろえて発注できます。

発注形態から委託先の選定まで、段階ごとに決めることを順に見ていきます。全体像はApache Kafkaのシステム開発の完全ガイドもご覧ください。

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

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

Apache Kafkaのシステム発注・外注の意味

Apache Kafkaのシステム発注・外注は、イベント基盤と接続する業務アプリの開発を、外部の開発会社やSI会社へ委託することです。

Kafkaは、注文、決済、在庫変動、IoTセンサー、アクセスログなどのイベントを、リアルタイムに収集・保存・配信します。

Kafkaは、メッセージを一時的に渡すだけでなく、イベントをTopicへ追記して一定期間保持します。さらに、複数のConsumerが必要な時点から読み直せる点も特徴です。

Kafkaで分断したデータを複数の業務へ届ける基盤

ECで注文が確定すると、受注システムは一つのイベントを発行できます。在庫引当、決済確認、配送指示のほか、顧客通知やデータ分析のConsumerが、それぞれ同じイベントを読んで処理します。

各システムへ個別にAPIを呼ぶ構成と比べると、連携先の追加や一時停止の影響を分離しやすくなります。

イベントの契約を決めておけば、需要予測や不正検知のConsumerも既存Producerを大きく変えずに追加できます。

小規模な非同期処理でKafka以外が適する場合

連携ごとに、処理の規模や必要な機能に応じて候補を分けて考えます。次のとおり、Kafka以外の候補も含めて比べます。

• 日次集計：毎日一回の集計で足りるなら、バッチのほうが構築・運用しやすいことがあります。
• 少数の遅延通知：数件を確実に遅延実行するだけなら、RabbitMQやAmazon SQSも候補に入ります。
• 単純な連携：CRUDや同期APIで完結する処理の場合は、通常のAPIが候補です。
• 大量イベントの配信：複数利用者への配信や後からの再処理が要るなら、Kafkaが候補になります。

Kafkaは、大量のイベントを複数の利用者へ配り、後から再処理する場合や、将来Consumerを増やす場合に費用対効果を出しやすい基盤です。

採用は、秒間イベント数、ピーク倍率、許容遅延を確かめてから決めます。保持期間、再処理の要否、順序保証の単位も判断材料です。これらが固まらないまま台数やPartition数を決めると、過剰投資や性能不足につながります。

発注形態の選び方

発注形態は、社内のクラウド運用力と、自社で保有したい範囲をもとに選びます。加えて、連携数、可用性・セキュリティの要求、将来の保守体制も判断材料になります。

代表的な形態は、自社運用、マネージドサービスの利用とアプリ開発の委託、SI会社への一括委託です。形態ごとに運用負荷と責任範囲が異なるため、以下で順に見ていきます。

マネージドKafkaで運用負荷を抑える方式

マネージドサービスを使うと、Broker構築、パッチ適用、障害対応の一部をサービス側に寄せられます。候補になるのは、AWS、Google Cloud、Confluent Cloudの3つのサービスです。

• Amazon MSK：AWSの環境で利用できる選択肢です。
• Google Cloud：Managed Service for Apache Kafkaという選択肢があります。
• Confluent Cloud：Kafka Connectやガバナンス機能も含めて比べられます。

AWS中心の環境なら、IAMやKMS、CloudWatchと組み合わせやすい選択肢です。PrivateLinkと組み合わせることもできます。Google Cloud中心の環境なら、BigQueryやCloud Storageとの接続を検討できます。

マネージドサービスを使っても、アプリ側の改修やTopic設計は残ります。Producer・Consumerの改修やスキーマ管理も必要です。権限、再送・冪等性、監視設計も含めて考えます。

見積に、発行元と利用先の改修、負荷試験、再処理手順が含まれているかを確かめます。

OSS版Kafkaを自社運用する方式の自由度と責任

OSS版Kafkaは、仮想マシンやKubernetesで運用でき、設定を細かく決められます。オンプレミスやハイブリッド環境も候補に入ります。

• 自社で決める項目：ネットワーク、ストレージ、監視、バージョン、バックアップ。
• 必要な運用力：Broker障害、容量予測、Partition再配置、KRaft更新、脆弱性対応、夜間対応。
• 費用の見方：VM、ディスク、転送、バックアップ、監視の費用です。オンコール、教育、更新も含めて見ます。

データの保存場所に厳しい制約がある企業にも適します。

ライセンス費用が無料でも、運用全体の費用が安くなるとは限りません。

社内に経験者が少ない場合は、最初のPoCと本番設計を外部へ委託する方法があります。そのうえで、運用の引き継ぎも契約に含めると現実的です。

Kafka基盤と業務システムをSI会社へ一括委託する方式

受発注や在庫、決済などの業務をまたぐ場合は、周辺の業務設計も必要になります。ERPやIoT、分析基盤が絡むと、業務設計の範囲はさらに広がります。

• 責任分界：一括で委託すると、どこまでを誰が受け持つかを整理しやすくなります。
• 委託範囲：業務ヒアリング、イベント一覧、既存システム改修を含められます。データ移行、クラウドネットワーク、監視、利用者教育も対象にできます。
• 体制：再委託先やクラウド事業者を含めた体制図で、関わる会社を把握します。
• 契約事項：成果物の著作権、設定情報の引き渡し、障害時の一次窓口を契約書に明記します。
• 納品物：設計書、IaC、Topic・ACL一覧、スキーマ、監視画面、運用手順。

Apache Kafkaのシステム開発を発注する進め方

Kafka案件では、クラスタの構築に加えて、業務イベントの発行元、Consumerの処理保証、失敗イベントの再送・隔離まで決めておく必要があります。

次の順に進めると、見積の条件と成果物をそろえやすくなります。

業務イベントと採用目的の棚卸し

棚卸しでは、業務イベントの条件と、Kafkaで改善したい目的を一覧にします。

• 業務情報：業務名、イベント名、発生元、利用先、発生頻度。
• 処理条件：ピーク倍率、イベントサイズ、許容遅延、保持期間。
• 業務上の意味：注文確定、支払完了、出荷指示、在庫変動のどれを単位にするか。
• 改善目標：在庫反映を15分から1分以内に縮めるなど、数値で示す目標。
• 再処理目標：障害復旧後に過去24時間分を処理する目標と、連携追加の短縮目標。

個人情報の有無と再処理の要否も、同じ一覧に加えます。業務単位で整理すると、ログ転送と重要なトランザクションを区別できます。

目的が新技術の導入だけであれば、API、CDC、クラウドのキューサービスも比べます。

小さなPoCによるKafkaの性能と失敗時の動きの検証

PoCは、代表的な1業務と1〜3個のTopic、数本のProducer・Consumerに絞って行います。正常系だけでなく障害系も検証すると、本番で起こりうる問題を前もってつかめます。

1. Consumer停止、Broker障害、通信遅延の発生時の動作
2. 権限エラー、スキーマ変更、重複イベントへの対応
3. 順序逆転と処理遅延が起きたときの再処理

納品物には、測定条件と処理件数、最大遅延を記します。再処理結果や残課題も含めます。PoCでは、同じキーのイベントが同じPartitionに入るかも確かめておきます。

Kafkaの順序保証は、原則としてPartition単位です。Topic全体で順序が揃うわけではないため、顧客IDや注文IDをキーにするかを、実データに近い条件で試します。

Partition数を増やしたときの処理順序も検証したうえで、本番構成へ進みます。

本番化での設計・開発・テスト・移行の管理

本番化では、成果を工程ごとに分けて管理します。設計詳細には、DLQ、ACL、暗号化、監視も含めます。次の項目を、工程の順に押さえます。

1. 設計：Broker、Topic命名、Partition数、Replication Factor、保持期間の決定。
2. 設計詳細：ログコンパクション、Producer再送、Consumer Group、Schema Registryを定めます。
3. 実装：Kafka Connect・Kafka Streamsの利用範囲と、個別開発の範囲。
4. 試験：機能、負荷、Partition再配置、Broker停止、Consumer再起動の確認。
5. 品質確認：重複、遅延、スキーマの後方互換性、バックアップ復旧の検証。
6. 移行：旧・新環境の並行稼働と、イベントの二重発行の防止策。
7. 切替準備：未処理オフセット、切り戻し条件、利用部門への告知。

Kafka案件の品質は、平常時のスループットと、異常時に安全に戻せるかの両方で測ります。

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

RFPでは、業務課題と対象範囲、イベント条件を伝えます。非機能要件と既存システムも記載します。製品名や「高性能にしたい」という希望は、その前提を示したうえで書きます。

運用体制と予算、スケジュールを記載します。納品物も書き添えます。現行の事実と将来の希望を分けて書くと、会社ごとの見積を比べやすくなります。

RFPに含めるKafkaのイベント定義とデータ契約

RFPには、イベントの内容と例、スキーマ管理のルールを、そろえて書きます。

• イベント項目：名前、発生元・条件、キー、ペイロード項目、型、最大サイズ。
• 利用条件：頻度、ピーク倍率、利用先、保持期間、個人情報の有無。
• データ例：「注文確定」の場合の注文ID、顧客ID、時刻、明細、金額、通貨など。
• 変更管理：互換性、契約責任者、変更申請、レビュー、旧版の廃止時期。

発生元のバージョンも定義します。そのうえで、項目が必須か任意か、欠損時の扱い、時刻のタイムゾーンを決めます。

項目を追加しても既存のConsumerが壊れないよう、形式を既存の言語や運用体制に合わせておきます。

Schema Registry、JSON Schema、Avroなどの選択肢があります。互換性の確認も、運用に含めておきます。

Kafkaの非機能要件の数値指定

性能は、平均値だけでなくピーク時の条件で指定します。運用と試験の条件も、具体的に書いておきます。

• 性能：秒間の読み書き数、最大サイズ、許容遅延、Consumerの同時数。
• 可用性：保持期間、必要容量、Replication Factor、RPO、RTO、バックアップ頻度。
• 運用：監視、通知先、一次対応時間、夜間対応、障害時のエスカレーション。
• 保守：容量追加の判断、バージョンアップ、脆弱性対応。
• 試験：「大量」といった表現を避け、試験方法と合格基準をそろえる。

障害時の連絡手順と復旧訓練も、RFPに明記します。

Kafka 4.0は、ZooKeeperなしのKRaftモードを前提とする大きな節目です。

BrokerやConnectなどにはJava 17、クライアントやKafka StreamsにはJava 11が必要とされています（出典: Apache Kafka「Apache Kafka 4.0.0 Release Announcement」、2025年、2026年確認）。

既存システムのJavaのバージョンと対応範囲も、要件に含めます。

個人情報・権限・委託先管理の要件

顧客IDや氏名、住所などを含むイベントでは、保存する項目を決めます。決済情報や行動履歴を含む場合も、保存する項目を決めます。

マスキングや匿名化の対象となる項目と、権限・委託先管理の条件も、RFPに記載します。

• データ項目：保存項目と、マスキング・匿名化の対象項目。
• アクセス保護：Topic・Consumer Group ACL、TLS、保存時の暗号化。
• データ管理：秘密情報、監査ログ、保持、削除、バックアップの扱い。
• 委託先：再委託、海外アクセス、ログ保存先、返却と消去証明の確認。

個人データを扱う情報システムについては、個人情報保護委員会のガイドラインが技術的安全管理措置を示しています。

その内容は、アクセス制御、識別・認証、不正アクセス防止、漏えい等の防止です（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

障害ログの保存場所も、RFPで確かめておきます。

契約形態と契約書の記載事項

契約形態は、要件の確定度と変更の多さで選びます。調査を伴うイベント設計やPoCには準委任契約が、成果物と受入条件が明確な開発には請負契約が候補になります。

要件整理とPoCは準委任、本番の確定機能は請負、稼働後の監視・改善は保守契約に分ける方法もあります。

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

契約では、請負と準委任のそれぞれについて、作業範囲、受入条件、予算管理を工程ごとに定めます。

• 請負の範囲：構築、アプリ改修、Schema Registry、監視を明記します。試験、移行、教育も含めます。
• 受入条件：指定イベント量での遅延、障害復旧、重複、権限、互換性、復元基準。
• 準委任の管理：時間、体制、会議、調査範囲、報告、未確定事項の決め方。
• 予算上限：月ごとに成果を確認し、優先順位の変更手順を決める。

要件が固まらないまま固定価格で発注すると、見積側がリスク分を上乗せすることがあります。さらに、後から変更費用が増える可能性もあります。

設定・コード・データ契約の引き渡し対象

引き渡し対象は、再現に必要な成果物と運用手順に分けて定めます。終了時のデータや継続費用も、別に取り決めます。

• 設定とコード：Topic・Partition・ACL、Broker設定、IaC、CI/CD、スキーマ。
• 運用資料：Connector、監視画面、アラート閾値、障害、バックアップ・復旧手順。
• 契約終了時：データ、設定、ログ、アカウント、秘密情報の返却・削除期限。
• 継続費用：利用料、サポート料、保守、時間外単価、更新、追加Connectorを、初期費と分けて示す。

管理画面での手作業の設定が残っていると、担当者の退職やベンダー変更の際に再現できません。

Apache Kafkaのシステム開発費用・相場の目安

Kafka受託開発に特化した国内の公的な相場統計は、まだ限られています。そのため、以下の金額は、2025〜2026年のクラウド料金と、類似する業務システム開発の工数の目安をもとにした推定です。

金額は税別で、個別見積を前提としています。イベント量や既存連携数、可用性によって変わります。個人情報や24時間運用、データ移行の有無も、金額を左右します。この金額は、確定した価格ではありません。

規模別の初期開発費の目安

費用と期間は、規模、連携数、可用性、運用条件によって変わります。次の推定レンジで比べます。

• 小規模PoC・MVP：1〜3 Topic、Producer・Consumer数本で300万〜800万円、2〜4か月程度。
• 中規模本番：3ゾーン、複数Producer・Consumerなどで800万〜2,000万円、5〜9か月程度。
• 大規模・基幹：複数リージョン、数十〜数百連携などで2,000万〜5,000万円以上、9〜18か月程度。

小規模の対象は、単一クラウド、基本監視、再送確認です。イベント定義や接続アプリの改修、負荷試験を含めると、一般的な小規模Web開発より費用が上振れしやすくなります。

中規模では、RDBのCDCやKafka Connectを使い、スキーマ管理と権限、監視を整えます。バックアップや段階リリースも対象に入ります。複数部門や基幹システムをまたぐと、要件整理と移行調整が増えます。

大規模では、厳格なRPO・RTOや監査ログが対象になり得ます。移行や24時間運用、複数ベンダーの統制も含まれます。高可用性と大量転送を同時に求めると、5,000万円を超える場合もあります。

対象範囲を分けて、見積を取ります。

クラウド利用料の転送・保存・接続を含めた試算

開発費とは別に、Brokerやマネージドサービス、ストレージの月額費用がかかります。データ転送やPrivateLinkなどの接続費も、見積に含めます。

• 基盤費：Brokerまたはマネージドサービス、ストレージ。
• 通信・接続費：データ転送とPrivateLinkなど。
• 運用費：監視、バックアップ、Connector、サポート。

Google Cloudの試算は、3ゾーン・3レプリカ、保存24時間を前提としています。Consumerの帯域は、Producerの帯域と同じ値で試算しています。

10MiB/秒では、自前運用が月額0.9Kドル、マネージドが1.1Kドルです（出典: Google Cloud「Managed Service for Apache Kafka pricing」、2026年確認）。

同じ前提で100MiB/秒とすると、自前構成は月額9.1Kドル、マネージドは11Kドルです。これはus-central1の試算で、日本リージョンの見積金額ではありません。

Confluent Cloudの公開価格では、Basicは月額0ドルからです。

Standardは約385ドル、Enterpriseは約895ドル、Freightは約2,300ドルからです。

（出典: Confluent「Pricing」、2026年確認）

1ドル=150円で換算すると、Standardは約5.8万円、Enterpriseは約13.4万円、Freightは約34.5万円です。為替と利用量で変わります。

eCKUやIngress・Egress、保存の費用が加算されます。Connectorや監査ログなどの費用も加わります。最低料金だけを基準に予算を組むと、実際の請求額との差が生じます。

自前運用では、クラウドVM、ディスク、レプリカ間通信を含めます。監視、バックアップ、運用人件費も入れます。

見積を取るときは、次の条件をそろえます。

• 見積条件：1日・1か月の書き込み量、平均・ピーク、イベントサイズ。
• 構成条件：Replication Factor、保持日数、Consumer読み取り量。
• 接続条件：リージョン間転送の有無と、同じ前提での比較。

Apache Kafkaの委託先選定と見積比較のポイント

委託先は、業務イベントを設計し、障害時の挙動を検証し、稼働後も運用できる会社から選びます。候補の3〜5社程度に、同じRFPを渡します。

価格だけでなく、前提条件と体制、成果物も横並びにします。除外範囲や保守費も、並べて比べます。

Kafkaの実績と担当範囲

Kafkaの利用経験だけでなく、担当した規模や業務を確かめます。クラウドや範囲も、あわせて聞いておきます。

• 設計・接続：イベント、Partition、キー、Schema Registry、Connect、Streamsの扱い。
• 運用経験：CDC、負荷・障害試験、移行、24時間保守の経験。
• 類似性：イベント量、既存連携、セキュリティ条件を再現できるかどうか。
• 体制：提案・実装・運用の担当者、一次請け、再委託の有無。

担当範囲は、一般論ではなく具体的な対応で確かめます。面談では、自社の要件に沿った回答を求めます。Consumer停止時の復旧、注文イベントの二重処理、Partition追加後の順序保証について質問し、具体的な対応を聞くと、会社ごとの差が見えやすくなります。

見積書の作業・前提・除外範囲による比較

見積書は、作業と前提、除外範囲を分けて、同じスコープで比べます。

• 開発作業：要件定義、PoC、クラウド・Kafka設計、Producer・Consumer改修ごとの区分。
• 周辺作業：Connector、スキーマ、監視、試験の区分です。移行、教育、PM、保守も分けて示します。
• 比較条件：成果物、職種・稼働月、イベント量、環境、除外作業。

安い見積でも、除外範囲に要件定義や負荷・障害試験が含まれていれば、追加費用が発生します。クラウド料金、監視、移行、引き継ぎも、除外の有無を確かめます。

高い見積には、24時間保守や複数環境、DR、セキュリティ審査が含まれることがあります。そのため、見積の範囲をそろえてから差額を評価します。

障害・セキュリティ・ベンダーロックインのリスク確認

委託先のリスクは、障害対応、セキュリティ、個人情報、引き継ぎ可能性の面から整理します。

• 障害対応：監視、一次対応時間、復旧目標、再処理、DLQ、データ欠損の責任。
• セキュリティ：認証、ACL、TLS、鍵の管理。脆弱性の通知と修正、監査ログ、環境分離も含みます。
• 個人情報：委託先と再委託先の安全管理措置を、契約前に審査します。
• 引き継ぎ：独自依存、データ出力、Topic・設定・IaCの所有者、文書、権限。

Kafka標準のAPIや設定と、独自サービスへの依存範囲を把握しておきます。

Topicとスキーマ、設定の所有者を自社に置きます。IaCや監視については、所有者を自社側で決めておきます。

別の会社でも引き継げるよう、資料とアクセス権を受け取っておきます。クラウド移行だけを目標に据えない点にも注意します。

よくある質問

発注時に迷いやすい質問をまとめました。費用や技術選定は案件ごとに異なるため、自社のイベント量と運用条件に当てはめて確認してください。

Apache Kafkaのシステムは小規模企業でも導入できますか？

導入は可能です。ただし、イベント量と再処理の必要性が小さい場合は、API、バッチ、クラウドのキューサービスが適する可能性があります。

Kafkaを選ぶなら、1業務・少数TopicのPoCで効果と運用負荷を確かめます。マネージドサービスと外部支援を組み合わせると、初期の負担を抑えやすくなります。

Apache Kafkaの開発費用はどのくらいかかりますか？

小規模PoC・MVPは300万〜800万円、中規模の本番連携は800万〜2,000万円、大規模・基幹連携は2,000万〜5,000万円以上が推定レンジです。

この金額は、Kafka専用の公的統計ではなく、類似システムの工数とKafka特有の非機能要件をもとにした目安です。

クラウド利用料や保守、監視、24時間対応、移行は、別費用になることがあります。見積書では、これらを分けて確かめます。

Kafkaのクラスタ構築だけを外注すれば十分ですか？

クラスタ構築だけを外注しても、業務で使うには別の作業が多く残ります。Producer・Consumerの改修やイベント・スキーマ設計が必要になり、再送・冪等性、権限、監視、障害訓練も欠かせません。

データ移行や運用手順も含めて考えます。クラスタ構築だけを頼む場合でも、アプリ側との責任分界と稼働後の窓口を、RFPと契約書で明確にします。テスト環境と本番移行の扱いも、あわせて決めます。

自社運用とマネージドサービスはどちらがよいですか？

運用、監視、障害対応、更新を担う体制があり、環境やデータ配置を細かく制御したい場合は、自社運用が候補です。

運用負荷を抑え、アプリとイベント設計に集中したい場合は、マネージドサービスが候補です。その両者を、総保有コストと障害時の責任分界で比べます。

まとめ

まず、Kafkaを採用する業務と採用しない業務を分けます。そのうえで、イベント量や遅延、順序、保持などを業務ごとに整理します。再処理とRPO・RTOも含めたうえで、運用形態と委託範囲を選びます。

発注前のRFPとPoCによる比較の準備

RFPには、イベント定義、Partitionとキー、スキーマ互換性を記載します。Producer・Consumerの範囲も書き添えます。負荷・障害試験、セキュリティ、監視も含めます。移行、成果物、保守条件も記載します。

3〜5社へ同じ条件で依頼し、見積の前提と除外範囲をそろえます。そのうえで、価格や体制、実績、運用力を比べます。要件が不確かな場合はPoCを準委任で発注し、結果から本番開発の請負範囲を固めます。

運用と引き継ぎまで含めた委託先の選び方

委託先を選ぶときは、業務と運用の設計力、成果物の引き渡し体制を確かめます。

• 説明力：業務イベント、データ契約、障害時の再処理を説明できるかどうか。
• 運用範囲：個人情報、クラウド費用、監視、教育まで扱えるかどうか。
• 納品体制：Topic・ACL・スキーマ・IaC、試験結果、手順を自社へ渡す体制。

契約が終わったあとも、別の担当者が再現できる状態をめざします。Kafkaの導入によって、データ連携の遅延と分断を続けて解消できる体制をつくります。

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

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