データ分析のレビューって難しくない？
データ分析の一連のプロセスに対するレビューって難しくないですか？難しいですよね。
今まではぬくぬくとレビュイーの立場を享受してきましたが、最近はレビュアー側に回ることも出てきました。アウトプットの品質を担保するためには重要な行為であることはもちろんなのですが、正直なところ何をすべきかわからず、中々上手くやれている気がしません。書籍やインターネットを調べても、その多くはコードレビューのお作法に対するものばかりです。しかし、ソフトウェアエンジニアリングの文脈におけるコードレビューと、データ分析におけるレビューは似て非なるものだなと感じます。
「世の中にないなら自分で書けばいいじゃない」
ということで、今までに受けてきたレビュー内容を踏まえつつ、僕が気をつけていること（気をつけるべきだと思っていること）をまとめます。
＊本記事における「データ分析」とは、分析の設計から始まり、レポートやスライドを活用してステークホルダーに分析結果を共有するまでの一連の手続きを指します。
大方針
レビューの目的を意識する
レビューの目的は、「アウトプットの品質を向上させること」だと考えています。多分これを意識することが一番大事だと思います。大量に赤を入れることが目的ではありませんし、人格否定と捉えられかねないコメントをすべきではないですね。レビュアーとレビュイーが協力して、アウトプットを洗練させる行為であることを忘れないようにしたいです。
段階的にレビューする
これは僕の肌感覚ですが、データ分析は手戻りが起きたときの損失が大きくなりがちだと感じます。分析設計の筋が悪いと、どれだけ高度な分析手法を用い、必死に考察しても、全てが無意味になってしまいます。手戻りが起きた場合の時間的損失が大きいと考えられる場合は、レビューの粒度を細かくすべきです。
僕は次の3段階に分けてレビューすることを基準としています。
分析設計
分析で利用するコードやクエリ
最終的なアウトプット
もちろん、「いかなる状況でも細かくレビューを行うべき」と言う主張ではありません。例えばですが、分析設計ではかっちりレビューするのではなく、壁打ちのような形で済ませることもあります。粒度はレビュイーの練度やタスクの難易度で調整できると良さそうです。
抽象度は適切か
あまりにも漠然としたコメントはレビュイーが疲弊してしまいます（例：「わかりにくい」、「もう少し詳しく」）。逆に具体的すぎるコメントは、品質向上という側面では良いですが、レビュイー目線で必ずしもいいとは限りません。レビュワーの傀儡となり、指摘された箇所を直すのはあまり面白くないですよね（卒論、修論でこの経験をした人も多いはず）。ほどほどの抽象度のレビューを行うことで、レビュイーの成長を促したり、モチベーションコントロールができそうだなと思っています。これは思っているだけなのであんまり自信はないです。誰かこの文章にレビューをください！！！
重要度、種類を明示する
時間的な制約などにより、すべてのレビューに対応できない状況もあると思います。コメントをつける際には、そのコメントの重要度（high、mid、low）や種類（question、suggestion、typo）などを明示することで、レビュイーの負担が軽くなると思います。イメージとしては、Githubのissueについているラベルです。
褒める
性質上仕方ないことですが、レビューはNegative Feedbackに偏りがちです。コメントが人格否定でないことはわかっていても、自分の不甲斐なさを感じて苦しくなってしまうことがあります。僕が単純な人間だからかもしれませんが、褒めてもらえると精神衛生上良いよな〜と思っています。スキルアップという面でも、Feedbackが不均衡データになると学習が難しいので、ExplicitなPositive Feedbackがあると嬉しそうです（適当）。
テキスト以外のコミュニケーションを利用する
レビュー内容によっては、頑張って長文で説明するより、画面を見せながら話したりホワイトボードを利用しながら説明したりする方が早く、伝わりやすいときがあります。選択肢として持っておきましょう。もちろんテキストに残しておくことは大事ですよ！
分析設計に対して
ここはちょうどいい参考文献が見つかりませんでした🙇
筋のいい分析設計の方法が載った書籍、Webサイトを募集しています。
目的は何か
これが一番大事です。目的がふわふわしている状態で行った分析の95%は上手く行きません（適当）。分析設計の時点で、「なんのために行うのか？」をはっきりさせておきましょう。
ちょっと発展的ですが、その目的を達成することに意義があるかどうかも確認しておきたいです（ﾑｽﾞｶｼｲ）。仮説検証型の分析であれば、「その仮説の真偽がわかると何が嬉しいの？」ってやつですね。
データ分析で解決可能か
そもそも必要なデータがあるか？（測定可能か？）という話です。ないなら無理です。とはいえ、直接的に測定する事が難しい指標や、すぐにはデータに表れない指標などもあります。多くの場合で、代理指標（Surrogate Metrics）が利用されると思います。レビューでは、代理指標が適切かどうかに注目する事が多いです。
例として「売上の向上が目的のとき、CTRが代理指標として適切か？」という問いを考えてみます。もしもクリックベイトのような施策だった場合では、一時的にCTRが向上しても長期的には売上が向上しないでしょう。直帰率やサイトの滞在時間の方が、CTRよりも売上と結びつきが強い指標かもしれません。
誰のための分析か
ステークホルダーをはっきりさせておきましょう！と言う話です。良い分析結果が出ても、活用されなかったらもったいないです。分析自体の質を高めるのではなく、分析結果の価値を高めるために必要だと思います。
分析手法は適切か
文字通りです。目的に対して適切な手法かどうかを吟味しましょう。個人的には次の点を気にする事が多いです。
なぜその手法を選んだか？
手法の前提となる仮定は満たされるか？
より簡易な手法で目的は達成できないか？
コード、クエリレビュー
ソフトウェアエンジニアリングの文脈におけるコードレビューとあまり変わらないので割愛します。「リーダブルコード」を読もう。
クエリをちゃんと設計する必要があるときは、こちらの記事もおすすめです。完全に踏襲するにはコストがちょっと重めですが、適宜つまみ食いして使えると良さそうです。
最終的なアウトプットに対して
ここでは簡単のために、アウトプットの形式を分析レポートとします。個人的にオススメする参考書籍を記載しておきます。
読み手につたわる文章 - テクニカルライティング
mochikoAsTechさんのテクニカルライティングに関する書籍です。書籍の中で、まるまる1章をレビューに関する内容に費やしていることが特徴的です。レビューについて記載がある本自体が希少なので、買い得だと思います。本記事の「大方針」に書いた内容のいくつかは、こちらの書籍の影響を強く受けています。
理科系の作文技術
理系の大学生にもっとも読まれている本の一つだと思います。普段の分析レポートに直接応用するには少し文章が硬すぎるかもしれませんが、一般的なお作法を復習する上で外せない一冊だと思います。
数学文章作法 基礎編・推敲編
「数学ガールシリーズ」の著者である結城浩さんが書いた、正確で読みやすい文章を書くための本です。固すぎず、柔らかすぎず、ちょうどいい文章の書き方が載っていいるので、僕が最も愛用している本の一つになります。レビュー観点では推敲編が役立つと思いますが、どちらも読んで損はないと思います。
これらを読んでください！と丸投げしたい（よくない）。
僕自身の思考の整理のためにも、普段レビューする際に気をつけているポイントをいくつかピックアップしてみます。
タイトルは適切か
昔決めたタイトルと中身がいつの間にかずれていた、みたいなことはよくある気がします。内容に則したタイトルをつけましょう。
結論は目的と対応しているか
たまによくあるやつです。結論が目的と対応していないと、読み手（聞き手）は混乱するので、必ずチェックしています。
用語や指標は定義、説明されているか
独自に作った用語であれば、当然その説明は分析レポート内に必要です。それに対し、ある程度一般的な用語については少し難しいです。想定読者（ステークホルダー）によって変わってくると考えています。
あなたが広告業界で働いているのであれば、CTRがClick Through Rateを示すことは説明不要でしょう。しかし、経営層に対してSHAP値を用いた分析結果を示す状況を考えてみてください。「SHapley Additive exPlanations の略である」という説明だけではほとんどの場合で不十分です。SHAP値が何を表すのか、概念的な説明も分析レポートに記載した方がより伝わりやすくなると思います。
あまりに丁寧な説明は、読み手が疲弊してしまいます。書き過ぎもよくないということは意識していきたいですね。
色の用途が統一されているか
これもたまによくあるやつです。色に意味を持たせること自体は有効なので、分析レポート内では統一しましょう。また、色数が多過ぎても読み手が苦しいので程々にした方がいいです（個人的には最大4色くらい）。
不要な情報が載っていないか
分析レポートは日記ではないので、取り組んだことをすべて書くべきとは限りません。読み手のことを考えて、載せる情報は取捨選択した方がいいと思います。「cherry pickingしろ！」という趣旨ではないので注意してください。appendixとかに載せておくといいと思います。
終わりに
自分用のメモとして書きましたが、思ったより長くなってしまいました。これだけ言っておいて、そもそもこの文章が読みにくかったら信頼性がない。網羅的に書けているわけではないので、「もっとこういった観点があるんじゃないか？」などのコメントをお持ちしています！
Enjoy!
いいなと思ったら応援しよう！
