図解入門 よくわかる最新システム開発者のための要求定義の基本と仕組み
上流工程にこれから携わろうと言う人にも、
すでに要求定義に関わっている人にも、
作業や考え方を整理するうえでいい本。
すでに要求定義に関わっている人にも、
作業や考え方を整理するうえでいい本。
| 図解入門 よくわかる最新システム開発者のための要求定義の基本と仕組み | |
![]() | 佐川 博樹 おすすめ平均 ![]() 分類が斬新 論理的かつ「情」も感じる、開発着手の前にまず読みたい本 眼から鱗Amazonで詳しく見る by G-Tools |
- [2007/03/21 13:16]
- 読書〔IT〕 |
- トラックバック(0) |
- コメント(0)
- この記事のURL |
- TOP ▲
要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?
「清水 吉男」の名になんとなく覚えはあった。
一頃「要求定義」に悩まされた。実際はこの後に来る設計やコーディングの段階でその失敗の痛みが出て来るのだが。。。かつて、失敗の分析のためにこんな雑誌を読んだりしたな。
この雑誌で言い足りない部分を書いたのが本書↓だそうだ。
「要求」「理由」「説明」をしっかりわけること。この三つの違いがよくわかっていないといけない。そしてIDをふり階層化して管理していく。散文的になってはいけない。シンプルで当たり前のことにも思えるけど、これを徹底して実践していくのは難しい。その大事さ、実践におけるコツを微に入り細に入り説明している。
■ソフトウェアエンジニアのためのホームページ
http://homepage3.nifty.com/koha_hp/
一頃「要求定義」に悩まされた。実際はこの後に来る設計やコーディングの段階でその失敗の痛みが出て来るのだが。。。かつて、失敗の分析のためにこんな雑誌を読んだりしたな。
| Software People Vol.4 | |
![]() | Software People編集部 おすすめ平均 ![]() プログラマからSEへむけて 燃えないために正確に仕様化しましょう 要件定義の重要性を再認識Amazonで詳しく見る by G-Tools |
この雑誌で言い足りない部分を書いたのが本書↓だそうだ。
| 要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか? | |
![]() | 清水 吉男 おすすめ平均 ![]() 要求仕様の重要性 システムを使う立場の方にもおすすめ とにかく読みづらい ソフトウェア開発に携わる人みんなが読むべき… 内容が冗長すぎAmazonで詳しく見る by G-Tools |
「要求」「理由」「説明」をしっかりわけること。この三つの違いがよくわかっていないといけない。そしてIDをふり階層化して管理していく。散文的になってはいけない。シンプルで当たり前のことにも思えるけど、これを徹底して実践していくのは難しい。その大事さ、実践におけるコツを微に入り細に入り説明している。
■ソフトウェアエンジニアのためのホームページ
http://homepage3.nifty.com/koha_hp/
- [2007/02/24 18:34]
- 読書〔IT〕 |
- トラックバック(0) |
- コメント(0)
- この記事のURL |
- TOP ▲
プロジェクト失敗を回避するには 〜システム開発において〜
この手のシステム開発プロジェクトの運営に関する本を手にしたのは久しぶり。
プロジェクト運営にはPMBOKみたいな手法もあるが、この使用が成功を約束してくれるわけでは決してない。しかも「ITは他の分野に比べて不確実性が大きい」と言われる。プロジェクトの成功に定石はない、というのが本当だろう。したがって、そのための成功ハウツー本も存在し得ない。では、こういった本で勉強する価値はないのだろうか。
『プロジェクトはなぜ失敗するのか』では、「プロジェクトは本来、失敗するものである」とし、そう考えることで「事前の対策にエネルギーを多く費やすことになり」、「失敗する確率、または失敗による影響度を減らすことにつなが」るという。そして逆に、プロジェクトは成功して当然であると考えると、「事前の対策より、失敗した後の担当者への責任追及などの事後対応が中心に」なるともいう。
「プロジェクトは本来、失敗するものである」ということを前提にして、上の二冊には失敗の具体例・典型的パターン、それらの分析がのせられている。システム開発プロジェクトを経験したことのある人だったら身に覚えのある「あるある!」ネタばかり。やはり、こういう本や自分の経験、特に失敗の経験から自ら考えて教訓を引き出し、次に活かさなければならないのだと思う。これらの本にも一応成功ノウハウや立て直し事例ものってはいるが、これに関しては結局、理想論や一般論に留まる印象がある。
予測のつかないプロジェクトを目の前にしたときほど、根拠のない甘く楽観的な見積もりや計画を立ててしまったり、新技術や新手法の「魔法の杖」で何とかなるはずなんて言い合ったりする。典型的なデスマーチの前奏曲。細かな失敗の萌芽をできるだけ早く察知して対処していく地道な繰り返し作業の先に、プロジェクトの成功はあると思う。常に前倒し、前倒しで失敗要因を潰す行動に出ていかねばならない。上の二冊は即座に対処すべき“問題をかぎ分ける嗅覚”を鍛えるのに役立つ。
・・・とは言っても、やはりPMBOKは基本だと思うし、個人的にはWBSも好き(?)っす。
ついでにこんな本もよんだ。上流工程に着き始めたころに読むと良い本。アナリストが書いた冷静な視点。ちょっと一般論が強いかな。ITコンサルが持つべき基本スキルが一通りのっている。
プロジェクト運営にはPMBOKみたいな手法もあるが、この使用が成功を約束してくれるわけでは決してない。しかも「ITは他の分野に比べて不確実性が大きい」と言われる。プロジェクトの成功に定石はない、というのが本当だろう。したがって、そのための成功ハウツー本も存在し得ない。では、こういった本で勉強する価値はないのだろうか。
| プロジェクトはなぜ失敗するのか―知っておきたいITプロジェクト成功の鍵 | |
![]() | 伊藤 健太郎 おすすめ平均 ![]() プロジェクトは本来、失敗するものである 成功をイメージしよう より深い議論が欲しい。 現場の問題がわかっていないのでは? 奇麗事だね。Amazonで詳しく見る by G-Tools |
| さらば!失敗プロジェクト―その経験が成功へ導く | |
![]() | 日経システム構築 おすすめ平均 ![]() 声が届かないから、失敗が繰り返される 参考になりました。 教訓としてはいいかもAmazonで詳しく見る by G-Tools |
『プロジェクトはなぜ失敗するのか』では、「プロジェクトは本来、失敗するものである」とし、そう考えることで「事前の対策にエネルギーを多く費やすことになり」、「失敗する確率、または失敗による影響度を減らすことにつなが」るという。そして逆に、プロジェクトは成功して当然であると考えると、「事前の対策より、失敗した後の担当者への責任追及などの事後対応が中心に」なるともいう。
「プロジェクトは本来、失敗するものである」ということを前提にして、上の二冊には失敗の具体例・典型的パターン、それらの分析がのせられている。システム開発プロジェクトを経験したことのある人だったら身に覚えのある「あるある!」ネタばかり。やはり、こういう本や自分の経験、特に失敗の経験から自ら考えて教訓を引き出し、次に活かさなければならないのだと思う。これらの本にも一応成功ノウハウや立て直し事例ものってはいるが、これに関しては結局、理想論や一般論に留まる印象がある。
予測のつかないプロジェクトを目の前にしたときほど、根拠のない甘く楽観的な見積もりや計画を立ててしまったり、新技術や新手法の「魔法の杖」で何とかなるはずなんて言い合ったりする。典型的なデスマーチの前奏曲。細かな失敗の萌芽をできるだけ早く察知して対処していく地道な繰り返し作業の先に、プロジェクトの成功はあると思う。常に前倒し、前倒しで失敗要因を潰す行動に出ていかねばならない。上の二冊は即座に対処すべき“問題をかぎ分ける嗅覚”を鍛えるのに役立つ。
・・・とは言っても、やはりPMBOKは基本だと思うし、個人的にはWBSも好き(?)っす。
| 名前だけのITコンサルなんていらない | |
![]() | 内山 悟志 おすすめ平均 ![]() 行き詰まった時の解決のヒントが沢山 これから求められるSEのあるべき姿を簡潔に・・・ ITビジネスに関わる人必見の書!!Amazonで詳しく見る by G-Tools |
ついでにこんな本もよんだ。上流工程に着き始めたころに読むと良い本。アナリストが書いた冷静な視点。ちょっと一般論が強いかな。ITコンサルが持つべき基本スキルが一通りのっている。
- [2007/01/29 06:02]
- 読書〔IT〕 |
- トラックバック(0) |
- コメント(0)
- この記事のURL |
- TOP ▲
- | HOME |


分類が斬新
論理的かつ「情」も感じる、開発着手の前にまず読みたい本
燃えないために正確に仕様化しましょう

内容が冗長すぎ
奇麗事だね。
