UNIX哲学から学ぶ設計

• 日程: Day 3 / セッション 02
• 時間: [9:30-10:00]
• 形式: ディスカッション
• ゴール: UNIX哲学の主要原則（小さく作る、1つのことを上手にやる、テキストで連携する等）を3つ以上挙げ、自チームの開発に1つ以上適用できる
• 学習形式: AIディスカッション

前のセッションで「設計思想は複数ある」と学びました。では、複数ある設計思想に共通する「土台」のような原則はあるのでしょうか？

答えはYesです。1970年代に生まれた「UNIX哲学」は、半世紀たった今もすべての設計思想の根っこに流れています。Linux、macOS、iOS、Androidも、Webアーキテクチャも、マイクロサービスも、DockerもKubernetesも、すべてUNIX哲学の影響下にあります。

ちょうど料理で言えば「だしの取り方」のようなものです。和食でも中華でも、ベースのだしが効いていれば味がまとまります。設計におけるUNIX哲学は、そのだしです。

UNIX哲学は1人の発明ではなく、ベル研究所のケン・トンプソン、デニス・リッチー、ダグラス・マキルロイらが少しずつ言語化してきたものです。代表的な原則を整理すると、次のようになります。

これらを現代風に圧縮した3つの頭文字語がよく登場します。

• KISS（Keep It Simple, Stupid）: 単純であれ
• DRY（Don't Repeat Yourself）: 繰り返すな
• YAGNI（You Aren't Gonna Need It）: それ、たぶん要らない

UNIXのコマンドラインは、UNIX哲学の生きた標本です。たとえば「ログファイルからエラーだけを抜き出して件数を数える」処理は、3つの小さなコマンドの組み合わせで書けます。

cat access.log | grep "ERROR" | wc -l

• cat: ファイルを表示するだけ
• grep: 検索するだけ
• wc: 数えるだけ

それぞれは1つのことしかしません。しかし、パイプ（|）でつなぐと、強力な処理になります。これがUNIX哲学の「小さな部品をテキストで連携する」思想です。

UNIX哲学の核心は「組み合わせやすい小さな部品を作る」ことにあります。「1つの巨大な機能」より「10個の小さな機能の組み合わせ」のほうが、変更にも再利用にも強いのです。

UNIXの生みの親、ケン・トンプソンは1969年、ベル研究所で「妻が実家に帰っている3週間」で初代UNIXを書き上げました。3週間で書けた理由は、「やることを最小限に絞った」からです。逆説的ですが、機能を削れば削るほど、ソフトウェアは速く完成し、長く生き残るのです。

KISS、DRY、YAGNIは抽象的に見えますが、現場ではこんなふうに現れます。

// NG: 凝りすぎ
const isEven = n => !!(n & 1 ^ 1);

// OK: シンプル
const isEven = n => n % 2 === 0;

// NG: 同じ計算が3回登場
const tax1 = price1 * 1.1;
const tax2 = price2 * 1.1;
const tax3 = price3 * 1.1;

// OK: 関数化
const withTax = price => price * 1.1;

// NG: 「いつか使うかも」で未使用の引数
function send(to, subject, body, cc, bcc, attachments, schedule, priority) { ... }

// OK: 今必要なものだけ
function send(to, subject, body) { ... }

DRYとYAGNIはときに対立します。「同じコードが2回出てきたら共通化（DRY）」vs「将来使わないかもしれない抽象化はしない（YAGNI）」。この判断はチームで議論する価値があります。

「銀の弾丸はない」で有名なフレデリック・ブルックスは、「セカンドシステム症候群」を警告しています。1作目を成功させたエンジニアは、2作目で「あれもこれも盛り込もう」として失敗しがちだ、というものです。YAGNIはこの罠を避けるための合言葉です。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「UNIX哲学を現代のWeb開発（React、Next.js等）に当てはめるとどうなる？」
• 「DRYとYAGNIが対立する具体例と、判断基準を教えて」
• 「マイクロサービスはUNIX哲学の現代版と言えるのはなぜ？」

チームで5分間、次のテーマを話し合ってください。

「自分たちの開発テーマに、UNIX哲学の原則を1つ適用するとしたら、どれを選ぶ？ なぜ？」

たとえば家計簿アプリなら「Do one thing well → 1機能ごとにモジュール分割」、レシピアプリなら「Store data in flat text → JSONでレシピを保存」など。

チームで選んだUNIX哲学の原則1つと、適用方法のメモ。AIに「この適用は妥当か？」を相談すること。

「全部適用しなければ」と気負わない。1つでも「これだけは守る」と決められれば、設計の軸ができます。

UNIX哲学は50年前の知恵ですが、現代のすべての設計思想に流れる「だし」のようなものです。KISS、DRY、YAGNIの3つは現場で頻繁に登場します。「小さく作る」「1つのことを上手にやる」「組み合わせで強力にする」を、自チームの開発でも意識しましょう。

次のセッションでは、UNIX哲学を土台にして発展してきた具体的な「設計アプローチ」（DOA、MDA、SOA等）を見ていきます。

• UNIX哲学の原則を3つ以上挙げられますか？
• KISS、DRY、YAGNIをそれぞれ自分の言葉で説明できますか？
• 自チームの開発に適用するUNIX哲学を1つ選び、理由を述べられますか？

• 参考リンク: マイク・ガンカーズ『UNIXという考え方』、エリック・レイモンド『The Art of Unix Programming』
• 発展課題: 自分が普段使うCLIコマンドを3つ挙げ、それぞれUNIX哲学のどの原則に従っているかを分析する