その他の有力な業務システムは、変更・危機管理、事故・化学物質管理、環境・品質管理の3領域に分けると全体をつかみやすくなります。
こうした分類は、現場の記録から経営判断までをつなぐうえで役立ちます。対象、導入効果、進め方、費用相場、開発会社の選び方の順に見ていきます。
▼関連記事一覧
・その他の有力な業務システム開発の進め方/やり方/流れや方法/手法/工程/手順
・その他の有力な業務システム開発でおすすめの開発会社/ベンダー6選と選び方
・その他の有力な業務システム開発の見積相場や費用/コスト/値段について
・その他の有力な業務システム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
その他の有力な業務システムの定義
その他の有力な業務システムは、特定の製品名を指す言葉ではありません。定番の基幹システムの周辺で、事故や災害、化学物質、環境負荷、品質変更などを扱うシステム群を指します。
「その他」にまとめられる理由
ERP、会計、人事、販売管理などは、取引や資源を日常的に処理するシステムです。
事故原因の分析や災害時の復旧には、専門的な知識と証跡が欠かせません。
SDSの改訂、排出係数の更新、品質変更の承認も、通常の取引処理とは性質が異なります。そのため、標準的な業務システムに含まれない領域を「その他」としてまとめます。
共通する機能
情報を保存するだけでは、改善にはつながりにくくなります。報告から判断、対策、確認、振り返りまでを一つの流れとして残すことが、改善の土台になります。
- 入力と対応の流れ：入力フォームとワークフローで、報告と判断をつなぎます。
- 権限と期限：承認権限、期限管理、通知、エスカレーションの設定。
- 記録と分析：検索できる証跡と集計ダッシュボードを備えます。
対象となる6つの種類と役割
対象範囲を分類すると、自社に必要な機能と既存システムとの境界が見えてきます。
導入時は、リスクが高く、現場の記録が滞っている領域から優先順位を付けると、進め方を決めやすくなります。
変更管理・BCP・危機管理システム
これらのシステムは、変更管理と事業継続・危機対応の記録を扱い、役割ごとに管理する内容が異なります。
- 変更管理：申請から影響評価、承認、実施、周知までを追跡します。
- BCP・BCM：重要業務や復旧に必要な計画・タスクを管理します。
- 危機管理：非常時の状況共有、指揮命令、通知、対応履歴の集約。
変更管理の対象は、製品仕様、設備、文書、業務手順などです。
版数や承認履歴を残せば、「誰が、なぜ、いつ判断したか」を後から確認できます。
BCP・BCMでは、事業影響分析と、目標復旧時間（RTO）・目標復旧時点（RPO）の設定を中心に扱います。
代替拠点、連絡網、訓練も対象です。
危機管理では、安否確認だけでなく、業務再開の手順と判断記録まで残しておく必要があります。
事故・ヒヤリハット・化学物質管理システム
事故報告と化学物質の情報を同じ仕組みで扱うと、現場対応と周知の状況を後から追えます。
- 事故・ヒヤリハット：重症度分類、原因分析、是正、再発防止、期限超過通知を管理します。
- 化学物質：製品情報、SDS、法規制判定、リスク対策をつなぎます。
事故報告には、スマートフォンから写真や位置情報を添えられます。
項目が多いと報告率が下がるため、現場では1分程度で一次報告し、詳細は管理側で追記できる設計が向いています。
化学物質管理では、製品と成分の情報（CAS番号を含む）、SDSの版、GHSラベルを扱います。
法規制判定、在庫、リスクアセスメント、ばく露防止措置、教育記録も対象になります。
厚生労働省は、2026年度から対象物質が約2,900物質に広がると案内しています。そのため、SDSの改訂通知から作業者への周知まで追跡しておく必要があります。
環境管理・CO2・品質管理システム
環境管理と品質管理は、数値の根拠や改善履歴を残し、説明責任を支えるシステムです。
- 環境管理：活動量と排出係数から排出量を算定します。
- 品質管理：逸脱、苦情、是正予防措置、監査、教育、文書、変更を管理します。
- 連携：事故・変更管理と組み合わせ、報告から効果確認までをつなぎます。
環境管理では、電力、燃料、廃棄物、水、物流などのデータを集めます。それをもとに、Scope1からScope3まで算定します。
根拠ファイル、係数の版、計算式、承認履歴を保存しておくと、開示や監査で根拠を示せます。
一定規模以上の排出事業者には算定・報告が求められており、2022年度の集計は12,044事業者、15,258事業所でした（出典: 経済産業省・環境省、2025年公表）。
品質や安全の説明責任が重い業種ほど、導入効果が見えやすい領域です。たとえば、製造、医療、物流、建設などが挙げられます。
導入による効果
導入効果は、紙を画面に置き換えることにとどまりません。さらに、情報の抜け漏れを減らし、対応期限と責任者を明確にできます。
経営層がリスクを比較できる状態をつくれる点にも価値があります。
効果を測る指標を先に決めておくと、導入後の改善を続けやすくなります。
情報の見える化と対応漏れの防止
対応状況を一覧で見られるようにすると、未処理の案件を見つけられ、予防指標の分析にもつなげられます。
- 案件の把握：報告日、責任者、期限、状態、承認履歴を記録します。
- 期限の管理：期限の数日前に通知し、超過時は上長へ連絡します。
- 傾向の分析：拠点・設備・原因・製品別に集計し、単発報告を分析します。
- 予防指標：完了率や最新版適用率などを組み合わせます。
Excelやメールで管理すると、最新版や対応状況、期限超過件数を毎回確認しなければなりません。
未処理案件を一覧にしておけば、担当者の記憶だけに頼らずに済みます。
事故件数だけでなく、ヒヤリハットの報告数も確認できます。さらに、是正措置の期限内完了率やSDSの最新版適用率も、予防につながる指標です。
監査対応と経営判断の高度化
監査の証跡と経営指標を結びつけると、根拠のある判断を現場の改善へ戻せます。
- 監査の証跡：入力者、承認者、参照した版、修正時期を残します。
- 情報の版管理：化学物質や環境情報の版と有効期限の管理。
- 経営判断：リスクと対応コストを同じ画面で比較します。
監査や取引先への説明では、結果だけでなく根拠とプロセスも示す必要があります。そのため、規制情報や排出係数の版を残しておけば、後から確認できます。
ファイル名だけで管理すると、改訂前の情報が残りやすくなります。
事故傾向、復旧時間、排出量の増減、是正措置の停滞を確認できれば、予算や人員を配分できます。
現場の入力を経営判断に反映し、その結果を現場へ戻す流れが、定着につながります。
その他の有力な業務システムの開発・導入の進め方
開発方式を選ぶ前に、業務の目的、現場の例外、必要な証跡、既存データとの境界を整理します。
全社や全領域から始めると、要件が膨らんでしまいます。そのため、優先度の高い業務をMVPとして試し、利用状況と効果を確かめながら広げる進め方が安全です。
要件定義でのMUST・WANTと例外運用の分け方
要件定義では、業務の現状と必要な統制を分けて整理し、例外運用についても担当者に確認します。
- 業務と要件：法令・安全・監査のMUSTと利便性のWANTを分けます。
- 例外運用：通常手順以外に起こる事態と対応を洗い出します。
- 非機能要件：セキュリティ、復旧、連絡、保存条件を明文化します。
棚卸しでは、入力者と承認者、期限に加えて、データの残し方と使い方も確認しておきます。
- 保管年限：データを残しておく期間。
- 利用端末：どの端末から使うか。
- 出力帳票：出力する帳票の種類。
- 連携先：データを受け渡す既存システム。
例外としては、夜間、停電、通信障害、緊急対応、代理承認などが挙げられます。
非機能要件では、MFAと最小権限、拠点別の閲覧制御のほかに、データを守る仕組みと、障害から戻すための準備も含めます。
- 暗号化：保存データと通信の保護。
- 操作ログ：誰がいつ何を操作したかの記録。
- バックアップ：データの複製を取り、保管すること。
- 復旧テスト：バックアップから実際に戻せるかを確かめること。
障害時の連絡経路、データ返却、保存期間も決めておきます。
IPAの中小企業向け情報セキュリティ対策ガイドライン第4.0版は、2026年3月公開で、バックアップを含む基本対策を整理しています（出典: IPA、2026年）。
RFPの非機能要件を作る際の確認材料としても使えます。
SaaS・パッケージ・ローコード・スクラッチの比較
方式は、標準機能の活用度と独自要件の複雑さをもとに選びます。そのうえで、各方式の得意範囲と制約を比べます。
- SaaS：標準機能を早く使い、更新や運用を任せたい場合に向きます。
- パッケージ：業界標準の業務に合わせて導入します。
- ローコード・ノーコード：フォームや台帳を素早く試せます。
- スクラッチ：独自の連携や危機対応が競争力に直結する場合に検討します。
SaaSでは、法改正や排出係数の更新、バックアップ、障害対応を任せられます。一方、独自の承認経路や細かな帳票には制約がある場合があります。
パッケージは、導入支援と追加設定を組み合わせて進めます。
ローコード・ノーコードは入力項目を現場で変えやすい反面、複雑な法規制判定や多言語のSDS生成には追加の設計が必要です。
精緻なScope3算定や基幹システムとの大量連携にも、追加の設計が必要です。
スクラッチ開発は既存ERP、PLM、MES、会計、設備IoTとの深い連携にも使われます。
スクラッチは、使う範囲を必要な業務に絞るほど、費用と保守負担を抑えやすくなります。
90日でのMVP作成と利用状況の検証
対象を絞って90日程度試すと、入力や連携の課題を早い段階で確認できます。試行後は改善を加えてから、対象を広げます。
- 試行範囲：業務や拠点を限定してMVPを作ります。
- 効果測定：利用状況と業務上の指標を確認します。
- 改善と拡張：利用者の声を反映してから対象を広げます。
試行例としては、事故報告フォームから是正期限、月次分析までをつなぐ方法があります。
三つ程度の拠点でCO2データを集め、排出係数、証憑、承認を確認する方法もあります。
対象を絞ると、データの欠損、入力のしにくさ、権限の不備、既存システムとの重複を早い段階で見つけられます。
測定する指標は、報告率、入力時間、期限内の是正完了率、月次集計時間、問い合わせ件数です。
「入力項目が多い」「スマートフォンで使いにくい」「承認者が分からない」という声があれば、機能追加より先に業務フローを見直します。
費用相場と開発期間の目安
費用は、ユーザー数や拠点数に加えて、法規制データ、排出係数、マスタ連携、データ移行の範囲で変わります。さらに、承認経路、監査証跡、教育、保守の範囲でも変わります。
ここで示す金額は、税抜を基本とした目安です。標準SaaSの公開価格と個別開発の推定レンジは性質が違うため、分けて見る必要があります。
▶ 詳細はこちら：その他の有力な業務システム開発の見積相場や費用/コスト/値段について
SaaSの初期費用と月額料金の目安
SaaSの料金は、サービスの対象や付帯機能によって差があります。代表的な価格帯と、その変動要因を見ておきます。
- BCP・安否確認：初期費用や利用人数に応じて料金が変わります。
- CO2排出量管理：月額と買い切り型で料金幅が異なります。
- 追加機能：連携、支援、データ管理の範囲が価格に影響します。
BCP・安否確認SaaSには、初期費用0〜10万円程度、月額数千円から数万円程度のサービスがあります。
2026年更新の複数製品調査では、初期費用の中央値は4.8万円でした。月額は50名で約9,500円、100名で約9,800円、300名で約15,990円です（出典: 安否確認システム料金調査、2026年更新）。
実際の料金は、電話連絡、訓練、API連携、休日サポートの有無によって変わります。
CO2排出量管理は月額3万円から200万円程度、買い切り型は初期50万円から300万円以上の例があります（出典: CO2排出量管理システム市場調査、2026年）。
拠点数やScope3の対象範囲を広げるほど、料金は高くなります。請求書の自動取込、サプライヤー回収、証憑管理、伴走支援が加わると、料金はいっそう上がります。ただし、安価なプランでも、排出係数の更新、データ出力、解約時の返却条件を確認する必要があります。
個別開発の費用と期間の目安
個別開発の費用と期間は、対象業務や連携範囲によって変わります。ここに示す金額は、要件から算出する推定値です。
- 単一業務：開発費100万〜500万円、期間2〜6か月程度です。
- 複数拠点・基幹連携：300万〜1,500万円、4〜12か月程度です。
- 本格的なEHS・QMS：1,000万〜3,000万円以上、6〜18か月程度の場合があります。
- 標準SaaSの初期設定：数日から1か月程度が目安です。
本格的なEHS・QMSの推定額は、化学物質、SDS、環境、品質に加えて、多言語・多国規制や生産・購買連携を含む場合の額です。製品価格の公表値ではありません。
要件定義を短くしすぎると、データ移行やテストが後ろ倒しになり、稼働後の追加費用につながります。
5年TCOで比較する費用項目
初期費用だけでなく、5年間の総保有コスト（TCO）で比べます。見積もりから漏れやすい費用も、あわせて確認します。
- 導入費：設定、データ整備・移行、API、端末、センサーを含めます。
- 運用費：更新、バックアップ、教育、担当工数、障害対応を含めます。
- 終了時の費用：解約時のデータ返却も確認します。
ライセンスや月額料金に加えて、初期設定、データクレンジング、移行、API、端末やセンサーの費用も見積もります。運用の面では、排出係数や法規制情報の更新、教育、担当者の工数、24時間対応、障害復旧を含めます。
開発費は、要件定義10〜15%、設計15〜20%、実装40〜60%、テスト・移行・教育15〜25%ほどに分けて考えると、抜け漏れを確認しやすくなります。
事故や停止による損失が大きい業務では、許容復旧時間、復旧テストの頻度、サポート受付時間も金額に置き換えて比べます。
開発会社・ベンダーの選び方
開発会社・ベンダーは、知名度や機能数だけで決めないことが大切です。標準SaaS、パッケージ、個別開発、複数製品の導入支援では、得意範囲や、どこまでを誰が受け持つかが異なります。
自社の課題のうち、標準機能で対応できる範囲と、設定・連携・開発が必要な範囲を比べます。
対象業務への適合性と専門性
業務ごとの必須機能に加えて、例外運用まで対応できるかを確かめます。導入実績も、条件をそろえて比べます。
- 事故管理：現場での報告、匿名対応、フィードバックを確かめます。
- SDS管理：物質情報から教育記録までの管理を確認します。
- 環境管理：データや係数、証憑、開示帳票の範囲を見ます。
- 導入実績：規模、対象業務、期間、効果を確認します。
事故・ヒヤリハットでは、スマートフォンで短時間に報告できるか、写真や位置情報、匿名報告に対応するかを見ます。SDSでは、製品・成分・CAS番号を確認したうえで、改訂から教育記録までの流れも見ます。
- 改訂通知：SDSが改訂されたときの連絡。
- 法規制判定：物質が対象となる法規制の判定。
- リスクアセスメント：物質ごとのリスクの評価。
- 教育記録：作業者への教育の記録。
環境管理では、一次データ、排出係数の更新、Scope3、証憑、開示帳票を確認します。ロゴや導入社数を見ただけでは、自社の例外運用に合うかどうかは分かりません。
画面デモでは、差し戻し、代理承認、期限超過、通信障害、改訂前データの参照を確かめます。導入事例では、拠点数、ユーザー数、移行データも確認します。
既存システムとの連携とデータ移行
重複や不整合を防ぐため、既存データとの連携方法を決め、移行対象と受入確認の手順も定めておきます。
- 連携方法：取込頻度、連携方式、正とするデータを決めます。
- 移行対象：保存・分析用と参照用の期間を分けます。
- 受入確認：現場責任者が件数、サンプル、権限を照合します。
連携対象は、従業員、拠点、製品などのマスタです。加えて、業務で使う他のマスタも、既存システムとの連携範囲に入るかを確認します。
- 設備：設備のマスタ。
- 取引先：取引先のマスタ。
- 会計：会計のマスタ。
- 購買：購買のマスタ。
- 物流：物流のマスタ。
CSVで定期取込するか、APIでリアルタイム連携するかを決めます。
正とする情報を定めないと、複数の箇所で内容が食い違います。そのため、連携失敗時の再送、差分確認、担当者への通知も要件に入れておきます。
移行では、古いExcelの重複、表記ゆれ、欠損、改訂日が不明なSDS、根拠ファイル不足が問題になりがちです。そこで、過去データは法定保存、監査、分析、参照の期間ごとに分け、移す対象を絞ります。
導入後の保守・更新と役割の分け方
法令や排出係数を扱う場合は、導入時の機能より更新体制を重視する必要があります。責任者と窓口も明確にしておきます。
- 更新体制：改正検知の担当、マスタ更新時期、更新内容の利用者通知、計算・判定の版を記録します。
- 保守と契約：復旧、サポート、再委託、バックアップを確認します。
- 役割分担：問い合わせ窓口と最終責任者を決めます。
- 長期運用：5年後まで無理なく運用できるか比べます。
SaaSの場合は、標準アップデートの範囲や個別設定への影響、事前告知、検証環境の有無を、発注側から事業者に確認します。
契約前には、障害時の復旧目標、サポート受付時間、脆弱性対応、データ保存場所を確認します。解約時のエクスポート形式や追加開発の単価も、あわせて確かめておきます。
要件定義と運用は、別の事業者が担う場合もあります。
▶ 詳細はこちら：その他の有力な業務システム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：その他の有力な業務システム開発の進め方/やり方/流れや方法/手法/工程/手順
▶ 詳細はこちら：その他の有力な業務システム開発の発注/外注/依頼/委託方法について
導入で失敗しないためのチェックポイント
失敗の多くは、目的、運用責任、データ、現場定着を曖昧にしたまま導入を進めることから起きます。そのため、導入前の状態と導入後の目標を数字で比べられるようにしておきます。
最初から作り込みすぎないこと
初期導入では、利用の定着と将来の変更に必要な範囲に絞ります。要望をすべて盛り込むと、現場で使われにくくなります。
- 要件の優先順位：最初はMUST要件に絞ります。
- 機能の選択：標準機能と独自対応の範囲を分けます。
- 段階的な定着：重要な業務の流れから使い始めます。
部門ごとの要望を取り込むと、入力項目や承認経路、権限、帳票が増えます。独自開発の場合は、設定で変える項目とプログラム変更が必要な項目を分けて、将来の変更に備えます。
事故報告では、細かな分類を増やす前に、一次報告、責任者の確認、期限、再発防止の流れを定着させます。
環境データは、全Scope3を一度に算定せず、一次データを得やすい範囲から始めます。そのうえで、データ品質の成熟度に合わせて精度を高めます。
現場定着の設計を要件に含めること
現場で使い続けられるよう、導入支援、利用環境、訓練後の改善まで準備します。
- 導入支援：対象拠点と利用者を決め、説明や相談窓口を用意します。
- 現場環境：端末や通信、入力方法に応じた対策を確認します。
- 訓練と改善：BCP訓練後の振り返りを改善タスクに登録できる仕組みを用意します。
短いマニュアルや、入力内容へのフィードバックも用意しておきます。報告者に何も返らないと、入力が負担になってしまいます。月次会議で改善事例を共有すると、現場の協力を得やすくなります。
スマートフォンで使う場合は、通信が不安定なときの一時保存、写真の容量、音声入力、匿名と記名の切替、端末紛失時の対策を確認します。
BCP訓練では、連絡先の古さや代理承認、代替手段、復旧手順の欠落を洗い出します。
よくある質問
導入前によく寄せられる疑問を、以下の質問ごとにまとめます。
導入前には、自社の業務範囲、法令上の責任、現場の利用環境、5年TCOを確かめながら判断してください。
その他の有力な業務システムは何から導入すればよいですか？
事故報告、SDS、CO2、BCPなどから、リスクが高く、集計負担が大きく、効果を測りやすい業務を選びます。
対象を一つに絞り、90日程度のMVPで入力率、対応期限、集計時間などを測ってから他領域へ広げると、失敗を抑えやすくなります。
SaaSと個別開発はどちらを選ぶべきですか？
短期間で標準機能を使い始め、法規制やバックアップの更新を任せたい場合はSaaSが向いています。
複雑な既存システム連携、独自の危機対応、特殊な帳票、他社との差別化が必要で、標準機能では業務が成立しない場合は個別開発を検討します。
標準SaaSを中心に、一部だけ連携や追加開発をする組み合わせも有効です。
法改正や排出係数の更新には対応できますか？
対応可否は製品や契約によって異なります。更新の主体、頻度、事前通知、過去データへの影響、利用者への周知方法を確認します。
化学物質管理では、SDSの改訂、対象物質、リスクアセスメント、教育記録をつなぐ必要があります。
環境管理では、係数の版、根拠データ、計算式、承認履歴を保存できるかを確かめておく必要があります。
個人情報や安全情報を扱うときの注意点は何ですか？
拠点や職種ごとの閲覧権限、最小権限、MFA、暗号化を要件に入れます。操作ログ、バックアップ、復旧テスト、保存期間、委託先管理も、あわせて入れておきます。
事故や安否情報は、全員が見られる情報と管理者だけが見られる情報を分けます。そのうえで、緊急時に必要な人が必要な情報へ届く設計にします。
導入前に権限表と障害時の連絡経路を作り、テストで確認してください。
まとめ
その他の有力な業務システムは、変更管理、BCP・危機管理、事故・ヒヤリハットを支えます。また、化学物質・SDS、環境・CO2、品質管理も、定番の基幹システムだけでは扱いにくい業務です。
現場の報告、責任者の判断、是正措置、承認、分析、改善を一つの証跡として残せば、記録を電子化するだけで終わりません。
導入前に押さえる要点
対象業務を6系統に分類し、MUST・WANT、例外運用、必要な証跡、既存マスタとの境界を整理します。SaaS、パッケージ、ローコード、スクラッチの得意範囲も比べます。
方式や費用は初期額だけでなく、5年TCOで判断します。法規制・排出係数の更新、データ移行、セキュリティ、保守、解約時のデータ返却も、見積もりと契約に含めます。
最初の90日で実行すること
最初の90日は、成果を確認しやすい業務をMVPで試します。測定結果を踏まえて、対象範囲と支援体制を広げます。
- 試行：事故報告から是正、または限定拠点のCO2収集を試します。
- 測定：利用と対応の指標を測り、利用者の声を反映します。
- 拡張：自社に合う開発会社・ベンダーと対象を広げます。
CO2データ収集では、証憑承認までを対象にできます。入力率、対応時間、期限内完了率、集計時間、問い合わせ件数を測ります。
自社のリスクと業務に合う相手を選び、現場で使われ続ける仕組みを設計することが、導入を成功させる近道です。
▼関連記事一覧
・その他の有力な業務システム開発の進め方/やり方/流れや方法/手法/工程/手順
・その他の有力な業務システム開発でおすすめの開発会社/ベンダー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を創業。