- URL: ザ・ゴール2思考プロセス
- 著者: エリヤフ・ゴールドラット 著 / 三本木亮 訳 / 稲垣公夫 解説
- 公開日: 2002-02-23
いつ読むか？
- 思考プロセスを適用している具体的なシーンを思い浮かべたいとき
- 対立を解消したい時
- ネガティブブランチを相手と共有したいとき
- 企業の目的を思い出したいとき
読書メモ
対立したときのふるまい
p. 21
「適切な妥協案が見出せないような交渉状態に陥ったら、すぐに対話を中止しなさい。これが最初のステップだ」
p. 22
いかに交渉が感情的になっても、相手を責めるのではなく、適切な妥協案を見出せない対立状況にお互いとらわれてしまったことが問題なのだということを認めなければいけない。
正確に <雲> (対立解消図) を書く
雲の書き方
- まずはコンフリクトしている条件を書き出す
- 次にその条件の理由を書き出す
- 最後に理由の目的を書き出す
- これは交渉相手と共有できるものである必要がある
p. 27
どう違うのか私には理解できないが、ここはジョナのガイドラインを思い起こして、彼女と議論するのはやめておこう。『人気者でいるため』を消して『仲間外れにされないため』と書き直し、「これでいいかい」とシャロンに確認した。
相手の理由 (および条件) には反論せず受け入れる。
p. 40
「ええ、そのようですね。コンフリクトに直面した時は、妥協して問題を回避してはいけない。副社長が教えてくれたことです。」
ネガティブ・ブランチ (Negative Branch)
p. 59
<ネガティブ・ブランチ> (Negative Branch)
参考: https://www.goldratt.co.jp/toc-dictionary/nbr
NBRとは
TOC（制約理論）の思考プロセスで使われる概念です。問題解決などの提案を実行したときに起こりうる悪影響、つまり「懸念」を指します。
目的
提案を実行する前に、起こりうる問題やリスクを洗い出して手を打っておくことです。これにより、計画段階から提案をより堅実なものにできます。
進め方
- 提案の実行と、そこから生じうる望ましくない結果との因果関係を検証する。
- その懸念を言語化する。これで変化の影響を深く理解でき、よりよい意思決定につながる。
- 望ましくない結果が起きないように提案を修正し、副作用を未然に防ぐ。
効果
NBRを検証することで、戦略の練り直しや不測の事態への備えができ、TOCのソリューションの効果を最大化できる、とされています。
ひとことで言えば、「良いアイデアにも副作用がある前提で、その因果を論理的に詰めて先回りで潰す」ための手法です。
ネガティブランチを相手と共有する
p. 90
「ただリストを読み上げるだけじゃ駄目だ。<論理ツリー> なんだから、矢印の順に『もしこれならば、なになにだ』っていう、“If-Then”の読み方をするんだ」
「相手が『当たり前だ』とか『常識だ』などと答える時は、ちゃんと相手とコミュニケーションが取れている証拠だ」
相手と論理ツリーを共有するために、一緒に読み合わせるときのポイント。 当たり前のことを言っているだけとお互いが思えていればコミュニケーションに問題はない。
p. 92
デイブに解決策を提案しようと思った時、ジュリーが私に目配せした。喉まで出かかった言葉をのみ込んで、代わりに「ゆっくり考えればいい、デイブ。出張は来週だから」とデイブに告げた。
p. 94
解決策をこっちから無理やり押しつけないで、ネガティブ・ブランチをはっきりと示すだけでいい。ジョナのアドバイスが的中したわけだ。もしこっちから提案していたら、きっとデイブはアンフェアで屈辱的な要求だと受け取ったに違いない
「ジョナの手法は確かに効果があるわ。いつも Win-Win で解決できるもの」
p. 284
「まずロジックを詳細に詰めることで、ネガティブを排除するためにどういうアクションを取ったらいいのか、冷静に判断することができるようになる」
「こっちのほうがもっと重要だ。自分一人の力でどうやってネガティブを取り除いたらいいのかわからない、ハービーの協力が必要な場合は、ハービーにああやったらとか、こうやったらと提案したら駄目だ。意見が対立して不愉快な思いをする可能性が高い。そのかわりに、どう考えてその結果どういう結論に達したのかを、ロジカルに説明するんだ。父さんがデイブに説明したようにだ。紙に書いて一つひとつステップ・バイ・ステップで読んで聞かせるんだ。もし、いいソリューションがあればハービーが自分で気づくだろうし、二人でそれを磨き上げればいい。それができれば、あとは心配することはもう何もないわけだから、クルマのリストアを諦めないといけない理由もない」
解決策 (方法) は相手 (当事者) に考えさせて、決めてもらう。 これにより、当事者意識をもって主体的に取り組んでもらえる。
現状問題構造ツリーを作る
p. 140
<思考プロセス> がいかに重要か、二人にもっとちゃんとせつめいすべきだろうか。本能的に感じることを言葉に表現してみることで、経験に基づいた自らの勘を最大限に活かすことができる。また、それを確認する能力が得られる。それが <思考プロセス> だ。
p. 142
「<思考プロセス> では、こうした問題は一つひとつ独立した問題ではなく、むしろ原因と結果という強い因果関係で結びついていると考えています」
まず最初にシステマティックな方法を用いて、、その状況におけるすべての問題を関連付ける因果関係を図に表します。この図を <現状問題構造ツリー> (Current Reality Tree) と呼びます。このツリーを構築できれば、問題すべてに一つひとつ対応する必要がないことがわかります。コアの部分には原因が一つか二つしかないからです
p. 143
「そのとおりです。一つか二つのコアの問題が他のすべての問題の原因なんです。問題のほとんどは症状であって、問題ではない。そうした症状のことを、私は UDE (Undesirable Effects : 好ましくない結果) と呼んでいます。コアの問題を原因として派生する結果なんです」
p. 144
プラント・マネージャーの時、私はジョナの手法は使わなかった。ただし結論だけは使わせてもらった。無理もない、ジョナの <制約条件の理論> (TOC : Theory of Constraints) のコアである <思考プロセス> については当時まだ知らなかったのだ。
p. 209
「矢印を辿ってみてください。どれがコアの問題だかわかりますか。直接でも、間接的にでも結構です」 二人はツリーの上に身を乗り出して、矢印を辿り始めた。しばらくしてジムが視線を上げた。「見つかったよ。みんな (他にまだ挙げていない UDE もあるだろうが) 同じステートメントに辿り着いたよ。『マネージャーは、部分最適化を達成することで、会社を運営しようとしている』。最初からわかっていたなどとは言わないよ」
現状問題構造ツリーで「コアの問題」を把握する
p. 247
他のみんながクライアントの UDE を把握しようとしているのに対し、ピートはクライアントの “コアの問題” を把握しようとしています。それが違いです。
「それだけでは不十分です。一つひとつの症状の原因を潰すだけでは、十分ではありません。すべての UDE を引き起こす原因となっている、“コアの問題” を正さなければ意味がありません」
UDE を把握するのではなく、「コアの問題」を把握する。 そのためにのツールが現状問題構造ツリーである。 「コアの問題」は思考プロセスの『何を変える』にあたる。
ネガティブを減らすメリットは価値を伝えやすい
p. 244
マーケット側の製品に対する価値観を決める要因が何だったか覚えていますか。製品を作るために費やされた努力ではなく、その製品を手にすることによって得られるメリットです
そのメリットには二種類あります。ポジティブなことを増やすメリットと、ネガティブなことを減らすメリットです。
p. 245
時間がないからです。マーケット側の価値観を高めるには、ポジティブな面を追加するのがいちばん強力な方法ですが、時間が限られている時は、ネガティブな面を減らすことに努力を集中させれば早く結果を出すことができます。ネガティブなことなら客自身よくわかっていることなので、いちいち存在を証明したり、取り除く必要性を説く必要もありません。最も抵抗の少ない方法です。
ネガティブ・ブランチ、現状問題構造ツリー、雲などを相手と共有するときに同意してもらいやすい (「あたりまえ」と思ってもらいやすい)。
雲を作り、いちばん気に入らない矢印を見つけ、「目的」を定め雲を消す
p. 209
この <雲> の中でいちばん気に入らない矢印はどれだろうか。
p. 235
『クライアントの価値観に基づいて意思決定し行動する』と『サプライヤーの価値観に基づいて意思決定し行動する』——この二つはお互い相容れない。単純な常識だ。しかし、その仮定は何だろうか。
p. 236
『製品に対するクライアントの価値観は、サプライヤーの価値観より著しく低い』——こういう状況でのみジレンマに直面することになる。
この仮定を変えるには何をしたらいいのだろうか。何か違った見方やアイデアがあるだろうか、私は自分自身に問うた。
『製品に対する市場の価値観を十分高めるために、何らかの策を講じる』
『製品に対する市場の価値観を十分高めるために、何らかの策を講じる』が目的。 この目的を達成すると雲が消える。 「目的」は思考プロセスの『何に変える』の入口であり方向性。
雲を消すための「目的」から、未来問題構造ツリーの最初の「目標」を決める
p. 237
ガイドラインによれば、ここで戦略的目標を選ばなければいけない。しかし、そう怖気づくことはない。「好ましくない結果」の反対を考えればいいだけのことだ。
私は一つ目の目標を丁寧に書いた。『価格を下げずにすべての生産能力を販売する』
私は、もう一つ目標を書き足した。『はっきりとした競争優位性を確立する』
二つの目標をどう達成するのか、その方法を考えなければいけない。つまり、<未来問題構造ツリー> (Future Reality) を構築しないといけない。
目的に対する目標を選択する。 この目標を未来問題構造ツリーを作り始めるときの最初の目標にする。
未来問題構造ツリーを作る
p. 255
私は部屋の隅からフリップチャートを引き寄せ、まっさらなページが現れるまで紙をめくった。ポケットからは分厚い付箋の束を取り出し、一枚目に『価格を下げずにすべての生産能力を販売する』、もう一枚に『はっきりとした競争優位を確立する』と書いた。私はこの二つの付箋をフリップチャートの上のほうに貼り付けた。
私は三つ目の付箋を今度はページのいちばん下に貼り付け、大きな声で読み上げた。「『我が社の製品に対する市場の価値観を十分に高めるために、何らかの策を講じる』」
移行ツリーを作る
p. 288
『支払う金額に対して、我が社の製品が最大の価値をもたらすことを買い手に示す』。なるほど、これが目標か。
「『支払う金額に対して、我が社の製品が最大の価値をもたらすことを買い手に示す』。そのためには、『我が社の製品の価値を買い手に示す』。当然だな。同時に『我が社の製品に対して、買い手が抵抗する原因を作らない』。これもオーケーだ。次がコンフリクトだな。」 『我が社の製品の価値を買い手に示す』ためには、買い手に『我が社の製品を提示する』。当たり前だな。しかし『我が社の製品に対して、買い手が抵抗する原因を作らない』ようにするには、『我が社の製品を提示しない』」
p. 289
現在から未来へいかに移行すべきか、その論法を詳しく示した “ハウツーツリー” だ。
p. 290
いちばん上には目標が記されている。
『買い手は、最初から買う気のあるところを見せてはいけないと考えている』
『買い手は、営業が自社の製品をどれだけよく言おうと、完全には信用しない』
『買い手は、印刷会社との取引であまりいい経験をしたことがない』
『買い手は、我々のオファーに対し関心よりも強い疑いを持つ』
p. 291
『時間的なプレッシャーのない状況で買い手と会う』
「そうです。時間を確保したうえで客に会うことができたら、まず最初に買い手側の <現状問題構造ツリー> について話をさせました」
p. 292
「ツリーを見せてから、今度は数字を使って説明するんです。実際に消費するであろう在庫一つ当たりの価格、つまり “使用可能ユニット単価” (Price-Per-Usable Unit) のコンセプトをわかりやすく説明するためです」
p. 293
『買い手が興味を示す』
p. 294
「そうですね。とにかく、この段階でもう一度、我が社の受注方針と買い手側の UDE の間ににどのような関連があるのか説明します。このページの要点を客にもう一度ちゃんと理解してもらうわけです。客がどんな反応を示すか想像できますか」
『買い手は落胆するが、我が社の営業スタッフを責めることはしない』
『これが我が社の新しい受注方針です』と言って客の <未来問題構造ツリー> を見せるんです
p. 295
<現状問題構造ツリー> を示した時に、客が認めた “If-Then” ロジックだけを使うわけか。
『売り手が寛容すぎると、買い手は疑いを持ち始める』
ネガティブ・ブランチを見せたんです
「いろいろありましたが、どの客からも、こうすればどうかと逆に提案されました」
p. 296
客が契約書を交わすにあたっての懸念事項、問題点をリストアップして客に見せたんです
前提条件ツリーを作る
p. 339
この <前提条件ツリー> によれば、そういうことらしい。このツリーから学べることはこうだ。まず、ステーシーに確固たる競争優位性を約束するようなしっかりしたマーケティング・アプローチを構築させる。次に、ピートの会社 (近い将来はボブの会社も) を “理想モデル” として売り込むという構想をブランドンとジムにも支持してもらう。それから、ボブのソリューションができ得る限りスムーズに導入されるよう尽力することだ。
企業の目的
p. 382
「目標を決めるのは簡単なことではありません。目標だけを切り離して話し合うことはできないからです。物事には限界があり、その範囲内で活動しなければいけません。目標達成に向けた活動範囲の境界線を定めずに、目標を定義しても無駄です 」
p. 383
『現在から将来にわたって、お金を儲ける』
= 目標 ソフトウェア開発部門にの活動範囲に境界線を定めると… 『現在から将来にわたって、スループットを最大化する』
『現在から将来にわたって、従業員に対して安心で満足できる環境を与える』
= 必要条件 ソフトウェア開発部門にの活動範囲に境界線を定めると… 『現在から将来にわたって、エンジニアに対して安心で満足できる環境を与える』
必要条件を侵したら、目標は達成できないのだ。「必要条件」という言葉の意味はそういうことなのだ。
p. 384
『現在から将来にわたって、市場を満足させる』
= 必要条件 ソフトウェア開発部門にの活動範囲に境界線を定めると… 『現在から将来にわたって、問題に対する効果的なソリューションを提供する』
戦略を立てる
p. 388
「まずは、確固たる競争優位性を構築するところから始めます。独自の技術や非常に優れた製品がなければ、多角事業グループでやったことと同じことを行います。市場側の問題を解消するような小さな変化に専念します」
p. 394
「いいかい、もう一度説明するよ。会社が確固たる競争優位性を築く。君の言い方だと、業界ナンバーワンということだ。みんなフル稼働で、会社はたくさん儲かる。みんなハッピーだ。しかし、市場が落ち込んで需要が減る。その結果、必要以上の人員を抱えることになる。問題は、そういう時どうするのかなんだ」
p.396
「単純さ。柔軟性を持てばいいんだよ。一つのセグメントだけじゃなくて、すべての従業員がいくつかの仕事に対応できるようにすればいいんだよ。たとえば、いま、すでに使っているリソースと同じリソースを使って別の製品を新たに開発するんだよ。できると思うかい」
「でも、普通の会社はこれとは正反対のことをやっているんだ。従業員に柔軟性を持たせるには、従業員でなく市場をセグメントしないといけない。でも、普通の会社はどうしていると思う。市場がもともとセグメントされていても、新しい市場が現れると、馬鹿な連中はすぐに新しい工場を作ってしまうんだ。市場ではなくリソースをセグメントしているんだよ。本末転倒さ」
バッファーのサイズ
p. 72
「バッファーのサイズは二つの要因によって決定される。予想消費量とそれを補充するためにかかる時間よ」
ソフトウェア開発の文脈に置き換えると…
- 予想消費量
- 後続タスクのリードタイム
- それを補充するためにかかる時間
- 先行タスクのリードタイム
思考プロセスとは
p. 409
<思考プロセス> を一言でいえば「変化を起こし、実行に移すための手法」である。そして変化を実現するには「何を変えればよいか」「どのような姿に現状を変えればよいか」「どのように変化を起こせばよか」という質問に答えることが必要になってくる。