設備点検管理システムの開発は、要件整理から定着までの6フェーズで進みます。
設備台帳から修繕履歴までを一つの流れでつなぎ、現場で使える最小範囲から段階的に広げるのが基本です。
紙やExcelでは点検漏れや転記ミス、履歴検索の手間が生じやすく、いきなり全拠点を作り替えると、現場に定着しないまま費用だけ増えかねません。また、2026年時点で確認できる公開料金や法定報告の注意点、見積もりで確認すべき項目は、開発を始める前に押さえておく必要があります。
▼全体ガイドの記事
・設備点検管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
設備点検管理システム開発の全体像
設備点検管理システムは、設備の基本情報や点検結果、異常、修繕の記録を設備単位で管理する業務システムです。点検結果を保存するだけでなく、「どの設備を、いつ、誰が、どの基準で点検し、異常があった場合に誰がいつ対応したか」を後から追える状態にすることが大切です。
最初に決めるべき目的と対象範囲
開発の出発点は、どの業務指標を改善したいかを決めることです。「紙をなくしたい」は手段なので、そこから目的を決めます。
- 設備台帳：設備IDや設置場所、担当の整理
- 点検記録：周期、項目、結果、証跡の記録
- 保全対応：異常と修繕履歴の結び付け
目標の例は、日常点検の実施率を上げることや、異常発見から一次対応までの時間を短くすることです。修繕履歴を設備投資計画に生かすことや、複数拠点の未対応案件を本部から把握することも、目標に挙げられます。
導入前に点検件数や未実施件数、報告書作成時間を計測しておくと、稼働後に効果を判断しやすくなります。異常対応時間や設備停止時間も、基準値として残しておきます。
対象範囲は、建物・不動産管理、工場・プラント保全、建設・設備工事のどれに近いかで変わります。たとえば建物管理では、棟・階・部屋・設備の階層や、協力会社への作業依頼、オーナー向け報告が重視されます。
工場では、設備停止や予防保全が中心になります。部品、修繕費、MTBF（平均故障間隔）やMTTR（平均修復時間）も重要です。
建設・設備工事では、現場ごとの写真や引き渡し後の保守台帳、協力会社ごとの権限分離を先に定義しておきます。
必要な機能と現場での利用イメージ
基本機能は、台帳から報告までの5つに分けて整理できます。
- 設備台帳：設備名、型式、メーカー、設置場所に加えて、導入日や重要度、保証期限を登録します。図面や取扱説明書も設備にひも付けます。
- 点検計画・チェックシート：日次・月次・年次の周期を決め、点検項目と基準値、判定方法を設定します。期限や担当者、承認者も含めます。
- 現場入力：スマートフォンなどでQRコードを読み込み、数値や判定、写真、コメントを登録すると、入力の負担を抑えられます。
- 異常・修繕管理：原因や優先度、対応期限から完了確認までを一つの案件として管理し、作業者や部品、費用も同じ案件にひも付けます。
- 報告・分析：記録をもとに、報告書の作成や集計を行えるようにします。
通信が不安定な地下設備や山間部の施設では、オフライン入力と後同期が必要です。
設備点検管理システムの価値は、帳票を電子化するだけでなく、点検から修繕完了までをつなぐ点にあります。
設備保全の最新動向としては、株式会社カミナシが2025年2月3日に「カミナシ 設備保全」を正式提供しました。
同製品は、設備台帳や故障履歴、保全計画、異常報告を設備カルテにまとめる構成で、QRコードとモバイル端末から現場で記録できます。
同社の公式発表では、ベータ版を利用した企業で記録数が従来の4倍に増えた事例も示されています。
導入効果を考えるときは、ペーパーレス化に加えて、記録件数や異常の把握率の改善もKPIに含めます。
参考にした資料は、株式会社カミナシの「工場設備の保全業務DXを実現する『カミナシ 設備保全』正式提供開始」（2025年2月3日）です。
設備点検管理システム開発の進め方
開発は、要件整理から定着まで6つのフェーズに分けて進めます。
- 要件整理
- 方式・製品選定
- 設計開発
- テスト
- 稼働
- 定着
最初から全社の完成形を作るより、重要設備を含む1拠点や1設備群などに範囲を絞り、現場で使えることを確かめてから展開するほうが安全です。
各フェーズで成果物と判断基準を決めておけば、開発会社との認識のずれを抑えられます。
1. 要件整理：業務とデータの洗い出し
要件整理では、現行の紙帳票やExcel、設備台帳などを集めます。点検周期や異常報告、修繕依頼、承認、報告書も対象です。
帳票の項目をそのまま画面に移すのではなく、設備IDを共通のキーにして、設備と点検、異常のつながりを整理します。
作業や部品、費用、添付写真も、同じ設備IDでひも付けます。
設備IDが拠点ごとに重複している場合は、既存の番号を残すか、新たに採番し直すかを、この段階で決めておきます。要件整理では、設備数や点検周期、承認者など10項目の条件を押さえておきます。
- 対象設備数と設備の階層
- 拠点数と利用ユーザー
- 点検周期と期限
- 基準値・判定区分
- 異常時の優先度とエスカレーション
- 写真・図面・取扱説明書の保存
- 承認者と権限
- 法定点検・報告様式の有無
- 既存Excelや基幹システムとの連携
- オフラインの必要性
要件会議には、現場担当者や設備管理責任者、情報システム部門、監査・安全担当を入れ、業務の例外も確認します。
2. 方式・製品選定：SaaS、個別開発、ハイブリッドの比較
標準的な点検や台帳、通知、写真、報告が中心であれば、設備保全・点検向けSaaSを優先して比べます。
独自の帳票や承認だけが課題なら、SaaSの設定変更やローコードを組み合わせる方法が候補になります。
既存のERPやBMSと深く連携する必要があり、業務ルールも独自であるときは、個別開発やハイブリッド構成を検討します。連携先は、大きく3系統に分けて洗い出します。
- 制御・監視：SCADA、PLC
- IoT：機器や設備から集めるデータ
- 購買・在庫：発注や在庫の情報
選定では、機能数の多さより、現場で1件の点検を終えるまでの操作数を見ます。
実際の設備を使ったデモで、QR呼び出しから異常写真の追加、通信断からの復旧、再点検、承認、報告書出力までを確認します。
さらに、同じ質問票で、データ移行の支援範囲やAPI仕様、SSO・多要素認証を比べます。拠点や協力会社ごとの権限、監査ログ、バックアップ、障害時の復旧目標も、質問に入れます。料金改定の条件と解約時のデータ返却も、同じ票で確認します。
3. 設計・開発：現場画面とデータモデルの確定
設計では、設備台帳、点検項目、基準値、判定、異常、作業、部品、費用を、どのデータ項目で表すかを決めます。たとえば「異常あり」を自由記述だけで登録すると、後から集計できません。
異常は、次の項目を分けて持たせます。
- 区分と重要度：異常の種類と、対応の優先度
- 発見の記録：いつ、どの設備で見つかったか
- 一次対応：最初に行った対応の内容
- 原因と再発防止：原因の記録と、再発を防ぐ対策
- 完了確認：修繕後に確認した結果
自由記述は補足として使うのが適しています。また、帳票の見た目だけでなく、将来の分析に使える粒度で設計します。
現場画面では、情報量を管理者画面に合わせず、絞ることが大切です。現場担当者向けには、設備をすぐ呼び出せる大きなボタン、必須項目だけの入力、数値の入力補助を用意します。写真撮影や前回値の参照、異常時の自動通知も、あわせて入れておきます。
設計レビューでは、ベテランだけでなく、初めて使う人が説明を受けずに点検できるかを確かめます。
開発会社には、画面一覧や業務フロー、権限一覧、連携一覧、受入条件を文書にしてもらいます。
4. テスト：異常系と現場条件の先行検証
テストでは、画面が表示されるかだけでなく、起票から修繕完了までの業務の流れを一続きで確かめます。
- 設備台帳から点検を起票する
- 期限通知を受ける
- 現場で写真と数値を登録し、異常を報告する
- 責任者が承認する
- 修繕完了後に履歴と報告書へ反映される
テストケースには、通常と異なるケースも入れます。例外の場面を、3つの面に分けて確かめます。
- 点検・写真：点検の未実施、基準値超過、写真未添付
- 承認・担当：承認差し戻し、担当者変更
- 設備と履歴：設備廃止、同じ異常の再発
現場受入テストでは、実際の端末を使い、手袋をした操作や屋外の反射、地下や工場内の通信状態を確かめます。
写真ファイルの容量やQRコードの読み取りやすさも、見ておきます。
データ移行テストでは、設備数や未完了の点検、過去履歴を検証します。添付ファイルの扱いや文字化け、重複IDも対象です。
合格条件は、「使えそう」ではなく、「日次点検を一定時間内に完了できる」「異常案件の担当者と期限が一覧で分かる」のように、測定できる形で書きます。
5. 稼働：重要設備からの段階的な切り替え
本番稼働は、全拠点を同時に切り替えるより、1拠点か1設備群を対象にしたパイロットから始めるのが向いています。
対象は、現場の協力を得やすいことに加えて、停止の影響が大きく、点検頻度が高く、効果を測りやすい設備を選びます。
開始前には、旧帳票をいつまで使うか、システムを正とする日付、入力できない場合の代替手順を決めておきます。加えて、問い合わせ窓口と、障害時の復旧連絡の方法も定めておくと、現場が迷わずに済みます。
パイロット期間は、週単位で数値を確認します。数値は、3つの面で見ます。
- 点検の進み：点検実施率、未完了案件数
- 入力の負担：1件あたりの入力時間、報告書作成時間
- 異常対応：異常登録から担当者決定までの時間
数値が改善しない場合は、すぐに機能不足と決めつけず、原因を切り分けます。設備マスタの誤りや入力項目の多さ、通知先の不明確さ、教育不足などが候補になります。
合格基準を満たしたら、設備種別や拠点を増やす順番を決めて、横展開します。
6. 定着：KPIと運用責任の設定と改善
稼働後は、システム管理者と設備管理責任者、各拠点の現場リーダーに役割を分けておきます。
問い合わせ窓口の担当も、あわせて決めておきます。
設備の新設・移設・廃止や点検項目の改定、担当者の異動、法定様式の変更は、誰が承認し、いつ反映するかを運用ルールとして決めます。
マニュアルを配るだけでなく、実際の設備を使った短時間の訓練と、現場から質問を集める期間を設けることが、定着につながります。
定着を測るKPIは、ログイン数だけでは足りません。点検や異常、報告の動きを、数値で合わせて見ます。
- 点検の実施：点検実施率、期限超過率
- 異常対応：異常報告の登録率、異常から一次対応までの時間
- 設備への影響：MTTR、設備停止時間
- 報告：報告書作成時間
- 紙の利用：紙帳票の残存数
月に1回はKPIと現場の声を確認し、不要な入力項目を削ったり、通知ルールや点検周期を見直したりして、小さな改善を続けます。
現場が入力したデータを管理者が意思決定に使う姿を見せることが、入力の意味を伝えるいちばん有効な方法です。
設備点検管理システムの費用相場とコストの内訳
費用は、設備数や拠点数、ユーザー数によって大きく変わります。既存データの状態や帳票移行、オフライン対応、外部連携の有無も、費用に響きます。そのほか、センサーや法定報告対応、導入支援の有無も影響します。
発注側は、1つの金額を相場として断定するのではなく、SaaSの公開料金と、個別開発・段階導入の推定レンジを分けて見積もります。
個別開発のレンジは、設備点検専用の統計ではなく、リサーチノートにある一般的な業務システム開発相場からの推定です。
方式別の費用レンジと期間の目安
既製クラウドやSaaSには、公開料金の例で初期費用0〜30万円程度、月額数万円〜24万円程度から始められるものがあります。
たとえば、MENTENAの公式料金ページでは、2026年8月時点で初期費用20万円のほか、10IDまで月額10万円・16万円・24万円のプランが掲載されています。ただし、オプションや追加テナント、オンボーディング、初期データ登録支援は別料金です（出典: MENTENA公式「料金プラン」、2026年8月確認）。
MONiPLATは、公式サイトでTBMについて、20設備まで月額0円、50設備まで月額1.5万円、100設備まで月額3万円と案内しています。
CBMは、設備に応じて1設備あたり月額1.5万円程度または3.5万円程度の例が示されています。TBMとCBMのいずれも、契約条件や対象機能は個別に確認が必要です（出典: MONiPLAT公式サイト、2026年8月確認）。
開発の種類ごとに、費用の目安は3通りに分かれます。
- PoCや小規模パイロット（検証・開発・調整を含む）：50万〜300万円程度
- 本番パイロット：300万〜1,500万円程度
- 独自業務や複数連携を含むスクラッチ開発：300万〜2,000万円程度
これらは、一般的な業務システム開発から推定した幅です。確定した価格ではなく、範囲や品質、連携条件を含めて見積もるための初期の目安です。
要件定義から本番までの期間は、SaaSの設定や移行なら数週間〜3か月程度、個別開発なら6〜18か月程度が目安です。
複数拠点、IoT、ERP、データ基盤まで統合する場合は、1,500万〜5,000万円程度、13〜36か月程度の大規模な計画になる可能性があります。（個別開発・PoC・全社展開のレンジは設備点検専用統計ではなく、一般的な業務システム開発相場からの推定です。）
初期費用・月額費用・追加費用の分け方
初期費用には、要件整理や環境設定、画面や帳票の設定、設備マスタの登録が含まれます。さらに、既存Excelからの移行や権限設定、教育、テスト支援も含まれます。
月額費用には、利用IDや設備数、拠点数、データ容量のほか、サポートや基本的なアップデートが含まれることが多いです。
契約時は、初期費用にデータ移行が含まれるのか、含まれるなら何行・何ファイルまでかを確認します。
追加IDや追加拠点の単価も、あわせて聞いておきます。
追加費用が生じやすいのは、個別の帳票や外部との連携、認証まわりの機能です。
- 帳票・連携：個別帳票、CSV・API連携
- 認証・接続：SSO、多要素認証、閉域接続
- 現場機能：オフライン機能、センサー・ゲートウェイ
- データ：初期データのクレンジング
- 教育・運用：現地教育、運用代行
クラウドの月額だけで比べると、導入初年度の実費を見誤るおそれがあります。そのため、初年度の総額は「初期費用＋12か月分の基本料金＋追加ID・拠点＋移行・教育＋連携・センサー」の形で並べます。
2年目以降の運用費は別に示すと、SaaSと個別開発を公平に比べられます。
費用対効果は、削減できる入力や報告の時間、点検漏れの抑制、異常の早期発見の面から評価します。さらに、設備停止の回避や修繕の優先順位付け、監査対応の短縮も、評価の対象に入れます。
たとえば、1回の点検で削減できる入力時間に、月間の点検回数と人件費単価を掛けます。さらに、報告書作成や異常対応の短縮分を足します。
故障回避による効果は不確実性が大きいため、期待値として扱い、複数のシナリオで試算します。
設備点検管理システムの見積もりを取る際のポイント
見積もりの精度は、発注前に業務とデータをどこまで具体化できるかで決まります。「設備点検を効率化したい」といった段階では、会社ごとに想定する範囲が違います。そのため、安く見える見積もりでも、後から追加費用が発生しがちです。
RFPや要件メモには、対象範囲や優先順位、現状データ、非機能要件、導入時期、受入条件を記載します。そのうえで、同じ資料を複数社に渡します。
RFPに入れるべき要件チェックリスト
RFPには、設備数や拠点数、利用者の役割、同時利用の想定を書きます。対象端末や対応OS、通信環境、既存の設備台帳、紙・Excel帳票のサンプルも添付します。
機能面では、次の機能を「必須」「できれば」「将来」に分けます。
- 現場入力：QR・バーコード、写真・動画
- 点検の流れ：定期点検の自動起票、再点検、承認
- 判定と優先度：基準値判定、異常の優先度
修繕と部品、費用も、同じ3区分で整理します。そのほか、帳票出力やダッシュボード、CSV、APIの要否も書き出します。
非機能要件は、機能と同じくらい欠かせません。稼働時間やレスポンス、オフライン利用、バックアップ頻度、復旧目標を示します。さらに、データ保存期間や暗号化、MFA・SSO、権限、操作ログも含めます。加えて、脆弱性対応や障害通知、サポート時間、データ返却形式も記載します。
法定点検が関係する場合は、対象設備や点検資格者、報告先、自治体の様式、提出方法を明記します。様式が改定されたときの対応責任も、あわせて書いておきます。
複数社を比較するときの評価基準
比較先には、受託開発会社だけでなく、設備保全・点検SaaSのベンダーも含めます。ただし、製品を提供する会社と、要件定義から個別開発する会社では責任の範囲が異なります。同じ表で並べるときは、提供方式を明示します。
評価軸は、対象業種や設備の実績、現場入力のしやすさを中心に見ます。そのほかの観点も、同じ表で並べて比べます。
- 移行と機能：データ移行、標準機能とカスタマイズ
- 連携：API・ERP・BMS・IoT連携
- 権限と運用：権限・監査ログ、サポート
- 料金と定着：料金の透明性、導入後の定着支援
候補会社には、実データに近い設備を使ったシナリオデモを依頼します。一連の操作として、「設備を登録する」「点検を起票する」「現場で写真を付けて判定する」「異常を担当者へ割り当てる」「修繕完了を承認する」「月次報告を出す」を見ます。機能一覧だけでは分からない差は、ここで見えてきます。
契約前には、デモでできなかった機能を、追加開発するのか、運用で代替するのか、将来対応とするのかを書面で分けておきます。
法定点検・セキュリティ・連携のリスク確認
建物の設備点検では、建築基準法第12条の定期報告制度と、一般的な保守点検を区別して考える必要があります。国土交通省によると、この制度は、建築物や建築設備、防火設備、昇降機などを対象に、所有者や管理者が経年劣化などを点検し、特定行政庁へ報告する仕組みです。
システムは、資格者による調査・検査や報告責任を代替するものではありません。2025年7月1日施行の告示改正もあるため、様式の版管理や自治体ごとの提出方法、報告期限を確認できる設計にします。
点検記録には、設備の構成や写真、異常、修繕費などの重要な情報が含まれます。そのため、通信やデータ、権限の保護が欠かせません。保護は、通信や保存データ、利用者ごとに分けて考えます。
- 通信：TLS
- 保存データ：暗号化
- 管理者：多要素認証かSSO
- ユーザー：最小権限
- 協力会社：拠点や案件単位の権限
ログインや設備情報の変更、点検結果、承認、帳票出力は、監査ログに残します。
バックアップからの復旧テストも行います。
クラウドの安全性評価として、ISMAPの掲載状況を参考にする場合でも、自社のデータ分類や復旧時間、委託先管理の要件は別に確認します。
（出典: 国土交通省「建築基準法に基づく定期報告制度について」「オンラインを活用した定期報告について」、2026年8月時点で確認できます。）
設備点検管理システム開発でよくある質問（FAQ）
最適な進め方は、対象業務や既存データの状態によって変わります。開発前によく質問される費用や導入期間、法定点検、Excelやオフライン利用について、順に答えます。
設備点検管理システムの開発費用はいくらですか？
公開料金のあるSaaSでは、初期費用0〜30万円程度、月額数万円〜24万円程度から始まる例があります。
個別開発は、対象範囲や連携によって300万〜2,000万円程度の幅になることがあります。ただし、これは設備点検専用の統計ではなく、一般的な業務システム開発の相場からの目安です。
設備数やID数、帳票移行、センサー、API、教育を分けて見積もると、必要な予算を判断しやすくなります。
導入・開発には何か月かかりますか？
SaaSの設定とデータ移行だけなら数週間〜3か月程度、個別開発なら要件整理から本番まで6〜18か月程度が一つの目安です。拠点数や連携、法定帳票、データのクレンジング、現場教育が増えるほど、期間は長くなります。
全社一斉導入の期限から逆算するより、まずパイロットで4〜12か月程度の本番運用を経験し、改善点を取り入れてから横展開する計画が現実的です。
システムを導入すれば法定点検や報告を自動化できますか？
システムは、点検計画や記録、期限通知、帳票作成を支援できます。ただし、資格者による調査・検査や、所有者・管理者の報告責任を代替するものではありません。
まず、建築基準法第12条の対象かどうか、どの特定行政庁へどの様式で報告するかを確認します。そのうえで、資格者の確認と承認を含む運用にします。
自治体のオンライン受付や様式改定、報告期限に対応できるかは、製品を選ぶ段階で必ず確認してください。
Excelのままではいけませんか？オフラインでも使えますか？
設備数が少なく、担当者が固定され、履歴検索や異常対応に問題がなければ、すぐに全面移行する必要はありません。
Excelの運用負荷が高まるのは、次のような業務が必要になるときです。
- 期限と履歴：複数拠点の期限管理、設備ごとの履歴
- 記録と承認：写真の保管、承認の記録
- 外部との共有：協力会社との共有
- 修繕の追跡：異常から修繕までの追跡
まず重要設備の台帳と日常点検だけをシステム化し、効果を確かめてから範囲を広げる方法が適しています。
オフライン利用は、製品によって対応範囲が異なります。通信が切れている間に入力できても、写真や添付ファイルの同期、同じ設備を複数人が更新した場合の競合、同期失敗時の再送を確認する必要があります。
実際の現場で機内モードや弱い電波を使ったテストを行い、同期が終わったことを画面で確認できることを、受入条件に含めます。
（出典: 国土交通省「オンラインを活用した定期報告について」、株式会社カミナシ「カミナシ 設備保全」正式提供開始、2025年〜2026年8月確認。導入期間・費用は対象範囲による目安です。）
まとめ
設備点検管理システムの開発は、現場の点検業務と設備データを整理し、方式を選んで段階的に導入したうえで、稼働後もKPIを使って改善していく取り組みです。
成功の要点は、紙帳票をそのまま画面に置き換えるより、設備台帳から点検、異常、修繕、費用、報告までを一貫して追えるデータと運用を作ることです。
まず着手する3つのこと
まず、紙やExcel、既存システムに分かれている設備台帳と点検帳票を集め、対象設備や点検周期、異常・修繕の流れを一覧にします。
次に、1拠点か1設備群を対象に、点検実施率や入力時間、異常対応時間など、導入前の基準値を測ります。
最後に、SaaSや設定変更、個別開発を同じ要件書で比べます。初期費用だけでなく、月額や移行、連携、教育、センサー、運用支援を含めた初年度総額で判断します。
失敗を防ぐ判断基準
製品や開発会社を選ぶときは、機能一覧や価格を見るだけでなく、実際の設備で一連の点検・異常・修繕を操作します。現場が短時間で入力できるかを、そこで確かめます。
法定点検では資格者と報告責任を明確にし、セキュリティでは権限・監査ログ・バックアップ・復旧テストを確認します。
小さく始めて現場の声を取り入れ、データを使って改善を続けることが、設備停止や点検漏れの抑制につながります。
▼全体ガイドの記事
・設備点検管理システム開発の完全ガイド
▼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を創業。