名もなき未知

エンジニアリングとか、日常とかそういうのをまとめる場所。アクセス解析のためGAを利用、Googleに情報を送信しています。商品紹介のためAmazonアフィリエイトを利用、Amazonに情報を送信しています。記事に関しては私が書いていない引用文を除いて自由にご利用ください。

PHPカンファレンス2026 リジェクトコン&アフターイベント に参加した

学びが多い会でしたね。

イベントページ

PHPカンファレンス2026 リジェクトコン&アフターイベント https://codmon.connpass.com/event/400633/ #PHP_After

メモ

Connpass に資料が公開されていないっぽいので、記憶ベース

  • コネクションをピン留めさせずに、SELECTクエリのタイムアウトを設定した話
    • 資料発見 https://speakerdeck.com/codmoninc/database-timeout-setting
    • 実行が長いものについて max_execution_time の機能を利用することにした
    • クエリごとに付与できるのでそれを活用する
      • Laravel の場合、 timeout メソッドがあるようでこれを活用できそう
      • https://laravel-news.com/laravel-12-51-0
      • 古い場合は DB::raw('/*+ MAX_EXECUTION_TIME(1000) */ *') のセットが必要なようだ
    • しかし RDS Proxy との相性が悪い
    • そのためクエリごとにコメントで付与する形式で対応
  • AI時代のPHP開発にASTクエリツール でコードベースの地図を作る
    • 資料発見 https://speakerdeck.com/codmoninc/ast-query-tool-php-codebase-map
    • AI は知識を持っているもののの、うまく情報を渡す必要がある
    • 構造をクエリで渡すことができないか、という発想
      • AST との組み合わせ
    • いろいろ調査をしてみて grep でも十分な効果を確認できた
    • ただしコード構造を渡すことで正解までの速度は高速化できそう
  • カートの信頼性を担保するWireMockを使ったe2eテスト
    • 資料発見 https://speakerdeck.com/ykagano/katonoxin-lai-xing-wodan-bao-suruwiremockwoshi-tutae2etesuto
    • WireMock は Java で動作する Mock サーバーらしい
    • e2e テストが外部APIの仕様変更に影響して落ち続けている問題があった
    • ただし WireMock が苦手とする分野もいくつか存在する
      • Javaの拡張を書くのはチームメンバーのスキルスタック的に難しい
    • WireMock を Proxy にしつつ、PHPでも Mock を一部書くことにして解決
    • 外部APIとの整合制については日時でチェックして取り込んでいる
  • エンジニアの地力の鍛え方:エラーチャンネルのボールを拾い続けること
    • 詳細は新潟で発表するということで今回はショートバージョン https://fortee.jp/phpconniigata-2026/proposal/be811eee-b0f2-4005-8f2f-96d1a0a6494b
    • エラーチャンネルへの通知を減らすための活動をしていますか?
    • 何回でも出るようなエラーについては典型的なパターンの可能性も高い
      • 典型的なパターンをつぶすのはAIが得意とするところ
    • 毎週1時間エラーを見る時間をつくってその時間帯で一緒にエラーをつぶす活動をしている
      • 1時間以内にPRまで出せるケースもある
    • 以外と一緒に活動して継続していると文化の形成にもつながるし、エラーの先には困っている一人のユーザーがいるというストーリーもよい
  • Laravelの検索ロジックをOpenSearchで高速にしてみた件
    • 資料見当たらないかも
    • 検索が非常に遅く、ユーザー体験が悪かった
    • RDSでの検索からOpenSearchへの検索に切り替え
    • しかし体験は変えないために、RDSでの検索と同党の体験になるようOpenSearchをチューニング
      • OpenSearch のメリットも一部薄れたが、既存ユーザーの体験を大事にした
    • 速度が大幅に高速化(10倍くらいといってた気がする)
    • 途中離脱率の改善にもつながった
    • プロダクト特性をかんがえていて、リアルタイムのデータ反映をしなくてもよいということが判断できたので、タイミングを見て OpenSearch に同期する方法を考えた

感想

各社の取り組みを知るとともに、 max_execution_time の設定の話とかは知らなかったので勉強になりました(そういうのに収まらない場合は徹底的にクエリをチューニングしようという方向に進みがちで、緩和しようというのをうまくやろうとしているのがすごいなと思った)。 WireMock のようなモックサーバーもあんまり使ったことがないし、気になるものばかり。

また Sentry を使って週1回エラーメッセージをちゃんと見て直しているのもいい取り組みだなと思いました。 こういうので時間ブロックしてコア作業しないとなかなかやろうと思ってもやれなかったりするので、いい文化だなと思いました。

そして OpenSearch など、全文検索エンジンはうまく機能するととても高速ですね。 前使っていましたがうまく使いこなさなかったので、改めて勉強しなおしてみようかな。

CRE Camp #6 に参加した

気が付いたら1か月前でした。ここのところいろいろあったので仕方ないですね。

イベントページ

【増枠しました!】CRE Camp #6 ー 現場でつくるユーザー信頼性 ー LTと対話のセッション

https://cre-camp.connpass.com/event/395332/ #cre_meetup

メモ

LT

  • 1個目
    • 資料公開されていました https://speakerdeck.com/assuredjp/cre_202607
    • 自分たちでCREを考え、定義した
      • 顧客対応とか、営業動向とかあったが…
      • Customer の形が多様であるからこそ、自分たちの組織にあっているものを定義する必要がある
    • お客様のビジネスの成長に貢献する、共創する
    • そのうえでやるべきことに取り組む
  • 2個目
    • 資料公開されていました https://speakerdeck.com/tanaken0515/when-do-you-feel-a-customers-trust
    • CRE組織の立ち上げからプロダクトの開発に戻った
    • プロダクトの開発でも同じように顧客の困りごとの解決には立ち向かっているし、意識的には実は変わらないのかもしれない
    • 一方で作っているだけでは気づけない、顧客の成果につながっていると実感しやすくなったのは良いこと

CREって何だろうというのを自分も学び始めたところなのですが、カスタマーが toB, toC なのかで変わってきそうな面もありますし、どういった問題を解決したいからサービスを導入するのか、という点を考えると customer にとって支援が必要なことは変わってくるのかもしれません。 そういったことを考えたときに、自分たちの Customer が何の問題を抱えているのか、ということを深く考えてみるのはやってみたいワークだなと思いました。

そのためには現状の分析や、対応していることをリストアップしてみるのが大事かもしれないですね。

OST

時間がたって覚えていない面があるのですが、顧客情報の取り扱い、個人情報の機密性、そういったものを守りつつどう高速に調査を回していくのかが大事か、という話が多かったように思います。 技術的なテクニックとして知らないものもあったり、ストレージとしてどうデータを管理しておくか、戦略にも生かすかといったところは各社取り組み方のスタンスが違うように思いました。

テクニカルな面で知らなかったのは Change Data Capture(変更データキャプチャ) 連携の話で、ログベースで分析基盤に送りつつ個人情報のところはマスクしましょうみたいなところで、データの連携についてもいろいろ考えるところがあるんだなと思いました。 あと BigQuery とか DWH の話を聞くとも多かったかな…。

感想

CREの方々と話せて非常に面白かったのと、市場的にCREという存在自体が稀有ということがよくわかりました。

そもそもサービスサイズが大きくスケールしてこないと、このような部署を設けるよりも兼任で取り組むところのが体感多いのかなと思っており、その予想自体はあってそうな気がしてきました。 つまり大きくなりつつあるサービスだからこそ求められる仕事であり、ポジションなんだなと再認識しました。

そういったところで各社採用に苦労しているという話も多く出てきました。 今だと AI もあるので、バックグラウンドがエンジニアでなくても、カスタマーサクセスの方がうまくサービスを組み合わせたり、クエリを実行するだけでもCREの業務に挑戦できる可能性があるということで、多様性を感じます。 今回参加されていた方で話している限りですと、エンジニアバックグラウンドの方も多かったですが、カスタマーサクセスやPMの方も聞いている感じだと何名かいらっしゃってました。

なかなかこのような顧客に密着しているところの運用を聞きつつ、話し合える場所というのはないので、今後もたびたび参加しようかなと思っています。 次回もあれば積極的に参加したいですね。

大吉祥寺.pm 2026 に参加した

今年は参加できたので参加しています。去年はくりあがれなかったので、参加できなかった記憶。

イベントページ

大吉祥寺.pm 2026 - connpass https://kichijojipm.connpass.com/event/387499/

雑感

AI時代に、なぜエンジニアはまだ集まるのか

資料公開されていました。 https://x.com/wabi_1318/status/2080829174630187110

コミュニティのあり方とか人はなぜ集まるのかとか、なんとなくいいと思っていたことを非常にうまく言葉にして表現していていいなと思いました。 還元したい気持ちが多いコミュニティの人が多いのも良いですし、実践して共有する場でもあるというのは会社や学校だとやりにくい部分もありますし、コミュニティがいい場所になっているというのは間違いなくあるでしょう。

コミュニティに参加して何になるんだろう、という人たちに対してこの発表の内容や言葉を使って伝えてみようかなと思いました。 (自分はなかなかコミュニティの良さという点を言葉に落とせなかったので、リスペクトしていきたいです)。

そこに3びきプロダクトがいるじゃろう——生成AI時代における“価値が届かない理由”の構造

便利そうだなーと思いつつも、なかなか使ってもらえない苦しさがあるなと思いました。 手を動かして作ることは楽しいものの、現代ではフロントエンド・バックエンドをきれいに作り込んでもなかなか使ってもらえないという難しさがあります。

しかし、つまづきは失敗ではなく、作ったからこそわかる学びが多そうに見えました。手を動かして形にするのはやっぱり今でも大事なように思います。

分割統治できない世界の歩き方

面白そうな話であるものの、後半スキップになっていたので資料が出たら読み返したい…。 資料公開されていました https://hihats.github.io/presentation/beyond_divide_and_conquer/

エンジニアリング、更に大きなところでは科学の礎となっており400年くらいある還元主義(分割統治)はエンジニアリングの文脈では有効であるものの、事業貢献や事業成長に寄与するような活動になるかというとそうではないという難しさがあります。

例えばボトルネックであったリリース頻度やリリース回数を増やしたとしても直接売上につながるか、ということは必ずしも結果として現れにくいということがあります。 リリース頻度やリリース回数は分割統治された分解した課題と言えますが、これを解決しても結果につながっていないというのは難しいところです。

その後でシステム思考の話が出てきたものの、結構飛ばされたスライドも多く理解が間に合わなかった… のでもし公開されたら後から追います。

人間の目はかわらない、だからJPEGは30年もつ

資料公開されていました。 https://x.com/yuzneri/status/2080860660767093118

JPEG がなぜ生き残っているのかがよくわかった気がします。 意外と圧縮されても色の違いが分かりづらい、というは人間の目の精度に由来するところもあり、人間が見る分にはこれくらいでいいんだと思いました。

JPEGの圧縮アルゴリズム自体も面白そうなので、実装してみるのも面白そうだなと思いました。

入口の先まで守る。AIで現実味を増す横展開と権限昇格

AIによる攻撃が高速化していることにより、今までたまたま攻撃されていなかった対策すべきところの対応速度を上げていく必要があると感じました。 クラウド環境に強い権限で入れると、強い権限で操られる可能性があるとか…

また問題が起きた後の事後対応を高速化していくことも大切です。

ファクト・リファクタリング

リファクタリングはどこでもやればいいわけではなく、重要なところに取り組む、というのは大切ですね。 一方でエンジニアとして楽しむという点も忘れないように。

おひる

ランチマッチングしてサルバトーレで食べてましたが、意外と色んな人たちと参加している勉強会がかぶっていて共通点があるのが良かったです。 ピザ美味しかった

仕様書のない組織を運営する 〜エンジニア、PTA会長になる〜

戻り時間が遅かったので最後だけちらっと聞いたのですが、まずはいきなり変えないことの大切さを知りました。 何を変えて何を変えないべきか、まずはじっくりと話を聞く。LINEグループにいくつも参加して情報を集めているのは地道だなと思いつつ、急に変えないために大切な活動だなと思いました。

変わらないものが、変わるものを決める — 全ての意図を残す意図駆動開発、データは追記のみのイベントソーシングと全てはイミュータブルに向かう

資料公開されていました。 https://x.com/tomohisa/status/2080886931161071955

お昼の後で結構眠くなってしまっていたので、若干記憶があいまいです。

考え方として上書きから追記へ、というメッセージは興味深かったです。今まで自分はあまり考えてこなかった分野のように思われる。 確かに追記型だと updated_at はわかるけど… みたいないケースは多いように思います。会計は消しゴムで消すことはなく、打消用の消込を入れているというのも納得感はありました。 他方、後からたどることができるとかリプレイできるというメリットはあるものの、保存量やスキーマ設計、プライバシーへの対応が必要という点も心掛けておきたいところです。

仕様の版管理とかも理想的ではあるなと思いました。アップデートされ続けるものの、その時の仕様としてはどうだったっけ、みたいなのもありそうですし…。 意図を残す、というのも結構納得感があるなと思いました。

お元気ですか.fm~5年間の配信で振り返る「かわるもの」と「かわらないもの」

資料公開されていました。 https://x.com/ogenkidesuka_fm/status/2080912820414414918

アウトプットの継続力や、自分たちの立場が変わる中での考え方の変化をリアルに残しているのがいいなと思いました。 またポッドキャスト形式だからこそ伝えやすいこと(ニュアンスとか)もあるので、発信方法のメリットデメリットがいろいろあるよな… とも感じました。

まずやってみて、残してみないとですね。

「待ち時間」の消滅と「自我消耗」の加速:生成AI時代のエンジニアを救うメンタル・リソース管理

仕事が高速化していく中で、ある程度制約をもって仕事をしていく。 それを個人の期待感として調整することが大事なのかな、と思いました。

あとはたまには外に出てリフレッシュするなど? 夕方ごろで疲れていたこともあり、記憶があいまいです。

それでも、技術なブログを書く理由

資料公開されていました。 https://x.com/shinkuFencer/status/2080954349384306800

ちょっとしたテクニックとして普段使っているアイコンをブログのファビコンとしておくとトレードマークとしていいかもっていう話がありました。いつかそうしようかな。

ただAIが登場する中でブログに対するモチベーションや向き合い方が変わっている、というのは自分も同意見な部分があり。 書き手自身が理解を整理して深く学ぶ、というプロセスはあまり変わっていないものの誰かの役に立っているのかな… は自分の場合はちょっとわからなくなってきました。

20年以上続くITコミュニティを見て、今までのITコミュニティ遍歴について考えてみた

疲れた時や変化があったときは少し離れてみても、人に貢献したいという気持ちがあればまた戻ってくるのもいいなと思いました。 コミュニティ運営はそもそも大変なので、無理しすぎないような距離感で何かいい形でかかわれればなと思います(自分も悩んでいるところではある)。

2026年、OSSコントリビュート初心者の歩き方 〜軽い一歩を、軽いままにしないために〜

資料公開しました。 https://x.com/5hun_s/status/2081401096950669700

AI Slops の話題が増えてきていますが、OSS で PR やレビューをするというところも変化がありつつあります。 その中で自分自身の理解を改めて深めたうえでこれだ、というものを出すことが大事だなとは思いました。 仕事の考え方ともあまり変わらない、というところは逆にOSSに入りやすいようなイメージも持てたので何かやれるといいなと思いましたね。

新卒2年目が感じているAIとの付き合い方の苦悩

AI があることによって達成感を得られにくくなったとか、作る部分に対しての向き合い方や感情の持ち方が変化してきているのをリアルな視点で聞けて良かったなと思います。 また AI が書いてきたものをレビューするスキルがすぐに必要になるなど、要求レベルの上昇も感じました。

あえて手で書いてみるのも手かもしれませんね。理解して役に立つという技術的な実感も大事なのかもしれない。

生成AI時代におけるLTの在り方

この LT のためだけの準備がとんでもなくすごかったです。 現地じゃないと味わえないおもしろさでしたね。

摂理と合理の肉体改造 — AI時代の減量を支える観測・制御・継続

資料公開されていました。 https://x.com/kiyosick/status/2080932565830308032

6か月くらいでいったん減量が止まりやすいというのは知らなかったです。知らないことがいっぱいだな…。 AI を活用してもっと目的を達成するために知っておかなければいけない知識を整理しておかないとなと思いました。

運動、瞑想、睡眠、野菜350g の大事さ。

進捗をなんとかする技術

https://blog.hanhans.net/2026/07/26/dai-kichijojipm-2026-lt/

やるしかないですね。やるしか…。

論語・武士道・産業革命から見る かわるもの、かわらないもの

資料公開されていました。 https://x.com/ici_mici/status/2081375345606009264

第一次産業革命、第二次産業革命は同じ革命だといっても、労働者にとってうれしいものであったかどうかは大きく違うように思われました。 第一次産業革命、本当に悲惨な歴史の一部を感じる。 逆に第二次産業革命ではさらに多くの仕事が生み出されて、非常に良い面が多かったように思います。これを目指したいですよね…。

そのうえで日本人らしさ? というものを考えると自然、意気、諦念みたいな考え方が出てくるようです。 なんかこの辺りは個別のものをしっかりと学ばないと理解が仕切れなさそうな気がするので、そのうち向き合ってみようかな。 五常、七つの徳目も確かに当たり前に存在するような価値観であるものの、こういったものが昔あったみたいなのは全然意識してなかったですね。 興味深いし調べたい。最後は人の良さ、というのはあるものの、日本で働くうえでひとの良さを言葉にするなら過去の考え方を追ってみるのも一つなんだろうなぁと思いました。

また楽器を弾くという話から、構造の理解の話もありましたがこれも昔から詳細と全体の行き来が大事ということで、ソフトウェアにつながってくるものがありました。

まとめ

発表内容が多岐にわたり、技術的なものもあれば、技術的な概念的なもの、またAI時代とどう向き合うかという話も多かったように思います。 ソフトウェアエンジニアとして生きていく上でのヒントというか考え方も多く得られたので、今後に生かしていきたいです。

ポッドキャスト… とかは悩みますね。声を少しだけ残してみたいというか。