業務進捗管理システム開発の発注/外注/依頼/委託方法について

業務進捗管理システムの発注・外注は、機能が多い会社を選ぶことではなく、自社の業務フローと達成したい成果を整理し、適切な発注形態と契約範囲を決めることが成功の近道です。まずはSaaS、ローコード、パッケージ、フルスクラッチを比較し、現場入力・既存システム連携・工数や原価の管理レベルに合う方式を選びます。

本記事では、業務進捗管理システムを発注・外注するときの進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較まで一つの流れで解説します。ライセンス料金だけで判断せず、データ移行や教育、運用保守まで含めて比較できるように、2026年時点で確認できる公式情報と受託開発の参考レンジを使って整理します。

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

業務進捗管理システムの発注形態はどう選びますか？

結論から言うと、業務進捗管理システムの発注形態は、業務を標準機能に合わせられるか、独自ルールや基幹連携がどの程度あるかで決めます。短期間で見える化を始めるならSaaS、自社で改善を続けたいならローコード、案件別の工数・原価・請求まで統合するなら業務パッケージやERP、特殊な業務や厳格な連携があるなら受託開発が候補になります。

SaaSは、提供会社が用意したクラウドサービスを月額または年額で利用する形態です。サーバー調達や大規模な初期開発が不要で、アカウント発行、初期設定、既存データの整理を済ませれば、1〜3か月程度で小さく始められる場合があります。担当者、期限、ステータス、コメント、ガントチャートなどが標準で揃っているため、まずExcelやメールに分散した進捗を一つに集めたい会社に向いています。

一方で、標準機能にない承認経路や複雑な原価計算を無理に合わせると、運用が不自然になったり、外部サービスやプラグインの追加費用が増えたりします。料金改定、データのエクスポート可否、解約後の保管期間、障害時の連絡方法も契約前に確認します。公式料金の例では、kintoneは初期費用無料で、ライトが月額1,000円、スタンダードが月額1,800円、ワイドが月額3,000円の1ユーザー課金です。料金は税抜で、2026年8月に確認した出典はサイボウズ公式料金ページです。

ローコードは、画面やデータ項目、ステータス、承認フローを部品の組み合わせで構築する方式です。kintoneのような基盤を使えば、部門ごとの台帳を作り、現場の意見を受けて自社で軽微な変更を続けられます。完全な内製が難しい場合は、最初の要件整理やアプリ構築をパートナーへ外注し、運用後の項目変更は社内担当者が行う分担も現実的です。

ただし、データモデルを部門ごとに別々に作ると、案件番号や顧客名の表記が揃わず、後から横断集計できなくなることがあります。発注時はアプリの画面だけでなく、マスタ、権限、データ連携、削除ルール、バックアップ、運用担当者の教育まで依頼範囲に含めます。自社で変更できる範囲と、外部パートナーへ依頼する変更の線引きをRFPに書くと、将来の費用を読みやすくなります。

案件ごとの工数、外注費、売上、原価、請求、利益予測まで管理する会社は、プロジェクト型ERPや業務パッケージを比較します。たとえばZACは、プロジェクト実行予算、担当者の工数予測、外注費予測、実績原価、収支予測を扱う機能を公式に案内しています（出典: オロ公式プロジェクト管理機能）。進捗を経営数値とつなげる必要がある場合は、タスク管理SaaSだけで足りるかを先に検討します。

フルスクラッチは、特殊な工程、複数拠点の権限、既存基幹との深い連携、独自の監査要件など、標準製品では重要な要件を満たせない場合に選びます。自由度が高い反面、要件定義、テスト、移行、保守引き継ぎの負担も大きくなります。発注前に「なぜ標準機能では足りないのか」を画面や業務ルール単位で説明できない場合は、まずSaaSやローコードの検証から始める方が安全です。

発注・外注はどの順番で進めますか？

発注は、いきなり開発会社へ「進捗管理システムを作ってください」と依頼するのではなく、目的、対象業務、現状の問題、必要な成果を順に整理します。発注者側で業務の判断基準を持てるほど、提案の比較がしやすくなり、開発会社の得意な製品へ一方的に誘導されるリスクも下げられます。

最初に「進捗を見える化する」という抽象的な目的を、測定できる状態へ置き換えます。たとえば、週次の集計に担当者一人あたり4時間かかっている、遅延案件の発見が納期直前になる、案件情報を営業と開発が二重入力している、といった現状を記録します。そのうえで、導入後に週次集計を1時間以内にする、期限超過のタスクを翌営業日までに確認するなど、検証可能な目標を設定します。

対象範囲は、最初から全社の業務を入れず、案件受付から完了までの一つの部門や、代表的な10〜30案件などに絞ります。対象外にする業務も明記します。範囲が曖昧なまま発注すると、開発中に「この承認も必要」「この帳票も必要」と追加され、納期と費用が膨らみます。現場、管理者、経理、情報システムなど、利用者ごとの期待を分けて書くことがポイントです。

候補先を探すときは、製品ベンダー、導入支援パートナー、受託SI会社を同じ「開発会社」として扱わず、役割を分けて調べます。SaaSの標準導入に強い会社と、基幹連携や個別開発に強い会社では、得意な見積単位やプロジェクト体制が異なります。自社と似た業界、利用人数、連携数、運用体制の事例を確認し、事例が自社に適用できる理由まで質問します。

問い合わせ時は、同じRFP、同じ回答期限、同じ質問項目を渡します。提案書に、想定する製品や方式、対象範囲、前提条件、標準機能と追加開発の境界、スケジュール、体制、費用、納品物、リスク、発注者側の作業を含めてもらいます。提案の見た目より、前提条件を明確にし、できないことや別途費用を正直に書いているかを重視します。

候補が絞れたら、デモ画面だけでなく、実際の案件データを匿名化して操作します。現場担当者がスマートフォンで更新できるか、ステータス変更に必要な入力が多すぎないか、管理者が遅延理由と次のアクションを確認できるかを見ます。データ移行のサンプルを入れ、既存の案件番号、担当者、期限、履歴、添付ファイルがどの程度引き継げるかも確認します。

PoCや小規模導入では、機能の多さより、入力完了までの時間、期限超過の検知率、週次会議の確認時間、二重入力の回数を測ります。導入後に利用率が低い場合は、機能不足よりも入力項目やステータス定義が現場に合っていない可能性があります。評価期間、成功条件、評価後に本導入へ移行する条件を契約書や発注書に書いておくと、試行を目的化せずに進められます。

RFPと要件整理には何を書けばよいですか？

RFPは、開発会社へ提案を依頼するための文書です。細かな画面仕様をすべて発注者だけで決める必要はありませんが、解決したい業務課題、対象範囲、利用者、データ、連携、セキュリティ、納期、予算の考え方をそろえておく必要があります。RFPが具体的なほど、会社ごとの提案差を比較しやすくなります。

業務進捗管理システムの中心は、案件や業務がどの状態にあるかを正しく共有することです。「受付」「確認中」「作業中」「承認待ち」「差し戻し」「完了」のようにステータスを定義し、それぞれの開始条件、完了条件、担当者、期限、次に行う作業を決めます。「対応中」のような広すぎる状態を残すと、画面上は進んでいるように見えても、実際の停滞を見つけにくくなります。

WBS、タスク、マイルストーン、依存関係、優先度、遅延理由、次のアクションも整理します。部門によって同じ言葉の意味が違う場合は、共通のステータスと部門固有の補助項目を分けます。管理者向けには案件全体の進捗率、担当者向けには今日やること、経営者向けには納期と採算というように、利用者ごとの表示も要件に含めます。

機能要件は、必須、できれば必要、将来検討の三段階に分けます。必須機能には、案件・顧客・担当者のマスタ管理、タスクと期限、進捗率、ガントチャートやカンバン、コメントと変更履歴、通知、承認、CSV出力を置きます。工数や原価を管理する会社は、実績時間、標準単価、外注費、予算、収支見込み、請求との紐付けも必須かどうかを決めます。

連携要件は、販売管理、会計、勤怠、CRM、チャット、メール、ファイルストレージなどを洗い出し、どちらを正とするか、連携頻度、エラー時の再送、担当者を決めます。APIがあるだけで連携できるとは限らず、項目変換、認証、上限、保守時の影響まで確認が必要です。スマートフォン対応、同時アクセス数、応答時間、バックアップ、復旧目標、データ保持期間も非機能要件に書きます。

顧客情報や個人情報を扱う場合は、全員が全案件を見られる設計にしないことが重要です。部署、役職、案件、協力会社などの単位で閲覧・編集・承認・出力権限を分け、退職者や外注先のアカウントをすぐ無効化できるようにします。個人情報保護委員会のガイドラインでも、アクセス制御、アクセス者の識別と認証、外部からの不正アクセス等の防止が技術的安全管理措置として示されています。出典は個人情報保護委員会「通則編」です。

操作ログの保存期間、ログを確認する担当者、バックアップの世代数、復旧テスト、脆弱性対応、委託先の再委託管理も確認します。IPAの「情報セキュリティ10大脅威 2026」では、組織向けの1位がランサム攻撃、2位がサプライチェーンや委託先を狙った攻撃、3位がAIの利用をめぐるサイバーリスクです（出典: IPA「情報セキュリティ10大脅威 2026」）。AI要約や検索を使う場合は、入力データの学習利用、参照範囲、権限の継承、利用上限、生成内容の確認責任をRFPと契約で確認します。

契約形態は請負と準委任のどちらがよいですか？

契約形態は、成果物と完成条件を明確にできる工程には請負、要件を一緒に検討しながら進める工程には準委任が向いています。実際には、要件定義を準委任、設計・開発を請負、リリース後の改善を準委任とするように、工程ごとに分けるケースが多くなります。契約名だけで判断せず、誰が何に責任を持つかを確認します。

請負契約では、受託者が合意した成果物を完成させ、発注者が検収する流れになります。業務進捗管理システムなら、画面、データ項目、権限、通知、外部連携、移行データ、テスト結果、操作マニュアルなどを納品物として定義します。単に「システム一式」と書くのではなく、受入テストで何を満たせば合格か、検収期間、修正対応、瑕疵対応の範囲を明記します。

請負でも、発注者の確認が遅れたり、要件が途中で変わったりすると納期へ影響します。変更管理の手順、追加費用の見積方法、優先順位の決め方を契約書や個別契約に定めます。ソースコード、設定情報、設計書、API仕様、データエクスポート方法をどこまで引き渡すかも、将来のベンダー変更に備えて確認します。

準委任契約は、受託者が専門的な作業を行うことを委託する形態です。要件定義、現状分析、プロトタイプ、アジャイル開発、リリース後の改善など、進めながら内容を具体化する工程と相性があります。成果物の完成を一方的に保証する契約ではないため、稼働時間、担当者のスキル、定例会、報告書、レビュー、課題管理、作業期間を決めて管理します。

準委任で特に注意したいのは、作業を依頼する側と指揮命令を行う側を混同しないことです。発注者の責任者が優先順位をまとめ、受託者の責任者へ依頼する体制にします。毎月の作業実績と残課題を確認し、契約更新や次工程への移行を判断します。費用を抑えるために必要な役割を削ると、要件整理や品質確認が発注者側に戻り、結果的に社内負担が増えることがあります。

契約前には、秘密保持、個人情報の取扱い、再委託、知的財産権、第三者サービスの利用、脆弱性対応、障害時の連絡、損害賠償の範囲、解約とデータ返却を確認します。特にSaaSでは、利用終了後にデータをどの形式で何日間取得できるかが重要です。受託開発では、汎用部品と自社専用の成果物を分け、利用許諾や二次利用の条件を明確にします。

業務進捗管理システムは、協力会社や外注先が案件情報にアクセスすることもあります。社外ユーザーの権限、アクセス期間、持ち出し制限、退職・契約終了時のアカウント停止、監査ログの確認者を決めます。法務や情報システム部門だけでなく、実際にデータを登録・閲覧する現場責任者にも契約条件を確認してもらうと、運用開始後の認識違いを減らせます。

業務進捗管理システムの費用相場はいくらですか？

費用は、利用人数、対象業務、データ移行量、外部連携、権限の複雑さ、カスタマイズ、導入支援の範囲で大きく変わります。受託開発の公的な一律相場があるわけではないため、以下はリサーチノートで整理した類似業務システムの参考レンジです。見積を保証する金額ではなく、RFPを作る前に投資規模を考えるための目安として扱います。

SaaSを標準機能で導入する場合は、初期費用が0〜50万円程度、月額は1ユーザーあたり1,000〜3,000円程度、または組織単位で月額数千円〜数万円程度が一つの参考レンジです。期間は1〜3か月程度が目安ですが、設定、データ移行、教育、権限設計を含めると長くなることがあります。たとえばBacklogは、公式料金ページでスターター月額2,700円、スタンダード月額16,000円、プレミアム月額27,000円、プラチナ月額75,000円を案内しています。料金は税抜で、2026年8月に確認した出典はBacklog公式料金ページです。

ローコードの設定・連携は、初期費用30〜300万円程度、1〜4か月程度が類似業務システムからの推定目安です。パッケージ導入と部分カスタマイズは500万〜5,000万円程度、6か月〜1年程度、フルスクラッチや大規模SIは1,000万〜数億円以上、6か月〜数年程度まで幅があります。独自業務や連携が増えるほど上限側へ寄りますが、会社規模だけで決めず、必要な品質・運用期間・業務効果とのバランスで判断します。

開発費の内訳は、要件定義10〜15％、基本設計15〜20％、詳細設計10〜15％、開発・製造30〜40％、結合・総合テスト15〜20％、移行・導入5〜10％を一つの目安にします。これは案件の性質によって変わる推定配分であり、各工程の割合を合計して価格を断定するものではありません。要件定義やデータクレンジングを削ると、後工程の追加開発や移行やり直しが増える場合があります。

見落としやすい費用には、初期設定、追加ライセンス、プラグイン、API利用、サーバー、監視、バックアップ、データ移行、データクレンジング、マニュアル、研修、問い合わせ対応、保守改修、脆弱性対応があります。Backlog AIアシスタントのように特定プランで提供される機能もあるため、機能名だけでなく対象プランと利用条件を確認します。2026年3月に正式リリースされた同機能は、参加しているプロジェクト内のデータを参照し、顧客データをAIモデルの学習に利用しない方針が公式に説明されています。出典はBacklog公式ブログです。

発注判断では、初期費用と月額だけでなく、3年分の総保有コストを試算します。ライセンス、保守、追加開発、連携、移行、教育、社内担当者の工数を年ごとに並べ、ユーザー数が増えた場合と減った場合の両方を確認します。ユーザー課金と組織課金は比較方法が違うため、10人、50人、100人など同じ利用条件で年額を計算することが大切です。

費用対効果は、作業時間が何時間減るかだけでなく、納期遅延、確認会議、二重入力、赤字案件の早期発見、引き継ぎ時間の短縮などで評価します。たとえば週次集計が毎週3時間減り、月に数件の遅延を早期に発見できるなら、導入効果の仮説を置けます。効果が測れない機能を優先して高額な開発を行うと、導入後に投資判断ができなくなります。

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

委託先は、価格の安さだけでなく、自社の業務を理解し、導入後まで責任を持てるかで選びます。見積書の合計金額を比べる前に、同じ前提条件で計算されているか、含まれていない作業が何か、追加費用の条件は何かをそろえます。提案説明に現場責任者や運用担当者が参加する会社は、導入後の定着まで考えているかを確認しやすくなります。

実績は、社名や導入社数の多さだけでなく、自社と似た業務構造を確認します。案件型ビジネスなら、工数・原価・収支を扱った経験があるか、現場作業が多いならスマートフォン入力や通信環境を検証したか、協力会社が使うなら社外権限の設計経験があるかを質問します。紹介された事例について、導入期間、発注者側の体制、移行件数、定着支援、導入後の改善方法も聞きます。

体制では、営業担当だけでなく、プロジェクト責任者、業務分析担当、UIや設計担当、開発担当、テスト担当、保守窓口を確認します。担当者が途中で変わる条件、再委託先、会議の頻度、課題のエスカレーション方法も確認します。開発会社の担当人数が多いこと自体が品質を保証するわけではなく、意思決定者が誰か、発注者に何を求めるかが明確なことが重要です。

見積書は「一式」ではなく、要件定義、画面設計、開発、連携、データ移行、テスト、教育、リリース、保守に分けてもらいます。画面数、帳票数、API本数、移行データ件数、テストケース数、訪問回数など、数量の根拠があると比較しやすくなります。SaaSの場合も、初期設定、アカウント設定、プラグイン、データ整形、マニュアル作成、研修を分けて確認します。

見積金額が安い場合は、要件定義や受入テスト、移行、教育、保守が別途になっていないかを見ます。高い場合は、必須ではない機能、過剰なカスタマイズ、不要なライセンス、発注者側でできる作業が含まれていないかを確認します。各社の提案を同じ評価表に入れ、費用、納期、方式適合、連携、セキュリティ、現場定着、引き継ぎを別々に採点すると、合計金額だけの判断を避けられます。

「何でもできます」「短期間で導入できます」という説明だけで判断せず、できないことを質問します。標準機能で対応できない要件、追加開発が必要な条件、連携先の制約、同時アクセスの上限、データ移行できない項目、AI機能の利用範囲、障害時の復旧目標、サポート時間を聞きます。回答が口頭だけの場合は、提案書や議事録に残して認識をそろえます。

発注者側の体制不足も大きなリスクです。業務を決める責任者、現場の代表、データ移行の担当、受入テストの担当、導入後の管理者を発注前に決めます。外注すれば社内の判断が不要になるわけではありません。自社の業務ルール、優先順位、例外処理、完了条件を決める人がいないと、開発会社が判断を代行することになり、期待と成果物のずれが起きやすくなります。

発注後の定着と運用はどう設計しますか？

システムは納品された日から価値が出るのではなく、担当者が正しい粒度で更新し、管理者がその情報をもとに行動して初めて効果が出ます。発注時から、入力ルール、定例会で見る画面、期限超過時の対応、管理者教育、問い合わせ先、改善要望の受付方法を決めます。

現場が入力しない原因を、意識の問題だけにしないことが大切です。入力項目が多い、同じ情報を複数画面へ入れる、スマートフォンで操作しにくい、ステータスの意味が分からない、入力しても会議で使われない、といった設計上の問題を調べます。最初は案件番号、担当者、期限、ステータス、遅延理由、次のアクションなど、管理に必要な最小項目へ絞り、入力が定着してから項目を増やします。

導入初期は、現場の代表者を含む週次レビューを設け、入力時間、未更新件数、期限超過件数、差し戻し件数を確認します。数字を責めるためではなく、入力しづらい箇所を改善するために使います。kintoneの公式事例でも、紙やホワイトボードで管理していた案件情報を一元化し、現場での改善を進めた例が紹介されています。出典はkintone導入事例「アートワークス」です。

Excelや既存システムから移行する場合は、項目名、表記揺れ、重複、不要な履歴、担当者コード、日付形式、添付ファイル、アクセス権を整理します。全件移行が必須とは限らず、進行中案件だけを移行し、過去データは参照用に別保管する方法もあります。移行前後で件数、金額、期限、担当者、重要な履歴を照合し、現場が検索できることを確認します。

保守契約には、問い合わせの受付時間、障害と不具合の区分、初動時間、復旧目標、アップデートの通知、バックアップ、脆弱性対応、追加改修の見積方法を記載します。受託先を変更する可能性も考え、設計書、ソースコード、設定情報、データベース定義、運用手順、アカウント一覧、連携仕様を発注者が取得できる状態にします。引き継ぎを最後に考えると、移行費用や期間を確保できないことがあります。

2026年は、進捗要約、課題作成、自然文検索など、業務進捗管理を補助するAI機能が増えています。便利ですが、AIが作った要約をそのまま経営判断に使うのではなく、元データの更新日、参照範囲、未入力の可能性、誤った推測の有無を確認します。AIを導入することより、案件のステータス、遅延理由、次のアクションが正しく入力されていることが先決です。

発注時は、AIの学習利用の有無、保存場所、第三者提供、参照できるプロジェクト、利用者ごとの権限、ログ、利用上限、停止方法を確認します。顧客情報や機密情報を含む場合は、匿名化や入力禁止項目を運用ルールにします。AI機能の有無だけで委託先を選ばず、セキュリティと業務責任の分界を説明できる会社を選びます。

よくある質問

発注前に特に相談が多い質問を、方式選び、費用、委託先選定の観点から回答します。自社の状況に当てはめ、RFPや初回相談の質問項目として利用します。

標準的なタスク管理や案件一覧で目的を達成できるなら、短期間で導入しやすいSaaSが向いています。工数・原価・請求まで深く統合する場合や、独自業務・既存基幹連携が重要な場合は、ローコード、パッケージ、受託開発を比較します。最初から方式を決めず、実データで標準機能を試し、足りない要件を具体化してから発注する方法も有効です。

標準SaaSなら初期費用0〜50万円程度、ローコードの設定・連携なら30〜300万円程度、パッケージや個別開発なら500万円から数億円以上まで幅があります。これは方式、規模、連携、移行、保守によって変わる参考レンジで、特定金額を保証するものではありません。まず必須機能と対象範囲を決め、ライセンス、導入支援、社内工数、保守を含む3年分の総額で予算を検討します。

現状の業務フロー、困っていること、対象部門と利用人数、案件数、ステータス、必要な帳票、既存システム、連携したいデータ、権限、希望時期、予算の考え方を1〜2枚にまとめます。完成した仕様書でなくても、現場で使っているExcelや帳票、画面の写真、匿名化したサンプルがあると、提案の精度が上がります。特に「何をもって進捗とするか」「導入後に何を改善したいか」を言葉にします。

候補を2〜4社程度に絞り、同じRFPと回答条件で依頼すると比較しやすくなります。SaaS標準導入、ローコード、業務パッケージ、受託SIなど、方式が異なる候補を含める場合は、価格だけでなく提案の前提と対応範囲をそろえます。見積の安さより、できないこと、追加条件、発注者側の作業、導入後支援を明示しているかを確認します。

まとめ

発注前に、解決したい課題、対象部門、必須機能、連携先、権限、納品物、検収条件、導入後の運用責任者を確認します。ここが揃っていれば、開発会社の提案と見積を同じ基準で比較できます。

全社一括の開発から始めず、代表的な業務と実データで入力時間や遅延検知を測定します。現場の声を反映しながら段階的に広げることが、費用と導入リスクを抑え、継続的な改善につながります。

業務進捗管理システムの発注・外注では、最初にSaaS、ローコード、パッケージ、フルスクラッチの違いを整理し、自社の業務課題と必要な統合レベルに合う方式を選びます。次に、業務フロー、ステータス、利用者、データ、連携、権限、非機能要件を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を創業。