事業計画管理システム開発の発注/外注/依頼/委託方法について

事業計画管理システムの発注では、単に予算を入力する画面を作るのではなく、中期計画・年度予算・見込・実績・KPIを同じルールで管理し、経営判断につなげる業務全体を設計することが重要です。発注形態、RFP、契約方式、費用、委託先の比較を先に整理しておくと、開発途中の追加要望や運用開始後の手戻りを抑えられます。

この記事では、事業計画管理システムを外注・委託するときの進め方を、パッケージやSaaSの導入、既存基盤の拡張、スクラッチ開発の違いから解説します。RFPに盛り込む要件、請負と準委任の使い分け、2026年時点での費用レンジ、見積書の比較方法、失敗しやすい契約上の注意点まで、発注前に確認したい実務をまとめています。

▼全体ガイドの記事
・事業計画管理システム開発の完全ガイド

事業計画管理システムの発注・外注で最初に決めること

事業計画管理システムの発注方針を整理する会議

事業計画管理システムの発注で最初に行うのは、製品名や開発会社を探すことではありません。何を計画し、どのデータを連携し、誰がいつ承認し、どの会議でどの指標を見るのかを決めることが出発点です。事業計画書を作成してPDFにするだけなのか、予算・見込・実績の差異分析まで行うのかによって、必要な仕組みも費用も大きく変わります。

目的と対象範囲を一文で説明できるようにします

まず「予算編成の集計時間を短縮する」「月次の予実差異を事業部別に説明できるようにする」「子会社を含むローリングフォーキャストを統一する」など、導入目的を一文で表します。次に、対象会社、部門、拠点、製品、顧客、案件、期間、通貨、勘定科目、KPIの粒度を決めます。対象範囲が曖昧なまま外注すると、委託先ごとに想定する業務が異なり、同じ見積書を比較できません。

Excel運用の何を残し、何を変えるかを切り分けます

既存のExcelは、入力項目、数式、マスタ、ファイルの版、承認者、提出期限、過去データを棚卸しします。柔軟なシミュレーションや現場固有の分析は残す一方、同じ数値を複数ファイルへ転記する処理や、メール添付による承認はシステムへ移す候補です。既存Excelをそのまま画面化するだけでは、属人化したルールや誤入力まで引き継ぐため、業務上の必須条件と慣習的な作業を分けて整理する必要があります。

発注形態は業務の成熟度と独自性で選びます

発注形態は、SaaS・クラウドサービスの導入、パッケージの設定と追加開発、ローコードや既存基盤の拡張、スクラッチ開発、複数サービスを組み合わせるハイブリッドの五つに分けて比較します。標準的な予算・予実管理を早く始めたい企業はSaaSやパッケージが候補です。独自の配賦、案件別採算、特殊な承認、複数システムの複雑な連携が競争力に直結する企業は、個別開発や既存基盤の拡張が候補になります。最初から全社機能を作り込まず、1事業部や1回の予算編成を対象に先行導入する方法も有効です。

事業計画管理システムの発注・外注はどこから始めますか?

事業計画管理システムの要件を整理する担当者

発注は、現行業務の可視化、要件整理、RFP作成、候補先の選定、提案・見積比較、契約、要件定義、開発・設定、テスト、移行、教育、運用評価の順に進めます。最初に作るべきものは詳細な画面仕様書ではなく、目的、対象範囲、優先順位、データの流れ、受入条件をまとめた発注方針です。これがあると、SaaSの導入支援会社とスクラッチ開発会社を同じ視点で比較できます。

現状分析で業務フローとデータの流れを描きます

経営企画、財務、事業部、情報システムの担当者から、計画策定、予算回収、実績取込、差異分析、会議資料作成までを聞き取ります。業務フローには担当者だけでなく、入力締め日、承認、差戻し、変更履歴、例外処理、会議で使う帳票を記載します。データフローでは、会計・ERPから実績、SFAから売上見込、人事システムから人員、ExcelやCSVから事業計画を取り込むのかを示します。

この段階で、会社・部門・期間・勘定科目・指標の共通マスタも確認します。例えば、事業部ごとに「売上」の定義や締め日が違う場合、機能を追加しても数字を比較できません。システム開発の前に、定義を統一するか、異なる定義を併存させるかを経営側で決めることが大切です。

MUSTとWANTを分けて段階導入の範囲を決めます

MUSTには、予算と実績を同じ粒度で比較する、承認履歴を残す、権限を分ける、会計データを取り込むなど、稼働に不可欠な条件を置きます。WANTには、複数シナリオの高度なシミュレーション、AIによる予測補助、細かなドリルダウン、特殊な帳票などを置きます。WANTを初回リリースへ詰め込み過ぎると、開発期間とテスト範囲が広がり、現場が使い始める前に要件が陳腐化する可能性があります。

先行導入の受入条件は「1回の月次予実を締められる」「予算と見込の版を区別できる」「差異の根拠をコメントで追える」など、利用場面で測れる形にします。画面数や機能数ではなく、入力時間、集計時間、差異説明に要する日数、エラー件数などを導入前に計測しておくと、投資効果を評価しやすくなります。

PoCと受入テストで実データに近い運用を確認します

候補サービスや開発会社が決まったら、実際のExcel項目、過去の実績、権限パターン、会議用レポートを使って小さな検証を行います。サンプルデータだけでは、欠損、コードの揺れ、締め日違い、手入力の例外が見えません。機密情報を渡す場合は、匿名化、利用目的、保管期間、返却・削除の方法を契約や発注条件に記載します。

受入テストでは、要件一覧の各項目を「合格・条件付き合格・不合格」で判定できるようにします。計画入力、承認と差戻し、会計連携、予実差異、権限違反の防止、バックアップからの復旧、CSV出力などを業務シナリオで確認します。AIによる予測や異常検知を使う場合も、予測値の根拠を確認できることと、最終判断を担当者が行えることを受入条件に含めます。

RFP・要件整理で発注先に伝えるべき項目

RFPで事業計画管理システムの要件を整理する場面

RFPは、発注者の課題と期待する提案内容を候補先へ同じ条件で伝える文書です。機能の羅列だけでなく、現状、目的、対象範囲、データ、体制、スケジュール、予算の考え方、提案書と見積書の提出形式を明記します。候補先が独自の前提を置いてよい部分と、必ず守る条件を分けると、提案の違いが見えやすくなります。

RFPには業務・利用者・データ・期限を記載します

基本情報として、会社数、部門数、拠点数、利用者数、想定する同時利用、予算編成の回数、月次締めの期限、稼働希望月を記載します。業務要件としては、中期・年度・四半期・月次の計画、トップダウン目標とボトムアップ計画の調整、予算・見込・実績の版管理、配賦、KPI、コメント、承認、レポートを整理します。経営層向けの集約画面と、事業部が入力する画面は目的が違うため、利用者別に書き分けます。

連携要件では、会計・ERP・販売管理・人事・SFA・DWH・BIの製品名、接続方式、更新頻度、データ量、過去データの移行範囲、エラー時の再送方法を記載します。APIを標準とするのか、CSVを暫定利用するのかも明示します。入力と連携の責任分界が曖昧だと、障害時に原因を追えないため、送信元、変換処理、受信側、監視担当をRFPの図に入れると安心です。

セキュリティとデータ所有権を機能要件と同じ重さで確認します

権限は会社、部門、役職、担当者、参照・入力・承認などの操作単位で定義します。MFAやSSO、暗号化、操作ログ、バックアップ、障害時の復旧目標、脆弱性対応、委託先の再委託、データセンターの所在、サービス停止時の連絡方法も確認対象です。会計データや人員計画などを扱う場合は、開発会社の標準セキュリティ資料だけでなく、自社の規程と監査要件に照らして評価します。

国税庁は、電子取引を行った場合、取引情報に係る電磁的記録を一定の要件で保存する必要があると説明しています(出典: 国税庁「電子帳簿保存法の概要」、2026年確認)。事業計画管理システムが直接の保存システムでない場合でも、見積書、契約書、請求書、承認記録をどこで保管し、検索・閲覧・出力できるようにするかを発注時に確認します。納品後にデータを取り出せる形式、仕様書の引き渡し、契約終了時の返却・削除も、ベンダーロックインを避ける重要な条件です。

提案書と見積書の提出条件をそろえます

候補先には、機能対応表、業務フロー、導入体制、プロジェクト計画、前提条件、リスク、導入後の支援内容を同じ順番で提出してもらいます。見積書は、ライセンス、初期設定、要件定義、設計、開発、連携、データ移行、テスト、教育、運用保守、追加変更の単価を分けてもらいます。「一式」だけの見積もりは安く見えても、何が含まれるか分からず、後から追加請求が発生しやすくなります。

提案の前提が違う場合は、候補先に確認質問を返してから再提出を依頼します。例えば、会計連携が標準機能なのか個別開発なのか、移行対象が直近1年なのか過去5年なのか、研修が何回含まれるのかで、金額も期間も変わります。比較の公平性を保つには、各社の提案を同じ要件番号にひも付け、対応方法を「標準・設定・追加開発・対象外」で記録する方法が有効です。

契約形態は請負・準委任・SaaS利用を分けて考えます

事業計画管理システムの契約条件を確認する担当者

事業計画管理システムの外注では、工程によって適した契約形態が変わります。完成すべき機能と検収条件を明確にできる開発工程は請負、要件が変わりやすく専門人材の支援を受けながら進める工程は準委任、サービスを継続利用する部分はSaaSの利用契約として整理します。一つの契約にすべてをまとめるのではなく、成果物、責任、変更手続き、支払い条件を工程ごとにそろえることが重要です。

請負契約は成果物と検収条件を具体化します

請負契約を採用する場合は、要件定義書、画面・帳票仕様、データ連携仕様、テスト計画、操作マニュアル、移行データ、ソースコードや設定情報など、納品物を一覧化します。検収では、要件を満たすことだけでなく、性能、権限、エラー処理、バックアップ、復旧、既知の不具合の扱いを定めます。検収後の瑕疵対応期間、修正の範囲、第三者ソフトウェアのライセンスも契約書と仕様書の両方で確認します。

準委任契約は体制・作業範囲・報告を明確にします

準委任契約では、特定の完成結果よりも、合意した業務を専門家が適切に遂行することが中心になります。要件が固まっていない構想策定、現状分析、データ棚卸し、プロジェクト管理、アジャイルな改善では使いやすい契約形態です。一方で、作業時間や人月だけを管理すると、導入効果や優先順位が見えにくくなります。

月次の作業報告、稼働予定、課題一覧、意思決定事項、次月の成果目標を定例会で確認します。委託先の担当者へ自社社員が直接指揮命令する運用は契約上の論点になり得るため、業務指示と進捗確認の窓口を明確にします。追加作業の依頼方法、単価、上限時間、再委託の承認、途中解約時の引き継ぎも事前に定めます。

SaaS契約は月額以外の費用と終了条件を確認します

SaaSでは、月額または年額の利用料だけでなく、初期設定、環境構築、ユーザー追加、データ容量、API連携、導入支援、研修、個別帳票、サポートの範囲を確認します。価格がユーザー数課金なのか、会社数・モジュール・データ量課金なのかで、利用拡大後の総額は変わります。無料期間やPoCのデータを本番環境へ移せるかも、契約前に確認したいポイントです。

契約終了時に、計画・実績・マスタ・コメント・承認履歴をどの形式で返却してもらえるか、返却費用はいくらか、削除証明を発行できるかを確認します。サービス障害時の補償やSLAだけでなく、アップデートで画面やAPIが変わる場合の通知期間、既存連携の維持責任も、長期運用の見積もりに含めます。

事業計画管理システムの費用相場と見積もりの内訳

事業計画管理システムの費用と見積もりを確認する場面

事業計画管理システムの費用は、利用人数だけでなく、対象会社数、管理軸、連携先、過去データの移行量、承認フロー、帳票、導入支援、保守範囲で変わります。以下はリサーチノートと公開価格、一般的な導入範囲から整理した2026年時点の目安です。各レンジは正式見積もりではなく、要件と前提条件をそろえたうえで比較するための基準として使います。

小規模クラウド導入は初期0〜300万円程度が一つの目安です

1社または少数部門で、計画入力、予算・実績比較、基本レポート、簡単なCSV連携に絞る場合、初期設定・データ移行・研修を含む初期費用は0〜300万円程度が推定レンジです。利用料は数万円から数十万円の月額になる場合があり、利用人数や機能で変わります。公開価格の例として、Forecast-planningは1ユーザー月額15,400円(税込)、6ユーザー79,200円などを掲載していましたが、2025年4月に新規サービス申込受付停止の告知もあるため、現在の提供状況は必ず再確認します(出典: Forecast-planning公式ニュース・価格情報、2026年確認)。

小規模導入でも、API連携、Excelの複雑な数式移行、複数の承認経路、個別帳票が加わると支援費用が増えます。月額だけで判断せず、初年度のライセンス、初期設定、移行、教育、保守を合計した初年度総額と、2年目以降のランニング費用を分けて見積もります。

部門単位の拡張は初期300万〜1,500万円程度が推定レンジです

複数部門で、承認、会計連携、予実差異、KPI、過去データ移行、経営会議レポートまで含める場合、初期費用は300万〜1,500万円程度、期間は3〜6か月程度が一つの推定レンジです。パッケージやクラウドを基盤に設定する場合でも、業務整理、マスタ統一、連携、テスト、教育の比率が高くなります。対象範囲を明確にしないまま「全社導入」と見積もると、会社数や管理軸の増加で金額が大きく変動します。

費用配分の目安として、リサーチノートでは要件定義約10%、設計10〜20%、実装40〜60%、テスト10〜20%を挙げています。ただし、SaaS導入では実装より設定・移行・教育の割合が増え、スクラッチ開発では設計・実装・テストの割合が増えます。割合は固定価格の根拠ではなく、見積書の偏りを確認するための補助線として扱います。

全社・複数子会社では1,500万〜4,000万円程度以上を見込みます

複数会社、多通貨、共通費配賦、連結、ERP・DWH連携、複雑な権限、グループ共通のレポートまで対象にする場合、初期費用は1,500万〜4,000万円程度、期間は6〜12か月以上が推定されます。独自の計画ロジックや複数システムとの大規模連携をスクラッチで実現する場合は、3,000万円〜1億円超、期間9〜18か月以上となる可能性もあります。これらは対象範囲から組み立てた目安であり、企業規模だけで決まる金額ではありません。

保守運用費は、リサーチノートでは初期費用の年5〜15%程度が一般的な目安とされていますが、SaaSの利用料、個別保守、連携監視、ユーザーサポート、追加開発を含むかで変わります。エンジニア単価を月80万〜120万円程度と置く見積もりもありますが、必要人数、期間、役割、専門性による差が大きいため、単価だけでなく作業量と成果物を確認します。

補助金は対象ツールと申請条件を確認してから織り込みます

中小企業・小規模事業者がITツールを導入する場合、デジタル化・AI導入補助金2026の通常枠では、補助率が1/2以内または条件により2/3以内、補助額は1プロセス以上で5万円以上150万円未満、4プロセス以上で150万円以上450万円以下と案内されています(出典: 独立行政法人中小企業基盤整備機構「デジタル化・AI導入補助金2026 通常枠」、2026年確認)。対象経費にはソフトウェア購入費、クラウド利用費最大2年分、導入関連費が含まれます。

ただし、補助金は自由なスクラッチ開発費が自動的に対象になる制度ではありません。登録ITツール、対象事業者、申請時期、導入後の報告などの条件があります。採択を前提に発注するとスケジュールを失うため、補助金を使わない場合の資金計画と、採択されなかった場合の契約解除・延期条件を社内で決めておきます。

委託先選定と見積比較で確認するポイント

事業計画管理システムの委託先と見積を比較する場面

委託先は、知名度や提示金額だけでなく、経営管理業務の理解、データ連携力、導入体制、定着支援、価格の透明性、契約終了時の移行性を確認して選びます。製品を提供するベンダーと、複数製品を組み合わせるSI会社、個別開発を得意とする会社では、得意な課題が違います。自社の課題に合わない会社を選ぶと、過剰な機能や追加開発を抱えることになります。

経営管理の業務知識と類似実績を確認します

実績確認では、単に「経営管理の導入経験がある」と書かれているかを見るのではなく、予算、見込、実績、KPI、配賦、連結、承認、会議レポートのどこまで担当したかを聞きます。自社に近い会社数、部門数、連携先、Excelの複雑さの案件があるか、担当予定のプロジェクトマネージャーや業務コンサルタントが過去案件で何を担ったかも確認します。営業担当が説明した実績と、契約後の実行チームが一致するかも重要です。

2026年に公開されたユアサ商事の事例では、予算策定と実績管理を異なるシステムで行っていたため、二重入力やシステム間連携の負担が生じていました。Loglass導入では、予算策定から予実管理、経営分析までの一元化と、新基幹システムとの連携実績が選定理由として示されています(出典: Loglass「株式会社YUASA 導入事例」、2026年4月公開)。この事例からも、機能数より既存システムとの接続と業務プロセスの一貫性を比較する必要があります。

見積書は初期費用・運用費・追加費用を分けて比較します

見積比較では、初期費用、初年度の利用料、2年目以降の利用料、保守費、追加変更費、データ移行費、教育費を別々に並べます。さらに、ユーザー数、会社数、連携本数、データ量、環境数、サポート時間、アップデート対応の前提をそろえます。3年間の総保有コストを作ると、初期費用が安くても利用料や追加開発が高い提案、初期費用が高くても標準機能で運用できる提案の違いが見えます。

比較表には価格だけでなく、要件対応、導入期間、連携方式、セキュリティ、運用支援、データ返却、契約柔軟性を記録します。例えば「会計連携あり」という記載だけでは、リアルタイムAPIなのか定時バッチなのか、エラーを誰が直すのかが分かりません。「標準機能」と「個別開発」の違いを明記し、個別開発部分の保守費と将来のアップデート影響まで確認します。

導入後の定着支援と責任分界を確認します

事業計画管理システムは、稼働しただけでは効果が出ません。入力ルール、マスタ変更、締め日、差異コメント、権限申請、問い合わせ対応を現場へ定着させる必要があります。委託先が操作研修だけを提供するのか、業務設計、管理者育成、初回予算編成の伴走、月次レビューまで支援するのかを確認します。自社側にも業務責任者、データ責任者、システム責任者を置き、委託先へ丸投げしない体制にします。

障害時には、データ連携の失敗が製品の問題なのか、送信元データの問題なのか、変換処理の問題なのかを切り分ける必要があります。RFPと契約書に、監視範囲、一次受付、復旧目標、再処理、報告、再委託先との連絡方法を記載します。発注時に責任分界を決めておけば、稼働後の障害対応や追加費用をめぐるトラブルを減らせます。

発注・外注で起きやすい失敗と対策

事業計画管理システムの導入リスクを確認する会議

失敗の多くは、機能不足よりも、対象範囲と責任の曖昧さから起こります。経営者は全社統合を求め、事業部は現場の柔軟性を求め、情シスは安全な連携を求めるため、関係者の期待を要件と優先順位へ落とし込む必要があります。発注前に「誰のどの判断を早くするシステムか」を共有すると、機能の追加競争を抑えられます。

機能を先に決めて業務設計が後回しになる失敗

製品デモで見たダッシュボードやシミュレーション機能を先に採用し、実際の計画・予実業務と合わなくなるケースがあります。対策として、候補先へ同じ業務シナリオを提示し、予算入力から承認、実績連携、差異説明までを実演してもらいます。華やかな画面ではなく、締め日に遅延なくデータがそろい、根拠を追跡できるかを評価します。

全社一括・低価格だけを条件にする失敗

全社・全機能・過去データ全件を初回リリースに含めると、要件変更、移行、教育、テストが同時に膨らみます。反対に、初期費用が最も安い提案だけを選ぶと、必要な連携や保守が別料金になり、結果的に高くなる可能性があります。初回は対象会社や業務を絞り、効果指標を確認してから拡張するロードマップを、初期費用と将来費用の両方で比較します。

委託先へ丸投げして自社に知識が残らない失敗

業務定義、マスタ、権限、受入テストをすべて委託先に任せると、担当者が変わったときに運用できません。自社側の業務責任者を早期に決め、要件の承認、データ定義、テスト判定、教育計画を自社の意思決定として行います。納品物として仕様書、設定一覧、データ項目表、テスト結果、操作手順を受け取り、将来の改修を別会社へ相談できる状態を作ります。

よくある質問

事業計画管理システムの発注に関する質問を確認する場面

事業計画管理システムの発注では、費用だけでなく、導入範囲、契約、データ連携、運用体制について疑問が生じます。ここでは、発注前に多く寄せられる質問へ、判断の基準を先に回答します。

事業計画管理システムはSaaSとスクラッチ開発のどちらがよいですか?

標準的な予算・予実管理を早く始めたい場合はSaaSやパッケージ、独自の計画ロジックや複雑な連携が重要な場合はスクラッチや既存基盤の拡張が候補です。会社数、利用者、Excelの複雑さ、連携先、将来の変更頻度を比較し、初回は標準機能で小さく始めて不足部分を追加する方法も検討します。

RFPを作れない場合は開発会社へ相談してもよいですか?

相談しても問題ありませんが、最初から1社の提案だけで要件と価格を決めないことが大切です。現状のExcel、業務フロー、対象会社、困っている作業、稼働希望時期を準備し、まず現状分析や構想策定を別工程として依頼すると、RFPの前提を整理できます。複数社へ同じ資料を渡し、提案の前提と見積範囲をそろえると比較しやすくなります。

事業計画管理システムの発注費用を抑えるにはどうすればよいですか?

初回リリースのMUSTを絞り、既存の会計・ERPや標準機能を活用し、Excelの全帳票を移行しないことが基本です。対象部門を限定したPoCで入力負荷とデータ品質を確認し、効果のある機能から拡張します。ただし、セキュリティ、権限、バックアップ、データ返却、障害対応を削ると将来のリスクが増えるため、削減対象は機能の優先順位と個別開発に限定します。

発注前にデータ連携とセキュリティをどこまで決めますか?

少なくとも連携先、データ項目、更新頻度、エラー時の責任者、権限、ログ、バックアップ、障害時の復旧、データ返却は発注前に決めます。細かなAPI仕様をすべて確定できなくても、方式、対象データ、責任分界、調査と設計を行う工程をRFPと契約へ記載します。後から決める項目は、追加費用とスケジュール変更の扱いも合わせて明示します。

まとめ|要件と責任範囲をそろえて発注を成功させます

事業計画管理システムの発注計画をまとめる場面

事業計画管理システムの発注・外注では、製品や開発会社を先に決めるのではなく、計画・予算・見込・実績・KPIの対象範囲と、解決したい経営課題を明確にします。そのうえで、現行Excelとデータ連携を棚卸しし、MUSTとWANTを分け、RFPで同じ条件を候補先へ提示します。

発注前に確認する五つのポイント

確認するポイントは、(1)SaaS・パッケージ・個別開発の選択が課題に合っているか、(2)RFPに業務・データ・セキュリティ・受入条件があるか、(3)請負・準委任・SaaS契約の責任範囲が明確か、(4)初期費用と3年間の運用費を比較できるか、(5)導入後の定着支援とデータ返却を確認したか、の五つです。価格の大小だけでなく、標準機能と追加開発、移行と教育、障害対応と保守を含めた総額で判断します。

最初の一歩は現行業務の棚卸しです

まずは、直近の予算編成や月次予実で使ったExcel、会計・ERP・SFAの連携資料、会議用レポートを集め、入力から意思決定までの流れを一枚にします。対象会社・利用者・連携先・稼働希望時期・予算の考え方を整理してから、複数の委託先へ相談してください。小さく検証して効果を測り、共通のデータモデルと承認フローを整えながら拡張することが、事業計画管理システムを定着させる近道です。

▼全体ガイドの記事
・事業計画管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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