『達人プログラマー』を読んだきっかけ
Claude Codeでサイトを構築してから、プログラミングの原則をきちんと学び直したいと思い、技術書の定番として挙げられる『達人プログラマー（第2版）』を手に取った。
この本の核心は DRY原則（Don’t Repeat Yourself） だ。「すべての知識はシステム内で単一・明確・信頼できる表現を持つべき」という思想で、コードだけでなく設計・ドキュメント・プロセス全般に適用できる。
私は個人事業と法人を併営しており、請求書作成・経費記録・ブログ投稿といった定型作業が日常的に発生する。この本を読んで「繰り返しを排除する設計」を実務に取り込んだら、可処分時間が明らかに増えた。以下、具体的な適用例を3つ紹介する。
DRY原則の適用例1：著者事実台帳で「自分の情報」を一元管理
ブログ記事を書くとき、以前は毎回「年齢は何歳だっけ」「法人名は株式会社USで合ってたか」と確認していた。記憶と過去記事を照合する手間が地味に積み重なり、書き始めるまでに5分以上ロスすることもあった。
解決策として、著者事実台帳（Markdownファイル）を作成し、年齢・居住地・事業構造・資格・読了書籍リストなど「変わらない事実」を1箇所に集約した。 記事生成スクリプトが毎回このファイルを読み込むことで、私は「何を書いたか」だけに集中できるようになった。
事実の重複管理を排除したことで、矛盾する記述も自動的に防げる。これは典型的なDRY原則の実装だ。
DRY原則の適用例2：経費・売上の記録を会計ソフトに一本化
併営事業では、個人事業の経費と法人の経費を分けて記録する必要がある。以前はExcelで管理していたが、確定申告前に会計ソフトへ転記する二度手間が発生していた。
現在は freee会計で個人・法人を別プロジェクトとして運用し、記帳は会計ソフトに直接入力する。 Excelは一切使わない。売上・経費・口座残高がリアルタイムで可視化され、申告時の転記作業もゼロになった。
「記録を二重管理しない」というDRY原則を守るだけで、月末の記帳作業が30分→5分に短縮された。
DRY原則の適用例3：ブログ投稿の自動化スクリプト
ブログ記事は週3回（火・木・土）の定時投稿だが、以前は手動でMarkdownファイルを作成し、front matterを毎回書いていた。日付・slug・カテゴリの入力ミスも頻発した。
現在は Python + Claude API で記事生成を自動化し、front matter・ファイル名・投稿日時の整合性をスクリプトが保証する。 私がやるのは「生成された記事を確認して公開ボタンを押すだけ」だ。
これもDRY原則の実装例で、「人間が毎回同じ作業を繰り返す」状態を排除した。記事本数が増えても、投稿にかかる時間は変わらない。
DRY原則を実務に落とし込むときの3つのポイント
『達人プログラマー』を読んで気づいたのは、DRY原則はコードだけでなく 「知識の重複を排除する設計」 として、あらゆる業務に適用できるということだ。
実装時のポイントは以下の3つ。
- 「二度やっている作業」を特定する：同じ情報を複数の場所に書いていないか、同じ手順を毎回繰り返していないかを観察する
- 「唯一の情報源（Single Source of Truth）」を決める：著者事実台帳や会計ソフトのように、1箇所に情報を集約する
- 自動化できる部分は自動化する：スクリプト・テンプレート・ツール連携で人間の手を介さない仕組みを作る
私の場合、DRY原則を実装した結果、記事執筆・記帳・情報管理にかかる時間が合計で週3時間ほど削減された。この時間を読書や家族との時間に回せるようになったのが最大の収穫だ。
まとめ：DRY原則は「時間を買う設計」
『達人プログラマー』のDRY原則は、プログラミングの枠を超えて「繰り返しを排除する設計思想」として使える。
私が実装した3つの例——著者事実台帳・会計ソフト一本化・ブログ自動化——は、どれも「同じ情報を二度書かない」「同じ作業を二度やらない」という原則に従っている。
38歳で併営事業を回しながら家族時間も確保するには、可処分時間を1分単位で増やす設計が必要だ。DRY原則はその実装手段として、コストゼロで始められる最良の投資だと実感している。
関連書籍
達人プログラマー（第2版）——熟達に向けたあなたの旅
DRY原則・直交性・信頼性といった普遍的な設計思想が平易に書かれている。Claude Code時代でも「何を書かないか」の判断軸として有効な一冊。