図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書

エディフィストラーニング株式会社上村有子

[ブクログ · ★★★★★]

きれいにまとまってかつ網羅的に説明がされてあって分かりやすくい良書でした。
以前とある開発案件紹介サイトのエンジニア評価欄で発注側はセキュリティに関する当たり前のことが満たされていなかったと低評価されたエンジニアが要件で言われてないことを後で要求されたと反論してる案件を目にしました。
この本では要件定義ではベンダー側がユーザー側に隠れた要求を引き出すべきとあるので、悪いのはエンジニア側であるように思います。
さしずめ、このエンジニアは相手からの要求さえ満たせれば問題ないと考えていたのでしょう。
この本を読むことで自分がそういうエンジニアにならないための指標本にもなったと思います。
さらにサンプルなども載っていて、自分で定義書を書く際のヒントにもなりそうです。
こういう本に早く巡り会いたかったと思いました。

[ブクログ · ★★★★★]

これまで読んだ要件定義と名の付く本の中では最高のものでした。
要件定義についての網羅感があるのと、各方法論の解説に加え、要件定義書のサンプルまで用意されているので、かなり経験が浅くても、この本に従うことで良い要件定義が出来そうなイメージが湧きました。
さらに、ユーザとの要件定義の進め方・会議の仕方などの解説や、事業会社の決裁のされ方についての解説など、要件定義の手前の話も充実していて、それなりに経験を積んだ自分にとっても有益な内容でした。
これは経験の浅いITエンジニアにおすすめしたい一冊。

[ブクログ · ★★★★☆]

要件定義のこの類の本は少ない気がする。
内容は基本的なことが多いが、個人商店になりがちな要件定義について網羅的に書かれており、気付くことが多い。

[ブクログ · ★★★★☆]

今後顧客に対してヒアリングしていく上で知識を整理できる良い本だった。

あとがきに「顧客に対して継続的にアドバイス・コンサルしていくような関係が求められていくだろう」という言及があった。
これからも広がっていくであろうクラウドインフラは、アップデートが頻繁なので、常に最新情報を持ち情報提供し続けられるベンダーは価値を出しやすいのではと感じている。

この本には、顧客と良い関係を保っていくための方法が体系的にまとめられているので、一読をすすめる。

[ブクログ · ★★★☆☆]

基本的なことが描かれているなという印象．

だけど，書いてあることがわかることとできることは違うしその基本の中で漏れているものがないかを振り返ることができる．
よほどの熟練者でない限り要件定義に携わる人は持っておいて損しない一冊ではないだろうか．

＝＝＝＝＝＝＝＝
どこまでやればいい？
→システム規模が見積もれる具体性
→設計工程の作業が進められる詳細度

衝突が発生しがちなシーン
優先順位付、作業開始・終了判定、合意・承認

作業の取り決め
やるべしことは何か
いつ、誰がやるか

合意と承認　の違い
関係者間と握る→合意
最終責任者の受け入れ、文書化された合意内容の凍結→承認

会議→開催目的(共有、最終決裁etc)

ジャッジのための基準を作る。
優先順位付　MoSCoW
must
should
could 余裕があれば可能
won’t 今回は不要

何がどの程度できていれば作業開始可能・終了可能かをチェックリスト化して事前合意 p67

p99 検証のチェックリスト

文書の検証→品質、妥当性
前者:基本的な日本語、表記の統一、言葉の定義...
後者:要件と事業目標との結びつきを確認するもの　ユーザ主体、事業目標まで遡って確認できることが重要、達成効果を測定可能な数値で示す

[ブクログ · ★★★★☆]

上流レベルの話の詳細が記載されている
図や、例が多くわかりやすい。

ステップを勧めるタイミングに合わせて、繰り返し読んだほうがよさそう