アカウント名:
パスワード:
俺がいってるのは品質に関する内容ぐらい図面見りゃわかるだろうといっているのであって、図面を書けと入っていない。例えていうなら機械でいうこんな「▽▽▽」記号のことだ。
それで製品の品質がイメージできるか？ そんなのでイメージできるのは部品の精度であって、最終的な製品としての品質ではないと思うぞ？
無意味と思うのは作り手側のろくでもない意識の問題だけであって品質は、それを使う側の人間にとっては非常に大切なことだ。
それには同意する。
それに、「不可能」というのは、尺度や測定の方法が確立されていないだけの話であって真実ではない。
では、既に他の人にも言われてるが、あなたは示せるの？ 工業製品との違いを理解しないで、不可能ではない、方法が確立されていないだけでできるはず！などと言っても、本職からすれば妄想にしか見えませ
通常、他の工業製品では統計的手法というのは検査の作業を省略するための手法であって本当に重要なものに関しては、全品検査を行うのが普通である。
さんざん反論されてるのと同じ人？ 何度も言うけど、プログラムと工業製品の違いを理解しなさい。 全品検査とか、あほな単語が出てくるのが理解できてない証拠、プログラムって言うのは「一品」しか作らないものなの。 パッケージソフトみたいにお店に出荷してるのも、単にそれをコピー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
発注側の責任でもある (スコア:3, すばらしい洞察)
と題してこういう問題を取り上げてた。
発注側もシステムをよく理解してないから、ほとんどメーカーの
言うなりになってきたけど、自治体が自分たちで業務を分析して
仕様書を書いて、機能をバラして発注してみたら、あーらびっくり
全然安くできちゃいました、みたいな話。
開発側のはしくれとして思うんだけど、こんなの当たり前だよね。
こういうお客さん、めずらしくない。
自分たちのシステムなのに、全然内容わかってなかったり他人任せ
にしてたりすることはよくある。そのくせひどいときには後から
文句だけは言ったりする。
いや工学として洗練されていないのが原因 (スコア:1, すばらしい洞察)
実際の話し、IT関連へ対する社会的なイメージは「最先端」、「高度」なんてイメージ持っている人多いようだけど、幻想に惑わされてはいけません。
機械でも、電気機器でも図面さえあれば高校でたての新人でもほぼ同じ品質の品物をイメージできるのに、そうじゃないのは情報関連ぐらいだよ。第一誰が見ても同じ物をイメージできる共通の図面に相当するものさえいまだに一本化できていない。
正直なところ、IT関連はエンジニアリングできていない工芸の世界ですよね。今回の分離発注が注目されることから見ても他の分野に比べると30年は遅れているんじゃないかな。実際のところこのあたり工学がしっかりと体系化できていないから今まで分離発注もままならなかったというのが真相でしょう。
「ITゼネコン」なんて呼び方、本物の「ゼネコン」に非常に失礼だと思う。
Re:いや工学として洗練されていないのが原因 (スコア:0)
プログラムは文学で、システム構築は伝統工芸なんです。
そもそも １人月なんて換算式を適用するのが間違いなんだから...
(本来は結果で判断されるべき業界だと思います)
大体 工学分野という切り分けで考えれば最近20年間程度で
弱電気、電子、経営(工)、情報、知識 etc...
と大きな進歩と大きな広がりをしてれば工学として確立される訳がない。
(工学として確立された頃には利用されないあるいはそれ以上を求められます）
あとどういう意図かは判りませんが
機械でも、電気機器でも図面さえあれば高校でたての
Re:いや工学として洗練されていないのが原因 (スコア:0)
>プログラムは文学で、システム構築は伝統工芸なんです。
とはいえ、工学にしていく動きは延々と存在していて、
Re:いや工学として洗練されていないのが原因 (スコア:0)
少なくとも、現状のシステム構築なんかは10年後くらいには工学化されるでしょう。
しかし、１０年後に今と同じシステム構築なんて誰もやっていないでしょう。
という事で、やはり１０年後にも同じ事を言っているように思います。
まぁ 進歩が止まれば工学
Re:いや工学として洗練されていないのが原因 (スコア:0)
この手の話は手を変え品を変え、延々と続けられてきましたよ。
珍しくも何ともない。
どうせまた一つ失敗の歴史を積み重ねるだけです。
プログラムの品質とは？ (スコア:0)
それで製品の品質がイメージできるか？
そんなのでイメージできるのは部品の精度であって、最終的な製品としての品質ではないと思うぞ？
Re:プログラムの品質とは？ (スコア:0)
＞そんなのでイメージできるのは部品の精度であって、最終的な製品としての品質ではないと思うぞ？
＞そもそもプログラムはそんな何ミリまで誤差があります、みたいな考えとは根本的に異なるものだし
▽▽▽を要求されている品物で～を想像するばか者は少なくとも専門教育受けていればいないだろう。少なくともおまえもそこまでバカじゃないだろう。要は、機械や電気では基本中の基本の精度や品質を情報関係ではあらわすことさえできていないところに未熟なところが残っているというこ
Re:プログラムの品質とは？ (スコア:0)
>あらわすことさえできていないところに
「できていない」じゃなくて「不可能」或いは無意味．
>未熟なところが残っているということを行っているのだ。
未熟なんじゃなくて，そもそも本質が異なる．
「ソフトウエアの品質」という言葉の意味さえ分かってない．
「精度がどれだけ」「何万Km走行しても故障するのはXX台辺り一台」
とかじゃなくて
「歴史に残る名車／名器」
の類に近い．
一個3億円のバイオリンと一個数十万円のレプリカは図面レベルじゃ
ほと
Re:プログラムの品質とは？ (スコア:0)
それが製品である以上品質は無意味なことはない。無意味と思うのは作り手側のろくでもない意識の問題だけであって品質は、それを使う側の人間にとっては非常に大切なことだ。
Re:プログラムの品質とは？ (スコア:0)
それには同意する。
では、既に他の人にも言われてるが、あなたは示せるの？
工業製品との違いを理解しないで、不可能ではない、方法が確立されていないだけでできるはず！などと言っても、本職からすれば妄想にしか見えませ
Re:プログラムの品質とは？ (スコア:1, 興味深い)
江戸時代の職人ならこんなこと言ってそうだな。昔の建築で使われていた釘を見てると同じ物なんて一つとしてない。それに比べ今のくぎなんて同じ規格のものなら違うもの探すほうが困難だろう。この原因はどこにあるのかというと、
1. 品物の図面があるのか
2. 作った品物がそのとおりにできているのか検査する手法が確立されているか
この二点に集約される。
逆に現状情報関連をみると、
1. 一応の図面に相当するものはある。ただし、記述方法に統一性と一貫性がない。品質に関する記述もない（できない）。
2. 作った品物の検査方法は、「使ってみる」しかない。
このレベルでは、品質に使える手法は統計的手法しかない。通常、他の工業製品では統計的手法というのは検査の作業を省略するための手法であって本当に重要なものに関しては、全品検査を行うのが普通である。これをやらないのは単に経済性の問題か非破壊検査が不可能な場合である。また、統計的手法によって不良品が引っかかった場合は、不良品をはねるために全品検査に切り替えるときもあるが、品質要求が厳しい場合は最悪全品破棄等もある。しかし、一番の問題は「使ってみる以外」の検査方法がないことだと思う。この部分がクリアできないことがこの分野が未熟だといわれる所以だと思う。
この分野で問題意識を持っている人は常に感じていることだと思うが、この分野が本当に他の分野と肩を並べて今後発展するためには、度量衡にあたる物、検査機器にあたる物が出てくるかどうかにかかっていると思う。
Re:プログラムの品質とは？ (スコア:0)
さんざん反論されてるのと同じ人？
何度も言うけど、プログラムと工業製品の違いを理解しなさい。
全品検査とか、あほな単語が出てくるのが理解できてない証拠、プログラムって言うのは「一品」しか作らないものなの。
パッケージソフトみたいにお店に出荷してるのも、単にそれをコピー
Re:プログラムの品質とは？ (スコア:0)
そうそう、わかってるじゃん。
「一品物」である以上、不具合があれば叩き壊して不具合のないものを提供するのが義務です。
作り手側に「一品物」を作ってる意識がないバカがたくさんいるから、ダメなんですよねぇ。
Re:プログラムの品質とは？ (スコア:0)
＞「一品物」である以上、不具合があれば叩き壊して不具合のないものを提供するの
＞が義務です。
一品物であるかどうかに関わらず、どんな不具合か次第でしょう。
契約した範囲内のものなら義務になるってだけ。
そうでなければお金をいただいて対応する、というだけ。
＞作り手
Re:プログラムの品質とは？ (スコア:0)
あぁ、「一品物」がなんたるかわかっていない典型的なコメント。
たとえ顧客が構わないというほどの瑣末なキズでさえ、許してはならないのです。
それこそが一品物クオリティ。
一品物をつくる技術も気概もなければ、単純労働による工業生産に従
Re:プログラムの品質とは？ (スコア:0)
＞それこそが一品物クオリティ。
職人とプロみたいなものですかね?
まぁ、そこまで入れ込んで作るほどの仕事は確かに出来ないので、
頑張ってください。
＞そりゃそうなんだけどさ、片手間に作った物を一品物だと言って売りつけるのは、
＞ある意味詐欺だぞ。
Re:プログラムの品質とは？ (スコア:0)
やっと理解できたよ。プログラムは特別だといっている（思い込んでいる）だけなんだな君は。君みたいなやつらの横行がプログラムに関してはPL法の適用さえされない味噌くそ分野に追い込むことに貢献しているんだな。
他の分野で一品物の典型は、土木や建築の世界で往々にして見ることができるけど、恐ろしく品質要求基準高いよ。たとえば、鉄筋コンクリート製の橋なんかをあるところにかけたとする。何億もかけ、その橋を作ったあと検査の際に材齢強度が設計基準を満たしていないと、基本的に取り壊して作り直
Re:プログラムの品質とは？ (スコア:0)
>車両や人を通さないのが土木建築の分野の品質管理水準。
実際に橋が落ちたこともあるし、新幹線のトンネルからコンクリートの
塊が落下してあわや大惨事ということもあった。コールドジョイントが
原因でその後一斉検査をしてたよな。
タコマナローズ橋は静的な強度計算しかしておらず、カルマン渦列による
力に耐えきれずに崩壊したのだろう？建築史上に残る有名な事件だと
聞いている。
土建屋の「品質管理」なんてそんなもんだ。
ソフトウエアのバグ０はそれに比べて
Re:プログラムの品質とは？ (スコア:0)
>
>ソフトウエアのバグ０はそれに比べても遙かに難しい。
まじめに品質管理するつもりなら、外因の多い土建屋の方がはるかに難しいぞ。
自分の主張のために事実を捻じ曲げるのは感心できない。
Re:プログラムの品質とは？ (スコア:0)
あの話は、風による共振現象で確かに橋が落ちたのだが、その後のアメリカの建築学会の総力を挙げた原因の究明と計基準の見直しなど多岐にわたる対策により、その後のつり橋の設計基準が変わり同様の原因によりつり橋が落ちる事は世界的になくなった。つまり、業界の問題に対する取り組みを象徴する出来事なのだ。
実際に、新幹線のトンネル壁剥落事故にしても、神戸の震災の高架が落ちた事故も、最近では、新潟の地震にしろ、土木や建築の学会は大挙して学者を派遣し、さらに、お金にならないのはわ
Re:プログラムの品質とは？ (スコア:0)
知らなかったくせに無理しなくていいよ。
それにやっぱりソフトウエアの本質を分かってないド素人ゆえの発言だ。
>その後のつり橋の設計基準が変わり
>同様の原因によりつり橋が落ちる事は世界的になくなった。
「その後」の「同様の原因」に限れば「ほとんど」なくなっただけ。
「同じ失敗は（ほとんど）二度と繰り返さない」ということ。
新しい失敗原因についてはやはり失敗は避けられない。
ソフトウエアは一品ものであり、毎回要求事項も作るものも変化する。
だからたとえ「同じ失敗を二度と繰り返さない」とし
Re:プログラムの品質とは？ (スコア:0)
おまえ何も書かないほうがいいよ。話の本質を読む能力に決定的に欠けている。見てて痛々しくなる。タコマの大橋の話の本質さえ読むことができないとは情けない。
＞ソフトウエアは一品ものであり、毎回要求事項も作るものも変化する。
これこそこの業界の問題を反映している事例じゃないか。おまえ何度言っても理解できてない。土木がいやなら設備のほうの話をしてやろう。工場なんて日本中に何百万とあるけど一つとして同じ工場はない。たとえ同じ品物を作る工場を同じ時期に立ててもすべて違ってい
Re:プログラムの品質とは？ (スコア:0)
無茶苦茶言ってるなぁ。
仕様バグを除けば、開発バグの要因なんてたかがしれてるぞ。
稀にわけわからんのが紛れ込んでたりするが、ほとんどは既知の事象じゃねぇか。
それでも
Re:プログラムの品質とは？ (スコア:0)
一番あとを引くのは異常系の処理だと思いますけどね……
これは仕様バグなのか、開発バグなのかな?
＞たとえ顧客が構わないというほどの瑣末なキズでさえ
Re:プログラムの品質とは？ (スコア:0)
＞しかし、１０年後に今と同じシステム構築なんて誰もやっていないでしょう。
＞という事で、やはり１０年後にも同じ事を言っているように思います。
を書いたACですけど、ちょっと書いた意図を勘違いされているようですからコメント
技術の連続性が希薄な新技術を採用したときの効率がそうでない場合の数十倍であったらどうします？それでも技術の連続性を重視し効率の悪い方を選びますか？
実際にあった話ですが、４年前のシステムのリースアップに絡み新規システムを
Re:プログラムの品質とは？ (スコア:0)
実際にそれの検証が取れるのに分野にもよるが速いものだと数ヶ月遅いものだと数十年の歳月を費やすことさえあります。
実際の技術の伝播の過程を建築関連の典型的な事例を示すと大まかには以下のような形となっているようです。（私が携わったことがある少ない経験からの話なのでもっと別の過程をたどることもあるかもしれません。）