UMLについての導入失敗例です。
それも、UMLを使うことを目的にした失敗例ですから、当然の結果です。
もう少し、活かせる使い方を解説して欲しかったです。
対象読者は新しい技術を使えば何とかなると思っている。頭の固い上層部です。
第二部は、UMLとはまったく関係のない話。
アーキテクトについてです。
内容は第一部より良かったのですが、
期待していない話です。タイトルを変えた方がよいと思います。
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
UMLは手段 (技評SE新書 005) 新書 – 2006/10/25
荒井 玲子
(著)
「Software People」の特集の書籍化。Vol.3の特集「uml導入の勝ち組と負け組」と、Vol.6の特集「アーキテクトに未来を賭けた」をもとに加筆・修正し、再構成します。ベストセラー「ソフトウェア開発で伸びる人、伸びない人」(技術評論社)、「UMLによるオブジェクト指向モデリングセルフレビューノート」(ディー・アート)の著者による、SE必読の書です。SE・プログラマーはもちろん、アーキテクト、プロジェクトマネジャー、管理者まで、ソフトウェアに携わるすべての人々に参考になる内容です。
- 本の長さ200ページ
- 言語日本語
- 出版社技術評論社
- 発売日2006/10/25
- ISBN-104774129372
- ISBN-13978-4774129372
登録情報
- 出版社 : 技術評論社 (2006/10/25)
- 発売日 : 2006/10/25
- 言語 : 日本語
- 新書 : 200ページ
- ISBN-10 : 4774129372
- ISBN-13 : 978-4774129372
- Amazon 売れ筋ランキング: - 1,723,769位本 (本の売れ筋ランキングを見る)
- - 88,288位投資・金融・会社経営 (本)
- - 98,062位新書
- - 150,042位ビジネス・経済 (本)
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
星5つ中3つ
5つのうち3つ
全体的な星の数と星別のパーセンテージの内訳を計算するにあたり、単純平均は使用されていません。当システムでは、レビューがどの程度新しいか、レビュー担当者がAmazonで購入したかどうかなど、特定の要素をより重視しています。 詳細はこちら
7グローバルレーティング
虚偽のレビューは一切容認しません
私たちの目標は、すべてのレビューを信頼性の高い、有益なものにすることです。だからこそ、私たちはテクノロジーと人間の調査員の両方を活用して、お客様が偽のレビューを見る前にブロックしています。 詳細はこちら
コミュニティガイドラインに違反するAmazonアカウントはブロックされます。また、レビューを購入した出品者をブロックし、そのようなレビューを投稿した当事者に対して法的措置を取ります。 報告方法について学ぶ
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2007年2月22日に日本でレビュー済み
第一部は、UML導入失敗例と導入失敗の分析。企業はUMLをどう導入すべきかという説明。
第二部は、アーキテクトについての説明とアーキテクトの育成方法を記述している。
第二部からいきなりアーキテクトがテーマになっているが、UMLとアーキテクトの関連がさっぱりわからない。
著者は、おそらくアーキテクトに関することを書きたかったのだろう。
その前振りとして、UMLを選んだのだと思う。
いずれせよ、会社として組織的にUMLを導入し、アーキテクトを育成するにはどうすればよいか論じた本。
アーキテクトを育成したいと考えていて、かつ、会社の運営方針を決定できる立場の人にとっては読む意味があると思う。
それ以外の人が、よんでも得るものは少ない。
第二部は、アーキテクトについての説明とアーキテクトの育成方法を記述している。
第二部からいきなりアーキテクトがテーマになっているが、UMLとアーキテクトの関連がさっぱりわからない。
著者は、おそらくアーキテクトに関することを書きたかったのだろう。
その前振りとして、UMLを選んだのだと思う。
いずれせよ、会社として組織的にUMLを導入し、アーキテクトを育成するにはどうすればよいか論じた本。
アーキテクトを育成したいと考えていて、かつ、会社の運営方針を決定できる立場の人にとっては読む意味があると思う。
それ以外の人が、よんでも得るものは少ない。
2006年12月29日に日本でレビュー済み
第1部 UMLは手段
-なぜUMLで失敗するのか
-負け組パターンを分析する
-勝ち組はここが違う
-コアコンピタンス経営によるUML戦略
第2部 アーキテクトに未来を賭けた
-システムトラブルはなぜ繰り返されるのか
-アーキテクトに向いている人、向いていない人
-間違いだらけのアーキテクト選び
-アーキテクトを育成する
第1部「UMLは手段」で
UMLの記述方法などは一切書いていません。
本書の目的はUMLを勉強するためではなく
UMLを採用してみようとか、
UMLを採用してみて失敗した人に
UMLを採用するべきかを判断するために書かれていと思う。
第2部「アーキテクトに未来を賭けた」は、
会社はどのような人をアーキテクトにすればよいか。
アーキテクトの育て方などが載っています。
こちらは最近のはやりのアーキテクトについての説明で
タイトルとは直接関連しない。
-なぜUMLで失敗するのか
-負け組パターンを分析する
-勝ち組はここが違う
-コアコンピタンス経営によるUML戦略
第2部 アーキテクトに未来を賭けた
-システムトラブルはなぜ繰り返されるのか
-アーキテクトに向いている人、向いていない人
-間違いだらけのアーキテクト選び
-アーキテクトを育成する
第1部「UMLは手段」で
UMLの記述方法などは一切書いていません。
本書の目的はUMLを勉強するためではなく
UMLを採用してみようとか、
UMLを採用してみて失敗した人に
UMLを採用するべきかを判断するために書かれていと思う。
第2部「アーキテクトに未来を賭けた」は、
会社はどのような人をアーキテクトにすればよいか。
アーキテクトの育て方などが載っています。
こちらは最近のはやりのアーキテクトについての説明で
タイトルとは直接関連しない。
2006年11月23日に日本でレビュー済み
本書は、「UML導入について」、「ITアーキテクト育成について」の2部構成となっています。本書はUMLのリファレンスではありませんので、記述方法などは一切書いていません。UMLを勉強する方よりもUMLを導入するかどうかを判断する立場の方にお勧めの本です。
一部目の「UML導入について」は、物語風のわかりやすいUML導入失敗事例を例にして、UMLは何のために導入するのか、導入失敗の原因は何か、導入成功に導くためにはどうすればよいのか、経営の視点からどのようなUML技術者を揃えればよいのかなどを解説しています。
二部目の「ITアーキテクト育成について」は、アーキテクトに向き・不向きな人、会社のどのような人をアーキテクトにすればよいか、アーキテクトの育て方などが載っています。育て方に関しては、一般的な技術者の育成計画にアーキテクトの要素を加味した程度のものであり、本書を読めばアーキテクトが育成できるわけではないと思います。
実は私は、作者の荒井玲子氏の元同僚でして、わかりやすい表現を使った文章は氏の人柄が出ているなぁ..と、思いながら読んでいました。
一部目の「UML導入について」は、物語風のわかりやすいUML導入失敗事例を例にして、UMLは何のために導入するのか、導入失敗の原因は何か、導入成功に導くためにはどうすればよいのか、経営の視点からどのようなUML技術者を揃えればよいのかなどを解説しています。
二部目の「ITアーキテクト育成について」は、アーキテクトに向き・不向きな人、会社のどのような人をアーキテクトにすればよいか、アーキテクトの育て方などが載っています。育て方に関しては、一般的な技術者の育成計画にアーキテクトの要素を加味した程度のものであり、本書を読めばアーキテクトが育成できるわけではないと思います。
実は私は、作者の荒井玲子氏の元同僚でして、わかりやすい表現を使った文章は氏の人柄が出ているなぁ..と、思いながら読んでいました。
2009年10月3日に日本でレビュー済み
新書は、専門書を読む気にさせれば成功だと思う。
本書は、新書の枠を超える実践的な書籍だと思う。
UMLは、道具である。
道具としての価値以外のものを売りにしている人達がいかに失敗してきたかを説明している。
UML関連文献でも、本当に必要なUMLの本と、
読む価値のないUMLの本が見分けられるようになれば成功だと思う。
たとえば、本書を読んだあとで、
「UMLモデリング入門 本質をとらえるシステム思考とモデリング心理学」 児玉公信
を見ながら、実際、図を書いてみてはいかがでしょうか。
アーキテクトについては、
たとえば本書を読んだあとで、
「コンピュータの構成と設計」 デイビッド・A. パターソン、ジョン・L. ヘネシー
「コンピュータアーキテクチャ 定量的アプローチ」
を読むようなら成功だと思う。
成功かどうかは、読者が次にどの本を読むかで決まるのかもしれない。
ps.
疑問に思ったのは、アーキテクトに関して、
「人にまかせる」
ことを正としている点だ。
自分の周りのアーキテクトでは、OSにしろ、コンパイラにしろ、ネットワークプロトコルにしろ、
人にまかせるのが嫌いだから、自分でほとんど設計している。
人にまかせるのが好きな人は、アーキテクトではなく、アーキテクトの作ったアーキテクチャを使う人のことではないかと感じた。
ps.
Enterprise Architectを購入すると、
「UMLモデリング入門 本質をとらえるシステム思考とモデリング心理学」
「その場でつかえるしっかり学べるUML2.0 」
などの本の図の書き方の資料があるらしい。
本書は、新書の枠を超える実践的な書籍だと思う。
UMLは、道具である。
道具としての価値以外のものを売りにしている人達がいかに失敗してきたかを説明している。
UML関連文献でも、本当に必要なUMLの本と、
読む価値のないUMLの本が見分けられるようになれば成功だと思う。
たとえば、本書を読んだあとで、
「UMLモデリング入門 本質をとらえるシステム思考とモデリング心理学」 児玉公信
を見ながら、実際、図を書いてみてはいかがでしょうか。
アーキテクトについては、
たとえば本書を読んだあとで、
「コンピュータの構成と設計」 デイビッド・A. パターソン、ジョン・L. ヘネシー
「コンピュータアーキテクチャ 定量的アプローチ」
を読むようなら成功だと思う。
成功かどうかは、読者が次にどの本を読むかで決まるのかもしれない。
ps.
疑問に思ったのは、アーキテクトに関して、
「人にまかせる」
ことを正としている点だ。
自分の周りのアーキテクトでは、OSにしろ、コンパイラにしろ、ネットワークプロトコルにしろ、
人にまかせるのが嫌いだから、自分でほとんど設計している。
人にまかせるのが好きな人は、アーキテクトではなく、アーキテクトの作ったアーキテクチャを使う人のことではないかと感じた。
ps.
Enterprise Architectを購入すると、
「UMLモデリング入門 本質をとらえるシステム思考とモデリング心理学」
「その場でつかえるしっかり学べるUML2.0 」
などの本の図の書き方の資料があるらしい。
2006年11月8日に日本でレビュー済み
レビューのタイトルどおり、読めばそれなりに面白いけれど、もう少し深堀りしてほしかった、と思ってしまう本です。
タイトルの「UMLは手段」と、「アーキテクトに未来を賭けた」の二部構成ですが、どちらも「うーん、もうちょっと詳しく」という感じです。
第一部「UMLは手段」では、プロジェクトにUMLを採用してみたはいいものの、うまくいかない、というケースについて、なぜ失敗したのか分析しています。この分析までは非常に的確だと思うのですが、著者の説明する「処方箋」がいまひとつ、分かりにくいのです。
「資産構築技術者」だの「第一線技術者」だのといった、著者独自の概念と思われるものが出てくるのですが、説明不足です。なんとなくは分かるのですが・・・
第二部「アーキテクトに未来を賭けた」も同様です。「今、プロジェクトにアーキテクトが必要である」という分析まではうなづけるのですが、「ではアーキテクトをどう育てるか」という対処法の話になると一気に説得力が下がります。いまひとつ具体的にイメージしにくいのです。
新書というフォーマットのせいもあると思います。著者には、ぜひ続編を期待します。
タイトルの「UMLは手段」と、「アーキテクトに未来を賭けた」の二部構成ですが、どちらも「うーん、もうちょっと詳しく」という感じです。
第一部「UMLは手段」では、プロジェクトにUMLを採用してみたはいいものの、うまくいかない、というケースについて、なぜ失敗したのか分析しています。この分析までは非常に的確だと思うのですが、著者の説明する「処方箋」がいまひとつ、分かりにくいのです。
「資産構築技術者」だの「第一線技術者」だのといった、著者独自の概念と思われるものが出てくるのですが、説明不足です。なんとなくは分かるのですが・・・
第二部「アーキテクトに未来を賭けた」も同様です。「今、プロジェクトにアーキテクトが必要である」という分析まではうなづけるのですが、「ではアーキテクトをどう育てるか」という対処法の話になると一気に説得力が下がります。いまひとつ具体的にイメージしにくいのです。
新書というフォーマットのせいもあると思います。著者には、ぜひ続編を期待します。
2006年11月10日に日本でレビュー済み
本のタイトルは「UMLは手段」となっているが、UMLといかにつき合うかについてかかれているのは前半のみ。後半は、「アーキテクト」とはどんな人か?どうやって育成するのかなど。
前半は、よくあるUMLの導入失敗事例を紹介しながら、導入する上でどういう点に気を付けていくべきかなど。後半は、最近、よく雑誌やWebの記事で注目されている「アーキテクト」について。アーキテクトの資質などを紹介しながら、日常でどういったことに気を付けていけばなどが書かれている。
新書というフォーマットUML導入において、「では、具体的にどうしていけば良いか?」などの対策には書かれていない。
前半は、よくあるUMLの導入失敗事例を紹介しながら、導入する上でどういう点に気を付けていくべきかなど。後半は、最近、よく雑誌やWebの記事で注目されている「アーキテクト」について。アーキテクトの資質などを紹介しながら、日常でどういったことに気を付けていけばなどが書かれている。
新書というフォーマットUML導入において、「では、具体的にどうしていけば良いか?」などの対策には書かれていない。