00:00
おだしょー:打ち合わせキャスト 第105回ということで 今回もケース
にたくさんお迎えしております よろしくお願いします
おだしょー:お願いします
おだしょー:今週あんまりライフ ワーク系のニュースがなくて Log
SeqがVer 0.7になりまして 待望の 離れた行を連続選択できるという
機能がつきました これは結構 アウトラインの整理において便利
だなという感じですね
おだしょー:便利ですね 全然 違いますね
おだしょー:あとは正式化のグループ 機能 上の階層を作る機能ができ
たら もう結構完璧なんじゃない かなというふうに思うのです
おだしょー:そうですよね アウトライナー 部分に関しては
おだしょー:結構 僕は最近ハマ ってて これも一つのアウトライナー
の形やなという感じがして アウトライナー 機能がついてるなんちゃらという
よりは 今までのアウトライナー と違う故障ができるアウトライナー
みたいな Type A型のアウトライナー と Type B型のアウトライナーぐらい
の新しい位置づけにできるんじゃない かなというのを感じていますね
おだしょー:そうですね 新しい 方向に進む一つのきっかけかもしれない
ですよね
おだしょー:この辺はまたちょっと 改めてLogSeqについて話したいと思
うのですが 今回 打ち合わせキャスト のハッシュタグではないんですが
いただいたハッシュタグに紐づいて たかな 感想というか質問か 質問
で 第45回ぐらいの回への質問で 45回は何を話したかというと これ
ScrapBoxを見たら分かるんですが 45回が断片的執筆法について 断
片的執筆法っていうのはちょっと ずつ書いていくみたいな感じかな
僕のあれですかね ちゃうな
おだしょー:これはどの断片的 執筆法の話でしたっけね
おだしょー:本の原稿ファイル はどのように保存してあるかみたい
なことがメモ書きに残ってるんです が
おだしょー:そんな話をした覚え はありますね
おだしょー:ちょっとずつ細かく 分けて書いていった後でまとめ
たらいいじゃんみたいな話なん かな 多分 そのとき多分テキストファイル
の話をしたんでしょうか いわゆる プラットファイル TXTとかMTファイル
みたいなのを現在たくさんって 日常の仕事の中でとかって使われて
おります
おだしょー:使ってますね 使ってますけど 中間ファイル的な使い方が多い
かな あとはオムニアオートライナー のファイルを保存するときにオムニア
オートライナー形式じゃなくて OPMLで保存するんですよね 別に
03:00
だからテキストエディターの検索 機能で検索できるという 読みづらい
けど検索できるっていう そういう 使い方はしてますね
おだしょー:なるほど だから 一つのファイル内のデータっていう
のをアプリケーションを超えて 利用できるメリットがあると
おだしょー:そうですね
おだしょー:そうかな 僕も大体 一時期はアンチテキストファイル
派として生きてたんですけど 最近 はテキストファイル神話勢みたい
になって 大体の情報をテキストファイル で残してますし 作業記録がテキスト
ファイルですし 原稿ファイルも テキストファイルプラスGitで管理
してますし 最近はだからログシーク のおかげでアウトラインもテキスト
ファイルで残ってますし あと Rスタイルではないですけど 別の
ちっちゃいブログもMDファイルで 書いて それをほにゃららららら
してブログで公開するみたいな ことになってるんで だからスクラップ
ボックスとワークフローに入ってる データ以外は 大体僕はテキスト
ファイルで保存してますね さっき 言ったようにVS Code上で検索を超えた
櫛出し ファイルを超えた櫛出し の検索ができるとか 僕程度のプログラミング
の知識でスクリプトを通して処理 するとかができるっていうところ
だからやっぱりデータの所有権 が自分にあることによって ツール
を選べたりとか 改造できたりっていう 魅力があると おそらくそれがパソコン
かソナルのコンピューターにおける データの一番それっぽい使い方
というかいう感じが 最近はしてますね
おだしょー:そうですね それっぽい っていうか それこそ初期UNIXまで
遡る伝統的な使い方でもあるだろう し 自由ですよね たぶん
おだしょー:自由度が高いという のと 伝統的なUNIXベースの資産
が全部使えるわけじゃないですか テキストファイルに関しては
その層の厚さがやっぱり違います よね Evernoteの使い方で言ったって
それは所詮10年の話ですから UNIXコマンドの歴史を考えりゃ
それでも全然浅いわけで だから やりたいことは大体検索したら
見つかるみたいな嬉しさはあります ね テキストファイルの操作に関
しては でも 一番ハックしやすい ハッカブル
なのがテキストファイルではある とは思いますね
おだしょー:そうですね Log Seekでそれが実現してますけど
本当を言えば他のアウトライナー でもOPMLなりにエクスポートするん
06:05
じゃなくて ファイル形式でOPML なりを使ってほしいっていう気持ちは
ありますよね
おだしょー:そうですね だから ドラマとかでも ドロップボックス
に置いてあるOPMLを読めたら パソコン上が別のアウトライナー
を使って ウェブ上ではドラマを 使うみたいなことができるはず
ですから ドロップボックスとの 連携がうまいこといかないから
そうなったんでしょうけど 現在 多分 でも Gitを使えばまた変わって
くるかな Gitを経由する連携もあり得る と思うんで
おだしょー:多分 そうしたいんだ と思うんですよね
おだしょー:ただ やっぱりドロップボックス よりもハードルがだいぶ上がって
いっちゃうっていうことはある かもしれないですよね
おだしょー:だから いろいろ リッチでない リッチっていう
のはリッチメディアではないし 多少 知識が必要なものの TextFile
をベースにすると ユーザーがアプリケーション を選べるようになるっていうメリット
があって だから 閉じ込められない というか ロックされないみたいな
ところが TextFileとSyncで それを 知識を学ぶだけの価値が そこには
ある気がしますね
おだしょー:そうだと思います
おだしょー:この前 ログシーク をショートカットアプリでメモ
を追記しようとしたら 共有メニュー から追記できるんですけど 余計
なタグがつくと ショートカット APPを使ったときに ログシークが対応
してないと 例えば Evernoteだったら ノートを作るみたいなのがもう
APPにもともと登録されるんですよ ね だから それ使えばノートが取
れるんですけど ログシークはそれが ないと 困ったなと思ったときに
そうだ ログシークはiCloud Drive に入ってるMDファイルであると
テキストファイルに追記するっていう ボタンはあるんですよ ショートカット
に それを使えばログシークに簡単 に追記ができるし それができる
ってことは ほとんどありとあらゆる ものができてしまうということ
なので そう ハックの道に開かれている という点は こういうことが好きな
人間としては大好物じゃないかな という気はしますけども
おだしょー:結局 そういう考え方 が こういうことが好きな人間以外
の人にどう広まるのか 広まらない のかっていうところですよね
三沢:雑に考えれば二極化するん でしょうね きっと だからある種
のノーションでいいっていう人たち と ObsidianとかLogicでないとっていう
人たちに分かれてしまうのかな という気はしますね
おだしょー:難しいですよね 僕は やっぱりどっちかというと手軽さ
09:02
重視になるんで だけど テキスト データのメリットというのは重々
承知している なんかちょっと溝 があるんですよね
三沢:なるほど ここは難しいところ ですよね 個人的にはテキストファイル
の解析というか ある種のルネッサンス みたいなところが 今 改めて認識
されてるんじゃないかなという のが ObsidianとかLogicの流れですね
おだしょー:そうですね
三沢:今回の本題なんですけども プロジェクトについてという この
タイトル自体がちょっと含みがあるん ですけど 僕が問題視している 問題
視というか ちょっと疑問に思って たのが GTTのプロジェクトという
呼び方が 昨今のタスク管理における プロジェクトっていう名称の権
因訳になってると思うんですけど それが 一般的なプロジェクト管理
と呼ばれている分野とのプロジェクト の中身の乖離を感じていたと
Twitterのコミュニティで別の呼び方 をするとか 何かできませんかっていう
ことをこうしたら いろいろな方 からリアクションとか ブログ基地
を書いていただいて この中でも 改めて考えが出てきたんで それ
について話そうかなと思うんですけど うちあわせキャストでもだい
びだびこの手の話はしてて だいたい そのときは僕 プロジェクト的な
ものの管理はどうしてますかって だいたい聞いてると思うんですよ
ね
おだしょー:そうですね
三沢:おそらくそれがプロジェクト っていう呼称に何か違和感を覚えて
いるからやと思うんですけど どこからいきましょうかね GTDのプロジェクト
と呼ばれているものがありまして 情報整理のレベルでいうと 下から
二つ目に当たるのがプロジェクト なんですね 一番下が実際に取れる
行動とかですね
おだしょー:いわゆるタスクですね
三沢:コピーを取るとかって 呼ばれているので それ一つ上の
プロジェクトとかある目的という か求めている状態のことで企画書
を完成する企画書を部長に提出 するとか そういう目指したい状況
があって そこには例えば複数の タスクが必要だと その複数のタスク
を じゃうな プロジェクトを達成 するために複数のタスクが必要
である 逆に複数のタスクによって 達成されるものがプロジェクト
だっていうのがプロジェクト それより上に目標とゴールとか
価値観とかいろいろあるわけですけど この上の階は一旦置いといて
ここGTDは基本的にプロジェクト とタスク Next Actionで日常大体回
12:07
るはずなんですよ かなり主要な概念 というか ただ このプロジェクト
が厄介というか 問題児というか こいつのせいでGTDなりタスク管理
っていうのがうまく回っていない 様子があると それについて考え
たいなというところがあったんですけど Twitterのやりとりで一つまず
新しい発見がGTDにおいて言及 されてる最新のものでは プロジェクト
は一つ以上のアクションを含む ものでいいらしいんですね 二つ
行動が必要ではない 必ずしも一つ のタスクっていうのもアリやという
ところ もう一つ一番大きいのが プロジェクトリストとNext Action
リストは別のものだという考え方 別のものですね
おだしょー:別のものという 考え方がGTDにはあると ここで
問題が一般的に 例えばトゥール ウィストとかは プロジェクトっていう
のを開くと 左にサイドバーに 自分でプロジェクト設定できる
んですけど プロジェクトっていう の開くと タスクリストが出てくるん
ですよね プロジェクト実感する ということは これは左のサイド
バーはプロジェクトリストかつ タスクリストのリストなわけですよ
これはだからGTD的ではないっていう ような指摘をいただいて なるほど
と思ったんですけど このなるほど を説明するのが長いわけですが
よく読んでますね その人 はね
おだしょー:非常によく読まれて 実践されてると思うんですけど
タスク管理ツールとか 何しろアウトライナー を使ったタスク管理でいうと 大体
さっき言った構造になるんですよ ね プロジェクトが
普通に作るとなります ね
おだしょー:プロジェクト名が 並んで その下にやるべき行為が
並ぶと だからコンテキスト別の リストは作らない 作るにしても
例えばタグとかで抜き出して 別で表示させるみたいな感じになってる
と 少なくともそういうやり方は あまりうまくいかないんではない
かと思い続けてきたここ5年ぐらい なんですよ
いかないです
おだしょー:それはなぜなのか っていうとこが 今回のやり取り
で分かってきたと つまりタスク リストとプロジェクトリスト
一緒にしてしまってたと それは うまくいかないんだなという
とこがまず一つの発見 なぜうまくいかないかに行く前に
15:06
この発見をしてすぐにまず思い 出したのが 文章を書くときに
メインの本文を書いているのの サイドバーにアウトライン窓
が欲しいと 正しいそのアウトライン 窓は本文と連動して欲しくない
っていう話を多分以前したと思 うんですけど これと全く一緒
みたいなと思ったんですよ
一緒です
おだしょー:一緒ですよね
一緒です 全く一緒です
おだしょー:ここが繋がって 欲しくないっていうのと プロジェクト
リストとタスクリストは別屋っていう のは多分 これは同じ話で だから
やっぱりそこを繋げるとうまく いかないんだと
そうです
おだしょー:これは繋がってる と ボトムとビジョンの関係がややこ
しくなるからですね きっとね ビジョン がなくなるからっていうこと
なのか
そうですね 難しいですね 使い方が
おだしょー:難しい 難しいんですけど
どうしましょうね どこから いきますかね 僕もそれずっと考えて
たんですけど
おだしょー:どこから切り出せば いいのか まず どっち方面からでも
いいんですけど とりあえずプロジェクト とタスクリストが分かれていることを
直接直結していないことが まず 一つ要件としてあると 僕も読み
返したんですけど プロジェクト リストには行動計画なり 必要な
情報なりは載せないと プロジェクト の名前だけが載ってると その
ほうが一覧できるからみたいな ことが書いてあったんですね 単純
に受け取れば 例えばアウトライナー で項目を回避する機能があれば
別にいいじゃないかみたいに思います よね
おだしょー:おそらくそれは 半分ぐらいは正しいんですけど
半分ぐらいしか正しくなくて 特に アウトライナーはまだしも トゥー
ドゥイストのようなものの場合は これ何回も言ってますけど タスク
しか書けないと プロジェクトっていう のは目指す状態の記述なはずなん
ですね だから文内緒は文章になってる はずって
おだしょー:それを書けない と プロジェクトのレビューがそも
そもできないはずなんですよ リスト はリストでコードのリストを管理
して プロジェクトは自分の目論 見的なものを文章として残して
いくっていうことを可能にする ツールでないと 少なくともGTT的な
管理ってそもそもできないはず なんですよね
おだしょー:そうですね そこは ちょっと難しいと思うんですけど
僕は例えばオムニフォーカスを 使ったことがないから オムニフォーカス
におけるプロジェクトを押したら どんな表示がされるかは分からない
ですけど 一般的なプロジェクト 管理において プロジェクトに関する
文章を主におけるものは多分 ほぼなくて せいぜいコメントで文章
18:05
書けるぐらいかなという 主従で 言うと10に当たるものだと
おだしょー:そうですね おだしょー:この段階でこういう
ツールでGTTを実践するのは恐らく 難しくて プロジェクトのリスト
はテキストエディターかアウトライナー で書かないと多分ダメだなとは
まず思いましたね おだしょー:そうですね 文章
っていうのをGTTと結びつけるか どうかはちょっと難しいとこですけど
でも 言われてることはよく分かり ます
おだしょー:まだ 箇条書きの 行為が書いてあるだけではダメ
っていうことはほぼ間違いない と思います そこは言い通して なぜ
直結していけばいけないのかと デジタルツールで開閉とかして
見えなくなればいいんじゃないか っていう気がしてるんですけど
でも そうじゃないはずだという 思いもあって そこが何なんだろう
かって分かれば もう少しGTTに 捉われないタスク管理の方法が
分かるんじゃないかなとは思ってるん ですよ やっぱり思うのは 実行結果
がプロジェクトにフィードバック されるかなという気がして
おだしょー:されるかな され なければいけない
おだしょー:はい
りなたむ:見えないけど フィードバック っていうのはどう言ったらいい
かな ちょっと難しいぞ 何かを実行 してみるした結果として プロジェクト
そのものが変わってしまったり とか 他のプロジェクトと融合したり
とか だから あるコード わかりました まず インボックスがありますよね
インボックスがGTTは そこに気になる ことを入れていくと 1個1個取り
出して 例えば これはコードや すぐできるコードやって言ったら
Next Action Listに行きますよね すぐ 取れるコードじゃないものを思いつ
いた これが1年以内に実行可能な 自分がコミットしてる対象やと思
ったら それがプロジェクトリスト にまずバッと載るわけですね 自分
がタスクを実行した結果として 最初のインボックスに入れた こう
したいとかっていう状態そのもの が変わってしまうことがあると
目指したい状態が変わるときに それはだから タスクが実行された
からプロジェクトが 例えば 十のうち三進みましたっていう
進着管理だけではない変化が起こる と
おだしょー:起こります 起こります はい
りなたむ:それは だから 直結 してる状態ではそういう変化は
反映されないから そういう管理 してるだけではダメだよっていうこと
かな おそらくは
おだしょー:なるほど アウトライナー 使ってると それはよく分かります
よね
りなたむ:アウトライナーで 言うと 下から上に上がるほうのシェイク
21:01
が行われるということなんですけど 少なくともプロジェクトが固定
ちゃうな だから そう プロジェクト が固定されて ただ進んでいる段階
を表示している 今 だから 五個の うちのタスクの三つが終わった
みたいな管理だけでは 十分なプロジェクト 管理にはならない
だから 繋がっててもいい 直結 しててもいいけど アウトライナー
のように直結してもいいけど プロジェクト そのものが変えられなければ
ならない なぜなら プロジェクト っていうのは 自分がその時点で
望んでいるこういう状態のこと です こういう状態を望むことが
変わったら プロジェクトも変わる から そうですね
GTTにおいては 日常の実行は プロジェクト は多分 ほぼ見ない 見るにしても
ちらっと見る程度で 基本的には ネクストアクションリストを見る
と それは結局 日常生活でそれより 上のことを考えても 実行が生まれない
から
おだしょー:それをカバーする ためにレビューをすることになって
るわけですよね たぶんね
おだしょー:日常生活では ややこしい ことを考えない 工事の判断
もせずに とりあえずやることを やると やることをやってるだけ
では ズレが生じるから 週に1回は レビューしましょうと 自分の中長期
的にやりたいことをもう1回チェック しましょうということ なので よく
1日レビューとか 瞬時レビューとか っていう言葉がありましたが あれ
だとダメなんですね 基本的には 1週間のタームの中で自分のやる
ことを少し工事から見返すという 行為がまず必要であると それを
しないと 基本的にGTDは多分回って いかない だから 1日ごとに見返
してるから 瞬時レビューはいり ませんっていう話には多分ならない
っていうところかな 今のとこ 整理できたのはそういうとこですね
おだしょー GTDはね まずあれなんですよ
ね そもそもこれは批判じゃないん ですけどって言おうとして いや
これ批判だなと思い直して 批判 なんですけど 例えば 今のプロジェクト
を実行した結果 プロジェクト自体 が変化してしまう可能性のことを
考慮してない 例えば タスク管理 アプリのようなものでしてない
24:01
要するにブレイクダウンの発想 しかないんですよね アウトライナー
的に言うと それって結局GTDのプロジェクト だと言いながら 多分いわゆる例えば
会社の何とかプロジェクトとか そっちのプロジェクトのほうが頭
にあるんだと思うんですよ 要するに プロジェクトは固定されていて
その固定されたプロジェクトを 実現するためにどんなアクション
をするかっていうふうに頭がな っちゃってて アクションをした
結果 プロジェクトが変わることは あんまり考えてないんですよね
おだしょー 恐らくは
おだしょー そういうものが多い なっていうのが一つと あと 整理
と実行 整理のためのリストと実行 のためのリストが混同されてる
っていうこともあるし 結局 デビット アレンが提唱したGTDっていうのは
紙なんですよね 元々
おだしょー そうですね もちろん
おだしょー 紙だから ネクスト アクションリストの ごめんなさい
プロジェクトリストの下にアクション を紐づけることができなかった
んだけれども
おだしょー そうですね 一覧性が破綻 しますからね
おだしょー で デジタルで生でそれができて
しまうために おそらくGTDとして はうまくいきにくくなってるん
じゃないかというのは ずっと思ってますよね ネクスト
アクションリストっていうから どうしてもプロジェクトのプロジェクト
名の下に次のアクションはこれ その次のアクションはこれって書い
ちゃうんですよね アウトライナー 的に言うとブレイクダウンなんですけど
デビットアレンはそんなことは 言ってなくて プロジェクトリスト
はプロジェクトリストで貼って
おだしょー コンテキストは別にリスト 性って言ったから そこのリスト
ではプロジェクトは紐づけられて ないんですよね
おだしょー そうそう プロジェクト リストを眺めて 次これやんなきゃ
いけないな これやんなきゃいけない なっていうアクションを書き出した
のがネクストアクションリストで そのネクストアクションリスト
を効率よく実行するためにコンテキスト ベースに分けなさいという考え方
だったんですよね これをプロジェクト の下にアクションを紐づけちゃう
から 逆に全てのプロジェクトの 全てのアクションを綺麗に並べ
なきゃいけないような気がしちゃ ったりとか
おだしょー なるほど
おだしょー それを 気まじめな人が厳密にやろう
としてパーンってなっちゃうんですよ ね
だけど実際にはこのプロジェクト リストを眺めて そうだ 次はこれ
やんなきゃ 次はこれっていうレベル 程度のことしかやらなくていいん
ですよね 多分DT的には
おだしょー そうですね きっと
おだしょー ただし 定期的にレビュー をする 毎週1だる1でレビューを
することによって 常にそのネクスト アクションリストを最新の状態
27:03
に更新しておくいうことが求め られるということで だからむしろ
アナログだからうまくいくんじゃない かっていう気がするんですよね
おだしょー 確かに 本質的にアナログだと思うん
ですよねGTDって おだしょー そうかもしれません だからこそ
デビューとあれがどれだけ頑張って もGTDのツールができないという
悲しい結末になるんかもしれない ですね
おだしょー そうなんですよね 生地できちゃう
から 紐付けができちゃうだと
おだしょー ってかしないと不自然 ですもんね そんな動画がない
と言っても おだしょー オムニフォーカスのユーザー
コミュニティのコメントとか見て ても オムニフォーカスもやっぱり
そうなってんですよ ただプロジェクト名に長文を入れ
られるっていう面はあるんですけど でもやっぱりプロジェクトリスト
の下に プロジェクトリストをブレイクダウン
する形でアクションを書きたくなる ような構造になってるんですよね
やっぱアウトラインだから ユーザー コミュニティの人が これをプロジェクト
が完了するまでの全アクション を書き出さなくていいんだって
言ってる人がいて っていうことは ほっとくとそれをやろうとしちゃう
人が多いっていうことですね おだしょー そうですよね
おだしょー だけどそれこそ文章 を書く前にアウトラインを作ろう
とすんのと同じで その通りにできる わけないんですよ
ね できるのは このプロジェクト
に関する次のアクションは何か って考えることは多分できるんです
よね だから実はそれだけやればいい
と おだしょー そうですよね だから
そうそうそう だから僕も例えば 今 進めてる本とかって 例えば
13章伊達ぐらいですけど 伊達や から ぐらいやから 13章って決まってない
っていうとこがもうすでにナチュラル フラーニングができひん理由なんです
けど 例えば今 初心者の頃は確実 に13個のタスクを立ててたんですよ
つまり第1章第2章 おだしょー すっごい分かりますけど
おだしょー これをより細かいレベル でやることもできますよね それぞれ
の章の内訳を 例えば1から4まで とかって すごいかっちょいいタスク
リストができるんですけど 超合金 のようなタスクリストができるん
ですけど 途端に嫌になってくる 上に さっき言った書いてるうち
に章立てそのものとか数とかが 変わってくると そうなってくる
と やっぱりリストに対する不信感 も芽生えてきますし あんまり見た
いものではないと 最近は本当に 結局考えてみるとGTDに帰ってきて
るような気がするんですけど 次の ことしか書いてないんですね 僕
毎週1回 最近プロジェクトをレビュー するようになってるんですけど
30:03
まずプロジェクトっていう そうか あれやな Zoomなんで画面共有しましょう
か 久しぶりに Textboxというところに プロジェクト
というページがあるんですね プロジェクト の名前は別に何でもいいんですけど
THみたいなプロジェクト開くと そのプロジェクトに関する情報
がそこに集まってると
おだしょー かっこいい
おだしょー ちゃんとリンクになってるん です それはいいんですけど 一番上
にピン止めされてるものがあって Part1の書き直し 本番書きっていう
ところ これはいわゆる僕の中の Next Action Next ActionはNextプロジェクト
に近いですけど 琉大でいうと そこを開くと 一週1回振り返り
があって これこれこういうことを したから 次はこうなるみたいな
ことが一週間ごとに書いてある それは普段は見えないようにしてる
と 普段はそのPart1のカラフルだけ 見えたらいいっていう状況にしてるん
ですよ よく考えたら これってもの すごいGTDやなっていうところに
今 話しながら気づいたんですけど だから僕もこれ ダスクリストとは
全然関係ないんですね ここのページ っていうのは ただプロジェクト
の情報がここに集まっているだけ ってなってて ダスクリストはダスクリスト
でまた別にあるし そのダスクリスト もさっき言ったように13章のタスク
が並んでいるわけでもないと これ やっぱナチュラルな感じですね
おだしょー:そうですよね
瀬尾:明らかに このただダスクリスト とプロジェクトを一つにまとめ
ようとすると そのツールのUIに 縛られてしまうと 入力できるもの
とか表示形式が 苦しい思いをして しまうと だからここで効率化を
進めばだめなんだなっていう話 かな
おだしょー:そうですね
瀬尾:だからタスク管理ツール じゃないものであれば もしかしたら
違った道が開けてくるかもしれません けど もしかしたら統合的に扱える
もの でも通常のタスク管理である と 課上書きのリストしか扱えない
ことが大半なので そうなるとプロジェクト リストがタスクリストのただ親構造
を並べてるだけのものになって しまうと これは情報的にも不足
するし さっき言った構造の変化 にうまいこと対応できないと だから
こういういろんな面でGTDが真の 意味では理解されてないし それは
やっぱりプロジェクトって名前が 悪いんじゃないかなと
おだしょー:そうなんです その言葉が悪いんじゃないかと思
うんですよね
瀬尾:確かにプロジェクトっていう 言葉自体が間違ってはいなくて
これを何と呼ぶかというと それは プロジェクトって呼ぶしかないん
ですけど プロジェクト管理の用語 とか操作方法がユーザーにも入って
くるし ツール開発者にも入って くるし 結局 実装がそっち向けに
どうしてもなってしまってる状況 があるんかなっていうのが今 感じ
33:04
てるとこですね
おだしょー:だからアウトライナー 的な考え方で言うと プロジェクト
とアクションもしくはタスクって 分ける必要ないと思うんですよね
その大きなアクションのことだ と思うんですよ プロジェクトって
GTD的なプロジェクトって だけど 元のGTDは紙であったためにプロジェクト
リストとNext Action Listっていう 別のリストを作ったわけですよね
瀬尾:そうですね
おだしょー:それは紙という 制約があったからそうしたんだ
と思うんですけど だけど それぞれのリストをデジタル化
して しかも これは一緒に扱えば 効率的だなと思っちゃうような
思考が多分働くんだと思うんですよ ね
瀬尾:普通にそうなると思います けどね 普通に考えたら
おだしょー:そうすると 例えば アウトライナーを使っていても
それをそのままアウトラインに 記述しちゃうんですよ そういう
構造を これは別にそれを意識した わけじゃないんですけど 例えば
僕がアウトライナーでライフアウトライン というものを作ったときに 自然に
AllっていうのとDaysが分かれるん ですよね 日々やるリストと全部
のリストが自然に分かれた 自然に っていうか 分かれてないと不便
だから分かれたんですけど 便宜 的に分けただけなんですけど 多分
正しいんですよね
おだしょー:そうですよね きっと
瀬尾:だから 多分 純GTDを例えば アウトライナーでやるとしたら
やっぱりプロジェクトリスト 何 いう名前で呼ぶかは別として プロジェクト
リストとNext Action Listは 多分 別のアウトラインにしたほうが
いいんですよね そういう気がします だから 情報の構造関係で言えば
GTDのほうを参照すると 一番上が 目的 価値観なんですね その人の
人生にとっての一番の目的 内緒 価値観で 下にビジョンがきて その
下に目標がきて その下に注意を 向けるべき分野 責任を持っている
分野があって プロジェクトがあって 行動があるんですけど これはだから
イメージとしてはピラミッド型 なんですね 当然 それは別に何も
間違ってはいない でも 問題は それを例えばアウトラインの構造
にしていいかというと これ 下 駄目なんですね
おだしょー:駄目なんですよ
りなたむ:例えば 一番最初に 目的っていう項目を作って その
下に自分の目的を書くと その書いた 下にビジョンを書くみたいなことは
これ駄目
おだしょー:駄目なんですよ
りなたむ:駄目なんですね やる としたら目的っていうのを作って
それを1回閉じて 強大項目として 構造ビジョンを作るっていう形
36:03
にする それはなぜならばツリー 構造のように1対1の関係として
つながってるんじゃなくて むしろ ネットワークのように下と上が
複数につながってることが もちろん あるわけですから そこを意識しない
と このアウトラインだけじゃなくて エトセトラも全部うまく使えない
で 純GTTで言うとコンテキストリスト じゃないですか コンテキストリスト
っていうことはプロジェクトに 紐づいてないわけで その1つの
行動が複数のプロジェクトに結 ぶって言っても全然オッケーな
わけなんですね
おだしょー:そうです
りなたむ:ある図書館に行って 調べるっていうのが複数のプロジェクト
に結ぶって言っても問題ないけど プロジェクトを先にしてしまう
と1個にしか所属できないから ややこしいことになってしまう
と
おだしょー:そうですね
りなたむ:だからコンテキスト リストが本当に有用かどうか別
としてタスクリストとプロジェクト リストは分けたほうがいいっていう
のはこれ結構明確になってきました ね
おだしょー:明確だと思います 明確だと思います たださっきの
整理するアウトラインと実行する アウトラインの混同っていうのも
そこでまた話が出てくると思うん ですけど 整理するアウトライン
というか考えるアウトラインですよ ね 考えるアウトラインと実行する
アウトライン 例えば私のアクション というかタスクはどういう構造
になってんのかな 例えばGTDの本 を読んでないとして 自分の例えば
人生の目標と今日のアクション はどんな関係になってんのかな
っていうときにアウトラインで こうでこうでこうでって考える
ときにそれが一つの巨大なピラミッド 型のアウトラインになってもいいん
ですよ 多分
りなたむ:ならざるを得ない でしょうね それは
おだしょー:そうか こうなってん のかと これ実際僕の中で起こった
ことですけど こういう構造なんだ なと理解することと それを日々
実用するアウトラインとしてそれが 使えるかっていうのは別問題で
日々使おうとすると多分もっと ずっと階層が浅くてパートごとに
分割した別々のアウトラインにしない とおそらく使えないんですよね
だけどその構造は考えるときには 一つのアウトラインの中で考えた
ほうが多分
りなたむ:便利ですね
おだしょー:理解がしやすい というか
りなたむ:これも結局アナログ でいうとどうなるかっていうと
一番上の価値観を書いた紙がある と その紙を見ながらメモすると
自分に必要なことが何かって それはインボックスに直接入る
わけですよね
おだしょー:そうですね
りなたむ:だからリストは別 なわけですよ 絶対に
おだしょー:別なるんですよね 勝手に
りなたむ:別なる上ないっていう か でもアウトライナーであれば
紐付けで書き出した後に移動できる から 別に最初は一緒に書いても
別に構わないっていうことは言える と思いますけど
おだしょー:そうですね
りなたむ:だから そのままの構造 で使おうとするとやっぱり難しい
39:00
ことになるから その下のライン は別のとこに移動させるっていう
アウトライナーでやる場合はその ほうがいいし 普通のタスク化に
する場合はリストを別に作って おいて 思いついたことをインボックス
に個別に入れていったほうがいい と だからプロジェクトはやっぱり
タグで十分ですよね プロジェクト のグクリじゃなくて カテゴリー
じゃなくて 使うとしてもタグでいい と思いますね
おだしょー:僕 あんまりタグ を使わないから
りなたむ:そうですよね
おだしょー:あれなのかもしれない ですけど 手動で別々にリストを
作るのが一番いいんじゃないですか ね
りなたむ:そうかもしれないですね
おだしょー:多分 それが二度 手間っぽく感じるかもしれない
けれども おそらく効率という点 でもそのほうがいいんじゃない
かと思う
りなたむ:そうでしょうね
おだしょー:ですよね どうなのかな 状況にもよるでしょうけれども
難しいですね 逆にそれこそ会社 のプロジェクトみたいな 自分の
プロジェクトリーダーみたいな のとして プロジェクトを三つ任
されているみたいな状況のときに そういう意味でのプロジェクト
は さっきダメだって言ってた構造 のほうがいいかもしれないんですよ
ね 多分
りなたむ:大幅な変更も迫られない し むしろそのとおりにやることが
任務やという場合は そうでしょう ね
おだしょー:難しいのは 例えば 会社員だったら そういう意味での
会社のプロジェクト的なプロジェクト と 個人のプロジェクトを 恐らく
両方 当然恐らくじゃなくて 当然 両方抱えているわけで そこが混乱
することはあるかもしれないですよ ね
りなたむ:最低の間違いがあって 思うんですけど 例えば 本の執筆
っていう 僕の仕事のプロジェクト の場合は 裁量がほぼ僕にあるわけ
じゃないですか 大げさに言うと でも 例えば セミナーとかにゲスト
で呼ばれてて そこでしゃべらな かみたいなのは 僕の裁量はほぼない
わけじゃないですか これはいわゆる 任務型のタスク管理でいけるん
ですね 僕の裁量の場合は 一番大きい 根本レベルで変えることができる
から プロジェクトそのものをリスタート したりとかっていうことができる
し すべきなときもありますから それはいわゆる任務型のタスク管理
ではうまくいかない あるいはプロジェクト 管理ではうまくいかないっていう
ところがあって プロジェクトの 性質によっても違いますし 自分の
裁量によっても違うから だから 一つ思うのは プロジェクトの扱い
は絶対に一種類ではないはずだと そこの区別が少なくともGDDには
見えてこないと おそらく実行した 結果がプロジェクトに跳ね返って
42:02
くるのは 要するに 終始レビュー のタイミングなんですよね だから
GDDがうまく回せてる人は終始レビュー でいわゆるボトムアップ的な
ことをやっておられると思うんですよ だから そこは言語化されてない
というか ノウハウとして書かれて はいない そこを補完するための
やっぱり デイリーアウトライン とかシェイクっていう考え方は
そこをきちんと補完してくれるん で だからシェイクはGDDを配達する
ものじゃなくて むしろ強く補完 するものですね きっと あれはレビュー
をよりはっきり解像度を上げる 行為だと思いますけど
>> 谷川 シェイクってレビュー そのものなんですよね
>> 三沢 そう そう それを違う 呼び方 あるいは行われるタイミング
とかが違う >> 谷川 そうですね だから 順次
TDをうまく回せてる人って 多分 プロジェクトリストを書き直してる
と思うんですよね
>> 三沢 恐らくそうでしょうね
>> 谷川 うん 多分 多分 毎週 新しくプロジェクトリストを書き
直すぐらい書き直してる人って いると思うんですよね
>> 三沢 うん いや 僕の場合は 書き直すって非生産的じゃないですか
って 変な言い方やな 変な言い方 やな 何を新しく生まないじゃない
ですかから 書き直すっていうのは で 読み返すも何も生まないんで
だから 僕はさっき見せたように 毎週なんか書いてる 書き足してる
>> 谷川 書き足してる はい
>> 三沢 書き足して 何か生み出してる 気持ちになってるっていうこと
ですけど でも やっぱりやってる ことは一緒なんですね だから
次のアクションが何が必要かについて 自分が今どうしたいのかを毎回
書いてる その意味では だから プロジェクトを毎回書き換えてる
って言っても 多分 いいと思うんですね
>> 谷川 そうですね うん まあ だから あれですよね 実際に書き
変えるかどうかと思う
>> 三沢 各々別にしてっていう
>> 谷川 うん ってことですよね
>> 三沢 だから ただ プロジェクト があるな 終わりじゃなくて それって
どういうことだろうを毎回 毎週 考えてるっていうことだと思います
ね
>> 谷川 そこがちゃんとできて たらいいでしょう あとは だから
それを促す作りになっているか で そこでは やっぱり文章の形で
書かれてることが 僕は必要だな と思うんですけどね
>> 三沢 いや 必要ですよ
>> 谷川 うん ここのレビューっていう 観点においては やっぱり文章で
残ってることが必須に近いかな という気はしますけど
>> 三沢 うん 少なくとも その 過剰書しか書けないという環境
は多分 ダメですよね
>> 谷川 うん うん うん うん うん うん うん うん うん うん うん
あと だから アウトライナーの場合 も 読みやすくない場合があるんで
>> 三沢 はい
>> 谷川 そこがちょっとネックでは ありますよね
>> 三沢 ネックですね うん
>> 谷川 そうか その点 だから 僕はさっきのテキストボックス
は見栄えを整えるという役割が あるので スタイルを整えるという
45:04
役割があるんで あの形になってて でも 結局 長くつられたら見にくい
から閉じる機能必要だろうなと思 って 閉じる機能つけたんですけど
>> 三沢 はいはいはい
>> 谷川 やっぱりアウトライン 的なものは必要だなっていうのは
思いましたけど
>> 三沢 うん うん うん うん
>> 谷川 なんか 結局 自分にとって 一番より
>> 谷川 うん うん うん
>> 三沢 そうそう いい形
>> 谷川 安い形を作ってるわけ ですよね あれは
>> 谷川 うん うん うん
>> 三沢 そう だから紙の場合も だから結局デザインできるじゃない
ですか 書き方とか
>> 谷川 はいはい
>> 三沢 だからそこも大きかったん じゃないですかね きっと
>> 谷川 そうですね その そう キラキラに飾るという意味での
デザインじゃなくて
>> 三沢 そうそうそう 文字の配置 とか 何にどこに何を書くかっていう
裁量が自分にあったわけですから
>> 谷川 うん そうですよね だってあれ デビッドアレンのセミナー
の動画とか見ると リストアップ するっていうと どうしても紙に
過剰書きで書いていくみたいな イメージするじゃないですか
>> 三沢 はいはいはい
>> 谷川 なんか それでもいいんだ けど それよりも A4みたいな紙に
1枚に書いて それをボンボンインボックス に放り込んでいくんですよね
>> 三沢 ああ 1枚1案件で
>> 谷川 1枚 そう
>> 三沢 はいはいはい
>> 谷川 で その後 1枚ずつ処理 していくと 場合によっては 紙が
そのまんま実行して丸めてしちゃう 場合もあれば その紙が別のフォルダー
に移動していくこともあるっていう ですね 1枚1枚紙になってるって
いうことの柔軟性っていうのは やっぱすごいなと思いますね
>> 三沢 マックのカード法ですね
>> 谷川 そう カードと同じですね そのときに 場合によっては カード
と違うのは 紙大きいじゃないですか 4要紙から そしたら場合によって
は真ん中に線引っ張って 右と左 に何か書いたりとか 丸と矢印
引っ張って何か書いたりとかいうこと もできるし
>> 三沢 ああ そうか そうしておけば 例えば より細かい作業が必要
になったら その紙の余白により 細かい作業を置けば
>> 谷川 そうそう
>> 三沢 一層になるわけですから ね
>> 谷川 そうなんで 要するに それこそ 文章とか何か手順みたい
のを追記することもできるし
>> 三沢 それは結構 アウトライナー 的ですよね そこ言っても
>> 谷川 アウトライナー的ですね これはね Grandviewというアウトライナー
昔使ってたんで あと そのNext Action Listじゃなくて パタッと挟むプラスチック
のフォルダでNext Actionって書いて あって そこに紙をボンボン投げ
込んでたりもするし それは別に リストを作ってもいいし そういう
フォルダの中に紙を 一アクション 一枚みたいな感じで紙の束を入れて
もいいっていうんですよね
>> 三沢 はい なるほど
>> 谷川 要はだから 自分のやり たいような形でやればいいって
言うんですけど
>> 三沢 そうですね
48:00
>> 谷川 ただ やっぱりアナログ なんですよね
>> 三沢 さっきストレスフリー の誠実実践編を読んでまして 2010
年って書いてあるんですけど アレン は会議のメモとかをマインドマップ
で取ると 多分デジタル数ですね マインドマップで取るって書いて
あって へーと思って その絵をプリントアウトして マインドマップをプリントアウト
して インボックスに放り込むんだ って書いてあったんですよ 実に
見事やなと思ったんですよね
>> 谷川 見事ですね
>> 三沢 やっぱりアナログなんや なと思って でも 確かにそれはGTD
的な処理やなと思いましたね それは
>> 谷川 そうなんですよ だから デジタル的な処理をアナログで
やってるんですよね 決してデジタル に弱いからアナログにやってる
わけじゃなくて 多分アナログが 一番自由で手軽だという感覚が
多分
>> 谷川 そうでしょうね きっと
>> 谷川 あったんでしょうね あと80年代からやってるわけだから
昔はアナログじゃなきゃできなかったん でしょうけど だけどやっぱり
物理インボックスって要するに 紙も入れられるし 例えば これも
なんか動画にあったんですけど ボイスレコーダーの関連値を変え
なきゃいけないっていうのをタスク として書くんじゃなくて 切れた
関連値をそのまんまインボックス に放り込むんですよね
>> 三沢 物理マイナーですね
>> 谷川 それ見りゃ分かるだろう と
>> 三沢 なるほど
>> 谷川 確かにアナログの柔軟性 って馬鹿にできないなとは思います
よね ただ 今 物事のやりとり自体 がデジタルになっちゃってるから
逆にそことの親和性が薄れちゃう かもしれないですけど
>> 三沢 そうですよね 先ほどマイン のマップも例えばスクリーンキャプチャー
を取って 例えばどっかエヴァとかに 送るとして 紙の場合と等価っていう
かっていうと やっぱ等価じゃない ですよね
>> 谷川 ない
>> 三沢 取り込めないですから やっぱり マインのマップの場合
はマインのマップの書いてある ことをやったら赤ペンとかで消して
いけば それがタスクリストになる わけですから エヴァのデモできない
わけではないですが ちょっと苦しい ところはあって
>> 谷川 面倒ですよね
>> 三沢 面倒ですね 紙に比べる と面倒ですね だから そうですね
なんかこうインボックスの概念 とかももう一回ちょっと考える
必要がありますし プロジェクト のリストはプロジェクトのリスト
で作るっていう 結びつけないっていう 考え方もちょっと再確認したほう
がいいかなと それはそれとして やっぱりそれはもう一回GDDに変
えるとしても さっき言ったプロジェクト によっては扱い方っていろいろ
あるよねっていう話はGDDからさらに 話を広げていきたい
>> 谷川 そうですね そこは多分 カバーされてないですよね
>> 三沢 はい と思いますね
>> 谷川 要な
>> 三沢 だからね あとそのアナログ なGDDが本当は別々に作ってたリスト
51:09
を実は内心運では結びつけたい と思ってたけど紙だからできなかった
だけなのか それとも本当にあえて そうしてたのかっていうのを聞いて
みたい もし機会があるなら聞いて みたいんですけどね
>> 谷川 紙というツールの中で 一番最適化された方法がそれやった
ということなんでしょう だから おそらくGDDのほうにプロジェクト
リストには余計なものを書いて はいけないって書いてあったんですよ
ということは書いた経験がある ということだと思うんですね きっと
>> 三沢 そうでしょうね
>> 谷川 だからそういう機能しない やり方が淘汰されて やっぱり機能
するのってこうだよねっていうこと に必然的に落ち着いたんでしょう
ね だからGDDをデジタル運用する 場合ってそれをちゃんと考える
デジタルと同じようにやればいい って話ではないですけども ツール
が分かれてたことにちょっと思い を馳せる必要はあるでしょうね
>> 三沢 そうですね あと いわゆるGDDの思想の影響を受けた
タスク管理アプリのことがGDDだ とつい思っちゃうけれども
>> 谷川 そうですね
>> 三沢 そこがやっぱり結構違うん じゃないかなと思いますよね
>> 谷川 今回改めて思いましたね
>> 三沢 難しいですよね
>> 谷川 いや プロジェクトを作って そこにタスクリストを並べることが
結構GDDっぽいと今までずっと無 自覚に思ってましたけど 全然GDD
じゃないなっていうのは思いました ね
>> 三沢 違うんですよ それはね
>> 谷川 違うんですよね
>> 三沢 だけど普通そうやります よね
>> 谷川 そうやりますよね
>> 三沢 普通に考えれば
>> 谷川 そう だからタスクその ものはプロジェクトから生まれて
くるから そうなるのはナチュラル といえばナチュラルなんですけど
でもやっぱり分けたほうがいい タスクをさっき言ったように行為
とプロジェクトが一対にならない 場合もありますし行為の結果がプロジェクト
のタスクを変える場合もあります し変えるどころかプロジェクト
が潰れる場合もあるんですから ね
>> 三沢 そうですね
>> 谷川 なんか参照書を書いてみ たらこの本ダメだと分かったみたいな
>> 三沢 ありますからね そういうこと もプロジェクトの可変性も含めて
運用していくっていうところかな
>> 谷川 そうですね そうだから その可変性のところをその本を
書くっていうのが一番多分分かり やすいと思うんですけど可変性
だからあるプロジェクトが次の アクションからそれが完成する
最後のアクションまでなんか10アクション ぐらい書いたとしても実際に取り
かかるとあれ書いてない別のアクション が出てくるじゃないですか
>> 三沢 出てきますねはい
54:00
>> 谷川 で結構一生懸命それに 時間を割いてやったのによしやった
な今日はやったなと思ってそれ チェックしようと思ったら何も
チェックできなかったりするんですよ ね書いてあることが
>> 三沢 そうですね
>> 谷川 結構やっぱりそれって 心理的なダメージになりますよ
>> 三沢 確かになりますね
>> 谷川 だから逆に何も書いてない 状態で例えばプロジェクトAを見
たときにパッと次にやることが 頭に浮かんだらそれを書いておいて
それをやったらチェックするっていう のを繰り返すっていうのが結果
的には効率の面でも精神衛生の 面でも
>> 三沢 精神衛生の面でいいのは 確かですねアレンよくそのやり方
をしてると頭に思いつくことしか やらなくなるとつまり偏ってしまう
>> 谷川 はい
>> 三沢 言うからちゃんと上の ことをレビューした上でプロジェクト
の次のタスクをあらかじめ決めて おいたほいとは本人は言ってます
本人は書いてましたね
>> 谷川 なるほど
>> 三沢 それは確かにそうだろう なとはちょっと思いました
>> 谷川 そうですよね
>> 三沢 読んでて
>> 谷川 だからあとあれですよね その先のタスクを書いてもいい
思いついたらもちろん忘れない で書いといてもいいんだけれども
これを全部こなさなきゃいけない 順番にこなさなきゃいけないっていう
発想にはなっちゃいけないっていう のですよね
>> 谷川 だからいわゆる僕の定義 で言うとトゥーズリストとデイリー
タスクリストっていったら集合 の大きさはデイリータスクリスト
のほうが小さいわけじゃないですか 同じようにプロジェクトの全タスク
とネクストアクションリストって いったらネクストアクションリスト
のほうがちっちゃいんですよね
>> 三沢 はいそうですね
>> 谷川 ただ僕はパート1を書き直す っていうネクストアクションを持ってます
けどやるべきこととしてパート 2とパート3がありますけど
>> 三沢 はいはいはい
>> 谷川 着手できませんもんね 1書き終わらないと
>> 三沢 そうそうそう
>> 谷川 だからネクストアクション に載せるのは1だけなんですね1だけ
であるべきなんですけどでもイメージ として何か1.2.3を書いてしまう
だってやることやからみたいな 感じでそういう特にトゥーズリスト
の場合はどういう点かなタスク しか載せられないからだから書く
しかない記録しておきたかったら 書くしかないっていうことか
>> 三沢 そうですね
>> 谷川 タスクとして書くしかない っていうだからそれを保存できたら
いいんかなタスクにするタスク というか次のアクションにする
ものとそうでないものをちゃんと 合わせて保存できたらいいと
>> 三沢 だから現状ではやっぱり そういう柔軟な使い方を許して
くれるのはやっぱりアウトライナー でもいいしテキストファイルでも
いいんだけれどもやっぱ汎用ツール だということになるんですけど
でもそういうことをちゃんと意識 してちゃんと機能するタスク管理
ツールができそうな気もするんですよ
>> 谷川 そうですよね
>> 三沢 そうですよね
>> 谷川 それは全然できると思います
>> 三沢 だけど結局デビッド・アレン も自分のオリジナルのそういう
57:08
ツールっていうのは作れてないん ですよね多分なんか設計案みたいな
ものを公開したことがあるんですよ すんごい複雑な
>> 谷川 そうでしょうね
>> 三沢 だけど多分これ作っても 使えないよなっていう感じはします
ね
>> 谷川 わかんないですけどね
>> 三沢 だから5つ価値観とかの 高度のラインを持っててでNext Action
をコンテキスト別っていうのを何か 違うやり方に置き換えたいなという
気がだって携帯電話でできる仕事 ってほぼ無限にあるじゃないですか
例えば
>> 谷川 今そういう意味でのコンテキスト はもう機能しないですよねでも
なんか今やっぱりログシークとか を見ても分かるとおりその代わり
としてデイリー日付っていうの が出てきてるっていうのはそういう
流れなんじゃないかなっていう気 がしますよね日付なら必ず使え
ますよ誰でも
>> 三沢 誰でもね万人に
>> 谷川 だからもしかしたらNext Action +コンテキストじゃなくProject
List +日付かなどうなんだろうな 完全に代わりにはならないかもしれない
>> 三沢 そうですね完全に代わり にはならないのがちょっともどかしい
ところですねこれは
>> 谷川 コンテキストをオムニフォーカス が今のバージョン3になる前今は
結局タグになっちゃったんですけど バージョン2のときはコンテキスト
だったんですよねコンテキスト 1アクションに一つのコンテキスト
しか割り当てられなかったんです だからそれが窮屈なんでいわゆる
普通のタグに変わっちゃったんですけど だけどそのコンテキストだった
ときにそのコンテキストをどう 使うのがいいかみたいなすごい
ユーザーコミュニティが議論する わけですよねでなんかこう自分の
エネルギー量を分けたらいいん じゃないかとか
>> 三沢 元気なときと疲れてる ときとかそうですよね
>> 谷川 そうそうまあそのまでして コンテキストを使わなくていいん
じゃないかなと思ったんですけど
>> 三沢 そうですね例えばデイリー タスクリストだったらその元気な
ときを上に並べて元気じゃない ときを下に並べてとかってねその
順番で制御できるんですかね別 なの
>> 谷川 あとねそのかかる時間 でその1時間2時間タスクと30分タスク
あと15分タスクと5分タスクみたいな のとかね
>> 三沢 そうそういうの精密に やろうとすればするほど複雑になって
くるんでどっかバランスいいとこで 着地させないと実用的にはならない
1:00:06
ですよね
>> 谷川 そうですねコンテキスト はもう本当に使いようがないですね
外出先のついでにどこそこで買い物 するっていうのはできる
>> 三沢 もちろんそうですね
>> 谷川 それ以外はないただやっぱり デビットアレンの時代にはやっぱり
電話とかパソコンとかっていう のが確かに意味を持ったんですね
その頃は職場とかね
>> 三沢 そうですね僕らはもうデイリー 派でデイリー派でなんか困ってる
かっていうとそんなに困ってはいない ただやるべきだなと思ってても
優先順位が低いものは永遠に先 送りされるっていう問題を抱えて
ますけどこの方式の場合
無理やりな優先順位の底上げみたい なのができなくて今日やろうと思
いついたことをやるわけですから やっぱそこでは好意の偏りがあります
けどでもGTDって生産性の拡大を 目指している手法なので逆に生産性
こだわらない手法に関しては別に そこに準拠する必要全くなくて
僕は最近そっち派ではあります ね
>> 谷 結局プロジェクトを別名 で呼ぼうという話から始まって
結局GTDのプロジェクトを再確認 したという非常に重要な体験やったん
ですが
>> 谷 そうですねでもやっぱプロジェクト の他の名前ってあんまり思いなんだろう
ななんか大きなアクションとしか 言いようがない
>> 谷 いやビッグタスクとかになっちゃいます からねそれは結局分かったのか
分かってないのかっていう感じ になりますしだから僕らの口に
馴染んでるからこそこうやって 使われてるわけですからねプロジェクト
という
>> 谷 そうですねやっぱりプロジェクト って頭に思い浮かべるものが結構
人によって違いますよね
>> 谷 そうですね特に企業が入って 働いてプロジェクトっていうのを
回してる人によっても違うしその 回している高さくらいの高さによって
も多分違う
>> 谷 違いますね
>> 谷 下の方はとりあえず上から 降ってくるのをなんとかこなす
ということになりますからね
>> 谷 そうなんですよね
>> 谷 だからプロジェクトについて 考えることに慣れてるかどうか
ってことか要するに裁量が高い 人ほどプロジェクトについて考える
のには慣れてるということだと思います けど
>> 谷 そうですねただ裁量が高く なくても結局その割り当てられた
そのプロジェクトなりなんなり をどうやるかっていうことに関する
裁量はある程度あるわけで
1:03:00
>> 谷 そうですね
>> 谷 結論的には他の名前は思いつ かないですけどでもそもそもプロジェクト
リストはNext Actionリストは別の リストだったっていうことを再確認
することは結構大事ですよね
>> 谷 それはめちゃくちゃ大きかった ですねいやだからプロジェクト
はプロジェクトでよくてGTにおける プロジェクトの管理をもう一回
再確認するっていうこととあと プロジェクトの扱い方ケアっていう
かなそういうものを例えばほに わらだ型プロジェクトはこうとか
ほにわらだ型プロジェクトはこう するみたいな区別ができたらより
実践しやすいかなという感じですね
>> 谷 そうですね会社のプロジェクト みたいなもう一段上なのかもしれない
ですけどね
>> 谷 そうですねもしかしたら
>> 谷 高さ高度でいったら
>> 谷 確かにそうそうだから社長 の考えたプロジェクトっていうの
があってそれを例えば部門レベル でより細かいプロジェクトか中
レベルのプロジェクトとして割り 振られるみたいなこともあります
からね
>> 谷 そうですねそれは担当者個人 から見たらもしかしたらゴール
とかそういうものに近い
>> 谷 そうですねそういうことも
>> 谷 かもしれない
>> 谷 確かに確かに
>> 谷 でもこの中長期のコミットメント をケアする情報の扱いみたいな
のはやっぱり今日やったら終わる っていう情報とは違うわけでこれ
が多分タスク管理の非常に大きな テーマですよねこの中長期の管理
が
>> 谷 そうですね
>> 谷 そうですね
>> 谷 そこの視点が入ってるタスク 管理アプリってそんなにない
>> 谷 ないですね
>> 谷 はい
>> 谷 そうだから特にアウトライナー とか特にワークロリとかでさっき
言った大構造を作るとどの階層 も同じ最期的に作られるんで違い
が見えにくいというか
>> 谷 そうですね
>> 谷 むしろこれ兄弟で並べた ほうがやっぱ違うっていうことが
はっきり分かる気がしますね
>> 谷 そうですね
>> 谷 そうか
>> 谷 何か
>> 谷 同じ階層に並べる
>> 谷 っていうほうがそれで上下 そこに上下を持ったほうが一つの
階層構造の中に入れるよりはより 扱いやすくなる
>> 谷 そうですねだから文章じゃなくても
多分実用するアウトラインは浅い ほうがいいんですよ
>> 谷 うんそうですねそうなりますね
結局は
>> 谷 階層を浅くしようとすれば 自然に多分固まりごとに同じ階層
に並んでいくんですよね
>> 谷 なるほど
>> 谷 うんそうかそうかそうか
>> 谷 これを結構でもアウトライン 作り方とかタスクリストの作り方
でいやまあ新しいといえれば原点 をちゃんと参照する形でちょっと
1:06:04
変わってくるかもしれないですね
>> 谷 そうですねでもアウトライン でそういうことを言ってる人は
そんなにいなかったと思います けどただやっぱりその純GTDその
アレンのGTDを改めて見直してみる とねやっぱり結構すごい
>> 谷 うんというのは思いますね
>> 谷 凄いんですよ
>> 谷 結構やっぱりね一周回って もう一度見たら正しかったっていう
のは結構感じますよね
>> 谷 いうことがありますねあと 1ページしか書いてないですけど
まあ日記を書いてるって言って 日記を書いたのを見てみたっていう
>> 谷 本物書いてありました
>> 谷 ああそっきとですね
>> 谷 もう一つの作業記録的な 日記ともっと内面に踏み込んだ
日記があってでそれは2つのする じゃあ一つの日記で書いてたけど
分けた方がいいことが分かった って書いてあってああなるほど
と思ったんですけど
>> 谷 へえそれを覚えてない人
>> 谷 それを覚えてない人
>> 谷 1ページしか書いてないです からいやだからまだまだ全然読み
込めてないなあっていうのをなんか 改めて確認しました
>> 谷 ああでもそうですねなんか 十数年前にGTDからいって今まで
いろいろ試してああだこうだって やってた人が改めてもう一度よく
読んでみると結構発見があるかもしれない ですね
>> 谷 そういうちょっと分厚い から採読がちょっとねこう遠慮
がちになりますけど改めて読み 合わせるのはちょっと意味があり
そうですね
>> 谷 そうですねあと決して読み やすい本じゃないですよね
>> 谷 まあ確かにねそれはそうですね なんか回半を重ねるごとに難しく
なってくるというか
>> 谷 ああっていうことは最初の 半の割にこう編集してあったの
かもしれない
>> 谷 そうですねもしかしたら
>> 谷 そうですね
>> 谷 まあそうですねもっとこう シャープにねその方法論っていう
のが整理されたらいいと思うん ですけどまあアレンいわくこれ以上
シンプルにはできないとは書いて あったんでほんまかなと思うん
ですけど
>> 谷 うんまあでもやっぱり確かに 一時代を築いただけのことはある
なと思いますよやっぱり
>> 谷 はいというわけで私の現在 のGTDはこうなってるみたいな話
があれば私で打ち合わせハッシュタグ 打ち合わせキャストひらがなで
打ち合わせアロベットキャスト までいただければこれ下からチェック
したいと思いますはいというわけ で何かご報告とか告知等ございます
か
>> 谷 特にありません
>> 谷 はいでは今回はこれまで にしたいと思いますお疲れさまでした
>> 谷 お疲れさまでした
