こんにちは。エキサイトでデザイナーをしている齋藤です。
今回は、開発施策をドキュメント化するときに心がけていることをご紹介します。
はじめに
私は、エキサイトブログやウーマンエキサイトなどのメディア系のプロダクトの開発に従事しています。
その中で、新規機能追加や数値改善施策を担当する場合、「なぜやるのか」「なにをやるのか」「どう評価するのか」をドキュメント化するようにしています。
PRD（Product Requirement Document・プロダクト要求仕様書）に類するものと思われますが、PRDより簡素なものでオリジナルの形式ですので知見を共有するためにブログに書きます。
なぜドキュメント化するのか
私がドキュメント化する理由は、チーム内向け・チーム外向けの2つに分かれます。
チーム内向けの理由
チーム内向け理由は、言わずもがなで目線と認識合わせのためです。
施策内容はチームミーティングで議論されることが多いですが、回を重ねるごとに議論が深化する故に状況が変わっていきます。
したがって、速記的な議事録のみですと漏れがあったり、内容にブレが生じたり、後から追っていくのに労力が必要になることも少なくありません。
そこで、議事録はあくまで発言内容のメモ程度に留めて、確定要素を切り出すことで内容に筋が通って追いやすくなり、結果的にチーム内の認識が合い、「結局何だっけ」状態を防げると考えます。
チーム外向けの理由
チーム外向けの理由は、自分が取り組んでいることの明文化を通じて指摘や助言を得られやすくするためです。
最近は、この点が開発施策をドキュメント化する大きな利点であると感じています。
私が属する事業部の開発部門では、ほぼ毎日チーム横断の朝会を実施しています。
その中で、タスク共有をするのですが、タイトルだけで報告するのではなく、ドキュメントを見せながら少し詳しく説明すると共有される側の解像度が上がり、疑問を投げかけてもらえたりします。
結果として、自分では気づけなかった課題が浮き彫りになることも少なくありません。
また、UI/UX設計について、他チームのデザイナーにレビューをお願いする際も貼付してリクエストすることで、レビュアーは表層的な意匠に留まらずに、施策の目的に沿ったUI/UX設計ができているかがチェックできると考えます。
どんなことをドキュメントに書いているか
普段書いているドキュメントはPRDほど重厚なものでなく、必要最低限の内容になっています。
最近の型は以下の通りです。施策の内容に合わせて変えることもあります。
- 関連ドキュメントのリンク
- 背景
- 仮説
- 狙う効果
- 競合調査
- やること
- やらないこと
- 成功定義と検証方法
- 機能概要
- ユーザー視点の要件
- ユーザーの体験
- 要件や体験を達成するために必要なデータ
関連ドキュメントのリンク
議事録やFigmaがある場合はリンクをまとめておきます。
背景
なぜその施策を実施するに至ったかの背景情報を記します。
{プロダクト}は{現状の状態}である。
{解決したい課題}となっている。
そこで、{施策を一文で表現}を通じて{期待する効果を一文で表現}を図りたい。
仮説
施策の土台となる仮説を記します。
{施策内容}することで、{ユーザーにもたらす影響}となり、結果として{期待する効果}のではないか
狙う効果
施策を通じてどんな効果を期待するかを箇条書きで簡潔に記します。
競合調査
競合とするプロダクトがある場合は、類似の施策が見られるかどうか、どんな内容になっているかを記します。
具体的な機能やUI/UXの設計に活かせる情報を記載するように心がけています。
やること
狙う効果や競合調査を踏まえて、どんなことをやるのかを箇条書きで簡潔に記します。
やらないこと
やらないことも箇条書きで簡潔に記します。
今はやらないけど次のフェーズでは検討の余地がある場合は、その旨もメモしておきます。
成功定義と検証方法
「成功」と表現していますが一喜一憂するためのものではなく、あくまで評価する目印であることを念頭に、何をもって施策は成功として、それをどう検証するかを記します。
特に数値改善の施策の場合、どの指標を用いるのか、その指標はどう取得できて、どうやって評価するのかを明確にしておきます。
機能概要
ここで、システム的な話を盛り込みます。
どんな機能にするのか、ユーザー目線の要件やどんな体験を実現するのか、その体験のためにどんなデータが必要になるのかを記します。
機能の実現方法は変化しておくことを前提に、初期段階ではがっちり書きすぎないようにするのも大切だと考えます。
まとめ
今回は、開発施策をドキュメント化するときに心がけていることとして、その目的や記していることをご紹介しました。
ご紹介した内容はあくまで一例であり、凝りすぎると起案者の自己満足で終わってしまう可能性もあるため、チームのかたちや状況に合わせて、そもそもドキュメント化が必要なのかから検討し、アレンジしていくことが大切であると思います。
現状、あくまで個人単位の取り組みでしかないため、組織として必要なのか、内容はマッチしているのか、ルール化は必要なのかは今後の課題です。
プロダクト開発に携わる方の一助となれば幸いです。
ご精読ありがとうございました。
