自治体向け子育て支援システムは、基幹業務、住民向け窓口、相談・施設管理を連携させることで、子育て世帯と職員の手続きを一体的に支える仕組みです。各テーマの詳細は、下の関連記事で確認できます。
▼関連記事一覧
・自治体向け子育て支援システム開発の進め方/やり方/流れや方法/手法/工程/手順
・自治体向け子育て支援システム開発でおすすめの開発会社/ベンダー6選と選び方
・自治体向け子育て支援システム開発の見積相場や費用/コスト/値段について
・自治体向け子育て支援システム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自治体向け子育て支援システムの全体像
このシステムは、特定の一製品を指す言葉ではなく、自治体内の給付・認定業務、住民向けオンライン窓口、相談や施設との情報共有をつなぐ仕組み全般を指します。
基幹業務を処理するシステム
基幹業務は、認定や利用調整、費用算定に加えて、給付、徴収、施設管理などにわたります。
- 認定と利用調整：教育・保育給付の認定や、施設の利用に関わる手続きを扱う領域です。
- 費用の算定と給付：保育料や利用者負担額、施設等利用給付、給付費の計算を担います。
- 徴収・還付と施設管理：納付の管理や払い戻しの処理、帳票の作成を行います。
児童と保護者、世帯の情報を管理し、所得や住所、在籍情報もあわせて扱います。また、住民記録や税、児童手当などの情報とは、必要な範囲で連携します。
利用調整では、きょうだいの同園や転園、広域入所、指数計算が絡みます。さらに、自治体独自の優先順位や減免も考慮が必要です。
機能一覧に「利用調整あり」と書かれていても、選考ルールや例外処理まで設定できるかは別の問題です。そこで、実データに近いケースを使って確かめます。
住民向け・現場向けのシステム
住民向けには、制度検索や保育所の空き情報、電子申請を提供し、申請状況の照会や予約にも対応します。加えて、健診や予防接種のお知らせ、相談窓口の案内も扱います。
- 住民向け窓口：制度検索や空き情報の確認から、電子申請、予約、通知、相談案内まで。
- 現場向け支援：相談記録や関係機関との連携、施設への給付と監査にわたる業務。
同じ制度情報を、自治体のWebサイト、スマートフォン、マイナポータルに載せることがあります。その場合は、制度情報を一か所で管理し、更新内容を各チャネルに配信できる設計が望ましいです。
現場向けの業務には、こども家庭センターなどの相談受付やアセスメントがあります。サポートプランやケース記録も扱い、関係機関との連携も行います。施設への実績報告や、放課後児童クラブなどの利用管理も含まれます。
基幹業務と住民向け機能は、必ずしも一つの画面にまとめる必要があるわけではありません。大切なのは、正本データと連携の責任を明確にすることです。
標準仕様と2026年の最新動向
2026年の調達では、標準仕様への適合に加えて、自治体独自の業務との境界を確かめておく必要があります。データ連携や今後の改定も、同時に確認しておきます。
こども家庭庁は2026年1月30日に標準仕様書第2.0版を公開しました。機能要件だけでなく、帳票要件、印字項目、帳票レイアウトも示しています（出典: こども家庭庁「標準仕様書（子ども・子育て支援）」、2026年）。
標準仕様のMUSTと自治体独自の差分
標準仕様は、自治体ごとに異なる仕組みを一定のルールに寄せ、移行や共同利用を進めやすくするための基準です。ただし、記載された機能だけで自治体のすべての業務を運用できるとは限りません。
- 標準機能：必須となる機能と、標準に合わせる業務を分けて整理する。
- 自治体独自の差分：独自に残す業務と、将来の追加候補。
- Fit & Gapの確認：優先順位や減免、広域利用、帳票注記、年度切替の手順を検証する。
標準外の機能を増やしすぎると、制度改正のたびに個別の改修が発生しがちです。一方で、現場の安全性や法定事務に関わる差分を無理に削ると、稼働後にExcelや手作業へ戻ることがあります。そこで、削ってよい差分かどうかは、業務効果とリスクで決めます。
制度レジストリと保育DXの連携候補
デジタル庁の子育て支援制度レジストリは、国や自治体の制度情報を構造化して集約し、アプリ事業者などが活用する仕組みです。
- 制度情報を整備する：担当課と更新頻度を決め、審査担当や公開前の確認も定めておく。
- 制度レジストリを活用する：API連携の対象になる制度情報から、活用の候補を選ぶ。
- 保育DXとの境界を決める：独自システムで持つ業務と、CSVで連携する部分を調達の前に確かめる。
2025年11月にアプリ事業者へのAPI連携が始まりました。2025年11月1日時点では、未就学児向けを中心に124種類の制度類型が対象です（出典: デジタル庁「子育て支援制度レジストリ」、2026年3月更新）。
制度情報の管理体制を決めておけば、情報が古いまま残ることによる取りこぼしを防げます。
こども家庭庁の保育業務施設管理プラットフォームは、自治体の給付・監査事務と保育施設側の業務を標準化して電子化する、国主導の基盤です。2026年度の運用に向けて、自治体・施設向けの説明やアカウント準備が進んでいます（出典: こども家庭庁「保育業務施設管理プラットフォーム」、2026年）。
自治体向け子育て支援システムの種類と選択肢
方式は、パッケージやクラウド、オンプレミス、スクラッチといった技術の名前だけで決めると、判断を誤りやすくなります。対象業務の標準化しやすさや独自要件に加え、既存環境と職員の運用能力も比べます。さらに、5年程度の総保有コスト（TCO）も比較の軸にします。
標準パッケージ・SaaSを使う方法
標準パッケージやSaaSは、設定と移行を中心に導入する方式です。ゼロから開発する場合と比べて、導入期間や品質の見通しを立てやすいのが利点です。
- 基本機能：認定や利用調整、給付などの業務を備え、帳票や制度改正にも対応します。
- 導入と保守：法改正に応じた保守を受けやすい。
- 独自要件：追加オプションや別契約、手作業が前提になる場合もあります。
ただし、自治体独自の選考ルールや帳票を、どこまで設定で対応できるかは確認が必要です。デモは一般的な例ではなく、自治体の代表ケースを再現してもらいます。たとえば、きょうだいの同園や転園、減免のほか、年度途中の変更と広域入所も含めます。
ガバメントクラウド・LGWAN-ASP・オンプレミスの比較
クラウドとオンプレミスは、更新の負担や運用の責任、長期の費用を同じ条件で比べます。
- クラウドの運用：利用料やネットワーク、バックアップ、監視、障害時の連絡、データ返却を設計する。
- 責任の分け方：クラウド側と自治体側の役割を、契約書で明らかにしておく。
- オンプレミスの責任：更新や脆弱性対応、バックアップ、災害復旧を自治体が受け持つ。
- 5年TCO：保守や機器の入れ替え、電源と設置、復旧訓練まで含めて計算する。
ガバメントクラウドやLGWAN-ASPは、サーバーや基盤の更新を自治体が個別に抱える負担を減らしやすい方式です。一方で、オンプレミスは既存の設備や閉域網を活用できる場合があります。
初期費用だけを見ると安く見えても、5年間の費用で比べると結果が変わることがあります。
スクラッチ開発とハイブリッド構成
スクラッチ開発は、自治体独自の業務や住民の利用体験を細かく設計できます。一方で、標準仕様への追随や制度改正、テスト、保守、担当交代時の知識継承の負担が重くなります。
- 構成の選択：標準に準拠した基幹パッケージを土台にする方法があります。
- APIでの拡張：住民ポータルや相談支援、分析、申請補助を、APIで追加できます。
- 連携の管理：正本データの管理先、再送の担当、項目定義の変更管理者を決める。
- 運用設計：データ項目や更新時期、エラー処理、監査ログを、先に定めておく。
基幹業務まで全面的に独自開発するより、APIで機能を補う構成のほうが現実的な場合も多くあります。
ハイブリッド構成では、児童や世帯の情報の正本をどのシステムが持つかを決めておく必要があります。画面を一つにまとめるよりも、連携とデータ管理の責任を明確にすることが大切です。
自治体向け子育て支援システムの進め方10段階
製品選定から始めると、要件が製品の機能に引っ張られがちです。そこで、業務とデータの現状を一覧にし、調達から効果測定までを一つの計画にまとめます。
代表的な進め方は、現状調査から効果測定までの10段階です。
▶ 詳細はこちら：自治体向け子育て支援システム開発の進め方/やり方/流れや方法/手法/工程/手順
1〜3段階目：現状調査・標準比較・RFP作成
業務の全体が見えていないと、必要な機能を取りこぼしたまま製品を比べることになります。そこで、担当課ごとの業務を洗い出し、紙やExcel、メール、電話での作業や、月次・年度更新の作業まで含めて把握します。
- 現状調査：業務や例外処理、承認経路、帳票、保有データを一覧にする。
- 標準仕様との比較：機能と帳票を現行業務と照らし合わせ、必須、代替、独自維持、廃止候補に分け、結果をRFPに反映する。
- RFP作成：提案依頼書に対象レイヤー、連携先、移行範囲を明記し、データ項目や試験、研修、保守、実現方法も書き込む。
申請から監査までの流れを業務フローにすると、二重入力や属人作業を見つけやすくなります。流れには、審査や認定、施設利用が含まれます。給付・徴収を経て、通知と監査に至ります。
特に、制度改正時の費用はRFPに明記しておきます。提案依頼書では、「できますか」と聞くだけでなく、設定・追加開発・運用のどれで実現するかを書いてもらいます。
4〜6段階目：提案比較・データ整備・試行
提案を比べるときは、機能の数より、自治体の代表ケースを処理できるかを見ます。
- 提案の試行：関係者が同じシナリオで、機能と価格を評価する。
- データ整備：移行対象と、重複や欠損などの扱いを整理する。
- 移行リハーサル：本番に近い形の移行を、少なくとも一度行う。
評価は、入力から審査、通知までを一続きで見るのが基本です。訂正や取消、監査ログまで通して確かめます。価格も、初期導入と移行、月額・年額の費用、制度改正や問い合わせ対応などに分けて点数化します。
移行対象は、児童や保護者、世帯の情報を中心に、在籍や認定、給付の履歴などです。旧住所や表記の揺れ、終了したデータの扱いは、移行の前に決めておきます。個人番号の扱いは、特に慎重に整理します。
本番データは、そのままテスト環境に複製せず、匿名化やマスキングをした検証データを使います。そのうえで、抽出や変換、取込の手順と、件数や金額、画面の照合を担う責任者を決めておきます。
7〜10段階目：受入試験・年度切替・定着・効果測定
単体テストに加えて、住基や税、福祉、電子申請などとの連携テストも行います。
- 受入試験：権限や負荷、障害からの復旧を確かめ、帳票と通知も検証する。
- 年度切替：前年の実績を使って、一連の処理を試しておく。
- 現場定着：現場で使う手順や窓口、代替運用、制度改正の管理を決めておく。
- 効果測定：導入の効果を測り、運用上の課題を見つける。
年度切替では、認定や保育料、加算が同時に動きます。施設や児童の進級、申請受付、通知時期も重なります。そのため、年度切替は一連の流れとして確かめる必要があります。
稼働後は、職員研修を一度行うだけでは現場に定着しにくい点に注意します。
効果測定では、問い合わせ件数や審査時間、二重入力件数を導入前後で比べます。帳票作成の時間も、導入前後で比べます。
オンライン申請率や施設からの差戻し、制度情報の到達率、重大インシデント件数も、あわせて見ていきます。
自治体向け子育て支援システムの費用相場
費用は、人口や施設数、対象業務の範囲で大きく変わります。既存システムやデータ量、独自帳票、連携数、移行方法の違いも、費用を左右します。
製品価格が非公開の案件も多いため、ここで示す数字は市場全体の平均ではありません。公開契約額と類似案件から整理した目安です。
自治体の予算要求や正式な調達では、現状調査のあとにまとめた見積もりに置き換える必要があります。
▶ 詳細はこちら：自治体向け子育て支援システム開発の見積相場や費用/コスト/値段について
公開契約額から見る費用の幅
公開されている契約額からも、同じ子育て支援分野でも業務の範囲によって金額が違うことが分かります。
- 標準化関連：1,427万8,000円の契約例。
- データ抽出：プログラム作成は1,669万5,250円の例。
- 移行データ抽出：352万8,800円の契約例。
- 改正・マスタ変更：277万6,400円と63万9,100円の例。
これらは自治体ごとの委託内容に対する契約額であり、全国共通の相場ではありません（出典: 各自治体の2025年契約資料）。
改正・マスタ変更の例は、2026年の制度改正対応と第一子の保育料無償化に伴うマスタ更新の契約例です。
移行や制度改正、マスタ変更、機器やクラウドの費用は、初期構築費とは別に発生します。そのため、すべてを初期構築費に含む前提で計画しない方が安全です（出典: 札幌市・東京都北区の契約資料、2025〜2026年）。
対象範囲別の推定レンジ
費用と期間は、どこまでを対象にするかで大きく変わります。次の4つの区分の推定レンジは、その違いを示したものです。
- 小規模な設定・移行：500万〜1,500万円、4〜9か月程度。
- 中規模の基幹刷新：1,000万〜3,000万円で、期間は9〜18か月程度。
- 住民向けポータル・アプリ：500万〜2,000万円、4〜10か月程度。
- 相談・ケース管理：1,000万〜3,000万円超、9〜18か月程度になる場合があります。
小規模でも、住基や税、児童手当との連携や帳票の確認、研修、受入試験を含めると、費用は上振れします。
住民向けの開発には、制度検索や通知、認証のほか、電子申請との連携や管理画面、アクセシビリティも含まれます。
相談・ケース管理では、機微情報の権限設計や関係機関との連携が加わります。
初期費用以外に、年間保守やクラウドの利用料、制度改正への対応が発生します。また、ネットワークやバックアップ、監視の費用もかかります。さらに、追加施設や帳票の変更、職員研修、データ返却も見込んでおきます。
工程の配分の目安は、要件定義が10〜15%、設計が15〜20%、開発が30〜40%です。テストは15〜20%、移行は5〜10%が目安になります。子育て分野では、移行や帳票、受入試験を削らない方が安全です。
年間保守は、初期開発費の15〜20%程度とする見方もあります。契約条件を含めた3〜5年のTCOで比べます。
データ連携・セキュリティ・運用の確認項目
世帯情報や所得、認定、相談記録などのほか、支援措置対象者の情報も扱います。漏えいや誤表示は重大な影響につながるため、機能要件と同じ水準で設計します。
発注側と開発会社は、誰が何を閲覧・変更できるか、変更の履歴をどう追うかを決めます。
連携項目と正本データ
連携先は、住民記録や税、児童手当、福祉などのほか、電子申請や施設情報、通知サービスも含みます。そのうえで、連携先ごとに管理項目を整理します。
- 連携仕様：項目やキー、更新頻度、訂正方法、責任者を定める。
- 再送と停止時対応：再送を担う人と、止まったときに業務を続ける手順。
- 返却条件：エクスポートの形式と頻度、終了時の返却方法を契約に含める。
世帯や児童を同じ人として判断するキーが違うと、きょうだい関係や住所変更の情報が食い違います。そのため、統合宛名や識別子の扱いを先に確かめます。
連携方式はAPI、CSV、ファイルのどれかを選ぶだけでなく、連携が止まったときの業務継続も決めます。さらに、未連携の件数や再処理の状況、担当課、期限を追えるようにしておきます。
最小権限・監査ログ・委託先管理の運用
権限は、課や職種だけでなく、業務や施設、地域、支援措置の有無、操作単位まで含めて設計します。
- 権限と認証：参照、登録、承認、出力を分けたうえで、多要素認証を使う。
- 保護と記録：暗号化や脆弱性対応、バックアップ、復旧、操作ログの記録まで備える。
- 委託先管理：アクセスや保守の承認、事故の報告、削除の証跡を契約で決めておく。
- 表示テスト：支援措置対象者の情報が、各出力先で漏れないかを確かめる。
通信時と保存時の暗号化、災害復旧も確かめたうえで、管理者権限は常時付与しない運用にします。
委託先と再委託先について、データへのアクセスや、保守時の申請・承認・記録、障害や漏えい時の報告期限を、契約に明記します。
DV等の支援措置対象者は、住所を通常の非表示にするだけでは足りない場合があります。検索や一覧、帳票の出力で、意図しない表示がないかをテストします。通知や連携ファイル、ログも対象です。
開発会社/ベンダーの選び方
開発会社やベンダーは、自治体業務への理解や、標準仕様と独自要件の整理、移行、稼働後の保守をもとに選びます。知名度や機能数だけでは判断しにくい点に注意が必要です。
基幹業務、住民向けサービス、施設・相談業務では、得意な領域が事業者によって異なります。そのため、必要な層を先に切り分けておきます。
自治体業務と標準化の経験
導入件数だけでなく、自治体業務と標準仕様への具体的な対応実績も確かめます。
- 業務実績：認定や利用調整、給付、施設管理などの実績。
- 標準化対応：近い人口や施設数の自治体での稼働と、対応する仕様の版。
- 導入・運用体制：移行や試験、研修、保守の計画と担当者。
可能であれば、導入済みの自治体に、移行で苦労した点や年度切替、追加費用の実態を聞きます。
提案書では、標準との差分や独自帳票の対応、連携方式、移行サンプルを確かめます。障害時の体制や担当者の経験も、提案の段階で見ておきます。
「対応可能」という回答だけでなく、標準機能か、設定か、追加開発か、運用での回避策かを明示してもらうと比べやすくなります。
導入後の体制と契約条件の比較
導入後は、制度改正への対応の速さや問い合わせ窓口、障害時の連絡網を確かめます。運用改善の定例会や、追加開発の見積ルールも見ておきます。
- 保守の範囲：無償と別料金の境目、法改正の判定を誰が担うかを決める。
- 運用変更：帳票の変更、職員異動時のアカウント管理、施設追加、データ修正の扱い。
- 契約終了や事業者変更への備え：返却の形式や費用、移行支援、APIや仕様書の開示範囲、ログの保存まで決めておく。
- 手順の引継ぎ：設定値や連携項目、帳票定義、障害対応、年度切替の手順を、自治体側の文書に残す。
これらを契約前に確かめておかないと、後で話がかみ合わなくなることがあります。
▶ 詳細はこちら：自治体向け子育て支援システム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：自治体向け子育て支援システム開発の発注/外注/依頼/委託方法について
導入で起きやすい失敗と対策
失敗は、性能が足りないことだけで起きるわけではありません。対象範囲や責任の分け方を決めないまま契約すると、それも失敗の原因になります。たとえば、住民向けの画面を先に作り、基幹側のデータや審査の流れが整っていないと、二重入力が残ります。
機能の詰め込みと導入目的のぼやけ
基幹業務や申請、予約に加えて、相談、通知、施設管理、分析まで、一度に実現したくなることがあります。しかし初回リリースに詰め込むと、法定業務の試験や移行が後回しになり、予算と期間が膨らみます。
優先の順番は、法定業務、住民の不便が大きい業務、職員の二重入力を減らす業務の順です。一方で、将来の拡張に備えたAPIとデータ設計は、先に確保しておきます。
稼働後の制度改正と現場定着の見落とし
保守契約の一文だけで制度改正への対応を決めてしまうと、無償の範囲と追加費用の境目が分からなくなります。
制度改正の対応は、年度切替のカレンダーに組み込んでおきます。
- 改正情報を集め、影響を分析する。
- 設定と帳票を変えて、テストまで行う。
- 通知とリリースを行い、職員へ周知する。
現場に定着させるには、操作研修に加えて、例外や訂正の処理を含む手順が必要です。そのうえで、問い合わせを記録し、同じ質問が繰り返される画面や帳票を改善します。
オンライン化率だけでなく、住民の途中離脱や職員の確認作業、施設からの差戻しも追います。
自治体向け子育て支援システムのよくある質問
調達や導入計画で聞かれやすい点をまとめました。回答は自治体の規模や既存環境で変わるため、自治体の業務量とデータに照らして確かめてください。
標準仕様に対応していれば自治体独自の業務も運用できますか？
標準仕様に対応していても、自治体独自の業務をすべて運用できるとは限りません。
利用調整や減免、広域入所、帳票、年度更新などの差分は、Fit & Gapで確かめます。そのうえで、設定と追加開発、業務手順の変更のどれで対応するかを決めます。
自治体向け子育て支援システムの導入期間はどのくらいですか？
小規模な標準パッケージ設定と移行は4〜9か月、中規模の基幹刷新は9〜18か月程度が目安です。
期間は、対象業務や施設数、連携数で変わります。独自帳票やデータの状態、年度切替の時期も関係します。要件定義や移行リハーサル、受入試験、研修も含めて見積もります。
住民向けアプリだけを先に導入してもよいですか？
可能ですが、先に基幹側の正本データと、制度情報の更新責任、申請受付後の審査担当を決めておく必要があります。
アプリだけを先行させると、職員が申請内容を別のシステムへ打ち直す手間が増えかねません。そこで、対象の制度を絞ったAPI連携や申請状況の返却まで含む、小さな実証から始めると安全です。
相談記録や支援措置対象者の情報はどのように守りますか？
守り方の基本は、最小権限や多要素認証、暗号化などを組み合わせることです。加えて、操作と閲覧のログ、バックアップ、災害復旧、保守時の承認、委託先の管理も含めます。
通常の画面に加えて、検索候補やCSV、帳票も確かめます。通知や連携ファイル、テスト環境も対象です。そのうえで、支援措置対象者が意図せず推測されないかを、受入試験で検証します。
まとめ
自治体向け子育て支援システムは、基幹業務、住民向けの窓口、現場・相談支援の3層を扱います。申請から監査までの流れを、一続きにつなぐ仕組みです。審査や認定、施設利用に加えて、給付・徴収と通知も、この流れのなかで結ばれます。
標準仕様第2.0版を基準に、独自の利用調整や減免、帳票、広域利用、支援措置を、Fit & Gapで整理します。
導入成功のために押さえる要点
製品を選ぶ前に、現行の業務とデータの正本を整理します。初期費用だけで比べず、3〜5年のTCOで見ます。移行や研修、制度改正、クラウド、保守、データ返却も含めます。
機能の数より、自治体の代表ケースを使った受入試験と、稼働後の現場定着を評価します。
最初に作るべき資料
最初に作るのは、対象業務の一覧や業務フロー、連携先の一覧です。そのほか、データ項目表や代表ケース、帳票、権限の一覧、5年TCOの試算表も用意します。
資料をもとに、標準機能と独自開発の範囲を決めます。住民や施設、職員それぞれの負担がどう変わるかを確かめておくと、調達後の手戻りを抑えられます。
▼関連記事一覧
・自治体向け子育て支援システム開発の進め方/やり方/流れや方法/手法/工程/手順
・自治体向け子育て支援システム開発でおすすめの開発会社/ベンダー6選と選び方
・自治体向け子育て支援システム開発の見積相場や費用/コスト/値段について
・自治体向け子育て支援システム開発の発注/外注/依頼/委託方法について
▼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を創業。