それって食えるのか？

最後にもう一度。高度な仕事になるほど個人に依存するのは避けられないし、属人性を排除すべきではない。属人性を排除して各人の能力を均一化して扱おうとしたソフトウェア工学は根本的に間違っている。
従来のソフトウェア工学が決定的に間違っている点

何か違う。（トラックバック先に書かれた範囲では）ソフトウェア工学は間違ってない。

「工学」とは何かを考えるときに、よく引き合いに出されるのは「理学」。



「工学」は「工業」に通じるので、全体としての生産性を上げたい、というのが目標。何故そうなるかを解明できているかどうかなんて、ときには二の次、三の次にされる。
だから、属人性を排除したい、ということは工学として当たり前のこと。

目指すべきところが「属人性を排除する」だけではないけれど、工業として成立するためには、安く大量に作れる、ということが大きい。
トラックバック先の主張をソフトウェア以外にも通じる言い方に変えれば、

一握りの職人が活躍できる環境をそろえてあげれば、バラ色の未来が待っている

ということにならないか？

包丁ひとつとっても、職人の鍛冶屋がたたかなくても、ある一定の品質さえ確保できれば、おいしい刺身にありつける（可能性が出てくる）のさ。

全て職人がやらなくても、ある程度の品質を保ったものを大勢に提供できる
ということは、工学として大事なことだよ。

分かりやすい実例を探しにくい、という意味では、ソフトウェア工学は、未だ成熟してないんだろう、ということなのかしら。



トラックバック先が書くように、「なぜ、属人化が避けられない」のだろう。

■具体的な処方箋を提供してくれてない

「構造化」に代表される【技術】については、具体的なやりかたを提供してくれるものがあまりない。いや、ほとんどない。
「共通的な処理をくくりだして、サブルーチンにしましょう」って、言われても「共通的な処理」がどこからどこまでをくくりだすかが悩みなのに。
具体的なやり方を提示してくれたのは OMT だけだな（個人的な好み）。

プロジェクトの管理のしかたや進め方については、主題が「処方箋の提供」だから、書かれているのは当たり前なのだけれど...

■具体的な手段を提供しても使ってもらえない

先人が苦労して解決方法まで何十年も前に分かっていることなのに、同じ苦労をどうして好き好んで（としか思えない）繰り返したがるかね。

• ソフトウェア工学に対する誤解
  コードを書く（or 設計する）ための技術だと勘違い。
  プロジェクト管理のしかたなどについて研究されたものも昔からあるのに、食わず嫌いどころか探そうともしない。
  
  
• 経験からくる諦め
  今まで苦労してきたことが、本一冊で解決できりゃあ苦労しないよな、と、読みもしないで諦める。
  本は読んだが、「俺のところじゃあなあ」と実践せずに放置するのも、この部類か。
  
  
• プライド
  俺のやってることが、その辺のやつらにできるか！、という障壁。
  何年もかかって身につけた技術が本一冊で誰にでも手に入れることが出来る、ましてや、もっといい方法があったなんて、と分かってしまうことに対する恐れ。
  
  
• 勉強嫌い
  おれは勉強苦手だから、とか、座学なんて実践ではクソほども役に立たないとか、言い訳はいろいろあるにしても、ソフトウェア工学をまともにやってるやつは少ない。
  「工学」とはいえ、「学問」だから、適正な評価が出る前に地雷を踏んでしまうこともあるのだけれど。
  
  
• 変化が大きすぎる
  本は面白いし、納得できるところもたくさんある。でも、今やってることと違いすぎて、実践するための一歩が踏み出せない。
  仕事でソフトウェアをやってる人にありがちなパターン。
  実践しようとしたのだけれど、「昔は腕を鳴らしてた」上司につぶされる、というのもこれに入るか。
  

もっとありそうだな。書いてて、自分の胸まで痛くなってきた　X-(


繰り返して書くけど、ソフトウェア工学 だからこそ、属人化の排除を目指すのだと思うよ。
ソフトウェア道 だったら、平準化を切り捨てるのはありだと思うけどさ。


とはいえ、トラックバック先に共感できる部分はあるのだけれども、。

30人のクズを集めてくるよりも、一人のスーパーマンに任せておけ(*)ば、あんなひどいことにはならなかったのになあ、というのは、仕事をやってると、割とよく目にすることです　:-)