カオスへのアプローチ

中学のとき、友人が「数学が何の役にたつのか全然分からん」と言っていた。高校でも同じようなことを聞いた。大学に入ると、さすがに数学科に入った連中からは聞くことはなかったが、バイト先の学習塾で数学を受け持ったのだが、その生徒である中学生がやはり同じようなことを言っていた。「数学なんて、何の役にも立たないから勉強しなくていい！」。実際、受験科目として不要な選択肢もあり得るわけで、いかんせん否定も反論もできず、僕はただ口をつぐんでいるしかなかった。

そんなモヤモヤを抱えて社会に出て、システムエンジニアという職についた。もちろんシステムエンジニアである以上コンピュータ・プログラミングとは切っても切れない関係であり、数学的な知識やセンスが大いに生かされる局面は多々あった。しかし、2年、3年と仕事を続けていたら、システムエンジニアの仕事はプログラマーとは違うということが分かった。
それは、クライアントが抱えるモヤモヤっとしたものに対して、ソリューションという名前の解決法を提示するという仕事だった。
もちろん、僕らにモヤモヤを相談してくれるクライアントは何となくコンピュータとそこに搭載されるソフトウェア、あるいは関連緒機器により解決がなされるんじゃないかという推測を持っているし、僕らの持つ解決法とは基本的にコンピュータとプログラムと関連機器によるものだから、必然的にソリューション＝システムということになることが多かった。だが、極端に言えば、システムでは無い解決法というのもあり得る。クライアントが行なっている業務のやり方を、組織体系を、考え方を変えるだけで、既存のコンピュータやソフトウェアや関連機器によってモヤモヤを解決できる方法が無いとも限らない。僕らシステムエンジニアは、そうしたモヤモヤの解決を第一義に置くべきであって、自らのシステムを売りたいがためにクライアントに余計な出費を出させるのはナンセンスである。

さて、この「モヤモヤ」が問題である。
一般的に、このモヤモヤはカオスである。混沌としていて、体系化されておらず、論理的では無いことが多い。何だか困ってる。何だか面倒だ。何だか非効率で、何だか旧式だ。便利になりたい。楽になりたい。正確にしたい。そんな感じだ。
我々システムエンジニアは、その絡まった糸を少しずつ解きほぐすところから始まる。注意深くヒアリングし、業務を整理し、問題となっている点を体系化して論理的にまとめていく。そして、解決すべき問題点が体系化された段階で、解決法を順次当てはめていくわけだ。

ここでちょっと待って欲しい。上に書いた「システムエンジニア」の仕事であるが、これが仮に教員だったらどうだろう。クライアント、つまり子どもの抱える問題はカオスである。それを少しずつ解きほぐし、体系化し、自分が持ちうるスキルで解決法を当てはめる。ではスーパーの店員ならどうだろう。客が何を今欲しがっているかというカオスな問題に、季節や地域の生活習慣や流行などといった情報から少しずつ解きほぐし、最も客が欲しいと思っている商品を都合の良い価格で提供する。

そう。カオスな問題にアプローチし、論理的に解きほぐして体系化し、自分が持っている手段によって解決法を当てはめることは、ほとんどの仕事において全く同じなのだ。与えられた単純業務をこなすだけの労働ではなく、自らが価値を生み出すような職業であれば、やっていることはほとんど同じなのである。

つまり、10分前に200m/分のスピードで出発した太郎くんに、忘れ物を届けるため400m/分のスピードで追いかけたら何分後に追いついてそれは出発点から何m離れた場所か、などといった一見カオスな問題を、x分後あるいはym地点で追いつくと仮定して論理的な連立方程式に解きほぐし、連立方程式の解法というスキルを持って解決に向かうことも、全く同じ作業なのだ。

従って、数学は役に立つ！と言いたいのだが、いずれにせよ説明が冗長なのは大問題である。
ふう。