3. 推論と前提を点検する

「資料の修正が多いのは、依頼者が必要な項目を伝えていないからだ」。この説明を確かめるには、修正の内容と、項目が伝わらなかった経緯を調べる必要がある。説明のどこが分かっていて、どこからが推測なのかを見ていこう。

3.1 原因の候補を比べる

次は、前章までの依頼のケースとは別の、教材用の架空のケースである。

最近修正した資料4件のうち、3件は顧客が必要としていた項目の追加だった。その3件では、必要項目が初稿作成前に作成者へ共有されていなかった。残る1件は計算誤りだった。依頼者がいつ必要項目を把握したかは、まだ確認していない。

項目を追加した3件については、作成前に項目が伝わっていなかったことを調べる価値がある。ただし、なぜ伝わらなかったのかは、まだ分からない。たとえば、次の二つの原因候補が考えられる。

どちらかによって、考える対策も変わる。知っていた項目を伝えていなかったのなら、共有方法を調べる。依頼者も知らなかったのなら、作成前に項目を確認できる相手や資料があったかを調べる。

計算誤りだった1件にも同じ原因があるかは、別に調べる。修正をひとまとめにせず、何を直したかを分けることで、調べる原因を絞れる。

3.2 仮説から予測し、記録で確かめる

「依頼者は必要項目を知っていた」という仮説を調べるなら、当時の打ち合わせ記録や依頼文を探す。記録が残っていれば、項目が明らかになった時点と、作成者へ伝わった時点を比べられる。

さらに、その仮説が正しければ、ほかに何が残っているはずかを考える方法もある。ここでは、仮に「依頼者は、把握した必要項目を必ず一覧に記録する」という運用があったとする。

1. 仮説：依頼者は、初稿を作る前に必要項目を知っていた。
2. 条件：把握した項目を、必ず一覧に記録する運用だった。
3. 予測：初稿を作る前の一覧に、その項目が記録されているはずである。
4. 確認：当時の一覧を探し、項目と記録時点を確かめる。

このように、観察した結果から原因の候補を考え、その候補から別の結果を予測して確かめる。結果、原因、別の結果へと考えを進める調べ方であり、Effect–Cause–Effectと呼ばれる¹。

一覧が見つからなくても、直ちに「依頼者は知らなかった」とは言えない。一覧に記録する運用そのものがなかったのかもしれないからである。予測が外れたら、原因の仮説と、予測に使った条件の両方を見直す。

逆に一覧が見つかれば、作成前にその項目が記録されていたことは確かめられる。作成者へ伝わったか、内容を理解していたかは、別に確認する。仮説から導いた予測と実際の記録を比べることで、確認できたことを少しずつ増やしていく²。

3.3 対立する要求の理由を調べる

原因の説明に加えて、「その方法が必要だ」という要求も点検できる。次は、完成版の提出をめぐる別の架空のケースである。

今日は火曜で、依頼者は「明日の午前中までに完成版がほしい」と言う。明日14時の打ち合わせでは、二つの案を比較し、どちらを詳しく検討するか相談したい。最終決定はしない。作成者は二案の概要と主な違いを把握しているが、詳細の確認に必要な情報は木曜にそろい、完成版は金曜に出せる。

このケースの「完成版」は、二案の詳細を確認済みとして示す資料を指す。依頼者は水曜に完成版を求めているが、作成者が出せるのは金曜である。提出するかどうかだけを話していても、何を満たせば双方が納得できるのかが分からない。

そこで、行動と、その行動で守りたいことを分ける。依頼者は、打ち合わせで二案を比較できるようにしたい。作成者は、未確認の内容まで確定したものとして扱われることを避けたい。この二つをともに満たす方法があるかを考える。

TOCには、この整理に使うクラウド（Evaporating Cloud、EC、対立解消図）がある。クラウドでは、その行動によって満たしたいことを「要求」と呼ぶ。双方に共通する目的、二つの要求、対立する二つの行動を、五つの要素に分けて図にする³。

Aは、双方が認めるかをこれから確かめる候補である。DとD′は、同じ時点に同じ資料を完成版として提出するか、しないかという対立になっている。

図は左の目的から、「そのために何が必要だと考えているか」と読む。AからB、BからDへとたどると、「次に検討する案を選ぶために、比較の情報が必要だ」「比較の情報を用意するために、完成版が必要だ」という考えになる。矢印は必要条件から目的側へ描いており、原因から結果への矢印とは読み方が違う。

この二つ目の関係を支えるのが、「比較の相談にも、詳細まで確認した完成版が必要だ」という前提である。この前提を調べるには、水曜の打ち合わせで何を比較したいのかを依頼者に確認する。

一方、CからD′の関係には、作成者の側の前提がある。詳細を確かめる情報は木曜まで得られず、水曜に「完成版」として出すと、未確認の内容まで確定事項として受け取られると考えている。

ここで、確認済みの違いと未確認点を分けた比較表を考えてみる。それで次に検討する案を選べると依頼者が判断し、未確認点の扱いも共有できれば、BとCをともに満たす方法の候補になる。

明日の相談では、二案のどの項目を比較したいですか。確認済みの違いと未確認点を分けた比較表を水曜に出し、詳細を確認した完成版を金曜に出す進め方で足りるでしょうか。

完成版が必要だと分かった場合は、その理由を踏まえて範囲や期限を再検討する。

3.4 点検する箇所を選ぶ

ここまでの例では、「何が起きたか」「ほかの原因はないか」「その方法が必要だと考える理由は何か」を調べた。TOCでは、説明のどの部分を確かめるかを整理した論理の点検基準（Categories of Legitimate Reservation、CLR）を使う。図にした説明にも、文章での説明にも使える⁴。

次の表は、点検基準と問いを対応させたものである。「事象」は、図に書く出来事や状態を指す。今の説明で疑問が残る箇所を選ぶために参照する。

「原因の十分性」は、考えている説明に足りない条件を探す点検である。「別の原因」は、同じ結果が別の経緯でも生じるかを調べる点検であり、両者は調べる対象が違う。

自分の説明で練習するなら、次の三つを書いてみる。

1. 説明の中で、まだ確かめていないことは何か。
2. それが違っていたら、結論や対策を変えるか。
3. 何を見たり、誰に尋ねたりすれば確かめられるか。

修正のケースなら、依頼者が必要項目をいつ知ったかを調べる。完成版のケースなら、水曜の相談で比較したい項目を尋ねる。調べた結果をもとに、現時点で言えることと次の行動を決める。

前：2. 必要条件と十分条件を使い分ける | 目次 | 次：4. 問いに合わせて思考プロセスを使う