書いてみるタスク管理

まずは、倉下さんの指摘にそって直すことを第一として、その後自分なりに変えたいところがあれば修正しようと思います。

タイトル候補

「書く」タスク管理

/icons/hr.icon

===1 書くことの延長線上にあるタスク管理

物事を扱うのに頭の中だけでいつも完結できるのであれば、それでもよいと思うのですが、その日の調子によっては頭のなかにうずまく感情があったりで、同じ物事を扱うのでも違った考え方や見方（たいていは一方的な見方）をしてしまうことがあります。

そんなときには、日を改めて考えてみるのがよいかもしれません。もしくは今ちょっとだけ脇においておきたい、頭の外に物事を出して扱いたいとき、そんなときには文字にしてみる、図に描いてみる、表にしてみるなどがあります。特に文字または文章にしてみることは、図や表に比べると素早く書き出せて、読んで頭の中に戻すことも容易です。また、後述するアウトラインとして扱うのにも適しています。書くことの延長線上に置いた「書いてみるタスク管理」があると私は考えています。

===2 Atomicなものとして書き出す

文字または文章にしみてるときは、Atomicに書き出すようにします。Atomicというのは、単語として「原子の」「きわめて小さい」という意味ですが、Andy Matuschak氏が提唱されたEvergreen notesというノート術にある「Evergreen notes should be atomic」としての意味に着目したいと思います。ここでは、これ以上分割できないというよりは、むしろ化学元素の最小単位であり、なおかつ下部構造の陽子の数によって原子（元素）が変わるように、最小単位としての要素を切り出すことと、他にも変わり得るものを同時に持つのがAtomicなものと扱ってみたいと思います。

たとえば、「髪の毛を切る」といったタスクについてAtomicなものとして書き出すとき、それは大きなタスクを小さなタスクに分ける分解とはちょっと異なったものになります。

分解

髪の毛を切る

いつ床屋・美容院に行くのか決める

床屋・美容院を予約する

予約した日時に床屋・美容院に行く

床屋・美容院で髪を切ってもらう

床屋・美容院から帰ってくる

Atomicなもの

髪の毛を切る

いつ床屋・美容院に行くのか決める

行くのが面倒くさいので、なにかのついでに行ってこようかなと思う

そういえば、近くに気になってたケーキ屋さんに寄ってみたい

ケーキをごほうびにして床屋・美容院を予約する

どうでしょうか、分解には、足して元の形にもどるという制約が盛り込まれてしまいます。しかし、Atomicなものは「面倒くさい」「気になっていた」「ごほうび」などの足しても元の形に戻らない要素がでています。

このように同じ「髪の毛を切る」でも、Atomicなものとして書き出した結果として、ケーキ屋さんに行くついでに床屋・美容院に行っているようなところさえあります。

===3 自分なりのアウトラインを作る

Atomicに書き出したものをどのように扱うかというと、文字情報を扱っていることを生かしてアウトラインとして操作することができます。アウトラインの基本的な操作としては、『アウトライン・プロセッシング入門』を参照してみてください。頭の中と外で行き来しやすい形にするのには、人のアウトラインにならうより、自分なりのアウトラインを作ることが重要になります。

先ほど挙げた「髪の毛を切る」アウトラインを見てみましょう。前者は、頭の外にある事柄を土台（ベース）にして作り上げ頭の中へと入れておく、すでにあるものを認識するアウトラインとなります。いわば「手順」のような誰が作ってもほとんど同じとなるものです。客観的な事象に基づく事柄を書き表しています。このときの主体はタスクにあり、タスクに関する理解が進むことになります。

===4 リストにあるタスクからの選択とリストにないタスクからの選択を並走させる

Atomicに書き出して、自分なりのアウトラインにしたものは、ノートやリストとして書いて残してみます。そうしたノートやリストの使い所として挙げるならば、日々を過ごす中でやること（またはやらないこと）について使ってみるのはどうでしょうか。以下に挙げるのは実際に自分が書いて残したものの例です。

週末に買い物に行くときに、買うもの、または買わないものを書いて残しておく。

気になった本があったときにタイトルをメモして残しておく。

家族の予定を聞いたときに書き留めておくなど。

ノートやリストを使ってみるときに気をつけたいのは、ノートやリストにしたものからだけやることを決めるものではないということです。せっかく、やることについてノートやリストを使ってみることにしたのに、と思いたくなりますが、やってみるとわかりますが、すべてのやることに対してリストから選択するのは、「言うは易く行うは難し」で意外とハードルが高いです。

最初は、リストにないものから選択することを優先して、適宜ノートやリストに書いて残しておくほうが慣れるまでは破綻しにくいと思われます。そうして徐々にノートやリストができあがってくると、リストがあるからリストにないタスクをやっていても元のタスクに戻ることができると思える状態が生まれてきたりします。リストに「休む」というタスクはなくても休みたいと思えば、休む選択をする。リストにないやることでも必要だと判断したらやる選択をする。そのようにして、リストにあるものとリストにないものとを並走させながらハイブリッドに選ぶようにします。そうして、リストにないものをやったときには再び適宜ノートやリストに書いて残すことを繰り返してみましょう。

===5 既存のシステムと自分のやり方をシェイクする

ノートやリストがただ点在していても、まとまりがありません。まとめるためのやり方にはどんなものがあるのでしょうか。時間が潤沢にあり、車輪の再発明もいとわないのであれば、ゼロから自分のやり方を作ることも可能です。また，そこに楽しみがあったりもします。ですが、もしかしたらそうしてせっかく作り上げた自分のやり方も過去の先人たちに遠く及ばないものかもしれません。もし、過去の先人たちの編み出した既存のシステムにどんなものがあるのか調べてみたくなったときには、うってつけの本として『「やること地獄」を終わらせるタスク管理「超」入門』（以下「やるおわ」）がありますので参考にしてみて下さい。

既存のシステム

GTD

自分←イマココ

マニャーナの法則

GTDからのトップダウンでGTDのシステム内に自分が入ることで、これまでの自分のやり方になかった部分を学び、吸収する格好になります。ただ、残念ながら既存のシステムを知っただけで、自分のやり方として使うことは窮屈で困難なことだと思います。そこで以下のとおり、アウトラインをシェイクしてみます。

トップダウンでの成果とボトムアップでの成果を相互にフィードバックすることで、書きながら浮かんでくるランダムな発想を活かし、有機的に連結していく

自分のやり方

GTD的←イマココ

マニャーナ的

自分（のやり方）をボトムアップさせて、GTDにトップダウンの形をとります。これだと自分のやり方のトップダウンでGTD的なシステムを扱うイメージができそうでしょうか。

GTDを使ってうまくいかないことも出てきたら、もしかするとまだ充分にGTDを学んだといい難い部分があるのかもしれません。そうしたときにふたたびGTDからのトップダウンで自分を位置づけます。こうしたシェイクを繰り返すことで、だんだんと自分のやり方としてGTD的な要素をAtomicに取り入れていくようにします。もしかすると、GTDそのものが自分にとって充分ではない部分があることに気づくかもしれません。

===6 自分のやり方の崩れに気づく

「既存のシステムと自分のやり方をシェイクする」ことで曲がりなりにも自分のやり方でやってみてうまくいくところを見つけることができたとします。でも、うまくいくようになった（できた）のに、自分でそのやり方を意識していないうちに崩してしまうようなことがあります。無理をしているところ、またはあとで無理がたたってくるようなことはないかどうかを確認してみます。

物事は変化していくので、崩れてあたりまえです。これを崩さまいとしたり、崩れたことに失望しているよりも、崩れたものを元に戻すのか、もしくは崩れたやり方のほうこそ本来の使い方とするのかを考えてます。うまくいかなかった（崩れた）ことを「Atomicなものとして書き出す」こと、そしてそれを「自分なりのアウトラインを作る」ようにしてみます。必要であれば再び「既存のシステムと自分のやり方をシェイクする」こともよいでしょう。

気をつけたいのが、「既存のシステム」と「自分のやり方」と比較して崩れている（合致していない）ことよりも、「うまくいっている（ときの）自分のやり方」と「うまくいっていない（ときの）自分のやり方」とを比較して崩れている、崩れてしまった部分に着目するようにします。なぜ崩してしまったのか、崩れないようにするにはどうすればいいのかを自分のやり方に含める（または取り除く）ことを考えます。

===7 ここに書いたことでさえ

これまで書いたことをタスク管理に限定して使うことを考えてタスクをライティングする行為として「タスク・ライティング」と呼んでみましょう。では、このタスク・ライティングをそのままやればいいのでしょうか。話はそう簡単には行きません。それはタスク・ライティングは私にとっては「自分のやり方」でも、人からみれば「既存のシステム」になってしまっているからです。

既存のシステム

GTD

マニャーナの法則

…

タスク・ライティング

自分←イマココ

そこで「既存のシステムと自分のやり方をシェイクする」です。

自分のやり方

GTD的

マニャーナ的

…

タスク・ライティング的←イマココ

「タスク・ライティング」のすべてを取り入れるのではなく、「Atomicなものとして書き出す」ことによって、「自分なりのアウトラインを作る」この繰り返しで、ぜひ自分のやり方を作り上げてみてください。そこまで含めてこそ「書いてみるタスク管理」なのです。

/icons/hr.icon

構成的についての指摘

タイトルが「タスク・ライティング」になっているのですが、その説明が最後まで出てこないので、読み手が「今自分は何を読もうとしているのか、自分の目に入ってくる情報をどのように位置づけていいのか」がわからないままに読み進めることになります。

伏線的に回収したい意図があるなら別ですが、そうでないならば冒頭に「これからタスク・ライティングについて紹介します。タスク・ライティングとは〜〜に役立つ手法です。これからその導入のための手順を１〜６に分けて解説していきます」（文章は適当です）みたいな段落を入れておくと、ぐっと読みやすくなると思います。

副線的に回収したい意図がある場合でも、これからどんな話がここで展開されるのかは早い段階で提示しておくのがよいと思います。全体がそれなりに長い文章の場合は特にそうです。

1. 「本稿ではこういう話をする」を冒頭に置く

2. 身近な具体例を置いて、それを解決するためにこういう方法があるのではないかと私は考えています、のような文章（文章は適当です）を置く

のような（実際は何でもいいのですが）、ワンクッションを冒頭においておくと良さそうです。

いきなり、「タスク・ライティングについて紹介します。」だと、「なにそれ、興味ない」で続きが読まれないように思えたので、伏線的に回収したいと思います。

あと、全体的に一つの文章が長い傾向があります。短く区切るように書き換えると、読みやすさが向上し、それと共に「自分がこの文で何をいいたいのか」がよりはっきりすると思います。

たとえば

>あと、全体的に一つの文章が長い傾向があってそれが読みにくさにつながっているので、できれば一文を短くしていくと読みやすくなりますし、自分が何を書こうとしているのかがはっきりします。

みたいなのが「長い文章」ということです。

そうなんですよね、どうも長い文章になりがちなので気をつけたいと思います。

以下それぞれのsectioncごと

===1 頭の中と外で行き来しやすい形にする

>頭のなか

頭の中、と別表記の部分があります。

一つ目の段落と二つ目の段落の接続がよろしくないように感じます。

たとえば、一つ目の段落の最後に「しまうことがあります。」とあるので、「そんなときには、日を改めて考えてみるのがよいかもしれません」みたいなものがあると接続がよくなりそうです（文章は適当です）。

ようは一つ目の段落で示される状況と、二つ目の段落の説明がうまくつながっていない印象を受けた、ということです。

とりあえず、「そんなときには、日を改めて考えてみるのがよいかもしれません」をそのまま使ってみました。また読み返して変えていくかもしれません。

物事を扱うのに頭の中だけでいつも完結できるのであれば、それでもよいと思うのですが、その日の調子によっては頭のなかにうずまく感情があったりで、同じ物事を扱うのでも違った考え方や見方（たいていは一方的な見方）をしてしまうことがあります。

そんなときには、日を改めて考えてみるのがよいかもしれません。もしくは今ちょっとだけ脇においておきたい、頭の外に物事を出して扱いたいとき、そんなときには文字にしてみる、図に描いてみる、表にしてみるなどがあります。特に文字または文章にしてみることは、図や表に比べると素早く書き出せて、読んで頭の中に戻すことも容易です。また、後述するアウトラインとして扱うのにも適しています。書くことの延長線上に置いた「書いてみるタスク管理」があると私は考えています。

===2 Atomicなものとして書き出す

>文字、テキスト、文章として書き出すときはAtomicに書き出すようにします

sec01の話を継いでいると思うのですが、その感触があまりありませんでした（結構突然出てきた感じがします）。

おそらく、sec01では「文字または文章にしてみることは」となっていて、sec2で「文字、テキスト、文章として書き出す」となっているからでしょう（表記が違っている）。表記を揃えるか、あるいは何かターム（用語）を仮に設定して統一的な表記ができるようにすると、sec01→sec02のつながりがスムーズだと思います。

表記を「文字または文章にしてみる」に揃えてみようと思います。

ターム（用語）も思いつたら設定してみようと思います。

>Evergreen notesの原理

文の途中で急に出てくるので、これを知らない人はびっくりすると思います。

「Evergreen notes」を知っている人しか読まない文章である、という前提を置かれているならば構いませんが、そうでない場合は少し工夫が必要かと思います。

一番簡単なのは、「hogehogeさんが提唱されたEvergreen notesというノート術で用いられている」（文章は適当）のように文の中で解説を入れることです。

あるいは注を入れてもよいでしょう。

他にも先に「原始的」の意味を説明した後で、「この考え方は、hogehogeさんのEvergreen notesにでてくるhogeを参照したものです」と付け加える方法もあります。

「Andy Matuschak氏が提唱されたEvergreen notesというノート術」に書き換えました。

>それはタスクの分解とはちょっと異なったものになります。

ここも「タスクの分解」が一般用語のように扱われています。

まあ、マニアックな人たちが読むであろう雑誌なので構わないと言えば構わないですが、たぶんそんなに一般的な用語ではありません。

「大きなタスクを小さなタスクに分ける」という説明を挟んでみようと思います。

>どうでしょうか、分解には、足して元の形にもどるという制約が盛り込まれてしまいます。しかし、Atomicなものは「面倒くさい」「気になっていた」「ごほうび」などの要素がでています。

前の文では「足して元の形に戻る」が言及されていますが、対比される後ろの文では、「足して元の形に戻る」になっているのかどうかが言及されていません。「しかし」で文をつなぐ場合は、この対比がないと若干不自然です。

「足しても元の形に戻らない」を挟みたいと思います。

>最後のほうではケーキ屋さんに行くついでに、床屋・美容院に行っているようなところさえあります。「急がば回れ」と言ったところでしょう。

これはよくわかるのですが、この説明が「atomic」とどう関係あるのかが見えてきません。このsecはatomicについて解説していると思うので、こうした記述がどうatomicであるのか、という説明があった方がよいと思います。

『このように同じ「髪の毛を切る」でも、Atomicなものとして書き出した結果として』に書き直します。

『「急がば回れ」と言ったところでしょう』はatomicと外れるので削除します。

===2 Atomicなものとして書き出す

文字または文章にしみてるときは、Atomicに書き出すようにします。Atomicというのは、単語として「原子の」「きわめて小さい」という意味ですが、Andy Matuschak氏が提唱されたEvergreen notesというノート術にある「Evergreen notes should be atomic」としての意味に着目したいと思います。ここでは、これ以上分割できないというよりは、むしろ化学元素の最小単位であり、なおかつ下部構造の陽子の数によって原子（元素）が変わるように、最小単位としての要素を切り出すことと、他にも変わり得るものを同時に持つのがAtomicなものと扱ってみたいと思います。

たとえば、「髪の毛を切る」といったタスクについてAtomicなものとして書き出すとき、それは大きなタスクを小さなタスクに分ける分解とはちょっと異なったものになります。

分解

髪の毛を切る

いつ床屋・美容院に行くのか決める

床屋・美容院を予約する

予約した日時に床屋・美容院に行く

床屋・美容院で髪を切ってもらう

床屋・美容院から帰ってくる

Atomicなもの

髪の毛を切る

いつ床屋・美容院に行くのか決める

行くのが面倒くさいので、なにかのついでに行ってこようかなと思う

そういえば、近くに気になってたケーキ屋さんに寄ってみたい

ケーキをごほうびにして床屋・美容院を予約する

どうでしょうか、分解には、足して元の形にもどるという制約が盛り込まれてしまいます。しかし、Atomicなものは「面倒くさい」「気になっていた」「ごほうび」などの足しても元の形に戻らない要素がでています。

このように同じ「髪の毛を切る」でも、Atomicなものとして書き出した結果として、ケーキ屋さんに行くついでに床屋・美容院に行っているようなところさえあります。

===03 自分なりのアウトラインを作る

>Atomicに書き出したものをどのように扱うか、文字情報を扱っていることを生かしてアウトラインとして操作することができます。

「、」が「。」なのか、あるいは「Atomicに書き出したものをどのように扱うかというと」くらいがよさそうです。あるいは二文に切っても。

「Atomicに書き出したものをどのように扱うかというと」とします。

>アウトラインの基本的な操作としては、アウトラインプロセッシング入門を参照してみてください

→『アウトライン・プロセッシング入門』

書名なので二重鍵括弧。

修正するつもりがうっかりしておりました。

>Atomicなものとして書き出すに挙げた

先ほど挙げた、くらいでも大丈夫だと思います。

承知しました。

>前者は、頭の外から中へのアウトラインにあたり、

ここから続く部分が若干わかりにくかったです。

以下のとおり書き直してみました。

「前者は、頭の外にある事柄を土台（ベース）にして作り上げ頭の中へと入れておく、すでにあるものを認識するアウトラインとなります。いわば「手順」のような誰が作ってもほとんど同じとなるものです。客観的な事象に基づく事柄を書き表しています。このときの主体はタスクにあり、タスクに関する理解が進むことになります。

前者と後者との対比で記載しましたが、表の形にしたほうがわかりやすいような書き方になってしまいました。また少し書き方を考えたい箇所です。

===3 自分なりのアウトラインを作る

Atomicに書き出したものをどのように扱うかというと、文字情報を扱っていることを生かしてアウトラインとして操作することができます。アウトラインの基本的な操作としては、『アウトライン・プロセッシング入門』を参照してみてください。頭の中と外で行き来しやすい形にするのには、人のアウトラインにならうより、自分なりのアウトラインを作ることが重要になります。

先ほど挙げた「髪の毛を切る」アウトラインを見てみましょう。前者は、頭の外にある事柄を土台（ベース）にして作り上げ頭の中へと入れておく、すでにあるものを認識するアウトラインとなります。いわば「手順」のような誰が作ってもほとんど同じとなるものです。客観的な事象に基づく事柄を書き表しています。このときの主体はタスクにあり、タスクに関する理解が進むことになります。

===4 リストにあるタスクからの選択とリストにないタスクからの選択を並走させる

一つ目の段落と二つ目の段落の接続がスムーズには感じませんでした。

>日々を過ごす中でやること（またはやらないこと）について使ってみるのはどうでしょうか

とあるので、その使い方の実際例が出てくるのかと予想するのですが、「ノートやリストを使ってみるときに気をつけたいのは」と続くのでちぐはぐな印象を受けます。

「以下に挙げるのは実際に自分が書いて残したものの例です。

週末に買い物に行くときに、買うもの、または買わないものを書いて残しておく。

気になった本があったときにタイトルをメモして残しておく。

家族の予定を聞いたときに書き留めておくなど。」

他にもいい実際例がでてきたら書き直したいと思います。

>リストがあるからリストにないタスクをやっていても大丈夫なときが生まれてきたりします。

それはどういうときなのかの説明、あるいは具体例があるとわかりやすいと思います。

割り込みタスクがわかりやすいかと思います。リストがあるからリストにないタスクである割り込みタスクをやっても元のリストを確認して元のタスクに戻ることができます。

これは、前の文章である「リストに「休む」というタスクはなくても休みたいと思えば、休む選択をする。リストにないやることでも必要だと判断したらやる選択をする」ことが「リストがあるからリストにないタスクをやっていても大丈夫なとき」というつもりで書いていました。

文頭に「このように」を付け足したいと思います。

最終的に全文を通して読み直して修正しました。

>ハイブリッドのように選ぶようにします。

「ように」が連続しているのが少しだけ気になりました。

「ハイブリッドに選ぶようにします」に修正しました。

===4 リストにあるタスクからの選択とリストにないタスクからの選択を並走させる

Atomicに書き出して、自分なりのアウトラインにしたものは、ノートやリストとして書いて残してみます。そうしたノートやリストの使い所として挙げるならば、日々を過ごす中でやること（またはやらないこと）について使ってみるのはどうでしょうか。以下に挙げるのは実際に自分が書いて残したものの例です。

週末に買い物に行くときに、買うもの、または買わないものを書いて残しておく。

気になった本があったときにタイトルをメモして残しておく。

家族の予定を聞いたときに書き留めておくなど。

ノートやリストを使ってみるときに気をつけたいのは、ノートやリストにしたものからだけやることを決めるものではないということです。せっかく、やることについてノートやリストを使ってみることにしたのに、と思いたくなりますが、やってみるとわかりますが、すべてのやることに対してリストから選択するのは、「言うは易く行うは難し」で意外とハードルが高いです。

最初は、リストにないものから選択することを優先して、適宜ノートやリストに書いて残しておくほうが慣れるまでは破綻しにくいと思われます。そうして徐々にノートやリストができあがってくると、リストがあるからリストにないタスクをやっていても元のタスクに戻ることができると思える状態が生まれてきたりします。リストに「休む」というタスクはなくても休みたいと思えば、休む選択をする。リストにないやることでも必要だと判断したらやる選択をする。そのようにして、リストにあるものとリストにないものとを並走させながらハイブリッドに選ぶようにします。そうして、リストにないものをやったときには再び適宜ノートやリストに書いて残すことを繰り返してみましょう。

===5 既存のシステムと自分のやり方をシェイクする

>これだけではまだ十分にGTDを学んだといい難い部分があります。

なぜそうなのかの説明があると良いかも。

「GTDを使ってうまくいかないことも出てきたら、もしかするとまだ充分にGTDを学んだといい難い部分があるのかもしれません」に修正しました。

「もしかすると、GTDそのものが自分にとって充分ではない部分があることに気づくかもしれません」を追記してみました。

>うってつけの本として「やるおわ」がありますので参考にしてみて下さい。

一応固有名詞が最初に出てくるときはフルネームがよろしかろうと思います。

『「やること地獄」を終わらせるタスク管理「超」入門』（以下「やるおわ」）くらいの感じで。

これまたうっかりしておりました。

===5 既存のシステムと自分のやり方をシェイクする

ノートやリストがただ点在していても、まとまりがありません。まとめるためのやり方にはどんなものがあるのでしょうか。時間が潤沢にあり、車輪の再発明もいとわないのであれば、ゼロから自分のやり方を作ることも可能です。また，そこに楽しみがあったりもします。ですが、もしかしたらそうしてせっかく作り上げた自分のやり方も過去の先人たちに遠く及ばないものかもしれません。もし、過去の先人たちの編み出した既存のシステムにどんなものがあるのか調べてみたくなったときには、うってつけの本として『「やること地獄」を終わらせるタスク管理「超」入門』（以下「やるおわ」）がありますので参考にしてみて下さい。

既存のシステム

GTD

自分←イマココ

マニャーナの法則

GTDからのトップダウンでGTDのシステム内に自分が入ることで、これまでの自分のやり方になかった部分を学び、吸収する格好になります。ただ、残念ながら既存のシステムを知っただけで、自分のやり方として使うことは窮屈で困難なことだと思います。そこで以下のとおり、アウトラインをシェイクしてみます。

トップダウンでの成果とボトムアップでの成果を相互にフィードバックすることで、書きながら浮かんでくるランダムな発想を活かし、有機的に連結していく

自分のやり方

GTD的←イマココ

マニャーナ的

自分（のやり方）をボトムアップさせて、GTDにトップダウンの形をとります。これだと自分のやり方のトップダウンでGTD的なシステムを扱うイメージができそうでしょうか。

GTDを使ってうまくいかないことも出てきたら、もしかするとまだ充分にGTDを学んだといい難い部分があるのかもしれません。そうしたときにふたたびGTDからのトップダウンで自分を位置づけます。こうしたシェイクを繰り返すことで、だんだんと自分のやり方としてGTD的な要素をAtomicに取り入れていくようにします。もしかすると、GTDそのものが自分にとって充分ではない部分があることに気づくかもしれません。

===6 自分のやり方の崩れに気づく

これは文章表現ではなく、本稿の論旨に関する指摘（というか疑問）です。

このsecで書かれている「あるやり方をしていてもうまく実践できない状況が出てくる。そのときに元々のやり方に沿わせるのではなく、そうじゃないやり方を考える、ということが、まさに「方法のシェイク」なのではないでしょうか。つまり、sec05で語られる「既存のシステムと自分のやり方をシェイクする」の内容がこのsec06の前半部分で語られることなのではないかと思った次第です。

シェイクはトップダウンでスタートしながらも、ボトムアップの「結果を受けて」トップを変換してしまう試みだと言えると思いますが、タスク管理システムにおける「結果を受けて」は、実践の結果でしょうし、それはつまり「あるシステムをやっていて、それがうまくいかなくなる」という結果も含むでしょう。

逆に言えば、sec05で語られる「既存のシステムと自分のやり方をシェイクする」がどういう行為を意味しているのかが、sec05の段階では不明瞭な感じがします。

上記はあくまで倉下の解釈ですので、ぜんぜんスルーしていただいて大丈夫です。

今回の原稿で一番大きな工事になりそうです。

sec06では、sc05で「既存のシステムと自分のやり方をシェイクする」ことによってうまくいくようになった（できた）のに、自分でそのやり方を意識していないうちに崩してしまうようなことがあることを提示したい意図がありました。

上記のsec05との区切りがわかるようにしてみようと思います

というか、上述のことを書いておいたらいいのかも。

===6 自分のやり方の崩れに気づく

「既存のシステムと自分のやり方をシェイクする」ことで曲がりなりにも自分のやり方でやってみてうまくいくところを見つけることができたとします。でも、うまくいくようになった（できた）のに、自分でそのやり方を意識していないうちに崩してしまうようなことがあります。無理をしているところ、またはあとで無理がたたってくるようなことはないかどうかを確認してみます。

物事は変化していくので、崩れてあたりまえです。これを崩さまいとしたり、崩れたことに失望しているよりも、崩れたものを元に戻すのか、もしくは崩れたやり方のほうこそ本来の使い方とするのかを考えてます。うまくいかなかった（崩れた）ことを「Atomicなものとして書き出す」こと、そしてそれを「自分なりのアウトラインを作る」ようにしてみます。必要であれば再び「既存のシステムと自分のやり方をシェイクする」こともよいでしょう。

気をつけたいのが、「既存のシステム」と「自分のやり方」と比較して崩れている（合致していない）ことよりも、「うまくいっている（ときの）自分のやり方」と「うまくいっていない（ときの）自分のやり方」とを比較して崩れている、崩れてしまった部分に着目するようにします。なぜ崩してしまったのか、崩れないようにするにはどうすればいいのかを自分のやり方に含める（または取り除く）ことを考えます。

===7 ここに書いたことでさえ

たいへん良い内容だと思います。

しまった。タイトルを「書いてみるタスク管理」にしたために、タスク・ライティングとの部分との折衝が必要になりました。

考えます。

案1　最初のタスク・ライティングは生かしておいて、最後の「タスク・ライティング」だけ「書いてみるタスク管理」とする

案2　すべての「タスク・ライティング」を「書いてみるタスク管理」に置き換える

タスク・ライティングを出すと話がややこしくなりそうなので案2にしてみたいと思います。

ただ、既存のシステムであることを表現するには「タスク・ライティング」がよさそうにも思えます。

優柔不断

通しで読むと案2のほうがよさそうに思えます。

===7 ここに書いたことでさえ

これまでに述べたことを「書いてみるタスク管理」と呼んでみましょう。では、この「書いてみるタスク管理」をそのままやればいいのでしょうか。話はそう簡単には行きません。それは「書いてみるタスク管理」は私にとっては「自分のやり方」でも、人からみれば「既存のシステム」になってしまっているからです。

既存のシステム

GTD

マニャーナの法則

…

書いてみるタスク管理

自分←イマココ

そこで「既存のシステムと自分のやり方をシェイクする」です。

自分のやり方

GTD的

マニャーナ的

…

書いてみるタスク管理的←イマココ

「書いてみるタスク管理」のすべてを取り入れるのではなく、「Atomicなものとして書き出す」ことによって、「自分なりのアウトラインを作る」この繰り返しで、ぜひ自分のやり方を作り上げてみてください。そこまで含めてこそ「書いてみるタスク管理」なのです。