00:00
はい、うっちゃわせキャスト第90回ということで、今回もゲストにたくさんお迎えしております。よろしくお願いします。
よろしくお願いします。
久々に噛んでしまいましたが、90回なんですね。結構続いてますが、
100、もうちょっと逆ですね。これやっぱり何気なく続くと何気なく続くんですよね。あまり気を言いせずに。
僕そのうちの94回ぐらい登場してますよね。たぶんね。逆のうちのね。
はい、大変お世話になっておりますが、いくつかハックニュース的なことを最初にお伝えすると、まずたくさんが出版された
アウトライナー実施ニューモン(技術評論者)が出た本が
なんと増刷されたということをだいぶ前に聞いて、すばらく忘れてたんですけども。
いやー、素晴らしいことです。
いやー、驚きですよね。6年前ですよ、だって。
会話になってもおかしくないぐらいの勢いなんですけども。
いやー、このまま消えていくものだと思っていたので。
まあでも正直アウトライナーについて語っている商業出版の本って、ほぼ現在あの本しかないと言っても過言ではなく。
そうでしょうね。アウトライナーを中心に据えているのは多分今絶版じゃない本ではあれしかない。
あと英語の、翻訳のやつはありますけどね。小説のやつ。
でもアウトライナーじゃないな。アウトラインを使うかどうかっていう話ですよね。
そうですね。小説を出品する上でアウトラインをどう作っていくかっていう話。
アウトライナーの話ではないですね。
ないでしょうね。
だから経由というか類称がないというか。なので技法さんも今後も頑張って売り込んでいってほしいところでございます。
ありがたいですね。ありがたいっていうか、もう率直に嬉しいですよね。
本屋に並ぶことでアウトライナーという通路する人もいるでしょうし、
ライティングの手塚くあたりからアウトライナーに興味を持って、
どういう使い方するかっていうところで入っていくっていうルートもできてるわけで、
ワードとかExcelみたいに大量に本が必要な本でも、ツールでもないわけで、
何冊があれば十分なので、そのうちの一冊として残っていってくれたらなという感じです。
はい、ありがとうございます。
もう本当に今更なんですけど、第90回になって打ち合わせキャスト、AppleのPodcastから配信されるようになりました。
なんで今まで配信されなかったんですか?
なんで配信されたかっていうと、僕が忘れてたんですけど、
忘れてたっていうか、Ankerっていうプラットフォームって、
もともと見たマルチプラットフォーム志向でAnkerに登録したら、
もう勝手に他のプラットフォームに配信してくれると、
03:02
Spotifyとかいろいろなものに、こっちの手続きはほぼいらなかったんですけど、
そのApplePodcastについては、自分で手続きしてくださいよっていうことやったらしいんですよ。
あっ、そうなんですね。
それ僕知らなかったんですね。
で、とある方から、打ち合わせキャストってApple iTunesで聞けないですかって言われて、
え?ってなったんですよね。
で、それを何ヶ月か前に聞いて、それすらも忘れてたんですけど、
たまたまAnkerのサイトにこのPodcastの音声ファイルを上げていったら、
なんか、利用可能なPodcastチャンネルみたいなボタンを見つけて、
追ってみたら登録することができたんで、
それは登録自体2日ぐらいでできたんですけど、
なので今後はAppleのPodcastからでも聞くことができます。
朗報、朗報ですね。
いや僕もね、なんでないんだろうなと思ってたんですね。
あの、なんだっけ、あれはあるじゃないですか。
ブックカタリスト?
ブックカタリストあるじゃないですか。
あれはゴリゴさんがやってたからです。
なんで同じAnkerなのにないんだろうなと思いつつ、
思っていただけで何も言わなかったっていう。
僕自身がPodcastを聞く側ではないので、
あんまり気にしなかったんですけど、
簡単な手順でできたので登録しておきました。
で、同じPodcastを繋がりで、
仕事アナの大橋さんが仕事アナキャストという
Podcast番組をつい最近先週ぐらいかな、開催されて、
あのレスはまた概要欄に貼っておきますが、
Anker.fmの仕事アナとか、内装は仕事アナキャストで
検索すれば出てくると思います。
はい、1回当たりが15分ぐらいの短いPodcastなんですけど、
続きもになっているという結構珍しいタイプのPodcastです。
新しい。
で、もう1個、ニュースじゃないんですけど、
CBAというのをちょっと考えておりまして、
で、これ以前Rサービスで書いたんですけども、
KDP祭りっていうアイデアがあったんですよね。
で、そのKDPってのは、キンドルセルフパブレスチングじゃなくて、
人のナレッジを集めた本を紹介しようっていう名前だったんですけど、
さすがにKDPという名前をそのまま使うのは紛らわしいなということで、
大案を考えていたんですけど、CBA、
Craftbook Awardというちょっとカッチュイな名前を思いつきまして、
このCraftっていう名前を発見した時に、
もうこれは買ったなと思ったんですけども、
Craft BeerのCraftですね。
名前が手作り感というか職人感ってある言葉で、
しかも何かを作るという具体的なイメージも付随してると。
で、まあセルフパブレッシングって言ってもいいんですけど、
あのまあCraftbookって呼ぶと。
06:01
で、そのCraftっていうのが職人というか技術に関することなんで、
僕らがよく書いているような個人のノウハウを扱う本っていうものを、
そう承するジャンルとして、Craftbookって呼んでみてはどうかと、
いうことを考えてまして、
12月ぐらいに、その年に出たCraftbookを応募、
時旬か多旬かはまだ決めてないんですけど、
してもらって、それを何か一つのウェブページに掲載して、
今年こういう本が出ましたよっていう、
ガイドページかなみたいなを作れたらいいなと。
アワードってつけてますけど、別に対象を選ぶとかそういうつもりはなくて、
あのなんか3文字目が欲しかったからアワードって言ってただけなんですけど、
まあそういうご好みなんで、
まあこれを聞いてる方とか、あるいはたくさんとかでもいいんですけど、
まあそのエンドリーしていただけたらそこのページに掲載されるという感じで、
で、そういう集合場所があることで、
あの非常に地味になりがちな本もそれなりに注目されるようになるのではないかと。
で、まあこれは試みとしてカーソルっていうものの、
まあ別バージョンというかな、カーソルはまあ一か所に集めるという形で、
テーマを決めて原稿を書いてもらうというタイプですけど、
どうせ雑誌の色に染まるっていうか、
まあ雑誌の色なんかないんですけど、カーソルには。
まあその本の作り方がカーソル余製になってしまうので、
もっと自分でコンテンツを出したいという人向けに、
まあこのCBAというのを作ったと。
で、あの、もっと前はエヴァーノート豆技50戦っていう本を作った頃は、
なんかレーベルっぽいものを作ろうと思ってたんですよ、ずっと。
はいはい、そう言ってましたね。
でも結局そのレーベルに値するかどうかみたいな判断をしないと、
レーベルって機能しないじゃないですか。
はいはいはい。
なんでもなのったら一応わけにはいかんわけで。
そうするとそれを担保するためのコストって多分見合わないだろうなと思ったんで、
それならその年に1回祭りのように集まって、
まあその露出する場所だけを提供するということに留めたら、
僕の運営コストも多分ペイできるだろうなという感じで、
まあこういう形を今目指していると。
なるほどなるほど。
もう一個、この話長なるんですけど、
もう一個だけ言うと、
そのCraftbookっていう呼び方を作るだけじゃなくて、
そのCraftbook writing method、
まあmethodっていうと大きいですけど、
こういう風に書いたらいいんじゃないかなっていう指針というか、
今のもちょっと一緒に提示できたらいいなと思って、
あのパクリはやめましょうとか、
その参考文献はちゃんと書きましょうみたいな、
そのいわゆるその論文の基礎メソッドみたいなものの、
09:00
そのCraftbook versionみたいなものができたら、
そのもうちょっと全体のクオリティアップに役立つんではないかなと。
なるほど。
これ本作り全般に関して言うと、
ちょっと大げさじゃないですか。
本はこう書けっていうのはさすがに大げさですけど、
Craftbookはこう書きましょう、
こう書けたらいいねっていうぐらいであれば、
そのそこまで押し付けがましくないというか、
ガイドブック的になるんではないかというようなことを、
今考えているところです。
なるほどなるほど。
まあ、これどう決着するかわかんない。
とりあえず今年やって、来年やってっていう感じで続けながら、
あまりに募集がなかったらやめますけども、
今のところはそういうことを考えているっていうとこです。
今年出た本ってことですね。
毎年やるんで、その年出た本に限定しようかなと。
そのページを年度ごとに作っていけば、
なんかカタログっぽくなるかなっていうのがイメージですね。
出版ニュースで言うと、
小田彩田さんが「Kindle出版のメイキング」っていう本をつい先日出されて、
僕勝手まだ読んでないんですけども、
タイトル通りのことだと思います。
どうやって本を作るのかっていう本だと思います。
この形のハイペースって感じですね。
すごいですよね。
1冊あたりのボリューム自体はそこまで大きいものではないですが、
それを考えたとしても結構のハイペースですよね。
それほど大きくないとは言っても2、3万字は毎回あると思うんで、
たぶん普通に会社員もされていると思うので、
これはすごいなといつも思ってますけど。
そのノウハウがたぶん解説されてるんじゃないですかね。
最後なんですけども、
前々から研究しているDramaというDevWinerさんのツールに新機能がありまして、
これがすごいんですけども、
RSSフィードをアウトラインに取り込めるという機能です。
素晴らしいですね。
これもともとインスタントアウトラインという機能がありまして、
他の人のアウトラインのXMLを登録しておくと、
その更新情報だけがわかるっていう機能をやったんですね。
よくよく考えたらこれってRSSフィーダーなんですよね。
そうなんです。
僕が最近実装されたRSSリーダーの機能を見て、
これってそういうことやったんですね。
初めて対応関係に気づいたんですけど、
だからもともとインスタントアウトラインといって、
他人が作っているアウトラインの更新情報を取れるだけじゃなくて、
いわゆるブログで発行されているRSSも取得して、
当然そのRSSが本部も含んでるんであれば、
12:02
本部内容もアウトラインにバリッと取り込めちゃう。
すごいですよね。
これはすごい機能で、すごい機能っていうか、
アウトラインから出ないっていうか、動かないというか、
ドラマを使っていたら必要な情報が必要というか、
仕入れたい情報が入ってくるし、
もともとあるツイートする機能とか、
ブログで公開する機能によって、
ドラマ上から動かずに情報を外に出すことができるっていう、
入り口と出口の間になる、
ベースキャンプのようなツールになってるし、
仕様としてますよね、これは。
これだからもともとこれもフロンティアにあった機能だったと思うんですよね。
なるほど。
で、アウトライナー界のEmacsとか言われたんですけどね。
まあ確かにそれっぽいね。
その中で何でもできるみたいな。
だからもともとフロンティアベースに
Radio UserlandとかManilaとか、
そういうCMSとかブログ関連のツールを派生で昔作ってたんですけど、
その機能がOPMLになったり、RSSになったりっていう、
それをまた今度ドラマで取り込んでる感じですよね。
なるほどね。
だからアウトライナーっていうよりも、
このアウトラインというデータの形式というかプレゼンテーションの、
アウトラインの形式も結局OPMLって結局XMLなんで。
そうですね。
そのアウトラインという形式を使って何ができるかっていう、
あらゆることができる。
あらゆることができると思う。
これは本当に、このRSフィードを取り込むための手順というのが、
その項目を作って、その項目のアイテムのアトリビュートっていうのを、
フィードに登録するっていう作業が必要なんですけど、
まず試してないですか、ドラマスクリプトっていう、
ドラマ用のスクリプト。
何の説明にも当てられない。
ドラマ用に調整されたJavaScriptにも、
フィードを読むっていうのが確か最近追加されてて、
そのコマンドを叩くことでも似たようなことが実現できるんで、
いちいち自分でURLを入れてっていうことをしなくても、
そのスクリプト経由で取り込むようなことも、
おそらくはできるようになっております。
もしかして、他人のRSSフィードを取り込むって思っちゃってますけど、
これもしかしたら自分の書いた何かを、
それこそマメロン文じゃないですけど、
それをブログ的に発行しておいて、
それをまたそのアウトラインで取り込むとか、
いろんな可能性を感じる機能ですよね。
15:02
これ多分、使う側の想像力次第で、
すごいいろんなことができるんじゃないかなと。
なるほど、確かに。
スクラップボックスの更新情報をフィードで入ってるんで、
だからスクラップボックスの更新データを
自分のアウトラインに引き戻すこともできるということですね。
そうですよね。
例えば僕だったら、そのアウトライナーの記事をブログに書いてますけど、
それをアウトラインに取り込めるんだったら、
それを使ってもっと大きなアウトライナーに関する
何かのアウトプットを作るっていうことがしやすくなるんじゃないかなとか。
確かに。
そうすると、マメロン文としてのブログみたいな、
自分のための、その梅沢的な意味のマメロン文なんだけど、
それをブログとして公開して人も読めるようにしつつ、
後々自分でも使うみたいなことも考えられるかなと思ってたんですよね。
やってもやりませんけど、一般ところ。
だから、ワークフローリとは違った意味でのプロセス型というか、
もっと大きい射程でのプロセス型というか。
そうなんです。射程がものすごく大きいですよね。
やっぱりこの辺がそのマイナーさんの凄さというか、
多分小さいことをすごく大きいことに繋げるんですよね、
確かに。
マイナーさんって。
だから、そう思いながら見てます。
関連する話題なんですけど、
Twitterで見かけまして、けらい14さん、
多分ハンドル漢字で言うとけらい、そのままけらいという方なんですけど、
アウトライナーが閉じるのも面倒問題というのを言及されてて、
アウトライナーは確実に書くのを楽にはしてくれるし、
あと他人の文章をアウトライナーにコピーすることで、
文節化しながら読むこともできるので、
他人の文章を読むのにも役立つんですけど、
自分の文章を振り返るのは必ずしも楽にならない感じがありますというのがあって、
まさにそうだなと。
まさにそうですね。
僕がアウトライナーにアイデア断片を多数並べても、
結局使えなかったというところの読みにくさというところだから、
他人の文章を読むというこの読むと、
自分の文章を振り返って読むという、
その同じ読むって使われてますけど、
行われてる動作が違うわけですよね。
そうですね。
電車はもっと分析的な読み解くという感じで、
校舎はもっとビジュアル寄りの読むという行為で、
校舎は基本的にはあんまりアウトライナーは向いてないというか、
バレット一つですらもう邪魔な人もいますし、
インデントとか空海行にバレットが付いてるのがダメとか、
いろいろ難事があるわけですね。
でもその上で考えたのはやっぱりドラマなんですよね。
ここ引き戻ってくるのが。
なぜかというとドラマの、例えばブログポスト機能で、
18:05
アウトライナーにデータはあるんだけど、
読むときにブログの形式になってるっていう選択が
可能になっちゃってるわけですね。
そうなんですよね。
読むための形式で吐き出せるわけですよね。
それは他人が読めるように書いてるわけで、
それは自分が読んでも読みやすい形にはなってるわけですね。
例えば、どんだけドラマ上でインデントを作ってても、
ブログ形式ではむしろ見出し+本文の形に変換されてると。
これはとても読みやすい。
だからワードが2つのモードをいきいきするように、
いきいきしてるわけじゃないんですけど、
2つの描写モードをドラマ上では持つことができる。
これ原理的にデジタルデータなら可能なはずなんですよね。
これは。
ワークロリーはエクスポート、
データ形式のエクスポートはできないんですけど、
ビュースタイルのチェンジっていうのが概念的にほとんどなくて、
ワークロリーのボードモードとアウトラインモードぐらいかな、おそらくは。
そうですね。
色を変えたりとかはもちろんできるんですけど、
アウトライン表示から全く違うものにするっていうことが、
たぶんこの2つのツールではできないんですね。
ROMリサーチはアウトラインのバレットと、
本文のバレットっていうのが確かあって、
本文のモードを選ぶと、
いわゆるテキストデジタルに打ち込んでると同じような表示になる。
でも、やっぱりそれはでも、
その項目のモードが変わってるだけであって、
全体が変わってるわけではない。
バレットがあるかないかっていうこと。
っていうぐらいしかない。
そこはやっぱりちょっと不十分とまでは言いませんけど、
ある種のデータを扱うのには向いてないなという感じがしますね。
だから、このケライさんが書いてるのも本当にそうで、
結局アウトライナー、
特にプロセス型のアウトライナーって、
今まさに動いている、育っていたり、
動いているものを扱うのにはすごくいいんですけど、
静的な情報を蓄積していくこと、
あとあとそれを見ることも含めて、
静的な情報を蓄積していくことはできるけれども、
あんまりやりやすくはないですよね。
そのまんまの形だと。
だから、アウトライナーはそういうものだって言っちゃってもいいし、
もしかしたら表示の仕方を変えることで、
そうじゃないアウトライナーを作ることもできるかもしれないとは思うんですけど。
現所のアウトライナー話っていうと、
Appleに採用される際にスライドで表示できたら、
これ良くなるよっていう、
21:00
まさにそれが現所のビューモードですよね。
だから別に同じことは普通に、
EvernoteとかStrapboxってノートをプレゼンテーションモードで表示することができるんですよね。
それは便利なわけですよ。
だから別に、
ワークロイドもできるのはできるんやけど、
階層が無限に入れ込んで、
見出しの位置がプロダクトとは違うんで、
どこが本部になって見出しになるのかが、
多分個別に設定しないと分からなくなってしまうのがあるんでしょうね。
多分素直に考えれば、データを表示の仕方を変えること自体は多分簡単だと思うんですけど、
例えば読みやすいように表示するためには、
例えば第3回想が本文とかで決めなきゃいけなくて、
そうするとそのプロセス型都市の良さを損なっちゃう可能性があるんですよね。
だから、単純に機能としてできるからそれがいいかっていうと、
多分そうじゃないかもしれなくて、
その問題実はドラマにもあるんですけど、
アウトラインをブログとして表示するときには、
プロセス型じゃなくなっちゃうんですよね。
日付、年月日の構造化に置かないときちんときちんとならない。
だからやっぱり文章というものがスタイルを持ってるっていうことの裏返しなんですけど、
あれ使ってて思ったんですけど、
やっぱりこの構造からは逃れられないんだなと思ったんですよね、ブログにするときって。
そうですね。
多分ワイナーさんはあんまりプロセス型とプロダクトが、
その言葉をどう使うかは別として、
多分その違いを意識してないと思うんですよね、まだ見てると。
だからドラマのアウトライナー自体は明らかにプロセス型であるにも関わらず、
あそこでそのブログとして表示するっていうことをやった瞬間に、
プロダクト型として使わなきゃいけなくなると。
だから別にそれをそれで全然機能としてはいいんですけど、
その使うときにそのプロセス型の良さを活かせるかどうかっていうことで、
ただプロセス型の良さを活かそうとすると、
このケライさんが書かれてるみたいに、
あの性的な情報を蓄積することには向かなくなっちゃうっていうことですよね。
ここはまあまあ、ジレンマというわけではないですけど、
例えばドラマの場合はファイル、ブログ、OPMLと普通のファイルっていう別のファイルを切り分けることで、
プロセス型、プロダクト型に使う面もありつつ、
プロセス型、プロセス型で使うということも一様できるので。
そうですね。
だからファイルで切り替えるわけですよね。
機能じゃなくて自分の頭の中で切り替える。
でもそれぐらいじゃないですかね、妥当なとこ、着地点で。
僕はそのドラマのブログ、OPML触ったとき非常に使いづらいなと思ったんですけど、
まあそれってもう要するに慣れの問題なんで。
だからまあ、使い慣れたらこれはこういうもんだと思って違和感はなくなる気がしますね。
24:03
うん。
そう、だから、まさにでもこのケライさん書いてるみたいに、
書いたことを記録していって蓄積して後から読み返すっていう目的だと多分、
アウトライナーでもできないことはないけど、もっといいツールが他にあるかもしれない。
そうですね。
というふうに、アウトライナーフリークの私でも思いますね、という。
以前、勉強したことある野良鉄さんがそのワードで日記を書いてるという記事を少し前に書かれたんですけど、
ワードなんてもうまさに読み返すための文章を書くつもりで、
向いてるんやろうなと思います。
いくらでも読みやすい形に表示できますからね。
だからやっぱりそのリッチテキストを直接扱おうとか、印刷を念頭に置いたページレイアウトができるっていうワードとかスクリプナーとかの方が、
単に情報を置いておくというよりは、情報を置いたそれを読み返すものとして保存するっていう場合には、
アウトライナーよりは遥かに向いてるんで、アウトライナーで読みやすさを担保しようと思ったら、
だから項目の数を絞っていかないと。
だから読みやすくするためのこの構造とき維持っていうのが多分必要で、
並べて保存しときゃ読みやすくなるかっていうと、これむしろどんどん読みやすさが下がっていくというか。
そうでしょうね。
これは僕自身がそのアイデアノートを貯めてたときに感じたんですけど、
だからツールを切り分けるか、ツールの使い方を変えるかのどちらかにしないと、
入力しやすい、保存しやすいのと読みやすいっていうのは機能としては別なんだなっていうのが、
ここまで10年の学びですね。
10年。
長くかかりましたが、理解するのにだいぶ長くかかりましたが。
多分それを両立させるうまい方法っていうのは多分見つかってないんだと思うんですよね。
そうでしょう。最終的にうまい調和っていうのは多分ないんでしょうね。
多分そこはある程度使う側がやらなきゃいけないのかもしれないし。
例えばそのアイデア断片の的な一行の書き込みがアウトライン上に並んでると、すごく窮屈な感じがするんで、
僕はそのモードだったらもっと業館が広い方がいいなってずっと思うんですよね。
Line8が2以上、2EM以上あった方がいいかなと思うんですけど、
そうすると普通のアウトライン、普通のリスト見たときにものすごいまぬけな感じになるんですよね。
だから個別ごとに、個別の情報ごとにスタイルっていうのは変わった方がいいとするならば、
27:00
やっぱりワークフローリーの限界みたいなのが、限界というか、どこまでも同じ構造がずっと広がっていくというものに対するある種の限界性は多分あるんだろうなと思いますね。
そうですね。だからそういう使い方をしようと思えばそういう限界として感じられるし、
一方ではどこまで階層降りていってもズームすれば同じ形になるっていうフラクタル構造を目で見えるようにしたことの凄さっていうのもあるし、
というのはもちろんありますね。
だから、どうでしょうかね。
いや、わからないです。
ワークフローリーはあれ以上複雑にしないといけない気はしますよね。
ワークフローリーはあれはあれでいいんです。
ある情報構造の中で自由に配置できるという良さはあって、
ある種のこういう単純化というかモデル化というか、情報構造のモデル化が行われていて、
グラフ理論でグラフを書くのに似ているんですよね。使うパーツ限定できないんですよ、グラフ理論で言うと。
だから、すごく複雑なものもあの構造に当てはめることで人間が操作できる認知レベルに落とせるっていうのはあるんですけど、
ドラマの例で言うとファイルを分けることでブログ的に使うこともできるし、そうじゃなく使うこともできるっていう、これ複雑化してるわけですね。
あるいは複雑をそのまま表現してるというか。
だから、どっちがいいかっていうか、どういう用途があるかっていうことなんですけど、
片方は操作したい、片方は見るために使いたい、みたいな切り分けをする場合は、
ワークフローリーの場合ってアトリビュートみたいなのが作れたらいいんですね。
だからドラマと同じように。項目に対してこれはこういう性質を持つものだから、こんな風に表示してねとか言えたら、多分同士のことができるんですけど、
それはでもほとんどワークフローリーじゃなくなってるから、なんとも言い難いんですけど。
僕自身はワークフローリーすごい好きですけど、ダイナリストとドラマが結局ファイル分割にしていることを考えたときに、
もしかしたら答えはそっちじゃないという気はしないではないです。
最終的にはやること、何をやりたいかによるんでしょうけど。
よるんですけどね、もちろんね。
あともう一個はワークフローリーの形式だったら、例えば今ズームして見えてる範囲にこのスタイルシートを適用するとか、
全回想を共通で当てるんじゃなくて、ここから下とか今ズームして見えてる範囲に異なるスタイルシートを適用する。
そのスタイルシートを簡単にメニューから選べるようにするっていう方法はあり得るなと思うんですけどね。
それはあります。結局ワークフローリーは個別がURLを持ってるんで、全ての項目がURLを持ってるんで、そのURLに対して何かしの条件分岐を起こすことが可能なので、
できるはずですよね。
30:00
それは原理的にはできると思います。ただURLを変えるってしまうと機能しなくなるんですけど、
でもワークフローリーは別に項目移動してもURLは変わらないからほぼ問題はないですね。
だからその自分のいくつかの用途に合わせたスタイルシートを自分である程度見た目を設定できて、それをメニューとして
ズームした画面から選べるともうちょっと違うかなっていう気がしますよね。
そうですね。
一応ダイナリストはプロにするとCSSを上書きできるんですけど、あれも全体に対しての。
全体になっちゃうでしょ。
だから個別の項目に対してできる、これはドキュメント風に見たいとか、これはリスト風に見たいとか、これはアイテムカード風に見たいとかって選べたら、
もっと使いやすさは広がりそうな気はしますね。
そうですよね。だからこのケライさんみたいなケースの使い方だったら逆にこの下は閉じないで全部開いちゃうとかね。
そうですね。そういうのもあると思います。
閉じるのも面倒で本来はショートカットの出番なんですけど、
ショートカットで採用してない操作とか、あとはモバイル利用の場合ってショートカット全部死亡しますから、
これ難しい問題なんですよね。だから正直言うとアウトライナーはあんまりモバイルで使うものじゃないかなと僕は最近思うんですけど。
今のこのモバイルのあり方だと、多分アウトライナーの力を100%発揮させるのは難しいかなと思うことは多いですよね。
普通のリストツールとほとんど変わらない感じになっちゃうことが多いですね。そう感じることが。
そうですね。一番うまくやってるのって、Omni OutlinerのiPad版とかはよくできてるなと思うんですけど、
グループ、まとめて上位階を作ることとか、
ワークフローインと違って、本目をまとめて1個1個飛び飛びで選択するみたいなこともできるし、
タッチ型の画面でアウトライナーを操作する方法に関しては一歩先行ってる感じがしますね。
ただ、動機に問題がありすぎて。
ちょっとあれなんですけど。
ここも難しいですね。ローカルのOmniとウェブブラウザーのワークフローインとかはダイナリスト。
ドラマはどっちかっていうとウェブブラウザーよりで。でも話に聞いたところによると、
ドラマのMac版はローカルのファイルが扱えるらしいんですよね。
なので、2つのコンピューターで同じファイルを使うことはドラマではできますね。
33:05
でも、それがウェブ版とは同期次第。現状は。
難しいところですね。
これも考えてると思いますけどね、デイブはきっと。
ただ、ドラマは結局ファイルなんですよね。
ファイルですね。
だから、どうしたって2つ以上のデバイスで編集すると競合する可能性はありますよね。
同じファイルだったら。
確かどっかでドロップボックスのAPIが叩くことができないみたいな話を彼が書いてたんですけど。
ドロップボックスが素直に使えるであれば結構スムーズにいけるはずですけど。
まあ、そこは上手いことではない。GitHubとの連携みたいな話を読みましたが。
そうか。それでやれる可能性はあるのかな。
その辺も、Gitをプッシュプルできる人であれば何も問題はなくなりますけど、それが実現すると。
ちょっと面倒なんで。
やっぱりそれが表に出てきちゃうと。
ちょっとね。
辛いところがあって、ここは難しいところではあります。
これが実はマイフリーの大爆笑です。
今回はちょっと手短な話になると思うんですけども。
僕が最近気になってる話題の一つで、タスク管理にどれぐらい手間と時間をかけておられるかっていう、
かけようという理念じゃなくて、実際にどれだけかけているかという現実的な話なんですけど。
数年前、5、6年前までは僕結構、いわゆる集字レビューとかも含めて、
完全なリストを作るっていうことを、厳密とかきちきちの一歩、二歩手前ぐらい前までやってたんですよね。
100%じゃないんですけど、86%ぐらいはきちっとリストを作ってたんですけど、
最近もうほとんどそういうのを作らなくなって、
デイリータスクリストはもちろん毎日作ってますし、
例えばまたリビジョンのやらんなあかんと発覚したことをリストにするとか、
というファイルを作っておくっていうことはやるんですけど、
それ以外のことほぼ何もしてないと。
でもタスク管理ツールと呼ばれるものも一切使っていないと。
で、話を聞くと、いくつかの話で聞くと、最近似たようなことになってるっていう人が増えてるんですけど、
たくさん今どんな感じでやっておられるかなっていうのがちょっとお聞きしたかった話です。
タスク管理をですか?
タスク管理関係、非常に大雑把でいいんですけど。
だからどこまでがタスク管理が大かんなんかなって思ったんですよね。
かけてるといえば結構かけてて、1、2時間かけることもあるんですよね。
36:07
っていうのは要するに今日のアウトラインを作るのにそのぐらいかかってることがあるんですけど、
そういうときって別にタスク管理をしてるわけじゃなくて、
実質的にタスクを書きながら仕事をしちゃって、作業自体をその中でしちゃっていたりするので、
いわゆるタスク管理と呼ばれていたものと、1日のアウトラインを作るっていうのが一体化しちゃってて、
例えば今日これを考えとかなきゃなとか、例えばわかりやすいところでいうとこの企画を考えとかなきゃいけないなっていうときに、
そういうふうにアウトラインに書いて、その下に内容を書き始めちゃったりするので、
それ自体がタスク管理と言えないことはないけれども、
実際はタスク管理を大幅に逸脱してるというか、タスクだけ書くっていうことがあまりなくなっちゃってますよね。
リビジョンに今書いてる話ですけどね。
いわゆるあえて意識的に言えば、純タスク管理、タスク管理のためだけの時間っていうのがほぼ消滅してたと。
そうですね。日によりますけどね、もちろん。
いわゆる受け追い系の作業をするときに、わーっと降ってきたタスクっていうのはやっぱり、
降ってきたタスクとして書くので、そういうときはより純タスク管理に近くなると思いますけど。
例えば、オファータスクの依頼とかが、メールとかチャットとかが発生したとしますよね。
それはアウトラインに記述されると思うんですけど、どういう項目に書かれるんですかね?
例えば、今日のアウトラインっていうのがあって、例えばメールで何かが来たときには、
何とかからのメールっていう項目を立てて、そのメールの文面をそのまま下に貼り付けちゃうんですね、アウトラインの中に。
で、見出しを立てて、例えばそこにタスクがあれば、そのタスクっていう見出しを立てて、その下にそれを入れちゃうとか、
メールの中身を一旦貼り付けてそれを解体してタスクっぽくしちゃったりとか。
なるほど。
メールの文面そのものがメーラーの中に残ってるので。
そうですね、はい。
だから、メールで来たらそんな感じだし、誰かとズームで打ち合わせしてて、タスクが発生したら、
打ち合わせのメモをその中で取っているのをやっぱり同じように見出し立てて、タスクと考えとることに分けたりとか。
39:00
タスクを書く項目の見出しはタスクって書いてあるんですか?
それもその時によっていて、普通は日付の下にやることを普通に書いてるんですけど、
例えばリビジョンっていう新しい作業が来たとして、その話が発生した時にリビジョンの打ち合わせ、
倉下さんと打ち合わせとかって書いて、打ち合わせの内容をメモするじゃないですか。
はいはいはい。そのメモをした中から自分のタスクだなっていうのを引っ張ってきて、その時にタスクっていう見出しを立てて、その下に落としてきたりはする。
そういう時はタスクが明示的に書かれるわけですね。
書かれるんですね。タスクって書くこともあるし、書かないこともあるので、決まってないんですけど。
決まってないってことはタスクというので検索して一括で抽出するみたいなことはやらないわけですね。
ああ、そういうことか。
例えば倉下さんと話したテレビジョンっていうプロジェクトができた時に、1日の中でアウトラインの中でそういう構造がその下にできるんですよね。
はいはいはい。それはわかります。
で、そしたらたぶん翌日に前の日のメモを見返した時にそのリビジョンっていう新しくできた項目をバサッとカットして、その1日のところから、allという名前がついている、全プロジェクトリストみたいなアウトラインがあるんですけど、そこに持ってって、そこの項目になるんですよね。
だからいわゆるプロジェクト化というような現象が起こるわけですね。
そうですね。そのタスク管理用語でいうと。
なるほど。
1項は例えば、じゃあ今日はリビジョンやろうっていう時に、そのファイルという項目を開いたら、そこにタスクっぽいものが書いてあるから、それが頭の中のタスクリストに入るみたいな感じですか。
そうですね。次の日の日付の下に書く時に、そのプロジェクトリストみたいなやつを見ながら、これは今日やんなきゃなとかっていう形で、個別のその日にやることを日付の下に書くんですけど、そっちのプロジェクトの方から引っ張ってきたりとか、検索して抜き出すみたいなことはしてない。
逆にその全プロジェクト、いわゆるGTDというかプロジェクトレビューというような、その全プロジェクトを見返して、そのプロジェクトの中のリストを整合させるみたいな行為とかってやってます?
やることもありますけど、たぶんレビューだと意識してはやってなくて、アウトラインを見ると僕シェイクしちゃうんですよね、本能的に。で、それが結果的にそのレビューの役割を切っているというか、そのALLっていう名前の全プロジェクトのアウトラインみたいなものをシェイクする、一つの文章を飛び出してるわけです。
42:05
これが自分が今やる、とりあえずやろうと思ってることだと。そのことに関する文章っていう二次式なので。
で、そのやらなきゃいけないけど、手つけてないやつを上の方に持ってきたりとか、これとこれは一緒にやった方がいいなっていうのがくっついたりとか、見てるうちにこれいらないようになってばさって切ったりとか、っていう作業をすることが結果的にレビューになってますけど、ただその意識してレビューだと思ってやってないので、
こういうことですごくスムーズにプロジェクトが回ってるように聞こえるんですけど、そんなことはなくて、結構抜けるわけです。
結構やんなきゃいけないの忘れてるとか。
ただ今の自分の仕事の状況だと、まあでもそのぐらいで十分回るので、これが例えば全職の中にいるときだったら多分もうちょっと違うようになると思います。
もっといわゆるプロジェクト管理に近いやり方になると思いますけど。
そうなんですよね。だからタスクという記号を必ずつけて後から抽出するっていうことって、いわゆるプロジェクト管理的なことなんですけど、
そういった抜け漏れをなくすというか、ある種の厳密さを必要とする場合に要求されることなんだろうなというのを最近そういうことを全然しない自分が感じてるんですけど。
だからやっぱり抜け…。ごめんなさい。
どうぞどうぞ。じゃあ言いますけど、
完全にタスクを網羅なく、例えば今86%網羅率を99%に上げたとして、その差が詰まった10何%のタスクができるかっていうと、できないんです。別に。
むしろもう8割補足したところで7割ぐらいしか結局できないんですよね。
そこの不完全さというのを許容できるように最近になってきたのかなというのが考えてると思います。
それ大事だと思いますよね。
完璧なシステムを作ったとしても、人間は完璧じゃないので、
そうすると逆に自分の作ったシステムの完璧さゆえに、自分のその完璧じゃなさがより強調されちゃうんですよね、自分の中で。
わかります。
それで結局無用にダメージを食らうことになるんで。
ただやっぱり確かに絶対に忘れちゃいけないことってあって、
仕事は絶対に忘れちゃいけない締め切りってありますけど、大体なんとかなるんですけど、
45:03
やっぱり何かのお金を入金するとか、
この日までにこれは振り込まなきゃいけないとかっていう、それを忘れたら致命的なことになるっていうことも中にもあるので、
そういうのは逆に僕は非常に忘れる人間だっていう自覚があるんで、
ものすごいそれこそ締め切り日前日、前々日、前々前日みたいな感じで何段階にもそのリマインダーを設定、
それは別にタスクとは関係ないカレンダーの領域になるんで。
逆に言えば、タスク管理っていうかアウトライナーの中では割に緩いんですよね。
あんまりシステムとしても、やるべきこととしても、完璧なものを作らないことがむしろ大事じゃないかというふうに言わせます。
これが多分重要な観点だと思うんですよ。
たくさんの最近のチャットの主考のOSという言葉がありますが、
あれが連想するイメージがもしかしたらちょっとロバストすぎるというか、
感じられすぎるし、そういうのを求める人がこういう知見にまず飛びつくわけで、
まあそこは仕方がないんですけども、やっぱ緩いんですよね。
緩いという表現が適切かどうか知りませんけど、
ある種の完全さを諦めた地点っていう管理の仕方っていうのが、
改めてフューチャーされた方がいいんではないかなというのを、
もちろん僕が気楽なフリーランスをやってるから言えることではあるんですけども、
でもやっぱりそういう厳密さが働く人全員に要求される社会ってやっぱりちょっとおかしいですよね。
おかしいですね。
逆に現在って意識して緩くしないと、
緩くならないんですよね。
たぶん普通に人と仕事してて常識的な行いをしようとすると、
必要以上に厳密になっちゃうので、
逆に緩くする仕組みを作るぐらいの方がいいんだと思うんですよね。
僕前も話しましたけど、
仕事になると意外に厳密になるところがあったんで、
それは自分の厳密じゃなさの自覚の裏返しなんですけど、
ちょっとそれを緩めるように。
ただその緩めると本当にザルになるので、
どこまで緩めるのかっていう、
それを仕組みに組み込もうとしてる感じはありますね。
48:04
それがどう成功してるのか、なかなかわかんないですけど。
そうなんです。
一時期は僕もプログラミングとかツール使って、
完璧な1日のレリー・ダス・クリストが自分で作らなくてもできてますっていう
応用っていうのをずっとやってたんですけど、
結局それってやるべきことの量のフレームっていうのが
もう与えられてしまってる状況から始まるんですよね。
で、それ、例えばその日体調が悪くてできないとすると、
なんかすごいできなかった感が生まれるんですけど、
どう考えても平均よりの体調よりも悪い日のダス・クリストは
平均より小さくなってるべきですよね。
それはそうですよね。
だから今はほぼリピートダスクってなくて、
毎日その日に朝やろうと思ったことだけをリストに書くっていうことをしてて、
やり終えたら新しく追記するっていうアペンディッド方式でずっとやってるんですけど、
こうやると基本的にそのダスクのやりすぎっていうのがまずなくなるんですよね。
当然のように。
その代わり、生産性って落ちるんですよ。
でもやっぱりこれでいいっていうふうに思えないのは、
どこか異常になってるなというのを最近感じます。
もしかしたらそれは本当に生産性が落ちてるのかっていうのは
長いスパンのレベルとしてはわからないですよね。
そう執筆文字数は落ちてるとは言えますけど、
どういう側面で測る生産性かによりますよね。
すごい文字数増やしましたけど、全部ツイートみたいなもんでしたっていうのでは、
そのプロダクティビティってなんやねんっていう話になってきますんで。
そうですよね。
逆に、そうやってガチガチにやりすぎた結果として、
体調を崩して3ヶ月なりもできませんでしたっていうと、
平均をとったら結局生産性が下がってる可能性もあるので。
だからザルである自分の最低ライン、
逆にガチガチとやりすぎない、
ガチガチになりすぎない最低ラインで、
たぶん1日に6個や、何か6個に乗るんですよ。
6という数なんですね。
その生産性の高い人から見ればものすごい少ない感じなんですけど、
でもゼロよりは6やる方がいいですね。
間違いなく。
だけどやりすぎないのは、その6を超えたものはやらなくていいっていうことを、
その仕組みとして組み込んじゃってるっていうところですよね。
51:00
あれはたぶんうまく機能してますね、自分では。
僕は全部手入力してるんで、デイリータスクリスト。
もう長くなりようがないですよね、めんどくさいから。
自分にとって主要なことだけをまず書くと。
出筆のプロジェクトは大きなことだけ書いて、
終わったら細かいことを書くって。
だからもう優先順位になってるんですよね、書くことが。
もうだからそれぐらいで抜けても。
僕だから一時期毎日何かをするっていうことが非常に得意やったんですけど、
それって結局テンプレートに耐えたるからなんですよね、これをやるって。
でも今もやるってことを思い出せないと書かないわけですよ。
だからすごく抜けるんですよ。
僕毎日イラストの練習するっていう日課を掲げたんですけど、
見たら前回2週間前でしたね。
2週間丸々空いてた。でも逆に言うと2週間忘れてても思い出せるときもあるんやなっていうのがあって。
1年で60体ぐらいイラスト練習してるんで、毎日って決めてたけど。
でも60回できてるし、いいじゃないかっていうふうに最近は思ってますね。
そうですよね。でもそれはもしかしたら無理して毎日やろうとして挫折してたら、
30回でできなかった可能性もあるわけですよね。
そう、全然あるんでね。だからそこはわからないですけど。
生産性とか習慣化の定着において毎日確実にやるっていうのは力になるんですけど、
でもイラストを毎日やるっていうことの優先順位って僕なかでそれほど高くないはずで、
だって別に僕物書きなわけですから。
だから全部をルーティン化するってしまうと優先順位その頃は見えなくなるというか、
何が重要なのかわからなくなるんですよね。
全部が等しく重要になるか、内緒が全部が等しく価値がなくなるかどっちかというか。
でもそれだから、本来やめてもいいはずのこともやっぱりやっちゃうんですよね。
重要非重要性がなくなってるから。
そういうのはあんまりよろしくないというか、
取捨選択をしてないことによる弊害っていうのが後々起こりそうだなというのを感じてて、
だからタスク管理を完璧にするためには効率的にやる必要があって、
効率的にやるためにそういう繰り返し処理が出てくるんですけど、
それが起こす弊害があるんであれば、
もう生産性っていうのが仮に厳密に測って下がったとしても、
僕はそれでいいんじゃないかなと最近思ってますね。
はい、まさに僕もそう思ってます。
だから、そういう話を最近いろんな人が聞くんで、
そこまで厳密にやってないっていう話をよく聞くんで、
他の人はどうなってるのかなというのを聞いてみたかった時代です。
でも、タスク管理をそこまで厳密にやるよりも、
一つ一つ、それこそ言い方はちんくですけど、
一つ一つの仕事を丁寧にやる方が結果的にはいいんじゃないかなと思うし、
54:02
逆にそれができない環境にいて、
自分によくない影響を与えているとしたら、
なんか考えなきゃいけないということなんじゃないかなと思います。
そういう時に、もっとタスク管理して解決しようっていうのは、
たぶん泥沼ですよね、きっと。
泥沼だし、でも、いわゆるタスク管理の界隈で起こりがちなことですよね。
そこは注意したい。
主法はあくまで主法でしかないっていうことなんですけど、
忘れがちになりますね。
特にシステムとして作っちゃうんで、
そのシステムに対して自分たちが従順になるというか、
従順になることがある種の管理なわけですからね。
そうですね。
タスク管理っていう言い方がやっぱりよくないんじゃないかと思いますね。
これは一大問題というか、一大発議というね。
でも、管理はしている部分はもちろんあるんですけど、
その管理だけで満たされているわけではないというのは確かですね。
そうですね。
だからね、スケジュール管理はあっていいと思うんですね。
スケジュール管理とか締め切り管理は必要じゃないですか。
はい、確かに。
だけど、その間にあるタスク、
直接時間軸に乗らないもの、時間が固定されていないものは管理するっていうイメージじゃないんじゃないかな。
なるほど。
そうですね。
これは別に答えはない問題ですが、
本人でゆるータスク管理、
管理じゃないんだったらゆるータスクなんちゃらみたいな概念がね、
2022年ぐらいのキーワードになるんじゃないかと勝手に予想しておりますが。
それで言うと僕はそのタスク、文章としてタスクを書くという。
はいはいはい。
文章にうまく乗っかるかどうかっていう。
なるほどなるほど。
乗っかるっていうか、その文章として書く気になるかならないかなっていう。
だから、ゆくらひたさんが言う、手動で毎日書くっていうのと多分同じ意味だと思うんですけど。
そういうやり方も一つあるし、
タスク集頭みたいに、
以前やったことは重要であるっていう風に見出すのも、
多分状況によっては多分ありだと思いますよね。
あれは1日24時間以上の作業を絶対に入れられない仕組みになってるんで。
でもその意味ではけうな仕組みですよね。
たぶんアプローチはいろいろあると思うんですけど。
ただ、とにかくシステムとしてタスクをひたすら溜め込んでいくだけの仕組みは回らなくなるっていうのは間違いないと思いますね。
57:08
だから管理じゃないとしたら、やっぱりマネージメントっていう言葉を僕は当てたくなりますが。
難しいですよね。
そういう意味でもいいような気がするんだけど。
マネージメントっていう言葉の元位が一人にして幅があるので、これが難しいですけど。
でももうちょっとマネージメントほど固くなくて、もうちょっと一般を消す、
理事基地に管理するわけでもないし、
かといって自由に生きようみたいなんでもないその間ぐらいの何かが多分、
方法論として提示されたら面白いんじゃないかなという気がしますね。
あとで、GO!さんが、GO!ギターさんがよく使う「安倍する」っていうのもいい言葉ですね。
一日の中に安倍するっていう。
このハッシュはたぶん尽きることがないので、一旦ここまでにしますが、
最近のタスク管理、僕はこうやってるよという、特にその緩くなってるよ情報をいただければ、
#打ち合わせキャストひらがなで打ち合わせアルファベットでキャストまでいただければと思います。
はい。たくさん何かお知らせしたいこととかございますかね。
特にはないです。
はい。じゃあ今回はこれまでにしたいと思います。お疲れさまでした。
お疲れさまでした。
