ヨンソクのブログ
戻る
2 min read
どのように問題を解くべきか?

旧正月に実家に立ち寄った際、高校2年生の頃に買っていた本を見つけた。 原題は How to Solve It、韓国語版では 어떻게 문제를 풀 것인가? - 수학적 사고 방법 - という本だ。 おそらく当時、Calculusのバイオリンの教科書を買うために教友社のホームページを訪れた際に見つけたのだと思う。 (教友社というキーワードがきっかけで思い出した。)
当時は本について調べてから購入したわけではなく、タイトルに惹かれて漠然と「問題を解くのに役立つのではないか」と期待して買ったと記憶している。 そうして購入後、本棚に差したままになっていた。

時が流れ、およそ10年が経ってから再び手に取ることになった。

韓国語版もあるが、第3章の順序が少し異なる。ただし順序と内容に関連はないので、大きな問題はないだろう。英語版では第3章がアルファベット順になっているが、韓国語版は訳者が独自の意味的な順序を付けたようだ。 韓国語版リンク

어떻게 문제를 풀 것인가 | G. 폴리아 저 | 교우사(오판근) - 예스24

이 책에서는 수학 문제의 답을 가르쳐 주는 것보다는 그 문제를 풀고 답이 나올수 있게 하는 수학적 사고 방법에 대해서 설명하고 있다.이 책은 수학을 배우는 사람이나, 수학을 가르치는 사람뿐만 아니라, 자연과학, 인문과학, 사회과학을 배우고 가르치며, 또한 연구...

https://www.yes24.com/Product/Goods/325507
어떻게 문제를 풀 것인가 | G. 폴리아 저 | 교우사(오판근) - 예스24

どのように問題を解くべきか?

本の内容をすべて要約したいわけではない。そのつもりもなかった。 ただ、本を読みながら感じたことを書き留めておきたかっただけだ。

この本の目的は、まず教授法に近い。表面的に見ると数学だけに関連しているように思えるが、問題を解決するために問いかけ、解決策を見出していくプロセスについての方法論を提示している。 単に解決策を見つけることが目的ではなく、一般化し抽象化するプロセスを通じて問題解決能力を育てることを扱っている。

もう少し広げて考えてみると、この本が提示する数学的思考の方法論はソフトウェア開発にも適用できると思う。
開発をしていて出会うもの、問題たち。問題を発見し、定義し、解決していくプロセスは数学的思考の方法論と類似している。

時にはどれが未知数なのかすら分からないことがあり、時には目的を見失うこともある。多様な方法が存在することもあれば、どの方法が最適なのか分からないこともある。

この本では、さまざまな質問を投げかけながら問題にアプローチしていく。

本の中では教師と生徒の間の問いかけだが、開発の場合は自分自身への問いかけだと考えればよい。

Four phases

  1. 問題の理解
  2. 関連性を把握し「計画」を立てる
  3. 計画を実行する
  4. 解決策を振り返り、検討し、議論する

望ましい問題解決のためには、この4つの段階を経る必要があるという。

本の中では直方体の対角線の長さを求める問題を例に挙げている。

ここで4つの過程を経ながら、教師が投げかける質問は次のようなものだ。

  • 「未知のものは何か?」
  • 「何が与えられているか?」
  • 「関連する問題を知っているか?」
  • 「関連する問題を以前に解いた経験はあるか?」
  • 「どのような補助要素を導入すれば、問題を解決できるだろうか?」
  • 「その手順が正しいとどうやって分かるのか?」
  • 「結果を別の方法で導き出せるか?」
  • 「それを一目で(glance)分かるか?」
  • 「結果や方法を他の問題に適用できるか?」

続いて、良い問いかけと悪い問いかけについても扱っている。

上の問題を解く過程で「関連する問題を知っているか?」という質問の代わりに 「ピタゴラスの定理を適用できるか?」と聞くこともできる。しかし著者はこれを良い問いかけとは見なしていない。

問題解決における問いかけ

ピタゴラスの定理は非常に簡潔なので、簡単に覚えて適用できる。しかし、なぜそれが成り立つのかという理解がなければ、拡張したり他の問題に適用したりすることは難しいだろう。 例えば、非ユークリッド幾何学ではピタゴラスの定理は成り立たない。なぜ球面座標系ではピタゴラスの定理が成り立たないのか?ということを導き出すのは難しいだろう。

まるで公式だけを持っているのは、AIが画像を解釈するのと似ている。 AIは芸術作品を一種の正射影のように見える表面的なピクセルとして解釈するが、実際のゴッホの「星月夜」には何層もの筆のタッチというもう一つの軸が存在する。 それを理解するには、絵を描くプロセスを理解しなければならない。

ソフトウェア開発においても、問題を解決するために問いかけることは重要だ。 この問いかけは自分自身にすることもできるし、同僚にすることもできる。

本でのアプローチは学習に対するものだが、開発は業務の領域にもまたがっているため、100%適用するのは容易ではない。 問題解決のために時間を無限に投資することはできないし、ともすればより上位の目標を忘れてしまうこともある。 開発的な達成のために問題を解決することが目的になり得るが、基本的にはビジネス上の目標を達成するために問題を解決するものだ。

それでもなお、問題を解決するために問いかけることは重要だ。 私たちが悩んでいる問題に対する多種多様な解決策はすでに存在している。

適切な解決策をうまく見つけて適用すること自体も簡単なことではないが、 ある程度自分自身が問題について理解し、解決策を見つけ出すために問いかける時間を持つことは重要だと思う。

例えば、複雑なコンポーネントに直面した時、「どうすればこの複雑さを減らせるだろうか?」という問題に出会うことがある。 この場合も具体的な状況に応じてさまざまな方法が存在し得る。compound componentsrender propscustom hooksHOC などなど。 適切に見つけて選択することも、問題を素早く解決する助けになるだろう。 もちろん車輪の再発明をしようというわけではないが、それぞれの車輪が生まれるまでには誰かの問いかけがあったはずだ。

言いたいのは、(余裕があれば)時間をかけて自分自身に問いかけてみようということだ。 そうして問題を解決するプロセスの中で、既存の解決策に収束することもあるだろうし、新しい解決策を見つけ出すこともあるだろう。 そのプロセスを通じて、どのような目的を持ち、どのような流れでその方法論が生まれ発展してきたのかについても理解できるようになるだろう。

respice finem

本に登場する格言で、ラテン語で「始める前に目標を考えよ」という意味だ。 That is, look at the end. Remember your aim. Do not forget your goal

本を読んでいると、大部分の内容は「当たり前だよね…」という感想を抱く。しかし当たり前のことだからといって、私たちがそれを実行しているわけではない。 それをもう一度思い起こすことが重要だと思う。