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

Snowflakeは、AWS・Azure・Google Cloudのいずれのクラウド上でも稼働する「マルチクラウド対応」のクラウドデータプラットフォームで、コンピュート（計算処理）とストレージ（データ保存）を完全に分離したアーキテクチャと、標準SQLだけで扱える扱いやすさによって、専任のデータエンジニアがいない組織でもデータ活用を進めやすい分析基盤として世界的に採用が拡大しています。特定のクラウドにロックインされずに構築できる点、データを物理的にコピーせず他組織と共有できる「データシェアリング」機能、需要に応じて計算リソースを瞬時に増減できる仮想ウェアハウスの仕組みは、AWS専用のAmazon Redshiftや、機械学習基盤としての性格が強いDatabricksとは異なるSnowflateならではの強みです。一方で、Snowflake導入を検討するデータ活用・BI担当者がまず直面するのが、「導入プロジェクトはどのくらいの期間がかかるのか」「要件定義からダッシュボードの本稼働まで、どんな工程をどのようなスケジュールで踏むのか」「納期をどう見積もればよいのか」という現実的な疑問です。

本記事では、Snowflake導入の開発期間・スケジュール・納期に焦点を当て、規模別の期間目安、要件定義から運用開始までの工程ごとの期間配分、Snowflakeならではの期間短縮の仕組み、納期を短縮する具体的な手法、そして納期遅延の典型要因とその対策までを、Snowflakeの実際の仕組みと現場のデータ基盤プロジェクトの知見に基づいて体系的に解説します。SaaS型フルマネージドであること、マルチクラウド対応、コンピュートとストレージの分離、仮想ウェアハウスの即時起動、データシェアリングといったSnowflake特有の要素が導入スピードにどう影響するかという観点を軸に整理しているため、これから導入パートナーを選定する方はもちろん、社内でスケジュールを策定する立場の方にとっても、現実的な計画を立てるための判断軸が身に付くはずです。

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

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

Snowflake導入の開発期間の全体像

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

規模別にもう少し具体的に整理すると、まず小規模プロジェクトは、単一の業務システム（基幹システムやSaaSのデータ）をSnowflakeに集約し、売上や在庫といった限定的なテーマのダッシュボードを構築するケースが該当し、期間は2〜4か月、初期費用は100万〜300万円程度が目安です。この規模であれば、小さな仮想ウェアハウス1台と最小限のスキーマ設計でスモールスタートでき、ETLもFivetranやSnowpipe、dbtといったツールでシンプルにまとめられるため、短期間での立ち上げが可能です。中規模プロジェクトは、複数の基幹システム・SaaS・ログデータを統合し、部門横断のKPIダッシュボードやロールベースのアクセス権限を備えた本格的な分析基盤を構築するケースで、期間は4〜9か月、初期費用は300万〜1,500万円程度になります。データモデル（スタースキーマやディメンショナルモデル）の設計、ETL/ELTパイプラインの整備、ロール設計、複数ダッシュボードの作り込みが中心工程となり、データエンジニア・BIエンジニア・プロジェクトマネージャーによるチーム編成が標準です。大規模プロジェクトは、全社データ基盤としてSnowflakeを中核に据え、他部門・他社とのデータシェアリングやAI・機械学習の前処理基盤までを含むケースで、期間は6〜12か月以上、初期費用は1,500万〜5,000万円以上に及びます。マルチクラウドでのデータ配置、厳格なデータガバナンス、クレジット消費のコスト設計、段階的な全社ロールアウトが必要となり、期間の見積もりには十分なバッファを織り込む必要があります。なお、これらの費用はあくまで導入・開発にかかる目安であり、Snowflake自体の利用料（クレジット・ストレージ）は別途、利用量に応じて発生する点に留意してください。

同じ「中規模のSnowflake導入」であっても、期間が4か月で済む場合と9か月かかる場合があり、その差を生むのがいくつかの変数です。第一に、そして最も影響が大きいのが「データの品質と前処理の量」です。分析対象となる元データが整備されておらず、表記ゆれ・重複・欠損が多い場合、名寄せやクレンジングといった前処理だけで数か月を要することも珍しくありません。Snowflakeはアカウント開設自体は容易ですが、データをロードしなければ性能も価値も出ないため、データ移行が必須の工程となり、その設計・実装工数が期間を大きく左右します。第二に「移行元システムの数と連携方式」です。連携するデータソースが1つの場合と、基幹システム・複数のSaaS・IoTログなど多数のソースを統合する場合とでは、ETL/ELTの設計・実装・テストの工数が大きく変わります。第三に「利用するクラウドとマルチクラウド要件」です。Snowflakeはどのクラウド上でも稼働しますが、各クラウドごとのネットワーク設計やセキュリティ最適化は自社側で設計する必要があり、複数クラウドにまたがってデータを配置・複製する要件がある場合はその設計・検証工数を織り込む必要があります。第四に「分析要件・ダッシュボードの複雑さ」と「データシェアリングの有無」です。定型レポートだけで済むのか、部門ごとに異なる指標やドリルダウン分析、さらには他社・他部門とのデータ共有まで求めるのかで、データモデルとBI構築、ロール設計の作り込み度合いが変わります。これらの変数を要件定義の段階で洗い出しておくことが、精度の高い納期見積もりにつながります。

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

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

要件定義・技術選定フェーズは、Snowflake導入の成否を左右する最も重要な工程です。ここでは「何のデータを、誰が、どう分析して、どんな意思決定に使うか」という分析要件の整理から始めます。よくある失敗が、技術選定を先行させて「話題になっているからSnowflakeで作ろう」と進めてしまうケースで、解決したい事業課題から逆算して分析のスコープとKPIを定義することが大切です。具体的には、対象業務のKPI整理、分析要件の定義、必要なデータソースの棚卸し、データの発生量と更新頻度の把握を行います。技術選定の観点では、そもそもSnowflakeが自社に最適かを、Amazon RedshiftやGoogle BigQuery、Databricksといった他の選択肢と比較して見極めます。Snowflakeは「特定クラウドにロックインされたくない」「他社・他部門とデータを共有したい」「専任のデータエンジニアがいなくても標準SQLで運用したい」「適切なサイジングで予算を固定し安定稼働を目指したい」といったニーズに強く、逆に「とにかく小さく安く試したい」だけであれば従量課金のBigQueryのほうが向く場合もあります。さらに、稼働させるクラウド（AWS・Azure・GCP）の選定、エディション（Standard・Enterprise・Business Criticalなど）の選定、データレイクとの役割分担、ETL/ELTツール（Fivetran・dbt・Snowpipeなど）の選定、BIツール（Tableau・Power BI・Looker・Looker Studioなど）の選定も、このフェーズで方針を固めます。これらをドキュメントとして残しておくことが、以降の工程での手戻りを防ぐ最大の予防策です。期間の目安は1〜3週間です。

設計・構築フェーズは、全体の5〜7割を占める最も工数の大きい工程です。設計では、まずデータモデルの設計（分析に適したスタースキーマやディメンショナルモデルの定義）、KPI設計、ダッシュボード設計、そしてSnowflakeのロール（RBAC）を用いたアクセス権限設計を行います。あわせて、どのワークロード（データ取込・変換、BIクエリ、アドホック分析など）にどのサイズの仮想ウェアハウスを割り当てるかというコンピュート設計を行うのがSnowflakeならではの重要工程です。仮想ウェアハウスはワークロードごとに独立して起動でき、互いに性能干渉しないため、たとえば重いバッチ処理とダッシュボード表示を別のウェアハウスに分離することで、双方の応答性を保てます。構築では、データベース・スキーマ・ロールのセットアップ、Snowpipeやサードパーティコネクタによるデータ取込パイプラインの実装、データの初期ロードと差分連携の仕組みづくり、SQLやdbtによる変換ロジック（ELT）の実装、そしてBIツールとの接続とダッシュボードの実装を進めます。SnowflakeはSaaS型のフルマネージドであるため、サーバーのプロビジョニングやパッチ適用、バックアップ、スケーリングといったインフラ運用をSnowflake側が肩代わりしてくれる分、開発チームはデータの加工ロジックとモデリングに集中できます。構築にあたっては、2週間〜1か月単位のスプリントで区切り、定期的に成果物を確認しながらアジャイルに進める手法が適しています。変換ロジックはコードとしてバージョン管理し、レビューとテストを組み込むことで品質を担保します。中規模であれば、このフェーズに13〜16週程度を見込んでおくのが現実的です。

テスト・移行・運用開始フェーズでは、構築したSnowflake分析基盤が要件を満たし、集計結果が正確であるかを検証したうえで本番運用に移します。データ分析基盤のテストで特に重要なのが「数値検証」です。ダッシュボードの見た目が整っていても、集計ロジックの誤りやデータ連携の欠損によって数値がずれていれば、意思決定を誤らせる致命的な問題になります。既存の帳票や現行システムの集計値と突き合わせて数値の整合性を確認する作業は、見た目の実装以上に工数がかかることが多く、テスト工数が膨らみやすい点に注意が必要です。加えて、想定するデータ量でのクエリ性能テスト（仮想ウェアハウスのサイズ設定が適切か、クラスタリングが効いているか）、そしてロール設計が意図どおりに機能しているかのアクセス制御テストも実施します。Snowflakeではこのフェーズで、実際のクエリ負荷に対してどれだけクレジットを消費するかを計測し、コスト面のチューニング（ウェアハウスの自動サスペンド設定やサイズの最適化）を行っておくことも重要です。テストが完了したら、ユーザー受け入れテスト（UAT）を経て、一部の部門やユースケースから段階的に運用を開始します。全部門へ一斉展開するのではなく、パイロット部門で運用しながら利用者のフィードバックを収集し、データモデルやダッシュボードを継続的に改善していく進め方が、失敗を避けるベストプラクティスです。リリース後はクエリ性能とクレジット消費のモニタリングを組み合わせた継続的な改善サイクルを回します。このフェーズには3〜5週程度を見込んでおきます。

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

Snowflakeが、DWHをオンプレミスやフルスクラッチで構築する場合と比べて導入期間を短縮しやすいのは、データベースエンジンそのものと、その運用に必要なインフラの大部分がSnowflakeによってSaaS型でマネージド（管理代行）されているためです。サーバーの調達・構築、OSやミドルウェアのインストール、パッチ適用、バックアップ、冗長化、スケーリングといった、本来なら数週間から数か月を要するインフラ作業が不要で、Webのコンソールからデータベースとウェアハウスを作成すれば、すぐにデータのロードとクエリを開始できます。ここでは、Snowflake導入の期間短縮を支える2つの仕組みを掘り下げます。

Snowflake導入で大きな期間短縮効果を生むのが、SaaS型フルマネージドであることと、マルチクラウド対応です。Snowflakeは特定のクラウドに紐づく製品ではなく、AWS・Azure・Google Cloudのいずれの上でも同じように動作するため、自社が主に使っているクラウドに合わせてアカウントを開設でき、既存のクラウド環境との親和性を保ちながら短期間で立ち上げられます。Amazon RedshiftがAWSエコシステムに密結合しており、VPCやIAMといったAWS固有のインフラ知識を前提とするのに対し、Snowflakeはクラウドの違いを吸収したうえで標準SQLだけで扱えるため、特定クラウドの深い専門知識がなくてもデータ活用に着手しやすいのが特徴です。また、サーバー機器の調達やクラスターの構築が一切不要で、パッチ適用・バックアップ・障害復旧・スケーリングといった運用作業はすべてSnowflakeが自動で担います。これにより、インフラ構築・運用設計にかかっていた時間をまるごと削減でき、開発チームは最初からデータの取込・モデリング・可視化という本質的な作業に着手できます。一方で、各クラウドごとのネットワーク設計やセキュリティ最適化は自社側で設計する必要があるため、その分の工数は計画に織り込んでおくことが重要です。

Snowflakeのもう一つの強力な武器が、コンピュート（計算処理）とストレージ（データ保存）を完全に分離したアーキテクチャと、仮想ウェアハウスの即時起動です。従来のDWHでは、計算能力とデータ容量が一体になっていたため、どちらか一方を増強したいだけでも全体のサイジングをやり直す必要がありました。Snowflakeではデータはクラウドストレージに一元的に保存され、それに対して計算処理を行う仮想ウェアハウスを必要なときに必要なサイズで即座に起動できます。ワークグループのように事前にノード数を見積もって確保しておく必要がなく、ウェアハウスを作成するだけですぐにクエリを実行でき、処理が終わってアイドル状態が続けば自動的にサスペンド（一時停止）してコンピュート課金も止まります。この即時起動・自動停止の性質は、導入初期に「まずは実データを入れて動かしてみる」までのリードタイムを大幅に短縮します。しかも、分析用・バッチ用・データサイエンス用といったワークロードごとに独立したウェアハウスを割り当てられるため、一方の重い処理が他方のダッシュボード表示を遅くするといった干渉が起きず、複数チームが同時に開発を進めても互いのスケジュールを圧迫しません。この分離アーキテクチャが、要件定義と並行して実データで検証を進めることを可能にし、プロジェクト全体のリードタイム短縮に直結します。

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

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

Snowflake導入の納期を短縮する最も効果的な手段が、最初のリリース範囲を厳しく絞り込むことです。全社のあらゆるデータと分析を一度に対象にすると、要件が膨れ上がり、データ連携先が増え、関係者の合意形成にも時間がかかって、いつまでたっても本番稼働にたどり着けません。これを避けるため、まずは成果が出やすく、経営や現場のインパクトが大きい1〜2のユースケースに絞ってPhase 1（MVP）を構築します。たとえば「月次の売上・粗利を商品・店舗軸で可視化する」「マーケティング施策ごとのCVRを一元的に見る」といった、明確な意思決定に直結するテーマを1つ選びます。対象を絞ることで、連携するデータソースが限定され、データモデルもシンプルになり、必要な仮想ウェアハウスも小さく済むため、3〜6か月という短期間で目に見える成果を出せます。この最初の成功体験が社内の理解と予算を引き出し、Phase 2以降の拡張をスムーズに進める推進力になります。Snowflakeはストレージとコンピュートが分離しているため、Phase 1で作ったデータ基盤に後からウェアハウスや分析用途を追加しても既存の構成を作り直す必要がなく、小さく作って育てていく段階的アプローチと非常に相性が良いのが強みです。最初から完璧な全社基盤を目指すのではなく、小さく作って早く価値を出し、そこから拡張していくという発想が、結果的に最短ルートになります。

スコープを絞ったうえで、開発・構築フェーズを2週間〜1か月単位のスプリントに区切り、アジャイルに進めることも納期短縮に有効です。データ基盤導入では、要件を最初にすべて固めてから一気に作るウォーターフォール型よりも、短いサイクルで「データを取り込む→集計する→ダッシュボードで見せる→フィードバックをもらう」を繰り返す進め方のほうが、データ活用の実像が見えやすく手戻りを減らせます。各スプリントの終わりに動くダッシュボードを関係者に見せることで、「この指標の定義が違う」「この切り口も欲しい」といった認識のずれを早期に発見・修正でき、後工程での大きな作り直しを防げます。加えてSnowflakeでは、データシェアリング機能を活かすことで、外部から取り込みたいデータを自前でETL構築せずに利用できるケースがあります。Snowflake Marketplaceで公開されている外部データや、取引先・グループ会社がSnowflakeを使っている場合の共有データは、物理的なコピーや連携パイプラインの構築なしに読み取り参照できるため、データ整備の工数そのものを削減できる場面があります。本番展開も、全部門への一斉リリースではなく、パイロット部門から段階的にロールアウトします。まず一部のユーザーに使ってもらい、運用上の問題やデータの不整合、クレジット消費の傾向を洗い出してから対象を広げることで、リスクを抑えつつ着実に定着させられます。段階的なロールアウトは、一見遠回りに見えますが、大規模な手戻りや運用トラブルによる遅延を防ぐことで、トータルの納期を守る現実的な戦略です。

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

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

Snowflake導入で最も多い納期遅延が、データ移行と元データの品質問題に起因するものです。Snowflakeはアカウント開設こそ容易ですが、データをロードしなければ性能も分析価値も生まれないため、データ移行が必須の工程になります。いざ実データを取り込もうとすると、表記ゆれ（同じ取引先が別名で登録されている等）、重複レコード、欠損値、フォーマットの不統一などが大量に見つかり、名寄せやクレンジングといった前処理だけで数か月を要することがあります。「アカウントを作ればすぐデータ活用」という期待に反して、現実にはこのデータ整備がプロジェクトの隠れた大きな山になるのです。対策の第一歩は、要件定義の段階で実データのサンプルを実際に確認し、データ品質と移行元システムの状態を早めに把握しておくことです。「データはきれいにそろっている」という前提を置かず、移行と前処理の工数を最初から見積もりに織り込んでおきます。また、完璧なマスターデータ整備を目指して立ち止まるのではなく、まず最優先のユースケースに必要な範囲だけを整備し、段階的に広げていくアプローチが有効です。SnowpipeやStreams & Tasksを使えば継続的なデータ取込を自動化できますが、その設計自体にも工数がかかるため、パイプラインの構築期間もスケジュールに明示的に確保しておくことが、遅延の連鎖を断つ鍵になります。

もう一つの典型的な遅延要因が、要件スコープの膨張と、コスト設計（クレジット消費の見積もり）の後回しです。前者については、ダッシュボードが形になってくると、関係者から「この指標も追加してほしい」「別の切り口でも見たい」という要望が次々と挙がり、対象データやデータモデルを作り直す重い手戻りが発生します。対策としては、要件定義の段階でPhase 1のスコープを明確に線引きし、追加要望は「影響範囲と工数を見積もってから合意する」という変更管理のプロセスを整えておくことです。挙がった要望はPhase 2以降のバックログとして記録し、最初のリリースをぶらさないことが重要です。後者のコスト設計については、Snowflakeはクレジット従量課金であるため、仮想ウェアハウスのサイズ設定や自動サスペンドの設定を後回しにすると、テスト段階やリリース直後にクレジット消費が想定を超え、コスト面の見直しのために追加のチューニング工数と期間が発生することがあります。Snowflakeは最小構成でも維持費が割高になりがちという特性もあるため、どのワークロードにどのサイズのウェアハウスを割り当て、どのタイミングで自動停止させるかというコスト設計を、構築フェーズと並行して早めに行っておくことが遅延回避につながります。数値検証（テスト）についても、データ分析基盤では見た目の実装以上に「集計値が正しいか」の確認に工数がかかるため、テスト工程には十分な期間を確保し、検証用のサンプルデータと期待値を早い段階で準備しておくことで、Snowflake導入固有の遅延リスクを最小化できます。

まとめ

Snowflake導入の開発期間は、単一データソースに絞った小規模なスタートで2〜4か月、複数ソースを統合する中規模の分析基盤で4〜9か月、データシェアリングやAI活用まで含む全社大規模基盤で6〜12か月以上が現実的な目安であり、工程配分は要件定義に約10%、設計に約10〜20%、データ加工・ダッシュボード構築を含む構築に約40〜60%、テスト・移行・運用開始に約10〜20%が標準です。SnowflakeはSaaS型フルマネージドかつマルチクラウド対応であるため、インフラ構築・運用をSnowflakeに肩代わりさせられ、特定クラウドの深い専門知識がなくても標準SQLで着手でき、コンピュートとストレージの分離と仮想ウェアハウスの即時起動によって立ち上げと並行開発を加速できるのが、AWS専用のRedshiftやエンジニア向けのDatabricksに対する期間面での強みです。さらに、1〜2ユースケースに絞ったMVPアプローチ、2週間〜1か月のスプリントによるアジャイル開発、データシェアリングの活用、パイロット部門からの段階的ロールアウトを組み合わせれば、着実に価値を出しながら短期間での本番稼働を実現できます。一方で、データ移行・前処理の見積もり漏れ、要件スコープの膨張、クレジットのコスト設計の後回しはデータ基盤導入固有の遅延要因となるため、実データの早期確認・変更管理プロセスの整備・コスト設計の前倒しといった対策をあらかじめ講じておくことが、納期遵守の鍵となります。これらの判断軸を押さえたうえで、自社のデータ活用に最適なスケジュールと体制を検討してください。

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

株式会社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を創業。