本記事では、Snowflake・Matillion・Tableauを活用したデータ基盤開発において、開発手順とドキュメントの標準化により、属人化の解消と工数削減を実現した事例をご紹介します。
複数プロジェクトにわたるデータ基盤開発では、属人的な開発手法による品質のばらつきやコミュニケーションコストの増大が発生することも多々あります。この事例では、データパイプラインの設計ルールとテスト仕様を明確に定義することで、誰もが理解・再現できる開発標準を整備することで、開発期間の短縮と品質の均一化を実現しました。
複数プロジェクトにおける品質管理の統一やコミュニケーションコストの削減に課題をお持ちの方におすすめです。ぜひ本記事をご覧ください。
IoTデータ向けデータ基盤構築支援
本プロジェクトは工場に設置された装置から取得される分単位のセンサデータを、時間・日単位に集計してTableauでダッシュボード化するプロジェクトでした。GRIではデータ集計とパイプライン構築を担当していました。
アドホックな開発による属人化と、品質均一化への課題
GRIでは、先行する別プロジェクトの提案時点から、中長期的なデータ基盤構築を見据えた標準化を想定していました。当初のプロジェクトではアドホックに開発が進められましたが、その後、数珠つなぎに複数のプロジェクトが進行することとなりました。プロジェクトを跨いで開発を進める中で、属人化を排除しつつも、作業効率を向上しながら、品質の均一化を実現し、品質を担保するための標準化ルールが必要となりました。
Matillion×Snowflake開発における標準化の具体策
これらの課題を解決するため、開発手順やドキュメント形式をプロジェクト横断の共通ルールとして定めました。実施した標準化の内容について、解説していきます。
開発ドキュメントとテスト仕様のフォーマット統一
システムの精度を担保するため、設計書やテスト仕様書のフォーマットを統一しました。各ドキュメントは作成目的とタイミングを明確にし、実装者・レビュアー・運用者が共通認識を持つことができるようにしています。
主要なドキュメントと作成目的
- データフロー図：システム全体のデータの流れを可視化
- ジョブ一覧 / 定義書：処理概要や依存関係、具体的な処理ロジックの明文化
- テーブル定義書：データベースに格納される各テーブルの構造定義
- 単体 / 結合 / 統合テスト仕様書：品質保証・第三者確認のエビデンス
- リリース計画書：本番環境への移行手順とスケジュールの明確化
また、テストで確認すべき項目は、ダッシュボードで正しい値が見られるか、ジョブが正しく実行されるかといった最終納品物が実運用で使用できるかという点を基準に選定しています。
環境分離とMatillionジョブ階層のルール化
Matillionの開発・運用環境を以下の3つに明確に分離し、ジョブの階層構造をルール化しました。
- 開発環境
- 本番環境（実データを加工するパイプラインを運用）
- 運用中のパイプラインに不具合があった場合の原因探索・修正環境
また、Matillionのジョブ階層のルールを定めています。プロジェクト単位のフォルダ配下で、ジョブの役割を以下のように分割しています。
- common：全体の更新方法（毎時実行の差分更新、週次実行の全件洗い替えなど）を管理するOrchestrationジョブを配置。スケジューラーの対象とする。
- main：Transformationジョブを動かすためのOrchestrationジョブ。実行の正否はここで判断する。
- trans：実際にデータを読み込み、成形して出力するTransformationジョブ。
可読性を高めるコンポーネント配置とSnowflake命名規則
初めてパイプラインを見る人でも大枠を理解できるよう、命名規則と配置ルールを厳格化しました。
Matillionのコンポーネントでは命名規則を、「行う操作_対象」の順にしています。（例：PIVOT_カラム名、JOIN_テーブル名）。また、Matillionではグラフィカルにコンポーネント配置をすることができるため、複数の入力がある場合には、始点は左上、終わりは右下になるように配置するようにしていたり、始点の一番下と出力の深さを揃え、入力と出力が1:1の場合は直線に配置するように、直観的に理解しやすいコンポーネント配置にしています。
さらに、Snowflake側のデータ層を以下の3段階に分け、役割を明確化しています。
- 生データ（センサから取得したままのデータ）
- 加工データ（集計・演算用に調整したデータ）
- 集計・演算データ（Matillionから出力されるデータ）
アウトプットテーブルの命名規則は、「やった作業_データの時間粒度_識別名」で統一することで、可読性を高めています。
開発期間の短縮とコミュニケーションコストの削減
これらの標準化ルールを導入した結果、実作業において明確なメリットを得ることができました。
共通認識の形成によるボトルネックの早期発見
設計書や報告書のフォーマットが定まったことで、作業時間が大幅に短縮されました。標準化を経たことにより、後続のプロジェクトでは設計書作成にかかる時間を3割削減することができました。
また、様々なステークホルダーと同時並行で開発を行う際にも、開発標準があることにより共通認識が形成され、コミュニケーションコストの削減につなげることができました。仕様書と格納データの不一致といったプロジェクトの詰まりやすいポイントを事前に検知できるようになったことも大きな成果だと言えます。
失敗から学ぶ注意点：プロジェクト目的の理解が手戻りを防ぐ
一方で、標準化を進める上での注意すべき教訓も得ることができました。
形式や進め方が共通化されると、作業者は決められたタスクをこなすだけといったスタンスに陥りがちです。過去の失敗例としては、ダッシュボードに表示すべき項目が欠けた状態で開発・テストが進み、大きな手戻りが発生したこともありました。
これは、作業者が「センサデータを正しく集計しダッシュボードに表示する」という最終目的を深く理解できないままに作業を進めていたことが原因であると考えています。標準化された環境であったとしても、扱うデータや状況はプロジェクトごとに異なります。個々のタスクにおいて、全体スケジュールとプロジェクトの目的を常に意識し、確認・判断することが重要です。
まとめ：標準化を成功させる3つのポイント
本事例を通じて得られた、データ基盤開発における標準化のポイントは以下の3つです。
- 標準化による工数削減：ドキュメントやパイプライン設計の共通ルール化は、属人化を防ぎ、開発期間の短縮に直結する。
- 可読性の高いルール設計：命名規則やフォルダ構成、コンポーネントの配置ルールを定め、初見のメンバーでもパイプラインの大枠を即座に理解できる状態を作る。
- 目的共有と密な連携：標準化は単なる作業のテンプレート化ではない。チーム内および顧客との日々のコミュニケーションを通じて、プロジェクトの最終目的にズレがないかを確認し続けることが手戻りを防ぐ鍵となる。
GRIでは、センサーデータをはじめとするデータ基盤開発の支援を多数行っています。データの活用やデータ基盤構築にお悩みをお持ちの方は、ぜひお気軽にお問い合わせください。
