はじめに：なぜSnowflakeは「ヘン」だと言われるのか？
本記事は、11月28日に開催されたイベント「【SnowVillage＆みん強コラボ企画】 ここがヘンだよ！？ Snowflake」の12分のライトニングトークをベースに、LT内では話しきれなかった考察を追加して、再構成したものです。
LTをご視聴いただいた方にとっても新しい考察を楽しめると思いますので、ぜひ読んでいただければと思います。
ちなみに、このイベントのタイトルである「ここがヘンだよ！？ Snowflake 」にある、ヘンというカタカナ言葉はとても奥が深い言葉だと思っています。
「変な人」と書くと違和感や異常といったネガティブな印象がありますが、
「ヘンな人」と書くと、そこには「変わり種」「エキセントリック」といった何かユニークなニュアンスが含まれないでしょうか？
イベントのタイトルは、Snowflakeを知らない人でも、Snowflakeの良さを嫌味なく伝えるという目的に合わせた、よく考えられた名前だと気づきました。
そういうタイトルや名称の重要性に気づいた上で、Snowflake以外の方にも興味を持ってもらえるような、Snowflakeの「ヘンなところ」を探そうと考えた末、機能名称の付け方がとてもユニークだと気づきました。
そんなSnowflakeの機能名称についての考察を、記事として再編集してお届けします！
Snowflakeはマーケティングとコミュニティで「下駄を履いている」？
私は2020年からSnowflakeを利用していますが、他社の営業担当者からよく言われることがあります。
「Snowflakeさんは マーケティングにお金を掛けているから、強いですよね」
「コミュニティに勢いあるから、強いですよね」
つまり、外部からは「製品はそこそこのくせに、雰囲気良さげな『イメージ』戦略で勝ってる」と思われている、ヘンなプラットフォームなんです。
そんな「イメージ重視」な戦略は機能名にも表れています。
1. Snowflakeの命名哲学：「機能説明」より「イメージ」
Snowflakeの「イメージ重視」戦略は、過去の画期的な機能の名称にも色濃く現れています。
Time Travel（タイムトラベル＝時間旅行）
- この画期的なデータの時点復旧機能に対し、SF映画的なメタファーであるタイムトラベルという名称を採用しました。
- 「いつでも戻りたい時点に戻せる」ということが誰にでも伝わる直感的なイメージ重視な用語です。
- 本質的には「Point-in-time Recovery（時点復旧）」機能ですが、この表現ではシステム運用管理者しか理解できなかったでしょう。
- 結果、このSnowflakeの固有名称が、後にDatabricksやBigQueryなど他のDWHも追随し、同名称を採用するほど一般用語化しました。
Data Sharing（データシェアリング＝データを共有）
- DB間のコピーレス連携機能に対し、「データを共有する」というビジネス価値を直接表現する名称を採用しました。
- 本質的な機能としてはコピーレスのデータ連携機能「Zero Copy」ですが、この表現ではETL担当しか理解できなかったでしょう。
- これも後に、Redshiftが同じ名称を採用したり、Databricksが類似名称（Delta Sharing）で提供したりしています。
- また「Data Sharing」という言葉は双方向性を含意しており、一部の企業が命名する「Zero Copy」は多くの場合、片方向のデータ受信を指すことが多いように感じます。
最近の機能名も抽象的な効能を重視
このような命名戦略は、最近の先進的な機能にも続いています。
| 機能名 | 命名戦略 | 表現していること | 競合戦略との対比 |
|---|---|---|---|
| Snowflake Intelligence | 抽象的な効能 | 「知能」「インテリジェンス」＝なんか頭良さそうに聞こえる | Databricks ONE、Amazon Qなど |
| Snowflake Optima | 抽象的な効能 | 「最適」という意味のラテン語 ＝具体説明なしで雰囲気重視 | 競合は機能説明型（Predictive Optimizationなど） |
| Snowflake Postgres | 愛称を採用 | 正式名称（PostgreSQL）ではなく、開発者コミュニティで好まれる愛称（Postgres） を採用し、プロダクト愛と後発差別化を図っている | 競合は機能説明型（RDS for PostgreSQLなど） |
特にSnowflake Postgresの名称は、この中でも秀逸であると考えています。
PostgreSQLにおける主要なコントリビューターである、Crunchy Dataを買収し、Snowflake上のPostgreSQLマネージドサービスとして提供する野心的なプロジェクトです。
その一方でPostgreSQLユーザーにとって、オープンソースであるPostgreSQLという製品が脅かされるのではないかと不安視する声もありました。
それに対してSnowflakeは、PostgreSQLという正式名称ではなく、あえて愛称であるPostgresを冠することで、PostgreSQLへの敬意を表したのではないかと推測しています。
とはいえ、ここには後発として他のマネージドサービス名である「for PostgreSQL」を避けたという差別化戦略もあると考えられます。
つまり、Snowflakeは、先進的な機能がなかなか理解されづらいからこそ、「イメージしてもらいやすい名前」を付けることに拘っている、とてもヘンなプラットフォームなのです。
2. Horizonのパラドックス：記事数わずか18件の謎
さて、そんな「イメージ重視」のSnowflakeの主要機能の中で、なぜかあまり注目されていない機能があります。それが、Snowflake Horizonです。
公式ドキュメント抜粋
Snowflake Horizonは、コンプライアンス、セキュリティ、プライバシー、相互運用性、データガバナンスの機能を統合したスイートです。組織がコンプライアンス要件を満たしながら、データを管理し、最大の価値を引き出すことを支援します。
これは、機能セットで見るとDatabricks Unity Catalogに匹敵する超重要なコア機能です。
しかし、記事の浸透度を見てみると、圧倒的な差があります。
| プラットフォーム | 統合管理機能 | 記事検索結果数（Qiita/Zenn合算） |
|---|---|---|
| Databricks | Unity Catalog | 831件 |
| Snowflake | Horizon | 18件 |
※2025年11月末時点の検索結果ベースに記事を書いています
Qiita/Zennで Databricks Unity Catalog、Snowflake Horizonでの完全一致
Snowflake Horizonは、競合の約40分の1しか記事がありません。イメージにこだわるSnowflakeにしては、異常なまでに全然浸透していないのです。
また改めて他のプラットフォーム製品の統合管理機能との比較もしてみました。
各プラットフォームの統合管理機能比較
| プラットフォーム | 製品名 | 製品タイプ | 命名の特徴 | 提供開始 |
|---|---|---|---|---|
| AWS | Lake Formation | データレイク管理 ※AWS全体 |
機能説明型 （データレイク・編成） |
2019 |
| Google Cloud | Dataplex | データ管理PF ※GCP全体 |
技術的複合語 （データ・複合） |
2021 |
| Databricks | Unity Catalog | 統合管理 （カタログ+ガバナンス） |
機能説明型 （統合・カタログ） |
2021 |
| Microsoft | Purview | 統合管理 | 概念的英単語 （視野） |
2021 |
| Snowflake | Horizon | 統合管理 | 唯一の自然現象メタファー （地平線） |
2023 |
この比較から以下のことが分かります。
リリース時期の遅れ:
類似の統合管理機能は他社が一斉に2021年頃にリリースされており、2021年はある意味ではデータガバナンス元年と言えます。
それに対し、Snowflake Horizonが発表されたのは2023年末と、2年も遅れています。
命名の非直感性:
競合が「Lake Formation（機能説明型）」「Unity Catalog（機能説明型）」「Purview（概念的英単語）」など、機能や目的を連想させる名称を採用する中、Horizonは 「自然現象のメタファー（地平線）」 という名称です。
競合に遅れをとり、しかも「地平線」という、Snowflakeらしくない意味不明な名称を採用したHorizon。
一体、その裏には何があったのでしょうか？
ここからは、このSnowflake Horizonの命名に関する一つの物語を語りたいと思います。
3. IFストーリー：Horizon命名に隠された「ユーザーへの誓い」
ここからは、Snowflake社内で議論されたであろう（※公式発表ではありません）架空のプロダクト会議のストーリーを通じて、Horizonの深い意味を考察します。
競合後追い名称の拒否
2021年頃、競合他社が統合管理機能を一斉にリリースした際、Snowflake社内でも同様の機能（当時開発中）の名称が議論されました。
- 担当Aは「Snowflake Unity Catalog」「Snowflake Governance」「Snowflake Protect」といった、競合後追いや機能説明的な名称を提案します。
- しかし、担当Bは「俺たちは名前に拘っているんじゃないのか！」と猛反発します。後追い名称や、「Governance」のように一部の機能しか示さない名称は、Snowflakeの哲学に反するというのです。
「Horizon」が意味するもの
担当Bが提案した名称は「Snowflake Horizon」でした。
なぜ「地平線」なのか？
担当Bは、Snowflakeの機能群（コンプライアンス、セキュリティ、プライバシー、ディスカバリー、コラボレーション）を一つの言葉で表すのは既に難しくなっていると指摘します。
さらに、Snowflakeは今後、AI/ML（Cortex AIなど）やアプリケーション開発（Streamlit, NativeApps）へと領域を拡大していく中で、今自分たちが見えている景色だけで機能名を決めていいのか？と疑問を投げかけます。
-
担当Bの主張:
- Snowflakeが新しい機能を提供するほど、ユーザーが実現できることは広がります。しかし、機能が増えることは、Simplicity（シンプルさ）＝複雑性からの解放、というSnowflakeが目指すものと逆行し、ユーザーの負担（足かせ）になりかねません。
- ユーザーの高い要求に応えるためにSnowflakeの領域がどんどん広がっていくとき、ユーザーが目指す高みから見えるSnowflakeの大地、その 最大境界線が「地平線」 だと言えます。
- 「Horizon」とは、広がっているSnowflakeの大地の端である『地平線』までもしっかり見渡せるように、全ての機能を 「安心して運用できる」ための統合管理基盤 なのです。
Horizonは「誓いの言葉」
つまり、Horizonは単なるガバナンス機能群の名称ではなく、「我々を信じて、チャレンジしようとするユーザーを裏切らない」というSnowflake自身の「誓いの言葉」 なのです。
そして、担当Bはこう主張します。
「ユーザーに意識されることなく、当たり前にそこにある存在になろう！」
「この機能が注目されるとき、それは、きっとそのユーザーの地平線が霞んで、不安を感じている時です」
偉い人はこの熱意と思いに同意し、製品名にSnowflake Horizonを採用することを決定しました。
そして、競合を意識するのではなく、社内の多数の開発プロジェクトこそが競争相手だと皆に宣言します。
そして最後に「もしかすると、この機能は書かれる記事の少なさが評価になるかもしれんな」と結論付けて会議を終えました。
その後、2023年11月1日にSnowflake Horizonがリリースされました。
同年のSnowflake Summit、SnowdayではDWH機能以外の多くの機能がリリースされており、これらは全てSnowflake Horizonが提供する各機能において統治されています。
Snowflake Summit（2023年6月）、Snowday（2023年11月）
・Cortex AIシリーズ（AI機能）
・Snowpark Contena Service（コンテナサービス）
・Streamlit in Snowflake（オープンソースWebアプリフレームワーク）
・Native Apps Framework（Snowflake アプリケーション開発）
・SOS/QAS（パフォーマンスチューニング機能）
・Iceberg Table対応（オープンフォーマット対応）
..etc
Snowflake Horizonは、機能が増えることによって生じる複雑性という名の『摩擦』をゼロにするために、2年の時を経て、満を持してリリースされた基盤機能だったのかもしれません。
結論：Snowflakeは僕らの未来をイメージしている
と、色々と考察に耽りましたが、Snowflake社内で、そのような会議や議論があったかどうかは全く分かりません。またSnowflake社内の人に聞いても命名理由などは明かされていないとのことです。
ですが、もし、Snowflakeがこんなことを考えてこの名前を付けていたとしたら、
Snowflakeは、僕らが思っている以上に、「僕らの未来をイメージ」してくれていて、その実現にめちゃくちゃ拘っている、とってもヘンなプラットフォームではないでしょうか？
そんな拘り屋のヘンなプラットフォームのせいで、いつの間にか私たちは「どんな目標も実現できる！」と、彼らの「イメージ通り」になっているのかもしれません。
この話、信じるか、信じないかは、あなた次第です。
と終わりたいところですが、LTでは時間の都合で触れられなかった重要な補足を追記します。
4. 既存機能の統合ブランドである、Snowflake Horizon
2023年11月1日に発表されたSnowflake Horizonですが、その多くの機能は今までも提供していた既存機能をHorizonの名のもとに提供するというリブランディングでした。
その後の新機能はSnowflake Horizon配下で提供されておりますが、その際もHorizonというブランド名よりも各機能名称でアナウンスされることが多いのもの事実です。
記事が少ないのは、既存ユーザーにとって「ブランド統合に過ぎない」からであり、これは逆説的に、Horizonが新機能ではなく既存の成熟した機能群であることの証明とも言えます。
一方で、経営層やビジネスユーザーに対して、これらの統合管理機能の一つ一つを説明するのも理解してもらうのも難しいテーマだと考えています。
「地平線」という名称は、技術者には遠回りに見えても、経営層やビジネスユーザーに対しては「すべてを見渡せる安心感」として響きます。
つまり、Snowflakeの「ヘンさ」は、技術ドリブンではなくビジョンドリブンな姿勢の表れとも言えます。
5. AI時代のデータカタログ Select Star社の買収
Horizonが既存機能の統合ブランドであることは前述の通りですが、2025年11月24日、SnowflakeはSelect Star社の買収と共に、データカタログ機能である、Snowflake Horizon Catalog機能の強化を目指すことを発表しました。
ここでは逆に、Snowflake Horizon というブランド名を前面に出してきています。
Snowflake Horizon自身も一つの地平線のようにすでに提供済の機能の多くは意識させず、革新的な機能だけはその地平線を広げるものとして紹介する際に「地平線」という言葉を使っているのかもしれません。
そしてこの買収は、Snowflake Horizon機能群において、まさに地平線を広げる、AI時代のデータカタログを強化するためのプロダクト強化と言えます。
SnowflakeがOpen Semantic Interface（OSI）の推進に取り組んでおり、彼らとしてAI時代のデータマネジメントの中核の一つとして、データカタログやセマンティックレイヤーを位置付けているのは明白であり、Snowflake Horizon Catalogもまた今後広がり続けるデータとAIの世界を見渡す機能でありたいとの強い意志の表れと推測する事もできるでしょう。
そして、我々のAIワークロードが本格的に運用される前に、彼らがHorizonにこれらの機能を組み込むならば──
我々はまたもや、存在して当たり前の機能として利用し、Snowflake Horizonの記事を書くこともないまま、自分たちの目標に集中し続けることでしょう。
それこそが、Horizonが目指した世界なのかもしれません。
6. もう一つのIFストーリー：Horizonが描く「地平線＝一つの大地」という統合思想
さて、Select Star買収に関連してそこから生まれた、イベント登壇時には時間の関係で話さなかったもう一つの考察を述べたいと思います。
Select Star買収の真の意味を理解するには、Snowflakeの買収戦略全体を俯瞰する必要があります。
2020年のIPO以降、Snowflakeは9社を買収し、判明しているだけで**約$1.37B（約1,900億円以上）**を投じてきました。
Snowflake買収履歴の全体像
| 買収年月 | 企業名 | 買収金額 | 専門領域 | 統合後の機能 |
|---|---|---|---|---|
| 2022年3月 | Streamlit | $800M | アプリ開発フレームワーク | Streamlit in Snowflake |
| 2022年8月 | Applica | $170M | AI文書処理 | Document AI |
| 2023年2月 |
Mountain （Mobilize.Net） |
非公開 | マイグレーションツール | SnowConvert |
| 2023年5月 | Neeva | $150M | AI検索・LLM技術 | Snowflake Copilot Universal Search |
| 2023年10月 | Ponder | 非公開 | Python/Modin | Snowpark強化 |
| 2024年5月 | TruEra | 非公開 | AI/ML監視 | AI Observability |
| 2024年6月 | Crunchy Data | $250M | PostgreSQL専門企業 | Snowflake Postgres |
| 2024年11月 | Datavolo | 非公開 | データパイプライン （Apache NiFi） |
データ統合基盤 |
| 2024年11月 | Select Star | 非公開 | データカタログ （メタデータコンテキスト） |
Horizon Catalog強化 |
この一覧を見ると、各社の専門領域がまったくバラバラであることが分かります。
アプリ開発、文書AI、検索、Python、監視、データベース、パイプライン、カタログ──これらは本来、別々のプロダクトとして提供されてもおかしくない領域です。
分断ではなく、統合という選択
しかし、Snowflakeはこれらを個別のプロダクトとして提供していません。
すべてが「Snowflake AI Data Cloud」という一つのプラットフォームに統合され、Snowflake Horizonという統合ガバナンス基盤の下で提供されています。
もしSnowflakeが各買収企業の製品を個別に提供していたら、ユーザーは以下の問題に直面していたでしょう。
- 各製品ごとに異なる認証・権限管理: Streamlit用、Postgres用、Search用...と個別にアカウント管理が必要になる
- データの重複やコピー: 各製品間でデータを移動させるためのETL処理が発生する
- 統合されないメタデータ: どの製品で何をしたかの履歴が分断され、追跡不可能になる
- バラバラなユーザー体験: それぞれのUIやAPI仕様を学習する必要がある
これは、まさに 「複雑性の爆発」 です。
「地平線」が示す「一つの大地」
ここで、Horizonという名称が持つもう一つの深い意味が見えてきます。
地平線とは、「見渡せる大地の端」です。そして、その地平線の内側は──「一つの連続した大地」 なのです。
つまり、Horizonは以下の三重の意味を持つと考えられます：
- 可視性: すべての機能を見渡せる（Universal Search、Catalogなど）
- 安心感: 統合ガバナンスによる安定した運用基盤
- 統合性: バラバラの買収企業・機能が「地平線＝一つの大地」として提供される
Snowflakeは、買収企業を別々の島として孤立させるのではなく、一つの大地として統合することを選びました。
そして、その統合された大地全体を見渡せるようにするための基盤が、Snowflake Horizonなのです。
「一つの大地」では同じルールが適用される
地平線の内側──つまり「一つの大地」の最も重要な特徴は、どこに立っても同じルールが適用されることです。
同じ重力、同じ大気、同じ法則。
Snowflake Horizonも同じです。
- 同じ認証・認可: すべての機能でSnowflakeアカウント一つ（Single Sign-On）
- 同じガバナンスポリシー: すべてのデータにRow-Level Security、Masking等が適用可能
- 同じメタデータ管理: すべての操作がUniversal Catalogで一元管理
- 同じ監査ログ: すべてのアクセスがAccess Historyで追跡可能
買収企業がどれだけ増えても、ユーザーが理解すべきは「一つの大地のルール」だけなのです。
統合が進めば、こんな世界が実現します。
Snowflake上でStreamlitアプリを作る。Universal Searchでデータを探す。買収したSelect Starの技術でAI時代のデータカタログを通じてデータ資産を発見し、理解する。TruEraの技術でAIモデルを監視する。
その時、ユーザーが意識するのは
- 認証: Snowflakeアカウント一つだけ
- 権限: Snowflakeのロール（RBAC）一つだけ
- メタデータ: Snowflake Horizon Catalogが一元管理
- 監査: Snowflakeの監査ログ一つだけ
すでにStreamlitは完全に統合され、「Streamlit in Snowflake」として提供されています。Universal Searchも利用可能です。そして今後、Select StarやTruEraなどの技術も、同じ「一つの大地」に統合されていくでしょう。
4社の異なる技術を使っているはずなのに、ユーザー体験は 「Snowflakeを使っている」 だけ──それが、Snowflakeの「地平線＝一つの大地」が目指す世界なのです。
買収を重ねるほど、シンプルになるという逆説
普通に考えれば、買収を重ねるほど、プラットフォームは複雑になります。
9社もの異なる技術を統合すれば、ユーザーは混乱し、学習コストは増大するはずです。
しかし、Snowflakeが目指しているのは逆のアプローチです。
「地平線＝一つの大地」という統合思想により、買収企業が増えても、ユーザーにとってはむしろシンプルな体験を提供し続ける──それがSnowflakeのビジョンなのです。
すでにStreamlitは完全に統合され、「Streamlit in Snowflake」として提供されています。Universal Searchも利用可能です。そして今後、Select StarやTruEraなどの技術も、同じ「一つの大地」に統合されていくでしょう。
そして重要なのは、地平線が広がるほど、ユーザーができることも広がるということです。
これこそが、Snowflakeが目指す「Simplicity（シンプルさ）＝複雑性からの解放」の本質なのではないでしょうか。
地平線が広がり続ける意味
2024年11月だけで、Select StarとDatavoloという2社を立て続けに買収したことは象徴的です。
これは、「一つの大地」がさらに広がることを意味します。
新しい機能が追加されても、それは別の島として孤立するのではなく、既存の大地に自然に接続され、同じHorizonの下で管理されます。
ユーザーから見れば、地平線は常に見渡せる位置にあり、その内側の大地は分断されることなく一つに繋がっているのです。
Snowflakeが目指している世界：
- Streamlitでアプリを作る（すでに統合済）→ 同じSnowflakeアカウントで認証
- Universal Searchでデータを探す（すでに利用可能）→ 同じメタデータストアを参照
- Select Starの技術でAI向けのデータカタログを構築する（統合進行中）→ 同じHorizon Catalogで管理
- TruEraの技術でAIを監視する（統合予定）→ 同じガバナンス基盤で統制
すべてがシームレスに繋がっていくのです。
もう一つのIFストーリー：2021年の架空の会議・続編
ここで、もう一度、あの架空のプロダクト会議に戻ってみましょう。
2021年、担当Bが「Horizon」という名称を提案した時、実はこんな言葉も添えていたのかもしれません。
「俺たちは、これから多くの企業を買収することになるだろう。
Streamlit、検索技術、AI、データベース...それぞれが素晴らしい技術を持っている。でも、それをバラバラに提供したら、ユーザーは混乱する。
それぞれに異なるアカウント、異なる権限、異なるルール...
それは、俺たちが目指す『Simplicity』とは真逆だ。だから、俺たちは『地平線』という約束をするんだ。
どれだけ大地が広がっても、それは一つの大地であり続ける。
そこでは同じルールが適用され、ユーザーは常にその全体を見渡せる。それが、Horizonだ」
偉い人は頷き、こう言ったかもしれません。
「つまり、Horizonは買収プロダクトの統合戦略そのものだな」
担当Bは笑顔で答えます。
「そうです。Horizonは機能名であると同時に、俺たちの統合への約束なんです。どれだけ買収しても、どれだけ機能が増えても、ユーザーから見れば常に『一つの大地』であり続ける──それが、俺たちの誓いです」
この物語が示唆すること
もちろん、こんな会議があったかどうかは分かりません。
しかし、2020年から2024年にかけての9社・$1.37Bという買収実績と、そのすべてが「一つの大地」として統合されている事実を見れば、Snowflakeが明確な統合思想を持っていることは間違いありません。
そして、その統合思想を体現する名称が「Horizon（地平線）」なのだとすれば──
Snowflakeは、僕らが思っている以上に、「僕らの未来」を見据えて、その実現に本気で取り組んでいる、とってもヘンなプラットフォームなのかもしれません。
結局、Snowflake Horizonとはいったい何なのか？
私の２つのIFストーリーはひとまず置いておくとして、客観的事実として言えることがあります。
Snowflake Horizonは、Snowflakeの根幹をなす統合管理機能であり、今なお増え続ける多数の機能を、一貫した設計思想の中で提供し続けています。
その基本思想の多くは既存機能からの継承ですが、これにより、ユーザーにとって革新的な機能であっても、その利用方法や権限管理、運用方法に迷うことは少ないのです。
具体例で見てみましょう。
Streamlit in Snowflakeは、2022年に$800Mで買収された革新的なアプリ開発フレームワークです。しかし、Snowflakeユーザーにとって、Streamlitの運用は驚くほどシンプルです。
- 認証: SnowflakeのRBAC（ロールベースアクセス制御）で管理
- 実行: Snowflakeのウェアハウスで実行
- 監査: 実行ログもSnowflakeの監査機能で追跡可能
これらは公式ドキュメントを一度読めば簡単に理解できる基本動作です。アプリケーションとしての実装方法を除けば、多くの技術記事を探す必要はありません。
そして、これこそがSnowflake Horizonの真の価値なのです。
革新的な機能が追加されても、ユーザーは「Snowflakeの基本ルール」を理解していれば、すぐに使い始めることができる──この「シンプルさ」を実現するための統合管理基盤が、Horizonなのです。
特別な難易度を持たず、記事にされにくく、結果として根幹機能であるにもかかわらず、数十件に満たない記事しか存在しない──
それは、第一のIFストーリーで述べた担当Bの予言「記事の少なさが評価になる」が、現実となったことの証左なのかもしれません。
Snowflakeは実直に一歩ずつ歩みを進めている
冒頭で触れた、競合他社からの「マーケティングにお金を掛けているから強い」という評価──
しかし、この記事を通じて見てきたSnowflakeの姿は、そのイメージとは大きく異なるのではないでしょうか。
Snowflake自身は、我々が思っている以上に、「我々の将来や未来」をイメージしてくれています。そして、より良くなって欲しいと願ってくれています。
そして、マーケティングが上手い会社と言われているとは思えないほど、我々に多くを語らず、ただ実直に理想を追求する探究者のように、より良い機能を提供し続けています。
重要なのは、イメージするだけでなく、その歩みが着実に前に進んでいることです。
Gen2 Warehouseによる基本性能の向上、Snowflake Optimaによる自律最適化、Query Insightsによる運用支援──その歩みは我々の半歩先を常に準備しており、結果として、我々は「彼らのイメージ通りの理想の成功体験」を最短で得られているのかもしれません。
外から見れば「マーケティングが上手い」。
しかし内側から見れば「実直に理想を追求している」。
この二つの顔こそが、Snowflakeの「ヘンさ」の本質なのかもしれません。
最後に
イベントで最後に指摘されましたが、こんなことに拘ったり、一人で考察している私自身が一番ヘンであり、それはSnowflakeへの愛情表現の一つではないかと。
ヒトは自分の好きなことを話す時、とても楽しそうに振舞うものです。
イベント配信のアーカイブを見ていただければ、きっとそこに答えはあるように思います。
それではまた次の記事でお会いしましょう。
Snowflake データクラウドのユーザ会 SnowVillage のメンバーで運営しています。 Publication参加方法はこちらをご参照ください。 zenn.dev/dataheroes/articles/db5da0959b4bdd
Discussion