フォト
無料ブログはココログ

Six Thinking Hats リンク

2015年11月25日 (水)

クレームへの対応-総集編(4)

  合併後の混乱が落ち着いたのはそれから3年後であった。吸収された会社側の社員は海外転出組や営業部門を除いてそのほとんどが退職してしまった。理由は個人によって違うが、共通していたのは努力しても評価されないと将来を悲観したようだと何かの折に人事課長から聞いた。自分から積極的に仕事を探してキャリアを重ねてゆく会社にあって、上から指示された仕事を言われた通りにする会社で長年過ごした人間は何をしてよいかわかなかったのだろう。見よう見まねで覚えた仕事の知識が全く役に立たなかった。忙しかった毎日を振り返るとほとんどが無駄な会議と不要不急の仕事ばかりだった。営業は決められた顧客に挨拶に行くだけ、設計は同じデザインの焼き直しか他社のコピー、製造は不良が出ても全数検査で取り除くだけ、納期は守ったことがない・・・ブランドに惹かれて入社した社員は一流大学が多かったようだが無能な上司やマネジメントに「教育」されて数年もしないうちに日々出社するだけが仕事のような無気力人間になってしまった・・・合併前はそんな状況だったらしい。

  合併に先立って両社の社長は人材の活用や顧客満足度の向上、市場の拡大、製品群やサービスメニューの充実など相乗効果を掲げ、会長と社長(旧社社長)の経営体制になった。
ところがその意に反して、旧社長はヘッドハンティングで決まっていたらしく新社長になっても出社せず合併発表後に転出してしまった。在庫もなくなり旧製品すべて販売終了、スペアパーツがある保守サービスを残すだけとなり、相乗効果は立ち消えとなった。ブランド力があったので旧製品はバブルの時代には売れたかもしれないがそれがはじけたとき、すでに技術的に古く、高額なだけでコストパフォーマンスが低いため高いメンテナンス料をかけてまで使い続ける顧客はいなかった。ほぼ同性能で価格が半額の製品に置き換えて顧客を確保する方針へと変更をかけたが、旧製品を扱っていた営業部がかたくなに拒み続けた結果、他社の製品に置き換えられてシェアを奪われていった。顧客の要求に合わせて会社が変わっていかなければならない。その会社を形作っている組織も柔軟に変化して対応しなければ生き残れないー適者生存の法則が企業活動にも当てはまる。

  危機感を感じた会長は社長を兼務し、新製品の開発を急がせた。3つの開発チームが立ち上がり、コードネームは I,J,Kで呼ばれた。3か月で試作品が完成、コストと機能(価値)を見積もり、AHPによってコストパフォーマンスを評価して開発する製品をIに選定した。


Ahp


 
 


 
  新製品 I はその後主流となるインターネットを駆使して様々なデータのやり取りやネットワーク機器の制御を可能にした意欲作だった。海外派遣組のエンジニアも設計段階から参加して3か月で発売にこぎつけた。それというのもこの新製品 I を使って国内と海外拠点をネットワークで結んでプロジェクトを進め、通常は市場に出てから発生するであろう様々な問題点を洗い出し、リアルタイムで改善できたことが大きかった。このコンカレントエンジニアリングは開発期間を短縮する理想的な方法だがこの実績が後の開発設計の基本になった。くすぶっていた双方の軋轢も解消し、ようやくワンチームとして会社がまとまった。

    新製品 I はハードよりもソフトに特徴があった。顧客は月々一定の料金を支払えばインターネットに接続するだけで様々なアプリケーションを使うことができる。それまではバージョンアップするたびにパッケージソフトやライセンスを買い替え更新の費用負担が問題になっていたが、必要な期間だけ契約すればよいので運用費が安くなる仕掛けだ。他社からの乗り換えなら費用が半額になるというキャンペーン効果もあって新製品 I は発売後1週間で当初の販売計画を大きく上回り、バックログを抱えて3か月待ちとなった。

  ケース7.顧客の囲い込みすぎが起こした問題

     ところが、発売後2か月もたたないうちにキャンセルが相次いだ。ユーザーからのアクセスが予想以上に多く、サーバーが頻繁にダウンするようになったからだ。アクセスできないならまだよいが作業中にフリーズしてデータが消失する事態も発生した。販売量に応じてサーバーを順次追加していたが焼け石に水であった。セキュリティを確保することと、ユーザーの利便性を考えてネット環境の中だけで作業や処理が完結するように設計され、データやファイル形式をそのアプリケーションに最適化していたために従来製品と互換性が全くないことも問題だった。また、オプション購入や有料ヘルプデスクを使った場合の課金システムもわかりにくく、高額請求されたユーザーからのクレームもあった。

  ケース8.ウィルスによって情報漏えいした問題

     急遽、データに互換性を持たせたりエミュレーションソフトを提供して他社のアプリケーションでも処理できるようにしてアクセス数はそれから3か月後には落ち着いてきた。ところが、外部機器と接続できるようにしたことでウィルスに感染しやすくなり、全体を管理していたホストは無事だったがローカルサーバーのいくつかはシャットダウンしてメールやWEBの閲覧ができなくなった。バックアップしていたデータで完全回復までに1週間がかかり、業務の遅滞や停止で損害を受けたユーザーからペナルティを請求された。それで収まるかに見えたが、ユーザーから発信元不明のスパムメールが大量に寄せられているとの指摘で管理していた顧客名簿が流出していたことがわかった。すぐさま対策本部を設置して顧客と連絡を取りパスワードやメールアドレスの変更を依頼して対応した。

  こうして新製品 I の出だしは好調だったものの技術的にも、販売方法や運用にも課題が多かったので代替案としてAHP評価で順位が2番目だったプロジェクトJに開発を続けさせていて、ほぼ完成していた新製品 J へと社長は切り替える決断をした。製品 I ほどの画期的な機能はないものの扱いやすく必要十分な処理能力と操作性があったので目標の80%を維持することができた。

  予測や判断は結果が出てから正しかったかどうかがわかる。予測は同じ経験をした期間だけが可能だ。たとえば製品 I を3か月販売したらその後の3か月は経験した3か月のデータでほぼ正確な予測が可能だが3か月以降は判断するしかない。データに基づく推測は予測だが、経験が全く無く、データに基づかない推測は予想-当たるかどうかわからないがとにかく方向を決めるしかない。新製品 I はネットワークに特化することが他社の製品とを差別化し、新しい顧客を獲得するという「予想」に基づいて判断された。その予想は間違いではなかったが別の理由で売り上げ増という成果を上げることはできなかった。正しいかどうか何を基準にするかは議論の余地はあるが考え方が正しかったとしても結果的にビジネスが立ち行かなければ正しいとは言い難い。

  巷間、数多の経営(者)論があるがたまたま成功したビジネスを分析した結果、その成功の法則を見出しただけで、これから成功するビジネスの法則については予想するしかない。当たるか当たらないかはその企業の組織力と社長のリーダーシップにかかっている。経営論で確かなのはこの点だけではないだろうか。
Claim4

2015年11月22日 (日)

クレームへの対応-総集編(3)

  統合プロジェクトの分科会は言葉の混乱があり、チーム結成:forming段階でまず用語集を作り互いに理解できる共通語の用語集を作ることから始まった。特に略語は同じ3文字でも全く異なるケースがあった。そのため略語はすべて日本語表記として英文字・カタカナ・省略による略語は廃止した。あえて使う場合はフルスペルで使うことを申し合わせた。用語集の作成段階では2000~3000ぐらいあった語彙は80%にその部署でしか通じない造語や同じ意味でも表記が違う重複・派生語があり、最低限必要で根拠がある専門用語や技術用語にまとめると200前後になった。この決められた用語で会議が始まった当初は混乱もあったが数か月もするとすっかり定着して社内コミュニケーションもよくなった。理解が難しく複雑な内容ほど簡単にわかりやすく話し、聞く側も理解できないことは質問して確認することで相互理解が進むがそうしたコミュニケーションの基本ができていなかった。

  合併前は両社ともビジネス分野で業績を伸ばしていたがダウンサイジングと情報化社会の波が押し寄せ、スモールオフィスやホームオフィス(SOHO)へと市場は激変し、資本や実績がなくても技術力があれば設計以外をアウトソーシングするビジネスモデルの起業が雨後の竹の子のように乱立した。竹の子は瞬く間に竹藪になり、急速に奪われる市場を取り戻し、ビジネスを拡大するため合併後の重要方針のとしてSOHOへの事業展開が決まった。

  時を同じくしてPL法が発効となり、通常の障害でも欠陥品として対応を要求する声がコールセンターにも上がるようになってきた。企業ユーザーは保守サービスも含めて製品を購入、運用技術もあるのでコールは多いもののクレームに発展するケースは月に数件だったが、SOHO製品は製品知識がほとんどない一般ユーザーで修理代が高額になるとクレームに発展するケースが多かった。これまではある程度の障害発生を見積もって3年前後の保守サービス費用を含めていたが価格を低く抑えるため1年保証に限定し、保証期間の延長は
購入時にオプションとしたことがユーザーにうまく伝わっていなかった。

  ケース4.コミュニケーションの混乱がクレームに発展した問題

      顧客から障害についてのコールが入るとコールセンターで対応できる案件はマニュアル通り処理されるが、技術的な内容や顧客が感情的になっている案件は2段階でエスカレーションされる。合併前は90%以上がこの第1段階で処理されていたが合併直後は正しく情報が伝わらず顧客に何度も内容を確認したり、担当者が決まらずたらい回しにされるケースが増えた。創業時からの顧客がそうした扱いを受け(元)社長が謝罪するといった事態にもなった。

  社内の混乱した状況はインターネットの普及とともに流行りだした電子掲示板(BBS)に投稿され、それがマスコミに取り上げられ、「合併早くも破綻」などと騒ぎ立てられた。統合が完了するまでの3か月間、社長は何度も会見を行い、検察の取り調べのような記者の質問に真摯に答える姿勢から誠実さ・真摯さが伝わり、騒ぎは収拾した。

  ケース5.障害情報の隠蔽体質が招いた問題

       合併前に設計されて持ち込みとなった新製品は十分な確認もされないまま、最後の製品ということで押し切られる形で合併記念のキャンペーンとして発売された。その直後から障害の発生が製造ラインや現場から報告されていたのだが、隠蔽体質だったため内部処理され続け、3か月後になって消費者センターや当局から指摘を受けて問題が発覚した。社長は責任者や関係者を問いただしたが「会社のため」とか「お客様のため」とか言い訳をするばかりだった。出荷検査データは確かに規格内だったが再検査すると基準を超える製品もあったのでさらに追及するとデータを捏造や改竄したことがわかった。リコールで製品回収を行い収拾にはさらに3か月を要した。

 社長は責任者を解雇、関係者を降格や減給処分にした。ところがこれを不服として訴訟が起こされ問題はさらに大きくなってしまった。マスコミはこの時も事実を捻じ曲げて処分者を擁護したためその対応も困難を極めた。この騒動に乗じて旧勢力が乗っ取りをも画策した模様で激しい抵抗にあって一時は合併解消や分社も検討された。その窮地を救ったのが海外派遣組による不正なデータ操作や証拠隠滅の事実の暴露であった。

  この海外派遣組は高い専門能力を持った技術者や管理者であったが約50名で旧社内にあって協調性がないために組織から弾かれて海外ビジネス展開として体よく追い出された連中だ。旧本社のリストラの意図に反して理不尽な抑圧から解放された「はみ出し組」は水を得た魚のように嬉々として拠点を作り、販路を広げ、現地生産工場まで稼働させてしまった。この工場ではコストを下げるために国内の製品を生産していたがエンジニアの大半が去ってしまった旧本社に代わって製品開発を始め、それが合併直後に持ち込まれた新製品だった。直前まで合併の事実を知らされておらず旧本社への反感が高まっていた。追い打ちをかけるように障害が海外工場の責任であるかのような報告をされたためくすぶっていた怒りが爆発して旧本社の隠蔽工作した旧役員とその一派をを訴えるに至った。

  不正が明るみになるにつれて不利を覚った旧勢力は訴えを取り下げ派閥を作っていた管理職とともに身を引いた。こうして後に55日戦争と呼ばれた社内紛争は収拾、最悪のシナリオだった分裂は何とか回避されたが双方に禍根を残した。とりわけ旧本社に取り残された若手社員は将来を悲観して出社しなくなったり、心の病に罹るケースも出てきた。社長はこの若手社員と個別に面談し、海外ビジネスの目的や使命について熱く語り、海外展開要員としてすでに編成していたスタッフ50人とともに海外に送り出した。海外生活に順応できず何人かは脱落して日本に戻ったが、多くはダイナミックな海外ビジネスに魅了され、先輩社員やスタッフの手厚い支援もあって半年もたたないうちに成果を上げるようになった。

  心優しい若者は傷つき、挫折しやすいが目標や役割を与えてきちんと評価すれば伸びるものだ。合併前の会社では目標となるはずの先輩社員は日々派閥争いに明け暮れ、人間関係はぎくしゃくして疑心暗鬼で疑い深く誰も信じられる状況にはなかった。夢も希望もない日々を過ごしたに違いない・・・・。このころはまだエンジニアだった営業課長は海外組の壮行会に出席して何人かと話すうちに彼らの胸の内をそう感じた。「これからは会社とか仕事とかも大事だけどその前に自分が何をしたいか見つけてくれよな。どうしても辛かったら我慢しないで俺に電話くれよ。たぶん何の役にも立てないが話だけはいくらでも聞いてあげるよ。」そうして一人一人と握手して見送った。

  一連の騒動が収束して1つのチームとして合併後の会社が起動するまでには統合プログラムが完了してからさらに1年を要した。海外展開も軌道に乗り、既存の製品は海外移管が30%近くになった。国によっては合弁会社を設立したり、使用部品の10%を現地調達しないとビジネスの許可が下りないように法律が改訂され、その対応中にクレームに発展する問題が発生した。

  ケース6.パーツのばらつきが起こした品質問題

     現地調達にはISO9000認証は必須とし、書類審査や工程監査を経て仮契約を行い、詩作試験、量産試験、信頼性検査で購入が始まる。想定外の調達リスクを避けるため3社購買を原則としている。新製品は設計変更が行われて3か月後国内販売が再開した。モバイル機器が普及し始めた時期で新製品は持ち運びにはやや重い2.5Kg であったが操作性がよいと評判で、当初のクレームを乗り越えて徐々に売り上げを伸ばしていた。ところが夏場に気温が36℃を超える地方に出した製品の一部は動作が遅くなるという問題が発生した。スペックでは-15℃~60℃を保証していたにもかかわらず、不具合品の特性は常温では全く問題ないが恒温槽で温度を上げると同じ症状が再現した。  返品が相次いだが常温で検査すると正常と判定されるため修理の必要なしと判定されて顧客に返送された。そのようなやり取りが三回以上にもなるとさすがに顧客も我慢できずクレームになった。在庫品を調べると温度を上げても不具合が発生する製品と全く問題ない製品があることが分かった。さらに調べると電源供給モジュールのノイズが原因であることが分かった。常温では問題ないが構成部品の耐熱性にばらつきが大きいためノイズを発生して制御信号ラインに回り込み処理速度を低下させることが根本原因であることが分かった。場合によってはデータを消失させたり破壊する恐れがあるためリコールを申請、回収に6か月もかかった。

  この品質問題を機にISO9000の社内監査でコンプライアンスを厳しくチェックするようになった。その結果文書化だけで実際には行われていない内容が多く検出され、根本的に品質マネジメントの見直しが行われた。品質マネジメントの品質保証はコンプライアンスを重視、品質管理はシックスシグマを導入して強化を図った。全社を挙げて品質向上を目指す・・・といったスローガンを掲げたところでそれを具体的に実現する仕組み、管理、評価、改善-本来の意味でのマネジメントができていなければ紙に書かれただけの仕組みになってしまう。人が機械のように管理・制御できない以上、問題を起こしたらすぐに察知して大きくならないうちに解決する仕組みを作らなければならない。そのためには個人や組織のあり方から問い直さなければならないのかもしれない。それはかつて「哲学」と言われていた。心の中心(理念)とばらつき(行動)の範囲を決める-それが行動規範につながり、良心に従った行動-「
品質」を生むのではないだろうか。

Claim3

2015年11月18日 (水)

クレームへの対応-総集編(2)

   クレームの聞き取り調査は新会社として独立してから5年後の合併前後に起きた一連の問題に移った・・・。

  グローバル化の追い風もあって事業は順調に発展し規模が3倍になった。時代がハードからソフトへ情報化に変革することを予見して元社長は情報機器とネットワークの草分け的企業の買収を決断した。買収条件の折り合いがつかず、株主の反対もあって難航したが6か月の交渉の末、対等合併で合意した。ほぼ同じくらいの事業規模だったため単純に計算すると2倍、創業時の6倍になるはずだったが、実際は業績が悪化して負債を抱えていたため合併時にはほぼ半分であった。事業を支えていた中堅エンジニアは合併直前に希望退職で会社を去り、残ったのは再就職が難しい管理職中心の50代後半と業務経験が浅い20代前半の社員ばかりであった。

  合併後業務の引き継ぎや新しい体制作りのためプロジェクトチームが結成され、双方から各部門の代表が集まり、3か月後の新体制発足までのロードマップ-120日計画が策定された。後にさまざまなプロジェクト管理に応用されることになる「10ステップロードマップ」とよばれる基本計画で次のような内容にまとめられる。


   Step 1: 統合の目的・目標・統合の進捗度の評価尺度と
             全体計画を立てる。
   Step 2: 人材・設備・資金・情報・顧客・市場など経営資源を
             調査してまとめる。
   Step 3:: 営業・企画・設計・製造・販売・保守のプロセスと
              付加価値・利益構造を比較、差異を分析してまとめる。
   Step 4: 人事制度や育成・管理、職場環境、福利厚生、文化など
              人的資源の管理方法を比較、差異を分析してまとめる。
   Step 5: 分析結果に基づいて顧客とその市場の要求達成を
             目的とする体制・組織・プロセスなどあるべき企業形態を
              明確にし、経営資源の統合戦略をまとめる。
  Step 6: 統合戦略を統合計画のスケジュールに沿って具体的な
              実施内容と個別目標、責任者を決め、資源を配分する。
   Step 7: 個別の具体的な計画に沿って整理統合を進める。
   Step 8: 統合によって生じた余剰人員の処遇、設備の処分などを
               決め、問題が起きないように調整しながら実行する。          
   Step 9: 統合計画の進捗を評価しながら目標・目的を達成したか
              判断し、新体制をスタート、顧客や社員、株主など
              ステークホルダーに説明、合意・承認を得る。
  Step10: 統合計画から引き継いだ事業継続計画へ移行する。

  (現)営業課長が技術部員として入社した直後に合併があり、社内は騒然としていた。配属が決まっていなかったこともあり、合併の混乱が遠因となったクレームやリコールの対応で2週間の新入社員研修が終わると顧客対応のため全国を飛び回った。同期入社の(現)企画課長は学生時代体育会系の部長という経験を買われて統合プロジェクトの分科会のファシリテーションをよく任されたという。最初は要領がわからず声の大きさだけで会議を仕切っていたが回を重ねるごとに櫛の歯を引くようにメンバーが出席しなくなり、代理で出席していた同期の(現)品質保証課長だけとなることがあった。同じ統合プロジェクト会議でも予算配分や組織統合、人事制度など利害のある経理・人事関連の会議は常に盛況であった。

  企画課長が進捗会議でプロジェクトリーダーに遅々として進まない状況を報告したところ、ファシリテーションに有効な手法として6色ハット発想法を勧められ米国本社で定期的に開催されるトレーナー研修に参加することになった。それまでもさまざまな研修を受けたがどれも会議の準備や発言の方法や議事録のまとめ方といった手法だったり、会議を盛り上げるためのヒントだとか形式的か会議の目的である合意形成にはあまり有効でない内容だった。このことを知ったのは6色ハット発想法が対立を解消し、同時に発想を変えるという考え方を根本から変える手法であることを体得してからだ。

  6色ハット発想法の研修から戻るとすぐに、企画課長は社内トレーニングを開始し、ファシリテータを育成する傍ら、自らも合併で発生し始めた問題の対策会議に出席してファシリテータを買って出て腕を磨いた。丸1日かけても結論が出なかった会議が20分で解決するケースが増えてくるようになり、統合プロジェクトチームでは標準的なファシリテーションツールとなった。しかしそれも統合が完了するとあまり使われなくなり、所属していた企画部内だけで細々と続けられた。というのも本来はハットを意識するだけでよいのだが、発想を切り替えやすくするためにボール紙で6色ハットを作り、ファシリテータの指示に従ってハットを着脱することが抵抗があったようだ。また、利害が対立したり、無関心なメンバーがいると6色ハットの仕組みが無意味になってしまうこともあった。

  会議に遅れることや時間通りに会議が終わらないことは日常茶飯事、会議室の予約が優先権を持つプロジェクトに占有されたり、予約はとっても実際に会議が行われなかったり、いくつもの会議の掛け持ちで出席に無理があったり、会議以前のモラルに問題があった。また、会議が行われたとしても重要案件は会議の最後のほうで話されるため時間切れで決まらなかったり、決まった事案も守られなかったり、最初からできない問題や議論しても結論が出ない問題、理想論ばかりで具体策が出ない、責任転嫁や回避が横行して会議の体をなしていなかった。

  最初の合併当時はそのような状況であったから現在では数時間で解決する問題が十分な対策会議ができないまま無為に
時間ばかりが経ってクレームへと発展していった。営業課長は日記のようにつけていた議事録を眺めながら当時を思い出し、聞き取りする人とのアポイントを取っていた。

Claim2

2015年11月16日 (月)

クレームへの対応-総集編(1)

   営業課長は見送りのターミナルで開発課長からこれまでのクレーム対応について聞き取り調査を行い、まとめておくように依頼された。帰国後、品質保証課長と品質マネジメントシステムを再構築するためだ。休暇とはいえスケジュールの半分は企業訪問やカンファレンス出席が組まれている。新社長の計らいで海外旅行をプレゼントされたことへの感謝の意もあった。

  クレームはその影響の拡大を防いだり、回避する方法はあるが完全に防止する有効な対策はないというのが営業課長の持論だ。クレームはその発生を如何に早く検知し、影響のステージを認識し、そのステージ以上に上げない対策を矢継ぎ早に講じる-それしか無い。それにはクレームのパターンを見極め、決められた対応プロセスを粛々と進めることだ。手始めに損害が数千万円以上に発展したクレームをまとめることにした。

  聞き取りしたクレーム事例は製品と関連付けて時系列にストーリーとして理解できるようにした。こうしたデータベースはかつては起こった事実をカードに箇条書きにして検索語をつけたものだが、全文検索が可能になった現在、検索のしやすさよりも問題の理解度と定着が重要になる。同じような局面になったときに想起させ、既知の問題は時を移さず対策を実行、未知の問題は現状分析、想定外の問題はリスク分析の判断を行うためだ。まずは発足当時のクレームの掘り起こしを行い3つのケースにまとめた。

 ケース1.クレーム自体が目的だった製品Eの規格問題

   15年前、前社長が当時は現役だったベテランエンジニアや有志社員を集めて親会社から独立した。その半年後、業界の常識を打ち破る低コスト高性能の製品Eを開発、華々しくキャンペーンを展開したことが功を奏して発売後3か月は順調に売り上げを伸ばした。ところが半年後になると規格に合わないという理由で返品が相次いだ。調査すると元親会社が製品Eの3か月後追うようにリリースしたほぼほぼ同性能の新製品が製品Eの規格と異なるためとわかった。元親会社の製品が国内ではデファクトスタンダードであるのに対し新製品Eはグローバルスタンダードに準じていた。前社長は日本製品のガラパゴス化に危機感を抱いておりグローバル化を目指していた。ところが業界では受け入れられず返品と激しいクレームに見舞われた。それでも外資系の顧客からは支持され、なんとかその後の5年間をもちこたえ、海外から安価な製品が輸入され国内規格はグローバル化せざるを得ない状況となり、売り上げを伸ばし始めた。国内に限らず海外の企業は自社の有利になるように規格の変更を行う。ゲームのルールを変えたらそのルールで戦うか、自社のルールに信念をもって戦うしかない。両者に適合するような戦術もあるがマーケットをしっかり見据えて将来性のあるセグメントを選択・集中する経営判断が求められる。

 ケース2.社内事情がクレームを大きくした問題

   製品Eのクレーム問題の対策として各部がばらばらに対応していたのを「お客様相談窓口」に集約しクレームを一括処理する仕組みに変えた。最初は週に数件だった案件が1か月後には5倍、3か月後には10倍と増え続け、コールセンターが新設された。相談窓口やコールセンターに集められたスタッフは各部の余剰人員-リストラ予備軍のため製品知識が深いわけでもなく、顧客対応のノウハウを熟知しているわけではなく問題解決は長期化した。問題が発生するとすぐにコールセンターに転送される仕組みで丸投げされた問題をスタッフが各部に事情聴収しながら顧客に対応せざるを得なかった。返品や返金に応じればそのコストの拠出を巡って紛糾し、技術的な問題は顧客の使い方が悪いという一点張りで一向に改善されない、品質に問題があってもテスト方法や製造規格を変えようとしない。そのうえ、問題が拡大・長期化して売り上げが減ると対応のまずさに責任転嫁される始末であった。やがてスタッフは半減し、ほとんど未処理で問題が長期間放置され、クレームはますます多く、深刻になった。

  ケース3.コミットを守らず、納期や要求が守れなかった問題

   ほどなくしてコールセンターが機能しなくなったためアウトソーシングに切り替えるようになった。コール件数は減らなかったが処理スピードが上がり、アウトソーシング前のように処理能力を超えることはなくなった。コールの50%は問い合わせや相談、25%は既知の問題でコールセンターの対応マニュアルの範囲で処理できた。残りの25%のうち、5%は社内の専門スタッフが関連部署に振り分けることによって解決を図った。20%は受注時に要求定義があいまいなことや機能説明が不十分でコミットした仕様が守れず、無理な納期のために大幅な遅延を起した問題だった。そのために数千万円のペナルティを払ったり、大形案件のキャンセルによる損失が発生した。


  このようにクレームのケースをまとめた後はWhy-5W1Hでなぜなぜ分析を行う。問題が起きるのは5W1Hの情報のどれかが欠けていることが多い。情報はむしろ不完全なほうが分析しやすいと開発課長が出発間際に言ったことを思い出した。

 Why-5W1H:起こった事実
  Why-What :なぜその製品やサービスに起きたのか
  Why-Were :なぜその場所や部分で起きたのか
  Why-When :なぜその時間やタイミングで起きたのか
  Why-Who  :なぜその組織や個人で起きたのか
  Why-Why  :なぜ原因や根拠、理由がわからないのか
  Why-How  :なぜ発生プロセスや問題の大きさがわからないのか

 同時にWhy Not-5W1H - 起こらなかった事実についても可能な限り調査しておく。問題の原因調査で陥りがちなのは詳細に不要な情報まで全体像をつかもうとすることだ。起こった事実と起こらなかった事実の比較によって原因はその違いから分かるものだ。全体像を分析したところで原因が細切れにされて真実はジグソーパズルのようになって本質が見えなくなってしまう。責任の所在が分からなくなるのは詳細すぎたり、対象規模が大きすぎる誤った調査の結果だ。何か月もかけて分厚い調査報告書を作ることが目的になり、効果的な対策は行われない。製品サイクルより長い調査が終わったころには次の製品に代わっている。調査スタッフの努力にもかかわらず報告が無駄になることがしばしばあった。調査の前に結果をどのように分析して判断に生かすかを決めておかずむやみに情報を集めても無駄な努力になることになかなか気づかない。

  営業課長はこうした過去の問題も振り返りながら聞き取りを進めた。

Claim1


2013年8月 2日 (金)

製造部クレーム対応-根本原因の追及(後編)

  判明した根本原因が取り除けない場合は現状のメカニズムでは不可能ということなので設計を変更する以外に改善の方法はない。解決するにはいままでとは全く違った考え方をしなければならない。そのヒントはベテランエンジニアの製品Zの開発プロセスにあった。

  昨年製品Xが大量の問題を発生して市場を失いつつあったとき、ベテランエンジニアが集められて製品Zが開発された。ベテランエンジニアはこれが最後の仕事になることが分かっており、集大成の意味も込めて製品Zと名付けていた。通常は10名程度のプロジェクトで新製品が開発されるが、1ヶ月以内に製品Xと同等の処理能力を目標としたため約30名でデザイン・ハードウェア・ソフトウェアが同時進行で開発された。

  開発方針として新しく設計を変更する時間がないので製品Xのハードウェアはメーカーが異なる同等品で組み合わせの最適化、ソフトウェアは基本ロジックは変えずにパラメータを変えて最適水準を選定することにした。何度かの打ち合わせの結果ハードウェア(HW1~8)の8種類、ソフトウェア(SW1~2)の2種類のパラメータを変更して実験を行った。特性値は望小特性の内部温度上昇として外側に使用環境の標準条件と最悪条件を配置してSN比で評価した。
<図表はクリックで拡大>
L12xvsz

  結果はハードウェアHW1、HW7、ソフトウェアSW2を変更することで内部温度上昇を抑えられることが分かった。ハードウェアは製品Xの開発時に信頼性試験を行っており、保守部品の代替品としても登録してあったので、すぐに量産体制に入り、製品Xと置き換えられて販売された。ただ、HW7は温度上昇が少ない分、処理能力に問題があった。この問題が分かっていても設計変更は出来ないので定期点検で問題発生を感知して現場で対応するしかない。そのためベテランエンジニアは現場でよく使われているKY(危険予知)の問題解決4ラウンドで6色ハット発想法を使って話し合い、定期点検の最適化を行っていた。
Optimizecheck_2   
  開発課長はこうしたベテランエンジニアによる危険予知と定期点検の最適化を含むシステムの運用探索方法をRFA(Route Finding Analysis)としてまとめた。
Rfa_2
RCAは問題がゆっくり大きくなる製造ラインのような状況では対策に十分時間が取れるので損失は大きくならないが情報システムのように短時間で状況が変わる場合には原因が分かってから対応するのではその時間の遅れが致命的になる。過去に起きた通信システム障害では数分の遅れが数万人の個人データ損失を引き起こしたことがあった。そのバックアップはマニュアル作業で行われ回復までに数ヶ月、数千万の損失となった。RFAは予測しながらそうした危険を回避し、想定外の問題が起きそうな場合はすぐに回復できるようにバックアップしたり、分散処理でリスクを分散させたり、最悪でも安全にシステムをシャットダウンさせるようになっている。また、問題が予測との差という形でフィードバックされ、ログにも残るので、あとから問題を再現させて根本原因を追及するのも容易になる。

  こうして開発課長は新製品Vの開発、再発防止のRFAの導入・標準化で製品Qの問題解決を同時に終えた。開発された製品Vは客先でもクレーム対策の最終案として提案され、新たに建設されるデータセンターに納入されることが決まった。RFAは公開され客先のデータベースで運用して効果を確認、客先でもソリューションパッケージとして販売されることになった。プロジェクトメンバーには1ヶ月の休暇と報償が与えられた。開発課長は休養をかねて次のプロジェクトを模索するためにアメリカに旅立った。
Vacance

2013年7月 4日 (木)

製造部クレーム対応-根本原因の追及(中編)

  5月の連休明けから製品Zへの置き換えが始まり、変更した計画は予定どおり6月いっぱいで完了、本稼働となった。製品Qは引き上げられさまざまな試験を行ったがシミュレーションのとおり記憶装置の過熱以外の原因は見当たらなかった。交換した製品Zは発売当初は障害が発生したもののベテランエンジニアが問題が大きくなる前に未然に防ぎ次々と応急処置が採られ、設計にフィードバックされ初期流動期間が終わる頃には偶発故障レベルに終息していた。開発課長は根本原因の追及方法と有効な対策の実施についてベテランエンジニアに何度も確認したが「あなたたちが古い考え方と言っているKKD(勘と経験と度胸)だよ」と答えるだけだった。数年前から 「KKDから科学へ」を合い言葉にLean Six Sigma を全社的に導入している。

  根本原因の追及はRoot Cause Analysis(RCA)と呼ばれ、問題解決の起点になる。その方法や考え方はさまざまだが、問題を絞り込み、有効な対策を実行するという流れは同じだ。表現が違うのは成功事例が異なるからだ。問題が発生すると症状や規模に従った対策が講じられる。その対策の中でたまたま結果が良かった事例が成功事例となり、結果から原因が想定されその解決プロセスが既成の改善手法で脚色され、
関係が薄い人間までお手柄を分けようとするあまり〇〇道具や✕✕法といった実際には使ってもいない改善手法が説明の手段として総動員されるのだ。上層部になるほど成功談を好む傾向があるのでマネジメントに報告されるころには全く別の話になっていることがあった。<図表はクリックで拡大>
Rca

  問題が解決するかどうかはプロジェクトチームの洞察力や分析能力、創造力やマネジメントの判断力であって、改善手法はその手段に過ぎない。 問題が起きたときに手当たり次第思いつく対策を打ってみて、全体として効果があった対策から原因の所在を探り当て解決して行くというのが実際の姿ではないだろうか。成功した事例を説明できるなら失敗した事例も説明できるはずだが、失敗事例をこうした説明の道具で根本原因を追及した事例は皆無だ。

  その理由は、
失敗した場合は誰か1人が責任追及されるのがこれまでは慣習のようになっていたからだ。以前、営業課長は営業部長と問題を起こした客先に何度も謝罪して回り、約半年が過ぎた頃、辞職を決意していた。
思いとどまったのは・・・

「君が辞めたらこの悪習はなくならない。奥さんほど君のことを知らないが会社での君はよく知っているつもりだ。辛い気持ちはよく分かるが,俺と一緒に乗り切ってこれ以上君のような有能な人材が犠牲になるのを止めにしないか。」

・・・と営業部長に説得されたためだ。問題が解決するのは全体の3割程度、あとの7割のうち3割は客先から取引を停止され、3割は営業課長のように誰かしらが責任を取らされて会社を去り、1割は気づかれないように隠し続け事実は関係者だけが握っているようだ。

  こうした事実は新社長が設置した外部の役員で構成される倫理委員会の調査で次々と判明した。新社長は先代社長の孫にあたり、2年前から取締役として営業本部長を務めてきた。
業績悪化で若返りを望む声が増え、6月の取締役会議のクーデターで擁立され株主総会で旧役員の総退陣とともに承認された。この筋書きは新社長の父でもあった専務が計画、昨年から慎重に根回しされ、実現した。倫理委員会は「同族企業の弊害」を払拭するためにも断行しなければならず、旧社長派も同時に一掃された。

  それどころか組織もすべて解体され、事務処理など日常業務はアウトソーシングに移行、開発・試作・販売・営業は国内でプロジェクト・ネットワーク型に再編成、海外工場や拠点は現地法人化やEMS・OEMまたは譲渡され独立採算の協力会社として切り離された。現地で指揮を執っていた工場長や事業部長、指導していたエンジニア約300名はすべて8月までに帰国し、グローバル化事業プロジェクトを立ち上げる予定だ。約2000名いた社員の2割が行き場を失い、その半数の社員はどのプロジェクトにも属せず早期退職プログラムに応じ、残りの社員は業務移行先のアウトソーシング会社に再就職した。株主からはこうした換骨奪胎の施策が好感されこのところ株価は連日高値を更新している。

  プロジェクトチームはアメリカン・フットボールの構成と同じオフェンスとディフェンスに別れ、オフェンスは新製品や新規顧客開拓といった新しい分野を開拓するチームで5-10年後に会社をリードする若手中心に結成され、ディフェンスはライフサイクルの後半にある製品群の改善、プロセス改善や大口顧客、得意先との関係維持、満足度の向上-CRMや持続可能な企業をめざす-CSRといった現状の枠組みを維持するプロジェクトチームが中堅やベテランで結成された。結成された全チームはディシジョンパッケージと呼ばれる計画書を作成し、ゼロベース予算方式による費用対効果で順位づけ、上位から順に360チームに予算が配分された。オフェンスが3チームディフェンスが10チーム予算配分がされず次の四半期末までグローバル化事業プロジェクトの準備要員として仮配属が決定された。
Zbb2
  プロジェクトの運営は上位10チームのパッケージが社長決裁、50チームが取締役決裁、以下はプロジェクトチームのリーダーに決裁がゆだねられた。さらにSWOT分析により、各チームの戦略ポジショニングが行われた。
Zbb3
  オフェンスとディフェンスは4半期ごとに「審判団」の役割を持った外部の調査機関による市場調査、内部調査で対象となる市場でチームの交代が告げられる。新製品が立ち上がるとオフェンスチームからディフェンスチームへプロセスが渡され、既成製品が終息段階に入るとディフェンスチームからオフェンスチームへ次の製品開発に必要な顧客の要求や動向の情報が引き渡される。また四半期の途中でもリードを奪われたり、障害が発生して市場を失いそうなときにも交代が告げられる。これは「主コーチ」役の新社長と、バランスト・スコアカードの指標である財務・顧客・業務プロセス・成長戦略を担当する4人の取締役の「副コーチ」による「コーチ陣」が行う。 

  コーチ陣が正確な判断が出来るように定年退職したベテランが集められ、市場での活動状況が逐一報告される。報告内容はプロジェクトチームにも公開され、事実と異なる場合は修正され、報告ルールが変更されるか、報告者を交代するしくみになっている。プロジェクトチームは会社で使えるすべての権限が与えられるが、結果の責任はすべてのコーチ陣の判断の責任として処理される。誤りの大きさによっては新社長が退陣することもありうるので、経営リスク回避のしくみも同時に作られた。

  こうした変革によって顧客に直接対応し、瞬時に判断するしくみになったため、これまでの会社の目標達成から顧客の要求の達成がプロジェクトの目標になり、年度方針はすべて破棄された。顧客があるからこそ会社が存在するのだ。それを忘れ自社に都合の良い顧客不在のMissionやVision、経営目標など達成するはずがない。顧客と出会う「真実の瞬間」にその要求のすべてに尽くす覚悟と志が求められるのだ。

  製品を単に売るのではなくその製品によって顧客のどのような要求が実現するのか-モノが作り出す価値を提供するように考え方が変わった。これまでは製品に見合う顧客を探して売りつけていたが、これを機に顧客の要求を実現する製品を探して組み合わせ、顧客が最適なものを選ぶ選択肢を提供するように行動が変わった。顧客が必要とする価値を提供するのが商売では当たり前なのだが、「押し売り体質」からの変化があまりにも急だったため辞める社員もいた。いつも丸投げで要求仕様を明確に出来ない顧客は自社の要求をまとめる煩わしさから去って行った。変革には痛みがつきものだ。ここで止める
わけにはいかない。まだ始まったばかりなのだ。

  開発課長はオフェンスプロジェクトとして製品Vの開発チームのQB(指揮官)となった。プロジェクトをまとめる会議では6色ハット発想法を使って

  目的:Red Hat で顧客の要求にあった「目的」を直感的に選定した。
  開発目標:Black Hatで目的を達成するための条件として決めた。
  製品概要:QFDを元にBlue Hatでセールスポイントをまとめた。
  評価尺度:Yellow Hatで目標達成時の利益を予想した。
  リソース:Black Hatで最小限のリソースを求めた。
  却下された場合の結果:Black Hatで損失を想定した。
  他の水準:Black Hatでさらにコスト削減できないか検討した。
  代替案:Green HatのAlternativeでアイデアを出し合った。

のシーケンスでファシリテーションを行いパッケージをまとめた。
Zbb1
  稼働時の熱分布をシミュレーションした結果が実機に良くあてはまることが実験的にも確認され、開発課長はベテランエンジニアの知恵を移植したシミュレータが完成に近づいていることを実感した。

2013年5月14日 (火)

製造部クレーム対応-根本原因の追及(前編)

  これまでの対策は消火活動に例えれば延焼防止-製品Zに置き替えることで問題の製品Qによる影響の除去で原因そのものは取り除けていない。根本原因を追及するときには「なぜなぜ5回」がよく使われていて問題は顧客の要求するレベルまでは改善していたので製品Qの記憶装置の過熱についても分析した。

  なぜ製品Qの記憶装置部分が過熱したのか
     →①発生した熱を十分排気出来なかったからだ
     なぜ十分排気できなかったのか
        →②冷却装置の能力が不十分だったからだ
        なぜ冷却能力が不十分だったのか
           →③設計を上回る蓄熱が起きたからだ
           なぜ蓄熱が設計値を超えたのか
              →④代替えで組み込んだ同等品だったからだ
              なぜ、同等品だと設計値を超える蓄熱が起きるのか
                 →⑤設計では考慮していない密集度が高くなったからだ


  今回の「記憶装置部分の過熱」のような問題は新製品を発売するたびに大なり小なり発生していた。対策としてシステムを冗長化して「過熱」したら切り替えるようにしていた。製品Qは制御装置に過熱を感知すると冷却装置のファンの回転数を上げるなどして単体で回避できるしくみを初めて採り入れた。国内で組み立てたシステムの稼働実験では良好な成績だったので、海外工場で生産した製品については生産の遅れもあって、十分な確認実験もせずに出荷してしまった。そこで製品Zと製品Qが稼働時にどのような熱分布になるかをサーモグラフィーで確認した。<図表はクリックで拡大> 
Cooling  なぜなぜ分析の①~④までは既知の原因でこのサーモグラフィーを使った実験で確認でき、製品Zに交換して本稼働させる応急処置の根拠となった。なぜなぜ分析のように原因追及のプロセスで既知の原因では分からなくなるところ-技術力や知見の限界-これが現時点での根本原因といえる。こうして既知と未知の境界として推定された根本原因を仮説として実験で真偽を検証しなければ真の原因かどうかはわからない。また密集度が実験で有意な要因として仮説が成り立ったとしてもなぜそれが過熱の原因となり得るかメカニズムとそれを制御する因子-加法性のある要因を確定できなければ過熱の原因を変えて好ましい結果を得ることは出来ない。

  そこで、営業課長は同期入社の技術部開発課長に放熱設計のシミュレータでなぜ過熱が起きるのか検証を依頼した。開発課長は次期モデルの製品Vで手一杯だったので徹夜してシミュレータが空いている深夜に解析を行い、早朝駆けつけた営業課長に検証結果を説明した。

   ① 冷却風向と直角に配置された記憶装置により渦流が発生、熱がたまる。
   ② 冷却風通信装置・制御装置を通って弱められ風量が不十分になる。
   ③ ①の原因で蓄熱場所の制御装置がシステム停止の誤動作を起こす。

  開発課長は製品Qの開発時点からこの問題に気づいており、有効な対策を考えつけないまま営業サイドから売り上げ挽回のための販売計画に押し切られてリリースしてしまった。開発課長は技術部長に何度もこの不具合について改善を訴えたが、すでに海外工場での組み立てが始まり、営業活動も記憶容量が向上することをセールスポイントとして売り込みにかかっており、その訴えは黙殺されたばかりか他言も禁じられた。

  開発課長はクレーム発生で社内が騒然としていたときに黙々と改善に向かっていてた。再現実験に立ち会ったとき記憶装置のレイアウトが主要因と推定されたので、記憶装置の容量は変えずにレイアウトをさまざまに変えて放熱特性のシミュレータでテストして最適条件を探していた。営業課長からの依頼はその最適条件がほぼ確定したタイミングであった。開発課長はその記憶装置のレイアウトから製品Vと名付けていて、営業課長には製品Qとの比較で説明した。  製品Vは冷却装置を記憶装置の直前に配置して風量を確保し、風向に対して取り付け角度を調整できるようにし、記憶装置の外形寸法のばらつきに対してもクリアランスを調整できるようにしていた。
Coolingv_2  営業課長は開発課長がクレーム発生後の数ヶ月どんな気持ちで過ごしていたかを思いながら説明を聞いていた。営業課長が技術部にいた頃、開発した新製品の性能や品質をめぐって技術部長と対立し、
社長に直訴するという非常手段で出荷を止めたことがある。それによって販売計画は大幅に遅れ、ようやく出荷できたものの営業課長の言ったとおり市場で仕様通りの性能が出ず、品質問題も発生して販売不振を招き、業績が落ち込んでしまった。その責任は判断を誤った技術部長に求められるべきだったが、開発リーダーだった営業課長に向けられ引責する形で理不尽にも人事異動で閑職に回されてしまった。営業部長は一連の流れから事情を知って、営業課長を営業部に招いた。

  それから5年の歳月が経っていた。激変する市場の要求は技術的な専門知識を必要とするようになり、営業課長は営業部員の技術指導にも力を発揮して信頼されるようになった。一方、同期の開発課長は淡々と仕事をこなすタイプで技術部長から信頼されるようになり、ベテランエンジニアが去った技術部で製品Qの開発プロジェクトを任された。もともと開発課長は創造力があり、ベテランからも頼りにされていた。製品Qはその集大成になるはずだったが現実は厳しかったようだ。

  営業課長は技術部を離れるとき飲み会でベテランエンジニアから言われたことがいまでも記憶に残っている。「会社は運だよな。同期でエリートと言われていた奴が海外工場を立ち上げて帰ってきたら席がなくなって、部長と喧嘩して結局辞めたよ。まっ、長く居たかったら喧嘩しないことだ。喧嘩しないで済む方法を探すことだな。辞めてもエンジニアはどこに行っても同じさ。頑固で自分を変えないから・・・」

  営業課長は説明を終わった開発課長を連れ出して飲みに行き久しぶりに昔話を聞いた。エンジニアの頑固さはその信念から来るのだ。頑迷とは違う。ほろ酔い加減で肩を組み、いつしか降りてきた夜霧のせいでネオンが滲んで見えた。

2013年5月11日 (土)

製造部クレーム対応-対策立案・実施

   連休は営業課長を中心とした対策のまとめチームと、技術部を中心とした製品Zの置き換えによる本稼働への試験チーム、品質保証部を中心としたデータ解析チームに分かれて朝7時から夜10時頃までほとんど休みを取らずに没頭した。営業課長は系統図で先方の購買部長の期待がある項目についてRight-Hand Columnで対策を展開した。<図表はクリックで拡大>Righthand_2
  これまでは障害に対してはどのような内容でも年数が経っていても100%補Warranty_2償してきた。製品は高くても売れ、信頼性も高く保守サービス費用を含めた価格が設定できたので問題にはならなかった。低価格化が進みコストが安い海外の品質のばらつきが大きい部品を使い、海外で生産せざるを得なくなったため障害が増え、修理コストが利益を圧迫するようになった。初期不良はそうした製品の品質低下が原因なので100%補償しなければならないが、急速に技術が進歩し、使い方も過酷になっている現状では設計当時では考えられない偶発故障が発生する。

  補償支払金額は毎年、保守サービス部門でかかった費用を合計していわゆるどんぶり勘定で一律製品価格に上乗せして価格設定してきた。また、保守サービス費はパッケージ化され簡単な修理でも高額な請求をされることがあり、顧客から不満を訴えられ、不払いでもめることもあった。さらに、保守費用が合計でしかとらえられないため製品ごとの問題が把握されず、改善が進まなかった。

  営業課長はこうした状況を考慮して偶発故障域に入る2年目は50%、3年目は25%に補償額を減額し、減額分を予防保全費用にあてる補償モデルを技術部・品質保証部・業務部・財務部・法務部と検討していた。2年目以降は損失を顧客と折半するような形になるので購買部長の理解を得るのは難しいかも知れないが「話せば分かる」ことを信じて、連休明けの会議に臨んだ。

  本稼働に向けた対策を第1に考えていることが好感を持たれ会議の滑り出しは順調だった。会議では重要度の高い(相手の関心の高い)議題から話すのが鉄則だが、これまではそうした議題は追及されるので後回しにして会議終了間際に話され、いつも結論が出ずうやむやになっていた。2時間の会議では議題は4-5項目程度に絞って、最後の議題は見送られてもかまわない。

  営業課長は会議全体をそのように組み立て、本日の最重要議題「規定外の補償」をもっとも議論が活発になる3番目に持ってきて説明を始めた。

   <文字の色はハットの色>


  購買部長:「製品が原因の障害だから何年経っても補償するのは当然だろう。」
  営業課長:「確かに初期不良はその通りですが、偶発的な障害はそうともいえません。」
  購買部長:「使い方に問題があるとでもいうのかね。」
  営業部長:「その原因もありますが、設計上の限界や耐久性の原因になります。」
  購買部長:「ならば、設計を変えて信頼性を上げればいいじゃないか。」
  営業課長:「納入価格と保守料金を数倍に値上げさせていただければ可能です。」
  購買部長:「コストを上げないで出来る方法があるだろう。」
  営業課長:「設計で信頼性は決まりますので予防保全でコストをおさえられます。」
  購買部長:「それが50%、25%の意味なのか」
  営業課長:「はい。これまでの御社納入分の障害データから算定しました。」
 
購買部長:「わかった。とりあえずそれで行ってみよう。」
  営業課長:
「ありがとうございます。お怒りになるかと覚悟しておりました。」
  購買部長:
「前回は根拠のない説明ばかりで納得できなかっただけだ。」
  営業課長:
「エンジニアの説明が不十分で真意が伝わらず、申し訳ありませんでした。」
  購買部長:
「以前の人たちも説明は下手だったが、親身になって対応してくれた。」
  営業課長:
「そう仰っていただくと嬉しいですがみな早期退職いたしました。」
  購買部長:
「まぁ、我が社も合併で同じ状況だから、出来ることは助け合おう。」
  営業課長:
「ありがとうございます。ご信頼を取り戻すように努力いたします。」
  購買部長:
「理解はしたが納得していないので都度報告して欲しい。」
  営業課長:
「承知いたしました。」

  補償ルールを明確に説明したため、その後に説明した対策は大きな問題は無く受理された。
 
  営業課長は顧客のように話し相手や会議のメンバーに6色ハット発想法を知らない人たちがいるときの使い方-日常ではこのケースがほとんど-についてあらかじめ確認しておいた。その基本はOODAループを回して相手の話に寄り添うように反応して行く。すなわち、

  Observe    :相手がどのハットの色の発想をしているか観察する
  Orient       :話の内容や意味から話の流れの方向を読み取る
  Decide      :方向が同じ色のハットで発想して返事の内容を決める
  Act           :決めた内容を話して相手の反応を見る-Observeに戻る

を会議中や会話中に瞬時に行って話を進める。購買部長と営業課長は旧知の間柄で会話の流れはある程度予測がつくので発想がわかりやすく反応が容易であった。しかしながら、通常は分からない事が多いのでOpen-EndedとClose-Endedの質問を交えて流れをつくると良いと教えられた。

  Open-Ended:相手の発想のハットの色に沿って質問する。
                     【例】新しい事実は何ですか?(White Hat)
                            一言で言うとどうなりますか?(Blue Hat)
  Close-Ended:相手がどの色のハットかYesかNoで確定できるように質問する。
                     【例】ご不満を感じていらっしゃいますか?(Red Hat)
                            それは事実ですか?(White Hat)
                                     

営業課長が対策案が受理されたことを工場で待機しているスタッフやメンバーに伝えると、さっそく暫定措置としての製品Z交換による本稼働に向けたスケジュールが始まった。
Schedule

  営業課長は通常稼働テストの順調な立ち上がりを確認して技術部と品質保証部が進めている根本原因の追及と再現実験の進捗具合を確認するため工場に向かった。数日降り続いた雨も上がって晴れ間が見え始めた。

2013年4月27日 (土)

製造部クレーム対応-データの整理

  これまでのクレーム対応は現状把握が終わった段階で状況説明を行い、客先には「社員の注意徹底」や「再教育」といった適当な報告で済ませていた。実質的には技術部の指導で製造部がきちんと対策を実施していたので今回のような再発はしなかった。しかしながら、先方の吸収合併した親会社のルールでは説明責任を求められていた。

  その理由は将来この障害が原因でPL問題など訴訟が起きた場合に責任の所在を明確にしておくための記録が必要だという。個人情報が漏れて損害を受けたと事実かどうか判然としないにもかかわらず公聴会で追及されマスコミやネットでも犯罪者呼ばわりされ、明確な反論も出来ないまま数億円の賠償金を払わされた同業者がいた。その結果トップだったシェアが急落、その上巨額の賠償金支払いのため昨年は赤字に転落した。国内のビジネスは相撲の土俵、海外のビジネスは何でもありのバトルロイヤルのリンクで戦うようなもので、対戦相手が誰か分からず、弱点があれば不意を突かれて負ける。正義やルールはビジネスの勝者が決める。同じ土俵で戦えば勝てるといういいわけはグローバル化が進む現在では通用しない。

  こうした対策で記録が必要なことはもちろんだが、そうした記録によって問題発生時に履歴を追えるトレーサビリティが必要だ。それによって問題の影響の範囲を限定でき、応急処置を的確に行えるばかりでなく、原因追及も絞り込みやすい。後で訴訟になったとしても適切に対応したことを証明できる。しかしながら現状ではオンラインシステムのデータベースが機能しておらず、各部門でデータフォームも内容も管理方法も違う形でデータが散在している。そのため問題発生時の対策やレポートに統一性がなく顧客の不信感を助長してしまう。その原因は顧客の関心事に合わせて都度レポートをまとめるため常にスクラッチから始め、作られたレポートは顧客への報告以外に利用されることなく、問題が解決すると設計や関連部門にフィードバックされることなく忘れられ、データベースとはならず、経験や勘といった曖昧な記憶にしかならなかった。それが問題発生時に思いつきの対策しか出来ない根本原因でもあった。

  営業課長はエンジニアとしての経験を生かしてデータに基づいた戦略を立て営業活動を展開し、成績を上げたことが認められ昨年昇格したばかりだった。そのためデータの必要性については身に染みて感じているがそのような社員は少数派である。この対策を通じて考え方を変え、データに基づく仕事が基本動作となるように行動を変えようとした。改善は仕組みを変え、考え方を変え、その結果として行動が変わることで改善効果としてアウトプットすることであるから、そのためにデータに基づく仕事の仕組みにしなければならない。

  そこで対策を進めるに当たってどのようなデータを必要とし、そのデータの存在の有無を調査してまとめた。
<図表はクリックで拡大>

Datalist
  対策プロセスのモデルは一種の帰還増幅回路のようなシステムと考えられる。すなわち、対策内容をインプットして、そのアウトプット-問題解決の進捗や効果を定量的にデータとして測定し、インプット側や、対策中のプロジェクトチームにフィードバックすることによって対策効果の予測や計画と比較して、ギャップがあればその解消に向けた行動を起こし、期日までに問題解決を完了するシステムだ。データは White Hat でその採り方やデータから集約される情報を読み取る。読み取った内容に基づいて予測を立てるYellow Hat、判断を下すRed Hat,対策効果を高めるアイデアを出す Green Hat, さらなる問題点や障害を見いだす Black Hat、対策プロジェクトを管理するBlue Hatへと展開して行く。

  この対策プロジェクトをデータのフィードバックによって管理する仕組みは製造部の日常管理の仕組みと同じだ。

Pdsasida   いわゆる統計的品質管理で設計規格の中心と規格の範囲内に製品の性能が分布するように製造の管理限界を推定、その範囲内に収まるようにPDSAを回す。その範囲は過去の実績から統計的に推定するか、設計規格に対する安全係数で設定し、その範囲内に入るようにばらつきを調節する。日々の日常管理は短期的にはSIDAループによって変化の瞬間を感知して即座に対応し、その結果として範囲内かどうかをPDSAで長期的に管理することになる。短期にしても長期にしてもデータをとった時点で問題があれば次にデータをとるまでの間に解決しなければデータをとる意味がない。調査した結果ではデータはとられているが記録されているだけで全く使われていないのが現状だった。日常管理はデータを管理図やQC七つ道具で使うための仕組みではなく、データによるフィードバックシステムのアーキテクチャーを構築・運用することなのだ。

  かつてTQC活動を全社的に推進していたころは製造部が中心になってこうした日常管理を実施して不良が低減した。QCサークルもそれなりに成果が上がっているように見えた。しかし、今振り返ってみると、見逃していた不良が社内で見つかるようになっただけであった。その不良の原因もほとんどがワークマンシップ-正しい作業の仕方が出来ていないか、ずさんな管理にあった。つまり、こうした意識を高めるだけの活動は人が原因の問題しか解決せず、改善活動は社内発表会で報告されるだけで、発表された数ヶ月後には元に戻っていた。発表者の現場は発表会がセレモニーと分かっていたので演出に大半の時間を割き、そうして誇張された改善結果は審査員となったマネジメントが満足するだけであった。

  品質は設計された時点で決まり、それ以上良くなることはない。製造で品質が改善されたとしたらそれは取りこぼしが減ったに過ぎない。製造ラインで出来ることはいかにして工程条件を調節して設計で決めた品質に近づけられるかだけだ。生産のしやすさも設計できまるので、それ以上に対価を払わずアウトプットを求める「改善提案」や「創意工夫」は社員の時間を必要以上に拘束し、会社への無料奉仕を強要・洗脳する労働強化の道具といえる。経営者は社員の時間や能力を自由や幸福を得るための契約の範囲内で活用すべきだ。家族的な経営と言えば聞こえがよいが、その実は生殺与奪の権利を掌握して社員の全人格・全生活を支配・私物化したがる。先代社長の考え方は戦後間もないころに日々の生活がままならなかった状況では価値があった。社員の生活が安定して豊かになった今は幸福を考える時間や拘束されない自由によって得られる幸福感を出来るだけ与えることのほうが価値がある。価値観は時代とともに変わり、新しい価値観がより幸福な社会や夢を実現して行くのだ。今はその価値観の変わり目にいるのかも知れない。

  これまで生産管理といえば「生産量はより多く」=効率化、「不良数はより少なく」=品質管理という固定観念があった。簡単に言えば目標値の無い管理なのだ。「生産量前年比〇〇%」とか「不良率半減」といった目標は「もっと頑張ろう」と言っているのと同じだ。投資に見合った利益を生み出し、持続可能な経営を実現するために生き残りをかけて必ず到達しなければならないレベルが目標なのだ。もともと達成できるとは考えていないマネジメントの思いつきで立てられた「もっと頑張ろう」を言い換えただけの目標は張り紙や看板にスローガンのように描かれるだけでそうした危機感はなく、達成しようとする努力もしない。

  この誤った固定観念の「効率化」により過剰な生産量を要求され、定時間内で作業は終わらず、「品質向上」で過剰な品質管理のために選別や検査が行われていた。その結果販売予定のない過剰在庫と過剰な品質検査で性能や商品価値には全く影響の無い不良品が生産され、ラインにはリワークを待つ不良の仕掛、倉庫に売り先のない在庫が増え続けた。営業がノルマを達成するために立てた根拠のない受注予測に基づく生産計画は破綻し、大量の陳腐化した仕掛や在庫を廃棄したため昨年は実質的には大幅な赤字であった。

  設計で見積もった生産量以上に出来たらその差分は支払うべきだし、生産が予定通り達成できなければ生産性を上げられるように設計を変えるか、管理の仕方を変える以外にはない。生産計画もまた実質的な需要やその変化に応じて設計や生産の根拠を与える情報として提供されなければならない。そうした設計や生産、情報管理の善し悪し-品質マネジメントシステムが直感的に判断できるような「見える化」なら良いが、コンサルタントの指導によって導入された「見える化」は責任を追及するための「見える化」としか利用されず、作業者を晒しものにして追い詰め、恐怖感を与えるだけの道具に過ぎなかった。「見える化」はマネジメントシステム-経営に求められるのであって設計-生産-販売の企業活動はきちんと経営機能の仕様通りに設計され常に見えなければならないのだ。営業課長は「見える化」を現場に求めるのは経営機能が無いためだと理解するようになった。

  これは顧客の要求にもいえることで規格や仕様が決まっているにもかかわらず、それ以上の性能を要求したり、不良のような品質問題は全く発生しないことを要求するばかりか、発生したときは無制限に償いを要求する。これがクレーム時によくある顧客という優位な立場を利用した到達目標のない「誠意を見せろ」という無制限の要求となる。

  営業課長はこうした背景をもとにデータの必要性を製造部のスタッフに説明し、データの収集は情報システム部に依頼した。すでに対策が始まって1週間が過ぎているので、先方の購買部長には進捗状況も併せて報告するするように対策書をまとめる作業に入った。4月中旬に稼働の約束だったが事情を説明して連休明けまで延期を願い出た。購買部長は「これが最後だ」といって苦渋の承認をした。

  もう、あとがない。営業課長や対策プロジェクトのメンバーやスタッフは連休の予定をすべて取りやめて、研修所で合宿して対策をまとめることになった。先ほどまで晴れていた空は急に暗くなって霰混じりの激しい雨と風に見舞われた。時折、雷鳴が響き会議室に閃光が走った。

2013年4月15日 (月)

製造部クレーム対応-現状を把握する(後半)

  営業課長は障害対応で立ち会った保守エンジニア、コールセンターで障害対応したマネージャー、障害品を分析した品質と製品のエンジニア、製造ラインマネージャ-とWhite Hatで製品Qの製造から問題発生、現在に至るまでの情報を時系列でVTA(Variation Tree Analysis)にまとめ発生経路の排除ノードをBlack Hatで分析した。 <図表はクリックで拡大>

Vta_4 
  排除ノードはBlack Hat①と②が想定された、すなわち

    ① 海外工場で試作時に実働試験で性能・品質・信頼性を確認してなかった。
    ② 障害発生時に原因を把握しなかったために同じ問題が再発した。


の2カ所で営業課長はその手前にブレーク(防衛線)を破線で入れ、恒久対策の基点とした。①についてはあとで製造・技術・品質保証部で試作や量産試作段階での性能・品質:信頼性の評価方法と問題発生時の対策・処置仕組みを作ることにして、②の原因分析を続けた。

  まず、何が問題かを明確にした。

     問題:システム障害が発生した。
             → 製品Qが原因でシステム障害を発生した。
                →製品Qが制御不能になり保護機能によりシステムがダウンした。
                   →製品Qのエラーにより制御不能になった。
                      →製品Qが過熱してエラーを発生した
                         →製品Qの記憶装置部分が過熱した。

  こうして得られた真の問題:「製品Qの記憶装置部分が過熱した」の原因についてBlack Hatで分析した。   
Kt1この区別点は「起こった事実」と「起こらなかった事実」を切り替える原因のスイッチと考えられるので区別点を元に想定原因を立て、この想定原因によってWhat~Howまでの事実を矛盾無く説明できるかさらにBlack Hatでテストした。Kt2このテストから3つの想定原因が関係していると考えられ、これらを1つにまとめると

   製品Qは記憶装置部分を製品Zとは違うレイアウトに変更したため排熱機能が放熱量に追いつかず蓄熱して過熱し、熱暴走のような現象を引き起こして結果的にシステムがダウンした。

という結論に達した。ここまでの分析ですでに午後6時を過ぎており、営業課長は製造・技術・品質保証部のエンジニアに想定原因について検証するように依頼して長い1日を終えた。

  翌日この想定原因を元にエンジニアはL9直交表で内部温度を特性値とする実験を行い、月曜日には実験の結果が出て、記憶装置のレイアウトが過熱の主要因と推定された。

Doe


  営業課長は現状把握の結果から先方に説明する暫定・恒久対策とリスクについて午後からメンバーを集めてまとめることにした。営業課長はもともとエンジニア出身で創業時に前社長(現相談役)と立ち上げたころを思い出していた。
 

«製造部クレーム対応-現状を把握する(前半)