はじめに
こんにちは。サイボウズでデータエンジニア兼データアナリストとして働いている喜多です。
現在、私はData Management部でデータエンジニアとデータアナリストの両方の役割を担っています。
サイボウズのData Management部では、所属メンバー全員がデータエンジニアとデータアナリストの両方の業務を行うという、他社では珍しい体制を取っています。
実際に採用要項でも「データエンジニア兼アナリスト」として、両方で活躍できる人材を募集しているほどです。[1]
サイボウズに入社して2年、データエンジニア兼データアナリストとしてデータ基盤開発からデータ活用まで一気通貫で経験する中で、それぞれの職種の知見がもう片方の職種の業務を行う際に非常に役に立っていると感じます。
今回は、「データエンジニアとしてデータアナリストの経験があってよかったこと」と「データアナリストとしてデータエンジニアの経験があってよかったこと」について書こうと思います。
サイボウズでの役割定義
まず、弊社でのデータエンジニアとデータアナリストの役割を簡単に説明します。
先に以前投稿したサイボウズのデータ基盤を紹介した記事を読むとより理解しやすいと思います。
データエンジニア
- ELTパイプラインの開発によるデータ基盤への新規テーブル・カラムの追加
- データ基盤(BigQuery)やBIツール、その他データ連携に関するリソースの運用管理
データアナリスト
- 他部署からのデータ活用に関する相談のヒアリング・要件定義のサポート
- データマートや分析用クエリの作成
- BIツールでのデータの可視化やレポート作成
- データ活用促進のための勉強会の実施
データアナリストの経験がデータエンジニアで活きたこと
ユーザーを意識したデータモデリング
データアナリストとして、様々な部署の分析を手伝う中で、どういった軸で集計を行うかや、よく使う集計条件などを深く理解できました。
この理解によって、ユーザーにとってより活用しやすいデータモデリングが可能になったと思います。
具体的には以下のようなことが挙げられます。
テーブルやカラムの命名規則の統一
「会社名」や「部署名」など、同じ値を持つカラム名は必ず統一するという意識が格段に高まりました。
同じデータソースのテーブルはもちろん異なるデータソースでも同じ情報であれば、基本同じカラム名として定義するようにしています。
また細かいところですが、ARRAY型のカラムではカラム名の最後に複数のsをつけることや、「ライセンス数」などの数を表すカラムにはlicense_countにするといった意識も生まれました。
これにより、カラム名を見ただけでどういった値を持つのか理解しやすくなり、クエリも書きやすくなったと思っています。
頻繁に使用するロジックのテーブル化
分析作業で頻繁に使うフィルター条件がある場合、あらかじめそのロジックをカラムとして持たせたテーブルを作成しました。
例えば、弊社製品を利用しているユーザーテーブルがあるのですが、検証用の社内ユーザーがかなり多いので、分析時に様々な条件で除外する必要がありました。
この手間を解消するために、ユーザーテーブルに社内使用かどうかがわかるBoolean型のカラムを追加しました。
また、頻繁にJOINするテーブル同士があれば、結合済みのテーブルを用意したほうが良いのではないかという検討もしています。
データ品質向上への意識改善
ユーザーのデータ活用を意識することで、より正しいデータの提供を心がけるようになりました。
具体的には:
- 分析やBIツールでの可視化経験から、データ連携が止まった際に分析やレポート結果に問題がないか意識するようになった。
- カラムのnullチェックやdbtのデータテストで異常値が含まれていないかの検証を実装した。
- モデルが正しい結果を集計することの担保として、dbtのユニットテストを導入した。
実際にデータを使う立場になることで、データの品質の重要性をより深く理解し、品質向上のための仕組み作りが必要なことを感じました。
非技術者とのコミュニケーションスキルの向上
データアナリストとして他部署のヒアリングや要件定義のサポートを行う際に、非技術者に対して技術的な内容をわかりやすく説明することを意識しています。
データエンジニアは比較的チームメンバーと話す機会が多いのですが、他部署の人とやり取りする際でも、データアナリストの経験から相手の立場になった説明ができるようになったと思います。
データエンジニアの経験がデータアナリストで活きたこと
データ連携の仕様理解によるクエリ作成の正確性と即時性の向上
データエンジニアの経験として最も実感したメリットは、データ連携の仕様を深く理解していることで正確なクエリを即座に作成できることです。
データ基盤にあるテーブルがいつどのように連携されているか、連携時にどのような加工が行われているかといった仕様面の情報はデータエンジニア以外だと把握が困難です。
しかし、データ基盤の開発・運用の経験があると、これらを知ったうえで分析作業ができます。
その結果、他部署からデータ活用の依頼を受けた際に、データエンジニアに確認することなく分析や集計の可否を回答できました。
また、データ連携の仕様を理解していることでデータの制約や特性を把握しているため、より正確なクエリを作成するのに役立ちます。
データの異常に対する感度の上昇
データエンジニアとして連携の仕様を把握していることで、入るはずのないデータが入っているという異常に気づきやすくなりました。
データ連携時に定義した仕様通りの値が入っていなければ、データ連携で何らかの間違いが発生していることを即座に察知できるため、分析結果の信頼性を向上させています。
コスト・リソースを意識したクエリ実行
データ基盤の運用を行っているため、クエリの実行時間や利用料金を常に意識しています。
例えば、パーティションやクラスタリングを活用したクエリを書くことで実行時間の短縮や利用料金を抑えることが可能です。
兼務ならではの課題
担当領域の広さ
データエンジニアとデータアナリストを兼任しているため、把握すべき領域が非常に広範囲に及びます。
社内データソースの仕様の把握から始まり、テーブル構成、データ連携、リソース管理、分析や可視化のサポート、作成したレポートの管理など…領域が広いと非常に大変なことを実感しました。
常になんとかキャッチアップしながら頑張っています。
スキルの深さVS幅のジレンマ
担当領域の広さにつながるのですが、幅広いスキルを手に入れることができる代わりに深さに関しては、データエンジニアやデータアナリストを専門で担当する場合より少し浅い可能性があります。
例えば、データエンジニアとしてELTパイプラインの開発やリファクタリングを取り組んでいる際に、分析業務を行うことや、逆にBIツールやデータ分析手法を深堀りしたい際にデータ連携が失敗したことによる緊急対応が入ることがあります。
そういった使う技術が頻繁に変わることで、幅は広がる一方、深堀りまでできないときがあります。
キャリアとしての価値
兼務ならではの課題はありますが、個人的にデータエンジニアとデータアナリストの両方を経験して非常に良かったと感じています。
先に上げたメリットがあったことに加えて、データ活用に対する価値提供を俯瞰的に考えることができるようになりました。
具体的には、ユーザーにどうすればよりデータを使ってもらえるかをデータアナリストとして理解し、達成するために必要な手段をデータエンジニアとして考えることができるようになりました。
引き続きデータエンジニア兼データアナリストとして、部署のミッションである「誰もがデータを活用できる会社」になるよう頑張っていきます！
-
なお、将来的にはデータエンジニアとアナリストの役割が分かれる可能性もありますが、2025年9月時点では兼務体制を続けています。 ↩︎
Discussion