読者です 読者をやめる 読者になる 読者になる

nekoTheShadow’s diary

技術ブログとして始めたはずが、読書&愚痴ブログになりました(´・ω・`)

最近読んだノンフィション: 『しんがり: 山一証券最後の12人』『住友銀行秘史』『戦地の図書館: 海を越えた一億四千万冊』

読書

最近読んだ本のうち、面白かったノンフィクション3冊を簡単に紹介したいと思います(´・ω・`)

清武英利『しんがり: 山一証券最後の12人』(講談社+α文庫)

山一証券の倒産といえばバブル崩壊の代名詞ですが、本書は崩れゆく山一証券において倒産の真相究明と精算業務を担った社員たちを描いたノンフィクションです。会社はもはや存在しないにもかかわらず、その原因を突き止めようという行動と心意気には感動しました。また大企業が倒産するときのドキュメントとしても面白く読めました。

國重惇史『住友銀行秘史』(講談社)

住友銀行秘史

住友銀行秘史

山一証券と同じくバブル経済の代名詞がイトマン事件。本書はイトマン事件にいち早く感づき、真相を究明すべく走り回った住友銀行の元重役が自ら書き下ろした1冊です。事件の当事者が書いているためリアリティは満載。子飼いの中堅商社を通じて財閥系銀行の金が闇勢力に流れたのは、単にバブルのあだ花というだけではなく、あらゆる時代に普遍的な人間関係のもつれや欲望の対立があったということがよくわかります。

モリー・グプティル・マニング『戦地の図書館: 海を超えた一億四千万冊』(東京創元社)

戦地の図書館 (海を越えた一億四千万冊)

戦地の図書館 (海を越えた一億四千万冊)

時代はうってかわって第2次世界大戦中のアメリカ。当時のアメリカは戦意高揚のため、戦場に向かう兵士向けの「兵隊文庫」を創設したのですが、本書はその兵隊文庫が兵士たちにどのような影響を与えたのかを描いています。銃弾の飛び交う戦場において兵隊文庫は兵士たちの唯一の娯楽であり、兵士たちがその兵隊文庫をいかに楽しみにしていたのかというエピソードには強い感動を覚えました。

『Land of Lisp』を読み終えた。

技術書

Land of Lisp

Land of Lisp

nekotheshadow.hatenablog.com

ハッカーと画家』に影響されてCommon Lispに関心を持ち、買ってしまった『Land of Lisp』ですが、一通り読み終えた&掲載コードを写経し終えました。取り組んだ期間はおよそ2か月。平日は仕事が忙しくほとんど進められませんでしたが、休日は1日3-4時間ほどを本書のために当てていました。

Common Lispの入門書としてとてもよかったように思います。「基本的な文法やライブラリを紹介するだけ」という入門書にありがちなことはまったくなく、ゲーム開発という関心がわきやすいテーマのもと、少しずつCommon Lispの文法や機能を学び、最終的にはLispの全体像やその哲学まで学べる構成の良さは、わたしが今まで読んできた入門書のたぐいでは一番かもしれません。ちょくちょく挟まれる漫画も箸休めとしてGood。また訳が非常に平易で、すいすい読み進めることができました。技術系の翻訳書だと機械翻訳をそのまま出版したかのような本がたまにあるので、そうでなかった点は評価が高いと思います。

ただしCommon Lispを学んでわかったのは、わたしにはCommon Lispは向いていないということ。個人的には同じLisp語族でもSchemeのほうが好みのようです。とくに何かが悪いというわけではなく、単に相性の問題、あうあわないの問題ですかね。結果的に自分の好みではなかったとはいえ、Common Lispに触れることができたのは貴重な経験でした。あとLispモンスターはきもかわいい(´・ω・`)

ブログを閉鎖した

雑記

数か月前に技術書ブログの書評感想ブログを意気込んで開設したのですが……このたび閉鎖することに決めました。理由はいろいろあるのですが、一番大きいのはモチベーションの低下。それに書評をよく掲載するメインブログがあるにもかかわらず、技術書だけ別のブログにするという意味も分からなくなり、いろいろ悩んだ末に閉鎖する運びになりました。

閉鎖したブログの記事は一部を除いて、このブログにインポートしました。技術書というカテゴリがその名残です。今も技術書は読んでいますし、書評をブログに載せたいようなこともあるので、今後は技術書カテゴリに技術書の感想や書評をほそぼそと書いていくつもりです。そういいつつ最近はこちらのブログもさぼり気味なのですが……。いかんせん仕事が忙しく、Qiitaにちょっとしたtips記事を書くのでいっぱいいっぱいです。転職したい(´・ω・`)

タッチタイピングのできないプログラマ

雑記

わたしはいわゆるSIerに勤務するシステムエンジニアであり、企業向けのシステムを構築するプロジェクトで日々働いている。この業界の常としてプロジェクトが始まると、どこからともなく技術者が集められてくる。わたしの所属するプロジェクトは中規模とされているが、それでも孫請けひ孫請けが同じプロジェクトルームにごろごろしており、同じシステムを作るため日々格闘しているのだから、不思議なものである。

そういう環境で働いている中で驚いたことがある。タッチタイピングができないプログラマシステムエンジニアがそこそこいることだ。それもひとりやふたりではない。「両手の5本指を使うが、下をみないとキーボードを打てない」程度はかわいいほうで、ひどいものになると使うのは親指と人差し指と中指だけ。それも右手が中心で左手はそえるだけなのだ。これで新人ではなく、この道何十年というベテランなのだから、この業界の闇は深い。

実をいうとわたしもタッチタイピングが完璧にできるわけではない。ほとんどのキーは大丈夫だが、あまり使わない記号になると少し怪しく、そういうときはついつい下を向いて確認してしまう。しかしわたしの場合、その割合は全体の5%かそれ未満。文字を打ち込んでいる間の半分以上を下を見ることに費やしているということはあり得ない。

タッチタイピングが全くできなくても、与えられたタスクをきちんとこなしていれば、全く問題はない。しかしプロジェクトにいるタッチタイピングできない勢はそろいもそろって生産性が低いのだ。終わらせるべきタスクを終わらせるべき時間内に終わらせることができないから、当然残業ということになる。つまり残業代を彼らに支払わねばならず、プロジェクトの予算を圧迫する。なにより生産性の低い人間ほど賃金が多いということになって、個人的には全く納得がいかない。またかれらのたいていは口入屋によって集められてきた孫請けひ孫請けの人間である。いってしまえばかれらは末端の作業員である。要するに「末端が夜遅くまで働いてプロジェクトに貢献しているにもかかわらず、それより上位の元受けがサッサ帰ってしまうのは何事だ!」という雰囲気になってしまい、プロジェクト全体が用もないのにだらだらと居残り残業を続けるという悪循環に陥っている。


タッチタイピングに関して思い出したことがある。タッチタイピングができないのは、なにも「ベテラン」に限ったことではないということだ。要するに新人や若者にもタッチタイピングができないものは数多くいるのだ。思い返してみれば新人研修の際、タッチタイピングができない同期は結構いた記憶がある。一番感心した(?)のは大学時代のころで、偉そうにMBA講義ノートをとっているにもかかわらず、その手元は人差し指だけでキーをたたいているという女子学生を見たことがある。彼女の場合その高価なMBAを買うお金を使って、パソコン教室にでも通ったほうがよっぽどためになったのではなかろうか。


弘法筆を選ばずということわざがある。その道の達人は道具にこだわらずとも素晴らしい作品を作り上げるという意味だが、逆に考えると「へたくそは道具にこだわったほうがよい」ということである。プログラマにとってはタッチタイピングも道具のひとつであり、使いこなせるに越したことはない。タッチタイピングを満足にできないプログラマシステムエンジニアを他山の石にして、自らの能力の研鑽に取り組みたい。

Paul Graham『ハッカーと画家: コンピュータ時代の創造者たち』

技術書
ハッカーと画家 コンピュータ時代の創造者たち

ハッカーと画家 コンピュータ時代の創造者たち

 

技術書というより技術エッセイに近いので、このブログに書評を残すべきか悩んだのですが、せっかく読んだので。

本書は技術エッセイであり、その大半はCommon Lisp礼賛&スタートアップ企業礼賛。そして「プログラマにはセンスが必要だ」ということも繰り返し述べられます。欧米のエッセイによくある感じのエッセイ、そのプログラマ版という印象です。そして感想ですが……この一言を述べるのが一番でしょう:『Land of Lisp』を買いました

これでわたしもLisp Hackerの仲間入りだ!!!!

Land of Lisp

Land of Lisp

 

日曜日の夕方は月曜日のせいでいつも憂鬱

雑記

現在時刻は日曜日の17:30。あとは晩御飯を食べて寝るだけで今日が終わってしまう。ひどく憂鬱である。なぜならば明日は月曜日。仕事に行かねばならないからだ。

わたしは受託開発オンリーのSIerシステムエンジニアをしている。この業界の常として仕事はプロジェクト単位で動くのだが、今わたしが参加している(参加させられている)プロジェクトの内実がひどく、明日もプロジェクト活動があるのかと考えると、気分は落ち込まざるを得ないのである。

プロジェクトをひどいものとしているひとつの原因は顧客のIT理解である。そこそこの規模の会社の情シスと情報子会社が顧客なのだが、ITの専門部署あるいは専門子会社とは思えないほどITに関する知識がない。正確には「ない」のではなく「古い」のである。メインフレームや大型ホストの時代から知識が止まっているようにしか思えない発言を繰り返しており、ミーティングがまったく実りのあるものになっていない。

個人的には情シスには同情的である。情シスの人たちのほとんどは日本的人事異動の結果連れてこられただけだろうし、そもそも日本企業においてIT系の部署は出世コースではない。どうせ勉強したところで数年もすれば人事異動で、そもそもこの傍流の部署から抜け出せるなら万々歳だと考えて、ITの勉強をする気にならないという事情はよく分かる。しかし情報子会社。てめえはだめだ。ITのためだけの会社のくせになぜITの知識がないのか。プログラミングができない、SQLが書けない程度ならまだしも、自分の親会社のシステムのアーキテクチャがどうなっているのかわからないとは、いったいいままでどんな仕事をしてきたのか?

顧客の悪口が多くなってしまったが、なら開発側のSIerはどうか? これもひどいものである。プロジェクトマネージャや営業は顧客の要望を伝書鳩に持って帰ってくるだけ。要件要望が増えても当然予算は増えないし、納期も据え置きである。大体にして要件追加に伴って増やす機能は果たして必要なのか? 「残業をして、品質を落として、作ったものが実はそれほど重要なものではありませんでした」となったらやりきれない。もっとも問題は顧客対策だけではない。アーキテクトと呼ばれる連中もなかなかひどい。ITのスペシャリストのくせにIT知識が10年前で止まっているのだ。日進月歩のIT業界において10年という年月は長すぎる。人間でいえば100年ぐらいに相当するだろうか。想像してほしい。100才のおじいちゃんやおばあちゃんが技術的な取りまとめを行っているのである。その結果出来上がるのは21世紀も半年が過ぎたとは思えないシステムやUIであり、すなわち古臭くて使いづらいシステムである。

こういう話を聞くとたいてい「ひどすぎる上流工程のしりぬぐいを下流工程が技術力の高さを生かしてなんとかする」という流れになりがちだが……しかしそうは問屋がおろさない。下流工程もなかなかのひどさなのである。今の現場はいわゆる多重下請けが横行しており、どこから集められてきたかわからないプログラマがうようよしている。中には参考にしたいと思えるプログラマもいるのだが、大半はだめ。サンプルコードをコメントアウトまでコピペしてくる程度はまだまだ上等なほうで、最下層だとタッチタイピングすらまともにできていない。Eclipseが移った、そこそこ性能の高いラップトップに向かって、両手の人差し指と中指だけでソースコードを打ち込んでいるさまを見ると、怒りすらわかない。怒りを通り越して笑うなんてこともなく、ただただ情けないだけである。タッチタイピングもできなくてもシステムエンジニアであり、しかもそこそこベテランなのだから、この業界の闇は深い。

プログラミングでいうと、オフショアリングとニアショアリングも利用している。この両者が作り上げてくるソースコードの品質だが――もはやいうまでもないだろう。ひとついえることは「安かろう悪かろう」である。よいものを手に入れたいなら適切な対価を支払うべきというのは、資本主義のいろはであり、小学生でも知っている。

そうこう愚痴を垂れ流している合間に18:15である。刻一刻と月曜日は近づきつつある。本当に憂鬱である。

西尾泰和『コーディングを支える技術: 成り立ちから学ぶプログラミング作法』(技術評論社)

技術書
コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

 

プログラミング言語 = 人造言語」。つまりプログラミング言語は全知全能の神によりデザインされたわけではありません。したがって完ぺきではなく、設計者のミスが入り込んだり、デザイン当初は実現不可能だったことが漏れていたり、さまざまな欠陥を持つ可能性があります。もっとも人造言語であるということはデメリットばかりではありません。たかだか人間の作ったものですから、簡単に修正することができますし、新しい言語を作る際にはほかの言語の欠点を補いながら開発を進めることが容易にできてしまいます。

プログラミング言語あるいはプログラミングという営みは、プログラマやデザイナたちの進化の集大成であり、本書はその「進化」の中で自明なものとして扱われるようになったトピックにことさらスポットライトを当てています。関数やエラー処理あるいはオブジェクト指向など、現代的なプログラミング環境では当たり前のことがなぜ当たり前になったのか? それをもう一度検討しなおしたのが本書であり、読み終えた後は基礎から鍛えなおされたような気分になりました。

繰り返しておくと、本書は何か新しい技術やツールを取得できる類の本ではありません。プログラミングの歴史を振り返り、プログラマとしての基盤をより一層強化したい開発者にとってはうってつけの1冊でした。