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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

出荷検査で不良がなくても良品率100%にはならない

今日はちょっと新入社員向けみたいな話です。

技術者であれば当たり前のことだと思うのですが、改めて確認しておきましょう。出荷検査で不良品が発生しなかったとしても良品率は100%になりません。特に日々大量に生産して大量に出荷するような量産品の場合は特にです(少量生産品で不良の程度が大きくない場合は手直しで使用可能になるケースもあるでしょう)。

「いや、今日出荷した分は全数検査して不良品0だったから良品率100%だよ!」

確かにそれはそうですが、その100%はその検査した対象に対してのみしか含んでいません。つまり、その部品・製品の生産において良品率100%を達成しているとは言えませんし、言ってはいけません。

仮にその製品の出荷検査は常に全数検査をすることになっていて、出荷開始から生産終了までの製品ライフサイクルのすべての出荷品に対して検査をすることになっているのであれば、生産終了を迎えて最終ロットの出荷検査が完了するまで不良品が発生しなかった場合のみ「良品率100%」と言って構いません。厳密には「良品率100%『だった』」と言わなければいけませんけどね。

本来であればこれは困るはずです。部品を納入することに対する保証ですので良品率100%は未来の話であってほしいからです。

・そもそもなぜ検査をするのか

検査をするのは不良が流出するのが怖いからです。逆に言えば、検査をするのは不良品が混入している可能性が0%ではないということであり、不良品の発生を認識しているということです。

「そんな、不良品がある前提で生産に取り組むなんて技術者じゃない!そんな品質の悪い会社には発注しない!」などとお思いでしょうか。違います。「人がやる事だから間違える可能性は常にある、だから検査をする。」というのが持つべき姿勢です。

本来であれば「持つべき」などという表現は使いたくないのですが、あえて使います。基本的に業務中は「ミスは発生するもの」、「事故は起こるもの」として扱うのが保証の基礎です。それをいかに影響のない範囲に抑えるかというのが品質の設計であり品質の保証です。

その影響の考え方が表れているのが抜き取り検査です。抜き取り検査はロットの一部を抜き出して検査を実施します。不良品の発生が認められれば次回以降の検査は厳しくし、不良品がない状態が継続していれば、検査の条件(抜き取り個数)を減らすなどしてコントロールします。

その程度はどの程度の不良率であれば許されるかで決まります。かつ、この不良率を上げることができれば検査数が小さくなる分検査が短縮できる上に、不良品が出荷数に含まれてもいいことになりますので生産コストが下がります。

・良品率100%は工程内で達成する

では逆に常に工程が流動するような製品の生産で良品率100%の達成は不可能かと言えばそんなことはありません。各工程内での不良流出を0にすれば不良品が出荷されることはありません。

ではどうすればいいのでしょうか。まず各工程内の工程能力を測定します。その工程能力が流動させる製品で要求される規格を常に満足していればいいはずです。更に加工精度が高く生産される製品が規格中央値に集中していれば工程の安定度は高いことになります。

更に量産中もその工程能力が維持されていることをモニタリングします。バラつきの発生要因になる加工工程で工程能力を満たしていることが実証できれば製品上は問題ないことになるからです。またロット間で中央値が遷移することがありますので、製品のバラつきが規格幅に対して十分であっても注意は必要です。

さらに言えば工程の変動要因を漏れなくとらえ、日常管理と日常整備で加工設備の状態を維持できればモニタリングが不要になるレベルまで工程能力が安定するかもしれません。このようにすれば全数に対して出荷検査をしないでも出荷品に不良がない状態を作ることは可能です。

特に他社や他工場に生産をお願いする際に私が特に注意して見ていたことは、一ヶ所の加工個所に対して一回の動作で作業が終了するかどうかです。

同じ個所を向きを変えたりしながら何度も加工しなければならないと、その分不良の発生確率が上がります。特に部材を持ち換えたり工具を取り替えたりするような段取り替えが複数回発生する形状で切削加工しなければならない場合などは、都度都度検査が必要になるなど手間がかかります。

そのような点も踏まえて生産に手間がかからない方法で部品や製品を設計できると品質の維持と向上につながります。

「なんでそんなに忙しそうなの?」と言われたときの話

私はあまり人に自分の状況を伝えるのが上手くないという悪い癖がありまして。そのせいなのですが、「今何をやってるんだ」とか「ずいぶん忙しそうだけど何やってるの」とか言うような言葉を過去にいろんな職場・現場で言われたなぁと思いだしましたので今日は軽く思い出話です。

新卒入社した会社で作業を覚えてきて少し経った頃、その自分ができるくらいの作業を職場内だけでなく、他職場からも頼まれごとをしたりだとかで嬉しかったのを覚えています。

そんなことが重なって結構忙しくなってしまったある時、先輩に言われました。「お前、忙しそうだけど何やってんの?」と。先輩は何か自分にやらせたい仕事があるようで、今あるものを早く終わらせろと言い残してどこかへ行ってしまいました。

その後も似たようなことがたまにあり、ある日も別の先輩からそのように言われたのですが、続けて「そんなことやってたら便利屋になっちゃうよ。そうなったら歳とった時『自分はこれなら通して仕事を進められる』っていう分野がもてなくて仕事で苦労するよ。」と言われました。若いときはある程度まとめて仕事の段取りを覚えておかないと、年齢が上がった時に組織やプロジェクトの中で役割を担当できないという意味でした。

これを言われた時にはハッとしたものの、その真意はその当時はまだあまり正確につかめていたとは言えない状態でしたが、最近でははっきりその意味が分かります。

・「自分はこれだけやっているから仕事ができる」と思う錯覚

その当時の「自分はこれだけの作業をこれだけの件数(とは言っても今思えば大した件数でもないのですが)こなしているから充分仕事をしているはずだ」と思っていても、その言葉を聞いた後で改めて考えてみると全く仕事のレベルとしては上がってないことに気が付きました。当然ですが仕事の対応範囲も広がっていませんでした。

これは実は結構怖いことで、自分の業務範囲の中でコアになるスキルを上げる理由ができないんですね。「自分で仕事を進められる」というのは状況を進捗させるために必要な情報を集め、または状況を測定してデータを生み出す能力が基礎として必要です。しかし、同じような仕事を数だけこなしていても広い範囲の状況を知ることはできないのと、どのようなデータが本来必要であるかを考察する力が養えません。
他部署からの突発的な頼まれごとはその人ができる作業のみに限定されるため、それらがあまりにも多く舞い込む状態は自分にとってあまりいいとは言えない状態だったわけです。

結果、仕事のレベルは上がらないし、頼まれた仕事や今自分の手元、自分の職場にある仕事がどのような意味を持つのか理解ができない状態にいました。これだけやってるからいいだろ、という問題ではありませんでした。

・自分の仕事が可視化されない

「頼まれてやる仕事」というのはもともと「頼んできた人がやるべき仕事」であり、「突発的にやる仕事」というのは「現状では穴があるからとりあえずその穴を埋めるための仕事」なんですね。要するにプロジェクトの状況を進捗させるものではない上に、実施したのが自分ということにならない可能性すらある仕事と言えます。

端的に言って、職場としてはこれは危機的状況です。なぜなら、自分の職場の工数が何か得体のしれない何かに吸い取られているように見えるからです。職場の配属というのは、本来その会社にある仕事を分割して、各職場に役割分担して、それらを遂行する上で必要な人材を必要な人数だけ各職場に配置しているものです。

既存のプロジェクトで穴があるならその穴を可視化してプロジェクトとしてもしくは担当職場として穴埋めの対策をする必要があるし、誰かが頼んでくるならその分の工数を(お金と時間という形で)職場としては差し引かなくてはいけなくなるはずです。

よって、なぜか自分が同じような仕事をやり続けなぜか忙しい状況が続いてしまったりします。対策が取られてないミスは永遠に繰り返されますし、自分が引き受けてくれることに味を占めた依頼者はまた頼んでくるでしょうからね。

最近若い人と話をすることが増え、そんな人たちの様子を見ていて自分の若いころの話を思い出してしまいました。

4月に入社した方はそろそろ半年経ち、先輩から仕事を教わり始める時期だと思います。そのほかにも異動があったり転職したり環境が変わる人もいらっしゃるかもしれません。案外、職場や会社はスタッフそれぞれの様子を見ているものです。あくまで自分を雇っているのは会社です。その会社の中で働いていく上で、職場と自分の役割というのは見失わない方がいいみたいです。

品質を上げるために一番必要なこと

これについては結論から書きます。これは業務や作業への慣れであり、品質を上げるために一番重要な資産は業務や作業に慣れたベテラン従業員の方々です。

理由は簡単で、作業の確実さ、技術の習熟度、職場環境の熟知、すべてにおいてベテランの従業員さんやスタッフさんに勝る人はこの世にいないはずです。職場を見回してみてください。その持ち場でその仕事をするのが一番上手な人は誰でしょうか。今そこで働いている方ではないですか?新しく雇った方があなたの会社で、その仕事を、今いる方より上手にできますか?少なくとも似たような作業をした人であっても新しい環境でそこにある道具を使うには少なくともいくつかは覚えることや慣れないとできないことがあるでしょう。ということは、あなたの会社で、その持ち場で、一番高い品質を出せるのは紛れもなく今いらっしゃる方です。

今いるその方の素晴らしさをこれから列挙します。

・作業が確実である

その方は長年その業務に当たられ、最適な道具の選び方も、道具の使い方も、材料の扱い方も、その工程の最適な状態も、すべて把握されています。その方はもはや理屈ではなく、身体でその作業を覚えていますので、自分がどんな状態であれ最適なアプローチで作業を完遂されています。

新しく採用した人材の教育にはその方の仕事を見せるのが一番です。いつどんなタイミングで何をしているか、あの振る舞いにはどんな意味があるか、仕上げたその製品はどのような状態か、それらをなぜ会社は評価しているか、あなたは新しいメンバーの隣に立って説明します。新しいメンバーはそのベテランを見習うべき対象と捉え、自分の業務に必要な情報を学び取ろうとするようになるでしょう。

・技術に習熟している

作業の話につながりますが、その方はとてもスキルが高く、普通であれば困難な案件もやすやすとこなしてしまいます。 その方には難しいことなど何もないようです。その方が働く姿は現場を訪問した顧客には見せるべきではありません。顧客はきっと簡単な作業だと勘違いするでしょう。笑

技術に習熟している方は新しいタスクを目の前にした時に情報を集め、あらゆる条件を考慮し、これからタスクを進めていくうえで起こりうる状況をタスクの完了までの各段階において条件分岐を作り、それぞれについて対策を講じます。そしてベストなソリューションを編み出し、タスクを最短距離で実現します。

もし可能であればあなたはその方の技術を可能な限り明文化して社内にいるメンバーに知らせるべきです。それはその方の技術を奪うことだと思ってはいけません。明文化することは組織の共有財産になり、それを作り上げたその方の功績を組織の中で確固たるものにします。更にはその方の仕事の仕方のポイントが共有されれば、今までは当人しか気にしていなかった事柄が他のメンバー、特に経験が浅いメンバーも知識として情報を得ることで実現に一歩近づきます。組織全体の知識レベルや経験レベルが今までよりも整います。その結果、ベテラン社員も今まで以上に自分の本分であるタスクに取り組むことができるようになり、その結果その方の評価が更に高まります。

・職場環境を熟知している

その方はきっと長年あなたの会社で働き、あなたの会社に来る仕事がどのようなものか、ひいきにしてくれている顧客はどのような人物で何を求めているのかをよく知っているはずです。その上、社内についてもよく目を配っていて、何か問題が起きたとき他のメンバーはどうするか、社長はどのようにしているか、そしてどのように解決するのが得意か熟知しているはずです。

あなたはその方のことを結構頼りにしていませんか?普段と変わらないようでもその方もきっとそのことに気付いていて、あなたと会社に貢献できることを何より喜んでくれているはずです。

会社、職場のメンバー、顧客に対してその方が払っている配慮は普段はなにげないものでも業務内で問題が起こった時、新しい顧客から受注した時など、課題がある中で解決の指標になるかもしれません。もしかしたらその方が率先して課題解決に向けた指針を出してくれるかもしれません。

それらの動きをあなたが受け入れることで組織はよりいい動き方をするかもしれません。もしあなたがリードを取ろうとしているならば、その方に協力を求めたら理解を示しその方の立場の中で最大限のサポートをしてくれるでしょう。

・人柄

あなたの会社でそこまでの実績と配慮を持ちながら日々勤務してくださるその方はきっと素晴らしい人柄の持ち主です。普段は不愛想だったり対応が冷たかったり、厳しく感じたりもするものですが、じっくり話を聞いてみると会社への思いと仕事への責任感を感じることができるはずです。そしてそれらは確固たる技術力に裏付けされて日々会社に還元されています。

あなたと会社ができることはその方への感謝を示し、その方が仕事をしやすい環境を作ることです。もしかしたらそれは新しい道具かもしれませんし、新しいタスクかもしれません。昇給かもしれませんし、もしポジションを要求されたら相応しい椅子を用意することがあってもいいのかもしれません。最終的にはあなたの判断ですが、その方の気持ちなら会社として受け入れられる範囲ではありますが、応えて損はないと思います。

品質を作り上げるのは人材です。お世話になったすべての方々の取り組みとご理解がなければ、今まで私が関係した製品は品質目標を達成できなかったでしょう。

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

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

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

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

・管理と検査

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

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

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

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

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

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

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

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

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

そしてそのあとも、

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

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

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

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

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

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

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

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

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