手続管理システムの発注・外注は、申請フォームだけでなく承認から証跡保管までを整理し、必要な範囲を決めてから委託する流れです。
費用は手続数や連携、データ移行の量で変わります。特定業務に絞った小規模な刷新は300万〜1,500万円、契約・法務手続を統合する標準規模は1,500万〜4,000万円が目安です。
▼全体ガイドの記事
・手続管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
手続管理システムを発注する前に整理すべき全体像
手続管理システムとは、申請や届出の受付から承認・審査、通知、完了、文書保管、更新期限の管理までを、一つの流れとして扱うシステムです。
発注前に対象範囲を定義しないと、ワークフロー製品の導入なのか、業務システムの新規開発なのかが曖昧になります。そのため、委託先から比較できない見積もりが出てきます。
社内と行政・対外の手続を分けて考えると、「作ったのに現場で使えない」「見積もり以外の費用が膨らむ」といった失敗を防ぎやすくなります。
社内申請・契約・法務手続を対象にする場合
社内向けでは、稟議や契約審査、法務相談が対象になります。ほかにも、購買申請、人事申請、押印申請などが含まれます。
- 申請受付：申請者、対象、期限の登録
- 審査・承認：担当者と承認経路の管理
- 証跡保管：判断と添付書類の追跡
承認の流れは、申請者、担当部署、承認者に分けて定めます。審査者と最終決裁者も区別したうえで、金額や契約種別による条件分岐を決めます。さらに、代理承認、差し戻し、督促の条件も定義します。
契約書や本人確認書類を添付する場合は、申請データと文書を関連付けます。そのうえで、誰がいつ閲覧、承認、変更したかを監査ログとして残す設計が必要です。
この領域では、既存の人事・会計システムとの連携が費用を左右します。販売や電子契約サービスとの連携も、範囲を先に決めておく必要があります。
社員マスタを毎日同期するのか、申請完了時に会計へ連携するのか、APIが使えない場合はCSVを介するのかを、発注前に決めておきます。そのため、連携部分の見積もりが安定します。
行政・対外手続を対象にする場合
自治体や事業者向けの手続では、住民・申請者が使う画面と、職員が審査する画面を分けて考えます。手続には、本人確認、添付書類の補正依頼、審査の差し戻しが含まれます。さらに、結果通知や台帳連携まで扱うため、社内ワークフローの延長では要件を満たせない場合があります。
デジタル庁は、2026年6月更新の「行政手続のオンライン化」で、スマートフォンなどで手続が完結することを目指しており、自治体のオンライン申請の拡大も進めています。この動向を踏まえ、スマートフォン対応や本人確認方式をRFPに含めることが大切です。根拠として、デジタル庁「行政手続のオンライン化」、2026年を参照しています。
行政・対外手続では、受付番号、申請者への通知、審査担当者の権限を後から追跡できる必要があります。処理期限と問い合わせ履歴も、追跡できるように残しておきます。マイナンバーカードや既存台帳との連携を予定する場合は、利用するAPIと認証の方式、エラー時の再送、データの保管場所を発注条件に書き、実績のある委託先へ確認します。
手続管理システムの発注形態の選び方
発注形態は、標準機能に業務を合わせられるか、独自の審査や連携が必要かで選びます。
手続数が少なく、早期に効果を確認したい場合は、SaaS・パッケージやローコードが候補になります。法務統制や複雑な外部連携が競争力に直結する場合は、カスタム開発を選びます。
最初からスクラッチ開発に決めず、Fit & Gapで標準機能と独自開発の境界を見極めます。
SaaS・パッケージを導入する発注
SaaSやパッケージは、申請や承認、通知などの共通機能を短期間で使い始められる方法です。料金を比較するときは、ライセンスだけでなく、初期設定、フォーム作成、権限設定の費用を合算します。さらに、データ移行、教育、追加連携の費用も含めます。
例えばkintoneは、2026年8月確認時点で、初期費用無料、1ユーザー単位の月額がライトで1,000円、スタンダードで1,800円、ワイドで3,000円です（税抜、最低10ユーザー）。一方で、実際の申請アプリ設計や電子契約連携は別途必要になるため、ライセンス価格をそのまま導入費用とみなすのは避けます。根拠として、サイボウズ株式会社「kintone 料金」、2026年8月確認を参照しています。
標準の承認経路に業務を合わせられる企業や、まずは1〜3種類の手続で試したい企業に適しています。ただし、製品の標準機能を超える複雑な審査、案件単位の細かな権限、大量文書の特殊な検索を無理に追加すると、カスタマイズ費用と将来の保守負担が増えます。
ローコードで内製・共同開発する発注
ローコードは、フォームや一覧、簡単なワークフローを自社で変更しやすく、現場の改善サイクルを回しやすい方法です。業務部門が手続マスタや承認経路を管理し、委託先が初期設計、連携、権限を支援する分担もできます。移行も、委託先が支援する形にできます。
発注時には、納品物にアプリ設定だけでなく、設計書、権限一覧、データ定義を含めます。さらに、変更手順と管理者教育も含めます。一方で、製品のAPI制限、添付容量、検索性能は、事前に検証が必要です。
権限の粒度や監査ログの保存期間も、検証の対象に入れます。ローコードの費用は、安いと決めつけず、プラグイン費や連携コネクタ、専門会社の支援費まで含めて比較します。将来の運用担当者の工数も、同じ比較に入れます。
スクラッチ開発を委託する発注
スクラッチ開発は、独自の審査ルールや複数法人の権限、特殊な文書管理など、標準製品に合わせることが難しい場合に選びます。行政・基幹システムとの連携が必要な場合も、この条件に含まれます。
申請ID、手続種別、担当部署をデータとして分けて持ちます。ステータス、期限、文書IDも、別々のデータとして持ちます。承認履歴も含め、変更されやすい業務ルールを設定値として管理できる構成にすると、法令改正や組織変更に対応しやすくなります。
ただし、要件を固める前の一括請負は、仕様変更や例外処理が増えたときに追加費用が発生しやすい方法です。初期の企画・要件整理は準委任で進め、機能が確定した部分から請負に切り替える段階発注も有効です。また、自社が業務上譲れない統制と、製品に合わせられる部分を分けて、開発会社に提示します。
手続管理システムの発注・外注の進め方と順番
発注は、現状把握と対象範囲の決定から始め、RFP作成、提案・見積比較、契約へと進みます。その後は、要件定義、設計・開発、テストへと進み、移行・教育、運用評価で締めくくります。
開発会社へ相談する前に、自社で手続の一覧と困っている点を整理するだけでも、提案を比べやすくなります。
現状の手続と課題の洗い出し
まず、手続ごとに手続名、申請者、受付方法、承認者を記録します。処理期限、添付書類、保存年限のほか、利用しているExcelやメール、連携先も書き出します。担当者へのヒアリングでは、「通常時の流れ」だけでなく、例外も聞き出します。
例外には、差し戻し、代理承認、緊急処理、担当者の異動、申請の取り下げなどがあります。さらに、月間件数、平均処理時間、期限超過件数、差し戻し率を現状値として残すと、導入後の効果測定に使えます。対象手続が10種類以上ある場合でも、最初からすべてを同じ優先度にはしません。
先行候補には、処理量が多い手続、ミスや期限超過の影響が大きい手続、関係部署が多い手続、標準化しやすい手続を選びます。そのうえで、代表的な1〜3種類をPoCの対象にすると、業務部門が実際に使えるかを確認しながら要件を調整できます。
Fit & GapとPoCによる発注範囲の絞り込み
候補のSaaSやパッケージを選んだら、現状業務を製品の標準機能でどこまで処理できるかを確認します。申請フォーム、条件分岐、代理承認、通知、全文検索を、同じシナリオでデモしてもらいます。CSV出力、SSO、監査ログ、電子署名連携についても、デモしてもらいます。
各機能は、標準、設定変更、追加開発、不可能の4段階で記録します。PoCでは見た目だけでなく、実データに近い添付文書、権限の異なる利用者、差し戻し、期限超過、担当者変更を試します。性能や検索精度を確認し、処理時間、入力漏れ、差し戻し率、利用者の操作負担を測ります。
PoCの結果をRFPの別紙に反映し、契約後に「想定外の追加要件」とならないようにします。
移行・教育・リリースを含む発注範囲
移行は発注範囲の一部として、過去の申請書や契約書をどこまで移行するかを決めます。移行対象の期間、文書の形式、ファイル名、必須メタデータは、文章で決めておきます。重複や欠損の扱い、移行後の検索確認も、あわせて決めます。
移行データを委託先へ渡す場合は、受け渡し方法、アクセス権、保管期間を確認します。返却と削除の証跡も確認します。リリース前には、業務部門による受入テスト、権限テスト、障害時の復旧テスト、通知の到達確認を実施します。
操作マニュアルを納品しても定着しにくいため、教育を計画しておく必要があります。教育は、申請者向け、承認者向け、管理者向けに分けます。問い合わせ対応と旧システムの停止時期まで計画します。
RFPと要件整理の書き方
RFPは、開発会社に「何を作ってほしいか」だけでなく、「なぜ必要か」「どの条件で提案を比較するか」を伝える文書です。
会社ごとに前提が違うまま提案を受けると、安い見積もりが機能不足、高い見積もりが過剰設計になりやすいため、要求と評価基準をそろえます。
手続単位の業務要件一覧
業務要件には、手続名、対象者、申請項目と、その必須・任意の別を記載します。添付書類、承認経路、条件分岐、差し戻し条件も記載します。通知先、処理期限、保存年限、検索条件、出力帳票も含めます。
手続マスタを管理者が変更できるのか、変更時に承認が必要なのかも決めます。過去の申請に影響させないかも、決めておきます。特に重要なのは例外処理で、「部長が不在なら代理承認」「一定金額以上は法務審査」といった条件を文章で書き、通常フローと区別します。
添付不備なら申請者へ補正を依頼し、期限を超えたら管理者へ引き上げる、といった条件も書きます。例外を後から追加すると、テストと見積もりが膨らむため、頻度の高い例外は初期要件に含めます。
非機能要件とセキュリティ要件の記載
機密文書を扱う手続管理システムでは、機能要件に加えて非機能要件とセキュリティ要件で委託先を比べます。利用者数と同時接続数、稼働時間、障害時の復旧目標をRFPに記載します。バックアップ、通信・保存時の暗号化、MFAやSSO、IP制限も記載します。
権限レビュー、監査ログの改ざん防止、ログの保存期間、脆弱性対応、データ所在も含めます。個人情報を含む場合は、再委託管理、従業者のアクセス制御、インシデント発生時の報告期限を確認します。調査協力や、契約終了時の返却・消去も確認します。
個人情報保護委員会も、クラウド環境を利用するサービスでは安全管理措置や委託先管理を確認する考え方を示しています。RFPの質問票と契約書の安全管理条項を連動させ、提案書にある「セキュリティ対応済み」の一文を、具体的な対応まで確かめます。根拠として、個人情報保護委員会「クラウド環境を利用して開発・提供する場合の留意点」を参照しています。
納品物と提案条件の統一
RFPでは、画面やプログラムだけでなく、要件定義書、画面・データ・権限の設計書、テスト仕様書と結果を納品物として指定します。さらに、移行計画、操作マニュアル、運用手順、API仕様を含めます。ソースコードや設定情報の扱いも、納品物の条件に入れます。
クラウドサービスの場合も、データをどの形式で返却できるか、契約終了後にいつ消去されるかを確認します。提案書の提出形式もそろえ、初期費用、月額・年額、ライセンス、導入支援を分けてもらいます。データ移行、連携、教育、保守、追加開発単価も分け、標準機能と個別開発を区別して記載してもらいます。
さらに、前提条件、除外項目、顧客側の作業、納期を、同じ章立てで求めます。体制、類似事例、想定リスクも同じ章立てで求めると、金額だけに引っ張られない比較ができます。
請負と準委任の契約形態の使い分け
契約形態は、成果物を完成させる段階と、要件を探索しながら支援する段階で分けて考えます。
請負は合意した仕事の完成を目的にしやすく、準委任は善管注意義務のもとで調査・設計・助言・開発作業を委託する形にしやすい契約です。
契約の名称だけでなく、成果、責任範囲、検収、報酬、変更手続を、契約書と個別仕様書で確認します。
請負契約に向く範囲と注意点
要件、画面、連携、テスト条件、納期が確定している開発や、確定した機能単位の追加開発は請負契約に向いています。検収基準を明確にできるため、発注側は完成状態を判断しやすくなります。ただし、仕様書にない変更を無償対応と期待すると、品質低下や追加請求につながります。
請負で発注する場合は、受入テストの観点、重大障害の定義、修補期限を定めます。検収の期限と、仕様変更の承認フローも決めておきます。文書移行や外部システム連携は、相手方のデータ品質やAPI仕様に左右されるため、完成責任の範囲と発注者側の協力事項を切り分けます。
準委任契約に向く範囲と注意点
業務ヒアリング、現状分析、要件定義など、進めながら内容が具体化する作業は、準委任契約が適しています。製品選定、PoC、アジャイル型の機能改善も、同じ準委任の対象になります。作業時間や体制に対して報酬を支払う形になりやすいため、月ごとの成果報告、稼働上限、会議体を設けます。
意思決定者や課題管理表も、あわせて設けます。準委任は、品質の責任が免除される契約ではありません。品質への責任は残るため、合意した作業内容と専門家としての説明責任を明文化します。成果物のレビュー方法、知的財産権、秘密保持、再委託、情報セキュリティも、契約に盛り込みます。
IPAの「情報システム・モデル取引・契約書」では、受託開発の段階や請負・準委任の組み合わせを整理しているため、契約交渉のたたき台として参照できます。根拠として、IPA「情報システム・モデル取引・契約書」、2025年版資料を参照しています。
要件定義と開発の段階発注
手続管理システムでは、現場の例外やデータ移行量が要件定義の途中で判明しやすいため、企画・現状分析、要件定義、開発・導入、保守を分ける段階発注が有効です。最初の契約では、全期間の仕様と金額を固定せず、各段階の成果物と次段階へ進む判断基準を決めます。
段階発注では、成果物の所有権、既存設定の再利用、途中解約時のデータ返却を先に確認します。また、次の開発会社へ引き継ぐ資料と、追加見積もりの単価も確認します。
発注先を一社に固定する場合でも、データ形式やAPI仕様を自社で把握し、ベンダーロックインを避けるための出口条件を契約に入れます。
手続管理システムの発注費用・外注費用の相場
手続管理システムの受託開発費用には、公的な一律の相場がありません。リサーチノートの一次Q&Aをもとに、手続数、利用者数、承認分岐を変数とした推定レンジを示します。連携数と文書移行量も、変数に含めています。
実際の予算は、同じRFPで複数社から見積もりを取り、前提条件と除外項目を比較して決めます。
開発規模別の費用レンジ
1〜3種類の申請フォーム、単純な承認、検索、通知、CSV出力を中心とする小規模な刷新は、300万〜1,500万円が目安です。10〜50種類程度の手続、複数部署の条件分岐、添付文書を含む標準規模では、1,500万〜4,000万円が目安になります。この規模には、権限、監査ログ、基幹連携、過去データ移行も含まれます。
行政向けの外部申請、本人確認、審査を含む場合は、4,000万円超を想定して予算枠を検討します。複数台帳、強い可用性、災害対策まで含める場合も、4,000万円超を想定します。この金額は、業務システム刷新に関する一次Q&Aの整理を対象領域に当てはめた推定値で、特定の金額を断定するものではありません。
RFPでは、手続数、利用者数、連携先を明示します。文書件数、保存期間、必要な可用性も示し、レンジのどこに位置するかを説明してもらいます。
SaaS・パッケージの初年度総額
公式料金が公開されている製品は、ライセンス部分のベンチマークになります。例えば住友電工情報システムの楽々WorkflowII Cloudは、公式ページで初期費用5万円、基本料金月1万円、1ユーザー月500円と案内されています。50ユーザーなら月額は3万5,000円、初年度のライセンス部分は47万円となりますが、税抜であり、導入支援、連携、追加オプションは別途確認が必要です。
オンプレミス版は、基本ライセンス300万円からと案内されています。根拠として、住友電工情報システム「楽々WorkflowII 価格・ライセンス体系」、2026年8月確認を参照しています。kintoneは最低10ユーザーで、ライトならライセンスだけで月額1万円、スタンダードなら月額1万8,000円、ワイドなら月額3万円です。
業務アプリの設計、権限・通知設定、帳票を含めた初年度総額は、リサーチノートの試算で50万〜500万円程度です。電子署名、データ移行、教育も含めたうえで、これは利用範囲による推定値です。SaaSは安く見えても、複数サービスを組み合わせると月額と保守窓口が増えるため、5年程度の運用費も比較します。
保守・運用・法改正対応の費用
初期開発費だけでなく、運用に関わる費用も分けて見積もります。クラウド利用料、ライセンス、監視、バックアップ、ヘルプデスク、障害対応が、その対象です。脆弱性対応、法令や組織変更に伴う改修、軽微なフォーム変更、データ保管も含めます。
リサーチノートでは、保守費を初期開発費の年5〜15%程度とする整理があります。ただし、月額か年額か、何が含まれるかで意味が変わるため、参考レンジとして扱います。電子帳簿保存法の対象文書を扱う場合は、検索要件、改ざん防止、保存期間を確認します。
また、関連するシステム関係書類と、ダウンロード要求への対応も確認します。国税庁の電子取引・電子帳簿保存制度の資料をもとに、法務や経理の責任者と要件を確認し、法改正時の対応主体と追加費用を契約に記載します。根拠として、国税庁「電子取引関係」および令和8年6月資料を参照しています。
委託先の選定と見積比較で確認するポイント
委託先は、知名度や提示価格だけでなく、手続の理解力や要件定義の進め方を基準に比べます。データ移行、セキュリティ、運用支援も、同じ基準で比較します。
カスタム開発会社と完成済みSaaSのベンダーは役割が異なるため、提案内容が自社の発注形態に合っているかを見極めます。
同種の手続・業界の実績の確認
実績は「ワークフローを導入した件数」だけでなく、契約審査や行政申請、本人確認に近い手続で確認します。複数法人の権限や文書移行など、自社に近い条件の実績も確認します。可能であれば、導入前の課題、対象手続数、利用者数を匿名の範囲で聞きます。
連携、移行、稼働後の保守体制も、匿名の範囲で聞きます。提案担当者と開発・運用担当者が異なる場合は、契約後の責任者を面談に同席させます。開発会社が要件定義をどのように行うかも、比較の対象になります。
現場ヒアリングの回数や、業務フロー図、プロトタイプの作成が見積もりに含まれるかを確認します。例外の洗い出し、Fit & Gap、受入テスト支援も、対象に入るかを確認します。要件定義を発注側がすべて準備する前提なら、その作業を自社で担える体制があるかを検討します。
見積もりの前提・工数・除外項目の比較条件
見積書は総額より先に、前提条件と内訳を確認します。内訳は、要件定義、画面・API設計、開発、テスト、移行を、数量や工数が読める状態で分けます。さらに、教育、PM、インフラ、ライセンス、保守も、数量や工数が読める状態にします。
手続数や画面数、連携先が何件として計算されているかを確認し、A社だけデータ移行を含み、B社は除外しているといった比較条件の違いをなくします。特に、追加開発単価、仕様変更の扱い、休日・夜間対応は見落としやすいです。再委託費、クラウド費の改定、ストレージ超過も、見落としやすい点です。
さらに、データ返却と契約終了時の移行支援にも注意が要ります。見積もりは、安さで選ぶ前に、同じ要件で不足しているものがないかを確認します。必要なら、見積もりを二段階に分けます。
安全性とベンダーロックインへの対策
委託先には、権限設計、MFA・SSO、暗号化について質問します。ログ監視、バックアップ、脆弱性対応も、質問項目に含めます。再委託先とインシデント対応についても、確かめます。
機密文書を扱う場合は、検証環境へ本番データをコピーしないこと、退職・異動時の権限を速やかに剥奪すること、管理者権限を記録することも要件に含めます。AIで書類の項目抽出や不備チェックを行う場合は、入力データの学習利用、ログの保存、誤判定時の人によるレビュー、最終承認者を明確にします。
ロックインを防ぐには、申請データと文書を標準的な形式で出力できるか、API仕様やデータ辞書が提供されるか、契約終了時に移行支援を受けられるかを確認します。自社がフォームや承認経路を変更できる範囲、委託先へ依頼する場合の単価、保守SLA、法改正時の対応範囲を事前に決めると、運用開始後の主導権を保ちやすくなります。
手続管理システムの発注でよくある質問
発注前に特に相談が多い質問をまとめます。費用や契約の答えは、対象手続、利用者、連携の条件によって変わります。移行やセキュリティの条件も関わるため、以下の回答はRFPの確認項目として使ってください。
手続管理システムの開発費用はいくらですか？
特定業務に絞った小規模な刷新は300万〜1,500万円、複数の契約・法務手続と連携や移行を含む標準規模は1,500万〜4,000万円が推定目安です。
行政向けの本人確認、審査、複数台帳、強い可用性まで含める場合は4,000万円超も想定します。これは固定相場ではないため、手続数、利用者数、分岐数、連携数、文書量を示して複数社から見積もりを取ります。
SaaSとスクラッチ開発はどちらがよいですか？
早期導入や標準化を優先し、製品の承認・通知・検索に業務を合わせられるならSaaS・パッケージが向いています。
独自の審査、複雑な権限、特殊な文書管理、既存基幹との深い連携が重要ならスクラッチ開発が候補です。判断に迷う場合は、1〜3手続のPoCで標準機能の限界と、独自開発が必要な部分を確認します。
RFPは自社だけで作成できますか？
手続一覧、現状フロー、困りごと、利用者を自社で整理します。連携先やセキュリティ条件も整理したうえで、詳細な要件定義やRFPのレビューを外部へ支援依頼する進め方が現実的です。
最初から技術仕様を固定するより、業務要件、評価基準、提案の前提条件を明確にし、候補会社へ同じ条件で提案してもらうことが大切です。
まとめ
手続管理システムの発注・外注は、製品や開発会社を先に決めるより、社内申請・契約や法務手続なのか、行政・対外手続なのかを分けることから始めます。そのうえで、現状の手続、例外、文書を洗い出し、連携と期限も整理します。
SaaS・パッケージ、ローコード、スクラッチにはそれぞれ向き不向きがあるため、Fit & GapとPoCで標準機能と独自開発の境界を確認します。
費用は、小規模な刷新で300万〜1,500万円、標準規模で1,500万〜4,000万円を推定レンジとして検討します。行政向けの大規模連携では、4,000万円超も想定します。
これは要件によって変動する目安です。RFPでは手続数、利用者数、承認分岐、データ移行、API、非機能要件をそろえ、初期費用だけでなくライセンス、保守、法改正、教育、契約終了時の移行まで比較します。
契約は、要件を探索する段階を準委任、仕様と検収条件が確定した開発を請負とする段階発注が選択肢になります。
委託先の実績、要件定義力、セキュリティ、データ返却、保守SLAを同じ質問票で確認し、現場が継続的に手続を改善できる体制まで含めて選定することが、発注後の成功につながります。
▼全体ガイドの記事
・手続管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。