材料在庫管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

材料在庫管理システムの開発は、在庫数量を画面に表示するだけではなく、入荷検品から棚入れ、製造への払出、余剰材料の返却、棚卸、購買までを同じデータでつなぐ取り組みです。成功のポイントは、要件整理から定着までを6つのフェーズに分け、現物在庫・現場台帳・基幹システムの数量を一致させることです。

本記事では、材料在庫管理システム開発の進め方を、要件整理、製品・開発会社の選定、設計開発、テスト、稼働、定着の順に解説します。材料・部品・仕掛品・支給品・端材をどのように区分するか、マスタ移行やロット管理をどこまで行うか、費用相場をどう見積もるかまで、社内稟議やRFP作成に使える判断基準として整理します。

▼全体ガイドの記事
・材料在庫管理システム開発の完全ガイド

材料在庫管理システムの全体像

材料在庫管理システムの全体像

材料在庫管理システムは、原材料や購入部品を中心に、製造で発生する仕掛品、顧客から預かった支給品、加工後に残る端材まで管理する業務システムです。商品在庫向けのシステムをそのまま導入すると、重量・長さ・個数の単位換算、ロットや検査状態、製造指図への引当が合わないことがあります。最初に管理対象と業務の境界を決めることが、開発の手戻りを防ぎます。

まず材料・部品・仕掛品・端材を分けて定義します

材料在庫の定義は、品目マスタの登録単位に直結します。たとえば鋼材なら、材質、板厚、幅、長さ、重量、仕入先、ロットを持たせ、購入単位と払出単位の換算ルールを決めます。樹脂や塗料なら、容器、容量、保管温度、有効期限、開封後の使用期限を管理する場合があります。購入部品は品番と仕入先を中心に管理し、仕掛品は工程や製造指図との関係を持たせます。端材は廃棄するだけでなく、再利用可能な寸法や保管場所を登録するかを決めておく必要があります。

支給品や預かり品は自社所有の材料と混ぜず、所有区分を在庫属性として持たせます。実物が同じ棚に置かれていても、所有者、使用可能な製品、返却条件が異なるためです。要件整理では「在庫として数えるか」だけでなく、「誰のものか」「どの製造指図に使えるか」「検査待ちでも数量に含めるか」まで確認します。

在庫数量ではなく、流れと履歴を管理します

必要な機能は、品目・材料マスタ、入荷検品、棚入れ、ロケーション、製造への払出、返品、廃棄、棚卸調整、ロット・製番トレーサビリティ、発注点、安全在庫、将来在庫の確認です。BOMや配合表から所要量を計算し、現在庫、引当済み、発注残、入荷予定を差し引いて不足量を出す場合は、MRPや生産計画との連携も必要です。機能名を並べるのではなく、「入荷した材料が検査待ちから使用可能になり、製造指図へ引き当てられ、余った分が戻る」というシナリオで確認すると、抜け漏れを見つけやすくなります。

2026年5月に中部経済産業局が公開した中小製造業向け資料でも、在庫・現品管理システムの代表機能として、原材料・仕掛品の管理、リアルタイム在庫、棚卸、ロケーション、ラベル発行、バーコード・二次元コード・RFIDによる現品照合が整理されています。導入効果として材料費や廃棄ロスの削減、棚卸時間の短縮、発注の適正化が示されています(出典:中部経済産業局「中小製造業の課題解決へ」、2026年5月)。自社でも導入前に、棚卸時間、在庫差異率、欠品件数、緊急購買件数、滞留在庫金額を測っておくと、効果を検証できます。

現物・現場台帳・基幹在庫の三者を一致させます

材料在庫管理で頻発する問題は、システムを導入しても数字が信用できないことです。倉庫にある現物、現場がExcelで持つ台帳、会計や生産管理システム上の在庫がそれぞれ別に更新されると、材料があるのに欠品と判断したり、同じ材料を重複発注したりします。入出庫の起点をバーコードや二次元コードの読み取りに統一し、誰が、いつ、どの品目を、どの場所から、どの製造指図へ動かしたかを履歴に残す設計が必要です。

材料在庫管理システムの進め方

材料在庫管理システムの開発プロセス

材料在庫管理システムは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進めると判断しやすくなります。各フェーズの成果物と意思決定者を先に決め、次の工程へ進む条件を明確にします。特に、現場観察とマスタ整備を開発会社任せにせず、材料を扱う担当者が主導することが重要です。

フェーズ1:要件整理では現場の流れとデータを棚卸しします

最初に、材料の発注から入荷、検品、棚入れ、引当、払出、製造実績、余剰返却、廃棄、棚卸までを実際の現場で確認します。会議室で聞くだけでは、棚番の付け方、仮置き場、検査待ちの材料、夜間の出庫、外注先への支給などが抜けやすいためです。倉庫担当、購買担当、生産管理、製造現場、品質、経理、情報システムから代表者を選び、同じ業務シナリオを見てもらいます。

要件はMust、Should、Couldに分けます。Mustには「入出庫履歴が残る」「使用可否と検査保留を区別する」「製造指図へ引き当てられる」「棚卸差異を承認できる」など、稼働初日から必要な機能を入れます。Shouldには複数拠点の在庫照会や購買自動提案、CouldにはAI需要予測や高度な異常検知を置きます。マスタ項目は品番、名称、材質、規格、単位、換算係数、ロット、保管条件、仕入先、リードタイム、安全在庫、所有区分、棚番まで表にし、現行データの欠損と表記揺れを数えます。

この段階の完了条件は、対象範囲、業務フロー、権限、連携先、移行対象データ、導入前KPIが合意されていることです。たとえば「材料在庫だけ」と決めたのに、途中でBOM、原価、会計、外注管理まで追加すると、費用も期間も大きく変わります。対象外の業務も要件定義書に明記しておくと、後の追加要望を優先順位に沿って扱えます。

フェーズ2:選定では実データでFit & Gapを確認します

選択肢は、在庫管理に絞ったクラウド型、製造業向け生産管理パッケージ、クラウドERP、オンプレミス・ハイブリッド、材料業務に特化したスクラッチ開発です。1拠点で標準業務に寄せられるならSaaSやパッケージが候補になります。BOM、MRP、購買、製造、原価まで一体化するなら製造業向けパッケージやERPが候補になります。重量・長さ換算、切断歩留まり、端材再利用、預かり品などが競争力に直結し、標準製品に合わせにくいなら個別開発が候補になります。

比較表には、品目と単位換算、ロット・製番・期限、検査保留、ロケーション、BOM・所要量計算、ハンディ端末、API・CSV、会計・購買・生産管理連携、権限、操作ログ、バックアップ、データ出力を同じ順番で並べます。デモではサンプル画面を見るだけでなく、自社の実データを10〜20品目ほど渡し、「入荷ロットを検査待ちにする」「材料を製造指図に引き当てる」「一部を返却する」「端材を再利用可能として残す」といったシナリオを実行します。

2026年6月に公開されたmcframe X 26.1では、仕入先がWebで注文確認や注文データのダウンロードを行える取引先連携、在庫や発注などの異常を通知するモニタリング、実データを使って約3か月で適合性を評価する導入検証ガイドが紹介されています(出典:ビジネスエンジニアリング株式会社「mcframe X 26.1」、2026年6月)。このように最新製品でも、機能の多さより自社データで適合性を早期に確かめることが、過剰カスタマイズを抑える判断材料になります。

フェーズ3:設計開発では例外処理と納品物を決めます

設計では、業務フローを画面、データ、権限、連携に落とし込みます。入荷登録を誰が行い、検品結果を誰が承認し、使用可能になった材料をどのタイミングで在庫へ反映するかを決めます。現場のハンディ画面は入力項目を絞り、棚番とラベルを大きく表示し、通信が不安定なときの再送や一時保存も検討します。本社の照会画面には、現物、引当済み、発注残、入荷予定、保留を分けて表示すると、購買判断に使いやすくなります。

クラウド型は自動更新、複数拠点、バックアップを利用しやすく、標準業務に合わせられる企業に向きます。オンプレミス型やハイブリッド型は工場内LAN、既存設備、通信断時の継続運用、データ配置を重視する場合に向きます。価格だけでなく、5年間の利用料、保守、端末、通信、バックアップ、障害対応、契約終了時のデータ出力までを比較します。スクラッチ開発を選ぶ場合は、要件定義書、画面・帳票仕様、DB定義、API仕様、テスト仕様、移行手順、ソースコード、運用設計書を納品物に含めます。

設計開発中は、要望を受けるたびに画面を増やすのではなく、変更管理表で目的、影響範囲、費用、納期、承認者を記録します。特に「今のExcelと同じ帳票が欲しい」という要望は、入力や承認の流れを変えずに画面だけ再現しようとしている可能性があります。帳票を残す目的が在庫証跡なのか、現場の作業指示なのかを確認し、必要なデータを先に設計します。

フェーズ4:テストでは材料の実運用を再現します

テストは、画面が表示されるかだけでなく、材料が業務の流れを正しく通るかを確認します。単体テストでは入出庫、単位換算、権限、ラベル出力などを個別に確認し、結合テストでは購買、生産、品質、会計とのデータ連携を確認します。総合テストでは、入荷したロットを検査待ちにし、合格後に棚入れし、製造指図へ引き当て、払出と余剰返却を行い、完成品のロットまで追跡する一連のシナリオを実行します。

異常系のテストも欠かせません。数量がマイナスになる入力、未登録品目、期限切れロット、保留材料の払出、通信中断、同じラベルの二重読み取り、棚卸差異、発注取消、途中で単位が変わるケースを用意します。現場受入テストでは、倉庫や製造の担当者が自分の端末で作業し、入力時間、表示の見やすさ、ラベルの貼りやすさ、例外時の問い合わせ先を確認します。

フェーズ5:稼働では移行・並行運用・切り替えを管理します

稼働前の移行では、品目、仕入先、棚番、BOM、在庫数量、ロット、発注残、入荷予定、過去のトレーサビリティを対象にします。ただし、すべての過去データを移す必要があるとは限りません。検索頻度、法定保存、品質調査、会計監査の必要性で優先順位を付け、移行しないデータは参照用ファイルとして保管する方法もあります。表記揺れを直す責任者、変換ルール、承認日、元データの保管場所を決めておくことが重要です。

切り替え方法は、一斉稼働、拠点ごとの段階稼働、材料グループごとの段階稼働、旧システムとの並行運用から選びます。初回導入では、1拠点と代表的な材料グループに絞ったパイロットが安全です。切り替え日の棚卸基準時刻、未処理の入荷・払出、オフライン時の手書き伝票、再入力の担当、障害時の戻し方を事前に決めます。稼働判定は「ログインできる」ではなく、重要な材料シナリオをエラーなく完了し、数量が現物と一致することを条件にします。

フェーズ6:定着ではKPIと改善会議を運用します

システムは稼働してからが本番です。導入後1か月は、入出庫の未入力、棚番の誤り、保留解除の遅れ、ラベルの再発行、在庫差異の原因を毎日確認します。その後は週次または月次で、棚卸時間、在庫差異率、欠品件数、緊急購買件数、滞留在庫金額、材料廃棄額、払出入力時間、納期遵守率を確認し、導入前の数値と比較します。KPIは責任者と目標値、集計方法、確認頻度まで決めて初めて機能します。

AI需要予測や自動発注は、品目マスタ、単位、在庫実績、発注実績がそろってから検討します。入力ルールがばらばらなままAIを追加しても、予測の根拠を説明できず、現場が使わなくなるためです。まずはAXとして紙・Excel・担当者の記憶に依存する手順を標準化し、その後に需要予測、滞留検知、異常な払出の検知へ広げます。アップデートや制度変更に備え、保守契約、脆弱性対応、バックアップ復元テスト、操作教育の責任分担も定着計画に含めます。

材料在庫管理システムの費用相場とコストの内訳

材料在庫管理システムの費用相場

材料在庫管理システムの費用は、材料の種類、拠点数、ユーザー数、品目数、BOMの複雑さ、ロット・期限・重量管理、ハンディ台数、外部連携、データ移行、教育の範囲で大きく変わります。材料在庫だけの全国統計は確認できないため、以下はリサーチノートに記載された在庫・生産管理システムの公開情報と類似案件から整理した目安です。市場平均や確定見積もりではありません。

導入形態別の初期費用と期間の目安

小規模なクラウド型で、1拠点の在庫・入出庫・棚卸・ロケーションに絞る場合は、初期費用10万〜100万円、月額2万〜20万円、導入期間1〜3か月程度が一つの目安です。生産管理パッケージを標準導入し、材料、BOM、MRP、購買、製造実績まで扱う場合は、ライセンスを含む初期費用200万〜800万円、期間3〜6か月程度が目安です。実際には導入支援、端末、連携、教育が加わるため、必ず個別見積もりで確認します。

パッケージに複数拠点連携、会計・ERP・WMS・MES連携、ロット・期限、個別帳票を加える場合は、初期費用500万〜2,000万円、期間6〜12か月程度が目安です。材料在庫に絞ったWebシステムを個別開発する場合も、重量・長さ換算、歩留まり、端材、預かり品、独自の引当が含まれると、800万〜2,000万円程度、期間6〜12か月程度から検討するケースがあります。生産、購買、原価、MESまで含む基幹刷新は1,500万円から数億円、期間1年から数年に及ぶ可能性があります。

公開価格の具体例として、日立ソリューションズ・クリエイトのTPiCS-X Ver5.1は、2026年1月現在、オンプレミス型のシステム購入価格が110万〜160万円、稼働ライセンスが1ユーザー10万円、年間スタンダード保守がシステム価格16.5万〜24万円、ライセンス保守が1ユーザー年3,000円と掲載されています(出典:日立ソリューションズ・クリエイト「TPiCS-X」、2026年1月現在)。これはパッケージの公開価格であり、材料在庫だけの最終導入費、連携費、移行費を含む総額ではない点に注意します。同社のFAQでは標準導入期間を約10〜14か月と説明しているため、パッケージ名だけで短期導入と判断しないことが大切です。

見積書では開発費以外の費目を分けて確認します

初期費用は、企画・要件定義、Fit & GapやPoC、基本設計・詳細設計、画面とAPIの開発、テスト、移行、教育、稼働支援に分けて確認します。材料在庫では、ハンディ端末、バーコードプリンター、ラベル、無線LAN、棚番表示、クラウド環境、既存システムとのAPI、帳票の個別対応が別費用になることがあります。品目・仕入先・棚番・BOMのクレンジングは発注者側の作業として計上されることもあるため、担当人数と作業時間を社内で見積もります。

ランニングコストには、クラウド利用料、ライセンス、ユーザー追加、保守、問い合わせ対応、監視、バックアップ、セキュリティ対策、端末交換、通信費、法改正対応、追加改修が含まれます。初期開発費だけを比較せず、1年、3年、5年の総保有コストで比べます。クラウドは初期費用を抑えやすい一方、ユーザー数やデータ量による料金変動、API制限、契約終了時のデータ出力条件を確認します。オンプレミスはサーバー、更新、バックアップ、保守人員を含めて比較します。

安さだけでなく、失敗時の追加コストも見ます

見積額が安くても、マスタ整備、現場教育、追加の帳票、通信工事、旧システムとの二重入力が含まれていなければ、稼働後に追加費用が発生します。逆に高機能なERPを導入しても、使わない機能のライセンスや過剰なカスタマイズが負担になります。失敗しやすいのは、現場の例外をすべて個別開発で再現し、標準機能に合わせる業務改善を検討しないケースです。見積書の安さではなく、何を標準化し、何を個別対応するかを比較します。

システム停止やサイバー攻撃によって材料の払出が止まると、生産遅延や取引先への影響につながります。経済産業省は2025年4月、中小規模の製造事業者向けに、工場セキュリティの重要性と具体的な始め方を示す資料を公開し、工場の規模にかかわらずサプライチェーンを通じた攻撃への対策が必要と説明しています(出典:経済産業省「工場セキュリティの重要性と始め方」、2025年4月)。見積比較では、MFA、権限分離、通信暗号化、操作ログ、バックアップ復元テスト、脆弱性対応、障害時の手入力と再同期まで確認します。

材料在庫管理システムの見積もりを取る際のポイント

材料在庫管理システムの見積もりポイント

見積もりの精度は、依頼内容の具体性で決まります。「材料在庫を見える化したい」だけでは、在庫照会だけなのか、入出庫や棚卸まで含むのか、購買や生産計画と連携するのかが判断できません。複数社に同じ条件を渡し、標準機能、個別開発、発注者作業、前提条件、除外項目を分けて提出してもらうと比較しやすくなります。

RFPには材料特有の判断項目を入れます

RFPには、対象拠点、倉庫、材料・部品・仕掛品・支給品・端材の区分、品目数、ユーザー数、月間の入出庫件数、単位、ロット・製番・期限、検査状態、保管条件、棚番、BOM、発注点、安全在庫、製造指図への引当、余剰返却、廃棄、棚卸を記載します。重量・長さ・個数の換算や、切断後に発生する端材の再利用など、一般的な在庫管理では表現しにくい業務は具体例を添えます。

連携要件には、会計、販売、購買、受発注、生産管理、WMS、MES、PLM、EDIとの接続方式、連携頻度、エラー時の再送、データの正とするシステムを記載します。非機能要件には、利用時間、同時接続、応答時間、工場ネットワーク、クラウドまたはオンプレミス、バックアップ、復旧目標、権限、ログ、脆弱性対応、契約終了時のデータ返却を入れます。これらを省くと、初期見積もりでは安く見えても、後から追加要件になりやすいです。

開発会社は業務理解・移行支援・保守体制で比較します

開発会社の選定では、製造業や材料在庫の導入実績を確認します。導入社数だけでなく、自社と似た生産形態、材料の単位、ロット・製番、端材、複数拠点、既存システム連携の事例があるかを尋ねます。可能なら、導入前の課題、現場の変更点、移行方法、稼働後のKPI、追加費用の発生要因まで聞きます。成功事例だけでなく、失敗した場合のリカバリー方法を説明できる会社は、リスクの見積もりも現実的です。

契約前には、プロジェクト責任者と現場担当者の役割、会議体、課題管理、仕様変更の承認方法、遅延時の扱い、検収条件、瑕疵対応、保守の受付時間を確認します。スクラッチ開発では、ソースコード、設計書、DB定義、API仕様、テスト結果、移行スクリプトの所有権と引き渡し条件も重要です。パッケージやSaaSでは、設定情報、帳票、連携データ、契約終了時のエクスポート形式を確認します。

工場のシステムは、事務系ネットワークだけでなく、設備やハンディ端末、ラベルプリンター、外部の仕入先とも接続します。業務ネットワーク、制御系、外部接続をどう分離するか、端末を誰が管理するか、通信断時にどう作業を続けるかを、情報システムと現場で決めます。権限は購買、倉庫、製造、品質、管理者に分け、棚卸調整や保留解除など影響の大きい操作には承認を設けます。

発注、請求、検収、電子の取引証憑を扱う場合は、経理・法務と保存要件を確認します。2026年1月1日から、下請法は中小受託取引適正化法、通称「取適法」へ移行しており、取引条件や支払に関する記録の扱いを見直す機会になります(出典:中小企業庁「2026年1月施行!〜下請法は取適法へ〜」、2026年)。材料在庫システムだけで法対応が完結するわけではありませんが、発注・検収・支払記録をどのシステムで正として保存するかを要件に含める必要があります。

見積依頼時には、セキュリティ診断、脆弱性対応、SBOMの有無、委託先の再委託範囲、データ保管地域、バックアップ世代、復元テスト、事故発生時の連絡時間を質問します。材料在庫を扱うシステムは、生産停止や取引先への供給にも影響するため、安さだけでなく、障害時の事業継続まで含めて発注先を評価します。

よくある質問(FAQ)

材料在庫管理システムに関するよくある質問

最後に、導入前によく寄せられる質問へ回答します。費用や期間は企業ごとの条件で変わるため、ここでは判断の基準と、見積もり時に確認すべき前提を示します。

材料在庫管理システムの開発費用はいくらですか?

在庫・入出庫中心の小規模クラウド型なら初期費用10万〜100万円、生産管理パッケージの標準導入なら200万〜800万円、連携や個別要件を含む場合は500万〜2,000万円程度が目安です。材料の種類、拠点数、ユーザー数、ハンディ台数、マスタ移行、BOM・MRP、ロット・端材管理で変動するため、公開価格や類似案件のレンジとして捉え、同じRFPで複数社に見積もりを依頼します。

開発から稼働までどのくらいかかりますか?

在庫・棚卸だけの標準的な導入なら1〜3か月、生産管理パッケージの標準導入なら3〜6か月、複数システム連携や個別開発を含む場合は6〜12か月程度が目安です。公開情報では、TPiCS-Xの標準導入期間が約10〜14か月とされています。要件整理、マスタクレンジング、現場テスト、教育を短縮しすぎると、稼働後に在庫差異が増えるため、機能の規模だけでなく、発注者側が割ける時間も期間に含めて判断します。

クラウドとオンプレミスはどちらを選ぶべきですか?

標準業務で複数拠点を早くつなぎ、自動更新やバックアップを利用したい場合はクラウドが候補になります。工場内の設備や既存サーバーとの接続、通信断時の継続運用、データ配置を重視する場合はオンプレミスやハイブリッドが候補になります。どちらが安いかを先に決めず、5年間の利用料、保守、通信、端末、バックアップ、障害対応、契約終了時のデータ移行を合算して比較します。

AI需要予測は最初から導入すべきですか?

最初から必須にする必要はありません。品目、単位、在庫実績、発注実績、リードタイム、季節性が標準化されていないと、予測結果を現場が信頼できないためです。まず入出庫と棚卸を正確に記録し、欠品、滞留、緊急購買の原因を説明できる状態にしてから、需要予測や異常検知を小さく試す進め方が安全です。

まとめ

材料在庫管理システム開発のまとめ

材料在庫管理システムの開発は、在庫を見える化する画面を作ることから始めるのではなく、材料の定義と入出庫のルールをそろえることから始めます。要件整理では、材料・部品・仕掛品・支給品・端材を分け、現物・現場台帳・基幹在庫の三者を一致させる業務フローを作ります。選定では、実データによるFit & Gapと小規模なPoCを行い、標準化する業務と個別開発する業務を切り分けます。

6フェーズを区切り、最初の一歩を小さく始めます

進め方は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズです。費用は小規模クラウド型で10万〜100万円、生産管理パッケージの標準導入で200万〜800万円、連携や個別要件を含むと500万〜2,000万円程度が目安ですが、公開価格や類似案件からの推定レンジです。発注前には、移行、教育、端末、連携、保守、セキュリティ、5年TCOを含めた見積条件をそろえます。

まずは1拠点、代表的な材料グループ、棚卸と入出庫など、効果を測りやすい範囲から始めます。導入後は棚卸時間や在庫差異率だけでなく、欠品、緊急購買、滞留、廃棄、払出入力時間を継続的に確認し、データが整った段階で購買自動化やAI活用へ広げます。材料の現場を理解し、要件整理から定着まで伴走できる開発会社と進めることが、システムを使われ続ける状態につながります。

次のアクションを社内で決めます

次に行うことは、代表的な材料10〜20品目の選定、現場の入出庫フローの観察、現行マスタの表記揺れ確認、導入前KPIの計測、候補会社への同一条件での相談です。最初から全社の業務を変えようとせず、材料が見つからない、重複発注する、欠品で製造が止まるといった最も大きな課題から対象にします。小さく検証して現場の納得を得ることが、全社展開の判断材料になります。

▼全体ガイドの記事
・材料在庫管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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