連載記事 飯塚悦功
第10回 知的業務のプロセス管理

1. プロローグ

1.1 設計プロセスに品質管理は適用できない?

私にとっての品質管理の洗礼は統計的品質管理(SQC;Statistical Quality Control)でした。大学での専門が応用統計で、その縁で品質管理に触れることになりました。その後、実践的な品質管理に取り組むようになります。時代は1970年代半ばです。共同研究のようなことを始めました。紹介されて行った会社での経験は貴重でした。良質な製品を効率的に生み出すための経営管理の実態を垣間見ることができたからです。

若かった私は、そこで優秀な設計技術者とぶつかることになります。その方は「設計に品質管理は適用できない」と言うのです。「設計は、新たなものを生み出す、いわば一品生産だから、量産工程の管理のための品質管理手法は適用できない」と主張します。「図面、仕様は、一枚一枚すべて異なり、一つの仕様を決めるにも独創性が要求され、標準化とか管理(画一化、統制・統御というような狭い意味でした)とは相いれない」と、もっともらしいことを言います。

「冗談じゃない。何が独創性ですか。もちろん独創性が必要ないとは言いませんが、あなたの設計に本当の意味での“初めて”のものなんてわずかしかないでしょう。どんなに少なく見積もっても80〜90%は過去の設計の流用ではないですか。“初めて”と思っているものでも、材料とか動作原理(機能発現メカニズム)は過去の設計で適用したものと同じですよね。どんなに新規と思っても何がしかの繰り返しがあるし、良い設計を生み出す優れた方法・プロセスというのものがあるはずです」
「それじゃあ、飯塚さんは、設計にも製造工程のようなプロセス管理を適用できるというのですか」
「はい、もちろん。そのままではだめですよ。設計というものの特徴を踏まえた工夫が必要でしょうけど」
「面白い、その優れたプロセスとやらを作ってもらおうじゃありませんか」

こうなったら引き下がれません。でも私には、当該製品に関わる製品設計技術や生産技術(工法)に関する十分な固有技術がありません。
「技術的に優秀で、頭の柔軟な(≒新しいことの本質を見極め試してみようと思う積極性のある)若い方を私の相棒に選んで下さい」
そうお願いして若く優秀な相棒を得ました。

1.2 設計業務のプロセス管理

こうして共同研究が始まりました。こちらに答えがあってそれを伝えればよいというわけではありませんので、何が問題で何が難しいのか、なぜそのようなことが問題になるのか、少しは分析してみなければなりません。そこで、もっときちんとやっていれば避けることのできた設計変更の分析をしました。設計とは要求・ニーズを満たす手段を指定する仕様を決めることです。それがうまくできなかった理由を分析しました。例えば、要求・ニーズの意味が分からない、実現手段の選択に配慮が不足している、要求・ニーズを満たすような仕様に展開できない、実現手段固有の性質に由来する望ましくない性質に対する考慮が不足している、などいろいろでした。

さらに、なぜこのような不備を引き起こすのか分析を続けました。私には固有技術についての知見が不足していますので、まずは固有技術の視点から設計不備になってしまう品質特性発現メカニズムを理解するために「相棒」の助けを借りました。

この分析の過程で、私は重大な知見を得ました。「その分野の技術の不足が原因で起きる不備はほとんどない」ということです。鉄という材料を使っていれば、ある条件で腐食します。片持ち軸の回転では、フリーの方で芯ブレが起きます。金属のプレスではスプリングバックが起きます。プラスチック成型ではある特徴をもったところにバリや引けができます。コーナーRが不適切だと応力集中によって亀裂ができます。構造が稚拙だと強度不足や無用な振動が発生します。このような不具合は、以前にも他の製品設計で何度も経験しているのです。それにもかかわらず、新規だとか独創性が必要とか言われると、「ちょっと待ってください。そんなことは前に経験しているではないですか。再発ですよ」と言いたくなります。

ここで「再発」の意味をめぐってメンツをかけた大激論が起きます。私は、設計・開発プロセスでの不具合事例について、管理・マネジメントの面で、どのような不備、脆弱性が原因(直接要因、間接要因、遠因、背景要因、誘因、…)となって問題が再発しているのかを明らかにしようとしたのです。

こうした分析を踏まえて、私は2つのことが必要だと説得しました。第一は、一回限りに見える仕事にも何らかの意味で繰り返しがあり、それを「管理」するために、繰り返し適用可能な優れたプロセスの確立です。第二は、再利用可能な設計知識の構造的可視化です。新規、独創性、ノウハウなどを理由に、個人の経験や技術力が決め手であると逃げることなく、ある程度のレベルの技術者が使える、適切なレベルで抽象化した、組織全体で使える設計知識ベースが必要だということです。

その後、少し時間がかかりましたが、第一の点については、優れた設計プロセスが有すべき性質を「設計・開発管理の原理」としてまとめました。これは、知的業務プロセスに内在すべき特徴と言ってもよいと思います。

第二の点については、顧客タイプ別(マーケットセグメント別)の要求・ニーズの構造、機能発現の構造と実現方法、設計仕様の構造化表現、生産技術要素などについての指針、ガイドの整備とともに、DR(Design Review、デザインレビュー)やFMEA(Failure Mode and Effect Analysis;故障モードと影響解析)の実効性を挙げる目的で、設計トラブルからの本質知抽出の方法論に取り組みました。

私にとっての「知的業務のプロセス管理」とは、こうした体系、すなわち価値変換・情報変換プロセスと、そのプロセスで用いる知識基盤を整備し、まともなアウトプットを産出できるようなプロセスの構築と運営を意味します。もちろん、このようなプロセスを人間が行う知的作業のすべてについて定義・構築できるとは思ってはいませんが、個人の資質にだけ頼るのでなく、組織全体が適用できる「組織知」としたいと考えています。

2. 設計・開発管理の原理

2.1 4つの原理

前章で「知的業務のプロセス管理」について2つのヒントを得たと申し上げました。本章ではこのうちの第一の点、すなわち、一回限りに見える業務に対して構築すべきプロセスについて、数百件の設計ミスの状況のマネジメントの側面からの脆弱さを裏返して得た「設計・開発管理の原理」についてご説明します。何回か修正を重ねましたが、1980年代初めまでに、私の頭の中には図表1に示すような思考形態が出来上がっていて、この種の問題の構造を理解しようとするときは、ごく自然に使っていました。個々の事例に適用する過程で多くの改良の余地があることに気づきましたが、まあそれも応用問題として適当に対応してきました。



図表1で示した原理は4つからなります。第一は、プロセスを定義すること、第二は、各単位プロセスにおいて、失敗しないようにすること、第三は、失敗を早く見つけること、第四は、失敗を鮮やかに解決することです。

まずは、たとえ1回限りの業務に見えてもそれを「管理」の対象にするということは、何らかの「継続性」があることを意味していますので、とにかく「プロセス」が定義されていなければならないと考え、これを第一の原理としました。次に、それら一連のプロセスを構成する単位プロセスにおいて、失敗しないような工夫をすることが重要と考え、これを第二の原理としました。さらに、そのように工夫していても失敗をする可能性があるので、早く見つける工夫が重要であり、これを第三の原理としました。加えて、見つけた失敗を適切に処理する工夫が必要で、これを第四の原理としました。

こう整理できてみると、論理的には自然に思えたし、またPDCAの観点から、[2]〜[4]の原理は、優れたPとD、適時的確なC、妥当なAと解釈することもできて、この枠組みは結構よい線を行っているのではないかと考えました。

2.2 [1] 設計・開発ステップの明確な定義

1回限りに見えても、何らかの繰り返しがありますので、一連の業務をモデル化して、どのような順序で何をするかというプロセスの流れを決めるのが得策です。そして、各プロセスの定義、すなわち、どのようなインプット(情報、もの、状態)から、どのような手順・方法で、どのようなアウトプット(情報、もの、状態)を得るかについて明確にしておく必要があります。さらに、それら業務機能的な側面ばかりでなく、これらの機能を果たす組織・担当、それらの組織要素間の協力やコミュニケーションのあり方についても明確にしておく必要があります。

2.3 [2] 質の高い効率的な業務の実施

前項[1]で定義された各プロセスにおいて、失敗をしないような工夫をして質の良い効率的な業務ができるような工夫をするということです。3つ挙げました。

その第一の秘訣は、「優れた計画」、すなわち、妥当な目的の設定と、その目的を達成する妥当な手段の特定に関わる工夫です。まず気になるのは「抜けの防止」ですが、マニュアル、指針などに、過去の業務例から抽出した適度に抽象化した知識が整理され、組織的に利用可能になっていることが必要です。

その上で「重点管理」が必要で、限られたリソースで業務を実施するときに最も重要な原理ではないかと思っています。一人で実施するときは、難しい業務・大切な業務を特定し重視すべきです。ふつうは業務全体の目的・目標を明確にし、それを達成するために必要なタスクを特定するでしょう。このとき、どのタスクが難しいか覚悟を決め、全体の工数見積もりをして、どこに力を注ぐか、どこで手を抜くか構想し、まずは難しい部分を何とかするのが良い方法と思っています。業務開始時に、そのようなラフな「プロジェクト計画」を書くような仕組みを構築しておくべきです。イマイチだなぁと思う方のやり方は、出来そうなところから手を付けて、時間が切迫しているなかで難しい業務に取り組むというスタイルです。

分担して実施するときは、一番忙しい人に、その人の優先順位を変えて、難しい仕事を割り当てるという工夫が必要です。「仕事の報酬は仕事」です。優秀な方は、仕事ができるから、カネや地位の代わりに、まずは次の難しい仕事が割り当てられるのです。優秀な方に比較的失敗が多いのは、巧みな組織運営の証ではないかと思うことさえあります。こうした組織運営が可能となるようにしておいて、有効な知識ベースを基盤に「予測と予防」を具現化できるプロセスを構築したいものです。

それほど重要でない業務をどうするかですが、これは「標準化」、すなわち、内外の過去の知見の活用、知識の再利用で乗り切るような仕組みと知識基盤の構築が良策と思います。高度に知的な業務であればあるほど「標準化」が武器になるということです。すでにどうすれば良いかほぼ分かっていることは、下手な工夫をすることなく、目的を達成できるのであれば、その次善・三善の策を採用し、難しい業務にリソースを集中すべきです。

そして、難しい業務を「もっと易しくできるようにする」工夫こそが重要と思っています。私は、「考慮事項の抜けの防止」、「関連性の正しい把握」、「妥当な判断」の3つが業務の難しさの代表と分析しました。いずれも、組織が共有する業務知識ベースとして整理しておくべきものです。

考慮すべき事項を抜けなく考慮するためには、その「視点」を木構造で展開した形で整理しておくべきでしょう。関連性とは、目的・手段関係、因果関係などを意味していますが、これらも木構造、あるいは二元表の形で整理しておくべきです。設計・開発で最も難しい関連性の把握とは、実は要求・ニーズと実現仕様の関係の把握です。このための工夫が、日本が1970年ごろに開発したQFD(品質機能展開)と言えます。妥当な判断も同様に、評価項目の構造の整理と、それぞれに対する評価の世間相場を整理しておくべきです。この3つは、結局はいずれも「関係性」の理解と言えそうで、私たちにとって難しい知的思考というものは「関係の理解」ではないだろうか、この難しさを克服する工夫を組織の業務プロセスに張り巡らすべきと考えています。

2.4 [3] 失敗の早期発見

まず、適切な段階での確認が必要です。設計・開発においては、古来より「試作」というプロセスがありました。これは設計通りのモノを現実に作って、設計の妥当性を評価するという機能を果たすものです。設計・開発の最終段階に実施していたのでは遅すぎることが多々ありますので、それより前の、材料、部品、ユニットなど適当な段階で評価をしたり、CAE(Computer Aided Engineering)を用いてモノを作らずに評価したり、あるいはDR(Design Review)など机上の検討・評価を行います。これらを、設計・開発の完成度の適切な段階で実施するということです。

次に、このような評価ステップにおいて、妥当な評価を行い、検出すべき不具合を的確に指摘することが重要となります。もっともらしい評価ステップが設けられているのに見逃してしまい、設計の不備を下流プロセスに流出させてしまった理由を分析してみました。「①評価項目抜け」、「②評価特性値不適」、「③評価条件不適」、「④サンプリング誤差」、「⑤計測誤差」、「⑥判定誤り」などいろいろでした。これらのなかで、頻度が多く重要なのが、①、③、⑥で、「評価項目の抜けの防止」、「使われ方を考慮した評価条件」、「合理的な判断基準」についての工夫が必要と分析しました。この3項目は、前項[2]の「難しい業務の容易化」で挙げた「考慮事項の抜けの防止」、「関連性の正しい把握」、「妥当な判断」と同根の難しさと考えています。

「評価項目の抜けの防止」のために、適度な抽象度でのチェックリストや評価の「視点」を準備します。「評価条件」について、私が設計プロセスに興味を持ったころ「使われ方」が一種の流行語であったことを思い出します。通常の使用・環境条件でまともに機能する製品を設計するのは当たり前で、その製品のライフサイクルの間に起こりうる使用・環境条件をどれだけ的確に想定しうるかが、一流の設計者かどうかを分けると言われていました。

「妥当な判断」とは、この程度の性能、頑健性があれば良いと適切に判断できるかどうかを問題にするものです。設計・開発者の価値基準、判断基準と、市場・顧客の判断基準の乖離を防がねばなりません。この問題を起こすと非常に悔しいものです。なぜなら、評価項目、評価特性、評価条件まで適切に設定していたのに、合否判断で誤ったことになるのですから。

こうしたことで上手の手から水が漏れることのないような工夫を、評価・確認プロセスに埋め込んでおくことが必要です。

2.5 [4] 失敗への迅速・適切な処置

見つけた失敗は、上手に対処しなければなりません。火に油を注ぐような対処をしてしまうことがありますが、そのようなことをできるだけ防ぐ工夫が必要となります。大きくは2つに分類できます。

第一は、「こんな失敗をするかもしれない」と、漠然とした覚悟を決めておくことです。ISO 9001や14001など附属書SLに従って規定されるISOのマネジメントシステム規格を通して、いまごろになって取沙汰されるようになった“Risk based thinking”(リスクベースの思考)や、30年ほど前に盛んに言われた「予測と予防」について少しだけ考えてみるということです。

「これをやったら、どんなことが起こるだろう」、「こんなことが起きるかもしれず、それはやっかいだ」、「そのときは、こうして難を避けよう」という程度のいい加減な覚悟を決めることで十分です。起こり得るすべてのことを予測しそのすべてに対して対応策を考えておく、なんてことまでは必要ないと思います。もちろん絶対に避けたいことはまともに検討しますが、細かいことまで考察していたら、それこそ「日暮れて道なお遠し」になってしまいます。

目的は、事件が起きたときにパニックにならないことです。あまりに落ち着いていると上司に叱られますので、一応は慌てたふりをしますが、内実は「う〜ん、やはり起きたか。それじゃあ仕方ない、次善の策で行くか」という具合です。これに近い考え方を採用している品質管理手法はPDPC法(Process Decision Program Chart; 過程決定計画図)です。学術会議議長も務めた近藤次郎先生考案の手法です。興味ある方はWebで調べてみて下さい。

第二は、いわゆる発生してしまった問題に対する適切な処置に必要な事項です。これらは、いわゆる科学的問題解決法の原理・原則そのままです。問題の大きさや重要性に応じて、適切に実施するための手順、手続き、方法を確立しておくべきです。問題解決については、いずれこの連載で触れます。

2.6 知的業務のプロセス管理

こうした考察を経れば、プロセス管理という考え方が、一般的な業務の質を管理する際にも使えることは明らかです。例えば、事務作業においてミスが発生したとき、チェックしろ、チェックを強化しろという方法もよいですが、ミスの原因、誘因、背景要因を明らかにしてプロセスを改善することによって発生率を減少させるほうが有効です。

そもそも何ごとにつけ因果関係を考えるのはある種の頭の良さで、その賢い方法を管理という目的達成行動において適用するとなると、手順、プロセス、業務インフラという、業務結果の原因系を制御することになり、それがプロセス管理にほかならないと言えます。

設計・開発などの知的業務は、いわゆる頭の良い人、出来る人が担当すればそれなりのレベルで遂行可能ですが、それでは組織全体の知的生産性が上がりません。いわゆるミスを個人の責任に帰しても問題の本質は解決しません。業務従事者が能力を発揮できるような、良いプロセス、良い知識ベースを構築したいものです。それが私にとっての知的業務のプロセス管理です。

3. 設計知識の構造的可視化

3.1 断片的知識の体系化

次に、1.2節で述べた、知的業務プロセスを支える知的基盤としての「再利用可能な設計知識の構造的可視化」について、私が試みたことをご紹介します。大きくは2つのことを考えました。第一は、個々人が保有する、言うに言われぬノウハウとか、ケース・バイ・ケースで考えるなどと適当にあしらわれることなく、目的達成の方法論が組織の標準類として体系的な知識として整理されている状況についてです。第二は、体系化しにくいと思われている断片的な知識を体系化する方法についての考察です。第二の体系化しにくい知識の体系化の話から始めます。

発端は、1.2節でご紹介した優秀な技術者との議論でした。その会社の全社的品質管理活動の一環として「設計責任トラブル」の分析をしていました。分析結果の一覧表の原因欄に並んでいたのは、「不注意」「技術不足」「使用条件不適」などで、挙句の果てに「不測の事態」とあるのです。このことをめぐって、その技術者とかなり激しい議論になりました。実はこの方は単なる頑迷な専門バカではなく、のちに設計知識の構造化を推し進め、最後は社長になります。

1.2節でご紹介しましたように、彼は、「設計は一品生産だから(製造で有効な)QCは使えない」と言います。管理とは「統制」、標準化とは「画一化」と誤解してのことです。私は、「起きている現象は同じ自然科学メカニズムに基づいているのだから、せめて個々の設計トラブルから、それを引き起こしている不具合メカニズムを解明しましょう」と説得しました。

そこで型通りに「設計トラブル事例集」を作り始めました。「m月d日顧客Cからクレームあり。p部品にX不具合発生。原因はZ部R指定不良。設計者の注意不足。……」という感じです。不具合事例の現象の記述や、最終的な設計変更事例は蓄積されましたが、あまり有効には使われませんでした。再利用性が低いからです。ほぼ同じような設計には反映できますが、それこそ一品生産ですから、同じ設計での製造には有効でしたが、類似設計への反映は限定的でした。問題を起こした当人は、むしろ忘れたいのに忘れられないくらいに事件をありありと覚えていますので、事例を残す必要はありません。同僚は「オレは(もっと賢いから)そんな間違いは起こさないぞ。このくそ忙しいのに、いちいち過去の事例を見ていらるか」となります。

そこで、過去の経験から得られる知見の再利用性を高めるために、検索できるようにしようということになりました。まだ大型計算機が全盛で、PCなどない、計算機の“高い”時代です。各事例にいくつかのキーワードを付して、参考にすべき事例を特定するチャチなソフトを作りました。しかし、ヒットする事例はカスばかりです。実に多くの事例がヒットしますが、どこをどう再利用してよいのか分かりません。

3.2 知識のABC構造

そこで私は、「ABC構造で行こう」と提案しました。「AがBのときCが起こる」という文法構造で、各事例を理解しようと言ったのです。ABCとは、「Aという性質を持っているものが、Bという条件にさらされると、Cという不具合モードが起きる」というものです。

それ以前のキーワードの与え方で問題と思ったのは、起きている不具合事象の発生メカニズムに関係のない特徴に気を取られることです。例えば、錆は、製品や部品、納入先顧客には関係なく、材料と使用環境条件によって起きたり起きなかったりします。そこで、「鉄は塩水で錆びる」と人を馬鹿にしたようなことを言いました。鉄がA、塩水がB、錆がCのつもりです。鉄とか塩水という表現は相当に乱暴ですが、ことの本質を伝えるには大した障害にはなりませんでした。鉄は、パイプだろうと、板だろうと何であろうと、塩水のような電位差が生じる中性でない液体が介在する環境におけば、何時間かで腐食が進みます。この事象を理解するうえでの本質は、鉄、塩水、錆であって、部品名とか、組み込まれる製品名とか、仕向け地そのものではないはず、と申し上げました。

ABC構造の最も重要な概念は「C」だろうと思います。不具合事象を適度に抽象化した形態分類、FMEAでいう「不具合モード」でとらえるということです。次に重要な概念は「A」だと思います。そのような不具合モードが「どこに」「どんな特徴を持つものに」起きるかを問題にします。そして、その不具合モードは「B」という厳しい条件、すなわち「どんなときに」「どんな関係が成り立つときに」起きるか、と理解しようとするものです。

このときから長い年月を経て、私の研究室に田村泰彦という学生がやってきて博士課程に進学します。こともあろうに、この超難しいテーマを選択しました。土曜は、彼とのデスマッチ議論という甘美の時間になりました。しつこい彼は容易なことでは納得しません。挙句の果てに、「ABC構造は間違っています。ストレス-ストレングスモデル(Stress-Strength-Model;SSM)がいいです」と言ってきます。SSMとは、不具合事象を、「定義属性」で規定され、「制御属性」で作り込まれる「ストレングス」を超える「ストレス」が課されると、「不具合モード」が起きる、と捉えることのできる事象の連鎖で起きる、と理解すべきだという理論です。

難しいテーマであるにもかかわらず、彼は順調に学位を取得し、私の研究室の助手を2年勤め、その後自らこの方法論の発展のために起業しました。彼の会社「構造化知識研究所」のホームページ(https://www.ssm.co.jp/)に、この方法について相当な量の紹介がありますので、ご参照下さい。相当に深くかつ広いです。全貌を理解するのはなかなか大変ですが、取り組んでみる価値は十分にあると思います。私は、その出藍の誉れの典型ともいえる弟子のセミナーの前座を務めるという至福のときをしばらく味わいました。

彼はのちに、SSMはABC構造とも言える、と先生思いの優しいことを言います。すなわち、

A: 「定義属性」で規定され
B: 「制御属性」で作り込まれる「ストレングス」を超える「ストレス」が課されると
C: 「不具合モード」が起きる

という具合です。

Cという不具合事象の発生メカニズムの理解において、「定義属性」という概念、私が言い出した「A」にあたる部分は、重要と思います。その不具合は、その部品だから起きるわけではない、と言いたいのです。「そういう性質を持っているからこそ、その不具合が起きる」と言えるような属性が何であるかを認識することが、トラブル予測において極めて重要であるし、起こしてしまった失敗から学ぶべきことではないかと思うのです。実際、いわゆる頭のよい、センスの良い人は、「○○には××が起こるものだ。それはかくかくしかじかのメカニズムで」という知識をもって、予測を行っているに違いありません。

こうして構造化できた知識が美しい体系をもっているなら、それは組織の知識データベースになったり、もっと一般的であるなら教科書にもなります。あるいは、手順に組み込まれ、こうした知識を基盤としていることをあまり意識せずに、優れた方法で業務を遂行することができるようになります。

3.3 知の体系化

この連載の第6回(9月号)で、「技術とマネジメント」という主題をとりあげました。そのとき、質の良い効率的な業務を遂行するためには、その分野に固有の技術とともに、それらの技術を活かすマネジメントが必要と申し上げました。マネジメントシステムのレベルは、そこに埋め込まれている固有技術のレベル以上にはなれず、固有技術の可視化・構造化・標準化のレベルに依存してしまいます。知的業務のプロセス管理のためには、その業務の分野にふさわしい構造での知の体系化が必要ということです。

私は「組織知の体系」は、以下のような要素によって実現できると考えています。

• 知識化:視点・観点、項目・特性、根拠・理由、原因・要因・誘因、目的達成手段、リスク、対応策、……
• 可視化:適度な抽象化・一般化、形式知、例示
• 構造化:表現(系統図、表、関連図)、関係(因果、目的・手段)
• 標準化:最適化、推奨・規定、選択肢、共有

第一に、とにかく個別断片的な知見を「知識化」する必要があります。ここで重要なのは抽象化、一般化能力でしょう。頭の良い人は、これをごく自然に行います。人から聞いた話から本質を抽出し、将来自分が使える知識に昇華します。教科書に書いてある一見無機的な体系的知識を、自分が担当する分野に使えるように、本質を維持したまま適度に具体化します。組織の個別断片的な経験から得られる知見を、ある文法構造で再利用可能な知識にします。

第二は可視化です。獲得できた知識を組織共有にするには「見える化」が必要です。個人を超えて伝承可能な知識にします。もちろん、それが完全にはできない知識もあります。自転車の乗り方がよい例ではないでしょうか。バランスをとるために、バランスが崩れるときはどのようなときで、そのときどうすればよいかアタマでは分かりますが、カラダが飲み込むのにもう一歩必要です。それでも、ただむやみに経験させるだけではない教育訓練法というものがありえて、現実的に可能な範囲での見せ方が、ここで言っている可視化です。

第三は構造化です。前節3.2で、ともすると断片的知識、個人のノウハウと片付けられてしまいそうな知識が持つ文法構造として、ABC構造をご紹介しました。構造化の目的は、再利用可能性の向上です。獲得した知識の再利用性を高めるためにABC構造のようなものを考えましたが、もっと整理されていれば図とか表とかの関係図で表現可能と思われます。この種の工夫をすることによって、有益な知識を組織共有の「組織知」とすることができるでしょう。

第四は標準化です。ここでの標準化は、統制とか画一化とかいう意味ではなく、現在の技術水準に照らして推奨できる内容(the state of the arts)を可視化して組織的に利用可能にすること(最適化、共有化)です。この内容が、手続き、手順に埋め込まれていたり、あるいは手順のある段階で参照する知識ベースに具現化されていることを期待しています。

3.4 知的業務プロセスにおける標準化

こう考えてくると、考慮の行き届いた計画・設計、新規性・独創性が要求される知的業務における標準化の重要性が再認識できると思います。標準化については、次月号で考察しますが、良いこと正しいことの組織的適用手段であり、また改善の基盤、独創性の基盤でもあります。

2.1節で、優れた設計・開発プロセスの要件を挙げました。そこで示した図表1を再掲し、いつくかの項目に2種類のハイライトをします。(図表2)



図表2の黄色は「標準化」すること自体が重要、水色は「標準の内容の工夫」が重要という意味です。もちろん、それぞれを明確に分けられるわけではありませんが、設計・開発プロセスに代表される知的業務プロセスにおいて、手順・規則などを決めておくこと自体(標準化)と、その標準の内容に「組織知」が巧みに内在していること(標準の内容の工夫)が肝要であると言いたいのです。だから、私は、マネジメントシステムのレベルはその組織が有している固有技術のレベルを超えることはできないと申し上げました。いわゆるマネジメントを否定し、個人の突出した力量のみに頼るのであれば、ここで申し上げていることは忘れていただいて結構です。でも、そのような天才的な人がどのくらいいるか、そして彼ら彼女らだけで組織目的を達成できるものかどうか考えてみれば、遠回りと言われようとここまで述べてきたような、優れた知識ベースを基盤とする知的業務プロセスの構築が王道であるとご理解いただけるものと思います。

3.5 設計・開発における多様な標準

設計・開発に代表される知的業務、もしくは企画・計画業務における「標準化」とは、標準化の意義や目的に照らすと相当広い範囲まで考えてよいと思います。私は、設計・開発における「標準化」は、以下のようなことまでカバーすると考えています。

• 商品開発手続き
• 設計・開発方法
• 設計標準、設計マニュアル、工作標準、製図方法、検図要領、……
• 設計対象に関する標準
• 標準部品・材料、標準レシピ、標準設計、設計基準、……
• 試験方法に関する標準
• CAD/CAM
• シミュレーション、○○解析、……

それは、業務手続き、技術的根拠のある方法、いわゆる設計標準、設計対象となる部品、ユニットなどが備えるべき特性に関する標準、その具体的な部品・材料などの仕様、評価方法に関する標準、CAD/CAMの活用に関する標準、シミュレーションの方法に関する標準、特性・性能解析に関わる標準など多岐にわたります。要するに、要求・ニーズを満たす実現仕様を確定する行為に関して、良いといことが分かっているモノや方法を推奨・規定したものです。いずれも設計・開発を支援するものです。実は、設計の本質を考慮すると、設計・開発支援として、ここに挙げたものより、重要なものがあると考えています。

3.6 設計業務・計画業務の本質

設計とは「要求を実現する手段の指定」と定義できると思います。飲料を入れ持ち運びできる容器が欲しいと言われれば、まずは液体の性質と容量を確認したうえで、材質、大きさ、形状、ふた(密閉方法)などをどうするか考えるでしょう。要求・ニーズを満たすように、仕様を決めるわけです。設計に限らず、計画についても同様の側面があります。PDCAの話のときに(連載第7回参照)、計画は2つの行為から成り立っていて、それは「P1:目的の設定」と「P2:目的達成手段の策定」だと申し上げました。P2の方は、目的達成のための「設計」を意味していると言ってもよいでしょう。

この世には多くの「設計支援システム」なるものがあります。その一つは、目的達成手段に関わる情報、例えば、過去の設計例、標準部品・材料、標準レシピ、標準設計、設計基準などの提示です。また、設計行為の支援としてのシミュレーション・設計計算の実行などもあります。それらは、設計要素に関わる基礎データや定量的関係の積み上げによる計算、シミュレーションであったり、設計対象のモデル化による中間特性(抽象化・一般化特性)を用いた特性間の関係の表現というようなものもあります。

ときには、「自動設計システム」なんていう名称のアプリケーションもあります。その基本は、複数の設計パラメータと複数の目的特性との間の定量的関係を基礎に、複数の目的特性を同時に所定の範囲に収めるための複数のパラメータ値の指定です。

でも、設計において本当に検討したいことはそんなことではないはずです。与えられた設計パラメータについてその値をどう決めるかではなく、どのような設計パラメータについてその値を指定すればよいかを知ることの方が重要です。このようなことが起きるのは、設計が「逆問題解析」だからです。

設計とは「要求を満たす手段の指定」ですから、設計解は要求を満たす手段のうちの一つに過ぎません。様々な実現手段を候補に挙げて、それらから最適解を選択しています。最適解であるために、もちろん要求を満たすという点において最適であることを考えますが、他にも考えなければならないことがあります。設計解の候補は、要求を満たすものとなっていなければなりませんが、意図しない(望ましくない、あるいは期待以上の)特性や属性が備わっていることにも留意しなければなりません。

私がこの話題で講演をするとき、例として講演卓を挙げています。目に入った手近なものだからです。講演卓に対する要求としては、ある重量のある大きさのもの、例えばマイク、水、PC、テキスト、時計、ポインターなどを置くことや、私の短足を隠すことなどがあります。これらの要求を満たすような強度、寸法、形状の卓を設計することになります。材料として、木材、樹脂、鉄、紙やこれらの組合せが考えられます。例えば、鉄を選ぶと重さが気になりますし錆も気になるでしょう。紙だと強度を得るために工夫するでしょう。燃えるようなことが起こるだろうかと考えるかもしれません。要は、要求を満たすことはできても、その実現手段に固有の性質の影響を考えなければならない、ということです。

この意味で、設計における「妥当性評価」は、設計プロセスにおける本質的行為と思います。DRや、トラブル予測のためのFMEAなどは、単なる設計の不完全さを補う方法などではなく、むしろ実現手段に固有の性質の影響の検討を通した、広い考慮を払った設計をするために必須のプロセスを実行する有効な方法論と考えられます。

すなわち、設計における妥当性評価においては、「設計対象に与えられる制約条件のもとで、目的の機能、性能を満足させることができるか」の検討とともに、「設計対象が具備する様々な特性、属性によって、望ましくない状態・現象が発生しないか」を検討することが重要で、むしろ後者のために実施していると言っても過言ではありません。

3.7 予測的試行錯誤法としてのFMEA

私は、信頼性工学においてFMEA/FTAと並び称される2つの手法のうち、FMEAの方が圧倒的に好きですし、遥かに有用であると考えています。FMEAは人の思考様式にあっていると思うのです。正しいものを、過不足なく、手戻りなしで案出することは難しいことです。しかしながら、案があれば巧みな批判をすることはそれほど難しくはありません。本当に創造的な人というのはまずいません。

FMEAの本質は「予測的試行錯誤法」にあると思っています。検討に値するそれなりのレベルの設計案があります。その案に何か問題はないか思考実験(問題は起きそうか、その問題の影響は大きいか)をします。問題があると判断したら、設計を見直します。まだモノは作っていません。机上で、頭の中でシミュレーションしているだけです。それで、試行錯誤法には違いないのですが、予測的だと名付けました。

効果的なFMEAのためには、的確に予測しなければなりません。妥当な故障モードを想起しなければならないということです。その故障モードの重要性を評価するためには、故障モードに端を発する事象の影響連鎖と、その故障モードの発生頻度を的確に推定するための故障モードの発生メカニズムの理解が必要となります。

FMEAの有効活用の検討はそれ自体が非常に興味深い主題なのですが、ここでは「故障モード」の意義にだけ触れておきます。「故障モード」という概念は実に巧みだと思います。定義するのは難しいのですが、実用的には「不具合現象を抽象化・一般化した用語・概念」と言えるでしょう。故障の形態分類です。部品で言えば、変形、亀裂、折損、腐食など、システムでは、ちょっと冴えないのですが、停止、動作せず、異常出力などです。設計中の製品・システムに潜む不具合の予測のための、「当該製品・システムに発生するかもしれない不具合を具体的に連想させる、不具合現象を抽象化・一般化して表現した用語」とでも言えそうです。

故障モードに関して私が感銘を受けるのは、適用者が認識しておかねばならない、その種類、数です。故障モードは、不具合現象の最終的結果でも根本的原因でもありません。不具合事象の連鎖において、適当な中間段階で適度な抽象レベルでとらえた不具合現象の形態分類です。故障モードとして、比較的少数を考えておけば済むのです。不具合事象はいろいろあって、千差万別、ケース・バイ・ケースと思いがちですが、変形、折損、疲労破壊、腐食などのレベルで理解しておけば、どんなに複雑で多様な事象が起きると言われるような分野でも、故障モードの種類は数百で、それらの連鎖として理解できます。

私がABC構造と言い、田村泰彦さんがSSMで整理すると言っている背景には、過去の失敗事例から学ぶべき技術は、不具合現象を一般化・抽象化して表した用語・概念と、不具合が発生するに至る物理的・化学的なメカニズムであるとの考えがあり、FMEAの有効性を極める心と同じ線上にあります。

問題

[1] 図表1にしたがって、あなたの組織の設計、または何らかの計画プロセスをレビューしてみて下さい。とくに、[2]の原理(質の高い効率的な業務)が、どのようなプロセス、システム要素に組み込まれているか、あるいは組み込まれるべきか考察して下さい。

[2] 図表2にしたがって、あなたの組織の設計、または何らかの計画プロセスに関わる標準の内容をレビューしてみて下さい。とくに、[3]の原理(失敗の早期発見)が、どのような標準類(手順、マニュアル、指針、チェックリスト、技術標準など)に反映されているか、あるいは反映されているべきか考察して下さい。

[3] あなたの組織に備わっている過去の知見の集積(過去トラ、技術の棚、知識データベースなど)について、それらが適度に抽象化・一般化された知識になっているかレビューしてみて下さい。その上で、データdata⇒情報information(意味のあるデータ)⇒知識knowledge(有用な情報・判断の体系)⇒知恵wisdom(知識を活用できる英知)のどのレベルであるか考察して下さい。