ナレッジ・デベロップメントとそのツール/デジタルノートエクスプレスvol.5

Weekly R-style Magazine ～読む・書く・考えるの探求～ 2021/05/31 第555号

○「はじめに」

なんと、今週はポッドキャストを配信していません！

配信がないとちょっと寂しさを覚えるくらいには、日常に浸透しております。

でもまあ、今週は次の本のコンセプト作りに集中していたのでちょうどよい「お休み」でした。

〜〜〜書き起こし再興〜〜〜

とあるプロジェクトで、録音の書き起こしを行っています。音声ファイルを聞いて、そこで話されていることをテキストに反映する作業です。

で、その作業を「効率的」に進めようと思い立ち、さすがにMusic.app（旧iTunes）ではやりにくいので、何かしらソフトウェアを用意しようと思いついた瞬間に過去の記憶が思い出されました。

何か、自分で、工夫して、ツールを作ったぞ。

具体的な内容はまったく思い出せませんが、かなり前に「書き起こしを効率よく進めるための工夫をDIYした」記憶だけはあります。

すでに自分がやった工夫があるならば、それを拝借するのが一番でしょう。というわけで、検索です。

しかしながらScrapboxではヒットしませんでした。これはごく簡単な話で、書き起こしの作業を行ったのが、Scrapboxを本格的に使いはじめる前だったからです。

だったら、Evernoteだと思い、「書き起こし」で検索してみると、多数のヒットが（そりゃそうだ）。それらを走査してみると、どうやら2016年の後半あたりに「Tak.さんとの対談を書き起こす」というプロジェクトを進めており、そこで自分が何かしらの工夫を行ったことはわかりました。

そこで今度はそのプロジェクトの情報を扱う情報を探したのですが──まるで探偵のような作業ですね──、残念ながらそのノートにはごく簡単な覚え書きしか残っていません。

「もっと、ちゃんと書いておけよ」と過去の自分に罵倒を投げかけても、タイムリープが起きて過去に戻れるわけではありません。

仕方がなく、一番ありそうな「AppleScript」での工夫の可能性を念頭に、スクリプトファイルを上から見ていくと、「QuikTime Player」を操作するだめだけのスクリプトを見つけました。非常に小さなスクリプトで三種類あります。

・ファイルを再生する
・5秒戻す
・5秒進める

以上です。これらの単機能を扱うスクリプトを書き、それぞれにMacのHotキーを割り当てることで、「効率化」を計っていたようです（おぼろげながら記憶がよみがえってきました）。

2021年の自分からすると、非常にダサい実装です。ループをずっと回しておき、キー入力を判定して、それぞれの操作を行うスクリプトを１つ書く方がはるかにスマートですし、MacのHotキーを触る必要もありません。

だったら、そういうコードを書いてやろう、と思ったのが泥沼への一歩でした。

散々検索して回った揚げ句、AppleScriptでそのようなキー入力の受け付けを実装するのはメチャ大変、という事実が分かったのです。過去の自分のダサい実装は、むしろ最適解であることがわかりました。

だったら、今回も同じようにそれらのスクリプトにHotキーを割り当てたら済む話なのですが、「ダサい」と感じている自分の気持ちがそれを阻害します。むしろ、AppleScriptでできないなら、Pythonで書けばいいじゃないか、Python書けるようになったんだし、という内なる声がどんどん強くなります。

当初の目的は作業の「効率化」であったはずなのですが、その効率化を実現するためにまたいろいろ面倒な作業を背負い込むことになりかけているわけで、本末転倒と言ってしまえばそうなのでしょう。

一方で、そういう面倒なことをするからこそ、新しい技術が身につく側面もあります。無駄なことのように見えて、無駄でない可能性だってあるのです。

ほとんど意固地になって自分でスクリプトを書こうとしていますが、その「意固地さ」は、学びを進める原動力にもなりうるのだ、という点は忘れないようにしたいものです。もちろん単に、自分の意固地さを正当化したいだけなのかもしれませんが。

〜〜〜224ページの壁〜〜〜

現在、電子雑誌「かーそる」第四号の編集作業を進めています。やることはたくさんあり、その大半は細かい作業なので進めやすいのですが、どうしても避けては通れない大きな問題として「ページ数」があります。

電子版はともかくとして、紙版も発売できるBCCKSプラットフォームでは総ページ数がきわめて重要です。なぜなら、規定のページ数が電子の軌道のように飛び飛びにしか存在しないからです。

{48、64、96、128、160、192、224、256、288、320}

現状の原稿は紙版にすると224ページであり、余りのページは０です。逆にこれが、225ページになると、256が適用されて、31ページが余りになってしまいます。そのすべてをメモ欄にするしても明らかに邪魔です。本体価格も上がってしまうので、読者さんの財布に優しくありません。

とは言え、これが236ページだとどちらに寄せるのかで難しい判断が迫られるわけですから、現状の状態はすごく「良い」と言えます。しかし、今後増える要素は一切許可できない、という「厳しさ」も持ち合わせています。

しかしながら、そうした有限化装置があった方が、全体的なジャッジメントがやりやすいことは間違いないでしょう。というわけで、着々と発行に向けて作業は進んでおります。

■発想の促進と阻害

結城タスクに憧れに似た気持ちを抱いています。

◇結城タスク / YukiTask - A Simple Task Manager for Command Line Lovers.

結城タスク / YukiTask - A Simple Task Manager for Command Line Lovers.

特に心を惹かれるのは、プロジェクト内でmkコマンドを実行すると、自動的にそのログが保存されて、後からプロジェクトに触ったヒストリーを閲覧できる機能です。

「ログのための記録を残す」という意識的な操作を必要とせずログが残る、という点でこの機能はきわめて優れていると言えます。なぜなら、人はログを残すためだけの非生産的な作業をよく忘れるからです。

なのでこの仕組みを自分の環境にも取り入れたいなとずっと考えていました。ただし問題は、私が結城タスクを使っていないことにあります。ターミナルベースで作業するのではなく、VS Codeのワークスペースベースで作業を行っているので、シェルスクリプトを噛ませる余地がありません。何かをしたら「自動的にログが残す」を実装できないのです。

おそらく、自分でVS Codeの拡張機能を作ればそのような実装も可能にはなるのでしょうが、そこまでの意欲は今のところ見つかりません、という状況がずっと続いていました。

しかし、あるとき気がついたのです。ターミナルで作業を行ったときに記録を残すことだけが、自動的な記録の残し方ではないぞ、と。

私は毎日の作業において作業記録を書き残しながら進めるようにしています。当然そこには、各々の作業が所属するプロジェクトの名前も残ります。だったら、それをデータとして処理すれば、「自分がプロジェクトを触ったヒストリー」の記録が生成できるでしょう。

こんな簡単なことに、非常に長い間気がついていなかったこと自体に驚きを感じます。

でも、よくあることなのでしょう。最初にアイデアの刺激を受けた情報があり、それに刺激を受けているがゆえに、その情報が持つ文脈から抜け出ることが難しくなるのです。抽象化ができないのではなく、抽象化の方向が偏ってしまうのです。

私が陥っていたのは、「何か作業をしたときに、それと同時にその記録が残る」という文脈への固執です。たしかにそうすれば、日付だけではなく時間や回数なども記録に残せます。素晴らしいことです。

しかし、よくよく考えれば「何か作業をしたときに、ログを残す意識的な操作をしなくても、作業をしたログが生成される」状態が私が求めているものでした。その文脈においては、「同時に記録が残る」ことは必須の条件ではありません。たとえば、一日の終わりに作業ログから「プロジェクト・コミット・ログ」を生成したってぜんぜん構わないのです。その着眼点を見失っていたのでした。

この話の教訓はこうです。

「他人のアイデアに刺激を受けよ。そしてそこから脱出せよ」

簡単ではありませんが、大切なことです。

■「ディグる」

ディグる(DIGる)、という言葉があります。digは「掘る」という意味で、ラッパーやDJさんがレコードを堀り探す行為を指して使われます。さらに言えば、「過去の良いコンテンツを掘り起こす」という意味にまで敷延できるでしょう。

ところで、現在の情報入手は「ググる」がメインになっています。たいていは検索結果のトップだけをさらうものであり、しかもそれは更新日時が新しいものが出てきます（古過ぎるものは表示されないことすらあります）。目新しさへの、表面的な注目です。

そのように考えると、「ディグる」は「ググる」に対抗する（あるいはそれを補佐する）情報入手の作法だと言えるでしょう。いろいろなリンクを辿りに辿って、日の当たらないコンテンツを掘り起こすこと。あるいは、Googleの検索結果の深いページまでサーチして、そこから面白いコンテンツを引っぱり上げること。それが、ディグるです。

でもって、すでに書店に並んでいないような本の面白さについて言及することも、ディグることだと言えます。

こうしたディグるは、現在のコンピュータ・デジタル・AIがもたらしてくれる「効率性」に抗うための活動です。皆さんもばんばんディグっていきましょう。

■プロジェクトのエンジン

これまでは体調不良をケアして、「一日一プロジェクト」の誓いを立て、それを守ってきました。同時並行であっちゃこっちゃ考えるのは、メンタル的に疲れるだろうと予想したからです。

一方で、最近はちょこちょこ複数のプロジェクトを進めています。そうなると、連日触るプロジェクトだけでなく、実行の日付が空いてしまうプロジェクトも出てきます。

そのように複数の性質を帯びたプロジェクトを触っていて気がついたのですが、前日に僅かでも進めておいたプロジェクトは、その日のタスクリストに項目があったときに「よしやろう」という気持ちが、かなり強く立ち上がってきます。たぶん、記憶・意識に残滓のようなものが残っているからでしょう。

この現象を帰納すると、「毎日続けているものは続けやすくなり、中断したものは中断の期間が空くほど復帰が難しくなる」というマタイの法則のアレンジバージョンができあがります。

「続けよ、さらば続けられる」

のようなパロディも作れるかもしれません。

なんであれ、このような心の動きは興味深いものです。そうした心の複雑な動きを押さえつけてロボットのように行動を制御していくのではなく、不可思議さと寄り添いながら自分をマネジメントしていきたいものです。

〜〜〜Q〜〜〜

さて、今週のQ（キュー）です。正解のない単なる問いかけなので、頭のストレッチ代わりにでも考えてみてください。

Q. どんな風に「効率」を日常に導入していますか。

では、メルマガ本編をスタートしましょう。今回はデジタルノートエクスプレスのno.5で、最終回となります。

○「ナレッジ・デベロップメントとそのツール デジタルノートエクスプレスvol.5」

前回は、アーカイブとアクティブの二つの情報に加えて、新たな情報の性質を吟味しました。さらに、そうした情報を扱う上でネットワーク型のノートツール、特にScrapboxが適していると述べました。

今回は、その「新たな情報」について検討していきます。

■生きた知識を活かす

まず、前回確認したのは以下の性質です。

「今日使い切って終わりになる情報ではなく、ごくたまに参照される静的な情報でもない、その間にある情報」

こうした情報は、ごく大ざっぱに言えば「知識」と名づけられるでしょう。もう少し限定すれば「生きた知識」と言えるかもしれません。

そのような情報を扱うのに、Scrapboxは適しています。

対象は何でも構いません。分野も問いません。仕事でもプライベートでも趣味でも、工学でも文学でもビジネス理論でもレシピでもなんでもござれです。重要なのは、分野ではなく、その中で扱われる情報の性質です。あるいは、情報を扱う手つきです。

もし、タスクのように実行すればもう二度と参照しないような情報であればScrapboxは活きません。同様に、保存して参照はするが、それを手入れすることはない場合もScrapboxは活きません。
＊「活きない」だけであって利用そのものは可能です。

保存し、利用し、書き換えていくことをする情報がScrapboxで扱うのに適しています。あるいはそのような情報の運用において、Scrapboxは力を発揮します。

■デベロップメント

やや堅苦しい表現になりますが、そのような情報の運用を「知識開発」と呼ぶことにしましょう。知識を保存し、アーカイブ（備忘録化）するのではなく、知識を使って知識を発展させていく行為が知識開発です。

たとえば、料理のレシピについて考えてみましょう。Webで見つけたよさげなレシピを保存して、料理をするときに使おうとするだけならば、EvernoteやNotionが活躍します。さまざまな外部ページを自動的に取り込んでくれるので、自作の「レシピ集」を作るのはすごく簡単です。

一方で、そうしたレシピをベースにしつつも、自分で実際にやってみてレシピをアレンジしたり、あるいは複数のレシピから新しいレシピを考案したりする場合、先の二つのツールは途端にその活力を失います。そうした知的作業を行うのに向いていないのです。

ここでは、情報を「使う」ことの二つのパターンが現れています。

Evernote的に情報を「使う」とは、どこかにある情報を保存しておき、必要なタイミングで引き出し、参照して何かを行うことを意味します。

一方、Scrapbox的に情報を「使う」とは、保存してある情報を利用して、何かしらの知的作業を行うことを意味するのです。

先ほど「知識開発」と名づけたのは、後者の知的作業であり、そのような作業でこそScrapboxの真価は発揮されます。

（下に続きます）