本書は著者で編集者の伊藤ガビン氏が、59歳から61歳までに渡る、老いに勢いがあり、やたら活発に老いている状況を客観的に見つめ直した珠玉のエッセイ集です。

いつか直面する老害問題
老害になる年齢はあるのか、職業によってその差はあるのか、旬の時期、いきいきと活躍できる老害は50代なのか？ 自分が老害であると考慮しつつ、気をつけざるを得ないという実感。すでに身に覚えのある方も多いのではないでしょうか。

身体的変化
この物語は「老眼」を老いと自覚することで始まり、さらには身長が縮み、眉が伸び、おじいさんの動きになった！というおじいさん感について人間行動学者の細馬宏通氏と午前2時まで対談する様子が描かれています。
また、見えない老いの一つ、信じられないほど手がカサカサするに対して、めちゃくちゃ水を飲んで克服したグラフックデザイナーの松本弦人氏の逸話も必読でしょう。

老いを書くことで、うっすらと見えてきた老いのヤバさランキング第一位とは何なのか？ 昭和のOSはアップデート対象外なのか？ 最終話 「逃げ切る」という考え方 についても、ぜひこの本を手にとって考えてみてください。

今まさに老いている方、老いのベテラン、そしてこれから老いようとする方、これら全ての方々が活躍する現代のソフトウェア業界にお勧めできる、たいへんカジュアルな老いの入門書です。

"「おじさんからの卒業旅行中でしょ。まだ『老い』が来てないから、そんなもん書けるんだよね」"
本書 センパイの話より 戸田誠司氏談

Pヴァイン刊 著者：伊藤ガビン 編集者／京都精華大学メディア表現学部教授（PC黎明期の雑誌LOGiN編集者であり、パラッパラッパーシリーズ・動物番長のシナリオライター、どこでも編集会議のポッドキャスター）

これは挫折と成長のイテレーションを繰り返しながらアメリカンフットボールの頂点を目指す、王道のスポ根ファンタジーコミックスです。

Getting started
まずおもむろに3巻まで読みましょう。舞台は関東の私立高校で、連載開始は2002年です。様々な場面で折りたたみ式の携帯型端末が登場しますが、これは携帯電話といって無線式の電波網を使用して通話や電子メールを送ることができる物でした。ブラウン管型のTVなどもキーポイントになっていますね。そして第3巻第20話で序章が終わり、チーム・泥門(でいもん)デビルバッツの物語が始まります。
もしよろしければ、引き続き6巻まで読み進めてみましょう。どうですかね？ すでに皆さんも泥門デビルバッツの一員として、大小さまざまな挫折と成長のイテレーションを回し、努力と友情と勝利の追体験をしてきたのではないでしょうか。そして、ここからはですね、さらにスコープが広がっていきます。もはや人前で読み進めるのは諦めましょう。ハンカチを準備して13巻まで進みます...

本書はあくまでフィクション中のフィクションであり、完璧なファンタジーです。しかし、このため、アメリカンフットボールの詳細な知識がなくても、登場人物と一緒に物語を追っていける構成になっています。
類稀なる才能の存在、個人としての挫折、時間との戦い、チームでの成長、これらの場面は様々な観点でソフトウェア開発の現場にも照らし合わせる事ができるのではないでしょうか。
最先端の技術を切り開いていく、迷い多き技術者の心を支えるための物語として、ここに本書を推薦致します。

集英社刊 ジャンプコミックス全37巻
作画：村田雄介 原作：稲垣理一郎(Dr.STONE、トリリオンゲーム原作者)

「コードレビューで、先輩に”こういうテストも書いた方が良いよ”と言われることがある」
──思い当たるフシがあるなら、是非オススメしたい1冊です。
(いずれにせよ「テストをちゃんと書く」観点でのレビューをしてくれるのは素敵な環境！と言えるかも知れません)

テストとは「正しいことを保証する」「エラーがないことを確かめる」という ものではない と説明されます。
本書によれば、 テストとは, エラーを見つけるつもりでプログラムを実行する過程である.(P6) ものです。
すると、良いテストとは「最大限の効率で、エラーの発見に与するもの」とも言えるでしょう。
『ソフトウェアテストの技法』は、まさにそのための道への入門を助ける1冊です。

持続性の高いテストの書き方、壊れにくい(あるいは「ちゃんと」壊れる)テストの書き方を教えてくれる本や、
テスト駆動開発のような設計のツールとして自動化テストを利用するための本は、英語でも日本語翻訳でも、本当に充実してきたと感じています。
それとは別の、あるいはもっと本来的な意味での、テストに自身を持つための手助けを求めてはいませんか？そんなあなたに、きっと役に立ちます。

執筆年代が少し古いので、文体や語彙に関して多少の読みづらさを感じる部分もあるかも知れません。
それでも、第2章「プログラム・テストの心理学と経済学」・第4章「テスト・ケースの設計」・第5章「モジュール(単体)・テスト」は、
今も古び図に必ず役に立つし、一読に値する内容だと信じています。

しかも、この本は比較的ページ数も割と抑えめです！！とてもお得ですね。

日々、トラフィックを捌き、バグと戦い、複雑な仕様をコードに落とし込む私たちバックエンドエンジニア。時に「動いて当たり前」とされ、その苦労や創造性が見過ごされていると感じることはないでしょうか。

​本トークでは、アメリカの思想家アイン・ランドの代表作『肩をすくめるアトラス』を紹介します。この物語は、「世界を支えるアトラス」＝「知性によって価値を生み出す者たち」が、理不尽な搾取に対して「肩をすくめる（ストライキする）」ことで、世界がどうなるかを描いています。

​現代の「アトラス」は、まさにエンジニアです。
技術に命を注ぐこと、良いプロダクトを作ろうと足掻くこと、そしてイノベーションを追求することは、単なる労働ではなく、人間として最も尊い活動（Noble Activity）であるということを、この本を通して再確認しませんか？

​明日のコミットに、確かな誇りを宿すための一冊です。

まれにある深夜メンテは遠足気分(?)で楽しかったりしますが、頻繁にあると生活リズムを崩してしまいますし「もし未知のトラブルに遭遇して長時間サービスをダウンさせてしまったら・・・」などの心配も尽きません。

本トークではメンテナンスを日中にやるための交渉術や実現するためのテクニックについてご紹介します。

想定観客

• 深夜メンテをしたくない、部下・同僚にさせたくない人

お話しすること

• 深夜メンテをしない合意形成
  • 希望を伝え続ける、起きたトラブルをダシに使う、お金の話をする
• 日中にメンテをするための考え方とテクニック
  • 影響範囲とリスクを明らかにする、障害を避けるべき時間を明らかにする、ダウンタイムを許容する、ロールバックに備える、後方互換性を確保する

AIをプロダクトに組み込んだとき、従来なかった壁にぶつかりました。実行する度に結果が揺れる非決定論的な出力に対して、どうテストすればよいのか。完全一致を求める従来のアサーションは使えず、人の目での検証には時間がかかり、バリエーションが増えるたびにデグレチェックが困難になるという問題です。

このトークでは、スプレッドシートへの出力が期待通りかどうかを検証するというケーススタディを取り上げます。一方はAIが出力するシート、もう一方は期待値（正解）を示すシートです。出力が予測できないためプログラマティックに検証できません。一方で、AIに検証を丸投げすると精度に不安があります。AIとプログラムの強みを組み合わせることで比較精度の安定と、不一致セルのハイライトのような検証利便性の向上も実現しました。

ケーススタディを通じて、LLMと向き合う際の発想について整理することも目指します。

GNU socialという2008年に生まれたPHP製のX/Twitter系のマイクロブログ型の分散SNSのフリーソフトがある。いろんな歴史的経緯があって、元の著者の手を離れ、複数のメンテナーを転々として、最終的に見捨てられたプロジェクト。
誰にも相手にされず、PHP経験ゼロ、Webアプリ開発経験ゼロ、人なし、金なし、コネなし、スキルなし。ないないづくしで、あるのはハンデだけの絶望的状態。ただの1ユーザーだった私が、この状態から、ここ何年かかけて、最終的にプータロー (無職) になって、この子の自称責任者になった。
ここまでのGNU socialで世界を変える物語の一番重要な始まりの序章を話す。

テクニカルな話は一切ない。あるのは泥臭い話だけ。というか、小手先の技術はネットや対話AIにきいたほうが人より詳しくて正確なことが大半。そんなことよりもっとクリティカルで重要なことがある。何をするか？方向と戦略が全て。

掃いて捨てるほどいるPHP技術者、IT技術者、人間の一人として、自分が世界でやりたいこと、すべきことって何？世界で自分しか理解できていない状態で、サラリーマンとして、組織に所属していて、しがらみ、忖度、組織の論理にまみれた中で、責任取れない立場で、組織のいいなり状態で、本当にやりたいこと・すべきことを邪魔されずにできるのか？
華やかな世界、規範、キャリア、組織・業界・コミュニティー・仲間からの評価・共感。所詮他人が勝手に作った基準。寄付、スポンサー、支援。基準や周囲の共感、理解、土台前提。恵まれた「普通」だからできる。他人・環境依存で弱すぎる。自分しか理解できないのだからどうでもいい話。

誰の力も借りず一人で自立。何のしがらみもなく、誰にも邪魔・指図を受けない「無敵の人」。それがプータロー。
言うのは簡単だがはたしてどうやる？気になったあなたを会場で待ってる。

チームに途中参加し、初見のアプリケーションを前にして「これ、どこから読めばいいんだろう」と立ち止まった経験はありませんか？

私は、技術サポートという仕事柄、すでに稼働している PHP アプリケーションに関わる機会があります。
中には長い歴史を持ち、コード量も多く、当時の設計意図がドキュメントとして残されていないケースもあります。

現場に入ると、こうしたアプリケーションをキャッチアップしていくのですが、
その様子を見ているメンバーの方から「どのようにキャッチアップすれば良いですか？」という質問を受けることがしばしばあります。

重要なポイントを一つ挙げるなら、すべてを理解するのではなく、必要となる箇所を効率よく把握することです。

本セッションでは、特に日々既存のアプリケーションのキャッチアップに課題を感じている若手の方に向けて、
私自身が実際に意識している考え方や、見るポイント、活用している手段などを具体的にご紹介します。

チームで既存アプリケーションの知識をシェアする方法を模索されている方にも言語化のヒントとして持ち帰っていただけると嬉しいです。

クラウドインフラコストを成果報酬型で削減してきたDELTAが新たにPHP/Rubyを第一弾としてバージョンアップの代行を始めました。
コンセプトとしては生成AIを活用して、半自動的にVersionUpができる状態を目指していますが、サービス黎明期の今は1プロジェクトずつ、手作業で泥臭く調査や検証、実行を重ねています。
今回は数あるプロジェクトの中でも、CakePHPの2系を最新バージョンまでアップデートする道のりについて語ります

取り上げる内容

• バージョンアップにおける生成AIの利用方法
• テストのカバレッジが低いアプリケーションのバージョンアップ方法
• (特に)Cake2からCake3へのバージョンアップ時の変更点の多さ
• Cakeのドキュメントのあいまいさと突破した方法
• AIを使って効率化（PRの高速化）を果たしてもレビューで詰まってしまい、プロジェクト自体のアウトカム生産性が高まらない際に実施した方法
• お客さんへ新しいバージョンのお作法やメソッドの変更などの共有

想定

• PHPで構成されたアプリケーションを開発しているエンジニア
• バージョンアップに向き合っている / まだ機会に遭遇していないが、具体実例から準備すべきこと・事前検討すべきことに興味関心がある方

OSS コントリビュートに憧れつつも、「何から始めればいいのか分からない」「英語やお作法が不安」と感じ、なかなか一歩を踏み出せずにいました。
そんな中、「AI とともにならコントリビュートできるのでは？」という考えが思い浮かび、実際にやってみた結果、見事コントリビュートを果たしました！

本トークでは、「AIを相棒に3日間でOSSにコントリビュートする」という挑戦についてお話しします。
AIを活用することで、心理的・技術的なハードルがどのように下がったのかを具体的に共有します。

OSS に貢献してみたいけれど踏み出せていない方の、最初の一歩を後押しする LT です。

レビューでつい「なんでこうしたの？」などと質問して、責める意図はないものの空気が気まずくなった経験はありませんか？
このLTでは、心理学をもとにした質問の技術を活用し、レビューを詰問ではなく「対話」に変えるためのヒントをお届けします。

「意図を引き出す」「気づきをもたらす」といった観点から、よくあるNG質問の言い換え例や、相手が話しやすくなる質問の工夫を紹介します。

• 話すこと
  • 相手を詰めずに意図を引き出す質問の例
  • NGな質問表現の言い換え例
• 話さないこと
  • レビューすべき観点そのもの

レビューの空気を気にする方に届いてほしい内容です。
少し変えるだけで大きく変わる質問の仕方を一緒に見てみませんか？？

Infrastructure as Code（IaC）とは、インフラ構築をコードや設定ファイルで定義し、再現性や自動化を実現するプラクティスです。IaC によって運用コストの削減やヒューマンエラーの防止といったメリットを得られる一方、導入初期の教育コストや特定メンバーへの依存といった課題も指摘されています。

私たちの組織では、2023年9月に既存サービスの稼働環境を見直した際に、AWS CloudFormation を用いて IaC を導入しました。導入からおよそ2年が経った現在も保守運用しています。

本セッションでは、はじめに IaC に関しての一般的な考え方やメリット・デメリットを解説します。続いて、私たちのチームでの導入に際しての実践内容や切り替えてからの運用の経過について共有します。最後に、IaC を導入してからのチームでの工夫や出てきた課題について紹介します。

IaC 導入での課題を感じられている方だけでなく、IaC 未導入の方や馴染みのない方にも、私たちの実体験から得た知見がヒントとなれば幸いです。

LaravelのQueueは便利ですが、Queueワーカーが裏でどのように動いているのかを知らない人も多いと思います。

ワーカーが内部で何をしているかが分かると、詰まり・遅延・失敗の原因に当たりを付けやすくなり、運用やデバッグがしやすくなります。

このトークでは、ライブコーディングを中心に、LaravelのQueueワーカーをゼロから（ただし必要最小限に簡素化して）実装しながら、php artisan queue:work が実際に何をしているのかを順番に解説します。

「Queueは使っているけれど中身はよく分からない」という人が、処理の流れを自分の言葉で説明でき、トラブル時に切り分けの視点を持てるようになることがゴールです。

基本的な情報

私たちのプロジェクトでは、Lumen FrameworkとCodeception / Specifyを採用していましたが
Codeception / Specify の更新が終了してしまいました。
移行先は pestphp を検討していましたが、１万を超えるテストケースを具体的にどうやって移行するのかが課題になっていました。

これらに、この１年でどう立ち向かったのか、どのように方針転換をしたのかをお話しします。

お品書き / 得られること

• codeception / specify についての簡単な説明
• 終わりの始まり：テスト用フレームワークの EOL
• Pest への移行
• Rector による置換の試みとその問題点
• 技術の進歩 Agent Skills という光
• まとめ

できるエンジニアは高額の報酬をもらって当たり前、と思っていませんか。
エンジニアは能力の差が大きいので、報酬の幅も大きいと言われています。
ところで、「能力」とは何でしょうか。技術力？本当にそれだけでしょうか。

本トークでは、一般的に受け入れられている能力主義の考え方を批判的に見直し、
概論にとどまらず、現在エンジニアが置かれている状況を整理していきます。
その上で、エンジニアとそのチームにとってより好ましい考え方、ふるまい方を探求します。

気が付けばいつの間にか「能力」にとらわれすぎていませんか。
新たな視点を提供することで、すこしでも解きほぐすお手伝いができたらうれしいです。

「i18n」や「k8s」など、長い英単語を数字で省略する語をヌメロニム（数略語）と言います。

PHP の標準関数でも当たり前の様に使われているヌメロニム。Web 開発者であれば毎日のようにどこかで目にするこれらの言葉ですが、いつの間にか自分の知らないヌメロニムが当たり前のように使われていたり、その意味を理解したつもりが雰囲気だけで使っている……そんなことはありませんか？

この LT では我々PHP開発者の身の回りに溢れるヌメロニムをクイズ形式で出題しつつ、その意味をちょっとだけ深掘りしていきます。

あなたも今日からヌメロニムマスター！

あなたの担当するプロジェクト、変更が難しい「モンスター」になっていませんか？

機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、オブジェクト指向設計の基礎であるSOLID原則への理解不足や誤解にあるかもしれません。

SOLID原則はソフトウェア開発において高品質で保守性の高いコードを書くための重要なガイドラインですが、やたら難しい言葉が並んでいるせいで理解が難しかったり、誤解が広まってしまっている面があります。

本トークでは、SOLID 原則に含まれる下記の5つの原則について、アンチパターンやPHP での実践的な例を交えながら解説し、その活用方法や得られるメリットについてお話しします。

• 単一責任の原則
• 開放閉鎖の原則
• リスコフの置換原則
• インターフェース分離の原則
• 依存性逆転の原則

このトークを聞けば、難しかったSOLID原則が「いつでも使える便利な武器」へと変わり、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

こんな人に向けて話します

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則、聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人
• SOLID 原則、理解しているけどどこまでやればいいのか悩んでいる人

deptrac、便利ですよね。
設定ファイルを書いて実行するだけで、アーキテクチャのルール違反を検出してくれる。神ツール。

内部では、一体どんなことが起きているのでしょうか？
考えてみると、私はdeptracのことを何も分かっていなかった──
依存関係をどう収集しているのか。グラフとしてどう表現しているのか。ルールチェックはどうやって…？
「こういう情報を集めて、上手く使っているんだろうな」と想像してみても、実装方法まではピンと来ません。

そして思ったのです。
自分で読んで作って、動かしてみよう！
そうすれば納得感が増すに違いありません。

今の時代、知らないコードを読むのにAIの力を借りないなんて、 嘘 ですよね！
少し前なら「読み解くハードルが高いぞ…」と感じていたものも、挑戦しやすくなりました。
今回は、その力を存分に借りながら、
「どういう技術要素が詰まっているのか」「どういう流れで処理していくのか」をひも解いて、
「deptracもどき」を動かすところまで進めます。

やること

• ステップバイステップで「コードリーディングと小さなコードの実装」を進める
  • 「中身を読む〜動かしてみる」までを、40分で追体験できるように
• deptracの基本的な機能（＝「依存先の解決」と「ルールチェック」）の実装

お届けすること

• 「実際にこんな感じでコードリーディングを進める」という雰囲気
• deptracの内部実装についての知識
• 自分にもできそうだな！という気配

対象者

• コーディング用AIを使いながら、複雑なコードを読むことにチャレンジしてみたい方
• 「雑に作って学ぶ」方式の勉強法が好き、または興味のある方

とあるカンファレンスの廊下で、こんな会話が聞こえてきました。
「その◯◯ライブラリは、コンストラクタを通さないでインスタンス化しているんですよ」

決してテスト用のライブラリでもなく、メタプログラミング用のユーティリティでもなく、
Doctrine ORMの話です。
Entityとして定義したクラスを用いて、DBから取得したデータを元にオブジェクトを作る時、コンストラクタを通さないのです。

私自身、過去にその挙動を知らずにハマってしまった事もありました。
しかし、よくよく考えてみると、
「EntityはORMから独立して存在できるようにする」世界観と、
「DBのカラムとPHPオブジェクトのプロパティのマッピングは、Attiribute等の情報で管理する」作法によって、
Doctrineは「コンストラクタを、ユーザーが自由にできる土地として解放する」という強力なパワーを授けているようにも感じます。

「どんな場面で、こんな設計思想が”アリ”になるのだろうか」を考えてみると、面白いのではないでしょうか。

このLTでは、
「そもそも、どんな技術で”コンストラクタを使わないインスタンス化”を実現しているのか」
「その方法が、何をもたらすのか」
について、考えを共有します。

「新しいクラスやメソッドが定義されたから、旧い方は廃止していきます！」
そんな時に、”Deprecated"を示しますよね。

PHPを使っていく上で、いくつかの方法があります。
「どうやって廃止したいか」によって、その良し悪しが変わるでしょう。
そう考えると、使える武器を整理して増やしておくのは、役に立つかも知れません。

このLTで、複数の”Deprecated"(&& ちょっと違うけど「禁止」をする)の術を紹介します

1. PHPDocの @deprecated tag
2. trigger_error / E_USER_DEPRECATED
3. \Deprecated アトリビュート
4. phpstan-deprecation-rules
5. class_alias と1〜2を組み合わせて新クラスへの移行を促すやつ
6. PHPUnitで --fail-on-deprecation を使う
7. disable_functions