クラウドを使った解決策

今回は「ザ・ゴール2」から

P5~P49を読みました。
今回は、この章に出てくる2つのツール
(1)クラウド
(2)ネガティブブランチ
について、考えてみました。
上記2つに
(3)I/Oマップ
を加えて思考プロセスの3つのツールとなるようです。
このI/Oマップについてはまた後の章で出てくるようです。
さて、今回の章の中では
主人公のアレックスと娘のシャロンとのやりとりが題材として描かれています。
シャロンが週末の土曜日の夜にパーティーに招待されたのですが、帰宅時間が12時になるとの事。
アレックスはこれを許しません。
10時までに帰宅するならば良いという条件を出します。
しかしこの条件にはシャロンが納得しません。
シャロンは泣きながら自分の部屋に戻っていきます。
そこで、アレックスはジョナ博士から教わった交渉テクニックを使ってみる事にします。
ジョナが示したガイドラインは次のとおりです。
(1)「適切な妥協案が見いだせないような交渉状況に陥ったら、すぐに対話を中止しなさい。これが最初のステップである。」
(2)「いかに交渉が感情的になっても、相手を責めるのではなく、適切な妥協案を見いだせない対立状況にお互いとらわれてしまったことが問題なのだという事を認めなければならない。」
(3)「正確に「雲=(クラウド)」(対立解消図)を書く。」
そこでアレックスは3番目のステップをためしてみることにします。
書きだしたクラウドは次のようなものでした。
IMGP5679-1.jpg

「10時までに帰宅」と
「12時までに帰宅」
という2つの行動が対立しています。
最終的にはこの2つの対立している理由を考え、それに対する解決策を見つければ良いのです。

それぞれの行動に対しては理由があります。(ニーズと呼びます)

「10時までに帰宅」のニーズは「安全のため」
「12時までに帰宅」のニーズは「仲間はずれにされないため」
です。
さらに、それら2つには「共通の目標」があります。
一番左の「健全な家族生活を営むため」です。
本当の両者の目的はこれなのです。
ここまでは書籍に書いてあるとおりです。
私達はやったことはまず、
「ニーズ」が満たされない理由をそれぞれ3つづつ考える事から始めました。
まず、
1. 「10時までに帰宅」のニーズが満たされない理由は、
  (1)10時までに帰宅できないと、自力で帰宅できる交通手段がなくなるから。(バス等)
  (2)10時までに帰宅できないと、犯罪等に巻き込まれる可能性があるから。
  (3)10時までに帰宅できないと、家族と連絡が取れなくなるから。

2. 「12時に帰宅」のニーズが満たされない理由は、
  (1)12時に帰宅しないと、パーティーを中座する事になり、場をしらけさせてしまうから。
  (2)12時に帰宅しないと、帰った後悪口を言われそうだから。
  (3)12時に帰宅しないと、次から誘われなくなりそうだから。

このような理由を考えました。
この場合、「12時に帰宅」の理由は単なる思い込みなのですが、そこはまだ年端もいかない子どもの事、仕方がありません。
そもそも大人ならばこんな対立はほぼ存在しないでしょう。
アレックスのニーズを考えてみました。
1. 「10時までに帰宅」のニーズを満たすためにはどうやら、
「夜間に安全に帰宅する手段」があれば良い、という事ではないでしょうか。
そこで、上記図の対立の横に、
(理由)
「夜間に安全に帰宅する手段がわからない」
と書き込みました。
これを解決する方法があれば、対立が解消されるはずです。
それならば、
●「アレックスが12時に車で迎えに行く」という【解決策】はどうでしょうか。
これならば、
「安全のため」というニーズと、
「仲間はずれにされないため」というニーズが両方満たされると思います。
これでクラウドを使って対立の解決策が見つかりました。
私なりに思うのは、ほとんどの経験ある大人はすぐに解決策がわかってしまうために、
ここまで順を追って理論的に考えるという事をしないと思うのです。
すぐに解決策を見つけてしまう人も多いでしょう。
それ故に、対立が起こりやすくなるとも言えますし、
また、重大な何かを見落としてしまう可能性もあります。
ごくごく簡単なものでも一度クラウドを使って、理論的に確かめてから実行に移すという事は
大事な事なのかもしれません。
もちろん、このツールを充分活用できるスキルをまずは習得しなければなりません。
そのためには数多くの事例を解いていくという訓練が必要なのかもしれません。
IMGP5679.jpg

bousicom

ローカルパフォーマンスの評価尺度

いよいよ今回でこの本も最後となりました。

「PART4 インフォメーション・システムを構築する/訳者あとがき/解説 」(p219~p254)です。
これは、各部門や部署に対するパフォーマンスの評価尺度をいかにつくり上げるかという話でした。
会社全体の利益につながるような行動を取るよう、動機付けできる評価尺度を策定するのです。
何のために策定するのかというと、
「企業にとってのいちばんの力は、人の直感です。この直感を最大限活かすには、彼らのパフォーマンスを適切に評価できる尺度がどうしても必要なのです。ローカルパフォーマンスを能率や差異ばかりで評価していては、社員は期待通りの働きをしてくれません。逆にまったく正反対の行動をとってしまうのです。」(P279)
すなわち策定される側にとっては、
「どのような尺度で私を評価するのか教えてくれれば、どのように私が行動するのか教えてあげましょう」(P220)
という事になります。このような評価尺度を見つけなさいという事です。
ゴールドラット氏はこのパフォーマンス評価を「コントロール」と呼ぶ事にためらいがないと言っています。
ここでいう”コントロール”という事はどういう事なのでしょうか。
それは「”どこで物事が起こるべきか”(計画)に対し、”どこで物事が起こっているのか”(実際)を知り、逸脱があった場合、その原因を究明する事なのです。」(P220)と述べられています。
さて、それでは実際にはどういった感じで評価していったらいいのでしょうか。
前述の「逸脱」の実際の例としては
「納期通りに製品を納入しない事」があげられます。
この評価尺度の適切なものとして、
(1)「納期までに納入できなかった注文の販売額」
(2)「納入が遅れた日数」
この2つを掛け合わせて考えなければならないとあります。
(この評価単位を「ダラー・デイズ」とします。)
たとえ、部品1個だけが遅れている部門としても、
会社としての損失はこの「納期までに納入できなかった注文の販売額」に他なりません。
決して部門ごとに折半・分配するものではないのです。
しかし、何らかの形で部門毎に適正な評価をしなければなりません。
そこで、各部門が次の部門に仕事を引き渡すまでの日数で考えるとどうでしょうか。
これならば各部門は”ペナルティ”を課せられまいとあらゆる手段をつくしてできる限り迅速に仕事を次の部署に引き継ごうとするはずです。
この評価を用いると自然と作業が迅速化されていくのです。
しかしながら、この評価方法は1つだけ問題点があります。
それは、次の部署にできるだけ早く仕事を回そうとするあまり、中途半端でいい加減な仕事になってしまいはしないかという心配です。
(実際にはおそらくそうなってしまうと思います。)
そこで、別途「品質管理部門」を作り、まずこの「品質管理部門」にすべてのペナルティを課すのです。
「品質管理部門」はペナルティの全部を受け取ったら、原因を作った部署をみつけて、この「ダラーデイズ」をその部署に割り当て直せばいいのです。
原因が突き止められなかった分は「品質管理部門」の責任となりますが、
これも「品質管理部門」にとっていい反省材料となり、仕事を遂行する上でのいい動機づけになるという発想です。
つまりTQMが提唱している「品質は担当部門で作り込め」のまさに実践となるのです。
   ※TQM=下記参照
読書会を進めていただいた谷口さんの言葉をお借りしますと、
「多くの会社では、品質管理部門は「儲ける」ということをほとんど考えることなく仕事を
しているのではないかと思います。
しかし博士の考えたローカルパフォーマンス評価の仕組みの下では、品質管理部門も例外なく
気がつけば「儲ける」ことに貢献してしまうように設計されています。
まさに全体最適です。」
すべてをうまくまとめてご説明いただきました。谷口さん、ありがとうございました。
次の章は、
「What If」を引き出すためにすべての「インフォメーション」があるという話でした。
そもそもインフォメーションは何のためにあるのか、といえば、「What If」に答えるためです。
そのためにインフォメーションシステムを構築していくのです。
あいにくここの章はまだ私には良く理解ができていませんのでまたじっくりと考えてみたいと思います。
さて、これでこの本も終わりとなりましたが、
実は原文ではこの後約100ページほど続きがあるそうです。
英語力には自信がないのですが、
Amazonで原書を取り寄せてみました。
電子化・OCRでテキスト化し、自動翻訳のサービスを使って、少しづつ読んで行ってみようかと思います。

bousicom