コード、ちゃんと消していますか？

普段の開発では「コードを書くこと」にスポットライトが当たりがちである。新機能を作る、バグを直す──どちらもコードを書いて価値を生み出す行為だ。
だからといって、「コードを消すこと」が不要になるわけではない。

コードを消すことは、コードを書くことよりも難しい問題もある。

ここで門戸を閉ざしてしまうのは些かもったいない。

ソフトウェアを構成するソースコードを消すことに関しては、著者の ｽﾞｯ友であるGenki Sano氏の資料を参照されたい。

<SpeakerDeck slideId="1754cdad63484007b189b66aa3bec9ac" />

ソースコードを消すことは難しいが、テストコードを消すことはどうなのだろうか。

そんな疑問に対して、ど真ん中で向き合うために、今回は「消しやすいテストコード」について考えてみたい。

## テストコードを消す必要性について

まずはここに切り込まねばならないだろう。書くことすら躊躇われることが稀によくあるテストコードをなぜ消す必要があるのか。

大前提として、コードは少なければ少ない方が良い。読む量が減れば、理解と変更にかかるコストも下がるからだ。
そういう意味でテストコードもソースコードも消したほうが良いだろう。

そして、テストコードはソースコードと比べて圧倒的に消しやすい。本番環境で動くプロダクトに影響がないため、気楽に消すことができる。
テストコードを減らすことで、残ったテストコードを物語る重要な仕様についての理解を深めることができる。

例えば、長く運用してきたサービスでは、

* もう誰も触っていない画面のテスト
* 仕様変更前の挙動を前提にしたままのテスト

が、そのまま生き残っていることが稀によくある。
リファクタリングやアーキテクチャ変更をしようとしたとき、こうしたテストが「本当に必要なのか」「誰に聞けばいいのか」が分からず、手を止めてしまうことが往々にしてある。

逆に、**安心して消せるテストコード** になっていれば、「これはもう役目を終えたから消そう」と判断しやすくなり、リファクタリングのスピードも上がるだろう。

## 消しやすいテストコードについて

`消しやすい` とはなにか。

筆者は `極めて独立しているテストコード` と定義したい。

この定義には重要なポイントが2つある。

1つは、誰でも消せること。
2つ目は、他への影響が皆無であること。

### 1. 誰でも消せること

今日新卒として入ってきたClaudeCodeくんでも、若者でも幼稚園児でも構わない。
熟練の炭鉱夫だろうが、ドメインエキスパートだろうが、人に依存していないことが重要である。

消せる人間が多いということは、テストコードが消されるまでのスピードが早い（可能性がより高まる）ことを意味する。

要するに、「あのテストを書いた◯◯さんに聞かないと消していいか分からない」という状態を避けたい。
特定の人の頭の中にだけ前提があるテストコードは、その人がいなくなった瞬間から、誰も触れない**聖域**になってしまう。

### 2. 他への影響が皆無であること

削除対象のテストコードを消したことによって、他のテストコードやCI・CDに影響が一切無いことを指す。
テストコードがテストコードに影響することはザラにあって、

* パラメータライズドテストのデータソースが共通化されており、2つ以上のテストコードが利用している
* モックオブジェクトが共有されており、1つのテストコードを消すと他のテストコードが失敗する
* テストコードの実行順序をずらすと、他のテストコードが失敗する

---

改めてまとめると、テストコードは依存していないことが最も重要である。ということが言える。

もちろん、「共有されているテスト用ユーティリティ」そのものが悪いわけではない。
問題なのは、**テスト対象の仕様を暗黙に埋め込んだまま、複数のテストで共有してしまうこと**だ。

依存関係はテストの単位が大きいE2Eでよくありがちである。E2Eのテストの捨てやすさに関しては、著者のｽﾞｯ友であるやまずん氏の記事を参照されたい。

[テストも捨てやすく作ろう by やまずん](https://t.co/2dngn79aoR)

## テストコードとアーキテクチャと開発手法について

消しやすいテストコードの真髄がわかったところで、 **アーキテクチャに合わせて、テストコードも変えていこう** という話を展開しよう。

アーキテクチャが変われば、責務の境界線も変わる。
つまり、**テストコードもアーキテクチャに合わせて変化すべき**だ。

この視点に立つと、「消しやすいテストコード」を育てていく方針が明確になる。

筆者は基本的に、コードのアーキテクチャはMVCから始めて、必要に応じてタイミングを見計らい、コードのアーキテクチャを組む。

そのタイミングで、APIの中規模テストを各コンポーネントの小規模テストに書き換えることにしている。

初期の段階では、API＋DBの疎通をテストする中規模テストが主役になる。
しかし、後からアプリケーションの責務が整理されてくると、

- ルール（バリデーション）
- 計算ロジック
- ドメイン知識

といった要素が独立し、**小さいテストに切り出せるようになる**。

このタイミングで、**中規模テストから積極的にテストを“消し”、より小さいテストへ置き換える**ことができる。

テストを小さくしていくことで、

* テスト実行コストを下げる
* 責任の所在が明らかになる

アーキテクチャの恩恵にテストコードも乗っかることができる。

例えば

* APIのI/OとDBへの疎通を見るテストは、引き続きAPIの中規模テストコードとして残す。
* 細かい入力値のバリデーションのテストは、責務の分割に伴い小規模なテストコードとして切り出す。

前者は「システムとしてつながっているか」を保証するためのテストであり、後者は「ロジックとして正しいか」を保証するためのテストだ。

この2つをきちんと分けておくと、「ロジック側の変更のたびにAPIテストを直す」といった不毛さから解放される。

こうすることで、テストコードの責任範囲が明確になり、消しやすくなる。

## まとめ

テストコードは、「書くこと」以上に「消せること」が大事になる場面がある。

- 役目を終えたテストを、誰でも・安全に消せること
- そのために、テスト同士やテスト用ユーティリティとの依存を極力なくすこと
- アーキテクチャの変化に合わせて、中規模のテストを小さなテストへと**移譲**していくこと

こうした工夫によって、テストコードは「ひたすら積み上がる資産」から
**役目を終えたらちゃんと退場していく、健全なサイクルを持った仕組み**に変わる。

テストは、永遠に残すためだけに書くのではない。
いつか安心して消せるようにしておくことも、開発者の大事な設計責任のひとつだ。


テストコードは積み上がるだけの資産ではない。役目を終えたら安心して消せる設計こそ開発の質を高める。本記事では、依存をなくした『消しやすいテストコード』の作り方を紹介。

開発者は消しやすいテストコードを書こう

去年は会場内部へ到達できなかったが、今年は両日ともGo Conferenceに参加することができた。
これが自分にとって初めてのGo Conferenceである。

タイムテーブルやチケット購入フローなど初めて触れるものが多かったが、特に困ることもなく参加できた。
会場へのQRコード入場はスムーズで、受付も混雑していなかった。

## 登壇内容

### [Deep Dive Into testing/synctest by Daiki Kubo](https://gocon.jp/2025/talks/957911/)

[testing/synctest](https://go.dev/blog/synctest) の解説は特に印象的で、bubbleという概念を日本語で聞けたのはありがたかった。

また、GoのコードがかつてGo自身で書き直されたタイミングがあったことを今回初めて知り、羨ましく思った。
使っている言語の内部実装がその言語で書かれているのは、より深い学びにつながりそうで面白い。

### [Goのビルドシステムの変遷](https://speakerdeck.com/ymotongpoo/the-history-of-gos-build-system)

ビルドの仕組みと紐づくパッケージ管理の歴史の話は必聴で、ぜひ聞きたいと思っていたセッション。

ビルド時間が長すぎたことがGo開発のモチベーションになった、というエピソードには驚いた。
「こんなにシンプルで、しかも重要な動機から開発された言語なのか」と感心した。

また、Goを触ろうとした時期に見かけたパッケージマネージャの乱立について、その歴史的背景を知れたのも興味深かった。
中長期的な技術採用の観点からも、とても示唆的なセッションだったと思う。

## スポンサーブース

普段使っている言語のカンファレンスでは出会わないような会社と話せるのは、新鮮で面白い。

仕事で日常的に利用しているサービスを提供している企業もあれば、業界は違うが似たようなビジネスモデルを展開している企業もあり、非常に勉強になった。

今回たまたまかもしれないが、Go Conferenceのスポンサーの方々は全体的に熱量が高く、とても良い刺激を受けた。

自分は「GoはPHPと比べてビルドや型の制約が強い分、スタートアップでは採用されにくいのでは」と思っていたが、実際にはそうでもないらしいことも知れた。
こうした技術イベントで、技術視点からビジネスモデルや未来の話を聞けるのは、自分にとって大きな楽しみだと再認識した。

## まとめ

全体を通じて、公式パッケージを題材にした最新のコード解説が多かった印象を受けた。
これほど多くの公式パッケージが取り上げられるカンファレンスに参加したのは初めての経験だった。

運営の方々の尽力もあり、とても素晴らしいカンファレンスだったと思う。
今回の体験でGoへの理解が深まり、来年もぜひ参加したいと感じた。

Go Conference 2025 参加記録。公式パッケージや testing/synctest、Go のビルドシステム変遷など登壇内容を詳しくレポート。Go 言語の学びと現場の熱量を紹介。

Go Conference 2025 レポート

## 前夜祭

委員長自らものづくりをしながら、Tronの人（？筆者は元ネタを追えていない）になりきって場を盛り上げていたのが印象的で、楽しい雰囲気から幕が開いた。

### [リアルタイムOS研究開発30年の歩み by Hiroaki Takada](https://confengine.com/conferences/scrum-fest-mikawa-2025/proposal/22985/os30)

「オープンソースで開発するためには資金が必要」。
その資金調達の工夫として、あえて会員種別のロイヤリティを設けず、β版へのアーリーアクセス権を薄く広く公開し、開発資金を確保していたという話があった。最終的にはオープンソース化するものの、“時間軸をずらす”ことで新しい価値を生む設計は非常に学びが深かった。

そして「ドキュメントは重要」という話には首がもげるほど頷いた。まさにADR（Architectural Decision Record）。

* 何を決定したのか

* どのような選択肢があったのか

* どの背景で選んだのか、選ばなかったのか

その記録は歴史として、古文書のように価値を持つ。
30年第一線で関わり続けてきた方の言葉は重かった。

## 当日

### [見えてきたEV2.0：家電向けのソフトウェアがクルマに載る日 by Manji Suzuki](https://confengine.com/conferences/scrum-fest-mikawa-2025/proposal/22837/ev20)

無人タクシー普及にまつわる課題は法律や倫理の問題がよく語られるが、キャッシュフローの観点から見るとさらにリアリティが増す。

車両はタダではなく、自動運転システムと車体そのもののコストを両方考える必要がある。

```
利益 = 現金 - {(外付けの自動運転システム) + (車体費用)}
```

中国で無人タクシーが急速に広まった理由のひとつはEVの安さにある。「安いは正義」。
某𓃬のクルマは1200万円スタート。一方で安価な中国製EVなら、無人タクシービジネスとして現実的な筋がある。

---

次に語られていたのは「家電としてのEV」の姿。

所有車は「乗る時間」より「放置される時間」のほうが長い。ではその空白時間をどう使うか？
中国では一人用EVをカラオケルームやゲームセンターに改造する動きもあるらしい。

ただ、これは「所有」を前提とした課題。シェアリングエコノミーに生きる人には響きにくい。とはいえ所有の歴史的概念を崩すのは簡単ではない。だからこそ、クルマを“空間の拡張”として再定義する動きが求められるのだろう。

### [テストを使って透明性を獲得しよう by やまずん](https://www.docswell.com/s/55_ymzn/KN9QME-scrumfestmikawa2025/1)

「あなたは、自分の仕事に対して存在否定の眼差しを向けたことがありますか？」
そんな問いかけのように感じた発表だった。

特に印象に残ったのは、テストは“作ってはいけないもの”を考える役割もあるという点。否定的な視点でプロダクトを俯瞰し、エンジニアと落とし所を見つける対話が必要になる。
普段自分が取り組んでいることが言語化されたようで、省みるきっかけになった。

### [「メカアジャイルのその後 ～実践編～」 ― 顧客検証を阻む“ルールの壁”を越えて ― by YUKI YAMAUCHI](https://confengine.com/conferences/scrum-fest-mikawa-2025/proposal/23033)

メカを市場に出すには、巨大なパイプラインを通過する必要がある。だからこそ、作る前からシフトレフトで品質を作り込むことが、リードタイムを短縮し、デプロイ速度に直結する。

それはつまり、`生産設備の生産性向上＝顧客の売上` にも影響を与える。自分たちの仕事が顧客の売上に直結する。このアウトカムは絶対に気持ちいいだろうと思った。

### [出張！何でもEBMワークショップ団 in 三河 by Tomonari Nakamura ( ikikko )](https://confengine.com/conferences/scrum-fest-mikawa-2025/proposal/23000/ebm-in)

チームで目標を立て、試行錯誤するワークショップ。
実現可能性はさておき「足掻く体験」そのものが良かった。

解説で特に刺さったのは「4keysはあくまで一部分」という話。
年1リリースでも競合より速ければ十分。他の指標にリソースを割くべきケースもある。全体を見つつ、どこに力を注ぐかを考える重要性を感じた。

資料： [4keysはあくまで一部分の資料](https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcThaBiwpiwLmv0XEZY9UCUfnjqPuAIrSgSag1FZgkXrmm75Q1IopGnU94Uy&s=10)

### [リーン/アジャイル/Teslaを通して見る近未来の自律的チーム　- 生成AIはチームの自律性を強化できるか？ - Kazutaka Sankai](https://confengine.com/conferences/scrum-fest-mikawa-2025/proposal/22884/tesla-ai)

コンウェイの法則の“超現実版”のような話。

4keysのような指標は現場のもの。本当に経営層が求めるのはシンプルな1つの指標だけ。だからエンジニアにはエンジニアリング以外をさせない。マネジメントを極力減らす。

これが、イーロン・マスクの思想。

その理屈は納得感があり、もっと分析や考察を深めた資料が出てきたらぜひ読みたいと思った。理解できたので、分析された文章や考察の資料や本が上がってきたら読んでみたいと思った。

### [改めて、“チームで話し合う”を考えよう 〜対話の原則とファシリテーションの視点から〜 by KEN TAKAYANAGI](https://confengine.com/conferences/scrum-fest-mikawa-2025/proposal/22790)

「場の設計が大事」──まさにこの一言に尽きる。

ファシリテーターとして何を期待するのか、参加者の属性を踏まえて場をデザインすることが重要。
正直、自分にはちょっと難しく「何が難しいのかすらわからないunknown unknown」という感覚だった。悔しさもある。

Art of Hostingの概念を学んでみたい。

## まとめ

ものづくりの土壌・三河で、初めてのスクラム界隈のカンファレンスに参加。
秋風が吹き抜ける豊橋で、止まらない熱気に包まれた人々の集まりは圧巻だった。

自分のやってきた仕事の羅針盤は大きく間違っていない、と確認できたし、懇親会でも勇気をもらえた。

企画・運営してくださったスタッフの皆さんに心から感謝しています。また必ず来たいと思います。


プライベートの予定と重なってしまい、行けないかも…と思っていたけど、念願かなってずっと行きたかったスクフェス三河に参加できた。ものづくりの会社が集う場での学びと感想をここに残す。

スクフェス三河2025に初参加してきた

ソフトウェアエンジニアリングに関係あるか微妙かも知れないが、他のジャンルが多いのでこっちに寄せた。

5月はそんな月。

## コード書いたり、実務ですぐに使えそうな感じの本

### [デザイニング・インターフェース パターンによる実践的インタラクションデザイン](https://amzn.to/3SAaqHy)

安定のO'Reilly。
年々インタフェースについて興味が増し、インタフェースでコードを組み始めることも多くなったため、購入。

目的買い。

### [プログラミング作法](https://amzn.to/3ZMfyvS)

何だっけな。

確かアプレンティスシップ・パターンを読んで引用されていた本だったから積んだ気がする。

引用買い。

## ソフトウェアエンジニアリングっぽいが、すぐに仕事で使えるかどうかはわからない本たち

### [雑に作る 電子工作で好きなものを作る近道集](https://amzn.to/3ZMfnkc)

このタイトルの雑さがまず良い。

「雑にさっさと作り切ることが大事」みたいなことがサラッと書いてあり、激しく頷いたため購入。

タイトル買い。

### [ビッグデータの正体 情報の産業革命が世界のすべてを変える](https://amzn.to/4kOvRAA)

生成AIに食わせるのは膨大なビッグデータであり、無関係ではなくなってしまったジャンルである。

流石に勉強するかということで購入。

危機買い

### [社会は情報化の夢を見る](https://amzn.to/43swfyY)

積読が趣味の同僚が、口にしてた本。

タイトルもイカしてるし、買ってみた。

同僚買い。

### [問いかける技術 確かな人間関係と優れた組織をつくる](https://amzn.to/3Ze1s6o)

一見ソフトウェアエンジニアリングに関係なさそうに見える。そう、一年前の自分だったらそう思っただろう。

実際はそんなことなくて、何を作るのか、ユーザーは何を欲しがっているのか。問いかけによって引き出し導く必要が往々にしてある。

そして人間関係や優れた組織というのは、コンウェイの法則によってソフトウェアエンジニアリングに直結する。

あと著者のエドガー・シャインさんが流行っていたから買った。

タイトル買い。

### [問いのデザイン 創造的対話のファシリテーション](https://amzn.to/3FvRzKJ)

これは全く覚えてない。無念。

多分タイトル買い。

### [「具体⇄抽象」トレーニング 思考力が飛躍的にアップする29問](https://amzn.to/3HlmSZ5)

友人たちと本屋に並んでいたときに紹介してもらった一冊。

実際、このトレーニングは実践で使うことが難しいと言われて奮えたので購入。

友人買い。


インタフェース設計、プログラミング作法、問いの技術、ビッグデータ、情報社会。2025年5月に積んだ、思考と実践を深める技術書の記録。

2025年5月に積んだ本 【ソフトウェアエンジニアリングっぽいやつ】

なんで買ったか覚えていない本が多かった。買うスピードが遅いのかもと反省した。

## 哲学・思想・人間っぽいやつ

### [治りにくい病気の漢方治療 アトピー・不妊症・喘息から不定愁訴まで](https://amzn.to/43ZuLfI)

以前、漢方について見聞を広めようと新書を買ってみたが、そのノリで今回も積んでみた。

流れ買い。

### [獄中日記 塀の中に落ちた法務大臣の1160日](https://amzn.to/4kMEETx)

いやもう、ツッコミどころありすぎるし気になりすぎる一冊。

ホリエモンもそうだったが、獄中日記系は品質が高い印象があるし、著者が元法務大臣。元法相から見る獄中の景色を見てみたくなった。

タイトル買い。

### [ソロモンの指環 動物行動学入門](https://amzn.to/3ZPl9ld)

我々動物は、遺伝子の乗り物であるという。ではその動物の遺伝子に刻まれた意思というか、行動指針とは何なのかは常々気になる分野である。

そんな中、YouTubeで良さげで骨太な入門書の紹介があったので、積んだ。

YouTube買い。

### [精神科医が見つけた3つの幸福](https://amzn.to/4jJcckM)

著者ではないが、お医者さんが紹介していたため積んだ。

紹介買い。

### [「甘え」の構造](https://amzn.to/4jCBUHB)

1971年初版のベストセラーらしい。半世紀前の思想、紡がれた人間関係のツールは気になり思い積んだ。

歴史買い。

### [格差の"格"ってなんですか？ 無自覚な能力主義と特権性](https://amzn.to/3Ze4sja)

新たな思想、哲学っぽい感じのタイトルで積んだ。特にこだわった理由はなかった気がする。

タイトル買い。

### [枝分かれ 自然が創り出す美しいパターン](https://amzn.to/4kMFiQX)

パターン・ランゲージのクリストファー・アレグザンダーさん関係の本だった気がする。が、覚えていない。

多分著者買い。

### [生物と無生物のあいだ](https://amzn.to/3ZgRQb4)

同僚が唸っていた為買った。新書だし、軽率に積んだ。

同僚買い。

### [人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則](https://amzn.to/3ZlAKJ8)

（まだ聞いていないが）同僚がPodcastで話していて、タイトル的にも含蓄深そうだったので積んだ。

<Podcast podcastId="4kWBK3mdYMv8v2zdmwIzsu" />

同僚買い。


漢方、獄中、動物行動、幸福論、格差と協力関係。2025年5月に積んだ、人間を深く知るための思想書と教養書の記録。



2025年5月に積んだ本 【哲学・思想・人間っぽいやつ】

5月は25冊。ビジネス書っぽいやつや哲学・思想っぽいやつが多い月。

## ビジネス書っぽいやつ

### [熟達論 人はいつまでも学び、成長できる](https://amzn.to/4ksVnM2)

為末選手は既知のスプリンターであり、とにかく思考の言語化が上手な人という印象を持つ。
YouTubeのなにかの動画で彼を見て、本を読んで脳みそを覗き込みたくなったので購入。

著者買い。

### [日本人の足を速くする](https://amzn.to/4kmOhs9)

上の本と同じ感じで、為末さんの足が早くなる理屈を知りたくなった。初版も2007年だし、20年前の考えに触れて差分を取ってみるのもいいと思った。

著者買い。

### [ストーリーが世界を滅ぼす 物語があなたの脳を操作する](https://amzn.to/3SUZxQN)

真実かフィクションはさておき、人間にとってストーリーは切り離せないということは記憶に新しいところだ。

文明や文化、宗教心などストーリー由来の物が多く、マーケティングとしても重要な存在感を示している。

もっと詳しく知りたい、ということで積んだ。

タイトル買い。

### [あなたを支配し、社会を破壊する、AI・ビッグデータの罠](https://amzn.to/3ZL43Vy)

最近流行っていて、波に乗っているからこそアンチの声に耳を傾けることは重要だと思う。

清濁併せ呑んだ上で突き進む道を自分で照らす必要がある。

タイトル買い。

### [人生の経営戦略 自分の人生を自分で考えて生きるための戦略コンセプト20](https://amzn.to/45Edgml)

同僚と話していてめちゃくちゃ気になった。

「社会資本」「人的資本」「金融資本」といえば、橘玲さんの [『幸福の資本論』](https://amzn.to/45d5Y9b)がまず思い浮かぶ。

単なる焼き増しなのか、どの程度の二番煎じなのか気になったためかなり気合を入れて購入。

同僚買い。

### [シェアド・リーダーシップ チーム全員の影響力が職場を強くする](https://amzn.to/4mFKvM9)

リーダーシップについて知りたい時があり、そのときに積んだ気がする。

タイトル買い

### [図解トヨタがやらない仕事、やる仕事変わり続けるトヨタの変わらない仕事術](https://amzn.to/4dInggq)

QAの同僚が薦めていたような気がする。

たぶん、同僚買い。

### [FIRE 最強の早期リタイア術 最速でお金から自由になれる究極メソッド](https://amzn.to/45GkvKt)

普段ならこの手のタイトルは買うことはないんだが、ラジオかオーディオブックで取り上げられていたため積んだ。

タイトルの邦訳は最悪なのだが、もともとのタイトルは『[Quit Like a Millionaire](https://amzn.to/4kNzhDF)』。気品漂ういい感じのタイトルである。

本の中身も言及されていた気がするが、忘れたのでまた読んでみるとしよう。

英語のタイトル買い。



熟達、思考、ストーリー、AI批判、人生戦略、早期リタイア。2025年5月に積んだ、視点を拡張するビジネス書の記録。



2025年5月に積んだ本 【ビジネス書っぽいやつ】

IT関連のビジネス本が多い月。

## ビジネス書っぽいやつ

### [スターバックスはなぜ値下げもテレビCMもしないのに強いブランドでいられるのか?](https://amzn.to/4jIX8DU)

アメリカのスターバックスは営業成績がよろしくないとのことだったので、気になって買ってみた。

Twitterを眺める感じで読みたい。

Twitter買い。

### [人事屋が書いた経理の本 ＭＧから生まれた戦略会計マニュアル](https://amzn.to/42I4i4w)

切り口としてとても興味深くて購入。

しかも初版が1978年と、名著の波動を感じる。

何かしらエッセンスを取り入れられると思い購入。

タイトル買い。

### [ＳＩＺＥ（サイズ） 世界の真実は「大きさ」でわかる](https://amzn.to/432olMj)

目に見えるもの見えないものを相対比較する技術というのは、原始時代から連綿と紡がれた我々人類の特性である可能性が高い。

大きいやつは強い。小さいやつは弱い。みたいな先入観。

サイズ、興味ありすぎて積んだ。

ジャケ買い。

### [AI時代のSEO戦略──組織を動かし成果を引き寄せる実務マネジメント](https://amzn.to/3S8JRJ0)

そのうち手に入らなくなるだろうなと思い積んだ。

っていうか、さっさと読まないと陳腐化するからまずいな。

このブログ書いててよかった。

タイトル買い。

### [君は戦略を立てることができるか 視点と考え方を実感する４時間](https://amzn.to/3S5u1if)

なかなかに骨太なタイトルで挑戦的で良さそうだった。

戦術は割とそのへんに転がっているが、そもそも戦略がないとその戦術は意味を成さない。よい戦略の立て方を学びたいと思い購入。

タイトル買い。

### [プロフェッショナルアジャイルリーダー　組織変革を目指すトップとチームの成長ストーリー](https://amzn.to/4kaJZnB)

同僚がシーシャ吸いながら読んでるのをタイムラインで見かけたのがきっかけ。

表紙デザインを見たとき、数十年前のほんだと思ったが、ちゃんと2025年初版だった。

これが昭和レトロ的な感覚なのか。

ジャケ買い。

### [ダイナミックリチーミング 第2版 ―5つのパターンによる効果的なチーム編成](https://amzn.to/3GtaaXS)

現場のSlackがざわついた一冊。

チームは人が入れ替わるし、停滞したところに適度な刺激をいれる方法など、いろいろあるよなあと現場で思うところはあった。

それが第Ⅱ版として夜に出てきたわけだから買うしかないと思った。

現場のSlack買い。

### [医療崩壊前夜](https://amzn.to/4lNzF6t)

上がる続ける年金、社会保険、健康保険。その原因や過程、歪はどこから来ているのか気になって積んだ。

読んでみたけど、なかなか骨太で面白かった。医療費が足りないのか医療品が足りないのか問題もある。

バランスを取ることが難しい感じだった。

タイトル買い。


ブランド戦略、戦略思考、SEO、チーム編成、医療制度。2025年4月に積んだ、視野を広げるビジネス書たちの記録。

2025年4月に積んだ本 【ビジネス書っぽいやつ】

4月は本当にたくさんの本を詰んだ。中長期的に役に立ちそうな本の購入動機を、当記事では紹介する。

## ソフトウェアエンジニアリングっぽいが、すぐに仕事で使えるかどうかはわからない本たち

### [ソフトウェア開発の名著を読む【第二版】 技評SE選書](https://amzn.to/430Z7xP)

名著が名著となぜ呼ばれるのかは、それが名著であるからだ。それはわかっている。

個人的には時代を経ても変わらない本質を突いていて、かつ当時の時流に乗れた本が名著と呼ばれるんじゃないかと今は思っている。

そんなわけで、名著を書く人が選んだ名著セレクションを知りたくなった。

著者買い。

### [プログラマーのためのCPU入門　CPUは如何にしてソフトウェアを高速に実行するか](https://amzn.to/3EopO6o)

低レイヤーの上っ面の明日から使える技術じゃなくて、低レイヤーの骨太な知識も蓄える。

これは自分に対する義務でもある。

タイトル買い。

### [システム設計面接の傾向と対策](https://amzn.to/3YJZbQ4)

システム設計面接ってやったことないんだけど、いつかはシステム設計面接を設計したり、自分のチームが求める人物像を考えたりする時が来るとおもう。

その時のために積み、知識を獲得したい。

タイトル買い。

### [スタッフエンジニアの道　―優れた技術専門職になるためのガイド](https://amzn.to/42uhrzf)

O'Reillyが出してるし、[『アプレンティスシップ・パターン』](https://amzn.to/4cQE0lk)と同じ波動を感じたので購入。

タイトル買い。

### [エンジニアチームの生産性の高め方 〜開発効率を向上させて、人を育てる仕組みを作る](https://amzn.to/4iAAGMs)

サブタイトルをみて、いいなと思って積んだ。

プロダクト開発に本気で取り組まないと良いコード・設計はできないと思っており、その現場現場で人は違うしチームの性格も異なる中で、どのように人を育てるか。という命題は喫緊の課題だろう。

だからこそ1つの情報源としてアクセスしたくなった。

タイトル買い。

### [エンタープライズアプリケーションアーキテクチャパターン: 頑強なシステムを実現するためのレイヤ化アプローチ](https://amzn.to/3YJo8uP)

ようやく手に入れられた。

長くシステムを運用する技術を体系的に学ぶことはまだしていないと思い購入。

Martin Fowlerさんの本は初めてだから楽しみだ。

著者買い


設計思考、低レイヤーの知識、名著の再読、育成と生産性向上。2025年4月に積んだ、中長期的な視点で選んだ技術書の記録。

2025年4月に積んだ本 【ソフトウェアエンジニアリングっぽいが、すぐに仕事で使えるかどうかはわからない本たち】

4月は本当にたくさん買った。特にコーディング周りの本が今までに比べて多い。

## コード書いたり、実務ですぐに使えそうな感じの本

### [テストから見えてくるグーグルのソフトウェア開発](https://amzn.to/4jtFnJ6)

* 同僚で優秀なQAが薦めていたのでかったみた
* 同僚買い

### [おうちで学べるデータベースのきほん　第２版](https://amzn.to/3EF9iPl)

* データベース何もわからん🤔となって、チームメンバーと話していたら「ミックさんっていう人がいて」という情報をいただいたので買った
* 読んでみたけど、基本中の基本を習ってなかったし学び直せてよかった。
* 正規化や集合の考え方、コストの知識もあってよかった
* 著者買い

### [マルチテナントSaaSアーキテクチャの構築　―原則、ベストプラクティス、AWSアーキテクチャパターン](https://amzn.to/3RuOWv9)

* マルチテナントという言葉が何もわからんとなっていたので買った
* ジャケ買い

### [ストリートコーダー](https://amzn.to/3Gitg30)

* 書名がドンピシャ過ぎて買った
* ジャケ買い

### [クリーンコードクックブック　―コードの設計と品質を改善するためのレシピ集](https://amzn.to/42OvWNf)

* リファクタリングや設計を考えるときに必要になると思い購入
* O'Reillyが出すこの手の本はなんか、買わないといけないようなきがしている
* 使命買い

### [大規模データセットのためのアルゴリズムとデータ構造 (Compass Algorithms)](https://amzn.to/3EphC5Q)

* データとアルゴリズムの本は積んであるけど、何種類合ってもいいと思って買った
* ジャケ買い

### [センスの良いSQLを書く技術 達人エンジニアが実践している35の原則](https://amzn.to/3Yhco2K)

* どこまでSQLにロジックをもたせるか。という問題に最近悩んでいて、SQLでどこまでできるのかも気になっていて買った
* 良いタイトルだなーと思っていたらミックさんだった
* ジャケ買い

### [コード×AIーソフトウェア開発者のための生成AI実践入門](https://amzn.to/3YfEzPw)

* PHPerKaigiでカワシマさんと話していて教えてもらった一冊
* 紹介買い

### [Gitハンズオンラーニング ―手を動かして学ぶバージョン管理システムの基本](https://amzn.to/4lEMEqV)

* `Gitの使い方だけでなくGitの仕組みから学べる入門書` って説明に書いてあって買った
* ハンズオン最近してないのでしたくなった
* やっぱりO'Reillyいい本出すよね
* ジャケ買い

### [Tidy First? ―個人で実践する経験主義的ソフトウェア設計](https://amzn.to/4cLVH5e)

* 薄すぎてびっくりな一冊
* でも内容はいいことが書いてある
  * 読んでる人多そうだったから買った一冊
* 流行り買い


2025年4月に積んだ技術書を紹介。Googleのテスト文化やマルチテナントSaaS、生成AI、SQL、Git、ソフトウェア設計など、実務に直結するテーマの書籍を多数購入しました。

2025年4月に積んだ本 【コード書いたり、実務ですぐに使えそうな感じの本】

有能な知り合いが生まれつつある小田原の地へ再訪。今回は登壇という形で。

得られた知見もあるし、振り返るとする。

## 前夜祭

### 登壇

1年ぶりの小田原なので、街の事情は完全に理解している。余裕をコいていたら集合時間ギリギリだったので反省している。

会場に着いたら着いたでスタッフも慌てていて、自分が登壇する時間もわからない。PHPカンファレンス名古屋で、お客さんの紳士で大人な対応ですごく助けられた経験を思い出し、落ち着くのを待った。

自分は『だから僕は（クラス）設計を辞めた』というタイトルで登壇の魁を務めた。登壇内容としては渾身の一撃だろうという意気込みだったが、自分自身の時間管理が甘く完成度としては改善点の残る物となった。

もう少し会場を巻き込んだ、落ち着きと談笑が湧く構成にしたいと振り返った。

<Docswell slideId="KP2318" />

あたふたしていてメンタル的にはかなり効いていたが、 [@TAKA_0411](https://x.com/TAKA_0411) さんが最前列で大きくリアクションして下さり、だいぶ有り難かった。その後の宮小路散策にて感謝申し上げた。

改めて、誰かの発表にはリアクションをオーバーにしてあげたいなあと前向きになった。

その場で行う、物理1分間フィードバックの企画は面白かった。

確かに、2,30人の規模であればポスト・イットにフィードバックを書いてボードにまとめておくことで、特に運営のコストが下がりそうだと思った。

みんな感想ありがとうございました！　こういうのがめっちゃ励みになるんだよな。

画として、文字として残るのめっちゃいい。企画した人天才。

### 前夜祭の感想

かがさんのLTめっちゃ良かった。

<SpeakerDeck slideId="10749e45bdb4455080eddff912694543" />

最近立ち上がった、 [俺の勉強会](https://ore-no-benkyoukai.connpass.com/)という名古屋の勉強会に参加したときも思ったけど、自分の波長が合うコミュニティはいくつか合ってもよいと思った。

特に今年は、PHP以外のコミュニティに足を伸ばしてみることが目標だから、少し背中を押された気がして嬉しかった。

---

宮小路に向かう前、 [@kyon_mm](https://x.com/kyon_mm) さんにスライド作成の極意を聞いた。プロポーザルを出す時点では資料の骨子が作成されており、いつでも登壇できるようにしているとのこと。

なるほど。それはプロポーザルが通ってからよりも長い時間、資料作成に時間を費やすことができる。

真似できるかはさておき、思考を文字に起こす速度向上が必要そうということがわかった。

## 本編

前夜祭参加組は、受付を済ませていたのでスマートログインみたいな感じで体験が良かった。

Tシャツもセルフで取っていくやつ、全然これでいい！　となった。名古屋ではできなかったので改めて学び。

### 登壇内容の感想

特に印象が残っているのは、 [meihei](https://x.com/app1e_s) さんの『改めて学ぶTraitの使い方 / phpcon odawara 2025』にAsk the Speakerをしに行って、話し込む中で呪力の核心を得たことである。

<SpeakerDeck slideId="1a3563488c60415486d5b58d16553e8d" />

traitに定義可能なメソッドには、あらゆるアクセス修飾子が付与可能であり、何ならプロパティも同じようにプロパティを定義できる。

実態があるようでない事の気持ち悪さと、抽象クラスに定義してある通常メソッドのような気味悪さから、自分はうまく使うことができていなかったこともあり、話は大いに盛り上がった。

喧々囂々とする議論の中で、「traitが最も輝く舞台は、変化が少ない完璧なドメインの中にあるのではないか？」という黒閃が爆ぜた。多重継承が設計される基幹システムやフレームワークなどがそれにあたる。

このような建設的な話し合いの中で生まれるミラクル的な体験がすごく面白いしたのしい。こういう瞬間のために、エンジニアって旅してるんじゃないかな。少なくとも、自分はそう思った。

---

次に印象に残ったのは [きんじょうさん](https://x.com/o0h_)の『「影響が少ない」を自分の目でみてみる』という登壇。

<SpeakerDeck slideId="249204c5841642409ce545bf3dd533a3" />

視点が尖すぎて切れ味抜群。とにかく難しい言葉を使わずに ~~依存~~ とか ~~凝集~~ みたいなものを図示するというテーマ。

自分もよく ~~考古学~~ コードからロジックを読み込むときは付箋やポスト・イット（本当はmiro）にベタベタ処理を貼っていっているのだが、その次の段階に行うようなことを簡単なスケッチで行えるというものだった。

影響が大きいものをどれだけ止められるのか。という視点で図をみて、影響の矢印をいじいじしてみる。目で見える図でなら、チーム内でも意思疎通がしやすそうで良さそうだった。

だからこそSQLにロジックを寄せて、影響がDBから出すぎないように調整することはすごく意味があると強く戒めた。

### イベントとしての感想

まずは食事について。

カンファレンスと地域・行政がここまで密着しているのはもはや小田原くらいじゃないか。
オーガナイザーの地元愛が凄まじすぎて本気を感じた。紹介していただいた飲食店全てが美味だった。
これは小田原に移住したく成る人の気持に寄り添っているなあと。

また、他のカンファレンスには見られない、全員参加型のアクティビティが行われた。PHPのビルトイン関数に関するクイズだったり、ソフトウェアエンジニアリングに関する問題を3人一組で解いていく。勝敗はどうであれ3人で行われるコミュニケーションそのものにとても意味があるし、勝敗があるからこそ強調して価値に行くモチベーションが湧いた。

とても面白かった。

## まとめ

今年も行って本当に良かった。登壇の機会まで与えられて、呪力の核心まで掴めて、大人数でしかできないコミュニケーションも取れた。

特に、大合戦の問題を考えたり、準備をするのは骨が折れただろうなと思う。あれはカンファレンス参加者に楽しんでほしいという、実行委員会の気持ちの顕れだと感じた。

本当にお疲れさまでした。

またいつか　話に行きたい　小田原に


「だから僕は（クラス）設計を辞めた」で登壇。trait設計の再発見と、現地の温かい空気に支えられた技術者としての旅の一歩。

Volare Viah

開発者は消しやすいテストコードを書こう

Go Conference 2025 レポート

スクフェス三河2025に初参加してきた

2025年5月に積んだ本【ソフトウェアエンジニアリングっぽいやつ】

2025年5月に積んだ本【哲学・思想・人間っぽいやつ】

2025年5月に積んだ本【ビジネス書っぽいやつ】

2025年4月に積んだ本【ビジネス書っぽいやつ】

2025年4月に積んだ本【ソフトウェアエンジニアリングっぽいが、すぐに仕事で使えるかどうかはわからない本たち】

2025年4月に積んだ本【コード書いたり、実務ですぐに使えそうな感じの本】

『だから僕は（クラス）設計を辞めた』 in 小田原：PHPカンファレンス2025登壇記