プロシージャ

総論では、思考術をプロシージャとオラクルの二つで捉えると述べました。ここでは、思考の大半を進める側であるプロシージャを掘り下げます。直観側のオラクルはオラクルで扱います。

プロシージャとは?

ここで紹介するプロシージャは、学術的に体系化されたものではなく、筆者が現場で繰り返し使ってきた頭の使い方を、後から手順として取り出したものです。総論で退けたロジカルシンキングとの違いは、偶発的に出た一回の結果を整理したのではなく、何度も再現できている使い方だけを手順にしている、という点にあります。

すべての段階で同じ結果が出る、とまでは主張しません。たとえば「そのままでは難しい問題を二分木で分割する」という手順を取り上げると、何を軸に切るかは人によって違いますが、切ったあとに「Aである」と「Aでない」が漏れなく重ならずに並ぶ状態(MECE)は、形式論理学(話の中身ではなく形だけを見て、筋道が正しいかどうかを判定する分野)のレベルで保証されます。プロシージャの中には、こうした「ここだけは絶対にずれない」部分が組み込まれています。

プロシージャの始め方

基本的には、日常的な思考方法で手詰まりになった場合に開始します。
いくつかの型があって、適している場面は違いますが、どれもあらかじめ組まれたプログラムのように、自分自身の思考を制御します。
その理由は「本当に頭を使うべき箇所で使う」ためです。

型ごとの具体的な組み立ては、次の「プロシージャのパーツ」で部品を定義したうえで、後半の「プロシージャ例」で見ていきます。

プロシージャのパーツ

プロシージャは共通パーツの組み合わせで構成されます。ケースごとに使うパーツや組み合わせ方は変わりますが、パーツ自体は共通です。

生成操作

プロシージャの中で思考を1ステップ進める操作です。

通常連想

あるものごとから、誰でも自然に思い浮かぶ範囲のことを思い出す操作です。「売上」と言われて「客数」と「単価」が浮かぶような、無理のない想起で、プロシージャの大半はこれで進みます。特別な訓練はいりません。

徹底単純化

ふだんは「当たり前すぎて言うまでもない」と素通りしてしまう層まで、あえて踏み込んで考え直す操作です。考え直す操作そのものは手順ですが、出てきた前提を次にどう使うかは、各自のオラクルに委ねることになります。オラクルに委ねる部分が増えるほど結果はぶれるので、使いどころを十分に絞ってから発動します。

逆張り

いま正しいと思っている命題を、わざと否定してみる操作です。「この前提は本当に必要なのか」と引っくり返すことで、無意識に置いていた前提を表に引き出せます。暗黙の前提を見直したいときに使います。

データ構造

プロシージャの中で項目を入れておく場所です。実体は、場合分けを作る木(二分木)と、項目を並べる配列(リスト)の二系統だけです。配列は、中身を誰が処理するかで「後回しリスト」と「オラクル待機リスト」に呼び分けます。

二分木

一つの条件について「あてはまる(真)」と「あてはまらない(偽)」の二つに枝分かれさせ、その先でまた別の条件で枝分かれさせていく構造です。枝が二股に分かれながら伸びるので二分木と呼びます。真と偽で分ければ漏れも重なりも出ないので、大きな問題を最初に切り分けるときの基本の形になります。

後回しリスト

プロシージャがあとで処理する項目を並べておく配列です。すぐ処理する、後で処理する、別のプロシージャに渡す、といった違いはありますが、扱う主体はどれもプロシージャで、順番や送り先は制御構造の側で決めます。だから入れ物としては、この一種類のリストにまとまります。

オラクル待機リスト

オラクルが処理する項目を並べておく配列です。構造は後回しリストとまったく同じで、違うのは行き先だけです。プロシージャの手順では答えが出せず、直観に委ねるしかない項目をここに入れ、プロシージャを終えたあとにオラクル経由で展開します。プロシージャとオラクルの境目を示す印になります。

制御構造

プロシージャの流れを制御する仕組みです。

分岐

条件の真偽によって、次に進む先を分ける動きです。先ほどの二分木と組み合わせて、「真ならこちら、偽ならこちら」と進路を決めるときに多く使います。

ループ

同じ手順を、条件を満たすあいだ繰り返し走らせる動きです。一回では終わらない作業を、決まったやり方で何度も回したいときに使います。

再帰

ある手順の途中で、同じ手順をもう一度、入れ子の形で呼び出す動きです。大きな問題を、同じやり方で解ける小さな問題に分け、その一つひとつにまた同じ手順をあてる、というときに働きます。

探索終了

プロシージャを止める条件です。「答えが出た」「これ以上分けても意味がない」といった見切りをあらかじめ決めておき、際限なく考え続けてしまうのを防ぎます。

オラクル

プロシージャから呼び出す、直観や閃きの領域です。中身はプロシージャの外側にあります。

同期型オラクル

呼んだその場で答えが返ってくるタイプです。プロシージャを止めずに、流れの中でそのまま使えます。

非同期型オラクル

答えが返るまでに時間がかかるタイプです。その場で粘らず、いったん寝かせて別プロセスにし、あとで返ってきた答えを拾います。

運用としては、まず同期型でトライし、答えが出なければ非同期型に切り替えます。オラクル自体がどう動くかはプロシージャの外側の話で、プロシージャは「ここで呼ぶ」ことだけを記述します。

プロシージャ例

ここからは、これまでのパーツを組み合わせた例を、簡単なものから順に見ていきます。

例1:あるWebサイトに流入してほしいユーザーの分析

最初は、洗い出し系のいちばん基本的な型です。二分木を作っていくプロシージャで、何かを漏れなく洗い出したいときに向いています。手順は次のとおりです。

  1. 分割基準Aで一番大きい事象を「trueとfalse」に分割する(二分木を作る)
  2. 1のtrueに対し分割基準Bで二分木を作る
  3. 1のfalseに対し分割基準Bで二分木を作る
  4. 以降、分割不可能になるまで繰り返す

※2と3は必ずしも同じ分割基準でなくてもかまいません。

こうすると、少なくとも形式論理学的にはMECEが保証されるので、「考慮漏れ」をする可能性がかなり減り、自分の思考のバイアスに依らない発想も出やすくなります。これだけだと分かりにくいので、実例で効果を確認します。

あるWebサイトに「流入してほしいユーザー」、つまり集めたい見込み客の像を洗い出したい、という場面を考えます。通常の思考でいきなり考えると、「20代の女性」「予算を持っている決裁者」といった、その場で思いついた像が先に出てきます。これは想起の力任せで、抜けが出やすく、考える人のバイアスにも引きずられ、いわゆるMECEも保証されません。そこで、この型に従って二分木で切っていきます。

最初の分割基準(分割基準A)として、「自社の製品を知っているか?」を置きます。流入してほしいユーザー全体を、この問いの真偽で二つに分けます。

  • true:自社の製品を知っている人
  • false:自社の製品を知らない人
flowchart TD Q1{"自社の製品を知っているか?"} Q1 -->|"true"| Know["知っている人"] Q1 -->|"false"| Unknown["知らない人"]

この一段で、流入してほしい人全体が「知っている人」と「知らない人」に、漏れなく重ならずに分かれます。どちらかに必ず入り、両方に入ることはないので、形式論理学のレベルでMECEが保証されます。ここから、二つの枝をそれぞれさらに別の基準で分けていきます。

次の段では、左右の枝で違う分割基準を使います。手順の注(※)にあるとおり、左右の枝で基準をそろえる必要はありません。それぞれの枝にとって意味のある切り口を選びます。

「知っている」枝は、分割基準として「具体的に検討しているか?」を置きます。

  • true:自社の製品を具体的に検討している人
  • false:知ってはいるが、まだ検討していない人

「知らない」枝は、別の分割基準として「会社名かブランド名は知っているか?」を置きます。

  • true:製品は知らないが、会社名かブランド名は知っている人
  • false:会社名もブランド名も知らない、まったくの未接触の人
flowchart TD Q1{"自社の製品を知っているか?"} Q1 -->|"true"| Q2a{"具体的に検討しているか?"} Q1 -->|"false"| Q2b{"会社名かブランド名は知っているか?"} Q2a -->|"true"| Consider["具体的に検討している人"] Q2a -->|"false"| NotConsider["知っているが検討していない人"] Q2b -->|"true"| BrandKnown["会社名かブランド名は知っている人"] Q2b -->|"false"| NoContact["まったくの未接触の人"]

枝ごとに基準を変えながら分けていくと、最初の思いつきでは出てこなかった「知っているのに検討していない層」や「社名だけ知っている層」といった像が、漏れなく表に出てきます。それぞれが、Webサイトで何を伝えるべきかの異なる相手になります。

ここから先は、すべての枝を一様に深掘りする必要はありません。一番左の「具体的に検討している人」は、特に工夫しなくても獲得できる層なので、ここではいったん置きます。代わりに「知っているのに検討していない人」を一段深掘りします。たとえば「1年以内に検討するか?」で分けると、近いうちに動く人と、当面は動かない人に分かれます。こうして深掘りを進めるほど、最初の漠然とした「流入してほしいユーザー」よりも、それぞれの層が打ち手と具体的に結びついてきます。どの層に、いつ、何を見せて後押しするか、という次の検討に渡せる形になっていきます。

例2:取引先からの発注額の減少

不足している情報をもとに「問題の原因」を探すケースです。

  • 取引先からの発注額が最近減少していて、その原因を考える場合
  • 取引先の業績悪化などのわかりやすい情報はない
  • 担当者とは普通にやりとりできている

原則の定義

  1. 簡単な思考を優先する。通常連想で行き詰まったら徹底単純化に切り替える
  2. 二分木で場合分けする(条件分岐)
  3. 探索時の判断(条件の作成や、二分木以外の分け方)は1の基準で行う
  4. 深掘りが困難な箇所のうち、手順で進められるものは後回しリストに、手順では答えが出せないものはオラクル待機リストに追加する
  5. 1〜4を再帰的に繰り返す
  6. 1の基準で進める探索がなくなったら探索は終了
  7. 後回しリストに残った項目は別プロシージャに渡し、オラクル待機リストに追加した項目はオラクル経由で展開する(このプロシージャの範囲外)

一番最初に思いつくことが起点

担当者に聞けばいいというのが、最も単純な手段として最初に挙がります。これを起点に置きます。ここから「聞ける/聞けない」の二分木が自然に立ち上がります。

担当者に聞ける場合

聞ける状態に対する通常連想は、「原因を直接聞くこと」です。実行した結果に対して二分木が立ち上がります。

  • true:聞いて原因が分かる → 直接解
  • false:聞いても分からない → 次の通常連想として「担当者より上の人に聞けるか」が立ち上がる

「上の人に聞けるか」以降は同じ構造の再帰になります。聞ける/聞けない、聞いて分かる/分からない、を聞き手を変えながら繰り返す形です。聞き手を変える通常連想が出尽くしたところでこのルートは終了です。

担当者に聞けない場合

直接、答えを知っていそうな人に聞けない場合の通常連想は、「自分で考える」の二分木です。

  • true:自分で考える → ルートを進める
  • false:自分以外に考えてもらう → 聞く系と同じような再帰なので後回しリストに追加

自分で考えるルート

自分で考える場合の通常連想は、「自分が把握できる事実」をリストアップすることです。これは判断を要する分岐の生成ではなく、作業として実行します。

自分が把握できる事実リストアップ

作成したそのリストを眺めて、その中にパッと分かる原因があるかどうかを判定します。

  • true → 確からしいものが出ているので探索を終了。事実検証を別プロシージャの起点として後回しリストに渡す
  • false → 「通常連想では答えが出ない」が推論で確定。このケースを展開する

「パッとは分からない」ケースの展開

このケースには、同じプロシージャの型を再帰的に当てはめます。ただし、ここからは事実ベースの判定が難しくなり、仮説ベースの軸が混じります。原則は同じように進めますが、このケースは起点の都合上「通常連想では答えは出にくい」と確定しているので、ここで原則1の徹底単純化に切り替えます。

すると、「そもそも、自社で変えられる原因なのかどうか?」という分岐が出てきます。

  • true:変えられる → 進める
  • false:変えられない → 原因が究明されても対処できないため、探索対象外として切り捨てます

原因は自社で変えられる可能性のみ探索

再び徹底単純化を発動します。普段は無視してしまうレベルまで単純化して問い直すと、別の方向性が見えてきます。

  • こちらから発注減を依頼していた
  • こちらが値下げしていたので金額が合わない
  • 自社の中で他の商品と代替されている
  • そもそも納品していなかった

これらは「商品の内容」や「他社との競争」というカテゴリ以外の可能性を示します。インサイトとして取り出します。これらの深掘りはもはやプロシージャでは届かない領域に入るため、オラクル待機リストに追加してこのプロシージャを終了します。

プロシージャとオラクルの共存

通常連想で流れの大半を駆動し、終端近くの絞り込まれた箇所で徹底単純化が発動する構造になっています。徹底単純化で出てきた可能性の深掘りは、オラクル待機リストに入れてオラクルに委ねています。プロシージャとオラクルがどう共存するかの一例として読めます。

フローチャート

flowchart TD Start["起点: 担当者に聞けばいい<br>最も単純な手段"] Start --> Q1{"担当者に聞けるか?"} Q1 -->|"聞ける"| Ask["原因を直接聞く"] Ask --> Q2{"聞いて原因が分かるか?"} Q2 -->|"true"| Direct["直接解"] Q2 -->|"false"| Higher["上の人に聞けるか<br>聞き手を変えて再帰"] Higher --> AskEnd["聞き手の通常連想が<br>出尽くしたら終了"] Q1 -->|"聞けない"| Q3{"自分で考えるか?"} Q3 -->|"false"| Others["自分以外に考えてもらう<br>後回しリストに追加"] Q3 -->|"true"| Think["自分で考えるルート"] Think --> List["把握できる事実をリストアップ<br>判断ではなく作業として実行"] List --> Q4{"パッと分かる原因があるか?"} Q4 -->|"true"| FactCheck["探索終了<br>事実検証を別プロシージャの起点へ"] Q4 -->|"false"| NoEasy["通常連想では答えが出ないと推論で確定<br>このケースを展開"] NoEasy --> Simplify["原則1の徹底単純化に切り替え"] Simplify --> Q5{"自社で変えられる原因か?"} Q5 -->|"false"| Cut["対処できないため<br>探索対象外として切り捨て"] Q5 -->|"true"| Explore["自社で変えられる可能性のみ探索"] Explore --> Simplify2["再び徹底単純化を発動"] Simplify2 --> Insight["インサイトを抽出<br>発注減の依頼 / 値下げ /<br>社内での代替 / 未納品"] Insight --> Oracle["オラクル待機リストに追加<br>プロシージャ終了"]

例3:新規取り組みの立ち上げ

漠然とした状態から「手段」を決めるケースです。

  • 経営会議で、ある事業課題(顧客離れ、業績の伸び悩み、新規領域への進出など)に対応するため、新しい取り組みを立ち上げる方針が決まった
  • 何を立ち上げるかの中身はまだ決まっていない。目的と方向性だけが合意されている状態
  • 何から手をつけるか、どう進めるかを、これから考える

原則の定義

  1. 通常連想で「やらないこと」を導出し、可能性から除外する
  2. 残った可能性に対して、通常連想で「ベタな発想」をリスト化する
  3. リストの各項目に徹底単純化を適用し、暗黙の前提を抽出する
  4. 抽出した暗黙の前提の逆張りを、オラクル待機リストに追加する
  5. リストの全項目を処理したら探索終了
  6. オラクル待機リストに残っている項目は、オラクル経由で展開する(このプロシージャの範囲外)

「やること」ではなく「やらないこと」を決める

このプロシージャは、アイデアを出すためでなく、余計な可能性を除外して「考えなくていい範囲」を特定し、考えるべき部分にオラクルを集中投入するための下準備のプロシージャです。

まずは通常連想で可能性を除外

前提条件の上で、意味のないものは最初に除外します。
例えば下記のようなものです。

  • 予算がない場合 → 予算で解決する系の手段は除外
  • 既存資産を活かす方針の場合 → 完全にゼロから始める事業は除外
  • 方向性が決まっている場合 → その方向性と違うものは除外

次に一般的な事例などを除外

他社や一般的な事例などは除外します。
状況が違う場合にそのまま効果が出る可能性は低いですし、
検討材料に含めるとしても、それは「手段を考える」というよりは「手段を検討する」別のプロシージャです。

  • 世間的によく知られた一般的な事例 → 除外
  • 他社の事例 → 除外

自社の過去施策も除外

自社で過去に行った施策は手段としては既出なので、除外します。
また、失敗している場合は特に「手段の再検討」という別のプロシージャです。

  • 自社の過去の施策 → 除外

絞り込まれた可能性の中で通常連想を行う

ここまででやるべきことが、下記の例のように大まかな条件事項という形で絞り込まれているはずです。

  • 完全に新規の施策である
  • 予算に頼らない
  • XXXをYYYする
  • etc.

この制限をもとに、通常連想を行います。
この場合は「ベタな誰でも思いつく発想」で構いません。
その連想を、機械的に思いつく限りリストアップします。

ベタ発想から暗黙の前提を抽出する

リストアップした先ほどの発想に対して、ひとつずつ「徹底単純化」の思考で「その発想の暗黙の前提は何か」を考え、これをリストアップします。

例として、「最新のスマホアプリでこれを解決」というベタな発想に対する暗黙の前提は次のように整理できます。

  • この問題を解決する必要がある
  • スマホアプリで解決できる
  • スマホアプリが作れる
  • みんながスマホを持っている

暗黙の前提とは、このように所与として扱われていて、未検討の可能性が高い前提のことです。
これらの中に、新たな発想のヒントがあります。

暗黙の前提の逆張りをオラクル待機リストに追加

抽出した暗黙の前提の「逆張り」を逐一検討します。その場で発想や洞察が出る可能性は低いので、その場合はオラクル待機リストに追加します。

前述の例の続きでは、以下のような項目をオラクル待機リストに追加します。

  • この問題を解決する必要がある → そもそも解決しなくてもいい可能性は
  • スマホアプリで解決できる → スマホアプリは必要か
  • スマホアプリが作れる → スマホアプリを作らないでいい可能性は
  • みんながスマホを持っている → スマホを持っていない人にはどうするか

このプロシージャでは、ここで探索は終了です。

フローチャート

flowchart TD Start["起点: 目的と方向性だけが<br>合意された状態"] Start --> Ex1["通常連想で前提に反する可能性を除外<br>予算で解決する系 / ゼロから始める事業 /<br>方向性と違うもの"] Ex1 --> Ex2["一般的な事例を除外<br>世間でよく知られた事例 / 他社の事例"] Ex2 --> Ex3["自社の過去施策を除外"] Ex3 --> Narrow["やるべきことが大まかな条件として絞り込まれる<br>完全に新規 / 予算に頼らない / etc."] Narrow --> Assoc["絞り込まれた範囲で通常連想<br>ベタな発想を機械的にリストアップ"] Assoc --> Loop{"リストに未処理の発想があるか?"} Loop -->|"ある"| Simplify["徹底単純化で<br>その発想の暗黙の前提を抽出"] Simplify --> Reverse["暗黙の前提の逆張りを<br>オラクル待機リストに追加"] Reverse --> Loop Loop -->|"ない"| End["全項目を処理したので探索終了"]

パーツは読者が組み立てるもの

ここまで挙げたパーツは、あくまで部品です。具体的にどう組み合わせて、どんな問いに対してどう走らせるかは、読者自身が自分の用途に合わせて組み立てる部分です。ここまでのプロシージャ例も、組み立て方の一例として読んでもらえれば十分で、覚えるためのものではありません。自分の現場で繰り返し使う問いに対して、自分のプロシージャを組み立てる、というのが本来の使い方です。