後で困らない要件ドキュメントの書き方

仕事でドキュメントに残す事によるメリットはいくつかあると思います。特に異動による人の入れ替わりの激しい組織に所属しているとノウハウだけでなく背景なども途切れ途切れになってしまうのでドキュメンテーションは本当に大事。そして何よりもドキュメンテーションを繰り返すと、抽象化する力や自分以外の誰かに伝えるという観点も鍛えられるので、最終的には回り回って自分に返ってくるという副次効果も得られます。
結局、仕事って誰かのために何かをやってあげる事で損する事ってあまりないと思うんですよね。ここら辺は特にテック系の会社で働いていると強く感じる所です。
まずは与えよ。自分の利益だけを考えて動いている人で得している人を僕は見た事がありません。

施策の要件はドキュメントをちゃんと残そう

webやアプリのサービス改善などをやっている体で話を進めます。施策の要件をドキュメントとして残す事には以下のようなメリットがあると思います。

誰が見ても
1.施策の背景や目的が分かる（立ち返る場所がある）
2.どういう条件で実行したのかが分かる（制約事項が理解できる）
3.打ち手の詳細が分かる（方法論が分かる）
4.その施策の結果が分かる（考察ができる。次につなげやすい）

ざっくりこんな感じでしょうか。文章にすると当たり前の事のように思いますがドキュメンテーションって習慣化しないと結構あっという間に崩れてしまうのでこういう軸があると続けやすいかなと思います。もう少し具体的なイメージで言うとドキュメンテーションする時は誰かの顔を思い浮かべながらやるとより良いと思います。その人に手紙を書くような気持ちだとエモくていいです。

施策の背景や目的が分かる

まず、そもそも何故この施策をやったのか。whyの部分を誰が見ても分かる状態にしておく事。ここがブラックボックスになってしまうと引き継がれた人、時間が経って見返した時、謎すぎてせっかく必要な施策だったとしても間違った判断につながってしまってはなんとも切ない気持ちに。
僕はこんな感じで書くようにしています。

施策の背景・課題：施策を行うにあたっての課題
事業目的：事業的なメリット
ユーザー目的：ユーザーにとってのメリット
指標：施策を判断する指標
効果見立て：この施策によって定量的にどんな数字が上がるのか

施策の背景や課題については、できるだけ定量的なデータも記載しておくといいです。定量的なデータがない場合は定性だけでもいいですが根拠が明確だと課題感がよりクリアになります。

また、目的については必ず事業目的とユーザー目的をセットで書くようにします。過去、事業目的だけで進めた案件でユーザー観点が弱くなってしまい最終的に思うような結果が得られなかった事があったりしたんですが、基本的にサービス改善において事業目的のみの施策がうまくいく可能性は限りなく低いでしょうし、ユーザー目的だけで取り組む案件は事業的なインパクトが出にくかったりします。そういう意味で両方の観点をちゃんと言語化しておく事は大事です。（もちろん施策によってここのバランスは変わったりする場合もありますが双方の目的が合致するのが良い）

また、ここら辺はユーザーストーリーという形で書いてみても良いと思いますがここら辺はチームによって臨機応変に変えればいいんじゃないかと考えています。

指標については施策を振り返る際にどんなKPIが達成できれば成功だったのかを判断するために設計します。KPIが定まっていないとせっかくの施策が正解だったのか失敗だったのかも分からなくなります。また、例えばA/Bテストを行う際なんかはKPIの他にテスト対象のセグメントなども決めておくと良いです。対象のセグメントによって分母が変わってくるので施策の検証結果のデータが変わってくる事もあるため、どういうセグメントかというのもKPIとセットで書いておくと分かりやすくなります。

例えばこんな感じ

ECサイトのお気に入り画面のUI改修によるABテストの場合
対象：お気に入りを1件以上しており、お気に入りページにアクセスしたUU
メインKPI：お気に入り経由のUUCVR
サブKPI：お気に入りページから商品詳細ページへの遷移率

効果見立てについては定量的にどれくらいのインパクトがある施策なのかを記載します。ここら辺はやり方は様々だと思いますが、過去の似た実績から改善インパクトを試算する、さらに松竹梅で効果を見立てる、などありますが大事なのはここの数字の正確さよりもインパクトを把握できるようにする事だと思います。ある程度、類推しておく事で実際の結果と照らし合わせて、次の施策の勘所としても使えるようになるんじゃないでしょうか。分からないではなく、推測して数字を置くって事が大事。コミットする数字としてしまうとちょっと気持ち的に辛いかもしれませんが。

どういう条件で実行したのかが分かる

ここからより施策の具体的な事を記載していきます。ただ、ここら辺はチームや扱っているものによって変わるので一旦はスマホアプリの改善と言う前提にしておきます。

対象OS：iOS / Android
対象画面：手を加える画面
A/Bテストの実施：テストの有無
制約・前提：ステークホルダーや機能的な制約がある場合に明記

対象OSが何か。どちらも展開しているサービスの場合、仕様差分が生まれる事もあるので分かる状態にしておきます。

またA/Bテスト案件なのか、本番すぐ反映の案件なのか。特にA/Bテストを頻繁に行っているチームとかの場合は案外認識ずれる事もあったりするので。

制約や前提はステークホルダーの確認がマストなのか、機能的な制約があるのかを開発後半の手戻り、ちゃぶ台返しを防ぐために明確にしています。どちらについても最初から読めるのであれば明記しておく事でリスクヘッジを早急に行えますし、もし開発途中でわかったとしたらすぐに追記＆周知は徹底した方がいいです。ディレクションする人は特にここら辺の情報のアップデートは過敏なくらいがちょうどいいです。

打ち手の詳細が分かる

実際に要件の詳細を記載していくパートです。が、ここについてはいろんなツールがあったりするのでコミュニケーションが取れる状態であればなんでもいいのではというのが持論です。

また併せて、よく抜けがちになるログの要件も明記しておくとリリースしてから「実はあのログ必要だったのに・・・！」なんて悲しみを防げますね。

・・・ここら辺はまた別にまとめたいと思います。

その施策の結果が分かる

施策の結果をまとめるコーナー。ここで欲しいのは抽出したデータとそのデータを元に分析した考察です。データだけが上がってても、課題に対してどういう結果だったのか。当初の仮説に対して結果としてどうだったのか。ここら辺をちゃんと言語化しておく事が大事だと思います。

アプリバージョン：施策をリリースしたアプリのバージョン
リリース日：対象バージョンのアプリがリリースされた日付
計測期間：データの計測期間
KPI：施策の判断指標
対象セグメント：施策の対象となる人たち
考察：施策によって分かった事と次にやる事

施策を打つ時って何かしらの仮説があるはずなのでその仮説がどうだったのか。当たっていたのであればその理由を。外れていたのであればその原因を。またそこから自分なりの考察を言語化しておき、さらにネクストアクションを決めておくと手詰まりがなくなります。逆にいうとここの考察の部分が抜けてしまうと施策が宙ぶらりんになってしまいます。施策が当たるに越した事はないですが、外れたとしてもその施策から何を学べたのかが一番大事な事なのでドキュメンテーションはそういった意味でもとても大事だと思うのです。

まとめ

要件ドキュメントテンプレート

▼背景と目的
施策の背景・課題：施策を行うにあたっての課題
事業目的：事業的なメリット
ユーザー目的：ユーザーにとってのメリット
指標：施策を判断する指標
効果見立て：この施策によって定量的にどんな数字が上がるのか

▼条件
対象OS：iOS / Android
対象画面：手を加える画面
A/Bテストの実施：テストの有無
制約・前提：ステークホルダーや機能的な制約がある場合に明記

▼詳細
zepplinやXD、figma、googledocumentなどなど

▼結果振り返り
アプリバージョン：施策をリリースしたアプリのバージョン
リリース日：対象バージョンのアプリがリリースされた日付
計測期間：データの計測期間
KPI：施策の判断指標
対象セグメント：施策の対象となる人たち
考察：施策によって分かった事と次にやる事

文章にすると非常に当たり前の事だなあと思うのですが、忙しかったりすると結構いろんな事が抜けたりします。ただ、大事な事は誰が書くか、どこに書くかと言う事よりも知識をちゃんとストックして成功も失敗も資産にするという事だと思います。またストックをする事でちゃんと自分の中に知識として定着していくため得られた経験の再現もしやすくなると思います。

施策の要件ドキュメントという前提で書きましたが、情報を構造化して整理して抽象化するという事は仕事において汎用的な事なのでドキュメンテーションやっていこうぜというお話でした。