Google BigQuery導入の開発期間・スケジュール・納期について

Google BigQueryは、Google Cloudが提供するサーバーレス・フルマネージド型のクラウドデータウェアハウス（DWH）で、テラバイトからペタバイト級の大量データに対して高速な分析クエリを実行できる分析基盤の代表的な選択肢です。最大の特徴は、サーバーやクラスターといったインフラを一切意識することなく、標準SQLを書くだけで分析を始められる「サーバーレス」アーキテクチャにあります。ストレージとコンピュート（計算リソース）が構造的に分離されており、クエリを実行するたびに必要な計算資源が自動で割り当てられるため、Amazon RedshiftやAzure Synapse Analyticsのように事前にノード数や専用プールのサイズを見積もって確保しておく必要がありません。経営ダッシュボード、マーケティング分析、IoTデータ分析、機械学習の前処理基盤など幅広い用途で採用が進む一方、BigQueryの導入を検討する企業のデータ活用・BI担当者がまず直面するのが、「導入プロジェクトはどのくらいの期間がかかるのか」「要件定義からダッシュボードの本稼働まで、どんな工程をどんなスケジュールで踏むのか」「納期をどう見積もればよいのか」という現実的な疑問です。BigQuery導入は、単にプロジェクトを作成してデータを流し込めば終わりというものではなく、既存システムからのデータ移行、ETL/ELTパイプラインの構築、データモデルの設計、BIツールとの接続までを含む一連のプロジェクトであり、その全体像を把握しておくことが計画づくりの第一歩になります。

本記事では、Google BigQuery導入の開発期間・スケジュール・納期に焦点を当て、規模別の期間目安、要件定義から運用開始までの工程ごとの期間配分、BigQueryならではの期間短縮の仕組み、納期を短縮する具体的な手法、そして納期遅延の典型要因とその対策までを、実際のGoogle Cloudの仕組みと現場のプロジェクト経験に基づいて体系的に解説します。サーバーレスDWHであるBigQuery特有の「インフラ構築工数のゼロ化」「サンドボックスによる即時検証」「段階的なユースケース展開」といった要素が導入スピードにどう影響するかという観点を軸に整理しているため、これから導入パートナーを選定する方はもちろん、社内でスケジュールを策定する立場の方にとっても、現実的な計画を立てるための判断軸が身に付くはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・Google BigQuery導入の完全ガイド

Google BigQuery導入の開発期間の全体像

Google BigQuery導入プロジェクトの期間は、対象とするデータ量、連携する既存システムの数、分析要件の複雑さによって大きく変動しますが、まずは規模別の大まかな目安を把握しておくことが、現実的なスケジュールを描く第一歩になります。DWH導入で失敗しやすいのは、最初から全社の全データ・全分析を一度に網羅しようとするパターンで、これは期間の長期化とプロジェクトの頓挫を招きます。実務で推奨されるのは、まず解決したい事業課題に直結する1〜2のユースケースに絞り、3〜6か月で早期に成果を出す「MVP（実用最小限の製品）」型のアプローチです。実際のBigQuery導入事例でも、あるEC企業は分析テーマを「売上分析」という1つのユースケースに絞り込むことで、わずか3か月でMVPを構築して成果を出しています。具体的な規模感としては、単一データソースの連携と基本的なダッシュボード構築に絞った小規模なスタートであれば2〜4か月、複数データソースの統合・データモデル設計・権限管理・複数ダッシュボードを備えた中規模の分析基盤であれば4〜9か月、全社横断のデータ基盤にAI・機械学習の活用まで組み合わせる大規模プロジェクトであれば6〜12か月以上が現実的な範囲です。ここで重要なのは、BigQueryはサーバーレスのフルマネージドサービスであるため、データベースエンジンそのものの構築・チューニングやサーバー調達にかかる工数がほぼゼロになり、プロジェクトの大半が「データの移行・加工・モデリング・可視化」に充てられるという特性です。この特性が、BigQuery導入の納期見積もりを考えるうえでの土台になります。

規模別にもう少し具体的に整理すると、まず小規模プロジェクトは、単一の業務システム（基幹システムやSaaSのデータ）をBigQueryに集約し、売上や在庫といった限定的なテーマのダッシュボードを構築するケースが該当し、期間は2〜4か月、初期費用は100万〜300万円程度が目安です。この規模であれば、BigQueryのサンドボックスや無料枠を使ってすぐに手を動かし始められ、データ連携もSaaSコネクター（後述するFivetranなどのマネージド型連携ツール）でシンプルにまとめられるため、短期間での立ち上げが可能です。中規模プロジェクトは、複数の基幹システム・SaaS・ログデータを統合し、部門横断のKPIダッシュボードや権限管理を備えた本格的な分析基盤を構築するケースで、期間は4〜9か月、初期費用は300万〜1,500万円程度になります。データモデル（スタースキーマやディメンショナルモデル）の設計、ETL/ELTパイプラインの整備、複数ダッシュボードの作り込みが中心工程となり、データエンジニア・BIエンジニア・プロジェクトマネージャーによるチーム編成が標準です。大規模プロジェクトは、全社データ基盤としてBigQueryを中核に据え、Cloud Storage上のデータレイクとの連携や、BigQuery MLをはじめとするAI・機械学習の前処理基盤までを含むケースで、期間は6〜12か月以上、初期費用は1,500万〜5,000万円以上に及びます。大量データのパフォーマンス設計、厳格なデータガバナンス、段階的な全社ロールアウトが必要となり、期間の見積もりには十分なバッファを織り込む必要があります。いずれの規模でも、BigQueryはインフラを持たないため、費用の内訳は「クラウドの利用料」よりも「設計・開発の人件費」が支配的になる点を押さえておきましょう。

同じ「中規模のBigQuery導入」であっても、期間が4か月で済む場合と9か月かかる場合があり、その差を生むのがいくつかの変数です。第一に、そして最も影響が大きいのが「データの品質と前処理の量」です。分析対象となる元データが整備されておらず、表記ゆれ・重複・欠損が多い場合、名寄せやクレンジングといった前処理だけで数か月を要することも珍しくありません。「明日からデータ活用」という理想とは裏腹に、現実にはこの前処理がプロジェクト期間の大部分を占めるケースが頻発します。第二に「移行元システムの数と連携方式」です。連携するデータソースが1つの場合と、基幹システム・複数のSaaS・IoTログなど多数のソースを統合する場合とでは、ETL/ELTの設計・実装・テストの工数が大きく変わります。BigQueryの場合、主要SaaSからのデータ取り込みはData Transfer ServiceやFivetranなどのコネクターで大幅に効率化できるため、標準的なコネクターが用意されているソースかどうかも期間を左右します。第三に「分析要件・ダッシュボードの複雑さ」です。定型のレポートだけで済むのか、部門ごとに異なる指標やドリルダウン分析、さらにはBigQuery MLによる予測モデルまで求めるのかで、データモデルとBI構築の作り込み度合いが変わります。第四に「利用者のスキルと運用体制」です。BigQueryはConnected Sheets（スプレッドシート連携）などで非エンジニアでも扱いやすい反面、誰がクエリを書き、誰がダッシュボードを保守するのかによって、教育やドキュメント整備に充てる期間が変わってきます。これらの変数を要件定義の段階で洗い出しておくことが、精度の高い納期見積もりにつながります。

工程別のスケジュールと期間配分

Google BigQuery導入のスケジュールを考える際は、全体の期間を「要件定義・技術選定」「設計・構築」「テスト・移行・運用開始」の3フェーズに分け、それぞれにどれくらいの割合を充てるかを把握しておくと、現実的な計画が立てやすくなります。データ分析基盤プロジェクトの一般的な工数配分の目安は、要件定義に全体の約10%、設計に約10〜20%、データ加工・集計ロジック・ダッシュボード構築を含む開発（構築）に約40〜60%、テスト・移行に約10〜20%です。開発（構築）フェーズが最も工数の大きい山場になる点が、DWH導入プロジェクトの特徴です。たとえば6か月（約26週）の中規模プロジェクトであれば、要件定義に約2〜3週、設計に約4〜5週、構築に約13〜15週、テスト・移行・運用開始に約4〜5週を割り当てる計算になります。BigQueryはサーバーレスであるため、他のDWHで発生しがちな「クラスターのサイジング検討」「ノード構成の設計」「インフラ構築」といった工程がほぼ不要になり、その分を「どのデータをどの粒度で集約し、どんな指標を可視化するか」というデータ設計・KPI設計に振り向けられます。ここでの判断がそのまま構築工数とダッシュボードの実用性を左右するため、上流に十分な時間を確保することが結果的に納期遵守につながります。

要件定義・技術選定フェーズは、Google BigQuery導入の成否を左右する最も重要な工程です。ここでは「何のデータを、誰が、どう分析して、どんな意思決定に使うか」という分析要件の整理から始めます。よくある失敗が、技術選定を先行させて「話題だからBigQueryで作ろう」と進めてしまうケースで、解決したい事業課題から逆算して分析のスコープとKPIを定義することが大切です。具体的には、対象業務のKPI整理、分析要件の定義、必要なデータソースの棚卸し、データの発生量と更新頻度の把握を行います。BigQueryは製品としての選定はシンプルですが、代わりに「コンピュート課金をオンデマンド（従量課金）にするか、BigQuery Editions（スロットの容量ベース課金）にするか」という料金モデルの方針を、想定するクエリ量・利用パターン・予算の固定度合いから判断しておく必要があります。断続的に使うスモールスタートや利用量が読めない初期段階ではオンデマンドが、利用が安定して大量になり予算を固定したい運用期にはEditionsの容量予約が向く、といった判断軸を整理します。さらに、Cloud Storage（データレイク）との役割分担、ETL/ELTツール（Dataflow・Dataform・dbt・Fivetranなど）の選定、BIツール（Looker・Looker Studio・Tableau・Power BI・Connected Sheetsなど）の選定も、このフェーズで方針を固めます。これらをドキュメントとして残しておくことが、以降の工程での手戻りを防ぐ最大の予防策です。期間の目安は1〜3週間です。

設計・構築フェーズは、全体の5〜7割を占める最も工数の大きい工程です。設計では、まずデータモデルの設計（分析に適したスタースキーマやディメンショナルモデルの定義）、パーティション分割やクラスタリングといったBigQuery特有のテーブル設計、KPI設計、ダッシュボード設計、そしてIAMやデータセット・列・行レベルのアクセス権限設計を行います。BigQueryのパーティション・クラスタリング設計は、後述するクエリコストとパフォーマンスに直結する重要な設計判断であり、ここを丁寧に行うことが運用コストの最適化にもつながります。構築では、データセットとテーブルの作成、ETL/ELTパイプラインの実装、データの初期ロードと差分連携の仕組みづくり、そしてBIツールとの接続とダッシュボードの実装を進めます。BigQueryはサーバーレスであるため、サーバーのプロビジョニングやパッチ適用、バックアップ、スケーリングといったインフラ運用をGoogle Cloudが完全に肩代わりしてくれる分、開発チームはデータの加工ロジックとモデリングに集中できます。構築にあたっては、2週間〜1か月単位のスプリントで区切り、定期的に成果物を確認しながらアジャイルに進める手法が適しています。SQLベースのビュー定義やDataform・dbtを用いたELTでは、データ変換ロジックをコードとしてバージョン管理し、レビューとテストを組み込むことで品質を担保します。中規模であれば、このフェーズに13〜16週程度を見込んでおくのが現実的です。

テスト・移行・運用開始フェーズでは、構築したBigQuery分析基盤が要件を満たし、集計結果が正確であるかを検証したうえで本番運用に移します。データ分析基盤のテストで特に重要なのが「数値検証」です。ダッシュボードの見た目が整っていても、集計ロジックの誤りやデータ連携の欠損によって数値がずれていれば、意思決定を誤らせる致命的な問題になります。既存の帳票や現行システムの集計値と突き合わせて数値の整合性を確認する作業は、見た目の実装以上に工数がかかることが多く、テスト工数が膨らみやすい点に注意が必要です。加えて、BigQuery特有の観点として「クエリコストのテスト」も欠かせません。ダッシュボードの各クエリがどれだけのデータをスキャンするかを事前に見積もり、パーティションやクラスタリングが効いてスキャン量が抑えられているかを確認しておくことで、運用開始後のコスト急騰を防げます。また、権限設定が意図どおりに機能しているかのアクセス制御テストも実施します。テストが完了したら、ユーザー受け入れテスト（UAT）を経て、一部の部門やユースケースから段階的に運用を開始します。全部門へ一斉展開するのではなく、パイロット部門で運用しながら利用者のフィードバックを収集し、データモデルやダッシュボードを継続的に改善していく進め方が、失敗を避けるベストプラクティスです。あわせて、BIツールの操作研修や問い合わせ窓口の整備といった定着支援を行うことも、運用開始フェーズの重要な作業です。このフェーズには3〜5週程度を見込んでおきます。

BigQueryならではの期間短縮の仕組み

Google BigQueryが、DWHをオンプレミスやフルスクラッチで構築する場合はもちろん、他のクラウドDWHと比べても導入期間を短縮しやすいのは、データベースエンジンと、その運用に必要なインフラの「すべて」がGoogle Cloudによって完全にマネージド（管理代行）されているためです。サーバーの調達・構築、OSやミドルウェアのインストール、パッチ適用、バックアップ、冗長化、そしてクラスターのサイジングやスケーリングといった、本来なら数週間から数か月を要するインフラ作業が、そもそも「作業として存在しない」のがサーバーレスの本質です。ここでは、BigQuery導入の期間短縮を支える2つの仕組みを掘り下げます。

BigQuery最大の期間短縮効果は、インフラ構築という工程そのものが消滅する点にあります。Amazon RedshiftやAzure Synapse Analyticsでは、たとえマネージドサービスであっても、どのノードタイプを何台構成にするか、専用プールにどれだけのリソースを割り当てるかといったサイジングを設計し、クラスターを立ち上げ、ネットワークを構成する工程が必要です。BigQueryにはこの「起動しておくクラスター」という概念が基本的に存在しません。プロジェクトを作成し、データセットとテーブルを用意すれば、あとは標準SQLでクエリを投げるだけで、必要な計算リソースがGoogle Cloud側で自動的に割り当てられて実行されます。処理能力はワークロードに応じて内部で自動スケールするため、「アクセスが増えたらノードを増設する」「夜間バッチのためにクラスターを拡張する」といった運用設計も原則不要です。この結果、他のDWHでは設計・構築フェーズの一定割合を占めるインフラ関連工数が、BigQueryではほぼゼロになり、その分の期間をデータ設計・可視化に振り向けられます。ストレージとコンピュートが分離しているため、データを溜めておくだけならクエリの計算課金は発生せず、「まずデータを集めてから徐々に分析を組み立てる」といった段階的な進め方も取りやすいのが特徴です。

BigQueryのもう一つの強力な武器が、BigQueryサンドボックスと無料利用枠の存在です。BigQueryサンドボックスを使えば、クレジットカードの登録や課金設定を行わなくても（一部機能に制限はあるものの）すぐにBigQueryを触り始めることができ、実データを使った検証を初日から開始できます。加えて、BigQueryには公式の無料利用枠として、毎月一定量のクエリ処理（一般的に1TiBのスキャン相当）とストレージ（一般的に10GiB相当）が無償で使える範囲が用意されており、小規模なPoCであれば実質的にコストをかけずに手を動かせます（無料枠の詳細は公式料金ページで最新情報を要確認）。オンデマンドのコンピュート課金はスキャンしたデータ量に応じた従量制のため、「まずは動かして試す」段階では使った分だけの少額で済み、事前に大きなリソースを予約する必要がありません。この即時起動・従量課金の性質は、後述するPoC（概念実証）やプロトタイピングと非常に相性がよく、要件定義と並行して実データで手を動かしながら検証を進められるため、プロジェクト全体のリードタイムを短縮できます。インフラ構築・運用設計にかかる時間をサーバーレス基盤に完全に肩代わりさせられ、初期投資ゼロで検証に入れることが、BigQuery導入の納期短縮効果の核心です。

BigQuery導入で納期を短縮する具体的な方法

サーバーレスの構造的なメリットに加えて、プロジェクトの進め方の工夫によってBigQuery導入の納期はさらに短縮できます。ここでは、スコープを絞ったMVPアプローチと、SaaSコネクター活用・アジャイル・段階的ロールアウトという、実務で効果の大きい2つの方向性を紹介します。

BigQuery導入の納期を短縮する最も効果的な手段が、最初のリリース範囲を厳しく絞り込むことです。全社のあらゆるデータと分析を一度に対象にすると、要件が膨れ上がり、データ連携先が増え、関係者の合意形成にも時間がかかって、いつまでたっても本番稼働にたどり着けません。これを避けるため、まずは成果が出やすく、経営や現場のインパクトが大きい1〜2のユースケースに絞ってPhase 1（MVP）を構築します。先述のEC企業の事例のように「月次の売上・粗利を商品・店舗軸で可視化する」といった明確な意思決定に直結するテーマを1つ選べば、3か月程度でMVPを立ち上げることも十分に可能です。対象を絞ることで、連携するデータソースが限定され、データモデルもシンプルになり、短期間で目に見える成果を出せます。この最初の成功体験が社内の理解と予算を引き出し、Phase 2以降の拡張をスムーズに進める推進力になります。最初から完璧な全社基盤を目指すのではなく、小さく作って早く価値を出し、そこから育てていくという発想が、結果的に最短ルートになります。BigQueryは従量課金かつサーバーレスであるため、小さく始めた基盤をそのままスケールさせられ、MVPで作った資産を作り直すことなく拡張できる点も、この段階的アプローチと相性がよい理由です。

納期短縮の二つ目の柱が、データ連携の内製を避けることと、開発をアジャイルに進めることです。データ分析基盤の構築で意外と工数を食うのが、各業務システムやSaaSからBigQueryへデータを取り込むETL/ELT部分です。ここをAPI連携からゼロで自社開発すると、開発工数がかさむだけでなく、接続先の仕様変更への追随といった保守負担も抱え込むことになります。BigQueryには、Google公式のData Transfer Serviceに加え、FivetranやtroccoなどのマネージドなSaaSコネクターが豊富に用意されており、主要なSaaSやデータベースであればノーコードに近い形で連携を構築できます。連携部分をこうしたマネージドツールに任せることで、開発チームは分析ロジックとダッシュボードの作り込みに集中でき、構築フェーズの期間を大きく圧縮できます。さらに、開発・構築フェーズを2週間〜1か月単位のスプリントに区切り、短いサイクルで「データを取り込む→集計する→ダッシュボードで見せる→フィードバックをもらう」を繰り返すことで、指標定義の認識のずれを早期に発見・修正でき、後工程での大きな作り直しを防げます。本番展開も、全部門への一斉リリースではなく、パイロット部門から段階的にロールアウトし、運用上の問題やデータの不整合を洗い出してから対象を広げることで、リスクを抑えつつ着実に定着させられます。段階的なロールアウトは一見遠回りに見えますが、大規模な手戻りや運用トラブルによる遅延を防ぎ、トータルの納期を守る現実的な戦略です。

納期遅延の典型要因と対策

BigQueryはサーバーレスの構造によって納期短縮に大きく寄与する一方で、DWH導入プロジェクト固有の遅延リスクも存在します。あらかじめ典型的な要因を把握し、対策を講じておくことで、スケジュールの破綻を防げます。ここでは、特に発生頻度の高い2つの遅延要因とその対策を解説します。

BigQuery導入で最も多い納期遅延が、元データの品質問題に起因するものです。分析基盤の構築そのものはサーバーレスのおかげで順調に進んでも、いざ実データを取り込もうとすると、表記ゆれ（同じ取引先が別名で登録されている等）、重複レコード、欠損値、フォーマットの不統一などが大量に見つかり、名寄せやクレンジングといった前処理だけで数か月を要することがあります。「明日からデータ活用」という期待に反して、現実にはこのデータ整備がプロジェクトの隠れた大きな山になるのです。皮肉なことに、BigQueryはインフラ構築が不要で立ち上げが速い分、この前処理工数の相対的な比重がかえって大きく見えることもあります。対策の第一歩は、要件定義の段階で実データのサンプルを実際にBigQueryへ読み込んでみて、データ品質の実態を早めに把握しておくことです。「データはきれいにそろっている」という前提を置かず、前処理の工数を最初から見積もりに織り込んでおきます。また、完璧なマスターデータ整備を目指して立ち止まるのではなく、まず最優先のユースケースに必要な範囲だけを整備し、段階的に広げていくアプローチが有効です。データ品質の改善は一度で終わるものではないため、Dataformやdbtで変換・クレンジングのロジックをコード化し、継続的に運用・改善できる体制をあわせて設計しておくことが、遅延の連鎖を断つ鍵になります。

もう一つの典型的な遅延要因が、要件スコープの膨張と、数値検証（テスト）の工数の見込み違いです。前者については、ダッシュボードが形になってくると、関係者から「この指標も追加してほしい」「別の切り口でも見たい」という要望が次々と挙がり、対象データやデータモデルを作り直す重い手戻りが発生します。対策としては、要件定義の段階でPhase 1のスコープを明確に線引きし、追加要望は「影響範囲と工数を見積もってから合意する」という変更管理のプロセスを整えておくことです。挙がった要望はPhase 2以降のバックログとして記録し、最初のリリースをぶらさないことが重要です。後者の数値検証については、データ分析基盤では見た目の実装以上に「集計値が正しいか」の確認に工数がかかります。現行の帳票や既存システムの数値と突き合わせ、差異が出た場合はデータ連携や集計ロジックのどこに原因があるかを一つずつ切り分ける必要があり、この作業を軽視するとリリース直前に大きな遅延を招きます。BigQueryの場合はここにクエリコストの検証も加わり、テスト段階で想定外の高額なスキャンが発生するクエリを洗い出し、パーティションやクラスタリングで最適化する作業も必要です。テスト工程には十分な期間を確保し、検証用のサンプルデータと期待値、そしてコストの想定値を早い段階で準備しておくことで、BigQuery導入固有の遅延リスクを最小化できます。

まとめ

Google BigQuery導入の開発期間は、単一データソースに絞った小規模なスタートで2〜4か月、複数ソースを統合する中規模の分析基盤で4〜9か月、AI活用まで含む全社大規模基盤で6〜12か月以上が現実的な目安であり、工程配分は要件定義に約10%、設計に約10〜20%、データ加工・ダッシュボード構築を含む構築に約40〜60%、テスト・移行・運用開始に約10〜20%が標準です。BigQueryはサーバーレスのフルマネージドサービスであるため、クラスターのサイジングやインフラ構築という工程そのものが存在せず、他のクラウドDWH以上に上流のデータ設計・可視化に工数を振り向けられるのが期間面での強みです。さらに、BigQueryサンドボックスと無料枠を使えば初期投資ゼロで即座に実データ検証に入れ、1〜2ユースケースに絞ったMVPアプローチ、Fivetranなどのコネクターによるデータ連携の効率化、2週間〜1か月のスプリントによるアジャイル開発、パイロット部門からの段階的ロールアウトを組み合わせれば、着実に価値を出しながら短期間での本番稼働を実現できます。一方で、元データの品質・前処理の見積もり漏れ、要件スコープの膨張、数値検証とクエリコスト検証の工数不足はDWH導入固有の遅延要因となるため、実データの早期確認・変更管理プロセスの整備・テスト期間の十分な確保といった対策をあらかじめ講じておくことが、納期遵守の鍵となります。これらの判断軸を押さえたうえで、自社のデータ活用に最適なスケジュールと体制を検討してください。

▼全体ガイドの記事
・Google BigQuery導入の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。