1. 【3.59．UNIX哲学④『効率性より移植性』②】
「移植性を重視した設計」によって得られる利点として最も適切なものはどれか？
解説： 移植性を重視することで、ソフトウェアが特定のハードウェアに縛られず、将来の変化にも柔軟に対応できるようになる。
堅牢なUNIXの哲学をクイズで学ぶ！
「UNIX哲学」要約＆クイズ
公開日：
最終更新日：
UNIX哲学は、効率的で堅牢なソフトウェアを生み出すための行動規範と判断基準です。本ページでは、この哲学の要点を要約で深く掘り下げます。
要約で哲学に基づいた設計とコーディングの秘訣を習得し、10問のクイズで知識を定着。時代を超えて通用する開発の真髄を身につけましょう！
UNIX哲学 目次
-
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問)
第３章：思想⑥
～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.59．UNIX哲学④『効率性より移植性』②】
2. 【3.57．UNIX哲学②『1つ1仕事』③】
次のうち「1つ1仕事」の原則を破っている例として最も適切なものはどれか？
解説： 「取得」と「整形」は本来別々の関心事であり、1つの機能に集中していないため「1つ1仕事」に反する。
3. 【3.63．UNIX哲学⑧『対話インターフェース回避』⑥】
CI/CDパイプラインから呼ばれるCLIツールを設計する。最適な入出力仕様は？
解説： 非対話・合成可能・観測可能という性質が、UNIX流の自動化に直結する。正解の選択肢はパイプや他ツールからの制御に適し、冪等なバッチ処理にも強い構成である。その他は“人待ち”を前提にし、再現性・自動化・運用効率を損なう。
4. 【3.56．UNIX哲学①『小は美なり』②】
「小さく始めて、小さいまま保つ」という設計方針の主な目的は何か？
解説： 「小さいまま保つ」ことによって、コードの複雑化を防ぎ、意図や処理の流れを見失わないようにすることが目的とされている。
5. 【3.55．UNIX哲学④】
UNIXの設計思想はなぜ「哲学」と呼ばれるのか？
解説： UNIXの「哲学」とは、具体的な実装や仕様にとどまらず、ソフトウェア設計におけるシンプルかつ普遍的な考え方を含んでいるためである。
6. 【3.64．UNIX哲学⑨『フィルタ化』④】
次のうち、「フィルタ化」の思想に合致するUNIXコマンドの例として最も適切なものはどれか？
解説： `grep` は「入力を受け取って加工（抽出）し、出力する」フィルタ型のコマンドであり、UNIX哲学の「フィルタ化」に最も適している。
7. 【3.60．UNIX哲学⑤『データはテキスト』②】
「データをテキストで保存する」ことの主な利点として適切でないものはどれか？
解説： テキスト形式は読みやすく扱いやすい点が利点だが、暗号化は別の処理で対応するものであり自動では行われない。
8. 【3.56．UNIX哲学①『小は美なり』③】
以下のうち、「小さなソフトウェアの利点」に該当しないものはどれか？
解説： 1つのソフトで全てをまかなう発想は「巨大で複雑な設計」につながり、「小は美なり」の哲学とは逆である。
9. 【3.63．UNIX哲学⑧『対話インターフェース回避』⑤】
UNIX哲学では、対話的インターフェースが有用とされる例外的な状況はどれか？
解説： 初心者には対話形式のほうが直感的で分かりやすいため、例外的に有用であり、熟練者向けの非対話形式と併設するのが望ましい。
10. 【3.59．UNIX哲学④『効率性より移植性』③】
次のうち、「移植性より効率性を優先した結果、起こり得る問題」として適切なものはどれか？
解説： 効率性を優先してハードウェアに依存した設計を行うと、他のプラットフォームでは動作しないコードになりやすい。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
