「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。
日経ビジネス online の記事に次のようなくだりがあった:
「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」
IT業界は 100億円かけても使えるものが作れない非常識な世界、というわけである。 まあよく聞く批判で、そう言いたくなる気持ちも理解できるのであるが、 100億円が高いとする根拠がいただけない。 同じ記事中に続けてこういう話が出てくる:
「例えば、自動車を買うとします。 希望の車種と色調を言えば、その通りの車が期限通りに納車される。 万一、色が違っていればすぐ取り替えてくれるし、 その車が動かないなんてことはまずない。 欠陥があった場合、リコールがある。 しかし、コンピューターの場合、自動車ではありえないことが四六時中起きる。 経営トップとしては何とも理解し難いわけです」
つまり、ソフトウェア開発を自動車の製造と比較しているのである。 自動車は、「わずか」数百万円なのに「使える」製品が買える。 自動車と同程度に複雑なソフトウェアを開発しようと思ったら、 少なくとも数億円から数十億円はかかるだろうし、 数十億円かけたところで、 現在の工業製品としての自動車のレベルの品質は望むべくもない。
このような批判は、 「ソフトウェア」を「モノ」と同一視したためにおこる誤解が元となっている。 ソフトウェア開発という「家内制手工業」をせめて「工場制手工業」へ発展させ、 ゆくゆくは「機械制大工業」に進化させようという試みの多くも、 同様の誤解がベースになっているわけで、 「ソフトウェア開発」を「モノ作り」と見なす誤解は、 広く蔓延してしまっているのかもしれない。
問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ?
答: 「設計」である。
自動車とソフトウェアを比較するなら、 「自動車の設計図」が、 「ソフトウェア」(より正確に言えばソースコード) に相当する。 「自動車の製造」に相当するのは、 ソフトウェアを出荷するときに行なう「ビルド」「コピー」「パッケージング」 であろう。
「自動車の製造」には例えば一台あたり百万円を超えるようなコストがかかり、 1万台生産しようとすれば 100億円を超えるコストがかかる。 大量生産すればするほど「製造コスト」が支配的になるから忘れがちであるが、 自動車の設計にも結構なコストがかかっている。 設計図を引くコストだけでなく、その前提となる研究開発も必要だし、 エンジンや制御用コンピュータなどの部品の設計も含めれば、 ゼロから一台の車を設計するコストは、かなりの額 (よく分からないが数億円で済むとはとても思えない) になるだろう。 完全「特注」の自動車を設計してもらうとしたら、 いったいどのくらいかかるのだろう?
一方、ソフトウェアの開発においては、 「製造コスト」は無視できる。 1万本生産するとしても、パッケージングコストは 1 本あたりせいぜい数百円程度だろうから、数百万円程度で済んでしまう。 ダウンロード販売なら何万本生産 (つまりコピー) しても原価は 0 円である (もちろん、ダウンロード サイトの運用などには費用がかかるが、 それは原価ではなく「販管費」である)。
ソフトウェアの設計というと、 要件定義、外部仕様、詳細仕様、等々を作ることを指すことが多いのでややこしいが、 製造業においても、図面を引く前には仕様を詳細につめているはずなので、 自動車の設計図を書く工程を「設計」と呼ぶのであれば、 ソフトウェアのコーディングも「設計」と見なすべきだろう。 コーディングの「家内制手工業」ぶりを批判したいのであれば、 比較対象は設計図を書く工程であるべきであって、 組み立て工程ではない。 ソフトウェア開発の近代化は重要な課題であるが、 そのお手本を「機械制大工業」における「製造工程」に求めてしまっては、 大きく道を誤る。
(つづく)
トラックバックURL
この記事へのトラックバック
この記事へのコメント
マツダの本に書いてありました。
やっぱりソフトウエアのコーディングを「製造」と形容してるのは問題多すぎますね。上流から「設計1」「設計2」3,4,5〜みたいな感じのほうがまだ良いような。
言葉を言い換えてもあんま効果ないと思うんだけど。
ソフトウェア開発の手法を改善する唯一の方法は、われわれ技術者自身が成長することであり、成長するには、そもそもソフトウェア開発が何であるかを理解することが重要だと思うのです。
ところが、ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか、そういう話になりがちではありませんか?
いみじくも「ソフトウェア部品」という言葉が象徴しているように、他の工業製品の製造プロセスを模倣することによって効率化を試みているわけです。これでは効率化が達成できるわけはありません。そもそもソフトウェア開発は製造ではなく、むしろ製造業で言うところの設計に該当するからです。
ならば、同じ学ぶにしても、その対象は製造プロセスではなく、(製造業における) 設計プロセスということになるでしょう。
モノづくりの定義がはっきりしてないし。というかモノづくりって言葉は曖昧だからいろんな使われ方をするわけだろうけど。
>ソフトウェア開発の効率化というと、ソフトウェアのモジュール化だとか、プログラムの再利用性の向上だとか
そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの?
>ならば、同じ学ぶにしても、その対象は製造プロセスではなく、設計プロセスということになるでしょう。
なんか言いたいことは分かった。つーか普通に設計やってるやろ。効率考えて。そんなんしてない会社があるんか?思いつきだけで動いてしまうような。。。ITベンチャーではありがちだったw
SEはデザイン画を描き、PGは設計図を書く。
建築の設計に建築士の資格が必要なようにプログラマにも専門資格を作り、持っていない人は職業プログラムを禁止して欲しいと私は思っております。
>
> そりゃコストのほとんどが人件費なんだから、そういう発想は当たり前なんじゃないの?
その発想は当たり前と思えるだけで、でも実際はそれで効率を上げることは不可能、という主張だと思うけど。
> つーか普通に設計やってるやろ。効率考えて。そんなんしてない会社があるんか?
ほとんどの場合、効率考えて設計してる「つもり」になってるだけだと思うけど。
作ると言ったものが作れない、いくらでできると言ったものができない。納期を守ると約束したのに約束が破られる。
詐欺ですか?
なんでもいいけど約束は守ろうよ。
昔は属人性が高かったのでそう思いましたが。
近年は、チームでしか動かないので「周辺」つまり
・「サポートチーム」(PMOみたいなやつ。機能してないけど)
・「本」(最近はたくさん売ってる)
・「部門サーバ」のサポート(各部署単位で知識のある人がサーバをメンテしてる)
も、「コスト」に含めるべきな気がしてます。ということで「人件費」
の割合は低下していると思います。
組織的な「知恵」を集積して、必要なところに流すために必要な「金」もソフトウェア開発に必要だと思いますが。
そんなところに重点的にかけてるところがあるかどうかは知りませんが、、
ちなみに私がいるところは、ほとんどが人件費です。(苦笑)
人件費にも回ってない気がするけど。
最終的にソフトウェア開発の成否は「ユーザの意識」にあると思うんですね。最初にきちんと契約書作ることもしかり、ソフトウェア”だけ”があれば何とかなるという意識もしかり。
その上で、7.通りすがりさんの意見に賛成します。ボクの周囲にも、IT企業にソフトウェア開発を依頼して、追加追加で料金を請求され、SE業務自体に不信感を持ってる方が何人か居ます。ビジネスマンとしての仕事の進め方を知らないで、プログラムだけが書けても仕方がないと思います。
> なんでもいいけど約束は守ろうよ。
なんかひどいメにあったみたいですね。気持ちはちょっとわかるつもりです。
肉体労働と違って人足・労働力集めても何の足しにもならない仕事です。建築士と一緒。設計重要。
なのに業界的には需要の方が圧倒的に多いので、仕方なく「5級建築士」的な人足をどうにか集めて、品質をごまかしつつ、どうにか案件を捌いている・・・そんな下請け会社を幾つも見てきました。
ひどいメに合わない為には、そいつらの技術力が本物かどうかを見分けられる眼を養うしかありません。すなわち、同じかそれ以上の技術力を自分で持っていないとムリかと思われます。
嫌だったら、もう自分で作るしかないですよ。実態は、金でどうにかなる世界じゃないと思います。
※イチ30歳WEB
エンジニアより「設計費」なんだから、安くないよ、って言いたいんだろうけど、ITが自動車産業ほどに高度に技術化されてるとでも、お思いですか?ちなみに、前にいた電子部品メーカーの設計は一人の人が1ヶ月に数製品の設計やってたよ。
熱機関・駆動系・流体力学・破壊力学、さまざまな学問・技術体系の上にさらに、安全性や低環境負荷を求めてABSやらハイブリッドエンジンやら、現代一般に普及しているものの中で、もっとも高度なモノをチョイスする感覚がどうもねぇ。
まあ、記事の中で車が引き合いに出されてるからなんだろうけどさ。
ITなんかを技術とは思ってないけど、そちらがそう思っているなら、もっと研究開発に力を入れたら?
それか、素直に未熟だって認めるか。
営業が無茶なスケジュールと予算で仕事を取ってくる。
などが無くなれば、ソフトウェアも予算内で期限内に完成すると思いますか?
IT業界、IT技術者といってもピンからキリまでありますよ?高度な集団もあれば、どうしようもない集団も。
「アフリカ」といえば「草原地帯とライオン」しかないイメージな人もいるかと思いますが、近代的なビルだって建ってるわけで、ましてやライオン見たこと無い現地人もいるわけで。
自分が知ってる面で「ひと括り」してそれがすべてだという前提になって議論しても...ね (´・ω・`)
実際にコード書く人がプログラミングや設計の基礎を知らずに、とりあえず就職したのでプログラミングの基礎だけ教えて、あとはOJTという姿勢がそもそもの間違いではなかろうか。
ルール無用でとりあえず動く代物を作ってパフォーマンスその他は見て見ぬ振りが、まわりまわって後から手を入れられなくなるスパゲッティとなり、その結果、後の人がデスマーチの悪循環。
いまだ成熟していない技術が社会の基盤を担うまでが、あまりに早すぎたのではないだろうか。
なんとなくそう思う。
「ソフトウェア設計とは何か?」
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
設計=DESIGN です。
家や服を特注デザインで作る場合、顧客とデザイナーは設計書を見ながら打ち合わせますよね。
本当にこのデザインで良いのかと。
デザインしていないモノは出来上がりません。
出来上がったデザインを採用するのは顧客です。
頼んだモノが出来ない=頼んだモノが設計されていない です。
設計されていない設計書にGOサインを出したのは顧客です。
設計を練り直すための時間、金、想像力が足りなかった場合、顧客と設計者どちらに責任があるのか。
ある画家に肖像画を描かせたのだが、肖像画が気に入らない。
そんな場合どちらに責任があるのか。
画家も顧客も権利・損害を主張するでしょう。
経営者は農場主みたいな自覚で、自分の事業がモノ作りかどうかすら興味がないのが本音。
設計図を見て報酬を決める経営者なんてまずいない。
成果主義では収益に直結したところから評価される。
設計図で購買意欲をかきたてるなんてことはまずないから、開発者はうだつがあがらない。
器械部品としたどこかの国家プロジェクトは失敗した。
ソフト開発はオーガニックな活動で、部品の組み立て方に著作権があるくらい創造的なもの。
設計図は機能しない。同じものはできない。
権威が技術者にあれば、経営側にも医者にかかるようなコスト認識が生まれたはず。
本当は治るかどうかわからない患者をこの時期までに治すと約束する、みたいなことを業界全体でやっている。しかも患者の言いなり。
工業の枠に入れた時点でソフトウェア産業の将来は絶たれたようなもの。
いんや。ソフトウエア開発で、特に日本のソフトウエア開発で一番問題になるのは「頼んでいない」や「顧客自身が何が欲しいか分かっていない」です。美容院で「私の美しさを一番際だたせる髪型にしてちょうだい」で任せて、できた後で「私のイメージしていたのと違う!私はもっとキリッとしてふんわりとしてエレガントなのを期待してたのに!」と言って怒るようなもの。そんな曖昧な要求で期待したものが手に入るわけないでしょう?
頼んでもいないし、自分でも欲しいかどーかも良く分からん物を、作ってくれと言われて「ハイできます」と答える営業もどうかとは思うけど、そんな営業の口約束であっさり契約してしまう顧客企業の経営者もどうかしてる。
でも、ソフトウェアの開発はモノ作りでは何なのか言うとやはり開発であると思います。
ただし新製品の開発です。
どんな物を作れば良いかという要求定義から仕様定義、設計、試験、製造方法の構築まで含まれるでしょう。
ちょうどソフトウェア開発の最初から最後までです。
冒頭の完成しないソフトウェアの問題は新製品開発を自動車などのカスタマイズと同じ感覚で発注していることにあると思います。
だって色を変えたくらいで試験をやり直す必要はないでしょう?
家電製品のように組み立て後に試験をするものを例にとっても不具合が見つかればその製品を廃棄するだけ。製造工程の話ですから開発とは別物です。
なにか新製品の開発に関わったことのある方っていらっしゃいます?
>問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ?
>答: 「設計」である。
ソフトウェア開発でコストが発生する要因を見誤らないためにも、重要な認識だと思いました。
\(^o^)/
ソフトウェア設計とは何か?
ソフトウェアを納品する直前までの過程は設計、という認識は正しいようです。
車などのハード製品の生産とソフトウェア製作が違うのは、
ソフトウェアには量産工程が無いという点だって事ですね。
製品の生産工程は
企画→研究→開発→量産→(アフターサービス、サポート)
という段階があります。
車などのハード製品の場合は、開発の段階までででモデル品を作り
量産工程でそのモデル品のコピーを大量生産します。
しかしソフトウェアだと、まったく同じものが欲しければ
単にコピーすればいいので量産工程がありません。
開発段階でモデルとなるモノが出来た時点で生産はほぼ終了です。
ソフトウェア開発は設計だ、というのもそういう意味でしょう。
同じものを同じ品質で量産工程がよどみなく進むことが重要です。
たとえばTOYOTAのカンバン方式はその点で優れています。
しかしソフトウェアは量産工程が無い。
ハードの量産品のようなまったく同じものが欲しいならコピーで済むから。
パーツの仕入れ数について悩む必要も無い。パーツもコピーで済むから。
話は脱線気味ですが、この「量産工程が無い」という点が見えていないから、
ハードの"量産工程段階"で使っている工程管理手法をソフトウェアの"研究開発段階"に
持ち込もうとする発想も出てきてしまうのだと思われます。
もしソフトウェア製作でTOYOTAの手法を真似るとしたら、
量産段階で使っているカンバン方式ではなく
TOYOTAが研究・開発段階で使っている手法を真似るべきでしょう。
枯れた技術のみを使えば、バグは非常に少なくなりますが、顧客は陳腐な技術を使ったものは求めていません。
50年前の自動車も、現在の自動車も期待されている機能・性能はさほど変わりませんが、50年前のソフトウェアと現在のソフトウェアでは期待されている機能・性能が大きく違うと思います。
いずれ、自動車も高度な機能を求められるようになり同じ問題を抱えると思います。