ECサイト/システム開発のフルスクラッチ・オーダーメイド開発について

ECサイトやEC基盤となるシステムを新たに立ち上げる、あるいは既存サイトを刷新する際、「ShopifyやmakeshopのようなカートASP・SaaSを使うか、EC-CUBEなどのオープンソースをベースにするか、ecbeingのようなパッケージを採用するか、それともゼロから自社専用にフルスクラッチで作るか」という構築手法の選択は、その後の売上拡大の自由度、保守体制、そしてトータルコストを大きく左右する最重要の意思決定です。とくにフルスクラッチ・オーダーメイド開発は、独自の購買体験やレコメンド、ポイント・サブスクリプションといった自社ならではの仕組みを制約なく作り込め、在庫・基幹・物流・会計といった社内システムとも自由に連携できる一方で、初期数千万円〜数億円という高い投資と、6か月〜2年以上という長い開発期間、そしてセキュリティから決済まで自前で抱える継続的な保守負担を伴います。「標準カートでは自社の複雑なビジネスモデルを実現できない」「大規模セール時のアクセス集中に耐えるサイトが欲しい」「顧客データや購買履歴を自社資産として完全に保有したい」といったニーズを持つEC事業者にとって、フルスクラッチは有力な選択肢ですが、その判断には4つの構築手法それぞれの費用・期間・トレードオフを正しく理解することが欠かせません。

本記事では、ECサイト・システム開発全般におけるフルスクラッチ・オーダーメイド開発に焦点を当て、カートASP/SaaS・オープンソース・パッケージ・フルスクラッチという4つの構築手法の費用と期間の比較、モール出店と自社EC構築という出店形態の違い、フルスクラッチがフィットするECと適さないEC、EC固有のメリットとデメリット、そして高額投資を成功に導くための実践的なポイントまでを、具体的な金額とともに体系的に解説します。「いきなりフルスクラッチか、それとも標準的な手法で十分か」という構築手法選びの意思決定そのものを軸に据え、SaaSとの損益分岐の判断軸、PCI DSSなど決済セキュリティの自前対応、繁忙期のスケーラビリティといったEC特有の論点を一般論で薄めずに掘り下げます。新規ECの構築方針を検討する経営者・EC担当者、既存サイトのリプレイスに悩む方にとって、自社にとって最適な構築手法を判断するための実践的な指針となる内容です。最後までお読みいただくことで、フルスクラッチという選択が自社のEC事業にふさわしいかを見極め、投資を成功に導くための視点が身に付くはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・ECサイト／システム開発の完全ガイド

EC構築手法の比較とフルスクラッチの位置づけ

ECサイト・システムの構築手法は、大きく「カートASP/SaaS」「オープンソース」「パッケージ」「フルスクラッチ」の4つに分けられます。この4手法は、費用・期間・自由度・保守構造のすべてが大きく異なり、自社がどこに位置づくべきかを理解することが、フルスクラッチを正しく判断する出発点になります。フルスクラッチは「自由度は最大だが、コストと期間も最大」という、EC構築手法のなかで最も投資の重い選択肢であり、他の3手法では実現できない要件が明確にある場合にのみ意味を持ちます。逆に言えば、標準的な手法で要件が満たせるなら、わざわざ最も高く長い手法を選ぶ理由はありません。まずは4手法それぞれが「いくらで・どれくらいの期間で・何ができて・誰が保守を担うのか」という構造を俯瞰し、その地図のなかでフルスクラッチがどの位置にあるのかを掴むことが、自社にとって過不足のない手法を選ぶための前提になります。ここでは、4手法の比較と出店形態の選択、そしてEC特有の費用構造の違いという3つの切り口から、フルスクラッチの立ち位置を整理します。

4つの構築手法のトレードオフを整理しておきましょう。最も手軽なのがShopify・makeshop・BASEといったカートASP/SaaSで、初期費用0〜数十万円・月額0〜数万円、構築期間も即日〜2か月程度です。サーバ保守やセキュリティ対応、システムの自動更新はサービス提供者側が担うため運用負担が軽い反面、機能はサービスの仕様に依存し、独自の作り込みには制約があります。次にEC-CUBEやWooCommerceに代表されるオープンソースで、ライセンスは無償、初期50万〜300万円・月額数万円〜、構築期間1〜数か月が目安です。プログラムを直接改修して会員・在庫・決済・物流連携を自由に開発できる一方、サーバやセキュリティ、バージョンアップの保守は自己責任になります。三番目がecbeingなどのパッケージで、初期300万〜3,000万円・月額5万〜30万円、構築期間3か月〜1年が目安となり、業種別テンプレートに手厚い標準機能を備え、基幹・OMO連携の実績も豊富です。そして最も自由度が高いのがフルスクラッチで、初期数千万〜数億円・月額数十万〜数百万円、構築期間は6か月〜2年以上に及びます。費用と期間はカートASP/SaaS→オープンソース→パッケージ→フルスクラッチの順に重くなり、自由度と拡張性はちょうどその逆順になる——この対称的な関係を頭に入れておくことが、手法選択の基本軸です。フルスクラッチは、この地図の最も右端、コストと自由度の両方が最大化する場所に位置します。

構築手法を考える前段として、そもそも「モールに出店するか、自社ECを構築するか」という出店形態の選択があります。Amazon・楽天・Yahoo!ショッピングといったモール出店は、既存の集客力と決済インフラを使えるため初期無料〜10万円程度で即座に販売を開始でき、立ち上げのハードルが極めて低いのが利点です。半面、デザインのカスタマイズ性が低くブランドの世界観を出しにくく、販売手数料（ロイヤリティ）が利益率を圧迫し、何より顧客データが自社資産になりにくくCRM施策が打ちにくいという制約があります。一方の自社EC構築は、独自ドメインで設計が自由でブランドを確立しやすく、顧客データを自社で蓄積してファンマーケティングや中長期の利益率向上につなげられますが、立ち上げ当初は集客力がゼロでSEO・SNS・広告に時間とコストが必要です。実務的には「モールで売上を作りつつ、自社ECでブランドと顧客資産を育てる」併用が定石です。そして、この自社EC構築の手段としてどの構築手法を選ぶか、という流れの最終地点にフルスクラッチが位置づきます。つまりフルスクラッチは「自社ECを、標準的なSaaSやパッケージの枠を超えて、独自に作り込みたい」という意思が明確になった事業者が到達する選択肢であり、出店形態の検討を飛ばしていきなり選ぶものではありません。

4手法のなかでEC特有の重要な違いが「保守構造」です。カートASP/SaaSはサーバ保守・セキュリティ対応・脆弱性パッチ・システム更新をすべてサービス側が担うため運用が手軽ですが、その対価として売上が拡大するほど決済手数料（3〜5%）やシステム利用料（1〜3%）、販売手数料が利益を圧迫します。つまりSaaSは「使った分・売れた分だけ手数料という変動費で支払う」構造です。逆にオープンソースやパッケージ、フルスクラッチは、ゼロからインフラを独自設計し、24時間365日の監視体制やフレームワークのバージョンアップ、基幹連携の保守を自前で抱える必要があるため、初期費用だけでなく総保有コスト（TCO）が格段に大きくなります。こちらは「保守体制という固定費で支払う」構造です。フルスクラッチを検討するということは、本質的にこの「手数料という変動費を、保守体制という固定費に置き換える」判断にほかなりません。売上規模が小さいうちは変動費型のSaaSが圧倒的に有利ですが、年商が数億円から数十億円規模に拡大すると、GMV（流通総額）に連動する手数料の累計が固定費型の保守コストを上回り、損益分岐点を越えてフルスクラッチが経済合理的になり得ます。判断軸は単純な月額比較ではなく、(1)GMV連動手数料の累計額、(2)標準機能では実現できない独自施策による売上向上の見込み、(3)自社で保守体制を維持できる人材・組織の有無、の3点を5年スパンで試算することです。この費用構造の違いを理解することが、手法選択の核心になります。

フルスクラッチが適するEC・適さないEC

フルスクラッチはすべてのEC事業者にとって最適な選択肢ではありません。高い投資に見合う価値が得られるECもあれば、カートASPやパッケージで十分なECもあります。むしろ実務では「本当はSaaSやパッケージで足りたのに、過剰にフルスクラッチを選んでしまった」という失敗のほうが、その逆よりも頻繁に起こります。自社のEC事業がどちらに当てはまるかを冷静に見極めることが、無駄な投資を避ける上で決定的に重要です。ここでは、フルスクラッチが適するECと適さないECを具体的に整理したうえで、両者の間をつなぐ「段階的移行」という現実的なアプローチを提示します。

フルスクラッチが適するのは、まず独自で複雑なビジネスモデルを持つECです。たとえば、定期購入（サブスクリプション）と都度購入を組み合わせた独自の販売形態、会員ランクに応じて価格やポイント還元率が動的に変わる仕組み、複数ブランドを横断する独自のレコメンドや購買体験など、標準カートの機能では実現できない作り込みが競争力の源泉になっている場合です。次に、大規模なアクセスが想定されるECです。テレビ放映直後やタイムセール、ブラックフライデーといった繁忙期に瞬間的なアクセス集中が発生するECでは、SaaSやパッケージの共有インフラでは性能要件を満たせないことがあり、アーキテクチャからスケーラビリティを最適化できるフルスクラッチが必要になります。さらに、基幹・在庫・物流・会計システムとの自由な連携を前提とするECも適合します。実店舗とECで在庫を一元管理し、受注から倉庫の出荷指示、会計計上までをリアルタイムに連携させたい場合、標準カートの限られた連携機能では対応しきれず、自社の業務フローに合わせた連携設計が可能なフルスクラッチが活きます。これらに共通するのは、年商規模が大きく、システムそのものが事業の競争力そのものになっているという点です。加えて、顧客情報や購買履歴といったデータ資産を自社に完全保有し、独自の分析やマーケティングに活用したいという戦略も、フルスクラッチを後押しする要因になります。要するに「標準機能では実現できない要件が、売上に直結する形で明確に存在するか」が、適合を判断する核心の問いです。

一方、フルスクラッチが適さないECもあります。代表的なのが、標準機能で十分にビジネスが回る小〜中規模のECです。一般的な商品一覧・カート・決済・会員管理といった機能で事足りるなら、カートASPやオープンソースで素早く安く構築でき、わざわざ数千万円のフルスクラッチで作る必要はありません。むしろフルスクラッチで作ると、構築に半年〜数年かかり費用も膨らむ上、決済セキュリティやサーバ保守まで自前で抱えることになり、費用対効果が著しく低下します。もう一つの適さないケースが、最速で市場の反応を確認したい初期フェーズのECです。新商品や新規事業の成否がまだ不確実な段階で、いきなりフルスクラッチで作り込むと、もし商品が売れず方向転換が必要になった場合に大きな投資が無駄になります。初期段階では、ShopifyやBASEといったカートASPで素早く出店して市場検証を行い、売上が軌道に乗り、標準機能の制約が明確なボトルネックになってからフルスクラッチへの移行を検討するのが賢明な進め方です。さらに、保守を担える人材・組織が社内にない事業者も、フルスクラッチには不向きです。フルスクラッチは作って終わりではなく、24時間365日の監視やセキュリティ対応を継続的に担う体制が前提になるため、それを内製でも保守契約でも維持できないなら、サービス側が保守を担うSaaSのほうが安全です。「標準機能で売上が伸びている」「まだ需要を検証している段階」「保守体制を持てない」というECでは、フルスクラッチは過剰投資になります。自社の要件が本当にフルスクラッチを必要とするレベルなのかを、感情ではなく事実で見極めることが大切です。

適する・適さないを最初から二者択一で決め切る必要はありません。EC全般の構築方針として最も現実的なのは、「まずSaaSやパッケージで標準的なECを立ち上げ、標準機能で詰まる独自要件が明確になってからフルスクラッチへ移行する」という段階的アプローチです。立ち上げ初期はShopifyなどのカートASPで素早く出店し、実際に運用しながら「どの機能が標準では足りないのか」「どの導線が売上のボトルネックになっているのか」を具体的なデータで把握します。この段階で得られた知見は、いきなりフルスクラッチで作る場合の要件定義の精度を飛躍的に高めます。なぜなら、机上の想像ではなく実運用で検証された要件だけを作り込むことになり、Fit to Standard（標準に業務を合わせる発想）の判断材料が揃うからです。また、すべてを一度にフルスクラッチで置き換えるのではなく、競争力の核となるフロントの購買体験だけを独自に作り込み、決済・在庫・物流といった汎用機能はヘッドレスコマースの発想で実績ある外部サービスとAPI連携する、というハイブリッド構成も有力です。これにより、決済セキュリティの自前対応や物流システムの新規開発といった重い負担を外部に切り出しつつ、自社の差別化に直結する部分だけに開発投資を集中できます。「ECサイト全体を一気にフルスクラッチか、すべてをパッケージか」という発想ではなく、運用で検証しながら、競争力の核となる部分から段階的にフルスクラッチへ寄せていく——この移行戦略こそが、コストとリスクを抑えながら差別化を実現する現実解です。

フルスクラッチECのメリットとデメリット

フルスクラッチECの判断は、メリットとデメリットを天秤にかけ、自社にとって投資が見合うかを見極める作業です。フルスクラッチには、他の3手法では得られない強力なメリットがある一方で、初期費用以上に重いデメリットも存在します。重要なのは、メリットだけに目を奪われず、運用フェーズまで含めた総合的な収支で判断することです。ここでは、EC固有の観点からメリットとデメリットを具体的に整理します。

フルスクラッチECのメリットは、第一に独自要件への完全対応と拡張性です。標準カートの制約に縛られず、独自の購買導線やレコメンドエンジン、ポイント・クーポンの複雑なロジック、サブスクリプションの柔軟な課金体系などを思い通りに実装でき、競合との差別化を技術で実現できます。アクセス急増時にもアーキテクチャから性能を最適化できるため、大規模セールでもサイトダウンを避ける設計が可能です。第二に、ソースコードとデータの完全な自社保有です。フルスクラッチではソースコードの権利を自社で保有できるため、特定のベンダーやSaaSプラットフォームに縛られないベンダーロックイン回避が実現します。SaaSのように提供者の都合で仕様変更・値上げ・サービス終了に振り回されるリスクがなく、システムそのものが企業の知的財産・IT資産として貸借対照表に乗り、事業売却時の企業価値向上にも直結します。第三に、EC事業の生命線である顧客情報・購買履歴・行動データを自社のデータ基盤に完全保有できる点です。モールやSaaSプラットフォームの制約を受けずにデータを横断分析し、独自のCRMやマーケティング施策、One to Oneのパーソナライズに活用できることは、データが競争力を左右する現代のEC事業において大きな戦略的価値を持ちます。これらのメリットは、いずれも「自社で完全にコントロールできる」という一点に集約されます。標準的な手法では他社の決めた枠のなかで戦うしかないのに対し、フルスクラッチでは枠そのものを自社で設計できる——これがフルスクラッチが持つ本質的な価値です。

一方、デメリットも明確です。第一に高コスト・長納期で、フルスクラッチECは初期数千万〜数億円の投資と、6か月〜2年以上のリードタイムを要します。この間は売上が立たないため、機会損失も含めた負担は大きく、繁忙期前のリリースを目指す場合はスケジュールの遅延が直接的な売上機会の喪失につながります。第二に、決済セキュリティの自前対応です。クレジットカード情報を扱うECでは、PCI DSS（カード業界のセキュリティ基準）への準拠が求められ、フルスクラッチで決済を自社実装する場合、この重い対応を自前で担う必要があります。多くの事業者は決済代行サービスを連携してカード情報の非保持化を図りますが、それでも連携部分の脆弱性対応やセキュリティ監査は継続的な負担となります。第三に、運用・保守を自前または保守契約で継続的に担う点です。SaaSと異なり、フレームワークのバージョンアップ、脆弱性パッチ、サーバ・インフラの24時間365日監視、不具合対応のすべてを自社で抱えるため、月額数十万〜数百万円規模のランニングコストと専任の運用体制が必要になります。第四に、技術選定のリスクです。長期間使うECだからこそ、採用したフレームワークや言語が将来EOL（サポート終了）を迎えると、再び高額なリプレイスが必要になります。これらのデメリットは初期費用以上に総保有コストを押し上げる要因であり、5年スパンのTCOで冷静に評価することが欠かせません。とくにEC全般で見落とされがちなのは、SaaSなら手数料に含まれていたセキュリティ対応やシステム更新が、フルスクラッチでは「自社が払う固定費」として丸ごと顕在化するという点です。手数料が消える代わりに保守体制の人件費が乗る、というこの交換を正しく見積もれているかが、投資判断の成否を分けます。

フルスクラッチECを成功させるポイント

高額なフルスクラッチEC開発で「予算が当初の何倍にも膨張した」「繁忙期に間に合わなかった」「リリース後に想定外のランニングコストが発覚した」といったトラブルを防ぐためには、要件定義・見積もり・契約の段階でいくつかの重要なポイントを押さえておくことが実務上欠かせません。ここでは、フルスクラッチECを成功に導くための具体的なポイントを、EC開発の現場に即して3つの観点から解説します。

第一のポイントは、スコープの明文化です。「どの機能を作るか」だけでなく「除外する機能」も明示し、独自要件として作り込むMust（必須）と、できれば欲しいWant（要望）を厳格に仕分けます。さらに、大規模セール時に何TPS（毎秒トランザクション数）を捌くか、ページ表示を何秒以内に保つか、稼働率をどこまで担保するかといった非機能要件を、RFP（提案依頼書）に必ず明記することが重要です。ECでは性能とセキュリティが売上に直結するため、機能要件だけのRFPでは見積もりも品質も大きくブレます。また、商品マスタの粒度、送料・決済・会員の仕様、在庫・基幹との連携仕様といったEC固有の要件は、早い段階で確定させないと後工程で大規模な追加開発を招きます。第二のポイントが、Fit to Standardの徹底です。標準的な機能をあえて独自仕様で作り込むと、コストが跳ね上がります。実際に、標準的なやり方で70%をまかなえたはずのところを全面カスタマイズした結果、予算が当初の2.5倍に膨張した事例もあります。人月単価×工数で費用が積み上がるフルスクラッチでは、「本当に独自である必要がある部分」と「標準的なやり方に業務を合わせられる部分」を見極め、後者は無理に作り込まないことが、コスト膨張を抑える最大の勘所です。前述の段階的移行で得た実運用の知見があれば、どこが本当に独自であるべきかを事実ベースで判断でき、競争力に直結しない機能まで作り込もうとする誘惑を、要件定義の段階で断ち切る規律が働きます。

第二のポイントは、隠れた費用を把握し、5年スパンの総保有コスト（TCO）で投資を評価することです。フルスクラッチECの見積もりで見落とされがちなのが、初期の開発費以外に発生する費用です。代表的なものに、既存サイトやモールからのデータ移行費があります。商品マスタ・顧客データ・購買履歴を新システムへ移す際、データ形式の不統一による文字化けや重複を防ぐためのクレンジング（整備）作業には、相応の工数がかかります。次に、オペレーション変更に伴うコストです。新しいECに合わせて受注処理や出荷のマニュアルを作り直し、運用担当者を教育する負担は、見積もりに含まれないことが少なくありません。さらに、決済代行・在庫・物流・会計といった連携先を後から追加する際の追加開発費も発生します。これらの隠れ費用に加え、月額数十万〜数百万円の保守費、サーバ・インフラ費、決済手数料（3〜5%）やシステム利用料（1〜3%）といったランニングコストを5年分積み上げて初めて、本当の投資額が見えてきます。ここでEC全般として有効なのが、第1章で触れた「手数料か保守体制か」の損益分岐の視点です。SaaSを5年使い続けた場合の手数料累計と、フルスクラッチの初期費＋5年分の保守体制コストを並べて比較することで、初めてフルスクラッチが経済合理的かどうかが判断できます。初期開発費だけを見て契約すると、リリース後にトータルの予算が大幅に超過する事態になりかねません。フルスクラッチは初期費用が大きいだけに、運用フェーズまで含めた5年TCOで判断することが、後悔しない投資の前提になります。

第三のポイントは、変更管理ルールと切り戻し基準を事前に合意しておくことです。フルスクラッチは自由度が高い分、開発中に「あの機能も欲しい、この導線も変えたい」と要望が膨らみやすく、これを放置すると予算・納期が際限なく膨張します。仕様変更が発生した際に、影響範囲の調査から工数・費用の見積もり、承認、実施という流れを明文化した変更管理プロセス（Change Request）を取り決め、発注側が主体となって定例会議や課題管理で進捗とスコープを統制することが、肥大化を防ぐ要です。もう一つ、ECで決定的に重要なのがカットオーバー（本番切替）時の切り戻し基準です。ECでは、サイトのリプレイス切替に失敗するとその瞬間から販売が止まり、売上が直接失われます。そのため、本番リリース時にどの条件を満たせなかったら旧システムへフォールバック（切り戻し）するのかという基準を、事前に発注者・開発会社の双方で合意しておく必要があります。とくにデータ移行は鬼門で、商品・顧客データの移行不備による文字化けや重複は、本番前にテスト移行を複数回繰り返して差分を検証することで防ぎます。繁忙期と切替が重なると致命的なため、リリース時期は年末や大型セールといった商戦期を避け、逆算してスケジュールを組むことも、ECならではの実務上の鉄則です。これらを契約段階で押さえておくことが、フルスクラッチという大きな投資を成功に導く実践的な要点になります。

まとめ

本記事では、ECサイト・システム開発全般におけるフルスクラッチ・オーダーメイド開発について、カートASP/SaaS・オープンソース・パッケージ・フルスクラッチという4つの構築手法の比較、モール出店と自社EC構築という出店形態の違い、フルスクラッチが適するECと適さないEC、EC固有のメリットとデメリット、そして成功のポイントまでを体系的に解説しました。フルスクラッチは「自由度は最大だが、コストと期間も最大」という特性を持ち、初期数千万〜数億円・構築期間6か月〜2年以上を要します。4手法を費用・期間・自由度・保守構造の地図のなかで捉えると、フルスクラッチは最も右端、コストと自由度の両方が最大化する位置にあり、独自で複雑なビジネスモデル、大規模アクセス、基幹・在庫・物流・会計との自由な連携、年商規模の大きいECに適する一方、標準機能で足りる小〜中規模ECや、最速で市場反応を見たい初期フェーズ、保守体制を持てない事業者には過剰投資となります。判断にあたっては、SaaSのGMV連動手数料の累計と、フルスクラッチの保守体制コストを5年スパンで比較する「手数料で払うか、保守体制で払うか」の損益分岐の視点が欠かせません。そしてEC全般の構築方針としては、いきなりフルスクラッチに飛び込むのではなく、まずSaaSやパッケージで標準を試し、標準で詰まる独自要件が実運用で明確になってからフルスクラッチへ寄せていく段階的移行が現実解です。独自要件対応・拡張性・ソースとデータの完全自社保有・ベンダーロックイン回避といったメリットと、高コスト・長納期・PCI DSS等の決済セキュリティ自前対応・保守負担・技術選定リスクというデメリットを天秤にかけ、スコープの明文化と非機能要件のRFP明記、Fit to Standardによるコスト膨張の抑制、隠れ費用の5年TCO評価、変更管理と切り戻し基準の事前合意を押さえることが、投資を成功に導く要点です。まずは複数の開発会社に相談し、自社のEC事業に最適な構築方針を見極めることをお勧めします。

▼全体ガイドの記事
・ECサイト／システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。