概要
突発的な問題は、どのような経緯であれ事態が解決されるのが優先だが、繰り返し発生する構造的な問題は、問題が発生する構造にメスをいれる解決策が必要である。構造的な問題を解決するための基本的な手順を紹介する。
まず、「問題」の定義を考える
たとえば、「請求書の内容にミスが多く、クレームが多発する」という問題があるとする。単発の発生であれば、訂正した請求書を再提示して丁寧に謝罪するという解決策でことは収まるが、多発するようでは、発生しないような対策もしなければならない。ミスが多発するのは何らかの構造的な要因があるからであり、その要因を究明して適切な対策を実施するのである。
構造的な問題の解決手順を述べる前に、まず「問題」の定義をしておきたい。
ここでいう「問題」とは、「実態とあるべき姿とのギャップ」である。上記請求書の例でいえば、「ミスが多発している状態」が実態であり、「ノーミスの請求書発行業務」があるべき姿である。この場合は「問題」は普段私たちがつかっている「問題」と意味としては合致しているので、スンナリと理解できる。
ではつぎのような場合はどうだろうか。
「３名で２日かけてやっている請求書発行を２名でやりたい」、
「５日でおこなっている締め業務を３日に短縮したい」。
これらは、今の状態を「あるべき姿」ではないと考えれば「問題」であるし、今の状態を「あるべき姿」と考えれば「問題」でも何でもない。だが、こういうテーマがあるべき姿として公認されたとすれば「問題」となる。少々ややこしいが、要するに上の定義のように「実態とあるべき姿とのギャップ」ならば「問題」とするのである。
問題解決の基本手順
「問題」として認識されたもののうち、単発で単純のものはここでの対象にはならない。対象としてもいいが、単発のものは即断即決で解決に迅速性が要求されるため、これから述べる手順にはあまりそぐわないからである。
手順は次のようなものである。
（１）問題の要因を分析する
なぜその問題が発生するのかの要因を具体的、かつ論理的に場合分けをして整理する。要因は一つではないことも多いし、要因を生み出すもう一段手前の要因もあるはだ。「なぜ」という問いを繰り返しおこなって、要因の構造を明らかにする。「なぜなぜ分析」とも呼ばれる。
冒頭の請求書ミスの例でいえば、「計算ミス」、「転記ミス」、「送付先のミス」などが要因として挙げられ、「計算ミス」の要因には「電卓の打ち間違え」、「検算をしていない」などがある。
このようにして、要因を、対策がとれると思われるところまで具体的に分析していけば、この問題の解決への準備が整ったことになる。使われる技法としては下のような図をまとめていく「連関図法」が使われることが多い。
連関図で平面的な構造が把握できたら、発生した問題の件数（または場合によっては金額など）を要因別に集計し、要因別の影響度を把握する。これを行なうことで、次におこなう解決策の案出と実施する対策の優先度付けができる。
（２）解決策の案出
要因分析ができると問題が構造的に明らかになるので、それをもとに解決策を考えていく。
解決策は、通常、一通りではなく色々な案が生まれる。効果の高いもの、効率に違いがあるもの、費用がかかるもの安く出来るものなどである。
この活動は発想力があればあるほど、良い案、沢山の案がでるが、うまくまとめていかないと収拾がつかなくなる場合がある。そこで技法としては、BS法（ブレーンストーミング）、特性（属性）列挙法などの発想法の各種技法と、下図に示す系統図法などを組み合わせて利用することが多い。
（３）解決策の決定と実行
複数の解決案のうち、いずれにするかは、コスト、効果、実施期間、実行可能性などによって評価して決める。
解決策を実行するのは既存の業務プロセスを変更することになるため、マニュアルや要員訓練なども考えて行なう。
要因が分析できない場合はどうするか
「３名で２日かけてやっている請求書発行を２名やりたい」というようなこれまでやったことがないことを目指す場合は要因が分析しづらい。しかし、これも「なぜ２名ではできないのか」という疑問を出発点としていけば、ある程度までは分析が可能である。うまくやっている外部の事例研究などが有効な場合もある。
（執筆：山田一彦）
■この記事の関連記事・関連サービス■
ブログに関する関するご意見・ご感想はお問合せフォームよりお知らせください。
デジ☆ブログへのご意見・ご感想
ITマネジメント・サポート協同組合では、DXの活用・推進にお悩みの中小企業に向け、DX計画向け解決策提示・スコアリングサービス『デジ☆レシピ』をリリースしました。こちらもご覧ください。
『デジ☆レシピ』サービスご紹介
