【Python】pyppeteerでのクローリング時に別ドメインのCSSを読み込む

pyppeteerを使ってクローリングする際、「JSを実行して値を取り出す」ため、セキュリティのための制限にひっかかることが割とあるようです。

私の場合、CSSの情報を取り出す際に、以下の問題に引っかかりました。

> document.styleSheets[0].cssRules
VM52621:1 Uncaught DOMException: Failed to read the 'cssRules' property from 'CSSStyleSheet': Cannot access rules
    at <anonymous>:1:25

一部のブラウザーでは、スタイルシートが異なるドメインから読み込まれている場合、cssRules の呼び出しで SecurityError が発生します。

自分や自社が管理するサイトの開発時のE2Eテストのような要件であればCORS (Cross-Origin Resource Sharing)の設定で対処できそうなのですが、私の場合はクローリングの案件だったのでその方法は使えません。Headless Chromeの起動オプションで指定できるそうなのでそちらで対処しました。

stackoverflow.com

上の記事ではpuppeteer(pyppeteerの元ネタのnode.jsのライブラリ)の話題ですが、pyppeteerでもほとんど同様に操作できます。

from pyppeteer import launch

async def main():
    browser = await launch(headless=True, args=['--disable-web-security'])
    # 以下、操作

小規模で、信頼できるサイトのクローリングならこれで問題ないと思っています。

【本】『わざ言語―感覚の共有を通しての「学び」へ』を読みました

年末なので本ばかり読んでます。普段と違う環境だと本に逃げてしまうので、なんとかプログラミングに集中する方法も見つけたいです。

わざ言語―感覚の共有を通しての「学び」へ

これも『コミュニケーション学がわかるブックガイド』で気になった本の一つで、後輩のレビューのときに「エラーの調査」や「プログラムの設計」の部分など、おそらく暗黙知に近く教えづらい分野もあったので、それをうまく伝えるヒントが無いか調べるために読みました。また、（趣味の）音楽関連でも、実際のスキルと少なくとも同程度には、立ち振舞いや暗黙の何かが重要になることが多いように感じています。

私たち実務者にとって重要なのは、やはり「（今すぐじゃないにしても）自分や周囲の仕事にどう役立てられるのか」だと思うので、抽象的な問題にハマってしまうより、具体的な問題意識を持って読む/自分なりにサンプリングして試すようなことは重要だと思っています。

本の内容はこちらにある通りです。

www.keio-up.co.jp

自分の問題意識から、気になったところだけピックアップします。とりとめない内容ですみません。

適応的熟達者について

P41 第二章 熟達化の視点から捉える「わざ言語」の作用

近年の研究において、熟達者は、知識・技能の柔軟性や創意によって、適応的熟達者（adaptive expart）と手際のよい熟達者（routine expart）に分けて考える捉え方がなされている。

チームの目標によって、どちらの熟達者がいいかは少しずつ変わりそうですね。私が興味がある（この本のテーマ的も）後者なのですが、こう説明されています。

適応的熟達者は、必要や興味関心に応じて熟達化を深化させ、新たな熟達の展開を行う。それゆえ、適応的熟達に向かう学習者は、新しいこと、より困難な課題、より複雑な問題状況に対峙するために、そうした状況の中にあえて立ち入り、身を置き、格闘せざるを得ない。すなわち探索的な初心者（intelligent novices）を経て初めて適応的熟達体験が得られるのである。

技術の創造と設計

以前、こちらで紹介されている本も似たテーマだった覚えがあります。

丸善丸の内に怪しいアイコンが飾られています。

自分は「GE巨人の復活」と「技術の創造と設計」を選書させていただきました。 pic.twitter.com/ddlM96fTjZ

— ところてん (@tokoroten) May 22, 2018

「わざ言語」の作用の様態を説明する六つの側面

P53

①「わざ言語」は、熟達化の過程で本人が「こういうことかな」、「いい感じだな」と気づくための態度や、気づくことのできるような状態に導く手がかりを与える。ただし熟達化には時間を要する。

②「わざ言語」は、直接的に問題解決を導くのではなく、問題解決の核を導く。

③「わざ言語」は、必然性をもつ文脈の中で用いられるものである。その文脈とは当人が求める感覚の状態によって規定される。

④「わざ言語」は、段階を経る中で、自動的な段階へと導く作用力をもつ。ただし、それは単なる自動化された動きを意味するのではなく、感覚が管理された、感覚が上乗せされた自動的な動きを意味する。

⑤「わざ言語」は、受け止める人の状態や体験等によって作用力が異なる。したがって、わざを教え学ぶ場では、感覚の共有が重要な意味を持つ。

⑥「わざ言語」によって導かれる状態は、最終到達形としてあるのではなく、さらなる洗練が目指される状態である。わざの探索と熟考は継続的に行われる。

思考を妨げる「文字知」

P103

では、なぜ「文字知」を拒むのか。問題視されるのは丸暗記である。西岡が、それでは分かったことにはならないと言うのは、丸暗記が頭での理解を目指すからである（西岡、1991、230頁）。しかし、宮大工の「知」は体得すべきもので、「できるかどうか」が重要となる。「教科書にあるような木はないんやから、もしかしたら真ん中は使えないかもしれない。外側の白太を外したら予定通りの寸法を取れないかもしれない」（小川、2001a、140頁）

（中略）

つまり、弟子を丸暗記に誘い込み、「思考」を停止させる危険性の回避のために「文字知」が拒まれたといえる。いかにして「考える人」を育てるか。「文字知」の拒否は、弟子に「思考」を促す工夫として理解できる。

これは工学系の分野でもその通りだと思います。特にITのシステム設計みたいな分野だと、割と「机上の空論で理想論だけなら割とどうとでも言える」ので、似たコンセプトのものが混在していて意味分からない感じになってますよね。だから先に「いろいろ試行錯誤させて『見る目』を養った後で、知識を教えよう」って話もある程度納得感があります。

また、レベルアップするために「手放される言葉」もあるというのも面白い話でした。

2つの「わざ言語」

P120

しかし佐藤氏の中では二つの区別がある。「われこれ複雑に言葉を尽くすよりも、一つの言葉ですとんと直ってしまう」言葉、そして「何かの現象を直すのではなく、自らの対峙によって悩み納得し、そうせざるをえないという質的変化を引き出す言葉」という区別である。本書の実践編からは割愛されたが、佐藤氏自身の命名に従って、以下、前者を「寄り添い型わざ言語」、後者を「誘（いざな）い型わざ言語」と呼ぶ。

全然関係ないかもしれないですが、「Hackers and Painters」のこの言葉も、自分にとっては「誘い型わざ言語」だった気がします。

他のものを創る人々、画家や建築家がどうやっているかを見れば、 私は自分のやっていることにちゃんと名前がついていると気づいていただろう。 スケッチだ。 私が言えるのは、大学で教わったプログラミングのやりかたは全部間違っていた ということだ。 作家や画家や建築家が、創りながら作品を理解してゆくのと同じで、 プログラマはプログラムを書きながら理解してゆくべきなんだ。

看護について

先程の「誘（いざな）い型わざ言語」の具体例のような内容。以下の本から引用されたこの文言をきっかけに学んでいく姿が指摘されていました。

看護の基本となるもの

ある意味において看護師は、自分の患者が何を欲しているのかのみならず、生命を保持し、健康を取り戻すために何を必要としているのかを知るために、彼の"皮膚の内側"に入り込まねばならない。

助産師のリフレクション（振り返り会）

P356

ーーそのサインというのはどういうことなのでしょう。後進の助産師の中には、熟練助産師がサインを送っているのに意味がわからない。隠そうとしているのに産婦の前で「ああ、これ、危ないですね」と思わず言ってしまうような助産師もいるわけですよね。そのサインは、どうしたらわかるでしょうか。

村上　ある後進の助産師は、その助産所に勤め始めたころは、どうしても言葉で言ってもらわないと意味がわからなかったと話しています。ただ、その助産所の熟練助産師は、お産の後に必ず、後進の助産師と共に振り返りをして、「ここはこうだったね」、「ああだったね」とか、「こういうサインを送ったのはわかった？」とか、わかってないかもしれないと思うときは、そのサインについて確認をしていると話してくれました。わかったという感覚、あるいは、危険だという感覚を共有している、共感していると思うのです。

【本】ソフトウェアエンジニアのための「アサーション入門」

…ってタイトルで書こうと思ったんですが、だいたいこのサイトに書いてある通りの内容ですね。

el.jibun.atmarkit.co.jp

アサーションと言っても、assert文を使った契約的プログラミングの話ではなく、この間の『コミュニケーション学がわかるブックガイド』で薦められてた本の一つの話です。

アサーション入門――自分も相手も大切にする自己表現法 (講談社現代新書)

「自分らしくあってよい」「気持ちや考えを表現してよい」など、なんとなく認知行動療法っぽい内容だと感じたのですが、検索した限りではけっこう関連する分野のようです。私はある友達の立ち振舞いから同じような考え方を学んだのですが、他の友達や後輩に勧めるときにいいかもしれません。

ただ、第四章「アサーションで身につく三つの力」で人間関係を以下の2つの場面に分けるのはちょっと興味深い内容でした。

• メンテナンス（関係維持）
• タスク（課題）達成

【Python】asyncioの代替ライブラリtrioを調べてみた

この記事はPython その2 Advent Calendar 2018の遅れてきた15日目の記事です。

最近、クローリング用のプログラムのasyncioを使った並行処理のプログラミングをしており、「asyncioのベストプラクティス」という趣旨の記事を書こうと思っていたのですが、自分自身感覚を掴めておらず、「あれ？これってasyncioのAPI自体も微妙なのでは？」「そもそもasyncioのドキュメントのドキュメントを読んでも、どの機能をどう組み合わせて使えばいいか分からない」と思ってしまっていて記事を書きかねていました。

ただ、知人から「trioというライブラリのAPI設計が素晴らしい」と薦めて頂いたのと、あまりにも待たせてしまうのも申し訳ないのでひとまず「調べてみた」レベルでアウトプットを出します。

私はまだ並列/並行/非同期処理に詳しいわけではないので、大きな思い違いをしている可能性はあります。鵜呑みにせず、一緒に勉強しましょう。もし変な箇所があればコメント等で連絡ください。

trioとは

「async I/O for humans and snake people」を名乗るライブラリです。requestsなどのAPI設計が優れたライブラリ作者のKenneth Reitzさんっぽい文言ですが、その後に実際に彼のコメントが引用されています。

github.com

まず、こちらのstack overflowの「asyncioとtrioって何が違うの？curioってライブラリもあるそうなんだけど…」という質問に、trioの"primary author"でcurioの"contributor"でもあるNathaniel J. Smithさんが以下のように答えています。

• asyncioのほうが成熟したライブラリだ
• trioはコードをもっとシンプルにしてくれる
• 詳細は多くの違いがある
  • asyncioや関連ライブラリではsome_functionを実行したときにコルーチンが実は完了していない場合もあり、例外やタイムアウト関連で厄介な問題が起きるが、trioの"nurseries"を使う方法ではその動作が完了していることを保証できる
  • trioのタイムアウトや中止の方法が今までにない新しいものである
  • asyncioはAPI設計に冗長な部分や、そのための落とし穴が多い

それでは、「asyncioよりシンプルなAPI」を実現するために、trioではどういう設計になっているのでしょうか？「Async concurrency for mere mortals - PyCon 2018」を引用しつつ紹介します。

Pythonでasync/awaitを使ったコードを書く時、Pythonの同期的な関数の中に、asyncio等のライブラリでasync/awaitの関数を実行して…とプログラミングしていきます。trioのアーキテクチャでは更に"Nurseries"と"Cancel Scope"が追加されています。

asyncioには存在しない"Nurseries"の層では、async with trio.open_nursery()ブロック中でstart_soonでコルーチンをセットしてバックエンドで実行開始し、async withブロックが閉じるときにこれらのコルーチンが処理を完了させている設計になっています。

そうすると、"nursery"のブロックの中でエラーが出たときに、ブロックに例外が通知され適切に処理できることが保証できます。その途中でgoto文論争や構造化プログラミングの話も出ていますが、おそらく「どこで何の処理が行われているか分からないと、適切にエラー処理できない」という例として触れているだけのようです。

次に"Cancel Scope"の説明です。ネットワークを介した処理を行う時、次の3つのことが起こりえます。

• 成功
• 失敗
• どちらでもなく、永久にハングアップする

ハングアップした場合に備えて「必ずタイムアウト処理を書くべき」だとNathaniel J. Smithさんは主張しています。trioでは、async関数の中で「ブロック内の処理がn秒以内に終わらなかった場合はキャンセルする」ような機構が提供されているようです。

Design and internalsによると、この辺りが基となったライブラリの一つのcurioとの大きな違いのようなのですが、両方のAPIに精通しないと読めないですね…。この辺りのAPI設計があまり理解できていないので、tutorialを見てみようと思ったのですが、運悪く「When things go wrong: timeouts, cancellation and exceptions in concurrent tasks」はまだ未整備でした。

関連記事

参考にした記事や、「ここから学んでいけば良さそう」という記事をメモしておきます。

Trio talks

こちらが今回の記事のほぼ元ネタです。この記事では説明し尽くせていない部分もあるので、見ておくといいと思います。

github.com

www.youtube.com

What is core difference between asyncio and trio

stackoverflow.com

Some thoughts on asynchronous api design in a post async/await world

curioとasyncioの異なるアプローチを比較した記事。先述したNathaniel J. Smithさんが書いています。

Some thoughts on asynchronous API design in a post-async/await world — njs blog

Reading list

trioのReading list。trioのアイデアの元になった言語やライブラリが紹介されています。これは骨が折れそうですが、並列/並行処理全般の様々なアプローチを学べそうなので、徐々に読んでいこうと思っています。

github.com

Pythonをとりまく並行/非同期の話

並列・並行処理関連は情報が多くて最初は混乱すると思います。慣れてない方は「CPUプログラムのボトルネックとなる処理がCPUが原因なのか、IOが原因なのか」は重要なのでよく見ておきましょう。

tell-k.github.io

async/awaitはIOが原因となる処理を高速化するための手法です。その後、Nathaniel J. Smithさんの動画を見ると分かりやすいと思います。

あまり関係ないですが、"GIL"のことを"ギル"って発音していたのでビックリしました。自分は"ジル"って読んでたので…。

trioを知る前は「Go, Erlang, Haskellとかの並列・並行処理が得意な（と言われている）言語のアプローチを勉強しようか」って思っていたんですが、もう少し楽できそうです。

最後に

公式リポジトリにもあるように、まだtrioは新しくてやや実験的なプロジェクト(young and still somewhat experimental)のようです。私はプライベートでの開発で試していこうと思います。

他にも、いくつかアドバイスや注意点が書かれています。例えば以下のようなものです。

• APIの後方互換性を破壊する変更はissue #1に投稿されるので購読してほしい
• 使ってみて分からない点はchat room, filing a bug, or posting a question on StackOverflowを通して聞いてくれ

早くtrioくんと平和な非同期処理の世界に暮らせる日を待ち望んでいます。

わーすた / うるとらみらくるくるふぁいなるアルティメットチョコびーむ MUSIC VIDEO Short Ver. - YouTube

関連ライブラリ・リポジトリ

• asyncio: みんなご存じ標準ライブラリ。
• trio: 今回紹介したライブラリです。
• curio: trioが影響を受けたライブラリの一つ。公式リポジトリの紹介によると、あるベンチマークではtrioの50%程度早いとか。
• uvloop: asyncioのloopを"ultra fast"なものに置き換えてくれるライブラリ。今回は「使いやすいものを探す」って趣旨ですが一応触れておきます。

【本】『コミュニケーション学がわかるブックガイド』で気になった本

これ読みました。けっこう面白い本も紹介されていたので、これから学んでいこうと思った本のアタックリストをメモしておきます。

コミュニケーション学がわかるブックガイド

わざ言語: 感覚の共有を通しての「学び」へ

プログラマーだとコードを見るとき「コードの不吉な臭い」みたいな、「何かこの部分ってイケてないな」って感覚ってあると思います。ただ、レビューする際にはなんとか言語化して議論しなきゃいけず、大変だってことも多いでしょう。

この本はスポーツを例にして、そういった暗黙知について議論した本のようです。また、宮大工の例として「痕跡を見る」「読み解く目を養わせる」みたいな話も載っているとか。

わざ言語:感覚の共有を通しての「学び」へ

アサーション入門

心理的安全性ガイドライン（あるいは権威勾配に関する一考察）でもこう書かれていて「アサーティブ・コミュニケーション」って呼ばれる分野が気になっていました。ここから掘っていけばいいかな？

あなた/相手は傾聴やアサーティブコミュニケーションのトレーニングを受けたことがあるか？

我々は「正しいことを言えば相手に伝わる」って思いがちですが、相手が真に質問したいことを言語化できていない場合など、「いや、何か返して欲しい答えと違う」→「この人に何を言っても無駄だ」って思われることって多々あると思っています。

アサーション入門――自分も相手も大切にする自己表現法 (講談社現代新書)

わかりあえないことから

従来の「価値観を一つにする方向のコミュニケーション能力」を養成するのではなく、共有性、つまり「わかりあえないこと」を前提にしながらわかりあえる部分を探っていく営みとしてのコミュニケーション能力の養成が重要であると述べている。

そのとおりだと思います。

わかりあえないことから──コミュニケーション能力とは何か (講談社現代新書)

組織化の社会心理学

会社やコミュニティなどの組織を「動的なもの」として捉えないといけない、と主張した本だそうです。「チームが学習して新しい技術を取り入れる」ことがなければうまくいかないと思うので気になっています。

組織化の社会心理学

知的創造企業

当時の日本企業を分析して、「暗黙知」を「形式知」に転換する方法を議論したもの。

そういえば、ソフトウェア開発手法の中に「実は日本の製造業が由来のもの」ってけっこう多いですよね。

知識創造企業

「からだ」と「ことば」のレッスン

「からだ」と「ことば」のレッスン (講談社現代新書)

誰のためのデザイン？

デザインの分野で有名な本ですね。

誰のためのデザイン？　増補・改訂版　―認知科学者のデザイン原論

フロー体験

フロー体験 喜びの現象学 (SEKAISHISO SEMINAR)

組織は戦略に従う

組織は戦略に従う

【Python】pyppeteerの非同期処理をこんな実装で行おうと思ってるんですが、どう思います？

pyppeteerで非同期でクローリングする実装をしていて、エラー時に自動でbrowserとpageを開き直してリトライ…って考えてたんですが、あまりにリトライ処理が煩雑になるので

• 毎回処理したい固定長のurlのリストを受け取る
• レスポンスはrequests-htmlのものが便利だったので流用
• ブラウザ操作周りの例外が出たらfetchの外で例外処理して全部やり直す
• HTMLから必要な情報だけをpyppeteerから取得することもできるが、一度メモリに乗せて同期的な世界に返してしまう

って感じに割り切って実装しようと思ってるんですが、どう思いますか？

↓こんな感じのコード

from pyppeteer import launch
import asyncio
from requests_html import HTML


def fetch(urls, *, headless=True):
    loop = asyncio.get_event_loop()
    return loop.run_until_complete(_async_fetch(urls, headless=headless))


async def _async_fetch(urls, *, headless):
    async with Crawler(headless=headless) as c:
        async def _inner(url):
            async with await c.get(url) as page:
                html = page.html
            return html
        return await asyncio.gather(*[_inner(u) for u in urls])


class Crawler(object):
    def __init__(self, *, headless):
        self._headless = headless

    async def __aenter__(self):
        self._browser = await launch(headless=self._headless)
        return self

    async def __aexit__(self, exc_type, exc, tb):
        await self._browser.close()
        return False

    async def get(self, url):
        page = await self._browser.newPage()
        await page.goto(url)
        return PageResponse(self, page, url)


class PageResponse(object):
    def __init__(self, browser, page, url):
        self._crawler = browser
        self._page = page
        self._url = url

    async def __aenter__(self):
        content = await self._page.evaluate('document.body.textContent', force_expr=True)
        self._html = HTML(html=content, url=self._url)
        return self

    async def __aexit__(self, exc_type, exc, tb):
        await self._page.close()
        return False

    @property
    def html(self):
        return self._html
    
    async def screenshot(self, path):
        await self._page.screenshot(path=path)

【本】ソフトウェアエンジニアが読む『ソーシャル・マジョリティ研究』

普段、ソフトウェアエンジニアとして仕事をしていて「複数人で目的を共有する難しさ」「自分の行動を言語化（説明）する難しさ」を感じています。

私はソフトウェアエンジニアの仕事を「いかに楽に欲しい機能を実現するか（もしくは今までに無かった機能を実現するか）」というゲームのようなものだと捉えています。そのために、

• 関係者の説明の表層的な面に惑わされず、いかに妥当な目的（ゲームのルールや制約条件）を見つけるか
• 注力すべき目的を見つけた後は、いかに妥当に実装していくか
• ゲーム自体を、どうすれば自分や他のメンバーが楽しんでスキルアップできるか
• （ルールの設計がうまくいけば）協力ゲームのはずなので、自分に不利な内容であっても率直に議論すること

というようなことを考えて行動し（ようとし）ています。ところが、人の特性や性格は様々なので、当然いろいろな問題が起きます。

• このゲームのルールは「文脈」や「空気」のようなもので、人によってはきちんと明示し続けないと伝わらないこと
  • というか、自分自身だんだん外して変なものを作ってしまうこともあるため、それを防ぐためにも明示したい
• （私の場合は）適度に友達と冗談を言いながらゲームしたいが、人によること😢
• 鬱屈して協力ゲームだと捉えられなかった人がいた場合に、彼が逸脱してしまうこと
• 斜に構えてゲームを楽しもうとしない人もいること
• …

というわけで、みんなが楽しいルールを設計して、自分自身もゲームを楽しむためには、他の人の特性を理解しつつハック（※パワーワード）する必要があると思っています。また、ゲームをするからには友達と張り合いたいので、私自身が他の人に比べて異様にそそっかしいのをなんとかカバーしたいと思っています。

両方の視点で読んで面白い内容

…うまくゲームのメタファーでごまかしつつ長い前置きをしてしまいましたが、他人や自分の特性を知る例の一つとして「大人の発達障害」に興味を持っています。その中で ソーシャル・マジョリティ研究: コミュニケーション学の共同創造 という本を知り、二重に面白い内容だったのでご紹介します。

ソーシャル・マジョリティ研究: コミュニケーション学の共同創造

この本は「発達障害者の側から多数派社会のルールやコミュニケーションを研究」したもので、自分が該当する場合でも該当しない場合でも「こう感じる人もいるんだ」「あの時自分が感じてたやりづらさはこう解釈できるんだ」とフラットに説明してくれます。例えば私の場合、

1. 普段私自身も暗黙的にやっているコミュニケーションのルールがフラットな視点で説明されている点（自分が該当しない場合）
2. 「こういう感情を感じるべきではない」と考えていたような、以前の自分が抱えていた問題も説明されていた点（自分が該当する場合）

の箇所に特に目が止まりました。

目次

序　章　ソーシャル・マジョリティ研究とは　　・・・綾屋　紗月

第１章　人の気持ちはどこからくるの？　　・・・澤田　唯人

第２章　発声と発話のしくみってどうなっているの？　　・・・藤野　博

第３章　人の会話を聞きとるしくみってどうなっているの？　　・・・古川　茂人

第４章　多数派の会話にはルールがあるの？　　・・・坊農　真弓

第５章　場面にふさわしいやりとりのルールってどんなもの？　　・・・浦野　茂

第６章　ちょうどいい会話のルールってどんなもの？　　・・・浅田　晃佑

第７章　いじめのしくみってどうなっているの？　　・・・荻上　チキ

終　章　ソーシャル・マジョリティ研究の今後の展望　　・・・熊谷晋一郎　

以前の自分の問題と向き合う

先程も触れた「第1章 人の気持ちはどこからくるの？」の話が特に自分と被る内容が多いので面白く感じました。

感情の「理解」と「感受」の分類は今まで思いつきもしませんでした。「看護師はときに感受して、患者の不安や苦しみを共感的に把握する必要がある」というエピソードとして出されていた、『終末期の患者さんが自分の体をつねって感覚の残っている箇所を確かめる「爪の痕」のエピソード』は身を切るような内容で、強い印象に残っています。

www.herusu-shuppan.co.jp

おそらく自分は感情の「理解」と「感受」を以前は分けられておらず、「上司から怒られたときに感情ばかりに目がいき、指摘内容が入ってこない」という質問者と似た問題も起きていたように思います。また、「他人をわかりつくすことはできない」「傲慢になる可能性がある」というのも筆者の言う通りだと今は思います。「相手の感情を敢えて理解にとどめて、本質的な対処法をする」ような手段も必要かもしれません。

また、社会的な文脈で望まれる感情に合わせるために「表層演技」と「深層演技」があると言われ、深層演技の場合、時折「自分の本当の感情が分からない」状態になるそうです。

historie.jugem.jp

第2章や第3章は音声と認知心理学の話で、「あの人やけに声が小さいな」という人に何人か心当たりがあるのですが、もしかしたらこんな事情によるものかもしれないと思い至りました。あと、音を聞いたときの心理的な特性の話も詳しいので、チップチューンを作るときに役立ちそうですね。

第5~6章のコミュニケーションの暗黙的なルールの話は、普段何気なくやっていた会話の流れが定式化されていく様が面白く感じました。ただ、私の場合は『オープンな質問を通して「今後の方針を決める」ような会話のモードに入りたい』が、相手によっては『YES/NOの質問として捉えられてしまって噛み合わない』ような箇所に悩んでいたので、そこにピッタリくる内容は無かったように思います。

第7章の「いじめのしくみ」も、いじめの構造を指摘し、それが行われつらい制度設計にしてカバーしようという内容で、開発者として好感が持てる内容でした。

コードの内容を簡単に説明できるなら、多分いいアイデアだ

序章が特に読んでいて反省させられる内容でした。

というのも、支援をしようにも、あまりにも一人ひとりが抱えている経歴・特性・困難がバラバラなのです。実際に発達障害のコミュニティに参加したことがある当事者の方は、「同じ診断名なのに、自分とはあまりにも異なるいろんな人がいる」とお感じになったことがあるのではないかと思います。そこから推測されるのは、教育・就労・司法・家庭など社会のいろいろな領域で、さまざまな身体特性をもった人びとが一律に「コミュニケーション/社会性の障害」という診断名を押し付けられ、社会から排除されているという現状があるのではないか、ということです。

病名に限らず、レッテル貼りに使ってしまい、言葉を「問題を適切に分類して解決するための手段」として使ってこなかったことも、今考えたらあります。

また、こちらの文章も考えさせられました。（発達障害ではないのですが）私にはアメリカ出身の友達が何人かいて、彼らと知り合って駅で戸惑っている姿を見る前は「駅の看板の漢字が読めずに困ることのある人がいる」ことに私自身が気づきもしなかったので。

多数派の身体を共有している人たちは、自分たちを取り囲んでいる多数派のルールに違和感がないため、無自覚でいることができます。そのため、実は言語化できておらず、少数派に属する人たちから「どうしてこういうときにそういう行動をするの？」と質問されても、「そんなの当たり前でしょ！ひねくれた質問しないで！」とはねつけることになりかねません。

多数派・少数派に限らず、後輩のメンタリングをする際に「なんでこういう設計をしているのか？」と質問されることはあるので、そういった意味でも、できるだけ理由を明示できるようにしていきたいです。そうすれば、お互いの勉強になるし、運が良ければ議論してもう少し良い実装が見つかるかもしれません。

最後に

自分に合ったやり方を設計しつつ、エンジニアリングの仕事を…だけじゃないですね、開発者人生を楽しんでいきましょう💪

正直自分はソフトウェアエンジニアとして伸び悩んでいる気がするのですが、それはそれとして自分や周囲のプレイヤーも楽しめる（あるいは楽しむ邪魔をしない）ように工夫したいです。タイトルに反して、それほど技術者に限らない話になってしまいました。

また、当時の研究会の様子がこちらに紹介されていました。

d.hatena.ne.jp

ソーシャル・マジョリティ研究: コミュニケーション学の共同創造

タイトルは以前読んだこちらの記事を真似ました。こちらも「論理的な会話のルール」が明示されている素晴らしい本です。

medium.com