選考進捗管理システム開発の発注/外注/依頼/委託方法について

選考進捗管理システムの発注・外注では、候補者のステータスを一覧化するだけでなく、担当者、期限、次のアクション、評価履歴までを業務フローとして設計することが成功の条件です。まずはSaaS、既存パッケージの連携、個別開発のどれが自社の課題に合うかを見極め、必要な範囲に予算を配分することが重要です。

この記事では、選考進捗管理システムを発注・外注する際の進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積比較、導入後の運用まで順に解説します。Excelやメールに分散した採用情報を整理し、社内稟議やベンダーとの初回相談に使える判断材料をまとめています。

▼全体ガイドの記事
・選考進捗管理システム開発の完全ガイド

選考進捗管理システムを発注・外注する全体像

選考進捗管理システムは、応募受付から書類選考、面接、最終判断、内定、入社までの状態を管理する業務システムです。採用管理システム（ATS）の一部として提供されることが多く、候補者、求人、担当者、評価、連絡履歴を一つの流れで扱います。発注時には「候補者を登録できるか」だけでなく、滞留を発見し、誰がいつ対応するかまで追えることを確認します。

採用区分や選考ステージが一般的で、短期間に運用を始めたい企業は、SaaSやパッケージを第一候補にできます。求人作成、応募者管理、評価フォーム、面接予約、メール自動化、ダッシュボードなどを標準機能で利用でき、バックアップや脆弱性対応を提供会社に任せやすい点がメリットです。一方で、独自の承認ルールや人材紹介・派遣の案件マッチングまで標準機能だけで対応できるとは限らないため、運用を合わせられる範囲を先に見極めます。

既存の求人媒体、採用サイト、カレンダー、適性検査、HRISなどをつなぎたい場合は、SaaSを中心にAPI・CSV連携を追加する方法が現実的です。人材紹介・派遣会社のように求人案件と候補者の組み合わせ、顧客向けポータル、独自の歩留まり指標、複数法人の複雑な権限が競争力に直結する場合は、受託による個別開発も候補になります。ただし、標準ATSで足りる機能まで作り込むと、初期費用だけでなく保守とベンダー依存も増えるため、独自開発の理由を一機能ずつ説明できる状態にします。

発注前に行う要件整理とRFPの作り方

発注先に丸投げするためのRFPでは、提案の良し悪しを比較できません。RFP（提案依頼書）は、解決したい業務課題、対象範囲、現状のデータ、希望する期限、予算の考え方、提案してほしい項目を同じ条件で伝える文書です。完成した仕様書を作る必要はありませんが、発注者側で業務の事実と優先順位を整理しておく必要があります。

最初に「応募受付→書類選考→面接調整→評価→合否通知→内定→入社」の流れを、採用担当、面接官、現場責任者、エージェントの役割ごとに書き出します。各ステージで、入力する項目、担当者、対応期限、通知先、例外処理、次のステージへの条件を整理します。たとえば「一次面接後48時間評価が未入力なら面接官と採用担当へ通知する」と定義すれば、単なる一覧表示ではなく、SLAに沿った進捗管理として要件化できます。

併せて、月間応募数、採用人数、求人媒体数、エージェント数、拠点数、面接官数、新卒・中途・アルバイトの比率を集計します。候補者のステータスが更新されない、評価がメールや紙に残る、媒体ごとに項目が異なる、同じ候補者へ二重連絡する、といった事象を件数や作業時間で記録すると、導入効果と優先順位を説明しやすくなります。

RFPには、目的と背景、対象ユーザー、対象業務、機能要件、外部連携、移行対象、希望スケジュール、運用体制、見積条件を記載します。機能要件は「候補者を登録できる」ではなく、「媒体から取り込んだ候補者を重複判定し、応募職種ごとの選考フローへ振り分け、担当者と次回期限を表示する」のように、業務結果まで書くと提案比較が具体的になります。

非機能要件には、組織・拠点・職種・候補者単位の権限、MFAやSSO、通信・保存時の暗号化、操作ログ、バックアップ、障害時の復旧目標、データのエクスポートと削除を含めます。履歴書、職務経歴書、面接評価、音声や動画を扱う可能性があるため、個人情報の利用目的、保存期間、削除ルール、再委託先、データ保管地域も発注前に確認します。個人情報保護委員会の通則ガイドラインでは、個人に関する評価や映像・音声も個人情報に含まれ得ると整理されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

要件を満たしたかを判断するため、受け入れ条件を業務シナリオで定義します。たとえば「求人を登録し、応募者を取り込み、重複候補者を確認し、面接日程を確定し、評価入力後に合否通知を送る」という一連の操作を、採用担当者と面接官が実際に行えることを確認します。画面が表示されるだけでなく、権限のない人には評価が見えないこと、通知が二重送信されないこと、連携失敗が記録され再送できることも合格条件に含めます。

KPIは、初回連絡までの時間、ステージ滞留日数、評価回収率、面接設定までの時間、辞退率、媒体別の通過率、採用担当者の転記時間などから選びます。全部を最初から追うのではなく、現在の課題に直結する3〜5個に絞ります。発注前に現状値を測っておくと、導入後に「便利になった」という感想だけでなく、改善の有無を判断できます。

発注形態はSaaS・連携・スクラッチを段階で選びます

発注形態の選択では、機能数ではなく、業務をどこまで標準化できるか、既存システムをどこまで活かすか、独自業務が競争力に直結するかを判断します。標準機能で始めて効果を測り、足りない部分だけ連携や追加開発に進む段階導入は、初期投資と運用リスクのバランスを取りやすい方法です。

応募者管理、求人管理、選考ステージ、評価フォーム、面接予約、候補者への連絡といった標準的な採用業務が中心なら、SaaSが候補になります。初期費用や開発期間を抑えやすく、機能更新やセキュリティ対応を自社だけで抱え込まずに済みます。デモでは機能一覧を見るのではなく、自社の代表的な一件を応募受付から合否通知まで操作し、面接官やエージェントも迷わず使えるかを確認します。

既存の採用サイトや求人媒体を残したい場合は、ATSを中心にAPIやCSVで連携する方法を検討します。見積時には、候補者ID、求人ID、ステージ名、応募経路、重複判定、更新方向、連携頻度、失敗時の再送方法を明示します。「API連携可能」という説明だけでは、どの項目をどのタイミングで同期できるか分からないため、サンプルデータと連携一覧を提示してもらいます。

連携が増えるほど、サービス間で同じ候補者を別人として登録するリスクや、片側だけ更新される不整合が生じます。連携元を一つに決めるマスター項目、エラー通知の担当者、再送の操作、障害時の手作業をRFPに含めます。連携費用を初期開発費だけでなく、仕様変更時の保守費としても見積もることが大切です。

人材紹介・派遣の案件マッチング、顧客企業向けの候補者ポータル、複数法人の権限、独自の評価基準、採用後の人材データ連携など、標準ATSでは業務を変えにくい領域がある場合は個別開発を検討します。最初から全機能を作るのではなく、第1段階で候補者・求人・選考ステージ・評価の共通データを整え、第2段階で日程調整や通知、第3段階で分析やHRIS連携を追加する構成が適しています。

個別開発では、業務知識を持つプロジェクト責任者を発注者側に置き、要件の優先順位を決め続ける必要があります。受託会社に任せれば自動的に業務が整理されるわけではありません。経営、採用、人事、現場、情報システム、法務の判断者を明確にし、仕様変更を承認するルールを整えます。

契約形態は請負・準委任・SaaS契約の違いを確認します

契約形態は支払方法の違いだけではなく、成果物、責任範囲、仕様変更の扱い、検収、リスク分担を決めるものです。選考進捗管理システムは要件が固まっている部分と、実際の運用で調整したい部分が混在しやすいため、工程ごとに契約を分ける考え方が有効です。契約書は自社の法務または専門家にも確認してもらいます。

請負契約は、合意した成果物を完成させ、発注者が検収する工程に向いています。画面、API、データ移行、操作マニュアル、テスト結果、ソースコードや設計書など、何を納品物とするかを契約書や仕様書に書きます。検収期間、指摘できる不具合の定義、修正期限、受け入れられない場合の扱いも曖昧にしないことが重要です。

要件が未確定のまま「一式」で請負契約を結ぶと、仕様変更が追加費用や納期延長につながりやすくなります。要件定義を準委任で行い、仕様が固まった実装部分を請負にするなど、確定度に応じて分ける方法もあります。見積書に含まれる前提条件と、含まれない作業を必ず確認します。

準委任契約は、要件定義、業務整理、アジャイル開発、運用改善のように、専門家が一定期間の業務を支援する工程に向いています。成果物の完成を一律に保証する契約ではないため、稼働時間、担当者、会議体、報告内容、作業範囲、品質確認の方法を明示します。発注者が優先順位を変更しながら、実際の利用者の反応を見て改善する場合に活用しやすい契約形態です。

準委任だから責任が曖昧になるわけではありません。課題管理表、意思決定ログ、週次報告、リスク一覧、次回までの成果物を運用に組み込みます。特に候補者データを扱うシステムでは、開発会社だけでなく、クラウド、メール、SMS、外部連携先など各委託先の責任範囲を契約上も整理します。

SaaSを発注する場合は、月額料金だけでなく、課金単位、最低利用期間、ユーザー数・応募者数・採用区分による変動、オプション、初期設定、データ移行、サポート範囲を確認します。解約時に候補者データをどの形式で返却できるか、返却後にベンダー側のデータがいつ削除されるか、APIやエクスポートに追加費用がかかるかも重要です。

セキュリティの確認では、ISO/IEC 27001、27017、27701などの認証取得の有無だけでなく、認証の対象範囲、データ保管地域、再委託、障害通知、復旧目標、脆弱性対応、管理者権限の記録を質問します。認証があることだけで自社の要件を満たすとは限らないため、RFPの非機能要件と一項目ずつ照合します。

選考進捗管理システムの発注・外注を進める手順

発注先を決めた後は、要件定義、設計・開発、テスト、移行、リリース、運用改善の順で進めます。工程を短く見せるために要件定義を省くと、選考ステージや権限の認識違いが後工程で発覚します。小さな検証を挟みながら、業務と画面を対応させていくことが大切です。

候補会社は、SaaS提供会社、連携に強い導入支援会社、業務システムの受託開発会社など、発注形態の異なる相手を含めて比較します。RFPを渡すときは、質問の締切、提案書の形式、見積の分け方、デモで確認したいシナリオ、プレゼンテーションの時間をそろえます。提案段階で仕様を無償で作り込ませすぎず、要件定義が必要なら有償の企画フェーズとして切り出します。

契約後の要件定義では、候補者、求人、応募経路、選考ステージ、評価、面接予定、連絡履歴のデータ項目を確定します。候補者を複数求人へ応募させるのか、同じ候補者を別法人で共有できるのか、内定後にどのデータをHRISへ渡すのかなど、後から変更しにくい関係性を先に確認します。画面設計では、採用担当者の一覧、面接官の評価画面、現場責任者の承認画面を利用者別に作成します。

例外処理も設計対象です。候補者が日程を変更した場合、面接官が評価を差し戻す場合、エージェントから同じ人が再推薦された場合、連携が失敗した場合、採用区分を途中で変更する場合に、誰が何を操作するかを決めます。通常フローだけでデモを行うベンダーには、例外シナリオも見せてもらいます。

テストでは、機能、権限、通知、API、負荷、バックアップ、監査ログを確認します。特に「評価未入力のまま次へ進めない」「退職者アカウントを停止できる」「候補者本人の情報を権限外の面接官が見られない」といった業務上の制約を、実データに近いテストデータで検証します。受け入れテストは開発会社任せにせず、採用担当と面接官が実際の業務シナリオを操作します。

データ移行は、項目の対応表、文字コード、日付形式、重複判定、添付ファイル、同意情報、削除対象を決めてから行います。最初から全件を移すのではなく、少量のデータで試行し、名寄せと権限を確認します。可能であれば一部の採用区分や中途採用から並行稼働を始め、現場の問い合わせと運用ルールを整理してから対象範囲を広げます。

選考進捗管理システムの費用相場と見積の内訳

費用は、利用する候補者数やユーザー数だけでなく、要件定義、画面数、外部連携、権限、データ移行、セキュリティ、テスト、教育、保守で変わります。公開料金と個別開発の見積は前提が異なるため、単純に月額と開発費を並べるのではなく、初期費用、月額・年額、移行・連携費、保守費、5年間の運用費を同じ表にして比較します。

公開例として、Thinkings株式会社のsonar ATSは初期費用なし、基本プラン月額2.2万円からと案内しています。求人作成、応募者管理、採用フロー構築、連絡自動化、評価フォーム、ダッシュボードなどが基本範囲に含まれ、採用AI、LINE連携、適性検査、面接官アサインなどはオプションとして案内されています（出典: Thinkings株式会社「sonar ATS 料金」、2026年確認）。この例から、標準機能で選考進捗管理を始める入口は月2万〜10万円前後を検討できますが、実際の金額は採用規模、課金単位、オプション、初期設定、移行、連携で変動します。

月額だけで安いと判断せず、初期設定の支援、求人媒体との連携、過去データ移行、操作研修、追加ユーザー、保存容量、サポートの時間帯を確認します。SaaSの料金表がダウンロード式の場合は、公開ページの数字だけで社内稟議を作らず、見積書に含まれる範囲を確認してから予算化します。

個別開発の公開目安では、小規模300万〜600万円、中規模600万〜1,200万円、大規模1,500万円以上というレンジが示されています（出典: 株式会社ripla「採用管理システムの開発方法・手法・工程・手順や進め方」、2026年3月11日公開）。これは公的統計ではなく、受託開発会社が公開する実務上の目安であり、個別案件の見積を保証するものではありません。

選考進捗管理システムに当てはめる場合、候補者登録、ステータス管理、検索、基本一覧、CSV出力に絞る小規模MVPは300万〜800万円程度、面接日程、評価フォーム、メール自動化、媒体・カレンダー・適性検査連携、ダッシュボードを含む中規模は800万〜2,500万円程度が一つの予算検討レンジになります。複数法人、複数拠点、エージェントポータル、HRIS連携、複雑な権限、過去データ移行、監査・高可用性まで含む大規模では2,500万〜5,000万円以上を見込むケースがあります。これらは公開されたATS開発費用と類似業務システムの知見を組み合わせた推定であり、機能と前提条件を付けて利用します。

個別開発では、初期開発費のほかに、年間保守、クラウド、監視、メールやSMSの送信費、脆弱性対応、法改正対応、追加連携、問い合わせ対応が発生します。年間保守は初期開発費の10〜20％程度を置く実務的な見方がありますが、契約内容や稼働時間で変わるため、レンジとして確認します。SaaSでも初期設定、移行、オプション、追加ユーザーを含めた年額を計算します。

見積書では「開発一式」ではなく、要件定義、設計、実装、連携、移行、テスト、教育、リリース支援、保守を分けてもらいます。各項目の数量、単価、前提、除外事項、追加時の単価、納期への影響が分かれば、要件を削る場合も優先順位をつけやすくなります。安い見積が、移行やテストを発注者の作業として除外していないか確認します。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や機能数だけでなく、選考業務を理解し、導入後の運用まで支援できるかで選びます。SaaS提供会社と受託開発会社は役割が異なるため、同じ評価軸に当てはめるのではなく、自社の発注形態に合う質問を用意します。提案書の美しさより、できること・できないこと・追加費用になることが明確かを重視します。

実績を聞くときは、「採用管理システムを作ったことがあるか」だけで終わらせません。候補者と求人をどのように紐付けたか、面接官の評価をどう回収したか、媒体やカレンダーとどう連携したか、データ移行で何が難しかったか、導入後にどのKPIを測ったかを確認します。可能であれば、公開事例だけでなく、担当するプロジェクトマネージャーや技術責任者との面談を行います。

提案デモでは、自社の代表的なシナリオを操作します。エージェントから候補者を受け付け、重複を確認し、面接官の予定を調整し、評価未入力を通知し、合否を記録する流れです。人材紹介・派遣であれば、求人企業、案件、推薦、成約の関係も見せてもらいます。担当者が説明しないと使えない操作が多い場合は、定着支援の費用と体制を確認します。

複数社の見積を比べるときは、要件定義、設計、実装、連携、データ移行、テスト、教育、保守を同じ行に並べます。単価と工数だけでなく、担当者の経験、再利用できるテンプレート、品質保証、プロジェクト管理、リリース後の支援も確認します。見積差が大きい場合は、機能の解釈、非機能要件、移行データの件数、テスト範囲、サポート期間のどこが違うのかを質問します。

「一式」「別途相談」「必要に応じて」といった記載が多い見積は、契約後に追加費用が発生する範囲が見えません。含む・含まない・前提・変更時の算定方法を文書で明確にしてもらいます。SaaSの場合は、候補者数、ユーザー数、採用区分、オプション、最低利用期間、解約時のデータ返却を同じ比較表に記載します。

選考情報には、連絡先、職歴、評価、採否理由などの機微性が高いデータが含まれます。委託先には、権限設計、ログ、暗号化、バックアップ、脆弱性診断、インシデント時の連絡、再委託、データ削除証明、従業員のアクセス管理を質問します。発注者側の設定ミスで情報が公開される可能性もあるため、管理者権限を誰が持ち、退職者アカウントをいつ停止するかまで決めます。

採用AIで書類を要約したり、候補者を検索したり、面接内容を分析したりする場合は、AIが最終判断をしない運用、人による再確認、説明可能性、誤判定時の訂正、学習利用の有無、候補者への通知を確認します。経済産業省が2026年3月31日に公表したAI事業者ガイドライン第1.2版では、人間中心、公平性、透明性・説明責任、プライバシー・セキュリティなどが確認軸として示されています（出典: 経済産業省「AI事業者ガイドライン第1.2版」、2026年）。AI機能を追加する場合は、便利さだけでなく、採用判断の記録と監査方法も見積条件に含めます。

導入事例から学ぶ発注後の運用改善

発注先を決めてシステムをリリースしても、入力されなければ選考進捗は改善しません。導入初期は、利用者が迷う画面や入力項目を見つけ、通知のタイミング、ステージ名、評価基準、権限を調整します。機能の完成度だけでなく、採用担当者と面接官が日常業務の中で使い続けられるかを検証します。

sonar ATSの公式導入事例では、SB C&S株式会社がまず通年稼働する中途採用から導入し、職種ごとのフローや面接官の調整を実際の採用業務で整えたと紹介されています。Googleカレンダーとの同期で面接官の調整と通知を効率化し、エージェントとの連絡履歴や候補者・選考ステータスを一元化した事例です（出典: sonar ATS「SB C&S株式会社導入事例」、掲載情報を2026年確認）。

同事例では、新卒採用への展開後、フォローアクション機能による自動通知で、一次面接から最終までの歩留まりが約60％から約90％になったという顧客談も掲載されています。この数値は特定企業の事例であり、すべての企業に同じ効果が出ることを示すものではありません。発注時には成功数値をそのまま約束させるのではなく、自社の初回連絡時間や評価回収率を測る設計に落とし込みます。

AIを使う場合は、応募書類の要約、面接評価の抜け漏れ検知、候補者への定型案内、滞留候補者の抽出など、人が確認しやすい補助用途から始めます。合否の自動決定や候補者の順位付けを導入する場合は、学習データの偏り、評価項目の妥当性、誤判定の確認、判断理由の記録、利用停止の手順を事前に定めます。ベンダーが入力データをモデル学習に使うかどうかも、契約前の質問項目です。

AIを導入しない場合でも、候補者の個人情報を扱う基本的な権限、保存期間、削除、委託先管理は必要です。発注者、開発会社、SaaS、外部連携先の誰がどのデータにアクセスするかを一覧にし、監査ログで追跡できるようにします。機能追加のたびにプライバシーと公平性への影響を確認する運用を、リリース後の保守契約に含めます。

リリース後は、初回連絡までの時間、ステージ滞留日数、評価の期限内入力率、面接設定時間、辞退率、媒体・エージェント別の通過率を定期的に確認します。数値が改善しない場合は、システムの機能不足だけでなく、ステージが細かすぎる、評価項目が多すぎる、担当者が曖昧、通知が多すぎるといった運用要因も調べます。月次で採用担当者と面接官の声を集め、変更の効果を確認します。

開発会社との保守会議では、問い合わせ件数、障害、連携失敗、アカウント棚卸し、バックアップ結果、脆弱性対応、次回の改善候補を共有します。契約終了やベンダー変更に備え、データのエクスポート、ソースコードや設計書の扱い、アカウントの移管方法も確認しておくと、長期的なベンダーロックインを抑えられます。

よくある質問（FAQ）

ここでは、選考進捗管理システムの発注・外注を検討する企業からよく寄せられる質問に回答します。費用や期間は要件で変わるため、公開されている料金や事例は自社の条件に置き換えて確認します。

標準的な採用フローを短期間で始めたいならSaaS、独自の案件マッチングや複雑な権限、既存業務との深い連携が競争力になるなら個別開発が向いています。まず標準SaaSで候補者・求人・選考ステージ・評価を整え、不足する領域だけAPI連携や追加開発で補う段階導入も有効です。

個別開発では、小規模MVPを300万〜800万円程度、中規模を800万〜2,500万円程度、大規模・複数法人を2,500万〜5,000万円以上とする推定レンジがあります。公開されたATS開発費用と類似業務システムから整理した目安で、要件定義、連携、移行、テスト、権限、保守の前提で変わります。SaaSは初期費用なし・月額2.2万円からという公開例もありますが、オプションや利用規模を含む総額で比較します。

自社に近い採用業務の実績、担当者の体制、できることとできないこと、データ移行と外部連携の範囲、セキュリティ、保守、解約時のデータ返却を確認します。見積は要件定義、開発、移行、テスト、教育、保守に分けてもらい、各社が同じ前提で提案しているかを確認すると比較しやすくなります。

AIを補助用途で利用することは可能ですが、合否判断をAIだけに任せず、人が確認して修正できる仕組みを設けます。学習利用、個人情報の取り扱い、候補者への説明、評価の偏り、判断ログ、誤判定時の再確認手順をベンダーに質問し、AI事業者ガイドライン第1.2版の観点で社内ルールを整えます。

まとめ

選考進捗管理システムの発注・外注では、最初に現行フローを整理し、候補者、求人、ステージ、評価、担当者、期限を共通の業務データとして定義します。そのうえで、標準化できる範囲はSaaS、既存ツールを活かす部分は連携、独自業務が価値になる部分は段階的な個別開発として切り分けます。

RFPには、業務課題、現行フロー、対象ユーザー、データ項目、外部連携、権限、個人情報、AI利用、移行、テスト、受け入れ条件、KPI、保守、解約時のデータ返却を記載します。見積は初期費用だけでなく、月額・年額、移行・連携、教育、保守、クラウドや通知の運用費まで含めたTCOで比較します。価格差があれば、機能の解釈や除外項目を確認します。

最初から全社・全採用区分を対象にせず、課題が明確な中途採用や一つの拠点で、初回連絡時間や評価回収率を測りながら始めると、導入後の改善点が見えやすくなります。機能の多さではなく、選考の滞留を減らし、採用担当者と面接官が次のアクションを迷わず実行できる委託先を選ぶことが、発注成功への近道です。

▼全体ガイドの記事
・選考進捗管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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