kなんとかの日記 このページをアンテナに追加

2009-02-04

従来のソフトウェア工学が決定的に間違っている点

| 02:41 |  従来のソフトウェア工学が決定的に間違っている点を含むブックマーク

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

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

仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。

よく、ソフトウェア開発を工場での作業に例える人がいるけど、これも「属人性を排除できる」という勘違いからもたらされているのではないだろうか。属人性を排除して能力を均一化できると考えているから、工場での作業に例えてしまうのだろう。そうではなく、属人性は排除できないという立場に立てば、もっと違ったモデルに例えるべきだとわかる。

たとえば水泳の「チーム北島」に例えるのはどうか。チーム北島では、北島選手のためだけにコーチや栄養士など何人ものスタッフがチームとしてサポートしている。あるいは売れっ子マンガ家とそのアシスタントでもいい。どちらも、たった一人の秀でた才能のためだけに何人ものスタッフがサポートしている。

ソフトウェア開発も同じような体制にしたほうがいいのではないか。生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。Ruby の開発でいえば、まつもとさんやささだ先生にサポートスタッフ (あるいは秘書とか内弟子とか) をつけて、極力彼らが雑用をせずに Ruby 開発に専念できるような環境を整えるべきではなかったか。少なくとも、大きなリリースを控えている忙しいはずの時に、主要開発者の方たちが壊れた Visor の替えを買いに走ったりとか、「雑用が多すぎて…」と愚痴ってるような状況は間違いだといえる。

属人性が重要だとすると、ソフトウェア開発が個人に依存することになるのでそれはよくないと考える人がいるかもしれないが、そもそも高度な仕事というのは個人に依存するしかなのだ。なぜなら、個人に依存せずにできるような仕事は高度でないからだ。特にソフトウェア開発では高度でない仕事は自動化しやすいので、自動化できないような高度な仕事しか残りにくい。

別にソフトウェア開発に限らず、どの分野でも高度な仕事は個人に大きく依存する。経営だってそうだろ? Steve Jobs がいなくなれば Apple は緩やかに衰退していくだろう。実際、井深氏と盛田氏が亡くなったあとのソニーは緩やかに衰退していき、今の惨状はみなさんご存知の通りだ。今は絶好調の任天堂だって、もし宮本茂氏や岩田聡社長がいなくなることになればどうなるかわからない。個人に強く依存するリスクを嫌うなら、属人性を排除するのではなく別の方法、たとえば同じような個人を育てたり見つけ出すことを考えるべきであるが、それは長くなるのでまた別の機会にしたい。

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

kmachukmachu 2009/02/05 07:12 「ソフトウェア工学」の適用先が(言語の開発のような)高度な仕事なのかどうかは、議論の余地があるかもしれませんね。

pekepekesamuraipekepekesamurai 2009/02/05 08:37 unique ですが、たしかOracleでも同じような感じだったかと。(null重複許可)

はじきたい場合は、not null をいれるか、default とかで妥協するとかですかね。

tanotano 2009/02/05 10:31 SQLの標準仕様ですね。

顧客ID|名前|あだな(任意)
のようなカラムで取り合えず、「あだな」にNULLを入れとくけど、
あだなの登録時に重複されると困るのでユニークにしておくとか。

null重複不可がほしい場面はnullの代わりにアプリで固定値つっこむのがよいと思います。

まっさちゅーまっさちゅー 2009/02/05 10:42 開発という言葉でひとまとめにしすぎじゃないかな。アーキテクチャはアートだと思うんだけど、それを実際のコードに落とし込む作業は特にアートである必要はないと思う。

tmtmstmtms 2009/02/05 11:19 null=null も偽なのでそういうものです。

とおりすがりとおりすがり 2009/02/05 11:33 削除日でuniqueにする場合は0をいれてます。

kwatchkwatch 2009/02/05 19:48 うおー、SQLに詳しいみなさん、どうもありがとうございます。
これがSQLの標準なのはわかりましたが、個人的にかなり困った仕様です。
今使っているORMが、「deleted_atがnullなら生きているデータ、そうでなければ削除されたデータ」と見なしているので、not null default 0 とかできないんです。
どうしよう、ORMを改造するしか。

kwatchkwatch 2009/02/05 19:57 kmachuさん:
例が2つとも天才により過ぎているので勘違いさせてしまっていると思いますが、それほど高度でない場合でも個人によって生産性や品質に大きな違いがある点は変わらないと思いますので、「属人性を排除すべきでない/できない」という結論は変わらないと思います。

まっさちゅーさん:
アートかどうかは関係ないです。個人による差が大きければ、アートであろうとなかろうと属人性を無視すべきではないです。あとソフトウェア開発では自動化しやすいので、誰にでもできるような仕事はすぐになくなって、より高度な仕事しか残らないと思います。誰にでもできるような仕事が残っていること自体が問題と見なされるのではないでしょうか。

beyondseekerbeyondseeker 2009/02/05 20:52 「従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている」というのは興味深いですね。このような主張をしている文献をいくつか提示していただけると、さらに議論の幅が深まるかもしれませんね。

kwatchkwatch 2009/02/05 21:55 beyondseekerさん:
たしかにそうですね。僕は「ソフトウェア工学は属人性を排除しようとしている」というのは共通認識として得られていると思ってましたが、そうでもないかもしれません。
文献となると学者ではないのでわからないですが、「ソフトェア工学 属人性」でぐぐるとそれなりにヒットしましたので紹介します。

http://techon.nikkeibp.co.jp/article/NEWS/20060217/113414/
> ソフトウエア開発から属人性を排除して科学的・工学的な手法で開発しよう,という考え方が伝統的なソフトウエア工学の立場だが...

http://topse.jp/dl/pdf/JISSEN-Oct-11-07.pdf
> ソフトウェア工学とは『ソフトウェアの開発、運用、および保守に対する系統的で規律に基づいた定量的アプローチ』[SWEBOK2004]であり、属人性を排除して一定の品質を保証すること(高品質)、および、生産性の向上(大規模・多品種)に寄与する。

https://camwe001.nagaokaut.ac.jp/syllabus/syllabus/search/SyllabusInfo.do;jsessionid=4DEB871C3A681B1271AEC299FCFD29E1?mode=print&nendo=2008&kogikey=nbB2506860
> 情報処理システムを構成するソフトウェアを,人間の経験や直感といった属人性に頼らずに,均質,高品位に開発・管理することを目指す「ソフトウェア工学」について,その考え方と手法に関する知識を修得する。

これでいかがでしょうか。これでもまだ疑問に思われるようでしたら引き続きコメントしてください。

beyondseekerbeyondseeker 2009/02/06 00:21 ご回答ありがとうございます。

先ほどおいらも google で「ソフトウェア工学 属人性」で検索してみましたが、793 件ほどヒットしました。確かに、ソフトウェア工学は属人性を排除するという内容が見受けられますね。なるほど。納得。なにやら疑問か少し見えてきた気がします。

気になるポイントは、下記の2つの問題に対して Yes と答えるか、 No と答えるかです。

1.ソフトウェア工学が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
2.ソフトウェア工学が、開発者の能力を均一化しようとしているか?

ちなみにおいらの考えですが、1についても2についても、ケースバイケースだと思っています。

たとえば、ヒューマンエラーを回避するための研究(例:テストの自動化の研究)であれば Yes だと思いますし、開発チームの適材適所に関する研究であれば属人性は前提条件なので No だと思います。2については、、、Yes の主張をするネタが思い浮かばないのですが、それを否定する理由も見つかりません。大半の研究に関しては、No なのではないかなと思っています。

しかし、

1.ソフトウェア工学の「あらゆる主張」が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
2.ソフトウェア工学の「あらゆる主張」が、開発者の能力を均一化せよという意図を持っているか?

という問いであれば、おいらは No だと思います。

kwatch さんや皆さんがどう思われているのか、ぜひ教えてくださいー。
m(_ _)m

ちなみに、ソフトウェア工学という分野については、定義に曖昧さが残っているようなので(※)、「深く」突っ込まないほうがシアワセになれる予感w。
※. 分野の曖昧性と論争 http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B7%A5%E5%AD%A6

kwatchkwatch 2009/02/06 00:55 > 1.ソフトウェア工学が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
> 2.ソフトウェア工学が、開発者の能力を均一化しようとしているか?

私感ですが、両方ともYES

> 1.ソフトウェア工学の「あらゆる主張」が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
> 2.ソフトウェア工学の「あらゆる主張」が、開発者の能力を均一化せよという意図を持っているか?

だれもそんな極論してません。

> 大半の研究に関しては、No なのではないかなと思っています。

このような主張をしている文献をいくつか提示していただけると(以下略)
というか、属人性を積極的に活かそうとしている分野がソフトウェア工学にあるならぜひ知りたいです。

beyondseekerbeyondseeker 2009/02/06 02:43 回答ありがとうございます。

ここで、kwatch さんの主張に関する私の理解をまとめてみますので、間違っていたら教えてください。

1.ソフトウェア工学に関する研究の多くが、「ソフトウェア開発」から属人性を排除せよと主張している。
2.ソフトウェア工学に関する研究の多くが、開発者の能力を均一化せよと主張している。
3.その主張の出典は、文献以外の何か。


以下、ご質問への回答です。

---
[引用]このような主張をしている文献をいくつか提示していただけると(以下略)

情報の齟齬があるといけないので、念のために確認させていただきます。先ほど私は、「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張を「していない」研究が大半だということを言いましたが、これは「属人性を排除するな」および「開発者の能力を均一化するな」という主張をしたわけではありません。

さて、文献について。

プログラミング言語に関する文献の例として「C Programming Language」を上げてみます。「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。

アーキテクチャ系に関する文献の例として「Patterns of Enterprise Application Architecture」を上げてみます。「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。

開発方法論に関する文献の例として「Extreme Programming Explained」を上げてみます。さまざまな価値やプラクティスを導入することにより開発者に制約をかけてはいますが、やはり「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。

ソフトウェア開発プロジェクトマネジメントに関する文献として「The Art of Project Management」 を例にしても、「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。それどころか、Communication and Relationships や How not to annoy people といった章を割いて非常に人間的な話題に言及していますし、チームメンバのスキルの種類の違いや能力差の扱いについても、「除外せよ」ではなく、どのように扱うべきかを How organizations impact planning の章で詳細に説明しています。


---
[引用]というか、属人性を積極的に活かそうとしている分野がソフトウェア工学にあるならぜひ知りたいです。

情報の齟齬があるといけないので、念のために確認させていただきます。私は、「属人性を積極的に活かそう」とは一言も言っていません。

でも、ネタがないわけではないので上げます。

例えば、デマルコのピープルウェアでは、不服従の社員を積極的に扱う方法について述べています。

小野さんのブログの「プログラマー風林火山(http://blog.livedoor.jp/lalha/archives/50065532.html)」は、エンジニアを風・林・火・山に分類し、その長所と短所を把握して、チームとしてのスキルセットのこれからを考えていくということを述べています。ブログの冒頭で述べられているように、ソフトウェア開発の経験を積み重ねることによって得られた情報をベースにしていることから、このネタはソフトウェア工学に分類可能と言えます。


以上、よろしくお願いします。
m(_ _)m

通りすがり通りすがり 2009/02/06 02:54 細かい文句だけど、Rubyの例に関しては、あれは「Rubyの仕様がむちゃくちゃで、レベルが低い」から、他人が介入しづらいということもあることには注意する必要があると思う。言語処理系であっても仕様がきっちり書かれてさえいれば、過剰に属人性に頼る必要はないと思うのだが。

kwatchkwatch 2009/02/06 04:06 beyondseekerさんは、何が言いたいんでしょうか。
ソフトウェア工学の定義について語りたいなら、それはこのエントリの主題ではないのでご自身のブログでやってください。トラックバックは歓迎します。

> 1.ソフトウェア工学に関する研究の多くが、「ソフトウェア開発」から属人性を排除せよと主張している。
Yes。排除せよ、というよりは排除できる、という感じですが。
> 2.ソフトウェア工学に関する研究の多くが、開発者の能力を均一化せよと主張している。
Yes。均一化せよ、というよりは均一化できる、という感じでしょうか。
> 3.その主張の出典は、文献以外の何か。
これは紹介したリンクでは満足されてないってことでしょうか。大学の講義で使われている資料でもだめというなら、どのようなものを出せば満足いただけますか?
なお「ソフトウェア工学 属人性」だけでなく「ソフトウェアエンジニアリング 属人性」や「CMM 属人性」などでも検索してみてください。それでもだめだ満足できない、というなら、こちらとしてはお手上げです。

> これは「属人性を排除するな」および「開発者の能力を均一化するな」という主張をしたわけではありません。
だれもそんな解釈はしてないので安心してください。単に何を主張したいのかが見えないだけです。

>「C Programming Language」
>「Patterns of Enterprise Application Architecture」
なぜこの2冊? 確かにソフトウェア工学は幅が広いですが、今回の趣旨に対して関係ない本を持ってくる意味がわかりません。

>「Extreme Programming Explained」
>「The Art of Project Management」
>「ピープルウェア」
どれも従来のソフトウェア工学に反旗を翻した内容ですから、「属人性を排除せよ」などという主張が出てくるわけないと思いますが。
というか、これらの書物と今回のエントリで書いた内容とは同じ方向を指してると思いますが、それだと何かまずいでしょうか?

>私は、「属人性を積極的に活かそう」とは一言も言っていません。
だれもそんな解釈はしてないので安心してください。ほんと何を主張したいのかが見えないだけです。

kwatchkwatch 2009/02/06 04:11 通りすがりさん:
別にRubyの仕様がどうのこうのは今回の趣旨と関係ない話だと思うんですけど。
関係ないついでにいうと、すでに決まってある言語仕様を実装するのと、どのような言語仕様がいいかを考えだす仕事では、大きな壁があると思います。また実装するにしても、できのいい実装とそうでない実装には天と地ほどの差があります。たとえRubyの仕様がむちゃむちゃでレベルが低いとしても(とてもそうは思えませんが)、実装の出来不出来は開発者の能力に大きく依存することに変わりはないと思います。
かりにですけど、もし「Rubyの仕様はレベルが低い、オレならもっといいのができる」と言いたいだけならご自分のブログでどうぞ。世界中のプログラマーがあなたに注目することでしょう。

tanotano 2009/02/06 12:59 > これがSQLの標準なのはわかりましたが、個人的にかなり困った仕様です。
> 今使っているORMが、「deleted_atがnullなら生きているデータ、そうでなければ
> 削除されたデータ」と見なしているので、not null default 0 とかできないんです。

データ登録前にfindでチェックするのは問題があるのでしょうか?
何か私が勘違いしているかな?

名の知られているDBMSのほとんどで不利になるIS NULL検索で、
有効レコードを取ってくるはORMの仕様として個人的にはイマイチと感じています。
DB構成の分りやすさとのトレードオフなのは分るけど。

archackerarchacker 2009/02/06 14:33 http://practical-scheme.net/trans/hp-j.html

上からの引用ですが。-------

ハッカーがやっていることは「計算機工学」と呼ばれることもあるが、この用語も誤解を助長するだけだ。優れたソフトウェア設計者は、建築家がエンジニアではないのと同じように、エンジニアではない。もちろん建築とエンジニアリングの境界ははっきりと定められているわけじゃないけれど、確かに存在する。それは、「何を」と「どうやって」の間にある。建築家は何をするかを決め、エンジニアはそれをどうやってするかを考え出すのだ。

「何を」と「どうやって」をあまり分けすぎるのは良くない。どうやれば出来るかを理解せずに何をするかを決めようとするのは、間違いのもとだ。でも、ハッキングには確かに、ある仕様をどうやって実装するか決めること以上のものがある。ハッキングの最良の形態とは、仕様を創ることだ--- ただ、仕様を創るいちばんの方法はそれを実装することだ、ということに過ぎない。

beyondseekerbeyondseeker 2009/02/07 07:28 kwatch さんの主張にはさまざまな興味深いデータやたとえが出てきているので、それらについて、どのような情報源から得ているのかなーというのが知りたかったということと、kwatch さんの主張について、私がうまく理解できていないところを確認したかったために、いろいろと質問させていただきました。

[引用]>「Extreme Programming Explained」
[引用]>「The Art of Project Management」
[引用]>「ピープルウェア」
[引用]どれも従来のソフトウェア工学に反旗を翻した内容ですから、「属人性を排除せよ」などという主張が出てくるわけないと思いますが。

という回答で、kwatch さんの文脈中での「従来のソフトウェア工学」の意味を理解でき、腑に落ちました。

ありがとうございましたー
m(_ _)m

namename 2009/02/09 02:51 ソフトウェア工学に決定的な間違いがあるのなら、「ソフトウェア工学の何をどうすればその間違いが改善されるのか」が欲しかった。
また、ソフトウェア工学の適用が必要な現場でその改善が行われた場合の、改善前後のメリットとデメリットの変化の考察も欲しい。

@ 2009/02/09 20:53 トラックバックの付け方が分からないのでぺたり( 'ω')ノ

http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1#.E4.BA.BA.E6.9C.88.E3.81.AE.E7.A5.9E.E8.A9.B1

kwatchkwatch 2009/02/09 23:41 tanoさん:
> データ登録前にfindでチェックするのは問題があるのでしょうか?
> 何か私が勘違いしているかな?
今は仕方なくそうしているんですけど、やはりDBで制約をかけられるほうが安心できます。

> 名の知られているDBMSのほとんどで不利になるIS NULL検索で、
> 有効レコードを取ってくるはORMの仕様として個人的にはイマイチと感じています。
> DB構成の分りやすさとのトレードオフなのは分るけど。
そうですね。その通りだと思います。
道のりは長いですが、ORMを改造する方向で考えてみます。
有益なコメントありがとうございました。

archackerさん:
> という回答で、kwatch さんの文脈中での「従来のソフトウェア工学」の意味を理解でき、腑に落ちました。
・・・どう腑に落ちたんだろう・・・

kwatchkwatch 2009/02/09 23:45 nameさん:
> ソフトウェア工学に決定的な間違いがあるのなら、「ソフトウェア工学の何をどうすればその間違いが改善されるのか」が欲しかった。
そんなのがあるなら、こっちが知りたいです。
ないから、教育をして地道に人材を育成するのが、遠回りだけど一番の近道とは思ってます。

> また、ソフトウェア工学の適用が必要な現場でその改善が行われた場合の、改善前後のメリットとデメリットの変化の考察も欲しい。
そこまで深い考察はないです。
#ただの問題提起に論文みたいなことを求められてもね。

めしおめしお 2009/02/14 01:27 ソフトウェア工学が間違っているとしたら、間違ったものから得られる所産も間違ってますね。するとたとえばオブジェクト指向なんかは間違ってるものの代表格でしょうか。

たとえばオブジェクト指向言語を使わないでアセンブリ言語で30倍生産性が高いスーパープログラマーがいたとして、一方でrubyとかpythonを使う普通のプログラマーがいたとしたらどうしましょう。普通な人を使う方がいい場合も多々あると思います。

あるいは、30倍な人が太刀打ちできない、300倍の人が必要な問題があったらどうしましょう。300倍の人は1000年に1度しかでてこないとしたら1000年待つんでしょうか。でも無為に時間潰すよりは、学問的なアプローチを進めておいた方が、まあ気休めかもしれませんがマシな気がします。土台があれば30倍の人でも将来300倍の問題をジャンプしてクリアできるかもしれませんからね。

って考えると、ソフトウェア工学は間違っていると断言できない気がします。適用しないほうが合理的な場合もあるっていう話ならわかるけど。
長くてすいまそん。。。

ネットで学ぶソフトウェア工学ネットで学ぶソフトウェア工学 2012/06/09 18:57 なるほど。うちの会社でも属人性の排除を目指すとか言ってる人がいて、もやもやしてました。すっきりした気がする。

ただ、うちの会社は、それほど優秀でない人を集めて、ソフトウェア開発してると思いますが、課題がそれほど難しくなかったり、他で優位化技術があったりすれば、それはそれで成り立つのでしょうね。
(個人の)ソフトウェア開発力では負けていても成り立つ。
ただ、ソフトウェア工学に興味があるものとしては悲しいですが。。。

SHOSHISHOSHI 2013/01/28 10:59 最初は属人的な技芸だったものを調査・分析・解析することで、何時でも・どこでも・誰でもできるようにすることが工学なのでは?
だからソフトウェア工学に限らず○○工学を学んだからと言って、学んだ人がこれまでにない何かを生み出すとは限らない。
○○工学を学んだ人は先人に追いつきやすくなるだけで、それだけでは追い越すことはできないと思う。追い越すためにはそれこそその人の"能力"によると思う。そのレベルまで来てようやく属人性が発揮できるのでは?
一刻も早く(歳を取らないうちに)属人性を発揮できるレベルまで引き上げてくれるのが○○工学だと思う。他人と同じこと(=○○工学を学んだだけ)をしていてはダメだよ。

トラックバック - http://d.hatena.ne.jp/kwatch/20090204/1233769288