従業員管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

従業員管理システム開発は、業務の整理、製品の選定、段階的な導入の順に進めると、正確な人事・労務処理と社内への定着につながります。

開発の進め方に加えて、データと権限の設計、費用相場と見積もりの要点も取り上げます。全体像は、従業員管理システム開発の完全ガイドもご覧ください。

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

従業員管理システム開発の全体像

従業員マスタを中央に置き、人事、労務、給与、会計、現場を結んだ図。
情報の起点を一つにすると、複数の業務領域で共有できます。

従業員管理システムは、基本情報や雇用契約、所属を管理するシステムです。異動や勤怠、給与も扱います。申請や退職なども、管理の対象です。

中心に置くのは従業員マスタで、人事・労務・給与・会計・現場が共通のデータとして扱い、変更履歴も追跡できる仕組みです。

まず対象範囲を決め、その範囲に合わせて製品導入と個別開発のどちらが合うかを比べます。社員名簿を作るだけでなく、業務で使える形にデータを整えることが大切です。

「従業員管理」の範囲の定義

対象業務は幅があり、入退社や勤怠、給与の処理を含みます。評価やスキル、配置分析まで含めることもあります。対象が広いため、次の区分ごとに段階に分けて検討します。

  • 基本情報:従業員に関する情報の管理
  • 人事・労務:入社、異動、退職の手続きまで
  • 勤怠・給与:年末調整までを含む処理
  • 人材分析:評価、スキル、配置分析を将来扱う場合

人事管理クラウドでは、情報収集フォームや承認経路などを標準機能で使える場合があります。組織情報や適用開始日付きの履歴も、標準機能の範囲に入るかを製品ごとに確かめておきます。

給与計算そのものや複雑なシフトには、導入支援や追加開発が必要なことがあります。派遣先別請求や独自手当、基幹連携でも、導入支援や追加開発が要る場合があります。

部門ごとに、入力者と承認者、締め日の扱いを確かめておきます。利用する帳票や例外処理も、部門の実態に合わせて整理する必要があります。

正社員以外の働き方も、同じ従業員番号の体系で扱えるかが問われます。アルバイトや派遣、出向も対象で、兼務者や休職者、入社予定者、退職予定者についても同じように確かめます。

人材分析を将来行う場合も、初回稼働で必要な項目と、第2段階で追加する項目を分けておきます。初回の範囲を絞ると、開発規模の膨張を抑えられます。

クラウド、パッケージ、個別開発の使い分け

開発方式は、必要な業務と運用体制に合わせて選びます。

  • クラウド:標準的な入社手続きや身上変更を早く始めたい企業向け
  • パッケージ・ERP:複雑な給与制度やグループ会社の統合に向く場合
  • 個別・スクラッチ開発:独自制度や深い社内連携が中核となる場合

クラウドは、法改正や税率変更への追随を任せやすく、初期投資も抑えやすいという利点があります。一方で、契約前には月額料金以外の条件も確かめる必要があります。確認すべき項目は、オプション料金や導入支援、従業員数課金です。APIや、解約時のデータ返却条件も含まれます。

個別開発を選ぶ場合は、独自の就業規則や特殊な手当、業界固有の勤務形態といった要件を、先に確認しておきます。

方式を比べるときは、独自画面が作れるかに加えて、5年後も法改正や脆弱性対応、担当者交代に対応できる運用体制を保てるかを見ます。

ポイント

全体像は、従業員マスタを中心に人事から現場までの情報をどう結ぶかで決まります。製品導入か個別開発かは、対象範囲を先に決めてから比べてください。

従業員管理システム開発の進め方

データモデル、マスタと連携、権限、機微情報の4項目を並べた図。
データの定義とアクセス範囲を、設計時にまとめて整理します。

開発は、画面や機能を作る前に、業務の実態を集めて優先順位を決める順で進みます。6段階のそれぞれで、成果物と次の段階へ進む判定基準を決めておきます。

開発規模の膨張を抑えるため、入社、身上変更、異動など、効果の見えやすい業務から始めます。一方で、給与や複雑な連携は、段階的に広げる方法も有効です。

フェーズ1:要件整理での現行業務と優先順位の確定

要件整理では、入社から退職までの業務を、担当者と承認者、入力項目とともに書き出します。期限や出力先も一緒に整理します。勤怠締めや給与確定、年末調整も対象に含めます。

Excelや紙、メールなど、情報を置いている場所を挙げます。勤怠端末や給与ソフト、会計ソフトといった既存システムも挙げ、同じ情報がどこへ複製されているかを確認します。申請書やCSVを含む帳票、計算式、エラー時の手順も集めます。

要求は、初回稼働に必須のMUST、できれば実現したいSHOULD、将来検討するWANTに分けておきます。

  • 法定期限:法律上の期日に関わる業務か
  • 業務停止:給与や人員配置を止めてしまう要件か
  • 代替手段:手作業が残っても、代わりの方法を用意できるか

成果物には、業務一覧やデータ項目一覧、権限案を残します。さらに、連携の一覧や非機能要件を残し、移行対象と成功指標も決めておきます。経営、人事、現場が同じ範囲に合意したら、次へ進みます。

フェーズ2:選定での適合度と総保有コストの比較

選定では、機能の数や知名度よりも、自社の要件にどれだけ合うかを比べます。

  • 要件適合:RFPと共通の業務シナリオで候補製品を比較
  • 対応範囲:標準で対応できる部分と、追加開発が要る部分の区別
  • 総保有コスト:3年総額で比べ、候補を2〜3社に絞る

RFPには、従業員数や拠点数、雇用形態といった基本の条件を書きます。兼務や出向の扱い、既存システム、必須連携も記載します。給与締め日や希望稼働日、運用担当者は、発注側の情報として示します。

候補各社には、デモで業務の流れを実際に見せてもらいます。見てほしいのは、入社予定者の登録や未来日の異動、退職の処理です。加えて、権限変更、CSV出力、エラー訂正も確かめます。

ベンダー、導入支援会社、連携開発会社が別々なら、障害の窓口と、どこまでを誰が受け持つかを明示します。3年総額には、初期設定、移行、教育を含めます。さらに、APIや保守の費用と、法改正対応、解約後のデータ取得も含めます。

フェーズ3:設計・開発でのデータと権限の境界の決定

設計では、データの構造を基点に、連携や権限、機微情報の扱いを決めます。

  • データモデル:従業員から変更履歴までの情報の定義
  • マスタと連携:どのシステムを正とするかと、受け渡しの方法
  • 権限:役割ごとの、項目・組織・操作の範囲
  • 機微情報:給与や健康情報、マイナンバーの区分

管理対象には、従業員番号や組織コード、給与コードなどがあります。データモデルは、従業員を中心に、勤怠や給与、申請など業務で扱う情報を結び付ける形で決めます。添付書類や変更履歴も、同じモデルに含めます。

異動を上書きしてしまうと、過去の所属や給与計算の根拠を後から確かめられなくなります。そのため、異動の履歴には、適用開始日と終了日、変更者、承認履歴を持たせます。

また、APIやCSVによる連携は、頻度や失敗時の再送方法、重複の検知まで仕様として決めます。権限は、人事管理者や労務担当、給与担当の役割ごとに設計します。部門長や本人、システム管理者についても、同じように決めます。

給与や健康情報、マイナンバーは、一般のプロフィール情報と同じ画面に置きません。そのうえで、最小限の人だけが見られるように管理します。そのために、MFAと暗号化を使い、アクセスログも取って、定期的に見直します。

個人番号を扱う場合は、委託先の監督と取扱区域を決めるほか、教育や漏えい時の報告手順も設計します。

また、「特定個人情報の適正な取扱いに関するガイドライン(事業者編)」は、令和7年6月に一部改正されています。

(出典:個人情報保護委員会、2025年)

フェーズ4:テストでの業務シナリオと給与結果の検証

テストでは、画面が正しく表示されるかだけでなく、業務シナリオ全体で動くかを確かめます。入社登録から承認、勤怠連携、給与計算を経て、明細配布や退職までの流れで見ます。

  • 機能と連携:単体テストと連携テスト
  • 安全性と性能:権限の設定、処理の速さ、障害からの復旧
  • 利用者確認:ユーザー受入テスト

テストデータには、実際に起きるケースを含めます。正社員や時給アルバイト、派遣、休職者の人も対象です。兼務者や途中入社、月途中退職も、テストの対象に加えます。

給与や勤怠を連携する場合は、旧システムとの並行計算を複数の締め期間で行います。支給額や控除額、勤務時間が一致するかを見ます。さらに、残業や休暇残数、振込データも照らし合わせます。

不一致が出たら、原因を、システムの不具合か、旧データの欠損か、制度解釈の差かに切り分けます。また、受入基準には、重大障害ゼロや未解決の高リスク課題ゼロなどを定めます。担当者による操作の合格や、バックアップからの復旧確認も含めます。

稼働日が迫っていても、基準に合格しないまま進めないことが大切です。

フェーズ5:稼働での移行リハーサルと問い合わせ体制の整備

稼働では、データ移行のリハーサルを行い、切替方式と問い合わせ体制を決めます。

  • データ整備:不要データの除外と、表記・重複・コードの統一
  • 移行対象:保存や業務に必要な情報の範囲
  • 切替と支援:段階導入と問い合わせ対応の準備

移行対象は、基本情報に加えて過去の所属や雇用契約を含みます。給与履歴や休暇残数、添付書類まで広げるかは、法定保存や業務で必要な範囲から決めます。退職者情報も、同じ考え方で扱います。

まず現行データを抽出し、不要データの除外や表記ゆれの統一を行います。続けて、重複の排除やコードの変換を行い、取り込みと件数照合で確かめます。

最低でも、本番を想定した移行リハーサルを行います。そのうえで、所要時間やエラー件数を確認し、修正担当と切り戻し方法も決めておきます。

稼働方式は、全社一斉切替か、部門ごと、対象業務ごとの段階導入から選びます。さらに、給与や法定手続きの締め日をまたぐ場合は、旧システムを参照用に残す期間と、二重入力を避ける運用を決めておきます。

問い合わせは、初日からすべてを一つの窓口に集めず、FAQや操作動画、管理者向け手順書を用意します。障害連絡先や緊急時の紙運用も、あらかじめ決めておきます。これらを前もって用意すると、現場の混乱を抑えられます。

フェーズ6:定着での利用率と業務効果の測定

説明会を開いたあとも、利用状況と業務効果を定期的に測り、運用を改善していくことが定着につながります。

  • 利用状況:情報更新率、差し戻し率、承認日数の月次の確認
  • 業務効果:二重入力、給与計算時間、問い合わせ件数の変化
  • 運用改善:法改正や連携、権限の状態の定期点検

freeeのテテマーチ事例では、約70名の企業で給与計算が平均6時間程度から1〜2時間になったと紹介されています。残業申請の漏れについては、月30件から2件に減ったと書かれています。

(出典:freee株式会社「テテマーチ導入事例」、公開確認日2026年)

時間や件数で効果を決めておくと、追加投資を判断しやすくなります。

稼働後は、法改正や組織変更、権限変更を定期的に点検します。退職者の削除や連携エラーも、同じ周期で見直します。バックアップや脆弱性情報も、点検の対象です。

追加要望は、法令対応と業務停止のリスクを先に見ます。そのうえで、効果や費用、他機能への影響を比べます。

利用率が低いときは、項目の多さや、実態と異なる承認経路が原因になっていないかを確認します。スマートフォンに非対応かどうか、権限が厳しすぎないかも見ておきます。

ポイント

各フェーズで成果物と判定基準を決め、承認してから次へ進みます。給与や複雑な連携は、初回稼働のあとに段階的に広げる目安です。

従業員管理システムの費用相場とコストの内訳

クラウド標準導入、部分開発、中規模刷新、基幹刷新の初期費用レンジを横棒で示した図。
要件の広がりに応じて、初期費用の想定幅も大きくなります。

従業員管理システム単独の公的な統一相場はありません。費用は、導入方式や従業員数、拠点数で変わります。

さらに、雇用形態やデータの状態、連携本数が影響します。給与計算の複雑さやセキュリティ要件、支援範囲も、費用に関わります。

ここで示すのは、NotebookLMリサーチノートにある人事・労務・給与システムの相場と類似案件を、従業員管理の要件に読み替えた推定です。ただし、特定の発注金額を保証するものではありません。

構築パターン別の初期費用の幅

構築パターン別の推定レンジは、標準導入から基幹刷新まで幅があります。そのため、初期費用に含まれる作業と、月額料金は分けて確認します。

  • クラウド標準導入:0万〜300万円程度です。
  • 部分開発:300万〜1,500万円程度です。
  • 中規模刷新:1,500万〜4,000万円程度です。
  • 基幹刷新:4,000万円〜1億円超の可能性があります。

標準導入の目安には、初期設定や権限設定、帳票を含みます。簡易データ移行と操作教育も、この目安に入ります。ただし、月額利用料や有料オプションは別途かかるため、初期費用だけでは判断できません。

部分開発は、従業員データベースや入退社、申請などが対象です。一方で、中規模刷新は、勤怠や給与、従業員情報を統合するケースです。

複数法人や複雑な制度、大規模な既存連携を含む基幹刷新では、上記より高額になる可能性があります。ここまでの金額は、要件の読み替えによる概算です。

要件整理が済んだら、画面数や帳票数、連携本数を積み上げて、金額を再計算します。移行件数やテストシナリオ数、PMの関与量も同じように数えます。

マネーフォワード クラウド人事管理の公開料金は、法人50名以下の場合で、年払いは月2,480円から、月払いは3,980円からです。51名以上は、個別見積もりになります。

同社の案内では、人事管理の従量課金は、登録従業員1名あたり月額600円です(出典:株式会社マネーフォワード公式料金ページ、2026年確認)。これは人事管理サービスの公開例で、給与や勤怠、マイナンバー、導入支援は、この料金とは分けて考えます。

月額費用と保守費用の3年総額

ランニング費用は、サービス料に加えて、課金や保守、支援まで含めて確認します。

  • サービス費:利用料、従業員数課金、ストレージ、オプション。
  • 運用費:連携基盤、監視、問い合わせ、法改正対応。
  • 保守費:改修費と、対応時間帯や契約単位の扱い。

NotebookLMリサーチノートでは、従業員100名規模のクラウド勤怠・給与などで、月額10万〜30万円程度という相場が示されています。ただし、これは対象サービスと支援範囲による推定です。

個別開発では、初期開発費の5〜15%を保守の目安とする回答もあります。ただし、月額か年額か、時間外対応を含むかは契約ごとに異なるため、割合だけで判断しない方がよいでしょう。

クラウド製品では、初期導入サポートが無料の場合もあります。ただし、業務設計やデータクレンジングは、別料金になる場合があります。個別研修や運用代行なども、別料金の場合があります。

SmartHRは、初期導入費用とサポート費用を無料と案内しています。一方で、状況に応じた導入・運用支援は別途費用と説明しています(出典:株式会社SmartHR「料金プラン」、2026年確認)。

3年総額には、初年度の費用のほか、2年目と3年目の料金改定を含めます。さらに、従業員増加や解約、データ返却まで見込みます。

ポイント

費用は構築パターンと要件の広がりで大きく変わるため、初期費用だけでなく、月額や保守を含めた3年総額で比べてください。

従業員管理システムの見積もりを取る際のポイント

見積もりの精度は、発注側がどこまで前提をそろえて伝えられるかでも変わります。たとえば「従業員情報を一つにまとめたい」という依頼では、画面やデータ移行、例外処理の範囲が見えてきません。判断材料を文書にまとめ、同じ条件で複数社に依頼すると、価格差の理由と自社の優先順位が見えやすくなります。

RFPに入れる業務、データ、連携、非機能要件

RFPでは、業務とデータの内容をそろえて書きます。連携や非機能要件も、具体的な業務シナリオとともに示します。

  • 業務と規模:対象の人数、拠点、勤務条件
  • データと連携:件数、移行期間、帳票、API・CSV
  • 非機能と日程:セキュリティ、復旧、支援、稼働日
  • 業務シナリオ:例外を含む一連の処理

対象の従業員数や増加の見込み、法人・拠点数を書きます。雇用形態と勤務パターン、給与締め日も並べます。現行システムやデータ件数、移行対象期間も含めます。必須帳票や希望稼働日、予算上限も明記します。

スマートフォン対応や、SSOやMFAといった認証の方式を見ておきます。可用性や復旧目標、操作ログも、確かめておきます。データ保管場所やサポート時間の扱いも、決めておく必要があります。法改正対応は、どこまでを誰が受け持つかも決めておきます。

業務シナリオは、新入社員の登録や扶養家族の変更、組織異動を、少なくとも用意します。加えて、兼務の追加や休職・復職、退職も含めます。管理者の退職による権限変更も、必ず含めます。

各シナリオには、入力者と承認者、完了条件を添えます。さらに、エラー時の対応と出力先も書いておきます。

例外を先に伝えておくと、想定外のカスタマイズによって費用や納期が膨らむリスクを下げられます。

複数社の見積もりの作業範囲と前提の比較

見積もりは総額だけでなく、作業範囲と前提、追加費用まで並べて比べます。

  • 作業範囲:工程別の費用と、成果物や完了条件
  • 契約条件:変更、検収、遅延、データ不備の扱い
  • 総額の差:抜け作業と将来の追加費用

工程は、要件定義、業務・画面設計、開発の順に分けて見ます。テストや移行、教育、保守も、工程ごとの費用として切り分けます。

PMやインフラの費用は、別の項目として見ておきます。工数一式や諸経費一式が多い場合は、内訳を確認します。

追加変更の単価と検収方法、遅延時の扱いは、契約前に確かめます。データ不備の責任範囲や、ライセンス費の値上げ条件も、確認が必要です。

製品ベンダーの見積もりが安くても、別会社による移行や連携開発が必要なら、総額は変わります。

一方で、受託会社の提案は高く見えても、データクレンジングや受入支援、教育が含まれる場合があります。稼働後の問い合わせ対応まで入っていることもあります。こうした比較が、適切な発注先を選ぶ近道になります。

失敗を防ぐチェックリストの契約と運用への落とし込み

契約と運用では、データ保護と責任者を明確にします。また、共有手順と稼働判定の基準も決めておきます。

  • 契約・安全管理:データ、復旧、障害、委託先の条件
  • プロジェクト運営:担当者を置いたうえでの、課題と予算の週次確認
  • 稼働判定:給与、申請、障害時の業務の継続性

契約前には、データの所有権やバックアップの頻度、復旧目標を確かめます。障害時の連絡経路や脆弱性対応、委託先の再委託も、確認が必要です。監査ログの保管期間や解約時のデータ形式、他社への移管支援も対象に入ります。

個人情報保護委員会のガイドラインでは、基本方針と取扱規程、安全管理措置(組織的・人的・物理的・技術的)、外的環境の把握が示されています。

マイナンバーや給与情報を扱う場合は、取扱担当者と端末を決めます。異動や退職の際に権限を止める時期と、ログを点検する人も決めておきます。

発注側では、責任者や業務代表を決めます。データ担当やセキュリティ担当、承認者も決めておきます。週次では、決定事項や変更要求、納期を確認します。

要件定義書やデータ定義書、操作手順は、関係者で共有しておきます。テスト結果と運用ルールも共有し、担当者一人に知識が集まることを避けます。稼働判定では、予定日に間に合うかどうかに加えて、業務上の基準も確認します。

ポイント

RFPで要件と前提をそろえ、同じ条件で複数社に依頼すると、価格差の理由が見えてきます。契約前には、作業範囲と追加費用、運用の条件まで確かめてください。

従業員管理システム開発でよくある質問

開発前に質問されやすい論点を、判断の順番に沿って回答します。判断では、従業員数だけで決めず、業務の複雑さや既存システム、データ品質を見てください。社内の運用体制も確認してください。

従業員管理システムはクラウドとスクラッチのどちらがよいですか?

標準的な人事・労務業務を早く始めたいならクラウド、独自制度や大規模な既存連携が中核なら、パッケージまたは個別開発が候補になります。

特殊な要件が一部だけなら、全体をスクラッチで作るより、クラウドを基盤にAPI連携や周辺機能だけを開発する方法もあります。

法改正やセキュリティ、担当者交代まで含めて、長期運用の負担で比べてください。

従業員管理システムの費用は何名規模で変わりますか?

クラウドでは、従業員数が月額課金の基準になりやすい点が特徴です。一方で、個別開発では人数に加えて、拠点や雇用形態、連携の内容が費用を左右します。権限やデータ量、テストケースも、費用に関わります。

そのため、100名だからいくらと一律に断定することはできません。費用は、初期費用や移行、教育と、月額や保守、法改正対応に分けて考えます。そのうえで、3年総額と1人あたりの運用負担を確認します。

2026年に補助金を使って導入できますか?

対象ツールや申請枠、補助対象経費の要件を満たせば、デジタル化・AI導入補助金2026を検討できる可能性があります。申請時期や登録支援事業者の要件も、確認が必要です。

中小企業庁は2026年3月に公募要領を公開し、6月に通常枠などの1次締切の採択結果を案内しています(出典:中小企業庁「デジタル・IT化支援」、2026年)。

採択や対象可否を前提に、契約や稼働日を決めるのは危険です。申請前には、最新の公募要領や締切を確認してください。対象製品と支援事業者も見ておきましょう。

Excelのデータ移行で特に注意することは何ですか?

まず、表記ゆれや重複、空欄を整理します。古い所属やコード体系、退職者の扱いも確かめ、移行対象と対象外を決めます。

元データをそのまま取り込まず、項目定義や必須条件、変換ルールを作ります。照合方法も用意し、本番前に複数回のリハーサルを行います。

給与や休暇残数などの情報を移す場合は、法定保存と業務上の参照期間を確認します。移行後は、件数や代表データ、権限表示を検証してください。

ポイント

クラウドか個別開発かは、従業員数だけでなく業務の複雑さや既存システム、データ品質で判断します。補助金は公式情報で再確認し、Excelからの移行は、データの整理と照合を先に進めてください。

まとめ

成功には、機能一覧より先に、入社から退職までの業務の流れを整理することが大切です。そのうえで、データと権限を決めます。連携や例外処理も、同じ流れで決めていきます。

6フェーズごとに成果物と判定基準を決め、MUSTとWANTを分けて、段階的に進めます。

6フェーズの判定基準の確認

要件整理では現行業務とMUST要件を、選定では標準機能と総保有コストを確認します。設計・開発ではデータと権限を、テストでは業務シナリオと給与結果を検証します。

稼働では移行と問い合わせ体制を、定着では利用率と効果指標を見ます。各フェーズの成果物を承認してから進むと、後工程の手戻りを減らせます。

発注前の自社の業務一覧と質問事項の作成

発注前に業務一覧と質問事項をまとめ、要件と総額を確かめてから方式を決めます。

  • 費用の幅:標準導入0万〜300万円、部分開発300万〜1,500万円。
  • 刷新の目安:中規模刷新は1,500万〜4,000万円程度。
  • 比較方法:3年総額をそろえたRFPで、複数社に依頼。
  • 契約前確認:料金や補助金の、公式情報による再確認。

これらは、要件とリサーチ情報に基づく推定レンジです。3年総額で比べるときは、初期費用や移行、教育を含めて見ます。

さらに、月額料金や保守の費用を加えます。法改正対応や解約・移管にかかる分も含めて、比べてください。

最終判断では、標準機能に業務を寄せられるか、独自要件をどこまで残すか、社内で運用を引き継げるかを基準にします。目指すのは、現場が使い続けられ、給与や手続きの正確性が保たれ、データを人材施策に活かせる状態です。

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

会社紹介

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

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

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

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

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

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