ホントにためになりました。
ソフトウェア開発がウマく行かない原因に関する指摘は、
発注者の立場としては、耳が痛いものがありましたね。
要するに、
・発注者側:要求仕様をちゃんと出しましょう。
・受注側:要求仕様をちゃんと出してもらいましょう。
ということなんですけど…ね。
まぁ開発プロセスが、そんなにキッチリ型にはまることってなかなか有り得ないんでしょうけど、こうすればウマく行くという最良の形を勉強しておくことも重要だと思いました。
¥4,399¥4,399 税込
無料配送 6月6日-7日にお届け
発送元: 令和書店 毎日発送中です!【安心の返金保証適用品】 販売者: 令和書店 毎日発送中です!【安心の返金保証適用品】
¥4,399¥4,399 税込
無料配送 6月6日-7日にお届け
発送元: 令和書店 毎日発送中です!【安心の返金保証適用品】
販売者: 令和書店 毎日発送中です!【安心の返金保証適用品】
¥1¥1 税込
配送料 ¥320 6月9日-11日にお届け
発送元: ネットオフ 販売者: ネットオフ
¥1¥1 税込
配送料 ¥320 6月9日-11日にお届け
発送元: ネットオフ
販売者: ネットオフ
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか? 単行本 – 2005/10/7
清水 吉男
(著)
{"desktop_buybox_group_1":[{"displayPrice":"¥4,399","priceAmount":4399.00,"currencySymbol":"¥","integerValue":"4,399","decimalSeparator":null,"fractionalValue":null,"symbolPosition":"left","hasSpace":false,"showFractionalPartIfEmpty":true,"offerListingId":"ggdjh6w93BWC7RWP5DcXwIIrI%2F5afBb8J6TbFtepS%2By8TB6NbspAARG%2Fks%2Flgmv%2FnDIVT%2F3%2B8On%2F8zKo%2BsvfZTlvy1G%2FsqwtqEiQjwh1%2FEI%2BwFYdj0az3tzt2%2FrAOWYunN6lb2XyNjKSFfSZjS403csX1wDWHK3%2FSbx4AfLpLfpnWNx2TyyXmA%3D%3D","locale":"ja-JP","buyingOptionType":"NEW","aapiBuyingOptionIndex":0}, {"displayPrice":"¥1","priceAmount":1.00,"currencySymbol":"¥","integerValue":"1","decimalSeparator":null,"fractionalValue":null,"symbolPosition":"left","hasSpace":false,"showFractionalPartIfEmpty":true,"offerListingId":"ggdjh6w93BWC7RWP5DcXwIIrI%2F5afBb8zN%2Bu0Pfb4TuD1g6zTIGXwvK7Smb4wmdxcG8kyA7%2F7YUuDO4FrEqna6RmbN7WZkIktLG9qmFf0ZyTjHspQDgLJpEdQ%2BRHrpaR4NTFaFZO7LknPsqBdk7itxaM3gZPAu9Pbk5hxACnZ6gr%2BRXLUVFnGw%3D%3D","locale":"ja-JP","buyingOptionType":"USED","aapiBuyingOptionIndex":1}]}
購入オプションとあわせ買い
ソフトウェア開発の根本であり工程すべてに関わってくる「要求の仕様化」について、現場で指導にあたる著者がその重要性からじっくりと解説していきます。「要求」とはなにか「仕様」とはなにかという「本質」から説き、仕様書作りの考え方や表現方法を具体的に提示します。相次ぐ「仕様の変更」に悩まされる現場のエンジニア必携の一冊です。
- 本の長さ368ページ
- 言語日本語
- 出版社技術評論社
- 発売日2005/10/7
- ISBN-104774125237
- ISBN-13978-4774125237
この商品をチェックした人はこんな商品もチェックしています
ページ 1 以下のうち 1 最初から観るページ 1 以下のうち 1
商品の説明
出版社からのコメント
◆こんな方におすすめ
・相次ぐ「仕様の変更」や「バグの発生」に悩まされているエンジニアに
・ソフトウェア開発をスムーズに進めたいエンジニアに
・要求仕様に関心があるすべてのエンジニアに
・システムの発注者側の人にも
・相次ぐ「仕様の変更」や「バグの発生」に悩まされているエンジニアに
・ソフトウェア開発をスムーズに進めたいエンジニアに
・要求仕様に関心があるすべてのエンジニアに
・システムの発注者側の人にも
登録情報
- 出版社 : 技術評論社 (2005/10/7)
- 発売日 : 2005/10/7
- 言語 : 日本語
- 単行本 : 368ページ
- ISBN-10 : 4774125237
- ISBN-13 : 978-4774125237
- Amazon 売れ筋ランキング: - 742,526位本 (本の売れ筋ランキングを見る)
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2006年3月17日に日本でレビュー済み
Amazonで購入
2012年10月28日に日本でレビュー済み
問題点の考察から始まり、
要求の定義、仕様とは?(ここまで入門)
そして
仕様化の技術、管理と測定へと
話しが進みます(実践)
大変、良い本です。
丁寧で内容が濃く、一読に値します。
ソフト開発の経験があると
第一部の
『要求仕様にまつわる問題』を飛ばし、
第二部の
『要求仕様を書く』から読みたく成りますが、
実は第一部が重要だったりします。
実践での筆者が解説している
エクセルを使った方法も
流石、実践で鍛えただけ有って
使える方法です。
しかし、
この方法を実践する事で自ずと身に付くのでしょうが、
本を読んだ直後から結果を出すのは難しいです。
出来そうで、出来ない・・・
マイナスを上げれば
幾つかの例題を並行して各段階で解説していますが、
それが、全体を読み難く、間延びした感じに
しちゃってます。
読む価値のある本です。
要求の定義、仕様とは?(ここまで入門)
そして
仕様化の技術、管理と測定へと
話しが進みます(実践)
大変、良い本です。
丁寧で内容が濃く、一読に値します。
ソフト開発の経験があると
第一部の
『要求仕様にまつわる問題』を飛ばし、
第二部の
『要求仕様を書く』から読みたく成りますが、
実は第一部が重要だったりします。
実践での筆者が解説している
エクセルを使った方法も
流石、実践で鍛えただけ有って
使える方法です。
しかし、
この方法を実践する事で自ずと身に付くのでしょうが、
本を読んだ直後から結果を出すのは難しいです。
出来そうで、出来ない・・・
マイナスを上げれば
幾つかの例題を並行して各段階で解説していますが、
それが、全体を読み難く、間延びした感じに
しちゃってます。
読む価値のある本です。
2007年2月28日に日本でレビュー済み
古くは設計工学の「設計理由」、アジャイルの「顧客&ストーリーボード」や、Carolynの「ペーパープロトタイピング」などに、断片的に含まれている「モノを作るための合意」を単独の技術として明らかにした良書です。しかし、筆者の想いと、書籍の設計理由と、仕様書を書くテクニックが、全て綯い交ぜになった結果、大変読みにくくなっています。軽く抜き出すと以下のような項目になるでしょうか。1. 要求仕様なくして、まともな開発などできるものか2. 利害関係者との合意があれば、食い違いや後戻りを未然に防止できる3. 要求仕様は設計書ではないが、設計を誘導する力はある4. 要求には理由をつけると解決したいことが明確になる5. 説明を加えてもいいけど、要求とはきっちり分けておく6. 要求には、番号を振ってチェックマーク欄もつけておく7. 要求を階層化してもいいけど、せいぜい2階層までに8. 表現するべき範囲を明確にし、カテゴリ化しよう9. 分析でも設計でもなく、意図を伝えるためにカテゴリを考えよう10. カテゴリをうまく立てると筋違いや担当違いの要求を書かなくなる11. 否定表現は{if (A) else (B)}の(A)を洩れを見付ける良い機会12. 要求仕様書は抜け,洩れを検出する技術であるただ、これらを全て実践でき、他人に教えられるくらいなら、筆者のように独立できるわけでして(笑)。実際にやってみると、どうしても要求仕様書に実装、設計のパラメータを含んでしまうので困りました。個人的には、「分野や時代背景が多少変わっても、そのまま通用する要求」が良い要求かな?と漠然と思っております。
2009年6月13日に日本でレビュー済み
Amazonで購入
ソフトウェアの要求仕様書の書き方に関する本である。
自らの経験をベースに、仕様化がなぜ失敗するのか、成功するにはどうするべきかということに関して丁寧に解説してある。
ある程度経験を積んで、仕様化に関して苦い経験を重ねた方であれば、共感できる部分もあるだろうが、経験がなく、仕様化というものがどういうものかということを知りたい方にはピンとこないと思う。私は後者なのだが、最後までピンとこなかった。
経験談をベースに延々と書かれているので、冗長で、要点が何か分からないと感じてしまった。
また、経験が浅いためか、あたりまえじゃないかと思うことも多かった気がする。
筆者は、自分の主義とは違うもの(アジャイルやWordなど様々)に関して、態度を明確にし、批判しているが、どれも根拠に説得力がない。
結論は、仕様化に関して苦い経験を積んでおり、自分の手法に疑問を持っている方には得るものがあるかもしれないが、まったく経験がなく、これから始めるという方には向いていない本だと思う。
自らの経験をベースに、仕様化がなぜ失敗するのか、成功するにはどうするべきかということに関して丁寧に解説してある。
ある程度経験を積んで、仕様化に関して苦い経験を重ねた方であれば、共感できる部分もあるだろうが、経験がなく、仕様化というものがどういうものかということを知りたい方にはピンとこないと思う。私は後者なのだが、最後までピンとこなかった。
経験談をベースに延々と書かれているので、冗長で、要点が何か分からないと感じてしまった。
また、経験が浅いためか、あたりまえじゃないかと思うことも多かった気がする。
筆者は、自分の主義とは違うもの(アジャイルやWordなど様々)に関して、態度を明確にし、批判しているが、どれも根拠に説得力がない。
結論は、仕様化に関して苦い経験を積んでおり、自分の手法に疑問を持っている方には得るものがあるかもしれないが、まったく経験がなく、これから始めるという方には向いていない本だと思う。
2017年12月26日に日本でレビュー済み
ふわっとしていた要求仕様に対する疑問解決の糸口を得られた。
要求に関して特に重要だもと感じたものは以下の4つ。
「要求」「仕様」「説明」を一意に識別できる記載とする。
「要求」は動詞形で表現する。
「要求」は範囲を指定する。
「要求」は「理由」とセットである。
要求に関して特に重要だもと感じたものは以下の4つ。
「要求」「仕様」「説明」を一意に識別できる記載とする。
「要求」は動詞形で表現する。
「要求」は範囲を指定する。
「要求」は「理由」とセットである。
2008年12月31日に日本でレビュー済み
個人的に作っている小さなシステムを構築する上で、「何をどこまでやればよいか」がはっきりしないのは、そもそも要求を仕様化できていないからであると気づき、本書を読むことにした。
本書のアウトラインと、読んでみた感想を以下に記述する。
【本書の内容】
□要求仕様化テクニックの説明
◇具体的な要求仕様書フォーマットが提示されており分かりやすい
◇具体的な事例が多用されており分かりやすい
◇要求の分割と階層化
□要求仕様化の工程に注力することの重要性
◇要求がきちんと仕様化されていない状態で設計以降の工程に入ると
後戻りや問い合わせの頻発で工数が膨れ上がる
◇要求仕様書の精度を高くすれば仕様変更率を低く抑えることができる
◇要求仕様書の精度を高くすれば派生開発時の工数・バグを低減可能
□要求仕様化のテクニックの応用
◇リスク管理に適用可能
【感想】
・役に立つことが書いてある。
・提示されている要求仕様書作成手法をまず一度試してみようと思う。
・具体的な事例が多い。というか、著者の経験豊富さ・発想豊かさが伝わる。
・著者はとても研究熱心な人だと感じた。
・著者の文章に癖があるからなのか、私の脳との相性の問題なのか、
頭の中に内容が入って行きにくいので読了に時間と忍耐が必要だった。
⇒ただし、それらのコストを払ってでも読了した価値は十分にあった。
本書のアウトラインと、読んでみた感想を以下に記述する。
【本書の内容】
□要求仕様化テクニックの説明
◇具体的な要求仕様書フォーマットが提示されており分かりやすい
◇具体的な事例が多用されており分かりやすい
◇要求の分割と階層化
□要求仕様化の工程に注力することの重要性
◇要求がきちんと仕様化されていない状態で設計以降の工程に入ると
後戻りや問い合わせの頻発で工数が膨れ上がる
◇要求仕様書の精度を高くすれば仕様変更率を低く抑えることができる
◇要求仕様書の精度を高くすれば派生開発時の工数・バグを低減可能
□要求仕様化のテクニックの応用
◇リスク管理に適用可能
【感想】
・役に立つことが書いてある。
・提示されている要求仕様書作成手法をまず一度試してみようと思う。
・具体的な事例が多い。というか、著者の経験豊富さ・発想豊かさが伝わる。
・著者はとても研究熱心な人だと感じた。
・著者の文章に癖があるからなのか、私の脳との相性の問題なのか、
頭の中に内容が入って行きにくいので読了に時間と忍耐が必要だった。
⇒ただし、それらのコストを払ってでも読了した価値は十分にあった。
2007年2月5日に日本でレビュー済み
要求仕様の重要性を耳が痛くなるほど、
叩き込まれます。
この本の一番良いところは、
要求仕様を書くのにExcelを使った方法の解説があり、
とても参考になりました。
この方法を実践してみて手応えを感じました。
要求仕様の重要性を理解するために、
第1部で多くのページ数を割いているのですが、
ここを読むのが辛かったです。
重要な箇所なんでしょうが、
もう少し完結にして欲しいです。
叩き込まれます。
この本の一番良いところは、
要求仕様を書くのにExcelを使った方法の解説があり、
とても参考になりました。
この方法を実践してみて手応えを感じました。
要求仕様の重要性を理解するために、
第1部で多くのページ数を割いているのですが、
ここを読むのが辛かったです。
重要な箇所なんでしょうが、
もう少し完結にして欲しいです。
2008年3月8日に日本でレビュー済み
他のレビュアーの皆様のご意見では、説明が冗長で分かりにくいというものもあったが、、、
自分は筆者の著書としてはこれが2冊目(先に「派生開発」に関する著作を読んだ)で、『要求を仕様化し表現する技術』の重要性に対する筆者の思い入れの強さや、筆者独特の言い回しに慣れていたので、あまり苦にならず、割とスムーズに読めた。
どちらの書籍もかなりのページ数だが、まず第一に装丁がすばらしい。
活字もレイアウトも(紙質も)ちょうど良く、いずれの書籍も通勤電車の中でそれぞれ1週間程で読み切った。(長距離通勤をしているためだが、、)
確かに至る所に筆者の経験に基づく実例(しかも組込系のプロジェクトに関して)が織り込まれているので、冗長とか読みにくいというご意見が出るのもごもっともだが、自分としてはそこがむしろ良かったと思っている。
開発の現場は奇麗事では済まされない。従来の方法のどこが逝けないかだけではなく、なぜその拙い方法が繰り返されてしまうのか?また、筆者が提唱している方法のどこが良いのか?しかし実践するに当たってどこが難しいのか?いち早く効果をあげるためにはどこから取り組めばよいのか?など、非常に実践的な内容だと思う。
システムの発注側/受注側、要件定義を行う人、設計者、実装担当者、テスター、プロジェクトマネージャーなど、システム開発に携わる全ての人に一読をお勧めしたい。
いや、一読ではもったいないので、是非ともボロボロになるまで何回も読んで欲しい一冊!
(まずは自分が模範を示すべきか・・・)
自分は筆者の著書としてはこれが2冊目(先に「派生開発」に関する著作を読んだ)で、『要求を仕様化し表現する技術』の重要性に対する筆者の思い入れの強さや、筆者独特の言い回しに慣れていたので、あまり苦にならず、割とスムーズに読めた。
どちらの書籍もかなりのページ数だが、まず第一に装丁がすばらしい。
活字もレイアウトも(紙質も)ちょうど良く、いずれの書籍も通勤電車の中でそれぞれ1週間程で読み切った。(長距離通勤をしているためだが、、)
確かに至る所に筆者の経験に基づく実例(しかも組込系のプロジェクトに関して)が織り込まれているので、冗長とか読みにくいというご意見が出るのもごもっともだが、自分としてはそこがむしろ良かったと思っている。
開発の現場は奇麗事では済まされない。従来の方法のどこが逝けないかだけではなく、なぜその拙い方法が繰り返されてしまうのか?また、筆者が提唱している方法のどこが良いのか?しかし実践するに当たってどこが難しいのか?いち早く効果をあげるためにはどこから取り組めばよいのか?など、非常に実践的な内容だと思う。
システムの発注側/受注側、要件定義を行う人、設計者、実装担当者、テスター、プロジェクトマネージャーなど、システム開発に携わる全ての人に一読をお勧めしたい。
いや、一読ではもったいないので、是非ともボロボロになるまで何回も読んで欲しい一冊!
(まずは自分が模範を示すべきか・・・)