シリーズ記事一覧: #Unix Linux Books
今回はちょっとしたエッセイなので多分たいした結論はない。
本当に何も知らなかった
僕がパソコンを仕事で使うようになった頃を少し思い出してみる。
Windows はまだ 2000 という(僕が触った中では)最も軽快でシンプルな OS バージョンだった。
まだ DOS/V が動いてる PC も残っていた。僕の当時の印象では、それらはたいてい IBM の Thinkpad だった。
DOS/V の PC は当時の僕のような素人から見ると魔法の箱のようだった。
たくさんのコマンドとホットキーを自由自在に使いこなす会社の先輩は魔法使いに見えた。
2000 の時代までは、Windows と DOS/V がうまく共存していたように思う。
その後 XP がリリースされるやいなや、またたく間に社内の PC で使用される OS が XP に塗り替えられていった。
僕は DOS/V を触れる最後の世代となった。
しかしそれはあくまで最低限の業務をこなすために丸暗記した知識だった。
「触れる」というだけで何も理解していなかった。
そして XP SP2 が定着する頃には DOS/V がインストールされた PC を社内で見ることはなくなった。
ここまでは商品のデータを管理・集計する業務で完全な「ユーザ」として PC を使っていたので、コードを書いた経験はなかった。
僕が最初にコードを書いたのは JavaScript だった。
その頃、家には妹のお下がり(そうそう、IT に関しては高校の頃から妹の方が先駆者だった)でもらった Fujitsu のデスクトップ PC があった。
ダイアルアップから ADSL への移行期であり、自宅もご多分にもれず ADSL に切り替えた。
インターネットの応答が「待てる」スピードになった。
当時フリーで間借りできるホームページサーバがいろいろ出てきて、そのうちのいくつかを借りていた。
CGI で掲示板を構築したりするのはちょっと敷居が高かったし、(あくまで個人的にだが)掲示板文化にちょっと馴染めない感じがした。
それまで静的な HTML ドキュメントしか上げられなかったところに JavaScript で動的なコンテンツを埋め込むのは楽しかった。
でもどういう仕組みでそれが動いているのかは全然理解していなかった。というか「仕組みを知ろう」という発想があまりなかったように思う。
「こういうコードを書くと、ブラウザでこんなふうに動く」という細切れの経験値が溜まっていくだけだった。
その後転職する機会があり、「なんとなく」プログラマ職に就く。
ここでも前職の Windows ユーザと DOS/V ユーザの差のような光景を目の当たりにする。
僕が受け持ったポジションは Windows をプラットフォームで動作するソフトウエアの開発(の見習い)で、基本的に Windows の IDE から外に出ることはない。
が、隣の島(とその奥にあるサーバルーム)では、たくさんの Linux 機が動いており、それを使いこなす先輩や同僚はマジで魔法使いだった。
正直憧れたが、同時に敷居の高さも感じた。
当時の印象は「何をやっているのかわからない」という一言に尽きる。
でもそれは自分の仕事も一緒だった。
「こういう SQL 文を書くとこういうデータが取れる」「こういうコードを書くと Office がこういう動きをする」という断片的な知識の寄せ集めで乗り切っていた。
当時、開発・保守していた製品にはコンパイルという過程が必要だったが、それが何をしているのかは全く理解できなかった。
誰も「なぜ」「どうして」の部分は説明しなかったし、自分も別に理解しようとしていなかった。
ただなんとなく営業職の同僚やクライアントよりもパソコンに詳しければ OK だった。
バージョンアップやカスタマイズがなんとか動く程度にできて、クレームをうまく乗りきれて、最終的にお給料が貰えればそれで結果オーライだった。
振り返ってみると、当時の僕には本を読んで勉強するという習慣がなかった。
仕事で必要なのでリファレンス本は何冊か持っていたが、読み物として読んだことはなかった。
その場その場で必要な情報はググるものだったし、困った時は先輩のコードをコピペすることが一番の対処方法だった。
仕入れた知識は右から左へ流れていくか、脳みその片隅に放置されて埃をかぶるか、まぁそんなところが関の山だった。
今だから言えることだが、当時の自分は Microsoft の奴隷だったのだと思う。いつも使っている IDE なしでは何もできなかった。
それと同時にビジネスの奴隷であり、自分が成長し認知されているという興奮剤の中毒者であり、ナルシストであったと思う。
誰か自分よりも知識量の少ない人物を見つけては優越感を味わい、自分よりも熟練した人物の前では子供のように振る舞うことでその場をやり過ごす。
「できる自分」を演出しているのは浅はかな知識(いや、むしろ「情報」)の集合だった。
それらは本質的に脆く、ニューロンのつながりは笊だった。
本を読もう
20 代まで転職の多かった僕は、次の２つの方法でサバイブしてきた。
- 必要なことは先輩に教えてもらう
- 質問しづらいことはググる
お給料をもらうだけが目的ならこれで OK だ。なんの問題もない。
ただし、自分の人生に少しの楽しみ、もしくは、ちょっとしたヒネリを加えたいと思ったらあまりにも素っ気ない。
やり方を改善してみる必要がある。
どう「改善」するか。これは僕個人の意見だが、即効性のある行動をやめて、逆に時間をかけて調べる習慣に置き換えてはどうだろうか。
人に質問すれば端的な解決策は容易に引き出せる。Web 検索も同様だ。
しかしそれではつまらないのだ。つまらないものは身につかない。
結論を言ってしまうと、本を先生にしよう。
本には正しいことも間違ったこともいろいろ書いてある。
大事なことはたいてい数ページに渡って詳しく書いてあったり、もっと言うと書いてなかったり(!)する。
それはあるスパン(もしくは１冊まるごと)を読み通して「感じる」ことだったりする。
今日常的に読書するようになって子供の頃父親が言っていたことが分かるようになった。
「通り一辺倒の意見しか書いてないような本はつまらない。１冊の中にいろんな意見が入り混じっているような本の方が面白い。」
父親と僕とでは読む本の種類がだいぶ違うのだが、この点に関しては僕も同意する。
本来的に結論なんてないもの(それなのにみんなが結論や解決策を求めて右往左往してるもの)に対して理路整然と筋の通った意見を美しい文章で結論付けられると、まるで世の中全体がそういう方向で動いている、理解している、と錯覚してしまう。
これは人間の同調本能と脳内の RAM 部分による動作をうまく利用した洗脳テクニックで、マスメディアが日常的に乱用している。
それはさておき、PC のスキルを高めるためには当然技術系の書籍を読み込むわけだが、どうも「固い」だの「読みにくい」「読む人を選ぶ」と言ったようなイメージがつきまとっているように思う。
しかしそれは普段から技術本を読んでない人のイメージであって実際は異なる。
実は、技術系の書籍などを読むときに心得ておきたいのは、次の点である。
- そこに載っている情報はその時点でのスナップショットであり、永遠ではない。
どんなにお固く、小難しく書かれていても技術革新や仕様変更でいとも簡単に「使えない」知識になる - 技術書と言えど、間違い、勘違い、矛盾した意見・見解、偏った表現は他ジャンルと同程度に含まれている
- そしてその人間らしさが読書の楽しみである。整然と最新情報だけが知りたいならオンラインマニュアルを読めば良い
だからまずは読み慣れることだ。
読み慣れれば面白いかつまらないかの判断は既に読み慣れているジャンルのそれと変わらないし、難しいか簡単かは単に自分の力量との差に準ずる。
また、本から情報や知識を手に入れるには手間がかかる。どうしてもスローになる。それが良い。
対価を払って手に入れた本ならなお良い。「ものにしたるぞ」という意気込みが違う。
僕の場合は、本を手に入れたらまず読む。そして PC 上で試す。
うまく行ったり行かなかったりする。悩む。
なぜかわからないが寝ると頭が整理される。
新しいアイデアやアプローチが思いついてまた試す。
複数の成功例が出てきたらベンチマークテストをする。
最速で且つ最もシンプルな手法を更新する。
複数のアプローチを試すことによって、丸暗記ではなく、そのタスクの「道理」を理解していく。
道理を理解する、仕組みを覗いてみる、という点に関しては Windows よりも Mac 、Mac よりも Unix/Linux がおすすめである。
PC での仕事に限らず、仕事上のタスクは常に不定であり、タスクを処理する道具は常に更新され整理され磨かれなければならない。
そうでなければそもそもその仕事は多分クズなんだろうし、野暮な道具でも通用するならプロの要らない分野なのだろうと思う。
このブログのシリーズを書き始めたのは、チームメイトにその筋での最高のプロになってほしいという願いからである。
その筋とはチームメイトそれぞれ違うのだが、共通している部分もたくさんある。
その最たるものが
- 如何に PC をうまく使いこなし
- 如何にドキュメントやプログラムを有効活用し
- 如何にタスクを飼い慣らすか
という仕事上の重要問題である。
そして僕個人の経験と好き嫌いから Linux をプラットフォームとして選択したわけだ。
Linux の一つの問題点として、僕が 20 代のときに感じたような敷居の高さがある。
2015 年現在は随分とインストールも簡単になり、デスクトップ環境もかなりイケてる感じのものが増えているので、「普段使い」という範囲では Windows/Mac と同等ではないかと思う。
しかし、Linux を仕事で使っていくにはコマンドラインを乗りこなす技術が必要であろう。
コマンドラインの敷居の高さは依然として変わらない。
それは最初に乗り越えなければならないハードルであり、何年経っても乗り越え続けるハードルである。
問題は、技術上のハードルを乗り越える作業が「楽しく」なる瞬間を見つけることだ。
これまた個人的にだけど、それには読書＋実践という方法が最適なように思う。
誰かから言われてやったことは、うまく行っても失敗しても、どこかでその人に依存してしまう。
本に書いてあることも誰かが言ったことには違いないのだが、少し距離があるおかげなのだろう、自然と「自分で選択した道」であるという自覚が湧く。
なぜ Linux を選んだか
Unix/Linux の哲学が好きというのは単に個人的な趣味の問題で、Linux をチームに薦めたのは「状況」と「実用性」によるところが大きい。
まず、我々が扱うファイルはほとんどすべてと言っていいほど「プレーンテキスト」である。
一部のデータベースやオブジェクトファイルなどバイナリーで動作するものも確かにあるが、それらはどちらかというとアプリケーションであったりアウトプットするものであって、それを構築・運用するインターフェースはプレーンテキストである。
僕が今まさにこのテキストを作成しているターミナル(またの名を端末、もしくはコンソール)はテキストを操作するという点で最高のツールである。
直接的には Vim, Emacs, Nano などのテキストエディタをターミナル上に立ち上げて文書を作成していく。
ターミナルの操作性と密接に結びついたこれらのエディタは快適な入力環境を提供してくれるだけではない。
ターミナル上ですべての操作を行えるということは、マウスを必要としないということだ。つまり腱鞘炎予防には最も効果的な環境を提供してくれる。
腱鞘炎を馬鹿にしてはいけない。IT で飯を食う人間にとっては死活問題なのだ。
マウスは腱鞘炎の原因になりやすいだけでなく、結果的には仕事を遅らせ、思考を停止させる要因になりやすいツールである。
(何時間も無駄にネットサーフィンしているときの自分を思い出してみれば一目瞭然である。)
僕自身は Windows を離れて以来数年の間 Mac の Unix 環境を利用してきた。
これはこれで素晴らしい環境ではあるのだが、Apple の提供するハードウエアや Xcode などの(ブラックボックスになりがちな)アプリケーションに依存する部分が少し気持ち悪く感じるようになった。
もっと身軽に、そして DIY な感じで Unix 的なアプローチを使っていきたいと考えて、今は Arch Linux というディストリビューションを主に使っている。
Arch Linux は目的を絞って仕事環境を構築するという使い方ではピカイチだが、何から何まで(主にコンソール上で)自分で組み立てる必要がある。
まずは「慣れる」という目的を素早く達成するために、インストール〜使用開始までの障壁の少ない Ubuntu 系のディストリビューションである Linux Mint をチームメイトには薦めた。
さて、これは我々のチームに関してはという注釈付きにはなるのだが、仕事のアウトプットは最終的に Web 上のコンテンツ、もしくは、それを動かすシステムやデータである。
つまりゴールや通過点で必ず Web が絡む。
Web サーバは一般に Unix か Linux 環境で構築されている(Windows サーバにはほとんどお目にかからないし、個人的にはあまり関わり合いたくない代物だ)。
以前、僕がまだ Windows しか知らなかった頃、PuTTY で Linux サーバにリモートログインしなければいけないタスクが発生して四苦八苦した思い出がある。
普段から Linux デスクトップで仕事をすることに慣れていれば、ネット上にある別の Unix/Linux にリモート接続したときにもすべての知識が応用できる。
こうした Web の裏側に強くなると、エンドユーザに見えるものがどういう仕組みで実現されているのかを理解することによって「仕事全体」がシンプルで無駄のないものになるはずだと踏んでいる。
そして最後に書いておきたいことは、チームメイトたちが自発的に Linux に興味を持ってくれたということ。
これは半ば成り行きとタイミングなのだが、とても嬉しかった。
みんなが知りたいものと、僕が教えたいものが一致したのでモチベーションを無理やりでっち上げる必要がない。
繰り返しになるが、主な勉強方法は本を読むことである。
ある意味それは諸刃の剣だ。とても自由で気楽なやり方であると同時にすべてが本人任せ・本人次第でもある。
このスタイルそのものが Linux 的でもあって好きなのだが、チームのプロジェクトとしてはいささか不安な部分もある。
しかしその不安についても Linux 的に解釈することにした。つまりチームがどういう方向に進むかは良くも悪くも「自由」なのだ。
#Unix Linux Books
