遺失物管理システム開発の発注/外注/依頼/委託方法について

遺失物管理システムの発注は、現状把握、要件とRFPの整理、デモと試行の順に進めます。そのあと契約と受入テストまで段階を踏むと、予算と導入効果を両立しやすくなります。

発注形態と費用相場、要件と契約、委託先の選び方を順に説明します。全体像は遺失物管理システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・遺失物管理システム開発の完全ガイド

遺失物管理システムの発注で最初に決める全体像

業務量と運用単位を中心に、業務量、拠点・保管、管理単位、業務の流れ、現場の課題を5つのスポークで示した図。
5つの観点をそろえると、機能と現場運用の検討範囲を見渡せます。

遺失物管理システムは、拾得時の情報を正確に残し、複数拠点の物件を検索して、本人確認の後に返還し、必要な物件を期限内に警察へ届け出るための業務基盤です。

機能の多さだけで製品を選ぶと、現場の運用に合わないことがあります。そのため、発注時には、どの業務をどの拠点で誰が運用するかを先に決めておきます。

SaaS・個別設定・スクラッチから選ぶ発注形態

発注形態は、標準機能で足りるか、個別業務との連携が必要かを基準に選びます。

  • SaaS・クラウド:標準機能で初期開発と導入期間を抑え、法令・帳票の変更にも対応しやすい。
  • クラウド個別設定:拠点、権限、帳票、問い合わせフォームを調整して、標準化と業務への適合を両立させる。
  • スクラッチ:会員管理、予約、配車、ホテルPMS、コールセンター、配送との深い連携や独自ルールに向く。
  • ローコード・ノーコード:1施設の試作や社内受付に向く。本番運用では専門会社の設計レビューを検討する。

ローコードやノーコードで外部公開する場合や、複数企業間でデータを分ける場合、厳格なSLAや個人情報を扱う場合には、専門会社の設計レビューを入れておくと安全です。

発注前に把握する年間拾得数と拠点別の業務量

見積もりの前に業務量と運用単位を洗い出しておくと、拠点や権限を追加するときの費用を見込めます。

  • 業務量:年間拾得数、繁忙期の1日あたりの登録件数、利用者数、問い合わせ件数
  • 拠点・保管:拠点数、画像枚数、保管棚や場所の数
  • 管理単位:交通事業者は路線・便・営業所、商業施設は店舗・防災センター・警備会社
  • 業務の流れ:拾得、登録、保管、照会、返還、配送、警察提出、期限切れ処理
  • 現場の課題:保管場所への移動、台帳への重複転記、場所移動の未記録

登録の単位と問い合わせを受ける単位が異なることもあります。電話のたびに保管場所へ行くといった現場の実態も、機能の優先順位を決める材料になります。

遺失物管理システムの発注・外注の進め方

現状把握、要件整理、デモと試行、受入テスト、本番稼働の順に矢印でつないだ発注手順の図。
段階ごとに確認を進めると、試行結果を次の判断へつなげられます。

発注は、現状把握から本番稼働まで順に進めます。最初から全機能を確定させず、業務を止めないためのMVP(Minimum Viable Product)を定めておくと、見積もりと納期の精度が上がります。

  1. 現状を把握して、業務量と課題を整理する。
  2. 要件を整理し、RFPにまとめる。
  3. 候補会社への提案依頼と、デモ・試行。
  4. 契約後の設計・開発と、受入テスト。
  5. 現場教育を経た本番稼働。

MVPには、拾得物の登録や画像付き検索が入ります。保管場所や返還ステータス、警察提出用データも含めます。

現状把握によるMUSTとWANTの切り分け

要件整理では、業務に欠かせないMUSTと、あると便利なWANTを分けます。そのうえで、入力の負担と導入効果を見比べて、優先度を決めます。

  • MUST:拾得日時・場所・分類・特徴・保管場所・担当者の登録
  • MUST:フリーワード検索、拠点間の移動履歴
  • MUST:本人確認・返還履歴、警察提出対象の抽出
  • MUST:権限管理と操作ログ
  • WANT:画像候補、自然言語検索、LINE・Webフォーム、多言語、自動振り分け

紙やExcelから移行する場合、入力項目が増えるほど現場の登録は遅くなります。そこで、スマートフォンやタブレットで写真を撮り、必須項目だけで一次登録する方法もあります。

一次登録のあとに管理者が補足する二段階方式も候補になります。その場合は、入力ルールやカテゴリ一覧、表記揺れの扱いを先に決めておくと、検索精度と教育のしやすさが高まります。

RFPに書く業務量・連携・成果物

提案と見積もりの前提をそろえるため、RFPには対象施設や拠点数、年間拾得数を書きます。ピーク時の登録数や利用者の役割も記載します。

保管場所の管理方法や問い合わせ窓口も記します。さらに、画像の保存量と警察提出の頻度、既存システムとの連携方式も書きます。

成果物には、要件定義書や画面一覧、データ項目定義、移行計画を含めます。さらに、テスト計画や操作マニュアル、運用設計、障害時の連絡体制も入れます。

  • 費用:初期費用と月額費用の内訳
  • 開発範囲:標準機能と個別開発の線引き
  • オプション:必須と任意の別
  • 見積条件:作業時間と前提条件の提示

追加費用の条件は、連携先APIの制限や画像容量、端末調達について回答を求めます。データクレンジングや問い合わせ代行、現場教育も含めます。

デモと小規模試行による現場の使いやすさの確認

提案書だけでは判断せず、実際の拾得物を使ったデモを依頼します。似た物件を検索して、何秒で候補を絞れるかも確かめます。

  • 似た物件:色の似た傘や鍵とキーケースの検索
  • 照合情報:財布の同梱物や外国語の問い合わせを使った照合
  • 保管履歴:保管場所を移動した物件の確認

AI画像検索を使う場合は、候補の根拠を人が確認できるかを見ます。あわせて、本人確認や二重承認で誤返還を防げるかも確かめます。

全拠点へ一斉に展開するより、1拠点または1つの問い合わせ窓口で試行するほうが現実的です。期間は2週間から数か月程度を目安にします。

試行の前後では、登録や検索、回答にかかる時間を測ります。返還処理と警察届出の時間、入力漏れの件数も見て、継続導入を判断します。

JR東日本情報システムのJRバス関東向け事例では、16拠点の情報を画像付きで共有し、届出書類の作成を短時間にできたことが導入の決め手と紹介されています(出典:株式会社JR東日本情報システム「MONODOKO」導入事例、2026年確認)。自社でも、同じ指標を試行の前後で確かめます。

ポイント

要件とRFPが固まる前に契約へ進むと、仕様変更や追加の見積もりが重なるおそれがあります。デモと試行で現場の使い勝手を確かめれば、契約前に判断材料をそろえられます。

契約形態と委託範囲の選び方

契約形態は、完成した機能を納品してもらうか、専門人材と一緒に業務やシステムを固めるかで選びます。要件が固まらないまま一括請負にすると、変更のたびに追加の見積もりが生じやすくなります。

  • 要件定義・MVP:準委任契約
  • 仕様確定後の開発:請負契約
  • 稼働後:SaaS利用契約や保守契約

工程ごとに契約を使い分ける方法もあります。その場合も、委託範囲と責任の境界は契約前にそろえておきます。

請負契約の成果物・検収条件・変更手続き

請負契約では、合意した仕様に基づく成果物を完成させて検収します。そのため、検収の判断基準を契約書や仕様書に定めておきます。

  • 成果物・契約条件:納品範囲、検収期間、不具合の定義、修正期限、保守開始日
  • 権利・ライセンス:ソースコードや設計書の帰属、第三者ライセンス
  • 受入条件:必須入力項目、検索条件、帳票出力、権限ごとの操作可否
  • 変更管理:不明点が多いと予備費や厳格な変更手続きにつながるため、業務フローを確認してから本開発へ進む。

請負契約では仕様変更の責任範囲が明確になりやすい一方で、要件が不明確なままだと、見積もりや変更管理に影響します。

要件定義や改善を伴走してもらうときの準委任契約

準委任契約は、専門家へ業務を依頼して、作業時間や役割に応じて報酬を支払う契約です。要件整理や改善を柔軟に進めたい場合に向いています。

  • 向く状況:現場ごとに運用が異なる、警察提出手順が未整理、優先順位が未決定
  • 体制:プロダクトオーナー、現場責任者、開発会社の役割と毎週の意思決定方法
  • 契約内容:作業内容、稼働時間、担当者、会議体、報告書や設計書などの納品物
  • 費用の見方:指定Q&Aでは請負が1.3〜1.5倍高い傾向。条件や責任範囲が異なるため単価だけで決めない。

準委任は、請負と比べて完成責任や成果物の範囲が異なります。そのため、契約時に作業の範囲を明確にしておきます。請負と準委任の費用差も、契約条件と責任範囲によって変わります。

SaaS利用や問い合わせ代行の運用責任

SaaSや問い合わせ代行では、データ管理、問い合わせ受付、返還判断の担当と責任範囲を決めます。

  • 運用責任:受付を代行しても、施設の業務ルールや最終的な返還責任は移らない。
  • 代行範囲:本人確認情報、回答文、対応時間、エスカレーション、配送手配、担当者権限
  • 委託管理:委託先選定、再委託条件、取扱報告、監査、漏えい時の連絡を契約に定める。

個人情報保護委員会のガイドラインは、再委託先への事前報告や承認、定期監査などによる監督を望ましいとしています。

出典は個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(2026年確認)です。

自社の契約書にも、委託先を確認する具体的な方法を書いておきます。

ポイント

要件が固まっているかどうかを基準に、請負と準委任を工程ごとに使い分けます。請負では検収の基準を、準委任では作業の範囲を契約前にそろえておきます。

遺失物管理システムの費用相場と見積内訳

標準SaaSは初期20万〜100万円、月額3万〜20万円程度が目安です。複数拠点、画像、権限を含み、さらに帳票やデータ移行も含むクラウド個別設定は、初期50万〜300万円、月額10万〜50万円程度です。

これらはリサーチノートと公開料金をもとにした幅で、特定の金額を約束するものではありません。実際の金額は、年間拾得数や拠点数、画像容量によって変わり、問い合わせ代行や連携数も影響します。

クラウド型の公開料金と相場の起点

公開料金は、見積もり比較の起点になります。そのうえで、プランに含まれるサービスと、自社の取扱量に合う条件を確かめます。

  • 基本料金:findのスタンダードは月額20万円から、初期利用料は月額の2か月分から(2026年確認)。
  • 従量料金:専用遺失物切符は1枚4円。施設の落とし物取扱量を基に見積もる。
  • 提供内容:ソフト以外の付帯サービスも含まれます。
  • 個別条件:拾得数の少ない1拠点や、代行を自社で行う場合は料金が異なる。最新条件を問い合わせる。

料金には、チャットや登録・検索、LINE問い合わせ代行が含まれます。個社向けの設定や現場向けの勉強会、管理ダッシュボードなども含まれます(出典:株式会社find「落とし物クラウドfind」公式料金ページ、2026年7月確認)。

見積もりでは、月額に含まれるユーザー数や拠点数、画像容量を確認します。サポート時間やデータ出力、追加API利用料も確かめます。ソフト利用料だけで比べないことが大切です。

規模と連携数で変わる個別開発の費用

個別開発の費用と期間は、機能の規模や連携の範囲によって幅があります。そのため、目安は同じ条件で比べます。

  • 小規模:フォームや顧客管理との連携は初期300万〜700万円程度。
  • 多拠点:登録、検索、返還、警察届出、権限、画像、基盤連携は700万〜1,800万円程度。
  • 大規模:横断検索、AI、配送、厳格な監査・セキュリティ、24時間運用は1,800万〜4,000万円以上の可能性。
  • 期間:小規模クラウドは2週間〜2か月、個別設定は1〜4か月、開発は3〜12か月程度。
  • 大規模連携・AI:9〜18か月程度を見込むことがあります。

期間は、要件定義や移行、現場テストを含むかどうかで変わります。教育や並行運用も、期間に影響します。開発期間だけでなく、本番稼働までの工程表で比べます。

見積書で分けて確認する開発費以外のコスト

見積もりでは、開発費以外の費目も分けたうえで、含まれる作業と追加料金の条件を確かめます。

  • 開発・導入:要件定義、UI設計、開発、テスト、管理、移行、教育、マニュアル
  • 運用・設備:画像保存、API、警察帳票、端末・撮影機器、保守、バックアップ、脆弱性診断
  • 追加料金:画像容量、拠点追加、問い合わせ代行、データ出力、解約時の返却
  • 参考費用:人件費は開発費の40〜60%、単価は月60万〜120万円程度。保守は年10〜20%を仮置きする場合がある。

人件費と単価は、一般的な業務システムの参考値です。遺失物管理システムの料金を直接決めるものではなく、工数や体制を確認する材料にします。

保守費は、SLAや監視時間、問い合わせ窓口、改修範囲によって変わります。

ポイント

初期費用や月額だけで比べず、保守や移行、教育、追加料金を含む前提条件をそろえて見ると、見積もりの差の理由がわかります。

RFP・要件整理で外せない機能と運用条件

非機能要件の管理項目として、アクセス制御、データ保護、記録と復旧、退職者対応を4枚のカードで示した図。
権限設定から退職時の処理まで、管理の範囲を一望できます。

要件定義では、画面の見た目より先に業務上の状態遷移を決めておきます。拾得物の状態と、各状態を変更できる役割を明確にします。

  • 受付・保管:登録済み、保管中、照会中の状態を管理する。
  • 返還:返還予定と返還済みを区別する。
  • 処理完了:警察提出済み、廃棄・売却対象を記録する。

状態を管理しておくと、現物を移動したのにシステムの場所が変わらない、返還済みなのに問い合わせ一覧へ残るといった事故を防ぎやすくなります。

登録・検索・返還・警察届出の一連の要件

拾得物の登録項目と問い合わせの情報を対応させておくと、候補を照合できる設計になります。

  • 拾得物:日時、場所、拾得者、カテゴリ、品名、色、メーカー、特徴、同梱物
  • 管理情報:画像、保管場所、担当者
  • 問い合わせ:失った日時・場所・品名・特徴・連絡先
  • 検索:フリーワード、カテゴリ、日付、場所、拠点、画像の有無

表記の揺れや曖昧な表現に対応できる検索も、実務で使いやすくするための条件です。

返還時には、本人確認の方法や日時、受取人を記録します。配送先や送料、受領方法、承認者も残しておきます。

警察提出では、対象物件を抽出して届出書やデータを作成します。提出日と受理情報を管理し、期限はアラートで知らせます。

ナニワ計算センターは、2026年5月の更新で、警察の新しい遺失物システムへの対応と、問い合わせフォーム「FindEntry」を案内しています(出典:株式会社ナニワ計算センター「FindManager」バージョンアップのお知らせ、2026年5月)。その更新対応が自社の運用条件に合うかを確かめます。

非機能要件に含める個人情報・権限・ログ

遺失物管理では、氏名や電話番号、住所などの個人情報を扱う可能性があります。加えて、本人確認情報や問い合わせ履歴、配送先、メールアドレスも含まれることがあります。

  • アクセス制御:役割別の権限と多要素認証を設定する。
  • データ保護:通信時・保存時に暗号化し、管理者権限を絞る。
  • 記録と復旧:操作ログとバックアップを用意し、復旧時間を定める。
  • 退職者対応:退職者のアカウントを速やかに無効化する。

問い合わせ用の画面と施設担当者用の画面を分けたうえで、画像のURLを推測できない設計にします。

個人情報保護委員会の指針は、委託先の安全管理措置や再委託状況の確認、必要に応じた監査を示しています。

IPAは、複数の利用者がいるWebアプリでは、認証に加えて、利用者ごとの操作を許可する認可制御が必要になる場合があると説明しています(出典:IPA「安全なウェブサイトの作り方 1.11 アクセス制御や認可制御の欠落」、2026年確認)。

ログインできるかだけでなく、拠点Aの担当者が拠点Bの個人情報を見られないことも、受入テストで確かめます。

発注範囲に含めるデータ移行・教育・受入テスト

データ移行や教育、並行運用、異常系テストを発注範囲に含めます。そのうえで、担当と確認方法を決めます。

  • 移行:対象データ、変換・検証方法、旧台帳の保管期間
  • 教育:管理者・登録スタッフ向けの説明と問い合わせ先
  • 並行運用:紙台帳とシステムの件数、場所、返還状態
  • 受入テスト:二重登録、場所変更、権限、画像なし、期限通知、警察提出後の返還

紙台帳やExcelの全件移行は必須ではありません。期限切れデータや重複物件、古い問い合わせ履歴の扱いも、あわせて決めます。

画像ファイル名や欠損値も移行ルールに含めます。さらに、データクレンジングを発注側と委託先のどちらが担うかで、費用と納期が変わります。

操作練習は短時間で行い、並行運用中に台帳とシステムの差異を確認します。

ポイント

業務の状態遷移、MUSTとWANTの区分、個人情報と権限の扱いを要件に入れておくと、委託先の提案を同じ前提で比べられます。

委託先の選定と見積比較で失敗しないポイント

委託先は、技術力だけでなく、遺失物業務の理解や法令対応、現場教育、稼働後の保守まで合わせて評価します。

交通や空港、ホテルでは、拾得物の扱いや問い合わせ窓口が違い、保管期限や警察提出の流れも異なります。商業施設や病院、大学も、それぞれ流れが異なります。

自社に近い業種や拠点規模の実績を確かめたうえで、導入前後の変化を聞きます。

件数より業務と運用の近さで見る実績

導入社数やAI搭載の有無だけで実績を判断せず、自社の業務量や運用条件にどれだけ近いかを確かめます。

  • 業務量:年間拾得数、拠点数、現場ユーザー数、問い合わせ件数
  • 運用:画像、警察提出方式、既存連携、稼働後の支援体制
  • 類似経験:複数拠点の物件管理、本人確認や配送を伴う顧客対応
  • 公開事例:findは登録621万453件、返却188万6,963件、導入4,000拠点以上(2026年6月30日時点)。

返還率や対応時間は会社ごとに定義が違うため、公開事例の数字をそのまま比べることはできません。findの数値も、自社と集計条件が同じとは限りません(出典:株式会社find公式サービスページ、2026年6月30日時点)。

発注側は、件数よりも、導入後にどのKPIをどう測ったかを確かめます。

同じ前提と内訳で並べる見積比較

各社には同じRFPを渡し、拠点数や年間拾得数、画像枚数、連携範囲も前提として示します。

  • 開発・設定:標準機能、設定費、追加開発
  • 導入:データ移行、教育、端末
  • 運用:保守、サポート、問い合わせ代行
  • 外部費用:サービス利用料

見積もりの額が安くても、機能や作業が含まれていない場合があります。そのため、合計額よりも前提条件と除外項目を読みます。

ユーザー数や拠点数の追加単価、画像容量、API制限を確認します。さらに、データ出力形式や解約後の返却期間、障害時の復旧目標も確かめます。

稟議の前に、再委託先や海外クラウドのリージョン、見積有効期限を確認します。価格改定条件や最低利用期間、初期設定後の変更料金も、あわせて確かめます。

契約後まで確認するサポート体制とKPI

導入後の支援内容とKPIを決めて、継続的に運用を見直せる契約にします。

  • 業務KPI:登録・検索・回答・返還の時間、返還率、返還までの日数、警察届出時間
  • 品質KPI:期限処理漏れ、誤返還件数、現場スタッフの利用率
  • サポート:平日・休日・夜間の対応、障害と操作質問の窓口、追加研修
  • 変更対応:法令、警察側システム、OS・ブラウザ、AI精度への対応者と改修費負担

返還率だけを追うと、本人確認を急いで安全性が下がる場合があります。そのため、対応速度と誤返還防止を合わせて評価します。

月次のレビューでKPIと問い合わせ内容を見直し、カテゴリや画面を改善できる契約にしておくと、定着が進みやすくなります。

ポイント

委託先は、実績の件数よりも自社の業務量や運用条件に近いかで比べます。見積もりは、同じ前提と内訳をそろえてから並べます。

よくある質問(FAQ)

発注では、費用と導入期間を確認したうえで、クラウドとスクラッチの選び方、法令、個人情報の扱いを整理して、候補会社へ相談します。

遺失物管理システムの開発費用はどのくらいですか?

小規模クラウドは、初期20万〜100万円、月額3万〜20万円程度が目安です。複数拠点や画像、帳票、移行を含む個別設定では、初期50万〜300万円、月額10万〜50万円程度です。

個別開発は300万〜700万円程度からで、多拠点連携やAI、厳格な監査を含むと700万〜4,000万円以上になる可能性があります。

findの公開料金では、スタンダードプランが月額20万円から、初期利用料は月額の2か月分からです。実際の料金は、施設の取扱量などをもとに見積もられます。

クラウドとスクラッチ開発はどちらが向いていますか?

標準的な拾得や検索、返還、警察提出を短期間で始めるなら、専用SaaSやクラウドが向いています。

会員や予約、配車、ホテルPMSなどとの深い連携や独自ルールが必要なら、個別設定やスクラッチを検討します。配送やコールセンターとの連携が必要な場合も、個別設定やスクラッチを検討します。

迷う場合はMUST機能をクラウドで導入し、運用データを見ながら追加開発する段階導入が現実的です。

遺失物管理システムで警察提出や保管期限を管理できますか?

管理機能は製品ごとに異なるため、期限処理と届出の流れは、デモやRFPで確かめます。

  • 施設への届出:警察庁は施設内で拾った物件を施設管理者へ速やかに届けるよう案内しています。
  • 期限:拾得者が施設へ24時間以内に届けない場合、権利を失うことがあります。
  • 警察での保管:届出日から原則3か月間です(出典:警察庁「お店等の施設で落とし物を拾った場合」、2026年確認)。

期限の計算や対象の抽出、提出記録、アラートを実装しても、最終的な判断は施設責任者が行います。

外注先に個人情報を預けるときは何を確認しますか?

委託先と再委託先の会社名やデータの取扱場所、利用目的を確認します。さらに、アクセス担当者や保存期間、削除方法も確かめます。

バックアップやログ、事故時の連絡期限、監査方法も確認します。拠点や役割ごとに権限を分け、一般の利用者が他人の問い合わせ情報や画像を見られないかを試験します。

契約が終わったあとのデータ返却と画像削除を決めておくと、サービスを変えるときのリスクを抑えられます。

まとめ

発注前に、年間拾得数や拠点、問い合わせ窓口を整理します。さらに、警察提出方式や現場端末、画像と個人情報の扱いも押さえておきます。

発注側は、MUST機能と将来の拡張に合う形を、標準SaaSやクラウド個別設定、スクラッチ、ローコードから選びます。

同じ資料での費用・要件・運用の比較

初期費用や月額、保守を分けて見積もります。移行や教育、端末も、項目ごとに確認します。

画像容量やAPIは、追加費用の条件として確認します。問い合わせ代行や警察提出対応、解約後のデータ返却も、見積もりの項目として確認します。

RFPには成果物と受入条件を記載し、請負と準委任は工程に応じて使い分けます。デモでは、類似物件の検索や拠点移動、本人確認を確かめます。期限アラートや権限エラーも見ておきます。

現場で使えるMVPから始める段階導入

まず現場で必要な機能をMVPとして試し、KPIと利用状況を見て、次の開発を決めます。

  • 初期導入:登録、検索、保管場所、返還、警察提出、権限、ログを実装する。
  • 効果測定:登録時間や問い合わせ回答時間などのKPIを測る。
  • 段階拡張:現場の声とデータを基に画像検索、LINE、配送、AI候補提示を追加する。
  • 発注先:技術力に加えて業務整理、教育、保守まで伴走できる体制を求める。

最初からAIや多言語対応をすべて実装せず、機能を段階的に導入すると、予算と定着のリスクを抑えやすくなります。

▼全体ガイドの記事
・遺失物管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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