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

Phoenixのシステムは、業務SaaS、リアルタイムサービス、IoT監視・API基盤の3つに分けると、独自業務のWeb化を考えやすくなります。

構築できるシステムと主要技術、開発の進め方、費用の目安、発注先の選び方を順に説明します。各テーマの詳しい内容は、下の関連記事でも確認できます。

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

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

Phoenixシステムの概要

Phoenixは、Elixirで書かれたサーバーサイドのWebフレームワークです。公式ドキュメントも、Phoenix v1.8.9をElixir製のMVC Web開発フレームワークと説明しています。

MVCの考え方で、画面とAPIを組み立てられます。さらに、データベースや認証、非同期処理、リアルタイム通信も、一つのアプリケーションとして設計できます。

Phoenix・Elixir・BEAMの関係

Elixirはプログラミング言語、PhoenixはWebアプリケーション用のフレームワーク、BEAMはElixirやErlangが動く仮想マシンです。

OTPは、プロセスの監視や再起動など、長時間稼働するシステムを支える設計思想と実行基盤です。

この構成では処理を分けられるため、安定運用しやすい仕組みを作れます。ただし、BEAM上で動くだけで高可用性になるわけではないので、障害切り分けや監視、DB冗長化、バックアップ復元を要件と設計に含めます。

Phoenixが注目される理由

Phoenixを選ぶときは、開発時と運用時に得られる特徴を分けて見ると、要件に合うかを判断しやすくなります。

• 開発速度：画面と処理を一つの設計で扱いやすい
• 同時接続・リアルタイム性：LiveViewで画面の状態を管理する
• 障害分離：プロセスを分けて運用しやすい

Phoenix LiveViewは、サーバー側で画面の状態を管理し、HTMLの差分をブラウザへ送ります。検索や入力、承認、ダッシュボードなどは、大量のJavaScriptを書かずに実装できる可能性があります。

ただし、Phoenixがすべてのシステムに最適とは限りません。既製SaaSで要件を満たせる場合や、Java・.NET資産との連携が中心なら、既存技術を使うことで移行リスクを抑えられることがあります。

採用は技術名だけで決めず、同時接続数や変更頻度、業務の独自性、社内の保守体制をもとに判断します。

Phoenixで構築できるシステムの種類

Phoenixは、要件に合わせてアプリケーションを構築する基盤です。完成済みの業務パッケージとは違い、独自の業務フローや利用者体験をWebシステムにしたい場合に検討の対象になります。

業務SaaS・社内業務システム

顧客や案件、在庫の管理などが、業務SaaSや社内業務システムの候補になります。受発注や予約、勤怠、申請、契約の管理も候補に入ります。さらに、部署やテナントごとの表示範囲も、認証・認可・データアクセスを中心に設計できます。

LiveViewでは、検索条件と一覧、入力エラーを同じ画面の流れで扱いやすくなります。承認状態も、画面の中で一緒に扱えます。

業務では、例外処理とデータの正しさが特に重要です。たとえば、Excelにしかない補助項目や、部署ごとの承認ルール、締め処理後の修正を、開発前に確認しておきます。単純なCRUDを超える要件は、先に整理しておきます。

チャット・通知・予約・共同操作

状態を利用者へすぐ反映するサービスも候補になります。チャットや即時通知、予約枠の更新のほか、作業状況の共有や共同編集も該当します。

Phoenix ChannelsとPubSubを使うと、WebSocketによる双方向通信や、複数のプロセス・ノード間でのイベント配信を設計できます。

接続が切れた後の再接続や、重複操作の整合性は、開発前に決めておきます。未受信通知の再取得や、利用者が増えたときの負荷分散も、あわせて決めます。何秒以内に何を反映するかを数値で定めると、過剰な構成を避けられます。

IoT監視・ダッシュボード・API基盤

センサーや外部サービスのデータを受けて、監視画面に表示するシステムも構築できます。管理者向けのダッシュボードやアラート、設備の稼働状況を、同じバックエンドで扱えます。モバイルアプリとの連携も、同じバックエンドで扱えます。

高頻度のイベントでは、受信、保存、画面配信を分けます。そうすると、遅延や欠損の場所を追えるようになります。

機械学習の推論や画像・動画処理は、別のサービスへ切り出し、Phoenixは認証やAPI、ジョブ管理、リアルタイム配信の中核に置く形が、保守しやすい場合があります。

Phoenixシステムの主要技術と構成要素

採用を判断する際は、画面とデータ、通信の組み合わせを確かめ、監視やデプロイまで見ておきます。代表的な構成を知っておくと、見積書や提案書の技術用語を比べやすくなります。

LiveViewとHEExで作る画面

LiveViewは、サーバー側でイベントを受け、状態を更新し、テンプレートの差分をブラウザへ送ります。初回は通常のHTTPでHTMLを返し、その後は持続的な接続を使います。

管理画面や業務画面をサーバー中心に作りながら、初期表示や検索エンジンにも配慮できます。公式ドキュメントにも、初回の静的HTMLと差分更新が説明されています。

HEExと関数コンポーネントを使うと、ボタンや入力欄、エラー、テーブルなどの部品を再利用できます。複雑なアニメーションや既存のJavaScriptライブラリとの統合では、必要な範囲でJavaScriptを併用します。

Ectoとデータベース設計

EctoはElixirのDBアクセスを担い、クエリやスキーマ、変更管理の役割を持ちます。一般的にはPostgreSQLなどと組み合わせ、マイグレーションで本番データの構造を段階的に変えます。

業務システムでは、削除や訂正の扱いと履歴を設計します。締め処理やテナント境界の扱いも決めておきます。データ移行では、重複や表記揺れ、欠損を調べ、過去の仕様も確認します。

そのため、実装の前に、移行件数や停止可能時間を決めておくと、リリース直前の手戻りを抑えられます。失敗時の戻し方と、移行後の照合方法も決めておきます。

OTP・監視・テスト・デプロイ

安定稼働には、実行基盤の特性を生かしたうえで、異常の把握からリリース後の確認までを運用に組み込みます。

• 監視：アプリケーションログに加えて、プロセス、DB接続、ジョブ、WebSocket、エラー率、応答時間
• テスト：権限、外部API障害、二重送信、接続断、DB復旧、負荷
• リリース：ロールバックの手順と、レビューの進め方

関数単位の単体テストに加えて、本番で起こりうる障害や利用者ごとの問題も確認しておく必要があります。

TelemetryやLiveDashboardを使う場合も、異常の定義、対応担当、対応時間を運用設計に記します。

Phoenix 1.8.0は2025年8月公開で、認証生成やスコープによるデータアクセスが改善されました。ただし、生成機能を本番要件とみなさず、案件固有のレビューを行います（出典: Phoenix公式ブログ、2025年）。

Phoenixシステム開発の進め方

開発では、画面を量産する前に事業目的と非機能要件を決めます。リアルタイム通信、マルチテナント、外部連携は、後から変えるとデータ構造や運用費に響きます。個人情報の扱いも同じ理由で、早めに決めておく必要があります。

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

1. 目的・業務フロー・非機能要件の定義

要件定義では、現場の作業と運用上の条件を結びつけ、あとから検証できる形にまとめます。

• 目的：誰のどの作業を、どの状態へ変えるか
• 要件項目：利用者、権限、処理件数、ピーク時間、保持期間の整理
• 運用条件：外部連携、通知、監査ログ、障害時の許容時間の記載
• 例外業務：返品、取消、差し戻し、担当者不在、締め後の訂正への対応
• 測定基準：応答2秒以内、ピーク時1,000件、通知30分以内、日次バックアップを30日保持

要件定義書では、機能要件と非機能要件を分けて書きます。測定基準を先に定めておくと、実装後に条件どおりかを検証できます。

2. 小さな技術検証によるリスクの確認

本格的な開発に入る前に検証範囲を絞ると、採用後に表面化する技術課題を早い段階で見つけられます。

• 動作検証：ログイン、権限、DB、主要画面、外部API、通知
• 運用検証：WebSocketの復旧、監視、デプロイを小さく試す
• 記録：検証の結果と、採用の判断材料を残す

要件定義のあとに、2〜4週間程度の技術検証を行います。この検証で、Phoenixの妥当性を確かめます。

検証で残すのは、動く画面だけではありません。Phoenix・Elixir・LiveViewのバージョンと依存ライブラリを記録し、クラウド構成、負荷試験の結果、未解決の課題、量産時の注意点も含めます。専門人材が少ない環境ほど、選定理由を文書にしておきます。

3. MVPの開発と業務価値の検証

MVPは、初期の範囲を広げすぎず、実際の利用から次に必要な開発を判断できる形にします。

• 対象を絞る：効果の大きい業務フローを1〜2個選ぶ
• 利用者の反応を見る：入力、用語、承認、通知への反応
• 安全策を保つ：MVPでもエラー表示、操作履歴、バックアップ、権限確認は省かない

対象の例は、顧客登録と案件進捗、予約受付と空き枠更新、設備データ受信と異常通知です。帳票や複雑な権限、全社連携を初めから詰め込むと、要件が膨らみ、検証が遅れます。また、本番データを使う場合は、検証環境のアクセス制御と匿名化も行います。

4. テスト・移行・リリース・引き継ぎ

本番化では、品質とデータの整合を確かめ、開発後も担当者が運用を続けられる状態を整えます。

• 本番前テスト：機能、権限逸脱、入力検証、同時更新、外部停止、ネットワーク断、負荷、復元
• 移行：リハーサル後に件数・金額・状態を旧環境と照合する
• 引き継ぎ：コード、設計書、データモデル、環境構築、CI/CD、監視、障害対応、依存更新、リリース・ロールバック

既存システムから移行する場合は、少なくとも1回リハーサルを行う前提で、計画を組み立てます。

依存ライブラリの更新手順も、引き継ぎに含めておきます。担当者が替わっても運用が続けられる状態を納品条件にすると、将来のベンダーロックインを抑えられます。

Phoenixのシステム開発費用相場と期間

Phoenix固有の国内公開料金表や統計は確認できません。そのため、ここに示す金額は、一般的なWeb開発相場と人月単価を基準に、専門性やリアルタイム要件を加味した編集用の推定です。

金額を左右するのは、利用者数と同時接続です。さらに、データ移行や外部連携、可用性、監査要件も、金額に響きます。

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

規模別の費用と開発期間の目安

必要な機能や運用要件で工数が変わるため、費用と期間はシステムの規模ごとに見比べます。

• 小規模MVP：300万〜800万円、3〜5か月
• 中規模業務システム：800万〜3,000万円、6〜12か月程度
• リアルタイム・高可用性型：2,000万〜6,000万円以上、9〜18か月
• 大規模案件：3,000万円〜1億円以上、1〜3年の場合もある

小規模MVPには、ログインや2〜3種類の権限、登録・検索・更新が含まれ、管理画面やPostgreSQLも入ります。中規模では、複数部門やCSV、外部API、通知が含まれます。監査ログと運用設計も、この範囲に入ります。

リアルタイム・高可用性型には、多数同時接続やChannels、複数ノードが含まれる場合があります。決済やIoT、チャットが入ることもあります。負荷試験と冗長化も、費用に影響します。

大規模案件には、基幹連携や複数拠点、長期移行、24時間運用を伴うことがあります。

2026年7月更新の一般的な開発費情報では、人月単価は50万〜150万円程度です。Webシステムのフルスクラッチは、300万円以上が目安です（出典: Webシステム開発費用相場の公開情報、2026年）。

Phoenixの推定レンジは、一般相場をそのまま当てはめず、専門人材、リアルタイム通信、運用設計の有無で上下します。

費用の内訳と増減要因

初期費用の配分と、工数が増減する条件を分けて見ると、見積もりの前提を比べる材料になります。

• 要件定義：初期費用の10〜15%
• 設計：25〜35%
• 実装・単体テスト：30〜40%
• 結合・総合テスト：15〜20%
• 移行・教育：5〜10%

割合は案件ごとに変わります。ただし、要件定義を削ると、仕様変更や手戻りで総額が増えることがあります。

費用が増える要因には、複雑な権限、テナント分離、既存データの移行があります。会計や決済、認証との連携も、費用を押し上げます。リアルタイム配信、監査ログ、負荷試験のほか、可用性目標も要因に挙げられます。

対象業務を絞ったり、既存の認証やマネージドDBを使ったり、LiveViewで共通画面を再利用したりすると、初期工数を抑えられる場合があります。

保守費・クラウド費・将来改修費

構築後の支出も含めて予算を考えると、初年度以降に必要な運用資金を見通せます。

• 運用費：クラウド、DB、監視、バックアップ、ログ保管
• 保守費：開発費の年額5〜15%、条件により15〜20%程度
• 将来費：更新検証、増強、保存量、担当者教育の見積もり

脆弱性診断や保守改修、障害対応にも費用がかかります。24時間監視やSLA、緊急対応、優先パッチ適用を含むと、年額保守が15〜20%程度になる場合があります。

初年度だけでなく、2年目以降の費用も確認します。Phoenix、Elixir、依存ライブラリの更新担当と、メジャー更新の検証費も見積もっておきます。

クラウドの増強条件や保存量の増加、担当者教育を契約に含めると、将来の予算を組めるようになります。

Phoenixの開発会社・ベンダーの選び方

Phoenixの発注先は、技術力と業務理解を中心に比べます。要件定義やセキュリティ、運用、引き継ぎについても、説明できるかを確かめます。

Phoenix・LiveViewの実運用経験の確認

本番稼働後の改善や障害対応を含む経験を確かめます。使っているPhoenix・LiveViewのバージョンや、Elixir・Erlang/OTPの経験年数も質問します。

Ectoを使った移行や、ChannelsとPubSubの用途を、具体的に確かめます。負荷試験や障害切り分けの経験も、詳しく聞いておきます。

可能なら、匿名化した設計例やテスト方針も見ます。コード量よりも、監視やタイムアウト、再試行、重複処理の考え方が、実務の成熟度を示します。権限境界やデータ整合性についても、同じように確かめます。

業務理解とプロジェクト管理の評価

発注先が、機能を画面に置き換えるだけでなく、業務目的と制約を確認するかを見ます。会議の頻度や課題管理、仕様変更の承認は、提案の段階で確かめておきます。受入テストの担当やリリース判断、遅延時の報告方法も、あわせて確認します。

海外を含む体制では、言語や時差、契約通貨を確かめます。加えて、準拠法や国外へのデータ移転、障害対応時間も確認します。国内体制でも、担当者への集中や休暇・退職時の代わりを確かめ、属人化を避けます。

見積書で比べる納品物・権利・保守条件

見積額だけでなく、契約終了後まで含めた条件を並べると、発注先ごとの支援範囲が見えてきます。

• 納品物：仕様、モデル、テスト、インフラ、CI/CD、監視、マニュアル、コード
• 権利：第三者・生成コードの扱い、利用権、データ所有権
• 保守：応答、復旧、更新、脆弱性対応、復元テストの条件

契約終了後の引き継ぎ費用や、軽微な改修の範囲も具体化します。見積もりが安くても、各項目が別料金なら、運用後の総額が高くなる可能性があります。

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

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

Phoenixシステムのセキュリティと運用設計

セキュリティは、要件、設計、実装、運用の全工程で作り込む必要があります。個人情報や決済、勤怠、医療情報を扱う場合は、標準機能だけで適合を判断せず、法令や業界ルールを確かめます。

認証・認可・テナント境界の分離設計

利用者の本人確認と操作権限を整理し、部署やテナントをまたぐ情報アクセスを防ぐ設計にします。

• 権限境界：利用者、ロール、組織、データ範囲、操作を分ける
• 認証対策：管理者の多要素認証とセッション失効を設ける
• 入力・操作対策：リセット、CSRF、入力検証、レート制限を含める

認証は本人確認、認可は操作の可否の判定です。ログインできたからといって、他部署や他テナントのデータを見られるとは限らないため、両者を分けて設計します。

個人情報保護委員会の通則編は、アクセス制御や利用者の識別・認証、外部からの不正アクセス防止を示しています。Phoenixのスコープや認可処理を使う場合も、重要操作の監査ログと、認可漏れのテストを用意します（出典: 個人情報保護委員会、2026年6月一部改正）。

TLS・秘密情報・バックアップの管理

公開後の情報保護と復旧に備え、通信設定や認証情報の管理方法を運用前に定めます。

• 通信：TLS、Cookie、HTTPヘッダーの管理
• 秘密情報：安全に保管し、ローテーションする
• 復旧：暗号化バックアップと復元テストを行う

公開システムでは、DB接続情報の管理も欠かせません。秘密鍵やAPIキーはコードに書かず、ログに個人情報やトークンを出さないよう、レビューで確かめます。

IPAは2025年4月にTLS暗号設定ガイドライン第3.1.1版を公開し、特段の要求がなければ、推奨セキュリティ型の利用を勧めています（出典: IPA、2025年）。暗号スイートや証明書の更新、脆弱性時の連絡方法も、あらかじめ決めておきます。

監視・障害対応・脆弱性対応の決め方

運用を始める前に、正常値と異常値を定めておきます。応答時間や5xx率、DB接続数などを監視し、通知先と担当を決めます。メモリやCPUのほか、WebSocket接続、ログイン失敗、権限エラーも監視項目です。

障害時の手順書には、影響の特定、通信の遮断、復旧、利用者への告知を含めます。証拠の保全や再発防止も、同じ手順書に入れておきます。依存ライブラリは、脆弱性情報の窓口と更新頻度を決め、テスト環境で確かめてから更新します。

生成AIでコード作成を速める場合も、運用の責任は人が担います。レビューやテスト、秘密情報とライセンスの確認も、人が行う必要があります。

2026年のPhoenix最新動向と採用判断

2026年時点で、Phoenixは新規開発に加え、既存のWebアプリを段階的に改善する選択肢にもなります。判断の軸は、最新機能の数より、チームが必要な機能を安全に運用できるかにあります。

Phoenix 1.8系の改善

Phoenix 1.8.0では、初期プロジェクトの生成と認証、スコープによるデータアクセスが改善されました。導入体験も改善されました。

新規開発では、Phoenix、Elixir、Erlang/OTPの対応バージョンを固定します。LiveViewやDBドライバも含めて、更新方針を決めておきます。

採用の判断は、新しさよりも、必要なライブラリやクラウド、監視、学習コストで評価します。既存案件では、互換性や非推奨API、DB変更の有無を確認したうえで更新します。ロールバックの手順も、あわせて確かめます。

LiveView 1.2と画面開発の変化

公式ブログによると、LiveView 1.2.0は2026年6月公開で、HEExの近くにCSSを置けるColocated CSSが紹介されています（出典: Phoenix公式ブログ、2026年6月）。

こうした仕組みは、画面単位の保守性やコンポーネントの再利用に役立ちます。

機能を増やすときほど、画面の責務を整理しておかないと、サーバー側の状態管理が複雑になります。長時間接続のタイムアウトや再接続時の状態は、実際の利用シナリオで検証します。ブラウザ拡張やアクセシビリティ、SEOも、検証の対象に含めます。

採用をおすすめできる条件・慎重にすべき条件

業務要件と社内外の保守体制を照らし合わせ、採用の適性を案件ごとに見極めます。

• 採用候補：継続改善、リアルタイム性、同時接続が重要
• 採用候補：画面とバックエンドを一体開発し、障害を分離したい
• 慎重に判断：既製SaaSで十分、Elixir運用者が不在、既存連携が中心
• 慎重に判断：ネイティブアプリや高度な画像処理が中心

既製品では独自の業務を吸収しにくいものの、完全なSPAほどの複雑さは必要ないケースで検討できます。

Java・.NET連携が中心の場合も、慎重に判断します。技術検証で保守とデータ連携のリスクを確かめ、必要であればPhoenixをAPIやリアルタイム機能に限定します。

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

発注前には、Phoenixの技術特性と、他の選択肢との違いを確認します。開発費や運用体制も、あわせて見ておきます。

Phoenixはどのようなシステムに向いていますか？

状態の更新や独自の業務ロジックがあるWebシステムに向きます。業務SaaSや社内システムのほか、チャットや通知、予約、監視ダッシュボードも例になります。既製SaaSで要件を満たせる場合は、導入期間と運用負担を比べます。

Phoenixのシステム開発費用はいくらですか？

小規模MVPは300万〜800万円、中規模業務システムは800万〜3,000万円、リアルタイム・高可用性型は2,000万〜6,000万円以上が推定レンジです。

Phoenix固有の公開料金は確認できないため、同時接続や連携、移行のほか、監査ログや保守条件も踏まえて、個別に見積もります。

ElixirやPhoenixの経験者が少なくても導入できますか？

導入はできますが、発注先に任せきりにせず、技術検証と文書の整備を行います。納品物には、バージョンや依存ライブラリ、監視、障害対応を含めます。加えて、移行やテスト手順も納品物に含め、社内担当者の教育と引き継ぎの時間を確保します。

LiveViewはSEOや初期表示に不利ではありませんか？

LiveViewは初回にHTTPでHTMLを返し、その後接続して差分更新できるため、初期表示や検索エンジンに配慮しやすい仕組みです。

公開ページでは、タイトルやメタ情報、構造、リンクを確認します。速度やアクセシビリティも確かめ、管理画面とは要件を分けます。

まとめ

PhoenixはElixirとBEAMを基盤にしたWebフレームワークです。業務WebシステムやSaaSを構築できます。チャットや通知、予約のほか、IoT監視やダッシュボードも対象になります。

LiveViewで画面を作り、Ectoでデータを扱い、ChannelsやPubSubで通信を設計できます。OTPは障害分離の土台になります。

採用前に押さえるポイント

採用前に確かめたいのは、要件定義とMVP、負荷試験です。権限や移行、TLS、監視の設計も対象になります。バックアップや脆弱性対応、設計書とソースコードの納品まで含めます。

小規模MVPは300万〜800万円、中規模は800万〜3,000万円が費用の推定目安です。リアルタイム・高可用性型は2,000万〜6,000万円以上となり、同時接続や外部連携で調整します。

技術検証と発注条件の整理

大規模開発をすぐに発注せず、2〜4週間程度の技術検証を先に行います。検証では、主要画面と認証、連携を確かめます。リアルタイム通信や監視、デプロイも、あわせて確認します。

業務フローや非機能要件、見積範囲を比べると、採用の価値とリスクを判断しやすくなります。保守や引き継ぎの条件も、あわせて比べます。

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

▼開発を相談する前に読みたい無料ホワイトペーパー
・【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を創業。