objectivize — 私稿を公開稿に変換する

あなたが実行しているのは、単なる禁止語句の置き換えではありません。文書ごとに「主観が漏れる」形は異なります。まず、その文書独自の主観的漏れ方を感知し、それに合わせた修正手法を選びます——形随功能（form follows function）。

以下のカテゴリはヒントであり、チェックリストではありません：足りなければ新たに命名し、多すぎればその場で削ってください。この説明自体も水のように捉え、テンプレートとして読まないでください。

一、まず感知し、それから手を動かす（省略不可）

一度通読し、次の三つの問いに答えてください：この文書は誰に向けて書かれ、誰の立場で書かれ、どのような「部外者には通じない」表現が含まれているか？漏れの箇所を自分の言葉で分類してください。よくある例：

成果物は、その文書専用の漏れ地図であり、汎用ルールではありません。次の文書では新たに描き直してください。

客観化で最もよくある間違いは、証拠まで消してしまうこと、あるいは実際のデータを改ざんすることです——それは客観ではなく、歪曲や捏造です。判断基準は一つだけ：それは観察された事実か、それとも書き手の口調か？事実は残し、口調は変える。

直接引用 = 証拠、保持する（中立的な帰属に変更してもよい）。回答者が「絶対にソフトには手を出さない」と言ったのなら、そのまま残します。それは主張を支える材料です。
一人称の言い換え = 漏れ、書き換える。「夢みたいなことはやめてくれ」は他人の声を代弁している → 「提案には根拠が必要」と書き換える。
実際のデータは絶対に変更しない——ユーザーコメント、ログ、統計、スクリーンショットの原文。たとえデータの中にたまたま削除したい単語が現れても、決して変えてはいけません：変えることは証拠の改ざんです。（実際の教訓：あるユーザーの悪評に「上司」と書いてあれば、そのまま残さなければなりません。）

枠組みを変え、内容は失わない。「上司の真意」→「プロジェクトの意図」：立場は消え、情報は残る。一行まるごと消したくなったら、まず「この行が伝えている判断／事実は何か」を問い、その部分を中立的な言い方で残します。

まず対外視点を選びます（この報告書は誰のふりをして、誰に向けて書くのか？）。それに基づき、各内部関係者に中立的な呼称を決め、文書全体で統一します。

同じ人を指すのに三つの異なる言葉（プロジェクトチーム／要求元／意思決定者）を同じ文書で使ってはいけません。読者は三者のように感じます。順序は：まず呼称を決める → 次に置換をかける → 最後に一貫性を確認する。
章の「内省的な骨格」も置き換える：「彼が言ったこと／言わなかったこと／なぜそう言ったか」といった「誰かを振り返る」タイトルを、「客観分析」タイプ（確定した意思決定／盲点と未解決／深層動機と制約）に変更します。構造を分析対象に合わせ、その会議の構造には合わせないでください。

主観を排除することは、「確信度／限界／疑問点／推測の層／実測による検証の必要性」まで平らにすることではありません。これらの正直な注釈こそが客観性の証であり、残してください。

用語統一はスクリプト化可能だが、辞書は毎回新規に作成する——まずそのバッチの呼称セットを感知し、それからそのバッチ用の置換を作成します。前のプロジェクトの表を再利用してはいけません。
機械的置換の後は必ず副作用を確認する——長い語を短い語より先に置換しないと、「すでに～された」のような変な語が生成されます。また、grepで残存や異常を確認します。
枠組み、語調、二人称などは手作業で一文ずつしか処理できない——スクリプトでは対応できません。
下流の成果物は再生成する——ソースを変更したら、レンダリングされたHTML/PDF/目次/表紙も再生成する必要があります。ソースだけを変更してはいけません。

一つでも不合格なら、最初のステップに戻ってください——ただし、文書ごとに合格の仕方は異なります。このチェックリスト自体を新たなテンプレートにしてはいけません。