1. うちあわせCast
  2. 第百八十三回:Tak.さんと文章..
2025-10-30 1:39:24

第百八十三回:Tak.さんと文章エディタについて2

サマリー

今回のエピソードでは、Googleポータルのサービス終了についての悲しみや、インターネットにおけるポータルの意義が議論されます。また、ワークフローリーの新機能やその使い方が具体的に紹介されます。さらに、文章エディタに関する議論が展開され、特にもの書きエディタの機能や改善点についての意見が交わされます。Takさんの考えをもとに、理想的なエディタの要素やユーザーの要望について深く掘り下げられます。Takさんとともに、文章エディタの機能やその進化が探求されます。特にリッチテキストとプレインテキストの扱いや、プロセス型とプロダクト型のアウトライン機能の重要性について議論が展開されます。このエピソードでは、文章エディタにおけるファイル管理の重要性とユーザーの視点から見た機能が検討されます。また、アウトライナーとファイル構造の関係や、作成過程から製品化の過程におけるツールの役割についても議論されます。田舎の文章エディタの機能やファイル管理の重要性について考察が行われ、エディタが吸収すべき知的作業のサポートについて語られます。また、ユーザーのニーズに応じた柔軟なインターフェースの可能性も探られます。文章エディタに関するディスカッションを通じて、情報処理の傾向や視点の違いについて考察されます。リニアな読み方が多い中で、他者との対話が自己認識にどのように影響を与えるのかが探求されます。さらに、生成AIを利用した知的生産の課題や、個別のエディタの重要性についても言及されます。

Googleポータルのサービス終了
スピーカー 1
おだしょー うちあわせCast第百八十三回ということで、今回もゲストにたくさんお迎えしております。よろしくお願いします。
スピーカー 2
おだしょー よろしくお願いします。
スピーカー 1
おだしょー おひさきしかたぶりで、せせんげない話は全く飛ばしまして、悲しいニュースなんですけども、Googleポータルがサービス終了そのお知らせということで、Google関連がいろいろ終わってまして、Googleの実証かな、Googleなんとかやったか忘れましたけど、
Web、インターネットで使える実証サービスもGoogle系のやつが終わったんですけども、Googleポータルも終わるということで、悲しい反面、よくよく考えたらここ数年Googleポータルアクセスしたことがなく。
スピーカー 2
おだしょー ないですね。
おだしょー そもそもポータルサイトって言ってわかんない人も結構いるじゃないですか。
スピーカー 1
おだしょー 今、日本メーカーのWindowsマシンを買ったときに、Yahooのトップが表示されるような何かがあればわかるかもしれない。Yahooのトップはまだちょっとポータル感があるはず。
Yahooのトップはまだ多分ポータル感が、僕最近Yahooを見ないですけど、ちょっとやっぱポータル感ありますね。なんか見たけど今。
Yahoo Japanすら使わない人であれば、ポータルという概念すら多分なくて、トップページってGoogleの検索ウィンドウが上に最初に出ているっていうのがイメージとしてのトップページというような雰囲気の人も多いと思うんですけど。
ポータルサービスが一つ終わるにして、ポータルサービスとは何だったのか。ポータルとは何かというか、インターネットにおけるポータルとは何かっていうのを誰かが振り返ってほしいなと思うんですけど。
スピーカー 2
もうあれですもんね。ポータルっていう概念がワーッと出てきてからもう多分20年以上経ってますよね。多分2000年過ぎあたり。
その後、企業ポータルみたいなのが上がってきて、今ダッシュボード的なものに多分進化していったんだと思うんですけど、そっちでは生き残ってるけれども、一般のインターネットのポータルはやっぱりGoogleの登場によって終止符を打たれたのかな。
スピーカー 1
Yahooニュースは見てるから、使ってるっちゃ使ってるんですよね。
日本人ユーザーはまだYahooのゴリゴリIT好き人間はあんまりYahoo見ないと思いますけど、結構一般の人はまだYahooのトップページとか、基本的にデフォルトで表示される場合も多いので、使われてる方は多いかなと思います。
使われてる方はどうなのかちょっとわからないですけど、Google最初の検索ウィンドウがインターネットの入り口というかインターフェースになっている現在で、OpenAIがAtlasだったかなっていうウェブブラウザーを出しまして、ChatGPTがメインで組み込まれているウェブブラウザーなんですけど、だから最初がChatGPTのチャットウィンドウなんですね。
最初が。検索っていうのもあるんですけど、入り口としてはここに聞いてくださいということになっている。だからGoogle検索の延長線上にChatGPTの使い方が組み込まれている。つまりユーザーインターフェースのデザインそのものはGoogleから進化していないし、ポータルが持ってた役割というようなもの。
ポータルを維持する人的コストが高いのは間違いないんですけども、雑多感というか本屋に行くとか雑誌を読むとかというメディア体験によって得られる、求めてないけども目に入るものというものとの出会いの場という役割は多分あったと思うんですけど、ポータルサイトというのは。
そういうのがほとんどなくなりつつあって、探しているものがあり、答えがあるというこのダイレクトな触通の関係にどんどん修練しているというか、そういう状況になっている中で、果たして適切な情報環境になっていると言えるのかどうかというのは長年の疑問ですね。
スピーカー 2
そこは難しくて、Googleが最初に出てきたときにすごく賞賛され、いろんな人がGoogleを賞賛している中で、誰が言ったのか覚えてないですけど、
やっぱり今よくあるようなポータルサイトというのは、結局ユーザーの当選を限定してしまう。
ポータルのトップページに表示されているものだけがインターネットであるかのように思っている人が多いと。
Googleはそうではないということを教えてくれるんだ、みたいなことを書いてる人がおられましてですね。
だからポータルに対するアンチテーゼみたいなもんだったんですよね、Googleの超シンプルなトップページは。
それから20数年がたぶん経って、倉下さんがさっき言われたみたいに、雑多な、いろんなものが特に見たくないわけでもないのに目に入るあの雑多な感じがなくなって、
ポータルの再評価
スピーカー 2
今直接答えに聞く、今の在り方というのは果たして適切な情報環境なのかという、正反対の見方が出てきているというのが非常に興味深いところで。
でもどっちも必要なような気はするんですけど。
スピーカー 1
もちろんどっちも必要なんですけど、やっぱりその20年前にGoogleを称賛していた人は、おそらくですけどもインテリなわけですよね。
スピーカー 2
でしょうね。
スピーカー 1
結局それは、その人が持っている知識体系とポータルサイトが示す知識体系を比べたときに、自分が持っている方が広いんだと。他にももっと知ってるよと。
Googleを使うためには検索ワードを自分の引き出しの中に持っておく必要があるわけですよね。
そういう人から見たら、ポータルサイトというのは拘束でしかない。制約でしかない。
一方ででも、検索ワードを持たない人間がGoogleの窓に向かったところで、何の情報を引き出せるのかという話なんですね。
スピーカー 2
そうですね。
スピーカー 1
そうしたときにやっぱり入門導入とか、あるいはある専門家が見たときにも、その専門以外の領域というのは初心者とか入門者なわけで、
知識領域の外にある、つまり自分が検索キーワードを持ってない領域というのはいっぱいあるわけで、
そういう観点から考えたときに、拘束的な制約的な構造が最初に示されていることの魅力とか価値っていうのを再確認しないと、
オープンだ、開放だ、自由だが、正義だというのは一方的すぎるなというようなことをここ20年いろいろ経験して学んできたという感じですね。
スピーカー 2
そうですね。今の今日のGoogleの検索結果がそのときにその人が称賛していたものと同じであるとは思えないわけですし、
検索の結果として表示されるリストの順位が自分の思惑とは全く関係ないところでいじられているような状況に比べれば、
かつての拘束的なポータルのほうがよっぽど良かったんじゃないかなという気がしなくもないですけど、
そもそもポータルのトップページって自分でカスタマイズできるのが前提でしたよね。
スピーカー 1
確かにそうですね。
ヤフーの凝ったトップページを作ってた記憶があります。
凝りまくったトップページを作るつもりですね。
そう、ダッシュボードを作ってたんですね、あの頃から。
スピーカー 2
転機用とニュースソースがあって、それと乗り換え案内と。
はいはいはい、やってましたやってました。
多分今そういうことに凝るタイプの人は、当時もそういうことに凝っていたんじゃないかと想像されます。
スピーカー 1
確かに確かに。
選択の自由だから、RSSリーダーで自分のニュースソースを作るのと同じように、
様々なビジュエットとかガジェットを組み合わせることで、
好みのポータルサイトを作るということがあった上でのポータルをやったわけですね。
スピーカー 2
そうですね。
だから、当時よりも多分今一般的に使えるスクリーンの広さというか解像度が全然広いわけですから、
そういういろんなものを配置できるポータルの有効性ってひょっとしたら今のほうが高いのか、
それともそれは例えばMacだったらデスクトップにペタッと貼り付けるあれに、
それに変わってしまうと言えなくもないのかもしれないし。
スピーカー 1
そうですね。
デスクトップにペタッと貼れるものの中にフィードリーダーみたいなものがあれはだいぶ保管はされるでしょうけど、
それがない場合、ただの面白ガジェットにとどまってしまうところはありますね。
そもそもポータルを維持し続ける人的コストという、何を載せて何を載せないのかっていう、
大カテゴリーを作ってサブカテゴリーを考えるっていうこと自体が一つの知的な作業なわけですから、
そんなものはもう割には合わないというのはわかるんですけども、
Gooポータルがなくなるのは別として、僕たちの知的活動においてポータル的なものをちゃんと構築するっていうことの意義っていうのは
確認したいなとは思いますね。
スピーカー 2
そうですね。
ワークフローリーの新機能
スピーカー 2
やっぱりお敷せのサービスとしてじゃなく、それこそ個人の情報との向き合い方の一環として、
それぞれにポータル的なものを作るというのがおそらく健全なあり方であろうかという気はしますけどね。
スピーカー 1
そうですね。
あとワークローリーがいろいろアップデートがあったんですけども、
これは後々増えるんですが、データ日付系の扱いで云々がありまして、
結構これも便利なのがありまして、ムーブトゥのアレンジでムーブトゥデータというのが生まれまして、
日付に飛ばすということですね、簡単に言うと。
一番よく使うのはムーブトゥトゥデイだと思うんですけど、ある項目を今日の日付に飛ばすとか、
ムーブトゥイエスタデイやったら昨日の日付に飛ばす。
日付をピッカーから選んでその日付に飛ばすっていうのも確かあったと思うんですけど、
スラッシュコマンドとかから日付に飛ばせるようになったという話で、
で、前回かな、前回ワークフローリーそのデータの扱い、
デイリー機能の話は前回したと思うんですけど、
で、ちょっとアナウンスをつけたんですが、改善されたということで。
スピーカー 2
改善されましたね。
スピーカー 1
移動するだけでちゃんとその日付の構成に組み込めるということで。
こんなの使わないかなと思ってたんですが、半分使うようになりまして。
今日の項目は普通のデイリーとは別に作ってある、僕の専用のメモっていうところに置いてるんですが、
1日経ったらワークフローリーが作るカレンダー項目に飛ばすようになってまして、
口で説明しても全く分かる、分かる人には分かると思うんですけど、
これまた画面共有しますけども、
メモっていう最上位にある項目の一番上にある今日の日付の項目、
10月30日の項目が僕の今日のメモで、iPhoneとかからメモを送るとここに自動的に送られてくると。
ワークフローリーが自動的に作るのはこのカレンダーという項目でして、
ここに並んでるのが移動できるやつ、こんな感じで移動できるやつで、
僕はここは昨日までしか入ってない、今日のはさっきのトップに入ってますけど、
1日経ったらmove toコマンドでこの10月のところに飛ばすと。実際やってみましょうか。
この項目を選んで、ここでもいいんですけど、
10とか選んだら出てくるんで、
一応ここで移動できるんですね。
あるいはシフトエンターを押すと移動したところに飛べるんで、
シフトエンターを押すと、もう無理か、消えてもうた。消えてもうたら移動できない。
ここにさっき移動したのがここになってきて、ちゃんとこのTodayっていうのが付与されてて、
この10月の1項目としてちゃんと移動できるようになっているんで、
僕は今日の項目はここの一番上に置いておいて、昨日以降は全部、
昨日以前は全部ここに移動させて、こっちでカレンダー項目として使うっていうような感じで使うようになって、
移動しただけでちゃんと項目になってて偉いなというのを感じておるところです。
どうですか、ダックさんは。
スピーカー 2
僕ですね、前回6割ぐらい肯定する肯定的みたいなこと言ったんですけど、
スピーカー 1
前回からたぶん一月弱の間に100%肯定に変わりました。
スピーカー 2
よくなったんですね、ベータ版の時からよくなったので、完全に全面的に全部それを使うようになったので、
Daysという日々の日付を司るアウトラインを作っていたんですが、
このカレンダー、アノアクロニが自動的にカレンダーっていうのを作ってくれるじゃないですか。
それをそのカレンダーの文字をDaysに書き換えまして。
スピーカー 1
そうですね、これ気づかない人はいると思いますけど、これを書き換えても何も問題なく作動するんで、勝手に書き換えてもらって大丈夫です。
スピーカー 2
だからもうDaysを完全にこのワークフローのカレンダー機能をそのものにしてしまいまして。
これがすごいというか、やってみて初めて気がついたんですけど、
このカレンダーボタンみたいなのが表示されるじゃないですか。
これですね。
そうそう、アウトラインの中に表示される方。
これをカレンダーが出てきて選択できるんですけど、この下にカレンダーレイアウトっていうのができるんですね。
これをやると、このレイアウトの中でYear, Month, Weekっていうチェックボックスがあって、
年と月と週っていうのを作るかどうかでWeekをチェックしなければその週っていう括りはなくなるっていうレイアウトを決められるチェックボックスが出てくるんですけど、
カレンダー機能の自動化
スピーカー 2
それをやってApply Changesっていうボタンを押すと、それが反映されるわけですよね。
その時にやってみて初めて気がついたんですけど、過去のWorkflowの日付を付与していた項目が全部この中に自動的に組み込まれたんですね。
スピーカー 1
知らなかった。それは知らなかった。
スピーカー 2
今月から使い始めたつもりだから当然Yearは25からなると思ったら23とかできてて、なんで23があるんだと思ったら過去に作った日付項目が全部その中に。
スピーカー 1
へえ。賢いなあ。
スピーカー 2
あるという。逆にそうしたくなかったらどうするんだという話はあるんですけど。
もう一回移動させ直せってことでしょうね。
確かね、Undoするあれが出てくるんですよ。
なるほど。気に食わへんかったら戻れと。
その直後は戻れるんだと思うんですけど、とにかく過去の日付項目になっていた項目が全部カレンダーの中に自動的に組み込まれてしまったという。
ただね、日付項目にしてない日もあったんで。
それだけは元のアウトラインに残っていて。
日付項目になっていたものだけカレンダーに組み込まれてしまったということになってるんで。
でも過去の日付項目になってないやつを日付項目に変えてやれば、もう一回このアウトラインチェンジ図を押せばまたそれも引っ込み込んでくれるんですよね。
スピーカー 1
ちなみにこれ使ったことがない方はわからないなと思います。画面で出ているのが日付項目ですね。
スピーカー 2
そうです。日付項目。
タイムフォーマットになっているやつですね。
単純なテキストではなくて。
スピーカー 1
日付を打ったら、2025とか13日付っぽいのを打った。スラッシュ入れて。
文章エディタの再考
スピーカー 1
日付っぽいデータを入力すると下のほうに日付にするっていうキーが出てくるんで、タブを押すかクリックしたらタイムフォーマットになって。
日付が自分が選んだフォーマットとして表示されるんですけど、それがタイトルになっている項目をワークフローリーが全体から拾ってきて、こいつはカレンダーだろうだろうと認識してちゃんと集めてくれるってことですね。
そういうことです。
スピーカー 2
偉いなあ、それは偉いわ。
なおかつこのワークフローリーの自動で作ってくれるカレンダー自体がデフォルトでは一番上のルート階層にできちゃうんですけど、好きな場所に移動できるようになったので。
これも確か一番最初できなかったと思うんですよね。
戻っちゃってたんですよね、確か。移動しても。それがどこにでも移動できるようになっていたんで、心置きなく自分のライフアウトラインの中のDaysがあってほしい場所にそれを移動しておけば完全に自分のアウトラインの中ではワークフローリーの日付関連機能が全部使えるという状態になりますので。
いやー便利便利と思いながら使っている。
スピーカー 1
本当にこのカレンダーレイアウトで年、マンス、ウィークをチェックできるというところが偉いですね、これは。
スピーカー 2
だからマンスいらないよっていう人もいるかもしれないし、一番多いのはウィークいらないよっていう人のほうが多いかな。
たぶんそうですね。ウィークは使い方が難しいんで、マンスまた買ったりしますからね。
唯一難点は日付の並び順が下から積んでいくタイプだったのが、上から順相当されてしまうという。
スピーカー 1
やっぱそれがね、普通に相当するとたぶんこの順になるはずなんですね。1,2,3,4,5、たぶんこの順になるはずなんですよ。
僕はこの機能を使ったわけじゃないんで並んでるんですけども。
このタイプでデイリーを使うとやっぱり今日の日付が上に来て欲しいんですよね。
スピーカー 2
欲しいですよね。
スピーカー 1
そこだけはあれなんですが、僕はさっき言ったように今日作ったのはムーブトゥーしてくるんで、ムーブトゥーは上に来るんで日付がギャルチャーになってるんですよ。
だからTodayボタンを押すと、この順番でもここに作られちゃうんですよね。
それがやっぱりちょっとそこだけ、別に難しくないはずなんで、トップに作るかボトムに作るかのオプションだけは欲しいなというところが唯一わがままなとこで。
一応たぶんですけど、やってないですけど相当があるはずなんで。
これ逆にしたら日付逆になりますよね、きっとね。やってないからわからないんですけど、きっと逆になるはず。
スピーカー 2
なるかもしれない。だから結局このWeekを作ってたりするときにまたなってるときに逆にちょっと使いにくくなっちゃうことはあるんですよね。
スピーカー 1
ナビが逆だったら全部並べた後に逆にしたらいいんですけどね。でもやっぱり今日は上に来るべきだと思うんやけどな。
スピーカー 2
だから来てほしいんですけど、ただ一つ言えるのはこの上のツールバーみたいなところにあるカレンダーボタンを押すとポンと今日に飛ぶんで。
まあ上になくても。
スピーカー 1
ズームしたらね。ズームしたらどこにあろうが関係はないといえば関係はないですね。
スピーカー 2
だからまあいいかなと思ってはいますけど、ちょっとそこら辺を選択させてくれるとより素晴らしいなという気はしますね。
スピーカー 1
そうですね。唯一僕は不満点はほんのそこだけで。僕にとって今日の項目は一番ホットなので。
正直ワークロリ全体としても上に来てほしいですね。だからここにある。
スピーカー 2
それ以外のことは何もなくて、普通に作ったらだいたいこの3階層とかの一番下に常になるので、なんかすごい気持ち悪いんですけど。
不思議な感覚で、例えばアナログ手帳作ってたら今日のページって常に真ん中ぐらいなわけですよ、要するに。
スピーカー 1
1日ずつ後ろに行くわけですよね。それで別に何も不満はないんですけど。
ワークロリの場合は上に来ないと気持ち悪いんですね。
スピーカー 2
なんでしょうね。なんででしょうね。
スピーカー 1
逆に普通に上から並べていくよっていう人もいましたね、この前アンケート取ったときには。
スピーカー 2
ルースリープだったら積んでいくタイプの人いると思うんですよね。
確かに。
どうでしょうかね。
慣れといえば慣れてますね。
スピーカー 1
そうでしょうね。今日のデイリーにズームして使うパターンが多い場合はそれでいいと思います。
僕は簡易のメモを場所として使ってるんで、パッと見えてこらないと困るというか。
僕はだいたいメモはこのようにズームじゃなくて合わせて開くことが多いので、
スピーカー 2
そういう使い方の点からこの場所がいいかなという感じですね。
スピーカー 1
とはいえそれ以外はほぼ文句はない感じ。
非常にいいし、プロセス型アウトラインの良さもちゃんと活かしながら、
カレンダー機能に必要なもの揃えてるという感じかな。
あと聞いた話でいうと、テンプレートで添えてほしいみたいな声は聞きましたね。
新しい項目作るときに白紙じゃなくて、自分が設定した項目をあらかじめ入れたもので作って、
要するにその他のツールのよりデイリーノートっぽい感じに寄せてほしいという意見もあって、
それは多分元々テンプレート機能があるので、アップデートでそういうのも増えてくるかもしれない。
使わないけどあってもいいぐらいですね。
というところで本題なんですけども、文章エディターについての第2回目ということで、
理想的なエディタの特徴
スピーカー 1
調べたところ第158回で文章エディターについてという話がありまして。
スピーカー 2
これ最近やってるんですね。
スピーカー 1
でも158だからあれですよ、2024年ですよ。
ちょうど1年前ですね。
これたぶんだからタクさんがノートで書き始めた頃ぐらいだと思いますね、きっと。
何回か会って、これについて話そうみたいな機運やったと思うんですけど。
でもだいぶ連載自体も終了に向かってると思うんですが。
スピーカー 2
そうですね、あと1、2回ですかね。
スピーカー 1
その記事を最近の記事読んで、その想像力云々の話で、
僕自身も文章エディターに関連してもの書きエディターという感じで記事を書いたんで、
改めてその辺の話ができたらなというのが今回のテーマなんですけども。
もの書きエディターの話からさせていただくと、
もの書きエディターというか自分が使いたいエディターなんですけども。
執筆業をしている人間にとってのエディターの最高の形はどんなものかというところで。
スピーカー 2
もの書き用のエディター。
スピーカー 1
そうですね、もの書き業用のエディターということですね。
単純なテキストレベルの操作でいうと、現状のテキストエディターでそんなに大きな不満はないというのが僕の感じで。
やっぱりもう少し上のレベルのエディット、エディティングの機能があってほしいなというのが一つの要望で。
そこがコードエディターの違い、コードエディターの差が一番出てくるところじゃないかなと思うんですけども。
もの書き用で自分が何をしているかというと、ブログ記事の単発記事を書いたりとか、
メルマガの連載記事を書くっていうことと、あと書き下ろしの本を書くと。
まずそれぞれに文章の長さが違うわけですね。
1,000字から2,000字とか、あとは2,000字の記事を5回とか10回とか、あるいは数万字を書き下ろすという単位で。
まずこの全てをフォローしてほしいというのが第一の欲望であり、
しかも例えば単発原稿とか連載原稿で書いたものをその書き下ろしのマテリアルで使うっていう素材の流れみたいなものもちょっと意識してほしいと。
スピーカー 2
わかります。
スピーカー 1
この辺があってほしいのと、それに関連するんですけど、何度も言ってるんですが、
ファイラーがアウトライナーになってないと。
例えばVS Codeは左にファイルエクスプローラーがあるんですけども、あれはソート順でしか並ばないと。
例えばあるファイルを上に置きたい。僕もワークフローでやってるようにメモは上に置きたいみたいなときに置けないんですね。
置くためにはファイルを先頭に00とか付けて、先頭で制御しなければ思い通りにならないし、それは非常に不満が多いわけですけど、
ファイルを扱う場所がまずアウトライン操作ができる。
かつ、わがままを言わせてもらえば、そこに直接メモを書き込めるみたいなものがエディターの内部の機能として備わっていれば、
先ほど言った連載とか本を書き下ろすっていうニーズにも割と応えやすくなるんではないかなという漠然とした思いがあるというところですね。
よくよく考えたら、たくさんはこれから記事を書かれると思うんですけど、
今はたぶん話せないと思うんですが、現時点で何かありますかね。
スピーカー 2
ここまで書いてきた中で、思ったこととか考えが変わったこととか、新しく考えついたことみたいな。
そうですね。最初からあんまり変わってなくて、機能の話はたぶんしてもあまり意味がなくはないんですけど、
この機能が欲しいよというよりも、どういう思想を持っているかという話をしたいなと思っていて。
どんな想像力というより何を期待するのかという意味。
エディターとして何を期待するのかという意味なんですけど、
どんな想像力に基づいたエディターがいいのかということをまず言葉にしたいんですけど、その言葉がなかなか思いつかない。
ただ一言で言うと明確で、プロセス型アウトライナーとプロダクト型アウトライナーの機能を両方持っている。
なるほど。
そのシームレスに使えるということなんですよ。
そこでいろんな機能が付加されていくということで、
何の想像力って言っていいのかなかなかまだ思いつかないんですけど、
書くためのアウトラインプロセッシングという、セルフファブリッシングで出版した電子書籍があるんですけども、
あれをするためのものですよね。
あれは結構、途中でアウトライナーを使い分けたりして、
アウトラインを新しく作り直すみたいなことをコツとして提示してるんですけども、
スピーカー 1
そういうアクロバティックなことをやらないで、すんなりそれができるようなものですよね、電子としては。
なるほど。
例えばある人が前半部分をワークフローリでやって、後半をワードを使ってやってたときに、
一つのソフトウェアでその全体のプロセスは補えるようなものということですか。
スピーカー 2
そうです。
スピーカー 1
なるほど。
スピーカー 2
ほとんどそれだけなんですよ。
でもそれは何かというと、要するにある程度まとまった長い文章を書くためのエディターっていうときに、
要するに何をするかというと、ランダムな発想を直線的な、リニアな語りとしての文章に変換していくための機能なんですね、それは。
はい。
で、なおかつフルデジタルではなくて、読みながら、
結局何度も読みながら書き込みをするという、そこだけは非常にアナログなので。
はい。
何度も読むというのを画面上でできるということですね。
それはプレビューじゃダメなんですよ。
マークダウンで書いて右側にPDFなりのプレビューをするということで大体できるじゃないかという人が多いんですけど、僕それ違うと思うんですよね。
プレビューをしたらプレビューを編集したいですね。
なるほど。
文章エディタの基本概念
スピーカー 2
でもなんでかっていうと、イニシエのウィジウィグという、画面に表示されるものと印刷されるものが全く同じであるという、今となっては古い考えのように思われますけど、僕はそれがすごく大事だと思っていて。
スピーカー 1
ただしそれをワードみたいに最初からそれが表示されちゃうとダメなんですね。
スピーカー 2
だけど最終段階の何度も読み返しながら修正を入れていくという段階では読みやすいことがすごく大事なタイプであって。
スピーカー 1
確かに。
スピーカー 2
なおかつ読みながら気がついたところをその場で手を入れたい。その時に、わかんないですけど、例えばラテフみたいなものを使ってたとしたら、手を入れるのは別の画面であって、
コンパイルしないといけなかったりするわけですよね。そうじゃなくて、読みながらここって思ったところはその場で直したいと。
そういう段階ごとに必要な機能が変わってくる。
スピーカー 1
だからそこのアウトラインにしても画面表示にしてもその段階ごとに必要なものが変わってくるということを反映されていてほしいということを書くつもりです。
まずその単純な疑問として、例えばですけど、序盤の段階、中盤の段階、後半の段階といろいろあると思うんですけども、当然それぞれのプロセスのタイミングによって必要とされる機能というのは多少異なってくると思うんですが、
それをどうメニューとかコマンドに組み込むかという話で、つまり初期状態ですべてのプロセスに対応したらメニューとかコマンドがあるのか、例えばツール上で次のプロセスに行くぞボタンを押すとUIそのものを含めて変わっていくようなイメージなのか、その辺あります?
スピーカー 2
前者ですね。切り替わっていくんじゃない。ただしそんなに僕必要ないと思うんですよね、機能が。アウトライナーの機能というのはもう限られているので、要は後半のプロダクト型アウトライナーの機能として必要なのはワードの機能ですよ。
ワードのどうでもいい余計な機能を省いた。ベアボーンなワードの機能ですね。要はプロダクト型のアウトライン機能プラススタイル。身だしごとにスタイルを定義できるというその機能だけがあればいいという。
スピーカー 1
おだしょー スタイルはどう文章で定義しましょうか。リッチテキストなんですかね。それともプレーンテキストをマークダウン的にする。
おだしょー リッチテキストをマークダウン的にするけど、背後はリッチテキストで保存するということですかね。また細かい話してますけど。
スピーカー 2
おだしょー だからその意味ではスクリブナーがやってることと同じですよ。リッチテキストの特定の書籍を表示してるだけっていう。そんなにそこを多分難しく考えなくてもいいんじゃないかなと。
おだしょー それは開発者ではないんで、難しいか難しくないかわからないですけど、あくまでもコンセプトを考えたいので。
スピーカー 1
おだしょー そうですね。実装をどうするかはつい考えてしまうんですが。リッチテキスト型でいくと、テキストファイルでは保存できないということになってしまうんで。あるいは別側にリッチテキストの情報を持たすかかな。
スピーカー 2
おだしょー プレインテキストであってほしいみたいのはあんまりないですか。
おだしょー そこが文章エディターはテキストエディターではない。
スピーカー 1
おだしょー なるほどね。確かにリッチテキストは文章ならではの機能ですもんね。
スピーカー 2
おだしょー そうなんですよ。そこは多分人によって考えが違っていて、全てプレインテキストであってほしいという思想は非常に完全に理解できますし、その考え方はあって当然だと思うんですけど、それではない。
おだしょー ただもちろん例えばワードだったら基本リッチテキストっていうか、ワードそのものはXMLなんですよね。今のワードの形式自体は。
おだしょー だからそのワード自体はそれをその形式で扱っているけれども別にそれをプレインテキストで保存することはできるんで、プレインテキストが必要だったら当然プレインテキストの形で吐き出すということは別に難しくはないと思うんです。
おだしょー ただ他のものとの行き来の時に、例えば見出し構造を当然、後半のプロダクトサイドに入れば見出し構造を持っているはずなので、見出しのレベル1、2、3、4ってある。
その見出しを例えばマークダウンなりHTMLなりに変換して出力するということはできてほしいですよね。
おだしょー それができれば他のものに簡単に持っていけるわけなので、なんでいまだにワードが例えばマークダウンに対応してくれないのかっていうのはやっぱり、それいろいろ理由はあるんでしょうけど。
だって見出し構造を持ってるわけだから、別にそれに単に記号を付けて保存すればいいわけなんですけど。
たぶんコパイロットさんに、それやりたいんだけどと言えばたぶんやり方を教えて、VBAでこうやってできるよって言ってくれると思うんですけど。
エディター自体はプレインテキストではないと考えたいなという気が。
スピーカー 1
そこはやっぱりだいぶ発見でしたね。僕の中ではもうプレインテキストからしか想像が始まってなかったので。
スピーカー 2
プレインテキストにしてしまうと、結局エディターとプレビューが別になってしまうわけですよね。
そうですね、基本的には。
スピーカー 1
それをいかに避けるか。
僕は逆にプレビューが別であってもいいかないしは別であってほしいぐらいの感じがあるのかな。
スピーカー 2
そこが目白に思想の違いですね。
スピーカー 1
そうですね。
一つのツール内でシームレスに動いていく便利さと、ツールを動かすことのメリットというか、別のツールに移動させる効能みたいなのもあって。
スピーカー 2
ありますね。
スピーカー 1
どういう効果か。もちろん一つのツール上でも起こせると思うんですけど。
現状、左にアウトワークフローリーで右にテキストエディターで文章を左を見ながら右で書くっていうことをやってるわけですが。
それでやっぱり意味があるので。
それまでと同じ延長線上で、プレビューも別の媒体であって、あるいは僕の中で別の媒体になっている。
想像力がそうなっているということか。
確かにプレビューをそのものを直接書くという欲望に応えるためにはリッチテキストでなければならないというのは確かですね、それは。
スピーカー 2
逆に僕はプレビューだけは別であってほしくないんですよ。
そうか。なるほど。
疲れるんですよね。
読んでいて、ここを直したいといったときに、違う形をしたものからそこを視覚的にプレビューで直したかったのは、このエディターでいうとここだなっていうのを頭の中で認識し直して、
このプレビューで直したかったように直すにはこうだなって。
文字を数文字書き換えるぐらいならまだいいんですけど、開業とか見出しをいじりたいとなったときに、
エディターの中で開業する、見出しはこのマグナムのホラーを書き換えるとか、
特に最終段階で読者の目で読んでいるつもりのときにそれをやりたくないというか。
僕がその非常にワードを好んで使う最大の理由はそれで、紙のように見える画面で読みながら直すときに、
ちょっと文字数文字直すのはそのまま直すけれども、これちょっと見出しの階層を変えたいとか、この見出しを動かしたいっていうときに、そのままアウトラインモードに切り替えられるわけです。
なるほどなるほど。
それに慣れてしまうと、他のやり方ができないっていうよりも、プレビューというのがものすごくまだろしく感じる。
それは間違いないと思います。確かに。
中間段階ぐらいなら大丈夫なんですけど、本当に死ぬほど読む段階みたいなところでプレビューになるとつらいというか。
探さなきゃいけないのがつらいのね、エディターの中で。
確かに。
それをでも、くもなくできる人であれば、多分それはあまり関係ないというか。
逆当然やっぱりプレビューを別にするメリットってあるので。
スピーカー 1
そうですね。僕の場合はだから、読み返すときは読み返すモードになってて、直すときは直すモードになってるんで、きっと。作業が完全に分断してるというか、印をつけてということが多いので。
スピーカー 2
それ印をつけるっていうのは、プレビュー上で。
スピーカー 1
PDF上でとか、そういうことですよね。
スピーカー 2
だから僕、書き込み方がちょっとおかしいのかな。
おかしいことはないと思いますけど。
そうなんですよね。僕はPDFに書き込むっていうことはほとんどやらないんで、紙のプリントアウトにペンで書き込むんですよね。
だから紙と同じ状態で画面に放り、それを反映するときは、紙と同じ状態で画面に反映されててほしいっていうのもあって。
それはある種古いやり方だと思うんですけど。
読み直していると必ず直したくなるじゃないですか。
だからそれをその場で直せない。そのままの状態。直したいと思ったまさにそこを怒ってて直せないっていうのがすごくダメなんですよね。
ただそこは個人的な傾向の問題かもしれないですけど。
大きくはプロセス型からプロダクト型への2種類のアウトライン機能をシームレスに持っているということを一番。
スピーカー 1
簡単に言うとワードが通常の文章モードとアウトラインモードがあるのに加えて、プロセス型のアウトラインモードもあれば完璧ということですね。
プロジェクト管理の視点
スピーカー 2
そうですね。だからワードを基準にすると多分それ実現できないんですけど、プロダクト側の機能はワードを参考にできる。
プロセス側はワークフロイとかナイナリストの機能ですよね。ほとんど全部言っちゃってますけど。
その動機をどうやって実現するのかということを示してくれたものがあるわけですよ。
あったじゃないですか。
スピーカー 1
何でしょう。
カカオが。
なるほど。ありましたね。
スピーカー 2
カカオこそがユイ、他にないと思うんですよね。非常に革命的なことをやっていたと思うんで。
確かに。
その方法を参考にしたいというか、僕は作るわけじゃないですけど。
スピーカー 1
それができるという気持ちにさせてくれたのはカカオでしたね。
ちなみに最終制画物が縦書きのことも想定すると縦書きにはなってほしいですかね。
スピーカー 2
いや、だからそれはもうこいつの機能の話なんで。
あればもちろん。
わかりますわかります。
コンセプトとしては、もちろんあれはいいですよね。
実装されるとしたらあれはあれば。
縦書きのアウトラインモードってどうなのかなと思って。
スピーカー 1
でも縦書きのまんまアウトラインにすればいいんじゃないですかね。
プロセスワークフローリーを縦型にしたらどうなるのかな。
スピーカー 2
だからそこはあれですよね。
スピーカー 1
縦書きはもしかしたらアウトライン状態は横書きだけでもいいかもしれないですね。
スピーカー 2
ワードがそうであるように。
プロセスワークフローリーは縦型にしづらそうだなと思って。
ハゴロウも縦でアウトラインに表示できるんですよね。
スピーカー 1
ただあんまり縦の状態でっていうのはどうもあんまりアウトラインにそぐわない感じがしますよね。
ゼロからというか仕事を最初始めるときはプロセス型ビューというかモードというかから始まるかなと思うんですけど、
スピーカー 2
そこは普通のアウトライナーっぽい感じかな、UIとしては。
そうですよね。完全に普通のアウトライナーでいいんじゃないかと思うんですよね、そこは。出だしは。
一応このまた細かい話ですけど、ファイルはプロジェクトごとに分かれてるほうがいいんですかね。
そこがね、だからファイルをまたがって扱う要はプロジェクト管理的なもしくはID的な機能まで求めるかどうかというのは難しいところですよね。
これが例えば書き下ろしするときにさっき言ったように、自分が連載した原稿を本の書き下ろしに使うみたいなことを仮にシームレスにやりたかったらプロジェクトは越境してほしいわけなんですよ。
スピーカー 1
しかしそうするとすごい巨大なライブラリーができなくなるんですよね。
スピーカー 2
そこはどうでしょうね。そこを文章エディターの機能とするのかどうか。
スピーカー 1
これは物書きエディターとしてどうなってほしいかの話近いですけど、スクリブナーにしろワードにしろ基本的にはプロジェクト単位でファイルを作ることが前提にはなってますし、そうした方が都合は良いかな。
つまりプロジェクトごとでスタイルがそもそも違うはずですから、求められるスタイルというのか。
スタイルを適用するのを変えようと思ったプロジェクト、ファイルを変えたほうが早いというのはあると思うんですけどね。
スピーカー 2
そうですね。基本的にイメージとしてはローカルにファイルを保存するイメージですけど、
例えば仮に連載プロジェクトとして扱うとすると、その連載の中でのスタイルは多分共通のはずじゃないですか。
プロジェクト管理、ファイル管理をするとしても、僕それ左側のペインにファイルが表示されてるっていうのがあんまりイメージできなくて、
それだったらアウトラインにそれも組み込んじゃいたいというか、
プロダクト型のアウトラインの、例えば第一階層、一番上の階層がファイルの境目になると。
基本的にはそれが例えばタイトルになるわけですよ。リュードというか、位置付けとしてはタイトルになって、
ファイル管理の意義
スピーカー 2
タイトルとなる第一階層を作って保存すればそれがファイルとして、この範囲がファイルとして保存されると。
だからファイル管理はされてるんだけれども、あまりファイルを操作している意識は取らなくていい。
基本的に第一階層が一ファイルに相当するというようなイメージにできないかなと思うんですけど、
スピーカー 1
じゃあそれを第一階層を第二階層に落としちゃったらどうなるんだ、みたいなことを考えると意外に簡単ではないなと。
仮想な話を続けますけど、例えば第一階層でABCDというのが仮に並んでいたとしますよね。
その場合、ABCA.○○B.○○というファイルがあるということですね。今の感じでいうと。
AをBの下にドラッグしたと。それを下位の階層に移したと。
Aはファイルではなくなるわけですから、Bのファイルの中身になるわけですね。
スピーカー 2
だからAというファイルをBのファイルの中に移して、Aというファイルを削除したらいいわけですね、要するに。
スピーカー 1
ファイルをマージして元々のファイルを消せば、アウトライン上で操作したそのものをファイルに反映させることもできるので、
一応可能ですね。ファイル機能とアウトライン機能を、ユーザーからはただアウトラインを操作しているようにしか見えないけど、実はファイル操作をしているということは全然できそうですし、
多分僕がイメージしていた感じのエディターに近いですね、それは。
スピーカー 2
だから難しいのは、どうやって実装が可能かどうかを考え始めた時点で、もう物書き視点ではなくなってしまうので。
これは難しいですよねっていうのはとりあえず置いといて、願望だけ。ただその願望だけっていうときに、あれもできるこれもできる超スーパーエディターっていうのを言ってもあんまり意味がないとは思うんですよね。
だから今の話はファイル管理という部分を文章エディターに組み込むとしたら、そういうふうにできる。
要するにファイルっていうのは文章、コンピューターに保存するファイルっていうのは文章からの発想ではないわけですね。
そうですね。そりゃそうです。間違いなくそうですね。
それをもしファイル管理的な機能を文章エディターに組み込むとしたときに、物書き視点からはどう見えるのかなっていう。
だから物書き視点の役割のいくつかのうち、特にセルフパブリッシャーぐらいの役割を考えたときに、ファイル管理を考えなきゃいけないわけですね。
スピーカー 1
ePub作るとかそういうことを考えるときに、ファイル単位でまとまってほしいという要望があって、
ユーザー視点からの機能
スピーカー 2
要するにライターの中にあるエディター成分がそれはどうなってるのかと囁きかけるわけですね。
もう一つは文章エディターの連載で書いたときに、今物書き視点って言いましたけど、
逆に物書きの想像力の範囲だけで考えて、コンピューターでできることを限定しちゃうっていうのも良くないわけですよね。
スピーカー 1
そうなっちゃってますけどね。しかも僕はさらに開発者視点も半分入ってるから。
スピーカー 2
想像力の幅がベンズ的に狭まってますね、きっと。
そう、だから、結局プロセスからプロダクトへっていう、発想から文章へっていうことなんですけど、
それは結局アナログでは実はできなかったんですね。
うん、確かに。
そこをシームレスに変換していくということはアナログではできなかった。
要するにアウトライナーがあって初めてできることなんですけど、
じゃあワークフローイだけでできるかっていうと多分かなり厳しいし、
Wordだけでできるかっていうと多分ガチガチの機能で発想を扱えるかっていうとちょっと難しい。
だから2つ使うわけですけど。
本来だったらそれはアウトライナーの特性ということをちゃんと踏まえれば多分統合できるはずだという思いがありまして、
おそらくそれは開発者視点でもそんなにとんでもなく難しいことではないのではないかなと想像してますけど、
ただそれはちょっと僕は開発者じゃないので。
スピーカー 1
可能か不可能かで言うと可能なことが多いでしょうけど、かなりめんどくさいことが発生するでしょうし、
プログラマーはめんどくさいことが嫌いなので避けられるということはあるでしょうけど、
一旦自分がコードを書く人間で起こしてしまう制約っていうのを一切無視して考えると、
まず自分のメモがアウトライナー上に全て集まる場所があると。
物書きエディターとして求めているものですよね。
そのスタート地点としてまずメモが全て集まっていると。
しかもそれはアウトライン上になっていると。
それを操作することができるけど、操作しても大元は残っている。
自分の着想のログはそのままの形で残っている。
それを何かプロダクトに使う、文章に使うときに、コピーというか副写というか、
ものが操作の対象になる。
そのときにだから、おそらくアウトラインがギット的に分岐するみたいな感じなのかもしれませんけど、
もう一個操作対象として生まれる。
そっちをどんだけ操作しても元のアウトラインは崩れない。
そのアウトライン操作がプロセス型から、僕の中で言うとボタンを押すことでプロダクト型に変わる。
それはもう戻れないみたいな。
スピーカー 2
いや、戻れます。
スピーカー 1
僕のイメージで言うと戻せないようにする。
戻せないようにする。
元々は残ってるんですよ。
だからボタンを押してもそのファイルは残ってるんですけど、
スピーカー 2
その操作のモードとしては次に行っちゃう。
スピーカー 1
お前はもうこのプロダクト型でやるしかないという風にツールが制約をかけてきて前に進むっていう。
それぞれのスナップショットは全部残ってるんですけども、
僕が感じているとステージが一個前に進んで、基本戻れないようなエディターのイメージがありますね。
とても自分では作れる気しませんけど。
スピーカー 2
そうですよね。
僕の個人的な感覚で言うと段階を切り替えるというのは違うかもしれないというよりも、
プロダクト型のアウトラインに移行した段階で段階は変わってるわけですよね。
そうですよね、きっと。
今倉瀬さんが言ったので思ったというか気づいたのは、ログを残すということをどう考えるか。
残すべきなのか。
日々のバックアップは当然ありますよね。
だから単純なバックアップで戻れればいいんじゃないかなという気がする。
ログを残すとか言うとどんどん複雑になりそうな気がするんですけれども。
あとGitのツリーがブランチを切れるみたいなことを考え始めると、
それってエンジニア発想じゃないかなと思うんですよね。
これは僕がずっと既存のツールを使ってたときに感じてる不満なんですね。
スピーカー 1
分かるでしょ。
操作したいけど操作したくないという2つの思いがあって。
スピーカー 2
要は一度チェックインしちゃったものはロックできるようなイメージですかね。
そうですね、ロックしてスナップショットが残るようなイメージ。
スピーカー 1
でも操作はしたいのでっていうわがままさがあるわけですね。
だからワークロールで言うとある日気づけにあることを思いついたっていうのをそこに置いておきたいけど、
それを組み合わせて別のこともしたいということがあって、
スピーカー 2
そういうことを操作しつつ残るということを何とかして実現してほしいという感じですね。
そうか、逆にむしろGit的というかソースコードのバージョン管理的なものをどう取り入れるのかっていうのは、
もしかすると飛躍のあり方として考えられるかもしれないですよね。
僕が例として連載であげたGrepとかOutlineなどは、
エンジニア発想が文章リターの飛躍になったという話なんですけど、
バージョン管理もそれに相当し得るんじゃないかという気もしますよね。
スピーカー 1
なんか全然違う形で過去原稿を使うということはあるでしょうね。
基本的に書き手は一次に言ったら前の原稿はほぼ無視する形で最新版を扱うわけですけど、
バージョン的なものがあれば違う書き方とかも生まれてくるやもしれないですね。
イメージはできない。僕もどっちかというと、基本的にスナップショットを残したいって言ってますけど、
エディタの未来像
スピーカー 1
残すだけで別に何かしたいわけじゃなくて、残っといてほしいっていうだけの話なんですけど、
新しい書き方もそこから生まれてくるかもしれませんけど。
僕の場合、ビューの切り替えでいうと、自分の着想が時系列で残っているビューと、
着想があるカテゴリーとかテーマで集まっているビューというふうに、
いろんな見え方をしてほしいかな。
スピーカー 2
そこから何か書くことが生まれてくると信じたい。
どこまでを文章エディターの機能と考えるかにもよりますが、
ちょっとそれを置いておくと、それはもの書きにとっての飛躍になり得る機能かもしれないですね。
スピーカー 1
文章エディターとは何かというと、文章を書くことは何かという話になるわけですけど、
やっぱりイメージ、一般の人がイページするのって、白紙のエディターを立ち上げて、
一文字目から書き始めますなわけですけど、文章を書くという行為は、
そんなに独立したものではないわけですよ、基本的には。
日々の考えたこと、思えたこととかがそこで流れていて、
そこからの何かで文章というのが立ち上がってくるというイメージしたときに、
少なくとも執筆業としてのもの書きエディターは、そこを流れる部分も抑えておくか、
スピーカー 2
少なくとも原稿を書く作業と何の中の形でつながっていてほしいという思いがありますね。
そうですね。
スピーカー 1
ワークローリーがやっぱり僕の中で絶大的だった。
メモを書いてたのに文章になっちゃってる感がやっぱり一番すごいなと思うので、
そこをかな、僕はどっちかというとメモから文章のつながりのほうが重要で、
文章の途中からプロダクトのほうは別にそんなに重視してないということが今わかりました。
メモから文章というのが逆にプロセス部分が使われる部分だと思うんですけど。
スピーカー 2
そこがプロジェクトに限定されないのが僕の場合は重要ですね。
スピーカー 1
そこはだから影響的になってほしいわけです。
スピーカー 2
後半に行くとそこは別にプロジェクトで切れていいかということで、
スピーカー 1
僕がファイルを切り捨てるのは多分そこですね。
データはどうなってるんやろってなっちゃうわけですね。
最初は一番総合の入り口があって、
あらゆるメモみたいなものが集まってて、
ここから文章というのがニョキッと生まれてくるってなったときに、
だからさっき言ったように、やっぱりタクさんが言われたように、
アウトライン上で操作してるだけやけど、
スピーカー 2
知らん間にファイルがニョキッと生まれてるっていうのが多分一番感じがいいはずですけどね。
僕のイメージだと、プロセスの第一階層の見出しができた時点で、
そこにファイルが、それイコールファイルになるイメージなんですけど、
ただ今気がついたのは、
ファイルのアウトラインの途中でその見出しを立ててしまうと、
その後が全部ファイルの中身になっちゃうので、
スピーカー 1
うーん、なかなか済んだりいかないかもしれないですね。
具体的に考えてみないとわからないことがいっぱいありますね。
そうですね。ファイルというか、フォルダーファイルという階層構造と、
アウトラインという階層構造は相似なので、扱える対象が違うだけで、
スピーカー 2
それは普通にくっつくはずなんですけど、
スピーカー 1
ファイルを考えなければ早いんですか?
スピーカー 2
いやそう、だから僕ね、ファイルを考えないイメージなんですよ。
ただ、ファイルを考える必要、
この一連の話を広げていくと当然ファイルを考えなきゃいけなくなりますよね。
いや、どうなの?
例えば、僕だからローカルでファイルを保存するイメージで考えてたんですけど、
例えばワークフローにファイルという概念がないですよね。
あのワークフローのイメージの中で全部考えたらどうなの?
スピーカー 1
いけると思います。この前までは思いつかなかったですけど、
今回のカレンダー機能を見て思いつきましたが、
ある項目にズームしたら、そこの中のはプロダクトと接するというようなことが可能だと思います。
スピーカー 2
そうですよね。
スピーカー 1
だから、自分の中で印を付けて、これはプロダクトだって印を付けておいて、
そこにズームしたら、あたかもプロダクト型のように動くというようなことはおそらく可能で、
しかもワークフローってバレット以外にモードがある、レイアウトがあるじゃないですか。
あんな感じで今している作業に合わせたUIに変えるということもおそらくできるでしょうし、
この場合ファイルはだから一番最後にファイルとして出力するというボタンさえあればいいということになりますね。
そうですね。
スピーカー 2
印を付けたら、これはファイルだよっていう印を付けたら初めてファイルを作るとかでもいいですけど。
それじゃないですかね。
スピーカー 1
それならありそうですね。
エディタとファイル管理
スピーカー 2
そのときに第一項目をファイル名としたMDを作るということは全然いけそうですね。
そうですね。
スピーカー 2
クライセンさんが言ってたみたいに、無数にあるファイルって言いましたっけ?
スピーカー 1
そんなにいかがかしなかったな。
スピーカー 2
思いつきの全体ってことですか?
スピーカー 1
それは複数のファイルに散らばってるっていうことですか?
だからね、基本的に一つのファイルであってほしいし、思いつき自体は。
思いつき自体がバラバラであってもいいんですけど、一覧はされてほしいわけですね。
一覧するのに一番簡単なのが一つのファイルに集めることなんですけど、
ファイルのタイトルと中身が一列で表示されるんであれば、ファイルでばらけててもいいですけど、
現状例えばMacのファインダーの場合って、タイトルの一覧はできますけど、
中身は開かないと見えないので、一覧したことにはならないので、
トグル的なものをやりたかったら一つのファイルに集めるしかない。
現状の装備では一つのファイルに集めるしかないですね、基本的には。
複数プロジェクトの管理
スピーカー 2
バイクを拡張すると似たことができるかもしれませんけどね。
スピーカー 1
リンクと拡張機能を自分で書くとかすれば。
スピーカー 2
最初はプロダクト型で、機能を拡張することでプロダクト的なこともできるよというようなことは一応想像ではできそうですけどね。
一般はあんまりそういうことは考えずに、こういう、さっきほとんどしゃべっちゃいましたけど、
こういうコンセプトのものということを示した上で、
でもファイルはどうするのかとか、ファイル管理どうするのか。
一旦ファイル管理は切り離したいです。
というか、機能から考えることはしたくないんで。
はい、わかります。
ただ、必要ですよね、それはね。必要ですよね。
必ずそこにぶつかりますよね。
スピーカー 1
実装の段階ではぶつかることです。
要するに、ソウルトゥールが何を支えるのかをまず大きく示したいということですね。
スピーカー 2
そうですね。
でも2つ目に1つしかないかな。
それこそ、ワードみたいに個別のファイルがある。
その中にその機能が、1つのファイルの中で全て使えて、
ファイルで分断されるというイメージか、
ワークフローイみたいにもう完全にファイルという概念を取っ払って、
さっきこら下さん言ったみたいなやり方をするか。
あと、Ulyssesみたいな。
あれをやると結局、左ペインにファイルが表示されることになるんですよね。
スピーカー 1
まあそれでもいいのかな。
Ulyssesは左を動かせますからね、自分で握り。
スピーカー 2
だからファイラーというよりもアウトライン的ではありますけど。
スピーカー 1
ファイラーをどう考えるかと。
僕もどちらかというと沢山派で、そもそもエクスプローラーなんていらなくて、
ファイルを扱えるラインがエディット上にあれば事足りるだろう派なんですけども。
それはもしかしたらあまり一般的ではない可能性もあるんですけども。
気持ち悪いということはあるでしょうけどね、その場合。
でもどうなのかな。
使ってて思うのはやっぱりアウトライン上でファイル的なものにアクセスできるような環境の方が使い勝手はいいとは思うんですけど、
直接テキストを書けるのでファイル以外のものも並べられるという点で自由度は大きいんですが、
自由度が大きいのは良いことかという問題も別途あって。
でもあそこは知的操作の場所ではないですよね、当然のように。
最近Obsidianで久しぶりにサイドバーを開いて使ってるんですけど、
あれはもうナビゲーションというただそれだけの役割で。
ナビゲーション自体が悪ではないんですけど、
ナビゲーションをしたからと言って知的操作してやるわけではないという割り切りは必要でしょうね。
スピーカー 2
そうですね。
一つ、ある程度まとまった文章を書くための文章エディターの機能ということで考えると、
たぶん1ファイルで済むんですけど、
それこそもの書きのエディターっていうことで言うと、
その連載をサポートする機能とかっていう意味でファイル管理とか、
あと複数のプロジェクトを扱う。
それはいろいろ当然出てきて。
筆筆する、文章を書き続ける日々をサポートしてほしいってことになりますからね。
これやっぱりあれじゃないですかね。
スピーカー 1
それぞれ考えて対比したいですね。
結構違うんじゃないですか。
話してみて、焦点を当てるところがだいぶ違うなというのはわかりましたね。
スピーカー 2
違いますよね。
別にどっちが正解っていうことではないんですけど。
スピーカー 1
本人の知的作業の癖というか、フォーカスしてるところによって、
当然サポートしてほしい場所も違うんだなってことなんですけど。
スピーカー 2
もちろんクライセンスの方がよりプロの物書きなので、
やっぱりその必要性っていうのは当然感じますよね。
より多くの違うものっていうことと、
多くのネタの中から抽出して、
しかも抽出したのが一つじゃなくて複数のプロジェクトにまたがうっていうこともありで、
書籍みたいな長いものもあれば短髪のブログみたいな短いものも、
あとはメルマガ、メルマガはそのメルガマ、メルガマじゃない。
一本の記事はそれなりの分量があるけど、
その中に個別の記事がいくつかあるわけだから、
それぞれは別々に書かれてるわけですよね、たぶん。
まあそういうものを扱える機能って考えだすと、
かなり違うものになってくる。
エディターの範疇を続けていきますよね。
スピーカー 1
エディターというよりも、
個人ライブラリーを扱うようなものに必然的に近づいていくというか、
まずメモからテキストを起こすっていうときと、
テキストを書いたものをその次の本に生かすっていう、
この一つの大きなエコシステムを扱えないと困るというか、
扱えるツールがあったら嬉しいなあか。
先ほど挙げていただいた僕の活動において、
やっぱり担当してるツールが全部違うんですね。
スピーカー 2
違う、そうですよね。
スピーカー 1
それは別にいいんですけど、いろんなツール使うの好きやからいいんですけど、
もし理想的なものを仮想するなら、
俺が全部やってやるよっていうツールがどーんってあって、
ユーザーのニーズとインターフェース
スピーカー 1
そこにアクセスしたら僕の執筆活動のすべてがあるみたいなものが、
理想のもの書きエディターってことになるんですけどね。
スピーカー 2
だから倉須さんが言ってるのは、
エディターももちろん、エディターの要素ももちろんあるけれども、
プロジェクト管理でさえないかもしれないですね。
もっとレイヤーが上ですよね。
もう一個上ですよね。
スピーカー 1
これもの書きの仕事全体で、ワークマネジメントですね。
スピーカー 2
そうですよね、ワークマネジメントですよね。
スクリブナーがIDEをイメージして作られた、
統合開発環境をイメージした、
だからなんとなくXコードにギターが感じになってるのはそのせいなんらしいんですけど、
でもあれって結局一つのプロジェクトじゃないですか。
あの中で複数のプロジェクトを突っ込むことはできますけど、
スピーカー 1
あのレイヤーじゃなくて、もう一つ上の仕事全体を扱うものがあればもっといいんですけどね。
それはもの書きエディターというか、それがないんですね、そういうツールが。
スピーカー 2
ないですね。そういう名前では多分表現できないものですよね。
仕事環境じゃないですか、それ。
スピーカー 1
ワークスペース?チャッチー言葉になったけど。
そうですね、そういうもの。
でも例えばワークフローリーだって作業空間として使ってるって話はよく聞きますけど、
もしスクリブナーがワークフローリーしかないって、
スピーカー 2
で、あなたの仕事環境を補佐するのをどっち選ぶかって言ったらワークフローリーになるわけですよ、これは。
スピーカー 1
ワークフローリーのプロダクタ型の弱さを何とか補うことでフォローできますけど、
スピーカー 2
スクリブナーは仕事全体を扱うにはあまりにも重たいので。
スピーカー 1
この3日間かけてワークフローリー整理したんですけど、
6600項目ぐらい消したんですよ。
逆に言うと6600項目ぐらい入ってたんですよ。
スピーカー 2
おかしいそれ。
スピーカー 1
全然気づかんぐらいスムーズに動くんですね、こいつ。
結局全部開かないからなんですけど、
でもそれができるってこいつの懐の広さというか、
スクリブナーに1000ぐらいファイル入れたら重くて動かないのに、
それは適した扱ってください、当然なんですけど、
このワークフローリーはすごいよなと思って、
これこそ総合場所やなと思いました。
スピーカー 2
逆にでも、ワークフローリー的なものに何かを加えたものなんじゃないですか。
僕のイメージはそうですね。
スピーカー 1
まずメモがそこに集まって、それを何かどっかに動かしてやっていくというようなことを可能にするツールが
多分僕が求めているものでしょうね、きっと。
スピーカー 2
そうですよね。
でも一方でクライアントさんは割にカードビュー的なものを求めるじゃないですか。
スピーカー 1
カードビュー的なものを求めますね。
スピーカー 2
それはやっぱり今話しているような物書きエディター的な、
もしくはもうちょっと上位の何かの中にもそういうものが必要という。
スピーカー 1
あるはずですね、それはきっと。
それはそのレイヤーのどこに当たるんですか、カードビュー的に。
スピーカー 2
メモが集まっている場所のビュー違い。
じゃあカードじゃなくてリスト的なビューもあると。
スピーカー 1
リストビューとカードビューがあるみたいな。
スピーカー 2
ないし、リストビューでさっき言った印をつけたものがあって、それがカードとして表示されるとか、なんかそんなですね。
それは最終的な文章への連続性の中にどこかに位置づけられてるってことですか。
スピーカー 1
おそらくそう。カードを見ながら書くとか、思いつくとか。
あるはず単純にコレクションして。
着想をいわゆる梅沢的なカードで閲覧していくっていう体験もいいんですけど、
自分が書いた原稿もカード的に表示されると嬉しいんで、わりかし。
リストだけじゃなくて。
スピーカー 2
僕わかんないですけど、その感覚が。
スピーカー 1
自分のブログとかをカードビューで表示する感じですかね、感じで言うと。
別に知的な動向じゃなくて、写真アルバムを見てる感じの楽しさがあるということですけど。
スピーカー 2
だからやっぱりビューは複数あってほしいですね、僕の場合は。
そこはレバーの音的な感じかな、ビュー切り替えられるみたいな。
そうだ、僕はブシオリタの連載で、アナログの発想でデジタルを制約するっていう例で、
書こうと思って結局書かなかったんですけど、
やっぱりカード法をデジタルで再現しようっていう試みがいっぱいあったわけですよね。
やっぱりそれがみんな、KJ法だったり梅田法のカードをいかに、
もしくは文献カードみたいなものをいかにコンピューターで再現するかっていうことをやろうとしていて、
それは自然なことだと思うんですけど。
やっぱりそれもデジタルでできることを制約しちゃっていたんじゃないかなという気がしていたんですけれども、
それを原稿用紙ビューみたいなもんで、制約に意味がある場合ももちろんあるんですけど、
制約しちゃってたんじゃないかなと思ってたんですけど、
倉下さんが言うカードビューって何かそれとちょっと違う気がするんですよね。
スピーカー 1
そうですね。
スピーカー 2
ちょっとデジタル的なカードビューのような気がするんだけど、どうもちょっとうまく言葉に。
スピーカー 1
まずカードビューが何がいいかっていうと、横になる部分なんですけど。
これは半分冗談で半分本気なんですけど、縦書きに並んでるリストを見るときとカードビューを見るとき何が違うかなっていうのを自分で考えてたんですけど、
リストって読むものなんですよ。でもカードって見るものなんですよ。
だからこっちが動かしている知的動作が根本で違うんですね。
読むは読解的、リニア的。見るは何て言うのこれは。絵画を見るような感じでね。ちょっと不適切な語彙がないんですけど。
働いている知的作用がかなり違うなと思って。
全く同じ情報でもリスト的に表示されるとカード的に表示されるので、こっちの知的の動きが違うなという感じで。
読むときのモードが発動しないに見るときの方が発想しやすいというと非常にチープですけど、脳の動きが違うなというのがあって。
だからどっちかだけがいいっていうことじゃなくて、どっちも欲しい。切り替えて使いたいというニーズがやっぱりありますね。
スピーカー 2
やっぱりそれを今聞いていると、僕はゴリゴリのリニア人間なんだなと。
スピーカー 1
読む派のタイプですよね、要するに。
スピーカー 2
読んでるんですかね。
情報処理と視点の違い
スピーカー 2
視点の動き方とか情報処理がやっぱりリニアってことは、僕が言う読む型に脳が動いているということだと思うんだよね。
そうかもしれないですね。
アトラインの階層はかなり視覚的に認識してるような気がしますけど、
でもやっぱり、この人たちの言ってることの意味はわかるんですけど、自分はその感覚を抱けないんですよね。
なるほど。
カードビューにして、読むんじゃなくて見る方が発想につながりやすいという感覚を抱けない。
むしろカードの境目にぶち当たって、苛立つことのほうが多いんですね。
スピーカー 1
それは読んでるからなんですよ、きっと。
スピーカー 2
読んでるから、そうそう。読んじゃってるんでしょうね、きっと。
特性でもあるし、硬さというか狭さでもあるかもしれないし、単なる傾向の違いかもしれないし。
書くためのアトライン文章を書いててつくづく思ったんですけど、自分で思ってるよりもずっとガチガチのリニアに。
そう思うんですよ、それは。
ほんとそうだなと思って。
だからやっぱりツールの使い方も傾向によってずいぶん違うんですよね、きっと。
だから軽々しくカードなんか役に立たねえとかアウトラインなんか役に立たねえって言っちゃいけないっていうことになるんですけど。
スピーカー 1
今この画面見て、一列に並んでるアウトラインがあったとして、この情報をどう認識するのかすら人によって違いますからね、きっと。
多くの人は多分上のほうが重要って思うかもしれませんけど、
例えば文字の流れが違う文化の人だったらそう思わないかもしれませんし、
もちろん真ん中に来てるほうが重要って思う人もいるかもしれませんし。
スピーカー 2
あ、ごめんなさい。
リニア人間だけど上のほうが大事だとは全然思わない。
ただ上から順に読みますよね。
スピーカー 1
重要ということの優先度が高いというか、
上に置いてるということは一番目に触れる回数が多いわけですよ、上から読んでいくとすると。
スピーカー 2
だからそういうふうに糸を持って並べてるわけですけど。
スピーカー 1
でもそんなふうに全然思わない場合もあって、
スピーカー 2
もっとバラバラに、個別にしか見てない場合もおそらくあるでしょうし。
スピーカー 1
この線が邪魔な人もたぶんいるでしょうし。
スピーカー 2
単純な1階層のリストですら人はどう読んでるのかがわからないんですからね。
結局自分がどういう傾向かを知らないというか意識しないと、
ツールなり手法の合う合わないとか、
適切な使い方とかっていうのも本当にはわかってこないということになるんですけど、
生成AIと知的生産の挑戦
スピーカー 2
こうやって違う人と話さないとわからない。
スピーカー 1
わからないですよね。
だって自分がその認識を持ってること自体自分ではわからないですからね。
スピーカー 2
相手が言ってると、「いや、そうはならないけど、あ、なるんだ!」みたいな。
そうですね。
やっぱり人と話すことは大事ですね、ほんとね。
スピーカー 1
そうですね。
ちょっと野暮った話しますけど、
生成AIを使って知的生産みたいな話をノートでよく見かけるんですけど、
あれが本当に面白くないんですけど、
あれ結局自分しか見てないからなんですね、結局。
自分とAIしかいないし。
まあそうですよね。
自分が何をやってるかを観測できてないわけですよ。
スピーカー 2
それは面白くないなという話で。
スピーカー 1
本人が書いてないからっていうこともあると思うんですけど、
それ以上に客観的な何かがない。
客観的なメタな視点がないというか。
スピーカー 2
まあそうですね。
スピーカー 1
そこの魅力のなさというのがあって、
だからああいう記事を何個書いても多分、
方法は発展していかないのではないだろうなと。
他の人の方法とかに触れて、
違和感を感じることで初めて自分が何をやってたのか分かるということが、
多分進歩の一歩ですからね。
スピーカー 2
そうですよね。
それこそ倉下さんのやり方に触れて、
自分からするとちょっと違和感を感じるときに、
その違和感をどう感じるかなんですよね。
スピーカー 1
そうですね。
スピーカー 2
なんだこいつって思う人もいるかもしれないし、
逆に、あ、倉下さんがこう言ってるのに自分は違った。
ああ、俺間違ってたみたいになる人もいるかもしれないし。
そうなんですよね。
あ、違うんだっていう。
違和感に喜びを感じる、喜びっていうか、
スピーカー 1
でもそこから世界が広がるわけなので。
だから他人が自分の違うやり方をしてるときに、
嫌悪感とか違和感とか、
ないしは妄心的な理想を設定して、
そこからのギャップで自分を貶めるんじゃなくて、
えーって思って、えーっていう感じを持って、
結構素直に最初にやってみる人は発見が多いと思いますね。
スピーカー 2
まあそうでしょうね。
個別のエディタの価値
スピーカー 1
妄目的じゃなくて、えーという感じでちょっとやってみると、
最終的にその方法を採用しないにしても、
多分ああこういうことかとわかることは多いと思います。
スピーカー 2
そうでしょうね。
そこに自分の思いとか自分の確信に対する、
なんていうか、それをどのくらい守ろうとするかって難しくないですか。
スピーカー 1
難しいと思うんですけど。
スピーカー 2
100%受け入れるのも違うけれども、
たくなに一切受け入れないのも違うけれども、
その受け入れる度合い、受け入れるっていうか、
なんて言うんでしょうね。
例えば、もしかすると倉下さんのほうが、
例えば僕から見たら、もしかすると圧倒的に知識とか経験が、
経験値があるとしたときに、
そうするともしかして自分が違うのは、
やっぱり自分の優れている優れていないじゃないけども、
自分の経験値のなさとか知識のなさによって、
こういう違いが生まれているんだという場合もあり得るわけですよね。
そうですね。
逆もあり得ますよね。
スピーカー 2
そうあり得ます。全然あり得ると思います。
どっちなのかっていうことによって、
本当は受け入れ度合いも違うはずなんですけど。
今は、倉下さんはもう長年こういう会話をしているので、
なんとなく感じがわかるというか、
違っていることはもう最初からわかってるので。
そうなんですけど、やっぱりこれが全然初めてで、
僕は例えばアウトライナーの話をしているから、
ある程度、専門と言ったらおかしいですけど、
ああ、倉下さんはそうなのか、でも自分はこうなんだよなって思えるんですけど、
そうじゃない分野、より自分の自信のない分野だったら、
そういうふうには思えないかもしれないですね。
確かにね。
だからここは全然結論ないですけど、難しいですよね。
違うというのは基本的には楽しいことだと思います。
スピーカー 1
そうですね。違うというのは基本的に楽しいことだというのが、
ある界隈、僕たちが言葉を入れることなんですけど、
それは個人的だっていうことなんですけど、
結局能力の経験や優劣の差があったとしてなお、
例えばAさんがBさんより卓越してたとしても、
Aさんにない視点をBさんが持っていることは普通になれるわけですから。
そうなんですよね。
上だろうが下だろうが、やっぱり平和と楽しめる傲慢さなのかなと。
中にはお裸足にならないって話なんですけどね。
そうやな。でも確かにこう言ってますけど、
こいつお話にならないと自分でまびいてることもゼロではないか。
それは傲慢と言えば。
でも明らかに自分の経験で乗り越えてきたものが提出されたら、
さすがに否定してはなりますよね、ちょっと。
いやもうそれは終わったんだという気持ちにはなるんですけど。
それすら間違ってるかもしれませんが。
スピーカー 2
そうなんですよ。否定しないというのも違うし。
それは明らかに違うでしょうっていうのも別にあってもいいんだけど、
ただそれは明らかに違うんでしょうすらも、
スピーカー 1
もしかしたらこっちが間違ってる可能性もあるということもあるんですけどね。
でもそこを持ってない人間は徐々に閉じていくというか、
空気が淀んでいく感じが多分あると思うんで。
何回かに1回はバカにしててもちょっとやってみるくらいの
スピーカー 2
マインドステップが若さの引き継ぎになるかなと思うんですが。
閉じてね、水が流れ込まないみたいになっていくんですよね。
それってもう一言じゃないんですよね。
スピーカー 1
まあ年取ってくると起きがちな傾向ですね、これは。
スピーカー 2
ただそれは本当にそうなりますし、
若い若くないって言い方どうかもしれませんけど、
年齢を重ねてもクリアーな、
オープンでクリアーな明石さを保っている人は、
やっぱり池に水が流れ込んでいるし、流れ出しているし、
ということは間違いないと思いますね。
スピーカー 1
そうですね、入ってきて出すという両方がやっぱり必要ですよね。
例えば結城博先生とかって新しいテクノロジー見つけたらすぐやられますから。
今思ってますよ。
スピーカー 2
あれを一つのモデルにしたいなという思いがありますね。
スピーカー 1
まさにそう思ってましたね。
何一つ結論はなくて、個人的なエディターは一つそれぞれ違うという。
当たり前かどうかすら怪しいですが、
その人の作業に寄り添えば寄り添うほど個人的になっていくというのがあって、
例えば僕がモノ書きエディターというのを本当に作れたとしたら、
モノ書きをしている人の何割かに刺さるエディターには多分なると思いますし、
リニア傾向が強い人とか、プレビューを動かしたくないという同じ性質を持っている人であれば、
たくさんの文章エディターも多分刺さると思うんで、
個人的ではあってもロンリーではないというか、何かあるんですよね。
井戸の底が他に繋がっているような感じの繋がり方というのがあるので、
割とこの話はアウトライナーとか詳しくなくても、パソコンで文章を書いている人が、
俺もこういうの欲しいよねっていうのをノートなりスクランブルボックスなりに書くと案外広がっていく可能性があります。
スピーカー 2
そうですね。
これなんかクラシタルさんと対談本にしてもいいかもしれないぐらいちょっと思いましたけどね。
なるほど。
スピーカー 1
統一された結論を出すのではないというところですね。
スピーカー 2
そういう開かれた話し合いというのは最近欠乏しつつありますからね、インターネット社会の中で。
難しいですね。
閉じるって悪い意味の閉じるじゃなくて、クローズドなところである程度考えを進めなきゃいけない部分もあるし。
もちろん。
その上で、ある程度まで済んだところを持ち寄ってオープンに話すのが理想だと個人的には思います。
スピーカー 1
まさにそうだと思います。
スピーカー 2
両方が欠けてると、話しっぱなしとか閉じっぱなしやと、どうしても思想的に閉じていくというか、そういう感じになってしまうんで。
スピーカー 1
ちょっと自分が最近とねぎみだなと思ってたんで。
スピーカー 2
まあ忙しいとか体調悪いときはもうしゃあないですけど。
スピーカー 1
それでもまだこうやってポッドキャストしたりとかノート書いてるだけでちょっと開かれてると思いますけど。
スピーカー 2
まあそうですよ。それがなくなったら本当に。
スピーカー 1
恐ろしいですね。
スピーカー 2
恐ろしいですよ。
スピーカー 1
というところで、俺はこんな文章を入れて欲しいという意見があれば、
ハッシュタグ打ち合わせキャスト、ひらがなで打ち合わせアルファベットキャストまでいただければと思います。
じゃあ何か連絡したいこととかございますでしょうか。
スピーカー 2
大丈夫です。
本編で喋っちゃいましたね。
スピーカー 1
多分10月30日、今日までロギング仕事実が半額なので。
今日中に放送聞かれてるかどうか知りませんが、30日内に聞かれてたらAmazonチェックしてみてください。
ということで今回はこれまでにしたいと思います。お疲れ様でした。
スピーカー 2
お疲れ様でした。
01:39:24

コメント

スクロール