日本人に足りないのは “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つのこと

そのためのポイントを簡単にご説明します。

・ある人のカンが働くところは他の人が迷うところ

「カンがいい」ということは他の人のカンが働かないところでその人はカンが働くということです。ということは、その人しか気が付いていない視点や状況があるということです。同時に他の人は同じ状況になると迷ったり間違えたりするということです。

カンはその業務を継続して経験している人にだからこそ気が付く部分だったりしますので、その人が業務を遂行する際に注意していることや判断基準などを作成する帳票類に盛り込むことでカンを明文化することができます。

ここで問題があるのは、日常的にその作業をしている方はそのカンを含んだ行動そのものが普通になってしまっていることです。なので、自分が普段仕事をしているときに考えていることのどの部分を書き起こせばいいか気づいていないことが多いです。

その場合は一度本人が手順書の形を完成させ、内容を他者(理想的には上司)がヒアリングをする形で補足する箇所を指定するなど、漏れを極力減らす施策を講じる必要があります。この方法が成立するのは、カンが働くところは本人が必ずしも意識して行動していない可能性があるからです。一度本人が作った手順書を元に内容をさらっていくと、「ここはどうしているの?」と思うところや「こういう時何を考えているの?」と聞き取る側が作業手順に応じて条件分岐を想定して進めることで、その作業者独特の判断基準を拾い上げることができます。

・ある人が「コツがあるんだよ」というところは他の人にできないところ

コツが必要な部分というのはその人が仕事を進める中で「こうしたら上手くいくな」という全体の作業に大きな影響を与えないミクロの範囲でオリジナルの技術を開発して適用している箇所と言い換えることができると思います。

実はコツを明文化する際に「カンの明文化」とは少々異なる部分、具体的には明文化を進めようとする管理者を困らせる可能性がある部分をはらみます。「カンが働くところは本人が必ずしも意識して行動していない可能性がある」と上で書きました。しかしコツというのはその人本人が編み出した方法、開発した技術です。だとするなら、その自分しかできない技術や方法を易々と他の人に教えるでしょうか。

同時にカンと違いコツはどこで適用されるかがわかりません。ですので、コツを明らかにする際には 現場を見学し、作業している本人を観察するのが一番です。管理者の方は「そんな時間ない」と仰るかもしれませんが、そこは少しずつでも現場に出て作業の様子を見ることをお勧めします。コツを明らかにするために現場を見るということは、現場にいる現役の作業者の目線で見ることに他なりません。それは昇進する前のあなたの目線そのものですし、管理職の椅子に座ってから書類と打合せの日々だったあなたに作業者時代の感覚を呼び戻します。そうすると熟練の作業者が適用しているコツを見つけることも、そのコツをどのような時に適用しているかを理解することもより簡単になります。

本当にコツを明文化する必要に迫られたとき、その作業者の持つコツと仕事に対する姿勢を理解した管理者がそのコツを明らかにして職場に展開してほしい旨をその人に説明することがまず必要でしょう。そしてそのコツを明文化した後、仕事の仕方などをどのように変えるかも検討事項です。

この時の明文化の対象になる帳票はオフィスワークでも現場業務でも何らかの作業標準を作ろうと考えている職場であれば、作業手順書などがいいでしょう。

カンは代表的な作業手順書を改定する形で判断基準や方法や考え方を明記する形で対応可能になるケースがあるかと思います。

コツについてはその技術の内容によっては、特定条件下での作業手順として明確にするという方法があります。

これらの明文化によって得られる効果には以下のようなものがあります。
(1)作業者全体の方法が揃う
(2)熟練した作業者の考え方を展開できる
(3)スキルを明示できる

特に(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)オペレーション品質

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

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

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

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



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

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