攻めの品質保証へ -1

今、新製品を企画して思うこと。の記事の中で以下のように書きました。

現時点では目的を達成できる最小限の仕様と構造を検討し、ユーザに要求するオペレーションもシンプルに目的が達成される使い方を提供すべき

今、新製品を企画して思うこと。

また別の記事では品質は開発の初期段階から積み重ねることもお話ししました。

品質が定義できないのはそもそも初期段階で目標が決まっていない、つまり製品が社会に与える価値が見えていないということ

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

逆に、この2つを抑えると、過去に類似製品の開発経験がない(アップデートの形式ではない)製品の開発についても、アプローチしやすいハードウェア製品の開発プロセスが作れるのではないかなと思っています。

今回は、2019年9月現在弊社で開発している製品で対応している方法を踏まえてお話ししたいと思います。

・新規の開発はわからないことだらけでもお客様のことを考えて

今までに自社内のみならず社会的にも開発実績のない製品というのはわからないことだらけです。そもそも「 社会的にも開発実績のない製品 =社会に存在しない製品」ですから、それというのは作れないか、欲しい人がいないかのどちらかだと思うのが普通でしょう。

本当に新しい製品で市場があるかどうかわからないレベルの物であれば、企画上中心になる機能などでサンプル品や簡単な調査などを計画して、一部のユーザを対象に意見を募った程度の情報しかないこともあります。そのような状態だと中心機能以外はどうしたらいいかとか実際に購入したお客様はどんなところでどんな使い方をするかとかの情報はまだ入手できません。

ですので、昨日達成する最低限の仕様を設定します。その状態ではお客様が実際に製品を使うときに行う行為をできるだけコンパクトにしてわかりやすいようにします。それによってお客様がスムーズに使用状態にたどり着けます。今までにない製品であればお客様は使うのが初めてですから使い方がシンプルでないと対応できない可能性があります。また、説明書は必ずつけます。そこには使い方もそうですが、まず製品仕様上絶対にやってはいけないこと、やってほしくないことの記載が必要です。

ユーザは必ずメーカの想定外の使い方をします。想定外のことなのでどんな使い方をするのかは実際にそういう使い方をして起こった故障品を見たり、実際にクレームを受けてみないと分からないのですが、どういうときにどういう故障が起こる可能性があるのか、それによってお客様にどのような不利益があるのかは説明書に記載が必要です。

・開発を最短距離で実施する

試作品をできるだけ早く作り機能検証をすること、実際に量産用の部品形状を早めに確定し組立ての仕方や梱包の仕方を確認することがより早い段階で必要です。ここが遅くなるとリリースのための検証が遅くなります。

開発上のポイントは機能開発と製品開発を分けることです。機能が実現できるかどうかと、その機能が製品に実装できるかどうかは別の問題だからです。また、実装できるかどうかとそれを組み立てる工程が成立するかどうかも別なので、厳密に言うと工程設計も別に必要です。下の図のように、必要があれば工程設計の段階で生産技術開発も実施します。

矢印がそれぞれ途中から始まっているのには理由があります。できるだけ早く検討は始めたいものの、機能の開発がある程度進まないと製品に乗せられるかわからず、製品のイメージが固まらないとどう組み立てるかも検討できません。一方でそれぞれの仕事が終わってから次に進むのでは遅すぎますので、ある程度のタイミングまで前倒します(フロントローディング)。

この時、何機種か製品を開発していると、どのような状態になったら次の段階に進めるかがわかってきますので、次の段階に進む条件を定義します。そうすると自社にとっての開発プロセスが定義できます。

・評価は検討できる最小限でもいいからする

上記の使われる範囲の制限を設定すると、その周辺の使ってほしくない条件が出てきますので、それらの条件で評価用の試験を検討します。新規の試作品だと台数も作れず破壊ができないので、実施するのは後回しになると思います(試作品を壊してしまったら他の確認ができませんので)。

簡単な製品だとそんな評価なんてする必要ないと思われる方もいるかもしれませんが、全く評価が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)オペレーション品質

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

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

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

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



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

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

品質を保証するということ

品質に関わる職場にお勤めの方は多くいらっしゃると思いますが、ご自身の部署のお名前は何でしょうか?「品質管理」でしょうか。「品質保証」でしょうか。もしかしたら「検査」という名前がついているかもしれません。

ちなみに、お勤めになっている企業ではどのような業務を行っているでしょうか?顧客から図面や仕様を受け取り加工したり実装したりして納品している企業は多いかもしれません。中には自社で企画し、提案・受注している企業もあるかもしれません。もしかしたら主な顧客は一般ユーザで、自社で企画、開発した製品を製造して販売している会社にいらっしゃる方もいると思います。

これらはどれも似ている言葉のように聞こえますが、違う意味を持ちます。特に組織の中で要求される要素としては大きく違う意味を持ちます。今回は簡単にそれらの違いを確認しておきたいと思います。

・管理と検査

検査とは決められた検査項目に対して検査基準を満たしているかどうか、対象物(出来上がった製品など)の合否判定を下すことです。検査でわかるのは検査基準を満たしてるかどうかのみです。検査をする前に、検査をする項目と検査基準を決めておく必要があります。

そして管理は検査項目と検査基準に対する検査結果の変動を管理します。工程内検査や日常管理の状況を把握して、基準値から逸脱もしくは逸脱する可能性が見られたときは改善活動を実施して、安定状態に戻るようにします。

根本的な管理と検査はこのようなところで、多くの企業や業種でそれぞれのやり方があるでしょう。特に製造業関連では日常管理や検査データなどを顧客企業から求められている方も多いと思うので、より業務の中で取り組まれている方は多いと思います。

・管理基準はなぜできるか

ではそれらの管理基準はどのように作られるのでしょうか。そもそもそれらはなぜ管理しなければいけないと考えられているのでしょうか。

部品などを加工して納入している製造業などの業種の方は、顧客企業からオファーがあった時「ここの部分をこうしておいてほしい」とか「これは相手方の部品とここであたるからこの部分は精度を高く」とかいうオーダを同時に受けていると思います。

これらはみなさんの顧客である完成品メーカの設計者が製品設計をした時に「そこを管理するべき」であったり、「ここを部品の機能上このように使う」などと考えて作っているわけですが(加工方法と部品設計がマッチしていないケースが多いといわれる加工業者さんも多いかもしれませんが…)、そもそもその製品が図面になるまでの過程があります。

その過程を開発中と仮定して大雑把に書き出すとこのようなります。

 商品企画 → 要件定義 → 仕様 → 製品設計(ここで図面化)

そしてそのあとも、

 部品検査 → 組立(工程設計)→ 評価 → 量産性検証 → 量産可否判断

という流れを追います。その結果として、販売できる商品としての形になるわけですが、ここでそもそもの商品企画の中で達成したい目的(商品を販売することで提供できる価値)を実現するために、要件が定義され、仕様が決定され、製品が設計されます。

つまり、加工段階まで形になった部品というのは組み込まれる製品を通して価値を社会に届ける使命を帯びています。そしてその使命は品質管理と検査として、部品加工を受注した企業に対して要求されます。

・品質保証が保証するもの

完成品メーカの品質保証担当者はよく「最後の砦」的な表現をされますが、それはあまり正しくありません。なぜなら上記の開発プロセスにある工程すべてに品質に影響する要素があるからです。

要件定義で定義されているべき価値を実現するための機能に曖昧さがあれば仕様の精度が上がりません。仕様の精度が上がらなければ製品設計時に不確定要素が入り込みます。設計上の不確定要素は管理項目の定義ミスや工程設計への遅れ要素となります。当然評価するべき機能の実現も怪しくなります。

部品加工時に完成品メーカの品質保証担当者が話をしているのは部品の寸法精度とその管理の話だけでも、実はその先に製品への影響と、社会へ提供できる価値の話が含まれています(品質保証担当者の仕事はもちろんそれだけではありません)。

翻っていえば、今まで受託でのビジネスしか行っていなかった企業が自社の企画を立ち上げ、直接社会に対して製品やサービスを立ち上げる際には、今完成品メーカがやっていることと同じことは最低限考えるべきことです。

それが「品質管理」から「品質保証」へ移行する第一歩となるでしょう。