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

Preactのシステムを発注・外注するときは、業務の範囲を整理し、発注形態と契約を選んだうえで、RFPと見積もりの条件をそろえて進めます。この流れで進めると、業務全体の責任範囲を明確にできます。

全体像は、Preactのシステム開発の完全ガイドもご覧ください。

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

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

Preactのシステムを発注・外注する前に知っておきたい全体像

Preactは、ERPや販売管理の製品ではなく、ブラウザ画面を作るJavaScript UIライブラリです。業務データを保存するデータベースやAPI、認証・認可、バッチ、監査ログは、Preactとは別に設計します。

業務システムには、ログインやダッシュボードの画面があります。顧客・商品・案件の検索画面もあります。一覧・詳細・登録・編集の画面も含まれます。機能には、CSV入出力や承認、権限別メニューがあります。また、通知や操作履歴などの機能もあります。

このうち、Preactが主に担うのは、フォーム、表、チャート、モーダル、画面状態です。

Preactの位置づけは、業務システム製品ではなく画面の技術

発注側は、Preactが担う範囲と、システム全体で評価する対象を分けて整理します。

• Preactの役割：ブラウザ上の画面を作るUIライブラリです。
• 軽量性の範囲：約3kBは基本ランタイムの目安です。

Preact公式は、「Fast 3kB alternative to React」と説明しています（出典: Preact公式「Preact」）。

約3kBという数値は、業務システム全体の容量やAPI、画像、帳票、データベース、開発費を示すものではありません。

初期表示や操作感は、JavaScriptの分割、API応答、画像サイズ、キャッシュ、端末性能を合わせて測ります。

発注側は、対象業務や利用者、画面数、データ項目を先に整理します。あわせて、外部サービスや権限、障害時の運用も整理しておきます。整理が先でないと、「Preactで作る」とだけの発注になり、業務ルールや連携範囲が抜けた見積もりになりやすくなります。

Preactを選びやすい案件と慎重に検証すべき案件

案件の用途と既存資産から、適性と事前検証の要否を見極めます。

• 軽い画面：現場端末やモバイル回線向けの管理画面。
• 部分的な導入：既存サイトの検索・予約ウィジェットや、静的ページへの機能追加。
• 分割・段階移行：小さな画面群や既存画面の一部置き換え。

部分的に導入する場合は、既存サービスとの境界を先に決めておきます。

React専用のUI部品やチャート、Portal、CSS-in-JS、テスト環境を多く使う場合は、preact/compatでの動作を先に確かめます。

互換レイヤーを使えば、React向けライブラリを利用できます。ただし、すべてが動くとは限りません（出典: Preact公式「Upgrade Guide」）。

社内にReactの資産と人材が豊富であれば、移行・教育・保守を含めたReactの総保有コストが低くなる場合もあります。

発注形態の選択肢（SaaS・パッケージ・スクラッチ）

発注形態は、標準業務に合わせるか、固有業務を作るか、社内でどこまで運用するかで選びます。また、SaaSやパッケージで足りる部分は既製品を使い、不足する画面や連携だけをPreactで追加する方法もあります。

SaaS・パッケージが向く標準業務の案件

発注側は、標準機能の適合性と、導入後に追加する範囲を分けて比べます。

• 適合性：顧客、案件、在庫、申請、帳票が標準機能に近いか。
• 導入効果：期間を短縮でき、更新やバックアップを任せられるか。
• 追加画面の条件：API、認証、規約、出力、障害時の責任の分け方。

費用の目安を見ると、2026年公開の国内相場では、クラウド型は無料から100万円程度、パッケージ型は100万〜300万円程度です（出典: 秋霜堂株式会社「システム開発の費用相場」、2026年更新）。

国内相場は、サービス導入や設定の目安で、個別画面、API連携、データ移行、教育、Preactの追加開発を含む総額ではありません。

クラウド上のAPIとPreact画面を分けた開発

独自業務があり、データや認証をクラウドで構築できる場合に適した構成です。この場合は、クラウド上のAPI・データベースとPreactの画面を分けて構成します。

• 構成：クラウドのAPI・データベースとPreact画面を分離。
• クラウド選定：AWS、Azure、Google Cloudは、既存の社内基盤、担当者の運用経験、監視・復旧体制をもとに選びます。

分離すると、画面とバックエンドの改修を分けて進められます。さらに、別端末や外部サービスからもAPIを使えます。

RFPには、同時利用者数とピーク時のAPIリクエストを記載します。ほかの条件も、保存期間、復旧、保管場所の3つの観点で記載します。

画面が軽くても、APIの遅延や認証切れ、連携エラーを検知できなければ、現場の生産性は上がりません。

スクラッチにおける固有業務と段階発注の範囲

独自業務が競争力に直結する場合はスクラッチを検討し、次の順に段階的に発注します。

1. 現状調査
2. PoC
3. 1部門のMVP
4. 本番展開

対象となる固有業務には、独自承認、複雑な料金計算、ERP・会計・WMS連携があります。さらに、業界固有データも含まれます。

全社で一括発注すると、仕様が早い段階で固定されるおそれがあります。

PoCでは、代表画面1〜3枚、主要API1本、実際の端末を対象にします。そのうえで、ログインから登録までの操作を確かめ、権限エラーや通信遅延、初期表示も見ます。

React向け部品の動作やアクセシビリティ、テスト作成も検証します。完了条件と本開発へ進む基準は契約前に決めておき、技術検証だけで費用が膨らむのを防ぎます。

Preactのシステム発注・外注の進め順序

技術名や機能一覧だけで発注すると、業務ルール、例外処理、移行対象、非機能要件が抜けた見積もりになりがちです。そのため、次の順に進めるとともに、社内に意思決定者を置きます。

1. 現状把握と業務の整理
2. 要件定義とRFP作成
3. 候補会社へのRFP提示
4. 提案・見積比較と契約
5. 設計・開発、テスト・移行
6. 教育と稼働

現状調査による業務の事実と困りごとの収集

現状調査では、対象業務と、実際に現場で行われている作業を把握します。

• 調査対象：利用部門・利用者数・拠点数、対象データ、1日の登録件数。
• 既存環境：Excel・紙・基幹システム、連携先、利用端末。
• 業務観察：担当者への聞き取りに加え、入力、承認、差し戻し、検索、帳票出力を観察。
• 例外処理：担当者がどのように処理しているかを記録。
• 業務の整理：重複入力、未使用項目、部門別コード、数値補正を調べ、残す・やめる・システム化を分ける。

業務をそのままデジタル化しても、効率化できるとは限りません。悪いアナログ業務を移すと、使いにくい仕組みが増えます。

要件定義とRFPで提案条件をそろえる方法

候補会社が同じ条件で提案できるように、発注側は業務、機能、非機能の要件を整理します。

• 提案条件：目的、対象、利用者、範囲、時期、予算、成果物、保守。
• 機能要件：操作に加え、条件と処理後の結果を明示。
• 非機能要件：性能、可用性、セキュリティ、運用、利用環境。

画面、データ、権限、外部連携、移行対象も記します。機能は、「顧客登録」だけでなく、重複確認、個人情報の表示権限、操作履歴まで定義します。

非機能要件には、同時利用者数、応答時間、対応ブラウザ、スマートフォン対応を含めます。加えて、可用性、バックアップ、復旧目標を定めます。監視やログ、脆弱性診断、アクセシビリティ、秘密情報についても決めておきます。

Preactの軽量性を評価するなら、対象端末と通信条件をそろえ、初期表示や操作開始までの時間、API応答、エラー率を測る基準を定めます。

業務シナリオによる設計・テスト・移行の確認

設計から移行まで、業務シナリオに沿って安全性と完了条件を確かめます。

• 設計：画面とサーバーの双方で権限を守る。
• テスト：正常系に加えて例外や障害を再現する。
• 移行：データを照合し、切替と復旧条件を決める。

設計では、APIエラーの形式やデータの正本、認証・認可、権限表を定めます。通知や操作履歴、バックアップ、復旧についても、設計に含めます。

認可は、ボタンを隠す対応に加えて、APIやサーバー側での権限確認を含めて成り立ちます。URLを直接呼ばれても、許可されないデータが返らないようにします。

テストでは、正常な登録に加えて、通信遅延や二重送信、同時更新を再現します。権限不足やセッション切れ、CSV不正値、連携停止、データ重複、ブラウザ差異も確かめます。

移行では、顧客・商品・案件・権限・履歴の件数と代表データを照合します。あわせて、旧システムを参照専用にする時期と、失敗時に戻す状態を決めておきます。

RFPと要件整理に盛り込む項目

RFPは、候補会社に同じ前提で提案してもらうための資料です。完成した要件定義書でなくても構いません。目的や範囲、課題、優先順位を示し、制約や希望納期、発注範囲も含めます。

Preactを指定する場合は、採用理由と検証したい性能を添えます。React、SaaS、パッケージなどの代替案も提案してもらうと、比べやすくなります。

利用者の行動から書く業務要件

業務要件は、利用者の行動とデータの扱いから整理します。

• 業務の流れ：入力者、承認者、次の業務へ渡すデータを記載。案件管理なら営業登録、責任者承認、受注後の請求・生産連携。
• 権限と操作：担当者別メニュー、閲覧・編集・出力、差し戻し、取消、代理操作、退職者アカウントの停止。
• マスタ管理：管理者と変更ルールを決め、商品・顧客コードの表記揺れによる検索・集計・連携・移行への影響を確認。
• データ整理：重複・欠損・廃止データの整理を発注者と委託先のどちらが担うか決める。

技術要件の互換性・性能・保守性

技術選定では、開発構成や表示方式、互換性と保守方法を要件に含めます。

公開Webの場合は、検索流入や初期表示の重要度も要件に記します。

• 開発構成：TypeScript、Vite、ルーティング、フォームと検証、表、状態管理、テスト、CI/CD。
• 表示方式：公開WebはSSR・SSG、業務画面は認証後のSPAを検討。
• 互換性と保守：部品の検証、依存関係、ライセンス、更新を確認。

Preact公式のGetting Startedでは、Viteや既存ビルド環境の利用が案内されています。そのうえで、構成と採用理由を委託先に説明してもらいます（出典: Preact公式「Getting Started」）。

preact/compatを使う場合は、UI部品やチャート、エディタの動作確認結果を成果物に含めます。テストとPortalの確認結果も残します。さらに、Suspenseとアクセシビリティの確認結果も加えます。

Preact公式のv11移行ガイドは、ESMなど更新時に確認する差分を示しています（出典: Preact公式「Upgrade Guide v11」）。

依存パッケージやライセンス、脆弱性監視、更新手順も、納品条件に含めます。

後回しにしないセキュリティと運用要件

扱うデータに応じて、保護策と運用時の責任の範囲を明確にします。

• 保護・運用：認証、多要素認証、権限、暗号化、秘密情報、監査ログ、バックアップ、診断、障害連絡、復旧訓練。
• Web対策：API側の値検証、出力エスケープ、CSRF、Cookie属性、CSP、依存管理。

個人情報や従業員情報、取引データを扱う場合は、これらの対策を要件に含めます。

画面で入力値を制限していても、API側で値を検証しなければ、安全とはいえません。

XSSやCSRFの原因と対策は、IPAが「安全なウェブサイトの作り方」にまとめています（出典: IPA「安全なウェブサイトの作り方」）。個人情報保護委員会の指針も、あわせて確認します。

委託時は、再委託、アクセス権、保存期間、返却・削除、漏えい時の連絡を契約に盛り込みます。あわせて、稼働後に脆弱性を直す担当者も決めておきます。

請負・準委任・保守の契約形態の使い分け

契約は、仕様や成果物、受入条件を決められるか、発注者がどれだけ意思決定に参加するかで選びます。あわせて、対象業務、責任の分け方、変更、検収、知的財産、再委託、保守を確認します。

請負契約の成果物と検収条件

画面やAPI、テスト、移行などの成果物と完成条件を定義できる工程では、請負が候補になります。検収では、対象ブラウザや権限別の操作、APIエラーを確かめます。さらに、性能・セキュリティ試験、移行件数、マニュアルも確認します。

納品後に見つかった不具合の修補範囲と期間も確認しておきます。ただし、要件が固まる前に全機能を請負にすると、変更のたびに追加見積もりや納期延長が起きやすくなります。

要件定義やPoCは準委任、仕様が確定したMVPは請負とするように、工程ごとに分ける方法もあります。

準委任契約が向く企画・要件定義・アジャイル

準委任は、作業時間や専門家の支援を対象にする契約です。現場調査や技術検証、要件定義、設計、優先順位付け、アジャイルのスプリントなど、進めながら判断が変わる工程に適します。

準委任では、発注者側の業務責任者がレビューと意思決定を行います。会議や設計レビュー、バックログ、課題管理、検証結果、次の判断材料を成果として確認します。

作業が増え続けないよう、月ごとの作業範囲や担当者、稼働予定、経費、追加作業の承認方法を明記します。

保守契約での脆弱性・障害・追加変更の区分

問い合わせ、障害受付、監視、バックアップ確認は、分けて記載します。さらに、更新やブラウザ検証、脆弱性対応、軽微な修正、機能追加を、別の区分として並べます。重要度ごとの連絡時間や調査開始、復旧目標、休日対応、再発防止報告も確認します。

契約を終えるときは、ソースコードや設計書、CI/CD・クラウド設定を返却できるかを確認します。依存一覧、ログ、データも、返却の可否を確認します。さらに、引き継ぎ期間や知的財産権、ライセンスも定義します。

Preactのシステム開発費用・相場の目安

Preactは、MITライセンスのオープンソースです。そのため、基本ランタイムの利用料が主な費用になるわけではありません。費用の中心は、要件や画面、API・データベース、認証です。テスト、移行、クラウド、教育、保守も、その中に入ります。

2026年公開の国内相場は、業務システムで300万〜1,500万円、期間は4〜12か月という目安です（出典: モカモコ株式会社「システム開発の費用相場完全ガイド 2026年版」）。

次に示すのは、この相場とリサーチノートをもとにした、Preact案件の推定レンジです。

規模別の費用レンジと前提

規模別の推定レンジは、機能と既存基盤を使えるかどうかで変わります。各金額は保証額ではなく、予算検討の出発点として見てください。

• 小規模：画面中心なら150万〜300万円程度、2〜4か月です。
• 中規模：社内業務なら300万〜800万円程度、4〜8か月です。
• 標準規模：複数部門なら800万〜1,500万円程度、6〜12か月です。
• 大規模：連携・移行・多拠点を含むと1,500万円から数億円です。

小規模はログイン、一覧・詳細、簡易管理画面、既存API連携が中心です。その際、認証とデータベースは既存基盤で使える前提です。

新規認証や権限、監査ログ、データ移行まで含めると、このレンジを超えることがあります。

顧客・案件・在庫などを扱う中規模では、複数のCRUD画面や権限、CSVを想定します。さらに、通知とAPI連携も含めます。テストと初期移行も、対象に入れます。

承認や帳票、複数部門、監査ログ、外部サービス連携、教育を含む標準的な業務システムは、標準規模の目安になります。

ERP・WMS・会計・生産管理との連携や大量データ移行、高可用性、複数拠点の展開まで含むと、1,500万円から数億円まで幅があります。

大規模案件では、PreactかReactかよりも、データ連携や移行、非機能、教育、運用設計が金額と期間を左右します。

工程別の費用と見積書の作業範囲

工程別の費用配分は、見積もりを読む際の目安になります。ただし、実際の比率は、画面数やAPI本数、連携、データ品質、検証難度によって変わります。

• 要件定義：全体の10〜15%程度
• 基本設計：15〜20%程度
• 詳細設計：10〜15%程度
• 開発：30〜40%程度
• 結合・総合テスト：15〜20%程度

移行・導入は5〜10%程度が目安です（出典: NotebookLMリサーチノート「Preactのシステム」、業務システム全般Q&A）。

見積書は、画面・API一覧、移行件数、連携本数に分けてもらいます。ブラウザ、テストの種類とデータ作成、教育回数、会議・管理工数も、別々に示してもらいます。「開発一式」とまとめられると、作業の抜けと効率化の区別がつきません。

画面単価だけでなく、業務シナリオを完了するまでの総工数で比べます。

保守費とクラウド費を含む総保有コスト

初期費用だけでなく、運用と保守を含めた総額で比べます。

• 継続費用：クラウド、監視、バックアップ、ログ、API、通知、端末、診断、問い合わせ、更新、検証、改修。
• 保守費：初期開発費の年額15〜20%程度を仮置き。
• 比較項目：初期費用、月・年額、5年保守、クラウド、移行、教育、追加変更単価。

保守費は、対応時間や休日、脆弱性対応、追加開発を含むかどうかで変わります（出典: NotebookLMリサーチノート「Preactのシステム」）。

Preactを使うだけで開発費が自動的に下がるわけではありません。性能上の利点を実測し、不要な画面や連携を減らす要件整理と合わせて、総額を抑えていきます。

委託先の選定と見積比較の確認事項

委託先は、業務理解やバックエンド、セキュリティ、テスト、保守を含めて評価します。ReactやTypeScriptの実績があっても、Preactやpreact/compatの検証経験があるとは限りません。

担当エンジニアや実装範囲、テスト体制、稼働後の窓口を、具体的に確認します。

PoCによる互換性・性能・テストの確認

実業務に近い画面でPoCやデモを依頼し、利用者の一連の操作を確認します。表示速度だけでなく、エラー通知や再送、管理者による復旧も見ておきます。

• 操作：ログイン、検索、登録、権限エラー
• 負荷・連携：大量表示、CSV出力、通信遅延、API停止
• 利用環境：スマートフォン表示と端末ごとの操作感

React用部品を提案してもらう場合は、preact/compatで動かす部品と代替品を一覧にしてもらいます。あわせて、コンポーネントやE2Eテスト、アクセシビリティ検査、依存更新、脆弱性対応の担当を確認します。

AdyenはCheckoutやKYC向けSDKでPreactを採用した事例を公開しており、用途を絞った技術選定の参考になります（出典: Adyen「Right tooling, Right Problem: Preact at Adyen」、2022年）。

同じ前提と除外事項による見積書の比較

金額の大小より先に、見積もりに含まれる作業と発注者側の条件を照合します。

• 費用と範囲：初期・月額・年額、期間、体制、画面、API、連携、移行、テスト、教育、保守、変更単価。
• 除外作業：要件、権限、エラー、移行、受入支援、脆弱性診断。
• 発注者の前提：データ、会議、決定期限、テスト、クラウド、API仕様、端末、素材。

低額の提案では作業漏れを、高額の提案では標準機能や段階導入で減らせる作業を確かめます。

前提が曖昧なままだと、会社ごとに見積もりの条件がずれてしまいます。前提が違えば、同じ1,000万円でも範囲は異なります。発注者が用意するデータ、会議の参加者、意思決定の期限、テストの担当は、見積の前に決めておきます。これらが決まっていないと、各社の見積もりは前提がそろいません。

各社に同じ質問をして、回答の具体性とリスク説明を評価します。

担当者・成果物・保守体制の契約前確認

会社の規模よりも、必要な役割を継続して確保できるかを確認します。あわせて、納品後も運用を引き継げる体制かを見ておきます。

• 担当者：要件定義、Preact、API・インフラ、QA、運用。
• 引き継ぎ：本番担当、再委託、交代時の設計意図と障害履歴。
• 成果物：設計、データ・権限、テスト、移行、操作資料、ソース。
• 運用資料：CI/CD、依存一覧、監視・バックアップ、障害手順。

ソースだけでは、ビルドやデプロイの方法が分からず、保守を引き継げない場合があります。

稼働後の改善会議と追加改修の見積ルールも、契約に明記します。

Preactのシステム発注・外注でよくある質問

技術の軽さ、既存資産との互換性、業務の複雑さ、費用、保守体制を分けて考えると、候補会社に具体的な質問をしやすくなります。

PreactとReactはどちらを選んで発注すればよいですか？

初期表示の軽さや埋め込み性を重視し、必要な部品をPoCで確認できるなら、Preactが候補になります。一方で、React専用ライブラリや社内資産、人材、運用基盤を広く使う場合は、Reactが適する可能性があります。

技術名だけでなく、主要画面や端末、互換性、性能測定、保守担当を同じ条件で比べます。

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

画面中心なら150万〜300万円程度、中規模の社内業務開発なら300万〜800万円程度です。複数部門の標準的な業務システムは、800万〜1,500万円程度が推定レンジです。

ERP連携や大量移行、高可用性、多拠点展開を含むと、1,500万円から数億円まで広がります。見積もりは、Preactの料金ではなく、要件やAPI、移行、テスト、運用を含めて立てます。

RFPや契約でPreactの実績をどう確認すればよいですか？

Preact単体またはpreact/compatの実案件や担当者、採用ライブラリ、テスト結果、保守担当を確認します。「Preact対応」という記載からは、実力を判断できません。

実績を公開できない場合は、匿名化した画面やPoCで互換性を示してもらいます。契約には、成果物や検収、ソース、依存関係を記載します。さらに、知的財産権、再委託、脆弱性対応、終了時の引き継ぎも記載します。

既製SaaSにPreactの画面だけ追加する発注はできますか？

APIやデータ出力があり、認証と利用規約で外部画面が許可されていれば、実現できます。既存SaaSを正本にして、不足する検索や入力、ダッシュボードだけを作れば、開発範囲を絞れます。

発注前には、API制限や仕様変更、障害時の責任の分け方、データ同期の遅延を確認します。

まとめ

Preactは、業務システム全体ではなく、画面を担う技術として位置づけます。そのうえで、SaaS・パッケージ、APIと画面を分けるクラウド開発、スクラッチの範囲を分け、必要であれば1〜3画面のPoCから始めます。

RFP・契約・見積比較を一つの条件でそろえること

RFPには、業務や画面・API、権限、移行を含めます。連携や性能、セキュリティも記載します。バックアップ、テスト、教育、保守も、あわせて含めます。また、請負と準委任は工程ごとに使い分けます。

見積もりは、初期費用だけでなく、範囲や除外事項、クラウド、保守、追加変更を同じ前提で比べます。実績については、実装者、検証結果、保守体制で確認します。

業務成果と運用まで確認する発注

発注時は、Preactの特性と、業務や運用の条件を確認します。

• 技術の適用範囲：軽量性は初期表示や埋め込み性を改善する選択肢ですが、業務改善を約束するものではありません。
• 運用と品質：業務データの品質、認証・権限、APIの信頼性、テスト、教育、障害時の復旧について、委託先と合意します。

AdyenやITANDIの事例も、技術の用途と目的を絞るうえで参考になります。

合意した条件のもとで、Preactの利点を生かしたシステムにします。

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

▼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を創業。