演習からは外しましたが、「なぜこのような問題が起きているのか」という洞察がこの後のステップとなります。最終要約は、
「ABCシステムでは受注が増えているために上流工程の仕様調整時間が減ってきている。その結果運用部門では業務負荷が高まり、派遣エンジニアの定着率低下とそれによる残ったメンバーへの負荷向上につながっている」
ですが、これがなぜ起きているのかと言えば、上流工程が下流工程のことを考慮する余裕がなくなるほど受注している、つまり
「この会社は需要が高まっているにもかかわらず、社内での営業の力が強すぎて事業のバランスを欠いてしまっている」という仮説を導き出すことができます。
実際の問題解決では、現場から小さな問題を拾い上げる他、さまざまな人から問題を聞き出し、また市場情報や業績情報も加えて"分析のための基礎パーツ"を最低でも30〜40個、多いときには200個以上を帰納法で分類・要約することになります。ただやり方は同じで分類による層が増えるだけです。今回の演習でコツさえ分かれば、規模は困る要素ではありません。もちろん、その分時間はかかってしまいますが…。
さて、帰納法は比較的理解しやすく、何度か実際に行ってみれば簡単にマスターできますが、しばしば陥る問題がいくつか存在します。その問題をクリアする方法もお伝えしましょう。
陥りがちな問題の一つ目は、2〜4のステップで起こります。「分析のための基礎パーツ」から分類・要約を繰り返して最上位の要約に至るわけですが、「要約」である以上、その過程で多くの言葉が消滅し、要約に残すべき重要な言葉が凝縮されているはずです。にもかかわらず、上位の要約の中に途中で消滅したはずの言葉を復活させてしまう場合があります。これでは帰納法が正しく機能しませんので、要約の段階では原因となる重要なキーワードを残すよう心掛けてください。実際に使いこなすには帰納法を繰り返し行ってみるのが一番です。
陥りがちな問題の2つ目は、3〜4のステップで起こります。要約の過程において「分析のための基礎パーツ」にも存在しないような言葉が現れてくることがあります。この場合、多くは要約の途中で既に洞察を行っていると考えられます。洞察自体は重要なステップ5に存在する重要な行為ですが、途中で行ってしまっては最上位の要約が「要約の要約」ではなく「洞察の洞察」になってしまい、「風が吹けば桶屋が儲かる」のような因果関係の低い結論を導き出してしまいかねません。洞察はステップ5までぐっとこらえ、ステップ5でのみ行いましょう。
何よりも多いのは、帰納法をフェアに分析せず、恣意的に行ってしまうケースです。頭に初めから解決策が浮かんでいると、その解決方法が適用できるように帰納法の答えを操作してしまい、実際の本質的問題は他にあるにもかかわらず自分の描いている解決策の正しさの証明をする道具として帰納法を使用してしまいます。既に「こうすれば良いのに」と思っている人は意識的/無意識的にかかわらずこの動きに陥りがちです。しかしながら思い付きの解決策では本質的問題の表面上の事象しか解決できない場合がほとんどです。問題解決の目的はあくまで本質的問題の解決であり、帰納法はその本質的問題を見つけ出す重要なプロセスですので、ぜひフェアに帰納法を行うことを心がけてください。
いかがでしたか? 今回はここまでです。次回からは解決策の検討フェーズについてお話ししたいと思います。
2000年にVSNに入社。インフラエンジニアとしていくつものプロジェクトに参画。VSNの“派遣エンジニアがお客さまの問題を発見し、解決する”サービス、「バリューチェーン・イノベーター(以下、VI)」の構想メンバーであり、一流コンサルタントより問題解決手法の教示を受け、多くの問題解決事案に携わる。派遣会社でありながら、担当した事案には、数億円規模の売り上げ向上につながった例も。
現在は、同社「経営イノベーション本部」にて今後の事業の根幹を担うVIをさらに加速させるべく、事業計画の立案や浸透・推進を行う。
株式会社VSN http://www.vsn.co.jp/
Copyright © ITmedia, Inc. All Rights Reserved.