全員に背景情報をフルに伝えるDuolingoのプロダクト仕様とは（すぐに使えるテンプレート付き）

チームが成長するにつれ、情報が整理された状態を保つことは難しくなっていきます。それはやがて、何を構築すればいいのか、なぜそれが重要なのか、どうすれば多くの部門が関係する情報をスケーラブルな状態で整理できるのか、わからなくなってしまう状況を招きます。

DuolingoのグループプロダクトマネージャーであるNatalia Castillejo氏は、プロダクト部門で身をもってこれを経験しました。承認は場当たり的に行われ、重要な情報（要求仕様書やリサーチ、戦略ドキュメントなど）は見つけにくく、会議は焦点が定まっていないものでした。

賢明な良い意志決定を行うために必要な正しい情報を、誰もが確実に得られるようにするにはどうすればよいか。この課題に答えを出すべく、チームは一からやり直すことにしました。

Castillejo氏とチームは、Notionでプロダクト仕様書を再構築しました。今ではそれは、人と情報をつなぐ中心的な存在となっています。コンテキストに詳細な要点を組み入れ、全員ができ得る限り最高の、そして最もインパクトのあるプロダクトをローンチすることに注力できるようになりました。

プロダクトチームは多くの場合中心的な存在で、社内のほぼすべてのチームと共に仕事をします。でも、各部門の関係者が必要とする情報の粒度はそれぞれ異なります。

Castillejo氏はこう言います。
「私たちのようにプロダクト部門全体にチームが分散している場合、構築に一貫性と統一性を持たせることがますます重要になります。メンバーが正しい情報を持っていなければ、私たちが目指すプロダクト作りに支障をきたしかねません」

たとえばリーダーが作業の概要を知りたい一方で、他部門の関係者はプロダクト仕様が検証している内容についてより深く詳しい情報を必要としている場合があります。

Castillejo氏は2つのセクションを設けて、全員が欲しい情報を入手できるようにしました。

仮説セクションでは、実験を詳細に定義します。チームは用意されたフレームワークに沿って、各仮説のインパクトを最大化します。

各仮説は以下の項目に沿っている必要があります。

1. 暫定的： 1つ以上の実験の結果に基づいて改善が可能。

2. 反証可能： 誤りを証明することが可能。

3. 検証可能： 実験を通じて仮説を裏付けたり反証したりするためのエビデンスの収集が可能。

4. 一般化可能： 1つの実験で得られた仮説の結果を、今後の実験に応用することが可能。

ここからチームは1行の簡単な説明を作成し、リーダーがドキュメントの冒頭を見た時に実験の概要がわかるようにします。しかしこの短い説明は、単にプロダクトの実験を定義する以上の働きをします。

仮説に異なるレベルがあることで、読者は俯瞰レベルでも深いレベルでも、何が起きているかを理解するのに十分な情報を得ることができます。

プロジェクトが部門横断的であればあるほど、並行して行われるすべての作業と進捗状況をまとめることは難しくなります。そうなると重要なコンテキストが不足するため、チームのコラボレーションのやり方にマイナスの影響が及びます。

Castillejo氏がこうした課題の多くに気づいたのは、プロダクト仕様のレビュー会議のときでした。焦点が定まらず生産性の上がらない会話をしていたため、チームは答えよりも疑問を抱えて会議を後にしているような状態だったのです。

そこでCastillejo氏とチームは、プロダクト仕様全体を通じて仕事を適切に結びつけるエリアを設け、検証中の事項に関するコンテキストを追加するエリアを構築しました。

• Meeting Goals（会議の目標）のセクションでプロダクト仕様のすべてのレビュー観点が定義されるため、チームは会議で具体的なフィードバックを得ることができます。

• Background and Summary of Changes（変更点の背景と概要）セクションでは、前出の1行仮説についての説明と、以前の実験から学んだことを記載します。

• Related Work（関連作業）セクションには、プロジェクトに関連するドキュメント、リサーチ、議事録、タスクなどをまとめて記載します。

• Design and Interaction（デザインとインタラクション）セクションでは、Figmaのデザインファイルの埋め込みや追加のスクリーンショットなどを掲載して、プロダクトの変更予定箇所を正確に示します。

情報をプロダクト仕様に盛り込んでまとめることで、関係者が複数部門にまたがっていても、たくさんのツールで最新情報を探したり、遅れをとったりする心配をしなくて済むようになります。プロジェクトのあらゆる部分をつなぐ信頼できる唯一の情報源がNotionに存在するため、チームの手元には的確な情報があり、また後々も簡単に見つけることができます。

Castillejo氏にとってフィードバックを収集することは、有意義な洞察をプロダクト仕様に取り入れ、アイデアを反復し、新しいプロダクトを計画するための方法です。そのすべてを、実際のユーザーデータに基づいて行うのです。

ペースの速いプロダクトチームにとってフィードバックを得ることは、焦点からぶれることなく（またスコープの漏れや変更を避けながら）構築するために特に重要です。Castillejo氏とチームはプロダクト仕様を再構築して、定性的・定量的なフィードバックの両方を取り入れられるようにしました。

Quantitative Feedback（定量的フィードバック）のセクションは、プロジェクトを主要な指標に結び付けます。これは、次の3つのエリアに分かれています。

• Success metrics（成功指標）： 実験により測ろうとしているもので、多くの場合、チームのOKRと合致しています。たとえば「1日あたりの収益」「1日あたりのアクティブユーザー数」などです。

• Feature metrics（機能指標）： 検証対象となる機能のインパクトです。たとえば「この機能から無料体験版を始めたユーザー数」などです。

• ガードレール指標： モニタリングすべき重要なビジネス指標で、この実験により悪影響を受ける可能性があるものです。たとえば、「この機能により1 日の収益は増加するかもしれないが、1 日のアクティブユーザー数には悪影響が出る可能性がある」といったものです。

Qualitative Feedback（定性的なフィードバック）セクションには、内部検証と正式なユーザーリサーチの両面からのコメントが含まれます。数字以外の側面に目を向けて、学んだこと、変える必要があるかもしれないこと、将来何を強化すべきかなど、さまざまな視点からの洞察を提供するよい機会となります。

チームと関係者、リーダー陣まで全員の足並みが揃った時、さらに強力な仕事が可能になります。対して、情報が散在してインパクトが不明確な時には、物事を効果的に行うことはまず不可能です。

DuolinngoがNotionでプロダクト仕様テンプレートを構築したのはそのためです。Notionで構築することで、プロダクトチームが全員の足並みを揃えるように情報を結び付けて整理することが可能になります。こうすると一か所で関連する情報や明瞭な答えが得られるため、チームはかつてなく集中して効果的に仕事ができるようになりました。

Duolingoのプロダクト仕様テンプレートは、こちらから複製してご利用いただけます。