GTDからGTD+B=MAPへ
― B=MAPでGTDを「確実に動く仕組み」に進化させる ―
はじめに:GTDは「整理する技術」、B=MAPは「動き出す技術」
GTDは完成された「タスク整理術」のシステム
GTDというタスク管理手法がある。
正式には Getting Things Done。デビッド・アレンが提唱した、生産性向上のためのタスク管理・思考整理の体系である。頭の中にある気がかりをすべて外に出し、それを整理し、次に取るべき行動へ変換し、定期的に見直す。これにより、頭の中の混乱を減らし、信頼できる外部システムにタスクを預けることを目指す。(詳細は書籍 新装版 はじめてのGTD ストレスフリーの整理術 をご覧いただきたい)
とても理解しやすいシンプルで明快なロジックで組み立てられた誰でも今日から真似できるシステムだ。特別なツールも、特別な知識も必要ない。
世界中の生産性に一家言あるクールな人たちに愛され、今も改訂が続く、本当に完成されたシステムだ。ちょっと立ち上がりだけは重いけど、導入してしまえばずっとあなたの生産性を支えてくれる。
みんなそう言ってる。間違いない。あのクールなハッカーだって愛用してる。
...でもさ、続いた試しがないんだよね
そう、難しいことは何もない。そのくせ生産性は使い込むほど上がっていく。
そのはずなんだ
……続かないだけで。
GTDに出会い、その美しくシンプルなシステムにHeart Beatし、Brain Dumpをし、Next Actionを書き、Weekly Reviewに挑戦した人は少なくないだろう。そして同時に、こう感じた人もいるはずである。
(あ、ちなみにHeart BeatはGTD用語ではない)
- 書いたのに動かないタスクがある
- Next Actionにしたはずなのに、まだ手が止まる
- Weekly Reviewが続かない
- Brain Dumpを始めること自体が重い
- システムは整っているのに、実行が安定しない
これは、あなたが間違っているからではない。
GTDが間違っているからでもない。
GTDは、今なお非常に優れた認知整理システムである。ただし、GTDが主に扱っているのは「タスクを信頼できる形で整理すること」であって、「そのタスクを確実に発火させること」ではない。
続けられない私が「弱い」んじゃない
一方、B=MAPという行動モデルがある。
これは、スタンフォード大学のBJフォッグが提唱した行動設計のモデルで、人が行動するには、Motivation(動機)、Ability(実行しやすさ)、Prompt(きっかけ)の3つが同時に揃う必要がある、という考え方である。
やる気がないと手がつかない、実行しづらいタスクは手がつかない、良いタイミングできっかけがないと手がつかない。適切な強度で3つを組み合わせて意図的に設計・配置することで、起こしたい行動を確実に起こせる…という。ちなみに、この3つの中で「Motivation(動機)」が最も不安定で、信用ならないと重ねて説かれている。
(こちらも詳細は書籍 習慣超大全――スタンフォード行動デザイン研究所の自分を変える方法 をご覧いただきたい)
つまりこういうことである。私たちがGTDを続けられないのは、私たちの意志が「弱い」せいじゃない。
そういうわけで、本日のお題
ごく簡単に言えば、
- GTDは「何をやるべきか」を整理する技術である。
- B=MAPは「どうすれば実際に動き出せるか」を設計する技術である。
この2つは競合しない。むしろ、非常に相性が良い。
そこに、B=MAPを組み合わせる余地がある。
GTDにB=MAPを加えると、タスク管理は単なる整理術ではなく、実際に行動が起きる仕組みに近づいていく。
この記事では、GTDをB=MAPで補強し、さらに生成AIを組み合わせることで、現代的な生産性システムへ進化させる方法を整理する。
1. GTDが解決したこと
GTDが解決した問題は明確である。
| 問題 | GTDの解決 |
|---|---|
| 頭の中が混乱している | すべて外に出す |
| 何から手をつけるか曖昧 | 文脈と状況で選択できるようにする |
| プロジェクトが止まる | Next Actionに変換する |
| システムを信頼できない | 定期レビューで更新する |
GTDの強みは、頭の中に散らばった「気がかり」を、信頼できる外部システムへ移すことにある。
「あれをやらなければ」
「これも忘れてはいけない」
「あの件はどうなっていたか」
こうした未整理の認知負荷を、頭の中に置いたままにしない。いったん外に出し、意味のある単位へ整理し、次に取るべき行動へ変換する。
GTDは、タスク管理というより、むしろ「認知負荷を下げるための構造化技術」と言った方が近い。(余談だが、情報が電子化され、もはや奔流状態の現代において、認知容量は最も重要な資源である。無駄遣い、もったいない)
これは非常に強力である。
GTDによって、私たちは次のような状態を得る。
- 頭の中だけで覚えておかなくてよい
- プロジェクトを行動単位に落とせる
- 今やるべきことを文脈から選べる
- 定期レビューによってシステムを信頼できる
つまりGTDは、「何をやるか」を明確にし、それが明確であり続けるための仕組みを提供している。
2. それでもGTD実践者がぶつかる壁
しかし、GTDを実践すると、多くの人が似た壁にぶつかる。
「整理はできた。でも動かない」
これだ。どうしても続かない。
忙しい時ほどGTDに頼りたいのに、忙しい時ほどGTDの習慣は後回しになるのである。
2.1 Brain Dumpの壁
GTDでは、頭の中の気がかりをすべて書き出すことが重視される。
しかし実際には、これが重い。
| 理想 | 現実 |
|---|---|
| すべて書き出す | 重い。終わらない。始めにくい |
「すべて出す」と言われると、それだけで身構える。
時間があるときにやろう…
落ち着いたらやろう…
週末にまとめてやろう…
そう思っているうちに、Brain Dumpそのものが先延ばしされる。
ここで問題になっているのは、やる気の不足ではない。行動のスケールが大きすぎることである。
より正確に言えば、行動全体が大きいことよりも、「始めるための入口」が大きすぎることが問題である。
頭の中に、ぱんぱんに詰まった「気がかり」を書き出すなんて、なんか後回しにしたくなるでしょ? ぱっと手をつけて、ぱっと終わるようなFocusがシンプルな人は、そもそもGTDを必要としないんだし。
2.2 Clarifyの壁
GTDでは、書き出した項目を明確化し、必要であればNext Actionへ変換する。
しかし、このNext Actionも、実際にはまだ大きいことが多い。
| 理想 | 現実 |
|---|---|
| 次の行動を書く | まだ曖昧。分解が面倒。 |
たとえば、
- 企画を考える
- 資料を作る
- 上司に相談する
- ブログを書く
これらは一見、行動に見える。しかし、実際に着手しようとすると、まだ大きい。
「企画を考える」とは、具体的に何をすることなのか? 「資料を作る」とは、まずファイルを開くことなのか、構成を書くことなのか、材料を集めることなのか? 「ブログを書く」とは、タイトルを決めることなのか、冒頭を書くことなのか、過去メモを探すことなのか。
Next Actionと呼んでいても、多くは「行動開始単位」まで小さくなっていないし、小さくするためにも「認知負荷」はバッチリかかる。そして、手が止まる。
2.3 Weekly Reviewの壁
GTDでは、Weekly Reviewが重要である。
しかし、これもまた重い。
| 理想 | 現実 |
|---|---|
| 毎週1時間レビューする | 先延ばしされる。いつの間にか消える。 |
Weekly Reviewは、GTDシステム全体の信頼性を維持する重要な仕組みである。
だが、「毎週1時間、全体を見直す」と考えた瞬間に、負荷が高くなる。
忙しい週ほどレビューが必要なのに、忙しい週ほどレビューできない。結果として、システムの信頼性が低下し、GTDそのものが使われなくなる。
ここでも問題は、意志の弱さではない。
行動の入口が大きく、実行のきっかけが固定されていないことである。
3. B=MAPとは何か
3.1 壁のことはシミの数まで知っている、で、どう助けてくれるんだ?
ここで役に立つのが、B=MAPである。
B=MAPは、行動が起きる条件を次のように整理する。
Behavior = Motivation + Ability + Prompt
厳密な数式というより、「行動は、動機・実行しやすさ・きっかけが揃ったときに起きる」というモデルとして理解すればよい。
- B:Behavior(行動)
- M:Motivation(動機)
- A:Ability(実行しやすさ)
- P:Prompt(きっかけ)
人は、やる気があっても、行動が難しければ動けない。
行動が簡単でも、きっかけがなければ始まらない。
きっかけがあっても、難しすぎれば先延ばしする。
つまり、行動を安定させるには、やる気に頼るのではなく、
- 行動の入口を小さくする
- 実行しやすくする
- きっかけを固定する
ことが重要になる。
ここでGTDとの接点が見えてくる。
GTDは、タスクを整理し、Next Actionへ落とすことで、ある程度Abilityを下げている。つまり、「何をすればよいか分からない」という難しさを減らしている。
しかし、GTDのNext Actionは、必ずしも「即座に始められる最初の一手」になっているとは限らない。
ここがB=MAPの出番である。
3.2 「30秒で始められる」とは、30秒で終えることではない
ここで注意しておきたいことがある。
B=MAPの観点から行動を小さくするとは、すべての行動を30秒以内に分解する、という意味ではない。
資料作成も、企画立案も、読書も、レビューも、それ自体は30秒では終わらない。無理にすべてを30秒単位へ分解しようとすれば、タスク管理そのものが肥大化し、かえって面倒になる。
そもそも30秒で終わらない仕事の全てを30秒単位に分解するタスク自体が30秒で終わらない。そのタスクを分解するタスクも30秒で終わらない…
無限の再帰ループ、地獄の蓋がOpen Sesameである。
3.3 手を付けてみたら意外に捗っちゃった…なんて経験あるでしょ?
重要なのは、行動全体を小さくすることではなく 着手点 を小さくすることである。
たとえば、「資料を作る」は30秒では終わらない。しかし、「資料ファイルを開く」「タイトルだけ書く」「前回資料を1つ確認する」であれば、30秒で始められる。そして手を付けてみると、案外、その次のアクションも自然に続けてしまいがちだ。
始めてみて、そのまま続けられるなら続ければよい。
30秒で止める必要はない。むしろ、始めた結果として自然に続くなら、それは望ましい。やる気と状況が許す限り、続けてしまえばいい。
逆に、中断した場合は、次に再開するときのために、あらためて「30秒で始められる一手」を設定すればいい。
「だいじょうぶ、今ちょっと中断しても、また30秒で戻れる」
…なんて安心感あふれる呪文だろうか。
つまりB=MAPが求めているのは、行動を極小単位に刻み続けることではない。
求められているのは、行動が止まっている場所に 小さな着火点 を置くことである。
4. B=MAPは、摩擦面にだけ介入する
B=MAPは終わらせる技術ではない
B=MAPの役割を誤解しないで欲しい。これは「タスクを確実に終わらせる技術」ではない。
B=MAPの焦点は 「確実に始める技術」 である。
人は、やるべきことが分かっていても、なかなか手をつけない。資料を作るべきだと分かっている。メールを返すべきだと分かっている。レビューをした方がよいことも分かっている。
あれもやっとかなきゃ、これもやっとかなきゃ、だってリストにもちゃんと書いてある。
何をしなくちゃいけないか? 全部、私は知っている!
それでも、手をつける代わりに先延ばしする。
この「分かっているのに始まらない場所」が 行動の摩擦面 であり、B=MAPが介入するのは、まさにココである。
行動全体を極小単位に分解する必要はない。すべての作業を30秒タスクへ刻む必要もない。必要なのは、止まっている行動に対して、始められるだけの 小さな着火点 を置くことである。
どうやったら終わるか? それはGTDに聞いてくれ
たとえば、「資料を完成させる」はB=MAPの主対象ではない。
B=MAPが扱うのは、まず「資料ファイルを開く」「タイトルだけ書く」「前回資料を1つ見る」といった、開始のための最初の一手である。
始めてみて、そのまま続くなら続ければよい。30秒で止める必要はない。
一方で、中断した場合や、再開が重くなった場合には、次の摩擦面が生まれる。そのときは、また次の「30秒で始められる一手」を設定すればよい。
つまりB=MAPは、タスクが確実に終わるまでの過程を管理し続ける技術ではない。
行動が止まる場所、先延ばしが起きる場所、再開が重くなる場所にだけ、そっと介入して「始める」「手を付ける」「再開する」をお手伝いする技術である。
完了を支えるのは、GTDのような信頼できる整理システムであり、レビューであり、望ましい習慣である。B=MAPは、それらを動かすための発火条件を整える。
GTDが「何をすべきか」を明確にするなら、B=MAPは「どうすれば始まるか」を明確にする。
この役割分担を間違えないことが、GTD+B=MAPを実践的な仕組みにするうえで重要である。
5. GTDとB=MAPはどこで接続するのか
GTDとB=MAPの接続点は、Next Actionのさらに手前にある。
- GTDは、プロジェクトをNext Actionへ変換する。
- B=MAPは、そのNext Actionを「実際に始められる行動開始単位」へ変換する。
整理すると、こうなる。
---
title: GTDとB=MAPの接続点
---
graph TD
inbox[気がかり]
clarify[明確化]
project[プロジェクト]
nextAction[Next Action]
bmap[B=MAPフィルター]
tinyAction[30秒着手単位]
behavior[実行]
inbox --> clarify
clarify --> project
clarify --> nextAction
project --> nextAction
nextAction --> bmap
bmap --> tinyAction
tinyAction --> behavior
GTDだけの場合、Next Actionを書いたところで止まることがある。
だからGTD+B=MAPでは、Next Actionに対してさらに次の問いを立てる。
- これは30秒で始められるか?
- 今この場で最初の一歩だけやるなら何か?
- はじめるためのキッカケはどこに・なにに貼り付けておくか?
- 何が見えたら、何が終わったら、これを始めるか?
たとえば、
| GTDのNext Action | B=MAP後の30秒着手単位 |
|---|---|
| 企画を考える | タイトル案を1つだけ書く |
| 資料を作る | 空のスライドを開いて見出しを1つ書く |
| 上司に相談する | チャット欄に相談文の1行目だけ書く |
| ブログを書く | 仮タイトルを1つ書く |
| Weekly Reviewする | プロジェクト3件に○×をつける |
GTDが「次に何をするか」を決めるなら、B=MAPは「どうすればそれを確実に始められるか」を決める。
この違いは小さいようで、大きい。
6. 実践プロトコル:GTD+B=MAPの使い方
では、具体的にどう使えばよいか。
ここでは、GTDの主要な実践をB=MAPで補強する形で整理する。
6.1 Brain Dump 2.0
従来のBrain Dumpは、「すべて出す」ことを目指す。
しかし、これが重い。
そこで、B=MAP的には、Brain Dumpの入口を小さくする。
---
title: Brain Dump 2.0
---
graph LR
subgraph past[従来]
past1[すべて出す]
end
subgraph evolved[進化版]
evolved1[タイマー5分]
evolved2[思いついた3件だけ]
evolved3[整理しない]
end
past --> evolved
「全部書く」を、目指さなくっていい。一つでも二つでも書き出せたら、その分だけ「脳」は軽くなる。十分だ。こんなめんどくさいことわざわざやってる私は偉い。
とにもかくにも、まず始めることである。手を付けたら、付けた分だけ前進している。途中でやめても、いつだって続きは始められる。(続きは何か? GTDに聞けば分かるでしょ?)
たとえば、次のようにする。
- 5分だけ書く
- 3件だけ出す
- 整理しない
- 書いたら終わりにする
Brain Dumpを「大掃除」にしない。「頭の中から少し外へ出す」だけでよい。
そこから続けられるなら、そのまま続ければよい。止まったら、また次に始められる入口を作ればよい。
6.2 Next Action 2.0
Next Actionは、さらに「着手しやすく」する。
問いは2つでよい。
- 30秒で始められるか?
- 明日やるなら、最初の一手は何か?
例を挙げる。
| 大きすぎる行動 | 30秒着手単位 |
|---|---|
| 企画を考える | タイトルだけ書く |
| 資料を作る | ファイルを開く |
| メールを書く | 宛先だけ入れる |
| 本を読む | 目次だけ見る |
| ブログを書く | 見出しを1つ書く |
ここで重要なのは、「それだけやっても意味があるのか」と考えすぎないことである。
30秒着手単位の目的は、完了ではない。
開始である。
開始できれば、行動は続きやすい。中断したっていい。いつだって戻ってきて再開できる。
6.3 Weekly Review 2.0
Weekly Reviewも、入口を小さくする。
---
title: Weekly Review 2.0
---
graph TD
subgraph past[従来]
past1[全体確認]
past2[1時間確保]
end
subgraph evolved[進化版]
evolved1[プロジェクト3件だけ]
evolved2[○×をつけるだけ]
evolved3[金曜昼後に固定]
end
past --> evolved
理想のWeekly Reviewを毎週できるなら、それに越したことはない。
しかし、毎週できない理想的レビューより、毎週できる小さなレビューの方が強い。
だって1週間経つと、タスクは1週間分、鮮度が落ちる。2週間後では手遅れのものも出てくる。
一方で、新鮮さが必要なタスクや、メンテしなくちゃいけないタスクなんて全体の2割がいいところだ。(いわゆる2:8の法則ってヤツなんで、厳密に計測して「2割じゃありませんでした!」なんて文句言ってこないように)
たとえば、次のようにする。
- 金曜昼食後に10分だけ行う
- プロジェクトを3件だけ見る
- 進んでいるか止まっているか、○×をつける
- 止まっているものだけNext Actionを1つ書く
これだけでも、システムの信頼性はかなり維持できる。
ここでもB=MAPが担うのは、「レビューを完全に終わらせること」ではなく、「レビューを始められる状態にすること」である。始めてみて、続けられるなら続ければよい。
7. Horizons of Focusとの関係
GTDには、Horizons of Focusという考え方がある。
これは、タスクやプロジェクトを、目先の行動だけでなく、役割・目標・ビジョンといった上位の地平から整理する考え方である。
整理すると、次のようになる。
| 地平 | 性質 | 時間軸 | 役割 |
|---|---|---|---|
| Runway | 実行可能行動 | 今日〜数日 | 実行 |
| 10,000ft | プロジェクト | 数週間〜数ヶ月 | 完了可能単位 |
| 20,000ft | 役割 | 継続 | 責任領域 |
| 30,000ft | 目標 | 1〜2年 | 到達点 |
| 40,000ft | ビジョン | 長期 | 方向性 |
ここで誤解してはいけないことがある。
B=MAPを導入するからといって、上位地平を30秒行動へ直接分解するわけではない。
たとえば、
- 良いマネージャーである
- 信頼されるパートナーである
- 持続可能な体制を築く
- チームの生産性を高める
こうしたものは、30秒で達成するものではない。
それらは、行動そのものではなく、行動を方向づける枠組みである。
B=MAPが介入するのは、上位地平ではない。
介入するのは、行動が発火する瞬間である。
---
title: Horizons of FocusとB=MAPの関係
---
graph TD
vision[40,000ft ビジョン]
goal[30,000ft 目標]
role[20,000ft 役割]
project[10,000ft プロジェクト]
runway[Runway 行動]
bmap[B=MAP]
tiny[30秒着手単位]
action[実行]
vision --> goal
goal --> role
role --> project
project --> runway
runway --> bmap
bmap --> tiny
tiny --> action
つまり、正しい統合はこうである。
- 誤り:上位地平を30秒に分解する
- 正しい:上位地平に整合する行動の着手点を30秒化する
上位地平は「意味の座標軸」である。
B=MAPは「行動の発火装置」である。
両者は役割が違う。
上位地平は、日々の小さな行動の累積によって近づく場所である。
小さな着手 × 固定トリガー × 繰り返し × 時間
= 上位地平への接近
B=MAPは、抽象を壊すものではない。
抽象に整合する具体を、確実に動かすための仕組みである。
8. AIによる補助:認知負荷をさらに下げる
ここに生成AIを加えると、GTD+B=MAPはさらに現代的なシステムになる。
重要なのは、AIを思考の代替として使うのではなく、認知負荷を下げる装置として使うことである。
AIが得意なのは、次のような補助である。
| 役割 | 目的 | B=MAP上の効果 |
|---|---|---|
| 分解 | タスクの着手点を小さくする | Abilityを下げる |
| 具体化 | 抽象を動詞化する | Abilityを下げる |
| トリガー提案 | 実行タイミングを提示する | Promptを設定する |
| レビュー補助 | 全体確認を軽くする | 継続負荷を下げる |
たとえば、AIに次のように依頼できる。
このプロジェクトについて、30秒で始められる最初の一手を提案して。
あるいは、
このプロジェクト一覧を、10分レビュー用に簡略化して。
または、
このタスクに対して、実行しやすい固定トリガーを3つ提案して。
AIは、GTDの整理そのものを完全に代行するわけではない。
まして、自分の価値観や判断を代わりに決めてくれるわけでもない。
しかし、タスクの着手点を小さくする、具体化する、レビューを軽くする、という点では非常に有効である。
B=MAPで言えば、AIは主にAbilityを下げる。
場合によってはPromptの設計も助ける。
つまりAIは、「考えなくてもよい仕組み」を作るのではなく、「考える前に詰まらない仕組み」を作るために使うのがよい。
9. 最終整理:GTD+B=MAP+AI
ここまでを整理すると、次のようになる。
---
title: GTD+B=MAP+AIの統合モデル
---
graph TD
subgraph gtd[GTDの領域:何のために何をするかを整理する]
direction TB
horizons[Horizons of Focus]
capture[Capture]
clarify[Clarify]
nextAct[Next Action]
end
subgraph bmap[B=MAPの領域:行動を発火させる]
direction TB
tiny[30秒着手単位]
prompt[固定トリガー]
end
subgraph ai[AIの領域:認知負荷を下げる]
direction TB
decompose[分解補助]
concrete[具体化補助]
review[レビュー補助]
end
action[実行]
habit[習慣化]
horizons --> capture
capture --> clarify
clarify --> nextAct
nextAct --> tiny
tiny --> prompt
prompt --> action
ai --> tiny
ai --> review
action --> habit
比較すると、こうなる。
| 観点 | GTD | GTD+B=MAP | GTD+B=MAP+AI |
|---|---|---|---|
| 整理力 | 高い | 高い | 高い |
| 行動開始 | 人による | 安定しやすい | さらに低摩擦 |
| 継続性 | 意志に依存しやすい | 構造に依存できる | レビュー負荷を下げられる |
| 認知負荷 | 中程度 | 低い | さらに低い |
| 強み | 何をやるかが明確になる | 始めやすくなる | 分解・具体化が軽くなる |
- GTDは「整理のOS」である。
- B=MAPは「行動のエンジン」である。
- AIは「認知負荷を下げる補助装置」である。
より具体的に言えば、GTDは「終わるまで迷子にならない仕組み」であり、B=MAPは「始めるところで固まらない仕組み」であり、AIは8割を引き受けて(…くれたらいいなぁ)本当に大事な2割に集中させてくれる「サポーター」である。これら3つを組み合わせると、タスク管理は次のように変わる。
- 頭の中を整理する
- 次にやることを明確にする
- それを30秒で始められる大きさにする
- 実行のきっかけを固定する
- 分解やレビューの負荷をAIで下げる
- 小さな着手を繰り返す
- 結果として、上位地平へ近づく
おわりに
あなたがGTDに惹かれた理由は、きっと「安心できる仕組み」が欲しかったからだ。
頭の中の混乱を外に出し、信頼できるシステムに預ける。
やるべきことを明確にし、気がかりに追い回される状態から抜け出す。
GTDは、そのための優れた方法である。
しかし、整理されたタスクは、それだけでは動かない。
タスクが動くためには、行動の入口が小さく、実行しやすく、きっかけが必要である。
そこでB=MAPが効いてくる。
GTDが「安心できる仕組み」を作るなら、B=MAPは「動ける仕組み」を追加する。
そしてAIは、その分解・具体化・レビューの負荷をさらに下げる。
GTDは古くなっていない。
むしろ、B=MAPとAIを組み合わせることで、GTDは現代的な生産性システムとして再解釈できる。
- GTDは、何をするかを整える
- B=MAPは、それをどう始めるかを整える
- AIは、その整える作業の摩擦を下げる
整理され、始められ、続けられる。
GTD+B=MAP+AIとは、そのための実践モデルである。