本書は、CPUが電気回路としてどのようにプログラムを実行しているかを解説する「CPU入門書」です。
CPUを作るチュートリアルとしては論理ゲートからOSまで自作する nand2tetris が有名ですが、本書は10個の汎用ロジックICで作るごくごくシンプルな4ビットCPUを題材に解説されているので、より「入門」に近い構成になっています。
プログラミング歴30年を超える私ですが、本書に出会うまでCPUがどのようにプログラムされた通りに動作しているかを理解していませんでしたし、それ以前に考えたこともありませんでした。
このトークではそんな私が本書を読んで受けた衝撃をみなさんにも共有します。

森見登美彦氏の『太陽の塔』は、元・恋人である水尾さんを、日々のスケジュールから住んでいるマンションに至るまで研究し続ける「私」の日々を描いた作品である。
偏屈な大学生の阿呆なやりとりの中に横たわる、どこまでも深く、深く落ちていくような失恋。
それがまるで人生のすべてだと言わんばかりのほの暗い感情は、果たして彼の中では人生そのものなのだ。

この小説を読むたびに鮮明に失恋の感情を思い出すことができる。そういった点で私はこの小説が大好きだ。
「あの時ああしていれば」「こうだったんじゃないか」「あれだってそうだ」「これだって」。
主人公である「私」のじわっとした感情は、あまりに等身大で、リアルで、青く、そして愛おしい。

また、これだけの感情を浴びて思うのは、こういった負の感情で満たされた一日も、のんびりご飯を食べたりテレビを見たりして何気なく過ごす一日も、同じ人生の「一日」という事実である。
私たちは日々をどれだけ自覚的に過ごせているだろうか？
やや拡大解釈ではあるが、日々を見直すきっかけとしてもおすすめの本作を紹介します。

野﨑まどによる『タイタン』は、至高のAIによって社会が平和に保たれた未来を描いた作品です。
舞台は2205年。2048年に誕生したタイタンAIによって、人間は「労働」から解放されています。
そんな時代に、主人公・内匠は今や失われたはずの「仕事」を依頼されます。
依頼内容は、突然働けなくなってしまったタイタンAI「コイオス」のカウンセリング。
内匠とコイオスのやり取りは、次第に「仕事」とは何かという話につながっていくわけですが…。

現実の2026年に生きる我々エンジニアは、いつの間にか当たり前のように生成AIを使っています。
しかし、問いかけてみたいのです。AIに指示を与え、AI同士で相談をさせたりして、
我々は本当に仕事をしていると言えるのか、と。あるいは、仕事の実感を得られているのか、と。
あらためて「仕事」とは何か、自分自身にとってどう位置づけられるものなのか、
見つめ直すきっかけになりうる1冊として、ぜひ手に取っていただきたいと思います。

本作は、交通系ICの暗号化技術を専門とする架空の企業「ジェイ・プロコトル」に勤める主人公が、香港を中心としたアジアの街並みを舞台に陰謀の渦へと巻き込まれていくハードボイルド小説です。
東南アジアへの交通系ICカード営業や、ICチップの暗号化技術（AES）とそれにまつわる特許の攻防といった技術的要素を軸にしながら、酒、煙草、カジノ、闇犯罪といった退廃的な世界が交錯します。
さらに本作の大きな特徴は、シェイクスピア四大悲劇の一つ『マクベス』になぞらえた、運命的で不穏な物語が中心に据えられている点にあります。
ハードボイルド小説やミステリ小説を愛するエンジニアに、ぜひ手に取っていただきたい一冊として、本作をご紹介します。

『未必のマクベス』（早瀬耕 著／早川書房）

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

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

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

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

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

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

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

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

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

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

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

原著副題：Exposing Fraud, Bias, Negligence and Hype in Science
(科学における詐欺、バイアス、過失、誇張を暴く)
"科学は間違いなく人間の活動であり、従って人間の欠点が刻み込まれている。"
本書 エピローグより

ポイント１
熱狂的な脚光を浴びた定説は、後世のより公平で正確な実態調査によって覆されることがあります。
「パワーポーズ」2012年にTEDトークで提唱され、史上2番目に多い視聴回数を記録しました。オンラインで目にした方も多いのではないでしょうか。
さらに「スタンフォード監獄実験」「成長マインドセット」など、これらの有名な実験結果について、のちの検証で再現性が見られなかった例が記されています。

ポイント２
この本は様々な理由により世に出た偽りの科学を暴くだけではなく、なぜそのような事が起こったのか、誤りを産む環境、そしてそれらを是正する取り組みに関して踏み込んでいます。
カリフォルニア州史上最大規模の災害復旧作業で発生した「逆インセンティブ」では何が起こったのでしょうか。

ポイント３
本書からソフトウェア開発者として省みる点はなにか。
論文発表システムという視点から科学の直面する課題を知ることで、ダイナミックに移り変わるソフトウェア開発の未来に備えることができるかもしれません。

"科学的知見に直面したとき、あなたには選択肢がある"
本書付録 科学論文の読み方より

ネット・ゲーム依存症対策条例が施行された市民として本書を広く社会に推薦します。

ダイヤモンド社刊 翻訳：矢羽野 薫、著者は元King's College Londonの研究者で、現AnthropicのResearch Comms lead を務める Stuart Ritchie

『Rubyソースコード完全解説』、通称『Ruby Hacking Guide』は、Ruby 処理系のソースコードを上から下まで網羅的に解説するという稀代な書籍である。

Ruby に限らず、そもそも「あるソフトウェアのソースコードを解説する本」という例自体が非常に少ないと言ってよいだろう。

私が言語処理系に興味を持ったり作ったりするようになったのはこの本の影響である。中学生の頃はゲームや小さなデスクトップアプリケーションを作っていた私が、高校 3 年間を自作の言語の設計と開発に費したのは、確実にこの本が原因である。

この本の執筆当時、Ruby は 1.7.3 (2002-09-12) であった。そこから 20 年以上の時を経て、Ruby はバージョン 4 となった。かつて抽象構文木を辿って実行していた評価器は YARV に始まる VM ベースの実行へと置き換えられ、JIT による機械語への変換さえもおこなわれるようになった。構文解析器すらもリライトされ、書籍中の解説と今の実装とでは乖離点も多い。

そのような状況で、今この本はどのような価値を持つのか？

現在に至るまでの私の興味関心領域を決定付けた本書を、是非紹介したい。

なお、本書は紙では絶版しているものの、当時から全文が Web 上で無償公開されている。したがって、古い書籍であるものの、現在も極めて容易にアクセス可能である。

https://i.loveruby.net/ja/rhg/book/

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

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

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

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

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

みなさんの人生を振り返った時、おおきな分岐点がいくつかあると思います。
そして、ほとんどの人はその分岐点の中に「進路（進学先）選択」があるのではないでしょうか。

私が高校受験をするとき、大いに影響を受けたのは漫画『桜蘭高校ホスト部』です。
高校卒業後は大学に進学しましたが、あの高校に通っていなければ大学進学先も変わっていただろうことを思うと、『桜蘭高校ホスト部』は私の人生に最も大きな影響を与えた作品といえます。

『桜蘭高校ホスト部』が好きすぎて漫画の編集者になりたかった時期もあります。
しかし『桜蘭高校ホスト部』の出版社しか考えられず、就活にやる気が出ないまま色々あってエンジニアとして働く今があります。

作中に出てくるセリフや価値観で、今でも大切にしているものがあります。
「人生何事も経験」「勉強ばかりしていても頭でっかちになるだけで人に寄り添えることはできない」
人の個性を尊重する心も『桜蘭高校ホスト部』で学びました。

今回のトークでは、実際に進路選択の時にどのような影響を受けたのかやどんな時に上記のセリフを思い浮かべているか、どのような価値観を持つようになり、それが人生のプラスになっていると思うかについてご紹介します。
このトークを聞いてみなさんが本を手に取ってもらえると嬉しいです！

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

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

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

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

・本屋で探したけれど、聞いたタイトルと違っていて、見つからなかった本はありませんか？
・薦められて読んでみたものの、「悪くはないけど、そこまで刺さらなかった」という本はありませんか？
・一方で、その本をきっかけに仲間が増えたことはありますか？
・仕事がうまくいかないときに何度も手に取ってしまう本はないでしょうか？

私にとって『Fearless Change』は、まさにそんな特別な一冊です。
ただし、最初から特別だったわけではありません。正直に言うと、最初に一人で読んだときは、その面白さがよく分かりませんでした。書いてることは当たり前の内容に感じ、自分の仕事や日常とどうつながるのか、ピンと来なかったのです。

転機になったのは、この本を「誰かと一緒に扱う」ようになってからでした。読書会や勉強会で、異なる立場や組織の人たちとパターンについて話し合い、ワークショップや発信を通じて実体験と結びつけていく中で、本の意味が少しずつ立ち上がってきました。本の内容を語るたびに、自分自身の考え方や、組織との向き合い方に小さな変化が起きていったのです。

読書会では、同じパターンでも置かれているコンテキストが違えば解釈も使い方も変わることに気づきました。何度も本を読み返し、勉強会の題材として扱うたびに、新しい視点や問いが生まれます。また、この本は変革のためのハウツーであると同時に、自分自身を見つめ直し、立ち止まるための「ケア」としても機能してきました。単体のパターンを使うだけでなく、複数のパターンを組み合わせることで、状況の捉え方が変わる体験も重ねてきました。

この本がなぜ読み返され続けるのか、なぜ人と人をつなぐのか、その面白さを実体験とともに紹介します。
参加者の皆さんが「自分にとっての特別な一冊」と向き合うきっかけになれば幸いです。

弊社では物流Techとして物流業界の様々な課題を解決しようと奮闘しています。
今回はその中でも注文情報周りを扱う処理が肥大化してしまい、変更がどんどんと困難になってしまった話をします。
注文情報というのは各ECプラットフォームから取得される情報で、どこに配送するかや、なにを配送するかなど多くの情報を持っています。
また、配送済みかどうかや、そもそも弊社倉庫から出荷するのかなど、更に内部の状態を複数持つことになります。
DDDライクな設計で実装を進めていましたが、最初は保存処理などシンプルなもののみをOrderRepositoryとして実装していたので、特に問題はありませんでした。
しかし、どんどんと機能仕様が膨れ上がり、注文が持っているべき状態というのもそれに伴って増えていきました。
注文の状態を更新するために他のテーブルの状態を見ないといけなくなり、そのロジックをトランザクションの中に入れようとした結果記述量が増えたり、
注文の状態が変わったことをeventで通知するのをすべてRepository層でやったことで抜けが発生したりと、だんだんとOrderRepositoryが太っていきました。
また複雑になっていくことで、機能追加するたびに他の機能の変更を気にしなければいけない状態になっており、同時に機能開発をしているとコンフリクトと戦う時間が増えてしまうという問題もありました。
そんなOrderRepositoryとどうやって向き合って、どうやって綺麗にしていったかの話をしていきます。

私たちは普段、当たり前のように「品質」という言葉を使っています。しかし、その言葉の定義や成り立ちを深く意識したことはあるでしょうか？

実は日本において「品質」には、ISO（国際標準化機構）という規格で定められたものと、TQM（総合的品質管理）という体系の中で使われてきたものという、2つの大きな文脈が存在します。これらは相互に関連していますが、捉え方は異なります。

本セッションでは、書籍『マネジメントシステムに魂を入れる』を題材に、特にTQMにおける「品質」の世界を紹介します。

本書が教えてくれるのは、単なる用語の解説ではありません。「品質」という概念がどのように生まれ、体系化されてきたのか。そして「品質管理（マネジメント）」とは、単に表計算ソフト等で数値を記録することではなく、チームや組織としてどのように対象を「コントロール」していくかという、より動的で深い営みであることです。

我々はエンジニアとして、チームとして、品質をどう扱い、どう実装していくべきか。
そのヒントが詰まったこの本を通して、PHPerの皆さんに「品質」という世界の奥深さと面白さを体感していただきたいと思います。

あなたがプログラミングに夢中になった原体験は、何ですか？
私にとっては、WordPressを入れてみて、テンプレートに少しだけ echo を書いてみて、表示内容が変わる様子は奇跡でした。

そこから随分と時が経ち、相変わらずプログラミングは楽しすぎますが、
どうしても経験を積むと「キレイな設計」「誰でも読めるし書き換えられるコード」を探求しがちです。

良いコードを追い求めるのは刺激的で、他にないくらい楽しい。
その一方で「無邪気に何かを作る」の楽しさも失いたくない！

そんな日々の中で出会ったのが、『雑に作る 電子工作で好きなものを作る近道集』です。
PHPはおろかプログラミングの本でもありません。
むしろ、『プログラミングなしで作品を作ることもできるんだ』という副題を冠した節すらあります。
そして、私は電子工作を嗜んでもいません。

たまたま著者のファンだからと手に取った書籍でしたが、
それでも、何かを作って動かして楽しんでいる立場にある自分にとって、
この本にはとんでもなく元気をもらいました！

見様見真似でも良い。ツギハギでも良い、笑っちゃうくらいみすぼらしい外見でも良い。
それでも「自分で動かした喜び」って掛け替えのないものになりますよね？
そんな気持ちを思い出させてくれる1冊です。

取り上げられている内容は、
「どんな材料が使いやすいか」「どこで買えばいいか(百均やらハンズやら秋月電子やら)」「配線の簡単な方法」といった具体的なTipsが中心ですが、
『盛るとテンアゲ⤴な素材』『気軽に分解してみよう』などは、作るのを楽しむ人・何かを始めようとする人への深い敬愛を感じて止みません。
これらは、ソフトウェア趣味人の我々にも語りかけるものがあります。

そんな「すごい元気をもらえた」本を紹介します。
自分の楽しみのためのものづくりを再開しませんか？

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

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

想定観客

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

お話しすること

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

「ハイコンテキスト」「ローコンテキスト」「言語間距離」。
これらは、日本語や英語といった自然言語を語る際によく用いられる言葉です。
言語が持つ"性格"を表す概念でもあります。

では、私たちのPHPはどうでしょうか。
文法があり、慣習があり、文脈によって意味が補われる。
PHPもまた言語である以上、「言語としての性格」を持っています。

近年、生成AIの普及によって、エンジニアの言語環境はより複雑になりました。
日本語で考え、英語を交えてPHPを書き、複数のAIと同時対話する。
このように異なる性格を持つ言語の行き来が、いまや日常となっています。

しかし、この切り替えは人間の脳にとって、時に無視できない認知負荷となります。
大AI時代となった今「以前より集中できない」「脳が疲れる」と感じる人が増えているのも、
この言語の切り替えによる負荷が、気付かないうちに積み重なっていることが原因かもしれません。

本セッションでは、技術選定や言語選定の是非は扱いません。
PHPを言語学の視点から捉え直し、AI時代の「脳疲れ」はどこから来るのか、
そして日々の思考を少し楽にする対策についてお話しします。

本セッションの対象者

• 最近なんとなく疲れや集中力の途切れを感じている人
• PHPをいつもとは少し違う視点で見てみたい人

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

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

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

"ジョシュアツリーの法則"を知ってますか？
「名前を知ればそれを認識できるようになる」「名前を知らないと認識できない」といった現象のことです。

我々エンジニアの身の回りには様々な現象があり、中にはみんなが経験したことがあるものも多数存在します。
そんな「現象」や「事象」の中にはあまりにも名前が付けられ、事象の解消や共有が行われているものがあります。
名前を知ることは認識すること！
この発表を聴いてそんな""あるある""の名前を知り、事象を正しく認識して、次に生かしましょう！

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

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

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

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