00:00
おだしょー:打ち合わせキャスト 第118回ということで 今回もゲスト
にたくさんお返ししております よろしくお願いします
おだしょー:よろしくお願いします
おだしょー:Lifehack Newsはあんまり ないんですが 個人的な連絡というか
お知らせというか Primitive Outliner というプロジェクトの名前をつけ
たんですけども
おだしょー:いきなり
おだしょー:ごく簡単なJavaScript だけでアウトライン機能を実装
しているというものでして リンク は概要ページに貼っておくんですけ
ども だいたい200行ぐらいのJavaScript で書いてあるんですけど 本当に
ごく基本的なことはだいたいできます 開業で新規項目を作るのと Shift
タブでインデントの切り替え オプション 上下で行の上下移動 コマンド上下
で開項目の開閉ぐらいができる 一応 アウトライナーっぽく 開の
項目が閉じてるときに 親項目で Enter を押すと兄弟項目に開いてるとき
に Enter を押すと子項目に作るみたいな ワークロリの動きを真似しております
本当に基礎的なもので コードも 簡易に書いてるんで スタイルとか
新しい機能付け足しとかがコード が書けるのであれば だいたい自分
でもできるという だから このツール を使うというより このツールを
ベースに自分なりのアウトライナー を作っていけるプロトタイプみたい
なのを書いたと コードが非常に 汚いので ちょっとまだ GitHubには
あげてないんですけど もうちょっと 綺麗にして もうちょっと改造し
やすい形にしたら GitHubにあげよう かなと思っております
おだしょー:逆に 例えば 将来 的には 自分の作ってるツールに
ちょっとしたアウトライン機能 を追加したいなみたいなことが
あったときに 使わせてもらえる とか
いう感じ これ単体でアウトライナー ツールを作るということももちろん
できますけど Webツール作ってる 方であれば DIVを一個加えるだけ
で そこにファンクションを与える だけで その部分がアウトライン
機能を持つというふうにできる ので 考え方次第ではいろいろできる
かなと そうやな デイブ・アヤナ さんも JavaScriptで使えるアウトライナー
を発表されていて ひかもGitHubに コードがあるんですけど 読めない
んです 複雑すぎるとか できる ことが多すぎてて 機能を理解的
解体をするためにすごく時間が かかるんですね 既存的な構造が
あって そこに機能を付け加えて いくというほうでいうと こっち
03:02
のほうが多分 やりやすいんではない かなというところで
おだしょー:Webインナーさん のは コンコードってやつですよね
多分 そうですね
おだしょー:コンコードですね
一応 コードは4なんですけども だいぶ改造に難しくて そのまま
使いづらかったんで 一応 自分なり にベース バニラJavaScriptっていう
んですけど 何のフレームワーク も使わずに 1から書いてあるんで
そういうフレームワークの知識 がなくても JavaScriptのコードが
読めるんであれば 改造できるかな と思います 一点 自分で作って
て気がついたことなんですけども アウトラインの開項目の開閉っていう
操作があるじゃないですか アウトライナー の醍醐味とも呼べる機能だと思うん
ですけども 基本的には多くのツール で 何とかオプション系のキー
を押して上下とか そういうのが 多いと思うんですけど どういう
点かな 閉じてるときは開くし 開 ってるときは閉じるわけじゃない
ですか 私の言うことを言ってます けど ということは ショートカット
キーは実は一種類でいいんですね
おだしょー:そうですね トグル するわけですよね
だから 下を押せばトグ る 閉じてるときは開くし 開いてる
ときは閉じるっていうことで いける もちろん上下に分けてもいいん
ですけど 統一することもできる と 自分でやってて気づいたんです
けど 統一するつもりはなくて 上下 キーを分けるつもりでやったら
コードをさまざま間違えて 下で 両方開いたり閉じたりするよう
になって気づいたんですけど これ トグルやんっていうことで そう
するとコマンド上が開くんですね コマンド上っていうのって その
ときに じゃあ その操作を仮に操作 すれたら どんな操作に割り当て
たら面白いだろうなっていうの をちょっとたくさんに聞きたかったん
ですよ
おだしょー:なるほど
僕の場合は親項目を閉じる 自分が子供にいるときに 親項目
を閉じるときに 自分の親を閉じる だから 自分も含まれて プシャッ
って閉じるっていうのを当てたん ですけど 他にありますかね イマジネーション
として
おだしょー:あれですよね 今 さらに一段上ごと閉じるって言
われてますよね 今言ったね それで 言うと僕 トグル嫌いなんですよ
そうなんですか 上は上 下は下
おだしょー:そう だから 開ける 操作と閉じる操作を分けたいん
ですよ なので とはいえ 今 主流 なおトライアントってみんなトグル
型になってるんですよね 確かは クロイもそうだし ダイナリスト
もそうなんですけど 基本的には 僕 開けるときは開ける 閉じるとき
は閉じるってやりたいんですね だから あんまりそこ考えたことが
ないんですけど でも もしやる としたら 今 パッと考えると クラシタ
06:04
さん方式かなと思います でも そうか 上矢印ですよね
コマンド上とかですね
おだしょー:コマンドの でも 矢印キーでトグルしちゃうと
すごい個人的には混乱しそうな 気がしますね
ここは難しいところで しかも 別に 僕が書いてるやつは
コマンド書とかってきは 自分で 設定してもらったらいいだけなので
別に 上下を分けてもいいですし 下に統一して上開けて 別のこと
をすることも全然できると あんまり 僕 考えたこと 上が開くっていう
のを考えたことがなくて 上を閉じる は結構便利やなと 自分でちょっと
使ってて思ったんですよね トントン と閉じながら上に行けるという
のがなかなか良かったんで そういう 機能があってもいいのかなという
ところかな 一瞬 グループを 自分を親にした白紙グループ
を作るっていうのを考えたんです けど 閉じる 開くと新規項目作る
っていうのは ちょっと領域が違う じゃないですか
違います
おだしょー:だから やっぱ 定劇はそこ対応したいなと思って
閉じると じゃうな 研ぐると上閉じ っていうのにしたんですけども
こういうのも一度考えだすと結構 難しいなと思うんですよね
結構深い話ですよね
おだしょー:大切ね これは
UI設計の専門的なことを 考えてる人が考えてそうな感じ
もしますよね そういうのって
おだしょー:そうですね バックスペース をどうするとか リターンで分割
するのか ただ新規加えるのかっていう のも 選べる 一回選んだらそうじゃない
ものが採用できないので だいたい 同じ動作であっても 動き方のカスタマイズ
は細かい アウトライナーっていう ツールは結構細かいなというの
を作りながら思ってました
そうですね だからやっぱり テキストエディターとの親和性
で分かりやすくっていうと 行を リターン機をしたら分割がいい
はずなんですけど 僕は個人的に アウトライナーとしては分割しないで
たとえ行の途中でリターンをしても 分割されないので 次の行ができて
ほしい派なんですよね ただ 多分 こっちの流派は少ないんじゃない
かっていう想像をしてます
おだしょー:そうですね その辺 を込み込みで コードが書けなくても
このキーでこれをしたいぐらいを 変更できれば カスタマイズできる
っていうレベルまで持っていければ もうちょっとフレキシブルにできるん
かな さすがにローカルファイル に保存とかまではできないんですけど
そうなると本格的なWebツールなんですけど でも 結構 自分の使い勝手のいい
ツールがそこにある快感っていう のを味わえるんじゃないかなとは
思いますね
おだしょー:それ 今 現在作っている アウトラインのデータはどこに入って
09:00
るんですか
おだしょー:今のとこはどこにも 入ってないです
おだしょー:どこにも入ってない じゃあ 逆にリロードしちゃったら
消えるみたいな
おだしょー:消えるっちゃいます それを保存するパターンも 基本的
別にすぐ実装はできるんですよ ローカル ブラウザーのローカル
に保存もできるんですけど それを 変えてしまうと 別の方法が選べ
なくなる可能性があるっていうところ あくまで 現象体制であると
おだしょー:オフターバックス のアウトライナー機能を提供
するものとして 今のとこは捉えて いるんですね パターンを選べ
てもいいかな これで保存するパターン っていう このまま使うにはさすがに
貧弱なので あくまでこういうコード で動くんだよみたいな これ 本当に
簡単なんですね 結局 HTMLのulとreが親子構造をもともと持っている
ので それを活かしているだけということ ですね
おだしょー:でも あれですね だから その辺の勉強をするのにも
初心者の人が勉強するにもいい かもしれないっていうことですね
おだしょー:いいかもしれない ですね 普段使っているツール
の延長線上にあるというのはいい ことですね この辺 興味あったら
リンク先覗いてくださいということで 今回は本編 タスク管理の基本について
の前回について後編なんですけども プロジェクトについて プロジェクト
は105回でプロジェクトについて っていうのをやってまして その
ときはGTTのプロジェクトっていうこと が プロジェクト管理のプロジェクト
と混ざるし ちょっとややこしい よねという話で 別の言い方をできませんか
みたいな問題提起をして 問題提起 自体は広がったんですけど 言い
かえみたいなのが見つかったわけ ではなく でも 解像度そのものは
広がったかなと思うんですけど 前回がプロジェクトについてという
タイトルやったんで 今回は別の 切り口で考えたんですけど プロジェクト
をなぜ作るのかという観点から 考えたいと思うんですよ
おだしょー プロジェクトをなぜ 作るのか
おだしょー なぜ作るのか 僕らが この手の話するときに それって
プロジェクトっぽいものですよね っていうふうに ちょっと濁した
言い方をするんですね それって プロジェクトですね じゃなくて
プロジェクトのようなものとか プロジェクト的なって言うんですね
つまり 一般的に含意されている プロジェクトとぴったり重なる
ものではないっていうイメージ があるから そう言うんですけど
それを違いに目を向けるんじゃ なくて 共通点に目を向けたいな
と つまり 違っているにも関わらず 似たものを作ってるわけですね
そのプロジェクトと呼べるような ものを 誰かし 僕でもおたくさん
でもGTTでも プロジェクト的なもの を作らずにはいられないという
か 作ることが有用であると その 有用性は何なのかっていうこと
を考えたほうが生産できるんじゃない かなと ちょっと思ってたんですよ
で プロジェクト つまりタスク だけでは足りないっていうこと
をですね 単純に 一番単純に考え たら だから 中長期的な行動 管理
12:04
っていうか 中長的な行動を扱う ためにプロジェクトというのは
作られると その項目を保存する という意味も つまり情報を保存
するという意味もあるんですけど やっぱり名前をつけるということ
が大きいのではないかなと 何かしの 名前を与えて 操作できるように
すると そこには関連する情報を 集めたりとか タスクを乗っけたり
とかってして 自分の頭の中にその プロジェクト的なものを保存する
領域を確立するためにプロジェクト というのをグループではないか
と だから この要件を満たしていたら 概ねプロジェクトと言うのでいいん
ではないかなというのが 今 考えてる ところなんですけど あんまり難しく
考えすぎないほうがいいかなという ところですね
おだしょー 同意ですね
おだしょー そうですか
おだしょー そうですね GTD的な プロジェクトが結構パッとなかなか
伝わらないところがあるんで 逆 に難しい定義を満たしてないと
いけないみたいな感覚についな っちゃいがちなんですけど 特に
タスク管理クラスターの人々は そんな難しいことでもないんじゃない
かなと思って 確かに だから要するに やろうとしていることの塊に名前
を付けるっていう
おだしょー うん っていう単純な その行為をプロジェクト化と呼んで
いるだけのことであって それが 例えば 複数アクションを含む 含まない
とかって言う 終わる 終わらない とかって言い出したら それは正直
化にはつながるでしょうけど リアル のタスク管理にどれくらい役立つ
かっていうと 結構微妙なところ だと思うんですよ 日々のあれでは
扱えない 日々のリストだけでは 扱いきれない よりスパンの長い
ものを保存していく概念として それをプロジェクトと呼ぶという
だけであって その内実はもうそれぞれ の人で違っていいんじゃないかな
と
おだしょー だから 多分 プロジェクト ってわざわざ分けたのは 多分
分けるのが有効なのは 多分GTD を厳密にやるときなんですよね
おだしょー はい はい はい なるほど
おだしょー 前も話でましたけど GTDが出てきた頃 デビットアレン
さんがGTDを作った頃は紙が前提 だったんで プロジェクトリスト
っていうのは分けない アクション リストとプロジェクトリスト分けない
と扱えなかったみたいなところ があって だからプロジェクト
っていう概念が必要になったので あって 要するに いわゆるタスク
15:02
そのタスクっていうか アレンさん がいうアクション 次のアクション
みたいなものっていうのは 一回で 一発で終わること 一発で終わらない
一発で終わらないことをそこに 混ぜると混乱して処理できなく
なるんで 終わらない大きい塊 はプロジェクトっていう名前にして
別のところにリストを作っておいて それを見て それぞれ次のアクション
を考えて 次のアクションはこっち のNext Actionリストのほうにコンテクション
とか別に分けて書きましょうねっていう 話だったと思うんで そのやり方
をするときにプロジェクトっていう 概念を分けることは有効だった
と思うんですけど その厳密なGTD をやらないのにGTDっぽいプロジェクト
の概念をきちんと踏まえなきゃ いけないって考えると あんまり
意味がなくなっちゃうというか あんまりそれやらなくてもいいん
じゃないかなという気が個人的に してますね
おだしょー:だからGTDレベル でいうと週のレビューでその1週間
の具体的なNext Actionはもう見定ま っているはずと そこにリストは
完備されてると だからその1週間 は1つ上の階層についてはもう考え
なくてもいいですよと 1週間経った 後にもう1回上の階層に立って考え
ようというときにそのプロジェクト リストっていうのが出てくると
そのレベルでは 週次レビューでは 逆に言うと具体的なタスクについて
はあんまり考えない だから考える 対象を分けるためにその2つのリスト
があるということですよね
森:そうですね
おだしょー:例えば 僕の環境における プロジェクトっていうのはそれ
はちょっと違うかな だって日々 参照してますからね 僕の場合は
森:そうですね だから僕も多分 違うですよね 僕はだからDoっていう
名前をつけて 大きいDoはプロジェクト に相当するし 小さいDoはタスク
らしいっていう感じに自分の中で なっちゃってて それで特に不都合
はないですよね だからアレンさん の次のNext Action Listというのはもう
その片っ端から 今 パソコンの 前に座ってるからパソコンでできる
パソコンというコンテクストで できるものを片っ端からやって
いこうっていう そういうレベル で実行できるものがAction Listになって
て 逆にそうじゃないものはプロジェクト なんですよね
森:そうですね はい
森:だから あんまり上の階層 というよりも 別れて 並行してる
というか
森:そうですね
18:00
森:感覚として 上の階層なんですけど 実際には
森:だから プロジェクトと呼ばれる ものは 実行するためにはブレイクダウン
が必ず必要なものが記述されてる はずですね GTDレベルでいえば
森:そうですね だから いわゆる GTDアプリみたいなものって 必ず
Next プロジェクトの階にタスク を入れられるようになって 必ず
じゃないけど そういうものがほとんど だと思うんですけど あんまり
現GTDって そういう感じじゃない 気がするんですよね プロジェクト
リストを見て このプロジェクト について 次に何をやるか 次の
アクションは何かっていうのを考え ればいい その考えた次のアクション
はNext Action Listにコンテクストベース に書いておくと 実際に行動する
ときはもうプロジェクトのことは 見ないで Next Action Listをほとんど
機械的にやっていくっていう そういう 分けて考えるっていうこと
ですよね きっと そのためにプロジェクト という概念が必要だったんじゃない
かな
おだしょー:分けて考えるために まさに必要で プロジェクトは一回
の構造で済まないっていう言い方 はちょっとあれですけど どういう
点かな だから 状態 目標 行為じゃなくて 出したいこと
分かんない 難しいな 直接的な行動結果 というよりは こうなりたいみたいな
こういう状態に持っていきたい っていうのが書かれる こういう
状態に持っていきたいっていう のは そのままでは達成できない
から必ず付随するアクションが 絶対に出てくると これをいわゆる
分解と呼ぶわけです 分解したわけ じゃないですね 演劇する その状態
に向かうために こんな行動が必要 かっていうのをレッドして だから
これは状況が変われば 出てくる タスクも変わるはずなんですね
おだしょー:そうだと思います
おだしょー:そうだと思います
おだしょー:だから ここがプロジェクト にタスクを紐付けちゃうな 買い付ける
とややこしいことになる
おだしょー:そうだと思います
おだしょー:そうだと思います
おだしょー:状況が変わると タスクが変わってしまうからっていう
そこを満たしてるGTDアプリと そうじゃないアプリがあるんですけど
やっぱりプロジェクトって言った ときに 僕らの認識では 会にタスク
を持つものとして ぎっしり結び ついた親子関係を持つものとして
理解され処理されてしまうから やっぱりGTDがうまくいかないって
いうことなんでしょうか
おだしょー:じゃないかなと思 うんですよね
おだしょー:それをやると 多分 GTDはうまくいかないですね きっと
ね
おだしょー:分解するっていう と 文字通り丸いケーキがあって
これを切って当分していく そうすると その部分は変わらない
わけじゃないですか
おだしょー:そうですね
おだしょー:そのGTDにおける プロジェクトに付随するアクション
って そういう感じじゃないと思 うんですよね
おだしょー:そうですね きっと
21:00
おだしょー:でも 分解するっていう と イメージとして プロジェクト
の最初から終わるまでの過程を タスクとして記述していかなきゃ
いけないみたいなイメージを持って しまう人が多くて 持っても別に
いいんですけど それだと結構苦しくなる というか 多分 その通りにはならない
ですね
おだしょー:ならないですね
おだしょー:うん
おだしょー:だから どっちか というと 細かい手順を全部書き出す
というよりも その時 与えられた 任意の時点において このプロジェクト
について 次にできることは何か っていう
おだしょー:うん そうですね
おだしょー:次に 常に考え続けて 回していくっていうイメージのほう
が 近い気がするんですよね
おだしょー:うん 多分 それを 一通りやったら Next Action Listも
きれいに切り替わって 新しい形 で自主に臨むという形におそらく
はなる おそらく Next Action Listも 1週間ごとに 本当はゼロスタート
をすべきなんですね きっと そこを 僕らはできない
おだしょー:なるほど 今週の Next Action List
おだしょー:Next Action Listっていう のを 毎回ゼロから作る プロジェクト
リストを見ながらっていうのを やらなければ きっといけないはず
なのに 僕らはTo Doリスト的な感じ で ずっと引き継いで運用してしまう
から 破綻してしまう 拡大してしまう みたいなことが きっと起こる だから
タスクサブタスクの関係と プロジェクト とタスクの関係は相似じゃない
っていうことを ここはちょっと 抑えておく必要はきっとあるでしょう
ね
おだしょー:そうですね だと思うんですよね だから ここがGTDのエキスパート
的な人と話したらどう言われる のか ちょっと分からないですけど
僕はちょっとそういうふうに理解 するように 最近なった気がします
ね だから 昔は自分もすごい誤解 してた気がするんですよね
おだしょー:僕も多分 全く間違 ってたと思います 自分 さっき言った
ある種のツリー構造を作るもの だと理解してましたね
おだしょー:そうですよね アウトライナー でGTDやろうとすると そうなっちゃ
うんですよね そうやっちゃうんですよ ね
おだしょー:分かります 分かります だって まず プロジェクトって項目
後にプロジェクトをだーって書いて いって そのプロジェクトに必要な
コードを
おだしょー:その下にタスクを 書いてあるんですよね
おだしょー:書いてありますね 確実に そうか そこはツールが でも
大抵ツリー構造になった プロジェクト の回が そのままリストになって
タスクとして登録されることが多い ですよね プロジェクトを見ながら
Next Actionリストを作るというより は プロジェクトのAの下にタスク
を書き込むみたいな形が多い気が しますけどね あれはだから
おだしょー:ほとんどそうですよ ね
おだしょー:本来はツリー構造 っていうのはタグなんですね きっと
このタスクはプロジェクトと関係 しているよぐらいを示すだけで
あって ペカで繋がらない はい
おだしょー:ごめんなさい ごめんなさい そう
っていうか プロジェクトリスト がアクションを書き出すための
トリガーぐらいの感じなんですよ ね 多分 感覚としては
おだしょー:そうですね だから GTDのプロジェクトは多分
24:04
僕が言うプロジェクトノートとは やっぱり違う
おだしょー:違うと思います
おだしょー:だから どっちかって プロジェクトの関連情報を集めた
フォルダが多分プロジェクトノート に相当して だから そのプロジェクト
ノートとプロジェクトのレビュー はちょっと噛み合わないかな
おだしょー:だから 暮らした さんのプロジェクトって どっち
かっていうと 中期計画
おだしょー:僕の場合は細かい ものはプロジェクトって呼ばない
ですね だから おそらく そこの流度 感はたくさんのDo群とは違うはず
ですね きっと
おだしょー:そうでしょうね 僕の 方が小さいかな どうかどうだろう
な
おだしょー:小さいものは 僕は多分含めないですし コミット
してないものをほぼプロジェクト と呼ばないので これ やるぞって
決めたものだけをプロジェクト と呼ぶことが多いですね
おだしょー:でも それは自然ですよ ね 動いているものですね だから
おだしょー:それ以外は全部 僕が気になっていることっていう
リストに入れますね それはたまに 見ますけど だから これ5日やる
プロジェクトリストに多分相当する ものやと思うんですけども しかも
そこはオームネビジネスに関係ない ものが並んでいる だから そこも
僕は結構分かれてますね 仕事と 呼べるようなものがプロジェクト
で しかもさっき言われたように 中期以上 1週間ではまず終わらない
ようなものばかりが並んでいる 感じですね
おだしょー:だから 根本的に 違う だから そのGTのプロジェクト
も 別にプロジェクトの中の進捗 を管理するためのもんじゃない
ですよね 概念的には
おだしょー:じゃないと思うん ですよね
おだしょー:そうですね きっとね そんな説明ないですもんね 別に
おだしょー:ような気がします ね
おだしょー:一応 ナチュラル プランニングっていう話はあります
けど あれはプランを考える話で あって その通り進んでいるかを
チェックしていきましょうとは 多分 述べてないはずで
おだしょー:ではないですよね ただ プロジェクトのリストを眺
めてるときに あるプロジェクト名 を見たときに これについて この
ような前に進めるには 次に何を するかって自然に浮かんでくる
ようなことが そういうものも含 めて 多分 ナチュラルプランニング
っていう
おだしょー:そうでしょうね きっと
おだしょー:出るような気が するんですよね アレンさんの
講演の動画みたいなのを見てた ときに 歩いてたら 前からクマが
来ましたと そのときに あなたは 何をするか自明ですよね みたいな
話 それがナチュラルプランニング だみたいな話をして
おだしょー:だから 要するに 直感的に思い浮かぶことという
27:01
ようなことだと思うんですよね
おだしょー:そこが 僕は半信半疑 というか 果たしてそれで本当に
直感だけでいいのかというのは ちょっとアレを読むたびにいつも
思うんですけど
おだしょー:微妙にもっと先の ことまで考えてるけれども 終了
まで全ての段階をビシッと計画 しなさいっていうことは言って
はない
おだしょー:なるほどね
おだしょー:ですよね きっと そういうことか 状況が与えられた
次の行動は自明ですよねっていうこと か そりゃそうかもしれないな
おだしょー:この理解があった のかちょっと分かんないですけど
おだしょー:ナチュラルプランニング って言いますけど ナチュラル
って全然ナチュラルじゃなくて かなり文化的な要素を受けるはず
で
おだしょー:そうでしょうね
おだしょー:それが必ずうまく いくとは限らなくて むしろバイアス
の影響をかなり受けているのではない かなと思うんですけど おそらく
それは成功するかどうかじゃなくて 自分がその行動を取ることに確信
を持てるかどうかっていうことが たぶんその際のポイントで それは
クマが来たら逃げるっていうのは 判断いらないじゃないですか そりゃ
そう逃げるよねって言って 判断 がいらないつまり納得できるって
いうことがおそらく重要で 毎週 のレビューでプロジェクトを見て
自分にとってこの行動が次は絶対 必要だと思えるものを探しなさい
っていうことなんでしょうね きっと だからある種 計画とはちょっと
違う
おだしょー:そうですね
大平:計画 作戦とかに近いかな なんとなくイメージとしては
おだしょー:そうですね 大前例 にしても多分 日本人があって
言っていいのか分かんないんですけど 子どもの頃から教え込まれてきた
この計画をきちんと計画的に行動 しなさいっていう計画とはずい
分違う
大平:違う気がしますね でも おそらくその文脈でプロジェクト
は理解されてるんじゃないですか ね だからうまくいかないんでしょう
けども きっと
おだしょー:そうですね さらに 例えば企業に勤めているときに
企業の中における何々プロジェクト っていう あのプロジェクトとも
さらに混ざって そうなんですね いわゆるプロジェクトって括弧
に入れて語っちゃうのは 喋ってる ときにこのみんなが違うプロジェクト
を思い浮かべてる可能性がある からね
おだしょー:そうですね プロジェクト っていう僕らが普段言う言葉が持つ
雰囲気において 大きさっていう のも大げささっていうのもあるん
ですけど 硬直性というのがありまして 何しろトップダウン性といって
もらうんですけど プロジェクト 計画を遂行することが主で そこで
働く人が10っていう形にどうしても なりがちで 少なくとも僕らのような
人間のプロジェクトはそうではない ことが多いので そこの勘違い
を発生したくないなというので プロジェクト的なものとは確かに
30:02
言いますね プロジェクトっていう のはタスクリストの一つ上の階層
のものと捉えるのか 単に自分が 達成したい中期的な目標 中期的な
というとあれか 短期以上の目標 なのかというとこで捉え方が異なる
んかな
おだしょー:そうですね あと 会社員だったときに会社からもしくは
上司からアサインされるプロジェクト における役割っていう そのプロジェクト
があるとしても その中でやるとして も その役割を果たすために自分
が個人としてやることって考えた ときに その中の自分の個人として
もまた別のレイヤーのプロジェクト っていうのも多分あるわけじゃない
ですか
確かにありますね
おだしょー:多分 それが同じ言葉 じゃいけないんでしょうね きっと
確かにね 内緒 そのプロジェクト の頭とか後ろになんかつけて区別
するか このタスクのグループも プロジェクトと呼んでしまいます
し 目標的なものもプロジェクト と呼んでしまって 呼ぶことによって
手法が混じり合ってしまうという 悲劇が起こる なるほど これはでも
やっぱりどっちかの呼び方を変える そうですね 一番使われやすい言葉
で どうですかね アメリカ人的な プロジェクトっていうと直感的に
ああいうことねって分かるんですか ね 企画みたいな小さいものも含
むんですかね やっぱり
どうでしょうね アメリカ にいたときはプロジェクトについて
考えなくてもいい年齢だったんで 分かる
おだしょー:そらそうです でも そんなに日本人とかけ離れ
やっぱりGTDのプロジェクトに対する 誤解ってある気がしますけどね
そうか やっぱりちょっと 大規模大げさな感じがしてしまう
おだしょー:だってアメリカ人 が作ったアプリもそういう構造
になってしまうから
そうですね 確かに この辺はもうちょっと あるいは
2022年の現代において ちゃんと GTDをもう1回説明してくれる人が
出てきてくれたら もう少しは幸せ な感じになるかもしれませんね
おだしょー:そうですね ただ やっぱりプロジェクトの最初から
最後まで手順ステップをきちっと 書き切らなきゃいけないという
意味じゃなくて 常に次のアクション を考えればいいんだよっていう
教えは有効だと思いますけどね
そういうふうに教えられる と 非常に納得感がありますね
おだしょー:それで コンテクスト っていうのが今の時代にちょっと
33:03
機能しづらくなっちゃったところ はあるんですけど いずれにして
も 次のアクションを書き出した リストがあって 行動するときは
それを見ながらそれを消していく それを そのサイクルをぐるぐる
回してるうちにプロジェクトが終わる っていう その考え方は多分 最初
から最後まで手順を明記しなきゃ いけないんだよって教えられる
よりも多くの人にとって有効なん じゃないかなと
そうですね それは間違い ないですね
おだしょー:今さら思いますね 結構 割に自分の中でGTD再評価が
今 ちょっと起こってるんですけど
だから その言い方をする と やっぱりコードという言い方
がしっくりきて だから プロジェクト とのタスクとは違う高さなんだよ
と だから タスクを集めたって プロジェクトにはならないって
話になりますよね それは
おだしょー:タスクの塊とプロジェクト は違う
違うっていうのがはっきり 示される
そういう意味でも コードという 言い方を単に比喩的なものとして
じゃなくて もうちょっと内容に 踏み込んだ解釈の仕方ができる
かなという印象ですね だから やっぱり もっとプリミティブな
GTDっていうのが 多分 提示できる だから 結局 本が若干大げさすぎて
受け取るほうも大げさになって しまうところがある もっとフランク
に語ったほうがGTDは分かりやすいん じゃないかなという気がします
ね 今みたいな話のほうは 遥かに そうだなと思いますけど
そうですね でも 書いて あることをそのまんまもう一度
受け取り直してやってみると いろいろ分かることがあるのかな
っていう気も最近してますね あと Getting Things Doneっていう英語を
訳すのが難しいんですよ あれ
おだしょー:そうですよね
最初に翻訳が出たときに 最初だか2番目だか 物事を成し遂げる
技術みたいなタイトルになった じゃないですか
おだしょー:成し遂げるという ような表現でしたね 確か
それは やっぱり そういう 感じじゃないよなとは思います
おだしょー:成し遂げるって 例えば 日本語で達成みたいな雰囲気
がありますけど もっと軽いんですか ね それは そのGetting
もっと軽いと思いますね ニュアンス としては 終わらせる
技術とか 完了する技術ぐらいの
おだしょー:終わらせる技術って いいですね なんか
なんかちょっと殺し屋 みたいになっちゃうんで ちょっと
あれですけど
おだしょー:いや でも 要するに プロセス 物事に対してプロセス
して 一個一個段階を終えていく っていうようなイメージが浮かび
ましたけどね 今
そうですね だって Getting Things Doneじゃない
ダンって終わらせるじゃないですか 達成する技術っていうと アチーブ
36:00
とかになるじゃないですか
おだしょー:そうですね 確かに 確かに
で 明らかにそういうニュアンス ではないんですよね 多分 でも ただ
でも その軽い いろんな たくさん 抱えている物事を終わらせていく
というのが いかに大変かっていう そこに
おだしょー:そうですね はい
そういう大きな 何を ああいう なんて言うんでしょう
巨大な仕事を達成するっていう のも大変だけど 無数に抱えている
巨大じゃない日々のやることを 終えていくのも大変だよねって
みんなできてないよね そのための やり方なんだよっていう感じ で
その先に大きい仕事を達成っていう のがもちろんあるわけですけど
おだしょー:もともとGTでは ボトムアップを歌ってましたから
ね その日々の雑事をきちんと片付け てっていう話をしてましたからね
今の方やこのタイトルって 何でしたっけ
おだしょー:ストレスフリーの整理 術ですね
あ そうですね
おだしょー:そこも 確かに情報整理 をしているわけで整理術ではあるん
ですが そうでもなんかちょっと 雰囲気 それこそマニュアナの法則
みたいな あるいはKJ法みたいな 内容とあんまり関係ない方が実
は親しみやすい可能性もあります けど
確かに
おだしょー:ストレスフリー 歌いすぎるのもちょっとなんか
違うかなという気が
そうですね ストレスフリー は多分現状の
おだしょー:副大化にもなってました けど
副大化にもなってました けどね きっとね
そうですね 難しいですよね
おだしょー:あとGTDが仕事術 なのかタスク管理術なのか情報
整理術なのか何なのかっていう 位置づけも難しいんですけど
難しいですね 全部の要素 があるから
おだしょー:含んでますけど だから その辺の広さも結構分かり
づらくしてるんでしょうね きっと
おだしょー:基本的な自分の気 になることをどう扱うかという
話で それを行動に結びつけていく ための方法論と考えていいと思
うんですけど それはカテゴリー 的に何なんでしょうね 知的生産
ではないんですけど
むしろ生き方に近い
おだしょー:そんな感じがします ね
実用的な生き方だという か
おだしょー:生活技術ですね 生活の技術
そう 生活の中に仕事が大きな 要素を占めるから その仕事術
の要素も当然
おだしょー:出てくると
出てくると強くなります けど 要するにその気になること
っていうのが われわれは気になる ことが頭の中でしじゅうこもや
もやしてて 集中できなかったり ストレスを感じたりしているの
を全部出しちゃって 頭の外に出して その外に書かれていることを上
から順番に見ながら実行していける ようにするみたいなことじゃない
39:00
ですか 結局
おだしょー:だから これ 105回に話した話とすごい60パーセント
ぐらい重なってる気がしますけど でもアナログ技術としてはすごい
優れてると思いますね やっぱり
結局 そこのデジタルアレンジ がうまくいってないし 結局それは
多分アノートツーでもそうで 情報カード もうまくアナログに着地できてる
気配があんまり スクラップボックス がないこと言ってますけど それ
以外はあんまりなく アナログで うまくいってたものがデジタル
ライズされたときに どうも着地 が変っていうのは各所で見受け
られますね
おだしょー:そうですね だから アナログにあったツールや手法
をデジタル化してより良くなった 例ってアウトライナーぐらいじゃない
ですか
アウトライナーは要する に付箋的なこととリストの組み合わせ
を可能にしたわけで ボードと付箋 の組み合わせだと だいたい画面
が狭まってるんで あんまり良く なってないんですよね 検索できる
ぐらいかな
おだしょー:難しいんですよね アナログツールをデジタル化する
って
そうですね アウトライナー は扱う情報が非常に限定的という
か 一行で しかもテキストだけや からこそデジタルにぴったりです
けど GTDでやってるように紙にいろいろ 書き出すっていうのは あれ フォーマット
は自由であるほうがおそらく良い はずで いろいろ書ける それがある
タスク管理ツールになると急に 全部タスクとかになっちゃって
運用が難しくなるから ノートツール を併用する必要が出てくるという
ので あんまりうまいこといかない どう片付けるか GTDを理解してる
人で かつプログラミングができる 人というか 軽裕な人がいないと
なかなか実現しないんですよけども
おだしょー:アレンさんが設計 した理想のGTDアプリみたいなもの
があったんですよね あったって 現実にじゃなくて 構想だけ発表
してたのが すんごいややこしいん ですよね 複雑な
でしょうね きっと
おだしょー:これだったら紙の ほうがいいんじゃないかなって
思ってしまった記憶があるんですけど
これだから 紙のほうがいい というか 情報を例えば複雑に
扱えたとしても 現実の僕らは結局 それをやるかやらないかライン
まで落とし込まないとタスク管理 には役立たないわけじゃないですか
そこがかみ合ってないんですか ね デジタルの情報のリッチさと
実行のときに必要なものの簡易 さが合ってないというか
おだしょー:だから 多分 紙 アナログだと一定程度以上複雑
にしようがないからいいっていう 面はありますよね きっと
そこはアレンさんの欲望 を爆発してしまうと むしろ僕が
42:04
考えた最強のツール的になって しまうみたいな そこまで複雑な
ことをしなければ僕らの行動が 管理できないなら 何か根本的に
間違ってる可能性があるんですよ
おだしょー:そうですね
リーガルパッドに何か 書いて 上から消していくという
レベルの行動を管理でできない のは複雑すぎませんか 求められている
行動が複雑すぎる気がするんですよ ね そうじゃない場合って
おだしょー:そうだと思います
現代の複雑さにタスク管理 を対応しようとするんじゃなくて
むしろそうじゃないほうに根本 レベルから向かったほうがいいの
ではないかなという気がするんですけど
おだしょー:やることが多すぎる なら もう枠をつけて 枠から溢れた
ことはやらないことにしちゃおう っていうのがOpenAuthTrainerでやってる
そうですね
おだしょー:それに近い 物事が複雑 すぎるなら 一定程度を超えた
複雑さはもう捨てちゃえみたいな
っていうぐらいの割り切り があったほうが 多分 サポート
しちゃいうなんじゃないですかね
おだしょー:本当は多分 人間 にとっていいのはそういうと同
然なんですけど それが許される かどうか
分かりませんけど でも 社会の機運として それおかしい
よって言ういての声が ないとおかしい です やっぱりデジタルツール
っていうのは個人をエンファンス するものだとしたら 社会的を
高めることが果たして答えるのか というのは 僕は疑問ではあります
けども
おだしょー:デジタルツール って 生地 それができちゃうので 複雑
なものを複雑に扱おうとしちゃ うんですけど 逆に複雑なことを
単純化してくれる方向になると いいよなというか ツールの進む
べき道って そっちなんじゃない かなというと偉そうですけど でも
ちょっとそう思いますよね
おだしょー:GTDツールを作る 場合は 高度0から高度5000までの
5段階で ビューが違うぐらいの ことはやってほしいですね 全部
を同じ 例えば一番下のほうはリスト が並んでていいんですけど 上の
ほうはリストじゃないほうがいい と思うんですよね 真ん中ぐらい
は例えばマインドマップとか そういう のとか それの答えは分かりません
けど それが変わることによって 僕らの視点が自然と上の高度に
向くようなUIになってたほうが いい気がしますね
おだしょー:だから 僕 それ 高度ごとに切り離されてたほう
がいいんじゃないかなという気がしますね
おだしょー:逆にもう一層のこと なるほど 確かにそうかもしれない
おだしょー:例えばマインドマップ が有効な高度があったとした
ときに そのマインドマップのある 枝垂にフォーカスすると 一個下
45:06
の高度に行って 例えばリストが 出てくるみたいなことになりがち
じゃないですか でも それが違うん じゃないかという気がちょっと
して
おだしょー:違いますね 先ほど 言ったように 考えるためのツール
と そこから生まれるものは別だ っていう理念がある以上 繋げて
しまうと繋がっちゃいますもんね
おだしょー:そうなんですよ マインドマップはいいとして マインドマップ
を見ながら別にリストを作るべき なような
おだしょー:そうですね それは そうです それは間違いなくそう
か ビューの切り替えというのは 5つの画面があるっていうぐらい
の感じのほうがいいんか
おだしょー:だから クラシア サンダーのテキストボックス
の横にスライドして切り替わる 画面 あのイメージのほうが 僕 あの
画面を見てて思ったんですよね 切り離したほうがいいんじゃない
おだしょー:確かに 切り離した それは
おだしょー:切り離されてるけど 一つのツールに入ってるっていう
おだしょー:そうですね それは そう だから 結局 僕が本文とアウト
ライン 原稿の本文とアウトライン を連動させないって選択してる
のと同じことですね 要するに
おだしょー:そうそうそうそう
おだしょー:ああ そうか 上の階層 と生字言っちゃうから繋がって
てほしいみたいな でも そうですね 流度がもう明らかに
違うわけで 先頭高度0と高度1000 は1000離れてるわけで 高度999と1000
みたいな違いじゃないんですよね もう完全に違う視点であると
おだしょー:だから 高度のメタファー なっちゃうか どこなんだろう
おだしょー:高度のメタファー へと繋がって 連続性を感じます
からツリー構造が思い浮かびます もんね 自然と
おだしょー:アルフィンさん自身 が多分 階層的に考えてるんだと思
うんですけど
おだしょー:だから 一人の人間 の中ではそういう
おだしょー:階層的にという 行動 繋がってるんですけど 実用
上は切り離されてたほうがいい じゃないかなと思うんですよね
おだしょー:しかも 繋がってる と言っても そこまで どういう
かな ノードがくっついてるという 感じじゃないと思うんですよ 例えば
ナチュラルプランニング的に言う と 僕がイメージするのはシャンパン
タワーなんですね 一番上にシャンパン タワーとかをポタポタ下に行く
じゃないですか つながってはいます けど 結合はしてないですよね
そういうイメージで僕は行動を 捉えてるんですけど それだとツリー
構造にはならない 上の影響は下 におけるけど それだけだと でも
逆にこのイメージだとフィードバック が働かないんで 下が上に行かない
んで これをうまいこと表現できる モデルがないかなと思ってるんですけど
それぐらいの関係性 ちょっと離れ これは何て言うんですかね 何て
言うのかな この二つの
例えば雨が降るじゃないですか 山に雨が降って 川に集まって
流れていって 海に流れていって 水蒸気になって 雲ができて また
48:01
山に雨ができてっていう そういう 何だろう そういう感じのフィードバック
そうですね だから 気候モデルとして 捉えるみたいな 一つの経緯を成してる
わけですね だから 繋がって関連してるけど
出るけど 直接繋がってるわけではない みたいな
そう 1対1でリンクしてるわけじゃない っていう
そうですね そういう感覚が多分 あったらいいですね だから そこに
その感覚 いや でも結局 先ほど 言われたように データを切り離せばいい
だけの話であって 要するに あの手のやつは全て同一のデータベース
で処理するから そうならないわけ であって コードごとのデータモデル
を別に持てばいいだけの話ですね きっと
そう考えると GTDでプロジェクト リストと次のアクションリスト
は別のリストになってるっていうこと の有効性が分かる気がするんですよ
ね そうですね おそらくそこはもっと
アクセントを置いて主張される べきやったんでしょうね
そうですね 多分 そこまで意識して たわけじゃなくて アナログだから
仕方なくそうなってしまうと思う なんか でも デジタルでリンク
できるようになって そうやって みた結果 思ったのは これは分かれて
たほうが良かったんじゃないか っていう
うん 確かに
もちろん それはそう思わない人 ももちろんいると思うんですけど
いや でも 例えばプロジェクトリスト って その下にタスクを並べると
多分 もうそのアウトラインが膨大 というか
いや 膨大になりますよ
膨大になりますよね しかも さっき言ったように タスクの中
でサブタスクを切れるものがある 以上 階層も深くなりますよね
なります でも 真面目な人がきちん とやろうとするほど その罠には
まるというか 絶対パンクします からね
そういうの 間違いなくそうしは がらないですね それは
もしくは 仕事をするべき時間を 使ってリストを作る判明になります
からね
ありますね だから そうですね 釣り構造が持つ誘惑みたいな 網羅
させてやりたくなるみたいなところ があって そこやったら やっぱり
切り離されてるほうがいい だから それは結局 デイリータスクリスト
が前日と本日は切り離されてる っていうと同じ文脈で やっぱり
別のものなんですね どれも
そうなんです まさにその話を昨日 書き回したけど でも それ 倉下
さんが書き直す 文章を 書き直す テイク1 テイク2みたいに書き
直すっていうのと同じだと思うん ですよね ちなみに そうです この
定期報道マガジンで昨日 昨日じゃない 今日 昨日か
昨日か
書き 回したやつで 前日終わらなかった タスクを 今日に引き継がないで
今日は新しく作り直すっていう 話を アウトライナーの文脈で書いて
るんですけど 引き継いじゃうと 削除するのが大変になるからです
51:03
よね 昨日と今日は確かにつなが ってるんだけど 多分 今日はゼロ
から考えたほうがいいっていう のも多分
そうですね 同じだと思います
今の話と同じようなことで 書き直す ということの有効性って もっと
なんか叫ばれてもいい 叫ばれて もいいっていうか 自分が叫べば
いいんですけど
コピペ前世紀の時代においての この書き直しの重要性
そうですね
というわけで ちょっといろいろ 放送トラブルがあったので すごい
話がちょっと半端かもしれません が 一旦 締めに向かいたいと思うん
ですけども GTDのプロジェクトについて もう一回考え GTDについてちょっと
もう一回考えてみるっていうのが 面白そうという話でした
プロジェクトについて思うところ があれば #うちわすキャスト 平仮名
でうちわすでアルフェットキャスト までいただければ あるいは自分の
ブログ記事を書いて 後ろにハッシュタグ をつけてもらっても全然大丈夫
なんで ご意見・感想をお寄せください というわけで こんなところですが
たくさん何かお知らせしたいこと ございますかね
大丈夫です
はい じゃあ 今回はこれまでにしたい と思います お疲れさまでした
お疲れさまでした
ありがとうございました
