SA取ったど〜(´・ω・`)

はい、SAも取ったので、恒例の「資格を取ったからこそdisりますよ」シリーズです(・∀・;)

さて、一般的には、「システムアーキテクト」と言う言葉は2通りくらいの意味で使われていると思うわけですが( ・ω・)

一つ目のケースは、こういう感じのやつで。

• 戦略的〜ビジネスの観点から〜みたいな話と、テクノロジーをリンクして語る
• アーキテクトと言うか、CIO補佐というかCTOと言うか
• スーパーマンで、そんな人は日本に何人もいないよ、みたいな人達(´д｀;)

二つ目のケースは、こういうの感じのもので。

• フレームワークの選定をしたり(・ω・)
• システム構成のレイヤと機能による水平/垂直の分割をしたり(・ω・)
• トランザクション戦略を決定したり(・ω・)
• 一通りのサンプルを作って展開したり(・ω・)
• 非機能要件を考慮して処理を非同期化することを決めたりとかも(・ω・)
• 足りないライブラリは自作したり(・ω・)
• ROIやシステムのライフサイクルメンバーのスキルレベルなんかを考慮して方針を決定したり(・ω・)
• あるいは自称アーキテクトだったり(´д｀;)
• 格好つけなければチーフプログラマーで良いじゃん( ﾟдﾟ)
• 自分は使い分けるために「狭義の意味でのアーキテクト」とかよぶもの

…っとまあ、アーキテクトという言葉は文脈により異なる意味や、都合良く使われたりするものだと感じているわけですが(・∀・;)

っで、情報処理技術者試験で言うところのシステムアーキテクトっていう奴は、上の二つともまた違うものを想定しているかな〜っという感じで(ﾟДﾟ;)
少なくとも、海外の書籍に出てくるシステムアーキテクト(こっちは狭義の意味でのアーキテクトの方が近いかな？)から想像するものとは別の、日本的なるものが情報処理技術者試験のSAだと思うわけで(´・ω・`)
しかも、その想定する人物像というのが、ちょっとどうなんだろう…というのが自分の考えなわけですが。

どこが気に入らないかと言えば、「アーキテクト」を入れている割には非機能要件に関するアーキテクチャ設計能力があまり求められていないところと言うか(´・ω・`)
どちらかというと、非機能要件的なアーキテクチャはあまり考えなくて良い世界での、業務要件的な事が主体な感じで。*1

特に酷いと思ったのが、情処で言うSAの人物像として、プログラミングはやらないで上流工程(笑)をやる人、みたいな定義しているところとかですね(・∀・#)
想定する人物像には、SAはプログラム開発工程を担当しないとかも書いてあるんですよ。
氏ねば、良いのにネ(・∀・)
そして、専門知識についてはNEやDBに相談する、みたいな事も書いてあって、おまえは何をやるの( ﾟдﾟ)？、っとか。
だいたい「アーキテクト」がテクノロジースペシャリスト系に分類されていないってどういうこと(ﾟДﾟ )？、っとか。

まあ、何をやるか決めるところまでやって、どうやるかには一切関与しないというポジションも無くはないですが、それをアーキテクトとか言うなよ、って。
アーキテクトと名乗るからには、手を汚して、自分で正しさを判断してなんぼでしょ、つって。
あれですか？、「プログラマー」と「PG」、海外で言うところの「Systems Engineer」と「SE」が異なるものを意味するように、洋書に書いてるような「システムアーキテクト」と「SA」も違うものを指す、っという理解でOKですか(´д｀;)？

まあ、情処で言うところのSAみたいな人が不要と言うわけではないけど、この内容ならむしろ「上流SE(笑)」「Advanced SE :p」略してASとかで良いじゃんなんて思ってみたり(・∀・)
っというか、昔のAEから変える必要があったの( ﾟдﾟ)？、っとか。

っで、中途半端に格好つけた名称を使うことにより、非機能要件とか本当の意味でのアーキテクチャとかが、かえって軽視されないかが一番の心配事項なわけですが(´・ω・`)
今のSAの内容では、アーキテクチャ設計の重要性が伝わらないよね〜、と思ったりして。

少し真面目な話をすれば、PM、テクノロジースペシャリスト、ドメインエキスパートによる三権分立というやり方は鉄板なので、現行のSAは分割して、非機能要件的な面を主体とした新SAと、もっと業務系の色を強くした「ドメインエキスパート」略してDEみたいなものにするのが良いんじゃないかと思うわけですが(・ω・)

今の内容の資格を持って「私はアーキテクトでござ〜い、設計は任せてくだし」とか言われても、そんなうぜーバカはまともに相手をしなくて良いかと思っちゃうしね(´・ω・`)
だいたいですよ、2〜3年くらい前までならまだしも、クラウドとかサービスシフトとかマルチパラダイム設計と言っている今時の開発では、開発メンバー全員に狭義のアーキテクト程度の意志決定能力は求められるし、アーキテクトを自称したい人にはもう一段上の設計能力が求められる時代だと思うわけでして(・∀・;)
ピントのずれたSAとか、業界の不健全な発展に貢献するものだと思ったり、ぬるい事言ってる自称アーキテクトは、おウンコ召し上がれでございますわ、なんつって(・∀・)

アーキテクトという言葉はどうでも良いけど、アーキテクチャを軽視しないためによんでおくべき本

…とかいうのをやろうとも思ったんだけど、良く考えたらプログラマ向け10冊(ただし本家、カレー方面のみ)とそう変わらない様な気もしてきた(・ω・;)ので、アーキテクトっぽい読み物として、読みやすく楽しめる本をいくつか紹介してみたいと思います(・∀・)

まずは読んで笑えて楽しめることろから。

間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)

これは読んでて爆笑しましたよ(・∀・)
笑えるだけでなく、ちゃんと参考になることも書いてあるし。

っで、今まで何回か紹介していますが、次はこれ。

Release It! 本番用ソフトウェア製品の設計とデプロイのために

併せて読みたいというとこではこちらもどうぞ。

Manage It! 現場開発者のための達人式プロジェクトマネジメント

っで、アーキテクトとつく書籍と言うことで、この辺も。

ソフトウェアアーキテクトが知るべき97のこと

キノコ亭シメジについてはまた近いうちに(・ω・)

っで、アーキテクチャというか、若干Web屋よりの基礎教養的な内容になりますが、技評のこのシリーズもどうぞ(・∀・)

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

あとこれも。

4Gbpsを超えるWebサービス構築術

コンシューマーWeb屋だけでなくイントラSI屋であっても、この辺は一通り読んでおくべきかなっと(・ω・)

っで、アーキテクトついでで思い出したけど、〜のやってはいけない、みたいなムックがありましたが。
アレは一部微妙なところがあるというか、アーキテクトだけでなく誰でも知っておくべき事が書いてあったりだとかで、紹介はしませんが。
つーかね、アーキテクトって言うからには守についてだけ語っていても駄目で、破離の検証、実践を常に行っていないとね(｀・ω・´)

アーキテクトの能力なんて、理論と実践の反復でしか身につかないと思うわけで(・ω・)

• 戦略的に理論や知識を蓄積する、プロジェクトを通してインバスケットで意志決定を繰り返す
• 数字(例えば原価)としてその成果を確認する
• 理論と実践の反復を行い、成果を確認することで、やっと基本となる型がわかってくる
• でも、そこはまだアーキテクトとしての出発点にすぎなくて(´д｀;)
• 知識の蓄積、実践での試行錯誤、その結果のフィードバック
• いくつものプロジェクトでそれを繰り返すことで、破の段階から離の段階へと移行し、やっと自信を持って、アーキテクチャについて語れるようになるヽ(・∀・)ノ

…っていう感じだと思うのよね(・ω・)？

実践と試行錯誤無き知識は「頭でっかち」って言うし、仮説とフィードバックの無い試行錯誤は「無駄な努力」って言うんですよ、つって(・∀・;)

っで、書籍の話に戻りますが、今回は読み物的なところを紹介しているので、SEのIT Architects' Archiveあたりは除外。
あと、PoEAAとかそっちも除外。
この辺は読む価値があるものなので、真摯にアーキテクトを目指す方は是非読んでくださいな(・∀・)

あと、書籍じゃないけど、アーキテクトを名乗るならフレームワークのソースは読め、つって(｀・ω・´)
出来ればいろんな言語のものを、比較したりもしながら。

…っで、情処のSAをdisったり、アーキテクトについてちょっとだけ語ってみたりしたわけですが(・ω・)
まあ、なんだかんだ言いつつ、報奨金はありがたく頂くんですけどね〜(・∀・)

*1:これは、プログラムなんて制御構造がかければ十分だ、SQLが出来ればシステムは作れる、…的な、典型的なSI屋の発想に繋がっていく気もするわけですが、それをアーキテクトと言われてもねぇ〜(´д｀)