未知なる領域へ臨むときに考える品質

2019年10月15~18日の会期で、千葉県幕張メッセにおいてCEATEC2019が開催されていました。少し遅くなりましたが、その中から今後の製造業やものづくりと、品質についての未来を考えさせられる話題について、QA+として興味深い話題について、何回かに渡ってご紹介をしたいと思います。

・日本初の月面探査実現に向けて

株式会社ダイモンは自社開発のローバーである“YAOKI”で日本初の月面探査を目指しています。CEATEC2019では、AVATAR Xの共創ブース内にて、YAOKIの走行体験を実施していました。2021年に米・Astorobic社のランダー(着陸船)に搭載され月面探査を予定しています。

ダイモン社のローバー、YAOKI。

YAOKIは小型軽量で大径車輪が特徴的なロボットで、コストが高くサイズに制限のある月輸送に対応したサイズと重量を実現し、月面での活動を考慮した走破性と強度を持たせた形状と構造になっています。砂地を再現した体験ブースでもスタックすることもなく起伏を越えることが可能でした。

ブースではリモコン操作も体験でき、実際の月面探査の際には地球上から無線制御で操作するとのことです。

月面での行動と宇宙空間の移動という通常想定される環境とは全く異なる環境条件での使用が前提となっている機械ですので、現時点で想定できる事項を可能な限り反映した設計になっているという印象です。

砂地での走破性と操作性を体験できるブース。実際に会場で参加者が操作することができた。壁面のモニターには会場にいるYAOKIから送信された映像が映し出されていた。

2021年に最初の1台を月面に送り込む予定になっているYAOKIは、ダイモン社代表の中島氏が一人で企画・開発・設計を行い3Dプリンターによる試作・製造を行っています。3Dプリンターの活用で設計変更の反映の時間短縮が可能となっており、また現時点での完成品についても設計強度を満足した個体を出展しています。

加工方法が開発フェーズとその費用、量産台数とコストとバランスするべきQCDに準じて検討されており、柔軟な開発体制や予算の見通しに影響していると感じられます。

株式会社ダイモンの中島代表。もともとは自動車の駆動系の技術者で、独立しダイモン社を創業している。

YAOKIによる月面探査事業については2019年10月29日に事業説明会が行われており、そちらも取材済みですので追ってお知らせしたいと思います。

商品を量産して販売したい時につまずくあれこれ

さて、実際に企画を思いついて試作も実施してみて「良くできたからこれを販売しよう!」と思った時に気が付くことがあると思います。特にそれらは一人(自社のみ)でやっていて、しかも今まで商品を販売したことがないとなると特にいざ品物を発送できるようにしようと思った時に気が付く問題だったりします。

そんな問題をいくつかここにリストアップしておきます。「地道に手売りしていくからそんなこと気にしないよ」という方もいらっしゃるかもしれませんが、今はネットでも販売しやすくなっているので、もしかしたらそういうサービスも利用しようとすると何らかの形で影響するかもしれませんので、気に留めておいて損はないかと思います。

  1. 梱包
  2. 取扱説明書
  3. 保証期間と補償範囲
  4. アフターサービス
  5. 環境規制対応
  6. JANコード

1.梱包

何か袋に入れておけばいいだろと思うかもしれませんが、商品がホコリや傷が付きやすかったりするものであれば何らかの保護が必要ですよね。特に静電気を嫌う電子機器などはエアパッキン(プチプチ)も帯電防止用のものを使う必要があります。

手売りなら袋に入れてお渡しすればいいだけかもしれませんが、もしWeb販売などの通信販売を検討されているならば手渡しというわけにいかなくなってくると思います。その場合一般の物流ルートに乗せることになりますが、輸送中の衝撃で壊れないように梱包する必要があります。

箱を用意するにしても中が詰まってないと箱潰れの要因になりますし、上に他の物を積まないように依頼するにしても、自分が同じ商品を複数発送してしまうとそういうわけにいかなくなります。

商品の破損についてはお客様が購入して梱包箱を開けて使い始めるまでは販売者の責任です。お客様が最初に箱を開けた時(=製造業で言えば受入検査に相当)に不備がないようにしましょう。

かといって厳重にすると梱包そのものにかなり高額なコストがかかります。梱包も原価に含める必要がある資材と捉えて販売方法と輸送の計画を立てましょう。

2.取扱説明書

案外おろそかにしがちなのが取説です。「使い方なんて見ればわかるだろ」とは絶対に言ってはいけません。また取説には使い方だけではなく、やってはいけない使い方、その結果起こる可能性のある傷害レベルも記載する必要があります。

これも手売り手渡しの場合は問題になりにくいですが、通信販売で遠隔地に発送する場合はユーザがどんな人か、またどんな使い方をするかが全く想定できません。ですので取扱説明書である程度の指示を出しておく必要があります。

これも全く何も書面での指示がないと何らかの事故が発生した場合に生産者が製造物責任を問われることになりますので注意が必要です。

特に乳幼児が触れるた場合の安全性についても言及が必要です。また実際に触れる可能性を0にすることができないものであれば安全性の確認もしておいた方がいいでしょう。

3.保証期間と補償範囲

通常1年の保証期間を付けることが多いと思います。またその保証期間内であっても生産者の責任範囲の不具合しか補償範囲になりません。買う側でいる時にはそのことを認識しているつもりでも、自分の商品を買った人がすべてその理解でいるとは限りませんので、補償範囲を明示しましょう。

例えば落下による破損などは使用者の不注意で防げる問題なので、通常であれば使用者の責任範囲になると思います。

使用者の環境で起こりそうな事象とその補償のしかたについて決めておくことは自社のビジネスを守る上で必要なことなので、事業を継続する観点からも必ず実施しましょう。

4.アフターサービス

3の話と関連しますが、何らかの故障が起こった場合にどのように対応するかを決めておきましょう。故障した品物を送ってもらう必要があるのか、送ってもらってもどの程度の壊れ方なら修理するのか、もしくはそのまま新品と交換することになるのかなどの基準を作っておきます。

故障に関する問い合わせやクレーム受付窓口も決めて取扱説明書などに記載します。他の商品でも「お客様センター」などの問い合わせ窓口の記載があると思います。

5.環境規制対応

今環境負荷が低くなるように商品を作ることが求められています。欧州のRoHS指令やREACH規則はよく知られていると思いますが、それ以外の各国で規制がかけられていますので、販売対象地域の規制を確認しましょう。

特にREACH規則などは今後追加される予定の物質に対しても徐々に対応方法の検討を各企業に求めます。商品を作ったら一時的に販売して終わることはあり得ませんので、今後の見通しまで含めて確認しましょう。

6.JANコード

これは筆者も知人のデザイナーに言われて気が付いたことでもあります。小売店に卸売り販売する場合はJANコードがないと商品管理ができず受け入れてもらえないことがありますので、事業者登録と商品登録をしましょう。

弊社でもこれから対応予定です。

事業者登録
https://www.dsri.jp/jan/jan_apply.html

商品登録データベース
https://www.dsri.jp/database_service/jicfsifdb/

完成品メーカはこれらの対応をする部門が存在しますが、中小規模のメーカの場合はこれらの対応部門がないことが多いので手さぐりになります。商品を市場に流通させるときには必ず必要になる要素な上、量産開始後では対応が遅いものも多くあります。漏れがあった場合は仕様設計のタイミングまでさかのぼり、設計上対応できているかも含めて確認しましょう。

これらの項目の更に細かい要素はまた別の記事でご説明したいと思います。

「足りないものがある」と思うならそれはできるということ

今まで顧客からの発注に対して、材料を加工して納品してきた加工メーカが自社で製品を作り販売しようとするといろいろな壁に直面します。今まである会社に勤めていた方が新しい職種、職場に転職しようとすると、実際に内定を得るまでに多くの企業が要求するスキルとミスマッチがあることを実感します。

今までにやったことがないことをやろうとすれば絶対にそこには足りないことがあるはずです。そして、特にビジネスにおいてやりたいと思い実際に足りないことを痛感するのは新しい領域に手を出そうとする時だと思います。

筆者は今初めて自分の会社で企画した製品のリリースに向けて活動していますが、その過程で感じたはまさにことを今のタイミングで簡単にまとめておこうと思います。

・一番どうにかなるのは方法=技術

自社製品を売り出そうにもまずは企画を考えなければいけません。実は今進めている企画はある材料と出会えたことで発想したものでした。つまりその材料との出会いがなければ思いつかなかったものでした。シーズベース、プロダクトアウトから始まった企画と言えますね。

そしてその企画を思いついた私はメーカからもらったサンプルを使用して機能試作品を作りました。それを自社が出展するあるイベントでプロトタイプとして展示しました。

そうしたらそれを見たイベント参加者はかなりの確率で私の製品に目を留めました。足を止めて見るまではいかずとも、「あれなんだろう」という表情で見ながら通り過ぎたり、時にはプロトタイプの前で立ち止まり「へー」と言って立ち去る人がいたりしました。

その中の何人かは「これどうなってるんですか?」とか「これはなんですか?」と質問して下さり、「それだったら自分はこういう時に使いたいです」と、それぞれが想定した使用シーンの話をして下さいました。

企画は思いついただけでは実行を判断するだけの情報になりません。実際に市場にリリースした時のお客さんがいなければそもそもビジネスにならないのですから、企画を思いついたらその企画にお客さんが付くかどうか確認しなければなりません。私はそれを自分が出展するイベントで実施しました。

「お客さんがいるか分からなくて不安」であれば実際に探してみればいいのです。自分が思いついた企画が本当に自分が思ったニーズがあるかどうかを確認していなければそれはビジネスではなく趣味でしかありません。

一方でその企画を思いついて、お客さんがいるとしてもそれを自社が作れるか分からないというケースもあると思います。その場合はその機能がどのように構成されるのかを考え、それを何らかの形で形作るものがこの世の中にないのか、探せばいいのです。案外やってくれる人や企業がいると思います。つまり、実は思いついたことを実現するための方法(=技術的なこと)は、案外どうにでもなるのです。

方法論が問題になるのは実際にリリースした後、コストと工数(納期)が見合わないとか、品質を市販レベルにするのに要求される作業がものすごく難しくてコストも納期も圧迫してしまうとか言う場合です。これは単純に工程設計が甘いだけなので、リリースを公表する前に量産性確認をすればいいだけです。

ちなみに量産後に量産性不良で困る人のタイプは大体決まっています。全部誰かに任せて自分では手を動かさない人です。企画を考えたのがあなたなら、あなた自身が一度は必ず手を動かしてみましょう。実現可能かどうかすぐわかるはずです。

・プロダクトアウトかマーケットインか

一応簡単に説明しておきますと、プロダクトアウトとはシーズベースで製品開発を始めることです。製品や技術が先にあって、その活用先を考える企画の立て方です。中小企業、特に製造業の方が商品開発をするときはどうしてもこの形になりがちです。元手をあまりかけないようにするため、自社にある材料と機械で開発しようとするからです。

一方でマーケットインとはニーズベースです。使い手がいて、どういう時にどういう使い方をする道具を作りたいかで、商品企画をします。

個人的にはこのどちらかで迷う必要はないと思います。理由としては買い手がつく可能性が未知数の企画に対して元手を掛けたくないのは誰でも同じで、一方でユーザがいるかいないかはどこかのタイミングで必ずわかることだからです。

上に書いたように私自身最初は品物を見てアイデアが浮かびました。その後、機能試作品を人に見せたことで、そこで聞いた意見でマーケットがあることを理解しました。ちなみに買い手になりそうな業界は複数あることが分かりましたので、今後それぞれの業界に合わせてプロモーション戦略を立てなければいけないという状況にあります。

技術が分かるというのは大きな強みです。企画さえ思いつけば実現への段取りを構築するのは早いはずです。一方でユーザの存在を見つけられていないというのはビジネスとして致命的です。

・常に新しい世界を探しに行く

歳をとればとるほど職場と家の往復で日々が過ぎていくようになる人が増えます。これは仕方のないことですが一方で新しい世界に触れないと自分の技術が必要とされる世界が他にないのか見つけることができません。かといって、違う業界の見本市や展示会にいきなり出展したところで新規の顧客が付くとは限りません。既にある業界は特に国内の業界の場合は既存の企業で成立していて新規の参入が困難なことがほとんどです。

そんな中で新しい企画と新しい顧客を発見するにはもっと思い切って視点を変化させる必要があります。今まで何気なく帰っていた自宅、自宅で生活している家族の様子から何か家事で使える物が作れないかとか、自分の趣味に通じるもので何かできないかとか、業界から、場合によっては仕事からも視点を変える必要があるかもしれません。

しかし「そんな小さい商品では自社の売り上げ構成比率が変わらない」と言って新規事業に踏み出さない企業も多いのが現状です。でも考えてみて頂きたいのは、そもそもあるかどうかすら分からない市場に新しい製品を持っていくんですから、はじめから売り上げが立つことを期待する方が間違ってるはずです。何らかの動きを起こす方が先ではないでしょうか。

技術の不足の話、ユーザの発見、企画の見つけ方と3つに分けて大雑把に書いてみました。足りない、分からないということが分かってるなら十分にアクションを起こす理由になります。

それさえクリアできれば、先へ進めるはずです。

日本人に足りないのは “Trust, but Verify” かもしれない

筆者は社会人になってから一度大学院に入学していまして、“Trust, but Verify(信ぜよ、されど確認せよ)”はその講義の中で聞いた言葉です。それが何の講義だったかは記憶が定かではないのですが、経営者から従業員に対して仕事などの取り組みの中で使われると聞いた記憶があります。「あなたのことは信頼しているよ。でも、だからこそ確認はさせてもらうよ」という風に言うような事がある、との事でした。

私はこれを聞いた時に「あぁ、外注先の会社さんにお仕事をお願いする時や工程監査などに伺う時、自分もそんな気持ちだったなぁ」と思った記憶があり、それからずっと頭の中から離れない言葉です。

そのことを、サウスピークという英語学校のインタビューを受けた際に答えたことがあります。

–品質保証部の方から確認されるということは、責められているかのような感情を抱かれることはありませんか?

そのような感情をいだかれる方もいらっしゃいます。

ですので、こちら側が信頼していることを伝えることが大事だと思いました。海外では「Trust, But Verify」(信ぜよ、されど確認せよ)という言葉があると聞いたことがあります。相手に対して「あなたと一緒に仕事をしたい」「あなたには一定の技術力があることを評価している」と信頼を伝えること、その後に認識の齟齬を確認していく、という順序が必要です。

相手は、別の会社であれ、別部署であれ、自分たちの製品を作ることに協力してくれている仲間です。良い製品を作り、広くお客様へ届けて、使っていただくことで価値を社会に広めることが目的であることを忘れることはありません。

信ぜよ、されど確認せよ。品質保証の経験者に聞いた目的を実現するための仕事術 , サウスピーク(https://souspeak.com/ks/hinsho-shigoto/),引用日:2019/10/3

・もともとはロシアのことわざ

改めてこの言葉を簡単に検索してみたら、元はロシアのことわざだそうです。

Trust, but verify (Russian: Доверяй, но проверяй; Doveryai, no proveryai) is a Russian proverb. The phrase became internationally known in English when used by President Ronald Reagan on several occasions in the context of nuclear disarmament discussions with the Soviet Union.

Trust, but verify , Wikipedia,(https://en.wikipedia.org/wiki/Trust,_but_verify),引用日:2019/10/3

「アメリカのロナルドレーガン大統領がソ連との非核化協議の中で度々引用していることから国際的に知られた」とあります。

どういう経緯で元の言葉がことわざと言われるほどに頻繁にロシアで使われるようになったのかはわかりませんでしたが、国際的に使われるようになったのはいつ実弾を交えることになってもおかしくない東西冷戦下の非核化協議です。その経緯は、どう考えても和気あいあいとした穏やかな雰囲気ではなさそうです。

当時のアメリカとソ連は、お互いのバランスを崩さないようにただいつ攻められても対応できる戦力を残しながらギリギリの交渉を進めていたと思います。「信頼しているよ」と言いながらその心境はものすごく大きな恐怖心と、かついつ何らかの決断を下す必要が出てくるか分からない緊張感を伴うものだと思います。

・製造業の受発注関係も緊張感を伴うもの

筆者がその言葉を聞いた時、その「信頼している」と表明しながらも「だけど確認はさせてもらうよ」という強さ、「その信頼を実際の形として見せてほしい」と表明する意志が、実は製造業における受発注関係にも求められているし個人的には相手先企業に求めていたことだったなと思い至ったのです。

文化や習慣の違いを前提としたコミュニケーションこそが他社を巻き込むプロジェクトチームに必要な考え方です。

Vol.39 ITプロジェクトこそ、”trust but verify”(信ぜよ、されど確認せよ) , スフィアシステムコンサルティング株式会社,(http://sphere-sc.co.jp/column/2350.html),引用日:2019/10/3

同じ言葉をテーマにコラムを書かれていたIT企業がいらっしゃったので、そのコラムから引用させて頂きました。

そもそも自分にできないことだからこそできる人にお願いする意味があるわけですから、この考え方は外注先と取引する時に絶対に必要な考え方です。

しかしここで相手先企業と積極的にコミュニケーションをとる人はどの程度いるでしょうか。加工屋さんに部品の加工を依頼した時、「頼んだ先に細かいことを聞くのは失礼じゃ…」とか「図面も出したし頼んだんだからいちいち細かいこと言わせないでちゃんとやって来てくれよ」とか思ったりしていませんか?

受託事業を営んでいる会社さんでは発注後何も聞いてこないし確認もしてこないで、品物を納めた時に文句を言われた経験のある方はいらっしゃいませんか?または明らかに知らなさそうなのに知ったように言ってくるなぁと感じたことや、コスト面で有利になりそうな施策が講じられていない図面などが顧客から送られてきたことなどはありませんか?

製造業などの受発注関係でも、コミュニケーション上の緊張感があるんですよね。

・曖昧な点は必ず聞いて確認する習慣をつける

もしわからないことや曖昧な点があるのであれば必ず聞いて確認する習慣をつけることをお勧めします。受注する側であればこの部品が搭載される予定の製品が要求している性能はどの程度で、要求仕様や図面に書かれている内容が製品として妥当なものであるのかを確認してしまってもいいでしょう。図面が受け取れるということは機密保持契約は済んでいると思いますので、逆に業務上聞いてはいけない内容ではないと思います。聞いてはいけない内容なら相手先から「そこについてはお話しできません」と言われるはずですし。

発注側であれば、「自分はできないから頼んでるんだ」とか「頼んでるんだからちゃんとやれよ」とかではなく、頼んだ内容が理解されているか、実現のための道筋が立てられているかを確認する責任があります。その確認をしないまま出来上がったものを見て指摘するのは筋が違いますし、確認を怠った結果そのまま製品が納入されてしまえば修正が必要な場合もあり得ます。

発注するということは自分側にできない理由があることになります。時間的に自社の工程が空かないとか、自社にその設備がない、技術がないというケースもあります。特に設備や技術がなく自社でできない仕事であればわからないことや知らないことがあるのが当然です。であれば、相手側に質問する大義名分ができるのです。その大義名分を活用して、相手側に教えて頂き、勉強させてもらいましょう。その勉強は、必ず次回の発注に役立つはずです。

あえて大雑把なくくり方で書きますが、「日本人」は「行間を読む」ことや「空気を読む」ことを要求しがちです。また空気を読んでしまって、不思議に思ってもその場をやり過ごしてしまうこともあるでしょう。

その行間を読むことは、お互いが協力関係にあり、何らかの目的のために前に進まなければいけない開発の現場であれば、むしろない方がいいものかもしれません。

これからの未来のために、自分の状況を表明しためらわずに声を上げましょう。

製品開発のハードルを下げたい

仕事に関連する中でもあまりお話しする機会のない話というのがいくらかあります。せっかくなのでそんな話をこのサイトに書き残しておくようにしようかなと思います。

製造業の業務範囲というのはその企業それぞれで大きく変わります。完成品メーカであれば部材の調達もしくは生産、社内での仕上げ加工や組立て工程を持ち、エンドユーザが使用する上で品質上問題が起きないことを保証しながら販売しなければなりません。

部品加工を受託した会社は顧客の要望を満たしながら部品の出荷品質を安定させ、常に同じものを出荷しなければなりません。

その受託する会社も、機械加工品の様な社員数名~数十名で一社で一つの材料を加工し出荷している会社から、社内で複数工程を持ち、外注先と連携しながらいくつかの組立てを担当することもできる会社さんもあるでしょう。クライアント一社への依存率や業界への依存度も会社さんによってかなり異なるのが現状だと思います。

・大企業の発注をあてにできない

日本製品が必ずしも売れる時代じゃないのは今(2019年10月現在)これを読まれている皆さんもお分かりだと思います。また、今まで製品を出荷する形でビジネスを続けてきた会社が大規模なITサービス系企業と連携したり、場合によっては競合したりもしています。

トヨタ「ライバルはもうホンダではない」の真意 全ての企業の競争相手はGAFAである - PRESIDENT Online

製品販売以外の事業を展開したりして、相対的に製造業の部分のウェイトが下がっている企業もあります。日本だとソニーなどがいい例で、製品を作るだけでなく、音楽や映画、金融に手を広げ、売上高や営業利益などを見ると、そちらの方が製造業が関連する事業よりも額としては大きいものも見受けられます。

ソニー 2018年度決算説明資料  2019年4月26日

製造業の海外流出というような、生産現場が海外に移転したり、人件費の安い海外の会社に発注されてしまうという状況ではなくなり、そもそも日本国内での製造業の仕事が減っているのが現状です。その中でもなんとかまだ世界レベルで製品を売って歩ける会社があるのでいいのですが、でもそのような企業が危機感を抱いており、そのために作戦を考えて行動したことにより徐々に結果を出しているのが2019年の今と言えます。

・自分のやっていることを伝える

日本の中小の製造業の方(他の業種の方もそうかもしれませんが)、大きな企業から仕事を受けている会社が多いと思います。もちろんそれが悪いことなのではありませんが、その流れてきている仕事がなくなる、細くなるのが現在ということになりますし、その風を一身に受けている会社が非常に多いはずで、危機感を募らせてらっしゃると思います。そのために自社の技術を活用して製品を作ろうと思う会社さんが多いのも存じ上げております。

しかし、本当に数名で受託事業を行っている会社さんはこれをやる事すら厳しい状況にいらっしゃると思います。そのような会社さんが取り組めること、それが実は社内に品質保証体制を構築することだったりします。

なぜなら、品質保証体制というのは技術的な対応と開発管理、生産管理、それらを通じた品質管理の意味と内容を整理して、作り始めから販売までを網羅することだからです。つまり元手が0円で済みます。

それらの取り組みを自社のパンフレットでもポスターでもいいです、TwitterなどのSNSやもしお持ちであれば自社のwebサイトでもいいです。それらを公開しましょう。公開することで、「弊社は、ものづくりをこのように捉えて取り組んでいる会社です。」という説明ができます。

それができると自社で製品を作りたいと思った時にもいいことがあります。それは自社の製品がどの程度の生産数量でどの程度の納期なら対応可能なのか整理ができるからです。

実はQA+で今までの記事の内容の様な事を延々と書いているのは、その品質保証体制を構築する上での参考情報にして頂きたいからです。

「うちはISO9001取ってるよ」とか「○○という大企業の要求にずっと応え続けてきたから技術力はあるよ」とか説明できる会社さんはたくさんあると思います。ただそれらのもったいないところは、それだけでは皆さんがどのようなお仕事をしているか、どのように案件に取り組まれているかは説明しきれていない点です。これらの説明ができると、外部からの理解はものすごく高まります。

QA+を運営している株式会社コルプの目的は、ご自身の会社と事業がどのようなことができるのか、改めて見つめ直して頂くための機会のご提供なのです。

品質とは、制御されるべきもの

過去3回にわたって「品質とは」という記事を書き続けました。

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

品質とは、つまるところ制御されるべきものと言えます。その制御の主体とはその品質を持つ製品やサービスを作っている企業、組織です。企業や組織は、企画した製品やサービスの品質を定義して、それを実現するのに必要な知識や技術、材料を集め社会に提供できる形にします。

「そんなことわかってるよ。うちはちゃんといい品質に維持できてるよ」と思われた方、ちょっと待ってください。「いい」とはどういう意味でしょうか。

・品質はよければいいわけじゃない

よければいいわけじゃないと書いたもののよくするのは実際大変なのでなかなかそこまで行けないんですが…

少なくとも顧客企業から部品の製造を頼まれ、何らかの部品の加工と製造のみを担当するのであれば、顧客の要求を実現することができればそれは「いい」品質と言えます。実際に顧客の要求を実現するのも大変なことがたくさんあると思いますし、その状態を維持するのも簡単なことではないと思います。

しかし、自社で製品やサービスを企画しそれを社会に対してリリースする場合にはちょっと事情が違ってきます。

品質をよくするために何をすればいいでしょうか?
材料をよくしますか?そうすると価格が高くなりますよね。
加工を丁寧にしますか?そうすれば時間がかかります。すると一日の稼働時間を同じにするのであれば一日に作れる個数が減ります。稼働時間を伸ばすのであれば加工の前後の段取りのために作業者を付けなければいけないかもしれません。すると人件費が上がります。

つまり、品質を変えることによってコストと納期が変わります。

・自社におけるQCDの相互作用を理解する

もうお分かりいただけたと思いますが、品質(Quality)というのはQCDの他の二つのパラメータであるコスト(Cost)と納期(Delivery)と相互に影響しあう関係にあります。

コストを削減し、納期を早めたければ品質も抑えることを検討せざるを得ませんし、納期に余裕があれば加工の手間もかけられるかもしれません。むしろ品質を上げることが最優先事項で、多少納期がかかったり販売価格が上がったりすることも許容できるケースもあるかもしれません。


むしろ高級ブランドなどは価格が高くても、納品に時間がかかっても、場合によっては生産数量が少なくてもそのブランドとその商品に見合った品質になっていれば顧客が待ってくれるビジネスというのも存在します。この場合にはむしろ品質は下げてはいけないパラメータになります。

では自社におけるQCDの相互作用というのはどのように見極めればいいのでしょうか。そのための情報は要件定義に落とし込まれる前の企画段階にあります。企画を作った時には以下のようなことが念頭にあるはずです。

  • その企画は誰に向けたものか
  • どのように提供されるのか
  • どのくらいの期間使えるものなのか
  • ユーザはどのように使うものなのか
  • ユーザはそれにいくらくらい払うと考えられるのか

つまり、製品やサービスとして出来上がった時、品質はこれらの項目をすべて含み、すべて合致していなければならないのです。

子供向けの商品であれば子供が使用した時に怪我なく使用できるように、高齢者向けのサービスであればユーザの対象年齢に合わせたサービス内容になっているようにしなければなりません。同じ商品で大人も子供も使う場合が考えられるならば、使用条件がどちらかに偏っていてはいけません。

そして開発され、生産が決まった商品は販売期間中ずっとその企画を実現するために品質が維持された状態で出荷されなければいけません。

しかし「出荷検査で不良がなくても良品率100%にはならない」でも書いている通り、工程に投入される部品の品質は変動するものです。変動するからこそ管理が必要なのですが、品質はその管理によって企画当初に想定された状態に制御されるということになります。

つまり、品質というのは組織によって「制御(Control)」されなければいけないのです。

・“ Quality Control ”を「品質管理」と訳す不思議

どういうわけか日本ではQCというと品質管理と訳されます。でもここまでの話の通り、品質とは「定義」され「設計」され「管理」されることによって「制御される」ものなのです。

ちゃんと品質管理している、いい状態を維持しているということは素晴らしいことですが、その内容はこの順番に従って制御されている結果であることが本来は求められています。

そして組織は品質が制御された結果目標としていた企画を実現するものとなっていることを、品質管理し続けることを通して社会に対して「保証」します。

ISO9001を取得している企業では、組織は品質マネジメントシステム(QMS)を構築し運用することを求められています。システムというのは入力の結果何らかの出力を得るもののことを言います。企業というのは企画をインプットすることで商品やサービスを出力するシステムですと言えます。

つまりこの「品質マネジメントシステムを運用する」ということが、「品質に対して管理値(制御対象となる値)を用いたフィードバック制御を行う」ということを意味するのです。

もしこの話を読んで意外な感じがした方は、ぜひ今一度「自社で行っている品質保証や品質管理は品質を制御できているか?」と立ち止まって考えてみてください。

もしかしたら今まで想像もしてなかったことができる余地があるかもしれません。

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

製品開発において、定義された品質は今度製品設計に落とし込まれます。要件定義が済んだ状態であれば仕様設計に、仕様設計が済んでいれば詳細設計に移行します。この時、要件定義の結果は要件定義書にされ、仕様設計時の参照書類になります。仕様設計の結果は仕様書にされ、詳細設計時の参照書類になります。

製品や機能の仕様設計や詳細設計が進むと製品に搭載する実際にどんな機能にするか、その機能の性能を適切に発揮するためにどのような構造にするか、技術的にどのようになっていればいいかが整理されてくるはずです。もし整理されていないならその仕様と設計はやり直しです。

・設計プロセスを保有するということ

「これは品質ではなく設計の話では?」と思われる方もいるかもしれません。確かに作業としては設計者の担当作業です。

しかし品質保証担当者はその設計部門内でプロセスがどのように定義されているかを知っておかなければいけません。またその結果としての仕様書や設計書の(当然その前段階の要件定義書も含めて)品質保証担当者は必要な項目が決定されているかを確認しなければなりません。

特に「対象の機能」が「すべての設定条件と設定値」に対して「動作」が決められ期待される「出力値」が定義されているかを確認しなければいけません。この中で一つでも決められていないものがあったり、他の条件の時の被っていたりする場合には設計上不備がないか、製品の動作上問題にならないか確認しなければなりません。

また各条件への分岐点がすべて洗い出せているのかを確認しなければなりません。つまり「書かれている条件だけで大丈夫だ」と無条件に考えてはいけないのです。「もしこうなった場合はどうなるのか」とか「この分岐点にはAとBという条件設定がされているがCは本当にあり得ないのか。Cのような状態が設定されてしまうことは本当にないのか」という問いを、書類に書かれていなくても自分で立て、設計者に問い合わせることが必要です。

「そんなことは設計者がやるべきだ」と思われるかもしれませんが違います。その問いを立てないまま形になった製品はその後工程で誰にも気づかれなければ不具合を内在したまま市場にリリースされます。その結果、その製品はエンドユーザのもとで品質事故を起こします。これはプロセスの適切な運用と管理、製品に対する業務遂行状況と管理が行われていることを確認しなければいけない品質保証担当者にも責任があります。

何より、自分が担当している仕事であっても作業をしている本人が見落としていて、周囲にいる人が気が付いて指摘するなどという場面はいろいろな局面であります。製品の設計作業も同じで、設計者がやったことに対して周囲の目も含めて確認するという行為が意味を持つことは多いので、必ず他職場の関係者を交えたレビューは行うようにします。

その設計書を元に製品設計が進みますが、ソフトウェアを動かすためのプログラムであればソースコードとして文字として書かれるでしょうし、製品に内蔵される機構であれば各条件分岐が物理的に存在します。それらが適切に設計されるプロセスを持っていることが必要になります。

・常に戻れる状態にしておく

どんなに慎重に確認したとしても何らかの見落としや思い込みが組織やチーム全体にある可能性は否定できません。ですので、設計が完了していても後工程で不備が発覚した時には、必ず要件定義書や仕様書、設計書に戻れるようにしておく必要があります。

とはいってもある段階においてはもう戻ることができなくなっている要素が出てくる可能性があります。ですので、重点的に確認するべき機能や要素の洗い出しもしておき、「開発期間のいつまでならこの箇所の修正は可能」という風に修正の締め切り日を設定します。これをしないとある機能aができていることを条件に稼働する機能bが存在した場合、最初の機能aの遅れが2番目の機能bの完成に大きく影響します。

もしソフトウェアであれば関連する箇所を明確にして機能aの遅延の影響範囲を小さくしたりするなどの工夫もできるかもしれません。ハードウェアの場合は構造的に積層される場合は影響が避けづらいので上記のように開発時期を分けるなどして対応します。

開発計画も戻ることを前提に入れて作成します。特に戻ることになった場合の作業内容や対象要素によりある程度作業工数を見積もっておきます。これは開発時に見積もりを作成しているはずなので、その該当箇所を参考にするといいと思います。また実際に手戻りが発生した場合は、状況に合わせて見積もりを元にしながら調整します。

品質保証担当者は修正箇所に対して修正作業が適切に完了したか検証する必要があります。検証作業を品質保証担当者が実施してもいいですし、設計者による検証結果を確認することで代替してもいいでしょう。これは修正箇所の重要度と修正作業の重さによります。

ここで注意するべきは修正が品質に与える影響を明確にするということです。直さなければいけないという事態が発生した場合、「直せばいいんだろう」とか「ほらこれでいいだろ?」とかいう形でただ修正しただけでは品質上の影響範囲が拡大する可能性があります。それを防ぐために品質保証担当者は修正作業の内容を把握しておく必要があります。そしてその作業方針の影響範囲が大きい場合は、検証範囲を調整します。

これらの段取りは開発を進めながら作るものではなく、先にある程度想定しておくべきです。製品も作るし開発プロセスも作るのでは抜けや漏れの発生は必ずあります。開発プロセスの整備は製品開発で可能な限り抜け漏れをなくしQCDをスムーズに作り込むためのものですので、事前にあるべきです。

また、品質面においてこれらの内容で不備があれば自社内であっても工程監査を実施すべきです。それは品質保証担当者が実施するのでもいいですが、製品開発を常に行っているようになったら内部監査部門を作って、社内の業務状況を常に管理しておくといいと思います。これは生産工程での日常管理と同じように業務状況を把握するためのものだからです。

この内部監査部門では開発部門の業務状況だけではなく、製品の環境対応の管理状況やISO9001などの認証を受けている企業の場合はその認証を満たしていることを管理することも業務に入ります。開発プロセスの業務状況の管理はISO9001の認証を受けている場合、ISO9001対応のみ帳票類の内容などの確認が不足するなど自社の業務に不足することも考えられるので注意してください。ISO9001に加えて自社の監査プランが構築できることが理想です。そしてこれらの評価は経営者が業務状況を管理するのに使用します。

発注と品質保証

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

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

・製造条件の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の状態で試作を終了するというのは考えづらいです。使用環境や使用条件が考えられる以上、その条件での動作耐久試験など、何らかの方法はあるはずです。

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

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

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

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

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

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

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

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

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

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

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

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

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

・そもそも論を歓迎する

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

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

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

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

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

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

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

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