やり直しをカイゼンする

やり直しは、仕事をする上ではあまり良いことではありません。

私が、ムダ取りをしましょうというと、

「この世にムダはない」

「車のハンドルにもあそびがあるじゃないですか？」

とおっしゃる人がいます。

これはただの論旨のすり替えであって、議論が噛みあっていないだけのことです。

ある設計者が、お客様の要求仕様に関する営業からの情報が分かりずらくて、

毎日のように問い合わせをしていることに、うんざりしていました。

「また、こんなに曖昧な訳のわからない言葉がある。確認しなきゃ！」

「営業からの文章をよく読んでみたら、標準仕様だっだ。一応確認しておこう。」

「この機械の右側には、コンセントをつけられない。ルールブックを見てほしいな！」

これが毎日の独り言でした。

こう言う時に、ただ一人で　ブツブツ入っているだけでは埒が開きません。

かなり頻繁に問題があるようでしたら、まずやることは、この現象を記録することです。

表計算ソフトで、簡単に表を作って、いつ・誰に・こんな問い合わせをしたと言うことを、１週間〜２週間分で良いですから、記録しましょう。

そしてそれぞれの現象の要因を分析します。

ブツブツ行っている内容を記録して、その原因を分析する。

なぜ、こんな問い合わせをしなければならないのか？

機械の仕様は標準化してありますので、営業担当者がわかりやすい情報を、送ってくれれば、

作図をすることなく、部品の手配に移ることができます。

それなのに、設計担当者は、毎日営業担当者に問い合わせをしているのです。

設計担当者の存在意義はなんでしょう？

彼の頭の中にある技術的な知見を活用して、お客様の要求に合った製品の図面を作図することではないでしょうか。

少し抽象度を上げてみると、作図と言うのは単なる手段ですから、製造に必要な情報を提供することということもできます。

２週間分の問い合わせ内容を分析してみた設計担当者は、原因が見えてきました。

営業担当者がルールブックを見ていないことが、大きな原因ではないかという結論に至りました。

一つ一つの現象に対して、ルールブックのどこに書いてあるかを一つ一つ確認しました。

原因がわかったところで、営業のリーダーに、ネットミーティングを提案しました。

営業担当者は、ネットミーティングで、営業の人たちにルールブックを確認してから、

仕様書を書くようにお願いすれば一件落着すると少し安心することができました。

そして、ネットミーティングの当日です。

「ルールブックのあることは知ってるけど、正直なところ、いつも見ていません。」

「お客さんとは、カタログで商談してますが、お客様の要求がルールブックの中のオプションでは、足りないので、いつもお客さんにできませんと回答するばかりで、仕事がやりにくい。」

「お客様の要求を一つ一つ聞いていると、うちの機械の仕様に合わせるのに苦労している。」

設計担当者は、自分から指示を営業に申し渡せば済むと思っていましたが、逆に営業の不満を一心に受け止めなければならなくなりました。

設計担当者は、自社の製品が標準化されているので、多少のオプション仕様を加えるだけで、お客様の要求に応えられると考えていましたが、あっさりと覆されてしまいました。

この事例では、標準仕様を再度見直し、それに合った仕様書を作成しました。

営業担当者が商談しやすいように、仕様書を作成し、オプション仕様の依頼があった時だけ、

その適用欄にレ点を入れるようにしました。

営業は、文章を一切書き入れることができないようにして、曖昧さを無くしました。

トヨタの製造ラインでは、特に仕掛かり在庫に注目します。

工程と工程の間に、物が溜まっていたら要注意です。

その原因を探れば、本当の問題が見えてきます。

今回は、設計と営業間の事例でしたが、情報空間の話になります。

情報空間では、在庫のように物理的に問題が見えるようなものがないために、

表面上は問題を探すのに、苦労します。

この事例では、最初は設計担当者が日々うんざりするほどの問い合わせをしているところから、問題意識が生まれました。そして彼は、「やり直し」に着目しました。

「やり直し」の現象を具体的にリストアップして、原因を追求することで、

本当の原因が見えてきます。

今説明しました通り、製造現場での在庫による問題の発見と情報空間における、「やり直し」は問題発見という面では、共通性があります。

こうやって抽象度を上げてみることで、カイゼンの横展を進めていくのです。

昨日、私はたくさんの問い合わせを受けました。

私が提出した情報に不明な点があったというご指摘でしたが、私がその情報を作る時点で、

「わかりにくい帳票だな！！」と感じながらも提出した情報でした。

問い合わせが来ることは、目に見えていました。

今日ご紹介し事例の中の、ルールブックにあたる物です。

ルールがそもそもわかりにくい、見にくい、から使っていない。ルールを示していない。

ルールが曖昧だから、情報を記入していく帳票がうまく作れない。

設計担当者から見ると、天つばでしたが、お互いにウインウインの結果になることができました。

この事例はどこにでも転がっています。

みなさんが、この事例を抽象度を上げて理解すれば、RASが開いて、またまた事例が目に飛び込んできます。