1. 【3.57．UNIX哲学②『1つ1仕事』④】
「1つ1仕事」の原則を無視すると、どのような問題が起きやすいとされているか？
解説： 多機能を1つのソフトに詰め込むと、処理の流れや目的が不明瞭になり、スパゲッティ・コード化しやすい。
堅牢なUNIXの哲学をクイズで学ぶ！
「UNIX哲学」要約＆クイズ
公開日：
最終更新日：
本ページでは、『プリンシプル オブ プログラミング』第3章「UNIX哲学」で取り上げられる、「1つのことをうまくやる」などの9つの哲学と、それを補強する10の小定理について、要点を押さえた要約と4択クイズで整理します。
要約でUNIX哲学が目指す設計の姿をつかみ → 4択クイズ（10問・全問解説付き）で理解度をチェック → 気になった部分は解説で復習。「読む→解く→わかる」のサイクルで、長年にわたって堅牢なUNIXを支えてきた哲学を、自分のプログラムや設計にも生かせる考え方の軸として身につけていきましょう！
3-6.堅牢なUNIXの哲学をクイズで学ぶ！ 目次
-
3-6.堅牢なUNIXの哲学をクイズで学ぶ！の要点・要約を読む(5分)
- 3.55 UNIX哲学（UNIX Philosophy）
- 3.56 小は美なり（Small is beautiful）
- 3.57 １つ１仕事（Make each program do one thing well）
- 3.58 即興プロトタイプ（Build a prototype as soon as possible）
- 3.59 効率性より移植性（Choose portability over efficiency）
- 3.60 データはテキスト（Store numerical data in flat ASCII files）
- 3.61 レバレッジ・ソフトウェア（Use software leverage to your advantage）
- 3.62 シェルスクリプト活用（Use shell scripts to increase leverage and portability）
- 3.63 対話インターフェース回避（Avoid captive user interfaces）
- 3.64 フィルタ化（Make every program a filter）
- UNIX哲学：小定理（UNIX little theorem）
- クイズに挑戦する(10問)
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(第4章：設計で迷わない目をクイズで養う！)
- 前のクイズへ(3-5.長寿のUNIXの思想をクイズで学ぶ！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想⑥
～UNIX哲学～
3.55 UNIX哲学（UNIX Philosophy）
要旨
UNIX哲学は、OS「UNIX」を作る中で育ってきた「どう設計し、どう作るか」の考え方セット。
小さく作る・一仕事に集中する・早く試す・移植性（別環境に移しやすい性質）・テキスト志向・組み合わせ活用などをまとめたもの。理由
この考え方を軸にしてきたからこそ、UNIX系のソフトウェアは何十年も第一線で動き続けている。
考え方そのものが普遍的（時代をこえて通用する）で、Webサービスやクラウドなど今の開発にもそのまま使えるから。結論
ここから出てくるそれぞれの原則を、日々の設計・コーディング・運用のチェックリストとして使う。
判断に迷ったときの「よりどころ」として、UNIX哲学に立ち返る。その他（範囲）
設計（どう作るか）／実装（どう書くか）／運用（どう動かすか）の全部で、意思決定の軸として活用する。
3.56 UNIX哲学①小は美なり（Small is beautiful）
要旨
ソフトウェアは小さく・シンプルに作るほど価値が高くなる、という考え方。
やることを絞り、コード量や機能をむやみに膨らませない。理由
小さいプログラムは、理解しやすく、直しやすく、軽く（CPUやメモリの負荷が小さく）、他と組み合わせやすい。
逆に巨大なプログラムは、理解もデバッグも難しくなり、想定外の入力や障害に弱くなる。結論
小さく始めて、小さいまま保つことを基本にする。
機能追加は「本当に必要か？」を確かめてから慎重に行い、Less is more（より少ないことは、より豊かなこと）を合言葉にする。その他（効果・具体）
- 小さいコードは、読みやすく理解しやすい → レビューや学習が楽になる
- 修正範囲も小さくなり、バグの影響範囲も限定しやすい
- 軽いので、古いマシンや小さな環境でも動かしやすい
- いくつかの小さなツールを組み合わせることで、柔軟に新しい機能を作れる
3.57 UNIX哲学②１つ１仕事（Make each program do one thing well）
要旨
1つのプログラム（関数／モジュール）は1つの役割だけを、きちんとやるようにする原則。
あれもこれも詰め込まず、「この子はこれを担当」とはっきり決める。理由
役割を絞ると、不要なものを削りやすくなり、本質（何をしたいのか）が見えやすくなる。
結果として理解しやすく、テストしやすく、再利用しやすい部品になる。結論
「取得」と「整形」など、関心ごとが違う処理は必ず分ける。
コードのレベルでは、1文1処理（1つの文に1つの動作）を基本にし、長い複合文に詰め込まない。その他（例・注意）
- 例：ディレクトリ一覧
- ①ファイル情報を取得する処理
- ②人間向けに一覧を整形して表示する処理
- 1つの関数があれもこれも抱え込むと、スパゲッティコード（絡まったコード）になりやすい
- 関数名・引数・コメントが「この関数は1つの仕事に集中しているか？」のチェックポイントになる
- 例：ディレクトリ一覧
3.58 UNIX哲学③即興プロトタイプ（Build a prototype as soon as possible）
要旨
できるだけ早くプロトタイプ（動く試作品）を作り、手を動かしながら考える原則。
頭の中だけで考えず、早く形にして試す。理由
メカニズム（どう動くかの仕組み）はわりと安定するが、ポリシー（どう使うかの方針）は変わりやすい。
早く画面や動きが見えると、「そもそもの前提が違う」「欲しいのはこの機能じゃない」といったズレに早く気づける。結論
早期プロトタイプ → 短いサイクルで改善 → 段階的リリースという流れで最適な形に近づけていく。
最初から完璧を狙わず、「まず動くもの」「使ってもらってフィードバックをもらうもの」を目指す。その他（効果・段階）
- 前提や要件の勘違いに早く気づける → 後の手戻り（やり直し）を減らせる
- 初期の段階から実際の動きで確認できるので、欠陥や使いにくさを早めに発見できる
- 典型的な変化の流れ
- ① 高性能だけど機能不足の段階（まず動かす）
- ② 機能を盛りすぎて性能が落ちる段階（欲張りすぎ）
- ③ 不要なものを削って、必要十分な機能と性能のバランスが取れた段階
3.59 UNIX哲学④効率性より移植性（Choose portability over efficiency）
要旨
「効率（速さ）」と「移植性（別の環境に持っていきやすさ）」がぶつかったら、移植性を優先するという考え方。理由
ある環境だけでしか動かない高速コードより、いろいろな環境で長く動かせるコードのほうが、トータルで見ると価値が高い。
移植コストが低いと、新しい環境やCPUに対応する余裕ができ、その分新機能や品質改善に時間を回せるから。結論
ハードウェア依存の部分はきちんと切り出し、その他の大部分は環境に依存しない形で書く。
抽象化（共通化して隠すこと）や層分離（レイヤー分け）を使い、移植しやすいアーキテクチャを選ぶ。その他（実践）
- OS／CPU依存の処理は専用モジュールにまとめ、インターフェース越しに呼び出す
- 標準ライブラリや標準規格（POSIXなど）を優先し、ベンダー独自機能にロックインされないようにする
- 「この最適化は、この環境だけの裏技になっていないか？」を常に自問する
3.60 UNIX哲学⑤データはテキスト（Store numerical data in flat ASCII files）
要旨
データの保存ややりとりには、テキスト形式（人が読める文字データ）を基本にする、という原則。
昔はASCII（文字コードの一種）の素朴なテキスト、今ならJSONやCSVなどがこれにあたる。理由
テキストは最もポータブルで、多くのツールからすぐ扱える。
人が目で見て確認しやすく、ログやデバッグでも強い。バイナリ専用形式だけに閉じると、ツールも人間も扱いづらくなる。結論
独自バイナリ形式は「どうしても必要なところ」に限り、基本は標準的なテキスト形式を採用する。
テキストI/O（テキストの入出力）を前提に、パイプ連携や他ツールとの組み合わせを設計に織り込む。その他（補足）
- 構造化データはJSONやYAMLなど、広く使われているテキスト形式を選ぶ
- 表のようなデータはCSV/TSVで扱い、既存ツール（表計算・スクリプト）をフル活用する
- テキストで持つことで、差分ツール（diff）やバージョン管理（Git）とも相性が良くなる
3.61 UNIX哲学⑥レバレッジ・ソフトウェア（Use software leverage to your advantage）
要旨
レバレッジ（てこの原理）のように、すでにある良いソフトウェアを組み合わせて使い、少ない労力で大きな成果を出す、という考え方。理由
「良いプログラマは良いコードを書く。偉大なプログラマは良いコードを借りてくる」という言葉があるように、再利用は開発スピードと品質の両方を上げる。
一から全部書くより、信頼できる部品を組み合わせたほうが、バグも少なくなる。結論
巨大な一体型システムを作るより、単機能のツールとグルー言語（つなぎ役のスクリプトやシェル）で構成し、全体として大きな仕事をさせる。その他（実践）
- 既存ライブラリやCLIツールを調査し、「車輪の再発明」を避ける
- 小さなコマンドをパイプやスクリプトで連結し、大きな処理フローを組み立てる
- 内製コードは、自分たちの強みやドメイン知識が生きる「核」の部分に集中させる
3.62 UNIX哲学⑦シェルスクリプト活用（Use shell scripts to increase leverage and portability）
要旨
シェルスクリプト（コマンドを並べて書く小さなプログラム）を「グルー言語（つなぎ役の言語）」として使い、既存コマンドの力を引き出す原則。理由
UNIXには多くのコマンドがあり、それぞれが単機能のツールとしてよくできている。
シェルスクリプトはそれらをパイプでつなぎ、自動化し、まとめて動かすための道具。多くの環境で動くので、移植性も高い。結論
小さなソフトをパイプで連結し、シェルスクリプトから編成・自動化して、大きな仕事をこなすスタイルを基本にする。その他（実践ヒント）
- 標準入力・標準出力・標準エラー、終了コード（0=成功／0以外=失敗）を正しく使い、連結しやすくする
- POSIX準拠のシェルやコマンドを意識して書き、できるだけ多くの環境で動くようにする
- 対話的な質問に頼らず、設定ファイルや引数で動作を切り替えられるようにする
3.63 UNIX哲学⑧対話インターフェース回避（Avoid captive user interfaces）
要旨
クリックや入力を何度も要求するような「対話専用UIだけ」のソフトは避け、スクリプトからも使えるインターフェースを優先する原則。理由
対話だけに頼ると、毎回操作方法を覚え直す必要があり、自動化もしづらい。
入力待ちで時間を失いやすく、処理内容も他のソフトから見えにくくなる。結果として、「小は美なり」や「レバレッジ」の考え方にも反する。結論
基本は非対話型（CLI（Command Line Interface）／設定ファイル／ファイルI/O）で動かせるようにし、必要なら初心者向けにGUIや対話UIを「追加で用意する」形にする。その他（問題点の内訳）
- アプリごとに独自UIを覚える必要があり、学習コストが高くなる
- ボタン操作前提だと、ソフト同士が直接「会話（連携）」しづらい
- 人の入力待ち時間が増えて、夜間バッチなどの自動処理にも向かない
- あいまいな入力を解析するコードが巨大になり、かえって中身が複雑になる
3.64 UNIX哲学⑨フィルタ化（Make every program a filter）
要旨
すべてのプログラムを、「データを受け取って加工し、またデータとして返す」フィルタとして設計する原則。
フィルタ＝流れてきたデータを変換する部品、というイメージ。理由
人やシステムが扱うデータ処理の本質は「変換」。
フィルタとして設計しておくと、組み合わせやすく、再利用しやすく、テストもしやすい部品になる。結論
標準入力 → 処理 → 標準出力（＋エラーは標準エラー）という流れを基本に設計する。
ファイルや他のプログラムとつなぎやすい「直列パイプライン」を意識する。その他（設計要点）
- テキスト（例：JSONやCSV）を基本形式にしておくと、他ツールと連結しやすい
- 内部状態をできるだけ少なくし、副作用（思わぬ場所を書き換えること）を避ける → チェーン（連結）に強くなる
- 終了コードとエラーメッセージで、成功／失敗や原因をはっきり伝える
UNIX哲学小定理（UNIX little theorem）
要旨
UNIX哲学を細かい場面で使いやすくするための、小さな指針セット。
日々の「ちょっとした選択」の積み重ねが、移植性・生産性・保守性の差になっていく。理由
大きな設計方針だけでなく、命名・ログ・並列処理などの細部も、長い目で見ると大きな影響を持つから。結論
以下の10項目を、重くなりすぎないチーム共通ルールとしてゆるく適用し、UNIX的な実用主義を徹底する。その他（小定理一覧）
①環境カスタマイズ
ユーザーが自分の好みに合わせて調整できる余地を用意する。
設定ファイル・エイリアス・スクリプトなどで「自分仕様」にできるようにする。②軽薄短小カーネル
カーネル（OSの核となる部分）は小さく保ち、追加機能は外側のアプリやライブラリで拡張する。③小文字使用
コマンド名やファイル名は、短く・小文字でそろえ、入力と読みやすさを両立させる。④森林保護
紙に印刷して配るより、検索・編集・再利用しやすいデジタル文書を活用する。⑤沈黙は金
意味のない出力を避け、本当に重要な情報だけを表示する。
ログレベルやverboseモードで調整できるようにする。⑥並列思考
仕事を小さく分割し、並列実行（同時に動かすこと）でスループット（こなせる量）を上げる。⑦商品コラボレーション
小さな部品同士を組み合わせて、単体を足し合わせた以上の価値を生み出すことを意識する。⑧90パーセント解
最後の10%に固執していつまでも完成しない状態を避け、現実的にちょうどよい解を狙う。⑨劣るが優る
一見「地味で劣って見える」方式でも、最大公約数（みんなが使える共通部分）を大事にしたほうが、長く生き残ることが多い。⑩階層指向
自然界と同じように、システムも階層構造で整理する。
大きな単位 → 中くらい → 小さな単位というふうに分けて、理解しやすくする。
プリンシプル オブ プログラミング(第３章－UNIX哲学)
1. 【3.57．UNIX哲学②『1つ1仕事』④】
2. 【3.61．UNIX哲学⑥『レバレッジ・ソフトウェア』②】
「良いプログラマは良いコードを書く。偉大なプログラマは良いコードを借りてくる」という格言が示す考え方はどれか？
解説： この格言は、「既存の良いソフトウェアやコードを活用することで、自分の生産性や成果を高めることができる」という考え方を表している。
3. 【3.58．UNIX哲学③『即興プロトタイプ』⑥】
要件が曖昧な新機能。最も価値の高い最初の一手は？
解説： プロトタイプは不確実なポリシーを早期に検証し、学習を最大化する。正解の選択肢はユーザーの現実の文脈で動く“最小”を届けるため、誤った前提の早期発見・手戻り削減に繋がる。
4. 【3.55．UNIX哲学③】
UNIX哲学の重要性に関して、ソフトウェア開発者が取るべき姿勢として最も適切なものはどれか？
解説： UNIX哲学は、その普遍性と優秀さにより、ソフトウェアの設計方針やプログラミングに積極的に取り入れるべきだとされている。
5. 【3.57．UNIX哲学②『1つ1仕事』⑤】
「1つ1仕事」の原則は、文や関数の設計においてもどのように応用できるとされているか？
解説： 関数や文においても「1つのことだけを書く」ようにすることで、読みやすく保守しやすいコードになる。
6. 【3.62．UNIX哲学⑦『シェルスクリプト活用』②】
「シェルスクリプトを使うと自ら実装する必要がなくなる」とされる理由として正しいものはどれか？
解説： シェルスクリプトは既存のコマンドやツールを呼び出してつなぎ合わせるため、自分で処理の詳細を再実装する必要がない。
7. 【3.60．UNIX哲学⑤『データはテキスト』③】
「バイナリ形式を可能な限り避ける」理由として、UNIX哲学における考え方で正しいものはどれか？
解説： バイナリ形式は中身を確認しにくく、また環境依存が強くなるため、UNIX哲学ではテキスト形式が好まれる。
8. 【3.63．UNIX哲学⑧『対話インターフェース回避』⑥】
CI/CDパイプラインから呼ばれるCLIツールを設計する。最適な入出力仕様は？
解説： 非対話・合成可能・観測可能という性質が、UNIX流の自動化に直結する。正解の選択肢はパイプや他ツールからの制御に適し、冪等なバッチ処理にも強い構成である。その他は“人待ち”を前提にし、再現性・自動化・運用効率を損なう。
9. 【3.62．UNIX哲学⑦『シェルスクリプト活用』⑥】
日次バッチで複数の小ツールを順に実行し、失敗時は停止・通知したい。最適な実装は？
解説： シェルはUNIXの“接着剤”。正解の選択肢は移植性の高い手段（標準入出力・終了コード・リダイレクト）で合成し、失敗を早期に検出・停止できる。
10. 【3.55．UNIX哲学⑤】
以下のうち、「UNIX哲学」の活用として適切なものはどれか？
解説： UNIX哲学は、シンプルで柔軟、かつ拡張しやすい設計原則として他の開発にも応用できるものであり、それを自らの設計に取り入れることが重要である。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
