スクール管理システムの開発は、要件整理から定着まで6フェーズで進みます。
まず画面を作る前に、入会から月謝までの業務ルールを整理します。学習塾や英会話教室、資格・研修スクールなど業態が違うと、同じ「スクール管理」でも料金体系や振替条件、講師の働き方が異なります。
▼全体ガイドの記事
・スクール管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
スクール管理システム開発の全体像
スクール管理システムは、生徒や保護者、講師、本部の情報をつなぐ仕組みです。入会前の問い合わせから受講、請求、継続までを、一つの業務基盤で扱います。
学校法人向けの校務支援システムと共通する機能もあります。ただし、民間スクールでは月謝や体験予約、欠席・振替の処理が特に重要になります。さらに、兄弟や世帯単位の請求、退会・休会の処理も押さえる必要があります。
対象業態と解決したい業務の決定
導入の目的を「スクール管理システムを導入する」のままにしておくと、優先順位が決まりません。そのため、最初にその目的を具体的な業務へ置き換えます。
たとえば、受付の入金確認を短くしたいのか、講師の紙の指導報告をなくしたいのか、保護者からの欠席・振替の電話を減らしたいのかで、優先する機能は変わります。業態によっても中心になる業務は異なり、学習塾なら成績推移や講習の請求、英会話教室なら曜日固定と振替が中心になりやすいです。スポーツ教室では定員・進級・休講連絡、資格スクールでは通学とオンラインの受講履歴を扱うことが多くなります。
直近1か月の電話や紙、Excelでの作業を書き出し、件数と所要時間を記録しておきます。入金確認や振替対応も含めて数えておくと、開発の目的と投資対効果を説明しやすくなります。
SaaS、パッケージ、個別開発の業務適合度による比較
方式の違いは、導入の速さ、標準機能への適合、固有業務への対応範囲に表れます。
- SaaS：標準の生徒管理、予約、出欠、月謝、通知を早く試せます。
- パッケージ：標準機能を使いながら、設定変更や帳票追加で自社運用との差を吸収できます。
- 個別開発：兄弟請求、独自振替、校舎集計、会計・LMS・決済連携が必要な場合に向いています。
判断では、機能の数より、「誰の何分を減らすか」「現場の入力回数を増やさないか」「生徒数や校舎数が増えたときも料金と権限を管理できるか」で比べます。
既製サービスを使いながら、APIやCSVで不足部分を補うハイブリッド方式も現実的です。その場合は、最初から全機能を作るより、後述するPoCで重要業務を検証してから追加開発の範囲を決める進め方になります。
スクール管理システム開発の6フェーズの進め方
スクール管理システムの進め方は、6フェーズに分けると判断の抜け漏れを防げます。フェーズは要件整理から始まり、サービス・開発会社の選定、設計・開発を経て、テストと稼働に進み、最後は定着で終わります。
発注側と開発会社は、各フェーズの終了条件を決め、前の段階で未決定の業務ルールを次の工程へ持ち越さないことが大切です。
フェーズ1：業務フローと例外から始める要件整理
要件整理では、入会から退会までの業務を一連の業務フローとして書き出します。体験予約や欠席・振替、請求・入金消込などの作業が、どの順で、誰の手を通るかを見える形にします。各工程について、担当者、利用する帳票やツール、入力項目、承認者、締め日、完了条件を記録します。
要件は、必須と将来に分けておきます。必須要件では、予約と請求を中心に押さえます。また、予約と請求を支える機能も、必須の範囲として確かめます。
- 出欠・振替：欠席連絡から振替予約までの処理
- 決済：支払いの受け付けと、結果の取り込み
- 権限：利用者ごとに見える範囲の違い
- 講座・クラス・時間割：組み方と定員の扱い
- 通知・データ出力：保護者への連絡と、情報の書き出し
将来要件は、成績分析、動画や教材の配信、AIによる指導報告、会計やLMSとの連携などです。
特に、「欠席した場合、何日前までなら振替できるか」「振替先の定員をどう確保するか」「兄弟の請求を世帯でまとめるか」といった例外は、システムの難しさと見積金額を左右します。要件の一覧には、業務上の重要度や利用者、削減したい時間、標準機能で対応できるか、受け入れテストの方法を付けると、優先順位を説明できます。
フェーズ2：同じ業務シナリオでの選定比較
選定では、複数のSaaS、パッケージ、開発会社に同じ要件メモを渡します。デモでは、管理者画面だけでなく、現場の操作まで確かめます。具体的には、受付担当が体験予約を登録する操作、講師が出欠と指導報告を入力する操作、保護者が欠席連絡と振替予約を行う操作、本部が校舎別の在籍・売上を確認する操作を、実データに近い条件で見せてもらいます。
比較表には、対象業態と規模、標準機能、料金の増え方、カスタマイズ、API・CSVを並べます。さらに、データ移行や権限、操作ログ、バックアップも同じ表で比べます。障害時の連絡や導入支援、解約時のデータ返却も含めます。
公開料金がある場合も、オプションや決済手数料を含めた金額を確認します。運用や導入の段階で別にかかる費用も、見積もりの対象に含めます。
- SMS・メール送信料：保護者への通知にかかる費用
- クラウド：サービスを動かす基盤の利用料
- 端末：現場で使う機器にかかる費用
- 導入支援：立ち上げ時のサポートにかかる費用
営業担当の説明だけでなく、導入支援と保守の担当体制、問い合わせの受付時間、契約終了後のデータ削除方法まで質問します。
フェーズ3：データと権限を先に固める設計・開発
設計では、画面の見た目より先にデータの関係を決めておきます。まず、生徒と保護者の情報を、どのIDで結び付けるかを整理します。そのうえで、業務ごとの情報をどの単位で持つかも、同じ段階で決めます。
- 世帯の情報：兄弟や保護者をまとめる単位
- 契約・受講の情報：契約内容と受講状況を記録する情報
- 講座・クラスの情報：講座の中身とクラスの編成
- 講師・教室の情報：担当する講師と使う教室
予約・出欠や請求・決済、連絡・指導記録も、同じ考え方で結び付けを決めます。
兄弟を同一世帯として請求する場合は、子ども単位の受講情報と保護者単位の連絡先を分けて持てるかが重要です。権限も同じ段階で分け、本部は全校舎を見られる一方、講師は担当クラスの生徒だけ、受付は請求情報を扱えても成績の詳細は見られないようにします。保護者は自分の世帯だけを見られるように分けます。
未成年者の個人情報や成績、出欠、決済情報を扱うため、操作ログやバックアップ、脆弱性対応、保存期間、退会後の削除を、設計書と契約条件に反映させます。
フェーズ4：通常操作と例外処理を分けたテスト
テストでは、画面が表示されるかだけでなく、体験予約から退会まで業務が最後までつながるかを確認します。途中の入会や月謝請求、決済結果の取り込み、欠席・振替、保護者への通知も、一つのシナリオとして実行します。利用者ごとの受け入れテストを用意し、受付や講師、保護者、本部の代表者が自分の操作で合否を判断できるようにします。
特に、定員が埋まったクラスへの予約や、キャンセル期限を過ぎた欠席、振替期限切れを確認します。兄弟割引や日割り請求、返金、決済失敗、重複登録も、例外処理として試します。権限外のURLアクセスや通信障害時の代替手順もテストします。
個人情報を扱うシステムでは、他人の受講状況や成績が見えないことを利用者の権限ごとに確認します。2026年にIPAが公開した教育サービス事業者の事例でも、予約システムのURL変更による情報閲覧とパッチ未適用が問題として示されており、機能テストとセキュリティ検証を分けずに実施することが大切です。
フェーズ5：小さな範囲から始める稼働
本番稼働では、最初から全校舎・全講座を一度に切り替えず、1校舎または1クラスを対象にしたPoCから始めます。NotebookLMのリサーチでも、限定範囲で試し、費用対効果と現場の反応を見てから本格導入する進め方が挙げられています。
PoCでは、予約処理時間、欠席・振替の電話件数、入金確認時間、講師の入力時間、保護者の利用率を導入前と比較します。また、移行では、紙やExcelの名簿を整理してから移します。重複や表記ゆれ、未入力の連絡先、退会者、未収金、振替残数を確かめておきます。
そのうえで、データ項目の対応表や移行前後の件数照合、テスト移行、本番移行の責任者、旧運用を参照できる期間を決めます。講師・受付・本部向けの操作説明と、保護者向けのログイン案内、障害時の電話や紙による代替手順も、稼働判定の条件に含めます。
フェーズ6：利用率と業務時間を30・60・90日で測る定着
システムは、稼働しただけでは定着しません。そのため、30日後にはログインと入力のつまずき、60日後には紙や電話が残る理由、90日後には業務時間とミスの変化を確認します。
たとえば、保護者の欠席連絡がシステム経由になった割合、講師の指導報告の期限内入力率、未収金の確認時間を指標にします。予約変更に関する電話件数や管理者のCSV集計時間も、指標に加えます。
利用率が低いときは、現場の意識を責める前に、入力項目の多さや権限不足、通知の未着、既存業務との二重入力といった原因を確かめます。月1回の改善会議では、要望を「法令・安全」「業務継続」「時間削減」「将来拡張」に分類し、優先順位を付けます。また、AI授業報告など新しい機能を加える場合も、個人情報を一般公開サービスへ入力しないこと、出力を人が確認すること、ログを残すことを定着条件にします。
スクール管理システム開発の費用相場と内訳
スクール管理システムの費用の参考レンジは、既製SaaSなら初期0万〜10万円程度・月額数千円〜10万円程度です。設定や軽微な追加を含むパッケージなら初期10万〜100万円程度、カスタム開発なら200万〜800万円程度が目安です。
これは市場全体の平均ではなく、2026年公開の開発会社記事と公式料金ページを照合した目安です。金額は、生徒数や校舎数によって変わるほか、次の条件でも増減します。
- 決済：支払いの仕組みを、どこまで入れるか
- 通知：保護者などへ送る範囲
- 移行：移すデータの範囲
- 権限：利用者ごとに見える範囲の設計
- 独自ルール：割引や休会など、自社の業務ルール
そのため、予算の上限を断定する数字としては使わないようにします。
生徒数と独自要件から見る導入方式ごとの相場
2026年4月公開のGXOの記事では、SaaS型を月額2万〜10万円、カスタム開発を200万〜800万円とする目安が示されています。一方、株式会社大和コンピューターのPlatinum School公式料金ページでは、在籍生徒数で価格が段階的に変わります。
税抜きで、在籍生徒数10〜100人の基本ユニットは初期5万円・月額1万円からです。100〜1,000人は初期5万円・月額2万4,000円から、1,000人以上は初期5万円・月額6万2,000円からです（出典：Platinum School公式料金ページ、2026年8月確認）。いずれもオプションやサポート、決済などが加わるため、公開価格をそのまま相場と見なさず、比較材料として使います。
GMOメディアのコエテコマネージャー byGMOは、初期費用なし・30日間の無料トライアルと、生徒1人あたり月額100円からのスタータープランを公式に案内しています（出典：GMOメディア公式サービスページ、2026年8月確認）。ただし、生徒数課金は小規模で始めやすい一方で、在籍数が増えたときの月額、決済手数料、上位プラン、通知やAPIの条件まで試算する必要があります。
要件整理、開発、移行、保守に分けた見積もりの考え方
カスタム開発の見積もりは、実装とテストを中心に、作業ごとに分けます。実装とテスト以外の作業も、それぞれ別の金額として書いてもらいます。
- 要件整理・企画：業務フローや要件の一覧を作る作業
- 画面とデータの設計：画面の構成とデータの関係を決める作業
- 移行・教育・本番切り替え：データを移す作業、現場への教育、本番への切り替え
参考として、要件整理に10〜15%、画面・データ設計に15〜20%、実装に40〜50%、テスト・移行・教育に15〜25%程度を置く方法があります。ただし、複雑な決済や既存データの整理がある場合は、この配分も変わります。
開発費だけを低く見せるために、移行や受け入れテストを別項目へ隠していないかを確認します。継続費用には、サービス月額やクラウド費、保守・監視、決済手数料、口座振替手数料が含まれます。さらに、SMS・メール・LINEの送信料も、継続費用に入ります。
ほかに、ストレージや端末の費用、追加ユーザーやAPI利用料、脆弱性対応の費用も見ておきます。
発注側は、初期費用が小さくても、5年間の利用者数の増加、校舎追加、通知件数、データ容量、運用支援まで入れた総保有コストで比べると、方式ごとの差を説明しやすくなります。
PoCで効果を測り、不要な開発費を抑える方法
費用を抑えるには、検証したい業務を絞って、機能を段階的に入れていきます。たとえば1校舎の予約・出欠・振替・保護者通知を先に導入し、電話件数と受付担当の処理時間がどれだけ変わるかを測ります。効果が確認できた後に、月謝の複雑な割引、成績、会計連携、多校舎ダッシュボードを追加する方が、使われない機能へ先に投資するリスクを下げられます。
ただし、PoCでも権限、個人情報、バックアップ、データ返却の設計を後回しにしてはいけません。小さな範囲で始める場合も、本番で使う生徒データを誰が閲覧できるか、終了時にデータをどう取り出すか、障害が起きたときに紙や電話へ戻せるかを決めます。
PoCの成功条件は、画面が完成したことより、業務時間や入力率、ミス、利用者の反応が改善したことで定義します。
スクール管理システムの見積もりを取るポイント
見積もりを比べるときは、金額の大小より、同じ業務範囲を比較できているかを確認します。
「システム一式」「連携一式」「初期設定一式」と書かれた項目は、中身を質問します。画面数や利用者数、データ量、対象期間を聞きます。テスト回数や研修回数、保守期間も確かめます。
安い提案には、移行や教育が含まれていないこともあります。そのため、作るものと作らないものを明確にしておく必要があります。
RFPに記載する業務シナリオと受け入れ条件
発注前の要件メモやRFPには、対象スクールの種類と校舎数、在籍生徒数、講師数を書きます。特に、月謝の締め日と決済方法は、はっきり書いておきます。ほかに次の内容も記載します。
- 予約・キャンセル・振替の条件：期限や例外の扱い
- 現在のツールや連携先：今使っている道具と、つなぐ先
- 移行したいデータ：既存の名簿や請求の記録など、移す対象
- 希望時期：稼働を望む目安
機能一覧だけでなく、「保護者が前日までに欠席を登録し、空き枠へ振替予約し、受付と講師へ通知される」といった業務シナリオを示すと、各社が同じ前提で見積もれます。そのうえで、各要件には、必須、できれば必要、将来検討の区分と受け入れ条件を付けます。
たとえば、必須の予約機能なら「定員を超えて登録できない」「キャンセル期限を過ぎた場合の扱いが表示される」「保護者と講師に通知される」「管理者が履歴を確認できる」までを合格条件にします。これにより、デモではできたが本番の例外処理では使えないというズレを防げます。
見積書の項目別に見る作業範囲と別途費用
見積書は、要件整理や設計、実装、テストといった作業ごとに分かれているかを確認します。外部連携や受け入れ支援、データ移行、研修、本番移行、保守も、項目として見えるかを見ます。
また、既存Excelの整形や重複除去を、発注者と開発会社のどちらが行うのかも明記します。データ移行は名簿だけか、契約・請求・未収金・出欠・振替残数・指導履歴まで含むのかで、作業量が変わります。初期費用だけでなく、100人、500人、1,000人の利用ケースと、校舎を追加したケースの月額を試算してもらうと、成長後の予算を見通せます。
別途費用として、決済会社の手数料や口座振替の収納代行、SMS・メール・LINEの送信料を確認します。クラウドとストレージ、端末、アプリストア、訪問サポートの費用も確かめます。追加ユーザーやAPI、データ返却、プラン変更の扱いも、見積もりに入れておきます。
契約条件まで含めたセキュリティとデータ返却
セキュリティは、通信の暗号化に加えて、運用と契約の条件まで確かめます。利用者ごとの権限や管理者ログ、二要素認証の有無、バックアップの頻度と復旧方法を確認します。特に、委託先と再委託先の扱いは押さえておきます。また、脆弱性への備えと、事故が起きたときの取り決めも、契約前に確かめておきます。
- 脆弱性の検知：問題をどう見つけ、誰が把握するか
- パッチ適用：修正をどの期間で当てるか
- 保存場所：データを置く場所と、その管理体制
- 事故時の連絡期限：事故が起きたときに知らせてもらう期限
- 第三者検証の有無：外部の機関による検証を受けているか
文部科学省の「教育情報セキュリティポリシーに関するガイドライン（令和7年3月）」は学校向けの資料ですが、未成年者や教育データを扱うスクール事業者が確認項目を整理する際の参考になります。さらに、教育データを複数のサービスで活用する可能性がある場合は、APIの仕様、データ項目、レート制限、利用料金、認証方式、サービス終了時の取り出し方法を確認します。
契約終了時には、生徒と契約の情報を、CSVやAPIで返却できるかを確かめます。返却の対象には、世帯の情報から連絡・指導記録までを含めます。
返却費用と期限、削除証明の有無も、契約書や利用規約に記載してもらいます。安全性と移行性は、価格と同じ見積もりの評価項目です。
最終比較で同じ重みで見る4つの観点
見積もりの最終比較では、4つの観点を同じ重みで見ます。第一に業務適合性として、予約、振替、請求、保護者連絡、講師入力が自社のルールで動くかを確認します。第二に費用の透明性として、初期費用や月額、決済・通知、移行、保守が分かれているかを見ます。
費用の面では、追加開発や解約時のデータ返却も、別項目で示されているかを確かめます。第三に安全性と継続性を見ます。権限、ログ、バックアップ、脆弱性対応、障害時の代替手順、担当者の体制を確認します。
第四に定着支援を見ます。現場研修、操作マニュアル、問い合わせ窓口、30・60・90日の振り返りが、見積もりと契約に含まれているかを確認します。この4観点を点数化すれば、価格だけが安い提案へ流れにくくなります。
スクール管理システム開発のよくある質問
スクール管理システムの開発では、費用だけでなく、既製サービスで足りる範囲、移行の難しさ、現場が使い続けられるかが判断の分かれ目になります。
導入前によく相談される質問に、実務上の考え方で答えます。
スクール管理システムはSaaSと個別開発のどちらが良いですか？
標準的な生徒管理、予約、出欠、請求、通知を早く始めたい場合はSaaSが候補になります。一方、独自の兄弟・世帯請求、振替、フランチャイズ集計、既存システム連携が事業に直結し、標準機能で運用を変えられない場合は、個別開発を検討します。
導入の進め方としては、まずSaaSや小規模なPoCで業務の流れを見える形にし、不足する部分だけを連携開発する方法もあります。
スクール管理システム開発の費用はどのくらいですか？
公開情報に基づく参考レンジでは、既製SaaSは初期0万〜10万円程度・月額数千円〜10万円程度です。パッケージ設定型は初期10万〜100万円程度、カスタム開発は200万〜800万円程度です。これは市場全体の平均ではなく、2026年公開記事とサービス公式料金を照合した目安です。
具体的な金額は、自社の条件を渡して複数社から取得します。見積もりは、決済や通知、移行、連携、保守を含めた3年・5年の総額で比べます。
Excelや紙の生徒データは移行できますか？
移行できますが、名簿をCSVで取り込むだけか、契約、請求、未収金、出欠、振替残数、指導履歴まで移すかで作業量が変わります。そのうえで、氏名や住所の表記ゆれ、重複、退会者、空欄、日付形式を整理し、項目対応表を作ってテスト移行と件数照合を行います。
発注側は、元データを誰が整形するか、移行後に旧データをどの期間保管するか、個人情報をどこで作業するかも、見積もりと運用ルールに含めます。
開発から稼働までどのくらいの期間がかかりますか？
既製SaaSなら即日〜2週間程度で使い始められる場合があります。一方、パッケージの設定や軽微な追加なら2週間〜3か月、基本的なカスタム開発なら2〜5か月が参考です。複数校舎や保護者ポータル、決済・会計・LMS連携を含む統合型なら、4〜8か月程度が目安です。
要件整理、データ整備、受け入れテスト、講師・保護者への案内が遅れると、開発期間だけではなく稼働時期も後ろへずれます。
生徒情報や成績をAIに入力しても問題ありませんか？
利用目的、委託先、保存場所、学習への利用、アクセス権限、削除方法を確認せずに、個人情報や成績を一般公開のAIサービスへ入力してはいけません。AIを使う場合は、入力データを学習に利用しない契約や設定、検索対象の権限フィルタ、出力の人手確認、プロンプトと結果のログ保存を決めます。
発注側は、授業報告の下書きや問い合わせの一次回答など補助用途から始め、誤回答や情報漏えいが起きたときの停止手順も決めます。
契約終了時にスクール管理システムのデータを返却してもらえますか？
返却できるか、どの形式か、費用がかかるかはサービスごとに異なります。導入前に、生徒と受講契約のデータを、CSVやAPIで取得できるかを確かめます。ほかに次のデータも対象になります。
- 世帯のデータ：保護者や兄弟をまとめた情報
- 請求・決済：支払いの経緯の記録
- 出欠・振替：欠席や予約変更の記録
出力の項目と依頼期限、解約後の保存期間、削除証明の有無も確認します。
将来の乗り換えを考えるなら、導入時から標準的な項目名とIDを使い、データを取り戻せる設計にします。
まとめ：小さく検証してから広げるスクール管理システム
進め方は、(1)業務フローと例外を整理する、(2)同じ業務シナリオでSaaSや開発会社を比べる、(3)データと権限を設計して開発する、(4)通常操作と例外をテストする、の順です。そのうえで、(5)1校舎や1クラスから稼働し、(6)30・60・90日で定着を測ります。
現状の件数と時間の測定
機能一覧を作る前に、直近1か月にかかった件数と時間を測ります。対象は、電話や紙、Excelでの作業、入金確認、欠席・振替、保護者への連絡です。
対象業態や校舎数、在籍生徒数、講師数、月謝の締め日を一枚にまとめます。割引や返金、休会・振替のルール、連携先、移行したいデータも加えると、見積もりの前提がそろいます。
価格だけでなく安全性と定着まで含めた発注
相場は参考レンジとして使い、初期費用だけでなく月額と保守も含めて比較します。初期費用以外の費用も、同じ表に入れて比べます。
- 決済・通知：支払いの手数料や送信の費用
- データ移行：既存の名簿や請求データを移す作業の費用
- 追加開発：後から加える機能にかかる費用
- 5年間の運用費：月額や保守、利用者の増加に伴う費用
さらに、権限やログ、バックアップ、脆弱性対応を、見積もりと契約に反映します。障害時の代替やAI利用時の人手確認、契約終了時のデータ返却も、契約に含めます。
スクール管理システムは、受講生・保護者・講師・本部の業務とデータを支える基盤です。まずは、現場が使い続けられる範囲から始め、効果を測りながら自社に必要な機能へ段階的に広げていきます。
▼全体ガイドの記事
・スクール管理システム開発の完全ガイド
▼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を創業。