正確性・可読性・再現性のある検証レポートを書くには
誰向けか、何がわかるのか
検証レポートを書くデータサイエンティスト、アナリスト
データドリブンな意志決定を行うエンジニア、PM、デザイナー
『検証・分析してくれ』『レポートを書いてくれ』と言われたけど、何を書けばいいかわからない方
検証レポートで伝えたいことを上手く伝えられずに困ってる方
メンバーの検証レポートの質を上げたいマネージャー、メンター
上記の想定読者が、正確性・可読性・再現性のある検証レポートを書くためのテンプレートと方法を紹介します。本記事の内容は、私が所属するデータサイエンスチームに導入したもので、実際に、一度書いたレポートが意志決定に何度も使われるようになったり、書き方が統一されてレビューコストが減ったり、と効果を発揮しています。
「検証レポート」の例
機械学習モデルの実験レポート
デバッグ、動作確認レポート
施策の効果検証レポート
企画・仕様・設計のためのユーザー行動ログ分析レポート
高速化、パフォーマンス・チューニングの実験レポート
負荷試験レポート
「検証」とは何か
検証とは、実験・調査などを通して不確定要素を確定させ、意思決定を進めるための作業です。例えば、
（効果検証）「リリースした新機能を継続するか or 取り下げするか」という意思決定をするには、「施策の効果はどれくらいか」という不確定要素を確定させる必要がある
（負荷試験）「オートスケールするサーバーの初期台数はいくつにすればいいか」という意思決定をするには、「想定負荷はどれくらいか」や「各台数において想定負荷に耐えられるのか」という不確定要素を確定させる必要がある
なぜレポートを残すのか
理由は2つあります。
1つ目は、検証をレビュー可能にするためです。レビューがないと、得られた知見が間違っていることに気付かず、間違った意思決定を行い、ユーザー体験や利益の損失に繋がります。
2つ目は、得られた知見を再利用可能にするためです。あるレポートを似たような他の意思決定にも使えると、検証工数を削減できます。このように検証レポートは、1回の検証で複数の意思決定に使えるので、ソフトウェアと同様、梃子のように価値を発揮します。
なぜ正確性・可読性・再現性が大事なのか
1つでも欠けると以下の問題に繋がるからです。
正確性：間違った記述や、曖昧な記述は、誤った意志決定を引き起こします。
可読性：いくら正確でも、読みづらければ、誤解を招いたり、そもそも読まれなかったり、レビューコストが上がったりします。
再現性：得られた知見に再現性がないと意志決定に使えません。また、再現手順が明記されてないと、検証が正しいかをレビューできません。
テンプレート
以下のテンプレを使うと、正確性・可読性・再現性のあるレポートを書きやすくなります。
# 仮説
# 意志決定
# 結論
# 結果・手順
## <数値 or 図 or 表> (1)
## <数値 or 図 or 表> (2)
## <数値 or 図 or 表> (3)
...各見出しについて、以下で説明します。
仮説
検証で明らかにしたい仮説（問い、不確定要素）を書きます。上述の例においては
施策の効果はどれくらいか
想定負荷はどれくらいか
各台数において想定負荷に耐えられるのか
などです。問いなので疑問文で書きます。
意志決定
検証で得られる【結論】を誰が・何を決めるのに使うかを書きます。上述の例においては
事業部のPdMが「リリースした新機能を継続するか or 取り下げするか」を決めるのに使う
SREエンジニアが「オートスケールするサーバーの初期台数はいくつにすればいいか」を決めるのに使う
です。
何を決めるのに使うかを明記する理由は以下です。
「その意思決定をするためには、その問いで適切か」をレビューできるからです。意志決定と仮説が噛み合ってないと、問いを明らかにしても適切な意志決定ができません。
得られた知見を別の場面で再利用できるか判断しやすいからです。似たような状況で得られた知見も、利用先が変わると再利用できない場合もあります。
結論
【仮説】（問い）に対する結論（答え）を書きます。読みやすくするため、端的に答え、根拠や詳細は後回しにします。閉じた（Yes/Noで答える）質問なら、まず「である or でない」で。開かれた（5W1Hを使う）質問なら、その疑問詞に当てはまる言葉を真っ先に。また、根拠となる【結果】を紐付けます。例えば、
# 仮説
施策の効果はどれくらいか
# 結論
かなりある/少しある/まったくない。なぜなら、下記の <数値 or 図 or 表 (n)> より。といったように書きます。「なぜなら」という根拠の紐付けをしないと、読み手は「この結論は、どの結果から言ってるんだ？」と探さなければならず、読みづらいです。
また、もし、施策や機械学習などがベースラインに勝てなかった場合、 ただ「勝てなかった」と書くだけでなく、「次にどうすればいいか」まで書くと生産的な検証になります。
そして、本来の結論からはズレてても、検証中に気づいたことは考察として、ここに残しておきます。
結果・手順
【結論】の根拠となる結果（数値・図・表など）を載せます。このとき、なんとなく数値・図・表を貼るのではなく、【仮説】から逆算し、問いに答えるために必要十分な数だけ貼ります。なぜなら、不足していると正確性・再現性に欠けますし、過剰だと可読性に欠けるからです。出そうとしてる図表は、結論を主張するのに本当に必要でしょうか？足りてない図表はありませんか？
グラフの縦軸と横軸には必ずタイトルを入れます。入れないと読み手はわかりません。
表には列に同じ型のものを入れます。
また、【結果】を出すための手順も明記します。どこからデータを取得し、どのコードを使って加工・可視化をしたのか、など。なぜなら、手順が明記されてないとレビューできず、間違った手順→間違った結果→間違った結論→間違った意志決定に繋がるからです。
手順をどこまで詳しく書くかは、「新規メンバーが結果を再現できるレベル」まで詳しく書きます。具体的には以下のものを載せることが多いです。
コード（GitHub の permalink などで楽をする）
コードの実行コマンド、引数の値
どの環境で・いつ実行したか
アンケート配布方法・インタビュー方法・対象者
また、上記を箇条書きにするのではなく、上から順に実行すれば再現できるよう、擬似コードのように命令文で書きます。
ちなみに、小見出し（<数値 or 図 or 表>）を設ける理由は、【結論】から根拠を探しやすくするためです。また、【手順】【結果】と分けるより、結果ごとに手順を近くに置いたほうが、手順をたどりやすいからです。
なぜこの順番で書くのか
よく見る順に書いた方が読みやすいからです。
多くの場合、得られた知見のみを知りたいので、【仮説】【意志決定】【結論】だけを読めば済みます。なので、時系列順に書いてしまうと、読み手が全文に目を通して【仮説】【意志決定】【結論】を探さなくてはならず、読みづらいです。
【結果・手順】まで読むことは稀です。レビュー時や再利用時くらいしか読みません。
つまり、読み手の心理状況と読みたい順番は以下のようになるので、この順番で書くと上から順にスムーズに読めます。
何を明らかにしたいの？ → 【仮説】
→ 明らかにして、どうするの？ → 【意志決定】
→ 答えは？ → 【結論】
→ なぜ？根拠は？ → 【結果】
→ 本当に正しい？どうやって出した？ → 【手順】
タイトルには仮説や意志決定を
タイトルには【仮説】や【意志決定】を入れると探しやすく、再利用しやすくなります。他の検証レポートと区別しやすい言葉を入れます。
NG例：「2022-04-19 効果検証①」
OK例：「2022-04-19 〇〇案件の効果はあったか、施策は継続すべきか → なかったが、改善する方針に」
実験前にレビュー
実験前にレポートを書いて、関係者にレビューしてもらいます。その時点で以下を埋めておきます。
仮説
意志決定
結果・手順
目的の問いに答えるためには、どのような数値・図・表が必要か？
図なら、縦軸・横軸は何か？
表なら、列には何が入るか？
事前レビューをする理由は、手戻りを防ぐためです。レビューせずに実験してしまうと、関係者の期待とズレが生じ、多大な工数が無駄になります。
まとめ
正確性・可読性・再現性のある検証レポートを書くためのテンプレートと方法を紹介しました。本記事を、セルフレビュー用チェックリストや、組織の検証レポートを標準化するガイドライン等の参考にしていただけたら幸いです。