品質担保に於ける技術の錯綜問題(20060928)

2006.9.28

品質担保に於ける技術の錯綜問題…

　“本当の”カスタマー・ファーストを追求すると、ゼロ・ディフェクトを確約すべき領域を明確化することになるのではないか、という話をした。
　　→　「品質問題の記事を見て」 (2006年9月25日)

　抽象的で、どういうことかわかりにくいかも知れない。

　「未熟者の浅知恵ですが、・・・」とは、謙遜の姿勢を表す言葉とされる。しかし、これが現実のものとなりつつあるということ、と考えればよいかも知れぬ。
　技術が錯綜すると、すべてを見ることができなくなるのである。本人はよく知っているように思うが、その範囲は限られており、気付いていない領域からの影響は考慮に入れていないのである。
　これを、伝承の知恵が伝わっていないから気付かないのだと解釈する人も多い。実際、その通りのことも多いからだ。

　　しかし、これは、現場のヒトの活躍に頼る品質管理が限界に来ていることを示していると見ることもできるのである。
　　そう考える理由は、大きくいえば3点。
　
　　簡単に説明していこう。
　
　　1つ目は、目で見てわかる「技術の錯綜」問題。　様々な技術が融合してきた上、技術そのものも高度化してきたから、専門家しかわからない技術が流れ込んできたことがある。
　例えば、機械の中に、通信回線が入り込んできたとする。機械屋にはわからぬ、高度な通信技術が起用されたとする。この回線に悪影響を与える電磁波が機械から発生する可能性はあるのか、どの程度のノイズまで容認できるのか判定できるだろうか。
　「そんなの常識」という“常識”がどこまで共有できるかで、問題発生防止ができるか否かかが決まることになる。
　アナログ・オーディオ屋の集団が率いていた時代なら、ノイズ防止の“常識”は共有できただろうが、機械、電気、電子、光、プログラム、・・・と技術が多岐に渡る時代になるとそう簡単ではないのである。

　しかも、技術の担当者が社外化してきた。社外との緊密な連携ができるようになったと言ったところで、社外の見方と、社内の見方は違う。社外の人は、どうしても個別最適を狙うことになる。
　それが組み込まれると、どのような影響がでるかは、知る由はない。

　つまり、全員懸命に、品質向上に注力していても、合成するとたいした効果が発揮できなくなるということである。それどころか、悪い方向に進む可能性もある。必要な知識の幅が余りに広く、影響が予想できなくなってきたということである。

　それではどうしたらよいか。

　少なくとも、モジュール化は避けて通れまい。言うまでもないが、組み立てを簡単にするための、物理的な意味でのモジュール化ではない。機能の面でモジュールという概念を取り入れる必要があろう。
　機能を実現するために必要な一切合切を一纏めにして考えるのである。

　要するに、モジュール内での品質マネジメントは従来型の絨毯爆撃でも通用する点にある。今迄培った力が活用できるのである。
　ただ、こんなことを可能にするためには、相当な組織能力を必要とする。
　モジュール間の干渉を防ぐと共に、モジュールを集めるだけで当初の目標を達成できるようにしなければならないからだ。各モジュールに、所与の条件を与え、モジュール相互のインターフェース規格を設定する作業が要となる訳である。

　実は、こんなことは、技術屋が顔をつき合わせて日々やっていることで、目新しいことではない。
　問題は、このプロセスを“見える”形で整備できるかなのだ。属人的なやり方がなされ、モジュールの切り分けも種々雑多、議論の進め方も様々、ということではどうにもならなくなる。現場の自律型の動きから、優れたやり方や教訓をまとめ、プロセスを作りあげる仕組みが上手く機能しているかどうかが勝負なのである。
　ただ、注意すべきは、モジュールを物理的に考えていない点。機能で考えるということは、将来を予測して考える必要があるということ。将来像を考えながら、モジュールを定義することになる。これは、今迄のやり方とは違うのである。

　この問題は、実は、2つ目の問題と絡む。
続く　→　(2006年10月2日予定)

　技術力検証の目次へ＞＞＞　　　　トップ頁へ＞＞＞