見出し画像

チームの視座をあげる「施策のドキュメント化」のススメ

松下ゆき

noteのデザイナー（ときどきPM）の松下です。

どんなプロダクトであれ、行った施策の概要・結果の記録化はしていることが多いと思います。
この手のドキュメントはそれぞれの開発チームのスタイルがありますが、この記事ではnoteの、私が所属するチームで使っている「施策ドキュメント」のテンプレをご紹介します。

私としては、この「施策のドキュメント化」を導入してメリットしかなかった…！

運用じたいは、始めたのは今年にはいってから。その経緯・目的と、具体的なフォーマットについて書いていきます。

導入の経緯

チームのコミュニケーションツールとして「ドキュメント」は重要ですが、事業フェーズや用途によって必要なドキュメントは異なってきます。

noteの開発チーム体制はというと、ちょうど過渡期にあります。
数年はスモールチームのフェーズだったので、開発ラインもほぼ一ラインで完結。細かい記録や整理よりは「これを作ろう！出せた！」をどんどん積み重ねる、スピード重視で開発を行っていました。

いまはプロダクトや事業が拡大したこともあり、新しい仲間がかなり増えました（私が入社したときは35人程度だったのが、150人クラスに！）。体制が変わり、複数の開発ラインが動くようになったことで、意思決定や情報流通の方法も、もちろん各所見直す必要が出てきました。

そんなわけで、いまの開発体制をより生産的にするために「施策のドキュメント化」を取り入れ始めました。

施策のドキュメント化をする目的

①施策の精度・設計の視座をあげる

得てして、施策の話は「どうやってする？」のHOWの話で盛り上がりがちです。デザイナーやエンジニアは特に（自戒）。

ですが、一番大事なのはいうまでもなく「目的を達成する」ことです。
目的の言語化を行っていないと、みんなでわいわい盛り上がっていた「それいいじゃん！」が、実は目的の達成からはズレていた！なんてことも起こります。

なぜやるのか？だれの体験をよくするのか？なにをするのか？
その一連の考えの言語化を行い、書き留めておくことで、開発する施策の精度もあがりますし、チームメンバーの施策設計の視座もあがっていきます。
これは、いまのnoteが目指す、「自律的な開発チーム」にもつながります。

②施策結果のアーカイブ化と情報流通

いうまでもなく、施策やテストの結果は資産です。次の手に生かすため、得られた学びは流通可能な形にしておきたい。
施策を行った当人でさえ、しばらく経つと詳細が曖昧になっていくのですから、知見は書き留めておくべきです。
アーカイブ化をしておくことで、他チームや新メンバーが、すでに検証済みのことを再び開発してしまうような二度手間を防ぐことにもつながります。

使っているドキュメントの構成

使用しているドキュメントの構成は以下のような形です。これはPM間で議論してフォーマットを決定しました。Google Docsでテンプレート登録をしています。

  1. Why（なぜやるか）

    1. 現状・課題

    2. めざす姿

  2. Who（だれに向けるか）

    1. だれの体験をよくする？

  3. What（なにをやるか） 〜 How（どうやるか）

    1. こうしたら解決するのでは？仮説

    2. やること

    3. やらないこと

    4. 成功条件

      1. めざす姿にたどり着けた場合どうなるか

      2. 評価指標/反指標

    5. どうやって届けるか？

  4. 結果振り返り

    1. 結果

    2. 次やること

この流れは、以前の記事でも書いたのですが、プロダクトを考えるうえでおさえるべき普遍的なものを展開しています。
構成が似ているものにPRDもありますが、今回はよりボトムの、個別の施策の記録を目的としています。

導入してみての効果

私としては、このドキュメントの運用は取り入れて良いことしかなかった！です。

もともと掲げていた目的に対しては狙った効果がでているといえます。

PM間で共通フォーマットを使用することで情報の水準をあわせることができますし、実際に、新しいメンバーが入ってきた際にこれまでの動きを振り返るうえでも活用されています。

いっぽうで、運用してみてわかった課題や改善ポイントもあります。

ドキュメント運用の課題・改善ポイント

導入時のハードル

いつだって、新しい取り組みを始めるときにはその浸透にコストがかかります。今回は新しいチーム体制が始まるのとほぼ同時にこの運用を開始したいとメンバーともコミュニケーションをしたので、区切りとしていいタイミングで導入ができました。
そのときの開発体制によって何を優先させるかは変化があります（noteがそうであったように）。必要だ！となったタイミングで、見込まれるメリットと一緒に提案してみると通りがいいのではと思います。

完璧なものを最初から用意するよりも、まずは試してみて、運用するなかで改善点があれば、PM間でサクッと合意し柔軟に変更するスタイルにしていました。

ドキュメント記入コストのバランス

それなりに項目数があるので、全ての施策で全て記入していると望む開発スピードとバランスがとれなくなることがあります。
必要性に応じて、必ずしもドキュメント作成や全項目記入を必須としない運用をしています（すでに出している施策のチューニングやバグ対応など）。
また、PMがすべて記入するのでなく、メンバーでの作成も前提にしています。

これまでに作成したドキュメントの検索

まわした施策数が積み重なるにつれ、過去の施策の参照コストがあがることは目に見えています（というかすでに見え始めている）。

現状は、記入/導入ハードルの低さ・メンバー間でコメントしあいながらの同時編集などのメリットが大きいためGoogleDocsを使用しています。
GoogleDocsはフォルダ内検索も可能です。しかし、本文のどこに検索ワードが該当しているかなのクイックな確認は難しいため、検索機動性の重要度が高まった場合は別のツールへの移行も検討するかもしれません。

まとめ

いうまでもなく、Why~Who~What~Howの流れはデザインともリンクするものです。
このドキュメントを自分でも作成してメンバーとの共通言語とすることで、私自身のデザインの視座をあげる訓練にもなっていると感じます。

今回のドキュメント以外にも、チーム開発で役に立つツールはメンバーレイヤーや用途に応じて様々なものがあります。
一例として、参考になれば幸いです！

サポート、あなたの想定以上にすごく励みになります！