■ 1. 著者と背景
- 著者 Dave Thomas は『達人プログラマー』の共著者であり、アジャイルソフトウェア開発宣言の署名者
- Dave は "Agile is Dead" と発言したことでも知られる
- 本書『シンプリシティ』を読む前に、巻末の訳者あとがきを先に読むことが推奨されている
■ 2. "Agile is Dead" の主張
- 背景:
- 本来、形容詞（機敏な）であった「アジャイル」がビジネス上の利益のために名詞化された
- 名詞化により、本来の柔軟性・適応性が失われ、認証制度・厳格なルール・恐怖心に基づくコンサルティングが蔓延した
- Dave が提唱した真の敏捷性（Agility）を取り戻すための4ステップ:
- 現状把握: 自分が今どこにいるのかを正確に理解する
- 小さな一歩: 目標に向けて小さな一歩を踏み出す
- 評価: その一歩の結果、何が起きたかを分析し、学習する
- 繰り返し: 上記のプロセスをフラクタルに繰り返す
- 結論: 現場の人間こそが問題と解決策を知っており、形通りのプロセスに依存せず自分たちの文脈に合わせた機敏性を追求すべき
■ 3. Simplicity の概念
- Agility を実践するには、開発者が自分の仕事を自律的に進める Agency（主体性）が重要
- 「自分の目の前にある複雑さを減らすこと」が仕事の進め方を軽くするという考えに到達したものが Simplicity
- Dave による Simplicity の定義: 理解しやすく、変更しやすく、「しっくりくる」感覚を生み出す状態
- Simpler な方法の条件:
- CよりもSの方が理解しやすい
- CよりもSの方が部品が少ない
- CよりもSの方が問題をより直接的に表している
■ 4. Simplicity へのアプローチ
- 方向を見定め: 複雑すぎると感じる何かを見つける
- 一歩進み: アイデアを試すためにできる最もシンプルなことを見つける
- 学び
- ふりかえる
- このアプローチは "Agile is Dead" で述べられた Agility の概念と同一であり、本書は Dave 自身の Agility の具体的な方法論を集めたもの
■ 5. 不健全な依存関係の削除
- left-pad 事件の教訓: わずか11行のコードは依存関係であってはならない
- ライブラリを導入するかどうかの判断基準:
- その機能は必要か
- コーディングする方が簡単か
- ジャングルを買っていないか
- プロジェクトにとって代替不能か
- 特定のバージョンにロックされているか
- 安全か
■ 6. フレームワークは機能を追加し続ける
- フレームワークが与える選択肢には、必要としていないものも含まれる
- すべてのオプションと機能には、複雑さ・依存関係・肥大化という代償が伴う
- 未使用の機能は将来のセキュリティホールになる可能性がある
- コードよりもフレームワークの維持に多くの時間を費やしているなら、そのフレームワークは助けになっていない
- 必要なことをこなしつつ、機能が最も少ないフレームワークを選ぶべき
- 著者はKotlinバックエンドにおいてSpringよりKtorを、JS/TSバックエンドにおいてHonoを好む理由として、この主張を挙げている
■ 7. 作らずに済んだ機能こそ最高の機能
- 機能とは、将来の負債を意味するマーケティング用語
- 「誰かが必要としない限り、コードを書くな」がソフトウェアをシンプルに保つ基本ルール
- 「xxだったらクールじゃない？」「xxを追加するのは簡単だろう」はニーズではない
- 機能ではなく、インクリメンタルな価値を提供することが重要（ニーズ駆動開発）
■ 8. コメントは基本的に悪き習慣
- コードを変更すると関連するコメントも修正が必要になり、作業が2倍になる
- コメントを追加する正当な理由は以下の3つのみ:
- コメントを抽出してドキュメントを作成するツールを使用している場合
- コードの将来の読者に、予想外の実装方法を選んだ理由を伝える必要がある場合（Why not）
- TODOやその他のフラグを追加するため
- TODOはプロダクションに存在すべきでないため、できるだけ早く消すようプレッシャーをかけることが重要
■ 9. まとめ
- 本書は「理解しやすく、変更しやすく、しっくりくる状態とはどういう状態か」を Dave 自身の実践例を通して学ぶための本
- Agility の4ステップ（現状把握・小さな一歩・評価・繰り返し）がもたらす結果を理解するための内容