こんにちは。ファインディ株式会社でFindy Team+の開発をしているkameです。 経歴としては、異業種から転職して現在エンジニア2年目です。ファインディには2026年5月に入社し、5ヶ月ほどが経過しました。 ファインディでは設計、実装、レビューなど各プロセスにおいてAIを活用しています。 このような経歴、環境下での私自身の思考の変化や、取り組んできたことに関して紹介します。 入社直後に感じたことから、事業に貢献したいと考えるようになるまで AIを活用して設計・実装するには、基礎力が必要だと実感した 基礎力強化が推奨される環境下で、勉強会に参加 個人学習として取り組んだこと 基礎力の強化が、普段の設計・実装にどのように生きてきたか ジュニアエンジニアの成長を支えてくれる会社のカルチャー 定期的な1on1や勉強会を通じて、自分の中の不明点を整理できる 基礎力強化を応援する文化 まとめ 入社直後に感じたことから、事業に貢献したいと考えるようになるまで 入社直後は、実装経験をたくさん積んで、エンジニアとしての技術力を高めたいという気持ちが第一にありました。 実際に、入社2日目から技術改善系のタスクにアサインしていただきました。プロダクトのドメインを理解しながら技術面の知見も深められる、良い環境だと感じています。 実際のアクティビティの推移を見ても、入社後から少しずつ伸ばしてこられたと感じています。(各棒グラフは上からイシュー作成数、プルリク作成数、マージ済みプルリク数、コミット数、レビュー数) 入社して1ヶ月半が経ったタイミングで、期の変わり目にAI時代の開発組織を模索する新しいチームが立ち上がり、そこにジョインすることになりました。 このチームでは、事業部メンバーからの声や顧客の声を直接聞き、エンジニアが要望のヒアリングから企画、実装、リリースまで一貫して行っています。このチームにアサインされたことをきっかけに、事業貢献の意識が強くなりました。 タスクとしては、社内のカスタマーサクセスから上がってきた要望を受け取り、Issueに落とし込んで実装まで行う機会が増えました。 直近ではFindy Team+のMCPサーバーを中心に開発しています。MCPツールの追加や関連するAPIの開発だけでなく、MCPツールの効果を追跡できるログや集計の基盤を作ったり、カスタマーサクセスと一緒にプロンプト例を考えたりしています。 この過程では、初めて実務で使う言語のキャッチアップを個人で進めたり、レビューを通してより良い書き方を学んだりしました。また、MCPサーバーは画面上に見える機能ではないため、実際に自分でプロンプトを試し、他の人からもフィードバックをもらいながら、どのような出力が出れば利用者に価値を感じてもらえるかを調整する難しさも経験しました。 ビジネスサイドと連携しながらタスクを進める過程を経験する中で、個人の技術的な知見を深めるだけでなく、事業に貢献できる状態を目指したいと思うようになりました。 AIを活用して設計・実装するには、基礎力が必要だと実感した しかし、AIを活用して設計、実装する上では、課題を感じることがありました。AIの出力する情報に理解の足りない単語が多く、AIが何を言っているのか調べるだけで、時間がどんどん過ぎてしまうこともありました。具体的には、次のような場面です。 問い合わせ起因で通信周りを調べる必要があった際に、「トランスポート層で処理される」という話が出ても、TCP/IPモデルの知識が乏しいため、何が行われているかのイメージがつかなかった パフォーマンスを考慮する必要があった際に、アルゴリズムのパターンの知識が足りていないため、既存のコードを参照して書かれたAIのコードに対して、「より良い書き方はないか？」という疑いの目を持つことができなかった また、AIとの壁打ち以前に、Issueを読み解く段階で苦労することもありました。例えばデータベース関連のIssueでは、ACID特性に関連する用語を理解しきれておらず、AIに解説してもらう必要がありました。 これらの課題は、実装以前に、コンピューターサイエンスの基礎知識が不足していたことからきていました。 このままではAI前提の開発のスピードについていけなくなる、という危機感を持ち、基礎知識を固めたいという気持ちが強くなりました。 基礎力強化が推奨される環境下で、勉強会に参加 ファインディでは、コンピューターサイエンスの基礎力強化のために、基本情報技術者試験レベルの知識習得がエンジニア全員に求められています。 そうした中で、有志によって開催されていた週1回の勉強会に誘っていただき、コンピューターサイエンスの基礎知識を学習するようになりました。 勉強会では、基本情報技術者試験の科目Aの過去問を実際に解き、シニアエンジニアの方から「どのような場面で役に立つ知識か」を説明いただきながら解答を理解していきました。 印象に残っているのは、リエントラント（再入可能）に関する問題を扱った回です。例えばRubyでは、変数が外部から書き換えられないようにローカル変数を使うといった考慮を行う、という話を聞き、安全なプログラムを書く上で覚えておくべき概念だと感じました。 これまで、資格勉強が普段の業務にどう役立つのかはイメージがつきませんでした。業務を進める上での土台となる知識だと自分の中に落とし込めたのは、勉強会に参加して良かったと思う点の1つです。 個人学習として取り組んだこと 基本情報技術者試験に合格する上では、過去問のテキストを購入して、本番の時間内に解けるまで周回しました。 今回は合格自体が目的ではなく「基礎力の強化」を行いたかったので、追加で次の点を意識しながら学習に取り組みました。 選択問題に関しては、正解以外の選択肢に関しても理解を深める 正解以外の選択肢は、別の基礎的な用語に関する説明であることも多いため 問題と実務の記憶が紐づく場合は、その場面をノートにメモしながら解説を読む 実際の実務に結びつけて理解した方が、同様の場面に遭遇したときに知識が生きるため 結果として、基本情報技術者試験に合格することができました。 基礎力の強化が、普段の設計・実装にどのように生きてきたか まだまだ足りていない基礎知識が多いという感覚はありつつも、コンピューターサイエンスの知識が全くなかった状態から知識を身につけると、次のような実感がありました。 設計や実装の壁打ちをする際に、AIの出力する内容で理解できる単語が増えた分、以前と比べてやりとりがスムーズになった 既存コードを読む際に、「どのようなアルゴリズムのパターンで書かれているか」を意識し、「別のパターンで書いたら計算量はどうなるか」という観点でAIと壁打ちするようになった 問い合わせや社内の会話の中で、AIに聞かなくても理解できる概念が増えた 例）IPアドレスとサブネットマスクから利用可能なホスト数を求める方法を理解したことで、普段の業務でよく目にするIPアドレスの許可範囲がどのように決められているのかをイメージできるようになった 難易度の高い設計や実装に取り組む際に、知らない概念が多いことに気付かされ、さらなる基礎力強化の必要性を感じるようになった 例）難易度が上がるほどAIも複数のパターンから人間に判断を求めてくることが多く、その中から根拠を持って「このパターンが良い」と答えるには、さらにベースとなる知識のストックを増やしていく必要があると感じた AIといくらでも壁打ちできる環境にいるからこそ、自分の中にある前提の基礎知識をもとにどの出力を採用するべきかを判断する力は、重要であると実感しました。 ジュニアエンジニアの成長を支えてくれる会社のカルチャー ファインディには、歴の浅いエンジニアの成長を支えてくれる仕組みと雰囲気があります。具体的には次のようなものです。 定期的な1on1や勉強会を通じて、自分の中の不明点を整理できる 各々の関心に合わせ、シニアエンジニアの方が勉強会を開いてくれる場面が多くあります。内容は基本情報技術者試験に向けた勉強会やアルゴリズムの解説など様々です。 また、社内全体で1on1が活発に行われており、話を聞いてみたい人に1on1を依頼すると、快く引き受けてくれる雰囲気があります。 技術的な内容は他のエンジニアに、ビジネスサイドの知見が足りていないと感じるときは営業の方に質問するなど、部署を超えた連携が活発に行われています。 そのような環境のおかげで、社歴やエンジニア歴が浅かったとしても心理的ハードルを感じずに他の人から知見を集めることができます。 結果として、技術的知見・ビジネス的知見双方への関心が強くなり、さらに理解を深めていきたいという意欲につながっていると感じています。 基礎力強化を応援する文化 AIがコードを出力してくれる時代だからこそ、ベースとなるコンピューターサイエンスの基礎知識が必要、という考え方を、普段の業務で活躍しているシニアエンジニアの方を中心に浸透させてくれています。 そのため、基本情報技術者試験の合格に向けて勉強しているエンジニアやコンピューターサイエンスの知識を学習するエンジニアを応援し、資格試験に合格したら労ってくれる雰囲気があります。 また、資格試験合格のためにナレッジを共有したり、受験や学習を通して学んだことを社内アウトプットとして共有する人も多いです。自分はそのおかげで良い刺激を受け、学習を続けるモチベーションになりました。 こうした雰囲気は、ファインディのバリューの1つである「前向き」が組織に浸透していることの表れだと感じています。 まとめ 今回は、エンジニア2年目の自分の、次のような思考の変化に触れました。 ビジネスサイドとの連携が増える中で、事業部へ貢献したいという気持ちが強まる AIを活用して設計・実装を進める中で、AIの出力やIssueを理解するための基礎力が不足していると実感 社内勉強会や個人学習を通じて基本情報技術者試験に合格し、コンピューターサイエンスの基礎的な理解を深める そういった基礎理解が、実務にも生きるようになった AIがコーディング業務を担う時代に、どのような力を伸ばせば良いか迷っていました。そんな時にコンピューターサイエンスの基礎の重要性を教えていただいたシニアエンジニアの方々と、学習を前向きに応援してくれた会社のカルチャーのおかげで、このような思考の変化が起きたと思っています。 今回は基本情報技術者試験合格に向けた学習をメインで行っていましたが、現在は基本情報技術者試験の問題の中で難しいと感じた分野・苦手だと感じた分野に関して個別の技術書を読んで理解を深めています。 今後も各分野の基礎理解を深めて日々の設計・実装に活かし、事業に貢献できるエンジニアを目指していきたいと思っています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは！ KINTO開発部 KINTOシステム開発G マスターメンテナンスツール開発チーム、技術広報部兼務、Osaka Tech Lab 所属の high-g（ @high_g_engineer ）です。フロントエンドエンジニアをやっています。 以前、社内で開催しているフロントエンド勉強会について紹介しました。 https://blog.kinto-technologies.com/posts/2025-06-30-frontend-study-group/ あれから勉強会は続き、2026年10月で第91回を迎えました。 今回はその中で、2026年8月〜9月に全5回で実施した 『HTML解体新書』の輪読会 について紹介します。 正直なところ、書籍の輪読会はフロントエンド勉強会では前例がなく、とりわけ、分厚い技術書の輪読会となると、「途中で失速しがち」「ただ読み上げるだけの会になりがち」という印象があり、少しハードルを高く感じていました。 実際、私自身も前職で同じ本の輪読会を経験したとき、内容を理解しないまま読み進めるだけの会になってしまった苦い思い出があります。 ですが、今回は最後まで走り切れたうえに、参加者全員が前のめりに議論する場になりました。 この記事では、その経緯と進め方、うまくいった理由などをまとめます。 題材にした書籍 https://www.borndigital.co.jp/book/25999/ 『HTML解体新書 ―仕様から紐解く本格入門』は、HTMLの仕様（HTML Standard）をベースに、各要素の意味や使い方、アクセシビリティとの関係を丁寧に解説した書籍です。 なぜHTMLの輪読会をすることになったのか 「次に何をやるか」をみんなで話し合った 輪読会を始める直前、勉強会ではTSKaigi 2026のセッション動画をみんなで視聴していました。ただ、最近のフロントエンド勉強会はTypeScriptの型の話に寄りがちな内容になっていて、動画を見るだけの会が続いていたこともあり、「もう少し現場に寄り添った勉強会にしたい」と考えていました。 そこで7月に2回ほど時間を取り、参加者が所属する各チームで実際に起きているフロントエンドの課題をヒアリングしました。 すると、チームは違っても次のような悩みが共通して挙がりました。 デザイナーとの協業の進め方に課題がある UI / UXに関する知識をもっと伸ばしたい アクセシビリティを最終的にコードへどう落とし込むか、どう周囲を巻き込むか キーワードは「情報設計」 議論を重ねるうちに見えてきたのが、「 情報設計 」というキーワードでした。 勉強会で立てた仮説はこうです。 正しく情報設計されているUI ≒ 正しくマークアップされている ≒ Webアクセシビリティを満たしている デザイナーと協業するうえでも、アクセシビリティを満たしたコンテンツを作るうえでも、土台になるのはHTMLの正しい理解です。 「HTMLの知識を強化することが、情報設計の理解につながり、ひいてはフロントエンドの全チームに共通する課題の解決につながるかもしれない」と考え、まずは h1 〜 h6 を正しい順序で使うという基礎的なレベルから理解し直そう、という結論になりました。その教材としてうってつけだったのが『HTML解体新書』です。 いきなり始めず「本を紹介する会」を挟んだ とはいえ、この本は全352ページというなかなかの厚さです。いきなり「来週から輪読会をやります」と言うと、参加のハードルが一気に上がってしまいます。 一方で「みんなの準備が整ったらやろう」では、いつまでも始まらない可能性が高いです。 そこで、まずは すでに本を持っている人に持参してもらい、どんな本なのかを紹介する会 を一度挟みました。 この会で中身をパラパラと眺めたことで「とりあえず買って一読してみます」「今Kindleで買いました」という声が出て、その場で進め方のルールも決めることができました。 また、マネージャーの承認をもらい、東京（室町）と大阪のオフィスに1冊ずつ会社で書籍を購入できました。 ただ、ふたを開けてみると多くの参加者が自分で購入していて、「会社で買わなくても、みんな持っていたかもしれない」というくらいでした。 輪読会の進め方 ルール ルールはシンプルにしました。 参加者はできる限り事前に読んでくる（ もちろん、読めなくても大丈夫 ） 説明担当は担当箇所を事前に精読し、当日に説明する（ 説明方法はおまかせ ） 書籍は会社購入分を貸し出し可（個人での用意もOK） 「読めなくても大丈夫」と明言しておくことで、担当以外の人も気軽に参加できるようにしています。 1回（約1時間）のタイムテーブル 時間 内容 10〜30分 担当者が担当箇所をざっくり説明 20〜30分 全員で感想や気になったことを話す 3分 次回の担当決めルーレット 次回の担当は、Claude Artifactsで作ったルーレットで決めました。ちょっとしたゲーム感覚があり、「誰になるかな」と盛り上がるポイントでもありました。 範囲は「主要な節だけ」に絞った 全章を読むと長期戦になってしまうため、CHAPTER 3の要素解説から、特に業務に関わりが深い5つの節に絞りました。 回 開催日 範囲 担当 第1回 8/7 セクション 花輪さん 第2回 8/28 グルーピングコンテンツ 三上さん 第3回 9/4 テキストレベルセマンティクス 齋藤さん 第4回 9/11 フォーム その1 high-g 第5回 9/18 フォーム その2 溝口さん お盆や私の休暇で何度かスキップを挟みましたが、当初の見込みどおり5回で完走できました。 アクセシビリティの有識者が参加してくれた 今回の輪読会で大きかったのが、社内のアクセシビリティの有識者である 辻さん 、 守谷さん が参加してくれたことです。 本に書かれている内容に対して「実際のスクリーンリーダーではこう読み上げられる」「昔はこう使われていた」といった、 本の一歩先の知見 をその場で補足してもらえたことで、議論の質が大きく上がりました。 各回の様子 各回とも、担当者が本の内容をなぞるだけでなく、独自の切り口でテキストベースのまとめを作ってきてくれました。ここでは各回で印象に残ったトピックをいくつか紹介します。 第1回：セクション section / article / aside / nav といったセクショニングコンテンツや、 header / footer がランドマークになる条件などを扱いました。 印象的だったのは、書籍の刊行と同じ2022年に アウトラインアルゴリズムがHTML Standardから削除されている ことです。 https://github.com/whatwg/html/pull/7829 現在は、 section で囲んでも見出しレベルは上がらず、 h1 〜 h6 の数字で決まります。 また、「Reactアプリケーションでは、最終的にレンダリングされたHTML全体を目にする機会がほとんどありません。セクション構造が正しいことを日々の開発でどう検証すればよいか？」という、コンポーネント開発ならではの悩みも話題になりました。 第2回：グルーピングコンテンツ p 、 ul 、 ol 、 dl 、 figure 、 main など「毎日書いている要素」がテーマでしたが、担当の三上さんは意味の深い説明よりも、個人的に「そうなんだ」と感じた部分を中心にまとめてくれました。 たとえば、 p の中に ul を書くとエラーにはならず、パーサーが黙って p を閉じてしまいます。 <!-- 書いたつもりのHTML --> <p> <ul> <li>項目</li> </ul> </p> <!-- パース後のDOM --> <p></p> <ul> <li>項目</li> </ul> <p></p> その結果、 p > ul を前提にしたCSSが効かなくなったり、末尾に生える空の p で余白が増えたりします。SSR環境ではサーバーで生成したHTMLとクライアントのDOMが食い違い、hydrationエラーの原因にもなります。 ほかにも、次のような話題で盛り上がりました。 ol の番号はDOMに存在しないため、コピー＆ペーストすると消える main は hidden 属性を付けたものを含めれば、1ページに複数置ける hr は「線」ではなく、段落レベルのテーマの区切り。スクリーンリーダーでは「区切り」と読み上げられる dl の読み上げはブラウザとスクリーンリーダーの組み合わせによって差があるが、セマンティクスとして正しいなら使う価値がある この回で特に印象に残ったのが、「セマンティクス＝スクリーンリーダーのため」というチャットの発言に対する、辻さんのひと言です。 「スクリーンリーダーのため」ってのはたぶんちょっと違うな。スクリーンリーダーはHTMLの仕様に合わせて解釈する側なので。 スクリーンリーダーで思いどおりに読ませるためにコンテンツを曲げるのではなく、仕様に沿って正しくマークアップし、スクリーンリーダー側がそれを正しく解釈する。アクセシビリティを考えるうえでの順序を、改めて確認できました。 第3回：テキストレベルセマンティクス em と strong 、 small 、 s 、 time 、 ruby 、 bdi 、 br 、 wbr などを扱いました。 担当の齋藤さんからは「普段はフレームワーク上でコンポーネント単位でしかHTMLを書かないので、要素そのものを意識したことがなかった」という率直な感想があり、まさにこの輪読会の狙いどおりの気づきが共有されました。 書籍の刊行後に仕様側で変わった点も話題になりました。たとえば、書籍の時点では対応するARIAロールがなかった要素にも、WAI-ARIA 1.2ではロールが割り当てられています。 HTML要素 WAI-ARIA 1.2でのロール em emphasis strong strong del / ins deletion / insertion sub / sup subscript / superscript b / i / small / s / u generic ほかにも、 <p>H<sub>2</sub>O</p> をVoiceOverで読ませると「エイチ・ツー・オー」ではなく「エイチニオー」と読まれた、日本語にはイタリック体の文化がないので i 要素はマークアップと見た目が一致しにくい、といった実際に試してみたからこその話も出ました。 チャットでは、昔使っていたHTMLエディタの話や、ガラケーでHTMLを書いていた思い出話で世代を超えて盛り上がる一幕もありました。 第4回：フォーム その1 私の担当回です。 form 、 label 、各種 input の type 、バリデーション属性、 autocomplete などを扱いました。 特に強調したのは、 label の for 属性の落とし穴です。存在しない id を指定するとHTMLチェッカーでエラーとして検出できますが、 別の要素の id を指定してしまった場合はHTMLチェッカーでは検出できません。 ラベルをコピー＆ペーストして for を直し忘れると、コピーしたラベルまで最初の入力欄に紐づいてしまう、といった事故が起こり得ます。 これは目で見ても気づきにくい一方、スクリーンリーダーで読み上げるとすぐに分かる、という話が辻さんからありました。 そのほかにも、次のような話題が出ました。 type="hidden" は「秘密」にはならない（値は改ざんできる） pattern 属性はセキュリティのためのものではない placeholder はラベルの代わりにならない 電話番号を「ハイフンなし」と注釈して type="number" で受け取るのは避けたい KINTOのサービスには申込フォームが多いので、そのまま業務に生かせる内容だったと思います。 第5回：フォーム その2 最終回は溝口さんの担当で、 button 、 select 、 datalist 、 progress / meter 、 fieldset / legend などを扱いました。 溝口さんの切り口がとても面白く、「今はゼロからフォーム部品を手書きすることは少なく、UIライブラリを使うことがほとんど」という前提に立って、 MUI・Ant Design・Radix UIがそれぞれの要素をどう実装しているか を、書籍の内容と突き合わせてくれました。 たとえばスイッチ（Switch）コンポーネントひとつとっても、実装方針はライブラリごとに異なります。 ライブラリ Switchの実装 MUI 見た目用の span と、透明な <input type="checkbox" role="switch"> Ant Design input を使わず <button type="button" role="switch" aria-checked> Radix UI <button role="switch" aria-checked> に加え、フォーム内でのみ非表示の input を追加 select も同様で、ネイティブの select を使わずに role="combobox" と role="listbox" を組み合わせて再現していたり、フォーム互換のために見えない select を置いていたりと、各ライブラリの工夫が見えてきました。 「アクセシブルな複数選択UIを自前で実装するのはかなり大変なので、ライブラリを使うのがおすすめ」という結論にも説得力がありました。 また、スイッチは「押した瞬間に反映されるもの」なので、「保存」ボタンと組み合わせたり、月額／年額のような二択に使ったりするのは本来の用途とずれる、というSwitchとトグルボタンの使い分けの話も盛り上がりました。 ふりかえり 全5回を終えたあと、勉強会の1回分を使ってふりかえりを行いました。 フレームワークには、KPTではなく Fun / Done / Learn を採用しています。KPTだと特に問題がなくてもProblemを挙げる必要があり、ネガティブな空気になりやすいと考えたためです。 Fun：楽しかったこと 輪読会は負荷の高いフォーマットなのに、担当者が理解したことを積極的にシェアしてくれた ただ読んでくるだけでなく、担当者が独自の解釈を織り交ぜて、より高度な内容に仕上げてくれた（UIライブラリの対応状況など） 発表者ごとに本のどこに着目しているかが資料に表れていて、他の人がどう技術書を読んでいるのかを知ることができた 有識者のアクセシビリティの知見を踏まえて本を読み進める体験ができた 発表後のディスカッションで、全員が前のめりに建設的な意見を出す場になった 辻さんからは、こんなコメントももらいました。 昔のWeb制作者は、HTML解体新書に書いてあるくらいのことは普段使いしていた。今の時代は、そうした知識がなくてもプロダクトが作れてしまう。だからこそ、この輪読会を通してみなさんが知ろうとしてくれていることがうれしかった。 さらに、「世の中の登壇には、画面を見ていないと置いていかれるものが意外と多いけれど、今回のみなさんの発表は、画面を見ていなくても話として理解できた」という、うれしい言葉もいただきました。辻さんがこの点について書いた記事も紹介されていたので、発表をする方にはぜひ読んでほしいです。 https://note.com/debugon/n/nae7f164bf8a7 Done：やり遂げたこと フロントエンド勉強会で書籍を輪読するスタイルは初めてだったが、無事に完走できた 社内に『HTML解体新書』の存在を広められた 複数回にわたって1冊の技術書を読む、というスタイルを勉強会として1つ確立できた 一人で読むのがつらい本でも、勉強会に持ち込んでみんなで読む、という選択肢ができたのは大きな収穫です。 Learn：学んだこと HTMLの現行仕様は常に更新され続けるHTML Standardなので、書籍の内容はすでに古くなっている部分もある。だからこそ 書籍は取っかかりとして使い、怪しいと思ったら仕様を引く セクショニングコンテンツ、グルーピングコンテンツ、テキストレベルセマンティクスといったHTMLの原点を改めて思い出せた a 要素の内容モデルはTransparent（透過的）で、親がフローコンテンツなら a の中に div などを置くこともできる セマンティックなHTMLを書けばアクセシビリティを網羅できるわけではない。 結局、見出しやラベルを適切に付けることが、アクセシビリティ的に一番重要 見た目に頼っていたマークアップを、要素の意味から考え直すきっかけになった 担当になった人は誰も発表を避けず、1週間で1時間分の議論ができる資料を作ってきてくれた。 1回あたりの適切なボリューム感 もつかめた うまくいった理由をふりかえってみる ふりかえりの内容も踏まえて、今回の輪読会がうまくいった理由を整理すると、次の4つだと思います。 現場の課題から題材を選んだ 「なんとなく良さそうな本」ではなく、各チームへのヒアリングで見えた共通課題（情報設計・アクセシビリティ）から逆算して本を選びました。そのため、参加者にとって「自分ごと」になりやすかったのだと思います。 始めるハードルを徹底的に下げた 紹介する会を挟む、「読めなくても大丈夫」と明言する、範囲を主要な節に絞る、書籍を会社で用意する、といった工夫で、参加の心理的なハードルを下げました。 説明方法を担当者に任せた 本の内容をなぞるのではなく、「そうなんだ」と感じた点に絞る、UIライブラリと突き合わせる、など担当者ごとの切り口が生まれ、毎回違った面白さがありました。 有識者が一緒に読んでくれた 書籍の内容を、現在の仕様や実際のスクリーンリーダーの挙動と照らし合わせて補足してもらえたことで、「読むだけの会」から「理解して議論する会」になりました。 おわりに 今回の輪読会を通して、HTMLの知識そのものはもちろん、「勉強会で1冊の本を読み切る」という新しい型を手に入れることができました。 ふりかえりでは、次の題材としてReactの公式ドキュメントのような無料で読めるリファレンスを読むのも良さそう、という声や、書籍の内容を起点に、現在のHTMLの仕様やAI時代のマークアップについてさらに議論を深める場をつくれないか、というアイデアも出ています。 少人数のふりかえりではありましたが、この輪読会を乗り越えたことで、新しいことができそうな可能性を感じています。 社内で輪読会を企画しようとしている方の参考になればうれしいです。

こんにちは。株式会社タイミーのバックエンドエンジニアの神山( @dak2 )です。 2026/9/19 に名古屋の大須演芸場で開催された名古屋 Ruby 会議05 に登壇してきました。 タイミーでは、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、そちらを活用して現地でカンファレンスに参加してきました。 今回は『特殊変数大全』というテーマで登壇しました。印象に残ったセッションや、当日の様子を紹介します。 Road to 名古屋 Ruby 会議05 会場の大須演芸場は、大須観音や大須商店街のある賑やかな大須界隈に位置する、1965年開館の寄席です。 www.osuengei.nagoya そんな場所で喋れる機会があったら、もちろん気になるじゃないですか？ しかも今回は出囃子を生演奏してくれるとのことで、これは絶対に壇上で喋りたいやつじゃん…！となるわけです。また、せっかくなので落語の着物を着たいと思ってました。 ということで、勢いよくプロポーザルを出しました。あと、このプロポーザルは自信がありました。 Accepted された時は嬉しかったですね。 2026/9/19(土) が開催日でしたが、前日入りで名古屋に訪れました。 ホテル代が高騰してた（アジア競技大会）のでカプセルホテルに泊まったんですが、かなり居心地良かったですよ。ウェルビー栄というサウナの聖地なんですがね。最高でした。 うなぎ食べたり、名古屋城行ったりしつつ、なぜか名古屋城のほとりに金シャチ横丁という食べ歩きができる施設があるんですが、そこでスライドを直してましたね。まさかお城の周辺でスライド直すとは思ってなかった。 自分のセッション 落語の寄席は流れがあって、前半 → 仲トリ → 仲入り → 食いつき → ヒザ → トリ とざっくりこういう流れで進んでいきます。 仲入りは、寄席の途中に設けられる休憩です。今回、自分は昼休憩直前の『仲入り前』の枠で登壇しました。 speakerdeck.com 本当にたまたま Ruby のリファレンスで特殊変数を読んでいて、Ruby::Box を有効にすると $_ はどう動くんだろう？と試したら、古い値が返るバグを見つけたところから探索が始まりました。 特殊変数、本当に奥深いんですよね、一枚岩じゃないんですよ。同じ $ でもプロセスやスレッド、ブロックごとに違ったりとか。それを注意深く追ってると、Box と Ractor で扱いが交差してくるしで一筋縄ではいかない。 スライドの内容を考えるにあたって、Ruby の処理系を真面目に追うことになりました。 皆さんも特殊変数追ってみてください（根気は必要そうです） スライドは少しでも落語調にしたくて UI を調整しました。スライド右の方にはめくりを表す白の余白、スライド下部には緋毛氈を表す装飾を施しました。フォントは寄せ文字の有料フォントです。このためにフォントを初めて買いました。（会場のコントラストの関係で、黒赤だと見づらかったようです） 演奏していただいた出囃子の楽曲は、たぬきという曲でした。化けるたぬきということで、$ の形をしながらもいろんな場所で姿を変える特殊変数を表したいというコンセプトでした。 これは撮影してもらった登壇時の写真です。初めて落語の着物を着ました。せっかくの機会なので自費でレンタルしました。めちゃくちゃ暑かったけど、こんな機会は滅多にないので着れてよかったです。 Special thanks to @tonyfactory210 他の方のセッション 片月亭 黒曜さんの型の話 「型 再考」、お聞きいただきありがとうございました！ こちら発表資料です！(一応Claudeで可能な限り裏取りしましたが、なにか間違った記述あったらすみません) https://t.co/QGlKiZGnra #nagoyark05 — 黒曜@Leaner Technologies (@kokuyouwind) 2026年9月19日 やはり、漸進的型付けはそれ自体が難しいという感想を抱いた。型付け自体の有用性は認めつつ、型付けで表現するということは、その表現可能な集合に文法が規定されるんだなという感想を持ちました。Ruby のように言語自体の表現力が非常に高い言語だとそりゃ難しいよなあと。untyped とかそもそも型検査を skip するようなハッチが生まれがち。それを直す契機は大体バグが起きた時なのもまた難しいポイントですね。 盆暗亭 しおいさんの Socket.getifaddrs の話 名古屋Ruby会議05にてお話しした『時うどん〜Socket.getifaddrsで学ぶネットワーク編』の発表スライドです。出囃子は『ふるさと』でした。お付き合いいただきましてありがとうございました! https://t.co/A5sjIqClTD #nagoyark05 — Misaki Shioi (しおい) (@coe401_) 2026年9月20日 上方落語の時うどんをアレンジしていてこだわりを感じました。うどん1杯を食べるために1文足りない主人公がいま何刻かを店主に言わせて、そこから数えて1文をちょろまかす話ですが、それがネットワークインターフェースになっており、近代化を感じました（？） ネットワークインターフェースの数の数え方は勉強になりました。 Socket オブジェクトを触ってみましたが、 UDPSocket などあって探索しがいがあり面白そう。追ってみたいなと思いました。 kamipo さんの基調講演 名古屋Ruby会議05の登壇資料です #nagoyark05 https://t.co/8akp5Xk9y5 — Ryuta Kamizono (@kamipo) 2026年9月22日 Rails の JOIN とどう向き合ってきたかというお話しでした。 joins、元々種類ごとに並び替えられてたんですね。left_joins 最後だったと。string joins の位置、join alias で where を先に書かないといけない問題の対応とか。 where.missing と where.associated 周りの話は興味深かったです。関連の有無を判定するSQLについて、JOINを使う方法と、NOT EXISTS / EXISTSを使う方法の違いが印象に残りました。着実な最適化がされてきたんだなと ActiveRecord の進化の歴史の一部を感じられました。 LATERAL JOIN 知らなかったので勉強になりました。サブクエリを行単位で適用できるのか。 観光など 台湾料理 矢場味仙 で台湾ラーメン食べたんですが、美味しかった！ただ、非常に辛かったです…! 愛知県長久手市にある Totopia Brewery というクラフトブルワリーにお邪魔しました。Hazy IPA のラインナップを推していて非常に香り高い一杯を提供してくれます。ずっと行きたかったので行けて最高でした！ Noxphobia - TDH Hazy Double IPA 終わりに 名古屋Ruby会議05に参加してよかったです。滅多にできないことをやれましたし、何より勉強になるセッションが多く、気づきを得られました。 改めてですが、タイミーでは、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。こちらご興味をお持ちいただけましたら、ぜひカジュアル面談にお申し込みください！ product-recruit.timee.co.jp カジュアル面談のお申し込みはこちら