品質とは管理されるべきもの

ここまでで新製品の品質を定義し、設計してきました。

品質とは定義されるべきもの
品質とは設計されるべきもの

その品質を管理し、維持するためのシステムを構築するのが生産工程の設計です。
部品の発注先を選んだり、製品設計中から製品の構造から組立工程の構成を考えたり、量産に移行する前に試作品を使って性能や信頼性を評価をしたり、量産に移った後も工程内管理や検査や定期的な信頼性試験を実施するのも全て品質を管理して維持するための行動です。

これらが欠けたら生産する製品の品質は維持できず、歩留まりが下がるか、最悪のケースでは開発中や生産中の品質不良を検出できず市場に流出させることになります。

・開発中の品質管理

開発中の品質管理はまさに「品質の設計」で書いたような部分になります。開発中の品質管理は、製品の品質そのものは作り上げる最中なので、その製品品質を作るためのプロセスが想定通りに稼働しているかどうか、開発プロセスの業務状況が適切かがその管理対象になります。

自社がどのような開発業務を設定し、それに対応するためにどのような組織を作り、開発プロセスを運用しているか(=製品開発のためにどのような段取りをしているか)を決めておき、その通りに業務が進んでいることを確認します。

開発中の業務を通して品質を管理しますが、生産中と異なり、数値で確認するのが難しいように感じるかもしれません。そうであれば、内部監査の結果や日々作られる書類、帳票類の内容の機能に関する項目などを数えるなど、定量化する方法を検討して何らかの指標にするという手もあります。

・生産中の品質管理

生産中の品質管理の目的は開発終了し量産移行した時の品質を維持することです。

工程が当初設計した通りに稼働していることは設備の日常管理で取得できるデータや、各工程間で行われる工程内検査のデータで行っていると思います。
出荷検査で不良がなくても良品率100%にはならない

生産中の管理はこれだけではなく、製品によっては量産中にも信頼性試験を実施します。これも製品の特性や生産数から内容や対象となる抜き取り数が設定されることが多いようです。

・販売後のケア

販売後、不良品が流出していた場合には顧客の手元でその不良が顕在化することもあり得ます。その時のために問い合わせ窓口と修理対応や不良品交換の準備をしておきます。

いわゆるアフターサービスやサポート対応になりますが、この話を管理の所ですることにも意味があります。ユーザの手元で発生した不良品は、そのユーザの使用環境と使用方法によって故障が発生しています。それらは合わせて貴重なマーケティングデータであり設計データです。ですので、ユーザからの問い合わせやクレームをただ面倒なものとせず、その中から使用環境と使用条件、使い方、壊れ方を情報として収集できる体制が必要です。

特に使用環境や使用方法については注意を払って確認します。ユーザは作り手が想像もしなかったような使い方をしたり、想定していなかった使用環境で動作させたりするものです。メーカとしては「そんな使い方しないでくれよ!」と思うこともあるかもしれませんが、逆のことを言えば、ユーザは「こんな場所でこんな風に使えたらこの製品はおもしろいかも、意味があるかも」と感じているということですので、その使われ方をする市場にニーズがあるということです。もし製品仕様として対応できる方法であれば対応させることでビジネスを拡大することができます。

一方で本当に使ってはいけない方法や環境で使っている場合、取扱説明書やパッケージに記載する注意書きの内容が不足している可能性もあります。修理対応の件数によってはその問合せ数に対応して取扱説明書に記載する注意喚起の書き方などをより分かりやすいように変更する必要があります。これらは製造物責任に関連する問題ですのでより注意深く対応します。

ユーザの使用方法や環境が問題ないのに故障が発生している場合、単純に設計上弱い部分が顕在化していることになりますので、市場での不良発生時は開発担当者や設計担当者にも必ず情報を共有し、組織的な改善活動を行います。

これらの管理内容に対応するためには企画時、開発時に適切に品質が設計されていなければ生産時、最悪の場合には市場に向けて販売を開始してから問題が発生した場合に、対応する方法がなく製品を回収(リコール)するしかなくなるというケースも考えられますので、注意しながら進めます。

出荷検査で不良がなくても良品率100%にはならない

今日はちょっと新入社員向けみたいな話です。

技術者であれば当たり前のことだと思うのですが、改めて確認しておきましょう。出荷検査で不良品が発生しなかったとしても良品率は100%になりません。特に日々大量に生産して大量に出荷するような量産品の場合は特にです(少量生産品で不良の程度が大きくない場合は手直しで使用可能になるケースもあるでしょう)。

「いや、今日出荷した分は全数検査して不良品0だったから良品率100%だよ!」

確かにそれはそうですが、その100%はその検査した対象に対してのみしか含んでいません。つまり、その部品・製品の生産において良品率100%を達成しているとは言えませんし、言ってはいけません。

仮にその製品の出荷検査は常に全数検査をすることになっていて、出荷開始から生産終了までの製品ライフサイクルのすべての出荷品に対して検査をすることになっているのであれば、生産終了を迎えて最終ロットの出荷検査が完了するまで不良品が発生しなかった場合のみ「良品率100%」と言って構いません。厳密には「良品率100%『だった』」と言わなければいけませんけどね。

本来であればこれは困るはずです。部品を納入することに対する保証ですので良品率100%は未来の話であってほしいからです。

・そもそもなぜ検査をするのか

検査をするのは不良が流出するのが怖いからです。逆に言えば、検査をするのは不良品が混入している可能性が0%ではないということであり、不良品の発生を認識しているということです。

「そんな、不良品がある前提で生産に取り組むなんて技術者じゃない!そんな品質の悪い会社には発注しない!」などとお思いでしょうか。違います。「人がやる事だから間違える可能性は常にある、だから検査をする。」というのが持つべき姿勢です。

本来であれば「持つべき」などという表現は使いたくないのですが、あえて使います。基本的に業務中は「ミスは発生するもの」、「事故は起こるもの」として扱うのが保証の基礎です。それをいかに影響のない範囲に抑えるかというのが品質の設計であり品質の保証です。

その影響の考え方が表れているのが抜き取り検査です。抜き取り検査はロットの一部を抜き出して検査を実施します。不良品の発生が認められれば次回以降の検査は厳しくし、不良品がない状態が継続していれば、検査の条件(抜き取り個数)を減らすなどしてコントロールします。

その程度はどの程度の不良率であれば許されるかで決まります。かつ、この不良率を上げることができれば検査数が小さくなる分検査が短縮できる上に、不良品が出荷数に含まれてもいいことになりますので生産コストが下がります。

・良品率100%は工程内で達成する

では逆に常に工程が流動するような製品の生産で良品率100%の達成は不可能かと言えばそんなことはありません。各工程内での不良流出を0にすれば不良品が出荷されることはありません。

ではどうすればいいのでしょうか。まず各工程内の工程能力を測定します。その工程能力が流動させる製品で要求される規格を常に満足していればいいはずです。更に加工精度が高く生産される製品が規格中央値に集中していれば工程の安定度は高いことになります。

更に量産中もその工程能力が維持されていることをモニタリングします。バラつきの発生要因になる加工工程で工程能力を満たしていることが実証できれば製品上は問題ないことになるからです。またロット間で中央値が遷移することがありますので、製品のバラつきが規格幅に対して十分であっても注意は必要です。

さらに言えば工程の変動要因を漏れなくとらえ、日常管理と日常整備で加工設備の状態を維持できればモニタリングが不要になるレベルまで工程能力が安定するかもしれません。このようにすれば全数に対して出荷検査をしないでも出荷品に不良がない状態を作ることは可能です。

特に他社や他工場に生産をお願いする際に私が特に注意して見ていたことは、一ヶ所の加工個所に対して一回の動作で作業が終了するかどうかです。

同じ個所を向きを変えたりしながら何度も加工しなければならないと、その分不良の発生確率が上がります。特に部材を持ち換えたり工具を取り替えたりするような段取り替えが複数回発生する形状で切削加工しなければならない場合などは、都度都度検査が必要になるなど手間がかかります。

そのような点も踏まえて生産に手間がかからない方法で部品や製品を設計できると品質の維持と向上につながります。

カン・コツを明文化する

以下の記事で、属人化した仕事を組織でまわすためにカンやコツまで明文化すると書きました。

組織を機能させるために必要な3つのこと

そのためのポイントを簡単にご説明します。

・ある人のカンが働くところは他の人が迷うところ

「カンがいい」ということは他の人のカンが働かないところでその人はカンが働くということです。ということは、その人しか気が付いていない視点や状況があるということです。同時に他の人は同じ状況になると迷ったり間違えたりするということです。

カンはその業務を継続して経験している人にだからこそ気が付く部分だったりしますので、その人が業務を遂行する際に注意していることや判断基準などを作成する帳票類に盛り込むことでカンを明文化することができます。

ここで問題があるのは、日常的にその作業をしている方はそのカンを含んだ行動そのものが普通になってしまっていることです。なので、自分が普段仕事をしているときに考えていることのどの部分を書き起こせばいいか気づいていないことが多いです。

その場合は一度本人が手順書の形を完成させ、内容を他者(理想的には上司)がヒアリングをする形で補足する箇所を指定するなど、漏れを極力減らす施策を講じる必要があります。この方法が成立するのは、カンが働くところは本人が必ずしも意識して行動していない可能性があるからです。一度本人が作った手順書を元に内容をさらっていくと、「ここはどうしているの?」と思うところや「こういう時何を考えているの?」と聞き取る側が作業手順に応じて条件分岐を想定して進めることで、その作業者独特の判断基準を拾い上げることができます。

・ある人が「コツがあるんだよ」というところは他の人にできないところ

コツが必要な部分というのはその人が仕事を進める中で「こうしたら上手くいくな」という全体の作業に大きな影響を与えないミクロの範囲でオリジナルの技術を開発して適用している箇所と言い換えることができると思います。

実はコツを明文化する際に「カンの明文化」とは少々異なる部分、具体的には明文化を進めようとする管理者を困らせる可能性がある部分をはらみます。「カンが働くところは本人が必ずしも意識して行動していない可能性がある」と上で書きました。しかしコツというのはその人本人が編み出した方法、開発した技術です。だとするなら、その自分しかできない技術や方法を易々と他の人に教えるでしょうか。

同時にカンと違いコツはどこで適用されるかがわかりません。ですので、コツを明らかにする際には 現場を見学し、作業している本人を観察するのが一番です。管理者の方は「そんな時間ない」と仰るかもしれませんが、そこは少しずつでも現場に出て作業の様子を見ることをお勧めします。コツを明らかにするために現場を見るということは、現場にいる現役の作業者の目線で見ることに他なりません。それは昇進する前のあなたの目線そのものですし、管理職の椅子に座ってから書類と打合せの日々だったあなたに作業者時代の感覚を呼び戻します。そうすると熟練の作業者が適用しているコツを見つけることも、そのコツをどのような時に適用しているかを理解することもより簡単になります。

本当にコツを明文化する必要に迫られたとき、その作業者の持つコツと仕事に対する姿勢を理解した管理者がそのコツを明らかにして職場に展開してほしい旨をその人に説明することがまず必要でしょう。そしてそのコツを明文化した後、仕事の仕方などをどのように変えるかも検討事項です。

この時の明文化の対象になる帳票はオフィスワークでも現場業務でも何らかの作業標準を作ろうと考えている職場であれば、作業手順書などがいいでしょう。

カンは代表的な作業手順書を改定する形で判断基準や方法や考え方を明記する形で対応可能になるケースがあるかと思います。

コツについてはその技術の内容によっては、特定条件下での作業手順として明確にするという方法があります。

これらの明文化によって得られる効果には以下のようなものがあります。
(1)作業者全体の方法が揃う
(2)熟練した作業者の考え方を展開できる
(3)スキルを明示できる

特に(3)のスキルを明示できることは人材育成の観点からもメリットが大きいので、できればここまで展開したいものです。

組織を機能させるために必要な3つのこと

「業務が属人化している…」という悩みを抱える経営者の方は多いかもしれません。 また、ある程度経験を積んだビジネスパーソンが「新しいことに取り組みたいけど今までやっていた仕事がいっぱいでなかなか手が出せない…」と思っていることもあるかもしれません。

いずれも「個人が対応することが慣例となっている業務を組織的に回せるようにフレームワーク化したい」というケースです。今回はそのために必要なプロセスを考えてみたいと思います。

(1)一般化

今あるタスクではどんな時にどんなことをしているか、顧客ごとにどう対応するか、社内の各職場向けの情報はどうやって作るかなど、個人のノウハウになっている情報はたくさんあると思います。それらを一つ一つ棚卸しして、状況別に仕分けます。ここは各個人の作業になりますが、ここである程度状況ごとに分類します。

例えば ある商品の 受注から発送までを行う作業があるとします。受注するルートはWebサイト、電話、小売店からのパターンがあるとします。Webと電話は個人への小売り、小売店の場合は小売店A社と小売店B社への卸販売だとすると、作業完了までに必要なタスクの並び方から4パターンの作業があることになります。

ここで仮に個人からの発注の場合は入金を確認出来てから発送するという条件にします。また取引が継続的にある法人の場合、請求は月でまとめている可能性もあるかもしれません。そうすると大きく流れは以下のようなものが想像できます。

1-a1. Web受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送
1-b1. 電話受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送 
1-c1. A社から受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求
1-d1. B社から受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求 

ここでの仕分け作業は、実際にタスクにあたる時にタスクの条件と照らし合わせて今後の対応の場合分けをする際に必要な情報となります。

その仕分け作業が済んだら、それらの中から固有名詞や特定の商品名や限定される条件を取り除きます。それによって一回り大きな情報で整理されます。例えば上の例で言うと、「A社から受注」「B社から受注」は卸売りという行為にまとまりますし、Webと電話は個人からの受注として扱うことになるかもしれません。

それらをまとめ直すと以下のように2パターンの業務フローがあることになります。

1-a2. 個人から受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送
1-b2. 卸販売の受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求

もしここでWebや電話での受注の仕方に更に細かいルーチンワークがあったりする場合は、個人向けとまとめずに別で分けたままパターンを考えた方がいいかもしれません。それはタスクの内容と実施状況によります。

この作業のパターンが作業工程(作業プロセス)になります。

(2)標準化

続けて一般化した作業工程の中に存在するタスクに誰でもわかるようなスタートとゴールを作ってタスクの標準的な処理の方法を作ります。

上記の例の中の「在庫確認」というタスクを見てみましょう。在庫確認は受注した数量が現在在庫として保有しているか確認する行為です。在庫を確認し、発送する数量をピックアップすることが在庫確認のタスクになると思います。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c. 必要な数量の商品をピックアップする

しかし、在庫確認の際に発生する行為はそれだけでしょうか。仮に商品が発送するのに必要な数量なかったら購入品であれば取り寄せる、自社で作っているものなら工場で生産する必要があります。ということは2-b1で数量を確認した結果によって2-cが2つに分かれることになります。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c1. 必要な数量の商品をピックアップする

2-c2. 数量が不足する場合は発注(生産指示)処理をする

更に2-c2には続きがあります。出来上がった製品が倉庫に納品されるのを待たなければいけません。この場合、発注したお客様にはお待ち頂く事になります(ここではWebや電話で受けた個人のお客様の注文ですから、Web上の注意事項や電話口などで在庫状況によりお待ち頂く旨をお伝えするようにします)。

その場合、発注した商品の入荷、倉庫への入庫(在庫数量が復活)が行われ、その上で必要な数量のピックアップが可能になり、梱包と発送処理の工程へと進みます。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c1. 必要な数量の商品をピックアップする

2-c2. 数量が不足する場合は発注(生産指示)処理をする
2-d2. 商品入荷の報告を受ける
2-e2. 商品を倉庫に納める(在庫が復活する)
2-f2. 必要な数量の商品をピックアップする

このように作業を標準化する過程ではだれでもわかるような説明の仕方で、タスクの処理中に発生する可能性があるイベントについて条件分岐を作成します。

その各条件に対してゴールを設定します。ある作業プロセスの中に存在するタスクなので、分岐してもゴールは同じところに 戻ることは多いですが、そうではないケースが発生する可能性がないか注意して検討する必要があります。

そうではないケースの典型的な例は、倉庫に在庫していたはずの商品の扱いが終了していた場合などです。その場合はお客様から受注する前に受注窓口をクローズします。すでに受注した後にその注文に応じることが不可能であることが発覚した場合は速やかにお客様に連絡した上でクローズと返金処理をしますので、商品のライフサイクルと販売期間終了時の取り扱いなども検討しておくべきでしょう。

(3)明文化

ここまで検討して明らかにした作業の内容は口頭での周知で終わらせてはいけません。全体を通して作業プロセスを記載した作業工程表、各タスクの内容と判断基準を明記した作業手順書、手順通りに実施していることを継続管理するための管理表や管理チェックシートを作成します。それらを作ったら、それらの帳票類の適用範囲と保存期間を決めておきます。

【作業工程表】
ある作業がどのようなタスクで構成されているかわかるように記載した表。その作業が何のためにあり、何をトリガーにしてスタートし、何ができていれば終了なのか明示する。各タスクはどの作業手順書を見ればできるのかがわかるように、作業を構成するタスクに対応する作業手順書の書類番号を記載する。

【作業手順書】
作業の中の各タスクで必要な行動や処理、判断が必要な場合の判断基準などが分かるように記載する。各タスクの開始条件や終了条件も明示する。判断基準にない状況が発生した場合の報告先を記載して、非常時対応が可能な状態にしておく。
作業手順書は写真や図などを含めてわかりやすくし、説明は手順を追って箇条書きにする。判断基準は複合して発生しない条件が望ましいが、どうしても複合してしまう場合は、判断基準に対しても場合分けをして条件が分かるようにする。

【管理表、管理チェックシート】
タスクを実行する中で継続的に確認しなければいけないこと(上記の例では在庫の数量など)はタスクを実行するたびに確認し、確認結果を表やチェックシートなどにして残す。在庫の数量でいえば発注日と発注数量を管理すれば在庫を消化する期間の把握ができる。

これらを実施しておくことで、担当者が変わった場合やメンバーが追加された場合に経験者が帯同する時間を短くすることができたり、判断を間違うケースが限定されたりします。

また明文化して残す際には必ずその職場のベテラン職員の意見を求めたり、その方の仕事の仕方を取り入れることを検討すべきです。なぜならベテランの業務にはその作業を行う中で積み重ねた工夫や、身体に染み付いたカンやコツが含まれているからで、それらは必ずその方と会社にとって付加価値になっているはずだからです。

付加価値を生むことができる条件を他のメンバーにも共有することが組織として付加価値を生み出す可能性を引き上げます。


この3つの作業を日常業務を行いながら実施することはかなり困難ではありますが、価値を継続的に生むためには不可欠なことですので、少しずつでも推進することをお勧めします。

プロダクト品質を形作るもの

多くの場合で「品質」という言葉が使われるときは出来上がったプロダクト(商品や製品、システム)の品質を指すと思います。

しかし業務の中で関わる品質は品物の品質を意味するプロダクト品質だけではありません。その製品品質を作る上で業務上影響する品質について簡単にお話しします。今回は大きく以下の3項目に対してご説明します。

・ドキュメント品質
・プロセス品質
・オペレーション品質

実はこれらは特にIT関係のシステム開発業界などでは頻繁に聞く用語だったりもしますが、製造業、特に今後自社で製品開発をしたい企業には参考になる部分も大きいので、製造業目線で書いてみます。

(1)ドキュメント品質

業務中に作成されるドキュメント(書類)の品質を言います。

・必要なことがもれなく書かれているか
・体裁や項目が統一されているか(毎回書かれることが違っていないか)
・読みやすい書き方になっているか
・(図面などは)書式が間違っていないか

業務中に確認するための文面だからこそ統一しておいた方がいいこと、抜け漏れが後の作業に影響することなどが多くありますので、社内で各担当部署、各プロセスで必要な書類と項目の取り決めなど、必要なことが多くあります。

(2)プロセス品質

プロセスとは生産工程ではなく新しい製品の開発プロセスのことで、ドキュメントや作っているプロダクトの状況を作り込みの各段階に応じて確認と検証をしながら作り進めることを考えます。顧客との仕様書や図面のデザインレビューなどに臨んだことがある方もいらっしゃるかもしれませんが、それらの位置づけや内容などはプロセス品質として考えるべきものになります。それ以外でも検証用の評価内容のレビューや、評価結果の報告と状況確認などもあり得ます。

ゲート管理などの方法を取り入れている会社さんもいらっしゃるかもしれません。作業と確認を組み合わせた業務の進め方そのものがここでのテーマになります。今までお伺いした会社さんでお話を聞いている限り、前工程への差し戻し条件や次工程への進行条件など、各社の進め方や考え方が出やすい部分でもあるように思います。

(3)オペレーション品質

各プロセス内での作業そのものの品質のことを指します。製造業であれば加工だったり組立作業になりますが、作業の品質が低いと当然ですがプロダクト品質は落ちます。

しかし開発中の製品の場合、必要な作業そのものが何かがまだ明確ではなかったり、今までにない新しい作業を導入する場合には担当者が作業に不慣れな状態だったりして、オペレーションの品質がそもそも低いことがあり得ます。

その場合は工程設計のための工程開発プロセスを製品開発のプロセスと同時に立ち上げ、作業者の人材育成とスキルマップの作製などを同時に進めた方がいい場合もあります(具体的なタイミングについては開発中の製品と作業内容によりますので詳しいご質問はお問合せにてお受けします)。

特に製造業の場合は量産時の品質安定が課題になります。工程設計のタイミングでは加工や組立ての量産バラつきを測定することも必要です。作業者の工程能力にあった製品設計になっているか、または作業者の工程能力を上げることができるかが検証ポイントになります。



如何でしたでしょうか。製品開発に取り組むとき、または自社の業務を見直すとき、品質は見直す目的であると同時に観察、計測する対象にもなり得ます。

これらを組み合わせて構築された業務でプロダクト品質は構成されますが、製造業の場合、実際の加工や組み立てでは量産バラつきが発生しますので、これらを意識しながらプロダクト品質を作り込むことを忘れないでください。