こちらでGoogle Chinaの社長であるKai-Fu Leeが彼の母校であるカーネギーメロン大学で先日行った講演が紹介されていた。かなり興味深い内容であったので、こちらでも紹介したい。紹介して下さったshimaさんは実際にカーネギーメロン大学に留学中のようであるが、日本にいる私たちでも同じ講演を簡単に観る事が出来るなんて本当にいい時代なんだろうな、と思う。

講演は一時間に及ぶものですが、普段あまり考えることのなかったことを色々と気づかせてくれる内容でした。特にアメリカ人と中国人ではインターネットに対する姿勢がまったく違うという内容は興味深い。姿勢が違えば市場も違う訳で、長期的な視点で中国については考えたいとEric Schmidtも言っていたようだが、中国市場である程度のプレゼンスを得る為にはまだまだ時間がかかりそうである。

リファクタリング本などの執筆で有名なMartin Fowlerが、CheaperTalentHypothesisという面白いタイトルでBlogエントリを書いている。なかなか興味深いのでご紹介。タイトルを意訳すれば「才能があるほど奴ほど安いという仮説」てなところだろうか。

Although the technorati generally agree that talented programmers are more productive than the average, the impossibility of measurement means they cannot come up with an actual figure. So let’s invent one for argument sake: 2. If you can find a factor-2 talented programmer for less than twice of the salary of an average programmer – then that programmer ends up being cheaper. To state this more generally: If the cost premium for a more productive developer is less than the higher productivity of that developer, then it’s cheaper to hire the more expensive developer. The cheaper talent hypothesis is that the cost premium is indeed less, and thus it’s cheaper to hire more productive developers even if they are more expensive.

CheaperTalentHypothesis

要するにあるプログラマの生産性（これを計ることは非常に難しいことだが）が平均より何倍かあるとして、そのプログラマに払う給料がその「何倍」よりも下だったら、結果的に安い買い物だということ。これは以前にLisp HackerのPaul Grahamも同じことを言っている。

経済的には、この事実は重要な意味を持つ。素晴らしいハッカーに、彼の価値相応のものを支払う必要が無いということだからだ。凄腕のプログラマは普通のプログラマの10倍から100倍生産的かもしれないが、普通のプログラマの3倍も給料をもらえばラッキーだと思ってくれるだろう。

Great Hackers

またMartin Fowlerが以下のように言っているように、生産性の高い少数精鋭のチームには、チーム内のコミュニケーションコストが大きなチームに比べて少なくて済むという大きなメリットもある。これは大規模なソフトウェアの開発に携わったことのある人間ならすぐに理解出来る話だ。Martinの感覚的な数字では、生産性はチーム人数に比して対数的に増加するとのこと。つまり人を4倍に増やすと2倍の生産性が得られるということだ。

The trouble is that that assumption assumes productivity scales linearly with team size, which again observation indicates isn’t the case. Software development depends very much on communication between team members. The biggest issue on software teams is making sure everyone understands what everyone else is doing. As a result productivity scales a good bit less than linearly with team size. As usual we have no clear measure, but I’m inclined to guess at it being closer to the square root. If we use my evidence-free guess as the basis then to get double the productivity we need to quadruple the team size. So our average talent team needs to have forty people to match our ten talented people – at which point it costs twice as much.

CheaperTalentHypothesis

アメリカのソフトウェア企業の給与体系がどのようなものになっているかは知らないが、彼らが生産性の高いプログラマを集めることができ、「その生産性に見合っているがその生産性ほどではない給料」を支払うことに成功しているとすれば、彼らがソフトウェアやインターネットの世界を席巻するのは当然とも言える。そして横並びで物事を扱うことに長けている日本が遅れをとってしまうのも、もしかすると当然の事なのかもしれない。
ちなみに以前開発チーム内で以下のリファクタリング本を輪読したのだが、かなり為になったのを覚えている。「そんなの当たり前だよね」という話も数多く載っているのだが、それが現実にはあまり守られていないのというのもこれまた事実であり、コード書きとして身を引き締める為にもいい読書でした。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

• 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
• 出版社/メーカー: ピアソンエデュケーション
• 発売日: 2000/05
• メディア: 単行本
• 購入: 94人 クリック: 3,091回
• この商品を含むブログ (312件) を見る

「初心者」って言葉を使ったとたんに話が分散するから使わない方が良いと思うけど。

Brainf.ck – 初心者が最も実装しやすい言語
C – 最も言語実装初心者向け
JavaScript – 最も初心者に身近
Perl – 最も初心者に(も)優しいコミュニティ
Python – 最も自言語初心者に優しいユーザーたち?
Ruby – 最も初心者に優しい言語の父

404 Blog Not Found:初心者向け言語もいろいろ

上の弾さんのエントリは多少僕の言いたいことを書いているけれど、要は「初心者向け」とかいうんじゃなくて、
誰のどういう動機に対してどの言語が向いているのか
という話をしなければならいんじゃないだろうか。まだ駆け出しプログラマの動機としては例えば以下のようなものがあるだろう。

• プログラミングの実行環境を整えるのが面倒
• 「面白い」って友達に勧められたプログラミングだけど、面白さ分からない。分かりたい
• 「抽象化」ってなんじゃらほい。「関数型」ってなんじゃらほい。「オブジェクト指向」って
• 兎に角ちゃっちゃと動かして遊びたい

とかまあ色々あると思う。またプログラマを管理する立場にあるプログラマとしては、

• セキュリティホール量産困る
• バグたくさん、困る
• 読めないコード困る
• すぐに戦力になってもらわんと困る
• 時間がかかってもいいからスーパーハッカーに育てたい

とかまあそういう事を考えているであろう。そういう風な動機に対してそれぞれ向いている言語を提示するべきで、セグメンテーションすることもなく「初心者向け」とか書いて議論していても、結局それぞれが頭の中に浮かべているシチュエーションが違う訳で、話が噛み合う訳もない。

Matzさんがまた示唆に溢れる事を書いている。

ここから「初心者向け言語が避けていること」言い替えれば「初心者が苦手なこと」が何であるかだいたいわかる。彼らは「抽象化」が苦手なのだ。

Matzにっき(2008-02-04)

そうそう、そうなんですよね。分かっていても中々言語化できなかったけれど、抽象化を理解し、その重要性を理解し、実際の仕事の中でその理解を役立たせることが出来るようになって、自分がやっとプログラマとして次のステップに進めた事を思い出した。逆にそれが出来ていない人は、いつまで経っても初心者の域を出ないとも言える。そして悲しいことに、この壁を超えるに必要なのは経験年数ではない。どんどん勝手に学んでいく天才も世の中にはいるだろうけれど、平均的にはやはり抽象化を行い易い言語を身につけ、良い抽象化を行っているソースを読み、自分のプログラムの中にどのように抽象化が活かせるのか真剣に考えた上で何度も失敗し身に付いていくものだろう。
まだ勉強途中だけど、以下の本はこと「抽象化」ということに関しては世界一の名著だと勝手に信じ込んでいるのでここに宣伝しておきます。あまりにも有名な本なので余計な事は書きませんが、僕に「プログラミングの奥深さ、難しさ、面白さ、神聖さ」を教えてくれた神本です。

Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science)

• 作者: Harold Abelson,Gerald Jay Sussman,Julie Sussman
• 出版社/メーカー: The MIT Press
• 発売日: 1996/07/25
• メディア: ペーパーバック
• 購入: 12人 クリック: 254回
• この商品を含むブログ (60件) を見る