フレームワーク活用ガイドひとことで言うと#
「何を加えるか」ではなく**「何を取り除くか」**で改善を図る思考法。もともとは神学で「神とは何でないか」を語ることで本質に迫るアプローチだったが、ナシーム・ニコラス・タレブが『反脆弱性』で意思決定やリスク管理の原則として再定義した。
押さえておきたい用語#
- ヴィア・ネガティヴァ（Via Negativa）
- ラテン語で**「否定の道」**。本質に到達するために、本質でないものを一つずつ取り除いていくアプローチ。
- ヴィア・ポジティヴァ（Via Positiva）
- 「肯定の道」。何かを追加・構築することで目標に近づくアプローチ。多くの人がデフォルトで採用する思考法。
- 引き算バイアス（Subtraction Neglect）
- 人間が改善策を考えるとき、追加する選択肢を過大評価し、除去する選択肢を見落とす認知的傾向。2021年のNature誌の研究で実証された。
- 反脆弱性（Antifragility）
- ストレスやショックによってむしろ強くなる性質。余計なものを取り除くことで、システムの反脆弱性が高まるとタレブは主張する。
ヴィア・ネガティヴァの全体像#
こんな悩みに効く#
- 機能やサービスを追加し続けた結果、プロダクトが複雑になりすぎている
- 「やることリスト」が増え続け、本当に重要なことに集中できない
- 会議・報告・承認プロセスが積み重なり、組織が重くなっている
- 改善策を考えるとき、いつも「何を追加するか」の議論になってしまう
基本の使い方#
まず、対象領域にあるもの（機能、プロセス、タスク、ルールなど）をすべてリストアップする。
- プロダクトなら全機能、業務なら全プロセス、個人なら全タスクを列挙する
- 「いつからあるか」「誰が始めたか」も記録すると、惰性で続いているものが浮かび上がる
- この段階では判断しない。まず全体を見渡すことが目的
リストの中から「なくなっても本質的な価値が下がらないもの」を見つける。
- 利用率が低いもの: 機能の利用率、会議の出席率、レポートの閲覧率を確認する
- 惰性で続いているもの: 「なぜやっているか」の理由が「昔からそうだから」しか出ないもの
- 副作用があるもの: あることによって複雑さ・コスト・混乱が生まれているもの
- 判断に迷ったら「もしこれが最初からなかったら、わざわざ今から作るか？」と問う
いきなり大きく削るのではなく、1つずつ除去して影響を確認する。
- まず最もリスクの低い除去候補から始める
- 除去後、2週間は観察期間を設ける。問題が出たら元に戻せる仕組みを用意しておく
- 「誰も困らなかった」なら本物の無駄。「一部困った」なら代替手段を検討する
除去によって生まれた時間・予算・注意力を、本当に重要なことに再配分する。
- 除去が目的ではなく、除去によって本質が際立つことが目的
- 「削った時間で何に集中するか」を事前に決めておかないと、別の雑事が入り込む
- 定期的に（四半期に1回程度）ヴィア・ネガティヴァの棚卸しを繰り返す
具体例#
ユーザー数8,000のプロジェクト管理SaaS。3年間で機能を47個追加してきたが、月間アクティブユーザー率（MAU率）は**62% → 44%に低下。新規ユーザーの初回ログイン離脱率が38%**に達していた。
棚卸し: 全47機能の月間利用率を調査したところ、利用率5%以下の機能が18個（全体の38%）あった。開発チームのリソースの**25%**がこれらの機能の保守に費やされていた。
除去プロセス:
- Phase 1: 利用率1%以下の機能7個を非表示に（データは保持、UIから消す）
- Phase 2: 2週間後、問い合わせゼロだった5個を完全削除。2件問い合わせがあった2個は代替手段を案内
- Phase 3: 利用率5%以下の残り11個も同様のプロセスで段階的に削除
結果:
- UIがシンプルになり、初回ログイン離脱率が**38% → 19%**に半減
- MAU率が**44% → 58%**に回復
- 開発チームのリソースの25%が解放され、コア機能の改善に投入。ユーザー満足度（NPS）が+12ポイント上昇
- 「機能が多い＝価値が高い」という社内の思い込みが覆った
12名のチームを率いるマネージャー。メンバーから「会議が多すぎて集中作業の時間がない」という声が上がっていた。チーム全体の週あたり会議時間は平均18.5時間（労働時間の46%）。
棚卸し: 全定例会議14個をリストアップし、それぞれについて「目的」「参加者」「決まったこと（直近1か月）」を調査した。
| 会議 | 頻度 | 直近1か月の成果 |
|---|---|---|
| チーム朝会 | 毎日15分 | 情報共有として機能 |
| 進捗報告会 | 週1回60分 | 3回中2回は報告のみで議論なし |
| プロジェクトA定例 | 週1回60分 | 意思決定あり |
| プロジェクトB定例 | 週1回60分 | 4回中3回は15分で終了 |
| 部門横断定例 | 週1回30分 | 1か月間で有用な情報交換ゼロ |
| その他9件 | 様々 | 半数以上が形骸化 |
除去アクション:
- 廃止（5件）: 部門横断定例、形骸化した会議を削除。必要な情報はSlackで非同期共有
- 短縮（3件）: 進捗報告会を60分→15分に短縮し、報告はドキュメント事前共有に変更。プロジェクトB定例を60分→30分に
- 統合（2件）: 類似テーマの会議2件を1件に統合
- 維持（4件）: チーム朝会、プロジェクトA定例など機能している会議はそのまま
結果: 週あたり会議時間が18.5時間 → 8.2時間に削減。メンバーの「集中作業に使える時間」が週平均10時間増加し、スプリントのベロシティが28%向上。マネージャー自身も「会議を減らしても何も問題が起きないことに驚いた」とコメント。
IT企業勤務のシニアエンジニア。多忙を極め、毎日12時間以上働いているが成果が伴わない。「もっと効率的な方法を追加しなければ」と新しいツールや習慣を次々に試すが、どれも長続きしなかった。
棚卸し（1日の時間配分）: 2週間、全ての活動を15分単位で記録した結果:
| 活動 | 週あたり時間 | 本人の価値実感 |
|---|---|---|
| コア業務（設計・実装） | 18時間 | 高い |
| コードレビュー | 8時間 | 中程度 |
| Slack対応 | 10時間 | 低い |
| 情報収集（RSS・Twitter） | 6時間 | 低い |
| 社内政治的ミーティング | 5時間 | 非常に低い |
| ツール設定・環境整備 | 4時間 | 低い |
| その他雑務 | 9時間 | 低い |
除去プロセス:
- Slack対応: 通知をOFFにし、確認を1日3回（朝・昼・夕）に限定 → 週10時間 → 3時間
- 情報収集: RSSフィードを120件 → 15件に削減。Twitterのフォローを400 → 60に → 週6時間 → 2時間
- 社内政治的ミーティング: 「自分がいなくても成立する会議」を全て辞退 → 週5時間 → 1時間
- ツール設定: 新ツールの試用を3か月間凍結。既存ツールだけで仕事する
3か月後: 週あたりのコア業務時間が18時間 → 31時間に増加。プルリクエストの数が月12件 → 月22件に。「足すのではなく引くことで、こんなに余裕が生まれるとは思わなかった」と本人が振り返った。
やりがちな失敗パターン#
- 除去すること自体が目的になる — ミニマリズムに走りすぎて、本当に必要なものまで削ってしまうケースがある。ヴィア・ネガティヴァの目的は「本質を際立たせる」ことであり、「少なくする」ことではない
- 一気に大量に削る — 小さく除去して影響を観察するプロセスを飛ばすと、取り返しのつかない事態になりうる。段階的に進めることが鉄則
- 「なくても困らなかった」を検証しない — 除去後に影響を測定しないと、実は静かに悪影響が出ていることに気づけない。除去後の観察期間を必ず設ける
- 引き算バイアスの存在を知らない — 人は本能的に「足す」方向で考える。この認知バイアスを自覚していないと、ヴィア・ネガティヴァの選択肢が検討テーブルに載らない
まとめ#
ヴィア・ネガティヴァは、「何を追加するか」ではなく**「何を取り除くか」**で改善を図る思考法である。人間には追加を好み除去を見落とす「引き算バイアス」があるため、意識的にこの視点を持つことが重要。実践のコツは3つ。棚卸しして全体を見渡し、小さく除去して影響を観察し、生まれた余白を本質に振り向ける。足し算の改善が行き詰まったとき、引き算が突破口になることは驚くほど多い。