.NETのシステム開発の完全ガイド - ブログ

.NETは、Web業務アプリ、API・バッチ、Windows画面を組み合わせ、会社固有の業務を支える基盤です。

標準パッケージでは業務に合わない場合に候補となり、発注前には開発方式や進め方、費用、移行、セキュリティ、ベンダー選びの要点を押さえておく必要があります。

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

.NETのシステムの概要

.NETのシステムは、.NET基盤の上に会社ごとの業務ルールやデータ連携を実装したアプリケーション全体を指します。特定の業務パッケージを指す言葉ではありません。

新規開発では、C#を中心にASP.NET CoreやEntity Framework Coreを使います。また、データベースにはSQL ServerやPostgreSQLなどを組み合わせます。

.NETと.NET Frameworkの違い

現在の.NETはクロスプラットフォームの基盤で、WindowsだけでなくLinuxやコンテナ環境でも動作します。

一方で.NET Frameworkは、主にWindows向けに使われてきた旧世代の基盤です。ASP.NET MVC、Web Forms、WCF、Windows Formsなどの既存資産が、今も残っています。

両者は、実行基盤と接続・配置の方法が異なります。この違いを見たうえで、見積もりの前に対象バージョンを確定させます。

実行基盤：ランタイムとライブラリの違い。
接続・配置：認証方式とホスティング環境の違い。

2026年時点で、.NET 10はLTS（長期サポート）として提供されており、サポート終了日は2028年11月14日です。

なお、.NET 8と.NET 9は2026年11月10日にサポート終了予定です。終了後は、セキュリティ修正や技術サポートを受けられなくなります（出典: .NET公式サポートポリシー、2026年）。

新規に長期運用する場合は.NET 10を第一候補にします。一方で既存システムは、移行の難しさを調べてから計画を決めます。

.NETを構成する主な技術

.NETの構成要素は、画面、連携、データ処理、認証・監視の領域ごとに選びます。

画面：ASP.NET Core MVC、Razor Pages、Blazorから選べます。
接続：スマートフォンや他システムとの接続に使うWeb API。
処理・データ：定期・大量処理にはバッチやワーカーサービス、データアクセスにはEntity Framework Core。
認証・監視：Entra IDやOpenID Connect、クラウドのログ・メトリクス基盤の組み合わせ。

画面、API、データベース、外部連携を分けておくと、既存のロジックを使い回しやすくなります。たとえば、受注画面はWebで提供し、会計へはAPIで渡し、在庫は夜間バッチで集計できます。

また、.NET 10のASP.NET Coreでは、API仕様を表すOpenAPI 3.1ドキュメントの生成が強化されています。画面とAPIを分ける場合は、入出力を先に共有でき、フロントエンドや外部連携側との認識違いを減らせます（出典: ASP.NET Core .NET 10公式リリースノート、2026年）。

採用の前には、開発会社と一緒に、既存APIとの互換性や利用ツールの対応状況を確かめます。

.NETのシステムが向いている企業

.NETが向くのは、標準パッケージだけでは業務に合わない場合や、将来の機能追加を見込む場合です。

独自ルール：承認や複雑な料金計算を、業務に合わせて組めます。
細かな連携：既存データとの連携や、現場向けの帳票。
拡張の見込み：利用者や拠点の増加に備えた共通基盤。

.NETで作ること自体を目的にせず、独自開発が必要な範囲と標準機能で済む範囲を分けて考えます。

業務が標準化されていて、短期間かつ低費用での導入を優先するなら、SaaSや既製パッケージの方が合理的なことがあります。

.NETのシステムでできることと種類

接続やデータ処理も画面と並ぶ構成領域です。

.NETはWeb画面だけに限らず、業務データの処理、外部サービス連携、定期集計、Windows端末向け画面を、用途に合わせて組み合わせられます。代表的な種類は、Web業務システム、Web API・バッチ・外部連携、デスクトップ業務アプリの順に見ていきます。

Web業務システムとポータル

Web業務システムでは、販売管理や受発注、在庫を扱えます。また、勤怠や顧客管理、申請承認も扱えます。

展開・更新：端末ごとに専用ソフトを入れずに使えます。
業務機能：検索、登録、承認、帳票、CSV入出力、操作履歴を共通部品にできます。
ポータル：お知らせ、申請状況、売上・在庫のダッシュボードをまとめられます。
権限表示：責任者には集計値、担当者には自分の処理一覧を表示できます。

機能の更新はサーバー側で済むため、複数拠点や在宅勤務にも展開しやすい方式です。

Web API・バッチ・外部連携

API連携とバッチは、接続先や処理量に合わせて方式を選びます。

連携先：会計、EC、物流、決済、IoT機器などへデータを渡せます。
連携方式：相手のAPI、定刻のファイル受け渡し、イベント通知から選べます。
バッチ処理：売上集計、在庫再計算、請求書作成、データクレンジングなど。

処理件数、再送、重複登録、障害時の復旧を設計しておくと、連携が止まったときの手作業を減らせます。

大量データを画面の処理で扱うと、タイムアウトや負荷の集中が起きやすくなります。そのため、夜間や閑散時間帯に処理を分けます。バッチでは、開始・終了・失敗件数をログに残す設計も効果的です。

デスクトップ業務アプリと新しい画面方式

端末や画面に求める機能によって、デスクトップ方式とブラウザ方式を選び分けます。

WPF・Windows Forms：印刷、バーコード、専用機器との連携に向いた方式。
既存資産の活用：共通データや承認機能を、Web API経由で共有できる形にします。
Blazor：ブラウザでリッチな操作感を求める場合の候補。

Blazorを選ぶ前には、端末とオフライン要件、印刷、画面の複雑さを確かめます。加えて、保守担当者のスキルも判断材料になります。

技術が新しいかどうかよりも、要件に合うかを基準にします。要件によっては、シンプルなサーバーサイド画面の方が、開発後の運用まで含めて安定します。

.NETのシステムに適した開発方式

標準化できる業務はSaaSやパッケージに任せ、独自性の高い業務は.NET開発で作ると、費用と柔軟性のバランスを取りやすくなります。

すべてをスクラッチ開発するか、すべてをパッケージにするかの二択ではなく、業務領域ごとに適した手段を選べば、全体を一つの方式でそろえる必要はありません。

SaaS・パッケージを選ぶケース

勤怠、経費、会計などのように、標準機能に業務を合わせられる場合に向いています。

導入：数日から数か月に抑えやすく、初期開発費を減らせます。
料金・制限：月額料金、ユーザー数、データ保管場所、API利用料、カスタマイズ制限が確認点です。
業務適合：マスタ、締め処理、権限、帳票、データ出力の対応範囲。
契約終了：データ返却の条件。

標準機能に合わせた結果、現場の手作業が増えると、導入費が安くても全体のコストが高くなる可能性があります。

.NETでスクラッチ開発するケース

独自業務が競争力や効率に直結する場合は、.NETで業務に合う仕組みを作れます。

対象業務：独自フロー、複雑な料金計算、特殊な在庫、既存設備との連携。
設計の自由度：データ構造や権限を自社に合わせ、将来の拡張にも備えやすい方式。
進め方：主要KPIに関わる最小機能をMVP（Minimum Viable Product）として定め、利用状況に応じて広げる。

自由度が高い分、.NET開発では要件定義、テスト、文書、保守体制の品質が結果を左右します。特に、要件が曖昧なままだと、承認条件や例外処理が増え、納期と費用が膨らみます。

パッケージと.NETを組み合わせるケース

業務領域ごとにパッケージと.NETを分け、独自の部分を連携させる構成も現実的です。

領域分担：会計・人事をパッケージ、販売・在庫を.NET、全社認証を共通ID基盤に分けられます。
連携：APIやデータ連携で、標準機能の更新と固有処理を両立させる形。
運用ルール：正とするデータ、更新順、失敗時の再処理、利用者の問い合わせ先。

システムの数が増えると運用が複雑になるため、データ項目と責任範囲を図にしてから方式を決めます。

ポイント

業務ごとに、標準機能で足りるか、独自の処理が成果に直結するかで手段を分けます。全体を一つの方式でそろえず、パッケージと.NETを組み合わせる道も候補に入れます。

.NETのシステム開発の進め方

リリース準備から稼働後の支援までを連続した工程として見渡せます。

.NET開発では、技術を選ぶより先に業務とデータを整理します。そのうえで、企画から運用までを一つの流れとして設計します。工程は、企画と要件定義から始まり、設計と実装、テストと移行を経て、運用に至ります。

各段階の成果物と受入条件も、あらかじめ決めておきます。短納期でも、認証や権限の設計は後回しにせず、監査ログやバックアップも要件に含めます。

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

企画・要件定義の決定事項

企画では、何を作るかより先に、解決すべき業務上の問題を定めます。現状を数値で記録しておくと、目標を置きやすくなります。

現状把握：受注登録は平均15分、在庫確認は半日、承認漏れは月に数件など。
成果目標：「登録時間を30％短縮」「締め処理を翌営業日の午前中に完了」など。
要件整理：利用者の業務フロー、データ、権限、連携、帳票の条件。処理量、障害対応、保存期間も含めます。
成果物：画面一覧だけでなく、例外処理や業務上の禁止事項まで書いた要件定義書と各種一覧。

成果物を分けて残しておくと、見積もりと受入テストの基準がそろいます。

設計・開発の確認事項

設計・開発では、構成の決定と品質確認、現場レビューを一連の工程に含めます。

設計範囲：DBとAPI、認証と権限を決めます。ログ、バックアップ、監視、障害復旧も含みます。
共通化：業務ロジックをサービス層や共通部品に分け、画面・バッチ・APIで使い回す。
品質確認：コードレビュー、静的解析、依存パッケージの脆弱性確認。
現場レビュー：開発中に画面を触ってもらい、入力項目や承認順の認識違いを早く見つける。

優先機能は2週間程度の短い単位で実装し、デモと課題管理を繰り返します。そのため、要件の変化にも対応できる状態を保てます。

テスト・移行・リリースの確認事項

リリース前には、テストと移行をそれぞれ準備します。業務を再開したあとの支援体制も決めておきます。

テスト：単体、結合、総合、負荷、障害復旧、受入の各段階。
例外確認：二重登録、権限外操作、締め後修正、連携タイムアウトを確かめます。同時更新、文字化け、日付境界も対象です。
検証データ：業務データを使う場合は、個人情報をマスキングします。
データ移行：項目対応、不要データ、コード変換、重複除去、件数照合、リハーサル。
稼働準備：当日だけに頼らず、事前に複数回練習し、戻し方と業務停止時間を決める。

稼働後の窓口、障害の優先度、復旧目標、更新担当者を、あらかじめ決めておきます。

ポイント

技術を選ぶより前に業務とデータを整理し、各段階の成果物と受入条件を決めておくことが、判断の出発点になります。企画から運用までの流れも、この段階で一つにつなげておきます。

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

導入時の費用と稼働後に続く費用を分けて確認できます。

開発費は、機能数や画面数、連携数で変わります。データ移行や非機能要件、開発体制でも差が出ます。たとえば、簡易な業務ツールなら100万〜300万円が一つの目安です。

部門横断の中規模システムは500万〜1,000万円、全社基幹や複雑な連携を含む場合は1,000万円〜数千万円以上が目安です（出典: 2026年公開の業務システム開発費用相場情報、2026年）。

費用の目安は、.NET専用の公的な価格統計ではないため、予算取りの参考値として扱います。

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

規模別の初期費用と期間の目安

規模や含める要件によって、開発費と期間の目安は次のように変わります。

小規模.NET Webシステム：300万〜500万円、2〜4か月程度。
部門向け：マスタ管理、一覧・登録、簡易承認、帳票、外部連携を含み、500万〜1,000万円、4〜8か月程度。
複数拠点・基幹連携：1,000万〜3,000万円程度、8〜18か月に広がることがあります。

複数拠点や基幹連携に当たるのは、販売・在庫・購買や会計、ERPとの連携、大量データ移行、厳格な監査要件を含む場合です。

公開例のC#系人材の月額単価は約68.9万円です（出典: フリーランスエンジニア月額単価レポート、2025年2月）。仮に3人が6か月稼働すると、約1,240万円になります（68.9万円×3人×6か月）。この金額は人材単価からの試算で、受託開発の見積額ではありません。

実際の総額には、要件定義、設計、テスト、管理、インフラ、移行の作業が加わります。利益や契約上のリスクも含まれるため、単価だけで総額を判断しないことが大切です。

見積もりに含める費用

見積もりでは、初期費用と利用料、運用・保守費を分けて見ます。

初期費用：企画・要件定義、UI・データ設計、開発、テスト。移行、教育、リリース支援も含みます。
利用料：クラウド、データベース・監視、証明書、メール配信。帳票、バックアップ、セキュリティ製品も含まれます。
ライセンス：買い切りか月額か、開発環境と本番環境のどちらに必要かの区別。
運用・保守：問い合わせ、監視、バックアップ、脆弱性修正、OS等の更新、.NET更新。

保守費は、初期開発費の年15〜25％で仮置きする考え方もありますが、対応時間や作業範囲によって変わります。そのため、サポート時間、障害の優先度、復旧目標、追加開発単価を契約書に明記します。

ポイント

費用は機能数や連携数、移行の範囲で大きく変わるため、見積もりの前提をそろえて比べます。保守費や利用料などの運用費も、初期費用と分けて把握します。

既存.NET Frameworkから現行.NETへの移行

既存の.NET Frameworkシステムは、状況に応じて判断します。すぐに廃棄する必要も、無条件に延命する必要もありません。

まず、業務の重要度や障害件数、保守人材を洗い出します。そのうえで、ライブラリやOS、認証方式、データベースの状況も踏まえ、現状維持、段階移行、全面再構築を比較します。

最初に調べる移行リスク

移行の前に、既存資産と業務の停止条件を調べます。

技術資産：プロジェクト、依存パッケージ、DB接続、Windows専用API、COM・ActiveX、WCF。
機能資産：帳票、ファイル出力、認証、セッション管理の一覧。
業務条件：利用頻度と、業務を止めてよい許容時間。
移行順：参照画面、帳票、マスタ、API、更新処理の順に分けて移す方法。

Web Formsや古いライブラリは、そのまま現行.NETへ移せない場合があります。自動変換したあとも、画面の動作や文字コード、日付計算を別途テストします。印刷や権限、性能もテストの対象です。

古い資産にしか残っていない業務ルールは、担当者への聞き取りと実データの確認で、書面に残します。

業務を止めない段階移行

並行稼働でデータを照合しながら移行し、同期方法と終了条件を決めます。

照合：データ件数、金額、在庫残高、承認状態の一致。
方式：APIで新画面から旧処理を呼ぶストラングラーパターンや、参照系からの置き換えが候補です。
計画項目：バックアップ、リハーサル、照合、切り戻し、問い合わせ対応。

新旧両方に入力する期間が長いと負担が増えるため、同期方法と終了条件を先に決めます。

費用は、画面数のほかに、データの汚れや連携先数、リハーサル回数、業務停止時間、旧仕様の再現範囲でも変わります。

サポート終了日が近いバージョンでは、更新計画の調査を早めに始めます。

現状維持・移行・再構築の判断

現状維持、段階移行、再構築は、安定性や業務変更の状況で選びます。

現状維持：安定稼働し、変更が少なく、短期予算を抑えたい場合。
段階移行：重要業務を止められず、既存資産を一部活かしたい場合。
再構築：業務変化、データ構造の破綻、大規模改修が続く場合。

サポート切れや担当者不足、脆弱性、クラウド移行の制約があれば、維持費と事業リスクを合わせて評価します。

再構築では、技術を更新するだけでなく、不要な業務を廃止し、承認やマスタの責任者を決めてから設計します。

ポイント

サポート期限と業務の停止条件、移行リスクを見て、現状維持、段階移行、再構築のどれにするかを決めます。既存資産の洗い出しを、その前に済ませておきます。

.NETのシステムに必要なセキュリティと運用

業務システムには、誰がどの情報を見て、何を変更したかを説明できることが求められます。そのため、認証や権限、暗号化、脆弱性、ログを要件に含めます。バックアップや障害復旧も対象に加え、その費用を開発費と運用費に反映します。

認証・権限・監査ログ

認証方式や権限の範囲、監査ログの扱いを決めて運用します。

認証：社内ID連携、シングルサインオン、多要素認証、条件付きアクセスが候補です。
権限：部門・拠点・顧客・処理状態ごとに、閲覧や登録の範囲を定めます。承認と出力も、同じ単位で決めます。
ログ：操作日時、利用者、対象、変更前後の値を記録します。

退職や異動の際に権限を止める運用を設計します。そのうえで、ログの改ざん防止や保存期間、検索、通知、確認担当者も決めます。

ログの対象は、ログイン、登録、更新、削除、承認とします。CSV出力や権限変更も、対象に含めます。特に、個人情報や機密情報を扱う場合は、画面表示やログへの出力範囲を最小限にします。

クラウド・監視・バックアップ

クラウドの構成と利用量、復旧目標は、運用設計に含めます。

構成管理：アプリ、DB、ストレージ、ネットワーク、秘密情報、監視の整理。
拡張と制御：自動拡張、環境分離、アクセス制御、コスト上限アラートの設定。
バックアップ：取得だけでなく、復元できることが重要です。復旧目標時間と時点を定め、訓練します。

月額費用は利用量で変わるため、想定利用量と上限を見積もりに入れます。

2026年の情報セキュリティ10大脅威には、委託先を狙う攻撃、AI利用のリスク、脆弱性を悪用した攻撃などが挙げられています（出典: IPA「情報セキュリティ10大脅威2026」、2026年）。そのため、委託先管理、依存パッケージの更新、生成AIコードのレビューも、運用項目に含めます。

生成AIを使う開発の注意点

生成AIは開発の補助に使えます。ただし、入力情報や成果物、品質確認のルールを定めておく必要があります。

活用例：コードのひな形、テスト、文書の下書き、SQLレビュー。
品質確認：人のレビュー、ライセンス・脆弱性の確認、テスト。
慎重な処理：権限、金額、個人情報に関わる生成結果を、そのまま本番へ出さない。

社内データや認証情報は入力しないというルールも設けます。

効果は、開発時間だけでなく、レビュー・テストの増加や保守性、仕様の理解者も含めて評価します。

利用サービスや入力可能な情報、成果物の所有権、ログ保存、再委託の範囲は、契約と社内規程に反映します。

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

.NETに対応していても、自社の業務を理解し、要件定義から運用まで伴走できるとは限りません。そのため、C#の経験だけでなく、既存資産の移行やデータ連携、セキュリティ、障害対応、利用定着も比べます。

実績と担当体制の確認

開発実績と、案件を担当する体制、納品後の支援を確かめます。

類似実績：業務、利用者数、データ量、連携方式、現行バージョン。
対応経験：新規開発、Framework移行、保守、障害対応、更新の実績を尋ねます。
担当体制：要件定義から運用までの担当者と、再委託の有無。
納品・支援：引継ぎ、ソースや設計書の範囲、リリース後の窓口。

可能であれば、機密を除いたうえで、類似案件の構成図や課題、対策を確かめます。資格は参考情報にとどめ、目の前の案件を管理する体制と成果物の品質を見ます。

同じRFPによる見積もりの比較

同じ要件資料を使い、見積もり範囲と提案内容を比較します。

共通条件：要件定義書、画面一覧、連携一覧、データ移行条件、非機能要件を各社へ渡す。
見積内訳：要件定義、設計、実装、テスト、移行を照合します。教育や保守、クラウド、ライセンスも対象です。
提案評価：リスク指摘、質問、日程、変更ルール、保守範囲。
契約条件：請負・準委任、受入基準、瑕疵・障害、知財、第三者ライセンス、終了時の引継ぎ。

極端に安い見積もりには、テスト、移行、運用設計、変更管理が含まれていない可能性があります。

発注側にも業務責任者と意思決定者を置いておくと、要件変更を整理しやすくなります。

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

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

ポイント

開発会社は、類似実績と担当体制、同じ要件資料での見積もり内訳を比べて選びます。安い見積もりは、テストや移行、運用設計が含まれているかを確かめる必要があります。

よくある質問

技術だけでなく、費用や移行、運用、発注方法についても疑問が出ます。そこで、相談前によく確認される質問に答えます。

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

小規模は300万〜500万円、中規模は500万〜1,000万円、大規模の基幹連携は1,000万円以上が目安です。機能や連携、移行、セキュリティ、期間で金額が変わるため、内訳と前提条件も確かめます。

.NET Frameworkのシステムはすぐ移行すべきですか？

すぐに全面移行はせず、まず依存ライブラリやOS、認証、帳票を調べます。WCF・COMや停止許容時間も確かめます。サポート切れや脆弱性、人材不足があるときは、参照画面やAPIから段階移行する方法も選べます。

パッケージと.NET開発はどちらが良いですか？

標準化できる業務が多く導入を急ぐならパッケージやSaaS、独自ルールや連携が成果に直結するなら.NET開発が向いています。

業務領域ごとに標準機能で済ませる部分と独自開発する部分を分けると、初期費用と将来の保守負担を抑えやすくなります。

生成AIを使って.NETのシステムを開発しても安全ですか？

補助には使えます。ただし、業務データや秘密情報の入力制限、コードレビュー、脆弱性検査、ライセンス確認、テストを省かないことが条件です。

認証、権限、金額計算、個人情報の処理は、設計者と業務責任者が確認し、承認された手順で本番へリリースします。

まとめ

.NETのシステムは、Web画面やAPI、バッチなどを組み合わせ、会社固有の業務を支える基盤です。デスクトップアプリやデータベース、認証、外部連携も、その構成の一部として組み込めます。

C#やASP.NET Coreの採用を目的にせず、標準化する業務と独自開発する業務を切り分けます。そのうえで、将来の運用まで含めて構成を決めます。

自社で最初に決める3つのこと

まず解決したい業務課題と成果指標を決めます。次に、SaaSやパッケージで標準化する領域と、.NETで独自開発する領域を分けます。

現行システムがある場合は、サポート期限や依存資産、データ品質、業務停止の許容時間を調べます。この3点がそろうと、開発方式と予算の前提を説明しやすくなります。

相談前に準備する資料

相談前に業務とシステムの現状、希望条件をまとめておくと、提案を比べる際の基準がそろいます。

業務情報：現状フロー、利用者・拠点、画面・帳票、外部連携、例外処理。
システム条件：データ件数、権限、希望時期、予算上限、保守体制。
費用比較：初期費用に加えて、移行、クラウド、保守、バージョンアップ費を含めます。

完成した仕様書がなくても、現場の困りごとや例外処理が分かる資料があれば、提案の精度が上がります。

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