SolidJSのシステム開発の発注/外注/依頼/委託方法について

SolidJSのシステムを発注・外注するなら、SolidJSを業務システム全体と考えず、画面のUI層と業務要件・API・データ基盤を分けて見積もることが成功の近道です。

SolidJSは、販売管理、在庫管理、CRM、社内ポータル、ダッシュボードなどのWeb画面に採用できるJavaScript／TypeScriptのUIライブラリです。この記事では、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用相場、委託先の選定、見積書の比較、保守まで、発注担当者が外注前に確認したいポイントを順番に解説します。

▼全体ガイドの記事
・SolidJSのシステム開発の完全ガイド

SolidJSのシステムを発注・外注する前に知る全体像

発注時に最初に整理したいのは、SolidJSの採用可否ではなく、どの業務を誰が、どのデータを使って、どの品質で運用するかです。フロントエンドの技術選定だけで見積を依頼すると、後から権限、帳票、監査ログ、データ移行、障害対応が追加され、予算と納期がずれやすくなります。

SolidJSは、ボタン、入力フォーム、一覧、検索、絞り込み、グラフなどの画面を構成する技術です。signal、store、effectを使った細粒度リアクティビティにより、在庫数だけ、承認ステータスだけ、一覧の該当行だけといった変更範囲を小さく更新できます。そのため、件数の多い一覧やリアルタイム通知など、画面の一部が頻繁に変わる業務UIでは操作感を検証する価値があります。

一方で、ログイン認証、ロール別の権限、API、データベース、帳票、CSV入出力、バッチ、外部サービス連携、バックアップは別の設計対象です。外注先には「SolidJSで作る」と伝えるだけでなく、フロントエンド、バックエンド、インフラ、運用をどこまで一括で委託するかを明示することが重要です。

SolidJSを採用するメリットは、動的な業務画面を軽快に動かしやすいことと、必要な箇所だけを細かく更新できる設計思想です。ReactやVueからの移行候補として検討でき、既存APIを活用して画面だけを段階的に置き換える方法もあります。ただし、Reactと比較すると人材、UI部品、社内ノウハウの選択肢が小さく、担当者が変わったときの引き継ぎに工夫が必要です。

SolidStartを使う場合は、CSR、SSR、ストリーミングSSR、SSGなど複数のレンダリング方式と、Vercel、AWS、Cloudflare、Netlifyなどへのデプロイ先を選べます（出典: SolidStart公式ドキュメント、2026年）。自由度が高い反面、ルーティング、メタデータ、サーバー処理、認証の配置をプロジェクトごとに決める必要があります。標準構成とドキュメントの納品を契約に入れることで、技術選定が属人化しにくくなります。

SolidJSのシステムの発注形態はどのように選びますか？

発注形態は、既存サービスの導入、パッケージの拡張、スクラッチ開発、内製チームへの人材補強を比較して決めます。結論として、独自業務が少ない場合は既存SaaSやパッケージを優先し、独自性の高い画面や複雑な業務フローにSolidJSを使うと、費用と保守のバランスを取りやすくなります。

勤怠、会計、販売管理など、法改正や制度変更の影響が大きい業務は、SaaSやパッケージを採用したほうが更新負担を抑えやすいです。標準機能で足りない社内ポータル、承認画面、ダッシュボード、データ連携画面だけをSolidJSで作り、API経由で既存サービスにつなぐ構成なら、全面刷新を避けられます。

この方式では、SaaS側と新しい画面側の責任分界を先に決めます。例えば、マスタの正本はどちらか、同期失敗を誰が検知するか、SaaSの仕様変更に誰が対応するか、利用停止時にデータをどう取り出すかをRFPへ記載します。初期費用だけでなく、連携APIの変更や追加ライセンスも比較対象にする必要があります。

独自の受発注ルール、複数倉庫の在庫引当、独自の審査フロー、既存基幹との複雑な連携など、標準製品に合わせるほうが業務を変えてしまう場合は、スクラッチ開発が適しています。SolidJSは画面層、Node.jsなどのバックエンドは業務API、PostgreSQLなどのデータベースはデータ管理というように、役割を分けて発注します。

スクラッチ開発で重要なのは、画面の見た目よりも例外処理とデータの整合性です。注文の取消、在庫不足、承認者の交代、同時編集、通信断、CSVの重複登録などを業務シナリオに含め、画面モックだけでなくAPIとエラー時の挙動まで見積対象にします。

既存のReactやVueのシステムを一度に置き換える必要はありません。まず読み取り専用のダッシュボードや検索画面をSolidJSで作り、利用状況と性能を確認してから登録・更新画面へ広げる段階移行が現実的です。APIと認証を既存システムと共有できれば、業務を止める期間を短くできます。

社内にプロジェクト管理者やバックエンド担当者がいる場合は、SolidJSの開発者だけを準委任で補強する方法もあります。逆に、要件定義、設計、開発、テスト、インフラ、導入教育まで任せたい場合は、成果物と責任を明確にした請負型の一括委託が向いています。人材補強は柔軟ですが、社内側の指示とレビューの工数が必要です。

SolidJSのシステム開発を外注する進め方

発注は、相談先を探していきなり開発を始めるのではなく、業務の棚卸し、PoC、RFP、提案比較、要件定義、設計・開発、受入テスト、運用移行の順に進めます。特にSolidJSのように採用実績と部品の選択肢を確認したい技術では、小さな検証を本契約前に置くと判断材料が増えます。

最初に、現場が使うExcel、紙、FAX、メール、既存画面、マスタ、帳票を集めます。利用者が行う作業を「入力」「検索」「承認」「出力」「例外対応」に分け、誰がどのタイミングで何を判断しているかを整理します。表記揺れや二重入力を残したまま画面だけを新しくすると、使いにくいシステムが完成するため、アナログ業務の改善も同時に検討します。

発注側が決めるべき資料には、対象業務、利用者数、拠点数、データ量、連携先、法令・社内規程、希望時期があります。利用者数は登録アカウント数だけでなく、同時利用者数とピーク時間帯も分けて示します。これがあると、委託先は性能、インフラ、ライセンスを過不足なく見積もりやすくなります。

PoCでは、10〜20件程度の実データに近いサンプルを使い、検索、並べ替え、インライン編集、承認、権限エラー、通信失敗を確認します。件数の少ないデモ画面だけでは、実際の操作感やデータの扱いを判断できません。ReactやVueの既存画面がある場合は、移行したい画面を1つ選び、再利用できるAPIと作り直す必要がある部品を分けます。

PoCの成果物には、動く画面だけでなく、採用理由、未解決の課題、想定する本番構成、テスト結果、正式開発での追加工数を含めます。PoCを無償の試作品として扱うと、評価後に成果物の権利や保守の責任が曖昧になります。目的、期間、納品範囲、正式発注時の扱いを短い契約書でもよいので定めます。

PoCの結果をもとに、要件定義で業務要件と非機能要件を確定します。基本設計では画面、権限、API、データ、外部連携の境界を決め、詳細設計で状態管理、エラー表示、ログ、テストケースへ落とし込みます。開発中に要望が追加された場合は、変更理由、影響範囲、追加費用、納期を記録してから着手します。

テストは、画面が表示されることだけでなく、権限のない利用者が操作できないこと、二重送信が起きないこと、通信失敗から復旧できること、監査ログが残ることを確認します。リリース前には利用部門の代表者が業務シナリオで受入テストを行い、データ移行と教育を含めた切替リハーサルを実施します。

RFP・要件整理で発注前に決めること

RFPは、技術者向けの機能一覧だけではなく、発注の背景と判断基準を委託先へ共有する文書です。SolidJSを採用することを必須条件にする場合も、性能、操作性、保守性のどの課題を解決したいのかを併記します。技術名だけで評価すると、目的に合わない高コストな構成や、実績を確認できない提案を選ぶ可能性があります。

RFPの業務欄には、対象部署、業務フロー、現行の困りごと、改善したい指標を記載します。機能欄には、ログイン、検索、登録、承認、通知、帳票、CSV、外部APIなどを、利用者と操作の流れに沿って記載します。非機能欄には、同時利用者数、目標応答時間、稼働時間、バックアップ、障害復旧、監視、アクセシビリティ、スマートフォン対応を含めます。

納品物は、ソースコード、設計書、API仕様書、テスト仕様書と結果、CI/CD設定、インフラ構成図、操作マニュアル、OSSライセンス一覧、データ移行手順、引き継ぎ記録まで明記します。SolidStartのルーターやメタデータ、認証方式など、会社の標準に任せる部分も、採用するライブラリ名と更新方針を確認します。

「使いやすい」「高速」「安全」といった表現だけでは、見積比較も検収もできません。例えば、検索結果を何秒以内に表示するか、CSVを何件まで取り込むか、承認操作でどのログを残すか、障害時に何分以内に通知するかのように、可能な範囲で測定条件を決めます。数値を決めにくい場合は、代表的な業務シナリオと合格・不合格の例を作ります。

機能は必須、できれば、将来検討の3段階に分けます。納期が厳しい場合は、ログイン、検索、登録、承認など業務の中心を最初のリリースに含め、分析画面や細かな自動化は第2段階へ回します。優先順位を付けずに全機能を一律で求めると、見積は高くなり、重要な機能の検証が遅れます。

顧客情報、従業員情報、取引情報を扱う場合は、個人情報保護委員会のガイドラインを確認し、アクセス権限、暗号化、操作ログ、バックアップ、委託先の監督、漏えい時の報告と通知手順を要件に入れます。個人情報保護委員会の通則編では、従業者への教育や技術的安全管理措置などが示されているため、画面のログインだけで安全要件を満たしたと判断しないことが大切です（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。

Webアプリケーションの検証項目は、OWASP Top 10:2025をリスクの共通言語として使い、実装・設計レビューやテストの詳細はOWASP ASVSへ落とし込むと整理しやすくなります。例えば、認証、認可、入力値検証、セッション、ログ、依存ライブラリの更新、秘密情報の管理を、誰がどの証跡で確認するかをRFPと契約書へ記載します（出典: OWASP Top 10:2025、OWASP ASVS、2025年以降の公開資料）。

SolidJSのシステム外注で契約形態をどう選びますか？

契約形態は、仕様の確定度、成果物の明確さ、発注側が担える管理工数によって選びます。要件と検収基準が固まっている範囲は請負契約、要件を一緒に探索したり人材を補強したりする範囲は準委任契約が候補です。名称だけでなく、責任、指揮命令、変更手続き、検収、保守の境界を文書化します。

請負は、合意した成果物を完成させ、検収を受ける形に向いています。画面一覧、API仕様、テスト条件、納品物が決まっていれば、予算を管理しやすい一方、発注後の仕様変更は追加見積になりやすいです。準委任は、月ごとの稼働時間や担当者の役割を定め、要件整理や改善を進める形に向いていますが、成果物の完成を当然の前提にせず、レビューと意思決定を発注側が担います。

実務では、要件定義を準委任、開発と検収対象の機能を請負、リリース後の改善を準委任に分ける方式もあります。契約を分ける場合は、設計書やソースコードの権利、情報管理、再委託、障害時の責任、未消化の作業時間、契約終了時の引き継ぎを契約間で矛盾しないようにします。

納品物は「ソースコード一式」の一言で済ませず、リポジトリ、ブランチ、ビルド手順、環境変数の一覧、デプロイ手順、依存ライブラリ、テスト結果、インフラ設定、運用マニュアルを列挙します。ソースコードの著作権、利用許諾、OSSのライセンス、第三者素材の扱いも、法務担当者と確認します。

再委託がある場合は、どの会社がどの工程を担当するか、個人情報を扱うか、発注先が再委託先を監督するかを確認します。海外委託では、時差、言語、準拠法、データの保管地域、緊急時の連絡方法が追加の論点になります。SolidJSの公開実績があっても、日本語で業務要件を定義できる体制や国内の契約・保守に対応できるとは限らないため、別々に確認します。

本番稼働後は、問い合わせ対応、障害一次切り分け、セキュリティパッチ、SolidJSや依存ライブラリの更新、ブラウザ対応、監視、バックアップ確認、軽微な改修が発生します。初期開発費だけで予算を判断せず、月額保守、クラウド、監視、ライセンス、データ保管、改修の時間単価を分けて見積もります。

業務システム全般の目安では、保守費を初期開発費の年15〜20％程度と整理する場合がありますが、これはSolidJS固有の料金ではなく、機能範囲、SLA、対応時間、体制によって変わる参考レンジです（出典: 業務システム全般のQ&A、2026年時点の一般的な整理）。重大障害の定義、受付時間、一次回答、復旧目標、計画メンテナンス、対象外作業を契約書へ記載します。

SolidJSのシステム発注費用相場と見積もりの内訳

SolidJS専用の国内相場を示す公的な統計はほとんどないため、以下は2026年時点で公開されている一般的な業務システムの相場と、SolidJS開発サービスの公開価格を組み合わせた推定レンジです。正式見積ではなく、RFPを作る際の予算仮説として使い、要件定義後に更新してください。費用の中心はフレームワーク名より、人件費、画面数、業務ルール、連携、移行、テスト、保守です。

検証や小規模CRUDで、5〜10画面、ログイン、検索、登録、簡易APIを含む場合は、100万〜300万円、期間は1〜3か月程度が一つの目安です。部門向けシステムで、10〜30画面、権限、承認、CSV、帳票、監査ログまで含める場合は、300万〜800万円、期間は3〜6か月程度が目安です。これらは、2026年時点の小規模・中規模の業務システム相場として公開されているレンジをもとにした整理です（出典: イー・ジーシステム、SIA、FUNBREWの2026年公開情報）。

複数部門やERP、CRM、WMSとの連携、データ移行、リアルタイム更新、SSRを含む場合は、800万〜2,000万円以上、6〜12か月以上になる可能性があります。販売・在庫・会計などの基幹刷新、大量データのクレンジング、並行稼働、厳しい監査要件まで含めると、1,500万〜5,000万円以上、12〜24か月以上のレンジも想定します。特定の金額を断定せず、業務範囲と前提条件とともに提示することが適切です。

海外の公開価格として、ilovesolutionはSolid.jsのWebサイトを9,995ユーロから、Webアプリを14,995ユーロから、Node.jsとデータベースを含むフルスタックを19,995ユーロから掲載しています（出典: ilovesolutionの公開プラン、確認時点）。海外業者の掲載価格であり、日本語の要件定義、税、国内法対応、移行、保守、為替を含む比較見積ではないため、価格の安さだけで国内発注と比較しないようにします。

見積書では、要件定義、基本設計、詳細設計、フロントエンド実装、バックエンド実装、インフラ、テスト、データ移行、教育、リリース、保守を分けて確認します。一般的な工程配分の目安は、要件定義10〜15％、基本設計15〜20％、実装30〜40％、結合・総合テスト15〜20％、移行・導入5〜10％です（出典: 業務システム全般のQ&A）。会社ごとの工数配分を比較する材料になりますが、業務の複雑さで変わるため、割合だけで優劣を決めません。

人月単価は60万〜120万円程度を目安として整理されることがありますが、経験、地域、役割、契約形態、品質保証、マネジメントを含むかで変わります（出典: 業務システム全般のQ&A、2026年時点の一般的な整理）。安い単価でも必要な工数が多ければ総額は上がり、高い単価でも要件整理やテストを含めて手戻りを抑えられる場合があります。単価ではなく、誰が何時間、どの成果物を担当するかまで質問します。

費用を下げるために要件定義やテストを削ると、後半の仕様変更、障害、再開発で高くなる可能性があります。費用を管理するには、必須機能を絞り、既存APIやSaaSを再利用し、画面の共通部品を設計し、移行対象データを段階化します。PoCで早く不確実性を減らすことも、発注後の大きな手戻りを抑える方法です。

見積依頼の段階では、初期開発費、PoC費用、クラウド費、ライセンス、保守費、追加改修の単価、データ移行費、研修費を別欄にします。将来機能を本体の見積に混ぜず、オプションとして出してもらうと、現在必要な投資と将来の拡張余地を分けて判断できます。

SolidJSの委託先選定と見積比較のポイント

委託先は、SolidJSの知識だけでなく、業務理解、要件定義、セキュリティ、テスト、保守まで確認して選びます。公開サイトにSolidJSの開発サービスがあっても、日本の業務システムを同じ品質で担当できるとは限りません。実績証跡と担当予定者を確認し、RFPへの回答の具体性と見積の透明性を比べます。

確認したい実績は、SolidJSまたはSolidStartを使った本番稼働URL、画面や構成の説明、担当範囲、利用者数、運用期間、障害対応、保守体制です。秘密保持のためURLを見せられない場合でも、匿名化した画面、コードレビュー、アーキテクチャ図、テスト計画で説明できるかを確認します。営業資料だけでなく、実際に開発を担当するエンジニアと要件定義者に質問します。

SolidJSは人材市場や部品の選択肢がReactより小さい可能性があるため、1人の専門家に依存しない体制を確認します。コードレビューの担当者、休暇や退職時の代替要員、ReactやVueとの併用経験、ライブラリ更新の判断者、引き継ぎ手順を聞きます。Solid 2.0 betaの動きも公開されているため、検証版を本番へ急いで入れず、採用バージョンと更新計画を提案書に書いてもらいます（出典: Solid公式リリース、2026年確認）。

複数社へ依頼するときは、画面数、権限ロール、連携先、データ移行件数、同時利用者数、テスト範囲、納品物、保守の期間を同じ条件で渡します。一社だけ要件定義を含み、別の一社は開発だけを含む場合、総額だけでは比較できません。含むもの、含まないもの、発注側の作業、前提が崩れたときの追加費用を並べます。

見積書の比較では、第一に業務要件の理解、第二に構成と品質、第三に価格、第四に保守と引き継ぎの順で評価すると判断しやすいです。極端に安い提案では、要件定義、テスト、セキュリティ、移行、教育、管理工数が抜けていないか確認します。逆に高い提案でも、経験のある担当者、手厚いテスト、運用設計が含まれるなら、その差額に理由があるかを質問します。

ヒアリングでは、要求をそのまま受けるだけでなく、採用しないほうがよいケースや代替案を説明できるかを見ます。SolidJSでなくても解決できる要件、SolidJSを使うと追加設計が必要になる要件、SaaSと組み合わせるほうがよい範囲を整理できる会社は、技術名に引っ張られずに提案できます。

さらに、障害が起きたときの検知、連絡、切り戻し、データ復旧を誰が行うか、プロジェクトが遅れたときの報告頻度、担当者が交代したときの引き継ぎ、契約終了時のソースコード返却を確認します。発注前に聞きにくい内容ほど、運用開始後のトラブルを左右します。

SolidJSのシステム発注・外注で失敗しやすいリスクと対策

発注の失敗は、SolidJSという技術だけが原因になるわけではありません。業務の前提を決めないまま開発を始めること、フレームワークの速度を成果と誤解すること、実績と保守体制を確認しないことが主な原因です。次のリスクを契約とプロジェクト運営に組み込み、早い段階で検知します。

「仮想DOMを使わないから速い」という説明だけでは、業務改善の成果にはなりません。実データで検索時間や入力待ちを測り、現場の作業時間、入力ミス、問い合わせ件数、承認の滞留などの指標と結び付けます。性能が課題でない画面までSolidJSへ置き換える必要はなく、技術を採用しない選択肢も同じRFPで比較します。

また、検証版や実験的なライブラリを本番の中核へ入れる場合は、更新停止や互換性のリスクを評価します。利用するSolidJS、SolidStart、UI部品、テストツールのバージョンを固定し、脆弱性対応とメジャーアップデートの責任者を決めます。コードの読み方、状態管理、フォルダ構成を文書化し、将来の担当者が保守できるようにします。

発注側と委託先の間で、マスタを用意する人、業務ルールを決める人、受入テストを行う人、データ移行を承認する人が曖昧だと、開発が止まります。RACIのような役割表を作り、各成果物に承認者と期限を設定します。発注側の回答が遅れた場合の納期扱いも、プロジェクト計画と契約書に含めます。

要望が出たら、すぐに画面へ追加せず、目的、利用者、頻度、業務上の優先度、データ影響、テスト影響を確認します。変更管理表に記録して、現行機能との整合性、追加工数、リリース時期を合意してから着手します。小さな変更を積み重ねて予算を超える事態を防げます。

委託先を替えられない状態を避けるには、ソースコードやクラウド契約を発注側が管理できる形にし、リポジトリ、ドメイン、アカウント、CI/CD、監視、バックアップの所有者を決めます。特定担当者しか分からない設計を避け、月次のレビュー、運用手順、障害履歴、ライブラリ一覧を納品・更新してもらいます。

契約終了時には、ソースコードだけでなく、データベースのバックアップ、環境構築手順、秘密情報の受け渡し方法、未解決の障害、利用中のOSS、次の会社への説明会まで引き継ぐ項目に含めます。引き継ぎを最後に追加するのではなく、開発中から月1回のドキュメント確認を行うと、交代時の負担を下げられます。

よくある質問

SolidJSのシステムを発注するときに、よく寄せられる疑問をまとめます。技術選定だけでなく、既存システムとの関係、費用、外注先の評価方法まで確認してから相談すると、初回打ち合わせが具体的になります。

SolidJSだけで業務システム全体が完成するわけではありません。SolidJSは主に画面のUI層であり、API、認証、権限、データベース、帳票、バッチ、インフラ、監視を別に設計します。発注時は、画面開発だけか、バックエンドや運用まで含む一括委託かを見積書で確認してください。

SolidJSを採用しただけで、総額が自動的に安くなるとは限りません。画面の性能や再利用性が改善しても、認証、業務ルール、外部連携、データ移行、テスト、保守の費用は別に発生します。100万〜300万円、300万〜800万円、800万〜2,000万円以上というレンジは業務範囲を含む推定であり、SolidJSの料金表ではありません。

SolidJSまたはSolidStartの本番実績、担当予定者、業務システムの要件定義経験、認証・権限・監査ログ・APIセキュリティの設計力、テストと保守体制を確認します。海外会社や人材補強会社を含める場合は、日本語での契約、時差、国内法への対応、引き継ぎ方法も比較します。公開実績があっても、案件の規模や担当範囲が自社と合うかを質問することが大切です。

まとめ

SolidJSのシステムを発注・外注するときは、SolidJSを業務システム全体ではなくUI層として位置付け、業務要件、API、データ、権限、移行、セキュリティ、保守まで含めて委託範囲を決めます。既存SaaSやパッケージで足りない部分だけを補う方法、独自業務をスクラッチで作る方法、段階移行や人材補強を使う方法を比較し、自社の体制に合う発注形態を選びます。

発注前には、(1)現行業務と資料を棚卸しすること、(2)実データに近いPoCで操作感と移行リスクを確認すること、(3)RFPに機能・非機能・納品物・受入基準を書くこと、(4)請負と準委任を工程ごとに使い分けること、(5)同じ前提条件で複数社の見積と保守体制を比較することを確認します。費用は、小規模CRUDで100万〜300万円、部門向けで300万〜800万円、複数連携で800万〜2,000万円以上という推定レンジを起点にし、要件定義後に更新します。

最初の相談では、「SolidJSで作りたい」という希望に加えて、解決したい業務課題、利用者、画面数、データ、連携先、希望時期、予算レンジ、保守の考え方を共有します。委託先には、SolidJSを採用する場合と採用しない場合の差、PoCの範囲、想定リスク、納品物、担当体制を提案してもらいます。技術の新しさではなく、現場が使い続けられ、将来も引き継げる業務基盤になるかを基準に発注先を選ぶことが、SolidJSのシステム開発を成功させるポイントです。

▼全体ガイドの記事
・SolidJSのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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