「ソフトウェア開発」は「モノ作り」ではない へのコメント http://www.gcd.org/blog/2006/07/91/ CTO兼プログラマ兼システム管理者の視点から Tue, 16 Feb 2010 17:40:39 +0000 http://wordpress.org/?v=2.9.2 hourly 1 softya :2 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-128 softya :2 Fri, 11 Jan 2008 18:42:47 +0000 http://www.gcd.org/blog/2006/07/91/#comment-128 <strong>コーディングは設計フェーズ</strong> ソースコードはドキュメント。しかも、テストできるドキュメント。他の設計書はテストできない。ソースコード(とそれを書く人も)をもっと大切にしたい。 「製造部分はインド・中国の.. コーディングは設計フェーズ

ソースコードはドキュメント。しかも、テストできるドキュメント。他の設計書はテストできない。ソースコード(とそれを書く人も)をもっと大切にしたい。
「製造部分はインド・中国の..

]]> softya :2 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-127 softya :2 Fri, 11 Jan 2008 18:37:35 +0000 http://www.gcd.org/blog/2006/07/91/#comment-127 <strong>コーディングは設計フェーズ</strong> ソフトウェア設計とは何か？ 変わりつつあるソフトウェア開発の価値観1（「建築学」から「園芸学」へ）　．．．landscapist： 造園家、庭師っていい言葉だな。 変わりつつあるソフトウェ... コーディングは設計フェーズ

ソフトウェア設計とは何か？
変わりつつあるソフトウェア開発の価値観1（「建築学」から「園芸学」へ）　．．．landscapist： 造園家、庭師っていい言葉だな。
変わりつつあるソフトウェ…

]]> ジブログ より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-126 ジブログ Sun, 30 Dec 2007 15:11:46 +0000 http://www.gcd.org/blog/2006/07/91/#comment-126 <strong>なんでシステム開発ってこんなに大変なんでしょうか？</strong> ただでさえ仕事は忙しいのに、機能追加案件は待ってくれない。 疲れているときに限ってクリティカルな障害が発生するし。 システム開発に関わる人が疲弊してしまうのを何回も見て... なんでシステム開発ってこんなに大変なんでしょうか？

ただでさえ仕事は忙しいのに、機能追加案件は待ってくれない。
疲れているときに限ってクリティカルな障害が発生するし。
システム開発に関わる人が疲弊してしまうのを何回も見て…

]]> ポケQ日記 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-125 ポケQ日記 Wed, 24 Oct 2007 06:14:53 +0000 http://www.gcd.org/blog/2006/07/91/#comment-125 <strong>システム開発の生産性</strong> システム開発の生産性について考えてみました。と言っても生産性を数字で表わすとなると結構難しいですね。何を基準にすればよいのか・・・。ステップ数じゃないし、機能数でもないし、売上金額も違うし・・・。と言うわけで具体的な数字は置いとくことにします。WEB上で色.. システム開発の生産性

システム開発の生産性について考えてみました。と言っても生産性を数字で表わすとなると結構難しいですね。何を基準にすればよいのか・・・。ステップ数じゃないし、機能数でもないし、売上金額も違うし・・・。と言うわけで具体的な数字は置いとくことにします。WEB上で色..

]]> ymikasa より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-112 ymikasa Thu, 06 Sep 2007 10:18:19 +0000 http://www.gcd.org/blog/2006/07/91/#comment-112 ソフトウェアが高度すぎるためバグ付きでもソフトウェアが出荷されます。(それでも重大なバグは残さないのが原則) 枯れた技術のみを使えば、バグは非常に少なくなりますが、顧客は陳腐な技術を使ったものは求めていません。 50年前の自動車も、現在の自動車も期待されている機能・性能はさほど変わりませんが、50年前のソフトウェアと現在のソフトウェアでは期待されている機能・性能が大きく違うと思います。 いずれ、自動車も高度な機能を求められるようになり同じ問題を抱えると思います。 ソフトウェアが高度すぎるためバグ付きでもソフトウェアが出荷されます。(それでも重大なバグは残さないのが原則)
枯れた技術のみを使えば、バグは非常に少なくなりますが、顧客は陳腐な技術を使ったものは求めていません。
50年前の自動車も、現在の自動車も期待されている機能・性能はさほど変わりませんが、50年前のソフトウェアと現在のソフトウェアでは期待されている機能・性能が大きく違うと思います。
いずれ、自動車も高度な機能を求められるようになり同じ問題を抱えると思います。

]]> ライドオン より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-111 ライドオン Wed, 20 Jun 2007 02:39:37 +0000 http://www.gcd.org/blog/2006/07/91/#comment-111 ハード製品を効率的に量産するには、必要なパーツを必要なだけ仕入れ、 同じものを同じ品質で量産工程がよどみなく進むことが重要です。 たとえばTOYOTAのカンバン方式はその点で優れています。 しかしソフトウェアは量産工程が無い。 ハードの量産品のようなまったく同じものが欲しいならコピーで済むから。 パーツの仕入れ数について悩む必要も無い。パーツもコピーで済むから。 話は脱線気味ですが、この「量産工程が無い」という点が見えていないから、 ハードの"量産工程段階"で使っている工程管理手法をソフトウェアの"研究開発段階"に 持ち込もうとする発想も出てきてしまうのだと思われます。 もしソフトウェア製作でTOYOTAの手法を真似るとしたら、 量産段階で使っているカンバン方式ではなく TOYOTAが研究・開発段階で使っている手法を真似るべきでしょう。 ハード製品を効率的に量産するには、必要なパーツを必要なだけ仕入れ、
同じものを同じ品質で量産工程がよどみなく進むことが重要です。
たとえばTOYOTAのカンバン方式はその点で優れています。
しかしソフトウェアは量産工程が無い。
ハードの量産品のようなまったく同じものが欲しいならコピーで済むから。
パーツの仕入れ数について悩む必要も無い。パーツもコピーで済むから。
話は脱線気味ですが、この「量産工程が無い」という点が見えていないから、
ハードの”量産工程段階”で使っている工程管理手法をソフトウェアの”研究開発段階”に
持ち込もうとする発想も出てきてしまうのだと思われます。
もしソフトウェア製作でTOYOTAの手法を真似るとしたら、
量産段階で使っているカンバン方式ではなく
TOYOTAが研究・開発段階で使っている手法を真似るべきでしょう。

]]> ライドオン より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-110 ライドオン Wed, 20 Jun 2007 02:30:21 +0000 http://www.gcd.org/blog/2006/07/91/#comment-110 （つづく）のほうにも書きましたが、 車などのハード製品の生産とソフトウェア製作が違うのは、 ソフトウェアには量産工程が無いという点だって事ですね。 製品の生産工程は 企画→研究→開発→量産→（アフターサービス、サポート） という段階があります。 車などのハード製品の場合は、開発の段階までででモデル品を作り 量産工程でそのモデル品のコピーを大量生産します。 しかしソフトウェアだと、まったく同じものが欲しければ 単にコピーすればいいので量産工程がありません。 開発段階でモデルとなるモノが出来た時点で生産はほぼ終了です。 ソフトウェア開発は設計だ、というのもそういう意味でしょう。 （つづく）のほうにも書きましたが、
車などのハード製品の生産とソフトウェア製作が違うのは、
ソフトウェアには量産工程が無いという点だって事ですね。
製品の生産工程は
企画→研究→開発→量産→（アフターサービス、サポート）
という段階があります。
車などのハード製品の場合は、開発の段階までででモデル品を作り
量産工程でそのモデル品のコピーを大量生産します。
しかしソフトウェアだと、まったく同じものが欲しければ
単にコピーすればいいので量産工程がありません。
開発段階でモデルとなるモノが出来た時点で生産はほぼ終了です。
ソフトウェア開発は設計だ、というのもそういう意味でしょう。

]]> t98907 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-109 t98907 Mon, 11 Jun 2007 03:26:31 +0000 http://www.gcd.org/blog/2006/07/91/#comment-109 http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html ソフトウェア設計とは何か？ ソフトウェアを納品する直前までの過程は設計、という認識は正しいようです。 http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
ソフトウェア設計とは何か？
ソフトウェアを納品する直前までの過程は設計、という認識は正しいようです。

]]> VIVER日記 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-124 VIVER日記 Sun, 22 Apr 2007 10:19:15 +0000 http://www.gcd.org/blog/2006/07/91/#comment-124 <strong>ソフトウェア・クリエイション</strong> 昨日のエントリに、事前に設計を固めるなんてことはユーザーの意見を無視しかねず、危険であるという話に絡むことで、プログラミングに関しては、そもそも設計とコーディングを分けること自体が何かおかしいという話。 まずは、前川徹の「日本のソフトウェアに未来はあるか ソフトウェア・クリエイション

昨日のエントリに、事前に設計を固めるなんてことはユーザーの意見を無視しかねず、危険であるという話に絡むことで、プログラミングに関しては、そもそも設計とコーディングを分けること自体が何かおかしいという話。 まずは、前川徹の「日本のソフトウェアに未来はあるか

]]> 坊やがゆく より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-123 坊やがゆく Fri, 09 Mar 2007 11:52:51 +0000 http://www.gcd.org/blog/2006/07/91/#comment-123 <strong>[システム開発]プログラマの生産性ってなんだ？</strong> なんてことを漠然と考えていたら「仙石浩明の日記: 「ソフトウェア開発」は「モノ作り」ではない」なんてタイムリーな話題を見かけたので、少し考えをまとめてみました。 一般的に受託開発で適用される生産性とは、成果物（主にステップ数）÷開発工数（時間）で求められま [システム開発]プログラマの生産性ってなんだ？

なんてことを漠然と考えていたら「仙石浩明の日記: 「ソフトウェア開発」は「モノ作り」ではない」なんてタイムリーな話題を見かけたので、少し考えをまとめてみました。 一般的に受託開発で適用される生産性とは、成果物（主にステップ数）÷開発工数（時間）で求められま

]]> 浜村拓夫 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-108 浜村拓夫 Mon, 25 Dec 2006 07:35:36 +0000 http://www.gcd.org/blog/2006/07/91/#comment-108 プログラマーではない人が、ソフトウェアの開発を、他の産業になぞらえて誤解を生じる可能性はありますね。 >問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ？ >答: 「設計」である。 ソフトウェア開発でコストが発生する要因を見誤らないためにも、重要な認識だと思いました。 ＼(^o^)／ プログラマーではない人が、ソフトウェアの開発を、他の産業になぞらえて誤解を生じる可能性はありますね。
>問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ？
>答: 「設計」である。
ソフトウェア開発でコストが発生する要因を見誤らないためにも、重要な認識だと思いました。
＼(^o^)／

]]> ハッカ飴 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-107 ハッカ飴 Thu, 17 Aug 2006 12:53:51 +0000 http://www.gcd.org/blog/2006/07/91/#comment-107 この記事に書かれていることはまったくその通りで、コーディングの段階でも細微な部分の設計が行われているのです。 でも、ソフトウェアの開発はモノ作りでは何なのか言うとやはり開発であると思います。 ただし新製品の開発です。 どんな物を作れば良いかという要求定義から仕様定義、設計、試験、製造方法の構築まで含まれるでしょう。 ちょうどソフトウェア開発の最初から最後までです。 冒頭の完成しないソフトウェアの問題は新製品開発を自動車などのカスタマイズと同じ感覚で発注していることにあると思います。 だって色を変えたくらいで試験をやり直す必要はないでしょう？ 家電製品のように組み立て後に試験をするものを例にとっても不具合が見つかればその製品を廃棄するだけ。製造工程の話ですから開発とは別物です。 なにか新製品の開発に関わったことのある方っていらっしゃいます？ この記事に書かれていることはまったくその通りで、コーディングの段階でも細微な部分の設計が行われているのです。
でも、ソフトウェアの開発はモノ作りでは何なのか言うとやはり開発であると思います。
ただし新製品の開発です。
どんな物を作れば良いかという要求定義から仕様定義、設計、試験、製造方法の構築まで含まれるでしょう。
ちょうどソフトウェア開発の最初から最後までです。
冒頭の完成しないソフトウェアの問題は新製品開発を自動車などのカスタマイズと同じ感覚で発注していることにあると思います。
だって色を変えたくらいで試験をやり直す必要はないでしょう？
家電製品のように組み立て後に試験をするものを例にとっても不具合が見つかればその製品を廃棄するだけ。製造工程の話ですから開発とは別物です。
なにか新製品の開発に関わったことのある方っていらっしゃいます？

]]> 仙石浩明CTO の日記 より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-122 仙石浩明CTO の日記 Tue, 01 Aug 2006 23:31:40 +0000 http://www.gcd.org/blog/2006/07/91/#comment-122 <strong>成長する秘訣は、今の仕事を捨てて自分を変えること</strong> ピーターの法則って知ってますか？ ウィキペディアから引用すると: 能力主義の階層社会に於いて、人間は能力の極限まで出世する。 すると有能な平構成員も無能な中間管理職になる。 時が経つに連れて人間は悉く出世していく。 無能な平構成員はそのまま平... 成長する秘訣は、今の仕事を捨てて自分を変えること

ピーターの法則って知ってますか？
ウィキペディアから引用すると:
能力主義の階層社会に於いて、人間は能力の極限まで出世する。
すると有能な平構成員も無能な中間管理職になる。
時が経つに連れて人間は悉く出世していく。
無能な平構成員はそのまま平…

]]> とおりすがり より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-106 とおりすがり Sat, 29 Jul 2006 16:35:36 +0000 http://www.gcd.org/blog/2006/07/91/#comment-106 >頼んだモノが出来ない＝頼んだモノが設計されていない　です。 いんや。ソフトウエア開発で、特に日本のソフトウエア開発で一番問題になるのは「頼んでいない」や「顧客自身が何が欲しいか分かっていない」です。美容院で「私の美しさを一番際だたせる髪型にしてちょうだい」で任せて、できた後で「私のイメージしていたのと違う！私はもっとキリッとしてふんわりとしてエレガントなのを期待してたのに！」と言って怒るようなもの。そんな曖昧な要求で期待したものが手に入るわけないでしょう？ 頼んでもいないし、自分でも欲しいかどーかも良く分からん物を、作ってくれと言われて「ハイできます」と答える営業もどうかとは思うけど、そんな営業の口約束であっさり契約してしまう顧客企業の経営者もどうかしてる。 >頼んだモノが出来ない＝頼んだモノが設計されていない　です。
いんや。ソフトウエア開発で、特に日本のソフトウエア開発で一番問題になるのは「頼んでいない」や「顧客自身が何が欲しいか分かっていない」です。美容院で「私の美しさを一番際だたせる髪型にしてちょうだい」で任せて、できた後で「私のイメージしていたのと違う！私はもっとキリッとしてふんわりとしてエレガントなのを期待してたのに！」と言って怒るようなもの。そんな曖昧な要求で期待したものが手に入るわけないでしょう？
頼んでもいないし、自分でも欲しいかどーかも良く分からん物を、作ってくれと言われて「ハイできます」と答える営業もどうかとは思うけど、そんな営業の口約束であっさり契約してしまう顧客企業の経営者もどうかしてる。

]]> i より http://www.gcd.org/blog/2006/07/91/comment-page-1/#comment-105 i Sat, 29 Jul 2006 14:14:00 +0000 http://www.gcd.org/blog/2006/07/91/#comment-105 現実は製造コストが最も重視され、削れるところから削ろうと血眼になっている。 経営者は農場主みたいな自覚で、自分の事業がモノ作りかどうかすら興味がないのが本音。 設計図を見て報酬を決める経営者なんてまずいない。 成果主義では収益に直結したところから評価される。 設計図で購買意欲をかきたてるなんてことはまずないから、開発者はうだつがあがらない。 器械部品としたどこかの国家プロジェクトは失敗した。 ソフト開発はオーガニックな活動で、部品の組み立て方に著作権があるくらい創造的なもの。 設計図は機能しない。同じものはできない。 権威が技術者にあれば、経営側にも医者にかかるようなコスト認識が生まれたはず。 本当は治るかどうかわからない患者をこの時期までに治すと約束する、みたいなことを業界全体でやっている。しかも患者の言いなり。 工業の枠に入れた時点でソフトウェア産業の将来は絶たれたようなもの。 現実は製造コストが最も重視され、削れるところから削ろうと血眼になっている。
経営者は農場主みたいな自覚で、自分の事業がモノ作りかどうかすら興味がないのが本音。
設計図を見て報酬を決める経営者なんてまずいない。
成果主義では収益に直結したところから評価される。
設計図で購買意欲をかきたてるなんてことはまずないから、開発者はうだつがあがらない。
器械部品としたどこかの国家プロジェクトは失敗した。
ソフト開発はオーガニックな活動で、部品の組み立て方に著作権があるくらい創造的なもの。
設計図は機能しない。同じものはできない。
権威が技術者にあれば、経営側にも医者にかかるようなコスト認識が生まれたはず。
本当は治るかどうかわからない患者をこの時期までに治すと約束する、みたいなことを業界全体でやっている。しかも患者の言いなり。
工業の枠に入れた時点でソフトウェア産業の将来は絶たれたようなもの。

]]>