Weekly R-style Magazine 「読む・書く・考えるの探求」 2018/04/16 第392号

はじめに

はじめましての方、はじめまして。毎度おなじみの方、ありがとうございます。

最近、「漫画村」が話題になっています。

「漫画村」（今どんな名前になっているかは知りませんが、とりあえずこの名称でいきます）の存在も問題ですし、その存在にどう対峙するのか、という出版業界の対応も問題となってくるでしょう。

無料で閲覧できてしまうサイトが、クリエイティブ生態系に与える影響は小さくないはずです。しかし、「漫画村」を退治したからといって、第二第三の、といういたちごっこが続く可能性はあります。

それに、電子書籍が普及しつつあり、コミックはWebアプリで読めるようになり、雑誌の売上げが低下しているのは、違法サイトの問題とは別に存在しています。どちらにせよ、構造転換が必要な場面が近づいているのでしょう。

たとえ違法サイトがあっても、コンテンツにお金を払う人は間違いなくいます。でもって、何がなんでもお金を払うつもりはない人もいます。そして、その中間に「環境や条件次第ではお金を払う人」もいます。「漫画村」などへの対応は、こうした中間的な人たちからどうやってお金を頂くか、という話に向かっていくのでしょう。

・制限や規制を強め、とにかくお金を払うしかない状況にする
・正規品の利便性をあげ、お金を払ってもらいやすくする
・無料で閲覧できるかわりに、広告収入などを得る

何が正解なのかはわかりません、ただこの舵の取り方で、結果は大きく変わってくるでしょう。とりあえず、気がついたら分水嶺を越えていた、という事態にならないことだけを願うばかりです。

〜〜〜Scrapboxいくつか紹介〜〜〜

最近よく触っているScrapboxをいくつか紹介しておきます。

◇考えて、生み出す技術(TAC） - Scrapbox
https://scrapbox.io/thinkandcreateteck/

こちらは今連載で書いている「新しいサイト」の準備用ページです。とりあえずここに記事になりそうなものを集めていき、最終的には「新しいサイト」で記事化する予定です

◇Kurashita's Object Collection - Scrapbox
https://scrapbox.io/rashitaobj/

こちらはライフログっぽいページです。

◇倉下忠憲のメモ - Scrapbox
https://scrapbox.io/rashitamemo

こちらはライフログならぬ「思考ログ」なページです。アイデアメモに近いかもしれません。

もしかしたら「Kurashita's Object Collection」と「倉下忠憲のメモ」は統合するかもしれません（その辺の適切な粒度感がまだわかっていない）が、とりあえずこういうものをたくさん作っていく予定です。

とりあえず、使っていて感じるのは、ぼやぼやしているとEvernoteさんは結構危ないぞ、というところ。Scrapboxがオフラインで使えるようになったら、一気に戦況が動くかもしれません。

〜〜〜意味の意味〜〜〜

ふと気がつきました。「意味」ってすごい言葉です。

「意」は、意識・意思・意外といった熟語からわかるとおり、「こころ」を表します。「味」は、あじです。

つまり「意味」とは、「こころのあじ」ということです。

でもって、味は、物理的な存在ではなく、むしろクオリアです。蜂蜜たっぷりのホットケーキを口に運んだときに感じられるあの「甘さ」は、舌を刺激する物理現象の結果として生じますが、体験であることに代わりはありません。それは自分だけに閉じていて、他の人に「はい、こうです」と容易に提出できないものです。

「意味」もまさにそれと同じです。それは概念の解釈であり、受信者の中だけで体験されえるものです。クオリアなのです。

そのことが、つまり、意味とは事象の解釈の結果として体験者の内側に生じるものであって、イデア的に固定されてはいないことがたった二つの漢字の組み合わせで示されています。誰が考えたのか、いつ生まれたのかまったく知りませんが、ちょっと鳥肌が立ちました。

〜〜〜体系的な知識〜〜〜

私はJavaScriptというプログラミング言語が書けるのですが、その「書ける」は、ホームセンターで売っている三段ボックスを買ってきて家で組み立てられる、くらいの「書ける」でしかありません。つまり、大工としてはほぼ素人です。

これまで解説書をほとんど読むことなく、Webに公開されているさまざまなコードのコピペで、必要事を済ませてきました。まさに三段ボックスの組み立てです。

で、実用にはそれで事足りるのですが、体系的な知識はまったく得られません。で、その「体系的な知識の有無」についてはよく言及されるのですが、まさに適切な実例に先日直面しました。

JavaScriptには「getElementById」というID名によって要素を指定する書き方があって、それは私がよくコピペするコードでも使われていたので、存在は知っていました。

でも、コピペライター（私のことです）は、これを「getElementById」とだけ認識し、なんか要素を指定するものだ、くらいにしか思っていませんでした。よく読めば「ゲット・エレメント・バイ・アイディー」ですし、ID名で指定して要素を得るものだとわかるはずですが、コピペライターは「getElementById」という一つの塊として認識し、そもそも読んでいなかったのです。

で、先日たまたま別のコピペしたコードｄえ「getElementsByTagName」と「getElementsByClassName」という兄弟分みたいな書き方を発見し、「ああ、そういうことか」と腑に落ちた次第です。

わざわざ「IDによって」という書き方がされているのですから、別の「〜〜によって」という書き方だってありうるでしょう。しかし、そういうものがありうるのだという発想すら以前の私はありませんでした。つまり、知識の欠落にすら気がつけないのが、体系的な知識がない状況です。

興味深いというか、致命的なのは、私はjQueryというJavaScriptのライブラリを使っていて、そこで$('#hogehoge')や$('hoge')や$('.hogehoge')という書き方を当たり前のように使っていたにも関わらず（これらはそれぞれ上記のコードに対応します）、JavaScriptでそれができるとは思わなかった点です。

jQueryだって、JavaScriptで書かれているのですから、jQueryでできるならJavaScriptでもできるはずですが、「そういうこともできるだろう」と思いつきもしませんでした。で、「できる」と思わないので、そうした機能を使ったアプリケーションのアイデアも思いつきません。知識の上限が発想を制約してしまうわけです。

今の世界は、コピペで済ませてしまう「知識のつまみぐい」みたいなものがたくさんあって、それは時間節約的には間違いなく正解なのですが、体系的な知識の欠如がもたらすものは大きく、しかも目に見えません（意識されません）。言い換えれば、その人の世界を小さくしてしまいます。

注意しておきたいところです。

〜〜〜キャッチコピー生成マシーン〜〜〜

歩いていると、キャッチコピー（っぽいもの）をよく思いつきます。

「お味噌汁は温めます。あなたの心と体を」
「小さくても、たしかな進捗をあなたの執筆に」
「あなたの人生のオブジェクト」

別に、「よし、今からキャッチコピーを考えるぞ！」と強い決意を携えて歩いているわけではありません。単にぱっと思いつくのです。たぶん、私の無意識領域には、makeCatchphrase(arry) みたいな関数が存在していて、歩きながら目にした情報がその関数に放り込まれ、出力結果が私の意識領域に浮かんでくるようになっているのでしょう。

で、その関数は、一種のパターン加工を行っているのだと想定できます。ゼロからキャッチコピーを作り上げているわけではなく、「そう書けば、キャッチコピー風に思える」というパターンに引数を当てはめているだけです。
※だから三つともに「あなた」が含まれています。

で、そのパターンはどうやって生成されるかと言えば、この世に存在するさまざまなキャッチコピーを目にすることからです。

「こういう書き方をしたらキャッチコピーになります」という定義が先駆的に存在するわけではなく、世の中のキャッチコピーとして機能している言葉の集合から平均的に、つまり事後的にパターンは形成されます。

で、世の中でスキルとかセンスとか言われるものは、このパターンをどれだけ収集しているかの結果なのでしょう。その業界で通用するパターンをどれだけ蓄積しているか。それがスキルを決めます。

だからインプットは大切ですね。しかも偏っていない広いインプットが。

〜〜〜Q〜〜〜

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

Q. 非現実的な方法でも構いません。漫画違法アップサイトに対抗する方策は何かあるでしょうか。

では、メルマガ本編をスタートしましょう。

今週も「考える」コンテンツをお楽しみくださいませ。

————————————————
2018/04/16 第392号の目次
————————————————

○「フレームワークとライブラリの問題点」 #BizArts3rd #タスク管理
　タスク管理を掘り下げていく企画です。

○「v牧師」 #ショートショート
　読み切りのショートショートです。

○「複数の場を持つ効能」#新しいサイト作り #知的生産の技術

○「場に集う人々」 #やがて悲しきインターネット

○「アウトラインとどう付き合うか」 #物書きエッセイ #アウトライン #アウトライナー
　物を書くことや考えることについてのエッセイです。

※質問、ツッコミ、要望、etc.お待ちしております。

—————————————————————————
○「フレームワークとライブラリの問題点」 #BizArts3rd #タスク管理 #システム論

前回は、仕事術の知見をフレームワークとライブラリで捉える話を掘り下げました。

今回はこの捉え方で見えてくる、不都合や障害について考えてみましょう。

■フレームワークの問題点

フレームワークは、一つの流れを提供してくれます。そして、流れとは、始まりと終わりがある、一続きの手続きを指します。その点を考えると、二つ以上のフレームワークを同時にインストールするのは相当に困難だということがわかります。

たとえば、GTDを実践しつつ、ポモドーロテクニックも一緒に実践するのは、だいたい無理です。ポモドーロテクニックの25分集中→休憩、というテクニックならばGTDをやりながらでも導入可能ですが、それ以外のアクティビティ管理とGTDは、やることがかなり違っているので、並行で走らせることができません。そうしようと思えば、混乱が生じるでしょう。

よって、ひとつのフレームワークを選択したら、基本的にはそれだけを骨子にすることが必要です。

ただし、例外もあります。一つは、区分けです。たとえば、会社にいるときは○○フレームワークを使い、家に帰ったら▽▽フレームワークを使う、ということは可能でしょう。仕事の日と休みの日のフレームワークを切り分けるやり方もあります。

ただし、その場合でも、「発生したタスクをどのようにキャッチするのか」については注意を払わなければいけません。仕事中にプライベートの用事を思いついたり、その逆だったりは頻繁にあります。フレームワークが違っていると、その思いつきを掴まえる保存場所も違ってくる可能性があるので、混乱が生じないようにしなければいけません。

もう一つの例外が、二つ以上のフレームワークから、まったく新しいフレームワークを構築することです。つまり二つの別々の流れをいったん解体し、そこから新しい一つの流れを構築してしまえば、流れの干渉は起きません。

ただし、それを実施するためには個々のフレームワークについての詳細な理解が必要です。どんな要素があり、それぞれがどう機能して、どんな効果をもたらすのか。そうした知識があって、はじめて新しいフレームワークが構築できます。これは一朝一夕ではまず不可能でしょう。

すると、新フレームワークの構築に至るには、まずどちらか一つのフレームワークに習熟した上で、次に別のフレームワークを試し、そちらも習熟してから、という二段階のステップが必要になりそうです。

■ライブラリの問題点

次に、ライブラリについて考えましょう。フレームワークに追加して使うライブラリにもいくつか問題があります。

まず、フレームワークとの相性です。フレームワークAでは「○○については深く考えずさらっと流す」ことが想定されているのに、ライブラリBでは「○○について深く考えて、それが決まるまでは先に進まないようにしましょう」と想定されていると、見事に流れが止まります。

また、フレームワークAでは「○○についてはメソッドCでやります」となっているのに、フレームワークBでは「○○についてはメソッドDでやります」となっていると、一体どっちをやっていいのかわかりません。これもエラーの原因になります。

さらに、上記の重複と似た話ですが、名前の衝突問題も起こりえます。さて、どういうことでしょうか。

ライブラリは部品なので、一つのフレームワークの上に複数のライブラリを乗せられます。しかし、それぞれの知見は、プログラミング言語的に「ライブラリ」として作られているわけではなく、その中で閉じたパッケージコンテンツとして提供されています。よって、違うライブラリに、同じ名前の部品が存在することが起こりえます。

たとえば、「レビュー」という言葉は、GTDではっきり定義された意味を（つまり機能と役割を）持ちます。しかし、別の仕事術でも「レビュー」という言葉が使われているかもしれません。しかし、その中身はGTDのレビューとは違っているのです。

もしそのような状況で、「さあ、レビューをしよう」となったとしたら、その「レビュー」がどちらを指しているのかわからなくなります。混乱が生じるわけです。

上記の記述は、プログラミング言語処理を念頭において表現しえちますが、実際のところは、自分の脳内でレビューというものが一体何なのかがわからなくなることが起こりえる、という話です。

プログラミング風に名前空間を設定し、GTD.レビュー()と、ふり返り仕事術.レビュー()と明確に切り分けて理解できていればいいのですが、そうでなければ、レビューという概念はひどく多義的で、境界線が曖昧になってしまいます。この状況で、自分なりのシステムを構築していくのはなかなか難しいでしょう。

〜〜〜

上記の考察から、二つのことが導けます。

まず、仕事術の知見を一つしか知らないと応用は効かないが、逆にたくさん知ってしまうと今回考察したような知見の混乱が生じうること。

次に、そうした混乱を避けるためには、読者の懸命な努力に頼るのではなく、既存の知識を整理し、インストール時に衝突や重複が起きないようにすることが必要だ、ということです。

たぶん、この話は仕事術の知見だけに限ったものではないでしょう。浅く広く情報を摂取していると、簡単に起こりうる事態です。

とりあえず、本連載のこれからの目標は、既存の知識をインストールしやすく整理することになりそうです。次回はまずGTDについてそれを行ってみましょう。

（次回に続く）