碁や将棋に定石があるように「問題にもその解き方がある」ということ。また問題を解く３つの手法には共通の手順とそのベースになる考え方があること。そして問題を解く流れの全体像を示す。
「問題の解き方」を知る前
長い間、その時々の問題に対して思い付いた順に着手してきた。製品や技術に対する知識から原因を推測をする。その工程や技術についてよく知っている先輩に聞く。現場を見にいく。記録を調べる。そんな取り組みを順不同で行っていた。再現実験も当てずっぽうでやってみた。時々当たったが、多くはハズレた。
お客様の品質問題は常に緊急かつ重要な問題。自分がその問題の窓口になることで「お客様の威を借りて」社内のリソースを使うことも覚えた。たくさんの人の力を借りて解決に取り組んだ。
経験を重ねていくと過去の問題にヒントがあることを知った。「過去トラ」の使い方にも長けてきた。特に自分自身が過去に取り組んだ問題の対応は容易だった。・・・実は「再発していること」そのものがさらに深い問題なのだが・・・
「問題は自分の知恵と工夫と才覚で解くもの」と考えていた。それなりに問題を解いてきた。結果、驕りもあった。自分は仕事ができると思っていた。それが大きな間違いだったことを思い知らされたのは「自分の知恵と工夫と経験を加えても解けない問題に出会った時」だった。
問題を解く３つの手法：８D ／ ８ステップ ／ KT法
世の中には多くの問題解決のフレームワークがある。元々、会社でメインで使われていた手法は「８D」だった。メインのお客様からも品質問題のレポートは「８D」のフォーマットで提出することを求められていた。「８Dはわかったことをお客様に報告するフォーマット」と理解していた。
ある時期に「８Dは報告のためのフォーマットでなく、問題を解く為の手順であること」を徹底して叩き込まれた。これが属人的にではなく標準的に問題を解く手法であることを知った。
自ら自分の問題を８Dで解いてみた。後輩や部下にも教育資料を使って自分の経験を加えて教えた。部下や後輩の取り組んでいる実際の品質問題をPJTで解いてもらい、毎日のようにその８Dを一緒にレビューした。毎日８Dを使って問題を解く事に取り組んだ。その中で８Dという手法の有効性を実感した。ここから問題には解き方があることを知った
別の機会に契約しているトヨタ出身のコンサルタントから「８ステップ」の手法を学んだ。この手法を使って入社２年目の若手が見事に大きな歩留り問題を解いた。
またつい最近、ある優秀な中途社員から彼は問題を解くために「K T法」を使っていると教えてもらった。「KT法」について書かれている本を入手して学んだ。その考え方は「問題を解く」ために有効だった。
３つの手法のそれぞれに特徴があり新鮮な学びがある。それぞれ使ってみて「なるほど」と腹に落ちる。これまで「問題を解けなかった」メンバーがまるで絡んだ糸をほどくように問題を解き始める。
「問題を解き方」の全体像
３つの手法それぞれの表現や言葉の定義、進め方などは若干異なっている。一方で、根本の考え方は共通している。８Dを土台にこの共通の考え方を整理してみた。その全体像は以下の通り。
- 問題を設定する
- 正確に「情報」を集める
- 全体像を把握する
- 特徴を抽出する
- 傾向を調べる
- 変化を調べる
- 仮説を立てる
- 問題のメカニズムを考える
- 可能性のある仮説をリストアップする
- 仮説を絞り込む
- 可能性のある仮説群を「情報」でテストする
- ロジックの合わない仮説を棄却する
- 真因を特定する
- 現場検証する
- 再現実験する
- 対策案を検討する
- 物差しを決める
- 問題を阻止するロジックを組み立てる
- 副作用をチェックする
- 対策を適用する
- 対策を適用する
- 物差しを使って効果をチェックする
- 維持管理する
- 展開する
- 問題の原因構造を掘り下げる
- 同じ原因構造が他にないか？点検する
- 展開する
問題解決の進め方
この「問題の解き方」を順に説明していく。事例もできるだけ入れたいと思う。私自身の経歴からどうしても取り上げる事例は品質問題・技術問題、マネジメントとして失敗した事例に片寄ることになる。
尚、この「問題を解くための流れ」必ずしも上から下に順に一方通行で進んでいくものではない。フローの中を行ったり来たりする場合もある。
「問題には解き方」がありそれに沿っていることに自信を持つこと。次に常に「その解き方」のどの部分を、今、自分が取り組んでいるのか？を俯瞰してみることはが大切だと考えている。
① 仕事に行き詰まっていませんか？：仕事とは「問題を解く」こと ⭐️問題には解き方がある⭐️
③ 問題を認識する：「見える化」「認識」「覚悟」→問題を解くことを楽しむ＝Enjoy the problem
コメント