はじめに
UNIXの考え方をまとめた『UNIXという考え方』を読みました。 20~30年前の書籍で古い情報もありますが、現代でも重要な考え方を学ぶことができました。 この記事では簡単に感想を書いておこうと思います。

下記リンクが公式サイトです。
感想
スモールイズビューティフル
まずは最も有名な考え方だと思われるスモールイズビューティフルです。 プログラミングをやっていれば必ずどこかで知ることになる「プログラムは小さく書く」の考え方です。
何も考えずにプログラムを書いていると、 一つのプログラムでいろいろなことをやろうとして多機能化してどんどん肥大化してしまいます。 大きいプログラムというのは読みにくいし、 保守も大変だし、 移植性も下がるし、 他のプログラムと組み合わせるのも難しいしなど、 たくさんのデメリットがあるためできるだけプログラムは小さくしようという考え方です。
そこでもう一つ重要な考え方として、 「一つのプログラムには一つのことをやらせる」というものがあります。 一つの小さいプログラムで一つのことをやらせて、 それらのプログラムを組み合わせることで複雑なこともできるようにするということが重要になってきます。
CLIでコマンドをパイプで繋いで複雑なデータ処理を行うとかがまさにこういう考え方になっていそうです。
ただ、この書籍で述べられていましたが、
lsコマンドのオプションが50個くらいあるみたいに、
コマンド一つ一つが多機能化して大きなプログラムになってしまう問題も発生しているようです。
私もいわゆるモジュール化や疎結合のような一つ一つの処理を分けて、小さなプログラムにして、組み合わせて使うというようなことを、 最近は少しずつ意識してプログラムを書くようにはしています。 とはいえまだまだ身に付けられていないので勉強あるのみという感じです。
新しい技術は拒否される
UNIXも最初はビジネスの世界では受け入れられず、 大学などの研究で好まれて使われていたという説明があって、 今では安定した立ち位置にいるUNIXでさえも最初はそんな感じだったのかと驚きました。
2026年現在では急速に発展し続けているAIが一部では受け入れられてなかったりしていて、 歴史は繰り返すという言葉の通りかなと思っています。
早く試作する
実際に作って動かしてみないと課題は見つからないという考え方で、 できるだけ早く試作しようと本書では述べられています。 仕事では完璧に仕様を決めてから開発に取り掛かることが望まれそうですが、 開発中に仕様変更が必要になることも多々あったり、 そもそも仕様の認識が合っていなくて作ってから認識のズレが分かったりするなどが起こりえます。 つまり最初に完璧な仕様を作成するというのが基本的には困難ということになりそうです。 私も実際に作ってみないと本当にできるのかよく分からないことが多いので、 早く試作するというのは大事な考え方だと思っています(私の場合は経験不足な部分もありそうですが)。
また、ドキュメントについて、詳細で丁寧なドキュメントが必要があれば最終的に作成することになるが、 何よりも開発を優先して、 ドキュメントは基本的な情報を書いたものがあればよいと書いてありました。 OSSでドキュメントが不親切だなと思ったことがいくらかありますが、 リソースが足りない状況では開発のほうに集中してドキュメントは必要最低限になるのも仕方ないかと改めて思いました。 結局はどれだけドキュメントが用意されていようと動かないことには意味がないということになると思います。
コミュニティのソフトウェア開発:3つのシステム
コミュニティでソフトウェアを開発する際には3つのシステムを作ることになるという話が特におもしろかったです。 以下のような流れです。
- 第一のシステム:一人あるいは小数人で「こういうソフトがあったらおもしろいよね」という考えのもとに開発する。足りないところもあるが斬新で革新的なソフトウェアができあがって、成功すれば世間的に流行する。
- 第二のシステム:第一の成功の魅力にひかれてたくさんの人が集まってくる。開発に関わる人や意見を言う人が多くなって要求が増えてソフト自体がどんどん多機能化、肥大化していく。人数の増えたコアメンバ間でも意見が一致せず、迷走気味になったりもする。
- 第三のシステム:第一や第二の開発を行っていた人たちは飽きたり他のおもしろいプロジェクトに移ったりなどしていなくなり、別の人たちが第一や第二の良いところ取りをした第三のシステムを作り始める。これが一番バランスの取れた良いソフトとなる。
ジンテーゼのような考え方でソフトウェアが作られていくのだなと思っておもしろかったです。 また、この話も実際に作ってみないと何が正しいか分からないということでもあるようです。 この話を読んだときに今使っているソフトとかも同じような道を辿っているのかも思ったりしました。 ここでもやはり歴史は繰り返すというやつです。
性能や効率よりも移植性や利便性が大事
この話は言われてみれば確かにそうだと思いました。 プログラムを書くときは性能や効率のことばかり考えがちだったのですが、 移植性や利便性を考えないと長く使えるプログラムにならないようです。
また、性能や効率はいずれコンピュータの性能が向上すれば解決するので、 現状で要求を満たせる性能に達していれば性能向上に時間を費やす必要はないとのことです。 もちろん性能や効率が高いにこしたことはありませんが、 それよりも移植性や利便性を向上させることに時間をかけたほうが良いというのは、 そのソフトを長生きさせる上では重要でなるほどとなりました。
どんなに性能が高いソフトでも、 流行りのプラットフォームが変わった時に移植に時間がかかってしまえば、 他のソフトに負ける可能性は大いにあります。 利便性でも同じことが言えます。 つまり結局は使ってもらえなければ意味がないということかと思います。
他のプログラムを借りてくる
今のOSSなどの考えと同じで、自分で独自に実装できるのも大切ですが、 全部独自実装だと時間がいくらあっても足りなくなるので、 車輪の再発明はせずに既存のプログラムを活用しながら足りない部分を自分で実装するのが良いとありました。
現在では生成AIがプログラムを書けるようになってきていて、 さらにこの話は重要になってくるのではないかと思っています。 極端に言えば全部AI任せでソフトを作り上げることもできてしまうので、 最終的には自分が何を作りたいのかをしっかり理解すること、理解できることが重要になってくると思っています。 AIに作ってもらってもそれが正しいのか判断できないと意味がなくなってしまいます。
おわりに
今回は『UNIXという考え方』を読みました。 少し古い本ではありますが、今でも通用する、 というかすでに常識になっているような重要な考えを学ぶことができました。 ここに書いた感想の内容以外にも様々な考えがあって勉強になったのでおすすめです。 技術はどんどん発展していきますが普遍的な考えもあると思うのでそのあたりをしっかり身に着けたいと思います。 それでは、また。