大吉祥寺.pm 2025 に参加しました。
カンファレンスに参加した感想をまとめます。
- イベントの概要
- 前夜祭について
- セッション
- 2025年になってもまだMySQLが好き
- 【実演版】カンファレンス登壇者・スタッフにこそ知ってほしいマイクの使い方
- 提案レベルを上げてみたら、私の『提案』が『進捗』になっていた件
- 今！ソフトウェアエンジニアがハードウェアに手を出すには
- 機能追加とリーダー業務との類似性
- 小さな開発会社を作った理由 (再)
- コミュニティはいつまでも続くわけではない - PostgreSQLコミュニティの危機
- 地方でエンジニアコミュニティを成功させる秘訣：”身内ノリ”を避け、”熱狂”を生み出すための挑戦
- エンジニア採用を引き継いだあなたへ 〜EMが採用に向き合うとき、まず知っておきたいこと〜
- 普及のすゝめ
- 2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
- 大「個人開発サービス」時代に僕たちはどう生きるか
- 定義のない仕事ーー2025年の今CTOになった私から伝えたい[CTOになった人／CTOを目指す人／CTOを迎え入れる人]たちに必要なナレッジ
- 【共催LT】 Japan Perl Association
- 明日から役にたつLTをダメにする技術をあなたに
- カオスエンジニアリングを5分でわかった気になろう
- 組織が大きく変わろうとするとき、自分はどうありたいかを考えている
- プロポーザル駆動学習：暗黙知を形式知へ変える実践的学習法
- 2025年のPython環境はここまで簡単になりました！ 環境構築ツールパビリオン クイックツアー
- 令和でもブログを自宅サーバで
- なぜスクラムはこうなったのか？歴史が教えてくれたこと
- キーノート
- 昼休憩
- アンカンファレンス
- 懇親会
- 感想
イベントの概要
「吉祥寺.pm」は、当初Perlのイベントとして始まりましたが、次第に参加者の多様性が広がり、プログラミング言語や、データベース、設計方法論、キャリア、勉強会開催方法など、Perlに限らず、「それぞれが発表したいことを自由に発表できる場」に変わっていきました。発表枠は毎回必ず全て埋まり、常に新しい人が参加し続け、毎回全く違う発表が行われる、数あるテック系勉強会の中でもユニークなイベントになっていると言えます。
引用：
前夜祭について
セッション
2025年になってもまだMySQLが好き
メモ
千葉.pmのpはPerl、mはMySQL。
MySQL歴13年。
RDBの面白さとは？使い方を間違えると大変。
妥協の中使っていかなきゃいけないのがかわいい。
MySQLは実行計画がおかしい。けど、許容できる。
DBAと開発者でロールが分かれていると、
監視が分かれる。メトリクスに対する経路が分かれる。
MySQL側でしか気づけないものがある。
結果、MySQL専属となる。
現在、アプリケーション監視が進化し、ログが集約されている。
アプリ側でもMySQL側の監視の実現が可能となってきた。
MySQL側でもオートヒーリングが実現し始めた。
オンコールから離れて過保護な監視になっていたことにも気づいた。
MySQLとMariaDB、まったくの遠縁ではない。
感想
MySQLとの出会いは新卒研修の17年ぐらい前でした。
ただ、こんなに情報を浴びたのははじめてでした。
MariaDBとの関係もはじめて意識をしました。
こだわりのあるエンジニア素敵すぎる。
【実演版】カンファレンス登壇者・スタッフにこそ知ってほしいマイクの使い方
メモ
・マイクは口の前に
・マイクスタンドは調整可能
・声を大きくした方が良い
・登壇用のマイクは単一指向性
・マイク叩いちゃ駄目
感想
マイク得意です。マイク叩いちゃ駄目は本当にそう。
提案レベルを上げてみたら、私の『提案』が『進捗』になっていた件
メモ
言語化を引き取ると提案が進む。
参考：
提案レベルが低いと、相手に判断を委ねて言語化コストを与えている。
提案ではなく、質問になっている。
言語化コストを引き受けると、進んでいるものとして進捗として扱える。
書き伝える。選ばせる。区切りをつける。
判断・翻訳・調整を提案に含めることで実現する。
言語化を引き取ると、提案は進捗になる。
感想
自分も組織レベルのやり取りで意見の投げ合いになりがちなことに気付きました。
細い管を通したコミュニケーションで、相手に何かを言って動いてもらうことはあまり良いやり方ではない。
できるだけサイロを作らずに、一緒に考える状況を作ることが重要と改めて感じました。
…そういえば、「投げっぱなしジャーマン」て言葉聞かなくなったな。
今！ソフトウェアエンジニアがハードウェアに手を出すには
メモ
HOWの楽しさ。
ソフトウェアとハードウェアの対比。
ソフトウェアは全体最適に向いている。ハードウェアは部分最適に向いている。
ハードウェアはAI登場以前のソフトウェアと同じ状態なのではないか？
前提：ハードウェア＝電子工作。
参考：
ソフトウェアエンジニアでもハードウェアに挑戦するハードルが下がっている。
非エンジニアがAIでソフトウェアに向かうのと同様に、
ソフトウェアエンジニアがハードウェアに向かうムーブを考えることができる。
ハードウェアは関数とみなすことができる。
ハードウェアの一部をソフトウェアに置き換えていく流れもある。
作り方については生成AIに質問をすると答えてくれる。
ハードウェア、生成AIとの付き合い方。
作る喜びを感じ続けることができる。
感想
今まで挑戦するにはハードルが高いと感じていたことを気軽にトライできる時代になったことを感じました。
作る楽しみはどんな形でも生み出していくことができる。
機能追加とリーダー業務との類似性
メモ
リーダーやって感じたこと。
やること増えた。エンジニアの時のやり方ではうまくいかない。
エンジニアとリーダーで求められる責務、スキルが違う。
新米リーダーの悩み。
違いが多すぎて、何から手を出せばよいか分からない。
なぜリーダーになったのか？上長に今までの業務経験から適正があると判断されたから。
V字モデルにおいて、エンジニアは各工程で成果物をつくる。
現状把握、計画、実行、確認をする。機能追加もリーダー業務に似ている。
自分の得意領域に持っていく。
違いもある。説明責任・実行権限。
マネージャーから与えられた実行権限をメンバーに付与していく。
説明責任と実行責任をすりあわせていく。
感想
自分がリーダーになった頃、「特に強みのない自分がリーダーなんて皆どう思うんだろう？」とびくびくしていたことを思い出しました。
リーダーを任せてくれた上司の評価を把握できていなかったと気づくことができました。
今は自分がリーダーをお願いする立場でもあるため、相手の何を評価して、何を期待しているか、何度も言語化してすり合わせたいと思いました。
登壇内容からemconfで聴いたこのセッションを思い出しました。
リーダー
小さな開発会社を作った理由 (再)
メモ
去年は体調不良で代打LT。
理由：父親を越える38年続く会社を作りたかった。
会社を継続させるために、一緒に力（知恵、行動）を合わせてくれる仲間が必要。
様々な年代の人が楽しく働ける環境が重要。ファンも重要。
受託開発好き。製品を作る・売るという活動が重要。
失敗しても何度もチャレンジする。
現在プロダクトを作っている。９末リリース予定。
感想
昨年のLTの衝撃を思い出しました。
想いが込められた仕事は強いと改めて思いました。
トライ&エラーを繰り返して練度をあげていく。内発的動機付けがそれを可能にする。
コミュニティはいつまでも続くわけではない - PostgreSQLコミュニティの危機
メモ
好きな場所はいかなきゃなくなる。
参考：
吉祥寺.pm = Postgres、MySQL会。
コミュニティは勝手に生まれるわけではない。
誰かがいなくなるとコミュニティはなくなる。
運営メンバーのライフステージ、転居、金銭・物理、モチベーション。
情熱だけで続けていくことは現実的ではない。
PostgreSQLはコミュニティが主体。
メンバーが固定している。理事の高齢化。継承リスクがある。
誰を巻き込んでいくか。
ホームランを打てるようになってから、バッターボックスに立つのではない。
登壇のバットを渡していく。
やっていくうちにできるようになっていく。手を動かした人だけが世界を変える。
感想
好きな場所には主体性をもって絡むべきだと改めて思いました。
本当に大切な場所だとしたら、受ける側でいるだけでなく、推進できる側に加わる。
今、PostgreSQLを使っています。何かプロポーザルを書けるか。
「はじめて出会ったjsonb列」的なやつぐらいしかない…
地方でエンジニアコミュニティを成功させる秘訣：”身内ノリ”を避け、”熱狂”を生み出すための挑戦
メモ
今、地方コミュニティが強い。
問題提起：エンジニア仲間欲しくないか？地元でも維持できるか？
地方コミュニティの意義。
新しい知識、深い知識。エンジニア同士の多様な考え方・視点の交換。
いつでも行ける準備が必要。
コミュニティは狂気で運営されている。モチベ：楽しさ、感謝、知的好奇心
プラス要素を増やして運用を維持していく。
参加しやすさと継続性が重要。参加してもらうための自己開示、呼びかけが重要。
感想
地方コミュニティ、TechRAMENでその魅力を味わいました。
八王子.pmや町田.pmに憧れています。多摩.pmが良いのかも知れない。
エンジニア採用を引き継いだあなたへ 〜EMが採用に向き合うとき、まず知っておきたいこと〜
メモ
EMは仲間集めのためにカジュアル面談にコミットすべき。
カジュアル面談にコミットすべき理由。
・対面で話す最初のタイミング
・営業に近い
・エンジニアによる面談が望ましい
もともとバックエンドがメインのエンジニア。
メディカルフォースにはEMを志して入社。
最初は分からないことがいろいろあり、頭を抱えることに。
カジュアル面談。
一次選考への通過率を65%にあげることができた。
CX（候補者体験）にこだわりたく、いろいろ試行錯誤をしている。
面談をするのではなく、会社への興味を持ってほしい。
感想
カジュアル面談をエンジニアがやる重要性について。
コンテキストが似ている人同士で会話をすることで、業務に対する理解が進むだけでなく、
どれだけ共通目的に対して同調できそうか掴むことができるイメージを持ちました。
メディカルフォースさん、開発生産性カンファレンスでのセッションも素敵でした。
普及のすゝめ
メモ
SREの普及をしている。
・ゆるSRE勉強会
・SREマガジン
・SRE Kaigi
・法人を作った
なぜやっているか？
おもしろいからだけじゃなく、おもしろいと思うことを普及したいから。
現状、SREがガートナーの報告で減退期に入っている。
界隈の壁を越えるためにも普及をしている。
興味を持ってもらってコミュニティのうねりを作りたい。
うねりを作りたい人の背中を押して、恩送りをしたい。
SRE Kaigi 2026開催決定！！
感想
「おもしろいから普及する」というモチベーションが大事と改めて思いました。
今年のSRE Kaigiでの学びも大きかったです。来年も参加したい。
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
メモ
AIコーディング支援の進化。補完型⇒チャット型⇒エージェント型。
チャット型：自然言語での対話でソースコードを実現
エージェント型：自動的にタスクを完了できる
コーディング・エージェントの３つの類型。
エディタ型、CLI型、自律型
タスクに応じて使い分けられるのが理想。
30分以内の小規模タスク：自律型エージェントが最適
チャレンジングなタスク：CLI型、エディタ型
大規模なタスク：人間によるタスク分解が必要
AIを使うことはもはやマネジメントである。
エンジニアの仕事がコードレビューに寄っていく。
AIがコードを書くようになっても開発生産性は変わらない。
ジュニアエンジニアの役割はどうなるか？
学習の効果を高めた早期成長が期待できる。
生成AIとの付き合い方。
はじめの一歩のハードルを下げることができる。
学習でのAI活用。ただ、自分で書いて覚えることは重要。
基礎力：プログラミングの基礎的な知識
瞬発力：新しいものが出たらとりあえず触ってみる
生成AIの発言を盲信しない。劇場のイドラ。
時代の転換点を楽しむ。
参考：
感想
ドメインごとの生成AIとの付き合い方はよく聞くなか、エンジニア目線での扱い方の整理がとても分かりやすかったです。
チームでも生成AIと付き合っていくうえでの知識をすり合わせていきたいと思いました。
大「個人開発サービス」時代に僕たちはどう生きるか
メモ
2010年頃。インターネットが爆発的に普及した。
すべてがブルーオーシャン。今はあらゆる領域がレッドオーシャン。
スイートスポットを満たすプロダクトだと生き残れない。
= サービス開発はコストがかかる * 資本主義の経済の成長力学。
そんななか、AIによる生産性の爆発が起こった。
開発に時間がかからないと資金調達が不要になった。
結果、少人数に充てたニッチな領域にも手を出せるように。
今は個人開発でそれが実現できる。
３つのでも。
・作りたいものが思い浮かばない→生活上での不便など改善したいものはあるはず
・既にそうしたサービスあるんじゃ？→似たものがあっても良い
・どうやって作れば良いか分からない→今こそ求められるスキル
感想
実装のコストが抑えられることでプロダクト開発のための費用が低くなり、
大きな売上が期待できなくても、特定の領域に充てたプロダクト開発をしやすくなったことを理解しました。
そのうえで、立ち上がりを生成AIがサポートしてくれることで、実現ハードルも低くなった。
個人開発、憧れます。音声だけでGoogleカレンダーにタスク作ってくれるアプリとか良いかも。
定義のない仕事ーー2025年の今CTOになった私から伝えたい[CTOになった人／CTOを目指す人／CTOを迎え入れる人]たちに必要なナレッジ
メモ
CTOはよくあるキャリア。プログラマから一直線した。
CTOやって学びが多い。貴重な経験をしている。
コンテキストゼロの状態からCTOをやるとどうなるのか？
VUCA時代。これまで通りの仕事が通用しなくなる可能性がある。
作る価値の低下。保守性より破棄性。
そんな時代に定義の無い仕事は誰にも訪れる。
定義のある仕事の競争相手はAI。
CTOの仕事に定義は無い。
どんな仕事をするかは変数次第。
組織フェーズ／規模／課題／事業特性／経営チームの構成
リーダーシップとマネジメントは違う。
・得意なことをインスタントにやる
自分は貢献できていないと思いがち。
リアリティショック。インポスター症候群。
心を落ち着けるために得意なことをやる。
・見の姿勢をやめる
見の姿勢はひとつのやりかたでしかない。
必要以上に恐れない。ぶつかりあったほうがいいこともある。
・対話する
開発メンバー、開発メンバー以外
・スケジュールの整理
参加しなくていいものを決める。
・得意不得意の可視化
互いの期待値のすりあわせ。自己開示してのすりあわせ。
・現場で協働
コードを書くことが活力になっていることに気付く。
・CEOの願いをかなえる
貢献できることの喜び。バイブコーディングで短い時間でできる。
やらなければよかったこと
・手当たり次第の1on1。オフィスアワーにすることで解消した。
・CTOがやるっぽいこと。誰かに権限委譲するのが重要。
エンジニアリング戦略を最初に文書化すべきだった。
定義が無いことで、自分の解釈に依存する形で定義するのが悪手。
誰かの目を入れることが重要。
感想
いつも娘が保育園でお世話になっています。
コードが心の栄養となる話に強く共感をしました。
定義の無い仕事を、コンテキストに合わせて定義していく。
組織を能動化していく重要性を感じました。
【共催LT】 Japan Perl Association
メモ
Lightning Talk。光のような速さ。
YAPC::Fukuoka 2025。11/14-15 @福岡工業大学。
感想
タイムラインに流れるプロポーザルから面白そうと思っていました。
行ってみたい。
明日から役にたつLTをダメにする技術をあなたに
メモ
駄目１：強烈なイメージ
駄目２：ウケを取りに行く
駄目３：自己紹介
駄目４：一般的な事例だけを紹介する
駄目５：主題を絞らない
伝えたい内容だけに集中し、ノイズを入れない。
ノイズが多い場合に何とかする技術：こんな感じです と伝える。
駄目６：内輪、一部の人にしか伝わらないネタ
感想
面白い。。
カオスエンジニアリングを5分でわかった気になろう
メモ
カオスエンジニアリング＝品質マネジメントの一環。
未知未知を確認するために、カオスエンジニアリングを適用する。
実験→認知矯正→未知未知を減らす。
何を残し、何を手放すかを苦痛を伴いながら体感する。
感想
今まで探索的テストを未知未知を洗うために扱っていましたが、
結局は意識に引きずられるため、カオスエンジニアリングが最適と思いました。
試してみたいです。
組織が大きく変わろうとするとき、自分はどうありたいかを考えている
メモ
ゆめみサーバサイド３年目。
買収発表時：驚き。他人事感はあった。
何日後：怪文書があった
買収の話題で会社の今まで厭に思っていた部分が表に出てきた。
ただ、コミュニティ活動などに忙しくすることで、忘れてきた。
一次情報も大切だと思った。
感想
環境は全然違うものの会社に対する想いに共感しました。
うーたんさんのコミュニティ活動に恩恵を受けています。
プロポーザル駆動学習：暗黙知を形式知へ変える実践的学習法
メモ
プロポーザルは、
１．脳内整理のための重要な機会
２．不足結果をもとに改善に繋がる
暗黙知を形式知に変える方法になる。仮説・問いの再認識にもなる。
推敲を重ねてギャップを埋める。
感想
今年は自分が少しでも扱う領域のカンファレンスには必ずプロポーザルを出しています。
推敲もっとしなくては。
2025年のPython環境はここまで簡単になりました！ 環境構築ツールパビリオン クイックツアー
メモ
仮想環境を人力で管理していたところ、uvが誕生した。
感想
Python扱うのにuv知りませんでした。調べる。
令和でもブログを自宅サーバで
メモ
ブログを書こう。
ブログ執筆はアウトプットよりインプットが本質。
体験を文章化するうえで、ブログを経由して
自分のアウトプットが、自分のインプットにもなっている。
ブログの良さ：バランス、外向きの自分を出せる
感想
大共感でした。
より良いインプットとするために、少しでも丁寧に書くことができればと思っています。
なぜスクラムはこうなったのか？歴史が教えてくれたこと
メモ
歴史の専門家ではなく、スクラムの実践者。
スクラムの源流をたどってみる。
RSGT2025でのHondaのCITYの開発の話はスクラムの源流の源流（湧き水）の話だった。
学びよりバトンを受けた感覚があった。
今後、自分たちのバトンをどう受け渡していくかを考える。先人の実践を学ぶ。
感想
スクラムを抽象度の高い体系づけられた静的な知識だけでなく、
動的な実践から学ぶことでよりその価値を理解できるイメージを持ちました。
特にスクラムガイドの抽象度だと自分のコンテキストに引きずられて解釈をしてしまいがちのため、自分の意識を補正するためにも先人の実践を学びたいと思いました。
キーノート
メモ
1972年生まれ。エンジニア30周年。
2025年、不安。新しいことのキャッチアップ。健康維持。周りとの関係性。
クライアントの求める設計できている？コミュニケーションを通して、わかると楽しい。
プロジェクトのマネジメント。成果が見えると楽しい。
新しい技術。PerlのコアモジュールにPR出し続けた。動くと楽しい。
人脈が広がっていく。仲間がいると楽しい。
不安に思ったことを、楽しいことに変えていく。
対象にアプローチして、変え続けてきた。
これからも実践を続けることができる気がする。
感想
個人の不安を楽しいに変えてきたことが、おおきなコミュニティに成長していくことに魅力を感じました。
１年前自分がはじめて吉祥寺.pmに参加したのも、自分のエンジニアとしての世界観が局所的なのではという不安からでした。
いつも豊かな学びをいただいています。
昼休憩
去年のマッチングはぼっち恐怖症により不参加でしたが、今年は思い切って参加しました。
ご一緒させていただいた皆様ありがとうございました。
ポッドキャストや配信についての話題が勉強になりました。
また、Yokohama North AMのhanhan1978さんとご一緒できて嬉しかったです。
個人でのポッドキャストを持続していくためのモチベーション維持についての話が興味深かったです。
アンカンファレンス
アンカンファレンスも興味深いテーマが多くありました。
自分はt_wadaさんの時間に参加しました。
ユニットテストについての不安との付き合い方が興味深かったです。
テストケースを増やしても、コードは増やさない。
生成AIを使うことを目的にしない話は、つい先日開発チームでt_wadaさんの話をもとにどう扱っていくのが良いか話していたので、改めて手段として活用していくことが重要と学びました。
懇親会
ぼっち症候群で懇親会避けがちですが、今回は思い切って参加しました。
登壇者であるArthurさん、azukiazusaさん、うーたんさんと同じテーブルで興味深い話をたくさん聞かせていただきました。
ご一緒させていただいた皆さまありがとうございました。
登壇や書籍、ブログなどを通じて学びをいただいた方や、普段X上などでお見かけする方にご挨拶できたことも嬉しかったです。
感想
前夜祭含め、豊かな学びの多い２日間でした。
自分はPerl使いでもPHPerでもないのですが、それでも終日楽しんで学べる場あることにコミュニティの豊かさを感じます。
今週、AI×開発組織Summitに参加したこともあるからか、
生成AIが躍進していく世界でいかにエンジニアが作る楽しみを持続していくか、といったテーマを感じました。
自分は今年42歳でMagnolia.Kさんの10歳下になります。
10年後も楽しめるように実践を続けていきたいと改めて思いました。
とても豊かな時間をありがとうございました。
