<< 前 ホーム 次 >>

bakaid: 200908101

東スポの弁護士追跡劇の記事がむっちゃおもろい (笑)。

--

アニマル・デベロップメントを提唱する自分からすると (笑)、
そもそもテクノロジーとアニマル・スピリットの間に
そんなに距離があるのかと問いたいね。

テクノロジーがテクノロジーたるには社会との関わりが
必要で、社会はアニマル・スピリットで動いている。

優れたテクノロジーが広く受け入れられないなんて
現象は腐るほど見てるだろうし。広く受け入れられる
テクノロジーにしても、広く受け入れられる理由は
『美しいから』だったりする。

Javaがこれほど当たるなんて、J.Goslingも思っても
みなかったろう。最初はセットトップボックス向けの
言語で、それが世に知られるようになったのはブラウザに
組み込んでアニメができるからで、本格的に広まったのは
サーバサイドでだった。当たった理由はいろいろある
だろうけど、『運が良かった、タイミングが良かった』
っていうのが本当のところだろう。

Rubyの膨張が止まったなんて誰にわかる? まだPCを
触ったことのない人なんて何十億といるだろう。あるいは、
既存の言語を置き換えるだけでも数千万はいるだろう。

膨張が止まってないとすれば、カギを握っているのは
アニマル・スピリットだろう。言語の進化なんてのは、
まつもとさんもいってるように、ノロノロとしたものだ。
シンタックス・シュガーを1つ加えただけでユーザが
何万人も増えるわけもない。

でも、アニマル・スピリットを刺激すれば? Rails
みたいな現象がもう一度起きないなんて誰がいえよう。

--

まぁ、こういうのは山師の発想で、いかにも新山さんが
嫌いそうな感じはする (笑)。

--

しかし、その新山さんこそ、アニマル・スピリットの
典型例でもある。

新山さんが『合理的』であるなら、日本にわざわざ
帰ってくるようなこともなかったろうし、障害者向けの
ソフトウェア開発なんかよりももっとお金の稼げる
仕事を選んだはずだ。

※ 『障害者向けのソフトウェア開発』の部分は自分の
    単なる憶測なので本人に問い合わせないように (笑)。

--

ああ、煽ってるわけじゃないんだよね (笑)。

自分としては、RubyKaigiにそんなに思い入れがあるわけじゃ
ないから。

Rubyにしても、Rubyそのものに思い入れがあるわけじゃ
なくって、Rubyに集まってる人に思い入れがあるわけで。

もし仮に、そういう人たちがRubyから離れてしまったと
しても、その人たちに対する思い入れは変わらないんだよね。

まぁ、ムリしてやるまでもないことだろうし、やるん
だったら、体調に気をつけて楽しんでくださいとしか
いえないなぁ。

--

しかし、オレが書くことの99%くらいは我田引水だな (笑)。

--

いや、ビジネス側のほうが賢い可能性だってあるんじゃ
ないか。

『最近は納期が短くなって』みたいな話をよく聞く。
でもって、その理由は『競争が激しくなって』みたいに
いわれる。

もちろん、その可能性は否定しない。

でも、最初はそうだったかもしれないが、実際にやって
みて気づいたんじゃないか。『これはイケル!』って。

納期が短くなるってことは、納期がズレたとしても誤差が
小さくなるってことだ。これはビジネス側にしてみれば
福音だ。大きなリスクを取らずに済む。

完成したときに、もし気に入らないところがあったら、
保守契約でやらせることもできるし、新たに開発契約を
結ぶこともできる。そもそも、完成しなかったら払わない
こともできる。

じゃあ、開発側はどうすればいい? もちろん、小さくて
動くシステムを素早く完成させて、それをちょっとずつ
大きくしていけばいい。その都度お金をもらえばいい。

--

開発側が進化的システムに踏み切れないのは、やっぱり
変更コストカーブのせいなんだろうな。

それ以外には因習くらいしか考えられない (これまで
それでやってきたんだから、それでいいじゃないか)。

でも、変更コストカーブは、XPの初歩なんだよね。

プログラミング技術は半世紀以上進化してきたんだけど、
その中でも、変更コストカーブを下げるっていうのは
大きな領域を占める。代表的な例がモジュール化だ。

何度か書いてるけど、オブジェクト指向を否定する
関数型大好きな人でも、モジュール化を否定する人は
見たことがない。それほど重要なプログラミング技術だと
いうこと。

もちろん、変更の種類によってはモジュール化が役に
立たないこともある。広範囲に変更しないといけない
場合なんかがそう。でも、それほど大きな変更は、
ビジネス的に失敗してる可能性のほうが高いんじゃ
ないか、フツーに考えて。そんな変更が必要になるなら、
どんな開発手法を採用してても、作り直すのが一番安上りに
なるんじゃないか。

もちろん、作り直すんなら早いほうがいいし、それを
見極めるためには早く動かしたほうがいい。

--

いや、でも、工事進行基準もマヤカシだよな。

ちょっと例に出して申し訳ないんだけど:

http://timekrei.tenda.co.jp/other.html

一番最初の図を見ると、要件定義とか、設計とかにお金
払ってるわけでしょ。客からすれば、そんなもんの
ドキュメントもらってもクソの役にも立たない。
役に立つとすれば、あとで瑕疵契約結ぶときに有利に
なるとか、そんな後ろ向きの話でしかない (いや、
それも大事なことだろうけど)。

小さくて動くもんにお金払って、あとは機能追加する
たびにお金払うほうがよっぽど健全だろう。

本家Permlink

<< 前 ホーム 次 >>


Copyright © 1905 tko at jitu.org

バカが征く on Rails