仕様を残しても、判断は引き継げない

仕様書を読み返していて、手が止まることがあります。何を決めたかは書いてある。項目の定義も、処理の流れも、現在の正解も残っている。それなのに、なぜその形を選んだのかが分からない。別の案はなかったのか。どんな制約があったのか。記憶をたどっても、もう曖昧です。

以前から、判断の背景を残すことは大事だと思っていました。ただ、運用できているうちは、その重要性を切実には捉えきれていませんでした。AIと仕事をし、仕様を参照させるようになって、この問題がはっきりと顕在化しました。

AIに変更案を出させたとき、すでに検討して見送った案が最善策として返ってきたことがあります。仕様には、その案を見送った理由が残っていなかったからです。答えだけを渡しても、AIは背景まで理解できません。そして、それは人への引き継ぎでも同じでした。

仕様は残っているのに、判断だけが消えていた

仕様書には、現在どう動くべきかが書かれています。

この項目には何を入れるのか。どの条件で処理が分かれるのか。誰がどこまで操作できるのか。実務を進めるためには、曖昧さのない答えが必要です。その意味で、仕様書は正典であるべきです。読むたびに結論が変わる文書では、運用できません。

一方で、正典として整えるほど、そこから落ちていくものがあります。

当初は別の案も検討していたこと。理想形ではなく、当時の制約を優先したこと。将来ある条件が変わったら見直すつもりだったこと。意見が割れた末に、まずは小さい範囲で試すと決めたこと。

最終的な仕様だけを見れば、これらはノイズに見えます。実務で参照する文書を簡潔に保つなら、検討過程をすべて残さない判断にも合理性があります。

しかし、時間がたって前提が変わったとき、このノイズだった情報が必要になります。

なぜ、この制約があるのか。今も守る必要があるのか。別の案へ切り替えてはいけないのか。背景がなければ、過去の仕様をそのまま守るか、根拠が分からないまま壊すかの二択になります。

仕様は引き継げても、判断できる状態は引き継げていなかったのです。

AIは、書かれていない背景を補えない

判断の背景を残す重要性は以前から感じていましたが、その不足が実務上の問題としてはっきり見えるようになったのは、AIにドキュメントを参照させるようになってからです。

AIは、書かれている情報を使うことには長けています。仕様が明確なら、その内容を整理し、矛盾を探し、関連する案を出せます。複数の文書を横断して、人が見落としていた接点を見つけることもあります。

ただし、書かれていない判断背景を、確かな前提として扱うことはできません。

ある仕様を現在の正解として渡せば、AIはそれを前提に考えます。その仕様が一時的な制約の産物だったのか、何度も検討した末の原則だったのかは区別できません。採用しなかった案と、その理由が残っていなければ、過去と同じ案を新しい提案として返すこともあります。

ここで足りないのは、情報量ではありません。

会議の全文やチャットログをすべて残しても、AIが必要な背景にすぐたどり着けるとは限りません。発言の断片は増えても、何が決定で、何が保留で、何を条件に見直すのかが分かれていなければ、文脈は埋もれます。

コンテキストマネジメントは、ログを大量に保存することではない。以前から抱いていたこの考えは、AIとの仕事を通じて、より明確になりました。ここからは、その考えを仕様書と検討ログに落とす型を示します。

必要なのは、現在の答えと、その答えに至った理由を、別の役割として残すことです。

仕様書と検討ログは、役割を分けて持つ

現在、私は仕様書と検討ログを同じ文書に詰め込まないようにしています。

仕様書に置くのは、今の運用で参照すべき答えです。定義、ルール、処理、責任範囲など、読み手が迷わず動くための情報を置きます。更新されたら、古い答えを残して読解を難しくするのではなく、現時点の正解が分かる状態を保ちます。そのうえで、仕様書には最新の検討ログへのリンクと適用日だけを残し、現在の答えがどの判断に基づくかを追えるようにします。

検討ログに置くのは、答えが生まれた背景です。

• 何を決める必要があったのか

• どの選択肢を比較したのか

• 何を優先して現在の案を選んだのか

• 何が未決のまま残っているのか

• どの前提が変わったら見直すのか

この二つを分けると、文書は増えます。管理の手間もゼロではありません。それでも、一つの文書にすべてを詰めるより、参照する目的が明確になります。

今日の業務を進める人は仕様書を見る。過去の判断を検証する人や、AIに変更案を考えさせたい人は検討ログも見る。未決事項だけを確認したいときは、保留中の論点へ移動する。

重要なのは、会議をすべて記録することではありません。判断の節目で、背景を短く構造化して残すことです。

議事録は、その場で何が話されたかを残します。判断履歴は、その後に何を再利用したいかを残します。似ているようで、目的が違います。

ここで残したいのは、うまくいった手順を再現するための記録ではありません。前提が変わったときに、その決定をやめる、あるいは作り変えると判断するための記録です。

背景を残すと、過去の決定を覆しやすくなる

決定背景を残すことには、過去の判断を正当化する印象があります。

これだけ検討して決めたのだから変えてはいけない。以前の担当者の意図を尊重しなければならない。履歴が詳しいほど、かえって変更しにくくなることもありそうです。

けれど、実際には逆でした。

背景が分からない決定ほど、触るのが怖くなります。どこまで影響が広がるのか、何を壊すのか、なぜこの形なのかが分からないからです。根拠不明の仕様は、正しいから残るのではなく、怖いから残り続けます。

決定背景があれば、当時の前提と今の前提を比べられます。

当時は人数が少なかった。今は役割が分かれている。当時はデータが取れなかった。今は取得できる。当時は速度を優先した。今は再現性のほうが重要になった。違いが分かれば、過去の判断に敬意を払いながら、今の条件で更新できます。

AIにとっても同じです。なぜその決定だったのかが残っていれば、単に仕様を要約するだけでなく、前提の変化を踏まえた代替案を考えやすくなります。人が最終判断を担うことは変わりませんが、議論の出発点は深くなります。

記録の目的は、過去の答えを固定することではありません。
あとから安全に覆せるようにすることです。

私は、仕様だけを書いて終わらせないようにしています。現在の答えと、その答えが成立する条件を分けて残す。未来の誰かが同じ結論を選ぶためではなく、その時点の条件で、もう一度判断できるようにするためです。

#BizOps #コンテキストマネジメント #ドキュメント管理 #ナレッジマネジメント #AI活用 #意思決定

暗黙知が消える組織には、足りない問いがある
本稿が、決まった後の背景をどう残すかを扱うのに対し、こちらは、その背景を人の経験からどう引き出すかを掘り下げています。判断履歴に何を書くべきか迷うとき、出発点になるのは記録の型よりも問いの型です。迷った場面、比較した選択肢、最後の決め手を聞くことで、本人にも見えていなかった判断の構造が言葉になります。記録の前段まで含めて考えるための一本です。

組織が賢くならないのは、AIのせいではない
個人がAIを使いこなしても、その試行錯誤や失敗理由が共有されなければ、組織の記憶にはなりません。こちらの記事は、問い・失敗・引き継ぎの単位を設計することで、AI活用を個人の生産性から組織の学習へ変える視点を示しています。本稿の仕様書と検討ログという実務の型を、組織全体の学習設計へ広げて捉えたいときに、思考を一段深めてくれます。

今のモノサシで過去を裁くな。批判家ではなく「建築家」であれ
判断背景を残す理由は、昔の決定を守り続けるためではありません。当時の制約と意図を理解したうえで、今の条件に合わせて安全に作り変えるためです。こちらの記事は、過去のオペレーションを断罪せず、意図を引き継ぎながら手法を更新する建築家の姿勢を描いています。本稿の結論である、過去の答えを固定せず、あとから覆せるようにするという考えの思想的な土台になる一本です。