Slackで過去の意思決定を見つける方法（検索だけでは足りないとき）
キーワード検索が失敗するとき、Slackで過去の意思決定を見つける方法。意思決定が消える理由、ログが定着しない理由、意思決定対応システムとは何か。
By Ellis Keane · 2026-03-14
ちょっと考えてみてください。チームがポーリングの代わりにウェブフックを使うことに決めたのはどこですか？決定内容ではなく – その意思決定が今現在、来月入社する誰かが見つけられる場所に書き留められているのはどこですか？
もし私たちと同じなら、正直な答えは「おそらくSlackのスレッドのどこか」と「#eng-backendだったと思う、たぶん3週間前で、2〜3人が関わっていたと思うけど、正直誰だったか全然思い出せない」の間のどこかでしょう。これはよく考えると興味深い状況です。なぜなら、その意思決定自体はシステム全体の動作を変えるほど重要だったにもかかわらず、タイムスタンプ順に整理された意識の流れではない場所に書き留めておくほど重要だとは誰も思わなかったようだからです。これが要するに、Slackで過去の意思決定を見つけようとする際の問題です – 情報はすべてそこにあるのですが、意思決定として取り出せる形で整理されていないのです。
しばらくSlackで過去の意思決定を見つける方法を研究していますが、掘り下げれば掘り下げるほど、核心的な問題は規律や習慣、あるいは人々が責める他のものではないと思うようになっています。それはアーキテクチャ的な問題です。Slackの検索はメッセージを見つけるために作られており、意思決定はメッセージではありません – それはメッセージを通じて表現される意味であり、この区別は一見些細に聞こえますが、「ウェブフック」の17回の言及のうちチームが実際にそれを使うことを決めた一つを探して20分間検索結果をスクロールした後には、そうは思えなくなります。
Slackの検索が実際にどう機能するか（そしてどこで失敗するか）
これについては正確に述べておきましょう。「Slack検索はダメだ」というのは正しい診断ではありません – Slack検索はやっていることにはかなり優れています。問題は、それがやっていることと、意思決定を探すときに必要なことが、根本的に異なる2つのことだということです。
Slackはメッセージをテキストとメタデータ（タイムスタンプ、送信者、チャンネル、そして有料プランの場合はスレッドの全文脈）でインデックスします。「ウェブフック」を検索すると、Slackはその単語を含むすべてのメッセージを忠実に返し、最近度と関連性の組み合わせでランク付けします。検索演算子で絞り込むこともできます – in:#eng-backend from:@sarah before:2026-02-15 – ただし行っているのは同じフラットなメッセージリストをメタデータでフィルタリングするだけです。これはキーワード検索であり、うろ覚えの特定のメッセージを見つけるには十分機能します。
しかし意思決定はキーワードではありません。意思決定は、問い、選択肢のセット、関係者、そしてグループが一つの選択肢に収束した瞬間の間の関係です。意思決定の実際のテキストは「うん、ウェブフックにしよう、ポーリングはレート制限を食い潰してる」かもしれません – これは口語的で文脈依存的であり、そのスレッドをすでに知っている場合にのみ意味をなします。あるいは「それでいい、プロトタイプを作ってみる」かもしれず、これはその技術的意思決定に関連するキーワードを一つも含んでいません。
これがアーキテクチャ上のミスマッチです。Slackはメッセージを時系列で保存し、キーワードで取得します。意思決定はセマンティック（意味についてのもの）でリレーショナル（タスク、人、結果に接続している）です。時系列ストレージシステムにセマンティック検索を求めているのですが、それはそのために設計されたことがないので、できません。「検索可能」と「見つけられる」の間のギャップは実は巨大です – Slackの履歴にあるすべてのメッセージは技術的には検索可能ですが、それはあなたが必要な意思決定が実際の意味で見つけられることを意味しません。
「Slackは歴史上最大の組織の意思決定リポジトリの一つを作り上げましたが、そのほとんどは意思決定として取り出すことができません – あらゆる言葉が完璧に保存され、ほぼ完全に見つけられない状態です。」 attribution: Ellis Keane
Slackで過去の意思決定を見つけようとすると何が起こるか
これが実際のミスマッチの様子です。3週間前にチームがGitHubインテグレーションのためにポーリングからウェブフックに切り替えることを決めたとします。#eng-backendでエンジニア数人が議論したことを覚えています。そこで「ウェブフック」をそのチャンネルで検索します。
返ってくるもの：#eng-backendでウェブフックに言及したすべてのメッセージ。6ヶ月前のバグレポート。全く別の文脈でウェブフックの再試行ロジックについて質問している誰か。ウェブフックのベストプラクティスについてのブログ記事へのリンク（皮肉なことに、そのすぐ隣にある実際の意思決定より検索結果で上位にランクされているかもしれません）。意思決定そのもの – ポーリングのアプローチがレート制限に達していると誰かが言ったスレッドへの返信 – は3ページ目のどこかに埋もれており、周囲の他のメッセージと見た目が全く同じです。
これはおおよそどんな言葉が使われたかを覚えているシナリオです。半分の時間、意思決定はとても文脈依存的な言葉を使うため、暗号化されているも同然です。「選択肢Bにしよう」という言葉には「ウェブフック」という単語が全く含まれていませんが、選択肢B が ウェブフックでした。「それでいい、プロトタイプを作ってみる」には「選択肢」という単語さえ含まれていません。意思決定の実際の瞬間は、スレッド全体の中で最も短く、キーワードが最も少ないメッセージであることが多いです。なぜなら、その時点では会話の全員がすでに文脈を持っており、単に合意を確認しているだけだからです。
これは情報アーキテクチャの問題として本当に興味深いと思います（そして、検索している本人になると少しイライラもしますが）。Slackは歴史上最大の組織の意思決定リポジトリの一つを作り上げましたが、そのほとんどは意思決定として取り出すことができません – あらゆる言葉が完璧に保存され、ほぼ完全に見つけられない状態です。
なぜ意思決定ログはより良い案内板のある墓場なのか
解決策を求めると、標準的なアドバイスは意思決定ログを維持することです。Notionデータベース、専用のSlackチャンネル（これを推奨する人たちにはそのアイロニーが見えていないようです）、ウィキページ – 意思決定が起こったときに記録される単一の場所。
私たちはこれを試しました。約6週間持続しました。最初の2週間は素晴らしく、全員が取り組み、エントリーは詳細で、ログは本当に役立ちました。3週目には、エントリーが散発的になり始めました。5週目には、一人だけがまだ更新していましたが、「認証について何かを決めた」というような、リンクも文脈もなく、誰が関わったか何が代替案だったかも示されていないものを書いていました。6週目に私たちは静かにふりをやめました。
問題はチームに規律が欠けていることではありません（まあ、そうかもしれませんが、ここでは関係のある問題ではありません）。問題は意思決定ログが最悪のタイミングで負担を課すことです。生産的な議論をして、合意に達して、誰かが作り始める準備ができている – そのときに、別のツールを開いて、要約を書いて、関係者にタグを付けて、元の会話にリンクを貼る必要があります。これは意思決定ごとに3〜5分かかり、チャンネルやスレッドにわたって1日に5〜10の重要な意思決定をするチームにとって、オーバーヘッドは誰も所有したくないほど積み上がります。
そしてシステムは100%のコンプライアンスがあって初めて機能します。意思決定の70%しかカバーしていないログは、場合によってはログがないよりも悪いです。なぜなら、今や2つの場所を確認して、どちらも信頼できないからです。ログを確認し、意思決定が見つからず、結局Slackで検索する – そして最初の場所に戻ってきます。ただ、最初にログを確認して2分無駄にしたことを除いて。
意思決定はイベントではなく – グラデーションです
手動ロギングが失敗する理由の一つは、意思決定が離散的で識別可能な瞬間であると仮定していることです。実際には、ほとんどの意思決定は会話を通じて徐々に現れ、「意思決定の瞬間」は本当に曖昧なことが多いです。
典型的なエンジニアリングの意思決定がどのように展開するかを考えてみましょう。誰かがFigmaのコメントで懸念を提起します：「このインタラクションパターンはモバイルでは機能しないかもしれない。」エンジニアが元のコメントにタグ付けしてSlackスレッドで返信します：「うん、調べた – コンポーネントライブラリはそれをサポートしていない。」デザイナーが同じスレッドで別のアプローチを提案します。エンジニアが「それでいい、プロトタイプを作ってみる」と言います。2日後、代替案を実装したPRが上がり、Linearの課題が更新されます。
意思決定はどこで行われましたか？問題を表面化させたFigmaのコメントでしたか？代替案が提案されたSlackスレッドでしたか？エンジニアが「それでいい」と言った瞬間でしたか？実装したPRでしたか？実際には、意思決定はその4つの瞬間すべてにわたって分散しており、2つのツールと3日間にまたがっていました。それはログに記録できるイベントではありませんでした – コードが変わったという理由だけで意思決定が行われたことがわかる、結果に解決したグラデーションでした。
これが（私が思うに）ほとんどの「意思決定トラッキング」アドバイスが間違えている部分です。意思決定を電話番号を書き留めるように、キャプチャするものとして扱います。しかし実際の意思決定のほとんどは再構築するものです – 何が変わったかを確認し、そこに至った会話を遡り、事後に推論をつなぎ合わせます。つまり必要なシステムはログではありません。グラフです。
グラフがログに対してできること
グラフはツールと時間をまたいでシグナルを接続します。誰かが手動で「レート制限のためウェブフックを使うことにした」と書く代わりに、グラフはレート制限が議論されたSlackスレッド、インテグレーション作業を追跡したLinearの課題、ウェブフックを実装したPR、そして会話に関わった人々をリンクします。意思決定は記録されるのではなく – すでに起きていたことの間の接続から再構築可能になります。
実際の違いは特定のシナリオで現れます。ウェブフックの意思決定の3週間後、新しいエンジニアが入社して尋ねます：「GitHubにポーリングではなくウェブフックを使っているのはなぜですか？ポーリングの方がシンプルに見えますが。」接続されたシステムがなければ、誰かが「ああ、以前に決めたんだよ」と言い、誰もどのチャンネルか覚えておらず、誰かが15分間Slackを検索し、見つけるか（より可能性が高いのは）記憶から推論を再構築します。これは危険です。記憶は信頼できず、元の推論はほぼ確実に誰かが3週間後に覚えているものよりもニュアンスが豊かだったからです。
グラフがあれば、エンジニアはGitHubインテグレーションのタスクを見ます。そのタスクに触れたすべてのシグナルがリンクされています：レート制限についての元の議論、ポーリング対ウェブフックが評価されたスレッド、変更を実装したPR。何も検索することなく、何もログに記録することなく、端から端まで完全な意思決定の軌跡。
ギャップは「良い検索」と「悪い検索」の間ではありません – キーワードによる取得と関係による取得の間にあります。意思決定はそれを表現するために使われた言葉によってではなく、タスク、人、結果への接続によって定義されます。
どのダッシュボードにも表示されないコスト
このようなソフトコストに対して正確な数字を主張する人には率直に懐疑的です（「チームは週にX時間を無駄にする」というジャンルの統計は、常に望ましい結論から逆算されたように感じます）。しかし、私たち自身のチームで観察したことを共有します。
最も明らかなコストは再検討です – 誰も元の意思決定を見つけられないとき、チームは単純にそれを再び開きます。時には人々が本当に覚えていないから、時には新しいチームメンバーが具体的な答えを誰も出せない正当な質問を持っているからです。決定を遡る方法が得られる前、私たちは定期的に解決済みの問題を再検討していました。そして各再検討には独自のオーバーヘッドがあります：会議の時間、すでに解決されたと思っていることを議論する感情的な疲労、元の推論が誰かの記憶より微妙だったのではないかというぬぐい切れない疑惑。
より微妙なコストはオンボーディング中に起こることです。新しいチームメンバーからの「なぜこのようになっているのですか？」という質問は毎回、元の意思決定に居合わせた誰かを邪魔し、答えは誰かが尋ねるたびに記憶から再構築され、語り継がれるたびに元の推論から少しずつずれていきます – 伝言ゲームのようなものですが、電話はエンタープライズソフトウェアで、メッセージは「なぜアーキテクチャはこのように機能するのか」です。そして時間とともに積み重なる信頼性のギャップがあります：「ウェブフックを使うことにした」は「ポーリングがGitHub APIレート制限の40%を消費していて、ピーク時間帯にスロットリングに達していたのでウェブフックを使うことにした」ほどの重みがありません。推論こそが将来のエンジニアが環境の変化の下で意思決定がまだ有効かどうかを評価できるものであり、その推論はSlackのスレッドのどこかに、完璧に保存され、実際にはほとんど見つけられない状態で存在しています。
Slackのスクロールで意思決定を失うのを止めましょう。SugarbugはSlackスレッドからLinearの課題、PRまで、完全な意思決定の軌跡を自動的に追跡します。
Q: Slackで過去の意思決定を見つけるのが難しいのはなぜですか？ A: Slackはメッセージを意味ではなく時系列で保存します。スレッドに埋もれた意思決定は他の返信と見た目が同じです – Slackの検索はキーワードにマッチできますが、「Redisを使うことにした」と「Redisを使うべきか？」を全会話の文脈を読まずに区別することはできません。時間が経つほど難しくなります。なぜなら、検索を有効にしていた文脈上の手がかり（誰が関わっていたか、どのチャンネル、どの週）を失うからです。
Q: SugarbugはSlackで行われた意思決定を自動的に追跡しますか？ A: はい。Sugarbugはタスクを参照し、担当者が関与し、ステータス変更やPRをもたらすスレッドなど、意思決定のようなパターンを特定しながら、Slackや他の接続されたツールからのシグナルを分類します。これらはナレッジグラフの関連タスクにリンクされるため、Slackの履歴を検索するのではなくタスクから意思決定の軌跡を追跡できます。
Q: 意思決定ログとナレッジグラフの違いは何ですか？ A: 意思決定ログは、発生したときに各意思決定を手動で記録する必要があります – それに気づき、一時停止し、要約し、タグ付けし、リンクします。ナレッジグラフはツールを流れるシグナルから意思決定を推測し、タスク、人、会話に自動的にリンクします。一方はすべてのチームメンバーの一貫した規律に依存し、もう一方はすでに起きているアクティビティからバックグラウンドで動作します。
Q: SugarbugはSlack以外のツールからも意思決定を抽出できますか？ A: SugarbugはSlack、GitHub、Figma、Linear、Notion、メール、カレンダーに接続します。意思決定は複数のツールにまたがることが多く（FigmaのコメントがSlackスレッドにつながり、PRにつながる）、ナレッジグラフはすべての接続されたサーフェスにわたってシグナルをリンクします。会話がどのツールで始まったかに関わらず、完全な軌跡を見ることができます。
Q: これはSlackの組み込み検索を使うことと何が違いますか？ A: Slack検索は特定のキーワードを含むメッセージを見つけます。ナレッジグラフはメッセージ、タスク、人の間の関係を見つけます。意思決定を探しているとき、単語を検索することはほとんどありません – チームが一つのアプローチを別のものより選んだ瞬間を探しており、その瞬間はそれを表現するために使われた言葉ではなく、他のシグナルへの接続によって定義されます。
---
意思決定がSlackの履歴に消え続けるなら、問題はSlackではありません – それは、重要な瞬間を監視して、それらが形作った作業に接続しているシステムがないことです。これが私たちがSugarbugで埋めようとしているギャップです。