プログラマーが発達障害検査を受けました
何故受けたのか
元々、睡眠薬を貰うために精神科に通っているのですが、「仕事のコミュニケーションの面や、集中力が続かなくて困る事がある」と伝えたら発達障害検査を勧められました。 前々から「自分が発達障害では?」という気が薄々していたり、子供の頃に言葉を喋りだすのが遅かったり、交友関係を築くのが難しいなど心当たり自体はたくさんありました。
自分が受けたのは「AQテスト」と「知能検査 (WAIS-IV)」です。 検査は医師と1対1で行いました。
AQテストの結果
このテストは自分の性質や性格に対しての質問に筆記で答えるものです。 小さい頃に、何か物に執着があったとか、人の感情を察するのが苦手……などです。 自分はこのテストでは「ADHDまたはASDの兆候が見られる」と判断されました。
知能検査 (WAIS-IV) の結果
試験詳細はネタバレになるのですが、筆記、パズル、聴覚を通じて行う検査です。 各項目としてはこんな感じです。
- 全検査IQ 各項目の平均、いわゆるIQと言われる指数
- 言語理解 言葉に対する理解力
- 知覚推理 図形などの視覚情報を処理する能力
- ワーキングメモリー 聴覚で記憶した情報を保持する注意力
- 処理速度 視覚で認識した情報を基に作業を行う能力
自分の結果は下記になります。
なんとなく低いだろうと思っていたワーキングメモリーが丁度平均でした。 また処理速度も遅いとは予想していたものの、それ以上に低くて、時間制限に余裕がないタスクをこなすのが苦手な理由も合点がいきました。 ここらへんに「口頭の指示をメモする」が苦手な理由がありそうです。
言語理解と知覚推理は手応えはあったとはいえ平均より上で驚きました。 何に役立っているか考えましたが、思い当たる節としては下記です。
検査結果として「処理速度」が平均よりも下回るレベルで低いことがネックになっていることがわかりました。 試験の総評として「一度に大量の仕事は引き受けず、一度に処理する仕事の量を制限する必要がある」とありました。
ADHDかASDか
2つのテストの結果はASD寄りと判断されました。ADHDの場合は知能検査の「処理速度」が高い傾向にあるそうですが、自分は逆に低いのでASD寄りと判断されました。
自分がプログラマーとして助かっていること
ASDや知能特性を踏まえた上で、現時点でプログラマーとして就労していて、この点が楽だと思うことです。
- 口頭での複雑な指示ではなく、基本的にチャットツールを通じて文章で指示や情報共有すること
- チケット管理ツールなどで具体的なタスクを記載して管理していること
- 1人で集中して作業する時間、空間があること
- 職場によってはリモートワーク可能で、落ち着いた環境で作業できる事
- 作業効率のムラを時間でカバーするのもある程度柔軟にできること
今まで働いてきたIT企業が全部こんな感じだったわけではないのですが、IT企業文化として、「チャットツールによる文章指示」「チケットによる具体的なタスク管理」があります。それが自分の「口頭で指示された事を覚えるのが苦手」をカバーできています。
また、多くのIT企業には給料に固定残業代が含まれており、毎度残業申請しなくても「今日はキリがいいところまでやりたい」と作業優先で進めることもあります。作業効率のムラに関してもこれでカバーができています。
現在では出社回帰の流れもありますが、リモートワーク可能な会社は多いです。一時的に出社した事があるのですが、疲労感がかなり酷く、体力的にかなりキツかったことがあります。
総合すると現時点のプログラマーとして就業する上で、知能特性のデメリットはカバーできて個人作業できています。
ASDを抱えた上でキャリアをどうするか
上記で個人作業するのは問題ないと書きましたが、仕事をする上で問題がないわけではありません。
コミュニケーションに難があるため、転職面接をした際に不利になることが多い 管理職として働くには向いていないため、キャリアの制限がある
業務委託契約で、契約期間を期に職場を変えたい場合は企業担当者と「面談」をします。実質的に転職の面接と同じです。 自分は「コミュニケーション・コストが高そう」「コミュニケーション文化が合わなさそう」という点で何度も見送りされており、数ヶ月失職することが度々ありました。一旦就労できればある程度問題ないけど、就労するまでが大変です。
医者にも相談してみましたが、ASD傾向がある人はあまり管理職は向いていないと言われました。 自分のコミュニケーションについて振り返ってみると、例えばチャットで、相手に勘違いさせないようにクッション言葉を入れたり丁寧語にしたり、補足説明を入れたり……など、相手の立場に立って考えると時間がかかります。 定期連絡やドキュメントのような「不特定多数の人に向けた情報共有」の文章は問題ないけど、特定の個人に向けたコミュニケーションの文章を考えるのは苦手な傾向があると思います。
じゃあ管理職にならなければどうするのか……ですが、 Individual Contributor という役職があります。 簡単に言えば人の管理はしないけど個人でバリバリ作業する人です。 目指すならこの方向だと思いますが、個人の興味や体力だったり、難しいタスクに取り組むプレッシャーを楽しむ実力を保持する必要がありそうです。 そもそもこの役職がある会社を見つけるのが難しそうです。
発達障害とどう付き合うか
どの役職でも、日常生活でも、コミュニケーションは避けられません。 が、コミュニケーションをする上で時々相手をイラつかせる事があります。自分としてはイラつかせるつもりが無くてもです。 ここで「自分は発達障害だから分からない」と言えば、イラつかせた相手からしたら「発達障害を免罪符にしている」と更にブチギレされるでしょう。
個人的な処世術は下記です。
- 相手をイラつかせている事に気がついたら素直に謝罪する
- 「こういう時は、こういう事を思っている事が多い」とパターンを覚える
- 無駄に他人の発言に悪意を汲み取らない
- 個人作業が金になる仕事を選ぶ
- 組織外部の人とのコミュニケーションは他の人に任せる
初見で分からない事はもう仕方ないので次回に活かしましょう。
余談: 検査するかどうか迷う人へ
発達障害検査ですが、やってみた感想として「説明書のない電化製品に説明書が後付された」という所感です。
自分が何が苦手か、それに対してどうすれば良いのかを考える道標にはなると思います。 とはいえ精神的な症状は病院に行きだすのが結構難しいです。自分は以前から内科の通院をしていましたが、精神科に行くのは躊躇しました。 そんな自分が精神科に行くようになった契機は、身近な人とのコミュニケーションのトラブルと、面接お祈り続きで失職の実害でした。 明確に「生活が困難になっている」という指標があったので行けるようになりました。
また発達障害検査ですが、手間と時間がかかるので、診察室が複数あるような少し大きめの病院を選ぶことをおすすめします。 最初に通っていた病院は小さいクリニックだったため検査はできませんでしたが、転院して大きめの病院だったのでできるようになりました。
面接がとにかく分からない
面接がとにかく苦手であり、面接官には常に不信感がある。なんの理由もないのに「全部○だと仕事してなさそうだから」という理由で適当に×をつける。それぐらい不信感がある。
特に開発現場で働いていない、営業の人が面接官だと警戒度は高まる。現場の事情を又聞きでしか知らないため、肌感覚が無い。
そのため話し方を合わせて変える必要がある。
例えば、スキル感をエピソードベースで話すがなんとも腑に落ちてなさそうというか、全然ピンと来てなさそうで困る。自分なりの解決策として「ReactとTypeScript歴5年です!」と経歴年数を強く主張するように話したら通るようになった。
正直、経歴年数とスキル感は全然一致しないし比例もしないが、経歴年数でのフィルタリングは採用で広く使われているので諦めて従う事にした。
無事にそこそこ技術が分かる人との面接に漕ぎ着けても、まだまだ課題はある。
「○○出来ますか?」「××が使えない制限がありますが問題なく作業できますか?」という「はい以外答えるメリットがない」質問に、勢いよく「はい、問題ありません」と答える必要がある。
自分はどうしてもこういう質問には茶番を感じてしまい、「そんなの、はい以外答えようがないですよ」と冗談めかして本音を漏らす。この点は仲介エージェントさんから猛烈に怒られた。「仮にそう思っても、商談の場で不愉快にさせる振る舞いは失礼です」と。
自分の欠点はとにかく思った事を全部喋ってしまう事だ。
またちょっとでも弱気の発言をすると足切り要因となる。「バックエンドについては実務的な経験は薄いですがキャッチアップして対応していく予定です」と答えると「バックエンドの経験が足りない」で落とされる。
正解がわからないが「バックエンドも問題ありません!」と盛った発言をすべきだったのだろうか。
こういう盛った発言をしたくないのは一緒に働く人に対する配慮の気持ちもあるが、面接官としては「自信がなさげだ」と写るのだろうか。
とにかく嘘をつくのが苦手で、誠実になろうとした結果、弱気で自信なさげな人に映って落とされる。
自分が高倉健なら「自分、不器用ですから」で格好がつきそうだが、現実は厳しい。策を打たねばならない。
なので「面接対策」をする必要がある。何度も聞かれる事は練習したり、ネガティブな点に対してポジティブな言い回しを考えたり。スラスラとハッキリ喋れるように準備する。そういうふうに喋るだけでコイツは出来そうと思われるらしい。
技術職の一部には面接対策に対して「口が上手いだけの詐欺師が通過するだけだ」と揶揄する向きもある。しかし何度も落とされて失職する危機を何度も経験すると、そんな理想論じゃ飯は食えねぇよと痛感させられる。
面接は何が正解なんだ?と思うが正解なんてないのだろう。
慣れている人にとっては、面接は単なるコミュニケーションだろ?と思うが、それが僕にとっては難しい事だ。
テスト用にGitHub ActionsのサービスコンテナでDBを建ててアクセスするときのメモ
書いた契機
GitHub Actions上でテストを実行する際に、使い捨てのデータベースにアクセスしたいと思いドキュメントを読んでいた。
これを読んでいて「コンテナーからサービスコンテナにアクセスするのと、ランナーマシンからサービスコンテナにアクセスするときの違いってどういうこと?」と思ったのであれこれ試行錯誤したメモ。
初歩的な理解ができていなかったので結構理解するのに詰まってしまった。
要約
- GitHub ActionsのランナーマシンではDockerが動くので、コンテナ上でもJob を実行させることができる
- サービスコンテナはJobを実行させるコンテナとは別にコンテナを起動させて、Jobと通信することができる
- 用途として、PostgreSQLとかRedisを起動させて、スクリプトを実行するなど
- ランナーマシン上で直接Jobを実行する時はマシン内のDockerにアクセスするのでホストのパスが
localhostになる (図の左) - コンテナ上でJobを実行する時は、同じDocker内のコンテナにアクセスするので ホストのパスがサービスコンテナのラベルになる (
postgres/redis) (図の右)
自分がコンテナ上でJobを実行させたことがほぼなかったので、直接ランナー上で実行する違いを全然理解していなくてちょっと混乱した。
選べるならどっちがいいの?
個人的な開発スタイルだと、Node.jsなどはローカルで、必要なデータベースなどのミドルウェアはDockerで建てることが多い。ので、GitHub Actionsで動かすときも似たような環境がいいので、Jobはランナー本体、PostgreSQLはサービスコンテナで運用したい。
setup-node みたいなActionを使った方がcacheのコントロールもしやすいと思うので、その点でもランナー上で実行するようにしたい。
最終的にWorkflowはこんな感じになった。
name: PostgreSQL Service Example on: push jobs: runner-job: runs-on: ubuntu-latest services: postgres: image: postgres env: POSTGRES_PASSWORD: postgres options: >- --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 ports: - 5432:5432 steps: - name: Check out repository code uses: actions/checkout@v4 - name: Setup node uses: actions/setup-node@v4 with: node-version: 20 cache: "npm" - name: Install dependencies run: npm ci - name: Connect to PostgreSQL run: node client.js env: POSTGRES_HOST: localhost POSTGRES_PORT: 5432
コンテナでJob実行する場合の差分はこんな感じ。
jobs:
runner-job:
runs-on: ubuntu-latest
- container: node:20
steps:
+ - name: Setup node
+ uses: actions/setup-node@v4
+ with:
+ node-version: 20
+ cache: "npm"
- name: Connect to PostgreSQL
run: node client.js
env:
- POSTGRES_HOST: postgres
+ POSTGRES_HOST: localhost
余談
actions/setup-node よりもコンテナーで実行した方がコンテナをPullする分時間がかかるんじゃないかと思ったけどそんなに変わらなかった。
おまけ: ローカルで実行するとき
GitHub Actionsの公式ドキュメントにPostgreSQLをサービスコンテナで起動して実行するスクリプトが例題としてある。
実際に開発するときはローカルでテストしてからPushしたい。
こんな感じのスクリプトを実行したい。
// client.js const { Client } = require("pg"); const main = () => { const pgclient = new Client({ host: process.env.POSTGRES_HOST, port: process.env.POSTGRES_PORT, user: "postgres", password: "postgres", database: "postgres", }); pgclient.connect(); const table = "CREATE TABLE IF NOT EXISTS student(id SERIAL PRIMARY KEY, firstName VARCHAR(40) NOT NULL, lastName VARCHAR(40) NOT NULL, age INT, address VARCHAR(80), email VARCHAR(40))"; const text = "INSERT INTO student(firstname, lastname, age, address, email) VALUES($1, $2, $3, $4, $5) RETURNING *"; const values = [ "Mona the", "Octocat", 9, "88 Colin P Kelly Jr St, San Francisco, CA 94107, United States", "octocat@github.com", ]; pgclient.query(table, (err, res) => { if (err) throw err; }); pgclient.query(text, values, (err, res) => { if (err) throw err; }); pgclient.query("SELECT * FROM student", (err, res) => { if (err) throw err; console.log(err, res.rows); // Print the data in student table pgclient.end(); }); }; main();
これに対して用意したいdocker-compose.yaml をこんな感じで建てる。
使い捨ての前提なので、永続化のためのvolumesは指定しない。
# docker-compose.yaml version: "3.9" services: postgres: image: postgres ports: - 5432:5432 environment: POSTGRES_USER: "postgres" POSTGRES_PASSWORD: "postgres" POSTGRES_DB: "postgres"
Docker Composeでコンテナを起動してスクリプトを実行。
$ docker compose up -d
$ POSTGRES_HOST=localhost POSTGRES_PORT=5432 node client.js
null [
{
id: 1,
firstname: 'Mona the',
lastname: 'Octocat',
age: 9,
address: '88 Colin P Kelly Jr St, San Francisco, CA 94107, United States',
email: 'octocat@github.com'
}
]
Docker Desktopの代替?となるOrbStackで確認した。早くて良い。
Twitterでエンジニアの仕事募集したらなんとか紹介してもらえたが再び無職になっている
タイトルで釣るの嫌なので結論をタイトルに書きました。
筆者の前提
職業: 個人事業主のソフトウェアエンジニア (主にWebアプリケーション、フロントエンド)
希望報酬: 最低55万円/月
募集ツイート
拡散して頂きありがとうございました。
フリーランスでフロントエンドエンジニアの案件を探しています。
— おじんさん (@Mr_ozin) 2023年11月30日
基本的にReact + TypeScriptが少し得意です。
詳細はGistをお願いします。
DMは開放しています。どうぞよろしくお願いします。https://t.co/KCuKP0O78s
なんでツイートで募集したのか
SNSの投稿経由という面白半分な雰囲気で、自己学習の結果をアピールしながら案件取れると思ったためです。
自分の実務経験はあまりアピールできる箇所がなく、面接でだいぶ苦労していました。
ただそれを補おうかのように、個人学習しまくって知識身につけているのでそれを積極的にアピールしたいのですが、当時利用していたエージェントさんからはそういうのはおすすめできないと言われました。
そのため全然アピールが出来ず、数ヶ月職がなくなったこともあり、ツイートで仕事募集しました。
募集した結果
3社程度エージェントさんから声掛けされて、そのうち1社さんに案件を紹介してもらいました。
手厚く対応頂き様々な案件を紹介して頂きました。ありがとうございます。
その後
紹介された案件は3ヶ月契約の案件だったので、先月で終了しました。
また私事ですが3月頭に左手を完全骨折しました。 現在はギプスも外れて日常生活には支障がない程度まで回復したので、6月以降の仕事を探して頑張っていきたいと思います。
Mr_ozinの2023年振り返り
趣味
映画
今年は「ガーディアンズ・オブ・ギャラクシー:VOLUME 3」が有終の美を迎えてとにかく楽しかった。ジェームズ・ガンもMCUから卒業し、シリーズ自体も最後、つまみ者同士の卒業映画として完璧。 MCUがどんどんマルチユニバースやドラマシリーズを絡めて内輪向け感を強める中、ガーディアンズ映画として独立させた内容なのも好感だった。
「Pearl」はプライム・ビデオで見たが前作「X」よりも断然好きだった。「オオカミ狩り」は2本の典型的な映画をかけ合わせることで新鮮味とバイオレンスを加速させた快作だった。
北野武監督の「首」も初めて同監督の作品を劇場で見たが、これも権力をうまい具合に風刺しつつ、シニカルな笑いとして昇華させていて大変良かった。世界の北野映画と言われる割に配信も再上映もあんまないのでこれを期に改善して欲しい。
ベストには入れなかったけどちょっと悪い意味で広まってしまった「バービー」も、自分たちが生きている現代社会のあり方を提示され、どう生きるのか?とシリアスな風刺をポップに包んでいて、なんで今さらバービーを題材に?と思ったが、正しく現代に沿う良い映画だった。
#2023映画ベスト10
— おじんさん (@Mr_ozin) 2023年12月30日
1. Gotg3
2. Pearl パール
3. オオカミ狩り
4. 首
5. キラーズ・オブ・ザ・フラワームーン
6. SISU/シス 不死身の男
7. フェイブルマンズ
8. ミッション:インポッシブル/デッドレコニング PART ONE
9. イニシェリン島の精霊
10. TALK TO ME
「自分に意外性や新たな視点を与えてくれる映画が好き」というのは特に変わらないけど、アクション映画のバイオレンスとか構成の妙とかも好きになってきた。来年も映画楽しみたい。
キーボード
HHKBが至高だとずっと思っていたけど、改めてメカニカルキーボードを買ってみたらすごくハマった。
買ったのは2個。
- Keychron Q1 V2
- NuPhy Halo75
すごく良い。筐体自体がすごくしっかりしているのもあるが、標準で付いているスイッチとの組み合わせでも十分打鍵感が良い。NuPhyは遊び心あるポップな見た目ながら打鍵感はかなり安定していて、とにかく楽しい。
個人的に打鍵音が静かな方が集中できるので静音スイッチに載せ替えているが、底打ちしてもHHKBのコトコト音程度しか鳴らなくなる。
そう言えばメカニカルキーボード版HHKBが今年発売されたので、来年からゲーミング以外のメカニカルキーボードも流行っていくんだろうなと思った。
体調
基本的にずっと胃腸が悪い。毎日30分ぐらいはトイレに篭っている。逆流性食道炎が慢性的に続いている。何食ってもすぐにお腹が張る。今年3月に胃カメラ飲んで胃がんではないことは確定したがそれでもずっと痛い。
筋トレは目標にしていた自体重超えをベンチプレスで狙う目標を達成したが、体重は全然減らない。上記の胃の不調もあるのに減らない。なのにずっとベンチプレスはすくすくと最大重量が上がっている。不健康なのか健康なのかよく分からない。
ベンチプレス110kg到達記念 pic.twitter.com/w8I6xHALpc
— おじんさん (@Mr_ozin) 2023年12月3日
技術・プログラミング
念願だった個人Webサイトをやっと作った。ドメイン取得して1年ぐらいずっと放置していてやっと作れた。実際に作ってみると要素はどう配置しようか、みたいな悩みが無限に出てくる。デザイナーではないのでこの辺の勘が本当に分からない。デザイナーさん凄い。
生成AIが世間ではブレイクスルーだったけど個人的にはCloudflare Workersが再びアツい。CDN上で動くサーバー実行環境みたいなものだが、基本的にWebアプリケーション作るのに必要な機能は大体パブリックになって、フレームワークのHonoも相まってかなり書きやすい。Discord Botも低コストで作れた。
何故か2022年に書いた結構基礎的なZennの記事が今年になって反応が増えたので、今年になってCloudflare Workers触りだした人が増えたんだろうなと推測している。
結局AWS勉強すると言いながらちょっとしか勉強出来なかったのでちゃんと腰入れて勉強します。
仕事
2022年があんまりにもダメすぎだったので比較すれば大体良いけど、それでも2023年は同じぐらい悪かった。
React + TypeScriptでガンガン開発していたが、人手不足なので別業務にアサインされて、「他人のテスト結果でNGになった項目を仕様書と突き合わせて、確定しなければもっと詳しい人に投げる」という業務を半年間やっていた。これが本当に良くなかった。
無限に愚痴が出てしまうが、プログラミング好きな自分の特性とも全然噛み合っていないのと、職務経歴でプラスにならない業務をやらされるのは、職務経歴を種に新しい経験を増やしていくフリーランスエンジニアには耐え難い苦痛ではある。
結果として3ヶ月ぐらい仕事が見つからず、Twitterで仕事募集した。この辺の経由は後日別ブログに書きたい。辛すぎてフリーランスエンジニアを辞めるか本気で悩んだ。
フリーランスでフロントエンドエンジニアの案件を探しています。
— おじんさん (@Mr_ozin) 2023年11月30日
基本的にReact + TypeScriptが少し得意です。
詳細はGistをお願いします。
DMは開放しています。どうぞよろしくお願いします。https://t.co/KCuKP0O78s
まとめ
映画やプログラミングの趣味は相変わらずずっと楽しいが、体調と仕事がずっとボロボロだった。 来年はボロボロなところを直しつつ。適度にコンフォートゾーンを抜け出して新しい事をやっていきたい。
ライブラリのWhyをしっかり読む
ライブラリの公式ドキュメントの細かいところを読んで手元のコードを直していると、ふと「特定ライブラリに依存したことしかできるようになっていないのでは?」と思う。
じゃあライブラリを一切依存しないのは難しい。簡単なものならできるかもしれないが、プロダクションレベルのことを考えると、要求に対して考えることが爆発的に増えてしまう。現実的ではない。または、既にライブラリが使われているプロジェクトに入ることで利用するパターンも有る。
なのでどのライブラリもサンプルコードと公式ドキュメントをさっと目を通して使えるようにする。業務中のコードなら先人が残した書き方を参考にする。正しいかは別にして、とりあえずさっと使えるようにする。
仕事としてはそれで正しいが、ふと「日々出るライブラリに振り回されているんじゃないか?」と思う様になってきた。
そう思ったので、ライブラリの公式ドキュメントを見るときは、「Why」の項目を読むようになった。「Why」にはそれが生まれた背景が書いてあり、作者の発想の方向性を知ることができる。出発点が分かるので、「設計者はこう考えたのかな?」と、アタリを付けて利用できる。よくわからないまま振り回されるのは減ると思う。
流石に全部のライブラリのWhyは探れないようにしても、コアなライブラリについては読んでおいたほうがいいと思っている。ViteとかReactあたり。
後続ツールは基本的に先発の「課題点」をクリアする、または前提背景が変わってきたため生まれる。その課題点をすくい取る審美眼は、ライブラリが変わっても持ち越せる資産だと思う。
HHKBからKeychron Q1 + Kailh Midnight Pro Silent Switch Linearに乗り換えて、気持ちいい
選定経由
HHKBを6年近く使っていて、壊れる予感も全く無かったが、それだけ使っているとマンネリを感じてしまう。 スペースキーを押した時の「ジャカジャカ」した鳴りが気になってきた。構造上仕方ないとは言え、タイピングが強めなので気になってしまう。
また、Fnキーを押さないと矢印キーすらタイプ出来ないのは日常使いとしては辛い。ソフトによってはF1キーとかに操作が割り振られていたり、ショートカットにF1~F12系列のキーを登録するときに認識してくれない時がある。
そんな中、自作キーボード界隈の盛り上がりを見ているうちに「昔使っていたメカニカルキーボードにまた手を出して」みようか、という気持ちになった。
そこから幾多のセールの見逃しを経験して最終的にKeychron Q1に決めた。
Realforce TKLモデルも良かったが、比較していくうちにKeychron Q1の方が魅力的だった。
Win / Mac切り替えを1スイッチできる
仕事と遊びの都合で接続先PCを毎日切り替えることが多い。RealforceだとWinとMac用で別モデルのためこれが出来ない。多分無視して使えるかもしれないが。
75%キーボード
正直TKLレイアウトでも良かったかもしれないが、机が狭いので少しでも小さい方がいいかも。
スイッチ交換可能
自作にはそんなに興味ないけどスイッチやキーキャップを交換して自分好みに変えられるのはマンネリ解消に良さそう。
ゲーミング光
人生一度は光ったヤツ欲しいじゃん。
使ってみてどうだったか
最初は付属していた赤軸のGateron G Pro Redから静音タイプであるKailh Midnight Pro Silent Switch Linearに換装したのを使っているが、理想的で快適に使えている。
Gateron G Pro Redは赤軸とは言え底打ちすると「バチバチ」鳴る。結構強くタイプするので静音タイプのスイッチに変えてもあまり意味ないかと思っていたが、欲を出して静音タイプに手を出した。
結果的にはKailh Midnight Pro Silentに変えてみて大正解だった。静音タイプとはいえ本当に音が静か。赤軸で底打ちした時のバチバチ音がない。強いて言えばスイッチが擦れる時の音が聞こえる程度。音量的にはシャーペンでちょっと筆圧強めで紙に書いた時程度。多分タイプしながら通話してもノイズが乗らないと思う。
打鍵感もHHKBに少し近い気がする。HHKBは「スコスコ」としか形容できないが、Kailh Midnight Pro Silent Switch Linearは「シャコシャコ」といった感じ。HHKBやRealforceは「静電容量無接点方式」なのでメカニカルスイッチとは原理的に全然違うし、打鍵した時の圧もKailhのほうが軽めだが、これはこれでいい。この軽さは押す時の引っ掛かりがないLinearタイプだからかもしれない。
筐体もアルミニウム製だからか、かなり重く、強くタイプしてもびくともしない。また、クッション機構が仕込まれている模様。試しにキーを押し込んでみると緩衝材みたいなものが仕込まれていそうなのがわかる。 スイッチとキーキャップだけでなくこの筐体の機構も打鍵感の一要素を兼ねているんだと思う。
HHKBと違ってとにかく重く、1.8kgぐらいなので、これを持ち運ぶは流石に狂気の沙汰だと思う。
まとめ・余談
というわけでHHKBからKeychron Q1に乗り換えて満足した。たまたまセールやっていたのでQ1の赤い筐体を買った。
Keychron Q1 QMK Custom Mechanical Keyboard - Version 2
KeychronはQシリーズに限らず、K Proシリーズも充分魅力っぽい。多分持ち運び用に買うかもしれない。 種類が多く見えるが、基本的にQ、Q Pro、K Proシリーズとキーボードのレイアウト100~60%の組み合わせで選べばいいっぽい。
最近だとハの字で打鍵するAliceレイアウトや左右分離レイアウトがある模様。Aliceレイアウトに関しては最近色々な新商品が出ているみたい。
初めてキーボードのスイッチ単品を買ってみたが、種類によっては売り切れになっていることもしばしばあるっぽい。 自分はkeychron.comで買ったが、在庫状況によってはいろんなショップで買い集める必要がありそう。 日本国内だと遊舎工房が品揃え豊富で良さそう。
後々調べてみたらQシリーズ+Kailh Midnight Proの組み合わせが売っていて最初からこれにすればよかったと思った。赤色のボディではないが。
