発注と品質保証

「自分にできないから誰かにお願いしよう…」と思うことはよくあると思います。製品開発でも、自社で対応できない加工方法や部品の制作や生産はどこか対応可能な工場にお願いしようとするのが普通だと思います。この時「きちんと作ってくださいよ!」と思うのは誰でも同じだと思います。しかし、何をもって「きちんと」しているというのでしょう。

今日は製品を生産する上で「きちんと」するために必要な確認事項などのご説明をしておこうと思います。

・製造条件の4M

4M管理というのは製造業にお勤めなら聞いたことがある方は多いのではないでしょうか。その4Mの内容と確認事項を簡単におさらいします

  1. 作業者   :Man
  2. 治工具と機械:Machine
  3. 材料    :Material
  4. 方法    :Method

1. 作業者:Man

一つ目はMan、つまり作業者や人材のことです。工程内で作業する作業者が変わらないことを意味しますが、同じ人物が休憩も取らず帰宅もせず長期休暇も取らないで常に業務にあたることは不可能ですので交代は必ずあります。ですので、人材はスキルで管理します。

  • スキルマップやスキルチェックシートがあるか
  • スキルマップやスキルチェックシートの内容が適切か
  • スキルマップやスキルチェックシートの管理方法は定まっているか
  • 作業者が交代しても必ず同じスキルレベルの作業者があたるように管理されているか

生産をお願いする企業にお邪魔した時は、そのような管理がされているかを確認し、可能であればスキルマップやスキルチェックシートを見せてもらいます。

2. 治工具と機械:Machine

次は道具と機械です。「この加工にはこのような機械を使います」というだけでは不十分です。私が自社、他社を含め確認するポイントを今(目の前に部品や機械がない状態で)思いつくだけ簡単に挙げてみます。

  • 機械にセッティングする治工具やアタッチメントの種類
  • その摩耗度や交換時期の管理
  • 機械の設定条件
  • 設定や工具の変更対応の方法
  • 使用方法等の手順書の整備(機械の操作盤等に使い方が書いてあるか、それ以外に作業手順書があるか)
  • 故障時に代替できる機械や方法の有無
  • 日常管理が行われているか(適切な管理スパンを把握しているか)、管理方法は定まっているか
  • 上記のものがない場合にそれを補完する経験や方法の整備があるか

生産する部品や使用する機械を定めていないので一般的な部分ですが、その道具や機械など生産設備に関連する部分に対して重点的に整備します。1のManと重なる部分もありますが、オーバーラップしても構わないので必要と思われるものは全て確認します。

3. 材料:Material

材料は製品そのものに組み込まれる一部になりますので非常に大事なものです。ですので、同じものが使われるのが前提ですが、この時に同じと思いながらも同じではないことが起こり得ますので、確認は必要です。これも一般的な範囲のみですが例を挙げてみます。

  • 材料の種類が変わってないか
  • 材料の種類や商品名が同じでも成分の変更がないか
  • 材料の生産工場の変更がないか
  • 材料の製造メーカの違いがないか
  • 使用する予定の材料以外の混入がないか
  • 材料の入荷時期の管理はされているか、管理方法は定まっているか
  • 材料や購買品の受入検査をする場合の検査方法とデータの管理はされているか
  • 副資材の仕様予定の有無
  • 副資材の追加や削除がないか

材料については同じ商品名や種類であれば大丈夫だろうと思われるかもしれませんが、材料の種類とメーカによっては成分の変更が発生する可能性があるので注意が必要です。特に塗料や潤滑油などはモデルチェンジで使い勝手を向上させたりすることがあり得るので、変更が入りそうなものは製造元に確認するなどします。

もし製品の輸出などを検討している場合は製品に含まれる物質に対して環境規制対応の確認が必要になります。RoHS指令やREACH規則などは聞いたことがある人も多いかもしれませんが、各国がそれらを元にして独自の規制をしいているので輸出先に関して調査しましょう。

確認の参考になるサイトをリンクしますので参考にしてください。

ここが知りたいRoHS指令 – J-Net21

ここが知りたいREACH規則 – J-Net21

4.方法:Method

ここでは製品の生産に関わる全ての方法について確認します。

  • 加工方法
  • 各工程の治工具や機械の扱い方
  • 各工程での帳票類や書類の管理方法

加工方法はもちろんのこと、道具の管理の仕方や書類の管理の仕方も漏れがあると生産に影響します。特に書類は組織で業務にあたる以上、複数の人が対応するのになくてはならないものなので、存在するのか、内容に必要な物が含まれているか、更新が必要な場合に更新されるなど管理されているかを確認します。

製品の生産をお願いするということは常に同じ製品が納入されることを期待するわけですから、それそのものが品質が安定していることを要求しているということになります。

工業というのは再現性を確保したものであると「ものづくり」の3ステップでお話ししました。

工業における最大の価値は組織化された生産プロセスによる量産性の高さと 再現性の高さ(品質の安定)です。

「ものづくり」の3ステップ

この「再現性の高さ」とは「同じ材料で同じ道具を使って同じやり方をしてれば同じものができるはずだよね?」ということに他なりません。

すなわち製品を発注するということは「この材料を使って作ってほしいのですが、どの道具をどういう風に使って、どうやって管理しながら作るんですか?」ということであり、生産が開始されたら「最初に聞いたようにこの材料でこの道具をこうやって使いながら、日々管理して生産してるんですよね?」ということになります。

「管理図を書いています」とか「工程能力が高いです」という説明を受けることがありますが、工程能力や管理図などは管理方法や管理対象にすぎません。工程能力がいいからそれでいいわけではなく、「何をどうやって管理するか」が決まっていないと意味がありません。そのすべてにわたるプロセスを維持してこそ初めて品質の維持が可能になりますので、忘れないでおいてください。

攻めの品質保証へ -1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

簡単な製品だとそんな評価なんてする必要ないと思われる方もいるかもしれませんが、全く評価が0の状態で試作を終了するというのは考えづらいです。使用環境や使用条件が考えられる以上、その条件での動作耐久試験など、何らかの方法はあるはずです。

そして何らかの評価は必ず実施しておくべきです。なぜなら、販売後に市場で不具合や品質事故が発生した場合に、試作品でどうなっていたかを後から確認することは不可能だからです。逆に試作品の時点で確認できている不具合が販売後にも発生しているのであれば、試作時の対策が不十分だったことが考えられますので、対策を打つべきポイントを見つけるのが早くなるなど、クレーム対応や在庫商品への対応が早くなります。

企業は製品と通じて社会とかかわります。ということは製品の品質のうち ユーザから見える部分とは、企業が社会に訴えかける主張の部分になります。そこで可能な限り不備なく、また余剰のない開発リソースを無駄にしないような開発プロセスの構築を目指すことを考えるべきなのだと思います。

カン・コツを明文化しないと、カン・コツの要らない世界になっちゃいますよ?

カンとコツの明文化についての話に対してあまり積極的に話したがらない人がいます。なんででしょう。自分でやってることをうまく説明できないのでしょうか。それとも自分だけのものにして有利な立場に立ちたいのでしょうか。いずれにしてもビジネスは競争ということを考えたらある程度意味のあることではあります。

技術を公開する方法としては社内であれば手順化、社外であれば特許などの方法が考えられます。一方で自社固有の、特定個人の技術として非公開で使い続けて優位性を保つという選択肢も実際にないわけではありません。しかし、技術の公開をしないともしかしたらよろしくない方向に事態が動くかもしれません。

例えば「なんだ、教えてくれないのか…」といって人が離れていきます。しかもそれだけではありません。「教えてくれないなら自分達で代わりのものをつくればいいか」と言って、入手できなかった技術を代替するものを作ってしまうかもしれません。

そうするとどうでしょう。自分が圧倒的に強みを持っていたはずの分野で、他の人がもっと低い性能で作った製品が、自分達の製品以上にもっと受け入れられてしまうかもしれません。自社内でコツを共有してできる人を増やしていれば、社内の生産効率が下がって、自社で販売している製品のシェアを落とさずに済んだかもしれません。

技術というものの大前提ですが、古い方法や製品は新しいものが出てきたら淘汰される事が少なくないということがあげられます。新しい製品が行き渡り、社会の中に浸透しても生き残るものもあります。しかし、特に工業の世界において以前からあるものは完全に淘汰されるか、それを使う意味がある領域にのみにしか売れなくなってしまいます。

コツを明文化して共有すれば常に市場で圧倒的なポジションを取れるという意味ではありません。それでもコツを明文化して共有することで対応できる人を増やし、組織全体の効率を上げることには意味があります。コツを産み出した能力の高い人に次のステップに進んでもらい、新しい方法や技術を産み出してもらわないと、自分達の技術の存在価値、ひいては自社の価値を維持できない可能性があるのです。

そのようになる前に、自分の中にあるものを明文化し自社固有の技術の効率を高めたり対応できる人数を増やして、次のステップへ行きましょう。

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

今、新製品を企画して思うこと。の中で以下のように書いた部分があります。

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

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

これは企画者が考えるべきことじゃないのか?と思われた方、正解です。そして、まだ企画段階だから品質保証の出る幕じゃないと思われた方、不正解です。

・企画を考えた段階から品質を考える

品質保証を実行できるようになろうとした場合、ここで「企画者が考えているから」で放っておいてはまずいことがあります。それはなぜかというと、企画者がそこで何を考えているか、そもそもマーケティングデータでどのようなデータを見ていて、なぜその考えが商品になるといいのかというポイントがそこにあるからです。

逆を言えば、その考えが商品に入ってないと商品をリリースする意味がないということになります。商品企画とは、その商品をリリースする意味の原点であり、それを元に要件定義や仕様が作られます。仕様になったものは図面化され、実際の品物になります。

つまり、最初に企画上の意図や意味だったものが、仕様により性能化され、図面上の管理ポイントに落とし込まれます。品質保証はこの段階を追っておく必要があります。もし仕様に不足があれば実際に図面になったり試作品を作った時にミスが発覚し、設計変更になります。

更に恐ろしいのは量産性を確認するための評価に移行し、試作品の台数を増やした時です。例えば、試作品の数台での評価では何も問題なかったはずが、量産性確認のために台数を増やしてみた途端、 性能を満たさない個体が多数発生してしまったとしましょう。検証の結果、量産工程の組立て時の工程能力では性能を達成する組立てができないとなってしまったらどうでしょう。その仕様は量産条件に合わなかったということになり、仕様設計までさかのぼる必要が出てきます。

こうなったらほぼ作り直しと同じことになり、予算が更にかかる上、発売時期が伸び開発中の製品で売り上げが立つタイミングが遅れます。開発で工数がかかりますのでその製品で利益を出すハードルは更に高くなります。実際に自社で製品を企画・開発・生産している完成品メーカなどの製造業はこのリスクに常にさらされます。

・そもそも論を歓迎する

もし開発が進捗してから問題が起こった場合、上に書いたように大幅なコスト増になることがあります。それを避けたいのは当然なので、詳細の原因究明をして、手戻りが最小になるようにするのですが、 本来は 最小にするための努力は初めから必要なところを明確にして確認を重ねていれば済むはずです。ただ、漏れがない仕事をすることが不可能なのも現実です。

また、ここで手戻りを少ないからということで、上に引用した「 目的を達成できる最小限の仕様と構造を検討 」し直そうという話になるかもしれません。この時よく起こるのは、手戻りを最小限にすることが目的にすり替わることです。そのために企画で決めた目標を下げるということが検討の選択肢に入ってくるかもしれません。

現実的な話にしてリリースを目指すのも方法の一つですが、ここで必ず確認しておかなければいけないのは「自分たちはそもそも何を作ろうとしていたのか」「変更後の目標で最初に企画した時の目的は達成可能なのか」を検討することです。リリースすることは大事ですが出して意味のない製品になるのならば、開発を中止した方が余計な予算を消化せずに済みます。

また、そもそも実はユーザの使用条件に対して 企画立案時や仕様検討時の内容に抜けや漏れがあったという可能性もあります。 開発が進むにつれてより具体的に製品の形が見えてくることで見えてくることもありますが、企画立案時の製品の概要や性能が使用シーンに合ってないのであれば企画の見直しが必要です。企画者が抜けもれなく仕事をしている保証はありません。また企画者には可能な限り具体的な使用シーンがイメージできている必要があります。

・初期から品質を定義する

組織として開発に際して注意することは適正なコストを投下して適切な結果を得ることです。その適切な結果とはユーザへの価値提供であって、製品のリリースではありません。品質が定義できないのはそもそも初期段階で目標が決まっていない、つまり製品が社会に与える価値が見えていないということなので、その開発自体を見直す必要が出てくるかもしれません。

品質はユーザに関連する部分以外にも多くあります。次機種の開発で使用する可能性のある機能や要素部品、生産工程の効率化に必要な要素などにも品質の定義が必要です。しかしこれらは製品の形が具体的になるにつれて検討の必要性が増してくるものでもあります。言い換えれば開発が進み具体的な話になればなるほど初期に決めた大きな要素の変更が困難になります。

開発開始時における品質とは、その製品を通じて達成すべき目的を定義することそのものです。

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

実は弊社では2019年中のリリースを目指して現在映像関係の新製品を企画中です。詳細はまた別途コーポレートサイトとブランドサイトにてお知らせしたいと思いますが(こちらでも何らかのご連絡はしたいと思います)、改めて自分で試作(というか工作?)したり、製品企画したりしていると、製品化と事業化の難しさと同時に心の底から楽しさ沸き上がってくる感じがします。

・その製品は使っていて楽しいか

B to C製品だったら主に使うのは個人のお客様です。仮にお仕事で使うとしてもオペレーションするのはお一人でしょう。そんな時でも、私は使っていて楽しい製品が作りたいなぁと思います。使っていて楽しいとは、(1)その製品に触れているとき(2)その製品を使っていて得られる結果が楽しい のどちらかは最低欲しいと思います。

(1)の場合は製品の出来がよくて、触ったり操作したりが心地よかったり、見た目がカッコよかったりして見てると嬉しくなる、などがあると思います。他にも操作している中で、目的の昨日の面接の至るまでの操作が合理的で使いやすいなども、使用時のストレスの軽減のみならず使ったときの楽しさにつながるんじゃないかなと思います。

最近の製品でそれを実現できているのはやはりiPhoneでしょう。最近は賛否両論聞かれますが、それでもApple製品とその中でもiPhoneはOSまで含めてですが洗練された使い勝手という点で特徴があるように思います。ちなみに筆者はWindowsとAndroidユーザなので厳密には知らないんですが。笑

(2)はまさにこんなことができる、あんなことができるというような機能の部分です。その部分が製品の本質で買う理由でもあるのでとても重要なのですが、その中でもある程度機能のバリエーションがあったり、これは場合によっては機能の制約条件だったりもします。 製品によっては(1)と複合するものもあるでしょう。

例えば、初心者向けのカメラなどは「スポーツモード」や「夜景モード」など、これを使えばそのシーンが上手に撮れそうな名前がついている機能があります。あれはカメラの露出制御を、そのシーンを撮る時に使われる設定値以外は設定できないようにしています。これは(2)のアプローチで、初心者のユーザが困らないようにしているわけです。

・その製品は作っていて楽しいか

作り手にとって、製品を作ることは楽しいことです。ただ作り進めていく中で考えるべきこと、自社でできないことが必ず出てきます。実は今の私もそうです。正直その事実に行きあたると気分は重くなります。でもこの時、自社でできないから、やり方が見つからないからやらないとするのはやっぱりもったいないと思います。

何か一つでも成立する方法があればそれで一度実現させてみる、ユーザにとってもっといい方法があるかもしれないと思うかもしれません。もっとカッコいいものになるはずだと思うかもしれません。同時に作る方にももっとシンプルな物、性能を保証しやすい加工方法などを考えなければとプレッシャーを感じます。

もっと良くするべき、良くできるはずという気持ちはよく理解できますし、筆者もそうしたいと思う人間です。でもそこで一度立ち止まることも必要なように思います。特に今まであまり製品として存在しないニッチな物、新しい物であればあるほど、完璧主義に近いこだわりは機会損失かも知れません。まず新しい価値を早く製品を通じて体現し社会に問いかけることで、ユーザにその価値を届けることができます。

そのバージョンアップやモデルチェンジを前提にした構成や構造がもし検討できるなら、実はその方がいいかもしれないのです。最初の製品の開発初期の段階で考えることを止めていいということではありません。現時点では目的を達成できる最小限の仕様と構造を検討し、ユーザに要求するオペレーションもシンプルに目的が達成される使い方を提供すべきだと思っています。

筆者は品質保証の業務経験がある機械系エンジニアですが、品質保証の人間がこんな割り切ることを是とするようなことをいうイメージは日本の製造業の方には少ないかもしれません。でも私が本当に製品開発でおもしろいと思っているのは、企画が技術的に達成可能であるかどうか、それを自分が扱いきれるかどうか、ユーザに提供する形にパッケージできるかどうかの3つがバランスして「これしかない!」と思える形に収まる瞬間がものすごく好きだったりします。

実現しなければいけない価値を実現するのがエンジニアリングであるべきなのですが、それが必ずしも達成できない場合には次の落としどころを探らなければいけません。その次の落としどころを探る行為が上記の3つのバランスを取ることだと思うのです。

全ての製品開発には困難があり(新しいことをしているのですから当たり前です)、それを何らかの形でクリアしなければいけないならば、その困難を乗り越えるか、できないなら回り道を見つけるか、何かをしなければいけないのです。

その何かが見つかった時が自分にとっては至上の喜びであり楽しさです。

そんな風に、作り手にとっても使い手にとっても楽しめる製品を作り、作り手も達成感を感じ使い手も新しい道具を手に入れた喜びを感じられるビジネスがしたいなぁと思います。

カン・コツを明文化する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「来ればわかる」「使えばわかる」じゃわからない

先日、生で音楽を聴く機会がありました。その時、出演者の方は自分の出番が終わった後、本当に謙虚に会場にいるお客さんと言葉を交わされていました。私も簡単にご挨拶しましたが、「来てもらえて、聞いてもらえることがありがたい」という気持ちは嘘ではないでしょう。

過去に私が書籍に挿入される写真を撮影した際、出版記念イベントに招待され、簡単に撮影の内容などをお話ししたことがありました。その後、懇親会のような形になり、著者が他にいらっしゃるその会で私の出番はほぼ終わったようなものだったのですが、その中でも少なからず写真の撮影者ということでご挨拶に来て下さる方がいらっしゃいました。
「写真がよくて 『 誰が撮ったんだ?』と思った」とか「 本を読む上で写真の雰囲気も背中を押してくれた」とか仰って下さる方がいらっしゃったんですね。

・聞いてない人、見てない人は買わない

当然のことではあるんですが、そのアーティストの曲を聞いたことがない人はその人の他の曲やコンサートチケットにお金は払わないんですよね。私の写真を見たことがない人も、私の写真を見るまで、掲載された本や作品を買おうとは思いません。

つまり何らかの形で知ってもらわないことには購入に至らないことになります。ですのでAmazonなどの通販サイトでは商品画像を掲載したり、書籍の中も一部公開したりして購入の判断をしやすくしています。実際「Amazonで公開されていた写真のページが素敵でした」と仰って下さった方がいらっしゃいました。私の写真が購入の理由の一つになっているとのことで、とても嬉しいことですね。

これらがない状態で「買って下さい」ということは、事実上道端でチラシを配ってるのと大して違いがありません。興味も関心もない不特定多数の前で商品の名前を叫ぼうと、誰も聞いてくれません。

人が自分の商品や自分が企画したものを知ってもらいたいと思うとき、 それでも案外多くの人が道端でチラシを配ろうとします。その人が道端で配っているチラシもティッシュも受け取ったことがなくてもです。

・無料サンプルが次の一手

「だったら使ってもらおう」ということで多くの人が無料サンプルをチラシに付けたりします。それでも興味も関心もない人には使う理由がありませんので、チラシと一緒に捨てられます。

だったら、圧倒的に使う理由がある人のいる所で配るのが得策だと気が付きます。もうチラシの時点でお気づきかもしれませんが、無料サンプルを付けたらその意味はチラシだけより大きくなります。

だから世間では量販店の類似商品売り場でサンプル試用ができたり、キャンペーンイベントを開催したりしているわけですが、完全に個人もしくは中小企業でそんな広告費を掛けられない、掛けたところでそもそも自分たちのことを知ってる人がほとんどいない人はどうしたらいいでしょうか。

・本当に「友達だろ?」というべきとき

結論から言ってしまいますがサンプルを作ったら友達に使ってもらう、最低限、自分と近い属性の人に使ってみてもらうことが一番の近道です。必ずしもいい顔をされるとは限りませんが、ここは何とかして頼み込んで、一人でも多くの友達に使ってもらう機会を作りましょう。もちろん相手の迷惑にならない範囲で。

この結果得られるものは賛同する意見や応援だけではなく、「こんなもん使わせんなよ」とか「これ何の意味があるの?」など率直な意見も多く寄せられるでしょう。

友達というのは自分とある程度の交際期間があり、お互いの社会的バックボーンをある程度知っている相手ということになります。そうであれば、作ったものが相手のニーズに合致していたかどうかを確認するのが比較的容易になります。

不特定多数の大雑把な反応より、少数の詳細なフィードバックの方が商品特性のコントロールがしやすい情報が手に入る可能性が大きいです。その使ってもらった友達の属性やタイプ、ニーズごとに反応を区分するとマーケットが予測できます。そうすればチラシを配る時、広告を打つ時にあらかじめ対象の範囲を決めることが可能です。

・これは「要件定義」の第一歩

自分の企画を立ち上げたとき、次にするべきことがあります。それは「要件」や「要求」を決めることです。

「要件」や「要求」とは、「その製品は何のために作られるのか、どのような機能を持ちそれによりどうやって目的を達成するのか、ユーザは効果を得ることができるのか」で、「要件定義」は「要件や要求を企画者が定義する作業」です。

なぜ企画の次工程に相当するそんな上流の話を品質というテーマの中に置くのかと思われる方もいるかもしれませんが、ここで定義される要件そのものが、製品やサービスになった時に品質と呼ばれるものの一部になるからです。決して全部ではありません。しかし確実に品質の一部に要件定義の内容は含まれてきます。

要件定義なくして開発プロジェクトの立ち上げはあり得ません。

・「生もの」は代替品を用意する

この記事の最初に音楽と写真の例を出しました。特に音楽などは音源を再生して聴くならともかく、ライブの興奮や楽しさみたいなものは体験しないとなかなか分からないものだったりします。

でも「体験しないと分からないよ」といくら言っても体験する前の人はその価値が分からないんですから、不特定多数にチラシを配っている状況と大して変わらない環境にあります。

ではどうするか。もうそのライブを疑似体験するものを用意するしか方法がありません。例えば何らかの形でライブを再現するか、そのパフォーマンスの価値を反映した映像を用意したり、もっとリアリティを込めて体験できる方法があればそれでもいいでしょう。

ただあくまで代替品は代替品でしかないのも事実です。疑似体験は本当の体験には程遠いものになるでしょう。それでもそれをどのように作るのか、疑似体験は疑似体験で丁寧に企画し、どのように感じられるかを作り込むことが、「生もの」のプロモーションには必要な気がしています。

「ものづくり」の3ステップ

QA+をお読みになっている方は製造業の方が多いように思います。日本は明治以降急速に近代化を進め、その発展はほぼ製造業の発展でした。戦後も製造業は 特に未成品についてはずっと 日本の花形産業でした。人々がよく「ものづくり」と呼ぶようになったのはこの頃のような気がします。

その後日本の産業の中で製造業以外も存在感を見せ始めると、製造業以外の業種でも何らかの制作物を作る分野を「ものづくり」と表現しているのを耳にするようになります。音楽や小説などの表現や芸術分野の人や伝統工芸のような技術に熟練した職人の手作り品のような工芸の分野も、確かに有形無形の「もの(制作物)」を生産し販売しています。そういう職種の方のそのような発言に対して、確かに「ものづくり」だなと思った記憶があります。

では芸術や工芸と工業は何が違うのでしょう。今回は私が考える基準にしている区分についてご紹介します。

・「ものづくり」のレベル感

芸術、工芸、工業3つには明確に異なる要素が存在します。それはシステムレベルです。システムレベルは制作物が出力されるまでのプロセス(工程:開発プロセス、生産プロセスとも)が「どの程度システム化されているか」、つまり「どの程度定型化され管理されているか」です。

システムレベルが高いほどプロセスが高度に組織化、システム化されていて、制作物の大きさや個数を大規模にしたり工程を組み替えたりの調整がしやすくなります。つまり作ったものの再現性が高くなります。

システムレベルが低いと作る人の意志や方法などで制作した結果が変わり、作ったものの再現性が安定しません。同じ絵を描こうと思っても書けませんよね?逆にどんなに同じものを作ろうと頑張っても毎回変わるので、その変化そのものが楽しみ方など作ったものの価値になったりします。

このシステムレベルの観点から3つの違いを見てみましょう。

【芸術】

一番システムレベルが低い状態です。芸術とは作家本人が制作物のコンセプトを考え、イメージを作り、作り方も考えた上で作る作業を実行し実体にします。そこで生まれるものは「作品」です。

量産性は低いです。同じものを作ろうと思っても再現性が低いのでどこかしらに違いが出ます。それは逆に作品の価値を高めます。ひとつの作品が世界で唯一無二の物になるからです。制作物の希少性が最も高くなる制作形態です。

基本的に作業者が交代できません。作る作業全般が属人化しますので、企画者、制作者が作家本人や作家と一緒に活動しているチームなどに固定化します。大規模な作品になれば組織化は必要ですが制作作業など標準化しやすい工程を除き、属人性の高さが排除できませんし、排除しない方が価値が高くなりやすいと思います。

【工芸】

中間のシステムレベルです。芸術よりも作り方が決まっているので技術の移転がしやすく、組織化や量産対応がしやすいです。ここで生まれるものは「作品」と呼べるものと「製品」と呼べるものに分かれます。

職人の習熟度合いにより作業技術レベルが変わります。技術レベルをそろえた職人を複数用意すれば組織化やシステム化を進めて量産可能な体制を作ることも可能ですし、工程を分けてライン生産化することも可能です。逆に複数工程を一人でこなすようになるとセル生産に近い形態になり、生まれるものは職人の技術やイメージに左右されるのでより「作品」に近いものになります。

その特徴から高い技術を持つ職人の作る品物は「作品」としても高い価値を帯びることがあります。更にそういう品物は制作点数が多くないので、その点でも価値が高くなりやすいと思います。

【工業】

システムレベルが一番高いものが工業です。工業では芸術や工芸の範囲では価値が上がる可能性があったアプローチは全て排除する対象になります。工業で作られるものは「製品」です。

職人の習熟度合いにより作業技術レベルが変わるのは工芸と同じですが、属人性は技術の移転の支障になる上、職人および組立作業者の技術レベルが揃わないとオペレーション品質が安定せず生産プロセスの構築に影響が出る場合があります。

製品を作る時、工程は複数あり、場合によっては各工程で専門性が異なる可能性もあります。その場合一人の職人が全体を統括するためには、統括するための視点と技術やツールが必要になるケースも多いです。このことから工芸のように高い技術を持つ職人が一人いても「作品」を作れるかどうかはわかりません。

工業における最大の価値は組織化された生産プロセスによる量産性の高さと 再現性の高さ(品質の安定)です。これらを追い求めることで市場に安くてプロダクト品質の高い製品を流通させることが工業における価値です。


このように何らかの形で物を作る活動をしていても取り組み方で作るものの意味合いが変わります。

陶芸を例に考えてみます。本人の中で作り方が決まっていて同じ技法を用いながら使う素材などを変えて違う作品を生み出す作家は陶芸を「芸術」として扱っているかもしれませんが、ある程度形をそろえて普段使いにできる食器を量産して販売している工房があれば、それは「工芸」かもしれません。

もしご自身が何かを作りたいと思っているなら、今自分はどの状況で、作りたいものはどこに位置付けられるものなのかを考えてみるといいと思います。

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

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

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

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

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

(1)ドキュメント品質

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

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

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

(2)プロセス品質

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

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

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

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

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

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

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



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

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

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

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

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

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

・管理と検査

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

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

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

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

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

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

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

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

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

そしてそのあとも、

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

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

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

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

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

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

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

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

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