Obsidianを使った意思決定管理の思考実験
はじめに
こんにちは。PIVOTでiOSアプリ開発を主に担当している楠瀬（@indiamela）です。
PIVOTでは現在、
- GitHub Projects でチームのタスク管理
- Slack で日々の議論
- Notion でナレッジやドキュメント管理
というツール構成で開発を進めています。
この構成自体に大きな不満があるわけではなく、タスクの進行状況は比較的クリアに把握できています。
一方で最近、次のような違和感を感じることが増えてきました。
「このタスク、なぜこういう結論になったんだっけ？」
「会議で何が決まったのか、後から追うのが大変」
そんな時、たまたま以下の記事を読んだことがきっかけで、上記の課題に対する新しいアプローチがありそうだと考えました。
この記事を参考に、Obsidianを使うことで改善できる可能性があるのかを、
あくまで 思考実験 として整理してみます。
現状の整理：PIVOTの情報管理で起きていること
できていること
-
GitHub Projects によって
- タスクの状態
- 担当者
- 進捗
が明確になっている
-
Slack では活発に議論が行われている
-
Notion には設計資料や共有ドキュメントが蓄積されている
日々の開発を回す、という観点では大きな問題はありません。
しんどさを感じているポイント
一方で、次のような点に負荷を感じています。
- 会議で決まった「結論」がどこにあるかわからない
- Slack・Notion・GitHub Issue に情報が分散している
- 新しく参加したメンバーほど文脈を追うのが難しい
整理すると、
情報は存在しているが、意思決定の履歴としては残っていない
という状態になっていると感じています。
問題の本質：タスク管理と意思決定は別物だった
GitHub Projects は、
「何を・誰が・いつまでにやるか」 を管理するには非常に優れています。
一方で、そこでは次の要素はあまり扱われません。
- なぜその判断に至ったのか（Why）
- どんな選択肢があったのか（Context）
- どの会議・議論で決まったのか（Decision）
つまり、このようになっています。
タスク管理 = 実行の管理
意思決定 = 思考の管理
同じツールで両方を担おうとしていたこと自体が、
そもそもズレていたのではないか、という仮説に至りました。
なぜ Obsidian が候補に上がったのか
この課題を考える中で、Obsidian に注目しました。
- Markdownベースで軽量に書ける
- ノート同士を双方向リンクでつなげられる
- 構造を最初から決めなくても、後から育てられる
特に重要だと感じたのは、
情報を「整理する」よりも「関係づける」ことに向いている点です。
参考の記事にもある通り、Obsidianはナレッジ管理ツールというより、
意思決定の背景や文脈を残すためのツールとして使えるのではないかと考えました。
思考実験：Obsidianをどう使えば改善できるか
Obsidianの役割定義
この思考実験では、Obsidianの役割を次のように定義します。
Obsidian = 意思決定の記憶装置
- タスクの進行は管理しない
- 「何が決まり、なぜそうなったか」だけを残す
会議ノートの書き方（仮）
会議ノートは、時系列ではなく
決定事項を最初に書く構成を想定します。
例：
# 2026-01-XX プロダクト定例
## 決定事項
* ホーム画面のA/BテストはiOS先行で実施
## 判断理由
* iOS側の実装影響が限定的
* 学習コストを下げたい
## 関連
* GitHub Issue #1234
* [[A/Bテスト設計]]
Decisionノートを独立させる
重要な決定は、会議ノートから切り出して
1つの意思決定 = 1ノートとして残します。
例：
# Decision: ホーム画面A/BテストをiOS先行にする
## 日付
2026-01-XX
## 決定内容
iOSのみ先行でA/Bテストを実施する
## 背景
[[2026-01-XX プロダクト定例]]
## 影響範囲
* GitHub Issue #1234
* iOS v5.4.0
決定を残すことは、変更しづらさを生むのか？
ここで一つ、よく感じる違和感があります。
決定を記録すると、後から方針を変えづらくなるのではないか？
実際、多くのチームでは
「決定を明文化すると縛られる」という感覚があるように思います。
しかし、この思考実験では逆の仮説を置いています。
決定を残すことは、変更を妨げるのではなく、
変更を説明可能にするのではないか、という仮説です。
- ある時点での判断 A
- 状況が変わり、新たな判断 B
- なぜ B に変えたのかが、A との関係性として残る
Obsidianのリンク構造は、
この「判断の変遷」を履歴として残すことに向いています。
決定を残すことは、
「固定する」ことではなく
変化の理由を言語化できる状態を作ることだと考えています。
既存ツールとの住み分け
この構成は、既存ツールを置き換えるものではありません。
| ツール | 役割 |
|---|---|
| GitHub Projects | タスクの進行管理 |
| Slack | 議論・一時的な会話 |
| Notion | 外向けドキュメント |
| Obsidian | 意思決定と背景の記録 |
あくまで 補完関係 として使うことを前提にしています。
Obsidianを使わなくてもいい、という結論
ここまで Obsidian を前提に話してきましたが、
実はこの思考実験で一番伝えたいことは別にあります。
それは、
問題はツールではなく、
意思決定をどう扱うかを定義していなかったこと
です。
意思決定を、
- その場限りの会話にするのか
- 後から振り返れる資産として残すのか
この選択をしない限り、
どんなツールを使っても同じ課題は繰り返されると思います。
Obsidianは、その問いに向き合うための
一つの具体例に過ぎません。
まとめ
今回の思考実験を通して考えたのは、
あなたのチームでは、
「なぜその判断をしたのか」を
1ヶ月後に説明できるだろうか？
という問いでした。
ツールの選定よりも先に、
意思決定をどのように残したいのかを
チームとして考えること自体が、
最初の一歩なのかもしれません。
今後、小さく試しながら検証していく予定です。
Discussion