2025/07/27【オフライン】Kyoto.rb Meetup テーマレス回
初参加の人は↓から編集権限をゲットしてください
Cosense の記法
イベントページ (connpass)
今日のルール
最初に質問するやつはえらい。馬鹿な質問をするやつはえらい。関係ない質問をするやつはえらい。
発表中でも気になること、わからないことがあればCosense（旧Scrapbox）に質問を書こう！
宣伝したいこと
コミュニティでも個人でも会社でもなんでもOK。
luccafort.iconGo Conference 2025も9月27~28日に渋谷でやるよ〜
sanfrecce_osaka.icon まだページはないけど ながらRuby会議 は 2025/9/6(土) になったYO
testingOsaka 9/12(金) 19:00~梅田
スクラム祭り プロポーザル 8/7まで 開催10/3-4
前回のTRY
luccafort.iconイベント冒頭で休憩は自由に取ってよいと伝える
次回OST開催するときに各テーブルに1台ディスプレイを配置する（使っても使わなくてもいい）
次回もOST（アンカンファレンス）形式で開催する
Meet とかなら Gemini パワーでまとめが作られる
自己紹介
code:text
名前(ハンドルネーム or 本名)
SNS(GitHubやX、mixi2など）
好きな寺社仏閣 or 近所の寺社仏閣（任意）
普段やっていること（仕事や学業など）
今日聞いてみたいこと・気になってること
SNS： github.icon @luccafort / Twitter.icon @luccafort
普段やっていること：マネーフォワードでプロジェクトマネージャーをしている。英語でのやり取りが死ぬほど大変。
今日聞いてみたいこと・気になってること：Ruby/RailsでVibe Codingしてる人の作業風景がみてみたい（うまく使えてないので真似したい）
やまずんymzn.icon
SNS:X@55_ymzn
好きな寺社仏閣：桃山天満宮(３年くらい伏見桃山に住んでいた)
普段やっていること：人事系SaaSのQAエンジニア （バックエンドはPHP・フロントエンドはTypescript）
Ruby歴:16時間くらい
最近読んだ本：ソフトウェアテスト徹底指南書
最近気になってる本：論理的思考の文化的基盤
今日聞いてみたいこと・気になること：rubyコミュニティが面白そうだったのできた/テストや品質についてなんか質問ある？
なまえ：matsuday.iconmatuday(マツダイ)
好きな神社仏閣：近くには大川神社
普段やっていること：舞鶴という僻地でポリテクで指導員してます。企業さんからの依頼でIoTサービス開発もしてます。
Ruby歴：15年ぐらい
最近Playwrightをはじめました。
名前：shonoshono(佐伯 奨乃)
好きな寺社仏閣：法多山尊永寺(静岡県袋井市）：学生時代、浜松に住んでました
普段やっていること：組込みソフトウェア開発、最近は開発周りの効率化を独自でやってる(C++)
Ruby歴：数ヶ月
最近読んだ本：ふつうのLINUXプログラミング、オブジェクト指向設計実践ガイド (Ruby)
気になっていること：広く浅く色々(テスト興味ある！！！)
名前：しもむ〜 (simomu, ashimomura)
SNS：X simomutter / GitHub ashimomura
近所の神社仏閣：近江神宮
普段やっていること：toB SaaS のバックエンドエンジニア
Ruby 歴：6年ぐらい
最近読んだ本：型システムのしくみ
今日聞いてみたいこと・気になること：地域 rb 初参加なので雰囲気を知りたい
オオクボ（ドデカミン）
SNS：twitter.icon @def_dodekamin
事業会社でECのバックオフィスを触ってます
Ruby歴は3年くらい
今日聞いてみたいこと: テスト・品質について
イトウ
SNSは特にしていません
南禅寺
事業会社でユニットリーダーをしています。LINEを利用した事業をいています。滋賀県大津市に住んで
Ruby 歴は4年くらい
最近読んだ本:Gitlab ハンドブック
気になっている本: 進化的アーキテクチャ。ネットワークの基礎系の本
今日きいてみたいこと: 地域rb の雰囲気
名前：もーりー（もりした）
Github：ko52
好きな寺社仏閣：春日大社
普段やっていること：自社開発や業務系など色々
読んでる本：プロになるためのweb技術入門
Ruby/Rails歴：1年ぐらい
今日聞いてみたいこと・気になっていること
初参加なので、色んな方の話を聞いてみたい
CelloTAK.icon cellotak(せろたく)
好きな寺社仏閣 or 近所の寺社仏閣（任意）
東寺 (たまたま寄ったら陶彩画展を無料でやっていて面白かった) 普段やっていること
BPS株式会社で(TechRacho書いている会社)Railsの受託開発。
Ruby歴は2年半くらい
最近読んだ本
今日聞いてみたいこと・気になってること
仕事の速度の上げ方
しがあきとし.iconしがあきとし
好きな寺社仏閣 or 近所の寺社仏閣（任意）
最近大阪天満宮のお祭り（天神祭）に行きました
普段やっていること（仕事や学業など）
Ruby歴は3年くらい
スキマバイトの事業会社でRailsやってます
参加できてない間に職を得ました
CelloTAK.icon:+1:
読んでる本
参加してない間にDBの本をたくさん読みました
今読んでる本は「誰のためのデザイン?」
今日聞いてみたいこと・気になってること
Railsの高速化
久々に参加できてうれしい！！！
sanfrecce_osaka.icon 森塚@sanfrecce_osaka
注: サンフレッチェ広島のサポーターではないです
好きな寺社仏閣 or 近所の寺社仏閣（任意）
最寄り
有名(？)
普段やっていること
株式会社Leaner Technologies
Ruby/Rails/React/TypeScript
4月から入社
この間 20〜30 カラムの integer のカラムを decimal に大きな障害なく変え切りました(〆切がパツパツで疲れた)
CI の実行時間が一時的に2〜4倍？になった :innocent:
Ruby歴
学習開始: パーフェクト Ruby (2.4)が出ているくらいから(2016くらい〜)
仕事: 6年目(2019〜)
最近読んだ本・最近気になっている本
Bliki
本じゃないけど
LR parser入門
Web API開発実践ガイド ――REST/gRPC/GraphQLからテスト、セキュリティまで
フルスタックテスティング 10のテスト手法で実践する高品質ソフトウェア開発
今日聞いてみたいこと・気になること
テストコードのテストデータでランダム値を使うのか・使わないのか・いつ使うのか
ymzn.icon火種になった人は私と同じチームやわ
Evil Martians 製の OSS を眺める(Gem を読むの Evil Martians 限定)
OpenAPI 3.1
コミットメッセージきちんと書いてる？
uproad3.icon すぎうり
SNS
すきな寺社仏閣
京橋に住んでるけど天神祭は家でテレビで見てました
窓を開けているとリアル花火の音を聞いてからテレビの花火が見れるので2倍お得
伏見稲荷
山の神社が好き
最近は暑くて奥の院までしか行けてない
鞍馬寺
関西Ruby会議08の翌日の叡電LTを追いかけるついでに行った
山of山で最高の自然を感じられる
宇宙を感じれるらしい
暑さは感じた
京都市内よりはかなり涼しかった(29℃)
普段やってること
株式会社ドワンゴ
ニコニ立体・ニコニコQ、イベントランキング・NicoFT・（未リリースサービス１つ）
RailsとAWSのメイン担当
10年もののサービスの負債解消を頑張っている
Ruby歴
高校生の頃、2006年に「たのしいRuby」を読んでからずっと使ってる
もう19年ってマ？
当時はRuby 1.8と1.9で仕様が変わりすぎてヤバいみたいな話があった
onk.icon たのしいRubyめちゃくちゃオススメなんだけど、在庫無いらしくて笹田さんの本屋さんに入荷されない
仕事では2015年からRailsを触っている
最近読んだ本・最近気になっている本
ゼロからのOS自作入門
今日聞いてみたいこと・気になること
Kaigi on RailsのCFP採択基準の記事
闇のAIコードに対する防衛術
スネイプ先生！
PicoRuby話せる人がいたら
onk.icon onk
名前(ハンドルネーム or 本名)
好きな寺社仏閣 or 近所の寺社仏閣（任意）
今さっき八坂神社で鷺舞を見てきた
https://gyazo.com/da8f2e310ffc8d9395b8f9430fe36950
普段やっていること（仕事や学業など）
株式会社はてな Mackerel 開発チーム
Ruby歴（Rubyやってない場合はソフトウェアエンジニア歴とか）
Ruby 歴 18 年ぐらい
今日聞いてみたいこと
せっかくなので QA 周りかなぁ
ワイガヤ欄
luccafort.iconわいわい
sanfrecce_osaka.icon がやがや
しがあきとし.iconいつかみんなでふる里行ってみたいです ymzn.iconシスコのパクリ製品のテストを３年くらいやってたよ！低レイヤーのネットワークならそこそこ詳しいです
おすすめガジェット
HHKB
Open Meet
session1
テストにランダム値を使うべきか？使わないべきか？
luccafort.iconケースバイケースかなぁ。テストの意図として明確にこの値は正常、この値は異常として判断したいなぁランダムを使うべきではないけど、例えばFizzingみたいなランダムな値をぶっこんだ結果見つけるみたいなのはあるからな。
onk.icon これは会話した結果着地した
結論としては「事前データとして意味のあるデータを設計しろ」
テストの事前データで以下は普通にやるよね
code:ruby
factory :user do
name { Faker::Name.name }
is_admin { Faker::Boolean.boolean }
end
create(:user)
code:ruby
admin_user = create(:user, is_admin: true)
何も考えずにすべてを random にして flaky なテストがある、という異常事態が問題だと言いたかった、らしい
sanfrecce_osaka.icon もともとのペインはランダム値に依存した期待値をテストに書いてしまっていたことによるものな気がする
しがあきとし.iconランダム値を指定することで意図を表現するってことですね
onk.icon faker が無かったとして、not null カラムがあると
code:ruby
# factories/users.rb
factory :user do
end
# foo_spec.rb
user1 = create(:user, name: "Taro", is_admin: true)
user2 = create(:user, name: "Jiro", is_admin: false)
とか適当に埋めると思うけど、この name やら is_admin やらにテストの事前条件としての意味があるかというと基本的には無いはず？
意味が無いものが目立ってしまうのがおかしい
しがあきとし.iconありがとうございます！意味のあるデータを目立たせるためにそれ以外に使うって感じですね
ちなみに↓のようなケースはどうする？
code:ruby
# factories/cart.rb
factory :cart do
unit_price { Faker.number }
size { Faker.number }
total { Faker.number }
# total { unit_price * size }
end
onk.icon 内部的に Cart という PORO があって、外から unit_price や size, total も外から入れる設計ってコトだよね
ロジックを Cart に入れて属性じゃなくしたら、な気がする
属性なんだとしても factory で計算できそう
ランダムな値を使うテストの例（プロパティベースドテスト）
CelloTAK.icon テストこそレビューをしっかりすべき？
ymzn.iconそれはあるけど、しっかりなレビューが不必要なくらいシンプルなテストコードを書くのがいいと思います。
なるほど！
しがあきとし.iconテストコードのレビュー辛い
(釈迦に説法かもしれないけど)いとうじゅんいちさんというRubyistの人がいいテストコードとは？って話をしていて、私はこの人の意見に賛同しています。
ymzn.iconそうそれ！
onk.icon 「値は何でもいい」を表現するのが Faker で、Faker で困る (Flaky になる) としたら、何でもよくはなかった、が分かったので改善しましょう、になりそう
onk.icon .oO(Datadog でどう flaky 検出しているんだろう)
onk.icon 便利〜
自動でリトライということで↓と考え方は同じだった
テストフレームワークの思想について
前提
業務でC++の単体テストコードを作ろうとしたことによる疑問
GDBのPythonAPIによってテストできそうだったのでそれをベースにテストフレームワーク作ろうとした。
テストが無いところだとテストを書きづらいコードになっている
テストを書きづらい＝内部状態の変化しかなくて、観測しづらい
それでもテスト可能にするフレームワークはある
e.g. Ruby は異常にテストが書きやすい言語
テスタビリティという概念もあります
onk.icon 質とスピード の頭30ページぐらいがすごく好きです 質とはつまり保守性 (＝理解容易性、変更容易性、テスト容易性) である、と分解していくところ
uproad3.iconテストできるところからテストする
uproad3.icon例えば DB が絡んでいるなら、実行して、DB がどう変化したかをまずテストに書ける
ymzn.icon個人的な意見
テストはインプット→プロセス→アウトプットを定義して、アウトプットと期待結果を比較するという構造は変わらない気がする（プロパティベースドテストとかAIのいろいろは別）
思想による差分は以下くらいな気がする
テストレベル
テストケースの構造
めっちゃマニアックな話
「自動テスト」を構造化すると上記の汎用アーキテクチャになるらしい
テスト文化がない企業は何から始めるといいか
前提
テスト文化がないのでQAの解像度低いです
今までいただいた回答
個人でできるところから実施して効果を訴求していく
E2E
なぜテストをするのかをチームで共通認識を持つことから始めるべきだと思うが。。
ymzn.iconわたしはみんなに「品質について考えて」って言ってる
ymzn.icon「品質を保証する」とは、「これで俺たちは顧客に価値を届けられる」と自信を持っていることで、これがきちんとあるならテストはしなくていいです。
ymzn.iconそうじゃないならそこから考えることな気がする
ymzn.iconそして、品質保証は経営課題なので、そこに訴えないといけない、それが経営課題と思ってないなら会社があってない
ymzn.iconあと、開発者のテストと品質保証のテストという論点もある
ymzn.iconこれのどっちをしたいかでアプローチが変わる
onk.icon SLO から始めよう、が SRE 的なアプローチっぽい
ymzn.iconコードカバレッジ（おすすめしないけど）
(余談)いかに仲間を増やしていくかでよく出てくる動画
https://youtu.be/IdULdrNAlNs?si=DQou7Us3UZIDbxQ7
2人目3人目の一緒に踊ってくれる人をどうやってつくっていくか
損益分岐点のスライド
セキュリティで攻める
ymzn.icon事業一発アウトの問題は重視すべき品質特性なので、話や投資は通しやすいですね
品質保証を勉強するためのおすすめリソース
session2
コミットメッセージきちんと書いてる？
onk.icon リファラジ でもべた褒めでしたね ymzn.iconテスト考える時とかにコミットメッセージを見に行くことがあるし、それについて詰めることもある
onk.icon 経緯を調べたいけど何も残ってない！というという経験が先に必要
なので 3 年未満のプロダクトならまぁまぁ要らないんじゃないか
sanfrecce_osaka.icon issue のリンクが貼ってあってリポジトリごと消えていたときの悲しみと歴史を追うときの大変さ
PR の description で十分という話がよく出てくるけどリポジトリごと消えたら
CelloTAK.icon コミット粒度も個人的には〜ね重要と感じてます。 (作業中はいいけど最終的には掃除してほしい)
下記やりとりで考えを改めました。
onk.icon 「指摘対応」を許さないのは育成目的
指摘されたから直した、ではなく、納得して直して欲しい
納得して直していたらそういう「指摘対応」ではなく Why が書かれるはず
CelloTAK.icon 結局Whyが伝わることが重要なのかもと思いました。
それがPR descriptionだろうとコードコメントだろうとコミットメッセージだろうと
onk.icon コミット粒度は revert で苦しむんじゃないの
バグが起きたときに綺麗に rollback / revert することができない
PR 粒度で十分という話はある
onk.icon コミット粒度をゴチャゴチャ言っているとマジで生産性半分ぐらいになるからなぁ……
何も生まない、PR 粒度としても問題にならない程度なのに更にコミット粒度まで精査するのは求めすぎだろう
CelloTAK.icon 確かにコミットがぐちゃぐちゃで困ったときってPR自体が巨大で追いようがないことがほとんどなので、PR粒度が問題なのかも？です
ymzn.icon(プログラマーじゃなくてQAの勝手な意見として)リポジトリはプログラマーのものではなく、会社全体の資産だからコメントもそれにふさわしいものであったほうがよくない？とは思う
luccafort.iconコミットメッセージまでレビューするならありかなぁと思うけどその必要性を全員が納得できるかのほうが難しそうに思うなぁ。
いいよねluccafort.icon*5
レビューコメントで気をつけていること
流行ってたっぽいけど読めてない
CelloTAK.icon LGTMに画像使てくれると和む
sanfrecce_osaka.icon 最近 LGTMoon がホゲータの画像が大量にあげられてて荒らされていてつらい
luccafort.iconLTTM が好きでよく使ってる sanfrecce_osaka.icon GitHub の絵文字、Slack みたいにカスタム絵文字がほしくなるときがある(ネコチャン絵文字とか)
ymzn.iconエンジニアのレビューと違うかもしれないけど、たとえばバグを起票するときは事実だけを伝えるとかは意識してます
しがあきとし.icon最初に感謝を伝えるといいかも→「対応ありがとうございます！」「コメントありがとうございます！」
onk.icon 「絶対」「正しい」「べき」を避けるとかは気にしていたし、語尾に何の絵文字を貼るかでずっと悩んでいた時期は私もあります！！！！
luccafort.iconこれはちょっとわかるなぁ。
copilot が nits を出してくるのでチームに馴染んだ
枕詞
session3
Rails のパフォーマンス・チューニングや重くしないために気をつけること
sanfrecce_osaka.icon どこでクエリが発行されるかを把握する
sanfrecce_osaka.icon EXPLAIN
sanfrecce_osaka.icon むやみやたらに
luccafort.iconまずは計測したいなぁ。DBのどこが遅い、それは何故？を明らかにしたい。
uproad3.icon それな。まず計測せよ
pockeさんがRails.Cacheがうまく使えていないというのを見つけてくれたブログがあったはずだけど見失ってしまった
sanfrecce_osaka.icon 話に出た counter_culture 知らなかった
しがあきとし.iconカウンターキャッシュ
しがあきとし.icon非正規化を恐れない
しがあきとし.iconコントロールできる所で負荷の高い処理をする
しがあきとし.iconrack-mini-profiler
しがあきとし.icon読み込む行数を少なくする
しがあきとし.iconN+1の自動検出
strict loading
bullet
しがあきとし.icon#count_async
しがあきとし.icon#pluckは必ずSQL発行するのでN+1にならないように注意
しがあきとし.iconKaigi on Railsの過去の発表(2020~)
しがあきとし.iconRuby on Rails パフォーマンスアポクリファ
ymzn.icon(自分語り)私もPHPで性能改善のプロジェクトに関わってるけど、技術的なボトルネックはあんまりわからない
ymzn.iconけど、計測のやり方とかは考える
ymzn.icon計測のやり方が決まるとテストもしやすい
ymzn.icon神みたいな人がなんかいきなりやってきてクエリを変えると劇的に早くなるとかあったなあ
CelloTAK.icon そもそもビジネス要求とかを見直した方がいい場合もありそう？
CelloTAK.icon 整合性を犠牲にできるならできることも増えそう
ymzn.icon計算量の話も大事だけど、そもそも仕様変更も視野にってのは誰かが言ってた気がする
https://www.youtube.com/watch?v=Ua1qbpwDJd4
session4
KPT
Keep/Good
sanfrecce_osaka.icon 新規参加者がたくさんいた
めちゃくちゃいい話luccafort.icon*5
しがあきとし.icon CelloTAK.icon
大久保.icon滋賀出身なので滋賀から2人来られて嬉しい
ymzn.iconわいも滋賀出身な点
これは Shiga.rb の機運か！？
matsuday.iconShiga.rbは小浜経由で参加かも
しがあきとし.icon京都が関西の中心かも
他社のレビュー手段を知れてよかった。(いとう
しがあきとし.iconRubyを普段触らない人も来てくれた
ymzn.icon建設的に意見交換ができていた
大久保.iconプロのご意見ありがたかったです
sanfrecce_osaka.icon どのセッションも盛り上がった
普段聞けない話が知れた
onk.icon コミュニティが混ざるのは嬉しい
よく貼る資料に差があるのが面白かった
luccafort.iconこれは普通に嬉しいし、いい話
CelloTAK.icon テストの話は無限にできそう
ymzn.icon無限にできるな
テストに対する資料がとてもよかった
Ruby に限らない議題が多くて助かった
コミットコメント関連を見直すきっかけになりそう
matsuday.icon仕事でテストを書き始められたので、メチャクチャ勉強になった。
CelloTAK.icon 変革マネジメントという概念があるんだということを知れました。
uproad3.icon 大阪にはOST形式の勉強会が少ないので新鮮
luccafort.iconいろんな企業の人の参加が増えてきた
onk.icon prosopite 面白いな。300行ぐらいしかない
code:txt
~/src/github.com/charkost/prosopite$ tokei lib
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
Ruby 4 334 274 2 58
===============================================================================
Total 4 334 274 2 58
===============================================================================
Problem
ymzn.iconテーマの水平展開ができなかった（いろいろなテーマができなかった）
uproad3.icon ちょっと時間足りなかったかも（もっと話したい）
onk.icon コードの話が少ない
uproad3.icon 席がギリギリだ！（大繁盛）
sanfrecce_osaka.icon 他の話も気になっているものが多かったけど、どれも得票数が多かったので並列にするかどうかの判断が難しい
持ち票を決めて2回目の挙手をしてもよかった？
しがあきとし.icon良さそう
matsuday.icon賛成！
luccafort.icon持ち票制はよさそう
onk.icon 得票数が多かったとしても遠慮無く割るかねぇ
ymzn.icon元々？のOSTみたいに複数セッションにして行きたいところに行くでもいい気はする
ymzn.iconあとはLeanCoffeeみたいにするとか
ymzn.iconrubyならではの話をもっと聞いてみたかった
同じく。(いとう)
CelloTAK.icon 確かにRubyコミュニティのはずがRubyの話があまりなかったですね、、
onk.icon 4 時間やるなら LT というか持ち寄り話題が 1 本ぐらいあった方が場が締まるんじゃないか
luccafort.icon話せることがあまりなかったなぁ。
luccafort.iconEvil MartiansのOSS眺めたかった……
しがあきとし.icononk.icon
sanfrecce_osaka.icon 次回リベンジでやりませう
sanfrecce_osaka.icon 次回も OST でよさそう？
luccafort.icon時間わけてもいいけどね〜。前半は発表、後半でOSTとか。
ymzn.icontestingOsakaはそんな感じです
しがあきとし.icon次回行きます！！！
大久保.icon
luccafort.icon飲み会向けのネタとガッツリ議論するネタが混ざると悩ましい（そして得票としては飲み会ネタが意外と高評価だったりするとさらに……）
Try
prosopite 読む
Evil MartiansのOSS 眺める
OST で時間制限をいれる
e.g. LeanCoffee
懇親会
時間: 19:00～
参加人数: 11名
次回開催情報
候補日
8/2（土） onk.icon
8/9（土） onk.icon
8/10（日） onk.icon
8/16（土） onk.icon
8/17（日） onk.icon
8/24（日） onk.icon
フリースタイル形式
要望や意見