Wonder Tech

疑い歩く

時間を確保してもあっという間に過ぎていく

去年の11月に仕事をやめてから約7か月が経ちました。

その間どうやって過ごしていたのかを備忘録的に書き留めていきます。

なぜ無職になったのか

次を決めずに無職になったのは、カンファレンスコアスタッフ業のためにまとまった時間が欲しかったからです。

一番は初開催となるReact Tokyo フェス 2026のためではありました。

speakerdeck.com

どう過ごしたか

11月 ~ 12月

仕事をやめた反動でめっちゃカンファレンスに行きまくっていました。ときには10日間ずっとカンファレンスに行くみたいな状態にもなってしまいました。。。

1~2月

一転してずっとReact Tokyoフェスの準備をしていました。毎日ノベルティを作ったり、印刷物のデータを作ったりで実質働いているような感じでした。

3~5月

クラウドネイティブ会議の準備をしつつ、転職活動をしていました。

この時から転職活動を始めましたが、以前よりもジュニア、ミドルの募集数が減っており、特にシニアエンジニアやテックリード向けの求人が目立ちました。

かなり就活には苦戦し、12月ぐらいからちゃんとやっておいたほうが良かったと後悔をしています。

ご縁があり、なんとか就職ができて安心です。

6月

地方カンファレンス遠征→疲れる→2日間ぐらいずっと寝るのサイクルを繰り返してしまい、2週間が過ぎてしまいました。

もったいない時間の使い方だなと反省しています。

過ごしてみて

何も無限にあった用に思える時間も気がつけばあっという間に過ぎてしまいました。

この期間に突入した最初はもっと基礎的な勉強をしたり、個人開発をしたりで技術力が向上できると夢を見ていました。

実際は、日々開発外のことをしていたり、就職活動に時間を大きく取られたりとでした。

コードを書く時間は大きく減り、以前より開発の勘が鈍ったように感じます。

働いている時は「成長できていない」と感じることもありました。

しかし振り返ってみると、日々の業務の中で少しずつ知識や経験を積み重ねていたのだと思います。

成長は止まっていたのではなく、気付きにくいだけだったのかもしれません。

もっと計画的に・・・みたいなことを考えるとキリがないですが、事実、時間をどう使うか自制をしないと過ぎ去っていくのをその身を持って体感しました。

7か月という長いようで短い時間を過ごしてみて、時間は意識して使わないと本当にあっという間に過ぎてしまうのだと実感しました。

また働き始めるので、この経験を忘れずに一日一日を大切にしていきたいと思います。

関ヶ原Ruby会議01 参加レポート

2026年5月30日に岐阜県関ヶ原町で関ヶ原Ruby会議が行われました。

自分の実家が隣町にあり、会場まで車で15分という立地で開催されました。

これまでRubyを業務でやってこなかったのですが、場所だけで参加を決めました。

印象に残ったセッション

Sorbetの型がRailsのMVC全てを貫通するまで

speakerdeck.com

React(Next.js) × Hono × DrizzleでTypeScriptではありますがバックエンドからフロントまで型を共有して開発したことがあったので、その経験を元にセッションを聞きました。

フロントエンド、バックエンドの全てで型が共有されることは、2点良さがあると思っています。

  1. 型の二重管理が減る

はい。そのままですね。

最近転職活動をしてみて昨今はフロントエンド、バックエンドのどちらか一つだけ専門的に行うことが減っていると感じました。

一人のエンジニアが機能開発をする際にフロントエンド、バックエンドそれぞれで型を書くことになると手間です。

機能を横断的に開発するからこそ型も横断的に使えるべきだと考えています。

昨今の開発体制から見ても型修正にかかる工数を削減できるメリットがあります。

  1. フロントエンド、バックエンドで型で表現したいコンテキストの抽象度が上がる

フロントエンドとバックエンドそれぞれで型を定義するとUI表示の都合で追加されたフラグや、一時的な表示状態を含む型ができやすいと考えています。

バックエンドも同じようにDBのテーブル表現に寄った型などが出来やすいです。

それぞれの固有の事情が入り込んだ型は時としてノイズになります。

フロントエンド、バックエンド両側面で見たときに過不足のない表現がされた型を書くとなると、自ずとドメインの情報が詰め込まれたドメインモデルに近い型表現がされます。

合戦

最初は何が始まるのだろうと思っていたのですが、みんなで玉入れをやりました。

申込時の東軍 or 西軍の回答で赤(東軍)、白(西軍)に分かれてわちゃわちゃと玉入れです。

結果は白(西軍)が勝ち、史実が塗り替えられた歴史的瞬間を目にすることが出来ました。

懇親会

懇親会である方と現状の勉強会についてお話しました。

最近のカンファレンスや勉強会は、運営も発表もすごくきれいになっていて、参加しやすくなっていると思います。一方で、昔あった雑さや熱量みたいなものは少し減っているのかもしれない、という話になりました。

昔は、駅前.jsのような勉強会に企業のオフィスで100人くらい集まることもありました。Rubyの人がJavaScriptのイベントに行ったり、その逆があったり、コミュニティを越えて動く人も多かったそうです。

ただ、ライフイベントやコロナでオフラインの場が一度途切れてしまい、その文化が下の世代にうまく伝わらなかった部分があるのかもしれません。

LTについても、今はきれいで学びのある発表が多いですが、もともとはもっと初心者が話すための場だったのでは、という話が印象に残りました。5分だけ、とにかく人前で話す。資料が粗くても、N番煎じでもいい。そういう雑さがあったから、登壇のハードルが低かったのだと思います。

カンファレンスの濃さは、発表の完成度だけではなく、初心者が雑に話せる空気や、コミュニティを越えて人が混ざるところから生まれるのかもしれないなと思いました。

まとめ

地元で開催されたのはとても嬉しかったです。

懇親会の後、有志で養老の焼肉屋に行き、その案内兼運転手という地元を他の人に知ってもらえるという体験が新鮮でした。

初めてRuby会議に参加しましたが、YAPCに似たゆるくも濃いカンファレンスでとても居心地が良かったです。

今後やったことのない言語、職種のカンファレンスでも行ってみようと思えるそんな良いイベントでした。

クラウドネイティブ会議 at スタッフ業記録

5/14,15に名古屋の中日ホールにてクラウドネイティブ会議が開催されました。

自分は実行委員として入っていて、その備忘録となります。

やったこと

プレーリーカードさんとの連携を担当しました。

連携企画として、プレーリーカードを読み込むと風雲戦国見立帖という診断アプリが体験できます。

詳細は下記の記事よりご確認ください

kaigi.cloudnativedays.jp

その企画向けに、プレーリードックがカードを支える台座を作りました。

みなさんから出来が良いとお褒めの言葉をもらえて嬉しかったです。

去年のCloud Native Days Winterで、以前趣味で作っていたマーモットの置物をプレーリーカードさんへお貸ししました。

そこから着想を得て、今回新規に専用の台座を作ったら面白そうだなと考えて製作しました。

どうやって作ったか

モデル自体は3Dプリンターで作成しました。

そこからプレーリードックの写真を参考にしながら塗装をしました。

3DモデルはGeminにサンプル画像から3方向からの画像を生成してもらい、それらを使ってTripoというSaaSでの3Dモデル生成AIで作りました。

また、そこからFusion 360で作ったカードホルダー部分をBlenderで合体して最終的な3Dモデルとなります。

自分自身Fusion360 は使えるのですが粘土こねこねするようなモデル製作は苦手で、AIに助けてもらいました。

やってみて

当日置いてみて、2日間ほぼブーススタッフをしていたのですが、プレーリーカードの話ではなくこれどうやって作ったんですか?みたいな会話がひっきりなしに来ました。

自分が意識せずこれぐらい普通だろうと思っていることも他の人の間隔ではそうではないと実感しました。

こうしたクラフト能力は、10年ほど趣味として作り続けてきた積み重ねによるものです。

みなさんも得意なこと好きなことがありましたら、そのことについてカンファレンスでの企画で思う存分に手腕を振るってみてはどうでしょうか?

楽しいですよ‼️

フロントエンドカンファレンス名古屋参加レポート

2026年5月9日にフロントエンドカンファレンス名古屋がウィンク愛知にて開催されました。

主催者のSatakeさん、Wabiさん、did0sさんお疲れ様でした!

当日スタッフとして、カンファレンスに参加しましたので、その様子をお伝えできればと思います。

すごく興味を持ったっセッション

基本的に1日中スタッフ業を行っていたので、セッションを多くは見れませんでしたが、それでも学びになることがありましたので共有させていただきます。

SPAに依存しないReact移行

www.docswell.com

当日スタッフとして、タイムキーパーをしながら、上記のセッションを聴講しました。

結論としては既存画面のCSSとReact部分のCSSを隔離するためにReact部分をShadow DOMで隔離するやり方をしていました。

上記のやり方は0か100かの移行ではなく、それまでの資産を活かしながら既存画面とReactの新規画面が相互に悪影響を与えなくて済む、とても良い方法だと思いました。

また、個人的にはiframeでの対応でも問題ないのではないかと考えていたため、セッション終了後に登壇者の方へ、その旨の質問をしました。

回答として、画面のちらつきや既存画面とiframe画面の読み込みの差で、表示体験を損ねてしまうのと、クロスドメインになることで開発が複雑になるということでした。

確かに過去の自分の経験としてiframeでReactの画面表示機能を作ってきた経験があるのでなるほどと思いました。

最終的に、部分移行の手段としてShadow DOMを利用する知見が溜まったのでとても学びになりました。

フロントエンドカンファレンス名古屋自体に感じた個人的な思い

名古屋という土地で開催された嬉しさ

自分の地元が岐阜で、名古屋ではないものの、この東海地方でカンファレンスが開催されたことはとても嬉しかったです。

その嬉しさから開催される情報を聞いた途端に主催のSatakeさんへとりあえず当日スタッフさせてくださいとお願いした思い出があります。

この嬉しさは例えるなら自分の得な技術を他の人に教えているときと似ている気がします。

何かを他人に教えるのは、その人の可能性を広げられたのだと感じるので、個人的にはとてもやりがいに似たものを感じます

スタッフの1/3が学生という若さ

フロカン名古屋ではスタッフの大体1/3が学生というとても若いスタッフ陣となりました。

これは、これまで学生主体でコミュニティ活動を行ってきたSatakeさんによるものが大きいと思います。

これまでは会社であれ、コミュニティであれ、年下ムーブで振る舞ってきたことが多かったです。

ただ、今回相対的に中堅ポジションとして参加してみて、当たり前ではありますが、年を取ったなと思いました。

そして、今回のスタッフの年齢分布を会社に当てはめてみると30代中盤ぐらいの位置として、自分は価値を発揮できるのだろうかと自問自答をしてみると、マネジメント方面でまだまだと思いました。

はたして、今この人たちに自分がリードできる部分はあるのだろうか、取りまとめて成果は出せるのであろうか、こういったことを考えると、難しいなと率直に思ってしまします。

そのために一つ自身を持てる分野が欲しいので、今後の技術を学ぶスタンスを変えていきたいです。

おまけ

スタッフ向けにフロカン名古屋のロゴキーホルダーを作りました。

皆さんにかわいいと言ってもらえて、作った甲斐があったなと思います。

また、このキーホルダーがあることで、カンファレンスを作り上げた思い出の品となればいいなと思っています。

今、リーダブルコードを読み直してみて

リーダブルコードは、「読んでよかった本は?」というアンケートで、よく名前が挙がる本です。

本書は良いコードを書くためのエッセンスが散りばめられた昔から読みつがれる名著です。

www.oreilly.co.jp

最初にこの本を読んだのは、自分が1年目エンジニアとして働き始めたタイミングでした。

そこから約5年たったこのタイミングで読み直した感想をお伝えします。

名前付けの本だと思っていた

1年目の自分は、本書を「適切な名前付けの重要性を説いた本」だと理解していました。

今振り返ってみても、その理解は間違いではありません。

本書を抜粋して例えると filter というメソッド名は、条件に合うデータを「選択する」のか、不要なデータを「除外する」のかが読み取れません。

そのため本書では、select(選択)や exclude(除外)のような明確な名前を使うことが推奨されています。

こういった変数名・関数名の付け方が多く解説されていたため、1年目の自分はその印象に引っ張られていました。

名前付けの先にある目的

今回読み直して、その理解には大事な視点が欠けていたと気づきました。

名前付けやコード構造には、見た目を整える以上の役割があります。

その役割とは、「このコードは何を目的としているのか」という意図を読み手に伝えることです。

今振り返ると、自分は「どう書くか(手段)」は理解していました。

しかし、「なぜそう書くのか(目的)」を見落としていました。

つまり本書が一貫して伝えているのは、コードを通じて書き手の意図を読み手に正確に伝えることでした。

読み直して、名前付けもロジックの整理も、突き詰めるとすべてこの一点に収束するのだと理解しました。

名前が適切でも、意図は伝わらない

この視点で読むと、「適切な名前を付ける」だけでは不十分だということがわかります。

たとえば getUsers という名前があったとします。

しかしこの名前からは、次のことが判断できません。

  • 有効なユーザーのみを取得するのか
  • 全件を取得するのか
  • キャッシュを使うのか

名前が適切でも、その背景にある意図まで表現できていなければ、読み手はコードの目的を誤認してしまいます。

自分が2年目3年目あたりで書いてきたコードにも、同じ問題がありました。

「まず動くものを作る」ことを優先するあまり、意図を伝えることが後回しになっていたのです。

その結果、自分が書いたコードなのに時間を開けるとコードの読み直しに時間がかかってしまうことがありました。

そしてその視点で過去のコードを振り返ると、自分が書いてきたコードの問題が「名前の付け方」ではなく「意図が伝わっていないこと」だったと気づきました。

今回読み直してみて

一度読んだ本でも、時間を置いたり、経験を積んだりした後だと、自分の中で新しい発見がありました。

もし読んだことがありましたら、改めてリーダブルコードを手に取ってみてはどうでしょうか?

おまけ:巻末の解説ページもぜひ読んでほしい

本編が終わると、そこで本を閉じてしまいがちです。

しかし巻末の解説ページには、「コードで意図を正確かつ過不足なく表現する」という考え方が、実際に本書を読んだ人の経験談を交えてわかりやすく整理されています。

本編の抽象的な考え方をより具体的に理解する助けになるので、ぜひ読んでみてください。

むしろ解説ページを先に読んでから本編に進むのも、良い読み方かもしれません。

多摩川.dev #1を開催しました!

2026年5月1日、多摩川駅近くで「多摩川.dev #1」を開催しました。

mokumokutamagawa.connpass.com


多摩川.devとは?

まず最初に多摩川.devについて整理しようかなと思います。 「多摩川.dev」は、多摩川周辺のエンジニアが気軽に集まれる場を作りたい、という思いから始めました。

多摩川.devで大事にしていること

このイベントで特に大事にしているのは2つです。

① 技術の垣根を越える

いろんなコミュニティに参加して感じたのは、

「コミュニティが変わると知ってる人がゼロになる」

ということでした。

だからこそ、多摩川.devではフロントエンド、バックエンド、インフラ、デザイナー、PM、言語や技術領域に関係なく、「初めて会う人とつながれる場」を目指しています。

② フィードバックでコミュニケーション

もう一つは「フィードバック文化」です。

  • 発表中は相槌OK
  • 終わったら拍手
  • 感想も歓迎

登壇者ファーストで、 「話してよかった」と思える場にしたいと考えています。

上記の詳しいお話は、最初のオープニングでお話させていただきました。

より詳しく知りたい人は下記のスライドをご確認ください!

speakerdeck.com

お菓子:大黒堂

今回はちょっとしたプレゼントとして 鮎焼きを用意しました。

地元で有名なお菓子屋さんの多摩川らしいお菓子です。

大黒堂の鮎焼き

LT

今回7人もの方にLTをしていただきました。

各LTを聞いて印象に残ったことや聞いたうえで考えたことを書きつつ、ご紹介していきます。

1人目:幡ヶ谷亭直吉さん「フィードバックは贈り物」

speakerdeck.com

幡ヶ谷亭直吉さんからはフィードバックを通して、アウトプットをしていくことの素晴らしさを発表していただきました。

特に、コウモリが互いの位置を知るために超音波を発する「エコロケーション」を例に、自分のやりたいことを世にアウトプットしていくことで視野や考えなどが広がっていくのはとても共感できました。

事実、今回の多摩川.devも、1年ほど前から自分が「やりたい」と話し続けていた中で生まれたものです。

お話の内容に共感できるところが多く、アウトプットしていくことの重要性を強く実感しました。

改めて、多摩川.devではこのようなエコロケーションによって皆様の可能性が広がる、そんな場にしていきたいなと考えさせられた発表でした。

2人目:フクイさん「タマの旅〜The Beautiful Tama River」

フクイさんからはキノの旅をオマージュした形のタイトルで、多摩川流域にあるITコミュニティの紹介をしていただきました。

発表されたコミュニティの中でいくつかは知っていたものの、LINEグループで交流されている「狛江IT部」さんがあったり、AEONさんの映画館を借りてLTを行う「シネマ de LT」を新たに知ることが出来ました。

その話を聞いて、狛江IT部さんのLINEグループに参加してみたので、今後イベントがあったらそちらにも顔を出して行きたいです!

また、LT内ではないですが、フクイさんから多摩川サミットと銘打って大規模なイベントをやりたいとのお話も聞きました。

多摩川流域全体でコミュニティの活性化につながる動きはとてもワクワクしますし、また、色んな人のやりたいことを話せる場を作りたいと自分が思っていたこととも重なりました。

自分が作りたかった「いろいろな人のやりたいことが自然に話される場」に少し近づけたと感じました。

3人目:小泉岳人さん「多摩川とセレンディピティ」

www.docswell.com

小泉岳人さんからはセレンディピティについてのお話をしていただきました。

前提として、セレンディピティの意味についてですが、「思いがけない発見や偶然の能力」、「価値あるものを偶然見つける能力」とのことです。(スライドから抜粋)

セレンディピティに似た言葉で偶発的計画性理論という言葉をよく目にしますが、似たニュアンスを持つ英単語があるのを知れました。

自分自身、思い返してみるとセレンディピティを感じるシーンや場面が多かったなと感じています。

発表の中で、セレンディピティを高めるために「偶然 × 洞察 × 行動」とありました。

セレンディピティを高めるために(スライド抜粋)

振り返ってみると、セレンディピティを感じる場面が多かった背景には、自分なりに行動量を積み重ねてきたことがあったのだと思います。

行動量が今までのものを支えているのだと実感した一方で、洞察力がもっとあればまた違った出会いがあったのかもと思います。

せっかくの次に繋がる機会があっても、それを逃しては損なので、僕は今後、洞察力を鍛えていかないといけないですね。

4人目:Negimaさん「AIを導入する前にやるべき事」

speakerdeck.com

NegimaさんからはAIを導入する前に、ドキュメントを構造化して、情報を整理することによるAIの回答精度向上にまつわるお話をしていただきました。

話を聞いていくとタスクの定義が甘かったり、手順が明確化出来ていない部分のドキュメントを改善することで良くなったとのことで、AIに限らず、人を動かしていくときにも気をつけないといけないなと思いました。

また、AIの精度向上という文脈だけでなく、タスク設計やドキュメントの質が成果に直結する点は、日々の開発にも通じる重要な学びでした。

何よりも印象に残った嬉しいことが、今回外部で登壇することが初めてとのことで、貴重な最初の登壇場所に多摩川.devを選んで頂いてとても嬉しかったです。

5人目:Steve Aokiさん「フィールドエンジニア at 多摩川」

speakerdeck.com

Steve Aokiさんからは多摩川の食べれる野草の紹介をしていただきました。

普段何気なく見ている多摩川ですが、どんなものが生えているかと一つ解像度を上げるとより楽しめるなと感じました。

多摩川へはいつも散歩しているのですが、その際に食べられる雑草がないのかなと考えるきっかけにもなりました。

次の散歩に行くときに何かしら野草を採ってきて、食べてみようと思います。(ミントが使い勝手良さそう)

6人目:ゆずねりさん「色を視る」

speakerdeck.com

ゆずねりさんからは我々が目で知覚している色の仕組みについてのお話をしていただきました。

普段からイラレや、塗装など色を扱う場面は他の人より多い自分ですが、その仕組みについてはあまり意識してこなかったです。

RGBが光の混合で色を作り出している一方、CMYKが色の吸収により印刷物上で発色しているという違いは個人的に知識面として面白かったです。

またフィードバックタイムでなぜ黒はスライド上に写っているのかを自分が質問させていただきました。

回答として、「できる限り黒の箇所に光を当たらないようにしている。とはいえ、光は出しているので、例えばダークモードの画面を投影するとコントラストの比率で見にくくなる。」といただき、登壇時のアクセシビリティを考えるきっかけになりました。

例えばですが、黒基調のスライドでの投影はかっこいい一方で、上記の問題をはらんでいると思います。

なので、プロジェクターの原理を意識した白基調のスライドを作るように意識していこうと思いました。

7人目:松尾淳平さん「AI時代に技術記事を書き始めて起きた、私の中での小さな変化」

speakerdeck.com

松尾淳平さんからは技術記事を書いていった結果、どのような変化が起こったかについてお話しいただきました。

特に印象に残ったのが、情報をただみてわかった気になるが、学びにはなっていないとおっしゃっていた点でした。

自分自身も思い当たる節があり、カンファレンスなどでセッションを聞いて、なるほどなと思う一方で、その学びが日頃の業務で実践できるだけの血肉になっていないと常々思っていました。

こうして、当日の振り返り記事を書いているのも、学びの定着の側面だったりします。

話は変わりますが、4人目のNegimaさんと同様に今回が初の登壇とのことで、こちらもめちゃくちゃ嬉しかったです。

飛び入り1 おさないさん 

note.com

飛び入り1人目のおさないさんからは、PHPカンファレンス新潟 2026のプロポーザル募集開始の宣伝をしていただきました。

自分もこのペチコン新潟には実行委員として関わっています。

また、PHPを知らない人たちにもこのお話の訴求が出来たことがとても大きいと思います。

どうしても、言語系は言語が違うと全く違う人達でコミュニティが形成されていると自分では考えていて、そこに飛び込むハードルの高さが一定あるとも考えています。

今回、中の人と面識を作ることで、参加者にとって参加のハードルを下げるきっかけにもなったと思いますし、個人的な思いとしては、カンファレンス当日に多摩川.devで会った人たちと会いたいなと思っています。

なので、皆さん!プロポーザルお願いします🙏

飛び入り2 ふりはたさん

飛び入り2人目はふりはたさんです。

「起業の科学」の本をベースとしたAIから指摘をもらって個人開発をしているというお話をしていただきました。

www.amazon.co.jp

どうしても、プロダクト志向で「どのような機能が本当に求められているのか」を考える機会は、自社開発や事業会社の環境にいないと得づらい面があると思っています。

とはいえ、そうでない環境で工夫しながら日々個人開発されているところにプロダクト思考は環境だけでなく、こうした日々の積み重ねでも十分に伸ばせるのだと気づかされました。

実際にやってみて

正直なところ、

「成立するのか?」という状態からのスタートでした。

でも、やってみると

  • 初めて会う人同士が話している
  • フィードバックが自然に出ている
  • 次につながる会話が生まれている

という、やりたかった状態が少し見えました。


これから

まだ次回をいつやろうかは決めていません。

ただ、今回の回を終えて、初対面の人たちが楽しそうに話している場面はとてもやりがいに感じました。

次に開いたらどんな交流が生まれるだろうとワクワクしているところもあるので、もう一度やりたいなとも考えています。

もしこの記事を読んで

「ちょっと気になるな」

と思った方がいたら、ぜひ次回遊びに来てください。