Hapiのシステム開発の完全ガイド

Hapiで作るシステムは、Web API・社内ポータル、BFF・外部連携、パッケージやクラウドとの組み合わせのどれを選ぶかで、業務に合う形が変わります。

各テーマの詳しい内容は、下の関連記事で確認できます。

▼関連記事一覧
・Hapiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Hapiのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Hapiのシステム開発の見積相場や費用/コスト/値段について
・Hapiのシステム開発の発注/外注/依頼/委託方法について

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Hapiのシステムの全体像

Hapiは、HTTPサーバーやAPIを作るためのNode.jsフレームワークです。リクエストを受けてから、認証、入力検証、業務処理、DBアクセス、レスポンス返却までを実装できます。

公式の説明では、セキュリティ、接続性、セッション管理、テストなどを、拡張可能なプラグインで組み立てられる点が特徴とされています。

業務システム製品ではなく開発基盤という位置づけ

業務システムは、顧客、商品、注文、在庫、従業員などのデータで、企業固有の仕事を支えます。一方、Hapiが提供するのは、HTTPサーバー、ルーティング、リクエストのライフサイクル、認証や検証の拡張点です。

また、販売管理画面、ワークフロー、帳票、マスタ管理は、業務要件に合わせて別途設計・開発します。画面、データモデル、権限、移行、運用監視の見積りも必要です。

Hapiは完成品を選ぶ場面より、要件に合うバックエンドの実装方式を選ぶ場面で評価されます。

認証・検証・ライフサイクルの整理と実装

Hapiの機能は、リクエスト処理や認証などの役割ごとに使い分けます。

• 機能：ルーティング、ライフサイクル、プラグイン、認証・認可、入出力検証を扱えます。
• 認証方式：schemeを方式、strategyを設定済みの利用単位として扱います。
• 認証連携：Cookie、Basic、JWT、外部認証基盤との連携を設計できます。

ただし、ログイン後の権限やテナント分離は、Hapiが自動で決めるものではありません。処理は、リクエスト受付とルート検索から始まります。そのあと、パラメータ・クエリ・ペイロード検証と認証を行います。最後に、業務処理、レスポンス検証を経て送信します。

処理の差し込み位置が明確なため、監査ログや共通エラー処理の置き場所を決めやすくなります。一方で、検証設定、秘密情報の管理、例外時のログ設計は、実装側の責任です。

画面・API・データ・外部連携の分離による典型構成

構成を考える目安は、Hapiを置く層と、利用規模に応じて加える機能です。

• 画面・入口：ブラウザやモバイルアプリ、CDN・WAF・ロードバランサーを置く層です。
• 処理・データ：Hapi API、業務サービス、バッチ、DB、キャッシュ、キュー、外部サービスで構成されます。
• 利用経路：社内画面、スマートフォン、外部連携APIから、同じ業務ルールを使えます。
• 拡張と分割：小規模ならHapiと単一のリレーショナルDBから始め、利用量に応じてキャッシュ、非同期キュー、バッチ、監視を加えます。
• 分割判断：データ責任と障害時の復旧方法を決めたうえで、効果のある部分だけを切り出します。

Hapiのシステムでできること・種類と向き不向き

Hapiは、単純なデータ取得のAPIから、複数部門や外部サービスをつなぐ業務基盤まで使えるフレームワークです。適性は、APIの複雑さ、認証・認可の要件、Node.js人材、運用体制で判断します。

Web API・社内ポータル・管理画面の用途

Hapiは、データの提供から社内業務の操作、複数の画面との連携まで支えられます。

• Web API：顧客、予約、申請、在庫、受発注、会員、勤怠などを扱えます。
• 画面との連携：業務画面は別のフロントエンド技術で作り、HapiをAPI層に置くと、入力検証と権限確認を一箇所にまとめられます。
• 社内ポータル：部署・役職・担当範囲の制御、承認履歴、添付ファイル、通知を実装できます。
• API中心設計：既存画面、スマートフォン、外部サービスから同じデータを使う場合に効果的です。
• 別途設計する機能：細かな帳票、複雑なワークフロー、法令計算は、業務ロジックや周辺サービスで扱います。

BFF・マイクロサービスの接続層での使い方

用途を決めるときは、連携の役割と、分散後の運用負担を合わせて考えます。

• BFF・連携API：Web画面ごとのデータをまとめるBFFや、決済・在庫・会計など複数の外部サービスをつなぐAPIに使えます。
• マイクロサービス：特定の業務領域を担当するサービスにも利用できます。
• 責任範囲：認証、ログ、ドキュメント、共通エラー処理をプラグインで分離できます。
• 運用負担：分散化すると、通信、分散トランザクション、再実行、監視、障害切り分けが増えます。
• 小規模チーム：一つのアプリ内で境界を明確にし、将来分割できる構造にすると、納期と保守性のバランスを取りやすくなります。

パッケージ・クラウド・スクラッチの使い分け

業務の標準化の度合い、独自要件、既存設備の条件を踏まえて、方式を比べます。

• SaaS・パッケージ：会計、勤怠、顧客管理の標準機能が合えば採用し、不足分をHapiで補います。
• 導入効果：開発期間と初期費用を抑えやすく、製品側の更新も受けられます。
• クラウド開発：独自ルールが競争力に直結する場合は、Hapiのスクラッチ開発が候補になります。
• 構成要素：マネージドDB、オブジェクトストレージ、キュー、WAF、監視を組み合わせます。
• 既存設備と選定軸：閉域接続や低遅延が重要ならオンプレミスやハイブリッドも比較し、標準化する業務と独自化する業務を分けて考えます。

Hapiのシステム開発の進め方（4段階）

まず業務とデータを整理して小さく検証し、そのうえで本番へ段階的に広げます。発注者側のマスタ整備、現場確認、受入テスト、移行判断も工程に含めておくと、後戻りを防げます。

▶ 詳細はこちら：Hapiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

第1段階のAXの棚卸しと要件定義

業務の棚卸しでは、現場の作業と例外処理を業務フローにまとめます。例外を見ずに画面を作ると要件漏れになりやすいため、ここで洗い出しておきます。

• 業務の流れ：紙、Excel、メール、FAX、個人メモを洗い出し、入力者、承認者、次工程へ渡すデータを整理します。
• 例外と履歴：異常時の処理、締め日、取消、返品、権限変更、過去データの扱いが対象です。

規模に関わる要件として、ユーザー数、画面数、API数、データ量を整理します。そのうえで、外部連携と認証方式、保存期間を決めます。監査ログ、稼働時間、障害復旧目標も要件に含めます。

RTOは復旧までの目標時間、RPOは復元するデータ時点の目標です。数値を決めずに「高可用性」とだけ記すと、構成も費用も比べられません。

第2段階のAPI・データ・権限の設計

設計では、API、データ、権限、外部連携の境界を決めます。

• APIとデータ：責任範囲、データモデル、画面との境界、外部連携方式を決めます。
• アクセス制御：認証・認可の方法を設計します。
• 連携仕様：OpenAPIなどで入出力、エラー、権限を合意し、正とするデータのシステムを決めます。

業務ロジックをHapiのルート定義に詰め込まず、サービス層やドメイン層に分けておくと、テストや移行に対応しやすくなります。

既存システムとの連携では、項目対応表と文字コード、日時の扱いを仕様に書きます。重複、再送、タイムアウトについても、扱いを決めておきます。プラグインは、Hapi・Node.jsの対応版、更新頻度、脆弱性対応の担当者も確認します。

第3段階の小さなPoCと優先機能の開発

全社業務を一度に置き換えず、重要で範囲を限定できる機能からPoCを行います。たとえば、申請から承認までの一業務、在庫照会API、外部サービスとの認証連携が該当します。

PoCでは処理速度に加えて、権限漏れと利用者に伝わるエラーを確かめます。さらに、ログから原因を調べられるか、運用担当者がデプロイできるかも確認します。

検証で書いたコードは、そのまま本番に流用しません。結果をもとに、本番用の設計、テスト、監視、バックアップを整えます。

第4段階のテスト・移行・リリース・運用

テストは、単体から始めてAPI間の結合へ進み、権限と性能、障害復旧を確かめたうえで、利用部門の受入に移ります。異常系も洗い出し、取消や二重送信、在庫不足を含めます。権限変更、連携タイムアウト、日付境界も対象です。

移行では、データの抽出と変換、名寄せを進め、欠損の確認や件数の照合、リハーサルまで行います。そのうえで、本番切替の日時、旧システムとの並行稼働、戻し方、問い合わせ窓口を決めます。

利用者への操作説明と権限申請も準備します。リリース後は、エラー率や応答時間、利用状況、バックアップ結果、脆弱性情報を継続して確認します。

Hapiのシステムの費用相場とコスト内訳

Hapiはオープンソースのため、通常はフレームワークのライセンス料がかかりません。一方で、開発費や要件定義の費用は別途必要で、さらにクラウド、DB、監視の費用もかかります。診断、移行、保守の費用も、見ておく必要があります。

以下の金額は、2025〜2026年の国内業務システムの相場と要件規模をもとにした推定で、Hapi公式の価格表ではありません。

▶ 詳細はこちら：Hapiのシステム開発の見積相場や費用/コスト/値段について

規模別の初期費用の幅（150万円から数億円）

初期費用の目安は、含める機能や外部連携の範囲によって変わります。

• API・PoC、小規模画面：5〜20程度のAPI、基本認証、単一DB、最小限の画面を含み、150万〜400万円、1〜3か月が目安です。
• 中小企業向け：CRUD、複数権限、帳票、CSV、メール通知、基本テストと移行を含む構成で、400万〜1,000万円、3〜6か月程度。
• SSO・外部連携：OIDC・SAML、ERP・会計・決済連携、監査ログ、運用設計を含む場合の1,000万〜3,000万円、6〜12か月程度。
• 大規模連携：複数部門の基幹連携は3,000万〜8,000万円、大規模・高可用性は8,000万円から数億円で、期間は1〜3年の場合があります。

金額は、画面数、API数、ユーザー数、権限の細かさによって上下します。さらに、連携先、移行量、可用性、監査要件でも変わります。

業務知識、テスト、移行、運用の工数が総額を左右します。Hapiを採用したからといって安くなるとは限らず、この点は見積りで確かめる必要があります。

工程・機能・非機能の3方向での費用の分解

初期見積りの割合は、工程ごとの目安として仮置きします。

• 要件定義：10〜15%。
• 基本設計・詳細設計：それぞれ15〜20%、10〜15%。
• 開発・単体テスト：30〜40%。
• 結合・総合テスト：15〜20%。
• 移行・導入：5〜10%。

割合は案件の特性で変わるため、固定の正解ではありません。

IPAが紹介するCoBRA法は、少数の過去プロジェクトのデータと経験者の知識から、工数の見積りモデルを作る考え方です（出典: IPA/SEC「CoBRA法に基づく見積り支援ツール」、2010年）。

発注側も、類似案件、連携の難易度、データ品質、受入に参加する人数を整理しておくと、見積りの妥当性を確かめやすくなります。

保守・クラウド・更新費用の見込み

ランニング費用は、保守範囲やクラウド構成によって変わります。

• 保守費：初期開発費の年10〜20%、または月額25万〜50万円程度から仮置きします。
• 開発3,000万円の場合：年300万〜600万円が保守費の推定範囲です。
• クラウド費：小規模は月3万〜30万円、中規模は月30万〜150万円程度を仮置きできます。

保守費は、障害対応の時間、脆弱性修正、Node.js・Hapiの更新によって変わります。加えて、問い合わせや改善開発の範囲でも変わります。クラウド費は、通信量、DB性能、ログ保管、WAF、バックアップ、監視の構成で変動します。

停止時の損失や復旧時間も含め、構成ごとの月額総額を比較します。

Hapi・Express・NestJS・Fastifyの選び分け

Hapi、Express、NestJS、Fastifyに絶対的な優劣はありません。

そのため、規約の強さや認証・検証の標準化、チーム経験を比べます。既存資産、性能、将来の保守担当も見て、業務リスクの低いものを選びます。

Hapiが向くケース：ライフサイクルと拡張境界を明確にしたい場合

ExpressとHapiでは、構成の自由度や処理の明確さに違いがあります。

• Express：自由な最小構成や既存資産・人材の活用を重視する場合に候補です。
• Hapi：認証・認可、入出力検証、プラグイン境界、処理順序を明確にしたい場合に検討できます。
• 公式仕様：APIドキュメントはライフサイクルと検証設定を定義します（出典: hapi.dev APIドキュメント、2026年8月確認）。
• 学習コスト：予測可能性は品質管理に役立つ一方、考え方の理解と設定標準化が必要です。

NestJS・Fastifyとの比較軸（チームと要件）

チームの設計方針や優先する性能に合わせ、各フレームワークの適合性を比べます。

• NestJS：TypeScript、クラス設計、依存性注入、一定の構成を標準にしたい場合に候補です。
• Fastify：軽さや高いスループットを優先し、機能を選んで組みたい場合に候補です。
• Hapi：認証・検証の位置、プラグインの責任、ライフサイクルを明確にしたい場合に適合しやすいです。
• 比較課題：認証、権限、検証、DBエラー、ログ、テスト、デプロイを各案で試します。
• 評価軸：ベンチマークの数値に加えて、実装時間、レビュー性、障害調査性を比べます。3年後に更新できる担当者がいるかも重視します。

Node.jsとHapiの対応バージョンの固定

本番利用と保守を見据え、実行環境のサポート状況を確認します。

• 本番環境：Active LTSまたはMaintenance LTSを基本とし、EOL版を前提にした設計を避けます。
• 採用時の決定事項：Hapi・Node.jsの版、TypeScriptの型、プラグイン、テストツール、コンテナイメージを固定します。
• 更新計画：更新担当者と期限を決めます。

2026年8月時点でNode.js公式一覧ではv24とv22がLTS、v26がCurrent、v25・v23・v21・v20・v18などがEOLです（出典: Node.js公式リリース一覧、2026年8月確認）。

Hapi v21は、Node.js v18対応、ESMプロジェクトとの互換性、Node.js v12のサポート終了を含む近代化リリースです（出典: hapi.js公式GitHubリリース、2022年）。

Hapiの開発会社/ベンダーやサービスの選び方

Hapiの開発会社やサービスは、業務の整理から移行・保守まで責任を持てるかで見ます。Webサイトに技術名が載っているかは、その入り口にすぎません。

HapiとNode.jsの経験は同じではありません。そのため、担当者の経験、成果物、更新方針を比べます。

Hapi・Node.js・業務APIの実務経験の確認

Node.js対応と書かれていても、実務の深さは分かりません。そこで、Hapiの版や認証方式、入出力検証の経験を尋ねます。さらに、プラグインの選定、テスト、コンテナ運用、障害対応の経験も確かめます。

実績では、規模、要件、納品物、現在の保守担当を確かめます。業務面では、マスタ設計や名寄せ、帳票、締め処理の経験を見ます。加えて、権限、外部連携、現場教育の経験も確認します。

技術に詳しくても業務の理解が足りないと、要件漏れや過剰なカスタマイズにつながります。そのため、初回の提案で前提や例外処理まで質問してくるかを見ておきます。

見積依頼に書くべきAPI数・移行・非機能要件

見積依頼には、対象業務、数値条件、納品範囲、発注者側の分担を具体的に書きます。

• 業務と規模：目的、対象業務、画面数、API数、ユーザー数、データ量、権限、SSOを記載します。
• 機能・運用：外部連携、帳票、通知、移行、稼働時間、性能、RTO・RPO、監査ログを含めます。
• 納品と分担：ソースコード・設計書の範囲、発注者側のマスタ準備と受入テスト分担も示します。

見積書は、総額だけでなく工程ごとの内訳で比べます。要件定義、設計、開発、テストの費用は、それぞれ金額を示してもらいます。移行、教育、クラウド、保守の費用も、同じように確認します。

追加要件の単価や仕様変更、遅延時の責任、検収条件を確かめます。再委託、個人情報、障害時の連絡時間も確認しておきます。安い見積りには含まれない作業もあるため、その点も確かめます。

保守・引き継ぎ・フレームワーク更新の契約条件

納品後も、自社や別の会社で保守を続けられる条件を、契約であらかじめ確保しておきます。

• 引き継ぎ資料：設計書、環境構築手順、テストコード、ログの見方、障害対応手順を含めます。
• 運用環境：リポジトリ、CI/CD、秘密情報の保管場所、バックアップ、監視画面、依存一覧を決めます。
• 契約条件：Node.js・Hapi更新、脆弱性時の初動、定期更新、互換性検証、障害時SLA、移管条件を定めます。
• 移行への備え：Hapi固有処理と業務ロジックを分け、API契約と自動テストを残します。

▶ 詳細はこちら：Hapiのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Hapiのシステム開発の発注/外注/依頼/委託方法について

Hapiのシステムでセキュリティと保守を失敗しないための注意点

Hapiには、安全な初期設定、ペイロード制限、タイムアウト、HTTPセキュリティヘッダー、認証・認可、入力検証の仕組みがあります。

安全な業務システムにするには、機能を備えるだけでなく、権限、秘密情報、依存パッケージ、TLS、監査、運用手順を一体で管理します。

認証・認可・入力検証・ログの業務要件

安全に運用するには、利用者の権限と入力の扱いを管理手順に落とし込みます。

• 認証・認可：本人確認と操作範囲を分けたうえで、部署、役割、担当顧客、テナント、所有者に応じて参照・登録・更新・削除を制御します。
• 管理者権限：付与・変更・剥奪を記録し、退職や異動時に反映します。
• 入力とエラー：クエリ、パラメータ、本文、Cookie、ファイルを検証し、エラーに内部情報を含めません。
• 防御・記録：HTTPS/TLS、WAF、レート制限、CSRF対策、秘密情報、脆弱性スキャン、SBOM、バックアップ、監査ログを確認します。

IPAは2025年4月に、TLS暗号設定ガイドライン第3.1.1版を公開しました。特段の要件がなければ、推奨セキュリティ型を勧めています（出典: IPA「TLS暗号設定ガイドライン」、2025年）。

プラグインと依存パッケージの保守状況

プラグインが増えるほど、更新経路と脆弱性の確認対象も増えます。

• 保守状況：更新日、Hapi・Node.js対応版、脆弱性、テスト、代替手段、保守担当を見ます。
• 重要機能：認証や権限処理を、保守が止まったパッケージに依存させません。
• 依存管理：ロックファイルで固定し、脆弱性スキャンと自動テストをCIに組み込みます。
• バージョン更新：Node.jsのLTS時期、Hapiとの互換性、TypeScriptの型、コンテナ基盤の検証が対象です。
• 更新延期：先送りする場合は理由、期限、暫定対策を記録します。

よくある失敗：要件漏れ・マスタ未整備・EOL放置

失敗を防ぐには、開発前の業務確認と、リリース後の更新体制を整えます。

• 要件と開発範囲：例外処理を見ずに画面を作ることや、標準機能で足りる業務まで開発することは失敗例です。
• マスタ移行：重複を残す移行を避け、現場の業務フローを確認し、顧客・商品データのクレンジング担当と期限を決めます。
• EOL放置：更新担当を決めず、サポートの切れたNode.jsや保守停止プラグインを使い続けることも失敗です。
• 運用カレンダー：定期的な依存更新、脆弱性対応、復旧訓練、権限の見直しを予定に入れます。
• 移行性：Hapi APIへの密結合を避け、将来の移行に備えて契約テストと設計書を保ちます。

Hapiのシステムに関するよくある質問

ライセンス、開発体制、TypeScript、個人情報、将来の移行について、技術面と業務面の両方から答えます。

Hapiにライセンス費用はかかりますか？

Hapiはオープンソースのため、通常はHapi自体のライセンス料はかかりません。ただし、開発工数やクラウド、DB、監視の費用は別途必要です。診断、保守、外部サービスの利用料も、あわせて見込む必要があります。

採用するプラグインや周辺サービスのライセンス条件も、個別に確認します。

HapiでTypeScriptは使えますか？

使えます。採用する場合は、型定義、API契約、実行時の入力検証、テスト、ビルド設定をそろえます。

型注釈は、外部からの入力を保証するものではありません。そのため、Hapiの検証機能やスキーマも実行時に適用します。

Hapiで個人情報を扱えますか？

扱えます。法令上の安全管理措置は、Hapiの仕組みに加えて、要件と運用の両面で満たします。

要件には、利用目的、アクセス権限、保存期間を含めます。さらに、委託先管理、暗号化、ログ、バックアップ、削除の扱いも決めます。

漏えい時の連絡手順も定め、個人情報保護法や組織の規程に沿って運用します。開発前には、法務・セキュリティ担当と責任範囲を確認します。

保守会社を変更したりHapiから移行したりできますか？

できますが、契約と設計の準備が必要です。ソースコードや設計書、テストコード、API仕様を揃えます。環境構築手順、依存一覧、監視・バックアップ設定、障害履歴も、利用できる状態にします。

第三者が再現できる受入条件を定めます。Hapi固有処理と業務ロジックを分離すれば、別のNode.jsフレームワークへの段階移行も計画しやすくなります。

日本の開発会社や開発サービスに依頼できますか？

依頼できます。国内外を問わず、Hapiの実務経験やNode.jsのLTS対応、業務要件の整理、移行、セキュリティ、保守、引き継ぎを、同じ基準で比べます。

技術ページにHapiの記載があるかどうかで判断するのではなく、担当者、対応時間帯、成果物、契約条件を確認します。

まとめ：Hapiを選ぶ前の業務要件と運用体制

HapiはNode.js上で、業務API、社内ポータル、BFF、外部連携基盤、マイクロサービスを構築するための技術基盤です。認証・認可、入力検証、ライフサイクル、プラグインの境界を整理できます。

業務機能、データ、画面、移行、保守を自動で用意してくれる製品ではありません。

技術・費用・運用を一体で見る採用判断

採用前に業務とデータを洗い出し、APIと権限の仕様を定めます。連携、性能、RTO・RPO、監査要件も、あわせて決めておきます。

採用範囲は、SaaSやパッケージで足りる範囲、Hapiで開発する範囲、クラウドや既存設備を使う範囲に分けます。

費用は、初期開発に加えて、クラウド、監視、診断、更新、保守、教育まで含めて比べます。

小さな検証と、将来の更新・引き継ぎの設計

範囲を限ったPoCで、認証、入力検証、外部連携、ログ、テスト、デプロイを確かめ、採用リスクを事前に把握します。

長期運用に備えて、Node.js・Hapiの対応版とプラグインの保守を決めておきます。あわせて、脆弱性対応の担当、ソースと設計書の納品、保守会社の変更条件も定めます。

▼関連記事一覧
・Hapiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Hapiのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Hapiのシステム開発の見積相場や費用/コスト/値段について
・Hapiのシステム開発の発注/外注/依頼/委託方法について

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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