Latest topics 近況報告

HMM 1/72 Firefox……じゃなくてFire Fox完成させた - Dec 31, 2020

今月は積みプラ消化月間にしようと決めて消化した2体目、ゾイド HMM Fire Foxです。2013年に予約して、届いて作業を始めたものの、作業を中断したまま数年放置、今月11日に作業を再開して、13日頃には完成していました。

正直、この機体がどういう物かも全く分かっておらず、子供の頃にもゾイドを履修しないまま来たため、自分にとってはこれが初ゾイドです。

簡単フィニッシュどころか、墨入れと部分塗装だけのパチ組みです。ガンダムマーカーの黄色が手元にあったので、スラスターの内側を塗ってみています。

続きを表示する ...

HGUC 1/144 セカンドＶ作った - Dec 31, 2020

今月は積みプラ消化月間にしようと決めて消化した1体目、HGUC セカンドVです。6日に着手して15日に完成しました。

このポーズを……立体で手元に置いておきたいと思ってからもう26年。悲願が達成されて感慨深いです。

成形色仕上げ部分塗装（ガンダムマーカー墨入れ流し込み用で墨入れして、ダクトの中やハードポイントの溝の中や装甲の裏や全身の丸いモールドををガンダムマーカーのグレーで塗って、BLベタの部分を黒で塗りつぶして、ハードポイントの赤い丸を赤でちまちま塗って、最後につや消しトップコート。目やトサカなどのセンサー部分だけは付属のシールをカットして貼り付けた）。合わせ目も消してないしパーティングラインもそのままです。アンテナとミノフスキードライブ下側の先端保護用の突起だけは除去しました。

いわゆる簡単フィニッシュとはいうものの、元々のキットがものすごく凝った作りになってて、合わせ目は肘関節とビームライフルくらいにしか出ないので、それで全然見栄えします。素晴らしい。ただ、ミノフスキーシールドの裏面ほか目立つ位置に肉抜き穴があったので、そこはランナーのタグ部分を切り出して埋めてみました。

目立つとこだけ穴を埋めることにした。足の裏とウェポンプラットフォームは、まあ見えないからいいかなって…… pic.twitter.com/HUVQe1h35Z

— Piro/Linuxｺﾏﾝﾄﾞ操作解説ﾏﾝｶﾞ連載中 (@piro_or) December 9, 2020

足の裏は、肉抜き穴が入り組んでてプラ材で埋めるのが大変そうだったのと、どうせ見ないのとで、そのままです。

なお、1枚目の写真は絶対にこの目で見たいポーズではあったのですが、実際にポーズを取らせた物を別角度から見ると

なんかちょっとこう……「えっへん」みたいな感じがあってマヌケっぽく感じてしまったため、棚に飾るにあたってはもう少し脇を締めてもらってます。宙に浮かせるのには、推奨のフライングベースが手に入らなかったため、たまたま余っていたfigmaガイバーⅠ付属のスタンドを流用しました。

続きを表示する ...

WSLでフォルダーを作るとWindowsでNTFSなパーティションでも大文字小文字が区別される落とし穴がある - Dec 23, 2020

業務でWindowsネイティブのアプリケーションに関わることになって、Visual Studio用のプロジェクトになってるリポジトリをcloneしてきてビルドしようとしたら、fatal error C1083: コンパイラの中間生成物 ファイルを開けません。（ファイルパス）:No such file or directory とエラーが出てビルドできなくて、ドハマリしてた。Windowsのエクスプローラで見ても確かにその位置にファイルはあるのに。何故？

他の人を巻き込んで調査に協力してもらって最終的に分かったことは、ファイルシステムがNTFSのパーティションでもパスの大文字小文字が区別される状態になっていることがあり、エラーメッセージに現れていたパス（すべて小文字）では実際のファイル（大文字小文字混在）にアクセスできなかったのが原因だということだった。パスの大文字小文字を区別しない状態に設定を修正したら、問題は解決した。

何故そんな状態が発生していたかというと、今使っている作業環境（Windows 10）に引っ越すにあたり、旧環境から必要なファイルをまとめて持ってくるために、WSL1上のrsyncを使ったのが原因だったようだ。Per-directory case sensitivity and WSL | Windows Command Lineという記事によると、This option controls which directories are treated as case sensitive, and whether new directories created with WSL will have the flag set.（（DevFsのcaseオプションは）ディレクトリー名の大文字小文字の区別を制御し、WSLで新たに作られたディレクトリーは大文字小文字を区別するフラグがセットされた状態となる）とあった。PowerShellで当該フォルダに cd して fsutil.exe file queryCaseSensitiveInfo . と実行してみると、確かに問題のcloneされたリポジトリのディレクトリーはパスの大文字小文字が区別される状態になっていた。

この状態は fsutil.exe というコマンドを使って、fsutil.exe file setcasesensitiveinfo . disable とすれば解除できるそうなのだけれど、残念ながらこの fsutil.exe は再帰的な実行に対応していないため、問題を解決しようと思うと、cloneしたリポジトリ配下のファイルやディレクトリーすべてにこのコマンド列を実行しなくてはならない。それはあまりにかったるいしヒューマンエラーも起こりそうだったので、既存の質問に寄せられていた回答に倣って、PowerShellで以下のようなコマンド列を実行して再帰的にディレクトリーの設定を修正することにした。

(Get-ChildItem -Recurse -Directory).FullName | ForEach-Object {fsutil.exe file setCaseSensitiveInfo $_ disable}

普段はファイル名に大文字小文字を混在させないようになるべく意識しているせいで、この状態が発生している事に気付いてなかった。メモ帳や秀丸エディタなどのWindowsアプリケーションでエラーメッセージに現れていたパスのファイルを開こうとして、確かにファイルはあるのにファイルが見つからないと言われる、という現象が調査の過程で発生して、それでやっと気が付いたんだった。自分で知らないうちに掘っていた落とし穴に、掘ったことにも気付かず自分でハマってしまった。

という学びを得た話をWSLアドベントカレンダー2020に書けばよかったんだけど、もうすべて埋まってたので、記録のためにここに放流しておく。

「真っ当なエンジニアリング」を意識してるITエンジニアと、ヴィーガンって似てるのかも知れない - Dec 04, 2020

コーディングスタイルを統一して読みやすい状態を保ち、変数や関数の名前付けは意味を取りやすい物にし、変数の再代入は可能な限り避けて、静的な型を使って静的解析を可能にし、モジュールは適切な粒度と凝集度を意識して設計し、自動テストも書いて、コミットごとにCIを回して。
Gitのコミットは、変更の意味を掴める単位に分割して行い、コミットメッセージは変更の意図が分かるように書き、複数人での開発ではマージコミットがなるべく発生しないようrebaseを使うようにして。
サーバーの構築・運用は、sshで入って手作業で操作するのではなく、Ansibleなどのプロビジョニング用の仕組みを使って静的な設定ファイルから環境を自動構築できるようにして。

……といった諸々のことは、決して最先端の人だけがやることでも、単なる一過性のトレンドでもなく、あらゆる現場で通用する（現時点での）ベストプラクティスと呼べる知見・姿勢だと僕は思ってる。実際、t_wadaさんによる主に自動テストにフォーカスを当てた「質とスピード」という発表の資料（2020秋版）で語られている所によれば、開発期間が1ヵ月を超える規模になったら、保守性を高く保つ真っ当なエンジニアリングを実践した方が、開発速度の面でも有利となり、ビジネス的にも合理的と言えるのだそうだ。

そういう「真っ当なエンジニアリング」について、少なくともWeb上に生息しているITエンジニアの、特に「開発に関わる者」という属性を持つ人の間では、「やってる方が不合理だと感じる」よりは、「やってないことに負い目を感じる」人の方が多そうな印象がある。

それと比べると、ヴィーガンを自称する、動物性タンパク質を排して植物だけ食べるという思想？　運動？　をやってる人達に対する、「食べる事に関わる者」「生活する事に関わる者」という属性を持つ人（つまり自分も含めた全員）からの見方は、「やってないことに負い目を感じる」人よりは「やってる方が不合理だと感じる」人の方が多いような印象がある。

というか、自分自身がそうで、正直「はぁ～、えらいどうでもええことに命かけてはりますねんなぁ～、僕ぁよう真似しまへんわ～、まあせいぜい頑張らはったらええんちゃいますか～」くらいに思ってる。思ってた。

だいたい、身近にヴィーガンがいない状態で生活しててヴィーガンを観測する場面というと、肉バルにわざわざ行って菜食のみのメニューをくれと要求するだとか、畜舎を破壊して家畜を逃がすとかの、狂信者とかテロリストじみた厄介者として観測される場合が多いので、いい印象を持ちようがないのも当たり前だと思う。

しかし、Twitterで別の目的でフォローした人がたまたまヴィーガンをやっていて、特に誰かに噛み付くでもなく、ヴィーガンテロを称賛するでもなく、ただ自身の生活の一環としてヴィーガン食の紹介だけをしている様子をしばらく観測しているうちに、どうも、ヴィーガンを自称する人の全員が全員狂信的テロリストというわけでもないようだ、と思うようになってきた。

確かに、理性的に考えれば、マクドナルドがヴィーガン向けメニューを発売したなんてニュースが聞かれるということは、巨大チェーンでわざわざメニューを設けて収益を伸ばせると目算が付く程度には、（現時点で、あるいは将来的に）需要が見込めるということで、顧客層の中にフツーに一定割合ヴィーガンがいる、ということの表れと見なしていいのだろう。テロリストと見なされて排除されるどころか、有望な顧客層として歓迎される程度に、社会と軋轢を起こすことなく普通に生活しているヴィーガンがそれなりの数いる、ということなのだろう。

続きを表示する ...

高級生食パンの先駆け「乃が美」の食パンと量産型高級食パン屋の食パンを同時に買ってきて毎日食べ比べた - Dec 02, 2020

高級生食パンの乃が美と、量産型高級食パン専門店のひとつの真打ち登場を4日ほどかけて食べ比べて、自分にははっきりした優劣は感じられなかったので、今後は（も）単純に店に行きやすい方で買って食べることになるだろう、という思いを新たにした。というのが結論で、以下は余談です。

「高級食パンがブームだ」という話はテレビで時々目にしてはいたものの、別世界の出来事だな、と思っていたら、近くにそういう店ができちゃったんですよね。それで興味本位で買ってみたら、確かにおいしいっすねと感じまして。

そもそも、脂肪と糖が多く含まれてればそれを美味と感じるバグが人間にはあって、「高級」食パンゆうても結局はバターたっぷり牛乳たっぷりブチ込んでそのバグを衝いてるだけに過ぎない、というのはブームになり始めた頃に度々聞き及んでましたし。

そういうシンプルな仕組みだから模倣も容易なのか、それで高級食パンのプロデューサーなる怪しげな人があちこちでヘンテコな名前の量産型高級食パン屋をプロデュースしている、という話も聞いてましたし。

その量産型高級食パン専門店のうちの一店が近くにできて、なんだかなあと思いはしつつも、これはこれで流行り物のエンタメかなと思って、たまに無性にパンを食べたい気分になったら買ってくる感じで、それなりに楽しんでおりました。

そんな折、

• 件のプロデューサーの量産型食パンの店舗一覧を見ると、「本物」がある地域には出店していない、量産型の店ができてるのは「本物」が出店を見合わせてたような民度の低い地域だけだ。
• 町の美観を損ねる目障りな店が増殖していて目障りだ、それほど美味しくもないのに。
• 美味いのは焼きたて当日だけ。翌日には固くなってた。
• 肝心のパンは不味いんだろう。
• やっぱり乃が美一択だ。

みたいな言説を立て続けに目にしたんですよね（いやはっきりそう言ってはいない物を勝手に僕が曲解しただけかもしれないんですけど。そういう文脈であるように僕は感じたのです）。

確かにドギツイ色と珍妙な店名はどうかと思うけど、出店された地域の側を貶されたり、食って満足してる人間の舌を馬鹿にされたりというのは、いい気分がしません。

もちろん、美味い不味いは主観なので、量産型を不味いと思う人がいても、自分にとって美味いと感じられるなら何も問題は無いはずです。

けれども、僕はすっかり呪いをかけられた気分になってしまいました。
「本物」を食べた事もないのに、量産型だけ食べて美味いと言っている、「本物」は格段に美味いかもしれないのに、それより格段に劣るかもしれない物を、安くない金額で買っているなんて、ああなんと哀れな事だろう、と。
そんな呪いの言葉が頭をチラつくせいで、僕はそれまで平気で食べられていた量産型を買いにくい気分に、すっかりなってしまったのです。

直接自分個人に向けられたわけでもない揶揄のせいで、ジレンマを感じてしまうなんて、馬鹿馬鹿しい話です。
買いたいと思って買うにせよ、買いたくないと思って買わないにせよ、自分のしたい行動をしたいように取れればそれでいいのに、それができないなんて。

この呪いを解くには、「本物」と持ち上げられてる物と量産型とを実際に食べ比べるしかない。
どうせ、そんな何万円とするような買い物でもあるまいし。
食べきれなくても、冷凍すれば保たせられるし。
無理せず買える程度のお金が手元にあって、買いに行ける距離に店舗があるのだから、とっとと白黒付けてしまった方がスッキリできます。

気をつけたいのは、食べ比べるにあたって「どちらが真に美味かを客観的に評価する」「すべての量産型の味を評価する」ことは目的にしないということです。前述の通りの個人的な屈託を解消するために、「本物」とされる物と、「量産型」とされる物の中でも自分が買う可能性がある物の味の差を体感して知り、自分の意志で判断を下せる状態になることだけを目的にします。

仮に量産型が本物より著しく不味いと感じられたとしても、「それでも近いから買おう」なり「値段に見合わないから買わないでおこう」なりの判断を下せるようになるなら、それは目的が果たされたうちに入ります。
逆に、自分が買いに行く可能性が無い量産型の物をいくら食べた所で、当初の目的の達成にはつながりません。
網羅的に調達するとか、厳密に条件を揃えるとか、二重盲検法だとかいった、データの客観性を高めるための努力をするつもりは最初からありませんでした。

続きを表示する ...

CROSS Party 2020でITマンガの話をした話 - Nov 30, 2020

1ヵ月ほど前の話になりますが、11月6日に行われたCROSS Party 2020という（オンライン）イベントにおいて、「90分、ITマンガ家に学ぶ技術の伝え方〜これであなたもマンガ家になれるかも？〜」というタイトルの枠で、わかばちゃんと学ぶシリーズの湊川あいさん、インフラ女子の日常のなつよさん、モデレータのゆうこりんさんとご一緒させて頂きました。丸一日のイベントを取り仕切られた運営の皆様、たいへんお疲れ様でした！

当日の様子はセッションの配信内容のYouTube Liveアーカイブ（の4:42:15頃から90分）でフルでご覧頂けます。

• セッション内容の要約書き起こし（さくマガ）（全部見るのはツラい！という方向け）
• セッション中で使用したスライド資料

ちなみに、この時間の直前の枠はotsune氏を含むお三方による、SNSでの炎上をテーマとしたパネルトークでした（アーカイブを90分ほど巻き戻すとその様子を見れます）。自分のセッションの準備のために途中までしか見られなかったので、後で見ようと思っていたものの、まだ見られていません。

リアルタイムでご覧になられた方の感想も拝読しております。皆さま、長時間お付き合い頂きありがとうございます！

• セッション中のTwitter上での反応ツイートまとめ（3ページ目以降）
• 「技術」の伝え方は、マンガもブログも共通・・かも。【CROSS2020】 | 伊藤愛子のいろどり招致（東京・オンラインetc）
• CROSS Party online 2020 〜明日の自分を今日変える〜 に少し参加した - sogaoh Memoris

元々はゆうこりんさん→湊川さん→僕 と話が回ってきて、さらに以前から交流があってお声がけしやすかったなつよさんが加わって、この面子になりました。「ITでマンガ」というと他にも有名な方がたくさんおられるので、次回以降また人が入れ替わって開催されると面白そうだなあ、と思っています。

話が回ってきた時点ではセッションの趣旨はまだ決まっておらず、異なる立場を代表する話者でのパネルディスカッション（議論）にするのか、議論形式でなく座談会のようにするのか、などのことを打ち合わせで喧々諤々した結果、イベントの視聴者層がITエンジニアであること、3人とも現役ITエンジニア業をしながらマンガを描いていること、イベント自体のテーマが「明日の自分を今日変える」であることを踏まえて、「セッションを見た人に、マンガを描くノウハウや、技術を絵で解説するノウハウを紹介して、自分もITでマンガをやってみようとか、普段の仕事に取り入れてみようとかの気持ちを持ち帰ってもらおう」という方向のパネルトークセッションになりました。各人がそれぞれの「マンガの描き方」「技術の話をマンガに持って行くまでの流れ」を語っているので、まだ誰もマンガで描いていない分野に皆さんが切り込んでいく上での参考になるのではないかと思います。なるといいなあ。

僕以外の登壇者お三方は皆アバター登壇で、僕だけ顔出しだったのですが、これは僕がLive2Dとかの技術についてけてないロートルおじさんだからです。白壁の前に移動して3000円くらいのLEDリングライトで顔を照らすという、アナログ極まりない方法で登壇しています。美容院の予約が間に合わず、半年くらい伸ばしっぱなしの髪のまま出ましたが、その2日後にバッサリ切ったので、今はだいぶ短くなっています。

タイムテーブルに「懇親会」とあったのですが、オンラインでどうやるんだ？と思っていたら、Zoomのビデオチャットに全員一斉参加した後、ランダムに複数人ずつブレイクアウトルームに割り振られて、ルーム間の移動は各自に任せる、という形になっていました。この形態は、同じルームの人と話す分にはいいのですが、

• そのルームで話されている話題に飽きてきたときの去り際が難しい。
• 他のルームで興味のある話題が展開されていることを認知できないので後から混ざれない。

という難があり、やはりオフラインで行われる懇親会とは質が異なっていて完全な代替にはならないな、と感じました。僕と同じルームになってしまわれた人は、僕のヨッパライ独演会に付き合わされた形になってしまったのではないかと思います。

オンラインでのイベント参加は、自分はこれの他にはOSS GateワークショップでDiscordのボイスチャット・ビデオチャットを使ったことがありますが、上記の問題は共通しているように思いました。オンラインイベントには「廊下」が無いという声を何度か観測していますが、「廊下」の方で話されている話題に混ざりたくても（共通の「廊下」が無いためにその存在を把握できず）混ざれない、というのも似た問題のように感じています。「他のルーム」や「廊下」で話されている内容がリアルタイムに文字起こしされて流れるテキストチャンネルでもあれば少しはマシになるのではないか、という気がするのですが、誰かやってくれませんかね……

WindowsのストアアプリがWindowsの更新後に「指定されたユーザーには有効なプロファイルがありません」で起動できなくなる問題の回避方法 - Nov 09, 2020

結論：Windowsをもう1回再起動してください。

Windows 10 1909からWindows 10 20H2に更新した後でWindows Terminalを起動しようとしたら、「指定されたユーザーには有効なプロファイルがありません」と言われて起動できなくなってしまった。Preview版の頃に入れてそのまま使っていたのがまずかったのか？と思って1回消してストアから入れ直してみたけど、症状は変わらなかった。

エラーメッセージで検索すると、どうもこれはストアアプリで共通して起こる問題らしく、他にはiTunesやSkypeやWordやExcelでも発生した事例があるようだった。ただ、検索上位に出てくる情報は役に立たない情報ばかり（何々というアプリが原因かもという的外れなリプライしか付いてなかったり、Wordのバージョンを書いて下さいというリプライに質問者が無反応で放置してたり）だった。

そんな中に1つ、Stack Overflowとかの情報を機械翻訳してる系のスパムサイトか？と思える文面のページがあって、そこには「更新後にもう一度再起動するで問題を解決できます」と書かれていた。更新の後に再起動かかった直後なのに、そんなので本当に効くのか？　と、機械翻訳くささに半信半疑になりつつも実際試してみたら、これが当たりだった。本当に2回目の再起動で状況が改善して、Windows Terminalが起動できる状態に戻った。1回アンインストールしたので、設定が吹っ飛んでしまったけど……

（教えてもらって気が付きましたが、ページ内に小さくリンクがありました。元記事はHow to fix broken Windows user profile after latest Win10 pro upgrade? - Super Userだそうです。）

次にググる人が少しでも優位な情報に辿り着きやすいように、ここに記録を残しておく事にする。

ラブタイツキャンペーンの炎上について、タイツフェチの視点からの記録と問題点の考察 - Nov 08, 2020

アツギ社が「タイツの日」に合わせて行った「ラブタイツ」キャンペーンが、各方面から批判されて中止になった件について、批判側に立っていた人の一人として書いてみます。

なお、アツギ社による公式の謝罪が既に出ていますので、このエントリはこれ以上の批判・非難を意図しません。自分がこの企画の何をどのように問題だと考えたかの自己分析・記録・説明と、表現に関わるあらゆる人が似たような事を繰り返さないための判断材料の提供を意図しています。

続きを表示する ...

鋼鉄人形論法を意識してトーンポリシングになる（気がする） - Oct 13, 2020

鋼鉄人形論法とは

最近、「鋼鉄人形論法」という言葉を知った。

• 藁人形論法と鋼鉄人形論法 – mhatta's mumbo jumbo

自分と反対の立場の意見について、その中でも最も愚かな主張をしている人を取り上げたり、時には実際には存在しない支離滅裂な言説をでっち上げたりして、容易に批判できる対象に対してマウンティングを取ることで、「だからあの連中は阿呆なのだ」と身内や周囲にアピールする論法を、藁人形論法と言うのだけれど、鋼鉄人形論法はその逆だそうだ。つまり、自分と反対の立場の意見の人の中でも、最も理性的で賢い人の主張を取り上げたり、相手の主張を理論的に補強したりして、容易には批判できない強固な敵と敢えて相対することで、自分の主張を鍛えていく、ということらしい。

反論をある程度想定した上で持論を述べる時には、なるべくそのようにした方がいいだろう、と自分もなんとなく思っていたので、それに鋼鉄人形論法という名前が付いてセオリーとして認知されていると知って腑に落ちた感覚がある。

トーンポリシングとは

別の話で、「トーンポリシング」という言葉がある。

• 差別や偏見を隠した「ずるい言葉」を解説　社会学者・森山至貴さんインタビュー｜好書好日

これはMeTooやBlack Lives Matterといった反差別の運動の文脈でよく聞かれる言葉なのだけれど、例えば抗議者が「差別をするな！　この差別者め！　貴様のような奴は生かしておけん！」みたいな強い口調で迫ったときに、抗議を受けた側（差別をしている側）や周囲の人が、「そんな攻撃的な言い方じゃ聞く気になれないよ」と言い方（トーン）を穏やかに改める（ポリシング）ようになだめることを、そう呼ぶようだ。抗議者（被害者）と被抗議者（加害者）の間に圧倒的な権力差がある状況では、穏やかな言い方に改めたら単に抗議が無視されるようになるだけだ、ということで、反差別の言説を無効化し差別を維持・強化する悪行であるとされている。

鋼鉄人形論法を意識すると、感情と向き合わざるを得なくなることがある

鋼鉄人形論法に則って相手の主張の論理を深く掘り下げていくと、多くの場合、相手の視点での合理的な判断の結果として自分とは異なる結論に至っていることが分かってくる。衝突を解消するための交渉においては、相手の合理的な判断と自分の合理的な判断とが衝突しなくなる落とし所を探る必要がある。

ただ、合理性では落とし所を見つけられない場合というのも多くある。僕はそれを、感情的に折り合いが付かない場合だと考えている。

例えば「あなた1人が死ねば100人が助かります。死んで下さい」と言われて、なるほど合理的だと納得して粛々と殺されようという人は、あまりいないのではないだろうか。少なくとも僕は納得して殺されようとは思えない。死ぬのが「怖い」し「嫌だ」、という感情があるからだ。感情に根ざす衝突は、どんなに鋼鉄人形論法を突き詰めても合理的な根拠には辿り着けない。

……という書き方をすると、「つまりそういう奴らは合理的な判断ができずに感情に流される愚かな連中なのだ」という話だと思われるかも知れないけれど、僕が言いたいのはそういうことではない。僕は今のところ、「感情で判断するな、合理性で判断しろ。感情なんてくだらない」とは思っていない。感情は合理性に劣るものではなく、合理性と直交する概念だと思っている。人は、合理性の面では利が小さくても感情面で利が大きい判断をすることが多々ある。僕自身は、合理性が高くても感情面で納得できない判断よりも、感情面で納得度の高い判断の方が、満足感・納得感が大きいという実感がある。

（これをもっと突き詰めると、「合理的な方が良い」と常に判断している人すらも、「合理的な方が好きだ」という主観的な感情に引きずられているのではないか？　という話になってくると思っている。ただ、これは本題ではないので、これ以上掘り下げないことにする。）

感情と向き合うと（本当の）問題が解決することがある

ともかく、両者の意見が衝突して落とし所が見つからないケースの中には、感情の折り合いが付かないことが根本的な問題であるにも関わらず、「双方あるいは片方が」「自覚的か無自覚かはともかく」感情の問題に向き合おうとしていないケースがある、と僕は思っている。

特に、「感情的になるのは愚かなことだ、感情で判断するのは愚かなことだ」というスティグマに囚われている人は、無自覚のうちに、自分の中の根本原因の存在にも、ましてやその解決からも目を背けてしまいがちではないかと思う。（というか、過去の僕はそうだった。）

そういうケースでは、感情面の問題が解決されるだけで、意外なほどスルッと話がまとまることがあるようだ。例えば、サポートセンターに電話をかけてきて、上司を出せ謝罪しろとがなり立てていたクレーマーが、電話口で一通りの感情を吐き出すとおとなしく引き下がっていった、みたいな話は度々見かける。そのクレーマー自身は、自分の感情を満足させたかっただけだとはきっと認めないだろうけれど、事実としてそれはやはり感情の問題だったのだろう。

先の「あなた1人が死ねば100人が助かります。死んで下さい」の例で言えば、多くの人は、それで救われる100人から「早く死ねよ」と石を投げられている状態よりも、感謝の言葉をかけてもらったり、「死後永遠に語り継いでいきます」みたいな事を（嘘でも）言われた方が、感情的に納得して決断をしやすくなるのではないだろうか。「お国のために」「郷里に残した家族のために」と涙を呑んで散っていった特攻隊の若者達のように。まあ、人によっては、「俺を犠牲にして自分が生き残りたいだけのくせに白々しい。そんな欺瞞に満ちたおべんちゃらを言われるくらいなら、石でも投げられた方がマシだ」ということもあるかもしれないけど（そういうタイプの人にとっては、そのように感情を徹底的に傷付けられることこそが、感情面で折り合いを付けるために必要な事なのかもしれない）。

感情面で受け入れられやすい表現にした方がいいのでは、と言うとトーンポリシングになる

差別の話についても、ここまでで述べたような感情の話が当てはまるのではないか、と僕は思っている。

といっても、ここで僕が注目したいのは、差別を受ける側の感情ではなく、「差別をした」と抗議を受ける側の感情だ。差別をしてしまう・やめられない・抗議を素直に受け入れられない側にある「自分がこれまで慣れ親しんできた文化が侵される嫌悪感」とか「自分と異質な物に対する忌避感」とか……もっと平たく言えば「怖い」「嫌だ」といったプリミティブな感情のことだ。

ここまでで述べたとおり、僕は、そういった感情も判断に大きな影響を与える要因で、且つ、決して軽視はできないと思っている。抗議される直接の加害者や、直接の加害者以外にも、その加害者を包摂する社会を構成する一員・間接的な関係者として抗議を受ける側となる、周囲の傍観者も含めて、「抗議する人とその支持者」以外のすべての人の感情を傷付けたり逆撫でしたりする言動は、問題の解決を遠のけることすらあると思っている。

「だから、抗議をするときは相手の感情を傷付けない言葉を選んだ方がいい」……というまとめ方をしたら、そう、トーンポリシングと非難されるアレになってしまうのですよね。これが、長々と書いてきてここで僕が言いたかった事。

僕自身は、何かを抗議した時に、まともに取り合う気のない相手からあれやこれやの言い逃れで抗議を無効化されれば腹が立つ。でも「言い逃れ」できる余地を残してしまっているのは自分の側の落ち度だと思うので、正攻法でいくなら、言い逃れができないように丁寧に外堀を埋めて臨むしかないのではないか、と思っている。表現を見直すこともあるだろうし、あるいは、根回しをすることもあるのかもしれない（自分はその手の政治がとても下手なので、できる気がしないけど）。傍観者から「自分の非も認められないガキが駄々をこねている」と思われてしまっては勝てない、という思いがある。

でも、「そんな悠長な事をやっていられない事態なのだ、これは今その場にある命の危機の問題なのだ」というのが差別の文脈ではよく聞かれる話で、確かにそれはそうだと思う部分もある。卑近な例えをしてしまうけれど、自分がかつて虐めを受けていた頃に、「まずは周りを味方に付けて」とか言われても「は？　ふざけんなし。味方なんかおらんし。戦って自力救済するしかないし」としか思えなかっただろうと思う。その頃の自分にとっては、自分の非を少しでも責める者はすべて「敵」で、自分の事を全部許して認めてくれる者だけが「味方」だったような気がする。

差別に抗議している最中の人達が、その頃の自分と同様の心境なのだとしたら、抗議を受けている世界を構成する一員であるところの、つまり、差別者の一員である僕から、どんな言われ方であろうとも、抗議の仕方を咎めるような言い方をされて、受け入れる気分にはならないのではないかと思う。

かといって、ここまでで述べたようなことを考えている僕には、傍観者の敵意を増すような抗議の仕方を積極的に擁護する事もできない。

なので僕は、抗議している人達に直接は賛同も批判もしないで、黙って自分の良心に従って行動するだけに留めるのがいいんだろう、と思っている。差別的言動を見かけた時には自分の言葉で咎め批判し、自分が差別的な言動をしてしまったときには粛々と反省し、自分の信じるメッセージを込めて、不用意に差別を再生産しないことを心がけて表現していくしかないな、と。

オチはないです。

「なぜMozillaはXULアドオンを廃止したのか？」に寄せられていた反応を見て、「甘い……甘すぎる……」と思って、W3C信者時代からの価値観に行き着いた話 - Aug 27, 2020

（1つ前の翻訳記事の末尾には当初、自分の個人的な考えを長々と書いていたのですが、翻訳記事でそういうことをやるのはマナー違反という指摘を頂きました。自分でも確かに、思い入れのあまり熱くなって書きすぎと感じていたので、別記事に分けるついでに増補改訂することにしました。）

原文に寄せられていたHacker Newsでの反応や、僕の翻訳に寄せられていた反応を見ていると、XULを捨てる判断を間違いと断じる物や、そのような判断をしたMozillaに対する恨み節、あるいは「バカな判断をしやがって、そんなだから俺らパワーユーザーから見捨てられたんだ」みたいな捨て台詞じみた物が結構見られました。

それらを見て僕は正直、「これだけ丁寧に書いてあってまだそんな風に思えるってどういうことなの……」と驚くやら呆れるやらしたのですが、自分自身もかつてはそっち側にいた自覚があったので、「なんでそう思うのか」も分からなくはありません。

甘い見通し

今でも「見境のない拡張機能の仕組み」を支持し続けている人というのは、アドオン開発者にしてもユーザーにしても、ある意味で楽天的というか、性善説を信じているというか、そういう感じなのかなあと思っています。

「従来路線でいっても生きていけただろう、少なくとも玄人向けとしてなら生き残れただろう」という意見については、以前の記事で「それでは結局現実に生き残れない」とバッサリ切りましたし、1つ前の記事のコメント欄にも書いてみました。しかし、それとは別に「諸々の進歩を継続しつつ、アドオン開発者やユーザーに自己責任での自由を残すのでは駄目なのか？」という主張もあります。自分もFirefox Quantum以前はそのような立場でした。

この場合の世界観は以下のように要約できるかと思います。

• アドオン開発者：「自分はFirefoxの変更に振るい落とされることはない、いつまでだって追従し続けられる」と考えている。
• ユーザー：「アドオン開発者はそのような努力をいつまでも続けてくれる」と考えている。

しかし、自分の体験と先の記事の内容を踏まえて、今僕が思うのは、「甘い……まったく甘すぎる……」ということです。

僕自身、日々壊れていくXULアドオン時代のTSTを維持するのには、ものすごい苦労を要していました。当時はそれが当たり前だと思って麻痺していただけで、実際には狂気の沙汰だったと感じています。TSTをWebExtensions化して以後の感覚では、XULアドオンを書くのなら、実作業時間で1時間あたりN万円くらいのお金を貰って仕事としてやらないと、とてもじゃないけどやってられないです。それくらいに、XULアドオンは維持にコストがかかると言わざるを得ません。「少額ながら寄附を……」とかいうレベルでは収まらない、もはやビジネスの話です。

僕自身はライフステージはそれほど変わらないままですが、結婚や子育てなどライフステージの変化の影響で、毎日アドオンのメンテナンスに時間を割くことはできなくなってしまう人も、当然いたでしょう。メンテナンスに膨大なコストを要するアドオンを継続し続けなくてはならないのでは、作者の人生をそれだけに縛り付けることにもなりかねません。

あるいは、作者個人が自分の使う範囲だけで細々メンテナンスし続ける程度なら可能かもしれませんが、それを「第三者が使いやすい」状態でリリースまでするモチベーションはどんどん下がっていく一方でしょう。

「見境のない拡張機能」は、もはや「ユーザー」はお断りの世界

なぜなら、ものすごく嫌な言い方をしてしまうと、今XULアドオンを一般向けにリリースしても、パッチも提供してくれない・問題の再現条件の特定もしてくれないクレクレ君達からの、「お願いですぅ～直してくださいぃ～ボクにはとてもメンテできましぇ～ん」みたいな声が増えるばっかりで、いいことがないからです。

それは言いすぎだろう、パワーユーザー向けならそんなことないのでは、と思う人もいるかもしれませんが、こういう修羅の世界では「敬意を払ってくれるユーザー」や「お金を出してくれるスポンサー」だけいても、結局は搾取構造にしかならない、と僕は考えています。。

一般的には「OSSにできるコントリビュートはプルリクエストだけではないです。障害報告も立派なコントリビュートです。必要な環境、再現手順、期待される結果、実際の結果を明記した良い障害報告をしましょう」ということを僕も言っていますが、「見境のない拡張機能」の世界では、それですら作者側の負担が大きすぎると言わざるを得ません。プルリクエストやコードを実際に提供し合うような、「同じ技術レベルで共に並び戦ってくれる戦友」同士で助け合う以外には成り立たない、そのレベルで戦列に加われない人に関わられて期待されても困る、というのが正直な所です。

技術的な事実をいうと、今でもFirefoxでは「見境のない拡張機能の仕組み」と同等のことをやる余地は残っています。AutoConfigの仕組みを使って、（Firefoxのインストール先）/defaults/pref/autoconfig.jsに

pref("general.config.obscure_value", 0);
pref("general.config.filename", "autoconfig.cfg");
pref("general.config.vendor", "autoconfig");
pref("general.config.sandbox_enabled", false);

という内容のファイルを置き、（Firefoxのインストール先）/autoconfig.cfgにゴリゴリ書いていけば、Firefoxのchrome領域上で任意の特権スクリプトを動かすことができます。実際、僕も仕事の上でどーーーーーーしても必要に迫られた場合はそうしていますし、Firefox内部で任意のスクリプトを特権付きで動作させるアドオンだった「userChrome.js」のエコシステムを継続している人達も、この方法を使っているようです。

こういう使い方をすると、前の記事で散々書かれているような「バージョンアップですぐ動かなくなる」「代替策がない」というドン詰まり状況が頻繁に発生します。ググって見つけたブログ記事やQiitaの記事のコピペで使うだけではとても維持できず、「自分で原因を調べて、自分でコードを直す」ということがどうしたって必要になってきます。誰かが直してくれるのをボケッと待ってるだけでは、今のFirefoxのリリースサイクルにはまず追従できないでしょう。

なお、この方法を使っている人達は百も承知だとは思いますが、この方法もいつまで使い続けられるかは分かりません。それでも、「Firefoxのソース自体に手を入れて、Firefoxそのものを独自ビルドする」のは依然として可能です。あるいは、そこまでやるならChromiumに乗り換える（Chromiumを改造して独自ビルドする）方がいいかもしれません。もはや完全に根性試しの世界ですが、腕力さえあれば乗り切れるのがOSSのいい所です。腹を括って「この方向でも生きていけるんだ」ということを示し続けていく人は、いてもいいとは思います。僕にはとても真似できませんが……

Thunderbirdの場合

FirefoxはFirefox 57で「見境のない拡張機能」をバッサリ切りましたが、Firefox ESRのスピード（1年ごとのメジャーアップデート）でゆっくり物事が推移しているThunderbirdは、もう少しソフトランディングな方向で進んでいます。会社のブログに書いたThunderbirdアドオンのTb78対応の話では「使うな」とサラッと流していますが、アドオン作者向けのThunderbird 78向け移行ガイドによると、Thunderbird 78では「公式のWebExtensions APIには含まれていないけれども、こういうAPIが欲しい」という機能があるときに、アドオン作者がそれを自力で実装する、Experimental APIという仕組みが利用できるようです（これはFirefoxでも提案はされていたのですが、なんやかやで結局実際には使える状態にならなかったと記憶しています）。

ただ、そのような本来の意図とは裏腹に、Experimental APIは結局「見境のない拡張機能」と同じことをするための互換レイヤー作りのために使われてしまっているようです。少なくとも、CardBookという巨大アドオンのThunderbird 78対応ブランチでは、ほとんどのソースはXULオーバーレイ前提になっていて、Experimental APIでXULオーバーレイ相当のことをしている様子が伺えました。

まあ、そうしたくなる気持ちは、分からなくもないんですよ。移行ガイドは（ちょろっとしか見てないですが）「こうやってちょっとずつ移行していきましょう」みたいなソフトな書き方をしてるし。一般的に、ハードランディングよりソフトランディングの方がいいとされてますし。前の記事にあった通り、Firefox自体もちょっとずつ段階的に改良されていったわけですし。

でもねえ、XULアドオンのWebExtensionsへの移行だけは、TSTのWebExtensions化で僕がやったように、「腹を括ってゼロから作り直す」以外の選択はないと思うんですよ。XULアドオンとWebExtensionsアドオンではパラダイムが違いすぎて、「ちょっとずつ置き換え」なんてできないんですよ。

「ちょっとずつ置き換えるためにとりあえずExperimental APIで全部持ち越した」の先にあるのは、「ちょっとずつ移行しようと思ってたけど、どうやって移行したらいいか見当もつかない」という混乱、そして何もできずに手をこまねいての停滞、最終的には時間切れ（Experimental APIの廃止）での完全死だけ。そうなる前に、いかに早く頭を切り替えて腹を括ってゼロから作り直そうと思い切れるか、それが生死を分けると僕は思ってます。

優先順位が違ったから僕は腹を括れたのかもしれない

XULアドオンのWebExtensions化では、「WebExtensionsらしいやり方でゼロから作り直して」「APIが足りない部分は、WebExtensionsらしい作法に則ったAPIを提案する」「要望が通らなかったら諦める、無理はしない」というのが最も「正しい」やり方です。自分は一応今のところはそういう方針でやっているつもりですが、改めて考えてみると、僕がこの方針を取れているのは、僕の本心が、多くの「見境のない拡張機能の仕組みに今でもこだわり続けている人達」とは別の所にあったからなのかもしれません。

元記事に寄せられたPale Moonのメンテナーの人のコメントでは、徹底的なカスタマイズを必要としている人のために頑張っているのだ、ということが語られています。それ以外の怨念の籠もったコメントや捨て台詞じみたコメントも、通底しているのは「自分のやりたいようにカスタマイズできることが一番大事、それ以外は二の次」という価値観のように僕には思えました。

対する僕は、「Mozillaの掲げるOpen Webの実現が一番大事、そのために必要な物としてGeckoというレンダリングエンジン実装が継続することが必要、自分のやりたいようにカスタマイズできることは二の次」と考えているようです。いま自分がインターネットを使いたいように使えるのはOpen Webがあってこそで、その邪魔になるなら自分の細かい要望は（なるべく実現できるに越したことはないけど、どうしても衝突するなら）脇に置いても構わない、というか、自分の要望を無理に押し通した結果Open Webが失われては元も子もない、という考え方なのだと思います。

これはべつに、Mozilla信者だからMozillaの言うことに何でも従ってる、というわけではありません。Mozillaに入れ込むようになるより以前、W3C信者として調子こいてた頃に僕が入れ込んでいた、アクセシビリティとかユニバーサルとかの話が先にあって、Mozillaの掲げるOpen Webはそれに連なる物だと捉えている、ということです。（そもそもで言えば、僕はWeb標準を素晴らしいと思っていて、そのWeb標準の技術に基づいたXULとCSSて実用的なデスクトップアプリケーションを作れる実例が示されていたから、ということでMozillaに入れ込むようになったのでした。）だから、もしMozillaが「Open Webなんかどうでもいい、Web技術の標準化とかどうでもいい」なんて言いだしたら、僕はその時の方が深く失望すると思います。

この日記の話題が、ここ数年ジェンダーとか差別とか多様性とかそういう話ばっかに偏ってた感じはありましたし、「シス管系女子」でみんとちゃんやその周辺の人物達の様子を描くときにもそれがずっと裏テーマとしてはあったんですが、それらも大きな括りでは近いところにあるんですよね。

そう考えると、僕がやってることはあれもこれもどっかで繋がってるんだなと。しがないラジオのときに自分のやってきたことを線で繋いだ図にしたけど、単にバラバラにそれらがあったわけじゃなく、1つの価値観の多様な表現形だったということなのかなと。

W3C信者活動をやめてすっかり軸足がよそに移ってしまったと思ってたけど、判断の根底にはまだまだW3C信者だった頃の何かが残ってたんだなあ、と改めて思い知らされて、感慨深い思いをしたここ数日だったのでした。