あらすじ
システム開発における最初の関門である「要件定義」を、豊富なイラストや表、具体例を用いてわかりやすく解説しています。現場に立つうえでエンジニアが身につけておくべき知識が満載の一冊です。
...続きを読む感情タグBEST3
Posted by ブクログ
きれいにまとまってかつ網羅的に説明がされてあって分かりやすくい良書でした。
以前とある開発案件紹介サイトのエンジニア評価欄で発注側はセキュリティに関する当たり前のことが満たされていなかったと低評価されたエンジニアが要件で言われてないことを後で要求されたと反論してる案件を目にしました。
この本では要件定義ではベンダー側がユーザー側に隠れた要求を引き出すべきとあるので、悪いのはエンジニア側であるように思います。
さしずめ、このエンジニアは相手からの要求さえ満たせれば問題ないと考えていたのでしょう。
この本を読むことで自分がそういうエンジニアにならないための指標本にもなったと思います。
さらにサンプルなども載っていて、自分で定義書を書く際のヒントにもなりそうです。
こういう本に早く巡り会いたかったと思いました。
Posted by ブクログ
これまで読んだ要件定義と名の付く本の中では最高のものでした。
要件定義についての網羅感があるのと、各方法論の解説に加え、要件定義書のサンプルまで用意されているので、かなり経験が浅くても、この本に従うことで良い要件定義が出来そうなイメージが湧きました。
さらに、ユーザとの要件定義の進め方・会議の仕方などの解説や、事業会社の決裁のされ方についての解説など、要件定義の手前の話も充実していて、それなりに経験を積んだ自分にとっても有益な内容でした。
これは経験の浅いITエンジニアにおすすめしたい一冊。
Posted by ブクログ
要件定義について分かりやすくまとめられている。
特に以下は参考になった。
1
・システムライフサイクルの絵
2
・対象範囲を共有するためにエコシステムマップを作る
3
・情報の一覧化整理
・BABOKの検証チェックリスト
4
・要件定義は具体的な施策まで示さない
・一覧化と整理方法
5
・IPA非機能要求グレード
6
・決定事項の明文化
・要求のライフサイクル管理
Posted by ブクログ
上流レベルの話の詳細が記載されている
図や、例が多くわかりやすい。
ステップを勧めるタイミングに合わせて、繰り返し読んだほうがよさそう
Posted by ブクログ
要件定義のこの類の本は少ない気がする。
内容は基本的なことが多いが、個人商店になりがちな要件定義について網羅的に書かれており、気付くことが多い。
Posted by ブクログ
今後顧客に対してヒアリングしていく上で知識を整理できる良い本だった。
あとがきに「顧客に対して継続的にアドバイス・コンサルしていくような関係が求められていくだろう」という言及があった。
これからも広がっていくであろうクラウドインフラは、アップデートが頻繁なので、常に最新情報を持ち情報提供し続けられるベンダーは価値を出しやすいのではと感じている。
この本には、顧客と良い関係を保っていくための方法が体系的にまとめられているので、一読をすすめる。
Posted by ブクログ
このシリーズなんかしっくりこないんだよな
とりあえず他の要件定義、Se系の本読んでからもう一周しようか
コンサル本も併せて読んだら良い感じになりそう
Posted by ブクログ
基本的なことが描かれているなという印象．
だけど，書いてあることがわかることとできることは違うしその基本の中で漏れているものがないかを振り返ることができる．
よほどの熟練者でない限り要件定義に携わる人は持っておいて損しない一冊ではないだろうか．
＝＝＝＝＝＝＝＝
どこまでやればいい？
→システム規模が見積もれる具体性
→設計工程の作業が進められる詳細度
衝突が発生しがちなシーン
優先順位付、作業開始・終了判定、合意・承認
作業の取り決め
やるべしことは何か
いつ、誰がやるか
合意と承認 の違い
関係者間と握る→合意
最終責任者の受け入れ、文書化された合意内容の凍結→承認
会議→開催目的(共有、最終決裁etc)
ジャッジのための基準を作る。
優先順位付 MoSCoW
must
should
could 余裕があれば可能
won’t 今回は不要
何がどの程度できていれば作業開始可能・終了可能かをチェックリスト化して事前合意 p67
p99 検証のチェックリスト
文書の検証→品質、妥当性
前者:基本的な日本語、表記の統一、言葉の定義...
後者:要件と事業目標との結びつきを確認するもの ユーザ主体、事業目標まで遡って確認できることが重要、達成効果を測定可能な数値で示す
