意思決定をログに残す、それだけで組織は変わる——システム化までの道筋

エンジニアとして、ログの価値を語るとき、いつも「再現性」の話をする。

だが、意思決定においても、ログは同じように機能する。

意思決定の3パターン

次の3つの文を見てほしい。

「〜っていうことがあったから〜というふうに決めた。」

これは イベント × 意思決定 だ。何かが起きたから判断した、という構造。

「前に〜っていうことがあったから、今回は〜って決めた。」

これは 意思決定ログ × 意思決定 だ。過去の判断が、今の判断の根拠になっている。

「〜っていう事実があるから、今回は〜って決める。」

これは 事実 × 意思決定 だ。データや状況を根拠に判断している。

整理すると、意思決定に求められるものの優先順位が見えてくる。

記録のない決断は、未来への負債になる。
1分のメモが、数ヶ月後のチームの何十時間を救う。

AIは成果物を残す。GitHubにエンジニアが出したコードを組織の上層部が見ても、それ自体がいいものかどうか判断できない。コミットやソースコード履歴には価値があるが、「なぜこう作ったか」の評価はできない。

だからADR（Architecture Decision Record）が生まれた。設計思想を残すこと。

エンジニア以外の世界、たとえば経営者も同じだ。経営者は生きてきた人生の中で判断軸をどこに置いているのか、なぜその決定をしたのか——そこには意思がある。その意思を記録しなければ、毎回話すことになる。経営者に時間的なロスが生まれ続ける。

意思決定ログは、組織に「記憶」を持たせることだ。

Github IssueやJiraなどのツールで意思決定ログを残す方法もある。
しかしそれらはすぐに限界を感じることになる。理由は次の3つ。

完璧なツールを求めると、誰も書かなくなる。

私がいいなと思ったのはSlackだった。すでに使っている特定のコミュニケーションツールの中に、意思決定ログを組み込む。摩擦をゼロに近づけることが、継続の鍵だと気づいたからだ。

実際に運用しているテンプレートはシンプルにした。

ルールは一つだけ。書かないよりは、雑でも書く。

「とりあえずA案にした、理由は時間不足」この一行でもいい。完璧を求めない姿勢が大事だ。

実際に経験した。会社判断と事業部判断でズレが生じ、インシデントが起きることもある。
30人程度の組織でそれが起きることもある。組織は拡張するにつれて、それはもっと深刻化する。

これは個人の問題ではない。「決まっていなかった」ことの問題だ。

上場企業になれば、意思決定の承認フローはさらに長くなる。承認者が増える。ただ、承認者が「何を見ているか」の基準は多くの場合、暗黙知のままだ。言語化されていない。

その暗黙知を言語化することで、AIで思考の代替ができる。承認基準をシステムが学べるようになる。

意思決定ログをさらに進化させるために、次のシステム構想を持っている。

Slack（意思決定の議論）
→ AI抽出（何が決まったか、なぜか）
→ Decision Log DB
→ プロジェクト管理シートからの参照

スタックのイメージ：S3 + Athena（SQL検索）+ MCP連携。

ポイントはAIによる自動抽出だ。Slackのスレッドをトリガーに、AIがコンテキスト・選択肢・決定理由を抽出してDBに書き込む。人間がフォームに入力する負荷をゼロに近づける。

プロジェクト管理シートのマイルストーン列に dl-001 のようなIDを紐付ければ、「その決定に至った経緯」へジャンプできる。意思決定が、プロジェクトの流れと接続される。

AIが日常業務に入り込んでくる今、意思決定の文脈を蓄積することの価値はさらに上がる。

過去の判断から類似ケースを検索できる。判断の一貫性をチェックできる。「なぜその選択をしたか」を組織として問い直せる。

そして何より、ログがあれば、次の世代に意思決定の哲学を渡せる。

口で言うのは簡単だ。だからこそ、残す。

意思決定をシステムに落とすことは、組織の意思を未来へ渡すことだ。