Engineering Skills

製品開発エンジニアがデータ解析のノウハウを垂れ流します

いかにして問題をとくか(1)

言わずと知れたG.ポリアの名著「いかにして問題をとくか」です。柿内賢信訳の書籍表紙見返りには要約がついています。まずはそこから

「いかにして問題をとくか」の要約

有名な訳は以下です、ちょっと多いのであとで圧縮してみます。

1.問題を理解すること

未知のものは何か、与えられているデータは何か、条件の各部を分離し書きあらわせ。

○未知のものは何か。与えられているもの(データ)は何か。条件は何か。
○条件を満足させうるか。 条件は未知のものを定めるのに十分であるか。または、不十分であるか。または、余剰であるか。矛盾しているか。
○図をかけ。適当な記号を導入せよ。
○条件の各部を分離せよ。それを書き表すことができるか。

2.計画を立てること

与えられた問題が解けなかったら、既に解いたことのある易しくて似た問題を思い出せ。条件の一部を残し他を捨てれば未知のものが見えてくる。

○前にそれをみたことがないか。同じ問題を少しちがった形で見たことがないか。
○似た問題を知っているか。
○役に立つ定理を知っているか。
○未知のものをよく見よ。そして、未知のものが同じかまたは、よく似ている見慣れた問題を思い起こせ。
○似た問題ですでに解いた事のある問題がここにある。それを使うことができないか。その結果を使うことができないか。その方法を使うことができないか。それを利用するためには、何か補助要素を導入すべきではないか。
○問題を言い換えることができるか。それをちがったいい方をすることができないか。
○定義にかえれ。
○もし与えられた問題が解けなかったならば、何かこれと関連した問題を解こうとせよ。
○もっと易しくてこれに似た問題は、考えられないか。
○もっと一般的な問題は?もっと特殊な問題は?類推的な問題は?
○問題の一部分を解くことができるか。
○条件の一部を残し、他をすてよ。そうすればどの程度まで未知のものが定まり、どの範囲で変わりうるか。
○データを役立させうるか。
○未知のものを定めるのに適当な他のデータを考えることができるか。
○未知のものもしくはデータ、あるいは必要ならば、その両方を変えることができるか。そして、新しい未知のものと、新しいデータとが、もっと互いに近くなるようにできないか。
○データをすべてつかったか。
○条件のすべてをつかったか。
○問題に含まれる本質的な概念は、すべて考慮したか。

3.計画を実行すること

計画を実行せよ。

○解答の計画を実行するときに、各段階を検討せよ。その段階が正しいことをはっきりと認められるか。

4.振り返ってみること

得られた答えを検討せよ。

○結果を試すことができるか。
○議論を試すことができるか。
○結果をちがった仕方で導くことができるか。それを一目で捉えることができるか。
○ほかの問題にその結果や方法を応用することができるか。

理系エンジニア向けへの翻案

有名なフレームワークP(plan)D(do)C(check)A(act)に対しG.ポリアの2.は(plan)、3.は(do)、4.は(check)に相当するのが現代にも通用する方法論であることの証左です。そして理系の技術者として大変参考になるのは1.と2.と思います。3.と4.は実験と考察、あるいは追加の検証になるので、ここまで到達すればある程度規定路線です。

まずはG.ポリアの1.「問題を理解すること」。これは取り掛かる未解明案件への最初のアプローチ。問題を理解出来ていなければ解明のしようがないです。また、考察を進める上での前提条件の整理でもあります。

実験結果の整理(未知のものは何か、与えられているデータは何か)
実験事実を分離する(条件の各部を分離し書きあらわせ)

そしてG.ポリアの2.「計画を立てること」は、元々の著作でも本項目だけ分量が多いです。本書の肝であるが故、比重が多く割かれているのだと思います。また、元々は数学問題へのアプローチのため数学証明のための記述があるので、技術者向けに選択・抜粋してみます。

類似/類推/関連/簡略化/一般化/特殊/部分 問題はないか
制約条件の変更(影響範囲)
未使用データ/不足データ/全て考慮したか?

課題自体の分解、一般化、特殊化、そして制約条件も分解してみる。手持ちのデータを使いつくしたか、反証/検証しつくしたか。

最終的にはストイックなフレームワークだけど、課題を理解しやすい形に変更することから始めています。実はとてもやさしい論証のフレームワークですね。

まとめ

G.ポリアの名著「いかにして問題をとくか」について、徒然に書きました。次回は図にしてみます。