製品操作とは何ですか？（プロダクトマネージャーについてここで説明しましょう）

プロダクトマネージャーの1回限りの説明

プロダクトマネージャーの日常業務では、さまざまな種類のドキュメントに触れたり、作成したりする必要があることがよくあります。標準化され、品質の高い文書を出力する方法をご存知ですか?この記事では、著者が文書で遭遇した落とし穴をまとめ、関連するスキルをまとめています。見てみましょう。

ドキュメント作成自体は、プロダクトマネージャーの日常業務の最も基本的な部分です。私たちはほぼ毎日文書を書いていますが、これらの出力は本当に適切なものなのでしょうか?ドキュメント作成機能を改善したい場合、どのような簡単な「すぐに使える」方法を使用できますか?

今日は私が長年文書作成で遭遇した落とし穴と、仕事でまとめたスキルを一つずつ紹介します〜

まず、文書の重要性についてお話ししましょう。それらの重要性に対する認識を高めることは、何かをうまく行うための前提条件です。

質の悪い文書を書いたり、悪い文書を書いたりする学生の多くは、それに十分な注意を払っていないことがわかりました。

私たちが日常的に作成する文書には、要件仕様書、製品マニュアル、製品紹介、あるいは通常の日報、週報、月次サマリー、四半期サマリー、年次レビューなどがあり、またプロジェクトの進捗や承認プロセス中のさまざまな出力、あるいは販売前プロセスにおける多くの資料もあります。

それらは、個人、チーム、さらには企業の専門性を客観的に反映することができます。

数年前、上司は、文書にタイプミスや構成の悪さがあったため、私が仕事をきちんとできていないと批判しました。
また、履歴書の誤字のせいで、希望していたオファーを逃してしまいました。
また、タイプミスが原因で特許出願が特許庁に却下されたケースにも遭遇しました。
パートナー組織から提供される文書に誤字脱字が頻繁に含まれていたため、私はかつて会社にパートナーを変更するよう提案したことがあります。
仕事で提出した書類が顧客に気に入られず、書き直しのために差し戻されるといった状況に遭遇することもよくあります。

したがって、これらのドキュメントをチーム内の「対処資料」としてのみ捉えたり、単語が多すぎて誰も注意深く読まないだろうと考えたりして、長期間にわたって標準化された良い習慣を身に付けることができなかった場合、後になって陥る落とし穴は間違いなく私が陥ったのと同じぐらいのものになるでしょう。

そこで、ドキュメント仕様の重要性について、皆さんの参考のために 4 つのポイントをまとめました。これらのポイントが皆さんの注目を集めることを願っています。

個人、チーム、会社のプロフェッショナリズムを実証し、相手からの評価を獲得します。同時に、これらの「いわゆる小さなこと」のせいで他人に非難されないようにしてください。
優れたドキュメントは「読みやすさ」や「可読性」を向上させることができ、読者に良い印象を与えるだけでなく、その後の作業で誤解や不要なトラブルを回避することにもつながります。
文書は、客観的な参考資料として、二者間の争いの際に最も有利な証拠となります。 （文書に曖昧な点があったり、自分のチームにとって不利な内容があったりすると、早い段階で見つけられなければ、後の段階で落とし穴があることを願うしかありません）
最後に、上で述べた重要な問題のいくつかを挙げます。これらの材料が何らかの重要な目的で使用されると、重大な悪影響が容易に発生する可能性があります。

文書の重要性を理解した上で、今日のテーマである【文書標準】を見て、文書をわかりやすく伝える方法を見てみましょう。明確な文書コミュニケーションの原則、文書形式の標準、コンテンツ標準という 3 つの側面から標準について説明します。さらに、ドキュメントの最後では、製品の PRD ドキュメントを例として使用して、ドキュメント作成基準の実際の解釈を示します。

文書はピラミッド原則に従って作成し、読者が最短時間で重要な情報を得られるように努める必要があります。読者に読みたいものを選んでもらうのではなく、読者が見たいもの、見るべきものを、最も正確な言葉を使って最も適切な場所に置くことです。誰もが文書を注意深く完全に読むとは想定しないでください。「より多く」かつ「完全」になることを目指すのではなく、「より少なく」かつ「より正確」になることを目指してください。

注:ドキュメントを書く前に、次の質問を自問してください。

背景は完全に理解されていますか?
目標（方向性）を正しく理解していますか？すべての関係者と合意に達しましたか?
現状のすべてのデータは明確ですか?リソースの割り当て（人員投入と時間を含む）は合理的ですか?
核心的な問題は明確に分類されていますか?サブ問題に対する的を絞った解決策はありますか?
考えられる選択肢はすべて検討されましたか?リソース投資の費用対効果は許容範囲内ですか?

覚えておいてください：問題を明確にせずに提案された解決策は不正であり、目標から分解されていない問題は解決する必要はありません。無意味なことに時間とエネルギーを浪費するよりも、考えることに時間を費やす方が良いです。

考えることでその後の行動がより効果的になる一方で、行動に没頭するとリソースが無駄になり、将来の計画が遅れるだけだからです。

文書を書く前に、誰がこの文書を読むのか自問してください。役割とポジションは何ですか?彼らはどんな情報を知りたいのでしょうか?一般的に言えば、およそ6つのカテゴリーがあります。

カテゴリー1: 顧客

質問: どんなプロジェクトですか?メリットとデメリットは何ですか？何をする？私たちは何をする必要がありますか?どうやって利益を上げるのか？一般的に顧客が気にするのは、あなたのプロジェクトが何であるか、あなたが何をする必要があるか、そして相手側が何をする必要があるかです。複数の比較を行って、最適なパートナーを選択することができます。したがって、彼らにとって重要なのは、明確な情報に基づいてあなたのプロフェッショナリズムを体験することです。

カテゴリー2: 上司（CEOなど）

質問: どんなプロジェクトですか?結論は何ですか?何をする？彼らは毎日あまりにも多くのことを処理する必要があり、初めて文書を見たときにはその内容に反応できない可能性があります。そのため、タイトルと本文にプロジェクト名と簡潔な背景を明確に伝える必要があります。プロジェクトが特定されると、最も重要な結論情報を読むのに少し時間を費やすだけで、詳細な分析プロセスには興味がありません。文書に問題が明示されている場合、上司は単に問題を知りたいのではなく、問題がどのように解決されるのか、また、解決できない場合は、解決するためにどのようなリソースが必要なのかを知りたいと考えていることに注意してください。あるいは、現時点ではどのようなアイデアをお持ちですか、あるいはどのような試みをしたいですか?

3番目のカテゴリー: ステークホルダー - 管理者（直属の上司など）

質問：結論は何ですか？どのようにしてこの結論に至ったのですか?次は何をしましょうか？文書の結論は彼らの仕事に直接関係しているので、彼らは結論が何であるか、どのようにして結論に達したか、それは厳密であるか、そして他の解釈の方法はないかに細心の注意を払うでしょう。文書によって明らかにされた問題については、その解決には彼のリソースが必要になる可能性が高いため、問題と目標について彼と合意し、調整して解決する必要があるものを明確にする必要があります。文書を送信する前に、相手方といくつかの重要な詳細を個人的に確認することをお勧めします。

カテゴリー4: ステークホルダー-実行者（製品や市場など）

質問：結論は何ですか？次に何をする必要がありますか?文書の結論は自分の仕事に直接関係しているので、結論自体にも注目しますが、それに比べると、協力するために次に具体的に何をする必要があるかということの方が気になります。このため、ToDo の責任をその人に割り当てる必要があります。

カテゴリー 5: 関連部門 (財務、設計、技術、テストなど) に通知する

質問: 何が問題なのですか?どうですか？それは私にどのような影響を与えるのでしょうか?何をすればいいですか?既知の部門は背景を完全には把握していない可能性があるため、最初の質問は「プロジェクトとは何ですか?」です。タイトルと背景からプロジェクトの内容がわかったら、結論をざっと見て、それが自分の仕事に影響を与えるかどうかを考えます。そのため、文書の内容自体はこれらの関係部署に関係ないものの、後々協力が必要になると感じた場合は、比較的早い段階で文書を同期させて、相手が準備できるようにすることができます。

6番目のカテゴリー: 私たち自身の人々（チームメンバーなど）

質問: 誰が何をしましたか?現在の進捗状況はどうですか?どのようにお手伝いしましょうか？弊社のスタッフは、文書の内容を一字一句確実に読み、情報を理解した上で、どのような情報やリソースが役立つかを考え、一時的な状況が発生した場合でも迅速なサポートを提供できるようにします。

機密データや結論を含まないドキュメントはグループ内で同期することを強くお勧めします。

背景：

プロジェクトの内容を説明する 1 ～ 2 文。データ分析の場合は、元データの範囲を説明する必要があります。

a.すべてのプロジェクトに背景情報が必要なわけではありませんが、背景情報を明確にすることで、プロジェクト自体を理解し、プロジェクトにおける自分の役割をより適切に位置付けることができます。

b.プロジェクトの背景は非常に複雑であり、厳密さと洗練の原則を遵守しながら、物事を迅速かつ明確に説明するために適切に拡張することができます。プロジェクトの背景を知らない人のために、拡張部分は括弧で囲まれています。

現状：

問題の現状を明確かつ簡潔に説明します。順序に従って記述します（時系列順、重要度順など）。

a.現在の状況を全て書かないでください。誰もが知っていることを書かないでください。記事の内容に関係のないことは書かないでください。この記事の内容に関連する最も重要な転換点と現在の状況のみを記述します。

b.現状について何を試み、何を考えたか、それが実行可能であればどのような結論に達し、実行不可能であればどのような障害があるかを他の人に伝えます。次に解決できる問題と、不要でまったく対処できない問題を全員に知らせます。

紀元前人員投入や時間など、プロジェクトの現在のリソース割り当てをリストします。

意思決定：

現在の状況を踏まえて、上司は今どのような決断をする必要があるでしょうか? （上司やリーダーは、単に問題を知りたいだけではありません。問題がどのように解決されるかも知りたいのです。解決できない場合、解決するにはどのようなリソースが必要ですか？あるいは、どのようなアイデアがあり、どのような試みをするつもりですか？）

a.現在の状況について早急に結論を出さないでください。通りすがりの人をランダムに呼び出して、この質問を見るように頼むところを想像してください。彼はどんな答えを出すでしょうか？答えが今考えていることと同じであれば、注意が必要です。

b.判断は十分な事実に基づいて行われなければなりません。根拠が不十分であったり、判断が適切でなかったりする場合は、事実をそのまま反映するだけで済みます。

紀元前定量化できるものは定量化する必要があります。これは、 「減少」と「増加」の後に特定の振幅が続く必要があるのと同じです。

d.できるだけ正確な言葉を使用し、 「影響を受ける」、「おそらく」、「おそらく」などの中立的な言葉の使用は避けてください。

e.長すぎるテキストは避けてください。テキストが長すぎる場合は、太字と色を使用して重要なポイントを強調します。データを提示するには、構造化されたアプローチを使用するようにしてください。データの集合であれば、表形式で提示することができます。

やること:

現在の状況を踏まえると、何かをするには他の人の協力が必要です。

a.行うべきことは、文書内の問題点を指摘することであり、明確な論理的対応を持つことが最善です。個人に責任を割り当て、納期も示すようにしてください。

b. 「to do」を書くときは、穴を掘らないこと、約束したことには責任を持つこと、確実にできるときだけ断定的な口調を使うことを心がけましょう。リソースの問題がある場合は、事前に開示する必要があります (たとえば、xxx がスケジュールを提示するまで待機し、xxx が問題を確認した後に解決策を提供します)。

分析プロセス（必要な方のために記事の最後に添付しています）

分析を書く目的は、結論がなぜ正しいのかを証明することです。結論と一致する必要があり、実際の分析の正確な順序で書かれるべきではありません。

a.行った作業をすべてリストする必要はありません。あなたの結論が多くの計算から導き出されたものであることは誰もが知っています。結論に関係のない部分は簡潔にまとめるか、本文から除外する必要があります。

b.大きな Excel テーブルの使用は避けてください。情報を見つけるのに役立ちません。重要でないコンテンツは削除して表示しないようにし、元のデータを添付ファイルとして配置することができます。

紀元前複数のディメンションは複数のテーブル (日付、都市など) に分割し、一度に比較するのは 1 つのみにする必要があります。

d.保持される指標を改良する必要があります。あまり一般的に使用されていない指標については、その計算方法と重要性を説明する必要があります。相手が直接理解してくれることを期待しないでください。

e.計算方法が不明な場合は、ビジネスの観点から数字の意味を考えてみましょう。 (たとえば、「平均してから合計」とすべきでしょうか、それとも「合計してから平均」とすべきでしょうか?)

f.データを表現できる「口径」は複数ありますが、ここでは分析後に最も科学的であると判断したものだけをリストアップしています。すべての計算を添付ファイルに含めることができますが、異なる結論を説明する場合を除き、ドキュメントにすべてをリストしないでください。そうしないと読者は混乱してしまいます。

この部分は長くて複雑になる可能性があるため、読者が理解しやすいように、分析の前にロジックを簡単に説明することができます。サブ見出しを使用して分析をガイドすることもできます。目標は、すぐ下の結論の根拠を見つけることです。

ほとんどの製品担当者はこの側面に注意を払う必要がありますが、多くの場合、ドキュメントが多すぎると、私たちは「麻痺」してしまい、いくつかの詳細を無視してしまいます。しかし、他の職種の同僚の多くは、文書形式の標準化にあまり注意を払っておらず、最終的な成果物は「説明するのが難しい」ものになっています。フォーマットの標準化には、主にフォント、段落タイトル、段落内タイトル、画像、ディレクトリが含まれます。

フォントに関して最も重要なことは、テキスト全体にわたって一貫性を保つ必要があるということです。 「本文フォント」「小見出しフォント」「表内のフォント」「補足説明フォント」「要点フォント」に分類し、各カテゴリ内のテキスト全体のフォントが統一されるようにします。

表内のフォントサイズは、表の並べ替えが「歪んで」しまったり「乱雑」になったりしないかどうかも考慮する必要があります。表の最初の行のタイトルは太字にして中央に配置することをお勧めします。各章のタイトルは、書式ブラシを使用して均一に維持する必要があります。多くの文書では、段落ごとにフォントサイズやスタイルに多少のばらつきが生じます。理由は、作者に確認する意識がなく、コピー＆ペーストが完了した後に書式ブラシを使って統一する習慣がないためです。

書式ブラシを使用してすべてのレベルでタイトルを統一する場合、小さな間違いが起きやすくなります。 eg1 を例に挙げます。下の図は、第 4 レベルのタイトルを第 3 レベルのタイトルに変えてしまう典型的なレベルエラーです。

例 2: 下の図は、番号を付け直さずにコンテンツをコピーしたために発生した典型的な番号付けエラーです。

さらに、文書内の段落内ではサブ見出しを同じ形式に保つようにしてください。例えば、(1)(2)(3)を使用する場合、文書内で複数レベルのソートが必要な場合を除き、①②③を使用せず、複数のサブ見出しスタイルを検討してください。

ドキュメント内の画像は中央に配置する必要があります。章内に連続した複数の画像がある場合は、各画像にテキストの説明を添付する必要があります。

さらに、画像のサイズも微調整する必要があります。特に、コピーした後で非常に大きくぼやけている画像があります。このとき、画像はテキスト全体と可能な限り一致するサイズに縮小する必要があります。特に、モバイルのスクリーンショットは、ドキュメントにコピーされた後、「細くて長い」ものになることがあります。この時、サイズは任意に調整し、幅を統一するようにしなければなりません。

カタログをタイムリーに更新することを忘れないでください。コンテンツが変更されたが、カタログを更新せずに直接送信される状況がよく発生します。また、多くのデフォルトの目次形式は非常に見苦しいため、特に Word で作成する場合は、目次のフォントと間隔を適切に調整することを忘れないでください。

上記詳細は、ドキュメントのフォーマット仕様のすべてです。それぞれを個別に実行する必要があることを知っている場合もあれば、簡単に実行できると思う場合もあります。文書を書くときは、これらを些細なことだと思って気にしないでください。細部がプロフェッショナリズムを決定します。上で述べた「小さな問題」がすべて 1 つのドキュメントにまとめられているところを想像してみてください。それは読者にとって「惨事の現場」ではないでしょうか？

ドキュメントの内容に関しては、業界や用途によって内容の要件が異なるため、この記事では内容の構成方法ではなく、内容に関係なく確認して回避する必要がある一般的な問題に焦点を当てています。

最初で最も重要な点は、インテリジェントな入力方法が普及したことにより、私たちの日常のテキストコミュニケーションにはタイプミスが溢れているということです。こうした誤字がプロダクト担当者のアウトプットに現れると、 「印象ポイント」に大きく影響し、担当者の注意力や真剣さも疑われることになります。タイプミスは悪いことだと誰もが知っていますが、それを検出するのは困難です。しかし、これはタイプミスを許容する理由にはなりません。そこで、タイプミスについては次の提案があります:

1) 比較的インテリジェントな入力方法に変更する

結局のところ、優れた入力方法は、私たちがよく使用する専門用語を記憶し、スペルミスがあった場合にインテリジェントなプロンプトを表示することができます。システムのデフォルトの入力方法では、この効果を実現するのは困難です。以前、タイプミスをよくする友人がいました。彼はMacのデフォルトの入力方法を使用していました。 Sogou に切り替えた後、タイプミスの数が約 60% 減少しました。頻繁にスペルミスをすることは大きな問題ではありませんが、間違いなく迷惑であり、個人的に影響を及ぼします。他の人の文書を読んでいるときに、タイプミスや休止、一貫性のない文章があることに気付いたと想像してください。どう感じますか？

2) 日常生活にもっと注意を払う

タイピングやチャットをするときは、タイプミスをしない習慣を身につけましょう。送信する前に内容をざっと確認してください。タイプミスがあった場合は、すぐに修正してください。これはすべてのプロダクト担当者が身につけるべき習慣だと思います。それは非常に基本的なことです。しかし、多くの人は気にせず、何度も指摘されてもただ笑って自分を慰める理由を見つけるだけです。そうすると、これらの人々は間違いなく、質の高い製品ドキュメントを書くことができなくなります。

3) チーム内で何らかの報酬と罰則を導入することができる

これは指導者が全員に従うよう要求する規則であり、ちょうど子供たちが初めて書き方を習ったとき、字の汚い生徒の宿題を破り捨てて書き直す権利が教師にあったのと同じです。重要な文書にタイプミスが見つかった場合にチーム内で赤い封筒を送ったり、他の学生の文書にタイプミスを見つけた場合にタイムリーにリマインダーを送信したりするなど、多くの賞罰措置があります。つまり、全員が注意を払い、毎日チェックする習慣を身につけるための対策を講じれば、徐々にタイプミスは減っていくでしょう。

4) 何度も読む必要がある

長い段落を書いた後は、必ず少なくとも 1 回は読み直して、一方ではタイプミスがないか確認し、他方では意味表現に問題がないか確認します。結果に対しては自分自身で責任を負わなければなりません

5) 同僚にチェックを手伝ってもらうこともできます

習慣的な思考のサイクルに陥っているため、自分で犯した間違いに気づくのが難しい場合があります。したがって、同僚に確認を依頼することをお勧めします。さらに、お互いの間違いを特定するために助け合うことは、自分自身を大いに調べ、タイプミスに対する認識を高めることにも役立ちます。

上記の方法は多面的であり、すぐに組み合わせて使用できます。意図的な練習の過程で、タイプミスに対する感度が徐々に向上し、エラーをすばやく特定し、「高頻度タイプミス」のいくつかを要約できるようになります。

コンテンツの標準化に関しては、上記で述べたことに加えて、もう 1 つ非常に重要な点があります。書き言葉は数百年にわたって発展し、書き言葉の表現は元の中国語 (古典) から中国語 (方言) へと変化してきましたが、中国語 (方言) は話し言葉と同等というわけではありません。話し言葉の代わりに書き言葉を使用する利点は、 formal、standardized、serious、rigorous という 8 つの単語にあります。チームの内部文書であれば、リーダーが異論を唱えない限り、誰もがやりたいことを何でもできます。

しかし、外部へのアウトプットとなると、厳密なロジック、明確な表現、明確な構造が基礎となります。ここでいくつかの重要なポイントを挙げ、文書を作成するときにこれらの問題を回避することをお勧めします。

1) 表現が簡潔でわかりやすい

もちろん、一部の文書は複雑かつ厳密なものにする必要がある場合もあります (特許出願文書など)。非常に読みにくいですが、論理的な抜け穴はまったく見つかりません。しかし、私たちが目にする文書のほとんどは、読者ができるだけ早く表現したい内容を理解できるよう、できるだけシンプルでわかりやすいものにする必要があります。例えば：

「したがって」、「さらに」、「だから」、「しかし」、「でない限り」などの論理接続詞を使いこなせるようになります。
フレーズを簡略化して、「何かが起こるとき」を「何かが起こるとき」に変更します。
複雑なロジックは、セグメンテーション、番号付け、因数分解によってより直接的に表現されます。

2) 曖昧な言葉を避ける

「千人の心の中には千のハムレットがいる。」多くの単語は多面的な意味を持ち、不適切に使用すると読者に誤解を招きやすくなります。したがって、これらの言葉を使用するときは、習慣的な考え方から抜け出し、ユーザーの視点からその表現が正確であるかどうかを検討する必要があります。

a.たとえば、「xxおよびその他の機能」、「など」という単語。非常に微妙です。販売前の文書であれば、「待機中」でも問題ありません。配送書類の場合、「待機」によってその後の受領に落とし穴が生じやすくなります。

b.たとえば、「ユニット」という単語は、測定単位、会社、雇用主を表すことができます。もちろん、文書の文脈と組み合わせることで意味を理解できますが、段落内で同じ単語が異なる意味を表すために現れる場合は、説明したり、別の形式で表現したりする必要があります。

紀元前また、ある本で、「資産運用」という言葉が非常に曖昧であることに気付きました。多くの人は、オフィス資産や固定資産などの「資産」管理システムと考えるでしょうが、金融実務家として最初に思い浮かぶのは、資金の「金融資産」管理システムでしょう。これら 2 つのシステムはまったく異なります。

したがって、コンテンツの「曖昧さ」を避けることは、コンテンツ標準において非常に重要なポイントです。

意味をはっきりさせ、相手に何度も理解させないようにしましょう

これは、簡潔でわかりやすい方法で物事を表現することに似ていますが、冗長性が少なく、ビジネスロジックを可能な限り直接的に保つ傾向があります。例えば：

二重否定語 (have to) を肯定語 (just) に変更します。
「網羅的」を「除く」に変更します（条件 1、2、3、4、5、6、7、8 では、条件 9 と 10 を除いて変更します）

最後に、コンテンツの標準化に関しては、特に顧客に送信される文書については、ファイル名の命名標準を恣意的に使用してはならないことを強調することが重要です。ファイル名を通じて、読者にこの文書の目的や中心となる内容を知らせるのが最適です。さらに、ファイル名はテキスト内のメインタイトルと一致している必要があり、ファイル名には顧客の略称、バージョン番号、または変更日を含めるようにしてください。変更日は通常、後続のバージョンが変更された後に追加されます。例えば：

【社名略称】製品名＋用途＋バージョン番号
【顧客名】+ 会社名+ 製品名+ アプリケーション+ バージョン
製品名 + 用途 + 日付 – 備考

つまり、ドキュメント名の重要性を無視しないでください。専門的でない名前を付けると、相手は開封もせずに拒否する可能性があります。

上記はコンテンツ基準の概要です。皆さんも意識的に練習して、避けるようにしていただければと思います。

上記のほかにも、参考として一般的な考慮事項がいくつかあります。

文書を作成するとき、未完成のコンテンツの一部をマークして、後で改善するまで待つ傾向があります。このとき、マーキングはすぐに見つけられるように非常に便利なものでなければなりません。たとえば、特定のキーワード (todo、完了予定) を使用したり、コメントを挿入したりします。単にフォントの色や背景色を追加して目立たせるだけではいけません。なぜなら、文書が非常に長く、行ごとにチェックされていない場合、見逃される可能性が非常に高いからです。

ドキュメントの内容がそれほど大きくない場合は、複数の人が共同作業を行うときに [リビジョンモード] を使用して、共同作業プロセス中の競合や不注意によるコンテンツの問題を回避するようにしてください。最終的なマージ中にリビジョンを 1 つずつチェックすることで、コラボレーションプロセスで多くのトラブルを回避できます。もちろん、ドキュメントが長い場合、修正モードは非常に遅くなります。複数の人が共同作業を行う場合、複数の人が同じ部分を修正することを避けるために、他の共同作業ツールを使用するか、作業を分割します。

「バージョン変更記録」はあったほうが良いですが、必須ではありません。結局、後から変更記録を維持するのは非常に面倒です。ドキュメントのバージョンが頻繁に変更される場合、またはそれを追跡する必要がある場合は、リビジョンレコードを追加できます。修正記録について注意すべきもう 1 つのこと:修正された内容は受信者が見るのに適していますか?理由については、多くは言いませんので、ご自身で考えてみてください。

他の顧客の名前、他の製品の名前、間違いやすいキーワードなどを含む「キーワードシソーラス」を日常的に維持することができます。ドキュメントが完成したら、グローバル検索を実行すると、おそらく「驚き」があるでしょう。

一部の章に内容がない場合や書き方がわからない場合は、「該当なし」としてマークできます。ただし、章を直接削除した場合、その後の納品およびレビュー時に修正される可能性があります。もちろん、削除の前提も顧客に明確に伝える必要があります。

次に、製品に対して一般的に記述される PRD ドキュメントを例に、参考テンプレートを示しますが、これはあくまでも参考用です。詳細は実際の状況に応じて適宜調整されます。

ディレクトリについては前回の記事で触れたので、ここでは詳細には触れません。つまり、ディレクトリの価値は、ドキュメントの特定の構造を表示し、検索を容易にすることです。

バージョン情報:

変更履歴:

主にドキュメントの更新ログを表示します。一般的には、要件レビュー後に補足する必要のある内容や確認する必要のある情報などです。会議後に元のドキュメントを更新し、後で紛争が発生しないように記録を残す必要があります。更新・補足された内容は末尾にタイトルが付けられ、異なる色やフォントで区別されるか、引用されます。つまり、前のコンテンツと区別し、素早く位置を特定できるようにするためです。

会議メモ:

一般的に、PRD レビュー中に、解決すべき主な対立と問題を記録し、会議後に ToDo リストを作成し、個人に責任を割り当て、具体的な目標と時間を定量化する必要があります。議事録のテンプレートは、インターネット上のオンラインドキュメントツールで見つけることができます。以下に参考用の簡単なテンプレートを示します。

現在のバージョンの要件に関連する利害関係者を表示します。関係者を素早く見つけ、需要スケジュールを確認することが目的です。需要スケジュールは、需要ガントチャートに置き換えることもできます。下図は、関係担当者と需要スケジュールの記録フォームです。一般的には、需要検討後、設計、フロントエンド、バックエンドテストなどの関係担当者の具体的なスケジュールがフォローアップされます。すぐにスケジュールを公開できない場合は、スケジュール時間を確認し、後ほどフォローアップします。

用語集:

この文書で使用されている専門用語の定義と略語の正式名称と説明を一覧します。特に、プロジェクトが新規開発であり、新しい定義が多数ある場合は、概念を具体的に示す必要があります。

需要背景：

背景については前回の記事で詳しく紹介したので、ここでは詳しくは説明しません。つまり、現在のニーズがどのような状況で、何をする必要があるのかを簡潔に示すことがコアコンテンツです。

参考文献/関連文書:

このドキュメントへのすべての参照を一覧表示します。この文書で参照されている他の文書も同様です。たとえば、複数の関係者が接続する必要があり、他の同僚のニーズが関係している場合は、相手方のドキュメントを参照する必要があります。例えば：

a.この文書がXXXXプラットフォームのXXXX要件を参照している場合は、[参照文書：「文書名：XXXXXXXXXXXXXX」関係者：XXX]と引用する必要があります。

b.このドキュメントには、対応するユーザー側の要件があります。 1 つの製品または 1 つの技術の波に責任がない場合でも、引用される必要があります。【参照文書：利用者側関連要件：「文書名 XXXXXXXXXXXXXXXXXX」関係担当者：XXX】

ユーザー調査:

ユーザー調査では、主に調査方法、サンプル状況、主要な結論について簡単に説明します。要件にユーザー調査が含まれる場合は、詳細なデータ分析レポートを再度添付し、最終的な関連文書 [付録] に追加する必要があります。（PRD ドキュメントではユーザーリサーチは必須ではないため、ない場合は含める必要はありません）

競合製品分析:

競合製品分析では、主に競合製品の比較に関する主な情報と重要な結論をリストします。要件が複雑で、関連する競合製品の比較が必要な場合は、詳細な競合製品分析レポートをここに添付し、最後の関連文書 [付録] に追加する必要があります。

（競合製品分析はPRD文書では必須ではないので、ない場合は記載する必要はありません）

ターゲット：

このドキュメントの全体的な目的と暫定的な目標について簡単に説明してください。全体的な目標は一般的な用語で説明でき、段階的な目標を定量化する必要があります（タスク、時間、優先度などを決定します）。たとえば、ユーザー側の新しいジョブ要件の場合を考えてみましょう。

インパクト：

他の既存の機能モジュール、ユーザー、関連部門、および関連システムに対するこの要件の調整または追加の影響を簡単に説明します。

製品/データステータス：

主に目標に焦点を当てて、現在の製品ステータスとデータステータスを簡単に説明します。

関数エントリ：

関数のエントランスはc末製品に偏っており、中央とバックエンドには比較的少数があります。特に、c末端に複数の入り口がある関数ポイントがあります。入り口の詳細は個別に説明する必要があります（必要に応じて、既存の製品関数のスクリーンショットを使用して、その特定の場所でマークと説明し、追加します）。

？例えば：

1。以下は、その関数の入り口を整理するための例として採用されたC末アクティビティです。

2。図の参照：次の図は[コースノート関数]を例として採用し、既存の製品関数スクリーンショット +アノテーションの形で説明します。

全体的なプロセス/論理関係：

この要件文書で説明されている製品またはコンポーネントの全体的なフローチャートまたは論理関係図について簡単に説明します。フローチャート、マインドマップ、状態図、またはビジネスフロー図で表すことができます。これは、全体的な要件のフローチャートであることに注意してください。複数のサブプロセスがある場合は、関連するサブプロセスに対応するサブプロセスのフローチャートを表示する必要があります。例えば：

以下は、購入コースノートのフローチャートです

この写真は、購入コースのメモのビジネスフローを示しています

ページインタラクション図：

ページフローは一般に、特別な説明を必要とするユーザー側の要件であり、ページ間のフロー関係と論理的な関係を明確に説明する必要があります。例えば：

コース紹介活動ページのインタラクティブな図

機能の詳細：

関数の詳細ディスプレイの詳細、相互作用、判断ロジック、インターフェイスロジック、および必要な関数ポイントに従って関数のその他の詳細を1つずつ説明します。

c在庫ユーザーページ（APP、MINIプログラム、H5）の場合、各関数の詳細な説明は、機能ロジックの特定のページに上から下、左から右に表示されます。

中間またはバックエンドページの場合は、各セグメント化された機能ポイントに基づいて要件の詳細を整理します。

要するに、複雑な要件は複数のサブレキアメントに細分され、各サブレキアメントの機能の詳細な説明が個別に与えられます。

？例：以下は、コース紹介アクティビティのC末ページとバックエンドページの例です。

ページ要素（注文：上から下、左から右）

次の図は、アクティビティバックグラウンド管理ページです。

ページ要素（注文：上から下、左から右）

次の図は、アクティビティデータページの説明を示しています。

注：複数の機能要件がある場合は、複数のディレクトリを表示する必要があります。ドキュメントの読書体験を改善するために、ディレクトリの階層的な関係に注意してください。（上記のドキュメント形式の仕様の階層仕様）

たとえば、特定の[アクティビティ要件]のディレクトリ階層のスクリーンショットを次に示します。

非機能的要件は、製品マーケティング要件、運用要件、財務要件、法的要件、使用支援、問題のフィードバックなど、技術開発を除き、この要件に関連する他の要件を参照してください。

たとえば、紹介キャンペーンを今すぐ保持したい場合は、アクティビティページ、関連するプロセスインタラクションなどが開発する必要がある開発要件です。開発に加えて。

アクティビティ調査、ユーザー調査、データ調査など。アクティビティの初期段階で[初期段階の研究ニーズ]に属します。
イベントがオンラインになる前の運用およびプロモーションコピーライティング、プロモーション資料、アウトリーチ戦略は[イベント前のプロモーションのニーズ]に属します。
イベントに関連する賞品の選択と購入は、 [購入要件]に属します。
購入中の資金の承認など[財務ニーズ]に属する。
それが比較的大きなイベントである場合、サードパーティの公証機関は、[法務/市場の需要]に属する公証化を行う必要があります。
アクティビティが開始された後、 [宣伝/トレーニングのニーズ]に属するビジネス側にトレーニングとプロモーションを提供するために、関連する製品運用が必要です。
アクティビティ、アクティビティレビューなどの起動と終了後のデータ追跡はすべて[データのニーズとレビューのニーズ]と見なされます。

アクティビティ計画から始めて、アクティビティを担当する人は、対応するノードのスケジュールを計画し、対応するパートナーにキータイムノードとキートゥドゥーを認識させる必要があります。個人に責任を割り当てることが最善です。非自信のデータと計画の場合、グループコンテンツを同期して、誰もがどのノードで完了する必要があるかを明確に知っているようにすることが最善です。

関連する追跡ドキュメントとデータ要件を表示する必要があります（これは、Cエンドのニーズに必要です）。

一般的に、企業はドキュメントを追跡するための標準的な追跡仕様を持っています。統一された要件に応じて、データ追跡テーブルに入力できます。ただし、執筆後に追跡要件が合理的であるかどうかを、対応する技術パートナーに確認することを強くお勧めします（PRDレビュー中に一緒にレビューできます）。さらに、データ収集の精度を確保するために、テストフェーズ中の追跡ポイントを測定することを忘れないでください。

一般に、Visual Data Dashboardがない場合は、この需要のデータ要件を個別に整理し、技術的な同僚に個別に処理するのに役立つように依頼する必要があります。データ要件は、ヘッダーフィールド、フィールド定義、および必要な更新時間を明確に述べる必要があります。

？例：紹介活動のデータ要件を例として取ります。

ここでは、ここでデータ要件、運用要件、調達要件など、ここに関連する以前のアクティビティ要件に関連するプロジェクト管理ドキュメントをこちらのメインテキストに添付します。これらは、ここに置いて、関連する責任者に@Edを配置できます。

起動の説明文書は、比較的複雑な要件、特に複雑なロジックを持つもの、または複数のプラットフォームまたは複数のポートの使用を含む要件が起動した後、関連する利害関係者に電子メールまたはグループの発表によって通知する必要があることを示しています。

オンラインの完全な要件[Operation Instruction Document]を出力します。これは、オンラインの機能ポイント、操作命令、および影響の範囲を説明しています。必要に応じて、操作ビデオを録画すると、ビデオに音声解説を伴う必要があります）、電子メールの添付ファイルとして関連する利害関係者に送信する必要があります。

たとえば、起動ドキュメントのディレクトリのスクリーンショットを次に示します。

起動通知の電子メール/グループ広告通知のテンプレートは次のとおりです（参照のみ）

今日のコンテンツがあなたに役立つことを願っています〜

この記事は、もともと @产品陀螺がプロダクトマネージャーである @产品陀螺によって公開されました。著者の許可なく複製することは禁止します。

タイトル画像は、CC0 プロトコルに基づいて Unsplash から取得したものです。

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。

<<: 製品操作技術（製品10ステップ方式）

>>: 製品運用入門（製品運用を始めるための必読）