00:02
うちあわせCast第百五十四回ということで、
今回もケースにたくさんお返ししております。
よろしくお願いします。
よろしくお願いします。
結構久しぶり、3週間、4週間ぶりなので、
ご無沙汰してます。
大量にニュースがあるんですが、
さすがに全部追いかけられないので、
気になることをいくつかピックアップしますが、
まずは、ノーションAIコネクターという機能を発表しまして、
ややこしいんですけど、スラックとつながることで、
スラックの中のデータをベースにしたAIに質問ができるようになったということで、
ノーションの根っこがいろんなツールに伸びてきているっていうのと、
やっぱりこのAIベースになってきてるんだなというのが感触ですね。
そのスラックがまた独自にプロジェクト管理機能というのが追加されたらしく、
スラックってチャット系のアプリなんですけど、
その中でタスクなどが扱えると。
だから漢字で言うと、
GitHubにもイシューとかタスクみたいな扱う機能があるんですが、
それと逆の方向で、チャットの方向からタスク系を扱えるということで、
どんどんこの点のやつが多機能化していって、
ノートツールがカレンダーツールを巻き込む動きがあったと思うんですけど、
チャットツールがタスク管理系も手広くやるということで、
基本的に全体的に多機能化に向かっているなという印象です。
良いか悪いかで言うと、
ワンツールで、ワンストップでできるのはいいかなと思いつつも、
難しいとこですね。
だからそうなんですよ。それしか使わないなら、
そういう超多機能ツールを2つも3つも使わざるを得ない状況っていうのが一番困るんですね。
かえってどこに何が書いてあるのかわからなくなっちゃうんだよね。
そうでしょうね、きっとね。
特にノーションで情報共有をしつつ、
スラックでチャットするみたいなことも普通にあるでしょうから、
どうすんねやろうみたいなところはありますね。
悩みが増えるばかりという感じですね。
いいんだろうか、それで。
最近頑張っているEvernoteなんですけど、
新しい機能が2つ紹介されてたんですけど、
1つは実装されていて、
オーディオ・トランスクリプションということで書き起こしかな。
03:04
だからEvernoteに音声メモを取る機能がもともとあるんですけど、
ノート上にロックボタンを押したら音声の入力が始まって、
ロックボタンを止めたらノート上に添付される形で音声ファイルが保存されるという機能なんですけど、
音声ファイルの右の方に翻訳、書き起こし、
よくわからない名前を覚えてませんけどボタンがあるので、
それを押すと、生成AIキーウェイだと思いますけども、
中身がちゃんと書き起こされると。
しかもなかなか精度が高いということで。
求められている機能で、これもAIのうまい使い方かなと思います。
もう一個が、デイリーノートテイキングということで、
これまだ多分実装されてない機能なんですけど、
ロームリサーチとかログシークを使っている方はお馴染みだと思いますけど、
その日の日ごとのノートを作ると。
作る際にテンプレート経由で作ることができるということで、
ますますモダンなノートツールに近づきつつあるなというところです。
大きめのニュース、だいぶ前なんですけど、
Appleの新製品、WWDCか?
リンクはまだ貼ってないですけど、
Apple Intelligenceというのが発表されまして、
名前がすごいなっていうのがまず第一印象なんですけど、
略したらAIになるという、
ネーミング上書き戦略みたいなものもすごいんですけど、
仕組みが結構面白くて、
いわゆる巨大な言語型のタイプじゃなくて、
それぞれのiPhoneの端末の中に乗っかる小さいタイプの生成AIで、
基本的にはアプリの操作とかを代わりにやってくれるという機能があり、
それとはまた別にちょっと複雑な機能が必要になったら、
Appleが運営しているサーバーに投げて、
そこで巨大なモデルで回答を生成して返してくるみたいな、
2階建ての構造になっているというところが非常に素晴らしいし、
これを結構いろいろ思うところは僕はあったんですけど、
昨今のAIの進化っていうのが、
巨大なモデルにどんどんなりつつあるわけですが、
果たして日常生活を送る僕らに、
果たしてそんな巨大なモデルが必要なのだろうかということは、
常々疑念やったんですけど、
06:02
iPhoneの操作とか代わりにしてくれるレベルって、
そんなに巨大じゃなくていいはずで、
ローカルでも扱えるような生成AIがあればいいじゃんっていうことを、
ちゃんとやってくれているというところがまず見事なのと、
これはRebuildっていうポッドキャストで聞いたんですけども、
このApple Intelligence経由でアプリが操作できるということ自体が、
実はそのアップルの歴史が関係していると。
つまり、スタートアップルスクリプトみたいなのがあり、
現状はショートカットAPPっていうのがあるんですけど、
それらはアプリ開発者がスクリプトとかショートカットで操作できるように、
アプリの機能をそこに開放していると、APIみたいなものを設けていると。
それがあるからユーザーがスクリプトで操作できると。
そういうのがあると、Apple Intelligence経由でそういう操作も可能になると。
だからこれはWindows OSの生態系ではなかなか成立せず、
Mac OSのアプリ開発の歴史があったからこそ結構できたんだという話を聞いて、
これはすごいなと思った次第ですね。
その小さい生成AIの話に関連するんですけど、
僕前回ぐらいかな、Googleって最近イノベーションしてないみたいなことを
ネガティブに言ったんですけども、
notebook.lmというのがGoogleから提供されまして、
これはGoogleアカウントを作ったら多分領域がもらえるやつだと思うんですけど、
そこに資料を自分でアップロードする。
例えばPDFファイルをいくつか上げると。
そうするとそこで読み込ましたデータセットをベースに
生成AIが答えを返してくれるという機能で、
これも一般的に使える大規模汎用型モデルじゃなくて、
個人が、インターネットを使ってるからローカルじゃないですけど、
個人化された生成AIの使い方ということで、
やっぱりこういうのが個人の知的精査においては、
こっち側のほうが多分役立つんじゃないかなというのは見てて思いました。
そうですね。ただ僕ちょっとイメージできないんですよね。
そのレベルで逆にAIを使う必要がどのくらいあるのかというのも、
ちょっとイメージできないところはあります。
ちなみに僕一応実験した感じで言うと、
こいつはね結構すごくてですね。
なんか論文のPDFファイルを上げるじゃないですか。
そうすると、まず質問しそうなことが提案されるんですよ。
自分が質問しそうなこと。
09:00
そうそう。この論文に関して質問しそうなことがまず選択肢に上がってきて、
そこを起点に話を広げていくことができると。
今までの生成AIって基本的に何か聞いてくださいというゼロスタートな感じで、
質問できる人は使えるけど、そうじゃない人は使えないみたいな感じだったわけですが、
限定された領域で例えばPDFの論文を処理するみたいな目的において、
統計的にこういう質問があり得るだろうみたいなのがあるんでしょうね、きっと。
そこから話を広げていくことができるということで、
たぶんその研究的な活動において言うと、
これ結構役立つんじゃないかなというところで、
大規模すごい型モデルじゃなくて、
ローカル個人的なモデルのシフトとして僕はこれは結構評価してますね。
プロンプティングを助けてくれるみたいな感じなんですかね。
そういうことですね。要するにプロンプティングの最初のきっかけを与えてくれるみたいな感じ。
もちろんそれ以降は自分でどんどん質問することができますし、
例えば同じ著者の複数の論文をまとめて与えることで、
例えば3つの論文から共通する観点を抜き出すみたいなこともおそらくできるでしょうから、
なかなかできる子じゃないか。
それはわかりますね。
そういう感じでローカル、ローカルというか小さいサイズとか、
個人向けの先生会の発達も徐々に起きていって、
それとまた別の流れなんですけど、
これ何て読むのかな、レイディーバードって読むのかな、
レイディーバードと読むと思うんだけど、
新しいブラウザの開発が進んでいると。
で、このレイディーバードの何がすごいかというと、
ブラウザってそのウェブブラウザってそのUIがあるわけですけど、
その裏側でエンジンが走ってるわけですね、ブラウザエンジンっていうのが。
で、最近出てるビバルディとかホニャララホニャララとかは、
全部Chromeのエンジン、Chromiumっていうのを使ってるわけですね。
だから、要するにChromeのコピーとかフォークみたいな存在なんですけど、
レイディーバードはそのエンジンそのものを新しく作ると。
で、現状その昔たくさんあったエンジンっていうのがどんどん修練されてきて、
もうほとんどChrome一挙になって、
あとSafariのWebKitかな、あたりがあって、
あと僕Firefoxは別のエンジンで走ってるという感じなんですけど、
複数のエンジンが競争している環境っていうのが好ましいわけですが、
その一挙対戦に一石を投じるということで、
実際どんな感じになるのかは全然わかりませんけど、
今ここまで発達した界隈において、
ブラウザエンジン1から立ち上げるって多分超すごい面倒くさいことだと思うんですけど、
12:01
それをやろうとしている人たちがいるというのは、なんかちょっと感動しました。
なかなか勇気がいることですよね。
うん、勇気がいることですね。
一応多分寄付ベースでずっとやっていくということで、
GoogleとかAppleとかの商業とは違うものを作るぞというような心意気があるんだと思います。
細かい話というか、ミニツールの話なんですけど、
Workroomというウェブで使えるエディターみたいな感じで、
自分だけの作業部屋が作れるノートアプリがあって、
これ誰でも使えるブラウザ系のアプリで、リンク貼っておくのでまた見てもらったらいいですけど、
一つの作業空間みたいなのが与えられて、
そこに自由に新しいウィンドウを置いて、
メモをペタペタ貼り付けられる型のエディターみたいな感じかな、イメージで言うと。
これ最近よく言っているマルチウィンドウの逆襲みたいな感じを体験するツールだなと思って、
どこまで使いやすいかは別として、
やっぱり複数を同時に舐められなくていいよねっていうのが、
これ体験できるアプリだと思います。
そうですね。それはいいと思います。
あとなんか、ウィジェット的にポモ泥タイマーとかも受けるみたいな感じで、
ちょっとハックなとこもあって、
こういう感じでいろいろ単一のシングルウィンドウで集中するというのとはまた別の感じが増えてきたらいいかなというところですね。
はい。
というところでニュースは大体そんなところ。
あ、すいません。
ちょっとね、僕ね、秋フローってあるじゃないですか。
秋フロー、はいありますね。
秋フローって気になるんですよね。
カレンダーベースの。
カレンダーベースの、これはタスク管理する?って言うんかな。
これ結局こういうの名前がわからないんですけど、
いわゆるタイムブロッキングと言われる手法をベースにしたやつですね、これ要するに。
なんかね、こういうものの逆襲が来るんじゃないかという気がちょっと最近しておりまして。
カレンダーベース。
そうか。最近カレンダーベースはあんましないか。
そう、カレンダーから離れていったんですよ。
そうかそうかそうか。確かに。
GTDみたいな。
15:04
でも、タスク集とはカレンダーベースと似ててもやっぱりちょっと違うところがあるか。
そうですね。カレンダーベースではないですけど、
ただその、タスクを実行するには時間がかかるということを
意識させてくれるツールという意味では共通したものがあるかなという気がしてますね。
そうか。僕もどっかで見かけてリングだけ拾っておいて、
こういうやつかってデモを見るだけ見て、アカウントは作ってないんですけども。
だから昔の手帳術、特にそのウィークリーが縦に並ぶやつかな、
バーティカルタイプか。バーティカルタイプの仕事術はだいたいこういう感じなんですけど。
そうそう。
その復権か。
Googleカレンダーを1日表示にしてこういう使い方してる人も昔はいましたが、
最近は聞かないかな。
要はその、この与えられてる時間の中でどれぐらい入れられるのかっていう、
タスクリストだとわからないんですよね。
あれ入ると思ってたのに入らなくなっちゃったっていうことがしばしば発生するわけですけど、
そういうところからのカレンダーというか、タイムブロック型の揺り戻しみたいなものがあるんじゃないかという気がちょっとしましたね。
これタイムブロッキング型だったら誰やったかなー。
IT界隈のマスクさんやったかなーがタイムブロッキング方式でしてるみたいなんで、
一時期その界隈で話題になったんですけど。
有限性を意識させるという。
デジタルは逆に無限性へ人を導くみたいなところがあるわけですけど、
その反転として時間という有限性を意識させるっていうことか。
やっぱりそのある種の窮屈さみたいなのを感じる反面、
制約がわかってより明確にクリアになるということはあるでしょうし。
確かに最近やってないですね、こういうの。
たぶん最近そういう物事に入ってきた人って、
逆にバーチカル型の手法がむしろ新鮮かもしれないですよね。
あーそうか。
いきなりデジタルからすると確かに、
僕らはある種アナログのあの感じを知った上でデジタルを使ってるところがありますけど、
デジタルがいきなりやと有限性が意識されずに詰め込みすぎが起こってしまうということはたぶんあるでしょうし、
18:05
タスク集とかやっぱり一定の指示を受けてるのもそうでしょうね。
他のタスクリストツールでは与えてくれない有限性がそこにあるから。
そうなんですよ。
タスク集とって取るにはいかないことにどれだけ時間を使ってるのかを見せてくれるっていう意味では、
すごいツールだと思うんですよね。
まあそうか。
だからそんなものを見たくないという人にとったら不評の極まりなんですけども、
リアルを直視するということの重要さが現れてますし、
でもスタート地点はリアルであるべきですからね。
だと思いますね。
リアルだけでいいかっていうとそれはちょっとあれなんですけどね。
リアルとそのビジョンの行き来っていうのが、
そう、バランスが。
アリオは一つだけでは不足してて、
二ついるみたいな話は今回のテーマと絡まってくると思うんですけど、
どこから行こうかな、どこから行こうかな。
管理の話もしたいんですけど、
タスク管理としてのツリーというところで、
参考ページにツイートのリンク貼っておくんですけども、
起点となるツイートが、
TODOというのはリストではなくてツリーだと思っているが、
世の中にあるTODOアプリはだいたいツリーで、
ツリーなのがほとんど少なくてリストだけになっていると。
現状でいうとオムニフォーカスみたいなものはツリー構造を扱えるという話があって、
これに関連してザクさんが、
確かにタスクの構造っていうのはツリーかもしれへんけど、
実行するときにはリニアが必要だよねというような話。
それっぽい、ようやくしましたけど、っぽいツイートされてたと思うんですけど。
ここをどう扱うというかということで、
難しい問題なんですね、これは。
難しいですね。
要は場面によって必要な構造が変わるんですね。
タスクの構造を理解するためにツリー構造にしたとしても、
それを見ながら実行しやすいかどうかということですよね。
そのときにタスクの構造、つまりツリー構造、
情報の回送とか関係性で整理されたツリー構造は何のためにあるのか。
つまりまっすぐに載せたリスト、
ナイシはさっき言ったタイムブロッキングのような時間の有限性を伴ったビューというのは、
21:04
まさに実行するためのビューだと思うんですけど、
ツリー型のビューというのは、ほにゃららのためのという、
このほにゃららに何が入るんでしょうね。
把握ですね。
何をするかを把握するということか、
なぜするのかというような把握なのか、
あるいは全部を含めた把握なのか。
そこがたぶん、
例えば仕事をすることを考えている人と、
ちょっと広い視点で考えている人とで、
たぶん考えが違うかもしれないですけど、
やっぱり両方含んでるんじゃないですかね。
そこで何をしているのかの一致がないと、たぶん話が混乱する。
例えば、自分の掲げているタスクが10個あるとして、
このうち5個やろうとか、あるいはこの時間に1個をやろうという、
全体像を把握してそのうちからやることを選ぶという、
全体像を把握しての把握という意味合いもありますし、
もう少しメタなレベルに上ったときに、
自分が解決しなければならない案件が20あるとして、
そのうちどれが自分のやるべきことなのかを決めるという、
取捨選択のための把握っていうのもあって、
似たようなことをしているようですけど、
ちょっと頭の働き方が異なるような気がするんですよね。
ツリー構造を必要とする、
そのタスクがどんな位置づけを持ってそこに置かれているのかを、
把握するっていうことは、やはりメタなレベルでやることを決める。
自分のやることは何かを定義するという意味での決定において、
役立つような気もするし、
逆にそれは情報量が多すぎるような気もするし、
どうかなー、ちょっと難しいですね。
多分、すべてをツリーと表現しようと考え始めると明らかに多すぎる。
とてもそんなことやってられないと思うんですよね。
だから、まずそのタスクの構造がツリーであるというのは、
GTD的な用語を使うなら、
24:02
タスクの上位階層にはプロジェクトがあるはずだというような、
プロジェクトの中に階概念としてタスクが並んでいて、
ツリーという意味でのツリーの行為って言うんだと僕は理解したんですけれども、
それを完璧に表現しようとするとおそらく、
実行する時間がなくなるというか、
それだけで多分、頭のリソースが外に持っていかれちゃうような気がするんですよね。
だから、完璧にそれをすべてのツリーの要素を書き出そうと、
書かれたものの理念的なツリーだとすれば、
それを全部やることにはおそらくさほど意味がないんじゃないかと思うんですけれども。
ただ、プロジェクトとかサブタスクとかって、
階層ごとに意味を固定することになるんですけど、
あんまりそういうことを深く考えないで、
なんとなく上の階層、下の階層って作っていくと、
抜け漏れというか、
頭の中でグルグルしてたけど、
実はツリーにしてみるというか、
構造をそのツリーの形で表現してみると、
実は考えなきゃいけないことのある一部分しか目が行ってなかったなっていうことが分かったりするんですよね。
視野が広がるというか、
そういう目的を持って、
ツリーというか、僕だったらアウトラインという言葉を使いますけど、
そういうところがあるんじゃないかなと思うんですよね。
ただ、オムニフォーカスなんかそういうふうに作られちゃってるんですけど、
あるプロジェクト、じゃあこれはプロジェクトだなっていうのがあって、
そのプロジェクトにはこういうタスクがあって、
ここまでこういう順番で完了かなっていうようなことを表現しようとし始めると、
ちょっと単語聞かれすぎて、むしろ実用性が低下していっちゃうというか。
名詞的表現の差ですけど、ツリーとアウトラインという表記のほとんど同化ですけども、
例えばこのリストではなくツリーだというような表現を聞くと、
さっき僕が練習したように、
完全な木にしなければならないという、
27:03
木そのものの全体像を描かなければならないという気がしてきまして、
タスクがある、そうするとその階層の上にプロジェクトがあると。
このプロジェクトはまず何に属しているのかと考えたくなりますし、
巨大プロジェクトは何かというふうに考えたくなって、
そのツリーを描写することそのものが目的化してしまうし、
そうやって出来上がったツリーは多分巨大すぎて圧倒される結果になりますけど、
自分がやろうとしていることの輪郭線、アウトラインを描くという表現ならば、
先ほどのような強化観念はちょっと薄いかなという気はしますね。
途中でアーっていう感覚が得られることがあるんですよね、アウトラインにしていると。
そうなったら逆にそれ以上完璧に細部を詰める必要はない気がする。
どうでしょうね。そこは人によって感覚がもしかしたら違うかもしれないですね。
そうなんですよね。
例えばさっきちょっと前に言った、自分がやるべきことは何かを定義するみたいな話になったときに、
やっぱりそうじゃったら自分が抱えているものをすべて列挙しなければならない的な
思考のスイッチは普通に入るでしょうし。
でも、そうですね。
例えばその年に1回、今年1年の自分のやるべきことを決めるぞ会議を1人で開くとして、
そのときにはやっぱりすべての列挙は多分必要だと思うんですけど、
でも例えばそうやって作ったリストが日々のタスクを決める役に立つかっていうと、
多分それは役に立たないんで。
その用途に合わせたツリーを作る必要があるということは言えるんじゃないかなと思いますけど。
そうですね。
頭を起動するための補助線的なツリーというか、表現が難しいですけど、
ツリー自体にそんな大層な意味があるわけはないというか。
ただ何となく階層化していくうちに、
ああ、そっかそっか、こういうことか。
ああ、そうだ、あれもあった、これもあった、みたいなことがだんだん目が届くようになってくるような感覚である気がするんですよね。
そうやって思いついたことを書き出していくことによって、
何というか、把握じゃないんですよね。
頭の中のマップができてくるというか。
そういうツリーなりアウトラインなら意味があると思います。
思考の補助線としてのツリーかアウトラインという役割。
30:01
世の中のタスク管理ツールがあって、それからリストじゃなくてツリーだと。
ツリーなので、たぶん一番最上位概念はあなた、自分ボケたらラスターというのが最上位ノードで、
その下にGTT的に言うとゴールとか価値観とかがあって、
その下にというのが5階層くらいあって、一番下のところにタスクがナシのネクストアクションみたいなのがあって、
その超膨大な、おそらく項目数100では効かないようなものを使って日々のタスクを実行していく。
例えば何か1個終わったら、その膨大なリストからたった1つのタスクを見つけてチェックマークをつけて、
大きなマップをクリアしていくみたいなものは、タスク実行ツールとしてはあまりにも応用だろうなという気はするので。
しません。
だからやっぱりタスクをハンドリングするっていう名詞同士で言い換えたときに、
実行するためのリストと、さっきザクさんがおっしゃられたような把握とか理解とか考えるためのビューの形っていうのはやっぱり異なるべきでしょうし、
ビューが異なるっていうと、ノーションでデータベース作って複数の見え方みたいな感じがします。
そうじゃなくて、そもそもリストとしての在り方が違うものであったほうがいいんでしょうね、これは。
だから結局以前もその話、元々のデビッド・アレンが提唱したGTDではプロジェクトリストとネクストアクションリストは別のリストなんですよね。連動してないんですよね。
生地コンピューターでアプリ化したときに、連動させることが可能になってしまったために、
一つのデータベースとプロジェクトビュー、そのプロジェクトの下にタスクが挟まっているビューとネクストアクションが表示されるビューを切り替えられるようになっちゃったんですけど、
それをやろうとすると結構辛くなってきちゃうというか、
このプロジェクトを構成するタスクは何かみたいなことを厳密に定義していきます。
だけれども実行する前にそんなにプロジェクトの様子、アクション、どういうアクションが具体的にどういう順番であるかなんてわからないわけですよね。
仕様書じゃないんだからみたいな。
だから仕様書っぽくなっちゃう。
あー、確かに。それはありますね。
33:03
だけどそれはね結構辛いだけなんですよ、それをやろうとする。
だからデビッド・アレンが言ったのは、プロジェクトリストをデビューの時に眺めつつ、
コンテキスト別に、それぞれの最低次にやる次のアクションは何かっていうのを書き出して、
それをコンテキスト別に並べたリストを別に作るっていう。
今はツリーなんだけれども、2つの独立したリストに分割しちゃったわけですよね。
それはだから昔というか、その当時はアナログやったからそうなるだろうやなかって、
コンテキストあるなら結びつけることが可能になったが、
結びつけることは技術的な制約というのとは別のところの理由があったというところなんでしょうね。
はい、そうだと思うんですよね。
最近ワークフローリーの使い方を紹介した記事を書いたんですけど、メルマガで。
自分の中で一つの発見は、プロジェクトの情報とプロジェクトリストを分けたということで、
このGTTの話とかなり近いんですけど、今週取り掛かりたいプロジェクトっていうのを並べつつ、
それとは別にプロジェクトリストっていうのをまた広告を持ってるんですけど、
今までなぜこの発想にならなかったかという、不思議に思うぐらいなんですけど、
やっぱり例えばプロジェクトリストって作ったら、プロジェクトの何つくものは全部そこに並べるべきやし、
例えば1週間のやることのリストを作ったら、そこには仮にプロジェクトを並べれたら全部のプロジェクトを並べるべきやし、
プロジェクトリストがあるんやったらプロジェクトはそこに行くべきみたいな、
名刺思考というか、重複やダブリーとか同じカテゴリーなのに分かれてるみたいなのは、
よくないことだみたいな感じがあって、
でもそれが決定的に実用性を損ねていたんですけども、
効率的な整理を実現するために、実践上の何か制約を逆に抱えてしまっていることがあって、
リストを分けるとか、2つのビューを別にモデルを作るとかっていうのは、
もう本当に非効率の極まりなんですけど、
実践上そのほうがいいというのは、資産の多い話ですね。
だから結局、われわれはコンピューターを使って何をしようとしてきたのかっていう。
データベースという形で、そこにデータが登録されていて、
36:01
それをさまざまなビューで抜き出せる。
どう考えてもそのほうが効率的に思えるんですけども、
そのほうが効率的な分野はたくさんあるはずなんですけど、
タスクというか行動のリストと言っていいのかわからないですけど、
タスク管理においてはそうじゃないんですよね。
明らかにそうじゃないと思うんですよね。
明らかにそうじゃないんですけど。
例えば、僕らって言うとこの前で線引くのが悪いんですけど、
だいたい1日のリストを作りましょうということを、
よくモダンな感じで言うとだいたいそうで、
さっき言ったタスクシュートもそうですし、
デイリータスクリストもだいたいそういう感じで、
これはコンテキスト別のリストとか、あるいは大きなトゥートリストを作らずに、
今日という文脈でやることを一列に並べましょうという言い方ですけども、
一列だから難しいな。
それと例えば、ある行動をするときに自分の大きな価値観を選び、
プロジェクトを選び、タスクを選びという階層的選択をしていないということなんですけども、
実際してないんですよね。
僕らが実際に行動を選ぶときに、
一番上の階層から順にたどってタスクを選ぶみたいなことを、
ナチュラルでは絶対やってないと思うんですよね。
例えばその行動、あるいはやろうとしている行動の価値がどうあるかを見極めようとしたときに、
初級的にそのような階層構造が見出されるとは思うんですけど、
これはこういうプロジェクトはダメだし、
このプロジェクトはこういう価値観に貢献しているから意味があるんだよという感じで、
定義なし評価されるという構造があって、
そこでは確かにツリーが出てくるんですけど、
僕らのリアルの行動はほとんど瞬間的な思いつきと直感の選択でできていて、
それを後から理由付けするときに構造が生まれるということなので、
確かにタスクについて考えるときにツリーは生まれるんですけど、
実行するときには一個一個の選択でしかない、
一つのタイムラインに並べるということがむしろ実際的な選択なので、
だから別物なんですよね、基本的にそれは。
だからタスクの情報というのを分析的に考えたらツリーだけども、
実行的に見たら一列に並べるしかないわけで、
だから実行の分野で見たらプロジェクトとか責任というのは、
ある種のまやかしというか、まやかしってちょっと大げさですけど、
39:02
恣意的に作られたものでしかなくて、考えるという局面においてのみ使われるものなので、
だからタスクについて考えるときの作るリストと実行されるときのリストは違っていいし、
違ったほうがいいというふうに言えるんでしょうね。
と思いますね。
じゃあその階層化で、例えば地下なりが最上位のほうにあるツリーなりアドラインが意味がないかというと、
そうじゃないなと思うのは、
例えばその実行のときにフラットに並べているという天使があったときに、
時間からあふれちゃいそうなとき。
要は限られた時間でどっちをやるか選択しなきゃいけなくなったときに、
どこなのかというのを確認するすべがないと、
おそらくひたすら圧の強いものに流されていくことになるんですよね。
そのときにお客さんに頼まれたとか上司に指示されたというものをひたすら習っていくことになるんですけど、
そのときに、すごいわかりやすい例ですけど、
例えば明日休日出勤をすることができるかと言われるときに、
明日は子供と公園に行くことをしていたと。
すごいわかりやすい例ですけど。
そのときに、明日は休日であるというときに、
じゃあどっちを選ぶかというときに、
それぞれのタスクの上位階層をたどったところに何があるかということに基づいて選択をするということができるかできないかというのは、
やっぱり階層的なリストがあるかどうかというところによるんじゃないかなと思います。
やっぱりそれもタスクをどれをするかというと判断のときに効いてくるということですよね。
判断というか考えるという行為をするときに、階層的なリストが役立つ。
階層的なリストにしておかないと優先順位とか重要度が見えてきにくいということはあるでしょうし、
だから実行者としての自分というのは基本的にはシステム1的な反応によって前に進んでいくわけですけども、
システム2的な理性とか内緒的なものの力を発揮させるには階層構造がいい。
実行と施行というのはかなり逆の属性を持っておりまして、考えすぎると実行できなくなるわけですね。
42:10
だから実行度を上げたかったらできるだけ考えないほうがいいんですね。
これはもう残念ながらでもないか。
だから複雑なタスクリストが実行に向かないのはむしろ考えてしまうからなんできっとね。
だからその用途が、人の精神に与える用途が多分違ってて、
だからアクセルとブレーキのように相反するリストが2つあったほうが、
実は全体的に見たときに人間の精神というか結果が何に影響を与えるということになるんかな、こんな感じは。
そうですね。両方あればいいんですよね。
片方が片方を内包してしまうんで、つまり階層型構造があればリストになってるやんってことになってしまうので、
そこを拒絶して2つ別に持つという、同一のツールの中にあってもいいけど、
違った形のリストとして持っておくほうがいい。
そうなんだよな。ややこしいなと思ったのが、
僕らはデイリーベースと言いますけど、
デイリーも置くツールによったら階層構造化に置かれてしまうわけですね。
今日の日付だった7月の改造化で2024年の改造化に置かれるわけですね、基本的には。
これも階層編でセルフツッコミしたわけですけど、
実行その日のページにフォーカスしたときには一律にしか並ばないわけですし、
それはさっき言った価値観の階層とは違う階層なので、また用途が別だから。
例えばワークフローリーがあったとしたら、
イヤリー2024っていうページがあって、その階層の下に7月何日っていうページがあって、
そこにデイリータスクが並んでる。
その日付の階層とは別に何かまたお題項目があって、
そこにプロジェクトとか自分がやろうと考えていることについて並んでいるものがあると。
夢の理想ツールで言うと、デイリーの項目と自分が考えているプロジェクトのタスクみたいなのがリンクしていたらハッピーみたいな、
その片方にチェックつけたらもう片方もチェックつきますみたいなのが夢のツールなんですけど、
おそらくその関係は切断している方が良くて、
片方は片方として、もう片方はもう片方として同じツールにあってもいいけど、
直接的な連動はしない方がいい。
例えばリンク機能で置いておくみたいなことじゃなくて、
それぞれ手をかけて作って、別のものとして動いていった方がおそらくはいいんでしょうね、これは。
45:04
と思います。
その連動は誰もがおそらく憧れるし目指すんですけど、
多分うまくいかないんですよね。
デイリーの実際のリアルな行動の中で必要になるタスク、行動を表現する言葉と、
プロジェクトとか大きい行動とか価値観をブレイクダウンしてきたときに、
こうだよなって考えたときに使う言葉ってなんか違うんですよね。
大きいアウトラインからデイリーのアウトラインにミラーコピーみたいなのをして、
うまくそぐわないというか、そういう性質のものじゃないんですよね。
それはやってみるとみんな感じると思うんですよね。
なぜなら散々やってみた。
みんなとかって決めつけちゃいけないですけど。
そうですね、本当に散々やってきました。
デジタルツールを使ったことがある人ならば、特にタスク管理に興味がある人ならば、
プロジェクトとデイリー、ないしはウィークリーとデイリーっていうものの連携みたいなのは普通に憧れますし、
最近のツールはやれるんですよね。
結構くもなくやれてしまうんですけど。
でもね、特に未完了のタスクみたいなのは、その2つの連携はうまくいかないですね。
いかないですよね。
例えばデイリーでやり終えたタスクみたいなのを、1週間のまとめ的にウィークリーに並べるっていう、
つまりDoじゃなくてDoneなものをリストアップする自動的にっていうのは、それなりにうまくいくんですよ。
やったことの確認。
それはありだと思います。
ただやろうとしていること、この1週間これやるぞって決めるときの何かと、デイリーの中で書かれるこれが結びつくかといったらこれ結びつかないんですよ、残念ながら。
だから、大きいプロジェクトからブレイクダウンしたタスクみたいなものをデイリーの表示制で、よしこれを日々やっていこうと思っても、
具体的な行動と結びつかないんでチェックできないんですよね。
怠けているわけじゃない、やってるのに書かれたそのタスクはなぜかチェックできない。
48:02
書いてないことをやってたりするんですよ。
リアルなデイリーの中での行動を事前に言葉として表現できてないし、やろうとしてもできないんですよね。
ちなみに、タスクさんはウィークリー単位の何かって、計画的なプランニング的なものってやっておられます?
やってない気がします。
デイリーベースの人に聞くと、ウィークリーはもうやらなくなったみたいなことをよく聞くので、そこはどっか合わない部分があるんでしょうね、きっと。
なんか、デイリーとウィークリーが近すぎて、同じことやってるみたいな感じになっちゃうからかもしれないですね。
マンスリーはある?
マンスリーもやってないです。
マンスリーって結局、請求とかそういう仕事上の切れ目が、そういう意味ではマンスリーを排除するわけにはいかない感じはしますけど。
ウィークリー問題やな。問題って言うほど大きくはないんですけど。
僕は最近ずっとデジタルノートでウィークリーどう扱うかっていうことを色々試行錯誤してるんですけど、なんかしっくりこないんですね。
手帳時代、ほぼ日手帳時代はほぼ日数のウィークリーを結構使ってたんで、ツール上の媒体上の違いなのか、僕の仕事の仕方が変わったからなのか、デイリー方式に基本的に致命的に相性が悪いのか。
実際言われるとおり、月曜日とか週末の日曜日とか、ウィークリー作るタイミングと近い日ってなんかすげえ無駄な感じがあるのは確かで。
ちょっと考えどころですね、これは。
逆にウィークリーをやるのであればデイリーなしでもいいのかもという気もしなくもないんですけど、どうでしょうね。
ウィークリーページにデイリーみたいなものを書いていって、1週間分のセブンデイズページとしてのウィークリーみたいなほうが、むしろ機能するかもしれないですね。
そうですよね。それこそ、さっきのバーチカルカレンダー型のウィークリーで、前のGoogleバーチカル表示にあったみたいに、バーチカルカレンダーの下のほうに時間の決まったタスクを書き出す欄があるみたいなやつが、実は一番強気出せもあったします。
確かに。デイリー型になって、デジタルのデイリー型になって、かなり詳細にデイリーページに書き込むので、やっぱりウィークリーの存在感そのものが薄いんですよね。
51:16
あえて別に作る意味がなかなか満たせないですよね。
しかも先ほどおっしゃられたように、ウィークリーで設定するタスクの流度って、1日の行動とタスクの流度で高いので、実行みたいなタイミング、チェックマークつけるみたいなことがほとんど起こらないので、作ってもやりがいみたいなのを感じにくいというのがありますね。
結局さっきの文脈で言うと、タスクは実行に関するリストと、試行、検討に関するリスト、ないしはツリーみたいなのがあったっていう言い方をしたときに、ウィークリーっていうのは実行の単位ではない以上、基本的にはウィークリー、その種類について考えるという行為しかやらないわけですし、
考えると行為に適したスタイルとかビューっていうのはどういうものかっていうのをちょっと一回考え直したほうがいいかな。
なるほど。
とりあえず今回得られた観点は、タスク管理といっても実行方面と試行方面で、実は別の営みであり、必要なツールも違うビューのほうがいいじゃろみたいなことは、これ結構平均的に言えそうな感じですね。
いえいえ、そうだ。それは言えると思います。
誰も教えてくれなかった話ですね、これはね。
あんまり意識されないように思えるんですけど、現実の実行上は多くの人がそうしてると思うんですよね。
確かに。
アナログの人は分けざるを得ないから必然的に分かれていくのかな。
こういうのはデジタル理念主義、原理主義の人が陥りやすいかな、混ぜてしまって混乱するみたいなのは。
そうですね。
あと、やっぱり完璧な最強のツールを作りたい願望があると。
結局その最強っていうのが最高効率を意味してる段階で多分もうミスってるわけですけどね、きっと。
まあそうなんですね。
難しいんですよね。
その最強ツールを設計してたり作っている段階ではそれが楽しいんで、一時的に実行の効率も上がるように感じるんですよ。
確かに。あるかもしれないですね。
だけど2ヶ月後そうじゃなくなるんですよ。
ありますね、確かに。その初期、スタートアップ的モチベーションの高さみたいなのがあって、そこでは多少の苦労でも乗り越えられますからね。
54:01
そうです。2ヶ月後の問題は。
結局思考のエンジンなしの思考のOSの作り方っていうのを教えてもらえないので。
だから実際は、あなたの思考とか行動をサポートするOSは、最初盛り上がって作るかもしれませんけど、2ヶ月後ちょっと冷静になって考えたほうがいいですよっていうアドバイスを受けたことがないから。
そうですね。だからしばしば、そんなツールのことなんて真剣に考えてない人のほうが物事を効率的にこなしたりするんですよ。
ああ、それは耳残りたいなあ。
まあそうですね。こだわること自体は悪くないけど、こだわりすぎて自ら罠にハマるというのは、まあ確かに。
今、我々が嫌なことを言いましたね。
いやでも、まさに金言というか真言というか、その通りですよね。それはでもやっぱり誰かが言わんとあかんことになっちゃうと思うんですよ。
つらいね。
まあでもね、知識があったりとか、こだわったり空腹したりすること自体は別に悪いことではないんで、ハマりすぎに注意というのがね、傾向としてあると。
たしかにツリーのときもあるが、タイムライン的に並んでいるビューもあって、それはあんまり統合的に管理しないほうがいいよというようなまとめですけども、
いやそうではないと。タスクはマインドマップが一番だみたいな話があれば、明日の打ち合わせキャストひらがなで、打ち合わせアラベルトをキャストまでいただければ、私たちがチェックしたいと思います。
ということで、たくさんお連絡したいこととかございますでしょうか。
特には今日はないです。
じゃあ今日はこれまでにしたいと思います。お疲れ様でした。
