連載記事 飯塚悦功
第22回 問題解決(3)

5. 業務システムの脆弱性分析

5.1 業務システムの問題のありかを探る

先月予告しましたように、4つの問題のタイプのうちの「[2] 仕組みの改善」の方法(12月号57頁参照)について考えてみたいと思います。

私たちは、日常業務に忙しく立ち回るなか、様々な問題に遭遇します。危うく大事故になるような背筋の寒くなるようなインシデント、やり直し・手戻りの日常的な発生で効率が低下し繁忙感に疲れてしまう毎日、みなマジメにやっているのになぜかギクシャクする内部コミュニケーション、……。こうした問題の分析を上手に行うコツを知りたいものです。問題の原因が仕事の仕組み、仕掛けにあるような問題、あるいは仕組みに手を打つことによって、改善が期待できるような問題をどのように分析するか、その基本技術について考えてみます。

仕組みの問題の分析をするときに、分かっていなければならない基本的な考え方があります。それは、「仕事のミスや問題は結果である」ということです。失敗したこと自体を叱りとばしても、多少は気が晴れるかもしれませんが、事態は好転しません。結果の悪さを責めても将来につながるよい良い影響はなかなか生まれません。実は、叱りとばし罰を与えることによってより良くなる世界がないわけではありません。それは抑止効果が効く世界です。あんなことをすると叱られるし罰せられるから、悪いことや下手なことはしないようにしようと皆が考えてそう努力することによる効果です。ただ、これが成立するためには、叱られ罰せられるようなことにならないために、どうしたらよいかが分かっていなければなりません。

しかし、仕事の失敗は、多くの場合、悪意があって故意に起こしているわけでなく、うまくやろうとして、いや少なくとも失敗しないようにとそれなりに気を遣っていながら、なぜかヘマをして問題を起こすのです。そのようなときに、叱っても罰しても、それだけでは事態は好転しません。重要なことは、良からぬ事態に陥らないための方法の明示を伴う、叱正、懲らしめ、罰でなければ抑止効果は働かないということです。

問題分析のためには、「結果は原因から生まれる」、すなわち「仕事のミス・問題の原因は、仕事の仕組みの不備、もろさ、弱さにある」という原則が分かっていなければなりません。そして、「改善のためには、原因に対して手を打つべきである」という原則に従うべきです。

起きてしまった問題に対しては、応急処置、影響拡大防止が重要です。火事が起きたらボヤのうちに消すべきです。迅速に延焼防止処置を取るべきです。しかし、仕事の改善、レベルアップを考えるのなら、将来経験するかもしれない類似の問題の再発防止、あるいは未然防止も考えるべきで、そのためには仕事の仕組みに潜んでいる問題の原因を分析する技術を会得していることが必要です。このことに焦点を当てようというのが今月の主題です。

「仕事の仕組み」や「業務システム」について、どこにどのような問題があるかを的確に分析するためには、その基本技術として、分析対象である業務システムに対する巧みなものの見方・とらえ方が必要です。さもないと、何か問題がおきてRCA(根本原因分析)をするにしても、ただ無意味に深く突き止めるばかりで、ことの本質には迫れません。

起きている問題の様相を理解し、適切に対応するためには、その問題を上手に「切り分ける」視点が必要です。業務システムの問題のありかを見る目として、「こんな見方はどうですか」というようなことをいくつか挙げてみたいと思います。

第一は、「システムの理解」ということです。私たちが「システム」という用語を使うとき、それは検討・考察の対象にしている系が少なからぬ構成要素から成り立っていて、系全体として何らかの目的あるいは機能を考えることができるときです。業務システムについていえば、その目的・機能は何か、その目的を達成するために必要な要素(プロセス)は何か、それらのプロセスがどのように連結されてシステムの目的を達成しているのか、各要素プロセスはどのような構成要素から成立していてどのように機能を発揮しているのか、などについて明らかにしておくことが必要です。問題が起きて、システムの全体設計、要素プロセスの設計に問題があるとき、その問題のありかの“あたりをつける”ために、システムの全体像を理解しておく必要があります。

第二は、「業務システムの運営の基本」という観点です。例えば、管理を効果的、効率的に行うためにPDCAを回すことが原則ですが、問題が起きたときに、そのPDCAの各ステップで実施すべき事項のどこに問題があったのかという切り分けです。例えば、問題がP(Plan計画)にあるのかD(Do実施)にあるのかを明らかにしようとするのは、目的を達成するための手段としての計画は目的達成に合理的なものだったのか、それとも計画は良かったが実施において計画通りできなかったのかという切り分けです。同じように、PDCAのすべてのステップのどこでどのような不備があったのかという見方です。

あるいは、これと類似していますが、問題が問題となってしまう経緯を考察するという見方もあります。すなわち、問題の火種が発生し、それが見逃され、小さなうちに上手に処理されずに拡大していって、ついには無視できない問題になるわけで、発生原因、見逃し原因、拡大原因という視点で原因を考えるという見方も有用です。

第三は、「業務の質・効率を左右する側面」にはどのようなものがあるかという視点からの考察です。ずいぶん前になりますが、管理/マネジメントについての基本的な考え方を考察していた連載第6回(2018年9月号)で、「優れた業務システムの要件」として、技術、マネジメント、ひと、文化の4つを挙げました。すなわち、質の良い仕事をするために、まずは技術が必要で、次にその技術を生かす方法論としてのマネジメントが必要で、さらに意欲・知識・技能の面で優れた人が必要だと説明しました。問題の原因を、それが技術の不足にあるのか、マネジメントの不備にあるのか、人の能力不足なのか、はたまたそれらのプラットホームとしての組織風土・文化に遠因、背景要因、誘因があるのかという切り口も、問題発生構造の多面的な考察、現実的な対応策を考察する際には有用です。

以降、こうした見方で、業務システムの問題のありかを探る方法について考察します。たぶん、これはRCAと称する深いはずの分析法でも十分には触れていないとらえ方ですし、いわゆる「なぜなぜ分析」によくありがちな、「問題の構造」をあまり意識しない原因分析とも少し距離感があると思います。何を参考にされても結構、ご自身が対峙する問題・課題に対し巧みに取り組んでいただければと思います。

5.2 システムの理解

業務システムの「問題のありかを見る目」の第一として、考察の対象となっている業務システムがどのような要素から構成され、それらの要素が互いにどのような関係をもって、システムの目的を達成しているのかを理解することが必要です。その第一は、「システム構成」(フレームワーク、プロセス、リソース)の理解、第二は「プロセスフロー」(プロセスの構造・流れ)の理解、第三は「ユニットプロセス」(その概念と構成要素)の理解であろうと思います。

(1) システム構成

業務システムを構成する要素をどうモデル化するか、いろいろ考えられますが、一つの方法はQMS(品質マネジメントシステム)のモデルにならうことです。すなわち、QMSは全体として、「フレームワーク」の枠組みのもとで、「リソース」を基盤とし、また「リソース」からの支援、インプットを受けて、「プロセス」によって価値の変換を行って、「顧客」に「価値」を与える、と考えることです(図表1)。



価値の変換というと難しく聞こえますが、部品・材料を加工・組立して製品を作るとか、データ・情報を整理・分析して報告書を作るなどのことを言っています。モノ、情報、状態に操作を加え、所望のモノ、情報、状態を得るということです。あらゆる業務は、このような変換の連鎖で、所望のアウトプットを得ていると考えることができます。

このモデルは、何か問題が起きたとき、正しい「顧客」に対して、正しい「価値」を提供したか、「フレームワーク」、「プロセス」、「リソース」は、期待した通りの機能を発揮したか、システムのどの要素にどのような不備があったのか、と問題のありかを「切り分ける」、あるいは「問題のありかがQMSのどのような側面に関連するか」について検討する際の視点を与えます。

これは、「プロセス管理の考え方」、すなわち「管理において、結果を生み出すプロセスで質を作り込む」という原理に基づく問題の受けとめ方にほかなりません。結果として問題を起こしたというのですから、プロセス管理の考え方に従って、要因系のどこかに問題があったからだと考え、結果を生み出す直接のプロセス、そのプロセスを支えプロセスで使われるリソース、それらを運用するフレームワークのどこに問題があるのかを検討しようという考え方です。

(2) プロセスフロー

読者諸賢はお気づきでしょうが、問題の真因の究明のために、このような漠とした解析では不十分で、もっと詳細に記述したプロセスの、どこにどのような不備があって、それがどのように問題の原因、誘因、遠因になったのかを明らかにしなければなりません。そのために、業務プロセスを詳細に記述する必要があります。プロセスの記述は、プロセスの流れを表現する「プロセスフローチャート(Process Flow Chart;PFC)」や、ある一つの機能を担う「ユニットプロセス(Unit Process)」のどこに不備があったかという検討方法がよいだろうと思います。

プロセスの全貌を理解するためには、PFCによって業務の可視化をするとよいでしょう。いろいろな書き方がありますが、一つの方法は、縦軸を業務の流れ(フェーズ、ステップ)、横軸を担当部門(業務機能)として描くことです。この図によって、その業務に、どのような活動が、どのような順序で必要であって、どの部門(経営機能)が担当しているのかを表現することができます。これら活動の流れの、どこにどのような問題があったのか「見える」ようになります。

一般に、何か問題が起きたときに、「どのような経緯があったのか」に関心を向けることは賢い方法です。業務プロセスの流れに着目するのは、その原則に従う方法です。

プロセスフローの理解の要素として、「関係者の理解」が重要な場合があります。問題のなかには、当該業務の「関係者の間の関係のあり方」が影響していることもあり、プロセスフローとともに、プロセスに関わる人々の間の関係がどうなっているのか理解しておくことが必要な場合があるからです。

その業務にはどのような関係者がいるのでしょうか。少なくとも当該業務へのインプットの提供者と、当該業務のアウトプットの受取手がいるはずです。そのほかにも当該業務の遂行にあたり様々に関与する関係者がいるかもしれません。あなたの業務を管轄する人や、あなたが管轄したり委託したりする人や部門があるかもしれません。上述のPFCで記述されるかもしれませんが、問題のありかが、関係者との関係のあり方に起因することも多いことから、どのような関係者がいて、どのような関係があるか、綻びはどこにどのような形でありそうか、などを検討する必要があるかもしれません。

関係のあり方としては、「価値提供連鎖」(誰から誰に価値が移動していくか)、「情報伝達」(どのような情報が誰から誰に伝えられるか)、「管轄権、責任・権限」(誰が管轄しているか、誰にどのような責任・権限があるか)、「委託・受託関係」(誰と誰の間にどのような委託・受託関係があるか)、「役割分担・協力」(どのような役割・業務の分担・協力をすることになっているか)など、いろいろあります。

(3) ユニットプロセス

業務の流れのなかで問題のステップが浮かび上がってきたら、それをユニットプロセスととらえて、問題の様相を理解するようにしたらよいと思います(図表2)。ユニットプロセスを構成するインプット、プロセス、アウトプット、リソース、測定・管理の各要素が、まともに運用されていたのかという観点から、さらに問題を深掘りします。



インプットされるモノ・情報・状態は正しかったのでしょうか。それを正しく確認したのでしょうか。プロセスの活動を支え、投入されるリソース、すなわち設備・機器、要員、技術・知識、業務環境などは整っていたのでしょうか。そのことは確認したのでしょうか。このプロセスで実施される一連の活動は定められた手順・方法で行われたのでしょうか。その手順・方法などは正しかったのでしょうか。このプロセスの進行とともになされる状態把握や必要に応じてなされる介入は適時・適切に行われたのでしょうか。役割分担・協力、責任・権限などは適切だったのでしょうか。そして、このプロセスのアウトプットとなるモノ・情報・状態が期待通りのものであることを正しく確認したのでしょうか。このようにして、業務システムのどこに問題があるか探っていきます。

ここでいう、インプット、アウトプット、プロセスなどは、モノづくりの現場のみならず無形の価値を生み出すプロセスも考慮しているので、実にいろいろあるということを考慮しておくべきでしょう。図表3のような、非常に広いとらえ方をしていることに留意してください。



5.3 業務システム運営の基本

業務システムの問題のありかを見る目の第二は、「業務システムの運営の基本」という視点です。

(1) PDCA

効果的・効率的な管理のために、PDCAサイクルを回すという考え方が有効ですが、問題が起きた業務プロセスについて、PDCAの各ステップのどこに問題があったのかという視点での切り分けは有意義です。

とりあえず持っていたい視点は「計画の質/実施の質」という見方、すなわち、問題の分析の際に、その原因がPlan(計画)にあるのかDo(実施)にあるのかを切り分けることから始めるという考え方です。このような検討をもっと詳細に、PDCAのどのような面にどのような不備があったのかを検討してみようということです。

PDCAサイクルの展開については、この連載でも触れたことがあります。繰り返しになりますが、目的達成のためのPDCAというステップは、図表4のような活動から構成されると考えることができます。



業務プロセスで起きた問題は、このPDCAのステップのどこにどのような問題があったからなのでしょうか。

Plan: 目的・目標は明確だったのでしょうか。また妥当だったのでしょうか。目的・ねらいを理解していたのでしょうか。目的が正しく理解され、設定されていたとして、目的を達成するための手段・方法は決めたのでしょうか。決まっていたとして、目的達成のための手段・方法は妥当だったのでしょうか。日常業務でいうと、手順、マニュアル、作業標準、ガイドラインなどは正しく、それに従えば満足な結果の得られるようなものだったのでしょうか。

Do: 実施のために準備しておくべきことは整っていたのでしょうか。例えば、使用する機器類は満足な状態にあったのでしょうか。担当者はその業務を行うのに十分な知識・技能を有していたのでしょうか。用いる材料、物品は、まともなものだったのでしょうか。そして、実施においては、決められた通りに実施したのでしょうか。この連載でPDCAについて検討したとき(連載第7回:2018年10月号)に紹介した「賢者の愚直」「ABC:(A)当たり前のことを、(B)ばかにしないで、(C)ちゃんとやる」は浸透していたのでしょうか。

Check: 業務が満足に進んでいるかどうか進捗を把握していたのでしょうか。進捗把握で得られた情報の意味を正しく理解していたのでしょうか。何も気が付かずに重大なことを見逃していたのかもしれません。副作用、副次効果についての確認もしたのでしょうか。こうした確認は事実に基づいて実施したのでしょうか。

Act: 満足できない事態が起きていることが分かったとき、迅速・的確に処置したのでしょうか。起きた事象によっては対応の方法を考察するための問題分析が必要になりますが、それはなされていたのでしょうか。小さな問題を大きくしないためになすべきことは実施されていたのでしょうか。今回の問題発生より前に、類似の問題が発生したとき、きちんと原因分析をして再発防止、未然防止の策を講じておいたのでしょうか。今回の問題は、そのときまともなプロセスに改善しておかなかったために起きた「再発問題」ではないのでしょうか。

(2) 管理の4原則

連載第10回(2019年1月号)において「知的業務のプロセス管理」を話題にしました。そこでは、私が若いころ設計・開発プロセスに関心を持ち、数百例の設計ミスを分析して、開発プロセス管理の原理のようなものを導いたことをご紹介しました。前項のPDCAの視点での業務プロセスの見方に近いのですが、少し違った視点から業務プロセスのあるべき姿を描いています。以下の4つの原理で構成しました。

① 業務プロセスの明確な定義: プロセスを明らかにする
② 質の高い効率的な仕事の実施: ユニットプロセスで失敗しないようにする−PD
③ 失敗の早期発見: 失敗を早く見つける−C
④ 失敗への迅速・適切な処置: 失敗をうまく処理する−A

そして、そのときの図表を少し改訂したものを掲載します(図表5)。



(3) 問題の発生・見逃し・拡大

「PDCA」や「管理の4原則」と基本的には同じなのですが、問題が問題となってしまう経緯に注目する問題のとらえ方もあります。分析の対象となるような問題が「問題となる過程」を考えてみると、問題の火種が発生し、それが見逃され、小さなうちに適切に処理されずに拡大していって、ついには無視できない問題になるわけで、「発生原因」、「見逃し原因」、「拡大原因」という視点で業務システムの脆弱性を見ようというわけです。

発生原因、すなわち、その問題がなぜ発生したかという原因を、関連する業務の標準的手順がどう設定され、どう利用されたのかという観点から、例えば図表6のように分析することができます。



この分析は、正しい業務が行われるためには、根拠ある正しい方法が決まっていて、その正しい方法を組織で共有するために標準が定められ、その標準に従って実施されていなければならない、という考え方に基づいています。なお矢印(→)の次の記述は、該当する場合の対応の方向性を示すもので、必要に応じてさらに詳細に分析したうえで具体的な対応策を明らかにします。

見逃し原因についても、業務プロセスの途中における中間評価・確認がどうなされるべきかという観点から、分析することができます。この分析は「管理の4原則」で挙げた「③失敗の早期発見」と同じものとなるでしょう。

発生した問題への対処の失敗の原因についても、「管理の4原則」の「④失敗への迅速・適切な処置」と同じものとなるでしょう。

5.4 業務の質・効率を左右する側面

業務システムの問題のありかを見る目の第三として、「業務の質・効率を左右する側面」にはどのようなものがあるかという視点について考えてみます。優れた業務の要件としての、技術、マネジメント、ひと、組織文化に、何らかの問題がないのかを分析しようということです。

(1) 技術

望ましい結果を得るためには、当該分野に固有の技術(目的達成のための再現可能な方法論)が確立していなければなりません。目的を達成するための有効な方法論が明らかになっていないのですから、これがなければ何も始まりません。

「餅は餅屋」と申します。餅は餅屋のついたものが一番うまいという意味で、その道のことはやはり専門の者が一番、何をするにもまずは専門性が重要だということです。確かに、もち米に関する知識や、蒸し方、つき方、こね方など、良い餅にするために必要な技術的な知見や技能がなければ、まともな餅はできないでしょう。

目的を達成するために必要な知識・技術コンテンツや技能を明らかにし、それらを保有し、さらにその専門分野に適した構造で、再利用可能な知識として蓄積し、利用できるようにしておかねばなりません。もし問題の原因がここにあるなら、技術的資産(技術標準、ガイドライン、マニュアル、技術知識ベースなど)の根拠とその妥当性を見直して、不足、不備を解消する必要があります。

ここで注意しておきたいのは、「技術に問題がある」とか「技術不足」と表現したとき、この世のどこにもその技術コンテンツがないのか、存在はするが自組織が持っていないのか、持ってはいるが可視化されていないのか、可視化されてはいるが良い構造で蓄積されておらず然るべき時に使えないのか、などいろいろなレベルがあるということです。これを「技術不足」と認識するのか、それとも技術を生かす「マネジメントの不備」と認識するのか、難しいところです。

私は、できるだけマネジメントの問題と認識するようにしていて、この世に存在はするが組織のどこを探しても存在しない技術・知識は「技術不足」、誰かの頭の中にあることも含め、組織のどこかに存在してはいるが組織的に活用できるようになっていないときは「(技術)マネジメントの不備」ととらえるようにしています。実際、かつて数百例の設計ミスの原因分析を行ったとき、必要な技術・知識が組織のどこを探しても存在しないケースは極めて少なく、「組織がいま何らかの形で保有している技術レベルのままでも、まともな設計・開発プロセスを構築すれば、トラブルは十分の一以下にすることができる」と確信しました。

(2) マネジメント

技術的にどうすればよいか分かっていても、いつでも、どこでも、誰でも、その通りにできるとは限りません。前項の「技術」の最後の段落で申し上げたような、組織のどこかに存在していてもそれがいざというときに利用できずに問題を起こすものです。

「餅は餅屋」と申しましたが、もち米に関する知識や、蒸し方、つき方、こね方など、良い餅にするために必要な技術的な知見や技能があっても、それが組織的に再現できるようになっていなければ、良い餅をずっと提供し続けることはできません。

日常の業務の中で、技術的にみて正しい方法を自然体で実行できるような手順、マニュアル、ガイドラインなどの業務標準を整備し、また適切な業務環境を整え、要員の教育・訓練を実施して業務実施者が正しい方法で作業できるようにする必要があります。優秀な人が、とぎすまされた集中力で1回成功するということと、普通の人がごく自然に何回でもそれなりのレベルでできることとは全く違います。科学、技術、理論、教科書から実施可能な「実施手順」の確立と運用へ、ということです。

必要な技術・知識が、必要なときに利用可能であるようにするための一つの方法は業務標準の設定と活用ですが、その業務標準で利用する技術・知識ベースを適切な構造で保有することも重要です。ノウハウ、ガイドライン、○○表、「技術の棚」などの類です。

マネジメントにどのような不備があるか、あるいは改善の余地があるかを見抜くための考え方やものの見方は、多々上述しました。

(3) ひと

目的達成のための再現可能な方法論としての技術が確立していて、その技術を組織的に活用して目的を達成するためのマネジメントの仕組みがあっても、そのもとで業務を実施する人がまともでなければ、まともな業務はできません。業務に従事する人々に「能力(知識、技能)」があって、十分な「意欲」がなければ、期待通りの業務が実施されません。

そのためには、知識・技術の教育、技能の訓練が必要ですし、手順・マニュアルなどの根拠・理由の理解を通して、その意義を十分に理解していなければなりません。また、人々の主体的な参加を促すような仕組み、例えば、手順類の策定・改訂への参画、改善提案制度なども必要です。

さらには、ヒューマンエラー、より広くは人間的側面への配慮の行き届いた業務システム、組織運営になっているかどうかも重要で、こうした点で問題はないのか、改善の余地はないのかを検討してみることも必要です。

(4) 組織文化

技術が確立し、技術を生かす健全なマネジメントが実施され、それらの基盤のうえで行動する優れた人々がいても、すべての仕事がそれらの規範だけで行われる訳ではありません。

技術の未成熟ななかで実施しなければいけないことも、手順が不明確、不十分ななかで実施しなければならないことも、ついつい安きに流れたくなる誘惑のなかで実施しなければならないこともあります。

そのようなとき業務遂行に関わる健全な価値観が浸透していて、組織の風土・文化が盤石であると間違いが起きにくいものです。その意味で、理念の浸透、良き伝統の継承、DNAの醸成に改善の余地がないかどうか検討することは、大いに意味があります。

私は、医療や原子力の分野で「安全文化」という言葉を数多く聞いてきました。これが何を意味するのか、安全文化の確立・醸成のために何をすればよいのか、それこそ迷走気味の議論を経験しました。私は「文化」とは「価値観」だと思っています。したがって、安全文化とは、何よりも安全が重要で、最優先で取り組むという価値基準であり行動原理であると考えています。そして、これらは「マネジメント」によって比較的短期間(2〜3年)で醸成・確立できるものと考えています。例えば、ある思想・行動基準を組織に浸透させようとするなら、それをルール化し遵守するように執拗に管理するのです。2年もすれば、それらしい言動をする人々が増えてくるものです。「文化」は組織のマネジメントスタイルを左右する基盤であり容易なことでは変えられないという論もありますが、私はそんなことはないと思っています。

6. 問題解決のステップ

6.1 私の問題解決手順

これまでかなりのページ数を費やして、問題解決・原因分析を主題として、いろいろな側面について、いろいろな切り口で語ってきました。QCストーリーについてはそのステップ、手順に従って留意点をご説明しましたが、「仕組みの改善」、「業務システムの脆弱性分析」については、問題解決のステップ、原因分析の手順については、あえて触れてきませんでした。問題解決法に関するほとんどの書物や解説では、ステップや手順、それに「何とか手法」が詳しく述べられているにもかかわらずです。問題のタイプや性質によっては、そうした型にはめたステップとか手順では適切に対応できないのではないかという疑問もあって、この連載では問題解決という主題に関わる「ものの見方」として、問題解決の基本的考え方とか、業務システムの問題のありかのとらえ方などについて語ってきました。

とはいえ、私自身、問題を目の前にすれば、問題の性質に応じて柔軟に対応しようと思ってはいても、これまでにご説明したようなことを念頭に置きつつ、何となく「問題を解きほぐしていく手順」のようなものに従って対処してきました。それをご紹介しようと思います。

ここでご紹介しようと思っている手順が対象とする問題は、実は限定されたものです。問題とは、本来は「自分たちの将来までをも考えたときに、いま実施しておかなければならないこと」くらいの広い意味ととらえるべきであり、「あるべき姿と現実のギャップ」と表現してもよいかもしれません。すると将来に向けて実施しておくべき課題、例えば新たな○○法開発とか、○○情報システムの構築とかも主題になります。先月号で取り上げた、タイプ[3]や[4]の問題です。しかし、ここでは、起きてしまった問題にどう向き合うかに限定して、私の手順をご説明します。

私は、起きてしまった問題を解きほぐし、対応策を考察するとき、以下の3つの段階を踏んでいます。

①状況把握
②原因構造解明
③対応検討

「状況把握」とは、まずは、いったい何が起きていて、何が問題であるのか理解するという意味です。起きていることが明らかに問題だと分かることもありますが、何かが起きていることは確かでも、そのどこがどのように問題なのかよく分からないこともあります。これを明らかにしておかないと、解くべき問題を間違ってしまいます。

さらに、その問題に関連して知っておくべきことを理解するということも含んでいます。いつでもそうなのか、いつからそうなったのか、それは何と関連していそうかなど、その問題の起き方にどのような特徴があるのか把握します。これが原因構造解明の大きなヒントになります。

「原因構造解明」とは、なぜ、どのようにしてそうなってしまったのか、問題発生メカニズムの全貌を解明することで、原因分析の中心となる活動です。とくに業務システムの不備や脆弱性に起因して、どのようなメカニズムで問題が起き、拡大していくか明らかにすることに力を注ぎます。「業務システムの問題のありかを見る目」について第5章で説明しましたが、その観点を用います。

「対応検討」とは、その問題にどう対応するか、さらに将来起きるかもしれない類似の問題にどう対応するかを検討することです。基本は、原因構造解明で明らかにできた問題発生メカニズムの全体像を理解したうえで、どの因果連鎖を断ち切るか、どこにどのように軟着陸させるように誘導するか、広い視野から考察することです。

さてそれでは、この3つの段階で、私がどのようなことを考えながら、どのようにして問題として提示されたことを理解し、その問題の発生メカニズムを解きほぐし、それを踏まえてどのようにして現実的な解決策を考察するように努めているのか、ご説明することにいたします。

6.2 ステップ1: 状況把握

「状況把握」では、まずは何が問題であるのか理解します。さらにその問題に関連して知っておくべきことを理解するように努めます。問題解決においてことのほか重要なのは、実は「問題の定義」です。「○○が問題だ」という訴えを鵜呑みにすることは危険です。意識的に実態をねじ曲げようとする方もいますし、何も分からず問題だと騒いでいる場合もあります。そこで私は、最初に、何が起きているのか、何が事実で、何が意見・見解・憶測か注意深く聞き取り、そのうえで、どのような目的を達成しようとしていて、どこがどのように不十分と受けとめていて問題と考えているのかを把握するように努めます。

何が問題か何となく把握できたら、次に事象の連鎖を理解するようにします。何が起きて、それに誘導されて次に何が起きたかという連鎖です。このとき理由・原因については、あまり深く考えないようにして、次の段階で解明することになる問題の構造、原因の構造に関係しそうな事実を把握するようにしています。

事象の連鎖の理解のために業務プロセスの理解が必要となることもあります。そのための、業務プロセスのフローと各プロセスの要素の実態の理解の方法については、すでにご説明しました。

事象の理解において、人がどんな状況で何を考え、どういう意図で何をしたのか(人の思考・行動プロセス)を把握することが重要なことがあります。このとき「なぜなぜ?」と問いつめるように聞き出すことはしません。「なぜ?」という質問は、問題の発生に深く関わってしまった人にとっては、「なぜ(してはいけないことを)したのか?」、「なぜ(なすべきことを)しなかったのか?」と詰問されているように感じ、正しい意味での「なぜ?」に答えられなくなってしまうことが多いからです。上手な質問、インタビュー、対話によって、何があったかのか、その状況を知るようにして、遠因、誘因、間接要因のヒントを得るようにします。

もしも問題が物理・化学的な現象に関わるなら、目で見た観察結果とか、科学的な測定・分析の結果についてお聞きします。この時点で、すでに物理・化学的なメカニズムが解明されていて、そのうえで業務システムに工夫をして、この種の問題の再発防止のために分析するという手はずにしたいので、業務システムに対する適切な工夫・改善を導くのに必要な程度まで、物理・化学的なメカニズムを理解するようにします。もし物理・化学的な因果メカニズムそのものが不明確であって、この解明こそが問題の本質に関わっていると判断したら、専門家に科学的・技術的な検討をしていただきます。問題解決には相違ありませんが、いまここで検討しようとしている原因分析とはタイプが異なるかもしれません。

こうした問題事象の理解の過程で、問題の原因構造解明の準備として、起きている事象の実態や特徴を把握するように努めます。事象の理解の際に、普段はどうやっているかとか、類似のものとどこが違うかというような「比較」を着眼点にすることがよくあります。また、いつから何が変わったかという「変化」にも目を付けます。時間そのものは原因ではあり得ませんが、その変化しているときに変わっている何かがあって、それが直接・間接の原因になっていることがあるからです。

問題の様相を理解するために「関係者分析」をすることもあります。それは、問題となっている仕事の仕組みについて、どのような関係者がいて、誰が誰に何をすることになっているのか理解するという分析です。これは、あらゆる業務プロセスが、誰かに何らかの価値を提供する過程であると解釈できて、その価値提供に多くの関係者が絡んでいて、それらの関係者が期待した通りに機能しないと、それが問題のきっかけになると考えているからです。この分析は、プロセスの分析と類似しています。関係者分析は、誰がそのプロセスのオーナー(主体的責任者)で、誰にどのような利害関係があるか理解しておくための分析です。

プロセスの理解の過程で、「問題領域」を明らかにしようと努めています。どのプロセスで問題が起きているのか、どの機能(ニーズ、実現構想、実施、検証、提供など)の問題なのか、どの部門(あるいは人)の“間”の関係の問題なのかなどについて、あたりをつけます。

6.3 ステップ2: 原因構造解明

「原因構造解明」では、問題が起きたその因果構造の全貌を明らかにします。この考察のとき、私は最初に、その問題がその分野に固有の技術・知識の未熟さに由来するものかどうか判断するようにしています。問題とは目的が達成できないことであり、目的達成に必要な再現可能な方法論(=技術・知識)があるかないかで対処の方法が全く異なると考えているからです。技術が未熟なら、組織の技術資産、知識レベルの充実を図る必要があります。これまでの私の経験では、技術が未熟で発生している問題は驚くほど少なく、ほとんどは確立している技術・知識が組織共有のものとして有効活用されていないことにより起きていて、マネジメントシステムの充実によって大幅な改善を図ることができます。

その問題がマネジメントの工夫によって何とかなるかもしれないときは、それが計画の問題か、実施の問題かの判断をします。すなわち、目的達成の方法論としての計画に不備があるのか、それともその計画通りにできなかったという実施に問題があるのかという切り分けです。より広くは、目的達成のためのPDCAのうちどこに問題があるか考察しています。ときには、「管理の4原則」に照らして、どこに問題があったかを考察します。これらの分析の視点は、前章5.3節の(1)、(2)で説明しました。

次に私は、業務プロセス全体のなかのどのプロセスで問題を発生させ、どのプロセスでその(小さな)問題を見逃し、どのプロセスで十分に対応できずに拡大させてしまったのか、そしてそれはなぜなのかを考察します。これは、健全な業務システムというものが、そもそも業務を遂行するためのステップが確立していて、各ステップにおいて失敗しないように業務を行い、失敗してもそれを早く見つけ、失敗に上手に対処できるようにしている必要があるとの原則に基づくもので、健全な業務システム像との対比においてどこに不備があるかを考察しています。これらの分析についても、前章5.3節の(3)で説明しました。

さらに私は、「ひと」に関わる改善の余地について検討します。技術が確立し、その技術を活用できる業務プロセスが確立していても、そのもとで業務を実施する人に能力(知識、技能)があって、十分な意欲がなければ、期待通りには実施されません。そこで、知識・技術の教育、技能の訓練の状況、手順・マニュアルなどの根拠・理由の理解などを調査します。また人々の主体的な参加を促す仕組みがあるかどうかも調べます。さらには、ヒューマンエラー、より広くは人間的側面への配慮の行き届いた業務システム、組織運営になっているかどうかについても、問題はないのか、改善の余地はないのかを検討します。

組織の文化・風土、価値観についても調べてみることがあります。それは、技術が確立し、技術を生かす健全なマネジメントが実施され、優れた人々がいても、すべての業務がそうした規範だけで行われる訳ではないからです。技術未成熟ななかでの業務実施、手順が不明確・不十分ななかでの業務実施、いい加減に済ませたくなる誘惑のなかでの業務実施でも、何とか成し遂げる健全な価値観の浸透、組織の風土・文化、「しつけ」ができているかどうか、それらを醸成する仕組みがあるかどうかを調べてみます。

もうお気づきでしょうが、上述した分析には、仮説、モデルが必要です。問題の起き方、業務システムの不備の類型をある程度知っている必要があります。第5章は、業務システムの不備の類型について、長々と説明しているともいえます。

6.4 ステップ3: 対応検討

問題への対応として、性質の異なる2つの活動が含まれます。第一は、その問題が進行中の対応であり、第二は、その問題がひとまず沈静化し、将来に向けて何らかの知見を得る段階での対応です。

起きている問題を上手に収めることは、テキパキと的確に対応しなければいけない難しい判断を要求される活動です。実はこの連載では、問題が沈静化したあとの反省、振り返りに焦点を当てていてほとんど説明していません。問題沈静化後に、「その問題をどのように収めるべきだったか」という分析のときに考察している程度です。このタイプの対応は、実は、問題露見直後から、状況把握と同時進行で進めるべきです。

この第一の対応で重要なことは、起きている問題そのものを早期に解消することです。原因の除去ができれば幸いですが、そうでなくてもとにかく問題事象そのものを除去、軽減、修復し、被害拡大防止、影響の極小化を図ります。問題の被害者など関係者への迅速、的確、誠実な対応も必要です。ここで行き違いが生じて問題がこじれてしまう例は枚挙にいとまがありません。さらに、同一の事象・原因で起きた、あるいは起きている他の問題についても対処が必要です。なかでも案外難しいのは済んでしまった問題の後処理です。対応する範囲の決定に必要な調査や対応そのものに膨大な手間を要することがあり、高度な判断が必要です。

第二の対応が、今回主眼を置いて考察したい対応で、将来起きるかもしれない同種の問題にどう対処するかについて検討します。基本は、原因構造解明で明らかにした問題発生メカニズムの全貌を考察して、どの因果連鎖をどう断ち切るか、どう軟着陸させるように誘導するかなどについて、広い視野から検討することです。大切なことは、候補となりうる対策を広い視野から吟味し、焦点を絞った効果的な対策を打つことです。「根本原因をつぶせ、原因はすべてつぶせ」というトラウマにはとらわれない方が得策です。

どのような対応を取るか考察する際には、候補となっている対応策について、効果、経済性、(技術的)実現可能性、対応策実施の完全性・継続性、対応策の副次的効果などについて検討します。できないこと、する気のないこと、守れないこと、実施しても効果の小さなこと、副作用の大きなことはすべきではありません。

「効果」とは、対応策を実施することによる、その問題の抑止効果のことです。原因構造解明が正しければ、因果連鎖のどこをどう変化させることによってどのような効果が得られるか正しく考察できます。「これで行こうかな」と思ったとき、私は「その対策案によって、本当に、その手の業務を自然体で上手くこなせるだろうか」と思案します。「経済性」とは、その対応策に必要なコスト、投資、追加工数などです。「(技術的)実現可能性」とは、その対応策が、本当にその業務システムのなかで実施できるだろうかという検討です。業務プロセスによっては、候補になっている高度な技術が、仕事の流れのなかで調和して実装できないこともあります。「対応策実施の完全性・継続性」とは、その対応策を自然体でほぼ忠実に実施できるか、続けていけるかという検討です。担当者に長時間にわたる緊張感を強いるような方法は、始めはともかく、間もなく雲散霧消します。「対応策の副次的効果」とは、対応策による、ねらった効果以外の副次的効果や副作用などの検討です。とくに副作用の検討は重要で、改善したつもりがかえって改悪になっていることがないかどうか検討します。

問題

[1] すでに原因分析をし、それに基づいて対応策を導いた、業務システムの改善事例について、ここに挙げたようなアプローチで原因分析を実施してみて下さい。すでに実施した分析との間に相違がありましたか。もし、あったのなら、それは問題や原因の構造を探る際のどのような視点の違いにあったからと思いますか。

[2] その問題を発生させた、純粋に技術的な因果メカニズムは解明できましたか。それらの技術的因果メカニズムに関わる知識は、組織知として構造的に可視化され、必要に応じ参照可能となっていましたか。構造的に可視化され参照可能となっているにもかかわらず問題が起きたのであれば、プロセスのどこに不備があったからですか。もし、そうでないとすると、マネジメントシステムのどこにどのような不備があったからですか。さて、現実的な対応策は、どのようなものであるとお考えですか。