はじめに
『UNIX という考え方』を読んだ。この本からどのようなことが学べるのか、個人的に感じたことを踏まえてまとめる。
- 『UNIX という考え方』
- Mike Gancarz 著、 芳尾桂 監訳
- 初版：1995 年（英語版）、2001 年（日本語版）
概要
企業で UNIX を教える立場にあった Mike Gancarz 氏が、UNIX 開発者たちのフィロソフィを語る内容。
重要な 9 つの教え（定理）と、次に重要な 10 の教えが記載されている。
9 つの教え
- スモールイズビューティフル
- １つのプログラムには１つのことをうまくやらせる
- できるだけ早く試作する
- 効率より移植性を重視する
- 数値データは ASCII ファイルに保存する
- ソフトウェアを梃子（てこ）として使う
- シェルスクリプトによって梃子の効果と移植性を高める
- 過度の対話的インターフェースを避ける
- すべてのプログラムをフィルタとして設計する
読むのにかかった時間
1 時間 30 分くらい。口語体なのでさらさらと読めた。
UNIX の難しい用語も出てくるが、哲学的なところが理解できれば良いのでわからない用語は一旦すっとばした。
全体の感想
「大きすぎるシステムはダメだ、小分けにしよう」とか、「移植できないシステムは避けよう」とか、今となっては当たり前なのかもしれないが、この本は 1991 年から構想されていたらしい（初版は 1995 年。日本語版は 2001 年）
自分の周りの情報だけで井の中の蛙になってしまうのではなく、１秒でも早く新しい考え方に触れていかないといけない、改めて思う。 エンジニアは勉強し続けないといけないんだな（自戒）
また、この本は 10+9=19 個もの教えを述べている。 他の方の書評を見に行くと、これまでの経験によって「印象に残った教え」が異なるのもおもしろいところ。
印象に残った教え４つ
移植性と効率はトレードオフ
中でも難問の一つが、移植性か効率かという選択だ。効率を選択すれば移植性に劣るコードができ、移植性を選択すればときに効率がいま一つのソフトウェアができあがる。
特殊機能を使うことで、プログラムの性能が飛躍的に向上することもあるが、そのためには機器依存のコードを別に書かなければならない。
その上で、移植性を重視せよと筆者は述べている。なぜなら
よいプログラムは死なず、ただ新しいハードウェアに移植されるのみ
という姿を目指しているからだ。
移植性と効率はトレードオフと改めて言われると、すとんと腑に落ちた。 （ベテランエンジニアには当たり前だろと言われるかもしれないが）
私は仕事で、移植性というか、再利用性の高い API を作成することが求められているが、そうすると UI 側の効率が落ちる。
UI 側のメンバーからは、
- 「えっ、これまで UI 特化で API を作ってくれていたのに、全部統一するってことは、UI 側で必要な API を取捨選択して取らないといけないの？」
- 「処理が増えるから TAT（Turn Around Time）が遅くなっちゃうよ」
- 「むしろ、API じゃなくてデータベースを開放してくれたら勝手に見に行くよ？（困る）」
といった内容を言われることがある。
UI 側の性能も重要なので、気持ちはわかる。なかなか言い返しにくい。
確かに処理の効率性を追い求めるなら、専用の機能を作ったほうが良いに決まっている。それでも移植性（再利用性）を追い求めるべきなんだということを会社の事業的観点で判断する必要がある。そして、効率の問題も克服しなくては。難しい。
難しいことは明日からも変わらないのだけど、「難しいのは当たり前なんだ」「自分の方向性は間違ってはいない」と思えたので良かった。
スモールイズビューティフル
小さいものは美しい。
筆者によるとその理由は、
- 理解しやすい
- 保守しやすい
- リソース食わない
- 組み合わせやすい
だからだ。完結だが、この「WHY」を心にとめておこうと思った。
私がシステム部門に異動した 3~4 年前から、マイクロサービスアーキテクチャという言葉が社内で飛び交い始めた。
とにかく互いの依存性をなくすこと。
大企業だと特に、マイクロサービスアーキテクチャを理論的にわかっていても問題は山積みだと思うが、とりあえず勉強しよう。（感想）
システムのライフサイクル（若いシステム～成熟したシステム～枯れたシステム）
残りの 2 つはシステムというよりは人生哲学として興味深かった。
システムには第一のシステム（若いシステム）、第二のシステム（成熟したシステム）、第三のシステム（枯れたシステム）という人間の一生のようなサイクルがあるとのこと。
ざっくりまとめるとこんな感じ。
- 第一のシステムは、少人数で勢いで作る。汚いかもしれないけど斬新で、めっちゃ役に立つ。
- 第二のシステムは、第一のシステムを批判して多様な人たちが恩恵にあずかりたくて作る。大きくなりがちで、勢いがなくなりスピードも落ちる。
- 第三のシステムは、第一のシステムの斬新な考えが受け入れられて、「普通のシステム」として作られる。第一、第二の失敗をもとにバランスの取れた良いシステムが出来上がる。システムを作るなら、この「第三のシステム」が最終的に作られることを目標にすべきだ。
以前、転職の思考法という本で読んだ、「伸びている業界に身を置け、大事なのはそれだけだ」という文章を思い出した。
私は実際の仕事では「第三のシステム」にしばらく携わっており、その後「第一終わりかけ～第二に入ったか？」というシステムに異動したのだが、仕事が格段に楽しくなった。
おそらく、システム開発に携わるなら「第一のシステム」をやっているときが一番楽しいんだろうなぁと。大変かもしれないが、いつかはやってみたいと思った。
（著者の意図とはあまり関係ないところに思考が行ってしまった）
90%の解をめざす
一言で言うと 「90%の人を満足させられればいいんだ。10%は捨てよう。俺たちは行政じゃないんだから」 ということ。
こちらも人生哲学だが、尊敬する上司から何度も言われたことと同じだったのでメモがてら記載した。
確かに 90%できているものを 100%にするのと同じ時間で、0 のものを 60%くらいまでもっていくほうが楽しいし有益だと思う。
実際の仕事だと、90%できているものを 100%にするほうが気が楽なので、そっちに流れがちだが、意識的に 80~90%の出来で強制終了するようにしている。
ずれた例えかもしれないが、Google マップでスタバを検索すると、大都市には大量出店して、少し都心から離れるとほとんど店舗が無い。あまりの割り切りっぷりに笑ってしまうけどそれでいいんだ。
まとめ
- 『UNIX という考え方』を読んで、共感した教えを４つまとめた。
- 1995 年にこれを提唱していた筆者はすごい。
- マイクロサービス勉強しよう。
- 本の感想記事は初めて書いたが、自分の記録になるので、また書いてみよう。
