ソフトウェア工学とスーパープログラマは両輪

さて。
そもそも何の話が発端だったかというと

バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。

従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記

ということでソフトウェア工学が間違っている、という話だった。この点についてはスーパープログラマの、ボリューム感のある仕事における有用性の限定度合いについて述べることが、一つの反証になりうるわけだから、スーパープログラマという点にこだわらざるを得ない。もちろん、事例が別のものであれば、別の反論をするだろうし、あるいは、納得のいく事例だったら反論しないだろう。文脈の話はそれだけのこと。
まあでも話がだいぶ変わってしまったみたいだから、ゆっくりと考えてみよう。
前置きとして、僕は年末にこういうエントリを書いた。

文芸センスに頼らなければならないのがIT業界なのだとしたら、IT業界は永遠にこのまま人海戦術の方法論で仕事をしていくしかないだろう。

「ITは文系領域も多いからコンピュータサイエンスなんて知らなくていいんだよ」的な言説が蔓延ることが業界の現状を招いているのだが - novtan別館

ここでいうコンピューターサイエンスとはちょっと正確ではないかもしれないけれど、ざっくりとまともなプログラマになるための方法論という意味で捉えている。もちろん、それ以外の部分も多く含まれるんだけど。
かたや、ソフトウェア工学は、プログラミングや設計そのものではなく、そのプロセスを検証していくものだ。これらの概念は、適用範囲が別個のものであり、それに対するスーパープログラマのポジションは、あくまで実務を行うものに過ぎない。
じゃあ、本題。

ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの？
スーパープログラマーは生産性がスーパーなわけではない - novtan別館

文章の意味がわかりません。ワシの頭でもわかるように書いてください

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

これは

なんか、Dan氏は
にも関わらず、
ソフトウェア開発も同じような体制にしたほうがいいのではないか。生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。
とならないのはなぜか
・生産性は定数ではない
・生産性は何を生産するかで多いに変わってしまう
・「生産性が高い」プログラマーほど仕事を選ぶ

ということを上げているんだけど、なんでこれが理由になるのか分からない。「スーパープログラマーでもいつも生産性が高いとは限らない」ことの理由としてならわかるけど、体制が変わらない/変えられないことの理由としてはさっぱり分からない。誰か解説して。

Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記

ということに対する反応。
「「スーパープログラマーでもいつも生産性が高いとは限らない」ことの理由としてならわかる」
のがなんでなのかイマイチわからないんだけど、想像してみると、

• 生産性は定数ではないから、スーパープログラマとて常に生産性が高いとはいえない
• 生産性は何を生産するかで変わってしまうから、スーパープログラマとて常に生産性が高いとはいえない
• (最後のは当てはまらないかな)

という感じだろう。dankogaiが言いたいのはこうではないか。

• 生産性は定数ではないから、常に生産性が高いかどうかわからないことのために体制なんか変えるかボケ
• 生産性は何を生産するかで変わるから、以下同文
• そんなスタッフつけたところで、スーパープログラマーは仕事が気に入らなきゃいなくなるよ

ということだろうね。
つまり、この最後のところが、僕のコメントなわけだ。すたっふーがどんなにいようが仕事が気に入らなきゃ選ばれない。逆に、どんなに劣悪な環境でも仕事が気に入ったらやるんじゃないの、dankogai的スーパープログラマは。dankogaiも当該エントリではそれがプログラマの習性だと述べている。

そもそもの前提として、業界は今現存する(あるいは将来生まれる)スーパープログラマーで全ての需要が満たされるというものが成立しないと、属人性を排除して均質化および全体の質の向上を図るという戦略が間違っているとはいえないから。
スーパープログラマーは生産性がスーパーなわけではない - novtan別館

なんでそんな前提が必要なの? 単に生産性の高い人の能力を引き出す、というだけの話になんでこんな前提が必要となるわけ?

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

それは、スーパープログラマ以外の人も含めて、業界全体の生産性を高めようとするソフトウェア工学が間違っていると言ったからだよ。スーパープログラマで需要が満たされるのであれば、ソフトウェア工学はいらない、ということだからその前提はおかしい、と言っているわけだ。もし、そういう前提じゃないんであれば、そもそもこの話は成り立たないわけだから。

Dan氏じゃねーよ、キミのことだよ。「スーパー」とか「天才」とかに過敏に反応しているキミのこと。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

事例に対する反論で事例にこだわらなくてどうするんだ。

ここが根本的な考え方の違いなのかなあ。物量が多いほど能力差による違いが顕著になってくるとワシは思ってるけど、この人は物量の前では能力差は誤差でしかないそうだ。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

それはある意味正しくて、ある意味間違っている。能力差による違いが顕著になる物量と、能力によらず一定時間を消費する物量が存在する。そして、ソフトウェア開発において、前者の物量も、後者の物量も、どちらも存在する。プログラム書く一つをとっても、10000行を書くのに費やす時間がそれほど大きな差になるかどうか。効率の悪い開発者でもタイピングだけは早かったりする。
もちろん、10000行を8000行で済ますことができる場合もあるし、設計しだいでは1000行になるかもしれない。こういう部分では確かに差が出るんだけど。
そして、設計書作成やテストにおいて、その差の出なさ加減は顕著だ。でもって、標準化やテスト技法の進化によって、差が出る部分の度合いを埋める努力は日々行われている。

多大な物量を目の前にしたとき、人海戦術しか思いつかないやつらと、code generationやmeta programmingで物量そのものを大幅に削減しようとするやつらの違いだな。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

ほら、プログラマーの話になっているじゃん。あと、ここで言っている物量は、成果物の物量ではなくて、作業の量の話だよね。大規模プロジェクトにおいて、成果の管理をどう行うかもソフトウェア工学の重要な視点だと思う。

変わるよ。『搾り出す』にはネガティブな意味があるからね。「絞り出す」ならまだよかったけど、『搾』は「搾取」でも使われているようにネガティブな意味がある。知らないみたいだから辞書引くといいよ。「簡単にはでないものを無理に出そうとする、むごく取り立てる」という意味が出てくるから。
これに対して『引き出す』は肯定的に捉えられる。『搾り出す』とは受ける印象がえらい違う。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

だから、それはたとえが悪いんだって。世界の頂点に立つ限界ぎりぎりの戦いだから「簡単に出ないものを無理に出す」わけじゃない。そういうニュアンスを無視して考えるならわざわざオリンピック選手なんて極端な話にする必要ない。体調管理とか、タスク管理とか、そんな程度のことも自分で出来ないからスタッフをつけるってわけじゃないでしょ。

自分のところでは雑用を引き受けてくれる体制ができている」ということを言っているんなら、それでいいんじゃない? いい体制だと思うよ。

世の中にはそうなってないプロジェクトもあるっていうだけのこと。その一例としてもとの文章では Ruby を挙げたけど、目に入ってない? 「スーパー」という単語に目がいっちゃって他の部分が読めてないかもしれないね。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

そうじゃないプロジェクトを減らすためにソフトウェア工学を否定する必要があるわけ？むしろ、そういうプロジェクト管理手法をきちっと適用してもらうことでプログラマーが楽に働ける環境になるんじゃないの？

目的はあくまで個人の能力に大きな差があることを認めたうえで能力の高い人を活かすことであり、そのための例えとして北島選手やマンガ家の例を出しているだけ(もとの記事でも『たとえば水泳の「チーム北島」に例えるのはどうか。』とちゃんと書いてるよね)。能力の高い人を活かせるなら別にチーム北島と同じ体制にする必要なんかこれっぽっちもない。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

目的、という点では完全に同意する。とはいえ

従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている。この点に置いて、従来のソフトウェア工学は決定的に間違っている

従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記

ソフトウェア開発も同じような体制にしたほうがいいのではないか。生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。

従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記

という話だから、需要における現実性とコストの面から言うと、折り合わないというのが僕の主張。だから、ソフトウェア工学は有用。出せる金と、求める信頼性において「安くていいもの」「高くていいもの」「安くてそこそこのもの」が提供できるのがよい。「高くてダメなもの」をどう排除していくか。これも一つのテーマだと思う。

そりゃそうだ、「月70万と140万」の場合の話なんだから。月70万と140万なら、4〜5倍がせいぜいじゃない? 金額を指定しなければ、できる人とできない人で30倍の開きぐらいあるでしょ。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

30倍がどのくらい現実的なのかイマイチわからなかったんだよね。倍で４〜５倍なら、月210万くらいなら30倍のパフォーマンスなのかなあ。

あとさ、『10000円の肉が1000円の肉の10倍おいしいわけじゃない』はどういう意味で書いたわけ? 月140万の人材は70万の人材の2倍も能力が高いわけじゃないってこと? それがキミの感覚?

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

単純に値段が高いことが能力の差に現れないことが多いですね。SIerにおける人材というのは、

• プログラムができる
• 設計ができる
• 全体設計のビジョンが作れる
• いろいろ客に説明できる
• 業務要件分析してシステム設計できる
• X人のチームを監督できる
• 特殊な技術領域に精通

等のさまざまなスキルによって値段がある程度決まってくる。そこに生産性という指標はなかなか入ってこないんだよね。だから、生産性という点で140万の人が70万の2倍の生産性がでるかというと、そういうわけでもない。

だからなんで「もとの趣旨を外してコーディングだけに限定している」の? 個人能力差が大きいことや属人性のことは、別にコーディングに限った話じゃないでしょ?

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

それは、生産性という言葉が当てはまらないからかな。もう一度引用すると

ソフトウェア開発では、個人の生産性は上と下とで 30 倍違うと言われる。これが本当だと仮定したら、これだけ差がでるものを均一化なんてできるわけない (したところで間違った結論しかでない) んだから、属人性を排除することは大きな誤りである。

従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記

生産性に差が出ることが、属人性を排除することが誤りである理由であるならば、それが間違っているといいたいから。次にこうある。

仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。

従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記

これは、上で述べたスキルをもった人材、ということだと思うんだけど、この文章自体は大いに同感なわけです。ただ、ソフトウェア工学の要不要とは結びつかない。

もう一回書いとくね。『個人の能力差はとても大きいのにそれを無視して属人性をなくそうとするのは間違ってる』。だれもコーディングだけに限定した話はしてない。してるのはキミだけ。

Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記

繰り返しになるけど、ソフトウェア工学の属人性排除が個人の生産性の差を理由に否定されるのであれば、生産性に差がつく場所の話をしなければ意味がないでしょう。コーディングだけじゃなくて、テストもそうだと思う。そして、差がつかないところも沢山あるんだよ、というのが僕の主張。
ウォーターフォールからアジャイルまで、様々な方法論がソフトウェア工学としてまとめられてきた。少しでも無駄をなくして生産性を高めようという努力が、品質向上のための標準化であったり均質化のための方法論であったりする。そういったものはコンピューターサイエンスから、あるいは天才のひらめきから生み出される。ソフトウェア工学は、それらをどうやって利用していくかの方法論でもある。不便だからコードジェネレータを作りました、というのを毎回繰り返していても仕方がないのだよね。スーパープログラマがソフトウェア工学を発展させ、どうしてもボリュームの必要な作業を少しずつ効率化していく。物量の問題は近い将来、ある程度解決する(≒ただ作業するためのプログラマは排除されていく)かもしれない。
墓穴を掘らないための努力によって、IT…SIerか？…業界の健全な発展が妨げられているという見方もあるとは思うけれども、それはソフトウェア工学の責任ではないし、むしろ、きちんと工学としてなりたったときにはじめて、属人性のあるスキル以外は不要になる世界がようやくやってくるんじゃないかなあ。