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

保育園・幼稚園向け園児管理システムの発注は、園児台帳だけを電子化するのではなく、登降園、連絡帳、健康・安全記録、請求、帳票までの業務とデータをつなぐ委託先を選ぶことが成功の近道です。

園長や法人本部が外注を検討するときは、SaaSを導入するのか、パッケージを設定するのか、独自システムを開発するのかで、費用、契約責任、導入期間が大きく変わります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較、導入後の運用までを、保育現場で起こりやすい例を交えて解説します。

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

保育園・幼稚園向け園児管理システムを発注する前に知る全体像

園児管理システムは、園児・保護者・職員が同じ情報を立場に応じた画面で扱う業務システムです。発注時は機能数の多さだけで比較せず、園児台帳の情報が連絡帳、出欠、健康記録、帳票、請求などに再利用される設計かを確認することが重要です。

園児台帳には、氏名や生年月日だけでなく、家族・緊急連絡先、認定区分、保育時間、アレルギー、服薬、既往歴、配慮事項、写真、同意履歴などを登録します。ここで一度入力した情報が、連絡帳や健康記録、事故報告、自治体提出帳票に反映されると、転記の手間と入力ミスを減らせます。

特に発注前に確認したいのは、園児本人、きょうだい、保護者、クラス、年度、職員を別々のデータとして管理できるかです。お迎えに来る人の変更やアレルギー情報の更新があったとき、誰がいつ変更したかを記録し、必要な職員だけが最新情報を確認できることが安全面で欠かせません。

「登降園管理あり」「保護者アプリあり」と書かれていても、園児台帳と別システムで二重入力になる場合があります。RFPでは、登園時刻から延長保育時間を集計し、請求へ反映できるか、欠席連絡をクラス担任と管理者が同じ履歴で確認できるかなど、機能同士の連携を業務シナリオで質問します。

また、連絡帳、日誌、個人記録、指導計画、要録、写真、午睡チェック、事故・ヒヤリハットなどは、現場が毎日使う可能性が高い領域です。一方で、すべてを初期導入すると研修と移行が重くなるため、最初は園児台帳、登降園、保護者連絡から始め、請求や帳票を段階的に追加する方法も現実的です。

保育園では登降園、延長保育、欠席、保育時間の集計が重視され、幼稚園では預かり保育、行事、写真、保護者連絡、園児募集との接点が重視されやすいです。認定こども園では認定区分や教育・保育の記録、請求、自治体帳票が複雑になりやすく、公立園ではネットワーク、監査、指定帳票、複数園の一括管理が選定条件になります。

そのため、同じ「園児管理システム」でも、1園の私立幼稚園と、複数園を運営する法人や自治体では発注の仕方が異なります。問い合わせ時には施設種別、定員、在籍園児数、園数、職員数、既存の会計・決済・勤怠、自治体とのデータ連携の有無を最初に伝えると、比較可能な提案を受けやすくなります。

発注形態はどれを選ぶ？SaaS・パッケージ・独自開発の違い

発注形態は、標準業務を短期間で整えたいならSaaS、標準機能を使いつつ園独自の帳票や運用を調整したいならパッケージ・ローコード、複数法人や自治体連携など固有要件が大きいならカスタム開発が基本です。費用の安さだけではなく、園の業務を製品に合わせるのか、製品を業務に合わせるのかで判断します。

SaaSは、ベンダーが提供するクラウドサービスを月額または年額で利用する形態です。サーバー構築や大規模な開発が不要で、標準機能を短期間に始めやすく、法改正や機能更新をサービス側に任せやすい点が強みです。初めてICT化する園や、園児台帳、連絡帳、欠席連絡、登降園を早く整えたい園に向いています。

ただし、独自帳票、複雑な料金計算、特殊な承認フローが標準機能に合わないことがあります。発注前に、データのCSV出力、解約時のデータ返却、利用停止時の保存期間、追加オプション、保護者アプリのアカウント管理、障害時の連絡手段を確認します。

パッケージは、保育施設向けに設計された機能を導入し、設定や一部カスタマイズで自園に合わせる形態です。園児台帳、出欠、保護者連絡、帳票などの標準業務を使いながら、園独自の入力項目や帳票を追加できる場合があります。SaaSより自由度が高い一方、バージョンアップ時の互換性や保守費用を確認する必要があります。

ローコードは、既存の開発基盤を使って画面やデータ項目を比較的短期間で組み立てる方法です。園独自の児童票、健康項目、CSV出力などを作りやすい反面、担当者が退職した後の保守やライセンス継続性が弱点になります。見積書では、初期開発だけでなく、基盤ライセンス、保守担当、障害対応、将来の仕様変更を含めて比較します。

フルスクラッチは、要件定義から設計、開発、テスト、運用基盤までを個別に作る方法です。複数法人をまたぐ権限、自治体の指定帳票、会計・給与・決済との深い連携、独自の保育記録など、既製サービスでは業務を変えにくい場合に検討します。

一方で、初期費用と期間が大きくなり、法改正への対応、脆弱性対応、バックアップ、障害時の復旧、開発会社との契約更新を発注者側も管理します。業務の特殊性が一部だけなら、標準SaaSと外部連携を組み合わせるほうが、全機能を独自開発するよりリスクを抑えられる場合があります。

園児台帳と保護者連絡はSaaS、独自の請求や自治体帳票は別システム、データ連携はCSVまたはAPIという分け方もできます。重要なのは、システムごとに園児情報の正本を決め、同じ情報を複数画面で編集しないことです。連携方式、更新頻度、エラー時の再送、責任を持つ会社をRFPに書きます。

園児管理システムの発注・外注はどの順番で進めますか？

発注は、現状把握、RFP作成、候補会社への説明、提案・見積比較、契約、試行導入、データ移行、全園展開の順に進めると整理しやすいです。いきなり「園児管理システムを作ってください」と依頼するのではなく、現場の困りごとと成功指標を先に言語化します。

最初の2〜4週間は、園児台帳、登降園、欠席・遅刻、連絡帳、午睡、健康、事故、請求、帳票、写真、バスなどの業務を一覧にします。業務名だけでなく、誰が、いつ、どの端末で、どの情報を入力し、どの帳票や連絡に使うかまで記録します。

園長だけで決めると、現場の例外処理が抜けやすいです。主任、担任、事務、法人本部、必要に応じて自治体担当者から代表を選び、「入力が増えないか」「通信が切れたらどうするか」「卒園・退園後の情報をどう保存するか」を確認します。現場代表を要件定義に入れることが、トップダウン導入の失敗を減らします。

RFPには、対象園数、定員、在籍園児数、職員数、施設種別、利用端末、ネットワーク、既存システム、移行対象データ、必要な機能、権限、帳票、外部連携、セキュリティ、サポート、スケジュール、予算の考え方を記載します。必須機能と将来機能を分け、必須・望ましい・提案に任せるという優先順位を付けます。

会社ごとに見積条件が違うと価格比較ができないため、初期費用、設定費、開発費、データ移行、研修、端末、通信、月額、保守、決済手数料、追加改修を同じ項目で提示してもらいます。公開SaaSと受託開発を同じ土俵で比較する場合は、3年間の総額と、導入できる業務範囲を別々に評価します。

契約前または本稼働前に、1園または1クラスで4〜8週間の試行導入を行います。登降園、欠席連絡、連絡帳、園児台帳など優先度の高い業務に絞り、入力時間、保護者の利用率、電話件数、誤入力、紙との二重管理件数を測定します。デモで操作できても、忙しい時間帯に片手で入力できるとは限らないためです。

試行期間中は、紙を完全にやめるか、どの業務だけ併用するかを決めます。通信障害や端末故障が起きた場合の代替手段、問い合わせの一次窓口、修正依頼の締切も確認します。試行結果をもとに要件を修正してから全園展開すれば、現場の負担を見ずに高額な追加開発を決めるリスクを抑えられます。

紙やExcelからの移行では、氏名の表記揺れ、きょうだいの重複、旧住所、退園者、緊急連絡先、アレルギー情報の欠落が起こりやすいです。移行対象、移行しない履歴、データクレンジングの担当、テスト移行、受入確認、本番移行、バックアップをRFPと契約書に分けて書きます。

研修も「操作説明会を1回実施する」だけでは足りません。管理者向け、担任向け、事務担当向けに分け、実際の園児データを使った演習、マニュアル、問い合わせ期間、入職者向けの教育方法まで決めます。保護者にも登録方法、通知設定、写真や個人情報の同意、障害時の連絡方法を説明します。

RFPと要件整理で何を決めるべきか

RFPは、開発会社に丸投げするための依頼書ではなく、発注者と受託者の認識をそろえる比較資料です。画面の希望だけでなく、業務の目的、利用者、データの流れ、例外処理、運用ルール、非機能要件、受入条件まで記載すると、提案と見積の差が小さくなります。

必須項目は、園児基本情報、保護者・家族、緊急連絡先、認定区分、保育時間、アレルギー、服薬、既往歴、配慮事項、入退園日、同意履歴などです。園ごとに必要な項目を追加できるか、未入力を警告できるか、変更履歴を確認できるか、卒園後に閲覧できるかを確認します。

業務フローは、「欠席連絡を保護者が入力する」「担任が確認する」「管理者が一覧で未対応を確認する」「延長保育時間を集計する」といった動詞で書きます。お迎え予定者の変更、食物アレルギーの更新、午睡中の異常、緊急連絡の一斉配信など、通常処理だけでなく例外処理も含めることが大切です。

園児情報には健康、アレルギー、服薬、発達、家庭状況など慎重に扱う情報が含まれます。園長、主任、担任、看護師、事務、法人本部、保護者で、閲覧・登録・承認・出力・削除の権限を分け、職員の異動や退職時にアカウントを止める手順まで決めます。

確認項目は、多要素認証、通信時・保存時の暗号化、IP制限、操作ログ、バックアップ頻度、復旧目標、障害通知、脆弱性対応、再委託先、海外拠点や海外クラウドの利用、データ削除・返却です。個人情報保護委員会の通則ガイドラインは、委託先に対して必要かつ適切な監督を求めているため、「認証マークがあるから安全」と決めつけず、園のリスクに合う証跡を確認します。（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）

会計、給与、勤怠、決済、写真販売、バス運行、自治体の指定帳票などとつなぐ場合、連携先、方式、データ項目、更新タイミング、エラー通知、再処理方法を整理します。CSV連携ならファイル形式と文字コード、API連携なら認証と利用制限を決め、連携先の仕様変更に誰が対応するかも書きます。

移行では、旧データをそのまま取り込むのか、過去何年度分を対象にするのか、写真や添付ファイルを含むのかが費用を左右します。ベンダーの担当範囲を「抽出支援」「変換」「取込」「照合」「誤りの修正」に分け、園側が確認するサンプル件数と承認者を決めます。

受入条件は、「ログインできる」だけでなく、「保護者が欠席連絡を送り、担任が確認し、管理者が未対応一覧を見られる」「登降園データから延長時間を集計し、請求データへ渡せる」といったシナリオで作ります。園の繁忙時間帯、複数クラス、スマートフォン、タブレット、通信が弱い場所でも確認します。

障害時の代替運用も受入条件に含めます。通知が届かない場合、登降園端末が止まった場合、誤ったアレルギー情報を訂正する場合に、誰がどの記録を残し、復旧後にどのデータを再入力するかを確認します。これにより、開発完了と現場で使える状態のずれを小さくできます。

契約形態と責任分界をどう設計するか

園児管理システムの外注では、要件が固まっている開発部分と、相談しながら進める企画・改善部分で契約形態を分けることがあります。請負か準委任かという名称だけで決めず、成果物、作業時間、品質責任、仕様変更、検収、再委託、知的財産、個人情報の扱いを契約書で確認します。

請負契約は、決めた成果物を完成させ、発注者が検収することを前提にしやすい契約です。画面一覧、機能仕様、テスト仕様書、移行結果、操作マニュアル、納品ソースコードなど、何を納品物とするかを明確にします。完成の基準が曖昧なまま請負にすると、追加要望が仕様変更として扱われ、納期と費用の調整が頻発します。

検収期間、修正の扱い、瑕疵への対応、受入テストで不合格になった場合の再実施、遅延時の連絡、第三者サービスの障害責任も確認します。請負だからすべての結果をベンダーが保証するわけではなく、発注者が提供するデータや確認の遅れが納期に影響する条件も整理する必要があります。

準委任契約は、専門家が善管注意義務をもって、要件定義、プロジェクト管理、調査、改善、運用支援などの業務を行う形で使われます。最初から仕様を確定しにくい園児管理システムでは、現場ヒアリングや試行導入を準委任で進め、要件が固まった機能を請負で開発する組み合わせも選べます。

準委任では、作業時間や体制、定例会、成果物の報告、意思決定者、時間超過の承認方法を決めます。成果物の完成保証や納期保証を期待するなら、契約の目的と責任範囲が合っているかを法務担当者に確認します。契約形態の判断は、システム開発に詳しい専門家へ相談することも有効です。

契約では、園児・保護者・職員データの管理者、利用目的、アクセス可能な担当者、再委託先、事故発生時の報告期限、監査への協力、バックアップ、契約終了時の返却形式と削除証明を確認します。独自に作った画面や帳票の著作権、汎用部品の利用権、ソースコードの開示範囲も、将来の乗り換えに関わります。

特にSaaSでは、利用規約だけでなく、個別契約、サービス仕様書、セキュリティ資料、障害対応方針を一緒に読みます。サービス終了や事業譲渡が起きた場合に、園児台帳、添付ファイル、操作ログをどの形式で、いつまでに取り出せるかが分からない契約は、価格が安くても長期利用の不確実性が残ります。

本稼働後は、問い合わせ、障害、機能改善、アカウント発行、年度更新、自治体帳票の変更、端末交換が発生します。保守費に含まれる範囲、問い合わせ受付時間、重大障害の初動時間、復旧目標、定期メンテナンス、軽微な修正と有償改修の境界を確認します。

保育中に使えない時間が長いと安全確認や保護者連絡に影響するため、障害時の電話窓口、メールや管理画面の通知、紙での代替、復旧後のデータ照合を運用手順に落とします。SLAの数値だけでなく、現場が実際に取れる行動まで決めておくことが重要です。

費用相場と見積書の読み方

費用は、園児数や園数だけでなく、機能、端末、ネットワーク、データ移行、帳票、外部連携、研修、保守、決済、個別カスタマイズで変わります。ここでは2026年時点で確認できる公開料金と民間概算を分け、特定の案件にそのまま当てはめない前提でレンジを示します。

公開料金の例では、CoDMONは定員30名までの基本利用料が月額3,300円、31〜60名が5,500円、61〜100名が8,800円（税込）と案内され、登降園、帳票、請求、健康記録などは機能やパックによって追加料金が発生します。（出典: 株式会社コドモン「CoDMONご利用料金」、2026年8月確認）

ルクミーにも、園児台帳・成長記録などを含む月額5,000円（税抜）のカスタマイズプランや、伴走支援を含む月額30,000円（税抜）のプランが公開されています。（出典: ユニファ株式会社「ルクミー料金プラン」、2026年8月確認）これらの公開例を整理すると、園児台帳と保護者連絡を中心にする場合は月額3,000〜10,000円程度、登降園、請求、帳票、安全機能などを複数追加する場合は月額1万〜4万円程度を比較の初期目安にできます。ただし、これは市場平均ではなく、公開価格から整理したレンジです。

民間企業が公開する2026年時点の概算では、園児管理と登降園で300万〜600万円、保護者アプリを加えて600万〜1,200万円、請求管理まで含めて1,200万〜2,000万円、写真・指導計画・行政連携まで含むフルスペックで2,000万〜4,000万円程度という幅が示されています。（出典: GXO「保育園・幼稚園ICTシステム開発の費用相場」、2026年確認）これは一般的な民間概算であり、正式見積ではありません。

園児数、対象園数、複数法人の権限、独自帳票、既存データの状態、外部連携、監査ログ、端末や通信、研修、保守が増えるほど上振れします。逆に、標準SaaSを利用し、CSV移行と基本設定だけで始めるなら、独自開発より小さな初期費用に抑えられる可能性があります。見積の数字だけでなく、その数字でどの業務まで使えるかを確認します。

公的調達の例では、江戸川区立保育園業務支援システムの令和7年度契約上限額が総額897万6,000円で、初期費用27万5,000円、サービス利用料870万1,000円とされています。（出典: 江戸川区「保育園業務支援システム導入および運用保守業務 実施要領」、2025年）これは複数の公立園を対象にした契約上限であり、1園の開発費に単純換算できませんが、初期準備、利用料、運用保守を分けて調達する視点を示しています。

こども家庭庁のICT化推進事業では、機能数に応じて1施設あたり20万円、40万円、60万円、80万円の補助基準額が示され、端末購入などを併せる場合は70万円、90万円、110万円、130万円となる資料があります。（出典: こども家庭庁「令和7年度保育関係補正予算の概要」）対象経費、補助率、申請時期、自治体の上乗せ、既存補助との重複可否が異なるため、「補助金で無料になる」とは考えず、自己負担と月額利用料まで確認します。

3年TCOでは、初期費用、月額・年額、オプション、端末、Wi-Fi、通信費、データ移行、研修、保守、決済手数料、追加改修、年度更新、データ出力を足します。SaaSは初期費用が小さくても、園児数や機能追加で月額が積み上がります。独自開発は初期費用が大きくても、運用保守や法改正対応を別に確保しなければなりません。

また、職員の入力時間、電話対応、帳票作成、請求修正、紙の保管、データ確認にかかる内部コストも見ます。導入効果を「必ず何時間減る」と断定せず、現状の作業時間を1週間測定し、試行導入後の実績で比較します。安い見積よりも、必要な範囲と運用負担が説明できる見積を選ぶことが大切です。

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

委託先は、知名度や営業資料の印象だけでなく、保育業務の理解、データ移行、現場定着、セキュリティ、障害対応、将来のデータ連携を同じ基準で評価します。標準SaaSを導入する会社と、独自システムを受託開発する会社では得意領域が異なるため、まず自園の発注形態を決めてから候補を絞ります。

実績は「導入社数」だけでは足りません。保育園、幼稚園、認定こども園、公立園、企業主導型のどれに対応したか、1園か複数園か、園児台帳から請求や帳票まで使われているか、導入後の定着率やサポート体制を尋ねます。可能であれば、同じ規模と施設種別の導入先から、発注前の注意点を聞きます。

デモでは、架空のきれいなデータではなく、実際の業務シナリオを見せてもらいます。兄弟の登録、アレルギーの更新、担任交代、欠席連絡の未確認、延長料金、年度更新、退園処理、自治体帳票の出力を操作し、現場の職員が迷わず扱えるかを確認します。

見積書では、要件定義、画面設計、開発、テスト、移行、研修、マニュアル、初期設定、プロジェクト管理、保守を行ごとに分けてもらいます。「一式」の行があれば、人数、期間、作業内容、成果物、前提条件を質問します。特に、帳票追加、CSV整形、写真移行、端末設定、保護者登録支援、年度更新が別料金かを確認します。

価格だけでなく、提案の前提をそろえることが重要です。対象園数と園児数、同時接続数、利用端末、データ移行件数、想定する保護者数、必要な帳票数、保守時間を同じ条件にして、初期費用と3年TCOを比較します。安い会社が機能不足なのか、別会社が過剰提案なのかを、業務シナリオで見極めます。

質問例は、「園児台帳を正本としてどの機能に連携できるか」「CSVやAPIで全データを取り出せるか」「データを扱う再委託先はどこか」「職員の退職時に権限をどう止めるか」「障害時の一次連絡は誰か」「法改正や自治体帳票の変更費用は誰が負担するか」です。回答を口頭で終わらせず、提案書や契約書に残します。

AI、午睡センサー、スマート検温、写真整理、多言語翻訳などの機能は、便利さだけでなく、人が確認する責任、誤出力時の対応、入力データの学習利用、機器停止時の代替を確認します。AIやセンサーだけで園児の安全を保証するような説明をする会社は避け、保育者の判断を補助する位置付けを明確にする会社を選びます。

候補を2〜4社程度に絞ったら、同じ業務シナリオでデモ、試行、見積説明を受けます。評価表は、業務適合性、使いやすさ、データ移行、セキュリティ、連携性、サポート、費用、契約の柔軟性に分け、園長だけでなく現場職員と事務担当の評価も反映します。

最終的には、機能の多さより「現場が毎日使い続けられるか」「必要な情報を正しく最新に保てるか」「契約終了後もデータを利用できるか」で判断します。導入後の月次レビューで入力時間、電話件数、帳票作成時間、請求修正、保護者利用率を確認し、改善計画まで提示できる委託先なら、発注後の定着も進めやすくなります。

よくある質問（FAQ）

発注前によくある疑問を、費用、導入期間、データとセキュリティの観点から回答します。個別の金額や期間は、対象園、機能、移行範囲、既存システムによって変わるため、ここでは判断の基準を示します。

標準的な園児台帳、登降園、保護者連絡を早く始めたいならSaaSが向いており、独自帳票や複雑な自治体連携が中心ならカスタム開発を検討します。まず標準SaaSのデモで業務をどこまで合わせられるかを確認し、合わない部分だけ追加開発する方法も有効です。

公開SaaSの例では、基本機能が月額3,000〜10,000円程度、複数機能を追加すると月額1万〜4万円程度が初期比較の目安です。カスタム開発は、園児管理と登降園で300万〜600万円、機能や連携が増えると600万〜4,000万円程度まで幅がありますが、いずれも公開料金や民間概算から整理した目安であり、正式見積ではありません。

施設種別、園数、定員、在籍園児数、職員数、現行の帳票、紙・Excelの台帳、利用端末、ネットワーク、既存システム、移行したいデータ、必要な外部連携、希望時期、予算の考え方を準備します。現場の1日の流れと例外処理を図や文章で示し、必須機能と将来機能を分けると、提案の比較がしやすくなります。

閲覧権限、認証、操作ログ、暗号化、バックアップ、障害通知、再委託、データの保管場所、削除・返却、契約終了後の保存期間を確認します。委託先のセキュリティ資料を受け取るだけでなく、園が必要とするリスクに対して十分かを確認し、事故時の報告窓口と連絡期限を契約に記載します。

まとめ

保育園・幼稚園向け園児管理システムの発注では、最初に園の業務とデータを棚卸しし、SaaS、パッケージ、ローコード、独自開発のどれが適するかを決めます。そのうえでRFPに機能、権限、移行、連携、セキュリティ、保守、受入条件を記載し、同じ条件の見積を複数社から取得します。

比較時は、初期費用や月額だけでなく、データ移行、端末、研修、帳票追加、決済、保守、解約時のデータ返却を含む3年TCOを見ます。園児情報を扱うため、権限、操作ログ、バックアップ、障害時の代替、再委託先の監督まで確認し、試行導入で現場の入力負担を測定してから全園展開を判断します。

よい委託先は、機能を売るだけでなく、現場の例外処理、職員研修、保護者への説明、導入後の改善まで一緒に設計します。園側の責任者と現場代表を置き、成果指標を継続的に確認すれば、園児情報を安全に活用しながら、紙・Excel・電話による二重管理を段階的に減らせます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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