2020年6月28日 いかにして問題をとくか
ルノアールのモーニング無料券をもらったので、喫茶店で読書でもするか〜と思い、スマホを持たずにルノアールに行った。持っていった本は、ポリアの『いかにして問題をとくか』という本。
著者のジョージ・ポリアは数学者で、組合せ論などの分野における権威者。この本では、そのポリアが数学の問題を発見的に解くための流れと、それぞれのフェーズで気をつけるポイントを教えてくれる。著者は数学者だが、この本では前提となる数学的知識はほとんど無い。理系の必読書として挙げられることも多い本なので、いつか読んでみたいと思っていた。
この本で扱う思考のフレームワークは数学以外にも適用できるとの話を聞いていたので、自分のよく扱う問題である、プログラミングやそのデバッグに置き換えて考えてみた。
問題を解くためのフェーズは問題理解・計画・実行・振り返りの4つに分けられると書かれている。
その最初の問題理解では、「未知のものは何なのか. 与えられているデータはなに. 条件は何か.」を把握せよ、これが済むまで次のフェーズに進むなと書かれている。これをソフトウェアのデバッグに置き換えてみると、
未知のもの＝不具合の原因
与えられているもの＝不具合の症状・ログ・メトリクス
条件＝不具合の起きた環境とその再現手順
となる。
数学と比べて、ソフトウェアのデバッグにおいてはこの問題理解フェーズがめちゃくちゃ重要になると思う。なぜかというと、デバッグではここまでをしっかりやればあとは答えが自明にわかってくることが多いから。裏を返せば、デバッグは計画・実行フェーズが数学に比べて多くの場合簡単といえる。
しかしデバッグの問題理解フェーズはとてもむずかしいと思う。というのも、現実のソフトウェア開発と運用では、様々な技術が複合して多層的に動作しているせいで、問題理解に必要な「未知のものは何なのか」を把握し切ることが困難だからだ。それら技術には数学のような厳密な定義が与えられていることはあまり無いし、アプリケーションを支えている技術やソフトウェアの数は膨大にある。結果的に、エンジニアは抽象化されたレイヤーのうちアプリケーションに近い層のいくつかに関する知識を使って問題理解に取り組むことになる。
しかし不具合の原因が自分の知っている知識の範囲で説明可能かどうかは問題が解かれてからでないとわからない。自分の知らない領域が不具合の原因だった場合、その分野を理解することが先に必要となる。しかしプロダクションで障害が起きている最中に勉強をしはじめるのはおそすぎるので、解ける問題の数を増やすために、エンジニアは普段使っている技術の裏側の仕組み（いわゆる低レイヤー）の理解を進めておくべきといえる。もっと勉強しようね