問題点の把握と原因分析

　コンサルティングのノウハウとして、今回は問題点の抽出方法とその原因分析のノウハウについてお話します。

（1）事実と問題点を混同してはいけない
問題点の出所は、
・通常我々がヒアリング対象者に事前に記入いただく業務調査票
（1ヶ月を通してどんな作業をどのくらいの時間をかけてやっているか
というアンケートのようなもの）
に問題点として記載されているもの
・ヒアリングで担当者の発言によるもの
以外に、
・第三者である我々が客観的に問題であると指摘したもの
があります。

自身の会社や業界に長くいるといつの間にかそれが当たり前になってしまい、問題と認識しなくなる場合があります。

ですから
「他の会社では普通そんなことしませんよね。」
といった外部の客観的な視点で問題を指摘することが重要です。

ところがこの「問題点の指摘」というのが案外難しいもので、駆け出しのコンサルタントの起こしやすいミスが事実と問題点を混同してしまうことです。
ここはASCメルマガの第一回目で野口が書いたコラム「それ、本当に問題点ですか？」に記載しているのでここでは説明を省きます。

（2）問題点は具体的に指摘する
問題点の指摘で必要なのは具体性です。
たとえば、「単価を調べるのに煩雑な作業となっている」や「納期のルールが不明確である」といった表現では何が煩雑なのか、何が不明確なのか問題点としては良く分かりません。
たとえば「受注時の単価が営業担当者の作成した見積書や契約書を見なくては確認できないため、煩雑である」とか「得意先との間では納入は受注3日後となっているにもかかわらず、急ぎの出荷が多く計画的に作業できない」といったように、出来るだけ分かりやすく具体的に指摘できなくてはなりません。
これまでの我々の経験では従業員100人程度の会社でも大小含め100や200の問題点は出てきます。
システムコンサルタントの視点としては
・業務の効率化
・在庫や利益などの管理水準
・顧客満足度
・内部統制
などで問題点を分類して抽出します。

（3）原因分析
問題点の洗い出しができたらこれらをKJ法的に集約して顕在化している問題点として抽象化し、本質的な原因分析をします。
問題の集約は先ほど書いた業務効率の視点等で「一言で言えば」というように表現します。100の問題点と100の改善項目が報告書に記載されても、脈絡やそれらの因果関係が良く理解できません。
それぞれの視点で集約化された問題を一番上におき、その真因を分析します。我々はこれを「なぜなぜ分析」と称していますが、トヨタのQC改善などでも言われるように「なぜを5回繰り返せ」といったル－ルで本質的な原因を追究していきます。
たとえば「製造ラインが度々ストップする」といった問題点の原因分析をする場合、
「製造ラインが度々ストップする」なぜか→「ヒューズが飛んでしまうから」
というレベルで問題分析が終わってしまえば、ヒューズを取り替えれば一時的には解決しますが、多分またヒューズは飛んでしまいます。
なぜ「ヒューズが飛んでしまうのか」をさらに掘り下げて
→なぜか「ラインを制御する基盤のコンデンサーの容量不足で一定電流以上の変化を吸収できないから」まで分析できれは、コンデンサーか基盤を取り替えることにより根本的な解決を図ることが出来ます。

原因分析は「ひょっとしたら、こういうことが原因なのではないか？」という仮説の場合もあります。その際にはデータの分析やヒアリングを通じて仮説を検証することが必要になります。

原因分析の方法論に慣れないうちは原因が発散してしまい、収拾がつかなくなる場合が往々にしてあります。これは慣れの問題ですので、夜となく土日となく考えることにより、ある日「目からウロコが落ちた」ように理解することが出来ます。読者の皆さんも訓練してこの習慣を身に付けて見てください。

関連サービス