卸売・商社向け在庫管理システムの開発は、業務とデータの整理、方式の選定、設計・開発、テストの順に進み、稼働と定着まで続けます。
そこまで進めると、取引全体の在庫と採算を追跡できます。業態ごとの要件と各フェーズで決めることを押さえておくと、打ち合わせの論点をそろえやすくなります。
▼全体ガイドの記事
・卸売・商社向け在庫管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
卸売・商社向け在庫管理システムの全体像
卸売・商社向け在庫管理システムは、共通マスタを使って倉庫の在庫から注文・調達・物流・売上・請求までをつなぐ業務基盤です。
商品、取引先、仕入先、倉庫、ロケーションは、この共通マスタで管理します。
倉庫作業だけを効率化しても、営業の納期確認や購買の発注残が改善されないことがあります。そこで、業態ごとの違いを最初に整理します。
卸売型の在庫・期限・拠点の管理
卸売業では、仕入れた商品を自社倉庫や外部倉庫に保管し、注文に応じて引き当てて出荷します。
現在庫だけでなく、受注残、発注残、拠点間の移動中数量も分けて管理します。
在庫数だけでは、別の受注に引き当て済みの商品も在庫として見えることがあります。そのため、選定の際には、受注残と発注残を反映した「予定フリー在庫」を表示できるかを確認します。
商品の特性によって、必要な管理要件は変わります。卸売業の業態ごとに、管理の重点がどこにあるかを見ておきます。
- 食品卸：賞味期限や許容日の管理
- 医療機器卸：ロット管理、預託在庫、短期貸出
- 金属・電子部品卸：多品種の扱い、長期滞留、重量・荷姿の換算
NECソリューションイノベータの食品卸事例では、2拠点、約13,000品目、月35万出荷明細を扱い、期限管理と無線ハンディを組み合わせています（出典：NECソリューションイノベータ「食品卸ULTRAFIX/WMS導入事例」）。
商品点数や出荷明細が増えるほど、スキャンと検品、通信障害時の運用を確認しておく必要があります。
商社型の在庫を持たない取引と採算の管理
商社では、直送や受発注同時の取引、輸出入や外為をともなう取引が少なくありません。
在庫だけを管理すると、入荷予定や納期回答が見えず、案件別の粗利も販売単価と仕入単価から把握できないままになります。
商社型では、取引をどこまで追えるかと、会計や物流とどこまで連携するかを確認します。
- 取引追跡：受注・発注・仕入・売上を、案件番号か伝票番号で追跡できるか
- 連携評価：在庫画面だけでなく、取引形態と会計・物流との接続まで
SCSKは2025年にPROACTIVEテンプレートを発表しています（出典：SCSK株式会社「商社・卸売業向けテンプレート」2025年）。その対応内容には、受発注同時と売買同時計上が含まれます。
さらに、輸出入・外為も含まれます。また、EDI・EC・WMS・物流会社APIとの連携も対象です。
導入前に決める成果指標（在庫差異率と業務時間）
導入目的を「最新システムにする」とだけ置くと、機能が増えても成果を測れません。そこで、開始前に棚卸時間や在庫差異の件数を測っておきます。
さらに、欠品や誤出荷の件数、受注入力や納期確認にかかる時間も測ります。導入後は、在庫と業務の成果を複数の視点から月次で比べます。
- 在庫精度：在庫差異率と棚卸時間
- 出荷品質：欠品率と誤出荷率
- 在庫効率：在庫回転率と滞留在庫金額
- 業務時間：受注入力にかかる時間
目標は、利用者の行動が変わる形まで具体的に書きます。たとえば、営業が倉庫に確認する回数を減らす、月末の棚卸を一日で終える、受注残と発注残を同じ画面で確認する、といった形です。
指標の定義・集計対象・基準期間・目標値・責任者を要件定義書に書いておくと、稼働後に改善を進めやすくなります。
卸売・商社向け在庫管理システムの進め方
卸売・商社向け在庫管理システムは、6つのフェーズで進みます。
現物、データ、取引を整理し、標準化する業務と残す業務を決めてから方式を選ぶと、手戻りを抑えられます。
画面の設計に入る前に業務を整理し、各フェーズの完了条件も決めておきます。
- 要件整理
- 製品・開発会社の選定
- 設計・開発
- テスト
- 稼働
- 定着
フェーズ1：要件整理による業務とデータの現状把握
営業・購買・倉庫・物流の現場と、経理、情報システム、管理職から話を聞きます。
各部門では、注文から請求までの流れと担当者を記録します。
入力項目や判断条件、例外処理、Excelや紙帳票も記録します。
- 通常処理：受注・引当・発注・入荷検品・出荷・売上・仕入・請求を時系列で整理する
- 例外処理：分納・返品・欠品・直送・預託・無償サンプル・キャンセル・拠点間移動の流れ
商品の基本情報として、商品コード・商品名・規格を洗い出します。単位・荷姿・JAN・バーコードも、あわせて洗い出します。
ロットや期限、仕入先・販売先も、棚卸の対象です。倉庫・ロケーション、単価・税区分も棚卸します。
「1箱24個」「1ケース10箱」の単位換算や同一商品の複数コードは、在庫差異や誤出荷の原因になります。
発注側と開発会社は、現物、Excel、旧システムからデータを抽出し、重複や未使用コード、表記ゆれ、欠損値がないかを確認します。
要件はMust、Should、Couldに分けて、業務継続に欠かせない機能か、効果の大きい機能か、後から追加できる機能かを区別します。
Mustは受注・発注・入出荷・棚卸・権限、Shouldは予定フリー在庫・EDI・ハンディ、Couldは高度な需要予測や特殊帳票です。
業務フローとデータ項目について関係者の承認が得られたら、要件整理を完了します。承認の対象には、例外処理や非機能要件、優先順位、受入条件も含めます。
フェーズ2：選定での機能適合度と5年総額の比較
まず標準機能を確認し、不足する部分だけを追加するのが基本です。方式によって、導入速度・業務適合・調整範囲・発注者の責任は異なります。
- クラウドSaaS：短期導入や拠点共有に向く
- 業界パッケージ：卸売の販売・購買・在庫を一つにまとめやすい
- セミオーダー・ERP：複数拠点、複数会社、会計連携の調整がしやすい
- フルスクラッチ：自由度が高い一方、要件定義・テスト・保守・人材確保の責任が広がる
候補会社には、自社の実データを使い、同じシナリオでデモやPoCを依頼します。
商品の単位やロット・期限、受注から返品までの流れが、確認の中心になります。さらに、直送や預託、輸出入・外為、拠点間移動の取引に加えて、ハンディやEDI・API、会計・請求との連携も確かめます。
「対応可能」という説明が出てきたら、実際に操作して確かめます。特に、受注から出荷までの操作数や入力ミスの防止、通信断時の処理、履歴の追跡を見ておきます。
契約前には、月額料金と開発費に加えて、5年総額を比べます。5年総額には、初期設定、マスタ整備、データ移行を含めます。
さらに、外部連携、ハンディ、帳票も含めます。教育、並行稼働、保守、追加改修も、同じ総額に入れて比べます。
データの所有者とAPIの利用条件、データの書き出しを確認します。また、障害時の復旧目標や解約時の返却、設計書とソースコードの帰属も、契約前に確かめます。
フェーズ3：設計・開発での標準業務と例外処理の具体化
設計では、受注、倉庫、商社取引の要点を画面やデータの形に落とし込みます。
- 受注画面：販売先別価格・与信・引当・分納・直送・納期回答・取消の扱い
- 倉庫業務：入荷・検品・ピッキング・出荷・返品の流れ
- 商社取引：案件番号・計上時点・外為・関税・粗利の定義
帳票・権限・連携・バッチ・ログの設計も、同じ段階で具体化します。
受注画面に納品条件を反映します。
倉庫では、数量差異や破損、ロット・期限、ロケーション移動の扱いも定めます。
商社取引では、伝票同士をどう結ぶかと、計上の時点を明確にしておきます。
- 伝票設計：受注と発注を別伝票にするか、案件番号で結ぶかの判断
- 計上設計：在庫を持たない取引の売上・仕入の計上時点
- 輸出入：為替や関税を含めた粗利の確定時点
輸出入では、通貨、船積み、入荷予定、費用配賦を経理と確認します。状態の移り変わりが曖昧だと、納期や採算の数字が部門ごとに異なるためです。
毎週の進捗会議では、課題・決定事項・未決事項・変更要求を管理します。
現場の代表には、画面のレビューに加えて、コードスキャン・入荷検品・棚卸・返品処理を実際に体験してもらいます。
標準機能に業務を合わせる場合は、その理由と現場の利点を説明します。一方で、カスタマイズする場合は、将来の保守費やバージョンアップへの影響を記録します。
フェーズ4：テストでの取引のつながりとデータの検証
卸売・商社のテストでは、正常な取引の流れと例外処理を確認します。工程は、まず機能ごとの単体テストを行い、次に機能どうしをつなぐ結合テスト、実業務に近い流れで確かめる総合テスト、最後に利用者が受入条件を確かめる受入テストの順です。
- 正常系：受注・引当・発注・入荷・検品・出荷・売上・仕入・請求の流れ
- 例外系：欠品・分納・返品・直送・受注取消・納期遅延・単位換算・ロット期限切れの扱い
検証で使う商品は、種類を幅広く選びます。データ移行後の照合も、あわせて行います。
- 商品データ：対象は類似品・セット品・複数単位・休眠商品・価格改定品・期限の近い商品
- 移行照合：旧システムとの照合項目は、商品コード・名称・単位・在庫数量・評価単価・取引先・受注残・発注残合計
移行リハーサルは少なくとも一度行い、差異が出た場合に備えて、修正の責任者と締切を決めておきます。
非機能テストでは、月間の出荷明細や同時利用者数を前提に、性能を確認します。加えて、バックアップからの復元・障害時の連絡・権限の逸脱・操作ログ・APIエラー・ハンディの通信断も確かめます。
受入条件は、合否を判定できる文で書きます。たとえば、受注残と発注残の表示、棚卸差異の承認、取引履歴の追跡などで合否を確認します。
フェーズ5：段階導入と並行運用による稼働
切り替えを一斉に行うか、代表拠点や特定の商品群から段階的に導入するかは、取引量と業務の複雑さで決めます。
初回は受注・発注・入出荷・棚卸に絞り、販売管理・会計・EDI・外部倉庫連携は後続にする方法もあります。
月末締めや法定帳票を後回しにすると二重入力が長引くため、締め処理の境界は先に決めておきます。
稼働の前に、切り替えに必要な日程と未処理業務を固めます。
- 切替計画：マスタ凍結日・最終棚卸・未処理受注・発注残・入荷予定・返品・請求締め・旧システムの参照期間の決定
- 緊急対応：紙の指示・連絡先・手入力様式・復旧判断者の準備
旧システムは、すぐに消去せず、一定期間は参照専用で残します。
稼働直後は、問い合わせ窓口を一本化したうえで、問い合わせを操作ミス・マスタ不備・仕様差異・システム障害に分けて記録します。
在庫差異・受注残・出荷遅延・連携エラーを日次で確認し、改善課題は週次で更新します。
稼働の判断は、旧手順に戻らずに業務を回せて、必要なKPIを測れる状態になってから行います。
フェーズ6：教育とKPI改善による定着
役割ごとに、短い教材を用意します。営業には在庫・納期・受注残、購買には発注点と納期回答、倉庫にはスキャン・検品・棚卸、経理には売上・仕入・請求の連携を教えます。
新入社員や応援要員が使えるように、画面の操作だけでなく、例外処理と問い合わせ先も残しておきます。
導入後の教育と改善は、時期ごとに見る指標を変えながら進めます。
- 1か月目：操作とデータの誤りの減少
- 3か月目：在庫差異と入力時間の確認
- 6か月目：欠品率・在庫回転率・滞留在庫金額の見直し
利用率が低い部門では、入力項目や通信環境、マスタ登録の責任者、旧Excelと比べた使いやすさを調べます。原因は利用者だけに求めず、調べた結果を原因ごとに分けて、改善を進めます。
AI需要予測やAI-OCRは、商品コード・取引日・数量・単位をそろえてから、段階的に導入します。入力ルールが不統一なままだと、誤った予測や読取結果の確認が増える可能性があります。
まずバーコード・マスタ・権限・履歴・棚卸を安定させ、その後に予測や自動化へ進みます。
卸売・商社向け在庫管理システムの費用相場とコスト内訳
費用は、利用者数、商品点数、拠点数によって変わります。さらに、月間明細、ロット、期限の扱いも費用を左右します。
ハンディ台数、EDIとAPIの本数、会計連携も、費用に影響します。また、移行、教育、非機能要件も費用の要因になります。
示す金額は、在庫・購買・受発注システムの一般的な目安を卸売・商社向けに読み替えたレンジです。公的な平均価格や、個別案件の確定額ではありません。
見積もりは、方式ごとに初期費用と運用費を分けて確認します。
方式別の初期費用の幅（SaaSから数億円規模まで）
クラウドSaaSは、設定と初期データの移行を含めて、初期費用0〜50万円程度から始められる場合があります。
たとえば、ZAICOの公開料金は2026年6月以降の料金です（出典：株式会社ZAICO「在庫管理システム zaico 機能一覧」2026年）。税別の月額は、スターター8,980円、ベーシック49,800円、プロフェッショナル15万円以上です。
ZAICOの公開料金は、ライセンスの実例で、卸売向け受発注・会計・EDI・ハンディ・移行・教育を含む導入総額ではありません。
- 業界パッケージ：初期費用100万〜1,000万円程度、期間3〜6か月程度
- セミオーダー・ERP：500万〜8,000万円程度、期間6か月〜2年程度
- フルスクラッチ：1,000万〜数億円。中〜大規模では5,000万〜3億円以上の目安もある
業界パッケージは、標準機能が合えば費用と期間を抑えられます。一方で、単位換算や取引先別の帳票、直送、複数会社、EDIを追加すると、費用が上振れします。
セミオーダー・ERPとスクラッチの金額は、要件、工数、連携数からの推定で、確定額を保証するものではありません。複数拠点、基幹刷新、外部倉庫・物流連携、厳格な性能・監査要件があると、費用は高くなります。
1拠点で標準的な入出庫と棚卸から始め、会計や受発注の連携は後から追加すれば、初期範囲を絞れる可能性があります。そのため、金額だけでなく初期範囲も確認します。
見積もりの内訳（要件定義から移行・教育まで）
開発費は、要件定義から移行・導入まで、工程ごとに分けて提示してもらいます。
類似業務システムでは、工程ごとの費用の割合に目安があります。
- 要件定義：10〜15%
- 設計：25〜35%
- 開発・単体テスト：30〜40%
- 結合・総合テスト：15〜20%
- 移行・導入：5〜10%
データが整っていない企業や連携の多い企業は、移行・テストの比率が高くなるため、割合を固定的に使わないようにします。
別途費用としては、商品マスタの整理と、過去の在庫・受注履歴の移行があります。
EDI・API・外部倉庫調整の費用も、別途費用の対象です。ハンディやラベルプリンター、帳票も対象に入ります。
教育やマニュアル、休日切替支援、並行稼働も含まれます。バックアップ環境も含めて、見積もりを確かめます。
見積書に「一式」とある項目は、数量・単価・成果物・回数・前提条件を尋ねて、中身を確かめます。
ランニングコストの内訳（保守・連携・端末・改善）
運用費は、基盤、保守、外部連携に分けて見積もると、費目ごとに比べやすくなります。
- 基盤：SaaS利用料・サーバー・クラウド・ユーザーや拠点の追加・ハンディ・通信・バックアップ・監視
- 保守費：問い合わせ・障害と法改正への対応・追加改修
- 保守条件：初期費用の年10〜20%程度が目安の場合もあり、契約時間・対象範囲・更新・休日対応・訪問支援で変わります
- EDI・API：接続先の仕様変更や通信量、監視、再送、エラー時の手作業も費用に影響します
- 会計・請求：締め処理・税区分、データの保存・検索・改ざん防止
国税庁は、EDI・インターネット・メール添付などを電子取引に含め、電子取引データを一定の要件で保存する必要があると案内しています（出典：国税庁「電子帳簿保存法の概要」）。
卸売・商社向け在庫管理システムの見積もりを取る際のポイント
相見積もりでは、最安の会社を探すよりも、同じ業務条件で費用と期間、どこまでを誰が受け持つかを比べます。移行を含む会社と開発だけの会社、連携を別料金にする会社があると、金額を並べても比べられません。
簡易なRFPで要件と前提条件をそろえておくと、見積もりを比べやすくなります。
RFPに書く業務量・データ・例外処理
RFPには、規模や取引量を抽象語ではなく具体的な数値で書きます。
- 拠点・利用者：会社、事業所、自社と外部の倉庫、利用者と権限
- 取引量：商品点数・年間と月間の受注件数・出荷明細・仕入先と販売先の数
- 管理条件：バーコードやラベル、ロット・期限、受注残と発注残の件数
数字が空欄のまま出されると、会社ごとに異なる前提で見積もりが作られてしまいます。そのため、数字は依頼の段階でそろえておきます。
規模を「中小企業」や「大量取引」と表すだけでなく、データ量やピーク時間でも伝えます。
業務要件は、通常処理と例外処理に分けて書きます。通常処理は、受注から出荷、発注から入荷、棚卸から差異承認までです。
例外処理には、分納、返品、直送、預託を含めます。欠品、代替品、仕入先変更も、例外処理として書き出します。輸出入、受注取消、売買同時計上も入れます。
各業務について、入力者と承認者、確定時点を整理します。さらに、取消の方法や履歴、帳票、連携先も書き出します。
非機能要件には、稼働時間・同時利用者数・応答時間・バックアップ頻度・復旧目標を含めます。
認証やMFA、IP制限、ログの保存期間も、要件に含めます。権限、API、CSV出力、障害時の手作業も、要件として書き出します。
電子取引データでは、取引年月日・金額・取引先による検索・訂正と削除の履歴・事務処理規程を、経理と情報システムで確認します。
ベンダーの比較（デモ・実績・支援体制）
候補会社には、同じ業務シナリオでデモを依頼します。たとえば、自社倉庫にない商品を発注し、直送か入荷後の出荷かを選んだうえで、分納後の売上・仕入・請求まで確認する流れを試します。
卸売型では、期限の近い商品の出荷やハンディ検品、棚卸差異の承認を試します。商社型では、在庫を持たない取引、外貨、案件別の粗利、受発注同時登録を確認します。
導入支援や契約後の対応も、会社ごとに同じ質問で比べます。
- 導入力：類似規模の実績、導入責任者、教育、移行担当
- 運用支援：障害対応、保守時間、追加改修単価
- 契約終了：データ返却と移行支援
どこまでが標準機能で、どこからがカスタマイズかを確認します。連携に障害が起きた際の一次対応も、あわせて聞いておきます。
導入事例では、「効率化した」といった表現よりも、商品点数・拠点数・出荷明細・端末・対象業務が自社に近いかを見ます。
事前に抑えるリスク（カスタマイズ・移行・定着）
事前に確認するリスクは、カスタマイズ、データ移行、導入後の定着の3つに分けて整理します。
- カスタマイズ：標準機能や手順変更で代替できるかと、更新時に壊れないかの確認
- 移行：重複コード・廃番・単位差・表記ゆれ・評価単価の欠損・受注残の定義差の洗い出し
- 定着：業務オーナー・マスタ管理者・システム管理者・ベンダー窓口、改善予算の決定
旧帳票やExcelをそのまま再現すると、カスタマイズのリスクが増えます。
特殊な帳票や根拠の曖昧な承認は、運用ルールを先に整理します。
旧システムのデータは、そのまま取り込めるとは限りません。そこで、移行対象を現行在庫、未完了の受注・発注、検索用の履歴に分け、保持期間と検索方法も決めます。
定着後に商品を追加したり、価格を改定したり、倉庫を増やしたり、EDIを変更したりする場合も、申請者、承認者、反映する時点を運用設計に含めます。あわせて、月次のKPI会議も予定しておきます。
よくある質問（FAQ）
導入期間、WMSとの違い、Excelからの移行、AIの必要性は、よく尋ねられる質問です。
答えは業態や規模によって変わるため、判断の基準をまとめます。
卸売・商社向け在庫管理システムは何か月で導入できますか？
標準機能中心のクラウドSaaSは設定やデータ移行を含めて1〜3か月程度、業界パッケージは3〜6か月程度が目安です。
複数拠点、EDI・API、会計連携、外為、売買同時計上を含む場合や、全面的な基幹刷新の場合は、6か月から2年程度、またはそれ以上かかる可能性があります。
期間は機能数だけでなく、意思決定の速さやマスタ整備、テストデータ、現場の参加度でも変わります。
在庫管理システムとWMSはどちらを先に導入すべきですか？
主な課題が入荷・ロケーション・ピッキング・検品・出荷精度にあるなら、WMSが有力です。一方で、受注・発注・売上・仕入・請求や拠点間在庫の統合が課題なら、販売・購買・在庫を含む基幹側の設計を先に進めます。
在庫の正本をどちらに置くか、受注・発注の状態をどう同期させるかを決めます。食品卸で期限管理やハンディ、大量出荷を優先する場合は、WMS連携を要件に含めます。
Excelから在庫管理システムへ移行するときの注意点は何ですか？
移行前には、移行の範囲と照合の方法を決めておきます。
- データ定義：Excelの形式をそのまま取り込まず、商品コード・単位・取引先・倉庫・在庫数量・受注残・発注残を定義し直す
- データ整理：重複・表記ゆれ・廃番・欠損を整理したうえでの移行
- 正本と在庫照合：別ファイルがある場合の正本の決定と、移行前の棚卸による現物とデータの照合
- 履歴の範囲：日常検索の期間と、監査・請求確認の保存方法（全履歴は移行対象外）
必要な履歴だけを選べば、費用と期間を抑えやすくなります。
卸売・商社の在庫管理にAI需要予測は必要ですか？
最初から必須ではありません。商品マスタや販売実績、季節性、発注・入荷実績、単位をそろえ、欠品や過剰在庫の原因を説明できてから導入すると、効果を検証できます。
発注点や安全在庫の補助から始め、予測値は自動発注へ直結させません。担当者が根拠を確かめてから承認する運用にします。
まとめ
卸売型では、受注残・発注残・入荷予定・期限・多拠点をつなぎます。一方、商社型では、直送・売買同時計上・輸出入・案件別採算まで含めて、取引全体を追跡します。
6フェーズの完了条件の設定
要件整理では現状とデータをそろえ、選定では標準機能、連携、5年総額を比べます。設計・開発では例外処理を形にし、テストでは実データと異常系を検証します。
その後は、段階導入や並行運用によって稼働のリスクを抑えます。定着は、教育とKPI改善で進めます。各段階で、誰が承認し、何を納品し、いつ完了とするかを決めておくと、追加要望や手戻りを早く見つけられます。
最初の一歩：現物・Excel・基幹の差異の洗い出し
商品マスタと拠点一覧を作り、現物、Excel、基幹システムの在庫を、同じ商品コードと単位で照合します。
受注から出荷、発注から入荷、返品や直送までの業務フローを描き、現場の困りごとに優先順位を付けます。そのうえで、RFPやPoCを準備し、方式と開発パートナーを比べることは、費用と定着を見通す第一歩になります。
▼全体ガイドの記事
・卸売・商社向け在庫管理システム開発の完全ガイド
▼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を創業。