00:00
ちなみに、大橋さんのドマってどんな感じなんですか?
ご用意してきました。こんな感じです。
ルートっていうのがあって、あとはこのプロジェクトがフラットに。
ああ、なるほど。
もともと使ってたものから強引にこのドマを導入したので混ざってるんです。
ルートっていうのが、違うけどインボックスに近くて、ここにまずは書き込んでいって、
ここから、最近ミラーができたのでミラーにする場合もありますけど、各プロジェクトに下ろすこともあればっていう。
ここがだからドマになってます。
なるほど。
僕が発見したのは、スカップボックスって埋もれてしまうじゃないですか。
長い間触らないと下に行きますね。
だけど、それをMake LinkっていうChromeの拡張で、HTMLでコピーしてます。
すると、これを貼り付けるとこういうふうにリンク式のあれになる。
これを使って、まずこっちがインデックスで、詳細はスカップボックスで見れば分かると。
なるほど。
ワークフローイって画像を使えないから、なのでまず僕はスカップボックスのノートを作って、
進むことになったら改めてワークフローイに転記する。
例えば、ちょうどこのR3の記事を出筆するという背面をいただきましたので。
その時の経緯はこうやってメモするわけです。
でも、普通はこの中で仕事をするんだけど、スカップボックスは非常にそういうことに向いてないので、
一応、これが経緯ですよっていうのをワークフローイから分かるようにしておいて、
ここで仕事を進めてます。
なるほど。作業の場所とその作業についてのメタ情報が切り分けられてリンクで繋がっていると。
そうですね。もし関連記事とかあったら、ここにリンクを貼るんじゃなくて、
こっちのスカップボックス上でリンクのページを作りに行く。
それをこっちに貼り付けるとリッチじゃないか。スカップボックスの方がね。
それで使い分けてます。
これ終わったプロジェクトはどうされるんですか?
終わったらこういう感じで。
そうか。コンプリートなのか。
下げる。
これ、なってもいいんだけど、なんとなく一応直近で終わったものは残しておいて、
もういいやと思ったものは消そうかなと。どうせあちこちに記録が残ってるんで。
はい、わかります。
この終わったものはしばらく置いておくっていうような、
コンプリートにするけどしばらく終わっていくっていうような運用方法って、
ルールからすると非常にアバウトじゃないですか。
アバウトですね。
でもね、これが必要なんですね。僕が長い間気づいたことは。
ルール化してしまうと非常に、なんていうんだろう、やらされてる感があるんですよね。
03:04
自分の注意の合わないというか。
あの、はい。
適当でいいんだなっていう。適当の方がいいかな。
それはあれじゃなくてね、ちょっと部屋散らかってきたから片付けようかみたいな、そういう感じ。
そう、だから、そうですね。だからどう言ったらいいかな。
その、例えば3日経ったら、コンプリートして3日経ったら削除するとかいうのはダメなんですよ。
ルールとして。
それは自動化するにしろ、手動にするにしろ。
自分の注意で、これはいらんなと1回1回判断した方がいいというのが僕の感覚ですね。
なるほど。最新の自分の注意に沿いなさいと。
そうそうです。それを注意払わずに機械的に処理すると、ちょっと消すはずじゃないものを消しちゃったなとかいうこともあるし、
これもういらんっていうのも残ってしまうことがあって、ちょっと居心地が悪くなってしまう。
あれですね、捨てるかどうかもよったら解きめくかどうかで決めなさいに似てますね。
そうですよね。だから、その解きめくっていうものじゃないですけど、なんか自分の中の偽装化などを常時発揮させるって感じですね。
でもそれはあれですね、やっぱりこのルールって決めた瞬間から沈黙化するじゃないですか。
そうですね。
それを今最新のルールのもとみたいな自分の注意ですよね。それに沿うようにするっていうのは非常に強力なルールですね。
そうなんですけど、ルールにしておかないと気持ち悪いっていう感じもやっぱりあるんですよ、人間ってね、不思議なこと。
人間かどうか、僕の性格なんだろうかわかりませんけど。
よくあるのは、例えば今日を新しく本棚クラウドサービスを使い始めたら、今まで買った本も登録しないと気持ち悪いみたいなのがあるじゃないですか。
あります、めっちゃある。
でもそれって本当は必要なくて、それをやりだすとキリがなくて、その時から始めたらいい。
揃ってなくてもいいはずっていうところからスタートできたら一番いいんですよ。
ルールも運用も全部、例えばすべての項目に同じルールが適用されてなくてもいいはずなんですよ、本来は。
でもなんかしなきゃいけない感が出てくるんですね、ルールって不思議なことに。
そうですね。
それは振り払っていいかなと。
どこで身に仕切るんでしょうね、その感覚。
学校でしょうね、きっと。
ちゃんとやりなさいと。
ちゃんとやれないことはダメだっていうような見につくんでしょうね、きっと。
あとは家庭環境で親がきちんとした親か、割り切れる親かで変わる気もしますね。
確かにそれはあるでしょうね。
ここは自分の領域なんで、自分で支配したらいいだけのことなんですよね。
06:03
外部的な批判に対応する必要はないんですけど、割り切るためにはステップを超える必要が多分あるんでしょうね、これは。
でもね、これ何がいいかってやっぱり一望できることなんですね。
そうなんですよ、そこなんですね。
これがこれよりも上なんてダメだろうみたいなね。
ダメだろうまでいかないけど。
だからこれがエバーノートでもスクラップボックスでもなく、アウトライナーなのはそこなんですよね。
そうですね。
位置づけるっていうことが実は意味があるんですよね。
これ動的なのがいいんですよね。
そうそう、動的であるべきです、基本的に。
しかもその動的さがさっきも言ったように、更新ビジョンで勝手に変わるとかじゃなくて、自分で定めた位置があるっていうことが、ある種そのデジタル化で失われてしまったことがここにあるんですよね。
スマートなんちゃらがないってことがいいんですね。
そう、スマートなんちゃらがないことが自分の注意と一通になった環境を作れるんですよね。
例えば、押し出しファイリングってあるじゃないですか。封筒を使った。
デジタルじゃなくて封筒でやるときって、例えば探すのをババーって見ていって、これかなって言ってっていうサーチをするじゃないですか。
使ったものは一番右か左に戻すって方法は、更新ビジョンのソートに似てますよね、デジタルの。
でもね、これ全く同じじゃないんですよね。
例えば、10番目のやつを出した、中見た、違ったって戻すっていう作業があるじゃないですか、そのまま。
例えば、スクラブボスクの場合って、更新ビジョンか閲覧ジョンのどっちかじゃないですか。
そうですね。
で、閲覧ジョンやと、さっきの封筒から出して、中見たけど違うかったっていうことでも更新されてしまうんですよね、13番。
確かに。
そこが任意じゃないんですよね。
押し出しファイリングの場合は、戻すかどうかを任意で選べますよね、そのトップに戻すかどうか。
そっかそっか、戻す位置をね。神様だったら右足ですもんね。
だからその場所に戻すか、トップに戻すかっていうのを意識で選べますけど、自動のソートの場合はそのルールに沿って勝手に変わってしまうんで。
だからピンしたくなるんですね。
だから意思がちょっと反映されにくいんですよね。
なるほどなるほど。
その分アウトライナーは、逆に言うと自分で並べない限りは並ばないので。
これワークフローにソート機能ってありましたっけ、ダイナリストになるのかな。
ダイナリストあります。
そうですね。
アルファベットとか作成美順でソートできますけど。
なるほど。
ソートできても別にもちろんいいんですけど、やっぱり自分の意思で並べるっていうことの意味ですよね。リストを作ることの意味とちょっと抽象的に言ってもいいんですけど。
そう、だから勝手にリストが並び替わっていることほど嫌なものはないですよね。
だから並べ替わってほしいときもありますけど、例えば自分が作ったプレイリストはやっぱりそのプレイリストの順番で聞きたいじゃないですか。
そうですね。
そういう感じですよね、だから。
09:00
大きいのが、ライブラリーがキーワードっておっしゃるんですよね。
そうですね、それに近いですね。
で、GTDにおいて重要なことって見通しとコントロールだって述べられてるんですけど、アレンさんは。
はいはい。
まさにだから見通しとコントロールがここにはあるんですよね。
で、エバーノートにはないんですよ。見通しもコントロールもないんですよ。
ストレージですね。
だから、管理するための方法はやっぱりこうなんですよ。位置付けとその順番の入れ替えなんですよね。
リストを使うときってそうでないと、非常に部分的な操作しかできなくなってしまうんで。
だから、さっき言ったように階層が浅いと全部がトップとかに並ぶんで見通せるじゃないですか。
はい。
で、それぞれがアウトライナーだから操作できる。
しかも注意に合わせて変えていく。
そのエバーノート的なものの、エバーノートGTD的なものの一番の僕の問題と思うのは、
エバーノートの第一階層、つまりノートブックって固定的じゃないですか、どう考えても。
トップをコロコロ変えたりしないじゃないですか。
中身が変わったからノートブックのタイトルを変えようみたいなことでもまあしないじゃないですか。
大事になりますよね。
そうそうそうそう。
そこがどうしても性的か動的かっていうと性的になっちゃうんですよね。
上部構造が固定化するっていう。
で、カテゴライズして情報を分類するときにはいいんですけど、情報を操作していくっていう扱いでは、
やっぱりそれは沢山が言う方のプロダクト型的な振る舞いになってしまうんですよね。
上が見出しが絶対に変わらないっていう。
で、それはそれでアーカイブとしてはいいんですけど、
情報の操作って考えたときにその上の分類、一番上の分類がコロコロ変えていけるようなものでないと、
プロジェクトに制約されるというか発想ベースじゃなくてプロジェクトベースの進め方になってしまって、
なんかちょっと気持ち悪いというか進めにくいっていうことが起こるのではないかと。
そうですね。これでやってるとですね、複数のプロジェクト的なトップレベルのものが、
このAとCは同じじゃんと思って統合することも多いんですよね。逆もあるけど。
だからそういう操作って、例えばGTEの解説書ではあんまり出てこないですよね。
一回作ったらそのままゴーみたいな感じじゃないですか、あれは。
まあ中時レビューでチェック。
だからそのプロジェクトレベルの改編というか改訂というか改善も見据えた、
特にデジタルだったらそれが普通に可能なわけですし、それをしないならわざわざデジタルにする意味は特にないと思うんで。
だからそこのルート直下も変えていける仕組み、変えてもいいよと思える仕組みかな。
変えてもいいと思えるかどうかって結構操作では変えられるはずですから、別にデジタル続くかどうか。
12:01
でもなんか固定されてしまうんですよね、一回プロジェクトっていうの作ってしまうと。
せっかくデジタルなのにアナログみたいですよね。
そうそうそう。そういうのを出すとこうなるんではないかな。
さっき言ったようにでもこの順番の並び替えっていうのはアナログ的なんですよね。
だから非常に良好的な性質がこれにはあるんですよね。
だからやっぱりアウトライナーもツールとしては外せないところはありますね。
使う頻度に差はあるにせよ。
例えばスプラットボックスだったらだけあったらいいかっていうとそういうわけでもないなと。
これアウトライナーは昔からあったにせよ。
このワークフローが出てるのは最近じゃないですか。その前ってどうしてたんですかね。
みんな頑張ってたじゃないですか。
頑張ってた。
ファイルベースでもっと固定できあったんじゃないですかね。
1個のファイルにプロジェクトの情報をという感じで。
それで問題ない仕事の進め方やったのか。
結局さっき言ったようにプロジェクトレベルから変えられるっていうのは
例えば大幅さんとか僕のようにフリーランスで自分の仕事の裁量が変えられる場合じゃないですか。
そうですね。
上司からプロジェクトこれって言われて、でもこのプロジェクトとこのプロジェクト一緒じゃないですかっていうわけにはいかないですよね。
だから昔の仕事のやり方ではあんまり問題がなかったのかもしれませんね。
そういうことですね。逆にそういう仕事のやり方でフリーランスになったら
変えちゃいかんっていう何か吊り込みがあって変えないでいたんだけど
実は変えられることに気づいたと。
そういう感じですね、たぶん。
だからですね、さっき視点の切り替えっていう意味で
これ知ってます?アサルトっていう
シューティングゲームですか?
デビュースのグローブターって戦車があるんですけど、これだけをフィーチャーしたね。
あの戦車のゲームなんですけど、これすごいのはね、こうやって戦車を
ああ、そういう動き方するのか。
そうなんです。独特。2本のレバーでね、両方を同時に横に倒すところがあるんですよ。
ああ、今のアーケードゲームっぽいですね、これ。
一番驚くギミックがですね、こうやって乗るとボーンと上がって
ジャンプするんですね。
ジャンプするときに前方が見えるんですよ。
ああ、この間は弾に当たらないんですか?
当たらないです。
この間攻撃はできるんです。
このね、ズームの感覚が非常にさっきのアウトライナーだなと思って。
ああ、なるほどね。
で、みんなこの地上に行っ放したから、右も左も分かんないんだけど、
アウトライナーでこの上げ下げしてることによって、とにかく秒が切り替えられると。
なるほどね、なるほど。
この感覚をね、ふとね、これだって80年代、90年代の記憶が蘇ったんですよね。
斬新、この世代でこの体型って結構斬新ですね。
斬新だと思います。90年8月だ。
90年。
30年前ですよ。
俯瞰、そうやな、俯瞰。
俯瞰、俯瞰です。
これは大変、この感じのゲームはこれ以来あってない気がします。
15:04
僕も初めて見ましたね。
そうですよね。
横に移動すったり、マップ表示させたりはありますけど、時期がジャンプするの初めて見ましたわ。
これ宇宙空間だから、たぶんこのね、着地してもそんな壊れないとかそういうことだと思うんですけどね。
まあ結構無茶な説ですけどね。
ほんとね、ゲームというのはね、発想を刺激するというのはあってですね。
ゲームは良くないっていうのがありつつもですね、やっぱりやった方がいいんだろうなと思って。
だからゲームは良くないっていうのはさっき言ったように、プロジェクトAとBが一緒じゃないですかねっていうような人間になってはいけないってことでしょ。
そうですね。
既存の社会ルールに疑問点を投げかけるようになってはいけないってことですよね。
勝手に象徴を改善してはいけないみたいな。
そういうことだと思いますよ。
だから俯瞰ってよく言うんですけど、俯瞰、さっきの話を引き継ぐと、だからワークフローでやってることで地図作りに出て。
そうですね。
で、地図って一覧できないという意味があるんですよね。
ああ、拡大縮小ってことですね。
だから一目で全体が見えてこその地図じゃないですか。
だから例えば本当に自分のやることが地図よりももっと行算あって、より詳細であって、そのデータが全部自分に表示されたとして意味があるかってことはないんですよね。
自分が今抱えているすべてのこと、すべてのアイディアが全部表示されたとするじゃないですか。
一画面には絶対収まりませんよね。
それは多分地図として役割を持たないんですよね。
自分がこれから何をする、次をどうするかを決めるためにそんなに情報はいらないんですよね。
個々の要素が小さく、つまりさっき言ったジャンプした状態で詳細から遠ざかるわけじゃないですか。
しかもジャンプしたとしても全画面が見えるわけじゃない。周辺だけしか見えないじゃないですか。
でもそれでいいんですよね。
GTD的なものを真剣にやるとすごいたくさんのプロジェクトが多分できるんですよね。
気になることも多分大量に集まるんですよ。
それは多分地図の役には立たないなと。
あくまで自分が一望できるラインに留めておくっていう非デジタル的な考え方がここでは有用やなと。
そこを多分誰も教えてくれないんですよね。
デジタルツールでトゥーディストとかやってると、とりあえず気になることは全部プロジェクトにしちゃうんですよ。
着手できそうにもないことを。
それはもちろん着手できないことをしている時点で間違ってはいるんですけど、それを止めるアフォーダンスがツールにないというか、
むしろ逆のアフォーダンスがあるというか。
でも一応200個までしかプロジェクト作れない。
それは多いでしょ。どう考えても。
一応上限がありますけど。
せいぜい細かいのも言えても10か15くらいあるじゃないですか。
18:03
そうですね。それ以上になるともう把握できないですね。
選択する役に立たないばかりか選択を阻害することになりかねないんで。
ジャムの実験ですね。
だからやっぱりタスクシュートがいいのも絶対に有限じゃないですか、あれは。
それは1日に組みつけるからですね。
時間というものに収めている以上、やりたいことじゃなくてやることになるんで、やることの理想は絶対に有限なんで。
だからそこですよね。
アナログのやることリストもノートに書く以上有限じゃないですか。
ページを複数またいでもいいんですけど。
その点、デジタルだと無人像に入れられてしまうんで。
あれがまずいですよね。
まずい、なるほどね。
だから2つの方向があって、自分の意識で扱える、注意か。
注意で扱える量に留めておくっていうドーマ式なりワークフローリーの使い方があって。
一方でスクラップボックスの注意の上限を気にしない管理の仕方。
下に送られちゃっても構いませんと。
関連リンクでたまに出てきますからっていうやり方。
この場合は自分の注意と無関係に量をスケールしていけるんですよね。
その代わり、支配はできない。
一覧においてそれを組み立てたりしていくことは代わりにできなくなるっていう量極端があって。
その間を目指すと、僕は失敗すると思うんですよ。
無限の情報を自分の階層から無限できちんとコントロールしていきたいっていう欲求は多分無理だと思うんですよね。
だからその点、某ノーションとかはそれになりがちかなとちょっと思うんですけども。
最初はいいんでしょうね。
最初はいいと思います。1000までの情報はいいと思います、きっと。
それを超えると階層が扱えなくなってくると思いますね。
まず一覧できなくなりますから。
それが水槽、浴槽、EKBっていうことですね。
だから、自分で生態系を管理できるのは多分水槽までなんですよね、きっと。
そう、生態系ですね、まさにね。
そこを自分で手を加えてどこに何があるか分かっている領域はやっぱりそこのところまでなんですよね。
だって人間の注意はそんなに広がらないですからね、拡張されないんで。
記憶は外部記憶で拡張されますけど、注意の量はやっぱり脳の根本的なあれをいじらない限りはなかなか増えないと思うんで。
だからその情報を扱うときに自分の注意で管理できるものと注意を抜きにして管理できるものの2つがあって、
後者の場合に階層を持ってくると破綻するし、逆に前者は位置づける階層がないとうまくいかないということですね。
なるほど、完全にワークフロイとスクラップボックスの話に当てはめると分かりやすいですね。
そうですね、そういう感じだと思います。
両方いるんですよね。
両方いると思いますね、やっぱり。
もちろんやろうと思えばできるんですけど、得意な扱い方ではなくなってしまうので、
ちょっと無理っぽい操作の仕方をしてしまうというか。
21:00
だから普通に切り分けていいんじゃないですかね。
結局お話さんがやってられるようにリンクというものがデジタルで情報をつなぐ最大の力じゃないですか。
分けても別にいいんですよね。
ちゃんと適切にね、これでも手動でリンクをメンテナンスしなきゃいけないので、それはありますけどね。
それくらいでいいじゃないですか。そのテーマが自分の許容に収まる範囲のものをここに突っ込もうとしても多分ダメなので。
確かに先ほどの生態系という言葉はまさにここでドマに当てはまるなと思いました。
なるほど。
だってこれ今僕把握できてますもん。
そこなんですね、やっぱり。
実はダイナリストにももっとこのカオスが広がってるわけですけど。
だから時々これを思い出したのに開いて、黒いに鉢を分けてるんですけど。
なるほど。
描いてるんですけどね。夕食をしてるわけですよ。
やっぱりちょっとずつやっていくと自分の中で、いわゆるその身体化された知識というか、どこに何がはっきりあるか分かってるっていうものになるんで。
これだから結局全部データをエクスポートしてインポートっていうのは多分ダメなんですね、これは。
そうそう。
生態系壊れるやつですね。
壊れるんでしょうね。やっぱり他の池の水がーって流し込むようなものですからね。
そうですよね。全部がしかもフラットになっちゃうからもう大変ですよね。
大橋さんのこの形も少しずつ増えてこうなってきたその経緯がやっぱり重要であって。
だからやっぱり一番最初にインボックス、プロジェクト、プライベートみたいなのを作ってしまうのはやっぱり良くないと思うんですよね。
見通しも悪くなるし、上を描いてはいけないっていうのはコントロール性が一段階失われるってことなんで。
やっぱりそれは避けた方がいいなと、よくある教え方ではありますけども、避けた方がいいなと思いますね。
この黒いとこはダイナリストのアウトライナーに関してみんなが色々とこのブログに書いてるじゃないですか。
それを見ると大体そういう分け方なんですよね。
でしょうね、きっと。
そうする度に僕は迷ってたんですよ。やっぱりこういう風にカテゴライズしなきゃいけないのかなとかね。
一見分かりやすいですからね、なんとなく。
非常に教科書に乗るような見え方じゃないですか。
それが言うに否定できないんですよ。
でもやっぱりそれと自分の使いやすさが合致するかどうか。
プロジェクト形式、さっき言ったGTDが提示するような方式でスタートして変えていけたらいいんですけどね、自分の手に馴染むように。
でも多分それは逆に大仕事になるでしょうね、きっと。
一つ今思ったのは、GTDをやったからこそプロジェクトというものの認識が持てるようになっている。
もちろんそうですね。
だから必要なプロセスだとは思うんですよね。
もちろん僕はよくGTDに文句言ってますけど、もちろん僕自身もGTDに強く影響を受けてますし、
24:00
一番重要なのはワークフローそのものじゃなくて、気になっていることに対してこれは何かという問いをぶつけるということが、
おそらくタスク管理だけじゃなくて地域生産においても情報を扱う上で一番重要なプロセスだと思いますね、そこは。
それはやっぱり大切なんですけど、さっきも言ったように日本人ってああいう案の方を経典にしてしまって、
一脱を許さないような空気があるんで、それに対してみんな自分で考えようという意味で言ってますけど、
別に僕はGTDを否定してるわけではないですよ、もちろん。
非常に重要なものだとは思ってますけど、それぞれの人のリストの形とかワークフローを判断するチェック、
イエスノーチェックもあれもっと個別で作ってもいいと思うんですよね。
でもそれの発想にならないでいかにあの通りにするかってなってしまうのは何かこう違うなと思うので。
だから他のメソッドを使っていても使えますよという。
そうですね、というかむしろ他のメソッドをどんどん吸収していこうという感じですね。
たぶん自分の方法を作りましょうっていう経験が実はあんまりないと言うと言い過ぎですけど、
既にある方法を慣れましょうっていう日本社会では多いですけど、
あなた自身のメソッドを作りましょうって言われた経験が実はあんまりないのではないかなと。
そういう可能性があるということを知るか知らないかなと。
そうですね、確かに。
だからメソッドっていうのはエディタブル以上にプログラムワーブなことなんですよね。
アレンジとかカスタマイズを超えた領域にあるんですよね。
たぶんこの辺はエンジニアの方とかは非常に馴染みが。
そうなんですよね、きっと。
作っちゃえばいいじゃんっていう。
っていう感じなんですよね、きっと。
だからやっぱりパソコンっていうものが人の認識を変えるんですよね、そこは。
そう思いますわ。
何かに作るっていう、あれほどコストをかけると何かが作れる媒体ってたぶんほとんどなかったでしょうからね。
だから世の有料サービス、特にIT系のサービスは知識があればお金払わなくて済むっていうところはありますからね。
確かに。
全部作れないんですけど、カスタムできるというところも含めると非常にコスパはいいですよね。
コスパはいいし、自分に合わせた使い勝手のものができるし、作る作業そのものも基本的に楽しいんで。
良いことしかない。時間がかかることを除けば良いことになるんですよね。
でもね、このマクロの使用頻度が高いほどに、全然この後は利息が出続けるフェーズに入りますからね。
確かに、確かに。
でもやっぱり自分で作ることって、自分の作ったものを使うってことって、見通しとコントロールがあると思うんですよ。
だからあそこが悪くなったらここを変えたらいいし、あれが使えなくなったらここを変えたらいいって自分でコントロールできるじゃないですか。
でも与えられたノウハウって、ちょっとでも悪くなったらもう無理なんですよね。何がどうなってるかわからないので。
27:06
確かに。
その辺で、逆にそういうのが不安感につながるのではないかという気もしますけど。
容易に動けないみたいなね。
そう、だからGitHub使うなっていう命令が出てるらしいですけど、GitHubは何か分かってないからなんでしょうね、要するに。
そうですね、そうですね。だから根本的にリテラシーの問題になりますね。
まあそうですね。だから最初に上手くいくノウハウが提示されるから当然いくんで。
だからブログ記事の正しい書き方とかって言われても困るじゃないですか。
ある程度ヒット率の高い書き方っていうのは面白かったらあるかもしれませんけど、結局ある程度自分で試行錯誤してその方法を身につけるっていうのが一番の近道なんで。
そうですね、でも値段を付けて売ろうとするとこれが正しいんですって言うんですよ、みんな。
言わざるを得ないんでしょうね。だからある資本主義のトラップというか。
あなたのやり方でいいんですって言うと、なんか値段付きづらいですよね。
まあね、そりゃそうですよね。だから逆説的にそういうのをメソッドにするしかないんでしょうけども。
まさにだからそういうオルタナティブが必要なシーンだったんですね。
だと思いますけどね、そういうのってもう今更誰かのやり方に従う時代ではないと思うのですが。
そういうことを本来は僕らのテレ像の変態工夫っていう本で書きたかったんですけど、まだ書けてないっていうね。
それは書こうと思っているわけですね。
そういう話をしようと思ってる本だったんですけど、まだ全然書けてないっていうね。
今でも休止してるわけですね。
別の保険庫を書いてるから止まってるというだけですね。
とりあえずまとめとしてはドマをやってみようと。
そうですね、ドマっていいよっていう風通しがいいよっていうことですね。
記事もあるし、とりあえずマネから入っていただいて、マネながら自分流をね。
デイリーに今日のことを書く以外はもう自分流にするしかない方法になってるんで。
そうだからプロジェクトの流度って難しいじゃないですか。一般的に定義するのって。
だってこれ全部レベル合ってないですもん、このプロジェクト。
でもそうなりますよね。だって自分が注意向けるものの流度って合ってないはずなんですよ、そんなものは。
だからそのベースで、自分注意ベースで進めていいはずなんですよね。
僕が全くダメだったらデイリーログは続かなかったんですよね。
デイリー、日記的なものは別に続くんですよね。
多分だからね、ディプリケートですよ。つまり僕はタスク周りにデイリーログがあるので。
こっちにも書くとね。
だったらもうルートに残しておいて、プロジェクトに散らせるという。
30:04
一応痕跡として残してますけど。
そういうのも別に自分勝手でいいというか。
そうなんです。だからね、必ずドマにはデイリーログをつけなきゃいけないところだと辛い。
じゃあドマの入門該当的な記事は寄せておきますので。
はい、ありがとうございます。
ぜひドマに取り組んでいただければと思います。
前回に続いて、くらしゃさんと今日はドマの話をしました。
くらしゃさん、どうもありがとうございました。
はい、ありがとうございます。
