アカウント名:
パスワード:
そもそも「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか？」は大抵の場合、ＮＯですから。
上流工程の段階から仕様をきちんと煮詰められる（プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる）人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
＃でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでＡＣ＃ＡＣの意味がないのは芸風です（言い切った）
> 「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。完全同意の、すごく良いこと言ってると思うんですけど、ここで言う 品質 に２つの意味が混ざっちゃってませんか？
「品質」と聞いて何を思うかは人それぞれですが例えばISO-9000でいう品質とは：
本来備わっている特性の集まりが、要求事項を満たす程度
ということになってます。つまり「その製品を要求事項にどれだけ近づけるか」が品質だ、とまずは定義しておいて、じゃあ要求事項って何よ、としたとき、「仕様書に書いてあるのが、要求されたことだ」と捉えるのが旧来の品質管理とすると、「『顧客満足』を満たすことが要求されたことだ」と、近頃は より踏み込んで品質管理を再定義する考え方が広まってきています。
巫女・・・失礼、ACさんのコメントで「バグの数＝ソフトウェアの品質」というのは前者の品質で、それ以外は後者ですよね。この２つの品質は分けて語らないと やることが正反対になっちゃったりするので要注意だと思ってます。# 仕様書原理主義と積極改訂派の聖戦を何度経験したことか
個人的には、どちらの考え方も大切だと思います。巫・・・ACさんの、バグの数だけ見ていても後者の意味の品質には永遠に気づけない、という考え方はお世辞抜きに、物作りに関わる全ての人に持って欲しい素晴らしい考え方です。が、「バグの数を品質管理に利用する」という方式論も、前者の意味の品質管理においては決して短絡的でない、有効な手法であると思います。
ああやだやだ。こういう俺様賢い的な馬鹿に何度苛つかせられたか。トラウマに触れたので横から参戦するよ。失礼。
＞ISOとかCMMとか、馬鹿にする前にちゃんと読んでね。あのねえ、ISOとかCMMとかを馬鹿にするコメントが今までどこに出てきてる？俺もISO9000を勉強したことがあるけど暗黙・明示的要求事項なんて元コメは理解してると思うよ。そのうえで明示＝旧来、暗黙＝新しい、と言い換えてわかりやすく説明してくれてるじゃん。何言ってるか理解してないのは多分あんただけだよ。
＞っていうのは、最近の流れではなくて、昔
わかってないなあ・・・トラウマ抱えたどうしらしいから相手してあげるよ。
＞昔は悪いもの。現在はいいもの。というきりわけに感じてしまいます。元コメよく読みましょう。＞個人的には、どちらの考え方も大切だと思います。って書いてるよね。良い悪い言ってるのはあんただけ。つーか老人にとっては昔が良いもので新しいのが悪いものなんだよ。
＞近頃と旧来を勝手に言い換えてしまいましたね。”近頃”、”旧来”がオレ目線でなく、”最近””昔”がオレ目線でしたらすいません。これが本気で言ってる？まさかそこまで馬鹿じゃないよな？言
ソフトウェアの品質を語るならISO9000よりもISO9126でしょう機能的な品質だけでなく非機能的な品質も考慮すべきなのは当たり前の話ですよね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
そもそも (スコア:3, 興味深い)
そもそも「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか？」は大抵の場合、ＮＯですから。
上流工程の段階から仕様をきちんと煮詰められる（プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる）人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
＃でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでＡＣ
＃ＡＣの意味がないのは芸風です（言い切った）
Re:そもそも (スコア:3, 参考になる)
> 「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。
完全同意の、すごく良いこと言ってると思うんですけど、ここで言う 品質 に２つの意味が混ざっちゃってませんか？
「品質」と聞いて何を思うかは人それぞれですが例えばISO-9000でいう品質とは：
ということになってます。
つまり「その製品を要求事項にどれだけ近づけるか」が品質だ、とまずは定義しておいて、
じゃあ要求事項って何よ、としたとき、
「仕様書に書いてあるのが、要求されたことだ」と捉えるのが旧来の品質管理とすると、
「『顧客満足』を満たすことが要求されたことだ」と、近頃は より踏み込んで品質管理を再定義する考え方が広まってきています。
巫女・・・失礼、ACさんのコメントで「バグの数＝ソフトウェアの品質」というのは前者の品質で、それ以外は後者ですよね。
この２つの品質は分けて語らないと やることが正反対になっちゃったりするので要注意だと思ってます。
# 仕様書原理主義と積極改訂派の聖戦を何度経験したことか
個人的には、どちらの考え方も大切だと思います。
巫・・・ACさんの、バグの数だけ見ていても後者の意味の品質には永遠に気づけない、という考え方は
お世辞抜きに、物作りに関わる全ての人に持って欲しい素晴らしい考え方です。
が、「バグの数を品質管理に利用する」という方式論も、前者の意味の品質管理においては決して短絡的でない、有効な手法であると思います。
Re:そもそも (スコア:2, 参考になる)
えっと、そのISOには、”要求事項”として、”暗黙の”要求事項も含まれると書いてあるので、「旧来の品質管理」であっても、仕様書に書いてあるのがすべてだなんてことはありません。
ISOとかCMMとか、馬鹿にする前にちゃんと読んでね。
なので、
＞より踏み込んで品質管理を再定義する考え方が広まってきて
っていうのは、最近の流れではなくて、昔からまともな考え方です。
ありうるとしたら、ISOやCMMを誤解した人たちが一時期いっぱいいたということでしょう。
＞仕様書原理主義と積極改訂派の聖戦を何度経験したことか
仕様書原理主義者っては、言われたことをやるのに精一杯な若手のことでしょ？
顔が老けたり、態度のでかい若手もいるでしょうが、そういうときは、戦うのではなくて、にこやかにたしなめるのが、先輩としての態度でしょうｗ
Re: (スコア:0)
ああやだやだ。こういう俺様賢い的な馬鹿に何度苛つかせられたか。トラウマに触れたので横から参戦するよ。失礼。
＞ISOとかCMMとか、馬鹿にする前にちゃんと読んでね。
あのねえ、ISOとかCMMとかを馬鹿にするコメントが今までどこに出てきてる？
俺もISO9000を勉強したことがあるけど暗黙・明示的要求事項なんて元コメは理解してると思うよ。
そのうえで明示＝旧来、暗黙＝新しい、と言い換えてわかりやすく説明してくれてるじゃん。
何言ってるか理解してないのは多分あんただけだよ。
＞っていうのは、最近の流れではなくて、昔
Re:そもそも (スコア:1)
まず、トラウマに触れたのならすいません。
自分は元コメの話の流れから、「仕様書に書いてあるのが、要求されたことだ」と捉えるのが旧来の品質管理とすると、」があたかもISOからそう導かれると読み取ってしまいました。
「ISOは、顧客の要求なんてどうでもよい。文章だけ整えればいいんだ。」という考え方を感じたんです。
自分には、そういう人たちに品質をずたずたにされたトラウマがあります。
トラウマで脊髄反射投稿してしまってすいません。
＞そのうえで明示＝旧来、暗黙＝新しい、と言い換えてわかりやすく説明してくれてるじゃん。
その言い換え自体が引っかかるんです。
なんで旧来のやり方は明示的なものだけだといえるんですか？
昔は悪いもの。現在はいいもの。というきりわけに感じてしまいます。これも誤読でしたらすいません。
＞最近っていつからいつまでさ。昔っていつさ。話者によってスパンが異なる概念をオレ目線でしか考えられないから
近頃と旧来を勝手に言い換えてしまいましたね。”近頃”、”旧来”がオレ目線でなく、”最近””昔”がオレ目線でしたらすいません。
以上
Re: (スコア:0)
わかってないなあ・・・
トラウマ抱えたどうしらしいから相手してあげるよ。
＞昔は悪いもの。現在はいいもの。というきりわけに感じてしまいます。
元コメよく読みましょう。
＞個人的には、どちらの考え方も大切だと思います。
って書いてるよね。良い悪い言ってるのはあんただけ。
つーか老人にとっては昔が良いもので新しいのが悪いものなんだよ。
＞近頃と旧来を勝手に言い換えてしまいましたね。”近頃”、”旧来”がオレ目線でなく、”最近””昔”がオレ目線でしたらすいません。
これが本気で言ってる？まさかそこまで馬鹿じゃないよな？言
Re:そもそも (スコア:1)
ずいぶん親切な方のようでありがとうございます。
＞会議でそういう奴がいると迷惑だろ？そういう奴がいるとさ、どうでもいい話に時間取られて大事な話ができなくなる。
会議ではさすがにしませんね。雑談場だと思うからしましたけど。
元コメの主張と違う瑣末なところに突っ込んだから怒られてるんですね。ようやく理解しました。
それなら全くその通りで、弁明のしようがないです。
（ちがってたらどうしよう。）
自分は元コメの「『仕様書に書いてあるのが、要求されたことだ』と捉えるのが旧来の品質管理とすると」
というところに引っ掛かっていました。過去は過去で品質のいい時代もありました。
が、それにＩＳＯを絡めるとかよくわかんない展開してますね。
＞ISOとかCMMとか、馬鹿にする前にちゃんと読んでね。
ではなくて、
「昔の品質管理だって悪いものばかりではないよ」を主張とすべきでした。
それにしたって元コメの主張とは外れてますけど。
１７時のコメントはちょっと冷静さを失ってました。
ＡＣさんのような語調は、プロジェクトを散々ひっかきまわした挙句退社した元上司を思い出してしまい、苦手でして、すいません。
元コメの方にもお詫びします。
Re:そもそも (スコア:1)
Re: (スコア:0)
ソフトウェアの品質を語るならISO9000よりもISO9126でしょう
機能的な品質だけでなく非機能的な品質も考慮すべきなのは当たり前の話ですよね