1. 【3.38．UNIX思想①『モジュール化の原則』①】
『UNIX思想』における「モジュール化の原則」の目的として最も適切なものはどれか？
解説： モジュール化の目的は、関係性の高い処理を集約し、影響範囲を局所化することで、保守性や拡張性を高めることにある。
AI×普遍の知恵、UNIX思想をクイズで学ぶ！
第3章：思想｜UNIX思想
公開日：
最終更新日：
AIが複雑なコードを吐きがちな今こそ、「小さく、組み合わせる」思想が効きます。本ページでは、『プリンシプル オブ プログラミング』第3章「UNIX思想」で紹介される、長寿なUNIXを支えた17の原則を、要点を押さえた要約と4択クイズで整理します。
要約でエッセンスをつかみ → 4択クイズ（10問・全問解説付き）で腕試し → 気になったところは解説で復習。「読む→解く→わかる」で、AI共創でも保守しやすい部品化と単純化の軸を身につけましょう。
3-3：AIが苦手な非機能要件クイズ！ 目次
-
3-3：AIが苦手な非機能要件クイズ！の要点・要約を読む(5分)
- 3.37 UNIX思想（UNIX Thought）
- 3.38 UNIX思想①：モジュール化の原則（Rule of Modularity）
- 3.39 UNIX思想②：明確性の原則（Rule of Clarity）
- 3.40 UNIX思想③：組み立て部品の原則（Rule of Composition）
- 3.41 UNIX思想④：分離の原則（Rule of Separation）
- 3.42 UNIX思想⑤：単純性の原則（Rule of Simplicity）
- 3.43 UNIX思想⑥：倹約の原則（Rule of Parsimony）
- 3.44 UNIX思想⑦：透明性の原則（Rule of Transparency）
- 3.45 UNIX思想⑧：安定性の原則（Rule of Robustness）
- 3.46 UNIX思想⑨：表現性の原則（Rule of Representation）
- 3.47 UNIX思想⑩：驚き最小の原則（Rule of Least Surprise）
- 3.48 UNIX思想⑪：沈黙の原則（Rule of Silence）
- 3.49 UNIX思想⑫：修復の原則（Rule of Repair）
- 3.50 UNIX思想⑬：経済性の原則（Rule of Economy）
- 3.51 UNIX思想⑭：生成の原則（Rule of Generation）
- 3.52 UNIX思想⑮：最適化の原則（Rule of Optimization）
- 3.53 UNIX思想⑯：多様性の原則（Rule of Diversity）
- 3.54 UNIX思想⑰：拡張性の原則（Rule of Extensibility）
- ソフトウェア入出力の箴言（Software Input/Output Proverbs）
- クイズに挑戦する(10問)
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(3-6：AI時代のミニマリズム、UNIX哲学クイズ！)
- 前のクイズへ(3-4：AIリファクタの軸、7つの設計原理クイズ！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想⑤
～UNIX思想～
3.37 UNIX思想（UNIX Thought）
要旨
UNIX思想は、長年使われてきたOS「UNIX」を作る中で育った設計・実装のコツ集。
「小さく分ける」「分かりやすくする」「組み合わせて使えるようにする」といった考え方は、今のWebサービスやアプリにもそのまま通用する。理由
UNIXが何十年も使われ続けているのは、最初の段階で良い設計ルールを決めて守り続けたから。
「単純さ」「明確さ」「組み合わせやすさ」を大事にした結果、あとから機能を増やしても壊れにくいシステムになった。結論
これから出てくるモジュール化（役割ごとの部品化）・明確性（分かりやすさ）・組み立て部品（つなげて使える部品）・分離（わけて考えること）・単純性（シンプルさ）などの原則を、設計レビューのチェックリストや普段のコードを書くときのマイルールとして使う。その他（効果）
- 仕様変更に強くなり、コードの変更がしやすくなる
- 部品を入れ替えたり再利用したりしやすくなる
- 中で何が起きているか観測しやすくなり、障害調査が楽になる
- 考え方の軸がそろい、学ぶ側の負担も小さくなる
3.38 UNIX思想①モジュール化の原則（Rule of Modularity）
要旨
関係が深い処理やデータをひとかたまりにまとめてモジュール（役割ごとの部品）にし、外から触れる入口は必要最小限のインターフェース（外部向けの窓口）だけにする。理由
なんでも１つのクラスや関数に押し込むと、少し直しただけで別の場所が壊れる。
モジュールごとに責任を分けておけば、バグや変更の影響をそのモジュールの中に閉じ込めやすくなり、全体を壊さずに改良できるから。結論
ソフトウェアは「モジュールの集合」として考える。モジュールは小さく／ゆるくつながり／役割がはっきりしている状態を目指す。
「このモジュールは何を担当していて、どこまでが仕事範囲か？」を、言葉で説明できるようにしておく。その他（指針）
💡AIワンポイント
モジュール化では、AIに公開関数を減らす方向でリファクタさせます。入口が多いほど互換維持コストが指数的に増えます。
3.39 UNIX思想②明確性の原則（Rule of Clarity）
要旨
「カッコいい一行」より「誰が読んでもすぐ分かる三行」を優先する原則。
書いた本人だけでなく、あとから読む人（未来の自分も含む）が一目で理解できるコードを目指す。理由
コードは一度書いて終わりではなく、何度も何年も読まれ続けるドキュメント（説明書）。
読みづらいコードは、バグ調査や機能追加のたびに「まず理解するコスト」がかかり、その分だけ時間もミスも増えるから。結論
変数名・関数名・クラス名は「役割が想像できる名前」にする。
インデントや改行で構造を見やすくし、コメントでは「なぜそうしたか（Why）」を書く。
読む人が「たぶんこういう意味かな？」と推理しないと分からない書き方は避ける。その他（実践）
- Why（なぜ）はコメントで、What / How（何を／どうするか）はコードで表現する
- 「この前提がある」「この制約がある」といった条件は、コメントや型・名前で見えるようにする
- レビューのとき「このコード、初めて見る人に5分で説明できるか？」をチェックポイントにする
💡AIワンポイント
明確性の原則として、AIが短縮記法を多用したら可読優先へ戻します。三項演算子の入れ子は一見速いが、保守時の誤読を増やします。
3.40 UNIX思想③組み立て部品の原則（Rule of Composition）
要旨
プログラム同士が「データのやりとり」で簡単につながるように作る原則。
テキストやJSON（データの書き方の決まり）のような分かりやすい形式で入出力を扱い、パイプ（流れのつなぎ目）のように組み合わせて使える部品にする。理由
テキスト形式の入出力は、他の言語やツールからも扱いやすく、中身の実装を知らなくても連携できる。
それぞれの部品は自分の仕事に集中でき、互いの内部構造を意識しすぎずに合体できるから。結論
独自バイナリ形式（自分たちだけの特別な形式）や、複雑すぎるシリアライズ（データの保存形式）に閉じ込める前に、シンプルなストリーム（流れるデータ）の設計を優先する。
CLI（コマンドラインツール）・バッチ処理・Webサービスなど、いろいろな場面で「つなげて使える」設計を目指す。その他（効果）
- 部品同士がゆるくつながるので、テストや差し替えが簡単になる
- CLIツールやバッチ処理、バックエンドの処理などを再利用しやすくなる
- ログを人間が読める形で出しやすくなり、監視・デバッグのしやすさも上がる
💡AIワンポイント
組み立て部品化を意識するなら、AIに入出力をJSON Linesなど直列可能な形へ寄せさせます。中間成果物をパイプしやすくなると検証が速いです。
3.41 UNIX思想④分離の原則（Rule of Separation）
要旨
「メカニズム（どう動くかの仕組み）」と「ポリシー（どう使うかの方針）」をはっきり分けて設計する原則。
例：ゲームなら「描画や入力の処理（メカニズム）」と「難易度やルール設定（ポリシー）」を分ける、など。理由
ポリシー（ルールや設定）はよく変わるが、メカニズム（動作の仕組み）はあまり変えたくない。
ここを一体化すると、少しルールを変えるだけで内部ロジックまで書き換える必要が出て、保守がつらくなるから。結論
「ここからここまでがメカニズム」「ここから先はポリシー」と境界を決めておく。
ポリシーを変えたいときは、設定ファイル・コンフィグ（設定情報）・DI（依存性注入）・プラグイン（あと付け機能）などで差し替えられる形にする。その他（例／適用）
- Webサービス：画面側（ポリシー）とAPI／ドメインロジック（メカニズム）を分ける
- エディタやIDE：設定・プラグイン（ポリシー）と編集エンジン（メカニズム）を分離する
- 「設定を書き換えるだけで振る舞いを変えられるか？」を設計のチェックポイントにする
💡AIワンポイント
分離の原則では、AIが判定ルールをコードへ埋め込んだら設定へ外出しします。運用で変わる値を実装と分離すると改修リードタイムが縮みます。
3.42 UNIX思想⑤単純性の原則（Rule of Simplicity）
要旨
設計や実装では、まず「シンプルであること」を最優先にする。
機能を足す前に、「本当に必要か？」と自分に問い直すクセをつける。理由
複雑さは、バグ・障害・開発コストの大きな原因。
放っておくとコードは自然に複雑になり、いつか誰も触れないブラックボックス（中身が分からない箱）になるから。結論
「Less is more（より少ないことは、より豊かなこと）」を合言葉にする。
最初は必要最小限の構成で出荷し、ユーザーの利用や実験を通じて「本当に必要」と分かったものだけを少しずつ追加していく。その他（文化・運用）
- 「シンプルにしてくれてありがとう」と言える文化を作る（やたらと複雑なコードを褒めない）
- 設計レビューでは「どこを削れるか？」を必ず話題にする（足す前に引く）
- 「トリッキーなコード」を自慢するのではなく、「素直で読みやすいコード」を評価する
💡AIワンポイント
単純性の原則に沿って、AI提案差分から未使用オプションを落とします。実装量を削るだけで障害面積が小さくなります。
3.43 UNIX思想⑥倹約の原則（Rule of Parsimony）
要旨
「大きいこと」「盛りすぎ」を避けて、小さく作る原則。
機能を足すときも「継ぎ足し」ではなく、できるだけシンプルな構造を保ちながら実現する。理由
巨大で複雑なシステムは、少し直すだけでも影響範囲が読めなくなり、そのうち誰も全体を理解できなくなる。
「複雑なコードをさらに複雑なコードでねじ伏せる」設計は、いずれ破綻するから。結論
まず削れないかを考え、それでも必要なものだけ足すという順番を守る。
関数やクラスはできるだけ小さな責任にとどめ、不要になった処理や使われていないコードは積極的に取り除く。その他（範囲・効果・実践）
- 関数の責任を一つに絞る（単一責任の原則）
- コピペで増えた似たようなコードは、共通化して重複を減らす
- ファイルの行数や関数の引数の数に「だいたいこのくらいまで」という目安を決めておく
💡AIワンポイント
倹約の原則では、AIが生成した長関数を早めに分解します。引数数と行数に上限を設けると、肥大化をレビューで止めやすくなります。
3.44 UNIX思想⑦透明性の原則（Rule of Transparency）
要旨
ソフトウェアの動きを外から見て理解できる状態にしておく原則。
「何をしていて、今どんな状態か」を確認できるようにしておくことで、トラブルに強くなる。理由
中で何が起きているか分からないと、バグ調査や障害対応は推理ゲームになり、時間と根気だけが必要になる。
最初から見えるようにしておけば、少ない情報で原因にたどり着けるから。結論
設計の初期段階から、ログ・メトリクス（数値で見る指標）・トレース（処理の流れの記録）など、観測する仕組みを組み込んでおく前提で設計する。
「本番コードだからデバッグしづらくてOK」ではなく、本番でも調査しやすいようにしておく。その他（実践）
- 構造化ログ（機械にも人にも読みやすいログ）・メトリクス（数値で見る指標）・トレース（処理の流れの記録）を意識して設計する
- ヘルスチェックや診断用エンドポイント（状態確認用のURL）を用意し、すぐ状態を確認できるようにする
- 障害が起きたときに「何が起きたか」を再現できるよう、必要な情報が自動で残る仕組みを作る
💡AIワンポイント
透明性を上げるには、AIコードに入力値と結果を結ぶログキーを埋めます。障害調査で再現不能になる主因は観測不足です。
3.45 UNIX思想⑧安定性の原則（Rule of Robustness）
要旨
ソフトウェアが多少の揺れやエラーでは簡単に落ちないようにしておく原則。
そのために、内部構造を分かりやすくし、制御の流れもシンプルに保つ。理由
不安定なシステムは、ユーザーから見て「信用できないサービス」になる。
少し入力が違うだけでエラーになったり、負荷が少し増えただけで止まるようでは、どれだけ機能が多くても価値が下がるから。結論
例外や異常系の処理を後回しにせず、正常系と同じくらい真面目に設計する。
読みやすい内部構造と単純な制御フローで、入力の揺れや予期しない状態にも耐えられる実装を目指す。その他（実践）
- コードレビューのとき、作者自身がコードの構造や意図をうまく説明できない場合、そのコードは危険信号と考える
- 特異値・極端な入力（空文字・最大値・想定外の形式など）を積極的にテストし、ツールや他のソフトからの入力でも壊れないことを確認する
💡AIワンポイント
安定性の原則として、AI提案を極端値テストに通します。空配列や巨大入力で崩れるなら、平常時の見た目が良くても採用しません。
3.46 UNIX思想⑨表現性の原則（Rule of Representation）
要旨
複雑な条件やルールは、できるだけ「コードのif文」ではなく「データ」として表現する原則。
テーブルや設定ファイルに落とし込むことで、全体が見渡しやすくなる。理由
入れ子だらけのif文や複雑なロジックは、人間にとって理解しづらい。
一方で、表や一覧の形になっているルールは、「どんなパターンがあるか」を直感的に把握しやすいから。結論
ロジックを複雑にするより、データ構造を工夫して表現力を持たせることを優先する。
「この分岐は設定ファイルやテーブルに出せないか？」と、いつも考えるクセをつける。その他（範囲・例）
- DBのカラムや設定ファイルに条件やルールを持たせて、コード側のifを減らす
- ルールテーブルやDSL（特定用途向けの小さな言語）で、意図を「書き下したデータ」として表す
- 後からルールを変えたいとき、できるだけコードではなくデータを変更するだけで済むようにする
💡AIワンポイント
表現性の原則では、AIに分岐条件のテーブル化を求めます。ルール変更をコード修正から設定差分へ移せると運用が軽くなります。
3.47 UNIX思想⑩驚き最小の原則（Rule of Least Surprise）
要旨
ユーザーや他の開発者が「こう動くだろう」と自然に想像する通りに動くインターフェースを目指す原則。
予想外の挙動（サプライズ）を減らして、学習コストを下げる。理由
同じような見た目や名前なのに挙動が違うと、人は強いストレスを感じる。
毎回使い方を調べ直す必要があり、ミスも増えるから。結論
用語・見た目・動きは、できるだけ一貫させる。
よく使われているソフトやWebサービスの慣習を参考にし、ユーザーがすでに持っている経験を最大限に活かせる設計を選ぶ。その他（設計指針）
- 似たような機能は、似たような名前・UI・操作方法にそろえる
- 他の有名サービスのインターフェースを研究し、「ユーザーがすでに知っているパターン」を優先的に採用する
- 「一見似ているのに微妙に違う挙動」を避ける（同じボタンなのに画面ごとに意味が違う、など）
💡AIワンポイント
驚き最小の原則では、AI生成CLIのオプション名を既存慣習に合わせます。同じ意味で別名を増やすとサポート負荷が増えます。
3.48 UNIX思想⑪沈黙の原則（Rule of Silence）
要旨
プログラムは必要なときだけ話す（出力する）、という原則。
ふだんは静かに動き、本当に重要な情報だけを前に出す。理由
メッセージが多すぎると、本当に重要なエラーや警告がメッセージの中に埋もれてしまう。
ユーザーも開発者も「何を見ればいいか」が分からなくなるから。結論
本物のエラーだけを標準エラー（エラーログ）に出し、進捗やデバッグ情報は「必要な人だけONにできるverboseモード（詳細ログモード）」などに回す。
ふだんは静かに、いざというときには必要な情報をきちんと出すように設計する。その他（範囲・実践）
- ログレベル（ERROR / WARN / INFO / DEBUG）の基準をチームで決める
- 不要なINFO・DEBUGログを削除または間引き、本当に必要な情報だけ残す
- CLIやサービスのデフォルトはサイレント寄りにし、詳細はオプション（例：
-v）や設定で切り替える
💡AIワンポイント
沈黙の原則として、AI提案の標準出力を成果物だけに絞ります。詳細はverboseへ退避し、パイプ連携を壊さない設計にします。
3.49 UNIX思想⑫修復の原則（Rule of Repair）
要旨
どうしても回復できないエラーに当たったら、その場で大きく・はっきり失敗する（fail fast & loud）という原則。
ごまかしながら無理に動き続けないようにする。理由
エラーを握りつぶして処理を続けると、その場では一見動いているように見えても、後で原因不明の不具合として現れる。
被害範囲も広がり、調査も難しくなるから。結論
回復できないエラーを検知したら、その時点で処理を止め、ログやアラートで大きく知らせる。
「大きく失敗」することで問題にすぐ気づき、再発防止もしやすくなる。その他（範囲・実践）
- エラーを握りつぶさず、例外やエラーコードとして必ず表に出す
- エラー時にどうするか（ロールバック／再試行／その機能だけ止める など）をあらかじめ決めておく
- アラートの基準や通知先を整え、問題が起きたらすぐ気づけるようにする
💡AIワンポイント
修復の原則では、AIに失敗時の停止条件を明示させます。回復不能エラーを継続実行すると、後段で汚染データが広がります。
3.50 UNIX思想⑬経済性の原則（Rule of Economy）
要旨
一番高価なのは「人間（プログラマ）の時間」という前提に立つ原則。
マシンやツールへの投資は、結果的に開発コストを下げるための節約になる。理由
遅いPC、使いづらいツール、整っていない情報環境では、待ち時間と手作業がどんどん増える。
そのぶん品質もモチベーションも落ちていくから。結論
性能の良いマシンや、テスト・デバッグ・自動化を助けるツールには、積極的に投資する価値がある。
開発プロセスのどこがボトルネック（詰まりどころ）になっているかを観察し、そこに時間とお金を使う。その他（効果）
- ビルドやテストの時間短縮 → トライ＆エラーの回数を増やせる
- レビューの効率が上がり、早い段階で不具合を見つけられる
- ムダなストレスが減り、離職や燃え尽き（バーンアウト）の防止につながる
💡AIワンポイント
経済性の原則では、AI導入で削れる待ち時間を数値で見ます。レビュー準備やテスト実行の自動化に投資すると、日次の総時間が減ります。
3.51 UNIX思想⑭生成の原則（Rule of Generation）
要旨
「コードを書くコード」（ジェネレータ・テンプレート・スキャフォールド・AIなど）を活用し、くり返し作業を自動化する原則。理由
人間は細かい同じ作業を何度もくり返すのが苦手で、コピペや手打ちが増えるとミスや不整合の元になる。
毎回似たようなコードを手で書くより、自動で生成したほうが品質もそろいやすいから。結論
CRUD（データの作成・読み取り・更新・削除）の雛形やAPIのクライアントコードなど、パターンが決まっている部分は機械に任せ、人間は「どんな設計にするか」「生成されたコードをどう使うか」に集中する。その他（範囲・実践）
- API定義やモデル定義から、自動的にコードを生成する
- 設定ファイルやスキーマ（データの型の設計）を変えるだけでコードを再生成できる仕組みを整える
- CI（継続的インテグレーション：継続的な自動テスト）で生成物の変更を検知し、ズレがあればすぐ気づけるようにする
💡AIワンポイント
生成の原則を使うなら、AI生成物は再生成可能な手順とセットで管理します。手修正混入を検知するチェックをCIへ置くと破綻しません。
3.52 UNIX思想⑮最適化の原則（Rule of Optimization）
要旨
「速さ」より先に「正しさ」を優先する原則。
まず仕様どおりに正しく動くものを作り、そのあとで本当に必要なところだけを計測しながら最適化する。理由
最初から速度だけを追いかけると、コードが複雑になり、バグも増える。
しかも、実際には別の場所がボトルネックだったということもよくあるから。結論
最適化は「必要性の確認 → 計測 → ボトルネック修正 → 再計測」という手順で行う。
また、いらない処理を削除することが最大の最適化である、という視点も持っておく。その他（実践）
- 安定した部分（めったに変えない部分）から最適化し、不安定な部分はまずシンプルな実装で学ぶ
- 使われていない分岐やデータを削ることで、読みやすさと性能を同時に改善する
- 「なんとなく遅そうだから」ではなく、必ず計測に基づいて手を入れる場所を決める
💡AIワンポイント
最適化の原則では、AIの高速化提案を一気に入れず一本ずつ検証します。改善前後の計測ログを残して、逆効果なら即戻します。
3.53 UNIX思想⑯多様性の原則（Rule of Diversity）
要旨
「絶対的な正解」は存在しないという前提に立ち、文脈に応じて最適な選択肢を選ぶ原則。
言語・フレームワーク・アーキテクチャなどには、それぞれ得意・不得意がある。理由
現実のシステムは、用途も規模も要件もバラバラ。
ある現場ではベストだった方法が、別の現場では逆効果になることもあるから。結論
原理・原則やベストプラクティス（よく知られた良い方法）は「あくまで指針」として扱う。
断定的な主張をそのまま受け入れず、いつも複数案をならべて比較・検証する姿勢を大切にする。その他（範囲）
- 言語・フレームワーク・インフラ構成・開発プロセスなどの選択肢を比較し、「なぜそれを選んだか」を記録しておく
- 他のチームやプロジェクトのやり方を観察し、「自分たちに合う形」にアレンジして取り入れる
💡AIワンポイント
多様性の原則として、AIには異なる実装方針を最低二案出させます。採用理由を記録しておくと、将来の技術移行判断が速くなります。
3.54 UNIX思想⑰拡張性の原則（Rule of Extensibility）
要旨
将来の拡張をあらかじめ想定し、既存ユーザーを壊さずに機能を足したり差し替えたりできるように設計する原則。理由
最初の設計だけで完璧なものを作ることはほぼ不可能。
拡張の余地がない設計だと、成長のタイミングで「ほとんど作り直し」に近い苦労が発生するから。結論
プラグインやイベント、拡張ポイントなど、「ここから先は後から足せる」位置をあらかじめ用意しておく。
「将来ここにフック（引っかける場所）を用意するつもり」という意図をコメントや設計書に残しておくことで、自分や他人が後から拡張しやすくなる。その他（実践）
- 拡張したい処理は、インターフェース・イベント・プラグインなどで外出しし、コア部分の改変は最小限にする
- コア部分の仕様（契約）はできるだけ固定し、中身の実装は差し替え可能にしておく
- 新機能追加時には、既存ユーザーの動作が変わらないように後方互換性（古いままでも動く性質）を意識する
💡AIワンポイント
拡張性を狙うなら、AIが追加するフック点に利用例を付けさせます。使い道の無い拡張ポイントは将来の負債になりやすいです。
ソフトウェア入出力の箴言（Software Input/Output Proverbs）
要旨
入力にはできるだけ寛容に、出力はきちんと厳格に、という考え方。
ただし「寛容」は入力の扱い方の話であって、仕様そのものをバラバラに解釈してよい、という意味ではない。理由
入力に少しゆらぎがあっても受け止められると、他のシステムとの連携がしやすくなる。
しかし、各実装が好き勝手に仕様を解釈し始めると、「どれが正しいのか分からない状態」になり、HTMLの歴史のように混乱が起きるから。結論
入力はバリデーション（検証）と正規化（形式をそろえること）を行ったうえで、意味をできる範囲で汲んで受け取る。
一方、出力は規格やスキーマ（データ形式の決まり）にきちんと従って、クリーンで正確な形で出す。
仕様の解釈そのものは、厳密で一貫したものに保つ。その他（実践）
- 入力値は型・範囲・形式をチェックし、許せる揺れは正規化（例：全角→半角、大小文字の統一）してから処理する
- どうしても受け入れられない場合は、理由を明確にしたエラーメッセージを返す
- 出力はJSON Schemaやプロトコル（HTTP / REST / gRPCなど）に沿っているか、自動テストで確認する
💡AIワンポイント
入出力の箴言では、AIが作る受信処理に正規化層を置きます。受け入れは広く、外部へ返す値はスキーマ検証で厳密に固定します。
プリンシプル オブ プログラミング(第３章－UNIX思想)
1. 【3.38．UNIX思想①『モジュール化の原則』①】
2. 【3.47．UNIX思想⑩『驚き最小の原則』①】
「驚き最小の原則」において、ユーザーにとって最も重要な設計方針はどれか？
解説： 「驚き最小の原則」とは、ユーザーが「そう動くと思った通りに動く」ことに価値を置く設計原則である。意外性より予測可能性が重要。
3. 【3.38．UNIX思想①『モジュール化の原則』③】
「モジュール化の原則」に従った設計で、望ましい構成はどれか？
解説： モジュール化では、関連性の高い要素をまとめ、関係性の低いものとは疎結合とするのが理想的な設計である。
4. 【3.37．UNIX思想④】
次のうち、『UNIX思想』に関する記述として適切でないものはどれか？
解説： UNIX思想は、今でも十分に有効な考え方であり、「古いから通用しない」という評価は誤りである。
5. 【3.51．UNIX思想⑭『生成の原則』②】
「生成の原則」に反する行動はどれか？
解説： 同じ構造をコピペで量産する行為は、ミスの温床になり保守性も悪くなるため、生成の原則に反する。
6. 【3.42．UNIX思想⑤『単純性の原則』②】
次のうち、「単純性の原則」に反する設計として最も適切なのはどれか？
解説： ワンライナーなどの技巧的な記述は一見スマートに見えるが、可読性を損ねやすく、「単純性の原則」に反する。
7. 【3.49．UNIX思想⑫『修復の原則』③】
「入力には自由主義的、出力には保守主義的」とは、どのような意味か？
解説： この考え方では、入力には寛容に対応する一方で、出力には高い品質と一貫性を持たせるべきとされている。
8. 【3.47．UNIX思想⑩『驚き最小の原則』②】
次のうち、「驚き最小の原則」に最も反する設計はどれか？
解説： 見た目と挙動が一致しないUIは「驚き」を生み、ユーザーの混乱や不信感につながる。これは原則に反している。
9. 【3.44．UNIX思想⑦『透明性の原則』⑤】
「透明性の原則」に基づく設計方針として最も適切なのはどれか？
解説： 「透明性の原則」では、ログ出力や監視の仕組みなど、可視化の手段を設計初期から設けることで、保守性と信頼性を高めることが推奨される。
10. 【3.37．UNIX思想①】
『UNIX思想』とは何か？
解説： 『UNIX思想』は、優れたプログラミングのために培われた実践的な「技」の集合であり、UNIX文化の中で育まれてきたものである。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
