ナカザンドットネット

それって私の感想ですよね

マッハ新書できそうだったけどやらずにちゃんと書いたという話

最近、マッハ新書ってあるじゃないですか。

nlab.itmedia.co.jp

golden-lucky.hatenablog.com

実践してる人たちのツイートをリアルタイムで眺めながら、「はー、そういうのもあるのか」くらいに思っていたのですが、期せずして自分の手元にもマッハ新書を出版できる＝12時間以内で最低限の思想を表明できるチャンスが巡ってきました。

しかし、結局マッハ新書的な形で出すのではなく、多少の時間をかけてそこそこボリュームのある記事を書くことを選びました。

このあたりの心の動きは来週くらいには忘れてしまっていそうなので、エッセイとして残しておきたいと思います。

最終的な成果物

昨日、こんな記事を公開しました。

blog.nkzn.info

執筆期間としては5/21〜25で、累計で20時間くらいかかっていると思います。

マッハ新書として出せたかもしれないもの

実は、ところてんさんが提唱していた箇条書きタイプのマッハ新書のレベルであれば、5/19か20あたりに既にできていました。MacとiPhoneのメモアプリでちまちまと書いたプロットが以下のものです。

仮題：react-native-domが浮き彫りにするReact Nativeの本質

* react-native-dom出ましたね
    * react-native-webと何が違うん？ 普通のReact Nativeとの違いは？

* RNはViewの抽象化
    * 所定のコンポーネントをiOSやAndroidのネイティブViewに変換して描画する
    * ReactはVDOMを用いた差分更新の仕組み
    * DOMやネイティブViewに書き込むところはReactとは別ライブラリ

* react-domは分かりやすい
    * 差分を随時書きこんでくだけ

* React Nativeは2段階
    * まず大前提としてJavaScriptはバックグラウンドで動いてる
    * Reactが算出した差分はReact Native Rendererに渡される
    * React DOMならここで終わるんだけど、React Nativeの場合はネイティブ側にRCTShadowView/React ShadowViewのツリーを構築するよ
    * ここの差分から新たに更新命令を作ってキューに突っ込むよ
    * Yogaはこのタイミングで評価されるよ
    * ここまでがバックグラウンドスレッド
    * あとはUIスレッドがよしなにキューから命令を引っ張り出して更新するよ
    * ShadowViewは/命令オブジェクトはネイティブコンポーネントへの参照を持っているので、ネイティブコンポーネントに定義された更新方法でViewを更新するよ

* さて、react-native-domの話をしよう
    * RNdomはDOMツリーをネイティブViewと見なして作られた、RNのサードパーティ実装だ
    * RNWindowsやRNmacosと同じ枠だね（RNWebが違う理由は後述）
    * こいつはやばい
        * RNのJS部分からはRNにしか見えてないのがやばい
        * WebWorkerまで使って2スレッド制を再現してるのがやばい
        * Yogaをwasm向けにポーティングしてるのがやばい
        * React DOMを使ってないのがやばい
        * WebComponentsなのがやばい
        * iOS SDKの再実装にまで片足突っ込んでるのがやばい

* RNwebはそこまでやばくないんだ
    * RNと同じ要素名と属性名とそれっぽいスタイルを持つコンポーネントを定義したUIライブラリでしかないんだ

* RNdomはやばい
    * DOMをネイティブViewだと言い張りやがった
    * これはRNシリーズの一角を張るのに恥じない作りをしている
    * それだけじゃない
    * Reactアプリケーションの実行にWebWorkerを使った点も評価したい
    * そもそも重いDOMの描画をUIスレッドに任せて、実はDOMに触らない
    * そして僕らがクソ重い処理を書き散らかしているReactアプリケーションを別スレッドに逃した
    * これは高速化が見込まれるのではないか（要出典）
    * DOMを直接触らない処理をWebWorkerに逃がすパラダイムは、今後のスタンダードになりうる威力を持つように思った

大筋としては最終成果物と同じことを言っています。これが書き始めからだいたい2時間くらいで書けていました。

この箇条書きができた時点で、ふと「あれ、これ今流行りのマッハ新書で出せるんじゃね？」という発想が脳裏をよぎりました。12時間以内にPDFを作ってBOOTHに投げるくらいなら、特に問題なく可能だったように思います。

しかし、それは却下することにしました。

記事の特性とマッハ新書のキモ

プロットをマッハ新書として出すのを諦めたのは、次のような理由からです。

  • React Nativeは要素技術が多岐にわたるため、読者がどの要素技術の出身かによって通じる話題と通じない話題の落差が激しい
  • React Native DOMの話はできればReact Native未経験のJavaScriptエンジニアを想定読者にしたかったので、読むための前提知識を求めたくない
  • このくらいの分量なら12時間に拘らずに、もうちょっと時間をかければ普通にそれなりのクオリティのものが出せるんじゃね？

これらをまとめると「どの文脈の話題なのかをしっかりと定めてから話し始めないと、何の話かわからない人や話題を勘違いする人が出てきそうだけど、でもそういう層の人たちも想定読者にしたいので、しっかり手をかけて文章を仕上げたい」ということになるでしょうか。

この拘りが功を奏したのか、普段ならReact Nativeの下回りに興味を示さなそうな人々が多く読んでくれたようで、こんなニッチ・オブ・ニッチなテーマについて語っている記事がホッテントリ入りするような状況になりました。

ぼんやりと思ったマッハ新書の特性

さて、怪我の功名というかなんというか、「マッハ新書にしづらい題材」を扱ったお陰で、なんとなくマッハ新書のキモの一端が見えたような気がしました。

私はマッハ新書に対して、 筆者と読者の間の文脈の共有にかける手間を極限まで端折って、本題だけを伝えることができる というメリットを感じています。

そもそも、商業レベルの文章というものが何故言葉を丁寧に選び、言葉を尽くすのかというと、 ミスリードを減らしたいから です。筆者が本来伝えたかった情報のニュアンスを誤解なく伝えるために日夜頭を抱えている人たちがいます。

ニュアンスの伝達においては、各種の用語についての認識が筆者と読者の間で共通かどうかが重要です。通常は各種の専門用語について筆者と同じ認識を持てている状態で本を読み始める人間は多くはないという前提で、文章の理解に最低限必要になりそうな専門用語については、随所随所に解説を入れざるを得ないことがあります。また、専門用語同士の関係性を理解していれば自明であるような事象についても、読者がそれを知らない可能性があるならば、関係性についても文章の中で言及する必要があるでしょう。

マッハ新書は、この「文脈を共有する手間」を意識的に排除することで高速に（比較的）短い文章を世に出す文化であると、私は認識しています。

文脈を共有する手間を惜しんだ場合、通常は誤解やミスリードが起こりやすくなります。しかし、実はこの問題を軽減できる状況があります。 筆者が所属するコミュニティが想定読者である ケースです。同じコミュニティの中では専門用語の認識が揃っていることも多いため、その認識に沿った用語の使い方をしている限りは、わざわざ言葉を尽くして文脈を共有する場面がかなり少なくなると思われます。

言ってしまえば「内輪向けなので細かく説明しなくてもだいたい伝わる」以外の何物でもないのですが、まあそういうものなのかなと思います。

コミュニティと表現すると正確でないケースも有るかもしれませんが、なんにせよ「言葉足らずがあったとしても行間を読んでもらえる」「あくまでもその時点でのスナップショットとしての思想であることを理解してもらえており、後にアップデートがあった場合にはたぶんキャッチアップしてもらえる」といった安心感を持って筆者が情報提供をできるような関係性を読者と構築できている場合に威力を発揮することは期待してもよさそうです。

さいごに

「マッハ新書とは何か」を語るには周回遅れという感じがしますが、当事者になりそうでならなかった立場になったので、いま思っていることを書いてみました。

特性はなんとなく分かってきた気もするので、適切な場面があれば出してみたいなあと思います。

おまけ

実はマッハ新書にすらできないショートバージョンがありました。

これだけでも分かる人には分かってほしかったけど、こんなので分かる人なんかいるわけないので、私たちはなんだかんだでマッハ新書程度には言葉を尽くす必要があるのであった。以上。