月: 2010年1月

最近、私の住む市のゴミ収集の制度が大きく変わりました。
今までは、街中のいたるところに設置されたダストボックスに
好きな時に投函しておけば、定期的に回収されていました。
今後は、決まった曜日の朝にしかゴミを出せなくなります。
ゴミ袋は自治体指定のもので、これが結構高い・・・
市のＨＰを見てみました。
制度が変わった背景には
「焼却炉の閉鎖などでゴミの減量が急務であること」
「あと３年で期限を迎える、ゴミ50%削減という市の目標」などがあり、
そのための策として
「自分で出したごみは自分で負担・管理することで、ごみ問題への意識を高める」
というやり方が採用されたそうです。
たしかに、ゴミ出しの日が制限され、ゴミ袋が高いとなれば、
当然、消費者（ゴミを出す側）としては心理的な制約になります。
きっと、ゴミはいくらか減ることでしょう。
しかし、ゴミは消費者の心理から生まれるものでしょうか。
そういう一面があるのは確かですし、意識改革も必要なことではあります。
しかし、それが要因としてさほど大きいとは思えません。
現代社会の消費構造自体が、まだまだ「ゴミを極力出さずに済ませる仕組み」になっていのが
主な要因でしょうね。
（そもそも、ゴミの量を10年間で50%も減らそうと思ったら、
　市レベルの活動でどうこうなるとは思えないのですが・・・）
プロセスを変えずに出口だけを絞るような真似をすれば、
消費自体が冷え込む可能性もあります。（大袈裟？）
このブログをお読みのみなさんの会社でも、似たようなことは行われていないでしょうか？
たとえば、「ノー残業デー」です。
「○曜日は残業しないようにしましょう。」などと呼びかけるだけで
本気で残業が無くなると思っているのかどうか分かりませんが、日本中の多くの企業で行われています。
それで上手くいった（残業及び残業代の削減に効果があった）会社があるのなら
真似をするのも分かりますが、そういう話も聞きません。
たしか、だいぶ前の「ヤング島耕作」に、
「用もないのに会社に遅くまで残り、残業代だけ稼ぐ社員」がちょこっとだけ登場しました。
そういう社員を早く帰らせるには、多少は効果があると思います。
もっとも、最初から残業代を稼ぐことが目的であれば、他の曜日により長く残ればいいだけですが。
本当に忙しくて残業している社員にとっては、「ノー残業デー」の呼びかけなど、ただ煩わしいだけです。
仕事が終わらなければ自分の評価が下がるだけなので、
無視するか、家に仕事を持ち帰るか、どちらかです。
業務体系を抜本的に改善して効率化するか、
仕事のスピードを速めるテクニックを各社員に伝授しないかぎり、
残業が減るということは本来あり得ないはずです。
「そんなテクニックは自分で考えろ！」という考え方もアリだとは思うのですが、
たいていの社員はこっそり家に仕事を持ち帰るんじゃないでしょうか。
（たとえ禁止されていても、可能な限り。）
だってその方が、仕事の仕方を変えるより楽ですからね。
アウトプットとプロセスは表裏一体です。
プロセスの質はアウトプットで計測し、アプトプットを改善したくば
プロセスを改善するしかありません。
毎月３件以上のクレームを起こしている社員に対し、
「お前は来月からクレームを２件以上起こすな！」と言ったところで、
本当にクレームが減るでしょうか。
減ったとしたら、うまく隠してるだけです。
そんな馬鹿な指導をする管理職がいるとは思えませんが、
実はそれと同じくらいナンセンスなことが世の中ではいっぱい行われている、というお話でした。
現状でそれなりに成立している（してしまっている）プロセスを変えることは、本当に大変なことです。
しかしだからこそ価値がある仕事と言えます。
（安易に出口を絞る仕事は、簡単ですぐに出来る分、成果もたいして上がりません。）
そんな仕事をしようしようと思いつつ、「自分に甘い」悪い癖のおかげでやらずにきてしまいました。
しかしとうとう、やらざるを得ない状況に・・・
日本のサラリーマンのみなさん、しなやかにたくましく、それなりに頑張りましょう！

今日のテーマは「設計・開発」です。
「設計って、図面を描くことでしょ？」と思われるかもしれませんが、
ISO9001の規格の文脈においては少々意味合いが異なります。
7「製品実現」の章に　7.3「設計・開発」という条があり、その中に
7.3.1「○○の計画」
7.3.2「○○へのインプット」
7.3.3「○○からのアウトプット」
7.3.4「○○のレビュー」
7.3.5「○○の検証」
7.3.6「○○の妥当性確認」
7.3.7「○○の変更管理」
の項があります。
（○○の部分は”設計・開発”に置き換えてお読みください。）
あれこれと要求されているわけですが、
「そもそも『設計・開発』とは何をするものなのか」が明確ではありません。
そのため、この条を適用除外として認める基準は認証機関によってバラバラです。
（アイソスNo.146「認証機関への質問」より）
顧客から図面を渡され、「この通りに作ってほしい」と言われるような
「受託製造」型の企業では除外を認めるケースが多いようですが、
私は「7.3.3設計・開発からのアウトプット」に着目し、少し違う結論を出しました。
この項の中では、「設計・開発からのアウトプットは次の状態でなければならない」として、
「b)購買、製造及びサービス提供に対して適切な情報を提供する」ことを要求しています。
つまり、「設計・開発」とは「購買、製造及びサービス提供」のための、
ひとつ前の準備段階なんですね。
そもそもISO9001の構成では、
7.2「顧客関連のプロセス」
7.3「設計・開発」
7.4「購買」
7.5「製造及びサービスの提供」
という順序でならんでおり、設計・開発の前には
「顧客要求事項を明確にする」という工程があります。
顧客から要望を聞き、それを明確化してレビューしたところで、
いきなりモノを作り始めることができるでしょうか？
いきなりサービスを始めることができるでしょうか？
必ず、「この要望を実現するにはどんなモノをどう作ったらよいだろうか？」
「どんなサービスをどう提供したらよいだろうか？」
を考える工程が存在するはずです。
それが無ければ、具体的に何をしたらいいのか分からないはずだからです。
よって、業種・業態・企業規模にかかわらず、
「設計・開発」が存在しないということはあり得ない、というのが私見です。
顧客から図面を渡されている場合、たしかに
「どんな製品を作ったらよいか」は明確ですが、それだけです。
納期までに指定の数を製造するには、
「原材料の調達、稼働人員の調整、ラインの構成」など、考えることはいっぱいあります。
それら「生産計画の策定」が、「設計・開発」に該当します。
（私がよく参考にしている西沢総研のサイトでは、それを「工程設計」と読んでいます。）
もっとも、QMSの適用範囲を個々の製品の品質のみとし、納期や数量を管理外とするならば話は別ですが。
私のような解釈の仕方は一般的ではないようで、
実際、規格の「7.1製品実現の計画」の注記において
「組織は、製品実現のプロセスの構築に当たって、7.3に規定する要求事項を適用してもよい。」
と書いてあります。
つまり、「生産（製造）計画の策定にあたって、「設計・開発」の考えを当てはめるかどうかは任意です。」
と言っているわけです。
よって、
「何を作ればよいかは顧客から明確に指示があり、
　生産計画を策定しさえすれば製造工程をスタートできる」
スタイルの企業であれば、設計・開発を除外出来ると考えてよさそうです。
さて、次回は「レビューと検証と妥当性確認」です。