# 考える技術・書く技術

## 概要

### 本

* [考える技術・書く技術―問題解決力を伸ばすピラミッド原則 | バーバラ ミント, 山崎 康司](https://amzn.to/3da5xxu)

### かかった時間

* 12.8 時間

### 感想

* 読みづらいのと、内容もそこそこ難しいので読む人を選びそうな本だった
* 読み手に寄り添うために、どういうことに気をつけなければならないかというのがたくさん書かれているが、意識していない or 甘いものもたくさんあったので、そこは勉強になった

## 読書メモ

## 第Ⅰ部: 書く技術

### 第 1 章: なぜピラミッド構造なのか?

* 読み手の作業を楽にするため
  * ピラミッド型の展開は、読み手の頭の中で起こる基本的なメカニズムを反映している

#### ピラミッド型へ並べ替える

* 人間は頭の中で、自動的に一定の規則に従って情報を整頓しようとする
  * 最初に、関連性を持つ物事を同じグループとして認識しようとする
  * 次に、グループ内の関連付けの論理を具体的にする
* この 2 つがあらかじめできている文章だと読みやすい

#### トップダウンに配列する

* まず全体を要約する考えを述べ、そのあとに個々の考えをひとつひとつ説明していく
* 読み手はトップダウンに考えを記憶しようとする。トップダウンで書き手の考えが示されていれば、読み手はより容易に理解できるようになる

#### ボトムアップで考える

* **ピラミット構造の 3 つの鉄則**
  * **どのレベルであれ、メッセージはその下位グループ群を要約するものであること**
  * **各グループ内のメッセージは、常に同じ種類のものであること**
  * **各グループ内のメッセージは、常に論理的に順序付けられていること**
    * 論理的な並べ方は 4 つの方法しかない(詳細は 6 章)
      * 演繹の順序(大前提、小前提、結論)
      * 時間の順序(1 番目、2 番目、3 番目)
      * 構造の順序(北から南、東から西、など)
      * 重要度の順序(1 番重要なもの、2 番目に重要なもの、など)

### 第 2 章: ピラミッドの内部構造はどうなっているのか?

* **ピラミッド内部の関連性**
  * **メッセージは縦方向に関連性を持つ(Q\&A 形式)**
  * **メッセージは横方向に関連性を持つ(帰納法 / 演繹法)**
  * **頂上ポイントは読み手の疑問に答える**
  * **導入部は読み手に疑問を思い出させる**

#### 縦の関係

* 縦の関係を通して、Q\&A(質疑応答)の対話形式で答えの理由付けを行っていく
  * あなたのメッセージは必ず読み手に疑問を生じさせなくてはならず、その疑問は 1 段下のレベルで横並びで答えられなくてはならない
* また、縦の関係を眼に浮かべることで、自然と自分の考えを整理できる

#### 横の関係

* 1 段下のラインで何を言うかを決めるためには、それらのポイントが上位ポイントの疑問に対して、単に答えるだけでなく、論理的に答えることが必要
  * すなわち、帰納的論理か演繹的論理か、どちらかの方法を用いて論理的に答えなければならない。両方をまぜこぜにしてはいけない

#### 導入部のストーリー展開

* 読み手の文章への興味を確実なものにするために、導入部で疑問の本質をはっきりさせることが必要
  * 古典的なストーリー展開を用いる
* 古典的なストーリー展開
  * 状況: まず状況の時間と場所を設定する
  * 複雑化: 状況の中で何かが起きる
  * 疑問: この複雑化によって、読み手は疑問を抱く
  * 答え: 疑問に対して、あなたの文章が答えを与える

### 第 3 章: ピラミット構造はどうやって作るのか?

#### トップダウン型アプローチ

* 手順は p30 に詳細の記載あり
* **ピラミッドを作る**
  * **主題(テーマ)を明らかにせよ**
  * **「疑問」が何かを決めよ**
  * **「答え」を書いてみよ**
  * **「状況」と「複雑化」によってその「疑問」が導かれるかどうかをチェックせよ**
  * **「答え」が妥当かどうかをチェックせよ**
  * **キーラインを埋める作業に取りかかれ**

#### ボトムアップ型アプローチ

* 3 つのステップ
  * あなたが言いたいポイントをすべてリストアップしてください
  * それらのポイント同士にどんな関係があるか考えてください
  * そこで結論を導いてください

#### 初心者への注意

* まず、トップダウン型に考えを構成することから始めなさい
* 導入部を考える際には、「状況」をそのスタートポイントとして利用しなさい
* 導入部を考えることを省略してはなりません
* 過去の出来事は常に導入部に書きなさい
* 導入部の記述は、読み手が合意する事項に限定しなさい
* もし選べるのであれば、キーライン・レベルでは演繹法よりも帰納法を用いなさい
  * 帰納的説明のほうが演繹的説明よりも読み手にとって負担が少なく、理解しやすい

### 第 4 章: 導入部はどう構成すればいいのか?

* **導入部を書く**
  * **「状況」を述べよ**
  * **その状況で「複雑化」が発生し**
  * **その複雑化が「疑問」を引き起こし**
  * **その疑問に対し、あなたの文書が「答え」を出す**

#### ストーリー形式

* 冒頭の導入部は、伝えたいメッセージ構造の外側、ピラミッド頂上部を囲む円と考えることができる(P48)
* なぜストーリー形式なのか?
  * 読み手の頭の中の雑念を追い払い、あなたの伝えようとすることに集中しやすくする、そのような仕掛けを読み手に提供する必要がある
  * 導入部で、読み手の頭の道順を効果的に支配する
  * また、読み手が合意できるポイントからはじめることで、読み手はあなたの考えに対してより柔軟な態度をとれる
* 「状況」の記述をどこから始めるか?
  * 「状況」の記述は、主題に関する記述からはじめる
  * これは読み手が合意するだろうとわかっていることでなければならない
* 「複雑化」とは何か?
  * 導入部の「複雑化」とは、多くの場合「問題」ととらえてかまわないが、厳密に言えば異なる
  * あなたが伝えようとしている物語の中で起こる状況の「複雑化」であり、これが緊張を発生させ、疑問の引き金となる
* 「状況 - 複雑化 - 解決」という構成は不可欠だが、順番は変えても良い
* 「キーライン」とは?
  * ピラミッドの「キーライン」の役割は、「主ポイント」に対して発せられる新しい「疑問」に答えを与えられるだけでなく、文書内容の展開を明らかにすることでもある
* 導入部の長さは?
  * 導入部は、読み手をあなたの考えへ導く前に、あなたと読み手が「同じ土俵に立っている」ことを確信できるくらいの長さがあれば十分
  * なので、導入部の長さは、その後に続く本文の長さとは必ずしも関係があるわけではない
  * むしろ、読み手の必要性と関係がある
* キーラインに導入部は必要か?
  * 本文の導入句と同じように、それぞれのキーラインポイントにも導入部分があるべき
  * 本文の導入句に比べればかなり簡略化する必要があるが、同じく「状況 - 複雑化 - 解決」の手法を用いる
* **よい導入部を書くための理論(まとめ)**
  * 導入部とは、知識を与えるためのものではなく、思い起こさせるためのもの
    * 導入部に内容が妥当かどうか説得しなくてはならないようなものを含んではいけない
  * 導入部にはストーリーの 3 要素を常に含ませる
    * 状況・複雑化・解決
  * 導入部の長さは読み手の必要性と文章のテーマによる

#### いくつかの共通パターン

* 読み手の「疑問」には、いくつかの共通パターンがある。結論から言うと、あなたの書く文書は原則として次の 4 つのいずれかの疑問に答えようとしている
  * 我々は何をすべきか?
  * 我々はそれをどのように実行すべきか?
  * 我々はそれを実行すべきか?
  * なぜそのようなことが起きたのか?
* 実際の文書を見ると「何をなすべきか?」について書かれたものが多い。よく見かけるのは以下の 4 つのパターン
  * 方針を与える(何をすべきか? あるいは、どのように実行すべきか?)
    * 状況: 我々は X をしたい
    * 複雑化: あなたに Y をしてもらう必要がある
    * 疑問: どのようにして Y を行うか?
  * 支出の承認を求める(それを実行すべきか?)
    * 状況: 我々は問題を抱えている
    * 複雑化: 我々は解決方法を有しているが、それには...ドルの出費がかかる
    * 疑問: 私は承認すべきか?
  * 「ハウツー」を説明する(それをどのように実行すべきか?)
    * 状況: 行動 X を実行しなければならない
    * 複雑化: そのための体制ができていない
    * 疑問: どのようにしてその体制を作るのか?
  * 選択肢の中から決定する(何をすべきか?)
    * 状況: 我々は X をしたい
    * 複雑化: そうするために、いくつかの選択肢がある
    * 疑問: どの選択肢が最も適切か?

#### いくつかの共通パターン...コンサルティングの場合

* 「提案書」と「進捗状況報告書」の例あり

### 第 5 章: 帰納法と演繹法はどう違うのか

* **論理的に理由づける**
  * **演繹法は一本の理由づけラインで展開する**
  * **帰納法は類似の考えや関連する行動をグループ化する**
  * **キーラインレベルでは、帰納法の方が演繹法よりも望ましい**

#### 演繹的理由づけ

* 考えを深める上で有効である反面、書くという側面から見れば多少重苦しい方法とも言える
* 演繹的理由づけとは、以下の 3 つの要件を満たすもの
  * まず世の中に実在する状況について述べる
  * 次に、同時にもうひとつ世の中に実存する関連状況について述べる。この記述は、最初の記述の主部か述部のどちらかについて注釈することで、最初の記述と関連を持つことになる
  * 同時に世の中に実存する上記 2 つの状況が意味することについて述べる
* 例
  * 人間はいつか死ぬ
  * ソクラテスは人間である
  * それゆえに、ソクラテスはいつか死ぬ
* キーラインのレベルでは、帰納的に書くほうがよいケースが多い
  * 読み手が議論に関心があることはまれで、基本的には行動に関心がある
  * ただし、演繹的に書くほうがよいケースもある
    * 事前の説明なしには、読み手が提案行動を理解できない場合など
* キーラインより下部のレベル(同一段落内のポイントレベル)では、演繹法が有効な場合も多い
* 注意
  * 演繹的理由づけでつなぐポイントは 4 つまでとする
  * 「それゆえに」ポイントは 2 つまでとする

#### 帰納的理由づけ

* 帰納的理由づけでは、いくつかの異なるものが何らかの点で似ていることに気づき、それらをひとつのグループにまとめ、その類似点の意味について意見を述べる
* キーとなるテクニックは「メッセージをグループ化して 1 語で表すこと」
* 次に必要なのは、ボトムアップで質問を繰り返しながら理由づけをチェックすること

## 第Ⅱ部: 考える技術

* キーラインの一段下のレベルまで作り終えたら、ひとまず書き始めることをおすすめする

### 第 6 章: ロジックの順序に従う

* 頭の中でグループ分けのために行った分析活動を配置の順序に反映させることが必要
* **論理的順序の種類**
  * **時間の順序**
    * ある結果の原因を特定する
    * 順序: 時間の順序
  * **構造の順序**
    * 全体を部分に分ける
    * 順序: 構造の順序
  * **重要度の順序**
    * 類似のもので分類する
    * 順序: 重要度の順序(度合いの順序)
* これら 3 つの順序づけは 1 種類のみを適用しても、あるいは組み合わせで適用してもかまわない
* また、順序をチェックしてみることで、グループ化の妥当性をチェックできる

#### 時間の順序

* 時間順に並べるということは、ある特定の結果を達成するために必要なステップを、実行に移す順番に記述していくことを意味する
* これは以下のどちらかとなる
  * 実際の行動ステップそのものか、行動の考えの種類(例: 提案、目的)
    * 原因と結果を区別し、因果関係を明確にしないとわかりにくくなってしまう
  * 頭の中に描いたあるプロセスから導かれるいくつかの結論
    * 自分の考えの根拠となっているプロセスをはっきりと認識していないと、わかりにくくなってしまう

#### 構造の順序

* 構成する各部分がはっきりと、かつ適切に区分されていることが必要
  * 構造を作る時は MECE になっていなければならない
* 時間の順序で見たのと同じように、構造の順序のコンセプトを、グループ内の論理欠陥チェックに利用することもできる

#### 重要度の順序

* 共通の特徴を持つものを類似のものとして分類し、グループ化した時に用いるもの
* 正しい分類グループを作る
  * 「この会社には 3 つの問題がある」という時には、「ダブリ」がないことを確実なものとするために、共通して持っている特徴を具体的にすることから始める
  * 次に、その特徴を持っている項目をすべてグループに含んだかチェックする
  * 最後に、その特徴を備えている強さの度合いに従って、それぞれを配列する

### 第 7 章: グループ内の考えを要約する

* ピラミッドプリンシプルの第 1 の鉄則「どのレベルであれ、メッセージはその下位グループ群を要約するものであること」
  * 演繹的なグループ化の場合、上部の要約メッセージは容易に導かれる
    * 下部メッセージの結論部分に大きく寄りかかったものになるため
  * 帰納的なグループの場合には、要約のメッセージは下部メッセージの関連性が何を意味するか述べないといけない
    * これは「考えるプロセスを完成させる」最終ステージともいえる
    * これができないと、いわゆる「白紙の主張」で終わってしまう

#### 白紙の主張を避ける

* 正しい要約のメッセージを導くことで、さらに思考が進められる
  * **白紙の主張では、考えの不完全さが隠れてしまう**
* 帰納的理由づけの場合、ポイント(下位メッセージ)は以下のどちらかとなるはず(p138)
  * 読み手に「何かをせよ」という行動の記述
    * 要約メッセージは、一連の「行動の結果」
  * 読み手に「何かについて」説明する状況の記述
    * 要約メッセージは、一連の考えから「推測される結論」
* ↑読み手に伝えることは、読み手に何かをすべきだと伝えるのか、何かがこういう状況だと伝えるかのどちらかであるため

#### 行動の結果を述べる

* 問題となるのは、グループ内の各行動は、グループ全体としてひとつの結果を達成するということを除くと、それほど大きな関連性を持っていないという点
  * したがって、ある目的達成のために必要な行動をリストする場合、不足している行動がないかチェックするには、リストされた行動で何がもたらされるかを考えるしか方法はない
* ↑の整理が大変。わかりやすく表現するためのテクニックは以下
  * **それぞれの行動をできる限り「具体的な」言葉で表現する**
  * **グループ化を「明白な」因果関係で構成する**
  * **結果の記述は、一連の行動から「直接」得られるものを書く**
* 具体的な言葉を使う
  * 具体的な結果だと、グループ化に漏れがないかのチェックがやりやすくなる
  * 読み手にとっても、イメージが描きやすく、文書が面白くなる
* 行動のレベルを階層化する
  * あまり深く考えずに、原因と結果を同じレベルで組み合わせてしまうことが多い
  * したがって、行動のレベルを意識的に階層化し、各レベルのステップ数を 5 つ以下に制限するとよい
* 直接的に要約する
  * ここまででプロセス内のステップをグループ化できた。ここは全体の結果を要約し、表現する部分
  * 2 つの原則
    * グループ化は MECE で行う
    * 要約は、行動を実行して直接得られる結果を、最終結果物をイメージできる言葉で表現する
  * グループ化作業が終わったとき、上の 2 つの視点で自分の考えをチェックする

#### 各結論に類似点を見つける

* 状況の考えの場合、各ポイントは(理由や問題点や結論などの)同じ種類の表現になる
* やらなければならないのは以下の 3 つ
  * **考えを結びつける構造上の類似点を見出す**
  * **類似点の中により深い関連性を見出す**
  * **要約のポイントレベルまで帰納的なジャンプをする**
* 構造上の類似点を見出す
  * 考えのグループ化の元になる共通特性は、通常、以下のいずれかの形で表れる
    * 各ポイントの文章が同じ種類の主部を論じている
    * 各ポイントの文章が同じ種類の述部を論じている
    * 各ポイントの文章が同じ種類の判断を意味している
  * ここでいう「同じ種類」とはまったく同じものという意味ではない。同じ分類に属するという意味
  * グループ化した考えに、明確な関係を見出せない場合、それはグループ化自体がおかしいことを示唆する
* より深い関連性を見出す
  * 類似点を見つけてグループ化したあと、「なぜ他の問題を取り出さなかったか?」「書き手にこれらをグループ化すべきと判断させた関連性は何か?」を考えることによって、書き手が頂上に書くべき要約も洗練される
* 帰納的なジャンプをする
  * まれに良くない文書において、類似点が意味するものが一体なんなのかわかりにくい場合がある
  * その場合、全体の文脈から自己的に帰納的なジャンプをして、上位理論を推定するほかない
  * 自分が文章を書くときはこの様なことが起こらないよう、しっかりと順序と関連性を持った帰納的グループを構成すべき

## 第Ⅲ部: 問題解決の技術

* 質問に対して答えを出す文書の思考プロセスは、理想的には以下の流れになる
  * 問題を定義する
  * 分析を構造化する
  * 分析を実施し、解決策を見出す
  * 考えを伝えるためにピラミッドを作る

### 第 8 章: 問題を定義する

* 問題が存在すると判断するとき、通常あなたは、今までの延長線上の結果と本来望んでいた結果の間にギャップを感じるはず
  * この「望ましくない結果」からどう「望ましい結果」に到達するかを伝えるのが「解決」
* 連鎖分析のプロセス
  * 問題を定義する
    * 1: 問題がありそうか?
    * 2: 問題はどこにあるのか?
  * 分析を構造化する
    * 3: 問題はなぜ存在するのか?
  * 解決を発見する
    * 4: 問題に対し何ができるか?
    * 5: 問題に対し何をすべきか?

#### 問題定義のフレームワーク

* 以下の質問に答えることができれば、問題は適切に定義されているといえる
  * 今、何が起きているのか?
    * 状況 = スタートポイント / オープニング + 懸念される出来事
  * 今の何が好ましくないのか? = R1
  * 代わりに何を望んでいるのか? = R2

#### 問題を配置する

* **正しく問題を定義し、解決案を生み出す第一歩を踏み出すためには、4 つの要素を特定する必要がある**
  * **スタートポイント / オープニング**
  * **懸念される出来事**
  * **R1(望ましくない結果)**
  * **R2(望ましい結果)**

#### 疑問を見出す

* 7 つの標準的な問題状況
  * 最も一般的な状況
    * 1: 読み手が R1 から R2 へ移行する方法を知らない
    * 2: R1 から R2 へ移行する方法をわかっているつもりだが、確信がない
    * 3: R1 から R2 へ移行する方法をわかっているが、その解決案をどのようにして実行していけばよいのかがわからない
  * 一般的状況の変形
    * 4: 読み手は R1 から R2 への移行方法を知っていると考え実行に移したが、その解決案はなんらかの理由によりうまくいかなかった
    * 5: いくつかの解決案を考えたが、そのうちのどれを実行すべきかわからない
  * 一般的ではないがあり得る形
    * 6: 読み手は R1 をわかっているが、解決案を生み出すほど R2 を明確にできない
    * 7: R2 はわかっているが、いま自分たちが R1 なのかどうかがはっきりしない

#### 導入部へ展開する

* p186 以降に記載あり

### 第 9 章: 問題分析を構造化する

#### データ収集から始める

* 1950 〜 60 年代のコンサルティング会社は、データ収集から始めるのが一般的だった
  * しかし、これでは膨大な資料の山に埋もれてしまい、意味のある結論を導くのが難しかった
  * ここで、データを収集する前に問題分析を構造化するという考えが生まれた
* やり方
  * いくつかの仮説を設定する
  * 誤った仮説を捨て、正しい仮説を選定できるように、仮説の実験装置を考案する
  * 仮説を説明する明確な結果が得られるまで実験(妥当性のチェック)を繰り返す
  * 証明された仮説にもとづき、望ましい行動を提案する

#### 診断フレームワークを作る

* 構造を図式化する
  * そのシステムが機能している状況、または本来機能すべき状況を図示すれば、その図に沿って答えるべき疑問を見出し、分析すべき問題原因を見出すことができる
* 因果関係をたどる
  * 特定の結果から因果関係の要素や活動をたどってみる
  * 1: 財務の構造
  * 2: タスクの構造
  * 3: 活動の構造
* 有りうべき原因を分類する
  * 事前にグループ化することで、バラバラの事実を統合しやすくする

#### フレームワークを利用する

* **診断フレームワークを作るのに必要なデータのみを収集することから始め、まずはそのフレームワークの中で現状の業務構造や関連性を明らかにすることに徹するべき**
  * すると問題原因について確度の高い推測ができ、その後でその推測が正しいことを証明するためにどのような情報が必要か考える
  * そして、その情報に的を絞り、データ収集の努力を集中すればよい

#### ロジックツリーを作る

* 解決の選択肢を明らかにする

## 第Ⅳ部: 表現の技術

### 第 10 章: 文書構成にピラミッドを反映させる

#### 構造を強調する

* 各キーラインポイントのサポートメッセージが 1 つだけのパラグラフで構成されるような短い文章の場合
  * 文書全体のポイント構成や関連性が、読み手にとって比較的簡単に伝わりやすい
  * なので、下線を引くなどして、文字通りポイント構造が目に飛び込んでくるようにするとよい
* 各キーラインポイントが 2 つ以上のパラグラフで構成されるような長い文章の場合
  * 最初にポイント紹介を行い、その後に見出しを用いて展開するのがよい
* ヒエラルキー型見出し(例は p239 にあり)
  * 注意点
    * それぞれのレベルで見出しがひとつだけで終わってはならない
    * 類似の考えはパラレルに表現する
    * 見出しは、考えの本質を表現するにとどめる
    * 見出しを文脈の一部としない
    * 見出しの各グループを事前に紹介する
    * やりすぎない
* ポイントのアンダーライン
  * いくつかの厳格なルールを守らねばならない
    * 完璧な規律に従って、Q\&A 論理を適用しなければならない
    * ポイントの表現には最大の注意を払い、できるだけ簡潔にメッセージを述べなければならない
    * 徹底的にポイントの絞り込みを行い、演繹法または帰納法的論理展開に必要な記述に制限する
* その他の方法
  * 数字インデックス
  * インデントによる右寄せ
  * ドット・ダッシュの箇条書き

#### グループ間の移行を助ける

* 長い文書になると、主だったグループの初めか終わりで定期的に休憩場所を設け、今どこにいるのか、次にどこへ行こうとしているのかを、読み手がわかるようにしてあげなければならない
* 方法
  * ストーリーを語る
  * 前を振り返る
  * 章や節を要約する
  * 全体を締めくくる
  * 次のステップを述べる

### 第 11 章: 文章表現にピラミッドを反映させる

#### イメージを創り出す

* 明確な文章を書くためには、自分がこれから述べようとすることをまず「見る」ことから始めなくてはならない
* このイメージ化を心がけるだけでも、言いたいことが明確になる

#### イメージを言葉にコピーする

* 頭の中にある考えの関係を、あえて眼に見えるように書いてみることが、わかりやすい表現をするための秘訣
* 頭の中にはっきりとしたイメージを持つことができれば、それをそのまま明確な文章に置き換えることができ、読み手はそれをそのまま理解し、把握することができる


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://y-meguro.gitbook.io/reading-record/other/the_pyramid_principle.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
