チームに新しく入ってきた人に、最初に紹介している本がある。
Polya の『いかにして問題をとくか』だ。
1945年初版の数学の問題解決書で、数学書の棚に置かれているが、中身は仕事の進め方の本として読める。
この本をただ「読んでおいて」と渡すだけでは、数ヶ月後には本棚の肥やしになる。
だから Notion のドキュメントテンプレートに構造ごと埋め込んで、何かを決めるたびに Polya の問いを通るようにしている。
この記事はその運用の話。
Polya の4ステップ
本の骨子はシンプルで、問題解決を4つのフェーズに分ける。
- 問題を理解する — 未知は何か、与件は何か、条件は何か
- 計画を立てる — 既知の問題とどう関係づけるか、類似問題はあるか
- 計画を実行する — 各ステップを検証しながら進める
- 振り返る — 結果と道筋を吟味する
誰かの企画や提案を見ていて「それ、何を解決するんだっけ？」と聞きたくなる瞬間は、だいたい 1 を飛ばして 2 から始まっている。Polya はこれを80年前に見抜いている。
Notion テンプレートへの落とし込み
提案や検討のドキュメントテンプレートは、Polya の4ステップを見出し構造にそのまま写している。
- 1. 問題の理解
- 解決したいこと（未知）
- 現状わかっていること（与件）
- 制約条件（条件）
- この問題を一文で言い換えると？
- 2. アプローチの計画
- 類似の事例（既存の仕組み・社内事例・過去の判断）
- 検討した選択肢と却下理由
- 選んだアプローチとその根拠
- 3. 実装計画
- 分解したサブタスク
- 各ステップの検証方法
- ロールバック手順
- 4. 振り返り（実装後に追記）
- Layer 1: 問題単位
- Layer 2: 姿勢
- Layer 3: 周辺状況
ポイントは、
テンプレートは埋めるためではなく、問いを思い出すためにあること。
小さな案件で全セクションを埋めさせるのはやりすぎで、むしろ「1. 問題の理解」だけ書いて話が崩れたら、それはそれで学びになる。
振り返りを3層に拡張する
Polya の「振り返る」は元々、解いた問題に対する検算と一般化の話だ。
これをチーム運用では3階層に拡張している。時間軸をずらして複数回行うのがミソ。
Layer 1: 問題単位
解は正しかったか。想定通り動いたか。未知は本当に未知でなくなったか。
ここは Polya の原典に一番近い。
Layer 2: 問題に立ち向かう姿勢
どう考えたか、どこで詰まったか、別の計画はあり得たか。
本人の思考プロセスをメタに見る層。
ここを書かせると、次の提案の「1. 問題の理解」の解像度が上がる。
Layer 3: 周辺状況
そもそもこの問題はなぜ発生したのか。
組織構造・設計・プロセスのどこに根があるか。
ここに踏み込むと、個別の問題解決が組織学習に変わる。
Layer 3 を同じドキュメント内で追記運用しているのは意図的で、問題解決ログが時間を越えて積み上がっていく。半年後に似たイシューが来たとき、Layer 3 まで辿れるドキュメントは一次資料として効く。
導入してみて
変わったのは提案の質そのものより、提案を出すまでに考える量だった。
「1. 問題の理解」で手が止まる人が出る。それでいい。
手が止まるということは、これまで止まらずに2に突入していたということだ。
注意点が一つあって、テンプレートは思考の補助線であって、埋めるべきチェックリストではない。
セクションを埋めること自体が目的になると、Polya がもっとも嫌った「理解せず手を動かす」の変種になる。
埋まっていない欄があっていい。問いを自分に投げた痕跡が残っていればいい。
まとめ
80年前の数学書が、2026年のドキュメントテンプレートになる。
フレームワークは古びないが、運用で腐る。
Notion に埋めて、振り返りを多層化して、時間軸で積み上げる。
これで初めて Polya は本棚から出てくる。