コミュニケーションへの苦手意識の克服とその先

3月末を最終出勤日として有休消化に入るため、全社集会で退職の挨拶を済ませて来た。約2年半勤めて、惜しまれるような雰囲気で、送別会もやって貰えるらしい。要するに普通の退職プロセスなのだけれど、私の人生を振り返ってみると「まともなプロセスで友好的にコミュニティを離れる」ことができたのが今回が初めてだと気づいた。

高校の部活も、最初に入った大学も、次の大学のサークルも、最初に就職した職場も、逃げるように途中で辞めて来た。毎回コミュニティの人間関係が徐々に悪化し、いづらくなるパターンだった。今までのコミュニティで人間関係が上手く築けなかったのはコミュニケーションに関するマインドセットに問題があったからだと今では認識している。何がまずかったか。

「浅い」コニュニケーションを軽視するのをやめる

これが一番まずかったのだけれど、昔の私は「浅い」人付き合いと「深い」人付き合いを区別し過ぎていた。つまり、お互いの価値観に高度な一致が見られ、趣味、学問、芸術などについて深い話ができる人間関係に価値があり、そうでないものに価値がないと考えていて、あまつさえ、浅い人付き合いを馬鹿にするような発言を積極的にしていた。これは今になっては完全に間違いだったと言える。

コミュニティでの人間関係は挨拶に始まって、雑談やコミュニティ運営に必要な(職場であれば業務上の)やり取りをただ積み重ねることにまず価値がある。話が盛り上がるに越したことはないけれど、価値観の高度な一致など必要なく、「そこにやり取りが交わされていること」自体に大きな価値がある。そういったやり取りを積み重ねる先に「信頼」が蓄積され、信頼のある人間はコミュニティで尊重される。

また「価値観の高度な一致」という幼稚な幻想を捨ててみると、人間はそれぞれに面白い。たとえ親密な関係にならなかったとしても人との会話それ自体が楽しく、一期一会的な味があると気づく。

コミュニケーションを恐れない ―普通の人はそんなにコミュニケーションが得意ではないと知る―

昔の私は、自分は世の中の普通の人と比べてコミュニケーション能力に劣っていると感じていて、例えば世間話などで上手く話題を選べないことなどを恐れて、挙動不審に陥っているような節があった。

今、特にコミュニケーションに苦手意識を持たない立場になってみると、実際あらゆる意味でコミュニケーションが得意で、そこを強みにしているような人はそんなにいないし、何らかの不安だったり苦手なコミュニケーションパターンを抱えている人がほとんどのように見える。

そういう適切な視座に立つと、上の世間話での話題が上手く選べなくて挙動不審になるとかの話も、そもそもコミュニケーションが得意な人が相手ならば自分が上手く喋らなくても話は弾むはずで、そうでないなら相手も自分と同程度以上にコミュニケーションが苦手ということなので、最善の努力をした上で話が盛り上がらないならそれは必ずしも自分が原因ではないと落ち着いて考えられるようになる。

なので、コミュニケーションが特に得意ではなくても、劣等意識を感じる必要はない。恐れのないテンションで臨むと、逆に他者の不安な気持ちが「見える」ようになって、場合によっては適切なサポートを入れることもできるかも知れない。

無難なコミュニケーションのその先へ

主に上の2つの観点のマインドセットの変更によって、今はコミュニケーションへの苦手意識がなくなった。これは大変な進歩なのだけれど、その一方で、無難なコミュニケーションの「型」に終始し過ぎているというのが最近の課題だ。

自分の中の尖っている部分を出したり、人と揉めたりすることへの忌避意識を少しずつ外していって、もう少し自然体で人と話せるようになりたい。今の私は人とのコニュニケーションを恐れてはいないけれど、過去の自分のように人間関係で失敗したくない、人から信頼される「まともなコミュニケーション」をしなくては、という点には強い恐れを抱いている。その恐れを解くことができればより本来的な自己をもってコミュニケーションに臨むことができるようになるはずだ。

30歳業務経験3年未満Web系エンジニアが転職エージェントを使って普通に転職したメモ

最近転職エージェントを使って転職したので、攻略や感じたことについてメモを書きたい。Web系エンジニアについて、社名を具体的に出すようなタイプの意識高い転職エントリは多いけれど、普通の転職活動の情報が少ない印象があるので、そういった参考になれば良いと思う。

転職概要

  • 中途でWeb開発の仕事を始めたジョブチェンジ組で、業務経験約2年半、年収400万円台から500万円台にアップさせるつもりで活動した
  • スキルレベルはRailsAPIモードのバックエンドとSPAのフロントエンドが書ける、インフラはチョットダケワカル、新機能開発プロジェクトの経験は比較的豊富、という感じ
  • 転職エージェント経由で15社書類応募して3社に内定を貰い、年収約90万円アップの条件で内定承諾した

転職エージェント

  • 市場感や面接での話し方のコツなど何も知らない状態だと色々と教えてくれるので助かる
  • エージェントの経験や能力の個人差が非常に大きい
    • レバテックやGeeklyのエージェントは全然頼りにならない感じだった
    • エージェントを使って転職したい方は私に連絡くれれば有能なエージェントの情報教えます
  • スケジュールの調整等を代わりに全部やってくれるので、多数の選考を同時進行しやすい
  • 企業研究に役立つ情報も色々と教えてくれる
  • 積極採用している企業の求人を紹介してくれるので、企業側の採用計画とのミスマッチが起きづらい
  • 内定時に年収の3〜4割の料金が採用企業に発生すると言われているので、エージェント経由以外の応募者と比べて採用判断で不利になりそう
    • 逆に言うと、内定獲得についてエージェントとの利害関係が強固に一致しているため、一緒に内定を取りに行く仲間として頼もしいとも言える

市場感

  • Web系エンジニアは圧倒的に売り手市場という感じだった
  • 業務経験3年程度(中級者)以上であれば引く手数多だと思う
  • 上場している有名企業を中心に受けたけれど書類と面接の通過率は予想以上に良かった

応募数

  • 15社に書類応募して13社通ってしまい、面接スケジュールが過密になってしんどかった
  • 本当に興味がある企業5社程度の応募で良かったと思われる

職務経歴書

  • そこまで詳しく読まれないことを前提として、主要なアピールポイントを上の方に分かりやすくまとめておくと良さそう

面接対策(一般)

  • 場数をこなすと面接はどんどん上手くなるので、一番最初のスケジュールに志望度の高い企業を入れるのはできれば避けたい
  • 職務経歴中心の自己紹介、転職理由、将来的になりたいエンジニア像、志望動機等の頻出の質問があり、基本的にどの企業でも同じような質問がされた
    • 転職理由と将来像と志望動機を一貫性がある形で構築すると良いというのが、エージェントに教えて貰った一般的な攻略法
      • これをウケが悪くなり過ぎない程度に本音に近い形で喋ることで、自分のやりたいことにマッチする企業かどうかこちら側からも見極めることができる
    • 自己紹介が当初長くなりすぎていて、途中から内容を絞って短くした
  • ハキハキとテンポ良く簡潔に分かりやすく答えることを意識するとウケが良さそう
  • 最後に質問時間があるので、事前に企業研究を良く行った上で、ビジネスモデル等について質問をすると好感触になりそう
  • とある人気企業の最終面接でカルチャーマッチや入社後の貢献イメージについてシビアに深堀りされてテンパってしまい、落とされた

面接対策(技術)

  • 自分が関わったプロジェクトで苦労したことやそれをどう乗り越えたかについてのエピソード、また実装上の工夫については聞かれることが多かった
    • どのプロジェクトについてアピールするかは事前に想定して、実装上の工夫について掘り下げて聞かれることを前提として詳しく準備しておくと良さそう
  • 技術的な観点は選考を通過するかだけでなく、内定後の社内グレードに基づくオファー年収にも関わってくるので、自分の業務経験や知識については可能な限り掘り下げて復習して臨むと良さそう
  • 質問に回答した内容について「それってどういうことですか?」みたいに2回くらい掘り下げられることを想定して、各技術トピックについての回答をイメトレしておくと良さそう
    • 掘り下げられたら答えに窮するような話題には自分からは触れず、理解度が一定以上高いトピックについてのみアピールすることを心がけると良さそう
  • 私が聞かれて困った質問は「DBのパフォーマンスチューニングやったことありますか」「大量アクセスを考慮した実装の工夫の経験はありますか」「Webアプリケーションにおけるキャッシュ利用について知っていることを教えてください」など
  • 個人開発の経験(私の場合短歌投稿サイトUtakataなど)は面接官の性格によっては話が盛り上がる(逆にまったく興味を持たれないことも多い)ので、職務経歴書に書いておくと良さそう

コーディング試験

何らかの実技試験がある企業も多く、形式には以下のタイプがあった。

メール試験

  • メールで送られてくる論述問題、プログラミング問題を2時間や3時間の制限時間内で回答して返信する
  • Google検索可能
  • Webアプリケーションの運用やパフォーマンス改善に関する論述問題と、オブジェクト指向プログラミング問題、アルゴリズム系のプログラミング問題の構成が多かった
  • アルゴリズム問題はググっても簡単に分からないような問題を出題して来るので、日頃から慣れていないと上手く回答することは難しい
  • Web APIを利用する問題は頻出と思われるため、フレームワークに依存しないHTTPクライアント利用については事前に慣れておいた方が良さそう
  • 必ずしも全問正解が内定の必要条件ではなく、アルゴリズム問題は解けなかったけれど内定が出た企業があった
  • 回答内容を後の面接でライブコーディングして更に掘り下げるタイプの選考をする企業があった

ライブコーディング試験

  • ビデオ会議ツールの画面共有またはHackMDのような同時編集ツールでリアルタイムにコーディングして回答する
  • FizzBuzz系のプログラミング問題(実行環境での実行あり)、ToDoリスト系アプリの要件を提示されテーブル設計する(実行なし)など
  • コーディング能力だけでなく、チーム開発上のコミュニケーション能力もチェックされる

アプリ開発試験

  • 簡単なWebアプリについて要件通りに作成してGitHubにアップして提出する

リファレンスチェック

  • 最終面接前後のタイミングで現職の上司、同僚にアンケート形式で職場での印象を書いて貰って提出する「リファレンスチェック」という仕組みを導入している企業がある
  • back checkASHIATOのようなリファレンスチェックサービスが利用されている
  • リファレンスチェックをお願いした人に転職活動していることを無断で経営者にシェアされてしまうトラブル*1があり、引き止め交渉があってちょっと大変だった

オファー

  • 最終面接を経て内定後、年収等の条件を提示されるオファー面談がある
  • この機会に残業時間等の条件を質問できるので、内定が出るまでの面接で労働条件についての質問をする必要はない
  • オファー年収については企業間での差がかなり大きくなる(私の場合3社で約50万円のレンジがあった)ため、選考が進んでいる企業については志望度がやや低くても安易に選考を辞退せず内定を取りに行った方が良さそう
    • 私の場合、当初の第一志望ではなくオファー年収が高い企業の内定を受諾した

個人的なキャリアプランについて

  • 現職が少人数ベンチャー企業であるが故のダメな部分を感じることが多かったため、もう少し体制のしっかりした企業が良さそうと思い、いわゆる大企業も受けてみたけれど、分業体制がしっかりし過ぎている会社は合わなそうだった
  • 私は技術力だけでなく、プロジェクト進行力とかビジネスサイド調整力などのコミュニケーション面も含めて勝負しないと相対的な価値が出ないタイプなので、そうなるとやはりベンチャー企業との相性が良いと再確認した
  • 転職後もかなりスタートアップ色の強い現場での仕事になる
  • 正直ベンチャーの「成長」周りのノリしんどいなあ、もっとマッタリ働きたいなあと思うところもあるけれど、流石に今のスキル感ではまだ守りには入れなさそうだった
  • ベテラン感のあるエンジニアになるのが直近の目標

*1:「やめて欲しくなくて」とのことだったけれど、勝手にシェアするのは流石にどうかと思った。

Next.jsでCMSにMDX形式で登録したコンテンツを利用する ―next-mdx-remoteの使い方―

Jamstackな構成では、CMSにどのような形式でコンテンツを登録するかが関心になって来るかと思う。

Markdownを採用する場合は、remark-reactやremark-htmlを使ってMarkdownをHTMLに変換できる。

ただ、実際にはMarkdownだと機能的に足りない部分が出て来そうで、MDXという、MarkdownにJSX(Reactコンポーネント)を埋め込める形式を利用すると捗る。

しかしこのMDX、CMSのような外部コンテンツとして登録する場合はどう使えば良いんだ?と思ったら、Next.jsの場合、next-mdx-remoteという便利なライブラリがあった。

next-mdx-remoteの使い方

例として、Next.jsのImageコンポーネントを利用してみる。

# プロフィール画像

<Image src="/images/profile.jpg" width="100" height="100" />

CMSには上のようなMDX形式で保存して、

Reactコンポーネントでこのように変換して利用できる。renderToStringhydrateメソッドの第2引数にMDXで利用しているReactコンポーネントを渡すといい感じに変換してくれるようだ。

2021/05/25追記

Version 3ではrenderToStringhydrateメソッドではなくserializeメソッドを利用する方式に変わっている。

JavaScriptで要素をフェードイン・フェードアウトで切り替える ―async/awaitでrequestAnimationFrameを使う―

妻の歌人としての個人サイトのトップページで、短歌をアニメーションで切り替える処理をJavaScriptで書いている。

jQueryには上のような専用メソッドがあるフェードイン・フェードアウト処理を自分でググりつつ書いてみたところ、試行錯誤できるポイントがあったのでまとめておきたい。

setTimeoutを使った当初実装

まずjQueryの実装は高度に共通化されていて読み解くのがなかなか大変そうだったので、ググって実装方法を探してみた。

このStack Overflowの回答が分かりやすかったので、参考にして実装してみた。

それがこれ。ループでsetTimeoutを使って100ミリ秒ごとに少しずつopacity(不透明度)を変化させている。

分かりやすい処理でちゃんとフェードイン・フェードアウトしたので満足しつつ、念の為他のサイトの実装例も色々と見てみたらもっと良い実装方法がありそうだった。

requestAnimationFrameを使ってより滑らかなアニメーションを実現

このサイトの実装例は明らかに私の当初実装より洗練されているように見えた。requestAnimationFrameというメソッドを使うと良いらしい。

このコールバックの回数は、たいてい毎秒 60 回ですが、一般的に多くのブラウザーでは W3C の勧告に従って、ディスプレイのリフレッシュレートに合わせて行われます。

ただし、setTimeout や setInterval は、ブラウザー側で再描画の準備が整っているか否かにかかわらず、必ず実行されてしまいます。また、ブラウザーのタブが非表示 (バックグラウンド) の場合でも常に実行し続けます。

一方で、requestAnimationFrame はブラウザーの負荷に合わせては 60 FPS 以内で再描画の準備が整ったタイミングで実行され、また、ブラウザーのタブが非表示 (バックグラウンド) にある場合は、発火頻度が自動で低下します。これにより、メモリーの消費を抑えることができます。

こういった理由で requestAnimationFrame はタイマーメソッドより、アニメーションの表現に向いていると言えます。一方で、正確な FPS を制御することはできません。

いい感じにブラウザのフレームごとにタイムスタンプを引数にしてコールバック関数を実行してくれるらしい。

このrequestAnimationFrameを使って上のように実装し直してみた。当初の100ミリ秒ごとの不透明度変更と比べて明らかにアニメーションが滑らかになっている。第2引数にフェードイン/フェードアウト持続時間durationを指定できるようになったのも分かりやすい。

async/awaitの利用

参考サイトと違うのはasync/awaitを使っている点で、

コールバック関数の引数にタイムスタンプが渡されることに注目して、1フレーム進んだ後にPromiseがタイムスタンプを引数にresolveして、const timeStampに1フレーム進んだタイムスタンプが代入される仕組みになっている。

その他の参考記事

Next.js + microCMS + VercelでJamstackなブログ付き個人サイトを作る

妻の歌人としてのブログ付き個人サイトをリリースしたので、技術的な観点をまとめておきたい。

Jamstack

これがサイトの構成図で*1、最近流行りのJamstackというアーキテクチャで作ってみた。

Jamstackは、静的サイトジェネレーターを用いてCMS等で管理するコンテンツをビルド時にすべて取得して、ユーザーアクセス前に用意しておいたHTML、CSSJavaScriptCDN経由で配信することで、画面遷移が非常に速い優れたパフォーマンスのサイト構築を可能にする。

CMS更新時のWebhook通知で自動デプロイする仕組みを入れることで、開発者がソースコードを触ることなく、サイト編集者で完結したサイト更新を行うことができるため、ビジネスから趣味の活動まで、静的サイト開発・運用の手段として有力な選択肢になるだろう。

  • 静的サイトジェネレーター
    • Next.js, Nuxt.js, Gatsby.js, Hugo, Jekyll等
  • ホスティングサービス
    • Netlify, Vercel, Firebase等
  • ヘッドレスCMS

Jamstackな構成をサポートする静的サイトジェネレーター、ホスティングサービス、ヘッドレスCMSには様々なサービスが覇を競っている状態で、ググると色々な構成例が出て来るので、サイトの目的や好みに応じてサービスの組み合わせを選ぶと良いだろう。私はNext.js(React)を使ってみたかったのでNext.jsとVercelを採用し、ITに詳しくない妻がサイトを更新するので、CMSには日本製で非開発者にもUIが分かりやすいと評判のmicroCMSを採用した。

Jamstackのメリット

実際にサイト開発、運用を経験して感じたJamstackのメリットについて書きたい。

お手軽ハイパフォーマンス

普通にNext.jsで開発してVercelにデプロイするだけでGoogleのPageSpeed Insightsで99のスコアが出るのはすごい。実際にサイトを触ってみてもページ遷移が非常に速いことが分かるだろう。

非開発者による更新も比較的容易

サイトコンテンツはすべてCMS上でMDX(Reactコンポーネントが使えるMarkdown)形式で管理している。microCMSにはリッチエディタ機能もあるけれど、仕事でリッチエディタを使っていて、想定外のHTMLタグが大量に混入して苦労することが多かったため、敢えてテキストエリアにMDX形式で入力する方式を採用した。

サイト更新者の妻はITにあまり強くないけれど、microCMSの管理画面を見ながら各APIのコンテンツ構成と、私が作成した初期コンテンツを元にMarkdownの説明を簡単にしたら、microCMS上でサクサクコンテンツ追加できるようになったので、noteやはてなブログのリッチエディタほど直感的に操作できないけれど、非開発者によるコンテンツ更新も比較的容易に行える感触だ。ちなみに妻にMarkdownエディタを紹介したところ面倒臭く感じたようで、microCMSの管理画面のフォーム上で直接更新して、デプロイ結果を見て実際の表示を確認していた*2。趣味のサイトであれば取り敢えずデプロイしてみる雑な運用もアリかなと思う。

開発体験が良好

Next.jsはReactベースのライブラリで、TypeScriptの導入も容易だ。TypeScriptの型チェックの恩恵を受けつつReactでキッチリとコンポーネント化できるフロントエンド開発は、普段仕事でBackbone.jsベースの複雑なSPAを触っていることと比較しても快適で、コーディングのモチベーションを終始高く保てた。Node.jsのライブラリ群も非常に充実している。

Next.jsは今回初めて触ったけれど、簡単なブログサイトを作ってデプロイまで行う公式チュートリアルが非常に易しく書かれているので、学習コストは低く感じた。

Reactの公式ドキュメントも日本語訳があり、分かりやすく丁寧に書かれていて助かる。

サイト制作手順

これから同様の構成で静的サイトを作ってみようという方への参考と自分用のメモのため、サイトリリースまでの手順を書いておきたい。工数的にはほぼ年末年始休暇中の作業でリリースまで持ち込むことができた。

  1. Next.jsのチュートリアルサイトを作成する
  2. GitHubチュートリアルサイトに名前を付けてリポジトリ作成する
  3. TypeScriptを導入する
  4. ESLintJavaScript Standard Style)を導入する
  5. CSSライブラリのBulmaを導入する
    • BootstrapをJSなしでCSSのみにしたような印象のライブラリ
    • 便利なスタイルが色々と用意されていて助かるが、 Bootstrapと同様に影響範囲が広くなるので、仕事で使うには注意が必要だと思った
  6. サイト構成・デザインを妻と相談しつつ決定する
    • ハンバーガメニューではなくフッターで4つのメニューを切り替える
    • トップページで短歌をフェードイン・フェードアウトで切り替えて表示する
    • 白背景に黒字をベースとし、アクセントカラーに緑を採用する
    • その他サイトタイトルやdescriptionなどを決定した
  7. ローカルにコンテンツを用意しつつ、各ページを作成する
  8. ローカルからmicroCMSにコンテンツを移動し、APIでコンテンツを取得する処理を書く
  9. CMSでMDX形式のコンテンツを管理する仕組みを導入する
  10. トップページで短歌がフェードイン・フェードアウトで切り替わる処理を追加する
  11. faviconとOGP画像を設定する
  12. VercelにGitHubリポジトリを連携してデプロイする
    • 環境変数(microCMSのAPIキー)の設定もGUIで簡単に行えた
    • GitHubにpush時の自動デプロイ機能がデフォルトで付いていて驚いた
  13. Vercel管理画面で独自ドメインを取得する
    • 分かりやすいUIでサクッと購入できた*3
    • 購入後自動で独自ドメインにアクセス可能になり、TLSSSL)の設定まで自動で始まって、約1時間後にTLS設定が完了した
  14. Vercel管理画面でDeploy用URLを取得し、microCMSのWebhook通知先に設定して、CMS更新時の自動デプロイを可能にする
    • Vercelのデプロイ用URLがエラーとなり機能しなかったが、Vercelのサポートに英語で報告したらすぐにバグ修正してくれた
  15. VercelからSlackにデプロイ通知する
    • プライベートでSlackを使っていないため、今回の実運用では採用していないが、仕事で使うならあった方が良いだろう
  16. サイト編集者にCMSの更新方法を案内する

*1:Slackのデプロイ通知については可能なことを確認したのみで、実際の運用は行っていない(プライベートでSlackを利用していないため)。図はDraw.ioを使って描いた。

*2:現状では30秒ほどでデプロイ完了する。

*3:お名前.comとは雲泥の差だ…。

妻の歌人公式サイトをリリースしました!

妻の歌人としての個人サイトを開発してリリースした。

開発の背景

悪友

悪友

  • 作者:榊原紘
  • 発売日: 2020/08/05
  • メディア: 単行本(ソフトカバー)

妻は去年、笹井宏之賞大賞受賞の特典で第一歌集『悪友』を出版して絶賛売り出し中なのと、最近のnoteのゴタゴタでnote退会したいみたいな話があったので、私のNext.jsの勉強がてらnoteみたいなブログ機能付きの公式サイト作ってみたら面白いんじゃない?ということで年末年始休暇にサクッと作ってみた。

トップページで短歌がアニメーションで切り替わるのと、Next.jsのSSG*1故のサクサク動くレスポンスがアピールポイント。

歌人で個人サイトを持っている人は少なく、持っていたとしてもワードプレスのテーマで作っている方が多いようなので、フルカスタマイズ可能なスクラッチ開発のサイトを持っているのは差別化になるかと思った。

やっぱりWebはコツコツ作ってるときが一番楽しい。HTMLは自由だし、最新のJSライブラリ群は恐ろしく快適な開発体験を提供してくれる。

2021/01/18追記

サイトの情報をソースにして、妻のWikipedia記事をどなたかが書いてくれた。

技術的な観点の記事も書いた。

*1:Static Site Generation。ユーザーがサイトにアクセスする前のビルド時にあらかじめコンテンツをすべて用意しておく手法。また、VercelではデフォルトでVercel Edge NetworkというCDNがサポートされている。

公立中学動物園論争に見る「ダブスタ指摘」論法のくだらなさ

中学受験について、匿名でないと書けないことを伝えたい

まぁこんなウダウダ書かなくても公立中出身者ならあの動物園に通わなくていいってので十分良さはわかるよ。

2020/12/08 22:32

公立中学を「動物園」と表現したブコメに日頃ポリコレや反差別にうるさい「はてなリベラル」が多くスターを付けているのはダブスタだという論争が話題になっている。

この論争には、私が以前からネットで多用される詭弁的論法の最たるものだと認識している「ダブスタ指摘」論法の問題点が表れていると感じたので、その観点に絞って書きたい。

問題点を指摘する増田を書く

論争が起きているのははてな匿名ダイアリー(通称増田)なので、私も久しぶりに上の増田を書いてみた。

他者の表現の自由を侵害しようと言うのであれば、その表現がどのように表現対象の人権(自由)を侵害する差別的な表現なのか、ということを十分に社会的合意が得られるレベルで示す必要がある。「自由」と「自由」の対立の調停を図るのが本来のリベラリズムの立場のはずだ。この2つの自由のうち、表現の自由の方を極端に軽視するのが、行き過ぎたポリコレ推進派が本当に「リベラル」なのかと、自己矛盾を感じさせるポイントだろう。しかし「はてなリベラル」嫌いの人たちは、「動物園」の表現の取り締まりにまったく躊躇がないらしく、その点で彼らが嫌いなはずのダメなリベラルに良く似いる。

表現の自由基本的人権なのだから、不快な表現、攻撃的な表現というだけで取り締まろうという方向にするべきではなく、取り締まろうと言うのであれば、その表現が他者の人権(自由)をどのように制限しているかの丁寧な説明が必要なはず、というのが論旨で、「はてなリベラル」批判派の人たちが「動物園」の比喩を曖昧な根拠で取り締まろうというのは、彼らが何よりも嫌いなはずの行き過ぎたポリコレ推進派と同じ立場ですよね?という指摘だ。

「日頃は反差別、ポリコレに熱心なはずの「はてなリベラル」が公立中学を「動物園」と表現するのはダブスタだ」という批判をするとき、この批判者自身の立場は、以下のような真逆の方向が想定し得る。

  1. ダブスタであり、公立中学への表現も厳しく取り締まるべきだ
  2. ダブスタであるから、公立中学への表現が許されるように、その他の差別問題に関する表現についても寛容であるべきだ

私がこの論法を嫌いなのは、批判者が自分はこのうちのどちらの立場なのか隠して批判することが多いためだ。首尾一貫性という、どうとでも破綻を見出せるような枷を、批判相手にのみ課して自らには課さないのは卑怯だと感じる。

ダブスタ指摘論法はミラーリング、試し行動の側面を持つ

私の増田への反応を見てみよう。

「公立中学差別」って何だ?

何でこう論理的思考が弱い人が多いのか、&quot;表現の自由を制限するには、その表現によってどのような人権が制約されているかの丁寧な説明が必要&quot; これを引き出す為の批判に決まってるじゃん(自由の制限の基準含め)

2020/12/12 11:15

今までの差別問題や表現問題のときにそれらはされてましたか?

するまでもなく明らかな場合もあったと思うけど、そうでなく意見が割れてるときにそんな建設的な流れになった記憶ないけど。

検証・説明しきれない部分を「理解してるくせにしらばっくれてる」みたいなのはあったっけ。

そう言えばいいですか?

なんで自分らが批判されるときだけ違う基準を持ち出したり、違うレギュレーションで議論しようとしたりするの?君たちだけそんなに特別な存在なの?

行き過ぎたポリコレ推進派のダメな部分をそのまま演じてやり返す「ミラーリング」のつもりらしい。何だかため息が出てしまう。わざわざ自分がダメだと思っている集団の行動を真似して人を不快にさせて、自分の不快感に気づいて貰おうというのでは、まるで子供の「試し行動」だ。

表現の自由と差別の問題は複雑で、人によって様々な立場を取り得る。自らの立場を隠して、あるのかないのか分からない「界隈」の対立を煽るからダブスタ指摘論法が嫌いなのだと、改めて確認させられる一件だった。