スマートメーター管理システム開発の完全ガイド

スマートメーター管理システムは、計測データの収集、品質管理、業務システムへの配信を担う基盤です。対象範囲とデータ量を定めたうえで、要件定義、PoC、設計・移行の順に導入を進めます。

各テーマの詳細は、下の関連記事もご覧ください。

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

スマートメーター管理システムの定義と役割

データの受け渡しに沿って、担当する業務が切り替わります。

スマートメーター管理システムは、一般にMDMS（Meter Data Management System）を指します。計量データを検証・補正・推定し、業務で使える確定データに変換する仕組みです。

MDMSが担う役割

MDMSの役割は、計量データを管理し、業務で使える品質に整えることです。

計量データの管理：30分値、15分値、5分値などを、メーターIDや契約情報と結び付けます。
データ品質の確保：遅延・欠測は再送で補い、重複を排除し、異常値を補正・推定する役割です。
業務への影響：1件の欠損や重複でも、請求額、託送精算、顧客対応に影響が及びます。
対象範囲の定義：提案依頼書でMDMSと定義し、対象システムの範囲を明記します。

原本データと、請求・分析用のデータは区別して扱います。なお、MDMはモバイル端末管理を指す場合もありますが、電力分野ではMeter Data Managementを意味します。

対象範囲には、メーター本体や通信網から請求システムまでのどこまでを含めるかを明記してください。

HES・MDMS・CISの違い

各システムは、次のように役割を分けます。

スマートメーター・通信網：計測とデータ伝送を担います。
HES（Head End System）：メーターとの通信制御とデータ収集を受け持ちます。
MDMS：計量データの蓄積、品質管理、配信が役割です。
CIS：顧客、契約、料金請求を管理します。

周辺システムには、設備管理、GIS、停電管理などがあります。需給管理や顧客ポータル、分析基盤も、MDMSから必要な情報を受け取ります。

メーターからHES、MDMS、CISまでをAMI（Advanced Metering Infrastructure）として一括で調達する場合もあります。ただし、MDMSとHESを同じ製品にする必要はなく、既存のHESやCISを残してMDMSだけを刷新する方式も選べます。

各システムの境界が曖昧なままだと、障害が起きたときに責任の所在が食い違い、データの不整合も生じます。そのため、調達範囲と責任範囲を先に定義しておいてください。

ポイント

MDMSの担当範囲を、HESやCISとどの境界で分けるかを、見積の前に決めておいてください。その判断が、障害時の対応分担とデータの責任の所在に直結します。

スマートメーター管理システムの主要機能と種類

機能は、データ収集、品質管理、業務への配信、異常・権限管理に分けて考えると整理しやすくなります。優先順位は、導入目的が請求精度の向上か、設備運用の高度化か、需要家向けサービスの拡充かによって変わります。

データ収集・VEE・台帳管理

受信の抜けや欠測は、収集の段階で把握しておかないと、VEEでどう扱うかを決められません。

台帳管理：メーター、通信端末、設置場所、契約、交換履歴を管理します。
受信記録：受信時刻、計量時刻、メーターID、データ種別を記録します。
収集監視：再送や順序変更への対応と、収集率、遅延、欠損、重複の監視。
VEE：Validationで検証し、Editingで補正し、Estimationで欠測値を推定します。

通信断で30分値が欠けた場合の補い方には、直前値の繰り返し、同曜日の実績、前後の値による補間などが候補になります。そのうえで、推定値を請求に使うのか、分析だけに使うのかを事前に合意しておく必要があります。

連携・分析・遠隔制御

連携機能は、相手先、データ項目、遠隔制御時の安全要件に分けて検討します。

連携先：CIS、請求、託送です。加えて、需給・停電管理、GIS、顧客ポータル、分析基盤も連携先になります。
連携項目：計量値に加えて、交換、契約切替、供給地点の情報も扱います。確定状態、推定フラグ、訂正履歴も含みます。
将来の連携：遠隔開閉、アンペア制御、停電検知が候補になります。さらに、分散型電源、蓄電池、EV、デマンドレスポンスも見込まれます。

連携はAPIかファイルで行います。連携先が増えるほど、項目定義と再送方式の重要性が高まります。

遠隔制御では、操作できる人の権限と二者承認を決め、対象を確認してから実行する流れを定めます。結果の照合と誤操作時の復旧も含めます。遠隔制御は機器に指令を返すため、閲覧中心の機能より高い安全性が必要です。

パッケージ・クラウド・スクラッチの違い

開発方式は、標準機能をどこまで使うか、運用の負担はどれくらいか、個別要件にどこまで応えられるかで比べます。

パッケージ：VEE、台帳、データ配信、監査ログを活用でき、導入期間を抑えやすい。
クラウド・SaaS：データ量に合わせて拡張しやすく、サーバー更新の負担も抑えやすい。
オンプレミス・プライベートクラウド：閉域網や既存の運用体制と組み合わせやすい。
スクラッチ開発：独自の計量ルールや既存OTとの深い統合に向いている。

制度ごとの料金計算や既存CISとの接続は、パッケージを使う場合でも追加の設定や開発になることがあります。そのため、標準機能と個別対応の境界を確認してください。

クラウドやSaaSでは、従量課金の仕組みと、データの保存場所を確認します。加えて、障害時の対応範囲や、データを別の基盤へ移せるかも見ておきます。

オンプレミスなどでは、設備更新やバックアップ、監視を自社が担う範囲を確認します。人材の確保も、同じ観点で見ておきます。

スクラッチでは、VEEや障害復旧、制度改定への長期的な対応も必要になります。一方で、MDMSのコアをすべて自作せず、標準製品やAPI、時系列データ基盤を組み合わせる方式も比較の候補に入れてください。

スマートメーター管理システム開発の進め方

候補評価の前に要件をそろえると、比較の前提が整います。

まず事業目的と現行システムを整理し、データ量や品質ルール、非機能要件を順に詰めます。そのうえで、製品や開発会社を比べます。

導入には、業務、設備・通信、ITの各部門が関わります。セキュリティや運用の部門も加わるため、全体の意思決定者を置いておく必要があります。

企画・現状調査と要件定義

企画・要件定義では、改善目標と現行環境を整理してから、システム要件を具体化します。

改善目標：請求確定までの時間短縮、通信欠損の削減、顧客への使用量表示などの数値目標。
現状調査：既存システムを洗い出し、責任範囲と正本データを確認します。

洗い出しの対象は、HESやCISのほか、請求や設備台帳にも及びます。データ連携と監視運用も含めて確認します。

要件定義では、台数と増設計画、計測粒度を明記します。そのうえで、ピーク同時受信数も数値で示しておきます。許容遅延、欠損率、日次締め時刻は、数値で定めておきます。保存年数、RPO・RTO、稼働時間は、障害時の復旧と保管の前提になります。認証方式、監査ログ、連携先も、あわせて定めます。

1台あたりの件数は、30分値が1日48件、5分値が1日288件で、レコード数は6倍変わります。そのため、将来の粒度変更も見込み、保存量と処理量を分けて試算してください。

RFI・PoC・製品比較

RFIとPoCでは、候補方式の対応範囲と例外処理を同じ条件で評価します。

候補方式：RFIで製品・開発方式の対応範囲を確認します。
評価データ：匿名化サンプル、欠損、交換履歴、契約切替のケース。
共通評価：VEE、再処理、連携、監査ログを同じ条件で比べます。
小規模PoC：数百〜数千台で、収集、VEE、1〜2連携、簡易画面を検証する形です。

機能一覧から実運用の対応力は読み取りにくいため、実データに近いサンプルで例外処理の使いやすさを確かめます。PoCの合否には、遅延や欠損が起きたときに誰が原因を追い、どのデータを再処理するかも含めます。未検証の事項は、本番見積のリスクとして金額と前提を記載してもらいます。

設計・移行・並行稼働・運用

本開発から本番運用まで、設計、試験、移行、切替後の確認を順に進めます。

データモデル、VEE、権限、監視の設計と、正常系・異常系のテスト。
請求・精算データは、旧システムとの突合結果を日次・月次で確認し、差異の原因を追跡できる状態にします。
過去データの扱いは、すべて移すか、参照用にアーカイブするか、請求・監査に必要な期間だけ移すかを決めます。
切替後は一定期間並行稼働し、新旧両システムの収集率、欠損、VEE結果、請求連携、処理時間を比べます。

連携仕様、バックアップ、障害復旧も、あわせて設計します。試験には、通信断、重複受信、時刻ずれ、停電を含めます。さらに、交換、契約切替、異常値、月次締め中の再処理も対象にします。

対象地域や契約種別を絞って段階的に展開すれば、導入時のリスクを抑えやすくなります。

▶ 詳細はこちら：スマートメーター管理システム開発の進め方

ポイント

製品や開発会社を比べる前に、事業目的、データ量、品質ルール、非機能要件が整理されているかを確かめてください。要件が固まらないまま比べると、評価の前提がそろいません。

スマートメーター管理システムの費用相場と内訳

継続中の費用と終了時の移行費も、比較対象に含まれます。

費用を左右するのは、まずメーター台数と計測間隔、保存期間です。そのほか、HES・CISとの連携数やVEEの複雑さも影響します。可用性、セキュリティ、移行範囲も、費用に関わります。

MDMS単体の定価や、日本の中小規模向けの公開見積は多くないため、ここで示すのは2026年時点で予算取りに使う推定レンジです。

メーター本体や通信回線、HESは別費用になる場合があります。データセンターや24時間運用、CIS改修も、別に費用がかかることがあります。

段階別の費用と期間の目安

段階ごとの予算と期間は、対象規模や個別対応の範囲によって異なります。

事前調査・RFI・要件定義：費用は300万〜1,000万円程度、期間は2〜4か月が目安です。
小規模PoC：数百〜数千メーターが対象で、費用は1,000万〜3,000万円程度、期間は3〜6か月程度です。
標準導入：パッケージやSaaSと基本連携を中心に、費用は3,000万〜1.5億円程度、期間は6〜12か月程度です。
中規模の個別開発：費用は1.5億〜5億円程度、期間は12〜24か月程度です。
広域・全国規模の刷新：費用は5億〜20億円超、期間は18〜36か月程度になることがあります。

中規模の個別開発には、複雑な基幹連携、高可用性、複数通信方式を含みます。詳細なVEEやデータ移行も、対象に入ります。

広域刷新では、HESやMDMSから請求、設備、運用までが対象になる場合があります。これらは、対象範囲を明確にしたうえで予算を立てるための目安です。正式な価格ではありません。

経済産業省の試算では、10社合計の現状設備更新費用が1兆2,173億円、機能追加を含むケースが1兆5,223億円とされています。この数字は全国の機器・通信・システムを含むため、個別企業のMDMS開発費とは分けて考えてください。

また、5分値データ取得の増分938億円には、通信部、メーターのメモリ・CPU、HES・MDMSの改修などが含まれます（出典: 経済産業省・次世代スマートメーター制度検討会「次世代スマートメーター導入に係るコストの再算定結果」、2021年）。

費用を左右する項目と5年TCO

初期費用だけでなく、継続費と将来の移行費を含めて比較します。

初期費用：開発、移行、教育、予定する機能追加の費用。
運用費：ライセンス、メーター数やデータ量に応じたクラウド利用料、通信費、サーバー、監視、バックアップを含めます。
保守費：制度改定、セキュリティ監査、障害対応にかかる費用。
終了・移行費：契約終了時のデータ搬出費と再構築費。

5年TCOを出すときは、初期費用に、60か月分の運用費、移行・教育費、予定する機能追加費を足します。

計測粒度も、費用に直結します。たとえば、1台あたり1日の件数は、30分値が48件、5分値が288件です。

100万台なら、30分値は1日4,800万件、5分値は1日2億8,800万件になります。実際の量は、項目数、再送、履歴保存によって変わります。圧縮や集計の方法でも差が出ます。

ピーク時の同時受信数と再処理時間も含め、容量試験を行ってください。

▶ 詳細はこちら：スマートメーター管理システム開発の見積相場・費用

ポイント

予算は、初期費用だけでなく、運用費、保守費、移行費を含む5年TCOで比べてください。対象範囲が未確定なら、段階別の費用の幅を前提に組むと、後の差異を抑えやすくなります。

スマートメーター管理システムの開発会社・サービスの選び方

開発会社やサービスは、知名度や機能数だけでなく、自社との適合性で比べます。適合性は、メーター規模や既存システムとの相性で見ます。運用体制と将来の計測粒度への対応も、あわせて確かめます。

価格だけでなく、電力業務やデータ処理への理解も確認します。OTとITの接続、セキュリティ、移行、24時間運用も、あわせて見ておきます。

電力業務と大規模データの経験

候補先の経験は、どの規模のデータを、どんな業務で扱ってきたかで判断します。

処理実績：台数、受信量、粒度、欠損率、保存期間を示せる、同規模の実績。
運用性能：平常時とピーク時の件数、遅延、復旧時間、再処理方法を数値で確認します。
業務領域：電力小売、送配電、アグリゲーター、自治体などでの経験の有無。
担当体制：業務担当者がVEEを変更できる範囲と、必要な役割の分担を確認します。

メーターや通信設備まで含めて一括で任せたい場合と、既存のCISやデータ基盤との接続を中心に頼みたい場合では、事業者の強みが異なります。自社が求める範囲を切り分けて選びます。

製品の拡張性と連携のしやすさ

製品を選ぶときは、どの利用環境で使うかによって、確認する点が変わります。

標準連携：API、ファイル、メッセージ、スキーマ、認証、版管理を確認します。
データ可搬性：原本出力、推定値・確定値の履歴保持、別基盤への移行可否。
クラウド：料金単位がメーター数かデータ量か、保存期間、リージョン、鍵を確認します。バックアップ、復旧目標、ログも含めます。
オンプレミス：サーバー、ライセンス、監視要員、パッチ適用、更新費用。

HESやCISを交換するときに備えて、特定の製品に依存しないデータモデルとインターフェースを選びます。契約終了時のデータ返却と移行支援も、契約書に含めてください。

運用・保守の役割分担

稼働後の体制は、契約前に具体的な形にしておく必要があります。

監視と役割：収集率、遅延、欠損、VEE、連携失敗、再処理を監視し、担当者を決めます。
障害対応SLA：24時間365日の運用なら、受付、復旧開始、暫定・恒久対応、報告の時間を確認します。
保守範囲：制度・料金変更、設定、OS更新、機能追加の契約内外の区分。
教育：教育計画と手順書のサンプルを確認し、導入後の属人化を抑えます。

HESや通信網への照会を含め、障害時の役割分担をあらかじめ決めておきます。

▶ 詳細はこちら：スマートメーター管理システム開発でおすすめの開発会社6選と選び方

ポイント

開発会社は、同規模のデータ処理の実績と、自社が任せたい範囲への対応力で比べてください。知名度や機能数だけで選ぶと、稼働後の運用で不足が見えやすくなります。

スマートメーター管理システムを発注・外注・委託する方法

発注時は、自社が決める事項と委託先に任せる事項を分けて考えます。自社が決めるのは、業務目的や対象範囲、データの正本です。請求・精算ルール、許容停止時間、セキュリティ方針も、自社側で決めておきます。

委託先には、実現方式と工数、体制を提案してもらいます。リスクや運用方法も、あわせて示してもらいます。開発会社への丸投げは避けて、両者の責任を明確にしておく必要があります。

RFI・RFPの記載項目

RFIとRFPでは、対象範囲、対応方法、評価条件をそろえます。

RFIの提示情報：メーター数、計測間隔、通信方式、既存HES・CISです。連携先、保存期間、導入時期、クラウド可否、運用時間も示します。
RFPの回答形式：機能要件と非機能要件を分けたうえで、各要件を標準対応、設定対応、追加開発、対象外のいずれかに分類してもらいます。
評価用データ：正常な時系列に加えて、欠損、重複、遅延、時刻ずれを含めます。メーター交換、契約変更、停電、異常値も入れておきます。
検収条件：収集率、処理時間、データ突合率、復旧時間を定めます。監査ログ、権限分離、バックアップ復元も含めます。

提案金額だけでなく、前提条件と未確定事項も比べられる形式にしてください。VEEルールの承認者や、変更後に行うテストも、RFP段階で文書にしておいてください。

契約・成果物・検収の決め方

契約前に、成果物と工程ごとの完了条件を定めておきます。

設計資料：要件定義書、基本設計書、データモデル、API仕様書、VEEルール一覧。
開発・運用資料：テスト計画、移行計画、運用設計書、手順書、教育資料。
契約条件：準委任と請負の工程、仕様変更の受付、影響分析、見積、承認、リリースの流れ。

データの所有権、二次利用、再委託、秘密保持は、契約書で確認します。個人情報や需要家情報の扱い、脆弱性対応、インシデント報告、ログ保管も含めます。契約終了時のデータ返却も、契約書に入れておきます。

委託先が複数に分かれる場合は、HES、MDMS、CIS、通信、運用の担当境界を一覧にしておきます。複数領域にまたがる障害への合同対応も、あらかじめ合意しておいてください。

▶ 詳細はこちら：スマートメーター管理システム開発の発注・外注・委託方法

ポイント

発注前に、自社が決める事項と委託先に任せる事項を分けておいてください。両者の責任範囲を契約書で明確にしておかないと、障害や仕様変更の場面で対応に迷いやすくなります。

セキュリティと2026年以降の最新動向

このシステムは、顧客・契約情報を扱うITシステムであると同時に、電力設備や通信網にも接続します。

そのため、認証・認可、通信暗号化、ネットワーク分離といった対策を、機能要件と同時に設計します。脆弱性管理や改ざん検知、監査ログ、バックアップ、インシデント対応も含めます。

ERABに関するサイバーセキュリティガイドラインは、Ver3.0に改定されました（出典: 経済産業省「ERABに関するサイバーセキュリティガイドラインVer3.0」、2025年）。改定後のガイドラインでは、IoT機器やクラウド経由の連携も考慮されています。

RFPで確認するセキュリティ要件

RFPの段階で、アクセス制御の権限と接続経路を分け、変更履歴を追えることを要件に含めておきます。

利用者権限：利用者、運用管理者、連携システム、機器制御を分け、最小権限と多要素認証を検討します。
接続境界：HES・通信網とMDMSの境界、外部経路、ファイアウォール、API認証、証明書更新、秘密情報の保管の決め方。
監査証跡：誰がいつ何を変更したか記録し、VEEルールや契約情報の変更も追跡できるようにします。

委託先・再委託先の脆弱性管理、ソフトウェア部品一覧、パッチ適用期限、脆弱性発見時の報告期限も確認します。

経済産業省は2025年に、電力制御システムのサプライチェーン・セキュリティ対策の手引きを公表しました。その手引きでは、機器、通信、クラウド、運用を含む供給網全体を管理する考え方が示されています（出典: 経済産業省「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」、2025年）。

第二世代・高粒度データ・分散型電源への備え

将来のデータ粒度の変更や分散型電源の接続に備えて、保存と処理、接続の要件を整理しておきます。

高粒度データ：30分値から15分値、5分値、1分値へ変わる可能性を見込みます。
容量と処理：保存量、収集ピーク、帯域、再処理、品質、締め処理への影響。
データ階層：ホット、ウォーム、アーカイブを分け、原本を再処理できる設計にします。
機器・制度連携：太陽光、蓄電池、電気自動車、デマンドレスポンス、共同検針に備えます。

連携時は、使用量のほか、設備や契約、制御指令、実績値も扱います。そのうえで、ID体系と時刻の扱いを設計してください。重複排除、有効期限、結果照合も、あわせて決めておきます。

2025年11月の改正では、セキュリティ規格の扱いも更新されました（出典: 経済産業省「電気設備の技術基準の解釈の一部を改正する規程」、2025年）。そのため、制度や規格を定期的に確認する体制が必要です。

よくある質問

導入前によく出る疑問は、HESとの違い、クラウド、開発期間、PoCの4つです。答えを先に持っておくと、予算申請や開発会社との打ち合わせが進めやすくなります。

MDMSとHESは同じシステムですか？

同じとは限りません。HESはメーターとの通信やデータ収集を担い、MDMSは収集データの保存、VEE、履歴管理、業務システムへの配信を担います。

製品によっては一体で提供される場合もあります。そのため、要件定義では、役割と障害時の責任範囲を分けて記載してください。

スマートメーター管理システムはクラウドで構築できますか？

クラウドで構築できますが、すべての案件でパブリッククラウドが適切とは限りません。機密性や閉域網、系統運用との接続を確認します。障害時の切替や保存場所、責任の分け方、監査要件も見ておきます。

パブリッククラウド、プライベートクラウド、オンプレミス、ハイブリッドを比較し、初期構築費だけでなくデータ量と保存期間に応じた5年TCOで判断します。

開発期間はどのくらいかかりますか？

期間の目安は工程や規模によって異なります。

要件定義：2〜4か月です。
小規模PoC：3〜6か月です。
標準的な導入と連携：6〜12か月です。
中規模の個別開発：12〜24か月です。
メーター・通信設備を含む広域刷新：18〜36か月以上になる場合があります。

期間は、既存データの移行や並行稼働、制度対応、関係部署の承認によっても変わります。開発だけでなく、試験・移行・教育の期間も計画に含めてください。

小規模な導入でもPoCは必要ですか？

必須ではありませんが、既存システムとの接続やVEEルールに不確実性がある場合は有効です。実データに近いサンプルを使い、収集や欠損補完、再処理を確かめます。連携と処理時間も、あわせて見ておきます。

PoCを行う場合は、検証項目と成功条件をあらかじめ決めてください。本番移行時に再利用できる成果物も、あわせて決めておいてください。

まとめ

スマートメーター管理システムは、HESから受け取ったデータをVEEで品質管理し、CIS、請求、託送、設備運用、分析へ安全に届ける基幹データ基盤です。計測値を集める仕組みにとどまりません。

最初にHES、MDMS、CIS、周辺システムの境界を定めてください。そのうえで、台数や計測粒度、保存期間を数値で示してください。連携先や許容遅延、RPO・RTOも、数値で示しておきます。

失敗を防ぐための先決事項

費用は、メーター台数と計測間隔に加えて、VEEや連携、移行の範囲で変わります。可用性、セキュリティ、運用保守も、費用に影響します。次のレンジは、予算取りの出発点です。

要件定義：300万〜1,000万円程度。
PoC：1,000万〜3,000万円程度。
標準導入：3,000万〜1.5億円程度。
中規模開発：1.5億〜5億円程度。
大規模刷新：5億〜20億円超。

正式な見積では、実データと非機能要件を示したうえで、初期費用と5年TCOを分けて比べてください。

段階導入と将来拡張の両立

発注や選定、将来拡張を判断する際は、試験条件と事業者の対応力をそろえて確認します。

共通テスト：欠損・重複・遅延・交換・契約切替を含め、VEEとデータ突合を確認します。
事業者選定：電力業務や大規模データ、標準API、可搬性で比べます。セキュリティや保守、制度対応力も確認します。
将来拡張：第二世代の高粒度データ、分散型電源、蓄電池、電気自動車、DR、共同検針を見据えます。
導入方法：目的と対象を絞った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を創業。