パフォーマンス問題へのシステムズ・アプローチ

なんだかこのところ、納期遅れのクレームが増えている。営業部門から問題提起があったので、工場で原因を調べることになった。製造部や品質管理部、資材購買、生産技術など各部門からキーパーソンを集めて、対策チームを作り、まずは現状分析をはじめた。グラフを作って調べてみると、納期遵守率が落ちてきていることが数字の上でも明白だ。たしかにこれは、何らかの対策を打たねば、客先からの信頼度、ひいては受注競争力の低下につながりかねない。

そこで、最近の納期遅延事例を、それなりの件数とりあげて、原因分析をしてみた。また、メンバーも自分の気づいた経験を共有してみる。その結果、20以上の原因があがってきた。いわく、長納期部品の仕入れが遅れた、出荷前検査で不良が見つかり加工段階から削り直しになった、鋳物材料に欠陥が見つかった、設計の不具合が顧客の承認図レビューで分かった、ツールの不具合で余計に製造時間がかかった、云々・・。

検討チームは原因のリストを見て、腕組みをしてしまった。どこかの工程に問題が集中しているのではないか、という事前の期待があったのだが、当てが外れてしまったのだ。それならば対策も取り組みやすかっただろう。もちろん、リスト上の個々の問題事象に対して、対策を考えることは可能である。しかし、どれから手をつけたらいいのだろうか? 中には二つ以上の要因が複合的に作用して、納期遅れを引き起こしたものもある。たしかに、工場には何か問題があるらしい。だが、何がわるいのかよく分からないのだ。

——この例のように、個別事象はいろいろあるが、何となく全体として仕事の成果が落ちている問題を、『パフォーマンス問題』とよぶ。世の中に問題と呼ばれるものはいろいろある。学校の試験で問われる問題もその一つだ。だが、ビジネス上で出会う問題は、大きく、技術的問題とパフォーマンス問題に大別される。

個別の案件で発生するトラブルのほとんどは技術的問題だ。問題構造が明確で、原因は(きちんと時間さえかければ)分析できる。対策も(すぐできるかどうかはともかくとして)明確である。「技術」と書いたが、これは理工系の技術だけを指しているのではない。たとえば法的なトラブルなども、一種の技術的問題である。

ところが、パフォーマンス問題は少し性格が違っている。これは、コストだとか品質だとか納期だとか、いわゆるビジネス上の業績(パフォーマンス)低下にまつわる問題である。技術的問題は具体的なトラブルとして、目の前に突きつけられる。しかし、パフォーマンスの尺度は、ある期間の平均値として測られるため、その問題に気づきにくいという特徴がある。気がつくとじつはかなり深刻だった、というのもパフォーマンス問題の特徴である。

そして何より、「悪構造の問題」である点に特徴がある。つまり、問題の構造や原因が錯綜していて、分かりにくいのだ。

ある意味、個別の技術的問題が積み上がって、パフォーマンス問題を生じさせているといってもいい。だが、個別の問題をモグラたたきのように対応しているうちに、そのことにリソースや時間を取られて、目の行き届かない別の場所にまた似たようなパフォーマンス問題が発生したりする。たちがわるいのだ。

洞察力のある読者にはお分かりの通り、パフォーマンス問題というのは、システムが歪んでいるが故に生じる問題である。だから、個別のモグラたたきだけでは解決しない。システム全体の歪みを正す必要があるのだ。いわば、傾いた土台の上に立っている建物か、シャーシが傾いた自動車のようなものだ。

ちなみに工場というのは、需要情報を得て、製品という物的な形に付加価値を具現化するためのシステム=生産システムである。工場のパフォーマンス問題は、生産システムの歪みを示している。(ついでにいうと、プロジェクトというのはActivityを組み合わせて成果物という価値を生み出す、時限的なシステムである)。

さて、システムの歪みを見るためには、マクロな視点から業務プロセスを理解する必要がある。プロセスはどんな要素から成り立っているか、その各要素がどう機能しているか、それを左右する主な要因は何か。システムの歪みは、能力と負荷のアンバランスから生じていることが多い。したがって定量的な検討が不可避である。また、システムを制御するための基準尺度、つまり個別の判断のためのモノサシが、システム全体に求められる機能からズレている場合にも、歪みが生じやすい。この場合、いわゆるKPIや権限範囲を見直す必要がある。

ところで、かの工場の検討チームだが、こうしたシステムズ・アプローチに詳しいメンバーは、残念ながらいなかったらしい。まあ、よくある話である。こういうとき、誰か声の大きい人間が一人いて、一つか二つだけの「分かりやすい根本原因」を名指しして、それを解決しに走るケースも、ありがちでだ。たとえば「そもそも皆の根性がたるんでる! まずは意識改革運動が必要だ!」といった類いの『対策』である。

しかしまあ、この工場では皆がそれなりに知恵を絞って、問題事象を大きく5つのカテゴリーに集約し、対策のアクションを考えた。パフォーマンス問題はシステム全体のきしみなので、一般に複数の対策案が出てくることが多い。

A 長納期部品の遅れ → 受注前の先行手配
B 製造能力不足 → 焼鈍蔵置の増強
C 不良による再製作 → 組立前部品検査の徹底
D 材料の欠品 → 一部材料の常備品化
E 不正確な納期回答 → 工場負荷状況の可視化システム

ここまで来たときに、議論が紛糾した。この5つの対策のすべてをやっている余裕は、人員的にも時間的にも、ない。それでは、どれを優先すべきか。それぞれ自分の部門に近い問題を、まず解決したいと考えた。当然の成り行きだろう。

こういうときには、「費用対効果マトリクス」を作ってみるのが有効なテクニックである。まず、洗い出した改善アクションそれぞれについて、「実現に要するコスト・労力」と、「パフォーマンスの改善効果」について、評価してみる。そして、それを二つの軸にした平面にプロットしてみるのである。こうすると、それぞれのアクションの費用と効果の関係が一目瞭然となる。

ただしこの時点では、コストについて正確な見積は難しいし、改善効果は定量的推定がもっとできにくいだろう。だから、大・中・小の3ランク程度に、主観的に分類する程度でもいい。複数部門のキーパーソンが集まって評価すれば、これでもそれなりのランクに収まるものである。なお、「A 長納期部品の遅れ」対策として「受注前に先行手配する」というやり方は、コストとしては(結局は同じものを発注するのだから)ゼロになるように見える。しかし、受注前に先行発注してしまうのだから、客先から注文をキャンセルされたら不良在庫になるリスクがあり、まったくタダという訳ではない。だからこそ、横軸は「コスト・リスク」になっているのである。
e0058447_00045122.jpg

実を言うとこの二軸のマトリクスは、前回「見えない非効率 ー 今、動いているんだからいいじゃないか」で描いた図と同じチャートである。変化への抵抗を説明するために、この図を流用したのである。

さて、こうして出来上がったマトリクスの四角形の中では、当然ながら左上にあるもの、すなわち費用が小さくて効果が大きいものの優先順位が高くなる。まあ通例、それほど多くはないが。逆に右下の、費用が大きく効果の小さいものは、とうぜん低い優先度しかえられない。

では、右上の「費用も大だが効果も大」と、左下の「費用も小で効果も小」の、どちらを優先すべきなのか? 第三者の経営コンサルタントなら、右上をきっとおすすめするだろう。一方、当事者としては予算がかからず手をつけやすい左下領域を優先したくなる。

もちろん、手をつけやすい方から優先してかまわないのである。ただし、その中から順番を選ぶときには、右上の対策を頭に置いて、取捨選択するようにすべきである。なぜなら、右上の対策とは、システム全体に及ぶ対処法である可能性が高いからだ。そして、将来そのような対策がなされたとき、左下のアクションの中には、逆に無用になってしまうものがあるからだ。

たとえば上の例でいうと、「E 工場負荷状況の可視化システム」というのは右上にあり、実現はたいへんそうだが効果も大きいと考えられる。すなわちこの企業においては現在、工場の負荷を考えずに、営業部門が固定納期で客先にオファーしている、という習慣があるのだろう。ということは、もしかすると、このような習慣自体が、システムを歪めている大きな一因なのかもしれないのだ。だとしたら、本来目指すべきなのは、正確な納期回答であって、それが実現できるならば、「A 受注前の部品先行発注」といったリスクの高いことをする必要はなくなる(無論、正確な納期回答をしても受注競争力に大きく影響しないのならば、という条件がつくが)。

このように、改善アクションの優先順位付けは、マトリクスで視覚化するのが、一つのテクニックである。こうすると、特定の「声の大きい」人の意見だけを通しにくくなる。それだけでなく、アクションの配置をよく見ることで、問題の根本構造が見えてくることもあるのである。

なお念のために書いておくが、上に述べた工場のケースは、架空の事例である。わたしが実際に経験したいくつかの事例を元に、作り上げた話だが、フィクションであっても本質は伝わると思う。似たような問題事象はどこにでもあるからだ。それこそ小はオフィスのチームから、大は長らく不況に苦しむ日本経済まで、考えてみるべきフィールドはたくさん見つけられるのである。


<関連エントリ>
 →「見えない非効率 ー 今、動いているんだからいいじゃないか」(216-11-13)http://brevis.exblog.jp/24909011/

by Tomoichi_Sato | 2016-11-21 00:09 | Comments(0)
<< なぜ、製造業のIT化が進まない... 見えない非効率 ー 今、動いて... >>