自閉症の人の綴る言葉はすごく心に突き刺さる

自閉症の僕が跳びはねる理由 (角川文庫)

我が家は長男が自閉症と診断されていて、現在は療育施設に通いながら通院も時々しつつ…という生活を送っている。長男はまだ話すことができないので、話せるようになるためのヒントがあればと思い、Amazonで色々と本を購入して勉強しようと思っているときに見つけた。自閉症の人が綴った本。タイトルが「自閉症の僕が跳びはねる理由」なんて、すごく気になった。自閉症の子の特徴として、その場でグルグル回ったり、ピョンピョンと跳びながら大声を出したりというのがあるのだけれど、うちの子も正にそれが当てはまっているから、それの理由がわかるのなら、純粋に、知りたい。そう思った。

東田さんが中学生の頃に書いた本で、訓練の末に、文字盤を使ったりパソコンのキーボードを打ったりして筆談ができるようになって、この本を書いたらしい。そして、本を読んだら（言い方が悪いのは承知の上だけれど）ちゃんとしてそうなのだが、会話でのコミュニケーションはできないし、声が出るのを抑えられないとか、どうも軽度の発達障害とかではないみたいだった。

本は、質問形式で58個あり、それに東田さんが答えていく。

想像もできない感覚

健常者からすると、全く想像もつかない感覚であることがわかった。時間の感覚が違うこと、自分の体をちゃんと認識できないこと、すぐ忘れてしまうこと、思っていることが言葉に出ないこと、逆に思っていないことが言葉に出てしまうこと…。そして、精神はちゃんと成長しているのだけれど、他人とコミュニケーションがとれなかったり、物事をうまくできなかったりするから、すごく小さな子ども扱いをされて傷ついてしまうとか…。体が全く思い通りにならないというふうに書いてあるのが健常者としては「いやいや、自分の体やん！」と不思議に思うのだけれど、心と体の意思疎通がうまくできない、という状態のようだ。

悲痛な叫び

心で思っていることと、体で行われる行動が伴わないため、誤解されることが多く、それですごく傷ついたり、辛かったりするそうだ。「手をつなぐのが嫌いですか？」という質問のところで、「いやではないけれど、他に興味があるものが目に付くと、手を振りほどいてそちらに行ってしまう。自分でもいつ手を振りほどいたのかわからない」という答えがあるのだけれど、うちの子ももしかしたらそうなのかもしれない。

突然泣き出したり、笑いだしたりするのも、時間の感覚がわからないからか、辛いことを不意に思い出したり、楽しかったことを思い出したりして、急になってしまうらしい。こういうことも、よくある。

声をかけても無視するのはなぜ？という質問にも「声をかけられていることに気付いていないから」という、全く想像もしていない答えだった。てっきり、言葉が理解できてないからなのだと思っていた。だって、あれだけ目の前で声をかけたり、ジェスチャーしたりしているのに、気付いていないなんて！でも本当にそうなんだろうなと思えた。「名前を呼んで、気付いてから話しかけてほしい」という答えに、自分も気を付けようと思った。

質問の答えでたびたび、根気よく助けてほしい、理解してほしいというメッセージが伝わってきた。親がそんなふうに思うなんてと思われるかもしれないが、本当にしんどくて、どう接すればええんや！とストレスになることが度々ある。しかし、その態度こそが彼らを傷つけてしまうことにもなるし、こっちを落胆させていると感じて、申し訳ないと凹んでしまうらしい。感受性は強いのだと思う。だからこそ、その行動への理解が大事だ。

知りたかったことばかり！

あくまで東田さんの感覚であって、うちの子の感覚ではないので、必ずしも一致しないとは思うけれど、偏食の理由とか、バイバイするときの手の平が自分のほうを向いている理由とか、ダメなことを繰り返してしまう理由とか、すごく腑に落ちた。これはこう言われないと絶対にわからないと思う。何度も書くけれど、自閉症の子の行動の理由が理解できるようになると、気持ちに受け入れ態勢ができるので、寛容になれると思う。そうでないと、本当にしんどいだろう。いい親であろうとすればするほど、うまくいかないことで「私たちの何が悪いのか？」に気持ちがフォーカスしてしまい、頭ではわかっていても、つい自分たちを責めてしまう。

理解から、寛容さと余裕が生まれる。理解できれば、根気よく手伝うのを頑張ろうという気持ちになれる。

絶対に読むべき

もし自閉症児が身近にいるのであれば、対処法とかの本よりも優先して、絶対に読んだほうがいい。私も常々、「なんとかして直せないか、よくできないか」と、よく考えてしまっていた。そういう気持ちが先走ってしまう前に、本人の感覚・感情に理解を示して、寄り添えるようにならないと、お互いに幸せになれないのじゃないか？と思う。自閉症は本人はもちろんのこと、周囲の人も含めて、直すものではなくて長く付き合っていくものだと思うので、より理解を深めていくよう努めていく。

東田さんは何冊も本を出されているので、できるだけ読んでいこうと思った。

株式会社リゾームで昇進しました

うちの会社は期首が9月で、今期で昇進した。世間では退職エントリーとか入社エントリーが多いから、自分は昇進エントリーを書く。

専門職に昇進した

私の勤める会社はキャリアとしてマネジメント職と専門職がある。今回は専門職に昇進した。専門職というキャリアパスは、私が入社した当初は存在せず、役員との面談の際などで「管理職以外のキャリアパスがないと、管理職になれなかった人たちや、プロパーの人達の目指すべきキャリアパスがない。意欲のある人は辞めていくのでは？」と言っていたら、数年前に作られた(私が言ってたからだけではないと思うけど)

専門職の職責

専門職にもランクはあるが、今回は一番下のもの。職責は、

• エキスパートとしてのプロダクト開発
• 技術選定の舵をとる
• 後輩の育成
• その他、幅広く課題解決に取り組む

みたいなところで、一般職より範囲が拡がっている。

専門職になるには？

マネジメント職は、ポジションが空いていて適任と思われる人がその職に就く。しかし専門職は期が変わる前辺りで立候補というか自己推薦する必要がある。自分が専門職としてふさわしい人材であるとアピールする必要があるわけだ。具体的には、今までの実績や資格、社内や社外での評価、専門職になったらどう組織に貢献できるか等。

上司に相談して、そのあたりのアピール方法を一緒に考えてもらったりもした。

その申請が役員会議で通れば、次期から専門職となる。通らない場合は、通らなかった理由をフィードバックしてもらえるから、また次に挑戦すればいい。

専門職への挑戦

実は、専門職が創設されてから、弊社に転職してきてすぐ専門職になっているケースや、勤続年数が長いが部下のいるポジションではなかった人が専門職になっているケースはあったのだが、実際に立候補して専門職になった人はまだいなかった。

このままだと、そういう人達向けの調整ポジションになってしまいそうと感じたので、自分が申請してみようと考えた。私が専門職になれば、後輩たちに実際に通れるキャリアパスがあると認識してもらえるし、例えなれなかったとしても、何を満たせば専門職になれるのかを、より具体的に周知できるだろうから悪いことは無さそうだなと判断した。

結果的には専門職になれたので、自分以外の人達にも転職以外にもキャリアパスあるんだよということが示されてよかったと思う。

年収上げたければ転職という風潮に抗いたい

人材流動性が上がることはよいことだと思う。しかし自分の価値をあげるのは転職だけというのはなんだか寂しい。もちろん、他所でやりたいことが見つかったとかなら、それは仕方のないことだと思う。

専門職に昇進したので、年収はあがる。転職しなくても年収はあげられる。Podcastで聞いた記憶だが、「転職できる実力を持って会社に残る選択をするのが最良」というのが、私もよいと思う。

弊社はまだまだ悪いところというか古臭いところもあるけれど、社員からのフィードバックには応えてくれるし(今回のキャリアパスの創設とか)、育児休暇取らせてくれたり、リモートワーク可能になるなど、家庭の都合に寄り添った制度に柔軟に変更していってくれている。変わろうとしてくれる。そういう会社だからこそ、貢献していきたいなと私は思う。

挑戦はこれから

まだ専門職になっただけなので、これからが挑戦！結果を出していかないと専門職からの降格はあり得るので、組織に貢献できる取り組みをどんどんやっていこうと思う。

FiNC様に会社訪問してきた

仕事で東京出張があったので、目的の打ち合わせが終わった後にどこかに会社訪問してみたいなーと思ってtwitterで募集してみたのだが、突然だったからか、反応が悪かった。しょうがないから23時にラーメンを食べに行った。

うち来てもいいよ！という開発会社さんありませんでしょうか？ https://t.co/MuiT4eECmH

— パトラッシュ@昇進エンジニア (@patorash) August 22, 2019

いきなり言われてもなかなかいいよって言ってくれるところはやっぱりないかなぁ。とりあえずラーメン食べに行くか…。

— パトラッシュ@昇進エンジニア (@patorash) August 22, 2019

多分初めての日高屋。美味しかった！ pic.twitter.com/c7rhy1CLld

— パトラッシュ@昇進エンジニア (@patorash) August 22, 2019

日高屋、初めて行ったと思う。美味しかった。会社の昼食用チャットで話題になったことがあったので行ってみたかったところ。

それはともかく、twitterで募集してもあかん！と思ったときに、ふと、最近勢いのあるSlackのruby-jpの存在を思い出したので、そこで募集してみたところ、応答してくださって、FiNC様に訪問できることに！ありがたい～🙏Rubyコミュニティの温かさに触れた瞬間だった。

FiNCについて

FiNCはヘルステックの企業で、最近は中村アンさんを起用したCMを打っててよくテレビで見かけるようになりました。実は自分は今年のRubyKaigiで見かけるまで知りませんでした。

finc.com

RubyKaigiの懇親会でFiNCの方と話す機会があって、業務内容が色々やっているみたいだったから、会社訪問できることになって嬉しい。

案内していただいた

突然の訪問にも関わらず快く受け入れていただいて、社内を一通り案内していただけました。ちなみに私と後輩の2人で伺いました。 会社訪問に慣れてないもので、会社の入り口の写真を撮り忘れてしまったけれど、オシャレな受付でした。オフィスとフィットネスジムが併設されていて、フィットネスジムは一般の方が来るところだそうです。

そして、執務スペースめっちゃ広い。社員数240名くらいということで、開発・マーケティング・デザインと分かれているみたいで、外国人の方も多く働かれているようでした。

その後、開発部屋に案内していただきました。開発部屋のほうはかなり静かで、集中してコーディングする空気。空いているデスクにもディスプレイアーム付きのディスプレイが既に置いてあったのが印象的でした。本棚も技術系の本がビッシリと並んでいる、かと思いきや本棚の下の段にはボードゲームがビッシリとありました。みんなでボードゲームをしたりするそうです。いいなぁ～。

フィットネスジムのほうも軽く案内していただいたのですが、その途中で棚に置いてある健康食品とかサプリメントとかの話になって、フィットネスアプリとジムだけではなくて、ECもやっていて、コラボやタイアップした商品を販売しているということが聞けました。ジムの会員さんに有効な健康食品を案内したり販売したり、トータルで健康をサポートするからということで、多角的で面白そうだなと感じました。

https://mall.finc.com/

フロアを移動

「実はフロアがもうひとつあるんです」と言われ、エレベーターでフロアを移動。こんだけ広いのにまだあるのか！と思いながら移動すると、超広いフロアが…。イベント用スペースだそうです。

FiNC様のイベント用のスペース。めっちゃ広い！

フィットネス系のイベントや、IT系のイベント、会社の集会などをそこで行っているようです。まぁこれだけ広いと社員が240名いても入りそう。バーカウンターがあって、イベント後に飲んだりすることもできるとか。壁にはFiNCのイメージ動画がずっと流されていたのですが、ここでスマブラ大会をやったことがあるとか。めっちゃ楽しそう。

調理師が正社員！

奥のほうに部屋が2つあり、1つは広めのキッチン、もう1つは撮影用・配信用のスタジオでした。調理師を正社員として雇っていて、これから従業員のランチを作っていくために手続きや環境を整える準備を進めているということでした。すごーく羨ましい！！社員に健康的な食事を、ということで素晴らしいなと思います。

開発者募集中だそうです

案内していただいた方は入社3年目でRailsエンジニアの方だったので、お互いどういうことをやっているのか等、話しました。開発と保守のバランスの話とか。これだけ人数がいても足りないのか…と思ってしまうけれど、メルカリとかもtwitterで開発者足りないって言ってるし、どこも人材争奪戦ですね。

まとめ

勢いのある会社すごい。突然にも関わらず受け入れてくださったFiNCさんありがとうございました！

Podcastを聴くようになった

スマホを新しくしてからというもの、小さなライフ チェンジングを色々としていて、それの１つがPodcastを聴くようになったこと。仕事しながら聴いたり、家事しながら聴いたり、通勤しながら聴いたりしている。車のオーディオと接続がよくなったので、気軽にできるようになった😆

大体はエンジニアがやってるやつを流し聞きしてるんだけれど、仕事しながら聴いてるとあんまり頭には入ってこない。まぁでもラジオの代わりみたいな感じで時々「わかる！」とか「その発想はなかった」みたいな話とか出てくるので継続していこうかなと思う。

そもそもPodcastを聴かなかったのは、よいアプリを知らなかったのだけれど、スマホを機種変更したタイミングでアプリを入れ直してたらGoogle PodcastというGoogleが作ったアプリがあったので入れてみたら思いの外よかった。再生速度も細かく変えられるし。

ただ、エンジニアのPodcastを速く聴くと、エンジニア特有の語り口が、早口になってなんとなくヤバイ人感が増したので、あんまり速くするのは微妙だった😥

文化を育んでいきたい

あんまり思っていることをブログに書いたりはしていなかったのだけれど、考えていることを文章として残しておくことは、後々の振り返りに使えるかなとも思うので、今後は書いていこうかなと思う。

数ヶ月前から、社内でフロントエンド技術勉強会と称して、勉強会を開催するようにした。ちょうど新入社員も入って2ヶ月目あたりなので、バリバリの技術情報というよりはHTML、CSSの基礎的なところを踏まえていくという辺りを焦点とした。すでに対象の本は読み終えて、今は皆で課題に取り組んでいるところである。

これは私なりの意図があって、新入社員の人たちのスキルアップもあるが、それ以上に「就業時間中に勉強会を開催してもよい」という認識をしてほしかったというのがある。就業時間中に仕事以外のことをするのは良くない、という認識はいいのだが（個人的にはよくないけど）、「スキルアップに取り組むことも充分仕事の内に入ることなのだ」、と思ってほしい。

投資は必ずよい結果が返ってくるものではない

仕事なので投資した分の結果（見返り）を求められるのは、そりゃそうだ、とも思うのだが、投資に条件が付きすぎると段々億劫になっていく。必ずよい結果を出すとか、ちゃんとまとめて形にしなければならないとか、プレッシャーがあると伸び伸びとチャレンジできなくなっていく。自分は性善説寄りの思考をしているので、いうても完全に仕事と全く接点のない遊びを業務時間中にはやらんだろうから、自由にさせて、成果が出たら知見を共有していく、という風土にしていきたいと考えている。全てのチャレンジで成功しなくてもよくて、見返りを求められなくてもよくて、試行回数を増やしていく方が重要かなと思う。

認知を変える

就業時間中に読書会、というのは、なかなか新入社員からは提案できないことだろうし、そもそも思いつきにくいだろうと思う。そこで、先輩である自分たちがそれを行うことで「こういうのやってもいい会社なんだな」とまず思ってもらうことが大事。すると、参加者は今後、「次はこういう勉強会しませんか？」と提案しやすくなるだろう、という思惑がある。

主体性を持ってもらう

仕事をする上でずっと受け身でいたい人というのもなかなかいないと思うので、読書会をある程度こなしてきたら、参加者に読みたい本を選んでもらおうと考えている。小さな粒度で主体性をもって決断する機会を設けていく。まぁ大した効果があるかどうかはわからないけれど、何事も慣れなので、そういう場を社内で作ることはいいことかなと思う。また、読みたい本を選ぶ=自分にとって必要な領域は何かを見つめる時間になる、と思う。

継続する

社内勉強会・読書会は基本的には緩くてもいいからずっと継続していきたい。読書会でなくなってもいいから、なんらかの形でスキルアップする会として残していけるようにしたい。そして、それが普通になっていくようにというか、むしろ増やしていきたい。

組織にとって継続は風土・文化になる

文化はある日突然持って来て適用できるものではない。長い時間かけて、守りながら育てていくものだろうと思っている。よっぽどその文化にフィットする人達だけが集まっていたらすぐに浸透するかもしれないけれど、そういうことは稀だ。

そういう文化があるところに転職する方が早い、みたいなことを言う人もいるだろうけれど、その文化も先人の誰かが育てたものなわけで、ならば自分は今の組織で文化を育んでいく側となっていきたいと考えている。

複数やっていく

技術寄りの勉強会と、技術ではなく組織論・思考法・設計なりの勉強会の両輪を回していこうと考えている。これはどちらも仕事する上では大事なこと。技術系が好きなエンジニアは後者寄りの本を自分で読む機会は少ないだろうから、そういう機会を準備してみることで、知見が補完されていく。また、後者のものは他者と意見交換しながら読み進めると新たな気づきが多い。他人の考えを輸入する機会を作って、視野を広げていってもらいたい。

まぁなんだかんだ言っても、自分のためでもあるだけれど、そういうことができる組織って素敵やんと思うので、理想を求めて文化を育んでいきます。

コスパ重視でGalaxy A30に機種変更した

以前まではArrows M04を使っていましたが、使い始めて2年が経過したのでそろそろ機種変を…と思い、後継機種を探すも、ない！！Arrows M05まだ出てない！！！ 

仕方ないので他のブランドで探すことに。

Arrows M04の総括

悪かった点

M04は基本的によかったのたけれど、不満点も多々ありました。

• 容量が16GBしかない
• メモリが2GBしかない
• カメラのピントがなかなか合わない

等々。

良かった点

無論、良かった点もたくさんあります。

• 見た目は普通ながらも、タフで壊れにくい
• 防水である。洗剤で洗える
• おサイフケータイである

やはり日本仕様に慣れているため、今後機種変更するにしても、防水とおサイフケータイは外したくありません。

Galaxy A30に決定！

候補は色々ありました。本当に欲しかったのはAquos zeroでしたが、10万円位したため、手が出せず…😣容量128GBとメモリ6GBあるし、他の点でも優秀なので高いのは仕方ないかなとは思います。

mineoユーザーなので、当初はmineoから販売している端末で探してたのですが、いわゆる日本仕様を満たしていて、かつ不満点を解消した手頃な価格の端末があんまりありませんでした。

そこで、mineoからの直販以外で探して見つかったのが、Galaxy A30でした。

仕様に不満点がなかった

Galaxy A30はau, UQ Mobile等から発売されています。mineoでも使えることをmineoのサイトで確認しました(au simであること！)。

• 防水
• おサイフケータイ
• 容量64GB
• メモリ4GB
• micro sdカードを512GBまで認識
• AndroidのバージョンがPie
• 指紋認証がある
• 大容量バッテリー

ミドルレンジのスマホとしては完璧😃✌️

価格がお手頃

気になるのはお値段なのですが、これだけの仕様を満たしながら、なんと3万円くらい。私はラクマでUQ Mobile版を購入しましたが、それくらいでした。

Galaxy A30の使用感

以前の端末がロースペックだったのであれですが、めちゃめちゃ快適です。サクサクです。カメラ性能も私的には充分よいです。おサイフケータイ使えるのは本当に便利。

指紋認証が便利

最初は指紋認証はオマケみたいなもん、という気持ちだったのですが、めちゃくちゃ便利です。パスワード管理アプリが指紋認証に対応しているので、マスターパスワードを入力しなくても指紋認証だけで済むのが最高です。あと、楽天銀行の認証も指紋認証でできました✌️こんなに便利なら指紋認証のあるスマホにもっと早く変更しておけばよかった😂

容量が全然余裕

私は容量16GBの壁に飼い慣らされた、よく訓練されたユーザーなので、ポケモンGOとかすぐ削除していたのですが、全く余裕です。現時点でまだ40GB余っていて、「使いきれるのか…？」という気分です。

まとめ

コスパ重視なら、かなりアリなスマホです！！

mutationでバルク処理をする場合のアプローチ

mutationでデータを更新するGraphQL APIを作りました。しかしそのAPIが時々しか呼ばれないならいいのですが、頻繁に何度も呼ばれるケースだとAPIのへのアクセスが複数回になり無駄が多いので、バルクアップデートみたいなことはできないか？と指摘を受けました。個人的には、「うーん、そうはいってもAPIってそういうもんでしょ…。」と思っていたのですが、他のサービスのケースとかを参考にしてみますと回答して、調査開始。

1度のmutationで同じAPIを使い回す

ググると、バルク処理用のAPIを作れみたいな記事が見つかってコレジャナイ感があったのですが、遂に以下の記事を見つけました。

blog.grandstack.io

path名をつけることで、同じmutationを複数回使うという方法です。 以下のように使います。

mutation {
  path1: updateUserName(input: { userId: 1, name: "foo" }) {
    user {
      id
      name
    }
  },
  path2: updateUserName(input: { userId: 2, name: "bar" }) {
    user {
      id
      name
    }
  },
  path3: updateUserName(input: { userId: 3, name: "baz" }) {
    user {
      id
      name
    }
  }
}

すると結果は以下のように返ってきます。

{
  "data": {
    "path1": {
      "user": {
        "id": "1",
        "name": "foo"
      }
    },
    "path2": {
      "user": {
        "id": "2",
        "name": "bar"
      }
    },
    "path3": {
      "user": {
        "id": "3",
        "name": "baz"
      }
    }
  }
}

おおお、1回のアクセスで3つ更新できた🎉

バルク処理のエラー検知

でもこれってエラーになったらどう検知するのよ？と思い、無理やりエラーが起きるようにしてみました。上記でいえば、存在しないuser_idを渡すとかです。

mutation {
  path1: updateUserName(input: { userId: 1, name: "foo" }) {
    user {
      id
      name
    }
  },
  path2: updateUserName(input: { userId: 2, name: "bar" }) {
    user {
      id
      name
    }
  },
  path3: updateUserName(input: { userId: -1, name: "baz" }) { # そんなユーザはいない！
    user {
      id
      name
    }
  }
}

そうすると、以下のような感じで返ってきました（実装次第ではありますが…）。

{
  "data": {
    "path1": {
      "user": {
        "id": "1",
        "name": "foo"
      }
    },
    "path2": {
      "user": {
        "id": "2",
        "name": "bar"
      }
    },
    "path3": null
  },
  "errors": [
    {
      "message": "ユーザが見つかりません",
      "locations": [
        # 略
      ],
      "path": [
        "path3"
      ]
    }
  ]
}

errorsの配列の中のpathの値を見たら、どのpathでエラーが起きているかが分かるので、対処しやすくなるかと思います。

所感

1つのデータ更新用のAPIと、バルク更新用のAPIをわざわざ作らないといけないのかなー？🤔と考えていたところだったのですが、これならば実装1つでいけるので、大変やりやすいです🥳ただし、トランザクションが必要になるケースの場合は、バルク更新用のAPIを作らないといけないでしょう。