ねんがんのアルトサックスをかったぞ!

TL;DR

アルトサックス買った。 お金が吹っ飛びました。 練習する場所なくて困ってます。

駄文

SELMERというメーカーのAXOSというモデルのアルトサックスを買いました。

www.nonaka.com

↓のエントリが去年の7月なので音楽教室に体験入学してからだいたい1年くらいで楽器を購入したことになる。

luccafort.hatenablog.com

本当は3ヶ月前の2月末に通っているサックスのレッスン教室の先生に購入したい旨を伝えていたのでそこで選定→購入となるはずだった。 ……がちょうど世間でコロナが騒がれていた時期で小学校や中学校が休校になったり、企業もリモートワーク推奨したりで世間がワチャワチャした結果、レッスン教室自体も休校になってしまい、伸びに伸びてしまいました。残念。 まさか3ヶ月も時間が立つとは思ってなかった。

その後、休校明け一発目にもう一回選定おなしゃす!ってリクエストしてようやく購入ということに相成った。 ところでレッスン教室に一緒に通っていたかたが退校されたそうで、コロナの傷跡は現在進行系で日本経済を蝕んでいるなと実感しました。 選定にはYAMAHAのサックスが3本、購入したSELMERの楽器が1本あって普段練習でレンタルさせてもらってるのが一番安くて今回買ったのが一番高かったです。

選定のときにまず自分で吹き比べてみたところ

YAMAHA 練習で使ったタイプ→普通、いつもと変わらん

YAMAHA ちょっとお高いタイプ→めちゃくちゃ吹きやすい!

YAMAHA 持ってきてもらった中ではお高いタイプ→少し吹きにくさを感じるがサックスらしい音

SELMER 持ってきてもらった中で一番高いやつ→指だとかマウスピースだとか諸々違いすぎて音がまともにでない!

みたいな感触でした。 この段階で①と③は選考から落としていて買うなら②か④だなと考えていました。

理由としては②は吹きやすく扱いやすそうに感じたこと、自分は初心者なので扱いにくいとすぐに挫折するのではないか?という不安から。 ④は単純に一番吹きにくかったが慣れの問題っぽかったので慣れれば一番音色が綺麗で好みに感じられたから。

その後、先生がそれぞれのサックスを吹き比べてくれたんですが率直に↑の2本で考えていることとその理由をお伝えしたら「じゃあ④がいいですね」と言われて即決しました。 JEUGIAのAPEXという管楽器?などを専門に扱う部署で買ったのですがレッスン教室自体がJEUGIAさんで行われているため、生徒割ということで1割ほどお安く買えました。

JEUGIAの店員さんからは「同じモデルでも個体差があるので日を改めて複数お持ちして吹き比べますか?」と言われたんだけど自分がその違いを理解できるとは思えないし それがわかるようになったと言えるならサックスを始めた当初のレベルはクリアしてるだろうと思ったこと、いつまた自粛で買えなくなるかわからなかったので

「これでいいです、正直多分個体差とかわかるレベルにないので!」

といって購入しました。「デカい買い物なのにそれでいいのか……?」みたいな店員さんと先生の感情が透けて見えた気がしました、が気にしない。

ということで念願の自分のサックスを購入することができましたチャンチャン。

で、まあ楽器が手に入ったら練習したくなるじゃないですか? なので家で試しに軽く吹いてみたらめちゃくちゃ音がデカくてびっくりしました。

普段レッスン教室は防音なので音がだいぶ吸収されてるんだなってわかったよね。 あと、いまグループレッスンで参加しているので一人だと、レッスン時は出来たつもりになってたところが全く出来てなかったことが判明して(´・ω・`)って気持ちになります。

ベルと呼ばれる部分にタオルぶっこんで試してみたりしたんだけどほとんど変わらなかったので吹奏楽の人たちは一体どこで自主練していたのだ…って気持ちになりました。

ということで世の中はいろいろ大変だし、多分どこかのタイミングで第2波・第3波が来るのは避けられないと思ってるんだけど そのときに心の栄養が取れるようにだけはしておきたくてサックスを購入したよ!という自慢話です、えっへん。

楽器がようやく手に入ったので頑張って練習していく所存です。 鴨川で「週休7日」Tシャツ着て下手くそなサックスを練習してる人がいたら90%くらいの確率でぼくです、よろしくでしょでしょ。

やっていくぞい!!!

初めてのGraphQL

TL;DR

いつもの読書ログです、読了しました。

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

この本を読むことで得られる期待値

  • GraphQLを採用するメリット・デメリットが理解できる
  • 何故GraphQLが開発されたのか説明できる
  • 自社プロダクトに組み込むと想定したときに具体的にどこで効きそうか、あるいはどの辺りは効かなさそうか判断できる
  • GraphQLいくつかのAPI共通で利用される機能(ファイルアップロード/ダウンロード、ログイン/ログアウト、アクセス権限制御など)をどう実装するか
  • N+1問題などのフロントエンドがクエリを組み立てることで発生する問題にどう対処するのか?

以下、感想

GraphQLはデータのあり方をクライアントサイドから再定義することで従来のサーバーサイドが行っていた不可侵領域を崩した。 これは今までサーバーサイド側の責務だったデータ設計がクライアント主体になることでクライアント側の問題を図る意図があった。

これは画面設計を行うときにデータ設計の不備が見つかることがあったので割と納得感がある。

書籍で明言されてなかったと思うがGraphQLはクライアント・サーバーサイドのどちらかに責務を寄せるのではなく、柔軟なレイヤーを一枚挟みたかったのではないかと思う。 その柔軟なレイヤーを共有することで責務がレイヤーという抽象化された概念に集約され、結果としてインターフェイスとしての責務が明確になる、みたいな。 …というようなことを読みながら考えていた。

反面、クライアントからみたデータ設計になるため、いままでとは異なる問題がサーバーサイドで起こるのではないか?という懸念をこの時点で抱いている。

GraphQLは「クライアントとサーバーサイドのパフォーマンス向上」と「データ構造の要件を満たす解決策」を目指して開発された。 つまりこれによって副次的にクライアントの開発速度が向上することが見込まれたり、エンドポイント管理の複雑さから開放される、というようなことが期待できる。

ただ結局のところ、最も目指したかったところはパフォーマンスの向上、そのためのデータ構造のユビキタス化なのだろうと思う。

GraphQLによって以下のような状態が解消されると書籍では紹介されている。

  • 過剰な取得、user.name がほしいだけなのに user.* が取れてしまうみたいなやつのこと。
  • 過小な取得、今度は逆に user が持つアイテムが知りたいだけなのに inventryfavoriteitemみたいに複数回リクエストしてしまうみたいなやつのこと、らしい。
  • エンドポイント管理の煩雑さ、RESTなサービスの難点の1つにRoutingがあると思う。GraphQLではエンドポイントは単一なので管理そのものが実質的になくなるためこのURLは実態を表すのに相応しくない、というような喧々諤々な言い合いがなくなる。

書籍内では「GraphQLはただの仕様(Specific)だ」と紹介されている。 これはクライアントとサーバーの仕様を定義するものでしかなく、アーキテクチャのようなものではないと理解している。 その分根本的な解決には難しいケースがありそうだと思う反面、取り入れやすさ(変更しやすさ)があるのだろうと理解した。

GraphQLのクライアントはサーバーサイドとはまた別に目的があるらしい。

  • 開発チームの作業効率の向上
  • アプリケーションのパフォーマンス向上

この2つが主となる目的だと書かれていた。 それを実現するために「ネットワークリクエストデータのキャッシュ」、「ユーザインターフェイスへのデータ注入の肩代わり」が行えるようになっているそうな。 (そういえばユーザインターフェイスのデータ注入の肩代わりって具体的にどういうことだったんだろう?)

GraphQLには大きく分けて2派閥あってRelayとApolloというフレームワークがあるが書籍ではApolloを使われている。

そもそもGraphQLの特性とはなにか? 元々グラフ理論というものがあり、その文脈として「グラフは多くのデータを必要とするアプリケーションと相性がいい」と書かれている。 有向グラフ、無向グラフあたりで調べると良いかもしれない。 書籍にも簡易だがイメージがつくようにわかりやすい紹介があったのでグラフ理論の名前を聞いたことがない、あるいは名前しか知らないという人でも安心して読めると思う。 少なくともぼくはそうだった。

GraphQLには大きく3つの機能がある

  • Query(取得)
  • Mutation(更新)
  • Subscription(購読)

わかりやすくいってしまえば

QueryはSQLにおけるSELECT文のことだし、 MutationはINSERT/UPDATE/DELETE文のこと。 SubScriptionはデザパタにおけるPubSubのこと。

ゾルバはDBだけを参照するものではない。内部APIや外部APIから受け取ったレスポンスなどを返すことができる。 だとするとクライアントがクエリを組み立てるのに懸念があるケースはDBモデルではなく専用に用意したリゾルバを参照されることで実装的には内部APIを叩いて負荷の少ない実装結果を参照させることができるのではないか? →後述される複雑さ(complexity)で解決しようぜ!って言われてたのでこの対応は筋が悪いのかもしれない。でも以前みた GraphQLでWebAPIを作っているでは graphql-batch 使え!みたいな話があった。これはそもそもの比較がおかしいとは思うんだけどリクエストさせない対応が複雑さで、とはいえN+1発生するようなリクエストって起こり得るよね!ってときに使う解決策が graphql-batchなのかなーって思いましたまる

patorash.hatenablog.com

mutation時にバリデーションエラーが発生したらどうするのだろう? →明確な答えは書かれていなかったがGraphQLにおけるエラーハンドリングの仕方を読んだ感じ 200 OKを返しつつmessageにエラーメッセージを詰める……みたいな対応するしかなさそう。

techblog.zozo.com

GraphQLにおけるテストは通常(既存)のテストと同じでよいのか?それとも気をつけることがあるのか? →特にテストへの言及はなし。pockeさんが書いてくれているGraphQLのクエリを自動的にテストするというのが参考になりそう。エンドポイントが1つしかないので今までと同じ……というわけにはいかなさそう。

qiita.com

トリビアルゾルバを最上位に追加するという説明で最上位にズラズラ書いてしまうのは嫌だなーという気持ちになり、なんかでまとめられないかなーとか思ってた。 →これに関しても言及がなかったけど多分探せば何かしらあるはず。

GraphQLでDatetimeはどう扱われるのか?タイムスタンプ?それとも文字列? →カスタムスカラー型を定義しましょう、と書籍で紹介されていたのでそれ読めばよい。

GraphQLでファイルのアップロード/ダウンロードが行えるのか? →結論からいうと行える、どうやるかについては書籍内の7章で言及されているのでそこ読めばよい。

apollo clientのキャッシュはデフォルトローカルに保存されると書いてあったが保存可能な最大サイズはどれくらいか?またそれはどこに保存されるのか?キャッシュ先をRedisなどに指定することは可能なのか? →明言されてないがどうにもInMemoryっぽい雰囲気。ただlocalStorageなどを指定もできる?という感じではっきりしていない。Apolloの公式ドキュメントをあたるのが良さそう。

apollo clientのキャッシュはページ遷移しても有効なのか?失効するタイミングやそのコントロールはどうするか? →InMemoryだと仮定して話すとページ遷移してもなくならない(はず)。失効するタイミングやコントロールに関しては書籍の7章に記載があるのでそちらを参照すればよい。

fetch policy: cache-onyってどういうときに使うもの?キャッシュがなければ例外が投げられるということだけどキャッシュがなかったら普通はリクエストしてデータをみにいくものじゃない?どういうケースのときにこれを使うことがあるの? →Queryコンポーネントなどをキャッシュする(サーバへの問い合わせがいらないもの)のときに使われる、ということだった。これも書籍に記載されている。

まとめ

基礎の基礎は理解できたと思う。 いくつか細かい疑問などはあるのだけどそれは実際に触ったり公式ドキュメントを読んだりしていけば解消しそうだなという気がしています。

この書籍ですが非常に読みやすい日本語だったことと、イメージの説明の仕方がうまいなと感心しながら読んでいました。

この書籍を読んで期待することのうち4/5は達成されたと思います。

N+1問題などのフロントエンドがクエリを組み立てることで発生する問題にどう対処するのか?

これに関してはもう一度↓のエントリなどを読み直して情報を整理しようと思います。 恐らくそれでほぼほぼ疑問に思っていることは解消するはず。

employment.en-japan.com

patorash.hatenablog.com

マネーフォワード 京都開発拠点からこんにちわ

前回のブログエントリから2ヶ月近く経過してしまった。 やってることとしてはそんなに何か大きなことが起こっていたりはしない。

Railsのコード書いたり、バグ対応に追われたり、普通にエンジニア・カイシャインしている。 カイシャイン・プリキュアは月曜の朝に死ぬ。

近況報告

近況でもないんだけどマネーフォワード 京都開発拠点に2020年1月からサーバーサイドエンジニアとして勤務してます、いえい!

本当は試用期間が終わったあとにブログエントリでも書こうかなと考えていたんだけどちょうどその前後で担当しているプロダクトのリリースがあったり今回のコロナ騒動があったりでなんかいろいろワチャワチャして書くのを後回しにしていました。

POが書いてたエモい記事がこれ

note.biz.moneyforward.com

実際に社内で使ってもらったあれこれの感想はこっち

note.biz.moneyforward.com

ちょうど面接を受けたのが年末の12月で活動し始めが11月の中頃。 内定をもらえたのがちょうど12月中旬だったので本当に1ヶ月くらいで転職活動から内定までのスピード転職でした。 ちなみに何社か受けたけどマネーフォワードが今回の転職活動の記念すべき1社目でした、なので最速で終えられたって感じです。

いまGoogle Calendarを確認したら

転職活動開始が11月の3週目 マネーフォワードの面接1回目が12月1週目 マネーフォワードから内定もらったのが12月3週目

でした。 マネーフォワードの面接1回目から内定までがだいたい2週間くらいなのでだいぶスピード感ある転職活動だなって感じです。

前職楽しそうにしてたのになんで辞めたの?

前職のトマルバを辞めた理由はいくつかあるんだけど一番大きいのは自分のメンタルが病んだから。 理由としては自分で「やらないといけない!」って抱え込んでしまってパンクしたって感じ。

こういうと仕事しすぎ?ってなるけどそうじゃなくて、なんか強迫観念的な状態で誰かに任せるとかの逃げの行動ができなくなっちゃってた。 抱え込んだまま仕事して失敗して、そして自分は駄目なやつだもっと頑張らないと!でも行動が伴わなくて結局自分で自分の心を殺してしまうみたいなわけがわからない状態になってた。 CTOのtangoさんと何度か話して最初は休職してから復活する予定だったんだけど、ぼくの精神状態とか諸々考えるとOffの日に会社のことを気にしないみたいなことは難しそうと言われた。 ボク自身もそう思っていたし、辞めたくないので休職という選択肢が取りたかったんだけど、結局休職から戻ってきても根本的な部分が変わってないから問題の先延ばしにしかならんなという結論になり、期限を切ってそれまでに返答する……ということで期限締め切り日を幾日か過ぎたあたりで辞めることを伝えた、みたいな経緯です。

トマルバという会社自体はとても好きだし、そこで働く人たちもとても好きです。 オフィスの京町家はめちゃくちゃエモいので京都に来る機会があったらぜひ利用してほしい。

ホテルに泊まるよりもいい体験ができると思う、お値段がその分高くなってしまうので4〜5名で泊まるといいかもしれない。 ホテル業界なのでそのあたりの業種を絶賛募集しているのでもし興味がある人がいたら応募してくれると元社員として嬉しい。

www.wantedly.com

マネーフォワード@Kyoto に入ってから

マネーフォワードに入社する以外にも選択肢はいくつかあったんだけど(その中にはライバル会社のfreeeさんもあった、最終的に技能面談で落ちたけどw)一番いいオファー条件を出してくれていたこと、元々Kyoto.rbなどで現職のボスである 谷口さんを通していろんな情報を意図せず吸収できていたのでそのあたりの安心感もあって入社することに決めました。

候補の1つにはてなさんがあってぼくにとってはある種の憧れみたいなものがあって受けるか随分悩んだ(入社できるかどうかは別として)んだけど最終的に「受けない」という選択肢をした。 恐らく成長という意味でははてなのほうができたのかな?と思う面がなくはないんだけど、それよりも自分がそこで働くという具体的なイメージが持てなかったので受けないという選択をした。 onkさんやdaiksyさん、他にも何人もはてな社員のかたを知っているので文化的なミスマッチは少なそうだったのでそういう意味では少し残念ではある、武者修行的に社会人留学生制度をそのうち京都のはてなさんとマネーフォワード京都拠点でできるといいのかもしれないなーとか少し考えたりすることがある、これは以前にonkさんが似たようなことを仰ってていまくらいならリリースもできたしこちらとしての体制が整いつつあるのでできるかも、という気持ちでいる。

さて、マネーフォワードに入社した経緯はもしかするとそのうちマネーフォワードのテックブログやnoteに書くことがあるかもしれないので割愛するとしてマネーフォワードに入って行った大きめのことを紹介していく

Money Forward Techbook #2 のまねふぉ執筆陣に参加した

Money Forward Techbook #2 のこと。しかも何故かトップバッターになっててウケる。

マネーフォワードが技術書典で書籍を出しているのは知っていたのでそれに参加したいなーみたいな雑談をしたところ、執筆陣(実態としては部活)のチャンネルを紹介してもらえた。 個人的には技術書典8にはもう間に合わないだろうから、秋頃にある技術書典9から参加したいなーみたいに考えてたら「じゃあ書きますか!」となって入社後2週間くらいで執筆陣入りしていた。

めちゃくちゃ焦った上に締め切りがそこそこ近かったので大変苦労した、チームメンバーにはそのせいでリリース間近なタイミングで迷惑をかけてしまったなと今にして反省している。 でも次回も参加する予定だけどね!テヘペロ

1月6日入社で17日に執筆陣チャンネルで「こんにちわこんにちわ」してたわ、圧倒的スピード感!!!

マネーフォワード クラウド会計Plusのリリース立ち会った

まあリリース直前にジョインしただけでなにかしたって言えない気もするけど微力ながらリリース前の駆け込み時期にスケジュールを遅らせることなくリリースまでこぎ着けたのは偉業なんじゃないか?って思ってます。 偉業なのでKyashとかで39円ください、皆様の温かいお気持ちお待ちしてます。

f:id:luccafort:20200517175915j:plain

京都開発拠点は実質お金稼いでるプロダクトがまだこれしかない状態なので稼ぎ頭です。 やれること、やりたいこと、やらないといけないことまだまだいっぱいあるので興味ある人は下のほうに会社の宣伝おいておくので連絡ください。

ちなみにぼくのブログを読んでいても特に加点とかないですし、別にぼくにリファラル紹介料はいるわけでもないです。

フルリモートに移行した

コロナ騒動で意図せずではあるのですが完全リモートワークに移行しました。 そら社員はそうだろ!って人もいると思うんですがなんとインターン生やお仕事を手伝っていただいているパートナーのかたも含めフルリモートする体制になっています。

出社するひとがいるのか?については京都開発拠点には1人もいないです。 オールフルリモートです、これはPOである杉浦さん(Not エンジニア&Not デザイナー)も含んでいます。

たまーに冷蔵庫の中身や会社においてある書籍を取りに行くひとが月に1回あるかないかくらいの頻度です。 でも仕事はいまオフィスではしてない状態です。

フルリモート、ぼくはあまり好きじゃなくて、週2回くらいまでが許容範囲かなーと思ってます。 そんな中フルリモートになったのでPCとか私物のやつだとスペック落ちちゃうなぁ…と思ってたら「今回は緊急時なので」という特例で会社PCを家に持ってお仕事できています。 MacBook Pro 16インチ 64GBなので潤沢にメモリ使えてハッピーハッピーです! ✌✌✌✌✌

反面、家においていた技術書をオフィスに移動させたところだったので手元にほしい技術書がなくてたまーに困ることがあるくらいです。 基本的に業務に関係しそうな書籍に関しては持ち帰ったので大丈夫のはずではあるんですがふとしたときに手元になーい!ってなることがあります、仕方ないね。

元々京都拠点はリモートで働くかたが何名かいらっしゃってそこで課題がいくつかあったのでいろいろ試したり、スクラムで開発しているので誰がなにしているのかがわかりやすかったり、モブワークでタスクを進める実験的な試みを行っていたなどの経緯もあり、課題はありつつもスムーズに移行できました。 このあたり前職でリモートワークしていた知見を共有して「とりあえず試そうぜ!」と声を上げた過去の自分を褒めたいです、よくやったな!

ちなみに拠点で勉強会をすることがあるんだけどそれもいまはフルリモートで行ってる、意外となんとかなるもんだ。

お金扱うんだからガチガチなんじゃないの?

やったことじゃないんだけどたまに質問されるので答えておく。 正直自分も入る前は金融系SIerみたいな堅苦しさがあるのかと思ってました。 いくつかの点でどうしても堅くせざるを得ないものはあるけどそれも必要最低限って感じに収まってます。

例えば……

セキュリティー的な点でカフェで仕事する!みたいな自由さはない。 これは扱うデータの特性上認められないので当然だと思ってる。

会社PCを持って帰る、これも上記のセキュリティー案件でNGです。 リモートワークするときは申請してリモートワーク用のPCからアクセスしないといけません。 ただし条件があえばワークフローを提出することで持ち出し可能。 今回のコロナ騒動は特例的にワークフローすらなしで持ち帰りOKでした、杓子定規な対応ではなく柔軟に対応してくれて非常に助かりました。

自宅から会社にアクセスするのにVPN繋がないと駄目。 「いまどきサーバはAWS/GCP、外部からもガンガンアクセスされるしVPN不要でしょ!」という向きがあるのは理解しつつもぼくらの扱うデータの特性上これは看過できないです。 ということでVPN不要なソリューションを提供していただける最高に優秀なエンジニアカモン!

でも、その他に関してはいろいろな人が苦心してくれてるおかげで非常に自由度高い状態を維持してもらってます。 この点は入社前とあとで印象が180度違う好例ですね。

そういう働きやすい職場をいろいろ苦心して作り上げてくれているのがすごくわかるので 入社してすぐに知り合いのエンジニアに1人声をかけました、よく考えるとこれ人生で初のリファラルかもしれない。 手放しでうちよいよ!って言えたのはいまのところマネーフォワードだけ。

だいたいあなたには来てもらいたいが満足するオファーが出せない、という理由でいままでリファラルの紹介をしたことがなかったりします。 お金、お賃金の話でいままでいた会社を手放しで知り合いに紹介するのは厳しかったですね。 その点マネーフォワードはメルカリやLINEほどの高給は難しいかもですが、東京水準での給与は保証できる会社なので安心して提案できます。

まとめ

他にも細かい話でいうと

  • 社内勉強会が充実していること
  • オフィスの環境、特に京都拠点は贅沢
  • ランチに鴨川散歩できてエモい
  • 社内チャレンジシステムがあること(POの杉浦さんが経理からジョブチェンジしてる)
  • POがドメインエキスパートなので優先順位が明確
  • いろいろなバックボーンを持ったエンジニアやデザイナーが揃っている

みたいな話があるんだけどなかなか伝えきれない文化の面なのでテキストだと難しいです。 そういうYoutubeチャンネルとかあると面白いのかもしれないけど……どうかな?わからん! 特にぼくはやりたいと思わないので、やりたい有志がいればやってくれるんじゃないかなきっと。

あえていままでブログで明言はしていなかったんだけど本当によい会社だと思っている。 話す内容は尽きないんだけど濃厚、濃密な3ヶ月を経て、ステップアップのための3ヶ月に突入したなと思っています。 今後もよりよいプロダクト開発のために邁進していく所存でござる。

なお、環境が変わったからかチームメンバーの影響なのか精神面でまいっていたのが 入社1ヶ月後の1on1で自分に対する評価を聞いてからほとんどなくなった。 自分ができなくてもチームのみんなが頼れるって気持ちになれたのがぼくには良かったのかもしれない。

元々は2〜3ヶ月くらい転職活動しながら精神を整えられるといいなと思ってたんだけど 逆に忙しく、はっきりとした目標に邁進していたのが余計なことを考える時間を減らしてくれて結果としてよかったのかもしれないっていまは思ってます。 そういう意味でもリリース直前、直後に関われたのはいいタイミングだったのかも。

ただの会社紹介で終わってしまったけどまあそんな感じで楽しく働いてます。 あと何故かマネーフォワードに入ってから以前までは1mmも上がらなかったLAPRASのスコアが微増しています。 書いてるコード量はむしろ減ってるし、技術的な難易度もどちらかというと前職のほうが高かったはずなのに……何故? (推測としてはレビューしているユーザとレビューされているユーザの数が何かしらの係数になっててそれで増えてるのではないかと疑っている)

会社の宣伝

会社の紹介資料はこちら

www.slideshare.net

京都拠点の紹介はこちら

moneyforward.com

京都拠点の求人はこちら、いまメインで募集している職種はRails/Goのエンジニアなんだけど他にこういうことがしたい!って人がいたらまずはカジュアル面談とかで希望を伝えてもらえるともしかすると東京や福岡、ベトナムなどの他の開発拠点をお伝えすることができるかも。 ただ京都にいるけど他拠点のエンジニアとして働く、みたいなのはいまの体制だと厳しい(いまは逆にフルリモートになったからそういう人にはチャンスかも)

www.wantedly.com

www.wantedly.com

www.wantedly.com

しがないラジオ sp #79 場外乱闘編

TL;DR

2月頭にゲスト@2周目として収録してもらったエピソードが公開されたのでshow noteには書いたけど話さなかった内容をつらつらと書いておく。

場外乱闘編

以下、話してないこと

coinhive「プログラムはウイルス」2審は有罪判決

  • 時事ネタなので入れた。
    • rebuild.fmでよくある時事ネタを真似てちょうどその前日に判決がでていたので時間か興味があれば話すネタによさそうだなと思ったので追加した。
  • 体感でいうなら「なんじゃそら」という不当な判断と言わざるを得ない。
  • 一方でそれだけではなく合理的に判断し、その結果今回残念な結果になったっぽいという現状を踏まえるといまぼくらが扱う環境に大いに影響がでそう。

趣味

  • 去年の夏くらいからサックスはじめた。

    • はじめた経緯はブログに書いたので興味あればどうぞ。
    • サックスやり始めたあたりからYoutubeみるようになった
      • サックスの技法や練習方法をみることが多い
      • たまに京都橘高校吹奏楽部の動画みたりHapa英会話みたりしてる
      • 最近困ったらYoutubeで検索してることがあり、youtubeは大変便利なツールなのだなと10年ぶりくらいに理解した。
        • と同時に昨今の動画コンテンツの隆盛を実際に自分がユーザになることで体感した。めちゃくちゃ便利。
  • 人生初TOEICの模擬試験した

    • 385点でめちゃくちゃ笑った、伸びしろしかないやつ(白目)
    • スタディサプリ(リクルート)が不満はありつつも教材として必要十分
      • やっていて楽しい
      • こういうちまちま単語帳倒すのがレベルあげのためにスライム倒すみたいで割と飽きずにやれてしまう性格
    • よく知ってる単語はリスニングでも脳内でシュッと紐付けできるけど脳内メモリに乗ってない単語は何度も聞き直さないとわからないということがわかった。
    • ディクテーションという問題が結構楽しい。頭と耳をそれぞれ鍛えられる感じがしており楽しい。なおわからない単語と綴りは何回やってもわからなかったりしてレベルの低さを実感する。

漫画アニメゲーム枠

  • 空挺ドラゴンズ@アニメ
    • 存在しない龍という幻想生物の味を想像してお腹が減る
    • フードポルノアニメ
  • ブルーピリオド@漫画
    • エンジニアに憧れていたときのことを思い出して悶そうになる
    • はくどーさんに勧められた8等分5等分の花嫁はまだ読めてない
  • リングフィットアドベンチャー@ゲーム
    • 買えない……頼む、買わせてくれー!!!
    • ちなみに社員の自己紹介のときにリングフィットアドベンチャー買うか悩んでるっていったら社長に笑われた

kyoto.goコミュニティーを作ったった

TL;DR

三行で説明すると

  • Umeda.goが休日開催で厳しい
  • Kyotoにもご当地Golangコミュニティーがほしい
  • ないので作る

という流れで「KyotoにもUmedagoみたいなコミュニティーほしー!」ってTwitterに投稿してから 1週間で爆速キックオフイベントを開催して無事クロージングできたという話をします。

当日のまとめ

kyoto.goコミュニティーのページはこちら

kyotogo.connpass.com

当日のイベントの告知ページはこちら

kyotogo.connpass.com

活動内容ログはkyoto.rbのscrapbox活用がめちゃくちゃ気に入ってるのでそれを参考にした。 kyoto.go のscrapboxページはこちら

scrapbox.io

基本的にはScrapboxにまとめてあるのでそちらのログを眺めるとなんかやっとるな!という雰囲気がつかめると思います。 でもまとめだけみても1000%理解するのは無理。

scrapbox.io

0次会で決めたこと

  • 毎月第3週の水曜日の19時に開催すること
  • 形式としては1枠20分で前後半の2枠で行うこと
  • 最後に10分で当日イベントの振り返りを行う
  • 時間は1時間+ 30分
    • 30分はグループ換えの時間やトイレ休憩、クロージング作業などで発生するバッファ時間を考慮

キックオフイベントで成し遂げたかったこと

まず主催者としてやりたかったことがいくつかあって

  • 「変化することは絶対的に正しい」というはてなismな思想をコミュニティーの中心に据えたかったこと
  • 誰かに依存するだけのコミュニティーにはしたくなかったこと
  • kyoto.go の骨組みを作り上げる

幸いにして概ね期待したことは決められたなと思っていて、あとは文化の問題なので継続的に持続させるように頑張っていこうと思ってる。

個人的な理想像としては大学のサークルや部活をイメージしていて部長がある程度の年数で代替わりしていく循環がある組織であるとよいなと思っている。 ある程度育った人が居座り続けることもできるし、そうでなく卒業していくこともできる、なんなら戻ってくることや不意に遊びに来ることも出来るそんなコミュニティーが理想。

コミュニティーとして決めたかったこととしては0次会のアジェンダにも書いたけど3つあって

  • 開催目的はなにか?
  • 開催頻度と開催日をどうするか?
  • 定期なのか不定期なのか

を最低でも決めたかった。

幸いにして当初ぼくが考えていた「平日夜19時から、内容はディスカッション形式で20分枠*2の振り返り10分で1時間コース、頻度は1ヶ月1回くらい」とざっくり考えてたことに対して

「開催する日程はある程度固定しておきたい、そのほうがスケジュールの都合がつけやすいから」や「休日も平日もやりたい、うちのオフィス使えます」などなどぼくが考えてもいなかったことがポコポコ生まれてきて最高の体験でした。 この段階で「勝ったなガハハ!」という気持ちだった、いえーい!!✌️✌️✌️

良かったこと

  • 人徳がなさすぎたのでコミュニティー作ってからほぼ毎日引用RTとかで「人徳が毎日2づつインクリメントされている、圧倒的成長!!!」みたいなアホ発言してたら最終的に46票も投票してもらえていた。
  • リモートでtenntennさんが参加してくれた!(このあとめちゃくちゃTwitter上の反応が上がったのでインフルエンサーつよい!ってなった)
  • キックオフイベントみたいな技術的なことでないイベントに11人ものGopherが集まってくれてしかも時間通り開始できた、最高!
    • 出席率100%で初回としてはこれだけで大成功といってよいのでは?ってくらい主催者としては非常に嬉しかった。
  • 一方的にぼくだけがしゃべるということがなく、意見や疑問などがでてコミュニティーらしさが出ていた
  • 発起人特権としてイベントの最後に「振り返りだけは絶対にさせてくれ!」という強い意志を表明して受け入れてもらえるようお願い(強制)した。
    • 継続的なコミュニティー運営や意見の吸い上げ、変化を促すには振り返りは必須だと思ってるのでここだけは独裁官としての権利を行使した。
  • Twitterでキックオフイベントやるよ!ってアナウンスしたら有識者が協賛してくれそうな雰囲気になってきた

改善したいこと

  • イベントを開催するの脳内前提条件をきちんと書き出しきれていなくて「これってそもそも〜」という聞かれることが多かった。
    • 定期か不定期かはまだわからないけどイベントの開催内容に関しては継続的にブラッシュアップする場を設けようと考えているので次回は脳内条件をちゃんと書ききっておこうと思った吉宗であった。
  • 締め切り時間の想定を舐めてた
    • 正直10票いけばいいと思っていたのでTwitterの締め切りを「イベント日の前日には結果みたいよなー」と思って当日0時で設定したら「投票できなかったです……」みたいなことになってしまった。
    • connpassの応募期間をイベント日の0時に設定していたら当日に「投票できないけど参加するにはどうすればいいですか?」という問い合わせを発生させてしまった。
  • 困ったときに知り合いの人に話しを振ってしまった、ちょっと馴れ合いっぽくなってしまって良くなかった。
  • コミュニティーへの貢献のお願いとしてブログやSNSでの告知、Slackの参加などの案内を時間になったらシュッと出来るようテンプレート作っておくのが良さそう
    • 人が来るたびに会場案内とかをしてしまったけど意味ないし疲れるのでイベントの開始時点の1回で終わらせるのが最良。

わかったこと

  • 京都にもGolangをやりたい人はそこそこいる
  • みんなもっと技術的なことでワイワイできる場があるとよいと思ってくれている
  • 金銭が絡まないので主催者の負担がだいぶ少ない
  • もっと学生や若くて勢いのある社会人に訴求していきたい
  • Wifi情報がSNSに上がるのはよくないと思います!!!……ごめんなさい。
  • Twitterの投票結果と参加者のやりたいことが真逆になってて面白かった
  • プログラミング初心者枠をいくつか設けてもいいかなという気がした
    • 運営としても初心者が多いか少ないかでイベントの傾向を事前に変えることができそうなので有用そう。

まとめ

ということでキックオフイベントで概要が決まったのでなにはともあれイベントページを用意しました! キックオフイベントと違ってまだまだ猶予があるので今回のように突然で都合があわないというケースも多少少なくなるはず!

ここからが本番なのでやっていくぞい!

kyotogo.connpass.com

Kyoto.rb Meetup 20191221

もう日付が変わってしまったんだけど2019年最後のKyoto.rbに参加してきた。

kyotorb.doorkeeper.jp

scrapbox.io

個人的には非常に楽しかった反面、いつもだけど反省点が見つかったので書き起こして次回に活かしたい。

やったこと

前半戦

scrapbox.io

コードリーディングとその司会の両方を初めてやった。

コードリーディング自体が初めてだったので全て手探り状態だったことで参加していただいた方に申し訳なく思った。 特に初心者の方がいたけれども一度も意見というか質問が出来ない空気のまま突っ走ってしまったのはよくなかった。

誰がどのくらい何について知っているのか?ということを事前に知るのは結構ハードルが高い。 今回でいうとFaradayのコードを読んでいたわけだけどそもそもどういう認知の状態かを最初に確認すべきだったかな。

使ったことがある、名前すら初めて、そもそもAPIクライアントとは?みたいなそれぞれのレベルの確認から入って「じゃあまずgithub.comのFaradayのREADMEを読みましょう、こうするとAPIと通信してくれるわけですねー」みたいなのが最初にあると良かったかもしれない。 コードを読む前にコードリーディングで知らないことがあったら読んでいる最中でも恥ずかしいことでも声に出すかそれが難しければScrapboxに書いちゃってください!って言っておくとそれぞれのレベル感で得るものを最大化できたかもしれない。

更にいうなら「なにか読みたいgemはありますか?」と質問したわけだけどそうではなく「どんなことが知りたいですか?」みたいなもっと抽象化した言語からじゃあ期待に対するgemがあるかどうかを調べてコードを読むみたいに出来たかなという気がする。

あとコードリーディングしているときに画面にコードを映しているとscrapbox業ができないのでページだけ用意して、誰かに先にお願いしておくのがよいかな。これは反省点。

後半戦

scrapbox.io

Rspecの話。

元々の発端は外部の方とやり取りをしたときのrspecのコードが手続き型っぽい invalid_postcodes = ['', 'aaa', 'いちにさん']each で回していて「それってrspecっぽくないよね?」なったけどそれってレビューの指摘としてどうなんだろうか?みたいな話(だったと思う)

結構難しい問題だったのかなという印象があって、minitestはTDD、rspecはBDDな思想が反映されていると思う。 ↑のような郵便番号に空文字や英字のみ、日本語(ひらがなカタカナ漢字)のケースでFailさせたいケースはぶっちゃけあまり差がでないのでrspecであることの理由というのはなんだろう?となった。

終わってからだけどminitestのほうが愚直にかけるので期待する値を与えたときにどうなってほしいのか?という点では明快な気がした。 反面それらがさまざまなケースとして発生し得る、例えば「ブログ→コメント→投稿者」みたいなさまざまな要素が複雑に絡みつくときにminitestだと煩雑になりすぎてしまうのでは?という気持ちがある。

rspecはDRYな構造には出来るけど単純にrubyが書けるだけではない学習コストが存在してそこがネックになるかも。 同じチームでずっとruby開発するならそのコストを払ってもいいと思えるけどスポットで参加するときに「いやこれはrspecライクな書き方じゃないから直して」って言われたらカチン!とくるかも。

テストとしての担保すべき内容が実装されていた場合その表現方法について議論するのは果たして正しいのか?みたいなところが宗教的で社内なら規約で縛られるけど外部の方となるとそこを強制するのは厳しそう。

結局答えが出ずにみんなでうんうん言って終わってしまったのがProblemになった。 参考資料でもminitestもrspecも両方書きましょう!で終わっていて両方使わないとメリットデメリットがわからないよね?というめちゃくちゃ初歩のところに戻ってしまった。

懇親会

コミュ障というか知らないひとに話しかけるのが苦手な性格なのでついつい知り合いとばかり話してしまったり、初心者のかたのフォローができていなかったなーと思って反省した。そういうとこやぞ!感ある。 shojiさんから「オーガナイザーいま1人しかいないのでどうですか?」と打診されたが正直この手のまとめをしたりするのが得意でないので「サポートならやるけどオーガナイザーはちょっと…」と返してしまった。

でも現在のオーガナイザーであるtaca10さんも経験があるわけじゃないのに1人で奮闘されているのをみているとやってもいいかもしれないなと少し思ってきた。 サブオーガナイザーみたいなポジション(そんなのあるのか?)から初めてもいいなら挑戦したいかなという気持ちがある。

今回はRailsGirlsでtaca10さんが告知をしてくれたおかげで初心者のかたが非常に多かった。 多かった反面やはり懇親会に残ってくれる方は少なくて少し残念な気持ちになった、でも気持ちはわかる。 ぼくも最初の勉強会では懇親会参加しなかったからね、あと初心者のかたは学生が多かったので飲み会の4000円がネックだったのはありそうという話をしていた。

懇親会こそ司会のひとやRuby/Railsに詳しい人に話を聞ける場なので積極的に活用してほしいなという気持ちがあり、次回も初心者のかたが多ければ改善して行きたいなという気持ちがつよい。 初心者のかたは話しかけにくかったり、何話していいのだろう?と不安に思うんじゃないかと思うのでその辺、懇親会で初心者の質問テーブルとかRailsについて話テーブルとかテーマが切れるといいかなという気がした。 もちろん雑談テーブルなどもあっていいと思うのでそのあたりは次回以降で工夫できたらなと思う。

まとめ

全体として忘年会シーズンだったこともあり参加者が多くて楽しかった。 反面聞きたい内容が各テーブルに分散してきけない!みたいなことが起こりがちであとからでもいいのでどういうことを話してたのか知りたいなと思うことが増えた。 毎回来ているひとはscrapboxに書いてくれているのだけどだいたいその人達がファシリテーター役だったりするのでみんなでscrapboxを肥え太らせていければなと思う。

あと毎回テーマをひねり出すのが難しいというか忘れてしまいがちなのとホワイトボードに書くんだけど離れていると「最初の方に話したのなんだっけ?」となりがちなのでSlackとかに流せば 「👀」か「🙋」が挙手の代わりで投票という感じにしていくと件数数えるのとかがなくてもっとシュッと終わらせられるかもなーって気持ちになった。

あと個人的にSlackで前回これ聞きたかったけど聞けなかった!みたいな振り返りができるのでやってみたい。

個人的には途中になってしまったけどもFaradayのコードが読めて楽しかったし、これってこういうことでは?とかこれってなんですか?みたいな話で深堀りしていけたのがモブプロっぽくて楽しくみんなでわいわいできてよかったですね。

ところでscrapboxのタイトルに":"が入ってるとはてなブログで「埋め込み」の展開で失敗して変なURL、ただのURLではなく変な位置で途切れて(改行されて)しまい期待するページのリンクにならない現象が発生して少し困った。

意思表明と平成の恥は平成のうちに断捨離していきましょうという話

gateau.hatenablog.com

もともと最近のインターネット上での発言などで女性をバカにするような話があがっていたり これはセクハラというのは厳しいのでは?と思う発言を見かけることが本当に増えた。

でも加害者は被害者の気持ちを完全に理解することはできないのでそうするとマジョリティー側が注意しないといけなくてただそれの行き過ぎたパターンも散見されて「それの向かう先はディストピアなのでは?」と思うこともあり、本当に難しい。 そしてぼくは男性で日本社会ではマジョリティー側に属しているので本当の意味で女性の横にたってご高説を垂れることはできないなといつも思ってしまうところがある。

そしてマイノリティー側から声をあげるということは非常に難しい。 心理的にも周りの反応的にも、もしかしたら自分が間違っているんじゃないか?と思ってしまうのもやむなしだと思う。 そういう意味でこのエントリが書かれた経緯などに対してぼくは敬意を払いたいと思っているし、もっとこういう議論が活発になって無知からくる差別がなくなってほしいと思っている。

このブログを書いている理由としては「あなたは何も間違っていない」ということを伝えたいなと衝動的に思ったので非常にセンシティブで、 一朝一夕では解決しないと思うしぼく自身に関してはなにも直接的なメリットはないけども賛同の声を表明しておこうと思ったということを伝えられたらいいなと思い書いている。

私が怖がっているときに「気にしすぎ、過剰反応だ、お前が○○した・しないのが悪い、それぐらい許せ」など責めないでほしい。

少なくとも被害者側であるはずの人たちにこのような不安や心配を抱えさせてはならないという義憤から書いてる面がある。

なので多分あとから冷静になって読み直したときにぼくはこの文章を呼んで身悶えすることになると思う。少なくとも現時点で羞恥のようなものはあるがそれでも意見表明するべきだと思ってこの文章を書いている。 少なくともよほど問題がある文章を書いていると思わない限りはこのエントリは消さないつもりだ。

正義や怒りで意見を表明するのはあまりよくないと個人的に思っているのだが 少なくともこのような発言をさせてしまうような社会にぼくは所属したくないし、現状存在する問題に対しては改善していってほしいと願っている。 ぼくができることは正直多くも強くもないと思っているがエントリに対する意思表明と賛同くらいはできるのでここで書きなぐっておく。

話が脱線してしまったので戻したいと思う。

件のエントリで↓というのがあってたまに(だと思ってるがもしかしたら嫌がるかたにとっては頻度が高いのかもしれない)Twitter上でやってしまうことがあったのだけどこういうのも確かによくないよねって改めて考えさせられた。

会社Slackの雑談チャンネルにて「童貞の〜」「女子大生飼いたい」など性的な発言が目に入る。(いろんな人で、ままある)

「女子大生飼いたい」とかはどういう文脈で出たのかわからないが正直理解に苦しむ発言でこれをパブリックな場でやったら駄目でしょ、というのが第一印象。 個人的に反省を促されたのが「童貞の〜」という文脈でぼくはこの「童貞」というワードを使うことがある。 自身を揶揄するときによく使っているのだけどこれもあまりよくないかなーと思うことがあったので最近は気づいている限りでは使わないようにしている(徹底して使っていないとまでは言わない)

性別ということで気になったケースが直近で2件あったがこれらも非常に難しいと思っている。 ぼく個人の見解では「“心は女性” 女性トイレの使用認めない国に賠償命令 東京地裁」のニュースは自身のアイデンティティとしての性別が女性であるなら女性トイレを使用を禁止するのは駄目だと思っている。

www3.nhk.or.jp

反面こちらのケースでは革靴はOKでヒールのある靴がNGというのがダブルスタンダードのように感じられて「嫌なことは嫌と伝える」という点で賛同しかねるものがあった。 「きちんと仕事する」服装がOKなら「女性が女性らしく振る舞う」こともOKになってしまうと考えるからだ。

そういえばぼくが子供の頃に父親が「NYのサラリーマンはスーツにスニーカーを履いている、これだからアメリカ人は!」というような話をニュースかなにかでみて賛同していたことを覚えている。 当時子供だったぼくはスーツにスニーカーがドレスコード的な意味でNGなのだろうと思いこんでいたのだがいま社会人になって思うことはこのニューヨーカーと呼ばれた人たちは非常に合理的だったんじゃないか?ということだ。 なにより彼ら、彼女らのすごい点は苦痛を許容するのではなく自分で工夫してしまうその精神性にあるのではないかと言う点で感動すら覚えてしまう。

なにが言いたいかというと社会はもっと寛容であってほしいということだ。 このドレスコード的な問題に関しては少し違うかもしれないがセクハラやトランスジェンダーに関しては無理解からくるハラスメント的側面があると思っている。

それをされることで嫌がる人が確実にいて何故そう感じるのかをしっかり確実に行っていくしか無いとぼく自身は考えている。 その間マイノリティーの人たちには我慢を強いることになってしまうのが心苦しい面があるが黒人差別などに関しても少しずつ歩み寄って改善されている面があると思うのでターニングポイントを超えるまでは歯を食いしばるしかないのかなと思う。 マジョリティーであるぼくが出来るとしたら #rebuildfm でNさんことひろしまさんが確か仰っていたと思うんだけど「マジョリティー側から歩み寄るしかない」ということだと思う。

最初はこの歩み寄りがマイノリティー側に優位な状態、つまりやりすぎなくらいしないといけないとそもそも平等にはならないという意見にぼくは非常に感銘を受けたし、今は同様に考えている…つもりだができてるとは思っていない。

「周囲の対応で嬉しかった経験」でも書かれていることは何も特別なことではないけど勇気がいることだと思う。 例えば下ネタで盛り上がってるところでそれをやんわりと辞めましょうとぼくはやんわりというスキルがないので

下ネタなどに乗らず、別の話題にそらせてくれた

このような機転が効いたことはできないなと思う。 そうすると場がしらけてしまうなーとか反感を持たれるんじゃないか?とか不安になると思う。 でもそこで口を噤んでしまうのは結局自分の不利益をマイノリティーに押し付けていることと変わりないと思う。

文中では「いじめに似ている」と評されているがまさに正鵠を射る例えだと感じた。

ここで不安から口を噤んでしまう行為は構図として「直接的ないじめに関与はしていないけど見て見ぬ振りをしているひとたち」と相違ないと思う。 ある意味で一番卑怯な人間だと思うし、ぼくが一番唾棄すべきだと考えている人間なのでこれにだけはなりたくないと思う。 出来るできないではなくやっていかなければいけないことだと思っている。

いじめは駄目なのでやめましょう!が正なのだからセクハラだって同じになっていかないといけないと思う。

勇気とは違うがぼくも女性が怖いというかどう付き合えば(男女の仲という意味ではない)いいのかわからくて不安に思うことがよくある。 これはものすごく単純な理由でぼくがステレオタイプな女性のマッチョイズムっぽい文化を怖がっているという無知からくるものだと分析している。

エンジニア文化に近い文化圏のひとたちは比較的この性別的な問題をある程度共有できていると思っているのであまり性別を意識せずそういうアカウントの人たちなのだなと思ってオンラインでもオフラインでも交流させてもらっている。 ぼくのような人間やめたほうがいいのでは?みたいな人間とも交流してくれている人がたくさんいて非常に助かっている。

ところが文化圏の外にいる人と話すときがものすごく不安になる。 こういうコンテクストがそもそもあるのか?どういう言葉が相手を不快にさせないのか?みたいなことを男女問わず気になってしまい、非常に疲れる。 ただ同性である場合はある程度楽な面があるのも否定しにくい。 少なくともセクハラの心配はほぼしなくていいという安心感がある、反面女性の場合は多くの場合は杞憂であるのだろうけど「ああいう発言をしてしまって不快にならなかっただろうか?」とか「うまく切り返しができず不快に思わせなかっただろうか?」などの心配をしてしまうことがある。

結局この問題は相手の文化を知らないために起こる無用な心配をしてるのだなと「異文化理解力」を呼んだあとでふとしたときに思ったことがある。 会社の同僚や仕事では女性と話せるがプライベートで女性と話すことができないのは会社などでは「仕事」という共通のコンテクストとそれに向かって協力するという前提条件が最初から備わっているから不安に思うことがないんだろうということだ。 なので結局相手を知るという当たり前のことから初めていくことが大事なのかなと改めて考えることとなった。

無理やりまとめ

どうしたらもっと楽に、自由に生きられるのか。 エンジニアをやめた方がいいのか、住む場所を変えた方がいいのか、悩んでいる現在である。

何度もいうがこのような発言を被害者側であるマイノリティーにさせてはいけない。

そんな社会に自分の子供や孫を放り込みたいのか?ぼくなら絶対にごめんである。

ぼく個人ができることなどたかが知れているがこういう意思表明を行うことで少なくとも周知に協力できるのではないかなと思って書いている。 本当は「相談に乗りますよ」というエクスキューズができるといいなと思うけども多分それはぼくよりももっといろんな立場や視点からアドバイス出来る人がたくさんいると思うのでそちらに任せたほうが誰もが幸せになれそうだと思う。 (多分ぼくができるとしたら愚痴はく相手役くらいだと思うのでそれでもよければ付き合いますよレベルだと思う)

少なくとも孤独に悩むような事態自体をなくしていければなと思ってかなり感情的に書きなぐっている。

せっかく元号も変わったのだしこの手の後世に誇れない文化は断捨離していきましょうというお気持ち表明です。