SharePointのシステム開発の完全ガイド

SharePointのシステム開発は、社内ポータル、文書管理、検索、業務アプリを一つの基盤にまとめる取り組みです。

OnlineとServer、標準機能と追加開発、情報管理と業務フローを整理すると、情報を安全に集約できます。各テーマの詳細は関連記事もご覧ください。

▼関連記事一覧
・SharePointのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・SharePointのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・SharePointのシステム開発の見積相場や費用/コスト/値段について
・SharePointのシステム開発の発注/外注/依頼/委託方法について

SharePointのシステムの概要

SharePointを中心に、社内ポータル、文書ライブラリ、検索と台帳、業務アプリを配置した図。
情報の保管から業務アプリまでを一つの基盤でつなぎます。

SharePointは、ページ、文書ライブラリ、台帳リスト、全文検索、アクセス権限を組み合わせるサービスです。社内ポータルのほか、共同作業、申請受付、文書承認、ナレッジ蓄積にも使えます。

システム開発では、標準機能を業務に合わせて設計し、不足する部分だけを安全に拡張するのが基本です。

社内ポータル・文書管理・業務アプリをつなぐ基盤

社内ポータルを起点に、文書を管理し、申請や分析までつなぐ構成です。

  • 社内ポータル:ニュース、規程、業務マニュアル、申請への入口
  • 文書ライブラリ:版履歴、承認状態、作成者、更新日、文書種別
  • 検索と台帳:部門・文書種別・対象期間・公開範囲を列やタグで絞る。Microsoft Listsで申請・設備・契約を管理
  • 業務アプリ:Power Automateの通知・承認、Power Appsの入力画面、Power BIで申請件数・処理日数を見られるようにする

SharePointは、情報を保管するだけでなく、発生、承認、公開、検索、分析を連続させる基盤になります。

TeamsやOneDriveとの違い

三つのサービスは、用途に応じて次のように役割を分けて連携します。

  • SharePoint:組織やチームの情報を構造化し、公開・管理する。Teamsチャネルのファイルも保存する
  • Teams:会話や会議を中心にチームで仕事を進める窓口。プロジェクトファイルを扱う
  • OneDrive:個人の作業中ファイルや下書きを保存し、必要に応じて共有する

全社規程や正式な手順書は、ポータルの文書ライブラリに置く方法があります。ただし、同じファイルを複数の場所へコピーすると、最新版が分からなくなります。さらに、検索や生成AIの回答にも、重複や古い情報が混ざります。

混乱を防ぐには、誰が何の目的でどの期間使う情報かを最初に決めておきます。

SharePointの種類とシステム構成の選び方

SharePointは、クラウドのSharePoint Onlineと、自社設備で運用するSharePoint Serverに分かれます。

構成は、標準機能だけで作るか、Power Platformで業務フローを補うか、SPFxやAPIで独自画面を加えるかを、段階的に判断します。方式は、情報の機密性と既存資産、運用体制を比べ、カスタマイズがどれだけ必要かを見て決めます。

SharePoint Onlineが向いているケース

SharePoint Onlineの特徴と、導入後に利用企業が担う設計事項は、分けて捉えます。

  • 基盤管理:サーバー設置、OS・ミドルウェアのパッチ、可用性管理を自社で抱えずに始められる
  • 連携と展開:Microsoft 365、Teams、OneDrive、Entra IDと認証・共同編集をつなぎ、ポータルや文書管理を段階的に広げやすい
  • アクセス:拠点や在宅勤務者が多い場合も、ネットワーク経由で同じ情報を利用しやすい

安全性は、クラウドに置いた後の設計で決まります。外部共有の設定やダウンロード、端末の扱いは利用企業が設計し、保存期間と削除ルールも利用企業が決めます。

費用は総保有コストで比べます。ライセンスに加えて、追加ストレージやバックアップ、監査、運用支援の費用も含めます。

SharePoint Serverを比較するケース

SharePoint Serverは、自社環境での運用要件がある場合に比較します。選定時は、次の条件と負担を確認します。

  • 比較する条件:ネットワーク分離、データ配置、既存オンプレミス資産、社内規程
  • 維持できる点:既存環境との連携
  • 継続管理:サーバー、データベース、バックアップ、監視、障害対応、アップグレード、ライセンス
  • 新規ポータル:Onlineを第一候補とし、Serverを選ぶ理由を要件表に明記する

特別な制約がないままオンプレミスを選ぶと、構築費に加えて毎月の運用工数と更新時の検証費が増えます。

既存業務システムが社内ネットワーク内にある場合は、接続方式や連携の実現性を先に検証します。

標準機能・Power Platform・SPFxの使い分け

業務に必要な機能ごとに、標準機能から順に拡張方法を選びます。

  • 標準機能:サイト、ページ、ライブラリ、リスト、標準検索、標準権限で業務を表現できるか確認する
  • Power Platform:入力画面や承認が不足する場合はPower AppsとPower Automateを検討する
  • 独自拡張:複雑な画面や独自Webパーツ、深い連携にはSPFx、Graph、REST APIを比べる

公式資料では、SPFxはSharePoint、Teams、Viva Connectionsの推奨拡張モデルとされています(出典: SharePoint Frameworkの公式概要、2026年8月確認)。

SPFxはTypeScriptやJavaScriptなど一般的なWeb技術を使えます。ただし、独自コードのテスト、脆弱性対応、API変更への追随が必要です。

独自開発を入れる場合は、作れるかどうかに加えて、3年後の保守担当者も決めておきます。

ポイント

方式は、Onlineを第一候補にしたうえで、自社環境での運用要件がある場合にServerを比べます。機能は標準機能から始め、Power Platform、SPFxの順に拡張を検討します。

SharePointのシステム開発の進め方

SharePoint導入の4工程として、目的と現状、サイト・ライブラリ・権限、PoCと移行、テスト・教育・リリース後の定着を並べた図。
設計と小規模な検証を挟んでから展開へ進みます。

SharePoint導入では、目的や対象データ、権限を定め、検索、移行、教育、運用まで決めたうえで、小さく検証してから広げます。テナントにサイトを作るのは、その一部です。

何を置くかを先に決めておかないと、画面を作ったあとに権限やデータ移行で手戻りが起きやすくなります。

目的と現状の棚卸し

導入目的を測る指標と、移行対象を決めるための情報を洗い出します。

  • 改善指標:検索時間、申請処理日数、最新版にたどり着けない件数、問い合わせ件数
  • データの所在:ファイルサーバー、旧グループウェア、Teams、個人PC、既存ポータル
  • 確認項目:保有部門、管理者、利用者、機密度、保存期限、外部共有の有無、更新頻度
  • 移行前の整理:重複、期限切れ、所有者不明、用途のない個人情報を含むデータを分ける

不要なデータを先に分けておくと、移行容量やテスト件数、権限設定を減らせます。

現状一覧、移行対象、廃棄候補、サイト構成案、KPIを資料として残すと、見積もりの前提が明確になります。

サイト・ライブラリ・権限の設計

設計では、サイトやライブラリをどの単位で分けるか、権限をどう持たせるかを決めます。

  • サイト:全社、部門、プロジェクトなど目的ごとに分け、各サイトに所有者を置く
  • ライブラリ:文書のライフサイクルや利用者が近い単位で設け、文書種別・公開範囲を列やタグで管理する
  • グループ:サイト、Microsoft 365、Entra IDグループの関係を図にする
  • 利用者:所有者、メンバー、閲覧者を一覧で確認できるようにする
  • 公開範囲:社外共有、ダウンロード制限、承認済み文書の置き場所を分ける

個別ファイルへの例外権限を増やすと、異動や退職時の確認が増え、検索や生成AIの参照範囲にも差が出ます。そのため、サイトまたはライブラリ単位でグループに付与するほうが運用しやすいです。

小さく始めるPoCと移行

全社展開の前に小さく検証し、移行対象と品質を確認します。

  • PoC対象:把握しやすい1部門、1ポータル、1種類の申請などに絞る
  • 合格基準:目的の文書を検索でき、想定権限で見え、承認が滞留しないこと
  • 保持:版履歴とメタデータを必要な範囲で保つ
  • 移行項目:所有者、更新日、版、権限、保持期間、リンク、検索用メタデータを確認する

PoCの合格条件には、ページが表示されるかどうかだけでなく、検索や権限、承認の動きまで含めます。

公開事例には、160GBのデータや100個超のデータベースを複数サイトへ移した例があります。こうした大規模な移行では、変換、検証、利用者教育を工程として分けます(出典: 2026年公開のソフトウェア開発導入事例、2026年確認)。

テスト・教育・リリース後の定着

リリース前は、テストの範囲と資料、リリースの準備を分けて確認します。

  • テスト範囲:機能、権限、検索、通知、承認、外部共有、スマートフォン表示、負荷、バックアップからの復元
  • テスト資料:見える文書の非表示や非公開文書の検索表示を防ぐため、役割別アカウントと具体的な文書サンプルを用意
  • リリース準備:管理手順、検索・共有手順、問い合わせ窓口、障害時の連絡先

個人情報や機密文書は、本番データをそのまま検証環境へコピーしない運用が安全です。

リリース後30日は利用率と検索失敗、60日は権限と不要サイト、90日はKPIと運用工数を評価します。サイト所有者が自分で運用できる状態まで、開発範囲に含めます。

ポイント

何を置くかを決めずに画面を作ると手戻りが起きやすいため、目的と現状の洗い出し、権限設計を先に済ませます。全社展開の範囲は、PoCの結果を見てから決めます。

SharePointのシステム開発費用相場とコストの内訳

SharePointの導入規模別の初期費用目安を示す横棒図。小規模は100万〜300万円、中規模は300万〜1,000万円、大規模は1,000万〜3,000万円以上。
規模ごとに費用帯が重なり、要件によって幅があります。

費用は、ライセンス、導入・開発、移行を中心に考えます。残りの費用は、下の項目で確認します。

  • 教育:利用者教育の費用
  • 保守・運用:稼働後の運用支援の費用

ライセンスだけを見て安いと判断すると、権限整理やデータ移行、利用者教育が別料金となり、総額が想定を超えることがあります。

この目安は、2026年時点の公開情報と一般的な業務システム案件を基にしています。契約条件や要件によって変わります。

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

ライセンス費と契約プラン・人数による違い

公式比較ページに掲載された、一般法人向けの年契約・年払いの月額相当の価格です。いずれも税抜です(出典: Microsoft 365公式プラン比較、2026年8月確認)。

  • Microsoft 365 Business Basic:1,049円
  • Microsoft 365 Business Standard:3,523円
  • Microsoft 365 Business Premium:4,797円

価格は、Teamsの有無や契約期間、キャンペーン、既存契約、地域、購入経路によって変わります。掲載価格を固定的な見積もりとして扱わないでください。

100ユーザーの場合、Basicは月10万4,900円・年125万8,800円、Standardは月35万2,300円・年422万7,600円です。Premiumは月47万9,700円、年575万6,400円です。

500ユーザーなら、上記の5倍です。加えて、SharePoint単体契約、既存契約、共有ユーザー、ゲストの扱いも確認します。さらに、追加ストレージやバックアップ、Copilot、Power Platformの費用も見ておきます。

導入・移行・追加開発の費用相場

規模ごとの初期費用と期間は、次の幅が目安です。

  • 小規模:標準サイト1〜3個、基本権限・文書庫・簡単なポータル・教育で100万〜300万円、1〜3か月
  • 中規模:複数部門や移行、メタデータ、検索設計、フロー数本、Teams連携で300万〜1,000万円、3〜6か月
  • 大規模:1,000万〜3,000万円以上、6〜12か月以上

大規模案件は、数千ユーザーや多数のサイト、複雑な権限、監査、全社教育を含みます。旧ポータルやオンプレミスからの移行、基幹システムやAPI連携も含みます。そのため、期間は6〜12か月以上になることがあります。

SPFxの独自Webパーツや特殊な入力・検索画面は、1機能あたり100万〜500万円程度を検討の目安にします。ただし、Power Appsや既製部品で代替できるかを先に比べます。

価格は、画面数だけでなく、移行ファイル数と容量、権限例外数、保持する版履歴、検索品質、承認フロー、外部連携によっても左右されます。

テストユーザー数や教育回数、問い合わせ対応時間も影響します。見積書では、要件定義、情報設計、移行、テスト、教育、運用設計の工程ごとに費用を分けてもらいます。

保守・運用費と追加コスト

保守・運用費は、目安と契約範囲の両方を確認しておきます。

  • 金額:初期費用の年15〜25%程度、または月15万〜80万円程度
  • 作業範囲:サイト払い出し、権限変更、問い合わせ、利用状況確認
  • 運用作業:フロー修正、更新検証、バックアップ・復元テスト
  • 対応時間:平日日中の問い合わせと夜間・休日の障害対応を分けて契約する

金額は一般的な業務システムの目安で、作業範囲によって変わります。サイト所有者を育て、申請や命名、権限変更、保存期限、退職者対応を手順にしておくと、運用費を抑えやすくなります。

すべてを利用部門に任せると、サイト乱立や過剰な権限付与につながります。中央管理者が定期レビューし、安さだけでなく運用開始後に誰が何時間対応するかも比べます。

ポイント

費用は、ライセンスの安さだけで判断せず、導入・移行・追加開発と保守・運用費を合わせた総額で比べます。見積もりは工程別に出してもらいます。

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

会社は、ライセンス販売だけでなく、情報設計や移行、権限の扱いで比べます。Power Platform、SPFx、教育、運用まで扱えるかも、あわせて比べます。

分業する場合は、要件定義、移行、稼働後の問い合わせを、どの会社が担当するかを確認します。

SharePoint・Microsoft 365の実績

件数以外の実績や提案姿勢も確かめます。

  • 案件の近さ:利用者数、データ量、業種、移行元、権限の複雑さ、公開範囲
  • 移行経験:ポータル構築と、旧環境から文書・権限・版履歴を移した経験を分けて確認する
  • 事例の詳細:期間、体制、対象データ、追加開発範囲、稼働後の問い合わせ件数
  • 提案姿勢:標準機能を中心とした進め方を示せるか確認する

初回提案に独自Webパーツや複雑な外部連携が多い場合は、標準機能で足りない理由を聞きます。Power Platformで代替できるか、将来の保守費も確認します。

技術の多さより、不要な作り込みを減らし、利用者が使い続けられる構成を示せるかを評価します。

提案書と見積書の比較方法

相見積もりと契約では、条件や確認事項をそろえます。

  • 範囲と規模:対象部門、利用者数、サイト数、移行元、データ容量
  • 要件と計画:権限、承認、外部共有、連携、希望時期、教育・保守の要否
  • 費目比較:要件定義、設計、構築、移行、テスト、教育、運用。省略か効率化かも確認する
  • 納品と検収:形式、検収条件、仕様変更、移行失敗時の再実施
  • 引き継ぎと契約:ソースコード・設定の引き渡し、ライセンス契約主体

問い合わせへの応答時間や、Microsoft 365更新の影響範囲も確認します。設計書、権限一覧、テスト仕様書、運用手順書を納品してもらうと、内製化や担当交代の際に役立ちます。

教育・内製化・運用支援の範囲

管理者が設定を変更できる範囲は広く、ルールと教育が成果を左右します。そのため、研修や稼働後の支援内容も確認します。

  • 教育:サイト所有者研修、利用者向け検索・共有研修、管理センター手順
  • 運用ルール:サイト申請の承認ルート、定期的な権限レビュー
  • 相談と保守:月次相談、改善提案、更新情報確認、障害切り分け
  • 改修:フローやWebパーツの変更範囲と単価
  • 内製化:設定理由、判断基準、テスト方法を引き継ぐ計画

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

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

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

ポイント

会社は、移行や権限の実績が案件に近いか、標準機能を中心に提案できるかで比べます。見積書は工程や費目をそろえ、稼働後の保守や教育まで比べます。

社内の知識基盤として使うほど、誰がどのデータに、どの端末から、どの期間アクセスできるかの設計が大切になります。

生成AIや組織検索では、古い共有権限や文書が参照範囲に入らないよう、データ分類と権限を見直します。

MFA・最小権限・DLPの組み合わせ

認証からデータ保護まで、基本対策を組み合わせて設計します。

  • 認証:多要素認証、条件付きアクセス
  • 利用環境:管理対象端末の確認、最小権限
  • 共有と監査:外部共有制御、監査ログ
  • 復旧:バックアップ・復元手順
  • 機密データ:秘密度・保持ラベル、DLP、ダウンロード制御

公式資料では、多要素認証、条件付きアクセス、外部共有管理、DLPによる機密保護が推奨されています(出典: SharePointとOneDriveのクラウドデータ保護に関する公式ドキュメント、2026年8月確認)。

制限付きサイトアクセス制御では、指定グループ外の利用者を、過去の権限や共有リンクがあってもアクセスできない状態にできます。サイトごとに最大10個のMicrosoft 365グループまたはEntraセキュリティグループを設定できます。

グループを追加しただけでは権限は付与されないため、通常のサイト権限と制限グループを両方設計し、テストします(出典: SharePointサイトの制限付きアクセス制御に関する公式ドキュメント、2026年8月確認)。

生成AI利用前の過剰共有の是正

2026年はSharePoint上の規程や手順書を生成AIで検索・要約する活用が現実的です。

2026年3月の事例では、SharePoint Onlineへ社内ポータルを移行し、全従業員の約6割が毎日生成AIを使うと報告されました。また、工場で社内規程を検索する用途も紹介されています。情報を集めるだけでなく、必要な人が必要な情報にたどり着く設計が成果につながります(出典: 2026年3月公開のSharePoint Online導入事例、2026年確認)。

AI導入前には、共有状態と権限について次の三点を確認します。

  • 参照範囲:AIは利用者が本来見られる情報を対象にするため、元データの権限が広いと、検索や回答の対象も広がる
  • 見直し対象:所有者不明サイト、全社公開の機密文書、退職者が残るグループ、期限切れ共有リンク
  • 権限確認:機密度と保存期限を設定し、誰に何を回答してよいかテストする

個人情報と電子帳簿保存法の業務要件への落とし込み

個人情報と電子取引データでは、業務要件や記録する項目が異なります。

  • 個人情報:利用目的、アクセス権、委託先、保存期間、削除、漏えい時の対応
  • 電子取引データ:改ざん防止、検索性、ダウンロード、システム概要書などを税務担当と確認する
  • 設計書:データ分類、保存期間、削除責任者、検索条件、監査ログ保持、復元方法

法令要件は、SharePointの版管理だけでは満たせないことがあります。

適用範囲や証跡は業種、取引、社内規程で異なります。最終判断は、法務や税務、情報セキュリティの担当者、または専門家と行います。

開発会社・ベンダーには、機能設定だけでなく、運用証跡を残す方法も提案してもらいます。

ポイント

生成AIを使う前に、所有者不明サイトや古い共有リンクを洗い出し、参照範囲を見直します。機密情報は、認証から監査、バックアップまでを組み合わせて設計します。

SharePointのシステムに関するよくある質問

導入前には、製品機能に加えて、ライセンス、移行、権限、運用分担も決めておく必要があります。よくある質問に、順に答えます。

ファイルサーバーからSharePointへ移行できますか?

移行は可能ですが、フォルダーを単純に移すだけでは不十分です。不要データ、所有者、権限、版履歴、メタデータ、保存期限を洗い出し、対象を分けて段階的に移します。

小さな部門で検索と権限を検証し、利用者の確認後に全社展開すると、手戻りを抑えられます。

Microsoft 365を契約中なら追加費用は不要ですか?

契約プランにSharePoint利用権が含まれる場合は、単体ライセンスが不要なこともあります。ただし、プラン、利用者、外部ユーザー、追加ストレージ、Copilot、Power Platform、バックアップ、導入支援は、別途確認します。

既存契約と必要機能を照合し、ライセンス費と開発費を分けて見積もりを取ります。

どこまで独自開発すればよいですか?

まず標準機能で業務を表現し、不足する入力や承認はPower AppsとPower Automateで補います。それでも足りない画面や連携だけを、SPFxやAPIで拡張するのが基本です。

独自開発では、保守担当者、テスト環境、更新対応、障害時の切り戻し、3年分の運用費まで含めて判断します。見た目の再現だけの作り込みは、更新や担当交代時の負担を増やします。

SharePointに機密情報を保存しても安全ですか?

認証、アクセス制御、データ分類を設計すれば、機密情報を扱える選択肢になります。残りの設計は、下の項目で確認します。

  • 外部共有と監査:外部共有の制御、監査ログ
  • 機密データ:DLP、保持ラベル
  • 復旧:バックアップ・復元手順

ただし、標準設定だけで安全が完成するわけではありません。

利用企業が権限と運用を管理し、機密度ごとに保存場所と利用者を分けて、権限と共有リンクを定期的に見直します。

SharePointのシステム開発にはどれくらいかかりますか?

標準機能中心の小規模ポータルは1〜3か月、中規模で移行や複数部門の業務フローを含む場合は3〜6か月が目安です。大規模移行や複雑な連携を含む場合は6〜12か月以上です。

期間は、サイト数よりも、移行データの整理や権限例外、利用者の合意、テスト、教育の範囲で変わります。希望納期から逆算し、PoC、先行部門、全社展開に分けて進める方法も検討します。

SharePointのシステム開発を成功させるポイントまとめ

SharePointは、社内ポータル、文書管理、検索、申請、承認、分析をMicrosoft 365内でつなぐ業務情報基盤です。

成功させるには、目的とKPIを決め、移行するデータと保存しないデータを分けておきます。そのうえで、権限と情報設計を先に固めます。

導入判断で外せない五つの確認事項

導入方式と見積もりを判断する前に、目的から運用体制まで次の五点を確認します。

  • 目的:検索時間や申請処理日数などの改善指標
  • データ:所有者、保存期限、移行範囲
  • 権限:サイトとグループを単位にした管理
  • 構成:標準機能、Power Platform、SPFxの選定順
  • 運用:教育、権限レビュー、アップデート対応を含む体制

整理した前提を複数の開発会社・ベンダーへ渡すと、提案と見積もりを比較しやすくなります。

最初に作るべき資料

見積もりの前提をそろえるため、導入範囲と体制を1〜2枚にまとめます。

  • 業務と規模:対象業務、利用者数、移行元、データ容量
  • 設計要件:権限パターン、外部共有、承認、必要な連携
  • 計画と体制:希望時期、導入後の運用担当

完璧な仕様書でなくても、困りごとと判断範囲が分かれば、PoC対象と見積もり前提をそろえられます。

小さく検証し、利用者の声と実測値をもとに全社展開の範囲を決めると、過剰なカスタマイズと移行リスクを抑えられます。

▼関連記事一覧
・SharePointのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・SharePointのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・SharePointのシステム開発の見積相場や費用/コスト/値段について
・SharePointのシステム開発の発注/外注/依頼/委託方法について

 

会社紹介

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

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

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

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

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

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