ソフトウェアアーキテクトが知るべき97のこと
O'REILLYから出ている「ソフトウェアアーキテクトが知るべき97のこと」を読んだ
珍しくAmazonが新刊を速攻で届けてくれた。つまり、予約があまりされなかったということだろう。技術書なんてそんなものだ…。
本書は、読んで字のごとくソフトウェアアーキテクトが知っておかなければいけないことや、何に注力していかないといけないのか？ということに関して数々の人がその考えを述べている。
本全体としてまとまっているというわけではなく、どちらかというと「あなたはどう思いますか？」って感じの質問に対しての解答集のようなものだ。
ちなみに、日本語訳は無いが原文はこちらにある
97 Things Every Software Architect Should Know - The Book
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book
日本語版である本書は、上記97の内容以外に日本人アーキテクトによる追加の内容11本を含んでいる
何を知るべきなのか
実際には、それぞれの立場や会社の性質。従事しているプロジェクトの内容やチーム編成によっても立ち位置は変わってくると思うので、「おー！そうだよね！！」って思うこともあれば「ふーん」と思うこともあった。
ただ、まとまっていないといっても、考えることというのは比較的似通っていて、言っていることはある程度のカテゴリに分けられている
- 技術を正しく把握・使うことの重要性
- コミュニケーションの重要性
- ビジネスを考えることの重要性
とってもざっくばらんに分けるとこんな感じじゃないかな？
たぶん、この人たちにとっては"ソフトウェアや技術に対する知識を持っているのは当たり前"で、プラスして何が重要かということが言いたいんだろう。技術ばっかりの頭でっかちになってはだめですよって。本書でたびたび出てくるところの「象牙の塔」ですね
面白いと思い、やはり悩ましいのはコミュニケーションだろう。
そんなときに必要なのは、昔から定評のあるテクノロジーです。実際、そのテクノロジーは、人類の歴史で最も重要な技術上のイノベーションです。何だと思いますか。それは話し合いです(P.6 Mark Ramm)
ソフトウェアアーキテクトをビジネスとデベロッパーの間に置くとなると、やはりこのスキルは必須になるだろう。これはプロジェクトをチームとして、会社として成功に導くためには間違いなく必要なことだ。
その割に、これにかかるコストだとか労力というものは軽視されがちで、結果としてプロジェクトはとん挫したりする。
また、もうひとつ。重要なコミュニケーションがある
ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。その手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。(P.84 Mark Richards)
そう。同じプラットフォーム、同じ言語で開発を行ったとしても別のチームのプログラマがすぐに他のチームで活躍できるとは限らない。仕様書が情報を知るための重要なリソースになることもあるが、プログラマであればまずソースを見ることが多いのではないか？その時に内容を理解したり、プログラムの意図や流れというものを理解するのにこれらデザインパターンというのは間違いなく威力を発揮する。
逆を言えば、本来であればデザインパターンを適用すると効果的な場面において適用されていないとすると、不必要な誤解を招く可能性まであるということだ。
私自身は、デザインパターンに対して習熟しているとはまだまだ言えない。
一人の技術者としてのコミュニケーションがとれるよう、勉強していかなければいけないと痛感することになった。
