データアナリストの仕事に応用できたエンジニアリングの知識・スキルと苦労話

この記事は Retty Part1 Advent Calendar 2021 の3日目の記事です。

adventar.org

はじめに

データアナリストの松田です。2020年10月にエンジニアからデータアナリストに転向し、1年が経過しました。アナリストとして仕事をする中で、エンジニアとして獲得していたスキルが役立っていたことが数多くあったため、棚卸ししておきます。

アナリストの主な仕事

Rettyデータアナリストの仕事内容については、以下の記事を参照いただけるとざっくりと把握して頂けるかと思います。

大きく分けると、意思決定支援というプロダクト開発に関わる分析が主な業務となる領域、分析の民主化という組織全体の分析レベルの底上げを行なっていく領域があります。

engineer.retty.me

必要なスキル

Rettyのデータアナリストはチーム内外と広く関わることの多い職種です。関わる幅は広いですがコアとなるスキルは大きく分けると4つほどになります。

1. データ分析

データアナリストとしての基本的なスキルです。 定量/定性データを基にした分析の実行や何を分析するかの設計、レポーティングといった実際に手を動かす領域です。

2. DWH開発

Rettyではデータ基盤の整備についてもデータアナリストが一定の役割を担っています。定量分析をする上で必要なデータについて、自分たちが使いやすいようにDWH開発を自ら行いBigQueryのビューやテーブルを作っていく領域です。

3. コミュニケーション

分析結果を正確に理解してもらうためにはデータアナリストから適切な説明をすることが重要です。ステークホルダーごとに前提となる知識が異なるため、相手に合わせた説明力が必要になります。

4. ファシリテーション

定例のような型がある程度決まっているミーティングのファシリテーションや、課題発見といったコミュニケーションをとりながら進めていく仕事のファシリテーション、どちらもデータアナリストが他チームと連携して仕事を進める上で重要になります。


エンジニアリングの知識・スキルが応用できたこと

主にデータ分析におけるハードスキル部分で役に立ったことが多かったかなと思います。

エンジニアの習慣

エンジニアに限らず行っていることだとは思いますが、一次情報を見る習慣がデータアナリストになってもかなり役に立ったと感じています。

RettyではBigQueryでデータを蓄積していますが公式ドキュメントが豊富なので基本的にドキュメントを見れば困ることはないですし、内製しているテーブルやビューについても実際に動いているクエリを見ることでキャッチアップが捗りました。

余談ですが、欲を言えばBigQueryのドキュメントは仕様や挙動だけではなく、どのような場面で構文や設定を使えば良いかまで書いておいて欲しいものです。

エンジニアの仕事の中でライブラリなどの利用方法で困ったらまずは公式ドキュメントを読む、それでもわからなければライブラリ自体のコードを読む、というのが習慣化していて良かったと思いました。

DWH開発

これは今のDWH開発フローがプルリクエストやCircleCIを利用していてかなりエンジニア寄りになっていることもありますが、Gitの概念やGitHubの使い方をある程度理解していることがかなり生きていました。

データアナリストの本職は開発ではないのですが、DWH開発においてはdbtやDataformなどのいずれのツールでもGitを使うことになるので、時間をかけて学習できておいて良かったと思っています。

Gitは最低限使うだけなら教えてもらえばなんとかはなるものの、概念の理解やある程度しっかり使える状態になるまでは年単位で時間がかかります(私はかかりました)。

この部分の学習負荷がゼロで済んだことで、ハードスキル以外の分析スキルを身につけることに多くの時間を割くことができました。


苦労したこと

大変だったことも多数(むしろ苦労したことの方が多い)あるので振り返っておきます。

データの場所・存在確認

ある程度しかたない部分もありますが、どのデータがBigQuery上のどこにあるかを理解するのが最初はかなり時間がかかりました。

データカタログがあるもののDescriptionが全部埋まっているわけではない状態なので「これってどこにあるんでしたっけ」をひたすら確認していました。今にして思えば設計思想を先に理解しておけば良かったなぁという思いがあります。

また、データの存在確認も大変でした。そもそも存在していないものはいくら探しても見つかるわけないのですが、データ自体が存在してないのか検索方法が間違っている(カラム名が違うなど)のか自分で判断するのは難しく、これも知っている人に聞くしかなかったです。

「このデータはどこにありますか?」「このデータは存在していますか?」は、組織的にデータ分析できる人を増やしていく上でもかなりの強敵だと思っています。倒し方があれば知りたいです。。

SpreadSheet

意外と大変だったのがスプレッドシートの使い方です。エンジニアやっているとスプレッドシートはあんまり触る機会がないんですよね。vlookupの使い方を知らない、グラフタイトルの変え方も知らない、と初心者以前のレベルでした。

無数のハマりポイント(ifなどの構文がプログラミング言語と異なる、シングルクォーテーションは文字列ではない、concatはArrayformulaで使えるがconcatenateはダメなど)を乗り越えつつ数をこなすことでなんとか使い慣れてきた感があります。

グラフについては「Google流 資料作成術」をオススメされたので読みました。各グラフの使い方についてカラーで細かい解説があり、いつも助けられています。WebアプリケーションやWebサイトと同じく情報設計をしっかり行っておくことが重要だという点が一番の学びでした。

SQL

生のSQLではなくORMを使うことが多かったため、実はそんなに使いこなせる状態ではなかったです。

SQL初学者のための問題集があるので、それに取り組んである程度window関数にも慣れることができましたが、狙った通りのデータ構造にできなかったことが一番苦労した点でした。

Web開発だと見た目を整えるのはSQLではなくJavaScriptなどにループ処理させるので、1:Nの配列構造でデータを取り出してきます。

一方、スプレッドシートに出すデータはBigQueryで出した結果をそのまま持ってくることが多いのでSQLで狙ったデータ構造に整形する必要があります。

データ構造もJavaScriptで整形するコードも思い浮かんでいるのにSQLだけは分からない、というのが1ヶ月ぐらい続いてかなり苦しみながらSQLを書いていました。

BigQueryはJavaScriptも実行できてしまうので「JavaScriptなら早く書けるのになぁ」と思いつつも、SQLが書けるように修行していました。

他職種からでもデータアナリストになれる環境

上述したエンジニアとしての知識やスキルがデータアナリストの仕事に応用できた要素はいくつかあるものの、根本的には他職種からでも異動しやすい環境が整っていることも大きく影響していたと思います。

BigQueryの問題集はPMやプランナーが自ら分析ができる状態を目指すために準備されていたものを転用できていましたし、データアナリストがファシリテーションをする習慣も私の異動前から存在していました。

私もこの環境をさらに改善し、今後の新卒メンバーや分析チームに入る方がデータアナリストとして活躍しやすいチームにしていきたいと考えています。

最後に

Rettyではデータ分析を活用したプロダクト開発を今後も推進していきます。Rettyデータアナリストについて知りたい方は他のブログ記事や、こちらの求人をご参照ください。

hrmos.co

カジュアルに話してみたいという方は、分析チームマネージャー平野のMeetyもありますので、こちらからどうぞ。

meety.net

meety.net