インドア人間が奈良に一年住んでみて感じている地方移住のメリット・デメリット

雑記

2021年の10月に東京から奈良に転居して1年以上が経つ。一般に、地方移住してみた結果の紹介記事のようなものは、外交的でアクティブな人が書くようなイメージがあるけれど、内向的で出不精な私もかなり楽しく暮らせているので、感じているメリットとデメリットを書きたい。

奈良移住の背景

妻の大学が奈良女で私も大学が関西だったので、学生時代に奈良でよく遊んだ経験があり、また、個人的に奈良の史跡が好きで、一人で奈良を散策する機会も多かったため、夫婦で奈良への印象が非常に良く、いつか奈良に移住したいねというようなことを話していた。その意向を会社のCTOとの1 on 1 Mtgで伝えたところ、すぐに会社の承認フローを通してもらえて、意外なほどアッサリと奈良への転居が可能になった。

奈良の中心部の近鉄奈良駅のすぐ近くに引っ越して来て、私はフルリモートでWeb系エンジニアの仕事をしていて、妻は医療系の現場の仕事をしている。

移住して良かったこと

近所が充実していて、散歩が楽しい

近鉄奈良駅付近は、飲食店や雑貨店などの数が非常に多く、家の近くを散歩しているだけで何だか満足した気持ちになってしまう。

とは言え内向的な人間なので、チェーン店以外の飲食店にはなかなか入る度胸がなかったりするのだけれど、飲食チェーンの選択肢も多いのがありがたい。

引越し前の、東京の大田区の外れに住んでいた頃は、近くのまともな飲食チェーンの選択肢がデニーズしかなかったけれど、今はやよい軒、松のや、珈琲館、餃子の王将、松屋、モスバーガー、サイゼリヤなど、色々と気分によって行き分けることができている。

地方移住して一番のメリットとしてチェーン店の話を始めるのはあまりにもアレな感じがするけれど、出不精人間にとって徒歩圏内の充実度は大事だ。奈良以外の一般論としても、東京の家賃の安い地域よりも、地方都市の中心部の方が徒歩圏内が充実しているということは大いにあり得るのではと思う。

家賃が安い

今は毎月の家賃が9万円の2階建て2LDKのテラスハウスタイプの物件に住んでいて、引っ越したときに新築だったので設備が充実していて快適だ。

大田区の頃の築40年以上の戸建て賃貸は、風呂はバランス釜だし、キッチンに蔦が侵入して来るしで色々と大変だった。

移住して良くなかったこと

現地の賃金水準がすごく低い

妻の医療系の仕事の給料が東京にいた頃と比べて尋常でなく下がってしまった。求人情報を見ても、ちょっとびっくりするくらい色々な職種の賃金水準が低い気がする。

ただ、妻の場合それで悲観しているという訳ではなく、最近は歌人・文筆家としての副業でかなりの売上を出していて、日々色々な友人や業界関係者と交流していて楽しそうだ。

夫婦で財布は別でやっているけれど、移住してからは私の家計負担率をより大きくしている*1。移住に際しては、現地の賃金水準と照らし合わせて、世帯収入が無理のある形にならないかの確認が必要ということだろう。

この点、私の職業のWeb系エンジニアは、現在フルリモート可の求人が多数あり、東京の会社の給料で地方都市に住めるのはちょっとずるい感じがする。

関西弁が喋れないと旅行者扱いされる

関東のイントネーションで喋っていると、「ご旅行ですか？」と言われることが多い。地域になじむには関西弁が喋れないとつらい気がする。私も関西の大学にいた頃は関西弁で喋っていたのだけれど、何となく真似て喋っていただけなので、リモートワークしていると日常的に関西弁で話す機会がないし、日常生活で関西弁を話せないと意思疎通に支障があるという話ではまったくないので、どうしても出身地である関東のイントネーションで話しがちになってしまう。

おわりに

何だか地味な話しかしない記事になってしまったけれど、今まで住んで来た地域*2の中では奈良がすごくしっくり来る感触があり、何かない限りはずっと住んでいたいと思っている。

*1:元々私の負担率を大きめにしていたけれど、更に大きく調整した。

*2:平塚（神奈川）、富山、京都、刈谷（愛知）、大田区（東京）。割と多い。

はてブのユーザーの質は低いが、はてブの機能性自体は悪くない

はてな

ヨッピーさんとはてなブックマーク（以下はてブ）ユーザーが揉めたのを発端として、はてブユーザーのマナーの悪さについて議論が起きている。この点については私も一家言あるので書いておきたい。

はてブコメントの何が不快か

上のブロガーの方々も語っているように、はてブのトップページなどに掲載されると極めて不快なコメントが大量につくというのは、多くのブロガーが経験していることだろう。

私も一昔前ははてブでも特に質の低いコメントが付きやすいフェミニズム / ジェンダー論関連の話題でよく記事を書いていたので、記事に不快なブコメが大量に付くという経験をしたことは多い。まずは個人的に感じている、ブコメが不快な理由についてまとめてみる。

論旨と関係ない内容で好き勝手に罵倒される不快さ

まず前提として、文章を書いてインターネットに発表している人間としては、たとえネガティブなものでもフィードバックがあるというのはありがたいことだ。批判されるから嫌だ、という話にはならない。

では何が嫌かというと、記事タイトルや本文の言い回しの一部を切り取って、記事の論旨と関係のない罵倒を好き勝手に書かれることだ。

最近のはてブユーザーはまとまった量の文章を書かない

また、ブコメ以外のまとまった記事でレスポンスを書くようなことがほぼないのも最近のはてブユーザーの特徴だと思う。手間暇かけて書いた記事の中身が何も読まれずに、短文で罵倒されて、はてなスターの承認の餌にされる様子の腹立たしさというのは筆舌に尽くしがたいものがある。

最近のはてブユーザーの不快なところ

  • 文章を読まない
  • 文章を書かない
  • 言葉遣いが攻撃的

まとめると、これらの特徴が最近のはてブユーザーの不快なところ、ということになる。「言葉遣いが攻撃的」については昔から変わらないはてブユーザーの特徴だと思うけれど、「文章を読まない／書かない」は最近特に顕著になっている特徴なのでは、と私は見ている。はてブの不快さは、ひとえにユーザーの質が劣化していることに起因しているのではないか。

とは言え、はてブの機能変更で民度を上げる提案には賛成できない

「人気コメント」欄の廃止など、はてブの民度を上げるための機能変更の議論も今回起こっているのだけれど、個人的にはあまり賛成できない。

悪質ユーザー対策のためにはてブ自体をつまらなくするのでは本末転倒

例えば、はてブコメントの不快さを軽減するためには、はてなスターと「人気コメント」欄を廃止するのが最も有効な機能変更になるだろう。しかし、はてなスターも「人気コメント」欄も本来はてなブックマークのユーザー体験を良くする機能なのだ。

私は先日はてブを普通のソーシャルブックマークとして活用する方法について書いた。記事で紹介したIT分野のように、ユーザーがちゃんと参考になったコメントにはてなスターを付けている場合は、「人気コメント」欄は参考になるコメントの良質なフィルタリングとして機能する。

はてなは継続的に悪質ユーザー対策の機能変更をリリースしている

はてなはこれまでに、悪質ユーザー対策の機能変更を多数リリースして来た実績がある。

最近でも、人気エントリの表示ロジックを変更して、トップページが特定の攻撃的なトピックで占拠されるのを避ける試みがリリースされた。この機能変更によって、トップページが大分見やすくなったと感じている。リリース記事に書かれているように、ユーザーアンケートやインタビューを元に、ユーザー体験に向き合った丁寧な開発がなされている印象だ。

また、上の増田にあるサポート窓口の回答から読み取れるように、表現の自由について骨太な姿勢で運営されている点も、今どきの他の企業やサービスにはないものが感じられて好印象だ。

おわりに

確かに最近のはてブコメントの酷さは目に余るものがあるけれど、これははてブユーザーの劣化によるものであり、はてブの機能変更で対処するのは容易ではなく、また、下手な機能変更ははてブ自体の魅力や機能性を下げてしまうことにもつながる。

私は今のはてなブックマークの機能性が好きなので、一部ブコメの酷さについては一定やむを得ず、そういうものとして対処するしかないと感じている。

『ファイアーエムブレム エンゲージ』 ―ストーリーマップの魅力に原点回帰したSRPGファン待望の一作―

game

『ファイアーエムブレム エンゲージ』をストーリークリアまで遊んで非常に楽しめたのでレビューを書きたい。

駄作の予感しかしない事前印象

事前印象だと、以下のような観点で駄作の予感が強く、「それでもFEシリーズである以上やるしかないか」という後ろ向きな気持ちで購入していた。

  • マルスなどが出てくるクロスオーバー作品
    • クロスオーバー作品はシナリオや世界観が破綻しがちな印象
  • 世界観・キャラクターが幼稚な印象で、特に魅力を感じられない
  • ゲーム部分も「いかにも普通のFE」という凡庸な印象

実際に遊んでみて、正直シナリオやキャラクターの稚拙さについては事前印象そのままな部分もあったけれど、SRPGのストーリーマップ攻略部分の完成度が圧倒的に高く、SRPGファンとして心の底から楽しめるゲーム体験だったため、その魅力について書きたい。

「ストーリーマップだけのSRPG」として遊べるありがたさ

前作の『ファイアーエムブレム 風花雪月』は重厚なシナリオとキャラクターの関係性の掘り下げで高い評価を得た作品で、私も全勢力クリアして楽しめたけれど、拠点要素の拘束時間が大きすぎてストーリーマップ攻略に集中できないことに強いストレスを感じていた。

「拠点要素とランダムバトルがない、ストーリーマップだけのSRPGを遊びたい」それが切実な願いだった。とは言え、現代にそのようなオールドスタイルな作品が出るというのも期待し難い部分があった。

そんな中、本作はまさに「ストーリーマップだけで遊べるSRPG」だったのだ。

具体的に言うと、拠点（ソラネル）の各種ミニゲームやランダムバトル（遭遇戦）自体はあるけれど、システム上任意参加となっており、拠点に行かない、ランダムバトルをやらないゲームプレイが可能になっている。更に重要なことに、クラスチェンジや武器の売買など攻略上必須の要素が拠点外のシステムメニューからアクセス可能となっており、拠点とランダムバトルを縛った条件でも、高すぎない難易度で遊べるように設計されているのだ。つまり、開発者の意図として、拠点やランダムバトルをやりたくない人はやらなくて良いゲームとして作られている。私は難易度ハードクラシックの拠点、ランダムバトル縛りの条件でプレイして、ストーリーマップだけのSRPGはこんなにも楽しいのだと、懐かしくも現代では得難いゲーム体験を新たに得られたことに、本当にありがたい気持ちを感じながら遊んでいた。

シンプルで奥深い戦略性

本作では武器残数システムが廃止されていたり、クラスチェンジが基本と上級の2階層になっていたりと、従来のFEからあるシステムががかなりシンプルに調整されている。

その一方で、本作固有の「エンゲージ」システムによって、FEの過去作主人公の魂が宿った指輪と出撃キャラを任意に組み合わせることが可能で、最大12個手に入るこの指輪がすべて性能の尖った強力なスキルを得られる仕組みになっているため、どのキャラをどのクラスにしてどの指輪を持たせるかによって、キャラの活用性が無限に広がる奥深さがある。実際に「FEエンゲージ」でTwitter検索すると、多彩な攻略法がプレイヤーによって開拓されている様子が分かる。

シナリオは残念な点も多いが、ゲーム部分と連携した表現は見事

Fire Emblem Engage(ファイアーエムブレム エンゲージ) -Switch

Fire Emblem Engage(ファイアーエムブレム エンゲージ) -Switch

Amazon

TwitterやAmazonで本作の評価を読むと、「シナリオは残念だが戦闘は面白い」という評価の傾向がほぼ確立されているように見える。実際に遊んでみて、シナリオについては、いかにも茶番じみた稚拙な部分が多いと私も感じた。

その一方で、マップやエンゲージシステムのようなゲーム部分と連携したシナリオの見せ方には優れたものがあり、ゲーム上の手強い展開とともに手に汗を握るような局面がいくつもあった。

昔からのFEプレイヤーのゆるすぎさんのルナティック初見ノーリセットの実況プレイ動画を見ると、本作のゲーム展開と絡めたシナリオの見せ方がいかに上手いかということがよく分かる。

おわりに

シナリオについては賛否両論の本作だけれど、SRPGのストーリーマップ攻略が好きな人には確実に楽しめる作りになっているので、ぜひ遊んでみて欲しい。個人的には、これまでに遊んで来た色々なSRPG作品を振り返ってみても、本作は最高に近いSRPG体験を与えてくれたと感じている。今は難易度をルナティックにして2周目を遊んでいるところだ。

つながりを求めないインターネット

Twitter

イーロン・マスク体制のTwitterがあまりにも不安定すぎることもあり、私もMastodonを始めてみた。

Twitterのような大企業による開発・運用体制を持たない形態からして当たり前の話ではあるけれど、Mastodonの機能性はTwitterと比べて弱い。その一方で、シンプルな作りであるが故に、何かを投稿して、知らないユーザーからいいねが来るというような、SNSの原始的な体験を再発見できる感覚がある。

対してTwitterはどうか。増えないフォロワー。ミュート。ブロック。有料noteで煽動する論客への苛立ち。引用ツイートでのクソリプ。スペースでのどうしようもない暇人たちの集まり。インタラクティブな「つながり」を実現する機能が充実している一方で、承認欲求と内輪への関心に閉じて行く様に、何とも言えない行き詰まりのような感覚がある。

Twitterに限らず、「つながり」に関心が傾いたインターネット体験は苦しい、と最近私は感じている。

インターネットに何かを投稿するということに、「フォロー／フォロワー」のような目に見えるつながりはなくとも、無限に開かれた可能性に胸をふくらませるような感覚が、かつて誰にでもあったと思う。時代は進んでも、Webの仕組みはそれほど大きくは変わっていない。変わったのはユーザーのあり方だ。

私は「つながり」ではなく自己満足としてのインターネットをもう一度求めてみたいと思っている。その試みの一つとして、まずはブログにこういう簡単なエッセイを書くところから始めたい。

IT系の最新情報のキャッチアップには「はてなブックマーク」を使うと便利

はてな

Web系エンジニアとして働いていて、基礎的な部分の技術理解度が何よりも大事と感じているけれど、その一方で、最新の動向に詳しいのも一定強みになる印象だ。というのも、日常的に最新の技術動向をチェックするということをやっていないエンジニアの方が多く、毎日少しずつチェックするということをやっているだけでトレンドに対する理解度に差が出て来る。

この最新情報にキャッチアップするためのツールとして、私ははてなブックマークが圧倒的にお手軽かつ、目的に応じて柔軟に活用できると感じているため、その活用方法を紹介したい。

はてなブックマークでの情報収集方法

その方法は非常にシンプルで、ただ「タグ検索」をするだけだ。例えば上のリンク先では「JavaScript」のタグ検索で、50ブクマ以上されているエントリが、新着順に表示される。JavaScriptやフロントエンドについて、有益なエントリが表示されていることが分かるだろう。

この検索パラメーター付きのURLをブラウザのブックマークに登録しておいて、毎日朝にチェックして、未クリックの色になっているリンクをクリックして未読記事を読むだけで良い。

私はこれらのタグをチェックしている。自分の興味に応じて、ウォッチするタグを任意に調整すると捗る。

ブックマークコメントがあることのありがたさ

はてブコメントと言うと、一般には、人様の記事にワラワラと集まって来てタイトルだけ読んで罵倒するという、有害なイメージがあるけれど、ことITに関しては本職のユーザーが多いため、ソーシャルブックマーク本来の集合知として、現在でも真っ当に機能している。

技術情報の記事を全部ちゃんと読むのはなかなかにしんどいけれど、ブックマークコメントがあることによって、まずコメントを読んで概要をつかんでから、興味のある記事だけ精読するということができるようになる。また、コメント自体に有益な視点や情報が書かれていることも多い。

おわりに

昔ははてなブックマークのトレンドに上がっている技術記事が何のことを書いているのかサッパリ分からないことが多かったけれど、実務経験を積むにつれて、内容を理解できる記事が多くなって来るのは嬉しい。

主にユーザーの治安の悪さについて、残念な部分も多いはてなブックマークだけれど、無料で使える完成度の高いソーシャルブックマークサービスという側面については、他にない特別な価値があると、日々使っていて感じている。

ライスさんの「からかい」批判を読んだ感想

雑記

ライスさんの記事を読んで、真っ当な批判で、支持できると思った。

その一方で、一般論として、こういった不誠実な議論を展開する論客や、その支持者に抗議することはなかなか難しいものがある。

まず、記事中でライスさんがされているような、特定界隈の攻撃のターゲットになることは、なかなかに耐え難いストレスを生むだろう。

また、このライスさんの記事に関するTwitterの反応を見れば分かるように、このレベルの事象についても、「どっちもどっち」的な相対化や、「からかい」や「いじめ」などの用語について、記事と無関係な文脈での一点突破の「論破」を試みる人間が多く、このような論客に言及すると、論客本人だけでなく、好き勝手に小理屈を展開する有象無象のユーザーの出現に苛立たしい思いをすることになりそうだ。

そのような中で、

というか、御田寺の行っているような「からかい」行為を許容しないというくらいの良心は、わたしに限らず、誰にでも持っていてほしいものだ。御田寺やその取り巻きの「からかい」行為を見て見ぬ振りをしながら、「御田寺の言論にも耳を傾けるべきところがある」としたり顔で言っている人々に対しては、いじめに参加している人に対して抱くのと同じような軽蔑の気持ちをわたしは抱いている。

ライスさんの記事が、敢えてどうとでも小理屈で反論できそうな、隙のある道徳的言及で締められているのは面白いと思った。こういう言いっぱなしの価値観の表明で実際十分なのだろうなと思う。

RailsでシンプルなREST APIを設計する

Rails

業務のRailsサーバーサイドのAPIリファクタ対応を通して得られた知見について、前回はService Objectについて書いたけれど、今回はREST API周りの手法について書きたい。

全体的にRails wayに沿って、実装者の恣意性による方針のブレを極力排した、見通しの良いリソースベースの設計を実現することを意識している。

REST APIのエンドポイント設計

CRUDの基本アクションの使用を優先し、適宜リソースを分割する

コントローラが元々持っているRESTアクションやデフォルトの5つの機能にはないメソッドを付け加えたいと思ったら、いつだって新しいコントローラを作る。それだけでいいのです。

上の記事でDHHが述べているように、index、show、new、edit、create、update、destroyの基本アクションの利用を優先し、独自アクションの定義を避けることは、リソースベースのエンドポイント設計の方針を明確化し、controllerの処理の見通しを良くする。

その一方で、DBのテーブルと1対1でcontrollerのリソースを定義している場合は、基本アクションのみで現実のビジネス要件に応えることはすぐに難しくなるだろう。DHHは、DBのテーブルとの対応にこだわらずにcontrollerのリソースを分割することで、基本アクションのみで実装できるとしている。

個人的には、厳密に基本アクションだけ使うのがベストかどうかは何とも言えない気がするけれど、DBのテーブルとの1対1にこだわらずにcontrollerのリソース分割を考えて良い、という考え方については、リソース設計の柔軟性がグッと増して視界が開けるような感覚があった。

resourcesメソッドの利用

上の基本アクションの利用と関連して、ルーティングの設定にresourcesメソッドを利用するとroutes.rbの記述がシンプルで見通しが良くなり、かつ実装者の恣意性によってエンドポイント定義のルールの一貫性が損なわれることがない。

resourcesメソッドをネストしてcontrollerを別立てする手法も便利だ。簡単な例で言うと、

このようにroutingを書くと、

Prefix Verb URI Pattern Controller#Action
posts GET /posts(.:format) posts#index
user_posts GET /users/:user_id/posts(.:format) users/posts#index

rails routesで出力される定義がこうなり、

このように、投稿の一覧APIとユーザーに紐づく投稿の一覧のAPIを別のcontrollerで定義できるようになる。

namespaceの分離

上のresourcesメソッドをネストするテクニックと併せて、namespaceメソッドを利用することでも、同じリソースについて完全に分離された複数のエンドポイント定義、controllerの実装を持つことができる。

例えばユーザーアプリケーション向けのAPIと管理画面向けのAPIが同じコードベースで実装されている場合に、管理画面向けのAPIに dashboard namespaceを割り振って、影響範囲を分離した上で別の体系のAPIとして実装する、というような使い方ができる。

Mastodonのroutes.rbを見ると、Railsのroutingの様々な手法が博覧会的に用いられていて参考になる。

総じて、業務でのREST APIの活用を考えると、多重実装的な考え方を許容してでも、文脈ごとにリソースを分けて影響範囲を分離し、個別の要件に柔軟に応えていくような考え方が持続可能な開発につながると感じている。

JSONレスポンスのフォーマットを統一する

業務のリファクタ対象がJSONを返すタイプのAPI（フロントエンドはReact）だったため、JSONレスポンスのフォーマットが実装者依存で無秩序にならないようにするため、下記のような手法を導入してみた。

ActiveModelSerializersを利用する

リファクタ前に使われていたjbuilderのレスポンス定義が規則性のない無秩序状態でつらすぎたので、ActiveModelSerializersを導入してみたところ、当初の予想以上に快適に使えて驚いた。

ActiveModelSerializersは上のサンプル実装例のように、Railsのmodelに対応するserializerを用意して、Railsのmodelと同じようにhas_manyやbelongs_toでアソシエーションを定義できる。このserializerをcontrollerで指定するだけで、モデル間のアソシエーションを含むレスポンスについても、ActiveModelSerializers側で決まったフォーマットで返すことができるようになる。

基本的なユースケースが如何にもスマートに見える一方で、複雑なビジネス要件に対する柔軟性が低いのではないかと気になっていたけれど、実際には

  • 1つのRails modelに対して、複数のserializer classを定義して、任意に使い分けることができる
    • 例えばnamespaceごとに別のserializerにするなど
  • controllerでincludeオプションを指定することで、定義されたアソシエーションのうち、どの範囲をレスポンスに含めるか、エンドポイントごとに任意に指定できる
  • 任意のオプションを作成して、controllerから渡した値を元にプロパティの出し分けを制御したりもできる

など、痒いところに手が届く機能が実装されていて、非常に柔軟に活用できるライブラリだった。

逆に苦手なユースケースとしては、ActiveModelSerializersを使った場合には配列形式のJSONレスポンスの件数が多くなるほどパフォーマンスが悪くなるので、大規模なデータを返す必要がある場合には他の方法を検討した方が良さそうだ。

エラーハンドリングの方式とJSONフォーマットの統一

リファクタ前のプロダクトはサーバーサイドのエラーハンドリングとレスポンスフォーマットの方式がバラバラで、その結果としてフロントエンドでもまともにエラーメッセージの出し分けができていないなど、悲惨な状態だったので、上のような形で、エラーメッセージと、class名を変換したエラーコードを返すシンプルなフォーマットでまずは統一させてみた。

世の中のWebアプリケーションの実装を見ると、Railsでのエラーハンドリングの方法とJSONのエラーレスポンスの返し方には様々な手法がある印象で、別のアプリの設計に携わる機会があればまた改めて深く考えてみたいと感じている。

おわりに

  • リソースを文脈ごとに分割して、見通しの良いエンドポイントを設計する
  • レスポンスフォーマットの決定について、実装者の恣意性によるバラつきを排除できる仕組みを導入する

全体を通して、これらの観点が見えて来たように思う。

リファクタ業務を通じて、RailsでのREST API設計については一定知見のようなものができてきたけれど、REST APIはビジネス要件に柔軟に応えるために、リソースとエンドポイントを分割して個別対応するという、多重実装を許容するようなアプローチを取らざるを得ない点に融通の利かなさを感じる部分はあり、この点でGraphQLの活用が近年注目されているのかなと思ったりもした。GraphQLでのAPI設計にも機会があればぜひ関わってみたいと感じている。