検証の概要とデータを分けることで、新規スタッフの引き継ぎがスムーズになった話

はじめに

こんにちは、計測プロデュース部の歌代です。

私たちはZOZOFITやZOZOMATといった計測系プロダクトの開発PM、データ収集、精度検証などサービス構築から、UI/UXの分析・評価など幅広く業務を行っております。

今回は私たちのチームが抱えていた課題と、対応策として行った工夫についてご紹介します。

直面した課題

私たちのチームが直面した課題は「QAスタッフの入れ替えが発生する度に、引き継ぎがうまくできず、検証のクオリティが下がる」というものでした。私たちの業務は、計測に関する独自のノウハウや技術が多くあります。また過去に実施した検証の内容を定期的に振り返り、過去の検証手法や検証結果を参考にして、現在の検証を決定する場面が多く発生しています。

スプレッドシートでまとめたメモには検証結果や分析データが精緻に記載されており、検証当時の環境や条件・結果を確認できるようになっていました。

その後、新しいスタッフを迎え、プロジェクトを振り返るタイミングで今回の課題が発覚しました。スプレッドシートを開き、当時の検証の内容を説明しようとすると難しい点に気がつきます。一つ一つの検証データは詳細に記載されていますが、検証の目的や概要などの記載はなく、日付とデータを見て、当時の状況を思い出しながら説明することになりました。結果として、説明をする側、説明を受ける側双方にとって、多くの時間を費やすことになりました。

目的の重要性

後任のスタッフに過去の検証実績をスムーズに引き継ぎできないのはなぜでしょうか。

当時の細かなデータは確かにスプレッドシートに記載されており、結果についてもしっかりまとめられており、検証結果を示すものとしては十分な資料になっていました。

実際、自分で資料を見直してみたところ、あることに気がつきました。それはそれぞれの検証の目的が具体的に記載されていないことでした。

それぞれの検証で「何のために」「何を調べたかったのか」などの情報が記載されていませんでした。その結果、細かなデータの記載はあるものの、そもそもこの検証を行った背景を理解しないまま、検証結果だけを共有されていました。後任のスタッフはゴールが見えないまま、データだけを読み解いていきながら、検証目的をぼんやりと理解しているのではないかと仮説を立てました。

概要とデータを分ける

そこで私たちは、検証の概要はドキュメントWebサービス（Confluence）、データはスプレッドシートで運用することにしました。

改善前までは検証に関する概要などのメモをフリーフォーマットでスプレッドシート上にまとめていました。しかしその状態では、ドキュメントごとに記載されている項目にばらつきがあり、必要な情報を探すのにも時間がかかり、ストレスがかかるものでした。

検証の「概要」と「データ」をそれぞれ得意とするドキュメントにまとめる運用を始めるにあたって、私たちは以下のポイントを重視しました。

概要はできるだけシンプルなフォーマットにすること
概要はできるだけ情報量を少なくし、初めて読む人がうんざりしない量に留めること
データは今まで通り、細かなデータを記載すること

基本的に過去の検証結果を振り返る際、まず概要の情報だけで「当時の検証が何を目的としており、結果どうだったのかサマリーで理解できること」を「概要」の役割としました。そして「概要」を読んで、もう少し詳しく知りたいと思う人が、さらに精緻な情報として「データ」を閲覧します。これにより、検証の目的を念頭においた状態で、より詳しく検証の理解を深めていくという運用を想定しました。

概要をまとめた効果

検証概要を情報共有ドキュメントWebサービスにまとめるにあたって、以下の項目に絞り込んで記載することにしました。

目的（検証の背景やゴール）
概要（具体的な環境・端末の情報）
結果（検証結果のサマリー：結論から書く）
課題（発覚した課題や残課題）
関連リンク（関連する過去検証の情報）

「後任スタッフへの引き継ぎがうまくいかなかった」私たちは特に「検証目的を明示すること」を重視しました。

目的を資料に書き起こすメリットは大きく3つあります。

資料を作成する人の頭を整理できる
資料を読む人の情報量を処理する負担が減る
明文化することで、目的を客観視・共有できる

特に「目的を客観視・共有できる」ことは、私たちのチームではとても効果的でした。「過去検証の振り返り」の対応策として実施した運用でしたが、現在進行形で検証を行う時にも非常に効果的でした。作業を依頼する人、作業を引き受ける人が口頭のみで共有するよりも、まず資料に文章で目的を明文化します。その後、文書と口頭で説明を補足することで、認識の齟齬を減らす事ができます。検証時に本来の目的以外で発見されたバグなどについては、スケジュールや発生頻度を考慮して、バグ修正を次回アップデートに回すといった柔軟な対応が取れるようになりました。

文書フォーマットの効果

私たちのチームでは検証の概要を、基本的には5つの項目でまとめました。ここで決められた項目（目的・概要・結果・課題・関連リンク）というフォーマットととても相性が良かったです。

自由なフォーマットに落とし込んで書いた場合、資料作成者が「伝えたいことを伝えたいだけ、細かく記載してしまう」ことが発生します。必要項目に記入していく形式にしたことで、資料を読む人やこのあと引き継ぎする人が、知りたい目的や概要、結果などをまとまった状態で読む事ができるようになりました。さらに文書共有ドキュメントWebサービスを使うことで誰が記載してもフォーマットさえ決めておけば、資料のクオリティを下げる事なく、情報をまとめる事ができます。書式なども決められたものを使うので、資料としてのまとまりがよく読みやすいという利点があります。このようなWebサービスでは資料をツリー管理しているため、前後の検証の資料と紐づいた形で資料を閲覧・管理できます。

私たちのチームでは概要ページのタイトルを「yyyymmdd_検証概要」という命名規則で、管理しています。単純に過去資料の振り返りをしやすくなったという効果の他に、半年に一度、自分が行ってきたタスクや業務を振り返る時にも役に立ちました。まとめた資料は見やすく、リンクを一覧化することで、同僚や上司にそのまま報告ができるといった効果がありました。また自身の実績を整理する際に、さまざまなファイルやドライブを探しまわる必要がなくなりました。ドキュメントWebサービスにこれまでの検証内容が概要としてまとまっていることで、作業効率が上がり、管理しやすいという効果を感じる事ができました。