ESG情報管理システム開発の発注/外注/依頼/委託方法について

ESG情報管理システムの発注は、指標と責任者を整理したうえで、発注形態、RFPと契約、費用、委託先と見積の順に決めていく流れで進みます。要件定義とPoCを経て委託先を選ぶと、開示に耐える基盤につながります。

▼全体ガイドの記事
・ESG情報管理システム開発の完全ガイド

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

ESG情報管理システムを発注する前に知るべき全体像

ESG情報管理システムは、環境・社会・ガバナンスの情報を集計するだけでなく、業務の基盤として設計します。具体的には、誰が、どの期間・拠点のデータを、どの算定式で入力し、誰が承認したかを追跡できるようにします。発注前に扱う範囲を共有しないと、環境データだけを扱う製品と、開示・監査まで支援する製品を同じ見積書で比べることになります。

CO2管理だけでなくE・S・Gのデータ基盤としての定義

環境領域では、Scope 1・2・3、電力、燃料を扱います。廃棄物や水、物流などもこの領域に含まれます。

社会領域では、従業員数や女性管理職比率、離職、労働安全などを扱います。さらに、人権デューデリジェンスやサプライヤー評価もあります。ガバナンス領域では、取締役会の構成、リスク管理、コンプライアンスを管理します。また、腐敗防止や情報セキュリティなども対象です。

発注書では「環境データ」と一括りにせず、指標名、単位、対象範囲を書き出します。そのうえで、基準年度とデータオーナーを記し、報告頻度と算定式も加えます。

開示率の上昇とデータ収集・証跡管理の重要性

人的資本の開示率は82.2%でした（出典: 金融庁「記述情報の開示の好事例集2025（サステナビリティ情報の開示）」、2026年確認）。また、同資料によると、2025年3月期の有価証券報告書では、気候変動が76.7%、人権が49.6%でした。

開示が広がるなかで、発注では関係部門を次のように整理します。

• 管理部門：開示対象の広がりに合わせて、各部門が同じ定義で情報を管理します。
• 共有する部門：経理、人事、購買、環境安全です。法務、IR、情報システムも含めて共有します。
• 発注の目的：入力画面を増やすことではなく、社内の根拠データを開示可能な状態にそろえることにあります。

発注形態の選び方

発注形態は、標準機能で足りるか、既存システムとの連携が必要か、独自の指標や承認フローを作るかによって決まります。フルスクラッチの外注だけでなく、ESG専用SaaSの設定・連携委託や、ERP・BI中心の構築もあります。また、要件定義だけを外部支援に依頼し、開発を社内で行う方法もあります。

標準機能を活用するSaaS導入の向いている場面

WebフォームやExcelテンプレートで集め、承認や証憑添付、ダッシュボードやレポート出力まで早く始めたい場合、ESG専用SaaSが候補になります。

• 基準対応：標準アップデートで開示基準の変更に追随しやすいです。
• 確認事項：独自の組織階層、細かな計算式、データ所在です。加えて、終了時のエクスポートやユーザー数・拠点数による課金も確かめます。
• 導入範囲：小さく導入し、Scope 3やサプライヤーへ広げる企業に適しています。

ERPや業務システムとの統合型による二重入力の削減

会計、購買、人事のデータが正確であれば、APIやCSVでの連携が有効です。設備、電力、物流のデータでも、同じ条件が前提になります。

• 連携例：人員数は人事、電力使用量は設備管理、購買金額は会計・購買から取り込みます。
• データ設計：コード体系と締め日を決めます。組織変更や単位、欠損値の扱いも取り決めます。
• 工数の傾向：連携本数が増えるほど、画面機能よりデータ変換とエラー処理に工数がかかります。

スクラッチ開発が向く独自要件の多い企業

独自の指標マスタや複雑な子会社管理、特殊な承認ルートが必要な場合は、スクラッチ開発やローコードを組み合わせます。加えて、既存データ基盤との統合や社内ポータルとの一体化が必要な場合も、この方法の対象になります。

自由度が高い反面、基準変更への対応は、自社か開発会社が継続して担う必要があります。対象となる基準は、SSBJやIFRS S1・S2、CDPのほか、GRIやCSRD・ESRSなどです。

要件が固まる前に開発会社を決めると、追加改修や納期延長が起きやすいです。そのため、最初にPoCで必須業務を検証します。

RFP・要件整理で決めること

RFPは、機能一覧を開発会社に示すだけでなく、発注の前提を伝えるための書類です。対象会社・拠点・指標、入力者と承認者、開示先を記載します。加えて、既存システムと移行する過去データも書き出します。

さらに、導入希望時期、予算の考え方、運用体制も、同じ前提で提示します。特にESGでは、機能より先に指標の定義と責任者をそろえると、提案内容と見積条件を同じ基準で比べられます。

対象指標・組織範囲・開示基準の一覧

要件の抜けを防ぐため、対象指標と組織範囲を次のように整理します。

• 指標の区分：環境・社会・ガバナンスの指標を、MUSTとWANTに分けます。
• 指標の定義：単位、対象期間・拠点、連結範囲を決めます。入力頻度、算定式、排出・換算係数も定めます。
• 責任と証跡：データオーナー、証憑、承認者の役割を明確にします。開示先も、あわせて決めます。

対象基準は、SSBJやIFRS S1・S2、CDP、GRIから選びます。TCFDやCSRD・ESRSも、選択肢に入ります。

SSBJは2025年3月5日以後終了する年次報告期間の開示から、2025年基準を適用できます。

改正基準も2026年に公表されています（出典: サステナビリティ基準委員会「サステナビリティ開示基準詳細」、2026年確認）。

基準名だけでなく、どの指標をどの報告書に出すかまで要件に落とし込みます。

入力・レビュー・承認を業務順に整理したワークフロー

実務で使えるシステムにするには、データを登録できるだけでなく、入力から承認までの流れを業務の順に整えておく必要があります。

• 承認フロー：拠点担当者が入力し、部門責任者、サステナビリティ部門が確認・レビューします。
• 証憑と承認：経理・法務・監査担当が証憑を確認し、経営層が承認します。
• 例外処理：差し戻しや期限超過、未入力を想定します。再計算、組織変更、過去値の訂正も含めて考えます。
• 履歴と保護：変更者、変更時刻、値を監査ログに残します。承認済みの値は、不用意に上書きできないようにします。

セキュリティ・連携・移行・運用の非機能要件

ESGデータには、人事情報や取引先評価、内部統制などが含まれることがあります。事故情報や取締役会関連情報が含まれる場合もあります。そのため、次のとおり要件に含めます。

• 認証・アクセス：ISO/IEC 27001などの認証を確認します。暗号化やSSO、MFA、権限分離も確かめます。
• 保護・通知：バックアップと脆弱性対応、データ所在を見ます。再委託先、インシデント通知期限、ログ保管期間も対象です。
• 移行・連携：Excel・紙の移行範囲、クレンジング担当、ERP・人事・購買・電力との連携本数を決めます。
• 運用：問い合わせ窓口、教育、並行運用の期間も、RFPに記載します。

契約形態（請負と準委任）の選び方

要件定義やデータモデル設計では、新しい開示基準や社内ルールが見つかることが多くあります。そのため、仕様を固定できる工程と、相談しながら進める工程を分けて考えます。

全工程を一つの契約形態にまとめるより、工程ごとに責任と成果物を定めるほうが現実的です。契約書の名称より、中身を優先して確認します。

納品物や検収条件、変更手続きが明確かを見ます。障害対応や、データの権利と返却方法も確かめます。

完成範囲と検収基準を固定できる場合の請負契約

請負契約では、合意した成果物を完成させて検収を受けます。成果物一覧には、指標マスタや入力画面、承認ワークフローを載せます。計算処理や証憑管理、ダッシュボードやCSV出力、API連携も、同じ一覧に含めます。

「Scope 1・2を集計できる」と確かめるだけでは足りないため、テストケースを具体的に作ります。単位換算や排出係数の版管理、差し戻し、承認後の訂正まで、テストケースに含めます。さらに、前年比較や証憑検索、仕様変更の見積方法と納期への影響も決めます。

準委任契約が向いている場合

準委任契約は、専門知識や作業の提供を受けながら、発注者と委託先が協力して進める場合に適しています。現状調査、指標の洗い出し、PoCのような工程に使いやすい契約です。データクレンジングや運用設計、導入後の改善にも使えます。

月ごとの作業内容や稼働時間、成果報告を決めます。加えて、意思決定者、未消化作業、品質の評価方法も定めます。完成保証の範囲は請負と異なるため、納期や動作保証を明確にします。

再委託・データ返却・障害時の責任の明文化

ESGデータは発注者の重要な情報です。そのため、データの扱いや障害時の責任を、契約で定めておきます。

• 権利と資産：システムや入力データ、算定ルールの扱いを定めます。設定情報と証憑、ログ、作成マスタも含みます。
• 委託先・保護：再委託先の事前承認と保管場所を確認します。バックアップや事故通知期限、脆弱性対応も確かめます。
• 停止・終了時：サービス停止時の復旧目標と、終了時のエクスポート形式、消去証明を定めます。
• SaaSの責任：サービス提供会社と導入支援会社の責任範囲を分け、障害時の連絡先を明確にします。

発注費用・相場の目安

費用は、製品ライセンスや初期設定、要件定義に分けて見積もります。さらに、データ移行や連携、開示支援、保守も、それぞれ見積もる対象です。

ESG専用製品は、拠点数、ユーザー数、指標数で価格が変わります。連携本数や対象国、開示基準、証憑保管年数によっても変わります。単一の固定相場はありません。

以下の金額は、リサーチノートと公開価格、類似するデータ管理システムの費用情報から整理した推定レンジです。正式な見積ではありません。

初期費用の推定目安：小規模SaaSは0〜100万円、中規模連携は500万〜2,000万円程度

初期費用、年間費用、導入期間は、導入の規模ごとの推定です。

• 小規模SaaS：初期0〜100万円、月額3万〜30万円、期間2週間〜2か月です。
• 20〜100拠点：初期100万〜500万円、年間100万〜1,000万円、期間2〜6か月です。
• 中規模連携：ERP・人事・購買・電力などと連携し、初期500万〜2,000万円、年間300万〜1,500万円、期間6〜12か月です。
• 変動条件：税や為替、ユーザー数、導入支援の範囲によって変わります。

公開価格の位置づけと総額との違い

Microsoft Sustainability Managerの日本語公式ページでは、EssentialsとPremiumの月額料金が公開されています。

公開料金は、導入支援などを含む総額とは分けて比較します。

• Essentials：テナントあたり月額4,000米ドルです。
• Premium：月額12,000米ドルです（出典: Microsoft「Microsoft Sustainability Manager」、2026年確認）。

要件定義やデータ移行、連携開発、教育は、別途費用になる可能性があります。Azureや他のMicrosoftライセンス、パートナー費用も別途発生することがあります。

ティーネットジャパンのestoma資料には、月額3万円（税抜）の記載があります。対象機能、ユーザー数、導入支援の範囲が異なるため、estomaとMicrosoftの料金は単純に比較できません。

連携・移行・運用費を含めたTCOでの比較

ライセンス以外の費用は、工程ごとの割合や連携費を含めて確認します。

• 工程割合：要件定義は約10%、設計は10〜20%が目安です。開発は40〜60%、テストは10〜20%です。
• ESG特有の費用：指標マスタやExcelでの洗い出し、データ整備が発生します。係数整理や証憑移行、API連携、教育も加わります。
• 連携費用：連携先ごとに数十万〜100万円程度、追加開発に1〜3か月程度かかる可能性があります。
• 大規模基盤：グループ会社やScope 3、多言語、監査対応を含む場合、初期は2,000万〜1億円以上です。
• スクラッチ：初期1,000万〜3,000万円以上、複雑な場合は1億円を超える可能性があります。

大規模基盤の年間費用は1,000万円〜数千万円、期間は12〜18か月以上が推定レンジです。工程割合は、リサーチノート「業務システム全般_6」の類似データ管理システム費用整理による目安です（2026年）。

ESG案件では、画面機能より指標定義や既存データ整備に予算が寄りやすい傾向があります。

見積書では、連携先ごとの作業と前提、テスト責任を分けて確認します。

ライセンス費だけで判断せず、TCOで比較します。TCOは、3年間の利用料や保守、クラウド、追加改修を合算したものです。開示基準対応と社内運用人件費も、同じ合算に含めます。

ESG情報管理システムの委託先の選び方

委託先選びでは、製品の知名度や機能数だけでなく、自社の開示範囲と運用体制への適合性を評価します。

ESG専用SaaSの提供会社、ERPやクラウド基盤に強い会社、データ連携やBIを得意とする受託開発会社があります。また、開示実務を支援するコンサルティング会社もあり、対応範囲はそれぞれ異なります。

同じRFPを各社に渡し、提案と見積、体制を同じ観点で比べます。さらに、実績と契約条件も並べて比較します。

似た業務フローでの実績確認

ESG導入実績の有無だけでなく、自社と同じ業種や拠点数、子会社構成の案件があるかを尋ねます。さらに、既存ERPや開示基準、指標数に近い条件の案件も聞きます。監査要件の案件があるかも確認します。

• 公開事例：IBM Envizi ESG Suiteの導入事例を確認します。
• 確認する内容：導入背景や選定理由、現場の入力方法を聞きます。データ移行や稼働後の支援も含め、自社との違いを判断します。

IBMは、アステラス製薬が2024年にEnvizi ESG Suiteの導入を決定したと紹介しています。

Go Liveは2025年10月に向けた事例です（出典: 日本アイ・ビー・エム「アステラス製薬におけるESGデータ管理の最前線」、2025年10月公開）。

既存環境と開示範囲に合う提案かの見極め

既存環境によって、候補に挙がる製品は変わります。

• Microsoft製品を標準利用：Microsoft Sustainability ManagerやPower Platformとの連携が候補です。
• SAP ERPが中核：SAP Sustainability Control Towerが候補です。
• グローバルで監査証跡を重視：IBM Enviziが候補に挙がります。
• Excelから段階移行：Excel・Web入力と証憑管理を備える製品が候補です。
• 部門横断の依頼・回答：開示ワークフローに強い製品が適しています。

候補企業には、MUST要件を標準機能、設定、追加開発のどれで実現するかを回答してもらいます。

契約前のセキュリティと運用支援の確認

契約前に確認したいのは、情報管理の安全性と導入後の支援体制です。安全性は認証や記録、委託の扱いで見て、支援体制は問い合わせ窓口や研修で確かめます。

• 認証とアクセス保護：ISO/IEC 27001などの認証を確認します。暗号化方式やMFA、権限の単位も確かめます。
• 記録と復旧：監査ログの検索方法や保存期間、バックアップ、復旧目標を見ます。
• 委託とデータ管理：脆弱性診断や再委託を確認します。データ所在と、契約終了時の返却も確かめます。
• 運用支援：基準改定時の更新責任と問い合わせ窓口を確認します。日本語マニュアル、拠点研修、年度末対応も含めます。
• 操作性：サンプルデータを使い、入力から承認、差し戻しまでをデモします。証憑確認と報告書出力も見て、現場で使えるかを評価します。

見積の比較ポイント

合計金額の安さだけで判断せず、提案書と見積書を照合します。要件ごとに、標準機能か設定か、追加開発か、運用サービスか別ライセンスかを確認します。

データ移行やAPI連携、教育が別料金なら、稼働までの総額は上がります。証憑保管や脆弱性対応、基準改定、サポート時間も、別料金かどうかを見ておきます。

見積の前提条件と含まれない作業の洗い出し

前提条件として、対象拠点数やユーザー数、指標数を確認します。過去データの年数やファイル容量、連携先も見ます。言語や環境数、同時利用者、サポート時間も、前提に含めます。

「データ移行一式」「連携一式」「導入支援一式」は、そのままにせず分解します。対象ファイル数や変換ルール、テスト回数に分け、発注者の準備物と完了条件も書き出します。作業量が未確定なら、上限金額や追加承認のルールを設けます。

機能・体制・リスク・TCOの評価表による採点

比較表には、機能以外の条件も評価項目として入れます。

• 評価項目：機能適合性、データモデル、開示基準へのマッピング、既存連携、証憑・監査ログ。権限、セキュリティ、期間、体制、保守、3年間のTCOです。
• 評価方法：価格と機能、納期と体制、リスクの比重を決めます。営業担当だけでなく、実担当のPMや技術者にも質問します。
• 提案の確認：提案企業が要件の不確実性を指摘し、前提条件とリスクを見積に明記しているかを評価します。

安い見積が高くなるリスクの確認

要件が流動的なまま請負で固定すると、変更管理が増えます。また、準委任と比べて見積が1.3〜1.5倍程度になる可能性があるという整理です（出典: リサーチノート「業務システム全般_6」のQ&A、2026年）。

• 数値の扱い：この倍率はESG案件の一律係数ではありません。
• リスク：基準対応や指標定義が未確定の段階で価格を固定すると、変更リスクがあります。
• 契約の分け方：要件定義やPoCは準委任で行い、仕様と検収条件が固まった開発を請負にするなど、変更量に合わせます。

発注後の進め方と失敗を防ぐポイント

まずは代表的な拠点と指標を選び、入力から開示出力までを検証します。全社への展開は、その後に進めます。

MVPで環境データと人的資本の必須指標を稼働させます。次に、連携や子会社、Scope 3へ広げ、サプライヤーや第三者保証へと進めます。こうした段階的な進め方は、費用と定着リスクを抑えやすいです。

プロジェクトの成否は、開発会社だけでなく、社内のデータオーナーと意思決定者を置けるかにも左右されます。

PoCでの入力・承認・証憑・出力の一連の検証

PoCでは代表的な2〜3拠点と複数指標を用意し、現場担当者が迷わないか確認します。

• 検証データ：請求書や検針票などの証憑を用意します。きれいすぎるサンプルでは、本番の欠損や表記揺れを見落とします。
• 操作検証：入力や単位換算、排出係数の適用を動かします。差し戻しや承認、修正履歴は実際に試し、拠点別比較と報告書出力まで確かめます。
• 例外データ：未入力や重複のあるデータで試します。組織変更や係数改定を含めた場合も確かめます。

運用責任者と基準改定への対応方法

稼働後は、運用責任者と基準改定の確認担当を決めておきます。

• 責任者：指標マスタや係数・算定式の改定、拠点入力の担当を明確にします。証憑確認と開示承認にも、担当を置きます。
• 定期確認：年度末だけに集中せず、月次または四半期で未入力、差し戻し、異常値を確認します。
• 基準改定：開示前に並行運用で突合し、SSBJや海外基準の更新担当と、製品設定・社内規程・RFPの更新箇所を決めます。

丸投げ・要件膨張・監査ログ不足の回避

初期導入では、次のような失敗が起きやすいです。

• 責任者不在：指標定義を決めずに開発会社へ任せます。
• 要件膨張：将来の要望まで初期開発へ詰め込みます。
• 費用漏れ：連携費や運用費を予算に含めません。
• 証跡不足：監査ログや証憑保管を後回しにします。

MUST要件は先に決め、WANT要件はロードマップへ分けます。

経営企画やサステナビリティ、経理を早くから参加させます。情報システムや法務、現場拠点も加わり、業務とシステムの責任分担を合意します。

よくある質問（FAQ）

外注では、価格だけでなく対象範囲や証跡、開示基準を確認します。連携と運用の条件も、確認の対象です。発注前によく寄せられる質問を、次に取り上げます。

ESG情報管理システムは無料で導入できますか？

小規模な試用や既存ツールの範囲で始められる場合はありますが、全社運用を無料で完結できるとは限りません。初期設定やデータ移行、連携には費用がかかります。さらに、証憑保管や教育、保守にも費用が発生します。

そのうえで、無料トライアルと本番導入の総額を分けて確認します。MVPで対象指標を絞り、段階的に予算化する方法が現実的です。

ESG情報管理システムの開発期間はどのくらいですか？

小規模SaaS導入は2週間〜2か月、20〜100拠点の収集・承認・ダッシュボードは2〜6か月が推定目安です。

複数システム連携を含む中規模案件は6〜12か月、大規模グループ基盤は12〜18か月以上が目安です。期間は、要件確定度やデータ品質、拠点数で変わります。連携本数や教育、並行運用によっても左右されます。

納品日だけでなく、マイルストーンも設定します。対象は、要件定義やPoC、移行、受入テストです。研修や稼働後支援も含めます。

RFPがなくてもESG情報管理システムを発注できますか？

発注はできますが、複数社の提案と見積を公平に比べるなら、簡易版でもRFPを作ることをおすすめします。RFPでは、対象拠点や指標、開示基準、連携先を整理します。

証憑や権限、希望時期も書き込みます。運用体制と予算の考え方も、RFPに含めます。

要件が未確定なら、最初のRFPで要件定義やPoCの提案を求め、開発範囲を後から確定する方法もあります。

外注先のセキュリティは何を確認すればよいですか？

ISO/IEC 27001などの認証と、データ保管場所を確認します。暗号化やMFA、権限分離も確かめます。

• 証跡と保護：監査ログとバックアップを確認します。脆弱性対応や再委託先も確かめます。
• 事故・終了時：事故通知、契約終了時のデータ返却と消去証明を確認します。
• アクセス範囲：人事・取引先情報は、担当者だけでなく会社・拠点・指標単位で制御します。
• 確認証憑：口頭回答で終わらせず、契約書やSLAで確認します。セキュリティチェックシートや第三者評価も見ます。

まとめ

発注前のRFPと責任分担の最終確認

RFPには、対象指標や組織範囲、開示基準、既存システムをまとめます。証憑や権限、連携、移行も加えます。

運用とセキュリティも、同じ書類に入れます。さらに、標準機能や設定、追加開発、別料金の範囲を確認します。

社内の意思決定者とデータオーナーを決めます。責任分担が明確なら、要件変更や障害時に判断者と費用を協議できます。

MVPからの段階導入と基盤の育成

導入範囲を絞って検証し、段階的に広げます。

• 初期範囲：必須指標と代表拠点を対象にします。
• 検証：PoCでデータ品質と操作性を確認します。
• 指標の拡張：環境・人的資本の指標へ広げます。
• 対象の拡張：システム連携、Scope 3・サプライヤー、第三者保証へ進みます。

社内で運用と基準改定を担える体制もつくります。発注時には、CO2計算だけでなく、E・S・Gの指標定義とデータオーナーを要件に含めます。証憑や承認、監査ログも、要件に加えます。

開示基準への対応も要件にします。方法は、SaaSやERP統合、ローコード、スクラッチから選びます。そのとき、独自要件と運用体制に合う方法かを見ます。

費用は小規模SaaSの初期0〜100万円程度から、大規模グループ基盤の初期2,000万〜1億円以上まで幅があります。推定レンジは、拠点数や指標数、連携によって変わります。移行や開示支援、保守でも左右されます。

RFPを共通化し、標準機能や設定、追加開発、運用費を分けて、3年間のTCOとセキュリティ条件で見積を比べます。これにより、発注後の追加費用と手戻りを抑えやすくなります。

意思決定者とデータオーナーを置き、委託先との責任分担を明確にすれば、基準変更後も改善を続けられます。

▼全体ガイドの記事
・ESG情報管理システム開発の完全ガイド

▼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を創業。