2026年9月に増補： 元の記事は一文だけでした。今回、個人的な読書日記を作り上げたり原著を長く引用したりせず、実践に使える読書ノートへ改めました。
ジョージ・ポリアの『How to Solve It』は1945年に刊行された数学の問題解決に関する本です。しかし、長く残った貢献は数学を越えています。「分からない」状態から「根拠を説明できる答え」へ進む間の、普段は見えにくい作業を観察できる形にしたことです。Princeton University Pressは本書を、発見と発明の方法であるヒューリスティクスの紹介と説明し、1945年以来継続して刊行され、多くの言語に翻訳されてきたと記録しています。
Table of Contents
版を選ぶ、または先に借りる
このノートが扱うのは方法なので、特定の版のページ番号には依存しません。本を探すときは表紙ではなく ISBN を使うのが確実です。
- Princeton Science Library ペーパーバック（2014年）：288ページ、ISBN 978-0-691-16407-6。出版社の書誌、または Google Books の書誌情報と限定プレビューを確認できます。
- Penguin ペーパーバック：272ページ、ISBN 978-0-14-012499-6。Penguin の書誌を確認できます。
版、価格、在庫は国や地域で異なります。購入前に合法的に借りたい場合は、地域や大学の図書館を検索してください。Open Library の版情報は所蔵先を探す手掛かりになり、その版と地域で利用できる場合だけ貸出入口を表示します。
独立系書店を支援したい読者は、通常の追跡なしリンクである Bookshop.org 米国版または Bookshop.org 英国版を確認できます。米国版と英国版は別の地域サービスです。これらはアフィリエイトリンクではなく、現在この記事から報酬は発生しません。
よく知られた枠組みは4段階です。
- 問題を理解する。
- 計画を立てる。
- 計画を実行する。
- 振り返る。
この一覧は覚えやすい一方、過小評価もしやすいものです。4つの見出しを成功保証のアルゴリズムとして扱うことに価値があるのではありません。各段階の中で問うこと、そして計画によって理解の誤りが見えたとき前へ戻れることに価値があります。
1. 問題を理解する
計算や実装を始める前に、別の人が確認できる形で問題を書きます。
次を尋ねます。
- 未知のものは何か。
- 与えられた事実、入力、制約は何か。
- 曖昧な用語はどれか。
- 何をもって正しい結果とするか。
- 図、小さな例、自分の言葉での言い換えを作れるか。
この段階は、間違った問いに技術的には正しい答えを出す失敗を防ぎます。「プログラムを速くする」だけでは、まだ検証可能な問題ではありません。「出力を変えず、固定データセットの処理時間中央値を12秒から8秒未満へ下げる」なら、かなり明確です。
この段階の成果物は、短い問題文、既知と未知、制約、成功を確認する方法です。
2. 計画を立てる
計画は有望な経路であり、成功の予言ではありません。ポリアのヒューリスティクスには、関連する問題を探す、より簡単な場合を考える、役立つ記号を導入する、補助要素を加える、目標を分解する、望む結果から逆向きに考える、といった方法があります。
実務では、できれば複数の候補を作ります。
- 最小の入力で失敗を再現する。
- 成功例と失敗例を比較する。
- 大きな処理系の一段階を分離する。
- 期待する出力から逆向きにたどる。
- 複雑な部品を制御できる代替物へ置き換える。
- 常に保たれるはずの不変条件を探す。
そのうえで、最小の費用で最も多くの不確実性を減らせる案を選びます。5分で仮説を否定できる診断は、その仮説を1時間かけて実装するより価値があることがあります。
3. 計画を実行する
実行には規律が必要です。仮定を書き、一度に一つの解釈可能な変更を行い、中間結果を確認します。ある段階が導けないなら、作業量で穴を隠さず、止まって推論を直します。
ソフトウェアなら、失敗した入力を保存し、正確なエラーを記録し、狙いを絞った確認を追加して、一つの変数だけを変えます。数学なら、各変形の根拠と定理の適用条件を確認します。研究なら、観察と推論を分け、再現に足りる文脈を記録します。
計画の失敗も証拠です。新しく分かった制約を持って最初の二段階へ戻り、同じ試行を強く繰り返すだけにしません。
4. 振り返る
第4段階は、一つの解決例を再利用できる知識へ変えます。
確認します。
- 答えは元の条件を満たすか。
- 別の方法や極端な場合で検証できるか。
- どの仮定が不可欠だったか。
- より簡単な説明があるか。
- より広い種類の問題にも使えるか。
- 同じ混乱を防ぐテスト、ノート、ツールを作れるか。
修正したバグは回帰テストにします。導出は代入、次元、独立した経路で確認します。うまくいった手順は、逸話のままにせず小さなチェックリストにします。
例：バッチ処理がファイルを黙って飛ばす
10個のファイルを受け取るプログラムが、8個の出力しか作らないとします。
理解： 正確な入力一覧、期待する一対一対応、出力先、ログ、終了状態、欠けた2つの名前を記録します。「時々飛ばす」を再現可能な文章へ変えます。
計画： 成功ファイルと欠落ファイルを一つずつ比較し、その2つだけのバッチに縮小します。フィルター、ファイル名解析、ファイルごとの例外を確認し、出力書き込み段階から逆向きにたどります。
実行： 各段階の件数をログへ加え、2ファイルの例を実行し、疑わしい条件を一つだけ変えます。証拠から、大文字の拡張子が大小文字を区別するフィルターを通らないと分かるかもしれません。
振り返り： 拡張子を正規化し、大小文字混在や特殊な名前のテストを追加し、10個すべての出力を確認して入力規則を記録します。修正は一回の実行だけでなく、今後のバッチを守ります。
この例はポリアの原著からではありません。同じ段階が技術保守へどう移せるかを示すための例です。
この枠組みがしてくれないこと
4段階は、専門知識、証拠、創造性、判断の代わりにはなりません。よく整理された計画も、誤ったデータから始まれば失敗します。複数の答えが認められる問題もあれば、単一の数学的証明ではなく、倫理、法律、費用、不確実性に制約される問題もあります。
また、この枠組みは厳密な一直線ではありません。計画を試す間にも理解は深まり、振り返りで元の問いの立て方が悪かったと分かることもあります。循環は欠点ではなく特徴です。
短いワークシート
問題：
望む結果と成功確認：
既知の事実：
未知のもの：
制約：
候補となる計画：
最小コストで情報量の多いテスト：
手順と観察：
否定された仮定：
検証：
より簡単な説明：
再利用できるテスト、ノート、ツール：
次の問い：この習慣はLazying.Artの考えに合います。一度苦労して得た解決を明確な成果物にし、他の人や未来の自分が再利用できるようにして、繰り返しの摩擦を減らします。オープンプロジェクトは、その成果物がコード、文書、ツールになる場所です。
2018年の原文
元の記事の全文は、次の英語一文だけでした。
This book introduced a way to analyze problems and develop solutions.