内部統制システム開発の完全ガイド

内部統制システムは、対象となる制度と業務範囲を決め、統制・権限・証跡をつないだうえで、重要な業務で試しながら運用を改善していく仕組みです。

制度と機能、導入の進め方、費用、開発会社の選び方、よくある失敗を押さえると、発注時の判断材料がそろいます。各テーマの詳細は関連記事で扱っています。

▼関連記事一覧
・内部統制システム開発の進め方/やり方/流れや方法/手法/工程/手順
・内部統制システム開発でおすすめの開発会社/ベンダー6選と選び方
・内部統制システム開発の見積相場や費用/コスト/値段について
・内部統制システム開発の発注/外注/依頼/委託方法について

内部統制システムの定義

内部統制システムは、経営者の方針を現場業務、情報システム、記録、評価、改善へ落とし込む仕組みの総称です。法令への適合は、その目的の一部にすぎません。まず制度上の対象を区別し、業務ごとに必要な機能と証跡を設計することが大切です。

内部統制が目指す4つの目的

内部統制には次の4つの目的があり、どれか一つだけを強めれば足りるわけではありません。

  • 業務の有効性と効率性
  • 財務報告の信頼性
  • 法令などの遵守
  • 資産の保全

たとえば購買申請の承認ルートを固定すると、不正の防止に役立ちます。ただし、マスタ変更の権限や支払データとの照合まで設計しなければ、財務報告の誤りを防ぐ統制としては不十分です。

金融庁の基本的枠組みは、統制環境、リスク評価と対応、統制活動を含む6要素で構成されます(出典:金融庁「財務報告に係る内部統制の評価及び監査の基準」、2023年)。残りの3要素には、情報の伝わり方、継続的な監視、IT面への対応が含まれます。

  • 情報と伝達
  • モニタリング
  • ITへの対応

システムは、ITへの対応を支えるだけでなく、権限・承認・記録・モニタリングを通じて複数の要素に関わります。

会社法上の内部統制とJ-SOXの違い

会社法上の内部統制とJ-SOXは、対象や手続が異なります。そのため、要件定義では、自社が扱う範囲を分けて整理します。

  • 会社法:取締役会が、取締役の職務執行や企業集団の業務を適正にする基本方針を定め、運用状況を確認する。
  • J-SOX:金融商品取引法に基づき、上場会社などが財務報告に係る内部統制の有効性を評価し、報告と監査を受ける制度。
  • 要件定義:J-SOX評価、会社法上の基本方針や内部監査、申請・承認と証跡の電子化を踏まえて対象を決める作業。

両者は重なる部分もありますが、対象資料、評価手続、報告先は完全に同じではありません。金融庁は2023年4月、評価範囲の選定や不正リスク対応を含む基準・実施基準を改訂しました。この改訂は、2024年4月以後に開始する事業年度の実務に影響しています(出典:金融庁、2023年)。

製品を探す前に、自社が説明すべき対象を先に確定してください。

内部統制システムの種類と主要機能

内部統制システムを構成するGRC・評価管理、申請・承認、既存システムの統制機能、文書・証憑管理を4枚のパネルで示した図。
必要な機能を組み合わせて統制情報と証跡をつなぎます。

内部統制システムは、GRC・評価管理と申請・承認ワークフローを軸に、必要な機能を組み合わせて作る方式があります。組み合わせる機能には、次のようなものもあります。

  • ERPや会計システムの統制機能
  • 文書・証憑管理

既存の会計・販売・購買・人事システムを残し、統制情報と証跡を連携させる設計もあり、すべてを単一のシステムに置き換えるとは限りません。

J-SOX・GRC型で管理する情報

J-SOXやGRCでは、リスク、統制目的・活動、キーコントロールを一つの台帳で追います。担当者や評価頻度、証憑、例外、不備、是正計画も、その台帳で管理します。

業務記述書、業務フロー図、RCMの3点セットを登録します。RCMは、リスク・コントロール・マトリクスのことです。加えて、次の内容も記録します。

  • 評価対象の変更履歴
  • 評価者レビュー
  • 証憑の差し替え
  • 監査人への提出状況

共有フォルダだけでは最新版が分からず、担当が変わったあとの経緯や期限超過も追いにくくなります。そのため、版数、承認状態、適用期間、関連プロセスを記録できる仕組みが必要です。

ワークフロー・証跡管理型で押さえる機能

申請・承認を電子化するときは、紙をPDFにするだけでなく、業務ごとに必要なフォームや承認機能を確かめます。

  • 申請・承認:稟議、購買、経費、契約、マスタ変更のフォームとルート
  • 例外処理:差戻し、代理承認、期限超過通知
  • 権限と変更:申請・承認者の分離、承認後の変更制限、ルート履歴
  • 証跡の保管:添付、操作ログ、設定、差戻し理由、例外、復旧履歴を、必要な期間保管
  • 監査での利用:記録を検索・出力できる状態

証跡は、誰がいつ、どの端末や経路から、何を申請・承認・変更したかを追えるように残します。会計や購買のデータと連携する場合は、連携に失敗したときの通知と再送、重複登録の防止も要件に含めます。あわせて、バックアップからの復旧履歴も証跡として保管します。

IT全般統制とIT業務処理統制

IT統制は、システム全体を管理する統制と、個別業務の処理に組み込む統制に分けられます。

  • IT全般統制:アクセス権限、職務分掌、プログラム変更、障害対応、バックアップ、委託先管理、運用手順
  • IT業務処理統制:個別業務の入力チェック、承認、計算、照合、エラー処理

たとえば、経費申請の上限超過を上位者へ回す機能は業務処理統制に当たります。一方で、承認者マスタの変更権限や、その変更のテストと承認、退職者アカウントの停止はIT全般統制の論点です。

機能の一覧に加えて、統制目的と管理責任の対応表を作ると、抜け漏れを見つけやすくなります。

ポイント

機能を選ぶときは、統制目的ごとに必要な証跡が残るかを基準にします。機能の数だけで比べると、例外処理や権限の抜けを見落としやすくなります。

内部統制システム開発・導入の進め方

対象範囲の整理、重要業務でのPoC、設計と受入テスト、稼働後の評価と改善へ進む内部統制システム開発の段階図。
PoCと受入確認を経てから稼働後の改善へつなげます。

内部統制システムは、契約を結んだだけでは完成しません。まず現状の業務と統制の差を確かめ、対象を絞り、重要な業務で試したうえで、証跡が残ることを確認してから展開します。監査対応を後付けにすると、稼働後に帳票やログを作り直す手間が生じます。評価と監査の手続は、初期設計に含めてください。

▶ 詳細はこちら:内部統制システム開発の進め方/やり方/流れや方法/手法/工程/手順

目的・対象範囲と現状業務の整理

まず、対象の会社・部門・業務を一覧にします。そのうえで、勘定科目、データ、評価対象、キーコントロールも同じ表に加えます。制度や業務の範囲によって、必要な機能と期間は変わります。

  • 制度の範囲:J-SOX、会社法、内部監査、コンプライアンス、情報セキュリティ
  • 体制:経営企画、経理、内部監査、情報システム、現場部門から責任者を出し、意思決定の場を早めに設ける

申請・承認・記録・照合・レビューが、紙やExcel、メール、ERPなどのどこで行われているかを洗い出します。

業務記述書やフロー図と実際の運用は、異なることもあります。そこで、帳票、例外処理、代理承認、月末の手作業を確かめ、MUSTとWANTを分けておきます。

方式の比較と重要業務でのPoC

方式を比べる際は、まず、標準機能に合わせる範囲と、既存ルールをカスタマイズする範囲を決めます。

  • パッケージ・SaaS:標準ワークフローやGRCを利用
  • 既存ERP:追加機能で対応
  • 個別開発:既存ルールに合わせて構築
  • 比較基準:統制情報と証跡の連携、変更時の影響の追跡性

候補には、購買・支払、経費、契約、マスタ変更などがあります。そのうえで、重要度が高く、互いに異なる1〜2業務を選び、PoCを行います。

申請から承認、会計連携、証憑保管、ログ検索、監査向け出力までを、実データに近い条件で試します。現場と管理者の操作負担も測ります。画面の使いやすさだけでなく、例外が起きたときにも統制が崩れないかを確かめます。

設計・構築・移行・受入テスト

設計では、運用と連携に必要な権限、記録、障害対応を定めます。

  • アクセスと承認:RBACによる役割権限、職務分掌、承認ルート、代理承認
  • 運用基盤:ログ保存期間、バックアップ、障害時の代替運用
  • 連携とデータ:API連携、データの所有権
  • 移行とテスト:資料の区分、機能・異常系・連携・証跡の確認
  • 受入確認:利用部門のUATで通常業務と月次・四半期・年度の評価業務を確認

人事異動や組織改編のときに、権限を変える人と時期、承認者が不在のときの手続も決めます。

移行では、ユーザーと組織、帳票を対象にします。3点セットや証憑、過去の評価結果も対象で、それぞれを移行、保管、廃棄のいずれかに区分します。

テストでは、アクセス権のレビューや異常系、連携の失敗を確かめます。あわせて、ログ出力、バックアップからの復旧、監査資料の作成も確認します。

稼働後の評価と改善

稼働後は、業務の停滞と統制の実効性をKPIで追います。

  • 業務の状況:申請滞留時間、差戻し率、未承認の期限超過
  • 統制の状況:権限レビュー完了率、証憑登録漏れ、不備再発率

申請件数だけを見ると、入力の負荷を避けた迂回を見落とすおそれがあります。そのため、利用が続いているかと、監査証拠がそろっているかを同時に評価します。

規程の改定や組織の変更、法令や監査方針の変更があったときは、業務フロー、RCM、承認ルート、マニュアルを更新します。内部統制は、リスクの変化に応じて見直し続けるものです。

生成AIを補助的に使う場合は、出力のレビューや利用ログ、機密データの入力制限を決め、最終判断者を明確にします。AIの提案だけを証跡にしない運用も必要です。

ポイント

導入の判断は、重要業務でのPoCで申請から監査向け出力までを通せたかで決めます。監査対応を後から足すと手戻りが増えるため、評価と監査の手続は設計の段階で含めます。

内部統制システムの費用相場とコスト内訳

部門ワークフロー、全社ワークフロー、J-SOX・GRC、横断基盤刷新、大規模・個別開発の5パターンについて費用目安を横棒で比べた図。
導入範囲が広がるにつれて費用帯も大きくなります。

費用は、申請・承認の範囲や利用者数、既存システムとの連携で変わります。3点セットや評価調書の移行、監査支援の範囲も、費用を左右します。

専用GRCは個別見積が多いため、ここで示すのは、ワークフロー、文書管理、GRC、連携開発を組み合わせる場合の実務上の目安です。設定、移行、教育、運用支援も分けて見積もります。

▶ 詳細はこちら:内部統制システム開発の見積相場や費用/コスト/値段について

導入パターン別の費用目安

導入範囲が広がるほど費用と期間も大きくなります。そこで、パターン別の目安を比べて確認します。

  • 部門ワークフロー:1〜2部門で50万〜300万円程度、1〜3か月。
  • 全社ワークフロー:帳票移行、権限・SSO、会計連携を含め300万〜1,000万円程度、3〜6か月。
  • J-SOX・GRC:台帳、3点セット、評価・不備管理を含め500万〜1,500万円程度、4〜9か月。
  • 横断基盤刷新:ERP・会計・購買・人事を横断し1,500万〜4,000万円以上、6〜18か月程度。
  • 大規模・個別開発:グループ、多言語、複雑な権限、スクラッチGRCを含め3,000万円〜1億円超、12〜24か月以上。

実際の金額は、帳票の数や承認の分岐、既存データの状態などによって変わります。

見積書で分けて示す費用項目

見積書では、費用を作業や提供内容ごとに分けて示してもらいます。

  • 製品・導入:製品・ライセンス、導入設定
  • 移行・連携:データ移行、API・CSV・SSO連携
  • 設計・定着:統制設計・文書化、テスト、教育
  • 運用支援:保守・評価支援

一式表記では、追加費用が生じる条件が分かりません。各項目の対象範囲と数量、単価を記載してもらい、あわせて前提と除外条件、変更時の精算方法も明記してもらいます。

公開されている価格の例では、クラウド型ワークフローは初期費用0円で、1ユーザー月額500円からの料金体系です。100ユーザーなら基本利用料は月5万円、年60万円です。また、基本料金、セキュリティオプション、フォーム移行、複雑な承認ルート、連携、教育は別途確認します。

安いライセンス料を、内部統制システム全体の費用とみなさないでください(出典:クラウド型ワークフロー提供事業者の公式料金表、2026年確認)。

3年間の総保有コストでの比較

初期費用だけでなく、3年間の総保有コストで比べます。

  • 共通費用:利用料、連携、変更、問い合わせ、教育、監査資料、保管拡張
  • オンプレミス等:サーバー、監視、パッチ、障害対応、担当者の教育・交代
  • 補助金の対象候補:2026年通常枠の導入関連費など

共通費用は導入後も続くため、将来分まで見積もってください。2026年の通常枠では、ソフトウェア購入費、クラウド利用料の最大2年分、導入設定、研修、保守などが対象になり得ます。補助額は、1プロセス以上の場合は5万円以上150万円未満、4プロセス以上の場合は150万円以上450万円以下です。

補助率は原則1/2以内、条件により2/3以内です(出典:中小企業向けデジタル化・AI導入補助金2026通常枠、2026年)。対象ITツールと登録支援事業者には要件があります。交付決定の前に契約や発注をせず、公募要領の最新の条件を確認してください。

ポイント

費用は、対象範囲、利用者数、連携、移行、運用支援を項目ごとに分けて比べます。3年間の総保有コストで見ると、初期費用の安さだけで選ぶ誤りを防げます。

内部統制システムの開発会社・ベンダー・サービスの選び方

開発会社やサービスは、知名度や機能数だけでなく、自社の統制設計を理解し、導入後の運用を支えられるかで選びます。

「J-SOX対応」と書かれていても、製品だけで法令適合や監査の通過が保証されるわけではありません。ただし、リスク、統制、権限、証憑、評価手続をシステムに反映する責任は、企業側に残ります。

自社の課題と導入実績の適合

候補先の得意分野を、自社の課題と照らして確認します。

  • 得意分野:リスク・評価管理、ワークフロー・証跡、ERP・会計・購買連携
  • 自社との適合:業種、利用者数、拠点数、グループ構成、既存システム、導入期間が近い事例

財務報告の評価管理と紙の承認電子化では、優先すべき機能が異なります。実績を尋ねる際は、3点セットの整理担当、監査人との論点整理、稼働後の権限レビューや不備管理の支援範囲を確認します。

導入社数だけでなく、導入前後の課題、期間、追加開発範囲、利用企業側の担当人数も聞くと、再現性を判断しやすくなります。

セキュリティと監査証跡の確認事項

クラウドのセキュリティと監査証跡は、次の観点で確認します。

  • セキュリティ:アクセス保護、運用継続、障害・脆弱性への対応
  • データ管理:ログ、データ返却・削除、サービス終了時の移行
  • 委託先の保証:報告書・認証と監査利用の範囲

データの所在や暗号化、認証(MFA・SSO)、IP制限、権限管理を確認します。あわせて、ログやバックアップ、復旧目標、脆弱性対応、インシデント通知も見ます。

委託先のSOC 1・SOC 2・ISO 27001などは、有無だけでなく、監査人が使える範囲と自社に必要な手続まで確認してください。

経済産業省はシステム監査基準・システム管理基準を整備し、財務報告に係るIT統制ガイダンス追補版を2024年12月に改訂しています(出典:経済産業省「システム監査制度について」、2026年6月更新)。これらの基準やガイダンスを踏まえ、アクセス、変更、運用、委託先管理を説明する資料が提供されるかを見ます。認証マークの有無とは別に、証跡の粒度と、どこまでを誰が受け持つかを契約前に明文化します。

RFPと契約での比較条件

RFPには、候補先が同じ条件で回答できるよう、自社の前提を記載します。

  • 組織と業務:組織図、対象業務、利用者数、帳票数
  • 既存環境:ERP・会計システム、3点セットの有無、監査指摘
  • 導入条件:希望稼働時期、保存年数、連携方式

候補先には、標準機能、設定、個別開発、運用で補う範囲を分けて回答してもらいます。デモで自社の申請から証跡出力までを実演すると、カタログとの差が分かります。

契約では、納品物と受入基準、データ移行の責任を明確にします。障害対応時間やサービスレベルも、あわせて定めます。

さらに、ログとバックアップの保管、再委託、情報管理を取り決めます。データ返却や解約時の移行支援、追加開発の単価も、契約に含めます。

監査人から追加の資料を求められた場合の対応範囲も記載します。価格だけでなく、将来の組織変更や法令対応を含めた変更のしやすさで比べてください。

▶ 詳細はこちら:内部統制システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら:内部統制システム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、自社の統制設計を理解し、導入後の運用を支えられるかで選びます。認証マークや機能数だけで決めると、どこまでを誰が受け持つかが曖昧なまま残りやすくなります。

内部統制システム導入でよくある失敗と対策

機能を追加するほど安心できるとは限りません。対象範囲、責任者、例外時の手続、運用負担を決めないまま導入すると、現場で使われず、監査資料も揃わないことがあります。

代表的な失敗を確かめ、その対策を導入計画に組み込んでください。

既存業務の再現による複雑化

紙やExcelの項目をすべて移行し、例外承認まで個別開発すると、初期費用も変更費用も増えます。

必要な統制と、慣習的に行っている手順を分けて考えます。そのうえで、標準機能に合わせる業務、簡素化する業務、個別に対応する業務を決めます。

個別開発の場合は、法令や監査方針、組織の変更に伴う改修を、誰が何日で行うかを確認してください。

ツール導入だけで監査に通るという誤解

ログや承認機能があっても、リスク評価や権限分掌が不十分なら、内部統制を有効に運用できません。証憑が統制目的に合わない場合や、評価者レビューがない場合も、有効な運用にはつながりません。

製品に「対応」と表示されていても、企業側の設計、設定、運用の代わりにはなりません。監査人への確認事項を整理したうえで、設計書、設定一覧、テスト結果、運用記録を残してください。

導入後の責任者と更新手順の不在

稼働後の権限申請、異動の処理、規程の改定、証憑の期限、不備の是正を担う人がいないと、数か月で情報が古くなります。

業務部門、経理・内部監査、情報システム、外部委託先の間で、どこまでを誰が受け持つかをRACIなどで明示します。あわせて、月次・四半期・年度の作業カレンダーを作成します。

問い合わせ窓口、設定変更の申請、緊急時の承認、ログの定期レビューも決めておきます。差戻しや期限超過が多い部門を月次のKPIで確認すると、負担を抑えながら統制を改善できます。

ポイント

導入の前に、対象範囲、責任者、例外時の手続、運用負担を決めておきます。これらが決まっていないと、現場で使われず監査資料も揃わない事態が起きがちです。

内部統制システムについてよくある質問(FAQ)

内部統制システムを検討する企業からよく寄せられる質問に、制度上の義務、ワークフローだけでの対応、クラウドやExcelからの移行、補助金、監査法人との関係の順に答えます。

内部統制システムの導入は義務ですか?

上場会社などは、財務報告に係る評価や報告、監査が関係します。ただし、すべての企業に同じ製品の導入が義務づけられているわけではありません。

会社法上は、取締役会が基本方針を決める場面もあります。対象範囲と手続は、会社の規模や上場の状況、事業内容によって異なるため、法務、経理、内部監査と確認してください。

ワークフローだけでJ-SOXに対応できますか?

ワークフローは申請・承認・証跡を電子化する部品ですが、それだけでJ-SOX全体に対応できるとは限りません。

リスク評価、3点セット、権限・変更管理に加え、IT全般統制、評価・不備管理、監査資料の提出まで必要なら、台帳や連携、運用手続を組み合わせます。

重要業務を一つ選び、統制目的と必要証拠を整理してから範囲を決めてください。

クラウド型でも監査に対応できますか?

クラウド型でも監査対応は可能ですが、クラウドだから自動的に適合するわけではありません。

アクセス権や変更管理、ログ、バックアップを確認します。あわせて、委託先管理や障害時の代替手続、データ返却も確かめます。提供者の報告書を自社の監査手続で使えるかは、監査人に相談してください。

利用企業側にも、設定、権限レビュー、運用記録が必要です。

中小企業やIPO準備企業にも必要ですか?

上場準備、取引先への統制説明、拠点や従業員の増加、経理・購買の属人化がある中小企業は、早めに整備する価値があります。

まずは、購買・支払、経費、契約、権限管理など重要な1〜2業務から始め、監査で説明できる記録を残す方法もあります。最初から全社のGRCを導入する必要はありません。

将来の利用者数や子会社展開を見据え、後から拡張できる方式を選んでください。

Excelや紙の資料から移行できますか?

移行はできますが、まず現行の資料を、最新版、履歴として保管するもの、廃棄の候補に分類します。対象となるのは、業務記述書やフロー図、RCMなどの文書です。文書に加えて、次の記録やデータも、同じ区分で分けます。

  • 評価調書
  • 証憑
  • ユーザーと組織の情報

分類した資料には、版数や適用期間も付けます。

移行後は、サンプル照合、件数と権限の確認、検索と出力のテストを行います。あわせて、原本の保存が必要かどうかも、法務や監査の担当者と確認してください。

補助金を使えるか、監査法人の承認を得られますか?

補助金の対象は、ITツール、申請枠、事業者区分、申請時期、対象経費によって決まります。内部統制の機能があるからといって、対象になるわけではありません。

2026年制度の通常枠では、ソフトウェア、クラウド利用料、導入関連費などが対象になり得ます。公募要領と登録状況を確認してください。

監査法人への相談では、自社のリスク評価、統制設計、証拠、評価手続の妥当性を取り上げます。製品導入の承認を得る場ではない点に注意し、導入前から論点を共有してください。

まとめ:証跡と運用まで設計する内部統制システム

内部統制システムは、会社法上の基本方針、J-SOX、内部監査、情報セキュリティ、申請・承認、証憑管理を、目的に応じて組み合わせます。対象範囲と3点セット、実際の業務を洗い出し、リスク、統制、権限、証跡、評価を一つの流れとして設計してください。

導入前に確認する5つのポイント

導入前には、対象制度と業務範囲、現状の証跡と不備を確認します。加えて、次の項目も確認します。

  • 権限・承認ルール
  • 連携・セキュリティ要件
  • 稼働後の責任者

初期構築だけでなく、移行、教育、保守、監査対応、組織変更まで含めた3年間の総保有コストで比べてください。重要な業務でPoCを行い、申請から監査向けの出力まで通してみると、導入後の手戻りを抑えられます。

対象業務と必要な証拠の一覧化

製品や開発会社を決める前に、比較の基準となる情報を一覧にします。

  • 統制情報:対象業務、リスク、統制活動、担当者、証憑、評価頻度
  • 現状の課題:現在の運用で解決したい点

この一覧をRFPや比較表の基準にして、標準機能、設定、個別開発、運用のどこで対応するかを、候補先に示してもらいます。

制度・認証・補助金の条件は更新されます。そのため、公開の前後に最新の資料を確認し、必要に応じて監査人や専門家へ相談してください。

▼関連記事一覧
・内部統制システム開発の進め方/やり方/流れや方法/手法/工程/手順
・内部統制システム開発でおすすめの開発会社/ベンダー6選と選び方
・内部統制システム開発の見積相場や費用/コスト/値段について
・内部統制システム開発の発注/外注/依頼/委託方法について

 

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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