産業機械製造業向け部品調達管理システム開発の完全ガイド

産業機械製造業の部品調達管理システムは、個別受注と見込生産の混在、BOMや設計変更への対応が要点です。発注から原価までをつなぎ、納期と製品構成を守る仕組みになります。

機能、導入手順、方式と費用、開発会社の選び方は、下の関連記事でも詳しく確認できます。

▼関連記事一覧
・産業機械製造業向け部品調達管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・産業機械製造業向け部品調達管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・産業機械製造業向け部品調達管理システム開発の見積相場や費用/コスト/値段について
・産業機械製造業向け部品調達管理システム開発の発注/外注/依頼/委託方法について

部品調達管理システムの概要

部品調達管理システムを中心に、受注、BOM、納期、原価がつながる図
複数部門にまたがる情報の接点を整理。

このシステムは、受注から原価までの流れを、BOMや設計変更、発注まで含めてひとつにつなぐ仕組みです。製品構成と調達状況を結び付けることで、必要な部品を必要な版数と納期までにそろえる判断を支えます。

導入の効果を左右するのは、購買だけでなく、営業、設計、生産管理、製造、品質、経理が同じ情報を参照できるかどうかです。

在庫管理との違いと調達判断の支援

在庫管理は、現在の数量、保管場所、入出庫の履歴を把握するものです。一方で、部品調達管理は受注残と製品構成から必要数を算出し、在庫、発注残、入荷予定、仕入先のリードタイムを重ねて見ます。

  • 入荷予定:納期に間に合う確定入荷があれば、在庫がゼロでも追加発注は要りません。
  • 引当済み在庫:別の案件に割り当てた在庫は、ほかの案件では使えない在庫として扱います。

在庫の数量だけで発注の要否を決めると、確定入荷や別案件への引当を見落としやすくなります。

個別受注生産と見込生産の混在への対応

産業機械では、標準モーターやボルトを一定量で在庫する一方で、顧客仕様の加工品や大型部品は受注後に手配することがあります。そのため、部品ごとに異なる調達ルールを扱える設計が必要になります。

  • 見込生産品:発注点と安全在庫で管理する部品。
  • 個別受注品:製番や案件ごとに引き当てる部品。
  • その他の調達品:支給品、外注加工品、長納期品。

すべての部品を同じルールで扱うより、特性ごとに分類したほうが要件を整理しやすくなります。

BOMと設計変更履歴の調達データへの反映

設計が変わると、旧版を使える期限、新版を手配する案件、発注済みの部品を返品するか転用するかを判断する必要があります。このため、部品表の版数、有効日、図面、仕様書、変更承認の履歴を調達データとつなぎます。

発注、入荷、払い出しの時点で参照した版数も記録しておきます。古い図面での発注や手配漏れを防ぐためです。

ポイント

導入を考えるときは、在庫数の把握で足りるか、受注や設計変更、原価まで一つの流れで見る必要があるかで判断すると整理しやすくなります。

必要な主要機能とデータ連携

品目マスターとBOMから所要量計算、発注・入荷・在庫、製番原価へ続く図
基礎データから原価確認までを順につなぐ構成。

評価の軸は機能の数ではなく、部品が必要になってから支払いや原価に反映されるまでのデータ連携です。初期導入では、品目マスターとBOMを土台に、所要量計算から納期管理までを優先します。さらに、分析や高度な自動化は、データが安定してから広げるのが現実的です。

品目・仕入先・価格・リードタイムのマスター整備

品目コードや品名、仕様、単位、発注ロットといった品目の情報と、標準価格、仕入先、納期、検査区分、保管場所、代替品を、一貫したルールで管理します。

たとえば、「個」「台」「セット」「メートル」の単位が部門で異なると、所要量計算と在庫集計がずれます。

  • 重複の解消:仕入先名や品目コードの二重登録を整理する。
  • 登録ルール:不要品目の整理と、必須項目、責任者の定め。
  • 変更管理:マスター更新の承認者を指定する。

二重登録や単位の揺れは、見積比較、価格分析、在庫集計の精度を下げます。

EBOM・MBOM・調達BOMとMRPの連動

設計部門のEBOM、製造工程に合わせたMBOM、購買用の調達BOMは、それぞれ目的が異なります。そのため、一つに統合するよりも、製品・部品・工程の関係と版数をつないで、どの情報を正とするかを明確にしておきます。

MRPは、受注と生産計画、BOMを起点に、在庫や入荷予定、リードタイムと照らして、不足数と手配時期を計算します。

設計変更後の再計算では、未発注、発注済み、入荷済みの部品を分けて表示すると、購買担当が判断しやすくなります。

見積依頼から発注・検収までの一連の流れ

見積依頼では、仕入先ごとの価格、納期、最小発注数量を比べます。支払条件や見積の有効期限も、同じ条件でそろえて見ます。

発注後は、注文書と納期回答、督促を起点に、分納や数量変更、返品を経て、検収と買掛データまで追跡します。

  • 追跡キー:発注番号と案件番号による記録のひも付け。
  • 仕入先連携:ポータルやEDIの入力項目は、控えめにする。
  • 段階導入:納期回答と納品予定から共有を始め、品質書類や請求連携へ広げる。

在庫・トレーサビリティ・製番原価の管理

入荷から廃棄まで、棚卸や引当、在庫移動も含めた在庫の動きを、ロケーションと製番にひも付けます。重要部品はロットやシリアルで管理し、使用した案件と仕入先を追跡できるようにします。

案件別原価には、仕入価格のほか、加工費や輸送費、為替などを集計します。追加工や特急費も含め、見積原価との差異も確認します。

手配漏れや特急調達まで見えるようになると、購買の値下げ以外の改善策も選べるようになります。

導入の進め方

現状業務の棚卸し、要件定義、実データの検証と移行計画、テスト・教育・段階稼働を並べた図
業務整理から現場での運用までを段階化。

導入の成否は、製品選定より先に、業務とデータを整理できるかで決まります。全工場と全機能を一度に扱うより、納期回答や発注残の見える化など、効果を測りやすい業務から試すのが現実的です。

高機能でも、現場で入力が続かなければ調達の判断基盤にはなりません。

▶ 詳細はこちら:産業機械製造業向け部品調達管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

受注から検収までの現状業務の洗い出し

引合、見積、受注の流れを、一枚にまとめます。受注のあとは、設計、BOM確定、所要量計算を経て、見積依頼へ進みます。見積依頼のあとは、発注と納期回答を経て、入荷へ進みます。入荷のあとは、検査、検収、払い出しを経て、原価計上で終わります。工程ごとに、担当者、ファイルや帳票、記録する番号を調べます。

聞き取りに加えて、発注書や納期回答、入荷記録、設計変更履歴を数件たどります。そうすると、手作業の例外や二重入力が見つかりやすくなります。

要件定義で決める業務判断とデータの正

要件定義では、機能の有無に加えて、誰がいつ何を判断するかを決めておきます。

  • 業務判断:遅延基準、設計版数の承認者、代替品の採用条件。
  • 例外条件:分納の在庫反映、外注加工中の所有権、仕入先別価格の有効期間。
  • データ管理:品目から会計まで、正を持つシステムの合意。
  • 要件と費用:画面・帳票、登録件数、BOM階層、利用者数、応答時間、設計変更の履歴期間、API・CSVの頻度を記載する。
  • 運用条件:バックアップ、復旧目標、権限、ログ、移行、教育、納品物を含め、追加項目は初期費用と将来費用を分けて示す。

実データによる検証と移行計画

候補システムのデモは、一般的な標準品の購買とあわせて、自社で難しい業務を実データで確かめることが重要です。

  1. 匿名化した実データで、BOM版変更、長納期品の不足、代替品、分納、外注加工、発注済み部品の案件変更を再現する。
  2. 1製品または1工場のPoCで、計算結果と入力時間、例外時の修正担当を確かめ、現場の期待に合うかを見る。
  3. 移行対象は、重複品目や旧版、廃止品、在庫残高、図面・仕様書の保管先として決める。移行前後の在庫と発注残を照合する。
  4. 差異の調査手順を用意し、マスター整備は社内のデータ責任者が担う。

テスト・教育・段階稼働による定着の確認

稼働前後の作業は、テスト、教育、定着の順に進めます。

  1. 通常発注、設計変更後の再計算、数量変更、分納、返品、納期遅延の場面をテストする。
  2. 同じシナリオで業務が止まらないかを見て、連携エラーや通信障害時の再送と手入力も試す。
  3. 役割ごとの手順書と問い合わせ窓口を用意し、稼働直後は旧台帳と照合する。毎日見るのは、在庫、発注残、納期遅延、未入力です。
  4. 入力負担が大きいときは、機能を足す前に、必須項目やバーコード・CSVでの代替、承認ルールを見直す。

代替品、外注先の未回答、仕入先休業、在庫差異もテストの対象です。購買、設計、生産管理、倉庫、品質、経理は、同じシナリオで確認します。

ポイント

進め方に迷うときは、データと業務ルールが整っているかを先に確かめ、効果を測りやすい一部の業務から始めるのが目安です。現場の入力が続くかも、範囲を広げる前に見ておきます。

費用相場と開発期間の目安

費用は、規模と業務の複雑さで変わります。規模では利用者数や拠点数、部品点数が影響します。加えて、BOMの複雑さや連携、移行、端末、カスタマイズ、保守範囲も費用を左右します。

ここで示すのは市場平均ではなく、予算取りの目安として推定した幅です。

▶ 詳細はこちら:産業機械製造業向け部品調達管理システム開発の見積相場や費用/コスト/値段について

▶ 詳細はこちら:産業機械製造業向け部品調達管理システム開発の発注/外注/依頼/委託方法について

導入範囲別の初期費用とランニング費用の目安

費用と期間には、方式や導入範囲ごとに幅があります。

  • 小規模クラウド:1拠点の品目・発注・入荷・在庫を標準管理。初期0万〜50万円、月額4万〜20万円、1〜3か月。
  • クラウド・セミオーダー:BOM・見積・発注・在庫を連携する範囲。初期100万〜800万円、月額10万〜50万円、2〜6か月。
  • 個別設定付きパッケージ:ERP・会計・CAD連携と移行を含む構成。初期500万〜2,000万円、6〜12か月。
  • 複数工場などを含む場合:初期2,000万〜8,000万円、12〜24か月以上になることがあります。
  • フルスクラッチ:独自ルールを全面開発する場合で、1,500万円から数億円まで広がる可能性があります。

複数工場などの範囲には、製番別原価や複数言語、EDI、現場端末が含まれます。また、クラウドの費用は、利用者数や容量、API、サポートの契約条件で変わります。

根拠は、開発相場と製造業向けサービスの公表価格を産業機械の要件に当てはめて整理したものです(出典: 2026年8月時点の製造業向け開発相場と公表価格の整理、2026年)。

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

見積もりでは、費用の内訳と追加条件を分けて見て、長期の総額まで確かめます。

  • 初期費用:企画から稼働支援までの開発作業。画面・帳票、API・CSV、移行、テスト、教育を含む。
  • 運用費:利用料・クラウド容量、ユーザー追加、保守・監視・バックアップ、脆弱性・法改正対応、問い合わせ、端末・ラベル交換。
  • 見積条件:一式の範囲、成果物、前提、除外項目、追加変更単価。
  • 見落としやすい費用:マスター・図面の移行、仕入先への説明、ネットワーク、端末、並行稼働、復旧訓練も含めて見る。
  • 長期比較:5年間の利用料、保守、追加開発、移行、教育を合算する。有料の連携や出力によって、総額の順位が入れ替わることもあります。

費用対効果の測定と判断時間の評価

効果測定では、在庫の削減額に加えて、業務判断にかかる時間も評価対象にします。

納期回答時間や督促件数、手配漏れ、特急発注などを測ります。発注残の確認時間、棚卸差異、原価集計日数、設計変更後の確認時間も、評価の対象に入れます。

たとえば、導入前に「納期回答に平均何時間かかるか」「発注残の確認に何人日かかるか」を記録しておくと、導入後の改善を比較できます。

ポイント

費用は、初期開発費に加えて、移行や教育、保守、5年間の運用費まで含めて比べるのが目安です。前提や対象外の項目がそろわない見積もりは、金額だけで比べないようにします。

クラウド・パッケージ・スクラッチの選び方

方式は、工場の独自性や拠点数、既存システム、通信環境、社内の保守体制をもとに選びます。そのうえで、標準化できる業務と、競争力に直結する独自業務を分けて考えます。

機能適合度、データの持ち方、連携、障害対応、更新、契約終了時の移行を、同じ条件で比べます。ただし、クラウドなら安全、オンプレミスなら自由とは限りません。

短期導入と段階展開を重視する場合のクラウド型

クラウド型は、サーバーの購入や基盤の保守を抑えやすく、1拠点や一部機能から始めて展開できます。加えて、仕入先や外注先と納期を共有しやすい点も利点です。

工場の通信が不安定な場合のオフライン運用や、大量BOMの検索性能、データの保管場所、契約終了時のデータ返却は、事前に確かめておきます。また、ユーザー数やAPIの上限、個別帳票の制約も見ます。

標準業務を早く整えたい場合のパッケージ型

パッケージ型は、購買、在庫、MRP、製造、原価など、製造業で共通する業務を標準機能で使えます。業務を標準に寄せるほど、要件定義やテストを短くでき、将来の更新にも対応しやすくなります。

BOMの版管理、代替部品、外注加工、支給品、複雑な製番原価が合わないと、追加開発が増えます。標準デモを見るだけでなく、実業務で確かめます。

独自業務の範囲で見るスクラッチとハイブリッド

独自業務への適合と開発後の運用を基準に、方式ごとの判断材料を比べます。

  • スクラッチ:独自の見積計算、設計変更、設備・帳票連携を細かく合わせやすい方式です。
  • 開発・保守リスク:要件変更の影響が広がりやすく、担当者交代や文書不足、OSやDB更新の費用も含めて見る。
  • ハイブリッド:標準基幹システムと連携基盤を使い、独自性の高い部分を追加開発する方式。
  • 検証と運用:実データと5年間の運用を通して、BOM再構成や設計変更、分納、発注取消を試す。代替品、外注加工、在庫引当も対象にします。
  • 責任範囲:修正担当を決め、連携先が多い場合は、どこまでを誰が受け持つかとエラー時の再処理を文書にまとめる。

方式は、機能一覧に並ぶ丸の数を見るより、独自業務の範囲に合わせて選びます。

ポイント

方式は、独自業務の範囲と社内の保守体制で絞り込み、実データでの検証で確かめるのが目安です。機能一覧の丸の数では、運用後の差が見えにくいためです。

導入で失敗しやすい原因と効果測定の方法

失敗は、業務ルール、データ、責任者、入力方法が決まらないまま進むことで起きます。たとえば、購買だけで要件を決めると、設計変更や原価、倉庫、会計の要件が後から加わります。

経営、設計、生産管理、購買、製造の代表者を、初期の段階から参加させます。品質、経理、情報システムの代表者も含めます。

マスターとBOMの整備の優先

品目コードや単位、仕入先、リードタイム、在庫、BOMが不正確だと、MRPや需要予測の計算結果を信用できなくなります。そのため、先に重複品目、廃止品、旧版、未登録の代替品、異なる単位を洗い出します。

マスター変更の申請、承認、履歴を運用に組み込み、設計変更と購買変更の責任を分けておきます。そのうえで、AIや自動発注を検討します。

初回リリースの範囲の絞り込み

受注から会計、取引先連携までを一度に刷新すると、要件の依存関係が複雑になります。最初は、1拠点・1製品群・一部の標準部品を対象にします。

まずはBOM、発注、入荷、発注残、在庫の見える化から始めます。効果を測ったあとに、特注品や外注加工、製番原価、取引先入力、複数拠点へ広げます。対象外の業務と将来対応の条件も明記します。

納期・手配漏れ・在庫精度のKPI

導入効果を比べられるよう、追跡する指標と測り方を整理します。

  • 納期:回答にかかる時間、発注から確定までの日数、遅延の早期発見率。
  • 手配:漏れの件数、発注残の滞留日数、緊急発注の件数。
  • 在庫・原価:在庫精度、棚卸差異、原価集計時間。
  • 測定方法:KPIは目的に合わせて3〜5個に絞り、導入前の1か月または3か月と導入後を同じ定義で測る。

セキュリティの確認項目も具体化します。経済産業省は2025年4月、中小規模の製造事業者向けに、工場セキュリティの始め方を解説する資料を公表しました。

同資料は、工場の規模にかかわらず、サプライチェーン全体での対策の必要性を示しています(出典: 経済産業省「工場セキュリティの重要性と始め方」、2025年)。

権限分離や多要素認証、操作ログ、暗号化、バックアップ、復旧目標を確かめます。取引先とは、どこまでを誰が受け持つかを決めておきます。

開発会社/ベンダーの選び方

選ぶ際は、知名度や機能数より、産業機械の業務を一緒に設計できるかを見ます。個別受注と見込生産、BOM版管理、長納期品、特注品といった業務を、同じシナリオで説明してもらいます。外注、製番原価、既存連携も対象に含めます。

見積額が低い候補ほど、前提条件や対象外、追加費用、導入後の支援範囲を丁寧に確かめます。

個別受注と部品調達の業務適合度

製品構成と版数変更、所要量計算、代替品、発注点、安全在庫を確かめます。見積比較や納期回答、分納、返品、外注加工も対象になります。支給品、ロット・シリアル、製番別原価も含みます。

デモには、表記揺れや未確定納期を含む実データを渡します。候補側が用意した整ったデータでは、現場の状況が見えにくくなります。処理可否に加え、例外時に現場が修正し、履歴を残せるかを見ます。

連携・移行・保守の責任範囲の切り分け

連携先には、CAD・PLM・PDMや販売管理、ERPなどがあります。会計、MES、WMS、ハンディ端末、EDIとも連携することがあります。データ項目、更新頻度、方式、エラー時の再送、障害時の暫定運用を確かめます。

移行では、抽出、名寄せ、受入検証を誰が担当するかを決めます。稼働後の問い合わせや障害、脆弱性、法改正、OS更新への対応は、契約書とSLAで範囲を確かめます。追加開発やデータ返却の支援範囲は、契約書の条件として確かめます。

RFPと比較表による候補の条件統一

候補企業の提案条件をそろえるために、RFPの記載項目と評価軸をまとめます。

  • RFPの規模情報:企業規模、拠点数、部品点数、BOM階層、月間受注・発注件数、仕入先数。
  • RFPの運用情報:同時利用者数、必要な連携、移行量、目標稼働日、保守体制。
  • 比較項目:機能適合度と追加開発、連携と移行、セキュリティ、費用と期間、現場支援と将来拡張。
  • 評価記録:5段階評価の点数に加えて、根拠と未解決の質問を残す。

取引先とデータを共有するときは、相手側の入力負担とセキュリティも確かめます。IPAは2025年12月に、サプライチェーン間のデータ連携要件を整理した手引きを公開し、2026年3月に更新しています。

また、データの目的やアクセス権、営業秘密、保存期間、退会時の削除、監査方法は、契約と運用の両方で定めます(出典: IPA「データ連携の仕組みに関するガイドラインの手引き サプライチェーン共通編」、2025〜2026年)。

▶ 詳細はこちら:産業機械製造業向け部品調達管理システム開発でおすすめの開発会社/ベンダー6選と選び方

ポイント

開発会社は、知名度より、個別受注や部品調達の業務を同じシナリオで説明できるかで比べるのが目安です。提案金額が低い候補は、追加費用や導入後の支援範囲も含めて比べると、後の食い違いを防ぎやすくなります。

よくある質問

導入検討で質問されやすい内容をまとめました。自社の業務やデータに当てはめ、候補システムへの確認事項として使えます。

部品調達管理システムと在庫管理システムは何が違いますか?

在庫管理は、数量と入出庫、保管場所の把握が中心です。一方で、部品調達管理はBOMや受注、所要量、発注残、納期をつなぎ、手配時期の判断を支えます。仕入先や設計変更、製番原価も、そこに含めて扱います。

標準品の在庫が主な課題なら、在庫機能から始めます。個別受注や長納期品が課題なら、調達や生産計画との連携を優先します。

クラウド型でも工場や取引先のセキュリティを確保できますか?

認証や権限、通信時と保存時の暗号化、操作ログ、バックアップを確認します。脆弱性対応や復旧目標、データ保管場所も、あわせて確かめ、リスクを管理します。

工場内ネットワークや設備、取引先の接続経路まで、どこまでを誰が受け持つかを明確にします。障害に備えて、紙や一時ファイルで業務を続ける手順も用意します。

安全性は、クラウドかどうかよりも、自社の重要度と影響範囲に合わせて評価します。

AIや自動発注は最初から導入したほうがよいですか?

最初から高度なAIや完全自動発注を入れる必要はありません。品目コードやBOM、在庫、発注残、リードタイム、納期実績が整っていないと、予測や自動発注の結果を検証できません。

まずは不足や遅延、過剰在庫を見える化し、担当者が承認する発注提案から始めます。データの品質と効果を確かめながら、自動化の範囲を広げます。

購買データを会計や電子帳簿保存につなげる際の注意点は何ですか?

発注、検収、請求、支払の番号と日付をひも付けたうえで、買掛や原価へ計上する時点を決めます。

国税庁は2025年度の電子帳簿保存法改正に関連し、デジタルインボイスから帳簿へ自動連携するデジタルシームレス保存を案内しています。

証憑の保存形式や改ざん防止、検索要件、保存期間、会計側との責任分担は、経理と一緒に確かめます(出典: 国税庁「事業者のデジタル化促進」、2025年)。

まとめ

部品調達管理システムは、在庫の記録にとどまらず、受注から原価までをつなぐ仕組みです。具体的には、設計とBOM、所要量の情報を、発注、納期、入荷、在庫と結び付けます。製品を約束どおりに完成させるための基盤になります。

個別受注と見込生産、標準品と特注品、社内在庫と外注加工を扱えることが、産業機械向けの重要な要件です。

最初に決める課題・KPI・データの責任者

導入前には、納期回答時間、手配漏れ、発注残、在庫精度、原価集計時間などから、改善指標を3〜5個に絞ります。そのうえで、品目、仕入先、BOM、在庫、発注残のデータを整えます。登録、承認、変更の担当も決めます。

データの正や業務判断が曖昧なままだと、現場が以前のExcelやメールに戻ってしまうおそれがあります。

小さな検証から始める連携と自動化の拡大

費用は、初期開発費に加えて、移行、教育、連携、保守、セキュリティ、5年間の運用費まで含めて比べます。そのうえで、クラウド、パッケージ、スクラッチの各方式で、実データを使って業務を検証します。

BOM変更や分納、代替品、長納期品、外注加工を確かめたうえで、1工場や1製品群から稼働させます。KPIを見ながら、取引先連携や会計、複数拠点、発注提案の自動化へ広げます。

▼関連記事一覧
・産業機械製造業向け部品調達管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・産業機械製造業向け部品調達管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・産業機械製造業向け部品調達管理システム開発の見積相場や費用/コスト/値段について
・産業機械製造業向け部品調達管理システム開発の発注/外注/依頼/委託方法について

会社紹介

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

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

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

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

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

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