Microsoft Teamsのシステム発注は、業務の課題と現状を整理し、要件と責任の範囲を決めてから進めます。同じRFPで委託先を比べ、小さく試行してから展開すると、過剰開発や手戻りを抑えられます。
全体像は、Microsoft Teamsのシステム開発の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・Microsoft Teamsのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Microsoft Teamsのシステム発注・外注の範囲
Teamsのシステム発注では、業務に合わせてテナントやユーザー、チーム、ファイルを設計・構築してもらいます。権限や申請、通知、監査、教育、保守まで任せる点が特徴で、チャットや会議の利用開始だけを頼む発注とは範囲が大きく異なります。
各チームはMicrosoft 365グループを基盤にし、ファイルはSharePointやOneDrive、予定表はExchange Onlineと連動します。そのため、Teamsの画面だけを設定の範囲にすると、権限やデータ管理の設計が漏れるおそれがあります。
業務基盤としてのTeamsの設計
Teamsには、1対1やグループのチャット、チームとチャネル、音声・ビデオ会議があります。また、画面共有、録画、文字起こし、ライブキャプション、ゲストアクセス、ファイルの共同編集も使えます。
Power AppsやPower Automateを使うと、申請・承認を業務に組み込めます。Power BIで状況を可視化することもでき、タブやボットから基幹システムを呼び出すことも可能です。
部門によって、Teamsで扱う業務の中身は変わります。
- 営業部門：案件情報の検索
- 現場部門：写真付きの報告
- 管理部門：会議後のタスク起票
そのため、画面に表示するデータをどこに保管し、誰が読み書きできるかを決めておく必要があります。加えて、退職・異動時の無効化と、会議録や添付ファイルの保存期間も定めます。
Microsoftの導入ガイダンスは、開始・試行・規模展開の段階に分ける考え方を示しています。また、利用シナリオやチャンピオン、教育、サービス正常性のレビューも組み合わせます（出典: Microsoft Learn「Microsoft Teamsを導入する」、2026年8月確認）。
外注範囲の領域と分け方
発注範囲は、企画から保守までの領域と、電話・会議室の有無に分けて確認します。
- 企画・要件：目的の整理から要件定義まで
- 認証・端末：Entra IDのユーザー・グループ、Intuneの管理端末
- Teams・ファイル：チーム・チャネルの作り方と命名、SharePointやOneDriveのファイルと移行
- 保護・連携：Purviewの保持・DLP・監査、Power Platform・Graph API・外部SaaSとの接続
- 利用支援：教育・ヘルプデスク・保守
電話や会議室も対象にする場合は、Teams電話、既存PBX、SBC、ネットワーク、端末機器を別のワークストリームとして加えます。
初期設定だけ、またはアプリ開発だけを依頼する場合も、どこまでを誰が受け持つかを契約書に残します。アプリ所有者の退職後の運用、Power Automateの接続先の更新、Graph APIの権限に同意する人を決めておくと、納品後に特定の担当者しか分からない状態を防げます。
発注形態の選び方
発注形態は、業務を標準化しやすいか、独自要件がどれだけあるか、社内の運用体制はどの程度か、将来の拡張性はどうかで選びます。まずは、標準機能で解決できる範囲を確認します。
標準機能で足りない部分だけをローコードやカスタム開発で補えば、初期費用と保守の負担を抑えやすくなります。小さな業務シナリオを試してから発注すると、発注判断の精度が高まります。
標準機能中心の導入支援
Teams、SharePoint、OneDrive、Planner、Formsなどを設定し、業務を標準機能の使い方に合わせる方法です。安全な会議・チャット・ファイル共有が目的であれば、まず候補に挙げます。
対象にできるのは、テナントの初期設定、チーム作成ルール、ゲスト利用です。会議ポリシー、基本的なファイル構成、管理者教育も対象にできます。なお、少人数のパイロットは2〜6週間程度で進められる場合があります。
- 命名と所有者：命名規則とチームの所有者を決める
- 共有と保持：外部共有と保持期間を定める
- 退職者対応：退職者が関わるチームやファイルの処理を設計する
Microsoftのガバナンス・クイックスタートでは、試行段階ではチームを作る人を限定し、命名やデータセキュリティを確認する考え方が示されています。
早期導入者が業務サイクルを経験する期間の目安として、60日も紹介されています。ただし、試行期間は一律ではありません（出典: Microsoft Learn「Microsoft Teamsのガバナンスのクイックスタート」、2026年8月確認）。
Power Platform連携による業務フローの組み込み
申請・承認、通知、簡易データベース、ダッシュボードには、ローコード型が候補になります。
実装では、Power AppsやPower AutomateにPower BIを組み合わせます。データの保存先には、DataverseやSharePointを組み合わせます。
たとえば、Teamsのチャネルで備品申請を受け付け、承認者へ通知して、結果を一覧にできます。標準機能と組み合わせて段階的に作れるため、既存の業務を大きく変えずに始められます。
作ったあとも業務が止まらないよう、個人への依存や運用の引継ぎを確かめておきます。
- アカウント：作成者の個人アカウントへの依存をなくす
- 環境とデータ：環境間のデータの持ち出しと、DLPの未設定の有無
- 運用の引継ぎ：ライセンス不足、接続情報、所有者、エラー通知、利用者追加時の権限を確認する
発注時には、画面の完成だけでなく、開発・検証・本番の環境を分けておくことも納品の範囲に含めます。
Graph APIやTeamsアプリ開発による独自業務への対応
基幹情報の検索や独自の申請画面が必要な場合は、TeamsアプリやGraph APIが候補になります。ボットやメッセージ拡張、エージェントを作る場合も、候補に入ります。
複数のシステムにまたがる通知では、Azure Functionsなども組み合わせます。
認証やアプリ権限、管理者の同意の設計が欠かせません。API制限、監査ログ、例外処理、データ保護も必要です。そのため、画面を作るだけでなく、業務システム開発として発注します。
- 開発基盤：Microsoft 365 Agents Toolkitが候補
- 退役予定の確認：Graph Toolkitの退役予定を踏まえた採用可否の判断
- 新規開発：古いツールは指定せず、Microsoft Graph SDKなどサポート対象の部品を前提にする
Microsoft 365 Agents Toolkitは、Teams、Outlook、Microsoft 365 Copilot向けの開発を支援します。対象には、アプリやエージェントが含まれます（出典: Microsoft Learn「Microsoft 365 Agents Toolkit」、2026年8月確認）。
Graph Toolkitは2025年9月1日に退役期間へ入り、2026年8月28日に完全退役予定と案内されています（出典: Microsoft Learn「Microsoft Graph Toolkitの概要」、2026年8月確認）。
Microsoft Teamsのシステム発注・外注の進め方
発注は、まず目的を明確にし、現状を把握して要件を整理します。そのうえで提案を依頼し、契約してから、パイロットを経て全社展開へ進み、運用を改善します。
対象ユーザーと業務シナリオを先にそろえておくと、各社の見積もりを同じ条件で比べられます。利用が始まるとチームやファイルが増えていくため、初期構築と運用の設計は同時に進めます。
企画と現状把握による発注目的の設定
まず決めるのは、「Teamsを導入する」という手段ではなく、解決したい業務課題です。改善の対象がメール添付なのか、会議後のタスク漏れなのか、現場報告や拠点間の電話なのかで、必要な機能と発注先が変わります。
発注先に相談する前に、利用規模や既存環境、外部との連携状況を整理しておくと、各社の提案が同じ前提で出そろいます。
- 利用規模：対象人数、拠点数、端末
- 既存環境：Microsoft 365契約、ファイルサーバー、PBX、基幹システム
- 共同作業：外部会社との連携状況
KPIには、利用者数だけでなく、申請から承認までの時間や会議後のタスク登録率を含めます。問い合わせの初回回答時間、ファイル検索時間、不要チームの削減数も設定します。
長崎県庁の事例では、約6,000人の環境で1年間に2,000超のチームが作られ、500〜1,000チームが未使用だと分かりました。このため、利用率だけでなく、作成・利用・終了を測る指標が必要です（出典: AvePoint「長崎県庁様導入事例」、2025年公開）。
要件定義とパイロットによる実現性の確認
要件定義では、業務フローに沿って、利用者の役割、チーム・チャネルの構造、保存先、検索対象を整理します。通知や承認経路、外部共有を決め、スマートフォンと会議録の扱いも定めます。
- 実装方法：標準機能、Power Platform、カスタム開発への振り分け
- 追加要件：後で検討する内容もバックログに残す
- 試行範囲：情シスに加えて、営業・管理・現場などの2〜3業務で試す
試行では、社外ゲストを含むプロジェクト運営や承認フロー、会議録からのタスク化を確かめられます。あわせて、権限、通知、検索、モバイルの使い勝手を確認します。
誰がチームを作るのか、未使用のチームをいつ見直すのかを、試行で確かめます。その結果を、全社展開の前の運用ルールに反映します。
展開・教育・運用の納品後までの設計
全社展開は、部署や拠点ごとに段階を分けて進めます。管理者、チーム所有者、現場のチャンピオンのそれぞれに、支援の内容を分けて提供します。利用ガイドや短時間の操作研修、問い合わせ窓口、障害時の連絡経路も用意します。
利用者がメールやファイルサーバーに戻らないよう、業務の開始点をTeamsに寄せます。そのため、データを移行する前に、移行対象と重複、アクセス権を確認します。さらに、ファイル名や所有者、移行後のリンク切れも確かめます。
納品のあとも、チームの管理や保持、アプリとライセンスの見直しは続きます。
- 日常管理：チーム作成申請、所有者の複数化、メンバー異動、ゲスト確認
- 整理と保護：期限が切れたチームのアーカイブ、保持と削除
- 継続運用：アプリ更新、ライセンスの見直し
たとえば、三菱電機の事例では、4万チームを手作業で作る場合、1チーム30分として約2万時間という試算が紹介されています。
自動払い出しや申請ワークフローは、利用促進と管理作業の削減に向けた要件として、RFPに含めます（出典: AvePoint「三菱電機様Teamsガバナンス事例」、2025年公開）。
RFPと要件整理で明記する内容
RFPは、作るものに加えて、実現したい業務の成果、対象の範囲、責任の分担を伝える資料です。具体的には、ライセンス、既存テナント、利用者数、拠点を同じ形式で渡します。
連携先や移行対象、セキュリティ基準、希望時期、保守条件も、そろえて渡します。条件をそろえておくと、各社の見積もりを同じ条件で比べられます。
利用者・場面・成果で書く業務要件
業務要件には、利用者の役割、場所と端末、入力情報を記載します。加えて、承認者、通知先、完了条件、例外処理も書きます。「申請をTeamsで行う」と書いた場合、必要な機能はまだ絞り込めません。
たとえば、現場担当者がスマートフォンで写真と金額を登録し、所属長が1営業日以内に承認し、経理が承認済みのデータを検索する、というように具体化します。そこまで具体化すると、必要な画面と権限が明確になります。通知、保存先、監査項目も、それに応じて決まります。
- 性能と利用性：応答時間、同時利用者数、可用性、モバイル、アクセシビリティの条件
- 記録と復旧：ログの保存、障害時の復旧、データ削除の条件
- ゲスト運用：招待部署と承認者、有効期限、共有可能なファイル分類、退場時の処理
Microsoft 365の接続関係を含む技術要件
技術要件では、Entra IDの認証方式と条件付きアクセス、グループ同期を書きます。Intune管理端末とSharePointサイトも明記します。
OneDriveやExchange Online、Power Platform環境に加えて、Azure、外部SaaS、基幹システムのAPIも要件に記載します。
Teamsのタブやボットから基幹システムを呼び出す場合は、API認証、最小権限、エラー表示を確認します。さらに、タイムアウト、監査ログ、個人情報のマスキングも見ておきます。
- 情報保護：情報分類、共有範囲、DLP、保持、監査、eDiscovery、バックアップ
- 委託と海外共有：委託先のアクセス、海外拠点とのデータ共有
- Purviewの指定：ライセンス、ポリシー、運用担当を明記する
Purviewの利用範囲はライセンスと構成で変わるため、要件には必要な機能を個別に並べて書きます。
法令対象のデータは、チャットへの添付だけで要件を満たすとは判断せず、法務・情報管理部門と保存、検索、削除の条件を確認します。
成果物と受け入れ条件の事前定義
RFPには、納品する資料を列挙します。まず、要件定義書、業務フロー、テナント設計書、チーム・チャネル設計、権限一覧を挙げます。さらに、セキュリティ設定、アプリ仕様書、テスト計画、移行計画も含めます。
操作マニュアルや運用手順、障害対応表、ソースコード、管理者アカウントの引継ぎも、納品の範囲に含めます。
特に、Power AutomateやTeamsアプリは、社内で修正できるか、ソースや設定値を受け取れるかを確認します。
- 完了シナリオ：申請、承認、部署への通知、監査ログの追跡まで一通り完了できること
- 退職時の確認：ユーザーを無効化した後も、所有者不在のフローが生じないこと
- 検収条件：テストデータ、合格基準、未解決の不具合の扱いの合意
画面の表示だけでなく、代表的な利用シナリオが完了することを受け入れ条件にすると、納品時の認識の違いを減らせます。
契約形態とMicrosoft Teamsのシステム費用相場
費用は、Microsoftライセンスと導入・設計・開発に分けて見積もります。移行・教育、運用保守も、それぞれ別に見積もります。ライセンス費は、ユーザー数と契約プランによって変わります。
導入・開発費は、対象業務、連携数、移行量、セキュリティ、電話や会議室の有無によって変わります。ライセンスだけで発注先を決めると、運用設計や保守が不足し、総額が高くなることがあります。
契約条件をそろえたライセンス費の試算
2026年8月に確認したMicrosoft公式の一般法人向け表示では、Teams Essentialsは1ユーザー月額599円です。この金額は、年契約の月額換算で、税抜の表示です。
Microsoft 365 Business Basicは1ユーザー月額1,049円とされ、Teamsを含む契約として検討できます。また、Teams電話スタンダードは1ユーザー月額1,499円と表示されています（出典: Microsoft「一般法人向けMicrosoft Teamsの価格を比較する」「Microsoft 365プラン選択」、2026年8月確認）。
電話番号や通話プラン、Operator Connectのほか、既存PBX接続や通話料も、別途確認が必要です。
100ユーザー・12か月の条件で単純に計算すると、プランごとの費用の差が見えてきます。
- Essentials：100ユーザーを12か月使う単純計算で約71.9万円
- Business Basic：同条件で約125.9万円
- 電話スタンダード：100ユーザー全員に付ける場合、約179.9万円を追加
実額は、ユーザー種別や年・月契約、共有端末によって変わります。会議室、Copilot、電話番号、販売店の条件でも変わります。
見積書では、税抜か税込か、月額か年額か、全員に付けるか一部に付けるかを、そろえておきます。
作業範囲別の導入・開発費の推定レンジ
Teams専用の全国統一の相場は、公開されていません。そのため、以下の金額は、業務システム一般の公開レンジと、Teams・Microsoft 365案件の作業範囲から見た推定です。
- 標準設定・小規模導入：50万〜150万円、2〜6週間程度
- 既存環境の整理と全社展開：150万〜500万円、1〜4か月程度
- Power Platform・外部SaaS連携：300万〜1,000万円、3〜6か月程度
- Graph APIのアプリなど：800万〜3,000万円以上、4〜12か月程度
- 大規模な周辺環境を含む移行：1,000万〜5,000万円以上、6〜18か月程度となる可能性
Graph API案件の推定には、認証、権限、データモデルに加えて、監査ログとエラー処理も含みます。大規模移行の範囲には、複数テナントや電話、会議室、ネットワークが含まれます。
この金額は、要件を削ったり追加したりしたときの差分を確かめる目安です。個別の見積もりに代わるものとしては扱いません。
一般の業務システムでは、人件費が総費用の約60〜80%を占め、保守運用費は初期開発費の年15〜25%程度とする整理もあります。そのため、初期費用と年間の運用費は並べて判断します（出典: NotebookLM「業務システム全般」Q&A、2026年8月確認）。
要件の確定度に合わせた契約形態
成果物と受け入れ条件を定義できる範囲は、請負契約が候補になります。その場合は、テナント設計書、アプリ、移行、テストなどの成果物、納期、検収条件、修正範囲を明記します。
一方で、探索的な要件定義や継続改善は、準委任や時間精算、月額支援が実態に合う場合があります。また、要件定義を準委任で行い、確定した範囲を請負で構築する段階契約も選べます。
契約書には、外部の仕様変更や権利、終了時の扱いまで書き込んでおきます。
- 外部仕様の変更：Microsoft・外部SaaSの変更、ライセンス値上げ
- サービス上の制約：API制限、テナント障害
- 権利と引継ぎ：知的財産権、ソースコード、管理者権限、再委託、個人情報、秘密保持
- 終了時の条件：セキュリティ事故、サービスレベル、データ返却、保守終了時の引継ぎ
ベンダーが制御できない事象の扱いも、契約で確認しておく必要があります。特に、権利や終了時の条件は、曖昧なままにしないことが大切です。
委託先の選定と見積比較の確認事項
委託先には、Microsoft 365導入会社やTeamsアプリ開発会社、電話・ネットワーク会社、ガバナンス製品の専門会社などがあります。得意とする領域は、会社ごとに異なります。
資格や導入社数だけでなく、必要な領域をどこまで自社で担えるかを確かめます。そのうえで、同じRFPを渡し、提案書の構成もそろえてもらいます。
会社名より似た要件の実績
「Teams導入実績があります」という答えの先まで聞きます。ユーザー数や拠点数、既存テナントを尋ね、ゲストや外部共有、電話についても質問します。ファイル移行や基幹連携も、あわせて確かめます。
パイロット期間、運用体制、導入後の改善も見ます。近い業種や規模の事例について、課題の解決方法、標準機能に合わせた範囲、開発範囲を聞くと、提案の再現性を判断できます。
- ガバナンス：チーム作成申請と、未使用チームの整理の設計経験
- 電話：番号移行、緊急通報、既存PBX、SBC、ネットワーク品質の経験
- 業務アプリ：Graph API権限、アプリ配布、API障害時の運用、ソースと保守体制
得意領域の違いを踏まえて、「Teamsに強い」という一言で比べず、領域ごとに比べることが大切です。
作業・工数・前提条件に分けた見積比較
見積書は、要件定義、設計、環境構築、アプリ開発、連携に分けてもらいます。テスト、移行、教育、管理、保守についても、同じ区分で示してもらいます。
各作業には、担当人数と工数、単価、期間を書いてもらいます。加えて、作業内容と成果物、対象外の作業も確認します。
ユーザー数やチーム数、ファイル容量、移行件数といった数量の前提をそろえます。連携API数や会議室台数、電話番号数も含めて、各社で同じ条件にします。
- 安い見積もり：要件定義、移行、テスト、管理者教育、リリース後の問い合わせが含まれない場合がある
- 高い見積もり：将来使わないカスタム機能や全員分のアドオンが含まれる可能性がある
- 比較総額：必須・できれば欲しい・将来検討に分け、初期費用、年間ライセンス、年間保守、変更単価を5年間で比べる
範囲と費用を分けて比べると、発注後の予算のずれを抑えられます。
保守と社内引継ぎの提案内容
Teamsでは、Microsoft 365の仕様やライセンスの変更、アプリの更新、APIの制限や退役への対応が必要になります。
月額保守の範囲と問い合わせ時間、障害の優先度を確かめます。一次切り分けと、Microsoftへの問い合わせの扱いも確認します。
- 変更対応：設定変更の回数、アプリ改修料金、定例レビュー
- 技術更新：開発部品の利用終了の監視と、移行計画の作成
- 社内引継ぎ：手順書、権限・設定一覧、フロー所有者、ソース、テストデータ、リリース手順、障害連絡先
月次または四半期で、チーム数やゲスト、所有者不在、外部共有を見直します。未使用アプリとライセンスも、同じタイミングで確かめます。
発注の成果には、社内の担当者が安全に変更や判断をできる状態までを含めます。
Microsoft Teamsのシステム発注・外注でよくある質問
費用や期間は、会社の規模、既存環境、移行量、連携要件によって変わります。そのため、以下の金額は一般的な目安として読み、同じRFPで個別の見積もりを取ってください。
Microsoft Teamsは設定だけで業務システムになりますか？
チャット、会議、ファイル共有、タスク管理は、標準機能の設定で始められます。ただし、業務システムとして使うには、権限や保存先、申請経路、通知、監査、運用ルールも必要です。
既存の業務を標準機能に合わせられる場合は、設定を中心に進めます。独自のデータ処理や基幹連携が必要になったときに、Power PlatformやGraph APIの開発を追加します。
Microsoft Teamsのシステム外注費はいくらですか？
標準設定・小規模導入は50万〜150万円、既存環境の整理と全社展開は150万〜500万円が推定のレンジです。
Power Platform連携は300万〜1,000万円、Graph APIの業務アプリは800万〜3,000万円以上です。
これらは、要件や規模、移行、保守を含めた作業範囲の目安です。Teams専用の公定価格ではありません。Microsoftライセンス、電話、通話料、保守を分けて、税抜か税込か、契約期間を確認します。
何社に見積もりを依頼すればよいですか？
比べられる状態をそろえたうえで3社程度に依頼すると、価格と提案の違いを見比べやすくなります。得意な領域は、電話・ネットワーク、Microsoft 365、Teamsアプリ、ガバナンス製品などで会社ごとに異なります。
候補の数を増やすより先に、RFPをそろえます。そのうえで、標準機能や開発を選んだ理由、保守の責任の分け方、社内に残す作業を説明できる会社を選びます。
まとめ：Microsoft Teamsのシステム外注は運用まで含めた発注
発注時は、Teamsの設定費だけでなく、Microsoft 365全体の認証やファイル、会議、端末を整理します。さらに、セキュリティや業務連携、教育、保守も、発注の範囲として分けて考えます。
標準機能、Power Platform、Graph APIやカスタムアプリのそれぞれで、必要な範囲を決めます。そのうえで、小さな業務シナリオから試し、全社へ広げると、過剰開発や手戻りを抑えられます。
発注前のRFPと比較軸の統一
RFPには、目的や対象ユーザー、業務シナリオ、既存環境を記載します。加えて、チーム・ファイル・ゲスト・電話・連携の範囲を書きます。セキュリティや成果物、受け入れ条件、保守条件も書きます。
見積もりは、初期費用だけでなく、ライセンス、移行、教育、年間保守、追加変更を含めた5年間の総額で比べます。さらに、似た規模の実績と、社内で運用や変更を続けられる引継ぎ体制も確かめます。
使われ続ける仕組みという外注の成果
Teamsでは、チームの作成や異動、ゲスト管理を継続して行います。見直しやアーカイブ、データ保持も欠かせません。不要なチームや所有者不在を放置すると、検索性と安全性が下がります。
発注の時点で、運用責任者や定例レビュー、教育、保守、Microsoftの仕様変更への対応を決めておきます。そのうえで、社内で安全に管理しながら、業務の成果と安全性を両立できる仕組みを育てます。
▼全体ガイドの記事
・Microsoft Teamsのシステム開発の完全ガイド
▼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を創業。