アナリティクスエンジニアの okoshi です。 私は、2024年3月まではWebエンジニアをしていましたが、ビッグデータに興味を持ち、データエンジニアを経験した後にアナリティクスエンジニアに転向しました。
新しいSaaSを導入するときにきになるのは、自分たちが期待する結果が本当に得られるか、そして日々の運用の中で無理なく使い続けられるかという点です。 dbt Cloudについても、マニュアルや紹介資料を読むだけではみえにくい部分、それは実際の使い勝手や機能の挙動、契約プランの適性などを確かめておきたいと考えました。
そこで今回は、dbt Cloudの全機能を一通り検証し、使える機能・運用上注意が必要な機能を整理しました。 想定通りに動作する部分も多くありましたが、実際に触れてみることで始めてわかることも多くありました。
特に印象に残ったのは、ベンダーのサポート対応の早さと丁寧さです。これはドキュメントではわからない部分であり、実際に検証してこそ得られる実感でした。
本記事では、検証の進め方や判断の観点、そして実際に得られた気づきを整理しています。同じようにdbt Cloudの導入を検討している方や、SaaSの評価・検証を行う方の参考になれば幸いです。
検証の目的と進め方
この検証では、dbt Cloudの全機能を対象に「自分たちの想定している使い方が現実的に実現できるか」を確認することを目的としました。
上記ページにある機能をもとに、
- ドキュメントに書いてある内容に対する自分たちの理解が正しいことの確認
- 我々はすでにdbt Coreを使って独自に構築した仕組みを運用していたので、同様あるいは近い運用ができることの確認
- 実際の業務環境における制約や注意点があるか
を検証項目として整理しました。 *1
各機能について、優先度の高いもの順に検証を開始。結果や気づきをドキュメント化し、後からどのような検証をしたかスクリーンショットとともに記録しています。
このように全機能を通して確認したことで、「使える/使えない」を判断するだけでなく、運用を見据えた機能選定基準を明確にできたと感じています。
導入見送り要因の整理
検証をはじめる前に、導入を見送る可能性がある要因をあらかじめ整理しました。 SaaSの導入検証では、「できること」だけでなく「できなかった場合にどう判断するか」を明確にしておくことが重要だと思います。
主な見送り要因として想定していたのは次の通りです
リネージの表示パフォーマンス
検証前にあった課題としてすでに作られている巨大なSQLのリネージの確認に時間がかかっている、エンジニアの介在が必要である、ということがあったがdbt Coreでdbt docs generateでリネージを表示する運用であった方が効率がよいと判断される場合は見送る。当社のセキュリティ基準を満たすこと
当社にはSaaSを使用するにあたって、厳しい基準が設けられています。社内の基準を満たさない場合は見送る。普段利用する機能の使用感・パフォーマンス
dbt Cloud CLI、dbt Cloud IDEを利用するにあたって、表示パフォーマンスがよくなかったり、それによる使用感の悪さにより、dbt CoreとVisual Studio Codeでの開発の方が効率よく開発ができると判断される場合に見送る。これは検証後の議論を必要とする。
これらを事前に定義しておいたことで、検証結果を感覚的に評価せず、明確な基準に基づいて導入可否を判断できました。 この基準は、添付資料内のコメントにも反映しています。
検証項目の設計方針
要求と利用シナリオを明確にする
各機能の要求と利用シナリオを明確にします。これは、ドキュメントを参考に、どう使用したいかという意思を交える必要があります。ドキュメント通りの動作確認だけでは意味がありません。
例えば、dbt Cloud CLIを例に挙げます。これは「dbt Cloud CLIの基本的な操作性と、dbt Coreとの使用感の違いを検証する。」としました。これは、dbt Coreの使用経験を踏まえ、dbt Cloud CLIの使いやすさ、既存ワークフローへの適合性を評価する意図があります。単なる機能検証に留まらず、実際の運用における効率性向上を目指します。
また、Enable Continuous Integrationも例に挙げてみます。こちらは「dbt Cloudの継続的インテグレーション機能が正常に動作し、コードの変更が自動的にテストされ、デプロイ前の品質保証が適切に行われることを確認する。特に、変更前後の差分確認機能が期待通りに機能し、意図しない変更が本番環境に影響を与えないことを検証する。」としました。これは、本番環境への意図しない変更を防ぎ、デプロイ前の品質を保証する意図があります。安定したデータパイプライン運用とリスク回避を重視しています。
手順を明確にする
検証前は、ドキュメントを参考にしながら、実現手順を明確にしました。この段階で、実現可否の見通しを立て、「できそうだ」と判断できれば検証前での手順の記入は完了としました。
検証中は、実際に行った手順や入力を詳細に記録し、スクリーンショットを検証ドキュメントに貼り付けました。これは、dbt Cloudが頻繁にアップデートされるため、過去の操作と現在の状態の変化を把握するためです。これにより、何かあったときのサポートへの問い合わせがスムーズになり、記憶に頼る必要がなくなります。
この作業は非常に手間がかかりますが、検証後の議論において、根拠の構築に大きく貢献しました。ここで注意しなければならないのが、例えばAPIトークンを貼るような場合は注意が必要です。社内でしか展開しないドキュメントとはいえ、使えば環境を壊してしまうことも可能なので、スクリーンショットをマスクするなどといった配慮が必要な場合があります。
期待される結果を設定する
期待される結果は、機能によって主に以下のような観点でどれか一つ、あるいは複数を組み合わせて設定しています。
- 機能の正確な動作: 各機能が意図した通りに、エラーなく正しく動作することを重視。
- パフォーマンス: 処理速度や応答時間など、システムが効率的に動作し、ユーザーがストレスなく利用できること。
- 使いやすさ・操作性: ユーザーが直感的に操作でき、既存のワークフローからの移行がスムーズであるかなど、ユーザーエクスペリエンスを考慮。
- 自動化と効率化: 手作業を削減し、プロセスを自動化することで、開発や運用が効率的に進められること。
- 品質保証とリスク管理: 意図しない変更による問題を防ぎ、システムの品質を維持すること。
これらの基準は、単に機能が利用可能であるかだけでなく、実際のビジネス運用においてどれだけ効果的で、安全で、効率的であるかを評価する意図があります。
検証結果を記入する
全体の評価は、ユーザー視点での使いやすさやワークフローへの適合性を重視した使用感と、技術的な処理速度や効率性を重視したパフォーマンスに焦点を当てて記述しました。
各機能の検証結果は、単なる合否だけでなく、使用を通じて得られた知見や応用アイデアも詳細に記述しました。これは、実際に使用してみなければ分からない点や、新たな発想を記録することの重要性を考慮したものです。パフォーマンスについては、具体的な時間基準を設けず、作業に支障のないレベルであれば「問題ないレベル」と評価しました。また、外部SaaSとの連携に依存する項目については、「BigQueryの性能に依存するため問題なし」といった形で評価しました。
さらに、公式ドキュメントには明記されていないものの、使用経験から推測される内部メカニズムについても考察を加えました。このような考察は、機能評価だけでなく、実際の業務における実用性や影響を深く掘り下げる上で有効であると考えております。
添付の資料について
実際に検証して記入した資料を公開いたします。一部非公開情報はマスクさせていただいておりますが、どのようなテイストで記入をしていったかを参考にしていただけると思いますので是非ごらんください。 なお、資料中のdbt Cloudの機能名は検証時のものをそのまま使用しております。検証中に機能名が変わったものに関しては新旧の名称が混在しておりますので予めご了承ください。
検証してわかった、ドキュメントに載っていないこと
ドキュメントを読んだだけではわからない、実際に触れてみて初めてわかったことがいくつかあったので、ご紹介させていただきます。
サポートのレスポンスが「とにかく」早い！
トライアル期間中もサポートを利用できたので、試しに利用してみたのですが、日中の連絡はその日のうちにレスポンスがあり、非常に丁寧な対応でした。これは本当に印象的で、ドキュメントだけではわからない、検証してこそ得られた実感です。もちろん、dbt Cloudを本格導入した今もサポート体制は変わらないので、安心して利用できています。
担当者の方も迅速に対応してくれた
dbt Cloudの検証はトライアル利用で行いましたが、これと並行して、社内のセキュリティ要件に適合するかどうかの調査や法務との調整もおこなっていました。質問を投げると、担当者の方が即座に返答をくださいました。社内調整も同時にやっていて非常に忙しかったので、この迅速なレスポンスには本当に助けられました。
非常に頻繁にアップデートされている
検証中に大きなアップデートがあったのは先述の通りですが、それ以外でも小さな修正がものすごく頻繁に行われていました。ドキュメントに不備があった際も指摘したら、すばやく修正されたのは驚きました。
まとめ
この検証は、単にdbt Cloudの機能が動作するかどうかを確認するだけでなく、私たちが期待する結果が本当に得られるか、そして日々の運用の中で無理なく使い続けられるかという、実運用を見据えた目的をもって全機能を対象に実施しました。
検証を進めるにあたり、リネージの表示パフォーマンス、社内のセキュリティ基準への適合、CLI/IDEの使用感・パフォーマンスといった導入を見送る可能性がある要因を事前に明確に定義しました。この明確な基準設定により、検証結果を感覚的に評価せず、明確な基準に基づいて導入可否を判断することが可能になりました。
実際に検証を行ったことで、ドキュメントや資料からは見えにくい重要な要素が明らかになりました。特に、ベンダーのサポート対応の早さと丁寧さは非常に印象的であり、トライアル期間中も日中の連絡に対してその日のうちにレスポンスが得られるなど、導入後の安心感につながる実感を得られました。また、dbt Cloudが非常に頻繁にアップデートされている点も重要な気づきであり、これに対応するため、検証中に実際に行った手順や入力内容を詳細に記録することが、その後に行われた導入可否の議論における根拠の構築に大きく貢献しました。
このように徹底した検証プロセスを通じて、機能の正確な動作だけでなく、運用を見据えた機能選定基準を明確にすることができました。本記事で整理した検証の進め方や判断の観点が、同様にSaaSの評価・検証を行う皆様の参考になれば幸いです。
*1:検証を行った時期は2025年の5月から6月のため、当時あった機能で検証しています。また検証中に機能名が変更(例えばdbt Canvasは以前はVisual Editorという名称でベータ版として存在していました)になったものもあります。現在とは異なりますのでご承知おきください。
