保育園・幼稚園向け保育料管理システム開発の発注/外注/依頼/委託方法について

保育料管理システムの発注は、料金ルールを整理してから、RFPで候補会社に同じ条件で見積もりを頼み、契約後に段階的に導入する流れで進めます。この順に進めると、追加費用や運用負担を抑えやすくなります。

▼全体ガイドの記事
・保育園・幼稚園向け保育料管理システム開発の完全ガイド

保育料管理システムの発注前に決める事項

発注前に決めるのは、請求業務の範囲と判断ルールです。まず、今使っている資料を洗い出します。Excelや紙の請求書、登降園端末、口座振替データが対象で、自治体帳票も加えます。

誰が入力・確認し、いつ請求を確定するかも、見える形にしておきます。前提が曖昧だと、各社の見積もりや納期を比べにくくなります。

「作業時間」と「請求精度」による発注目的の定義

導入目的は、現状の数値と照らして定めます。導入後に比べられるよう、作業時間や修正請求、未収確認といった指標を、あらかじめ決めておきます。

  • 請求作業:月末に担当者3人で2日かかるなど、現状の記録
  • 修正・未収:修正請求の頻度と、未収確認にかかる1週間
  • 現金・問い合わせ:集金袋の照合や保護者からの問い合わせ件数

導入後は、同じ指標を使って現状と比べます。指標がそろっていれば、導入の前後を数字で比較できます。

料金ルールと例外の発注資料への落とし込み

料金表は、請求項目と計算条件を分けて整理しておきます。特に、施設種別ごとの制度や帳票の違いも、要件に含める必要があります。

  • 請求項目:月極、延長、一時・預かり保育、給食、おむつ、教材、行事費の区分
  • 計算条件:年齢、認定、保育時間、曜日、日数、兄弟、減免、無償化上限の整理
  • 例外処理:欠席・退園の日割り、返金・繰越、施設種別ごとの制度の確認

保育園や幼稚園、認定こども園のほか、企業主導型や認可外でも、制度や帳票は異なります。そのため、料金マスタで切り替えられるかを確認します。

無償化の対象は3〜5歳の利用料や、0〜2歳の住民税非課税世帯の利用料です。一方で、送迎費、食材料費、行事費などは保護者負担です。対象外の実費や、自治体の認定・減免も明細にできるかを確認します。

なお、幼稚園の預かり保育には月額1.13万円までの上限があります(出典: こども家庭庁「幼児教育・保育の無償化について」、2026年確認)。

ポイント

判断に迷ったら、請求業務の範囲と料金ルールの例外が資料にそろっているかを先に確かめ、そのうえで発注形態の比較に進みます。

発注形態の選び方(SaaS・パッケージ・スクラッチ)

SaaS型とスクラッチ型を、早期導入・標準化と独自制度・連携の観点で対比した図。
標準化の優先度と独自要件の深さが、選択を分ける軸です。

発注形態は、園の規模に加えて、独自ルールや本部管理の有無で選びます。既存システムとの連携や、制度改正への対応体制も判断の材料になります。

SaaSは、早く始めたい園に有力な選択肢です。標準機能で足りなければ、パッケージの設定追加やハイブリッド構成を検討します。

早期導入と標準化を優先する園に向いたSaaS型

SaaS型は、ベンダーのクラウドサービスを月額で使う方式です。自園でサーバーを用意する必要がなく、運用の負担も抑えられます。

  • 導入・拡張:1園から法人内の複数園へ、利用者や施設を追加しやすいこと
  • 運用:制度改正、バックアップ、脆弱性対応の一部を、ベンダーに任せられること
  • 確認事項:料金マスタ、自治体帳票、端末連携、データ返却の制約の有無

費用面では、まず月額に含まれる範囲を確かめます。初期設定や端末、移行費のほか、決済・口座振替の手数料や保護者アプリの利用料も、費用に入れて考えます。

会計や口座振替との連携にも、制約がある場合があります。そのため、公開価格だけでなく、3年間の総額で比べます。

パッケージ型の設定追加と連携開発の範囲

パッケージ型は、園児台帳や登降園、請求、帳票の標準機能を使い、自園の設定や連携を加える方式です。要件定義を短くしやすく、必要な部分だけを調整できるのが特徴です。

  • 設定:料金マスタや帳票レイアウトの変更範囲
  • 連携:CSV出力やAPI連携が、標準か追加費用かの区分
  • 開発:承認画面やデータ移行の個別開発範囲

預かり保育や認定こども園の複合請求は、標準機能と合うかを確かめる必要があります。

「対応可能」との回答に加えて、画面や帳票、テストケースまで依頼します。

スクラッチ・ハイブリッド型の保守と役割分担

スクラッチ型は、自治体独自の制度や本部会計がある場合の選択肢です。複数法人の統合や基幹連携、複雑な権限や承認が必要なときにも、候補になります。

  • 保守責任:制度改正、OS・ブラウザ更新、脆弱性対応、監視、バックアップの担当
  • 代替手段:独自機能の前に、API・CSV連携やパッケージ設定で代替できるかの検証
  • 役割分担:SaaSと別システムのどちらを正本にするかの決定

ハイブリッド型では、連携の頻度と失敗時の再送を、契約前に定めておきます。加えて、年度更新や退園後のデータ保持も、あらかじめ決めておきます。

こども家庭庁は、保育分野のワンスオンリーや保活ワンストップを見据えて、標準化を検討しています。対象は、業務プロセスやデータフロー、データセット、マスタです(出典:こども家庭庁「保育現場でのDXの推進に向けた調査研究事業」、2026年確認)。

RFPと要件整理の作り方

RFPは、開発会社やベンダーへ提案と見積もりを依頼する文書です。

機能一覧だけでなく、現場の課題から選定基準までを同じ前提にまとめます。同じ条件で提案を受けると、価格差の理由を説明しやすくなります。価格だけで会社を決めないための、判断材料にもなります。

現行業務と完成後の業務フローの記載

RFPには、園児登録から返金までの工程を時系列で記します。各工程には、担当者、入力データ、承認者を添えます。また、帳票や例外処理、締め日も書き込みます。

  • 請求まで:園児登録、契約、登降園、料金計算、請求確定、保護者通知の流れ
  • 入金後:決済、入金消込、未収管理、返金までの流れ
  • 例外:打刻漏れの修正者や、確定後の取消・再請求の方法

テストには、通常月のほかに、兄弟在籍のケースや月途中の入退園を含めます。複数回の延長保育も、テストに入れておきます。さらに、無償化対象外の費用や日割り、返金・繰越、口座振替の失敗も加えます。

実データは使わず、匿名化したデータで期待する請求額と明細を示します。こうした具体例があるほど、理解力と見積もりの精度を比べる材料になります。

機能要件の分類(計算・請求・連携・権限)

機能要件は、園児台帳から決済・連携までの機能群に分けます。保護者アプリやメールでは、明細の閲覧や支払方法の登録、再請求の案内のほか、問い合わせ履歴も確認します。

  • 計算・請求:認定、料金マスタ、延長・一時保育、固定費、実費、減免、上限、日割り、帳票の整理
  • 決済・連携:口座振替、カード、入金消込、未収、返金、繰越、CSV・APIの確認
  • 権限・安全:職員や保護者の権限、認証・暗号化・ログ・バックアップの定め

ロールは、保育士や事務、園長から、本部、自治体、保護者まで分けます。特に、請求の確定や金額の変更は、権限と二者承認を定めておきます。

返金や取消、マスタ更新も、権限と二者承認の対象に含めます。操作履歴の保存期間も決めておきます。

子どもの氏名や住所、家族、利用履歴、決済情報を扱います。そのため、退職者のアカウント停止も、RFPに含めます。

納品物・移行・保守の条件

納品物には、要件定義書や画面・帳票仕様、料金ルールを含めます。テスト仕様、マニュアル、運用設計も、納品物として明記します。

  • 納品・データ:移行計画、障害手順、設定情報の範囲、SaaSのデータ取得形式と期限
  • 移行:園児・保護者・兄弟・在籍履歴、料金マスタ、未収、入金履歴の範囲
  • 保守:制度改正、受付時間、障害連絡、復旧目標、再委託先の明記

スクラッチや個別開発では、ソースコードを受け取るか、設定情報だけにするかも決めます。

移行データの欠損や表記の揺れを誰が直すか、リハーサルの回数も定めます。バックアップと復元テストも、保守条件に含めます。

条件を後から追加すると、当初の見積もりとの差額が大きくなることがあります。

ポイント

RFPに業務フロー、例外、権限、移行、保守の条件が書かれていれば、各社の提案を同じ前提で比べられます。迷ったら、この条件が抜けていないかを見直します。

外注・委託の進行順序

保育料管理システムの外注を現状整理からRFP作成、要件定義・移行、段階稼働へ進める流れ図。
候補選定の前に業務を整理すると、後続の条件をそろえられます。

外注は、現状整理から運用評価まで、順に進めるのが基本です。候補選びは、現状整理のあとに行います。1園の場合でも、本部と現場の代表者を早い段階から参加させます。

  1. 現状を整理し、運用を変える範囲と変えない範囲を合意する
  2. RFPを作り、候補選定と提案・見積もりの比較を行う
  3. 契約後に要件定義、設計・設定、テスト、移行を進める
  4. 段階稼働し、運用を評価する

候補会社に渡す同じRFPと同じテストケース

候補は、保育園・幼稚園・認定こども園での導入経験で絞り込みます。請求計算や登降園・決済連携、本部管理、制度改正への対応も見たうえで、同じ条件を提示して比べます。

  • 候補数:現場の負担を考えた、要件に合う3〜5社程度への依頼
  • 提案条件:各社への同じRFPの提示と、対応範囲・除外項目の統一
  • デモ:例外を含む請求から消込・再請求までの、実際の操作

デモで使う例は、月極料金に延長2時間を加えたケースです。給食費や教材費、兄弟割引、欠席返金も含めます。

特に、明細や承認履歴がどう残るかを見ておきます。打刻漏れや返金、口座振替の失敗、年度更新への対応も確かめます。成功例だけでなく、例外の扱いが選定の分かれ目になります。

要件定義・テスト・移行の段階ごとの承認

契約後は、RFPの内容を要件ごとに分けて整理します。料金マスタや画面、帳票、連携、権限、非機能要件が対象です。そのうえで、要件定義の完了条件と、追加・変更の扱いを文書にします。

  1. 正常系と異常系のテスト仕様を作り、期待値を園と委託先で確認する
  2. 匿名化データで移行リハーサルを行い、旧請求額と新計算を照合する
  3. 差異の原因を記録し、一部で並行稼働してから範囲を広げる

現場の例外が設計後に見つかると、追加費用や納期の延長につながります。稼働判定の責任者と、問題が起きたときの手戻りの方法も、計画書や契約書に記しておきます。

まず、1園または一部の請求項目で月次締めを経験する方法も有効です。

ポイント

迷ったときは、運用を変える範囲と変えない範囲を先に合意します。その合意が、後の要件定義と段階稼働の判断を支えます。

契約形態は請負・準委任・SaaS利用契約の使い分け

契約形態は、成果物と責任の置き方で選びます。工程ごとに使い分けることもあり、要件が固まった開発部分は請負、要件整理や調査、継続的な改善は準委任、既製のクラウドは利用契約が当てはまります。

契約名を見るだけでなく、中身の条件を確認することが大切です。納品や検収、変更の条件は、契約の最初に押さえたい項目です。障害対応や知的財産の条件は、契約書に明記してもらいます。データ返却と再委託も、対象に含めます。

請負契約の成果物・検収・変更管理

請負では、何を完成させれば検収となるかを具体的に決めます。画面の表示だけでなく、業務上の受入条件を成果物と結び付けます。

  • 成果物:料金マスタ、延長料金計算、請求確定、領収書、入金消込の定義
  • 受入条件:権限、操作ログ、CSV出力、バックアップ復元のテスト
  • 変更管理:不具合修正期間と、追加費用になる仕様変更の区別

園側の確認やデータ提供が遅れると、納期にも影響します。このため、料金ルール、帳票、移行データの確認担当を決めておきます。

固定価格の場合は、対象外の作業と前提条件、追加見積もりの単価を明らかにしておきます。あわせて、課題管理表で委託先と進捗を共有します。

準委任契約の作業範囲・稼働時間・成果確認

準委任は、作業の実施そのものを重視する場面で使います。要件定義や業務整理、移行支援、運用改善、追加開発の調査などが、その例です。

  • 稼働:月ごとの時間と担当者の決定
  • 成果確認:作業項目、成果物、レビュー日の定め
  • 予算:上限と追加承認の条件の決定

初期段階は柔軟に進められますが、作業時間だけが積み上がると予算管理が難しくなります。そこで、会議を開いた回数ではなく、承認済みの成果物で確認します。

ヒアリングや料金ルールの整理、サンプル計算、RFP作成、候補比較を準委任にして、後続の開発を請負にする方法もあります。

料金ルール一覧やテストケースが承認済みか、移行項目と責任者が確定したかを記録しておくと、次の工程へ進みやすくなります。

SaaS利用契約のデータ・変更・解約条件

SaaSでは、開発の請負とは異なる条件を確認します。停止や障害、制度改正や更新の通知、料金改定のほか、利用人数や施設数、決済手数料、サポート範囲も対象です。

  • 障害対応:停止連絡、復旧、サポート範囲の確認
  • 個人データ:再委託先、保管場所、事故報告、アクセス権限の確認
  • 解約:退会後のデータ削除と返却の条件

個人情報保護委員会の通則ガイドラインでは、委託先の安全管理措置を事前に確認することが示されています。

ほかにも、アクセス制御や、アクセス者の識別・認証、外部からの不正アクセス防止、ログの定期分析が挙げられています(出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

「SSL対応」という回答に加えて、園・本部・委託先の権限分離と、事故対応の実効性も質問します。

ポイント

成果物を検収で確かめられる工程は請負、作業の実施を重視する工程は準委任と考えると、判断しやすくなります。既製のクラウドは、データ返却と解約の条件を利用契約で確かめることが大切です。

発注費用・外注費用の目安

設定・連携、1園向け、複数園・大規模の個別開発費用レンジを比較する横棒図。
対象範囲が広がるほど、見積もりの初期レンジも上がります。

費用は、既存サービスを使うか新規に開発するか、連携や移行の範囲によって変わります。単一園の請求SaaSでは、公開価格で初期費用0円から数十万円、月額5,000円から3万円程度が比較の目安です。

定員、端末、設定、移行、サポートなどは、別料金の場合があります。決済や口座振替も、別に費用がかかることがあります。そのため、公開価格を導入総額として扱わないよう注意します。

導入から3年の総額で見る公開価格

リサーチノートで確認した公式の公開価格の例では、CoDMONは定員30名まで月額3,300円です。31〜60名は5,500円、61〜100名は8,800円(税込)で、初期費用0円からと案内されています。

  • WEL-KIDS:初期費用0円、月額5,500円(税込)から
  • ルクミー請求管理:月額5,000円(税抜)から
  • CoDMON:定員区分ごとに月額3,300円、5,500円、8,800円(税込)

これらは公開プランの例で、一律の相場ではありません(出典: 各サービス公式料金ページ、2026年確認)。

月額の中に含まれる請求や登降園、通知と、別に払う費用を分けて考えます。月額の外では、口座振替の1件あたり手数料や端末、カードの費用がかかります。設定や移行、研修の費用も、月額の外で確かめます。問い合わせや制度改正対応の費用も、あわせて確認します。

1年目だけでなく、2年目と3年目の月額やオプション、値上げ条件、解約時のデータ取得費まで合算します。

個別開発費の幅(50万円台から5,000万円超)

保育料管理だけを対象にした公開統計は、ほとんどありません。ここに示す数字は、一般的な業務システムの工程比率と公開事例をもとにした推定です。

  • 設定・連携:既存パッケージ、帳票追加、CSV連携は初期50万〜300万円程度
  • 1園向け:保育料・延長料金・請求・入金管理の新規構築は300万〜800万円程度
  • 複数園・大規模:要件により800万〜2,000万円程度、または2,000万〜5,000万円超

登降園や通知、決済、移行を加えるほど、上限に近づきます。会計や給付費の連携、自治体連携、権限・監査ログの対応も、要件に含まれる場合があります。

複数制度、外部API、冗長化に加えて、24時間運用や大規模移行まで含むと、2,000万〜5,000万円超となる可能性があります。ただし、これは案件ごとの実績相場ではなく、要件整理の初期レンジです。

期間の目安は、設定・連携で1〜3か月、1園の新規構築で3〜6か月です。複数園や自治体連携は6〜12か月、大規模案件は12〜18か月程度です。

見積書の工程別内訳(要件定義・開発・移行・保守)

開発費は、要件定義から保守まで、工程ごとに分けて見ます。画面・帳票設計や料金計算、登降園や決済の連携も、そのなかに含まれます。

  • 要件定義:10〜15%程度
  • 設計・開発:設計15〜20%、開発30〜40%程度
  • テスト・移行:テスト15〜20%、移行5〜10%程度

この工程比率は、保育料管理案件の統計ではありません。委託先が工程を省いていないか、または含めているかを見るための目安です。

初期費用の15〜20%程度を年間の保守費とする考え方もあります。ただし、クラウドや決済、端末、制度改正、追加開発、サポートをどこまで含むかで変わります。

東京都の2025年資料では、保活ワンストップの連携改修の契約額として、コドモン2,420万円、ルクミー2,997万5,000円が示されています。これは、自治体と複数サービスの連携改修の契約額で、単一園のSaaS価格や一般的な開発費とは異なります(出典: GovTech東京「統合年次報告2025」、2025年)。

補助金は、交付決定前の契約の可否や対象機能、補助率、1施設あたりの上限を、自治体へ確認します。端末や申請主体、実績報告についても、確かめておきます。

令和7年度の保育所等ICT化推進等事業では、1機能20万円、2機能40万円、3機能60万円、4機能80万円の補助基準額が示されていました。端末購入を含む基準額もありました。

年度や自治体によって条件が変わるため、2026年度の公募要領を必ず確認します(出典: こども家庭庁「令和7年度保育関係補正予算の概要」、2025年)。

委託先の選定と見積比較の確認事項

委託先は、価格だけでなく、保育料計算への理解や質問力で評価します。運用支援や移行、セキュリティ、保守の継続性も、判断の材料にします。

重要な要件が「別途」になっている場合、契約後に費用が増えます。そのため、比較表には対応の可否だけでなく、標準・設定・個別開発・対象外の区分を記します。

保育施設での実績と導入後の支援体制

「保育業界の実績」があるかだけでなく、施設種別や導入園数、担当範囲も質問します。自園に近い事例があるかを、見ておきます。

  • 実務経験:月末締め、年度更新、制度改正、返金、未収対応の経験の有無
  • 導入支援:研修の担当と回数、マニュアル、問い合わせ窓口、稼働初月の支援
  • 障害対応:連絡経路と、複数園展開時の本部支援体制

認可保育所や幼稚園のほか、認定こども園、企業主導型、認可外では、料金や帳票の前提が異なります。そこで、近い施設の事例を確認します。

可能であれば、こうした経験を持つ担当者から、直接説明を受けます。

保育士の入力を増やさずに、園長や事務担当が請求を承認できる流れまで設計できる会社は、導入後の定着につながります。

見積比較の総額・前提・除外項目

見積もりは、同じ期間と対象範囲をそろえて比べます。初期費用からデータ返却まで項目ごとに分け、1年目と3年目の総額を算出します。

  • 費用項目:初期、月・年額、決済、端末、移行、研修、保守の内訳
  • 追加条件:追加開発、制度改正、解約時のデータ返却の扱い
  • 比較期間:オプションや値上げ条件を含めた1年目と3年目の計算

たとえば、月額が安くても、請求や通知、口座振替、帳票、サポートが追加になれば、TCO(総所有コスト)は変わります。

園児数や施設数、追加単価などの前提を、各社でそろえて確認します。移行年数や連携システム数、テスト・研修回数、障害対応時間帯も含めます。

質問への回答が具体的で、リスクや対象外を先に示す会社は、発注後の認識のずれを抑えやすい傾向があります。

セキュリティとベンダーロックインの確認

暗号化のほか、権限分離や個人認証、多要素認証、操作ログを確認します。監視やバックアップ世代、復元テスト、脆弱性対応も、あわせて確かめます。

  • 委託先管理:再委託先、保管期間、削除手順の契約への記載
  • 事故対応:端末紛失対策、報告時間、連絡先の明記
  • データ移行:園児・保護者、料金、請求・入金、操作履歴の返却形式

CSVなどで取り出せるかを確かめます。APIの利用料や回数制限、仕様変更の通知、停止時の業務継続も見ておきます。

データが独自形式でしか残らないと、サービス変更や法人統合の際に追加費用が生じる場合があります。そのため、項目と返却形式をRFPと契約書に記します。

ポイント

委託先は、質問への具体的な回答と、リスクや対象外を先に示す姿勢で比べます。迷ったときは、同じ期間の総額で見て判断します。

保育料管理システムの発注・外注でよくある質問(FAQ)

費用だけでなく、料金ルール、移行、契約、運用体制を合わせて判断することが大切です。発注前によくある疑問をまとめます。

保育料管理システムは既製品と個別開発のどちらがよいですか?

早期導入や標準化を重視するならSaaSやパッケージ、独自制度や深い連携が必要なら個別開発が候補になります。まずは、料金マスタやCSV・APIで代替できるかを確かめます。

標準、設定、個別開発の差額を比べたうえで決めます。最初からスクラッチに限る必要はありません。

RFPにはどのくらい詳しい要件を書けばよいですか?

画面の細部よりも、業務フローや料金ルール、例外の扱いを中心に、前提を書きます。連携や帳票、権限、移行、保守の前提も含めます。

月途中の入退園や兄弟割引、無償化対象外の実費などのテストケースがあると、同じ条件で比べやすくなります。延長保育や返金、打刻漏れのケースも含めておきます。

保育料管理システムの費用は月額だけ比較すればよいですか?

月額だけでは不十分です。初期設定や移行、端末、決済・口座振替のほか、研修やサポート、制度改正、追加開発まで含めて比べます。

解約時のデータ返却まで加えて、1年目と3年目の総額を比べます。そのうえで、園児数や施設数、機能を同じ前提にそろえ、個別の見積もりで判断します。

委託先には保育園の実績をどこまで確認すればよいですか?

自園に近い施設種別で、料金計算や請求、決済、移行などの担当範囲がどこまでかを確かめます。

導入社数に加えて、月末締めや例外処理への対応を質問します。稼働初月の支援や障害連絡、解約時のデータ返却も、あわせて聞きます。

まとめ

発注では、料金ルールや例外、施設種別、既存連携を洗い出すところから始めます。そのうえで、SaaS、パッケージ、スクラッチ、ハイブリッドを比べ、RFPには業務フローや保守まで書き込みます。

発注前の比較表とテストケースの完成

見積もりは、初期費用だけでなく、1年目と3年目のTCOまで含めて、同じ条件で比べます。対象には、追加機能や決済、端末が含まれます。移行や研修、保守も、比べる項目です。制度改正やデータ返却も、対象です。

候補会社には同じ例外テストを渡し、説明の具体性やリスク開示、導入支援を確認します。契約形態に応じて、成果物と検収、作業範囲、障害、個人情報、解約条件を、契約書に反映します。

自園の条件に合う委託先への相談

外注は、機能を買うことにとどまらず、請求ルールを整えて、現場と保護者が確認しやすい業務に変える取り組みです。

料金表や請求書、登降園データ、例外処理を整理してから相談すれば、発注形態と費用レンジが明確になります。さらに、追加費用や運用負担も抑えやすくなります。

▼全体ガイドの記事
・保育園・幼稚園向け保育料管理システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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