Litのシステム発注は、業務範囲を決め、既存システムとの連携を確かめ、PoCと段階導入を経て進めるのが基本です。この順で進めると、Litの共通部品を生かせます。
発注形態、要件整理と開発工程、契約と費用、委託先選定は、それぞれ押さえる点が異なります。
▼全体ガイドの記事
・Litのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Litのシステムを発注・外注するときの全体像
Litで外注する場合、画面部品だけを頼むか、業務システム全体を頼むかで、必要な会社や費用、契約、期間が変わります。そのため、Litで担う範囲と、別途設計する範囲を先に分けておきます。
Litの位置づけ：画面部品の基盤
Litで作れるのは画面部品までで、業務ルールや周辺機能は別に設計します。そのうえで、Litが担う役割と技術の範囲を、発注前に確かめておきます。
- 役割：Web標準でWeb Componentsを作る軽量ライブラリです。
- 技術と言語：Custom Elements、Shadow DOM、HTMLテンプレートを使い、TypeScriptまたはJavaScriptで開発します。
ボタン、入力欄、検索フォーム、テーブルは共通部品にできます。さらに、モーダル、通知、ナビゲーションも共通部品にできます。ブラウザでは、通常のHTML要素に近い形で扱えます。
顧客・案件・受発注・在庫・勤怠の業務ルールは、Litだけでは提供されません。DB、API、認証認可、帳票は、Litの外で用意します。バッチ、監査ログ、クラウド、監視も、Litの外で用意します。
発注書やRFPには、画面、API、業務サービス、データ、インフラの各層を、誰が担当するかまで記載します。
共通部品と段階移行に向く業務
Litの共通部品は、同じ画面を複数の拠点や業務で使う場面と相性がよく、既存画面は段階的に置き換えられます。
- 利用場面：複数の社内サービスや拠点で、同じUI部品を使います。
- 共通化：部門間で検索条件、一覧表、日付入力などをそろえられます。
営業、購買、在庫、管理部門の画面では、権限表示やエラー通知も共通化できます。その結果、操作のばらつきや重複開発を抑えやすくなります。
ReactやVueを一度に廃止せず、特定の画面や部品から置き換える段階移行にも適しています。
Lit公式はShadow DOMによるDOM・スタイルのカプセル化を説明しています（出典：Lit公式「Working with Shadow DOM」、2026年8月確認）。
一方で、イベント、フォーム、ルーティングの境界は、別途設計が必要です。状態管理やE2Eテストの境界も、事前に決めておく必要があります。
Litのシステムの発注形態を選ぶ方法
発注形態は、SaaS・パッケージ、既存システム連携、スクラッチの順に比べます。まず業務の標準化と既存資産を確かめ、そのうえでLitを画面基盤に使う適性を評価します。
標準業務が中心の場合のSaaS・パッケージ比較
標準業務にどこまで合うか、導入時の負担はどれくらいかを比べて、発注方式を決めます。
- 標準業務：会計、勤怠、CRM、在庫などが中心ならSaaSやパッケージを先に比較します。
- 導入効果：導入期間と初期費用を抑えやすく、更新や運用ノウハウも使えます。
Litは、製品内部を置き換えるのではなく、SaaSのデータを集約する社内ポータルや、複数サービスに埋め込む共通ウィジェットに活用します。
標準外の独自処理を大量に加えると、カスタマイズ費用や更新対応、操作テスト、保守負担が増えます。そこで、要望を「必須」「標準機能で代替」「将来検討」に分けます。
製品に合わせる業務と、自社独自の価値として残す業務を分けます。
既存システムと共存する場合の連携開発
既存システムを残したままLitを導入する場合、まず既存の資産とAPIをどう扱うかを決めます。
- 既存資産：PHP、Java、C#、React、Vueをすべて作り直す必要はありません。
- 既存API：Litで検索・登録・承認画面を作り、データと業務ロジックは既存サービスを使えます。
古い画面を一括で刷新するより、利用頻度と課題が大きい1画面から置き換えるほうが、操作性と連携方式を確かめられます。
連携では、属性とプロパティ、CustomEventの命名、フォーム送信、エラー表示、認証状態の受け渡しを決めます。既存CSSやグローバルJavaScriptの影響も、事前に確認します。
Lit公式によると、現行ブラウザのWeb標準を使いますが、ES2021やbare module specifierなどの要件もあります。そのため、対象ブラウザとビルドツールも発注条件に含めます（出典：Lit公式「Requirements」、2026年8月確認）。
独自業務が競争力の場合のPoCとスクラッチ開発
独自の業務を既存製品に合わせると、強みそのものを手放すおそれがあります。そこで、スクラッチで進めるかどうかを、PoCで確かめてから決めます。
- スクラッチの条件：独自の承認経路、料金計算、在庫引当、製造ルール、顧客対応が強みの場合です。
- Litの役割：画面部品を再利用する基盤として使います。
業務ロジック、データモデル、権限、APIは、画面とは別のレイヤーで設計します。このため、将来フロントエンドを変えても、業務データとサービスを活用しやすくなります。
全社の機能を一度に発注するより、既存APIにつなぐ検索・登録・権限付き一覧など、1業務のPoCを依頼します。
PoCでは、実データ、エラー、権限、キーボード操作、ブラウザ、ログ出力を確かめます。また、合格条件、本番移行時の成果物、追加費用、期間は、契約前に決めておきます。
RFPと要件整理を行って見積の前提をそろえる方法
各社の想定する画面数、ユーザー数、連携範囲、テスト範囲がばらばらだと、見積を比べられません。そこで、目的、対象業務、優先順位、制約、受け入れ条件をRFPにまとめます。
発注側が仕様を完成させておく必要はありません。ただし、同じ条件で各社から提案を受けられる状態にします。
目的・対象範囲・成功指標の記載
発注の背景と、開発に含める業務範囲を、RFPで具体的に書きます。
- 発注理由：二重入力削減、月次集計短縮、承認状況の可視化、保守切れに備えた段階移行などです。
- 目的の整理：経営目的と現場課題を分けて書きます。
Lit採用そのものを目的にせず、導入後に測る業務指標を決めます。
対象範囲には、利用部門・人数、画面、データを含めます。権限、既存システム、外部APIとの連携も範囲に入れます。帳票、通知、バッチも対象に加えます。移行、教育、保守も範囲に含めます。さらに、初回リリースの対象外も明記します。
「将来対応」とだけ書くと、解釈が分かれます。そのため、今回の契約外であることと、将来追加する場合の見積方法を確認します。
業務シナリオによる通常処理と例外処理の整理
Litの画面部品と業務APIの連携を見極めるには、機能一覧に業務の流れを添えることが要ります。具体的には、各シナリオに利用者、前提データ、操作手順、期待結果、監査ログの要否を記載します。
- 通常処理：ログイン、検索、登録、承認、差し戻し、取消、再処理、CSV出力
- 例外処理：権限エラー、通信失敗、二重送信への対応
コンポーネントAPIとイベント仕様も評価の対象です。また、プロパティと属性の使い分け、イベント名やpayloadの型、親子間の状態管理について、各社の提案を求めます。
仕様を決めないまま画面を増やすと、似た部品でも使い方がばらばらになり、再利用の効果が下がります。
非機能要件と納品物の指定
利用環境や性能の条件と、受け取る成果物を具体的に指定します。
- 性能・可用性：利用者数、応答時間、稼働時間、バックアップ、復旧目標を記します。
- 利用・安全要件：ブラウザ、スマートフォン、ログ保存期間、個人情報、アクセシビリティ、脆弱性診断、障害連絡を含めます。
自社環境がLit公式の現代ブラウザ要件に合わない場合は、ポリフィルやビルド設定の費用が生じることがあります。このため、この費用の有無も事前に確かめます。
納品物には、コードのほかに、画面・API仕様書、コンポーネントカタログ、デザイン・トークン、イベント仕様を含めます。さらに、テスト仕様と結果、依存パッケージ一覧も求めます。
脆弱性対応の方針、インフラ構成、運用と移行の手順、教育資料も対象です。内製化や他社への引き継ぎに備えて、コードと設計資料を発注側が使える権利も確認します。
Litのシステム開発を発注してから稼働するまでの進め方
発注後は、要件定義、設計、開発、テスト、移行の順で進みます。そのあと、パイロット、全体展開、保守へと続きます。各工程には、終了条件と発注側のレビュー担当を決めておきます。
技術チームだけでなく、業務担当者も受け入れ判断に参加できる体制を作ります。
要件定義での業務ルールとコンポーネント境界の決定
業務ルールを画面の後から整理すると、部品の範囲が場当たり的になりがちです。要件定義の段階で、現状の業務を把握し、共通部品と画面固有機能の境界を決めます。
- 現状把握：Excel、紙、メール、既存画面から業務フロー、マスタ、権限、例外処理、連携データを整理します。
- 部品の境界：共通Web Componentと画面固有ロジックを分けます。
共通化しすぎると使いにくくなり、少なすぎると重複開発になります。境界は、利用シナリオと保守単位で判断します。
設計レビューでは、ワイヤーフレームに加えて、部品の入力値と出力イベントを確認します。さらに、エラー、読み込み中、空データ、権限不足の状態も見ておきます。
Litのリアクティブ更新は、プロパティの変更を契機に非同期でDOMを更新します（出典：Lit公式「Lifecycle」、2026年8月確認）。そのため、状態変化の共通ルールを設計書に残しておきます。
画面単体から業務シナリオまでの段階的なテスト
部品や画面が業務で使えるかは、段階を分けて検証します。
- テスト範囲：部品単体、画面結合、API、権限、業務シナリオ、移行を段階ごとに分けます。性能、セキュリティ、ブラウザ互換性は、それぞれ別に検証します。
Shadow DOM内部を直接参照するE2Eテストは壊れやすいため、利用者操作や公開イベントを中心にします。内部の検証は、コンポーネントテストで分担します。
全社展開の前に、1部門または1業務でパイロットをします。そのうえで、検索、登録、承認に加えて、通信失敗、セッション切れ、権限変更を確認します。さらに、二重送信、データ不整合、障害時の手動運用も見ておきます。
KPIには、処理時間、入力ミス、問い合わせ件数、承認滞留、旧画面との二重入力件数などを設定します。導入後の改善判断は、これらの数値をもとに行います。
運用移管：コード以外の知識の引き渡し
稼働後に自社で運用できるよう、手順と管理方法を決めます。
- 運用手順：デプロイ、ロールバック、障害切り分け、ログの扱いを決めます。依存更新、脆弱性、アカウント、バックアップ復元も含めます。
ビルド環境とnpm依存を再現できることも確認します。更新を止めるとセキュリティやブラウザ互換性のリスクが高まるため、担当者とレビュー周期を決めます。
継続保守を外注する場合は、コンポーネントカタログ、API仕様、データ辞書、既知の制約、障害履歴、問い合わせ分類を引き継ぎます。
別の会社へ移る場合に備えて、リポジトリ、クラウドアカウント、ドメイン、証明書の所有者を契約で確認します。監視、ログ、データ出力についても、所有者を決めておきます。
Litのシステム発注で契約形態を使い分けるポイント
成果物と受け入れ条件がどこまで確定しているかで、契約を選びます。調査しながら進める工程と、機能を完成して納品する工程では、適した契約もリスクの分担も異なります。
契約名に加えて、作業範囲、指揮命令、検収、変更管理、責任分界を具体的に定めます。
要件定義やPoCで候補になる準委任契約
作業しながら内容を固める工程では、準委任契約の条件を確認します。
- 候補工程：現状分析、要件定義、技術調査、PoC、アジャイル開発など、作業中に内容を確定する工程です。
稼働時間、役割、レビュー、進捗報告、会議体、成果物の扱いを記載します。ただし、成果物がある場合は、完成保証や検収の扱いも明確にします。
準委任でも、品質の責任は残ります。したがって、設計・コードレビュー、テスト、課題管理、報告期限などの品質基準を合意しておきます。
月単位の稼働契約では、予定時間を超える作業の承認方法と未消化時間の扱いも確認します。
開発成果物が確定する部分での請負契約
完成物や検収条件をあらかじめ定められる工程では、請負契約を検討します。
- 候補工程：画面仕様、API、テスト条件、納期、検収基準が確定し、完成機能を納品する工程です。
たとえば、指定ブラウザで検索・登録・承認が動くこと、権限別表示が期待結果に合うこと、テスト仕様書と結果が納品されることを定めます。
請負でも、仕様変更や前提の変化は、契約の手続きに沿って扱い、そのぶん費用も見直す対象になります。そこで、追加画面、API変更、移行データの不備、対象ブラウザの追加ごとに、申請・影響評価・承認・再見積の流れを決めます。
検収後の不具合対応期間、再委託、知的財産、OSSライセンス、契約終了時の引き継ぎも確認します。
保守契約での対応時間と対象範囲の区分
保守の対象業務と委託先が対応する範囲を明確にします。
- 対象範囲：障害、問い合わせ、監視、バックアップ、ブラウザ・依存更新、脆弱性を含みます。改善、データ修正、利用者追加は、別に分けます。
受付時間、一次回答、復旧目標、休日対応、重大度を定めます。あわせて、月の作業時間と追加単価も決めておきます。なお、軽微な画面修正と新業務ロジックの開発は、保守費に含まれない場合が多いです。
一般的な目安として、年間の保守費は初期開発費の10〜20％程度と仮置きできます。ただし、Lit専用の公定価格ではありません。
24時間監視、高可用性、複数環境、頻繁な改善、旧ブラウザ対応を含む場合は、別見積になります。見積の根拠と対象外の作業も確認します。
Litのシステム開発の費用相場と見積内訳
Litはオープンソースで、製品ライセンス料を基準にした価格表はありません。費用を構成するのは、要件定義、画面・部品設計、業務ロジック、API、DBです。さらに、認証、移行、テスト、クラウド、教育、保守も、費用の対象になります。
金額は画面数だけでなく、業務の複雑さ、連携範囲、品質要件でも変わります。
既存APIにつなぐPoCの推定レンジ：100万〜300万円
既存APIに接続するPoCの費用は、検証する範囲で変わります。
- 費用目安：共通部品や1画面を既存APIへ接続するPoCは、類似検証の推定で100万〜300万円程度です。
画面が少なくても、認証、実データ、権限、テスト、デザインシステム、対応ブラウザを含むほど、費用は増えます。なお、Lit専用の公開価格ではありません。
目安として使う場合は、画面範囲と検証条件を明記しておきます。そのうえで、成果物にはソース、部品仕様、実装方針、検証結果、残課題を含めます。
本番へ進まない場合でも、他社や社内チームが結果を使える形で残せば、調査費用を次の判断につなげられます。
小規模業務画面の費用の前提：300万〜800万円程度
小規模画面の推定費用を、公開されている規模別の相場と比べます。
- 小規模画面：検索・登録・一覧・権限管理を備える場合、類似Webアプリ推定で300万〜800万円です。
- 簡易システム：簡易な業務管理ツールや社内向け単機能システムは100万〜300万円です。
- 中規模：部門横断業務システムは500万〜1,000万円です。
- 大規模：1,000万円〜数千万円以上です（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。
小規模の下限に近づくのは、既存API、認証、クラウド、デザイン、マスタが整い、画面とテストを絞れる場合です。
新規の業務ルールや複雑な承認、基幹連携を含むと、中規模に近づきます。帳票、移行、アクセシビリティ、複数ブラウザ対応を含む場合も、中規模に寄ります。
価格だけでなく、見積に含まれる作業も確認します。
基幹連携や全社展開の想定：1,000万円以上
連携範囲や運用条件によって、全社規模の費用は大きく変わります。
- 対象範囲：複数部門のCRM、案件、在庫、受発注を統合します。会計、ERP、人事、外部サービスとも連携する場合です。
- 費用の幅：1,000万円以上から数千万円、要件によって数億円規模の可能性があります。
移行、拠点展開、監査ログ、可用性、性能が加わるため、費用は大きくなります。さらに、災害対策、教育、24時間運用が加わることもあります。Litを採用したからといって、総額が一律に下がるわけではありません。
共通部品の再利用による重複削減は、個別に見積もります。公開相場の人月単価は、60万〜200万円程度です（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。
実単価は専門性、地域、契約、納期、セキュリティ水準で変わります。そのため、役割別の工数、レビュー、管理、テスト、移行、保守を分けて確認します。
Litのシステム委託先選定と見積比較のポイント
委託先は、Litの掲載の有無だけでなく、実力を見て選びます。Web Components、TypeScript、API・認証、要件定義を一つの案件で扱えるかを確認します。さらに、テスト、アクセシビリティ、運用移管も見ておきます。
Lit専業会社の公開情報が少ない場合は、担当者やコード例を見ます。そのうえで、公開実績と提案上の対応可能性を分けて評価します。
実装・テスト・保守の証拠による確認
候補会社の技術力と運用力は、実績や成果物から確かめます。
- 技術・実装：Web Components、ReactやVueとの共存、Shadow DOMを含むE2E、TypeScript型定義を確かめます。
- 運用・品質：Storybookなどのカタログ運用とアクセシビリティ試験の方法を確認します。
Lit実績が公開されていなくても、標準技術の理解と実装を証拠で確認できれば、候補になります。一方で、Litの名称だけで業務システムや保守まで任せられるわけではありません。
営業だけでなく、要件定義、フロント・バックエンド、インフラ、QA、保守の責任者に会えるかも確認します。
提案時に、検索・登録・権限エラー・通信失敗を含む小規模PoCを依頼します。さらに、技術説明が実装とテストに反映されているかを見ます。
工程・前提・含まれない作業を並べた見積比較
同じ前提で費用を比べるため、工程と見積条件をそろえます。
- 工程別内訳：要件定義、UI、共通部品、画面、API、認証を分けます。移行、テスト、インフラ、教育、保守も、分けて示してもらいます。
- 一式見積：「Litシステム開発一式」という形では、各社を比べられません。
前提欄には、画面・部品・利用者数、既存API、データ件数を書いてもらいます。さらに、対象ブラウザ、環境数、テスト範囲も記載してもらいます。
必須要件の対応、希望要件を外した場合の減額、追加単価、納期短縮を比べます。さらに、再委託費、クラウド・保守費、データ出力・解約費用も比較します。
A社が既存APIを使い、B社がAPIも新規開発する場合、金額差は前提の違いによるものかもしれません。このため、価格差の理由を説明できる会社を評価します。
個人情報・OSS・引き継ぎの責任分界
従業員、顧客、案件の情報を扱う場合は、認証、認可、通信、ログ、バックアップ、委託先管理を確かめる必要があります。
個人情報保護委員会の指針は、委託先の安全管理措置の確認と監督を示しています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン 通則編」、2026年8月確認）。
- RFP条件：再委託、保管場所、アクセス権、事故報告、削除・返却、監査協力を記します。
- OSS管理：Litやnpm依存のライセンス、脆弱性検知・更新、影響調査、緊急パッチを確認します。
- 安全設計：Shadow DOMはDOMとスタイルを隔離しますが、認証やデータ秘匿の境界ではありません。
秘密鍵やアクセストークンはブラウザに埋め込まず、API側で認証認可します。また、CSPで読み込み元を制限し、XSS対策や未検証HTMLの挿入制限、監査ログも設計します。
業務システムでも、アクセシビリティを発注条件に含めます。WCAG 2.2は、2024年12月公開のRecommendationで、キーボード、フォーカス、フォームの名前・役割・値などを整理しています（出典：W3C「Web Content Accessibility Guidelines 2.2」、2024年12月公開・2026年8月確認）。
特に、自作のCustom Elementは、スクリーンリーダー、フォーカス移動、エラー通知、ズーム、コントラストを実機で確認します。
Litのシステム発注・外注でよくある質問
発注では、技術の採用に加えて、業務範囲、既存資産、体制、費用の前提をそろえることが大切です。相談前によく寄せられる質問を、次に挙げます。
Litに強い開発会社はどのように探せばよいですか？
Litの掲載実績に加えて、Web Components、TypeScript、Shadow DOM、APIを確認します。さらに、認証、要件定義、テスト、保守についても確かめます。
担当範囲、コード例、React・Vueとの共存、アクセシビリティ試験、納品物、脆弱性対応を尋ね、必要なら小規模PoCで評価します。
Litのシステム開発はどのくらいの費用がかかりますか？
既存APIにつなぐPoCは100万〜300万円、小規模業務画面は300万〜800万円、中規模は500万〜1,000万円程度が検討レンジです。
基幹連携、移行、複数拠点、厳格なセキュリティ、全社展開を含む場合、1,000万円以上から数千万円規模になる可能性があります。
ただし、これはLit専用の確定価格ではありません。費用は、画面・利用者数、API、認証、テスト、移行の前提で変わります。
ReactやVueを使っている会社でもLitを発注できますか？
発注は可能ですが、共存方式はPoCで検証します。属性・プロパティ・イベント、フォーム、状態管理の境界を設計します。加えて、ルーティング、スタイル、E2Eの境界も決めます。
全面刷新より、共通入力部品や特定業務から段階移行すると、リスクと費用を抑えやすくなります。
Litのライセンス費用だけを支払えば使えますか？
Litはオープンソースですが、利用料だけで業務システムが完成するわけではありません。費用は、要件、画面、API、DB、認証認可にかかります。さらに、テスト、クラウド、移行、教育、保守にも費用がかかります。
依存パッケージのライセンス、脆弱性監査、更新担当、障害対応も、発注範囲に含めて見積もります。
開発会社へ相談する前に何を準備すればよいですか？
目的、課題、対象部門、利用者数、業務フローを準備します。画面一覧、既存システム、連携先、データ件数、権限も、あわせて整理しておきます。さらに、希望時期、予算上限、必須・希望要件も伝えられるようにします。
仕様書がなくても、現場の画面、Excel、帳票、例外処理を見せれば要件整理が進みます。また、RFP作成を要件定義会社へ依頼する方法もあります。
まとめ
Litは、業務システム全体ではなく、Web Componentsを共通化する画面基盤として扱います。SaaS、既存連携、スクラッチを要件で比べ、必要なら1画面のPoCで共存やAPI連携を検証します。
テストとアクセシビリティも確かめたうえで、業務に合う方式を段階的に導入します。
発注前のRFPと見積比較の条件設定
RFPには、目的、範囲、通常・例外シナリオ、利用者、権限を記します。さらに、連携、非機能要件、納品物、保守も盛り込みます。見積は工程別に分け、対象外作業と追加単価も比べます。
契約は準委任と請負を工程で使い分け、検収、変更管理、データ、OSS、知的財産、引き継ぎを明確にします。
技術力と業務・運用力を持つ委託先の選び方
委託先を選ぶ際は、技術・運用の対応力と費用の前提をあわせて確認します。
- 委託先：Litの名称だけでなく、Web Components、TypeScript、業務要件、API、認証、テストを確認します。
- 選定材料：セキュリティ、アクセシビリティ、保守移管の証拠も確かめます。
- 費用目安：PoCは100万〜300万円程度、小規模業務画面は300万〜800万円程度です。
- 規模と見積：中規模以上は500万〜1,000万円から、基幹連携は1,000万円以上の公開相場と推定レンジを起点にし、案件の前提を加えます。
▼全体ガイドの記事
・Litのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。