はじめに
課題｜分析レポート内容がうまくPM / 他メンバー / 顧客に伝わらない
データサイエンティストは日々様々な実験・分析を行いレポートを書いています
コードを書いている時間より前処理の時間とレポーティングの時間が長いくらいです
レポートはPM / 他メンバー / 顧客など様々な人が読みますが、うまく内容が伝わらないと色々な問題が生じます
問題例①｜分析内容の質問の応酬で時間がかかる
PMや顧客はレポートを読んで色々な疑問を持ちます
- そもそも何を目的に何を比較しているのか？
- 実験条件は本当に妥当なのか？
- KPIの具体的な計算方法は？
疑問に答えて、また疑問が生じて... という応酬で時間がかかってしまうことがあります
(特にチャット上で非同期にコミュニケーションを取る現代では...)
問題例②｜数値や図版の追加出力依頼の応酬で時間がかかる
PMからの意見としてよくあるのが以下のようなものです。
- 体裁の修正 : 「この図だと顧客提示できないから、ここの体裁を直して出力し直してよ」
- 詳細数値の質問 : 「全体の結果は良いっぽいけど、具体的にこのサンプルでの数字はどうなの？」
数値や図版の出力が粗いと、これもまた二度手間になってしまいます
問題例③｜分析の間違いにPM / 他メンバーが気づけない
例えば以下のような「書いてあればすぐ気づけるミス」も記述できていないと気づけず、間違った分析をしてしまう恐れがあります
- 分析に利用するデータが間違っている
- 実験コマンドの引数が間違っている
- ...
目的意識｜1回で納得してもらえる / フィードバックがもらえるレポートを書く
- 「上記のような問題を最小化し、PM / 他メンバー / 顧客などに納得してもらえて、間違いがあれば助言や意見がもらえるレポートを書く」
- そのために筆者が心がけていて、概ね汎用的に使えるであろう記述の流れやTipsを記述します
- (補足) あくまで「最初に書いてさえいればプロセスを省略できる内容の効率化」であり、コミュニケーションして分析をBrushUpすること自体は必要です！(質問プロセスの否定ではありません)
(補足)この記事について
記事の流れ
- まず全体のレポート構成の話をします
- その後で「背景 → 目的 → 実験/分析内容 → 結果 → 結論/課題点」各所での記述Tipsを書きます
- 最後に上記記述を楽にするためのテクニカルな内容を書きます
記述の前提
- 日々書いていく社内での分析ログくらいが対象イメージです
- (顧客向けに最終発表で出す資料とかではない)
- GitHubのIssueなどMarkdownでのレポート記述を多少意識しています(筆者の労働環境のため)
- ただし、ほぼ汎用的に利用できる内容かと思います
0. 全体構成
背景 → 目的 → 実験/分析内容 → 結果 → 結論/課題点 の連鎖でストーリーを追いやすく
- 「背景 → 目的 → 実験/分析内容 → 結果 → 結論/課題点」としっかり記述しましょう
- (おおよそテクニカルライティングの一般的な流れですが)
- 大抵の場合は最初の分析では綺麗な結論には行きつかず、結論を出すには何らかの課題が残ります
- その課題が次の分析の「背景」につながるという連鎖ができているとストーリーが追いやすく伝わりやすいです
1. 背景
何が課題なのか、現象だけでなく価値がわかるように書く
- 何が課題なのかがスタート地点です
- ありがちな失敗は「現象だけが書いてある」ことです
- 現象だけでなく、それによりビジネス上のどのような損失があるのかを書けると良いです
- ❌ : 〜という分類のサンプルで予測精度が悪化している
- ⭕️ : 〜という分類のサンプルで予測精度が悪化しており、顧客の確認作業負荷が増加している
背景課題のより詳細なLinkがあれば貼り、簡易な説明も書く
- 背景課題は別のどこかで生じたはず → その箇所のLinkなどがあれば貼って流れを追えるようにしましょう
- ありがちな失敗はLinkだけ貼って「これ見てね」 → 読む人が流れを追う負荷が増えるので、簡易な説明も書くと良いです
- ❌ : 背景課題は (Link) を参照
- ⭕️ : 〜という課題がある。詳細は(Link)参照
新規参入者が理解できる言葉で書く
- 背景時点でドメイン知識が多分に必要な記述がされると以降の理解が追いつかなくなりがちです
- 新規参入者が理解できるように、その分析で特に必要となる言葉の意味などは補足できているとBetterです
2.目的
最終的に何の意思決定がしたく、何を明らかにしたいのか
- ありがちな失敗は「手段が記述されていること」
- あくまで目的では「何の意思決定がしたく、そのために何を明らかにしたいのか」がわかると嬉しいです
- ❌ : AとBの条件でCVを比較する(手段)
- ⭕️ : 〜というサンプル群でのCV改善のためにどのような手法が有効かを明らかにし、改修可能にする
明らかになった場合のビジネス上の利益 / 実現される顧客価値は何か
- ありがちな失敗は「技術的な目的」だけを書いていて、どのような顧客価値につながるかを書いていないことです
- 顧客価値への寄与を記述すると、プロジェクト全体の中での重要性について目線を合わせることができます
- ❌ : 〜による計算時間の削減幅を明らかにする
- ⭕️ : 〜による計算時間の削減幅を明らかにし、検証効率の改善(=仕事効率の向上...顧客価値)への有効性を判断する
3.実験 / 分析内容
KPI は何か(計算方法)、目標ラインは何かを明らかにする
- KPI が何か+目標ラインが明らかになっていると意思決定に繋げやすく、記述は必須です
- ありがちな失敗は「新しく定義したKPIの計算方法が記述だけではよくわからない」などです
- ❌ : 在庫回転率 をKPIとする
- ⭕️ :
在庫回転率 = (期間内の売上金額合計) / (期間内の平均在庫金額)をKPIとする- (コード上の計算箇所へのLinkなども貼ってあるとBetter)
コントロール(比較)する変数 / 実験条件は何かを明らかにする
- 基本は何らかの対照実験を行うので、これも記述が必須です
- 記述されているとストーリーがわかりやすくなります
コントロール変数以外で 自分で決めた実験条件 / 従来の分析と変えた条件
- 上記の比較対象の条件以外で、従来の分析から変えている条件などが分析結果に影響することがあります
- 例 : 集計対象で〇〇はノイズとなるので今回分析からは除外している
- 記述されていないと、分析結果の過去分析との差異に説明がつかず、追加分析が発生することがあります
参照したデータ / 実験コマンド / 分析コード等を明記する
- 重要な参照データやコマンド等が記述されていることで以下のようなメリットがあります
- 実験の再現性が保たれる
- データやコマンドの間違いに他メンバーが気付き指摘できる
- 他メンバーがデータにアクセスして追調査できる
- 特に以下の内容は記述推奨です
- 参照したデータパス(重要なものに絞って良い)
- 実験時の
git hashorPull Request等 - 実験コマンド・分析コード・クエリ等
4. 結果
目的のKPIの比較結果がわかる図表を貼り、根拠を示してコメントを書く
- ありがちな失敗は「図表と結果のコメントがあるが、図表のどこからそのコメントの判断がされているか不明」です
- ❌ : (図表)からわかるように、Aと言う条件で有効な結果が出ている
- ⭕️ : (図表)の**〜の箇所の◯◯率からわかるように、Aと言う条件で精度が改善**している
- (そもそもコメントなしで読み取れるような図表を示せているのがベスト)
詳細数値の出力｜Spreadsheet等で数字をそのまま出す
- 「全体は良さげだけれど、〜のようなサンプルではどんな結果なの？」のような詳細数値への質問は非常に頻繁に起こります
- 数万件程度までに絞れるのであればSpreadsheetなどに出力してLinkを貼り付けておくと、PMや顧客が勝手に見て自分で解決してくれて非常に手間が減ります
- これにより、全体では見つけられなかった問題や集計上の課題を他者が発見してくれると言うメリットもあります
図表は新規参入者が見ても理解でき、そのまま顧客提示可能な体裁で出す
- 本質的ではないのですが、図表が顧客提示するのには粗い体裁だと、これも修正依頼が発生し二度手間です
- 例えばよくある例としては...
- 軸ラベルや凡例に「コード内での変数名」が使われていて「顧客が利用している業務名」でない
- 解像度が粗い
- 画像サイズがスライドに貼るのに適していない(結構横長な方がスライドに文字を書く余白ができて嬉しいことがある)
- 詳細は クソどうでもいい図版の体裁指摘で死なないために（matplotlib / seaborn）に書いています
5. 結論/課題点
「目的」の答えは出たか
- 最終的に「目的」の答えが出たのかは(当然ですが)記述必須です
目的に沿わない結果である場合は課題点を明らかにする
- よくあるのは、「目的に沿わない結果になってしまって記述の歯切れが悪くなり、Next Actionがわからない」ことです
- 現状の分析では課題がある場合はそれを明確にしてNext Actionに繋げられるようにしましょう
- ❌ : 今回分析では〜の判断はつかなかった
- ⭕️ : 今回分析では**「Aによる精度改善」と「パラメータの差異による精度変化」の区別がつかず**〜の判断がつかなかったと思われる。〇〇に条件を揃えて比較することがNext Actionとなる
(補足)上記記述を楽にするためのTips
レポートのテンプレート化
- 例えばGitHubの場合Issue Templateなどを活用し、上記の流れをMarkdownテンプレートとして保存しておくことで記述がかなり簡単になります
終わりに｜そんな丁寧に書くのも大変だよね
- 色々書きましたが「そんなに丁寧に書くのは大変だよ」と言うご意見もあると思います
- 記述が粗いと結果的にコミュニケーションコストが増えてしまうので、チーム全体の生産性で考えると丁寧に書いたほうが良い、というのが自分の経験則です
- また、上記の流れの記述は最初のうちは大変かもしれませんが、慣れれば恐らく大変ではなくなります
- 特にプロジェクトが忙しく分析を急いでいるときには記述を省略したくなりますが、むしろそういうときこそ一旦落ち着いてわかりやすい記述ができると、チームでのコミュニケーションコストが小さくなり結果的にチームで良い成果が出せるようになると思います