「いかにして問題をとくか」をいかにして読みとくか

作者:G. ポリア
発売日: 1975/04/01
メディア: 単行本

繰り返し読み返すべき技術書、今回はGポリア著「いかにして問題をとくか」を取り上げる。

この本は、本来は"数学を解こうとする教師と学生のため"に書かれた本だ。所謂コンピュータサイエンスの技術書ではない。

だけど以前、この「いかにして問題をとくか」の中心となる”問題をとくための4つのステップ”、「問題を理解する」「計画をたてる」「計画を実行する」「ふり返ってみる」は、まさにソフトウェア開発のステップそのものであり、特に「問題を理解する」に出てくる「条件はかき表されているか」という問いかけを出発点として、ソフトウェア開発で必ず問題化する「暗黙知」について考察するスライドを書いて、そこそこ評価していただいた。

blog.magnolia.tech

個人的にはこの本を最近宣伝されてるような所謂ビジネス書として読むのは（抽象度が高すぎて）少々無理が有ると思うが、数学とコンピュータサイエンスは切っても切り離せない関係なので、ソフトウェア開発へのヒント、という文脈では現代でも十分に有益なのではないかと思っている。

冒頭にも書いた通り、この本は、数学を解こうとする教師と学生のために書かれた本だ。

問題を理解する

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

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

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

得られた答えを検討する。結果をちがった仕方で導くことができるか。他の問題にその結果や方法を応用することが出来るか。

(上記は、丸善出版のサイトからの引用であり、本書の記載よりさらにコンパクトにまとめられている……本書の表紙裏に書かれたまとめの方が記述量は多い）

問題をとくために全体を4つのステップに分解し、「問題を理解する」「計画をたてる」「計画を実行する」「ふり返ってみる」と定義する……現代から見れば当たり前のように思える分解方法も、原著が出版された1945年当時は画期的な発想だったのだろうし、日本語訳が出版された1954年(昭和29年!!)でもやはり画期的な発想だったのだろう。

いま読んでも十分に通じる内容なのだから。

ページ数はそこまでない(250ページくらい)ながら、割と文字がみっちり詰まっている構成なので、ぱらぱらっとめくったくらいだと、かなり難しい本という印象が有るけど、最初の30ページが最も大事なことが書かれていて、40ページ以降はさまざまなトピックを取り扱う小辞典(ABC順)なので、気になったトピックを拾い読みをしていけばよい。

とにかく最初の、4つのステップの解説を何度も読んでおいた方がいい。特に興味深いのは、「計画をたてること」に重点が置かれていること、「ふり返ってみること」が最後にきちんと組み込まれている点。表紙裏のリストには、「計画をたてること」のトピックは7つも挙げられているのに、「計画を実行すること」では1つしか挙げられていない。しかも本文では、実行には「必要なのは主に忍耐だけである」とまで書いて、計画の重要性を説いている。

ここで言われている”計画”とは、単に作業スケジュールを決めることではなく、問題そのものをよく吟味し、問題を適切にとくために「類似の問題を引っ張ってきたり」、「問題をいいかえたり」、「問題がとけないときに他のアプローチを考えたり」と、問題に対する取り組みの方針、作業の中身について語っている点に注意。本書は作業監督官のために書かれた本ではないのだ。

ここで挙げられている”問い”や”注意”を一つ一つの作業の中でいちいち問いかけていくのは難しいし、そんなことばかりやっていては時間も足りなくなってしまうかもしれない。だけど、非常に複雑な問題を解くときに、改めてここに書かれている”問い”や”注意”と、目の前の問題を照らし合わせていくことで発見されることは有る。

ちなみに第Ⅲ部の小辞典は、あまりに色々なトピックが並列に並んでいるので、読みづらいところが有るけど、一つ絶対に読んだ方が良いのは「分解と結合」。これぞまさにソフトウェア開発のアプローチそのものなので、設計やデバッグなど、あらゆる場面で役に立つ思考のステップが書かれている。

分解と結合とは大切な心の働きであるという名言から始まり……