間違いだらけのソフトウェア・アーキテクチャ の商品レビュー

トムエンゲルバーグ【著】,長谷川裕一,土岐孝平【訳】

2011/10/27

アーキテクトっていうのはこういう事している、というのが分かる本。
話の中で、オブジェクト指向やらコンピュータの歴史、Webの歴史などを引き合いに出している。
セミナーで話をしている、というスタイルで本を書いているので、技術書と言うよりかはほとんどエッセイ。
読みやすいといえば読みやすい。

2011/09/26

著者のユーモラスあふれるセミナーに参加しているかのように、対話形式で書かれており、ワクワクした気持ちで読める。
アーキテクトとは？アーキテクトが知らなければならない事や、プロジェクトの立ち上げから評価、派生開発に至るまでの一連の流れが書かれている。
話しと言っても概要レベルなので、詳細はネット等で調べる必要があるけど。
■派生開発のでは、清水さんが継承しているXDDPが紹介されている。海外でも有名になってきているんですね。
直接コンサルを受けた人間にとってはとても嬉しい事だ。
■実装ガイドライン、コーディング規約を用意して、おのおのが勝手なプログラムを作らないようにする。
■アプリケーションアーキテクチャを大きく分けると、物理層と論理層に分けられる。論理層にあるフレームワークなどは枯れて安定しているが、論理層はそのドメインによってビジネスロジックが異なるためしっかり設計する必要がある。 しかしこういう所は、外注やオフショアに出したりしている。

2011/08/05

会話形式（？）なので気軽に読める。
アーキテクトというものに対して漠然としたイメージしかなかったが、この本を読んでその感覚が意外と間違ってないんだなと思った。
具体的な技術は紹介程度で、アーキテクトの全体像と考え方、環境などについて書かれた本。

2011/07/27

アーキテクトとして活躍するトム・エンゲルバーグさん著。そしてSpringユーザ会で、WebLogic勉強会で有名な長谷川裕一さん、土岐孝平さんによる翻訳です。

「間違いだらけのソフトウェア・アーキテクチャ」とは私にとってとってもしっくり来るタイトルです。
建築でもソフトウェアでも同じだと思いますがアーキテクチャというのは唯一の解があるものではなく、同じ目的・機能を実現するのに幾通りもの方法があります。
正解がたくさんあるのと同時に、目的・機能を実現出来ていながら明らかに不正解と言えるアーキテクチャもあります。

この本は後々ボロを出さないためにも「間違いだらけ」にならないアーキテクチャを決定するための著者なりの方法論や経験が書かれています。
ただ、方法論といっても堅苦しいものではありません。アーキテクトとしてのベストプラクティスについてのセミナーの様子を一冊の本にまとめたという設定で、筆者の視点から饒舌に語られています。
さらにセミナー受講者としてシニア・マネージャやSE、宇宙人(!)など様々な立場の人が登場し、様々な角度からの質問をぶつけてくるのに対して軽妙な語り口で筆者が答えていくという面白いスタイルになっています。

経験豊富な筆者の話をあるある(笑)、と読み物として楽しむのも良いですし、筆者の経験を疑似体験して実際の開発に役立てるのも良いと思います。

体系的に方法論を学べる本ではありませんがどのようなレベル、立場の方でも何かしら得るものがある本だと思います。

私は最近エンジニアでないお客様に見積もりの提示やその根拠の説明をしなければならないことが多いのですが、本書でクローズアップされている「非機能要件」の定義についてはちょっとヒントを貰えた気がします。

なんだかざっくりとした書評になってしまいましたが、フランクな文体で書かれており肩の力を抜いて読める面白い本です。
# そのフランクな文体が長谷川さんと土岐さんを悩ませたことと思いますが・・・

ちなみにトム・エンゲルバーグさんは Java のスペシャリストみたいですが本書は特に Java に特化した内容ではありません。モダンなオープン系システムの開発に携わっている方であればすんなりと読めるはずです。

2013/11/24

・会話形式で、さらっと読める本。システム開発の細部でなく、全体を掴むのに良い。
・品質特性シナリオ、ATAM、DSM、派生開発、メトリクスなど、興味深い手法の概要を説明。当初で雰囲気を掴み、詳細は別の本で調べる感じ。

・アプリの論理層（ビジネスロジック）はすり合わせ技術が必要とされる為、（モジュール技術の）フレームワークは適さない

・アーキテクトの提案が妥当かユーザ側で判断できない場合、医療のセカンドオピニオンみたいな自衛策を取ると良い。

・車の設計では製造前に、試作、テスト／改良を繰り返す。しかし、ウオーターフォールでは、製造業と違って、試作、テスト／改良がなく、設計の後はいきなり製造に入ってしまう。（そして、製造後のテストで炎上というお決まりのパターン…）

・製造工場でも品質の為のテストはあるが、それは要件や設計のテストではない。あくまでも（大量生産での）不良部品や製造工程の不良を見つける為のもので、システム開発のテストとは異なる。そもそも、ソフトウェア開発の現場が製造工場を真似するのが間違っている。

・人間のやる事は結構しっちゃかめっちゃかで、それでいて最後はツジツマが合うようになっている。それを、プログラム（ビジネスロジック）で表現するのは、スゴく大変。

・大規模システムのスケジュールを日単位で見積もるのは、建設する高速道路の長さをミリ単位で予想するのと同じくらい馬鹿げている。

・（作中に登場するシニア・マネージャの台詞）サービスの追加とか変更に対して素早く柔軟に対応できたら、お金が取れないじゃないか。時間を掛けて修正するからこそ、お金が取れるんだろ？お客さんは時間にお金を払うって事を知らんのか！　→はぁー。いつまで、時間給の仕事を続ける気なんだろ…。

・（作中に登場するアジャイル教の教祖）開発は楽しくじゃ。楽しく工場で、奴隷の様に働かせて、時々お菓子をやって喜ばせるのじゃ！

2011/06/02

海外のユーモアのノリがあわないとつらい本かもしれない。
会話形式で書いてあるので、内容は濃くないけど、
逆にアーキテクチャについて堅苦しくない感じの本は
あまり見たことがないので貴重だと思う。

2011/06/03

[○11/05/29完読]強く共感できて面白かった。意外だったのは欧米でもこういう感性でアーキテクトという職責を観ている部分があるということ。もしかしたら著者自身が日本での仕事経験があるためかもしれない。それにしても日本でアーキテクチャ関係をやっていればより深く共感できるかもしれない。欧米と日本でどれくらいの温度差があるのかはこの本からは不明だった。あと、正直、スライドに重要性があるとは思えない。最後のDSMは私もよくやる。

2011/02/18

アーキテクチャやプラットフォームなどという言葉が流行っていますが、
本書はソフトウェア工学におけるアーキテクチャを
敷居が低く表現する努力をしています。

ソフトウェア工学そのものが進化の過程であり、
（近年進化しているのか？
以前に戻っているのか疑問に感じるところもありますが。。）
完全な正解がないと考えています。

為になったことを列挙しておきます。
・形式主義
・メトリクス
・DSM

2011/02/05

きれいごとじゃない、本音がちりばめられていて、共感。この本に出てくるキーワードを起点に、アーキテクチャの勉強を始めて見るのもよいかも。

2011/01/20

共感をもって最後まで読んだ。
説明がうまいなぁと思った。

この本にかかれていることはだいたい理解している人向けの本だと思う。
「あぁ、そうだよねぇ。」とか、「やっぱりそうなんだ。」とか、「そうそう！」とか、そういう共感が得られないと、「砕けた文章がずっと書かれているけど、内容は薄いよなぁ」とか、思っちゃって満足できないような気がする。

共感をもつことによって、自分に自身がつく。
自分だけじゃなくて、海の向こうのアーキテクチャが同じように考えていたってことがわかったことが、この本を読んでの収穫だ。

説明がうまいので、後輩に説明するときにこの本を引用すると楽ができるような気もした。

訳者がかなりの意訳をしている部分が多々あるような気がする。
原書も読みたいと思ったが、Ａｍａｚｏｎや紀伊国屋の検索とかでは見つからなかった。