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

過去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に加えて自社の監査プランが構築できることが理想です。そしてこれらの評価は経営者が業務状況を管理するのに使用します。

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

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

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

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

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

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

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

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

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

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

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

・そもそも論を歓迎する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「やりたいこと」を想い「できること」を考え「やるべきこと」に落としこむ

最近は働き方の話題も増え個人でもお勤めしている仕事のほかに副業をされる方がいたり、企業でも新規事業を始めようと思う会社さんも増えていると思います。

そんな時には「好きなことを仕事にしよう!」とか「やりたいことやろう!」などと言われることがあります。やっぱりみなさん自分の好きなことを仕事にするとか、華々しい企画を立ち上げらあれる企業になりたいという気持ちが押さえられないんですよね。わかります。自分もそうでした。

・やりたいこととできることは別

ただ現実的には必ずしもそうはいきません。時間の問題、資金の問題、技術の問題、会社だったら人材の問題が立ちはだかります。

【時間の問題】
既に抱えてる案件、普段からやっている仕事(個人の方であればお勤めしてる時間)があればその分の時間は確保する必要があります。そしてそれを終わらせた空き時間は必ずしも多くありません。

【資金の問題】
個人であれ企業であれ、自由に使えるお金は潤沢じゃないケースも多いです。生活したり旅行したりするくらいなら問題ない貯金額でも、事業を起こすとなると心もとない額にしかならなかったり、企業でも次の案件の仕入れに必要な資金は取っておかないと仕事が回らなくなってしまいます。

【技術の問題】
今まで楽器を一切やったことがないのに「音楽が好きだからギターを弾いて演奏してお金をもらいたい」と思っても、すぐにお金を取れるほどギターが上手くなるわけがありません。つまりやったことある事、もともとできることしか仕事になりません。
企業であれば、生産設備があるかどうかが大きい問題です。金属の切削加工を生業にしていた会社が化学薬品メーカに転向するとなると設備も技術も違います。

【人材の問題】
仮に自分がギターを弾けても、他の楽器ができる人がいないとバンドが組めません。新しい設備を導入してもそれを稼働させるための人と技術がないと稼働できないのです。

今の自分にできることを考えると、案外やれることは限られてくると思います。「やりたいこと」の中から、特に自分にとって「できること」が浮き彫りになってきます。

・できることを「パッケージング」する

「パッケージング」とは製品や商品を包装すること、その包装を考えることです。

それと同じように、そのやりたいことの中から浮き上がってきた自分ができることを、他の人から見えるように、他の人が買えるようにしてあげる必要があります。

ギターを弾ける人が、バンドは組めなくても一人で弾き語りをしたり、自分でオリジナル曲の作曲を始めてみたり、「商品」になる形にします。

私も、今はカメラマンとしても活動していますが、そもそもそれはお客様からご依頼を頂いて撮影することをやったことから始まりました。仮にそれが売り上げにつながらなくても、ボランティア活動であっても、商品として提供できる形になっていることが大事なことだと思うのです。

・「パッケージング」を考えると、やるべきことが見えてくる

商品の形を考えると、その形にするために考えるべきことが見えてきます。先ほどのギターを弾ける人が商品を作ることを考えてみます。

 (1)ギターを弾ける人が一人で弾き語りをしてみる
  →今まであまり歌ってこなかったのならば、歌の練習もする必要がある

 (2)自分でオリジナル曲を作ってみる
  →作曲の勉強を始めてみる

どうでしょうか?これらはやりたいことを実現しようと思わなければやらなくて済んだことです。でもやりたいことに付随することであればやるべきこともできそうな気がしてくるかもしれません。

企業であれば、今までとは異なる業務が発生するかもしません。新しい設備を導入しなければいけないかもしれません。そのために人を雇うことになるかもしれません。でもそれは必要なことなのです。やりたいことを実現するためならば。

・やりたいことを想えば想うほど、やるべきことが増える

やりたいことというのは仕事のきっかけであって、実際に仕事をする時には「実際に自分はそれをこなせるか」とか「ちゃんと納品することができるか」という、いわゆる「加工」の作業や「管理」が発生することになります。実際に売り出した後には売りに歩く「営業」の仕事や、実際にその商品がお客様に受けているかを確認し、受けていないならば受ける形を探っていく「マーケティング」の作業が待っています。

これらを見てどう思うでしょうか。実はお勤めの方であれば社内にある各職場の仕事だったり、企業であれば既存事業のとしてすでにやっていることだったりすると思います。

つまり、お勤めになっている会社や既存事業では「やらなければならない」仕事ばかりが多い理由は、もうすでに誰かが「やりたい!」と想い始めたことが「やるべきこと」に落とし込まれて事業という形になっているからです。

これは自分で新しいことを始めても、ゆくゆくは同じ状況になります。やりたいことがある人、新規事業を起こしたい企業のみなさんは「やらなければならないこと」に追われる覚悟を持って、ぜひ挑戦しましょう。