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

3. 科学的問題解決法

3.1 QCストーリー

先月は、問題解決にあたっての基本的なことがらをお話しました。今月は、問題解決法の基本ともいえる「科学的問題解決法」を再確認することから始めます。品質管理の分野では「QCストーリー」といわれる問題解決法です。

QCストーリーという名称からは、やや軽い印象を受けますが、いわゆる科学的方法と言われる思考形態、すなわち「観察→仮説→検証→法則」というステップ(観察した事象に関わる仮説を立て、それを検証して、それらの事象を説明できる法則を導く)を繰り返して知見を得ていく方法と本質的には同じで、至極まともな考え方を基本にしています。

いろいろな説明があるようですが、基本的には次のようなステップからなります。

(1) テーマ
(2) テーマ選定の理由
(3) 現状把握
(4) 解析
(5) 対策
(6) 効果の確認
(7) 歯止め
(8) 今後の課題

以下では、この各ステップにおける留意点を検討します。

この連載の第12回の「継続的改善」のなかの「3. 改善の基盤−問題解決力」の項で、有効な改善を組織的に推進していくためには、その基盤として、起きた問題の解決能力が必須と申し上げました。そして、問題解決にかかわる能力を表に示しました。その内容を詳細に説明する形で、QCストーリーの各ステップのポイントを挙げておきます。

3.2 (1)テーマ、(2)テーマ選定理由

これから解決しようとする「問題」を述べ、またそれがなぜ問題でなぜ解決する必要があるのか、あるいはその問題の解決を通して達成したいことを明確にします。重要なことは、取り上げたその問題が、取り上げるに値する“まとも”な問題であることです。

問題を解決するためには、まずは問題があるのではないかと感じて、状況を調査・分析し、問題があるかどうかをはっきりさせようという気にならなければなりません。ところが「その気になること」はそれほど容易なことではありません。日ごろから、危機感を抱き問題意識が持てるような組織運営を心がける必要があります。

漠然とした危機感や何とかしなければならないという問題意識を持っていたとしても、それだけでは問題を具体的に認識はできません。一つの方法は、組織のあるべき姿と現状の差を分析し、「結局のところ、現在何に困っていて将来何に困りそうなのか」という問いかけをすることです。ところが、問題の中には、問題であると「認識しにくい」ものがあって、このような簡単な問いかけでは問題が見えてこないことがあります。私は、以下の3つのタイプを見聞しました。

• 複雑:組織、仕組み、情報網に関することなど、問題があったとしてもその現れ方が複雑で見えにくい問題
• 未来:放置したら将来ゆゆしき問題となる状況など、見えているとしても今のところ兆候しか現われていなくて見えにくい問題
• 防衛:自分を分析し自分を変えざるを得ないことを嫌うため、問題として取り上げることを無意識のうちに避けようとする自分の問題

問題の存在を認識できたとしても、それが漠然としていてなかなか特定できない場合があります。解決すべき問題がまだ明確になっておらず、事実の収集とその分析という過程を経てはじめて問題が特定されるような場合が多々あります。問題を特定することが難しいような問題に対しては、このステップを

(a) 問題らしきものの現状把握
(b) 問題の構造の分析
(c) テーマ設定
(d) 目標設定
(e) 問題解決計画の立案
に分ける必要があると思います。

テーマ設定のこれらのステップの中では「(b) 問題の構造の分析」が最も難しいと思います。ここでいう「問題の構造の分析」とは、問題を分解することと、分解された問題間の関係を把握することを意味しています。この分析によって、取り組むべき漠とした問題らしきものの本質的部分が明らかになります。

こうした考察を経て「(c) テーマ設定」がなされ、その問題の何が、どの程度、どのような意味で問題なのか、その問題がどのような関係者の間のどのような環境・制約条件での問題なのかが明らかにされ、問題の様相が明確にされます。

問題が明確にされたら「(d) 目標設定」となり、その問題のどの側面を、どの程度まで改善すべきかについて、ある程度合理的な、明確な目標を決めます。ところが、問題によっては達成可能な合理的目標を設定することが難しい場合があります。合理的目標を設定するためには、多少の問題発生原因の分析や対応策の検討が必要です。目標設定のための分析を徹底的に行うと、目標を設定できるころには問題の解決案が明らかになってしまいます。分析を精緻に行いすぎると「あるべき姿」ではなく「達成可能な最低水準」を目標としかねません。かといって分析をいい加減に行うと、合理的目標を設定できません。このジレンマを克服できるかどうかは、想定原因、取りうる対策、その対策の期待効果に関する事前に保有している知識や情報の質と量にかかっています。

さらに、課題によっては、達成可能かどうかを考えるまでもなく、とにかくやり遂げなければならないというものがあります。事実上目標が設定されていないに等しいとも言えるのですが、それはおかしいと簡単に排除することもできないでしょう。絶対に達成するとの気構えで「人事を尽くして天命を待つ」という問題解決があってもよいと思います。

要は、その問題に関わる上位目標達成への寄与と、その問題の目標達成可能性の2つを勘案して決めることになります。

問題が明確になり目標が設定されたら、「(e) 問題解決計画の立案」をすべきです。解決への過程を完全に見通すことは難しいのですが、自己・会社・世の中の経験を調査することによって、解決への過程がそこそこ見通せるかもしれません。

3.3 (3)現状把握

このステップでは、観察・計測などによって事実を集積し、問題がどのように発生しているかを正確に把握します。この状況把握によって、問題のありか、力点を置くべき課題などが明らかになり、以降のステップの方向性を妥当なものにできます。

問題解決にあたり、その問題に関する事実をよく調べずに、先入観で行動を起こす人がいます。事実かどうか分からない他人から聞いただけの話を、なぜああまで信じ込んでしまうのでしょうか。可能であれば、問題が起きている現場に行って事実を把握すべきです。自席にいたのでは事実はなかなか把握できません。問題の実態を自分でよく観察したいものです。意外なことが分かるもので、まさに「事実は小説よりも奇なり」です。他人からの情報、他人が集めたデータで行動を起こすと、ひどい目に遭うことがあります。計測は正しいのか、データは加工されていないのか、事実に基づかない報告ではないのか、よく調べないと誤った方向に進みかねません。

例えば不具合が発生すると、管理者・技術者はもっともらしい説明をしたがります。しかも興味深い不具合発生メカニズムで。ただ、業務実施者が業務・作業標準を守らなかっただけかもしれないのに。その技術者が考えているような不具合現象ではないかもしれないのに。「不具合発生に至るメカニズムが技術的にそんなによく分かっているのにどうしてそんな問題が起きるのですか?」と聞いてみたいものです。

このステップにおける難しさは「何を見るか」に尽きます。問題には、何を見れば問題の現状を把握したことになるかが比較的分かりやすい問題とそうでないものがあります。例えば、ある品質不良が問題であるとき、どんな現状把握をすればよいかについて、それなりの常識が存在します。一方で、品質マネジメントシステム(QMS)に問題があるとき、問題がどのように現われているかを的確に表現することは、易しくはありません。社内の情報ネットワークに関して問題があるとき、この現状を把握するのも難しいでしょう。こうしたマネジメントシステムに問題があるとき、どこがどのように問題であるかを見る方法については、次月に「マネジメントシステムの脆弱性分析」で検討することにします。

「何を見るか」の次は「どう見るか」、すなわち見る方法です。重要なことは、もちろん「事実の把握」です。そのために「観察」をします。これには、目で見る観察も、科学的な測定・分析も含まれます。難しいのは、人が何を考えどういうつもりで何をしたか(人の思考プロセス)について“見る”ことなのですが、上手な「質問」によって、「どのような状況で何があったかのか」を知るようにします。「なぜ?」と聞いてはいけません。「なぜ?」には、「なぜ、してはいけないことをしたのか?」「なぜ、するべきことをしなかったのか?」「なぜ、間違えたのか?」など、責め立てる感じになり、正しいことができなかった背景要因、誘因のヒントが得にくくなります。

問題の発生状況に関して何をどう見ればよいか分かったとしても、問題によってはそのことに関する事実の集積が難しい場合があり得ます。たとえば、「売上げ目標未達」という問題に対して、どこでどのように売り上げられなかったかに関する状況を正確に把握しないと鋭い分析にはつながりませんが、これは一筋縄ではいきません。受注しようとして受注できなかった失注にしても、受注機会を見逃しての受注遺失にしても、その原因を的確に把握するのは易しくはありません。このように観測・観察が原理的に難しい場合や、時間的制約や経済的制約によって状況把握が難しい場合があることも心にとめて、何とか垣間見るとか、関連事象から推測するなど、実態を把握する現実的な努力をしたいものです。

その上で「実態の把握・特徴の抽出」が必要です。その基本的な方法は、「比較(何が違い、何が同じか)」と「変化(いつから何が変わったか)」と思います。比較においては、基準、対照、以前、良い例/悪い例などと比べて何がどう違うかを知り、事実の特徴を把握します。変化も同様です。いつからどう変わったのかという情報は貴重です。時間そのものは原因ではあり得ませんが、時間とともに変わった何かが原因に関係しているかもしれません。これらの考察が原因構造分析に大いに役立ちます。

丹念に拾い集めた断片的事実を積み重ね、ジグソー・パズルを解くように問題の真の姿を見つけたいものです。問題の発生の仕方の“クセ”を知るように努力しなければなりません。それで真実を垣間見ることができるかもしれません。いま問題になっている不具合は、どんな時にどんな状況で発生し、どんな姿をしているのでしょうか。それらは不具合発生のどんなメカニズムを示唆しているのでしょうか。こんなことを自問しながら、問題の実態を把握したいものです。

3.4 (4)解析

このステップは、問題があるという結果とそれを引き起こしている原因との関係を明らかにすることを主眼とします。問題を生じさせている原因を特定するためには、まず原因の候補を列挙する必要があります。数少なく、しかも見逃すことなくその問題に特有の原因の候補を挙げるためには、その問題に関連する分野に固有の技術についての十分な知識を基礎として、それまでに集積した事実から示唆される問題発生のメカニズムを論理的に想定することが大切です。

いま目の前にある問題がこの世で初めてということはないでしょうから、過去にその種の問題がどう分析され、どう解決されたか、一応は組織内外の関連情報を調査してみるべきでしょう。

全く情報が無いように思えても、物理・化学、生物学、社会心理学、認知科学などの知見を参考に、起きている問題発生の仮想的メカニズムを論理的に組み立てることは、ある程度できるはずです。その不具合が自然科学法則に従う現象であれば、その発生原因は、必ず、物理的・化学的に説明できるはずです。問題が、組織運営に関わる問題であるなら、社会学・社会心理学、認知科学の知見を活用して、説明できるはずです。断片的事実を積み重ね、その不具合が発生しうるいくつかの仮想的メカニズムを論理的に組み立てたいものです。

問題を引き起こしている原因を特定するためには、原因の候補のいくつかがまさにその問題の原因になっているということを実証しなければなりません。ところが、原因の候補をいくつか挙げて、そのうちの特定の少数が主要な原因であると言い切る人がいます。たとえそれが論理的には正しく組み立てられていようとも、「自分がそう考えている」ということと、「現実にそうである」ということは、明確に区別しなければなりません。

「現実にそうだ」と言うためには、論理的に他にはありえないと言えるか、あるいは実証が必要です。不具合の原因が、自分が想定したものであることを、実験やすでに存在しているデータの解析によって確かめなければなりません。例えば、自分が想定した不良発生メカニズムを再現させて不良を意図的に発生させる再現実験は、その一つの手法です。

ところが、技術的・経済的理由により調査・実験の実施可能性、観測可能性、時間的制約などによってこの検証が難しいことがあり、因果連鎖の論証の積み重ねや可能性の高い推論など現実的な方法に頼らざるを得ない場合もあります。

現状把握や解析においては、必要に応じ、適切な技法・手法・方法論などを使いこなせればと思います。難しい手法を使う必要はサラサラありません。事実の構造的可視化のための基本的手法で十分です。

3.5 (5)対策

問題を引き起こしている原因が特定されたら、これを除去するような現実的な対策案を考え、実施に移します。ところが、問題が起こるとすぐに、「こうすればよい」と手を打ち、うまくいかなければ他の手を打つということを繰り返して、自分が打った手の効果に一喜一憂し、たまたまその問題が収まればそれでおしまい、という方が少なからずいます。

問題に対応しようというその積極性は大いに結構ですが、問題の原因を除去するような対策を打たなければ、本当の効果は期待できません。真の原因を事実に基づいて発見し、その問題の本質を理解した上で、現実に採用可能な効果的な対策を打ちたいものです。

しかし、原因は分かってもこれを除去できる有効な対策案を思いつけないことがあります。簡単に対策案を思いつけないときには、その問題の発生に到らしめた因果の連鎖を表現し、その連鎖のいずれをどんな手段で断ち切るのが効果的・効率的であるかを検討するのがよいでしょう。

対策案を考えるときに、その対策の有効性を総合的に評価すべきです。最初に思いついた一つの案のことしか考えないというのは賢くありません。その対策は本当に効果があるのでしょうか。現実的で実行可能なのでしょうか。どれほどの費用がかかるのでしょうか。「副作用」は無いのでしょうか。「より良いことは良いことの敵だ」とのことわざにあるように、ねらった効果は得られても思わぬ副作用が現れてしまう失敗は避けたいものです。対策を考えるときには複数の案を候補とすべきです。そして、それぞれの案を実行したときの影響を、ねらった効果のみならず、品質、コスト、効率、安全、維持・整備、計測容易性、材料・部品などの入手容易性などの広い考慮を払って評価したうえで決めたいものです。

対策といっても様々のものが考えられます。問題発生そのものを防止するための原因除去、速やかな処置を促すための問題の早期発見、問題が発生しても影響を小さくするための影響防止などがあり得ます。対策立案においてこの観点も重要です。

3.6 (6)効果の確認

対策を講じたら、その効果を問題発生防止、副作用発生、コスト・効率などの面から評価する必要があります。効果の確認に際しては、問題解決の前後で同一尺度での比較をすることと、効果の直接的把握に努めることが大切です。

結果が良かったかどうか確かめない人は少ないでしょうが、確かめてはいても、漠然と全体的・間接的な効果を見ているだけのことがあります。対策の効果は直接計るようにしたいものです。たとえば、業務のミスを低減するために要因解析をして、そのうちの一つの要因に対して手を打ったとしましょう。ミス全体の発生率がどう変化したかだけでなく、たとえば、そのミスがある特定の状況で起きやすいのなら、その状況のときの発生率がどう変化したかをできるだけ定量的に見るべきです。自分が想定したメカニズム通りに不具合が発生していたことを、因果の連鎖の各段階での変化で確認できれば、それは素晴しいことです。

問題によっては、効果の正確な把握までに時間がかかり、それまで待っていられないという場合があります。システムの改善、長期的目標の達成など例はいくらでもあります。このようなときは、中間結果や最終結果に結びつく条件・状態で確認し、最終結果を予測するというような工夫が必要になるでしょう。

3.7 (7)歯止め

対策に総合的な効果が認められたら、この効果を持続させるための「歯止め」を考えます。対策を日常的に実施するための標準化、標準の意味・根拠の周知、標準遵守の諸施策を考えるということです。歯止めにおいては、無理なく確実に実施可能かどうかの吟味と、確実に実施しているかどうかの継続的確認が必要です。

ところが、原理的に有効であると分かっている対策でも、長期的に自然に実施できるような歯止めに結びつけるとなると、その実現が難しいことがあります。三日坊主はともかく、3カ月ほどで雲散霧消する改善は日常茶飯に経験します。ルール・標準・指針などの根拠の理解と、それらを愚直に守ることの重要性に関わる組織文化・価値観の醸成が必要です。

3.8 (8)今後の課題

問題が一応解決したら、その問題の解決を完全なものとし、また関連する問題の解決の一助とするために、残された問題と将来起こることが予想される関連する問題を明らかにしておきます。QCストーリーのこのステップは、一般には、結びの言葉以上の意味には解釈されていないようですが、将来への見通しを立てておくという点で重要です。

4. 問題のタイプ

4.1 問題のタイプの考慮

前章では、発生した問題の解決の手順として、QCストーリーの各ステップのポイントを述べました。しかし、まだ起きていない問題、例えば、社内○○制度構築、○○情報システムの構想・設計、○○法開発などのような課題にどう対応すればよいのでしょうか。品質管理の分野でも「課題達成型問題解決」にも対応すべきと言われ、実際にそのような手法・手順が提唱されています。

こんなことからも、問題解決の定石を考えるにあたって、問題と言われるものを必要最小限のタイプに分けておく必要がありそうです。どんな観点で分ければよいのか迷うところですが、2つの視点から4つに分けてみることにします。2つの視点とは、

(a) 起きてしまった問題/まだ起きていない問題
(b) 個別の問題/仕組みの問題

です。

(a)については、この両者の違いを際立たせるため、「分析型アプローチ/設計型アプローチ」という言い方をする場合があるようですが、「設計型アプローチ」において分析が必要ないとの誤解を与えかねないので注意が必要です。実際、まだ起きていない問題の解決においても「分析」が必要です。ただしこの分析は、QCストーリーでいう現状把握や要因解析とは少し違ったものです。すなわち、その課題が取り上げられる契機となった現存する問題について、その本質的部分の明確化、その課題に関連する因果メカニズムを含む様々の知識の調査と整理、調査によって得られた知識のその課題への適用可能性の吟味などの分析が必要です。何の分析もなくいきなり良い案を思いつこうとすることが「設計型アプローチ」の真髄であるかのような誤解は、まさに愚の骨頂と言わざるを得ません。

まだ起きていない問題の解決において重要なことは、「優れた案の発想」と「鋭い問題予測に基づく案の評価」の2つです。この2つとも人間の思考のうちでもかなり高度であり、比較的よい結果に導く方法論を記述することは難しいものです。私は、問題の因果メカニズムや目的・手段関係に関する、適度な抽象レベルでの構造化知識が鍵になると思っています。

(b)の視点は取り上げる必要がないかもしれません。しかし、私の観察によると、仕組みの不備を分析したり、新たな仕組みを構想するときには、個別の問題の原因分析をしたり、新しい具体的なモノを創造したりするのとは違った難しさがあるように思えますので取り上げることにします。

では、(a)と(b)の2つの視点を組み合わせて、問題を

[1] 起きてしまった個別の問題
[2] 仕組みの改善
[3] 新しいモノの創造/新たな知識の獲得
[4] 新システムの構築/大幅なシステム改善

の4つに分けて、それぞれにどのように対応したらよいか考えることにします。

4.2 問題解決のステップ

これら4つのタイプの問題を解決するために、基本的にどのようなステップに従うのがよいでしょうか。[1]、[2]はQCストーリーのステップに従うのがよいように思います。ただし、[2]のタイプの問題では、問題そのものを正しく認識するまでのステップが重要ですので、そのことを考慮すべきと思います。

[3]、[4]については、「優れた課題達成案の発想」と「その案の的確な評価」に焦点を当てたステップを考慮するのがよいと思います。

[1] 起きてしまった個別の問題の解決のステップ

このタイプの問題に対しては、QCストーリーのステップをそのまま採用して

(1) テーマ
(2) テーマ選定理由
(3) 現状把握
(4) 解析
(5) 対策
(6) 効果の把握
(7) 歯止め
(8) 今後の課題

という、手順で問題解決を図ることにしたらよいと思います。



[2] 仕組みの改善のステップ

このタイプの問題に対しては、上記のステップ(2)を分解して

(2-1) 問題らしきものの認識
(2-2) 問題らしきものの現状把握
(2-3) 問題の構造の分析
(2-4) テーマの意義や焦点を当てるべき領域・側面の明確化
(2-5) 目標設定

というステップを、テーマ設定の際に踏み、問題・課題の実態の把握を確実に行うようにしたらよいと思います。

とくに、「(2-3)問題の構造の分析」、さらに「(3)現状把握」、「(4)解析」において、個別の問題の把握と解析とはひと味違った分析が必要となりそうです。この方法については、「業務システムの脆弱性の分析」と題して、次月に詳しく考察します。



[3] 新しいモノの創造/新たな知識の獲得のステップ

このタイプの問題に対しては、例えば以下のように進めることが考えられます。

(1) テーマ……問題の構造の理解とテーマ設定
(2) 解決計画……解決に至る道筋、予想される困難
(3) 事前調査……情報収集、可能性の検討、「世の中どうなっているのか」の確認
(4) 評価項目……目的特性値の明確化、広角・複眼・遠近両用の視点
(5) 因子……目的特性値に影響を与えると思われる因子の列挙、交絡(効果の混合)、交互作用(組合せ効果)、調査範囲などの考慮
(6) 実験・調査……調査、予備実験、新知見獲得の実験、データ解析、技術的解釈など
(7) 対応策……現実的対策の立案
(8) 確認……確認実験、使用・環境条件の考慮、ばらつきの確認
(9) 技術の蓄積……得られた知見の一般化、再利用可能な知識の獲得



[4] 新システムの構築/大幅なシステム改善のステップ

このタイプの問題では、過去を詳細に振り返るより、あるべき姿を提示して、これを多面的に評価した方がよいでしょう。以下のようなステップで進めることが考えられます。

(1) 課題の明確化……最終目的、ねらい
(2) 解決計画の立案……プロジェクト計画(実施事項・手順、日程、資源、リスクなど)
(3) 現状分析……問題の本質の見極め、関連情報の収集(ほどほどに)
(4) 構想……構想案、新システムの記述の工夫(何をするか、情報の流れ、ヒトと機械、モノと情報)
(5) 構想内容の評価……問題予測、机上評価、レビューの視点、思考実験
(6) 構想の実現……新システム実装の計画・実施
(7) 実施評価……問題摘出、確認、モニター方法
(8) 今後の課題……得られた知見、残された課題、今後の計画



4.3 [3]新しいモノの創造/新たな知識の獲得

上記の手順だけでは少々分かりづらいと思われる[3]と[4]のタイプの問題への取組みについて、その留意点をご説明しておきます。まず、新材料・新機構・新技術・新ツール・新手法などの考案・開発・評価など、[3]のタイプの問題・課題では、いかに無駄なく知るべきことを知り、最適な道へ進むかが鍵となります。

(1) テーマ

この種の問題・課題は未知の部分が多く、それだけに始めのうちは努力した分だけの新しい知見が得られ、新たな興味もわき、充実した楽しい時間が過ごせるものです。基礎研究の中には、何があるか分からないので研究者の興味とセンスに任せておいてもよいものがありますが、多くの場合何らかの目的を持っているのが普通です。ともすると、これを忘れます。どんな制約の下で何を目的としているのか、明らかにしておきたいものです。錯綜しやすい大きなテーマの時には、きちんとサブテーマに分けて、サブテーマ間の関係を明らかにしておくべきです。

例えば、「新技術XYZ法の開発」などというテーマで活動を進めている場合、ときどき自分の目指すものは何かと問いかけてみた方がよいでしょう。新しいことが次々に分かってくると、ついつい寄り道をしたくなるものです。寄り道をした方が良い場合もありますので一概には言えませんが、当面の目的が何であったかは常に確認しておくべきでしょう。

(2) 解決計画

新しい何かを得ようとするのですから、何が起こるか分からないとも言えます。だからこそ運にばかり頼ってはいられません。問題を解決に導くために何をしたらよいのか、またどんな困難が予想され、それはどのようにしたら回避できそうなのかを、問題に着手するときに考えておくべきです。PDPC法(https://www.i-juse.co.jp/statistics/product/func/nqc/pdpc.html)などの手法が利用できるでしょう。不透明なものを相手にするときに、起こり得ることを予測して、それが起きたときの影響や対応策を考えておくことはよいことです。その方が良い道を探せる確率が高いでしょうし、何よりもうまくいかなかったときの対処の仕方が変わってきます。

新QC七つ道具の中のPDPC法は、私の好きな手法の一つです。研究開発や販促プロジェクト、重要サプライヤーとの取引契約など、事態の成りゆきに関する不透明さが問題となる領域で盛んに活用されています。複雑な研究開発などでは、その解決を個人あるいは小グループの活動のみに委ねるのは危険であり、重要な局面においては、全関係者による組織的な協力が必要です。このような場合、担当者が現在までの経過と問題点をPDPC法でまとめて関係者に示すことにより、関係者による問題点の理解と積極的な参画が容易なものとなります。

(3) 事前調査

新しいこととはいえ、先人が何か調べているかもしれません。自分が解決しなければならない問題の実像を明らかにするために、解決のためのより良い道筋を探すために、しなくてもよい無駄を省くために、その問題に関することはできるだけ調べておくべきでしょう。

調べたことのすべてが有効であるとは限りません。それがどのような背景を持った情報かを正しく把握し、本質だけを抽出したいものです。調べすぎたため多くの適切でない情報を得て判断を誤ったり、多くを知りすぎて萎縮して身動きが取れなくなってしまうなどというのは、当の本人の問題への取組みに改善の余地があるだけのことであって、調査そのものが悪いわけではないはずです。

(4) 評価項目

問題そのものが明らかになったら、まず評価項目を定めるとよいでしょう。目的がどの程度達成されたかを測る、適切な特性値を定めなければなりません。意を注ぐべきは、「広い考慮」です。物事には様々の顔があります。ある一面だけを見ていたのでは誤った判断をします。問題の性質上、未知の部分の多いものを対象としているのですから、広角・複眼・遠近両用で評価したいものです。

機能・性能を気にしていたら、「使われ方」を考えてみるべきです。時間が経ったらどうなるか考えてみるのもよいでしょう。同時に、作りやすさ、直しやすさ、運びやすさなどについても考えるべきです。品質について評価しようと思っているときには、コストについても考え及ばなければ一人前とは言えません。

(5) 因子

なるべく良いものを作りだそうとしているとき、目的特性値に影響を与えると思われる因子をいくつか取り上げて、実験や計算を行うでしょう。因子は先入観を持たずに列挙すべきです。実験できないとか、測定が難しいとかいうことは、あとで考えればよいことです。

過去に行われた実験・調査・解析などから、取り上げる因子を絞り込むときには、「交絡」(効果の混合)、「交互作用」(組合せ効果)、「調査範囲」(因子のどの水準範囲についての知見か)をキーワードとして特別の注意を払いたいものです。

(6) 実験・調査

実験・調査を行うときには、用いる手法の本質を理解して正しい計画を立てたいものです。失敗すると、良くても不十分な情報しか得られず、普通はやり直し、時にはやり直しもきかないことがあります。

実験・調査のデータは、ぜひとも正しく解析したいものです。どんなに手間がかかろうとも、解析に要するコストは、データを得ることに比べたらわずかなものです。それなのに、なぜかその大切なデータに対してお粗末な解析で済ませる人が少なからずいます。

実験・調査の解析結果には、屁理屈でもよいですから、もっともらしい技術的解釈をしたいものです。理屈にならない理屈を考えて呻吟するうちに、はっと素晴らしい解釈を思いつくことも期待できます。すべての解析結果を矛盾なく説明する、物理・化学的メカニズム、生理学的メカニズム、あるいは社会科学的メカニズムを提示できたら素晴らしいことです。

(7) 対応策

問題にしていることの因果関係がほぼ明らかになったら、この知見を利用して目的特性値を然るべき水準にするための対応策を考えます。目的は多面的であり、したがって対応策は妥協の産物となるでしょう。個々の目的の重要度を考慮し、根拠の明白な、現実的な対応策を定めたいものです。

(8) 確認

未知の側面の多いものを評価していますので、これまでに得られていることが絶対に正しいと確信するわけにはいきません。事情の許す限り、数を増やし色々な条件の下で確認をとりたいものです。どんなレベルになるかだけではなく、ばらつきがどのくらいあるかも知っておくことが重要なときもあります。

(9) 技術・知識の蓄積

得られた知見は一般化して、共有できる「技術」として蓄積すべきです。当面の問題が解決できればそれでよいというものでもありません。今回取り組んだ課題の周辺に関して、何がどうなっているのかについての一般的知識を得ることも大切です。これが組織的にできるようになれば、似たような実験・調査を繰り返す必要もなくなり、この手の問題解決自体の効率が格段に向上することになります。

先輩が過去に行った実験結果が利用できないと、なぜ若い技術者は言うのでしょうか。技術の進歩が早すぎて、少し前の実験結果などとても参考にならないのかもしれません。参考にできる技術資料の存在そのものや、存在する場所が分からないためかもしれません。でも本当のところは、残された技術資料の質が問題ではないのでしょうか。実験は、目的特性値を最適の値にする因子の水準を定めるためだけに行っているのではありません。因果関係のメカニズムとその定量的関係を知ることも大切です。そうであるなら、然るべき因子を取り上げ、広い水準範囲で、交互作用を考慮した実験を行い、その目的特性値がどのようなメカニズムで変動するのかについて、できるだけ広く通用する一般的知識を技術資料として残したいものです。

4.4 [4]新システムの構築/大幅なシステム改善

これまでにないような新しいシステムを構築するときや、既存のシステムの大幅改善に取り組むとき、どのような点に留意すべきでしょうか。

(1) 課題の明確化

新システムのねらい、システムの大幅改善の目的と理由などを、始めに明らかにしておかないと、どの範囲までのシステムを構築するのか、どの程度の改善をするのかが不明確になりかねません。構想を固めるうちに変わって来ることもありますが、無用の混乱を避けるため、活動の初期に広い範囲の人々にとっての共通認識を得ておいた方がよいでしょう。

(2) 解決計画の立案

課題達成に必要な要員・工数、専門性、機器類などの必要リソースの質と量を見積り、手順、スケジュールを定めます。必要な能力分野、レベル、必要量をある程度の精度で見積もることが基本になりますが、同時にリスクとその対応方法も考慮しておく必要があります。

それなりのレベルの「プロジェクト計画」を作成すべきでしょう。計画に盛り込む項目としては、以下のような項目があり得ます。

• 目的:プロジェクトの目的
• 概要:プロジェクトの意義、理由・背景、制約・境界条件など
• アウトプット:プロジェクト活動の結果として得られる具体的結果(新システム、新体制、新たな状態、新技術、新製品など)
• インプット、参照情報:プロジェクトへのインプット(もの、情報)や参照情報
• WBS(Work Breakdown Structure):具体的実施事項
• 関連活動:関連する他のグループとの関係、必要な活動など
• マイルストン:スケジュール、重要な中間目標達成時期
• 必要リソース:プロジェクト遂行に必要な人、モノ、カネ、時間、知識、コミュニケーション・インフラなど
• リスク:想定しうるリスクとその対応

なお、この種のプロジェクト計画は、当然のことながら、タイプ[3]の「新しいモノの創造/新たな知識の獲得」についても作成すべきです。

(3) 現状分析

全く新しいか、かなり異なったシステムを作ろうとしているのですから、現状の解析はほどほどにしておいた方がよいと、私は考えています。この解析の目的は、現状システム内の不備を細かく分析し改良案を得ることではなく、現状システムでは何が本質的に大きな問題であるのかの共通認識を、議論でも感想でもなく事実に基づく分析から得ようとするものです。現状システムについて、子細な業務フローを描き、これを用いて不備を列挙している例をよく見かけますが、あまり効果的ではないと思います。システムの大幅改善では、現状の深い分析に基づく現在のフレームワークでの改善よりも、問題と分かったら根こそぎ変えてしまった方が、効率的・効果的な場合が多いからです。

(4) 構想

どのようなシステムの構築を目指すかがおおよそ明らかになったら、新システム案を「こうあるべきだ」と案出して、広い考慮を払った綿密な評価を多くの人々の参加を得て行った方がよいと思います。

良い構想設計をするためと、多くの人の適切な評価を受けるために、新システムの記述方法には力を注ぐべきです。システムがどんなものであるか、どんな問題が潜在していそうかを容易に理解させるものでなければなりません。ソフトウェアの要求分析・要求定義の方法が参考になるでしょう。たとえば、「どうするか」でなく「何をするか」をトップダウンで考える、システムに情報がつきものなので、まず情報(データ)の流れを考える、現実の業務はヒトと機械、モノと情報のからみ方が問題となるので、このことにとくに留意する、などです。

(5) 構想内容の評価

新システム案の評価にあたっては、システムをうまく記述した書き物を使って、ねらいが達成できているかを評価します。これといった方法が確立しているわけではありませんので、まずは、なるべく多くの人に評価してもらうのがよいでしょう。その際に重要なのは、システム記述文書の質です。然るべき人にシステムの具体的イメージを持たせ、システムの不備をできるだけ多く指摘してもらえるようにしたいのです。

そのシステムで処理される様々の形態の業務を、机上で流してみるのも一つの方法です。改善のねらいが達成できているかの確認を第一にするのですが、個々の業務例について「もしこれがルール通りでなかったらどうなるか」と様々の例外を想定してみて、うまく処理できるかどうかチェックしてみるとよいでしょう。

(6) 構想の実現

構想したシステムが完成したら、それを実業務に適用することになります。業務実施方法が大きく変わることになりますので、関連する要素、例えば業務手順、業務実施者、設備・機器類、標準類、帳票類などの変更を具体的にどう実行に移していくかを記した周到な計画に従って新体制に移行します。

(7) 実施評価

実際に適用された新システムを評価します。システムの不備を早期に摘出し改善するために、新システムの開始時から、不備の吸い上げ方、不具合の記録や調査の仕方などを決めておくなど、モニター方法を埋め込んでおくとよいでしょう。

(8) 今後の課題

得られた知見、残された課題などを整理し、今後の計画を明確にしておきます。

問題

[1] 発生した個別問題のうち、ご自身が過去に取り組んだ解決事例について、QCストーリーの手順に従って、解決への経緯をレビューしてみて下さい。どのような改善の余地がありますか。

[2] 問題解決においてQCストーリーがその持ち味を最もよく発揮できるのは、①何が問題か比較的よく認識できる問題、②起きてしまった問題、③原因の候補を挙げることはできるがすぐに特定するのが難しい問題、に対してであると思われます。この3つの特徴の意味について考察してみて下さい。

[3] ご自身が過去に取り組んだことのある問題・課題について、「問題のタイプ」で挙げたような分類をしてみたとき、タイプに応じた解決手順を踏んだかどうかレビューしてみて下さい。

[4] 「新しいモノの創造/新たな知識の獲得」に分類される問題・課題の解決において、どのステップが最も重要と思いますか。それはなぜですか。ご自身の課題達成事例の経験に照らして考察してみて下さい。

[5] 「新システムの構築/大幅なシステム改善」に分類される問題・課題の解決において、どのステップが最も重要と思いますか。それはなぜですか。ご自身の課題達成事例の経験に照らして考察してみて下さい。