時代は変わりましたが、それぞれの話題が完結しているので、空いた時間に読み直すのが
楽しみです。中には、古いなと感じる内容もありますが、いろいろと面白いです。
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
ソフトウエア開発 55の真実と10のウソ 単行本 – 2004/4/8
ロバート・L・グラス
(著),
山浦 恒央
(著)
IEEE Software誌の気鋭コラムニストが「名著」をめぐる旅で確信した真実
ソフトウエアの世界には、法則集は多くありますが、本書はソフトウエア開発における「真実」 と「ウソ」をクールな視点でまとめた読み物です。
プロジェクト管理、品質管理、ライフ・サイクル、再利用、見積もり、教育など幅広いジャンルから 引き出した“55”の真実と“10”のウソ。それぞれについて、多くの文献を引用しながら、 概要と「反論」を展開していくユニークな構成です。引用されているのは、トム・デマルコ、 ジェラルド・ワインバーグ、アラン・デービス、フレデリック・ブルックスなど、著名な本ばかりです。 また古典ばかりでなく、アジャイル開発やエクストリームプログラミングなど最近のテーマも取り上げています。
ソフトウエアの世界には、法則集は多くありますが、本書はソフトウエア開発における「真実」 と「ウソ」をクールな視点でまとめた読み物です。
プロジェクト管理、品質管理、ライフ・サイクル、再利用、見積もり、教育など幅広いジャンルから 引き出した“55”の真実と“10”のウソ。それぞれについて、多くの文献を引用しながら、 概要と「反論」を展開していくユニークな構成です。引用されているのは、トム・デマルコ、 ジェラルド・ワインバーグ、アラン・デービス、フレデリック・ブルックスなど、著名な本ばかりです。 また古典ばかりでなく、アジャイル開発やエクストリームプログラミングなど最近のテーマも取り上げています。
- 本の長さ328ページ
- 言語日本語
- 出版社日経BP出版センター
- 発売日2004/4/8
- ISBN-104822281906
- ISBN-13978-4822281908
商品の説明
メディア掲載レビューほか
ソフトウエア開発55の真実と10のウソ
プロジェクト管理、ライフサイクル、品質――。ソフトウエア開発におけるこれらの概念の“真実”と“ウソ”を、痛快に指摘した1冊。コンピュータ業界で45年間のキャリアを持つベテラン・エンジニアである著者が、「遅れているプロジェクトに人を追加すると、もっと遅れる」といった真実や、「ソフトウエアには、もっと開発方法論が必要である」といったウソを紹介する。
プロジェクト管理、ライフサイクル、品質――。ソフトウエア開発におけるこれらの概念の“真実”と“ウソ”を、痛快に指摘した1冊。コンピュータ業界で45年間のキャリアを持つベテラン・エンジニアである著者が、「遅れているプロジェクトに人を追加すると、もっと遅れる」といった真実や、「ソフトウエアには、もっと開発方法論が必要である」といったウソを紹介する。
どの真実、どのウソでも、興味のあるものから気軽に読み始められる構成になっている。それぞれの真実やウソを説明する文章の後には、想定される反論意見を載せてあり、読者が自ら考える材料を豊富に与えてくれる。関連する文献や論文などの情報源も多数紹介されており、全体として親切な作りである。
著者は「非常に基本的なものなのに、簡単に忘れてしまい、よく覚えていない“真実”と“ウソ”を集中的に集めた」という。ステップアップを望むソフトウエア技術者にぜひお薦めしたい。
(日経コンピュータ 2004/05/31 Copyright©2001 日経BP企画..All rights reserved.)
-- 日経BP企画
内容(「MARC」データベースより)
現代のソフトウエア産業は、19世紀末の怪しい売薬業と状況が似ている。ソフトウエア業界の誰を信じれば良いのか? 真実はどこにあるのか? ソフトウエア開発の基本となる55の真実と10のウソをすべて紹介。
登録情報
- 出版社 : 日経BP出版センター (2004/4/8)
- 発売日 : 2004/4/8
- 言語 : 日本語
- 単行本 : 328ページ
- ISBN-10 : 4822281906
- ISBN-13 : 978-4822281908
- Amazon 売れ筋ランキング: - 416,807位本 (本の売れ筋ランキングを見る)
- - 8,614位電気・通信 (本)
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2009年4月5日に日本でレビュー済み
Amazonで購入
ソフトウェアを一から開発するときにその技法、技術について自分がどれだけ知っているか、知らないことがどれだけあるかを学びたくて購入。
通読してみると、ソフトウェア開発について、PMから要求仕様書作成や、コーディング、テスト、運用までライフサイクル全体にわたっての問題、定説などを開設してくれている。全体を問うして認識させられたのは、プロジェクトマネジメントなどの技法では、メジャラブルな情報で管理するというのが基本でそれは間違いないと著者も述べているが、実際にはプログラム、ツールの複雑性の濃度、生成物の分野の複雑度、人の能力の違いなどにより均一的な管理を前提としたマネジメントは難しいと述べられている気がする。また、本書の中にはそれに対する根拠も数多く提示されている感がある。おもしろかったのはインスペクションに対する評価だ。開発工程の中でウェイトを置くべきものというイメージはなかったが、本書を通して価値を再認識できた。
ソフトウェアを開発する上で識者たちが培った忘れがちな暗黙知にあたる内容を明文化してくれている書籍だと思う。
通読してみると、ソフトウェア開発について、PMから要求仕様書作成や、コーディング、テスト、運用までライフサイクル全体にわたっての問題、定説などを開設してくれている。全体を問うして認識させられたのは、プロジェクトマネジメントなどの技法では、メジャラブルな情報で管理するというのが基本でそれは間違いないと著者も述べているが、実際にはプログラム、ツールの複雑性の濃度、生成物の分野の複雑度、人の能力の違いなどにより均一的な管理を前提としたマネジメントは難しいと述べられている気がする。また、本書の中にはそれに対する根拠も数多く提示されている感がある。おもしろかったのはインスペクションに対する評価だ。開発工程の中でウェイトを置くべきものというイメージはなかったが、本書を通して価値を再認識できた。
ソフトウェアを開発する上で識者たちが培った忘れがちな暗黙知にあたる内容を明文化してくれている書籍だと思う。
2004年5月7日に日本でレビュー済み
Amazonで購入
SEを10年もやってると、いろいろな経験則が自分の中で生まれてきますが、なかなかズバリと表現することは難しいものです。
「○○はどれくらい時間がかかる?」
「半月ほど・・・」
「どうして?」
「何となく・・・」
こんな風にモヤモヤとしたものをスッキリとさせてくれるのが本書です。自分の考えは間違いではなかったと安心することができるでしょう。また、経験の浅いSE諸君は先輩の知恵を”盗む”ことができます。
本書の中でたびたび参考文献として登場する、「ソフトウェア開発201の鉄則」もオススメです!
「○○はどれくらい時間がかかる?」
「半月ほど・・・」
「どうして?」
「何となく・・・」
こんな風にモヤモヤとしたものをスッキリとさせてくれるのが本書です。自分の考えは間違いではなかったと安心することができるでしょう。また、経験の浅いSE諸君は先輩の知恵を”盗む”ことができます。
本書の中でたびたび参考文献として登場する、「ソフトウェア開発201の鉄則」もオススメです!
2011年8月28日に日本でレビュー済み
50年近くソフトウェア開発業界に関わってきた著者が、ソフトウェア開発における真実とウソを列挙する形式の本。
真実が55個、ウソが10個の割合だ。
この類の本は様々あるし、実際にソフトウェア開発に携わっていれば、なんとなく感覚で身に付いてしまうことも多いだろう。
プログラマの質により生産性に10倍以上の差が出ることははっきりしているし、見積手法は確立されているのにそのとおりにいかないことも長年言われてきた。
ソフトウェア開発者として、目からウロコと言うわけには行かないが、あるあるこんなこと!と思うことが溢れている。
著者と翻訳者が堅実な方らしく、ほとんどの内容に典拠となる論文や参考文献を挙げているので、もっと研究したい方は原典に当たることができるようになっている。
ただ、一般の開発者はそこまで不要な気がする。
一点気になったのは、「計測できないことは管理できない」についてだ。
管理できないではなく、制御できないが原典だと言うことなのだ。原文の英語は何なのだろう。それぞれcontrolとmanageだろうか。日本語で「管理」と訳されてしまう言葉は英語にたくさんあるので、このような言葉遣いの違いを言う時にはカッコ書きで原文を示して欲しい。
真実が55個、ウソが10個の割合だ。
この類の本は様々あるし、実際にソフトウェア開発に携わっていれば、なんとなく感覚で身に付いてしまうことも多いだろう。
プログラマの質により生産性に10倍以上の差が出ることははっきりしているし、見積手法は確立されているのにそのとおりにいかないことも長年言われてきた。
ソフトウェア開発者として、目からウロコと言うわけには行かないが、あるあるこんなこと!と思うことが溢れている。
著者と翻訳者が堅実な方らしく、ほとんどの内容に典拠となる論文や参考文献を挙げているので、もっと研究したい方は原典に当たることができるようになっている。
ただ、一般の開発者はそこまで不要な気がする。
一点気になったのは、「計測できないことは管理できない」についてだ。
管理できないではなく、制御できないが原典だと言うことなのだ。原文の英語は何なのだろう。それぞれcontrolとmanageだろうか。日本語で「管理」と訳されてしまう言葉は英語にたくさんあるので、このような言葉遣いの違いを言う時にはカッコ書きで原文を示して欲しい。
2007年11月20日に日本でレビュー済み
→ソフトウェア開発に対して問題提起をしている本です
その問題提起は、経験から発想した単なる思いつきではなく
経験を通しての詳細な観察、追求に追求を重ねた文献研究から
導き出されたものであるため
それぞれが磨かれた宝石のようにキラキラしています
→問題提起だけではありません
その問題に対する自論だけでなく
想定される反論についても、
著者自身が仮説を立て提示しています
→管理者視点の問題提起も面白いですが
開発者視点の問題提起の方が生き生きと筆が踊っています
著者が大学に移ってからも忘れなかった「一技術者としての魂」が
そうさせているんだと思います
→私が特に、議論したい真実はこれ
「仕様設計フェーズから設計フェーズに移るとき
膨大な数の派生仕様が生じる。
これは、問題解決プロセスが複雑なために発生するもので、
この設計仕様の量は、元の仕様の50倍になることもある。」
(P124)
..誰かといつか、議論したいものです
→「多くの目にさらせば、バグは枯れる」(P276)
これは、10のウソの中の1つです
反論..できますか?
その問題提起は、経験から発想した単なる思いつきではなく
経験を通しての詳細な観察、追求に追求を重ねた文献研究から
導き出されたものであるため
それぞれが磨かれた宝石のようにキラキラしています
→問題提起だけではありません
その問題に対する自論だけでなく
想定される反論についても、
著者自身が仮説を立て提示しています
→管理者視点の問題提起も面白いですが
開発者視点の問題提起の方が生き生きと筆が踊っています
著者が大学に移ってからも忘れなかった「一技術者としての魂」が
そうさせているんだと思います
→私が特に、議論したい真実はこれ
「仕様設計フェーズから設計フェーズに移るとき
膨大な数の派生仕様が生じる。
これは、問題解決プロセスが複雑なために発生するもので、
この設計仕様の量は、元の仕様の50倍になることもある。」
(P124)
..誰かといつか、議論したいものです
→「多くの目にさらせば、バグは枯れる」(P276)
これは、10のウソの中の1つです
反論..できますか?
2009年11月1日に日本でレビュー済み
私がソフトウェア開発で実際に体感していることを真実として、
多く取り上げられていたので共感できました。
また、その真実を具体的な数値で示しているところが参考になりました。
世の中には「真実」と「ウソ」の情報が満ち溢れています。
それを見抜く力を少しばかり得られました。
信用度の高い研究をしてきた人の名前が列挙しているところなど、
著者の本物を追求する研究の成果ではないでしょうか。
私がもっとも参考になった真実を一つあげると、
「ソフトウェアの開発ライフサイクルは、20・20・20・40」というものです。
多く取り上げられていたので共感できました。
また、その真実を具体的な数値で示しているところが参考になりました。
世の中には「真実」と「ウソ」の情報が満ち溢れています。
それを見抜く力を少しばかり得られました。
信用度の高い研究をしてきた人の名前が列挙しているところなど、
著者の本物を追求する研究の成果ではないでしょうか。
私がもっとも参考になった真実を一つあげると、
「ソフトウェアの開発ライフサイクルは、20・20・20・40」というものです。
2005年11月26日に日本でレビュー済み
この本のポイントは,2つ
・普通の、そして現場で働いている人が実際に感じるという意味で議論の価値がある問題を提起し、さらに非常に納得行く形で、問題を明文化していること
・ 問題に対する真実やウソの評価のための議論において、著者の意見の言いっぱなしジャーマンだけでなく、ソフトウェア工学の論文や過去の名著をきちんと参照していること。
あなたがソフトウェアの開発に携わっている方なら、まずは,自分が感じる問題があるか眺めて見よう.必ず壷にはまる問題を見つけることが出来るはずだ。
その次に本当にどう改善したいのかを考えた時に、この本を読み込もう。さらに議論を深めたいなら、この本が参照している論文や名著を探ろう。
個人的に,もっとも影響を与えている本の一つ.お勧め.ついでに訳も最高に良くこなれている。
・普通の、そして現場で働いている人が実際に感じるという意味で議論の価値がある問題を提起し、さらに非常に納得行く形で、問題を明文化していること
・ 問題に対する真実やウソの評価のための議論において、著者の意見の言いっぱなしジャーマンだけでなく、ソフトウェア工学の論文や過去の名著をきちんと参照していること。
あなたがソフトウェアの開発に携わっている方なら、まずは,自分が感じる問題があるか眺めて見よう.必ず壷にはまる問題を見つけることが出来るはずだ。
その次に本当にどう改善したいのかを考えた時に、この本を読み込もう。さらに議論を深めたいなら、この本が参照している論文や名著を探ろう。
個人的に,もっとも影響を与えている本の一つ.お勧め.ついでに訳も最高に良くこなれている。
2010年2月15日に日本でレビュー済み
本書はソフトウェア開発について55の真実と10の嘘について解説したものです。
ソフトウェア開発のエンジニアリングは歴史が浅いので当然、いままでの経験による
著者が見つけた真実となります。
ただし、その解説にはきちっと証拠となる文献とのせ、読者が自分でかんがえて比較できるように
きちんと反論ものせています。
本書を読むだけでソフトウェア開発のスキルがあがること間違いなし。
参考文献も豊富に記載されているのでこれをもとにさらに勉強することもできます。
ソフトウェア開発のエンジニアリングは歴史が浅いので当然、いままでの経験による
著者が見つけた真実となります。
ただし、その解説にはきちっと証拠となる文献とのせ、読者が自分でかんがえて比較できるように
きちんと反論ものせています。
本書を読むだけでソフトウェア開発のスキルがあがること間違いなし。
参考文献も豊富に記載されているのでこれをもとにさらに勉強することもできます。