1年以上間をあけてしまったものの、ぼちぼち復活させていこうかと。
まず1個目のネタとしては、「アーキテクトの素養としての数理」。
とりあえずアーキテクトの素養として、数学、とくに代数学系が分かってたほうがいいって最近とみに思う。
まぁ、アーキテクトと言っても非常にその語の指す範囲も広く、ビジネスアーキテクトとかそういうのも入ってくるわけで、ここではどちらかというとITSSで言うところの「アプリケーション共通基盤」周りをやる人たちが対象かな。
まぁ、「数学がアーキテクトの素養」とか言うと、「んなこたぁない、経験でやってきてるが上手く行っている」って良く言われることも多い。
私としてはそれはそれで正しいと思うし、むしろアーキテクトとしての必須の素養は「揺るぎない自信」が何よりも勝る気もするので、アーキテクトとしてその主張をするのはそれは間違いないと思うところでもあり。
が、工学な大学院出ていてIT業界でないエンジニアを友人として持っている人間から見てみると、IT業界っておかしくて、機械系の勉強していた奴だけがメーカーに入ってエンジニアをやり、建築系の勉強していた奴だけが建設会社に入ってでかい建造物の設計をやる、というのがエンジニア系の業界の普通であって、(あくまで例えば、ですが)「経済の勉強してました、プログラミングなんてしたことありません」ってのが、(専門性を必要とされる)SEやプログラマをやる、なんてのはちょっと不思議に思えるところ。
まぁ、自分がそう思う、というだけであって、そこからIT業界けしからん論を展開するつもりは毛頭ないので、これはこれっきりでおしまい。
話を戻して、どういう背景で「数理はアーキテクトの素養」なんて思うのかといえば、諸々のアルゴリズムへの理解は言わずもがなとして、近頃出てきた様々なシステム構築パラダイム(言語、フレームワーク、設計方法論)を見ていくと、そこら辺の知識に依拠した背景を持つものも少なくないと思うから。
また、フレームワークを作るときにあたっては、その利用の側面を考えるのはもちろんの事、それらの環境についての理解をしておいた上で作ることがやっぱり必要になるわけで。
というか、そこら辺の素養が「どう作るべきか？」の判断の一つの基準になるような気もしていて、だからこそ、抑えられるところは抑えておきたいと思うところ。
とはいえ、そういった学問は広範であること、抽象度が高いために難解であることなどから、パッと応用に繋げられなそうなところが厄介。
でもまぁ、地道に行こう。
