データエンジニアのための売り上げ向上分析入門

# はじめに🌇

普段よりおつきあいのある[エンジニアと人生コミュニティのアドカレ](https://adventar.org/calendars/6522)です。
今年は、当コミュニティには色々なところでお世話になりました。どういうところでお世話になったかというと、例えば・・・ちょっと今パッと出てこないですけれど、言葉で言い尽くせないくらい感謝しております。

先日の投稿者はyutaさんでした。彼は日本と海外を股にかけ働くハイパースレッディングかつオーバースレッショルドなエンジニアで、Shopifyでは並み居る競合をちぎっては投げちぎっては投げ八面六臂の大活躍を繰り広げております。その活躍の様については[先日のアドカレ](https://note.com/kenzan100/n/nc04b0fc0e046)をご覧いただくとして、本日は私の記事をご笑覧いただけたら幸いです。

さて、私は普段はデータヱンジニヤとして仕事をさせていただいており、データ基盤/パイプライン構築から、DB設計、データ分析、コンサルタントなどなど幅広く承っております。今回はデータエンジニアが、特に会社の売上に貢献するための入門的な話を、技術と分析の話を交えながら進めていけたらと考えております。

## お金はどうやって捻出するの💰

世の一般のエンジニアにとっては、お金の問題は重要でありながらもあまり興味のない話題であると思います。少なくとも、関わっていて楽しいというエンジニアはそう多くないのではないでしょうか。お金にまつわる問題は人事や政治に関わる問題で、世の中の仕組みを必要以上に複雑にするので、技術のことを考えるのが楽しいエンジニアが積極的に関わりたくないのはわかります。ですが、これだけエンジニアの重要性がうるさく言われるようになっても、世間のマジョリティが見ている景色にエンジニアがかかわってくることはさほど多くないのです。

お金を捻出するためには、**コストを抑える**か、**売上を伸ばす**かの二択しかありません。
もし会社の主力製品が、エンジニアリングと密接に関係していないような企業でしたら、エンジニアリングにかけるコストを圧縮する方向で考えないといけないですし、逆に製品の質と技術が直結するようなステージにおいては、製品のどういった特性がウケているか分析して売上に貢献していく必要があります。

## データマネジメントにおける節約💸

繰り返しになりますが、世の中の事業はそもそもエンジニアリングをコアコンピタンスとしていない事業も多いです。また、経営層のマインドとして、エンジニアリングは固定費と考えている人の方が大多数です。
データエンジニアリングに力を入れている企業様におかれましては、以前に書いた[2020年度版 データ分析基盤での利用ツールの紹介](https://qiita.com/sista05/items/6ff65f4bd7dd12d17c12)をご覧いただけたらと思いますが、このパートでは、エンジニア固定費を圧縮しつつもデータマネジメントに効果を発揮することができる、データ関連最新の技術に触れていきたいと思います。

データ分析に限らずですが、最新技術の進歩はコストを抑える方向でも進んでいきます。IT技術の標準化、コモディティ化が進むにつれてコストも競争圧力に晒され、分析の敷居はますます下がっていくことでしょう。
今回紹介する**Fivetran**、**Snowflake**、**dbt**はそのような傾向に一役買う存在です。これらは日本ではまだ有名ではないですが海外ではすでに十分な知名度を得ており、今後日本でも存在感を増していくことが予想されます。

これらの大きな特徴の一つとして、全てクラウド上で完結しているフルマネージドなサービスであるということが挙げられます。また、これらサービスはそれぞれ独立したサービスであるにも関わらず、**E**(Fivetran)、**L**(Snowflake)、**T**(dbt)パイプライン間で相補的に連携を促すような機能を備えております。例えば、Fivetranでデータソースからデータを取得しつつ、dbtと連携してデータの整合性を取りながら取得したデータを変換してSnowflakeに流すという一連の流れが、それぞれのサービスの主な機能としてあらかじめ用意されているのです。


### Fivetran🔀
Fivetranは有名どころのサービスなどのデータソースを対象に、自動でデータ取得パイプラインを構築してくれるSaasサービスです。現時点で公称で150以上のサービスを対象としたコネクタをサポートしています。例えばSalesforceやMarketoなどのCRMや、Google AnalyticsなどのWebマーケティングツール、Zendeskなどのカスタマーサポートも対象としており、Fivetranを使えばそれらのデータを簡単にDBに格納することができます。
利用イメージとしては、Fivetran上で取得したいサービスの対象データを選択するだけで、あとは自動的に対象データをBigQueryやSnowflakeなどのDWHに格納し、以降はデータを定期的に同期してくれます。また、Fivetran上でサポートされていないサービスに関しても、APIをキックしてデータを取得するようなLambdaやCloud Functionsなどの実装を介してデータ取得することが可能です。

![Fivetran-Image.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/c07b05e6-19b5-a41a-b518-ef082f77b355.gif)

私がFivetranを利用した感触ですが、もちろん利用形態に依るので一括りにできないのですが、通常の分析に利用する程度でしたらいくつかのCRMやweb分析データを同期しても月20〜30万程度で運用費は収まるのではないかと踏んでおります。なお、Fivetranの利用価格は取得したデータのRow数に係ってくるのですが、取得するRowが100万行を超えた後はRowが10倍になるごとにコストは1/5になるので、もしトチってたくさん不要なデータを取り込んでしまうことがあったとしてもコストが線形に増加することはない。というとりあえずの安心材料にはなりそうです。

### Snowflake❄️

SnowflakeはBigQueryやRedShiftと並ぶDWHとして急速に進化してきました。その大きな特徴は、高いトランザクション性と信頼性を同時に備え、スケーラビリティを持ちながらもパフォーマンス調整可能な点が挙げられます。また、Snowflakeは他の有名どころのDWHと比較して、DL/DWH/DMを一まとめにした環境を提供し、非構造化データのサポートが厚かったり、パフォーマンスを調整できるところが強みと考えています。一方で、他のDWHと比べてまだ歴史も浅いので、セキュリティなど細い設定を伴う面においては他のサービスの方が強そうです。


![Snowflake.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/8e317333-b4ff-23e5-28fc-efcacdf24c27.png)

BigQueryを使っていて困ったところは、データスキーマが柔軟性に欠けているため、後からデータ構造を変更したいという場合にテーブルの作り直しが必要となることがよくありました。
余談ですが、私は複数のデータソースのデータを一つのテーブルで管理しているようなプロジェクトに遭遇したことがあります。そのカラム数は優に300を超えており、似たような名前はあるわ頻繁に型が違うデータが入ってくるわ、しかも誰も真面目に管理してなかったので独りで面倒をみるハメになりました。他の業務を抱えながらでしたが、このテーブルをデータクレンジングするのに約半年かけた上に誰にも評価されませんでした。
地味な作業ですが、データは最初から整理していないと後々データエンジニアやアナリストが泣きを見ることになるので注意したいところです。

最初からデータをしっかり管理しているような企業では問題ないでしょうが、企業や環境の拡大につれて構成を柔軟に変更していきたいという企業の方がおそらく多いでしょう。そしてそのような場合にはSnowflakeの方が向いていると感じました。また、コンピューティングリソースに依存したクエリ実行形式であるため、データの取得速度の細かい調節が可能となるので、速度要件とコストのバランスを取ることができるのは他にない強みと感じました。

### dbt💠

dbtはOSSのデータ変換サービスです。いわゆるELTのT(Transration)に相当します。FivetranやSnowflakeと比べて国内の知名度はさらに低いですが、海外ではすでに著名な存在でコミュニティ活動も活発に行われています。また、dbtのSaasサービスであるdbt Cloudでは統合開発環境やCIも提供しており、dbtのデータ変換コードをgit管理しつつUI上からさまざまなdbt操作を実行することが可能になります。似たようなサービスとして少し前にGCPに吸収されたDataformもございます。

まず、もちろんデータ転送に必要なテストや自動実行などの基本機能は充実しています。
また、SQL構文を記述する際に、DB間で微妙に異なる構文の違いを意識する必要がなくなります。どういうことかというと、RedShiftやBigQueryではそれぞれ使用するSQLに若干の方言とも呼べる違いがありますが、dbt上でSQLを記載することでその方言の違いをある程度吸収してくれるので、データ転送先のDBを変更した場合でもSQL構文を書き換える必要がなくなるのです。
そして、dbt Cloudではコード自体をしっかり管理しておけば、データマネジメントに付き物のデータの説明のドキュメント化やデータ間の連携DAG図も自動で生成することが可能です。言うなればData Structures as a Codeと呼べるようなサービスと言えるでしょう。

経営層の方々などがお金の流れを把握する際にデータフローの図は必須です。データ構造が頻繁に変わっても、それがそのまま管理の過程でドキュメント、DAG図になるというのは、資料更新の大きなコスト削減に繋がります。社内にせっかく豊富なデータを蓄えているのに、データガバナンスがガバガバということになってしまってはその恩恵を活かし切ることができません。ガバガバは私ではなくコミュニティの人が仰っていました。

**DAG**
![dag.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/62fccf7c-257a-5633-c8c7-041c5d672c07.png)

**Document**
![Document.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/a93e5669-8e1d-cc1d-19e4-4da90db9805f.png)

**将来的にE-R図もサポートされる？**
![data_structure.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/abf52f1a-3247-4e38-c105-ffb2d26c580e.png)

dbt Cloudを利用する場合にはTeamプランでは一人につき$50/monthかかります。ちなみに、こないだdbt Cloudの方にチャットでお世話になる機会があったのですが、無料枠であるにも関わらず私のオペミスに対して迅速に対応していただいたことには感謝しきりでした。感謝を伝えるのにyou're an angelと言うところをyou're my angelと言ってしまいました😇


## データ分析で売上を伸ばすには📈

ここまではコスト削減の話でしたが、ここからは売上につなげるための分析をいくつか挙げていきます。
データを売上に直結するには、データ分析が欠かせません。また、体感ですがデータエンジニアにも分析経験が求められるようなケースが多くなってきたと感じております。データエンジニアが分析視点を持ち得ることは、技術のコモディティ化に対抗するために他と差別化する方法として将来的なスタンダードになる可能性があります。そうでなくても複合技術を持っていることは技術の相乗効果も見込めるため、決して無駄にはならないと考えております。

データを扱うための方法論は、さまざまな観点でデータを分析する必要性から非常に多岐に亘ります。それだけで本が書けるくらいの分量があるのですが、ここではいくつか典型的な分析を紹介したいと思います。

### チャーン分析👶
お客様の解約率について分析する手法で、最近のSaasサービスなどでよく用いられます。そのため、特に先に挙げたFivetranなどを用いたサービスと相性が良い分析です。カスタマーサクセスにおけるチャーンレート分析は複数のCRMツールとの連携で効力を発揮し、KPI指標の作成からメール開封率の向上、要求の掬い上げなどのアクションに繋げていきます。

![スクリーンショット 2021-11-30 21.48.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/bdf6d010-4f4c-0f74-0f3a-05354b405ee7.png)
本当は別のキャラクターで作っていたが怖くなってやめた

### クロスセル・アップセル分析👜
よくECサイトで見かける、おすすめ商品のレコメンドのための分析です。顧客により高いものを購入させたり(アップセル:🍟➡️🍔)、抱き合わせで商品購入を促したりします(クロスセル:🍔🍟➡️🍔🍟🥤🍦)。分析には協調フィルタリングという手法が主に用いられており、購入した商品との相関関係が強い商品をスコアリングする分析ですが、分析に用いるためのデータには各顧客の属性や時期的なもの、などなど複合的になることも多く、機械学習とも親和性の強い分析手法になります。
![storategy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/03324e2f-f016-66d8-6b78-f28ceee31ab4.png)

### 発注最適化📊　

製品の発注、商品の生産、出荷・物流、販売などの計画を最適化するための分析です。在庫最適化、サプライチェーンマネジメント(SCM)とも呼ばれ古くからある分析ですが、今流行りのデータドリブンなDXではよく用いられる分析で、この分析を起点として様々な改善活動や別の分析につなげていきます。
最近ではSCM×AIとも呼ばれることもあり、注目すべき指標を求めて需要予測につなげたり、顧客をセグメンテーション化してそれぞれの顧客に適した戦略を考えたりします。対象範囲が広範にわたり取り扱うデータ量も大きくなりがちなので、今回紹介したfivetranを利用するよりは独自でパイプラインを構築した方が割安になるかもしれません。

![需要予測.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/244490/c9fcacf0-3d4f-8a81-be40-733269ee8483.jpeg)


# さいごに💮

成長のためのロールモデルを求めるような考え方が通用しにくい時代になってきました。誰もが次なる指針を求めている時代なのに、ググって回答を知ろうとしても前例がないから答えは落ちていないのです。何らかの前提を基にしか考えることができない人間の性(サガ)として、考えても答えが出ない場合は前提を覆す必要があります。そしてデータ分析とは前提を疑うためのツールなのです。

世界はますます自動化が進み、その分空いたリソースは新しいことを考えるために割かれることとなるでしょう。そうした際に、エンジニアが提供できる価値とはコーディングではなくその思想にあると考えております。本記事では技術のコモディティ化が進む世界に向けて、価値を研ぎ澄ませていくための指針の一つを提示したつもりです。