はじめに
読んでおいた方がいいような気がしたので買って読みました。
130ページぐらいのさくっと読める感じで、日本語版の第1版は2001年に出ているやや古めの本です。
2001年の頃の私はといえば、ブランコで最高地点に行ったときに飛び降りて鮮やかに着地する遊びに命をかけていたような気がします。
感想
なんか UNIX だとライセンスまわりが面倒だからそれの完全オープンソース版として LInux ができた、みたいな話をどこかで読んだことあるなぁ〜ぐらいの認識でした。
なんか本を読んでいるとソースコードをバンバン公開して不特定多数のみんなでモリモリ開発することで、 UNIX をどんどん強くしていこう！的なこと（本書では梃子（てこ）の原理と呼んでいます）を推奨していて、なんとなく脳内で Linux のことだと微妙に勘違いして読み進めていました。
多分今の時代の我々が想像するようなマジなオープンソースではなく、特定の企業に属するようなものでソースコードが完全に秘匿されている訳ではない感じ、のことなのかなぁと想像しています。歴史マニアになりたい訳ではないのでこの辺りを深掘りしてはいないですがね。
カーネルの設計思想というよりはもう少し高級なツール群のことについて述べられています。
本書の中で挙げられている UNIX 哲学 は9つ（ 定理 と書いてありました）あって、これ自体はググれば出てくるので多分ここに書いてもいいと思うので一応書きますね。
ググって出てくるなら書かなくてもいいだろとは思いますが、せっかくなので書きます。
- スモール・イズ・ビューティフル
- 一つのプログラムには一つのことをうまくやらせる
- できるだけ早く試作を作成する
- 効率より移植性
- 数値データはASCIIフラットファイルに保存する
- ソフトウェアの梃子を有効に活用する
- シェルスクリプトを使うことで梃子の効果と移植性を高める
- 過度の対話的インタフェースを避ける
- すべてのプログラムをフィルタにする
抽象的な 定理 とやたら具体的な 定理 が登場しますが、具体的な方についても「今風に解釈するならこうかなぁ」というのは大体イメージできるかと思います。
本書ではこの9つの定理だけではなく、UNIX 哲学として全員に認められているかは議論の余地があるけどきっと大多数の人はわかってくれるだろう、てきな定理も10個紹介されています。
1~3 について
まず 1. スモール・イズ・ビューティフル ですが、これはまぁマイクロサービスと同じような考え方ですよね。 大は小を兼ねる、ではなく小さいものをその都度必要なだけ用意して組み合わせていくという発想です。 ちゃんとモジュール化しようねというお話です。
2. 一つのプログラムには一つのことをうまくやらせる も似たようなところですね。
3. できるだけ早く試作を作成する はアジャイルというかプロトタイピングみたいなもんですね。
この 1 ~ 3 はリンクしていて、適切にスコープを管理して小さい機能を早い段階でリリースし、その使い心地を確かめてもらって改善していくやつです。 このあたりで本文中に出てくる「 ソフトウェア開発に終わりはない。あるのはリリースだけだ。 」という格言がとても良いですね。
このへんの今でこそ割とベタなお話が最初に書かれているのですが、この本にはまた別の視点も書かれてまして、「人間には三つのシステムしか作れない」という話ですね。
この「三つ」というのは時系列でみたときの話で、一つ目は荒削りでコアとなるコンセプトのみを実現したようなソフトウェアを指します。この段階では必要に迫られて、ある少人数が必要なものだけを詰め込んだ形でまずリリースします。 するとそれをみたたくさんの人が「こいつぁいいや！」と気に入って広まるのですが、欲しい機能は人によって微妙に違うので、色々と機能追加しようとする流れができてきます。こうしてソフトウェアが肥大化していくのが二つ目のソフトウェアとなります。 なんかみんながコントリビュータとして名を残そうとして大したことない人たちが専門家ヅラして色々口出してくるのでヒデェ事になる、とやたらキレた感じの記述があります。
4~5 について
ここまでの流れでは「とにかく小さくて単純なものを早く作ろう」という話だったのですが、 4. 効率より移植性 では多少効率が落ちたりソフトウェアが大きくなったりしても移植性を優先しよう、という話になります。 移植性を確保することでソフトウェアそのものの寿命も長くなるし、また開発した当初は多少効率面で不利なことがあったとしても移植されていくうちにPCの性能も上がって効率の問題はすぐに気にならなくなる、という話ですね。
5. 数値データはASCIIフラットファイルに保存する はやたら具体的な話ですが、定理4と関連した移植性・互換性の話とあと人間に読める形式にすることでメンテしやすくなるという感じです。 人間にも読める形式のテキストファイルをプログラム間のインタフェースにするのは大事ですよね。
6~7 について
6. ソフトウェアの梃子を有効に活用する はあれです、小さい労力で大きな成果を得ることを「てこの原理」になぞらえて説明しています。
まず自分が開発するときはソースコードを借りてくることで車輪の再開発を避け、またそれで自分が作ったものを今度は公開することで次の開発に生かす、そうして UNIX 全体を発展させていく、こうして UNIX は覇権を取りつつあるんだぜ！といった感じです。
今でこそ GitHub でコードを公開したり、パッケージ管理ツールで気軽にイカしたライブラリを入手して使ったりできるので、あんまり意識することはないですが大事なことですよね。
てこの原理自体はいろんな場面で有効な例え話なので、ツールをうまく使ったタスクの自動化の具体例として 7. シェルスクリプトを使うことで梃子の効果と移植性を高める が紹介されています。
各種コマンドのソースコードの合計が例えば10000行になったとして、それらのコマンドを使ってワンライナーのスクリプトを書いたとしたら「たった1行で10000行文の機能が得られた！これが梃子の効果だ！」という訳です。
シェルスクリプトはインタプリタ言語なので、この本が書かれた当時に主要な言語だったC言語と比べてコンパイルする手間が減ります。 なのでその分思考のプロセスとの時差が少ないので効率いいですよね、C言語に比べると速度が落ちるかもしれないけどマシンパワーなんて年々爆上がりしてるのですぐに気にならなくなるからいいよね！という既に何回か出てきた論法がここでも登場します。
8~9 について
8. 過度の対話的インタフェースを避ける は、シェルスクリプト書いて自動化したいと思ったときに重要性がわかるかと思います。 あとコマンドラインインタフェースがそれで占有されてしまうと不便だよね、という話です。
9. すべてのプログラムをフィルタにする はコマンドをパイプしてどんどんつなげていく UNIX のやり方の根底にあるものですね。 入力のデータ（たいてい何かしらのコマンドの結果としてコマンドラインに出力されるもの）に対していろんなコマンドでフィルタして（ awk や grep のイメージ）いって最終的に欲しい出力を得る、というよくあるワンライナーの書き方です。
さらなるUNIXの10の考え方
今までに上げてきたものほど中心的な教義として信仰されてはいないが、おおよそみんな認める「考え方」を挙げたものとなります。 なにもUNIXにのみ顕著な特徴という訳ではなく、他のOSにもいくつか取り入れられたりしているものもあるということで、ある程度この業界にいると「まぁそうだよね」的な内容がほとんどな感じです。
というよりは、これは次の章で紹介される（この記事では触れませんが）本書が書かれた時代のUNIX以外の主要なOSの中をいくつか取り上げ、UNIXとは違う哲学がどのようなものか、それに基づいてどんなものが作られているのか、を紹介しているのですが、そことの対比に向けて先に色々細かいところを挙げているような気もします。
そして対比されているのが Atariホームコンピュータ と MS-DOS と OpenVMS という、まぁナウい感じのものでは ない ので、先ほど説明した「UNIX哲学を部分的に取り入れたもの」が増えて広まっていった今現在の世の中においては殊更に「せやな」程度な感想になるのかもしれません。
一応書いておきます。
- 好みに応じて自分で環境を調整できるようにする
- オペレーティングシステムのカーネルを小さく軽くする
- 小文字を使い、短く
- 森林を守る
- 沈黙は金
- 並行して考える
- 部分の総和は全体よりも大きい
- 90パーセントの解を目指す
- 劣る方が優れている
- 階層的に考える
主張していることは大体次のような感じです。
- 好みに応じて自分で環境を調整できるようにする
- ユーザーを迷わせないために一本道にするんじゃなくて選択肢いっぱい用意した方が後々良いよ
- オペレーティングシステムのカーネルを小さく軽くする
- これまで述べた通り
- 小文字を使い、短く
- 当初はマシンリソースとの兼ね合いだったけど、可読性や使いやすさを考えると短い方がいいよね
- 森林を守る
- ペーパーレス。書かれた時代が時代なので、そもそもPCを使おうよ、という話から始まっている
- 沈黙は金
- 親切すぎるエラ〜メッセージも考えものだよね。ワンライナー書くときも余計な出力があると考慮することが増えて面倒だし。
- 並行して考える
- 個々の部品を小さくして並列に計算した方が効率良いよね
- 部分の総和は全体よりも大きい
- 拡張性やメンテナンス性を考えたとき、モノリシックな構成だと取り回しが面倒だよね
- 90パーセントの解を目指す
- 100パーセントを目指すとソフトが肥大化するしリリースまでの速度も落ちるし、そもそも100％なんてないんだからね
- 劣る方が優れている
- 得てして明らかに（少なくともその時点では）正解とはいえないアプローチ、解決法が実は生き残ったりするものなのだそうだ
- 階層的に考える
ちなみに私は9の項目の冒頭にあったこの一文が好きです。
軍隊経験のある人なら、世の中には「正しいやり方」と「間違ったやり方」と「軍隊方式」があることを知っている（119ページ）
「軍隊方式」が具体的にどういったものとして説明されているかは是非とも本書を読んでいただきたいですが、「UNIX方式は」は軍隊方式にどこか似ているらしいです。
まとめ
一冊通して、今の時代でもそのまま当てはまるもの、「今の時代だと若干違うかもなぁ、でも根底の考え方はまた別の形で現在にも息づいているなぁ」と感じる項目の二種類あるように感じました。
そう考えると割と占いや預言のようなものに近いかも、と思いました。 つまり、若干的を外していてもこちら側が好意的に「今の技術だとこういうことかな」と想像して補完する感じです。 多分それも読み方として間違っていないと思うのですが、安易に聖典にするのではなく適度に疑っていきながら自分の仕事に当てはめて考えてみるのはとても有益なことだと思います。
ってなんか批判しているみたいですが、ちゃんと考えながら読めるので「学び」としては最高級の本だと思います。
輪読したら楽しそう。
