Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/245: 1 2 3 4 5 6 7 8 9 »

「なぜ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信者だった頃の何かが残ってたんだなあ、と改めて思い知らされて、感慨深い思いをしたここ数日だったのでした。

Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか - Jun 16, 2020

1つ前のエントリにちょいちょい追記してるんだけど、見通しが悪くなってしまったので別エントリにした。

blacklistをblocklistにするとか、master/slaveを別の語に言い換えるとかの変更は、一体誰のためのもので、どういう意義があるのか? という問いに対して、1つ前のエントリを書き始めた時点でまだ自分は完全に腑に落ちる理解ができていなかったように思う。

その後、観測した反応や他の人による同じ件への言及を見ていて少しずつ、表題の話が腑に落ちるようになった。と同時に、改めて、先の言い換えを推進する流れの妥当性の怪しさを感じた。

自分がどう理解しどう腑に落ちたのか、今どのような疑問を持っているのか、を記録のためにまとめる。

続きを表示する ...

ポジショントークに騙されないようにしたいし、狭い視野でポジショントークじみた極論を言うよりも、メリットとデメリット両方を把握した上でソフトランディングを図っていきたい - Jun 06, 2020

ツイッターでつぶやいてた話

匿名と実名、どちらか一方を称揚する発言に対する評価の話

ネットは実名であるべきなのか匿名であるべきか、という話は何年かに一回くらい目にする議論な気がする。

自分は、「Piro」というハンドル(ペンネーム)で、匿名でWebを使い始めて、「OSSのライセンス文には本名を書かないといけないらしい」という誤解があって途中から実名も公表するようになったので、実名のメリットもデメリットも、匿名のメリットもデメリットも、全部一通り我が事として体験してきたと思う。

その上で思うのは、「匿名の連中は無責任だから全員実名を強制するべきだ」「いや匿名の方がいい、実名を使いたがるやつは売名目的だから出ていけ」みたいな、「自分がどうするか」ではなくて「みんなどうするべきか」でどっちかに寄せたがる発言をする人や、そういう言説は、あんまり信用しちゃいけないな、ということ。

  • 確かに実名の公表には、「子供もいないし子育てもしたこともない人が教育論を語っている」「社会に出たこともない人が仕事論を語っている」ようなまやかしを防ぐ効果がある。それに「馬鹿な事をしないように慎もう」と思わせる一定の力もある。
    • けれど、馬鹿な事をやらかす人は実名でもやる。Webが一般的になる前のパソコン通信時代やネットニュース時代に一番ヤバい事をしていたキチは、実名だったという。実名公表は、最後の一線として究極的には機能しない。
  • 確かに匿名の言論には、「既に知名度のある人が、社会的地位を濫用して道理の通らぬ事を押し通す」事を阻む効果がある。「その人の社会的地位から切り離された、純粋な言論だけでやり取りされるフェアな世界」がもたらされるように見える。
    • けれど、それは同時に「過去何度も同じやらかしをしてきた人が、素知らぬ顔でまた同じやらかしをする」「過去何度も他人を騙してきた人が、次の獲物を狙う」「その時その時でコロコロと言う事が変わり、理屈に一貫性がなく、確たる裏打ちがあってそう言っている訳ではない、という事実を包み隠す」ことをも容易にする。「フェアな世界」に見えていた物は、詰まるところ、相手を口八丁で言いくるめる技に長けた人が有利なだけの世界に過ぎない。

まずかつての自分のように、こういうそれぞれのデメリットを分かっていなかった(言葉で知っていても実感はしていなかった)時点で、わかりやすいメリットだけ並べて「だからみんなそうするべきだ」って言ってる人は、視野が狭く考えの浅いアホなので、信用するに値しない。

また、匿名のデメリットも実名のデメリットも分かった上で、デメリットを伏せてメリットだけ並べて「だからみんなそうするべきだ」と言ってる人は、自分の持つ武器(社会的地位なり、相手を言いくるめる術なり)が最大の効力を発揮し、自分の持つ不利(社会的地位の無さなり、理屈のガバガバさなり)を最大限ごまかすのに、たまたまそっちの方が都合がいいからそう言ってるだけの事が多い(そういう発言を「ポジショントーク」と呼ぶ)。自分の都合のいいように世論を動かして自分が利益を得たいだけで、煽られた他人が実際に被る不利益の事なんか知ったこっちゃないのに、それを隠してる不誠実な人なので、これも信用してはいけない。

善意のアホが悪意のポジショントーカーに乗せられてる事もあるし、アホが無自覚にポジショントーカーになってしまってる事もある。結局ポジショントークをする人にロクな人はいない。「ポジショントークをしない事」イコール「信用に足る」という事では必ずしもない(信用する十分条件ではない)けれども、ポジショントークをしてる人の事は真っ先に「あ、この人は信用しちゃ駄目だ、信用しない人リストに突っ込んじゃっていいや」とバッサリ切ってしまっても、大抵は不都合がない(信用する必要条件ではある)。今の自分の感覚をなるべく正確に言い表すと、こんな感じになると思う。

続きを表示する ...

性役割が逆転された世界、の描き方に現れる視点の違い - May 08, 2020

ほんとに「女が強い時代」って、こういうこと? 「女が支配する社会」を描いたディストピア作品3選 - wezzy|ウェジー という記事が話題になっているのを観測した。自分の観測範囲では批判的な感想が多かったように感じるけれど、それは「この記事を批判的に見た人が、記事を紹介し、同様の批判的意見を紹介している様子」を観測したせいかもしれない。

男女の性役割逆転というのは昔から度々描かれているようで、家畜人ヤプーはその代表的な一作と言えるようだ(僕は江川達也氏による漫画版だけ見た)。僕は先の記事に挙げられている3作品はいずれも未見だけれども、近年の観測範囲でも、立て続けに2作品ほど男女の性役割逆転を描いた作品を見かけた。ただ、先の記事の3作品や「家畜人ヤプー」と、僕の観測した2作品とでは、描き方にどうも差があるように感じられた。

 

僕の観測した1作目は「貞操逆転世界」(原作:天原、漫画:万太郎)で、主人公が「性」に関する事だけ男女の性役割の逆転した世界に迷い込んでしまうという内容。先の記事で紹介されている「軽い男じゃないのよ」とプロットは似ていて、「街中に無意味に男の水着の広告が溢れている」のような描写も共通しているようだけど、設定としては以下の点が大きく異なる。

  • 主人公は男性ではなく女性。
  • 主人公は社会人ではなく学生(高校生)。
  • 体力・体格差などの肉体的な性差は逆転していない(性的な消費・被消費の関係以外は現実世界を踏襲している)。

これらの事から、本作は「今まで優位な立場だった人が、劣位の立場に戸惑う」という内容ではなく、「今まで消費される性の立場だった人が、消費する性の立場に戸惑う」という内容になっている。

敢えて「優位・劣位」と書かなかったのは、本作では「高校生」という、性差が経済的な差や権力差にあまり結び付いていない年代の視点であるために、必ずしも「性役割が逆転したら女性が優位になっている」とは限らないからだ。

続きを表示する ...

「もっと考えろよ」「想像力なさすぎだろ」みたいな言い方を僕はしたくないなっていう話 - May 06, 2020

IQが20違うと会話が成立しない、みたいな話は昔からよく聞くけど、そもそも「自分自身が一般よりIQが高い天才です、一般人と会話が通じなくて困ってます」って当事者になってることがあんまり無いと思うので、実際そうなのか?ってのはよく分からない人の方が多いんじゃないかと思うんですよね。僕もそのクチで。

ツイッターみてたら、そういう場面において、一般よりもIQが高く「ギフテッド」と呼ばれる人の側が当事者として実際どう感じているのか、をご自身の体験から詳しく説明されている記事が流れてきて、読んでみたら、前々から「きっとこういうことなんだろうなあ」と考えてた事とわりと合致する話が書かれてたんですよ。

というのも、これって「自分がアニオタで、アニメにまったく興味がない人に話が通じない」みたいな場面にすごく似てるなって思ったんですよね。

  • 自分はその作品にも、作品が生まれた背景にも、今のオタク業界にも色々詳しくて、業界用語もめっちゃたくさん知ってる。オタク仲間同士なら呼吸をするように自然に会話が成立する。
  • でも、そういう前提を共有してない人と話すとなるとものすごく大変。好きな作品の好きなキャラの事を語ろうとしても、作品の説明に時間がかかるし、キャラの説明に時間がかかるし、「◯◯という作品の××というキャラのように……」みたいに言うとその「◯◯」や「××」自体も詳しく説明しないと分かってもらえないし……

こういうの、すごく身に覚えがあるんですよね。「オタク知識」の話でなくても、社会人だったら自分の業務分野・専門分野の知識とか、自分は滅茶苦茶詳しくてお客さんは全然詳しくないので説明に苦労するってのはすごくありふれた話だと思うんです。自分も今まさに、テクニカルサポートの業務でお客さんに説明する場面でそういう事はよくあるし、Linuxのシェルコマンドの解説漫画を描く上で大変な事もまさにそういう事だし。

で、「自分側が知識がありすぎて、知識が無い側の人に話が通じなかった」体験をそういう風に想起できる一方で、「自分側の知識レベルや頭の回転速度が低過ぎて、有能な相手がする話の内容がまるで理解できなかった」体験もまた、自分には想起できるんですよね。学校で先生の言う話が分からなくて授業についていけないとか、仕事の上で先輩の話しに全然ついていけないとか。むしろこっちの方が多いくらい。

なので、自分としては「IQが20も違うと会話が成立しない」という話の両方の当事者の感覚を想像しながら、先の記事を読んだんです。

それで思ったのが、「この記事を書かれた方(ギフテッドの人)には、もしかして、自分の話を相手に理解してもらえなかった経験はあっても、相手の話が自分には理解できなかった経験が無かったりするんだろうか?」という事で。

そもそも記事自体が「IQが高い側の弁明」という体裁だから敢えてそう書いたのかもしれないんですが、「やばい、相手の言ってることがまるで自分には理解できない。どんなに説明されてもチンプンカンプンだ」という感覚が、あまりその記事からは感じられないような気がして。

続きを表示する ...

僕がある問題について自分がどう考えるかとその背景を書いているのは、フルブレーキングの副産物に過ぎない、という話 - Dec 08, 2019

blogとの付き合い方について あるいはなぜ自分がblogを書き続けているかについて - podhmo's diaryという記事の中で、僕の事が以下のように評されてました。

Piro_orさんはある問題について自分はこう考えるということの表明とその背景説明がとても上手な印象です。

これを書かれた方ご自身は「自分の思った事を書く」という事が今あまりできていないそうで、それで「できている人」として例に挙げて下さっていて、尊敬しているとまでおっしゃって頂いていてなんというか恐縮です。確かに、自分でもそういう事をよくしているような気がしてます。

ただ、自分がそうしている事の動機がどこにあるのかという事を改めて考えてみると、必ずしも目指すに値する対象とは言えないんじゃないだろうかという気がしています。

続きを表示する ...

誤用の心理的安全性 - Jul 10, 2019

いやね、「みんな仲良くぬるま湯状態」は心理的安全性とは違うとはみなさん言いますけど、それじゃあ「口の悪いベテランが欠点をあげつらって罵倒しまくってて、それに新人がビビってる状態」は心理的安全性があるのかないのか、って話なんですよ。

 

最近「心理的安全性」という言葉をよく目にします。

最近あった7payのトラブルは、パスワード再発行の仕様がザルで、誕生日とメールアドレスさえ分かれば第三者がアカウントを乗っ取り放題だったせいで、最低でも900人に計5500万円以上の被害が出た上に個人情報も漏洩した恐れがある、という事件でした。以前から一般ユーザーによって危険性が指摘されていたという話も、開発に関わった人が良識を持っていれば絶対に指摘していただろうという話も聞かれて、そういった技術的・倫理的に正しい指摘がきちんとエスカレーションされていさえすれば防げたかもしれない事件だった、なのに誰も止められなかった。何か言えば上司に「余計な事を言って仕事を増やすな」とか「スケジュールを遅延させる気か」と詰られると思うと、皆我が身かわいさに「正しい指摘」を引っ込めざるを得なかった、のではないだろうか。正しい事を正しいと言えなかったがために起こった事故なのだろう。……というような話がまことしやかに囁かれています。

そういう事を防ぐために、正しい事を正しい・間違っている事を間違っているときちんと指摘してよい、指摘しても懲罰的人事などの理不尽な形で不利益を被る事は無いという意識が、メンバー全員で共有されている状態。挑戦に失敗しても致命的なダメージを被らないで済むというセーフティーネットがあるために、意欲的に挑戦してより良い成果を生み出せる状態。みんなで一丸となって、やるべき事をつつがなく遂行できる状態。そういうのを、心理的安全性が高い状態と言うそうです。

詳しい話は心理的安全性ガイドライン(あるいは権威勾配に関する一考察)とかそのあたりの記事を参照してください。

 

その「心理的安全性」なんですが、急激に流行りだしてバズワードと化したせいか、本来の意味とは異なる意味で使われてしまっている場面があるそうです。具体的には、「批判されると萎縮してしまって何もできなくなる。だから、相手の事を批判してはいけない。みんな仲良く、和気藹々。それが心理的安全性が高い状態である」というような使われ方。

先の説明から続けて読めば、これがどうして「間違った理解」なのかは明白ですよね。「本来の心理的安全性」は筋の通った正しい指摘を引き出す物のはずなのに、「誤用の心理的安全性」では、そういう正論ベースの指摘は「和を乱す物」として否定され得る。明らかな穴があっても、「彼がせっかく頑張って考えたプランなんだから、それでやろうよ」と、穴に目を瞑ってナアナアで済ませる。そうして幾つもの誤りを見過ごして破滅に突き進む。我々はこれを言い表す的確な言葉を既に知っています。「事なかれ主義」です。その単純な言い換え語として「心理的安全性」を使うというのは、確かにいただけません。

 

でもその一方で、この誤用をしたくなる気持ちを僕は否定もしきれないんですよね。何故なら世の中には、「論理的に正しいかどうかがすべて」を信条に、人の神経を逆撫でしたりこき下ろしたりする人がいるからです。ただの観測範囲の問題かも知れないんですけど、「(IT)エンジニア」にはそういう人が目立つような印象が、僕にはあります。

続きを表示する ...

「お疲れ様」が失礼とかそういう話 - May 12, 2019

自分は「ご苦労様」というフレーズが「目上の人に使うのは失礼な言葉だ」「代わりに『お疲れ様』なら言ってもいい」と言われるようになった過程を見てきた世代の人間なので、「お疲れ様」が今「目上の人に使うのは失礼な言葉だ」と言われるようになっているという話を見かけて、まあ驚きましたね最初は。

「ご苦労様」が咎められていた頃にも「そもそも、目上の人に『ご苦労様』と言う例は昔からあった」とか色々反論は目にしましたが、結局みんな馬鹿馬鹿しいとは思いつつも、それで失礼だと言われたら怖いとビビって「ご苦労様」を目上の人には使わなくなったと思うので、「お疲れ様」もそのうちみんなビビって使わなくなるのかもしれません。

 

捏造マナーを広めてマッチポンプで仕事を作り出す失礼クリエイター(自称「ビジネスマナー講師」)に踊らされるのは癪だなあと思いつつ、しかし、お疲れ様もご苦労様も目上の人に言うのは失礼だというのは案外当を得ているのではないか?という気がする部分もあります。

というのも、「お疲れ様」が目の敵にされるようになった時にも「それは目上の者が目下の者の労をねぎらう時の言葉だからだ」と説明されていて、今回の「お疲れ様」でも同様の言われ方をしているようなので、そもそも「労をねぎらう」というのが「上から目線」の行為という事なのではないだろうか、だとしたら、目下の側からねぎらいの言葉が発される事自体が失礼扱いされるのは致し方ないのでは、と思ったのですね。

現代で「お疲れ様です」が発されるのってどういう場面なんでしょうか。「労をねぎらう」と一言で言ってしまっているケースでも、分析してみると実は色々なコンテキストがあるんじゃないでしょうか。

  • その人が自分のために労を割いてくれたので。
  • その人が自分のしたミスの尻拭いをしてくれたので。
  • 自分が関わる事ではないが、その人が何か仕事をこなしたので。
  • 見るからに疲れている様子なので。
  • すれ違いざまの挨拶として。メールの書き出しとして。

相手が労を割いてくれたという事だと、「ありがとうございます」という表現がより適切な気がします。

相手が尻拭いをしてくれたという事だと、「ご迷惑をおかけして済みません」の方が適切に思えます。

自分の関係ない所でその人がした事に対して、何も言わないのは失礼だから何か言いたいという時は、「素晴らしいお仕事です」とか「敬服致します」とか言える気がします。

見るからに疲れている様子なら、「お疲れのご様子なので今日はどうぞお帰り下さい」とかなんとか。

すれ違いざまの挨拶だと、その日の初回の遭遇だったら「おはようございます」「こんにちは」「こんばんは」が適切な気がします。2回目以降の遭遇では、どうなんでしょう。自分は「会釈」「黙礼」でいいと思いますが。ちなみに、最近読んでる「総務部総務課 山口六平太」では、典型的な日本型大企業の中で平社員が社長に遭遇したという場面では平社員が黙礼するだけという描写が多い印象があります。

 

こうして改めて「お疲れ様」「ご苦労様」の言い換えを考えてみると、他の言葉がより適切な場合もあるし、そもそも適切な・しっくりくる他の表現が無い場面もある、という気がしてきました。

「ご苦労様」って、かなり広い場面で使えるユニバーサルな言葉という気が僕はするのですよね。「それさえ言っておけばまあ大丈夫」というカテゴリの言葉というか。語彙力が無いと、それだけで全部済ませたくなっちゃうというか。だとすると、個別のコンテキストに応じた適切な言葉の使い分けを面倒臭がって、万能のフレーズ1つであらゆる場面を済ませてしまう怠惰さは、言われた相手の側にするといい気がしない、というのは一理ある気がします。少なくとも自分は、「自分のためにわざわざありがとうございます」「自分の不始末でご迷惑をおかけしてすみませんでした」等が適切な場面で「お疲れ様です」と言われたら、「なに他人事みたいに言うてんねん」とイラってなりそうです。「お疲れ様」が失礼となるケースがもし現実にあるとしたら、そういうケースが該当していそうな気がします。

そうでなく、しっくりくる表現が他に無いから「お疲れ様」が使われているというケース、挨拶やメールの書き出しのような場面が問題だとするなら、そもそも「ねぎらいのフレーズ」を無関係の場面に流用したのが間違いだった、ということはないでしょうか。言った側は「流用したフレーズを以て挨拶しただけ」のつもりが、相手はそれを流用ではなく本来の意味の使われ方すなわち「目上の者が目下の者に対して言う言葉」と捉えたために、失礼と感じられた、という事だったりしないでしょうか。

だとしたら、もういっそのこと、既存の言葉を流用しないでその場面に適した言葉を新しく作った方が建設的ではないでしょうか。例えばこんな感じで。

  • 平社員が社長とエレベーターで乗り合わせた。黙っているのも変なので、挨拶する。「社長、きゆゎぶです!」
  • 部下が上司にメールを書こうとしている。相手がいつ読むか分からないので「おはようございます」と言うのも変だ。なので、こう書き出す。「めでぺづです、結城です」。

「ランダム 文字列」で検索したら任意の文字数のひらがなの文字列を自動生成できるページが見つかったので、これで作った文字列を造語として流行らせてみると面白いのではないかという気がしています。社内で流行らせた結果、うっかり社外の人にまで使ってしまうとどうなるか分かりませんが……もしかしたら案外世間で流行るかもしれないですよね。「拝承」みたいに。

Chrome Extensionsのマニフェストのバージョン3とアメリカの銃規制 - Jan 29, 2019

ちょっと前に話題になったChromeの拡張機能のAPIの新バージョンの案の概要を把握するために、変更点のまとめの部分だけを読んでみた。全訳するのも大変なので、適宜つまみながら。


動機

APIや権限の仕組みに対して大規模な変更を行う物なので、マニフェストバージョンを3に上げる。拡張機能が実際に使用しているAPIや権限の中には、パフォーマンス、セキュリティ、プライバシー、および人間工学的な観点から、ユーザー体験を低下させている物が多数ある。新しいマニフェストバージョンではそういった負の影響を与える要素を一掃し、新しいAPIや機能だけを使えるようにする予定である。拡張機能の作者達に向け、移行を容易にするための明確な手順と、新基準に拡張機能を移行するに足る追加のインセンティブを用意するつもりである。

  • 目標: マニフェストV3では、安全・高速・プライバシーに配慮された拡張機能を容易に開発できるようにし、一方で、危険・低速・プライバシー情報の漏洩に繋がる拡張機能を開発しにくいようにする。拡張機能の品質を高め、ユーザーに積極的に勧めやすいような物にする。
  • セキュリティ: マニフェストV3に基づいて開発される拡張機能は、外部からの攻撃(その拡張機能を狙ってXSSを仕掛けてくるような悪意あるWebサイトなどからの攻撃)と、内部からの攻撃(悪意ある拡張機能)の両方に対して、より強力なセキュリティ機構を保証するのが望ましい。ユーザーは安心して拡張機能をインストールできることが望ましく、そのためには、その拡張機能が重大な損害をもたらし得ない事を保証する必要がある。その結果、自動および手動でのレビューをより容易にする。
  • プライバシー: ユーザーは拡張機能に対してより広範な制御権を持つことが望ましい。ユーザーは各拡張機能に対して、どの個人情報の使用を許可するかを制御できることが望ましい。
  • 性能: マニフェストV3に基づいて開発された拡張機能は、より高速になる事が望ましい。長時間動作するバックグラウンドプロセスは禁止されるべきである。APIは高速・効率的である事が保証されている必要があり、性能を劣化させるような誤った使い方がしにくいようなAPI設計となっていることが望ましい。

変更の概要

優先度1(最高)

  • バックグラウンドプロセスについては、イベントベースの永続的なバックグラウンドページから、Service Workersへ移行する
  • コンテンツのデータへのアクセスの制限については、activeTabスタイルの、実行時にのみアクセスが許可されるモデルへ移行する
  • リモートに置かれたコードについては、直接の実行を禁止する
  • クロスオリジンの通信は、コンテントスクリプトはWebページのスクリプトと同じルールに基づくこととして、拡張機能のページは過去にアクセスしたことがあるサイトに対してはクロスオリジンの通信を可能とする。
  • ホスト単位での権限の指定は、API自体の権限を列挙する permissions 配下でまとめて指定していたのを host_permissions に分離する。
  • PromiseベースのAPIとする

優先度2(高い)

  • Webからアクセスできるリソースについては、拡張機能の実行コンテキストから切り離された安全な領域に登録されたリソースを、動的に生成されるURLで読み込む形とする。
  • 動的なコンテントスクリプトについては、それに特化した権限の仕組みを設ける。

APIの変更

  • webRequest は、リソースの読み込みをブロックする使い方を制限する
  • 代わりに、読み込みブロックのための宣言型の新しい仕組みとして declarativeNetRequest を設ける。
  • ツールバーの動作とページでの動作は、browserActionpageAction を単一の action APIに統合する。
  • chrome://favicon に関する権限をchrome.favicon APIに移す。
  • tabs, pageCapture, tabCaptureおよび desktopCaptureを単一のcapture APIに集約する。
  • オープンなWeb標準で定義された機能はAPIからは削除する。
  • ServiceWorkerベースのAPIへの更新。特に、いわゆるメインスレッドとして走る処理のための物。
  • 公に非推奨・廃止予定とされていたAPIの廃止・削除
  • その他、性能や利便性、人間工学的な観点での細かい修正。

以上、翻訳とメモの中間みたいな物でした。

この中で特に webRequestdeclarativeNetRequest に関わる部分は、chromeの機能拡張の変更について | 280blockerで詳しく解説されている。

コンテンツのデータへのアクセスについて、<all_urls>を廃止して、コンテンツに触れたければ必ずactiveTabの権限の範囲でできる事だけに制限するというのは、かなり息苦しくなるなあという感じがある。例えば複数選択されたタブのそれぞれについてコンテンツの内容を収集してきてクリップボードにコピーする、みたいな事はできなくなるという事だろうか?

Promiseベースにするというのは、FirefoxのWebExtensionsが既にそうなっているし、ChromeのAPIをそのスタイルに合わせるためのPolyfillも既に広く使われているようなので、妥当だと思う。

 

総じて、Chrome開発チームが思う所の「こうあるべき」という思想を前面に押し出した案だなと感じた。元々、Firefoxの拡張機能がXULとXPCOMでなんでもできたのに対して、無害そう・使用頻度が高そうなニーズに応える機能だけ取捨選択してChromeの拡張機能APIとしてまとめたのが、今からほぼ10年前。10年を経てさらに取捨選択を進めると同時に、新たに明らかになってきたリスクを改めて潰し直すというのが、マニフェストV3でやりたい事なんだろう。Googleのやり方を強硬的で独善的だと非難する向きもあるようだけど、それは今に始まった事じゃない「Googleの社風」なんだと思う。

Googleが認めるやり方での広告ブロック以外は認められないという形に結果的になっているのは事実のようだけれど、巷で騒がれている「広告ブロックを禁止するための陰謀だ」みたいな見方は深読みしすぎだと思う。多分Googleの人達はそこまで考えてなくて、彼らはきっと、性能劣化がとにかく嫌で、それに繋がりうる物をなくしたら結果的にこうなった、という事なんだと僕は思ってる。やっかみ混じりで悪意に取ったとしても、せいぜい「は? 俺らが熟慮して『これで充分じゃん』って考えた物なんだから、これで完璧でしょ? 文句の付け所があるわけ?(キョトンとした顔で)」くらいの事なんじゃないかな。

サイドバーAPIを頑なに付けないのも、要はそういう「は? そんなもんいらんやろ? ブラウザは最低限の機能だけでええやん、常時表示するカスタムUIなんて無駄なだけやん(キョトンとした顔で)」みたいな感じなんじゃないのかなと僕は認識してる。僕はツリー型タブを「脳内ワーキングメモリが極めて貧弱な自分でも、Webのブラウズ履歴を視覚的にその場に残して常に全体をざっと眺められるようにできれば、ワーキングメモリの小ささを補って人並みの仕事ができる」という使い方をしてるけれども、優秀なGoogleの人達は(※やっかみ)ワーキングメモリが広大で、そんな風にツールで補う必要がきっと無いから、それで必要性を認めないんだろう、と僕は思ってる。

 

速度以外のセキュリティについても、セキュリティが担保されるなら利便性はどうでもいいというのが彼らの本音であるように思う。いや、セキュリティ第一であるべきというのは一般的にもちろん正しいし、一般ユーザー向けに「セキュリティより自由度を」なんて言ってる人がもしいたら、アホだとは思う。「よく分かってる人・開発者向けにだけ裏道を残しておけばいい」とは言っても、大抵の人は自分が何をしてるか分からないまま自分の足を撃ち抜きがちで、しかもその事に気付いてすらいないものだから、そういう「パワーユーザー向けにだけ解放」が絵空事でしかないというのも分かる。

これって何かに似てるなと思ったら、あれだ、アメリカの銃規制に似てるんだ。アメリカは銃を所持する事が自分の自由を守る事とセットだという建国の精神だから、いくら安全のためとはいっても銃を完全に社会からなくそうとすると強い反発が起こる、っていう。

銃乱射事件が起こる度に出てくる「全米ライフル協会『(被害者が)銃を持っていればこんな事件は防げた』」というジョークを見る度に「アホやなあ」と僕は思っていたけれど、それを笑っていた僕自身もまた、リスクに目を瞑って、危険な武器を自分が手にできる自由を声高に叫んでいた人の1人だったのだな、と。自分自身が「ただのユーザー」から「自分の使う道具を自分で作り替えられる開発者」にステップアップできる余地があったから(他にも理由はあったけど)、僕はMozillaを使っていたし、「Chromeと同じになってしまった」「Mozillaはアドオンを殺した」なんて言われた後の今でもSuccessor Tabs APIコンテキストメニューのコンテキストのオーバーライドのように「安全」とのバランスを取りながら自由度を増す事に寛容な姿勢が垣間見えていて、方向性としてはまだそういう自由度を尊重してくれているように思えるので、それで僕はFirefoxを使い続けてるんだな。自分が独り立ちできた事の根底にあった「建国の精神」とガッチリ結びついてるから、僕は自由度をなるべく捨てたくないんだな。ということを、Chromeの拡張機能マニフェストV3のいざこざを見ていて改めて意識させられた。

 

そういう感じでなんかこうセンスというか目指すところが合わないので、僕は今後も当面Chromeに移ることは無いかなと思っているのでした。

「じゃあサイドバーAPI付きのChromiumベースのブラウザならどうなんよ、Operaとか」っていう疑問も当然浮かぶわけだけれど、ベースになってる物の設計思想が決定的に自分とマッチしてない(と僕は思ってる)以上、その上に組み上げられた物も自分にはマッチしないんじゃないかなあという見方をしてしまうし、それにChromeチームの意向で梯子を外されてOperaも他のChromiumベースの製品もみんなおじゃんになっちゃいましたみたいな未来もあるんじゃないかくらいに悲観的に考えてるので、やっぱりその路線も無しというのが今の自分の考えです。

#しがないラジオ 2 Advent Calendar 2日目:OSSやると英語の訓練になったり公表できる実績積めたりするんじゃないかなって話 - Dec 02, 2018

しがないラジオ2 Advent Calendarをご覧の方々、初めまして。しがないラジオsp.31でゲストとして出させて頂いた、Piroと申します。自分がどういう背景を持つ人間かについては、しがないラジオの当該回を聞いてみて頂けましたら幸いです。前後編で3時間はありますが……

しがないラジオ2 Advent Calendarの2日目は、「しがない」エンジニアになるためにあると良さそうな「人にアピールできる実績」の積み方についてのお話です。

つよいエンジニアって何だ?

さて。しがないラジオに限らず、エンジニア系Podcastを聞いているとよく「つよいエンジニア」というフレーズを耳にする印象があります。

強いとはどういうことか。人によって解釈にブレはありそうですが、「口だけじゃなく、形として実績が目に見えている」というのはわりと共通して言えそうな気がします。例えば、Googleのような著名企業でサービスやプロダクトの開発を主導しているとか、著名なOSSの作者(開発チームの一員)だとか、そういうプロジェクトに外部からパッチを提供しているとか。あるいは、何かの技術イベントを主催してるとか、技術書を(特に、商業出版の書籍を)書いてるとか。

で、いつかはそうなりたい、そうなるにはどうすればいいんだろう、と憧れを抱いている人が多いのかなと思います。

僕がそういう方にお勧めしたいのが、OSSの開発やコミュニティに実際に関わってみてはどうでしょうか? という事です。既存のプロジェクトに関わるのも、自分で始めるのもどちらでもOKです。

「いやいや、ああいうのはつよいエンジニアの人がやる事で、自分みたいなペーペーがやるなんておこがましい……」そんなふうに思っていませんか? だとしたら、それは因果関係が逆です。むしろ、OSSの開発に関わったから、その人は結果的につよいエンジニアになった、という風に考えてみて下さい。

続きを表示する ...

Page 1/245: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき