センサーデータ管理システム開発の発注/外注/依頼/委託方法について

センサーデータ管理システムは、要件整理、提案比較、PoC、本番開発の順で発注すると進めやすくなります。

段階を踏めば、予算超過や現場での未活用を抑えられます。全体像は、センサーデータ管理システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・センサーデータ管理システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

センサーデータ管理システムを発注する前に知る全体像

センサーデータ管理システムは、計測値を集めるだけでなく、どの設備のどのセンサーが、いつ、どの単位で取得した値かを管理し、保全や品質管理、省エネ、遠隔監視につなげる仕組みです。

発注範囲をアプリ開発だけに絞ると、設置工事や通信、データ品質、運用担当者の作業が後から加わります。その結果、予算と納期が膨らみやすくなります。

発注対象の広がり

発注対象は五つの領域に分かれます。既存システムとの連携や運用支援も、そのひとつに含まれます。

• 現場機器：センサー本体、電源、設置金具、校正、交換品が対象です。
• 通信・ゲートウェイ：MQTT、HTTP、OPC-UA、Modbus変換、IoT SIM、エッジPC、通信断時の一時保存を扱う範囲。
• データ基盤：時系列DBへの蓄積、欠損・重複・異常値、単位、保存期間、バックアップの取り決め。
• 画面・通知：設備別トレンドや拠点一覧の画面と、閾値超過、急変、通信断、電池残量低下の通知。
• 連携・運用支援：MES、ERP、保全チケット、チャット、CSV、APIの連携先ごとに、担当会社と受け持つ範囲、導入後の運用支援をRFPに記します。

最初に決めるのは機能ではなく業務目的

「センサーを増やして見える化したい」という要望だけでは、発注先は構成も費用も算出できません。そのため、温度逸脱を何分以内に検知するか、設備停止の原因調査を何時間短縮するかを、先に決めておきます。

目的は、異常通知や予防保全、品質証跡などから一つか二つに絞ります。そのうえで、成功指標を数値で表します。省エネや遠隔監視なども候補に入ります。

• 通知の速さ：アラートから担当者の確認までの時間を測ります。
• データ品質：通信断の検知率や欠損データの割合を追います。
• 業務の変化：点検記録の作成時間や設備停止時間。

発注側は、電力原単位を比べる単位も決めておきます。

AIによる予知保全を初期から必須にすると、学習データの整備や誤検知の検証に時間がかかります。そこで、まず閾値通知とデータ品質を改善し、効果を確かめてから異常検知へ進む方法が現実的です。

発注先には、クラウドへデータを送る力だけでなく、現場でデータを整え、既存の業務データと結び付ける力も求めます。たとえば、日立は2025年、たけびしのデバイスゲートウェイと連携する製品トレーサビリティソリューションを発表しました（出典: 日立「Hitachi Intelligent Platformとたけびし社デバイスゲートウェイの連携」、2025年）。

この仕組みは、PLCやセンサーなど170シリーズ以上からOTデータを集め、ERPやMESのITデータと統合します。

さらに、AWSも2025年にMQTT対応のSiteWise Edgeゲートウェイを一般提供しました（出典: AWS「MQTT enabled SiteWise Edge gateways」、2025年）。同社は、エッジでのストア・アンド・フォワードや、MES・ERPデータとの連携を示しています。

こうした動向を踏まえ、RFPでは、複数メーカーの機器が混在する環境や通信断、エッジ処理を評価項目にします。既存業務データとの連携も、同じく評価の対象にします。

発注形態の選び方と、パッケージ・一括委託・部分外注の違い

発注形態には、パッケージやクラウドの導入、一括委託、自社主導の部分外注があります。最適な形態は、既存設備や社内のIT・OT人材、独自業務の多さで変わり、センサーの台数だけでは決まりません。

導入後に自社で変更したい範囲も、発注形態を選ぶ判断材料です。

パッケージ・クラウド中心と向く企業

パッケージやクラウド中心の場合は、標準機能との適合、検証の進め方、継続費用をあわせて確認します。

• 標準機能：設備台帳、トレンド、閾値アラート、ユーザー権限などが標準機能に収まれば、開発量を小さくできます。
• 小規模PoC：短期間で画面の利用状況や通知の効果を確かめてから、本番へ広げられます。
• 利用条件：月額料、データ量課金、保存期間による増額、仕様変更、データ出力の可否。
• 追加開発：標準機能と追加開発の範囲をRFPで分け、個別改修が常態化するのを避けます。

SIerへの一括委託と向く企業

複数の領域をまとめる利点と、契約前に決めておく責任範囲を分けて確認します。

• 窓口一本化：センサー設置、PLC接続、ネットワーク、クラウド、画面、既存連携、教育、保守を、一社または主契約者にまとめて頼めます。
• 一貫した展開：IoTやOTの専門人材が少なくても、現地調査から設計・施工、運用引き継ぎまで頼め、複数工場の標準構成と拠点ごとの差分も管理できます。
• 成果物と権利：データ所有権、API・CSV出力、構成図、データ辞書、運用手順書、再委託先の確認項目。
• 責任分界：不要機能や製品依存を避け、障害時の一次窓口と各社の役割を明文化します。

特に、提案をそのまま採用すると、不要な機能や特定製品への依存が入り込むおそれがあります。

自社主導の部分外注と向く企業

自社と委託先の担当範囲、向いている条件、統合時の注意を分けて見ておきます。

• 自社で担う領域：目的、データ辞書、業務フロー、優先順位を決め、変換や画面開発は外注に任せます。
• 適する企業：設備や業務に詳しく、拠点追加や画面変更を内製したい企業。
• PoCの分担：要件が未確定の場合はデータ収集を専門会社に任せ、評価と業務設計は自社で行う形です。
• 統合負担：接続・障害再現試験とログ保管の共通化。

自社が担えるプロジェクト管理と運用保守の範囲も見積もり、発注形態を選ぶ段階で確認します。

試験条件と記録先をそろえておけば、通信断やデータ欠損が起きたときに、委託先同士が責任を押し付け合う事態を防げます。

RFPと要件整理で発注前に決めるべき項目

RFPは、各社が同じ前提で見積もりと提案を出すための比較資料です。「良い提案をしてください」と頼むだけの文書とは違います。

完璧な仕様書は要りません。ただし、対象範囲や現状の課題、制約をそろえ、希望時期と評価基準も同じ条件で示します。要件が曖昧なまま価格を比べると、後から追加費用が発生しやすくなります。

目的・KPI・対象範囲のまとめ方

見積もりの条件をそろえるには、対象範囲とデータ量の前提を決めておく必要があります。

• 導入目的：対象の拠点・設備・部門、課題、導入後の判断基準。
• 設備情報：メーカー、型式、設置場所、既存PLCの有無、利用可能なプロトコル、データ保存方法を示します。
• データ条件：センサー台数、計測周期、1日のデータ量、保存期間、必要なリアルタイム性をそろえます。

センサーを新設するか既設の値を使うかで、現地調査と費用が変わります。

「100台から1分ごとに取得し、明細を3年間保存する」のように、数値で書きます。さらに「異常値は5分以内に通知する」と書けば、通信量や保存、通知処理を見積もれます。

PoCと本番で台数が違う場合は、初期の範囲と将来の拡張を分けて書きます。

データ項目・品質・連携要件の定義

データ項目と品質管理を定めます。障害時の扱いや既存連携の要件も、RFPに書いておきます。

• データ辞書：センサー・設備・拠点のID、取得・受信時刻、単位、校正日、品質フラグ。
• 欠損・補正：通信断後は再送か欠損扱いかを決め、重複や異常値を自動で補正する場合は、元データと補正履歴を監査ログに残すかを決めます。
• 連携仕様：連携先、方向、頻度、方式、再送、担当者、MES・ERPとの用途。
• 未確定API：調査工程を見積もらせ、仕様確定後の開発費の変動も示してもらいます。

たとえば、端末ごとに時刻がずれると、複数センサーの相関分析や原因調査に使えません。

MESから設備マスターを受け取り、システムからKPIを返すか、ERPの製造指図と測定履歴をひも付けるかで、設計が変わります。

RFPに含めるセキュリティと運用

工場のOTネットワークをクラウドへつなぐ場合は、その対策をRFPに含めます。また、機器のライフサイクルや個人情報、委託先管理も対象にします。

• 接続対策：ネットワーク分離、デバイスごとの認証、TLSなどの暗号化、初期パスワードの変更、最小権限の設定。
• 機器管理：脆弱性対応、ログ監視、バックアップと復旧試験、交換時の認証無効化を決めておきます。
• 個人情報：位置や個人に結び付く稼働状況を扱う場合の、個人情報保護法上の取り扱い、利用目的、保存期間、アクセス権限。
• 委託先条件：再委託、事故報告時間、脆弱性修正の期限、監査協力の範囲。

加えて、廃棄時のデータ消去やファームウェア更新も決めておきます。IPAは、2025年9月公開の「IIoT機器ライフサイクル管理構築手引き」で、導入から廃棄までの管理を整理しています。

契約形態と委託範囲の決め方：請負・準委任・段階契約

センサーデータ管理システムは、現地調査を終えるまで設備や通信の条件が確定しないことがあります。そのため、最初から全体を固定価格の請負にするより、調査、要件定義、PoC、本番開発を分けたほうが、変更の理由と費用を説明しやすくなります。

契約形態の違いを踏まえて、工程ごとに成果物と責任範囲を決めます。

成果物と完成条件が明確な場合の請負契約

請負では、完成条件と検収のシナリオを合意します。変更時の扱いや費用の範囲も、あわせて決めます。

• 契約の適合性：成果物の完成と検収を約束する契約で、要件が固まった本番開発に合います。
• 検収条件：画面表示に加え、指定周期の受信、復旧後の再送、指定時間内の通知まで試す。
• 変更管理：設備追加や仕様変更の手順、追加単価、納期への影響、瑕疵対応期間。
• 費用と障害：第三者サービス障害時の扱いと、センサー・クラウド費の請求区分。

検収条件に実際の業務シナリオを含めると、完了後の予算管理にもつながります。

調査・要件定義・PoCに向く準委任契約

準委任は、調査や設計を進めながら要件を具体化していく工程に向いています。

• 対象工程：現地調査、PLC接続の確認、データ辞書の設計、PoC評価、運用設計。
• 合意事項：調査内容、納品資料、会議体を定めるもので、本番稼働までは約束しません。
• 工数管理：月次報告、消化工数、残課題、次月の予定、追加作業の承認手順を設けます。
• 発注者の体制：ヒアリング、現場立ち会い、データ提供、迅速な意思決定を発注側が担います。
• 相場の目安：請負は準委任の1.3〜1.5倍になる場合もありますが、条件によって変わります。

近接領域の倍率は一律に当てはめず、契約内容とリスク分担を見て比べます。

段階契約による不確実性と追加費用の管理

不確実性を段階ごとに確かめるため、調査から保守までを工程に分けて契約します。

1. 現地調査・企画：設備とネットワークの制約を確かめます。
2. 要件定義・PoC：代表ラインの欠損率や通知の有効性を検証します。
3. 本番開発：KPI、予算、現場での受け入れやすさ、セキュリティ審査を基準に、着手の可否を判断します。
4. 展開・保守：本番後の展開と運用を引き継ぎます。

判断基準を設けておくと、効果の見えないPoCを惰性で広げずに済みます。

次工程へ進まない場合に備えて、データや設定、成果物の返却、クラウドの停止、センサーの扱いも決めておきます。

PoCのデータ辞書や接続アダプターを本番へ引き継げるかを確認します。全体構成と拡張方針を初期から共有しておけば、検証を使い捨てにせずに済みます。

センサーデータ管理システムの費用相場と見積内訳

費用はセンサー台数だけでは決まらず、計測周期や既存設備との接続数、拠点数で変わります。通信断への対応や保存期間、画面や業務連携の複雑さも影響します。

ここで示すのは、リサーチノートにある近接領域の業務システム相場を基に、センサー、ゲートウェイ、通信を加えた推定レンジです。個別案件の確定価格ではないため、RFPの前提と合わせて比べてください。

PoC・本番・全社展開別の初期費用

初期費用の推定レンジは、PoC、本番、複数工場への展開で異なります。

標準クラウド中心なら数週間〜3か月、スクラッチ開発や全社展開なら半年〜1年以上かかる場合があります。PoC期間は1〜3か月程度ですが、入場手続きや設備停止があれば長くなります。

• 小規模PoC：1拠点・10〜100台、簡易画面と閾値通知で300万〜800万円程度です。
• 本番導入：1〜数拠点・100〜1,000台で800万〜2,000万円程度が推定幅です。
• 複数工場：統合や冗長化を含む展開では2,000万〜5,000万円以上の可能性があります。

PoCに現地調査やゲートウェイ設定、クラウド初期構築、データ項目の定義、接続試験を含めると、センサー価格だけでは収まりません。さらに、本番では、権限や履歴、帳票・API、既存設備や保全システムとの連携を含む場合があります。

複数工場では、エッジの冗長化やOT・MES・ERPの統合が費用を大きく左右します。加えて、監視、教育、予兆検知の範囲も費用に響きます。

センサー・通信・クラウド利用料と開発費の区分

機器、通信、クラウドの料金は、初期費や開発費と分けて見積もります。小さな値を高頻度で送る場合は、Azure IoT Hubのメッセージ数も試算します。

• 機器費：センサー、ゲートウェイ、電源、金具、配線、防水・防爆対応、校正、交換ごとの内訳。
• センサー：1台5,000円〜10万円超まであり、屋外・高温・防爆・高精度などで変わります。
• ゲートウェイ：一般構成は1拠点5万〜30万円程度ですが、冗長化等で上振れします。
• 通信・クラウド：通信料は周期とデータ量で変動し、通信以外の費用は別に見積もります。

SORACOM Airの日本カバレッジIoT SIMは、2026年8月確認時点で500MB込みのプランが月385円です。超過分は500MBあたり110円、初期費用は1枚990円です（出典: SORACOM Air公式料金、2026年）。この通信料には、クラウドや監視、アプリ開発、保守は含まれません。

Azure IoT HubのBasic・Standardは、課金対象操作を4KB単位のメッセージで計測します（出典: Microsoft Learn「Azure IoT Hubの課金情報」、2026年更新）。

ランニングコストを左右する保守・監視・保存期間

ランニングコストは、クラウドの内訳、保守体制、契約期間を分けて見積もります。24時間365日の監視か、営業時間内の対応かによって、必要な体制と費用が変わります。

• クラウド料金：取り込み、処理、保存、バックアップ、ログ、通知、通信、分析の各費用。
• 保守内容：監視、問い合わせ、交換、設定変更、脆弱性修正、復旧試験、教育の範囲。
• 契約・総額：対応時間と各費目を分け、保存延長も含む3年程度の総保有コストで比べます。

AWS IoT SiteWiseの公式例では、10設備が毎秒1測定を送る場合、SiteWise部分は月39.48米ドルです（出典: AWS IoT SiteWise Pricing、2026年確認）。これは特定サービス部分の例で、IoT接続や監視、通知、転送、開発会社の保守費は含まれません。

発注側は、初期費用、月額固定費、従量課金、現地対応費、追加開発費を分けて提示してもらいます。

委託先選定と見積比較で確認するポイント

委託先は、知名度や提示価格だけでなく、センサーデータを業務で使える状態まで届けた経験で比べます。設備の停止制約や保全業務を理解していないと、稼働後に使われないおそれがあります。

同じ条件のRFPを複数社へ渡し、提案の前提や除外項目を含めて評価します。体制や保守も、同じ基準でそろえます。

実績の確認項目：センサーの種類と運用範囲

実績を見るときは、技術条件や事例の中身、参加体制、継続要員を確認します。

• 技術条件：業界、台数、拠点、計測周期、プロトコル、通信断対策、PLC・MES・ERP連携を聞きます。
• 導入事例：可能なら似た設備条件の事例で、課題、PoCから本番への条件、現場定着策、改善指標を見ます。
• 説明可能性：社名を出せない事例を、規模と技術条件を匿名で説明できるかどうか。
• 担当体制：設計、現地調査、クラウド、保守の担当者と、再委託先の役割・判断者。
• 継続性：工程ごとの体制と要員の継続性。PoCだけを担った会社が、本番の大量展開や24時間監視まで担えるとは限りません。

工程・数量・単価・前提条件に分けた見積書

見積書で確認するのは、工程別の内訳、除外項目、将来拡張費です。

• 工程内訳：調査、要件定義、設計、機器、通信、クラウド、開発、テスト、設置、教育、保守に分けた内訳。
• 比較項目：数量、単位、期間、単価、担当者、納品物を記し、「一式」と書かれた項目は内訳を求めます。
• 除外項目：夜間作業、足場、電源、校正、回線、本番アカウント、移行、審査、教育が含まれるか。
• 拡張費用：100台から1,000台への追加単価、拠点追加、保存期間延長の費用。

選定基準に含める運用・セキュリティ・撤退条件

データの継続利用、運用時の対応力、PoCの終了条件を、選定基準に入れます。

• データ継続性：所有権、出力、終了時の返却、クラウド移行支援。
• 運用・安全性：脆弱性への対応、障害通知、復旧目標、バックアップからの復元。
• PoCと撤退：取得率、欠損、確認時間、作業削減、停止予防を測り、終了時の成果物と費用を決めます。

機器が増えるほど、認証情報やファームウェア管理の扱いが問われます。IPAのIIoT手引きに沿って、導入、運用、更新、廃棄まで評価できる会社を選びます。

効果が出なかった場合に、何を残し何を止めるかを決めておくと、撤退しやすくなります。加えて、継続的に改善できる責任体制も選びます。

発注から導入・運用開始までの進め方

要件定義が終わるまで現場を待たせず、早い段階で代表設備のデータを確かめながら進めます。

たとえば、センサー値、既存設備への負荷、通知の判断しやすさを先に検証すると、本番開発の手戻りを減らせます。

RFP配布・提案比較・PoCによる発注先の絞り込み

発注先を絞る工程は、次のとおりに進みます。

1. 現場、情報システム、設備保全、品質、調達、セキュリティの関係者で、要件を確認します。
2. 同じRFPを複数社へ配布し、質問期限、提案書式、見積内訳、プレゼン評価項目をそろえます。
3. 機能の充足度、前提条件の妥当性、現地調査の深さ、運用への配慮、総保有コストを比べて候補を選びます。
4. 代表ラインや一部拠点でPoCを行い、データと現場業務の変化を測ります。
5. 評価に合格したら、対象台数、追加連携、運用体制を確定して本番契約へ進みます。

PoCでは、画面の見栄えより、計測値の欠損や通信断からの復旧、通知の適中率、担当者の確認時間を測ります。加えて、データを使った会議や点検の変化も評価します。

通信断・異常値・権限を含む実条件でのテスト

受入テストでは、実際の障害や権限、現場条件、展開後の運用まで確かめます。

• 異常時の動作：通信・電源断、再起動、交換、時刻ずれ、欠損、重複、異常値、閾値境界。
• データ復旧：通信断時のエッジ保存、復旧後の時刻順の再送、二重集計の防止、CSV出力、バックアップの復元。
• 安全と権限：設備停止時の安全手順と時間帯、拠点・設備ごとの閲覧制限、操作ログ。
• 段階展開：一部現場で通知や指標を調整し、手順書と連絡先を用意します。

全拠点へ広げる前に、センサーの交換手順と月次のデータ品質確認も準備しておきます。

検収条件に含める納品物と運用引き継ぎ

納品物と運用の分担、定例確認を、検収条件に含めます。

• 納品資料：要件定義書、構成・ネットワーク図、センサー台帳、データ辞書、API、設定、テスト結果。
• 運用手順：障害、バックアップと復旧、ユーザー管理の手順を受け取り、追加作業の担当範囲を決めます。
• 定例確認：欠損、通信断、通知、対応時間、クラウド費、故障、権限、業務KPIを追跡します。

発注先だけが設定を理解している状態だと、担当変更や拠点追加のたびに費用がかかります。そこで、自社の担当が設備やセンサーを追加する範囲と、委託する範囲を決めておきます。

通知が多すぎれば閾値や担当者を、少なすぎれば検知条件を見直します。また、効果は稼働率だけでなく、点検時間や停止時間、品質逸脱、エネルギー原単位などの業務KPIで追います。

よくある質問（FAQ）

発注時によくある疑問を取り上げます。機器費と開発費の区別、PoCの必要性、相見積もりの条件を確認しておくと、発注後の認識のずれを抑えられます。

センサーデータ管理システムの発注費用はいくらですか？

要件未確定時の推定レンジは、小規模PoCで300万〜800万円、本番の1〜数拠点で800万〜2,000万円です。複数工場や全社展開では2,000万〜5,000万円以上です。

金額は、センサーや設置工事、ゲートウェイをどこまで含むかで変わります。通信とクラウドの費用、開発、連携、保守も含めて、前提条件と内訳を比べてください。

センサーデータ管理システムはPoCから始めるべきですか？

既存設備が多い、通信条件が不明、現場がアラート運用に慣れていない場合は、代表ラインでPoCを行うことをおすすめします。

データ取得率や欠損、通知の適中率、担当者の対応時間、業務KPIの変化を確認し、本番化の条件を決めます。ただし、標準機能で要件が明確な場合は、限定拠点への短期導入をPoCの代わりにする方法もあります。

相見積もりでは何社に依頼し、何をそろえるべきですか？

3社前後を目安に、同じRFPを渡します。対象設備、台数、計測周期、保存期間、連携要件、希望時期もそろえると、比べやすくなります。

価格だけでなく、現地調査の有無、標準機能と追加開発の区別、除外項目、保守体制、データの持ち出し、障害時の責任分界も確認します。提案の前提が違う場合は、安いほうを選ぶ前に、同じ条件での再見積もりを頼みます。

工場のセンサーデータをクラウドに置いても安全ですか？

安全性は、クラウドかオンプレミスかよりも、ネットワーク分離や暗号化、デバイス認証で変わります。権限やログ、更新、バックアップと復旧、委託先の運用によっても変わります。

OTネットワークからクラウドへ送るデータを絞り、通信断時はエッジで保持する構成も検討します。個人にひも付く位置情報や作業状況を扱う場合は、利用目的とアクセス権限を整理し、委託先との契約に反映します。

まとめ

発注では、アプリ機能やセンサー単価に加えて、設備や通信、データ品質を一体で整理します。通知後の業務やセキュリティ、保守も、同じ流れで扱います。

標準機能で早く検証するならパッケージ・クラウド、複数領域をまとめるならSIerへの一括委託、ノウハウを残すなら部分外注が候補です。迷う場合は、現地調査とPoCを先に委託し、その結果から本番の方式を決めます。

RFPには、目的とKPI、設備やセンサーの台数を記します。計測周期や保存期間、通信断、既存連携、権限、運用保守も、同じ文書に入れます。

見積もりは、機器、開発、クラウド・通信、現地作業、保守に分けて比べます。除外項目と将来拡張の単価も見ます。

初期の推定レンジだけで決めず、同じ前提で複数社から提案を取ります。そのうえで、PoCの評価基準と契約・検収条件を定めてから発注すれば、予算超過や未活用を抑えられます。

▼全体ガイドの記事
・センサーデータ管理システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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