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

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

2020/06/07

読みやすさの割にアーキテクチャにまつわる知識やノウハウが体系的に含まれている。アーキテクチャの評価を行うための手法など、実際に役立ちそう。

2018/10/23

ソフトウエア・アーキテクトときくとなにやら怪しいと思ってしまう私。その理由は、アーキテクチャに言及するやつで、まともなプログラマに会ったことがないからなのだが、どうやらこの本の著者はまともらしい。こんなやつと一緒にプログラムを書いてみたいものである。

2014/02/11

ソフトウェアアーキテクチャについて、過激、かつ辛辣に語られるセミナー形式の解説書。面白そうだったので同僚より拝借。

アーキテクチャについて、あえて体系立てもせず、やや精神論込みで語られていて面白かったです。原書の著者であるトム・エンゲルバーグ氏は日本での技術者経験もあるからなのか、現場開発における苦悩や実態も把握した上での説明が多く、「あるある」も多かったですね。まあ、それらに対して「決して解はない」ところは、やはりこの手の書籍のご愛嬌ですが(^-^; まあ、それがあればIT技術者はとっくに楽になってますね。

さて、少し中身の話。
アプリケーションをステレオやスピーカーに例えて論理と物理に分ける説明（依存性逆転の法則）は分かりやすい例えですね。実はこのあたり、今、自分が取り組んでいる仕組みの根底にあるパターンなのですが、これを周りにうまく説明できずに、理解してもらえなかったり、評価してもらえなかったり、苦労してきたんですね。参考にさせてもらおう。

このほか、システム開発を製造業の生産ラインに例えるのではなく、自動車の新モデル開発やBPMのようにビジネスプロセスの一部を常に変えて進める方法に例えた方が近いなど、システム開発現場の苦悩が分かっていない人々を説得するときに使えそうな表現も多くて、これまでの小難しい「アーキテクチャ」を、うまく粉砕している感じがよかったです。

最後にメモ。
ここでも言われているのは、早い段階からのプロト検証と修正の繰り返し（CIはもはや当たり前）。企画段階から、さっさと動くもの出していくくらいの感じ。

2013/10/13

業務システムにおけるソフトウェアアーキテクチャとは何か、について論じた本。本書では、フレームワークなどを"物理アーキテクチャ"、業務アプリケーションなどを"論理アーキテクチャ"と定義していた。"ソフトウェアアーキテクチャ"と聞いて、具体的なイメージが湧かない人は、一度読んでおくと良い。

IT業界にはITアーキテクトという言葉があり、大体そういった場合の担当範囲はいわゆるソフトウェアアーキテクチャ(アプリ基盤)のようであるが、人や組織によって対象とする範囲が異なるため、本書で定義するような形で、自分は～までを職責と考える、と言えるようになりたいものである。
(でなければ、プロジェクトとして必要な人材を集めたつもりが、アーキテクチャという言葉の範囲の違いでミスマッチを産んでしまい、システム全体が崩壊しかねない）

2013/05/12

ソフトウェアアーキテクチャに関する本というのはあまりない気がするが、いくつかまとめて読もうと思ったうちの1冊。セミナーでの会話形式のため、最初はかなり軽い本かと思ったが読み進めるうちに、経験から得られたであろう深い内容がかなり含まれていて、面白かった。また後半のアーキテクチャの分析・評価については、うまく応用すれば実用も可能そうだ。
いずれにしろソフトウェアアーキテクチャ、そしてアーキテクトの仕事を理解するにはよい1冊なのではないかと思う。

2013/02/19

主にエンタープライズアプリケーションのアプリケーションアーキテクチャを念頭にした、ソフトウェアのアーキテクチャの読み物。かなり面白かった。砕けたセミナーの対話スタイルなので、さくさく読める。
アーキテクチャと何か？アーキテクトとは？アーキテクチャはどうあるべきか？どうやって作るか？どのように評価するか？などが書かれている。

ちょうど仕事で初めて大規模なアーキテクチャを考える段階にあったので、品質特性やATAMなど参考になることも多かった。
過去、EJBは確かにオーバースペックで貶された時期があったが、メインフレーム置き換えのような大規模なアーキテクチャを考える際には必要となることだという指摘もその通りだと思う(EJBが素晴らしいかどうかは別として。)
また、小規模なWebアプリケーションしか構築したことがない若い開発者が、メインフレームからの移行といった大規模なエンタープライズアプリケーションに取り組むことになるという筆者の懸念も理解できる。

アプリケーションアーキテクチャについて抽象的なことをわかりやすく解説しているので、PoEAA本の副読本としていいかも。
ただエンタープライズアプリケーション、DIやEJB、ドメインモデルなどの言葉が頻繁に出てくるので、ある程度の基礎知識がないと読んでも面白くないかもしれない。
何のことを指しているかわかるレベルなら、それらが実際、どういうものなのかを理解する助けになるかも。
Webアプリケーションやサービスについて下地がある人が大規模なアプリケーションに挑む時にもお勧め。
↓の引用もどうぞ。

2013/01/27

予想以上に面白かった。
このたぐいの本は、アカデミックかコマーシャルベースの本が多いが、この本は実務にもとづく事が多く、それでいて楽しく読む事ができた。

2012/05/01

「第4章　品質特性シナリオ」が一番参考になりました。そこには、こんなことが書いてあります。

　まず簡単に言うと、アーキテクチャは、基本的に機能要求と非機能要求、そして制約条件と前提条件などから導かれる。ちょっと補足すると、前提条件は「お金はいくらでも使って良い」というプラスの条件、制約条件とは「予算は100万円以内」とかマイナスの条件のことって僕は区別している。

品質特性シナリオには重要な品質特性ごとに、これから作ろうとしているモノ（成果物：artifact）に対して、誰が（刺激の発生源：source of stimulus）、どんな時に（環境：environment）、どんなことをすると（刺激：stumulus）、どういう結果が(応答：response）、どれくらいで返ってくるか（応答測定：response measure）を描くんだ。
　注意してほしいのは「誰が」っていうのは必ずしも人ではないってことだ。
　あと「どのくらいで返ってくるか」というのも時間だけじゃない。資金などのコストやアンケート結果のパーセンテージってこともある。基本的には定量的に測定できなければならないんだけどね。
　それと、これは一般的な品質特性シナリオにはないんだけど、僕は誰が（刺激の発生源：source of stimulus）ってところい、どんな状況（status）なのかっていうのも、付け加えたりするんだ。こいつは、最近のシステム利用者っていうのが、空調の効いたデスクの快適な椅子に座ってパソコンからシステムにアクセスしているだけじゃなくなってきているからなんだ。たとえば、システム利用者が屋外にいて走っていたり、自宅のソファに寝転がって画面を横にして見たりとか、そういうことも考慮する必要があるからなんだ。つまり、こうした追加項目がないと、モバイルを端末にするって話が出てこないんだな。

これを読むと、アーキテクトがアーキテクチャを作る前に分析していることってテスト技術者がテスト分析（テスト要求分析）で分析している内容と同じなんだということが分かります。
ということで、テスト関連の人は、第4章を読んでおくといいですよ。おすすめです。

2012/03/11

会話形式で進むので、一見読み進めやすいが、内容がいったりきたりして、理解はしづらい気がする。

休憩時間に読んで、アーキテクトについて、なんとな～く知るには丁度良い。ユーモアのセンスもあるし。
なんとな～く知っておいて、細かいことについて気になったら他書を読む、という使い方が良さげ。

2011/12/25

読み物として。
これだけ読んで勉強になるような内容ではないが、ものすごく気軽に読み進められる。
生の声というか現職のアーキテクトが考えていることに触れられるので、別途勉強したことや知識などが身近に感じられるようになりより理解が深まる。