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

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日に事業説明会が行われており、そちらも取材済みですので追ってお知らせしたいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

品質を上げるために、形容詞と副詞を排除する

ミスをした時やアウトプットが想定よりも低かった場合、「ちゃんとしなさい」とか「きちんとしなさい」とか言われた経験がある人はたくさんいると思います。子供のころテストの点数が低かった時、「ちゃんと勉強してないからだ」と親に叱られたり、大人になってからご自身の子供が部屋を片付けない時に、「きちんと片付けなさい」と注意したり。

ではなにができてたら「ちゃんと」しているのでしょうか。どうなっていたら「きちんと」したと言えるのでしょうか。テストであれば100点に近ければ近いほど「ちゃんと勉強した」と評価されやすくなりそうですね。部屋の片付けであれば余計なものが床や机に出ていなければ「片付いている」と判断されるかもしれません。

ご自身が叱られた時、また誰かを叱った時、この「ちゃんと」や「きちんと」の中身を定義して叱ったことがある方はいらっしゃいますか?仕事の時はこれを定義しないとアウトプットに悪い影響を与える可能性があります。

・バラつきは言葉から生まれる

品質は製品開発と製造から得られるアウトプットです。アウトプットは製造された品物であったり測定されたデータです。それらは工程中の作業で作られ、工程中の作業は作業手順書に従って行われます。その作業手順書は製品の設計書から作られますから、帳票類の表現がそのまま落とし込まれます。

品質を安定させるためには帳票類に記載される文言のブレをなくす必要があります。そのために、まず最初に形容詞や副詞を排除し道具と方法の指示(名詞と動詞)と数字もしくは画像などによる設定値や出力値の明示を行います。

それぞれの帳票を作る時もそうですが、前工程で作成された帳票を参照して次の帳票を作る際にも解釈が人によってブレそうな部分は前工程の担当者に確認した上で書き換えます。

・曖昧さやわからないことは形容詞や副詞の使われ方から判断する

他の業務を担当する人が話す内容で曖昧なことやわからないこと、また外部に業務の一部を委託する上で不明点を明確にしたかったり、事前の確認をしたい時もあると思います。ではそのような時も含めて、会話をしている中で曖昧な所、わからない所があるかどうかを判断するにはどのようにしたらいいでしょうか。

これは筆者がよくやる方法なのですが、相手の言葉の中で形容詞や副詞を使って表現されている部分について、確認するようにしています。例えば「ちゃんとやります」と言われた場合、その「ちゃんと」というのはどういう状態のことを指すのかを確認します。「何がどの程度にどのような状態になっているのですか」とストレートに聞いてしまいます。

聞き方としてはちょっときついように聞こえてしまうかもしれません。ただここに至るまでには、その周辺の業務や作業の状況整理(仕様書や図面、作業手順書など帳票類の版管理の確認、整理や内容確認など)、残っている記録の確認などをし終わっていることがほとんどです。

その上でわからない部分をお聞きすることになるので、かなり細かいポイントにまで絞り込まれていることが多いです。そうであれば事細かに聞くような聞き方でも必ずしも相手はきつめには感じず、一緒に曖昧な点を明確にしようというという姿勢になって頂けることもしばしばです。

・「○○性」という言葉を疑う

「○○性」という接尾辞があります。「○○」という名詞に「性」という漢字一文字を付けることで「○○という性質を持つ」という意味になります。形容詞や副詞を書き換える時には「○○性」という言葉も一緒に書き換えます。

【例1:可能性】
例えばある装置の仕様書に「出力がXとなる可能性がある」という表現があるとします。「出力がXとなる可能性がある」ということは「出力がXとならない可能性もある」ということですよね。つまり出力がXとなる条件と出力がXとならない条件があると言っているわけです。ということは大きく以下の3パターンの条件と出力の組み合わせが存在します。

  1. 出力が確実にXになる条件
  2. 出力がもしかしたらXになる条件
  3. 出力が確実にXにならない条件

出力がXにならないといけないならば、1の条件以外を選択できないように動作制限を掛ける必要があります。XにならなくてもいいならX以外の出力値が得られる条件とその時の出力値を示します(もしかしたらこの時の条件と出力値の組み合わせはものすごく種類が多いかもしれません)。

仕様書の段階ではこのすべての条件か、出力値をXにするための動作制限が明示されている必要があります。動作制限が入るのであれば制限のトリガーになる条件も明示されていないといけないのですが…

【例2:耐熱性】
今度は性能の様に読み取れる「耐熱性」で考えてみます。

例えば容器として販売しようとしている製品の取扱説明書に耐熱性に関する記載をするとします。その時「この製品には耐熱性があります」と書くより、「この製品は150℃まで対応します」と書かれていれば通常生活で使用する上では沸騰させたお湯までは対応できるということが分かります。

さて、それだけで大丈夫でしょうか。150℃の温度に達する熱量が製品に均一にかかるなら大丈夫だけど、局所的な温度上昇がある場合は製品が破損するとしましょう。容器として販売する予定の製品ですので、以下の使われ方が想定できます。

  • 沸騰した100℃の熱湯を入れる
  • 水を入れて電子レンジで加熱する
  • 水を入れて直火で加熱する
  • 200℃に加熱された油を入れる

1つ目と2つ目は製品に均一に熱がかかると思われるので、破損はしないでしょう。しかし3つ目に関しては局所的な加熱ですし、4つ目については耐熱温度を超えています。つまり後半2つは使用方法として不適切ということになります。

実際に容器として販売されている製品の記載を読むと「直火にかけないでください」などと書いてある場合があります。おそらくその製品の仕様書にはこの様な指摘があるのでしょう。

「曖昧なことをしない」ようにしようにも、何が曖昧かわからないと表現が変えられません。曖昧さは閲覧者の誤解や困惑につながります。

これは曖昧さを検出して排除するための一つの方法ですので、念頭において帳票類を眺めると、その帳票の閲覧者が困る箇所が検出しやすくなるかもしれません。

「なぜ」と一緒に「もし」を考える

なぜなぜ分析は何らかの事象に対して真因を探る際に用いる手法としてよく聞くと思います。そしてインターネットで検索するとなぜなぜ分析に関する情報ややり方の説明、その歴史などはたくさん出てくるので、読んだことがある方もたくさんいらっしゃると思います。

では、みなさんは実際にお仕事の中でなぜなぜ分析を使ったことはありますか?またはどのようにやるかと言われたらご自身は普段自分でやっているやり方を説明できますか?もしくはなぜなぜ分析を受けた時というのはどういう時でしょうか。

・仕事で「なぜ?」と聞かれると答えづらい

「なぜ?」と聞く時は基本的に原因や理由を知りたい時です。「なぜそれをしたの?」とか「なんでそこへ行ったの?」とかですね。

筆者自身、かつても今も、いろんな方とお仕事をご一緒させて頂く際によく「なぜ?」「どうして?」と質問することはよくあります。またされることもよくあります。

でもですね、普通に考えて仕事中に「なんでこんなことやってるの?」「どうしてこんなことになったの?」と聞かれて気分がいい人はいないと思うんです。仕事でわざわざ質問されるときというのは何か問題が起こった時です。しかもそれが実際にお仕事を頂いている顧客から「なんで?」「どうして?」と聞かれて怖くないわけがないですよね(笑)。

ただ業務上「なぜ?」と問われて答えづらいときにはただ嫌な気分だからとは言い切れない部分もあります。なぜなら、相手が抱えている案件は自社が発注したものだけではないからです。発注側と受注側で機密保持契約と取引基本契約書を取り交わしているとしたら、受注側は他社とも同じ関係を結んでいます。

しかし使う設備や場所は同じ場所だったりするわけです。もしかしたら「どうしてこんなことになったんですか?」と問い質されている仕事の前には別の顧客の案件の対応をしていたのかもしれません。そうであればそこに関連する話題の一部は言えないものかもしれません。

筆者の場合、もし自分が質問する側で、回答する側が答えに詰まるようなケースが起こったとしましょう。そういった場合には「なぜ?」と聞くのを一回止めます。その代わりに「もしかしてこういうことですか?」という一言を挟むのです。

・「もし」が意味するもの

なぜなぜ分析を実施する上でのポイントとして、「質問の回答が得られたらその前段階の疑問が解消すること」というのがあります。

この時、「もしかしてこういうことですか?」とか「もしかしたらこうじゃないんですか?」とか聞くというのは「質問する側としては回答の方向性をこういう風に予測しているよ」という表明になります。そうすると回答者はそれに対して同意する場合は「そうですね」と言いながら実際の状況の様子を教えてくれたりします。違う場合には「いえ、そうじゃないんです」と言いながらやっぱり実際の状況を教えてくれます。つまり「もしかして」という一言は回答を誘発(誘導じゃないんです)するための切り札になります。

この時の「もしかして」というときの注意点としては、自分からあまり話し過ぎないことです。例えば「もしかしてこういうことですか?そうじゃなければこんなことになるなんてありえないですよね?」などと言ってしまった日には「はい、その通りです。申し訳ありません。」で話が終わってしまいます。

たまにここで話過ぎてしまう人がいます。そうするとそれに対して Yes か No の答えしかなくなってしまって、回答者が実際とは違う答えをすることも可能になってしまうので、話過ぎは禁物です。あくまで目的は相手が置かれてる状況を理解し、事象の原因・真因が何なのかをつきとめることです。

・本当に求めるべきもの

なぜなぜ分析の目的として冒頭でも書いたように「事象の真因を求めること」と言われます。まず最初に起こった事象の真因という意味で何が起こったのかを知りたいのはそうだと思います。しかしそれは本当に求めるべきことでしょうか。また実際にその事象を起こした組織が求めたいのはそれでしょうか。

本当に求めたいのは開発する際に、または生産する工程を設計する際に同じようなミスを再発しないことではないのでしょうか?製品の不具合の再発は一回事故を起こせば修正を入れることは可能ですが、そこを次回以降の製品開発時も活用可能な情報にできたらその方が理想的です。

そのためにはその製品もしくはその工程を作っている際に何を考えてそうしたのか、その時に何が漏れていたのかを明らかにしておく必要があります。顧客に対する回答としてはその製品に関する原因究明でも十分かも知れませんが、実は組織内では次回以降の製品開発の効率が上がっていくことが理想ですから、製品開発の活動全体に対する改善活動になる場合が理想です。

すなわちなぜなぜ分析を通じて、実際に業務にあたる際に想定された判断ポイントの条件分岐を想像することが求められます。そのためにはなぜなぜ分析に入る前にすることがありますので、それについては別の記事でご説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・開発中の品質管理

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

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

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

・生産中の品質管理

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

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

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

・販売後のケア

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアの品質とハードウェアの品質

ソフトウェアやシステムの世界で働いている人にお聞きすると品質についての認識が (加工メーカ、完成品メーカ問わず) ハードウェアの人と違うことに気づかされます。

ハードウェアを作っていても制御にソフトウェアを使うので、ハードウェアの人もソフトウェアから逃れることはできませんし、ソフトウェアの技術者もハードウェアに関連した業種で働いている人も多いと思います。

また、ソフトウェアの技術的な特徴から、その開発の仕方から作り込みのプロセスに関していろいろな方法論が検討されています。その結果、品質や開発プロセスに関しても明文化されている知識が多く、それらを学習することはソフトウェアが搭載される製品を作ってるハードウェア担当の方、またソフトウェアと関連がない(機械加工のみなどの)分野の製品を作ってる方もその考え方は参考になる部分が多い(というか基本的な意味は同じ)と思うので、今後時々話題に上げていきたいと思います。

今回は、私がソフトウェア開発の技術者の方から聞いた中で理解できたその特徴と、ハードウェアの技術者の方が理解しておくと相互理解が進みそうなポイントの概略を簡単に書いておこうと思います。

・ソフトウェアは目に見えない

ハードウェアでも回転しているエンジンの中や走行中の自動車の構造などを見ることはできませんが、ソフトウェアでも同様に動作中の回路の中でプログラムがどのように動作しているか見ることができません。しかもどんなに簡単なプログラムであっても動作させてみるまでちゃんと動作するかわかりません。

ハードウェアの場合は試運転した後分解して動作の状況を確認しますが、ソフトウェアは動作した後の痕跡がプログラム上に見える形で残らないことが多いです。そのために、実際にどのように動作したかはその結果を見ないといけません。動作した時のログを残すようにすることも可能ですが、そのログをどのタイミングで残すかというのもソフト開発上の管理ポイント次第になりますので、管理ポイントの設定ミスがあった場合には本来欲しい箇所のログが記録されないことになります。

また、動作させたプログラムが途中で止まった場合は、止まったところから先の部分に関しては確認ができませんので、その部分は先送りになります。かつソフトウェアで恐ろしいのは、書かれているコードがどのように書かれているかでどこに影響するのかがわからないケースがあることです。

これはものすごく恐ろしくて、動作が想定されていないタイミングである機能が動作した場合、想定されていない事故が発生する可能性があります。それがないように機能の動作仕様を丁寧に決め、製品の状態において各機能がどのような状態にあればいいか整理した上で設計し、実際にそれに則ってプログラムが書かれるようになっていなければならないのです。

逆に言えばソフトウェアに関してはこれらの、何をしたいかを決める要件定義、どういうものを作ればそれが実現可能かを示す仕様設計、その仕様をどのように形にするのかの詳細設計、詳細設計を実際に形にする作業が明確に分けられ、丁寧に実行されます。

これはいろいろな開発プロセスの形がある今の時代でもそれぞれが何らかの形で存在し運用されるプロセスです。

・ソフトウェアを作るのは全部手作業だけどコピーは容易

特に部品の製造をやられている会社などでは、加工機の自動化が進んだ現在では製造は自動化され、CADから読み込んだ図面データから機械の動作を決め加工するのが一般的だと思います。

しかし、まだ多くの場合ソフトウェアは人の手で作られます。そして不具合を直すのも人手です。その分それだけの時間がかかりますし、ミスも発生します。かつ先にお話しした動作させないと分からないという問題があるので、検証用の環境を使いながら作られます。ハードウェアだと各個人が検証設備を持つなど考えられませんが、それが可能であり、それをやらなければいけないのがソフトウェアの世界でもあります。

よくAIの活用が取り上げられますが、そのAIが何をどのように学習するのかも人間が決めますので、そもそも最初に作る時に想定していなければ、自動で学習してくれることはありません。つまり、どんなに技術が進歩しようと、何をしたくてどういう道具と方法でそれを実現しようとするかは結局人が考える部分として残る可能性があります。

その一方で一度作ってしまえばソフトウェアはコピーが容易なので、今まで手作業で実施していた社会の中のある仕事は一瞬で自動化できます。自動機を使用する上でのノウハウは各社お持ちだと思いますが、そのノウハウというのはすなわちそれぞれが仕事をしてくる中で「顧客の要望に応えるためにはこのように工夫しておいた方がいい」という知見です。

その知見こそが、自社の「人が考える部分」になります。もしこの部分がなくなってもいい物であればその会社は消滅し、その会社に勤めていた人は別の仕事で手を動かす必要が出てくるでしょう。この話題はこちらの「カン・コツを明文化する」と同じ内容になりますので省略します。

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

・ソフトウェアはハードウェアの制約を受ける

どんなにいいものを作ってもソフトウェアは実装されるハードウェアの制約を受けます。「新しいOSを導入したらパソコンの動きが遅くなった」という経験をお持ちの方も多いでしょう。これはOSがパソコンというハードウェアの影響を受けているからです。

ソフトウェアを動作させるハードウェアの仕様や性能を決めておけばある程度使用環境に対して融通がきく部分もあります。例えばMicrosoftが作るWindowsは市販のWindows用のパソコンに搭載できる部品であればある程度交換しても動作可能です。それはもちろんそのWindowsのバージョンによって要求された動作仕様と性能を満たしていることが条件ですが。

実はここでは機能、動作、構造を分類して一般化、規格化することによって会社をまたいでも共通の認識を作ることが役に立っています。会社の中や組織内部に関してのそのような話については以下の記事で書いていますので参考にしてみてください。
組織を機能させるために必要な3つのこと

ここまでのことを反対から捉えれば、ハードウェアの作りを十分に理解しないままソフトウェアを作る事は非常に困難なことばかりか、ハードウェアを破損する、最悪の場合にはその破損によりユーザの身体の安全を脅かす事故を起こす可能性があります。

同じ製品に搭載されユーザに価値を提供する以上、ソフトウェアとハードウェアの相互理解と技術的特性を生かした役割分担は必ず有効に働くはずです。またその技術的特性の違いがあっても、その技術的アプローチには学ぶところが多いと思います。

自分の担当する技術分野以外の情報を集める意味でも、その特性を理解することは意味があると思います。

発注と品質保証

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

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

・製造条件の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ステップ

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

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

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

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

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

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

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

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

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

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

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

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

【芸術】

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

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

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

【工芸】

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

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

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

【工業】

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

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

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

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


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

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

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