Work > 思考法・問題解決 on M1KE BL0G

Post-Incident Processing

Mon, 24 Aug 2026 18:00:00 +0900

Background

When a problem happens in daily life, everyone reacts and deals with it in the moment
But preparing beforehand, and reflecting afterward once it’s resolved, tend to get neglected
This post organizes a way of thinking that turns what happened into a lasting lesson, instead of letting it fade away

Classifying Problems

By cause

Problems can be split into two types based on where the cause lies.

Problems you directly caused
- Problems where your own mistake or judgment was the direct cause
Problems that originated from someone else
- Problems where something outside you (another person, the environment, a system) happened and ended up affecting you

Three phases by timing

Dealing with a problem can be split into three phases along the timeline.

Phase	Content
Prevention	Taking action before the problem happens
In-the-moment response	Responding on the spot while the problem is happening
Post-incident review	Reflecting and preventing recurrence after the problem has settled

Why prevention and review get neglected

People react strongly and take action the moment a problem occurs
But prevention for a problem that hasn’t happened yet rarely gets prioritized, and tends to be put off
Once the in-the-moment response is over and the problem has settled, people feel satisfied, and the post-incident review (reflection, recording, prevention) tends to be left undone
As a result, similar problems keep happening again and again in different forms

The 4R Framework for Post-Incident Review

A framework of four questions for making sure post-incident review doesn’t get skipped
Named 4R after its four items
Based on the After Action Review (AAR), a method established in US Army training doctrine
- AAR is built around four questions: “What was supposed to happen?”, “What actually happened?”, “Why was there a difference?”, “What can we learn from it?”
- The 4R here reworks that into four items for handling everyday problems after the fact

#	Item	Question
1	Report	What happened?
2	Reason	Why did it happen?
3	Respond	How did you respond?
4	Prevent Recurrence	How will you prevent it from happening again?

Report: What happened?

First, record the facts of what happened, objectively
Write down when, where, and what happened, without speculation

Reason: Why did it happen?

Dig into the cause behind the facts written in Report
For a problem you caused, reflect on your own judgment or actions; for a problem that originated from someone else, reflect on the assumptions or systems you were relying on

Respond: How did you respond?

Record what you actually did while the problem was happening
Also reflect on whether that response was appropriate, or whether there could have been a better one

Prevent Recurrence: How will you prevent it from happening again?

Decide what to change going forward, so the same problem doesn’t repeat
If there’s something that can be turned into a concrete preventive measure, translate it into a specific action here

What recording the 4R gets you

Keeping the 4R as a single set makes it easy to look back later and see, at a glance, when something happened, what happened, why it happened, how you responded, and what you did for the future
Keeping a proper log even after the 4R is resolved turns the problem into a reusable lesson, instead of letting it end as a one-off, glossed-over response
Prevention is hard to fix structurally, but post-incident review can be covered by a habit — the habit of writing the 4R

Summary

Problems can be organized along two axes: cause (yourself / someone else) and timing (before / during / after)
People handle the in-the-moment response, but tend to neglect both prevention and post-incident review
Logging the post-incident review as a 4R (Report / Reason / Respond / Prevent Recurrence) turns problems into lasting lessons instead of letting them get glossed over

References

TC 25-20: A Leader’s Guide to After-Action Reviews (US Army AAR field manual)

Markdownメモの取り方

Sun, 04 Aug 2024 00:52:30 +0900

背景

個人的なMarkdownメモの記録方法を残した
このやり方が2, 3日前の思考Logを取り戻せるのでおすすめ

記録方法

コツは一つで、情報はStockとFlowで書き分けて記録する事。

Stock
- Stockの情報は蓄積される情報の事
- 後々見返すようにまとめる事が目的
- 精緻化された構造化情報となる
Flow
- Flowの情報は流れ去ってしまう情報の事
- ある時にぱっと思いついた事を残す事が目的
- 言語化された非構造化情報となる

つまり、Flowで記憶より記録に残し、Stockで記録より実用する事を目指している。

記録の例

以下が個人的なMarkdownのLogのサンプル。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


# Stock

## 買う物

- パスタ
- 牛乳

## blogネタ

- xxx

## 4D

- Do
 - xxx (6h)
 - yyy (2h)
- Defer
- Delegate
 - xxx (Mr. DDD)
- Delete

## 積読

- xxx

# Flow

## 10/10

- xxxだった
- 部屋の掃除をする

## 10/11

いい言葉:

- xxx
- yyy

aaaについてxxxと思った。

## 10/12
## 10/13

見出しの自動生成

ツールは、PCとスマホでHackmdを使用している
そして、日付の自動生成はVimの次のマクロで生成している

1

1 -> esc -> qa -> yyp -> ctrl-a -> q -> @a -> 30@@

ツール

VimモードがあるEditorを使うのが良い。

自分のPC（Kubuntu）を使う時
- KateをEditorとして利用する
- DropboxでファイルをPCとスマホで共有している
他人のPCを使う時
- Hackmd.io

まとめ

シンプルなツールを使い、個人のThoughtsを残す事が重要
Markdownの記法は、StockとFlowで書き分ける事が良い

参考文献

手段の目的化（自己目的化）の回避方法

Sun, 19 Nov 2023 18:09:57 +0900

背景

いつもあまり重要ではない目先の物事に集中してしまう
特に、そこでStuckすると、再帰的に問題が発生する
- 問題解決の為の問題解決の為の問題解決などという感じ
つまり、いつもWayが目的化してしまう
それによって、時間の浪費をすることもある
もちろん、それをやり切る事が大切な次の場合もある
- クリティカルパス
- コアコンピタンス
- コントロールが必要な所
- 自分で理解し、自分でやらなければならない事
ただ、往々にしてそんな事は稀である
また、他にも簡便な道があったりする
また、経験上、今は重要だと思えても、実は1年後から振り返ると、全然重要ではなかった事が多い
そこで、改めてこの目的（Goal）と手段（Ways）の逆転現象（自己目的化）について整理する

定義

自己目的化

自己目的化（じこもくてきか）とは、ある目的のために設定した目標や手段、行動などが、いつの間にか目的にすり替わってしまうこと
英語ではactivity trapと言う
例
- 健康増進を目的として、スポーツ、トレーニングを始めたが、過度に高い目標を設定したり、高強度のトレーニングに夢中になり、体を壊してしまった

手段と目的の意味

手段と目的の基本形は次。目的が上で手段が下のダイアグラムとして表現される。手段と目的はニコイチ、DYADである。

その手段と目的は別の手段となり、それが連鎖する。

目的とは、次の式で表される。

1

目的＝目標＋意味

英語での手段と目的の違い

英語で言うと次の違いがある。

目的：Purpose
目標：Goal、Milestone
方法：Ways、Method
手段：Means

手段の目的化の原因

手段の目的化の原因としては、次のような原因が考えられる。

全体像把握の欠落
- 例えば、なぜその作業が必要なのかのを理解していないことによって発生
- 単純に上位レイヤーの目的を理解していない事が多い
短期記憶の限度
- 例えば、問題解決の為の問題解決の為・・・と掘り下げると発生
- 問題解決の為の調査に時間や短期記憶を使うので結局目的を失念する
サンクコスト
- 例えば、ある課題解決に3h費やしたので、元に引き返せないパターン
- これはプライドというか躍起になっている事にも関連する

解決方法

グラレコ

最初は、ロジックツリーを書いて可視化する
俯瞰して見るため、目的と手段を明確にして、整理する

トラバース

視座を上げたり他の方法を考えたり、縦と横にロジックツリーを広げる
1つの方法に拘らないで、大局的に考えて、柔軟に目的達成することに拘る

アドバイス

また、依頼者や上長に報連相してコミュニケーションを取る事も大切
他には、専門家にフィードバック（ダメだし）をもらって多角的に修正することも重要

柔軟な考えではない例

ドリルがほしい客

ドリルがほしい客がドリルがほしいと思い込む事。

ドリルを買いに来る客はドリルがほしくてドリルを買いに来るのではなく、飽くまでも欲しいのは「穴」
もっと言うと、その「穴」もまた何かの手段であり、別の目的がある
どの次元まで見えているかで意味が変わる例

ルンバを作れなかった

日本人がルンバを作れなかったのも1つの例。

「日本人にルンバは作れなかった」ロボット先進国としての危うい現状 | 日刊SPA!
日本人の思考は具体・細分化方向には進む
最初の着想概念から目的や原因などの抽象方向へは遡らなかった
楽に掃除をするという目的（抽象）方向に思考が行かなかった例

ロウソク問題

人間の機能的固着（Functional fixedness）を示す例。

コルクボードの壁にロウソクを固定し、点火する問題
ただし、ロウソクがテーブルに滴り落ちてはいけない
道具は以下
- 1束のマッチ（a book of matches）
- 1箱の画鋲（a box of thumbtacks）

実験をした結果、ロウソクを画鋲で壁に固定しようとしたり、箱を使わなかった
つまり、道具の機能というbiasがかかって柔軟な発想がなくなるパターン

NIH症候群

プライドによる自前主義の一例。

Not Invented Here Syndrome.
特定の組織や国が外部の発明やアイデアを採用することに対して抵抗を示す心理現象
自組織や自国で開発されたものに対して過度に偏った好意を持ち、外部の発明やアイデアを不当に低く評価する傾向がある
イノベーションや進歩の妨げになると言う事

柔軟な考え方の例

ジュガール

いわゆるバンドエイドソリューションの事。

インドのジュガール（Jugaad）も1つの例
ざっくり言うと、最低限の道具や材料でとにかくどうにかして問題を解決すると言う事
別の言い方だとHack、コロンブスの卵敵なソリューション
固定観念にとらわれず、コスパ・タイパ良く目的を達成する手法

ワンパス

完璧に作るより簡易に作る方が大切。

ソフトウェア開発での用語
ワンパスを通すとは、必要なモノを最低条件で作る意味
細部に拘らず、スタートからゴールまで1つのpathを通して形を作る事が大切と言う意味
別の言い方だと次がある
- Done is better than perfect
- 完璧主義やプライドを捨てる
つまり、一度骨組みや骨子を作った後に、肉付けを行う

コード設計

ライフサイクルの長さによってメンテナブルに書くかを分ける。

検証用コード
- ライフサイクルは短い
- 故に殴り書きやべた書きのコードでOK
基幹システム
- ライフサイクルは長い
- 故にDDDなどでアーキテクチャを設計して書く

その他

NASAの清掃員

有名なNASAの清掃員の話。これは目的意識の大切さの話。

ケネディ大統領がNASA宇宙センターを訪問したとき
ほうきを持った用務員の男性を見つけて、何をしているのかと尋ねました
男性はこう答えました。「大統領、私は人類を月に運ぶ手伝いをしています」

まとめ

総じて目的達成（結果）が大切
視座を高くして目的を設定する
全ては手段にしか過ぎない
プラグマティックに
もしくは、マキャヴェリストに

“The great end of life is not knowledge but action.” ── Thomas Henry Huxley, English Biologist

参考文献

3つの問題解決方法

Thu, 02 Nov 2023 00:45:55 +0900

背景

日常のあらゆることは問題解決
何を問題とするのか、そしてその問題をどう解決するかを日々処理している
何を問題とするかも極めて大切だが、どのように解決するかも大切
- 前者は、いわゆる何がIssueか問題
そこで、後者のどのように解決するかのアプローチについてまとめてみた

3つのアプローチ

次の3つが一般的な問題解決手法。

#	問題解決の型	問題の新規性	知識の有無	例え
1	原因特定型	既知の問題	ある	ポリスドッグ
2	仮説検証型	未知の問題	ある / なし	ファーストペンギン
3	模倣学習型	既知の問題	なし	コピーキャット

この3つの型の違いは、次の2つの基準から生まれる
- 問題が既に知られている問題かどうか
- そしてそれに対処する知識があるかないか
既に先人が解いた問題ならその回答をマネすればいいだけ
また、その問題の分野の専門知識がない場合は学習する必要がある
もし、問題が前人未踏の場合は仮説検証を行い実験する必要がある

それぞれの型を英語にすると以下になる。

CI Type: Cause Identification Type
HV Type: Hypothesis Verification Type
IM Type: Imitative Learning Type

問題解決アプローチの詳細

原因特定型

これはシンプルに医者型の問題解決手法
どこが問題なのか、そしてその問題の原因を特定する
例えば、お腹が痛くて病院に行ったら、診断して何が原因か推定して薬をもらうだろう
知識があるため、できるアプローチ
また、スコープを決めて原因特定をするのがよい
- Don’t boil the ocean.
- これは海の水は沸かせないが、コップの中の水は沸かせる比喩
基本的に知識があるので問題とその原因を具体的にすれば解けるタイプの解決方法

仮説検証型

これはいわゆる科学的方法
未知の問題のため、小さな仮説検証を繰り返す必要がある
現象・実体・本質を見極める方法でもある
それが科学的方法と仮説検証の違いは次
- 科学的方法の場合は再現性を重要視するが、問題解決のための仮説検証の場合は一過性でも問題ない
具体的には、仮説 -> 実行 -> 検証のステップを行うことになる
質のいい仮説を立てるには多角的、多次元的に物事を見る必要がある
- 例えば、旅行を言ったら時空を超えたような経験になる
- それをヒントにタイムマシン経営のアイディアを得るなど
また、別の言い方をすればいわゆるPDCAやToyota WayのKaizenも当てはまる
仮説検証をする前に基本的に先行研究やケーススタディをベースラインとすると良い

模倣学習型

これは前提となる知識が無いときの手法
問題に対応する知識がないため先に学習することを意味する
学校で先生をマネて学習したように、人間の基本的機能の1つ
TPP（徹底的にパクる）もこの手法の1つ
Copycat型とも言える
昨今のGenerative AIによるAGIのように、学習とその量が問題解決には実は一番大切
日本だって古来は中国、近代は欧米のマネをして発展した
本を呼んで学習することもこれに当たる
学習方法には知徳、体得、会得とあり効率を良いモノを選ぶべき
- 例えば、丘の上で本を呼んで泳ぎ方を知徳するより、水に入って体得する方が効率が良い
AIで言う機械学習や強化学習などもこれの一種

共通するコツ

3つの型に共通する、次の2つのコツがある。

データが全て

全ての型に共通して言えることは、データで物事を判断することが大切
つまり、Don’t guess, Just measureということ
データの中に答えはあるし、数字は平等に共通認識を作るから
逆に変にguessして数段論理を積み上げても、空理空論の空想になりがち
data is oil

多角的に見る

また、全ての型に共通することは、多角的に見なければならないと言う事
例として、下の画像は円柱（cylinder）の見え方の違いを挙げる
これは見る人の角度や立場によって真実は別の形で表現されると言う事
3次元で見れば円柱だが、2次元だと投影された方向によって、長方形や円にmappingされる
宇宙も、現状、地球からの視点でしか見る事が出来ない、これも単眼的な例
つまり、色々な人の話を聞いたり、色々な方向から観察して、多角的に物事見ることが大切と言う事

まとめ

問題解決には大きく3つの型がある
その際に2つのコツがあるので意識しましょう

参考文献

成功の5つのコンセプト
イシューからはじめよ
宇宙思考
How Cisco IT reduced Mean-Time-to-Resolution with Cisco Nexus Dashboard - Cisco Blogs
Root cause analysis - Wikipedia

第一原理で考える

Mon, 30 Oct 2023 11:32:47 +0900

背景

クリエイティブな思考法が欲しかったので第一原理思考を調べたメモ
特に、イーロンのfrom the first principlesが頭に残った
海外の解説ブログをベースにまとめた

第一原理

第一原理思考とは

第一原理思考とは「類推ではなく第一原理から推論する」こと
あるプロセスを、「真実であるとわかっている基本的な部分にまで煮詰め（boil down）、そこから構築していく行為」の事
別の言い方だと、現在の仮定を特定し、それを基本的な真実に分解してゼロベースで解決策を作成する方法
類推（reasoning by analogy）ではなく、推論（reasoning by first priciples）をする事

第一原理とは

第一原理とは、それ以上推論することができない基本的な仮定の事
物理学でいう、エネルギー保存則のようなFirst Principleの事
アリストテレスは第一原理を次のように定義した
「the first basis from which a thing is known（物事が認識される最初の基礎）」

前提と仮定

第一原理を探す方法は、デカルトではないが、疑い得るすべてのことを疑うアプローチが必要
つまり、最終的に、完全に疑いの余地のない真実と見なせるものだけが、第一原理という事
ただし、第一原理思考では、実践的には極限まで単純化する必要はなく、1つか2つ深く考えればいい

推論と類推

人々は類推で生きている

人間は、機能を予測して形を捨てるのではなく、現在の形を予測する傾向にある
分かりやすいのが次の疑問

「空飛ぶ車はどこにあるか？」

往々にして人々は「空飛ぶ車はない」と答える
しかし、答えは「飛行機」と呼ばれるもの
人は形（車のように見える飛行物体）にこだわりすぎて、機能（飛行による輸送）を見落とてしまう
つまり、「人々はよく類推で人生を生きている」という事
人間の思考プロセスは慣習や過去の経験との類推に支配されている

推論 vs. 類推

「どちらも別の事物から、ある事物を推し量る」という意味では共通しているが、次の違いがある。

推論
- 「基となる事実からある事物を推し量る」こと
類推
- 「似た事物からある事物を推し量る」こと

つまり、「推し量る」ための根拠が異なっている。

推論思考 vs. 類推思考

推論
- 基本的な事実や原理から始める
- これらの基本原理から論理的に推論を積み重ねていく
- 既存の考え方にとらわれず、根本から問題を考え直す
- ある意味、非常識であり、素直であり、前提を疑う事がベースにある
類推
- 既知の事例や経験を基にする
- 似たような状況や問題に当てはめて考える
- 過去の成功例や失敗例を参考にする
- ある意味、先入観、習慣、常識がベースにある

前例をベースに固定概念から考えるのが、類推かもしれない。

「これまでずっとそうしてきたから、そうしよう」
「誰もそんなことをしたことがないから、それは良くないに違いない」

分からない事は類推になる

第一原理の前提は科学知識やデータして事象を観察することが大切
科学的な知識や事実を知っていれば事物をある一般的な現象だと理解できる
科学的に事物を正しく理解しないと、そもそも正しい推論ができない

例

雷が鳴る => 天が怒っている
月が常に同じ顔を見せる => 地球が中心だ

シェフ vs. コック

シェフはレシピを考えるが、コックは作業をするだけ。

シェフ
- シェフは第一原理から考える（推論する）
- シェフにとって第一原理とは生の食べられる材料
- 新しい方法なのでレシピが存在せず、試してtrial-and-errorでレシピの仮説検証を行う
コック
- 他方、コックは、すでに存在しているものを類推する
- つまり何らかのレシピ、試してみて気に入った料理、誰かが作るのを見た料理などを基にして作業する
- レシピは既にあるのでそれをTTPするだけ

第一原理思考の実践

第一原理思考の例

スノーモービル
- OODAループで有名なジョン・ボイド大佐の第一原理と推論で考えてイノベーションを思いつく思考実験がある
- 例えば、スノーモービルは次のパーツから組み合わせて作れる
  - モーターボート
  - 軍用戦車
  - 自転車
活版印刷
- 推論による発明の有名な例は、ヨハネス・グーテンベルクが発明した印刷機
- 最初の活版印刷機は次を組み合わせて活版印刷機を作った
  - ワイン製造に使われるスクリュープレス
  - 紙
  - インク
- ちなみに、出版社のPressも、圧搾機（Pressing Machine）がベースにある

第一原理で考える方法

シンプルに考えたい事の例や過去事例ではなく、原理原則から考える
例えば、AIに考えたい事の原理原則を聞いたり、いくつかの本で学んだ原則原則を基に考える
他の表面的な現象を真似するのではなく、深層にある原理原則から推論する
数学手で言えば、ユークリッド原論の公理から推論するようなもの
ここでポイントは自分の中にある当たり前の前提や思い込み、先入観を疑う事
類推は常識などの前提を捨て、仮定ではなく、第一原理のようなな原理原則をベースに考える

まとめ

第一原理思考は類推ではなく推論する思考法
物理学のように「第一原理からの推論」をする事
他の言い方だと、分析・統合をする事
数学をやる時に、ユークリッド原論から始めるようなイメージ
Boil down to fundamentalsという事