Latest topics 近況報告

凍結されても迷惑行為をやめない人にできる事はあるのか問題 - Jun 30, 2018

• ｢低能先生｣を凶行に駆り立てたネット民の闇 | インターネット | 東洋経済オンライン | 経済ニュースの新基準
• 「本当の引き金は６月10日の"増田"ではないか」Hagexさん殺害事件、親交のあったおおつねまさふみ氏に聞く | AbemaTIMES

この事件に関する報道を見ていた感じでは、限りなく通り魔に近いような物だったという印象だった。迷惑行為を繰り返す→通報される→通報されて凍結とかBANとかの対応を取られる→またアカウントを作り直す→迷惑行為を繰り返す……という事をしていた人が、通報・凍結の頻度が上がって追いつめられてストレスを募らせて、そんな時にまた煽られて、たまたま手の届く距離に来た人がいたから暴発した、という。だから、Hagex氏が公然と通報を煽らなければ良かった、みたいに言う人もいるけど、「人生がうまく行ってる人を見て妬む」みたいなのだってあるわけで、「不用意な発言をしないように気をつけましょう」なんてのは何の役にも立たないアドバイスなんすよね。

それはそうと、東洋経済オンラインの記事は「加害者を追いつめすぎるな」という論調だけど、かといって「迷惑行為をさせるがままにして、他のユーザーは彼の迷惑行為の被害を我慢しなければいけない」というわけにもいかないじゃないすか。ごく少数の迷惑なユーザーのせいで、一般ユーザーが離れてしまっては元も子もないし。

AbemaTIMESの動画では、よく炎上する事で知られるウーマンラッシュアワー村本氏が「昔は罵倒してくる人をブロックしてたが、ブロックされた人が逆上して余計に罵倒してきていた。今はミュートするようになって、相手はその事を知らずにずっと罵倒し続けているから、自分は快適で相手もスッキリしてWin-Win」みたいなことを発言していて（うろ覚えです。詳細は違ったかも）、やっぱり、こういう迷惑行為からフツーの人を守る鍵になるのは「ブロックよりミュート」という考え方だと思うんすよね。

自分がブロックされる側になる事があんまり無いからか、多くの人が気付いてないんじゃないかと思うけど、ブロックって「拒絶・否定した」というメッセージを相手に対して表明する行為なんすよ。普通に生活してて、明確に拒絶の意思を表明される事ってそうそう無いじゃないすか。これは多分断られるだろうなあ、断られても仕方ないよなあ、みたいな心構えができてる時ならともかく、前触れも無しに拒絶されたらイラッとする人多いと思うんすよ（僕はそうです）。それまでニコニコしてた人が、NOを伝えた瞬間に逆上するってよくある光景じゃないすか。「自分は相手から否定された」という事をわざわざ相手に知らしめる事は、リスクなんすよね。

もちろん、やっちゃいけない事をした人に「それはやっちゃいけない事だ」と指摘して、行為を改めさせる事は大事です。でも、言ったからってやめる人ばかりじゃないし。むしろ、自分の中で反省する準備ができてない人は、何を言われても頑なになるだけで、反省なんかできるはずが無いし、行為だって改めないし、余計に攻撃的になる事だってあるわけじゃないすか（こういった話は、実際に刑務所等で犯罪者の更生に関わった人が書いた「反省させると犯罪者になります」という本が面白いのでオススメです）。行動を改めも反省もしない人に対して、「あんたはブロックされたよ」「あんたはBANされたよ」とわざわざ伝える事に意義なんて無いわけですよ。

「ミュート」の面白い所は、ここがデジタルというかネットというか非物理的なサービスの面白い所なんだけど、見る人ごとに違う物を見せる機能だという点なんですよね。ミュートしてる人からは、ミュートされた人がいないかのように見える。ミュートされた人からは、自分がミュートされているとは分からない、今まで通りの物が見えている。なので、僕はこう思ったのです。迷惑行為で通報された荒らしユーザーは、サービスを使用する権利を全面的に剥奪される代わりに、単に隔離されて、自分以外の全員からミュートされるようになってたらいいんじゃないのか？　と。そうすれば、迷惑行為をはたらく人は今までと変わらずに迷惑行為（と主観的には感じられる行為）をしてスッキリできるし、他の人は迷惑行為から守られるし、Win-Win。もっと言えば、サービス運営者も「迷惑な人」一人分のPVを失わないで済むのでWin-Win-Winかもしれない。

ただ、相手の反応なんかお構いなしに暴れ回る人ならそれでいいんだけど、反応される事が自分の快楽ループに組み込まれてる人だと、「無視するんじゃねー！！」と逆上してしまいかねないという問題は残る。これをどう解決すればいいか。

スラドのように、他人からの評価がマイナスの人は「デフォルトでは見えない」「わざわざ見ようと思って見る物好きは見れる」というシステムになっていれば、何かしらの反応はある状態を維持できるかもしれない。でも、本人を逆上させないためには「自分の評価がマイナスという事を本人に知らせない」事が大事と考えると（スラドはそうはなっていない）、荒らしを自ら覗きたがるような意地の悪い物好きだもの、「あんた評価マイナスで見えなくなってるよ」とわざわざ告げ口しかねない。告げ口は無粋、黙って観察せよ、というスタンスの「ウォッチャー紳士」ばかりではない。だから「人に見させる」のはやっぱりリスクだと思う。

それで考えたんすけど、ここはひとつ、今流行りの機械学習でもって「荒らしがされたい反応だけを返す人」を演じるbotも用意して、「一般ユーザーが見てる世界」と「荒らし本人（達）と、それに反応するbotだけの世界」とを用意してみるというのはどうでしょうか。実際、自身が隔離されているという事を本人が認知できるという点を除けば、GTAやタイタンフォールといったオンラインゲームにはそれに近い仕組み（違反者とNPCだけがいる、「負け犬サーバー」とか「チータープール」と呼ばれる物）があるそうだし。専用ワールドを維持するコストはかかるけど、Twitterやはてブのように人の悪意が増幅・拡散されやすい仕組みのSNSでは、人の命がかかってるんだから、社会に対する義務を果たすための必要経費として容認してもよいのでは？　なんて思っちゃって。

……という事を考えてはみたんですが、自分で言っててすごいディストピア感ありますね。だって、何も言われずに隔離されて、その事に本人で気付けないって、自分で行動を改める機会を奪われるという事だもの。ある意味非常に冷酷で残酷な措置だ。主観的には幸せかもしれないけど、客観的には哀れですよね。というか、そういう物が既に実用化されていて、自分自身も既にそういう世界に隔離されてるんじゃなかろうか？　と思うと、背筋が薄ら寒くなってくる。

もっと生産的に考えると、単に荒らしがされたい反応だけを返すbotにするんじゃなくて、カウンセラーのように振る舞うbotにするというやり方もあるかもしれませんね。つい最近、カウンセラーにも当たり外れがある（誰もが人間的にできたカウンセラーばかりでなく、未熟で技能的にも不適格な落第カウンセラーもいる）という話を見かけたけど、botだったら「自身の感情」に流されずにカウンセラー役を淡々と勤め上げられるでしょうから。どうでしょう。まだまだSFの世界の話すぎますかね？

セクハラを「軽い気持ちでやってしまう」人、の考える事：自分の場合の振り返り - Jun 28, 2018

このエントリは、女性エンジニアの権利を守りましょうとか差別よくないよねとかの社会に対する語りかけとは本質的には関係無い、個人的な述懐です。

女性エンジニアの差別やハラスメントの話と、それをきっかけに考えた差別やハラスメントそのものの話と、立て続けにクッソ長文を書いてしまったのですが、自分でもちょっとどうしたのと思う部分はあります。

「自分がやってる事まで一緒くたにされると困る」「下手したらこっちにまでとばっちり来そうだから先に釘刺しておきたい」みたいな自己保身、予防線というのも動機の一つではあったのですが（その割に、「シス管系女子なんてタイトルの物を作ってる奴がどの口で言うんだ」みたいな明らかに文章を読んでない反応もあったので、藪蛇にしかならなかったのかもしれませんが）、やっぱり最大の動機は、過去の自分を恥じる気持ちが強いからなんだと思います。

自分が言及した記事の反応（の一部）や僕の書いたエントリへの反応（の一部）なんかも、見てるとほんと辛いんですよね。憤慨してる人がいる一方で、何が悪かったのか全く分からないという人がかなりいて、それが過去の自分にものすごくそっくりに思えて。なので、「過去こういう中の一人だった自分だからこそ、こういう人達に届く表現ができるのではないだろうか？」と思って、色々な言葉でなんとか表現してみようとしたのでした。結果はお粗末でしたが。

続きを表示する ...

差別性・ハラスメント性は「どこかの極悪人」だけの物じゃなく皆が持つ物なんだよという話 - Jun 24, 2018

1つ前の女性エンジニアうんぬんの話のエントリの反応を見ていて、「これは差別だ」「これは差別ではない」という軸での対立が見られる事に気がつきました。

そもそも僕が書いたエントリ自体もざっくり言えば「これは差別だ」派に属しているわけですが、それに対して「これは差別ではない」派の方からの言及があり、その対立軸を自分自身がよりはっきりと意識する機会になりました。

1. Y社のエンジニア炎上について思ったこと -「女性エンジニア少ない問題：元増田
2. Y社のエンジニア炎上について思ったこと 続き：僕の1つ前のエントリへの言及
3. それへの僕のコメント
4. 僕のコメントへの返信

このやり取りを見ると、僕が長文で書いた事の諸々のうち大筋では「これはよいこと」「これはよくないこと」という認識が双方で共有されているものの、「元発言が差別か否か」という点で決定的に認識が対立しているようである事が読み取れます。

自分としては、「こういう点で問題があるから避けよう」「こういう理由で問題無いからこのままやろう」という線引きが明らかになる事で、同様の「やらかし」が世の中から少しでも減りつつ、「なんか炎上しそうだから……」という漠然とした不安からの萎縮も減ってくれる事が望みなので、敢えてこれ以上の事を続ける必要も無いかなとも思うのですが、その一方で、肯定派と否定派の対立が一点に集約されるのも興味深い話だと思ったので、自分の思う所を改めて記しておこうと思います。

あと、自分はこれを「差別」と「ハラスメント」の両方にまたがる話と捉えており、両者は同じ物事の異なる面であって不可分と考えているので、このエントリでは「差別」と「ハラスメント」をワンセットで取り扱う事にします。

続きを表示する ...

女性エンジニア少ない問題を解決する話、の何が問題なのか - Jun 22, 2018

自分の観測範囲で「女性エンジニア少ない問題」を解決するために、機械学習で男性エンジニアを女性に変換する - ログミーTech（テック）という記事が話題になっていたので見たら「ｱﾁｬｰ……」としか言いようがなかった。

概要を説明すると、技術職の男性の発表で「職場に女性がいないとやる気が出ない」「女性エンジニア増やしたい（※文脈的にはITエンジニアという意味のようでしたが、ITに限らず言える事のようなので、以下の文でもそのまま単に「エンジニア」と表記します）」「本物の女性エンジニアを増やすのは人材育成のコストがかかる」「なので機械学習で声質変換を実現した。男の声で喋った内容に対応する女声の音声を出力する仕組みを作った。」という話です。技術的には多分大したことなんだと思う（自分は機械学習には詳しくないのでよく分かってない）けど、その発表の「掴み」のための話が技術の良さを台無しにしていると思いました。

これに対して、自分の観測範囲では「懲戒処分ものだ」とか「この程度で過剰反応しすぎ」とか色々な反応が見られましたが、賛否どちらにしても「何が問題なのか」という点がきっちり共有されていない印象を受けたので、その点にフォーカスして覚書を残しておきたいと思います。「なんかよくわからんけど、この辺の話題は怖いから触れんようにしとこ……」みたいに腫れ物扱いして萎縮してしまわないで済むよう、こういう根拠でこう言えるからこれは改めようとか、こういう根拠でこう説明できるからこれはそのままでいいとかの、明確な判断をするための材料の一つとして読んでもらえたら幸いです。

最初に明記しておきたいのですが、僕はこの発表を行った彼個人をやり玉に挙げて個人的な責任を問うべきとは思っていません。詳しくは後述しますが、これを通過させたチェック体制の方だったり、社風だったり、あるいは社会の風潮だったり、そういう事の方にずっと重い責任があると思っています。（そして、彼の所属組織にもイベントの主催団体にもメディアにも自分は全く関係ありませんが、別の所でその責任の一端を自分も負っている、と思っています。）

（28日追記）また、この件を非難している人は必ずしもジョークを解していない訳ではないという事も、本題に入る前に明記しておきます。恐らく発言者の彼にとっては「女性エンジニア云々は技術の本題に入る前のただの枕のジョーク」という認識だったと思いますし、擁護している方も「ただのジョークじゃないか」と思っている様子が窺えますが、批判している人の多くはこれを「悪質なジョーク」として批判しているのだという事は、最初に押さえておくべきポイントです。

続きを表示する ...

私達はここまで来た - Jun 06, 2018

昨年10月のFirefox 57リリース直前の時期に、アドオンのWebExtensionsへの移行を主導してきたAndy McKay氏がそれまでの歩みを述懐して書かれたブログ記事の勝手訳です。

私はMozillaに在籍してきたこの7年の間に色々な事をやってきました（訳註：Mozilla Add-onsに始まり、Firefox OS用のマーケットプレイスとその支払いの仕組みに関わった後、Mozilla Add-onsとWebExtensionsに戻ってきた、とのこと）。 ほんの2年前、私はアドオンコミュニティをWebExtensionsに移行させるという、Mozillaに参加して以来で私にとって最大のプロジェクトを任されました。 あと3週間ほどのうちに、Firefox QuantumはすべてのFirefoxユーザーの元に届けられ、WebExtensionsはFirefox 57においてアドオンを実行するための唯一の方法となります（訳註：その後、2017年11月14日にリリースされた）。

これは、物事を変えると決めて一緒に取り組んできたMozillaの人々の素晴らしいチームによる、2年間の努力の成果です。 私はその最初の数週間、何でこんな事になってしまったんだ？という、とんでもない恐怖の感情に駆られた事をはっきりと覚えています。 多くの人がこのプロジェクトにおいて私を助け支えてくれましたが、特に私が思うに、Kev Needham（訳註：Mozillaでプロジェクトマネージャを務めている人）が我々を導いてくれなかったら、私達は救いようのない状態に陥っていたでしょう。 私がその最初の数週間のパニックと恐怖に陥った時に、Kevと何度か対話した結果もう少しマシな状態に戻る事ができたというのは、その好例です。

最初の数週間は私達のエンジニアリングチームにはKumar McMillan、Stuart Colville、Matthew MacPherson、そしてKris Maglioneがおり、外を出歩いて更なるエンジニアを見つける事が、その月の私の主な目標でした。 その後すぐにChristopher Grebs、Mathieu Pillard、Mark Striemer、そしてLuca Grecoが加わってくれました。 私達が働き始めた最初の週には、2016年のベルリンにMatthew Wein、Andrew Swan、そしてBob Silverbergもいました。 後にShane CaraveoとAndrew Williamsonが参加してくれたのも、私達にとってはとても幸運な事でした。 様々な分野の知見と技術力を備えた彼らエンジニアの能力は誇張するまでもなく、彼らが成し遂げられた事は驚くべき事です。 私は彼らがなした事のすべてをこの記事に列挙したかったのですが、それをすると記事がとんでもなく長くなってしまうでしょう。 私達がやった事やWebExtensionsのアドオンを書く事に関する多数のブログ記事をぜひ読んで下さい。

• WebExtensions in Firefox 57 | Mozilla Add-ons Blog
• Test the new look of addons.mozilla.org! | Mozilla Add-ons Blog
• Extension review wait times are about to get much shorter | Mozilla Add-ons Blog
• web-ext 1.8 released | Mozilla Add-ons Blog
• A New Firefox Add-ons Validator | Mozilla Add-ons Blog
• WebExtensions and parity with Chrome | Mozilla Add-ons Blog
• Firefox Accounts on AMO | Mozilla Add-ons Blog
• Signing API now available | Mozilla Add-ons Blog
• Not Found | Mozilla Add-ons Blog

私にとっては、個人としてこのプロジェクトを受け入れないという選択は取り難かったのですが、この決定に反対する人達も大勢いました。 彼らは様々な異なる方法で定期的にその事を私達に知らしめようとしました。 私がMozillaに在籍するようになってから、これほどまでに激しい反対に遭った事はありませんでした。 Mozillaの他の人達が取り組まなくてはならなかった色々な事に対し、私は本当に感謝しています。

それらの懸念の声の周りを進む事は非常に大変で、時には私は舵をうまく取れず、その体験自体も助けになりませんでした（訳註：苦労したわりに得られる物が無かったという事か？）。 学習曲線がそうであるように、最初からはうまくいかない物です。

その一方で、この決定に同意してくれた他の人達による手助けは素晴らしい物でした。 ちょうど先週トロントで、複数の人々が私達の方にやってきて、私達がやり遂げた変革に対して感謝を述べてくれました。 助けてくれた皆さん、本当に、本当にありがとうございます。

私は今も、これが私達がFirefoxに対してできる最善の事の一つだったと強く確信しており、成し遂げた事を私は誇りに思っています。 それは大きな変革であり、リスクと不確実性を伴う物でした。 控えめな表現をすると、これが今後どう進んでいくかについて、やや神経質になっている部分はあります。

でも、私達はもうここまで来ました。3週間後にはFirefox Quantumがリリースされ、そこにはもうレガシーなアドオンは存在し得ません。

以上、Andy McKay氏のブログ記事の訳でした。

WebExtensionsへの完全移行に伴うレガシーアドオンの廃止については、アドオン作者や一般ユーザーから強い反発がありましたが、Mozillaの外からだけでなくMozillaの中からもそういった反発があったというのが興味深いです。

氏はその後、今年の3月にGitHubに移籍されています。そのGitHubが今度はMicrosoftに買収されて、間接的にMS資本の元におられる状態になっているという事で、不思議な運命を感じますね。

1つ前に訳したroc氏のブログ記事では、「Geckoを捨てWebKitに移行するべきだ」という破壊的な提案が述べられていましたが、そちらは実現する事はありませんでした。それと、このレガシーアドオンの大量死と大混乱をもたらしたWebExtensionsへの移行という大転換との間には、「最後までやり遂げて実現させたか、させなかったか」というだけの違いしか無いのかも知れません。

ただ、XULの中にはXPCOMと密に結合した部分も多々あり、XULの一切合切をWebKitの上に移植するのは現実的ではなかったのでしょう。仮に本当に互換性を保つ形でやるとしたら、相当に分厚い互換レイヤがWebKitの上に乗っかる事になり、そのオーバーヘッドは無視できないレベルだったのではなないでしょうか。あるいは、オーバーヘッドをなくすためにGecko上のXPCOMやXULとの互換性を犠牲にしていたら、結局それに合わせるための作業がXULアプリやアドオン側にも発生するわけで、それだったら最初からWebKitに親和性が高い形で作った方がなんぼかマシという事になっていたでしょう。いずれにしろ、roc氏の予想にあったような「WebKitの高性能さとXULの資産のいいとこ取り」は絵に描いた餅に過ぎなかったのだと僕は思っています。

Andy氏には、2016年のAll Handsにお声がけを頂き、現地でお会いした際には、グループディスカッションの場では英語のやり取りが速すぎてついていけなかったので、その後一人になられた時を見計らって捕まえて、「アドオン同士の連携を取れる事が大事なんだ」という事をつたない英語で一生懸命伝えた（同じような事をLuca氏にも言った）のを覚えています。

自分はこの記事が書かれる1ヵ月弱前にツリー型タブのWebExtensions版をリリースしましたが、「もうグダグダXULにしがみついててもしょうがない、やるしか無い」と腹を括って重い腰を上げ、他のアドオンとの連携を意識したAPIも備えた物をリリースするに至った背景には、その時Andy氏やLuca氏等と直接話して感じた「ああ、この人達は本気で物事を良くしようとしてるんだな」という心意気……みたいな？　そういうのを感じて、こちらも相応の物で応えねばなるまいと思ったから、というのも心のどこかにあったのだと思っています。

1つ前の翻訳記事にも書きましたが、WebExtensionsによってFirefoxとアドオンが明確に切り離された事は、FirefoxおよびGeckoの抜本的改革を進める上でプラスに働いているという事を最近とみに実感します。 実際、Firefox 59からFirefox 60にかけての間でも、タブバー周りの実装からXBLが取り除かれるなどのかなり大きな変化がありました。 今までであれば（WebExtensions版より前のツリー型タブなどの）アドオンの互換性が損なわれたという事で大騒ぎになっていた（僕がグダグダ噛み付いていた）かもしれません。 そういった一切がWebExtensions APIの向こう側に隠蔽された事によって、アドオン作者は安心してアドオンの開発に集中できるようになっているという現実を見るに、レガシーアドオンの廃止とWebExtensionsへの移行はやはり必要だったという事を改めて感じる次第です。

（2018年6月8日追記。大袈裟だ、WebExtensions移行を正当化したいだけのこじつけだ、と思う人もいるかもしれませんが、最近実際にあったFirefox 61での後退バグとその原因の例を見るに、XULアドオンの仕組みのデメリットは色々あったという事は否定できないと思っています。）

というか、最近久しぶりに仕事でレガシーアドオンを触る事があって、「もうこんなの作りたくない……WebExtensionsで書かせてくれ……」と思ってしまいました。最初あれだけ渋ってたのに、今じゃすっかり骨抜きですよ……

古代のブラウザ戦争の歴史：MD5ハッシュ化された投稿の機密解除 - Jun 06, 2018

Robert O'Callahan氏（Mozilla内では愛称の「roc」でもっぱら通っていたようです）が1月に公開されたブログ記事をえっちらおっちら勝手に訳してみました。多分誤訳してる所があると思うので、間違いを見つけた人は指摘して頂けると幸いです。

roc氏はFirefox以前から長くMozillaに関わっておられていた重鎮中の重鎮の一人で、現在もFirefoxの日本語入力関係のコードを手がけておられる中野さん曰く、「何かGeckoで分からん事があったらとりあえずrocに聞けば答えが返ってくる」みたいな、Mozillaの低レイヤ周りの生き字引とも言えるような方です。roc氏は2016年にMozillaを退職されたのですが、最近になって、回顧録的に上記リンク先のブログ記事を公開されました。10年くらい前の、WebKitが登場してきてめちゃくちゃ持て囃されてFirefox（Gecko）から一気に人気をかっさらい始めた時期の、ライバルのキラキラした様子を横目で見ながら、クソコードの山だったGeckoにそれでも関わり続けないといけなかったやるせなさから来る、ヤケクソな感じが吐露されていて興味深いです。

「ブラウザ戦争」と題されていますが、これはIE6の牙城を崩すべくFirefoxやChromeやOperaが競っていた頃の、第二次ブラウザ戦争と言われたり言われなかったりする物の事です。MosaicとNetscapeとIEが争ってた頃の方は第一次ブラウザ戦争で、そっちはそっちでまためちゃくちゃ面白いので、「マイクロソフトへの挑戦 ～ネットスケープはいかに してマイクロソフトに挑んだのか～」や「Webの創成」あたりを読むといいと思います（どっちも絶版ですが）。

2007年から2008年はMozillaにとって興味深い時期でした。 市場において、Firefoxは健闘しており、IEの牙城を着実に崩しつつありました。 その一方で、技術面においてはそううまくいっていませんでした。 WebKitが性能面と機能開発の迅速さで私達を追い越していたのです。 Geckoが設計上のミスと技術的負債に悩まされている一方、WebKitはOSS開発者達の心を掴んでいました。 私達はGoogleがWebKitベースのブラウザを開発中だという事も、それがWebKitの市場シェアの少なさという問題を解決するだろうという事も知っていました。 私は強い懸念に囚われ、しばらくの間、MozillaはGeckoを捨ててWebKitに全面移行する事に挑戦するべきだという意見を持っていました。 私がこういう事を大声で言うとプロジェクトに深刻なダメージがあるだろうと思い、私はこの事をごく少数の人にだけ話していました。 公的には、私は不公平な攻撃からGeckoを擁護していましたが、私自身の全体的な判断と矛盾しないように気を配っていました。

私だけがGeckoについて悲観的だった訳ではありません。 Mozilla内部では、「Mozilla 2.0」というお題目を掲げ、自動リファクタリングツールによる分析のような、私達の技術的負債を減らすための近道になる方法を求めて、かなりの時間を費やしていました。 Mozilla外部においては、ライバル達はエンジン開発の面で私達を早急に追い越す事を目指していました。

蓋を開けてみると、私達はほとんどすべての事について間違っていました。 私達は銀の弾丸を見付ける事はできませんでしたが、ただただ大変な頑張りによって、Geckoはライバル達を驚かせる程度には地位を保っていました。 また、時間の経過と共にWebKitの弱みも明らかになってきました。その場凌ぎの省略によって性能は底上げされ、いくつかの互換性テストの上で優位に立ってはいたものの、それらは同時にWebKitにとって技術的負債にもなっていました。 GoogleはWebKitプロジェクトを加速させましたが、AppleとGoogleの軋轢は問題をも生み、最終的にはBlinkというフォークが生まれる結果となりました。 Firefox 57への市場の反応は、FirefoxOSに対する誤った投資という大きな迷走の後においても、Geckoが今日においてもまだ競争力を持ち続けている事を示しています。

ここでの1つの教訓は、内部にいる人は古いコードベースに基づく見通しから、過度に悲観的になり得るという事です。 献身的で有能なスタッフの長年に渡る働きは奇跡を生む事があり、その一方で、あなたのライバル達は彼ら自身で問題を生み抱え込んでしまう事もあります。

もう1つの教訓として、2007年から2008年にかけて私はIE（そしてFlash、WPFも）を倒す事に過度に集中しており、全てのオープンソースのブラウザがたった1つのエンジンの実装を共有する事になったとしても、それはWebにとってそれほど大きな問題ではないと思っていました。 でも今では私はすっかり意見を変えました。 エンジンにおいてより多くのコードを共有する事は、不具合の共通化までをも招くため、真に独立した実装を持ち続ける事は非常に重要なのだと。

私は、Brendan（訳註：Brendan Eich。Netscape時代からの古参でJavaScriptの開発者だが、同性婚反対の運動への寄付がきっかけとなって2014年にMozillaを追われた）や他の人達が、私の意見を取り入れなかった事によって、Mozillaを誤った道へと導くという過ちを私に犯させずに済ませてくれた事に、非常に感謝しています。 もしそうなっていれば、それは誰にとっても大きな災いだったでしょう。

鬱憤ばらしと、記録を後世に残す事を意図して、私は2007年から2008年にかけて、私の考えを説明する4つのブログ記事を書き、それらのMD5ハッシュだけを公開していました。 Firefox 57のリリースの成功の余波がある今は、それらのブログ記事を無害な状態で機密解除するのにちょうどいい時と言えるでしょう。 くれぐれも、私は既に意見を変えているという事を心に留め置いておいて下さい。

続きを表示する ...

「ツリー型タブ」が、Firefoxのアドオン管理画面にオススメとして表示されるようになりました - Jun 04, 2018

標題の通り、ツリー型タブが、Firefoxのアドオン管理画面にオススメとして表示されるようになりました（メールインタビューでやり取りしたScottさんが教えてくれた）。一定期間で入れ替わるやつなのでそのうちまたどっか行くと思うけど、記念に記録を残しておきます。

最初に書いておくと、このエントリはただの自慢です。こういう所に注目してくれる人はどこにもいないので、自分で解説して「僕TUEEEEEE」とアピるという物です。

統計データ上ではFirefoxの全ユーザーの中でアドオンを使っている人は意外と多くなくて、せっかくアドオンがいろいろあるのだから認知を向上させたい、というのがMozilla的には一つの課題のようです。2016年のAllHandsで既に、「アドオンをインストールするまでのハードルを下げたり、アドオンのインストールというよりも機能のON/OFFのように見えるようにしたりするといいのでは？」という方向でリニューアルを進めているということが通達されていて、現在のMozilla Add-onsやアドオン管理画面はその時見たモックほぼそのままのデザインが踏襲されています。

その時見た「機能のON/OFF」の選択肢の中に自分が作ったアドオン、特に「ツリー型タブ」が登場しているというのが、何とも感慨深いです。

というのも、WebExtensions版を作った時の苦労話の冒頭に名前が出てくるTBEより若干マシになってはいたものの、ツリー型タブもアドオンとしての「お行儀の悪さ」はなかなかのものでした。Firefox本体の関数をガンガン置き換えるわ、eval()で関数の行単位でモンキーパッチを当てまくるわ……なのでMozilla Add-onsのレビューポリシー的に「一般向けのアドオン」としては認められず、サイト上の検索結果等には表れない「開発者向けアドオン」の地位に長く留まっていました。TBEやツリー型タブのせいで（互換性を壊すとクレームがMozillaの方に来るから）Firefox本体の大規模な改修が阻害されていた、という部分ももしかしたらあったかもしれず、恨まれたり疎まれたりしていてもおかしくないくらいです。

そういう背景を持つツリー型タブが今、Mozilla Add-onsのバリデーションでエラーも警告も一切無く、Firefoxを使っている人がアドオン管理画面を開いたら目に入る位置に、広告ブロック等の桁違いのメジャーな選択肢に紛れて表れている現状を見ると、「ずいぶん立派になったもんだ……」と思うわけです。

ところで、苦労話に書いた通り、ツリー型タブのWebExtensions版は同様のWebExtensionsベースの縦長タブバー型アドオンとしては最後発と言っていいくらいに遅れて登場しました。いま自分が把握してるだけでも、サイドバー内に縦型のタブバー風UIを表示するアドオンは他にもこれだけあります。

• ColorfulTabs
• sidebarTabs
• Tab Center Redux
• Tab Sidebar
• Tree Tabs
• Vertical Tabs Reloaded
• Vertugo Tabs

それらを差し置いて何故ツリー型タブがおすすめになっているのでしょうか。選考過程は関知していないのであくまで憶測ですが、「これらの中ではツリー型タブが一番クソ真面目にFirefoxのタブバーを真似てるから」ではないだろうか、と自分は考えています。

実際に自分自身で上記の縦型タブバーアドオンをいくつかを試してみると、「みんな意外と適当だな……？」という印象を受けました。例えば以下のような具合です。

• 見た目・配色がまずFirefoxのタブと大きくかけ離れている。
• リンクをサイドバー内にドラッグ＆ドロップしても、タブとして開かれない。
• リンクをサイドバー内にドロップすると、ドロップ位置ではなく常にタブバー末尾に開かれる。
• コンテキストメニューが無い。
• コンテキストメニューがあるが、項目の並び順がFirefoxのタブバーの物と違う。
• 音声をミュートしたタブの表現の仕方が独特。
• Firefoxのタブバー上のタブの並びとサイドバー内での並びが一致しない。

ツリー型タブはどうかというと、基本的に見た目も挙動も全部Firefoxのタブに合わせるようにしています。技術的に不可能な事以外は、Firefoxのタブバーでできることは全部ツリー型タブでも同じようにできるようにする、という方針です。何故かというと、平たく言えば「そうじゃないと自分が使えないから・使う気にならないから」です。だってイヤじゃないですか、たかが個人開発のアドオンごときのために今まで覚えた物全部捨てて一から順応しなきゃいけないなんて。

もう少し格好を付けて言うと、度々述べていますが、UIの実装時には既存の何かに合わせるのが鉄則で、必要のない中途半端な自己主張はユーザーにとっては邪魔でしかない、と僕は考えています。コンテキストメニュー項目の並び順にせよミュート状態の表示の仕方にせよ、「Firefoxのタブと違う」という事それ自体が学習コストを引き上げ、使い勝手を悪くします。メニュー項目の並び順などはその典型で、人は普段よく使うメニュー項目を「だいたいここら辺」というような視覚的な位置で記憶しているようで、並び順が違うとそれだけでもう目当ての項目を見つけられなくなります。まったく違うならそれはそれで覚え直せばいいのですが、中途半端に似ていると、両方の記憶が混ざって余計に悲惨な事になります。似せるなら半端に似せないで完コピする、「俺の考えた最強のUI」を披露したいというエゴは捨てる、というのが、既存の何かに対する「改良版」と言える物を作る時に必要な心がけだ、と僕は思っています。

こういう所って、頑張れば頑張るほど違和感が無くなって既存の物に溶け込んでいってマジで誰にも気付いてもらえなくて報われなくて、それだけならまだしも、こういう事を頑張る事の価値自体が認識されなくなって誰もこういう所を頑張ろうとしなくなるんじゃないかということを心配してるので、ダサいとは思いつつ折に触れてアピっておく次第です。

また話は変わりますが、Google Chrome向けにもツリー型タブの代替になりそうな拡張機能はいくつかあるものの、どちらも自分にとっては「コレジャナイ」感が強くて、Chromeへの移行を考える材料にはなりませんでした。

• Sidewise Tree Style Tabs
• Tabs Outliner

どのあたりが「コレジャナイ」なのかは上手く言語化できないのですが、上記のような点が理由なんじゃないかなあとなんとなく思っています。Chrome全然使ってないから憶測ですが。

今見てみたところ、これを書いている現時点でのTabs Outlinerのユーザー数は13～14万人くらい、ツリー型タブのユーザー数は12万人くらいらしいです。Firefoxより圧倒的にユーザー数が多いはずのChrome用拡張機能ですから、ユーザー数に何倍も差があってもおかしくなさそうですが、実際にはこのように案外健闘しているようだというのが興味深いです。元々こういうタイプのUIに順応できる人やこういうUIを求めている人の絶対数がそのくらいという事なんでしょうか？　とりあえず今のところは、「Chromeユーザーの中でこれらの拡張機能を使ってる人の割合より、Firefoxユーザーの中でツリー型タブを使ってる人の割合の方が多いという事は、ツリー型タブの方がユーザーに選ばれているという事に違いない！」と勝手に自慢しておこうと思います。

という、最初から最後まで自慢でしかないエントリなのでした。

技術書典4に参加して「まんがでわかるLinux シス管系女子3」とかグッズとか頒布しました - Apr 23, 2018

去る2018年4月22日、東京・秋葉原UDXにて開催された技術同人誌オンリーイベント技術書典4に、サークル「シス管系女子会」として参加してきました。無駄にパトロン枠での参加でした。

毎度、シス管系女子の草の根的な営業活動とファンサービス、あと〆切を設けることで何か新作を作るモチベーションにするという目的で参加していますが、今回も結果のほどを記しておこうと思います。なお、技術書典、技術書典2の結果、および技術書典3の結果は過去記事をご参照下さい。

数字的なこと

今回の数字は以下の通りでした。一般的な技術同人誌のサークルというよりも、一般書店で購入可能な商業出版物メインの企業参加者の例という感じで見て頂いた方が良いと思います（申し込みは自分が個人的にやっていますが、商業出版物は日経BPの委託販売という形で、売り上げもそっくりそのまま渡しています）。

• 技術書典4 Webサイト上でのサークル詳細ページの被チェック数：230（4月23日時点）
• 持ち込み部数：
  • ムック「まんがでわかるLinux シス管系女子」35部
  • ムック「まんがでわかるLinux シス管系女子2」35部
  • ムック「まんがでわかるLinux シス管系女子3」79部（会場当初持ち込み分60部、途中追加分19部）
  • ステッカー 106枚
  • タイツ各種 計30枚（だったか？）
• 頒布実績：
  • ムック「まんがでわかるLinux シス管系女子」35部 完売
  • ムック「まんがでわかるLinux シス管系女子2」35部 完売
  • ムック「まんがでわかるLinux シス管系女子3」見本用の1部を除き、78部 完売
  • ステッカー 50枚
  • タイツ各種 計7枚

技術書典2の時に作成した、サンプルを兼ねたチラシ形式のリーフレットも持ち込んではいました。ただ、こちらは前回に引き続き今回も積極的にばらまかなかったので、数としてはほとんど出ていないと思います。

今回特筆すべきは、本の持ち込み分が早々に完売してしまったという事です。特に「シス管系女子3」は、当初持ち込み分60部は11時の開場から12時50分頃までの間に払底してしまい、途中で日経Linux編集部にあったという19部を急遽追加してもらいましたが、14時30分の頒布再開後14時58頃までの間になくなってしまいました。本が無くなって以後も何度か「3を……えっもうないの」的な反応を頂いていて、数だけは多く用意できるはずの商業出版物であるにも関わらず、せっかく来ていただいたのに申し訳ない限りです。一応、Amazon等の通販や書泉ブックタワー等会場近くの書店でも普通に入手できる旨は案内させていただきましたが……

シス管系女子3、技術書典4会場持ち込み分完売してしまいました……本自体はヨドバシの上の書店や書泉ブックタワー等でお買い求め頂けます〜 pic.twitter.com/27pYMf4fN7

- Piro/Linuxコマンド操作漫画連載中 (@piro_or) 2018年4月22日

持ち込み部数は前回までの実績を踏まえて検討した結果だったのですが、晴天に恵まれてのべ参加者数が倍増した事と、今回の新刊である「シス管系女子3」が4月19日発売でこれ目当てに来て下さった方が相当数いらっしゃったようだという事から、全く想定外の売れ行きとなりました。新刊が多めに出るのは想定の範囲内でしたが、既刊も前回参加時より多く出ており、全ての本が15時台にはなくなってしまいました。やはり天候の効果は大きかったようです。グッズも、ステッカーは頒布価格が高めだったので10〜20ほど出ればいいくらいかなと思っていたのですが、気がつくと半分程なくなっていました。タイツは……元々あしピタが本命の物なので、まあこちらは想定の範囲内ですね。

スペース設営のこと

今回は商業誌3冊に加えてグッズも並べる必要があったのですが、今までのやり方だと確実に場所が足りなくなるので、どうにか縦方向にディスプレイする方向で工夫してみました。

スペースできた pic.twitter.com/Qspx06BDMS

- Piro/Linuxコマンド操作漫画連載中 (@piro_or) 2018年4月22日

まず本を縦にディスプレイする方法ですが、既製のイベント展示用の雛壇を調達しました。できれば何度も使える耐久性の高いプラスチックや金属や木の物を調達したかったのですが、ちょうど良さそうな物は品切れだったり、微妙にサイズが合わなかったりしてなかなか良い物が見つからず、最終的に選んだのはIGARASHI PROというメーカーの段ボール製組み立て式雛壇でした。本来はイベント毎に使い捨て前提の製品のようですが、それは勿体ないので、両面テープで固定する部分をマジックテープで置き換えてバラして持って帰れるように改造しました。また、結構奥行きがあってこれを置くと平積みのスペースを確保できないため、一番手前の段を潰すことにしました。

調達したダンボール製陳列棚。平積みと併用したいけど机の奥行きが足りないので、一番手前の一段を潰して平積み用のスペースを確保しようかなと。切らずに折ってるだけなので一応元の形（4段）にも戻せる……はず。 pic.twitter.com/IHTelNY87y

- Piro/Linuxコマンド操作漫画連載中 (@piro_or) 2018年4月18日

タイツは普通に置くと滑り落ちて危ないので、普通の店舗でワゴンセールになってる物のように縦にしてケース（たまたま家にあった未使用の不織布製収納グッズ。ある程度の柔軟性がある）に詰めて、その後ろに背の高いディスプレイでサンプルを展示する形にしました。高さを出すための物は最初は段ボール工作を考えていたのですが、もえじら組の最初のイベント参加の時に買ったスチレンボードの残りが出土された（10年以上前の物……）ので、それを切り貼りして適当に作りました。

スチレンボード工作のこれは……なんと言えばいいんだ……？ タイツ四種を貼り付けて縦にディスプレイしようかなと。 pic.twitter.com/ni7zaXnGeV

- Piro/Linuxコマンド操作漫画連載中 (@piro_or) 2018年4月18日

後ろ側は紙製の簡易スタンド（同人誌の見本や値札を立てかけるために使われるような物）ですが、高さがある分倒れやすいので、後ろの方に足を延長してバランスを取ってみました。

トップヘビーになって倒れてしまったので、足だけちょっと延長してる（ホチキス使用） pic.twitter.com/giSxH6G8rN

- Piro/Linuxコマンド操作漫画連載中 (@piro_or) 2018年4月19日

POPは、タイツがネタグッズなのでそれに合わせる形でヴィレヴァン風POPの作り方を参考にそれらしい物を作ってみました。手書きでやる自信が無かったので、青地の部分をたぬき油性マジック、それ以外の部分をふい字Pで「手書き風」にしました。ロゴは、フォントの形状がヴィレヴァンのロゴの物に似ているとして紹介されていたHelvetica Ultra Compressedベースで作成しています。

本物のヴィレヴァンPOPには値段は書かれていないようですが、今回は値段も一緒に入れてしまっています。

「完売しました」のお知らせをその場で書いたりするのに、何も書かれていない白紙の状態の物も用意しておけばよかったなあ……と思いましたが、後の祭りでした。

物を作るモチベーション維持のこと

技術書典への参加目的の1つは何か作る事へのモチベーションを高めるという事なのですが、今回はちょうど「シス管系女子3」の作業とタイミングが重なったため、これをモチベーションに作業を進めていました。

まんがでわかるLinux シス管系女子3 (日経BPパソコンベストムック)

posted with amazlet at 18.04.23

Piro(結城 洋志)
日経BP社 (2018-04-19)
売り上げランキング: 1,552

Amazon.co.jpで詳細を見る

元々は、この1週間後くらいの発売予定で作業スケジュールが組まれていたのですが、そうなると技術書典の直前くらいは作業の大詰めで何も他の事ができそうになく、技術書典合わせの何かコピー本を用意するという事ができない＆「シス管系女子3」も間に合わないという最悪の事態になってしまう事が予想されたため、〆切を早めてもらって発売日をイベントの前に変更、イベントにも新刊として持ち込むことができました。冒頭のプロローグの構成をギリギリで変更する事になったり、目立つ所では裏表紙の大野先輩のスカートのテクスチャが抜けた状態になってしまっているなど詰めの甘い箇所が残ってしまったりと、心残りもいくつかありますが、本来の価値である技術の本としては申し分ない物にできたのではないか……と自画自賛しています。

また、〆切が手前にずれた関係でイベント直前に2週間ほどの余裕が生まれ、コピー本は無理でしたがグッズを用意することができました。

なお、グッズ類は現在BOOTHで通販もしています。会場に来られなかった方や、会場で見落とされていた方は、こちらからご注文いただければと思います（あんしんBOOTHパック利用のため、こちらに個人情報が伝わる事はありません）。グッズがなければBOOTHを使ってみる事もなかったので、これも技術書典がきっかけで活動の幅が広がったという事だと言えそうです。今後は、過去に少数だけ生産したブックエンドもラインナップに加えられたらなあと思っています。

会場での反応のこと、新刊への反応のこと、今後のこと

毎度書いている気がしますが、会場では読者の方に何度もお声がけをいただき、大変ありがたかったです。紙媒体の商業出版物でしか読めない連載ということもあってか普段あまり感想を見聞きする機会が無く、こういう場で「1も2も持ってます」「3をずっと待ってました」のようなありがたいお言葉を頂けると、大変励みになります。

また会場外でも、今回の「シス管系女子3」についてはWeb上、というかTwitter上で今までにない量の反応を頂けている印象があります。2年前にWebサイトやTwitterアカウントの運用を開始して以降、自分にできる範囲で地道なプロモーションとも言えないようなプロモーションを続けてきましたが、その間湊川さんや沢渡あまねさん、ビタワンさん、ナツヨさん（※今回イラスト内のキャラクターの使用許可を頂いた方々）、他にも数多くのフォロワーの方々に度々告知やアピール文を拡散していただけていて、その影響がこうして目に見える形で表れてきたという事なのではないかと思っています。皆さんのご厚意に感謝するばかりです。

正業の傍らでの短いページ数の連載、しかも掲載媒体の日経Linux誌が月刊から隔月刊になったということで、今まで以上にページ数が溜まるスピードが落ちる事が予想され、次の本が出るとしたら一体どのくらい先になってしまうのか全く見えない状況ではありますが、今のこの気持ちを忘れないで、腐らず歪まず続けていければと思っております。皆さん本当にありがとうございます。（……と感謝の意を激しく表明すると「最終回」っぽさが漂ってしまいますが、別にそんな事はなく実際これから次の回の作業に入らなくてはいけないので、今後とも見守っていただけましたら幸いです。）

余談

どういう訳か、スペースにお越しの方に「マンガで分かるGitのスペースはどこですか」と訊かれてしまいました。それは僕じゃなくて湊川さんなんです……タイトル似てますが別作品です……

tmuxとかの仮想端末で複数の画面間でBashのコマンド履歴を共有すると同じ履歴が何度も記録されてしまう問題を解決する - Mar 04, 2018

このエントリはQiitaとのクロスポストです。

まんがでわかるLinux シス管系女子の74ページで、仮想端末（本編中ではtmux）の使用時に複数の画面間でコマンド履歴が共有されない問題の解決策として~/.bashrcにこういう記述を追加すると良いという話を書きました。

function share_history {
  # 最後に実行したコマンドを履歴ファイルに追記
  history -a
  # メモリ上のコマンド履歴を消去
  history -c
  # 履歴ファイルからメモリへコマンド履歴を読み込む
  history -r
}
# 上記の一連の処理を、プロンプト表示前に（＝何かコマンドを実行することに）実行する
PROMPT_COMMAND='share_history'
# bashのプロセスを終了する時に、メモリ上の履歴を履歴ファイルに追記する、という動作を停止する
# （history -aによって代替されるため）
shopt -u histappend

ところが、これを使用しているとコマンド履歴に同じ項目がどんどん溜まっていくという問題が起こるようになります。自分の場合だと、git commit -pしてからgit pushするとか、その前にgit pullするとかいう操作が多く、コミットの粒度も細かくするようにしているので、コマンド履歴があっという間にこれらのコマンド列で埋まってしまいます。

Ubuntuの場合だと~/.bashrcには最初からHISTCONTROL=ignorebothという記述がありますが、この指定は「直前のコマンド列と同じコマンド列の実行時にはコマンド履歴を残さない」という物です（正確には、これはHISTCONTROL=ignorespace:ignoredupsの省略形で、重複を記録しないという動作はignoredupsの効果です）。似た指定でHISTCONTROL=erasedupsという指定もあり、こちらは直前のコマンド列に限らずコマンド履歴全体の中で重複を排除する物です。しかしどちらを指定しても、上記の設定と組み合わせると期待通りの結果を得られません。何故なのでしょうか。

これは、HISTCONTROLの指定が一体何に対して作用するのかという事を考えると分かります。GNUのbashのバージョン4.4.18のソースコードを見てみると、ignorebothやerasedupsはどちらもメモリ上のコマンド履歴に対して、新しい項目を追加する時にメンテナンスを実行するようになっています。しかし、上記の設定を使用している場合、せっかくそのようにメンテナンスしたコマンド履歴はhistory -cで消去されてしまって、その後、重複を含んだままの履歴ファイルからhistory -rで履歴を読み込み直しています。これではignorebothもerasedupsも全く効果を得られなくて当たり前です。

ではどうすればよいかという話なのですが、とりあえずの解決策としてはこういう方法があります。

function share_history {
  history -a
  tac ~/.bash_history | awk '!a[$0]++' | tac > ~/.bash_history.tmp
  [ -f ~/.bash_history.tmp ] &&
    mv ~/.bash_history{.tmp,} &&
    history -c &&
    history -r
}
PROMPT_COMMAND='share_history'
shopt -u histappend

tacコマンドというのは、catの逆で最後の行から最初の行に向かってファイルの内容を出力するコマンドです。これを使ってファイルを逆順出力してから、重複行の最初の1行目を残して残りを削除して、それをまた逆順にして出力し直した後、出力結果で~/.bash_historyを置き換えています（1行の中でそのままリダイレクトでファイルを置換しようとすると元ファイルが消えてしまうので要注意！）。[ -f ~/.bash_history.tmp ] で一時ファイルがちゃんと作成されていることを確認して（何らかのエラーで一時ファイルが作成されなかった場合、そのまま続行するとコマンド履歴が消失して終わりになってしまいます！）、history -cでメモリ上のコマンド履歴を消去してhistory -rで読み込み直すようにするわけです。

これにより、同じコマンド列を何度も実行しても最新の1つだけが履歴に残るようになります。やりましたね！

もっとスマートなやり方もあるんだろうとは思いますが（例えば、BashではなくZshを使えば最初からこういう挙動になっているそうです）、自分がパッと思いつく解決策はこういう物でした、ということで主にシス管系女子読者の方向けの3年越しのフォローアップ記事として公開しておきます。

余談：tacの代用

tacはGNU coreutilsのコマンドの一つなのですが、macOSなどのBSD系の環境だとコマンドが存在しません。そのためtail -rで代替する必要があります。

WindowsでのFirefoxのビルドに使用するMozillaBuildだと、tacもtail -rもどちらも使えません。このような環境では、sedでの代替実装を使って以下のようにtacコマンドの代わりの関数を定義しておくとよいでしょう。

function tac {
  exec sed '1!G;h;$!d' ${@+"$@"}
}

説明すること、理解を求めること、自分が相手を理解すること、目を逸らさず自分の非に向き合うということ - Feb 26, 2018

sp.13b【ゲスト: pupupopo88】楽しいよちよちRubyistがコミュニティに貢献する理由 | しがないラジオの中でKPTの導入の話があった。KPTとは、今取り組んでいることに対して何かのタイミング（定期的に、が基本）でKeep（よかったこと、今後も続けること）・Problem（よくなかったこと、改善が必要なこと）・Try（改善案、Problemを取り除くための次の取り組み）の3つの観点で振り返りを行う手法のことだけど、これを使って会社の中で物事を改善していくにあたって「問題・対・私達」という姿勢が大事という事が話されていた。それで思い至った話なんだけど。

そもそもなんで敢えて「問題・対・私達、という姿勢で取り組まないといけない」なんて事を言わないといけないのか。言い換えれば、なぜ敢えてそういう風に言っていかないと、我々は、すぐに「えっ困ってる？ それ君個人の問題だよね、俺ら関係ないよね？」と考えてしまうのか。

我々って誰だ。KPTでの改善が必要なくらいに、問題が解決されないままになってしまっている集団に属している人々、だ。なぜ問題が解決されないままになってるのか。誰もが自分で責任を引き受ける事から逃げ続けているからだ。自分で責任を引き受けるとはどういうことだ、「それ君個人の責任だよね」と言うことと何が違うのか。まったく違う。「それは君個人の責任じゃないね。そういう事が発生してしまう状況を放置してきた我々（その一員である自分）の責任だね。だから私もこの問題の解決に取り組まないといけないね」、こういう姿勢が要るってことだ。

「問題・対・私達」という考え方で問題に取り組むためには、今まで個人に責任を押しつけて自分は無関係だと無視を決め込んでいた自分を改めないといけない。そういう駄目だった自分がいたという事実に向き合わないといけない。

しかしなぜこうも、我々は問題を個人の責任に帰結しようとしてしまうのだろう。僕は、「そういう教育を受けてきたから」「大人がそうしているのを幼い時分から見てきて、そうするのが当たり前と学んできたから」なのではないかと思っている。

こういう話題になったときに僕が決まって思い出すのは、幼い頃の「言い訳するな、他人のせいにするな」と「怒ら」れ「反省を強いられた」体験だ。いや、事実としてそうだったとは限らなくて、主観的にはそう感じられたという事なんだけど。いちいちハッキリ詳細に覚えているわけではないけど、自分の思う正義とか道理とかがあって、それに反した事を頭ごなしに押しつけられて、弁解の余地も与えられなかった、そんな体験の記憶がある。ちゃんと自分が悪かったと納得していたら、こういう記憶の残り方はしなかったのではないだろうか。納得できないままただ反省の言葉を述べることを強いられた、という終わり方だったからこそ、そう記憶しているのではないだろうか。

僕が度々紹介している本で、反省させると犯罪者になります（著：岡本茂樹）という本がある。というか、「反省」というフレーズが関わるような場面での僕の考えや発言のかなりの部分はこの本の影響を受けている。刑務所で犯罪者の更生に関わっていたという人の書いた本なんだけど、「形式的な反省を重視して、本人の納得を軽視する」事は何の解決にも改善にもならない、なぜなら本人が納得しないまま反省のポーズを取ることだけを求めると、処世術としてポーズを取ることだけを覚えるからだ、というような事が書かれている。

そこから考えを発展・一般化させると、こういう事が言えるのではないだろうか。
形式的な反省を強いることは、問題の本質と向き合わずにただその場をやり過ごす（反省のポーズを示す）という処世術や、それを良しとする姿勢を養う。
問題の本質と向き合わずやり過ごす最も簡単な方法は、問題の発生をその問題に直面した個人の責任に帰結させること。
問題が解決されることそのものよりも、「責任を認めた個人がいて、その人が反省して以後改めると言った」ということの方にばかり注目する、そうして「やり過ごす」事が重なっていく。
その結果として、様々な問題が解決されないまま放置され続け、深刻化していくのではないか。
仕事の現場以外での社会の問題、例えば生活保護受給者の自己責任論も、ワープア派遣労働者の自己責任論も、この延長線上にあるのではないか。

べつに、何でもかんでも組織や社会のせいにして個人の責任をうやむやにせよと言いたいわけではない。問題の本質を深掘りしていくと、組織やシステムのせいである場合も、個人のせいである場合も、どちらもありうると思ってる。大事なのは、「個人のせいにすればいい」あるいは「システムのせいにすればいい」のどちらか片方に決めつけてしまうという思考停止、をしないこと、ちゃんと問題の本質を理解すること、だと思う。

人には防衛機制という物がある。本当に自分に責任がある事でも、まずは責任転嫁して「自分のせいじゃない」と考える傾向がある。そのため、認知を歪めて世界を自分に都合のいいように解釈してしまう。そしてこれは、問題を起こした人本人だけでなく、その人に関わる周囲の人にも同じ事が言える。その問題が引き起こされた原因はもしかしたら、自分（周囲の人）が属しているシステムの方にあって、その人本人はたまたまその皺寄せが表出するときに居合わせただけなのかもしれない（し、そうでないかもしれない）。問題の本質に近付くためには、双方の対話を通じて慎重に認知の歪みの存在を炙り出して、それを取り除いていかないといけない。どちらか片方でもその姿勢が欠けていれば、途端に本質から遠ざかってしまう。

本質に辿り着いていないままの状態でする議論も対策も、すべて無意味だと僕は思う。本質と離れた状態のままで議論しても、本質が分かっていない分、必ずその結論には歪みが生まれる。プログラミングで言えば、ロクな調査もしないでworkaroundを重ねるのと同じだ（こういうのをカーゴ・カルト・プログラミングと呼ぶという事を僕は最近知った）。問題の真の解決を図るためには、物事や世界を良くしていくためには、問題の本質と徹底的に向き合う事から逃げてはいけない、と僕は思う。

偏見、決めつけ、思い込み、認知の歪み、自分はそういった物に影響され間違った事を度々してしまう残念で平凡な人であるという事を、歳を重ねるごとに思い知らされる感じがある。「できた人」「有能な人」では決してないから、「そういう駄目さをカバーしてちゃんと問題の本質に近付くために」いろいろ工夫して仕組みを作っていかないといけない、そんな気がしている。

僕が常々「正確な説明」とか「分かりやすい説明」とかを心がけているのは、そういう思いが根底にあるからなのではないかと思う。本質の理解を避けて表面的な丸暗記だけに留めてしまうと、応用が利かず、教わったたった一つのやり方を、本来適用するべきでない場面にまで適用してしまい、事態を悪化させてしまう危険がある。そう思っているから、僕はシス管系女子ではできる限り「おまじない」的な思考停止を促すような説明を避けているつもりだ。

別の事例で、僕が公開しているコードに寄せられたプルリクエスト に対して、たった1行だけの変更を入れるか入れないかでコメントのやり取りを2～3往復要したというのもあった。Closeする事だけに着目すれば「まずマージして、その後勝手に直す」という対応を取る所だろうけれども、相手が「これは不備ではなく意図的なものだ」という説明をしていたので、これは双方の意図に食い違いがあるのではないかと思い、改めて自分の意図を丁寧に説明して、相手の誤解が解けた事をもって初めてマージするという事をした。余計な手間をかける事に何の意味があるのかと思う人もいるだろうけれども、自分の方がむしろ間違っている可能性もあると考えると、その可能性を排除しないまま自分のやり方を押し通す事が最良とは思えなかった。

こういうのは、難易度が高い事というよりはとても面倒な事で、色々な事に忙殺されているとなおざりにされがちなのだろう。教育の現場なんてその最たる例で、一人一人の児童に寄り添って丁寧にやってたら成り立たないのだろう、だから前述の僕の嫌な記憶は「学校」とセットになっているんだと思う。

状況が許す限り、僕は問題の本質の理解を蔑ろにしたくないし、それと表裏一体で、本質の理解を蔑ろにしなくても済むように、本質にきちんと向き合える状況を維持していきたいものです。