Home | Blog | ガイド

5つのツールを使うチームで意思決定を追跡する方法

Slackスレッド、Notionドキュメント、Linearのコメント、PRレビューに散らばった意思決定を追跡する方法 – そして決定ログがあなたを救わない理由。

By Chris Calo · 2026-03-13

「もうこれ、決めませんでしたっけ？」

5人が通話に参加している。誰も答えない。誰かがミュートを解除して、3週間ほど前のSlackスレッドで話題になったと思う、たぶん#engineeringだったかもしれないし、#backendだったかもしれないと言う。デザイナーはNotionのコメントをうっすら覚えている。エンジニアの1人はもうLinearをスクロールしていて、クローズされたか、アーカイブされたか、別のプロジェクトに移動されたかもしれないイシューのコメントを探している。

問題の意思決定：今後使うAPIバージョニングスキーム。会社の命運を左右する選択ではない。アーキテクチャの崖っぷちでもない。ただ、複数ツールにまたがる意思決定をどう追跡するかについての率直な話し合い – より正確に言えば、確実に、証明可能に、すでに行われており、互いに話し合わない5つのツールの隙間に消えてしまった特定の意思決定をどう見つけるかということだ。

犯行現場を再構築してみよう。

消えた意思決定のフォレンジックタイムライン

実際に起きたことを、後から組み立てると次のようになる（結局すべてを見つけた – 水曜日の午後のほぼ1時間を費やしたが、それが生産的な時間の使い方だと感じた）。

1日目、午前10時14分 – エンジニアの1人が「APIバージョニングオプション」というタイトルのNotionドキュメントを#engineeringに投稿する。3つのオプション、それぞれの長所と短所が整理されている。きれいなフォーマット。良い考え。チームがうまく機能していると感じさせるドキュメントだ。

1日目、午前10時22分 – 共有リンクの下のSlackスレッドで議論が始まる。最初の20分で6つの返信。後方互換性、クライアントSDKへの影響、ヘッダーベースのバージョニングがデバッグの苦痛に見合うかどうかについての本物の有益な会話。また、返信4あたりで、昼食をどこで食べるかについての短い脱線（これが正直なところ、バージョニングの議論よりも速くコンセンサスが得られた）。

1日目、午前11時47分 – ずっとROMしていたデザイナーが一言: 「パスバージョニングの方がAPIエクスプローラーが読みやすくなる、/v2/にしよう。」サムズアップのリアクションが2つ。反論なし。意思決定完了。

1日目、午後2時30分 – チームメートがAPIリファクタリングイシューのLinearコメントに結果をまとめる。良い直感だ。しかしイシューがクローズされると、Linearのコメントは機能的に見えなくなるため、発見可能性の観点では最悪だとわかる。

8日目 – /v2/を実装するPRがマージされる。PRの説明はLinearイシューを番号で参照しているが、バージョニングの決定自体やそれが実際に起きたSlackスレッドについては何も言及していない。完全に普通のことだ。PRの説明に「ちなみに、この決定の完全な系譜はこちら」と書く人はいない。誰もそんな変人ではないから。

43日目 – 別のメンバーが関連チケットを担当し、「パスバージョニングをやっているのか、ヘッダーバージョニングをやっているのか？」と尋ねる。Notionドキュメント？結果で更新されたことは一度もない。Slackスレッド？6週間分のメッセージに埋もれている。Linearコメント？誰も検索しないクローズドイシューにある。PR？それが存在することを知っていなければ見つけられない。

そして5人が通話に座り、互いに見つめ合い、すでに6週間前に解決された意思決定を再導出している。進歩だ。

意思決定が死ぬ場所

問題は、これらのツールはどれも失敗していないことだ。SlackはSlackがやることをやった。Notionはドキュメントを美しく保持した。Linearはイシューを追跡した。GitHubはコードをマージした。すべてのツールが孤立した状態で完璧に機能した。それは褒め言葉に聞こえるが、実際には診断なのだと気づくまでは。

| 発生場所 | 後で見つけられない理由 | |---|---| | Slackスレッド | 6週間前に誰かが使った正確な言葉を覚えている必要がある。健闘を祈る。 | | Linearコメント | クローズドイシューのコメントは海底に刻まれたようなもの | | Notionドキュメント | ドキュメントは存在するが、誰も結果を更新しなかった。人間だから | | GitHub PR | マージ後に会話が折りたたまれる – どのPRを発掘すべきか知っている必要がある | | 会議（口頭） | 誰かがメモを取って、かつどこか見つけやすい場所に置いたのでなければ、完全に消えた | | メールスレッド | 検索はまあまあだが、正しいチェーンに入っていた場合のみ |

6つのツール。6つの検索エンジン。共有メモリはゼロ。

すべてのツールが孤立した状態で完璧に機能した。それは褒め言葉に聞こえるが、実際には診断なのだと気づくまでは。 attribution: Chris Calo

決定ログ：美しい骸骨

うなずきながら読んでいたなら、おそらくすでに「インスピレーション」が来ている。「よし、決定ログを作ろう」というやつだ。大文字のD、大文字のL。日付、決定、コンテキスト、利害関係者、ステータスの列を持つ豪華なNotionデータベース。チームチャンネルで発表する。自分で最初の3エントリを細かい詳細で追加すると、本当に素晴らしい気分になる。

私はこれを3社で全く同じように作ったことがある（そして、同じ失敗した実験を繰り返して異なる結果を期待することには臨床的な名前があることも知っている）。毎回、絶対に続くと確信していた。「今度は規律を持つ！」持てなかった。あなたも持てない。残酷なことを言いたいのではない – 失敗パターンが設計の中に焼き込まれているから言っているのだ。

こうなる。第1週：美しい。第2週：ほぼ入力されている。第3週：誰かがSlack DMでさっと決める、そしてログはそのことを聞かない。第4週：アーキテクチャの意思決定がレビューコメントに埋まったPRがマージされ、誰もそれを書き写そうとは思わない。第5週：誰かが休暇中で、残りのチームが昼食中に何かを決める（また昼食の話題が出た）、そしてログが沈黙する。

第6週には決定ログは記念碑になっている。良い意図への上品なモニュメントで、Notionのサイドバーに座って、デジタルの埃をかぶっている。私には3つある。美しい。そして完全に役に立たない。

決定ログが失敗するのは、チームが規律を欠いているからではなく、それが起きている最中に瞬間を重要だと認識し、一時停止して、ドキュメントツールにコンテキストスイッチし、6週間後に役立つだけの十分な詳細で書き上げることを人間に求めるからだ。本当の仕事で忙しい人たちにそれを求めるのは、馬鹿げたことだ。

実際に複数ツールにまたがる意思決定を追跡する方法

手動ログは人間の性質によって失敗する。ツールごとの検索はフラグメンテーションによって失敗する。実際に機能するのは、ツールの全表面積を監視し、誰も手を止める必要なく点を結ぶものだ。

実際には、4つのことを意味する：

自動取り込み。 ツールからのすべてのシグナル – Slackメッセージ、Linearコメント、PRレビュー、Notionの更新、会議の文字起こし – は誰かが指一本動かすことなくキャプチャされる。作業を続ける。システムが監視し続ける。スプレッドシートを開いてたった今起きたことを記録するために考えを中断する必要はない（いずれにしても、我々が確立したように、誰もしない）。

分類。 すべてのメッセージが意思決定ではない。ほとんどはステータス更新、質問、またはノイズだ。システムは「パスバージョニングとヘッダーバージョニングのどちらを使うべきか？」（質問）と「/v2/にしよう」（意思決定）と「/v2/エンドポイントがデプロイされた」（ステータス更新）の違いを伝える必要がある。ここでLLM分類器が役に立つ – ただし絶対確実ではない。「yeah let's just do that」が本当にコーヒーを飲みに行くことに同意しているだけなのに主要な意思決定としてフラグが立てられ続けた、印象的な時期があった。適切な確信スコアを得るには時間的コンテキストと送信者ロールの重み付けが必要だとわかった。

リンク。 これが「より良い検索」と実際の意思決定追跡を分けるポイントだ。Slackスレッドの意思決定がLinearイシューと関連し、GitHubのPRを生み出した場合 – それらのつながりは、誰かが丁寧に手で描いたからではなく、システムが参照（イシューID、PR番号、スレッドURL、時間的近接性）をたどったから存在する必要がある。Notionドキュメント、Slackスレッド、Linearコメント、PRはすべて互いを指し示す必要があり、自動的に、なぜならそれが実際に起きたことだから。

検索。 「APIバージョニングの意思決定」と検索すると、最初に検索したツールだけでなく、完全な軌跡が返ってくる。オプションが記載されたNotionドキュメント、決定が下されたSlackスレッド、それをまとめたLinearコメント、それを実装したPR。すべて接続されている。誰も1つのログに1つのエントリを入力することなく。

今すぐ試せる2つのこと（本当に、条件なし）：

#decisionsチャンネル。 Slackで作成して、別の場所で何かが決定されたら一言メモをそこに落とすようチームに頼む。手動だし、1ヶ月以内に機能しなくなる（この点について実績を確立している）が、部分的で劣化するログでさえ、断片化したコミュニケーションのパターンを痛いほど可視化する。

PRの説明習慣。 意思決定を実装するPRを開くとき、説明に1行追加する：「決定: [何が決定されたか] – [スレッド/ドキュメントへのリンク]参照。」10秒かかる、コードレビューを生き残り、未来の自分が実際に検索できるものを残す。Slack DMや昼食中に起きる意思決定は捉えられないが、捉えられるものはもっとも重要なもの – コードベースを変えるものだ。

つながった意思決定追跡が実際に変えること

考古学がクエリになる。 冒頭のバージョニング探索は、クロスツールインデックスがあれば、チェーン内のすべてのアーティファクトがリンクされた5秒の検索になる。水曜日の午後を恥ずかしく過ごさずに済んだ。 This is what visibility across your engineering tools actually means in practice. It’s closely related to a semantic approach to finding past Slack decisions and a connected view of tasks that span three or more tools – all three problems stem from the same fragmented-tools root cause.

腐らないオンボーディングコンテキスト。 新しいチームメンバーは、3ヶ月前に最後に更新されてみんな何となく間違っていることを知っているが誰も修正しようとしないウィキページの代わりに、なぜ物事がそうなっているのかの繋がったトレイルを得る。（あなたもそれを持っている。誰もが持っている。）

同じ議論の再演が減る。 これは私を驚かせた。意思決定が見つけられるようになると、「もうこれ決めませんでしたっけ？」が、誰もが話し合ったことを覚えているが実際に何が結論されたかを誰も確認できない10分間のグループ幻覚に溶けていく代わりに、数秒で答えられるようになる。

以前は見えなかったパターン。 意思決定が総合的に見えるようになると、どのトピックが最長の議論を生み出し、どこで意思決定が停滞するかに気づき始める。単一のツールでは得られない運用インサイト – 単一のツールには全体像がないから。

Sugarbugのアプローチ

バージョニング探索は、私がSugarbugの構築を始めるきっかけとなった最後の一撃だった（それと、良心を圧迫していた3つの死んだ決定ログ）。上で説明したシステム – APIで既存のツールに接続し、すべてのシグナルをナレッジグラフに送り込み、自動的に分類してリンクする。グラフはチームが作業する間に自分で構築される。ドキュメント化は作業自体の副作用だから、誰も何もドキュメント化しない。

まだ初期段階（本番稼働中、プレローンチ）で、解決していない難しい問題がある – ノートを取らなかった会議での口頭での意思決定や、「yeah, let's do that」を本当のコミットメントから曖昧さを解消すること（コーヒーの件が確信閾値について多くを教えてくれた）。しかし過去の意思決定を探すのに費やす時間が「定期的に頭にくる」から「時々軽度に」に減ったのは、妥当な軌跡だと感じる。

シグナルインテリジェンスをインボックスに届けます。

よくある質問

数週間前のSlackスレッドで行われた意思決定をどうやって見つけますか？

クロスツールインデックスがなければ、私がやったことをやっている – スクロールして、異なるキーワードを試して、大体いつ会話が起きたか覚えていることを願う。SugarbugはSlackメッセージを他のソースと並んでナレッジグラフに取り込むので、正確なキーワードではなく概念で検索できる。魔法ではない – 会話はまだテキストで行われている必要がある – しかし考古学的発掘よりはましだ。

Sugarbugは複数のツールにまたがる意思決定を自動的に追跡しますか？

追跡する。接続されたツールからのすべてのシグナルが分類される – 意思決定、ステータス更新、質問、ブロッカー – そして関連する人とタスクにリンクされる。Linearイシューに関連するSlackスレッドに意思決定が現れると、誰もリンクをコピーペーストしたりログを更新したりすることなく、グラフが接続する。

決定ログとナレッジグラフの違いは何ですか？

決定ログは、何が決定されたか、いつ、誰によってかを誰かが書き留めることを必要とする。ナレッジグラフは、ツールがすでに生み出しているシグナル – Slackスレッド、Linearイシュー、それを実装したPR – からそれらのつながりを自動的に構築する。一方は規律を必要とし（私が十分に確立したように、我々はひどく苦手だ）；もう一方はシステムを必要とする。

なぜ決定ログは常に失敗するのですか？

ちょうど最悪のタイミングでコストが発生するから。それが起きている最中に意思決定を重要だと認識し、一時停止し、別のツールに切り替え、数週間後に役立つだけの十分なコンテキストで書き上げ、そして思考の流れを失わずに仕事に戻る必要がある。これを試みたすべてのチームが6週間以内に放棄する – 怠慢からではなく、そのプロセスが実際の働き方に逆らうから。

小規模チームは恩恵を受けられますか、それとも大規模組織向けだけですか？

私の経験では、小規模チームの方がより大きな打撃を受ける。ドキュメントを維持する専任PMはおらず、「組織の記憶」は良い記憶力を持っている1人か2人の人間だ。Slack、GitHub、Notionにまたがって毎週数十のマイクロ決定をしている5人のスタートアップは、50人の組織と同じ断片化問題を抱えている – ただ何かが失われたときのコストを吸収する人が少ないだけだ。

---

すでに数週間前に解決された意思決定を5人が再構築しようとしている通話に座ったことがあるなら、それがまさに我々がSugarbugを構築して排除しようとした問題だ。ウェイトリストに参加する。