調達管理システムは、申請から支払いまでの調達業務を一つにつなぐ業務システムです。必要な機能と導入方法は、対象業務、既存システムとの連携、取引先の参加方法によって変わります。
全体像から方式、導入手順、費用、開発会社の選び方、法制度まで、発注側が押さえる点をまとめました。
▼関連記事一覧
・調達管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・調達管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・調達管理システム開発の見積相場や費用/コスト/値段について
・調達管理システム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
調達管理システムの定義
調達管理システムは、物品やサービスを適切な条件で購入し、その事実を証跡として残す業務システムです。
このシステムは、予算から支払いまでの各段階を、一つの流れでつなぎます。承認と契約を経て、納期、検収、請求へと進み、最後に支払いへつながります。
調達業務を申請から支払いまでつなぐ流れ
調達の基本的な流れは、購買申請と承認から始まります。見積依頼と見積比較、仕入先選定を経て、発注、納品、検収に進みます。そのあと、請求書照合、支払い、実績分析へとつながります。
メールや表計算ファイルで管理すると、承認者や予算、発注数量と納品数量の一致を後から追いにくくなります。一方で、申請番号や発注番号で書類を紐付けておけば、担当者が変わっても追跡できます。
購買管理・在庫管理・会計システムとの違い
購買管理、調達管理、在庫管理、会計システムは、扱う範囲がそれぞれ異なります。
- 購買管理：購買申請や発注など、購入行為の管理が中心です。
- 調達管理：価格交渉や仕入先評価、契約条件まで範囲を広げた考え方で、購買統制や支出分析も含みます。
- 在庫管理：入出庫、現在庫、発注点の管理です。
- 会計・債務管理：仕訳、支払い、残高の管理を扱います。
製品名だけでは機能の範囲が分かりにくいため、申請から検収・請求のどこまでを扱うかを確認します。
在庫、会計、販売へ渡すデータの確認も必要です。
生産管理と連携する場合は、その受け渡しも確かめます。
直接材・間接材・サービスで変わる要件
直接材では、部品表や所要量、ロットを考慮します。リードタイム、品質検査、トレーサビリティも合わせて見ます。
一方で、間接材では、カタログ購買や予算承認、相見積が中心です。請求書照合も欠かせません。
外注費や専門サービスでは、作業範囲と契約期間、成果物を確かめる必要があります。検収条件と工数も、あわせて押さえておきます。特に、対象を絞るか全領域を統合するかで、必要な機能と費用が変わります。
調達管理システムの主な機能と導入効果
機能は、業務上のリスクを減らす順番で選びます。
土台になるのは、申請と承認の履歴、見積比較、発注・納品・請求の照合です。さらに、仕入先情報や会計、在庫との連携、分析機能も加わります。
購買申請・承認ワークフローによる統制
申請画面では、部門、プロジェクト、品目、数量を入力します。
あわせて、希望納期、予算、購入理由も書き込みます。そのうえで、金額や品目に応じて承認者を決めます。
- 承認ルート：多段階承認、代理承認、差戻しを設定します。
- 例外ルート：緊急購買や少額購買の簡略ルートを定義します。
- 購買制御：契約外購入や予算超過を検知する仕組みです。
さらに、承認前の発注を防ぐルールも設けます。適切な経路を定めることで、統制と現場の停滞抑制を両立できます。
発注・検収・請求の3点照合による差異の発見
3点照合は、発注内容と納品・検収内容、請求内容を比べる処理です。数量や単価、税率が合い、納品日や検収状況も一致すれば、支払いへ進みます。
一致しない場合は、差異の理由を確認します。
分納や返品、値引を想定していないと、担当者が表計算で補正を続けることになります。注文変更、未納、請求書分割も確かめます。照合結果と差戻し理由を記録しておくと、監査対応や業務改善に役立ちます。
仕入先管理とKPI分析による改善
仕入先マスタには、基本情報や取引の情報のほか、税務に関わる情報も登録します。
- 基本情報：名称、住所、担当窓口
- 取引の情報：口座、契約、評価
- 税務と取引状態：適格請求書発行事業者の登録番号と、取引停止の状態
表記揺れや重複を防ぐため、登録の申請と審査、変更と削除の権限を分けます。
分析では、購買の状態と、承認や納品などの業務の進み具合を見ます。
- 購買の状態：購買額、単価差異、集中購買率、契約外購買率
- 業務の進み具合：承認リードタイム、納期遵守率、請求差戻し率、在庫切れ件数
作業時間に加えて、購買単価や例外処理の減少をKPIにすると、効果を説明しやすくなります。
調達管理システムの種類と選び方
方式は、クラウドSaaS、パッケージやERPへの追加、スクラッチ開発に大別できます。
複数のサービスを組み合わせる方式は、ハイブリッドと呼ばれます。
方式を比べるときは、従業員数だけでなく、直接材の有無や拠点数、月間発注件数を合わせて見ます。仕入先数や承認段階、既存システムも対象です。
業務の独自性と海外展開も、あわせて比べます。
標準化と早期導入を重視する場合のクラウドSaaS
クラウドSaaSは、初期投資と導入期間を抑えやすい方式です。さらに、法改正や機能更新を自社で実施せずに済みます。
間接材、少拠点、標準的な承認ルートから始める場合の候補になります。一方で、画面や承認、取引先との接続に制約が出ることがあります。
- 画面と承認：画面項目、承認条件、請求照合
- 取引先とデータ：取引先の利用方法、データ保存期間、API
費用では、月額料金に加えて、ユーザー数や取引量、追加環境も確認します。
初期設定やデータ移行、取引先の招待を導入前に確かめます。
解約時のデータ返却も、ここで見ておきます。
基幹業務との一貫性を重視する場合のパッケージ・ERP
パッケージやERPでは、調達や在庫、販売のデータを、生産や債務、会計と一つの業務基盤で扱いやすくなります。
特に、複数拠点や直接材を管理し、グループ標準化を進める場合に有力です。
業務を製品に合わせるのか、追加開発で現行業務を残すのかが曖昧なままだと、費用が増え、更新も難しくなります。そのため、標準機能、設定、追加開発、運用変更の境界を要件定義で決めておきます。
独自業務と連携を優先する場合のスクラッチ・ハイブリッド
スクラッチ開発は、特殊な検収や工場端末、複雑な取引先連携に合わせやすい方式です。独自の購買ルールも組み込めます。
- 契約条件：要件の凍結、テストデータ、移行、保守要員、障害時の責任分界を契約で定めます。設計書やソースコードの納品も含めます。
- ハイブリッド構成：申請と承認は標準SaaSで行い、会計や在庫とはAPIやCSVで連携して、独自の部分だけを開発する形です。
- 開発範囲：全体を作り込まず、差別化につながる業務と標準化できる業務に分けて考えます。
調達管理システムの導入・開発の進め方
製品より先に、業務の側を整理するのが進め方の基本です。
まず現状業務と目標、対象範囲を押さえ、そのうえで連携、データ、運用体制へと進みます。
購買部門に加えて、経理や情報システムも初期から関わります。
現場や仕入先も、同じ段階から巻き込みます。
▶ 詳細はこちら：調達管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
現状の購買プロセスと例外処理の洗い出し
申請から承認、見積、発注までを業務シナリオとして書き出します。納品、検収、請求、支払い、分析も、同じ形で並べます。
通常処理に加えて、緊急購買や少額購買を確かめます。分納や返品も対象です。
注文変更や納期遅延、契約外購買も確かめます。請求金額の不一致も含めます。現場、購買、経理に加え、情報システムや監査、主要取引先へも聞き取ります。そのうえで、Excelやメール添付の使われ方を洗い出します。こうして業務の事実を把握すると、不要なカスタマイズを減らせます。
要件定義とRFPによる比較条件のそろえ方
要件は、Must、Should、Couldに分けて整理します。初回リリースに必要な範囲は、そのなかから決めます。機能要件には、申請項目や承認条件、見積比較を含めます。発注書や納品・検収、返品、3点照合も入れます。
仕入先評価や帳票も機能要件に含めます。検索と分析も、機能要件として定義します。一方、非機能要件では、利用者数や同時接続、応答時間を決めます。可用性、バックアップ、RTO・RPOも含めます。
監査ログや権限、認証も定義しておきます。データの保管場所やサポート時間も含みます。RFPでは、同じ業務シナリオとサンプルデータを渡します。そのため、デモや見積の前提がそろいます。
開発・テスト・データ移行の分離管理
設計・開発では、画面や帳票を確かめます。承認ルートや権限、採番も確認します。状態遷移や連携エラー時の再送、監査ログも、設計の対象です。
- テスト：単体と結合、業務シナリオの順に進めます。性能、セキュリティ、受入も行い、発注から請求まで検証します。
- データ移行：仕入先、品目、単価、契約、部門、勘定科目、予算、未完了発注、過去証憑の範囲を決めます。名寄せや重複除去は先に行います。
マスタ移行を発注側の作業に含めて計画しておかないと、後工程で費用と期間が膨らみます。
小規模リリースと利用定着
導入は、1拠点や1部門、1品目群、間接材の一部といった小さな範囲で試す形から始められます。そのうえで、承認時間や発注漏れ、差戻しを測ります。請求照合や利用率も対象です。
仕入先には、利用開始時期や入力項目、費用負担を伝えます。問い合わせ窓口と障害時の代替方法も説明し、取引先の導入期間も確保します。
マニュアルに加えて、役割ごとに短い操作教育を用意します。申請者や承認者、購買担当、検収担当、経理担当が対象です。そうすると、現場が使い始めやすくなります。
調達管理システムの費用相場と開発期間
費用は、方式や利用者数、取引先数によって変わります。月間発注件数や連携数、直接材の有無、データ移行の難しさも影響します。
次の数字は、在庫・購買・受発注の相場と類似業務SaaSの公開価格を組み合わせた、2026年時点の検討用の目安です。
調達専用システムの一律の価格ではない点に注意してください。実際の金額は、要件をそろえた個別見積で確かめます。
▶ 詳細はこちら：調達管理システム開発の見積相場や費用/コスト/値段について
方式別の初期費用と期間
方式と連携内容をそろえて比べられるよう、初期費用と導入期間の目安を並べます。
- 標準SaaS：初期費用20万〜300万円程度、月額7万〜50万円程度、期間1〜3か月が目安です。
- 連携・設定あり：会計、在庫、ERPとの連携や権限・帳票の設定を伴う場合で、初期費用300万〜1,500万円程度、月額10万〜100万円程度、期間3〜9か月。
- パッケージ・ERP：アドオンを加える場合、1,000万〜8,000万円程度、期間6〜18か月となるケースがあります。
- スクラッチ・大規模刷新：5,000万〜3億円以上、期間1〜3年以上になる場合があります。
金額と期間は、案件の条件によって変わります。取引先ポータルやEDI、請求書読み取りを加えると、少人数の会社でも費用が上がります。3点照合や複数通貨、海外拠点も、費用を押し上げる要因です。
グループ共通マスタや厳格な職務分離も、費用に影響します。
一方で、標準的な間接材の申請・承認から始め、連携と移行を限定すれば、初期費用を抑えられる場合があります。
要件定義・開発・移行に分けた費用の内訳
見積は、要件定義や設計、開発・設定、テストに分けて確かめます。データ移行、教育、リリース支援、保守も、それぞれ分けて見ます。
初期費用の配分は、要件定義が10〜15%、設計が25〜35%、開発・テストが45〜60%、移行・教育が5〜10%程度と仮置きすると、比べやすくなります。
ただし、標準SaaSとスクラッチでは構成が異なります。マスタ整備や連携、帳票、取引先案内、テスト環境、操作教育が別料金だと、総額は変わります。
月額料金を含めたTCOの算出
総保有コスト（TCO）は、初期費用に加えて、利用中と移行時にかかる費用も含めて算出します。
- 導入・運用費：初期費用、月額利用料、年間保守を合算します。クラウド基盤や追加改修、API利用料も含めます。
- 周辺費用：電子請求やEDIの取引料、サポート費、社内の運用人件費を見ます。教育やデータ移行、取引先支援も対象です。
- 保守費の計算例：初期費用3,000万円に年間保守15〜20%を仮定すると、年間450万〜600万円になります。SaaS料金や追加改修は別途かかります。
5年程度の利用を想定して、機能追加や契約更新、障害対応、解約時のデータ返却まで比べます。
調達管理システムの開発会社・ベンダーの選び方
会社を比べるときは、知名度や機能一覧より、自社の業務シナリオを実装・運用できるかを見極めます。
完成品を提供するベンダーと、要件定義や連携開発を担う会社では、役割が異なります。
契約上の責任範囲も、あわせて確かめます。
類似業務の経験と実装範囲の確認
導入社数だけでなく、近い業界の案件で、拠点数や月間発注量、直接材の有無、取引先数が近い経験があるかを確かめます。
会計や在庫、生産との連携条件も照らし合わせます。また、デモでは自社のサンプルを使い、申請から承認、見積比較を経て発注まで再現してもらいます。
分納や検収、請求差異、差戻しまで確かめます。納品範囲として、要件定義書や設計書、テスト仕様書、操作マニュアル、移行手順書を見積に含めます。
連携・移行・定着支援の責任分界
契約の前に、連携や取引先対応、移行、稼働後の支援ごとに担当範囲を決めておきます。
- システム連携：API、CSV、EDI、ファイル転送のどれを使うか、頻度や再送、項目変換、採番を決めます。マスタの正本も確かめます。
- 仕入先支援：招待、アカウント、利用料、教育、問い合わせを決めます。未参加時の代替処理も含めます。
- データ移行：抽出、名寄せ、検証の担当と、稼働後の修正権限を契約書に記載します。
- 運用支援：改善会議の持ち方や、サポート時間、障害時の連絡体制を比べます。SLAや再委託先の管理も含めます。
セキュリティと契約終了時のデータ出口
セキュリティ対策と契約終了時の取り扱いは、運用条件とあわせて確かめます。
- アクセスと記録：最小権限や職務分離、多要素認証、SSO、暗号化を確かめます。操作や承認、マスタ変更の監査ログも含めます。
- 安全管理：脆弱性への対応や、バックアップと復旧テスト、データの保管場所、再委託先を見ます。
- 機密情報と返却：口座情報、価格、図面、仕様書の閲覧・ダウンロード制御を確かめます。返却の範囲・形式・期限と消去証明も質問します。
▶ 詳細はこちら：調達管理システム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：調達管理システム開発の発注/外注/依頼/委託方法について
2026年の最新動向と法制度への対応
調達管理システムは、証憑保存や税務、サプライチェーンのセキュリティ、企業間のデータ連携に関わります。法令や制度の当てはまり方は取引形態で変わるため、経理や法務、情報システムと確かめます。
電子帳簿保存法の検索性と改ざん防止
電子帳簿保存法に対応するには、対象データと保存・検索の要件を整理することが出発点です。
- 対象データ：メールやクラウドで受け取る注文書、納品書、請求書などは対象になり得ます。
- 改ざん防止：訂正削除履歴を残すか、訂正削除できない仕組みを備えます。
- 検索・関連付け：取引年月日や金額、取引先で検索できるようにします。関連番号で発注、検収、請求のデータを行き来できるようにします。
なお、国税庁は2026年6月に「電子帳簿等保存制度を活用して、デジタル化をさらに進めてみませんか？」を公開しました。
インボイス制度に必要な仕入先情報の管理
インボイス制度では、仕入税額控除に必要な帳簿と適格請求書などの保存が関係します（出典: 国税庁「適格請求書等保存方式（インボイス制度）」、2025年4月1日現在法令等）。
そのため、システムでは仕入先の登録番号や適用税率、消費税額を管理します。請求書の受領日や発注・検収との紐付けも、あわせて扱います。
登録情報の変更や失効を確かめます。免税事業者との取引条件や経過措置は、税務担当者の判断をシステムに反映させます。請求書がどの発注と検収に対応するかを確かめられることが大切です。
取引先まで含めたサプライチェーン対策
制度動向と共通要件を踏まえ、調達システムの接続やデータ連携を設計します。
- セキュリティ評価制度
- システム要件：提供側の安全性に加えて、取引先接続や権限、端末、委託先を評価します。障害時の連絡と契約上の役割分担も見ます。
- データ連携指針
- 初期設計：将来の連携拡張に備えて、データ項目や識別子、権限、履歴、交換方式をそろえておきます。
経済産業省は2026年3月に構築方針を公表し、2026年度末頃の制度開始を目指しています。
この制度では、IT基盤の対策段階を示し、状況を見えるようにする方向です（出典: 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」、2026年3月27日）。
情報処理推進機構は2026年3月、トレーサビリティや信頼性、相互運用性、データ主権などを共通要件とするガイドラインを公開しました（出典: 情報処理推進機構「データ連携の仕組みに関するガイドラインの手引き サプライチェーン共通編 1.0版」、2026年3月）。
導入前に確認したい要件チェックリスト
資料請求や見積依頼の前に業務とデータを確かめておくと、提案を比べやすくなります。ただし、回答できない項目は調査課題として残します。
対象範囲と利用者の決定
直接材や間接材、外注・サービスのうち、どこを対象にするかを決めます。
対象の部門や拠点、海外法人をどこまで含めるかも、あわせて整理します。
月間の申請件数や発注件数、請求書件数を把握します。
仕入先数や承認段階、同時利用者、紙やFAXが残る業務も押さえます。
申請者や承認者、購買の権限を分けます。代理承認や異動時の扱いも、あらかじめ決めておきます。そのうえで、検収、経理、監査、システム管理者には、それぞれ次の権限を持たせます。
- 検収：納品内容を確かめて受け入れる担当者の権限
- 経理：支払いと仕訳を扱う担当者の権限
- 監査：操作や承認の記録を確かめる担当者の権限
- システム管理者：設定とマスタ変更を担う権限
マスタ・連携・証憑の状態
仕入先や品目、単価、契約のマスタを一覧にします。部門やプロジェクト、勘定科目のマスタも含めます。ほかに、次のマスタも対象です。
- 税区分：課税や非課税などの区分
- 予算：部門やプロジェクトごとの予算額
- 在庫：品目ごとの在庫数量
- 発注残：発注済みで未納の数量
正本を置くシステムや更新頻度、コード体系を確かめます。重複や表記揺れがあるかも見ます。
会計や在庫、販売、生産、電子契約との連携も整理します。
請求書やEDI、ID管理との連携では、項目とタイミング、エラー時の扱いを決めます。
注文書や納品書、検収記録、請求書、契約書の保存期間と形式も整理します。
導入効果を測るKPIの事前設定
導入後の効果を示すには、導入前の数字を先に押さえておく必要があります。そこで、同じ指標を導入の前後で測れるよう、次の項目を決めておきます。
- 導入前の基準値：申請から承認・発注までの時間、契約外購買率、同一品目の単価差、相見積の実施率
- 納期と請求：納期遵守率、検収遅延、請求差戻し率
- 発注・在庫・仕入先：発注漏れ、二重発注、在庫切れ、仕入先利用率
そのうえで、導入後は月次で比べ、未利用の理由を調べます。AIによる見積比較や価格異常検知を加える場合は、マスタと実績を整えておく必要があります。さらに、人が判断結果を確かめられる承認ルートも残します。
調達管理システムに関するよくある質問（FAQ）
価格や機能だけでなく、既存業務や取引先、法制度、運用体制も合わせて考えます。初期検討で多い質問に答えます。
調達管理システムはSaaSと開発のどちらがよいですか？
SaaSと開発のどちらが合うかは、次のように業務の条件で変わります。
- SaaSが候補：標準的な間接材の申請・承認を早く始めたい場合
- 追加開発やスクラッチが候補：独自検収や複雑な連携が競争力に直結する場合
- 標準機能と開発の範囲：直接材や複数拠点、既存ERP、取引先接続がある場合
- 費用と将来の確認：初期費用だけでなく、5年程度のTCOやデータ出口、更新時の影響
小規模な会社でも調達管理システムを導入できますか？
導入できます。
件数が多く、手作業の負担が大きい範囲に絞り、間接材の申請・承認や発注、請求照合などから始めるのが現実的です。
利用者数や取引量が少なくても、仕入先マスタや権限、証憑保存、会計連携は、後から作り直すと高くつきます。そのため、将来拡張できるデータ構造と契約条件を確かめておきます。
仕入先がシステムを使わない場合はどうしますか？
仕入先向けポータルやメール、CSV、EDIなど、複数の受け渡し方法を用意します。不参加の場合の代替処理も定義しておきます。
利用料の負担者や入力項目、導入説明や問い合わせの担当を決めます。対象の仕入先は、重要度や取引量で分けます。
全社一斉より、段階的に参加を進めるほうが定着しやすくなります。
調達管理システムにAIを導入すべきですか？
AIは、請求書の読み取りや品目分類、見積比較を補助できます。
価格異常検知や需要予測にも使えます。
ただし、仕入先名や品目コードがそろわないと、誤分類や誤検知が増えます。まずマスタや承認ルール、過去実績、例外処理を整えます。そのうえで、AIの判断を人が確認できるログと承認経路を残し、効果を測りやすい業務から段階的に適用します。
まとめ
調達管理システムは、購買申請や発注書だけでなく、予算や承認、見積、仕入先までをつなぐ業務基盤です。納品・検収から請求、支払い、分析までも、同じ流れでつなぎます。
導入時は、直接材や間接材、サービスの範囲を整理します。会計や在庫、生産との連携、仕入先の参加方法、マスタ移行、セキュリティ、法制度も確かめます。
自社の調達範囲と業務量に基づく方式の選定
SaaS、パッケージ・ERP、スクラッチ、ハイブリッドのどれを選ぶかは、会社名や機能数だけでは決まりません。決め手になるのは、自社の業務条件です。
月間発注件数や仕入先数、承認段階、直接材の有無、連携数、業務の独自性を、そろえて比べます。5年程度のTCOも同じ条件で比べます。
標準化できる業務は標準機能に合わせ、独自性と効果の高い部分へ開発費を集中させると、費用と運用負荷のバランスを取りやすくなります。
要件とKPIの整理と比較の開始
導入前の整理、候補の比較、稼働後の測定を順に進め、調達業務の改善につなげます。
- 現状の購買フローと例外処理を洗い出し、対象範囲、利用者、データ、連携、権限、証憑保存、セキュリティ、KPIを一枚にまとめます。
- 複数の開発会社・ベンダーに同じシナリオで質問し、初期費用や移行、取引先支援、保守、追加改修、契約終了時のデータ返却を比べます。
- 導入後は、承認時間や契約外購買率、単価差、納期遵守率、請求差戻し率を継続して追います。
▼関連記事一覧
・調達管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・調達管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・調達管理システム開発の見積相場や費用/コスト/値段について
・調達管理システム開発の発注/外注/依頼/委託方法について
▼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を創業。