自動車部品製造業向けかんばん管理システム開発の完全ガイド

自動車部品製造業向けのかんばん管理システムは、受注、生産、在庫を連携させ、現場の実績から納入までを追跡できる業務基盤です。

紙やExcelでは情報が分かれやすいため、受注、生産、在庫、実績を一つの流れでつなぐ点が、このシステムの要となります。あわせて、費用相場や失敗対策、選定の要点も扱います。

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

自動車部品製造業向けかんばん管理システムの全体像

かんばん管理システムを中心に、受注情報、生産・調達量、納入実績、データの正を結ぶ図。
需要の変化と現場の記録が同じ業務の輪につながります。

かんばんは、後工程が必要とする部品を、必要な数だけ前工程へ知らせる仕組みです。

システム化では、かんばんを単独の在庫票として扱わず、需要情報と現場の実績を結び付けます。さらに、補充が必要になった理由まで追跡できる状態を目指します。

内示から納入までをつなぐ仕組み

内示、確定受注、納入指示を受け取ると、在庫と仕掛を差し引いて必要量を計算します。

  • 段階的に届く情報:月次・週次の内示、日々の確定受注、納入先・便・時間帯の納入指示
  • 生産・調達量:受注の差分を確かめ、在庫と仕掛を差し引いて求める
  • 納入までの実績:完成、空容器回収、補充、出荷、検収の各段階

データの正は、業務ごとに置き場所を決めておく必要があります。販売システムの確定受注、現場の読取実績、出荷実績のどれを基準にするかが曖昧だと、部品の二重引当や在庫だけの増減が起きます。

要件定義では、情報の発生源、更新者、更新時期、訂正方法を決めておきます。

紙・Excel運用で起きる情報の分断

紙やExcelには扱いやすさがある一方で、情報の記録や更新に課題があります。

  • 紙かんばん:回収、紛失、記入漏れが起きやすく、履歴をたどるのが難しい傾向がある
  • Excel:集計・加工には便利な一方、担当者別のファイルと最新版の管理に課題が出やすい
  • 内示変更:計画、購買、出荷表の手修正に時間がかかり、その伝達遅れが欠品や余剰在庫を招くことがある
  • 紙を使う工程:安全上の理由から、一時的に紙で運用するのが適する工程もある
  • 後登録の代替手順:日時、担当者、品番、数量、移動元を記録し、通信断や端末故障の後で登録する手順

紙をなくすこと自体は目的ではなく、現場の安全と、通信断や端末故障時の業務継続を考えたうえで電子化を進めます。

ポイント

かんばん管理を考えるときは、紙やExcelに分かれた記録をつなぎ直せるかを基準にします。受注の変更、現場の実績、在庫が一つの流れで見えるかどうかで、必要な機能の範囲が変わります。

主要機能と自動車部品特有の要件

受注差分、生産方式、現場実績、ロットと出荷先の履歴を4枚のカードで示す図。
受注の変更から現場記録、出荷後の追跡までを確認できます。

自動車部品向けの製品は、一般的な在庫管理の機能一覧だけでは比べきれません。

品番や容器、納入先といったマスターを、どの粒度で持つかが運用の使いやすさとデータの信頼性を左右します。工程やロットなど、ほかのマスターも同じ考え方で扱います。

受注・内示・EDIの差分管理

受注情報は、区分と品番の対応を保ったまま持ち、担当者が取込状況を確認できるようにします。

  • 受注区分:内示と確定受注を別々に保持して、前回との差分を見る
  • 形式・品番:日・週・月単位での取り込みと、得意先品番から自社品番への変換
  • 納入情報:納入先と納入便の、受注への紐付け
  • 複数EDI:エラー、未取込、重複取込を確かめられる画面
  • 内示減少:数量は上書きせず、材料・仕掛品への影響と変更前後、理由、確認者、生産指示を履歴に残す

変更履歴が残っていれば、現場の判断が一人の経験に寄らず、取引先とも同じ記録をもとに確認できます。

かんばんと計画生産の品目別の使い分け

品目によって適する生産方式は異なるため、全品目をかんばん方式に統一する必要はありません。

  • かんばん向き:需要が安定し、補充の周期が明確な量産品
  • MRP・計画生産との併用:需要が変動する品目、長納期材、試作品、補給品、工程制約が強い品目
  • 方式設定:品目や工程ごとに決め、同じ品番でも受注区分や納入先によって計算を変える
  • 管理マスター:かんばん枚数、容器収容数、補充点、リードタイム、安全在庫、最小ロット

公開されている製品情報にも、かんばん生産と計画生産を混在させる要件の例があります(出典: 自動車部品向け生産管理製品の公式機能情報、2026年確認)。

現場実績とトレーサビリティの一体化

現場実績は、読取手段と作業者が使いやすい入力画面を組み合わせて記録する仕組みにします。

  • 読取手段:ハンディターミナル、タブレット、バーコード、QRコード、RFIDを使った読み取り
  • 登録実績:着手、完成、払出、入庫、出荷の登録
  • 入力画面:管理者向けの情報を絞り、作業者が一度の操作で登録を終えられる構成
  • 読取エラー:失敗や誤品番をその場で知らせ、後からのExcel修正を減らす
  • 履歴管理:材料ロット、設備、作業者、工程、検査結果、出荷先の記録

トレーサビリティは、品質部門だけが使う機能ではなく、在庫差異や誤出荷の原因を調べるための業務基盤です。訂正や取消が起きた場合は、元の値と変更者を監査ログに残しておきます。

導入方式とシステム構成の選び方

導入方式は、標準業務の範囲をパッケージやSaaSで使い、競争力や安全性に直結する固有要件だけを拡張する構成が検討しやすいです。

既存の販売、生産、購買のシステムを、すべて置き換える必要はありません。WMSや会計、設備のシステムとは、連携によって段階的に改善できる場合があります。

SaaS・クラウドが向く場面

SaaSやクラウドは、初期のインフラ負担を抑えられるため、小さく試したい場合に向いています。

  • 試行範囲:1工場や限定品番からの開始
  • 費用条件:ユーザー・拠点・端末の追加費用、将来の利用者数・データ量を確かめる
  • 障害対応:一時保存、オフライン入力、復旧後の再送、バックアップ、監視、障害通知が標準機能に含まれるか
  • 工場ネットワーク:外部接続に頼る場合は、キャッシュ、冗長化、予備端末、紙の緊急手順を検討する

止められない工程の可用性を保つには、クラウドを使う場合でも、工場側のネットワーク設計が必要です。

パッケージ拡張と個別開発の境界

標準機能と固有要件の境界を先に決めておき、追加開発は必要な範囲に絞ります。

  • 業界特化パッケージ:内示、EDI、所要量、かんばん、生産、出荷の各機能を、短期間で導入しやすい
  • 追加機能の注意:標準機能にない項目を全部足すと、更新の影響確認や保守が難しくなる
  • 個別開発の対象:画面の自由度より、独自計算、工程制約、設備連携など差別化に必要な範囲を選ぶ
  • 連携方式:API、EDI変換、CSV、メッセージキューのいずれでも、受信・検証・登録・再送を分けて設計する
  • 直接連携:増やしすぎると、変更のたびに複数箇所を直す必要が出る

共通マスターは、品番や取引先を中心に、ロケーションと単位も持たせます。あわせて、エラーを再送できる仕組みも設計します。

ポイント

導入方式は、標準業務をパッケージやSaaSで使い、競争力や安全性に直結する部分だけを拡張する形で考えます。工場ネットワークと連携方式の確認も、方式を決める前に進めます。

自動車部品向けかんばん管理システムの進め方

現状把握と要件定義からPoC、教育・切替、定期測定と改善へ進む4工程の図。
検証と教育を経て、運用後の測定へ進む構成です。

導入は、製品選定から始めるより、現場の業務イベントと判断ルールを整理してから進めたほうが、失敗しにくくなります。

まず、企画と要件定義から始めます。そのあと、設計・開発とテストを行い、教育と段階導入へ進みます。各段階で成果物と意思決定者を明確にします。

▶ 詳細はこちら:自動車部品製造業向けかんばん管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

現状把握と要件定義で決める業務の正

要件定義では、通常業務と例外時の流れを現場で観察し、必要な事項をフローに記録します。

  • 観察する工程:かんばん発行・消費、空箱回収、補充、生産、検査、入庫、出荷、検収
  • 確認する例外:内示急変、欠品、仕掛滞留、容器不足、誤読、通信断、夜間の緊急出荷
  • フローの記録:担当部署、入力場所、利用端末、判断条件、後工程への通知
  • RFPの規模:拠点数、品番数、得意先・仕入先数、EDI接続先
  • 処理量・運用条件:1日の受注件数・イベント数、端末台数、同時利用者数

ロット・シリアルの管理単位、データ保持期間、目標復旧時間も、RFPに明記しておきます。

「柔軟に対応」といった曖昧な表現は避け、「内示を日次で取り込み、変更差分を確認し、確定受注を納入便単位で引き当てる」のような業務シナリオで要求します。

代表品番でのPoCと連携テスト

対象を絞ったうえで、代表品番を使い、業務の一周と異常時の処理を試します。

  • 試行範囲:1工場、1ライン、代表的な品番群
  • 確認する流れ:受注取込、生産指示、現場実績、在庫更新、出荷照合
  • 品番条件:安定品、変動品、長納期材、かんばん・計画生産の混在品
  • 異常シナリオ:内示急減、欠品、通信断などの例外
  • 連携エラー:通知、再送、二重計上の防止まで

試験では、重複データや受注増、容器不足、バーコード読取不良を再現します。権限不足や出荷先違いも、試験の対象に含めます。連携テストでは、エラーの通知先と再送するデータを確かめ、二重計上を防ぐ手順も確認します。

教育・切替・本稼働後の改善の設計

教育、切替、本稼働後の測定を、ひとつながりの計画として設計します。

  • 現場教育:実端末を使った、通常時と異常時の操作の練習
  • 切替条件:旧運用との並行期間、切戻し条件、在庫確定のタイミング
  • 支援と帳票:問い合わせ先と障害連絡先の決定、入力負担を抑えるための既存帳票の削減
  • 定期測定:在庫日数、欠品件数、納期遵守率、かんばん回転数、棚卸差異、計画変更に要する時間、出荷照合エラー、現場入力時間を定期的に確かめる
  • 改善基盤:導入直後のAI・予測機能の追加より、品番・在庫・実績の定義をそろえ、効果測定の基盤を整えること

事前の準備を重ねておくと、本稼働日の混乱を抑えられます。

ポイント

進め方を比べるときは、代表品番で異常時の処理まで試せる計画かを基準にします。要件定義で例外の流れを押さえ、本稼働後の測定まで計画に入っているかも確かめます。

費用相場とコストの内訳

費用は、拠点数や品番数、同時利用者数によって変わります。EDI先の数や端末・設備との連携、データ移行も、金額に影響します。24時間運用や冗長化の条件も加わるため、公開価格は一律ではなく、次に示す金額は初期予算の推定レンジです。

正式な見積もりでは、要件ごとの工数と前提条件を分けて確かめます。

▶ 詳細はこちら:自動車部品製造業向けかんばん管理システム開発の見積相場や費用/コスト/値段について

方式別の初期費用と期間の目安

初期費用と導入期間は、方式や連携範囲によって変わります。

  • SaaS・クラウド:初期設定、教育、限定移行で20万円から100万円程度。期間は数週間から3か月程度
  • 業界特化パッケージ:標準導入で300万円から1,500万円程度。期間は3か月から6か月程度
  • 複数システム連携:EDI・WMS・端末連携で800万円から3,000万円程度。期間は6か月から12か月程度
  • 個別開発:独自計算、工程制約、設備連携、原価、複数工場を含むと1,000万円から5,000万円程度
  • 基幹刷新:全社・複数工場では5,000万円を超え、1億円以上の場合もある

これらは市場の統一価格ではなく、公開価格が少ない領域での初期試算です(出典: 本稿の試算、2026年)。金額は、拠点、連携、データ移行の前提によって変動します。

初期費用以外のコストの内訳

見積書では、導入費用を項目別に分けて示してもらいます。

  • 要件・開発:要件定義、標準設定、追加開発、EDI接続、マスター整備、データ移行
  • 設備・環境:端末とラベル、クラウドやサーバー
  • 導入支援:テスト、教育、現場リハーサル、切替支援、保守

一式の金額では、後から追加費用が発生する箇所を見つけにくくなります。ランニングコストには、利用料や保守、クラウド、EDI通信、端末のほか、バックアップ、監視、セキュリティ対応、機能追加も含まれます。

運用保守は、初期開発費の年15%から25%程度を仮の目安にすることがあります。費用はサービス水準や対象時間で変わるため、平日営業時間外の障害対応、復旧目標、データ復旧、アップデート検証の範囲も確かめます。

ポイント

費用は、拠点や品番の数、連携範囲、データ移行などの条件で大きく変わるため、条件を揃えて比べます。見積もりでは、要件定義、開発、導入支援、運用保守を項目別に分けてもらうと比べやすくなります。

導入で失敗しやすいポイントと対策

導入の失敗は、ソフトウェアの機能不足だけが原因とは限りません。

現場の例外処理、マスターの品質、責任分界、教育、障害時の運用が要件に入っていないと、システムが稼働しても、元のExcelや紙に戻ってしまいます。

データ移行とマスター整備の前倒し

マスターの不備は、かんばん枚数や在庫の計算誤りにつながるため、移行の前に整えておきます。

  1. 不備を確認:品番・単位の表記ゆれ、得意先品番の対応漏れ、廃止品、重複ロケーション
  2. 責任者を設定:品番、工程、容器、収容数、リードタイム、安全在庫、取引先、納入先、ロットの各マスターごとに決める
  3. 試行移行:一括投入の前に、データを試しに移して確認すること
  4. 差分確認:重複、欠損、古い値を見つけて整える
  5. 本番移行・照合:旧システムと新システムの在庫合計を、品番・ロケーション・ロット別に照合し、差異の調整承認者を事前に決める

入力負荷と障害時の代替手順

紙帳票と端末入力が二重になるのを避け、操作性と障害時の継続方法を確かめます。

  • 操作性:タップ数、読取距離、手袋での操作、画面の見やすさ、端末の持ち運び
  • 実機確認:入力完了時の反応を見たうえで、作業者が試作品で入力時間と誤操作を測る
  • 代替手段:通信断・端末故障時の紙の緊急かんばん、予備端末、ローカル保存
  • 復旧処理:再送と、登録済みデータの重複防止の設計
  • 停止時の対応:責任者、記録用紙、復旧後の照合手順についての訓練

障害時に独自の判断で在庫を動かすと、復旧後にシステムの数量と実在庫がずれてしまいます。

過剰なカスタマイズと短期の安値

見積額だけでなく、含まれる作業と現場に必要な機能とを照らし合わせて判断します。

  • 安価な見積もり:要件定義、移行、教育、切替支援が含まれていないと、追加費用が生じる
  • 過剰な機能:使わない画面や不要な連携が、投資効果を下げる
  • 必要範囲:標準、設定変更、追加開発、将来対応に分けて絞り込む
  • 追加開発:標準で代替できない理由、業務効果、更新時の検証担当の記録
  • 優先KPI:欠品、出荷誤り、在庫精度、現場入力時間、監査・追跡を予算判断の材料にすること

KPI・セキュリティ・トレーサビリティの設計

導入効果は、「見える化できた」という感想だけでなく、導入前後の数値で説明します。

KPIとセキュリティは後付けにせず、要件定義の時点で、測定方法、データの出所、確認頻度、目標値、責任者を決めておくことが大切です。

業務のボトルネックに基づく効果測定

業務のボトルネックに合わせて、導入前後で比べられるKPIを選びます。かんばん回転数だけを目標にはしません。

  • 在庫・供給:在庫日数、欠品件数、納期遵守率、かんばん回転数、棚卸差異率
  • 計画・現場:内示変更の計画修正時間、出荷照合エラー、現場入力時間
  • 比較方法:計画反映時間を毎日測って、導入前後の平均を比べる
  • 見る成果:ログイン数よりも、経営課題や現場負担の改善
  • 目標設定:納期遵守率、欠品、在庫日数、緊急搬送を、品目・工程別に定める

KPIは、本稼働後も定期的に確認します。需要変動が大きい品目では、かんばん回転数を上げると欠品のリスクが高まる場合があります。

IT・OT・取引先評価の一体的な確認

工場システムは、事務所のITに加えて、現場端末や設備などのOT環境と接続する場合があります。

  • アクセス管理:最小権限、多要素認証、端末管理
  • ネットワーク・監視:分離、脆弱性対応、ログ監視
  • 復旧・委託先:バックアップ、インシデント対応、委託先管理
  • ベンダー確認:自己評価・対策証跡、パッチ適用手順、復旧訓練の支援
  • 取引先対応:自己評価、証跡管理、復旧体制をRFPに含めること

JAMA/JAPIAのガイドラインには、企業全体向けのものに加えて、工場領域版もあります。

工場領域版は、2026年4月16日に公開されました(出典: JAMA/JAPIA「自動車産業サイバーセキュリティガイドライン工場領域版 v1.0」、2026年)。

システム選定では、自己評価や対策証跡、工場停止を伴うパッチ適用の手順、復旧訓練の支援を確かめます。

経済産業省の制度構築方針は、2026年度以降の評価基準や運用整備を示しています(出典: 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」、2026年)。

特定の認証取得だけを目指すのではなく、取引先が求める自己評価や証跡管理、復旧体制をRFPに含めておくと、将来の確認に備えられます。

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

ベンダーは、知名度や機能数ではなく、自社業務を安全に稼働させられるかで選びます。内示、EDI、納入便、かんばん、計画生産、支給品、トレーサビリティの連動は、製品デモと導入支援体制で確かめます。

業界適合性と業務シナリオへの対応

自社の業務シナリオと機能の適合性を、次の観点で確かめます。

  • 受注・納入:内示と確定受注の差分、得意先別EDI、納入便
  • 生産・資材:かんばん増減、空箱回収、計画生産との混在、量産・補給品、支給品
  • 現場・連携:ロット追跡、現場端末、WMSや設備との接続
  • 実現方式:「対応可能」の一言で判断せず、標準機能、設定、追加開発、外部連携のどれに当たるかを確かめる
  • デモ検証:実データに近いサンプルを使った、一連の処理の確認

デモでは、内示急減や確定受注増、かんばん減枚、材料欠品、通信断、出荷先違いを再現します。画面の表示だけでなく、エラー検知から承認、訂正、再送、履歴確認までの操作も確かめます。

導入支援・保守・費用の透明性

導入支援、担当者の対応力、稼働後の体制を比べます。

  • 支援範囲:現状分析、要件定義、移行、連携、教育、リハーサル、本稼働、改善
  • 対応力:製造現場への理解、休日・夜間切替、問い合わせ窓口
  • 稼働後:担当変更時の引き継ぎ方法と保守体制
  • 総保有コスト:初期費用と月額・年額を含め、3年程度で比較する
  • 提案条件:前提、対象外、追加費用、納期、受入基準、責任分界の記載

費用には、連携や端末、ユーザーの追加にかかる額も含めて考えます。さらに、データ保管、保守、アップデートの費用も見ます。教育と障害対応も、同じ見積もりの中で確かめます。

▶ 詳細はこちら:自動車部品製造業向けかんばん管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら:自動車部品製造業向けかんばん管理システム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、機能数や知名度より、自社の業務シナリオに実際に対応できるかで選びます。デモでは異常時の操作まで確かめ、導入支援、保守、提案条件の記載を合わせて比べます。

よくある質問(FAQ)

自動車部品製造業で導入を検討する際によく出る疑問を取り上げます。

最適な構成は自社の業務条件で変わるため、ここでの回答をそのまま製品要件にせず、現場の品番、工程、取引先、既存システムに照らして確かめます。

紙のかんばんをすべて廃止しなければなりませんか?

すべて廃止する必要はありません。電子データを正としつつ、現場の視認性や緊急時の代替手段として紙を残す、ハイブリッド運用も可能です。

大切なのは、紙で発生した消費、補充、出荷のイベントを、いつ、誰が、どの方法でシステムに反映するかを決めておくことです。

既存の生産管理やERPを置き換える必要がありますか?

置き換えが必須とは限りません。既存システムを残したまま、かんばん・現場実績・出荷照合の機能を追加し、APIやEDIで接続する方法があります。

在庫や受注の正を複数のシステムが持つと二重管理になるため、データ項目ごとの管理元と更新ルールを決めてから、方式を選びます。

小規模な工場でも導入できますか?

導入できます。まずは1工場や限定品番に対象を絞り、受注取込、在庫、かんばん補充、出荷照合など、効果を測りやすい範囲から始める方法があります。

全社導入を前提にした大規模な構成を最初から作る必要はありません。将来の拠点追加やEDI追加に対応できる設計だけを先に確保しておくと、初期投資を抑えやすくなります。

AIや需要予測の機能も最初から必要ですか?

最初から必須ではありません。AIや需要予測を使うには、品番、受注、在庫、実績、欠品、計画変更のデータが正しく蓄積されている必要があります。

まずはマスターと実績の品質を整え、予測を使わない場合の補充ルールとKPIを確立したうえで、効果が見込める品目から検証します。

まとめ

自動車部品製造業向けかんばん管理システムは、紙かんばんをデジタル画面に置き換えるだけのものではありません。

このシステムは、内示や確定受注、EDIを取り込み、かんばん生産と計画生産を使い分けます。そのうえで、所要量、生産、調達を一つの流れにつなぎ、在庫と現場実績もその中で扱います。さらに、出荷と検収までを同じ業務基盤の中でつなぎます。

導入時は、現場の例外処理とデータの正を定義したうえで、代表品番を使ってPoCと連携テストを行います。

費用は、標準導入、複数連携、個別開発、大規模刷新によって大きく異なります。そのため、要件定義や移行、教育、保守、障害対応まで含めて比べます。

開発会社・ベンダーは、機能数や価格だけでなく、業界要件への適合性、導入支援、セキュリティ、稼働後の改善体制で選ぶことが大切です。

最初に、内示変更から補充、出荷までの業務を一つのシナリオにまとめ、現状の作業時間、在庫日数、欠品、納期遵守率、棚卸差異を測ってみてください。

その数値をRFPとPoCの評価基準にすると、自社に必要なシステムを比べやすくなります。

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

 

会社紹介

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

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

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

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

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

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