東京〜現実歪曲フィールド界隈

東京で外資系企業の営業で働く人

【参考図書メモ】問題解決の基礎トレーニング──新版 問題解決プロフェッショナル

——再読してわかった「本が悪いわけではない」という結論

なぜ今、この本?

第三章(1)ロジックツリーを書くにあたり、「企業参謀」と併せて、参考図書として、区立図書館から本書を借りた。

大前研一氏の「企業参謀」を軸に据えることは最初から決めていたが、それだけで本当に十分か?、入門編としての視点は必要なのでは?、という不安があったからだ。

本書の著者、齋藤嘉則氏は「問題発見」「問題解決」で大前氏の盟友として著名な方。私が学んだMBAの特別コースの指導教官でもあった。

同じ系譜に連なる問題解決の方法論を、入門者に優しいとされる視点から、どうしても確認しておきたかったのだ。

でも、氏と自分の相性の悪さは知っていた。特別コース、なぜか途中で履修放棄していたことを、MBAの成績証明書で見たから。理由はわからない(笑)

余談が過ぎた。

違和感のまま

この手の話は、簡単に理解できる。
私にとっては、極めて当たり前の世界であるから。
修士では、化学実験のうまく行かない合成で、散々悩み、問題解決をしてきた。
プラスチックの製品開発の過程も同じ。
大前研一氏の原子炉の研究と、本質的には大差ない。

日々、当たり前と持っていることを、書籍で読んでも感動なんてあるはずがない。
ただ、高い授業料を無駄にしたのは理解不能だ。

ゼロベースで本書を紐解く。

説明は丁寧だし、事例も豊富で、わかりやすい。

しかし、わかっている、ということ以上に、ある違和感が積み重なっていった。

——どうも、自分ごととして入ってこない。

実践編で扱われる事例の多くは、MBAの企業プランや、コンサルティングの現場を前提としている。
若い頃であれば、「いつか自分も事業計画に関わるかもしれない」と思いながら、興味を持って読めたかもしれない。

しかし、現実には、そのような機会はほとんどなかった。
事業環境の内側で仕事を続けてきた今、この切り口を突きつけられても、「だからどうした?」と、どこか距離を取ってしまう自分がいる。

役に立たない、というよりも、自分の立っている場所と、前提条件が合っていない。
そんな感触だった。

変わったのは、本か、自分か

変わったのは、明らかに自分である。

34歳の頃、MBAを学んでいた当時は、コンサルティングという道も、選択肢の一つとして頭の片隅にはあった。
だが、最終的には、事業環境の内側に身を置くことを選んだ。

その結果、必要とする問題解決のスタイルも変わった。
抽象度の高いフレームワークよりも、もっと現実に密着した、具体的で、再現性のある事例でなければ、腹落ちしなくなった。

そう考えると、本書に対して感じた距離感は、批判というよりも、立場の違いから生まれた必然なのだと思う。
コンサルタントが書いている以上、そこで扱われる事例が「特殊」になるのは、ある意味では仕方がない。
そういう状況しか、書けないから。

普通の人が考えることは、普通の人でしか書けない。

第三章との接点 —— それでも有用

結論から言えば、この本を今後、実務で使うことは、おそらくもうない。
少なくとも、何かに迷ったときに、手に取る一冊にはならない。

だが、それは本書が無用だからではない。
ただ、私には刺さらなかった。
それだけのことだ。

第三章で私が書こうとしていたのは、「ツールの正解」ではない。
ツールがどのような前提で生まれ、どのような場面で有効で、どこから先は無力になるのか。
その境界線を、自分自身の言葉で確かめることだった。

その意味で、本書は、「もう使わない」と結論づけるために、必要な一冊だった。
避けて通るべきではなかった、という意味で。

執筆ノート〜2 第一部を書き終えて

ブログを開設してから、23日。来週で、1ヶ月。

序、第一章、第二章、第三章まで書いてきた。
実は、ここまでが第一部。
本書は、まだ秘密の書籍タイトルでの三部構造で考えている。

さらに夢は大きく、本書を含めたシリーズの三部作の構想がある。
企画書を書けるくらいの精度で、三部作のデザインはできている。でも、まずは本作。
全ての入り口であり、全編の基盤だから、神経質にならざるを得ない。

特に難産だった第三章

Case-by-Caseであるということ。
この章のタイトルは構想段階から決めていて、全くブレることなく、今に至る。
コンセプトにブレはなかったのにも関わらず、なぜここまで難産だったのか?

まず入口で恐れ慄いた。
執筆ノートという新しいカテゴリを作ったのは、それが理由。
もう一つは、毎日更新の呪縛だ。これも第三章の(3)で書いた通り。

すでに世の中で確立していることを書くから、正確さとわかりやすさは必然。
だが、「構造化の知的生産ツール」は、概説やケースだけで本になる
そのくらい、深く、難しい。

もう一つの難しさは、「共感」
ロジックツリーを実際に書いて考えている人はどれだけいるのだろう?
まず、その部分が想像できなかった。

ましてや、TOC理論のクラウド
非常に印象的だが、なかなか見る機会がない。
解説の書籍も、グッと少なくなる。

書く歯車が回り始めた

書くことが、本当に辛かった。
でも、書いてみた。AIも使った。参考図書も読み漁った。
自分の言葉にならないことが、何よりももどかしかった。

だいたい、動きを見せるのがわかりやすい。
それなのに、ブログ、書籍かよ。字だけで、多少イメージを挿入するにしても、 それで、わかるのだろうか?伝わるのだろうか?共感できるだろうか?

アクセス解析見て、絶望的に少ない読者数を見て、
ニーズはそもそもあるのだろうか?
こんなに読むのが重たいブログを、受け入れてもらえるのだろうか?と。

でも、私には、この先に、書きたいことがある。
それは、誰もまだ本にしていないこと。自分が読みたいこと。
誰も書いてくれない、だったら、自分が書くしかない。と。

この世にないものを作る、は、この本の核心である。
その学問の核心である。
でも、あまり知られているとは思えない。

でも、そこにたどり着くには、前段の部分での共感が必須。
それが、重たいドアを開けるための、条件である。
だから、歯を食いしばって、書いてみた。

正直、拙いところはある。
私は、ビジネス書の著者にはまだなっていない。
そのレベルまでは、いかないといけない。

でも、改めて考えてみたら、
私も含めて、成長していくストーリーは好きだ。
勇者だって、Level 1からスタートする。

理解しきれないまま、わかったふりをするのではなく、
わからないこと自体を、構造として書く。
その姿勢に切り替えたことで、第三章は前に進み始めた。

AS-ISとTO-BEの解像度を上げるということ

この苦しさの中で得たことの最大の一つは、
試行錯誤のループを何度も回ることの意味だった。

道に迷って、散々苦労して歩いたのに、
たどり着いたのは、さっきと同じ分岐点に戻っていただけだった、
そのような徒労感を感じることは、きっと誰にでもあるだろう。

でも、気がついたことがある。
たとえ、また同じ分岐点に戻っただけだとしても、
その前に来た時と、今の自分では、全然成長している、ということ。

PDCAサイクルを回して、また同じ問いに立つかもしれない。
でも、自分は成長している。
以前は見えていなかったものが、見えている。
形を伴って、細部まで少しずつ見えるようになっている。

試行錯誤を続けることは、決して無駄なことではない。
そのことで、AS-ISとTO-BEの解像度は、必ず上がるからだ。
目的を見失うのは、そもそもTO-BEの設定が間違っていただけ。
自分が折れたのではない。

最近のビジネス書でも、「解像度」という言葉がよく使われる。
ぼんやりとしていた世界が、輪郭を持って立ち上がる。
第三章で書きたかったのは、まさにその感覚だった。

翻訳から本論へ

第一章から第三章までは、
世の中にすでにある考え方やツールを、
できるだけわかりやすく、自分の言葉で伝える「翻訳」の作業だった。

ここから先は違う。
私自身が「書きたい」と思った本論に入る。

独りよがりにならないように。
特に「ああ、そういうことだったんだ」と腑に落ちる感覚を大切にして、
受け入れることのできる最小の変化で、最大のレベルアップが伝わるように

第二部は、その期待の芽をあなたの心に芽吹かせる。 まずは、第四章。
冬から春への希望を見つける旅へ。

ぜひ、ご一緒に参りましょう。

第三章(5)Case-by-Caseであるということ

第三章では、一貫して構造化を論じた。
トップダウンのロジックツリー、
ボトムアップのピラミッドストラクチャー、
対立問題を雲として描き、解決思考を構造化するTOCクラウド

どれも難関でした。
使い方を習熟しているかはともかく、どういうものかは理解した。
でも、いつ、どれを使えばいいか、まで、実戦で使える領域へは遠い。

構造化ツールの実戦投入

あなたの人生で、構造化ツールを使うケースを考えよう。
そもそも、それはどんな時か?

今(AS-IS)に対して、これからの未来(TO-BE)を考える時だ。

だが、何を使うかはケースバイケース。
選択には、今の自分の座標の診断を必要とする。

今(AS-IS)と未来(TO-BE)を提示して、
謙虚に、そしてゼロベースで冷静に見つめ、
今の自分の座標を診断をする。

  • 今 vs. 未来
  • 事実に重き vs. 目標に重き
  • 選択の有・無
  • 自・他の分離

これらは正解を選ぶための基準ではない。
思考を動かしてから、正解を探す。
思考を動かすためには、いまの自分がどの座標に立っているか?
それを確かめるための基本的な問いから始めるのである。

未来のことを主に考える場合は、ロジックツリーが相性がいい。
どうありたいか、どうしたいかをブレインストーミングで列挙する。
分類し、共通点を抽出し、関係性を分析して、
全体を構造化し、ロジックツリーとして描き直す。

現状の問題を整理したい場合は、ピラミッドストラクチャーが相性がいい。
まずは、事実(ファクト)を収集する。 収集した事実を分類し、共通点を抽出し、関係性を分析して 全体を構造化し、ピラミッドストラクチャーを描き始める。

ジレンマに陥っている時。
他者との関係で板挟みにあっている時。
もっと良い解決策があるのでは?と自信がない時。
明確な対立構造がなくても、TOCクラウドを適用するといい場合は多い。
回答は一つしかないと、あなたは思い込んでいるかもしれない。
鏡にかざしてみて、反対の方向から眺めてみる。
そうすると、想像もしていなかった対立の構造が具現化することもある。

この構造化ツールの選択は、1発で成功させなくていい。
ロジックツリーで構造化しようとしてみたら、思い込みの違いによる対立構造が見えるかもしれない。
もしくは、究極的な目標と思っていたものが、実は、数ある現象の一つに過ぎず、さらに上の上位概念が存在していることだってあるだろう。

誰だって判断は間違うことがある。
間違えたと思ったら、すぐに方針転換することが大事なのだ。
思考を停止してはならない。
ケースバイケースで対応する柔軟性を忘れないことだ。

知的生産ツールとケースバイケース

第三章で取り上げた構造化するツールも、絶対的なツールはなかった。
第二章の指標としてのKPIも、第一章のフレームワークも同様だった。

www.tokyo-nw-field.com

www.tokyo-nw-field.com

私たちは、ケースバイケースで、知的生産ツールを使い分けなくてはならない。

正直に使い分けは面倒に感じる。
でも、どのツールも切れ味は抜群。使わずにはいられない。
習熟が大変!!と、げっそりするかもしれません。
でも、安心して欲しい。心配はご無用だ。

そもそも、現実の世界の方が、使う道具は複雑・多種だ。
例えば、プラスのドライバー.。
こんな単純なものですら、
太くてごっついのから、精密で微小なものまで、バリエーションが豊富だ。
ドライバーセットだけで、それなりのボリュームになる。

それだけ、最適化がなされている。
パフォーマンスの最大化を考えるならば、ケースバイケースの最適化に至る。
でも、あらかじめ多様なケースを想定して準備するとなると、非効率だ。
ジレンマである。
効率的な準備とパフォーマンスの最大化を両立できないか?

要素のバリエーションの掛け合わせに分解する

例えば、144通りのバリエーションがある場合を考えよう。
それぞれの最適解、144個を覚えるのは大変だ。
掛け算の九九よりも、記憶する量が多い。
とても現実的でない。

144通りに共通する項目を調べたら、

  • 要素Aで4パターン
  • 要素Bで3パターン
  • 要素Cで6パターン
  • 要素Dで2パターン

で構成されていた。
つまり、
  4✖️3✖️6✖️2=144
で記述されることがわかった。

この場合、4つの要素に分解した。
各要素が取りうるバリエーションを上記の箇条書きで整理した。
それらを掛け合わせることで、
対象をパターン化できた。

具体的に見てみよう。 さまざまな症状が見られる風邪について

  • 頭痛・体の痛み
  • 発熱・だるさ
  • のどの痛み
  • 胃腸の不調

に分類できる。
これらの各要素が取りうるバリエーションの掛け合わせのパターンに応じて、
治療法を変えるという具合だ。

このように、

  1. 要素に分解する。
  2. 各要素が取りうるバリエーションを整理する。
  3. それらを掛け合わせて、対象をパターン化する。

のである。

対象のパターン化により、
144通りの最適解の全てを覚えなくても、
効率的に準備ができて、
パフォーマンスを最大化できる。

そして、各要素に分解するツールが、フレームワークであり、KPIである。

構造を特定して、パターン化する

整理しよう。
まず最初にやることは、暫定的にAS-ISとTO-BEを用意する
そして、診断を通じて構造を求める。(プラスドライバーを使うことの特定)
それから、パターン化のために分解する。(風邪の症状)
再びAS-ISとTO-BEに戻り、それぞれの解像度を上げる
この順番で、思考し続けることによって、成功への確率を高めることができる。

第一章から第三章まで論じてきたのは、構造を特定し、対象をパターン化するための、知的生産ツールである。
最小限の労力で、成功確率を最大化する。 知的生産ツールを使用するメリットは、まさにここにあるのだ。

  1. 暫定的にAS-ISとTO-BEを用意する
  2. 診断により、構造を求める
  3. 要素に分解してパターン化する
  4. AS-ISとTO-BEの解像度を上げる

これが、王道なのである。

第三章(4)見える世界と見えない世界の構造化

TOCクラウドは、図を見ても、少しもすっきりしない。
言い方を変えると、安心できない。

イメージ:TOCクラウド
一方で、ロジックツリーも、ピラミッドストラクチャーも、見た時の安心感はハンパない。
イメージ:ロジックツリー

そう感じるのはなぜか。

前節を書くまで、TOCクラウドは全く理解できない代物だった。
正直に、「なんだこの中途半端な図は!」と思っていた。
でも、そうではなかった。
不完全さには、意味があったのだ。
ようやくそのことに気がついた。

完了と未完

ロジックツリーは、書き上がった時点で思考の中間ゴールになる。
ピラミッドストラクチャーも同様である。
書き上がったツリー図そのものに、同じ図の中でさらに手を入れていく、という使い方は基本しない。

一方でTOCクラウドの場合、この図がスタートラインになる。
本当の思考は、これからである。 書いたのは、対立構造を「見える化」しただけだ。
まだ、考えていない状態である。

対立構造の見える化は、ロジックツリーのような構造化とは異なる。
網羅感が重要なロジックツリーに対して、
不安定な構造に見せるべきなのが、TOCクラウドなのだ。

意図的に、不安を感じさせる。
安心感があったら、大失敗だ。

中途半端感が生む解決へのモチベーション

そもそも、クラウド、「雲」だ。
見通しのいいものではない、逆。
消し去るべき、蒸発させるべき対象である。
この雲がとれたら、富士山が綺麗に見られるのに!の「雲」なのだ。
おじゃま虫、と言っていい。

意図的にそうするのは、

  • 思い込み
  • 根拠のない前提
  • 目を曇らせるもの

に気づくための舞台だから。

ロジックツリーのように澱みなく流れる構造にはしない。
分断ばかりのツリー構造をつくる。
分断があると、脳は自然に、
それを埋めるべく、考えることを始める。

TOCクラウドが、意図的にスカスカのツリーなのは、そういうことだった。
スカスカなのに、クラウドで曇っているから、それをスッキリさせたくなる。
私たちは、
とにかく図を書いてしまえばそれであらかた終わる
と思っている。
しかし、TOCクラウドは、思い切り、それを裏切る。

ロジックツリーもピラミッドストラクチャーも、書き終えるには相当なパワーがいる。
書き終えた時の達成感もひとしおだ。
一方で、TOCクラウドは、全然逆だ。書くほどに不安になる。
頭の中の対立構造を見せつけられるから、平気なわけがない。
だから、クラウドを晴らす、決意が湧く。

だ、け、ど、
傍観者にはそれが分からない。
あなたがTOCクラウドが理解できないのも、無理はない。

しかし、実は常時、そんな環境に身を置く職種が、この世にはある。

クラウドを蒸発させる方法

多分、TOCクラウドを晴らすコンテストを開催したら、優勝するのは営業だろう。
常に、あちらを立てれば、こちらが立たずな状況の中で、
できるだけ、多くの人がハッピーになる答えが求められる。

Win-Winなんて優しい、三方良しどころではない、
もっと複雑な利害関係の中に身を置いている。
建設的であるのは当たり前。
さらに生産的で、クリエイティビティが求められる仕事が、営業だ。
今は、サステイナビリティも要求されている。
いまだに、お調子者であればなんとかなる、なんてのは石器時代の「営業」だ。

営業は、どうやってTOCクラウドを蒸発させるだろうか?
対立構造そのものに直接手を入れようとする営業は、少ない。
だいたいにおいて、藪蛇になる。 中途半端に肩入れすることが一番ヤバい。

営業において一番大切なのは何か。
それは信頼関係だ。
営業を知らない人は、お客様と営業の信頼関係だ、というかもしれない。
実はそこではない。
会社から信頼されているか、が問題の核心なのだ。

営業が経験する板挟みの大半は、お客様と会社との間だ。
その対立関係に手を入れると、大やけどを負う。
お客様側に立てば、給料ドロボー? それどころではない、逆賊だ。
会社側に立つと、客は離れる。
禁じ手である。

さて、絶対にやってはいけないことは理解した。
ではどうするか?だ。
弁証法みたいな、高度な技術は必要ない。
前節の私のケースを思い出してほしい。
対立構造を補強するD→B、あるいはD'→Cの構造が
「そうでなければならない」「そうであるべきだ」など
思い込みに過ぎなかったのであって、本質ではなかったと指摘する。
本質は別なところにある。
私のケースでは、「何を伝えたいかを明確にすること」が抜けていた。
すると、クラウドは内部から崩壊する。
これが王道だろう。

まさに、ブログのタイトル通り、「現実歪曲フィールド」を炸裂させる。
「でもね、実は、○○○なんですよ。」
そんな一言で、対立構造そのものを無効化する。
見るべきだが見えていない、異なる現実を見せるのだ。

それが、「クラウドの蒸発」である。

徹底的な現実主義

実は、もう一つ別な方法ある。
それは徹底的な現実主義。
というより、ダークサイドだ。

対立構造を補強するD→B、あるいはD'→Cの構造は、
全て思い込みであり、辛い現実を見たくない夢と見なす解決法。
たわけ! 戯言(ざれごと)じゃ。
お前の目は節穴か!
大魔王「信長」の如く、力技で前提そのものを焼き払い、冷徹な現実を突きつけてクラウドを消し去る。

こういうの、意外とよくある。
世間的には、ショック療法、ちゃぶ台返し、と言われる。
霧を晴らすための、すべき努力を放置した、もしくは、されてしまったがために、
極端な現実が突きつけられる。

「信長」以外のなにかいい例がないか? ああ、思い出した。
ちょっと、懐かしの領域だけれど、
笑ゥせぇるすまん、喪黒福造の、ドーン!!だ。

営業としては、そんなやり方はもちろん、したくない。

第三章(3)頭の中の構造化──TOCのクラウド

この世には、形を伴った構造体がある。ピラミッドとか法隆寺五重塔とか。
もう一方で目には見えない強固な思考の構造体も存在する。思い込みや思考回路とか。

第三章では、「構造」をキーワードに、知的生産ツールを語る。
本節では、いよいよ目には見えないものへと踏み込もう。

ザ・ゴール2の思考プロセス

ロジックツリー、ピラミッドストラクチャーという、目に見えて思考を構造化するツールは、説明する上で非常に便利だ。
ほぼ、誤解されない。
概ね、理解を共有できる。

しかし、そうではない構造化ツールがあることを、私は知っていた。
ザ・ゴール2で扱われている思考プロセスのツールだ。

初版発行は2002年2月21日。
記憶では、発売当時の大型書店の平積みから手に取って読んだはず。
ザ・ゴール同様に、ストーリー展開が面白くて、一気読みした。
しかし、主役級の思考ツールは、なんだかよくわからないもの、だけれど興味深いものとして、ずっと頭の中にこびりついていた。

「非常に強力な思考ツール!」と再三再四取り上げられて、ストーリ上で大活躍するけれど、当時は「どう使ったらいいのか」全くピンと来なかった。
でも、覚えていたのだ。
きっと、有効なツールなのであろう。

そう思っていただけに、このブログで取り上げるアイデアが湧いた時、勉強し直すチャンスが来た、と素直に喜んだ。
本ブログでは、知的生産ツールを一通り紹介する。
フレームワーク、KPI、構造化のツール。
二つの対立する課題を鮮やかに解消する思考ツールとして、ザ・ゴール2の思考ツールも含めようと企画を立てた。

さっそく1週間前に、ザ・ゴール2を区立図書館で借りて、通勤時間、昼休みなどを使って、斜め読みしてみた。知的ツールの使い方を説明している箇所を探そうとして。
しかし、ストーリ展開の中でスポット的に登場するばかりで、思考ツールの使い方を説明している部分がない。
これは、非常に焦る展開だ。
クラウド、と呼ばれる対立構造を解きほぐすツールの効能は分かる。
だが、どうやったらそれを利用できるのか、皆目、見当がつかない。
執筆予定の日まで、残りわずかになってしまった。

そこで、AIにぼやいてみた。
クラウド」が分からないのは、私の問題ではなかった。
そもそも、ザ・ゴール2には、具体的な方法は書いてないのだった。

AIのおすすめに従って、解説本を手に取ることにした。
すっかり準備時間は無くなっていたので、Kindleで購入することにしたのだ。 今原稿を書いている2日前のことである。

TOCクラウド

AIが勧めた本。
少し読み進めたら、出てきた。
ザ・ゴール2で見た、対立構造図、「クラウド」。
ロジックツリーの精緻な美しさとは打って変わって、これで何が説明できるのだろう?と不安になる、単純な図。
こんなんで大丈夫なのか?

それでも、解説本を読み進めていくと、少しずつ輪郭が見えてきたような気がした。
だが、全く馴染んでこない。
理解はできるのだが、納得感がない。
自分の血肉にして、完全にモノにするには、あと何日かかるのだろう?
絶望的な気分になった。

だから、またAIに愚痴った。

ちょっと、ブログに書くには、理解するだけの十分な時間が必要。 だから、執筆日誌で今抱えている苦悩だとか、 参考にしている本のことを紹介する記事を書いて、 なんとか毎日更新だけ継続して、 本編は後回しにしてもええのかなぁ・・・

そうしたら、「その「歯がゆさ」は、書き手として健全な感覚です。
結論から言うと、あなたが感じている逡巡は クラウドそのものの性質と完全に同型で・・」とほざいてきやがった。

ハッとした。
そう、自分は今、対立構造の只中に立っていたのだった。

ブログ筆者の対立構造

このブログを書き始めたきっかけは、年末休みにAIと壁打ちをして、「自分が読みたい本」の主題を掴んだからだ。だから、なるべく早く、本としてのまとまりを作りたい。結論を見たい。それがブログを書くモチベーションだ。

しかし、その一方で、十分に理解しないでブログを書く、人に説明するのは、筆者としてあるまじき行為ではないか、と思ったのである。

要するに、(クラウドの書き方に倣うと)

  • D: TOCクラウドが理解できるまで本編では書かない。
  • D': とにかくAIを使ってでも、予定通りTOCクラウドを本編で書き、先へ進む。

という二つの相反する立場のどちらにもつけられない、宙ぶらりんな状態にいたのだった。

共通目的を考える

そんな私には、一切構うことなく、AIは淡々と先に進もうとする。

次に、対立構造にはなっているけれども、DとD'のどちらにも共通する究極的な目的を考えましょう。

一度は本気でブログを運営しようと考えたことのある人なら、
ブログは原則、毎日更新すべきだ と、思い込んでいるはずだ。
だから私は、共通目的(A)に
ブログを毎日更新するため
と置こうとした。

AIにそう回答したら、ダメ出しを受けた。
ここには「行動」ではなくて、「目的」を置くのですと。
もう少し考えた。
意味のあるブログの記事を毎日提供すること
これならどうだ。十分に目的である。

AIは随分と評価してくれた。
だが、まだもう少し磨きましょうと。
「意味のある」が後でどうにでも捻じ曲げられるから、良くないのらしい。
なのでAIは、

A:読者にとって意味のあるブログ記事を、毎日提供すること

を提案してきた。
もちろん異論などない。

対立構造へのなぜ?

次にAIがアドバイスしたことは、

B:なぜ「理解できてから書きたい」のか

C:なぜ「連載を止めたくない」のか

事実ではなく、信念・恐れ・経験をあげなさいと。

Bについて考えを進めた。
理解してから、書きたいというのは、別に間違いを犯すことを恐れているわけではない。
理解していないのに、私は理解しています、と自分を欺いていることが、受けれられないのだ。

AIが即座にまとめてくれる。

B:自分が理解していないことを、理解しているふりをして書きたくない

なぜ、これがいいのか?

  • 技術的問題ではなく
  • スキル不足でもなく
  • 価値観・倫理・自己同一性の問題

だからだそうだ。

次に、Cについて考えた。
「書いている本」の全体から見たとき、TOCの思考ツールの話は瑣事でしかない。
それよりも、全体像を早く完成させたほうがいい。
目の前の障害にかまけないで、大志である本物のゴールへ早く近づくこと、を考えるべきだ。
そうしたい、という欲求でもある。

再び、AIが翻訳してくれた。

C:個別の難所に足を取られず、
 本全体の完成という大きなゴールに向けて前進したい

これは、

の対立になっており、TOC理論そのものを内包したCだ、と評価していた。

TOCクラウドクラウド

正直いうと、このクラウドの図を見ても、まだ、さっぱり解決策が見えない。
このダイアグラムの意味は後で考えるとして、次にやることは何か?

AIがアドバイスを続けてくれる。

そして「蒸発」へ

次の段階でやることは、ただ一つです。
BとCが“本当に両立できない”と思っている理由は何か?
つまり、

  • Bを守るには、なぜDしかないと思っているのか
  • Cを守るには、なぜD’しかないと思っているのか

このとき出てくるのが、
「理解していないものを書いたら欺瞞になる」
「立ち止まると全体は進まない」
というもっともらしい前提です。

ここを一つずつ疑い始めた瞬間、
クラウドは“問題”ではなく“素材”に変わります。

さて、ここが考える踏ん張りどころである。

世間感覚では、B→Dを先に考えるだろう。
つまり、「理解していないものを書いたら欺瞞になる」 という理由だ。
だから、こちらから消そう。

読者は、書き手がその道のプロであると思い込む。
だから私も、「理解できるまで書いてはならない」という思い込みに囚われている。
でも、読者目線で見れば、私がその道のプロであるかを検証するすべはない。
それよりも、著者が伝えたいことが、読者へ正しく伝わるかが問題なのだ。
TOCクラウドについて、著者が深く理解しているか否かは、読者には分からない。
それよりも、謙虚で真摯な姿勢が大切だ。

著者としての私の本質的な問題は、
何を伝えたいのか、が明確になっていない
ということだった。

頭をガツンと、殴られたかのような衝撃だった。
なんで、こんな根本的なことを理解していなかったんだろう。

ここまで思考を進めた結果、B→Dの結びつきがプッチンと切れた。

「理解していなくても、
伝えたいことが明確なら書ける」

のである。
著者としての道徳感は抜きにして。

では、他方はどうだろうか?
C→D'の結びつきである。

片方の前提を壊してみると、残りも同じ構造であることに気がついた。
まるで鏡の世界を見ているようだった。
とにかく体裁を取り繕ってでも、書く、連載に穴を開けない、という成果ばかり気にしていた。
これも本質的には誤りだ。
著者として「伝えたいこと」を明確にして、それさえ書ければ良い、という境地に至ることが大事なのだ。

こうして、C→D'の結びつきも、同じようにガラガラと音を立てて崩壊した。

まとめ

AIは鮮やかに解説してくれた。

B→D と C→D’ の両方を壊したことで、
クラウドはこう変質しています。

D と D’ のどちらも
「取る必要がない行動」になった

対立は「解決」されたのではなく
存在理由を失った

つまり、

書く/書かない
無理する/立ち止まる

という二項対立そのものが、問いとして意味を失った。

これが、クラウドの「蒸発」です。

そして、最後に残ったのは、

著者として、何を伝えたいのかを明確にすること

でした。

こうして、この節を前に私が抱えていた対立は、
TOCクラウドについて書くか、書かないか」ではなかったことが分かった。

何を伝えたいのかが定まらないまま、
行動だけを選ぼうとしていた。
それ自体が、対立を生み出していた。

AIの助けを借りて、クラウドを利用することで、ようやく辿り着いた境地。
やってみれば分かる、はその通りだった。
こうして、私は、実地でクラウドの破壊力を体験したのだった。

第三章(2)ピラミッドストラクチャー ──AS-ISからの構造化

多様多種な事実に溢れ、簡単には全体像が見えないとき、
ピラミッドストラクチャーは威力を発揮する。
これは、ボトムアップから全体構造を掴む方法だ。 データや事実は、少ないよりも、多少、多い方がいい。
でも、過ぎたるは猶(なお)及ばざるが如(ごと)し
という孔子の言葉にあるように、
多ければ多いほど良いわけではなく、
話はそんなに単純でない。

なぜならば、事実やデータが多すぎると、それらが意味するところの理解が難しくなる。
部分にばかり目がいき、全体構造が見えなくなる恐れがあるからだ。

ロジックツリー(イシューツリー)は、ゴールから逆算して構造化していく方法だが、
ピラミッドストラクチャーはその逆である。

ピラミッドストラクチャーの作り方

ピラミッドストラクチャーの作り方は、ブレインストーミングのまとめの段階に似ている。

【手順1】グルーピング
まず、集めた事実、データを似たもの同士、関係性があるものでグループ分けする。

【手順2】グループ別にまとめる
グループごとに、要するにどういうことか?を抽出する。
例えば、事実Aと事実Bのグループについて、この二つの事実から導き出される結論Cを考えるのである。 この時、結論Cはメッセージであることが望ましい。
概念を代表するキーワード、例えば「コミュニケーション」でまとめてしまうと、せっかくの具体性を失ってしまうからだ。「グループ内のコミュニケーションが不足する」のようにしたい。

この結論Cを事実Aと事実Bのグループの上に置く。
このように、下から上へと、つまりどういうことなのか?の関係性を構造化していく。

もし、グループをまとめる上位のメッセージが見当たらない場合は、
共通項を見つけ出し、新しい解釈や概念を自分で設定する。

【手順3】全体構造の構築 各グループの小結論が得られたら、グループ間の関係性を確認しよう。
それらを束ねて、「最終的に一番言いたいことは何か(メインメッセージ)」をピラミッドの頂点に置く。

【確認作業】上から下へ見直す ピラミッドができたら、今度は上から下への論理構造を確認する。
上のメッセージについて、どうしてそう言えるのか?の関係性が成り立つかを検証するのだ。
そして、底辺まで論理の破綻がないことを確認して、ようやくピラミッドストラクチャーの完成である。

このように事実から出発し、「要するにどういうことか?」で上への関係性が説明され、逆に上から下へは「どうしてそう言えるのか?」が説明される。
ボトムアップのアプローチで、下から上へと構造化する手法をピラミッドストラクチャーというのである。

どう使うか?

今の時代、道具の使い方についてのガイドは、いくらでも手に入る。
しかし、肝心なことは、道具をどう使うか?なのである。

ピラミッドストラクチャーは、とにかくトラブル続きで、仕事が捗らない場合に役に立つ。

まず、今抱えているトラブルや、やらなくてはならないことを全て書き出してみよう。

営業としての例を出すと、

  • 請求単価の間違いを指摘され、請求書の単価修正の承認を依頼されている
  • お客様から、見積価格の件で問い合わせを受けている。
  • グローバル本社から、日本の平均単価が著しく低いとの指摘を受けている。

が上がったとしよう。
共通する問題は何か?
営業における「単価管理の仕組みが機能不全になっている」というのが、想定される上位に来るメッセージだ。 同じように他のトラブルをまとめていくと、最終的にピラミッドの頂点には、営業活動をサポートする仕組みが機能していない、という結論が得られるかもしれない。

このように個々の事実を問題解決の対象として直接扱うのではなく、
「なぜそうなるのか?」という一つレベルを上げた原因に引き上げ、最終的な課題を見つけるのである。

根本的な課題が明白なものとなれば、重要なイシューに集中して取り掛かればいい。
間違っても、個別の問題に対して、一つ一つ対応するなどと考えてはいけない。
なぜならば、その場、その場の瑣末なケースに過ぎず、根本的な問題解決は都度先送りされてしまうからだ。
問題の根源を放置し続けると、末端問題は再生産され続け、処理する私たちの方がエネルギー切れして、鬱になってしまう。

問題の構造はわかった、解決法は?

ピラミッドストラクチャーを利用して、問題の全体像が掴めた。
では、そのまま問題の解決に向かって良いか?
実はよろしくない。

この構造は、問題の本質を掴むための構造であって、解決策を講じるための構造ではないからだ。
解決する際は、再びロジックツリーに戻り、解決すべき課題に細分化していくのだ。

先ほどの営業での例で言えば、「営業活動をサポートする仕組みが機能していない」が最終的な結論であった。
これをロジックツリーで問題解決可能な課題の塊へと分解していく。
営業活動をサポートする仕組みには何があるのか?
そして、それぞれの仕組みの重要性と業務における影響を評価し、
まず何を解決すべきかを決める。

単価管理システムに、オペレーション上の不都合が多く、問題の巣だと判明したら、
そこから問題解決を図るのである。

何かを成すとき、ボトムアップのアプローチで、細かいことをたくさんやっても、バリューは出ない。
本質的に重要な急所を叩かなくては、意味がないからだ。

延々とモグラ叩きをしても埒があかない。
そのうち疲れ、燃え尽きてしまう。
根本的な課題、もぐらの巣を叩いて、一網打尽にしなくてはならない。

問題発見のための手法

このように、ピラミッドストラクチャーは、
たくさんの事実や結果からボトムアップで構造化して、
本質的な課題を見つけるためのツールである。

問題のありかを下から上へと構造化する、問題発見編のツールなのである。
そして、解決編はロジックツリーが主役交代で出てくる。

問題を帰納的に扱い、本質的な課題を見つけるツールが、ピラミッドストラクチャー。
問題を分解し、集中させる力点を見つけるツールが、ロジックツリーである。
この使い分けを、十分に意識しなくてはならない。

第三章(1)ロジックツリー──TO-BEからの逆算思考

成功法則の一つに、
ゴールから逆算して考える
というものがある。
ゴール、TO-BE(あるべき姿)が明確な時、ロジックツリーはとても有効である。

決算期末が12月であることの多い外資系企業では、
1月は業績評価と新年度の業務目標を決める月だ。

達成すべき今年度の目標や予算が、上から降ってくる。
だが、どうやってそれを実現するか?
懇切丁寧に教えてくれる人はいない。

文字通り自分の責任と権限で、実現する方法を考えなければならない。

予算達成を例に、どのように戦略立案するかを考えてみよう。

予算達成への戦略立案

成り行き任せで、予算が達成できる幸運もある。
しかし、それには準備ができていることが前提だ。

まず最初に、フレームワークに区切って考える。
製品別、顧客別、用途別などの様々な切り口で予算を分解しながら、

  • どこを、どのように伸ばすか?
  • どの部分が、自然減で凹みそうか?
  • 景気動向の影響を受けやすい部分の傾向と対策は?

といった問いをたてて、一つひとつ考える。
その際、部分で考えず、全体構造を意識する。
相互の関係性を踏まえ、打ち手が及ぼす影響を考慮しつつ、戦略を立案するのだ。

このように、あらかじめ「どこを、どうするか」の準備ができていれば、予算達成の雲行きが怪しくなった時点で、素早く対応できる。

これまでの文脈で語るならば、
目標を達成するためのKPIを、計器として眺めるだけでは不足だ。
まず、事前に手の打ち筋(ソリューション)を用意する。
ひとたびKPIが異常を示したとき、用意した打ち手を澱みなく実行する。
そうして、結果的にKPIを改善する。

事前にソリューションを用意するには、対象の構造がわかっていることが大前提である。

長年している自分の仕事ならば、構造は手に取るようにわかる。
だが、そうでない場合はどうしたら良いのだろうか?

ロジックツリー〜企業参謀

大前研一氏の「企業参謀」で、ものごとの本質に早くたどり着くための方法として紹介されているのが、イシューツリーである。
世界で一般的には、ロジックツリー(Logic Tree)と呼ばれている。

本書が書かれたのは、1975年4月。
実に、半世紀も前に書かれたビジネス書であり、もはや古典の領域だが、時の重みに負けない名著である。
私が初めて『企業参謀』を読んだとき、
強く印象に残った場面がある。

それが、
「企業の利益を改善するには、どうすればよいか」
という問いに対して、
ロジックツリーを組み立て、原因を細分化しただけでなく、さらに必要な(と考えられる)分析事項に綺麗に落とし込まれていく過程だった。

いま読んでも、
ここまで十分に考えを落とし込めているか?不完全な自分に恥入りたくなる。

利益とは何か。
それは、売上からコストを引いたものだ。

では、売上を伸ばすにはどうするか。
価格を上げるか、数量を増やすか。

一方で、コストを下げるにはどうするか。
原価を下げるか、固定費を削減するか。

このように、
一つの問いを起点に、
論理的に、順序立てて分解していく。

イメージ:プロフィットツリーの出発点〜企業参謀
だが、ここで終わりではない。 販売量を増やすことについて、さらに市場の成長性、シェア拡大の可能性を論じ、さらにケースを細分化して、必要となる分析事項を決めていく。
イメージ:シェア拡大のためのプロフィット・ツリー〜企業参謀

例えば、「製品Aの適応市場をm以外に伸ばせるのか?」の問いに対して、必要となる分析事項の例として、

  • 地理的拡大の可能性
  • 最終ユーザー・セグメント拡大の可能性
  • 拡大のコスト・ベネフィットの比較

を提示している。

逆算し、拡散して考える

このように、ロジックツリーの場合は、解決すべき課題(イシュー)について、逆算して、構造化する。

似た有名なものに、トヨタ自動車の「なぜを5回繰り返す(WHY x 5」というものがある。
どちらも、KPIなどが示す表層の問題の本質的原因がどこにあるのか、掘り進めていく考え方である。
シンプルで、極めて直線的だ。
局所原因の特定には強いが、
構造的な広がりをあえて無視する点に注意したい。

逆算し、思考を拡散して、構造に落とし込むところに、ロジックツリーの強みがある。

どこまで掘り進めばいいのか

ただ、「WHY x 5」のメリットは、なぜ?を5回繰り返せばいいという、終了点が明確である点だ。
一方でロジックツリーでは方法論上の終わりを設定していない。

その気になれば、分解を延々と繰り返して、非常に微細な単位にまで落とし込むことはできる。あくまで理論上は。
しかし、それが有用なのか?となると話は違う。
無限にすべきことを増やしてしまうからだ。

効果の大きさに無頓着に、
できることを全てやったとしても、
その価値は最大化しない。

Doing more with less
(DMWL: より少ない労力で、より多くの成果を)
これは、常に意識したい原則だ。

イシューからはじめよ[改訂版]――知的生産の「シンプルな本質」の冒頭で、安宅和人氏はこう指摘する。

  • 「問題を解く」より「問題を見極める」
  • 「知れば知るほど知恵が湧く」より「知りすぎるとバカになる」
  • 「一つひとつを速くやる」より「やることを削る」

そして、氏は「犬の道」に踏み込むことに、大いなる警鐘を鳴らしている。
犬の道とは、「一心不乱に大量の仕事をすることで、バリュー(価値)をあげようとするルート」、すなわち、質を量でカバーするアプローチである。

TO-BEがなかなか見えないとき

あるべき姿、解決すべき課題が明確であるとき、逆算して考えるロジックツリーの破壊力は抜群である。
しかし、そもそもの根源的な問いが見つからないときは、全く役に立たない。

個別の事例、事実が多く集まっている
解決すべき状態だが、最終的にどうするべきか?
TO-BEを明確に描けない、言語化できない
こんな時、ロジックツリーは、全く役に立たない。

それはなぜなのか?
経験が浅い頃は、私も分からなかった。

TO-BEが言語化できない状態で、ロジックツリーを使おうとしても、
一番上に置く根本的な問いを間違えるばかりか、
個別の事例を解決すべき課題と早とちりし、
対症療法的な考察に陥りやすい。

木を見て、森を見ず
になるからだ。

ロジックツリーは、ボトムアップのための方法論ではない。
ロジックツリーは、トップダウンのための方法なのだ。

次の節では、ボトムアップの方法論を議論する。