アカウント名:
パスワード:
>肝心の品質ってのは、書類に書きようのない事柄がいちばん重要なんじゃないか、と思う。 それは、せいぜい設計レベルか、町工場でしか通用しない考えですよ。 大型生産の現場では、属人化をなくすために書類化しているのです。 品質のために文書があるのではなく、第一に効率化ですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
H/W or S/W ? (スコア:2, 興味深い)
Re:H/W or S/W ? (スコア:5, 参考になる)
# 最近はソフトにも無理させている？色々詰め込みすぎ
例えば、要求仕様を満たすにはそれなりに発熱してしまうモジュールを開発する場合、いくら空冷するとは言っても要求された能力を出すにはもっと冷やさないといけない・でも、全体のデザインが熱が飽和してしまう作りになっていてシステムに熱が籠るようになってしまい、
結果、実地テスト中や量産に入ってから、出荷した物が(SONYの)要求仕様を大きく下回る使用時間でへたって(SONYから)クレームで戻ってきたり、他の部分が熱でやられたり。と言う泥沼何回か見ていますので(;´Д`)
まー、そういう状況を見ていますからね…
SONYの場合、個々のデザイナは優れている人がいるんだろうけど、全体を見ることが出来る人が殆どいないのではないかと(;´Д`)
まぁ、SONYでまともなのは、デバイス部門位のような気がしています…
Re:H/W or S/W ? (スコア:5, 興味深い)
(さらに蛇足ながら、Quality, Cost, Delivery の頭文字を意味する。)
しかし書類上で管理できるのは、製品仕様・コスト・出荷時期の3点であって、
肝心の品質ってのは、書類に書きようのない事柄がいちばん重要なんじゃないか、と思う。
ISO 9000 シリーズがはびこっているために勘違いしている人が多いけれど、
品質は書類で管理できない。
品質を書類で管理できるという思い込みで経営すると、
スパイウェアCD みたいな大惨事につながるんじゃないかな。
ロバート・C・マーチンは「悪魔は詳細に潜んでいる」と述べたけれど、
アウトソーシングの多用によって、詳細に潜む悪魔との戦いが、
あまりにも外注先の技術者に委ねられてしまっているんじゃないだろうか。
Re:H/W or S/W ? (スコア:4, 参考になる)
それは、せいぜい設計レベルか、町工場でしか通用しない考えですよ。
大型生産の現場では、属人化をなくすために書類化しているのです。
品質のために文書があるのではなく、第一に効率化ですよ。
だからどこかの臨界事故がおきた発電所では、品質上最悪な手順としての
バケツリレーが文書化されていたというわけ。
>ISO 9000 シリーズがはびこっているために勘違いしている人が多い
というか、あなたを含めてISO 9000シリーズの使い道を勘違いしている人が多い。
一番最悪なのは、あなたが指
Re:H/W or S/W ? (スコア:3, 参考になる)
品質問題で悩んでいないメーカーは皆無ですが、それに対して間違った膏薬を塗り続けている
ことの愚かさを、もっと認識し易くすべきでしょう。
品質向上のための妥当な方法論を持たずに効率管理に走っている会社では、
品質上のリスクをちょっとずつ発生させながら効率を少しずつ向上させる、
というプロセスが走っている訳ですが、それの問題点は、効率向上は
少しずつしか実現しないのに対して、品質リスクの具現化は
たまにドカンとやって来ることでしょう。1999年にジェーシーオーという
ウラン加工会社で起きた臨界事故は、その最たる例です。