
こんにちは。お久しぶりの田中です。
僕はアナグラムにおけるバックオフィスの領域を長らく担当しており、社内向けに月次のレポートファイルを作成したり、各種媒体から取得したレポートデータを Google データポータルや Google スプレッドシートに出力したりという業務の遂行や管理を行っています。
レポート作成業務全体を俯瞰している中で、レポート業務に求められる役割だったり、求められるレポートの形式というのが変わってきているなと思うことがあり、現在見えている風景とそこから見える少し先の未来について、この記事にアウトプットすることで頭の中を整理しておきたいと思った次第です。
この記事を読んだことで今すぐ取れるアクションが生まれるわけではない、そんなチラシの裏書きのようなものですが、なにか気づきが生まれてくれると嬉しいなと思い、筆……ではなくキーボードを叩いています。
※レポート作成業務というのはどの業界にも存在するものだと思いますので、この記事におけるレポート業務とは、運用型広告の領域で作成するパフォーマンスレポートやWeb解析の領域で作成する分析レポートのことを指しています


目次
レポートは見る人によって必要な情報が変わってくる

読んで字の如しではありますが、レポートは見る人の立ち位置(役割や役職)によって変わってきます。例えば、スタートアップのマーケティング担当者と、複数の事業を持つ事業会社の社長では必要とされるレポートは異なるはずです。
スタートアップのマーケティング担当者であれば、次の打ち手を考えるために必要な情報を網羅したいでしょうし、事業会社の社長であれば、複数の事業について事細かに把握する時間が取れないので、重要なポイントがまとまったサマリーだけ欲しいというケースもあるでしょう。
したがって、レポートによって枝葉を見る必要があるのか、幹を見る必要があるのかは、その人の立ち位置によって変わって来るため、報告をする相手によって適切なものを使い分けるのが良いというのが僕の考えです。
運用型広告の文脈に限って述べれば、(もちろん双方の合意あっての上ですが……)管理画面へのアクセス権を付与しておき、数値については管理画面上で確認をお願いするでも究極は良いわけです。
レポートの多様化

僕がレポート業務に携わる中で見えてきている風景の1つにレポートの多様化があります。
ITが発達したことによって、レポートの形式も多様化してきました。
ひと昔前であれば、レポートといえばExcelやLotus 1-2-3(知っている人ほとんど居ないかもしれません……)でしたが、今やGoogle スプレッドシート、Google データポータルやTableauといったBIツール、Google BigQueryでデータウェアハウスに蓄積されたデータをSQLで直接集計するなど、その形式はさまざま。
また、それぞれの形式でもメリットとデメリットが存在するので、場合によって最善なものを採用したいですね。
Excelが不要になるわけではない

近年になって、BIツールの導入を進めた結果として、Excelでレポートを集計する必要がなくなった、Excelは不要だ!とか、データウェアハウスにデータをすべてまとめてSQL集計できるBigQueryが至極!などの論調が見かけられます。
それぞれの論調がその人によっては正しいのは間違いありません、なぜならExcelの必要性がないレポーティング環境を構築して手に入れたから。
では、万人がExcelをやめてBIツールによるビジュアライズや、BigQueryでの集計に移行するのが良いか?と考えると決してそんな事はありません。
先にも述べましたが、レポートは見る人によって必要とするものが変わってきます。未来永劫Excelを使い続けることが正解であるとは言えませんし、Excelに固執し続ける必要はありませんが、Excelを廃止するありきで物事を考えてしまうと、レポーティングという本来の目的を見失いかねません。
Google スプレッドシートで共有する際、相手方がGoogle アカウントを持っているとは限らない
オンラインでデータを共有するためにGoogle スプレッドシートを使い、相手方に閲覧権限をもたせて共有することも少なくはないと思います。週次で報告する必要がある場合など、都度レポートをメールで送るなどする必要はなくなりますし、いつでも新しいデータにアクセスすることができるので大変便利です。
普段からGoogleのプロダクトに慣れてしまっていると見落としがちになってしまうのですが、Google スプレッドシートやドキュメント、スライドなどは、特定の人のみに向けてセキュアに共有する場合、招待される側もGoogle アカウントを所持している必要があります。
オフィススイートとしてGoogle Workspace(旧:G Suite)を使っていると、会社のEメールアドレスがデフォルトでGoogle アカウントとして扱われますが、そうではない場合はGoogle アカウントが必要になります。
その他にも、企業のITセキュリティのポリシーとしてGoogle スプレッドシートによる共有が認められていないケースもあるので、事前に確認しておくと良いでしょう。
BIツールによるビジュアライズも準備と運用が必要

Google データポータルやTableauといったBIツールにてダッシュボードを構築し、レポートのビジュアライズ化する方法も近年はトレンドになってきています。
ダッシュボードに様々なデータソースを接続して1つにまとめることで、グラフを作成したり地図などのコンポーネントにプロットしていくなど簡単に行なえるので、パッとひと目で状況が把握できるレポートが作成できます。
ノンプログラミングで高度なダッシュボードが構築できる反面、複数のデータをまとめるためのトリミング、ディメンションや指標を考慮した複数データのマージなど初期段階で行う準備などが立ちはだかります。
また、各データはAPIを使って接続されるケースが多いため、APIのバージョンアップによって出力されるデータやフォーマットが変更となったり、項目が増減したりといった事象への対処が必要になりますし、ダッシュボード上に新たな項目を変更するなどといった対応は継続していきますので、作って終わりというものではありません。
SQLによるレポート集計はスキルが必要(属人化)

ここ1~2年の間では、Amazon Web Service(AWS)、Google Cloud Platform、Microsoft Azure などを利用したデータウェアハウスを構築し、外部サービスで取得しているデータをそこにまとめて管理するという方法も増えてきました。
データウェアハウスはデータを集めた倉庫になるので、そのデータを集計する手段が別途必要になるのですが、Google Clud Platformのサービスの1つとして提供されている Google BigQuery にデータを格納してSQLで集計する方法が注目され始めています。
余談ですが、Google アナリティクス4(GA4)にて Google BigQuery と直接連携できるようになっているためWeb解析に携わっている方中心に Google BigQuery の利用が増えてきているように見えます。
SQLは昔からデータベースの集計といった分野で世界的に利用されている言語ですので、広く普及し習得もしやすいです。しかしながら、習得までには学べる環境とそれなりの時間が必要になってくるため、今日明日で完璧に身につくといったような種のスキルではありません。
故に、担当者の異動や離職によってチーム内にSQLが分かるメンバーが不在となってしまったときに、SQLを使った分析の継続が困難になることも想定できます。
SQLを利用したレポート集計を行う場合は、集計を特定メンバーに一任するのではなく、複数のメンバーがSQLのスキルを身につける、SQLの部分はシステム部門のエンジニアのヘルプを借りて、データウェアハウスのデータをソースとしBIツールで集計するなど、運用体制や方針もある程度決めておく必要がありますね。
データを整えて汎用性を高めることの重要性が高まる
日々のレポート作成業務で僕が見えてきているもう1つの風景は、レポートデータの汎用性についてです。これに関してはいくつかの視点で思うところがあります。
各システムを接続する際は、APIでどこまで取得できるか知っておく

運用型広告の領域では、各広告媒体のレポートをAPIを使って取得して、データウェアハウスなりに格納し、それを束ねてレポートを作ることはしばしばあります。また、様々なベンダーからもデータの取得、格納、集計、ビジュアライズできるようなレポートツールも提供されています。
このようなレポートツールを利用する場合も含め、APIでデータを取得している以上は、APIでどこまでできるか?は知っておきましょう。
値やフォーマットを知っておく
2018年の話ではありますが、Yahoo!広告で提供されていたYahoo!ディスプレイアドネットワーク(YDN)で、管理画面上で表示されるコスト関連の指標における小数点以下の扱いが変更となったことがありました。
参考:【YDN】コスト関連の指標における小数点以下の金額取り扱い変更のお知らせ - Yahoo!広告
APIで取得できるコスト関連の指標は当時より小数点以下の数字も含まれていたため、APIから取得できる数値自体に変更があったわけではありません。
しかしながら、管理画面上で表示されるコスト関連指標で小数点以下の端数処理方法が変更になったため、APIで取得されるコスト関連の数値の丸め処理を意図的に行わないと、集計したレポートと管理画面上で数値に差異が発生するということが発生しました。
結果として、集計時にデータの前処理を行ったことで、管理画面と数値が一致させることができたので特段の問題は発生していませんが、個人的には印象深い出来事でした。
余談ですが、Facebook広告のAPIで取得できるリーチ数は、日別に出力したものを足し上げた値と月別で出力した値は一致しません。詳説は省きますが、これは同一人物に対して複数回リーチできた場合に、日単位で重複を加味するのか月単位で重複を加味するのかといった処理の違いによるものです。(日別にリーチ✕フリークエンシーを求めて1ヶ月分足し上げたものに、月別で出力されたフリークエンシーで割り算すると、月単位のリーチ数が計算できます)
取得できる項目を知っておく
APIにて取得できる項目の種類がレポーティングの障壁となるケースもあります。
例えば、Google 広告、Yahoo!広告、Facebook広告は、広告レベルでデバイス別のレポート数値を取得することが可能ですが、LINE広告では広告レベルでデバイス別のレポートが出力できません。
なので、これらを1つまとめ集計しようと思ったとき、LINE広告の広告別レポートのデバイスはモバイルであるという情報は、どこかのタイミングで与えてあげないとうまく集計できないといった事態に陥る可能性があります。
または、SQLを利用する場合であればテーブルの結合が思い通りにいかない、なんていうケースにも遭遇しかねません。
データをキレイにトリミングすることは汎用性を高める
ここまでお読みいただいて何となくひらめいた方もいらっしゃるかもしれません。
レポートは相手によって適切な形式で提供することの多様性を担保するためには、どのレポート形式で提供しても良いように、そのもととなるレポートデータは汎用性をもたせる必要があるということです。
つまり、どのレポート形式にも落とし込めるようなデータの前処理というのがとても重要。
Excelで作るにせよCSVでダウンロードして加工しますし、APIで取得したレポートデータをBIツールで扱ったりSQLで処理したりするにも、APIの仕様をある程度知っておかないと正しい数値でのレポーティングは困難だったりします。
レポートの形式に正解はない
ここまでの話はバックオフィスを担う役割である僕だけが見えている景色ですし、これはアナグラムのような複数の顧客と向き合うような広告代理店だからこその話であって、事業会社の視点で俯瞰してみたときには気にする必要がない話ではあります。
個人的にレポートの形式に正解はないと思っていて、提供された顧客の役に立つ形式で提供できるのが望ましい反面、それは顧客に向き合うメンバーのレポート作成能力(属人性)に左右する部分も大きいため、いかにデータに汎用性を持たせて提供し、各メンバーが加工しやすくできるか(多様化に対応できる環境の提供)を突き詰めることが個人的なミッションであると心に誓っていたりします。