工事原価管理システム開発の完全ガイド

工事原価管理システムは、工事番号ごとに費目と入力・承認の流れをそろえ、工事中の利益と赤字の兆候を把握するための仕組みです。見積や実行予算、発注、日報、出来高を工事ごとにつなぐため、完成までの利益の変化を追えます。

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

工事原価管理システムの全体像

工事番号を中心に実行予算、発生原価、発注残、見込原価、出来高が結び付く図。
工事番号に情報を集めると、工事途中の利益変化を追えます。

工事原価管理システムは、工事中の原価と利益の変化を工事単位で追い、経営判断につなげる仕組みです。

見積時の実行予算、工事中の発生原価、現時点の出来高、完成までの見込原価を工事ごとに比べます。そのため、会計の仕訳集計とは役割が異なります。

工事番号による売上と原価の接続

工事台帳には、工事番号、契約金額、工期を登録します。

住所、元請・下請区分、担当者も工事ごとに登録し、拠点とJV情報も同じ台帳で扱います。

  • 工事データ:見積、実行予算、発注を工事番号でひも付けます。納品、請求、支払、日報、出来高も、同じ番号で扱います。
  • 費目:材料費、労務費、外注費、現場経費、共通経費などを、コードで統一した区分。

費目のコードがそろえば、予算と実績を同じルールで比べられます。

工事中の利益と赤字兆候の早期把握

工事の途中で判断するには、まず発生原価と発注残を見ます。そのうえで、見込原価と出来高を並べ、完成時の利益を読みます。

  • 追加発注:完成時利益を見ながら、発注内容を検討します。
  • 工程変更:赤字兆候を踏まえた、工事責任者による変更の検討。

モデルケースでは、実行予算1,000万円に対して発注済みが700万円、労務費が180万円、出来高は60%です。ここに未発注材料や追加工事の見込原価が加わると、完成時利益が下がる可能性があります。

導入の価値は、締め処理後の確定利益を見るだけでなく、工事の途中で判断材料を早く得られる点にあります。

現場・工事部・経理・経営層の情報の集約

部門ごとに必要な画面は違いますが、データは工事番号と費目コードでそろえておきます。

  • 現場・工事部:日報と出来高を入力し、予算差異と発注残を確認します。
  • 経理・経営層:請求、支払、仕訳の処理と、案件別粗利・赤字工事の確認。

データを一つにまとめると、会議のたびにExcelへ転記する手間を減らせます。

閲覧・登録・承認の権限を分け、変更履歴を残す設計にすると、原価管理の正確さを支えます。

ポイント

工事番号と費目のコードを見積から入金まで同じルールで持てるか、工事の途中で利益を読めるかが判断の目安です。ここが曖昧だと、数字の信頼性は上がりません。

工事原価管理システムの定義と役割

工事ごとに予算と発注を登録し、実績と出来高、売上を集めて、実際原価と完成時利益を更新する仕組みです。

会計ソフトが会社全体の財務結果を確定するのに対し、こちらは現場の業務から工事別の利益変化を把握します。

基本機能の内容:工事台帳・予算・発注・日報・予実管理

必要な機能は、工事台帳と見積・実行予算です。発注・仕入・支払、日報・労務費も含みます。さらに、出来高、予実損益、売上・請求・入金を、工事単位でそろえて扱います。また、会計連携、帳票、権限・監査ログも備えます。

  • 日報:作業員、作業時間、工種、現場、作業内容をスマートフォンから入力します。
  • 発注・仕入:注文書、納品、請求、支払査定を工事単位で処理する機能。

スマートフォンで日報を入力すれば、紙から転記する手間を減らせます。

発注・仕入の情報を使えば、未計上の原価も確認できます。

建築・土木・設備・専門工事で変わる必要な粒度

管理に必要な細かさは、工事の種類によって変わります。そのため、機能の数よりも、自社の工事番号、費目、単位、出来高を登録できるかを選定時に確かめます。

  • 建築:工種別予算と、追加変更・下請発注の差異の管理。
  • 土木:歩掛、出来高、工程と資材搬入との連動の確認。
  • 設備・内装:材料・仕入・在庫・施工の管理。

特に内装やリフォームでは、小口の材料と外注も案件ごとに細かく管理します。

経営KPIによる導入効果の測定

紙をなくしたことだけで評価すると、現場の負担に見合う成果かどうかが分かりません。

導入前に指標を測り、導入後も同じ条件で比べることが欠かせません。

  • 決算・日報:月次決算日数と日報提出率を確認します。
  • 原価・損益:原価計上の遅延日数、予算差異、赤字工事の早期検知率。
  • 請求・支払:手戻り件数の追跡。

たとえば、日報提出率が低い現場では、入力項目を減らす、オフライン入力を用意する、承認者を見直すといった改善を行います。

工事原価管理システムの種類と選び方

クラウド・SaaS型、建設業向けパッケージ、個別開発型、ハイブリッド型の特徴を4枚のパネルで示す図。
標準業務から独自要件まで、方式ごとに得意な範囲が分かれます。

方式は、クラウド、建設業向けパッケージ、原価管理の個別開発、工程・日報・会計のフルスクラッチに分かれます。規模や工種に合わない大きな仕組みは避けます。

今すぐ解決する業務と将来連携する業務は、分けて考えます。

短期間で標準業務を整えたい場合のクラウド・SaaS型

クラウド型は、サーバーの購入やバックアップ運用を抑えられ、現場や出先からも使いやすい方式です。

  • 小さく試行:日報、工事台帳、写真、発注、請求から範囲を絞れます。
  • 費用と運用:ユーザー課金、ストレージ、API利用料、通信障害時の入力。
  • データ・業務:エクスポートと、標準機能に合わせる業務変更を確かめます。

範囲を絞れば、即日から数週間で試行できる場合もあります。ただし、月額が安く見えても、全ユーザー課金と長期利用を含めたTCOで比べる必要があります。

建設業の標準フローを早く使いたい場合のパッケージ型

建設業向けパッケージには、見積や実行予算、発注、仕入の流れと、原価、支払、会計連携が、頻出業務としてあらかじめ整理されています。

  • 導入:標準フローを使い、導入期間を短くしやすい方式です。
  • 追加機能:独自の費目体系や承認経路を、追加する範囲の絞り込み。

過剰な追加は、アドオン費用とアップデート対応を増やします。そのため、Fit & Gapで、標準機能に合わせる業務と追加機能で対応する業務を決めておきます。

独自の原価計算や連携を重視する場合の個別開発型

工種固有の歩掛や特殊なJV管理、複雑な既存連携、独自帳票が、競争力に直結する場合があります。そのときは、個別開発が候補になります。

  • 独自要件:会計・勤怠・受発注・販売管理との連携を、自社の業務に合わせて組めます。
  • 長期運用:要件定義、移行、教育、保守を自社と開発パートナーで分担。

初期の自由度に加えて、法改正、脆弱性対応、担当者交代、データ返却まで含めた運用を設計します。

既存基幹と現場サービスをつなぐハイブリッド型

原価・会計は既存パッケージ、日報・写真・承認はクラウドで扱い、APIやCSVで連携します。この構成なら、全面的な置き換えを避けつつ、現場の入力と経営側のデータ統合を両立できます。

  • 連携設計:連携頻度と、マスタの正とするシステムを決めます。
  • 障害時対応:再送、重複防止、連携停止時の責任範囲。

これらを決めておかないと、システム間の不整合が新たな課題になります。

ポイント

どの方式が合うかは、標準業務で足りるか、独自の原価計算や既存基幹との連携が要るかで分かれます。機能の数より、この2点で候補を絞るのが判断の目安です。

工事原価管理システム開発・導入の進め方

現状業務の棚卸しから要件定義、データ移行、1〜2拠点のPoCを経て全社展開へ進む流れ図。
小規模な試行を通じて課題を絞り、全社へ広げます。

導入は、現状調査、コードと範囲・要件の整理、設計開発の順に進みます。そのあと、データ移行、連携・受入テスト、教育、試行を経て、全社展開に至ります。一括で導入すると、入力負担とデータ品質の課題が重なります。そこで、優先順位を付けて段階的に進めます。

▶ 詳細はこちら:工事原価管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

現状業務の整理と導入範囲の決定

最初に、見積、実行予算、発注の流れを部門横断で描きます。納品、請求、支払、日報、出来高、会計仕訳も、その流れに並べます。そのうえで、入力者、コード、承認者、出力帳票も整理します。

  • 対象を洗い出す:Excel、紙、メール、共有フォルダ、販売管理、勤怠を確認します。
  • 課題を洗い出す:重複、欠損、表記揺れ、担当者だけが知る例外。

第一段階は、工事台帳、日報、実行予算、予実確認に絞るか、発注や会計まで含めるかを決めます。ただし、範囲を広げるほど、整理すべき課題も増えます。

業務シナリオに基づく要件定義とRFP

要件は、日報登録から労務費への反映までといった業務シナリオの形で書きます。抽象的な言葉のままだと、開発会社との認識がずれやすくなります。例として、発注残と仕入計上済み金額を予算費目別に比較する流れを記します。

  • 利用条件:利用者数、拠点数、工事数、工種、費目、権限、承認経路の記載。
  • 機能・連携:帳票、会計・勤怠・受発注連携、移行件数、スマートフォン、オフライン対応を記載します。
  • 運用条件:監査ログ、バックアップ、教育、保守、SLAを含めます。

コード統一・データ移行・連携の事前検証

移行の前に、工事番号、取引先、材料、工種のマスタを整理します。さらに、費目、作業員、単位、税区分、勘定科目のマスタも整えます。

略称と正式名の表記、袋・本・平方メートルといった単位の違い、過去工事の終了日を確認すると、集計の誤りを防げます。

  • 移行手順:対象期間の決定、クレンジング、テスト移行、本番移行、差分確認。
  • 連携試験:重複、欠損、タイムアウト、金額不一致が起きたときの再処理も試します。

1〜2拠点のPoCによる試行と全社展開

工種や規模が異なる1〜2拠点を選び、実際の工事で見積、実行予算、日報、発注、請求、予実確認の一連の流れを確かめます。

  • 試行評価:現場入力、経理の再入力、赤字兆候の確認。
  • 全社展開:小さな試行を本稼働につなげ、未解決の差異を整理して、マスタと運用ルールをそろえます。

国土交通省の2026年度の建設分野では、AI活用、企業・工事規模を問わない普及、試行から本格運用への移行が重点です(出典: 国土交通省「i-Construction 2.0の2年目の取組成果」、2026年)。

確認する指標は、週次で日報提出率と未承認件数、月次で予算差異と計上遅延日数、四半期で赤字検知率と手戻り件数です。

指標が悪化したときは、会議で入力画面、承認経路、マスタ、教育、権限を見直します。

ポイント

試行で何を確かめるかを事前に決めておくと、全社展開へ進むか見直すかを数字で判断できます。提出率や予算差異など、合否の基準を先に合意しておくのが目安です。

工事原価管理システムの費用相場と内訳

費用を左右するのは、方式、利用者・拠点数、機能範囲です。さらに、既存連携や移行、現場アプリも金額に響きます。帳票、カスタマイズ、教育、保守も、費用に響く要因です。

2026年時点の公開情報では、原価管理単体が400万〜1,000万円、工程・原価・日報を統合した場合が800万〜2,000万円です。品質・安全・原価・法対応書類まで含む標準的な工事管理は、500万〜2,000万円程度です(出典: 建設業向けシステム開発費用の2026年版公開情報、2026年)。公開相場は個別の見積を保証しないため、予算取りの起点として使うのが適切です。

▶ 詳細はこちら:工事原価管理システム開発の見積相場や費用/コスト/値段について

▶ 詳細はこちら:工事原価管理システム開発の発注/外注/依頼/委託方法について

方式別の初期費用と導入期間の比較

方式ごとの導入負担を比べるには、初期費用と利用開始までの期間を見ます。

  • クラウド・SaaS:初期設定支援は無料〜60万円程度、または数十万円規模で、月額が別途かかる場合があります。
  • 建設業向けパッケージ:ライセンス・設定・連携・教育で数十万〜数百万円が目安です。
  • 個別開発:原価管理単体は400万〜1,000万円、4〜8か月程度です。
  • 統合開発:工程・原価・日報統合は800万〜2,000万円、6〜12か月程度です。
  • フルスクラッチ:1,000万〜5,000万円以上、大規模案件は5,000万円〜1億円以上の可能性があります。

一般的な業務SaaSの月額は、1ユーザーあたり数百円から数千円程度です。ただし、機能が一体化した製品では料金体系が変わります。導入期間は、クラウドで即日から数週間、パッケージで数週間から数か月が目安です。

フルスクラッチの金額は、特殊な原価計算、全国拠点、複数の基幹連携、複雑なJV管理を含む場合の目安です。そのため、公開相場と一般的な人月計算による推定を踏まえ、範囲を分けて見積もります。

初期費用と月額以外を含むTCO

TCOには、初期費用と月額以外の費用も含めて見ます。見積の段階で、次の内訳を分けて確かめます。

  • 開発作業:要件定義、ヒアリング、UI設計、実装、連携、帳票の費用。
  • 開発の周辺作業:テスト、データ整備・移行、マニュアル、教育、管理費。
  • 運用費:クラウド利用、ユーザー追加、ストレージ、バックアップにかかる費用。
  • 稼働後の対応:脆弱性・法改正対応、連携監視、問い合わせ、帳票変更、マスタ更新。

保守費を初期開発費の年15〜25%程度と置いて試算する方法もあります。ただし、契約範囲によって変わるため、5年間のTCOで比べます。

同じ業務シナリオによる見積の比較

同じモデル工事について、見積、予算、日報、追加発注、出来高、請求を示してもらい、標準機能で処理できる範囲を比べます。

  • 見積の不足:要件定義費が極端に少ない、テストや移行作業がない場合は注意します。
  • 運用条件:法改正・障害対応の別料金、連携エラーの責任範囲の確認。

安い総額だけで決めず、作業の含有・非含有を同じ粒度で比べます。

300万〜800万円程度の小規模PoCで、1〜2拠点の日報・予算・予実確認を試す方法もあります。この金額は個別要件からの推定で、製品の定価ではありません。

PoCの終了条件は、提出率、原価計上の遅延、予算差異を把握できるか、会計連携の一致率とします。事前に合意しておけば、本開発へ進むかどうかを判断しやすくなります。

ポイント

金額を比べる前に、同じ業務範囲で見積もられているかを確かめるのが判断の目安です。範囲が違う総額は、そのまま比べられません。

工事原価管理システムの開発会社/ベンダー・サービスの選び方

開発会社は、知名度や機能数よりも、現場業務と原価発生時点の設計力で見ます。そのうえで、工種・規模・利用形態を、同じ質問票で比べます。会計・勤怠・受発注との連携やデータ移行も、質問項目に入れます。追加開発・サポート・法改正対応も、比べる項目です。

自社の工種と原価計算への適合性

建築、土木、設備、専門工事では、費目や出来高、歩掛が異なります。さらに、発注単位や工事間接費の配賦も違います。

  • 実工事で確認:見積から予算を作り、材料・労務・外注・経費を登録します。
  • 原価の更新:日報と発注を原価に反映し、完成時利益の再計算。

設定で対応できるか、追加開発が必要かを確かめます。

追加開発が製品の更新に与える影響も質問します。

連携・データ移行・データ返却の条件

会計、勤怠、給与との連携対象を整理します。販売管理、受発注、在庫、電子請求との連携対象も整理します。

  • 連携仕様:API・CSV、頻度、マスタの正、エラー検知と再送担当を決めます。
  • 契約終了:データ形式、全履歴の返却、バックアップの取得、移行支援費の確認。

将来の乗り換えや事業再編に備えて、データを取り出せる条件を確かめておきます。

権限・監査・障害対応・サポート体制の評価

現場、工事部、購買、経理、管理職、経営層それぞれについて、閲覧、登録、承認、取消の権限を確認します。

  • 監査と安全:変更前後、変更者、日時、理由、多要素認証、暗号化、脆弱性対応の確認。
  • 障害対応:バックアップ、復旧目標、障害連絡の確認。
  • サポート:窓口、対応時間、法改正更新、教育資料、担当交代時の引き継ぎを質問します。

現場の通信が不安定な場合は、オフライン入力に加え、端末紛失時のデータ削除、再送時の重複防止も必要になります。

変更履歴を監査ログに残せるかも確かめます。

同じシナリオのデモと契約条件による比較

候補を3社以上に絞り、同じモデル工事で見積、予算、発注、日報、請求、赤字アラートを操作してもらいます。

  • 操作性:入力時間、未入力の検知、予算差異の理由の記録方法を見ます。
  • 契約内容:各作業の範囲の照合。

画面の印象だけでなく、作業の流れと契約範囲を評価します。契約前には、見積書と契約書の内容を一致させておきます。

対象は、標準機能、設定、追加開発、データ移行、教育、保守です。さらに、バージョンアップ、法改正対応、解約時のデータ返却も含めます。

▶ 詳細はこちら:工事原価管理システム開発でおすすめの開発会社/ベンダー6選と選び方

ポイント

候補を比べるときは、現場業務と原価発生時点の設計力を先に見るのが判断の目安です。知名度や機能数は、その次の段階で比べれば足ります。

導入で起こりやすい失敗と定着させる方法

導入後に入力が進まない、数字が合わない、利用者が限られるといった問題は、機能不足だけが原因とは限りません。原価の定義やマスタ、入力時期、承認者、現場への説明が曖昧だと、同じ問題が起きやすくなります。そのため、運用ルールを整えておきます。

Excel帳票の再現範囲の絞り込み

現行Excelには、不要項目や重複列、担当者ごとの例外、手作業で補正する数字が混在することがあります。

  • 共通化:経営判断に必要な原価項目と、法令・契約上の記録を分けます。
  • 独自性:利益や業務品質に影響する項目に絞って残します。

帳票をそのまま画面化すると、入力項目とマスタが増え、開発費や教育負担が膨らみます。

現場の入力負担の軽減と管理者の先行利用

入力項目を絞り、スマートフォンで片手でも操作できる画面にします。

  • 入力の工夫:工事番号や工種を候補から選ばせ、同じ内容を複数の画面に入力させません。
  • 管理者の利用:予実画面を先に使い、日報を提出した現場へ具体的に返します。
  • 現場支援:推進担当を置き、問い合わせを一か所にまとめます。

現場が、入力したデータを経営判断に使っていると実感できるようにします。

建設業法では営業所ごとの帳簿や請負契約記録が求められ、帳簿・関連図書により保存期間と対象が異なります。

請求書や注文書を電子で受け取る場合は、電子取引データの保存要件も確認します。

「法対応済み」という説明を、そのまま判断の根拠にしないようにします。

  • 建設業法:帳票、保存期間、検索、出力、変更履歴、削除権限を、法務・税務担当と確認します。
  • 電子取引:訂正・削除履歴、タイムスタンプ、規程、出力可否の設計。

2026年3月改訂の資料には、工事名・所在地、契約日、注文者、完成確認、引渡しなどの記載事項と下請記録があります(出典: 国土交通省中国地方整備局「建設業法における帳簿の記載事項と保存期間」、2026年)。

国税庁は、取引年月日・金額・取引先での検索や改ざん防止措置を案内しています(出典: 国税庁「電子取引関係」「電子帳簿保存法の一問一答」、2026年確認)。

実際の要件は、取引の形態と保存の方法で変わります。

稼働後のKPI管理と改善会議

現場・工事部・経理・経営の代表者で、月次の改善会議を行います。

  • 日報提出率:低い場合に、画面や締め時間を見直します。
  • 原価差異:大きい場合の、費目コードや予算登録の見直し。
  • 会計不一致:連携マッピングを見直します。

業務を変えるときは、マスタ、権限、帳票、マニュアルを同時に更新し、変更の理由を残します。

よくある質問(FAQ)

導入の検討では、費用、Excel移行、現場入力、会計との違い、法令対応についての質問が多く寄せられます。判断しやすいよう、各質問への答えを先に示します。

Excelで工事原価を管理する方法から移行するべきですか?

工事数や入力者が少なく、締め処理と予実確認に問題がなければ、すぐ全面移行する必要はありません。

  • 段階移行の目安:複数台帳、日報の再入力、月次決算まで利益が不明な場合は、段階移行の効果が出やすいです。
  • 移行範囲:日報、工事台帳、実行予算から始める方法。

移行前には現行Excelを整理しておき、過去データを完璧に移すことにはこだわらないようにします。

会計システムがあれば工事原価管理システムは不要ですか?

会計システムは仕訳と決算を、工事原価管理は現場の利益変化を工事別に管理します。役割が異なるため、会計システムがあっても足りるかは別に確かめる必要があります。さらに、承認済みの金額や仕訳を会計へ渡せば、再入力と部門間の不一致を減らせます。

工事原価管理で扱う対象情報には、見積、実行予算、発注があります。日報、出来高、発注残、見込原価も含まれます。

小規模な建設会社でも導入できますか?

導入できます。工事台帳、日報、実行予算、予実確認に絞り、クラウド型やパッケージ型から始められます。

利用者・工事・拠点の数と連携の有無で、費用は変わります。そこで、1〜2拠点のPoCで入力の定着と効果を確かめ、業務に合わない機能への投資を抑えます。

法令対応や電子帳簿保存法に対応できますか?

対応できる構成はあります。ただし、製品や開発会社の「対応済み」という説明だけでは判断できません。

建設業法上の帳簿・関連図書、電子取引データを、業務と照合します。検索項目、保存期間、訂正・削除履歴、出力方法も、照合の対象です。

法改正に備え、更新の責任範囲、法務・税務担当が確認できる証跡、長期保存の仕組みを契約前に確かめます。

まとめ

工事原価管理システムは、工事番号を使って予算、発注、仕入、労務費をつなぎます。外注費、材料費、経費、出来高、売上も同じ番号でひも付け、工事中の利益と赤字兆候を把握する仕組みです。

選定では、工種、現場入力、連携を、業務の流れに沿って確かめます。移行、監査ログ、法令・電子保存、保守も、同じ流れで確かめます。

工事番号・費目・入力タイミングの先行統一

見積から完成・入金までの流れを洗い出し、工事番号、費目、取引先、工種、単位、出来高の定義をそろえます。

そのうえで、現場日報、予算差異、発注残のうち、どれを先に扱うかを決めます。完成利益、請求・支払、会計連携も候補になります。定義が曖昧なままでは、製品を選んでも数字の信頼性は高まりません。

小規模な検証から全社展開までの段階

導入方式と総保有コストを比べ、拠点で効果を確かめてから全社へ広げます。

  • 方式と費用:SaaS、パッケージ、個別開発、工程・日報統合、フルスクラッチの比較。
  • 小規模検証:移行・教育・連携・保守を含むTCOで比べ、1〜2拠点でPoCを行います。
  • 全社展開:提出率、計上遅延、予算差異、赤字検知率の測定と、効果を確認した範囲からの拡大。
  • 共通の判断:現場と経営が同じ数字で判断できる状態を、段階的につくります。

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

 

会社紹介

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

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

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

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

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

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