品質工学を学ぶ

まとめてのupになってごめんなさいね、
実質先週水曜以来のupになります。まとめup。
毎日書いてるつもりが4/7しか書いてなかった、猛省。

◇

今日は昨日までの生活がたたって
久々に半日以上寝ました。

ところで独学で品質工学（タグチメソッド）を学ぶ必要性に迫られており
昨日本を買いつつ今日勉強に励んだのだけれど、
残念ながら一日で読み切ることができませんでした。
（さすがにゲームと違って一日ではクリアできない。）

具体的には、現在の業務内容がこの品質工学と呼ばれる概念とマッチしているため
周囲からはこの概念を少しでも3年次の発表に盛り込むことを
要求されているように思うのだけど、
業務として作業内容として盛り込む可能性は低く、
なおかつその選択肢を選ばなかったことを
社員（？）に納得させるために勉強が欠かせなくなっている、という筋書きです。

…というわけで今日は"ベーシックタグチメソッド"　長谷部光雄 著
の習得事項をここに記載します。

※本文の内容を転写した部分も多いので、クレームありましたら削除します。
クレームがなければ終わりまでこういった感じの読書ノートを作ります。

どうでもいいことですが、喫茶店に2時間入り浸ってpomeraをノート代わりに
纏めた結果です。1行の表示文字数が少なめのため改行が多いのはご愛嬌。

一応全部通読したのですが、
やっぱノートを作った方が何かと役立ちますね。

以下読書ノート。
興味がない場合は全く面白くないので読まないことを勧めます。
（あと、Tabキーの空白が反映されていなくてかなり読みづらいっすね…）


読書　"ベーシック タグチメソッド"

Intro
　■日本のモノづくりの現状認識
　　現在の日本のモノづくりは多少なりともスペックの
　　大小に振り回されている部分があり、"よいモノ"
の指針が失われつつある。
実は日本は品質工学的な見地で欧米等に
後れをとっている。
生産現場での品質管理においては他に勝る日本。
製品開発での技術をブラッシュアップさせ、
技術立国の復権を図るのだ。

§1 タグチメソッドはなぜ必要か　～品質管理方式を超えて～
　■製造現場（工場）と開発設計での意識カイリ
　　現在の品質は、現場での対応に助けられている
部分が大きい。しかし開発サイドの余裕がない
ことも事実。

　■技術のDNAはユビキタス性
特定の技術では使えないようなモノではなく、
汎用性の高い考え方が必要である。
（汎用性＝環境変化の対応力や頑強性）

　　□現在の問題点
　技術管理の本質を問題点の項目数という量で
　把握しているにすぎない。質で管理すべきものにも
　量的な評価に引っ張られる。労務管理の発想。

　●この現象が誘発する問題点
製品開発部門の慢性的な残業と人手不足、
納期遅れ。
技術者を作業者とみなすことによる
技術者の質の低下。
　○問題点のもたらす結果
・同様のトラブルが何度も起こる再発問題
・1つの問題を解決するとまた別のがでてくる
　もぐらたたき現象
・新規技術に手が回らない技術者の能力低下

□機能性評価
　基本的な考え方は
　①目的を達成するための機能を考える
　②機能を具体的に測定できる方法を考える
　③ワーストケースを考える

　●①に関する記述
今の状態が問題ではなく、将来的にエラーが
起こるかどうかを判断することが重要である。

　●②、③に関する記述…ワーストケースでの安定性評価
機能性を損なうパラメータの洗い出しを行う。

□具体例…モータの例
　一つのパラメータを変化させたときのばらつきを
　平均値で割る。
　▼ばらつきって標準偏差と等価なのか？
多分、違うような気がする。
とにかく、ばらつきの導出によって設計品質が
わかるのだ。
　そして、従来半年かけていた信頼性評価を
　数日の作業に変えた。

§2 徹底的なユーザ思考と目的重視

□"タグチメソッド"と"品質工学"の用語的な違い
　"タグチメソッド"はskill=手段であり、
　"品質工学"はwill=設計思想である。
　何がしたいかわからなければタグチメソッドは
　役に立たない。

□"品質工学"という用語に立ち戻る
　品質工学が追求するのは
　使用条件でのばらつきである。
　●ばらつき発生要因…2つある。
・生産ラインの工程ばらつき
　大抵きちんと管理されている。
・使用者の手元で起こる品質ばらつき
　環境や使用条件は管理されない。
　事前対策を練っておかないことには
　対策が無理である。
→市場クレームに対応するのはこっち
　品質工学適用の中心は上流の開発・設計現場が
　対象である。
　
　用語でのアプローチをするなら
　従来→フィードバック方式
　品質工学→フィードフォワード方式
　
　●用語定義確認
フィードバック方式
　生産工程（現場）中心
　発生した問題を解析する役割
　泥棒が入ったら縄を作る泥縄方式
後工程での評価条件が厳しくなる
惨事に陥りやすい
→技術の素質が悪いことを小手先の修正で
　乗り切る発想が不可欠なため
開発期間や必要人員が予測できない

フィードフォワード方式
　開発設計工程中心
　潜在する問題を予測して対策する役割
　泥棒が入りにくい環境を事前に作る。

　というように、問題発生の前に広範な問題を
　予測して対策する方法である。

　あとは…
　①初期の機能が目標値を満足していること
　②その機能が様々な条件で安定して発揮されること
　の２つだけ書けていればよいか。

　■ＳＮ比
　　フィードバック、フィードフォワードの話の
発展系だが、段落を分ける必要性があったので
分けて書くこととする。

□たとえ話
　改札の検出制度を上げる際に検出回路の
　電圧を上げることを第一に考える…が、
　ノイズも増幅されるので品質改善に関わるかは微妙
　■まとめ
機能達成度→機能安定性　のチェック順（ＦＢ）でなく
機能安定性→機能達成度　の順（ＦＦ）でみていく！
　　□ちょっと掘り下げ
　従来の手法とはやり方が異なるが、
　その差異を別に表現してみよう（3点）
①ユーザ視点であること
②目的重視であること
（科学的な真理へのアプローチではなく）
③常に実証データを重視すること。

　■Appendix
ライト兄弟のたとえ話。風洞実験を行ったことで
実環境での振る舞いをよく理解した…という
ことになって他の科学的事実からアプローチした
科学者との差異を指摘しているが、
実環境での振る舞い（の推定）に抜けがある
可能性があったことはどう解釈すればいいのだろう？
（ライト兄弟のやったことがフィードバック的に
　見えてしまうのだが、その解釈は
　誤りなのだろうか？）
そうそう、このコラムは
前段落の②についての記述なのだけど、
科学的真理=品質なのではないか？
という疑問があり、氷解していない。

以上 2/11分（進捗：2章終わりまで）