保育園・幼稚園向け保育料管理システムの発注・外注は、料金ルールと例外を先に整理し、SaaS・パッケージ・スクラッチを比較できるRFPで複数社から見積もりを取る進め方が基本です。
保育料のシステム化では、単に請求書を発行できれば十分というわけではありません。登降園の実績、認定区分、延長保育、預かり保育、給食費や教材費、兄弟条件、無償化、減免、返金、入金消込までを一つの業務として設計する必要があります。本記事では、発注形態の選び方、RFPと要件整理、契約形態、2026年時点で確認できる費用レンジ、委託先の選定方法、見積書の比較ポイントを、保育園・幼稚園の実務に沿って解説します。
▼全体ガイドの記事
・保育園・幼稚園向け保育料管理システム開発の完全ガイド
保育料管理システムを発注する前に何を決めますか?

発注前に決めるべきことは、製品名や画面デザインではなく、請求業務の範囲と判断ルールです。現在のExcel、紙の請求書、登降園端末、口座振替データ、自治体の帳票を集め、どの情報を誰が入力し、誰が確認し、いつ請求を確定するのかを見える化します。ここが曖昧なまま外注すると、開発会社ごとに前提が違う見積もりとなり、価格も納期も比べにくくなります。
発注の目的を「作業時間」と「請求精度」で定義します
最初に、なぜシステムを導入するのかを数値で表します。たとえば「月末の請求作業を担当者3人で2日かけている」「延長保育の修正請求が毎月発生する」「未収の確認に1週間かかる」「現金の集金袋を手作業で照合している」といった現状を記録します。導入後に請求作業時間、修正請求件数、未収確認時間、現金取扱量、保護者からの問い合わせ件数を比較できると、発注の成果を判断しやすくなります。
料金ルールと例外を発注資料に落とし込みます
料金は、月極保育料、延長保育料、一時預かり、預かり保育、給食費、おむつ代、教材費、行事費などに分けて整理します。さらに、年齢や認定区分、保育標準時間・短時間、曜日、利用日数、兄弟姉妹、減免、無償化の上限、欠席や退園の日割り、返金・繰越を条件として並べます。保育園、幼稚園、認定こども園、企業主導型、認可外では適用する制度や帳票が異なるため、施設種別を一つの前提に決めつけず、料金マスタで切り替えられるかを要件に含めます。
こども家庭庁の無償化案内では、3〜5歳の利用料や、0〜2歳の住民税非課税世帯の利用料が対象となる一方、通園送迎費、食材料費、行事費などは保護者負担とされています。また、幼稚園の預かり保育には月額1.13万円までの上限が示されています(出典: こども家庭庁「幼児教育・保育の無償化について」、2026年確認)。発注時は「無料になるか」ではなく、対象外の実費や自治体ごとの認定・減免まで誤りなく明細化できるかを確認します。
発注形態はSaaS・パッケージ・スクラッチのどれを選びますか?

発注形態は、園の規模だけでなく、料金ルールの独自性、複数園の本部管理、既存システムとの連携、制度改正への対応体制で判断します。早く始めたい園にとってはSaaSが有力ですが、標準機能で足りない部分が多い場合はパッケージへの設定追加やハイブリッド構成が現実的です。スクラッチ開発は自由度が高い反面、保守と制度改正の責任まで引き受ける選択です。
SaaS型は早期導入と標準化を優先する園に向いています
SaaS型は、ベンダーが提供するクラウドサービスを月額で利用する方式です。サーバーを自園で用意する必要がなく、制度改正やバックアップ、脆弱性対応の一部をベンダーに任せやすい点がメリットです。1園で始めてから法人内の複数園へ広げる場合も、利用者や施設を追加しやすくなります。
一方で、料金マスタの自由度、自治体指定帳票、既存の登降園端末、会計や口座振替との連携、解約時のデータ返却形式には制約がある場合があります。契約前に、月額に含まれる機能、初期設定費、端末費、決済手数料、口座振替手数料、データ移行費、保護者アプリの利用料を確認します。公開価格が低く見えても、3年間の総額で比較することが必要です。
パッケージ型は設定追加と連携開発の範囲を分けます
パッケージ型は、園児台帳、登降園、請求、帳票などの標準機能を使いながら、自園の料金マスタや帳票、CSV連携を設定・追加する方式です。保育業務の知見を持つサービスを利用できるため、業務を一から作るより要件定義を短くしやすく、現場に合う部分だけを調整できます。幼稚園の預かり保育や認定こども園の複合的な請求など、標準機能との適合性を確認しながら進めたい場合に向いています。
見積書では「設定」と「個別開発」を区別してもらいます。料金マスタの登録、帳票のレイアウト変更、CSV出力、API連携、承認画面、データ移行がそれぞれ標準対応なのか、追加費用なのかを確認します。ベンダーの説明が「対応可能」だけで終わる場合は、実際の画面、サンプル帳票、テストケースで判断できる資料を依頼します。
スクラッチ・ハイブリッド型は責任分界を明確にします
スクラッチ型は、自治体独自の制度、法人本部の会計、複数法人の統合、既存基幹との深い連携、複雑な権限・承認など、標準サービスでは業務を変えにくい場合の選択肢です。ただし、開発後の制度改正、OSやブラウザの更新、脆弱性対応、監視、バックアップ、保守要員まで継続的に必要です。独自機能が欲しいという理由だけでなく、APIやCSV連携、パッケージの設定で代替できないかを先に検証します。
ハイブリッド型では、園児台帳と登降園はSaaS、法人会計や分析は別システムというように役割を分けます。この場合は、どのシステムを正本にするか、連携頻度、失敗時の再送、年度更新、退園後のデータ保持を契約前に決めます。こども家庭庁も、保育分野のワンスオンリーや保活ワンストップを見据え、業務プロセス、データフロー、データセット、マスタの標準化を検討しています(出典: こども家庭庁「保育現場でのDXの推進に向けた調査研究事業」、2026年確認)。将来の連携を考えたデータ設計が、発注形態の選択にも影響します。
RFPと要件整理はどのように作成しますか?

RFPは、開発会社やベンダーに提案と見積もりを依頼する文書です。機能一覧を並べるだけではなく、現場の課題、対象施設、利用者、データ、業務フロー、連携、非機能要件、納品物、選定基準、スケジュールを一つの前提にまとめます。RFPの目的は、安い会社を探すことではなく、同じ条件で提案を受け、価格差がどこから生まれたかを説明できる状態にすることです。
現行業務と完成後の業務フローを一緒に記載します
RFPには、園児登録から契約、登降園、料金計算、請求確定、保護者通知、決済、入金消込、未収管理、返金までを時系列で書きます。各工程について、担当者、入力データ、承認者、出力帳票、例外処理、締め日を記載します。たとえば打刻漏れがあった場合に、保育士が直接修正するのか、園長が承認するのか、請求確定後は取消と再請求にするのかを明記します。
テストケースは、通常月だけでなく、兄弟が同時在籍する世帯、月途中の入園・退園、延長保育を複数回利用した園児、無償化対象と対象外の費用が混在する園児、欠席による日割り、返金・繰越、口座振替失敗を含めます。個人情報を含む実データではなく匿名化したデータで、期待する請求額と明細を提示します。具体例を渡すほど、開発会社の理解力と見積もりの精度を比較しやすくなります。
機能要件は計算・請求・連携・権限に分けます
機能要件は、園児台帳と家族情報、認定区分、料金マスタ、登降園、延長・一時保育、固定費と実費、減免・上限・日割り、請求書・明細書・領収書、口座振替やカード決済、入金消込、未収・督促、返金・繰越、CSVやAPI連携に分けます。保護者アプリやメール通知を使う場合は、明細の閲覧、支払方法の登録、再請求の案内、問い合わせ履歴まで確認します。
権限要件では、保育士、事務担当、園長、法人本部、自治体、保護者のロールを分けます。請求額の確定、例外金額の変更、返金、取消、マスタ更新を誰ができるか、二者承認が必要か、操作履歴をどの期間保存するかを決めます。こどもの氏名、住所、家族情報、利用履歴、決済情報を扱うため、機能要件と同じ粒度で認証、アクセス制御、暗号化、ログ、バックアップ、退職者アカウントの停止もRFPに含めます。
納品物・移行・保守の条件を先に書きます
RFPには、要件定義書、画面・帳票仕様、料金計算のルール一覧、テスト仕様書、操作マニュアル、運用設計書、データ移行計画、障害対応手順、設定情報の納品を含めます。SaaSでも、園が入力したマスタや請求履歴をどの形式で取り出せるか、契約終了後にいつまで取得できるかを確認します。ソースコードを受け取る契約なのか、設定情報だけを受け取るのかも、スクラッチや個別開発では明確にします。
移行では、園児・保護者・兄弟・在籍履歴、料金マスタ、未収、入金履歴をどこまで移すかを決めます。移行元のデータに表記揺れや欠損がある場合、誰が修正し、何回のリハーサルを行うかも必要です。保守では、制度改正の対応範囲、問い合わせ受付時間、障害時の連絡経路、復旧目標、バックアップと復元テスト、再委託先を確認します。これらを後から追加すると、初期見積もりとの差額が大きくなりやすいです。
保育料管理システムの外注・委託はどの順番で進めますか?

外注の進め方は、業者探しから始めるのではなく、現状整理、RFP作成、候補選定、提案・見積比較、契約、要件定義、設計・設定、テスト、移行、段階稼働、運用評価の順にすると安定します。1園での導入でも、法人本部や現場の代表者を早期に参加させ、運用を変える範囲と変えない範囲を合意しておくことが大切です。
候補会社には同じRFPと同じテストケースを渡します
候補は、保育園・幼稚園・認定こども園での導入経験、保育料計算と請求の実績、登降園や決済の連携実績、複数園の本部管理、制度改正への対応体制で絞り込みます。候補数は多すぎると現場の負担が増えるため、要件に合う3〜5社程度へ同じRFPを送り、提案の前提、対応範囲、除外項目をそろえて比較します。
デモでは、園児を登録する画面より、請求額が確定するまでを見せてもらいます。月極料金に延長2時間、給食費、教材費、兄弟割引、欠席による返金を加えたケースを実際に操作し、明細、承認履歴、入金消込、再請求まで確認します。ベンダーが用意した成功例だけでなく、打刻漏れ、返金、口座振替失敗、年度更新のような例外をどう扱うかが選定の分かれ目です。
要件定義・テスト・移行を分けて承認します
契約後の要件定義では、RFPの内容を料金マスタ、画面、帳票、連携、権限、非機能要件に分解し、追加・変更の扱いを決めます。設計・開発が進んでから現場の例外を出すと、追加費用や納期延長につながるため、要件定義の完了条件を文書化します。料金計算は、正常系と異常系を合わせたテスト仕様を作り、期待値を園側と委託先で確認します。
本番移行の前には、匿名化データを使ったリハーサルを行います。過去の請求額と新システムの計算結果を照合し、差異があればルール、データ、計算式のどこに原因があるかを記録します。最初から全園を切り替えるのではなく、1園または一部の請求項目で並行稼働し、月次締めを経験してから対象範囲を広げる方法も有効です。稼働判定の責任者と、問題が出たときの手戻り方法を契約書や計画書に書いておきます。
契約形態は請負・準委任・SaaS利用契約をどう使い分けますか?

契約形態は、成果物と責任の置き方を決める重要な項目です。要件が固まった開発部分は請負、要件整理や調査、継続的な改善は準委任、既製のクラウドサービスは利用契約というように、工程ごとに使い分けることがあります。契約名だけで判断せず、納品、検収、変更、障害、知的財産、データ返却、再委託の条件を確認します。
請負契約は成果物・検収・変更管理を明文化します
請負契約を使う場合は、何を完成させれば検収となるかを具体的に書きます。画面が表示されるだけでなく、料金マスタの版管理、延長保育料の計算、請求確定、領収書発行、入金消込、権限、操作ログ、CSV出力、バックアップ復元など、受入テストの条件を成果物に結び付けます。検収後に見つかった不具合の無償修正期間と、仕様変更として追加費用になる条件も必要です。
請負であっても、園側の確認やデータ提供が遅れれば納期に影響します。料金ルールの決定者、帳票の承認者、移行データの確認者を園側の体制として定め、委託先と共同の課題管理表で進捗を管理します。固定価格を選ぶ場合ほど、対象外の作業、前提条件、追加見積もりの単価が明確であることが重要です。
準委任契約は作業範囲・稼働時間・成果の確認方法を決めます
準委任契約は、要件定義、業務整理、データ移行支援、運用改善、追加開発の調査など、作業を進めることに重きを置く場面で使われます。要件が変わりやすい初期段階では柔軟ですが、作業時間だけが積み上がると予算を管理しにくくなります。月ごとの稼働時間、担当者、作業項目、成果物、レビュー日、予算上限、追加承認の条件を定めます。
保育料業務では、現場ヒアリング、料金ルールの整理、サンプル計算、RFP作成、候補比較を準委任で依頼し、その後の開発を請負にする方法もあります。園側が欲しい成果を「会議を実施した」だけにせず、「料金ルール一覧とテストケースが承認済み」「移行項目と責任者が確定済み」のように記録すると、次工程へ進む判断がしやすくなります。
SaaS利用契約はデータ・変更・解約条件を確認します
SaaSを利用する場合は、システム開発の請負契約とは異なる確認が必要です。サービス停止時の連絡、障害時の復旧、制度改正や機能更新の通知、料金改定、利用人数や施設数の数え方、決済手数料、サポートの範囲を契約前に確認します。個人データを委託先が扱うため、再委託先、保管場所、事故発生時の報告、アクセス権限、退会後の削除と返却も確認します。
個人情報保護委員会の通則ガイドラインでは、委託先の安全管理措置を事前に確認すること、アクセス制御、アクセス者の識別・認証、外部からの不正アクセス防止、ログの定期分析などが示されています(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。「SSL対応」と書かれているだけで安心せず、園・本部・委託先の権限分離と事故対応の実効性を質問します。
保育料管理システムの発注費用・外注費用はいくらですか?

費用は、既存サービスを使うか、新規開発するか、連携や移行をどこまで含めるかで大きく変わります。単一園が請求管理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円(税抜)からとされています。これらは各サービスの公開プランの例であり、施設の契約条件や追加機能を含む一律の相場ではありません(出典: 各サービス公式料金ページ、2026年確認)。
見積比較では、月額に含まれる請求・登降園・保護者通知の範囲、口座振替の1件あたり手数料、端末やカードの費用、初期設定、過去データの移行、研修、問い合わせ、制度改正対応を分けます。1年目だけでなく、2年目・3年目の月額、オプション、値上げ条件、解約時のデータ取得費まで足すと、安いプランが必ずしも安いとは限らないことが分かります。
個別開発は50万円台から5,000万円超まで要件で変わります
個別開発の費用は、保育料管理だけの公開統計がほとんどないため、以下はリサーチノートにある一般的な業務システムの工程比率と公開事例をもとにした推定レンジです。既存パッケージへの設定、帳票追加、CSV連携なら初期50万〜300万円程度、1園向けに保育料・延長料金・請求・入金管理を新規構築するなら300万〜800万円程度が比較の起点になります。登降園、保護者通知、決済、移行まで含めるほど上限に近づきます。
法人の複数園、本部管理、会計・給付費・自治体連携、権限・監査ログを含める場合は800万〜2,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年目の総額を計算します。月額が安いサービスでも、請求機能、保護者通知、口座振替、帳票、サポートが追加オプションなら、実際のTCOは変わります。
次に、金額の前提を確認します。園児数や施設数は何人・何園で計算されているか、利用者追加時の単価は何か、データ移行は何年分か、連携は何システムか、テストと研修は何回か、障害対応はどの時間帯かを質問します。RFPに対する質問への回答が具体的で、リスクと対象外を先に説明する会社は、発注後の認識ずれも抑えやすい傾向があります。
セキュリティとベンダーロックインを契約前に確認します
セキュリティは、通信の暗号化だけでなく、職員・本部・自治体・保護者の権限分離、個人認証、多要素認証の有無、操作ログ、ログの監視、バックアップ世代、復元テスト、脆弱性対応、端末紛失時の対策を確認します。子どもの情報を扱うため、委託先や再委託先の範囲、保管期間、削除手順、事故時の報告時間と連絡先も契約に含めます。
ベンダーロックインを抑えるには、園児・保護者・料金マスタ・請求履歴・入金履歴・操作履歴を、解約時にCSVなどで取り出せるかを確認します。APIがある場合も、利用料、レート制限、仕様変更の通知、連携停止時の業務継続を質問します。独自形式に閉じたデータだけが残ると、将来のサービス変更や法人統合で追加費用が発生しやすいため、データ項目と返却形式をRFPと契約書の両方に書きます。
保育料管理システムの発注・外注でよくある質問(FAQ)

ここでは、発注前に園長や法人本部から寄せられやすい質問に答えます。費用だけで決めず、料金ルール、データ移行、契約、運用体制を一体で判断することが重要です。
保育料管理システムは既製品と個別開発のどちらがよいですか?
早期導入や標準化を優先するならSaaS・パッケージ、独自制度や深い連携を優先するなら個別開発が候補です。ただし、最初からスクラッチに決めず、料金マスタやCSV・API連携で代替できるかを確認し、標準・設定・個別開発の差額を比較して判断します。
RFPにはどのくらい詳しい要件を書けばよいですか?
画面の細部まで決める必要はありませんが、業務フロー、料金ルール、例外、利用者、連携、帳票、権限、移行、保守の前提は書く必要があります。特に、月途中の入園・退園、兄弟割引、無償化対象外の実費、延長保育、返金、打刻漏れなどのテストケースを添えると、提案と見積もりを同じ条件で比較しやすくなります。
保育料管理システムの費用は月額だけ比較すればよいですか?
月額だけでは不十分です。初期設定、データ移行、端末、決済、口座振替、研修、サポート、制度改正、追加開発、解約時のデータ返却まで含め、1年目と3年目の総額で比べます。公開価格はプランの一例であるため、同じ園児数・施設数・利用機能を前提にした個別見積もりで最終判断します。
委託先には保育園の実績をどこまで確認すればよいですか?
自園と近い施設種別で、料金計算、登降園、請求、決済、移行、制度改正のどこまで担当したかを確認します。導入社数だけでなく、月末締めの運用、例外処理、稼働初月の支援、障害時の連絡体制、契約終了時のデータ返却まで質問すると、導入後の支援力を見極めやすくなります。
まとめ

保育園・幼稚園向け保育料管理システムの発注では、最初に料金ルール、例外、施設種別、既存システムとの連携を棚卸しします。そのうえで、SaaS、パッケージ、スクラッチ、ハイブリッドを比較し、業務フロー、テストケース、権限、移行、保守まで含めたRFPを作成します。
発注前に比較表とテストケースを完成させます
見積もりは初期費用だけでなく、1年目・3年目のTCO、追加機能、決済、端末、移行、研修、保守、制度改正対応、データ返却まで同じ条件で比較します。候補会社には例外を含む同じテストケースを渡し、説明の具体性、リスクの開示、現場への導入支援を確認します。請負、準委任、SaaS利用契約の違いに応じて、成果物、検収、作業範囲、障害、個人情報、解約条件も契約書へ反映します。
自園の条件に合う委託先へ相談します
保育料管理の外注は、機能を買うだけでなく、園の請求ルールを標準化し、現場と保護者にとって確認しやすい業務へ変える取り組みです。自園の料金表、請求書、登降園データ、例外処理を整理してから相談すれば、必要な発注形態と費用レンジが明確になり、導入後の追加費用や運用負担も抑えやすくなります。
▼全体ガイドの記事
・保育園・幼稚園向け保育料管理システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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