いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。
日経ビジネス online の記事に次のようなくだりがあった:
「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」
IT業界は 100億円かけても使えるものが作れない非常識な世界、というわけである。 まあよく聞く批判で、そう言いたくなる気持ちも理解できるのであるが、 100億円が高いとする根拠がいただけない。 同じ記事中に続けてこういう話が出てくる:
「例えば、自動車を買うとします。 希望の車種と色調を言えば、その通りの車が期限通りに納車される。 万一、色が違っていればすぐ取り替えてくれるし、 その車が動かないなんてことはまずない。 欠陥があった場合、リコールがある。 しかし、コンピューターの場合、自動車ではありえないことが四六時中起きる。 経営トップとしては何とも理解し難いわけです」
つまり、ソフトウェア開発を自動車の製造と比較しているのである。 自動車は、「わずか」数百万円なのに「使える」製品が買える。 自動車と同程度に複雑なソフトウェアを開発しようと思ったら、 少なくとも数億円から数十億円はかかるだろうし、 数十億円かけたところで、 現在の工業製品としての自動車のレベルの品質は望むべくもない。
このような批判は、 「ソフトウェア」を「モノ」と同一視したためにおこる誤解が元となっている。 ソフトウェア開発という「家内制手工業」をせめて「工場制手工業」へ発展させ、 ゆくゆくは「機械制大工業」に進化させようという試みの多くも、 同様の誤解がベースになっているわけで、 「ソフトウェア開発」を「モノ作り」と見なす誤解は、 広く蔓延してしまっているのかもしれない。
問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ？
答: 「設計」である。
自動車とソフトウェアを比較するなら、 「自動車の設計図」が、 「ソフトウェア」(より正確に言えばソースコード) に相当する。 「自動車の製造」に相当するのは、 ソフトウェアを出荷するときに行なう「ビルド」「コピー」「パッケージング」 であろう。
「自動車の製造」には例えば一台あたり百万円を超えるようなコストがかかり、 1万台生産しようとすれば 100億円を超えるコストがかかる。 大量生産すればするほど「製造コスト」が支配的になるから忘れがちであるが、 自動車の設計にも結構なコストがかかっている。 設計図を引くコストだけでなく、その前提となる研究開発も必要だし、 エンジンや制御用コンピュータなどの部品の設計も含めれば、 ゼロから一台の車を設計するコストは、かなりの額 (よく分からないが数億円で済むとはとても思えない) になるだろう。 完全「特注」の自動車を設計してもらうとしたら、 いったいどのくらいかかるのだろう？
一方、ソフトウェアの開発においては、 「製造コスト」は無視できる。 1万本生産するとしても、パッケージングコストは 1 本あたりせいぜい数百円程度だろうから、数百万円程度で済んでしまう。 ダウンロード販売なら何万本生産 (つまりコピー) しても原価は 0 円である (もちろん、ダウンロード サイトの運用などには費用がかかるが、 それは原価ではなく「販管費」である)。
ソフトウェアの設計というと、 要件定義、外部仕様、詳細仕様、等々を作ることを指すことが多いのでややこしいが、 製造業においても、図面を引く前には仕様を詳細につめているはずなので、 自動車の設計図を書く工程を「設計」と呼ぶのであれば、 ソフトウェアのコーディングも「設計」と見なすべきだろう。 コーディングの「家内制手工業」ぶりを批判したいのであれば、 比較対象は設計図を書く工程であるべきであって、 組み立て工程ではない。 ソフトウェア開発の近代化は重要な課題であるが、 そのお手本を「機械制大工業」における「製造工程」に求めてしまっては、 大きく道を誤る。
(つづく)
ちなみに車の開発費は小型車の場合で3社共同開発でも一社800億円、自社で全部持ったら開発工数ももとより増えるので2000億円台では効かないそうです。
マツダの本に書いてありました。
やっぱりソフトウエアのコーディングを「製造」と形容してるのは問題多すぎますね。上流から「設計１」「設計２」３，４，５～みたいな感じのほうがまだ良いような。
Comment by Shinpei3 — 2006年7月28日 @ 09:10
で「設計」だと、当初見積もられていたコスト内でできあがらないとか、そういうトラブルの言い訳がなんかできるんですか？
言葉を言い換えてもあんま効果ないと思うんだけど。
Comment by Bar — 2006年7月28日 @ 12:19
言い訳をするために「言い換え」をしようというのではありません。
ソフトウェア開発の手法を改善する唯一の方法は、われわれ技術者自身が成長することであり、成長するには、そもそもソフトウェア開発が何であるかを理解することが重要だと思うのです。
ところが、ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか、そういう話になりがちではありませんか？
いみじくも「ソフトウェア部品」という言葉が象徴しているように、他の工業製品の製造プロセスを模倣することによって効率化を試みているわけです。これでは効率化が達成できるわけはありません。そもそもソフトウェア開発は製造ではなく、むしろ製造業で言うところの設計に該当するからです。
ならば、同じ学ぶにしても、その対象は製造プロセスではなく、(製造業における) 設計プロセスということになるでしょう。
Comment by 仙石浩明 — 2006年7月28日 @ 14:22
見出しに騙されたなあ。
モノづくりの定義がはっきりしてないし。というかモノづくりって言葉は曖昧だからいろんな使われ方をするわけだろうけど。
＞ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか
そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの？
＞ならば、同じ学ぶにしても、その対象は製造プロセスではなく、設計プロセスということになるでしょう。
なんか言いたいことは分かった。つーか普通に設計やってるやろ。効率考えて。そんなんしてない会社があるんか？思いつきだけで動いてしまうような。。。ITベンチャーではありがちだったｗ
Comment by とおりすがり — 2006年7月28日 @ 15:22
同意です。
SEはデザイン画を描き、PGは設計図を書く。
建築の設計に建築士の資格が必要なようにプログラマにも専門資格を作り、持っていない人は職業プログラムを禁止して欲しいと私は思っております。
Comment by 村人Ａ — 2006年7月28日 @ 16:06
> > ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか
>
> そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの？
その発想は当たり前と思えるだけで、でも実際はそれで効率を上げることは不可能、という主張だと思うけど。
> つーか普通に設計やってるやろ。効率考えて。そんなんしてない会社があるんか？
ほとんどの場合、効率考えて設計してる「つもり」になってるだけだと思うけど。
Comment by anonymous — 2006年7月28日 @ 17:56
モノでも設計でもサービスでもなんでもいいけど、少なくとも頼んだモノは作って下さい。お金を決めて、それで作ると言ったモノは作って下さい。
作ると言ったものが作れない、いくらでできると言ったものができない。納期を守ると約束したのに約束が破られる。
詐欺ですか？
なんでもいいけど約束は守ろうよ。
Comment by 通りすがり — 2006年7月28日 @ 21:41
「ソフトウェア開発」は家を建てるのと同じ
最近仕事でふつふつと自分が感じていることと同じことを考えている人が居た。 仙石浩…
Comment by Net-walker.jp — 2006年7月28日 @ 22:21
>そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの？
昔は属人性が高かったのでそう思いましたが。
近年は、チームでしか動かないので「周辺」つまり
・「サポートチーム」(PMOみたいなやつ。機能してないけど)
・「本」(最近はたくさん売ってる)
・「部門サーバ」のサポート(各部署単位で知識のある人がサーバをメンテしてる)
も、「コスト」に含めるべきな気がしてます。ということで「人件費」
の割合は低下していると思います。
組織的な「知恵」を集積して、必要なところに流すために必要な「金」もソフトウェア開発に必要だと思いますが。
そんなところに重点的にかけてるところがあるかどうかは知りませんが、、
ちなみに私がいるところは、ほとんどが人件費です。(苦笑)
人件費にも回ってない気がするけど。
Comment by 加納正和 — 2006年7月29日 @ 00:01
約束は守りたくても、日本の商慣習は、実際のところ正式には約束したことにはならないんだよね。だって契約書作るのってしてないことも多いし。だからユーザは「頼んだもの」を明確にしないとだめですね。
最終的にソフトウェア開発の成否は「ユーザの意識」にあると思うんですね。最初にきちんと契約書作ることもしかり、ソフトウェア”だけ”があれば何とかなるという意識もしかり。
Comment by yenxing — 2006年7月29日 @ 00:04
ソフトウェア
■ 読み比べて、面白いと思った…
ITの常識は世間の非常識
「ソフトウェア開発」は「モノ作り」ではない
仙石浩明の日記にある「決め」の一言について…
＞問: 「ソフトウェア開発」が「モノ作り」でないなら、何??ab??
Comment by やの日記 — 2006年7月29日 @ 00:14
航空機開発では，所期の性能を下回ったり，納期が遅れたりした場合の違約金について契約でしっかり決められていますが，ソフトウェアの場合はどうなっているのでしょうか。
Comment by 通行人 — 2006年7月29日 @ 00:52
[開発]「ソフトウェア開発」は「モノ作り」ではない
http://blog.gcd.org/archives/50603640.html http://business.nikkeibp.co.jp/article/tech/20060623/104991/ まあいつもの奴ですね．今までも何度となく取り上げている． http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html 経営トップからす
Comment by カレーなる辛口Javaな転職日記 — 2006年7月29日 @ 01:09
ソフトウェア開発は設計である、という前提に一理あるかも知れません。その場合、クライアントが、そのように納得しているかどうか、が一番重要だと思います。
その上で、7.通りすがりさんの意見に賛成します。ボクの周囲にも、IT企業にソフトウェア開発を依頼して、追加追加で料金を請求され、SE業務自体に不信感を持ってる方が何人か居ます。ビジネスマンとしての仕事の進め方を知らないで、プログラムだけが書けても仕方がないと思います。
Comment by sisen — 2006年7月29日 @ 02:09
> 詐欺ですか？エンジニアより
> なんでもいいけど約束は守ろうよ。
なんかひどいメにあったみたいですね。気持ちはちょっとわかるつもりです。
肉体労働と違って人足・労働力集めても何の足しにもならない仕事です。建築士と一緒。設計重要。
なのに業界的には需要の方が圧倒的に多いので、仕方なく「５級建築士」的な人足をどうにか集めて、品質をごまかしつつ、どうにか案件を捌いている・・・そんな下請け会社を幾つも見てきました。
ひどいメに合わない為には、そいつらの技術力が本物かどうかを見分けられる眼を養うしかありません。すなわち、同じかそれ以上の技術力を自分で持っていないとムリかと思われます。
嫌だったら、もう自分で作るしかないですよ。実態は、金でどうにかなる世界じゃないと思います。
※イチ３０歳WEB
Comment by passerby — 2006年7月29日 @ 03:05
[言及]「ソフトウェア開発」はほんとうに「モノ作り」ではないのか？
http://blog.gcd.org/archives/50603640.html 問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ？ 答: 「設計」である。 自動車とソフトウェアを比較するなら、「自動車の設計図」が、「ソフトウェア」(より正確に言えばソースコード) に相当する。「自動車の製
Comment by honestaholicのめろんうま日記 — 2006年7月29日 @ 03:38
[仕事]「ソフトウェア開発」は「モノ作り」ではない
http://blog.gcd.org/archives/50603640.html なるほど。 ソフトウェアの開発はやはり、 設計というか研究というか芸術の域に近いわけで、 納期は過去の経験から予測するしかなく、 全く同じ作業の繰り返しは皆無であるのだから、 作ってみなければ正確には分からないという
Comment by いのくにの戯言 — 2006年7月29日 @ 03:54
なんでわざわざ自動車の例を持ち出すかなあ？しかも、「自動車と同程度に複雑なソフトウェア」だって。
「設計費」なんだから、安くないよ、って言いたいんだろうけど、ITが自動車産業ほどに高度に技術化されてるとでも、お思いですか？ちなみに、前にいた電子部品メーカーの設計は一人の人が１ヶ月に数製品の設計やってたよ。
熱機関・駆動系・流体力学・破壊力学、さまざまな学問・技術体系の上にさらに、安全性や低環境負荷を求めてABSやらハイブリッドエンジンやら、現代一般に普及しているものの中で、もっとも高度なモノをチョイスする感覚がどうもねぇ。
まあ、記事の中で車が引き合いに出されてるからなんだろうけどさ。
ITなんかを技術とは思ってないけど、そちらがそう思っているなら、もっと研究開発に力を入れたら？
それか、素直に未熟だって認めるか。
Comment by any — 2006年7月29日 @ 05:37
「ソフトウェア開発」は「モノ作り」ではない (2)
「「ソフトウェア開発」は「モノ作り」ではない」を
とても多くの方々に読んで頂けた。
コメント/トラックバックを頂いた方々、
はてなブックマーク して頂いた方々に
感謝申し上げる。
これだけ多くの方々に読んで頂くと、
誤解するかたも少なくないようだ。
….
Comment by 仙石浩明の日記 — 2006年7月29日 @ 07:54
パッケージソフトウェアの考察
ソフトウェア開発はもの作りではなく、設計だというはなし。
「ソフトウェア開発」は「モノ作り」ではない
自動車とソフトウェアを比較するなら、「自動車の設計図」が、「ソフトウェア」(より正確に言えばソースコード) に相当する。「自動車の製造」に相当するのは、ソ…
Comment by civic site — 2006年7月29日 @ 11:34
顧客が開発開始後に仕様変更や追加機能を要求してくる。
営業が無茶なスケジュールと予算で仕事を取ってくる。
などが無くなれば、ソフトウェアも予算内で期限内に完成すると思いますか？
Comment by DIY — 2006年7月29日 @ 12:13
高度な集団もあれば、どうしようもない集団も。
「アフリカ」といえば「草原地帯とライオン」しかないイメージな人もいるかと思いますが、近代的なビルだって建ってるわけで、ましてやライオン見たこと無い現地人もいるわけで。
自分が知ってる面で「ひと括り」してそれがすべてだという前提になって議論しても…ね (´・ω・｀)
Comment by 通りすがり — 2006年7月29日 @ 12:37
設計といっても、基盤となる学問体系もなければ設計者の技術標準もない。あくまで個人のスキルに頼り切った構造では、先が見えているのではないか？
実際にコード書く人がプログラミングや設計の基礎を知らずに、とりあえず就職したのでプログラミングの基礎だけ教えて、あとはOJTという姿勢がそもそもの間違いではなかろうか。
ルール無用でとりあえず動く代物を作ってパフォーマンスその他は見て見ぬ振りが、まわりまわって後から手を入れられなくなるスパゲッティとなり、その結果、後の人がデスマーチの悪循環。
いまだ成熟していない技術が社会の基盤を担うまでが、あまりに早すぎたのではないだろうか。
なんとなくそう思う。
Comment by 新入社員のとき開発にいました — 2006年7月29日 @ 13:04
参考までに。
「ソフトウェア設計とは何か？」
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
Comment by fujii — 2006年7月29日 @ 14:34
会社の誕生日とシステム（ソフトウェア）開発について
１年前の今日、うちの会社ができた。そう１歳の誕生日である。 SEOをメインとしつ…
Comment by Shoulder.jp — 2006年7月29日 @ 15:25
ITエンジニアの本質と、今後
複数のブログを読んでみて、
ITエンジニアとしての本質と今後について、
頭にあるものを掃き出してみようと思う。
ただし、まだ考えがまとまらないので、
抽象的なものになる。
Comment by D.I.'s Memorandum — 2006年7月29日 @ 15:45
13の人は読み違えてるようなきがします．
Comment by 通りすがり — 2006年7月29日 @ 16:01
> 少なくとも頼んだモノは作って下さい。
設計＝DESIGN です。
家や服を特注デザインで作る場合、顧客とデザイナーは設計書を見ながら打ち合わせますよね。
本当にこのデザインで良いのかと。
デザインしていないモノは出来上がりません。
出来上がったデザインを採用するのは顧客です。
頼んだモノが出来ない＝頼んだモノが設計されていない です。
設計されていない設計書にGOサインを出したのは顧客です。
設計を練り直すための時間、金、想像力が足りなかった場合、顧客と設計者どちらに責任があるのか。
ある画家に肖像画を描かせたのだが、肖像画が気に入らない。
そんな場合どちらに責任があるのか。
画家も顧客も権利・損害を主張するでしょう。
Comment by 慣習を変える必要があるのは確か。 — 2006年7月29日 @ 17:48
現実は製造コストが最も重視され、削れるところから削ろうと血眼になっている。
経営者は農場主みたいな自覚で、自分の事業がモノ作りかどうかすら興味がないのが本音。
設計図を見て報酬を決める経営者なんてまずいない。
成果主義では収益に直結したところから評価される。
設計図で購買意欲をかきたてるなんてことはまずないから、開発者はうだつがあがらない。
器械部品としたどこかの国家プロジェクトは失敗した。
ソフト開発はオーガニックな活動で、部品の組み立て方に著作権があるくらい創造的なもの。
設計図は機能しない。同じものはできない。
権威が技術者にあれば、経営側にも医者にかかるようなコスト認識が生まれたはず。
本当は治るかどうかわからない患者をこの時期までに治すと約束する、みたいなことを業界全体でやっている。しかも患者の言いなり。
工業の枠に入れた時点でソフトウェア産業の将来は絶たれたようなもの。
Comment by i — 2006年7月29日 @ 23:14
>頼んだモノが出来ない＝頼んだモノが設計されていない です。
いんや。ソフトウエア開発で、特に日本のソフトウエア開発で一番問題になるのは「頼んでいない」や「顧客自身が何が欲しいか分かっていない」です。美容院で「私の美しさを一番際だたせる髪型にしてちょうだい」で任せて、できた後で「私のイメージしていたのと違う！私はもっとキリッとしてふんわりとしてエレガントなのを期待してたのに！」と言って怒るようなもの。そんな曖昧な要求で期待したものが手に入るわけないでしょう？
頼んでもいないし、自分でも欲しいかどーかも良く分からん物を、作ってくれと言われて「ハイできます」と答える営業もどうかとは思うけど、そんな営業の口約束であっさり契約してしまう顧客企業の経営者もどうかしてる。
Comment by とおりすがり — 2006年7月30日 @ 01:35
成長する秘訣は、今の仕事を捨てて自分を変えること
ピーターの法則って知ってますか？
ウィキペディアから引用すると:
能力主義の階層社会に於いて、人間は能力の極限まで出世する。
すると有能な平構成員も無能な中間管理職になる。
時が経つに連れて人間は悉く出世していく。
無能な平構成員はそのまま平…
Comment by 仙石浩明CTO の日記 — 2006年8月2日 @ 08:31
この記事に書かれていることはまったくその通りで、コーディングの段階でも細微な部分の設計が行われているのです。
でも、ソフトウェアの開発はモノ作りでは何なのか言うとやはり開発であると思います。
ただし新製品の開発です。
どんな物を作れば良いかという要求定義から仕様定義、設計、試験、製造方法の構築まで含まれるでしょう。
ちょうどソフトウェア開発の最初から最後までです。
冒頭の完成しないソフトウェアの問題は新製品開発を自動車などのカスタマイズと同じ感覚で発注していることにあると思います。
だって色を変えたくらいで試験をやり直す必要はないでしょう？
家電製品のように組み立て後に試験をするものを例にとっても不具合が見つかればその製品を廃棄するだけ。製造工程の話ですから開発とは別物です。
なにか新製品の開発に関わったことのある方っていらっしゃいます？
Comment by ハッカ飴 — 2006年8月17日 @ 21:53
プログラマーではない人が、ソフトウェアの開発を、他の産業になぞらえて誤解を生じる可能性はありますね。
>問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ？
>答: 「設計」である。
ソフトウェア開発でコストが発生する要因を見誤らないためにも、重要な認識だと思いました。
＼(^o^)／
Comment by 浜村拓夫 — 2006年12月25日 @ 16:35
[システム開発]プログラマの生産性ってなんだ？
なんてことを漠然と考えていたら「仙石浩明の日記: 「ソフトウェア開発」は「モノ作り」ではない」なんてタイムリーな話題を見かけたので、少し考えをまとめてみました。 一般的に受託開発で適用される生産性とは、成果物（主にステップ数）÷開発工数（時間）で求められま
Comment by 坊やがゆく — 2007年3月9日 @ 20:52
ソフトウェア・クリエイション
昨日のエントリに、事前に設計を固めるなんてことはユーザーの意見を無視しかねず、危険であるという話に絡むことで、プログラミングに関しては、そもそも設計とコーディングを分けること自体が何かおかしいという話。 まずは、前川徹の「日本のソフトウェアに未来はあるか
Comment by VIVER日記 — 2007年4月22日 @ 19:19
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
ソフトウェア設計とは何か？
ソフトウェアを納品する直前までの過程は設計、という認識は正しいようです。
Comment by t98907 — 2007年6月11日 @ 12:26
（つづく）のほうにも書きましたが、
車などのハード製品の生産とソフトウェア製作が違うのは、
ソフトウェアには量産工程が無いという点だって事ですね。
製品の生産工程は
企画→研究→開発→量産→（アフターサービス、サポート）
という段階があります。
車などのハード製品の場合は、開発の段階までででモデル品を作り
量産工程でそのモデル品のコピーを大量生産します。
しかしソフトウェアだと、まったく同じものが欲しければ
単にコピーすればいいので量産工程がありません。
開発段階でモデルとなるモノが出来た時点で生産はほぼ終了です。
ソフトウェア開発は設計だ、というのもそういう意味でしょう。
Comment by ライドオン — 2007年6月20日 @ 11:30
ハード製品を効率的に量産するには、必要なパーツを必要なだけ仕入れ、
同じものを同じ品質で量産工程がよどみなく進むことが重要です。
たとえばTOYOTAのカンバン方式はその点で優れています。
しかしソフトウェアは量産工程が無い。
ハードの量産品のようなまったく同じものが欲しいならコピーで済むから。
パーツの仕入れ数について悩む必要も無い。パーツもコピーで済むから。
話は脱線気味ですが、この「量産工程が無い」という点が見えていないから、
ハードの”量産工程段階”で使っている工程管理手法をソフトウェアの”研究開発段階”に
持ち込もうとする発想も出てきてしまうのだと思われます。
もしソフトウェア製作でTOYOTAの手法を真似るとしたら、
量産段階で使っているカンバン方式ではなく
TOYOTAが研究・開発段階で使っている手法を真似るべきでしょう。
Comment by ライドオン — 2007年6月20日 @ 11:39
ソフトウェアが高度すぎるためバグ付きでもソフトウェアが出荷されます。(それでも重大なバグは残さないのが原則)
枯れた技術のみを使えば、バグは非常に少なくなりますが、顧客は陳腐な技術を使ったものは求めていません。
50年前の自動車も、現在の自動車も期待されている機能・性能はさほど変わりませんが、50年前のソフトウェアと現在のソフトウェアでは期待されている機能・性能が大きく違うと思います。
いずれ、自動車も高度な機能を求められるようになり同じ問題を抱えると思います。
Comment by ymikasa — 2007年9月6日 @ 19:18
システム開発の生産性
システム開発の生産性について考えてみました。と言っても生産性を数字で表わすとなると結構難しいですね。何を基準にすればよいのか・・・。ステップ数じゃないし、機能数でもないし、売上金額も違うし・・・。と言うわけで具体的な数字は置いとくことにします。WEB上で色..
Comment by ポケQ日記 — 2007年10月24日 @ 15:14
なんでシステム開発ってこんなに大変なんでしょうか？
ただでさえ仕事は忙しいのに、機能追加案件は待ってくれない。
疲れているときに限ってクリティカルな障害が発生するし。
システム開発に関わる人が疲弊してしまうのを何回も見て…
Comment by ジブログ — 2007年12月31日 @ 00:11
コーディングは設計フェーズ
ソフトウェア設計とは何か？
変わりつつあるソフトウェア開発の価値観1（「建築学」から「園芸学」へ） ．．．landscapist： 造園家、庭師っていい言葉だな。
変わりつつあるソフトウェ…
Comment by softya :2 — 2008年1月12日 @ 03:37
コーディングは設計フェーズ
ソースコードはドキュメント。しかも、テストできるドキュメント。他の設計書はテストできない。ソースコード(とそれを書く人も)をもっと大切にしたい。
「製造部分はインド・中国の..
Comment by softya :2 — 2008年1月12日 @ 03:42
うーん、困った事に我々が生きてる社会では日々環境が変化するのですよ。
そして、お客様の要求もそれに応じてへんかしてしまう。
注文するときに日産 マーチくださいといっておいて、受け取るときには、レクサス LFAじゃないから受け取れん
もし、自動車を買う人がそう言ったら、自動車会社では、どんな対応をするのでしょうね？
少なくても、レクサス LFAは提供できない、値段が違いすぎるのだから
ソフトウェア産業では、そう言う事が平然と行われます。
だから、掛かるコストが当然変わってしまう。
自動車でも、必要な機能などが変われば、掛かるコスト変わりますよね？
Comment by RHEA — 2010年4月16日 @ 02:07
「「ソフトウェア開発」は「モノ作り」ではない」というご主張に同意します。というか別段目新しい主張ではなく、むしろ海外では常識に近いんじゃないでしょうか？
しかし、批判的なコメント欄を読んでいると、人々の知識の低さに驚かされます。他の工業製品と比較してソフトウェアが本質的に複雑であることを理解していない無知者が多いんですね、この国は。もっと勉強して欲しいと思います。
チューリング賞学者ブルックス先生の「人月の神話」、ロバート・L・グラスの「ソフトウェアクリエイティビティ」などソフトウェアに関する良書は過去から現在までたくさんあるんですけどね。
Comment by 日本に絶望 — 2010年7月6日 @ 02:04
だいぶ時期がズレてるので、読んで貰えるでしょうかね・・・(–;
まぁ、とりあえず・・
主張されたい点については理解できます。
要は日経onlineの記事の比較対象がズレているのだと思います。
ただ、コメントを見る限り筆者例示の比較対象にも「？」がある様に思います。
自動車開発とソフトウェア開発を比するのなら
自社開発ソフトウェアに絞らなければ、
主張したい事の趣旨と議論がズレてくる様に思います。
（実際コメントでもその辺が混同している様ですし・・）
その意味においては、ソースコードは、設計ではなく
自動車のプロトタイプとかその辺ではないでしょうか？
どちらも設計の過程と設計書は存在するのでしょうし・・・
もし主張されている意図を読み違えている様でしたらご容赦下さい。
Comment by B — 2010年8月10日 @ 00:25
車の場合は注文する段階で現物が存在しますが、システムはそうではないので、いろいろむずかしいですねー。
Comment by turutosiya — 2010年12月2日 @ 12:57
この場合でお聞きする内容かどうか？分かりませんが。車のエンジンの設計図を制作する為の、ソフトウェアを探して居ます。教えて頂けませんか。
Comment by 臼井邦明 — 2011年5月27日 @ 09:37