間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)
- 技術評論社 (2010年8月17日発売)
本棚登録 : 327人
感想 : 38件
- Amazon.co.jp ・本 (176ページ)
- / ISBN・EAN: 9784774143439
感想・レビュー・書評
-
ソフトウエア・アーキテクトときくとなにやら怪しいと思ってしまう私。その理由は、アーキテクチャに言及するやつで、まともなプログラマに会ったことがないからなのだが、どうやらこの本の著者はまともらしい。こんなやつと一緒にプログラムを書いてみたいものである。
1
詳細をみるコメント0件をすべて表示 -
主にエンタープライズアプリケーションのアプリケーションアーキテクチャを念頭にした、ソフトウェアのアーキテクチャの読み物。かなり面白かった。砕けたセミナーの対話スタイルなので、さくさく読める。
アーキテクチャと何か？アーキテクトとは？アーキテクチャはどうあるべきか？どうやって作るか？どのように評価するか？などが書かれている。
ちょうど仕事で初めて大規模なアーキテクチャを考える段階にあったので、品質特性やATAMなど参考になることも多かった。
過去、EJBは確かにオーバースペックで貶された時期があったが、メインフレーム置き換えのような大規模なアーキテクチャを考える際には必要となることだという指摘もその通りだと思う(EJBが素晴らしいかどうかは別として。)
また、小規模なWebアプリケーションしか構築したことがない若い開発者が、メインフレームからの移行といった大規模なエンタープライズアプリケーションに取り組むことになるという筆者の懸念も理解できる。
アプリケーションアーキテクチャについて抽象的なことをわかりやすく解説しているので、PoEAA本の副読本としていいかも。
ただエンタープライズアプリケーション、DIやEJB、ドメインモデルなどの言葉が頻繁に出てくるので、ある程度の基礎知識がないと読んでも面白くないかもしれない。
何のことを指しているかわかるレベルなら、それらが実際、どういうものなのかを理解する助けになるかも。
Webアプリケーションやサービスについて下地がある人が大規模なアプリケーションに挑む時にもお勧め。
↓の引用もどうぞ。
1
-
著者のユーモラスあふれるセミナーに参加しているかのように、対話形式で書かれており、ワクワクした気持ちで読める。
アーキテクトとは？アーキテクトが知らなければならない事や、プロジェクトの立ち上げから評価、派生開発に至るまでの一連の流れが書かれている。
話しと言っても概要レベルなので、詳細はネット等で調べる必要があるけど。
■派生開発のでは、清水さんが継承しているXDDPが紹介されている。海外でも有名になってきているんですね。
直接コンサルを受けた人間にとってはとても嬉しい事だ。
■実装ガイドライン、コーディング規約を用意して、おのおのが勝手なプログラムを作らないようにする。
■アプリケーションアーキテクチャを大きく分けると、物理層と論理層に分けられる。論理層にあるフレームワークなどは枯れて安定しているが、論理層はそのドメインによってビジネスロジックが異なるためしっかり設計する必要がある。 しかしこういう所は、外注やオフショアに出したりしている。
1
-
アーキテクトとして活躍するトム・エンゲルバーグさん著。そしてSpringユーザ会で、WebLogic勉強会で有名な長谷川裕一さん、土岐孝平さんによる翻訳です。
「間違いだらけのソフトウェア・アーキテクチャ」とは私にとってとってもしっくり来るタイトルです。
建築でもソフトウェアでも同じだと思いますがアーキテクチャというのは唯一の解があるものではなく、同じ目的・機能を実現するのに幾通りもの方法があります。
正解がたくさんあるのと同時に、目的・機能を実現出来ていながら明らかに不正解と言えるアーキテクチャもあります。
この本は後々ボロを出さないためにも「間違いだらけ」にならないアーキテクチャを決定するための著者なりの方法論や経験が書かれています。
ただ、方法論といっても堅苦しいものではありません。アーキテクトとしてのベストプラクティスについてのセミナーの様子を一冊の本にまとめたという設定で、筆者の視点から饒舌に語られています。
さらにセミナー受講者としてシニア・マネージャやSE、宇宙人(!)など様々な立場の人が登場し、様々な角度からの質問をぶつけてくるのに対して軽妙な語り口で筆者が答えていくという面白いスタイルになっています。
経験豊富な筆者の話をあるある(笑)、と読み物として楽しむのも良いですし、筆者の経験を疑似体験して実際の開発に役立てるのも良いと思います。
体系的に方法論を学べる本ではありませんがどのようなレベル、立場の方でも何かしら得るものがある本だと思います。
私は最近エンジニアでないお客様に見積もりの提示やその根拠の説明をしなければならないことが多いのですが、本書でクローズアップされている「非機能要件」の定義についてはちょっとヒントを貰えた気がします。
なんだかざっくりとした書評になってしまいましたが、フランクな文体で書かれており肩の力を抜いて読める面白い本です。
# そのフランクな文体が長谷川さんと土岐さんを悩ませたことと思いますが・・・
ちなみにトム・エンゲルバーグさんは Java のスペシャリストみたいですが本書は特に Java に特化した内容ではありません。モダンなオープン系システムの開発に携わっている方であればすんなりと読めるはずです。
1
-
読みやすさの割にアーキテクチャにまつわる知識やノウハウが体系的に含まれている。アーキテクチャの評価を行うための手法など、実際に役立ちそう。
0
-
ソフトウェアアーキテクチャについて、過激、かつ辛辣に語られるセミナー形式の解説書。面白そうだったので同僚より拝借。
アーキテクチャについて、あえて体系立てもせず、やや精神論込みで語られていて面白かったです。原書の著者であるトム・エンゲルバーグ氏は日本での技術者経験もあるからなのか、現場開発における苦悩や実態も把握した上での説明が多く、「あるある」も多かったですね。まあ、それらに対して「決して解はない」ところは、やはりこの手の書籍のご愛嬌ですが(^-^; まあ、それがあればIT技術者はとっくに楽になってますね。
さて、少し中身の話。
アプリケーションをステレオやスピーカーに例えて論理と物理に分ける説明（依存性逆転の法則）は分かりやすい例えですね。実はこのあたり、今、自分が取り組んでいる仕組みの根底にあるパターンなのですが、これを周りにうまく説明できずに、理解してもらえなかったり、評価してもらえなかったり、苦労してきたんですね。参考にさせてもらおう。
このほか、システム開発を製造業の生産ラインに例えるのではなく、自動車の新モデル開発やBPMのようにビジネスプロセスの一部を常に変えて進める方法に例えた方が近いなど、システム開発現場の苦悩が分かっていない人々を説得するときに使えそうな表現も多くて、これまでの小難しい「アーキテクチャ」を、うまく粉砕している感じがよかったです。
最後にメモ。
ここでも言われているのは、早い段階からのプロト検証と修正の繰り返し（CIはもはや当たり前）。企画段階から、さっさと動くもの出していくくらいの感じ。
0
-
業務システムにおけるソフトウェアアーキテクチャとは何か、について論じた本。本書では、フレームワークなどを"物理アーキテクチャ"、業務アプリケーションなどを"論理アーキテクチャ"と定義していた。"ソフトウェアアーキテクチャ"と聞いて、具体的なイメージが湧かない人は、一度読んでおくと良い。
IT業界にはITアーキテクトという言葉があり、大体そういった場合の担当範囲はいわゆるソフトウェアアーキテクチャ(アプリ基盤)のようであるが、人や組織によって対象とする範囲が異なるため、本書で定義するような形で、自分は～までを職責と考える、と言えるようになりたいものである。
(でなければ、プロジェクトとして必要な人材を集めたつもりが、アーキテクチャという言葉の範囲の違いでミスマッチを産んでしまい、システム全体が崩壊しかねない）
0
-
ソフトウェアアーキテクチャに関する本というのはあまりない気がするが、いくつかまとめて読もうと思ったうちの1冊。セミナーでの会話形式のため、最初はかなり軽い本かと思ったが読み進めるうちに、経験から得られたであろう深い内容がかなり含まれていて、面白かった。また後半のアーキテクチャの分析・評価については、うまく応用すれば実用も可能そうだ。
いずれにしろソフトウェアアーキテクチャ、そしてアーキテクトの仕事を理解するにはよい1冊なのではないかと思う。
0
-
予想以上に面白かった。
このたぐいの本は、アカデミックかコマーシャルベースの本が多いが、この本は実務にもとづく事が多く、それでいて楽しく読む事ができた。
0
-
「第4章 品質特性シナリオ」が一番参考になりました。そこには、こんなことが書いてあります。
まず簡単に言うと、アーキテクチャは、基本的に機能要求と非機能要求、そして制約条件と前提条件などから導かれる。ちょっと補足すると、前提条件は「お金はいくらでも使って良い」というプラスの条件、制約条件とは「予算は100万円以内」とかマイナスの条件のことって僕は区別している。
品質特性シナリオには重要な品質特性ごとに、これから作ろうとしているモノ（成果物：artifact）に対して、誰が（刺激の発生源：source of stimulus）、どんな時に（環境：environment）、どんなことをすると（刺激：stumulus）、どういう結果が(応答：response）、どれくらいで返ってくるか（応答測定：response measure）を描くんだ。
注意してほしいのは「誰が」っていうのは必ずしも人ではないってことだ。
あと「どのくらいで返ってくるか」というのも時間だけじゃない。資金などのコストやアンケート結果のパーセンテージってこともある。基本的には定量的に測定できなければならないんだけどね。
それと、これは一般的な品質特性シナリオにはないんだけど、僕は誰が（刺激の発生源：source of stimulus）ってところい、どんな状況（status）なのかっていうのも、付け加えたりするんだ。こいつは、最近のシステム利用者っていうのが、空調の効いたデスクの快適な椅子に座ってパソコンからシステムにアクセスしているだけじゃなくなってきているからなんだ。たとえば、システム利用者が屋外にいて走っていたり、自宅のソファに寝転がって画面を横にして見たりとか、そういうことも考慮する必要があるからなんだ。つまり、こうした追加項目がないと、モバイルを端末にするって話が出てこないんだな。
これを読むと、アーキテクトがアーキテクチャを作る前に分析していることってテスト技術者がテスト分析（テスト要求分析）で分析している内容と同じなんだということが分かります。
ということで、テスト関連の人は、第4章を読んでおくといいですよ。おすすめです。
0
-
会話形式で進むので、一見読み進めやすいが、内容がいったりきたりして、理解はしづらい気がする。
休憩時間に読んで、アーキテクトについて、なんとな～く知るには丁度良い。ユーモアのセンスもあるし。
なんとな～く知っておいて、細かいことについて気になったら他書を読む、という使い方が良さげ。
0
-
読み物として。
これだけ読んで勉強になるような内容ではないが、ものすごく気軽に読み進められる。
生の声というか現職のアーキテクトが考えていることに触れられるので、別途勉強したことや知識などが身近に感じられるようになりより理解が深まる。
0
-
アーキテクトっていうのはこういう事している、というのが分かる本。
話の中で、オブジェクト指向やらコンピュータの歴史、Webの歴史などを引き合いに出している。
セミナーで話をしている、というスタイルで本を書いているので、技術書と言うよりかはほとんどエッセイ。
読みやすいといえば読みやすい。
0
-
会話形式（？）なので気軽に読める。
アーキテクトというものに対して漠然としたイメージしかなかったが、この本を読んでその感覚が意外と間違ってないんだなと思った。
具体的な技術は紹介程度で、アーキテクトの全体像と考え方、環境などについて書かれた本。
0
-
・会話形式で、さらっと読める本。システム開発の細部でなく、全体を掴むのに良い。
・品質特性シナリオ、ATAM、DSM、派生開発、メトリクスなど、興味深い手法の概要を説明。当初で雰囲気を掴み、詳細は別の本で調べる感じ。
・アプリの論理層（ビジネスロジック）はすり合わせ技術が必要とされる為、（モジュール技術の）フレームワークは適さない
・アーキテクトの提案が妥当かユーザ側で判断できない場合、医療のセカンドオピニオンみたいな自衛策を取ると良い。
・車の設計では製造前に、試作、テスト／改良を繰り返す。しかし、ウオーターフォールでは、製造業と違って、試作、テスト／改良がなく、設計の後はいきなり製造に入ってしまう。（そして、製造後のテストで炎上というお決まりのパターン…）
・製造工場でも品質の為のテストはあるが、それは要件や設計のテストではない。あくまでも（大量生産での）不良部品や製造工程の不良を見つける為のもので、システム開発のテストとは異なる。そもそも、ソフトウェア開発の現場が製造工場を真似するのが間違っている。
・人間のやる事は結構しっちゃかめっちゃかで、それでいて最後はツジツマが合うようになっている。それを、プログラム（ビジネスロジック）で表現するのは、スゴく大変。
・大規模システムのスケジュールを日単位で見積もるのは、建設する高速道路の長さをミリ単位で予想するのと同じくらい馬鹿げている。
・（作中に登場するシニア・マネージャの台詞）サービスの追加とか変更に対して素早く柔軟に対応できたら、お金が取れないじゃないか。時間を掛けて修正するからこそ、お金が取れるんだろ？お客さんは時間にお金を払うって事を知らんのか！ →はぁー。いつまで、時間給の仕事を続ける気なんだろ…。
・（作中に登場するアジャイル教の教祖）開発は楽しくじゃ。楽しく工場で、奴隷の様に働かせて、時々お菓子をやって喜ばせるのじゃ！
0
-
海外のユーモアのノリがあわないとつらい本かもしれない。
会話形式で書いてあるので、内容は濃くないけど、
逆にアーキテクチャについて堅苦しくない感じの本は
あまり見たことがないので貴重だと思う。
0
-
[○11/05/29完読]強く共感できて面白かった。意外だったのは欧米でもこういう感性でアーキテクトという職責を観ている部分があるということ。もしかしたら著者自身が日本での仕事経験があるためかもしれない。それにしても日本でアーキテクチャ関係をやっていればより深く共感できるかもしれない。欧米と日本でどれくらいの温度差があるのかはこの本からは不明だった。あと、正直、スライドに重要性があるとは思えない。最後のDSMは私もよくやる。
0
-
アーキテクチャやプラットフォームなどという言葉が流行っていますが、
本書はソフトウェア工学におけるアーキテクチャを
敷居が低く表現する努力をしています。
ソフトウェア工学そのものが進化の過程であり、
（近年進化しているのか？
以前に戻っているのか疑問に感じるところもありますが。。）
完全な正解がないと考えています。
為になったことを列挙しておきます。
・形式主義
・メトリクス
・DSM
0
-
きれいごとじゃない、本音がちりばめられていて、共感。この本に出てくるキーワードを起点に、アーキテクチャの勉強を始めて見るのもよいかも。
0
-
共感をもって最後まで読んだ。
説明がうまいなぁと思った。
この本にかかれていることはだいたい理解している人向けの本だと思う。
「あぁ、そうだよねぇ。」とか、「やっぱりそうなんだ。」とか、「そうそう！」とか、そういう共感が得られないと、「砕けた文章がずっと書かれているけど、内容は薄いよなぁ」とか、思っちゃって満足できないような気がする。
共感をもつことによって、自分に自身がつく。
自分だけじゃなくて、海の向こうのアーキテクチャが同じように考えていたってことがわかったことが、この本を読んでの収穫だ。
説明がうまいので、後輩に説明するときにこの本を引用すると楽ができるような気もした。
訳者がかなりの意訳をしている部分が多々あるような気がする。
原書も読みたいと思ったが、Ａｍａｚｏｎや紀伊国屋の検索とかでは見つからなかった。
0
-
アーキテクチャの設計、構築をするための基礎を仮想的なセミナー形式で説明しています。ジョーク交じりで教科書的な書とは一線を画しており、楽しく読めます。
0
長谷川裕一の作品
