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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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