職人芸、あるいはブラックボックスの悲劇

http://www.atmarkit.co.jp/fembedded/chaos01/chaos01a.html

ほほう．実に挑戦的なネタですね．相変わらず突っ込みどころ満載です．言ってることはウソとは限らないが，どうにも胡散臭さがつきまとう．
今回はさわりだけのようだから，とりあえず次回待ちかな．*1
http://d.hatena.ne.jp/JavaBlack/20050720#p1
http://d.hatena.ne.jp/JavaBlack/20050624#p1
http://d.hatena.ne.jp/JavaBlack/20050605#p2

一方で開発ノウハウが属人的となり、職人技をチームで共有できないというデメリットもあります。現在は「その人にしか分からない」という属人性が、市場の変化に対応できない原因の1つとなっています。

いやー，ソフトウエアがその人にしか分からないのも見積もりがほとんど外れるのも，「ソフトウエアの持つ本質的な複雑さ」が原因ですよ．もちろん可読性の低いソフトを書く人もいるけれど，それは職人芸的ソフトウエア開発とは別次元のお話です．

加筆：可読性が高く，他人にも理解しやすいソフトウエアを作成するテクニックは知られている．ただし，それを使いこなすのには高度な技術力が必要になる．つまり理解しやすいソフトウエアを作るのは，極めて属人的な技術なのである．属人性の否定は，分かりやすいソフトウエアやノウハウの共有*2の否定でもある．

*1:だいたいこの手のお話のパターンは，１，従来は職人芸的な開発手法でなんとかやってきた．２，最近の高度化複雑化したソフトウエアでは，「時代遅れの」職人芸的なやり方がむしろ足手まといになってきた．３，そこで登場するのが「科学的」な新時代の開発手法です．このような「科学的」開発手法ならきっとうまくいきます．なぜなら「科学的」だからです．21世紀はロケットが月にいく科学の世紀なんです．
アホらし．

*2:ちなみにノウハウの共有の最大の障害は，価値のある情報への正当な対価の支払いである．これはナレッジマネジメントの基本．