アーキテクチャとは何であろう
最近仕事柄良く聞かれます。同じ部の人に。
- アーキテクトって何する人っすか
- アーキテクチャって何スカ。設計と何が違うんすか
- アーキテクト・グループ(私が所属している部署)って何する部署っすか
- アーキテクトがいないプロジェクトもありますけど、本当にアーキテクトって必要なんすか
とか。まぁ、4に関しては、
- 専任の高度なアーキテクトがいないだけで誰かが知らず知らずのうちにアーキテクトロールを押し付けられてる
- つまり、認識していないだけでアーキテクトロールを持つ人は存在する
- 他のシステムを構築するときに確定したアーキテクチャを流用していたりとか、パッケージなどの基本的にアーキテクチャが確定しているようなソリューションを利用していたりとか
のどっちかなだけで、専任かどうかとか技術的に高度な判断ができるかどうかとかはおいといて、アーキテクトロールを持ってる(持たされてる)人が全くいないプロジェクトって無いとは思いますけど。
そして、システムも複雑化してきた昨今、兼任アーキテクトでは中々技術的に高度な問題に対して(最適ではないにしても、少なくとも)間違いでは無い判断を下し続けつつ、本来のお仕事もこなすのはちょっと難しいんじゃなかろうかってところだと思うんですけどまぁそれはさておき。
じゃーアーキテクチャって何スカって言われると、万人に分かりやすく納得がいくように説明しようと思うとまだまだ未熟な私にはこれがなかなか難しい。
上記wikipediaのページにはそれぞれ「ソフトウェアアーキテクチャという用語に関して、万人が合意した厳密な定義は存在しない」「システムアーキテクチャの明確な定義はなく、各種団体が様々な定義を与えている」とか、まだまだみんな考え中みたいなことを言っているかと思えば、
上記@ITの記事には「アーキテクチャに関しては十分定義され尽くしている」とか書かれていますが、
とか正直私には意味がよく分かりません。『設計と進化の指針となる原理に体現された (略)構造』ってどんな構造っすか。
まぁそれはさておき。
人によっては、アプリケーションの各問題領域ごとのフレームワークやライブラリの選定・作成やそれらの使い方・組み合わせ方を規定し、全問題領域をカバーする、要件に適したフルスタックなフレームワークを作成することがアーキテクチャ確定であると思う人もいるのでは無いでしょうか。
というかまぁそれは私のことな訳ですが。
しかし、よくよく考えてみると、これは狭義の意味においてはアーキテクチャ確定のような気がしますが、だからといってフルスタックフレームワークが出来上がれば「後よろしく」と去って行くアーキテクトもいないと思います。
というか必ずしもフレームワークが必要な訳でも無いですし。
アーキテクチャを確定する人がアーキテクトだと考えれば、フルスタックフレームワークを作成し終わってもそれだけではアーキテクトの仕事は終わらない→フルスタックフレームワークを作成する以外にもアーキテクトには仕事がある→フルスタックフレームワークを作成するだけではアーキテクチャ確定は終わらない→語弊を恐れずに言い換えてみると、フルスタックフレームワークを作成するだけではアーキテクチャは確定しない→アーキテクチャ≠フルスタックフレームワーク(より正確に言うと、フルスタックフレームワーク ∈ アーキテクチャ)ということになるかと思います。
まぁようするに
何がいいたいのかというと、
実は決まった定義は無かったりするんじゃないか
ということです。そんな訳で、ちょっとお酒も入ったこの勢いで、広義の意味でのアーキテクチャを勝手に俺定義してみたいと思います。
アーキテクチャとは、要求をシステム化するための(主に技術的な)「手段」である
- システムの基本構造を決めることも
- Web化することも
- フレームワークを使用することも
- フレームワークを組み合わせることも
- その組み合わせ方を規定することも
- 開発ツールを選定することも
- 開発環境を整えることも
- 開発手法や開発プロセスを整備することも
- 全て、要求をシステム化するための手段である。
よって、
うむ。
ものすんごい俺定義
後悔はしていません。異論もお叱りも認めます。
