Thursday, May 31, 2007

ベッカー「人的資本」

経済学の名著だそうだが、それはおいといて。
企業が社員を教育する時、そこにはコストがかかる。そのコストの負担を、どこに求めるのかという洞察が面白い。
会社がもつの?個人がもつの?

これを考えるときに、汎用性のある教育と特殊性(その企業特有の)教育とをベッカーさんは、別けて考えている。

汎用性のある訓練、教育によって人的資本の価値をあげる際、教育投資とそれを回収する期間を考えれば、長期雇用できることが、企業側として必須条件となる。要するに教育に使った金の分、働いてね、と。

逆に、特殊なその企業でしか通用しない知識の場合、ヨソでは通用しない知識であれば、従業員にとっては、長期間働けるという保証がないなら、特殊な教育を受けるべきではない。従業員にとっては、ヨソにも行けないデッドロック。

さて・・。
SOX のセミナー無料でやるから、2年は契約して働いてね、という会社がある。
組み込み・制御系、未経験でもいいから、3年は契約してね、という会社がある。
SOXは、当分需要があるだろうし、組み込みは、特定の処理系に依存しない考え方が身につけば、悪い話じゃないと思う。
が、オレも一緒だけど、常に、その次・・を意識していないと、食い詰めるだろうなあ。

Wednesday, May 30, 2007

三角関数

20代のころ、文学部出身の僕は、理系出身のプログラマーにかなりコンプレックスを持っていた。プロッターでグラフを描画するのに、座標を求める必要があるとき、サイン、コサイン、タンジェントが必要だった。

僕が苦労していると、理系出身のT君は、当たり前ジャン、常識ジャンと、ちょこちょこと、1ー2行書いて、ホイと渡してくれた。ああ、オレは、この先PGとしてやっていけるだろうか、向いてないんじゃない?とか、けっこう悩んだわ。

だけど、仕事やってく上で、文学部ですからあ、なんていい訳できんしねえ。知らんかったら、調べりゃいいじゃん、以上。

今でも、三角関数は、調べないと思い出せない ^^;;
けれど、調べる方法は、インターネットをはじめとして、ものすごく豊富になってきて、困らない環境ができている。

PG・SEで、ずっとやってきて、今、営業のような?仕事をしている。
最初は、言い訳してたかもしれない。「おれは、技術者だ、営業は素人だ」
でもね、何年もやってたら、「営業は素人」だなんて、言ってられないんだ。
やらなきゃいけないとなれば、それでメシ食おうとする以上、プロになんなきゃ。

三角関数を覚えてなくても、なんとかなった。
今も、立派じゃないけど、何とか、何かの間違いで、幸運と周囲の人に支えられて・・・何とかなってる。

Tuesday, May 29, 2007

10年生き延びた本(古典的技術書2)

古典的技術書の続き。

IT、ソフトウエア関連の本は、巷にあふれている。中には、その製品のマニュアルの引き写しそのままだったりする。

そうでないまでも、特定の言語、特定の処理系、特定の技術エンティティに特化した内容のものが多いよなあ。もちろん、そういう詳細を説いた書物って、実用性という意味では優れていて、「高いなあ」と思いつつ、けっこう購入してきたし、たぶん、これからも、昔ほどではないにしろ、必要に迫られて少しは買うんだろうなあと思う。
でも、そういう本って、寿命が短いよね。それらが良書か悪書かという議論じゃなくて、流行の旬の技術要素って、どんどん変わっていくし、そういう本は、その流れにあわせて、どうしても消えていく。十分に実用性があってもね。

そんな中で、10年以上という歳月、生き延びてきた技術書は、時代を越えて通用する概念や考え方があると思う。
製品やプロダクト、処理系、フレームワークは、これからもどんどん変わるだろう。この業界で仕事していく決心をしているなら、それらの本ににある時間を越えて通用する概念・知識こそ、身につけていきたいし、部下、後輩、仲間に、身につけてほしいと願う。

だけど、これがけっこう大変なんだ。俺は最近は、技術書に限れば毎月1冊だわな。他の分野の本も読まなきゃいけない立場だし。
だけど、月1冊でも、継続していくと、けっこうな力になると思ってます。
10年で120冊。流れやハヤリで消えていく知識の積み重ねではなく、時代を越えて残るITの概念・哲学・思想の蓄積。差が出ると思うよ。


部下・後輩に読ませたい本のアマゾンのリストマニアはこれ

Tuesday, May 22, 2007

言語の歴史 4 オブジェクト指向

構造化言語も頑張った。が、やはり時代が許さない。

今まで、コンピューターは、本質的に「計算機」として使われてきた。XXシステムとかXXアプリ。外装の機能は変わっても、やってることは計算機。

が今は、ネットの携帯、メール等、独立した個々の間ののメッセージツール、コミュニケーションツールになってきた。計算、演算の処理であれば、構造化言語でも十分対応できた。しかし、巨大なネット空間、トポロジー、メッセージ伝送を、モデルとしてとらえようとすると、手続き型や構造化の考え方では、表現が非常に困難。できないといってもいい。
web2.0のシステム概念など、オブジェクト指向そのものだ。

世の中でおきていること、シカケ、ビジネスの仕組み。問題領域、システム化対象領域の多くは、オブジェクト指向で表現するほうが、無理が無い。できないと言ってもいいかもしれない。
オブジェクト指向は、エンジニア、プログラマのニーズや好みで生まれたものじゃない。

C++より後発の、Java PHP5 Ruby などは、ネットを意識して、マシンをまたいでのメッセージ連携、プロセス間通信が、最初からできる。ネットに関係するコンストラクションの際に、今はそれらを選択することが妥当だろう。勿論、次に何が来るかはわからない。

今、PGとしてするべきは、オブジェクト指向を理解したうえで、それらの処理系を使いたい。
JAVAのクラスメソッドをたくさん覚えても、オブジュクト指向を理解したことにはならないんで。

C++ JAVA PHP5 Ruby,Squeak
本稿では、いつもの言語の説明はしない。馴染みは十分あるだろうし。

Monday, May 21, 2007

古典的技術書

久しぶりの更新だ・・。

先日後輩2人と飲んだ。年は10歳も違う。

だいたいサラリーマンが飲めば、大企業であれば上司、中小であれば社長の批判か、あるいは顧客とのやりとりの愚痴と相場が決まってる。10歳違おうが、IT会社であろうが、まあ話題は一緒だったりする。

が、今回は、インフラ対APの技術論・実装論などで、やたら熱くなった。店に出入り禁止にならないか心配になるくらい。そのうち、攻撃の矛先が、先輩であるオレにむいてくる。

「だいたい、高橋さんなんて、はっきり言ってロートルですよね。(ぐはあ) でもいいじゃないですか。僕らはそんなこと期待しない。Apacheのconfig のパタメータやら、PHPのクラスのメソッドの細かい仕様やら、oracle のチューニングパラメータを、あんたに教えてもらおうなんて思ってないですよ。
でもね、そういう細かいことは、僕らはいくらでも、必要なこと自分で調べていけるんですけど、常識というか、経験に裏打ちされたノウハウとか、年食った人は、そういうことこそ、教える責任あるでしょ。」

あいたた、痛い、痛い。そんなもんOJTだろと開き直るのも何だかなあ、「じゃあ」と、オレが読んで感銘・影響を受けたいくつかの書名をあげた。いまどきのハウツー、解説じゃなくて、哲学・思想がある時代を超えて通用しそうな本。
「すでに古典だけどな。これは、こういうとこが今でも通用すると思うぞ、ETC」

その時の本+アルファ アマゾンのリストマニアにまとめた。

いいか悪いかしらんが、少なくともオレは、これらの本からは、かなり影響受けてる。マジ読んで欲しいなあ。

話題にした本のアマゾンのリストマニアはこれ

まあ、ほんと、オレは、いい後輩に恵まれていると思うよ。