公式情報源に基づく製品更新ログの管理方法

更新ログは、以前 → 現在 → 証拠 というシンプルなスキーマに基づいて構築されます。これにより、製品の実際の変更と、アナウンス、要約、または独自の解釈を区別することができます。

以前の状態と新しい状態を特定し、対象者を明記し、公式の情報源を添付できる場合にのみ、ログエントリを作成します。要素のいずれかが欠けている場合は、推測で空白を埋めるのではなく、エントリのステータスを「要確認」としてください。

責任に応じて情報源を固定する

各製品について、公式ページとチャネルの簡易マップを作成してください。異なるタイプの変更は、通常、異なる場所で確認されます。

• リリースと機能 — 更新セクション、リリースノート、ドキュメント、公式ブログ、またはチームのチャネル。
• 価格と制限 — 料金プランページ。支払いの詳細が重要な場合は、関連する利用規約も参照してください。
• 利用規則とデータ処理 — 利用規約、プライバシーポリシー、特定の機能に関する個別の規則。
• 障害と可用性 — ステータスページ、インシデントに関する公式発表、およびその後の補足説明。

公式チャネルは迅速にニュースを伝えることができますが、常にすべての制限事項を含んでいるわけではありません。投稿で「新機能が利用可能」と述べられていても、ドキュメントで地域、プラン、または有効化の手順が詳細に説明されている場合、主要な証拠は条件を記載した文書となります。投稿は追加のリンクとして保存できます。

「以前 → 現在 → 証拠」のスキーマに従って記録する

1つのログエントリは1つの変更を記述します。後で検証できるように、以下のフィールドを追加してください。

次のテンプレートを使用してください：

• 検出日: [DD.MM.YYYY]
• 確認日: [DD.MM.YYYY]
• 発効日: [DD.MM.YYYY または「未指定」]
• 以前: [公式情報源に基づく以前の状態]
• 現在: [公式情報源に基づく新しい状態]
• 対象ユーザー: [料金プラン / 地域 / アカウントタイプ / 「未指定」]
• 条件と制限: [条件、制限、例外 / 「未指定」]
• 変更ステータス: [アナウンス済み / 導入中 / 有効 / 取り消し]
• アクション: [確認または変更が必要な事項]
• 証拠: 「[正確な引用]」；[ページのスクリーンショット: 日付、URL]
• 原文: [公式情報源のURL]
• エントリステータス: [確認済み / 要確認 / 補足により置換]

変更ステータスは、変更自体がどの段階にあるかを示します。エントリステータスは、現在の記述を信頼するのに十分な根拠があるかどうかを示します。例えば、公式情報源が将来の条件を直接記述している場合、変更は「アナウンス済み」でも、エントリは「確認済み」となります。あるいは、変更が「有効」であっても、どのユーザーに影響するかが不明な場合は、エントリは「要確認」となります。

事実と結論を区別する

重要なエントリには3つの層があります：

1. 確認済みの事実 — 原文で直接述べられていること。
2. 作業上の結論 — あなたにとってそれが何を意味するか。
3. 未解決の質問 — 情報源が説明していないこと。

例えば、公式テキストが新しい設定について報告しているとします。事実：「設定が追加された」。結論：「現在のワークフローに変更があるか確認する必要がある」。質問：「使用中のプランで利用可能か？」これらの部分を別々に記録し、仮説が確認済みの変更のように見えないようにしてください。

独立したレビュー、コメント、または要約は、どこを見るべきかを示唆することがあります。しかし、それらは価格、条件、可用性、またはインシデントの原因を確認するものではありません。そのような資料はエントリのメモに保存し、「原文」フィールドには公式情報源を残してください。

補足情報が出た後にエントリを更新する

アナウンスは不完全である場合があり、条件は変更される可能性があります。過去の表現を黙って修正しないでください。新しい関連エントリを作成し、そこに新しい確認日と補足情報へのリンクを追加してください。以前のエントリはステータス「補足により置換」で保存してください。変更が取り消された場合は、新しいエントリで変更ステータスを「取り消し」に設定し、取り消しの証拠を保存してください。

これにより、ログには元のバージョンと、それが最新ではなくなった理由が残ります。ログは、現在何が知られており、それがどの情報源に基づいているかという2つの質問に答えます。