日本人に足りないのは “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企業がいらっしゃったので、そのコラムから引用させて頂きました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

カンとコツの明文化についての話に対してあまり積極的に話したがらない人がいます。なんででしょう。自分でやってることをうまく説明できないのでしょうか。それとも自分だけのものにして有利な立場に立ちたいのでしょうか。いずれにしてもビジネスは競争ということを考えたらある程度意味のあることではあります。

技術を公開する方法としては社内であれば手順化、社外であれば特許などの方法が考えられます。一方で自社固有の、特定個人の技術として非公開で使い続けて優位性を保つという選択肢も実際にないわけではありません。しかし、技術の公開をしないともしかしたらよろしくない方向に事態が動くかもしれません。

例えば「なんだ、教えてくれないのか…」といって人が離れていきます。しかもそれだけではありません。「教えてくれないなら自分達で代わりのものをつくればいいか」と言って、入手できなかった技術を代替するものを作ってしまうかもしれません。

そうするとどうでしょう。自分が圧倒的に強みを持っていたはずの分野で、他の人がもっと低い性能で作った製品が、自分達の製品以上にもっと受け入れられてしまうかもしれません。自社内でコツを共有してできる人を増やしていれば、社内の生産効率が下がって、自社で販売している製品のシェアを落とさずに済んだかもしれません。

技術というものの大前提ですが、古い方法や製品は新しいものが出てきたら淘汰される事が少なくないということがあげられます。新しい製品が行き渡り、社会の中に浸透しても生き残るものもあります。しかし、特に工業の世界において以前からあるものは完全に淘汰されるか、それを使う意味がある領域にのみにしか売れなくなってしまいます。

コツを明文化して共有すれば常に市場で圧倒的なポジションを取れるという意味ではありません。それでもコツを明文化して共有することで対応できる人を増やし、組織全体の効率を上げることには意味があります。コツを産み出した能力の高い人に次のステップに進んでもらい、新しい方法や技術を産み出してもらわないと、自分達の技術の存在価値、ひいては自社の価値を維持できない可能性があるのです。

そのようになる前に、自分の中にあるものを明文化し自社固有の技術の効率を高めたり対応できる人数を増やして、次のステップへ行きましょう。

組織を機能させるために必要な3つのこと

「業務が属人化している…」という悩みを抱える経営者の方は多いかもしれません。 また、ある程度経験を積んだビジネスパーソンが「新しいことに取り組みたいけど今までやっていた仕事がいっぱいでなかなか手が出せない…」と思っていることもあるかもしれません。

いずれも「個人が対応することが慣例となっている業務を組織的に回せるようにフレームワーク化したい」というケースです。今回はそのために必要なプロセスを考えてみたいと思います。

(1)一般化

今あるタスクではどんな時にどんなことをしているか、顧客ごとにどう対応するか、社内の各職場向けの情報はどうやって作るかなど、個人のノウハウになっている情報はたくさんあると思います。それらを一つ一つ棚卸しして、状況別に仕分けます。ここは各個人の作業になりますが、ここである程度状況ごとに分類します。

例えば ある商品の 受注から発送までを行う作業があるとします。受注するルートはWebサイト、電話、小売店からのパターンがあるとします。Webと電話は個人への小売り、小売店の場合は小売店A社と小売店B社への卸販売だとすると、作業完了までに必要なタスクの並び方から4パターンの作業があることになります。

ここで仮に個人からの発注の場合は入金を確認出来てから発送するという条件にします。また取引が継続的にある法人の場合、請求は月でまとめている可能性もあるかもしれません。そうすると大きく流れは以下のようなものが想像できます。

1-a1. Web受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送
1-b1. 電話受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送 
1-c1. A社から受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求
1-d1. B社から受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求 

ここでの仕分け作業は、実際にタスクにあたる時にタスクの条件と照らし合わせて今後の対応の場合分けをする際に必要な情報となります。

その仕分け作業が済んだら、それらの中から固有名詞や特定の商品名や限定される条件を取り除きます。それによって一回り大きな情報で整理されます。例えば上の例で言うと、「A社から受注」「B社から受注」は卸売りという行為にまとまりますし、Webと電話は個人からの受注として扱うことになるかもしれません。

それらをまとめ直すと以下のように2パターンの業務フローがあることになります。

1-a2. 個人から受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送
1-b2. 卸販売の受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求

もしここでWebや電話での受注の仕方に更に細かいルーチンワークがあったりする場合は、個人向けとまとめずに別で分けたままパターンを考えた方がいいかもしれません。それはタスクの内容と実施状況によります。

この作業のパターンが作業工程(作業プロセス)になります。

(2)標準化

続けて一般化した作業工程の中に存在するタスクに誰でもわかるようなスタートとゴールを作ってタスクの標準的な処理の方法を作ります。

上記の例の中の「在庫確認」というタスクを見てみましょう。在庫確認は受注した数量が現在在庫として保有しているか確認する行為です。在庫を確認し、発送する数量をピックアップすることが在庫確認のタスクになると思います。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c. 必要な数量の商品をピックアップする

しかし、在庫確認の際に発生する行為はそれだけでしょうか。仮に商品が発送するのに必要な数量なかったら購入品であれば取り寄せる、自社で作っているものなら工場で生産する必要があります。ということは2-b1で数量を確認した結果によって2-cが2つに分かれることになります。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c1. 必要な数量の商品をピックアップする

2-c2. 数量が不足する場合は発注(生産指示)処理をする

更に2-c2には続きがあります。出来上がった製品が倉庫に納品されるのを待たなければいけません。この場合、発注したお客様にはお待ち頂く事になります(ここではWebや電話で受けた個人のお客様の注文ですから、Web上の注意事項や電話口などで在庫状況によりお待ち頂く旨をお伝えするようにします)。

その場合、発注した商品の入荷、倉庫への入庫(在庫数量が復活)が行われ、その上で必要な数量のピックアップが可能になり、梱包と発送処理の工程へと進みます。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c1. 必要な数量の商品をピックアップする

2-c2. 数量が不足する場合は発注(生産指示)処理をする
2-d2. 商品入荷の報告を受ける
2-e2. 商品を倉庫に納める(在庫が復活する)
2-f2. 必要な数量の商品をピックアップする

このように作業を標準化する過程ではだれでもわかるような説明の仕方で、タスクの処理中に発生する可能性があるイベントについて条件分岐を作成します。

その各条件に対してゴールを設定します。ある作業プロセスの中に存在するタスクなので、分岐してもゴールは同じところに 戻ることは多いですが、そうではないケースが発生する可能性がないか注意して検討する必要があります。

そうではないケースの典型的な例は、倉庫に在庫していたはずの商品の扱いが終了していた場合などです。その場合はお客様から受注する前に受注窓口をクローズします。すでに受注した後にその注文に応じることが不可能であることが発覚した場合は速やかにお客様に連絡した上でクローズと返金処理をしますので、商品のライフサイクルと販売期間終了時の取り扱いなども検討しておくべきでしょう。

(3)明文化

ここまで検討して明らかにした作業の内容は口頭での周知で終わらせてはいけません。全体を通して作業プロセスを記載した作業工程表、各タスクの内容と判断基準を明記した作業手順書、手順通りに実施していることを継続管理するための管理表や管理チェックシートを作成します。それらを作ったら、それらの帳票類の適用範囲と保存期間を決めておきます。

【作業工程表】
ある作業がどのようなタスクで構成されているかわかるように記載した表。その作業が何のためにあり、何をトリガーにしてスタートし、何ができていれば終了なのか明示する。各タスクはどの作業手順書を見ればできるのかがわかるように、作業を構成するタスクに対応する作業手順書の書類番号を記載する。

【作業手順書】
作業の中の各タスクで必要な行動や処理、判断が必要な場合の判断基準などが分かるように記載する。各タスクの開始条件や終了条件も明示する。判断基準にない状況が発生した場合の報告先を記載して、非常時対応が可能な状態にしておく。
作業手順書は写真や図などを含めてわかりやすくし、説明は手順を追って箇条書きにする。判断基準は複合して発生しない条件が望ましいが、どうしても複合してしまう場合は、判断基準に対しても場合分けをして条件が分かるようにする。

【管理表、管理チェックシート】
タスクを実行する中で継続的に確認しなければいけないこと(上記の例では在庫の数量など)はタスクを実行するたびに確認し、確認結果を表やチェックシートなどにして残す。在庫の数量でいえば発注日と発注数量を管理すれば在庫を消化する期間の把握ができる。

これらを実施しておくことで、担当者が変わった場合やメンバーが追加された場合に経験者が帯同する時間を短くすることができたり、判断を間違うケースが限定されたりします。

また明文化して残す際には必ずその職場のベテラン職員の意見を求めたり、その方の仕事の仕方を取り入れることを検討すべきです。なぜならベテランの業務にはその作業を行う中で積み重ねた工夫や、身体に染み付いたカンやコツが含まれているからで、それらは必ずその方と会社にとって付加価値になっているはずだからです。

付加価値を生むことができる条件を他のメンバーにも共有することが組織として付加価値を生み出す可能性を引き上げます。


この3つの作業を日常業務を行いながら実施することはかなり困難ではありますが、価値を継続的に生むためには不可欠なことですので、少しずつでも推進することをお勧めします。

プロダクト品質を形作るもの

多くの場合で「品質」という言葉が使われるときは出来上がったプロダクト(商品や製品、システム)の品質を指すと思います。

しかし業務の中で関わる品質は品物の品質を意味するプロダクト品質だけではありません。その製品品質を作る上で業務上影響する品質について簡単にお話しします。今回は大きく以下の3項目に対してご説明します。

・ドキュメント品質
・プロセス品質
・オペレーション品質

実はこれらは特にIT関係のシステム開発業界などでは頻繁に聞く用語だったりもしますが、製造業、特に今後自社で製品開発をしたい企業には参考になる部分も大きいので、製造業目線で書いてみます。

(1)ドキュメント品質

業務中に作成されるドキュメント(書類)の品質を言います。

・必要なことがもれなく書かれているか
・体裁や項目が統一されているか(毎回書かれることが違っていないか)
・読みやすい書き方になっているか
・(図面などは)書式が間違っていないか

業務中に確認するための文面だからこそ統一しておいた方がいいこと、抜け漏れが後の作業に影響することなどが多くありますので、社内で各担当部署、各プロセスで必要な書類と項目の取り決めなど、必要なことが多くあります。

(2)プロセス品質

プロセスとは生産工程ではなく新しい製品の開発プロセスのことで、ドキュメントや作っているプロダクトの状況を作り込みの各段階に応じて確認と検証をしながら作り進めることを考えます。顧客との仕様書や図面のデザインレビューなどに臨んだことがある方もいらっしゃるかもしれませんが、それらの位置づけや内容などはプロセス品質として考えるべきものになります。それ以外でも検証用の評価内容のレビューや、評価結果の報告と状況確認などもあり得ます。

ゲート管理などの方法を取り入れている会社さんもいらっしゃるかもしれません。作業と確認を組み合わせた業務の進め方そのものがここでのテーマになります。今までお伺いした会社さんでお話を聞いている限り、前工程への差し戻し条件や次工程への進行条件など、各社の進め方や考え方が出やすい部分でもあるように思います。

(3)オペレーション品質

各プロセス内での作業そのものの品質のことを指します。製造業であれば加工だったり組立作業になりますが、作業の品質が低いと当然ですがプロダクト品質は落ちます。

しかし開発中の製品の場合、必要な作業そのものが何かがまだ明確ではなかったり、今までにない新しい作業を導入する場合には担当者が作業に不慣れな状態だったりして、オペレーションの品質がそもそも低いことがあり得ます。

その場合は工程設計のための工程開発プロセスを製品開発のプロセスと同時に立ち上げ、作業者の人材育成とスキルマップの作製などを同時に進めた方がいい場合もあります(具体的なタイミングについては開発中の製品と作業内容によりますので詳しいご質問はお問合せにてお受けします)。

特に製造業の場合は量産時の品質安定が課題になります。工程設計のタイミングでは加工や組立ての量産バラつきを測定することも必要です。作業者の工程能力にあった製品設計になっているか、または作業者の工程能力を上げることができるかが検証ポイントになります。



如何でしたでしょうか。製品開発に取り組むとき、または自社の業務を見直すとき、品質は見直す目的であると同時に観察、計測する対象にもなり得ます。

これらを組み合わせて構築された業務でプロダクト品質は構成されますが、製造業の場合、実際の加工や組み立てでは量産バラつきが発生しますので、これらを意識しながらプロダクト品質を作り込むことを忘れないでください。