WordPressのシステム発注は、業務とデータの範囲を決め、RFPで要件をそろえてから、工程ごとに契約と委託先を選ぶ流れで進めます。公開後も運用しやすい基盤につながります。
発注形態から委託先の選び方まで、各段階で決めることを順に説明します。
▼全体ガイドの記事
・WordPressのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WordPressのシステムを発注する前に押さえる全体像
WordPressは、PHPとデータベースを基盤にしたオープンソースのCMSです。投稿や固定ページのほか、会員サイトやポータル、ECにも使えます。採用サイトや予約・問い合わせ受付の用途もあります。
複数ブランドの情報管理にも使えますが、導入しただけで業務システムになるわけではありません。そのため、発注では管理するデータと業務ルールを設計する必要があります。
WordPressのシステムの定義と構成
WordPressのシステムは、CMSの機能と周辺サービスを組み合わせて構成します。
- システムの構成：CMS機能にテーマやプラグイン、独自機能を加えます。さらに、サーバーやメール、CDN、WAF、外部APIと組み合わせます。
- 標準機能：コンテンツ管理や検索などの基本機能を最初から備えます。
投稿・固定ページやカスタム投稿タイプ、カテゴリー・タグ、メディア管理は、標準で扱えます。下書きや予約公開、リビジョン、ユーザーとロール別の権限も使えます。さらに、検索やフォーム、アクセス解析連携も利用できます。
発注時は、WordPress内の情報を正データとするか、顧客・商品・在庫・注文の情報をCRMや基幹システムで管理するかを分けておきます。
複雑な受発注や在庫引当を投稿機能で再現しようとすると、プラグイン同士の依存が増えます。そうなると、将来の更新やセキュリティ対応が難しくなる場合があります。そのため、CMSに向く業務と専用システムに任せる業務は、先に切り分けておきます。
ホームページ制作とシステム開発の違い
制作範囲は、サイトの基本機能と業務システム機能に分けると比べやすくなります。
- ホームページ制作：ページ構成、デザイン、問い合わせフォーム、スマートフォン対応、基本的な更新機能が中心です。
- システム開発：部署別権限、承認フロー、会員認証、複雑な検索、既存データ移行も対象です。
CRM・予約・在庫・決済との連携や、監査ログ、性能、障害復旧も検討対象になります。見積書に「WordPress構築一式」とあるなら、どこまでが含まれるかを確認しておきます。
原稿移行やAPI連携が別料金になっていると、最終的な予算は大きく変わります。ステージング環境、テスト、運用マニュアル、公開後の保守も、料金が別かどうかを見積書で確かめます。
依頼内容は、「誰のどの作業を何分短縮するか」という業務の言葉に置き換えておきます。「見栄えのよいサイト」のような表現だと、会社によって受け止め方が変わります。
発注形態の選び方
発注形態は、要件がどこまで決まっているか、自社に担当者がいるか、どれくらい急ぐか、公開後に誰が運用するかで選びます。既成テーマは短期間で始めやすい一方、独自開発は業務に合わせて組みやすい方法です。まずは、標準機能で足りる範囲と追加開発が必要な範囲を分けておくと、技術名で先に決めずに済みます。
既成テーマ・テンプレートでの発注
既成テーマで足りるかは、条件と対象範囲に当てはめて見ます。
- 向いている条件：ページ数が少なく、自由度より費用と公開スピードを優先したい場合です。
- 対象例：会社案内、サービス紹介、基本的なブログ、問い合わせフォームなら、標準機能で範囲を絞れます。
発注先には、テーマのライセンスやカスタマイズの範囲、スマートフォン対応、更新時の互換性を確かめてもらいます。
既成テーマは、安さだけで選ぶと将来の負担になることがあります。更新の停止や不要な機能、独自仕様の上書きなどが、その例です。表示速度やプラグインの競合も、あわせて確かめておきます。
納品時には、テーマ本体と子テーマの関係、変更箇所、更新手順を説明してもらいます。そうすると、制作会社が変わっても運用を続けられます。
独自テーマ・プラグインの組み合わせ
独自テーマが必要かどうかは、追加する業務機能で見極めます。
- 必要な機能：独自デザイン、複数投稿タイプ、部署別入力項目、承認、予約公開、会員向け表示制御です。
- 向いている企業：既存管理画面を拡張し、編集担当者が日常的に更新する企業です。
プラグインを足すだけで要件を満たそうとすると、開発会社が変わったときに構成を理解しにくくなります。
プラグインごとに、採用理由や設定値、ライセンス、データの保存場所を一覧にします。あわせて、更新担当や代替手段、独自開発と既製プラグインの境界も書いておきます。
プラグインの数を減らすこと自体が目的ではありません。大切なのは、責任を持って更新できる構成になっているかどうかです。
API連携・ヘッドレス・専用システムとの組み合わせ
配信先の数と、業務データをどこで管理するかから、構成を検討します。
- 配信先：Webに加えて、アプリやサイネージ、店舗端末へ配信する場合に候補になります。REST APIやGraphQL APIを使います。
- データの役割：CRM、予約、在庫、決済、認証は外部を正とし、WordPressは公開コンテンツと表示を担います。
自由度が高い一方で、設計する範囲も広がります。フロントエンドやAPI、認証、キャッシュは、それぞれ別に設計します。プレビューや検索、監視、障害時の表示も、同じように設計の対象になります。
複数チャネル配信や高い負荷が課題でないなら、通常構成やハイブリッド構成の方が運用しやすい場合もあります。
提案の段階で、ヘッドレスで解決する課題と、それに伴って増える運用負担を並べて説明してもらいます。
RFPと要件整理の進め方
RFPは、要望を伝えるための資料であると同時に、同じ前提で提案と見積を比べるための文書です。画面デザインの指定が中心だと、APIや権限、移行の範囲が会社ごとに変わり、運用や保守の扱いも揃いにくくなります。
目的と対象範囲、データ、利用者を一つの資料にまとめます。非機能要件や成果物、見積条件も、同じ資料に入れます。
目的・対象範囲・成果物の記載
RFPには、業務上の目的と対象範囲、納品後に必要な成果物を記載します。
- 目的と範囲：「各拠点が本部承認を受けて予約公開する」「問い合わせをCRMへ二重入力せず登録する」などの成果と、対象外の機能を記載します。
- 成果物：要件定義書や画面設計、データ定義、サイトマップを挙げます。テーマ・プラグイン一覧やAPI仕様書、ソースコード、インフラ設定も含めます。
- 運用資料：テスト仕様書や移行結果、操作マニュアル、運用手順書。
対象サイトや部署、データも具体化します。納品形式や検収基準、修正回数、教育時間まで書いておくと、納品後に必要な作業を見積から漏らしにくくなります。
発注の目的には、記事公開までの社内作業を短くすることも挙げられます。
データ・利用者・権限・連携先の洗い出し
データの種類と管理条件をそろえると、必要な権限や連携が具体的に見えてきます。
- 対象データ：投稿や固定ページ、商品、店舗、会員を洗い出します。予約や注文、画像、問い合わせも、対象に入れます。
- 管理条件：登録者と承認者、公開範囲、更新頻度を確かめます。保持期間や履歴の要否、削除方法も決めておきます。
部署や拠点、代理店、管理者によって見える情報や操作範囲が違うなら、ロールと権限を画面とデータの両方で定めます。
連携先は、CRMや基幹システム、在庫、決済を含めて洗い出します。予約やメール配信、検索、アクセス解析、認証基盤も対象になります。
- 連携条件：正となるシステム、連携頻度、失敗時の再送、重複防止、個人情報の保存場所を決めます。
- 仕様が不明な場合：全体開発に無理に含めず、調査や技術検証を先に発注する方法もあります。
非機能要件と公開後の運用の記載
公開後も安定して運用するには、性能や復旧の条件を項目ごとに定めておく必要があります。
- 性能・復旧：想定アクセス数、表示速度、API応答時間、可用性、バックアップ頻度、復旧目標を定めます。
- 監視・障害対応：ログ保存期間、監視、脆弱性対応、障害連絡を決めます。アクセス想定は、キャンペーン時の倍率などで示します。
障害を何分以内に検知するかも、具体的に決めておきます。決めきれない項目は、候補と前提条件を提案してもらいます。
本番、ステージング、開発の各環境について、更新の承認者を決めておきます。そのうえで、WordPress本体やPHP、テーマ、プラグインの更新担当も定めます。
- 復旧・窓口：バックアップからの復元テストと問い合わせ窓口を決めます。
- 契約名義：サーバー、ドメイン、SSL、CDN、WAF、監視の名義を確認します。
発注先を変える可能性があるなら、管理者アカウントと契約を自社名義にしておくことが、引き継ぎの条件です。
WordPressのシステム開発の進め方
開発は、調査から始まり、設計と実装へと進みます。一括で委託する場合でも、工程ごとに成果物と発注側の確認事項を分けておくと、進捗と品質を判断しやすくなります。
- 現行サイトと業務の調査、要件定義
- サイト構造やデータ、権限、連携の設計
- 実装とデータ移行、テストの実施
- 受入確認後の公開と、保守への移行
現状調査と要件定義
要件定義の前に、現行環境と実際の業務を調査します。
- サイトと環境：ページや投稿、画像、ユーザーを調べます。プラグイン、PHP、サーバー、アクセス、フォーム、外部連携も、現行の環境として確認します。
- 業務の聞き取り：例外処理、承認が止まる場面、手作業、障害時の対応を確認します。
- 効果の把握：利用者が気づいていない二重入力や確認作業も洗い出します。
調査が済んだら、要件の優先順位と導入範囲を決めます。
- 優先順位：要件をMust、Should、将来候補に分けます。会員、EC、予約、在庫、アプリを一度に作る必要があるかを見極めます。
- 段階導入：効果とリスクを確認しやすい機能からMVP（Minimum Viable Product）として始める方法もあります。
連携やデータ品質に不確かな点があるなら、4〜8週間程度のPoCや先行調査に切り出せます。その成果は、本開発の見積条件に反映します。
設計・実装・データ移行
実装の前に、画面やデータ、権限、連携の仕様を設計しておきます。
- サイトと業務：サイト構造、投稿タイプ、カスタムフィールド、分類を定義します。権限、入力画面、承認フローも定めます。
- 機能と公開：検索やURL、リダイレクト、フォーム、API、エラー処理を確認します。編集画面と公開状態も、確かめておきます。
- 独自プラグイン：保存データの形式と将来のバージョンアップ方針を設計書に残します。
移行対象は、記事や固定ページ、画像のほか、カテゴリー・タグ、ユーザー、URL、メタ情報です。移行の前後で、件数と内容を照合します。
古いHTMLをそのまま取り込むか、文章を整理して新しい投稿タイプへ移すかによって、工数は変わります。
本番の前に移行リハーサルを行い、文字化けや画像の欠落、リンク切れ、公開日時、検索流入への影響を確認します。
テスト・リリース・保守への移行
受入前に、機能と運用環境の両方をテストします。
- 機能テスト：権限や承認、予約公開、フォーム、メール、検索の動作を確認します。API連携とデータ移行も対象です。
- 環境テスト：バックアップ復元、スマートフォン表示、同時アクセス、更新後の互換性を見ます。
- 受入テスト：発注側がシナリオを用意し、現場担当者が業務を行えるかを試します。
合格条件が曖昧なまま公開日を優先すると、不具合や追加費用が起きやすくなります。
WordPress公式のバージョン一覧では、7.0が2026年5月20日に公開されています（出典：WordPress.org「WordPress Versions」、2026年7月更新）。
IPAは2026年7月、WordPress 6.9.0〜6.9.4と7.0.0〜7.0.1に関係するwp2shellについて注意喚起しました。
修正版6.9.5、7.0.2などへの更新を推奨しています（出典：IPA「WordPressの脆弱性対策について」、2026年7月22日）。
公開後は、自動更新に任せきりにせず、ステージングで検証してから更新します。失敗したときに戻す手順も、保守契約に含めておきます。
契約形態と委託範囲の決め方
契約形態では、支払いのほかに、成果物や完成責任、変更、検収、権利、障害対応を定めておく必要があります。企画や調査は要件が変わりやすい一方、実装は仕様が固まってから進みます。そのため、工程ごとに条件を検討します。
準委任契約と請負契約の使い分け
調査や検証のような進め方と、完成物の検収では、適する契約が異なります。
- 準委任契約：現状調査、企画、要件定義、技術検証、アドバイザリー、運用支援などの業務遂行に向きます。
- 請負契約：合意した成果物を完成させ、検収を受ける工程向けです。
準委任契約では、作業時間に加えて、調査項目や会議、成果資料、報告方法、対応時間を定めておきます。完成結果までは保証しないこともあるため、業務完了の条件も明記します。
請負契約は、仕様が固まったテーマ実装やプラグイン開発、データ移行、テストなどで使いやすい形です。ただし、要件が変われば、追加費用や納期の変更が生じます。
契約の名前だけに頼らず、変更申請や影響調査、再見積、検収、瑕疵や不具合への対応を確かめます。
ソースコード・権利・引き継ぎ条件
開発資産の所有権と、契約終了時の引き継ぎは、事前に決めておきます。
- 所有者と引き渡し：コードやテーマ、独自プラグイン、設定を契約で定めます。画像やデータ、サーバー、ドメイン、CI/CD、監視設定も、対象に含めます。
- 第三者ライセンス：プラグインやフォントは譲渡できない場合があり、利用許諾、更新費、終了後の利用可否を確認します。
- 内製化への備え：将来内製化するなら、ソースコードに設計書と運用手順も加えます。
著作権を譲り渡す場合は、対象や地域、改変、再利用、第三者素材の扱いを定めます。第27条・第28条の権利を含めるときは、契約に明記します（出典：文化庁「著作権契約マニュアル」）。
契約が終わるときに備えて、データの返却やアカウントの移管、削除の確認、引き継ぎ期間も先に定めておきます。
WordPressのシステム開発の費用相場
費用は、既成テーマか独自開発か、ページ数によって変わります。そのほか、原稿や画像の準備でも費用は変わります。会員・EC・予約の有無や、外部連携、移行量の多さも、費用を左右します。
セキュリティや保守の範囲も、費用に影響します。ただし、公開料金は各社の前提に基づく目安で、業務システム型の案件にそのまま当てはめることはできません。
費用の見方では、リサーチノートで確認した公開価格と、類似する業務システムの相場を分けて見ます。
公開料金から見る制作・構築費の目安
公開料金は、制作方式や期間の条件と合わせて比べます。
- テンプレート導入：10万〜30万円程度からの公開プランがあり、リラクスは15万〜30万円程度です。
- 実装代行：リラクスはデザイン済みデータの実装を10万〜30万円程度で公開しています。
- オーダーメイド：リラクスは30万〜150万円程度、期間は1〜3か月です。
- メディアマックスジャパン：5ページ基本の税込プランはシンプル49万8,000円、ベーシック79万8,000円、パーフェクト149万8,000円です。
テンプレートと実装代行の期間は2週間〜1か月です（出典：株式会社リラクス公開料金、2026年確認）。メディアマックスジャパンのオーダーメイドは見積もりです（出典：株式会社メディアマックスジャパン「WordPressのサイト制作費用・料金プラン」、2026年確認）。
ページ数やデザイン、フォーム、更新機能、素材準備の条件で、価格帯は変わります。そのため、金額の数字だけで高い・安いを判断しないようにします。
会員・EC・API連携を含むシステム開発の目安
会員や予約、EC、外部APIを含むと、一般的なサイト制作より費用は大きくなります。SSOや承認、監査ログ、既存データ移行、複数の投稿タイプも、費用を押し上げる要素です。
- EC：WooCommerceなどは80万〜300万円程度です。
- 外部連携：API・会員・業務連携は300万〜1,000万円程度です。
- 大規模構成：マルチサイト・高トラフィックは1,000万円〜5,000万円以上です。
- 人件費：業務システムに近い案件では大部分を占め、一般的な整理で60〜80％です。
上記は、要件が近い案件の目安または推定であり、特定の案件の確定金額ではありません。PMは月90万〜150万円、設計SEは月65万〜110万円、プログラマーは月50万〜90万円程度が目安です（出典：リサーチノート内の業務システム全般Q&A、2026年）。この単価を、そのままWordPress制作の料金に当てはめず、見積書で各役割の必要日数を確かめます。
保守・サーバー・ライセンスの継続費
運用にかかる継続費は、初期費用とは分けて、項目ごとに確かめます。
- 継続費：サーバーやドメイン、SSL、CDN、WAFの費用が発生します。バックアップや監視、メール配信、決済、会員認証も、継続して発生する項目です。
- 保守など：テーマやプラグインのライセンス、更新代行、障害対応、記事運用代行が対象です。
- 保守費の目安：初期開発費の年15〜25％、または月1万〜8万円程度からです。
24時間監視や緊急対応を含む場合は、別のレンジになります。また、初年度だけでなく、3〜5年の総保有コストで計算しておくと比べやすくなります。
- 保守範囲：更新回数や軽微修正、脆弱性対応、バックアップ世代数、復元テストを確認します。
- 対応条件：問い合わせ時間、障害時の目標、バージョンアップ検証の扱い。
- 長期費用：更新や引き継ぎが別料金なら、長期では割高になる場合があります。
委託先の選び方と見積比較のポイント
委託先は、知名度や金額だけでなく、課題に近い実績と要件定義の力で比べます。WordPress以外の技術や保守体制、引き継ぎやすさも、判断の材料になります。
発注前には、2〜3社へ同じRFPを渡し、提案や前提、対象外、担当体制、質問の質をそろえて見比べます。
同規模・同業務の実績と担当者
委託先が合うかどうかは、近い実績と契約後の担当体制で見ます。制作件数の多さだけで判断するのは避けます。
- 課題に近い実績：会員や予約、EC、複数拠点、移行、外部APIに近い実績があるかどうか。承認フローの経験も含みます。
- 実績の説明：公開例が少ない場合は、構成や運用、障害対応、移行検証を聞きます。
- 契約後の担当：提案担当者が、要件定義やレビューにも関わるかどうか。
- 担当体制：営業やPM、WordPressエンジニア、インフラ、デザイン、テスト担当の配置。
- 再委託：範囲、責任者、連絡経路、品質管理を質問します。
課題を聞かずに技術や実績を説明する会社よりも、現行業務の例外や運用負担を確かめてくれる会社の方が、要件に合った提案をしやすくなります。
見積の内訳・前提・対象外の比較
同じ作業条件で比べるには、見積の内訳と数量をそろえることが欠かせません。
- 費目：要件定義、設計、デザイン、テーマ実装、独自プラグイン、環境構築を分けます。移行、テスト、公開、教育、保守も、別の費目にします。
- 数量と工数：ページや投稿タイプ、フォーム、連携先を数えます。移行件数や修正・会議回数、納品物も数値にします。
- 前提：「一式」に含まれる作業と対象外を確認します。金額の差は、前提条件の違いでも生じます。
原稿や画像を発注側が用意するのか、旧サイトを整理するのか、テストデータを誰が作るのかも、そろえておきます。
サーバーの契約者も確かめておきます。そのうえで、固定価格と実費精算の範囲、変更単価、納期が延びる条件を比較表に記録します。前提をそろえておくと、総額だけを並べる比べ方を避けられます。
セキュリティと保守の責任分界
対策方針と委託先の担当範囲を照らし合わせ、保守のどこまでを誰が受け持つかを決めます。
- 基本方針：WordPress公式は複数の対策を組み合わせる方針です（出典：WordPress.org「Hardening WordPress」）。
- 委託先の範囲：多要素認証や最小権限、IP制限、WAFを、委託先がどこまで担うか。改ざん検知やログ、復元テスト、脆弱性監視も同様に確かめます。
具体的な対策には、管理者アカウントの保護や不要機能の削減、更新、バックアップ、サーバー側の防御があります。
保守契約では、通常更新と緊急更新、障害の一次切り分け、復旧、原因調査を分けて書きます。軽微修正や機能追加、問い合わせも、別々に扱います。
対応時間と連絡方法は、契約前に確かめておきます。初動と復旧の目標も、障害時の対応を左右する条件です。月間の作業時間や対象外の作業、休日対応費も、見積の段階で確認します。
個人情報を扱う場合は、アクセス制御や認証、不正アクセス防止に加えて、再委託の管理や漏えい時の報告体制も発注条件に含めます。
よくある質問
WordPressの発注では、費用や開発範囲、セキュリティ、制作会社の選び方について、疑問が出やすいものです。依頼の前に確かめたい質問を、ここにまとめます。
WordPressで業務システムを作れますか？
作れます。ただし、すべての業務をWordPressだけで実装するのが適切とは限りません。コンテンツ管理や申込受付、会員ページ、検索、承認は、相性のよい機能です。
在庫引当や複雑な会計、厳密な監査、基幹データの正管理は、専用システムや外部サービスに任せる設計が検討されます。
WordPressのシステム開発は50万円でできますか？
小規模サイトや既成テーマの実装なら、公開料金で10万〜50万円程度のプランが見つかる場合があります。
一方、会員やECを含めると、費用は上がります。予約や外部API、データ移行、独自権限、保守まで含めると、数百万円以上になる可能性があります。
予算を理由に機能を削るより、必須機能と将来機能、保守費を分けて、段階的に発注する方が現実的です。
プラグインを多く使うとセキュリティが危険ですか？
プラグインの数だけで危険かどうかは決まりませんが、未更新や配布元不明、過剰な権限、未検証の組み合わせは、リスクになります。
採用理由と管理責任者を一覧にして、不要な製品は削除します。更新や復元は、ステージングで検証します。
管理画面の多要素認証や最小権限、WAF、バックアップ、脆弱性情報の監視も、あわせて組み合わせます。
WordPressの開発はどの会社へ依頼すればよいですか？
自社と同じ規模・業務の実績があり、要件定義から保守まで担える会社を選び、同じRFPで2〜3社に相見積もりを依頼します。
制作実績だけでなく、API連携やデータ移行、セキュリティ、テスト、障害対応についても確かめます。ソースコードや契約の引き継ぎ条件も、確認しておきます。
見積の安さよりも、前提と対象外を説明でき、公開後にどこまで責任を持つかを示せる会社を選びます。
まとめ
発注時は、ホームページ制作と業務システム開発を分けて考え、WordPressと外部システムのどちらでデータを管理するかを決めます。
目的や利用者、権限、連携の条件を、RFPにまとめます。移行や非機能、運用、成果物も、同じ資料に入れます。要件がどこまで決まっているかに応じて、既成テーマや独自開発、API連携、段階導入から選びます。
発注前に確認する項目
見積は、初期費用だけでなく、保守やライセンス、サーバー、脆弱性対応まで比べます。要件定義や移行、テストに加えて、復旧と契約終了時の引き継ぎも含めます。
準委任と請負の使い分け、変更時のルール、ソースコードとデータの権利、アカウント名義を契約に定めます。保守は、どこまでを誰が受け持つかも決めます。
先に決めておけば、安い見積の後から追加費用が積み上がるリスクを抑えられます。
2〜3社への同条件での相談
相談の前に要件を整理し、各社の提案条件を同じ項目で比べます。
- 相談準備：現行サイトと業務を洗い出し、必須機能と将来候補を分けて、2〜3社へ同じRFPで相談します。
- 提案比較：担当者や実績、見積前提、テスト、セキュリティ、保守、引き継ぎを確認します。
自社で運用を続けられるWordPressのシステムを選びます。
▼全体ガイドの記事
・WordPressのシステム開発の完全ガイド
▼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を創業。