スタッフ管理システム開発の発注/外注/依頼/委託方法について

スタッフ管理システムの発注・外注は、店舗型か派遣管理型かを先に分け、現行業務と必要な連携を整理してから、SaaS・パッケージ・スクラッチ開発を選ぶことが基本です。

Excelや紙、LINEで集めた勤務希望の転記、急な欠勤の補充、勤怠から給与・請求への二重入力に悩む企業では、機能を足すだけではなく、業務のどこを委託するかまで決める必要があります。本記事では、発注形態の選び方、RFPと要件整理、請負・準委任の使い分け、2026年時点の費用相場、委託先と見積書の比較ポイントを、発注者が実際に判断できる順番で解説します。

▼全体ガイドの記事
・スタッフ管理システム開発の完全ガイド

スタッフ管理システムの発注・外注は何から始めますか？

最初に決めることは、開発会社を探すことではなく、管理対象と業務の境界です。「スタッフ管理システム」という言葉には、店舗や拠点のシフト・勤怠を扱う仕組みと、人材派遣・紹介会社が登録スタッフ、案件、契約、給与、請求まで扱う仕組みの両方が含まれます。ここを分けないまま相見積もりを取ると、同じ名前の機能でも各社の見積範囲が異なります。

店舗・多拠点型では、スタッフマスタ、勤務可能日、希望シフト、必要人数、スキル条件、確定通知、出退勤、人件費の集計が中心です。店長やエリアマネージャーがスマートフォンから希望を回収し、欠勤時に勤務可能な人へ募集を送る運用も対象になります。POSや売上予測と連携して人時売上まで見たい場合は、シフト管理だけでなく経営指標の設計が必要です。

派遣・紹介型では、応募者や登録スタッフ、求人・案件、スキル、就業先、契約、派遣帳票、勤怠承認、給与、請求までが対象になります。契約更新、資格期限、抵触日、本人確認書類、マイナンバーなども関係するため、店舗向けシフトアプリだけで置き換えることはできません。RFPの冒頭に「店舗型」「派遣管理型」「両方の連携型」のどれかを書いておくと、提案の前提がそろいやすくなります。

発注目的は「最新のシステムを導入する」ではなく、測定できる業務課題で定義します。たとえば、シフト作成にかかる時間、希望シフトの回収率、欠勤が埋まるまでの時間、勤怠締めにかかる日数、転記ミス、問い合わせ件数、人件費率などです。派遣会社なら、スタッフ情報の重複登録、案件とのマッチング漏れ、勤怠未回収、契約更新の確認漏れ、請求確定までの日数を導入前に記録します。

この数値が分かると、発注先へ「何を作るか」だけでなく「何が改善すれば成功か」を伝えられます。反対に、目的が「AIで自動シフトを作りたい」のような機能名だけだと、休み希望、連勤、夜勤明け、資格、最低人数などの制約条件が抜けやすくなります。自動化の対象と、最後に管理者が判断する部分を分けておくことが安全です。

発注形態はどのように選びますか？

発注形態は、現場の標準化の度合い、独自ルールの重要性、導入までの時間、将来の拡張、社内の運用体制で選びます。短期間で標準機能を使いたい場合はSaaS、業界固有の帳票や業務を早く整えたい場合はパッケージ、独自の配置ルールや基幹連携が競争力になる場合はスクラッチまたはハイブリッドが候補です。

SaaSは、サーバー運用、アップデート、バックアップ、脆弱性対応を自社で抱えにくく、無料体験や小規模導入から始めやすい方式です。ただし、課金単位がスタッフ数なのか管理者数なのか拠点数なのか、初期設定やデータ移行が別料金か、解約後にデータを返却できるかを確認します。スマートフォンの画面が用意されていても、スタッフが実際に使う通知手段や、未提出者への催促、欠勤募集が自社の運用に合うとは限りません。

派遣管理パッケージは、人材・案件・契約・勤怠・給与・請求などの標準知識を利用しやすい点が強みです。標準機能に合わせて業務を整理するFit to Standardを基本にし、独自要件はAPIや周辺機能へ切り出すと、法改正やバージョンアップの負担を抑えやすくなります。見積もりでは、標準機能、設定変更、追加開発、連携、保守を分けて提示してもらいます。

スクラッチ開発は、自社独自のシフト制約、評価、需要予測、スタッフと案件のマッチング、既存基幹との連携を設計に合わせられます。一方で、要件定義、設計、テスト、データ移行、教育、保守を自社と開発会社が継続して担う必要があります。すべてを独自開発するのではなく、スタッフ台帳や認証は既存サービス、独自性の高い配置ロジックだけを開発する方法も現実的です。

ハイブリッドでは、SaaSやパッケージを業務の土台にし、APIで給与・会計・POS・求人・勤怠をつなぎ、必要な画面だけを追加します。外注先には、将来の仕様変更時にどの範囲を自社で変更できるか、APIの仕様書とソースコードの扱い、障害時の責任分界を確認します。独自開発の範囲が広がるほど、初期費用だけでなく保守費用も増える点に注意が必要です。

一括発注は、全体の納期と責任範囲を一本化しやすい方法です。要件が固まり、対象拠点や連携先が明確で、社内の意思決定も速い場合に向いています。ただし、現場の例外を把握しないまま全社開発を始めると、リリース直前に仕様変更が集中します。大規模な一括発注では、設計前に現場検証の工程を置くことが重要です。

段階発注は、現状調査・要件定義、PoC、1拠点のMVP、本番展開のように分ける方法です。まずスタッフマスタと希望回収だけを試し、シフト作成時間や未提出率を測り、その結果を勤怠・給与連携へ広げます。要件定義を急ぐと後から例外ルールが発覚し、工数や費用が1.3〜1.5倍に膨らむ場合があるため、リサーチノートでは段階的な要件確認が推奨されています。

RFPと要件整理には何を盛り込めばよいですか？

RFPは、提案依頼先が同じ前提で提案と見積もりを出すための資料です。「スタッフを管理したい」という機能一覧だけではなく、業務上の課題、対象範囲、利用者、データ、連携、非機能要件、納品物、評価基準、希望スケジュールを記載します。IPAも要件定義では業務の要求とシステム化する要求を分けて整理する考え方を示しており、発注者が要件の意図を説明できる状態を作ることが大切です（出典: IPA「要件定義とは？今さら聞けないDX関連用語」）。

現状調査では、スタッフ数、拠点数、管理者数、雇用区分、月間のシフト件数、勤務パターン、現在使っているExcel・紙・チャット・勤怠・給与システムを一覧にします。担当者へのヒアリングだけでなく、希望を集める、シフトを作る、変更を通知する、打刻を承認する、給与用データを締めるという流れを実際に観察します。入力者、承認者、次に使うデータの行き先まで記録すると、二重入力の原因が見えます。

例外には、急な欠勤、遅刻、勤務交換、応援要員、資格期限、連勤、夜勤明け、最低人数割れ、店舗間移動、契約更新、勤怠未回収を含めます。通常ケースだけで要件を作ると、現場が一番困る場面でシステムが使えません。例外の発生頻度、現状の対応方法、誰が最終判断するかをRFPに書き、必須要件と将来要件を分けます。

スタッフマスタには、氏名、連絡先、所属、雇用区分、時給、勤務可能時間、スキル、資格、有効期限を定義します。店舗型では希望提出、必要人数、シフト自動作成、確定通知、欠勤募集をつなぎ、派遣型では応募者、登録、案件、マッチング、就業先、契約、勤怠、給与、請求をつなぎます。「機能があるか」ではなく、「誰が入力し、誰が承認し、どのデータが次へ渡るか」を受入条件まで落とし込むことがポイントです。

給与・会計・POS・求人・入退室などと連携する場合は、スタッフID、拠点コード、勤務区分、割増条件、締め日、支払日を共通化します。CSVで十分か、APIが必要か、連携エラー時に再送できるか、どのシステムを正本にするかも明記します。AI自動シフトを入れる場合は、制約条件の設定、結果の理由、手動修正、再計算、承認履歴まで要件に含めます。

非機能要件には、利用者数、スタッフ数、拠点数、同時利用数、ピーク時の応答、稼働時間、バックアップ、復旧目標、監視、保守窓口、障害時の連絡時間を含めます。権限は、本部、拠点責任者、コーディネーター、給与担当、スタッフ本人などの役割ごとに、閲覧、登録、変更、承認、削除、出力を分けます。操作履歴には、実行者、日時、対象データ、変更前後の値を残せるか確認します。

スタッフの本人確認書類やマイナンバーを扱う場合は、通常のスタッフ情報と保管場所、権限、ログ、保存期間を分離します。個人情報保護委員会は、個人データの委託先について、再委託の相手方や業務内容の事前報告・承認、定期的な監査などで安全管理を確認することが望ましいと示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。RFPでは、再委託、海外保管、インシデント通知、データ返却・削除も質問します。

契約形態は請負と準委任をどう使い分けますか？

契約形態は、完成させる成果物と受入条件が固まっているか、発注者と開発会社がどこまで協力して要件を決めるかで選びます。スタッフ管理では、企画・現状調査・要件定義を準委任、仕様が確定した開発や納品を請負、リリース後の改善を保守・運用契約に分ける構成が実態に合いやすいです。契約名だけでなく、各工程で何を合意するかを確認します。

請負契約は、決められた成果物を完成させ、発注者が検収する工程に向いています。たとえば、スタッフマスタ、希望提出、シフト確定、勤怠出力、管理者権限を対象にし、画面、帳票、API、テスト仕様書、操作マニュアルを納品物として定義します。検収条件には、通常ケースだけでなく、欠勤、勤務交換、権限不足、連携エラー、データ移行後の件数照合などを含めます。

仕様変更が発生したときの見積方法、承認者、納期への影響、瑕疵や不具合の扱いも契約前に確認します。「一式」と書かれた範囲に何が含まれるか、受入テストを誰が行うか、検収が遅れたときの扱いが曖昧だと、開発終盤に追加費用や責任分界の問題が生じます。経済産業省が公開する情報システムのモデル取引・契約書第二版も参考にしながら、法務担当や専門家と確認します。

準委任契約は、専門家が調査、設計、会議、開発支援などの業務を善良な管理者の注意をもって行う工程に向いています。現場ヒアリングをしながら要件を確定する場合や、アジャイルで優先順位を変える場合、発注者側にも意思決定とレビューの役割がある場合に適しています。成果物の完成だけを約束する契約ではないため、作業範囲、体制、稼働時間、会議体、成果の確認方法を具体化します。

準委任だから品質を問えないわけではありません。要件定義書、業務フロー、画面一覧、データ定義、課題管理表、レビュー記録など、工程ごとの成果を合意しておくと、次の請負工程へ移りやすくなります。月次の稼働報告、課題の優先順位、追加作業の承認方法を定例化し、発注者が判断を先送りしないことも重要です。

契約書では、ソースコード、設計書、データモデル、API仕様、テストケース、マニュアルの権利帰属と利用範囲を確認します。既存のOSSや開発会社の共通部品を使う場合は、第三者ライセンスと、契約終了後に自社が利用できる範囲を確認します。スタッフデータの所有・利用目的、バックアップの保存場所、契約終了時の返却形式と削除証明、再委託先の管理も対象です。

保守契約では、受付時間、一次回答と復旧の目標、法改正対応、OSやミドルウェアの更新、脆弱性対応、バックアップ、障害時の代替運用を定めます。個人情報や勤怠を扱うシステムでは、開発が終わった後のアカウント管理とログ監視が続くため、初期開発費だけでなく、毎年の運用費と人員を予算化します。

スタッフ管理システムの費用相場と開発期間はどの程度ですか？

スタッフ管理だけを対象にした公的な開発費用統計は確認できないため、以下は公開料金と、類似する人事・勤怠・派遣管理などの業務システムの相場を組み合わせた目安です。実際の費用は、スタッフ数、拠点数、雇用区分、連携本数、データ移行、権限、帳票、法令対応、保守範囲で変わります。特定の金額をそのまま発注予算とせず、同じ前提の見積もりで確認します。

小規模なシフト管理SaaSは、無料体験や初期費用無料で始められるサービスがあります。たとえばAirシフトの公式料金ページでは、無料体験後の利用料をスタッフ1人あたり月額330円（税込）とし、スタッフ数が2人以下の場合は月額990円（税込）としています。初期費用とサポート費用は無料とされていますが、スタッフ用アプリとの連携人数が課金対象になるため、実際の人数変動を前提に試算します（出典: 株式会社リクルート「Airシフト 費用・料金」、2026年確認）。

派遣管理SaaSの例として、STAFF EXPRESSの公式料金ページでは、スモールプランが月額25,000円から、ライトが月額30,000円から、オールインワンが月額35,000円からと掲載されています。買い切りプランも月額プランとは別に示されていますが、機能、アカウント、導入支援、追加連携、データ移行の範囲によって総額は変わります（出典: 株式会社エスアイ・システム「STAFF EXPRESS 料金」、2026年確認）。公開料金は比較の起点であり、導入費込みの3年総額とは分けて考えます。

リサーチノートの類似業務システムの推定では、シフト、スタッフ台帳、権限、通知を中心とする小規模スクラッチ開発は300万〜800万円程度、複数拠点で勤怠・給与・API連携やデータ移行を含むと800万〜2,000万円程度が目安です。派遣のマッチング、契約、帳票、勤怠、給与、請求、マイナンバーまでを統合する総合基盤では、1,500万〜5,000万円超になる可能性があります。いずれも統計的な確定価格ではなく、要件から算出するレンジです。

開発期間も、小規模なら3〜6か月、複数拠点や連携を含むと6〜12か月、派遣業務の総合基盤では9〜18か月以上が一つの目安です。要件定義、設計、実装、テスト、移行、教育を含めるかで期間は変わります。開発会社の人月単価は、リサーチノートで中小規模会社が1人月80万〜120万円程度、大手SIerが150万〜200万円程度という業務システム一般の目安として整理されています。会社名や工程を隠したまま単価だけを比べないことが大切です。

総保有コストには、初期設定、要件定義、開発、ライセンス、スタッフ向けアプリ、データ移行、API連携、端末、研修、問い合わせ対応、保守、法改正、脆弱性対応、追加ユーザー、解約時の移行を含めます。SaaSの月額が安くても、複数拠点や管理者を追加したときの課金、外部連携、導入支援が別料金なら、3年後の総額は変わります。スクラッチも、開発費だけでなく、運用担当者と保守契約を毎年確保します。

見積書では、要件定義、設計、実装、テスト、移行、教育、リリース、保守を別行にしてもらいます。リサーチノートでは、リリース後の保守・運用費を初期開発費の年15〜25％程度として予算化する考え方が示されていますが、SLA、対応時間、法改正や機能追加を含むかで変わります。率だけで決めず、何を何時間まで対応する契約かを確認します。

委託先選定と見積比較では何を確認しますか？

委託先は、知名度や提示価格だけではなく、対象業態への理解、要件定義の力、連携と移行の経験、運用まで支える体制で選びます。店舗型のシフト最適化と、派遣型の契約・請求管理では必要な知識が異なるため、同業・同規模に近い導入事例を確認します。事例は導入社数だけでなく、何人・何拠点で、どの業務時間やミスがどう変わったかを聞きます。

具体例として、オーエムネットワークの公式導入事例では、アルティウスリンクが600名以上のシフト管理にR-Shiftを導入し、毎月9日かかっていたシフト作成を1日に短縮したと紹介されています。これはベンダー掲載の事例であり、自社で同じ効果が得られると断定できる数字ではありませんが、発注前に「対象人数」「現行の作成日数」「紙やExcelからの移行」「勤怠連携」を確認する際の質問例になります（出典: オーエムネットワーク「R-Shift 導入事例」、事例記載時点2023年）。

店舗型なら、複数店舗の人員差配、希望回収、欠勤補充、売上や人件費の連携を確認します。派遣型なら、案件とのマッチング、契約書や帳票、就業先との勤怠承認、給与・請求、資格期限の管理を確認します。提案担当者が機能を説明するだけでなく、現場責任者や運用保守担当者が参加し、例外ケースをその場で説明できるかを見ると、導入後の体制を想像しやすくなります。

確認したい質問は、同規模の導入先での稼働人数、移行したデータの種類、標準機能と個別開発の境界、給与・会計・POSなどとの連携方式、障害時の代替運用、導入後のサポート窓口です。AI自動シフトを提案された場合も、休み希望や資格、最低人数を守れなかったときの検知、説明、修正、承認履歴まで確認します。

相見積もりでは、同じRFPと同じ質問票を渡し、各社が置いた前提条件を並べます。要件定義、画面・データ設計、開発、テスト、連携、移行、教育、PM、保守を分解し、「一式」の行を減らします。特に、スタッフ数、拠点数、管理者数、API本数、過去データの移行範囲、帳票の本数、スマートフォン対応、受入テストの担当を揃えないと、安い見積もりほど対象外が多いことがあります。

金額のほか、納期、体制、発注者側の作業、成果物、検収条件、変更単価、保守、再委託、データ返却を比較します。提案書の機能数が多い会社より、不要な機能を削り、MVPと将来拡張を分けている会社のほうが、予算と現場の負担を管理しやすい場合があります。見積比較表には、初期費用、月額・保守、3年総額、未確定項目、リスク、質問への回答を記録します。

スタッフ管理システムでは、氏名、連絡先、勤務実績、給与に関する情報、資格、本人確認書類などを扱う可能性があります。最小権限、MFA、通信・保存時の暗号化、操作ログ、バックアップ、脆弱性対応、退職者のアカウント停止、開発環境への本番データ持ち出し禁止を確認します。勤怠機能では、厚生労働省のガイドラインが始業・終業時刻を確認・記録し、原則として客観的な記録を基礎にする考え方を示しているため、打刻修正の履歴と承認者を残せる設計にします（出典: 厚生労働省「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」）。

運用開始後に特定の担当者や開発会社しか変更できない状態を避けるため、管理者マニュアル、データ定義、API仕様、障害対応手順、バックアップ復旧手順、テストデータ、アカウント棚卸しの方法を納品物に含めます。契約終了時にデータをCSVや汎用形式で返却できるか、ソースコードやクラウド環境の管理権限をどう引き継ぐかも、選定段階で確認します。

発注からリリースまでをどの順番で進めますか？

外注プロジェクトは、現状調査、要件整理、RFP配布、提案・見積比較、契約、設計・開発、テスト、移行・教育、段階リリース、効果測定の順に進めます。各工程の終わりに、発注者が何を承認するかを決めておくと、問題を次の工程へ持ち越しにくくなります。

提案評価では、機能、費用、納期だけでなく、業務理解、体制、移行計画、テスト計画、セキュリティ、保守、データ返却を同じ基準で確認します。候補を決めた後は、契約前に要件の未確定項目を洗い出し、いつ誰が決めるかを課題管理表へ記録します。未確定のまま請負契約を結ぶ範囲と、準委任で詰める範囲を切り分けます。

発注者側には、業務責任者、現場代表、情報システム担当、個人情報・法務担当、意思決定者を置きます。開発会社の会議に参加するだけでなく、サンプルデータを出し、画面をレビューし、受入テストを実施する役割が必要です。社内の判断が遅れると開発会社の待機や仕様変更が増え、費用と納期の両方に影響します。

テストは、画面が表示されるかだけでなく、業務シナリオで行います。スタッフ登録から資格期限の通知、希望提出、シフト確定、欠勤募集、打刻、休暇申請、承認、給与用出力までを一連で実行します。派遣型では、案件登録、マッチング、契約更新、就業先承認、請求確定までを確認します。権限不足、同時更新、連携データの重複、通信断、通知失敗、日付の境界も再現します。

データ移行では、スタッフID、所属、雇用区分、時給、資格、過去の勤怠、契約情報を対象にし、移行前後の件数とサンプルを照合します。旧システムに重複や表記ゆれがある場合は、先に名寄せルールを決めます。過去履歴を移行しない場合も、どこに保管し、必要時に誰が参照できるかを決めておくと、現場の問い合わせに対応しやすくなります。

全社同時に切り替えるのではなく、業態や運用が代表的な1〜数拠点でPoCやMVPを実施します。スタッフが自分のスマートフォンで希望を出せるか、管理者がシフトを修正できるか、通知を見落とさないか、通信障害時に業務を続けられるかを確認します。AI自動作成を使う場合も、最終承認を管理者が行い、誤配置時の修正と履歴を残します。

稼働後は、シフト作成時間、希望回収率、欠勤充足時間、転記ミス、勤怠締め日数、問い合わせ件数、人件費率、スタッフの利用率を導入前と比較します。効果が出ない場合は、機能不足だけでなく、通知手段、締切、権限、教育、現場の業務分担を見直します。定着化までを外注範囲に含めるか、運用開始後の改善契約を別に結ぶかを発注時点で決めます。

スタッフ管理システムの発注・外注でよくある質問

最後に、発注前に多く寄せられる疑問へ回答します。費用だけで方式を決めるのではなく、対象業態、スタッフ数、拠点数、連携、運用体制を前提に判断することが共通のポイントです。

標準的なシフト・勤怠を早く始めたい場合はSaaSやパッケージ、独自の配置ルールや基幹連携が競争力になる場合はスクラッチやハイブリッドが向いています。最初から全機能を独自開発するのではなく、SaaSを少数拠点で試し、差別化したい業務だけを追加開発する方法も選択肢です。

スタッフ台帳、希望回収、シフト、権限、通知に絞った小規模開発なら、リサーチノートの目安である300万〜800万円程度の範囲に入る可能性があります。ただし、複数拠点、勤怠・給与連携、データ移行、派遣の契約・請求、本人確認書類を含むと、800万〜2,000万円程度またはそれ以上になる可能性があります。要件、連携、移行、テスト、保守を分けた見積もりで確認し、500万円を上限と断定しないことが大切です。

管理者を不要にするのではなく、制約条件を反映した案を作り、管理者の調整時間を減らす機能として考えます。休み希望、資格、連勤、夜勤明け、最低人数などを正しく設定できるか、結果の理由を説明できるか、手動修正と最終承認を記録できるかを確認します。個人データをAIの学習に使わない設定や、誤配置時の責任分界もRFPと契約に含めます。

社数を先に固定するより、同じRFPに対して比較できる候補を複数社そろえることが重要です。店舗型、派遣型、SaaS導入、スクラッチ開発など候補の得意分野が違う場合は、同じ評価軸で提案を依頼します。価格だけでなく、要件定義の進め方、実績、体制、移行、保守、データ返却、質問への回答の具体性を比較し、自社の発注体制で管理できる相手を選びます。

まとめ

スタッフ管理システムを発注・外注するときは、最初に店舗・多拠点型か派遣管理型かを分け、現状業務と例外処理を棚卸しします。そのうえで、SaaS、パッケージ、スクラッチ、ハイブリッドの適合度を比較し、RFPには機能、データ、連携、非機能、セキュリティ、納品物、評価基準を記載します。

第一に、公開料金や開発費だけでなく、移行、連携、教育、保守、解約時の返却を含む3年TCOで比べます。第二に、請負と準委任を工程に応じて使い分け、成果物、検収、仕様変更、知的財産、個人データ、再委託、障害対応を契約に落とし込みます。第三に、同じRFPで見積もりを取り、業態・規模・連携の実績と、稼働後の運用体制を確認します。

いきなり全社の完璧なシステムを発注するのではなく、スタッフ情報の重複登録、希望シフトの回収、欠勤補充、勤怠締めなど、最も効果を測りやすい業務を一つ選びます。現場の実データと例外をもとに小さく検証し、成果を確認してから拠点、給与・請求、分析へ広げると、費用と導入リスクを管理しやすくなります。発注者側の業務責任者と委託先が同じ成功条件を持てる状態を作ることが、スタッフ管理システム開発の出発点です。

▼全体ガイドの記事
・スタッフ管理システム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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