プロジェクト管理をしていると「最新版はどれ？」と電話が入る。
仕様書は整っているのに、合意が薄い。これが一番悩ましいですね。
そこで今回は、「合意が残らない」構造的な理由を整理し、なぜWord/Excel中心の運用を捨てて「構造化されたテキスト」に戻るべきなのかを掘り下げます。
合意が崩れる典型パターン
私たちの現場でよく起きるのは、次のような流れです。
・会議で出た論点が、議事録や資料に「散在」する（決定/未決/次アクションが混在）
・更新のたびに誰がどこを直したかが追えず、合意の履歴がぼやけていく
・結果として「前回は何が決まったのか」が不明確になり、同じ議論が再発する
・上書きと複製が増え、v2_final_修正.xlsx のように最新版の判定が崩れる
・最終的に、合意事項は「存在するのに探せない」状態になり、管理不能になる
ここで起きているのは、合意の“錯覚” です。
「資料がある＝合意がある」と見えてしまう。でも実際は、誰も読み返せない形式で埋もれている状況になりやすいです。
ツールの限界は、保存形式と運用設計にある
WordやExcelは「見せる」ためには便利です。問題は、中身が差分管理できない形式で保存されることです。
その瞬間、履歴が止まり、合意の変遷が追えなくなる。
私は過去に、Excel方眼紙のファイル修正だけで週末が消えたことがあります（正直、心が折れました）。
ただ、それ以上に困ったのは「誰が、いつ、何を変えたのか」が追えないことでした。
見た目が整っていても、合意の履歴が残らないなら意味がないんです。
一次ソースが残らないと、合意は再現できない
議事録が「書いて終わり」になると、決定事項が蒸し返されます。
音声も残っていない。あるいは残っていても、探し出すのに30分かかる。
つまり、合意の再現性がない。
合意とは「その場の空気」ではなく、一次ソースとして残る構造で担保されるべきです。
ここで重要なのは、「一次ソースがテキストとして残っているか」 という土台です。
テキストなら差分が追え、履歴が残り、合意の変遷を検証できます。
その延長線上で、AIが初めて有効に働く。バイナリの中身は安定して読めませんが、Markdownならそのまま理解できる。
だからこそ、まずは「構造化されたテキスト」に戻る必要があると思います。
リッチなドキュメントを捨てる理由
見栄えの良い資料は、プロジェクトを前に進めるときに便利です。
ただし「合意事項を管理する」という目的には向いていません。
・差分が取れない
・検索できない
・SCMで変更履歴が追えない
・決定事項/未決事項/次アクションが混ざる
結果として、PMは判断の時間より「整形と管理」に追われる。
これが「判断リソースの枯渇」です。
まとめ：合意は“中身が読める形”で残す
合意形成の再現性は、一次ソースの即時化とテキスト化から始まります。
私たちが捨てるべきなのは、豪華な資料ではなく「差分が追えない形式」です。
次回は、第2回「ドキュメントからコードへ」。
なぜPMがVS Codeを開くべきなのか、Docs as Codeの話に進みます。