ロケーション管理システムの開発は、要件整理から定着まで、段階を踏んで進む流れです。
最初から全倉庫・全機器を対象にせず、代表的な1拠点または1ゾーンで入荷から棚卸しまでを通すMVPを設けます。KPIを確認してから拡張すると、現場定着のリスクを抑えやすくなります。
- 要件整理：対象業務と現状の課題、導入効果を測るKPIを定める。
- 選定・設計開発：製品・開発会社の選定と、現場の運用に合わせた設計。
- テスト・定着：稼働前の検証と、現場への展開・改善。
▼全体ガイドの記事
・ロケーション管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ロケーション管理システム開発の全体像
ロケーション管理システムは、保管場所をマスタとして登録し、入荷から出庫、棚卸しまでの履歴を、その場所とひも付けて残す仕組みです。
後から差異の原因を追える運用にするには、棚番と一緒に、商品コードやロット、使用期限を記録しておきます。荷姿や在庫状態、作業者、処理時刻も同じ一つの記録として残すと、差異が出た時点を後からたどれます。
倉庫内のロケーション管理と屋外の位置情報管理の切り分け
ロケーション管理システムの中心は、倉庫や工場の棚番を管理するWMS型です。倉庫からフロア、ゾーン、列、段までの階層をロケーションマスタに登録し、商品や資材の置き場所をバーコードやQRコードで記録します。
固定ロケーションなら商品ごとに定位置を決め、フリーロケーションなら空き容量や品目属性に応じて格納場所を変えます。その判断には、温度帯や先入先出などのルールも使います。一方、車両や作業員、保守員、設備の現在地や移動履歴を追う場合は、位置情報システムとして設計します。
位置情報には、GPS、BLEビーコン、UWB、スマートフォンなどを使います。GPSは屋内で精度が落ちやすいため、倉庫内の棚番管理をGPSだけで行うと、期待した効果が出にくくなります。対象が在庫の所在か、人・車両・設備の現在地かは、要件定義の最初に文書で明確にします。
最初に押さえる基本機能と連携範囲
倉庫向けに最低限確認したい機能は、ロケーションマスタと商品・資材マスタです。そのうえで、入荷、検品、格納から出庫、ピッキング、移動、棚卸しまでの作業機能を見ます。在庫照会や在庫引当、入出庫履歴もそろっているかを確認します。
ロット・期限や荷姿まで扱うなら、予約在庫や返品、滞留在庫も対象になり、現場の例外処理を含めて画面とデータの動きを確認します。誤格納や誤出荷の防止には、現品コードと棚番を続けて読み取る操作が有効です。ただし、紙の一覧を画面に置き換えるだけでは、防止にはつながりません。
販売管理やERP、EC、会計などと連携するなら、APIかCSVで入出力し、エラー通知や再送、重複排除、データの正とするシステムを決めます。ロケーションコードや商品コード、単位などの定義が拠点ごとに違ったまま連携を始めると、稼働後に在庫差異が発生します。開発範囲を抑えるには、連携対象を「必須」「将来対応」「今回は対象外」に分けます。
ロケーション管理システムの進め方と6フェーズ
要件整理から定着まで6フェーズに区切って進めると、抜け漏れを段階ごとに把握しやすくなります。
最初のMVPは、代表的な1拠点または1ゾーンで入荷から棚卸しまでを通す範囲です。その結果をもとに、次の拠点や範囲へ広げます。
フェーズ1：現場の事実をそろえる要件整理
最初に、倉庫レイアウトや拠点数、品目数、入出庫量を調べます。さらに、作業者数や温度帯、通信環境、既存のバーコードや棚番も把握します。ヒアリングだけでなく、入荷から棚卸しまでの作業を実際に歩いて観察し、例外処理まで記録します。
「返品時は仮置き場に置く」「期限切れは別棚へ移す」「同一商品でも荷姿が違う」といったルールは、会議室の要件表から抜けやすく、重要な確認事項です。要件定義書には、業務フローに加えて、固定かフリーか、先入先出の判定単位、ロット・期限の必須項目を書きます。さらに、引当・予約在庫の扱い、オフライン時の代替手順、権限、監査ログ、バックアップ、障害時の切り戻しも記載します。
成果指標は、「便利になる」ではなく、棚卸し時間やピッキング時間、誤出荷率などの導入前に測れる数値にします。教育期間や1時間当たりの処理件数も、同じ考え方で数値にします。
フェーズ2：同じ条件での製品・開発会社の選定
製品の種類には優劣をつけず、自社の業務差分と将来の拡張性で比べます。標準業務に合わせられ、早く小さく始めたいならSaaSが候補です。入出庫やロット、棚卸しの実績を使い、設定と少量のアドオンで済ませたいならWMSが合います。
独自の保管ルールや特殊端末、複雑な基幹連携が競争力に直結するならスクラッチが選択肢になります。在庫の中核は既製品にして、作業アプリや分析だけを別に開発するならハイブリッドが現実的です。候補会社には、同じRFPを渡して、同じ業務シナリオで回答してもらいます。
確認項目は、同業種・同規模・同じ温度帯での実績、ハンディやスマートフォンの操作性、電波が弱い場所での動作です。さらに、基幹・EC・配送とのAPI/CSVやマスタ移行、教育の内容を確かめます。契約後の運用に関わる条件は、支援の範囲とデータ・成果物の扱いに分けて比べます。
- サポート時間：問い合わせに対応する時間帯
- 障害時の復旧：障害が起きたときに、復旧をどこまで誰が担うか
- データ返却：契約を終えたときに、データを受け取れるか
- ソースコードや設定情報の引き渡し：別の会社に保守を頼む場合の前提
価格に加えて、標準機能に業務を合わせる範囲と、追加開発を残す範囲を比較表にして判断します。
フェーズ3：データと現場操作を固める設計開発
設計では、まずロケーションコードの体系を決めます。たとえば、倉庫・ゾーン・通路・棚・段を一意に表せる形式にし、現場で読み上げやすく、ラベルに印刷しやすい長さにします。商品コードや単位、荷姿も、同じ考え方で定義します。そのうえで、在庫に付く属性も決めておきます。
- ロット：ロット単位で在庫を追うかどうか
- 期限：期限切れの在庫を別棚へ移すなどの扱い
- 在庫状態：引当や仮置きなど、在庫の状況の区分
画面では、手袋をしたまま操作できるボタンの大きさや片手操作を確認します。読み取り後の音や色による知らせ方、誤読時の戻し方も確かめます。冷凍庫や粉じんの多い工場、屋外、通信が不安定な場所では、端末の耐環境性、オフライン保存、再接続時の同期、電池切れ時の代替手順も仕様に含めます。
マスタを誰が登録、承認、変更するかが決まっていないと、システムが完成しても、現場ごとに別々のコードが増えます。連携設計では、どのシステムを正とするか、処理の失敗を誰に通知するかを決めます。再送しても二重計上しない仕組みも必要です。
フェーズ4：通常処理と例外処理を通すテスト
テストは画面単位の確認だけでは不十分です。代表的な商品を使い、入荷予定の取り込みから基幹への実績返却までを一つのシナリオで通します。そのなかで、検品から棚卸しまでの各作業を確かめます。例外として、数量違い、商品違い、棚番違い、同一商品の複数ロケーションも想定します。ロット・期限切れ、返品、欠品、通信断、端末故障、途中キャンセルも、業務を止めずに復旧できるかを確かめます。
データ移行テストでは、現行のExcelや紙の一覧をそのまま取り込まず、重複商品や表記揺れ、単位違い、存在しない棚番、在庫数が未確定の行を洗い出します。移行前後で総在庫数、ロケーション別在庫、ロット別在庫を照合し、差異が出た場合の承認者を決めます。
受入テストは、情報システム部門だけでなく、入荷、保管、出荷、棚卸しの現場担当者が行います。「3回連続で迷わず処理できる」などの合格基準を現場と決めておくと、稼働後の混乱を減らせます。
フェーズ5：稼働日の在庫確定と切り戻しの管理
稼働前には、初期在庫とロケーションを確定させます。そのうえで、ラベルを貼り、端末や無線LANを現場で確かめます。教育は一度の説明会で終わらせず、入荷、格納、出荷の担当者と管理者が、実際の端末で短い練習をします。
稼働初日は、ベンダーと社内の責任者を現場に置きます。問合せの受付方法や優先順位、障害時の紙運用、復旧後の再入力手順も、事前に決めておきます。旧運用を並行して残す期間は、長すぎると二重入力が常態化し、短すぎると現場の不安が増えます。
並行稼働は対象業務と期間を限定し、毎日の処理件数、在庫差異、エラー、未解決の問い合わせを確認します。重大な不具合に備えて、旧運用へ戻す条件と責任者、データを戻す時点を事前に決めておきます。これが、納期を守るための安全策になります。
フェーズ6：KPIと改善サイクルによる定着化
稼働後は、利用率に加えて、棚卸し時間、ピッキング時間、誤出荷率、在庫差異率を導入前と比べます。保管スペースや教育期間、入出庫処理件数も同じように比べ、改善した業務と悪化した業務を分けて見ます。
たとえば、棚卸し時間が短くなっても、例外処理が増えて出荷が遅れていれば、画面やルールを見直す必要があります。体制は、週次の立ち上げ確認から月次のKPIレビューへ移し、改善要望の受付窓口も残します。RFID、自動最適配置、ビーコン、フォークリフト端末などの高度な機能は、バーコード運用で現場データが安定してから追加します。
現場が紙や個人管理へ戻るのは、操作が遅い、電波が弱い、例外処理ができない、入力しても業務上のメリットが見えないといった実装上の問題が原因です。改善の優先順位は、利用者の声とKPIを照らし合わせて決めます。機能の追加より、コード体系や端末、教育、マスタ管理の修正を優先する場合もあります。
ロケーション管理システムの費用相場とコストの内訳
費用は、SaaSの標準利用か、WMSの導入支援・連携か、独自開発かで大きく変わります。公的な平均価格がある領域ではないため、ここに挙げる金額は、公開料金と業務システム開発の一般的なレンジを組み合わせた企画段階の目安です。
総額は、拠点数や品目数、端末台数によって変わります。ハードウェアやデータ移行、API連携、電波調査、教育、保守を含むかどうかでも、差が出ます。そのため、固定の価格とは考えず、同じ条件で見積もりを比べます。
方式別の初期費用と導入期間の目安
SaaSの標準利用なら、初期費用が0万〜60万円程度、月額が0.9万〜15万円以上、導入は即日から1か月程度が一つの目安です。株式会社ZAICOの公式料金ページでは、2026年6月開始のプランとして、スターター月額8,980円、ベーシック月額49,800円、プロフェッショナル月額150,000円以上が税別で示されています。
SaaS以外の方式は、含む範囲の広さで金額と期間が変わります。拠点の数と連携の範囲で、規模の目安を分けて見ます。
- 1拠点の小規模カスタム：商品・棚マスタ、入出庫、スマートフォンまたはハンディ、CSV連携を作る場合で、100万〜300万円程度、期間1〜3か月程度です。
- 中規模WMS：複数拠点や販売管理・ERPとのAPI連携を含み、300万〜1,000万円程度、3〜9か月程度を見込むケースがあります。
- 大規模構成：複数倉庫やRFID・ビーコン、フォークリフト端末を含み、1,000万〜3,000万円以上、6〜18か月以上になる可能性があります。
中規模WMSの金額と期間は、フリーロケーション、ロット・期限、検品の範囲で変わります。大規模構成の金額と期間が伸びるのは、冗長化、監査ログ、複雑な基幹連携まで含む場合です。
QR・バーコード、棚卸し、ロット・期限、外部連携などの機能やユーザー追加で条件が変わるため、公開料金と初期設定・移行費用を分けて確認します（出典: 株式会社ZAICO「料金プラン」、2026年）。
小規模カスタムの金額は類似する業務システムの相場からの目安で、中規模以上の金額は、業務システムの一般的なレンジと公開機能からの推定です（出典: NotebookLM Q&A「業務システム全般_18」、2026年）。
人件費・機器費・連携費・運用費の切り分け
開発費の中心は工数で、次の作業が対象です。
- 要件定義：PMや業務担当を含む工程
- 設計：UI・データ・連携を含む工程
- 実装：設計をもとに作る工程
- テスト：通常処理と例外処理を確かめる工程
- 移行・教育：データの移行と現場への教育
NotebookLM Q&Aでは、技術者単価を50万〜200万円／人月程度、保守費を初期費用の年15〜25％程度とする一般的な目安が示されています。ただし、会社や役割、難易度、契約形態によって変わります。
要件定義を削って安く見せると、後の仕様変更や追加開発で、初期見積もりの1.3〜1.5倍程度に膨らむ可能性があります。そのため、前提条件と変更管理の方法を契約に明記します。
見落としやすいのは、RFIDリーダーやタグ、フォーク端末、無線LANです。さらに、ラベル発行機や現場用スマートフォンも、費用に入っているかを確かめます。電波調査と端末の保守は、運用費に含まれるかを見ます。
クラウドWMSのロジザードZEROでも、公式ページは初期費用をソフトウェアライセンス、導入支援、オプションに、月額費用をソフトウェア利用料、サポート、オプションに分けて示しています。同社は、標準機能で導入できる利用者が約7割とも説明しています。ただし、基幹連携や開発は別見積もりとされています（出典: ロジザード株式会社「ロジザードZERO 利用料について」、2026年閲覧）。
見積もりを取る際のポイント
見積もりの精度は、発注側が業務とデータをどこまで具体化できているかで変わります。詳細な仕様を最初からすべて決める必要はありません。ただし、次の項目はそろえておきます。
- 対象拠点・対象業務：見積もりの範囲を決める材料
- 現場端末：端末の台数によって総額が変わる
- 連携先：販売管理やERPなど、つなぐ先をすべて
- 移行データ：サンプルを渡し、重複や欠落を確かめる
- 希望時期・成功指標：稼働の時期と、導入前に測れる数値
そろえた前提があると、提案会社は同じ条件で計算できます。
見積書は、合計額だけでなく、何が含まれ、何が別途なのかを確認することが重要です。
RFPに載せる業務量・端末・例外処理の情報
RFPや依頼書には、拠点数や倉庫の面積、レイアウト、棚・ロケーション数を記載します。加えて、商品・資材の種類と月間の入出庫行数、ピーク時の処理量も書きます。現場の条件も、見積もりの前提に含めます。
- 作業者数：端末台数や教育の規模を見積もる材料
- 温度帯：端末の耐環境性に関わる保管条件
- 通信状況：電波が弱い場所や、通信が不安定な場所の有無
- 既存端末：今ある端末を使うかどうか
- ラベルの種類：ラベル発行機で印刷する形式
固定かフリーか、同一商品を複数場所に置くか、ロット・期限を扱うかを明らかにします。さらに、先入先出の判定単位や、返品・仮置きの扱いも決めておきます。連携先は、販売管理やERPなど、つなぐ先をすべて挙げます。
連携では、入荷予定や出荷指示、在庫数、出荷実績、エラー情報について、項目と頻度を整理します。移行データはサンプルを渡し、商品コードの重複や棚番の未登録、単位の換算、ロット・期限の欠落を確認してもらいます。実際の画面で「入荷から棚卸しまで」を試すPoCを依頼すると、カタログでは見えにくい操作時間や例外処理の差が比べられます。
複数社の見積もりを同じ分類で比べる方法
比較表の分類は、要件定義や基本設計、画面・API開発、端末対応、テストで分けます。さらに、データ移行や教育、稼働支援も分類に入れます。開発以外の費用も、同じ表に並べて比べます。
- 保守：稼働後の保守契約にかかる費用
- ライセンス：ソフトウェアの利用権にかかる費用
- 機器：ハンディ端末やラベル発行機などの費用
- クラウド利用料：月額で続く利用の費用
各社で「導入支援」「初期設定」「連携対応」の呼び方が違うため、作業内容と成果物まで照合します。
特にAPI連携は、「標準コネクタ」か「個別開発」かを確認します。CSVの手作業が残るのか、エラー時に誰が再送するのかも確かめます。ベンダー選定では、最安の提案より、標準機能に合わせる業務と独自開発する業務の線引きが合理的かを見ます。
ロジザードZEROのように、標準機能と標準料金を前提に、必要な開発だけを個別見積もりにするサービスもあります。製品を変える際に備えて、データ返却や契約終了時の移行支援、バージョンアップ時の費用、脆弱性対応の責任範囲も、初期見積もりと同じタイミングで確認します。
個人情報・物流標準・セキュリティの見積もりへの組み込み
作業員のIDや位置履歴、入退場時刻を保存するなら、利用目的から退職者データの扱いまで、先に決めておきます。
- 利用目的：収集した情報を何に使うか
- 閲覧権限：誰がどこまで見られるか
- 保存期間：データを残す期間
- 第三者提供：社外へ渡す場合の扱い
- 退職者データの扱い：退職後のデータをどう扱うか
位置情報を人事評価へ無制限に使うと現場の理解を得にくいため、車両や設備の位置管理と、個人にひも付く作業履歴はデータを分けます。そのうえで、必要最小限の権限と監査ログを設計します。法務や労務上の判断が必要な場合は、個人情報保護委員会の資料も確認したうえで専門家へ相談します。
物流会社や荷主、運送会社とデータ連携する予定があるなら、国土交通省が2025年2月7日に公開した「物流情報標準ガイドライン」ver3.00を確認します。同改訂では、物流サービス提供者が参画する標準プロセスや、運送事業者から荷主企業へのCO2排出量報告への対応などが示されています。
すべてを採用する必要はありませんが、将来連携したいデータ項目を個社専用の形式だけで固定しないことが、再開発の抑制につながります（出典: 国土交通省「物流情報標準ガイドラインをver3.00に改訂」、2025年）。
クラウド、端末、API、現場ネットワークを含むため、認証や最小権限、暗号化は要件に含めます。さらに、バックアップや脆弱性対応は、要件として明記します。ログ監視と障害連絡も、誰が何を担当するかを含めて要件に入れます。
IPAは2026年3月27日に「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開し、経営者が実行すべき重要な取り組みを整理しています（出典: IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」、2026年）。誰がアカウントを発行し、バックアップを復元し、端末紛失時に停止するかを発注側が決めておくと、見積もりを実際に使える形になります。
よくある質問（FAQ）
導入前には、在庫管理との違いや、GPSの使いどころ、Excelからの移行、1拠点からの開始、作業員の位置情報の扱いについて、特に質問が多く寄せられます。
回答は自社の業務やデータの扱いで変わるため、そのまま採用せず、要件定義書やPoCの確認項目に置き換えて使ってください。
ロケーション管理と在庫管理は何が違いますか？
在庫管理は、商品や資材の数量、金額、状態、入出庫を管理する考え方です。一方、ロケーション管理は、その在庫がどの場所にあるかを正確に管理する考え方です。
実務では両方を一体で使うことが多いです。場所だけを管理しても、数量が更新されなければ、探す問題は解消しません。要件定義では、「場所の検索」だけか、検品から棚卸しまで含むWMSかを分けて記載します。
GPSは倉庫内の棚番管理に使えますか？
GPSは屋外の車両や作業員の位置管理には使いやすい一方、建物内では衛星信号が弱く、棚単位の精度を安定して得にくいです。
倉庫内の棚番管理では、バーコードやQRコードを基本にします。読み取りを自動化したい場所に限り、RFID、BLE、UWBをPoCで比べます。必要な精度と対象エリアを先に決め、技術名から選ばないことが大切です。
Excelからロケーション管理システムへ移行できますか？
移行はできますが、Excelの列はそのまま取り込まず、整理してから移します。商品コードや単位、ロット・期限の重複や表記揺れを直します。棚番と在庫数も、重複や表記揺れを含めて直し、現物と移行データを照合してから初期在庫を確定します。
zaicoの公式ページでも、Excelや紙で管理していた在庫データの初期インポート代行が案内されています。自社で行う場合は、移行前のバックアップや検証環境での取り込み、差異の承認、稼働後の追加登録ルールを決めます。
1拠点だけでも導入する価値はありますか？
導入する価値はあります。むしろ、1拠点・1ゾーンで入荷から棚卸しまでを試すと、ロケーションコードや端末、通信、教育、例外処理の課題を小さく見つけられます。
ただし、将来の複数拠点展開を考えるなら、拠点コードや商品マスタの共通化、権限、APIの拡張余地を初期設計の段階で確かめておきます。小さく始めることと、使い捨ての仕組みにすることは別の話です。
作業員の位置情報はどのように管理すべきですか？
収集目的や対象時間、閲覧者、保存期間、本人への説明、第三者提供の有無を明確にしておき、業務に必要な範囲だけを取得します。
現在地を常に記録する場合と、作業完了時の実績だけを記録する場合では、従業員への影響が異なります。そのため、同じ仕組みにまとめず、権限や画面を分ける方法もあります。
評価や懲戒に使う場合は、導入前に法務・労務担当と確認し、目的外利用を防ぐルールとログを用意します。
まとめ
ロケーション管理システム開発は、機能一覧を並べる前に、現場の課題を観察して測定可能なKPIへ変換することから始まります。課題の例は、「どこに何があるか分からない」「探す時間が長い」「棚卸しで差異が出る」「誤出荷が減らない」です。
倉庫内の棚番・在庫管理と、車両・作業員・設備の位置管理を分けます。そのうえで、必要な精度に合わせて、バーコードやQR、RFID、BLE、UWB、GPSから選びます。
6フェーズによる無理のない進め方
進行は、要件整理から定着まで段階ごとに区切ります。要件整理ではマスタと例外処理を、選定では同じRFPとPoCを確かめます。
設計開発では現場操作と連携、テストでは通常処理と障害時の復旧を見ます。稼働では在庫確定と切り戻し、定着ではKPIと改善窓口を確認します。
全社一斉の導入にこだわらず、1拠点・1ゾーンでMVPを実施して、結果を見ながら広げるのが現実的です。
見積もりの総額より前提条件の確認
費用は、標準SaaS、小規模カスタム、中規模WMS・API連携、大規模なリアルタイム構成で幅があります。公開料金と個別見積もりは、分けて見ます。
初期開発だけでなく、端末やタグ、電波も含めて、各社の見積もりを同じ分類で比べてください。分類に加えるのは次の項目です。
- データ移行：現行データの整理と照合
- 教育：現場での操作練習を含む
- 保守：稼働後の対応にかかる費用
- 連携：販売管理やERPなどとのAPI・CSV連携
- セキュリティ：認証や暗号化、監査ログへの対応
契約前に、データ返却やバージョンアップ、障害対応、個人にひも付く位置情報の扱いまで確認しておくと、導入後の想定外の負担を抑えられます。
導入した時点は、完成ではありません。棚卸し時間、ピッキング時間、誤出荷率、在庫差異率、保管密度、教育期間などを継続的に測り、現場が使い続けられる操作とルールへ改善していくことで、投資効果を確認できます。
▼全体ガイドの記事
・ロケーション管理システム開発の完全ガイド
▼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を創業。