の作業記録

原稿を進める水曜日

8:00

おはようございます。昨日はほとんど作業ができなかったので、今日は頑張って原稿を進めます。

TH:

なんとなく原稿がうまく書けない感じがして、順番とかをいろいろ考えていたのですが、ようやくわかりました。「どこまで、説明を合目的的に行うのか」という点を決め切れていなかった、ということでした。どういうことか。

ようするに「Aしましょう。そのためにはまずBをして、次にCをして、最後にDをしましょう」というのが合目的な説明ということです。で、そういう説明をすると、読者にとっては、DもCもBもすべて「Aのために行うこと」としてマッピングされてしまう。そのことについての危機感がある。

説明としてはそれがすごくスムーズだ。話がスラスラと流れていく。逆にそうした説明をしないと、すべての説明がバラバラになってしまう。それぞれが「何のために」という位置づけを欠いているからだ。

しかし、自分の実践に立ち返ったときに、はたしてそんなに合目的に構成されているのかはかなり疑問である。というか、どう考えてもそんな風にはなっていない。

よって、合目的な説明が「説明のための必要な整理」（たとえば電流の流れをプラスからマイナスへと説明するかのような整理）として許可できるか、あるいはそういう説明をしてしまうと実践がひどく歪んでしまうからやめた方がいいのかの判断がまだついていない。

で、基本的にノウハウ書というのは合目的な説明によって構成されてきた。そのノリに乗っかるのか、それともあえて外れるのか。外れるにしても、序盤はノッておいて、後半は外れる、のような形もありうる。

そういう検討を欠いていた。だから、文章を書きながら迷いが生まれていた。すべノーではなかった迷いだ。ある意味で、すべノーは邪念がなかった。

たとえば、「私はメモ魔である。メモ環境の構築に人生を費やしてきたといっても過言ではない」のような書き始めならば、合目的な説明はほとんどしなくていい。逆に「仕事をうまく進めたいなら、メモをしましょう」は合目的な説明であり、しかも、このように書くと、すんなり受け入れられるだろうが、その分危うさがある気がする。嘘ではないのだが、いろいろなものがこぼれ落ちている気がする。

＊　＊　＊

わかりやすく伝えるための単純化は必要でも、結果として情報の受け手が、対象そのものを「単純なものだ」と理解してしまうと、現実との齟齬が大きくなりすぎるし、より深く知ろうとする動機付けを失わせてしまう。でもって、その弊害が一番大きいのが「自分」という対象であろう。

難解な文章を書くつもりはない。しかし、いかにもわかりやすい構図に落とし込むことはしない。私たちはそういう意味において単純な存在ではないから。

＊　＊　＊

もしかしたら、そうして説得的に書くことが「一番良いノウハウ書の書き方」なのかもしれない。が、自分はどうしてもそれにはノレない。そうやって、読み手を押さえつけ、異なるやり方へと開かれない方法を語るのは、自分の仕事にはできない。

だから今回は、そういう説得的な構成にはしない。「あなたは、これをしなければならない」のようには語らない。それでいて、読み手の手を引いていけるような、そんな本にする。

push :道具を使いこなすとは何か？

9:00

デスクトップの整理:

すべノーが一段落したので、Macのデスクトップのファイルを変えてみる。今良く使うものを配置する。でもって、よく考えたら、Webサービスへのリンクもデスクトップにおいておけばよいことに気がついた。

でもって、長らく使ってきて思うのは、VS Codeのワークスペース自体は、command + rで切り替えるので、ここに並んでいても、たいした意味がない、ということだ。せいぜい「自分が取り組んでいるもの」のリマインダーになっているくらいだ。だったら、メインプロジェクト以外は置かなくてもよいかもしれない。

むしろ、執筆、プログラミング、アイデア、みたいな分け方をした方がフィットするかも。ぱぱっとクリックしたらしゅるっと表示される。たとえば、ネタ帳とか考えていることリストとか。というか、Evernoteのノートはどうか。

＊　＊　＊

現状のEvernoteで、ノートをデスクトップにドラッグすると、アプリ版ではなくWeb版へのリンクになる。使えない。AppleScriptが使えるなら、このノートのIDを取得して、それを開くスクリプトを書けばいいだけだが、それもできない。

terminal経由でも、開くべき「ファイル」がわからないので、実行は無理。いろいろ限界があるな。

そりゃそうか。Evernoteはホーム画面＝デスクトップなのだから、二重性が出てくる。

ふむ。

一応「タスク」にURLを設置すれば、クリックでそれを表示させられる。URLスキームを使えば、ファイルへの移動もたぶん可能だろう。

Evernoteのホーム画面をデスクトップ的に使うこともできなくはない。でもやっぱり「配置」がないのが気になる。平面配置。

リストも表示させられるが（「タスク」がリスト表示になっている）、しかし順番を変更することはできない。ホーム画面上の「操作感」が小さいのだ。

特定のノートを固定表示させることもできるが、しかし、そこで編集はできない。編集ができるのはスクラッチパッドで、しかしそれはノートではない（クラウド同期していない）。しかも、リッチテキストは扱えない。

微妙にいろいろ足りていない。

Mac全体の「系」として見たときに、Evernoteのノートは、それ単体で非常に扱い難い。Evernoteの中ならばまだマシだが、それでもホーム画面上での「配置感」は著しく乏しい。

もっと自由なデスクトップが欲しい。多種の情報を扱いながら、ユーザーからは在る程度均一的で、しかもそれを平面的に扱える装置が。

となると、今管理している「今年買った本リスト」は、Evernote以外に移した方がいいかもしれない。そもそもspotlightでも出てこない。

今Evernoteは非常に「いい感じ」の方向に向かっているだけに惜しい。ホーム画面さえ開いておけば、必要な情報を抽出できるというコンセプトは、まさにEvernoteに必要なものだが、しかし、総合的に見て、足りない部分が多いし、それは「機能追加」というよりも、もっとベーシックなシステム設計に関わっている気がする。

とりあえず、購入本リストをEvernote以外に移すとする。あるいは、Web版のEvernote？　これならばデスクトップと同じように扱えるはず。ただし機能は結構変わってくると思うが。

Web版にするならば、そもそもMacからアプリケーションを削除する使い方になるだろう。それもそれでアリな気はする。とりあえず、Macのファイルであるかのように、ノートを扱えるようになることが肝要だ。

で、Notion以外にも、いろいろツールはあるし、なんならテキストファイルやらスプレッドシートという手もある。むしろ、この用途ならスプレッドシートが一番かもしれない。うまくすれば、書籍名をサーチしてテキストに挿入する装置のバックエンドとしても使えるし。年度別に分けることもできる。

書籍名、著者、購入日、読了日、コメント（あるいは感想を書いたページのURL）など。

あるいは、行管理ではなく、もっとテキストっぽい管理をしてもいい。書名を書いて、購入した日付を書いて、とこの作業記録みたいにブロック単位で記述していく。

その場合、「一覧」がしづらいが、マークダウンで書名を見出しにすればOUTLINEでずらっと一覧はできる。正規表現でgrepしてもいい。

データの利用しやすさで言えば、スプレッドシートだろう。一方で、「読み物」としての使いやすさ、ないしは記入の自由度で言えば、テキスト形式なはず。

この点をもう少し考えたい。新しいフォーマットが必要なのかもしれない。

11:00

妻の昼食準備など

帳簿的管理:

たとえば経理アプリでは、ある帳簿に入力すると、自動的に他の帳簿（たとえば総合管理用の帳簿）に転記される。

それと似たコンセプトの、「情報整理ツール」はあっただろうか。たとえば、デジタルカレンダーはそれに近い。具体的な日付のページに予定を書き込んだら、月間カレンダーにもそれが表示される。そのようなデジタルちっくな情報整理ツールはもっと考えられるのではないか。

＊　＊　＊

イメージしているのは、テキストベースのデータベース的な管理法。

スプレッドシートで管理すれば、ソートやら抽出やらsumならいろいろ便利がことができるが、基本的に「ログ」としての購入本管理だから、そこまで便利なことがしたいわけではない。記録を残しつつ、それを後で読んだり利用したりできたらいい。

で、テキストベースで進めるとする。

現状Evernoteでは、表組みを作り、購入日の行に書名を入れている。が、それが非常に「作業っぽい」感じを受ける。

であれば、本の購入記録をテキストで書き、その見出しだけをピックアップすることで「一覧」を生成するのがよいのではないか。基本的に、そのテキストは一ヶ月分とか一年分とかで一枚になっているが、見出しごとに切り出してHTMLファイルを生成し、それをブラウザで一枚一枚「読んで行ける」ようにしてもいい。

現状のフローに載せるなら、毎回書いているbookのところを一日の終わりに抽出する、という形になるだろう。が、そこはまた後で考える（でないと、今のフローに実装が引きずられる）。

まずテキストファイルでずらっと買った本などについて書いていく。で、書名の行をピックアップし、その「一覧」を生成する。ファイルで生成するかgrepで抽出するだけかは検討課題だが、そういうことはできるだろう。特定の条件にフィットする本だけを抽出表示するとかになるとスプレッドシートの方が便利だが、そこまでしたいわけではない。

読了などの管理ができたらいい。

逆に言うと、そのツールセットで自分は何をしたいのか。

まず、買った本の管理をしたい。管理というか、自分がいつ何を買ったのかを一覧したい。一年の振り返りて気に利用する。でもって、本を読み終えた記録も残したい。だから、Evernoteでは購入日の欄と、読了日の欄があった。そういう発想を少し変えてみる。

基本となる「帳簿」を作成し、そこから別枠で自動的に購入本リストや読了日リストが生成されるイメージ。とりあえず、それを考えてみる。

イメージ図。

Image from Gyazo

あとで読む:

13:00

TH:

手書き（iPad）のメモを原稿に反映する作業。

Image from Gyazo

Image from Gyazo

＊　＊　＊

アウトライナーに転記。

Image from Gyazo

さらにこれを整えます。

＊　＊　＊

順番を考えるために、こざね法を。

Image from Gyazo

なんとなく膨らんできました。イースト菌みたいに。

17:00

TH:

こざね法をやっているうちに、「うん、これ、この文体」と思える文章が2行ほど書けました。おそらく、これがこの本の文体を決定づけると思います。

なるべくそれを壊さないように、周りも固めていきましょう。

fragment:テキストファイルからの「切り出し」:

たとえばテキストファイルにマークダウン式で見出しを入れていたとする。

そのファイルを読み込み、見出し部分で「カット」して、それをHTMLに変換して、それをドラッグなどで移動できるツールがあったらどうか。

Image from Gyazo

barrett ideaは付箋ツールだけども、そこに原稿のブロックごとを一つひとつ入れ込んでいくと、上のようになる。こういう操作感が欲しい。で、これがエディターの「プレビュー」的なものでできると尚良い（移動結果が反映されると尚良い）。

一応、barrett ideaの付箋生成の仕組みをテキストファイルとかjson形式で取りこめるようにすれば、import自体はこのままできる。でもって、この付箋の並びからテキストファイルが出力できるなら、一応「行き来」は可能。

19:00

TH:

もう一回テキストファイルを作り直します。γ稿。

＊　＊　＊

以下の見出し行だけを先に書いておきました。

明日からはこれを埋めるように書いていきます。

book:read:『サボる哲学』:

を読みはじめましたが5ページくらいで止めました。

20:00

イラストの練習

「花」のページが終わったので、次は「料理」が始まります。

book:read:GEB:

p.294~。

チェスの場合と同じように、人間がアルゴリズム──実行したい処理の正確な記述──を定式化しようとしていたとき、ある基本的なパタンが自然に発生したようである。いいかえれば、アルゴリズムはある高いレベルの成分をもっていて、非常に制限された機械語やアセンブリ言語によるよりも、そういう成分による方がずっとやさしくきれいに書けるのである。

すべてのコンピュータ言語の中で、最も重要でしかも魅力的なもののひとつはリスプ（Lisp 表処理 List Processing を表す）で、これはアルゴルが発明されたのとほぼ同じ頃ジョン・マッカーシーによって発明された。

21:00

本日の振り返り:

THの原稿がいったりきたりしていますが、「文体」が見つかったとなれば、あとは書くだけです（希望的観測）。「これはよし、これはわるし」という判断が徐々にできるようになってきたので、明日からはがーっと書いていきましょう。

書籍の購入状況を管理する仕組みもじわじわ整えたいと思います。とりあえず、この手の情報は脱Evernoteを目指してみましょう。

というわけで、本日はぼちぼち閉店がらがらです。

お疲れさまでした。仕事終わりの妻を迎えに行ってきます。