Business On DemandというWebの天才プログラマはいらないのか？という記事を読んだ。以前自分自身の記事の単純に真似すると痛い目を見るにも関連があることなので、思うところを書いておく。

もうちょっと上をたどると同Business On Demandの「CNET Japan Blog – 梅田望夫・英語で読むITトレンド」という記事。これは［梅田望夫・英語で読むITトレンド］続・100万行のソフトの作り方という記事の感想であって、この記事にはおらの駄文の単純に真似すると痛い目を見るに繋がっています。まぁこの文章も元記事があるわけですが。
ぐるーっと回って自分のところに帰ってきたそんな感じ。
他にも、僕が以前に書いた
プログラマってなりたい仕事？
日本企業は優秀なエンジニアを必要としない
なんて駄文も関係あるかもしれません。
さて、
「リスクの程度と場所の違い」という観点からこの話を考えてみます。
ここでいうリスクとは、
リスクを増やすことによりリターン（プラスのリターンだけでなく、マイナスのリターンも含める）を増やす方向に働かせるもの。とでもしておきます。
もちろん必ずリターンが増えるわけではなく、リスクを増やすと、予想されるリターンの誤差が大きくなっていきますので、リターンが負の値になる可能性も増えていきますし、その負の値も大きくなっていきます。
リターンは、顧客がハッピーになるとか、収益があがるとか、楽に開発できるとかそうゆうのがプラスですし、予期しないバグが発覚するとか、仕様に満たないものができあがって顧客に怒られるとかがマイナスになります。
顧客が要望しているものを解決するために、枯れた技術を当てはめて解決していきましょう。というスタンスは、リスクを少なくして、リターンの誤差を減らしていくことを目指しています。
当たり前の技術を使って、想像できうる範囲内のものを、想像できうる範囲の予算で（予算は厳密じゃ。）作り上げていくのを目指します。
この場合「プログラマの能力」というものはリスクのひとつとなりますから、それも排除する方向に動くでしょう。どんなプログラマでも一定の成果が得られるような開発構造に進んでいきます。
ちょっとだけリスクを取った場合、枯れそうな技術を導入するというリスクの取り方があります。メインフレームベースのシステムを使っていた顧客にPCベースのシステムを入れるってのもひとつのリスクです。そのためにちょっとだけ「プログラマの能力」の下限を上げなければならないかもしれません。
ちょっとだけリスクをとればちょっとだけリターンがよくなる可能性があがります。しかしその分、リターンの誤差の割合も増えていきます。負のリターンになる可能性も増えます。
枯れている技術と枯れている技術を組み合わせて新しいものを作るというのも、一つのリスクです。リスクが増えた分、そのリスクに対応した必要とされる「プログラマの能力」があがっていきます。ただしリスクが増えた分、リターンもよくなるでしょう。顧客がよりハッピーになるかもしれません。しかし、その分リターンの誤差も増えていきます。負のリターンになる可能性ももっと増えます。
新技術を開発していくというのもひとつのリスクです。これは先のリスクに比べてちょっと大きなリスクですね。その分、顧客がよりハッピーになることが予想されますが、もちろん、リターンの誤差も大きくなります。
スタートアップの企業の場合でも、同じことです。
新技術を開発して大きな利益を得ようとすることは、大きなリスクです。リターンの誤差が大きいことも簡単に予想できますし、ほとんどが負のリターンになって倒産していきます。
大規模開発の場合、見えないリスクがいっぱいあってリターンの誤差が大きくなりがちですし、それを小さくしたいのは当然必要なことですから、リスクをできるだけとらないというのは戦略の一つとして重要です。
どのようなリスクをとって、どのようなリターンを期待するのかは、それぞれの顧客や企業によってまちまちだと思われます。
大きなリスクをとる開発には天才プログラマが必要になります。天才プログラマがリスクを下げる方向に働くからです。新技術を開発するための必要な技量や経験がリスクを下げます。でもリスクを取らない場合は、天才プログラマは必要ありません。逆に天才プログラマ自体がリスクになる可能性もあるかもしれません。
全部のリスクをなくすことはできませんから、この部分のリスクは増やすけれど、こっちの部分のリスクは減らしたいという、リスク配分も行われるでしょう。
日本で行われている個別業務システム開発の場合、
市販APPのカスタマイズで済ませるとリスクは少ないけど、便利さが足らないので、ちょっと（かなり？）リスクをとって新規開発を行い、業務の利便性というリターン得ようとするのでしょう。新規開発を行うリスクは取るけれども、開発に伴うリスクはとりたくないなら枯れた技術を使うでしょうし、もうちょっとリスクをとって、新技術でもっともっとリターンを増やしたいと考えるかもしれません。
僕が想像するに、日本での個別業務システム開発では、新規開発に伴うマネージメントや設計に関するリスクを大きめに取って、要素技術に関する部分のリスクを少なめにするのではないでしょうか。
ですから、マネージャーやアーキテクトに優秀な人材が必要になり、プログラマはそこそこの人材があればいいことになるのではないでしょうか。
リスクマネージメントは、人それぞれ、企業それぞれ、文化それぞれによってまったくもって違うものだと思いますので、どちらが正しいってことは無いと思います。
そこまで厳密にリスクマネージメントをしていなくても直感的になんとなく、このへんがやばそうだなとか、考えているうちに経験的に今の状態のリスクの取り方になっているというのもあるかもしれません。
天才プログラマは、リスクの大きなところに出没することが多いと思います。そのような関係から先の文章では天才プログラマは必要ないことになるのだと思います。また日本ではそのようなリスクをとることが少ないので、日本全体として天才プログラマの需要も少ないのでしょう。

アメリカの場合は市販されているＡＰＰ（ＳＡＰのＲ／３とか）のカスタマイズ程度で済むと聞いていますので、

僕はこの部分に関しても、日本とアメリカのリスクの取り方に違いがあるんだと思っています。
日本では日常業務の進め方を変更するというリスクをとりたがりません。そこでシステム開発において現在の業務にあわせるようにシステムを作りこみます。日常業務の進め方を変更するリスクを少なめにする代わりにシステム開発のリスクを大きめにとるようです。
アメリカではこのあたりのリスクの取り方にもバリエーションがあります。
ひとつに、システム開発のリスクをとらずにできるだけ市販されているAPPのカスタマイズで済ませてしまい、日常業務をそのシステムにあわせてしまうというリスク（コスト？）をとります。
これは一般的なAPPのカスタマイズであれば、人（使う人やメンテナンスする人）が変わってもそのシステムに馴染みやすいという、ひとつのリスク軽減にもなっているんだと思います。
逆に日本のようなリスクの取り方をする場合もあります。
ただし、このあたりのリスクの取り方は、大企業であればあるほど、できるだけ定量化して戦略として熟慮しているようです。

天才は必要ないといっているだけで、それもマネジメントしづらいだけで、言うことさえ聞いてくれれば何も問題ないんです。

これ、個人的にはかなーり笑いました。同じような経験があるもんで。。これって言い換えると、「こっちでリスク取ってるんだから余分なところでリスクを増やすんじゃない。」ってことだと思います。
リスクとリターンって考え方は投資の話から思い出した話なんだけど、結構いい感じでまとめられたかも。まぁ企業戦略なんだから、リスクとリターンを考えるのは当然かもしれないけどね。
自分にとって働きやすい「リスクの程度」ってのがあるので、どんなリスクをどの部分でとるのかどんなリターンを目指すのかは、ばらばらです。このあたりって定量化しづらいからよくわかんねぇんだよね。自分自身はリスク取りたくないけどリターンは増やしたいので、他にリスクをうっちゃっておいてリターンだけGetってのを狙うし。
俺って、リスクマネージメントをまだまだ勉強しなきゃだめなんだよなぁ。なんかいい本無いかしら。
以前読んだ「リスクとリターンで考えると、人生はシンプルになる!　山崎 元 (著)」という本を思い浮かべながら書いてみました。
別にこの本は投資とか企業の意思決定とかの話じゃなくてただの人生相談の本なんだけど、リスクとリターンで考えると、いろんなものがすっきり見えて面白いです。もちろんすべてのリスクを定量化することは難しいし、単純にリスクとリターンで考えてしまう危険性も否定しないけど、考え方のひとつとしてとっても面白かったです。
考え方の一つとしていかがでしょう。
感想お待ちしております。