00:00
はい、打ち合わせキャスト第52回ということで、今回もゲストにたくさんお迎えしております。よろしくお願いします。
52回というと、一週に1回でいうとちょうど1年のベースなんですけどね。ズレてますけども。
でもそんなになりますかね。
結構長いことをやってますね。
今回はライフハックニュース的なものは特にはなかったかな。
今週は特になかったんで、早速本題なんですけども。
プロジェクトノートについてちょっと考えてみようという話で。
プロジェクトノートって何かっていうと、プロジェクトについてのノートなんですけど、
これも結構、プロジェクトの言葉の流度というか定義が、
結構人によってバラバラですね。
GTDでいうと、単発のアクション以上のものは大体プロジェクトと定義されるはずなんですよね。
会社レベルの仕事でいうと、ちょっと中規模以上の企画みたいなイメージですかね。
まあなんか案件とか。日本の企業で言ってた案件がそのままかっこよくプロジェクトって言うようになったって、
一番多くの会社で当てはまるんじゃないですかね。
小さいレベルの意味のプロジェクトから大きい意味のプロジェクトまでいろいろあるんですけども、
継続的に行うことがまず一つ共通点で。
継続的ってのは要するに1日では終わらないってことですね、おそらくは。
もう一つは終わりがある。が二つ目の特徴かな。
この二つの特徴を備えていれば、大体プロジェクトに定義しても終わらないかなと思います。
そうですね。終わらなきゃいけないってね、プロジェクト。
だからルーティンとか、いわゆる繰り返されるもの、リピートタスクみたいなものは明確な終わりがないんですよね。
だからプロジェクトではないとよく言われますね。
どういう状態が完了なのかと定義できるということですね。
そうですね。そういうものがプロジェクトであると。
先ほど言ったように、1日では終わらないので、情報の引き継ぎが必要になると。
個人レベルで言うと、今日の自分から明日の自分へ。
組織レベルで言うと、共同で動いている人への共有という意味での引き継ぎ。
引き継ぎというか共有というところがいいかな、この場合は。
どちらも一緒なんで。
03:01
パッとやって終われるものは情報の引き継ぎが必要ない。
明日の自分にも必要がないし、他の人にも引き継ぐ必要もない。
でもプロジェクトって呼ばれるものになってくると、何かしらの形で今の自分の存在以外の人と情報をやり取りしないとうまく進まないので、それを管理しましょうというのが、広い意味でのプロジェクトノートだと思うんですよね。
たくさんの中でもプロジェクトっていう定義はご自分でいいんですけど、その関する情報を扱うものって何かあります?
扱うものってのはツール?
保存しているツールですね。
僕はアウトライナーの中に、ALLというアウトラインを作って、そこにやろうと思ったことが全部書いてあるアウトラインがあって、
そこがいわゆるプロジェクトリストに近いんですけど、さっきのプロジェクトの定義に当てはまらない、
1日でワンストロークで終わっちゃうようなものも実はそこに書いてあって、
なので今日やってないやるべきことは全部そこに書いてある。
明日以降の自分に引き継ぐものはそこの場所にあると。
その中にプロジェクトも含まれてると。
さっきの定義でいうと、引き継ぎが必要なものはそこに入れておくという。
そうですね。
そこには、そのALLの中の個々のプロジェクト名の中にある項目には具体的じゃなくて、抽象的にはどんなことが書いてあるんですかね。
抽象的にはそこも決まりがなくて、すごい思いつきレベルのことから、いわゆるプロジェクトとして動いているものもあるので。
動いているものほど具体的になりますよね。
動いているものは、その下に日付をぶら下げて、何月何日にこれについて何をやったっていうのをなるべく書くようにして。
そんなに厳密じゃないんですけど。
つまりログ的なものがまず書かれる。
以前はそういうことやってなかったんですけど、それは千葉さんの影響でやるようになった。
一方では、例えばもっと漠然とした、こういうことをやりたいなと思ったのは文字通りこういうことをやりたいなというレベルで書いてあるだけのものもあるし。
暫定的に言うとアイディアが書いてある。
そうですね。アイディアが、なるべく頭に浮かんだ言葉のまんま書いてあったりとか。
要するにタスクではなくて、Doという言葉を使うようにしてるんですけど、
Doっていうのは、タスクとそのタスクにまつわる思いが一緒二人だったものがDoなので、
思いがそのまま思いとして書いてあったりするんですよね。
06:03
思いがだんだん具体化していくと、最終的にはプロジェクトの姿になっていくみたいな。
綺麗に言うと、そんな綺麗には動かないんですけど、綺麗に表現するとそういう感じですね。
進んでる、今着手しているプロジェクトが何かあったとしますよね。
なんでもいいんですけど。
今日ログこれこれこうしたということが書かれたと。
明確にこういう作業が必要になるということか、こういう作業をしたほうがいいということが発覚したとか、
あるいは共同に作業してる人からこういうことをしてほしいって言われたときに、
いわゆるタスクですよね。
はどこにどう書かれます?
いわゆるログ、その日付の日付の、
例えばクラシタさんと何回会ってて、クラシタさんの発言がタスクだったとしたときには、
その日付の下にまずそれを書きますと。
クラシタさんがこういうことを言ったっていうふうに書いて、
それとは別にプロジェクトに相当する項目の一番上に、
タスクとして、なんとかの記事を整理とかあったとしたら、
タスクっぽい感じで書くんで、2カ所に書く感じですかね。
まあそうなんですよね。
そこは僕はずっと疑問に思ってて。
これがね難しい問題なんです。
例えばそういう過去のプロジェクトとは別に、
デイリーの項目を作っておられると思うんですよね。
デイリーの項目内には、そのプロジェクトに関するものは直接書き込まないでくださいね。
さっきのもっと正確に言うと、
ログって言ってたものがあるじゃないですか。
そこに書かれるのは、実はそれは日付の下に最初、
「Days」という名前をつけてるんですけど、
要するに日々の、何月何日っていう項目を立てて、
その下にその日のやることとか、その日にあったことを書いてるんですけど、
倉下さんが言ったこと、実はそこに最初に書かれるはずなんですよね。
翌日の、新しくその翌日の「Days」の日付の項目を作るときに、
昨日のを見て、あ、倉下さんこれ言ってたのは、例えばRevisionならRevisionのプロジェクトの話だなと思ったときに、
それをコピーして、オールの下のRevisionの項目の下の昨日の日付のところにポコッと移すんですね。
で、「Days」のほうに書いてある「それ」はコンプリートして見えなくする。
検索に引っかかるように残しておく。
カットじゃなくて、こうコピーしてコンプリートなんですね。
それも以前はカットしてたのを、千葉さんの影響で。
千葉さんがそうやってたんですよ、なんか。
なるほど。
だから千葉さんの影響で、日付の下にも残すんだけど、残したまんまだと二重に、
09:08
二か所に書いちゃうことになるんで、日付の下に移したあとはコンプリートしちゃうんです。
そうなんですね。
だからこれ、デイリーベースで作業してる僕たちみたいな人っていうのは、
大体プロジェクトベースの管理手法も平行して走らせてることが多いんですよね。
デイリーだけってことはあんまりなくて。
そうやってると、デイリーとプロジェクトの情報のやりとりが常なる課題になるんですね。
大体は手間が発生するんですよ。
やっぱり先ほど言われたように、二回角とか両方にあるっていうことをしとかないとどうにも落ち着かないんですよね。
そうですね。
あれは僕もいろいろ試したんですけど、
結局これがいいなっていう形にはならないんですよね。
手間の最小化ができないというか。
そうですね。
だからこの場合は、プロジェクトっていうかウォールのほうに書くのをそれほど厳密にしていなくて、
ログとして全てを振り返れるようにしようとは思ってないんですよね。
うんうん。
それをやろうとすると結構大変になっちゃうというか。
厳密にやろうとすると大変なんで。
大体はそっちに移してるけど、まあなくてもないこともあるよね、ぐらいの感じでやってるからできるのかもしれないですよね。
ここで問題となってくるのは、なぜプロジェクトノートを我々は作っているのかっていうところなんですよね、結局。
僕はそれをずっと考えてたんですけど。
どこから話を始めましょうかね。
一つ思ったのは、デイリーとプロジェクトに両方同じデータがあって、片方見えないんですけど、データがあるっていうことは、
僕の言い方で言うと、AでありBであるっていう状況が多分担保されてるんですよね。
つまり同じ情報がデイリーの1日のその日の行動として残りつつも、プロジェクトの一つの記録としても残っているという状況をコピペで実現してると。
できればデジタルデータなので、それをコピペじゃなくて実現したいなと思う。
プロジェクトにあるタスクも、いちいちコピペしてデイリーに持ってくるんじゃなくて、プロジェクトにあるままにデイリーから参照できたらきっと便利だろうなと。
そういうときにロームリサーチとかの他のページの項目をエンベッドできるみたいな機能がありまして、
12:04
ああ、こういうのってまさに欲してたものだなと思ったんですけど、結局あんまりうまくいかないんですよ。
でしょ?
うまくいかない理由が結局わかったんですけど。
たくさんの言い方をすると、それはタスクで書いてるから。あれはDoで書かないとダメなんですね。
そこの管理が僕は甘かったからうまくできなかったんですけど。
これがここからの問題なんですけど、今僕ほとんどプロジェクトノードっていうの作ってないんですよね。ほぼデイリーなんです。
デイリーのみ。
デイリーのみなんですよね。
何かのデイリータスクリストというよりも、デイリーログも兼ねてるんで、これはなんて呼ぶんやろな。
デイリーリスト?
いやでもリストじゃないもんな。
ダイヤリー?
そこはダイヤリーって言うんでしょ。
頭のほうにやるべきことのリストがあって、その下に、今日やったことを時系列で下に追加していくっていう形なんですよね。
要するに手帳の1ページに近いかな。
上のほうに3つくらいトゥードゥーランがあって、その下に1ページ分があるみたいな。
印象としてはあれに近いんですよ。
僕もデイリーとプロジェクトが分かれてたときも、だいたい最初にデイリーに書いてたんですよね。
デイリーに書いた後にプロジェクトに移すみたいなことをしてたんですよ。
やっぱり最初に書くならデイリーのほうがいいんですよね。
移動が必要ないからなのか、やっぱり自分がこのタイムラインにいるっていうことがわかるからなのか、理由はわからないですけど、やっぱりデイリーに書きたいよね。
でもそのまま今はデイリーに書いてて、例えばリビジョンズ、コロン、開業って言って作業記録をどんどん書いていくんですよね。
別の作業するときになったら別の作業名を書いて、コロンって書いて、書いていくんですよね。
ずっと繰り返して1日が終わるんですよね。
プロジェクトノートの役割として、前回自分が何をやってたかを振り返りたいという役割をしてたときに、
結局全てのデイリーの日付ごとのファイルをグレップして、さっき言ったリビジョン、コロンで検索すると、
検索結果って、プロジェクトノートと同じ情報がほぼ表示されるんですね。
ほぼ。
これと、この検索結果と、これまで自分が作ってきたプロジェクトノートって何が違うんだろうなと、
使い続けてずっと考えたんですよ。
ほぼ一緒やなと。
15:00
ほぼ一緒やけど、唯一違いは検索結果はアウトライナーと違って、項目を後から移動できない。
後から移動できないぞっていうことは、ログでは困らないんですよ。
当たり前ですけどログは動かさないんですよ。
動かさないほうがいいですね、ログはね。
だからただログを見たいというだけであれば、わざわざ作る必要はないと。
僕みたいにデイリーベースで記録を残してる人は、そこに書くのがさっき言ったように自然なので、
プロジェクトで作る場合って結局コップペなりなんなりがいるんですよね。
その作業は別にいらない。
プロジェクトノートでしかタスクを管理してない人は、もちろんそれはそれでいいんですけど、
デイリーベースプラスプロジェクトっていう二つの体制であるならば、
デイリーを検索できたら、過去のログを振り返る目的としてのプロジェクトノートは別にいらないなっていうのが、
一つわかったことなんですよね。
で、これは結構大きな発見で、
これってプロジェクトノート以外にも言えることと言えないことがいろいろあるなと思ったんですよ。
で、タスクの話も以前したかな。
結局タスクっていうのもデイリーの中に埋め込んでおけば、
そのタスクの項目だけを抽出できたら、タスクリストも別に必要ない。
ほとんど。ほとんどっていう保留がつきますけど、ほとんど必要ないんですよね。
で、これはかなりデジタルベースの考え方だなと思うんですよ。
プロジェクトノートを先に作ってしまうっていうのは結構アナログ的な考え方だと。
だからデイリーベースで進めていって、
例えばプロジェクト名って作業記録以外にも、
普通の文中にも多分出てくるじゃないですか。
なので区切りのコロンを入れて、これが見出しの扱いですよね。
コロン付きで検索したら必ず作業したものだけが抜粋される状態ができるんであれば、
あえて作る必要はないと。
で、もう一個このやり方で抜け落ちてしまうのは、
先ほどたくさん言われた、頭にタスクを持ってくるっていうやつ。
これだけはできないんですよね。
なぜならばタスクを書いてもいいんですけど、
書いたところで、さっき言った順番の入れ替えができないんで。
結局その役割ってそこにあるんですよね。
その順番を入れ替えることに。
上に書くっていうことは。
まず上に書くっていうこと自体が、
その順番、位置の力を使ってますよね。
基本的には。
それができない。
それがどれくらい必要なのかっていう検討は必要やけども、
もしそれが必要ないのであれば、別にいらないなと。
18:03
で、今結構その形になってますね。
特に困ってもいませんね。
だから情報としてそこの書かれたものが出てくればいいのであれば、
おそらく必要ないんですよね。
その独立したリストっていうのはそういう意味では。
だから独立したリストっていうのは、その中身を操作するために作ればいいんで。
操作が不要なものは、ほぼ検索で頼って問題ないなっていうのが、
今のところの発見というか、結構大きい発見ですね。
それってたぶん、感覚的には誰もがわかってるんだけどなんとなくやらないというか、
そのことを真剣にあんまり考えてみた人が、
さほどたくさんはいないっていうことかもしれないですよね。
「作ってもいいじゃん」っていうのはあるんで、
「検索じゃなくて作ってもいいじゃん」って言われたら別に僕も作ったらいいですよって思うんですけど。
これってデジタルベースの発想になったらこうなるなっていうのはあるんですよね。
だから倉下さんはコロンをつけて、キーワードと合わせてグレップすることで、
擬似的なテンポラリーなリストができるという使い方ですけど、
それを持ったグレップって何やねんっていう人にも使えるように実装された機能というのが実はタグなんじゃないかと思うんですよね。
タグなんですよね、それ結局やってることは。
そう、まさにタグなんです。タグなんです。
タグで、既存のツールやと、特にエバーノートやとグレップのように表示されないんで、
後々ログを辿るのがめんどくさいけども、グレップなら簡単にやってくるんですよね。
エバーノートはどれだけタグをつけたところで引っかかるのがノート単位になっちゃうんですけど、
それこそフロイとかダイナリストだと、もう本当に共単位でタグをつけるので、
グレップしたのと極めて近い結果になるんですよね。
そうですよね。だからアウトライナーでやってみると、
デイリーの中に作業項目をハッシュタグつけて書いて、その下に書くことで、
プロジェクトノートの代わりにするということになりますね、この場合は。
やっぱりそうすると、さっき小田下さんが操作と言いましたけど、
要するにデジタルなんだけど、それを言い換えしつつアナログ的な扱いをしたいときには、
たぶん何か分けてそこのつくんなきゃいけないんですよね。
それはそうやと思います。
なぜなら分けるということ自体がアナログ的な操作だからですよね。
そうそうそう。そうです、まさに。
自分は極めてアナログ的な使い方をしてる。
わかってたんだけど確かにアナログ的な使い方をしてるんですよね。
いやでも直感的に使うとそうなるんじゃないですかね。
21:02
僕だってここ10年ずっとプロジェクトノート型でやってきたんで。
そうですね。今考えたんですけど、じゃあそう言われてみると、
ALLがなくてもひょっとしていいんじゃないかと思って今考えたんですけど。
要するにALLっていうのは、プロジェクトリストでもあるし、
GTDでいうところのサブデイリストみたいな、いつかやることリストでもあるし。
なんとなく忘れたくない思いつきリストでもあるし、
企画とかアイデアリストでもあるしっていう、そういうの全部兼ねてるんですけど、
なんで兼ねられるかというと、アナログ的に位置を動かすからなんですよね。
最近触ったものとか、最近考えたものは上に動かす。
デジタルだと、更新したものは自動的に相当されて上に行くみたいなことってデジタル的なんですけど、
更新したけど上に行ってほしくないものとかあるんですよね。
あります。
逆に更新してないんだけど、これ考えてみて上がいいなって、上に動かしたいものもある。
そうするとやっぱり、アナログ性というものがどうしても必要になってきちゃって、
それを実行する場所が多分モールになっているということだと思うんですよね、ジェムの場合は。
まさにそうですよね、きっと。
そうですね。だからやっぱりキーワードは「アナログ操作」。
だから非アナログ的になると、デジタル的になると、何がいいのかというと、
そのような一覧を一旦抜けられるんですよね。
そういう操作のメリットもありつつもデメリットもあって、
操作可能な項目の数がどうしても上限があると思うんですよ。
で、やりたいことリストが膨れ上がってしまう問題みたいなことが起こると。
で、この方式だと別にいいんですよ、どんだけ増えても。
自分がそのキーワードを覚えてさえすれば、いくらでも遡れるし放置してもいい。
だから、一個しかない項目があっても、100個項目があっても、別に変わらないんですよ、こっち側やることって。
そうすると、例えば、プロジェクトがどんどんトンドしてもいいんですよね。
これはどう言ったらいいかわからないですけど、
つまり、リストを作ってやることの優先順位と言っても違うな、
やりたいことを並べて可視化しておくっていうことをすると、
その方向に向かって進みやすいっていうのはあるんですけど、
逆に言うと、それをしなくてもいいというか、どういう点かな。
そういう、今日やりたいことをやればいいっていう感じになれるんですよね。
24:05
いや、それは会社員ではまずい考え方なんですけど。
その時に自分がやりたいことをただやるっていう。
その時に、前回着手した日付がいつであろうが全く関係がないんですよね。
そうですね。
普段細かくリストをいじってると、下の方に行ったり消えてしまったりするものでも、
ごくフラットに扱えるんですよね。
ここが良さでも悪さでもあるというか、方向性が弱くなるっていう言い方ができるんですけど、
その日の気分で作業するんで。
その代わり、抱えておける案件がリストの上限より広がるんですよね。
だからいろんな細かいことを分散的に気まぐれにやる人にとっては、こっちのほうがいいです。
たぶんそうだと思います。
気合を入れて、この期間これするっていうタイプの場合はリスト管理のほうがタイプ。
デジタルによって拡散型の人が初めて適切な管理方法を手に入れられたのではないかという話が、ここでもポイントで。
まさにフリーランス的な仕事の仕方にフィットするのではないかと。
ちょっと大げさな話ですけど、そういう仕事の仕方を根本的に変えるというか、
仕事の仕方ってプロジェクトの着手の力学を変えるというか、
そういうことが可能になる。リスト管理から解放されると。
そうですよね。だから例えば従来だったら、従来のリストを作っていた場合だと、
これはもうとっざしたプロジェクトだと判定されていたはずのものが、
残っていてある日浮上するってことがあるわけですよね。
そうそう。
でも自分の中で「あ、あれしよう」って気持ちの高まりとともに書けばいいんですよね、その作業記録に。
何してたかは、過去の自分が記録を残してるはずなので、
それを検索すれば、立ちどころに、立ちどころにって大げさですけど、見つけられると。
これは本当に実験として、僕って結構興味に波があるんですよね。
一ヶ月ぐらいすごいメモツールをプログラミングしたと思えば、
すごい本を買うごとに夢中になることもあれば、ずっと本を読んでる期間もあって、
あんまり文章を書くことは毎日してるんですけど、それ以外が結構揺れてるんですよね。
そうすると、リスト的なプロジェクト管理だと、結構コロコロ切り替わる。
上位にくるものが切り替わっちゃうんですけど、それをしなくてもいいと。
27:02
で、一ヶ月ぶりにコードを書こうってなったときに、
やっぱそのとき、書こうってなったときは気持ちが高まってるんで、やる気が湧くんですよね。
で、過去の記録を振り返ると、あーそうそう、これしてたって言って、すぐに復帰できるっていう。
プロジェクトリストが優先順位が入れ替わってると、やっぱその上がったモチベーションがうまくかみ合わないんですよね。
昨日の自分は、プロジェクトBを進めようって思って優先順位を決めてたと。
ある日の僕はプロジェクトAをすごくやりたいと。ここがかみ合わないんですよね。
リストが提示する優先順位と僕のやりたい気持ちがかみ合わないんですよね。
別にかみ合わなくてもかまわないんですけど。むしろだから、仕事としてはBをやらなきゃいけない方はBをやれって話で、
それはこれまでのマネージメントだったと思うんですけど、そうじゃないやり方も今ちょっとできつつあると。
で、その際に一番重要なのが、作業記録を書いておくってことなんですね。
これを書いておかないと、さっきの復興は不可能なんですよ、これ。
物の見事に忘れてるんで。
作業記録で、これこれこういうことをしました。
次はこうしたほうがいい。
そのためには、例えばこういう工夫がありそうだとか、ここのページを見たらいいってことを書いておく。
これを書いておくだけで、魔法のようにその時の自分に戻れるんですよ。
それと対比すると、プロジェクトノートにタスクを書いておく方法は全く無理なんですよね。
これね、本当にね、何回もたびたび経験してるんですけど、
半年ぐらい放置してたプロジェクトノートを見て、上にタスクリストがあって、
全くその行動はわかるんですよ、それぞれの行動は。
ただ、それをする気持ちが復元されないんですよね。
これはやっぱりルーが欠損しろがあるんですよね。
この話はメールマガジンに書いたんですけど、
メールマガジンに書いて感想のメールを、とある響さんという方がいただいたんですけども。
タスクってどう言ったらいいんかな。
表現が短い。宣伝されてるっていうか、切り詰められてるじゃないですか。
それは情報不足じゃなくて、むしろ情報量が多いっていうことを言われたんですよ、響さんが。
つまり、僕の解釈からすると、
そうやって結局、書かれてる文字が短いほど、文脈がいくらでもあり得るじゃないですか。
文章にすればするほど意味が限定されますよね。
だから、そのとき、今読んだ自分がそのタスクを解釈してしまって、
30:01
そのとき、昔の自分が書いたことじゃないように読み取ってしまっているんではないかと。
まあそれは確かにあるかもなと思ったんですね。
で、やっぱり文章の形で書けば書くほど、
そのときの自分の気持ち、doが乗っかるんで、復元しやすいんだろうなと。
ここまでの話を合わせたら、日々の作業記録をとっておけば、
プロジェクトノートっていうのは8割5分いらない。
操作したいものについてはもちろんリストを作ればいいんですけど、
そうじゃないものはあえてリストかノートか別にノートとして切り出す必要は、
必然性はそんなにはないだろうなっていうのが今のところの感触ですね。
今聞いてて思ったんですけど、
doっていうのは要するに、タスクとそのタスクに関する行動に関する思いが合わさったものがdoだと定義したときに、
doを意識して書く限りは、記録も、要するに過去のことを記録する。
記録も未来のことを書くタスクリストなり、プロジェクトノートなり、ほとんど違いはないというか。
結局、プロジェクトリストなりを作るということも、考えようによっては、
このプロジェクトをこれからこうしようと今日思ったという記録なわけですよね。
そういうことです。まさにそういうことです。
そう考えるとどっちも全ては記録だと考えて……。
あ、そういえば佐々木さんがそんなこと言ってた気がしますけど。
タスクリストも記録だと佐々木さんは言ってた気がしますけど、確かにその通りですよね。
うん。だから、アイデアメモもタスクだっていうのとは逆位相で。
結局だから、頭の中に起きた、発生したものを書き留めているし、
そのメモは後で処理されなければならないからタスクだっていうことで、
結局その2つって変換可能なんですよね。
ツールの便宜的に分けてるだけであって、情報としての根源としては一緒なんですよね。
だからどこにハサミを入れるかっていうだけの違いでしかない。
で、やっぱりこれこれこうしたっていうことで書いておくと、
例えば読み返したときに、1ヶ月後の自分が読み返したときに、
1ヶ月前の自分が切り出したタスクとは別のタスクが切り出される可能性が存分にあるんですよね。
例えばプログラミングやったら、新しいコードの書き方を知ってるから、
こうじゃないなっていうのがわかるみたいなことですよ、簡単に言うと。
だから、タスクの形で切り出されたものは切り出されてるので、
なんて言うんだっけ、そのときにスナップショットが効果があるのは。
33:03
だから、タスクの取り扱いって消費期限が短いって言い方がいいかな。
だから原本というか、タスクの元になったルーというか思いのほうを保存しておいたほうが良い。
そういう意味では、タスクっていうのは消費期限が短い。
何のためにタスクリストってあるかっていうと、チェックして消していくためじゃないですか。
うんうん、そうですね。特にレイリーとかそういうのね。
タスクってのはチェックしやすいように書かれてるわけですよね。
うんうん、たしかに。
何をするかという、思いというか考えというのは、おそらくタスクリストの形ではなくて、
もっとモヤモヤっとしてて、これこれこう思ったんでこうしたいとか、
そういう、いわゆる、例えば「なんとかプロジェクトの第三章をチェック」みたいな、
そういうふうに書かれるものではないんですよね。
うんうん、そうですね。
だから、タスクリストは、やることについて考えたことのうち、
やったことを確認、チェックして確認、これは確かにやったぞってチェックして消していくために切り出したものっていうことなんでしょうね。
うんうん、たしかに。そういうことなんですね。
その背後に思いがあるっていうことさえ忘れていなければたぶん大丈夫なんですけど、
だからタスクリストとか、タスク管理っていう言葉の一番狭い領域だけで考えてしまうと、
やりきれないものが残ってしまうというか。
おそらくなんですけど、タスク管理の文脈において、なぜ背景にあるものがそぎ落とされてきたかというと、
もちろんツール的な制約もあると思うんですけど、
一番の問題は、組織の中で割り振られるタスクって、
関係ない。
ルーは関係ないですよね。
関係なくてやらなあかんっていうことなので、
土台としてそれがないままにタスクという情報を扱うための手法が確立されてしまったのではないかと。
タスクをアサインするっていう言い方が近年にさりこんでされるようになったんですけど。
ものすごい嫌いな言葉なんですけど。
アサインしてもいいんですよ、ちゃんとね。
ただタスクをアサインするということは、
アサインする側、要するに上司なり何なりが部下にタスクをアサインするんですけど、
その上司の中にルーがなければいけないんですよね。
上司だけじゃなくて、要するに会社の中に企業の中にルーはないというよりも、
36:08
本来は企業がそのルーを持ってなきゃいけなくて。
企業理念とその理念を踏まえて、この契約なり受けた仕事なりを自分の会社としてどうやるのかと。
理想は企業としてのルーがあり、それを受けて管理職のなんとかさんのルーがあり、
そのルーに基づいて部下のなんとかさんにタスクをアサインするというようなのが理想なんでしょうけども、
大体はそうなっている。
まあ規模が大きくなると不可能なんですよね、きっとそれは。
あわさん、階層が深くなると無理なんですよね。
これもおそらく本来の機能通りに機能していることはほとんどないでしょうけど、
企業理念みたいなものが、昔は応接室に飾ってあって、
今はサイトの「about us」みたいなところに書いた絵の下に「私のミッションは」みたいなことで書いてあるような、
あれとそこで働く人のそれぞれのルーがすり合わされて、別に一緒にする必要は全然ないんですけど、
その中でそれを踏まえてどうするのかがすり合わされて、それがタスクに反映されていくというのが理想の姿なんでしょうけども、
なかなかそうなってないということなんでしょうね。
なってないですね。
だから階層が深くなると、断絶が生じるのかバケツリレーが生じるのか何かわからないですけど、
深い階層のほどそれは実現されないんですね。
実現されたらされたて、またちょっと別の盲目的にそこの企業のあれに染まっちゃうみたいなことは、それはそれで問題ではあって。
でもそれがさっき言われたすり合わせるっていうことが、その階層ではないかと僕は思うんですけども。
そのまま鵜呑みじゃなくて、理念は理念として、現実は現実として、自分ができることは自分ができることとして、
この三角形の中で何をするかを考えていけば、カルト的な感じにはならないのではないかと思うんですけど。
で、企業マネージメントの話と個人マネージメントの話は、僕は常にこうしてると思ってて、
ブラック企業の話ってセルフマネージメントにも多分入れるなと思うんですよ。
39:00
自分自身をブラックに扱ってしまう人って結構いると思うんですよ。
さっきの話で言うと、企業の理念と個人のdoをすり合わせるって話で言うと、
個人のビジョンってあるじゃないですか。ビジョナリーというニュアンスのビジョンと実践のdoもやっぱりすり合わせたほうがいいんですよね。
これはリビジョンズの話なんですけど。
だから自分の立てたビジョンに盲目的になってはダメなんですよね。
ここがね、難しいとこなんですよ。
ビジョン、僕は少なくともその七つの習慣的な意味での高いビジョンというか、
将来に向けて何かを掲げる的なことは大切やなと思うんですよ。
あれを全面的に否定するのは間違ってると思うんですよ。
かといって、やっぱりあっち方向に進みすぎるのも問題やなと思うんですよね。
その塩梅がどこにあるかっていうのは、今話を聞いて思いましたね。
このすり合わせるっていうところを聞いて、ああそうやなと。
自分のビジョンは企業のビジョンと同じように扱えばいいんではないかっていうのはちょっと。
すり合わせが一番難しいのであって、そこに触れないとたぶんダメなんですよね。
だからやっぱり、どうしても七つの習慣自体は非常に素晴らしいと思うんですけど、
あそこに出ているミッション・ステートメントの見本みたいなものが、
やっぱりどう考えてもあれは立派すぎる。立派であっても全然いいんだけれども。
やっぱり多くの人の人生の実感とはそぐわないものになってしまっていて。
だけど七つの習慣が素晴らしければ素晴らしいほど、ああいうのを書かなきゃいけないと思って、
ついああいうのを書いちゃうと当然そうはできないわけですよね。
だからやっぱりダメだって思う人が出てきちゃうんだけど、たぶんそういうものじゃない。
でもだからといって、そういうものなしに、
いわゆる今ってぶっちゃけるということが何かいいことのように扱われる。
もしくは人間ってそうじゃん、人から向けばこうじゃん、みたいな。
そういう方向に行っちゃうけれども、
やっぱりフリーライティングしてると、恐ろしいほどいいことを書いて、立派なことを、
人に立派に見せようという意図じゃなくても、
恐ろしいほどいわゆる立派なことが出てくることもあれば、
それとその次の行にものすごくひどいことが出てくることもある。
両方が自分だということなんですよね。
はいはい、そうですね。
両方あることを踏まえて、
ビジョンという言い方でもいいし、ミッションでもなんでもいいんですけど、それを描いて、
42:00
両方ある自分を抱えてどう生きていくかというのが、どう生活するかというのが、
最終的には一番下まで降りていくとタスクになるんだと思うんですけど。
まあ、いろんな人がいたから、どう生きるかという話になるわけですよね。
そうなんですよね。
だから僕のリストって、リブ構成になってて、
頭にデイリータスクリストがあって、その下にログなんですけど、
一致しないんですよね、完全に。
完全に一致することはほぼバレなんですよね。
これがこの「乖離」なんです、要するにね。
で、これが表すことが2つあるっていうことなんですよね。
上に掲げるものと、実際に下に起こることっていうのは違う。
でも、だからって上がいらないっていう話には僕は絶対ならないと思ってて。
僕やってて思うんですけど、
デイリータスクリストを作るときと作らないときの一日の動向って間違いなく違うんですよね。
例えば僕、最近テンプレートっていうのあんまり使ってなくて、デイリータスクリストで。
以前は決まりきったテンプレートをコピーして使ってるんですけど、
それを使わなくなると、コンビニブログの更新がすっかり忘れられることが多いんですよ。
あれほど毎日更新してるのに。
デイリータスクリストに項目が載ってるときは、たぶん項目を書かせたことはないんですよね。
あれ、5分ぐらいしか書かれてませんし、
いわゆる認知資源の使用量が、Rスタイル書くのに50が足したら、あれ1ぐらいしか使わないんで。
瞬間に戸惑うことがない。着手するのに戸惑うことはないですね。
もう書いたらやるっていう感じなんですよ。
そのような簡単なことでも、毎日繰り返してても、デイリータスクリストになかったらやらないことがあるんですよね。
絶対にやらないわけでもないんですけど。
だからやっぱりリストが促す行動っていうのはあるんですよね。
変えてしまうものがあるんですよ。
で、変えてしまったことが良いかどうかはリストを保証してくれるんですね。
コンビニブログを毎日更新したら僕の得が上がるとか、天国に行ける保証はどこにもないですけど、
ある日の僕が毎日更新したほうがいいと思ってたビジョンを実現させる力は確かにあるんですよね。
だから、未来を向いたリストを作ることと、実際にやったログを積み重ねる。
この二つをやっていくっていうのが、実はダスク管理というかセルフマネジメントのコアではないかなと。
ここにプラスアルファはいくらでもできますけど、
たぶんこれを抜いたら何も身のあるものはできないんではないかなと個人的には思うんですけども。
でも両輪が必要ってことですよね。
両輪が必要ですね。両輪が必要だと思いますね。
現実的にデイリータスクリスト、1日の上にあるやつも作らなくていいはずなんですよ、原理的には。
45:06
検索して未着手のタスクをするってことだけにすればいいはずなんですけど、やっぱりしないんですよね。
なぜかというと並べ替えたいからなんですよ。
やりたいことを上にして、やらないことは下にするっていう操作をしたいからなんですよね。
ログは操作しなくていいし、ビジョンは操作したいっていうこの二つの違いと、
デジタルツールならではのことっていうのが最近わかってきたなっていう。
だからやっぱ操作したいってのは何かしらの意思の表明ですよね。
意思を、そうですね。同じ言葉で言う。意思を加えたいってことですね。
なんで意思を加えるのかというと、あれはどうなんだろう。
自分に対してそれを表明したいからなんですかね。
こういうこともあるんじゃないですかね。
やっぱり並び替えたいんですよね。
ある種の支配ではあるんですけど、領土化というか支配ではあるんですけど。
余計な操作と言われるよりも、もしかしたら余計な操作なんかもしれないですけど、
ある種のしっくりきたい感じっていうのは、その操作を経ないとなかなか得られない。
デビューターレンがストレッツフリーの政治図の中で、
大切なのは見通しとコントロールだと確か言ってましたけど、
コントロールに属する行為だと思いますね、順番を入れ替えたりするのは。
リストで一覧することが見通しを得る。
だからリストを作って操作するっていうのは根本的な要素なんだよね。
デビューターレンをあんまり入れ替えてる印象ないですね。
うーん、やっぱりアナログとの。
順番を並べてる印象はデビューターレンにはないですよね。
言及したことはたぶんないですね。
リストを見たらやるべきことがすぐ明らかになると思われたので。
デビューターレンは、やりたいこと、プロジェクトについて次のアクションをとりあえず全部考えておいて、
その次にやることをコンテクストでなるべく変える。
だからコンテクストに立てはめに位置づけていくのが、なるべく変える理想とするのかもしれないですけど。
いやー、でも結構微妙じゃないですか。
それはさっき言ったようにテンポラリーリストに近いもので、コンテクストに沿わせるっていうのは。
そのコンテクストリスト、ネクストアクションリストを見てみたら、自分が次に取り掛かることは、
直感的にわかるかもしれない。そういう表現をされてたので。
わかんないですよね。
48:00
あるいは直感的にわかるんだけど、やらないとか。
やらない。
確かにそう、操作の話。
操作の話はね、実はあんまり、
優先順位、星マークをつける話はたまに出てきますけど、
タスク管理全体で、タスクを順番を入れ替えましょうっていう話をしてるのは、
たぶんほぼないんじゃないですかね。
そうですかね。そんなことはないような気もするけど、じゃあ誰が言ってるんだというか、
自分は言ってるけど、あんまり思いつかないような気もしますけどね。
そもそもその時代のタスク管理理論がアナログベースの話になってるんで、
今日やることを選びなさいっていうのはまずよくあるじゃないですか。
6つぐらい選びなさいとか、リストを作りなさいとかあって、
カエルを食べてしまえみたいなやつは、一番難易度高いものから取り掛かれって言ってますよね。
で、えーっと、名前忘れた。
なんとかのなんとか専門では、ABCの優先順位つけなさいって言ってるんですよね。
これも説明が不要だと思うんですけど、こういう話はよく聞くんですね。
これは結局入れ替えるというよりは、要素付けをしてるだけなんですよね。
選んでる、そうですよね。
だから選んでるって位置があります。
入れ替えてるわけではない。
で、思い返すと、ポモドールでもないし、ロワッカーも言ってないし、
いや多分ね、言ってないところですよ。
入れ替えなさい、リストを作りなさいまでは言いますけど、
入れ替えなさいはたぶんタスクさんしか言ってないじゃないですかね。
どうなのかな。
そう、優先度じゃないんですよね。
優先度じゃないんですよね。
優先度じゃないです、これは。
何を先にやるかを優先度と捉えれば優先度なんだけども、
重要度じゃないことは確かですよね。
そうですね、重要度では全くない。
もちろん流れに近いか。
だからタスク集とは多少それに、でもあれも並べてるけど、
入れ替えなさいっていうんじゃないかな。あれ好きに取り掛かっていいですよとは言ってますけども。
運用の仕方によっては近くなるのかな。
リストを入れ替え…。
でもまあ、方針としてリストを作って入れ替えることで自分の意思を反映しましょうみたいな話ではないですね、きっと。
だからやっぱりデジタルベースでないと、
アウトラインはアウトライナーによって初めて生きるって話と一緒で、デジタルベースで考えないとそれってあんまり出てこないんじゃないですかね。
だって書いたリストは消すか消さないかしかアナログの場合はないので。
そういう意味ではアナログで言うと、実は野口幸男さんが、
51:06
コピー用紙の失敗したやつを切り刻んだメモ用紙に書いてそれを順番に並べてホチキスで飲めるみたいなことを言ってて。
それを打つと、例えば小雑面法みたいな感じで、紙に一件ずつ書いてある。
並べ替えてっていうか机に広げてじゃなくて、重ねる順番を変えてるみたいな運用を無意識に。
結果的にやってた人って結構いるような気がするんですよね、昔から。
カード法はそうだよね。確かね、ポイックやったかGTD+Rやったかは忘れたけど、
タスクを一枚カードに書いて、それを集めて、デッキを作って、実行中に並べなさいって言ってたのはありましたね。
だからやっぱりリストというよりはカード型?これ適切な言葉が思いつくけど。
リストじゃなくてカード型の場合はその発想がね。
だから順番の自由に並べ替えるってのは結局アナログでやろうとしたらカードにならざるを得ないわけですよね。
あ、あと一つ。
そういうこと?
トゥードゥーボードですよ、そういえば。
あの細い付箋を順番に。
トゥードゥーボードは付箋を使うんでしたっけ、あれ。
ああ、そうですね。
そうそう、順番に並べていくっていうやつですよね。
まあね、近いといえば近いのかな。
なるほど。確かに。
まあでも付箋の問題はログが残らないってことなんですね。
そうそうそうそう。
あれは便利なんですけどね、ログ管理としてには使えないっていうのがあって。
だからログとして見れればいいものと、リストとして扱って管理して操作するものっていう二つの違いがあるなと。
これはデジタルで情報扱うときに覚えておいたほうがいいことなのではないか。
ツールの使い分けで迷ったときとかには、一つの指針になるんではないかなと思うんですよね。
そうですよね。
まあでもとにかく、いわゆるタスク管理アプリで項目の並べ替えが自由にできないっていうのはやっぱりアウトだと思うんですよね。
実は結構あるんですよ。
うーん、ありますね。はい、ありますあります。
だから上からやっていくべきっていう強い意志があるかもしれませんけど。
まあこの辺は全然発展途上の分野ですね。
だからいまだにテキストファイルのほうが使いやすい場合が多いっていうのが、ツール開発が負けてる気持ちですかね、基本的に。
54:07
これを言うともしかすると怒られちゃうかもしれないですけど、ツールを作る人がデータベース的な発想をしてしまったりとか。
もちろんデジタルの強みを生かすにはもちろんそれは必要なことなんですけど。
やっぱりタスク管理もそうだし、文章を書くみたいなのもそうなんですけど、ちょっとそれとは違うっていうところがあって。
ただちょっとそれとは違うと思っている自分が逆に、ツールを開発する人にうまくそれを説明できないっていうところがあって。
もしくは自分が作れれば一番いいんですけど。
それはやっぱりあらゆる分野で起こるというか。
だからやっぱり、それこそVS Codeとかもそうですけど、
プログラマー向けのツールが一番発達するのは、プログラマーが自分で何が欲しいかわかるからですよね。
そうなんですよね。
そうなんですね。それはあります。
それと同じレベルでは、プログラマーさんはこちらがうまく伝えられてないっていうところもあるし。
だからそういう意見交換の場っていうのがあんまり少ないのはありますね。
一方では、開発の経験とか全く知見がない人が要望を出し始めるととんでもない無茶なことを言っちゃったりとか。
でもあんまり遠慮しすぎるのもあれなんで。
要望は要望として、要望ボックスみたいなところに入れてちゃんと閲覧できるみたいなこともあればいいし、
今温め中の共同連載の第2回目のエディター系の話で、
そういう書き手から見てこういうのがあったらいいなっていう話が、一つまとまったらいいなと思いますけども。
それとも関係しますけど、文章もそうなんですけど、
最近思うのは、時間はリニアであるという当たり前のことを。
昨日ちょっとブログの記事を書いたんですけど、
時間はリニアなんですよね。当たり前なんですけど、そのリニアな時間の中で我々は生きてると。
だから多数ともリニアに並ぶんですよ、最終的には。
どんなに階層的に扱ったとしても。
だから究極のリニアにタスクを並べたものの一つが、たぶんタスクシュートだと思うんですけど。
57:08
あと実は、作業記録に一行でずっと書いていくのもリニアなんですね。
文章もそうなんですよね。最終的にはリニアになるんですよね。
大事ですね。何部何省何校立てしようが、最終的にはリニアになります。
すごく大事なことなんじゃないかなと思っていて。
なのでそれを踏まえて文章を書くこととか、タスクを扱うこととかを考えるようになったんですけど。
たぶん今日小田下さんが言ってた話とも繋がるんじゃないかなと思いますね。
だから結局、検索ベースでやると、フラットに書けるんで、
階層構造みたいなのから解放されるっていうのはありますね。
検索用語を自分で工夫すれば、いくらでも複雑な構造が作れるんですよね。
例えばプロジェクト名の後に「スタート」って書いてコロン打ったら、
そのプロジェクトのスタート時期だけが抽出できるとか、いろいろやり方次第でできるんで。
多少エディタブルというよりはプログラマブルっていうか、そっちに近いカスタマイズができるんですよね。
結局、いわゆるグレップ的な検索機能と検索する文字列を工夫するだけで、
実は専門のタスク管理アプリに対応できる機能を実現しちゃったりできちゃうっていう不思議なことが起こるわけですよね。
その行為自身がある種自分の意思の反映だったりするんですよね。
これが結構自分の道具を作っていく上では重要ではないかなと。
便利便利じゃない以前に、そこに何か求めるものがあるっていう感覚が、わりかし大切かなと。
そうなと思います。
いやでも、だいぶ前に妄想みたいなこと書いたんですけど、
アウトライン系でタスク管理、回想系でタスクを管理すると、
プロジェクトによってはタスクの回想がずれてしまうのがあって、
単発のプロジェクトのタスクは第2回想にあるけど、
大プロジェクト、サブプロジェクト、タスクの場合って第3回想にタスクが並んでしまうんですよね。
ここのずれるのが、僕はどうしても気に食わないんですよね。
だから逆に一番下の回想が揃ってて、上の線の長さが違うから、
1:00:04
上はトップで下も揃ってるけど、真ん中だけがちょっと違うみたいな。
見え方をしたらもうちょっとタスク管理ってやりやすくなるんではないかと思ったけど、
そんなツールは今までにかつて見たことはないんですけど。
それに近い試みをしている人を実は一人見かけたんですけど、
たぶんそれ、勝手に言っていいかどうかわからないですけど。
今の話の問題って、結局細かくなるに従って回想を下げていくから起こるんですよね。
逆に、今言うルート回想みたいなものを一番下にして、上げていけばいいんですよね。
より上の。
なるほど。
実はワードのアウトライン機能ってそういう構造になってるんですよね。
本文回想が、ルートって言うとちょっとコンピューターに詳しい人ほど誤解をもらえるかもしれないんですけど、
今言う回想っていうのがあって、下げていくんじゃなくて、今言う回想に対して見出しをつけると、
見出しの分かれを一個上げるんですよね。
それをさらに大きな章をつけると、さらにそこから一個上げる。
だから実は本文の回想は常に揃ってる。
同じっていう構造に、実はワードのアウトライン機能はできてて。
だから多分、アウトラインをどう作っていくかという考え方一つで、全然使い勝手が変わって、同じアウトラインでも変わっちゃうっていうところがあって。
今のワークフローとかダイナリストみたいなアウトライナーは、多分今言う回想があって、回想化しようとすると一段下げるわけですよね。
そうですね。一番細かい回想がプロジェクトの大きさによって浅かったり深かったりするってことが多分起こっちゃうんですよね。
だからあれは、Zoomで使うことが前提なんでしょうね、きっと。
だから回想がずれても気にはならないはずなんですけど、
複数の項目を一列で並べたときにバラバラになるっていうことが、タスク管理の場合は起こるんですよ。
それになっちゃいけない。
本の表立ては絶対揃ってるはずなんで。
でもタスクの場合って、大きいプロジェクトと小さいプロジェクトの場合で回想がずれてくることがあるんで、そこが管理しづらいんですよね。
ああそうか。確かにでも、ワードはメインが本文だから。
文章化したときには最終的に出来上がったら回想は揃ってなきゃいけないっていう、
その揃ってる状態を前提に設計されてるわけですよね。
1:03:01
なるほどなるほど。
ああそうそう。
ちなみにだからオーグモードもそうですね。
オーグモードもまさにその思想で管理されてます。だからあれは使いやすいんですけど。
だからオーグモード、要するにアウトライナーじゃないけどマークダウン的なものはそういうことなんですよね。
そうですね。確かに確かに。本文ベースで見出しを上げたり下げたりしていくっていう。
アウトラインひとつをとっても多くが深いわけですよね。
そうですね。だから普通にアウトラインを使った場合、ワークホリー的なアウトライナーを使った場合とエディターの違いはそこにあって、
トップがスタートなのか、ボトムがスタートなのかっていう違いがあるってことですね。
面白いな。
その違いは、プロセス型とプロダクト型って言っているもののちょっと親戚みたいなことなんですけど、ちょっと違う。
ただボトムを揃えて上げておくのってプロダクト型になるんですよね。
うんうんうん。そうですね、確かに。
だから逆に言うと、アウトライナーでは階層の違うものを同列に扱えるメリットがあるってことですね。
だからやっぱりどっちがいい悪いじゃないんですよね。
だから管理のビューとしては階層が違っていいけど、実行のターボになるとずれてると困るってことなんですね。
そうかそうか。
だからタイミングによってどっちかのほうがいいっていうことが起こるんですけど、
意外に実はそれは交換可能ではなくて。
そうなんですよ。
そうですね。この場合は無理ですね、きっと。
まあちょっと工夫するとワードではそれに近いことができるだけれども、
ワードはワードで、逆に別の問題があるんで、
本当にプレイでメインとアウトライナーとして使うのは厳しいですよね。
そこは単一ツールでは完結しないんですね。
これは追求するときも面白い話じゃないかな。
結構深い話ですよ、これ。
とりあえずプロジェクトノートって別に作ってもいいんですけど、作らなくてもいいですし、
作るにしろ作らないにしろ、ログベースで記述していく。
単なるタスクの裏列にすると非常に消費期限が短くなってしまうっていうのは、
1:06:01
たぶんどの環境においても言えることだと思うんで。
これは結構意識したほうがいいのではないかと。
あと、ベイリーとプロジェクトをどうリンクさせるのかは、
たぶん個々の人の課題なので、一般界は与えられませんけど。
でも普通の2つの視点というか、レイの視点とプロジェクトの視点があったほうがいいのは確かですね。
それぞれにログを振り替えられると、やっぱり良いと思います。
たぶん何もないと思います。何かご報告なり宣伝なりがあれば。
僕も今のとこは何もないんで。
じゃあ今週はこのままでした。
