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








