数学が強力なのは抽象性と厳密性の両方を兼ね備えているから、というのどこかの偉い先生がどこかに書いていて、すごく印象に残っている。
抽象的なものが力を発揮するのは厳密性が足場を支えているからであり、曖昧な世界観で抽象的なことを述べても、そのままブラックボックス的に使えることはあんまりないと思っている。
アルゴリズムみたいな話だと厳密性が高いので「このアルゴリズムはO(log n)で計算できます」と言うことであれば、実際O(log n)で計算されることが保証されているし、盲目的に使える。 一方で、問題がすごく複雑だったり曖昧だったりして、全てを変数にすることができないようなこともあって、そういうものは厳密性を上げるのが難しいなと感じてる。例えば、設計とかプロジェクトマネジメントとかが当てはまる。
例えば、「目の前の問題に対してこのデザインパターンが有用かどうか」みたいなのは結構難しい問題だと思う。デザインパターンは数学でいうところの「命題」みたいな立ち位置のように見えるが、自分の目の前の問題が「命題」の仮定を満たすかどうかを確認するのは容易じゃないように思う。じゃあどうしているのかと言うと、デザインパターンの本などには具体例がちゃんと説明してある。それを見て、こういう場合にこういう手法を取るとうまくいくことがあるのだな、と学ぶ。学んだうえで、自分の設定でそれが使えるかどうかを自分やチームで考える、ということを行う。つまり具体的な問題を抽象的なパターンにしているんだけど、実際には抽象化したものだけでは不十分なので具体例とセットで学ぼうね、ということになってる。
じゃあ厳密性の低い設定では、物事を抽象化することに意味はないのかというと、そうではないと思っている、というのは前にも書いていて、今も同じ考えでいる。
じゃあアーキテクチャとかデザインパターンとかって何なんですか？役に立たないんですか？というとそうではないと自分は思う。 設計の本に書かれている抽象的なパターンとされているものは、特定の問題に対して優秀なエンジニアたちが与えた解なのではないか。 具体的な問題があってそれに対する解を与えて、じゃあなんでそれが解なのかを考えると、要素をそぎ落として抽象的なものが残るはずで、 なんかそういう手続きの最終的な出力なのだと思う。 それから学ぶためにやるべきことは何かというと、解を見ることではなくて、問題と解の関係や、解決の過程なんじゃないかと思う。
プロジェクト進行などについても似たようなことを感じている。人間が絡むので当たり前だが、問題が複雑で抽象化したときに情報が抜け落ちているのではと思うことがある。今の職場ではプロジェクト進行をやることが結構あって、いっぱい失敗したり助けられたりしつつ何とかやっている。なんとなく自分の中で「こういうときはこうするのがよさそう」みたいな理解はあるが、抽象化するのは諦めつつあり、ケーススタディとして他人に共有するのが良いのかなと考えたりしてる。
