Microsoft Teamsのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Microsoft Teamsのシステム開発は、Teamsの設定だけで終わらせず、Microsoft 365全体の認証・ファイル・権限・業務アプリ・運用を6つのフェーズで設計することが成功の近道です。

チャットやWeb会議を始めたい企業だけでなく、申請・承認、現場報告、営業案件の検索、会議後のタスク起票、社外メンバーとの共同作業までTeamsに集約したい企業が増えています。一方で、チームが乱立する、機密ファイルが外部共有される、退職者やゲストが残る、標準機能と開発の境界が分からないといった問題も起こります。本記事では、要件整理から定着化までの進め方、標準・ローコード・カスタムの判断基準、費用相場、見積もりのチェックリストを実務目線で解説します。

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

Microsoft Teamsのシステム開発とは何ですか?

Microsoft Teamsのシステム開発の全体像を整理する担当者

Microsoft Teamsのシステム開発とは、チャットや会議の設定に加えて、ユーザー・認証、チームとチャネル、ファイル保存、予定表、端末、セキュリティ、業務データ連携を一つの業務基盤として設計することです。TeamsのファイルはSharePointやOneDrive、会議や予定表はExchange Online、ユーザーとアクセス権はMicrosoft Entra IDと関係するため、画面だけを見ていると設計漏れが生じます。

Teams単体ではなくMicrosoft 365全体を設計します

Teamsは、人・会話・会議・ファイル・業務アプリを集める入口です。ファイルの保存場所をSharePointのチームサイトにするのか、個人作業をOneDriveに残すのか、社外共有を許可するのか、会議録やチャットをどの期間保持するのかを決めなければ、利用者は便利でも管理者には扱いにくい環境になります。Microsoft Entra IDのグループとTeamsのメンバーをどう連動させるか、異動や退職時に誰が更新するかも最初に決めます。

業務システム化の範囲は、申請・承認をPower AppsとPower Automateで作る、案件データをDataverseや既存基幹システムと連携する、Teamsのタブやメッセージ拡張で検索画面を提供する、といった形で広がります。最初から全機能を開発するのではなく、業務効果が大きく、利用者が明確な2〜3業務をパイロットに選ぶと、必要な開発範囲を判断しやすくなります。

導入設定と業務システム開発の境界を分けます

テナントの初期設定、ユーザー登録、MFA、チーム・チャネルのルール、基本ポリシー、管理者教育は導入作業に近い領域です。独自の承認経路、複数システムのデータ照合、業務データの検索画面、自動的なチーム払い出し、AIエージェントの回答制御は開発領域に近くなります。見積書でこれらが一つの「Teams導入費」にまとめられている場合は、設定、移行、開発、テスト、教育、保守に分けて記載してもらいます。

開発の目的はTeamsを高機能にすることではなく、業務の処理時間や情報検索の負担を減らすことです。たとえば「会議をTeamsに移す」だけでは成果を測りにくいため、「会議後24時間以内のタスク登録率を上げる」「問い合わせの初回回答までの時間を短くする」のように、利用行動と業務指標を結び付けます。これが後の要件整理、テスト、定着化の基準になります。

Microsoft Teamsのシステム開発はどのように進めますか?

Microsoft Teamsのシステム開発の進め方を検討する会議

基本の進め方は、要件整理、選定、設計・開発、テスト、稼働、定着化の6フェーズです。Microsoft Learnの導入ガイダンスも、開始、試行、規模展開という段階を示しており、最初から全社へ一括展開するより、現実の業務で試してから広げる考え方が基本です(出典: Microsoft Learn「Microsoft Teamsを導入する」、2025年更新)。以下では各フェーズの目的、成果物、完了前のチェック項目を整理します。

フェーズ1:要件整理で業務・利用者・データを決めます

最初に、導入目的を「Teamsを使う」から「誰のどの作業をどう改善するか」へ置き換えます。対象部門、利用者の種類、拠点数、同時利用、処理件数、既存のメール・電話・ファイルサーバー、紙やExcelの業務、外部ゲストの有無を洗い出します。現場ヒアリングでは、理想の機能だけでなく、例外処理、承認者の不在、スマートフォン利用、通信が不安定な場所、保存期間まで確認します。

要件整理の成果物は、業務フロー、利用者・権限一覧、データ分類、移行対象一覧、連携先一覧、成功指標、必須・希望・将来の優先順位です。チェック項目は、正データの所在が決まっているか、個人情報や機密情報の扱いが明確か、チーム作成者と所有者が決まっているか、外部共有の条件があるか、成功を測る数値があるかです。ここで曖昧なまま「便利な機能」を追加すると、後で開発費とテスト範囲が膨らみます。

フェーズ2:選定で標準・ローコード・カスタムを比較します

要件を、TeamsやSharePointなどの標準機能、Power Apps・Power Automateなどのローコード、TeamsアプリやGraph APIを使うカスタム開発に振り分けます。文書共有や会議、一般的なタスク管理は標準機能を優先し、条件分岐のある申請や通知はローコードを検討します。複雑なデータモデル、大量処理、外部公開、既存基幹システムとの厳格な連携は、DataverseやAzure、APIを組み合わせる候補です。

比較する観点は、初期費用だけではありません。ユーザー数、データ量、API制限、標準コネクタの有無、認証方式、権限管理、監査ログ、障害時の再実行、運用担当者のスキル、3年後の拡張性を並べます。標準機能に業務を寄せられるなら短納期になりやすく、独自業務を残すほど開発の自由度は上がりますが、更新対応や保守の責任も増えます。

フェーズ3:設計・開発で権限と運用まで具体化します

設計では、チーム・チャネルの命名規則、作成申請、所有者、メンバー追加、ゲストアクセス、外部共有、ファイル保存先、保持期間、退職・異動時の処理を決めます。機密度に応じて公開・組織内・限定・外部共有可などの分類を用意し、誰でも自由に作れる範囲と管理者の承認が必要な範囲を分けます。Entra ID、Intune、Purviewを使う場合は、ユーザー認証、端末条件、保持・DLP・監査の責任分界も設計書に残します。

開発では、画面、データ項目、状態、承認ルート、通知、エラー処理、ログ、再実行、バックアップ、管理者権限を定義します。Teamsアプリを作る場合は、Microsoft 365 Agents Toolkit、Teams SDK、Microsoft Graph SDKなど、公開時点でサポートされるツールを確認します。Microsoft Learnは新しいTeamsアプリやエージェント開発にAgents Toolkitを推奨しており、Graph Toolkitは2026年8月28日の完全退役予定が案内されています(出典: Microsoft Learn「Teamsアプリを構築するためのツールとSDK」「Microsoft Graph Toolkit overview」、2026年確認)。旧ツールを前提にした開発は、移行費を含めて評価します。

フェーズ4:テストで正常系以外の失敗を確認します

テストは、画面が表示されるかだけでなく、業務が最後まで流れ、見せてはいけない情報が表示されず、失敗から復旧できるかを確認する工程です。単体テスト、連携テスト、権限テスト、移行テスト、利用者による受け入れテストを分け、テストケース、期待結果、実施者、合否、未解決課題を記録します。パイロットでは、実際の2〜3業務を使い、利用者が説明書なしでどこまで処理できるかも見ます。

最低限、承認者の不在、差し戻し、同時更新、重複送信、添付容量超過、通知失敗、API停止、ネットワーク切断、移行データの欠損、退職者アカウント、権限のない利用者、ゲストのアクセス遮断を試します。会議録やAIエージェントを扱う場合は、機密文書を意図せず参照しないか、回答の根拠を確認できるか、誤回答時に利用者が判断できるかも確認します。

フェーズ5:稼働で移行・切り替え・問い合わせを準備します

稼働前には、本番テナント、ユーザー、ライセンス、端末、チーム、サイト、アプリ、フロー、連携先を確認し、移行するデータと移行しないデータを確定します。既存ファイルをすべてコピーするのではなく、所有者、重複、最終更新日、機密度、保存期間、検索要件を確認し、不要なデータを整理してから移します。移行前後の件数照合、バックアップ、切り戻し条件を用意すると、問題が出たときに判断しやすくなります。

全社一括展開と、部門・拠点ごとの段階展開を比較します。段階展開では、パイロット部門の利用率だけでなく、申請処理時間、検索時間、エラー件数、問い合わせ件数、未使用チーム数を測定し、合格基準を満たしてから対象を広げます。告知文、操作説明、問い合わせ窓口、障害時の連絡網、旧環境をいつ停止するかまで決めておくと、稼働日に現場が迷いにくくなります。

フェーズ6:定着化で使われ続ける状態を作ります

稼働しただけでは、利用者がメールや個人フォルダーへ戻る、同じ用途のチームが増える、所有者が不在になるといった問題が起こります。業務別の短い研修、現場のチャンピオン、FAQ、問い合わせ窓口、月次または四半期の棚卸しを組み合わせます。管理者だけが使い方を知る状態ではなく、各部門がチーム作成、メンバー更新、ファイル共有、削除申請を自分で判断できるようにします。

定着化のKPIは、ログイン数だけでなく、申請処理時間、紙の削減量、会議後のタスク完了率、検索時間、承認の滞留、問い合わせ件数、不要チームの割合など業務成果に置きます。長崎県庁の事例では、約6,000人の職員が利用する環境で、年間に約1,000人の人事異動があり、チームメンバーの更新準備だけで1週間程度かかっていました。また、使われていないチームが500〜1,000ほど発生していたと紹介されています(出典: AvePoint「長崎県庁様導入事例」、2025年公開)。この事例は、利用促進と同時に棚卸し・異動・ゲスト管理を設計する必要性を示しています。

標準機能・ローコード・カスタム開発はどう選びますか?

Microsoft Teamsの開発方式を比較する担当者

方式は「標準機能で足りるか」「Power Platformで追加できるか」「TeamsアプリやAzureの開発が必要か」の順に検討します。安価そうだから標準機能、自由度が高そうだからスクラッチという決め方ではなく、業務の独自性、データの複雑さ、セキュリティ、利用規模、運用体制を合わせて評価します。

標準クラウドは短期間で始めたい場合に向いています

Teams、SharePoint、Planner、Formsなどの標準機能を設定し、業務を既存の機能に合わせる方法です。チャット、会議、ファイル共有、簡単なタスク管理、定型的な情報収集が目的なら、標準機能を優先すると数週間から2か月程度でパイロットを始めやすくなります。チーム作成、所有者、命名、ゲスト、外部共有、保持期間のルールを先に決めることが条件です。

標準機能の注意点は、業務固有の細かな分岐や基幹システムの複雑なデータ処理に無理に合わせると、現場の手作業が残ることです。標準で対応できる範囲と、対応しない範囲を要件定義書に明記し、将来の追加開発候補として残します。最初から全社のすべてを移すより、目的が明確な部門で効果を測る方が失敗を発見しやすくなります。

ローコードは申請・通知・集計を段階的に追加したい場合に向いています

Power Appsで入力画面を作り、Power Automateで承認・通知を流し、SharePointやDataverseにデータを保存する構成です。Teamsの画面から申請状況を見たり、承認依頼を受けたりできるため、紙・メール・Excelを置き換える小規模な業務改善と相性があります。複数部門で使う場合は、開発環境と本番環境の分離、DLPポリシー、接続先の管理、アプリやフローの所有者を設計します。

ローコードでも、作成者が異動したときの引き継ぎ、失敗したフローの再実行、ライセンス、データ容量、同時実行、監査ログを確認します。要件が3〜6か月程度の段階導入で実現できるなら有力ですが、大量データ、複雑なトランザクション、厳格な可用性が必要な処理はAPIやAzure側へ分離した方が保守しやすくなります。

カスタムTeamsアプリは独自業務と大規模連携に使います

タブ、ボット、メッセージ拡張、通知、エージェント、Graph API連携によって、Teamsを業務ポータルの入口にする方法です。営業案件、問い合わせ、社内規程、現場写真、会議後のタスクなど、利用者がTeamsから離れずに既存システムの情報を参照・登録できるようになります。独自性は高い一方、認証、権限、データモデル、監査ログ、API制限、障害監視、Microsoftの仕様変更への対応まで必要です。

2026年時点で新規開発を検討するなら、Microsoft 365 Agents ToolkitやTeams SDK、Microsoft Graph SDKなどのサポート状況を確認し、旧TeamsFxやGraph Toolkitに依存しない方針をRFPに入れます。AIエージェントを採用する場合は、回答の根拠、参照可能なデータ範囲、個人情報のマスキング、誤回答時の人による確認、ログ保存を要件にします。画面を作るだけの見積もりでは、実運用の安全性が不足します。

Microsoft Teamsのシステム開発費用相場はいくらですか?

Microsoft Teamsのシステム開発費用を見積もる担当者

費用は、ライセンス、導入設定、業務アプリ開発、移行、教育、運用保守に分けて考えます。MicrosoftがTeams専用の全国統一開発価格を公開しているわけではないため、下記の導入・開発費は、一般的な業務システムの費用情報とTeams案件の作業範囲を組み合わせた推定レンジです。ユーザー数、チーム数、拠点、移行量、電話、セキュリティ、保守時間で変わるため、予算検討の起点として扱い、固定価格と断定しないことが大切です。

ライセンス費はユーザー種別と追加機能で変わります

Microsoft公式の一般法人向け表示では、Microsoft Teams Essentialsが1ユーザーあたり月額599円、Microsoft 365 Business Basicが1ユーザーあたり月額1,049円です。年契約の月額換算で、税抜表示です(出典: Microsoft公式「一般法人向けMicrosoft Teamsの価格を比較する」、2026年8月確認)。Teams電話スタンダードは1ユーザーあたり月額1,499円と表示されていますが、電話番号、通話プラン、Operator Connect、Direct Routing、通信事業者、既存PBXとの接続は別途設計が必要です。

100ユーザーで単純計算すると、Teams Essentialsは月額5万9,900円、年間約71万8,800円です。Business Basicは月額10万4,900円、年間約125万8,800円です。Teams電話スタンダードを100ユーザーに付ける場合は月額14万9,900円、年間約179万8,800円の追加となります。ただし、管理者、現場、会議室、共有端末、外部ユーザー、電話利用者で必要なライセンスは異なります。Copilot、Teams Premium、会議室、通話料、Azure従量課金などを含めると変動するため、役割別のライセンス表を作ります。

導入・開発費は50万〜5,000万円以上まで広がります

標準設定・小規模導入は50万〜150万円程度、期間は2〜6週間程度が目安です。テナント初期設定、チーム・チャネル方針、基本ポリシー、管理者説明、少人数のパイロットを含む想定です。既存Microsoft 365の整理と全社展開は150万〜500万円程度、期間は1〜4か月程度で、Entra ID、Intune、SharePoint、OneDrive、ゲスト管理、命名、棚卸し、教育、段階展開などを含めます。

Power Platformによる申請・承認、通知、Teamsタブ、DataverseやSharePointとの連携は300万〜1,000万円程度、期間は3〜6か月程度が目安です。Graph APIを用いたTeamsアプリ、ボット、業務ポータルは800万〜3,000万円以上、期間は4〜12か月程度になる場合があります。大規模移行、複数テナント、電話、会議室、複数拠点、BCP、24時間運用まで含める場合は、1,000万〜5,000万円以上、6〜18か月程度の計画になる場合があります。いずれも特定企業の定価ではなく、リサーチノートに基づく推定レンジです。

ランニングコストは保守・通話・棚卸しまで見込みます

初期費用だけでなく、ユーザーやグループの追加・削除、チーム作成申請、ゲストの再承認、保持期間の変更、DLPや監査ログの確認、問い合わせ、データ移行の追加、Power AutomateやAPIの障害対応を見込みます。カスタムアプリでは、Azureの実行環境、ログ、監視、バックアップ、証明書やシークレットの更新、Graph APIやSDKの仕様変更への追随も保守範囲に入ります。一般的な業務システムでは保守運用費が初期開発費の年15〜25%程度という整理もありますが、Teamsの利用規模と契約範囲で変わるため、参考レンジとして扱います(出典: NotebookLMリサーチノート「Microsoft Teamsのシステム」、2026年8月)。

電話を含む場合は、Teams電話スタンダードのライセンスに加えて、番号、通話プランまたは通信事業者、SBC、端末、ネットワーク、番号移行、緊急通報、録音、FAXや既存PBXとの併用を確認します。会議室を含む場合は、Teams Roomsのライセンス、認定デバイス、設置工事、保守も別枠にします。見積総額の比較では、初期費用、月額ライセンス、月額保守、従量課金、追加変更の単価を分けて表示してもらいます。

Microsoft Teamsの見積もりを取る際のポイント

Microsoft Teamsの見積もり内容を確認する担当者

相見積もりでは、単価の安さよりも、同じ前提条件で比較できるかを重視します。ユーザー数やライセンスだけでなく、対象チーム数、移行データ、ゲスト、電話、拠点、既存システム、セキュリティ、教育、保守時間をそろえて提示します。作業範囲が異なる見積書を総額だけで比較すると、安い提案に重要な移行や運用が含まれていないことがあります。

RFPにはユーザー・データ・連携・運用を具体的に書きます

依頼書には、目的、対象業務、ユーザー数と種類、部門・拠点、チーム・チャネル数、既存のMicrosoft 365契約、Entra IDやIntuneの有無、移行元、ファイル容量、ゲスト利用、外部共有、電話、会議室、基幹システムやSaaSとの連携、必要な監査・保持・DLP、希望時期を記載します。業務フローとサンプルデータがあると、ベンダーが標準・ローコード・カスタムの判断をしやすくなります。

成果物もRFPに書きます。要件定義書、テナント設計書、権限一覧、命名規則、移行計画、テスト仕様書、操作マニュアル、管理者教育、運用手順、ソースコード、設定値、障害時の連絡先、引き継ぎ資料を納品対象にします。特にPower Platformのアプリやフロー、Teamsアプリの所有者と管理者権限を発注者側へ移せるかを確認し、担当者個人のアカウントに依存する状態を避けます。

導入会社と開発会社の対応範囲を確認します

Teamsの初期設定が得意な会社と、Graph APIやAzureで業務アプリを開発できる会社は同じとは限りません。全社展開ならEntra ID、Intune、Purview、SharePoint、教育、運用まで扱えるかを確認し、電話を含むならネットワーク、SBC、番号移行、緊急通報の実績を確認します。連携開発なら、認証・権限、API、データ移行、監視、障害対応、Microsoftの更新への追随を誰が担うかを質問します。

候補会社には「同じ規模のTeams運用で、チーム乱立やゲスト管理をどう防いだか」「異動時のメンバー更新をどう自動化したか」「標準機能に寄せた範囲と独自開発した範囲」「本番後の月次作業」「担当者が退職した場合の引き継ぎ」を聞きます。Microsoft認定や導入社数だけで決めず、今回の要件に近い成果物、体制、保守窓口、費用の前提を確認します。

チーム乱立・外部共有・仕様変更のリスクを見積もります

Teamsは使い始めやすい反面、自由にチームを作れる状態にすると、似たチームが増え、古いファイルやゲストが残ります。長崎県庁の事例のように、導入初期は利用を優先しても、後から棚卸しや人事異動対応の負担が表面化します。チームの作成申請、目的、所有者、利用期限、最終確認日、削除・アーカイブの承認者をあらかじめ決め、見積もりに棚卸しの仕組みを含めます。

機密情報を扱う場合は、条件付きアクセス、多要素認証、端末管理、外部共有制御、保持、DLP、監査ログ、eDiscovery、管理者権限の分離を確認します。個人情報や証憑をチャットや添付ファイルで扱う場合は、保存場所、保存期間、検索性、削除、開示請求、基幹システムとの責任分界を別途整理します。Microsoft 365の機能があることと、社内規程に沿って正しく設定・運用できることは別なので、誰が設定し、誰が定期確認するかを契約へ記載します。

Microsoft Teamsのシステム開発でよくある質問

Microsoft Teamsのシステム開発について相談する担当者

Microsoft Teamsの導入や開発を検討すると、「Teamsだけ契約すればよいのか」「どこまで外注するのか」「開発会社へ何を伝えるのか」といった疑問が生じます。ここでは、初期検討で特に相談の多い質問へ直接回答します。

Microsoft Teamsはライセンスを契約するだけでシステムになりますか?

なりません。ライセンス契約でチャット、会議、ファイル共有などを使い始められますが、業務システムとして使うには、認証、権限、チーム作成、ファイル保存、保持、外部共有、教育、運用ルールの設計が必要です。申請や基幹システム連携など独自処理が必要なら、Power Platformやカスタムアプリの開発を追加で検討します。

小規模企業はどのフェーズから始めればよいですか?

まず要件整理で、対象部門、使う業務、ユーザー、保存したいデータ、外部共有の有無を決めます。その後、2〜3個の現実の業務を選び、標準機能でパイロットを実施し、利用者の反応と運用負荷を測ってから全社展開します。小規模でも所有者、ゲスト、命名、削除・棚卸しを決めておくと、後から整理する費用を抑えやすくなります。

Teamsアプリを開発するのはどのような場合ですか?

Teamsの標準機能やPower Platformでは、業務固有の検索、複雑なデータ連携、大量処理、独自の画面、エージェント、既存システムとの厳格な連携を満たせない場合に検討します。開発前に、標準機能でできない要件、利用者、データ、権限、監査、障害時の動きを明確にします。アプリ本体だけでなく、認証、API、ログ、監視、保守、将来のSDK移行まで含めた見積もりが必要です。

Teamsのチャットやファイルは安全に管理できますか?

管理できますが、製品の機能を有効にするだけでは不十分です。機密度に応じたチームとファイルの分類、多要素認証、端末管理、外部共有の制御、保持期間、DLP、監査ログ、eDiscovery、退職・異動時のアカウント処理を設計し、定期的に確認します。個人情報や法令に関係する証憑を扱う場合は、保存場所、検索性、改ざん防止、削除、社内規程との整合性を専門部署と確認します。

まとめ

Microsoft Teamsのシステム開発計画をまとめる担当者

Microsoft Teamsのシステム開発では、Teamsを導入すること自体をゴールにせず、業務課題、利用者、データ、権限、運用責任を先に整理します。要件整理、選定、設計・開発、テスト、稼働、定着化の6フェーズに分け、各段階で完了条件を確認すると、設定と開発の境界や、必要な費用を説明しやすくなります。

6フェーズで小さく始め、運用まで含めて広げます

標準機能で足りる範囲は標準機能を使い、申請や通知はローコード、独自業務や複雑な連携だけをカスタム開発に分けると、初期費用と保守負担を調整しやすくなります。費用相場は標準設定・小規模導入の50万〜150万円程度から、大規模移行や複数テナント、電話、独自開発を含む5,000万円以上まで幅があります。ライセンス、開発、移行、教育、保守を分け、同じ前提のRFPで比較してください。

使われ続けるためのガバナンスを最初から組み込みます

チームの乱立、ゲストや退職者の残存、ファイルの保存先、チャットや会議録の保持、仕様変更への対応は、導入後に後回しにすると大きな運用負担になります。作成申請、所有者、利用期限、棚卸し、教育、問い合わせ、障害対応を最初から設計し、利用率だけでなく処理時間や検索時間などの成果で改善を続けることが、Microsoft Teamsを業務システムとして定着させるポイントです。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。