僕はプログラマとかソフトウェアエンジニアとか、まぁそういう類のことを生業にしています。そういう人種が日々で何をしているか？というと、一言でいうなら「問題解決」です。

なので、ソフトウェア界隈では、問題とはなにか？から深く洞察するワインバーグの書いた本を読めと言われるのです。読んでない人は読みましょう。

学校では、予め厳密に定義された問題が出されて、その問題を解くことが、学生の生業です。（研究とかのレベルまでいけば違うとして）

社会人は、今ある問題の整理、潜在的問題の洗い出し、解かなくていい問題を消し込むこと、問題のリストから、チームと自分にとって、今解くべき問題をピックアップすることなどから始まった上で、実際に問題を解決します。

で、今回の記事は、こういった前置きをしつつも、たいそうなことを書きたいわけではなくて、僕が問題解決スキルを成長させていった原体験みたいなものを語りたいなーと思っただけのものです。（問題発見の方の記事ではありません）

問題を解くということ

成人するかしないかくらいの頃の、とあるイベントで、とあるパズルを説いたらスタンプを押して貰える！みたいなお遊びがありました。

そのパズルは、条件に合致する答えを出せばOK!というものでした。

大雑把にいうと、9x9 のマス目にルールに沿った数字を埋めればいいものです。

数独と似たような制限で、より自由度の高いパズルでした。

僕がその問題を解こうとしてたときに、数独に似てることは気づいてたんですが、自由度が高すぎて、これはどう解くのが正しいんだろう？みたいにハマってました。

同じイベント参加者が、さささっと問題を説いてて、あれ？？？？？そんなサクサク解けるのか？と思って、ついついどうやって説いたんです？と聞いてしまったんです。

「数独よりルールとしてはゆるいけど、数独であると決めつけちゃえば簡単やん」

当時の僕としては、とても目からウロコな体験でした。

確かに数独よりもゆるいルールなら、数独と決めつけた上で、足りない数字がいっぱいあるなら、それは「答えが何種類もある、激烈に簡単な数独」の問題に変換できるんだ。

できていいんだ

問題の解決方法は、学校で習ったような、固定のやり方ではないんだ、というのを初めて実体験として学んだのがそのときだったと覚えています。

大人になった今としては「正しいもの」なんて大抵の場合無いと知っています。むしろ「正しいものなんてのは、自分たちで作ればいいんだ」ということが大切です。

なにかを学ぼう、スキルを身に着けたいと思っている人は、道が一つではないこと、正しいものなんて大抵は無いってことを思い出していただければいいかもしれません。