このエントリーを含むブックマーク 2006年07月28日

「ソフトウェア開発」は「モノ作り」ではない

いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。

日経ビジネス online の記事に次のようなくだりがあった:

「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」

IT業界は 100億円かけても使えるものが作れない非常識な世界、というわけである。 まあよく聞く批判で、そう言いたくなる気持ちも理解できるのであるが、 100億円が高いとする根拠がいただけない。 同じ記事中に続けてこういう話が出てくる:

「例えば、自動車を買うとします。 希望の車種と色調を言えば、その通りの車が期限通りに納車される。 万一、色が違っていればすぐ取り替えてくれるし、 その車が動かないなんてことはまずない。 欠陥があった場合、リコールがある。 しかし、コンピューターの場合、自動車ではありえないことが四六時中起きる。 経営トップとしては何とも理解し難いわけです」

つまり、ソフトウェア開発を自動車の製造と比較しているのである。 自動車は、「わずか」数百万円なのに「使える」製品が買える。 自動車と同程度に複雑なソフトウェアを開発しようと思ったら、 少なくとも数億円から数十億円はかかるだろうし、 数十億円かけたところで、 現在の工業製品としての自動車のレベルの品質は望むべくもない。

このような批判は、 「ソフトウェア」を「モノ」と同一視したためにおこる誤解が元となっている。 ソフトウェア開発という「家内制手工業」をせめて「工場制手工業」へ発展させ、 ゆくゆくは「機械制大工業」に進化させようという試みの多くも、 同様の誤解がベースになっているわけで、 「ソフトウェア開発」を「モノ作り」と見なす誤解は、 広く蔓延してしまっているのかもしれない。

問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ?

答: 「設計」である。

自動車とソフトウェアを比較するなら、 「自動車の設計図」が、 「ソフトウェア」(より正確に言えばソースコード) に相当する。 「自動車の製造」に相当するのは、 ソフトウェアを出荷するときに行なう「ビルド」「コピー」「パッケージング」 であろう。

「自動車の製造」には例えば一台あたり百万円を超えるようなコストがかかり、 1万台生産しようとすれば 100億円を超えるコストがかかる。 大量生産すればするほど「製造コスト」が支配的になるから忘れがちであるが、 自動車の設計にも結構なコストがかかっている。 設計図を引くコストだけでなく、その前提となる研究開発も必要だし、 エンジンや制御用コンピュータなどの部品の設計も含めれば、 ゼロから一台の車を設計するコストは、かなりの額 (よく分からないが数億円で済むとはとても思えない) になるだろう。 完全「特注」の自動車を設計してもらうとしたら、 いったいどのくらいかかるのだろう?

一方、ソフトウェアの開発においては、 「製造コスト」は無視できる。 1万本生産するとしても、パッケージングコストは 1 本あたりせいぜい数百円程度だろうから、数百万円程度で済んでしまう。 ダウンロード販売なら何万本生産 (つまりコピー) しても原価は 0 円である (もちろん、ダウンロード サイトの運用などには費用がかかるが、 それは原価ではなく「販管費」である)。

ソフトウェアの設計というと、 要件定義、外部仕様、詳細仕様、等々を作ることを指すことが多いのでややこしいが、 製造業においても、図面を引く前には仕様を詳細につめているはずなので、 自動車の設計図を書く工程を「設計」と呼ぶのであれば、 ソフトウェアのコーディングも「設計」と見なすべきだろう。 コーディングの「家内制手工業」ぶりを批判したいのであれば、 比較対象は設計図を書く工程であるべきであって、 組み立て工程ではない。 ソフトウェア開発の近代化は重要な課題であるが、 そのお手本を「機械制大工業」における「製造工程」に求めてしまっては、 大きく道を誤る。

(つづく)



hiroaki_sengoku at 08:22 │Comments(27)TrackBack(16)技術と経営 

トラックバックURL

この記事へのトラックバック

1. 「ソフトウェア開発」は家を建てるのと同じ  [ Net-walker.jp ]   2006年07月28日 22:21
最近仕事でふつふつと自分が感じていることと同じことを考えている人が居た。 仙石浩...
2. ソフトウェア  [ やの日記 ]   2006年07月29日 00:14
■ 読み比べて、面白いと思った... ITの常識は世間の非常識 「ソフトウェア開発」は「モノ作り」ではない 仙石浩明の日記にある「決め」の一言について... >問: 「ソフトウェア開発」が「モノ作り」でないなら、何??ab??
3. [開発]「ソフトウェア開発」は「モノ作り」ではない  [ カレーなる辛口Javaな転職日記 ]   2006年07月29日 01:09
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 経営トップからす
4. [言及]「ソフトウェア開発」はほんとうに「モノ作り」ではないのか?  [ honestaholicのめろんうま日記 ]   2006年07月29日 03:38
http://blog.gcd.org/archives/50603640.html 問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ? 答: 「設計」である。 自動車とソフトウェアを比較するなら、「自動車の設計図」が、「ソフトウェア」(より正確に言えばソースコード) に相当する。「自動車の製
5. [仕事]「ソフトウェア開発」は「モノ作り」ではない  [ いのくにの戯言 ]   2006年07月29日 03:54
http://blog.gcd.org/archives/50603640.html なるほど。 ソフトウェアの開発はやはり、 設計というか研究というか芸術の域に近いわけで、 納期は過去の経験から予測するしかなく、 全く同じ作業の繰り返しは皆無であるのだから、 作ってみなければ正確には分からないという
6. 「ソフトウェア開発」は「モノ作り」ではない (2)  [ 仙石浩明の日記 ]   2006年07月29日 07:54
「「ソフトウェア開発」は「モノ作り」ではない」を とても多くの方々に読んで頂けた。 コメント/トラックバックを頂いた方々、 はてなブックマーク して頂いた方々に 感謝申し上げる。 これだけ多くの方々に読んで頂くと、 誤解するかたも少なくないようだ。 ....
7. パッケージソフトウェアの考察  [ civic site ]   2006年07月29日 11:34
ソフトウェア開発はもの作りではなく、設計だというはなし。 「ソフトウェア開発」は「モノ作り」ではない 自動車とソフトウェアを比較するなら、「自動車の設計図」が、「ソフトウェア」(より正確に言えばソースコード) に相当する。「自動車の製造」に相当するのは、ソ...
8. 会社の誕生日とシステム(ソフトウェア)開発について  [ Shoulder.jp ]   2006年07月29日 15:25
1年前の今日、うちの会社ができた。そう1歳の誕生日である。 SEOをメインとしつ...
9. ITエンジニアの本質と、今後  [ D.I.'s Memorandum ]   2006年07月29日 15:45
複数のブログを読んでみて、 ITエンジニアとしての本質と今後について、 頭にあるものを掃き出してみようと思う。 ただし、まだ考えがまとまらないので、 抽象的なものになる。
10. 成長する秘訣は、今の仕事を捨てて自分を変えること  [ 仙石浩明CTO の日記 ]   2006年08月02日 08:31
ピーターの法則って知ってますか? ウィキペディアから引用すると: 能力主義の階層社会に於いて、人間は能力の極限まで出世する。 すると有能な平構成員も無能な中間管理職になる。 時が経つに連れて人間は悉く出世していく。 無能な平構成員はそのまま平...
11. [システム開発]プログラマの生産性ってなんだ?  [ 坊やがゆく ]   2007年03月09日 20:52
なんてことを漠然と考えていたら「仙石浩明の日記: 「ソフトウェア開発」は「モノ作り」ではない」なんてタイムリーな話題を見かけたので、少し考えをまとめてみました。 一般的に受託開発で適用される生産性とは、成果物(主にステップ数)÷開発工数(時間)で求められま
12. ソフトウェア・クリエイション  [ VIVER日記 ]   2007年04月22日 19:19
昨日のエントリに、事前に設計を固めるなんてことはユーザーの意見を無視しかねず、危険であるという話に絡むことで、プログラミングに関しては、そもそも設計とコーディングを分けること自体が何かおかしいという話。 まずは、前川徹の「日本のソフトウェアに未来はあるか
13. システム開発の生産性  [ ポケQ日記 ]   2007年10月24日 15:14
システム開発の生産性について考えてみました。と言っても生産性を数字で表わすとなると結構難しいですね。何を基準にすればよいのか・・・。ステップ数じゃないし、機能数でもないし、売上金額も違うし・・・。と言うわけで具体的な数字は置いとくことにします。WEB上で色..
14. なんでシステム開発ってこんなに大変なんでしょうか?  [ ジブログ ]   2007年12月31日 00:11
ただでさえ仕事は忙しいのに、機能追加案件は待ってくれない。 疲れているときに限ってクリティカルな障害が発生するし。 システム開発に関わる人が疲弊してしまうのを何回も見て...
15. コーディングは設計フェーズ  [ softya :2 ]   2008年01月12日 03:37
ソフトウェア設計とは何か? 変わりつつあるソフトウェア開発の価値観1(「建築学」から「園芸学」へ) ...landscapist: 造園家、庭師っていい言葉だな。 変わりつつあるソフトウェ...
16. コーディングは設計フェーズ  [ softya :2 ]   2008年01月12日 03:42
ソースコードはドキュメント。しかも、テストできるドキュメント。他の設計書はテストできない。ソースコード(とそれを書く人も)をもっと大切にしたい。 「製造部分はインド・中国の..

この記事へのコメント

1. Posted by Shinpei3    2006年07月28日 09:10
ちなみに車の開発費は小型車の場合で3社共同開発でも一社800億円、自社で全部持ったら開発工数ももとより増えるので2000億円台では効かないそうです。
マツダの本に書いてありました。

やっぱりソフトウエアのコーディングを「製造」と形容してるのは問題多すぎますね。上流から「設計1」「設計2」3,4,5〜みたいな感じのほうがまだ良いような。
2. Posted by Bar    2006年07月28日 12:19
で「設計」だと、当初見積もられていたコスト内でできあがらないとか、そういうトラブルの言い訳がなんかできるんですか?

言葉を言い換えてもあんま効果ないと思うんだけど。
3. Posted by 仙石浩明    2006年07月28日 14:22
言い訳をするために「言い換え」をしようというのではありません。

ソフトウェア開発の手法を改善する唯一の方法は、われわれ技術者自身が成長することであり、成長するには、そもそもソフトウェア開発が何であるかを理解することが重要だと思うのです。

ところが、ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか、そういう話になりがちではありませんか?

いみじくも「ソフトウェア部品」という言葉が象徴しているように、他の工業製品の製造プロセスを模倣することによって効率化を試みているわけです。これでは効率化が達成できるわけはありません。そもそもソフトウェア開発は製造ではなく、むしろ製造業で言うところの設計に該当するからです。

ならば、同じ学ぶにしても、その対象は製造プロセスではなく、(製造業における) 設計プロセスということになるでしょう。
4. Posted by とおりすがり    2006年07月28日 15:22
見出しに騙されたなあ。
モノづくりの定義がはっきりしてないし。というかモノづくりって言葉は曖昧だからいろんな使われ方をするわけだろうけど。

>ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか

そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの?

>ならば、同じ学ぶにしても、その対象は製造プロセスではなく、設計プロセスということになるでしょう。
なんか言いたいことは分かった。つーか普通に設計やってるやろ。効率考えて。そんなんしてない会社があるんか?思いつきだけで動いてしまうような。。。ITベンチャーではありがちだったw
5. Posted by 村人A    2006年07月28日 16:06
4 同意です。
SEはデザイン画を描き、PGは設計図を書く。
建築の設計に建築士の資格が必要なようにプログラマにも専門資格を作り、持っていない人は職業プログラムを禁止して欲しいと私は思っております。
6. Posted by anonymous    2006年07月28日 17:56
> > ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか
>
> そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの?

その発想は当たり前と思えるだけで、でも実際はそれで効率を上げることは不可能、という主張だと思うけど。

> つーか普通に設計やってるやろ。効率考えて。そんなんしてない会社があるんか?

ほとんどの場合、効率考えて設計してる「つもり」になってるだけだと思うけど。
7. Posted by 通りすがり    2006年07月28日 21:41
2 モノでも設計でもサービスでもなんでもいいけど、少なくとも頼んだモノは作って下さい。お金を決めて、それで作ると言ったモノは作って下さい。

作ると言ったものが作れない、いくらでできると言ったものができない。納期を守ると約束したのに約束が破られる。

詐欺ですか?
なんでもいいけど約束は守ろうよ。
8. Posted by 加納正和    2006年07月29日 00:01
>そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの?

昔は属人性が高かったのでそう思いましたが。
近年は、チームでしか動かないので「周辺」つまり
・「サポートチーム」(PMOみたいなやつ。機能してないけど)
・「本」(最近はたくさん売ってる)
・「部門サーバ」のサポート(各部署単位で知識のある人がサーバをメンテしてる)

も、「コスト」に含めるべきな気がしてます。ということで「人件費」
の割合は低下していると思います。

組織的な「知恵」を集積して、必要なところに流すために必要な「金」もソフトウェア開発に必要だと思いますが。

そんなところに重点的にかけてるところがあるかどうかは知りませんが、、
ちなみに私がいるところは、ほとんどが人件費です。(苦笑)

人件費にも回ってない気がするけど。
9. Posted by yenxing    2006年07月29日 00:04
5 約束は守りたくても、日本の商慣習は、実際のところ正式には約束したことにはならないんだよね。だって契約書作るのってしてないことも多いし。だからユーザは「頼んだもの」を明確にしないとだめですね。
最終的にソフトウェア開発の成否は「ユーザの意識」にあると思うんですね。最初にきちんと契約書作ることもしかり、ソフトウェア”だけ”があれば何とかなるという意識もしかり。
10. Posted by 通行人    2006年07月29日 00:52
航空機開発では,所期の性能を下回ったり,納期が遅れたりした場合の違約金について契約でしっかり決められていますが,ソフトウェアの場合はどうなっているのでしょうか。
11. Posted by sisen    2006年07月29日 02:09
ソフトウェア開発は設計である、という前提に一理あるかも知れません。その場合、クライアントが、そのように納得しているかどうか、が一番重要だと思います。
その上で、7.通りすがりさんの意見に賛成します。ボクの周囲にも、IT企業にソフトウェア開発を依頼して、追加追加で料金を請求され、SE業務自体に不信感を持ってる方が何人か居ます。ビジネスマンとしての仕事の進め方を知らないで、プログラムだけが書けても仕方がないと思います。
12. Posted by passerby    2006年07月29日 03:05
> 詐欺ですか?
> なんでもいいけど約束は守ろうよ。

なんかひどいメにあったみたいですね。気持ちはちょっとわかるつもりです。
肉体労働と違って人足・労働力集めても何の足しにもならない仕事です。建築士と一緒。設計重要。
なのに業界的には需要の方が圧倒的に多いので、仕方なく「5級建築士」的な人足をどうにか集めて、品質をごまかしつつ、どうにか案件を捌いている・・・そんな下請け会社を幾つも見てきました。

ひどいメに合わない為には、そいつらの技術力が本物かどうかを見分けられる眼を養うしかありません。すなわち、同じかそれ以上の技術力を自分で持っていないとムリかと思われます。

嫌だったら、もう自分で作るしかないですよ。実態は、金でどうにかなる世界じゃないと思います。

※イチ30歳WEBエンジニアより
13. Posted by any    2006年07月29日 05:37
なんでわざわざ自動車の例を持ち出すかなあ?しかも、「自動車と同程度に複雑なソフトウェア」だって。
「設計費」なんだから、安くないよ、って言いたいんだろうけど、ITが自動車産業ほどに高度に技術化されてるとでも、お思いですか?ちなみに、前にいた電子部品メーカーの設計は一人の人が1ヶ月に数製品の設計やってたよ。
熱機関・駆動系・流体力学・破壊力学、さまざまな学問・技術体系の上にさらに、安全性や低環境負荷を求めてABSやらハイブリッドエンジンやら、現代一般に普及しているものの中で、もっとも高度なモノをチョイスする感覚がどうもねぇ。
まあ、記事の中で車が引き合いに出されてるからなんだろうけどさ。

ITなんかを技術とは思ってないけど、そちらがそう思っているなら、もっと研究開発に力を入れたら?
それか、素直に未熟だって認めるか。
14. Posted by DIY    2006年07月29日 12:13
顧客が開発開始後に仕様変更や追加機能を要求してくる。
営業が無茶なスケジュールと予算で仕事を取ってくる。

などが無くなれば、ソフトウェアも予算内で期限内に完成すると思いますか?
15. Posted by 通りすがり    2006年07月29日 12:37
IT業界、IT技術者といってもピンからキリまでありますよ?
高度な集団もあれば、どうしようもない集団も。
「アフリカ」といえば「草原地帯とライオン」しかないイメージな人もいるかと思いますが、近代的なビルだって建ってるわけで、ましてやライオン見たこと無い現地人もいるわけで。
自分が知ってる面で「ひと括り」してそれがすべてだという前提になって議論しても...ね (´・ω・`)
16. Posted by 新入社員のとき開発にいました    2006年07月29日 13:04
設計といっても、基盤となる学問体系もなければ設計者の技術標準もない。あくまで個人のスキルに頼り切った構造では、先が見えているのではないか?
実際にコード書く人がプログラミングや設計の基礎を知らずに、とりあえず就職したのでプログラミングの基礎だけ教えて、あとはOJTという姿勢がそもそもの間違いではなかろうか。
ルール無用でとりあえず動く代物を作ってパフォーマンスその他は見て見ぬ振りが、まわりまわって後から手を入れられなくなるスパゲッティとなり、その結果、後の人がデスマーチの悪循環。
いまだ成熟していない技術が社会の基盤を担うまでが、あまりに早すぎたのではないだろうか。
なんとなくそう思う。
17. Posted by fujii    2006年07月29日 14:34
参考までに。
「ソフトウェア設計とは何か?」
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

18. Posted by 通りすがり    2006年07月29日 16:01
13の人は読み違えてるようなきがします.
19. Posted by 慣習を変える必要があるのは確か。    2006年07月29日 17:48
3 > 少なくとも頼んだモノは作って下さい。

設計=DESIGN です。
家や服を特注デザインで作る場合、顧客とデザイナーは設計書を見ながら打ち合わせますよね。
本当にこのデザインで良いのかと。
デザインしていないモノは出来上がりません。
出来上がったデザインを採用するのは顧客です。

頼んだモノが出来ない=頼んだモノが設計されていない です。
設計されていない設計書にGOサインを出したのは顧客です。
設計を練り直すための時間、金、想像力が足りなかった場合、顧客と設計者どちらに責任があるのか。

ある画家に肖像画を描かせたのだが、肖像画が気に入らない。
そんな場合どちらに責任があるのか。
画家も顧客も権利・損害を主張するでしょう。

20. Posted by i    2006年07月29日 23:14
2 現実は製造コストが最も重視され、削れるところから削ろうと血眼になっている。
経営者は農場主みたいな自覚で、自分の事業がモノ作りかどうかすら興味がないのが本音。

設計図を見て報酬を決める経営者なんてまずいない。
成果主義では収益に直結したところから評価される。
設計図で購買意欲をかきたてるなんてことはまずないから、開発者はうだつがあがらない。

器械部品としたどこかの国家プロジェクトは失敗した。
ソフト開発はオーガニックな活動で、部品の組み立て方に著作権があるくらい創造的なもの。
設計図は機能しない。同じものはできない。

権威が技術者にあれば、経営側にも医者にかかるようなコスト認識が生まれたはず。
本当は治るかどうかわからない患者をこの時期までに治すと約束する、みたいなことを業界全体でやっている。しかも患者の言いなり。
工業の枠に入れた時点でソフトウェア産業の将来は絶たれたようなもの。
21. Posted by とおりすがり    2006年07月30日 01:35
>頼んだモノが出来ない=頼んだモノが設計されていない です。

いんや。ソフトウエア開発で、特に日本のソフトウエア開発で一番問題になるのは「頼んでいない」や「顧客自身が何が欲しいか分かっていない」です。美容院で「私の美しさを一番際だたせる髪型にしてちょうだい」で任せて、できた後で「私のイメージしていたのと違う!私はもっとキリッとしてふんわりとしてエレガントなのを期待してたのに!」と言って怒るようなもの。そんな曖昧な要求で期待したものが手に入るわけないでしょう?

頼んでもいないし、自分でも欲しいかどーかも良く分からん物を、作ってくれと言われて「ハイできます」と答える営業もどうかとは思うけど、そんな営業の口約束であっさり契約してしまう顧客企業の経営者もどうかしてる。
22. Posted by ハッカ飴    2006年08月17日 21:53
5 この記事に書かれていることはまったくその通りで、コーディングの段階でも細微な部分の設計が行われているのです。

でも、ソフトウェアの開発はモノ作りでは何なのか言うとやはり開発であると思います。
ただし新製品の開発です。
どんな物を作れば良いかという要求定義から仕様定義、設計、試験、製造方法の構築まで含まれるでしょう。
ちょうどソフトウェア開発の最初から最後までです。

冒頭の完成しないソフトウェアの問題は新製品開発を自動車などのカスタマイズと同じ感覚で発注していることにあると思います。
だって色を変えたくらいで試験をやり直す必要はないでしょう?
家電製品のように組み立て後に試験をするものを例にとっても不具合が見つかればその製品を廃棄するだけ。製造工程の話ですから開発とは別物です。

なにか新製品の開発に関わったことのある方っていらっしゃいます?
23. Posted by 浜村拓夫    2006年12月25日 16:35
5 プログラマーではない人が、ソフトウェアの開発を、他の産業になぞらえて誤解を生じる可能性はありますね。

>問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ?
>答: 「設計」である。

ソフトウェア開発でコストが発生する要因を見誤らないためにも、重要な認識だと思いました。
\(^o^)/
24. Posted by t98907    2007年06月11日 12:26
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
ソフトウェア設計とは何か?

ソフトウェアを納品する直前までの過程は設計、という認識は正しいようです。
25. Posted by ライドオン    2007年06月20日 11:30
(つづく)のほうにも書きましたが、
車などのハード製品の生産とソフトウェア製作が違うのは、
ソフトウェアには量産工程が無いという点だって事ですね。

製品の生産工程は

企画→研究→開発→量産→(アフターサービス、サポート)

という段階があります。

車などのハード製品の場合は、開発の段階までででモデル品を作り
量産工程でそのモデル品のコピーを大量生産します。

しかしソフトウェアだと、まったく同じものが欲しければ
単にコピーすればいいので量産工程がありません。
開発段階でモデルとなるモノが出来た時点で生産はほぼ終了です。
ソフトウェア開発は設計だ、というのもそういう意味でしょう。
26. Posted by ライドオン    2007年06月20日 11:39
ハード製品を効率的に量産するには、必要なパーツを必要なだけ仕入れ、
同じものを同じ品質で量産工程がよどみなく進むことが重要です。
たとえばTOYOTAのカンバン方式はその点で優れています。
しかしソフトウェアは量産工程が無い。
ハードの量産品のようなまったく同じものが欲しいならコピーで済むから。
パーツの仕入れ数について悩む必要も無い。パーツもコピーで済むから。

話は脱線気味ですが、この「量産工程が無い」という点が見えていないから、
ハードの"量産工程段階"で使っている工程管理手法をソフトウェアの"研究開発段階"に
持ち込もうとする発想も出てきてしまうのだと思われます。

もしソフトウェア製作でTOYOTAの手法を真似るとしたら、
量産段階で使っているカンバン方式ではなく
TOYOTAが研究・開発段階で使っている手法を真似るべきでしょう。
27. Posted by ymikasa    2007年09月06日 19:18
ソフトウェアが高度すぎるためバグ付きでもソフトウェアが出荷されます。(それでも重大なバグは残さないのが原則)
枯れた技術のみを使えば、バグは非常に少なくなりますが、顧客は陳腐な技術を使ったものは求めていません。
50年前の自動車も、現在の自動車も期待されている機能・性能はさほど変わりませんが、50年前のソフトウェアと現在のソフトウェアでは期待されている機能・性能が大きく違うと思います。
いずれ、自動車も高度な機能を求められるようになり同じ問題を抱えると思います。

この記事にコメントする

名前:
URL:
  情報を記憶: 評価: 顔   
  emoji panel